最初、仕事場のPC(Win98)で焼いてみたのだが、どうもISOファイルは焼けないみたいで、読み込みに失敗してしまうのだった。そんなソフトもあるのね。
まあ、旧くてCD-Rを読めないドライヴもあるからなぁ。DECサーバのもこの手の旧いヤツで、なんで読めないのか一時途方に暮れたのであった・・最終的にフロッピで起動させて、ネットワーク インストール したのである。
インストーラには「Upgrade」というメニューもあるが、これを選択すると、凄味のある脅し文句が出てくる。気が弱いので、今回も設定ファイル/データをすべてバックアップし、クリーンインストール。
OS自体のインストールは、あっという間に終わってしまうわけだが、なにしろ現用サーバなものだから、各サービスを復旧させるには、それなりの時間がどうしてもかかってしまう。
データがたくさんあったりすると tar czpf foo.tar.gz ./foo/ とかで固めてftpで隣のサーバにバックアップ。最近は100BASE-TXだから70Mbpsくらいで転送できちゃうので、とっても幸せである。
さて、仕事場のDECサーバ(Pentium100MHz)では、こんなふうにディスクを切ってみた。
| da0s1a | / | 900MB |
| da0s1b | <SWAP> | 127MB |
| da1s1e | /usr/local | 1027MB |
シンプルである。/usr/local/ は cronで丸ごとDATにバックアップするようにしている。
それはさておき、kernelの make depend all install にかかった時間は約55分であった。4.3-RELEASEのときとほとんど変わらない。これで、ApacheやSambaを動かしているが、ユーザの少ないローカルサーバなので、ほとんど負荷を感じることはない。
最初は失敗したが、インクルードファイルの置き場所見直し、gmake の使用などでようやくコンパイル完了。httpd.confに mod_encoding のLoad設定を書いてApacheをrestart・・けど、なんとこれが再起動せえへんのよ。
# /usr/local/apache2/bin/apachectl restart
Syntax error on line 218 of /usr/local/apache2/conf/httpd.conf:
Cannot load /usr/local/apache2/modules/mod_encoding.so into server: /usr/local/apache2/lib/libiconv_hook.so.1: Undefined symbol "iconv_open"
ええっ!? Syntax error・・なんか、N88BASICを思い出してしまったぞ。
しばらく悩んだが、結局 mod_encoding.so か libiconv_hook.so が 「iconv_open なんて知らないよ」と言ってるわけで、Makefile に LIBS = -L/usr/local/lib -liconv を追加して再度makeすることでなんとかmod_encodingをLoadしてくれた。
Linuxではこういうのは不要みたいなのだが、FreeBSDでは必要になる(もともとFreeBSDにはiconvが標準では入ってないため?)ようだ。
さあ、これでXPでの認証も日本語ファイル名もバリバリOKだ・・と、思ったら、そうは問屋が卸してくれないわけで、結局どちらもNGなのよ。
まず、ベイシック(BASIC)認証にしておいて、Win95から日本語名ファイルをコピー。これは成功。日本語名フォルダの作成も成功。しかし、XPからは、あいかわらずアクセス不能。DAV Explorerからはアクセスできるが、日本語ファイル名の表示はできるものの、そのファイルをイジることができない。
ダイジェスト(DIGEST)認証にすると、Win95からはアクセスできるものの、これまたファイルをイジれない。しかも、化けてる。DAV Explorerでは、日本語名ファイルは表示すらされなくなる。
結局、あきらめました。正式版をひたすら待つことにしよう。
それにしても、DAV関係の記述はどこにもなかったような・・・いったい、どのパッチが効いたのだ。???
とにかく、試してみたら、日本語名ファイル等を扱わないのであれば、ベイシック認証、ダイジェスト認証どちらでも正常。件の mod_encoding についても、ベイシック認証であれば問題なく動いている。
ところで、なぜ、ダイジェスト認証環境上で mod_encoding がマトモに動いてくれないのか・・まさか・・とは思いつつ、以下のメイルを webdav-webmasters@todo.gr.jp様宛に出してみた。
FreeBSD+ApacheでDAVを動かしています。
WinXPでの認証問題は、WinXP側のパッチでどうやら解消したみたいですが、
mod_encodingを使って日本語ファイル名をいじろうと思っても、
Digest認証の環境では正常に動作してくれないのです。
もちろん、Basic認証では正常に動くのですが。
そーいうものなのでしょうか。
したっけ、wakatono氏から「まだ情報として整理していませんが、そういうものです。(後略)」というお返事が・・・えええぇぇぇぇえええぇぇーーーっ!? へなへなへなへなへなへなへな・・・
そこで登場するのが、UNIX上で動くNetWareエミュレータ、mars_nwe である。
幸いなことに、FreeBSD用のパッケージも用意されている。で、/stand/sysinstall でエイヤッとインストールしてしまった。
インストールしただけでは起動はしないようになっているパッケージが多いのだが、mars_nweは違った。インストールすると、起動用のスクリプトファイルには実行属性が付加され、システム再起動させるとmars_nweも起動してしまうようになっている。
が、起動はできなかった。segmentation faultでコア吐いてお亡くなりになるのである。
で、いろいろ調べてみると、当然だが、kernelがIPXを使えるようにする必要がある。
options IPX をkernelコンフィグに記述して、kernelを再構築。
次に、rc.confにifconfigの記述を追加。
ifconfig_fxp0_ipx="ipx 0x101"
ifconfig_lo0_ipx="ipx 0xbebe.1"
0x101とか、0xbebeってのは、どっかからそのまま持ってきた値で、特に意味はない。
また、mars_nweの起動以前に IPXrouted を動かす必要があるとのことで、/usr/local/etc/rc.d/nwserv.sh の nwserv の前に IPXrouted -s の行を追加。
最後に、/usr/local/etc/nwserv.confの設定をする。
とりあえず変えたのは、以下のセクションである。
1 SYS /usr/local/samba/nwe/SYS/ kt 711 600
2 HAMANASU #NWSERVER_NAME
3 0xbebe 1 #Same as lo0
12 SUPERVISOR root PASSWORD
なんとなく起動したようだが、これだけだとクライアントからは見えない。NetWareクライアントは通常frameとして、Ethernet802.3とか802.2を使っているのだが、FreeBSDの場合、Ethernet_IIでしか使えないようだ。したがって、DOSクライアントの NET.CFG の中身を「FRAME ETHERNET_II」とする。
ちなみに、Win95,98,2K等で「フレームタイプ」を「自動」にしてしまうと、なぜか接続できない。必ず「Ethernet II」に設定のこと。
mars_nweが起動すると、loginやらpublicといったおなじみのディレクトリが作成されている。本物のNetWareサーバから LOGIN.EXE をDOS機にCOPYし、自前で実行すると、めでたく接続完了。
しかし、いろいろ試してみたら、ファイル名の制限があるようだ。
DOS側からFreeBSDにこCOPYする場合、LOGIN.EXE→login.exe のように、ファイル名が小文字に変換される。また、FreeBSD側にある大文字ファイル名の例えば LOGIN.EXE ってのは見えない。小文字でなければ見えないのだ。
漢字ファイル名、例えば 受付帳綴.docってのは、DOSから見ると、当然だが大文字になって 受付帳綴.DOC というふうに見える。
しかし、calamaris のような9文字以上のファイル名は見えない。また、index.html のような4文字以上の拡張子のファイル名もダメ。
とまあ、そんな若干(?)の制限はあるものの、DOS機とFreeBSDでデータ交換ができる(Samba等を併用することでIPXの設定をしていないWindows機とも可)ので、良しとしておこう。
で、いまさらなんでDOS機と・・って話なんだけど、そ、それは勘弁してくだせえぇぇ。(^^;
#現在の問題点
その1 サーバ、クライアント側とも設定はまったくいじっていないのに、接続(LOGIN以前のATTACH)ができないときがある。複数のクライアントで試してみたが同じ。サーバ側に何か問題が??
(サーバ側の再起動で接続できる。また、クライアントを数回再起動させると接続できることもある)
その2 転送速度がせいぜい1Mbps程度しか出ない。クライアントは10BASE-Tや10BASE-2。サーバ側は100BASE-TX。本物のNetWareでは3Mbps程度は出てたような。
4.7-RELEASEは、4.6.2とほとんど変わらないようだが、うちの環境では 4.6.2 よりも安定である。4.6.2 までは、SETI@Home を動かして放っておくと、いつのまにか固まっていることがよくあったが、4.7ではまだ一度も固まっていない。(^^;)
ついでに、パッケージから KDE を入れてみたが、マウスの具合が悪く(クリックしても反応がやたら遅い)、削除して GNOME を入れてみた。しかし、Segmentation Fault で死んだり、フリーズしたりで安定性に欠けるため、GNOME を削除して再び KDE をインストールしたところ、今度はうまく動いた。
日本語化されたパッケージもあるようなので、再び KDE を削除し、ja-kde-i18n-3.0.3 をインストールし、無事日本語版が起動した。(DeskTop画面)
さて、まず、ブラウザである Konqueror を立ち上げてみた。どうやら、ベースは Mozilla らしいが、Windowsと同じようにマウスホイールが効いてほしい。
いろいろ調べてみたが、Net上にある情報はまだ XFree86 3.* のものが多く、だいぶ回り道をしてしまった。4.7-RELEASE 付属の XFree86 4.* では、まず moused のフラグを指定する必要がある。
/etc/rc.conf に、次の記述を追加。
moused_enable="YES"
moused_flags="-z 4"
次に、/etc/X11/XF86Config の記述を修正/追加する。
Section "InputDevice"
Identifier "Mouse0"
Driver "mouse"
Option "Device" "/dev/sysmouse"
Option "Protocol" "auto"
Option "Buttons" "5"
EndSection
"Protocol" のところは、当初 "MouseSystems" としていて、ホイールが効かず、完全にハマってしまった。(^^;)
何が問題かというと、検索なのである。もはや、Googleなどの検索サイトはWebブラウジングに必要不可欠であり、当然ながら検索キーワードを入力しなければ使うことができない。
というわけで、日本語入力のための kinput2 と かな漢字変換サーバ canna をインストールした。cannaは、just.canna というサンプルを ~/.canna にrenameする。これでちょっとだけATOK風になる。
しかし、インストールしてみて愕然とした。なにがって、あなた、ローマ字入力なのである。
・・と、いうことは・・・そう。私は既に絶滅したと考えられている(かもしれない)「カナ入力者」なのである!!
その昔、仕事場にワープロが導入された当初からカナ入力だったのだ。しかし、昨今ではどうだ。WindowsでもUNIX系でもローマ字入力がスタンダードとなってしまい、カナ入力者は、いわれのない差別を受け、迫害されているという現状があることに気づくこととなった。
で、なにがどうしたかというと、ひらがなの「ね る め む ろ を」が入力できないのである。もちろん、ローマ字入力で変換すればちゃんと入力できるのだが、リコーのワープロ、ATOKと経てきた筋金入りのカナ入力をFreeBSDを使うためにやめることなどできるわけがないのである。
そりゃ、私だってローマ字入力くらい人並みにできる。しかし、たとえ無意識に打鍵するのであっても、何が悲しゅうて日本語をわざわざアルファベットに分解して入力せんとあかんのや。無意識に言葉をローマ字に解体していること自体、日本語が変質して行く原因のひとつになってるような気もするぞ。
で、いろいろ情報を漁り、.cannaの中身の「(setq romkana-table "just.cbp")」となっている部分の just.cbp を kana.cbp に書き換え、同ファイル中の「シンボルの定義」
の部分を削除することで、「を」「ろ」以外は入力できるようになった。
しかし、「を」と「ろ」を入力する方法がわからない。さらに情報を漁ると、keymapを強制的に書き換えるという手法があることが判った。
# kbdcontrol < /dev/ttyv0 -d > /usr/share/syscons/keymaps/mykeymap.kbd ・・と、やって、keymapを mykeymap.kbd に書き出し、mykeymap.kbdを編集して、起動時には逆に kbdcontrol < /dev/ttyv0 -l mykeymap.kbd ・・として修正後のkeymapを読み込ませるというわけだ。
これでやっと、真の自由にたどり着いた(^^;)と思いきや、これではダメだったのである。確かにkeymapは修整したはずなのに、あいかわらず「を」「ろ」が入力できない。(化けてしまう)
どうやら、X の環境では、Xの起動時に改めてkeymapが定義されるらしい。
ということは、Xでのkeymapを取得し、修整して、X起動時には修整したkeymapが読み込まれるようにすればいいのだ。
% xmodmap -pke > mykeymap.kbd
xterm で これを実行し、mykeymap.kbd の中身を keycode 19 = 0 bar kana_WA kana_WO と keycode 123 = grave underscore kana_RO に書き換えて、.xinitrc に一行追加し、次のようにする。
kinput2 -canna &
xmodmap - < mykeymap.kbd
exec startkde
これでようやくマトモにカナ入力可能になり、戦い続けることができるわけだ。
※この後、再び「ろ」が入力できなくなった
なお、インストールしただけのcannaは「お馬鹿」であると言われているので(それはたぶん正しい)、Windowsで使用しているATOKから自前登録単語(2,500語程度)を抽出し、エディタの置換機能と conv_atok2canna というawkスクリプト(これはATOKの旧バージョン用であり、スクリプトだけでは正しく変換できない)を使ってcanna辞書formatに変換し追加辞書として使っているが、今のところはなんとかなっている。
