こんなん 「事故」 ちゃうど。(まぁ暗号化云々は事故かもしれないけど) こんなマヌケなバグが存在すること自体問題じゃないのか？ スレッドや変数のスコープについての配慮はプログラミングの基礎中の基礎だ。 ど素人の学生さんあたりの「作品」なら仕方ないかもしれないが， プロの仕事なら許されないぞ， こんなの。
記事では 「テストでの発見が非常に困難」 とかかれているが， そんなこたぁない。 DBトランザクションの境界テストや高負荷を発生させるラッシュテストくらいは最低でもするだろう。 その時点で上記の問題は発覚する筈だ。 まぁ発覚しても原因がそんなマヌケなコーディングミスにあるとは (マヌケ過ぎて) なかなか気付かないかもしれないが。 上記のような 「別人問題」 を発生させたサイトはそれすらやってないという証拠だよな。(そもそもテストの意味が分かってるのか？) つまり 「別人問題」 以外にも重大な障害が潜在している可能性が大きいということだ。
「[memo:5023] サイト「日本におけるインターネットの法に基づく傍受」」
TIFF画像なのでモニタで見るのは疲れる。 一度紙に出力しないとダメかな，こりゃ。
Windows & Macintosh 版正式リリース。 ソースコードも公開。(6.5.8 以来) いやぁ，めでたい。 しかし，やはり日本語のサポートが欲しいところ。
「“便所の落書き”から抜け出すには 〜有意義な議論を行なうための掲示板ツール」
掲示板というよりも 「公開稟議システム」みたいな感じ。 こうなると発言にファイルとか添付できるようになるとなおよいかも。
「PGP8.0リリース、ソースコードも制限付き公開」
「暗号化ソフト「PGP8.0」関連製品群リリース 〜 WindowsXPとMac OS Xをフルサポート」
あぁやっぱり日本語の記事はいいな。 「バグ修正の義務を負わない」 のなら (ckt版のような) fork を許可して欲しいと思うのだが... まぁ実績はこれから作っていくものだし当面は暖かく見守っていくしかないのだが。
「あなたのパソコン、まだFATなんですか？ NTFSのススメ」
まっWfW系を使ってるんじゃなきゃFATにするメリットはあまりないかも。 そっかぁ， ハードリンクは標準機能だったのか。
「CRYPTREC暗号技術評価の経過報告」
「CRYPTREC暗号技術評価結果 〜平成13年度で評価を終了した暗号技術〜」
うへぇ！ 「新たな電子政府用システムを構築する場合、より長いハッシュ値のものが使用されるのであれば、256ビット以上のハッシュ関数を選択することが望ましい」 だって。 160ビットじゃ足りまへんか。
MD5，RC2，DES/TripleDES は安全とみなされていない。(RC2，DES/TripleDES には2^32ブロック以上を同じ鍵で暗号化すると平文1ビットの情報が漏れる可能性がある) また SSL/TLS は2001年版のレポート (PDF) を見る限り安全とはみなされていないようにみえる。
「Windows XP Disclosure of Registered AP Information」 (SNS Advisory No.60)
Windows XP の無線LAN機能はヤバいという話。 サードパーティ製のドライバを使う事で回避できるかもしれないそうだ。 上記のはバグに近いが， 無線LAN自体セキュリティ上の観点から見てヤバいって (何度でも言うが)。 使うならそういう心配のない条件で使うか， WEP以外にも2重3重のガードをかける (できればノードも分ける) ようにしないと。
これは， Windowsが脆弱であるということにはならない。 Windowsプラットフォームで大流行するウイルス (含ワーム) のほとんどは既知のセキュリティホールを突いたもので， 基本的に回避可能なものばかりだ。 ウイルスだけじゃなくセキュリティ対策は日々の運用が大事である。 Linux プラットフォーム向けのウイルスも今後増えていくだろう。 もっとも Linux の場合はウイルスよりも配布パッケージにトロイの木馬等を仕掛けられる危険性の方が大きいと思うが。 「UNIXだから安全」 などと考えるオメデタい人間が管理者をやってるようじゃWindowsよりも危ないよな。
今回は久し振りに TeX & Ghostscript インストールメモだ。 長文注意。
現在， 家庭内LANの再構築を行っているのだが， この機会に pTeX と Ghostscript もインストールし直すことにした。 昨年の7月以来の作業である。(まぁ部分的にアップグレードはしていたが)
早速 「日本語 TeX についての情報」 で最新情報をチェックしてみる。 おおっ！ いつの間に Web2C-7.4.0 & Kpathsea-3.4.0 ベースになっとるぢゃないか。 GNU 版の Ghostscript も 7.05 になっとるし。 ええいっ， 全部ダウンロードしちゃえ！
GNU Ghostscript は gs-cjk Project の成果を取り込んで日本語が扱いやすくなっていた。 Windows プラットフォームでの導入手順は以下が参考になる。 UNIX 系のプラットフォームでは日本語環境の設定が難しいところだが， Vine Linux あたりは出荷状態でちゃんと日本語が使えるらしいので特に問題ないであろう。
奥村晴彦さんの所の説明はちょっと不完全なので注意が必要。 CJKフォント情報を格納する Resource フォルダ下には少なくとも Font フォルダを作っておく必要がある。(中身は空でよい) つまり Resource フォルダ下には CIDFont, CMAP, Font の3つのフォルダが存在する事になる。 私はここでひっかかった。 更に Ghostscript を TeX などの他のツールから使う場合には環境変数 PATH にパスを追加する必要がある。 インストール先が c:\gs なら PATH に 「c:\gs\gs7.05\bin;c:\gs\gs7.05\lib」 を追加する。 なお以前は必要だった GS_DLL, GS_LIB 各環境変数はこのバージョンでは必要ない。(これらは何とレジストリに登録されている) 以前のバージョンからアップグレードする場合にはこの2つの環境変数をあらかじめ削除しておく方が安全である。
「東風明朝 CID 化キット」 は本当に素晴らしい。 このフォントを導入する事により PDF に埋めこまれたフォントのライセンスに悩まなくても済むようになる。 フォントの作成をしておられる方々にはいつも感謝をしております。 このフォントを使えるようにするには幾つか方法があるが， gs705w32.exe パッケージに含まれる CIDFnmap, CIDFnmap.CJK を書き換えるのがお上品と思われる。 具体的には CIDFnmap 内の CIDFnmap.Koc, CIDFnmap.CJK 呼出部分のコメントを外し， CIDFnmap.CJK 内の以下の記述部分のコメントも外す。
%/Ryumin-Light /Kochi-Mincho ; % CIDFnmap.Koc %/GothicBBB-Medium /Kochi-Gothic ; % CIDFnmap.Koc
ついでに以下の記述も CIDFnmap.CJK に追加しておくとよいだろう。
/HeiseiMin-W3 /Kochi-Mincho ; % CIDFnmap.Koc /HeiseiKakuGo-W5 /Kochi-Gothic ; % CIDFnmap.Koc
CIDFnmap.CJK はオリジナルをベースに上記の東風フォント用とかMSフォント用とか幾つかパターンを用意しておくとよいだろう。 そうすればあとは CIDFnmap 内の記述と CIDFnmap.CJK のファイルの差し替えで環境を切り替えられる。 ちなみにMSフォントを使う場合は奥村晴彦さんの所の説明が参考になる。
GSView は (少なくとも Windows プラットフォームでは) もはや不要である。 PostScript ファイルは Ghostscript のターミナルウィンドウにファイルをドラッグ & ドロップするだけで表示される。 Postscript から PDF への変換は Ghostscript パッケージに含まれるコマンド (ps2pdf14) で問題ない。 また中丸幸治さんのサイトで公開されている jps2pdf を使うという手もある。(でも jps2pdf はそのままではWindows プラットフォームでうまく動かないみたい)
dvipdfm-cjk は dvipdfmx Project として開発が続けられているらしい。 角藤亮さんが公開しておられるパッケージには日本語対応版の dvipdfm とは別に dvipdfmx が同梱されている。 これは以前は dvipdfme として配布されていたものだ。
dvipdfmx の特徴は
といったところだろうか。 ほとんど無敵である。 詳しくは 「CID-keyed font support for dvipdfm」 を参照のこと。
dvipdfmx を使えるようにするには幾つかの設定ファイルを修正する必要がある。 以下は角藤版パッケージを前提にしている。 まず， share\texmf\texmf.cnf 内の CMAPINPUTS 値を上記の Ghostscript のセットアップ時に作成した Resource フォルダに変更する。 こんな感じ。
CMAPINPUTS = c:/Resource/CMap//
次に share\texmf\dvipdfm\config\cid-x.map 内の rml, gbm, rmlv, gbmv の各定義を変更する。(実は変更しなくても動作するのだが， この場合MSフォントを埋めこんでしまう) cid-x.map の記述を調べて以下のMSフォントの定義をコメントアウトし，
rml H :0:msmincho gbm H :0:msgothic rmlv V :0:msmincho gbmv V :0:msgothic
代わりに Acrobat Reader 標準フォントを定義している以下の部分のコメントを外す。
%rml H Ryumin-Light %gbm H GothicBBB-Medium %rmlv V Ryumin-Light %gbmv V GothicBBB-Medium
dvipdfmx はAcrobat Reader 標準フォント (Ryumin-Light, GothicBBB-Medium, HeiseiMin-W3, HeiseiKakuGo-W5) が指定されている場合はフォントの埋めこみを行わないようになっている。 ちなみに H は横書き， V は縦書きを意味する。 このうち少なくとも H については定義しておかないと正しく動作しないらしい。
暗号化の設定は share\texmf\dvipdfm\config\dvipdfmx.cfg で行う。 K で鍵長 (40-128) を， P でパーミッションを設定できる。 例えばパーミッションを 0x0B14 にすると印刷や複製は許可するがファイルそのものへの変更はできなくなる。 実際にドキュメントを暗号化する場合には 起動パラメータに -S を指定する。 オーナーおよびユーザのパスワードを訊かれるので， あらかじめパスワードを決めておくこと。 パスワードを空欄にすると暗号化されない。 パーミッションを有効にするにはオーナーパスワードを設定する必要があり， PDFファイルを開く事自体制限するにはユーザパスワードを設定する必要がある。
dvipdfm では， 日本語でブックマーク (しおり) を作成する場合にはもとになる情報を一旦 Unicode に変換する必要があった。 dvipdfmx では pLaTeX2e ソースファイルのヘッダ部分 (なるべく先頭の方) で以下の special コマンドを追加すればよい。
\AtBeginDvi{\special{pdf:tounicode 90ms-RKSJ-UCS2}}
なお，ブックマークを作成するには hyperref パッケージの指定で以下のようにパラメータを追加する。
\usepackage[dvipdfm,bookmarks=true,bookmarksnumbered=true,bookmarkstype=toc]{hyperref}
...これで out2uni は必要なくなった。
dvipdfm(x) ではフォントデータを埋めこまずに 「軽い」 PDFファイルを生成する事が可能だが， ツールによってはそれが難しいこともある。 そういう場合は中丸幸治さんの replacejfonts を適用する事により最少構成の Ryumin-Light および GothicBBB-Medium データに置き換えてくれる。(フォントメトリック情報を残すこともできる) PostScript データから (Ghostscript 経由で) PDF を生成する際には便利。
角藤版パッケージを導入している場合は 「CID フォントとGS (Win32)」 の後半の記述を参考にして replacejfonts を導入しよう。
前回はパッケージを展開するだけで動いてたのに比べると， 今回はセットアップに多少手間がかかる。 それでも Windows プラットフォームに限れば角藤さんの見事なディストリビューションで作業を相当軽減できている。 いつも感謝しながら使わせていただいてます。
日本語のフォント環境に関しては， ここ1,2年で随分改善されているように思う。 ひとつはフォントに対する著作権の意識が定着しはじめていること。(法的には 「フォントデザインには著作権がない」 とする国が多いらしいけど) もうひとつはフリーなフォントとコマーシャルなフォントとが対等の立場になりつつあり 「交換可能」 になってきていること。 これはきっと前者の 「著作権の意識」 と無関係ではないだろうし， Linux をはじめとするオープンソースなプラットフォームの台頭が後押しをしている事も確かだろう。 フォントを駆使する必要のない私文書や技術資料などはフリーで十分間に合うし， それ以上を望むなら 「商品」 を購入しフリーな環境に追加しても全く問題はない。(ライセンス条項に反しない限り，だけど)
「Adobe Universal PostScript Windows Driver Installer 1.0.6 - Japanese」
前にダウンロードしていたが， バージョンが上がっていたのでこいつもアップグレード。 出力ポートを FILE にすればどんなドキュメントも PostScript ファイルになる魔法のドライバ。
たて続けに障害報告をいただく。 大体絞り込めてきたけど何せ直してるヒマがない。 今度の連休で何とかできればいいけど... ご不便をかけまして申し訳ないです。
今回もインストールメモ。 今回は SSH を中心にお送りします。
勤務先から格安でまき上げたマシンに UNIX プラットフォームを構築する事にした。 いや， 実験で自由に使える環境が欲しかったので。 Linux と FreeBSD で悩むところだが， ハッキングが目的ではないので 「初心者に易しい」 Linux， それも 「日本人に易しい」 といわれる Vine Linux を選択した。 まぁ 2.6r1 のパッケージが雑誌の付録として本屋に積み上がってたというのも理由のひとつなんだけど。 その辺の顛末はいずれ。
んで， ようやく再構築中の家庭内 LAN 環境が整いつつあるのだが， どうせなら Windows から Linux 機をリモートで操作できるようにするべ， ということでツールの物色をはじめることにした。
他のディストリビューションは知らないが， Vine Linux 2.6 では初期状態ではリモートからアクセスできないようになっている。 telnet は例外みたいだけど。 で， その辺のアクセス制限を解除しようといろいろ怪しい事をしてみたがどうもうまくいかない。 まぁその手の本を買って読めば一発なんだろうけど， 面倒臭いし仕事の合間に少しずつやってる状態で腰を据えてできないという事情もある。 そのうちデフォルトの設定のまま SSH 経由でアクセスすればいい事に気がついた。 そういうチューニングになっているようである。 ということは Windows 側で適当な SSH クライアントを用意すればリモートでアクセスできるようになるわけだ。
真っ先に思い浮かんだのは TTSSH を使ってアクセスする方法だった。 これなら以前仕事で使ったこともあるし， 何とかなるじゃろ。 TTSSH は ForwardX11 をサポートしている。 うまくいけば Windows を X 端末として使える筈である。
X サーバは WeirdX を使う事にした。 ASTEC-X は以前仕事で使ったこともあるので馴染みがあるが， いざ個人で買って使うとなるとちょっと躊躇する値段である。 WeirdX の最終的な起動パラメータは以下のとおり
java.exe -Dweirdx.display.charset=JISX
-Dweirdx.display.keymap=jp106
-Dweirdx.display.visual=TrueColor16
-Dweirdx.displaynum=0
-Dweirdx.ddxwindow=com.jcraft.weirdx.DDXWindowImpSwing
-Dweirdx.windowmode=RootlessWM
-jar weirdx-1.0.31.jar
WeirdX はデフォルトでディスプレイ番号を2に設定している。 が， TTSSH では0番固定になっているようなので WeirdX の方の設定を変更する必要がある。 ウィンドウマネージャは WeirdX 側のものを使う (RootlessWM) ことにした。 他の方法はうまくいかないか， あまり使い勝手が良くない。
表示スピードはまぁまぁ。 私の非力なマシンでも特にストレスは感じない。 大したもんである。 が，しかし， 日本語が表示されない。 なんで？ Google で WeirdX の日本語関連のページを漁ってみるが設定に問題は見当たらない。 とするとあとは Java のバージョンか。 私の環境には現在 J2RE 1.4.1_01 を導入している。 そういやこいつ例外を吐いてるなぁ。 やっぱこれかな。
「複数ベンダーのSSH製品にセキュリティ・ホール，管理者は要確認」
ところで上の記事にあるように SSH の各実装で脆弱性 (内容や程度は製品によって様々) が報告されているようである。 TTSSH は今のところ 「unknown」 になっている。 しかし， それをいうなら SSH1 は幾つか脆弱性が報告されていて既に推奨されないプロトコルになっている。 この機会にそろそろ古いツールからの乗り換えが必要な時期かもしれない。 (TeraTerm の真価はテキストベースのパソコン通信や telnet といった従来のダム端末用プロトコルをいかに効率的に利用するかという点にあると思うし)
上の記事を見て 「そういや PuTTY ってのがあったな」 と思い出した。 0.53b なら報告された脆弱性の心配はないようである。 せっかくなので PuTTY を試してみる事にする。 うまくいけば乗り換えも考えよう。
PuTTY およびその日本語環境のインストールについては 「PuTTYによるWindows上でのSSH接続」 がお薦めである。 ただしインストール後の (鍵の生成・登録など) 設定については 「Putty による SSH の設定」 の方が分かり易い。(後者のページは PuTTY の古いバージョンの日本語パッチを使っているので注意が必要) ちなみに公開鍵をサーバサイドに転送するのには PuTTY に同梱されている pscp コマンドを使った。(現時点でまだ FTP のセットアップをしていないのだ) 認証は (S/Key 認証はサポートしてないみたいだし) 取り敢えずパスワード認証。
PuTTY もポート転送をサポートしている。 もちろん ForwardX11 もサポートしている。 しかもディスプレイ番号を指定できるようになっている。 試しに上記の WeirdX を weirdx.displaynum プロパティを指定せずに (つまりデフォルトの2番で) 起動して kterm を呼び出してみたら問題なく起動した。 これはやはり TeraTerm から乗り換えない手はないな。
でもやっぱり日本語の表示ができない。 まぁ今のところ UNIX プラットフォームでデスクトップ作業をする気はないので取り敢えずよしとしよう。 あぁ， もっとちゃんとした X サーバが欲しい。(Cygwin を使えってのはなしね) それともやっぱり買わなくちゃだめなんだろうか。
pscp 用のフロントエンドとして 「Putty による SSH の設定」 で紹介されている Secure iXplorer Pro を試してみたのだが， 何故かログイン後のディレクトリ情報収集の段階で止まってしまうようである。 で， WinSCP 2.0 beta (#110) を試してみた。 これが実に使いやすい。(LOOK&FEELをエクスプローラ風にしてひとつのフォルダのように扱える) これなら FTP も SAMBA も要らねぇぢゃん！ 難点は
だが， 致し方あるまい。 2.0 の正式版リリースに期待しよう。
やられた！ RFC2440 のページが無くなってるぢゃん！ しかも日本語版まで無くなってるし。 ちうわけで， 日本語版が見れるところは 「GNU Privacy Guard講座」 内だけかな？
「あゆめみのホームページ」 で Windows プラットフォーム用の日本語 mo ファイルが公開されてるぞ。 他にも pgpdump の Win32 バイナリとか， WinPT に日本語化パッチをあてた奴とかあって凄いぞ。 でも何故か WinPT をダウンロードしようとすると 24KB しか取れなくて解凍に失敗するんだけど...
前回， うまくダウンロードできないと書いてしまった 「あゆめみのホームページ」 で公開されている WinPT のパッチだが， 何とご本人から直接メールを頂いてしまった。 恐縮です。 あれはパッチ情報しか含んでいないので24KBのサイズで正解なんだそうだ。 本家の WinPT をインストールしているフォルダに上記パッチファイルを置いて実行すれば自動的に処理してくれる。 パッチをあてる前にCRCチェックもしてくれるので， 万一違うバージョンのパッチファイルを実行してしまっても大丈夫。
おおっ， なんか着々と環境が整備されていく。 着々でないのは拙作のみかぁ。 困ったもんだ。
「【5分で覚えるIT基礎の基礎】 だれでも一度はアセンブラを学んでおこう！」
こういうものが連載されるということは， 本当に今のソフトウェアエンジニアたちはアセンブラを知らなかったりするのか？ まぁうちの勤務先でも最近は新人研修カリキュラムからアセンブラが削除されたりしているのであり得ない事ではないが， そういう人はどうやって C や C++ といった低級言語を理解しているのだろう。 謎である。
WinXP を再インストールする時に煩わしいアクティベーションを省略するためのTIPSだ。 憶えておいて損はない。
最近仕事で WinXP を触っている。 WinXP は 「よくできている」 OS と言っていいと思う。 少なくともユーザインタフェースに限ってはそうだ。 見た目が大幅に変わっているので慣れるのに時間がかかってしまったが， 慣れてしまえば実に使いやすい。
しかしコンピュータ管理者としての立場からみると全く逆の感想になる。 こんな性悪な OS はない。 先ほど 「最近仕事で WinXP を触っている」 と書いたが， あまりの使い勝手の悪さにキレた私は設定を全てクラシックモードに変えてしまった。 しかし納入の際は元の設定に戻さなければならないので頭の痛いところである。
使い勝手が悪いと感じる理由のひとつは， ほとんどの管理ツールがユーザから見えないようになっている事だ。 WinXP の設計コンセプトは 「余計なものは見せない」 ようになっている点で， ユーザ操作の傾向を監視して表示のフィルタリングを行っている (これはW2Kからだが， より徹底的である) 点も見逃せない。 全部見えるようにするにはクラシックモードに切り替えるしかない。 もうひとつは， こちらがより重要だが， OS 内のリソースへのアクセス制限がより厳密になっている事だ。 はっきり言って 「Users」 グループのユーザはデフォルトではコンピュータ内のリソースに殆どアクセスできないようになっている。 特に NT 4.0 から WinXP に乗り換えた人は， そのギャップのあまりの大きさにとまどってしまうかも知れない。 レジストリなどのシステムリソースの使い方の悪い， いわゆる 「行儀の悪い」 アプリケーションは WinXP では殆ど動かないのではないだろうか。
もちろん制限が厳しくなったのは度重なる Windows プラットフォームのセキュリティインシデントに対する批判への回答でもある。 そういう意味では一定の評価をすべきなかも知れない。(もっとも「やっとこれで人並み」とも言えるかもしれないが) しかし， このような設定なら WinXP ユーザは利便性を求めて常に Administrators 権限で運用するようになってしまうだろう。 これでは本末転倒である。
WinXP のセットアップはデフォルトの Administrator ユーザ以外に通常ユーザのアカウントを作成するように強制する。 これ自体は悪い事ではない。 しかし作成したアカウントは最初から Administrators 権限が付与されている。 一方， 本当の意味での一般ユーザである筈の Users グループで作成したアカウントは 「制限ユーザ」 と呼ばれ， 殆ど何の操作もできない可能性がある。 WinXP を導入したごく普通のユーザがコンピュータやアカウントなどの管理をどのように行うか， 火を見るよりも明らかである。
今回もインストールメモ。 今回はケロちゃんを中心にお送りします。
Linux マシンに Kerberos 5 を入れて W2K マシンの認証をやらせてみる。 元ネタは以前ここでも紹介した 「Windows 2000 マシンの認証を Linux 上の Kerberos サーバで行なう方法」 から。
Vine Linux は Kerberos パッケージを直接サポートしていないらしい。 ソースコードからコンパイルするすればいいのだが， ちょっと面倒に感じたので取り敢えず Red Hat Linux 8.0 Publisher's Edition の中にある rpm パッケージ (krb5-server, krb5-workstation, およびその依存パッケージ) をツッコんで使ってみることにした。 導入時の参考としては同じく Red Hat のサイトにあるリファレンスガイドが役に立った。 なお Kerberos 5 には脆弱性が指摘されているので取り扱い注意だ。
Realm および KDC を以下のように定義して話を進めよう。
Realm Name: HOGE.LOCAL KDC (Key Distribution Center) : krb5.hoge.local (192.168.1.2)
Vine Linux をインストールすると何故か krb5.conf が最初から存在するが中身は空っぽである。 rpm パッケージをインストールするとサンプルファイルができるのでそれをもとに krb5.conf を構成する。 ここで気をつけなければいけないのが以下の記述 (特にアンダーラインの部分) である。
[libdefaults] ticket_lifetime = 24000 default_realm = HOGE.LOCAL default_tkt_enctypes = des-cbc-crc default_tgs_enctypes = des-cbc-crc dns_lookup_realm = false dns_lookup_kdc = false
実は W2K では Kerberos 5 と互換性のある暗号タイプとして des-cbc-md5 と des-cbc-crc しかサポートしていない。 一方， Kerberos 5 Workstation は des-cbc-crc と des3-hmac-sha1 がデフォルトである。 したがって， 両方のプラットフォームで使えるようにするには des-cbc-crc しか選択肢がない。 この辺は 「Windows 2000 マシンの認証を Linux 上の Kerberos サーバで行なう方法」 の記述では不完全なので要注意だ。
もう一点 「Windows 2000 マシンの認証を Linux 上の Kerberos サーバで行なう方法」 の記述では不完全と思われる部分が W2K 側の設定である。 W2K 側は ksetup.exe を使って設定するのだが， 具体的には以下のように設定する。
C:\> ksetup /SetRealm hoge.local Setting Dns Domain C:\> ksetup /AddKdc HOGE.LOCAL 192.168.1.2 C:\> ksetup /AddKpasswd HOGE.LOCAL 192.168.1.2 C:\> ksetup /SetComputerPassword password Setting computer password C:\> ksetup /MapUser * *
なお， 対象となる W2K マシンは DNS に登録されている必要がある。
以上2点に気をつければ他の部分は 「Windows 2000 マシンの認証を Linux 上の Kerberos サーバで行なう方法」 の通りに作業すれば問題ないようだ。 当然ながら Principal はホストとユーザ両方を登録しておく必要があり， Realm と Principal の初期登録で最低でも4つのパスワードをあらかじめ用意しておかなければならない。 今回は実験なので管理用パスワードを全部同じにしたのだが， 実運用ではそういうわけにはいかないだろう。
Active Directory ではグローバルなアカウントとローカルコンピュータのアカウントは別物 (したがってプロファイルも別物) になるのだが， 今回の構成ではアカウントの管理はあくまでローカルコンピュータ (W2K) 側にあるので， 見た目は特に変わったように見えない。 でも実を言うとその方がいろいろと嬉しかったりする。
Windows プラットフォームの認証システムは Kerberos＋LDAP を核とした Active Directory と RADIUS を核にした IAS (インターネット認証サービス) によって完全に統合されている。 従って Windows プラットフォームの中にいる限りこれら認証システムの導入・運用は非常に楽に行える。 一方， 認証システムを外 (Linux 等) に出した場合は保守・管理がかなり面倒になりそうである。 暗号タイプが事実上 des-cbc-crc しか使えないというのも痛い。 しかし， やっぱりサーバサイドを Windows プラットフォームにするというのは (将来を考えると) できるだけ避けたいので， この方式でもう少し調べてみることにしよう。 MS のサイトにある文献も挙げておく。
「Windows 2000 マシンの認証を Linux 上の Kerberos サーバで行なう方法」 で紹介されているリンクは古いので上記の方を利用するとよい。
つか， ほぼ修正が終わった。 いろいろ試したあげく， --batch オプションを追加すればいいことに気付いた。 相変わらずマヌケな私。 あとはパッケージングを行ってなんとか今年中にはリリースできそうかな。
年がかわらんうちに書いてしまおう。
実は10月の契約更改時に勤務先のオフィスを追い出されてしまったのだが， その代わりに今まで使っていたマシンを安く譲って貰うことにした。 といっても買ったのは既に5年以上前なのでかなり古い機種だ。 5年以上と聞いてピンと来る人もいるかもしれないが， このマシン既に減価償却が終わっているのだ。 結局マシン一式を下手なブランド品のHDDよりも安い値段で引き取ることができたのだった。 それでもしばらくは， 出張中だったこともあり， 放ったらかしていたのだが， 12月に入って体調を壊し広島に帰ったのを幸いに少しずつ家庭内 LAN 環境を整備する事にした。
で， そのマシンをどうするかだが， UNIX または UNIX 互換環境を入れることは決定していた。 今回は一応目的が2つある。 まずひとつは Windows Workgroup システムを UNIX 側でどれだけ引き受けられるか実験すること。 もうひとつは UNIX 上で Windows (またはその他のプラットフォーム用の) のクロス開発環境を構築することである。 候補としては FreeBSD または RedHat/Vine Linux にしようと思っていた。 結果は前に書いたとおりである。
クロス環境が必要な理由のひとつは次期 BkGnuPG である。 殆ど設計せずに行き当りばったりで作った BkGnuPG は早くも設計上の破綻を見せはじめている。 一方， GnuPG まわりでは GPGME や OpenCDK など魅力的なライブラリが公開されていて自前で全部作るのはもはや合理的ではなくなっている。 次期 BkGnuPG はこの辺を取り入れて多少なりとも合理的な (^^;) 設計を目指す必要がある。 となれば上記ライブラリや GnuPG や WinPT といったあたりも見てみなければなるまい。 そのためのクロス環境なのである。 (まっそれも来年忙しくなればまた棚上げになる可能性が高いけど)
クロス環境としては Cygwin という手もある。 実は一度導入したことがあるのだが結局捨ててしまった。 Cygwin は Windows プラットフォーム内で UNIX 互換環境をエミュレートするものだ。 したがって単に UNIX のコマンドやアプリケーションを Windows 上で動かすという以上のものがある。 もちろんこういう需要があるのは分かっているしそれを否定するつもりはないが， 明らかに Windows プラットフォームと Cygwin プラットフォームはひとつのマシンの中で齟齬を起こしている。 私にはそれが非常に気に入らなかった。 それならば低いスペックでもいいから開発専用の UNIX マシンを用意してそこで作業した方がすっきりしてるし安心感もある。 ...と思って画策しはじめたのが一年以上前だから呑気な話である。
しかし， Linux がここまで 「使える」 ようになっているとは正直あまり想像していなかった。 UNIX を管理者モードで使う事自体久し振りなのだが， 私の中では 「Linux はオモチャ」 という先入観が強く (昔は Linux なんて X 端末機用の OS くらいの位置付けだったのである) サーバとして使えるようにするためにはかなり手を入れる必要があるんじゃないかと覚悟していたのである。 でもまぁこれはディストリビュータの成果といえるかもしれないけど。
ちうわけで当分慣れるまでは私も Linux 初心者として振舞う事にした。 先行して書いているインストールメモもそういう立場で書いてるつもりだ。 この辺は改めてどこかにまとめて公開するかもしれない。(主に私用に)
ついでに書いておこう。 今回 Microsoft Software Update Services を実験的に導入している。 @IT の記事などでは Active Directory を構成していないと難しいように書かれているが， そんなことはない。 Active Directory を構成していればドメインのポリシー設定で各マシンに SUS クライアントを一斉にセットアップできるから楽， というだけの話である。 Workgroup での SUS のセットアップは SaKuRa WORKS 内のコンテンツである 「SUSをネットワークに立てよう」 および 「クライアントをSUSに同期させる」 が役に立った。(SaKuRa WORKS のコンテンツは有用な情報が多くお薦めだ) もし LAN 内の Windows マシンが W2K 以上で構成されているなら SUS は絶対お薦めだ。 ただし MS の Hotfix の量は尋常ではないので， 回線が細い場合は要注意である。(再来月の請求が恐い)
Vine Linux は apt-get コマンドが使える。 これは便利。 ただし， こちらも Update するモジュールの量は尋常ではなかった。(再来月の請求が恐い)
両者の Hotfix/Update モジュールの量を見てるとウンザリする。 メンテナンスフリーなんてあり得ないとは分かっているが， これはちょっと酷すぎる。 両者を単純に比較するのは難しいが， ユーザ (コンピュータ管理者) の立場からいえばどっちもどっちな感じである。
「Windows デスクトップ製品のライフサイクル - Internet Explorer および他の Windows オペレーティング システムのコンポーネント」
なんと IE5.5 のメインストリームでのサポートは実質今年いっぱいで終了らしい。 IE6 Gold もそうだ。 従って今のところ大丈夫なのは IE6SP1 または W2K 付属の IE5.01 である。 IE ユーザは早めにアップグレードを。
というわけで何とか年内にリリースできました。