FreeBSD PHP 5.6.23 へのアップグレード

FreeBSD の ports へ PHP 5.6 のアップグレード（5.6.22 から 5.6.23 へ）が到着しました。

portmaster で関連の php-extensions も一気に更新しておきました。

php56-5.6.23 のビルドオプション

FreeBSD に DEFAULT_VERSIONS+=ssl=openssl の警告

いつものように FreeBSD で構築している自宅サーバの ports を更新しようとしたところ次のような警告メッセージが表示されるようになりました。

/!\ WARNING /!\
You have security/openssl installed but do not have DEFAULT_VERSIONS+=ssl=openssl set in your make.conf

どうも SSL の標準値の設定を行うように促しているようです。設定先は /etc/make.conf です。

そこで設定を追加したところ、警告メッセージはなくなりました。

# vi /etc/make.conf

-- 最終行へ追加 --
DEFAULT_VERSIONS+=ssl=openssl

FreeBSD OpenSSL 1.0.2_14 へアップデート

FreeBSD の ports へ OpenSSL のアップデート（1.0.2_13 から 1.0.2_14 へ）が到着しました。

前回の openssl-1.0.2_13 は脆弱性の問題で一時的にインストールが停止されていましたが、その後、解除された模様でインストールされていました。今回の openssl-1.0.2_14 は、脆弱性の問題もなく、素直にインストールされました。

openssl-1.0.2_14 のビルドオプション

FreeBSD OpenSSL 1.0.2_13 アップデート失敗

ここ数日の間、午前３時に到着する自宅サーバ（FreeBSD 10.3）のセキュリティ・リポートに OpenSSL 1.0.2_12 の脆弱性の問題が報告されていました。

本日 ports へ OpenSSL 1.0.2_13 へのアップデートが到着しました。

そこで早速 portmaster で更新を行ったところ、再び脆弱性問題でインストールが停止されてしまいました。新しく届いた OpenSSL 1.0.2_13 にも脆弱性が存在するそうです。

脆弱性のない新しい OpenSSL の到着を待つしかないようです。

===> Cleaning for openssl-1.0.2_13
===> openssl-1.0.2_13 has known vulnerabilities:
openssl-1.0.2_13 is vulnerable:
OpenSSL -- vulnerability in DSA signing
CVE: CVE-2016-2178
WWW: https://vuxml.FreeBSD.org/freebsd/6f0529e2-2e82-11e6-b2ec-b499baebfeaf.html

1 problem(s) in the installed packages found.
=> Please update your ports tree and try again.
=> Note: Vulnerable ports are marked as such even if there is no update available.
=> If you wish to ignore this vulnerability rebuild with 'make DISABLE_VULNERABILITIES=yes'
*** Error code 1

Stop.
make[1]: stopped in /usr/ports/security/openssl
*** Error code 1

Stop.
make: stopped in /usr/ports/security/openssl

===>>> make build failed for security/openssl
===>>> Aborting update

===>>> Update for security/openssl failed
===>>> Aborting update

FreeBSD ISC-DHCP-Server 4.3.4 へアップグレード

FreeBSD の ports へ ISC-DHCP-Server のアップグレード（4.3.3P1_1 から 4.3.4 へ）が到着しました。

isc-dhcp43-server-4.3.4 のビルドオプション

これまで気づかなかったのですが、isc-dhcpd の自動起動の設定フォーマットの設定例（/etc/rc.conf へ記述）が案内されていました。

dhcpd_enable="YES"
dhcpd_flags="-q"
dhcpd_conf="/usr/local/etc/dhcpd.conf"
dhcpd_ifaces=""
dhcpd_withumask="022"

以下は、今までの我が家の設定です。上記の設定例を参考にして見直しました。"bge0" は自宅サーバのネットワーク・インターフェース名です。なお、下記の状態でも動作しています（笑）。

dhcpd_enable="YES"
dhcpd_ifaces="bge0"

FreeBSD GnuTLS 3.4.13 へアップグレード

FreeBSD の ports へ GnuTLS のアップグレード（3.4.12 から 3.4.13 へ）が到着しました。

gnutls-3.4.13 のビルドオプション

FreeBSD cyrus-sasl2-saslauthd のコアダンプの怪 の続き

自宅サーバを FreeBSD 10.3 へアップグレードしたところ、SMTP 認証で使用していた saslauthd がコアダンプしてしまい、動作しなかった問題の続きです。

FreeBSD cyrus-sasl2-saslauthd のコアダンプの怪
http://near-unix.blogspot.jp/2016/05/freebsd-cyrus-sasl2-saslauthd.html

経緯

自宅サーバを FreeBSD 10.3 へアップグレードした後、全てのパッケージ（ports）を portupgrade コマンドによって、FreeBSD 10.3 の環境（ライブラリ）の影響下で再ビルドしなおしました。

# portupgrade -af --batch

当然古い FreeBSD 9.3 のライブラリなどは不要になったとの判断で 古い設定ファイルやライブラリを消去していました。

# cd /usr/src
# make delete-old
# make delete-old-libs

その後、メールが SMTP エラーにより送信できないことが判明しました。原因として saslauthd がコアダンプして停止していることを発見しました。復旧させるために関連パッケージを再ビルドするなどを行いましたが、解決することができませんでした。

検証のため、余剰のパソコンへ FreeBSD 10.3 を新規にインストールした後、 saslauthd 関係のインストールを行いました。自宅サーバの sendmail の設定ファイルをコピーして SMTP 認証によるメール送信を行ったところ、saslauthd は停止することなく、メールも正常に送信することが確認されました。これにより、自宅サーバ固有の問題であると判断しました。

その後に行ったこと

そこで、自宅サーバのハードディスクを5月22日に行った後、以前のハードディスクをそのまま保存していたことから、この古いハードディスクを使って、再度 FreeBSD 10.3 へアップグレードを行って、同じように saslauthd がコアダンプして停止してしまうのかを検証してみました。

自宅サーバで使っていた古いハードディスクをパソコンへ接続してアップグレードを行っているところです。

自宅サーバのハードディスク交換作業
http://near-unix.blogspot.jp/2016/05/blog-post_22.html

FreeBSD 10.3 へアップグレード

古いハードディスクには、現在稼働している自宅サーバの設定がそのまま残っていることから、そのまま動作させると各種サーバ類が衝突してしまうため、起動ファイル（/etc/rc.conf）の ***_enable="YES" の項目を全て "NO" と変更した後、cron で定期的に動作させているソフトウェアやシェルスクリプトを停止させました。その後、アップグレード処理を行いました。

今回のアップグレードでは、あえて古い FreeBSD 9.3 の設定ファイルやライブラリを残しておきました。万が一、互換性の問題で saslauthd に障害が発生しているのかもしれないと考えたからです。

第一回目の saslauthd の動作確認

FreeBSD 10.3 へアップグレードした直後は、saslauthd は正常に動作していました。また SMTP 認証経由のメール送信もできました。

パッケージの再ビルド

portupgrade で全てのパッケージを更新する前に、障害が発生しやすい perl5 と ruby だけは、事前に再ビルドしておきました。その上で全てのパッケージを再ビルドしました。自宅サーバには 410 個のパッケージが存在しており、再ビルドに要した時間は 16 時間ほどでした。なお samba36-3.6.25_3 は、脆弱性問題で portupgrade の更新から自動的に排除されました。

# portupgrade -af --batch

第二回目の saslauthd の動作確認

全てのパッケージの再ビルドが終わったところで再起動したところ、saslauthd は再びコアダンプを出力して停止してしまいました（涙）。

freeBSD 9.3 時代にビルドした saslauthd と FreeBSD 10.3 でビルドした saslauthd で結果が異なることとなりました。なおビルド設定ファイル（/ect/make.conf）は全く同じものを使用しています。

結果

単純に同じ経過を繰り返しただけでした（笑）。
結局 saslauthd が起動しない原因は不明のままです。

FreeBSD 10.3 の p5 (NTP) アップデート

FreeBSD 10.3 へ p5 アップデート（NTP）が到着しました。

今回のアップデートは、マシンの時刻合わせに関わる NTP に存在する複数の脆弱性対策だそうです。今年に入って NTP の脆弱性対策が何度も行われています。時刻合わせはとても身近な事だけに早急な対策が必要のようです。

FreeBSD-SA-16:24.ntp
- Multiple vulnerabilities of ntp -
https://www.freebsd.org/security/advisories/FreeBSD-SA-16:24.ntp.asc

/usr/src/UPDATING　の内容

20160604        p5      FreeBSD-SA-16:24.ntp

        Fix multiple vulnerabilities of ntp.

ソースツリーの更新

subversion でソースツリーを更新しました。

# svn update /usr/src
Updating '/usr/src':
U    /usr/src/contrib/ntp/ntpd/ntp_config.c
U    /usr/src/contrib/ntp/ntpd/ntp_keyword.h
U    /usr/src/contrib/ntp/ntpd/ntp_parser.h
U    /usr/src/contrib/ntp/ntpd/ntpd-opts.c
U    /usr/src/contrib/ntp/ntpd/ntpd.1ntpdman
U    /usr/src/contrib/ntp/ntpd/ntpd.man.in
U    /usr/src/contrib/ntp/ntpdc/invoke-ntpdc.texi
U    /usr/src/contrib/ntp/ntpdc/ntpdc.1ntpdcman
U    /usr/src/contrib/ntp/ntpd/ntpd.1ntpdmdoc
U    /usr/src/contrib/ntp/ntpd/ntpd.mdoc.in
U    /usr/src/contrib/ntp/ntpdc/ntpdc-opts.c
U    /usr/src/UPDATING
　　　　　　↓
　　　　　　↓
　　　　　　↓
U    /usr/src/usr.sbin/ntp/config.h
U    /usr/src/usr.sbin/ntp/doc/ntpd.8
U    /usr/src/usr.sbin/ntp/scripts/mkver
Updated to revision 301309.

ユーザランドの再ビルド

今回のアップデートでは、ユーザランドの再ビルドが必要です。

# cd /usr/src
# make buildworld

カーネルとユーザランドのインストール

# make installworld

マシンの再起動

# reboot

FreeBSD 10.3 の p4 アップデート

FreeBSD 10.3 へ p4 アップデート（3個）が到着しました。

FreeBSD 10.3 にアップグレードを行って初めてのアップデートを行いました。
今回は、三つのアップデート（その他 FreeBSD 9.3 のみのものが一つ）がありました。FreeBSD-SA-16:20.linux と FreeBSD-SA-16:21.43bsd は、攻撃者による権限昇格よってシステムの乗っ取りの危険性が存在するそうです。FreeBSD-SA-16:22.libarchive は、不正なアーカイブによって、不正なディスクへの書き込みを許してしまうそうです。どれも重要なセキュリティアップデートですので、すぐにアップデートを行いました。

FreeBSD-SA-16:20.linux
- Kernel stack disclosure in Linux compatibility layer -
https://www.freebsd.org/security/advisories/FreeBSD-SA-16:20.linux.asc

FreeBSD-SA-16:21.43bsd
- Kernel stack disclosure in 4.3BSD compatibility layer -
https://www.freebsd.org/security/advisories/FreeBSD-SA-16:21.43bsd.asc

FreeBSD-SA-16:22.libarchive
- Directory traversal in cpio(1) -
https://www.freebsd.org/security/advisories/FreeBSD-SA-16:22.libarchive.asc

FreeBSD-SA-16:23.libarchive (FreeBSD 9.3 only)
- Buffer overflow in libarchive(3) -
https://www.freebsd.org/security/advisories/FreeBSD-SA-16:23.libarchive.asc

/usr/src/UPDATING　の内容

20160531        p4      FreeBSD-SA-16:20.linux
                        FreeBSD-SA-16:21.43bsd
                        FreeBSD-SA-16:22.libarchive

Fix kernel stack disclosure in Linux compatibility layer. [SA-16:20]
Fix kernel stack disclosure in 4.3BSD compatibility layer. [SA-16:21]
Fix directory traversal in cpio(1). [SA-16:22]

ソースツリーの更新

subversion でソースツリーを更新しました。

# svn update /usr/src
Updating '/usr/src':
U    /usr/src/UPDATING
U    /usr/src/sys/compat/linux/linux_ioctl.c
U    /usr/src/sys/compat/linux/linux_misc.c
U    /usr/src/sys/conf/newvers.sh
U    /usr/src/sys/kern/vfs_syscalls.c
U    /usr/src/contrib/libarchive/cpio/bsdcpio.1
U    /usr/src/contrib/libarchive/cpio/cpio.c
U    /usr/src/contrib/libarchive/libarchive/archive.h
U    /usr/src/contrib/libarchive/libarchive/archive_write_disk.3
U    /usr/src/contrib/libarchive/libarchive/archive_write_disk_posix.c
U    /usr/src/contrib/libarchive/libarchive/test/test_write_disk_secure.c
 U   /usr/src
Updated to revision 301110.

カーネルとユーザランドの再ビルド

今回のアップデートでは、カーネルとユーザランドの再ビルドが必要です。

# cd /usr/src
# make buildworld
# make buildkernel KERNCONF=MYKERNEL

カーネルとユーザランドのインストール

# make installkernel
# make installworld

マシンの再起動

# reboot

[2016-06-04] 訂正

表題が「FreeBSD 20.3 の p4 アップデート」となっておりましたが、「FreeBSD 10.3 の p4 アップデート」の間違いでしたので訂正しました。

FreeBSD cyrus-sasl2-saslauthd のコアダンプの怪

自宅サーバを FreeBSD 9.3 から 10.3 へアップグレードを行った後、まだ残っている問題が一つあります。それは SMTP 認証を司っている cyrus-sasl2-saslauthd がコアダンプ（core dump）してしまうことです。

# service saslauthd start
Starting saslauthd.
Segmentation fault (core dumped)
/usr/local/etc/rc.d/saslauthd: WARNING: failed to start saslauthd

我が家のメール事情

我が家にある各パソコンからメールを送信する場合には、自宅サーバの MTA の Sendmail の smart_host 機能を経由して、プロバイダのメールサーバへ接続した後、メールを送信するようになっています。

上記のとおり、Sendmail の SMTP 認証が出来なくなったことから、メールの送信が出来なくなってしまいました。メールを送信する最低限のパソコンだけ、自宅サーバを経由せず、直接プロバイダのメールサーバへ SMTP 認証を受けるようにして、メール送信を行うことで、不具合に対処していました。

原因不明

単純に portmaster で依存関係にあるパッケージと一緒に再インストール（※１）を試みましたが、コアダンプしてしまうことに変化はありませんでした。なおビルドオプションは標準に戻してビルドを行っています。またターゲット CPU を prescott に設定していましたが、i686 に設定を行ってもコアダンプしてしまいました。

なおこの問題のため、休眠中のパソコンへ FreeBSD 10.3 をインストールして、 cyrus-sasl2 と cyrus-sasl2-saslauthd を portmaster でインストールしてみましたが、問題なく動作していました。このため saslauthd がコアダンプしてしまう問題は、我が家のサーバだけの問題のようです。

# portmaster security/cyrus-sasl2  security/cyrus-sasl2-saslauthd

しかし pkg でビルド済みのパッケージをインストールすると何故か動作してしまうのです（笑）。　謎です。

# pkg install security/cyrus-sasl2  security/cyrus-sasl2-saslauthd

私の稚拙な知識ではどうすることもできませんでした。
とりあえず、saslauthd が動作する pkg のビルド済みのパッケージを利用して、現状のメール送信できない状況を回避しました。

※１：この SMTP 認証の saslauthd のコアダンプ問題の他にも、いろいろと問題が自宅サーバにあったことから、インストール済みの全てのパッケージ（ports）を再ビルドしていました。18 時間ほどかかりました（涙）。 この全パッケージの再ビルドによって、FreeBSD 9.3 時代の各種のライブラリのリンクなどは新しい FreeBSD 10.3 のものへ移行しているはずです。

# portupgrade  -af  --batch

SMTP 認証の参考サイト

27.9. SMTP Authentication - FreeBSD
https://www.freebsd.org/doc/handbook/SMTP-Auth.html

[2016-06-04] 追記

本記事の saslauthd がコアダンプしてしまう件について、その後、自宅サーバで smarthost 機能を経由してのメール発信を中止しました。個々のパソコンから直接、プロバイダの SMTP サーバへ接続して、メールを発信するようにしました。

理由は、pkg のビルド済みパッケージでも動作が不安定になることがあったためです。もう数日、この件で時間ばかりが過ぎ去るばかりで解決することができませんでした。

なお新規に余剰のパソコンへ FreeBSD 10.3 をインストールした後、SMTP 認証に必要なパッケージを portmaster でインストールして、saslauthd の設定を行って動作確認をしてしてみました。新規インストールの場合は、全く問題なく saslauthd が動作して、SMTP 認証経由で smathost 機能が動作しました。やはり saslauthd がコアダンプしてしまう件は、我が家の自宅サーバ固有の問題でした。

FreeBSD PHP 5.6.22 へアップグレード

FreeBSD の ports へ PHP 5.6 のアップグレード（5.6.21 から 5.6.22 へ）が到着しました。また一緒にウェブサーバの Apache 用の PHP モジュール（mod_php56）も到着していました。

portmaster -ad  コマンドで更新を行っておきました。

php56-5.6.22 のビルドオプション

FreeBSD named (bind99-9.9.9P1) のアップデート

FreeBSD の ports へ named (Bind9) のアップデート（bind99-9.9.9_1 から bind99-9.9.9P1 へ）が到着していました。

bind99-9.9.9P1 のビルドオプション

FreeBSD の portsdb エラー

新しく FreeBSD 10.3 になって ports ツリーの更新を行いました。

すると portsdb のエラーが発生しました。

HASH: Out of overflow pages.  Increase page size
/usr/ports/INDEX-10:20155:dbm_store failed

原因

以前にも同じような症状が発生していました。原因は portsdb の問題です。

対策

portsdb の再構築を行いました。

現状の portsdb の様子を確認しました。何と！ INDEX-6 からのものが存在していました（笑）。

# cd /usr/ports
# ls | grep INDEX
.portsnap.INDEX
INDEX-10
INDEX-10.db
INDEX-6
INDEX-7
INDEX-8
INDEX-8.db
INDEX-9
INDEX-9.db

現状の portsdb を過去のものを含めて削除しました。

# rm -rf INDEX*

portsdb の再構築を行いました。再構築には結構な時間がかかりました。

# make index
Generating INDEX-10 - please wait..--- describe.accessibility ---
--- describe.arabic ---
--- describe.archivers ---

# portsdb -uU
Updating the ports index ... Generating INDEX20160528-41516-6hhlqn - please wait..--- describe.accessibility ---
--- describe.arabic ---
--- describe.archivers ---

出来上がった portsdb を確認しました。

# ls | grep INDEX
.portsnap.INDEX
INDEX-10
INDEX-10.db

以上で portsdb のエラーが発生しなくなりました。

[追記 : 2016-05-29]

再び同じエラーが発生しました。

再度ネット上を検索してみたところ、ruby-bdb に問題があると同様のエラーが発生することがあるようです。そこで ruby-bdb のインストール状況を確認してみました。すると ruby 本体がバージョン 2.2 （標準）と 2.1 の二つがインストールされていました。さらに ruby-bdb も 2.1 のものがインストールされていました。

# pkg info | grep ruby
ruby-2.2.5,1     Object-oriented interpreted scripting language
ruby21-2.1.9,1  Object-oriented interpreted scripting language
ruby21-bdb-0.6.6_4  Ruby interface to Oracle Berkeley DB

そこでこの古いバージョン（2.1）と標準バージョン（2.2）を含めて削除した後、再度インストールし直すこととしました。我が家では portupgrade の依存関係で ruby がインストールされているため、思い切った処置をしました。

# pkg delete ruby-2.2.5,1 ruby21-2.1.9,1 ruby21-bdb-0.6.6_4 portupgrade-2.4.14,2

次に再度 portupgrade をインストールして、依存関係で ruby 類の自動インストールを行いました。

# portmaster ports-mgmt/portupgrade
===>>> The following actions will be taken if you choose to proceed:
    Install ports-mgmt/portupgrade
    Install databases/ruby-bdb
    Install lang/ruby22

===>>> Proceed? y/n [y]

portupgrade のインストールが終わったところで、再度 ports ツリーのダウンロードを行いました。そして

# portsdb -FU

インストール済みパッケージの中でアップデートが到着していないか確認してみました。エラーが発生するときには、ここで発生します。

# portversion -vL=

今度は、本当にエラーが発生していないようです。

FreeBSD Perl5 の関連パッケージのマニュアル・インストール・エラー

以前より気になっていた FreeBSD において portmaster や portupgrade を使ったインストールにおいて、インストールの最終段階においてマニュアルのインストールができなくてエラーとなる現象を対策しました。

これまでは、portmaster や portupgrade でインストールできない Perl5 関連のパッケージは、pkg コマンドでビルド済みのものをインストールしていました。しかし度々、依存関係にあるパッケージが古いバージョンに置き換えられるなど苦労をしていました。

現象

現象としては次のような感じでエラーが発生してインストールが中断してしまいます。

pkg-static: Unable to access file
/usr/ports/work/databases/p5-DBI/stage/usr/local/share/man/man1/dbiproxy.1.gz:
No such file or directory
*** [fake-pkg] Error code 74

原因

原因としては、Perl5 のバージョン情報によって制御を変更する設定ファイル（/usr/ports/Mk/Uses/perl5.mk）に問題がありました。・・・というか、現在の標準バージョンの 5.20 から次期バージョンの 5.22 への過渡期で、一時的な対応で問題が発生しているようでした。正確には、各 ports 側のマニュアルの保管場所の問題なのかもしれません。

/usr/ports/Mk/Uses/perl5.mk には、バージョン 5.20 が終わったら消去するように求める部分が存在しています。ここで "THIS_IS_OLD_PERL" と設定されてしまうことによって、マニュアルのインストールに障害を発生させているようです。

- /usr/ports/Mk/Uses/perl5.mk の過渡期対策 -

# remove when 5.20 goes away.
.sinclude "${LOCALBASE}/etc/perl5_version"
.if defined(PERL_VERSION)
PERL5_DEPEND=   ${PERL5}
THIS_IS_OLD_PERL=       yes
.else
# end of remove

対策

対策としては、上記の "THIS_IS_OLD_PERL" の部分を削除するのはなく、後続にある "THIS_IS_OLD_PERL" とによってマニュアルのインストール・ディレクトリを制御している部分を修正しました。

113 行目付近にあるマニュアルのインストール・ディレクトリを切り替えている部分を下記のとおり、"THIS_IS_OLD_PERL" の "yes" / "no" に係わらず、同じディレクトリへインストールさせるようにしました。具体的には、赤文字部分の先頭に # を付加してコメント化した後、青文字部分を追加しました。

.if defined(THIS_IS_OLD_PERL)
#SITE_MAN1_REL?=        share/man/man1
SITE_MAN1_REL?= ${SITE_PERL_REL}/man/man1
.else
SITE_MAN1_REL?= ${SITE_PERL_REL}/man/man1
.endif

以上の対策により、portmaster や portupgrade で Perl5 関係のパッケージのインストールが できるようになりました。

そしてマニュアルのインストール先のディレクトリは次の場所となりました。

/usr/local/lib/perl5/site_perl/man/man1/

FreeBSD Bind9 (named) のインストール

- 注意 -
この記事において FreeBSD 9.3 のときにシステム内で使っていた /etc/namedb のディレクトリ内のデータをコピーして、新しく ports からインストールした named に使用する内容の記述をしました。このままの手順で行うと、以前の /etc/namedb のディレクトリ内のデータを参照するようになってしまいます。コピーして設定した場合には、/usr/local/etc/namedb/named.conf の中にある各ディレクトリの設定の見直しが必要です。

"/etc/namedb" --> "/usr/local/etc/namedb"

FreeBSD 10 系よりシステム内にあった DNS サーバの Bind9 (named) が ports へ移管されることになりました。今回、自宅サーバのシステムを FreeBSD 9.3 から FreeBSD 10.3 へアップグレードしたことにより、ports の Bind9 (named) をインストールしました。

FreeBSD 10.3 へアップグレード
http://near-unix.blogspot.jp/2016/05/freebsd-103.html

経緯

元々は FreeBSD 9.3 の段階でシステム内の Bind9 (named) から ports の Bind9 (named) へ移行しようと試みました。ビルドは成功して、インストールも行われたのですが、何故か起動スクリプト（/usr/local/etc/rc.d/named）がインストールされていないなど、問題を抱えている状態でした。

いろいろと操作して ports の Bind9 (named) を起動させることも不可能とは思われませんでしたが、当初より予定していた FreeBSD 10.3 へのアップグレード後に、新規に Bind9 をインストールすることとしました。

なおインストールした Bind9 (named) のバージョンは 9.9 のものです。ports 上には 9.10 と開発版の devel のものも存在していましたが、安定版志向ということで 9.9 を選択しました。

インストール

portmaster コマンドでインストールしました。依存関係のあるパッケージも一緒にインストールされました。

# portmaster dns/bind99
===>>> The following actions will be taken if you choose to proceed:
    Install dns/bind99
    Install dns/idnkit

===>>> Proceed? y/n [y]

設定ファイルの移動

FreeBSD 9.3 の時に使用していた設定ファイルをそのままコピーして使用しました。

# cp -Rp /etc/namedb  /usr/local/etc/namedb

起動スクリプト（/etc/rc.conf）

電源起動時の起動スクリプトは、FreeBSD 9.3 の時に使用していたものがそのまま使用することが出来ました。起動設定では、IPv4 のみの動作で、ユーザに bind を指定しています。

- /etc/rc.conf の named の起動部分 -
named_enable="YES"
named_flags="-4 -u bind"

起動

手動で起動させるときには次のコマンドです。（start：起動、stop：停止、restart：再起動）

# /usr/local/etc/rc.d/named start

名前の解決（/etc/resolv.conf）

DNS サーバの設定を行う /etc/resolv.conf を編集して、自分自身（127.0.0.1）の named を参照するように変更しました。

# vi /etc/resolv.conf

- /etc/resolv.conf の編集部分 -
nameserver    127.0.0.1

named : the working directory is not writable の警告

起動させると警告が出ていました。以前から発生していたものか？不明です。次のウェブサイトに詳しい解決方法が記述されていました。

BIND - name server error "the working directory is not writable"
http://scratching.psybermonkey.net/2009/09/bind-name-server-error-working.html

named が書き込みできないディレクトリは /var/name/etc でした。どおりで /usr/local/etc/namedb のディレクトリをいくら操作しても解決しなかったはずです（笑）。

# chown -R bind:wheel /var/name/etc

そして named の取り扱うファイルについての設定も変更しました。

# vi /etc/mtree/BIND.chroot.dist

- /etc/mtree/BIND.chroot.dist の変更部分 -

赤色部分が root から bind へ変更した部分

青色部分が追加した部分

/set type=dir uname=bind gname=wheel mode=0755
.
    dev             mode=0555
    ..
    etc
        namedb
            dynamic uname=bind
            ..
            master  uname=bind
            ..
            slave   uname=bind
            ..
            working uname=bind
            ..
        ..
    ..
/set type=dir uname=bind gname=wheel mode=0755
    var             uname=root
        dump
        ..
        log
        ..
        run
            named
            ..
        ..
        stats
        ..
    ..
..

FreeBSD 10.3 へアップグレード

自宅サーバのシステムを FreeBSD 9.3 から FreeBSD 10.3 へシステム・アップグレードを行いました。

経緯

昨年末から FreeBSD 10 系へのアップグレードを考えていましたが、なかなか着手することができず、ずるずると本日まで引き伸ばしてきました。しかし FreeBSD 9.3 のサポート期限の 2016 年 12 月 31 日まで、あと半年と迫ってきたことから、流石に重い腰を上げてアップグレード作業を行いました。

また先日、ハードディスクを交換したばかりなので、その内容に大きな変化のないうちに、アップグレードを行っておくと、万が一アップグレードに失敗したときには、古いハードディスクに戻すことによってとりあえず機能を復旧させることも可能なため、早いうちにアップグレードを行いたいと考えていました。

FreeBSD 10 系では、DNS サーバの named (Bind9) がシステムの中から ports へ移管されることから、アップグレードにより DNS サーバ がすぐに動作しないことを考慮して、OpenWrt をインストールした無線 LAN ルータの中に、予備の DNS サーバを用意して、今回のアップグレードに備えていました。
なお ports の中の bind9 のインストールの記事は、別の記事として記述しています。

FreeBSD Bind9 (named) のインストール
http://near-unix.blogspot.jp/2016/05/freebsd-bind9-named.html

準備作業

アップグレードの前に事前にいくつかの準備作業を行っておきました。

- DNS サーバ（Bind9） -

最終的なデータを OpenWrt をインストールした無線 LAN ルータへコピーをして、動作確認を行いました。すでに先日の自宅サーバのハードディスク交換のときにも、この OpenWrt をインストールした無線 LAN ルータの DNS サーバを使っており、検証も終わっていました。

- DHCP サーバ（isc-dhcpd） -

自宅サーバの DNS サーバが停止しても問題ないように以前より第二 DNS サーバにOpenWrt をインストールした無線 LAN ルータの DNS サーバを設定していました。更に念の為、第一 DNS サーバに OpenWrt をインストールした無線 LAN ルータの DNS サーバを指定しておき、万全を期しておきました。作業を開始する前に、稼働中のパソコン類の LAN 接続を一度切断して、再度接続し直して、新しい LAN 設定に変更させておきました。

# vi /user/local/etc/dhcpd.conf

# /usr/local/etc/rc.d/isc-dhcpd restart

- resolv.conf の編集 -

どこの DNS サーバを参照するか決める設定ファイル（/etc/resolv.conf）を編集して、自分自身を指していた 127.0.0.1 を OpenWrt をインストールした無線 LAN ルータの DNS サーバの IP アドレスへ変更しました。

# vi /etc/resolv.conf

- /etc 設定ファイルのバックアップ -

システム内の各種設定ファイルが保管されている /etc ディレクトリをバックアップしておきました。アップグレードの最終段階で行う mergemaster の処理のとき、万が一、誤った処理をしたときに元のファイルに戻せるように配慮しました。

# cp -Rp  /etc  /etc.old

ソースツリーの更新

アップグレードのまず最初の作業として FreeBSD 10.3 のソースコードを取得しました。古い FreeBSD 9.3 のソースツリーを消去した後、subversion コマンドで取得しました。

- ソースツリーのあるディレクトリを削除 -
# rm -Rf /usr/src

- 新しくソースツリーを作成 -
# mkdir /usr/src
# cd /usr/src
# svn checkout https://svn0.us-west.FreeBSD.org/base/releng/10.3 /usr/src

カーネルのビルドオプションの設定

カーネルのビルドプションを設定しました。設定ファイル名は、FreeBSD のマニュアルに出てくる MYKERNEL の名称をそのまま使用しました。

- GENERIC から MYKERNEL へ複写 -
# cp /usr/src/sys/i386/conf/GENERIC /usr/src/sys/i386/conf/MYKERNEL

そしてこの MYKERNEL を編集しました。を私は、ブートコード部分を i486、i586 を排除して i686 一本に設定した後、PC カード関連のモジュールを組み込まないようにしました。

- MYKERNEL を編集 -
# vi /usr/src/sys/i386/conf/MYKERNEL

カーネルのデバックを行うことがないため、カーネルの巨大化を防ぐためにシンボル類のビルドも中止させました。" # " 記号でコメント化しました。

- MYKERNEL 編集部分の一部 -
#makeoptions    DEBUG=-g                # Build kernel with gdb(1) debug symbols
#makeoptions    WITH_CTF=1              # Run ctfconvert(1) for DTrace support

カーネルとユーザランドのビルド

カーネルとユーザランドをビルドしました。途中にある二つのアンパサンド（&&）は、連続して二つの make 処理を行う連結記号です。

# cd /usr/src
# make buildworld && make buildkernel KERNCONF=MYKERNEL

カーネルのインストール

FreeBSD 9.3 から 10.3 へのメジャー・アップグレードとなるため、従来のようにカーネルとユーザランドを一気にインストールすることはしませんでした。とりあえずカーネルだけをインストールして様子をみました。

# make installkernel

カーネルのインストールが終わったところで、再起動させました。

# reboot

ユーザランドのインストールでトラブル

無事 FreeBSD 10.3 のカーネルで起動することができました。早速、ユーザランドをインストールしようとしたところ、インストールエラーとなってしまいました。これは "unbound" というユーザが登録されていないことが原因でした。

ERROR : Required unbound user is missing. see /usr/src/UPDATING.

解決するには unbound ユーザを追加します。ユーザの追加は、手動で設定するのではなく、システムアップグレードで追加されるユーザを追加する "mergemaster -p" コマンドで解決するのが一般的のようです。

# mergemaster -p

"mergemaster -p" では /etc/group と /etc/master.passwd の二つのファイルを、新規インストール時に設定されるファイルと順次比較して表示してくれます。

作業としては、インストール（i）や消去（d）を選択せず、合併（m）を選択します。右側部分に "unbound" の項目が表示されたところで、[R] キー（右側の選択）をして、"unbound" のユーザを追加しました。その他の部分では、従来からある左側の部分を選択 [L] キーを選択しました。

最終行まで選択が終わったところで、[Q] キーを押して編集モードを抜けた後、インストールの [i] キーを押して編集内容を反映させました。

ユーザランドのインストール

以上でユーザランドのインストールができる準備ができましたので、インストールを開始しました。

# cd /usr/src
# make installworld

ユーザランドのインストールが終わったところで、システムの設定ファイル（/etc 以下のファイル）の合併作業（mergemaster）を行いました。ここでは、編集を行っている設定ファイルをどのように処理するのか問い合わせを行うオプションの "Ui" で行いました。未編集の設定ファイルは、自動的に FreeBSD10.3 のものに置き換えられてしまいます。

# mergemaster -Ui

ここでの mergemaster の操作は、基本的に旧来からのものをそのまま使用するときには [d] の削除を選択しました。後で手動で再編集をする設定ファイルなどは、[i] を選択して FreeBSD 10.3 の初期設定ファイルをインストールしました。もちろん新旧の設定ファイルを合併させたいときには [m] を選択して、編集モードへ移行して、旧来からの設定の場合は左側の [L] キーを選択して、新しい設定の場合には右側の [R] キーを選択して設定ファイルを合併させてください。

mergemaster の最終部分では、各種設定を反映させるスクリプトを動作させるかどうかの問い合わせがありました。すべて [Y] で応えて、反映させました。

再起動

mergemaster による操作が終了したところで、マシンを再起動させました。

# reboot

動作確認

マシンが再起動したところで各種の動作確認を行いました。
sendmail の設定データの再インストールも念の為に行っておきました。なお mergemaster での操作ときには、sendmail***.cf ファイルなどは全て [d] を選択して、従来から設定していたデータをそのまま流用しました。

# cd /etc/mail
# make
# make install
# make restart

その他、いろいろと問題が発生していましたが、順次解決させました。

FreeBSD Samba 4.2 へアップグレード

以前よりセキュリティ上の問題で FreeBSD の ports にある Samba 3.6 はアップグレードやインストールが禁止となっていました。

Checking for packages with security vulnerabilities:
samba36-3.6.25_3

そこで今回 Samba のアップグレードを行って、この Samba 3.6 のセキュリティ上の問題を回避することとしました。

Samba のインストール・バージョン

FreeBSD の ports には、以下の四つのバージョンの Samba が用意されていますが、Debian Jessie と同じ Samba 4.2 をインストールしました。

samba36 -- 現状のバージョン
samba42 -- インストールしたバージョン
samba43
samba44

pkg コマンドでインストール

いつものように pkg コマンドでインストール・バージョンの変更を行った後、portmaster でインストールを試みました。

# pkg set -o net/samba36:net/samba42
Change origin from net/samba36 to net/samba42 for samba36-3.6.25_3? [y/N]: y

# portmaster net/samba42

samba42-4.2.12 のビルドオプション

がしかし、perl5 のライブラリがインストールできないとの理由でインストールが中断されてしまいました。

FreeBSD にて depends on file: /usr/local/bin/perl5.20.2 - not found エラー
http://near-unix.blogspot.jp/2016/05/freebsd-depends-on-file.html

そこで pkg コマンドで実行ファイルを直接インストールしました。

# pkg install net/samba42
Updating FreeBSD repository catalogue...
FreeBSD repository is up-to-date.
All repositories are up-to-date.
pkg: gnutls has a missing dependency: trousers-tddl
The following 6 package(s) will be affected (of 0 checked):

New packages to be INSTALLED:
    samba42: 4.2.12
    ruby: 2.2.5,1
    py27-dnspython: 1.12.0
    ntdb: 1.0
    ldb: 1.1.26
    libinotify: 20160505

The process will require 150 MiB more space.
27 MiB to be downloaded.

Proceed with this action? [y/N]: Y

Samba 4.2 の設定

Samba 4.2 は Samba 3.6 の設定ファイルが流用できました。一部無効となっている設定項目もありますが、とりあえず動作しました。今後、設定項目の見直しが必要です。

Samba 3.6 の設定ファイル（smb.conf）を次のようにコピーして、Samba 4.2 の設定ファイル（smb4.conf）を作成しました。

# cp /usr/local/etc/smb.conf /usr/local/etc/smb4.conf

Samba 4.2 の起動方法が変更となっています。起動ファイル（/etc/rc.conf）の変更が必要です。

# vi /etc/rc.conf

- rc.conf の変更内容 -
samba_enable="YES"
nmbd_enable="YES"
smbd_enable="YES"
　　　↓↓↓
samba_server_enable="YES"

動作確認

従来と同じように動作するか確認しました。我が家では問題なく動作しました。

portmaster で再インストール

perl5 の "depends on file: /usr/local/bin/perl5.20.2" のエラーを解消した後、Samba 4.2 を portmaster でインストールし直しました。通常は pkg でパッケージをインストールした状態のままで問題ありません。我が家では認証に PAM 認証を加えたかったので、portmaster でビルドし直しました。

===>>> pkg-message for samba42-4.2.12
Always:
===============================================================================

How to start: http://wiki.samba.org/index.php/Samba4/HOWTO

* Your configuration is: /usr/local/etc/smb4.conf

* All the relevant databases are under: /var/db/samba4

* All the logs are under: /var/log/samba4

* Provisioning script is: /usr/local/bin/samba-tool

For additional documentation check: http://wiki.samba.org/index.php/Samba4

Bug reports should go to the: https://bugzilla.samba.org/

===============================================================================

===>>> Done displaying pkg-message files
===>>> Re-installation of samba42-4.2.12 complete

FreeBSD にて depends on file: /usr/local/bin/perl5.20.2 - not found エラー

FreeBSD の ports のアップデートのうち、perl 関連の ports において、下記のような依存関係のエラーが発生して、アップデートが出来なくなっていました。

パッケージ名 -- depends on file: /usr/local/bin/perl5.20.2 - found

症状

perl5 関連の ports のアップデートやインストール時に perl5.20.3 がインストール済みにも係わらず、 perl5.20.2 を発見してインストール動作を試みるものの perl5.20.2 関連のディレクトリが存在しないとしてインストール・エラーとなってしまうものです。

下記にあるように perl5.20.2 の実行ファイルを消去して、さらに perl5.20.3 を再インストールしても次のように perl5.20.2 が存在しないとしてエラーが発生していました。

パッケージ名 -- depends on file: /usr/local/bin/perl5.20.2 - not found

原因

具体的にどうしてこんなことになってしまったのか不明ですが、perl5.20.2 を残したまま、perl5.20.3 がインストールされていました。

# ls /usr/local/bin/perl5*
/usr/local/bin/perl5
/usr/local/bin/perl5.20.2
/usr/local/bin/perl5.20.3

対策

すでに不要となった perl5.20.2 の実行ファイルを手動で消去した後、perl5 のバージョン管理ファイル（/usr/local/etc/perl5_version）を手動で訂正しました。

 perl5.20.2 の実行ファイルを消去

# rm /usr/local/bin/perl5.20.2

perl5 のバージョン管理ファイルを訂正

# vi /usr/local/etc/perl5_version

- 以下は編集内容 -
# Do not modify PERL_VERSION here, instead use DEFAULT_VERSIONS= perl5=5.20

PERL_VERSION=5.20.2
　　　　↓↓↓
PERL_VERSION=5.20.3

FreeBSD 9.3 の p42 (atkbd) アップデート

FreeBSD 9.3 へ p42 アップデート（1個）が到着しました。その他、FreeBSD 10 系向けのセキュリティ・アップデートが一個ありました。

今回のアップデートは、何と！キーボード・ドライバ（atkbd）でした。こんな枯れたドライバにどんな脆弱性が残っているのか？と疑問に思ってしまいました。下記のセキュリティ情報によると、ioctl の部分に問題箇所（バッファ・オーバーフロー）が存在しており、この問題箇所を悪意のある一般ユーザーが攻撃することでカーネルメモリを破壊して、一般ユーザによる「特権昇格」を行うことができるそうです。複数のユーザで一つのマシンを共有することがなければ、それほど意識する問題ではないのかもしれません。しかし脆弱性問題は、できるだけ早く対策しておくことに変わりはありません。

FreeBSD-SA-16:18.atkbd
- Buffer overflow in keyboard driver -
https://www.freebsd.org/security/advisories/FreeBSD-SA-16:18.atkbd.asc

FreeBSD-SA-16:19.sendmsg (FreeBSD 10 only)
- Incorrect argument handling in sendmsg(2) -
https://www.freebsd.org/security/advisories/FreeBSD-SA-16:19.sendmsg.asc

/usr/src/UPDATING　の内容

20160517        p42     FreeBSD-SA-16:18.atkbd

        Fix buffer overflow in keyboard driver. [SA-16:18]

ソースツリーの更新

subversion でソースツリーを更新しました。

# svn update /usr/srcUpdating '/usr/src':
G    /usr/src/UPDATING
U    /usr/src/sys/conf/newvers.sh
U    /usr/src/sys/dev/kbd/kbd.c
Updated to revision 300113.

カーネルの再ビルド

今回のアップデートでは、カーネルの再ビルドが必要です。

# cd /usr/src
# make buildkernel KERNCONF=MYKERNEL

カーネルとユーザランドのインストール

# make installkernel

マシンの再起動

# reboot

FreeBSD OpenVPN 2.3.11 へアップグレード

FreeBSD の ports へ OpenVPN のアップグレード（2.3.10_2 から 2.3.11 へ）が到着しました。

openvpn-2.3.11 のビルドオプション