1.概要

　従来Windows98へPWSをセットアップし、さらにはPerl for Win32を稼働させ、インターネットサーバーとして運用しておりましたが、セキュリティはもちろん色んな面で不安も少なくなく、UNIX系のサーバーとして生まれ変わることに決定。CGIはそのまま移行出来ると判断しますが、ASPで作り上げて来た資産は廃棄を決定。これまで懸案としてきたProxyサーバーやSambaに挑戦することにしました。

　FreeBSDのバージョンは手持ちの3.3.8を試みようとしますが、NICがどうしても認識できず、結局3.5.1Rでチャレンジ。その経緯については、NICとして挿入したMelcoLGY-PCI/TXLがどのドライバでも動作しなかった事もありますが、そもそも手持ちのバージョンにはドライバが少なかったようでした。このNICはmxドライバで動作することが確認されていますが、3.5Rからは汎用性に富んだドライバが実装されているようで、扱えるNICの種類が増えているようです。

　例によってブートフロッピーの作成から始まります。
http://www.jp.freebsd.org/
ここから辿ると該当バージョンのブートイメージが入手できます。二枚組のFDを作成し、早速インストールに取りかかります。
　前回98ノートで追った手順と同様にベースとなるKernel部分を簡易的に構築できるように、あまり多くのパッケージを選択せずにインストールを進めます。しかし今回はKernelの再構築も目的であるため、ソースは出来るだけ落としておきます。

　FreeBSDが起動出来るようになるところまではスムースに進むはずです。問題はこの後。
　必要と思われるパッケージを選択し、インストールさせます。この段階では、インストーラーの自動処理ですので環境に合った設定に変更が必要な部分も出てきますが、とりあえず選択したパッケージは以下の通り。

　これらの中でも単体で動作するパッケージについては、苦もなく動き出すものは一つもないと言って良いかも知れません。順番に説明していくと膨大な資料になってしまいますが、稼働に成功したものから順に説明して行きます。

２．Apache1.3.12

　 Apacheについては、これまでも何度も設定を経験している事もあって、それ自体が動き出す為の設定は比較的容易であると感じます。問題点と言えばCGIの稼働かと思われますが、とにかく今回もこれまでのApacheと同様な設定を目指します。
　セットアップ後再起動を促してApacheが動き出すケースもあるものと思いますが、とにかくhttpd.confは書き直しが必要なはずです。
　初期段階でLocate.databaseはまだ構築されていないと思われますので、find / -name httpd.confなどでその所在を確認。エディタで開き、各設定情報を正しく書き込みます。
　httpd.confでの注意箇所はLinuxでの設定と同様に、ServerNameの部分、cgiの実行可能設定などに絞られるかと思われますが、Linuxとほぼ同様であるためここでは省きます。
　Linuxでは気にならなかったapachectlを直接さわります。httpd.confの内容についてもチェック出来る(apachectl configtest)ので、これは利用すべきです。詳細は、
http://www.apache.or.jp/
から入手出来るでしょう。
#/usr/local/sbin/apachectl start
でいよいよ動き出します。
http://servername.domain/
で毎度おなじみのサイトが出現します（笑）。次にcgiの確認。
http://servername.domain/cgi-bin/printenv
でapacheに添付される環境変数を確認するスクリプトが動き出します。

　この段階で従来Windows98で稼働していたhtmlやcgiスクリプトなどを移動。順番に動作確認していきます。どうやらコンテンツも大丈夫。
　ちなみにmod_perl-1.24はパッケージを選択すると自動でインストールされます。現在はhttpd起動などは自動。

３．squidへ挑戦

　Linuxでは二枚目のNICの認識に失敗し頓挫していたsquidだが、今度は同じNICを二枚実装しているため期待は大きい。もちろんインストール後に二枚とも認識されていることは確認済み。だが、そもそもDHCPやwinsをルータに頼っている環境であるため、この二枚差しは無意味では？と疑問を持ちながらも設定。まあ、とりあえず一枚で動作させるのもいいか。。。
　Proxyとはご存じとは思うが、LAN内から複数のユーザーが同じWebサイトを閲覧しようとしたときに、キャッシュのデータを有効に利用して、アクセス速度を向上させることが大きな目的である。squidを活用することで外部へのアクセスを最小限に押さえ、インターネットとの接続回線への負荷を減らすことが出来ると言うのは大いに意義のあることです。

　/stand/sysinstallからパッケージを選択した段階で、squid自体は適切な場所へセットアップされている。後は設定だけである。通常は/etc/squid.confあたりになるだろう。squid.conf自体は大きなファイルであるが、設定箇所は多くない。
http_port 8080
　プロクシのポート番号を設定。
ftp_user Squid@duskinhkr.co.jp
　squidがanonymous ftpにアクセスする際に使用するメールアドレス。
acl localnet src 192.168.1.0/24 210.227.170.80/28
　アクセスを許可するLAN側のネットワークアドレスと、インターネット側のネットワークアドレス＆ネットマスク。
http_access allow localnet
　localnetで指定したネットワークからのアクセスを許可する。

　設定はこれだけ。上書き保存し、squidをスタートさせる。
　こちらではこの段階でキャッシュディレクトリのパーミッションが違うと怒られた。。。(^^ゞイヤァ
　即座にパーミッションを変更し再起動するとキャッシュ用のディレクトリへ何やら新たにディレクトリを作成し動き出したことが確認された。

　次にクライアント側の設定。
　Windowsクライアントであれば、Webブラウザの接続設定あたりに「LANの設定」などと言う項目があるはずだ。そこへ「Proxyを使用する」と設定し、squidが稼働しているサーバーのアドレスとポート番号を入れる。こちらの設定では、192.168.1.3とポートは8080である。

　※このところ該当サーバーの8080ポートを検索する行為が増加しています。外部からはアクセス出来ません。何度も繰り返しアクセスしようとするネットワークは、Firewallでそのほかの接続も一切拒否しますのでご注意下さい。

　※The act which searches 8080 ports of an applicable server this place is increasing. It cannot access from the outside. Keep in mind that the network which it is going to access repeatedly also refuses other connection entirely by Firewall.

４．Sambaへの挑戦

　今回のFreeBSDサーバーはHDDを増設している。標準内蔵4.3GBに増設17GBである。何とも大きなHDDではないか。これをネットワークで共有しない手は無い。当初からの目論見でもあったが、Linuxでは設定がうまく行かず失敗していただけに不安も少なくない（って何にしても不安はあるなぁ）。
　とにかく日本語も入れた事で期待はある。smb.confを直接触っても今ひとつピンとこないのでswatに頼る事にした。swatの各情報は
http://www.samba.gr.jp/
から入手。swatはいとも簡単に動き出した。
　ところがsmbdは動き出す物の、nmbdが動かない。これには参った。どこをどう直せば良いのかも分からず二日間は悩む。
　結局logが落ちている事がわかり原因追及出来たのが二日目の深夜。慎重に設定したはずだが、「設定したネットワークが見つからない」と言うエラー内容だった。ヘルプファイルを読んでいくと、ネットワークアドレスが自動認識できる事を確認。早速設定情報のその部分を「自動」にして再起動。やった！見えたぞ。

　Sambaは利用するユーザーがLAN内で一意でないと利用できない。こちらではWindowsNTサーバーでドメインユーザー管理を行っている為、今回Sambaを利用させたいユーザーはFreeBSDでも同じユーザー名でIDを登録しなければならない。特に問題は無いが、利用は限定したいため、同一部門の二名に限定して登録。さて結果は・・・

　思惑通り登録したユーザーからPCが見える。ログインしたユーザーのディレクトリが見えている。これだけでは面白くないので、増設したHDDの一部にSambaの共有ディレクトリを作成し、すべてのユーザーから利用できるように設定。まずはデスクのWindowsクライアントからはファイル転送が実現。こりゃ便利だ。

５．Kernelの再構築

　ここまで進んで起動時のdmesgを確認すると、やたら不要なデバイスを検索している事が気になってくる。これを省くことで起動時の時間の節約やメモリの節約が可能な事は自明の理。では早速Kernelの再構築と行きますか。
　通常は/sys/i386/conf/あたりに存在するGENERICを自分の環境に合わせて書き直す事から始める。直接書き直すのも怖いので、適当な名前をつけてコピーする。
# cp GENERIC MYKERNEL
　次に編集作業となるが、その前にdmesgをプリントアウトしておくと便利だ。どのデバイスがnot foundになっているかなどが確認できる。
# ee MYKERNEL
　変更箇所は以外と多いのだが、とにかくdmesgでnot foundとなっているデバイス類の部分をコメントアウト。またNIC部分は装備していないものすべてコメントアウト。不明な物は極力触らないようにする。
　書込後、
#config MYKERNEL
　でソースツリーを作成させる。ミスが無ければbuildされたディレクトリの情報が出てくる。こちらの場合は、
../../compile/MYKERNEL
と出てきた。早速移動する。
#cd ../../compile/MYKERNEL
　ではコンパイル開始。
#make depend; make
　これはかなり時間のかかる作業である。エラーがあれば当然やり直しだが、警告が出るのもいささか気になる。まあコンパイル自体は成功するようだが。
loading kernel
rearranging symbols
・・・・・・・
成功したようだ。では
#make install
#shutdown -r now
で再起動すれば完了。もし再起動に失敗するようであれば、もともとのkernelはkernel.oldとしてバックアップされているので、Boot:の段階で手動で切り替えて立ち上げた後にやり直す。例えば、
Boot:wd1:kernel.old
#chflags noschg /kernel
#mv /kernel /kernel.new
#cp -p /kernel.old /kernel
#chflags schg /kernel
これで元に戻るので、もう一度再構築に挑戦しよう。 　

スタートページへ

2002/08/05 : Proxy警告文書追加