自宅で運用しているFreeBSDサーバーを13.5 から 14.4 へ更新しました。
本当なら、FreeBSD13系を使い続けたかったのですが、デイリーセキュリティーレポートに脆弱性が載りまくり。（以下）
FreeBSD -- Missing large page handling in pmap_pkru_update_range() CVE: CVE-2026-6386 WWW: https://vuxml.FreeBSD.org/freebsd/128951d0-3df0-11f1-bb07-bc241121aa0a.html FreeBSD -- Kernel use-after-free bug in the TIOCNOTTY handler CVE: CVE-2026-5398 WWW: https://vuxml.FreeBSD.org/freebsd/971b5528-3def-11f1-bb07-bc241121aa0a.html FreeBSD -- Remote code execution via RPCSEC_GSS packet validation CVE: CVE-2026-4747 WWW: https://vuxml.FreeBSD.org/freebsd/733febba-28d2-11f1-b35e-bc241121aa0a.html
即、運用が危険という事ではないものの、穴が開いたままになっているというのは気持ちが悪い。いずれ14系に上げなきゃいけないのは決定事項。実はフレッツADSLサービスが終わったことにより、ADSLモデムが使っていたルーターIPアドレスが空いたままになっていて、旧ルーターIPアドレスを新しいルーターに変更するついでに室内ネットワークもいじって OSも更新してしまおうと、思い切って作業を開始しました。
FreeBSDのOS更新は何度も行っているので作業自体は慣れっこ。重要度が引くサーバーから順に上げてゆく計画。自宅内だけで使うFreeBSDサーバーは、既知の設定（以下）変更が必要になるだけで、大きな問題は発生しなかったのですが、このサーバー（インターネットに公開しているサーバー）は、トラブル出まくり。
既知の現象
既知の現象1: FreeBSD14.x に上げると、SSHdのデフォルト設定が、旧sshからのリモートアクセスできなくなる。「Unable to negotiate a key exchange method」が、出る。
既知の現象2: 同、「no hostkey alg」
いずれも、sshd のバージョンアップにより、古くて弱い暗号化アルゴリズムが切り捨てられたためで、MacOS X 10.4 のような古い MacOS Xからsshアクセスしようとすると発生します。FreeBSD14.x と同世代の OSからsshアクセスする場合は問題ありません。対策は、SSHd サーバーの /etc/sshd_config を修正すること。
既知の現象3: FreeBSD 14.3以降（14.0～14.2は使ったことが無いので正確にはわからない） では、telnetd 自体が /usr/libexec から /usr/local/libexec に移動、かつ、オプションになっていて、2回目の freebsd-update を発行すると、/usr/libexec/telnetd が消えて、telnet 接続が出来なくなってしまう。
なので、
#pkg install -y freebsd-telnetd
を発行してインストール、inetd.conf も14.x書式に変更しないといけない。
ここまでは14.4に上げる全サーバーで発生する現象で既知の現象なので、エラーはすぐに解決できました。
新規の現象
- 「could not parse aliases file `/etc/aliases’: No error: 0」が出る
メールログに、「aliases line 100: syntax error、could not parse aliases file `/etc/aliases’: No error: 0」が記録される。最近、/etc/aliases なんて触っておらず、先ほどまでは問題なかったカ所。newaliaes しても同じエラーが出るだけで解決しない。
調べてみると、メール送信エージェントが、古い sendmail から dragonfly mail agent というものに置き換えられたらしく、互換性はあるものの、/etc/aliases の書式が異なるらしい。自動転送書式は旧書式をそのまま通るものの、コマンド渡しのパイプ「|」を使ったものがエラーになる模様。
シンプルに転送だけしているならいいけど、メーリングリストや、自動処理に渡している場合は、何らかの対処が必要になるようです。OS更新中に調査して DragonFly Mail Agent書式に書き換えるのは無理なので、DMA から sendmail に戻すことにしました。幸い、telnetd のように sendmail が消されている事はなかったので、/etc/mail/mailer.conf を消して、/usr/share/examples/sendmail/mailer.conf を /etc/mailer.conf としてコピーする。
そして、sendmail を再起動。
DragonFly Mail Agent は sendmail より軽いらしく採用されたようですが、使い方がわかるまでは、sendmail で運用する予定。
情報源は、https://forums.freebsd.org/threads/etc-aliases-strangeness-after-upgrade-from-13-5-to-14-4.102237/。
2026/05/04 追記：
パイプより後ろにスペースキャラがあることが原因と判明。 - Apache HTTPd が起動しない。
# service apache24 start Performing sanity check on apache24 configuration: Syntax OK Starting apache24. /usr/local/etc/rc.d/apache24: WARNING: failed to start apache24
httpd-error.log には、
AH00016: Configuration Failed
と一行残っています。これが唯一のヒント。
「AH00016」を検索してみると、.conf ファイルの記述間違いという事なのですが、いやいや、2時間くらいまで動いていた設定ですよ。修正もしていないし。
apachectl configtest は、問題なく通る。HTTPサーバーが起動しないのには、困った。Web検索して、SSLの問題らしいとわかりました。FreeBSDに限らず最近よく発生するんですよ。
私のWebサーバー、HTTPs接続もできるようにはしているのですけど、個人認証なので上位認証局とはつながっていない。そのサポートが面倒なので、サーバーは https:// を受け付けられる設定にしているけど、ファイヤーウォールで Port 443 をブロックしている。つまり私以外はHTTPs 接続できないということ。HTTPSを停止しても全く問題ないので、試しに httpd.conf などから SSL 接続用の設定を全部オフにしてみたところ、HTTPサーバーが無事に起動。原因は分かったので、とりあえずは HTTPのみで運用することとして、後日解決策を探ろうと思っています。
2026/05/04 追記:
sendmail の現象調査が一段落したので、server.key と server.crt を作り直してみました。
やり方に関しては、自分が書いた過去のメモのやり方を繰り返し。作り直して、設定を戻してみたところ、HTTPd 再起動に成功しました。エラーは出ませんでした。コマンド発行時にふと気づいたのは、証明書の有効期限を3650日に設定していたこと。記事の日付と比べると、HTTPSを公開していないものの、既に証明書の期限が切れていたかもしれません。それでもデーモン起動時、エラーは出ていなかったのですが、OSを新しくしたためサーバーが変わったと認識して起動しなくなったのかも と推測できそうです。本当かどうかはわかりませんが。
まっ、こっちも解決しました。 - portsnap が消えた。
FreeBSDの /usr/portsメンテナンスが、13.x 系は portsnap コマンドだったのですが、freebsd.org 側サーバー管理の都合だと思いますが、14系で 2026/04/30 にて portsnap が廃止され、git によるメンテナンスになるとアナウンスされています。2026/05/01 に更新作業を行った私はもろにこの影響を受けたようです。
2回目の freebsd-update を発行したことで、telnetd とともに portsnap もバイナリーごと消されてしまったようです。
pkg コマンドによるバイナリーインストールはそのまま運用できるのでオプションコマンドのインストールは問題ありませんけど、/usr/ports 下の情報を見て、インストールするパッケージ情報を掴むには portsnap をインストールするか、git に切り替える必要があるようです。
私の場合は、「pkg install -y portsnap」でportsnap を復活させました。近日中に git へ切り替えようとは思いますが、更新中にgit を勉強して切り替えるのは無理なので、とりあえずは旧スタイルで運用。
まとめ
サーバーの更新は終わって、サービスは再起動したもののの、課題山積み状態。