2016年6月27日月曜日

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

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

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

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


2016年6月24日金曜日

Buffalo HD-HGLAN(二台目)へ Debian Jessie をインストール

二台目の HD-HGLAN へ Debian Jessie をインストールしました。

Debian Jessie のインストールに成功した二台目の HD-HGLAN です。

シリアルコンソールの設置

インストールの前に HD-HGLAN のボード上のシリアルコンソールの端子へピンヘッダを予めハンダ付けしておきました。一台目の HD-HGLAN と同じ要領です。
Buffalo HD-HGLAN へシリアルコンソールの端子設置
http://near-unix.blogspot.jp/2016/06/buffalo-hd-hglan_20.html
Debian Jessie をインストール中の HD-HGLAN です。

u-boot 1.2.0 の書き込み

u-boot の書き込みは、玄箱 HG のファームウェアから出来ないことが確認されています。そこで一台目の HD-HGLAN と同様に純正ファームウェアのアップデートに起動コードを u-boot 1.2.0 に置き換えたもので書き換えを行いました。
Buffalo HD-HGLAN へ Debian Jessie をインストール
http://near-unix.blogspot.jp/2016/06/buffalo-hd-hglan-debian-jessie.html#u-boot

Debian Jessie のインストール

Debian Jessie のインストールも一台目の HD-HGLAN と同じ方法でインストールしました。
Buffalo HD-HGLAN へ Debian Jessie をインストール
http://near-unix.blogspot.jp/2016/06/buffalo-hd-hglan-debian-jessie.html#debian-jessie-install

動作確認

問題なく起動して動作しました。一台目の HD-HGLAN のときのように LAN ポートの障害はありませんでした。これで Debian Jessie 化した HD-HGLAN が二台となりました。


Buffalo HD-HGLAN(二台目)へ純正ファームウェアのインストール(失敗)

バッファロー製 HD-HGLAN(二台目)へメーカ純正ファームウェアのインストールを試みましたが、失敗しました。

二台目の HD-HGLAN も純正ファームウェアのインストールに失敗しました。

はじめに玄箱 HG のファームウェア

一度、メーカ純正のファームウェアのアップデート失敗していました。その後、ファームウェアのアップデートを受け付けない状況となっていました。一台目の HD-HGLAN の時のように EM モードへ移行していなかったことから、玄箱 HG のファームウェアがインストールされているハードディスクを取り付けてみました。するとこの玄箱 HG のファームウェアで起動することができました。

ここでフラッシュメモリのバックアップを取得しようとしました。しかしなぜか /dev/fl* へのアクセスができませんでした。また u-boot を書き込んでみようと試みましたが、書き込むことができませんでした。

メーカ純正ファームウェア(1.65)のインストール失敗

玄箱 HG のファームウェアからフラッシュメモリへアクセスできないことが判明したため、直接 Debian Jessie へ移行してしまうことを諦め、一旦メーカ純正のファームウェアをインストールすることとしました。

しかし一台目の HD-HGLAN と同じ症状でファームウェアのアップデートができませんでした。一台目の HD-HGLAN には LAN ポートの異常があったことから、これが原因だと判断していましたが、間違っていたようです。原因は、別のところにあるようです。
Buffalo HD-HGLAN にメーカ純正ファームウェアのインストール(失敗)
http://near-unix.blogspot.jp/2016/06/buffalo-hd-hglan_15.html

以上のことが判明したことから、一台目の HD-HGLAN と同じ手順で Debian Jessie をインストールしたいと思っています。

Buffalo HD-HGLAN (二台目)のハードディスク検査

二台目となるバッファローの HD-HGLAN のハードディスクを検査しました。

二台目の HD-HGLAN に搭載されていたのはサムスン製 SV1604N でした。

ハードディスクの検査

筐体を開いてハードディスクを取り出してみると、運悪くサムスン製のハードディスク(SV1604N, 160GB)でした(涙)。 早速ハードディスクの検査用のデスクトップ・パソコンへ接続して検査を行いました。

検査中のサムスン製 SV1604N の様子です。

HGST の DriveFitnessTest では「異常なし」として検査終了しました。

そして各セクタの様子を検査するために MHDD でも検査しました。すると二箇所のセクタで 500ms という危険値が検出されていました。その他 3.5 インチ・ディスクとしては遅めの 50ms のセクタも 4133 個も検出されました。

SAMSUNG SV1604N の MHDD の検査結果

ちなみに一台目の HD-HGLAN に搭載されていたウェスタンデジタルの WD2500BB では、500ms 以上の異常値を示すセクタは無く、さらに 50ms の遅めのセクタもたった 37 個しかありませんでした。同時期に製造されたと思われるハードディスクですが、これだけ性能に差が現れてしまっています。

WDC WD2500BB の MHDD の検査結果

ハードディスクの消去

Debian Jessie のインストールに備えて、ハードディスクを綺麗さっぱりとゼロフィルして初期化しました。


2016年6月23日木曜日

Buffalo HD-HGLAN 二台目を入手

二台目となるバッファローの NAS 製品 HD-HGLAN(HD-HG160LAN)をインターネット・オークションにて入手しました。

手前が今回入手した二台目の HD-HGLAN です。

経緯

二台続けて HD-HGLAN を入手した理由は、一台目の HD-HGLAN の異常で、もしかするとフラッシュメモリを JTAG にて書き換える必要があるかもしれないと考えて、オリジナルのフラッシュメモリのデータを入手することを前提として入手したものでした。しかし、その後一台目の HD-HGLAN は、フラッシュメモリの起動コード部分を U-boot 1.2.0 へ書き換えることに成功し、無事 Debian Jessie をインストールすることに成功していました。そのため、この二台目の HD-HGLAN は当初の目的を失ってしまいました(笑)。

上段が二台目の HD-HGLAN です。

ファームウェアのアップデート(失敗)

現状のファームウェアのバージョンは 1.02 でした。そこで 1.65 へアップデートを行ってみました。

何と!ファームウェアのアップデートに失敗してしまいました(涙)。 一体どうしたことでしょう!

結果、アップデート・ソフトウェアから HD-HGLAN が見つけられなくなってしまいました。

以前の 1.02 で起動します

アップデート・ソフトウェアから見つけられないのですが、何故か普通に起動をして動作していました。ブラウザから HD-HGLAN へアクセスすると設定画面へたどり着くことができました。NAS としての動作もしていました。

どうもハードディスク内のファームウェアの書き換えに失敗した模様ですが、以前のファームウェアがそのまま残っていることからシステムが起動したようです。ファームウェアのアップデートを制御する部分だけが動作していない模様です。

ファームウェアのアップデートに失敗しながらも起動しました。

ハードディスクの初期化予定

どうもハードディスクを消去して EM モードで起動させると、ファームウェアのインストールができるのではないかと考えています。明日以降に行ってみたいと思っています。

この HD-HGLAN は、背面のネジが残っていることと、筐体の爪に傷がないことから、まだ未開封の個体のようです。



2016年6月22日水曜日

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


@nifty フォン-C の着信不良

注意:内容を全面的に記述しなおしました。次の記事を参照してください。
@nifty フォン-C の着信不良(全面書き換え)
http://near-unix.blogspot.jp/2016/06/nifty-c_27.html


我が家ではプロバイダとして使用している @nifty のサービスの一つの @nifty フォン-C (IP 電話)を使用しています。それも自宅サーバの中に設置してある Asterisk サーバから接続させていました。この IP 電話の番号へ着信が出来なくなっていました。何故か発信はできる状態でした。そして発信した直後だけは、着信が可能な状態となっています。

原因調査

Asterisk サーバを再起動させて @nifty フォン-C の SIP サーバ(我が家の場合 voip09.nifty.com)との接続状況を確認しました。
# asterisk -r
*CLI> sip show peers

念の為 sip.conf の @nifty フォン-C の設定に "qualify=yes" を付加して、具体的に応答していることを確認してみたところ、応答がありませんでした。
nifty-sip/ABCDEFGH        153.146.---.---
5060     UNREACHABLE


パケットフィルタの設定変更

ここで @nifty フォン-C の SIP サーバの IP が変更になっていることに気づきました。以前は 210.227.109.--- でした。このため NTT から貸し出されているフレッツ光 ホームゲートウェイ PR-400NE のパケットフィルタの設定も変更しなければならないことに気づきました。
光ネクスト隼 PR-400NE の設定
http://near-unix.blogspot.jp/2013/03/pr-400ne.html

PR-400NE のパケットフィルタの設定を新しい IP アドレスに合わせて変更しました。そして接続状況を確認しました。・・・しかし接続できませんでした。(訂正2016-06-26:接続できました。)

さらに PR-400NE のパケットフィルタを特定の IP アドレスの SIP パケット(5060)だけが通過できる状態から全ての IP アドレスからの SIP パケットが通過できるように変更しました。それでも接続できない状況に変わりありませんでした。

ドメイン名指定から IP アドレス直接設定へ

(注意:この IP アドレス直接指定はおすすめしません。voip09.nifty.com で接続できました。2016-06-26)
@nifty フォン-C の新旧の IP アドレスを whois コマンドや ping コマンドで調査してみると、まだ古い @nifty フォン-C の IP アドレスの SIP サーバは生きているようです。(注記:@nifty フォン-C と名前がついていますが OCN の IP 電話サービスを再利用しているようです。)

ドメイン名で指定された SIP サーバ(voip09.nifty.com)に問題があるのではないかと考えて、直接以前の SIP サーバへ接続できるように IP アドレスを sip.conf へ設定してみました。

-- sip.conf の @nifty フォン-C の設定部分 --
赤字の部分を ";" でコメント化
青字の部分を追加
[nifty-sip]
type=friend
secret=PASSWORD
defaultuser=ABCDEFGH
fromuser=05012345678
fromdomain=nifty.com
;host=voip09.nifty.com
host=210.227.---.---
context=nifty-in
dtmfmode=inband
canreinvite=no
insecure=port,invite
progressinband=no
qualify=yes

新しく設定した sip.conf を読み込ませて起動させました。すると SIP サーバと接続できました。応答もあります。そして @nifty フォン-C への着信も可能となりました。
# asterisk -r
*CLI> sip reload
*CLI> sip show peers

nifty-sip/ABCDEFGH        210.227.---.---
5060     OK (16 ms)

以上のことを確認した後、 PR-400NE で行っていたパケットフィルタの設定を元通りに特定の IP アドレス(210.227.---.---)の SIP パケット(5060)だけが通過できるように設定しました。

今後の事

IP アドレスの直接指定で着信出来ないという問題は回避することが出来ましたが、将来的にはドメイン名に戻したいと思っています。どうして SIP サーバが変更となり、接続(受信)出来ないのか? 今後どうなってしまうのか? 全く不明で不安です。