自宅鯖 RHEL10 まとめ
rio自宅鯖をRHEL8からRHEL10に移行した話は、単にOSを入れ替えたというより、ハードウェア、10Gbpsネットワーク、DNS/DHCP、メール、WordPress、Dify、RAG、IT News、監視、バックアップ、セキュリティ検証まで含めた、拙宅インフラ全体の再構成になった。
関連する記事が増えてきたので、ここでは読む順番と、移行プロジェクト側の実装場所を整理しておく。細かい手順は個別記事に任せ、このページは全体像を辿るためのリファレンスにする。
全体像
現在の自宅鯖は、RHEL10上でホストネイティブなDNS/DHCP/メール系サービスを動かしつつ、WordPress、Dify、ownCloud、監視などのアプリケーションはPodman Quadletで管理している。HTTP/HTTPSの入口はTraefikで、WordPressやDifyなどの背後に振り分ける。
移行の中心になった記事は自宅鯖のRHEL8をRHEL10にAIエージェントで移行した。旧構成、移行方針、AIエージェントを使ったアセスメント、to-beモデル、Ansible Playbook化、検証作業までをまとめている。
| 層 | 主な役割 | プロジェクト側の実装 | 関連する記事 |
|---|---|---|---|
| ハードウェア | CPU、メモリ、SSD、10G NIC | plans、ベンチマーク記事、運用メモ | パーツ発注、CPU、SSD |
| ネットワーク | 10Gbps LAN、IPv4/IPv6、経路、DNS配布 | ansible-playbooks/infra/network、baremetal/kea、baremetal/unbound、baremetal/knot | ネットワーク図、iperf、Kea、NetworkManager |
| OS基盤 | RHEL10、systemd、tuned、kernel/sysctl | ansible-playbooks/infra/*、verify-ansible-playbook | RHEL10移行、チューニング結果 |
| コンテナ基盤 | Podman Quadlet、Traefik、WordPress、Dify等 | ansible-playbooks/infra/podman-quadlet | Quadlet化した |
| アプリケーション | rio.st、RAG検索、Dify、IT News | wp_news_clawler、wp-rio-st関連スクリプト、Dify/WordPress stack | WordPressにRAG、IT NEWS |
| 運用 | DMARC解析、OpenVAS、イメージ更新確認、バックアップ | ansible-playbooks/operations/*、baremetal/restic | DMARC、OpenVAS、各種運用記事 |
ハードウェア
新サーバは、RHEL10で作り直す前提で2025年7月にパーツを発注した。新・自宅鯖のパーツを発注したでは、Core Ultra 7 265、メモリ、Gen5/Gen4 SSD、10G NICなどの選定を書いている。
CPUについては自宅鯖のCPUが速いで旧旧・旧・新の差を確認した。Podmanで多数のコンテナを動かし、GPUなしでも軽いAI処理を試す前提なので、CPUとメモリは強めにしている。
SSDは自宅鯖のSSDでベースラインを取った。今後のチューニングや劣化確認のためにも、最初に基準値を残しておくのは大事。
ネットワーク
物理構成の出発点は自宅新ネットワーク図。QNAP、TP-Link、Netgearの10Gスイッチを使い、自宅内の10Gbps LANを組んでいる。
実測値はiperfで速度を測っておくにまとめた。MacStudioからTP-Link、QNAPを経由して自宅鯖までの経路で測り、sysctlやethtool側の設定値も残している。
RHEL10移行後に一番厄介だったのは、NetworkManagerとAQC107まわりのデフォルトルート問題。プロジェクト側では ansible-playbooks/infra/network に、デフォルトルートを確認して欠けていれば戻す ensure-default-route 系のsystemd timerを置いた。根本修正ではないが、運用上の回復性を上げるための暫定策。
DHCPはkeaにどハマりした件。Kea DHCPv4/DHCPv6、Unbound、HGWのRA、Zen WiFiが絡むと、問題が単純な「DHCPが動かない」では済まない。プロジェクト側では ansible-playbooks/baremetal/kea に、Keaの設定、検証、段階的cutoverの考え方を整理している。
メールとDNS
自宅鯖はDNSとメールも担っている。DNSはKnot/Unbound、メールはPostfix/Dovecot/Rspamdなどを、ホストネイティブなサービスとして管理する。コンテナに寄せないのは、DNS/DHCP/メールはホストやネットワークと密接に絡むため。
so-netのOB25B対応では、auひかりホーム10G + so-net環境でのSPF見直しについて書いた。自宅でメールを送るなら、SPF/DKIM/DMARCはもう趣味の追加設定ではなく、普通に必要な運用要件になっている。
その延長で、DMARCレポートをAIに解析させるを書いた。プロジェクト側の ansible-playbooks/operations/dmarc-report は、日次でDMARC aggregate reportを解析し、修正要否をメールで返すサービスとして管理している。
RHEL10とAnsible
プロジェクトは、移行作業のメモというより、現在の自宅鯖の構成管理リポジトリになっている。大きくは次のように分かれる。
| ディレクトリ | 役割 | 例 |
|---|---|---|
| ansible-playbooks/baremetal | ホストネイティブなサービス | chrony、postfix、dovecot、rspamd、knot、unbound、kea、restic |
| ansible-playbooks/infra | OS基盤と共通インフラ | network、kernel-tuning、tuned-profile、podman-quadlet、users、certificates |
| ansible-playbooks/operations | 運用ジョブと監査 | dmarc-report、hardening、image-tag-scanner、image-update-check |
| verify-ansible-playbook | 検証、idempotence、テストホスト比較 | 構成差分、playbook matrix、public surface比較 |
| wp_news_clawler | IT News用WordPressプラグイン | RSS収集、embedding、クラスタリング、要約、ショートコード |
RHEL10移行時には、AIエージェントに旧サーバのアセスメント、to-beモデル作成、サービス単位のAnsible Playbook化、検証項目の整理をかなり手伝わせた。ただし、AIエージェントに任せれば終わるわけではなく、公式ドキュメントを見る、サービス間の依存関係をまとめる、新旧サーバを取り違えない、といった運用ルールが重要だった。
Quadletとコンテナ
当初はPodman Composeを使っていたが、最終的にはQuadlet化した。理由は単純で、systemdとの親和性が高く、sliceや依存関係、起動順、運用単位を素直に扱えるから。
現在の実装上の中心は ansible-playbooks/infra/podman-quadlet。ここで wp-rio-st、dify、owncloud、traefik、observability、infinity、umami などのスタックをレンダリングする。古い quadlet-managed 配下は、かなりの部分がretired-safeな参照・退避先になっている。
WordPressは wp-rio-st スタックとして動き、Nginx、WordPress/PHP、MariaDB、Valkeyなどを含む。Difyは別スタックだが、RAGやワークフロー実験でWordPress側から参照される。
WordPress、RAG、Dify
rio.stは単なるブログではなく、WordPress上にいくつかの実験機能が載っている。WordPressにRAGを簡単に導入するでは、DifyバックエンドのRAG検索から、MariaDBのベクトルサポートを使うWordPressプラグインへ考え方を移している。
初期のWP RAG SearchはDifyに依存していたが、別スタック依存やチューニングパラメータの多さが運用上の重さになった。そのため、より単純なWP Retrieverとして、WordPress内で完結しやすい方向に寄せた。
このあたりの運用補助スクリプトは scripts/wp_rag_*.php や scripts/deploy_plugin.sh に残っている。DifyやInfinity rerankerなどの実体は、Quadletスタック側で管理される。
IT News
IT NEWS は、WordPressプラグイン wp_news_clawler で実装している。RSS/RDF/Atomを収集し、英語記事を日本語化し、embeddingを保存し、類似度でクラスタリングし、OpenAI Responses APIで日本語タイトルと短い概要を生成する。
固定ページ側は wpan_news limit="100" のショートコードで表示する。収集はWordPressのwp-cronではなく、wp-rio-st コンテナ内で wp wpan collect をsystemd timerから実行する想定にしている。これは、WordPressの画面表示と重い収集・正規化処理を分けたいから。
検証とセキュリティ
OpenVASでスキャンしてみるでは、外部露出を確認する話を書いた。プロジェクト側では ansible-playbooks/operations/hardening に、OpenSCAP/OpenVASの結果を踏まえたremediation planを置いている。
このホストはSSH、HTTPS、SMTP、Submission、SMTPS、IMAP、IMAPS、DNSなどを意図的に提供するので、一般的なベンチマークに対して「閉じればよい」とはならない。必要な公開面は例外として明記し、SSH、sudo、fail2ban、firewalld、sysctl、AIDEなどは役割に合わせて硬くする。
Playbookの検証は verify-ansible-playbook にまとめている。idempotence matrixでは、baremetal、infra、operations、podman-quadletなどを、check-first、clean-on-test、retired-safeといった分類で管理している。
チューニングと運用監視
チューニング結果では、Headless Chrome + Lightningでrio.stを測った結果を残している。プロジェクト側では ansible-playbooks/infra/tuned-profile、infra/kernel-tuning、infra/cgroup-slice などが土台になる。
コンテナイメージの運用では、同じtagのdigest driftを見る image-update-check と、新しいtagが出ているかを見る image-tag-scanner を分けている。どちらもreport-onlyで、自動更新ではなく、最終判断はoperator側に残す。
ドキュメント化
構成が大きくなると、ブログ記事だけではなく、配布用・整理用の文書も欲しくなる。OverleafでSoftware Design風レイアウトを作るは、その延長にある。AIエージェントにOverleafを立てさせ、Software Design風の誌面レイアウトを作らせた。
自宅鯖の話は、日々の作業メモとしてはブログでよいが、全体像や手順書、運用設計はPDFや同人誌の形にした方が読みやすい。プロジェクト側のREADME群と、このページのようなインデックス記事の両方が必要になる。
読む順番
初めて読むなら、以下の順が分かりやすい。
| 順番 | 読むもの | 分かること |
|---|---|---|
| 1 | RHEL8をRHEL10にAIエージェントで移行 | 全体構成と移行方針 |
| 2 | 新・自宅鯖のパーツを発注 | ハードウェアの前提 |
| 3 | 自宅新ネットワーク図、iperf | 10Gbps LANと実測 |
| 4 | Kea、NetworkManager問題 | ネットワーク運用で詰まったところ |
| 5 | Quadlet化した | コンテナ運用の現在形 |
| 6 | WordPressにRAG、IT NEWS | アプリケーション層の実験 |
| 7 | OpenVAS、DMARC解析 | 運用とセキュリティ |
