2016年9月12日月曜日

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はよくわからんな。

2016年2月5日金曜日

サーバのアップデート


明日 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 の "自動アップデート" を実行する

2015年11月5日木曜日

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 が空でないと拒否られる。

2015年10月21日水曜日

StartSSL でやらかした

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

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

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

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

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

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

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

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

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

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

2015年9月26日土曜日

.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 は使わずシンボリックリンクを使えってことなんだけど、これって常識?

2015年8月19日水曜日

ZeroC Ice のインストール

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

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

参考にしたのは Ice 3.5 と Ice 3.6 のインストールドキュメント。
ビルドに必要なライブラリがいくつかあるが、用意しないといけないのは 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 変数を参照できるんだね、今知ったわ。

2015年8月18日火曜日

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 もちゃんと動作した。