問題は山積している

整理する。書きながら考えるメモ。

まず、VIVER CORE Serverに入れるファイルサーバー。適当なネットワークファイルシステムが見つからない。ファイルが共有できないと、いろいろできない。と言うか、何もできない。
現状、500MB超のシステムをメモリのぶちまけるのは、あまり現実的ではないと思う。システムをそれ以下のサイズに抑えることは可能だろうけど、その作業は面倒。ネットワークファイルシステムで共有できたほうが嬉しい。
あるいはHDDをキャッシュに使うか。でもHDDを積んだ瞬間、いろいろおいしくない。安くて壊れにくいストレージは無いものか。そろそろフラッシュメモリをキャッシュ代わりに積むことを前提にするのもアリか？512MBか1GBくらいあるだけでも全然違う。1GBで1,000円から2,000円くらい？…DRAMとさほど変わらないんじゃないか…DRAMの方が高いけど、性能が圧倒的に違うな…。
でもDRAMだと、スロット数などなどハード側の関係で制限があるかも。USBやIDE(CF/SSD)なら空いているはず。デスクトップ向けだと1GBあっても足りないかもしれないけど、その場合はHDDを積んでもいい気がする。

突然、フラッシュメモリをキャッシュに使うアイディア。キャッシュなので、特に内容を保持することは考えない。単純に全部swapにして、tmpfsのバックエンドに使うのはどうか。VIVER COREのpostboot=を使って、swapをパーティションIDで自動検出してswaponするスクリプトを起動する。

このフラッシュメモリには、swapの他に小さなパーティションを含むことができる。ブートローダや鍵、マシン固有設定ファイルなど。…ここまでするとメンテナンス性が下がるか。マシン固有設定ファイルはMACアドレスで識別してサーバーで管理した方が良いか。

swapが十分にあることを仮定するので、ネットワークファイルシステムで/usrなどを共有することなく、全部tmpfsにぶちまける。カーネルにうまくやっていただく。…これは楽だなぁ。結局共有だのCopy-on-Writeだのとやると、不安材料が出てきかねない。ローカルに保持するのが一番ラクだし、分かりやすいし、考えないといけない事項も少なくなる。
運用方法はまったく従来通り。パッチ当てやアップデートは適当なツールで。再起動する度にHDDが飛ぶので、リストア元としてマスター（マスタールートファイルシステム）を必ず用意しなければならない、と考えればいい。新規ノードのパッチ当てにはpostboot=が使える。

とりあえず、postboot=でswapを自動検出するスクリプトを作る必要がありそう。それからpostboot=に複数のファイルを指定できるようにする。セミコロン区切りで。スペース区切りでソースを冗長化。postboot=http://192.168.0.2:9000/autoswap.shとでも。

しかし、リストア元としてのマスターを考えると、マスターの更新が比較的頻繁に発生する可能性がある。新たなパッチを適用したり、パッケージを追加したりする度に（そしてそのテストを行うときにも）、マスターを変更する必要がある。現状、tar.gzで固めないといけないので、これは面倒。tar.gzに直接chrootして作業できればいいけど、そういうツールは…FUSEにありそうだけど、遅そう。
そうなるとやっぱりNFSか？という話になりそうだけど、ここはクライアント側からはRead Onlyで良く、しかもクライアント側にサーバーの変更を動的に反映する必要は必ずしも無い。そりゃサーバーに変更を加えるだけでクライアント側も動的に更新されると嬉しいけど、まずはそこまで求めなくてもいいんじゃないか。HDD起動より悪くなることはない。

というわけで、rsyncなんてどうだろう。rsyncdはNFSと違って軽量（いろいろな意味で）。
rooturl=でrsync://をサポートする。VIVER CORE Serverパッケージにstart-rsyncdを。

rsyncなんだから、クライアント側はcronでrsyncを回したっていいんじゃないか。cronでなくても、適当なポートへのアクセスをトリガにしてもいい。あまりに泥臭くて古典的だけど、まぁ確実。サーバーが落ちても影響が出ない。システム全体をrsyncすると負荷が気になるかな…。でも適当にスクリプトを書けばこういう小細工を実現できるあたり、ローカルに全ファイルがあるのは安心。

で、そろそろ、ネットワークブートしたクライアントにまったく同じコマンドを発行したくなってくる。実はこれは結構厄介。クライアントの状態が完全に同じだとは限らないから、あるノードではコマンドが失敗して、あるノードでは成功するかもしれない。そうなるととても面倒。あるいは、あるグループだけに適用したいかもしれない。
つまり、クライアント群の管理ツールが欲しくなってくる。商用のパッケージがたくさんありそうだけど、もちろんそれは使えない。

クライアントに対して一斉に適用した操作には何があるか。ソフトウェアパッケージのアップデートやインストール、独自アプリケーションの配置、設定ファイルの変更、アプリケーションの起動/終了/再起動、シャットダウン/リブート…くらいか。各種状態の取得は、たぶん別途監視ツールでやるべき。

ファイル操作系は、さっきのrsyncでできる。あるいはpostboot=と同じように、tar.gzで固めたパッケージを上書きするような方法でもいい。これだとtar.gzの作成が面倒だけど、/etc/のあるファイルだけ、と言うような場合にはこれで十分。後はこのコマンドをクライアント全部（あるいは特定のグループ）にどう発行するか。

アプリケーションの再起動は、おそらくファイルの操作と共に発生する。やっぱりpostboot=と同じように、tar.gzに入っている/runを実行する、と言う形でいいかも。シャットダウンやリブートも同じく。

syslogをサーバーに転送しておくようにしておけば、失敗したかどうかはそこそこ分かるはず。
む、VIVER CORE Serverにsyslogサーバーが要るか？postboot=でautosyslog.shとか。クライアントからの受信専用syslog(-ng)って設定できたっけ？

クライアントのグループ管理云々という話まで全部VIVER COREでやるのは、やり過ぎの感がある。そこは運用の問題なので。運用方法まで食い込むのは、次期RUNESからで。

次期RUNESはどこまでやるのか。何をやって何をやらないのか。
次期RUNESは、クライアントに個性を与える仕事をする。ネットワークブートすると、クライアントは全部まったく同じになる。しかしそれではネットワークにならないので、１台１台が別の動きをする必要がある。具体的に言えば、設定ファイルに書き込むIPアドレスやホスト名をノードごとに変えたり、ノードによってアプリケーションを起動したりしなかったりする。RUNESはそれをやる。その他はやらない。

設定ファイルに書き込むIPアドレスをノードごとに変えるにはどうするか。IPアドレスにまつわる情報をメタな情報で記述できるようにしておき、記述しておいてもらう。起動時にその情報を解釈し、実際の設定ファイル（あるいはコマンドライン引数）に変換し、アプリケーションを起動する。

「メタ」というと、基本的にはクライアントが自分を識別する方法は、サーバーから与えられるIPアドレス（DHCPサーバー）かブートパラメータ（ブートサーバー）くらいしかないので、１次ソースにはそれを使う。
一方、サーバーがクライアントの個体を識別する方法はMACアドレスくらいしかないので、ネットワーク全体を統括する設定ファイルは、MACアドレスをキーとしたテーブルになるはず（DHCPサーバーが別に存在することを前提とするなら、IPアドレスがキーになるかもしれない）。サーバーはこの設定ファイルを元にクライアントにパラメータを与える。クライアントはこのパラメータを受け取る。

…ここから先はまだ考えてない。たぶん、適当なスクリプト言語を使って、クライアントのグループをクラス、一つ一つの個体をオブジェクトとして扱うといいんじゃないか。クラスによって実装されているインターフェースが異なる。サーバーから与えられるパラメータが個体ごとに違うので、初期状態が異なる。あとはメッセージパッシングでいろいろと。ネームサーバーは別途用意する必要があるかもしれない。DDNSの資産を活かしつつSRV/TXTレコードを勝手に拡張するとか。