教育用の中規模LAN環境の運用について

ハードウエア環境

ハードウエア構成を表1に示します。 この当時、仕様策定にわたしはかかわらなかったのですが、 3ボタンマウスやLANカード等、 FreeBSDのためにあるような機種になっていたのが嬉しかったです。

導入したメーカが協力的だったため、 ディスクを2パーティションに分割し、 半分を何も入れないままで提供して頂きました。 おかげで、FreeBSDの導入は比較的楽に行えました。 ちなみに、大学などでの大規模教育用システムでは、 最低限のインストールを済ませた状態で納入されることもあるようです。

サーバはクライアントと同じ機種で、 64Mbyteメモリーで2.5GbyteHDD×2(IDE)、LANカード2枚で構成しました。

ネットワーク構成

当時のシステム配置図を図1に示します。 各コンピュータは、島状に配置されており、 各島にプリンタが用意されています。 島ごとにHub(導入当時は10baseTのDumb Hub)が設置されており、 各島からスイッチに接続されるネットワーク構成となっています。

ユーザのホームディレクトリはNFSサーバからの提供です。 ユーザのホームディレクトリは2台のハードディスクで分散しました。 授業では、学籍番号が連続した学生が利用しますので、 偶数番号と奇数番号でホームディレクトリを振り分けています。 この構成で、問題が起こったのはNetscapeを 演習で一斉に立ち上げた時で、キャッシュディレクトリが一斉に作成されたため、 輻輳が発生しネットワークが利用できない状態になったことでした。 これは、キャッシュディレクトリをあらかじめ作成しておくことで解決しました。

演習室内は、サーバによるfirewall経由でのアクセスとなっており、 プライベートアドレスで構築しています。 これは、純粋に「やってみたかった」という部分と、 クライアントへのcrackを可能な限り防止したかったことがあります。 当初はNATは利用せず、アプリケーションゲートウエイでのアクセスで 利用する形式としました。 サーバリプレイス時にNATを利用した設計に変更しました。 HTTPだけは、授業で同じページを見にいくことが多いため、 Squidを使ってキャッシュしています。

ソフトウエア環境

クライアントは基本的にリリースベースにしてあります。 最新のものをmake worldで利用し続けるという方針も 考えられますが、教育用システムでは利用できない状態があることは 非常に問題であるため、 どうしてもリリースを利用せざるを得ません。 これは、管理の起点をどこからはじめるかが統一されていて欲しいだけなので、 snapshotを適切に残せるのであれば、どの時点でも構わないわけです。 しかし、やはりあちこちで手軽に手に入るsnapshotとしては、 どうしてもリリースになってしまいます。

ソフトウエアは一般に使われているものを中心に導入しました (表2)。 マシンが非力なため，統合環境はおろか ウインドウマネージャですら軽いfvwm1を選んでいます。 同じ理由から，Mozillaは使えず，いまだにNetscapeを利用しています。

コンピュータのshutdownですが、当初はshutdownアカウントを作成することで 対応していました。 学生用クライアントはxdm経由でのログインになっています。 gdmやkdmでは、 ログインメニューからshutdownできるようになっていますが、 xdmではできないため、 shutdownボタンを作成しています。 これらの方法については[FreeBSD-users-jp 35974]に解説されています。

Windows95とのデュアルブート環境であることは既に述べましたが， 低学年ではこちらを利用することが多いため， デフォルトのブートOSをWindowsにしたいという要望がありました。 標準のBootMgrでは、前回起動したOSが立ち上がってしまうため、 問題があります。 そこで、OS-BSを使っています。

当初はインストールを個別にやっていたので、 各クライアントにアプリケーションを インストールすることは非現実的でした。 そこで、NFSサーバのアプリケーションを利用していました。 10baseTのネットワーク環境でも、特に帯域等に問題なく利用可能でした。 具体的には、/usr/local/および /usr/X11R6/を全て共有していました。 このときの工夫としては、 /usr/local/etc/rc.d/や /usr/X11R6/etc/rc.d/も共有されてしまうため、 ホスト名をみて、サーバだけで立ち上がる必要があるソフトウエアだけは きちんとコントロールするということぐらいです。

システム更新(平成12年3月)

平成11年度補正予算で、サーバがPentiumII 400MHz×2(SMP), Memory 256M,HDD 4GB(SCSI)×2に更新されました。 これまで、クライアントとほとんど変わらない性能で運用していた無謀な状況が 少しは改善された形です。 さらに、Hubが100baseTXに更新されたことにより、 LAN内でのネットワーク帯域は広くなりました。 また、この時スイッチングHubも導入されましたが、 基本的にサーバに繋ぎにいくトラフィックが主なため、 あまり効果が無かったのじゃないかなと思っています。 いま思えば、サーバに複数のネットワークカードを差す形式に するべきだったでしょう。

この時期と全後して、管理者が私一人からもう一人追加されました。 この時点でCVSを利用していればトラブルも少なかったのだろうなと思うのですが、 この点はまだ現在も改善していません。 複数での管理では是非CVSを利用すべきでしょう。 参考文献としては、[4]が比較的まとまっています。

patchシステム

一般にリリースを導入したそのままの状態で使えるわけはありませんので、 システム設定等の更新は必須です。 このためには、大阪大学の斎藤先生考案の patchシステム[1] を利用して、更新しています。 このシステムは、基本的にシェルスクリプトを次々に実行していき、 成功した場合、/etc/patchnoなどの適当なファイルに 現在までに当たっているパッチの番号を登録しておくという方法です。 更に斎藤先生のシステムでは、 ほぼ常時運用環境でも利用可能なように、 定期的に更新を行うなどの仕組みも用意されています。

FreeBSDの場合、幸いにも/usr/local/etc/rc.d/を 起動時に自動実行する仕組みがありますので、 ここに、patch.shなどという名前で、 適当なディレクトリのスクリプトを自動実行していくスクリプトを 入れておきます(図2)。 これをサーバからコピーした後でリブートすると、 必要なパッケージの導入や適切な設定をおこなってくれます。 しかし、現在のクライアントに必要な全てのパッケージの導入には1時間30分ほど かかってしまいます。

#!/bin/sh
nofile='/etc/patch.no';
case "$1" in
start)
    # サーバの場合には実行しない
    if [ ! X`hostname` = X"herb" ] ;then
        if [ ! -f $nofile ] ;then
            patch=0
        else
            patch=`cat ${nofile}`
        fi
        patchfile="/usr/local/etc/patch/${patch}.sh"
        while [ -f ${patchfile} ] 
        do
            echo -n "Apply Patch ${patchfile}..."
            ${patchfile}
#           本来は終了コードをチェックすべき
            echo "Done."
            patch=`expr ${patch} + 1` 
            patchfile="/usr/local/etc/patch/${patch}.sh"
        done 
        echo ${patch} > ${nofile}
    fi
    ;;
stop)
    ;;
*)
    echo Usage `basename $0` {start|stop} >&2
    exit 1
    ;;

システムのインストール

最初はなにしろ、何も知らない状態だったので、とりあえずインストールは CD-ROMを持ち歩いて、インストールしていました。 かなりの時間をこの作業で取られていた覚えがあります。 この当時のFreeBSDは2.1.7Rでした。 クライアントはCD-ROMブートができないので、 フロッピーが必須だったのが大変困りました。 最終的にはほとんどネットワーク経由でのインストールを行うことになりました。 これは、CD-ROMドライブの速度が遅いことの他に、 どうせネットワークの設定を行うなら最初からやっておいた方が楽なためです。

patchシステムを導入してからは、 IPアドレスやホスト名などのネットワークの設定さえしてしまえば、 あとはpatch.shをコピーしてリブートするだけで 基本的な設定から必要なパッケージの導入まで終るようになりました。 更に、MACアドレスベースのDHCPサーバを使えば、 ネットワークの設定も必要無くなります。

これからどういう方針でインストールしようかというのを少し考えてみます。 やはり、学生から自宅でも同じ環境で演習などを行いたいという要望があります。 長期休みなどにインストール実習を希望者に対して行っているのですが、 自分でインストールできる自信をつけれる学生はあまりいません。 そういう意味で カスタマイズしたインストールCDを作成することは意味があると思います。 例えば、 木本さんの記事で紹介されているPOPS などのように、実際に授業で使っている環境だけに限ったものを作成すれば、 インストールの時だけでなく学生への配布にも使えるでしょう。 うまくインストール自動化スクリプトinstall.cfg [2] を作ってあげれば、 学生の負担も減らせるかも知れません。

ネットワークカードを選びますが、 PXEBOOTによるネットワークブートが利用可能な環境では、 これとinstall.cfgを 組み合わせることでインストールを自動化することも可能です [3]。

普段の運用/管理

年度毎に必ず生じる作業がユーザ登録です。 基本的にUIDは学籍番号を利用しています。 留年や退学などで学生の入れ替わりが生じますので、 名前の先頭に出席番号を付加することで、 メーラの整列機能を利用して、提出物の確認がしやすいようにしています。 ユーザはNISに登録していますが、この時に [FreeBSD-users-jp 4972]で紹介された adduserへのpatch相当の物を当てて利用しています。

学生用の設定ファイルの中でも一部は、設定変更に伴って変える必要があります。 しかし、学生が配布後に変更をしている場合がありますので、 単純に置き換えるという方法は取れません。 グローバルな設定ファイルだけで、ユーザには可能な限り配らないという方針 もあるのですが、 設定ファイルを自由に書き換えてカスタマイズする喜びが無くなるのも 悲しいので、 学生用設定ファイルから変更が行われだろう部分をincludeするという 方法を取っています。 具体的には.emacsなどでは

	  (load "/usr/local/share/skel/dot.emacs")
	

	  include(/usr/local/share/skel/dot.fvwmrc)
	

	  source /usr/local/share/skel/dot.cshrc
	

クライアントのpackageの追加や設定変更は全てpatchシステムを使っています。 作業履歴も残るため、誤った設定が分かりやすいというメリットがあります。 もちろん、テストマシンで作業テストを行った上で、 実際に利用しています。

利点

利点としては以下のようなものがあげられるでしょう。

• 多くのソフトウエアがフリーで利用可能なため、 維持経費を非常に安く押えることができる。 また、これらのソフトウエアはports/packagesを使えば、 簡単に導入が可能です。 すぐに使える教材もかなりの数入っています。

  また、最近ではOffice Suiteも充実してきているため、 特にWindowsと比べても遜色がありません [1]。

• 古いコンピュータでも、 工夫しだいで使えるようなシステムが構築可能です。 これは、リプレイスの見通しがたたない所では大きな利点となります。

• とりあえず、ソースがあるので自分で頑張ればなんとかなります。 もちろん、時間と能力は要求されますが…

問題点

私が考える問題点は以下の通りです。

• 学校等では、定期休み以外にOSのリプレイスをするのはほとんど無理です。 しかし、最近のリリースは休み空け直後に出るので、 悲しかったりします。

• 活発に開発が行われているのは歓迎すべきことなのですが、 1年後にはほとんどサポートが打ち切られる現状は、 少し困ってしまいます。 したがって、年に2度程度(春休みと夏休み)は アップグレードする必要があります。 特に、portsが使えなくなるのが一番の問題です。