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

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


試行錯誤と対策

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

  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の有効化手順

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

grubby –update-kernel ALL –remove-args selinux

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

vi /etc/selinux/config
SELINUX=enforcing

SELINUX=permissive

予期せぬリブートの問題

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

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

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

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

/sbin/fixfiles -f -F relabel
reboot

3.再起動後の確認
正常に起動できることを確認し,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にアップグレード」)

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

dnf –refresh upgrade

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

2.システムアップグレードの準備

dnf system-upgrade download –releasever=41

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

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

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に設定する場合は以下の手順を行います。

1.デフォルトゾーンをinternalに設定

firewall-cmd –set-default-zone=internal

2.マスカレードと転送を有効化

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

3.インターフェースをinternalゾーンに追加

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

4.設定のリロード

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サーバーとは物理的かつ回線的に分離したメインサーバーに保存されています。これにより,公開サーバーからのアクセスリスクを排除し,セキュリティを徹底しています。

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

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

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