柔軟性が高いゆえにやっかないものに．．．(alternatives)
でびあんには， Alternatives-System という機能がある．
（参考：http://debian.fam.cx/index.php?Software%2FAlternatives-System）
これは，似たようなもの，例えばmpichとlam, viとvimとnviなど切り替えるのを一括管理する機能である．これ自体はcoolな機能だと思う．なぜなら，でびあんが管理しているディレクトリに管理外のファイルを置かなくてすむし，パッケージが削除された際にリンク切れとなることもない．
が，クラスタなどの複数のPCを管理するときには厄介になる．何が厄介になるかというと，でびあんのポリシーでは，各コンピュータの設定は/etc 以下に置くようになっている．Alternatives-System も同様に/etc/alternatives/に存在する．
結論を先に言ってしまえば，Alternativesはクラスタとして考えた場合，各コンピュータで管理されるものというよりは，クラスタ全体で共有されるものの色合いが強い．つまり，共有サーバにアプリケーションをインストールしたならば，クラスタPC全部や端末PC全部で同じように使えなければ，管理者からすればありがたくないことで，Alternatives-Systemはそれを引き起こすものの一つである．
ここでもう少し具体的なクラスタPCや端末PCについて考えてみる．最も多いと考えられるのが，NFSを使うものが多いと思われる．*1
NFSを使うといっても使う割合もいろいろあると考えられる．
例えば，
- /homeのみを共有してほかはすべてローカルディスクを使う
- /homeと /usr/などの共有プログラム用ディレクトリを共有する
- ルートパーティションごと共有し，個別の設定はローカルないしは，別の場所に保存する
などが考えられる．これらをもう少し考えてみる．
/homeのみを共有してほかはすべてローカルディスクを使う
/homeのみを共有する場合はAlternativesはそんなに問題がない．
むしろまったく同じ設定ができるか，インストールを自動化する仕組みはできるかなどが問題になる．こっち問題は，でびあんのパッケージのみを使うことにして，サーバで設定した項目を伝播するような仕組みを作れば，何とかなるかもしれない．
しかし，でびあんでもすべてのアプリケーションがあるわけでもなく，最新版でもない．なので，configre;make;make installすることは往々としてあるし，たとえ，checkinstallを使ってすべてのアプリケーションのパッケージを作ったとしても，個別のPCで設定しなければならないものもあるだろうし，それを自動化できるわけでもない．
少なくとも自分には無理であった．
*2
/homeと /usr/などの共有プログラム用ディレクトリを共有する
これもほぼ/homeのみを共有する場合と同様であるが，/usrを共有する場合には，さらにAlternativesが問題になる．具体的に見ると
# ls /usr/bin/vi -al lrwxrwxrwx 1 root root 20 Aug 5 2005 /usr/bin/vi -> /etc/alternatives/vi
となっていることがわかると思う．さらに
# ls -l /etc/alternatives/vi lrwxrwxrwx 1 root root 12 Jan 12 00:52 /etc/alternatives/vi -> /usr/bin/vim
となって，/etc/alternatives/のシンボリックリンクを操作することで，一括して似たようなアプリを管理できるようになっている．
つまり，/usrを共有してしまうと，/usr/bin/vi は存在するが，/etc/alternatives/vi が存在しない場合が管理者としてもユーザとしてもうれしくない状況である．
では，/etc/alternatives を共有してしまえということになるが，coolではないし，ここだけを共有すればいいのかということになる．
そもそも，/binにもalternativesを参照するものはあるし，パッケージをインストールしたときには，/varなどのディレクトリにファイルやディレクトリを作成することもある．
alternativesは，むしろでびあんでPCを一括管理した場合に問題になりやすい部分であり，これを解決しようと思ったとたん，さまざまな問題が存在することに気づかされる斥候のようなものだと思う
ルートパーティションごと共有し，個別の設定はローカルないしは，別の場所に保存する
現状のクラスターは，
- ネットワークブートし
- 全ノードがサーバの共有ディレクトリをルートパーティションとしてマウント
- ブートスクリプト中で以下の処理を行う
- 共有サーバ上の各ノード用のetcをマウント
- /varはローカルディスクがあればそれをマウント
- ローカルディスクがマウントできなければ，共有サーバ上の緊急用varをマウント
のような構成になっている．*3
現時では，alternativesの問題は残っている．現在考えている解決方法は，ありきたりだが/etcと/varをunion-fsにしてしまう方法である．union-fsについてはあちこちに書いてあると思われるが，ルートパーティション上の/{etc,var}をベースに引いて，各PC個別の/{etc,var}を上にかぶせ，読み込む場合は個別の/{etc,var}にファイルがあればそっちを読み込み，なければベースを読み込み，書き込みは個別のディレクトリに書きもむ．
イメージ的には，ベースのディレクトリにサランラップをまいているイメージに近いともう．unionというと構造体のunionが出てきてなんかイメージが違う気がするけど．
ほぼそれで解決できるのではないかと思われるが，まだ実行に移していない．理由としては時間がないこと，union-fsに移すことで現状のパッケージのツールがほとんど使えなくなること，管理用のツールを自分で作らねばならないこと．これらをほかの人に投げられないこと．考えればいくらで言い訳はできるかと．
あと，現状ではあまり気にはしていないが，サーバマシンへの負荷がある．
起動時のそれはとんでもなく，同時にノードを起動するとload avgは20を超える．．．
そうなると，dhcpでIPを取れなかったり，tftpからカーネルを取得できなかったり，nfsがマウントできなかったり，いくつか問題が発生する．確率的には128中3台ぐらいではないかと思われる．が，起動時だけなので特に問題にしていない．一時期，updatedbが一斉に起動して，サーバマシンに多大なる負荷をかけたことがあったが，今は停止している*4
とりあえず，現状は負荷の問題は起動時以外は確認できていない．むしろサーバがクラッシュした際にすべて止まることのほうが問題となっている．
今のところは起きていないが，起きたときは最悪である．バックアップはとってあるがホットスタンバイはできていない．．．何とかせねば．．．
*1:別のファイル共有システムを使っているとか，クラスターシステムを独自に作っている場合は除いて．たぶん，googleは
*2:以前のクラスタシステムのときに，OSをインストールした後に，makeをしたらIPの設定，hosts,nis,nfs,rsh,ssh,clockspeedまではやってくれるようにmakefileを作ったことがある．が，時間はかかるし，うまくはいかないし，なにしろ，再インストールの時間とその自動化にかける時間を考えるとモチベーションが維持できなくなる．なにしろ，いくら自動化して早く再インストールできたとしても，それを実感するためにわざわざ再インストールするわけにはいかないし...orz
*3:この時点で結構複雑になっているが，半分はパッケージでできてしまったりするｗ
*4:時間差でやる方法も考えたけどね
