自宅サーバのハードディスク交換の予行演習

今まで何度か行なってきた自宅サーバ(FreeBSD)のハードディスクの交換ですが、いろいろと作業に手間取り、データの移行作業が出来ないままの状態となっています。少なくとも来週の休日まで延期となりそうです。とりあえず移行作業の目処が立ちましたので、移行作業の予行演習として、模擬的に作ったコピー元のハードディスク( Hitachi HDS723020BLA642 )から移行先のハードディスク( WDC WD20EZRX )へコピーを行なってみました。今日はここまでの作業でした。

上手く移行作業が出来なかった原因は、はっきり言って、移行先のハードディスクの WDC WD20EZRX を 4KB/セクタできっちりとパーティション切りが出来なかったためです。

現在使用中のハードディスクは従来からの 512B/セクタのものでした。またパーティションも MBR の標準通りの 63 ブロックから始まるパーティションで設定がしてあって、単純にハードディスク間で dd コマンドでイメージコピーをすれば完了する状態ではありませんでした。

現状のハードディスクのパーティション状況

もちろんこの 4KB/セクタを無視し、 AFT 機能を存分に活かして動作させる方法もあります。今回のように大量のデータをコピーするには 4KB/セクタでパーティションを区切ったハードディスクに比べて3倍程度の時間は掛かると思いますが、一応は動作するはずです。

しかしこの時間のロスや、将来再びやってくるであろうハードディスクの交換に備えて現時点で 4KB/セクタで対応したパーティション切りをしておきたいと思いました。

まず今回最も問題となったのが、FreeBSD 9.2 の標準のインストーラ(bsdinstall)でのパーティション設定でした。シェル上で手動により設定する他ありませんでした。一応、GUI での設定ツールにおいても複数のパーティショニングを行うことができて、それも割り当てられた領域のブロック数が8で割れる 4KB/セクタに対応できるような状態でした。しかし先頭のパーティションの位置が 4KB/セクタの区切りではない場所から始まっていることから全体のパーティションの区切りもずれた状態となっていました。これでは本来のハードディスクの読み書きの性能が得られません。

# gpart show
=>        63  3907029105  ada0  MBR  (1.8T)
          63          63        – free –  (31k)
         126  3906994077     1  freebsd  [active]  (1.8T)
  3906994203       34965        – free –  (17M)
赤字で表示した freebsd のパーティションの開始位置 126 が 8 で割り切れないブロック位置から開始していることが問題なのです。ちなみに1ブロック512バイトです。
=>         0  3906994077  ada0s1  BSD  (1.8T)
           0     1048576       1  freebsd-ufs  (512M)
     1048576     2097152       2  freebsd-swap  (1.0G)
     3145728     4194304       4  freebsd-ufs  (2.0G)
     7340032     1048576       5  freebsd-ufs  (512M)
     8388608  3898605468       6  freebsd-ufs  (1.8T)
  3906994076           1          – free –  (512B)

手動でパーティションを設定するときに使うコマンドで -b オプションによってパーティションの開始ブロック位置の調整ができるようになっていますが、この gpart のコマンドのバグなのか仕様なのかはよく解りませんが、63 ブロック単位でまとめられてしまう癖があり、4KB/セクタの区切りの良い場所でパーティションが設定出来ない状態となっていました。例えば bsdinstall の標準で割り当てられる最初のパーティションの開始ブロックは 126 ブロックとなっています。しかしこれを8で割り切れる 128 ブロックに指定しても、やはり 126 ブロックから開始とするなどと理由のわからぬ位置で区切ってしまうのです。さらに Linux などでよく使われる 2048 ブロックを開始位置にしようとしても 2048 ブロックから配置してくれないのです。

gpart コマンドでのパーティション設定例

MBR 形式でハードディスクを初期設定します。
# gpart create -s mbr /dev/ada0
ada0 created

FreeBSD に割り当てるパーティションの先頭を 504 ブロックとした例です。
# gpart add -a 4k -b 504 -t freebsd /dev/ada0
ada0s0 added

ネット上を検索しながら彷徨っていると、開始ブロックを 504 ブロックから開始すると調度良い区切りができるという情報を得て、ようやく 4KB/セクタに対応したパーティション区切りができました。

# gpart show
=>        63  3907029105  ada0  MBR  (1.8T)
          63         441        – free –  (220k)
         504  3907028601     1  freebsd  [active]  (1.8T)
  3907029105          63        – free –  (31k)
青字で表示した freeBSD のパーティションの開始位置が 504 ブロックと 8 で割り切れるブロックからの開始となりました。

=>         0  3907028601  ada0s1  BSD  (1.8T)
           0     1048576       1  freebsd-ufs  (512M)
     1048576     2097152       2  freebsd-swap  (1.0G)
     3145728     4194304       4  freebsd-ufs  (2.0G)
     7340032     1048576       5  freebsd-ufs  (512M)
     8388608  3898639992       6  freebsd-ufs  (1.8T)
  3907028600           1          – free –  (512B)

ここままで時間をかなり使い果たしてしまいました。データの移行作業は12時間以上の時間が掛かるため、今回の休日での作業は断念となりました。

そこで来週に備えて、以前データの移行作業で使ったシェル・スクリプトの見直しをしました。そして手持ちの空きハードディスクへ新規に FreeBSD 9.2 をインストールして、この仮設のハードディスクから移行先となる WDC WD20EZRX へデータを転送してみました。そして起動まで正しく行えることを確認してみました。
新規に FreeBSD をインストールしたてのため、システムのみの小容量のデータなのでさほどデータに転送の時間が掛かりません。何度かデータの転送を繰り返してみて、データ転送用のスクリプトを試験・調整を行なっておこうと思っています。

データ転送試験の様子です。
手前が仮設のシステムディスクです。
奥がデータの転送先となる新しいハードディスクです。

参考
前回のハードディスクの交換の様子の記事はこちらです。
http://near-unix.blogspot.jp/2011/03/blog-post.html

FreeBSD Asterisk 1.8.28.2_1 へアップデート

FreeBSD の ports に asterisk 1.8.28.2 から Asterisk 1.8.28.2_1 へのアップデートが到着していました。

いつものように、さっくりと portupgrade で更新しておきました。我が家での動作は問題ありませんでした。

asterisk 1.8.28.2_1 のビルド設定画面です。

WestanDigital WD20EZRX 2.0TB を購入

我が家では珍しく新品でハードディスクを購入しました。自宅サーバのハードディスクがそろそろ三年になろうとしているため、故障してしまう前に新しいハードディスクへ交換をしようと考えたからです。もちろん交換してしまえば、電源を入れっぱなしとなるため、新品以外に考えられませんでした(笑)。

いつも好んで購入していたのは、日立というか HGST のものでした。しかし最近ではまだ出回っているのか不明ですが、いわゆる安価な価格帯で並ぶ商品ではないようです。結局悩むことなく、某世界最大級と言われているネットショップから一番安価なものを選びました。

それがこの WestanDigital WD20EZRX 2.0TB でした。 現在使用しているハードディスクの容量が 2.0TB のもので、まだ 70% 程度の使用率のため、増量することなく現状の容量を維持したまま交換することとなりました。

WestanDigital WD20EZRX のストレス・フリー・パッケージです。
しっかりとしたダンボールで出来た箱で、これなら普通のパッケージ品よりしっかりした梱包ではないかと思いました。

ただ気になることは、現在のハードディスクは 512バイト/セクタの製品で、新しいものは 4,096バイト/セクタのものとなっています。そのため、単純に dd コマンドでイメージ・コピーをするわけには行かないようです。もしかすると前回の交換の時に意識して 4Kバイト区切りでパーティションを切っているかもしれませんが、あまり期待しない方が良さそうです。

ハードディスクの試験専用に用意してあるパソコンに繋いでテストを行いました。
長時間の試験で発熱も心配されることから、ちゃんと冷却ファンで空冷をしました。

さて購入したハードディスクですが、WestanDigital 謹製のハードディスク・試験ソフトウェア(Data Lifeguard Diagnostic)で早速試験をしてみました。問題なく終了して、輸送中の障害も無かったようです。

ついでに HGST の試験ソフトウェア(DriveFitnessTest)でもテストを行なってみましたが、やはり問題はありませんでした。

問題は、コピー作業に12時間程度の時間が掛かると予想しています。この作業中に一切の仕事を止めて作業をする訳にもいかず、代替のサーバを用意して作業をしようと思っています。自宅 LAN 内の DHCP, DNS, Web, SMTP, IMAP, Asterisk の部分だけを一時的に移植してみようと思っています。

休日の日曜日にコピー作業を予定していますが、上手くゆくことやら・・・。

おまけの画像
2ch で「WD20EZRX 00D8PB0」の話題を検索してみるともちろんありました。重さが 600 グラム程度で二枚プラッタを使用しているらしいのですが、私の手元にあるものは 630 グラムでした。微妙に重たいのですが誤差の内でしょうか(汗)。

WestanDigital WD20EZRX 2.0TB 00D8PB0 の重さ 630 グラム

Debian Wheezy の Cups で {job_originating_user_name} と表示される件

ちょっと以前から気になっていた Debian Wheezy の Cups で印刷を指示したユーザー名や文章名などが表示されず {job_originating_user_name} という表示になっていた件をネット上で検索して対策しました。

印刷文章名が「未知」、
ユーザー名が{job_originating_user_name}となっています。

次の URL を参考にしました。
cups: joblist displays {job_originating_user_name} instead of real username
https://bugs.launchpad.net/ubuntu/+source/cups/+bug/890644

問題を対策するには、/etc/cups/cupsd.conf を修正する必要がありました。JobPrivateValues という変数を default から none へ変更します。同じ変数が二箇所に出てきますので、どちらも同様に修正します。

JobPrivateValues default
     ↓
JobPrivateValues none

この修正が終了したところで、cupsd を再起動させます。

# /etc/init.d/cups restart

以上で再度 Cups 経由で印刷を行ったとき、 {job_originating_user_name} と表示されず、本来のユーザー名が表示されれば成功です。「完了したジョブを表示」をクリックして過去の印刷結果を表示させると、{job_originating_user_name} の部分がちゃんとユーザー名に変わっているはずです。

ちゃんとユーザー名の表示をしてくれました。

FreeBSD 9.2 p9 へアップデート

FreeBSD 9.2 へ p9 アップデートが到着していました。

# svn update /usr/src
Updating ‘/usr/src’:
U    /usr/src/contrib/file/Magdir/commands
U    /usr/src/contrib/file/file.h
U    /usr/src/contrib/file/ascmagic.c
U    /usr/src/contrib/file/softmagic.c
U    /usr/src/contrib/file/funcs.c
U    /usr/src/UPDATING
U    /usr/src/sys/conf/newvers.sh
U    /usr/src/crypto/heimdal/lib/gssapi/krb5/prf.c
Updated to revision 267868.

アップデートの内容は以下のとおりです。

20140624:       p9      FreeBSD-SA-14:16.file
                        FreeBSD-EN-14:08.heimdal

Fix multiple vulnerabilities in file(1) and libmagic(3). [SA-14:16]
http://www.freebsd.org/security/advisories/FreeBSD-SA-14:16.file.asc

Fix gss_pseudo_random interoperability issue. [EN-14:08]
http://www.freebsd.org/security/advisories/FreeBSD-EN-14:08.heimdal.asc

セキュリティ対策一点とエラー対策一点の合計二点のアップデートとなっています。なお FreeBSD 10 には、この他にも更に二点の対策が含まれています。詳しくは FreeBSD 公式ウェブサイトをご覧ください。

どちらもユーザーランドの再構築を行うように指示があります。カーネルのバージョン番号も一緒に引き上げておきたいので、私はユザーランドもカーネルも再ビルドしておきました。アップデート後の動作に問題はないようです。

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

Debian Wheezy LXDE で PDF リーダーと関連付け

Debian Wheezy LXDE をインストールしている ThinkaPad X31 へ PDF リーダーをインストールしました。

なぜか LXDE をインストールした時には PDF リーダーが事前にインストールされていませんでした。PDF リーダーもいろいろある中、Gnome でもおなじみの Evince をインストールすることとしました。他の gnome のデスクトップがインストールされているマシンと同じ条件で表示されるものの方がよいと考えたからです。

インストールは簡単でいつものように aptitude コマンドでさっくりとインストールしました。

# aptitude install evince
以下の新規パッケージがインストールされます:
  evince evince-common{a} libdjvulibre-text{a} libdjvulibre21{a}
  libevdocument3-4{a} libevview3-3{a} libgxps2{a} libkpathsea6{a}
  libnautilus-extension1a{a} libspectre1{a} libt1-5{a}
更新: 0 個、新規インストール: 11 個、削除: 0 個、保留: 0 個。
8,537 k バイトのアーカイブを取得する必要があります。展開後に 21.5 M バイトのディスク領域が新たに消費されます。
先に進みますか? [Y/n/?] 

インストール完了後、PDF ファイルを読み込んで表示させてみたり、先日整備したプリンタ環境を使って印刷も行なってみました。どちらも問題ありませんでした。

しかし気になることが…。

それは LXDE 標準のファイラーである PCManFM の関連付けでした。PCManFM で PDF ファイルをダブルクリックすると、画像編集ソフトウェアの Gimp が起動してしまうのです。PDF ファイル上で右クリックをして起動させるソフトウェアを選択してファイルを開くことも可能ですが、いまいち使い勝手がよくありません!

そこで関連付けを見直すこととしました。

と言っても関連付けの作業は簡単です。 PDF ファイルを右クリックで選択した後、「アプリケーションで開く」を選択して、改めて「ドキュメントビューア」の Evince を選択して、更にダイアログボックスの左下にある「選択したアプリケーションをこのファイルタイプのデフォルトのアクションとする」にチェックマークを入れるだけです。次回からはダブルクリックで Evince で PDF ファイルが開くようになります。

同様にして画像ファイルの PNG ファイルなども Gimp が起動するようになっているので、同様にしてイメージビューアの GPicView を関連付けすれば使いやすくなると思います。