仮想化

やたら多いMicrosoft UpdateをVMWare Fusionで当てつつ作業。

とはいっても、元々のMTAを止めた上でルータ経由のSMTPを新MTAに流して、実際に外との導通をとってみるだけ。最初はgreylistingにひっかかってなかなか確認できなかったが、一応一通りの操作はできたので安心。内部DNSを新MTAに向けなおして実働に入る。

Postgreyは、/etc/rc.conf でホワイトリストを指定。その上で普段利用の転送サーバをホワイトリスト指定している。

postgrey_flags="--pidfile=/var/run/postgrey.pid \
        --whitelist-clients=/usr/local/etc/postfix/postgrey_whitelist_clients \
        --whitelist-recipients=/usr/local/etc/postfix/postgrey_whitelist_recipients \
        --inet=10023 -d --user=postgrey --group=postgrey --dbdir=/var/db/postgrey"

次は、Cyrus-IMAPdと併用してのSMTP Authまわりかな。まあ内部用なので割と気分的なものだし、後まわしでいいや。

DNSSECをみすえてと、いい加減にBINDの肥大化と手順のややこしさにめげてきたので、DNSのResolverをunbound、Contantsをnsdに移行してみる。Jailでさくさくと複数環境を用意して、それぞれportsでinstall。

まずはunboundからざっと設定。localなzoneは、local-dataとして完全に記載する形にした。本当は外ファイルに出すべきなのかな。IPv6対応は外回線が確保できてからということで、あえてOFF。DNSSEC対応はこれから様子見つつテスト予定。portsなので起動も/usr/local/etc/rc.d/unboundからできるし、rc.confでunbound_enable=”YES”で起動も設定。

server:
        verbosity: 0
        interface: 192.168.xxx.xxx
        do-ip4: yes
        do-ip6: no
        do-udp: yes
        do-tcp: yes
        do-daemonize: yes
        access-control: 0.0.0.0/0 refuse
        access-control: 127.0.0.0/8 allow
        access-control: ::0/0 refuse
        access-control: ::1 allow
        access-control: ::ffff:127.0.0.1 allow
        access-control: 192.168.xxx.xxx/24 allow
        use-syslog: yes 

        private-address: 192.168.0.0/16
        private-domain: "localnet"

        local-zone: "localnet." static
        local-data: "ns.localnet. A 192.168.xxx.xxx"
        local-data-ptr: "192.168.xxx.xxx ns.localnet"

nsdも同様に別Jailに設定。ZONEは独自形式もできるようだが、そのままBINDのものを利用。逆引きの登録ができないのが若干不安。同じように登録してやればいいのかな。

と思ったら、ISPの業務移譲に伴い、逆引き移譲が消えているらしい。むー。

server:
        ip-address: 192.168.xxx.xxx
        hide-version: yes
        ip4-only: yes

        database: "/var/db/nsd/nsd.db"
        username: nsd
        zonesdir: "/usr/local/etc/nsd"

zone:
        name: "fortunerinn.org"
        zonefile: "fortunerinn.org.zone"

ついでに、RT105eでサーバへの静的NATもしているため、そちらも設定も変更しておく。

# nat descriptor masquerade static 1 1 192.168.xxx.xxx udp domain
# nat descriptor masquerade static 1 2 192.168.xxx.xxx tcp domain

今迄のサーバのBINDを止めて、一通り問題ないことをチェックしてから、移行完了。

unboundのlocal-dataをファイル分割。ついでに、nsdでSPFをIPアドレス制限で表明してみる(←まだやってなかった)。

色々考えた結果、ルータ入れ替えとかの際に面倒になるので、素のezjailのままで行くことに決定。VIMAGEは必要なところだけ使って遊ぶ予定。

ということで、jail を作りなおす。ezjail-adminで済むと色々と楽だなあ。

DNSサーバをいじる土台をつくったところで終了。

ESXのアップグレードを参照しつつ作業。今回はvihostupdateを利用。

まず、ESXiホストをvSphere Clientでログインしてメンテナンスモードに変更。

vSphere CLI 4.0.0と ESXi 4.1 (upgrade ZIP from ESXi 4.0) 07/13/10 をダウンロード。vSphere CLIをWindowsにインストールしてから、アップグレード通知をESXiホストに送信。

C:\Program Files\VMware\VMware vSphere CLI\bin>vihostupdate.pl --server xxx.xxx.xxx.xxx -i -b "upgrade-from-ESXi4.0-to-4.1.0-0.0.260247-release.zip" -B ESXi410-GA-
esxupdate
Enter username: root
Enter password:
Host updated successfully.

C:\Program Files\VMware\VMware vSphere CLI\bin>vihostupdate.pl --server  xxx.xxx.xxx.xxx -i -b "upgrade-from-ESXi4.0-to-4.1.0-0.0.260247-release.zip" -B ESXi410-GA
Enter username: root
Enter password:
The update completed successfully, but the system needs to be rebooted for the c
hanges to be effective.

一応インストールできているかを確認。

C:\Program Files\VMware\VMware vSphere CLI\bin>vihostupdate.pl --server xxx.xxx.xxx.xxx --query
Enter username: root
Enter password:
---------Bulletin ID--------- -----Installed----- ----------------Summary-------
----------
ESXi410-GA-esxupdate          2010-07-15T11:30:58 ESXi pre-upgrade Bulletin

ESXi410-GA                    2010-07-15T11:35:52 ESXi upgrade Bulletin

vSphere Clientからホストの再起動。

ホストの起動画面でアップグレードを確認。

続き。

複数Jailとepairで繋ぐために、ブリッジを作成。epair0aに接続。

# ifconfig bridge0 create
# ifconfig bridge0 addm epair0a

というのを一々するのは面倒なので、/etc/rc.confにこう書く

cloned_interfaces="epair0 bridge0"
ifconfig_bridge0="addm epair0a up"

調べていると、Jailの起動とepairの両立がよくわからない。IP指定までして立ち上げるとepairが終わるというか、ezjail同様に”-c vnet”がきいてくれないし。

ifconfig_epair0b="vnet yayoi" あたりでいけるのかな?

ezjailでは、起動時にIPを指定することを期待している。一方、VIMAGEを使うとepairを生成、それからjail起動、jailに割当てるという形式になる。結果、かなり相性が悪いらしい。色々書き換えて対応するパッチが昔あったようだが、今は無い。どうやら、素直に対処する方法はないようだ。

というわけで、あきらめて素直に作成することにする。どうせディスクは余っているし、アップデートの手間もかかるが、バッチ化できないわけではない。

まずは epair を作成。

# ifconfig epair create
epair0a

ezjailのbasejailを利用してコピー

# cp -rp basejail yayoi

jail 作成

# jail -c vnet name="yayoi" host.hostname="yayoi" path=/jail/yayoi/ persist

ホストとインタフェースが一致していないことを確認。別ネットワークスタックなので、先程作成した epair も見えない。

# jexec yayoi ifconfig
lo0: flags=8008 metric 0 mtu 16384
 options=3

epair0a を割当てる。これでホストとjailが繋がれ、jailからは一端であるepair0bが見える。

# ifconfig epair0b vnet yayoi
# jexec yayoi ifconfig
lo0: flags=8008 metric 0 mtu 16384
 options=3
epair0b: flags=8842 metric 0 mtu 1500
 ether 02:00:00:00:05:0b

このままでは一対一になってしまうので、ブリッジを介して接続するようにする。

VMWare ESXi は、「構成」の「ストレージ」から新規ストレージを追加しておしまい。そのまま、FreeBSD に新規ディスクを割り当てる。

FreeBSD側では面倒だったので、まずは新規ディスクを認識させるべく sysinstall からfdiskしてlabelを貼り、勝手にnewfsしてもらう。全部丸ごと確保させると、Software Updateもついてくれるのか。いつの間にかsysinstallも/standではなくなっていた。隔世の感がある。

後は、/etc/fstab に登録してマウント。今回は/jailとした。

ezjailを使ってFreeBSD jailを効率よく管理するを参考にしつつ ezjail をインストール。

Jailのインストールのために、/etc/ezjail.conf.sample を元に ezjail.conf を作成して、ezjail_jaildir を先程のディレクトリに向け、ezjail_ftphostをftp.jp.freebsd.orgに変更。ベースとなる環境をまずはインストールする。

# ezjail-admin install

次に、ホスト側のdaemonの調整。

syslogdは、/etc/rc.confに一言追加。

syslogd_flags="-s -b 192.168.xxx.xxx"

同様に、ssh は、/etc/ssh/sshd_config で ListenAddressを追加。

sendmail も動いていたので、とりあえず /etc/mail/sendmail.cf を編集

# SMTP client options
O ClientPortOptions=Family=inet, Address=192.168.1.129

一応Update

# mkdir /jail/freebsd-update
# freebsd-update -b /jail/basejail/ -d /jail/freebsd-update/ fetch
# freebsd-update -b /jail/basejail/ -d /jail/freebsd-update/ install

Jailごとにネットワークスタックが独立するVIMAGEを使いたかったので、/usr/src/sys/amd64/conf/GENERIC を編集。SCTPは元からあったのを潰しておく。

# for Jail with Vimage
options         VIMAGE
nooptions       SCTP

ざっと make world

# cd /usr/src
# make KERNCONF=GENERIC buildkernel
# make KERNCONF=GENERIC installkernel

doggie氏情報によると、ReleaseのVMImageはtracerouteできないなどの一部バグがあるので、stableを追いかけた方が良いらしい。

ESXi4にFreeBSD 8.0Rをインストール。事前にDVDイメージを取得していたのだが、どうやら壊れていたらしく、CDブート時にブートローダからイメージを読みにいって延々止まってしまっていた。最初はESXiとの相性問題を疑ったせいで、延々時間をかけてしまう。

結局、Boot用の最小イメージを落としてきて、それでネットワークインストール。

そういえば、PC 64bit archの名称が”amd64″なので、ダウンロード時に一瞬とまどってしまう。Release Noteを読めば Intel の 64bit も含まれているのはわかるし、そもそも歴史的にAMDが(珍しく)勝った命令セットでIntelが追随したというのも記憶を掘りかえせば知っている。歴史的・技術的には至極正しい。

よって、arch名としてはそのままでも問題ない。ただ一点、せめてウェブの誘導のところくらいはおもてなしの観点から “FreeBSD Intel/AMD 64bit “とか書いておいて欲しい、というような意味をtwitterで呟いてみたら、はたのさんから妙な顔をされた。ええ、技術者的に気持ち悪いのはわかります。

久しぶりなので、インストールはベースだけにして、そこから追加することにする。まずはscreenとかsudoとか色々と必要なツールをportsからインストール。

あ…Xを禁止するのを忘れていた。あわてて /etc/make.conf に WITHOUT_X11=yes をつけ加える。

• [PC]Transcend DDR3 1333 ECC 2GB TS256MLK72V3U x2

メモリが到着したので、早速GT110bに装着し、VMWare ESXi4をインストール。今度は何事もなく入ってくれる。

問題があるのはクライアントの方。何といってもMac OS XにはVMware Infrastructure(VI) Clientはない。コマンドラインでリモート管理はできるようだが、最初からそれでやれると思う程自惚れてはいない。

というわけで、VMWare Fusion上のVI Clientからアクセスすることになる。普段はWindows Messenger程度しか入れていない仮想マシンなので、起動ももたつきなかなか面倒だ。

なんとかVMを作れるかな? と思えるようになったあたりで終了。