No Such Blog or Diary

セキュリティ検査にパスしないとサーバを公開できないので来年度用にセキュリティ検査を受けてみた．結果，明らかな false positive を食らってるとか期限の切れてない証明書が期限切れ判定になってるとかで……　検査がひどい．どうにかしてくれないもんかね．

とりあえずこのまま公開の許可申請を投げてみるか．却下されたら戦おう．

停電が明けたのでサーバ群のアップデートを実行．22.04 が出て 1年になるので，20.04 だった連中を do-release-upgrade してみた．だいたい問題なかったけど，一部面倒が起きてたのでその解決のメモ．

まず，DNS の名前解決ができなくなったのが居た．古くから do-release-upgrade を重ねてきて netplan になってないようなやつだと思う．最も単純だろう解決として，/etc/systemd/resolved.conf に DNS のエントリを書くことにした：

[Resolve]
DNS=xxx.xxx.xxx.xxx

そして sudo systemctl restart systemd-resolved でサービスを再起動して解決．

次に，libvirtd が立ち上がらなくなってて virsh list が以下のエラーを吐いていた：

error: failed to connect to the hypervisor
error: Failed to connect socket to '/var/run/libvirt/libvirt-sock': No such file or directory

ps で見てみても libvirtd が居ないし，sudo systemctl start libvirtd としても "Unit libvirtd.service not found." を食らうという状況で，結局のところサービス起動部分のパッケージ libvirt-daemon-system が入ってないというオチだった（libvirt-daemon 自体は入ってた）．なので sudo apt install libvirt-daemon-system して sudo systemctl start libvirtd したら解決．

そして何故かネットワークにつながってこないのが居てて，原因を探ってみたら NIC の名前が ens3 から enp0s3 に変わってた．VM 母艦側のアップデートの影響かもしれないけれど，とりあえず /etc/network/interfaces とかで名前を書き換えて解決．

あとは apache2 で php のモジュールが無効化されてたのもあった．sudo a2enmod php8.1 して sudo service apache2 restart とかで解決．

最後に一番面倒だったのが OpenLDAP で，アップグレード中に「DB を移行できなかったから手動でどうにかしてね！」って警告が出ていた．調べてみた結果，2.4.x 系から 2.5.x 系にアップグレードされていたのだけど，2.5.x 系で DB のバックエンドの一部が使えなくなったのが原因らしい．syslog にも "slapd[73012]: lt_dlopenext failed: (back_hdb) file not found" とか出てて，HDB のバックエンドが使えないと言われてる．

ということで，「Service - Migrating from OpenLDAP 2.4.x to 2.5.x？」を参考に，2.5.x 系でも使えるバックエンドに移行するのを手動でやってみた．以下，元々のバックエンドが HDB の話（BDB でも一文字違うだけのはず）．

まず，諸々の設定が入ってる DB のダンプがアップグレード中に /var/backups/slapd-2.4.XXXX/cn=config.ldif として保存されてるらしいので，そいつを元に新しいバックエンド用の設定を作る．具体的には，そいつのコピーを取って，テキトウなエディタで "hdb" を "mdb" に置き換えて（一部は頭文字が大文字なので "Hdb" を "Mdb" にして），olcDbConfig のエントリを削除する（手元のファイルだと 4行消した）．これで新しいバックエンド（LMDB？）用の設定が用意できた．

次に，用意したファイルで設定用 DB を復元する．具体的には，/etc/ldap/slapd.d/ を空にしたうえで，slapadd で用意したファイル処理させる（カレントディレクトリの cn=config.ldif が用意したファイルとして）：

sudo slapadd -F /etc/ldap/slapd.d -n0 -l 'cn=config.ldif'

これで slapadd がエラーを吐かなければバックエンドの移行は成功．/etc/ldap/slapd.d/ の持ち主を改めれば DB 本体の移行の準備が整う：

sudo chown -R openldap:openldap /etc/ldap/slapd.d/

あとは残りの DB を全部同様に slapadd で投入すればよい．/var/lib/ldap の中身を空にした上で，slapadd でバックアップされてる ldif ファイルを投入：

sudo slapadd -l '/var/backups/slapd-2.4.XXXX/dc=example,dc=com.ldif'

投入が終わったら持ち主を改めておく：

sudo chown -R openldap:openldap /var/lib/ldap

そして最後に slapd を起動＆確認．

sudo service slapd start
sudo service slapd status

これくらいオートでやってくれよと思わなくもないけれど，とりあえず無事に移行が完了した．参考にしたドキュメントを書いてくれた人に感謝．

追記：一番大きな落とし穴があった……　mailman が消えてる．ここらの報告 をみてもまだちゃんと直ってない気がするので，とりあえずバックアップを復元してもうしばらく古いままで行くか．

暖房つけてないのに部屋の室温が 25℃超えとる．とても暑い．頭痛い．

明日の停電に備えて夕方に研究室の VM サーバ群を落としてイメージのバックアップを取っていたら，その途中でVM母艦とバックアップ先サーバの電源を落とされた．同じ部屋にサーバを置いてる別の研究室の奴らが犯人．なんでそんなことするん？

ということで，サーバとの接続が切れた直後に原因究明のためにサーバ部屋に直行して，怪しいやつがちょうど去るところだったのでとっ捕まえて事情聴取して，現場検証して犯行が確定して犯行動機を確認したら「止めるべきサーバをあと 2台探してて，目の前に動いてるサーバがあったのでヤッちゃいました」との供述．なんなんだその理由は……

自分ちのか分からんのに人んちのを落とすなよ！　しかもディスクアクセスしまくりだっただろ！

サーバ止めたらヤベェとかディスク吹っ飛んだらヤベェとかいう感覚はないのだろうか．なんかこう，責任者出てこい案件だよね……

そして責任者に凸ったら不在で，復旧作業が安定してからメール投げようとしたらメールサーバが止まってて，まあもう週明けでいいや．

空リストもリストだから「該当なし」ってのを確認すればいいのねと思ってたら，単純に中身を忘れてただけだったらしい．ちょっと残念．

会議直前に「延期します」ってのはヤメレ．延期の理由が事前に十分想定できる事柄だったりするのは特にヤメレ．