CentOS への FUSE の導入と DKMS

マシン運用

ちょっと unionfs が欲しくなったので yum search したところ、rpmforge から fuse-unionfs パッケージが提供されていたので yum install。FUSE を使うのは今回が初めてなので、備忘的にメモ。
インストールしたところ、そのものズバリの unionfs というコマンドが導入されたので早速実行してみると、「fuse モジュールがないので modprobe しろ」みたいなエラーが発生。「modprobe って、なんか久しぶりに聞いたなぁ」と思いつつ、

# modprobe fuse

が、「そんなモジュールねーよ」的なつれない返事。確かに、rpm q fuse -l とか見てみても、それらしきものは皆無。
「そういうのは依存関係に入れといてよぉ」と思いつつ yum search fuse すると、どうやら dkms-fuse パッケージがそれっぽい。dkms ってのは初耳だが、とりあえずインストールしてみて驚いた。
DKMS、なかなかやるな!!
一言で言えば、“カーネルモジュール専用のソースパッケージシステム”。種々のカーネルモジュールのソースを dkms.conf という設定ファイルと合わせてパッケージングしておくと、dkms コマンド一発でビルドから modprobe までが完了する。現在稼働中のカーネルを自動検出してくれるのでチマチマした設定が不要((もちろん、dkms-fuse みたいなパッケージが提供されている場合だけだが。))な点もいい。
最高なのは、/etc/init.d/dkms_autoinstaller。システムが起動する際に DKMS 対応のカーネルモジュールを自動的にロードしてくれる。必要ならばビルドもしてくれる。これでもう、カーネルをアップデイトしたり変更したりした際にカーネルモジュールのことを気にする必要はない。全てが自動。メンテナンスフリー。
玉に瑕だったのは、yum install dkms で kernel-devel がインストールされてしまったこと。僕は kernel-xen を使っているので、kernel-xen-devel がインストールされなければいけない((dkms が「インストールされているカーネルに対応するヘッダが見つからない」といってエラーになってしまう。))。でもまあ、「kernel-xen がインストールされていれば kernel-xen-devel も必要だが、そうでなければ kernel-xen-devel はなくてもいい」っていう依存関係は RPM では表現できないよね。

root へのメール

マシン運用

root には、いろいろと大事なメールが送られてくる。たとえば、logwatch は、1日1回、ログをざっとまとめた結果を root にメールしてくる。他にも、cron が実行したプロセスが出力した結果は root へのメールになる*1。
ところが、この root へのメール、悲しいほどに放置されている。「su すると、なんかメールがどうのこうのとかいう変な英語のメッセージ出ますよねぇ?」とか言われてしまう始末だ。
cron に仕込んだ自慢のバックアップスクリプトが実は失敗していて動いていなかった、なんていう悲劇を防ぐためにも、root へのメールはちゃんと読むようにしよう。
その際、root でログインして mail コマンド、なんてことはしないでいい。root へのメールを適当なところに転送するようにすればいいのだ。具体的には、/etc/aliases にこう書く:

root: いつものメールアドレス

/etc/aliases を変更したときには newaliases コマンドを実行するのを忘れずに。

スマートホストを使ったメール配送

root へのメールをいつものメールアドレスに転送しようとしてもうまくいかないことがある。
最近は迷惑メールがひどいことになっているので、大概の MTA は、どこの馬の骨とも分からないホストからの SMTP 接続なんて受け入れてくれない。ISP による OP25B も一般的になったし、会社の LAN なんかだと組織外への IP 接続が許されていないのが普通だ。
でも、普段、MUA を使ってのメール送信は普通にできている。ISP なり LAN なりは、内部からのメール送信のために SMTP サーバを置いてくれているからだ。ならば、Linux マシンのローカル MTA も、この枠組みに加えてやればいい。要するに、すべてのメールを ISP や LAN の内部向け SMTP サーバに送信するようにローカル MTA を設定すればいいわけだ。HTTP でいうところのプロクシだが、SMTP の場合は「スマートホスト」と呼ぶらしい。
スマートホストを使うように Sendmail を設定するのは非常に簡単だ。/etc/mail/sendmail.mc にある以下の記述を書き換えればいい:

dnl define(`SMART_HOST', `your.isp.mail.server')

「dnl」を削除してコメントアウトを解除し、「`your.isp.mail.server'」に自分のスマートホストを書く。書き換えたら、/etc/mail で make して sendmail サービスを再起動するのを忘れずに。

エンベロープの送信者欄を ISP 提供のメールアドレスにする

自宅に設置した Linux マシンの場合、ISP の SMTP サーバをスマートホストに指定してもローカル MTA からのメール送信ができないことがある。
自分が適当につけたホスト名がエンベロープの送信者欄((from と sender のどちらが正しい用語なのか分からないので、「送信者欄」と書くことにした。))に書かれているため、ISP の SMTP サーバにメールの受け取りを拒否されてしまうのだ。SMTP セッションで「MAIL FROM: ユーザ名@自分で適当につけたホスト名」を発行した直後、ISP の SMTP サーバに「そんなホストは存在しない」と言われてセッションを切られてしまう。エンベロープの送信者欄はバウンスメールの送り先なので、ドメイン部分が DNS の MX レコードで引けないようなアドレスは拒否するのが親切なのだ。
自分のホスト名を DNS に登録するのはちょっと大変なので、エンベロープの送信者欄を ISP 提供のメールアドレスにすることで対処する。Sendmail や Postfix での設定方法はよく分からなかった((エンベロープの送信者欄だけを書き換えたいのだが、From: ヘッダも書き換わってしまう。多分、僕が設定方法を分かってないだけだと思う。))ので、Exim を使うことにしよう。
設定は実に簡単で、/etc/exim/exim.conf で「begin rewrite」の次にこう書くだけでいい:



*@自分で適当につけたホスト名 ISP提供のメールアドレス F
ちなみに、Exim でスマートホストを使うには、/etc/exim/exim.conf をこんな感じで書き換える:
変更前
dnslookup:
  driver = dnslookup
  domains = ! +local_domains
  transport = remote_smtp
  ignore_target_hosts = 0.0.0.0 : 127.0.0.0/8
  no_more
変更後
send_to_smart_host:
  driver = manualroute
  route_list = !+local_domains スマートホストのFQDN
  transport = remote_smtp

自分用のスマートホストを作る

エンベロープの書き換え設定は大した作業ではないが、sendmail.mc をちょろっと弄るのに比べるとかなり面倒くさい。何度もやらなくて済むよう、この書き換えをやってくれる SMTP サーバを自分用のスマートホストとして運用してみよう。
まず、LAN 内のどのマシンから送られてきたメールに対してもエンベロープの書き換えが行われるように、さっきのエンベロープ書き換え規則をちょっとアレンジする:

変更前
*@自分で適当につけたホスト名 ISP提供のメールアドレス F
変更後
*@*.自分で適当につけたドメイン名 ISP提供のメールアドレス F
続いて、LAN 内のホストからのメールをリレーするように以下を設定する:


hostlist   relay_from_hosts = 127.0.0.1 : LAN内のIPアドレスパターン
「LAN内のIPアドレスパターン」は、たとえば「192.168.0.0/24」のように指定する。
最後に 25/tcp を LAN 内のホストに対して開放すれば、設定は完了だ。
他のホストでは、この SMTP サーバをスマートホストに指定するだけでよくなる。ただし、sendmail.mc の SMART_HOST に指定する値は、DNS で解決できるホスト名でなければならないっぽい*2。IP アドレスでの指定や /etc/hosts で解決できるようにした名前ではダメなので注意しよう。

*1:一般ユーザの cron ジョブの場合は、そのユーザにメールされる。

*2:きちんと調べたわけではないが、僕のところではそうだった。

仮想マシンへのログインに SSH の HostbasedAuthentication を使う

マシン運用

最近矢鱈に気に入っている Xen の話。
仮想ネットワークは NAT モードにしているので、Domain U へのアクセスは Domain 0 からしか行えない。このとき、xm console という手もあるが、普通は SSH を使うだろう((xm のマニュアルには、console はシリアルコンソールだから curses がちゃんと動かないかも、とか書いてある。))。今日日、sshd は何の設定をしなくても動いてくれているので何もしなくていいんだが、ちょっと嫌なことがある。
パスワードを入れるのが面倒くさい。自分だけのための、自分しか知らない、自分にしか見えない、自分しかいない、仮想マシンにログインするのにパスワードなんてなくていい。公開鍵認証にしたところで、パスフレイズをいれなきゃいけないので面倒なのは同じだ((ssh-agent を PAM あたりから蹴るべく頑張ればいいんだろうが、GSSAPIAuthentication の方が便利なのでモチベーションが上がらない。))。
というわけで、SSH の HostbasedAuthentication を使ってみた。やり方は、こんな感じ:

【Domain U 側の設定】
/etc/ssh/sshd_config
  • HostbasedAuthentication yes
  • IgnoreUserKnownHosts yes
  • IgnoreRhosts yes
/etc/ssh/shosts.equiv
  • (Domain U から見た) Domain 0 の FQDN を書いておく。
/etc/ssh/ssh_known_hosts
  • 「 ssh-keyscan -t rsa Domain-0-の-FQDN 」の出力を書いておく。
【Domain 0 側の設定】
/etc/ssh/ssh_config
  • EnableSSHKeysign yes
  • HostbasedAuthentication yes
  • HostbasedAuthentication の方は、Host キーワードを使って対象ホストを制限しておくのもいいかもしれない((EnableSSHKeysign は、ホストごとの設定にはできない。))。
これで、Domain 0 から Domain U への SSH がパスワード無しで繋がるようになる。Domain U の方に作るユーザアカウントは、ユーザ名が同じでありさえすれば UID やグループは違っていても構わない((僕の場合、Domain 0 のアカウントは Winbind が作り出しているものなので、useradd とかで作るやつとはちょっと違っている。))。パスワードは一切使わないので、passwd -l してしまって大丈夫だ。

NFS の使い方、覚えてますか?

マシン運用

今日は Xen の話ばっかりで俄者ぶりをいかんなく発揮しているが、また1つ。
Domain 0 と Domain U との間でファイルをやりとりするのには NFS が便利だ。最近は Samba の CIFS ばっかりで済ませてきたので hard,intr とか /etc/exports の書き方とかすっかり忘れていたが……。
久しぶりに NFS 使ってるんだなぁ、と実感したのは、POSIX ACL との絡み((ACL が有効になっているボリュームがエクスポートされた場合、クライアント側では acl オプションを指定しなくてもちゃんと ACL が有効になる。))を発見したとき。NFS を普段使いしていたあの頃は、POSIX ACL なんて知らなかった……。

仮想マシンへの HDD 増設

マシン運用

Xen の HDD イメージって何か特別な形式なのかと思ったら、別に中身はどうでもいいのかよ。ちょっと驚いた。
ちなみに、大きいファイルを作るのには dd の seek= が便利だと思う。たとえば、20G バイトのファイルはこう作る:

$ dd if=/dev/zero of=disk.img bs=1 count=0 seek=20x1024x1024x1024

実際に 20GB の読み取りや書き込みが発生するわけではないので、一瞬で終わる。
できたファイルに mke2fs -j -F する流儀もあるみたいだけが、僕は、仮想マシンの方から mke2fs -j /dev/xvdb とかする方が何となく好きだ。

仮想ネットワークのための Bind

マシン運用

僕の用途だと、仮想マシンは実マシン管理のための作業場なので、仮想ネットワークは NAT モードにするのが便利だ。この辺りで、Linux でブロードバンドルータ*1もどきを作って遊んでいた昔の知識がなかなか役に立つ。
仮想ネットワークのために Domain 0 で Bind named を走らせておくと、いろんなことがスムースに行ってよい。caching-nameserver というパッケージを使えば、外からアクセスされない DNS サーバのセットアップはすぐにできる。

*1:という言い方は、当時はしていなかったが。

仮想マシンのコピー

マシン運用

仮想マシンへの OS のインストールなんて、何度もやってられるわけがない。コピーするのが楽でいいよね。
コピーしてきた後にやらなきゃいけない作業を備忘的にメモ:

マシン名の修正
  • /etc/sysconfig/network
  • /etc/hosts も忘れずに
IP アドレスの修正
  • /etc/sysconfig/network-scripts/ifcfg-eth0
  • MAC アドレスの方も、ちゃんと直しておく
SSHd のホスト鍵を削除する
  • /etc/ssh/ssh_host_* を捨てる
  • 忘れてたよ……。