ウェブサーバ | 豊橋技術科学大学情報メディア基盤センター

ホスティングサービスウェブサーバ

このページには，共通サーバ上のウェブサーバに関するFAQが記述されています．共通サーバの利用開始前の質問・要望は， supports@imc.tut.ac.jp にメールを送ってください．共通サーバの利用開始後の質問・要望は， jointserver-users@lists.imc.tut.ac.jp にメールを送るか，FAQに追加してください．

利用できる容量は?

20GBまでコンテンツを置くことができます．

ファイルをアップロードするにはどうしたら良いですか?

共通サーバでは，WebDAV サーバが稼働しています． http://www.atmarkit.co.jp/flinux/special/webdav/webdav02b.html などを参考にして，適当な WebDAV クライアント(Windowsの場合はウェブフォルダ)を使ってください．

なお，Windows Vistaでウェブフォルダを利用するには，Windowsの追加修正プログラムを適用するか，または，別の WebDAV クライアントの導入が必要です．詳しくは以下のページを参照してください．

また，Windows7 のウェブフォルダは，BASIC 認証のかかった WebDAV サーバにアクセスできない問題が知られています．設定で回避することは不可能ではないのですが，設定が複雑なので，あまりお勧めできません．適当な WebDAV クライアントを使っていただくほうが簡単だと思われます．例えばどちらかのWebdavクライアントをダウンロードしてみてはいかがでしょうか？

Windows でファイルがアップロードできないんだけど?

共通サーバでは，WebDAV を使っています．アップロード先のURLが，https://imc.tut.ac.jp/dav/example.imc.tut.ac.jp/htdocs/ のようになっているために誤解されるかもしれませんが，Internet Explorer ではアップロードできません．必ず，http://www.atmarkit.co.jp/flinux/special/webdav/webdav02b.html などを参考にして，適当な WebDAV クライアント(Windowsの場合はウェブフォルダ)を使ってください．

Windows7の標準機能である「ネットワークドライブの割り当て」は、2018年04月に実施したホスティングサービスセキュリティ強化により、そのままでは接続できなくなりました．引き続き使用したい場合は以下のURLに従って更新プログラムの適用をお願いいたします．

https://support.microsoft.com/ja-jp/help/3140245/update-to-enable-tls-1-1-and-tls-1-2-as-a-default-secure-protocols-in

特定のアプリケーションソフト、ツールでファイルがアップロードできないんだけど?

2018年04月に実施したホスティングサービスセキュリティ強化により、WebDAV機能を利用するにはアプリ、ツールの規格はTLSv1.1、TLSv1.2が必須となりました．古いアプリケーションで使用しているWebDAVの規格がTLSv1.1、TLSv1.2に対応しているかご確認下さい．

既存ファイルの上書き，ファイル名の変更やコピーができません

Mac OSXやLinuxなどの一部の WebDAV クライアントソフトウェアと，共通サーバの WebDAV サーバを組み合わせて使ったばあいには，ファイルの上書き，ファイル名の変更，コピーなどの操作ができないことがあります．これは，WebDAV サーバの実装の制限に起因しており，現状では解決は非常に困難です．

そのような制限のあるクライアントソフトウェアを使っている場合であっても，新規ファイルの作成とファイルの削除は可能です．したがって，ファイルをローカルディスク上に一度コピーして，ローカルで編集または名前の変更を行ってから，WebDAV フォルダ上に書き戻せば，編集および名前の変更ができるはずです．

お手数をおかけしますが，当面の間，上記のように運用で回避していただくようにお願いします．

ドメインの管理者以外のユーザにファイルのアップロードを許可したいのですが?

そのフォルダ(ディレクトリ)に .htdavgroup という名前のファイルを作成してください．このファイルには，そのフォルダおよび，それ以下のフォルダへのアップロードを許可するユーザのアカウント名を，1行1アカウントの形式で記述してください．.htdavgroupの編集はドメインの管理者のみが行えます．

なお，ドメインの管理者は，.htdavgroup の指定に関わらずアップロードすることができます．

ファイル名やフォルダ名に使えない文字はありますか?

RFC3986で特殊文字として予約されている以下の文字は利用できません．

: / ? # [ ] @

Windows でピリオドから始まるファイル名のファイルが作れません!

この問題は，エクスプローラの制限のようです．ファイルを先にアップロードしておいてから，ファイル名を変更しようとしても，以下のようなエラーが表示されてしまいます．

以下のようにすると対処できます．

まず，作りたい内容のファイルを「メモ帳」などで開いて，クライアント上のローカルなディスク(例えば，デスクトップ)に「名前をつけて保存」します．この時，作りたい名前(例えば，.htaccess や .htpasswd など)の名前で保存しなければなりません．
作ったファイルを，ウェブフォルダにドラッグ&ドロップします．

ファイル名やフォルダ名に日本語は使えますか?

一応は使えるように設定されていますが，推奨しません．

現時点では，ブラウザからサーバに日本語を含むURLを送る場合，どのように送るかについて標準が規定されていません．そのため，ブラウザによって挙動が異なり，あるブラウザでは見えるページが，他のブラウザでは見えないということがしばしば発生してしまいます．

アクセス制限はかけられますか?

はい．いくつかの方法があります．

第1の方法は，SSL 化が完了している場合に使える方法です．本学のユーザ認証基盤を参照する Shibboleth SP として動作するように，設定を IMC に依頼した上で，以下のような .htaccess を用意してください．この設定では，本学のユーザ認証基盤に登録されているユーザ(教職員，学生，研究員など)であれば誰でも，このディレクトリにアクセスできます．

AuthType Shibboleth
ShibRequestSetting requireSession 1
Require valid-user

Shibboleth SP として設定する方法は，安全性・確実性の両方から見てもっとも良い方法です．既に SSL 化を完了しているウェブサーバの場合は，この方法を使うことを特に推奨します．SSL 化が完了していない場合で，SSL 化を希望される場合は，別にご相談下さい．

なお，特定のユーザのみに対してアクセスを許可する場合には，以下のようにします．

AuthType Shibboleth
ShibRequestSetting requireSession 1
Require user アカウント名1 アカウント名2

第2の方法は，SSL 化されてない場合でも，本学のユーザ認証基盤を用いて認証を行う方法です．以下のような .htaccess を用意します．この設定では，本学のユーザ認証基盤に登録されているユーザ(教職員，学生，研究員など)であれば誰でも，このディレクトリにアクセスできます．

AuthType None
Require valid-user
TktAuthLoginURL /authtktlogin

なお，特定のユーザのみに対してアクセスを許可する場合には，以下のようにします．

AuthType None
Require user アカウント名1 アカウント名2
TktAuthLoginURL /authtktlogin

第2の方法は第1の方法に比べて簡便ではありますが，送信元サーバの完全性の保証がないなどの欠点があるため，できるだけ SSL 化して第1の方法を用いることが推奨されます．

第3の方法は，従来と同様に，digest 認証を使う方法です．例えば，以下のように .htaccess に書くことにより，digest 認証によるパスワード制限をかけることができます．なお，AuthUserFile の指定は，適切なファイル名に置き換えてください．

AuthType Digest
AuthName "private area"
AuthUserFile /var/www/htdocs/.htdigest
Require valid-user
BrowserMatch "MSIE" AuthDigestEnableQueryStringHack=On

なお，BASIC認証は，認証情報が平文のままで通信経路上を流れてしまう問題があるので，共通サーバでは使えないように設定されています．

第1および第2の方法は，どちらも本学のユーザ認証基盤を利用していますので，本学のユーザ認証基盤に登録されているユーザの認証しかできません．言い換えれば，本学のユーザ認証基盤に登録されていない閲覧者を許可することはできません．第3の方法は，本学のユーザ認証基盤に登録されていない閲覧者を扱うことができますが，その代わりに，閲覧用のユーザ名・パスワードをどのように配布するのか? などの鍵配布問題が発生します．

特定のIPアドレスからだけアクセスできるページは作れますか?

はい．

アクセス制限したいフォルダ(ディレクトリ)に，以下のような内容の .htaccess を置いてください．

Order Deny,Allow
Deny from All
Allow from 133.15.xxx

xxx の部分は，適宜にアクセス制限したい範囲で置き換えてください．また，Orderディレクティブの書式に注意してください．「Deny」と「Allow」の間は，空白ではなく半角のカンマです．

なお，本学構成員だけがアクセスできるページを作成するために，以下のような内容の .htaccess を記述することは推奨されません．

Order Deny,Allow
Deny from All
Allow from 133.15

学内にはゲスト利用するための無線 LAN が整備されていますが，この無線 LAN を利用している端末にも，133.15.0.0/16 なグローバル IP が付与されています．そのため，上記のように 133.15.0.0/16 のみにアクセスを制限したとしても，学外者がアクセスする可能性があります．本学構成員だけがアクセスできるページを作成したい場合は，本学のユーザ認証基盤を利用する方法を検討して下さい．

メールを送信する CGI は作成できますか?

はい．ただし，悪用できないように，慎重な設計をおこなってください．

sendmail 互換のプログラムが /usr/lib/sendmail にインストールされています．しかし，直接に呼び出すことは推奨できません(将来，パスが変更になる可能性があります)．

perl スクリプトの場合，Mail::Sendmail などを使うことを推奨します．共通サーバには，Mail::Sendmail は既にインストール済みですので，単に以下のように記述すれば利用できます．

use Mail::Sendmail;

PHPスクリプトの場合、mb_send_mail関数を使うと、sendmailコマンドを経由してメール送信することが可能です。 mb_send_mail関数はmail関数のラッパーになっていますので、mail関数の説明も参照してください。これらの関数は標準で用意されていますから、使うために特別な操作は不要です。

CGI で jcode.pl は使えますか?

いいえ。 jcode.pl は Perl4 のための日本語変換モジュールです。 Encoding モジュールなど、Perl5 のための日本語変換モジュールをご利用ください。

/cgi-bin/ 以外に CGI を置きたいんだけど?

可能です．適当なディレクトリに拡張子が .cgi のファイルを置き，かつ，そのディレクトリに以下のような内容を含む .htaccess ファイルを置いてください．

Options +ExecCGI

PHP で記述されたページは表示できますか?

簡単な答: できます．適当なディレクトリに拡張子が .php のファイルを置き，かつ，そのディレクトリに以下のような内容を含む .htaccess ファイルを置いてください．

Options +ExecCGI

複雑な答: できます．ただし，共通サーバには mod_php はインストールされていません(mod_php はスレッドセーフではないので，worker MPM が使用できないため)．代わりに mod_fcgid がインストールされていて，拡張子が .php であるファイルを CGI として解釈・実行するように設定してあります．そのため，CGI の実行が許可されていないディレクトリでは，拡張子が .php であるファイルは処理されないので，上述のような .htaccess ファイルが必要になります．

アクセスログを見れませんか?

https://imc.tut.ac.jp/log/ドメイン名/ というURLのウェブページで確認できます．

コンテンツ管理システム（CMS）を使いたいんだけど?

WordPress, MovableType, Drupal等のCMSを設置頂けます。 CMSに必要なデータベース（MySQL）を設置しますので以下の申請ページより申請下さい。自身が申請したドメイン、または申請者が許可したアカウントが設定されているドメインが表示されますので、対象ドメインが見当たらない場合はドメイン管理者に申請または自身のアカウントで申請可能にするよう設定して頂く必要があります。

* https://imc.tut.ac.jp/alt/apply/hosting/portal.php

CMSはWebコンテンツを管理する上で大変便利ですが、同時に多くの攻撃者から狙われています。 2017年2月発生した大規模なWebサイト改ざん攻撃では、下記のように国内大学のWebサイトを含む多数の被害が発生しました。

このような被害を防ぐため、CMSを設置する場合は次の項目を必ず守って下さい。

だからCMSは狙われる　WordpressやDrupalに攻撃が相次ぐわけ (1/2) - ITmedia エンタープライズを一読し、CMSを設置する上で注意するべき事項について確認下さい。
セキュリティアップデートなどCMSの管理は，情報メディア基盤センターではなく，ホスティングサービス利用者に責任があります．
CMSの管理者には複雑なパスワード（例えば8文字以上、英数記号混在など）を設定して下さい。
CMS管理画面（WordPress: wp-login.php, MovableType: mt.cgi）には、.htaccessによるアクセス制限を設定して下さい。
- Digest認証によるユーザ認証やアクセス元IPアドレスの制限によって、不正なユーザがCMS管理画面にアクセスできないようにして下さい。
- アクセス制限の設定の仕方はこちらを参照下さい。
WordPressを設置する場合は必ず WordPressの自動更新設定を有効にして下さい。
- 自動バックグラウンド更新の設定 - WordPress Codex 日本語版

Shibboleth認証を設置しているWebサイトの証明書更新を行いたい（VM編）

Shibboleth認証を設置しているWebサイトでは，正しい順序で証明書の更新を行わない場合、証明書更新後に認証が行えなくなります．また証明書の更新はサーバ管理者だけで行うことはできず，情報メディア基盤センター側の作業も必要になります．

以降では、2種類の証明書更新手順を説明します。一つ目は、Shibboleth認証を停止することなく証明書の更新を行う方法です。Shibboleth認証が停止しない代わりに、作業を3日間に分けて行う必要があります。二つ目は、一時的に数時間程度Shibboleth認証が利用できなくなる更新方法です。代わりに1日で更新作業を終えることができます。作業体制や手間などを考慮の上、どちらかの手順をお選び下さい。

証明書更新手順1（Shibboleth認証の停止なし）

手順1（作業者: Webサイト管理者）

https://imc.tut.ac.jp/beta/upki/action/start にアクセスし、新しい証明書・秘密鍵を取得する
WebサイトのApacheで使う証明書・秘密鍵を交換する．旧証明書・旧秘密鍵もこのときの作業で必要になるので削除しないこと．

新しい証明書・秘密鍵を復号のために使うようにShibboleth SPを設定する

/etc/shibboleth/shibboleth2.xmlで次のようになっている箇所を探す

<CredentialResolver type="File" key="旧秘密鍵ファイル名" certificate="旧公開鍵ファイル名"/>

この箇所を次のように書き換える

<CredentialResolver type="Chaining">
    <CredentialResolver type="File" key="新秘密鍵ファイル名" certificate="新公開鍵ファイル名" use="encryption"/>
    <CredentialResolver type="File" key="旧秘密鍵ファイル名" certificate="旧公開鍵ファイル名"/>
</CredentialResolver>

shibdを再起動する
```
% service shibd restart
```

作業が終わったことを情報メディア基盤センターに連絡する

手順2（作業者: 情報メディア基盤センター）

新証明書をメタデータに予備鍵として登録する
Webサイト管理者に連絡を行う

手順3（作業者: Webサイト管理者）

新しい証明書・秘密鍵を主として利用するようにShibboleth SPの設定を行う

/etc/shibboleth/shibboleth2.xml内で「use="encryption"」の位置を変更する

<CredentialResolver type="Chaining">
    <CredentialResolver type="File" key="新秘密鍵ファイル名" certificate="新公開鍵ファイル名"/>
    <CredentialResolver type="File" key="旧秘密鍵ファイル名" certificate="旧公開鍵ファイル名" use="encryption"/>
</CredentialResolver>

shibdを再起動する
```
% service shibd restart
```

作業が終わったことを情報メディア基盤センターに連絡する

手順4（作業者: 情報メディア基盤センター）

メタデータから旧証明書を取り除く
Webサイト管理者に連絡を行う

手順5（作業者: Webサイト管理者）

Shibboleth SPから旧証明書・旧秘密鍵を削除する
1. /etc/shibboleth/shibboleth2.xmlを下記のように編集して，元々の内容に戻す
```
<CredentialResolver type="File" key="新秘密鍵ファイル名" certificate="新公開鍵ファイル名"/>
```
2. shibdを再起動する
```
% service shibd restart
```
3. 旧証明書・旧秘密鍵を削除する

証明書更新手順2（Shibboleth認証の停止あり）

手順1 Apacheで使う証明書・秘密鍵を交換する

手順2 /etc/shibboleth/shibboleth2.xml の証明書部分を次のように変更する

変更前: 
<CredentialResolver type="File" key="旧秘密鍵ファイル名" certificate="旧公開鍵ファイル名"/>

変更後: 
<CredentialResolver type="File" key="新秘密鍵ファイル名" certificate="新公開鍵ファイル名”/>

手順3 Shibbolethを再起動する

# service shibd restart

手順4 作業が終わったことを情報メディア基盤センターに連絡する

Webページが「この接続ではプライバシーが保護されません」となり、コンテンツが表示されない

証明書の有効期限が切れていますので以下より発行依頼をお願いします。

https://imc.tut.ac.jp/beta/upki/action/start

有効期限の確認はURLの側面にある鍵マーク（ブラウザによって異なります）から確認ができます。 SSLサーバ証明書の発行手続きの流れは以下の通りです。

https://imc.tut.ac.jp/wiki/UPKI?highlight=%28%E8%A8%BC%E6%98%8E%E6%9B%B8%29

サーバ証明書発行・更新手順

手順１：あらかじめ、以下の情報を入手してください。

サーバのホスト名（例: kyomu.office.tut.ac.jp）
サーバを別名で運用している場合、その別名（例: www.kyomu.office.tut.ac.jp）
サーバソフトウェア名と、そのバージョン（例: Apache 2.2.16, IIS 7.0 など）　※ホスティングサービスの場合は、Apache 2.4.25

手順２：UPKI SSL サーバ証明書の Webページにアクセスします。

https://imc.tut.ac.jp/beta/upki/action/start

手順３：「A: 証明書発行要求(CSR)と秘密鍵の生成」→「証明書をインストールするサーバのホスト名」を入力「CSR と秘密鍵を生成する」ボタンをクリックします。

手順４：「秘密鍵をダウンロードする」ボタンをクリックします。

kyomu.office.tut.ac.jp の場合は、kyomu.office.tut.ac.jp.key という名前のファイルが生成されます。

手順５：「次に進む」ボタンをクリックします。

手順６：「証明書を使うサーバソフトウェア名と、そのバージョン」を入力します。

サーバを別名で運用している場合は、「サーバの別名の入力欄を追加する」ボタンをクリックし、表示された「証明書をインストールするサーバの別名」欄にサーバの別名を入力します。たとえば以下のようなケースです。
https://office.tut.ac.jp
https://www.office.tut.ac.jp

手順７：「依頼する」ボタンをクリックします。

手順８：情報メディア基盤センター宛に「以下の証明書要求を提出します」という内容のメールが（IMCへ）送信（自分もCCにはいっています）されたことを確認します。

kyomu.office.tut.ac.jp の場合、メール件名は以下のようになります。
新規の場合: 「NEW CSR for kyomu.office.tut.ac.jp」
更新の場合: 「UPDATE CSR for kyomu.office.tut.ac.jp」このメールはIMCが受領し手順９につながる作業を行いますので利用者はメールが送信されたことを確認し、手順９のメール受信を待ってください。

手順９：SSL サーバ証明書が発行されたら、その旨を伝えるメールが送信されます。

手順１０：メールの記載内容にしたがってサーバ証明書をダウンロードします。

メールの件名は、「[UPKI] サーバ証明書発行受付通知 / [UPKI] server certificate issue acceptance notice」です。ダウンロードファイルはkyomu.office.tut.ac.jp.cerとなります。

手順１１：発行された「秘密鍵」と「サーバ証明書」を USBメモリにいれて情報メディア基盤センター 2F 203 下條まで持参してください。