■レンタルサーバご利用参考資料
サーバご利用の参考にJF Project によるJF (Japanese FAQ)を掲載しています。
Linux JF(Japanese FAQ)Project.
JF は, Linux に関する解説文書・FAQ などを作成・収集・配布するプロジェクトです.
グリーンネット・トップページへ戻る
一覧に戻る
Windows LAN server HOW-TO
by Ryan Cartwright, crimperman@enterprise.net
v0.1, 21 September 2000
翻訳：瀬戸口 崇 setzer@mx3.tiki.ne.jp
日本語訳：2000 年 11 月 15 日
このドキュメントは Windows9x を走らせているコンピュータのあるオフィス
で Linux を サーバにしたいと願っている人々の手助けになることを意図した
ものです。
______________________________________________________________________
目次
1. 献辞
2. 序章
2.1 筋書き
2.2 選択肢
2.2.1 修理
2.2.2 交換
3. Linux の選択
3.1 調査が大切です
3.1.1 読み進める事の重要性
3.2 ツール
3.3 上司を納得させる
3.4 どのディストリビューションにするか?
4. インストール
4.1 RedHat
4.2 Samba
4.2.1 Samba の設定
4.2.2 Microsoft Word テンプレート
4.3 E-mail
4.3.1 qmail
4.3.2 fetchmail
4.4 ファックス
4.4.1 Windows クライアントからの FAX
4.4.2 HylaFAX
4.4.3 Word のマクロ
5. これで完璧？
6. 結論
7. 参考文献
8. 日本語化について
______________________________________________________________________
1. 献辞
第一に、本書を、わが救世主たるイエス・キリストに捧げます。この仕事をや
り遂げた能力は、主によって与えられたからです。第二に、本書を、本書に登
場する様々なユーティリティとドキュメントの作成者達に捧げます。それをや
り遂げたツールは、かれらによって与えられたからです。
2. 序章
職場での Linux の人気はますます高まっています。主に、サーバレベルでの
インターネットの市場で展開されていますが、内部ネットワークサーバやワー
クステーションなどの他の分野へも拡大しはじめています。このような状況を
鑑み、また後で述べるような理由もあり、私の会社は Windows9x ベースの
ネットワークに Linux ベースの LAN サーバを配備することにしました。私は
Linux の基本的な知識と UNIX の いくらかの知識をもって、このプロジェク
トに着手しました。このプロジェクトを通して私は、この仕事の内容について
書かれたある種のドキュメントがあれば役に立つだろうと感じました。そして
その類のドキュメントを見つけられなかったので、書く事にしたのです。
使用した様々なツールやユーティリティのインストールや設定について、ここ
で改めて解説するような事はしていません。そのような説明を繰り返す事は私
には意味がありませんのでその代わり、インストールや設定の時に遭遇した問
題やそのような場合の解決法をドキュメントに含める事にしました。
2.1. 筋書き
新しいサーバが設置される前の環境に関する背景を少し説明しておいた方が良
いでしょう。
およそ35台の PC が広い敷地内を横切った Ethernet LAN で繋がっています。
多くのオフィスと同じように、最初は1台の PC から始まり、少しずつ拡大し
て現在の環境になりました。スピードや利便性、コストの面から ピアツーピ
ア(peer to peer)ネットワークが採用されました。共有レベルのアクセスを利
用して、ユーザ達はネットワーク越しにディレクトリやプリンタを共有してい
ます。
それらの PC の内の1つが "サーバ" と称されるようになりました。 (これ以
降、これの事を "サーバ 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 を再起動する間、他のユー
ザは大切なファイルにアクセスができなくなるうえ、再びアクセスできるよう
にデータベースやファイルの排他共有ロックを解除しなければなりませんでし
た。
2.2. 選択肢
この状況では何らかの救済手段が必要でした。最も基本的なレベルの選択肢
は、「修理、あるいは交換」ですが、ありがちな事にそれには予算上の制限が
ありました。
2.2.1. 修理
修理する、というのは一見最も迅速かつ安価な選択肢ですが、大抵の場合、特
に正確な原因が判明していない場合には容易な事ではありません。ワークス
テーションとしてはこの PC には何の問題もないのですが、サーバとしてはし
ばしばその仕事量に圧倒されている様に見えました。この状況は、ネットワー
クトラフィックを高速化するネットワークスイッチを設置することで一部解消
することは可能でしたが、結果としておそらくは高速化したトラフィックの要
求に必死でついて行こうとするサーバPC のボトルネックを作り出した事で
しょう。その PC は Windows98 を走らせていました。これは、デスクトップ
環境としては全く問題ないのですが、サーバとしてとなるととたんに「苦闘」
し始めるという代物です。つまり、特にネットワークがこのまま拡大し続ける
のであれば、この選択肢はせいぜいしばらく問題を先送りにするだけのその場
しのぎであると思われたのです。
2.2.2. 交換
サーバ PC を専用のサーバと交換し、クライアントサーバの関係を構築すれ
ば、予想されるネットワークの規模とトラフィックを許容できたでしょう。こ
こでの(専用サーバの)選択肢は WindowsNT か NetWare のどちらかであり、専
用のサーバとは伝統的に多額の出費を伴うものでした。近年、Linux が大変注
目されるようになり、別の交換戦略をもたらしました。
3. Linux の選択
Linux は UNIX クローンであり、それ自体に UNIX の 卓越したネットワーク
能力を内包しています。 Linux がインターネットサーバ市場での採用を増や
しているのは、この特色(他のものとくらべての)によるものです。 Linux
は、その時我々が直面していた問題に対して安価な交換戦略を提供し、さらに
は非常に低コスト、あるいは全くのただで予想されたネットワークの拡大への
対応も可能でした。
Linux が効果的でコスト的にも優れたサーバソリューションであることに疑問
はありませんでしたが私達はそれがはたしてこのケースにおいての特効薬とな
りうるのかどうか知る必要がありました。 Linux は、ファイルサービス、社
内メール、ネットワーク FAX、インターネットメールの再配信などを含めた従
来のサーバPC が提供していた役割をすべてこなすことができるのか、という
ことです。初期調査で、それが可能であることが明らかになり、問題は
「Linux にその能力があるか?」という事から「私が Linux でそれを実現でき
るのか?」という事へと変化しました。
3.1. 調査が大切です
経営陣に対して採用を提言する前に、その内容について調査する事が賢明であ
ると思われました。そして私は 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 ユーザーズガイド、システム管理者ガイド、ネットワーク管
理者ガイドを利用しました。
3.1.1. 読み進める事の重要性
全体的に成果を収めるための調査の重要性についてはいくら強調してもし足り
ないくらいです。「備えあれば憂いなし」や五つの P(Proper preparation
prevents poor performance: 適切な準備によって低性能を防ぐことができる)
といったものも含め、このことを端的に表現した沢山の言い回しや逸話があり
ます。
3.2. ツール
初期調査によって、私が進むべき方向と、私がより多く学ばなくてはならない
特定のプログラムが明らかになりました。代表例はこれらのプログラムです:-
o Samba (ファイルとプリンタの共有サービス),
o qmail (メールの配信 - MTA)
o fetchmail (契約プロバイダのメールボックスからメールを集める)
o mgetty+sendfax または HylaFAX (FAXサーバ)
他にも候補があったものの、これらが最もお薦めであり、u.c.o.l(ニュースグ
ループ uk.comp.os.linux の事)への問い合わせで、良い選択であることを確
認しました。 (u.c.o.l ユーザ達のアドバイス同様に私の助けとなった)Linux
Journal の記事で、ネットワーク FAX サービスが可能でしかもそのツールが
利用可能である事は分かっていました。
3.3. 上司を納得させる
これは、初期の段階で最も心配な仕事の一つとなりました。 Linux こそ最適
な解決法であると私自身が認識する事と、上司達を同じ結論へと導くことを考
えると言う事は、全く別の事でした。
額面上は経費(常に立ちはだかる大きな障害ですが)はかからないのですが時間
の問題がありました。このプロジェクトは私にとって学びながら進めるのに相
当な時間を要し、転じて事態の解決にいたるまでには全体として長い時間がか
かるであろうと予想されました。
現状の欠点をあげつらって、その上で全てを克服する英雄として Linux を提
案するという誘惑にかられました。しかしこれはうまくいきそうにありません
でした。なぜなら、単にそのアイデアを気に入っているという理由だけで、あ
る解決案を押し進めていると受け取られかねないからです。さらに、この論法
で主張した場合 Linux サーバを配備する上でのいかなる遅延も説明しがたい
ものとなったでしょう。私はこの議案を、会社にとって利益をもたらすものと
して提案しなければなりませんでした。この目的のためには、現存する問題点
を使う事もできましたが、「Linux のための Linux」という姿勢にならないよ
う気をつけなければなりませんでした。
偶然にも、私の心配は全く無用でした。というのは、現在のサーバについて話
しているとき、IT の管理者がまさに私が論じようと思っていたのと全く同じ
解決案を出したのです! 彼は、私がここに書いた様なものと同様の内容につ
いての確信を得ようとしていました。あなた方の状況はもちろん同じではない
でしょうが、いかなるケースにおいても、議論を可能な限り客観的に進めると
いうやりかたは間違いなく有益なものとなるはずです。
3.4. どのディストリビューションにするか?
私は、このプロジェクトに RedHat 6.0 を選びました。理由はいたって簡単
で、すでに持っていたので素早く始められるからです。また、家で使用してい
たので馴染みがあった、という理由もあります。私が思うに、他のものに比べ
てある特定のディストリビューションを使うべきだといった様な実質的な理由
は個人的な好みを除いてはありません。色々なディストリビューションにいく
つかのサーバ版がありますが、ここでもやはり個人的な好みの領域です。私
は、色々なディストリビューションについてあまり経験がありませんので、特
にどれかを推薦するような資格はないと思われます。あえてアドバイスすると
すれば、未知の部分をできるだけ無くしたいと考えるがゆえに異なるディスト
リビューションの微妙な違いを学んでゆくと、それが新たな悩みのタネを生み
出すかもしれない、という事です。
4. インストール
4.1. RedHat
私は IT の倉庫に転がっていたかけらを寄せ集めて PC を組み立てました -
それは楽しいトレーニングでしたが - 最終的には P133(訳
注:Pentium133MHz)、32MB の RAM、540MB のハードディスクで構成された試用
システムが出来上がりました。ハードディスクはもっと大きなものに交換する
予定でしたが、まずはその前にインストールのテストを行ないたかったので
す。
以前に2、3回 RH6(訳注:RedHat Linux 6.0)をインストールしたことがあった
ので、私は(インストールなど)朝飯前であろうという事を "知って" いまし
た.....「さて、それはどうかな?」そんなフレーズがぴたりとはまる事態とな
りました。 (原文:I believe "famous last words" is the phrase I am
looking for!) インストールはうまくいったように見えましたが、初回の起
動時(続いて次回もその次も)システムが Linux を展開しようとする時に "不
正な圧縮フォーマットです(Invalid compressed format)" というエラーに遭
遇しました。そして起動時に "LI" とプロンプト表示し、システムがハングす
るようになりました。 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 が正常に動いている事が確認できました。
4.2. Samba
RedHat をインストールする時に Version 2.0.3 が一緒に組み込まれました。
とりあえずのテストだったので最新バージョン(これを書いた時点では 2.0.7)
をダウンロードする理由はとくに見当たりませんでした。 Linux マシンから
Windows PC の共有資源にアクセスする必要はないので smbclient はインス
トールしませんでした。 901 番ポートをウェブブラウザで指定(例:
http://localhost:901)してアクセスできる SWAT ユーティリティのおかげで
設定はいたって簡単でした。このユーティリティにはネットワークを通じて
Windows のマシンからさえもアクセス(http://:901) し、設定す
ることが可能でした。
4.2.1. Samba の設定
諸般の事情により、私の会社のユーザ達は - しばしばそれが可能であったに
もかかわらず - 習慣的にあまりワークグループ外のネットワークをうろうろ
しませんでした。彼らのテリトリーを混乱させない様に、またアクシデントを
最小限にとどめるため、サーバはサーバ自身のワークグループに置きました。
Sambaのセットアップと設定についてはたくさんの素晴らしい文書があります
ので、ここでその内容を繰り返すよりそれらの文献を紹介することとします。
会社の PC は全て固定の IP アドレスを持っており、ユーザ達は原則的に同じ
PC の前に毎日座っていたので私は Samba の共有セキュリティオプション を
選択しました。これは、ネットワークを参照する誰にでもリソースを開きっぱ
なしにするという危険をはらんでいたので、同時にグローバルセクション(the
global section)でホスト認証(host-allow)機能を使用しました。ホスト認証
は一部の IP アドレスを使用する私達のネットワーク内の人間に限定されまし
た。共有は様々なディレクトリに対して、全て新しい /resources ディレクト
リの下にポインタが作成されました。
4.2.2. Microsoft Word テンプレート
MS Word97 のテンプレートに関する以外、全ての共有はうまくいきました。
MS Word はオプションとして Workgroup Templates の場所を設定する機能を
持っています。この問題はその場所の参照先が Samba の共有であった場合に
は、例えば //SERVER/template の様なトップレベル上に共有ポインタを置け
ないというものでした。 MS Word で「ファイル」 - 「新規作成」をクリック
すると「その場所のテンプレートを開くことができません。」と言ってくるの
です。「ファイル」 - 「開く」では開くことが可能であるにもかかわらず、
です。さらに混乱することに、エクスプローラで例のトップレベル上の共有
ディレクトリを開き、テンプレートをダブルクリックすると、そのテンプレー
トを元にした新規文書を作成することができました。結局、単純にテンプレー
トの親ディレクトリを共有し、そのパスを経由して(例:
//SERVER/resource/template)テンプレートを見に行くように設定すると動作
する事が分かりました。ファイルのパーミッションやユーザ名を修正を幾度と
なく修正してみましたが、どうやらそれが唯一の方法でした。原因がどちらに
あるのかについては、未だにはっきりと分かりません。他のファイルは問題な
く使えるので、MS Word が犯人であるように思えますが、Windows のトップレ
ベル共有では問題がない事から考えると Samba もまた疑わしいのです。
4.3. E-mail
Mail Transport Agent (MTA) として RedHat 付属の sendmail ではなく
qmail が選ばれました。この主な理由は、qmail の方が、sendmail よりも設
定の容易さや良好なセキュリティという点において世間で評判が良かったから
です。
4.3.1. qmail
のミラーサイトから最新のソースファイルをダウン
ロードし、コンパイルしてインストールしました。 qmail には大量の文書が
付属してきましたが私は Life With Qmail (
) も利用しました。この文書は
HOWTO 物のような感じで、私達の目的のためにおそらく最も役立つ文書でし
た。
qmail は簡単にインストールできましたが、使用中に2、3の小さなトラブルに
遭遇しました。私は、パフォーマンスと信頼性の理由から、Maildir をデフォ
ルトの配達に使うように設定しました。古き良き標準的なメールプログラムは
このような形の配達を認識しませんでしたので、どうして私のメールが送り届
けられるのかを理解しようと時間をかけましたが、分かりませんでした。その
解決法は Maildir をサポートする mutt ( )を使うこ
とでした。もちろんこれは、メールを読むのに Linux マシンではなく
Windows のワークステーション上で POP クライアント (MS Outlook)を使う
ユーザ達にとってはなんでもない問題でした。
4.3.2. fetchmail
fetchmail はメールの収集に使われ、インストールと設定は非常に容易でし
た。特に fechmailconf について理解した時は:o)。常時メールを収集する必
要はありませんが、設定した周期で行ないたかったのです。これを容易にする
ためには、毎日 cron job で fetchmail を -d オプションを付けて呼び出
し、もう一方で停止させるようにすればよいのです。
メールはネット上のホストにある 10個のメールボックスから収集されていま
した。そのうちの一つはまるまる私たちのホスト名宛のものを転送するもので
したが、のこり 9 つの指定されたアドレスに対しては預けられていました。
このメールボックスから全てをダウンロードし、受取人アドレスを使って
qmail に SMTP 転送する為に fetchmail のマルチドロップ機能が使われまし
た。新しい qmail サーバから営業所の店員にメールを送る時、問題が起こり
ました。彼らは、ネット上のホストから直接メールを読み込むのですが、彼ら
のドメイン名は社内の他のドメイン名と同じなのです。したがって、(オフィ
ス内の)ローカルユーザが(営業所の)店員の一人にメールを送ろうとするたび
に qmail はメッセージを送る為にローカルユーザ名を探し、該当するユーザ
がいないので、メールサーバの管理人に送りかえすという事になってしまいま
した。これは、店員達のもう一つのメールアドレスに送信することで解決しま
した。私達が使っていたネット上のホストはダイアルアップサービスを提供し
ていなかったので、店員達は WEB にアクセスする為に各自で無料 ISP(訳
注:Internet Service Provider インターネットサービスプロバイダ)のアカウ
ントを持っていました。そのため店員達は別のドメインにアドレスを持ってい
たので、qmail は全てのメールをそのアドレスにエイリアスファイルを使って
転送することができました。
注釈: 営業所の店員達の人生を過ごしやすくするため、私達が使っているネッ
ト上のホストは彼ら宛てに届くメールを全て無料 ISP のメールアドレスに転
送しました。これにより、店員達はノートパソコン上で複数のアカウントやア
ドレスをお手玉して "混乱" せずに済みました。彼らに幸あれ :o)
4.4. ファックス
古いサーバ PC は Microsoft Network の FAX 機能を使って ネットワーク経
由で FAX サービスを共有していました。ユーザ達は MS Word の(VBA マクロ
が入った)テンプレートを使って自動的に FAX を作成/送信し、エラーはユー
ザにメールで通知されました。新しいサーバで、前より良くならないまでも同
等のサービスを提供するために、ローカル FAX サービスとして mgetty と
sendfax の組合せを選択しました。インストールは簡単で、すぐに Linux
サーバからの FAX はスプールできる様になりました。 Windows クライアント
からの FAX に関しては比べものにならないほど困難で、結局別の選択をせざ
るを得なくなりました。
4.4.1. Windows クライアントからの FAX
以前の構成では、全ての Windows クライアントに FAX サービスを提供するた
めに MS Outlook で Microsoft Fax を使ってサーバ PC から FAX モデムを共
有していました。これに付け加えて、自動的に FAX 送信する機能を持った標
準の Word97 テンプレートを使用していました。 VBA の Sendfax コマンドを
使ったこのマクロで、ユーザ達はテンプレートの項目を埋めて、Word のツー
ルバーにある "今すぐ FAX を送信する" というボタンを押すだけで FAX を送
信することができました。たった今テンプレートに入力したばかりの内容を、
全て繰返し入力しなければならないようないかなるサードパーティ製のプログ
ラムを使わなくても済んだのです。このようにして、以前のこの構成ではユー
ザ達にシームレスな FAX 送信を提供しており、私はなんとしてもこの環境を
継続すべきだと考えていました。
理想的には、送信したい文書、ユーザ名そして FAX 番号を Windows クライア
ントのアプリケーションから Linux サーバの faxspool に渡す何らかの方法
が必要でした。あらゆる Windows アプリケーションに FAX サービスを提供す
る伝統的な方法は、FAX モデムを "プリンタ" として設定するというもので
す。
4.4.2. 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 は非常に簡単にインストールでき、あっという間に
設定できたのです。
4.4.3. Word のマクロ
すでに述べた通り、ユーザ達は MS Word97 でボタン一つで FAX 文書を送信す
るのに慣れていたので、新しいサーバでもこの機能が使えるようにするのは重
要な事でした。 WHFC は OLE 互換なので、FAX 送信に必要な情報を入力する
ために新しいポップアップボックスを出したりせずに FAX を送信できるよう
にするための新しいマクロを書く事が可能でした。このマクロは二つの事をし
ます - まず、現在の文書を印刷イメージとしてファイルに保存し、次に WHFC
の SendFax OLE 機能を使って印刷イメージファイルを HylaFAX に送信しま
す。 WHFC のセットアップノートで推奨されていたので、プリンタドライバに
は Apple Laserwriter 16/600(ps) を使いました。
ここに、私達が使ったマクロのコーディングを書きます ...
Sub Spool_fax()
Dim givenfax, realnum As String
Dim whfc As Object
Dim OLE_Return As Long
Dim Box_Return As Integer
Application.PrintOut FileName:="", Range:=wdPrintAllDocument, Item:= _
wdPrintDocumentContent, Copies:=1, Pages:="", PageType:=wdPrintAllPages, _
Collate:=True, Background:=False, PrintToFile:=True, _
OutputFileName:="c:\faxtemp\printout.ps", Append:=False
Set givenfax = ActiveDocument.Fields(8).Result
realnum = "9" + givenfax
Set whfc = CreateObject("WHFC.OleSrv")
OLE_Return = whfc.SendFax("c:\faxtemp\faxoutput.ps", realnum, False)
If OLE_Return <= 0 Then
Box_Return = MsgBox("Error sending file", 16, "FAX Not Spooled")
Else
Box_Return = MsgBox("Fax Job ID:" & 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
5. これで完璧？
これで、新しいサーバを立ち上げて運用するために必要なツールやユーティリ
ティのインストールと設定についてきちんとカバーできました。要求された通
りの仕事をこなすだけの単なるツールよりも、良いサーバのためになるものが
まだまだあります。前にも触れた、Linux システム管理者ガイド(Linux
System Administrators Guide)、特に 10 章を読むことをお薦めします。ため
になりますよ!
6. 結論
Linux サーバはこのプロジェクトをスタートしておよそ 2ヶ月くらいで稼働し
始めました。もし内容がわかっていれば、この期間は数日で済んだに違いあり
ませんが、もし似たようなプロジェクトを考えているなら十分な時間的余裕を
もって実行することをお薦めします。私のように、Windows における彼らのサ
ポート工数を低減するなら、とりわけ適切です。 (Windows に比べて)Linux
は使うのが難しいのではなく、単に違うのです。そして Windows からの移行
には時間がかかります。始める前に、周りにある素晴らしい文書を読んでくだ
さい。そして、現在の古いサーバを運用したまま、別のマシンで少しずつこれ
らを試していった方が有益であると思います。段階的に移行する方が、直接置
き換えるよりもよいアプローチです。
7. 参考文献
o Linux Documentation Project -
o Freshmeat -
o qmail -
o HylaFAX -
o Samba -
8. 日本語化について
本ドキュメントの日本語への翻訳に対し快諾いただき、また誤解されやすい表
現について貴重なアドバイスをしてくださった著者の Ryan Cartwright 氏
に感謝します。このドキュメントの原文は以下
にあります。
o LDP(Linux Documentation Project)のサイト:
o 上記サイト内 Linux-LAN-Server HOWTO:
また、日本語化にあたっては JF-MLのメンバーの方々より、様々なアドバイス
や指摘等をいただきましたので感謝とともにここに紹介します。
o 川嶋 勤さん
o 水原 さん
o 千旦裕司さん
o Konkitiさん
o 山下義之さん
o 武井伸光さん
一覧に戻る
グリーンネット・トップページへ戻る
|
