カテゴリー: Linux

世間では，Windowsパソコンで世界規模の障害が発生し，航空会社のシステム等で影響があったようです。
（参考：TBS NEWS DIG「Windows世界規模システム障害　原因はセキュリティソフト」）

セキュリティソフトの不具合のみで，世界規模の障害が起きてしまうとはとても恐ろしいことですし，この世界規模の障害のようにWindowsパソコンでブルー画面が発生した場合には，その原因がわかるまで非常にあせってしまいます。

当事務所でもいろいろなシステムを利用していますが，その一つにデータ保管のクラウドサーバーとしてNextcloudサーバーを利用しています。

クラウドサーバーは，一般的にgoogleドライブやOne Driveを利用する方法もありますが，特に重要な個人情報を扱うため，さすがにグローバルサーバーを安易に利用することができません。どこで急にハッキングされたり，漏れたりするかわからないからです。また，一般的なクラウドサービスは，そのサービス会社の従業員であれば，中身を覗けるという情報も存在します。

その点，自社のNextcloudでは，物理的に自社内でFedoraサーバーを構築しており，あくまでもイントラネット上でのみ使用しているため，外部に情報が出ることはまずあり得ません。よって，セキュリティ的には安心なのですが，問題なのは不具合が発生した場合には自身で修復しなければなりません。

最近の問題点として，Nextcloudが29.0.3にアップデートしたところ，アクセス中「Internal Server Error」が発生しました。error_logを調べると

[時刻] [core:alert] [pid xxxx:tid xxxx] [client 127.xxx.xxx.xxx:xxxx] /usr/share/nextcloud/.htaccess: ErrorDocument not allowed here

が記録されました。

全くデータの同期がされなくなり，大変困りましたが，Fedoraでは以下の方法で修復できました。

vi /etc/httpd/conf.d/nextcloud-(利用しているもの).inc

#Apache 2.4　以降に追記↓
AllowOverride All

FedoraでNextcloudを利用するかたは，参考にしてみてください。

Windowsであっても，Linuxであっても文字を操作するプログラムには，文字コード変換が絡んでくる場合が多いです。

Windowsの場合は，以前のプログラムの文字コードがShift-JISのままになっており，最近ではUTF-8に変換する必要があります。

Fedoraにおいては，創生初期からUTF8を採用しており，特に問題にはならない場合が多いのですが，昔の資産であるbashコード等のプログラムを利用するため，system()やexec()を利用したときに変な現象に遭遇しました。

その現象とは，例えば以下のようなソースを，コマンドラインで直接実行した場合と，Web経由でPerl(CGI)とsystem()を利用してbashとして実行したときに全く別の結果が出ました。

#!/bin/bash
test=’長野県長野市’
echo ${test:0:3}

bashやperl:　長野県
Apache経由CGI:　長

説明すると，通常は前から３文字目まで文字の切り出しをして表示するので，「長野県」と出力されるのが正しいところ，Web経由で「長」と出力するのみで文字化けのような状況になりました。

よく考えるとCGIの場合，漢字1文字で3バイトであるため，3バイト分しか表示していないことがわかります。

試しに以下の実行命令をしのばせておくと

locale

出力にOSからのコマンドラインやPerlからexec()やsystem()で実行した場合には，”ja_JP.UTF-8″と表示するにも関わらず，CGIから実行した場合には，”POSIX”を表示してしまいました。このままでは，コマンドラインとWeb環境では日本語処理が同じようにできない状態です。解決方法としては上記ソースの2行目に

export LANG=ja_JP.UTF-8

を挿入すれば，Apacheでも正常に文字の切り出しができることがわかりました。

本来はどうすればいいか調べると，どのサーバー環境の文字環境でも対応できるよう，POSIXに統一してソースを書いたほうがベストらしいので，

#!/bin/bash
export LANG=POSIX
test=’長野県長野市’
echo ${test:0:9}

とするほうが正しいのかも知れません。しかし，プログラムが長い場合，大量の文字数の書き換え等が必要となってしまいます。古い資産を使うという点では，system()やexec()の用いたときには，ソースを書き換えずには利用したいので，対処方法としては「export LANG=ja_JP.UTF-8」の1行を挿入するほうを選択しました。

UNIXやLinuxはすでに歴史が長くなってきているので，昔の人が作ったプログラムをそのまま実行したいというニーズも多いかと思いますので，参考にしてください。

以前Fedora39からFedora40に移行について，記事にしましたが，Webサーバーからのファイル出力やデバイスの制御ができなくなってしまい，かなり手を焼きました。

症状としては，Fedora39からFedora40にアップデートしてから，FAXサーバー（efax）と知識の整理に使っていた「YukiWiki」というウェブアプリケーションが使えなったことです。

eFAXは，受信も送信も使えなくなりましたが，送受信それぞれ原因は異なりました。FAXの送信ができない理由とYukiWikiが使えなくなった理由は一緒でした。

FAX受信のほうは，もともとtiff形式で受信するため，tiffをPDFに変換するソフトが必要で，今までは「tiff2pdf」を利用していましたが，Fedora40からバンドルされなくなったのが原因です。
これについては，他のツール「ImageMagick」のconvertというコマンドを使うことにして解決しました。

convertの使い方は

convert recivefax.000.tiff recivefax.001.tiff recivefax.pdf

というように，複数のtiffファイルを１冊のPDFにすることも可能なので比較的移行が簡単にできました。

FAX送信のほうはかなりたいへんでした。症状としては，httpd(Apacheサーバー)から，/home以下にファイルの出力ができなくなったことと，/dev/serial　といったモデムデバイスにアクセスできなくなったことです。

例えば，次のcgiを作成してWebサーバー上からアクセスした場合，

open(DATAFILE, “> ./test.txt”) or die(“Error:$!”);
print DATAFILE “長野県\n”;
close(DATAFILE);

通常なら，cgiのあるディレクトリ上にtest.txtというファイルが作成され，長野県と文字が入力されますが，作成されず，エラーログを確認すると

[cgid:error] [pid xxxxxx:tid xxxxxx] [client ::1:xxxxx] AH01215: stderr from /home/hoge/test.cgi: Error:Read-only file system at /home/hoge/test.cgi line 1.

が「/var/log/httpd/error_log」上に出力されます。他にも，PukiWikiを実行して，テキストの書換えを行うと

AH01215: stderr from /home/hoge/test.cgi: Permission denied at /home/hoge/test.cgi line x.

や

AH01215: stderr from /home/hoge/wiki.cgi: [Fri May x xx:xx:xxx 2024] wiki.cgi: /home/home/hoge//diff/XXXXXXXXXXXXXXXXXXXX.txt cannot be created at Yuki/YukiWikiDB.pm line 84., referer:(略)

等，大体同じようなアクセス制御系のエラーが表示されました。

httpdのコンフィグやファイル，ディレクトリのアクセス権限等，いろいろあたってみましたが，全然解決せず，途中でFedoraフォーラムに問い合わせてみましたが，書いたあとにたまたまsystemdでhttpdのファイル制御している記事（Webuzo:「How to increase the number of open files allowed for Apache2」）を見つけて，自己解決できました。

理由は，どうやら，systemdの制御のコンフィグが変わったのが原因のようでした。解決の方法としては，

vim /usr/lib/systemd/system/httpd.service

以下追記
DeviceAllow=/dev/ttyS0 rw

ProtectHome=read-only
PrivateDevices=yes
↓
ProtectHome=false
PrivateDevices=no
に変更

のちに，

sudo systemctl daemon-reload
sudo systemctl restart httpd

を実行したらうまくいきました。/homeディレクトリと/devをsystemdでアクセスを制限していたようです。無事Fedora40でもefaxサーバーの運用ができるようになりました。
（”PrivateDevices=yes”と” sudo systemctl restart httpd”は，5/11追記 ）

Linuxサーバーのディストリビューションのひとつである，Fedoraが40にアップグレードされました。

アップデート方法は，今までとあまり変わりないようです。
（参考：Fedora Documentation “Upgrading Fedora Linux Using DNF System Plugin“）

FedoraはRed Hat Linux9(RHL9)から派生したディストーションですが，RHL9からファイルサーバー等に利用しています。司法書士業務での利用は，Fedora20から開始しており，セキュリティを考慮し，この時期からアップグレード毎に更新をしています。

Fedoraは，ほぼ半年に１回は更新されており，Linuxの中でも先進的な技術を利用することができる反面，更新されたパッケージが成熟していない場合もあり，バグ対応や自身のメンテナンスを必要とする場合が多いです。

オンラインの登記申請，書類作成等は，当然Windowsのパソコンを利用しますが，データの保存やバックアップ，履歴保存，クラウド利用のみならず，データベースやFax，プリントサーバー，内線通話にも利用しているため，Fedoraサーバーも欠かせない存在となっています。

利用頻度が高いため，将来的には安定版のCentOSやRed Hat Enterprise Linux(RHEL)への移行も考えなければならないところですが，踏み切れていないのが現状です。

今まで，当ホームページのフォームはBASHのCGIを使っていましたが，せっかくWordpressでもフォームが利用可能なので，Wordpressの利用に変更しました。

ですが，フォームは手軽に連絡ができるため，利用しやすいのですが，不具合が多いため，お問合せフォームをしたのに連絡が行かないという方は，お電話にてお問い合わせいただくようお願いします。

半年に一度の単位で行われる，Fedoraディストーションがメジャーアップデートしたようなので，業務サーバーのバージョンをアップしました。

方法は，

dnf system-upgrade download --releasever=39
dnf system-upgrade reboot

これのみでした。

ログイン中

● device has a firmware upgrade available.
Run `fwupdmgr get-upgrades` for more information.

が出るようになりました。サーバー機のＳＳＤのファームウェア（ＵＥＦＩ，ブートローダー部分）のアップデートの必要性を検出するようになりました。

具体的なアップデート方法は，

fwupdmgr update

ブートローダーは，ＯＳを起動するための前段階のプログラム（ＳＳＤやハードディスクの最初の方に書かれている）ものです。ＷｉｎｄｏｗｓなどのＯＳ上ではアップデートするようなものではなさそうですが，前からＦｅｄｏｒａではアップデートできるようになっているようでした。

iOSやiPadOSのOpenVPNですが，バージョンを3.4.0以上にした場合，tls-clientやpushのオプションが使えなくなるため，これらのオプションを変更する必要があります。

iPhone側の*.ovpnで

tls-client → client

サーバー側の*.ovpnで

tls-serverを消去

OpenVPNはアップデートすると，設定ファイルによっては突如として利用できなくなり，書き換えが必要となるため，注意が必要です。

Fedoraディストーションがメジャーアップデートしたようなので，業務サーバーのバージョンをアップしました。

方法は，

dnf system-upgrade download --releasever=38
dnf system-upgrade reboot

これだけでした。

アップデートした後，業務で使用しているNextcloudが，PHPのバージョンチェックに引っかかってしまうので，「/usr/share/nextcloud/lib/versioncheck.php」にある

if (PHP_VERSION_ID >= 8xxxx) {
http_response_code(500);
echo ‘This version of Nextcloud is not compatible with > PHP 8.0.
‘;
echo ‘You are currently running ‘ . PHP_VERSION . ‘.’;
exit(-1);
}

を”/*”と”*/”でコメントアウトしました。

PHPのバージョンはそのままでも問題なくNextcloudは起動できました。

弊所のサーバーについて，Fedora36→37にアップデートしました。

Linuxサーバーを運用していると，新しいソフトウェアでバグ等により，急な対応や調整が必要になる場合があります。

ときには痛い目にあうことがありますが，大きな修正や対応を行いながらも，１０年以上運用しています。

今回のアップデートには特に障害や特別な対応はありませんでした。

Ｇｍａｉｌを外のサーバーから使う際，ＳＰＦレコードの登録が必要になったようです。

弊所利用のプロバイダにおいても，送信メール対策やメールのＳＳＬ化をしたようで，スパムメールを防ぐため，セキュリティが向上しています。

セキュリティ向上は好ましいのですが，業務サーバーからＧｍａｉｌやＹＡＨＯＯメール等に通知する場合，スマートフォンに転送する場合には，そのセキュリティが送信の邪魔をして，とても苦労します。

Ｇｍａｉｌにおいても，セキュリティが高くなり，安易に転送できなくなりました。弊所も転送機能で，フォームを受け入れたり，通知を受けたりしています。

対策として，ＤＮＳにＳＰＦレコードを登録します。
（参考：ｇｏｏｇｌｅ　「SPF レコードを定義する: 詳細設定」）

v=spf1 include:_spf.google.com -all

さらにチェックが必要で。以下のサイトでチェックします。
Google Admin Toolbox Check MX

これで，ようやくＰｏｓｔｆｉｘからメールの転送ができるようになりました。