webminの操作にも慣れてきたし、今までPleskにどれだけサーバリソースを使わされていたかということも痛いほどよく分かった。
webminは面倒なこともあるが、基本的に最初の設定が完了すればあとはPleskと大差ないユーザビリティを備えていると思う。そんなわけで、もう二度とPleskは使わない・・・言い切ってしまいたいところなのだが、実は問題が一つだけあった。
私の仕事では、一台のサーバに異なるドメインの複数サイトをホスティングすることがあるが、普通にwebminをインストールした状態では実現できない。
そこで、Virtualminという複数ドメインのホスティングをサポートするためのwebmin追加モジュールをインストールすることにした。

まずはVirtualminのページ左上にある「Virtualmin Installer」をクリックする。VirtualminにはGPL版とPro版があり、Pro版は有料ライセンスが必要。今回はGPL版をインストールする。

wget http://software.virtualmin.com/gpl/scripts/install.sh

インストール用のシェルスクリプトに実行権限を付与して、実行する。
chmod +x install.sh
./install.sh

私の環境では１０分くらいでインストールが完了した。
感動的に簡単だ。

先日この記事でphpをソースからビルド・インストールしたと書いたが、サイトを作っていくうちにmb_send_mailが動作していないことが分かった。
エラーも出ないし、なんだか理由が分からなかったが、いろいろ調べていくうちにコンパイル時の問題であることが分かった。
mb_send_mailでメールが送れなくて、phpをソースからインストールしたという方は、phpのソースディレクトリの「main/php_config.h」このファイルの中に
#define HAVE_SENDMAIL 1
という行があるかどうか見てほしい。もしなかったら、原因はこれだ。
上記のファイルに「#define HAVE_SENDMAIL 1」という一行を追加する。私は適当に「#define ・・・」が続いている最後の行に追加した。

次に /etc/php.ini をどこかにコピーしてバックアップを取っておき、httpdを終了させておく。

phpをコンパイルする前に、ソースディレクトリに移動して
make distclean
を実行し、その上で再度phpをコンパイルする。前の記事でも書いたが、あらためてもう一回私が使ったconfigureオプションを掲載しておく。

'./configure' \
'--prefix=/usr/local' \
'--with-mysql=/usr/local/mysql' \
'--with-pdo-mysql=/usr/local/mysql' \
'--with-apxs2=/usr/sbin/apxs' \
'--enable-mbstring' \
'--enable-mbregex' \
'--with-jpeg-dir' \
'--enable-ftp' \
'--enable-exif' \
'--enable-sockets' \
'--with-openssl' \
'--with-zlib' \
'--with-gd' \
'--with-curl' \
'--enable-zend-multibyte' \
'--enable-pcntl' \
'--with-mcrypt' \
'--with-tidy'

で、makeするわけだが、私の環境では下記のようなエラーが出てmakeできなかった。

/usr/bin/ld: cannot find -lltdl
collect2: ld returned 1 exit status
make: *** [libphp5.la] エラー 1

lltdlがインストールされていないのが原因なので、インストールする。
yum install libtool-ltdl libtool-ltdl-devel

で、
make
make install

以前使っていたサーバから新しいサーバへ引越する手順で結構めんどくさいのがMySQLのデータ引越。
DNSも外にあるのでAレコードの変更だけで済むし、コンテンツファイルはまぁサイズが大きくてもtarしてftpで転送するだけなので大した時間はかからない。
mysqlもmysqldumpでファイルを付くって、新しいサーバでコマンドラインから投入すれば数分で済むと思っていた。

ところが、やってみるとこれが非常に時間がかかる。遅い。遅すぎる・・・
私のサイトのテーブルは２０Mくらいのサイズしかないのだが、試しに移行してみると１時間かかっても終了しなかった。１テーブルだけ（１．４メガくらい）を移行テストしてみたところ、１０分かかった。

とんでもなく遅い。なんでこんなに時間がかかるんだ。
でネットでいろいろ調べてみた方法を試してみた。

・mysqldumpにオプションを付加する方法
--disable-keys　をつけると、インサートのたびにキー更新せず、insertが全部完了してからテーブルのインデックスを作るので早くなる。
ただ、私の環境では　--opt　を付加してmysqldumpを実行しているので、これはもともとそうなっていた。

--extended-insert　をつけると１行で複数のinsert文を作るので早くなる。これも同様に私の環境では既にそうなっていた。

--no-autocommit　をつけるとまとめてコミットするので早くなる、とのことだったので試してみたが、結局前よりも遅くなった。

・移行先のmysql設定を見直してみる
net_buffer_lengthのサイズを大きくしてみたが効果なし。

key_buffer=256M
query_cache_size=32M
こんな設定も試してみたが変化なし。関係ないらしい。

myisam_max_sort_file_size=2G
tmpdir=/home/tmp
これも変化がなかった。このmyisam_max_sort_file_sizeをべらぼうにデカイ値にするという記事もあったが、試してみたところshow variables;でエラーになってしまったのでやめた。

で、最終的にはmysqlのデータファイルをまんまコピーするという荒技を試してみた。

・mysqlのデータを単純にコピーする方法
mysqladmin variables | grep datadir これを実行するとmysqlのデータがどこに格納されているかが分かる。そのディレクトリにあるDB名のディレクトリを丸ごと圧縮する。
tar zcvf db_backup.tar.gz dbname
こんな感じで。
このファイルを移行先のサーバにFTPで転送し、
zip -dc db_backup.tar.gz | tar xvf -
これで解凍・展開する。展開するとopt、frm、MYD、MYIなどの拡張子のファイルが沢山できるので、同じようにmysqlのデータ格納ディレクトリを調べて、db名のディレクトリに丸ごとコピーする。

データが更新されていたらうまくいかないのでテーブルをロックする、などの注意書きもあったのだが、私の場合は特にそういうことをしなくてもうまくいった。
割とDB更新が多いサイトを運営しているが、３回試して３回ともうまくいった。しかも移行元と移行先でmysqlのバージョンが違っているにもかかわらず。
単純にコピーしたいだけの引越ならこれが一番簡単ではないだろうか。ていうかmysqlはそういうたぐいの方法を用意するべきじゃない？

ちなみにデータベース名やデータベースユーザ名は移行元と先で統一して実験した。

tritonnの公式ページに記載されているインデックスの設定方法だと、アルファベットの大文字小文字が別物として扱われるようで、例えばAと検索するとaが結果として帰ってこない。
大文字小文字、半角全角を区別せずに検索結果としてヒットさせたい場合のインデックス設定は下記の通り

alter table テーブル名 add FULLTEXT INDEX インデックス名 USING SENNA, NORMALIZE (カラム名);