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 で依存関係にあるパッケージと一緒に再インストール(※1)を試みましたが、コアダンプしてしまうことに変化はありませんでした。なおビルドオプションは標準に戻してビルドを行っています。またターゲット 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 のビルド済みのパッケージを利用して、現状のメール送信できない状況を回避しました。

※1:この 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 のビルドオプション

Buffalo WLI-UC-GNHP が故障

自宅の玄関口に設けていた監視カメラ(LD-HLA + WLI-UC-GNHP)からの通信が途絶えてしまいました。調査したところ、無線 LAN アダプタの WLI-UC-GNHP が故障していました。

症状

無線 LAN アダプタの WLI-UC-GNHP が故障した模様で、無線 LAN 通信が出来なくなった他、 WLI-UC-GNHP の本体が異常な発熱をしていました。

無線 LAN アダプタを交換

そこで無線 LAN アダプタを交換することとしました。交換するにあたって、以前より気になっていた rt2800usb ドライバで動作するチップの発熱の多さを気にして、今回は zd1211rw のドライバで動作する無線 LAN アダプタを使用することとしました。

(旧) Buffalo WLI-UC-GNHP — rt2800usb
(新) Buffalo WLI-U2-KG54L — zd1211rw
下が故障した WLI-UC-GNHP です。
上は今回から使用する WLI-U2-KG54L です。

監視カメラの本体となる HD-HLAN を設置場所から降ろした後、シリアルコンソールを接続して、無線 LAN 設定をし直しました。

zd1211rw のファームウェアをインストールしました。

# apt-get install firmware-zd1211

そして udev において無線 LAN のデバイス名を指定するファイルを編集して、以前 wlan0 となっていた項目を削除しました。

# /etc/udev/rules.d/70-persistent-net.rules

この状態で新しく使用する無線 LAN アダプタの WLI-U2-KG54L を接続すると、自動的に wlan0 として登録してくれました。

動作確認

監視カメラを設置する前に地上で動作確認を行いました。

HD-HLAN による監視カメラの動作確認です。

 

設置

動作確認が終わったところで、元通りに監視カメラを設置しました。

元通り玄関口へ設置し直しました。

 

参考記事

玄人志向 玄箱用 Debian Jessie wifi 対応版
https://densankiblog.wordpress.com/2016/04/01/%e7%8e%84%e4%ba%ba%e5%bf%97%e5%90%91-%e7%8e%84%e7%ae%b1%e7%94%a8-debian-jessie-wifi-%e5%af%be%e5%bf%9c%e7%89%88/

 

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 へアップグレード
https://densankiblog.wordpress.com/2016/05/26/freebsd-10-3-%e3%81%b8%e3%82%a2%e3%83%83%e3%83%97%e3%82%b0%e3%83%ac%e3%83%bc%e3%83%89/

 

経緯

元々は 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
..
..
..