VMWare 3.2を利用して仮想ネットワーク(VMNet)の構築をおこないました。このネットワークは、OpenPBSのテストを目的とし、バッチシステムのサーバ(キュー)の役割を持たせるHost OSも、その上で稼働し実行ホストの役割を持たせる複数のGuest OSもすべて、RHL8.0 (実際はこちらのRed Hat Linux 8.0) を用いました。
2003-02-25 | 桑村 潤 |
さきに、RHL8.0上で稼働するVMWareを利用して複数のGuest OSにRHL8.0をインストールしてテスト用のネットワークを作ります。
+---------Host-OS--------+ | server | | | | Guest-OS-+ Guest-OS-+ | | | linux1 | | linux2 | | | +--------+ +--------+ | | Guest-OS-+ | | | linux3 | | | +--------+ | +------------------------+ +--------+ +--------+ +--------+ | linux1 | | linux2 | | linux3 | バッチシステムの実行ホスト +----+---+ +----+---+ +----+---+ eth0|*.11 eth0|*.12 eth0|*.13 | | | o-------+-----------+-----------+-----------+-------o 192.168.218.0/255.255.255.0 | *.1|vmnet1 +---+----+ | server | バッチシステム(バッチキュー)のサーバ +--------+
server (Host OS)のインターフェースの構成はvmnet1のドライバ構成で見ることができます。
# /sbin/ifconfig -a ... vmnet1 Link encap:Ethernet HWaddr 00:50:56:C0:00:01 inet addr:192.168.218.1 Bcast:192.168.218.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 ...
linux? (Guest OS)のインターフェースの構成はeth0のドライバ構成で見ることができます。
linux1# /sbin/ifconfig -a eth0 Link encap:Ethernet HWaddr 00:50:56:C7:C3:D9 inet addr:192.168.218.11 Bcast:192.168.218.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 ... linux2# /sbin/ifconfig -a eth0 Link encap:Ethernet HWaddr 00:50:56:C7:C3:DF inet addr:192.168.218.12 Bcast:192.168.218.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 ... linux3# /sbin/ifconfig -a eth0 Link encap:Ethernet HWaddr 00:50:56:C7:C3:DD inet addr:192.168.218.13 Bcast:192.168.218.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
バッチシステムの運用に必要な各種ネットワークサービスの設定を行います。
serverでVMNetネットワーク向けにDNSサービスを走らせます。ここでは、VMNetのドメインを vmnet.rccm.jp とし、次のようなゾーンファイルを /etc/named/vmnet.zone に作り、
$TTL 86400 @ IN SOA server.vmnet.rccm.jp. root.server.vmnet.rccm.jp. ( 1 ; serial 28800 ; refresh 7200 ; retry 604800 ; expire 86400 ; ttl ) @ IN NS sabor3 sabor3 IN A 192.168.218.1 1 IN PTR sabor3 linux1 IN A 192.168.218.11 11 IN PTR linux1 linux2 IN A 192.168.218.12 12 IN PTR linux2 linux3 IN A 192.168.218.13 13 IN PTR linux3 linux4 IN A 192.168.218.14 14 IN PTR linux4
このファイルの指定を/etc/named.confファイルに次のように追加します。
zone "vmnet.rccm.jp" { type master; file "vmnet.rccm.jp.zone"; }; zone "218.168.192.in-addr.arpa" { type master; file "vmnet.rccm.jp.zone"; };
リゾルバの設定ファイル /etc/resolv.conf を次のようにします。
search vmnet.rccm.jp nameserver 192.168.218.1
リゾルバの設定のみファイル /etc/resolv.conf に記述します。
search vmnet.rccm.jp nameserver 192.168.218.1
VMNetのDHCPサービスの設定は/etc/vmware/vmnet1/dhcpd/dhcpd.confで行われます。このファイルに実行ホストのMACアドレスとIPアドレスとの対応付けを登録します。
host linux1 { hardware ethernet 00:50:56:C7:C3:D9; fixed-address 192.168.218.11; } host linux2 { hardware ethernet 00:50:56:C7:C3:DF; fixed-address 192.168.218.12; } host linux3 { hardware ethernet 00:50:56:C7:C3:DD; fixed-address 192.168.218.13; }
おそらく、インストール時DHCPクライアントとして設定してあると思いますが、もしそうでなければ、netconfigコマンドで設定します。
時刻合わせにTIMEサービスを使います。NTPでもかまわないのですが、ここでは設定が簡単なTIMEサービスを使います。TIMEサーバはxinetdデーモンが面倒を見ますので、chkconfig を使ってサービスを有効にし、xinetdの初期化をして構成を読み直させます。
# /sbin/chkconfig time on # /etc/init.d/xinetd reload
定期的に時刻合わせをするようにCRONサービスに登録します。
# echo "/usr/bin/rdate -s server" > /etc/cron.daily/time # chmod +x /etc/cron.daily/time
これでも時刻が頻繁に狂うようなら、 /etc/cron.daily/ディレクトリのかわりに/etc/cron.hourly/ディレクトリの下にコマンドファイルを置きます。
OpenPBSの実行もジュールを含む、実行ホストで使う共通のプログラムや入出力のためにNFSを利用してストレージをを共有します。ここでは、serverの/opt/pbs/というディレクトリ以下を共有とする設定を行います。
本来、実行プログラムは実行ホスト側からは読み込みのみとして、入出力ファイルとは分けるべきですが、今回のテストでは簡便のために同じファイルシステムにて共有するようにします。 まず、ディレクトリを作成します。
# mkdir -p /opt/pbs
この/opt/pbs以下のファイルシステムを実行ホストへ輸出(export)するための設定を/etc/exportsファイルに記述します。
/opt/pbs linux1(rw,sync,no_root_squash) /opt/pbs linux2(rw,sync,no_root_squash) /opt/pbs linux3(rw,sync,no_root_squash)
この記述の中の "(rw,sync,no_root_squash)" はマウントした実行ホスト側でもroot権限で書き込みができるようにします。 chkconfigコマンドで、次の起動からNFSサービスが自動的に有効になるようにしておきます。
# /sbin/chkconifig nfs on # /sbin/chkconifig --list nfs
"--list" オプションでNFSサービスが有効になったかどうかの確認ができます。
なお、マルチユーザモードの実行レベル(run level)は3です。
serverからNFSでエキスポートされたファイルシステムは、mountコマンドでマウントすることができます。serverと同じ/opt/pbsというディレクトリを使ってマウントしてみます。
# mkdir -p /opt/pbs # mount -t nfs server:/opt/pbs /opt/pbs # df /opt/pbs
df コマンドでファイルシステムがマウントされていることを確認できます。次から起動時に自動的にマウントするためには、/etc/fstabファイルに次の行を追記しておきます。
server:/opt/pbs /opt/pbs nfs auto 0 0
Sendmailデーモンプロセスはおそらく既に走っていると思います。psコマンドで確認できます。
# ps ax | grep sendmail 22444 ? S 0:15 sendmail: accepting connections 22454 ? S 0:00 sendmail: Queue runner@01:00:00 for /var/spool/client
念のためchkconfigコマンドでOSのブート時にsshdが起動される設定になっていることを確認しておきます。
# chkconfig --list sendmail sendmail 0:オフ 1:オフ 2:オン 3:オン 4:オン 5:オン 6:オフ
sendmailの設定は /etc/mail/ ディレクトリに移って作業をするのがよさそうです。 まず、サーバーで受け取るメールの宛先のドメイン名を local_host_names ファイルに登録します。
# cd /etc/mail/ # cat > local_host_names server.vmnet.rccm.jp vmnet.rccm.jp ^D
注 ^D はコントロールキーとDキーを同時に押すことを示し、ファイルの終了を意味するコードになります。
次に、sendmail.mc ファイルを編集して localhost からのメールしか受け取らなくなっている既定の設定を変更します。DAEMON_OPTIONS で接続を許すアドレスがローカルホストのみとなっているのをコメントにして除外(行頭に dnl を挿入)します。次はもとの設定との差分で、下の方が変更後です。
# diff sendmail.mc.orig sendmail.mc 56c56 < DAEMON_OPTIONS(`Port=smtp,Addr=127.0.0.1, Name=MTA') --- > dnl DAEMON_OPTIONS(`Port=smtp,Addr=127.0.0.1, Name=MTA')
変更したファイルを保存したら、make を実行して sendmail.cf を作りなおし、sendmail デーモンを再起動させます。
# make # /etc/init.d/sendmail restart
設定は不要です。確認のため試しにserver の sendmail デーモンプロセスに接続してみます。
# telnet server 25 Trying 192.168.218.1... Connected to server.vmnet.rccm.jp (192.168.218.1). Escape character is '^]'. 220 server.vmnet.rccm.jp ESMTP Sendmail 8.12.5/8.12.5; Tue, 25 Feb 2003 17:53:50 +0900 quit 221 2.0.0 server.vmnet.rccm.jp closing connection Connection closed by foreign host.
SSHのデーモンプロセスはおそらく既に走っていると思います。psコマンドで確認できます。
# ps aux | grep sshd root 807 0.0 0.0 3280 1472 ? S Feb14 0:01 /usr/sbin/sshd ...
念のためchkconfigコマンドでOSのブート時にsshdが起動される設定になっていることを確認しておきます。
# chkconfig --list sshd sshd 0:オフ 1:オフ 2:オン 3:オン 4:オン 5:オン 6:オフ
双方向でsshコマンドが利用できるよう、サーバ側と同様にSSHのデーモンプロセスが走っていることを確認します。
リモートコマンドが円滑に使えるようSSHの設定を行います。旧来のバークレーのRSH(リモートシェル)系コマンドはパスワード認証をバイパスするよう設定すると、ホスト名だけが便りのホスト認証になります。ホスト名は簡単に詐称できてしまうためセキュリティが低いとされ、昨今ではほとんど使われなくなりました。 これにに対してSSH(セキュアシェル)系のコマンドでは鍵のペアを認証に使うことが可能で、しかもセッションが暗号化されるということもあってセキュリティは高いとされRSH系に代わって使われることが多くなりました。
まず、ssh-keygenコマンドを実行し、リモートコマンドを使いたいアカウントで認証に使う鍵の対(ペア)を生成します。
# ssh-keygen -t dsa Generating public/private dsa key pair. Enter file in which to save the key (/root/.ssh/id_dsa): リターン Enter passphrase (empty for no passphrase): リターン Enter same passphrase again: リターン Your identification has been saved in /root/.ssh/id_dsa. Your public key has been saved in /root/.ssh/id_dsa.pub. The key fingerprint is: xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx root@server
ここではすべてのプロンプトに対してリターンキーだけを押して返しました。最後の行のxxは実際には十六進数値が表示されます。 (例えば、0c:dc:09:b7:34:d5:a1:a5:e6:13:fb:50:e8:17:bb:5b) うまくゆけば、.ssh/ ディレクトリに id_dsa というプライベート鍵(秘密鍵)と id_dsa.pubというパブリック鍵(公開鍵)ができます。パーミッションに注意して見ると、プライベート鍵へは持ち主しかアクセスすることができないことがわかります。
# ls -l .ssh/ 合計 8 -rw------- 1 root root 668 2月 25日 15:01 id_dsa -rw-r--r-- 1 root root 600 2月 25日 15:01 id_dsa.pub
パブリック鍵の方は、実際にはリモートのホスト(実行ホスト)の同じく .ssh/ディレクトリ下に authorized_key2 という名前でコピーして使います。ここでは、相互にSSH系コマンドが使えるようにするため簡便な措置として同一のプライベート鍵とパブリック鍵の対を各実行ホストにコピーすることにしたいので、単に名前を変えることにします。
# mv .ssh/id_dsa.pub .ssh/authorized_keys2
次に実行ホストを既知のホストとして認識するための記載を .ssh/known_hosts に行いたいのですが、これはSSH系のコマンドを実行ホストに対して実行した時にコマンドから聞かれるので yes を返すと登録されます。これを、鍵の対のリモートコピーの際に行うことにします。
# scp -r .ssh linux1: The authenticity of host 'linux1 (192.168.218.11)' can't be established. RSA key fingerprint is ff:f8:33:34:f2:c0:c6:27:5b:b2:ec:d2:88:3c:de:03. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added 'linux1,192.168.218.11' (RSA) to the list of known hosts. root@linux1's password: xxxxxxxxxxxxxxxx known_hosts 100% |*****************************| 231 00:00 id_dsa 100% |*****************************| 668 00:00 authorized_keys2 100% |*****************************| 601 00:00
ここでは、鍵の交換前のためパスワード認証となるので、 xxxxxxxxxxxxxxxx に実際のパスワードを入れる必要があります。
同じように他の実行ホスト(linux2 と linux3)へも鍵のペアをリモートコピーしておきます。
# scp -r .ssh linux2: # scp -r .ssh linux3:
すると同時にすべての実行ホストの含まれた known_hosts ファイルもできているはずで、最後にリモートコピーをしたホストには、そのファイルもコピーされているはずです。ここでは便宜上実行ホスト間でもリモートコピーをできるようにすべてのホストに同じknown_hosts ファイルをコピーすることにします。
最後にコピーを行ったホストへリモートログインをすると、鍵の対による認証が有効になっていることのテストも同時に行うことになります。
# slogin linux3 Last login: Tue Feb 25 11:28:25 2003 [root@linux3 root]#
そして、最後のリモートホストlinux3からサーバへ known_hosts ファイルをリモートコピーすると、サーバのホスト情報も追加されたファイルができあがるはずです。
[root@linux3 root]# scp .ssh/known_hosts server:.ssh/ The authenticity of host 'server (192.168.218.1)' can't be established. RSA key fingerprint is 11:6c:e8:19:91:b0:f5:86:3e:57:7c:0c:f1:79:98:ce. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added 'server,192.168.218.1' (RSA) to the list of known hosts. known_hosts 100% |*****************************| 923 00:00
最後はサーバへリモートログインしなおし、そこからそのファイルを残りの実行ホストへリモートコピーすればSSH系コマンドのための配備ができあがります。
[root@linux3 root]# slogin sabor3 Last login: Fri Feb 21 18:29:13 2003 [root@server root]# scp .ssh/known_hosts linux2:.ssh/ known_hosts 100% |*****************************| 923 00:00 [root@server root]# scp .ssh/known_hosts linux1:.ssh/ known_hosts 100% |*****************************| 923 00:00 [root@server root]# exit [root@linux3 root]# exit
※ホームディレクトリのパーミションに注意しましょう。GroupやOtherからは読めなくしなくてはなりません(例:drwx--x--x)。