この文書は学内向けにWWWサーバの運用に関する情報をまとめたものです。 内容は既にかなり古くなっています。 また間違いも含んでいます。 コメントをお願いします。 この文書の位置づけ
これは、言い換えれば、利用者が同時にサービスの提供者でもあるこ とを示しています。サービス提供の機会がすべての利用者に均等に与え られているのがインターネットの特色なのです。
ここではインターネットへの情報発信の手段として、WWW サーバの 運用について解説します。
2.WWW とは
WWW (World Wide Web) とは
CERN (Conseil Européenne pour la Recherche Nucléaire)
によって提唱されている、分散ハイパーメディアシステムの
構築を目標としたプロジェクトです。
この基本となるハイパーテキストとは、読者が文書のある部分に関連 する情報を容易に入手できるよう、文書のその部分に関連する情報への 「ポインタ」を埋め込んだものです。一般の文書なら、それが参照して いる別の文書を入手するのにある程度の手間がかかりますが、ハイパー テキストでは、それを「読む」ためのソフトウェア (ブラウザ、 NCSA Mosaic 等) を使用することにより、例えばその部分をマウスで「クリッ ク」する程度で関連する文書に「リンク」できます。
分散ハイパーメディアシステムとは、 インターネット上に散在する 様々な情報 (資源と呼びます) をハイパーテキストを使って互いに関連づ けようとするものです。 この記述には HTML (HyperText Markup Language) を用います。
WWW においてリンクされる情報は、インターネットを介してアクセ ス可能なものなので、実際の所在は問いません。また種類もハイパーテ キストやプレーンテキストに限らず、プログラムやデータベース、画像 や音声、動画なども含んだ、まさにハイパーなものです。
3.URL とは
インターネット上の資源は、所在や種類だけでなくそのアクセス方法
も多岐にわたります。そこでこのような資源に対して統一的な命名法を
用意することが考えられています。それが URL (Uniform Resource
Locator) で、書式は以下のようなものです。WWW ではこれをポインタ
として用います。
アクセス方法://ホスト:ポート/パスこのアクセス方法には以下のようなものがあります。このほか whois なども対象になります。
これらのアクセス方法のうち WWW の中心となるのは HTTP ですが、 WWW の目指しているものは HTTP に限らずインターネット上の様々な 資源を集約することです。WWW のサーバ、すなわち HTTP のサーバ自 体は当然 HTTP でしかアクセスできませんが、ブラウザがこれらのもの に対する統一的なインタフェースを提供します。このためブラウザは非 常に大きなソフトウェアです。
但し、ブラウザが上に挙げたすべてのアクセス方法をサポートしてい るとは限りません。例えば、 Macintosh や Windows 上のブラウザでは、 WAIS をサポートするためのパッケージ public domain に存在しないた め、現時点ではそれらからは直接 WAIS のサーバにはアクセスできませ ん。しかし UNIX 上に用意されている WAIS と HTTP のゲートウェイを 介すればアクセスすることができます。
4.HTTPとは
HTTP (Hypertext Transfer Protocol) は、WWW においてハイパーテキ
ストデータの転送に用いる手順です。ブラウザは URL を見て、それが
HTTP でアクセスすべき資源なら、URL に示されたホストの HTTP 用の
ポートに TCP で接続し、"GET /URLのパスの部分" というリクエストを
送ります。サーバはこのリクエストに従って要求された資源 (データ) を
ブラウザに送ります。なお、この "/URLのパスの部分" のことを URI
(Uniform Resource Identifier) と呼びます (CrLf は復帰改行です)。
host: www.wakayama-u.ac.jp http://www.wakayama-u.ac.jp/ → port: 80 (HTTP の well-known port) uri: / ↓ request: "GET / CrLf"このようなリクエストを Simple Request といいます。このほかに Full Request があります。
Method URL ProtocolVersion CrLf Header CrLf CrLf data ....ProtocolVersion を省略すると HTTP/V0.9 が仮定されます。ここに HTTP/V1.0 を指定すると FullRequest となり、ブラウザは次に RFC822 (つまり電子メール) 形式のヘッダを送ることが可能になります。 ヘッダはブラウザ側の情報やサーバに対する指示 (キャッシュに置かれたデータを使うかどうかなど) を含みます。 ヘッダの終りは空行 (CrLf のみ) で示し、その後ろにデータが続きます。
Method には GET の他 HEAD や POST などいくつかのものがあります。 GET の応答は FullRequest に対してはデータの先頭にサーバの情報や データの詳細 (作成時間や有効期限など) を示す RFC822 形式の ヘッダを付加したものになります。 また HEAD はそのヘッダだけを取り出します。
5.HTTPサーバの種類
すでに述べたように、HTTP 自体は簡単なプロトコルなので、それを
解釈するサーバプログラムもいろいろなところで開発されています。
"GET uri" の形式の Simple Request だけを実現するなら、
sh スクリプトでも簡単に書くことができます。
#!/bin/sh read get docid version cat /server_root/`echo $docid | tr -d '\015'` # strip trailing CRこれを inetd で起動するよう設定します。
追記:現実にこんな方法でサーバを動かしたら、 セキュリティ上とてつもなくでっかい穴を空けることになります。 決して真似しないでください :-P
以下は UNIX 用のサーバですが、ブラウザ同様 Macintosh や Windows 用のものあります。
GN
基本的には gopher サーバですが、HTTP によるアクセスも可能です。
HTTP でアクセスされたときは、gopher サーバとしての応答を HTML
化して送ってくれます。gopher サーバとしてもオリジナルの gopherd に
はない機能を持っており、特に検索機能に関してはサーバ自身で grep 方
式による検索機能を持っているのに加え、WAIS のインデックスを使っ
た検索が行えるなど充実しています。また gopher のメニューを記述する
menu ファイルの中に HTML による記述を埋め込むことができるので、
HTTP でアクセスされたときだけインラインイメージを貼り込むような
こともできます。これを index.html のように使用すれば、本当の HTTP
サーバと同じ使い方ができます。CERN や NCSA の httpd に比べてスク
リプト機能が劣るとされていますが、基本的な使い方では不足を感じま
せん。
インストールは多分これが一番簡単で、筆者の luna に "すら" ほとん ど手を加えずにインストールできました。ややこしい設定ファイルも ありません。
NCSA httpd
もっとも人気のあるブラウザである Mosaic を作っているところが出し
ている HTTP サーバ。多機能な割に軽いという評判です。設定ファイル
がアクセス制御用のものを含めて三つもあるのと、その書き方が HTML
的で取っつきにくいのが難点と言えなくもないでしょう。現在 version
1.3 が emily0 で動いています。
CERN httpd
WWW プロジェクトの中心である CERN で開発されたサーバ。現在
ryujin で使用している 3.0pre6 というバージョンでは、WAIS のゲート
ウェイの他 proxy (ゲートウェイ/代理応答) やキャッシュなどの機能を持
ちます。NCSA のものに比べてかなり大きいのですが、設定ファイルは
一つだけです。
Plexus
perl で書かれたサーバ。機能は NCSA 版とほぼ同等だそうです。
その他のサーバ
パソコン上で稼働するものに KA9Q NOS (MS-DOS), NCSA httpd for
Windows, SerWeb, WEB4HAM (以上 Windows), HTTPS (Windows-NT),
MacHTTP (Macintosh) などがあります。インターネットに情報を発信す
るのに、必ずしも UNIX ワークステーションが必要なわけではないのです。
6.HTTPサーバのインストール
6.1.HTTPサーバのコンパイル
現在までに筆者は CERN httpd 3.0pre6 (ryujin)、ncsa-httpd 1.3 (emily0)、
gn 2.12 (luna) の3つの HTTP サーバのインストールを行いました。ここ
では CERN のものについて解説します。CERN のサーバは、Sun 等のポ
ピュラーなプラットホームに対しては、コンパイルされたバイナリが用
意されていますから、それを利用すればよいでしょう。ソースファイル
をコンパイルして作る場合は、以下のような手順になります。最初に
ソースファイルのパッケージを入手し、それを展開します。
% zcat cern_httpd.tar.Z | tar xf -これによって WWW というディレクトリが作成されます。WWW/All の中に、サポートしているプラットホームごとにディレクトリがありま すから、インストールしようとするプラットホームが含まれているかど うか調べてください。サポートされていれば、単に make するだけでコ ンパイルできると思います。必要に応じて WWW/All/プラットホーム名 /Makefile.include を修正してください。
% cd WWW % makeこのとき、もしプラットホームの判別に失敗するようなら、make する かわりに次の手順を用いてください。
% setenv WWW_MACH プラットホーム名 % ./BUILDこれで WWW/Daemon/プラットホーム名 に httpd ができるほか、htadm、 htimage、cgiparse、cgiutils といったユーティリティー群が作られま す。
なお、サポートされていないプラットホームインストールしようとす るとき、それが BSD 系の OS なら、上の手順の "プラットホーム名" を unix に設定してみてください。なお SONY の NEWS-OS 4.x はリンク時 に strftime と mktime がないというエラーがでます。 これらは glibc などのパッケージに含まれているので、 持ってきて一緒にコンパイル/リンクすればいいでしょう。
6.2.コンフィギュレーションファイルの設定
httpd はデフォルトではコンフィギュレーションファイルとして
/etc/httpd.conf を読み込みます。これは httpd の起動時に -r オプションで
指定することによって変更できます。
httpd -r /usr/local/etc/httpd.confこのサンプルが httpd のソースファイルと同じところに server_root.tar.Z として用意されています。この中には次のようなファイルが含まれてい ます。
他にも多数のディレクティブが用意されています。一部を紹介しま す。
このディレクトリの下に Welcome.html か welcome.html あるいは index.html という HTML 文書を置けば、それが http://www.server.host/~user/ という URL でアクセスできます。
HTML を知らなくても、単にこのディレクトリにファイルを置くだけ で、サーバが自動的にファイルの一覧を HTML 形式で作成してブラウザ に送ってくれます。その際そこに README ファイルがあれば、ディレ クトリ一覧の先頭にその内容を表示してくれます。
7.CGI
CGI (Common Gateway Interface) とは、参照するかわりに実行して結果
を得ることのできる資源です。HTTP とその他のプロトコルのゲート
ウェイをサーバ側で用意したり、データベースの検索を行う場合などに
使用します。URL がコンフィギュレーションファイルの Exec ディレク
ティブに設定されているパターンにマッチするとき、それが実行可能な
プログラム (シェルスクリプトを含む) ならその標準出力を応答としてブ
ラウザに返します。
7.1.一般的な CGI スクリプト
HTTP サーバは通常ファイルの拡張子を見て、そのファイルの MIME
タイプ (HTML 文書なのか画像なのか等) を決定しますが、CGI スクリプ
トの出力に対して実行前にそれを知ることは困難です。このため CGI ス
クリプトは出力の先頭にかならず MIME タイプを示す Content-Type: 行
を置く必要があります。Content-Type: とデータの本体の間には1行空行
を入れてください。
#!/bin/sh echo "Content-Type: text/html" echo "" echo "<HEAD>HTML output</HEAD>" echo "<BODY>" echo "<H1>This is a sample HTML output</H1><P>" echo "</BODY>" #!/bin/sh echo "Content-Type: text/plain" echo "" echo "This is a sample PLAIN output"Content-Type: で明らかになっているので、出力中に <HTML>〜 </HTML> や <PLAINTEXT> 等を埋め込む必要はありません。
CGI スクリプトにデータを渡すには、引数と環境変数を用います。い
ま、sh スクリプトで書かれた CGI スクリプト /cgi-bin/script を、下のよ
うな URL を用いて起動した場合を考えます。ドキュメントを公開する
ディレクトリは /usr/doc/WWW とします。空の変数やURL によって内
容が変化しない変数は省略しています。
したがって URL の CGI スクリプトの部分に (さもサブディレクトリが
あるかのように) 続くパス名は、ドキュメントを公開するディレクトリ
からの相対で示された資源へのパスであり、? に続く部分は
QUERY_STRING と CGI スクリプトの引き数に渡されます。その際 + で
区切って複数の引き数を渡すことができます。ただし? に続く部分に =
が含まれていれば、これは引き数として処理されずに QUERY_STRING
だけに渡されます。
なお、このように区切り文字として使われている /, ?, +, =, & や |, <, >, (, ), !, # , % など多くのの特殊記号は、 URL の中で使うことができません。 このような文字を引き数などで使用したい場合は、% に続けた文字 コードの 16 進表記で表現します。
#!/bin/sh cat << 'EOT' HTTP/1.0 200 Script results follow Server: MyScript/1.0 via CERN/3.0 Content-Type: text/html <HEAD>NPH-Script output</HEAD> <BODY> <H1>This is a sample NPH-Script output</H1><P> </BODY> EOTこれは、例えばHTTP のリザルトコード (例中の 200) を CGI スクリプ トの状態によって変えたいときなどに使われます。
7.3.ISMAP (Clickable Map)
HTML 文書に埋め込むインラインイメージをアンカーにするとき、
ISMAP という属性を付けることができます。
<A HREF="http://host/path"> <IMG SRC="/img/sample.gif" ISMAP> </A>このイメージ上をクリックしたとき、もし ISMAP がなければ HREF で指定された URL にそのままリンクしますが、ISMAP が指定されてい るときは URL に引き数が付きます。
http://host/path?x+yここで x, y はクリックしたイメージ上の位置です。したがって、path を与えられた引き数の値によって応答を変えるCGI スクリプトにしてお けば、クリックした位置によってリンク先を変えることなどが実現でき ます。
CERN の httpd にはこれをサポートするために htimage というユーティ リティーが付属しています (NCSA httpd にも imagemap という同様な ユーティリティーが付属しています)。これを使用するには、まずイメー ジ上のクリック位置とリンクする URL を対応付ける設定ファイルを作 ります。
<A HREF="/cgi-bin/htimage/maps/sample.map"> <IMG SRC="/images/sample.gif" ISMAP> </A>"/cgi-bin/htimage/maps/sample.map" という記述が長すぎるなら、サーバ のコンフィギュレーションファイルにおいて "Map /img/* /cgi-bin/htimage/maps/*" のようにマップしておけば、"/img/sample.map" のように書けるようになります。
htimage や imagemap のようなユーティリティーを自作するのは容易だ と思います。単に他のURL にリンクするだけでなく、アイデア次第でい ろんな応用が考えられると思います。
7.4.ISINDEX (Search)
ISINDEX はデータの検索のための問い合わせを実現します。HTML 文
書が <ISINDEX> を含んでいると、ブラウザ上のその位置に入力欄が現
れます。
ここにキーワードをタイプし改行すると、キーワードを引き数にして もう一度同じ HTML 文書にリンクしようとします。
#!/bin/sh echo "Content-Type: text/html" echo "" case $# in 0) echo "<ISINDEX>" … ;; *) echo "<TITLE>Search Results</TITLE>" … ;; esac
QUERY_STRING からキーワードを切り出すには、CERN httpd に付属 している cgiparse というユーティリティーを使うと便利です。これは "%16進数" の形にエンコードされた文字のデコードも行ってくれます。
#!/bin/sh echo "Content-Type: text/plain" echo "" n=0 for i in `cgiparse -keywords` # QUERY_STRING からキーワードを切り出す do n=`expr $n + 1` echo "arg[$n]=$i" done
username=tokoi&switch=on&status&fruit=orange&comment=good bye joeつまり = の左辺に NAME= で指定されたものを置き、その右辺に入力 欄の内容や選択肢、あるいは VALUE= の設定を置いたものを、項目ご とに & で区切って並べたものが得られます。
QUERY_STRING から要素を切り出すには、この場合も cgiparse が使 えます。要素を一つ一つ切り出すには -value オプションを使います。ま た -form オプションを付けたときの cgiparse の出力は下のようになりま すから、これを sh スクリプト等で eval するだけでシェル変数として使 用できます。
FORM_username='tokoi'; FORM_switch='on'; FORM_fruit='orange'; ... #!/bin/sh echo "Content-Type: text/plain" echo "" cgiparse -value username # tokoi を出力 cgiparse -value switch # on を出力 eval `cgiparse -form` # 全部をシェル変数に
ネットワーク内のコンピュータが一つでも不正侵入されると、同じ ネットワークに接続された他のコンピュータも破られる危険性が非常に 高まるため、インターネットに接続している機関のシステム管理者は、 その機関が所有するすべてのコンピュータに対して、侵入の足がかりと なるような問題点 (セキュリティーホール) を持たないよう常に注意を払 わなければなりません。しかしコンピュータの数が増えるに従って、こ のような体制による管理は困難になってきます。そこでインターネット と LAN の接点部分で外部からの侵入を阻止しようとするアイデアが firewall (防火壁) です。
インターネットと LAN のように異なるネットワークを相互に接続す るには、ルータという装置が使われます。ルータには専用機もあります が、複数のネットワークインタフェースを持つワークステーションも ルータとして使用されます。
後者のタイプのルータにおいて、例えば片方のネットワークからもう 一方のネットワークへの通信を中継しないようにすれば、外部のネット ワークからルータを越えて直接内部のネットワークにアクセスすること が不可能になります。同様に内部のネットワークからも直接外部にアク セスすることができなくなりますが、ルータ自身は双方のネットワーク にアクセス可能なので、内部からは一旦これを経由することで外部への アクセスが可能になります。
当然外部からもこのルータを経由すれば内部へのアクセスが可能なの で、ルータは不正侵入の矢面に立たされることになりますが、管理者は 不正侵入を防止するためにこのルータだけに注目していれば済むので、 セキュリティー監視の労力が大幅に軽減されます。
このような措置をとっても、電子メールやネットワークニュースのよ うに「蓄積再送型」の通信では一旦ルータを経由させるような設定が容 易にできるので、使い勝手にはほとんど影響しません。しかし telnet や ftp、それに WWW などは、先方との間で直接コネクションを張る必要 があるため、これらを利用するには利用者は一旦ルータにログインする 必要があり不便です。また外部へのアクセスを要求する利用者をすべて ワークステーションルータに登録することは、手間がかかるだけでな く、利用者数の増加によるセキュリティーの低下も引き起こします。
8.2.proxy
proxy (代理応答) はこれらのサービスにおいて、内部のネットワークの
利用者が透過的に firewall を経由して外部にアクセスできるようにする
ためのメカニズムです。
proxy に対応したブラウザ (Mosaic-2.4 等) は、proxy の設定がされていれば、与えられた URL に記述されたホスト に直接接続するかわりに、proxy サーバに指定された httpd にアクセス方 法やホスト名を省略しない完全な URL をもったリクエストを送りま す。httpd はブラウザから送られてきたリクエストの URL が完全なもの なら、それに従って先方のサーバにリクエストを送り応答をブラウザに 中継します。
なお中継の際にデータを proxy サーバでも保存しておき、以後同じ URL に対するリクエストがあったときには、先方に接続するかわりに保 存していたデータをブラウザに送り返すことによって、データのキャッ シングを実現することもできます。これによってインターネット上のト ラフィックを軽減することができるほか、利用者に対しても良好な応答 速度を実現することができます。
CERN の httpd 自身も proxy クライアントの機能を持ち、他の proxy サーバに接続することができます。これによって、多段の proxy を構成 することができます。
DeleGate で漢字コードの変換を行うには、例えば次のようにします。
delegated -P8090 PROXY=www.wakayama-u.ac.jp:80\ SERVER=http://www.wakayama-u.ac.jp\ CHARSET=SJISこれを emily0 で動作させたとすると、HTTP proxy に未対応のクライ アントでは直接この DeleGate に接続するだけで www.wakayama-u.ac.jp のページを見ることができます。
Mosaic http://emily0.emily.eco.wakayama-u.ac.jp:8090HTTP proxy に対応したクライアントでは、上の URL を http_proxy に 設定すればよいでしょう。
setenv http_proxy http://emily0.emily.eco.wakayama-u.ac.jp:8090
和歌山大学の場合、購読しているカテゴリはそれほど多くないにもか かわらず、現在1日あたり 150MB〜200MB の記事が流入してきます。 この大半は読まれることなく捨てられています。64Kbps の回線は1日あ たり最大でも 700MB 弱しか転送できませんから、他のサービスによる トラフィックを考えると、これは結構危機的な状況なのではないかと感 じています。
また一方で、和歌山大学が購読していないカテゴリもたくさんありま す。その中にもおもしろそうなものがあるので手を広げたい欲求はある のですが、現状を考えるととてもその気にはなれません。
この無駄をどう考えるかは議論のあるところですが、少なくとも現在 の方式は、データ転送方式として UUCP を用いていたため記事を全部 バッチ式にコピーする必要があり、また記事の流量もそれが可能な程度 しかなかった頃に開発されたもので、インターネットで全世界が結ば れ、記事の流量も膨大なものになってきた現在の状況に十分適応できて いるかどうかは疑問です。
WWW の問題点はキャッシュや階層的なデータ管理の仕組みさえ整備 すれば解決可能なのではないかと思います。将来はこのような方式が ニュースシステムにも適用されて、オンデマンドであらゆるニュースが 購読できるようになるかも知れません。