Windows LAN server HOW-TO by Ryan Cartwright,&space; v0.1, 21 September 2000 翻訳:瀬戸口 崇 日本語訳:2000 年 11 月 15 日 このドキュメントは Windows9x を走らせているコンピュータのあるオフィスで Linux を サーバにしたいと願っている人々の手助けになることを意図したものです。 献辞

第一に、本書を、わが救世主たるイエス・キリストに捧げます。 この仕事をやり遂げた能力は、主によって与えられたからです。 第二に、本書を、本書に登場する様々なユーティリティとドキュメントの作成者達に捧げます。 それをやり遂げたツールは、かれらによって与えられたからです。

序章

職場での Linux の人気はますます高まっています。 主に、サーバレベルでのインターネットの市場で展開されていますが、 内部ネットワークサーバやワークステーションなどの他の分野へも拡大しはじめています。 このような状況を鑑み、また後で述べるような理由もあり、私の会社は Windows9x ベースのネットワークに Linux ベースの LAN サーバを配備することにしました。 私は Linux の基本的な知識と UNIX の いくらかの知識をもって、このプロジェクトに着手しました。 このプロジェクトを通して私は、この仕事の内容について書かれたある種のドキュメントがあれば役に立つだろうと感じました。 そしてその類のドキュメントを見つけられなかったので、書く事にしたのです。

使用した様々なツールやユーティリティのインストールや設定について、 ここで改めて解説するような事はしていません。 そのような説明を繰り返す事は私には意味がありませんのでその代わり、 インストールや設定の時に遭遇した問題やそのような場合の解決法をドキュメントに含める事にしました。 筋書き

新しいサーバが設置される前の環境に関する背景を少し説明しておいた方が良いでしょう。

およそ35台の PC が広い敷地内を横切った Ethernet LAN で繋がっています。 多くのオフィスと同じように、最初は1台の PC から始まり、少しずつ拡大して現在の環境になりました。 スピードや利便性、コストの面から ピアツーピア(peer to peer)ネットワークが採用されました。 共有レベルのアクセスを利用して、ユーザ達はネットワーク越しにディレクトリやプリンタを共有しています。

それらの PC の内の1つが &dquot;サーバ&dquot; と称されるようになりました。 (これ以降、これの事を "サーバ PC" と呼ぶ事にします。) ピアツーピアネットワークにはサーバ自体存在しないので、専属のユーザをもたないという点を除けば この PC は他の PC と何ら変わりがありませんでした。 この(サーバと称する)PC はすべてのユーザが使用するためのテンプレートや小規模のデータベースなどの 共通ファイルを保存したり、社内メールシステムの為の Microsoft Mail postoffice のディレクトリに 使われていました。 Microsoft Fax を使ってこの PC を介したネットワーク FAX が送信されたり、もっと最近では メールサーバユーティリティを使った e-mail 配信も追加されました。これは定期的に社外の メールサーバに接続し、メールを再配信するものです。 近くの大多数のユーザ達の為にプリンタも共有していました。 FAX や メールのクライアントには Microsoft Outlook が利用されていました。

サーバ PC を介したトラフィックの増加、とりわけインターネットメールが増加した事で ついにはファイルアクセスのスピードが低下したり、 ユーザーがインターネットメールサーバにログオンできない事があるような事態にまで達しました。 はじめは、インターネットメールサーバのプログラムが疑われたのですが、 テストが進むにつれそれが間違いであることが証明されました。 ユーザ達の欲求不満はどんどん膨らみ、IT サポートの担当者達にこれらの苦情を次々と 持ってくるようになりました。

さらに2次的な問題も考慮しなくてはなりませんでした。 サーバ PC と称する PC の運用を経営者から見れば、 そこに誰も座っていないが故に、立派な1台の PC が "何も仕事をしていない" 事を意味していました。 ユーザ達は臨時的にこの PC をワークステーションとして使うことを許可する、という決定がなされました。 しかしこの PC は、ワークステーションとして使われている時にフリーズしてしまう事がありました。 こうなると PC を再起動する間、他のユーザは大切なファイルにアクセスができなくなるうえ、 再びアクセスできるようにデータベースやファイルの排他共有ロックを解除しなけれなりませんでした。

選択肢

この状況では何らかの救済手段が必要でした。 最も基本的なレベルの選択肢は、「修理、あるいは交換」ですが、ありがちな事に それには予算上の制限がありました。

修理

修理する、というのは一見最も迅速かつ安価な選択肢ですが、大抵の場合、 特に正確な原因が判明していない場合には容易な事ではありません。 ワークステーションとしてはこの PC には何の問題もないのですが、サーバとしてはしばしばその仕事量に 圧倒されている様に見えました。 この状況は、ネットワークトラフィックを高速化するネットワークスイッチを設置することで一部解消することは可能でしたが、 結果としておそらくは高速化したトラフィックの要求に必死でついて行こうとするサーバPC のボトルネックを作り出した 事でしょう。 その PC は Windows98 を走らせていました。 これは、デスクトップ環境としては全く問題ないのですが、サーバとしてとなるととたんに「苦闘」し始めるという代物です。 つまり、特にネットワークがこのまま拡大し続けるのであれば、 この選択肢はせいぜいしばらく問題を先送りにするだけのその場しのぎであると思われたのです。

交換

サーバ PC を専用のサーバと交換し、クライアントサーバの関係を構築すれば、予想されるネットワークの規模とトラフィック を許容できたでしょう。 ここでの(専用サーバの)選択肢は WindowsNT か NetWare のどちらかであり、専用のサーバとは伝統的に多額の出費を伴うものでした。 近年、Linux が大変注目されるようになり、別の交換戦略をもたらしました。

Linux の選択

Linux は UNIX クローンであり、それ自体に UNIX の 卓越したネットワーク能力を内包しています。 Linux がインターネットサーバ市場での採用を増やしているのは、この特色(他のものとくらべての)によるものです。 Linux は、その時我々が直面していた問題に対して安価な交換戦略を提供し、 さらには非常に低コスト、あるいは全くのただで予想されたネットワークの拡大への対応も可能でした。

Linux が効果的でコスト的にも優れたサーバソリューションであることに疑問はありませんでしたが 私達はそれがはたしてこのケースにおいての特効薬となりうるのかどうか知る必要がありました。 Linux は、ファイルサービス、社内メール、ネットワーク FAX、インターネットメールの再配信などを含めた 従来のサーバPC が提供していた役割をすべてこなすことができるのか、ということです。 初期調査で、それが可能であることが明らかになり、問題は「Linux にその能力があるか?」という事から「私が Linux でそれを実現できるのか?」という事へと変化しました。

調査が大切です

経営陣に対して採用を提言する前に、その内容について調査する事が賢明であると思われました。 そして私は Linux の管理についてより深く詳細を学ぶ決心をしました。 私は家でたった2、3ヶ月使用しただけですが Linux を経験しており、また会社では Linux は使われていなかったので 事実上、社内では私が Linux のエキスパートだったのです。

私はまずニュースグループ、特に uk.comp.os.linux (u.c.o.l.) に投稿された記事をひたすら読むことで調査を開始しました。 この様にニュースグループで投稿もせずに読んでばかりいるとグループによっては嫌がられるかも知れませんが、 この様なプロジェクトの初期の段階ではお薦めの方法です。 他の人の質問や回答を読めば、将来遭遇するかも知れないプロジェクトにアプローチする貴重な洞察力を得る事が できます。 他人の失敗から学ばない人は愚か者であるといわれます。 さらに私は O'Reilly ()刊「Learning Red Hat Linux」という本を持っていました。 この本は、家で Linux をインストールする時に利用したのですが、このプロジェクトの為にはすばらしい本です。 この本には、Samba についての重要な章がありました。Samba は Linux を Windows9x のためのファイルサーバとして動作させることのできるネットワークアプリケーションです。 Linux Documentation Project(LDP - ) も広範囲にわたって利用しました。 特に、Linux ユーザーズガイド、システム管理者ガイド、ネットワーク管理者ガイドを利用しました。

読み進める事の重要性

全体的に成果を収めるための調査の重要性についてはいくら強調してもし足りないくらいです。 「備えあれば憂いなし」や五つの P(Proper preparation prevents poor performance: 適切な準備によって低性能を防ぐことができる) といったものも含め、このことを端的に表現した沢山の言い回しや逸話があります。

ツール

初期調査によって、私が進むべき方向と、私がより多く学ばなくてはならない特定のプログラムが明らかになりました。 代表例はこれらのプログラムです:-

Samba (ファイルとプリンタの共有サービス), qmail (メールの配信 - MTA) fetchmail (契約プロバイダのメールボックスからメールを集める) mgetty+sendfax または HylaFAX (FAXサーバ)

他にも候補があったものの、これらが最もお薦めであり、u.c.o.l(ニュースグループ uk.comp.os.linux の事)への問い合わせで、良い選択であることを確認しました。 (u.c.o.l ユーザ達のアドバイス同様に私の助けとなった)Linux Journal の記事で、ネットワーク FAX サービスが 可能でしかもそのツールが利用可能である事は分かっていました。

上司を納得させる

これは、初期の段階で最も心配な仕事の一つとなりました。 Linux こそ最適な解決法であると私自身が認識する事と、上司達を同じ結論へと導くことを考えると言う事は、全く別の事でした。

額面上は経費(常に立ちはだかる大きな障害ですが)はかからないのですが時間の問題がありました。 このプロジェクトは私にとって学びながら進めるのに相当な時間を要し、転じて事態の解決にいたるまでには 全体として長い時間がかかるであろうと予想されました。

現状の欠点をあげつらって、その上で全てを克服する英雄として Linux を提案するという誘惑に かられました。 しかしこれはうまくいきそうにありませんでした。 なぜなら、単にそのアイデアを気に入っているという理由だけで、ある解決案を押し進めていると受け取られかねないからです。 さらに、この論法で主張した場合 Linux サーバを配備する上でのいかなる遅延も説明しがたいものとなったでしょう。 私はこの議案を、会社にとって利益をもたらすものとして提案しなければなりませんでした。 この目的のためには、現存する問題点を使う事もできましたが、「Linux のための Linux」という姿勢にならないよう 気をつけなければなりませんでした。

偶然にも、私の心配は全く無用でした。というのは、現在のサーバについて話しているとき、IT の管理者が まさに私が論じようと思っていたのと全く同じ解決案を出したのです! 彼は、私がここに書いた様なものと同様の内容についての確信を得ようとしていました。 あなた方の状況はもちろん同じではないでしょうが、いかなるケースにおいても、議論を可能な限り客観的に 進めるというやりかたは間違いなく有益なものとなるはずです。

どのディストリビューションにするか?

私は、このプロジェクトに RedHat 6.0 を選びました。 理由はいたって簡単で、すでに持っていたので素早く始められるからです。 また、家で使用していたので馴染みがあった、という理由もあります。 私が思うに、他のものに比べてある特定のディストリビューションを使うべきだといった様な実質的な理由は 個人的な好みを除いてはありません。 色々なディストリビューションにいくつかのサーバ版がありますが、ここでもやはり個人的な好みの領域です。 私は、色々なディストリビューションについてあまり経験がありませんので、特にどれかを推薦するような資格は ないと思われます。あえてアドバイスするとすれば、未知の部分をできるだけ無くしたいと考えるがゆえに 異なるディストリビューションの微妙な違いを学んでゆくと、それが新たな悩みのタネを生み出すかもしれない、 という事です。

インストール RedHat

私は IT の倉庫に転がっていたかけらを寄せ集めて PC を組み立てました - それは楽しいトレーニングでしたが - 最終的には P133(訳注:Pentium133MHz)、32MB の RAM、540MB のハードディスクで構成された試用システムが出来上がりました。 ハードディスクはもっと大きなものに交換する予定でしたが、 まずはその前にインストールのテストを行ないたかったのです。

以前に2、3回 RH6(訳注:RedHat Linux 6.0)をインストールしたことがあったので、私は(インストールなど)朝飯前であろうという事を "知って" いました.....「さて、それはどうかな?」そんなフレーズがぴたりとはまる事態となりました。 (原文:I believe &dquot;famous last words&dquot; is the phrase I am looking for!) インストールはうまくいったように見えましたが、初回の起動時(続いて次回もその次も)システムが Linux を展開しようとする時に &dquot;不正な圧縮フォーマットです(Invalid compressed format)&dquot; というエラーに遭遇しました。 そして起動時に &dquot;LI&dquot; とプロンプト表示し、システムがハングするようになりました。 u.c.o.l ではいくつかの質問でこれはドライブジオメトリの問題である、 と取り上げられていました。 LOADLIN から Linux にアタッチする MS-DOS のブートディスクからシステムを起動する事はできましたが とても容認できるやり方ではありませんでした。 その代わりに、1GB のハードディスクを使うことにしました。

次は NIC(訳注:この場合、いわゆる LAN カード)の問題が起こりました。 最初に使ったのは Realtek8019 ISA カードでした。これは NE2000 互換のカードだったので NE2000 のドライバを使う "べき" でした。 何度試してみても、カーネルの再コンパイルまでしても、このカードはそのドライバで動作しなかったので 他の PC に差さっていた D-Link DT-530 PCI カードと入れ替えました。 このカードは "tulip" ドライバで動作するという報告がありました。 ところが、RedHat のインストーラでは検出できませんでした。 D-Link のウェブサイトを覗いてみると、最新の via-rhine ドライバを使えば解決するとありました。 同サイト()の pci-scan driver file に沿って、このドライバをダウンロード、コンパイル、インストールしました。 このサイトにはインストールに関する素晴らしい解説も用意されていました。 新しいドライバでこのマシンは立ち上がり、2、3回 ping を打って NIC が正常に動いている事が確認できました。

Samba

RedHat をインストールする時に Version 2.0.3 が一緒に組み込まれました。 とりあえずのテストだったので最新バージョン(これを書いた時点では 2.0.7)をダウンロードする理由はとくに 見当たりませんでした。 Linux マシンから Windows PC の共有資源にアクセスする必要はないので smbclient はインストールしませんでした。 901 番ポートをウェブブラウザで指定(例: http://localhost:901)してアクセスできる SWAT ユーティリティのおかげで設定はいたって簡単でした。 このユーティリティにはネットワークを通じて Windows のマシンからさえもアクセス(http://<IPアドレス>:901) し、設定することが可能でした。

Samba の設定

諸般の事情により、私の会社のユーザ達は - しばしばそれが可能であったにもかかわらず - 習慣的にあまり ワークグループ外のネットワークをうろうろしませんでした。 彼らのテリトリーを混乱させない様に、またアクシデントを最小限にとどめるため、サーバはサーバ自身のワークグループ に置きました。 Sambaのセットアップと設定についてはたくさんの素晴らしい文書がありますので、ここでその内容を繰り返すより それらの文献を紹介することとします。

会社の PC は全て固定の IP アドレスを持っており、ユーザ達は原則的に同じ PC の前に毎日座っていたので 私は Samba の共有セキュリティオプション を選択しました。 これは、ネットワークを参照する誰にでもリソースを開きっぱなしにするという危険をはらんでいたので、同時に グローバルセクション(the global section)でホスト認証(host-allow)機能を使用しました。 ホスト認証は一部の IP アドレスを使用する私達のネットワーク内の人間に限定されました。 共有は様々なディレクトリに対して、全て新しい /resources ディレクトリの下にポインタが作成されました。

Microsoft Word テンプレート

MS Word97 のテンプレートに関する以外、全ての共有はうまくいきました。 MS Word はオプションとして Workgroup Templates の場所を設定する機能を持っています。 この問題はその場所の参照先が Samba の共有であった場合には、例えば //SERVER/template の様なトップレベル上に 共有ポインタを置けないというものでした。 MS Word で「ファイル」 - 「新規作成」をクリックすると「その場所のテンプレートを開くことができません。」と 言ってくるのです。「ファイル」 - 「開く」では開くことが可能であるにもかかわらず、です。 さらに混乱することに、エクスプローラで例のトップレベル上の共有ディレクトリを開き、テンプレートをダブルクリック すると、そのテンプレートを元にした新規文書を作成することができました。 結局、単純にテンプレートの親ディレクトリを共有し、そのパスを経由して(例: //SERVER/resource/template)テンプレートを 見に行くように設定すると動作する事が分かりました。 ファイルのパーミッションやユーザ名を修正を幾度となく修正してみましたが、どうやらそれが唯一の方法でした。 原因がどちらにあるのかについては、未だにはっきりと分かりません。他のファイルは問題なく使えるので、MS Word が 犯人であるように思えますが、Windows のトップレベル共有では問題がない事から考えると Samba もまた疑わしいのです。

E-mail

Mail Transport Agent (MTA) として RedHat 付属の sendmail ではなく qmail が選ばれました。 この主な理由は、qmail の方が、sendmail よりも設定の容易さや良好なセキュリティという点において世間で評判が良かったからです。

qmail

のミラーサイトから最新のソースファイルをダウンロードし、コンパイルしてインストールしました。 qmail には大量の文書が付属してきましたが私は Life With Qmail () も利用しました。 この文書は HOWTO 物のような感じで、私達の目的のためにおそらく最も役立つ文書でした。

qmail は簡単にインストールできましたが、使用中に2、3の小さなトラブルに遭遇しました。 私は、パフォーマンスと信頼性の理由から、Maildir をデフォルトの配達に使うように設定しました。 古き良き標準的なメールプログラムはこのような形の配達を認識しませんでしたので、どうして私のメールが 送り届けられるのかを理解しようと時間をかけましたが、分かりませんでした。 その解決法は Maildir をサポートする mutt ()を使うことでした。 もちろんこれは、メールを読むのに Linux マシンではなく Windows のワークステーション上で POP クライアント (MS Outlook)を使うユーザ達にとってはなんでもない問題でした。

fetchmail

fetchmail はメールの収集に使われ、インストールと設定は非常に容易でした。特に fechmailconf について理解した時は:o)。 常時メールを収集する必要はありませんが、設定した周期で行ないたかったのです。 これを容易にするためには、毎日 cron job で fetchmail を -d オプションを付けて呼び出し、もう一方で 停止させるようにすればよいのです。

メールはネット上のホストにある 10個のメールボックスから収集されていました。 そのうちの一つはまるまる私たちのホスト名宛のものを転送するものでしたが、のこり 9 つの指定されたアドレスに対しては 預けられていました。 このメールボックスから全てをダウンロードし、受取人アドレスを使って qmail に SMTP 転送する為に fetchmail のマルチドロップ機能が使われました。 新しい qmail サーバから営業所の店員にメールを送る時、問題が起こりました。 彼らは、ネット上のホストから直接メールを読み込むのですが、彼らのドメイン名は社内の他のドメイン名と同じなのです。 したがって、(オフィス内の)ローカルユーザが(営業所の)店員の一人にメールを送ろうとするたびに qmail はメッセージを 送る為にローカルユーザ名を探し、該当するユーザがいないので、メールサーバの管理人に送りかえすという事になってしまいました。 これは、店員達のもう一つのメールアドレスに送信することで解決しました。 私達が使っていたネット上のホストはダイアルアップサービスを提供していなかったので、店員達は WEB にアクセスする為に 各自で無料 ISP(訳注:Internet Service Provider インターネットサービスプロバイダ)のアカウントを持っていました。 そのため店員達は別のドメインにアドレスを持っていたので、qmail は全てのメールをそのアドレスにエイリアスファイル を使って転送することができました。

注釈: 営業所の店員達の人生を過ごしやすくするため、私達が使っているネット上のホストは彼ら宛てに届くメールを全て 無料 ISP のメールアドレスに転送しました。これにより、店員達はノートパソコン上で複数のアカウントやアドレスを お手玉して "混乱" せずに済みました。彼らに幸あれ :o)

ファックス

古いサーバ PC は Microsoft Network の FAX 機能を使って ネットワーク経由で FAX サービスを共有していました。 ユーザ達は MS Word の(VBA マクロが入った)テンプレートを使って自動的に FAX を作成/送信し、エラーはユーザにメールで通知されました。 新しいサーバで、前より良くならないまでも同等のサービスを提供するために、ローカル FAX サービスとして mgetty と sendfax の組合せを選択しました。 インストールは簡単で、すぐに Linux サーバからの FAX はスプールできる様になりました。 Windows クライアントからの FAX に関しては比べものにならないほど困難で、結局別の選択をせざるを得なく なりました。

Windows クライアントからの FAX

以前の構成では、全ての Windows クライアントに FAX サービスを提供するために MS Outlook で Microsoft Fax を使ってサーバ PC から FAX モデムを共有していました。 これに付け加えて、自動的に FAX 送信する機能を持った標準の Word97 テンプレートを使用していました。 VBA の Sendfax コマンドを使ったこのマクロで、ユーザ達はテンプレートの項目を埋めて、Word のツールバーにある &dquot;今すぐ FAX を送信する&dquot; というボタンを押すだけで FAX を送信することができました。 たった今テンプレートに入力したばかりの内容を、全て繰返し入力しなければならないようないかなるサードパーティ製の プログラムを使わなくても済んだのです。 このようにして、以前のこの構成ではユーザ達にシームレスな FAX 送信を提供しており、私はなんとしてもこの環境を 継続すべきだと考えていました。

理想的には、送信したい文書、ユーザ名そして FAX 番号を Windows クライアントのアプリケーションから Linux サーバの faxspool に渡す何らかの方法が必要でした。 あらゆる Windows アプリケーションに FAX サービスを提供する伝統的な方法は、FAX モデムを "プリンタ" として設定するというものです。

HylaFAX

最初は、mgetty と sendfax の組合せを FAX サーバとして使うようにインストールしました。 このようにした主な理由は、この組合せは RedHat 6 に付属しておりすぐに使える状態だったからです。 ところが運の悪いことに この組合せは Microsoft Word マクロを使って FAX を FAX サーバに送信するという用途には 適していないことがわかりました。 mgetty と sendfax の組合せを使える素晴らしい Windows クライアントはいくつかあったのですが、悲しいかなこれらは 全て、FAX を送信する度にユーザが毎回 FAX 番号などの入力をしなければならないものだったのです。 ユーザが Word のテンプレートに入力してボタンを押したらマクロがその文書の中から FAX 番号を読みとり、 VBA の Sendfax コマンドを使って MS Fax 経由で FAX を送信するという当時の環境にマッチする解決方法が必要でした。

検討と調査を重ねた結果、私は WHFC() という Windows クライアントを持つ HylaFAX () に目をつけました。 このクライアントは VBA マクロ経由での通信をサポートしており、まさに私が望む通りのものでした。 若干頭の痛いクライアントアクセスの問題はあったものの Hylafax は正常にインストールできました。 この問題は、クライアントの IP アドレスを /var/spool/fax/etc/hosts だけでなく /var/spool/fax/etc/hosts.hfaxd にも正しく追加されていることを確認することで解決しました。 一旦設定してしまえば実用を開始するのに時間は全くかかりませんでした。 WHFC は非常に簡単にインストールでき、あっという間に設定できたのです。

Word のマクロ

すでに述べた通り、ユーザ達は MS Word97 でボタン一つで FAX 文書を送信するのに慣れていたので、新しいサーバでも この機能が使えるようにするのは重要な事でした。 WHFC は OLE 互換なので、FAX 送信に必要な情報を入力するために新しいポップアップボックスを出したりせずに FAX を送信できるようにするための新しいマクロを書く事が可能でした。 このマクロは二つの事をします - まず、現在の文書を印刷イメージとしてファイルに保存し、次に WHFC の SendFax OLE 機能 を使って印刷イメージファイルを HylaFAX に送信します。 WHFC のセットアップノートで推奨されていたので、プリンタドライバには Apple Laserwriter 16/600(ps) を使いました。

ここに、私達が使ったマクロのコーディングを書きます ...

Sub Spool_fax() ' Spool_fax マクロ ' マクロ作成日:09/08/00 作成者:Ryan Cartwright Dim givenfax, realnum As String Dim whfc As Object Dim OLE_Return As Long Dim Box_Return As Integer ' まずローカルファイルに文書を印刷します - Background プロパティが False でなければならない点に注意してください。 ' さもなければこの機能はファイルを完全に書き込む前に終了してしまい、HylaFAX は正しく文書を変換できません。 Application.PrintOut FileName:=&dquot;&dquot;, Range:=wdPrintAllDocument, Item:= _ wdPrintDocumentContent, Copies:=1, Pages:=&dquot;&dquot;, PageType:=wdPrintAllPages, _ Collate:=True, Background:=False, PrintToFile:=True, _ OutputFileName:=&dquot;c:\faxtemp\printout.ps&dquot;, Append:=False ' テンプレート内で Autonew マクロにより FAX 番号等を質問されるようになっています。 ' FAX 番号のフィールド番号は 8 なので、ここの内容を取り込んでその前に 9 をくっつけます。 Set givenfax = ActiveDocument.Fields(8).Result realnum = &dquot;9&dquot; + givenfax ' OLE オブジェクトを作成し Sendfax() サブルーチンを呼び出します。 Set whfc = CreateObject(&dquot;WHFC.OleSrv&dquot;) OLE_Return = whfc.SendFax(&dquot;c:\faxtemp\faxoutput.ps&dquot;, realnum, False) ' 最後に、戻り値のテストを行ない、その内容にしたがって通知します。 If OLE_Return <= 0 Then Box_Return = MsgBox(&dquot;Error sending file&dquot;, 16, &dquot;FAX Not Spooled&dquot;) Else Box_Return = MsgBox(&dquot;Fax Job ID:&dquot; & OLE_Return & Chr(13) & "You will be notified by email if it was successfully sent", 0, "Fax spooled") End If Set whfc = Nothing End Sub

これで完璧?

これで、新しいサーバを立ち上げて運用するために必要なツールやユーティリティのインストールと設定について きちんとカバーできました。 要求された通りの仕事をこなすだけの単なるツールよりも、良いサーバのためになるものがまだまだあります。 前にも触れた、Linux システム管理者ガイド(Linux System Administrators Guide)、特に 10 章を読むことを お薦めします。ためになりますよ!

結論

Linux サーバはこのプロジェクトをスタートしておよそ 2ヶ月くらいで稼働し始めました。 もし内容がわかっていれば、この期間は数日で済んだに違いありませんが、もし似たようなプロジェクトを考えているなら 十分な時間的余裕をもって実行することをお薦めします。 私のように、Windows における彼らのサポート工数を低減するなら、とりわけ適切です。 (Windows に比べて)Linux は使うのが難しいのではなく、単に違うのです。そして Windows からの移行には時間がかかります。 始める前に、周りにある素晴らしい文書を読んでください。 そして、現在の古いサーバを運用したまま、別のマシンで少しずつこれらを試していった方が有益であると思います。 段階的に移行する方が、直接置き換えるよりもよいアプローチです。

参考文献

Linux Documentation Project - Freshmeat - qmail - HylaFAX - Samba -

日本語化について

本ドキュメントの日本語への翻訳に対し快諾いただき、また誤解されやすい表現について貴重なアドバイスをしてくださった 著者の Ryan Cartwright 氏 <cimperman@enterprise.net> に感謝します。 このドキュメントの原文は以下にあります。

LDP(Linux Documentation Project)のサイト: 上記サイト内 Linux-LAN-Server HOWTO:

また、日本語化にあたっては JF-MLのメンバーの方々より、様々なアドバイスや指摘等をいただきましたので感謝とともにここに紹介します。

川嶋 勤さん <kawawa@mail.interq.or.jp> 水原 さん <mizuhara@acm.org> 千旦裕司さん <ysenda@pop01.odn.ne.jp> Konkitiさん <konkiti@lares.dti.ne.jp> 山下義之さん <dica@eurus.dti.ne.jp> 武井伸光さん <takei@webmasters.gr.jp>