Docker を試してみる

GCE (Google  Computer Engine) の無料枠でいろいろ練習してみることにする。関心があったけどこれまで面倒で触れてなかった CentOS7 と Docker。今は CentOS6 を使ってるけどそろそろ次のことも考えて CentOS7 の準備もしておかないといけない。Docker は使いこなせるようになったらインストールとかサーバ移行とかテストとか楽になるんだろうか。

GCE で CentOS7 の準備

インスタンスの作成とSSHでログインできるようにするところは省略。とりあえず yum で update しておく。

$ sudo yum update
$ sudo shutdown -r now

Docker のインストール

参考:

• Qiita:  CentOS7にDockerをインストールする,
• Docker公式: Get Docker CE for CentOS

古い docker がインストールされていないことを確認（インストールされてたら削除する）。
$ sudo yum list installed | grep docker


必要なパッケージをインストール。
$ sudo yum install -y yum-utils device-mapper-persistent-data lvm2

リポジトリ追加。
$ sudo yum-config-manager --add-repo https://download.docker.com/linux/centos/docker-ce.repo

Docker CE をインストールする。CE ってなんだ？ああ、Common Edition か。
$ sudo yum install docker-ce

Docker を起動する。
$ sudo systemctl start docker

確認する。
$ sudo docker run hello-world

Docker Compose のインストール

参考:

• Qiita: CentOS7.3にDocker Composeまでインストール
• Docker公式: Install Docker Compose

Docker Compose のダウンロードとインストール。公式だとcurl でダウンロードした実行ファイルを直接 /usr/local/bin に放り込んでる。引くわ。
$ curl -L https://github.com/docker/compose/releases/download/1.18.0/docker-compose-`uname -s`-`uname -m` -o ./docker-compose
$ sudo install docker-compose /usr/local/bin/

バージョンの確認。
$ docker-compose --version

自分自身を docker グループに追加

docker コマンドを直接実行できるように docker グループに自分を追加しておく。次回ログイン時から有効になる。
$ sudo gpasswd -a $USER docker

composer の更新

mediawiki のいくつかの拡張は composer を使用している。composer が何者かあまり意識してなかったけど、PHP のパッケージ管理ツールということらしい。

composer がどういう状態になっているかサーバを確認してみると mediawiki のホームディレクトリにインストールされていた。

まずはインストールされているパッケージの一覧を確認してみる。 composer show -i で確認できるとのことだ。PHP 自体が scl の管理下にあるのでコマンドラインが長い。

$ sudo -u apache scl enable rh-php56 -- php composer.phar show -i
Warning: This development build of composer is over 60 days old. It is recommended to update it by running "composer.phar self-update" to get the latest version.

パッケージの一覧は確認できたが warning も表示された。composer がちょっと古いらしい。

composer のバージョンは -V で確認できる。

$ scl enable rh-php56 -- php composer.phar -V
Warning: This development build of composer is over 60 days old. It is recommended to update it by running "composer.phar self-update" to get the latest version.
Composer version 1.2-dev (f0f932fca403267a141e91f9262ab649b95b2ed9) 2016-09-10 10:52:23

なるほど。

調べると composer の現行バージョンは 1.5.5 だったが、いきなりあげて動かなくなったら困るので 1.2 系列の最終バージョンで様子を見ることにした。特定バージョンに更新するには self-update のあとにバージョンを指定すれば良いらしい。

$ sudo -u apache scl enable rh-php56 -- php composer.phar self-update 1.2.4
Updating to version 1.2.4 (stable channel).
    Downloading: 100%
Use composer self-update --rollback to return to version f0f932fca403267a141e91f9262ab649b95b2ed9

パッケージ更新前に --dry-run で更新対象パッケージとバージョンを確認しておく。

$ sudo -u apache scl enable rh-php56 -- php composer.phar --dry-run update

で、バージョン確認後、問題なさそうなので更新。

$ sudo -u apache scl enable rh-php56 -- php composer.phar update

幸いサーバにはトラブルなかった模様。

MediaWiki 更新

MediaWiki を 1.26.3 から 1.27.1 へ更新した。
展開したファイルをコピーしてインストールディレクトリの maintenance ディレクトリへ移動、update.php を実行したところ composer が古いので update しろとのメッセージが出てしまう。

MediaWiki インストールディレクトリに移動して php composer.phar update を実行してはみたものの、エラーが出て動かない。

この状態で MediaWiki 本体は動くのだけれど、composer に依存してる chameleon skin が有効にならない。

いろいろ試行錯誤して試したところ、 php composer.phar install を実行してからの php composer.phar update で直ったみたい。その後 php composer.phar require mediawiki/chamelein-skin で再び使えるようになった。

composerはよくわからんな。

サーバのアップデート

明日 OS とボイスチャットと掲示板のアップデートをする予定。

CentOS

1. yum -C update を実行する
2. 再起動

Teamspeak3

1. ts3server.sqlitedb にサーバの設定が記録されているので念のため保存しておく
2. teamspeak3-server_linux_amd64-3.0.12.tar.bz2 をダウンロード
3. 古いTS3サーバの sql ディレクトリを削除
4. 新しいTS3サーバのファイルを既存のディレクトリに上書き
5. TS3の起動

phpBB

1. 実行中のバージョンを確認して、対応するアップデートファイルをダウンロードする　(phpBB-3.1.6_to_3.1.7-pl1.tar.bz2)
2. ファイルを展開し、フォルダ "install" と "vendor" を phpBB3ルートディレクトリ（config.php が存在するディレクトリ） にアップロードする 
3. AdminCP の "自動アップデート" を実行する

NetBSD の SSL Root 証明書

NetBSD で Git 使おうとしたらエラーになった。

$ git clone https://github.com/letsencrypt/letsencrypt
Cloning into 'letsencrypt'...
fatal: unable to access 'https://github.com/letsencrypt/letsencrypt/': SSL certificate problem: unable to get local issuer certificate

これは以下の理由によるらしい (引用 NetBSDあるある )。

SSLのRoot証明書がないため。NetBSDはSSLのRoot証明書は、pkgsrcから入れると便利。まず、mozilla-rootcertsをインストールする。

インストール後のメッセージを参考に、

$ sudo /usr/pkg/sbin/mozilla-rootcerts install

を実行したら、なんか大量に /etc/openssl/certs 以下にインストールされた。なお、/etc/openssl/certs が空でないと拒否られる。

StartSSL でやらかした

StartSSL で失敗した話。単に自分の不注意というだけなんだが。

StartSSL は無料でSSL証明書を入手できるサイトとして人気だ。自分もここを利用している。

今回、新たに取得したドメインがあるので、そこも StartSSL の証明書を取得しようとした。

以前取得してから随分日が経っているので、細かい手順はよく覚えてはいなかったが、うろ覚えで操作をした。

まず、ドメインの所有者確認を行って、サーバ証明書の発行手続きだ。CSR を作成するのが面倒だから、プライベートキーは StartSSL 側で生成すればいいか。で、証明書を発行してダウンロードと…。

プライベートキーをコピペして保存しておくのを忘れた。

ブラウザで前のページに戻ろうにも期限切れで表示できず、StartSSL からダウンロードもできないので、プライベートキーは完全に失われてしまったようだ。

新たなプライベートキーを生成して、サーバ証明書を取得しようとしても、発行済の証明書を取り消さないとダメといわれた。当然だ。だが、証明書の取り消しは有料で $24.9 だと。

どうしたものかと思ったが、WoSign Free SSL Certificateが3年無料でマルチドメイン対応かつStartSSLがクロスルートと最強な件 によれば、WoSign という中国系のSSL認証局が無料でSSL証明書くれるらしいので、そこで取ることにした。ありがたい。

証明書を取得するところは英語のページがあるので特に問題はなかったが、アカウント管理には英語版が見当たらなかった。漢字だからなんとなくわかるところもあるけれど、間違えて変なとこクリックしても困るからほっとくか。

.htaccess と RewiteRule

Apache の RewriteRule を設定していて結構はまったのでメモ。

RewriteRule を .htaccess に書く場合、最も深いサブディレクトリにある .htaccess のルールから適用され、その後親ディレクトリの .htaccess のルールが適用される（この動作は RewriteOption で変更可能)。

でも、やってみたら親ディレクトリの .htaccess が全く効いていないっぽい。ていうか、DocumentRoot にのみ .htaccess を置いても無視された。

原因は Alias を使って子ディレクトリを別のディレクトリに向けていたことだった模様。

どいうことかというと、RewriteRule が適用される .htaccess は、URL じゃなくて、実ディレクトリベースで解釈されるので、Alias を使うと親子関係が切れてしまうってこと。シンボリックリンクなら大丈夫。

例えば、

ServerName  www.example.com
DocumentRoot  /var/www/html
Alias  child  /opt/html/child

とかいう場合、http://www.example.com/child/index.html へアクセスすると、実ファイルは /opt/html/child/index.html になる。このとき RewriteRule はプレフィックスを /opt/html/child として解釈し、/opt/html/child の .htaccess にある RewriteRule を index.html に適用する。

URL ベースでみると親ディレクトリに相当する /var/www/html は実ディレクトリベースでは親じゃない。なので、/var/www/html に置いた .htaccess の RewiteRule は参照されない。

これが、Alias じゃなくて下のようなシンボリックリンク貼ってると動作する。

/var/www/html/child -> /opt/html/child

この場合、http://www.example.com/child/index.html へアクセスすると、実ファイルは /var/www/html/child/index.html として解釈される。RewriteRule はプレフィックスを /var/www/html/child と解釈し、/var/www/html/child の .htaccess にある RewriteRule を index.html に適用する。

さらに、/var/www/html は親ディレクトリなので DocumentRoot に置いた .htaccess の RewriteRule も適用される。このときプレフィクスは /var/www/html で 適用対象は child/index.html だ。

まとめると、親ディレクトリの .htaccess で RewriteRule 使いたかったら Alias は使わずシンボリックリンクを使えってことなんだけど、これって常識?

ZeroC Ice のインストール

CentOS6に ZeroC Ice をインストールした。公式 rpm も出てて最初はそれを入れていたのだが、非標準のライブラリなども入れる必要があってそれが標準のライブラリと干渉することがあるので、ソースからビルドしてインストールすることにした。

ちなみにバージョンは公式rpmと同じ 3.5.1 にしている。もしかしたら最新の 3.6 でもphpMumbleAdmin は動くかもしれないけど、様子がわからないので動作確認がとれている 3.5.1 で実行することに決めた。

参考にしたのは Ice 3.5 と Ice 3.6 のインストールドキュメント。

• https://doc.zeroc.com/display/Ice35/Building+Ice+from+Source
• https://doc.zeroc.com/display/Ice36/Building+Berkeley+DB+and+mcpp+on+Linux

ビルドに必要なライブラリがいくつかあるが、用意しないといけないのは Berkeley DB 5.3 と mcpp 2.7.2 (with patches) の2つ。どちらも ZeroC Ice のサイトからダウンロードできる。ほかは CentOS 標準のライブラリでよい。

まず DB 5.3 のビルドとインストール。今回 Java を使う予定はないので --enable-java は指定していない。/opt/db53 にインストールする。

$ wget https://zeroc.com/download/berkeley-db/db-5.3.28.NC.tar.gz
$ tar xzf db-5.3.28.NC.tar.gz
$ cd db-5.3.28.NC/build_unix
$ ../dist/configure --enable-cxx --prefix=/opt/db53
$ make
$ sudo make install
$ cd /opt/db53
$ sudo ln -s lib lib64

次に mcpp をビルドする。mcpp は静的ライブラリになるのでインストールはしない。 ソースは https://github.com/zeroc-ice/mcpp.git からダウンロードする。

$ wget https://github.com/zeroc-ice/mcpp/archive/master.zip
$ unzip master.zip
$ cd mcpp-master
$ make

最後に Ice-3.5.1 のビルドとインストール。インストール場所はデフォルトの /opt/Ice-3.5.1 。ただし、インストールドキュメント通りにしたらランタイムライブラリのパスがなぜか /opt/Ice-3.5 になってしまったので emmbedd_runpath_prefix=/opt/Ice-3.5.1 を指定してパスが正しくなるように修正している。

$ tar xvfz Ice-3.5.1.tar.gz
$ cd Ice-3.5.1/cpp
$ make DB_HOME=/opt/db53 MCPP_HOME=(絶対パス)/mcpp-master embedded_runpath_prefix=/opt/Ice-3.5.1
$ sudo make install
$ cd ../php
$ make PHP_HOME=/opt/rh/rh-php56/root/usr emmbedd_runpath_prefix=/opt/Ice-3.5.1
$ sudo make install

あとは PHP に IcePHP.so を読み込ませて /opt/Ice-3.5.1/php にパスを通せばよい。次のような内容のファイルを /etc/opt/rh/rh-php56/php.d/IcePHP.ini として作成する。

; Enable Ice extension module
extension = /opt/Ice-3.5.1/php/IcePHP.so

; Add to include_path
include_path = ${include_path}":/opt/Ice-3.5.1/php"

PHP の ini ファイルの中で既存の ini 変数を参照できるんだね、今知ったわ。

MariaDB10にしてみた

Software Collections のサイトが復活したので調子に乗って MariaDB10 を入れてみた。

rhscl-rh-mariadb100-epel-6-x86_64.noarch.rpm をダウンロードして、

$ yum install rhscl-rh-mariadb100-*.noarch.rpm
$ yum install rh-mariadb100

で、

$ mysqldump --single-transaction -u root -p --all-databases > mysqldump_all_database.dump

$ service mysqld stop
$ service rh-mariadb100-mariadb

$ scl enable rh-mariadb100 'mysql -u root' < mysqldump_all_database.dump

として mediawiki のページにアクセスしてみるとデータベースエラー、接続できないときた。

mediawiki ユーザのパスワードを再設定してみようとしたら、そんなユーザは知らないと言われる。'select user,host from mysql.user;' ではちゃんと表示されるのに!

ERROR 1133 (28000): Can't find any matching row in the user table

バックアップデータを戻したあと、flush privilieges; を実行していなかったのが原因だった。

MariaDB [(none)]> flush privileges;

mediawiki もちゃんと動作した。

301リダイレクト

MediaWiki でショートURL表記にする で301リダイレクトを返す R=301 の指定をしたのだが、"一度301リダイレクトにしてしまうと、「やっぱりやめた」というのは利きません" という罠があるらしい。

なんでも、301リダイレクトがブラウザにキャッシュされるのでブラウザにキャッシュが残っている限りはサーバで変更しても参照されない、キャッシュはデフォルトで無期限、コンテンツのサイズが０なのでキャッシュから追い出されることは期待できない、のコンボでサーバの設定をどういじっても修正できなくなるそうだ。

おそろしい。

Windows 10 のネットワークアダプタ優先順位

うっかりノートPC を Windows10 にアップグレードしてしまった。

しばらく使っていると、有線LAN接続してるのにいつの間にかWiFiに切り替わっていることがあることに気づいた。

8.1 のときは特に何もしなくても有線LANの方が優先されていたのであまり深く考えなかったが、このあたりどうなっているのだろう。

調べてみると、 http://www.lifehacker.jp/2013/05/130508force_cable_connection.html 優先順位の設定というものがあるらしい。知らなかった。初めて見た。

で Windows 10 でも 8.1 と同じ所にその設定はあった。WiFi の優先順位が有線LANより高くなっている。以前の設定はわからないがここで有線LANの優先順位を上げればよいのだろう。

(追記)
優先順位変更してもダメだった。というか変更が反映されない。
WiFiアダプタのメトリックを増やす、というのをやっても効果なし。
とりあえず手動でWiFiをOffにするか…

(追記2)
しばらく使ってみたけどその後この症状は発生していない。
あのときはISPのDNSがやや調子悪かったので有線LANが切れて無線LANにフォールバックしてたのかもしれないと想像してる。
ちなみに無線LANは2.4Gと5Gの両方あって、有線LANの識別名は2.4Gの方と同じになっている。この辺りの仕組みはよくわからない。無線LANの方はSSIDだけど、有線LANの方はなんだろう?

CentOS6 のリポジトリ

CentOS6標準のソフトがあまりにも古すぎるのでいろいろ検索したり試行錯誤したりして適当なサードパーティリポジトリをいれるという手段を選んだのだが、案の定依存するパッケージなどが喰違ってインストールできないケースがでてしまった。容易に予想されることではあるけれども。

今日調べたところ http://wiki.centos.org/AdditionalResources/Repositories によれば、適当な野良リポジトリは不整合を招くのでよくないとある。標準パッケージが古くてこまるというときは Software Collections (SCLリポジトリ)　を使え、とある。

なんだ、そういうのがあるんなら早く言ってくれよ。なんでみんな黙ってるんだ？って思ったのだが、使えるようになたのが去年の終わりごろのようで、まだあまり広まっていない (ブログなどに書く人がいない) からのもよう。しゃーない。

それでも CentOS + SCL で検索するとそれなりに引っかかる。CentOS だと埋もれてしまうんだな。

さっそくやってみる。SCL で入れたパッケージは他の標準パッケージなどを壊さないように独自のディレクトリ構成の中にインストールされるので、インストールするだけなら既存の環境を壊すことがなくて安心だ。実行がちょっとめんどくさいが。

前準備
$ yum install centos-release-SCL

Apache24のインストール
SCL のページから CentOS 6 に対応する rhscl-httpd24-epel-6-x86_64.noarch.rpm をダウンロードしてくる。

$ yum install rhscl-httpd24-epel-6-x86_64.noarch.rpm
$ yum install httpd24
$ yum install httpd24-mod_ssl

設定ファイルはに置かれる。
/opt/rh/httpd24/root/etc/httpd/conf/httpd.conf


'apachectl configtest' コマンドの実行は以下のように行う。'httpd24' はパッケージグループの名前。
$ scl enable httpd24 'apachectl configtest'

サービスとして実行するときはもう少し簡単。'httpd24-' がプレフィクスにつく。
$ service httpd24-httpd start

PHP56のインストール
SCL のページから CentOS 6 に対応する rhscl-rh-php56-epel-6-x86_64.noarch.rpm をダウンロードしてくる。

$ yum install rhscl-rh-php56-epel-6-x86_64.noarch.rpm
$ yum install rh-php56
$ yum install rh-php56-php
$ yum install rh-php56-php-intl
$ yum install rh-php56-php-mysqlnd
$ yum install rh-php56-php-mbstring

MediaWiki で必要な APCはPHP56moreの方に入っていた。こちらも同様に remi-php56more-epel-6-x86_64.noarch.rpm をダウンロード。


$ yum install remi-php56more-epel-6-x86_64.noarch.rpm
$ yum install more-php56-php-pecl-apcu

プレフィクスが 'more-' なのに注意。

Postfix の設定

freenom でとった .tk ドメインでもメールを受け取れるようにしてみる。

main.cf に外部からメールを受け付ける設定と、指定ドメイン宛のメールを自分宛と認識させる設定を行う。下の例では追加で受け取るドメインを example.com としている。

inet_interfaces = all
mydestination = $myhostname, localhost.$mydomain, localhost,
        example.com

/etc/aliases で root 宛のメールを gmail に転送するようにして newaliases でデータベースを更新。

root:    どこか@gmail.com

aliases ファイルの本体は Git で管理してるディレクトリに置いて、/etc/aliases はそこへのシンボリックリンクにしてるんだけど最初 newaliases がエラーで動かなかった。

postalias: fatal: open /etc/aliases.db: Permission denied

/etc/aliases.db のパーミッションが悪いわけではなく、/etc/aliases のオーナーが root でないとこんなエラーが出る。これはエラーメッセージが不親切。

MediaWiki での CSS カスタマイズ

MediaWiki の デフォルトの文字の大きさがちょっと小さすぎるような気がしたので修正した。

MediaWikiのデフォルトのデザイン (Vectorスキン) のカスタマイズはCSSファイルを編集するのではなく MediaWiki の MediaWiki:Common.css とMediaWiki:Vector.css のページに追加のCSS記述を行う。

MediaWiki:Common.css と MediaWiki:Vector.css の使い分けははっきりしないが、スキンに依存するような修正は MediaWiki:Vector.css で行うのがよいのだろう。

Firefox の開発ツールを使うと、指定した要素にどんなCSSがどんなルールで適用されているのかがわかるのでそれを見ながら作業する。

MediaWiki:Common.css ではこんな感じ。デフォルトで h1, h2 要素が明朝体になってるのでゴシックに変更。

.mw-body h1, .mw-body h2 { font-family: sans-serif; }
.mw-body-content { font-size: inherit; }

MediaWiki:Vecor.css では左サイドバーの幅をちょっと大きめにして、本文フォントサイズをちょっと大きめに。

div#mw-panel { width: 14em; }
div#footer, #mw-head-base, div#content { margin-left: 14em; }
#left-navigation { margin-left: 14em; }

div#mw-panel div.portal h3 { font-size: inherit; }
div#mw-panel div.portal div.body ul li { font-size: 95%; }

で、これだけだとログインページヘは反映されない。安全のため、ログインページなどはデフォルトでカスタマイズCSSが反映されないようになってるとのこと。

変なCSSを注入されるおそれがない場合には LocalSettings.php で $wgAllowSiteCSSOnRestrictedPages を true に設定すると反映される。

$wgAllowSiteCSSOnRestrictedPages = true;

MediaWiki でショートURL表記にする

MediaWiki をインストールして http://サーバ/mediawiki でアクセスできるようにした。

このままだと http://サーバ/mediawiki/index.php/Hoge って感じでアクセスすることになるのでこれを http://サーバ/mediawiki/Hoge って感じでアクセスできるようにする。サーバやインストールの形態によってやり方は異なるので一例としてみてほしい。

サーバは Apache 2.2 で mediawiki のファイル群は /home/apache/mediawiki にインストール、DocumentoRoot からは以下のように httpd.conf の Alias 設定で飛ばしている。

Alias /mediawiki /home/apache/mediawiki

http://サーバ/mediawiki/Hoge にきたリクエストを http://サーバ/mediawiki/index.php/Hoge に書き換えるには以下のような .htaccess を /home/apache/mediawiki に置けばよい。

<IfModule mod_rewrite.c>
   RewriteEngine On
   # Redirect Trailing Slashes...
   RewriteRule ^(.*)/$ /$1 [L,R=301]

   # Handle From Controller...
   RewriteCond %{REQUEST_FILENAME} !-d
   RewriteCond %{REQUEST_FILENAME} !-f
   RewriteRule ^ /mediawiki/index.php [L]
</IfModule>

最後に MediaWiki 内でも http://サーバ/mediawiki/Hoge 形式で取り扱うように LocalSettings.php を以下のように修正する

$wgScriptPath = "/mediawiki";
$wgArticlePath = "{$wgScriptPath}/$1";

これで完了。

（追記）
R=301 の指定は危険なのでやめたほうが無難そう。

MediaWiki のインストール

Pukiwiki がちょっと肌に合わない感じなので MediaWiki を入れて試してみることにした。

MediaWiki のインストール説明に従い、あらかじめ MySQL でデータベースの作成と管理ユーザを作っておく。

# mysql -u root -p
mysql> create databse mediawiki;
mysql> grant index, create, select, insert, update, delete, drop, alter, lock tables on mediawiki.* to 'mediawiki'@'localhost' identified by 'パスワード';

MediaWiki を展開してアクセスすると初期設定が始まる。最初の動作環境チェックでキャッシュとunicode処理のモジュールがないと言われたので yum で追加インストールする。なくても動作するらしいがないとパフォーマンスが悪いそうなので入れておくことにした。

yum install php56u-pecl-apcu.x86_64
yum install php56u-intl.x86_64

で、もう一度チェックすると今度は libicu （php56u-intl が依存するライブラリ）が古いと言われた。

libicu の新しいのは Remi http://rpms.famillecollet.com/ とかいうリポジトリにしか見当たらなかったのでやむなく Remi を入れる。

rpm -Uvh remi-release-6.rpm

で、php から丸ごと入れなおし。

yum install --enablerepo=remi-php56 php php-mysql php-mbstring
yum install --enablerepo=remi-php56 php-pecl-apcu
yum install --enablerepo=remi-php56 php-intl

MediaWiki がなぜか動かないので Apache のログ見たら

PHP Fatal error:  Class 'DOMDocument' not found in ...

っていうエラーが出てた。 ググるとPHPパッケージによってはモジュールが別で作成されてるとのこと。php-xml を入れればいいらしい。

yum install --enablerepo=remi-php56 php-xml

動いた。

SSLの設定確認

今日口座の残高確認しようと思ってみずほ銀行のサイトにアクセスしたらあいかわらずトップページでhttpsが使えない状態だった。Googleで「みずほ銀行」を検索しても公式トップじゃなくて宝くじコーナーが検索トップにきてるし。どうなっているのやら。

それはさておき、自分のhttpsサイトの設定は大丈夫かと気になった。もちろんブラウザで接続して閲覧できることは確認してるけど、設定がちゃんとしているかどうかはわからない。
  
SSL の設定は Qualys SSL Labs の SSL Server Test  でチェックしてくれる。

チェックの結果見つかった減点項目は、SSLv3、RC4 が有効になってるのと、中間証明書がインストールされていないこと。

Apache の SSL 設定は Mozilla SSL Configuration Generator でおすすめを出してくれる。

ssl.conf を編集すればよいのかと思ったが、SSLCipherSuite などは <VirtualHost _default_:443> のブロックでなくて SNI で指定している <VirtualHost *:443> ブロックの中に書かないと有効にならなかった。このあたりの設定の有効範囲があまり理解できてない。

RC4 が有効になってないかどうか確認するには openssl を使って確認できる。

$ echo Q | openssl s_client -connect localhost:443 -servername www.example.org -cipher RC4

これで接続できれば RC4 が有効になっている（設定に失敗している）ってことだ。

という感じで設定して A 判定取得

CentOS で Apache の更新はどうしたら

CentOS6 に入ってる Apache のバージョンは 2.2.15。ちなみに2.2系の現時点の最新版は2.2.29 だ。

標準の yum のリポジトリが古いのにはもう慣れた。そうだな、最新もしくはそれに近いバージョンの rpm が入ってるリポジトリをインストールすればいいんだろ。ってなわけでググってみると http://centos.alt.ru/repository/centos/6/$basearch/ というのが見つかった。

ru...

いや、まあ、ドメインがロシアだからどうってわけではないけど（あるけど）、みんなこれ入れてるの? リポジトリの信頼性とか安全性とかみんなどう確認してんだろ。

しかも Firefox で http://centos.alt.ru/ にアクセスすると

この Web ページ (centos.alt.ru) は攻撃サイトであると報告されており、セキュリティ設定に従いブロックされました。

って出るし（google の診断らしい）。

ちょっと使えなさすぎじゃないですかね。

Apache の名前ベースバーチャルホストによる SSL (SNI)

かつて SSL は名前ベースのバーチャルホストでは運用できないとされていたが、今はそのための規格やサーバ、対応クライアントの普及もあって、まあ使える。

もちろん対応していないクライアントもまだまだ残っていて、商用では「使えない」とされるのかもしれないけれど、それは置いておこう。

その規格は SSL/TLS の拡張仕様で SNI (Server Name Indication) と呼ぶらしい。 Apache 2.2 系などで使えて、"NameVirtualHost *:443" とすると有効になる。

あとは "<VirtualHost *:443>" ～ "</VirtualHost>" の間にディレクティブを記述すればよい。通常の名前ベースのバーチャルホストと同様だ。

ただ、HTTP でリクエストされたホスト名がバーチャルホスト定義のどこにもマッチしないときは、先頭のバーチャルホスト定義がデフォルトとして使われる、かと思ったがどうも違うようだ。

ホストがマッチしない時は元から入っている "<VirtualHost _default_:443>" の定義が使われているようであるし、DocumentRoot はグローバルに記述したところが有効になっているようだ。

:80 の場合と設定が有効になるルールが異なっているような気がするのだが、どうなんだろう。

Windows の Emacs で tramp

Emacs には　tramp というものが入っている。

これがどういうものかというと、リモートマシンのファイルをあたかもローカルにあるかのように取り扱えるという便利なものだ。

昔はサードパーティーの elisp パッケージだったのが、いつからか標準で Emacs に含まれるようになっている。

バックエンドとして ssh を使っていて、UNIXライクな環境だと特に何も考えずに使えるようになっているのだが、例によって Windows だと使えるようにために設定が必要である。

参考にしたのはこのページ http://d.hatena.ne.jp/t0m0_tomo/20101208/1291782058

まず、バックエンドに PuTTY を使うとして、PuTTY へのパスを通す必要がある。PATH に PuTTY のフォルダを指定している人はこの設定はたぶん飛ばせる。

たとえばユーザ ｘｘｘ が自身の "ドキュメント" フォルダに PuTTY のフォルダを置いているとすると、実際のパスが "C:\Users\xxx\Documents\PuTTY" とかになっているので、~/.emacs.d/init.el に以下を設定する。

(setenv "PATH"
    (concat
     (getenv "PATH")
     ";" "C:\\Users\\xxx\\Documents\\PuTTY"))

あくまで例示なので、自分のとこではパスが違うとかそういうのは適当に自分の環境に合わせて読み替えてほしい。

これで　Emacs から PuTTY を使う準備ができた。

次は tramp でPuTTY の plink.exe を使う設定。

(require 'tramp)
(setq tramp-default-method "plink")
(setq tramp-shell-prompt-pattern "^[ $]+")

これでいける。

あとは　C-x C-f でファイルを開くときに "/hostname.example.com:~" とかいう感じで指定すると hostname.example.com のホームディレクトリが参照できる。

ちなみにこの hostname.example.com の部分は PuTTY でのセッション名でもいける。セッション名の方がリモートユーザ名とかあらかじめ設定できて便利だと思う。ただ、日本語のセッション名を入れたら tramp の方が認識しなかった。ホスト名っぽいセッション名にしておいた方が無難な模様。