ここの所FreeNASの記事が続きますが、嵌っているからです。嵌るのはWeb GUIの枠を外れたことをしようとするからで、そんなことをしなければFreeNASは便利だと思いますよ。

で、今回はSubversionサーバ機能を載せようと。サーバ機能自体はJailを作ってそこに任せるのですが、外からはFreeNASのIPアドレスでアクセスさせたい(というか外向けのIPアドレスが1個しか取れない)のでFreeNAS→Jailのポートフォワードを設定しようと。

ここでUSBメモリ上のFreeNASということで以下の方針を採ります。

• /の書き換えは最小限にする。できればやりたくない。やるなら/conf/base/etc/rc.confだけにする。理由はリードオンリーでマウントされているのを解除して作業する心理的抵抗感と、FreeNASのバージョンアップなどで変更を帳消しにされるから。タスクのInit/Shutdown scriptはFreeNASの設定として保存できるのでOK。
• 追加のコマンド・スクリプト・設定ファイルなどはJailを入れるHDDなど別の場所に入れる。ここなら後から気楽に書き換えできる。HDDが死んだらJailも死ぬので一蓮托生(^_^;)

現在のところうまく行ったのはinetd+socketだけ どの方法も多少の問題ありnatd以外の方法はうまくいってます。詳細次のページに。

環境

• マシン: HP Microserver N54L 6GB RAM HDD: 1.5GB x 4 RAID-Z
• FreeNAS-9.3-STABLE-201508250051

[2015/9/15 追記] DeleGate, inetdがうまくいかなかった理由はIntel NIC でした。sysctl -w net.inet.tcp.tso=0で問題解消。

Linuxで運用していたSSHサーバ機能をUSBメモリにFreeNAS-9.3-STABLE-201506292332インストールしたマシンに移動。サーバのSSHキーが変わると自動でここにデータを送ってくる外のプログラムが止まってしまうので、LinuxのSSHキーファイルをFreeNASマシンの/etc/sshにコピー。この時点では問題無し。

が、FreeNASというかSSHサービスを再起動すると、キーファイルが新しいものに上書きされてしまう。Web画面からSSHサービスの設定を変えて保存しただけで内部では再起動扱いのようで、キーファイルが変わってしまう。

そのためにSSH設定項目にHost Private Keyがあるはずなのですが、ここに書いてもなぜだか無視される 。

USBメモリのどこかに書いてある上書き用のキーファイルを書き換えるのは、リードオンリーでマウントしている/を書き込み可能にして編集とかFreeNASのバージョンアップや再インストール の度に発生するのでやりたくない。再インストール→保存していた設定読み込み→ハイ復活が理想なんです。

というわけで、以下の方法で逃げることにしました。

• 信頼できる保存場所(私はFreeNAS支配下のHDD ZFSプール内)にキーファイルを保存。ここでは/mnt/pool/sshと仮定。
• FreeNAS SSHサービスの設定画面でExtra optionsに以下を指定

HostKey /mnt/pool/ssh/ssh_host_key
HostKey /mnt/pool/ssh/ssh_host_rsa_key
HostKey /mnt/pool/ssh/ssh_host_dsa_key

とりあえずSSHサービス再起動しても/mnt/pool/ssh内のキーファイルが使われているようです。キーファイルのパーミッション設定は適切に…

[2015/8/8 追記] 再起動したらmissing boot loaderと出て起動しなくなりました。どうやら私の理解が間違っているようです。下記の内容は失敗例として参考にしてください。

先日様子見することにした FreeNASのシステムが入っているUSBメモリですが、昨日ライトエラーを繰り返しZFSから切り離された模様。交換ですな。

まずはda1をOfflineに。

# zpool offline freenas-boot da1p2

データ用デバイスとは異なりこいつにはパーティションが切られているため、新USBメモリ(da2)にパーティションテーブルを複製。da1は壊れているとはいえパーティションテーブルくらいは生きているでしょ…

# gpart backup /dev/da1 | gpart restore /dev/da2

新USBメモリをZFSに組み込み。

# zpool replace freenas-boot /dev/da1p2 /dev/da2p2
Make sure to wait until resilver is done before rebooting.

If you boot from pool 'freenas-boot', you may need to update
boot code on newly attached disk '/dev/da2p2'.

Assuming you use GPT partitioning and 'da0' is your new boot disk
you may use the following command:

        gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 da0

ご丁寧にブートローダーを新メモリに入れる方法を指南してくれ、調べる手間が省ける。

# gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 da2

ZFSの状況確認、再構成中。

# zpool status freenas-boot
  pool: freenas-boot
 state: DEGRADED
status: One or more devices is currently being resilvered.  The pool will
        continue to function, possibly in a degraded state.
action: Wait for the resilver to complete.
  scan: resilver in progress since Sat Aug  8 04:36:30 2015
        296M scanned out of 742M at 807K/s, 0h9m to go
        296M resilvered, 39.84% done
config:

        NAME                                            STATE     READ WRITE CKSUM
        freenas-boot                                    DEGRADED     0     0     0
          mirror-0                                      DEGRADED     0     0     0
            replacing-0                                 OFFLINE      0     0     0
              4340356687696627280                       OFFLINE      0    89     1  was /dev/da1p2/old
              da2p2                                     ONLINE       0     0     0  (resilvering)
            gptid/d7bb72a8-1b95-11e5-b672-000c29a6b2ea  ONLINE       0     0     0

errors: No known data errors

完了

# zpool status freenas-boot
  pool: freenas-boot
 state: ONLINE
  scan: resilvered 743M in 0h19m with 0 errors on Sat Aug  8 04:55:56 2015
config:

        NAME                                            STATE     READ WRITE CKSUM
        freenas-boot                                    ONLINE       0     0     0
          mirror-0                                      ONLINE       0     0     0
            da2p2                                       ONLINE       0     0     0
            gptid/d7bb72a8-1b95-11e5-b672-000c29a6b2ea  ONLINE       0     0     0

errors: No known data errors

[参考]

• gpart(8) (FreeBSD.org)
• Replacing a Device in a ZFS Storage Pool (Oracle Solaris ZFS Administration Guide)

USBメモリ2本挿しでZFSミラーリング構成 にしてから一か月しか経ってないのに、もうエラーですか…今回はZFSのエラー訂正機能だかミラーリング相手だかを使ってデータロスはなかった模様。

ミラーリング構成にしてあるしFreeNASの設定は保管してあるので今回は様子見することにしましたが、どちらのメモリがエラーを出したのかは気になるので調べることに。

まずはどのデバイスがエラーを出したのか。ルートシェルから

[root@freenas ~]# zpool status -v freenas-boot
  pool: freenas-boot
 state: ONLINE
status: One or more devices has experienced an unrecoverable error.  An
        attempt was made to correct the error.  Applications are unaffected.
action: Determine if the device needs to be replaced, and clear the errors
        using 'zpool clear' or replace the device with 'zpool replace'.
   see: http://illumos.org/msg/ZFS-8000-9P 
  scan: scrub repaired 130K in 0h7m with 0 errors on Sat Aug  1 03:55:52 2015
config:

        NAME                                            STATE     READ WRITE CKSUM
        freenas-boot                                    ONLINE       0     0     0
          mirror-0                                      ONLINE       0     0     0
            da1p2                                       ONLINE       0     0    27
            gptid/d7bb72a8-1b95-11e5-b672-000c29a6b2ea  ONLINE       0     0     0

errors: No known data errors

da1p2にチェックサムエラー(CKSUM)が発生しているので、怪しいのはda1らしい。次にこれが2本のうちどちらかを知るために

[root@freenas ~]# camcontrol devlist -v
(中略)
scbus7 on umass-sim0 bus 0:
<BUFFALO USB Flash Disk 1.00>:      at scbus7 target 0 lun 0 (pass4,da0)
scbus8 on umass-sim1 bus 1:
<UFD 2.0 Silicon-Power8G 1100>:     at scbus8 target 0 lun 0 (pass5,da1)

da1はSilicon powerの物らしい。

余談ですが、私はHDDでもUSBメモリでもRAIDを構成する時できるだけ違うメーカー・型番の物を混ぜることにしています。理由は二つ、

1. 同じメーカー・型番のドライブは似たような時期に壊れる可能性が高くなる(→RAIDデグレード中にもう一台逝ってしまう)
2. 交換するドライブが分かりやすい

RAIDの性能は一番遅いドライブに引っ張られる特性上、パフォーマンス重視の場合は同一メーカー・型番の方が良いのでしょうけど。

マイグレーションをリセット して元のデータをリストアする時、以下の条件に当てはまるエンティティがある場合注意が必要です。

• ナビゲーションプロパティを持っている(→テーブルに外部キーが設定されている)状態でプロパティを追加した(特にshort, integer, long integer等整数型)
• エンティティ定義しているソースコードの最後以外の行にプロパティを追加し、Add-Migrationした(ソースコード上のプロパティの順番が追加していった順になっていない)

問題はカラムの順番です。何が起こるかというと、プロパティ追加前、テーブルにはナビゲーションプロパティの外部キーを保存するためのカラムがあります。特にKey属性などを設定してない場合、参照先のIdカラムと同じinteger型になるでしょう。ここに新しいプロパティを追加すると、カラムの順番の最後に入ります。

Id	integer primary key
Name	varchar(30)
NavigationId	integer (参照先のKeyカラムの型)
NewPropterty	integer

次にマイグレーションを整理してテーブルを作り直すと、ナビゲーションプロパティのカラムが最後に入ります。

Id	integer primary key
Name	varchar(30)
NewPropterty	integer
NavigationId	integer (参照先のKeyカラムの型)

リストアは作り直した空テーブルへの実行となりますから、mysqldumpにはno-create-info(-t)オプションを付けることになると思います。これで出力されるファイルにはカラムの順番情報がありません。リストア先のテーブルもId, Name, NavigationId, NewPropertyの順番でカラムが並んでいる前提になってます。

このダンプファイルを使って作り直したテーブルにリストアするとNewPropertyとNavigationIdの値が入れ替わって保存されます。NewPropertyがvarcharなどNavigationIdと異なる型になっている場合はエラーなどになるでしょうが、同じ型の場合エラーなく保存されます。外部キー整合性のチェックはリストア時には行われないようです(やったらめちゃくちゃ重くなりそうだし)。結果ナビゲーションプロパティはでたらめなデータを参照します。

上記の内容がよく分からない、マイグレーションを重ねすぎて条件に合致するか分からない場合は、complete-insertオプションを付けてmysqldumpを実行した方が安全です。ダンプ・リストア共に劇的に遅くなりますが。

昔の記憶ですがPostgreSQL(8.1)もダンプはこういう仕様(オプション付けないとカラムの順番を保存しない)だったような。テーブル大きいとダンプ・リストアも高速化したいですからねぇ。

保険のためにデータベースのフルダンプ(テーブル作成SQL込み)を取ってなかったら爆死だったな…