FreeNASで以前使っていたSSHキーファイルを使う

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

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

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

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

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

  • 信頼できる保存場所(私は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内のキーファイルが使われているようです。キーファイルのパーミッション設定は適切に…

— posted by mu at 03:18 pm   commentComment [0]  pingTrackBack [0]

FreeNASのUSBメモリ、結局交換

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

先日様子見することにしたLink 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
[参考]

— posted by mu at 04:39 am   commentComment [0]  pingTrackBack [0]

FreeNASのUSBメモリがチェックサムエラー

blog20150801-FreeNAS_Alert

USBメモリ2本挿しでZFSミラーリング構成Link にしてから一か月しか経ってないのに、もうエラーですか…今回は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-9PLink 
  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の性能は一番遅いドライブに引っ張られる特性上、パフォーマンス重視の場合は同一メーカー・型番の方が良いのでしょうけど。

— posted by mu at 10:00 am   commentComment [0]  pingTrackBack [0]

Entity Framework&MySQLでテーブルを作り直すときの注意

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

  • ナビゲーションプロパティを持っている(→テーブルに外部キーが設定されている)状態でプロパティを追加した(特に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込み)を取ってなかったら爆死だったな…

— posted by mu at 09:47 am   commentComment [0]  pingTrackBack [0]

Entity Framework 6.1.3 & MySQL 5.6でマイグレーションが失敗する 2

Update-Databaseを実行すると、なぜか対象のDBがフレッシュだと誤認→マイグレーションを最初から当てようとする→既に存在するテーブル名で作成しようとしてエラーとなる。

半日かけても原因が分からず、__MigrationHistoryが壊れてしまったのかもしれないと思い込むことにする。一度Rollbackなんてしたからその時おかしくなったのだろうか。

今回の変更は新規テーブルの追加のみだったのですが、カラム数と外部キーが多く手動はちとめんどくさいので以下の手段で。

  1. MySQLに新しいデータベース(スキーマ)を作成。Entity Frameworkで用いるユーザーに必要な権限を与える。
  2. App.configのConnection Stringを新しいデータベースを対象とするように書き換える。この時のApp.configは開始プロジェクトのもの。
  3. Update-Database実行。新しいデータベースにテーブルが作成される。
  4. 新しいデータベースからマイグレーションで追加されるテーブルと__MigrationHistoryをデータ付きでdump。
  5. $ mysqldump -uroot -p -hlocalhost 新データベース名 __MigrationHistory 追加テーブル1 追加テーブル2 ... > migration.mysqldump
    
  6. 既存データベースにリストア
  7. $ mysql -uroot -p
    mysql> use 既存データベース
    Reading table information for completion of table and column names
    You can turn off this feature to get a quicker startup with -A
    
    Database changed
    mysql> drop table __MigrationHistory;
    Query OK, 0 rows affected (0.82 sec)
    
    mysql> source migration.mysqldump
    

ConnectionStringを元データベースに戻し、Update-Database -Scriptを実行(-Scriptオプションは実際に実行されないように)でさらに適用するマイグレーションが無いことを確認して完了。

[余談] 今回マイグレーションかける直前にmysqlのディレクトリのスナップショットを取ってあったので焦らずに済んだのですが、普段取らないのになぜ今回取る気になったのだろう?

[参考]

— posted by mu at 12:03 pm   commentComment [0]  pingTrackBack [0]

T: Y: ALL: Online:
ThemeSwitch
  • Basic
Created in 0.0399 sec.
prev
2017.11
next
      1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30