タグ: Fedora

Fedora45のリリースとアップデート

Fedora 45は、PHPの脆弱性（CVE-2026-109618、CVE-2026-109619：PHP2shell、 参考：情報処理推進機構「PHPの脆弱性対策について」）の影響か、あるいはLinuxカーネルのTCPの脆弱性（CVE-2026-98432 参考：piyolog「Linuxカーネルの脆弱性 CVE-2026-98432 についてまとめてみた」）の影響かはわかりませんが、リリースのスケジュールが延期となっていました。
先日ようやくリリースされたため、メインサーバーとサブサーバーをFedora 45にアップデートしました。

方法は以下のとおりです。

まずは、Fedora 44で最終アップデートを行い、必要に応じて（カーネルのアップデートがある場合などは）再起動します。

dnf upgrade --refresh -y
reboot -n

次に、Fedora 45をダウンロードして、PGPを確認します。

dnf system-upgrade download --releasever=45

PGPは以下のサイトで確認します。 「Fedora Keeps You Safe」

そして、アップデートを実行します。

dnf5 offline reboot

アップデート後の状況として、WordPressのバージョンが6.9系から7.1系に変更されたため、データベースのアップデートが行われました。
Nextcloudに関しては特に変化はありませんでした（通常のアップデートと同じ作業です）。

また、アップデート後に不具合が発生しました。Webログ管理ツールの「awstats」がFedora 44用のままになっていたため、Fedora 45のSELinuxポリシーとの間で不整合が生じたことです。

状況を確認すると、以下の通りパッケージがfc44のままでした。

dnf list --installed awstats
# 出力結果：awstats.noarch 8.x-x.fc44 updates

この対処として、エラーが出た後に手動でポリシーモジュールを作成し、インストールしました。

sudo ausearch -m AVC -c awstats.pl -ts today | audit2allow -M awstats_local
sudo semodule -i awstats_local.pp

インストール後、以下のコマンドでポリシーが適用されたか確認します。

sudo semodule -l | grep awstats_local

運用していく中で、他に何かあれば、その都度対応して情報を共有する予定です。

PHPの大騒動とFedoraでのアップデート

世間的には令和8年10月21日午後11時の段階で、外部サーバー類のWebを使ったプログラムとして多く利用されているPHPの緊急メンテナンスをするよう告知がありました。
（参考：piyolog「PHPの2件の深刻な脆弱性(CVE-2026-109618、CVE-2026-109619)についてまとめてみた」）

FedoraでWordpressを利用している当サーバーもPHPのアップデートが必要となり、緊急メンテナンスを実施。

公式のリポジトリでは、PHPのアップデートが間に合わないため、Koji（ビルドパッケージ）からダウンロードしました。以下はその手順です。

１． Kojiをインストール

dnf install koji

2. RPMを取得

mkdir -p ~/php-8.5.12
cd ~/php-8.5.12
koji download-build --arch=x86_64 php-8.5.12-1.fc44

3. 取得したRPMを確認

ls -lh *.rpm

4. 更新内容を事前確認

dnf upgrade ./*.rpm --assumeno

問題がなければ、次へ進みます。

5. PHPを更新

dnf upgrade ./*.rpm

6. PHPのバージョンを確認

php -v
rpm -q php php-common php-cli php-fpm

PHPが「8.5.12-1.fc44」 になっていれば完了です。

追記、令和8年10月23日現在で、dnfによる公式のリポジトリでアップデートできるようになっています。

Sambaサーバーの遅延対策とRsyncによるバックアップの改善

Sambaは、WindowsとLinuxのファイルシステムをつなぐ重要なサーバー機能ですが、最近、一部のSambaサーバーで遅延が発生し、Windows端末での操作に支障が出ることがありました。

Sambaのアップデートでは、古いSMBプロトコルや認証方式の扱いが変更されることがあります。事務所では、古いスキャナーやプリンターなどを接続していることもあり、設定変更には慎重になります。

今回、実際に発生した問題について、２点変更したところ改善しました。

１．Rsyncのパーミッションエラー

Windowsにはrobocopyがありますが、差分バックアップではRsyncも比較的高速で便利です。当事務所では、RsyncとFedoraサーバーへのSSH接続のためにCygwinを利用しています。

Rsyncでは、

rsync --delete -t -v -r --perms /cygdrive/c/path //Sambaserver/backup-path

としていましたが、Sambaサーバー側でパーミッションのエラーが発生しました。

そこで、

--perms

を

--no-perms

に変更したところ、正常にバックアップできるようになりました。

--permsは転送元のパーミッションを転送先にも設定するオプションです。バックアップ先でパーミッションを再現する必要がなければ、--no-permsで問題ありません。

  1. 不要なサーバーではNT1を無効にする

古い機器との互換性のため、SambaでSMB1（NT1）を許可している場合があります。

今回、古い機器と接続する必要のないSambaサーバーについて、

;server min protocol = NT1
;ntlm auth = yes

として、これらの設定を無効にしました。

その結果、Windows端末からSambaサーバー上のテキストファイルを開く際などに発生していた遅延が改善しました。

ただし、古いスキャナー、プリンター、スマートフォンなどが接続されている場合は注意が必要です。設定変更後に、それらの機器からSambaサーバーを利用できるか確認した方が安全です。

今回、

  • Rsyncの--permsを--no-permsに変更
  • 不要なSambaサーバーでSMB1（NT1）を無効化

したところ、バックアップが正常に動作し、Windows端末からのファイル操作も改善しました。

古い機器との互換性が必要な環境では無理に設定を変更する必要はありませんが、必要のないサーバーまで古いプロトコルを有効にしておく必要もありません。
接続する機器に応じて、設定を分けておくことが重要だと思います。

セキュリティ対策として SPF・DMARC を導入

いわゆる電子メールの仕組みは，昔ながらの POP3 や SMTP というプロトコルの上に成り立っています。
とても便利な一方で，セキュリティ面ではどうしても古い部分が残っており，大量送信が容易なことから，不正な攻撃に悪用されてしまうことがあるようです。

最近では，認証情報を狙った不審メールを大量に送り続けるタイプの攻撃が増えているとの報道もあります。
（参考：日本経済新聞「世界の不審メール7億通、8割は日本標的」）

こうした状況を受けて，特に Gmail や携帯キャリアのメールでは強力なフィルタが導入されています。
しかしながら，仕組みの詳細が公開されているわけではなく，システム管理者にとっては「どこで弾かれているのか分からない」状況になることも多いのが実情です。

Gmail では，SPF レコードや DKIM，DMARC といった認証技術の導入を強く推奨しているようです。
（参考：Google「認証方法について（管理者向け）メール認証の基本を学ぶ」）

当事務所でも，外部への送信メールを一部システムで利用していることから，今回は SPF レコードと DMARC の設定を行いました。

参考にしたのは次のサイトです。

設定後，オープン側のサーバー（基幹サーバーではありません）から送信したメールについて，SPF も DMARC も「PASS」と判定されるようになりました。これにより，Gmail やスマホキャリア宛ての返信メールでも，これまでより安定して届くようになったと思います。

今後もセキュリティへの配慮を続けながら，メールシステムの安定運用に努めていきます。

↓設定実施前のgmailのメールソース

↓設定実施後のgmailのメールソース

Fedora42→Fedora43

２０２５年１０月２８日に Fedora 43 がリリースされたため，メインサーバー（クローズド環境）を早速アップデートしました。

手順は次のとおりです。

#事前準備
dnf upgrade --refresh
reboot -n

#ダウンロード
dnf system-upgrade download --releasever=43 --allowerasing
#(Fingerprintを確認)

#アップグレード実行
dnf system-upgrade reboot

アップグレード後，いつもどおり eFAX サーバーと Nextcloud の設定を再投入する必要がありましたが，
今回は dovecot（IMAP メール受信サーバー）で問題が発生しました。

dovecot が 2.3 から 2.4 にバージョンアップしたことにより，設定記述の方式が一部変更されています。
特に メールのパス指定 が変更されており，元の設定に戻す必要があります。

vi /etc/dovecot/dovecot.conf
mail_path = ~/mail
↓
本来のメールパス

また，「/etc/dovecot/conf.d」以下の 「10-mail.conf」 などの設定ファイルが削除または無効化されていました。
そのため，必要に応じて設定を再作成・再有効化する必要があります。
再作成する場合には，記述方法がver2.3とは異なっているので注意が必要です。
（参考　Dovecot CE「Upgrading Dovecot CE from 2.3 to 2.4」）

テキスト処理で一行目だけエラー？──原因は「BOM付きUTF-8」でした

先日，あるテキストファイルを使ってコマンド処理をしようとしたところ，一行目だけがどうしてもエラーになってしまうという現象に直面しました。

リストファイルの各行をもとにコマンドを生成し，コピペで実行しても一行目だけが動かない。
不思議に思い，最終的には一文字ずつ文字コードを調査して原因を特定するに至りました。

原因は「FEFF」──UTF-8のBOM

調査の結果，一行目の先頭に「FEFF」という不可視の文字コード（BOM: Byte Order Mark）が入っていることがわかりました。
この「FEFF」は，UTF-8でBOMありとして保存されたファイルの先頭に付く特殊なコードで，Linux系OS（Fedoraなど）では扱いに注意が必要です。

なぜBOMが入っていたのか？

使用していたクラウドソフトが，スマホ表示に対応するため標準でBOM付きUTF-8形式でテキストを記憶しなければならない仕様になっていたため，Windows側のテキストアプリケーションの設定で「BOMあり」ファイルを作ってしまっていたからです。

その結果，テキスト処理スクリプトやシェルコマンドなどが，一行目を正しく認識できなくなっていたというわけです。

対処法と今後の教訓

テキストエディタで保存形式を確認

・UTF-8（BOMなし）で保存できるようにエディタの設定を見直す

最後に

一見ただの文字列ファイルでも，見えないバイト列が処理を妨げていることがあるという良い教訓になりました。
今後も，テキスト処理を行う際には，BOMの有無や文字コードの確認を忘れずに対応していきたいと思います。

同じように「なぜか1行目だけエラーになる」などの不可解な現象でお悩みの方がいれば，ぜひBOM付きファイルでないか確認してみてください。

Fedora41→42 のリリースとアップグレード

昨日，Fedora42が正式リリースされたようでしたので（参考 fedora MAGAGINE　「What’s New in Fedora Workstation 42」），メインサーバー等をFedora41から42にアップデートしました。
方法は以下のとおりです。

１．いつも通り，現状バージョンの最終アップデート

dnf upgrade --refresh
reboot -n

２．DNFアップグレードパッケージのインストール

dnf install dnf-plugin-system-upgrade

３．Fedoraの新バージョンのダウンロード

dnf system-upgrade download --releasever=42

４．GPG キーを検証します。（識別子が下記サイトと同じかを確認します）ＯＫなら［ｙ］を入力してenterを押します。

場所：　Fedora はあなたの安全を守ります

OpenPGP キー ● をインポート中:
 UserID: "Fedora (42) <fedora-42-primary@fedoraproject.org>"
 識別子: ●
 提供元: file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-42-x86_64

Is this ok [y/N]: y

５．ダウンロード後，リブートして更新

dnf system-upgrade reboot

６．各パッケージの正常性を確認します

更新後，１点問題点がありました。postfixが起動していませんでした。よって以下の設定をしています。

#古いパッケージを消す
dnf install remove-retired-packages
remove-retired-packages 41

#コンフィグファイルの更新
dnf install rpmconf
rpmconf -a
#何回かenterを求められる

「/etc/postfix/mail.cf」などが更新されて，加工前のものが「main.cf.proto」に入れられます。

そして，postfixのサービスが停止しているため，改めてスタートさせます。

systemctl start postfix

メールの送信を確認します。

#メールの送信
mail root

以下のエラーが出るため，mtaを変更

s-nail: Cannot start /usr/sbin/sendmail: executable not found (adjust *mta* variable)
alternatives --config mta

再度 mail rootを実行時メール

#メールの送信
mail root

#メールの受信
#→メールクライアントを使用

※追記　postfixの起動だけではメールの送信ができませんでしたので，alternativesを追加しました。

WordPressのアップデートができない！？SELinuxによる書き込み制限

SELinux を運用しながら WordPress を更新する際に，FTP 接続情報の入力画面が表示される 問題についての解決策をまとめました。

問題の原因

SELinux により，WordPress のディレクトリ./wordpress に対して 書き込み権限が制限されている ため，WordPress が通常の 直接更新 を行えず、FTP 接続を求めてきます。

エラーログ（ausearch の出力）からも，httpd_sys_content_t のコンテキストでは 書き込みが許可されていない ことが確認できます。

type=AVC msg=audit(xxxxxxxxx.xxx:xxxxx): avc: denied { write } for pid=xxxx comm="php-fpm" name="wordpress" dev="dm-0" ino=xxxxxxxxx scontext=system_u:system_r:httpd_t:s0 tcontext=unconfined_u:object_r:httpd_sys_content_t:s0 tclass=dir permissive=0

解決策

① SELinux のコンテキストを一時的に変更

以下のコマンドで，WordPress のディレクトリに書き込み権限を付与 する。

sudo chcon -R -t httpd_sys_rw_content_t .(どこか)/wordpress/

この操作で，WordPress が更新ファイルをダウンロードし，直接適用できるようになります。

② WordPress の更新を実施

管理画面から WordPress の更新 を実行する。
FTP 接続画面が表示されずに，直接更新ができるようになります。

③ 更新後、元の SELinux コンテキストに戻す

更新完了後に、本来の SELinux の設定に戻す ことで、余計な書き込み権限を解除します。

sudo restorecon -R -v .(どこか)/wordpress

これにより，WordPress ディレクトリの SELinux コンテキストがデフォルトに戻り，セキュリティが保たれます。

④ 永続的に書き込みを許可する場合（オプション）

頻繁に WordPress を更新する場合は，SELinux の設定を変更して 永続的に書き込みを許可 することもできます。（セキュリティ的にはやや劣後します）

sudo semanage fcontext -a -t httpd_sys_rw_content_t ".(どこか)/
wordpress(/.*)?"
sudo restorecon -R -v .(どこか)/wordpress

まとめ

方法SELinux の設定更新後に戻す必要
chcon で一時的に変更httpd_sys_rw_content_t を適用必要（restorecon）
semanage fcontext で永続的に許可.(どこか)/wordpress/ のコンテキストを変更不要

どの方法が適切か？

🔹 厳格なセキュリティ管理が必要な場合
　✅ chcon を使って一時的に変更し，更新後 restorecon で戻す
🔹 他のアプリケーションの影響を最小限にしたい場合
　✅ semanage fcontext で .(どこか)/wordpress のみ書き込み許可

また，「setsebool -P httpd_unified 1」 を有効化する方法もあるようですが，セキュリティ的にさらに劣後することになります。これについては，他サイトを参照してください。（未検証）

これらの方法で，SELinux を有効に保ちつつ，WordPress の更新をスムーズに行えるようになるでしょう。

Fedoraサーバーでの頻発するリブートとjournalのエラーへの対処方法

最近，Fedora38からFedora41へとアップデートを行ったサーバーで，3～5時間に1回程度，勝手にリブートがかかるという問題が発生しました。この問題の原因を調査し，最終的に解決した方法について記録します。

問題の概要

はじめに，リブートのタイミングがcrontabで実行されるジョブの時間と一致していたため，定期実行されるプログラムが原因と考えました。しかし，問題を掘り下げるうちに，以下の状況が判明しました。

  1. SELinuxをPermissiveモードに設定すると，さらにリブート頻発時間が短くなる
  2. リブート直前のログが不完全で，途中で切れている（/var/log/messages）
  3. journalctl --verifyコマンドでジャーナルログの破損を検出

エラーログの確認

リブート直前のログは以下のように記録されていました：

Nov 14 06:40:11 server audit[1]: SERVICE_STOP pid=1 uid=0 auid=xxxx ses=xxxx msg='unit=user-runtime-dir@0 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Nov 14 06:40:11 server systemd[1]: Removed slice user-0.slice - User Slice of UID 0.
Nov 14 06:40:11 server systemd-logind[748]: Removed session 548.
Nov 5 15:13:30 server su[1540]: (to root) user on pts/0
Nov 5 15:19:00 server smbd[2128]: [2024/11/05 15:19:00.003114, 0] ../../source3/smbd/msdfs.c:97(parse_dfs_path_strict)

journalctl --verifyを実行すると，次のエラーが確認されました：

71ce810: Data object references invalid entry at 10598418
File corruption detected at /var/log/journal/xxxx/system.journal:274295040 (of 276824064 bytes, 99%).
FAIL: /var/log/journal/xxxx/system.journal (不正なメッセージです)
PASS: /var/log/journal/xxxx/user-1000.journal

どうやら，ジャーナルログが破損しており，これが原因でjournaldやrsyslogの動作に影響を与えている可能性が高いことがわかりました。

試行錯誤と対策

ログの破損を防ぐため，以下の対応を試みました。

  1. 過去のジャーナルログを削除
journalctl --rotate
journalctl --vacuum-time=1s
  1. ジャーナルログのサイズ制限
    /etc/systemd/journald.confを編集して以下の設定を追加：
SystemMaxUse=2G
SystemMaxFileSize=500M

設定変更後にサービスを再起動：

systemctl restart systemd-journald
  1. ハードウェア検査
    メモリーテスト（Memtest）やSSDのSMART情報をチェック（smartctl -x /dev/sda など）しましたが，特に異常はありませんでした。
  2. Fedoraの再インストール
    上記の対応を行っても，症状が改善されることはありませんでした。そのため，Fedoraを再インストールしました。再インストール後も同様の症状があり，解決しませんでした。

最終的な解決策：サーバー本体（メインボード）の交換

上記の対応を行っても，症状が改善されることはありませんでした。そのため、最終的にメインボードの交換をしました。サーバーの交換後，以下を確認しました：

  • journalctl --verifyでログ破損なし
  • リブートが発生しない

これにより，ハードウェア自体に何らかの故障があった可能性が高いと結論付けました。

再発防止のための設定

再インストール後は，以下のポイントを守ることで，再発を防ぐ体制を整えました。

  1. ジャーナルログの定期チェック
journalctl --verify
  1. バックアップの確保
    システムの変更前に設定ファイルや重要なデータをバックアップ
  2. ハードウェア診断の定期実施
    定期的にメモリやディスクの健全性を確認

まとめ

今回の問題では，サーバー本体の交換が最終的な解決策となりました。おそらく，SSDやメモリー以外のメインボード等のハードウェアが故障した可能性が高いと推測されます。同様の問題に遭遇した際には，まずジャーナルログの破損を疑い，ハードウェアの状態を慎重に確認することも視野に入れる必要がありそうです。

SELinuxのPermissiveの検証でサーバーにリブートし続ける症状が発生

FedoraサーバーでSELinuxを有効にした際の検証プロセスについて，以下の手順と注意点をまとめました。

SELinuxの有効化とモードの設定

内部サーバーのセキュリティ強化のため，SELinuxを有効にしてPermissiveモードでの検証を行いましたが，今回発生した不具合と対処方法を示します。

SELinuxの有効化手順

１．grubbyコマンドを使用してSELinuxを有効化
SELinuxを有効化したい場合，以下のコマンドを使用します。

grubby --update-kernel ALL --remove-args selinux

２．SELinuxのPermissiveモードへの切り替え
SELinuxを有効にしてもいきなりファイルアクセスが制限されないよう，Permissiveモードで動作検証します。これはSELinuxの設定ファイルを編集することで行います。

vi /etc/selinux/config
SELINUX=enforcing
↓
SELINUX=permissive

予期せぬリブートの問題

SELinuxの初回有効化時，ファイルの再ラベリングが自動的に行われるため，その影響でシステムがリブートを繰り返す現象が発生しました。ログによると，/dev 以下でのエラーや，一部の手動で作成したサービスがリブート時に問題を引き起こしていたようです。

対処方法：手動での再ラベリング

１．レスキューモードでの起動
ブートローダーのメニュー画面でレスキューモードの位置で「e」キーを押し，編集画面から「F10」でブートを開始します。

２．手動ラベリングの実行
root権限でログインし，次のコマンドを使って手動で再ラベリングを行います。

/sbin/fixfiles -f -F relabel
reboot

３．再起動後の確認
正常に起動できることを確認し，Permissiveモードでの検証を続けます。

結果と考察

手動の再ラベリングによって，Permissiveモードでのシステムの安定起動が確認できました。なお、手動で作成したサービスや/dev以下のファイルに起因するSELinux関連のエラーが発生する場合には，上記の再ラベリングの作業をする必要があると考えられます。

SELinuxの設定はかなり難しいと感じていますが，今後いつか設定方法をご報告できたらと思います。