タグ: Fedora

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の設定はかなり難しいと感じていますが，今後いつか設定方法をご報告できたらと思います。



Linux(Fedora)サーバーでVPN利用時のVoipとNAT変換の動作

Fedoraサーバーへのセキュリティ向上のため、ファイアウォール設定を従来のiptablesからFirewalldへ移行しましたが、移行後に内線電話で利用しているSIPサーバーが正常に動作しない事態が発生しました。このようなケースにおける検証結果と解決策についてご紹介します。

SIPサーバーは以下のとおりで使っています。

業務ネットワークイメージ

問題の発生状況

Fedoraサーバー上では，SIPサーバーを通じて業務ネットワーク内のWiFi接続（192.168.0.xおよび192.168.1.x）でSIPクライアントを利用しています。SIPクライアント（iphoneアプリ）として使用しているのはAGEPhoneで，VPN経由で接続しています。

移行後，SIPクライアントが「403 Forbidden」エラーを返し，通信ができなくなっていることが判明しました。
パケットキャプチャを使用して詳細を調べたところ，IPマスカレード（NAT変換）の動作により，SIPプロトコルが正しく機能しなくなっていたことがわかりました。

検証結果と原因

以下のように，Firewalldによる設定ではVPNのホスト名に変換され，SIPサーバーが要求するIPアドレス認証に一致しないため，403エラーが発生していました。

すると，iptablesでは，ipアドレスでSIPサーバーにアクセスしていましたが，Firewalldでは，NAT変換されてしました。（「tcpdump host 192.168.0.3」で検証）

iptablesの設定：

192.168.1.x > 192.168.0.3 (SIPのIPアドレスで通信)

Firewalldの設定（IPマスカレード設定時）：

vpn.example.com > 192.168.0.3 (ホスト名に変換され通信不可)

この問題の原因は，SIPが発信元IPアドレスの一貫性を必要とする仕様により，NAT変換されたアドレスを受け入れないことにありました。

解決策

Firewalldの設定を見直し，IPマスカレード（NAT変換）を解除することで，SIPサーバーが元のIPアドレスで通信できるようにしました。具体的には，以下のコマンドを使用しました。

firewall-cmd --zone=internal --remove-masquerade --permanent
firewall-cmd --reload

この設定変更により，異なるローカルネットワークでも直接IPアドレスがやり取りされ、SIP通信が可能になりました。パケットキャプチャ上でも発信元のIPアドレスが確認できるようになりますが、SIPの仕様に従うための対応です。

SIPとNAT変換のドキュメントがなかなかありませんでしたが，学会論文誌に掲載がありました。
【情報処理学会論文誌：「ファイアウォールや NAT を通過できる IP 電話の提案と評価」　伊藤将志氏， 鹿間敏弘氏，渡邊晃氏】

他のサービスでの影響

SIPサーバー以外のサービス（Samba，Web，RDP，Ping，SSH等）は，IPマスカレードを使っていても問題なく動作しているため，通常はマスカレードを導入したほうが利便性が向上します。しかし，SIPサーバーを使用する場合は，IPマスカレード解除の設定を行うことが推奨されます。

まとめ

SIPサーバーの設定には，ファイアウォールの詳細設定が関わってきます。Firewalldに移行した際には，各サービスごとの通信要件を確認し，必要に応じてマスカレードの有無を調整することが重要なようです。今後も，安全かつ効率的なネットワーク運用を目指して設定の改善に取り組んでまいります。

Fedora40→41にアップグレード

当社では，安定性とセキュリティの向上を目的として，メインサーバーにLinuxディストリビューションのFedoraを採用しております。この度，Fedoraの最新バージョンへのアップデートを無事完了しましたので，報告いたします。

アップデートの手順

Fedoraのアップデートは，以下の手順に従って実施しました。これにより，システムの最新機能とセキュリティパッチを適用し，サーバーのパフォーマンスを最適化しています。
（参考 ninjav8氏アメーバブログ「Fedora Linux 40からFedora Linux 41にアップグレード」）

１．パッケージリストの更新とシステムのアップグレード

dnf --refresh upgrade

このコマンドにより，最新のパッケージ情報を取得し，既存のパッケージを最新バージョンに更新します。

２．システムアップグレードの準備

dnf system-upgrade download --releasever=41

Fedoraの次期リリースバージョン（ここではバージョン41）へのアップグレードをダウンロードします。

３．システムの再起動とアップグレードの適用

dnf system-upgrade reboot

サーバーを再起動し，ダウンロードしたアップグレードパッケージを適用します。

アップデート後の確認

アップデートが完了した後，以下のコマンドでシステムのバージョンを確認し，正常にアップグレードされたことを確認しました。

uname -a

アップデート時の注意点

Fedora 39から40へのアップデートと比較すると，特に注意点はありませんが，のアップデートでは以下の点に注意が必要です。

  • 手動での修正
    自動アップデートでは対応できない設定ファイルの調整が必要となる場合があります。特にカスタマイズされたアプリケーション（efaxやNextcloud等）の設定については，アップデート後に手動で修正を行うことがあります。
  • 互換性の確認
    特定のサービス(phpやperl等)やアプリケーションが新しいバージョンと互換性を持つかどうかをできるだけ事前に確認したほうがいいです。問題が発生した場合には，迅速に対応できるよう準備を整えていく必要があります。

今後の展望

今回のアップデートにより，サーバーの安定性とセキュリティが向上し，業務の効率化が期待されます。今後も定期的なシステムアップデートを実施し，最新の技術を取り入れることで，より安全で信頼性の高いサービスを提供してまいります。

また，アップデートに伴う設定変更やトラブルシューティングに関する情報を随時共有し，Linux等のサーバー構築に関するドキュメント公開の活発化に資することを目指します。

Linux(Fedora)サーバーでVPN利用時のfirewalld設定

最近，LinuxでVPNを利用する際のfirewalld設定に関する情報が少ないことから，独自に検証を行い設定方法をまとめました。特に，異なるネットワーク間で双方向に接続する構成のドキュメントが見当たらなかったため，以下に紹介します。

ネットワーク構成

以下の構成図で，LinuxサーバーをVPNゲートウェイとして複数ネットワークを接続します。

client(0.x)--rt(192.168.0.1)==grobal==rt(192.168.1.1)--client(1.x)
  server(0.2)↑eth0                                      ↑server(1.2)
          ↑----------------------VPN-------------------------↑
 192.168.2.1(eth1)                                    192.168.2.2

この構成で「双方向」に通信する場合には，VPN(OpenVPNなど)によって共通のネットワークエリアを形成し、server(0.2)側でfirewalldのゾーン設定を行う必要があります。

firewalld設定

VPN接続で別ネットワークを双方向に接続するため，server(0.2)側の設定では192.168.0.xのネットワークと192.168.2.xのネットワークを同じゾーンに設定します。例えば、ゾーンをinternalに設定する場合は以下の手順を行います。

１．デフォルトゾーンをinternalに設定

firewall-cmd –set-default-zone=internal

２．マスカレードと転送を有効化

firewall-cmd –zone=internal –add-masquerade –permanent
firewall-cmd –zone=internal –add-forward –permanent

３．インターフェースをinternalゾーンに追加

firewall-cmd –permanent –zone=internal –add-interface=eth1

４．設定のリロード

firewall-cmd –reload

同じゾーンにしないと片方からの通信のみ可能となってしまうことから，ゾーンは必ず同一にする必要があるようです。

ダイレクトルールの注意点

検証の結果，ダイレクトルール（firewall-cmd --permanent --direct）を用いると，予期しない挙動が生じ、通信が途絶えることがありました。確実な通信を目指す場合、ダイレクトルールの使用は避け，ゾーン設定を活用する方法をおすすめします。

この方法が皆様の環境構築の一助になれば幸いです。今後もこのような検証結果をもとに，最適な設定方法を紹介してまいります。

新しいサーバースペックとデータ保護の取り組み

当所では，効率的なデータ管理と高い信頼性を提供するため，メインサーバーのスペックを最新化しました。過去のクライアントPCをベースにしたこのサーバーは，SambaとNextcloudを中心としたファイルサーバー兼クラウドファイルサーバーとして稼働しています。

サーバースペック

  • OS：Fedora 40
  • CPU：Core i5-9400 (2.9GHz)
  • メモリ：40GB（16GB×2 + 4GB×2）
  • ストレージ：M.2 SSD 2TB

このスペックにより，安定したパフォーマンスとデータ処理の迅速化を実現しています。

データセキュリティと分離設計

登記データなどの重要情報は，公開されているWordPressサーバーとは物理的かつ回線的に分離したメインサーバーに保存されています。これにより，公開サーバーからのアクセスリスクを排除し，セキュリティを徹底しています。

データの多重化と完全削除の方針

ストレージの二重化は行っていませんが，データ保存の多重化を採用し，物理的な破損や誤削除が発生しても，重要な情報が簡単には失われない体制を整えています。
また，削除するデータは完全削除を行い，個人情報保護方針に基づいた運用を徹底しています。

今後もこのような取り組みを通じ，信頼性の高いサービスを提供し続けてまいります。