2012年12月23日日曜日

mikutterユーザ会共用サーバ(VPS)について

OSC 2012 Tokyo/Fallにて、お名前.com様からVPS(KVM メモリ4GBプラン)を mikutterユーザ会用として無償提供していただきました。
ありがてぇありがてぇヽ('ω')ノ三ヽ('ω')ノ

そこで、私(@Phenomer)が管理を引き受け、皆で共有できるようにしようとし た...のですが #ておくれポイント

ておくれポイント

  • FreeBSD + jailで共用サーバをユーザ毎にjailで隔離して利用できる設計に
    -> FreeBSDとKVMの相性は相変わらずイマイチらしい…
  • VIMAGEでjail毎のネットワークを分けよう
    -> EXPERIMENTAL
  • FreeBSD9-STABLEに最近入ったらしいvirtioでどうにかしよう
    -> RELEASEではない
  • とりあえずpfで。OpenBSDやNetBSDでも使ってるし
    -> 恐ろしくパフォーマンスが出ない(100KB/s程度…)
  • ならipfilterで。
    -> これまた恐ろしくパフォーマンスが出ない
  • 仕方ないのでipfwで
    -> NAT有効にした瞬間TCPが突然死する
  • ならipfw + natdで
    -> pf, ipfilter並にパフォーマンスが出ない
  • NAT無効だが環境が出来た状態でベンチマークとっていた
    -> NATかませたらパフォーマンス最悪 + 不安定に
    -> 手元の実験環境では問題なくパフォーマンスが出ていた
    -> 問題の切り分けが早期に行えなかった
  • jail内の環境構築にハマる
    -> wikiとかDBとか
  • 優先順位の見極めができていない
    -> どうでもいいところでずっとハマって悩む
  • 追い打ちをかけるFreeBSD鍵流出問題
    -> 疑いが持たれる公式パッケージを利用していたので、 全て再インストールするのが最善という悲しい結果に

...orz

結果

  • FreeBSD9やめてDebian wheezy + LXCにしました
  • 全てのユーザ毎にコンテナを作成するのはとりあえずやめました
  • ベースは1週間ぐらいでできました

ヽ(´ー`)ノ

現状

既に共有できるように設定済みですので、アカウント名と公開鍵を@Phenomer までご連絡頂ければ設定して折り返し連絡致します。 また、Arch LinuxのLiveCDベースのmikutter LiveCDの配布も行なっています。

詳細はmikutterユーザ会のWebページで ヽ('ω'ヾ(@⌒ー⌒@)ノ'ω')ノ

2012年12月3日月曜日

カーネル/VM Advent Calendar 2012 3日目: DragonflyBSDのHAMMERを使ってみよう!

1 はじめに

例年こわい方々で一杯と評判のカーネル/VM Advent Calendar、3日目は今年恐 る恐る初参加の@Phenomerです。 今回は、日本語情報がいまいち多くないDragonflyBSD(3.2.1)のHAMMERファイルシステ ムの使い方のようなものを纏めてみました。(いまいち纏まってない気もしますが…)

長くなってしまったので pdf版も上げておきます。よかったらどうぞ。

2 HAMMERとは

HAMMERは、DragonflyBSDにおけるFFSの代替のファイルシステムである。ZFSや btrfsに似ている機能を多く持っている。

HAMMERの機能として以下が挙げられる。

  • 障害からの素早い復旧
  • 複数のボリュームにまたがる大規模なファイルシステム
  • ミラーリング
  • スナップショット
  • きめ細かな履歴の保存
  • データの整合性チェック
  • データの重複排除

HAMMERの管理に関連するコマンドは以下の通りである。

  • newfs_hammer(8)
  • mount_Hammer(8)
  • hammer(8)
  • undo(1)

3 とにかく使ってみる

使ってみないことには始まらないのでDragonflyBSDをインストールする。 HAMMERの動作には最低でも50GBの空き領域が必要らしい。もし既にインストー ルしてあるDragonfly上で新たにHAMMERファイルシステムを作る場合、以下の ようにnewfsしてmountしておく。

# newfs_hammer -L MIKU /dev/ad0s1d
# mount_hammer /dev/ad0s1d /miku

残念ながらバージョン3.2.1ではvirtioやXen DOMUにはまだ対応していないた め、パフォーマンスも試す場合は物理マシンに導入したほうがよい。

(virtioは2011年のGSoCで実装する動きがあったようだが、本体にマージはさ れていない模様)

3.1 ディレクトリ構造

HAMMERファイルシステムの状態はinfoサブコマンドで参照できる。

negix# hammer info /
Volume identification
        Label               ROOT
        No. Volumes         1
        FSID                5c95cbb8-302f-11e2-8c0e-b9ac6f12aafc
        HAMMER Version      6
Big block information
        Total           69038
        Used              590 (0.85%)
        Reserved           39 (0.06%)
        Free            68409 (99.09%)
Space information
        No. Inodes     110799
        Total size       539G (579132719104 bytes)
        Used             4.6G (0.85%)
        Reserved         312M (0.06%)
        Free             534G (99.09%)
PFS information
        PFS ID  Mode    Snaps  Mounted on
             0  MASTER      9  /
             1  MASTER      9  /var
             2  MASTER      0  /tmp
             3  MASTER      9  /usr
             4  MASTER      9  /home
             5  MASTER      0  /usr/obj
             6  MASTER      9  /var/crash
             7  MASTER      0  /var/tmp

HAMMERでよく利用されるディレクトリは、/pfsと/var/hammerである。

  • /pfs - 各PFSへのシンボリックリンクを置く
  • /var/hammer - 各PFSでcronにより自動生成されるスナップショットへのシ ンボリックリンクが置かれる

ls -loすると、/pfsは以下のようになっている。

negix# ls -lo /pfs
total 0
lrwxr-xr-x  1 root  wheel  - 10 Nov 17 05:55 home -> @@-1:00004
lrwxr-xr-x  1 root  wheel  - 10 Nov 17 05:55 tmp -> @@-1:00002
lrwxr-xr-x  1 root  wheel  - 10 Nov 17 05:55 usr -> @@-1:00003
lrwxr-xr-x  1 root  wheel  - 10 Nov 17 05:55 usr.obj -> @@-1:00005
lrwxr-xr-x  1 root  wheel  - 10 Nov 17 05:55 var -> @@-1:00001
lrwxr-xr-x  1 root  wheel  - 10 Nov 17 05:55 var.crash -> @@-1:00006
lrwxr-xr-x  1 root  wheel  - 10 Nov 17 05:55 var.tmp -> @@-1:00007

mountは以下のようになっている。

negix# mount
ROOT on / (hammer, local)
devfs on /dev (devfs, local)
/dev/mfid0s1a on /boot (ufs, local)
/pfs/@@-1:00001 on /var (null, local)
/pfs/@@-1:00002 on /tmp (null, local)
/pfs/@@-1:00003 on /usr (null, local)
/pfs/@@-1:00004 on /home (null, local)
/pfs/@@-1:00005 on /usr/obj (null, local)
/pfs/@@-1:00006 on /var/crash (null, local)
/pfs/@@-1:00007 on /var/tmp (null, local)
procfs on /proc (procfs, local)

また、/etc/fstabは以下のようになっている。

# Device                Mountpoint      FStype  Options         Dump    Pass#
/dev/mfid0s1a           /boot           ufs     rw              1       1
/dev/mfid0s1b           none            swap    sw              0       0
/dev/mfid0s1d           /               hammer  rw              1       1
/pfs/var                /var            null    rw              0       0
/pfs/tmp                /tmp            null    rw              0       0
/pfs/usr                /usr            null    rw              0       0
/pfs/home               /home           null    rw              0       0
/pfs/usr.obj    /usr/obj                null    rw              0       0
/pfs/var.crash  /var/crash              null    rw              0       0
/pfs/var.tmp    /var/tmp                null    rw              0       0
proc                    /proc           procfs  rw              0       0

/となるPFSのみHAMMERとしてmountされ、それ以外はPFSに対しシンボリックリ ンクを張り、そのシンボリックリンクをnull mountしていることが分かる。

/を/pfs/rootとして置きたければ、以下のようにすればよい。

negix# ln -s @@-1:00000 /pfs/root
negix# ls /pfs/root
COPYRIGHT       compat          home            pfs             root            tmp
bin             dev             miku            proc            sbin            usr
boot            etc             mnt             rin             sys             var
negix# ls /
COPYRIGHT       compat          home            pfs             root            tmp
bin             dev             miku            proc            sbin            usr
boot            etc             mnt             rin             sys             var

3.2 マスタPFSの作成と削除

マスタPFSを作成しマウントする。そしてアンマウントして削除する。

negix# hammer pfs-master /pfs/miku
Creating PFS #8 succeeded!
/pfs/miku
    sync-beg-tid=0x0000000000000001
    sync-end-tid=0x0000000106e33fa0
    shared-uuid=d9c9419e-3489-11e2-ad25-b9ac6f12aafc
    unique-uuid=d9c941b0-3489-11e2-ad25-b9ac6f12aafc
    label=""
    prune-min=00:00:00
    operating as a MASTER
    snapshots directory defaults to /var/hammer/<pfs>
negix# mkdir /miku
negix# mount_null /pfs/miku /miku
negix# mount
ROOT on / (hammer, local)
devfs on /dev (devfs, local)
/dev/mfid0s1a on /boot (ufs, local)
/pfs/@@-1:00001 on /var (null, local)
/pfs/@@-1:00002 on /tmp (null, local)
/pfs/@@-1:00003 on /usr (null, local)
/pfs/@@-1:00004 on /home (null, local)
/pfs/@@-1:00005 on /usr/obj (null, local)
/pfs/@@-1:00006 on /var/crash (null, local)
/pfs/@@-1:00007 on /var/tmp (null, local)
procfs on /proc (procfs, local)
/pfs/@@-1:00008 on /miku (null, local)
negix# umount /miku
negix# hammer pfs-destroy /pfs/miku
You have requested that PFS#8 () be destroyed
This will irrevocably destroy all data on this PFS!!!!!
Do you really want to do this? y
This PFS is currently setup as a MASTER!
Are you absolutely sure you want to destroy it? y
Destroying PFS #8 () in  5 4 3 2 1.. starting destruction pass
pfs-destroy of PFS#8 succeeded!

4 複数ボリュームの利用

HAMMERでは、複数ボリュームによるスパニングがサポートされている。 スパニングを行いたい場合は、newfs時に複数ボリュームを指定すればよい。

negix# newfs_hammer -L TEST -f /dev/ad2s0 /dev/ad3s0
Volume 0 DEVICE /dev/ad2s0      size   1.95GB
Volume 1 DEVICE /dev/ad3s0      size   1.95GB
initialize freemap volume 0
initializing the undo map (504 MB)
initialize freemap volume 1
---------------------------------------------
2 volumes total size   3.91GB version 6
boot-area-size:        4.00MB
memory-log-size:       4.00MB
undo-buffer-size:    504.00MB
total-pre-allocated:   0.51GB
fsid:                5fe2448b-3c62-11e2-835a-535400123456
...
negix# mount_hammer /dev/ad2s0:/dev/ad3s0 /mnt
negix# df -h /mnt
Filesystem   Size   Used  Avail Capacity  Mounted on
TEST         3.4G   187M   3.2G     5%    /mnt
negix# hammer volume-list /mnt
/dev/ad2s0
/dev/ad3s0

/etc/fstabに書く際は、以下のようにコロンで区切り指定する。

/dev/ad2s0:/dev/ad3s0 /mnt hammer rw 1 2

デフォルトの場合は/dev/serno以下のノードを利用しているようなので、そち らを用いたほうがいいのかも知れない。

/dev/serno/QM00002.s0:/dev/serno/QM00004.s0 /mnt hammer rw 1 2

複数ボリュームを利用したHAMMERファイルシステムのマウント時は、全てのボ リュームを指定しないとエラーになる。

negix# mount_hammer /dev/ad2s0 /mnt
mount_hammer: mount  on /mnt: Invalid argument
negix# mount_hammer /dev/ad2s0:/dev/ad3s0 /mnt

4.1 ボリュームの取り外し

ボリュームの取り外しは、volume-delサブコマンドを用いて行う。

negix# hammer volume-del /dev/ad3s0 /mnt
negix# hammer volume-del /dev/ad2s0 /mnt
hammer volume-del ioctl: Invalid argument
negix# hammer volume-list /mnt
/dev/ad2s0

取り外した後は、再マウントしないとファイルシステムサイズには反映されな いようだ。(ディスクが無くなった分はUsedが大きくなっている)

negix# df -h /mnt
Filesystem   Size   Used  Avail Capacity  Mounted on
TEST         3.4G   2.1G   1.2G    63%    /mnt
negix# umount /mnt
negix# mount_hammer /dev/ad3s0 /mnt
negix# df -h /mnt
Filesystem   Size   Used  Avail Capacity  Mounted on
TEST         1.4G   179M   1.2G    12%    /mnt

4.2 ボリュームの追加

ボリュームの追加は、volume-addサブコマンドを用いる。 何故か複数ボリュームを指定してnewfsした時よりSizeが大幅に減ってしまう ようだ。(ディスクサイズが小さ過ぎるのが原因?)

negix# dd if=/dev/zero of=/dev/ad3s0 bs=1m count=128
128+0 records in
128+0 records out
134217728 bytes transferred in 2.548319 secs (52669121 bytes/sec)
negix# hammer volume-add /dev/ad3s0 /mnt
negix# hammer volume-list /mnt
/dev/ad2s0
/dev/ad3s0
negix# df -h /mnt
Filesystem   Size   Used  Avail Capacity  Mounted on
TEST         1.4G  -677M   2.1G   -47%    /mnt
negix# umount /mnt
negix# mount /dev/ad2s0:/dev/ad3s0 /mnt
negix# df -h /mnt
Filesystem   Size   Used  Avail Capacity  Mounted on
TEST         2.3G   227M   2.1G    10%    /mnt

ボリュームの追加前は、一旦dd等を用いて元あったHAMMERファイルシステムを 上書きしておかないとエラーになることがある。

negix# hammer volume-add /dev/ad3s0 /mnt
hammer volume-add ioctl: Inappropriate file type or format

5 ミラーリング

5.1 スレーブPFSの作成とマスタからのコピー

スレーブPFSはリードオンリーのPFSであり、マスタPFSのミラー先として用い られる。ミラーリング操作には主にmirror-copy、mirror-streamサブコマンド を用いる。この他にも、mirror-read、mirror-read-stream、mirror-write、 mirror-dumpサブコマンドがある。stream系サブコマンドは、PFSの状態に変更 があった際に自動的に送受信する用途で用いられる。

以下の例は、単純にマスタPFSからスレーブPFSへのコピーを行なうものである。

negix# hammer pfs-master /pfs/miku
Creating PFS #8 succeeded!
/pfs/miku
    sync-beg-tid=0x0000000000000001
    sync-end-tid=0x0000000106e34240
    shared-uuid=3da094bc-348b-11e2-ad25-b9ac6f12aafc
    unique-uuid=3da094cf-348b-11e2-ad25-b9ac6f12aafc
    label=""
    prune-min=00:00:00
    operating as a MASTER
    snapshots directory defaults to /var/hammer/<pfs>
negix# hammer pfs-slave /pfs/negi shared-uuid=3da094bc-348b-11e2-ad25-b9ac6f12aafc
Creating PFS #9 succeeded!
/pfs/negi
    sync-beg-tid=0x0000000000000001
    sync-end-tid=0x0000000000000001
    shared-uuid=3da094bc-348b-11e2-ad25-b9ac6f12aafc
    unique-uuid=5c88ff4f-348b-11e2-ad25-b9ac6f12aafc
    slave
    label=""
    prune-min=00:00:00
    operating as a SLAVE
    snapshots directory defaults to /var/hammer/<pfs>
negix# touch /pfs/miku/mikumiku
negix# hammer mirror-copy /pfs/miku /pfs/negi
Prescan to break up bulk transfer
Prescan 1 chunks, total 0 MBytes (520)
Mirror-read /pfs/miku succeeded
negix# ls /pfs/negi
mikumiku
negix# touch /pfs/negi/rinrin
touch: /pfs/negi/rinrin: Read-only file system
negix# touch /pfs/miku/rinrin
negix# ls /pfs/negi
mikumiku
negix# hammer mirror-copy /pfs/miku /pfs/negi
Prescan to break up bulk transfer
Prescan 1 chunks, total 0 MBytes (312)
Mirror-read /pfs/miku succeeded
negix# ls /pfs/negi
mikumiku        rinrin

スレーブPFSにコピー元のマスタと同じshared-uuidを設定していない場合、 mirror-copyを行う際に怒られるので注意。shared-uuid等を更新する場合は pfs-updateサブコマンドを用いる。

negix# hammer mirror-copy /pfs/miku /pfs/rin
mirror-write: source and target have different shared-uuid's!
negix# hammer pfs-update /pfs/rin
shared-uuid=3da094bc-348b-11e2-ad25-b9ac6f12aafc
/pfs/rin
    sync-beg-tid=0x0000000000000001
    sync-end-tid=0x0000000000000001
    shared-uuid=3da094bc-348b-11e2-ad25-b9ac6f12aafc
    unique-uuid=b11665b3-34d7-11e2-ad25-b9ac6f12aafc
    slave
    label=""
    prune-min=00:00:00
    operating as a SLAVE
    snapshots directory defaults to /var/hammer/<pfs>

5.2 スレーブからマスタへのコピー

mirror-copyの宛先にマスタPFSは指定できないため、一旦スレーブPFSとマス タPFSを切り替えてからコピーを行い、その後元に戻す。マスタPFSとスレーブ PFSの切り替えはpfs-upgradeとpfs-downgradeサブコマンドを用いる。

negix# touch /pfs/miku/lukaluka
negix# hammer mirror-copy /pfs/negi /pfs/miku
mirror-write: target must be in slave mode
negix# hammer pfs-upgrade /pfs/negi
pfs-upgrade of PFS#9 () succeeded
negix# hammer pfs-status /pfs/negi
/pfs/negi       PFS #9 {
    sync-beg-tid=0x0000000000000001
    sync-end-tid=0x0000000106e3c6f0
    shared-uuid=3da094bc-348b-11e2-ad25-b9ac6f12aafc
    unique-uuid=5c88ff4f-348b-11e2-ad25-b9ac6f12aafc
    label=""
    prune-min=00:00:00
    operating as a MASTER
    snapshots directory defaults to /var/hammer/<pfs>
}
negix# hammer pfs-downgrade /pfs/miku
pfs-downgrade of PFS#8 () succeeded
negix# hammer pfs-status /pfs/miku
/pfs/miku       PFS #8 {
    sync-beg-tid=0x0000000000000001
    sync-end-tid=0x0000000106e3c730
    shared-uuid=3da094bc-348b-11e2-ad25-b9ac6f12aafc
    unique-uuid=3da094cf-348b-11e2-ad25-b9ac6f12aafc
    slave
    label=""
    prune-min=00:00:00
    operating as a SLAVE
    snapshots directory defaults to /var/hammer/<pfs>
}
negix# hammer mirror-copy /pfs/negi /pfs/miku
Prescan to break up bulk transfer
Prescan 1 chunks, total 0 MBytes (0)
Mirror-read /pfs/negi succeeded
negix# ls /pfs/miku
mikumiku        rinrin
negix# hammer pfs-status /pfs/miku
/pfs/miku       PFS #8 {
    sync-beg-tid=0x0000000000000001
    sync-end-tid=0x0000000106e3c790
    shared-uuid=3da094bc-348b-11e2-ad25-b9ac6f12aafc
    unique-uuid=3da094cf-348b-11e2-ad25-b9ac6f12aafc
    slave
    label=""
    prune-min=00:00:00
    operating as a SLAVE
    snapshots directory defaults to /var/hammer/<pfs>
}
negix# hammer pfs-status /pfs/negi
/pfs/negi       PFS #9 {
    sync-beg-tid=0x0000000000000001
    sync-end-tid=0x0000000106e3cb70
    shared-uuid=3da094bc-348b-11e2-ad25-b9ac6f12aafc
    unique-uuid=5c88ff4f-348b-11e2-ad25-b9ac6f12aafc
    label=""
    prune-min=00:00:00
    operating as a MASTER
    snapshots directory defaults to /var/hammer/<pfs>
}
negix# hammer pfs-downgrade /pfs/negi
pfs-downgrade of PFS#9 () succeeded
negix# hammer pfs-upgrade /pfs/miku
pfs-upgrade of PFS#8 () succeeded

5.3 ssh経由でのファイルシステムのミラーリング

マスタPFSとスレーブPFSが別ホストのHAMMERファイルシステム上で運用されて いて、それを同期したい場合は、mirror-copyとmirror-streamサブコマンドが 便利である。

mirror-copyの場合はその時点でのコピーがスレーブPFSに作成される。

negix# hammer mirror-copy root@127.0.0.1:/pfs/miku \
> root@127.0.0.1:/pfs/negi
Prescan to break up bulk transfer
Prescan 1 chunks, total 0 MBytes (0)
Mirror-read /pfs/miku succeeded

mirror-streamの場合はssh接続が維持され、ファイルの変更があった際にスレー ブPFSに自動的に同期が行われる。

negix# hammer mirror-stream root@127.0.0.1:/pfs/miku \
> root@127.0.0.1:/pfs/negi
Prescan to break up bulk transfer
Prescan 1 chunks, total 0 MBytes (6616)
.....

ファイルシステムの操作にはroot権限が必要であるため、sshd_configは デフォルトでPermitRootLogin without-passwordとなっており、鍵ペアを事前 に用意しrootログインが可能になるようにしておく。

6 スナップショット

6.1 スナップショットの作成

マスタPFSのデフォルト設定では毎日スナップショットが作成される。手動で 作成する場合はsnap、snaplo、snapqサブコマンドを用いる。以前はsnapshot サブコマンドを用いていたようだが、現在は非推奨となっている。

negix# hammer snap /miku
negix# hammer snapls /miku
Snapshots on /miku     PFS #8
Transaction ID          Timestamp               Note
0x0000000106e4d170      2012-11-22 20:03:44 JST -
negix# touch /pfs/miku/neginegi
negix# hammer snap /miku "add neginegi"
negix# hammer snapls /miku
Snapshots on /miku     PFS #8
Transaction ID          Timestamp               Note
0x0000000106e4d170      2012-11-22 20:03:44 JST -
0x0000000106e552a0      2012-11-22 20:06:42 JST add neginegi

ディレクトリのスナップショットを作成したい場合はsnaploサブコマンドを用 いる。

negix# mkdir -p /miku/hachune/negi
negix# hammer snaplo /miku/hachune "hachune directory"
negix# hammer snapls /miku | tail -n 1
0x000000010b40f540      2012-11-26 18:55:04 JST hachune directory
negix# ls -l /miku/hachune/snap-20121126-1855
lrwxr-xr-x  1 root  miku  33 Nov 26 18:55 /miku/hachune/snap-20121126-1855
 -> /miku/hachune@@0x000000010b40f540

また、スナップショットへのシンボリックリンクを作成せずにスナップショッ トのみを作成する場合は、snapqサブコマンドを用いる。snapqコマンドでは、 作成したスナップショットへのパスが標準出力に出力される。

negix# hammer snapq /miku/hachune "neginegi"
/miku/hachune@@0x000000010b40f660

注意点として、null mountしていない状況で/pfs以下のシンボリックリンクに 対しsnapサブコマンドを実行すると、シンボリックリンクの対象がおかしくな る点が挙げられる。

negix# umount /miku
negix# hammer snap /pfs/miku symlinktest
negix# hammer snapls /pfs/miku | tail -n 1
0x000000010b40f8e0      2012-11-26 19:10:18 JST symlinktest
negix# ls -l /pfs/miku/snap-20121126-1910
lrwxr-xr-x  1 root  miku  22 Nov 26 19:10 /pfs/miku/snap-20121126-1910
 -> //@@0x000000010b40f8e0

snaploはディレクトリ基準でシンボリックリンクが作成されるため問題になら ず、snapqは自分でシンボリックリンクを作成するため問題にならない。

6.2 スナップショットの利用

特定のディレクトリにスナップショットを纏めておきたい時は、このsnapqを 用いればよさそう。

negix# mkdir /snaps
negix# ln -s `hammer snapq /miku/hachune "neginegi"` /snaps/miku.hachune-121126_2000
negix# ls -l /snaps/miku.hachune-121126_2000
lrwxr-xr-x  1 root  wheel  33 Nov 26 19:01
/snaps/miku.hachune-121126_2000
 -> /miku/hachune@@0x000000010b40f760
negix# ls -l /snaps/miku.hachune-121126_2000/
total 0
drwxr-xr-x  1 root  miku   0 Nov 26 18:54 negi
lrwxr-xr-x  1 root  miku  33 Nov 26 18:55 snap-20121126-1855
 -> /miku/hachune@@0x000000010b40f540

作成したスナップショットから過去の状態を参照する場合は、TransactionID を指定し各コマンドを実行する。スナップショットのTransactionIDはsnapls サブコマンドで確認できる。

negix# hammer snapls /miku
Snapshots on /miku      PFS #8
Transaction ID          Timestamp               Note
0x0000000106e4d170      2012-11-22 20:03:44 JST -
0x0000000106e552a0      2012-11-22 20:06:42 JST add neginegi
0x0000000106e55440      2012-11-22 20:11:48 JST -
0x0000000106e555a0      2012-11-22 20:15:04 JST -
0x0000000106e55b60      2012-11-22 20:23:28 JST -
0x0000000106e55da0      2012-11-22 20:38:37 JST -
0x0000000106e55ea0      2012-11-22 20:40:04 JST -
0x0000000106e56000      2012-11-22 20:47:21 JST -
0x0000000106e560c0      2012-11-22 20:48:36 JST -
0x0000000106e56140      2012-11-22 20:48:49 JST -
0x0000000106e56260      2012-11-22 20:49:56 JST -
negix# ls /miku/@@0x0000000106e55da0
mikumiku                snap-20121122-2003      snap-20121122-2023
neginegi                snap-20121122-2006
rinrin                  snap-20121122-2015

ディレクトリのスナップショットに対しシンボリックリンクを貼ることで、リー ドオンリーの状態でそのディレクトリ以下の過去の状態を参照できる。

negix# ln -s /miku/@@0x0000000106e55da0 /tmp/miku
negix# ls /tmp/miku 
mikumiku                rinrin                  snap-20121122-2006    snap-20121122-2023
neginegi                snap-20121122-2003      snap-20121122-2015

スナップショット間のdiffも同様に指定することで閲覧できる。

negix# diff /home/miku/.history@@0x0000000106892480 \
> /home/miku/.history@@0x0000000106cf8170
56a57,88
> #+1353130082
> ls
> #+1353130085
> top
> #+1353130086
> ls
> #+1353130094
> tmux
> #+1353130103
> ls /usr/pkg/bin/zsh
> #+1353130111
> chsh -s /usr/pkg/bin/zsh
> #+1353130119

historyサブコマンドにより、ファイル毎のトランザクション履歴を確認する こともできる。この履歴はスナップショットに関わらず作成されるため、作業 中にうっかりファイルを壊してしまった場合などに有用である。

negix# hammer history ~/.history
/root/.history  0000000102c5113d clean {
    0000000102c61ca0 16-Nov-2012 21:53:05
    0000000106895e40 17-Nov-2012 14:27:32
    00000001068960a0 17-Nov-2012 14:29:55
    0000000106cf6fb0 21-Nov-2012 21:50:28
    0000000106e3cdf0 22-Nov-2012 19:52:30
    0000000106e66d20 22-Nov-2012 21:33:22
}

残念ながら、ファイルを一旦rmしてしまうとhistoryでは追えなくなってしま うようだ。(過去のTransactionIDが分かれば一応参照はできる)

negix% rm miku.txt
negix% hammer history miku.txt
miku.txt        No such file or directory
negix% cat miku.txt@@0x000000010b4100a0
miku
mikumiku
mikumikumiku
negix% touch miku.txt
negix% hammer history miku.txt
miku.txt        000000010a01792d dirty {
}

また、historyを元に行う操作はundoコマンドを用いて行うこともできる。 "undo -a"で全履歴の表示、"undo -t TransactionID -u"でTransactionID時点 にロールバックした.undoファイルの作成が行える。

negix% echo luka > luka.txt
negix% echo lukaluka >> luka.txt
negix% echo lukalukaluka >> luka.txt
negix% undo -a luka.txt
luka.txt: ITERATE ENTIRE HISTORY

>>> luka.txt 0001 0x000000010b432a20 03-Dec-2012 03:00:56

luka
lukaluka
lukalukaluka

>>> luka.txt 0002 0x000000010b432ee0 03-Dec-2012 03:01:50

luka

>>> luka.txt 0003 0x000000010b432fa0 03-Dec-2012 03:02:02

luka
lukaluka
lukalukaluka
negix% undo -t 0x000000010b432ee0 -u luka.txt
negix% cat luka.txt.undo.0000
luka

スナップショット以外にもトランザクション履歴を追える機能などは、Linux のnilfs2の機能と似ているかもしれない。

6.3 マスタのスナップショットからスレーブへのコピー

マスタPFSをスナップショットの時点に戻せないのかと思い、mirror-copyサブ コマンドを実行する際にスナップショットのTransactionIDを追加してみたが、 何も指定しなかった時と同様に現時点の状態でコピーされた。

negix# hammer mirror-copy /pfs/miku/@@0x0000000106e55440 /pfs/rin                 
Prescan to break up bulk transfer
Prescan 1 chunks, total 0 MBytes (7160)
Mirror-read /pfs/miku/@@0x0000000106e55440 succeeded
negix# ls /pfs/rin
mikumiku                rinrin                  snap-20121122-2006
snap-20121122-2023      snap-20121122-2040
neginegi                snap-20121122-2003      snap-20121122-2015
snap-20121122-2038
negix# ls /pfs/miku/@@0x0000000106e55440
mikumiku                neginegi                rinrin
snap-20121122-2003      snap-20121122-2006

もしスナップショットの時点のディレクトリ以下のファイルを復旧したい場合 は、cpdupコマンドを用いる。

negix# cpdup /pfs/miku/@@0x0000000106e552a0 /rin/
negix# ls /rin
mikumiku                neginegi                rinrin
snap-20121122-2003

cpdupではPFSの状態(snapshot等)はコピーされない点については注意が必要か も知れない。(過去のスナップショット時点へのロールバックはできない?)

ある時点のスナップショット「以降」の変更をスナップショットごとコピーし たい(古いスナップショットはコピーしない)場合は、mirror-readサブコマン ドとmirror-writeサブコマンドを用い、またmirror-readサブコマンド実行時 にコピーしておきたい時点のTransactionIDを指定する。

negix# hammer mirror-read /pfs/miku 0x0000000106e55440 | 
> hammer mirror-write /pfs/rin
Prescan to break up bulk transfer
Prescan 1 chunks, total 156 MBytes (164220376)
Mirror-read /pfs/miku succeeded
Source can update synctid to 0x0000000106eb6670

7 掃除

7.1 Dedup

重複の排除は、hammer version5でサポートされたdedupサブコマンドを用いて 実行できる。以下の例では、0埋めした1GBのファイルを/home以下に保存し、 dedupを実行している。dedup-simulateサブコマンドでは、dedupを実行した際 どの程度まで圧縮可能かを確認できる。

negix# df -h
Filesystem        Size   Used  Avail Capacity  Mounted on
ROOT              539G   5.2G   534G     1%    /
devfs             1.0K   1.0K     0B   100%    /dev
/dev/mfid0s1a     756M   213M   483M    31%    /boot
/pfs/@@-1:00001   539G   5.2G   534G     1%    /var
/pfs/@@-1:00003   539G   5.2G   534G     1%    /usr
/pfs/@@-1:00004   539G   5.2G   534G     1%    /home
/pfs/@@-1:00005   539G   5.2G   534G     1%    /usr/obj
/pfs/@@-1:00006   539G   5.2G   534G     1%    /var/crash
/pfs/@@-1:00007   539G   5.2G   534G     1%    /var/tmp
procfs            4.0K   4.0K     0B   100%    /proc
/pfs/@@-1:00008   539G   5.2G   534G     1%    /miku
negix# hammer dedup-simulate /pfs/home
Dedup-simulate running
Dedup-simulate /pfs/home succeeded
Simulated dedup ratio = 4198.66
negix# hammer dedup /pfs/home                                         
Dedup running
Dedup /pfs/home succeeded
Dedup ratio = 301.21
     1024 MB referenced
     3481 KB allocated
     3232 KB skipped
           0 CRC collisions
           0 SHA collisions
           0 bigblock underflows
       16342 new dedup records
    1070350336 new dedup bytes
negix# hammer dedup-simulate /pfs/home
Dedup-simulate running
Dedup-simulate /pfs/home succeeded
Simulated dedup ratio = 4198.66
negix# df -h
Filesystem        Size   Used  Avail Capacity  Mounted on
ROOT              539G   4.3G   535G     1%    /
devfs             1.0K   1.0K     0B   100%    /dev
/dev/mfid0s1a     756M   213M   483M    31%    /boot
/pfs/@@-1:00001   539G   4.3G   535G     1%    /var
/pfs/@@-1:00003   539G   4.3G   535G     1%    /usr
/pfs/@@-1:00004   539G   4.3G   535G     1%    /home
/pfs/@@-1:00005   539G   4.3G   535G     1%    /usr/obj
/pfs/@@-1:00006   539G   4.3G   535G     1%    /var/crash
/pfs/@@-1:00007   539G   4.3G   535G     1%    /var/tmp
procfs            4.0K   4.0K     0B   100%    /proc
/pfs/@@-1:00008   539G   4.3G   535G     1%    /miku

7.2 Prune

スナップショット間のトランザクションの履歴を掃除する場合はpruneサブコ マンドを実行する。pfs-updateでprune-minを変更することでpruneされる間隔 を指定することもできるようだ。

negix# hammer prune /pfs/home
TID 0000000106ed17c0 - 0000000106faffc0
TID 0000000106e682a0 - 0000000106ed17c0
TID 0000000106cf8370 - 0000000106e682a0
TID 0000000106cc1af0 - 0000000106cf8370
TID 0000000106cbc7f0 - 0000000106cc1af0
TID 0000000106cb74f0 - 0000000106cbc7f0
TID 0000000106c7a0a0 - 0000000106cb74f0
TID 00000001068929c0 - 0000000106c7a0a0
TID 0000000000000001 - 00000001068929c0
Prune /pfs/home/: 9 snapshots
Prune /pfs/home/: objspace 8000000000000000:0000 7fffffffffffffff:ffff pfs_id 4
Prune /pfs/home/: prune_min is 0d/00:00:00
Prune /pfs/home/ succeeded
Pruned 0/18874 records (0 directory entries) and 0 bytes

7.3 Rebalance

rebalanceサブコマンドでは、B-Treeのバランスを再調整することができる。 rebalanceは、PFS毎に行う必要がある。

negix# hammer rebalance /pfs/usr
rebalance start 8000000000000000:0000
Rebalance /pfs/usr succeeded
Rebalance:
    11011 btree nodes scanned
    4 btree nodes deleted
    0 collision retries
    5122 btree nodes rebalanced

7.4 Reblock

reblockサブコマンドでは、いわゆるデフラグを行うことができる。rebalance と同様に、 PFS毎に行う必要がある。

negix# hammer reblock /pfs/miku
reblock start 8000000000000000:0000 free level 0
Reblock /pfs/miku succeeded
Reblocked:
    51/51 btree nodes
    2371/2371 data elements
    145759632/145759632 data bytes

7.5 Cleanup

ここまでのお掃除サブコマンドをいちいち全て行うのは面倒であるので、これ らの作業とrecopy、そして古いスナップショットの整理を纏めて行うためのコ マンドとしてcleanupが用意されている。

negix# hammer cleanup /pfs/miku
cleanup /pfs/miku            - HAMMER UPGRADE: Creating snapshots
        Creating snapshots in /var/hammer/pfs/miku
 handle PFS #8 using /var/hammer/pfs/miku
           snapshots - run
               prune - run
           rebalance - run..
             reblock - run....
              recopy - run....

7.6 Periodic

cleanupを手作業で行うのも面倒であるので、それをcronで実行するシステム がデフォルトで有効になっている。実行間隔の設定は、configサブコマンドで 参照でき、viconfigサブコマンドで変更できる。

negix# hammer config /pfs/miku
snapshots 1d 60d
prune     1d 5m
rebalance 1d 5m
#dedup     1d 5m
reblock   1d 5m
recopy    30d 10m

この例の場合、以下のように設定されている。

  • スナップショットを1日毎に作成し、作成してから60日経過したスナップ ショットは削除する。
  • 1日毎に5分間だけprune、rebalance、reblockを行う。
  • dedupは行わない。(コメントアウトされている)
  • recopyを30日毎、10分間だけ行う。

8 復旧

8.1 破損したファイルシステムからのファイルのリカバリ

recoverサブコマンドを用いることで、破損したHAMMERファイルシステムが存 在するブロックデバイスをスキャンし、ターゲットディレクトリに保存するこ とができる。このコマンドは、お亡くなりになったファイルシステムからデー タを復旧する「最後の防衛線」である。

negix# hammer -f /dev/mfid0s1d recover /home/miku/test
Running raw scan of HAMMER image, recovering to /home/miku/test
mkinode (dir) /home/miku/test/PFS00000
dir  0000000000000001:00000 entry 000000010000046d "sbin"
dir  0000000000000001:00000 entry 000000010000048b "dev"
dir  0000000000000001:00000 entry 000000010000049a "mnt"
dir  0000000000000001:00000 entry 00000001000004b7 "root"
dir  0000000000000001:00000 entry 00000001000004bb "usr"
dir  0000000000000001:00000 entry 00000001000004f0 "sys"
dir  0000000000000001:00000 entry 0000000100000551 "bin"
dir  0000000000000001:00000 entry 000000010000055e "proc"
dir  0000000000000001:00000 entry 0000000100000567 "tmp"
dir  0000000000000001:00000 entry 0000000100000575 "etc"
dir  0000000000000001:00000 entry 0000000100000637 "boot"
dir  0000000000000001:00000 entry 0000000100000688 "pfs"
dir  0000000000000001:00000 entry 000000010000076e "var"
dir  0000000000000001:00000 entry 000000010000078e "home"
dir  0000000000000001:00000 entry 00000001000007e2 "COPYRIGHT"
mkinode (dir) /home/miku/test/PFS00000/sbin
...

8.2 /pfs以下を誤って削除してしまった場合

/pfs以下にあるものはただのシンボリックリンクなので、hammer infoでPFSID を確認してシンボリックリンクを作り直す。以下は、PFSIDが8の/pfs/mikuを 削除してしまった場合の復旧例である。

negix# /pfs/miku
negix# hammer info 
Volume identification
        Label               ROOT
        No. Volumes         1
        FSID                5c95cbb8-302f-11e2-8c0e-b9ac6f12aafc
        HAMMER Version      6
Big block information
        Total           69038
        Used              603 (0.87%)
        Reserved           39 (0.06%)
        Free            68396 (99.07%)
Space information
        No. Inodes     110786
        Total size       539G (579132719104 bytes)
        Used             4.7G (0.87%)
        Reserved         312M (0.06%)
        Free             534G (99.07%)
PFS information
        PFS ID  Mode    Snaps  Mounted on
             0  MASTER      8  /
             1  MASTER      8  /var
             2  MASTER      0  /tmp
             3  MASTER      8  /usr
             4  MASTER      8  /home
             5  MASTER      0  /usr/obj
             6  MASTER      8  /var/crash
             7  MASTER      0  /var/tmp
             8  MASTER      -  not mounted
             9  SLAVE       -  not mounted
            10  SLAVE       -  not mounted
negix# ln -s @@-1:00008 /pfs/miku
negix# ls /pfs/miku 
hoge                    pf.conf            snap-20121122-2006      snap-20121122-2038      test2
mikumiku                rinrin             snap-20121122-2015      snap-20121122-2040
neginegi                snap-20121122-2003 snap-20121122-2023      test

9 その他

9.1 TransactionIDの手動作成

スナップショットを作成せずにTransactionIDのみを手動生成する場合、 synctidサブコマンドを用いる。

negix# hammer synctid /pfs/miku
0x0000000106feb9d0

9.2 B-Treeの統計情報の参照

B-Treeの統計情報を参照する場合はbstatsサブコマンドを用いる。

negix# hammer bstats
  elements iterations    lookups    inserts    deletes     splits
         0          0          0          0          0          0
      1464       7100         59          0          0          0
       999       3873         41          0          0          0
       990        116         80          7          0          0
         0          0          0          0          0          0
       350         59         29          0          0          0
     26282       8211       1333          0          0          0

9.3 I/Oの統計情報の参照

I/Oの統計情報を参照する場合はiostatsサブコマンドを用いる。PFS毎のI/Oの 統計情報は見れない(?)模様。

negix# hammer iostats
  file-rd   file-wr  dev-read dev-write inode_ops ino_flsh cmmit     undo
        0         0         0         0         0        0     0        0
        0         0         0         0         0        0     0        0
   190952         0         0         0       148        0     0        0
        0         0         0         0         0        0     0        0
        0         0         0    458752         0       23     2    27800
        0         0         0         0         0        0     0        0
        0         0         0         0         0        0     0        0
   133619         0         0         0       293        0     0        0

9.4 ファイルのHash値を参照する

ファイル毎のHAMMERディレクトリハッシュを参照する場合は、namekey1、 namekey2、namekey32サブコマンドを利用する。

negix# hammer namekey1 /
0x79d3d2d400000000
negix# hammer namekey2 /
0x3c00000f79d3d2d4
negix# hammer namekey32 /
0x79d3d2d4

9.5 blockmap

ブロックデバイス上のブロックマップをdumpする。

negix# hammer -f /dev/mfid0s1d blockmap | head -n 10
zone btree            next 2000000000000000 alloc 2fffffffffffffff
  layer1 4000000000000000 @2000000000800000 blocks-free 68410
        4000000000000000 zone=4 app=8388608 free=0
        4000000000800000 zone=4 app=8388608 free=0
        4000000001000000 zone=3 app=8388608 free=0
        4000000001800000 zone=3 app=8388608 free=0
        4000000002000000 zone=3 app=8388608 free=0
        4000000002800000 zone=3 app=8388608 free=0
        4000000003000000 zone=3 app=8388608 free=0
        4000000003800000 zone=3 app=8388608 free=0

9.6 checkmap

ブロックデバイス上のブロックマップの割り当て情報をチェックする。

negix# hammer -f /dev/mfid0s1d checkmap
Volume header   records=0 next_tid=0000000107046570
                bufoffset=0000000044040000
Collecting allocation info from B-Tree: done

9.7 show

ブロックデバイス上のB-Treeをダンプする。エラーが見つかった場合は"B"と 表示されるらしい。

negix# hammer -f /dev/mfid0s1d show| head -n 25
Volume header   records=0 next_tid=0000000107046570
                bufoffset=0000000044040000
                zone 0  next_offset=0000000000000000
                zone 1  next_offset=0000000000000000
                zone 2  next_offset=0000000000000000
                zone 3  next_offset=30000000165cb908
                zone 4  next_offset=2000000000000000
                zone 5  next_offset=0000000000000000
                zone 6  next_offset=0000000000000000
                zone 7  next_offset=0000000000000000
                zone 8  next_offset=80000002d4b96000
                zone 9  next_offset=9000000293be13f0
                zone 10 next_offset=a000000345890000
                zone 11 next_offset=b00000033cbdae70
                zone 12 next_offset=c000000000000000
                zone 13 next_offset=d000000000000000
                zone 14 next_offset=e000000000000000
                zone 15 next_offset=f000000000000000
show 80000002cf6db000 depth 0
     NODE 80000002cf6db000 cnt=05 p=0000000000000000 type=I depth=0 
       mirror 0000000107046550 fill=z8:1438=100% {
G------ ELM  0 I obj=8000000000000000 key=8000000000000000 lo=00000000 rt=00 ot=00
               d tids 0000000000000001:0000000000000001 suboff=800000029d8f8000 mirror 0000000107046550
G------ ELM  1 I obj=00000001042a3d5d key=348524d485d90000 lo=00030001 rt=11 ot=02
                 tids 00000001068912e0:0000000000000000 suboff=80000002cf711000 mirror 0000000106f5da70
G------ ELM  2 I obj=00000001044742d2 key=0000000000001fb0 lo=00030002 rt=10 ot=02

9.8 show-undo

ブロックデバイス上のUndo/Redoマップをダンプする。

negix# hammer -f /dev/mfid0s1d show-undo | head -n 10
Volume header UNDO 30000000165cb908-30000000165cb908/3000000023000000
Undo map is 560MB
3000000000000000 UNDO(0168) seq=0037fafd dataoff=200000025412bec0 bytes=320
3000000000000168 UNDO(0098) seq=0037fafe dataoff=200000025412c000 bytes=112
3000000000000200 UNDO(0200) seq=0037faff dataoff=200000025412c070 bytes=472
3000000000000400 UNDO(0200) seq=0037fb00 dataoff=200000025412c248 bytes=472
3000000000000600 UNDO(0200) seq=0037fb01 dataoff=200000025412c420 bytes=472
3000000000000800 UNDO(0200) seq=0037fb02 dataoff=200000025412c5f8 bytes=472
3000000000000a00 UNDO(0200) seq=0037fb03 dataoff=200000025412c7d0 bytes=472
3000000000000c00 UNDO(0200) seq=0037fb04 dataoff=200000025412c9a8 bytes=472

10 最後に

自宅用に静かな実験鯖が欲しいですヾ(@⌒ー⌒@)ノ

ておくれの理に導かれたmikutterユーザ会VPSは今週中に直します。

ヽ('ω')ノ三ヽ('ω')ノもうしわけねぇもうしわけねぇ

11 参考

2012年10月9日火曜日

お名前.comのVPS(メモリ4GBプラン)にFreeBSD(virtio)を導入

お名前.comのVPS(メモリ4GBプラン)をmikutterユーザ会として1年間無償で借りることができたので、 早速いろいろ試してみた。

今回はVPS上で「コミュニティーでいろいろ共用できるサーバ」にするので、コンテナ型の仮想化が一番 よさそうと考え、とりあえずFreeBSDを導入することにした。ただ、 FreeBSD9.1-RC1の時点ではまだvirtioが利用できないため、 virtioがbaseのGENERICに入った9-STABLEをビルドし導入する。

今回テストしたバージョンは以下の通り。
FreeBSD 9.1-PRERELEASE #0 r241139: Wed Oct 3 04:26:52 JST 2012

CentOS 6.2(linux-2.6.32, virtio)
dd if=/dev/zero of=test.img bs=1M count=1000
1048576000 bytes (1.0 GB) copied, 3.63471 s, 288 MB/s 
FreeBSD 9-stable(not virtio)
% dd if=/dev/zero of=test.img bs=1M count=1000
1048576000 bytes transferred in 7.655223 secs (136975241 bytes/sec)
FreeBSD 9-stable(virtio)
% dd if=/dev/zero of=test.img bs=1M count=1000
1048576000 bytes transferred in 3.158812 secs (331952641 bytes/sec)

ホストは共用なので細かい速度はあてにならないかもしれないが、 virtioを有効にしたFreeBSDはそれなりに速度が出ている模様。やはりvirtio無しは遅い。 CentOSは何度か試したところ、試したタイミングが悪かった可能性があるのでなんとも言えないものの、 速度にFreeBSDより大きなばらつきがあった。

試しに安鯖で有名なML110G7でも同様の処理をしてみた。

FreeBSD 9-stable(ML110G7)
% dd if=/dev/zero of=test.img bs=1M count=1000
 1048576000 bytes transferred in 11.833178 secs (88613221 bytes/sec)

VPSのほうがDisk I/Oは圧倒的に速いようだ。かなしい。

dmesgは以下の通り。

Copyright (c) 1992-2012 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
        The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 9.1-PRERELEASE #0 r241139: Wed Oct  3 04:26:52 JST 2012
    root@vps.m.hachune.net:/usr/obj/usr/src/sys/GENERIC amd64
CPU: Intel(R) Core(TM)2 Duo CPU     T7700  @ 2.40GHz (2533.48-MHz K8-class CPU)
  Origin = "GenuineIntel"  Id = 0x6fb  Family = 0x6  Model = 0xf  Stepping = 11
  Features=0xf8bf3ff
  Features2=0x80002201
  AMD Features=0x20100800
  AMD Features2=0x1
  TSC: P-state invariant
real memory  = 4294967296 (4096 MB)
avail memory = 4101722112 (3911 MB)
Event timer "LAPIC" quality 400
ACPI APIC Table: 
FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs
FreeBSD/SMP: 4 package(s) x 1 core(s)
 cpu0 (BSP): APIC ID:  0
 cpu1 (AP): APIC ID:  1
 cpu2 (AP): APIC ID:  2
 cpu3 (AP): APIC ID:  3
ioapic0: Changing APIC ID to 4
ioapic0  irqs 0-23 on motherboard
kbd1 at kbdmux0
acpi0:  on motherboard
acpi0: Power Button (fixed)
cpu0:  on acpi0
cpu1:  on acpi0
cpu2:  on acpi0
cpu3:  on acpi0
atrtc0:  port 0x70-0x71,0x72-0x77 irq 8 on acpi0
Event timer "RTC" frequency 32768 Hz quality 0
hpet0:  iomem 0xfed00000-0xfed003ff on acpi0                                     [46/403]
Timecounter "HPET" frequency 100000000 Hz quality 950
Timecounter "ACPI-safe" frequency 3579545 Hz quality 850
acpi_timer0: <24-bit timer at 3.579545MHz> port 0xb008-0xb00b on acpi0
pcib0:  port 0xcf8-0xcff on acpi0
pci0:  on pcib0
pci_link4: Unable to route IRQs: AE_NOT_FOUND
isab0:  at device 1.0 on pci0
isa0:  on isab0
atapci0:  port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xc000-0xc00f at device 1.1 on pci0
ata0:  at channel 0 on atapci0
ata1:  at channel 1 on atapci0
uhci0:  port 0xc020-0xc03f irq 11 at device 1.2 on pci0
usbus0: controller did not stop
usbus0 on uhci0
pci0:  at device 1.3 (no driver attached)
vgapci0:  mem 0xf0000000-0xf1ffffff,0xf2000000-0xf2000fff at device 2.0 on pci0
virtio_pci0:  port 0xc040-0xc05f mem 0xf2020000-0xf2020fff irq 11 at device 3.0 on pci0
vtnet0:  on virtio_pci0
virtio_pci0: host features: 0x711fffe3 
virtio_pci0: negotiated features: 0x110fbba3 
vtnet0: Ethernet address: 02:16:3e:68:9f:e5
virtio_pci1:  port 0xc080-0xc0bf mem 0xf2040000-0xf2040fff irq 11 at device 4.0 on pci0
vtblk0:  on virtio_pci1
virtio_pci1: host features: 0x710006d4 
virtio_pci1: negotiated features: 0x10000254 
vtblk0: 81920MB (167772160 512 byte sectors)
virtio_pci2:  port 0xc0c0-0xc0ff mem 0xf2041000-0xf2041fff irq 10 at device 5.0 on pci0
vtblk1:  on virtio_pci2
virtio_pci2: host features: 0x710006d4 
virtio_pci2: negotiated features: 0x10000254 
vtblk1: 327680MB (671088640 512 byte sectors)
virtio_pci3:  port 0xc100-0xc11f irq 10 at device 6.0 on pci0
vtballoon0:  on virtio_pci3
virtio_pci3: host features: 0x71000002 
virtio_pci3: negotiated features: 0x0                                                                         [7/403]
atkbdc0:  port 0x60,0x64 irq 1 on acpi0
atkbd0:  irq 1 on atkbdc0
kbd0 at atkbd0
atkbd0: [GIANT-LOCKED]
psm0:  irq 12 on atkbdc0
psm0: [GIANT-LOCKED]
psm0: model IntelliMouse Explorer, device ID 4
fdc0:  port 0x3f2-0x3f5,0x3f7 irq 6 drq 2 on acpi0
fdc0: does not respond
device_attach: fdc0 attach returned 6
uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0
uart0: console (9600,n,8,1)
orm0:  at iomem 0xc9000-0xc97ff on isa0
sc0:  at flags 0x100 on isa0
sc0: VGA <16 virtual consoles, flags=0x100>
vga0:  at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0
attimer0:  at port 0x40 on isa0
Timecounter "i8254" frequency 1193182 Hz quality 0
Event timer "i8254" frequency 1193182 Hz quality 100
fdc0: No FDOUT register!
ppc0: cannot reserve I/O port range
ctl: CAM Target Layer loaded
Timecounters tick every 1.000 msec
usbus0: 12Mbps Full Speed USB v1.0
ugen0.1:  at usbus0
uhub0:  on usbus0
GEOM: vtbd1: corrupt or invalid GPT detected.
GEOM: vtbd1: GPT rejected -- may not be recoverable.
uhub0: 2 ports with 2 removable, self powered
ugen0.2:  at usbus0
uhid0:  on usbus0
cd0 at ata0 bus 0 scbus0 target 0 lun 0
cd0:  Removable CD-ROM SCSI-0 device 
cd0: 16.700MB/s transfers (WDMA2, ATAPI 12bytes, PIO 65534bytes)
cd0: Attempt to query device size failed: NOT READY, Medium not present
SMP: AP CPU #1 Launched!
SMP: AP CPU #3 Launched!
SMP: AP CPU #2 Launched!
Timecounter "TSC-low" frequency 9896395 Hz quality 1000
Trying to mount root from ufs:/dev/vtbd0p3 [rw]...

試しにメモリ1GBプラン(60日体験版)も試してみたところ、CentOS6.2(linux-2.6.32, virtio有効)で だいたい100〜130MB/sだった。どうやら容量だけでなく速度の面でも4GBプランはメリットがある模様。

余談

いつものようにファイアウォールはpfでいこうとしたところ、pfctl -eした瞬間 何故かダウンロードのみ激遅(10KB/sぐらい)になったりと散々だったので、ipfwを覚えることに。 VIMAGEもいろいろと不具合があってハマりまくったので今回は見送り。

2012年10月8日月曜日

OpenBSDでvirtioを利用する

OpenBSDにvirtioが入ったようなので、早速使ってみる。
今のところ5.2には無く-currentにのみ入っているようなので、素直に-currentをビルド。 -currentならGENERICにvirtioが入っているので、特別な設定は要らない。 ビルド手順については、 公式のドキュメント通りに行った。

…がしかし、 sys/arch/amd64/amd64/cpu.cのコンパイルが失敗する。

{standard input}: Assembler messages: 
{standard input}:198: Error: no such instruction: `rdrand %rbx'
*** Error code 1

どうやらインラインアセンブラでこけているようだが、rdrandなんて見たこと無いのでググってみた。
http://en.wikipedia.org/wiki/RdRand
どうやら、インなんとかさんのIvy Bridgeで追加された乱数生成命令らしい。 そんなものうちのAMD E-450には無いので、rdrand()の中を全部さくっとコメントアウト。 ついでにrdrandでgrepして引っかかったidentcpu.cのhas_rdrand = 1をhas_rdrand = 0に変更。
rdrand()自体がr1.51で最近追加されたばかりの関数のようなので、 たぶんこれで大丈夫じゃないかなーと思いビルドしなおしたらあっさり通った。 そしてユーザランドも問題なくコンパイルできた。
dmesgは以下の通り。

OpenBSD 5.2-current (HACHUNE.MP) #0: Mon Oct  8 17:23:02 JST 2012
    root@obsd.k.hachune.net:/usr/src/sys/arch/amd64/compile/HACHUNE.MP
real mem = 1072685056 (1022MB)
avail mem = 1024802816 (977MB)
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xfd980 (11 entries)
bios0: vendor Bochs version "Bochs" date 01/01/2007
bios0: Bochs Bochs
acpi0 at bios0: rev 0
acpi0: sleep states S3 S4 S5
acpi0: tables DSDT FACP SSDT APIC HPET SSDT
acpi0: wakeup devices
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimadt0 at acpi0 addr 0xfee00000: PC-AT compat
acpihpet0 at acpi0: 100000000 Hz
acpiprt0 at acpi0: bus 0 (PCI0)
mpbios0 at bios0: Intel MP Specification 1.4
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: QEMU Virtual CPU version 1.2.0, 1646.91 MHz
cpu0: FPU,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,SSE3,CX16,POPCNT,NXE,LONG,LAHF,SVM,ABM,SSE4A
cpu0: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 512KB 64b/line 16-way L2 cache
cpu0: ITLB 255 4KB entries direct-mapped, 255 4MB entries direct-mapped
cpu0: DTLB 255 4KB entries direct-mapped, 255 4MB entries direct-mapped
cpu0: apic clock running at 1009MHz
cpu1 at mainbus0: apid 1 (application processor)
cpu1: QEMU Virtual CPU version 1.2.0, 1663.20 MHz
cpu1: FPU,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,SSE3,CX16,POPCNT,NXE,LONG,LAHF,SVM,ABM,SSE4A
cpu1: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 512KB 64b/line 16-way L2 cache
cpu1: ITLB 255 4KB entries direct-mapped, 255 4MB entries direct-mapped
cpu1: DTLB 255 4KB entries direct-mapped, 255 4MB entries direct-mapped
mpbios0: bus 0 is type PCI   
mpbios0: bus 1 is type ISA   
ioapic0 at mainbus0: apid 2 pa 0xfec00000, version 11, 24 pins
ioapic0: misconfigured as apic 0, remapped to apid 2
pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 "Intel 82441FX" rev 0x02
pcib0 at pci0 dev 1 function 0 "Intel 82371SB ISA" rev 0x00
pciide0 at pci0 dev 1 function 1 "Intel 82371SB IDE" rev 0x00: DMA, channel 0 wired to compatibility, channel 1 wired to compatibility
pciide0: channel 0 disabled (no drives)
atapiscsi0 at pciide0 channel 1 drive 0
scsibus0 at atapiscsi0: 2 targets
cd0 at scsibus0 targ 0 lun 0:  ATAPI 5/cdrom removable
cd0(pciide0:1:0): using PIO mode 4, DMA mode 2
piixpm0 at pci0 dev 1 function 3 "Intel 82371AB Power" rev 0x03: apic 2 int 9
iic0 at piixpm0
iic0: addr 0x4c 48=00 words 00=0000 01=0000 02=0000 03=0000 04=0000 05=0000 06=0000 07=0000
iic0: addr 0x4e 48=00 words 00=0000 01=0000 02=0000 03=0000 04=0000 05=0000 06=0000 07=0000
vga1 at pci0 dev 2 function 0 "Cirrus Logic CL-GD5446" rev 0x00
wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
virtio0 at pci0 dev 3 function 0 "Qumranet Virtio Network" rev 0x00: Virtio Network Device
vio0 at virtio0: address 52:54:00:12:34:56
virtio0: apic 2 int 11
virtio1 at pci0 dev 4 function 0 "Qumranet Virtio Storage" rev 0x00: Virtio Block Device
vioblk0 at virtio1
scsibus1 at vioblk0: 2 targets
sd0 at scsibus1 targ 0 lun 0:  SCSI3 0/direct fixed
sd0: 5000MB, 512 bytes/sector, 10240000 sectors
virtio1: apic 2 int 11
isa0 at pcib0
isadma0 at isa0
com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo
com0: console
pckbc0 at isa0 port 0x60/5
pckbd0 at pckbc0 (kbd slot)
pckbc0: using irq 1 for kbd slot
wskbd0 at pckbd0: console keyboard, using wsdisplay0
pms0 at pckbc0 (aux slot)
pckbc0: using irq 12 for aux slot
wsmouse0 at pms0 mux 0
pcppi0 at isa0 port 0x61
spkr0 at pcppi0
lpt0 at isa0 port 0x378/4 irq 7
fdc0 at isa0 port 0x3f0/6 irq 6 drq 2
fd0 at fdc0 drive 0: 1.44MB 80 cyl, 2 head, 18 sec
fd1 at fdc0 drive 1: density unknown
nvram: invalid checksum
mtrr: Pentium Pro MTRR support
vscsi0 at root
scsibus2 at vscsi0: 256 targets
softraid0 at root
scsibus3 at softraid0: 256 targets
root on sd0a (cf20ab2e3b470529.a) swap on sd0b dump on sd0b
clock: unknown CMOS layout

肝心のディスク読み書き速度は以下の通り。

  • virtioなし: read 29767487 bytes/sec, write 21957414 bytes/sec
  • virtioあり: read 53455607 bytes/sec, write 46648054 bytes/sec

virtioを有効にするとだいたい2倍ぐらい速くなるようだ。 これでOpenBSDのBHyVe上への導入も捗る…?

追記: 先にユーザランド更新しとけばrdrandで文句言われなくなるんじゃね?と教えていただいたので、やりなおしてみます。
-> 無事できましたヾ(@⌒ー⌒@)ノ

2012年9月15日土曜日

OSC 2012 Tokyo/Fallにmikutterユーザ会として出展しました

9月7,8日に開催されたオープンソースカンファレンス2012 Tokyo/Fallに mikutterユーザ会として出展しました。
http://www.ospn.jp/osc2012-fall/

去年のOSC仙台以来2回目の参加でいきなりブース出展、しかも一番規模が大 きな東京会場ということでかなり不安もありましたが、お隣の日本NetBSDユー ザグループさんやmikutterのユーザさん達等からいろいろと支援して頂いたり しつつ、mikutterの薄い本vol.2の印刷が間に合わないトラブル等もありましたが、 なんとか無事に終えることが出来ました。ありがとうございました。

mikutterブースの様子。mikutter開発者の @toshi_aさんは、残念ながら お仕事の都合で来れないということで、モックアップとしての参加に。隣に ちびづるん(モックアップ)なるものも参加していたり。 (あっ、マミさ…あれ? 違う… という参加者のつぶやきが聞こえてきたりも)

いろいろなキャラクターが同居しているのもオープンソース界隈ではよくあること(?)
(ちなみに、mikutterグッズはほぼ全てお隣のNetBSDユーザーグループさんからの提供です。)

いろいろと頂いたもの。「mikutterブース」として用意していったものは LiveUSBメモリイメージとmikutterのうすい本 vol.2のサンプル程度だったのですが、 いろいろなブースを巡っていたらいつの間にかバッグがノベルティだらけに。 特にデカかったのはOpenSolarisの本。1000ページ近くあり、持って帰るのが大変な位でした。 (オライリー本は一日目に買っておいて良かった...)

流石に何も作らず持って行かないのはマズいと急遽作成したmikutter LiveUSBメモリイメージ。 配布条件が「4GB以上の全削除可能なUSBメモリを持っている事」 という割と狭い感じでしたが、それでも10人近くの方がUSBメモリを持参してきてくれました。 (中にはわざわざ新品を買ってきたという方も。もうしわけねぇヽ('ω')ノ三ヽ('ω')ノ)

そしてこのカンファレンス中に「mikutterがDebianのパッケージになる…かもしれない」という話が 浮上。Debianのパッケージになると、その派生ディストリビューションにもパッケージとして入ること もあるため、これはwktkしつつ待ちたいところ。
(mikutterのDebianパッケージの問題として、mikutter本体とskinデータのライセンスの違いが一番大きい。 mikutter本体はGPLv3であるものの、skinデータは初音ミクの歌声データ等が含まれる為GPL互換にはできず、 DFSGに適合できない。その点について解決するために、初音ミクに関連するskinを含まないmikutterを 準備する必要がある…という感じ。)

その他にも、お名前.comさんからmikutterユーザ会として VPS(KVM) 4GBプラン 1年分を頂いたりもしました。 今後これを皆で使えるように整備するのが当面の仕事になりそう。

これからもmikutterをよろしくお願いしますヾ(@⌒ー⌒@)ノ

2012年9月13日木曜日

OpenSMTPDからGmailのSMTPサーバを利用する

OpenSMTPDとは

OpenSMTPDはOpenBSDプロジェクトのうちの一部として開発されているSMTPデー モンで、OpenBSDの標準システムに含まれており、またLinux等への移植性も確 保されている。

今回は、Arch Linux上のOpenSMTPDを用いて自宅ローカルネットワークからの メールをGmailのSMTPサーバを経由して送信できるようにする。

OpenSMTPDのインストール

ArchLinuxのOpenSMTPDパッケージはAURにあるので、yaourtを用いてビルドし インストールする。特にPKGBUILDの編集などは必要ないようだ。

$ yaourt -S opensmtpd

インストールされる全ファイルの一覧は以下の通りである。軽量・安全・簡単を 売りにしているだけあって、ファイル数は少なく抑えられている。

[miku@test mail]$ yaourt -Ql opensmtpd
opensmtpd /etc/
opensmtpd /etc/mail/
opensmtpd /etc/mail/smtpd.conf
opensmtpd /etc/rc.d/
opensmtpd /etc/rc.d/smtpd
opensmtpd /usr/
opensmtpd /usr/bin/
opensmtpd /usr/bin/mailq
opensmtpd /usr/bin/newaliases
opensmtpd /usr/lib/
opensmtpd /usr/lib/systemd/
opensmtpd /usr/lib/systemd/system/
opensmtpd /usr/lib/systemd/system/smtpd.service
opensmtpd /usr/libexec/
opensmtpd /usr/libexec/mail.local
opensmtpd /usr/libexec/opensmtpd-portable/
opensmtpd /usr/libexec/opensmtpd-portable/makemap
opensmtpd /usr/sbin/
opensmtpd /usr/sbin/makemap
opensmtpd /usr/sbin/smtpctl
opensmtpd /usr/sbin/smtpd
opensmtpd /usr/share/
opensmtpd /usr/share/man/
opensmtpd /usr/share/man/man5/
opensmtpd /usr/share/man/man5/smtpd.conf.5.gz
opensmtpd /usr/share/man/man8/
opensmtpd /usr/share/man/man8/makemap.8.gz
opensmtpd /usr/share/man/man8/newaliases.8.gz
opensmtpd /usr/share/man/man8/smtpctl.8.gz
opensmtpd /usr/share/man/man8/smtpd.8.gz

smtpd.confの編集

デフォルトのsmtpd.confは以下のようになっている。設定ファイルの形式は、 pf.conf等に似ている。127.0.0.1でlistenしているため、内部へのmbox形式の メール配送と外部へのメール送信のリレーのみを行うようになっている。

listenするインターフェース又はネットワークを10.0.0.0/8等に変更すれば、 LAN内のホストからの要求も受け付けるようになる。この際、accept from 〜等で ネットワーク毎にルールを設定することもできる。

# $OpenBSD: smtpd.conf,v 1.2 2009/11/03 22:32:10 gilles Exp $

# This is the smtpd server system-wide configuration file.
# See smtpd.conf(5) for more information.

# XXX try to find a portable way to get the IP interface
#listen on lo0
listen on 127.0.0.1

map "aliases" { source db "/etc/mail/aliases.db" }

accept for local alias aliases deliver to mbox
accept for all relay

しかし、このままでは内部への配送は正しく行われるが、外部へのリレーは利 用しているプロバイダや回線の契約によってはOP25Bにより正しく行われない可 能性がある。そこで、GmailのSMTPサーバを経由し外部へのメール送信を行う ように設定を変更する。

Gmailでは、STARTTLSを用いた認証を行うことでSMTPサーバを利用できる。 サーバホスト名はsmtp.gmail.com、ポート番号は587、アカウント名は"gmail アカウント@gmail.com"、パスワードはGmailのものを用いる。

以上の変更点を適用したsmtpd.confは以下のようになった。

listen on lo

map "aliases" { source db "/etc/mail/aliases.db" }
map "secrets" { source db "/etc/mail/secrets.db" }

accept for local alias "aliases" deliver to mbox
accept from all for all relay via tls+auth://smtp.gmail.com:587 auth "secrets"

この他にも、Gmailのユーザ名とパスワードを保持刷るためのファイル /etc/mail/secrets.dbが必要になる。このファイルはプレーンテキストで以下 のように書かれた/etc/mail/secretsを、makemapコマンドを用いて変換したも のである。

smtp.gmail.com Gmailのアカウント名@gmail.com:Gmailのパスワード

このsecretsとsecrets.dbのパーミッションは640、オーナーはroot:_smtpdに 設定する。

smtpdの起動

smtpdの動作を確認するため、まずはコマンドラインから-d(Do not daemonize)と-v(verbose output)オプションを付けて起動する。

試しにメールを送信してみる。

[miku@test ~]$ telnet localhost 25
Trying ::1...
Connected to localhost.
Escape character is '^]'.
220 test.k.hachune.net ESMTP OpenSMTPD
EHLO hachune.net
250-test.k.hachune.net Hello hachune.net [IPv6:::1], pleased to meet
you
250-8BITMIME
250-ENHANCEDSTATUSCODES
250-SIZE 18446744073709551615
250 HELP
MAIL FROM:
250 2.1.0 Sender ok
RCPT TO:
250 2.0.0 Recipient ok
DATA
354 Enter mail, end with "." on a line by itself
Subject: SMTPD Test
From: Miku Hachune
To: Phenomer
Date: Thu, 13 Sep 2012 17:29:26 +0900

mikumiku
.
QUIT

メールが正しく届いていればOK、もし届いていないようであればmailqや端末 上のログを確認する。 このままOpenSMTPDを使い続ける場合は、/etc/rc.confのDAEMONSにsmtpdを追 加しておく。

参考

OpenSMTPD
http://www.opensmtpd.org/

その他のメール クライアントの設定 - Gmail ヘルプ
https://support.google.com/mail/bin/answer.py?hl=ja&answer=78799

2012年5月16日水曜日

Arch LinuxのXenでxlコマンドが利用できない件

ノートPC(X121e)にArchLinuxを入れてXen DOM0で遊んでいるのだが、xlコマンドがうまく動作せず、 Xen4.1の時点ではdeprecatedなxmコマンドをずっと使っていた。しかし乗り換えない訳にもいかないので 原因を探ってみた。

xenstored起動スクリプトの修正

まず一つ目の、xenstoredが起動しているにも関わらずxenstoredが動いてない(?)と怒られる問題。 単純にpidファイルのパスがArchとXenとで合っていなかっただけだった。 /etc/rc.d/xencommonsのxenstored起動部分を書き換えるだけでOK。

# xenstored --pid-file=/run/daemons/xenstored.pid $XENSTORED_ARGS
xenstored --pid-file=/var/run/xenstored.pid $XENSTORED_ARGS

停止時も考慮しないといけないよなぁ、と思ってdo_stop()を見てみたが、

printhl "WARNING: Not stopping xenstored, as it cannot be restarted."

そいつは一度起動したら止められないぜ!…ということらしい。

xl consoleの不具合

xlコマンドは実行できるようになったものの、何故かxl consoleで consoleに入れない。エラー内容も「失敗した」と出るだけ。 仕方がないのでstraceしてみたら…

execve("/usr/lib64/xen/bin/xenconsole", ["/usr/lib64/xen/bin/xenconsole", "4", "--num", "0", "--type", "pv"],
 [/* 15 vars */]) = -1 ENOENT (No such file or directory)

/usr/lib64ってなんですかー。 どうやら、xenconsoleバイナリの参照先が/usr/lib64決め打ちになっている模様。どこのディストリの名残りなのやら…。 とりあえずln -s /usr/lib /usr/lib64してあっさり解決。

miku@hachune% sudo xl create -c netbsd.cfg
パスワード:
Parsing config file netbsd.cfg
xc: error: panic: xc_dom_bzimageloader.c:556: xc_dom_probe_bzimage_kernel: kernel is not a
 bzImage: Invalid kernel
Daemon running with PID 6683
                            Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 
2004, 2005,
    2006, 2007, 2008, 2009, 2010, 2011, 2012
    The NetBSD Foundation, Inc.  All rights reserved.
Copyright (c) 1982, 1986, 1989, 1991, 1993
    The Regents of the University of California.  All rights reserved.

NetBSD 6.0_BETA (HACHUNE_U) #0: Thu Apr 26 19:16:15 JST 2012
        miku@hachune.hachune.net:/tmp/netbsd/sys/arch/amd64/compile/HACHUNE_U
total memory = 512 MB
avail memory = 486 MB
mainbus0 (root)
hypervisor0 at mainbus0: Xen version 4.1.2
vcpu0 at hypervisor0: AMD E-450 APU with Radeon(tm) HD Graphics, id 0x500f20
xenbus0 at hypervisor0: Xen Virtual Bus Interface
xencons0 at hypervisor0: Xen Virtual Console Driver
xenbus: can't get state for device/suspend/event-channel (2)
xbd0 at xenbus0 id 0: Xen Virtual Block Device Interface
xennet0 at xenbus0 id 0: Xen Virtual Network Interface
xennet0: MAC address 00:16:3e:39:03:10
balloon0 at xenbus0 id 0: Xen Balloon driver
balloon0: current reservation: 524288 KiB
xennet0: using RX copy mode
xenbus: can't get state for device/suspend/event-channel (2)
balloon0: current reservation: 131072 pages => target: 131072 pages
ignore shutdown request: 
xenbus: can't get state for device/suspend/event-channel (2)
xenbus: can't get state for device/suspend/event-channel (2)
xenbus: can't get state for device/suspend/event-channel (2)
xenbus: can't get state for device/suspend/event-channel (2)
xenbus: can't get state for device/suspend/event-channel (2)
xenbus: can't get state for device/suspend/event-channel (2)
xenbus: can't get state for device/suspend/event-channel (2)
xenbus: can't get state for device/suspend/event-channel (2)
boot device: xbd0
root on xbd0a dumps on xbd0b
root file system type: ffs
Wed May 16 09:56:39 JST 2012
Starting root file system check:
/dev/rxbd0a: file system is clean; not checking
Starting file system checks:
Setting tty flags.
Setting sysctl variables:
ddb.onpanic: 1 -> 0
Starting network.
Hostname: netbsd.hachune.net
IPv6 mode: host
Configuring network interfaces: xennet0add net default: gateway 10.39.3.1
.
Adding interface aliases:.
Building databases: dev, utmp, utmpx.
Starting syslogd.
Mounting all filesystems...
Clearing temporary files.
Updating fontconfig cache: done.
Checking quotas: done.
Starting virecover.
Checking for core dump...
savecore: /dev/rxbd0b: Device not configured
May 16 09:56:46 netbsd savecore: /dev/rxbd0b: Device not configured
Starting local daemons:.
Updating motd.
Starting powerd.
Starting sshd.
Starting inetd.
Starting cron.
Wed May 16 09:56:53 JST 2012

NetBSD/amd64 (netbsd.hachune.net) (console)

login: miku
Password:
May 16 10:23:51 netbsd login: miku on tty console
Last login: Tue Apr 24 03:50:07 2012 on console
Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005,
    2006, 2007, 2008, 2009, 2010, 2011, 2012
    The NetBSD Foundation, Inc.  All rights reserved.
Copyright (c) 1982, 1986, 1989, 1991, 1993
    The Regents of the University of California.  All rights reserved.

NetBSD 6.0_BETA (HACHUNE_U) #0: Thu Apr 26 19:16:15 JST 2012

Welcome to NetBSD!

This system is running a beta release of the NetBSD operating system, aimed
at stabilizing the next formal release.  It is close to formal release quality,
but may still contain bugs, even serious ones.  Please bear this in mind and
use the system with care.

You are encouraged to test this version as thoroughly as possible.  Should you
encounter any problem, please report it back to the development team using the
send-pr(1) utility (requires a working MTA).  If yours is not properly set up,
use the web interface at: http://www.NetBSD.org/support/send-pr.html

Thank you for helping us test and improve this beta NetBSD release.

netbsd$

DOMUがNetBSDだからかInvalid kernelとか出ていたり、いろいろとエラーメッセージが出ているが、 とりあえず動いているので気にしないことにする。

Xen Documentation
http://xen.org/support/generated.html

2012年4月7日土曜日

進学、そして引越し

研究生生活も終盤の2月に、これが最後のチャンスのつもりで受験した院試に合格。 これまで二十数年住み続けた山形県酒田市を離れ、神奈川県川崎市にお引越し。

今までは「文系大学生」から「文系研究生」だった訳だが、いつの間にか「情報系大学院生」に。 大学入学した時はまさかこんなことになるとは思ってもみなかった。

いろいろと不安が無いわけでもないが、せっかくの機会、無駄にしないよう頑張っていきたい。

2012年3月3日土曜日

Arch Linuxの野良リポジトリを作る

Arch Linuxはパッケージ更新が早くて新しもの好きには嬉しいディストリなのだが、 公式リポジトリにあるものでは少々物足りない場合がよくある。 AURも含めればかなりパッケージ量は増える のだが、EeePC等でパッケージビルド作業を行うのは少々辛い。

そこで、一度他のマシンで作製したパッケージを他のマシンでも利用できるように、 自前のリポジトリを構築してみようと思う。

HTTPサーバを用意

とりあえず公開用のHTTPサーバとディレクトリを用意する。 わざわざApacheやらnginxを準備するのは面倒くさいので、rubyでパッと作ってしまう。

miku@hatsune% ruby -r webrick -e "WEBrick::HTTPServer.new(:Port=>3939,:DocumentRoot=> '/var/repo').start"

終了する時はpkill -kill rubyで。

4/15追記: ruby1.9なら、以下のようにするとCtrl-cで終了できるようになるので楽。

miku@hatsune% ruby -r webrick -e "WEBrick::HTTPServer.new(:Port=>3939,:DocumentRoot=> '/var/repo').tap{|sv| trap(:INT){sv.stop}}.start"

パッケージを作成

AURのパッケージのビルド&インストールには、 yaourtを 普段利用している。yaourtでは、ほとんどpacmanと同様の操作感でAURのパッケージを 扱うことができる。 以下の例は、通常のリポジトリとAURのリポジトリを更新し、 mozcをインストールするものである。

miku@hatsune% yaourt -Syua
refresh & upgrade...
miku@hatsune% yaourt -S mozc
build & install...

この操作でmozcがビルド&インストールされ、/tmp/yaourt-tmp-miku/aur-mozc以下にパッケージ (ibus-mozc-1.3.975.102-2-x86_64.pkg.tar.xz, mozc-1.3.975.102-2-x86_64.pkg.tar.xz)ができている。 このパッケージをインストールする前に公開するリポジトリのディレクトリ(ここでは/var/repo)にコピーしておく。

4/15追記: /etc/yaoutrcを以下のように設定しておくとパッケージがPKGDESTで指定したディレクトリに追加される模様。

EXPORT=1
PKGDEST=/var/repo

リポジトリに追加

Archのリポジトリの管理には、repo-addコマンドを用いる。操作はいたって簡単。リポジトリのDBへのパスと リポジトリに追加するパッケージへのパスを引数に与え実行するだけ。

miku@hatsune% repo-add /var/repo/hachune.db /var/repo/mozc-1.3.975.102-2-x86_64.pkg.tar.xz

DBがまだ存在しない場合は自動的に作成される。これだけで、Arch Linuxのリポジトリとして機能するようになる。

リポジトリを利用

リポジトリが作成できたので、今度は別ホストからこのリポジトリを利用する。 これも単純で、/etc/pacman.confに以下を追加すればよい。

[hatsune]
Server = http://10.39.39.39:3939/

いつも通りpacman -Ss mozcすると…

miku@hachune% pacman -Ss mozc
hatsune/ibus-mozc 1.3.975.102-2 (mozc-im)
    IBus engine module for Mozc
hatsune/mozc 1.3.975.102-2 (mozc-im)
    A Japanese Input Method for Chromium OS, Windows, Mac and Linux (the Open
    Source Edition of Google Japanese Input)

mozcをリポジトリ上のパッケージとして利用することができるようになった。

もしかしたらもっと便利な方法があるのかもしれないが、 とりあえずこれでもそれなりに楽なのでよしとしておくことにする。 またパッケージの署名も可能なようだが、今は気にしない。

2012年1月30日月曜日

NetBSDでぷららのIPv6を利用する

昨年IPv4アドレスが枯渇すると同時にふつうのプロバイダでもじわじわと対応が始まった ネイティブIPv6接続機能。我が家でサブ回線として利用していた plalaでも提供されていたが、 ようやく自宅側の環境が整いつつあるので今になって試してみた。

IPv6にはIPv6対応トンネルアダプタが 必要!」なんて書いてあるが、そんなもんいらねぇんじゃねーの?、ということの確認も兼ねて。

dhcp6cを用意

plalaのIPv6ではPPPoE接続しDHCPv6でアドレスブロックを取得する。 そこで、DHCPv6クライアントをpkgsrcからビルドする。

# cd /usr/pkgsrc/net/wide-dhcpv6
# make install clean
# megurine$ dhcp6c    
usage: dhcp6c [-c configfile] [-dDfi] [-p pid-file] interface [interfaces...]

あっさりと終了。

PPPoEを設定

PPPoE接続の設定はIPv4と同じだが、plalaのIPv6ではIPv4とは異なるログイン IDが必要になる。(詳細: http://www.plala.or.jp/ipv6/access/flow/) パスワードはIPv4と同じでよいらしい。 我が家の場合は光ホームなのでユーザID + @v6h.plala.or.jpとなる。 今回設定した/etc/ifconfig.pppoe1は以下の通り。

create
! /sbin/ifconfig re0 up
! /sbin/pppoectl -e re0 pppoe1
! /sbin/pppoectl pppoe1 myauthproto=chap \
  myauthname=ユーザID@v6h.plala.or.jp \
  myauthsecret=パスワード max-auth-failure=0
up

pppoecfg pppoe1コマンドを実行してphaseがnetworkになっていれば、 接続が確立されている。

megurine$ sudo pppoectl pppoe1
Password:
pppoe1: phase=network
        myauthproto=chap myauthname="ユーザID@v6h.plala.or.jp"
        lcp timeout: 1.000 s
        idle timeout = disabled
        max-auth-failure = 0
        max-noreceive = 15 seconds
        max-alive-missed = 3 unanswered echo requests

pf.confの編集

IPv6でもパケットフィルタは必要、ということでpf.confをIPv6用に設定し直す 必要がある。アドレスの取得にはDHCPv6を用いるので、以下のポートについて検討する 必要があるようだ。

dhcpv6-client   546/tcp    # DHCPv6 Client
dhcpv6-client   546/udp    # DHCPv6 Client
dhcpv6-server   547/tcp    # DHCPv6 Server
dhcpv6-server   547/udp    # DHCPv6 Server

細かいルールは環境や管理者のポリシーによって異なるので、dhcp6cを実行しつつtcpdumpで様子を 見ながら設定を変更すればいいんじゃないかなぁ、と思う(ぇ

21:34:20.077819 PPPoE  [ses 0x3a6f] IP6 fe80::21b:21ff:fec6:d3bc.546 > ff02::1:2.547: dhcp6 solicit
21:34:20.099950 PPPoE  [ses 0x3a6f] IP6 fe80::90:1a00:41a3:dd40.547 > fe80::21b:21ff:fec6:d3bc.546: dhcp6 advertise
21:34:21.088076 PPPoE  [ses 0x3a6f] IP6 fe80::21b:21ff:fec6:d3bc.546 > ff02::1:2.547: dhcp6 request
21:34:21.111510 PPPoE  [ses 0x3a6f] IP6 fe80::90:1a00:41a3:dd40.547 > fe80::21b:21ff:fec6:d3bc.546: dhcp6 reply

リンクローカル・マルチキャストな送信とリンクローカルなユニキャストへの送受信について、 許可が必要な感じ…だろうか。

dhcp6c.confの編集

DHCPv6クライアントは設定が必須のようなので、/usr/pkg/share/examples/wide-dhcpv6/dhcp6c.conf やgoogle先生を参考に/usr/pkg/etc/dhcp6c.confを作成する。IPv4のPPPoE接続ではpppoeデバイス自体に アドレスが割り当てられていたが、DHCPv6ではprefixを割り当てるデバイスを指定する模様。ここではwm0 とした。

interface pppoe1 {
        send ia-pd 0;
};

id-assoc pd {
        prefix-interface wm0 {
                sla-id 1;
                sla-len 0;
        };
};

設定ファイルの作成が終わりPPPoE接続が確立されているなら、 # dhcp6c pppoe1のようにDHCPv6クライアントを起動する。

ルートの設定

DHCPv6でアドレスをwm0に割り当てることができたのだが、dhcp6c.confの書き方が悪いのかルートも resolv.confも設定されなかった。仕方が無いのでpppoe1へデフォルトルートを手動で割り当てる。

sudo route add -inet6 default -iface fe80::21b:21ff:fec6:d3%pppoe1

とりあえず通信をテスト。

megurine$ ping6 -c 3 ipv6.google.com 
PING6(56=40+8+8 bytes) 2400:7800:4000:d00:21b:21ff:fec6:d3bc --> 2404:6800:4004:805::1012
16 bytes from 2404:6800:4004:805::1012, icmp_seq=0 hlim=55 time=44.717 ms
16 bytes from 2404:6800:4004:805::1012, icmp_seq=1 hlim=55 time=44.804 ms
16 bytes from 2404:6800:4004:805::1012, icmp_seq=2 hlim=55 time=44.897 ms

--- ipv6.l.google.com ping6 statistics ---
3 packets transmitted, 3 packets received, 0.0% packet loss
round-trip min/avg/max/std-dev = 44.717/44.806/44.897/0.090 ms

比較用に、月1000円固定IPv4アドレスの某プロバイダのほうもテスト。

megurine$ ping -c 3 www.google.com   
PING www.l.google.com (74.125.235.144): 56 data bytes
64 bytes from 74.125.235.144: icmp_seq=0 ttl=54 time=19.173 ms
64 bytes from 74.125.235.144: icmp_seq=1 ttl=54 time=19.139 ms
64 bytes from 74.125.235.144: icmp_seq=2 ttl=54 time=19.429 ms

----www.l.google.com PING Statistics----
3 packets transmitted, 3 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 19.139/19.247/19.429/0.159 ms

サーバが違うのかv6のほうが応答速度が圧倒的に遅くなってしまった。

IPv6といえばkame.net。kame.netに打ってみる。

megurine$ ping6 -c 3 orange.kame.net
PING6(56=40+8+8 bytes) 2400:7800:4000:d00:21b:21ff:fec6:d3bc --> 2001:200:dff:fff1:216:3eff:feb1:44d7
16 bytes from 2001:200:dff:fff1:216:3eff:feb1:44d7, icmp_seq=0 hlim=54 time=33.162 ms
16 bytes from 2001:200:dff:fff1:216:3eff:feb1:44d7, icmp_seq=1 hlim=54 time=36.307 ms
16 bytes from 2001:200:dff:fff1:216:3eff:feb1:44d7, icmp_seq=2 hlim=54 time=33.538 ms

--- orange.kame.net ping6 statistics ---
3 packets transmitted, 3 packets received, 0.0% packet loss
round-trip min/avg/max/std-dev = 33.162/34.336/36.307/1.718 ms
megurine$ ping -c 3 orange.kame.net  
PING orange.kame.net (203.178.141.194): 56 data bytes
64 bytes from 203.178.141.194: icmp_seq=0 ttl=48 time=32.123 ms
64 bytes from 203.178.141.194: icmp_seq=1 ttl=48 time=31.671 ms
64 bytes from 203.178.141.194: icmp_seq=2 ttl=48 time=31.441 ms

----orange.kame.net PING Statistics----
3 packets transmitted, 3 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 31.441/31.745/32.123/0.347 ms

ついでにipv6.2ch.netにも打ってみる。

megurine$ ping6 -c 3 ipv6.2ch.net
PING6(56=40+8+8 bytes) 2400:7800:4000:d00:21b:21ff:fec6:d3bc --> 2407:3000:6:175::12
16 bytes from 2407:3000:6:175::12, icmp_seq=0 hlim=55 time=22.456 ms
16 bytes from 2407:3000:6:175::12, icmp_seq=1 hlim=55 time=22.704 ms
16 bytes from 2407:3000:6:175::12, icmp_seq=2 hlim=55 time=22.587 ms

--- ipv6.2ch.net ping6 statistics ---
3 packets transmitted, 3 packets received, 0.0% packet loss
round-trip min/avg/max/std-dev = 22.456/22.582/22.704/0.124 ms
megurine$ ping -c 3 ipv6.2ch.net  
PING ipv6.2ch.net (125.6.175.12): 56 data bytes
64 bytes from 125.6.175.12: icmp_seq=0 ttl=54 time=19.327 ms
64 bytes from 125.6.175.12: icmp_seq=1 ttl=54 time=19.542 ms
64 bytes from 125.6.175.12: icmp_seq=2 ttl=54 time=19.863 ms

----ipv6.2ch.net PING Statistics----
3 packets transmitted, 3 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 19.327/19.577/19.863/0.270 ms

v4もv6もほぼ変わらない値に。6to4などに比べればやはりかなり速くなった。難点は固定IPv6アドレスではないってことだけなのだが…また固定オプションはv4同様 お高いプランになるのだろうか…。対応しているルータさえあれば実は要らなかったトンネルアダプタ といい、こういうところがあざといなぁと思わざるを得ない。