山田邦博です。

DLC (DiskLess Client) Versin 0.0 の投稿です。

-...-

  初心者を対象としたユニックス教育(Unix education)を目的としています。
特に、初心者にルート(root)権限を安全に与えます。
いわゆる diskless client をベースとしていますが、nfs-root ではありませ
ん。 RAMDISK 上に独自のルートファイルを構築します。

 クライアントマシンのハードディスクを一切使用しないため、Windows マシ
ンをそのまま Linux マシンに変身させることができます。 ずらりと Windows
マシンが並んだ教室をそっくり Linux 教室に化けさせる事が可能となります。

詳細は後の README.jp.txt と INSTALL.jp.txt を参照して下さい。

-...-

DLC (DiskLess Client) Versin 0.0 の全てのファイルは

        ftp://ftp.tksa.gr.jp/king/school/dlc_0.0.tgz

にあります。
最新の DLC については

       http://www.tksa.gr.jp/king/Software/DLC/index.html

を参照して下さい。


=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
README.jp.txt
-------------

                     DLC - DiskLess Client

                            山田邦博
                YAMADA Kunihiro <king@tksa.gr.jp>
                    12 Sep.2004 (Release 0.0)
                 Copyright policy: GNU GPL Ver.2


<Copyright>

本パッケージの作者は 山田邦博 YAMADA Kunihiro <king@tksa.gr.jp> です。
Copyright は GNU GPL, Version 2 に従います。
よって、配布、改編は自由です。 当然の事ながら無保証です。
詳細は別ファイル GPL-2 を参照して下さい。


＜背景＞

皆さんは Unix 教育をどういう風にやっているのでしょうか? 単なる一ユーザ
として一般的なアプリケーションを教えるだけなら Unix マシーン(ホスト)の
用意は簡単です。 でも、このレベルでは Windows 下でアプリケーションを教
えるのとあまり変わりがありません。 Cygwin を使えば Windows 下で Unix 
もどきのユーザインターフェイスが得られるので、Unix マシーンは必須では
ないかも知れません。 私に言わせれば、このレベルでの教育ではたとえ Unix 
マシーンに触れさせたと言っても特に Unix の教育をしたことにはならないだ
ろうと思っています。

今時の子供達は幼い頃からコンピュータに慣れ親しみ、コンピュータをある意
味で使いこなしています。 この中には Linux や FreeBSD のような PC Unix
上のアプリケーションを扱っている子供達も大勢いるはすです。 ですが、彼
らの殆んどはコンピュータの内部構造や、OS には全くと言って良い程興味が
無く、理解もありません。 この原因の一つに相応しい指導者がいないという
のもありますが。
多くの、いや殆どのコンピュータユーザは、ゲーム、メイル、ウェブ、お絵書
き、あるいはチャットで、一部の人は特定のアプリケーションだけで十分でしょ
う。 当然、これらの殆どは Unix 上で同様の事ができます。 しかし、これら
は Unix を扱っているというよりは、アプリケーションを扱っていると言うべ
きでしょう。
ちなみに、私の娘は 3歳の誕生日の頃には Linux 上のアプリケーションを使
い始めていました。 しかし、これらは Windows でも同等の事ができます。
小学生になった現在でも状況は同様です。 この間、Unix 教育はしていません。
たとえ Linux を使っていても Unix 教育にはなっていないという実例です。

さて、もう一歩進んで Unix の内部に踏み込もうとしたり、Unix システムを
勉強しようとしたり、あるいはカーネルやネットワークの内部構造に立ち入り
たいとすると、途端にルート権限が必要になって来ます。 ここまで行かなくて
も Unix の管理をしようとすると /etc の書き換えは必須です。 いや、/etc
の書き換えを行なわずしては勉強になりません。
Unix 教育とはルート権限が必要になるようなレベルの事だと言っても良いでしょ
う。

Unix の教育を行なおうとする時、ユーザにルート権限をどう与えるかが結構
問題になります。 Unix の場合、ルート権限はそのホストを管理する人にのみ
与えられるべきです。 さもないと、Unix ホストの管理は破綻します。 つま
り、一般ユーザにはルート権限を与える訳にはいかないのです。 逆に Unix 
ホストのユーザと管理者が同じ、つまりマイコン(my computer)は理想となり
ます。

ほんの二三人に教えるだけならユーザ専用のホストを用意するのは簡単でしょ
う。たとえ初心者にシステムを壊されても、再インストールすれば済むので人
数が極少ないうちは何とかなるでしょう。 しかし、そのうち人数が増えたら
多分どうにもならなくなるでしょう。(それらホストのお世話係が泣きそうに
なっている姿が目に浮かびます。)

各ユーザ自前のパソコンに Unix をインストールしてもらうのが理想です。 
これなら、ユーザと管理者が一致していて、当然各自が各自のホストにルート
権限を持つ事になります。しかし、Unix 教育の前にインストール教育が必要
になります。 そのインストールをきちんとするためにはその前に Unix の知
識と経験が欲しい。 .....  結構厄介ですね。
Unix 教育の問題点の一つにはルート権限をどう与えるかという最初の一歩に
あるのではないでしょうか?


＜Unix 教育環境＞

単にユーザに Unix マシンを割り当てるだけでなく、ルート権限を含めて与え
なければならない。 この時、マシンの管理が容易でなければならず、まだ素
人であるユーザが少々の誤った操作をしてもシステムの復旧が容易でなければ
ならない。 さらに、このシステム復旧に通常はシステム管理者の手を煩わせ
ないことも必要である。
これだけの条件が満たされるならば、ビギナーのための Unix 教育環境として
理想的でしょう。


＜如何にして一般ユーザにルート権限を与えるか＞

最終的には各ユーザは各自のホストにインストールされた Unix を使うべきで
す。しかし、それまでの教育途上では、ユーザが何をしてもシステムが壊れな
い物が理想です。

ユーザが何をしても壊れないシステムは、ハードディスクへの書き込みが一切
できなければ実現できます。 
NFS mount という方法でそのホスト自身のハードディスクに一切触れない方法
がありますが、/ や /var も NFS mount とすると、サーバ側のハードディス
クのどこかを書き換える事になります。 各ホスト毎にその領域が異なるので、
それらの領域のどれかが壊れても復旧は容易でしょう。 ですが、これでもそ
のサーバの管理者は嫌がるでしょうね。

これに対する解としては、/ や /var の内、書き換えの起こる部分を ram
disk に置き(必要ならサーバからコピーする)、その他の書き換えの起こらな
い部分を全てサーバから NFS mount(read only)で使用する。 サーバは read
only で export すれば良いから、サーバは傷付く事がない。 システムはブー
ト後常に同じ状況になる。 つまり、ブートする度に元に戻っている。 このよ
うなシステムであればユーザにルート権限を与えても支障は起こらない。
これだけでは、ユーザが居ない、あるいはユーザが居てもそのデータ(ホーム)
がないという事になるので、ユーザのホームに関してだけは read/write 可で
サーバから NFS mount することになる。 この場合、ホームが壊れることを防
げないが、その場合でもシステム自体は無傷である。 ホームの防御ないし再
構築に関しては後述する。

これには、FD からブートし、ram disk image を同一の FD 中に入れておくと
いう通常の方法が使えます。 これは以前のバージョン BRFD (Ver.1.0)
<http://ftp.tksa.gr.jp/king/school/brfd_1.0.tgz> でやりました。
(CD-rom からブートという手もありますが。)
Etherboot や PXE を使用すると kernel と ram disk image をネットワークか
らブートできます。 DLC はネットワーク ブートです。


<DLC: DiskLess Client>

要はディスクレス・クライアントです。 ですが、いわゆる nfs-root ではあり
ません。
私の作り上げた Diskless Client system は tftp からネットワークブートし
ます。 FD には(通常) Etherboot というネットワーク ブート ローダが入っ
ています。ブート後、サーバから必要なファイルを ram disk 上の root file
にコピーし、その他のファイルはサーバへ read only で NFS mount します。
私の工夫は FD 中にユーザ ID と暗号キー(passkey) を入れた事です。
各ユーザのシステムは FD によって区別されます。 各ユーザ用に用意された
passwd file を含むファイルは passkey を使って復号され使用されます。 ユー
ザ毎にホスト設定が可能なようになっています。


＜動作環境＞

AT 互換機(i386 architecture) 上でしか動きません。

Debian GNU/Linux 3.1 (Sarge)
Etherboot (5.2.4-2)
udhcpc (0.9.8cvs200407)
gnupg (1.2.4-4)
qmail (1.03-31)
等々。

Server 上には
       dhcp
       dns : dhcp で割り当てたアドレスの逆引きができること。
       tftp
       NFS
等が最低限必要ですが、前者二つは windows 用等で既に用意されていればそ
れを使えます。

メモリー(RAM)は少なくとも 128MB 位は必要でしょう(特にクライアント)。


<Install>

$ cd $HOME/yourworkdir                  # $HOME = /your/home
$ tar zxf dlc_(version).tgz
$ su
# mkdir /client
# ln -s /your/home/yourworkdir/dlc_(version) /client/dlc

ディレクトリ $HOME/yourworkdir 以下に展開されます。  DLC はデフォールト
では /client/dlc に(等価的に)展開されていることを期待しているので、上記
のように symlink を張っておくのが良いでしょう。

同文書の説明では、各ファイルは /client/dlc を起点としてありま
す。

設定ファイルに関しては doc/CONFIG.txt を参照して下さい。
詳細は bin/configure.sh, etc/rc/{rcS.ramnfs,ramnfs,ramnfs.2} を解読して
下さい。 Boot 後の init と rc files の動作を理解できている人であれば解読
は簡単でしょう。

最低限の設定は、etc/dlc.conf をあなたのサイトに合わせて書き換える事、
etc/students.reg にユーザを設定する事、etc/hardware.conf に client PC の
ハードウェア状況を設定する事です。 後は、
        # bin/mkaccount.sh
        # bin/setup-students.pl
        # bin/configure.sh -a
で終りです。

dhcp, tftp, nfsd(export) 等の設定に関してはここでは触れません。
また、FD から boot したい人は Etherboot を入れる必要がありますが、それも
ここでは触れません。 doc/INSTALL.txt を参照して下さい。


＜ホームの防御と再構築に関して＞

NFS を使用している以上、書き込み可能で export されたファイルシステムは
そのネットワーク上の誰でも破壊可能であると言わざるを得ません。 Root
squash を指定しても、意図的な破壊には無力で、せいぜい不注意による破壊
が予防できる位と考えて下さい。 どうすれば他人のファイルを破壊できるか
は自分で考えてみて下さい。 残念ながら現在の NFS はそんなレベルの代物で
す。

NFS サーバ上の通常のユーザアカウントは本 DLC のユーザアカウントとして
使用すべきでない。 また、DLC のユーザのホームは /client/home/ 以下と
すべきです。 さらに、重要なファイルは置かない事。 これで、通常の
/home/ 以下のユーザのホームは DLC ユーザの故意、過失による破壊から逃
れられます。
重要なファイルは別のマシン等に ssh (scp) 等でアクセスして使用しましょ
う。

NFS サーバ上の通常のユーザ(userid)が DLC ユーザとなることができますが、
DLC ユーザとなった時のホームは /client/home/userid となります。 サーバ上
の /home 以下を export しないようにしましょう。

/client/home/ 以下のバックアップコピーを毎日定期的に取っておきましょう。
私が作った Autobackup を使えばこれが簡単にできます。 さらに、read only
の mirror を用意できます。
前日の状況にならユーザ自身でも簡単に復帰、再構築ができます。
実際の使用では、自分のファイルをうっかり消したり、上書きしたりといった
トラブルが殆どでしょう。 その対策にも Autobackup がお勧めです。

上記のような再構築ができない場合の最後の手段として、簡単なホームの所期化
の方法があります。
        # rm -rf /client/home/userid
        # bin/configure.sh -h
ある DLC ユーザのホームが無いと、そのホームを作ります。

あるいは、DLC ユーザ自身に再構築を試みさせるのも(勉強になって)良いでしょ
う。 そのため、ホームの雛型が /client/home/com にあります。 DLC ユーザに
は /home/com に雛型が見えます。


＜Passwd に関して＞

各 DLC 上のユーザとルートの passwd は同一です。
        Note: 初心者ユーザのパスワード管理は信用できません。
              それゆえ、いい加減なユーザがいても管理者が困らないように
              考えてあります。

サーバ上に DLC のユーザアカウントを作る必要がありますが、サーバに
login できないようにすべきです。 bin/mkaccount.sh を使って DLC ユーザ
アカウントを作るとそうなっています。
bin/mkaccount.sh はまた config/account ファイルを作ります。 この
account ファイルの 2番目の項目が Diskless Client の passwd となります。
DLC ユーザが新規に作られた時、この passwd は config/students.reg 中の
最初の項目(Student Number) となります。 従って、その Student Number は
他の学生等に良く知られていると考えられるので、その DLC ユーザに対する
security は殆どありません。 例えば、この Diskless Client を使用中に勝
手に login されるかも知れません(しかも root で)。 ですが、たとえ crash
させられてもすぐに復帰できるので、これで良いとしています。
(Version 1 でこの方法を変更することを考えています。)
もし、これで不都合なら次のような方法が使えます。

account ファイルの passwd (2番目の項目)の文字列の最初を "-" にすると
passwd を plain-text で書けます。 管理者が面倒でなければ、個々に書き込み、
ユーザに通知して使用させれば良いでしょう。

また、DLC ユーザがサーバに login できる時、account ファイルの passwd
(2番目の項目)を "x" にすると、/etc/passwd または /etc/shadow に書かれた
passwd を使用します。 DLC 専用のサーバを確保でき、DLC ユーザの行動を信頼
できるならこの方法を使っても良いでしょう。

あるいは、ユーザ教育の一環で passwd の構成を良く教え、mkpasswd で新しい
passwd を作らせ、あるいは passwd コマンドで変更された passwd 部分を調べ
させ、それを(gnupg を使った暗号)メイルで DLC 管理者に知らせる ... などと
いうのが考えられます。(管理者は単純に account ファイルを書き換えるのみ。)
(Version 1 で、変更された passwd(shadow) ファイルからサーバ側の
account ファイルの passwd を変更するコマンドの実装を考えています。)


＜ブート フロッピーとキー フロッピーに関して＞

PXE を使用する人はブート フロッピーの必要はありません。
PXE が使用できない時は(あるいは Bios の設定が面倒な人は) Etherboot を使
用して下さい。 /usr/share/etherboot/ あるいは rom-o-matic.net から 対応
する NIC driver の ROM イメージ(*.zdsk)を取って来て、
        # cat yournic.zdsk > /dev/fd0
と書き込めば終りです。

なお、dhcp の設定が windows 用の環境のまま使用しなければならない所では、
tftp 上の kernel image の設定ができないでしょう。 この場合 Etherboot の
make の際に、-DDEFAULT_BOOTFILE="tftp:///kernel.dlc" のような boot
file の場所を指示しておく必要があります。

このままでは、フロッピーに userid と passkey が入っていません。 この状態
でブートすると、userid と passphrase を要求して来ます。 Passkey が正常に
探せたら、userid と passkey をそのフロッピーに書き込みます(問い合わせが
あります)。 以後、そのフロッピーはブート用とキーフロッピーを兼ねます。
PXE を使っている人も、同様にしてキーフロッピーが作られます。


＜ template/ ディレクトリについて＞

template/ 以下は基本的に ramdisk image の雛型です。

実際に client(生徒、学生)に何を教えるかで、ここの内容が決って来るはずで
す。 DLC の管理者であるあなたがその内容を知っていなければなりません。


普通の diskless と違って、 /bin, /sbin, /lib, /etc および /var を直接
nfs mount しません。 それらはそれぞれ、 /.bin, /.sbin, /.lib, /.etc およ
び /.var に nfs mount されます。 大部分は /{bin,sbin,lib,etc,var} から
/.{bin,sbin,lib,etc,var} へ symlink が張られますが(.linklater)、必要に応
じて、事前に(.include)あるいは事後に(.copylater)、ramdisk の
/{bin,sbin,lib,etc,var} に実体がコピーされます。 これによって、nfs
mount が全て umount されても独立して動けるようになります。


-- dir to be exported --

template/etc/ および template/var/ 以下にある .export ファイルで、サーバ
側が用意すべきファイル・ディレクトリを記述します。 この etc と var は
dlc client 専用としてサーバ上の /client/etc および /client/var に作られ
ます。
.export ファイルは template/{etc,var}/ および、それ以下の任意のサブディ
レクトリに置く事ができ、サーバの対応するディレクトリから作られます。

.remove ファイルが template/etc/ または template/var/ 以下にあると、
.remove ファイルで指定されたファイルまたはサブディレクトリを対応する
直前に .export ファイルによって作られた /client/etc または /client/var
から消去します。


-- ramdisk --

.include ファイルが template/ およびそれ以下の任意のサブディレクトリにあ
ると、.include ファイルで指定したファイルまたはサブディレクトリ ツリーを
サーバの対応するファイルまたはサブディレクトリから ramdisk image にコピー
します。

.linklater ファイルおよび .copylater ファイルは、dlc client が起動した時、
スクリプト ramnfs によって参照されます。
template/ 以下の bin, sbin, lib, etc および var ディレクトリは、起動した
client のルートファイル(ramdisk)を指します。 サーバは、これらに対応する
ディレクトリを nfs mount のために export します。(client は /.bin,
/.sbin, /.lib, /.etc および /.var に mount する。)

.linklater ファイルが存在すると(ファイル内容は無関係)、nfs mount された
対応するディレクトリ上のファイル・ディレクトリへ、ramdisk の
.linklater ファイルがあったディレクトリ上に symlink が張られます。 ただ
し、既に、ramdisk のそのディレクトイ上に既にファイル、ディレクトリ、リン
クが存在すると無視されます。

.copylater ファイルが存在すると、そこで指定されたファイル・ディレクトリ
をまず、ramdisk から消去し、次に nfs mount された対応するディレクトリ上
のファイル・ディレクトリを ramdisk 上にコピーします。


＜キーフロッピーを紛失したら＞

DLC では通常のパスワードよりもキーフロッピーの方を重視しています。
(ビギナーのパスワード管理を信用していない。)
キーフロッピーを紛失したユーザ(userid)の passkey を変更することで、その
キーフロッピーは無効となります。 そのためには；
        1. $ edit etc/account
                userid の passkey の項を書き換える。
                あるいは；
                        1.1. userid の行を消す。
                        1.2. $su
                        1.3. # mkaccount.sh     # 新しい乱数が書き込まれる
                とやっても良い。
        2. $ su
        3. # bin/configure.sh -s
とします。

キーフロッピーがコピーされた可能性がある時も同様の処置をお勧めします。


=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
# INSTALL.jp.txt
#

# Author: YAMADA Kunihiro <king@tksa.gr.jp>
# Copyright Policy: GNU GPL Ver.2

# History:
#         (Please see other document "change.log" for detail.)
#   14 Aug.2002   brfd ver.1.0 : released
#                   (Boot and Root from single Floppy Disk)
#   28 May 2004   started DLC (DiskLess Client)
#                 name changed from brfd to dlc because PXE boot is supported
#   12 Sep.2004   DLC ver.0.0 : released
#


＜インストール場所＞

/client/dlc/ 以下を想定しています。 これ以外の場所を使うなら、適当に
script と config file(etc/dlc.conf) を書換えるか、symlink を張って下さい。



DLBASE=/client/dlc を起点として、以下で説明します。

$ cd /home/you/your/workdir
$ tar zxf some/path/dlc_(version).tgz

# ln -s /home/you/your/workdir/dlc_(version) /client/dlc
# cd /client/dlc
# ....


＜設定ファイル＞

etc/dlc.conf : 各サイトの事情に合わせて下さい。 全体の概略設定をします。

etc/hardware.conf : 各 client マシンについて記述します。

etc/students.reg : 各 ユーザ(スチューデント)について記述します。

        上記 3個の設定ファイルは必須です。
        下記の設定ファイルはあるコマンドで作成ないし、修正されます。

etc/account : これは bin/mkaccount.sh コマンドで(etc/students.reg)から作
              成されます。 このコマンドで作成後ならば、既にあるエントリ
              を修正、削除の編集をして構いません。

etc/students.conf : これは bin/setup-students.pl コマンドにより
                    (etc/students.reg)作成、ないし、修正されます。 この
                    コマンドで修正した後なら、既にあるエントリを編集して
                    構いません。

        dlc.conf を除き、上記設定ファイルに関しては doc/CONFIG.txt を参
        照して下さい。


＜カーネル＞

Server 上で Diskless clients 用の kernel を install する必要があります。
Make する時の設定は doc/config-2.4.22 を参照して下さい。
        不特定多数の dlc ユーザ(Diskless client users) を対象とする時
        は、HDD(ハードディスク)関係のドライバを外しておくと良いでしょ
        う。 これで、システムクラッシュの際も、HDD は無事です。
        逆に信頼できるユーザだけならば、HDD 関連のドライバを module と
        しておけば、この dlc はメンテナンス用(レスキュー用)として重宝
        します。
Server 上で、この kernel を boot することはありませんが、Diskless
clients に modules を export するために必要です。 また、script が
/boot/ に kernel image がある事を前提としています。
従って、Server 上の現用の kernel とは version が異ならなければいけませ
ん。

Server 上の lilo.conf からこの kernel を起動しないようにしてください。


＜DHCPサーバ＞

DHCP サーバが必要です。 何が設定されている必要があるかは
etc/rc/udhcpc.bound を参照すれば分かると思います。
Windows 向けに設定された DHCP サーバではいくつかの設定が不足、あるいは
不都合が起こるかも知れません。 その時は、etc/dlc.conf に追加的に書く事が
できます。 etc/dlc.conf の設定が優先されます。
現在追加できる設定は SERVERID, NTPSRV, DNS です。

特に、dhcp の設定が windows 用の環境のまま使用しなければならない所では、
tftp 上の boot file の設定ができないでしょう。 この場合 Etherboot の
make の際に、-DDEFAULT_BOOTFILE="tftp:///kernel.dlc" のような boot
file の場所を指示しておく必要があります。(試していません)
この boot file の設定だけは、etc/dlc.conf ではできないので、DHCP サー
バで行うか、ブートフロッピーに書き込む Etherboot(の make option)で対処
して下さい。

        Note: DHCP3 サーバを使用すると、PXE ブートまで設定できます。


＜DNSサーバ＞

DHCPサーバによってリースされた IP を逆引きできる必要があります。


＜theサーバ＞

SERVERID のサーバです。 Diskless clients がブートする時のカーネルイメー
ジとルートイメージを tftp で提供します。 また、Diskless clients が必要と
するファイルを NFS で提供します。 NFSSERVER で指定される nfs server と同
一としていますが、異なる server とする事もできます。 この場合、DLC のシ
ステムの入っているサーバから別のサーバへ何らかのファイルを転送しなければ
ならないので、ちょっと厄介でしょう。
何を export すべきかは doc/exports.example を参照して下さい。