freebsd-update をかけたところ、ssh でのリモートログインが一時的にできなくなった。原因を確認したところ、更新された pam_unix.so が libypclnt.so を参照しようとしており、そのファイルが無くて失敗していた。別のマシンよりバイナリファイルを転送して回復させた。
/var/log/messages より抜粋
Jan 12 15:45:45 ns sudo: in openpam_load_module(): no pam_unix.so found
ldd /usr/lib/pam_unix.so.4 の結果
/usr/lib/pam_unix.so.4:
libutil.so.7 => /lib/libutil.so.7 (0x2818d000)
libcrypt.so.4 => /lib/libcrypt.so.4 (0x2819b000)
libypclnt.so.3 => not found (0x0)
libpam.so.4 => /usr/lib/libpam.so.4 (0x281b4000)
libc.so.7 => /lib/libc.so.7 (0x28083000)
cd /usr/lib; ls –l libypclnt* の結果
-r–r–r– 1 root wheel 23778 1 12 15:43 libypclnt.a
lrwxr-xr-x 1 root wheel 14 1 12 15:55 libypclnt.so -> libypclnt.so.2
以前より同じ問題が発生していたが、今回の変更により実際の影響が出たのであろう。libypclnt.so が存在しなかったのは、make buildworld; make installworld によるシステム更新において NIS を無効にしている時代が長くあり、削除してシステムを使っていたため。バイナリ更新をするのであれば、可能な限り素のままのシステム構成でないと痛い目に会うことがある。
ソースコードを利用した更新をしたのであれば、その後もそのようにすべき。
今回は、リモート作業していたsshセッションが切れてしまったら二度とログインできなくなっていたところであり、回復までもっていけたのはラッキーであった。
(1/16 追記)
他のマシンでは、更に /lib/libxpx.so.4 が不足しているために、ネットワーク関係の起動プロセスすら動かなくなった。元々ソースコードから不要なモジュールを削除してビルドしたのが原因であったため、以下の作業で復旧した。
cd /usr/src/lib/libipx; make; make install
ネットワーク経由でファイルを持ってくることができず、結構難儀した。これがリモートマシンだったら手も足も出なかったであろう。
不要なモジュールを削除してビルド＆インストールしていたのはハードディスク容量が少なかった時代の流儀の名残であり、現在では、本当に特別の理由がない限りはリリースされたそのままで使うのが良い。
