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 ( http://www.ora.com)刊「Learning Red Hat Linux」という本を持っていました。 この本は、家で Linux をインストールする時に利用したのですが、このプロジェクトの為にはすばらしい本です。 この本には、Samba についての重要な章がありました。Samba は Linux を Windows9x のためのファイルサーバとして動作させることのできるネットワークアプリケーションです。 Linux Documentation Project(LDP - http://www.linuxdoc.org) も広範囲にわたって利用しました。 特に、Linux ユーザーズガイド、システム管理者ガイド、ネットワーク管理者ガイドを利用しました。
全体的に成果を収めるための調査の重要性についてはいくら強調してもし足りないくらいです。 「備えあれば憂いなし」や五つの P(Proper preparation prevents poor performance: 適切な準備によって低性能を防ぐことができる) といったものも含め、このことを端的に表現した沢山の言い回しや逸話があります。
初期調査によって、私が進むべき方向と、私がより多く学ばなくてはならない特定のプログラムが明らかになりました。 代表例はこれらのプログラムです:-
他にも候補があったものの、これらが最もお薦めであり、u.c.o.l(ニュースグループ uk.comp.os.linux の事)への問い合わせで、良い選択であることを確認しました。 (u.c.o.l ユーザ達のアドバイス同様に私の助けとなった)Linux Journal の記事で、ネットワーク FAX サービスが 可能でしかもそのツールが利用可能である事は分かっていました。
これは、初期の段階で最も心配な仕事の一つとなりました。 Linux こそ最適な解決法であると私自身が認識する事と、上司達を同じ結論へと導くことを考えると言う事は、全く別の事でした。
額面上は経費(常に立ちはだかる大きな障害ですが)はかからないのですが時間の問題がありました。 このプロジェクトは私にとって学びながら進めるのに相当な時間を要し、転じて事態の解決にいたるまでには 全体として長い時間がかかるであろうと予想されました。
現状の欠点をあげつらって、その上で全てを克服する英雄として Linux を提案するという誘惑に かられました。 しかしこれはうまくいきそうにありませんでした。 なぜなら、単にそのアイデアを気に入っているという理由だけで、ある解決案を押し進めていると受け取られかねないからです。 さらに、この論法で主張した場合 Linux サーバを配備する上でのいかなる遅延も説明しがたいものとなったでしょう。 私はこの議案を、会社にとって利益をもたらすものとして提案しなければなりませんでした。 この目的のためには、現存する問題点を使う事もできましたが、「Linux のための Linux」という姿勢にならないよう 気をつけなければなりませんでした。
偶然にも、私の心配は全く無用でした。というのは、現在のサーバについて話しているとき、IT の管理者が まさに私が論じようと思っていたのと全く同じ解決案を出したのです! 彼は、私がここに書いた様なものと同様の内容についての確信を得ようとしていました。 あなた方の状況はもちろん同じではないでしょうが、いかなるケースにおいても、議論を可能な限り客観的に 進めるというやりかたは間違いなく有益なものとなるはずです。
私は、このプロジェクトに RedHat 6.0 を選びました。 理由はいたって簡単で、すでに持っていたので素早く始められるからです。 また、家で使用していたので馴染みがあった、という理由もあります。 私が思うに、他のものに比べてある特定のディストリビューションを使うべきだといった様な実質的な理由は 個人的な好みを除いてはありません。 色々なディストリビューションにいくつかのサーバ版がありますが、ここでもやはり個人的な好みの領域です。 私は、色々なディストリビューションについてあまり経験がありませんので、特にどれかを推薦するような資格は ないと思われます。あえてアドバイスするとすれば、未知の部分をできるだけ無くしたいと考えるがゆえに 異なるディストリビューションの微妙な違いを学んでゆくと、それが新たな悩みのタネを生み出すかもしれない、 という事です。