DigiLoog

自宅サーバで運用しているProxmoxにスタティックルートを設定しようとしたら、
Web GUIから追加する方法が分からなかったのでメモ。
結論を先に書くと、Web GUIから追加する事は出来ずCLIで設定を直接弄る必要があった。

筆者のProxmox環境では、各NICでサーバインスタンスのトラフィックを出しつつ、
ホストサーバにも接続出来る様にする必要があった為、
物理NIC→ブリッジ→管理I/Fの様に仮想NICを構成している。

この状態でセグメント毎に戻り通信を分散出来るようにスタティックルートを書きたかったのだが、
画像の通りWeb GUIではゲートウェイ(デフォルトルート)しか設定出来なかった。
同じ事を考えている人は多いと思うので調べてみたら次のフォーラムがヒットした。

• Proxmox VE: Networking and Firewall > up ip route add is ignored

要約すると、”/etc/network/interfaces”にスタティックルートを直記するのが唯一の手段らしい。
筆者はmgmt1の”OVS IntPort”にプライベートIP宛のルーティングを切りたかったので次の様にした。

$ cat /etc/network/interfaces
auto mgmt1
iface mgmt1 inet static
    address 192.0.2.2/24
    post-up route add -net 10.0.0.0/8 gw 192.0.2.1
    post-up route add -net 172.16.0.0/12 gw 192.0.2.1
    post-up route add -net 192.168.0.0/16 gw 192.0.2.1
    ovs_type OVSIntPort
    ovs_bridge vmbr1

細かく設定するならpost-downとルーティング削除も追加すべきだが、
そこまで厳密な制御は今回いらなかったので設定しなかった。

………

2022年末頃のProxmox VE 7.2までは”route add”で動いていたのだが、
Proxmox VE 7.3でバグってしまったので下記に変更した。
何回か再起動もしてみたが問題なく適用出来ている。

$ cat /etc/network/interfaces
auto mgmt1
iface mgmt1 inet static
    address 192.0.2.2/24
    post-up ip route add 10.0.0.0/8 via 192.0.2.1 dev ${IFACE}
    post-up ip route add 172.16.0.0/12 via 192.0.2.1 dev ${IFACE}
    post-up ip route add 192.168.0.0/16 via 192.0.2.1 dev ${IFACE}
    pre-down ip route del 10.0.0.0/8 via 192.0.2.1 dev ${IFACE}
    pre-down ip route del 172.16.0.0/12 via 192.0.2.1 dev ${IFACE}
    pre-down ip route del 192.168.0.0/16 via 192.0.2.1 dev ${IFACE}
    ovs_type OVSIntPort
    ovs_bridge vmbr1

この設定でWeb GUIからmgmt1にデフォルトルートを切りなおしたり、
仮想NICのVLAN変更なども実施したが今の所問題なく動いている。
小技なのとDebian/Ubuntuに慣れた人ならお手の物だが、
RHEL使いやNetworkManagerを使っている人は意外と嵌るので備忘録としておく。

CentOS 8のサポートが2021年末で終了すると発表され紆余曲折あったLinux界隈。
筆者も自宅サーバでCentOS 8を利用しているので、年末迄に方針を固める必要があった。
色々な環境を動かしているので、CentOS Streamが適切な検証環境もあったり、
Web・DNS・Mail・DBと安定稼働させたい本番系があるのも事実だった。

当初は全台をCentOS Streamに移行予定だったのだが、
以前試した時に謎の挙動をしたので、本番系は他のディストリビューションへ移行する事に。
AlmaLinuxとRockyLinuxの二つが候補となったが今回はRockyLinuxを採用する事にした。

という事で、RockyLinuxを選んだ経緯とアップグレードした結果を書こうと思う。

RockyLinuxへツールで引っ越したサーバのバージョンがこちら。標記もRockyに変わっていた。
移行には公式が準備しているツールを利用した。
そのままのコマンドだが、筆者が撃ち込んだ実際のコマンドは次の通り。

# curl https://raw.githubusercontent.com/rocky-linux/ \
  rocky-tools/main/migrate2rocky/migrate2rocky.sh -o migrate2rocky.sh
# chmod u+x migrate2rocky.sh
# ./migrate2rocky.sh -r
# reboot

自宅サーバのメールゲートウェイでは、OpenDMARCを使ってDMARCレポートを生成しているのだが、
OpenDMARCをv1.3からv1.4にアップグレードしたら、レポート生成時にエラーが出力される様になった。

実際に出力されたエラーログのサマリは次の通り。最初はDBが壊れたと思った (´・ω・｀)

opendmarc-reports: can't extract report for domain example.com: Unknown column 'messages.arc' in 'field list'
opendmarc-expire: DELETE failed: Table 'opendmarc.arcauthresults' doesn't exist

DBにカラムが足りなそうだったので、リリースノートと公式ドキュメントを確認した所、
OpenDMARC v1.4.0でARC(Authenticated Received Chain)にも対応した影響で、
生成するレポート用データのフォーマットとDBカラムが変更になった様だった。

• OpenDMARC RELEASE_NOTES at Master

1.4.0 Add ARC support ... Update SQL schema to support new porting functionality for DKIM selectors

OpenDMARC v1.3以下はARCに対応していないので、当然ながらデータベースもARCを想定していない。
その為、v1.3.X以下を利用している環境をアップグレードした場合は追加されたARCカラムが存在しないので、
レポート生成データを格納するデータベースに情報をinsert出来ずエラーとなる。

比較的簡単なテーブル構造なので人力でカラムを追加しても解決出来るのだが、
今回はデータを格納しているデータベースを一度初期化してデータを作り直す事に。
生成したDMARCレポートは別の方法でバックアップしているので、
カラムを弄って整合性を崩すよりも一から作り直した方が安全と判断した。

作り直した後はエラーも発生せずにレポートを生成が出来ており従来通りの機能を使えている。
当面は自宅サーバでメール送受信をし続けるので、
コア機能のコンポーネントアップグレードには気を付けねばと改めて実感する出来事だった。