Software-Defined どさにっき 〜2015年4月中旬〜

by やまや
<< = >>

2015年4月14日(火)

設定ファイルの履歴管理

_ bhyve のあるくらし。つづき。

_ VM なホストが増えると設定ファイルも増える。ちゃんと履歴管理できるとうれしい。ということで、これまで何度か話に聞いていた etckeeperを調べてみたんだけど、あれ、freebsd には対応してない?

_ 中身はただのシェルスクリプトのようなので移植はたいした手間ではなさそうなんだけど、いろいろ考えてるうちにもっといいアイデアを思いついたのでそっちで実現することに。

_ まず、母艦で VM のディスクイメージをマウントする。

# mdconfig -a -t vnode freebsd0.img
md0
# mount /dev/md0p2 /mnt
VM のファイルを母艦に同期する。
# rsync -a --delete /mnt/etc freebsd0/etc/
umount する。
# umount /mnt
# mdconfig -d -u md0
おしまい。これをスクリプトにして cron で動かせばよし。超らくちん。

_ rsync で母艦に同期してるだけなのになぜ履歴管理になるかというと、母艦が ZFS で snapshot 機能があるから。cron で毎日スナップショットを取得するようにしてるので、同期スクリプトと合わせて設定ファイル群のスナップショットが毎日作成される。clone を作れば簡易的なブランチ管理もできる。スナップショットは取るばっかりではなく、古いものは適度に捨てていってるので完全な履歴管理ではないけど、そこまで厳密なものを要求してるわけじゃないし。

_ ディスクイメージをマウントせず、ふつーにネットワーク越しに rsync してもいいけど、その場合は root ログインを許可する必要があってキモいし、この方法なら停止中の VM でも気にせずバックアップできる。つーか、もうめんどくさいからディスクイメージはずっと母艦にマウントしたまんまでいいかも。

_ もちろん、ディスクイメージ自体のスナップショットを保存しておいて必要になったら過去のイメージをマウントして取り出すというのもありだし、実際そうできるようにはしてあるけど、母艦のディスク容量的にちょくちょく VM のスナップショットを消す必要が出てきそうなんで、こちらはあまり頼らない方がいいと思う。最近の freebsd は UFS でもスナップショットを取得できるので、その気になれば VM の中だけでやることもできるけど、ZFS に比べるとパフォーマンスはよくないし、こういうのは別ホストにバックアップしておくことに意義があるわけだし…って、VM から母艦にコピーしてるだけじゃダメだけどな。


2015年4月15日(水)

zvol

_ bhyve のあるくらし。つづき。

_ VM のディスクイメージはふつーにファイルとして作成してたんだけど、スナップショットでいろいろやったりすることを考えたら ZFS のボリュームとして管理した方がよさげな気がしてきた。ZFS のファイルシステム上にある1ファイルとしてスナップショットを管理するより、VM のイメージそのものをスナップショット管理の対象にした方がいろいろ都合がよい。

_ ということで VM のお引越し。

_ 既存のイメージファイルと同じ大きさで ZFS ボリューム作成。

# zfs create -V 8G zroot/vm/freebsd0
# zfs list zroot/vm/freebsd0
NAME                    USED  AVAIL  REFER  MOUNTPOINT
zroot/vm/freebsd0        64K   273G    64K  -
# ls -l /dev/zvol/zroot/vm/freebsd0
crw-r-----  1 root  operator  0x78 Apr 15 22:58 /dev/zvol/zroot/vm/freebsd0
作成した ZFS ボリュームに VM のイメージをコピーする。
# dd if=freebsd0.img of=/dev/zvol/zroot/vm/freebsd0 bs=1M
ディスクとしてちゃんと見えることを確認する。
# mount /dev/zvol/zroot/vm/freebsd0p2 /mnt
# ls -l /mnt
# umount /mnt
vmrcの設定を変更する。
# ( echo vm_dev_type=zvol; echo host_zpool=zroot/vm ) >> freebsd0.conf
VM を起動してみると、はい、以前と変わりなく動きました。おしまい。

_ …って、あれ、いったん起動すると /dev/zvol/ 以下のボリュームをマウントしたりとか、ディスクとしてのアクセスができなくなるのか。VM を停止すると、ふたたびアクセスできるようになる。vmm (bhyve のカーネルモジュール)がなんかそのへんのことをやってるっぽい? 履歴管理のために適宜マウントする、という方法が使えなくなってしまった。うーん、どうしよっかなぁ。

_ あー、稼働中の VM に母艦からディスクとしてマウントすることはできないけど、そのボリュームに対するスナップショットはふつーにマウントできるな。

# zfs snapshot zroot/vm/freebsd0@tmp
# mount -t ufs -o ro /dev/zvol/zroot/vm/freebsd0@tmpp2 /mnt
# なんか操作
# umount /mnt
# zfs destroy zroot/vm/freebsd0@tmp
スナップショットは必ず @ という文字を含むため、mount コマンドが NFS と勘違いしないように UFS と明示するのと、スナップショットには書き込みできないので read only でマウントすることを明示する必要あり。とりあえずこれで用は足りるかな?


2015年4月18日(土)

切り替えた

_ うちの自宅サーバ、メールと web を新しいものに切り替えた。どちらも内部の構成はだいぶ変わってるけど、外からの見え方はほとんど変わってないはず。たぶん。きっと。

_ DNS はまだ以前のホストの方で動いてるものが見えてる。ヒマがあればこれも明日には切り替わるはず。たぶん。


2015年4月19日(日)

メールサーバ作りかえた。

_ bhyve のあるくらし。つづき。

_ 外に晒す環境と内向けの環境を明確に分離したので、メールサーバも構成変更。図にするとこんな感じ。

                    +--外側サーバ-----+       +--内側サーバ ----+
                    |   +---------+   |       |   +---------+   |
inbound(25) ----------> |         | ------------> | milter  |   |
submission(587) ------> | postfix |   |       |   +---------+   |
outbound(25) <--------- |         | -----+    |                 |
                    |   +---------+   |  |    |                 |
                    |        |        |  |LMTP|                 |
                    |        |auth    |  |    |   +---------+   |
                    |        v        |  +------> |         |   |
                    |   +---------+   |       |   | dovecot |   |
imap(143) ------------> | dovecot | ------------> |         |   |
                    |   +---------+   |       |   +---------+   |
                    +-----------------+       +-----------------+
外側では外とのメールのやりとりと、自分が外出してるときに使う Submission/IMAP を提供する。内側では SMTP なサーバは動かず、IMAP/LMTP サーバと、dkim やら spf やらの milter が動く。dovecot は両方で動くけど、機能は異なり、外側の IMAP は内側の IMAP に対する単なるプロクシ。ユーザ情報は内側の dovecot が一元管理するが、SMTP auth による認証は内側の dovecot に直接問い合わせるのではなく、これも外側の dovecot に proxy させる。

_ 複雑なように見えるけど、設定自体はとくに難しくはない。内側の dovecot はふつーに設定した上で、 LMTP の口を開ける設定を追加するだけ。外側の IMAP proxy は、 dovecot wiki の howtoをほぼそのままコピペしておしまい。postfix も、ふつーの設定との違いはローカル配送を LMTP にやらせるところと、宛先アドレスがローカルにいるかどうかの判定を裏側にやらせるところぐらい。

mailbox_transport = lmtp:inet:内側サーバ:24	# LMTP でローカル配送

local_recipient_maps =		# ユーザの情報をローカルに持たない
smtpd_recipient_restrictions =
    ...
    reject_unverified_recipient	# 宛先アドレスが存在するか後段に問い合わせて、いなければ蹴る
reject_unverified_recipient は lmtp_generic_maps で配送先アドレスを書き換えてるとどうもうまく動いてくれないみたいでちょっとハマったけど、まあその程度か。

_ 上記以外の、生活環境な VM から cron やら何やらのスクリプトから出ていくメールの処理。どうしようかなーとしばらく考えて、まあ複雑な設定が必要なわけではないので標準で入ってた sendmail をそのまま使うことに。.mc にこんな設定を追加して .cf を作り直しておわり。

dnl 送信時に STARTTLS を使わない(S)、SMTP AUTH を使わない(A)
CLIENT_OPTIONS(`Family=inet, Address=0.0.0.0, Modifier=SA')dnl
dnl submission 不要
FEATURE(`no_default_msa')dnl
dnl 外行きメールを投げる先
define(`SMART_HOST', `外側サーバ')dnl
dnl ローカル配送は LMTP で
FEATURE(`local_lmtp', `[IPC]', `TCP [内側サーバ] 24')dnl
dnl Return-Path は dovecot で付与してくれるので sendmail ではいじらない(-P)
MODIFY_MAILER_FLAGS(`LOCAL', `-P')dnl
これとは別に、ssl まわりをぜんぶコメントアウト。ssl を喋って不都合があるわけじゃないんだけど、外界とは接触しないのでいらんだろ。


<< = >>
やまや