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

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 対応版
http://near-unix.blogspot.jp/2016/04/debian-jessie-wifi.html

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

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

Partimage サーバの使い方

先日、我が家のファイルサーバのハードディスクを交換しました。このファイルサーバでは、Samba を稼働させていますが、その他に Partimage サーバも稼働させて、パソコンのパーティション単位でのファイルのバックアップも行っています。

ファイルサーバ用ハードディスクの複写
http://near-unix.blogspot.jp/2016/05/blog-post.html

今回、久しぶりに Partimage サーバを使って、パーティションを保存しようとしたところ、操作方法をすっかり忘れてしまっており、大変苦労しました（苦笑）。そこで、その操作方法を備忘録として記事にしました。これでたまに行うパソコンのバックアップも安心です！

概要

Partimage の使い方は、パソコンへ USB ドライブなどを装着して、そのドライブへ保存する方法が一般的です。今回は、外部に Partimage サーバを起動させて、その外部サーバへ LAN 経由で保存するものです。

Partimage
https://www.partimage.org/Main_Page

この記事では、Partimage サーバのインストール＆設定を行った後、データのバックアップを行うパソコン上で行う Partimage クライアントの記述を行います。なおマシンは Debian Jessie が稼働していることを前提としています。

そしてこの記事では、バックアップ部分について記述しています。バックアップしたデータを元のパソコンへ戻すリストア操作については割愛しました。

Partimage サーバ

Partimage サーバをインストールしました。

# aptitude install partimage-server

Partimage サーバがデータを保存する初期値のディレクトリ（/var/lib/partimaged/）を変更します。我が家のファイルサーバの場合、下記の /home/disk1/partimaged/ へ変更しました。

# vi /etc/default/partimaged

- 変更内容-
TARGET=/var/lib/partimaged/
　　　　　　↓↓↓
TARGET=/home/disk1/partimaged/

Partimage サーバの保存先ディレクトリを作成しました。

# madir /home/disk1/partimaged
# chown partimag:partimag /home/disk1/partimaged
# chmod 750 /home/disk1/partimaged

正しく保存先ディレクトリが作成されたか？ ls コマンドで確認しました。

# ls -l /home/disk1/partimaged
drwxr-x---  2 partimag partimag  4096 2010-08-08 03:13 partimaged

Partimage サーバへユーザ登録しました。

# vi /etc/partimaged/partimagedusers

- 編集内容　"user" を追加した事例 -
# Add all users which shall be allowed to connect to the partimage server.
# One user per line. See "man partimagedusers" for more information.
user

Partimage サーバを起動させました。

# partimaged

Partimage サーバを起動させると次のようなコンソール画面が表示されます。そして、[ * ] キー終了させることができます。

Partimage サーバのコンソール画面

Partimage クライアント

Partimage のクライアントをインストールしました。

# aptitude install partimage

Partimage クライアントを起動させました。

# partimage

Partimage の設定画面

ここでは NTFS フォーマットされている sda1 パーティションをバックアップすることとしました。[Tab] キーで次の項目へ移動させます。

[Image file to create/use]  の項目で保存先のファイル名を指定します。この場合、ディレクトリを含めて指定します。

そしてバックアップ先に Pertimage サーバがしているマシン（ホスト名、または、IP アドレス）を指定しました。詳しくは、設定画面を参考にしてください。

Partimage サーバを指定した設定画面

[F5] キーで次のページへ移行します。ここで Partimage サーバのユーザ名とパスワードを入力します。パスワードの部分では、入力した文字は表示されません。[Tab] キーで [OK] へ移動した後、[Enter] キーで確定します。

ユーザとパスワードの入力画面

ユーザ認証に合格するとバックアップの設定項目が表示されます。
"Compression level" （圧縮強度）は、初期値の "Gzip" をお奨めします。
"Image split mode" （ファイル分割）は、"Automatic split" をお奨めします。保存先の容量が存在するかぎり、単一のファイルで保存してくれます。もともとここの設定は、CD-ROM や DVD などへ保存するときに、バックアップ・ファイルを分割しながら保存することを前提としているものです。

バックアップ方法の設定画面

[F5] キーで次のページへ移行します。ここでは、どのようなバックアップを行ったのかを自由に記述することができるメモの部分です。適宜記述した後、[OK] で次のページヘ移行します。

バックアップのメモの記述

保存元のパーティションが NTFS のときには、"experiment" （実験的なもの）として注意喚起が行われます。ここも [OK]  で次へ進みます。

NTFS フォーマットの注意喚起画面

保存するパーティションや保存先について、最終確認を行います。ここも [OK]  で次へ進みます。

保存内容の最終確認画面

最終確認が終わるとバックアップを開始します。バックアップ中は、終了までの予測時間が表示されます。

バックアップ中の画面

バップアップが終了したところで、[OK] をクリックすると、Partimage クライアントは終了します。そして Partimage サーバも [ * ] キーで終了させました。

バックアップ終了の画面

Windows マシンの NTFS パーティションのバックアップ

Debian などの Linux をインストールしてデュアル・ブートができるようになっていない Windows マシンでは、Linux ライブ CD を使って Partimage クライアントを起動させて、バックアップさせることができます。

ただし大切な条件が一つあって、それは Partimage クライアントとサーバのバージョンが同一である必要があります。上記の Debian Jessie の場合のバージョンは 0.6.8 となっています。一部の Linux では 0.6.9 をよく見かけます。バージョン確認を事前に行っておく必要があります。0.6.9 のクライアントから 0.6.8 のサーバへの保存は拒否されました。

Debian Jessie 上に Partimage サーバ（0.6.8）を稼働させている場合には、GParted Live CD を使用することをお奨めします。この GParted Live CD の Partimage クライアントのバージョンも 0.6.8 となっています。

GParted -- Live CD/USB/PXE/HD
http://gparted.org/livecd.php

GParted Live CD を起動させると GParted が自動的に起動されます。この GParted を終了させて、端末ソフトウェアを起動させた後、sudo コマンドと一緒に Partimage を起動させます。その他の操作は、上記の Partimage クライアントと同一です。

# sudo partimage

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

PT2 サーバのハードディスクの冷却ファン取り付け

屋外の最高気温が30度を超えるようになってきました。もちろん室内も屋外ほどでないにしろ、結構気温が上昇しています。暑くなってくると気になるのが、ハードディスクの温度です。FreeBSD で稼働している自宅サーバ（FMV ESPRIMO D5220）には、すでに CD ドライブベイの部分へ冷却ファンを取り付けてハードディスクの温度上昇を抑制していました。今回は、自宅サーバの隣に設置してある PT2 サーバ（FMV ESPRIMO D5210）にも冷却ファンを取り付けて、ハードディスクの温度上昇を抑制するようにしました。

ハードディスク用の冷却ファンを取り付けた FMV ESPRIMO D5210 です。

冷却ファンの取り付け

昨年の夏は、PT2 サーバにも小さな冷却ファンを取り付けていましたが、秋ごろには騒音が激しくなったことから取り外してしまいました。そこで今回も以前と同じように CD ドライブベイの部分へ冷却ファンをネジで固定しました。ハードディスクとの間には穴が無数に開いた状態となっており、この穴から風を送り込んでハードディスクの表面温度を下げるようにします。またこの穴を使って冷却ファンを固定しました。

CDドライブベイへ取り付けた冷却ファンです。

ハードディスクと冷却ファンの位置関係がよく解るように撮影したものです。
冷却ファンの風はハードディスクへ吹き付けるように設置しました。

冷却ファン用電源ケーブル

冷却ファンの電源ケーブルの先端は 3 ピンコネクタとなっています。一般的なパソコン用電源から分岐させるケーブルなどがありますが、このケーブルでは 12 ボルトが供給されるようになっており、冷却ファンがかなりの高速回転をしてしまいます。そこで 5 ボルト電源を供給するケーブルを自作して、回転数を下げる工夫をしました。

作業は簡単で、4 ピンの電源コネクタと 3 ピンのピンヘッダの間をケーブルで接続するだけの簡単なものです。

ピンヘッダは、小さな蛇の目基盤へ一旦ハンダ付けしたあとにケーブルをハンダ付けしました。

冷却ファンへ 5 ボルト電源を供給するケーブルを作ったところです。

端子の部分が剥き出しになっているため、テープで簡単に絶縁処理を施しておきました。

冷却ファンへ 5 ボルト電源を供給するケーブルを接続したところです。
パソコン用電源のケーブルのうち 5 ボルトは赤色のケーブルで、
黄色のケーブルは 12 ボルトになっています。

これで回転数が抑えられた状態で冷却ファンが回転するようになりました。冷却ファンの騒音も気になりません。これで今年の夏を乗り切りたいと思っています。

ファイルサーバのハードディスクのエラーの原因は

先日ハードディスク（WD20EARX）の不調のため交換を行ったファイルサーバですが、再び調子が悪くなってしまいました。原因を調べてみると SATA ケーブルに問題がありました。

ファイルサーバ用ハードディスクの複写
http://near-unix.blogspot.jp/2016/05/blog-post.html

症状

交換したばかりの 2TB のハードディスク（WD20EZRZ）から DMA エラーが発生しているログが次々とコンソール上に表示されていました（涙）。

マザーボードが 1.5Gbps までの速度しか対応していないため、もしかして上手く動作切替ができていないのかしれないと考えて、ハードディスクの側面にあるショートジャンパの 「1.5Gbps 制限動作」の設定を行ってみました。しかし症状は変わりませんでした。

1.5Gbps に制限した WD20EZRZ です。
この写真では SATA ケーブルは交換済みです。

原因は SATA ケーブル

原因を探ると SATA のケーブル（写真の青いケーブル）に問題があったようで、このケーブルで接続するハードディスクのデータ転送が不調となってしまうことが判明しました。

問題があった SATA ケーブル

不調だと思って交換した古い 2TB のハードディスク（WD20EARX）は、すでにデータ複写用のマシン上で検査を行って異常がないことを確認していました。そのため、今回のせっかくハードディスクを交換したのですが、不調の原因は SATA ケーブルに問題があったようです（苦笑）。

新しい SATA ケーブルへ交換したところ、 DMA エラーなどは発生せず、順調に動作しました。これからは、ケーブルにも注意を払いたいと思いました。

自宅サーバのハードディスク交換作業

FreeBSD で稼働している自宅サーバ（FMV ESPRIMO D5220）のハードディスクを交換しました。

左側のマシンが自宅サーバの FMV-ESPRIMO D5220です。
右側のマシンは、データ複写用マシンです。

経緯

自宅サーバの前回のハードディスク交換は、2014 年 7 月でした。それからおよそ2年が経過していました。我が家のメールや電話など多くの機能がこの自宅サーバに詰まっているため、故障する前に交換することとしました。

自宅サーバのハードディスク交換の予行演習
http://near-unix.blogspot.jp/2014/06/blog-post.html

自宅 FreeBSD サーバの HDD 交換
http://near-unix.blogspot.jp/2014/07/freebsd-hdd.html

準備

昨日までに交換する新しいハードディスクの検査などを終えて、準備を整えていました。なおヘッドの自動待避機能は、WDIDLE3 によって 8 秒から 300 秒へ変更しておきました。

自宅サーバ用ハードディスク（2TB）の交換の準備
http://near-unix.blogspot.jp/2016/05/blog-post_21.html

データ複写

FreeBSD による UFS フォーマットを行った現状の（古い）ハードディスク（WD20EZRX）から新しいハードディスク（WD20EZRZ）へ移行させました。この二つのハードディスクは、型番は異なりますが、基本的な仕様は同一のものです。

前回のハードディスクの交換の再、 4KB/セクタのハードディスクへ対応するために、アライメント（Alignment） 調整を済ませていました。そのため、今回のデータ複写は、単純なイメージコピーで行いました。（訂正2016-05-23： GPT への対応の部分を削除しました）

二年ほど前に設置した WD20EZRX です。

データ複写用に用意したデスクトップ・パソコンへ、新旧のハードディスクを設置した後、GParted Live CD を使って立ち上げました。自動的に起動する GParted を使って、新旧のハードディスクのデバイス名（/dev/sda、/dev/sdb）を確認しました。一旦、GParted を終了させた後、端末ソフトウェアから ddrescue コマンドによってデータの複写を行いました。

GParted -- Live CD/USB/PXE/HD
http://gparted.org/livecd.php

GParted Live CD 上では ddrescue コマンドを実行させるには sudo コマンドも必要でした。実際に指定した ddrescue  コマンドのオプションは次のとおりです。リトライ回数は 3 回に設定しています。

sudo ddrescue  -d  -f  -r 3  -b 4096  /dev/sda  /dev/sdb

古いハードディスク　（WD20EZRX）：/dev/sda
新しいハードディスク（WD20EZRZ）：/dev/sdb

なお実際の作業は、上記の ddrescue のコマンドを実行した後、すぐに Ctrl + C によって複写を停止させた後、GParted を再度立ち上げて、新品の /dev/sdb のハードディスクのヘッダ情報（パーティション情報）が書き換わっていることを確認しました。これは間違って逆方向にデータを複写していないことを確認するためでした。そして、GParted  を再度終了させた後、端末ソフトウェアから ddrescue コマンドで複写をハードディスクの先頭部分から最後まで行いました。

データ複写作業中の様子です。

GParted Live CD 上で ddrescue コマンドで複写を行いました。

複写終了

深夜から開始して、早朝明るくなるまでの約 6 時間ほどで、複写は終了しました。もともと正常に動作していたハードディスクですので、複写作業中に問題は発生しませんでした。そしてすぐに自宅サーバのマシンへ装着して動作確認を行いました。正常に起動を開始して、自宅サーバは再び息吹を吹き返しました。

データ複写中は冷却ファンでハードディスクを冷やしていました。

自宅サーバ用ハードディスク（2TB）の交換の準備

昨日、ファイルサーバのハードディスクの複写を行い、無事交換を行うことができました。そして本日は、自宅サーバのハードディスクの交換の準備を行いました。

ファイルサーバ用ハードディスクの複写
http://near-unix.blogspot.jp/2016/05/blog-post.html

準備作業

準備の内容としては、新品のハードディスク（WD20EZRZ）の検査を行っただけでした（笑）。ウェスタンデジタル製の検査ソフトウェア（Data Lifeguard Diagnostics）で５時間ほど時間を掛けて、しっかりと検査を行いました。

ハードディスクの試験を行っているところです。

Data Lifeguard Diagnostics で検査が終了したところです。

そして WDIDLE3 により、ヘッドの自動待避機能の待避開始時間を８秒から３００秒（５分）へ変更しました。

WDIDLE3 を使ってヘッドの待避時間を調整しました。

交換の予定

メールなどのやり取りがほとんどない深夜からハードディスクの交換作業（複写）を行いたいと思っています。

自宅サーバには、システムに FreeBSD がインストールされており、ファイルシステムに UFS を使用しています。以前のようにダンプ＆リストア方式で複写を行わず、ddrescue によってハードディスクのイメージ・コピーによって複写を行う予定です。既に前回の複写のとき 4K セクタのハードディスク用にアライメント（Alignment）調整を行っていますので、ddrescue によるイメージ・コピーで問題なく動作すると思っています。この ddrescue によるイメージ・コピーによりファイルサーバと同じく６時間〜７時間の作業で終了すると見込んでいます。なお前回のダンプ＆リストア方式の場合は、１６時間ほどでした。

自宅サーバのハードディスク交換の予行演習
http://near-unix.blogspot.jp/2014/06/blog-post.html

自宅 FreeBSD サーバの HDD 交換
http://near-unix.blogspot.jp/2014/07/freebsd-hdd.html

ファイルサーバ用ハードディスクの複写

2011 年 8 月よりファイルサーバ用に使用していたハードディスク（2TB, WD20EARX）に不調が発見されたことから、新しく購入したハードディスク（2TB, WD20EZRZ）へデータ複写をしました。

一部にデータエラーが発見された 2TB のハードディスク（WDEARX）です。
2011-08-30 の書き込みがあることから、この日から使用を開始した模様です。

ファイルサーバとして使用していたマシンの様子です。
2TB と 3TB のハードディスクを装着しています。

複写作業

デスクトップ・パソコンへ古いハードディスク（WD20EARX）と新しいハードディスク（WD20EZRZ）を接続して、Linux 環境から ddrescue コマンドによってハードディスクの複写を行いました。

左側が古いハードディスク（WD20EARX）で
右側が新しいハードディスク（WD20EZRZ）です。

ddrescue コマンドの特徴

ddrescue コマンドでの複写は、いわゆるディスクイメージの複写となります。全域を複写した場合には、同じ内容のハードディスクがもうひとつ出来上がることとなります。

そして ddrescue コマンドは、データの読み取りができない場合には、再度指定した回数まで繰り返して読み込みを行って、できる限りデータを救出する動作をします。動作不良となったハードディスクからデータを救出する場合には、一般的な dd コマンドよりも ddrescue を使用した方がデータの救出率が高まります。昨年、テレビ録画用に使用していたハードディスクからデータを救出したときにも ddrescue コマンドを使用しました。

PT2 サーバのハードディスクの複写
http://near-unix.blogspot.jp/2015/07/pt2_22.html

PT2 サーバのハードディスクの複写終了
http://near-unix.blogspot.jp/2015/07/pt2_26.html

ddrescue で複写

複写をする場合、データの取り扱いを標準の 1 セクタあたり 512 バイトから、4096 バイトへ変更して作業を行いました。これはもちろんアドバンスド・フォーマットにより、 1 セクタあたりのバイト数がどちらでも読み書きができるのですが、4096 バイト単位であれば、より効率的に複写ができるためです。

実際に指定した ddrescue  コマンドのオプションは次のとおりです。リトライ回数は 3 回に設定しています。

ddrescue  -d  -f  -r 3  -b 4096  /dev/sda  /dev/sdb

古いハードディスク　（WD20EARX）：/dev/sda
新しいハードディスク（WD20EZRZ）：/dev/sdb

ddrescue で複写中の様子です。

作業時間

概ね６時間３０分ほどの作業時間を必要としました。この作業時間は、もう一台の新しいハードディスクの複写作業の時間の見積もりに助かります。

[追記] ハードディスクの装着

複写の終わったハードディスクをファイルサーバへ装着しました。動作確認も行いましたが、問題なく動作していました。これから数年間、ファイルサーバとして頑張ってもらいます。

下の段のハードディスクが今回交換した WD20EZRZ です。

Western Digital ハードディスク WD20EZRZ を購入

ウェスタンデジタルの 2TB ハードディスク（WD20EZRZ）を二台購入しました。

購入したハードディスクには青いラベル（Blue）が貼り付けられていましたが、従来からある同社の緑色のラベル（Green）のものと中身は同等のものだそうです。そのためヘッドの自動待避機能も８秒で動作するそうです。使用を開始する前に５分へ変更する予定です。

今回入手したウェスタンデジタルの WD20EZRZ の梱包箱です。

ウェスタンデジタルの WD20EZRZ を取り出したところです。

梱包状態

最大手の通販会社より入手しました。ちょっと心配なこととして、ユーザの評価欄に通販会社からの発送方法に問題が指摘されていました。ハードディスクのような精密機器にも係わらず、簡易包装のまま郵便ポストに投函する方法で配達されていたことを問題視していました。幸い我が家では、二台まとめて購入したこともあってか、大きなダンボール箱へ圧着フィルムで固定するという標準的な方法で送り届けられました。

簡易包装ではなく、ダンボール箱で届きました。

経緯

ハードディスクを購入した経緯は二つあります。一つは、ファイルサーバとして活躍しているマシンのハードディスク（2TB）を検査してみると問題があることが発見されたためです。もう寿命に達したようで、交換の必要がありました。

もう一つは、現在自宅サーバとして使用しているマシンのハードディスク（2TB、WD20EZRX）を前回交換してから２年が経過しようとしていることから、問題が発生する前に交換しておきたかったからです。

自宅 FreeBSD サーバの HDD 交換
http://near-unix.blogspot.jp/2014/07/freebsd-hdd.html

ハードディスクの検査

現在のところ、ハードディスクの交換に向けて、届いたハードディスクの検査（Data Lifeguard Diagnostic）を行っています。長く使用するものですので、使い始めだけはしっかりと検査をしておきました。

冷却ファンでハードディスクを冷やしながら検査を行いました。

ハードディスクのの検査の様子です。

2TB で５時間程度の掛かりました。

WDIDLE3 でヘッドの待避時間調整

DOS プログラムの WDIDLE3 を使って、ハードディスクのヘッドの待避時間を調整しました。初期値の 8 秒から 300 秒（5 分）へ変更しました。

- 300 秒へ設定 -
wdidle3 /s300

- 設定値の確認 -
wdidle3 /r

WDIDLE3 でヘッドの待避時間を調整しているところです。

今後の予定

すでに問題が表面化しているファイルサーバのハードディスクから交換をしたいと思っています。

Yahoo! ジャパンが２０周年だそうです

最近はめっきり使用することの無くなった Yahoo! メールへログインをしてみると、Yahoo! ジャパンが２０周年を記念した特別企画を知らせる案内が来ていました。

下図のように私は、Yahoo! メールのアカウントを作って１４年が経過しているそうです。Yahoo! メールは、どうも１９９９年１月６日から正式に開始されていたようです。

かつては迷惑メールの発信基地として活用されたり、大量の広告メールにうんざりさせられてきた Yahoo! メールですが、こうした時間の経過をみると、メールサービスそのものが遺産化しつつもまだ健在なことに感慨ひとしおです（笑）。

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

Debian ImageMagick 関連のアップデート

Debian Jessie に画像処理ソフトウェアの ImageMagick 関連のソフトウェアのアップデートが到着しました。意外と大量のアップデートに驚きました。こんなに ImageMagick って使っていたのですね（笑）

ImageMagick 関連のアップデート通知

FreeBSD OpenVPN 2.3.11 へアップグレード

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

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

Debian Vivaldi （ヴィヴァルディ）ブラウザのアップデート

Linux 版の Vivaldi （ヴィヴァルディ）ブラウザがアップデート（1.1.453.52-1 から 1.1.453.59-1 へ）しました。

前回の Vivaldi のアップデートが５月２日でした。二週間ほどで新しいアップデートが到着しています。頻繁にアップデートが行われているようです。

Vivaldi ブラウザのバージョン情報