archive-de.com » DE » K » KW-BERLIN.DE

Total: 256

Choose link from "Titles, links and description words view":

Or switch to "Titles and links view".
  • suEXEC サポート - Apache HTTP サーバ
    今のところ suEXEC は root グループによる CGI SSI プログラムの実行を許可していません 対象となるグループ ID は最小の ID 番号よりも 大きい か 最小グループ ID 番号は設定時に指定されます これは CGI SSI プログラム実行を許可されるグループ ID のとりうる最小値です これは system 用のグループを閉め出すのに有効です wrapper が正常に対象となるユーザとグループになれるか ここで setuid と setgid の起動によりプログラムは対象となるユーザとグループになります グループアクセスリストは ユーザが属しているすべてのグループで初期化されます CGI SSI プログラムが置かれているディレクトリに移動 change directory できるか ディレクトリが存在しないなら そのファイルも存在しないかもしれません ディレクトリに移動できないのであれば おそらく存在もしないでしょう ディレクトリが Apache のドキュメントツリー内にあるか リクエストがサーバ内のものであれば 要求されたディレクトリが suEXEC のドキュメントルート配下にありますか リクエストが UserDir のものであれば 要求されたディレクトリが suEXEC のユーザのドキュメントルート配下にありますか suEXEC 設定オプション 参照 ディレクトリを他のユーザが書き込めるようになって いない か ディレクトリを他ユーザに開放しないようにします 所有ユーザだけがこのディレクトリの内容を改変できるようにします 対象となる CGI SSI プログラムは存在するか 存在しなければ実行できません 対象となる CGI SSI プログラムファイルが他アカウントから 書き込めるようになって いない か 所有者以外には CGI SSI プログラムを変更する権限は与えられません 対象となる CGI SSI プログラムが setuid または setgid されて いない か UID GID を再度変更してのプログラム実行はしません 対象となるユーザ グループがプログラムの ユーザ グループと同じか ユーザがそのファイルの所有者ですか 安全な動作を保証するための環境変数クリアが可能か suEXEC は 安全な環境変数のリスト これらは設定時に作成されます 内の変数として渡される安全な PATH 変数 設定時に指定されます を設定することで プロセスの環境変数をクリアします 対象となる CGI SSI プログラムを exec して実行できるか ここで suEXEC が終了し 対象となるプログラムが開始されます ここまでが suEXEC の wrapper におけるセキュリティモデルの標準的な動作です もう少し厳重に CGI SSI 設計についての新しい制限や規定を取り入れることもできますが suEXEC はセキュリティに注意して慎重に少しずつ開発されてきました このセキュリティモデルを用いて サーバ設定時にどのように許すことを制限するか また suEXEC を適切に設定するとどのようなセキュリティ上の危険を避けられるかに 関するより詳しい情報については とかげに注意 Beware the Jabberwock の章を参照してください suEXEC の設定とインストール ここから楽しくなります suEXEC 設定オプション enable suexec このオプションは デフォルトではインストールされず 有効にはならない suEXEC 機能を有効にします suEXEC を使うように APACI に要求するには enable suexec オプションにあわせて少なくとも一つは with suexec xxxxx オプションが指定されなければなりません with suexec bin PATH セキュリティ上の理由により suexec バイナリのパスはサーバに ハードコードされている必要があります デフォルトのパスを 変えたいときはこのオプションを使ってください 例えば with suexec bin usr sbin suexec のように with suexec caller UID Apache を通常動作させる ユーザ名 を指定します このユーザだけが suexec の実行を許可されたユーザになります with suexec userdir DIR suEXEC がアクセスを許されるユーザホームディレクトリ配下の サブディレクトリを指定します このディレクトリ以下の全実行ファイルは 安全な プログラムになるよう suEXEC がそのユーザとして実行できるようにします 単純な UserDir ディレクティブを使っている場合 すなわち を含まないもの これと同じ値を設定すべきです Userdir ディレクティブがそのユーザのパスワードファイル内の ホームディレクトリと同じ場所を指していなければ suEXEC は適切に動作しません デフォルトは public html です 各 UserDir が異なった仮想ホストを設定している場合 それらを全て一つの親ディレクトリに含めて その親ディレクトリの名前をここで指定する必要があります このように指定されなければ userdir cgi へのリクエストが動作しません with suexec docroot DIR Apache のドキュメントルートを設定します これが suEXEC の動作で使用する唯一のディレクトリ階層になります UserDir の指定は別 デフォルトでは datedir に htdocs というサフィックスをつけたものです datadir home apache として設定すると suEXEC wrapper にとって home apache htdocs がドキュメントルートとして使われます with suexec uidmin UID suEXEC の対象ユーザとして許される UID の最小値を指定します 大抵のシステムでは 500 か 100 が一般的です デフォルト値は 100 です with suexec gidmin GID suEXEC の対象グループとして許される GID の最小値を指定します 大抵のシステムでは 100 が一般的なので デフォルト値としても 100 が使われています with suexec logfile FILE suEXEC の処理とエラーが記録されるファイル名を指定します 監査やデバッグ目的に有用 デフォルトではログファイルは suexec log という名前で

    Original URL path: http://xserve.kw-berlin.de/manual/ja/suexec.html (2016-02-16)
    Open archived version from archive


  • Apache バーチャルホスト説明書 - Apache HTTP サーバ
    IP アドレスに 複数の名前がある 名前ベース とがあります 複数のサイトが物理的に同じサーバで扱われている ということはエンドユーザには 明らかではありません Apache は 特に手を入れない状態で IP ベースのバーチャルホスト をサポートした最初のサーバの一つです バージョン 1 1 以降の Apache では IP ベースとネームベースのバーチャルホストの両方をサポート しています ネームベースのバーチャルホストは ホストベース あるいは 非 IP ベース のバーチャルホストと呼ばれることもあります 以下のページでは Apache バージョン 1 3 以降でのバーチャルホストのサポートについての詳細を説明します バーチャルホストのサポート 設定ディレクティブ 参照 mod vhost alias ネームベースのバーチャルホスト IP ベースのバーチャルホスト バーチャルホストの一般的な設定例 ファイル記述子の限界 大量のバーチャルホストの設定 バーチャルホストのマッチングについての詳細 バーチャルホストのサポート ネームベースのバーチャルホスト 一つの IP アドレスに複数のウェブサイト IP ベースのバーチャルホスト 各ウェブサイトに IP アドレス バーチャルホストの一般的な設定例 ファイル記述子の限界 または 多過ぎるログファイル 大量のバーチャルホストの設定 バーチャルホストのマッチングについての詳細 設定ディレクティブ VirtualHost NameVirtualHost ServerName ServerAlias

    Original URL path: http://xserve.kw-berlin.de/manual/ja/vhosts/ (2016-02-16)
    Open archived version from archive

  • 認証、承認、アクセス制御 - Apache HTTP サーバ
    bin ディレクトリ以下に置かれます ファイルを作るには 次のように タイプしてください htpasswd c usr local apache passwd passwords rbowen htpasswd は パスワードを要求し その後 確認のためにもう一度入力するように要求してきます htpasswd c usr local apache passwd passwords rbowen New password mypassword Re type new password mypassword Adding password for user rbowen もし htpasswd がパスの中に入っていない場合は もちろん 実行するためにプログラムまでのフルパスを タイプする必要があります 私のサーバであれば usr local apache bin htpasswd にプログラムが置かれています 次に サーバがパスワードを要求するように設定して どのユーザがアクセスを許されているかをサーバに知らせなければ なりません httpd conf を編集するか htaccess ファイルを使用するかで 設定します 例えば ディレクトリ usr local apache htdocs secret を保護したい場合は usr local apache htdocs secret htaccess か httpd conf 中の Directory usr local apache apache htdocs secret セクションに 配置して 次のディレクティブを使うことができます AuthType Basic AuthName Restricted Files AuthUserFile usr local apache passwd passwords Require user rbowen 個々のディレクティブについて見てみましょう AuthType ディレクティブはどういう認証方法でユーザの認証を行うかを 選択します 最も一般的な方法は Basic で これは mod auth basic で実装されています しかしながら これは気を付けるべき重要なポイントなのですが Basic 認証はクライアントからサーバへ パスワードを暗号化せずに送ります ですから この方法は特に機密性の高いデータに対しては用いるべきでは ありません Apache ではもう一つ別の認証方法 AuthType Digest をサポートしています この方法は mod auth digest で実装されていて もっと安全です ごくごく最近のクライアントしか Digest 認証をサポートしていないようです AuthName ディレクティブでは 認証に使う Realm 訳注 領域 を設定します Realm は大きく分けて二つの機能を提供します 一つ目は クライアントがパスワードダイアログボックスの 一部としてユーザにこの情報をよく提示する というものです 二つ目には クライアントが与えられた認証領域に対してどのパスワードを 送信すれば良いのかを決定するために使われる という機能です 例えば Restricted Files 領域中で 一度認証されれば 同一サーバ上で Restricted Files Realm としてマークされたどんな領域でも クライアントは 自動的に同じパスワードを使おうと試みます このおかげで 複数の制限領域に同じ realm を共有させて ユーザがパスワードを何度も要求される事態を 防ぐことができます もちろん セキュリティ上の理由から サーバのホスト名が変わればいつでも必ず クライアントは再びパスワードを尋ねる必要があります AuthUserFile ディレクティブは htpasswd で作った パスワードファイルへのパスを設定します ユーザ数が多い場合は リクエスト毎のユーザの認証のための プレーンテキストの探索が非常に遅くなることがあります Apache ではユーザ情報を高速なデータベースファイルに 保管することもできます mod authn dbm モジュールが AuthDBMUserFile ディレクティブを提供します これらのファイルは dbmmanage プログラムで作成したり操作したりできます Apache モジュールデータベース 中にあるサードパーティー製の モジュールで その他多くのタイプの認証オプションが 利用可能です 最後に Require ディレクティブが サーバのこの領域にアクセスできるユーザを 指定することによって プロセスの承認部分を提供します 次のセクションでは Require ディレクティブの様々な用法について述べます 複数の人が入れるようにする 上記のディレクティブは ただ一人 具体的にはユーザ名 rbowen の誰か がディレクトリに 入れるようにします 多くの場合は 複数の人が 入れるようにしたいでしょう ここで AuthGroupFile の登場です もし複数の人が入れるようにしたいのであれば グループに属するユーザの一覧の入っている グループ名のついた グループファイルを作る必要があります このファイルの 書式はきわめて単純で お好みのエディタで生成できます ファイルの中身は次のようなものです GroupName rbowen dpitts sungo rshersey 一行にスペース区切りで グループに所属するメンバーの 一覧をならべるだけです 既に存在するパスワードファイルにユーザを加える場合は 次のようにタイプしてください htpasswd usr local apache passwd passwords dpitts 以前と同じ応答が返されますが 新しいファイルを 作るのではなく 既にあるファイルに追加されています 新しいパスワードファイルを作るには c を使います ここで次のようにして htaccess ファイルを 修正する必要があります AuthType Basic AuthName By Invitation Only AuthUserFile usr local apache passwd passwords AuthGroupFile usr local apache passwd groups Require group GroupName これで グループ GroupName にリストされていて password ファイルにエントリがある人は 正しいパスワードをタイプすれば入ることができるでしょう もっと特定せずに複数のユーザが入れるようにする もう一つの方法があります グループファイルを作るのではなく 次のディレクティブを使えばできます Require valid user require user rbowen

    Original URL path: http://xserve.kw-berlin.de/manual/ja/howto/auth.html (2016-02-16)
    Open archived version from archive

  • Apache Tutorial: CGI による動的コンテンツ - Apache HTTP サーバ
    ExecCGI Directory 上記ディレクティブは CGI ファイルの実行を可能にするよう Apache に伝えます また どのファイルが CGI ファイルかを サーバに伝える必要があります 次の AddHandler ディレクティブの例では cgi または pl を拡張子に持つすべてのファイルを CGI プログラムとしてみなすことをサーバに伝えます AddHandler cgi script cgi pl htaccess ファイル htaccess チュートリアル は httpd conf を変更できない場合にどうやって CGI プログラムを 使えるようにするかを説明しています User ディレクトリ cgi で終わるすべてのファイルに対して CGI プログラムの 実行を許可するには 以下の設定を使用できます Directory home public html Options ExecCGI AddHandler cgi script cgi Directory ユーザディレクトリの cgi bin サブディレクトリの すべてのファイルを CGI プログラムとして指定したい場合には 以下のようなものを使います Directory home public html cgi bin Options ExecCGI SetHandler cgi script Directory CGI プログラムを書く 通常の プログラミングと CGI プログラミングの間には主に二つの違いがあります 一つは CGI プログラムのすべての出力には MIME type ヘッダを付けなければなりません これはどのような種類のコンテンツを受け取っているかをクライアントに示す HTTP ヘッダです ほとんどの場合では 次のように出力します Content type text html もう一つは 出力を HTML か ブラウザが表示することができる何か他の形式にする必要があります 大抵の場合は HTML でしょうが GIF イメージや他の非 HTML コンテンツを出力する CGI プログラムを書くこともあるでしょう これら二点以外では CGI プログラムを書くことは あなたが書いている他のプログラムとよく似ているでしょう 最初の CGI プログラム 次に示すのは ブラウザに 1 行印字する CGI プログラムの例です 以下を入力し first pl というファイルに保存し それを cgi bin ディレクトリに置いてください usr bin perl print Content type text html n n print Hello World Perl に精通していなくても 何が起こるかを理解することはできるでしょう 1 行目は usr bin perl で見つけられるインタプリタに このファイルを供給することでこのプログラムが実行されることを Apache に シェル上で実行しようとしているならば そのシェルに 示します 2 行目は 前述したとおり content type の定義を印字します これには復帰改行の二つの組を後に付加します これにより ヘッダの終りに空行が置かれ HTTP ヘッダの終りとボディの始まりを示します 3 行目は Hello World という文字列を印字し これで終りとなります 好みのブラウザを開き アドレス http www example com cgi bin first pl あるいはファイルを置いたロケーションを指定すると Hello World という 1 行がブラウザウィンドに現れるでしょう それはあまりエキサイティングなことではありません しかし これがうまく動けば 他のどのようなものでも動かすことができるようになります しかし まだ動かない ウェブから CGI プログラムへのアクセスを行なったとき ブラウザで見る可能性がある四つの基本的なことがあります CGI プログラムの出力 素晴らしい それはすべてがうまく動いたことを意味します 出力が正常だけれども ブラウザが正常に処理してくれない場合は 正しい Content Type を CGI プログラム内で セットしたかを確認してください CGI プログラムのソースコード または POST Method Not Allowed というメッセージ これは CGI プログラムを処理できるよう Apache を適切に設定していなかったことを意味します CGI を許可するように Apache を設定する の章を読み直し あなたが何を間違えたかを探してみてください メッセージが Forbidden で始まっている これはパーミッションの問題ということを意味します Apache のエラーログ と 後述の ファイルのパーミッション の章をチェックしてください Internal Server Error というメッセージ Apache のエラーログ をチェックすると Premature end of script headers というログが記録されていると思います そして おそらく CGI プログラムによって生成されたエラーメッセージも記録されているでしょう この場合 CGI プログラムが適切な HTTP ヘッダを出力できない原因を知るために 以下の各章でチェックしてみてください ファイルのパーミッション サーバはあなたの権限で実行されていないのを忘れないように つまり 起動するとき サーバは特権をもたないユーザ 通常 nobody や www の権限で実行されます したがって あなたが所有する ファイルを実行するには別のパーミッションが必要となります 通常 nobody が実行するのに十分なパーミッションを与える方法は ファイルに誰でも実行可能とするパーミッションを与えることです chmod a x first pl また もしあなたのプログラムが他のファイルを読み書きするならば それらのファイルは これが可能となる正しいパーミッション を持っている必要があります パス情報と環境 コマンドラインからプログラムを実行するとき 意識しなくてもシェルに渡される情報があります 例えば 参照するファイルのためにどこを検索したらよいかを シェルに伝える PATH があります プログラムが CGI プログラムとしてウェブサーバによって実行されるとき それは同じ PATH ではないかもしれません CGI プログラム内で呼び出すあらゆるプログラム 例えば sendmail のようなもの は フルパスで指定する必要があるでしょう それにより CGI プログラムを実行しようとしたとき シェルはそのようなプログラムを見つけることができます 同様なことは スクリプトのインタプリタ しばしば perl へのパスで CGI プログラムの 1 行目に次のように示されます usr bin perl これがインタープリタへの実際のパスであることを確認しておきます また CGI プログラムが他の 環境変数 に依存している場合は その環境変数が Apache から渡されるようにする必要があります プログラムエラー CGI プログラムが失敗するのは大抵 プログラム自身に問題がある場合です 一度 CGI の使い方を理解し 前述の二つの誤りを犯していないならば まず間違いなくそうでしょう ブラウザを使ってテストする前に まず確認することは コマンドラインからプログラムが実行できることです 例えば 以下を実行してみてください cd usr local apache2 cgi bin first pl perl インタプリタは呼ばないでください シェルと Apache がスクリプトの最初の行の パス情報 を使って見つけます 最初にプログラムから出力されるのは Content Type を含み 後に空行の続く HTTP ヘッダでなければなりません 他のものが出力されている 場合は Apache はこのプログラムをサーバ経由で実行しようとしたときには Premature end of script headers エラーを出力します 詳細は 上記の CGI プログラムを書く を読んでください エラーログ エラーログは友達です 全てのうまくいかないことは エラーログにメッセージを生成します 必ずそれを最初に見るべきです もし あなたがウェブサイトを主催している場所が エラーログの参照を許していないならば きっと他のサイトで主催するべきです エラーログの読み方を学ぶことで ほとんど全ての問題が迅速に確認され 迅速に解決されるということが分かるでしょう Suexec suexec サポートプログラムは バーチャルホストやユーザのホームディレクトリの場所に依って CGI プログラムを違うユーザ権限の下で走らせることを可能にします Suexec の権限のチェックは非常に厳しく それを満たさない場合は CGI プログラムが Premature end of script headers エラーで 実行されません suexec を使っているかどうかを調べためには apachectl V を実行して SUEXEC BIN の場所を調べてください Apache がそこに suexec のバイナリを発見した場合は suexec が 使用されます suexec を完全に理解していない限り 使うべきではありません suexec を無効にするには SUEXEC BIN から指されている suexec バイナリを削除 か名前を変更 するだけです suexec を読んだ後で まだそれを 使いたいのであれば suexec V を実行して suexec の ログファイルの位置を調べ そのログファイルを使ってポリシー違反を 見つけてください 裏で何が起こっているのか CGI プログラミングに習熟すると 裏で起こっていることについて更に理解することの役に立ちます ブラウザとサーバがどのように相互通信するかについては特にそうです なぜなら Hello World を印字するプログラムを書くことはおおいに結構ですが それは特に有益ではありません 環境変数 環境変数は あなたがコンピュータを使うときに辺りに存在している値です それらは パス コマンドをタイプしたときに実行する実際のファイルを探し出すところ ユーザ名 端末型などのような便利なものです 通常 普段使用している環境変数の完全なリストを調べるには コマンドプロンプトで env を入力します CGI の処理中 サーバとブラウザも環境変数を設定し それにより相互に通信することができるようになります その環境変数は ブラウザタイプ Netscape IE Lynx サーバタイプ Apache IIS WebSite 実行されている CGI プログラムの名前などです

    Original URL path: http://xserve.kw-berlin.de/manual/ja/howto/cgi.html (2016-02-16)
    Open archived version from archive

  • Apache チュートリアル: .htaccess ファイル - Apache HTTP サーバ
    ディレクティブが htaccess ファイルの設定を許可している場合は Apache は 各ディレクトリで htaccess ファイルを探します ですから htaccess ファイルを許可すると 実際に使用しているか どうかに関わらず 性能の低下を招くことになります また htaccess ファイルは文書がリクエストされる度に読み込まれます さらに Apache は適用すべきディレクティブを集めるために すべての 上位のディレクトリの htaccess ファイルを探す必要があることにも 注意してください ディレクティブが適用される方法 を 参照してください ですから www htdocs example にある ファイルがリクエストされたときは Apache は以下のファイルを調べます htaccess www htaccess www htdocs htaccess www htdocs example htaccess ですから そのディレクトリのそれぞれのファイルへのアクセスに対して 上の例のファイルがまったく存在しないときでも 追加のファイルシステムの アクセスが行なわれることになります これは htaccess が に対して有効になっているときの場合で 普通はそうなって いないことに注意してください 二つ目はセキュリティです ユーザにサーバの設定を変更することを 許可することになりますので あなた自身が管理できない変更をされる 恐れがあります ユーザにこの特権を与えるのが良いのかどうか 十分 検討してください また ユーザに与える権限が必要なものよりも少なすぎると 余分な技術サポート報告を受け取るようになる可能性が高いことにも 注意してください 確実に ユーザにどの程度の権限を与えたか明確に告げるように してください AllowOverride に 何を設定したかということと 関連する文書を示すことで 後々の混乱をぐっと減らすことが できます ところで ディレクティブの書かれた htaccess を www htdocs example に置くことと 同じディレクティブを 主サーバ設定の Directory セクション Directory www htdocs example に書くことは 完全に等価です www htdocs example の htaccess ファイル www htdocs example の htaccess ファイルの 内容 AddType text example exm httpd conf のセクション file Directory www htdocs example AddType text example exm Directory しかし この設定はサーバ設定ファイルに書いた方がパフォーマンスの 低下が少なくなります ファイルがリクエストされる度に 読み込まれる代わりに Apache の起動時に 1 回だけ読み込めば よくなるからです AllowOverride ディレクティブの 値を none に設定することで htaccess ファイル の使用を完全に無効にすることができます AllowOverride None ディレクティブの適用のされ方 htaccess ファイルの設定ディレクティブは htaccess ファイルの存在するディレクトリと そのサブディレクトリすべてに適用されます しかし 上の階層のディレクトリにも htaccess ファイルが 存在するかもしれないことを覚えておくことは大切です ディレクティブは現れる 順番に適用されます ですから あるディレクトリの htaccess は ディレクトリツリーのより上の階層の htaccess ファイルの 設定を上書きするかもしれません そして その htaccess も より上の階層で書かれたディレクティブを上書きしたり 主サーバ設定ファイル そのものの設定を上書きしたりしているかもしれません 例 ディレクトリ www htdocs example1 に以下の内容の htaccess ファイルがあります Options ExecCGI 注 htaccess ファイルで Options ディレクティブが有効になるためには AllowOverride Options を有効にする必要があります ディレクトリ www htdocs example1 example2 には 以下のような htaccess ファイルがあります Options Includes 二つめの htaccess により ディレクトリ www htdocs example1 example2 では CGI の実行は 許可されません これは Options Includes のみが 効力を持ち それがすべての以前の設定を上書きするからです メイン設定ファイルに対する htaccess のマージ As discussed in the documentation on Configuration Sections htaccess files can override the Directory sections for the corresponding directory but will be overriden by other types of configuration sections from the main configuration files This fact can be used to enforce certain configurations even in the presence of a liberal AllowOverride setting For example to prevent script execution while allowing anything else to be set in htaccess you can use セクションの設定 に記載されているように htaccess ファイルを使って Directory セクションの設定をディレクトリ毎に上書きできますが

    Original URL path: http://xserve.kw-berlin.de/manual/ja/howto/htaccess.html (2016-02-16)
    Open archived version from archive

  • Apache チュートリアル: Server Side Includes 入門 - Apache HTTP サーバ
    Apache に伝えます mod expires で提供されているディレクティブを使用して ファイルが無効になる時刻を明示します これにより ブラウザとプロキシにキャッシュが有効であることを通知します 基本的な SSI ディレクティブ SSI ディレクティブは以下の文法で記述します element attribute value attribute value HTML のコメントのような書式をしているので もし SSI を正しく動作可能にしなければ ブラウザはそれを無視するでしょう しかし HTML ソース中では見えます もし SSI を正しく設定したなら ディレクティブはその結果と置き換えられます element はたくさんあるものから一つ指定することができます 指定できるものの大多数については 次回もう少し詳しく説明します ここでは SSI で行なうことができる例をいくつか示します 今日の日付 echo var DATE LOCAL echo 要素は単に変数の値を出力します CGI プログラムに利用可能な環境変数の全ての セットを含む多くの標準変数があります また set 要素を用いることで 独自の変数を定義することができます 出力される日付の書式が好きではない場合 その書式を修正するために config 要素に timefmt 属性を使用することができます config timefmt A B d Y Today is echo var DATE LOCAL ファイルの変更日 This document last modified flastmod file index html この要素も timefmt フォーマットの設定に従います CGI プログラムの結果を取り込む これは 全ての人のお気に入りである ヒットカウンタ のような CGI プログラムの結果を出力する SSI のより一般的な使用のうちの一つです include virtual cgi bin counter pl 追加の例 以下は SSI を使用して HTML ドキュメントにおいてできることのいくつかの特別な例です いつこのドキュメントは修正されたのか 先に ドキュメントが最後に変更されたのはいつかを ユーザに通知するために SSI を使用することができることを述べました しかしながら 実際の方法は いくぶん問題のままにしておきました HTML ドキュメントに配置された次のコードは ページにそのような タイムスタンプを入れるでしょう もちろん 上述のように SSI を正しく動作可能にしておく必要があります config timefmt A B d Y This file last modified flastmod file ssi shtml もちろん ssi shtml の部分を実際の当該ファイル名と置き換える必要があります もし あらゆるファイルに張ることができる一般的なコードを探しているなら これは不便であるかもしれません おそらくその場合は そうする代わりに変数 LAST MODIFIED を使用したいと考えるでしょう config timefmt D This file last modified echo var LAST MODIFIED timefmt 書式についてのより詳細については お好みの検索サイトに行き strftime で検索してみてください 文法は同じです 標準のフッタを挿入する もし数ページを超えるページを持つサイトを管理しているならば 全ページに対して変更を行なうことが本当に苦痛となり得ることが 分かるでしょう 全てのページに渡ってある種の標準的な外観を 維持しようとしているならば特にそうでしょう ヘッダやフッタ用の挿入用ファイルを使用することで このような更新にかかる負担を減らすことができます 一つのフッタファイルを作成し それを include SSI コマンドで各ページに入れるだけで済みます include 要素は file 属性または virtual 属性のいずれかを使用してどのファイルを挿入するかを決めることができます file 属性は カレントディレクトリからの相対パスで示された ファイルパスです それは で始まる絶対ファイルパスにはできず また そのパスの一部に を含むことができないことを意味します virtual 属性は おそらくより便利だと思いますが 提供するドキュメントからの相対 URL で指定すべきです それは で始めることができますが 提供するファイルと同じサーバ上に存在しなくてはなりません include virtual footer html 私は最後の二つを組み合わせて LAST MODIFIED ディレクティブをフッタファイルの中に置くことがよくあります SSI ディレクティブは 挿入用のファイルに含ませたり 挿入ファイルのネストをしたりすることができます すなわち 挿入用のファイルは他のファイルを再帰的に挿入することができます 他に何が設定できるのか 時刻書式を config で設定できることに加えて 更に二つ config で設定することができます 通常 SSI ディレクティブで何かがうまくいかないときは 次のメッセージが出力されます an error occurred while processing this directive このメッセージを他のものにしたい場合 config 要素の errmsg 属性で変更することができます config errmsg It appears that you don t know how to use SSI おそらく エンドユーザはこのメッセージを決して見ることはありません なぜなら そのサイトが生きた状態になる前に SSI ディレクティブに関する 全ての問題を解決しているはずだからです そうですよね そして config において sizefmt 属性を使用することで 返されるファイルサイズの書式を設定することができます バイト数には bytes を 適当に Kb や Mb に短縮させるには abbrev を指定することができます コマンドの実行 今後数ヶ月のうちに 小さな CGI プログラムと SSI を使用する記事を出したいと考えています ここではそれとは別に exec 要素によって行なうことができることを示します SSI にシェル 正確には bin sh Win32 ならば DOS シェル を使用してコマンドを実行させることができます 下記の例では ディレクトリリスト出力を行ないます pre exec cmd

    Original URL path: http://xserve.kw-berlin.de/manual/ja/howto/ssi.html (2016-02-16)
    Open archived version from archive

  • ユーザ毎のウェブディレクトリ - Apache HTTP サーバ
    パス home rbowen public html file html へ 変換されます パスがスラッシュで始まるときは ディレクトリパスはそのパスに ユーザ名を加えたものからなります 次の設定のとき UserDir var html URL http example com rbowen file html は パス var html rbowen file html へ変換されます アスタリスク を含むパスが指定されたときは アスタリスクを ユーザ名で置換したものが使用されます このような設定だと UserDir var www docs URL http example com rbowen file html は パス var www rbowen docs file html へ変換されます この機能を使用できるユーザを制限する UserDir のドキュメントに示されている構文を使うことで どのユーザがこの機能を使うことができるかを制限することができます UserDir enabled UserDir disabled root jro fish 上の設定は dissabled 文のユーザ以外のすべてのユーザに

    Original URL path: http://xserve.kw-berlin.de/manual/ja/howto/public_html.html (2016-02-16)
    Open archived version from archive

  • Apache 2.0의 새로운 기능 개요 - Apache HTTP Server
    1 8080 필터링 이제 아파치 모듈을 서버로 오고가는 흐름에 대한 필터로 사용할 수 있다 예를 들어 mod include 의 INCLUDES 필터를 사용하여 CGI 스크립트 출력에서 Server Side Include 지시어를 처리할 수 있다 mod ext filter 모듈은 CGI 프로그램을 핸들러로 사용하는 것과 같이 외부 프로그램을 필터로 사용할 수 있게 한다 다국어 오류 응답 브라우저로 보내는 오류 응답문이 이제 SSI 문서를 사용하여 다국어로 제공된다 관리자는 통일된 외관을 위해 이 문서를 수정할 수 있다 간단해진 설정 혼란을 주던 많은 지시어들이 간단해졌다 자주 혼란을 주던 Port 와 BindAddress 지시어는 없어지고 IP 주소 연결에 Listen 지시어만을 사용한다 ServerName 지시어는 리다이렉션과 가상호스트 인식에만 사용될 서버명과 포트를 지정한다 Windows NT 유니코드 자체 지원 Windows NT에서 Apache 2 0은 이제 모든 파일명 인코딩에 utf 8을 사용한다 파일명은 하위 유니코드 파일시스템으로 직접 변역되어 Windows 2000과 Windows XP를 포함한 모든 Windows NT기반 시스템에 다국어 지원을 제공한다 이 기능은 Windows 95 98 ME에는 지원되지않고 파일시스템 접근에 전과 같이 시스템의 지역 코드페이지를 사용한다 정규표현식 라이브러리 Updated Apache 2 0은 Perl호환 정규표현식 라이브러리 Perl Compatible Regular Expression Library PCRE 를 포함한다 이제 모든 정규표현식에 더 강력한 Perl 5 문법을 사용할 수 있다 모듈에서 나아진 점 mod ssl Apache 2 0에서 새로 추가되었다 이 모듈은 OpenSSL이 제공하는 SSL TLS 암호화 프로토콜의 인테페이스다 mod dav Apache 2 0에서 새로 추가되었다 이 모듈은 웹컨텐츠를 올리고 관리하기위한 HTTP Distributed Authoring and Versioning DAV 표준을 구현한다 mod deflate Apache 2 0에서 새로 추가되었다 네트웍 사용량을 줄이기위해 브라우저에게 컨텐츠를 압축해서 보내라고 요청할 수 있다 mod auth ldap Apache 2 0 41에서 새로 추가되었다 이 모듈은 HTTP Basic Authentication에 사용하는 정보를 LDAP 데이터베이스에 저장한다 관련된 mod ldap 모듈은 연결풀 connection pool 을 제공하고 결과를 캐싱한다 mod auth digest 공유메모리를 사용하여 프로세스간 세션 캐싱을 지원한다 mod charset lite Apache 2 0에서 새로 추가되었다 이 실험적인 모듈은 문자집합 변환과 문자집합 재작성 기능을 제공한다 mod file cache Apache 2 0에서 새로 추가되었다 이

    Original URL path: http://xserve.kw-berlin.de/manual/ko/new_features_2_0.html (2016-02-16)
    Open archived version from archive



  •