adsaria mood

■ Chrome OSをシェルから使ってみる

私は家電とかPCとかマニュアルを読んで使うということが余りない。色々と試行錯誤して使ってみる方だ。勿論、困り果ててしまえば見るしかないが、大抵のことは何とかなる。

Google Chrome OSはオープンソースでもあり、ドキュメントもあるので見れば直ぐに分かるのだろうが、今のところ試行錯誤を楽しんでいる。しかし、sshデーモンの自動起動ができなくて数時間を費やしてしまった。まだ、出来ない。手動で起動すれば問題なく動くのだが。標準のDebianと何が違うのだろう？

さて、と言ったところでハマってはいるのだけど、Chrome OSをシェルから使うのは難なくできた。

１．Chrome OSを立ち上げる

２．ログインする

３．[F12]キーを押してウィンドウの一覧にする

４．“Ctrl＋Alt＋t”を押してxtermウィンドウを起動する

５．xtermウィンドウをクリックする

ここで３は必ずしも必要ない、が確認の為に一覧表示にしておいた方が良さそうだ。また、実機で試す場合は問題ないが、VMwareの仮想マシン環境では“Ctrl＋Alt＋t”を押そうとすると“Ctrl＋Alt”でゲストOSの入力からデフォーカスされてしまうので、まず“Ctrl＋Alt”を押して、そのままの状態でマウスの左クリックで再度ゲストOSへフォーカスしてから“t”を押すとxtermウィンドウが起動する。

さて、xtermウィンドウが起動すれば、あとはLinuxの世界となる。画面にはいつもの見慣れたメッセージが出ている。

To run a command as administrator (user "root"), use "sudo <command>".
See "man sudo_root" for details.

chronos@localhost:~$ 

ここでsudoを利用するためには“chronos”というアカウントのパスワードが必要となる。これも勘でハックしてみたが、なんと２回目でビンゴ！だった。パスワードは“chromeos”。

chronos@localhost:~$ sudo -s
[sudo] password for chronos: chromeos
root@localhost:~# 

ここまで来れば、あとは何でもできる。（しかし、Linuxはroot権限が手に入ってしまえば何でもできる、というのは如何なものかと。）

この後の作業はxtermを使っても良いのだけども、仮想環境ではキー入力がもたつくし、何よりも字が小さすぎる。そこでsshデーモンを起動して他のマシンからsshでログインできるようにする。

root@localhost:~# /etc/init.d/ssh start
* Starting OpenBSD Secure Shell server sshd					[OK]

余談になるが、最近のDebianではRedhatと同様、サービスの起動にデフォルトでserviceコマンドが使えるようになっている。ので、

root@localhost:~# service ssh start

でもOK。（私が普段使っているUbuntu 8.04ではデフォルトには入っていないので、ついつい癖で/etc/init.d/xxxを使ってしまう。）

さて、これで別のマシンからログインできる。

どのようなプロセスが動いているか見てみると、

root@localhost:~# ps ax
  PID TTY      STAT   TIME COMMAND
    1 ?        Ss     0:00 /sbin/init
    2 ?        S<     0:00 [kthreadd]
    3 ?        S<     0:00 [migration/0]
    4 ?        S<     0:00 [ksoftirqd/0]
    5 ?        S<     0:00 [events/0]
    6 ?        S<     0:00 [cpuset]
    7 ?        S<     0:00 [khelper]
   10 ?        S<     0:00 [netns]
   13 ?        S<     0:00 [async/mgr]
  157 ?        S<     0:00 [kblockd/0]
  159 ?        S<     0:00 [kacpid]
  160 ?        S<     0:00 [kacpi_notify]
  277 ?        S<     0:00 [ata/0]
  278 ?        S<     0:00 [ata_aux]
  282 ?        S<     0:00 [ksuspend_usbd]
  287 ?        S<     0:00 [khubd]
  290 ?        S<     0:00 [kseriod]
  351 ?        S      0:00 [pdflush]
  352 ?        S      0:00 [pdflush]
  353 ?        S<     0:10 [kswapd0]
  404 ?        S<     0:00 [aio/0]
  419 ?        S<     0:00 [crypto/0]
  499 ?        S<     0:00 [pciehpd]
  691 ?        S<     0:00 [scsi_eh_0]
  694 ?        S<     0:00 [scsi_eh_1]
  736 ?        S<     0:00 [kpsmoused]
  740 ?        S<     0:00 [kstriped]
  747 ?        S<     0:00 [kondemand/0]
  751 ?        S<     0:00 [usbhid_resumer]
 1013 ?        S<     0:00 [kjournald]
 1035 ?        S<     0:00 [kjournald]
 1061 ?        SLs    0:00 /usr/bin/slim -d
 1065 tty1     Ss+    0:22 /usr/bin/X -nolisten tcp vt01 -auth /var/run/slim.auth
 1067 tty2     Ss+    0:00 /sbin/getty -8 38400 tty2
 1079 ?        Sl     0:00 /usr/sbin/rsyslogd -c4
 1080 ?        Ss     0:00 /bin/cat
 1084 ?        Ss     0:00 /bin/dbus-daemon --system --fork
 1085 ?        Ss     0:00 /sbin/wpa_supplicant -u -s -O/var/run/wpa_supplicant
 1088 ?        Ss     0:01 /usr/sbin/connmand
 1091 ?        Ssl    0:00 /usr/sbin/console-kit-daemon
 1093 ?        S      0:00 /sbin/dhclient -d -q -e BUSNAME=org.moblin.connman -pf /var/run/connman/dhclient.eth0.pid -lf /var/run/connman/dhclient.eth0.lease
 1174 ?        Ts     0:00 /sbin/init
 1184 ?        Ss     0:00 /usr/sbin/acpid --confdir /etc/acpi/events --socketfile /var/run/acpid.socket
 1254 ?        S<s    0:00 /sbin/udevd --daemon
 1380 ?        S<     0:00 /sbin/udevd --daemon
 1381 ?        S<     0:00 /sbin/udevd --daemon
 1584 ?        Ss     0:00 /usr/sbin/ntpd -g -u ntp:ntp
 1748 ?        S<     0:01 [loop0]
 1767 ?        S<     0:00 [kdmflush]
 1815 ?        S<     0:00 [kjournald2]
 1833 ?        S      0:00 /usr/bin/ck-launch-session /etc/X11/chromeos-xsession
 1838 ?        S<     0:00 [kcryptd_io]
 1839 ?        S<     0:01 [kcryptd]
 1869 ?        S      3:23 /usr/bin/chromeos-wm --hotkey_overlay_image_dir=/usr/share/chromeos-assets/images --panel_anchor_image=/usr/share/chromeos-assets/
 1870 ?        S      0:00 /bin/sh /usr/bin/chromeos-chrome-loop
 1871 ?        S      0:00 /usr/bin/xscreensaver -no-splash
 1900 ?        S      0:00 /usr/lib/devicekit-power/devkit-power-daemon
 1912 ?        S      0:00 /usr/lib/devicekit-disks/devkit-disks-daemon
 1913 ?        S      0:00 devkit-disks-daemon: not polling any devices
 1927 ?        S      0:00 /usr/bin/xterm -bg black -fg grey
 1928 pts/0    Ss     0:00 bash
 2016 ?        Sl     0:04 /opt/google/chrome/chrome --enable-gview --no-first-run
 2022 ?        S      0:00 /opt/google/chrome/chrome --enable-gview --no-first-run
 2023 ?        S      0:00 /opt/google/chrome/chrome --type=zygote
 2032 ?        Rl     0:01 /opt/google/chrome/chrome --channel=2032.b289850.535399988 --type=renderer --lang=en-US --force-fieldtest=AsyncSlowStart/_AsyncSlo
 2042 ?        Sl     0:00 /opt/google/chrome/chrome --channel=2032.b49f450.1173946133 --type=renderer --lang=en-US --force-fieldtest=AsyncSlowStart/_AsyncSl
 2045 pts/0    S+     0:00 /bin/bash
 2070 ?        Ss     0:00 /usr/sbin/sshd
 2073 ?        Ss     0:00 sshd: chronos [priv]
 2087 ?        R      0:00 sshd: chronos@pts/1
 2088 pts/1    Ss     0:00 -bash
 2097 pts/1    R      0:00 /bin/bash
 2117 pts/1    R+     0:00 ps ax
root@localhost:~#

使っているメモリは？

root@localhost:~# free
             total       used       free     shared    buffers     cached
Mem:        252540     245160       7380          0        776     169580
-/+ buffers/cache:      74804     177736
Swap:            0          0          0
root@localhost:~#

75MB程度。（もっともキャッシュでメモリの殆どは利用されているが。でも256MBもあれば十分か。これであれば、Dynabook SS 3480 (PORTEGE 3480 DS60P/1N2T)でも動かせそう。（“UbuntuとVMwareでThin Clientを作ってみた”の記事で使った10年選手のラップトップPC。）

仮想ディスクには約1GBのスワップ領域があったが、システムでは全く使っていない（スワップ無し）。本体で大したアプリケーションは動かさないから必要はないだろう。

さて、ディスクの使用量は？

root@localhost:~# df
Filesystem           1K-blocks      Used Available Use% Mounted on
rootfs                  957496    591148    317708  66% /
udev                    126268    126268         0 100% /dev
/dev/disk/by-label/C-ROOT
                        957496    591148    317708  66% /
/tmp                    126268        28    126240   1% /tmp
shmfs                   126268       140    126128   1% /dev/shm
/dev/sda1               957496     57460    851396   7% /mnt/stateful_partition
/dev/sda1               957496     57460    851396   7% /var/cache
/dev/sda1               957496     57460    851396   7% /var/log
vartmp                  126268        20    126248   1% /var/tmp
/dev/sda1               957496     57460    851396   7% /home
varrun                  126268        52    126216   1% /var/run
varlock                 126268         0    126268   0% /var/lock
/media                  126268         0    126268   0% /media
/dev/mapper/cryptohome
                        811972     31716    745272   5% /home/chronos
root@localhost:~#

大体600MB＋α程度か。（udev（/dev）が随分大きいような気がする。ここの部分はディスクの占有領域ではなくてメモリキャッシュかと思われるが。）

ちなみに、[F12]を押すとウィンドウ一覧になるが、こういったキーボードのショートカットは[F8]を押すとショートカット一覧の対話型メニューが現れ、確認できる。

（VMwareの仮想マシンでは画面サイズが小さくてショートカット一覧が全て表示しきれない。実機で動かせば全体が見れるのだが、スナップショットが撮れないので仮想マシンの画面を載せておいた。）

まぁ、あとは色々と楽しんでください。

■ Chrome OSをカスタマイズする

sshデーモンをシステム起動時に起動するように設定しようとして、色々やったのだが、上手くいかない。なんか標準のDebianと違うところがあるようだ。

仮想ディスクをマウントして、そこで設定を変えてから仮想マシンを立ち上げることで、設定をかえることは可能。例えば、次のようにする。

root@vmhost:~/tmp# ls
chromeos-image-999.999.32309.211410-a1.vmdk  chromeos-image.vmdk
chromeos-image-flat.vmdk
root@vmhost:~/tmp# mkdir work
root@vmhost:~/tmp# vmware-mount chromeos-image.vmdk 3 work/
root@vmhost:~/tmp# ls work/etc/init.d
acpid          keyboard-setup         procps              start_login.sh
alsa-utils     killprocs              rc                  stop-bootchart
bootchart      module-init-tools      rc.local            stop-bootlogd
bootlogd       mountall-bootclean.sh  rcS                 stop-bootlogd-single
bootlogs.sh    mountall.sh            README              udev
bootmisc.sh    mountdevsubfs.sh       reboot              udev-finish
checkfs.sh     mountkernfs.sh         rmnologin           umountfs
checkroot.sh   mountnfs-bootclean.sh  rsyslog             umountnfs.sh
console-setup  mountnfs.sh            sendsigs            umountroot
dbus           mountoverflowtmp       session_manager.sh  urandom
hal            mtab.sh                single              x11-common
halt           networking             skeleton            xstart.sh
hostname.sh    ntp                    slim
hwclock.sh     ondemand               ssh
root@vmhost:~/tmp#

ここで色々と設定を変える

root@vmhost:~/tmp# vmware-mount -d work/
root@vmhost:~/tmp#

この例ではオリジナルの“chromeos-image-999.999.32309.211410-a1.vmdk”から作成したフラット仮想ディスク“chromeos-image.vmdk”を使って設定を変えているが、可変仮想ディスクでも同様にマウントして変更出来る筈。（私は変更後のディスクイメージをUSBメモリにコピーして実機でも使えるようにしているので固定仮想ディスクを使って設定を変えている。フラットディスクの作成と、USBメモリへのコピーについては“Chrome OSをUSBブートで実機で使ってみる”を参照。）

これで、設定の変更はできるのだが、SSHの自動起動ができない。取り敢えずは手動で起動できるので、これはその内暇な時にでもやるか。

Permalink | コメント(0) | 00:36

■ VMware Server 2.0.2がリリースされた、しかし...

以下の話、“VMware Serverのコンフィグ時の警告について”に補足しておいた。結局、警告は特に問題ないようだ。

Ubuntu 8.04 LTS（長期サポート版）Serverと VMware Server 2.0.1で非常に安定して使っているのでブログに書くネタもなくなっていた。

ところが先週ごろ、Ubuntu 8.04のカーネルがバージョンアップになった。カーネルが 2.6.24-24 から 2.6.24-25 へアップした。

Linuxのカーネルのバージョンを上げるとVMware Serverが再コンフィグできなくなることが多い。ホストOSとしてFedoraを使っていた頃は結構頭を悩ましていた。しかも、Fedoraの場合、カーネルのバージョンを上げないと他の機能にも影響が出ることがあるので、無理やりVMware Serverにパッチを当てて対応していた。Ubuntu 8.04 LTS Serverをベースにしてからは、このようなことは無かったのだが....。

念のためルート・ファイルシステムのバックアップを取ってから、カーネルをバージョンアップして、VMware Server 2.0.1 の vmware-config.pl を実行してみた。するとvsockモジュールのコンパイルの部分で、

Using 2.6.x kernel build system.
make: Entering directory `/tmp/vmware-config0/vsock-only'
make -C /lib/modules/2.6.24-25-server/build/include/.. SUBDIRS=$PWD SRCROOT=$PWD/. modules
make[1]: Entering directory `/usr/src/linux-headers-2.6.24-25-server'
  CC [M]  /tmp/vmware-config0/vsock-only/linux/af_vsock.o
  CC [M]  /tmp/vmware-config0/vsock-only/linux/driverLog.o
  CC [M]  /tmp/vmware-config0/vsock-only/linux/util.o
  CC [M]  /tmp/vmware-config0/vsock-only/linux/vsockAddr.o
  LD [M]  /tmp/vmware-config0/vsock-only/vsock.o
  Building modules, stage 2.
  MODPOST 1 modules
WARNING: "VMCIDatagram_CreateHnd" [/tmp/vmware-config0/vsock-only/vsock.ko] undefined!
WARNING: "VMCIDatagram_DestroyHnd" [/tmp/vmware-config0/vsock-only/vsock.ko] undefined!
WARNING: "VMCI_GetContextID" [/tmp/vmware-config0/vsock-only/vsock.ko] undefined!
WARNING: "VMCIDatagram_Send" [/tmp/vmware-config0/vsock-only/vsock.ko] undefined!
  CC      /tmp/vmware-config0/vsock-only/vsock.mod.o
  LD [M]  /tmp/vmware-config0/vsock-only/vsock.ko
make[1]: Leaving directory `/usr/src/linux-headers-2.6.24-25-server'
cp -f vsock.ko ./../vsock.o
make: Leaving directory `/tmp/vmware-config0/vsock-only'
The vsock module loads perfectly into the running kernel.

警告（WARNING）が出ている。一応は“The vsock module loads perfectly into the running kernel.”ということでカーネルへのモジュールの組込みは成功しているものの、ちょっと気持ち悪い。

さて、どうしたものか。ネットをあちこち見ていると、なんと昨日、VMware Server 2.0.2がリリースされているではないか。“これはホストOSとしての要件リストにあるUbuntu 8.04 LTSのカーネル更新に合わせてリリースされたに違いない”などと妄想を抱きつつダウンロードして、インストールしてみた。しかし、結果は全く同じ。（警告メッセージの部分は一字一句同じ。）

ところで、この警告メッセージについて調べたところ、ちょっと古い書込みだがVMwareのコミュニティサイトでこんなのを見つけた。

“VMware Communities: Install problem ...”

この中に“Nothing in Server 2.0 requires or uses VSock, it's just a useful communication API/platform for people (ISVs, developers) building services that need to communicate between hosts and guests with high bandwidth/low latency (i.e. faster than guest networking).”というVMwareロゴ付きの書込みがある。つまり、ゲストOSとの高速通信を必要とするアプリケーションをソフトベンダなどが開発のためのものであり、VMware Server製品では使っていない、ということなので普通に使う上では必要ないらしい。

ここで、取りうる選択は次の２つだろう。

1. カーネル 2.6.24-24 ＋ VMware Server 2.0.1 の安定環境でもうしばらく使い続けて、将来 VMware Server 2.0.3とかが出てきてカーネル 2.6.24-25と共にバージョンアップ。（もしくは、カーネルのバージョンを上げないと他の機能にも影響が出てくるまで。）リスクとしてはLinuxもVMware Serverも既知のバグと脆弱性を内在しながら使わなければならないこと。しかし、外向けのサーバではないし、ホストOSは仮想マシン・エンジンとしてしか使っていないので、それ程のリスクにはならない。
2. カーネル 2.6.24-25 ＋ VMware Server 2.0.2 の組み合わせで vsock の機能無しで利用する。特にリスクは無いが、vsockが使えないことで、どれ程の影響が出るかが心配。

２の方法でもいいのだけど、２の方法で環境を設定してしまうと１の環境に戻せない事が悩ましい。（ゲストOSにインストールするVMware Toolsもバージョンアップしなければならないので。）　当面は１の方法で運用して、必要に迫られたら２に移行するか。

■　VMware Server 2.0.2って何だ！？

さて、半年以上経ってバージョンアップされたVMware Serverだが、何が改善されたのかとRelease Noteを見てみると....。

なんと２つの脆弱性が解決されているだけで、既知の問題が山ほどある。う〜ん、何のためのバージョンアップなのだろうか？　せめて（ユーザガイドの要件リストにある）ホストOSのカーネルのバージョンアップにくらい対応しておいて欲しい。

なんとなくだが、VMware社は株式公開してから無償製品や個人向け製品に力を入れなくなったような気がする。もっぱらデータセンタ向け製品や企業向け製品に力をいれている。もちろん利益を上げるためそうした方向は構わないのだが、今まで無償製品を使って来ている個人ユーザをがっかりさせないで欲しい。VMware Server 1.xの頃は頻繁にバージョンアップしてくれていたので助かっていたが。

今は取り敢えず安定して動いているの良いが、VMware Server製品の対応が今のままであれば、次回マシンを入れ替えるときはKVMや、改めてXenというのも現実的な選択肢かも知れない。それにWindows 7＋Virtual PCというのも評価次第では。２年前とは仮想マシンの環境も変わってきている。

そうそう、Windows 7といえば。VMware Server 2.0.2が昨日（10月27日）のリリースなので、“おぉ、いち早くWindows 7をゲストに使えるようにしたのか”という妄想を抱いても仕方あるまい。しかし、2.0.2をインストールして仮想マシンを作成するメニューで“Windows 7”は無かった。こちらも、ちょっと寂しい思いをしてしまった。

Permalink | コメント(0) | 22:55

■ 起動時のファイルの自動マウントについて

Linuxをブートしたした時にISOイメージファイルやHDDイメージファイルを自動的にマウントして利用する方法をメモしておく。（超小技程度の話なのだが、どうもautomountの設定をしようとすると毎回、基本的なところから調べなおしているので、ちょっとメモっておく。）

なお、ここではOSとしてFedora 8を使っているが、ベーシックなところなので大体のLinuxで同様に設定になると思う。（しかし、未だにFedora 9へアップグレードしようという“動機”が湧かない。）

■ ISOファイルをマウントしておく

“/home/Opticals/Fedora-8-x86_64-DVD.iso”というISOイメージファイルを、OSの起動時に自動的に“/mnt/F8-DVD”というディレクトリへマウントするようにしておく。

まず、/etc/fstabに次の一行を加える

/home/Opticals/Fedora-8-x86_64-DVD.iso	/mnt/F8-DVD	iso9660	ro,loop	0 0

ファイルのパスやマウント・オプションは利用している環境に合わせて適宜変更する。

これでリブートすれば起動時にマウントしてくれると思ったが、Fedora-8ではもう一つ、SELinuxの設定が必要だった。ローカルポリシを作る方法もあるが（後述）、ここでは“allow_mount_anyfile”という論理フラグを有効にしておく。論理フラグを変更するには“SELinux Management”ツールを使ってチェエクする、

か、setseboolコマンドを使って設定する。

[root@fedora-8 ~]# getsebool allow_mount_anyfile
allow_mount_anyfile --> off
[root@fedora-8 ~]# setsebool -P allow_mount_anyfile=on
[root@fedora-8 ~]# getsebool allow_mount_anyfile
allow_mount_anyfile --> on
[root@fedora-8 ~]# 

これでブート時にISOファイルを特定のディレクトリにマウントできる。

■ HDDイメージファイルをマウントしておく

次にHDDのイメージファイルをマウントする方法。これはディスクレスのクライアント用ルートファイルシステムを１つのファイルに格納しておいて、サーバでサービスする時にマウントして使う、といった利用方法である（PXEによるディスクレス・クライアント（総集編）/ クライアント用のファイルシステムの作成を参照）。ただし、ここで検証に使ったのは１つのファイルが１つのパーティション・イメージとなっているもの（つまりファイルを直接mkfsでフォーマットしたもの）で、１つのファイルが１つのHDDイメージのもの（つまり複数のパーティションを持つ仮想ディスクのようなイメージ、「HDDイメージファイルをマウントして使う方法」参照）ではない。複数のパーティションを持つHDDイメージタイプのものでもoffsetを指定すればマウントできる筈だが、ここではパーティション・イメージのファイルを使った。

“/home/ClientImages/Fedora-8.img”というパーティション・イメージのファイルを“/mnt/F-8.IMG”というディレクトリへマウントする。ただし、Fedora-8.imgはext3でフォーマットされているとする。これも次のような１行を/etc/fstabへ追加すればいい。

/home/ClientImages/Fedora-8.img         /mnt/F8-IMG     ext3    loop    0 0

ただし、Fedora 8等の環境ではやはりSELinuxがマウントを阻害する。今度は論理フラグの設定だけでは回避できないのでローカルポリシーを設定する必要がある。

一旦、SELinuxのモードをPermissiveにしてリブート、audit2allowコマンドでポリシーのひな形をつくる。まず、“SELinux Management”ツールでSELinuxをPermissiveにしてリーブし、リブート直後に次の要領でローカルポリシを設定する。（なお、先ほどのallow_mount_anyfile論理フラグがonになっているとreadパーミッションは通ってしまうのでwriteのみのひな形が出来る。allow_mount_anyfile論理フラグを一旦offにしてからリブートし、read/writeをまとめてローカルポリシとして設定した方が（設定があちこちに分散しないので）良いだろう。

[root@fedora-8 ~]# mkdir tmp
[root@fedora-8 ~]# cd tmp
[root@fedora-8 tmp]# audit2allow -a -l -m LocalMount > LocalMount.te
[root@fedora-8 tmp]# ls
LocalMount.te
[root@fedora-8 tmp]# cat LocalMount.te 

module LocalMount 1.0;

require {
        type home_root_t;
        type mount_t;
        class file { read write };
}

#============= mount_t ==============
allow mount_t home_root_t:file { read write };
[root@fedora-8 tmp]# make -f /usr/share/selinux/devel/Makefile
Compiling targeted LocalMount module
/usr/bin/checkmodule:  loading policy configuration from tmp/LocalMount.tmp
/usr/bin/checkmodule:  policy configuration loaded
/usr/bin/checkmodule:  writing binary representation (version 6) to tmp/LocalMount.mod
Creating targeted LocalMount.pp policy package
rm tmp/LocalMount.mod tmp/LocalMount.mod.fc
[root@fedora-8 tmp]# ls
LocalMount.fc  LocalMount.if  LocalMount.pp  LocalMount.te  tmp
[root@fedora-8 tmp]# semodule -l | grep Local
[root@fedora-8 tmp]# semodule -i LocalMount.pp
[root@fedora-8 tmp]# semodule -l | grep Local
LocalMount      1.0
[root@fedora-8 tmp]# 

■ automountを使う

/etc/fstabに記述することによって起動時から定常的にマウントできるが、普段あまり使わないファイルシステムであれば、定常的にマウントするよりは必要な時に“自動的に”マウントできる方がいい。（mountコマンドで通常使わないファイルがマウントされている情報が出るのも気分的には良くなし、まして、マウントしている状態でイメージファイルを消してしまうと言うことも考えられる。）その場合に利用するできるのはaoutomountの機能となる。（元々はローカルなデバイスをマウントすると言うより、NFSの環境で必要に応じてサーバにマウントするために開発された機能だが。）

オートマウントを利用するためには、マスタ・マップ・ファイルの/etc/auto.masterと、マスタマップで指定されるマップファイル/etc/auto.*というファイルを設定する。上の例のISOファイルだが、このファイルはどこにマウントしても構わないので、automountが一般的に使かう“/misc”の下にマウントするようにする。その場合はマスタマップは変更することなしに、/etc/auto.miscというマップファイルを変更する。ここでは“Fedora-8-x86_64-DVD.iso”というファイルを“/misc/F8-DVD”というディレクトリにマウントするようにする。/etc/auto.miscに次の一行を加える。

F8-DVD	-fstype=iso9660,loop,ro,nosuid,nodev		:/home/Opticals/Fedora-8-x86_64-DVD.iso

（先程の/etc/fstabでマウントしているのであれば、fstabをコメントして、ファイルをアンマウントしておいた方がいい。）

次に、autofsサービスを再起動する。

[root@fedora-8 ~]# service autofs restart
Stopping automount:                                        [  OK  ]
Starting automount:                                        [  OK  ]
[root@fedora-8 ~]# 

これで自動マウントの設定が有効になる。普段、/miscの下は空だが、/misc/F8-DVD というディレクトリにアクセスしようとすると、自動的に“/misc/F8-DVD”というディレクトリが作られ、さらに auto.miscで指定したファイル（やデバイス）をマウントする。

[root@fedora-8 ~]# ls /misc
[root@fedora-8 ~]# ls /misc/F8-DVD
fedora.css                     RPM-GPG-KEY
GPL                            RPM-GPG-KEY-beta
images                         RPM-GPG-KEY-fedora
isolinux                       RPM-GPG-KEY-fedora-rawhide
Packages                       RPM-GPG-KEY-fedora-test
README-BURNING-ISOS-en_US.txt  RPM-GPG-KEY-rawhide
RELEASE-NOTES-en_US.html       stylesheet-images
repodata                       TRANS.TBL
[root@fedora-8 ~]# ls /misc
F8-DVD
[root@fedora-8 ~]# 

標準設定ではマウントしたディレクトリがビジーでなく、5分間アクセスが無ければ、自動的にアンマウントされディレクトリも削除される。

次に“/home/ClientImages/Fedora-8.img”を自動マウントするようにする。このHDDイメージも/miscの下にマウントするのであれば、上の例と同様に/etc/auto.miscに追加すればいい。

F8-IMG	-fstype=ext3,loop		:/home/ClientImages/Fedora-8.img

しかし、このファイルはディスクレス・クライアントのルートファイルシステムが格納されているという想定であり、/tftpboot等の下のディレクトリにマウントしたい。そこでautomountのマスタマップに次の１行を追加する。

/tftpboot/dlroots		/etc/auto.dlroots

（“dlroots”の名前は何でも構わない。ここではDiskless rootという意味でdlrootsにした。ちなみに余談だがNISを使っていない環境ではマスタマップの“+auto.master”の行は“#”でコメントアウトしておく。autofsサービスが起動する度にログに警告メッセージが残るので。）

次のこのエントリに対応するマップファイル/etc/auto.dlrootsを作成する。

[root@fedora-8 ~]# vi /etc/auto.dlroots

	：

[root@fedora-8 ~]# cat /etc/auto.dlroots
#
# This is an automounter map and it has the following format
# key [ -mount-options-separated-by-comma ] location
# Details may be found in the autofs(5) manpage

f8	-fstype=ext3,loop		:/home/ClientImages/Fedora-8.img
[root@fedora-8 ~]# 

以上で、ディスクレス・クライアントのルートファイルシステムを/tftpboot/dlroots/f8へ自動マウントするような設定にした。

最後に、Fedora 8等の環境ではSELinuxのローカルポリシが必要なる。SELinuxの標準設定ではautomountは/tftpbootの下にはアクセスできないらしい。ローカルポリシの設定の仕方は上の方法と同じで、一旦 permissiveにしておいて起動いしてaudit2allowコマンドを使って雛型を作成、ポリシを更新する。

[root@fedora-8 ~]# mkdir tmp2
[root@fedora-8 ~]# cd tmp2
[root@fedora-8 tmp2]# audit2allow -a -l -m LocalAutofs > LocalAutofs.te
[root@fedora-8 tmp2]# cat LocalAutofs.te 

module LocalAutofs 1.0;

require {
        type automount_t;
        type tftpdir_t;
        class dir mounton;
}

#============= automount_t ==============
allow automount_t tftpdir_t:dir mounton;
[root@fedora-8 tmp2]# make -f /usr/share/selinux/devel/Makefile
Compiling targeted LocalAutofs module
/usr/bin/checkmodule:  loading policy configuration from tmp/LocalAutofs.tmp
/usr/bin/checkmodule:  policy configuration loaded
/usr/bin/checkmodule:  writing binary representation (version 6) to tmp/LocalAutofs.mod
Creating targeted LocalAutofs.pp policy package
rm tmp/LocalAutofs.mod.fc tmp/LocalAutofs.mod
[root@fedora-8 tmp2]# ls
LocalAutofs.fc  LocalAutofs.if  LocalAutofs.pp  LocalAutofs.te  tmp
[root@fedora-8 tmp2]# semodule -i LocalAutofs.pp
[root@fedora-8 tmp2]# semodule -l | grep Local
LocalAutofs     1.0
LocalMount      1.0
[root@fedora-8 tmp2]# 

これでautofsサービスを再起動してアクセスすると次のようになる。

[root@fedora-8 ~]# ls /tftpboot/dlroots/
[root@fedora-8 ~]# ls /tftpboot/dlroots/f8
lost+found  root  snapshot
[root@fedora-8 ~]# ls /tftpboot/dlroots/
f8
[root@fedora-8 ~]# 

これで実際にディスクレス・クライアントを立ち上げると、自動的に/tftpboot/dlroots/f8をマウントして問題なくクライアントが立ち上がる。ただし、クライアントを1回起動するとマウントポイント以下がビジーとなりアンマウントされなくなる。NFSのデーモンが/tftpboot/dlroots以下のリソースを掴んだままになるらしい。別にマウントされたまま使い続けても問題はないが、気分的にすっきりしたいのであればNFSのサービスを再起動すれば、そのうち自動的にアンマウントされる。

■ SELinuxのローカルポリシのまとめ

ローカルポリシは2つになる。1つはmountコマンドに関するもの。もう一つはautomountに関するもの。mount関連のポリシではいくつかのファイルコンテキストに対して読み書きができないので、それを許可するように設定する。私の環境ではmountするファイルがあちらこちらのディレクトリに分散しているので幾つかのコンテキストに対して許可をする必要があった。（いまのところhome_root_t、tftpdir_t、samba_share_tである。）最終的に次のようなローカルポリシを追加した。

[root@fedora-8 LocalMount]# cat LocalMount.te

module LocalMount 1.0;

require {
        type home_root_t;
        type tftpdir_t;
        type samba_share_t;
        type mount_t;
        class file { read write };
}

#============= mount_t ==============
allow mount_t home_root_t:file { read write };

#============= mount_t ==============
allow mount_t tftpdir_t:file { read write };

#============= mount_t ==============
allow mount_t samba_share_t:file { read write };
[root@fedora-8 LocalMount]#

これらのポリシのreadに関しては論理フラグ allow_mount_anyfile を on にすることで対応できるが、writeに関してはallow_mount_anyfileでは対応できないので、ローカルポリシを設定する必要ある。（ファイルをroでマウントする場合、つまりISOファイル等をマウントする場合はallow_mount_anyfileの設定だけでも良い。）

automountに関しては先ほどの通り、tftpdir_tに対してマウントできるようにしておく。

[root@fedora-8 LocalAutofs]# cat LocalAutofs.te

module LocalAutofs 1.0;

require {
        type automount_t;
        type tftpdir_t;
        class dir mounton;
}

#============= automount_t ==============
allow automount_t tftpdir_t:dir mounton;
[root@fedora-8 LocalAutofs]# 

Permalink | コメント(0) | 23:52

■ VMware Server 2.0 RC1を使ってみる

7月1日にVMware Server 2.0のRC1（Release Candidate 1）が出た。ちょっと忙しくてインストールできなかったが、週末にちょっと試してみた。

今回のRC1のリリースで嬉しいことが2つあった。

1. コンパイルエラー無し（もちろんパッチ無し）でVMware Serverをインストールできるようになった。
2. Fedora 8やFedora 9をゲストする際、Kernel 2.6.25にVMware Toolsが対応していなかったのが解消した。

全体的には、いい感じで仕上がりつつある感じである。また、今回はβ2から気になっていたリモートコンソールについて直接起動する方法も見つけたので書き留めておく。（「 vmware-vmrcというリモートコンソールの本体だけを使う」）

2008/08/19に“RC2”が出たので、ちょっとだけ使ってみた。「VMware Server 2.0 RC2を使ってみる」

RC1から大幅に変わっているところは別に無さそうだ。

■ 何の問題もなくインストールできた

インストールするホストはいつもの実験用Inspiron 1501＋Ubuntu 8.04にした。RC1の"VMware Server Users Guide"にある正式サポートのホストOSとして、ついに"Ubuntu Linux 8.04"が載った！ これでvmware-any-any-updateに悩まされることもなく、長期に安定してVMware Server 2.xを利用することができる。UbuntuのLTS（長期間サポート版）は個人で利用する人間としてもありがたい。今後、FedoraはもっぱらゲストOSとして使うことになるだろう。

丁度、Inspironにはちょっとした実験のためXen Expressをインストールしてあったが、これをつぶしてUbuntsu 8.04をクリーンインストールする。ソフトウェアの更新を終了してから、その状態で一旦バックアップをとっておき、いよいよVMware Server RC1をインストールする。Ubuntuなので（Fedoraと異なりrpm版ではなく）tar.gz版を使いtarで展開した後、vmware-server-distribにて"./vmware-install.pl"コマンドでインストールする。ネットワークの構成や"Virtual Machines"へのパスなど、一部のカスタマイズを除いて殆どデフォルト値でインストールした。ベータ2でコンパイルできなかったvsockも問題なくコンパイルできた。（VMwareの人の投稿どおり、修正されていた。）

今までFedoraの環境でパッチを当てたり、気分的には良くない警告メッセージに悩まされてきたことを思うと嘘のようである。（vsockのコンパイル時に3行警告メッセージは出たが、それ以外は全くなかった。ちなみにこの警告メッセージは私がβ2で無理矢理ソースを変更してコンパイルした時のものと全く同じだった。多分、同じところを修正しただけなのだろう。「追記：”vsock module”のコンパイル」参照。）なお、β2で出ていた「VMware Server Web Accessを使うためにIPv6の機能を無効にすることを勧めます」というメッセージはなくなったので、UbuntuのIPv6の機能はそのまま有効にしておいた。

VMware Server 2.0からはWebベースの管理画面（のVMware Server Web Access）になる。ブラウザを使ったアクセスの仕方や、管理画面の構成はベータ2と殆ど変らなかったので、ここでは特に細かくは触れない。（VMware Server 2.0 β2のインストール」を参照）一点だけ。Internet Explorerで、以前β2などで一回ActiveXをインストールしていると、RC1のActiveXがインストールできない。そこで次のメッセージに従って、一旦、以前のActiveXを削除してから、再度インストールする必要がある。

An outdated VMware Remote Console plug-in has been detected and must be uninstalled in order to install the new version.
Click here for instructions on how to uninstall the old plug-in. Details
1. Close all instances of Internet Explorer.
2. Open Control Panel > Internet Options > Programs > Manage Add-ons.The Manage Add-ons dialog box is displayed.
3. Select the VMwareRemoteConsole Class add-on.
4. In the Delete ActiveX section of the dialog box, click Delete.
5. Click OK.
6. Restart Internet Explorer.
7. Return to the console tab of any virtual machine and install the VMware Remote Console plug-in.

（ 1.一旦IEを閉じる。 2.コントロールパネルのあるインターネットオプションを開き、［プログラム］タブから［アドオンの管理］をクリックする。 3. VMwareRemoteConsole Class add-onを選択し、 4.［削除］ボタンをクリック、 5.OKをクリックしでActiveXを削除する。 6. IEを再度立ち上げる。 7. VMware Remote Console plug-inをインストールする。）

さて、VMware Server Web Accessも使えるようになって、これも問題なく利用できるか、と思ったら、何と仮想マシンの新規作成ができなかった。新規作成のガイド画面の最初のところで止まってしまう。［NEXT］ボタンを押しても受け付けない。何度やってもだめなので、vmware-config.plから再度設定してみたが、これも何回やってもNG。vmwareをアンインストールして再度やってもNG。仕方ないので、Ubuntuのバックアップを戻してVMware Server最初からインストールしたら、今度はOKになった。（Ubuntuをバックアップしておいて良かった。）原因は不明だが、最初のインストールの時にNATインタフェースを2つで設定していた（デフォルトでは1つ）。2回目のインストールでは、デフォルトと異なることは出来る限り避けたのでNATインタフェースは1つだけ。これが原因とは考えにくいが、思いつく違いはこれ位しかない。

何はともあれ、ちゃんと動いたのでヨシとした。

■ Webベース管理画面はイマイチ

VMware Server 1.xで使っていたバイナリベースのRemote Consoleと違い、WebベースのVMware Server Web AccessはActiveXなどで実現されているため、どうしても動作がまったりする。サクサク動かない。特にブラウザを動かすクライアントコンピュータはサーバのように高性能ではないので、ちょっと、いらつく。

それから、まだ完成度が低い（開発途中）のためか、マウス操作の環境がいま一つ。例えば、ゲストマシンの設定を確認もしくは変更する場合に、思わず左のInventoryのアイコンをマウスで右クリックしてしまう。Windowsにしろ、GNOMEにしろExplorer等で慣れ親しんだマウスの操作だ。しかし、VMware Server Web Accessでマウスの右クリックを行うと"ブラウザのメニュー"が表示される。普段使っているGUI環境と操作性が異なるので、「使いづらい」という印象が出てしまう。

もう一点、VMware Server Web Accessでイタダケナイのは、リモートコンソール画面である。VMware ServerのリモートコンソールはVMware Server Web Accessとは独立して別のウィンドになっている。Xenのようにゲストのコンソールが管理画面に組み込まれていない。従って、見た目も不自然である。コンソール画面を管理画面とは独立して表示するつもりであれば、最初から［Console］タブのようなものは設けなかっただろう。現在の状況はまだ開発途上であり、将来コンソール画面を管理画面に組み込む計画なのか、または、最初は組み込み式でデザインしたが途中から方針が変わって独立になったため余り意味のない［Console］タブが残ってしまったのか。

そして見た目より困るのは、コンソール画面を出すためにWeb Accessで仮想マシンをONにして、次にリモートコンソールを開くという2段階の手続きになるため、リモートコンソールが出た時には既に仮想マシンのブートがある程度のところまで進んでしまっていることだ。つまり、BIOSで止めたり、ブートローダを選択することができなくなってしまう。仮想マシンが停止した状態でリモートコンソール画面を出すことができないので、こうなってしまう。何とかならないものか。

色々といじっていて気がついたのだが、管理画面のWeb Accessと、仮想マシンのRemote Consoleが分離してしまったのは、Remote ConsoleをVMware Server専用ではなく、VMware Player、VMware Workstationと共通化（というか、同じ1本のソフトウェアで実現）しようとしたためのような気がする。つまり純粋にRemote Consoleの機能以外のもの（例えば、サーバ上での仮想マシンの設定など）はRemote Consoleに埋め込まず簡易なWeb Accessで実現しようとしたためではないだろうか。そのためにVMware Server 2.0からはWeb AccessとRemote Consoleの一体感がなくなったしまったように思える。（この点に関してはXenの方が好きだ。）

リモートコンソールに関してはもう一つ、ゲストのコンソール画面のスクリーンキャプチャができなくなったもの頂けない。Windowsのブルースクリーンのような情報もスクリーンキャプチャがあれば証拠として保存できたのだが。（リモートコンソール・ウィンドウ自信をキャプチャすることはできるが、あとで画像エディタでフレームを取り除く必要があり、ユーザにとっては不便だ。）

とにかく、BIOSの段階で止めたりできないのは大変不便なので、ちょっと抜け道を見つけてみた。（⇒続き）

Permalink | コメント(0) | 11:38

■ Linux Kernel 2.6.25でもVMware Toolsが使えるようになった

Fedora 8やFedora 9では既にカーネルが2.6.25になってしまっている。これらのOSをゲストとするとVMware Toolsがインストールできない、といったトラブルが続いていた。マウスのオペレーションがちょっと不便だったのと、テキストのコピー＆ペーストができないのが不便、といった程度なので我慢して使っていたが、RC1に付属しているVMware Toolsをインストールしてみたところ、こちらも気持よくコンパイルできた。

ただし、Fedora-8でも問題なく使えたが、Fodora-9ではVMware Toolsをインストールすると、/var/log/Xorg.0.logに次のようなログを残してXウィンドウが立ち上がらない。

(II) LoadModule: "vmware"

(II) Loading /usr/lib64/xorg/modules/drivers//vmware_drv.so
dlopen: /usr/lib64/xorg/modules/drivers//vmware_drv.so: undefined symbol: PictureScreenPrivateIndex
(EE) Failed to load /usr/lib64/xorg/modules/drivers//vmware_drv.so
(II) UnloadModule: "vmware"
(EE) Failed to load module "vmware" (loader failed, 7)

VMware Serverはまだ正式版ではなくRC1なので、今後F9（というよりはXorgの新バージョン）に対応して行くことを期待したい。

あと、F8でもF9でも、"HGFS"が使えない。カーネルモジュールは正常に組み込まれているが、ブート時にエラー的なメッセージが出る。HGFSは今まで使ったことがなかったので、設定の問題だけかも知れないが。

Permalink | コメント(0) | 11:38

■ Fedora 8のカーネル2.6.24とVMware Server

Fedora 8のカーネルが2.6.24.7から2.6.25.4へ上がった。"ソフトウェアの更新"で余り何も考えずにアップグレードしてしてしまった。「またvmware-config.plを実行して設定ファイルをいくつか直さなければならない」と思いつつ。そしたら、ソフトウェアの更新後リブートして、vmware-config.plを実行したらコンパイルが通らない。「any-any-updateの最新版を当ててみるか」と思い、http://groups.google.com/group/vmkernelnewbies/files をアクセスする。すると、

ファイル名	アップロードの実行者	サイズ	アップロードを行った日付
vmware-any-any-update117.tgz	Peter Teoh	483.2 KB	5月6日
vmware-any-any-update117.tgz (2)	Peter Teoh	483.8 KB	5月7日
vmware-any-any-update117a.tgz	@rik	483.7 KB	5月15日
vmware-any-any-update117b.tgz	Sumant	2.4 MB	6月6日

とany-any-update117が4つもある。どれを使えば良いのか？　仕方ないので、(2)、a、b、と順番に試してみた。（「(2)」と「a」は含まれている内容は同じだった。どうもバージョン管理が混乱している。） 結果、117bを使ってvmware-config.plは無事、カーネルモジュールをコンパイルすることができた。ただ、いくつか気になることかがある。

1. any-any-updateのメインストリームではない（メインストリームがあるのかわからないが）。ちなみに、作成者のSumant氏のホームページはここ：http://www.dre.vanderbilt.edu/~sutambe/?p=27 元々はFedora 8 2.6.24のために作ったらしい。
2. ".gz"の拡張子がついているが、ファイルは圧縮されていないtar形式。単なるオペチョンとは思うが、大丈夫かなぁと心配。
3. vmmonのコンパイル中の警告（warning）も結構ある。（vmnetに関しては全く出てこない。）
4. これらの4つのパッチはどれもany-any-update116ではなく115をベースにしている。（といっても、どうやら116自身がメインストリームではないのかも知れない。最近、ayn-ayn-updateは http://platan.vc.cvut.cz/ftp/pub/vmware 以外に最新版が置かれるようになっていて、どれが（本当の）最新版なのかよくわからない。）

vmware-any-any-update117bを使ってvmmonモジュールをコンパイルしたログは以下のとおり。いつもより警告メッセージが多いような。

Building for VMware Server 1.0.0.
Using 2.6.x kernel build system.
make: Entering directory `/tmp/vmware-config6/vmmon-only'
make -C /lib/modules/2.6.25.4-10.fc8/build/include/.. SUBDIRS=$PWD SRCROOT=$PWD/. modules
make[1]: Entering directory `/usr/src/kernels/2.6.25.4-10.fc8-x86_64'
  CC [M]  /tmp/vmware-config6/vmmon-only/linux/driver.o
  CC [M]  /tmp/vmware-config6/vmmon-only/linux/driverLog.o
  CC [M]  /tmp/vmware-config6/vmmon-only/linux/hostif.o
  CC [M]  /tmp/vmware-config6/vmmon-only/common/comport.o
  CC [M]  /tmp/vmware-config6/vmmon-only/common/cpuid.o
  CC [M]  /tmp/vmware-config6/vmmon-only/common/hash.o
  CC [M]  /tmp/vmware-config6/vmmon-only/common/memtrack.o
  CC [M]  /tmp/vmware-config6/vmmon-only/common/phystrack.o
  CC [M]  /tmp/vmware-config6/vmmon-only/common/task.o
cc1plus: warning: command line option "-Werror-implicit-function-declaration" is valid for C/ObjC but not for C++
cc1plus: warning: command line option "-Wdeclaration-after-statement" is valid for C/ObjC but not for C++
cc1plus: warning: command line option "-Wno-pointer-sign" is valid for C/ObjC but not for C++
cc1plus: warning: command line option "-Wstrict-prototypes" is valid for Ada/C/ObjC but not for C++
/tmp/vmware-config6/vmmon-only/common/task_compat.h: In function ‘void Task_Switch_V45(VMDriver*, Vcpuid)’:
/tmp/vmware-config6/vmmon-only/common/task_compat.h:2666: warning: ‘sysenterState.SysenterStateV45::validEIP’ may be used uninitialized in this function
/tmp/vmware-config6/vmmon-only/common/task_compat.h:2666: warning: ‘sysenterState.SysenterStateV45::cs’ may be used uninitialized in this function
/tmp/vmware-config6/vmmon-only/common/task_compat.h:2666: warning: ‘sysenterState.SysenterStateV45::rsp’ may be used uninitialized in this function
/tmp/vmware-config6/vmmon-only/common/task_compat.h:2666: warning: ‘sysenterState.SysenterStateV45::rip’ may be used uninitialized in this function
  CC [M]  /tmp/vmware-config6/vmmon-only/common/vmciContext.o
  CC [M]  /tmp/vmware-config6/vmmon-only/common/vmciDatagram.o
  CC [M]  /tmp/vmware-config6/vmmon-only/common/vmciDriver.o
  CC [M]  /tmp/vmware-config6/vmmon-only/common/vmciDs.o
  CC [M]  /tmp/vmware-config6/vmmon-only/common/vmciGroup.o
  CC [M]  /tmp/vmware-config6/vmmon-only/common/vmciHashtable.o
  CC [M]  /tmp/vmware-config6/vmmon-only/common/vmciProcess.o
  CC [M]  /tmp/vmware-config6/vmmon-only/common/vmciResource.o
  CC [M]  /tmp/vmware-config6/vmmon-only/common/vmciSharedMem.o
  CC [M]  /tmp/vmware-config6/vmmon-only/common/vmx86.o
  CC [M]  /tmp/vmware-config6/vmmon-only/vmcore/compat.o
  CC [M]  /tmp/vmware-config6/vmmon-only/vmcore/moduleloop.o
  LD [M]  /tmp/vmware-config6/vmmon-only/vmmon.o
  Building modules, stage 2.
  MODPOST 1 modules
  CC      /tmp/vmware-config6/vmmon-only/vmmon.mod.o
  LD [M]  /tmp/vmware-config6/vmmon-only/vmmon.ko
make[1]: Leaving directory `/usr/src/kernels/2.6.25.4-10.fc8-x86_64'
cp -f vmmon.ko ./../vmmon.o
make: Leaving directory `/tmp/vmware-config6/vmmon-only'
The module loads perfectly in the running kernel.

2.6.25カーネルでコンパイルできるパッチを提供してくれたSumant氏に感謝しつつも、ちょっと様子見モード。念のために2.6.24のルート・ファイルシステムとブート・ファイルシステムはイメージファイルとしてしばらく保存しておき、何かあったら直に戻せるようにしておいた。（もっとも、VMwareが動作保障をしていないFedoraを使おうというところが、そもそも間違いなのだが。）

無理にカーネルのバージョンを上げることはないのだが

安定して動いているので、カーネルのバージョンを無理に上げる必要はないのだが、Fedoraの場合、頻繁に色々なソフトウェアのバージョンがあるので、ある程度追従していないと、そのうち更新が正常にできなく恐れがある。以前も、しばらくカーネルの更新だけをスキップして（他のソフトウェアは随時更新していた）、久しぶりに更新しようとしたら、うまく更新できないことがあった。

VMware Serverもバージョンが上がっている

VMware Serverも1.0.6へバージョンが上がっている。1.0.6は"Version 1.0.6 is a maintenance bug fix release"ということで、何が修正されているかというと、

• Virtual machines fail unexpectedly after a Symantec virus definition update from version 213 to version 220.
• Previous versions of VMware Server allowed using the VIX API from the guest operating system. In VMware Server 1.0.6 this is no longer allowed by default. This feature can be enabled in VMware Server 1.0.6 by setting a new parameter in the configuration (.vmx) file: vix.inGuest.enable="TRUE"

1番目の修正は、Symantecのウィルス対策ソフトは使っていないので、とりあえずは関係ない。（しかし、ウィルスの定義ファイルの更新で仮想マシンが落ちるなんてことがあるんだ、と感心してしまう。）

2番目の修正は結構、大きな修正だが、どちらかというと、今すぐ導入したくないかも。しばらく様子を見た後でも良いのでは？と思った。

ということで、今回は1.0.6へのバージョンアップは見送ることにした。ただでさえLinuxのカーネルバージョンが上がって心配なのに、同時に不安定要素を付け加えたくない。

VMware Serverの今後の導入方針

やはり、VMware社が動作保証リストに載せているUbuntuをベースにしたい。ただ、現時点では最新のLTS（長期サポート）版であるUbuntu 8.04（Linux 2.6.24ベース）はまだリストに載っていないので、VMware Server 2.0のリリース時に8.04がリストに載るのを期待したい。VMware Server 2.0β2では大きな問題もないので、たとえリストに載らなくても大丈夫だとは思うが。

あと、Fedora＋VMware Server 1.x から Ubuntu＋VMware Server 2.x への移行は、Server 2.0のリリース時期もあるが、新しいマザーボードでPCのハードウェアを一新してから行いたいので、Intel 4シリーズのチップセットG45チップセット対応のマザーボードが出そろったところで、考えてみたい。

Permalink | コメント(0) | 19:45