重要な Note: 複数の .wsgi ファイルを使用する場合 (それぞれのファイルに別個の Trac environment を設定するケースなど) は、 os.environ['TRAC_ENV'] には Trac environment のパスを 設定しない でください。この方法を使うと、別の Trac environment の設定が Trac にロードされてしまうことがあります。 (以前にロードした Trac environment のパスが使われてしまいます。) この問題は .wsgi ファイルの内容を下記の通り変更することで回避できます:

import os

os.environ['PYTHON_EGG_CACHE'] = '/usr/local/trac/mysite/eggs'

import trac.web.main
def application(environ, start_response):
  environ['trac.env_path'] = '/usr/local/trac/mysite' 
  return trac.web.main.dispatch_request(environ, start_response)

ここで、

os.environ['TRAC_ENV_PARENT_DIR'] = '/path/to/parent-dir'

を使っていた場合、これを回避コードに置き換えるには、 environ の添え字を 'trac.env_parent_dir' としてあげればいいみたいです。

def application(environ, start_response):
        environ['trac.env_parent_dir'] = '/path/to/parent-dir'
        return trac.web.main.dispatch_request(environ, start_response)

弊社の場合、一方を公開のプロジェクト、もう一方を非公開のプロジェクト (SSL 通信限定でパスワード保護) としていたのに、リロード繰り返したら公開の方の URL が非公開の内容を指していたりで機密的にかなりやばいことになっていた (^_^;;; ので、似たようなことをやろうとしている方は厳重に注意が必要です…。

直接お金になる仕事ではないのですが、ここしばらく、某所の BBS を開発するため、 Perl をいじっております。正直、 .NET や JavaScript 、ケータイアプリの開発なんてことばかりやっておりますと、たまにいじる Perl が楽しくて楽しくて、ついついこっちばかりやってしまう、という日々がしばらく続いております。いかんですな。

で、こちらの開発がとりあえずキリの良いところまで進んだので、一旦お蔵入りにしようと思うのですが (といっても年単位で寝かせるわけではないですが)、その前にこれに関連する技術的なメモをしたためておこうかと思うのであります。

作っているのは、さくらの共有レンタルサーバーサービス上で動作する CGI なのですが、レンタルサーバの性質上、 CPAN から最新のモジュールを引っ張ってくることが出来るので、割とモダンチックなスタイルで開発できるのが強みだったりします。

ただ、レンタルサーバ上で動作確認する場合、 500 エラーになってもエラーログをすぐには参照できないので (さくらにメールで問い合わせすることは可能らしいですが…)、弊社サーバー上にも設置し、動作確認するようにしました。

弊社サーバーはさくらの VPS を利用しており、 CentOS5 で動いています。基本的にはソフトウェアの導入は yum から行っているのですが、その場合、 DBD::mysql を始めとした多くの CPAN モジュールが、かなり古いバージョンで導入されることになります。特に、 DBD::mysql は 3.0007 と極めて古く、Unicode を扱うのに必要不可欠な接続時オプション mysql_enable_utf8 が使えないといった弊害がありました。他にも、 DateTime がタイムゾーンを理解できないなど、いろいろと弊害があったため、 CPAN から最新版をインストールしようかと試みたのですが、そのままではほとんどのモジュールについてコンパイルが通らないなど、cpan コマンドからではインストールが出来ませんでした。

CPAN 自体を最新版に

まず、cpan コマンドとして動作する Bundle::CPAN モジュール自体が古いので、それを最新にしてしまいましょう。

$ sudo cpan -i Bundle::CPAN

さらに、導入済みのモジュールを最新版に一括して更新してしまいましょう。こちらは cpan コマンドからではうまくいかなかったので、 perl から。

$ sudo perl -MCPAN -e 'CPAN::Shell->install(CPAN::Shell->r)'

DBD::mysql のインストールには MySQL 自体のソースが必要

ここまでやっても、DBD::mysql のインストールはやっぱり失敗していて、古いバージョンのままです。

$ perl -MDBD::mysql -e 'print "$DBD::mysql::VERSION\n"'
3.0007
$

結論から言うと、DBD::mysql を make する際に、MySQL 自体のヘッダファイルを参照しており、単に yum から MySQL だけを入れた状態ではこのヘッダファイルが導入されていないために、コンパイルに失敗してしまいます。そこで、 MySQL の開発用リソースを導入するパッケージ mysql-devel を事前に入れておく必要があります。

$ sudo yum install mysql-devel
$ sudo cpan -i DBD::mysql

これで、最新の DBD::mysql のインストールが成功するはずです。

サーバー全体の動作が重くなるのをどうにかする

さくらの VPS を利用するようになってから、サーバー全体の動作が重いのが気になっていました。結論から言うと、 Apache がメモリーを食いつぶし、スワップを引き起こしまくっていたからでした。

Trac のページやこのブログ、会社のトップページでさえ、表示するのにやたらと時間がかかるので、 ssh で接続して状況を見ようとすると、その ssh での応答も非常に時間がかかるという状態。まさかこれが単体の専用サーバーと VPS の差だとは到底思えなかったので、 ps -AF するなり top するなりして軽く状況を見てみると、メモリーどころかスワップ領域もほぼフル回転で httpd が食いつぶしていた。こりゃああかんと言うことで、ネットで調べつつ設定を修正…。

起動するプロセスの数を減らす

とりあえず応急処置と言うことで、一度に起動するプロセスの数を減らすことを考えてみた。以下のサイトが参考になりました。

• ウノウラボ Unoh Labs: Apache MPM の基礎をしっかりと理解しよう！

まず MPM に何を選択しているのかを知る必要があります。 CentOS を採用しているさくらの VPS では prefork MPM が選択されていました。

$ cat /etc/sysconfig/httpd
# Configuration file for the httpd service.

#
# The default processing model (MPM) is the process-based
# 'prefork' model.  A thread-based model, 'worker', is also
# available, but does not work with some modules (such as PHP).
# The service must be stopped before changing this variable.
#
#HTTPD=/usr/sbin/httpd.worker

(以下略)

その場合、 httpd.conf ファイルにて修正すべきは、以下の部分と言うことになります。

<IfModule prefork.c>
StartServers       8
MinSpareServers    5
MaxSpareServers   20
ServerLimit      256
MaxClients       256
MaxRequestsPerChild  4000
<IfModule>

基本的に社員2名の会社で社内サービスがメイン、会社サイトもこのブログもそれほど頻繁にアクセスされているわけでもないのに、プロセス 256個同時起動はまずあり得ないでしょう。プロセス 1つで 70MB ぐらい消費してしまうのに、メモリー 512MB、スワップ領域 2GB でプロセスをそんなに確保できるわけがありません。

また、待機するプロセス数の最大 20も大きすぎます。一度作られた待機プロセスは Apache を再起動でもしない限りは残ったままになってしまうらしく、メモリー使用量を抑えたいのであれば、この数を減らしてやる必要があります。

というわけで、変更後の内容は以下の通りです。

<IfModule prefork.c>
StartServers       8
MinSpareServers    5
MaxSpareServers   10
ServerLimit       15
MaxClients        15
MaxRequestsPerChild  4000
</IfModule>

とりあえずこの設定で数日間動かしてみたところ、それでもまだメモリーは景気よく食いつぶされているものの、重たくて使い物にならないような状況には至らなくなりました。

使わなさそうなモジュールをざっくり外す

1つ1つのプロセスが消費するメモリー容量がそもそも大きいので、シェイプアップも図ってみることにしました。デフォルトでロードするよう設定されているモジュール類でも、必ずしも全て必要なわけではなく、使わないモジュールを外すことでメモリー使用量を抑えることができるという情報を見つけたので、Apache のドキュメントとにらめっこしながら、今は使っていないし近い将来使う予定もなさそうなモジュールを威勢よく外してみました。

LoadModule auth_basic_module modules/mod_auth_basic.so
LoadModule auth_digest_module modules/mod_auth_digest.so
LoadModule authn_file_module modules/mod_authn_file.so
#LoadModule authn_alias_module modules/mod_authn_alias.so
#LoadModule authn_anon_module modules/mod_authn_anon.so
#LoadModule authn_dbm_module modules/mod_authn_dbm.so
LoadModule authn_default_module modules/mod_authn_default.so
LoadModule authz_host_module modules/mod_authz_host.so
LoadModule authz_user_module modules/mod_authz_user.so
LoadModule authz_owner_module modules/mod_authz_owner.so
#LoadModule authz_groupfile_module modules/mod_authz_groupfile.so
#LoadModule authz_dbm_module modules/mod_authz_dbm.so
LoadModule authz_default_module modules/mod_authz_default.so
#LoadModule ldap_module modules/mod_ldap.so
#LoadModule authnz_ldap_module modules/mod_authnz_ldap.so
#LoadModule include_module modules/mod_include.so
LoadModule log_config_module modules/mod_log_config.so
LoadModule logio_module modules/mod_logio.so
LoadModule env_module modules/mod_env.so
#LoadModule ext_filter_module modules/mod_ext_filter.so
LoadModule mime_magic_module modules/mod_mime_magic.so
LoadModule expires_module modules/mod_expires.so
#LoadModule deflate_module modules/mod_deflate.so
LoadModule headers_module modules/mod_headers.so
#LoadModule usertrack_module modules/mod_usertrack.so
LoadModule setenvif_module modules/mod_setenvif.so
LoadModule mime_module modules/mod_mime.so
LoadModule dav_module modules/mod_dav.so
#LoadModule status_module modules/mod_status.so
LoadModule autoindex_module modules/mod_autoindex.so
#LoadModule info_module modules/mod_info.so
LoadModule dav_fs_module modules/mod_dav_fs.so
LoadModule vhost_alias_module modules/mod_vhost_alias.so
LoadModule negotiation_module modules/mod_negotiation.so
LoadModule dir_module modules/mod_dir.so
#LoadModule actions_module modules/mod_actions.so
#LoadModule speling_module modules/mod_speling.so
#LoadModule userdir_module modules/mod_userdir.so
LoadModule alias_module modules/mod_alias.so
LoadModule rewrite_module modules/mod_rewrite.so
#LoadModule proxy_module modules/mod_proxy.so
#LoadModule proxy_balancer_module modules/mod_proxy_balancer.so
#LoadModule proxy_ftp_module modules/mod_proxy_ftp.so
#LoadModule proxy_http_module modules/mod_proxy_http.so
#LoadModule proxy_connect_module modules/mod_proxy_connect.so
#LoadModule cache_module modules/mod_cache.so
#LoadModule suexec_module modules/mod_suexec.so
#LoadModule disk_cache_module modules/mod_disk_cache.so
#LoadModule file_cache_module modules/mod_file_cache.so
#LoadModule mem_cache_module modules/mod_mem_cache.so
LoadModule cgi_module modules/mod_cgi.so
#LoadModule version_module modules/mod_version.so

厳密にはこれに加えて、さらに conf.d/proxy_ajp.conf や conf.d/welcome.conf の中身をコメントアウトしてみたりもしています。結果として、メモリー使用量はプロセス当たり 70MB ぐらいだったのが 50MB ぐらいまでスリムアップしました。

WebDAV 設定

社内で一時的なファイルのやりとりをするのに使用する共有フォルダ的なものが欲しかったので、WebDAV を設定して Web フォルダとして使用することにしました。要件としては以下の通りです。

• クライアントは Windows および Mac OS X (あとたまに Ubuntu)。
• 社外には公開しない。
  • 認証が必要。匿名アクセスは不許可。
  • SSL による通信の保護が必要。

まず、SSL を使用するため、 developer.harapeko.jp サブドメインを使用することにしました。 WebDAV の為のディレクトリは、 developer.harapeko.jp サブドメイン用に用意しているディレクトリ下に作成することにします。

$ mkdir -p /var/www/vhosts/developer/dav/davroot

dav ディレクトリ、dav/davroot ディレクトリの両方に、 apache ユーザーが書き込みを行う権限が必要です。

次に、ダイジェスト認証用の認証ファイルを davディレクトリ下に作成します。 realm を DAV とする場合、

$ htdigest -c /var/www/vhosts/developer/dav/.htdigest DAV murachi

とかやって、パスワードを設定します。 2人目以降は -c オプションは不要です。

そして、conf.d/ssl.conf (SSL が適用されているヴァーチャルホストに対して設定を行うので、conf/httpd.conf ではないという点に注意) の <VirtualHost> セクション内に、以下の設定を書き加えました。

<ifmodule mod_dav.c>
    DavLockDB /var/www/vhosts/developer/dav/DavLock

    Alias /dav /var/www/vhosts/developer/dav/davroot
    <Location /dav>
        Order Allow,Deny
        Allow from all
        Options +Indexes
        Dav On

        AuthType Digest
        AuthName DAV
        AuthUserFile /var/www/vhosts/developer/dav/.htdigest
        <LimitExcept OPTIONS>
            Require valid-user
        </LimitExcept>
    </Location>
    <Location />
        Header add MS-Author-Via "DAV"
    </Location>
</ifmodule>

あとは Apache を再起動すれば ok です。

設定ファイルについて軽く解説すると、まず、最後の

    <Location />
        Header add MS-Author-Via "DAV"
    </Location>

の部分は、Windows から Web フォルダとしてアクセスする場合に必ず必要になります。この記述がないと、Windows クライアントは /_vti_inf.html ファイルが見つからないなどという意味不明なエラーを吐いてこけてしまいます。この設定のロケーションは / でなければなりません。

それから、

        <LimitExcept OPTIONS>
            Require valid-user
        </LimitExcept>

の部分は、本来であれば

        Require valid-user

のみであるべきなのですが、Digest 認証を用いる場合には、上記のように書かないと、やはり Windows の Web フォルダとして利用することができません。これはどうやら Windows の (IE の?) バグのようで、 OPTIONS メソッドでアクセスする際にのみ、 Digest 認証が理解できないからなのだそうです。

この辺の、 Windows の Web フォルダ機能に絡んだ設定方法については、以下のサイトが参考になりました。

• WebDAVサーバの構築 – KamoLand
• Web フォルダで WebDAV – reroの日記

と、いっても、現状何かサービスを展開しているわけでも無し、本ブログもこれまで通りそのまま閲覧できますので、「だから何?」とか言われちゃうと困ってしまうわけですが…。

今回の移転作業に於きましては、すべての作業内容を逐次メモに取り、その内容を公開しております。弊社のように、既に他社の専用サーバや VPS を用いてサーバーを構築しているものの、とっても安価でよさげなさくらの VPS に移行したいなぁなどとお考えの方々に、少しでも参考になれば幸いです。

• さくらの VPS セットアップメモ

とりあえず svn だけ設定しました (←まだ匿名アカウントを用意していないので私以外はアクセスできませんが…)。Subversion/WebDAV は初めて設定するのでちょっと手こずりました。

設定の際に参考にさせて頂いたサイトを以下に記します (敬称略)。多謝!!

• Fedora Core 3 で WebDAV/Subversion を使おう

  基本的な内容は概ねここに書かれていました。SELinux は使っていないのですが…。

• メモ/WebDAVでSubversion – SaikyoLine.jp

  Apache 側での設定がもう少し詳しく触れられています。ユーザー毎の制御についても書かれています。

• AuthzSVNAccessFile – 気の向くままに･･･ – livedoor Wiki（ウィキ）

  ユーザー毎の制御を行う AuthzSVNAccessFile の設定方法について解説されています。

• G-chan Square – subversionとWebDAVと

  Subversion/WebDAV でアクセス時に 403 Forbidden エラーが出て失敗してしまう場合は、こちらをチェックしましょう。私もこれでハマりました (^_^;A 。

ファイル構成を検討する

が、その前に、今後もこのサーバーを開発用途に使い続けていくことを考え、使い始めからファイル構成には気を遣ってみようと思い、以下のような方針を出してみました。

• すべての開発関連ファイルは /var/Developer の配下に配置する。
• オリジナルの開発物と、外部から委託された案件とで全体を二分する。
• その中で、プロジェクト毎にディレクトリを設ける。
• プロジェクトのディレクトリ毎に、単独の svn リポジトリと trac リポジトリを設ける。

これを例示すると、以下のようなファイル構成となります。

/var/Developer/
  original/    # オリジナル用
    foo/    # プロジェクト foo
      svn/    # foo の svn リポジトリ
      trac/    # foo の trac リポジトリ
      .htdigest    # 内緒のプロジェクトの場合、 Trac にログオンするためのダイジェスト認証ファイル
    bar/    # プロジェクト bar
      svn/
      trac/
    baz/    # プロジェクト baz
    # ...
  trust/    # 外部から委託された案件用
    hoge/    # プロジェクト hoge
      svn/
      trac/
      .htdigest    # 委託案件は他人にみられちゃまずいので絶対必須
    fuga/    # プロジェクト fuga
    # ...

Trac の導入

それでは Trac を導入しましょう。今回、以下のサイトを参考に、 Trac の導入を行いました。感謝!!

• CentOS & Trac | Hanada.Org
• Trac インストールに挑戦 – メモチョウ

基本的には前者のサイトを参考にしました。後者は python-genshi が yum からは install できなかった点について参考にさせていただきました。

やったことについては概ね以下の通りです。

1. SELinux はそもそも使っていません。 iptables は使っていますが、 yum のポートはフィルタしていないのでここも設定不要でした。
2. Subversion 用 WebDAV モジュールはインストールだけしましたが、秘匿する案件については利用予定はないので、Apache 側の設定まではしませんでした。
3. 今回は外部委託の案件なので、この案件のファイルにアクセスできる権限のためのグループを設けました。

   % sudo groupadd hoge
   % sudo vim /etc/group # グループにユーザーを追加する
   

4. Subversion リポジトリを構築します。だいたい以下のような感じです。

   % su -
   % mkdir -p /var/Developer/trust/hoge/svn
   % cd /var/Developer/trust/hoge/svn
   % chown murachi.hoge .
   % chmod g+w .
   % chmod g+s .    # 配下のファイルのデフォルトグループ権限が統一される
   % exit    # root のままリポジトリ作ると import 時に問題が起こるので…
   % svnadmin create /var/Developer/trust/hoge/svn

   そして手元の環境から、既に作り始めているファイルをディレクトリごと import します。 Linux 環境、あるいは Cygwin などを利用しているならば、以下の通り。

   % svn import /path/to/hoge svn+ssh://murachi@onaka.harapeko.jp/var/Developer/trust/hoge/svn/trunk/hoge

   trunk/hoge がインポート先パスに追加されているのは、メイントランクのプロジェクト名にファイルを突っ込みたいから。 TortoiseSVN を使うのであれば、インポートするフォルダを選択して、上記と同様の URI を指定してあげれば ok 。別の場所に同様の URI でチェックアウトできることも確認しておきましょう。

5. Trac をインストールします。先ほどのサイトを参照して、 yum のリポジトリ追加を行ってからインストールを試みます。が、python-genshi が無いよ、と怒られてしまいますので、これだけは rpm パッケージを拾ってきて手動でインストールする必要があります。

   % sudo yum install python-setuptools    # python-genshi のインストールに必要でした。
   # 事前にディレクトリを参照して最新版のファイル名を確認しておきましょう。。。
   % wget http://packages.sw.be/python-genshi/python-genshi-0.5.1-2.el5.rf.i386.rpm
   % sudo rpm -i python-genshi-0.5.1-2.el5.rf.i386.rpm
   % sudo yum install trac

   ここでインストールされる Trac は英語版なので、これは一旦削除し、代わりに日本語版の Trac をインストールします。

   % sudo yum remove trac
   # これも事前に最新版のファイルの URI を確認しておきましょう。。。
   % wget http://www.i-act.co.jp/project/products/downloads/Trac-0.11.2.1.ja1.zip
   % unzip Trac-0.11.2.1.ja1.zip
   % cd trac-0.11.2.1.ja1
   % sudo python setup.py install

6. trac リポジトリを構築します。
   普通に作ろうとすると DBMS に SQLite を使用するようになるのですが、今回は MySQL を使いたかったので、こちらのサイトを参考に、データベースの構築から行います。ちなみに、 MySQL は既にインストールされていて、使える状態になっているものとします。

   % mysql -u root -p
   mysql> create database trac_hoge;
   mysql> grant all privileges on trac_hoge.* to trac_hoge@localhost identified by 'password';
   mysql> use trac_hoge;
   mysql> alter database default character set utf8 collate utf8_general_ci;
   mysql> quit
   % su -
   % mkdir /var/Developer/trust/hoge/trac
   % cd /var/Developer/trust/hoge/trac
   % chown murachi.apache .    # apache から扱えるように。
   % chmod g+w .
   % chmod g+s .
   % exit
   % trac-admin /var/Developer/trust/hoge/trac/hoge initenv

   そして、database connection string について聞かれたら、以下のように入力します。

   mysql://trac_hoge:password@localhost/trac_hoge

7. Apache に設定を追加します。弊社の環境ではヴァーチャルホスト設定によってサブドメインを追加しているので、そのディレクティブ内に設定を記述します。今回は秘匿する必要があり、 SSL を介して用いたいので、 /etc/httpd/conf.d/ssl.conf の中に設定を記述します。

   その前に、ダイジェスト認証を用いたいので、まずはダイジェスト認証用のユーザー定義ファイルを作成します。

   % htdigest -c /var/Developer/trust/hoge/.htdigest realm murachi

   設定の記述内容は、概ね以下の通りです。

   <VertualHost>
   
   # ...
   
   # trac location
   <Location /trust/hoge/trac>
       SetHandler mod_python
       PythonDebug On
       PythonHandler trac.web.modpython_frontend
       PythonOption TracEnvParentDir /var/Developer/trust/hoge/trac
       PythonOption TracUriRoot /trust/hoge/trac
   </Location>
   
   <Location /trust/hoge>
       AuthType Digest
       AuthName realm
       AuthUserFile "/var/Developer/trust/hoge/.htdigest"
       Require valid-user
   </Location>
   
   </VirtualHost>

   Digest 認証の場合、 AuthName は realm でなければなりません。もっとも、 SSL で通信路自体が暗号化されているので、 Basic 認証でも問題なかったかも知れませんが…。

   それから、Digest 認証で AuthUserFile ステートメントを用いるのは Apache 2.2 以降で、 2.0 以前の場合は AuthDigestFile ステートメントを使用します。

8. 設定が文法上問題ないことを確認してから、 Apache を再起動します。

   % sudo /etc/init.d/httpd configtest
   % sudo /etc/init.d/httpd restart

URI がいまいち…

以上ですべての準備が整いました。ブラウザから、 https://developer.harapeko.jp/trust/hoge/trac に接続してみます。すると、以下のようなページが表示されました。

えっと…。どうやらここには Trac そのものではなく、 Trac のリポジトリを設定したプロジェクトの一覧が配置される模様。

で、表示されているリンクをクリックすると Trac のトップページに遷移するのですが…

URI の中にプロジェクト名が 2つ重なって出てきてしまう。これは何ともイタダケナイ。

構成を再検討

そんなわけで、ファイルの構成を再検討中です。とりあえず、反省点としては以下の通りでしょうか。

• svn リポジトリと trac リポジトリは、やっぱり完全に分けた方がよさそう。そもそも、svn リポジトリは unix ユーザーで権限を制御しているのに対して、 trac は Web の認証で権限を制御するので、あんまり一緒に管理するメリットはない気がしてきた。
• trac リポジトリはオリジナル用と外注用の 2つに分けた上でプロジェクト毎に作成し、DB もプロジェクト毎に別個に作成する。アクセス制限はプロジェクトごとにロケーション別で設定可能だが、外注用についてはプロジェクト一覧ページには自分以外は入れないように制限する必要がある (オリジナルも同様に制限するかも…)。
• svn リポジトリはプロジェクトごとに別個に作成する。公開している Trac から svn リポジトリを覗いてみたら外注で開発しているソースが見えちゃったでござるの巻、なんてことがあってはならない。

構成例としては以下のような感じでしょうか…。

/var/Developer/
  svn/
    original/
      foo/
      bar/
      baz/
      # ...
    trust/
      hoge/
      fuga/
      # ...
  trac/
    original/    # オリジナル用の TracEnvParentDir になる
      foo/
        .htdigest    # 認証用のユーザー定義ファイルはリポジトリの中に置いてしまう
      bar/
      baz/
      # ...
    trust/
      hoge/
        .htdigest
      fuga/
        .htdigest
      # ...

という感じで軽くメモを書くだけのつもりが長々と書いてしまいました。これからまた設定です。おなか空いた…。

まだ未確定な部分が多々あるのであまり公にはできないのですが、やっと会社としての初めてのお仕事がもらえそうです。この不況時になんてありがたい…。

で、せっかくなので、会社のサーバー (まさにこのサイトを動かしているサーバーですね) をソースやタスクの管理に利用しようと思いたったのですが、情報が外部に漏洩するリスクは極力抑えなければなりません。

そこで、秘密の情報を扱うページに認証をかませ、さらに SSL による暗号化をかませることで、通信路の安全性を確保することを考えました。これ、ちゃんとやろうとするのであれば、SSL 証明書を正規の認証局に発行してもらい、それを導入する必要があります。仕事で使うものを個人認証局でごまかして客先で警告ダイアログとか表示されちゃったら信用失っちゃいますし、そうでなくても産総研のあのお方とかに見つかって Dis られでもしたものなら今度は社会的な信用を失っちゃいますからね (^_^;A 。

検討

とはいえ、SSL 証明書の発行にはお金がかかります。特に、 VeriSign 社の証明書など導入しようものなら、もっともリーズナブルな「セキュア・サーバID」でも年間 85,050円とかしちゃいます。これまで仕事に恵まれず、公共料金を浪費し続けていただけの弊社の資金からはとてもとても捻出できません＞＜。

でも大丈夫。探せばもっともっとリーズナブルな証明書は見つかるのです。というわけで、今回は DigiTrust 社さんの「DigiTrust Standard」を利用させていただくことにいたしました。とりあえず 1年契約で 15,540円。これなら社員一人の超零細企業でも何とか手が出る金額設定です。

購入

まず、申し込みフォームにいろいろ入力する前に、実際に SSL 証明書を導入するホスト上で CSR (Certificate Signing Request = 署名要求) を作る必要があります。やり方は DigiTrust 社のサイト上にばっちり書かれています。弊社の場合、使用しているデルタ1 が CentOS で、Apache2 も mod_ssl も最初から入っていたので、書かれている通りにコマンドを入力するだけで ok でした。できあがったファイルは rsync などを使って手元のマシンに転送すれば良いでしょう。

あとは申し込みフォームに必要事項を記入すれば、翌日には請求書が PDF で送られてきます。で、請求通りに銀行に振り込むと、即座に証明書のファイルが送られてきます。早い!!

設定

設定方法も、DigiTrust 社さんのサイトに書かれています。こちらも概ね書かれている通りにすれば ok です。ただ、弊社の場合、 iptables でポートフィルタリングしていたのをすっかり忘れていたために (^_^; 、https スキーマから接続しようとしても応答せず、そこで 2時間ぐらいハマりましたが (バカだ… orz)。

確認

とりあえずこんな感じです。これから、この配下に開発リソースをいろいろと追加していく予定です…。ウヒヒ。

サーバーを借りる

今回借りたのは、ファーストサーバさんとこの、デルタ1・シリーズというやつです。このサービスは、ソフトバンクIDC のデータセンターに置かれたそこそこのスペックのマシン (Celeron420 1.6GHz / 512MB RAM / 80GB HDD) をまるまる一台自由に使わせてもらえるというものです。但し、マシンは CentOS (後になって FreeBSD のコースもできたようですが) をインストールしただけの (そして ssh 以外のサービスを一通り停止させた) 状態で納品され、設定用の特別なツール (Web から操作できるコントロールパネルとか) や、監視などの各種サービスはなく、設定も管理もすべてお客さんの方でやってね、という非常に漢 (おとこ) らしいサービスです。

価格は、初期費用 (入会金のようなもの、恐らくは設備投資費) が 36,750円、月額費用が 6,510円。ノーメンテなだけあって、国内の専用サーバーレンタルサービスとしては非常にリーズナブルです。契約では支払い単位を半年とさせていただいたので、初回の請求金額は 75,810円となりました (次回以降は月額費用のみなので、39,060円を半年ごとに納めることになります)。

さて、私が申し込んだのは 4月の半ば頃で、オンラインお申し込みのページには ご提供まで2週間程度のお時間を… などと書かれていたのですが、実際には申し込みをした2日後には設定完了の報告書が請求書とともに送られてきました。これはうれしい誤算!! まだドメイン名すらなく、IP アドレスだけで ssh からログインできますよーというだけの状態だったのですが、早速中を覗いてみたり、とりあえず惰性で apache を動かしてみたりしました。

ドメインの移転

ここでサーバーの設定の話に入ってもいいのですが、その前に、ドメインの取得と設定について書いた方が、話の流れ的には正しいような気がするので、そうしておこうと思います。

私の場合、 harapeko.jp ドメインは以前から持っていたのですが (いわゆる「ホームページ」を作るために予約していたまま、ほとんど使わずに放置していました)、当時の管理業者であった ISP が提供するサーバーでしか使わせてもらえないというものだったので、他のレジストラに変更する必要がありました。同じファーストサーバさんの Doレジを利用するという手もあったのですが、今後のフットワークも考慮して、JPRS 自体が提供するドメイン名登録管理サービスである JPDirect を利用させていただくことにしました。

ISPとの契約を解約する

まずは JPDirect に申し込む前に、これまでドメイン名を管理してもらっていた ISP との、ドメイン名に関する契約を解約しなければなりません (接続契約まで切る必要はないですよ、念のため)。私の場合は、これはオンラインではなく、申込書を FAX するという手続きでした。

注意点が一つだけあって、ドメイン名を「廃止」するのか、他のサーバーに「移行」するのかを聞かれますので、これは必ず「移行」にしなければなりません。誤って廃止してしまうと、同じドメインは 1ヶ月間利用 (というか取得) できなくなってしまうので注意しましょう。

移転を申し込む

ドメイン名を whois で調べるとこんな感じで表示されるのですが、このときの「登録者名」が元々個人名義だったのを、会社名義に変更したかったので、指定事業者変更WEBで登録者情報を会社の名前にしてみたところ、JPDirect さんから電話がかかってきて、「登録者名を変更したい場合は [移転] という扱いになるので、申し込み方法が異なります」とのご説明をいただきました。指定事業者変更であれば料金は無料だったのですが、移転の場合は有料 (3,885円) になるみたいです。なるほど。

移転申請の場合は、JPDirect に登録 ID を持っていないうちは、本来であればメールにて問い合わせる必要があるのですが、私の場合は先ほどのお電話口にて移転手続きに関するご案内メールを送っていただけるという話になったので、そのメールの案内に従って、移転手続きの Web ページにて必要事項を入力する、という形になりました。

DNS を立てる

レジストラの仕事はドメインの管理だけなので、登録したドメインを使用するホストの IP と結びつけるには、自分で DNS を立てる必要があります。DNS には BIND というのを使用します。これはデルタ1・シリーズのサーバーには最初からインストールされていました。

BIND は chroot 環境で動作するよう設定されていたので、設定ファイルの類はすべて /var/named/chroot ディレクトリの配下に置く必要があります。まずは /var/named/chroot/etc/named.conf を以下のような内容で作成し、

options {
        directory "/var/named";
};
zone "." {
        type hint;
        file "named.root";
};
zone "localhost" {
        type master;
        file "localhost.zone";
        allow-update { none; };
};
zone "0.0.127.in-addr.arpa" {
        type master;
        file "localhost.rev";
        allow-update { none; };
};
zone "harapeko.jp" {
        type master;
        file "harapeko.jp.zone";
};
zone "21.237.218.202.in-addr.arpa" IN {
        type master;
        file "harapeko.jp.rev";
};

さらに、/var/named/chroot/var/named ディレクトリ下に、正引きおよび逆引きのゾーンファイル localhost.zone、localhost.rev、harapeko.jp.zone、harapeko.jp.rev をそれぞれ作成しました。

BIND の設定に関しては、以下のサイトを参考にさせていただきました(敬称略)。感謝!!

• FC Lab – BINDの設定
• @IT – BINDで作るDNSサーバ　第2回　名前解決の仕組みとゾーンファイルの設定
• ごった煮 – CentOS 4.0導入記(覚え書き) – DNSサーバ(bind9)の導入

設定ファイルを書き終わったら、後は BIND を起動すれば ok です。ついでに chkconfig コマンドでデーモンの自動起動の設定もしておきましょう。

% su -
% /etc/init.d/named start
% chkconfig named on    # あるいは ntsysv コマンドによる UI で選択しても ok

ネームサーバーの登録

私はこれを勘違いしていたために無駄に時間を食ってしまったのですが、取得したドメインが実際に運用に乗るためには、取得して DNS を立てる、だけでは駄目で、世界中の DNS が登録したドメインをたどって自分の DNS にたどり着くことができるように、レジストラに DNS があるホストマシンの場所を登録しておかなければなりません。

JPDirect で登録した場合、それは登録者ログインのページから入って行うのですが、それまでのメールや書簡での案内にはこのページについては触れられておらず、そういう設定が必要だという説明もQ&ampA のページに埋もれているだけだったりするので、名前解決の仕組みに関する十分な知識がない人はなかなか気づけないかもしれません (っていうか気づきませんでした、お恥ずかしい)。しかもここで入力する登録者番号やパスワードは、書簡で送られてきた請求書の片割れの隅っこにひっそりと小さく書いてあるだけなので、知らないと捨ててしまって紛失してしまっているかもしれません (っていうか紛失しかけました…)。注意しましょう。

ここで行うべき設定は以下の通りです。

• ネームサーバ設定／解除指定事業者変更や移転の場合は、移行前の事業者が設定していたネームサーバーの設定が残っています。これをそのまま自分のホスト名に変更して登録…できればいいのですが、私がやったときはそれではうまくいきませんでした。いったん前の設定を「解除」してから、新たに設定し直す、という手順を踏む必要があるようです。登録するのはホスト名なのですが、もしかしたら IP アドレスでもいいのかもしれません。私は念のため、 hostname コマンドが返す名前を指定しておくことにしました。
• ホスト情報新規登録DNS の設定で、ネームサーバー用に設定したホスト名と、ホストの IP アドレスを結びつける設定を行います。これはもしかしたら不要なのかもしれません。あるいはネームサーバー設定で指定すべきホスト名をここで定義できる、というだけの話なのかもしれません…。

設定が完了すると、行った設定ごとに JPDirect からメールが送られてきます。実際に設定が反映されるまでにはそれなりに時間がかかります (夜のうちに設定すれば、一晩たてば翌朝には使えるようになる、ぐらいの感覚です)。

今回はここまで。次回は DNS 以外の設定に関するメモを公開します。

そんなわけで、従来使っていたメールアドレスが正式に復活しました。ケータイへの転送用アドレスも復活しています。ここにはそれらのアドレスは書きませんが… (それについてはあとで個人ブログの方でアナウンスします)。

で、それとは別に、仕事用のメールアドレスを追加しました。それはここで公開しておきます。

• toshiyuki.murayama あっとまーく harapeko.jp

すでに取引がある方々にもお伝えしなくては…。あと名刺も作らないとね…。

でも明日は私用で出ずっぱりなのですが…。

なんだかんだで結構忙しいなぁ。

あ、ちなみに、サーバーの設定に関する技術的なメモとかは、別エントリーで後ほど up します～。