月: 2013年10月

今度はMailmanのメーリングリストをお引越しする。まずはmailmanのサービスの停止。

service mailman stop

まずはlistユーザーにsuしてnewlistを使って旧サーバーと同じ名前で新サーバーで空のメーリングリストを作成しておく。最初はアーカイブが公開になっているので、非公開のメーリングリストはarichives/publicにあるシンボリックリンクを削除しておく。

旧サーバーでmailmanフォルダ内のlistsとarchives/privateをtarで固める。このとき、tar pzcfの様にpオプションを付けてパーミッションが保存されるようにしておく。このtarファイルを新サーバーにコピーする。

念の為、listsとarchives/privateをリネームして保存しておいてから、tarファイルをこれまたtar pzxfの様にpオプションを付けてパーミッション付きで展開する。その後、listsフォルダ内の全ファイルをlists:lists所有に、archives/private内の全ファイルをlists:www-data所有にchown -Rで変更する。

これで新サーバーでも旧サーバーと全く同じメーリングリストが設定される。後はmailmanを再起動すれば元通り。

service mailman start

本来ならデータベースをダンプして、それを新サーバーに取り込むのがお作法なのだろうけど、それは面倒なので、エクスポート＆インポートで再現することにする。

WordPress Importプラグインは最初はインストールされていないので、インストールしてネットワークで有効化しておく。

旧サーバーと同様に新サーバー上にユーザーとブログを作成したら、旧サーバーの各ブログのダッシュボードから全コンテンツをエクスポート。そのファイルを今度は新サーバーのブログのダッシュボードからインポートする。これでカテゴリーやらエントリーやらコメントやらはすべて元通りになる。

後は見栄えのカスタマイズを手でコネコネと再現するだけ。

管理するのに便利なように細々とした設定を追加。

ひと通り必要なパッケージはインストールが終わったので、これ以後はaptでパッケージの更新をする時に必ず更新内容が表示されるようにする。

すでにapt-listchangesはデフォルトでインストールされているので、dpkg-reconfigure apt-listchangesで最後の質問でインストール前に更新内容を表示するように変更する。

次に更新があったパッケージをroot宛にメールで通知するようにする。これは単純にapticronをインストールするだけ。

apt-get install apticron

多分デフォルトの設定で問題なし。ただ、デフォルトだと1時間ごとに実行されるのでさすがにそれはうざい。一週間に一度実行されるように/etc/cron.d/apticronを書き換えておこう。44 * * * *になっている部分を0 6 * * 7に変更する。これで、Weeklyスクリプトが動く時にその直前に実行される。

最後に、毎日ログをおさらいして問題があった場所をメールで報告してくれる便利パッケージも入れておこう。これはlogwatchパッケージをインストールする。

apt-get install logwatch

これも多分デフォルトのままでいいので、インストールしただけで放置。

ja.wordpress.orgから3.6.1-jaのパッケージをダウンロード。面倒なのでDebianのApacheのDocument Rootである/var/wwwの直下に展開しちゃう。

/var/www/wordpress以下すべてのファイルをApacheの実行ユーザーであるwww-data:www-dataの所有に変更しておく。

chown -R www-data:www-data /var/www/wordpress

とりあえず、http://[servername]/wordpress/にアクセスして画面の指示どおりにインストール。ついで、以前のエントリー通りにマルチサイト化するためのフレーズと自動アップデートのためのフレーズを/var/www/wordpress/wp-config.phpの最後に追記。

WordPressにadminでログインして、ツール->ネットワークからマルチサイト化する。ネットワークをなんと呼ぶか？という質問が増えているがとりあえずかっこつけて”BAM-System Blog Network”とでも入力しておく。後は指示どおりにごにょごにょすればマルチサイト化が完了する。

ここで、自分のユーザーを作成しようと思ったら、なんといつの間にか4文字よりも短いユーザー名はダメというルールになったらしい。それは困る。というわけで、4文字制限を3文字制限に強引に変えてしまおう。

いじるファイルは/var/www/wordpress/wp-includes/ms-function.php

if ( strlen( $user_name ) < 4 )

という行を見つけて、これを3にしておく。ついでにその次の行のエラーメッセージも4->3に変えておくか。これで3文字のユーザー名も受け入れてくれるはず。

自分用のユーザーとブログを作成した後、デフォルトで最初に作られるトップディレクトリのブログの所有権と特権ユーザーを自分に指定した後、adminユーザーは削除してしまおう。

というわけで、続けてPHP5とphpMyAdminのインストールを行う

apt-get install php5 phpmyadmin

インストール中にphpMyAdminがいろいろ設定を要求してくる。まずは、連携するhttpdにApacheを選択。サーバー管理をdbconfig-commonにおまかせにするか手動にするかの選択はおまかせに。次にデータベース操作のためのMySQLのルートパスワードを入力。最後に、非管理者権限でphpMyAdminがMySQLと連携するためのパスワードだが、どうせこれはphpMyAdminがMySQLとの間で使うだけなので空欄にして自動生成させる。

これだけでちゃんとApacheの設定にphpMyAdminが追加されてphpMyAdminがウェブベースで使えるようになっているはずデフォルトではサーバーのドキュメントルート直下の/phpmyadminにアクセスすれば立ち上がるはず。

とりあえずrootでログイン。次にデータベースタブから新規データベース’wordpress’を作成する。

次にWordPress用のユーザーを作成する。特権タブから新しいユーザーを追加する。ユーザー名はwordpress、パスワードは自動生成してメモしておいてもいいが、今回はパスワードジェネレーターで作成したものを貼りつけた。外部からアクセスすることはないので、localhostからのアクセスに制限しよう。作成後、特権を編集で、wordpressデータベースに対してすべての権限を有効にしておく。

以上でWordPress用のデータベースの準備は完了。WordPress本体はパッケージでなく手動でインストールすることで、WordPress内部からの更新でメンテできるようにする。

まずはMySQLをDebianにインストールする。

apt-get install mysql-server

途中、MySQLのrootのパスワードを要求されるので、パスワードジェネレーターで作ったパスワードをとりあえず入力。

例によってMySQLはインストール時には危険な状態(いい加減なんとかしろよ!)でインストールされるので、セキュリティを向上させる初期スクリプトを走らせる。

/usr/sbin/mysql_secure_installation

最後にWordPress用のデータベース作成だが、せっかくなのでphpMyAdminを利用して見ることにする。

CGIを旧サーバーから移植するためにjcode.plを用意する必要がある。

調べてみると、Debianではlibjcode-perlパッケージをインストールすればいいらしい。

で、インストールされたはずのjcode.plが見当たらないと思ったら・・・

/usr/lib/perl5/jcode.pl

こんなところにインストールされていた。

移植する予定のCGIではjcode.plについてはフルパスを書かず、システムが認識するデフォルトのjcode.plを暗黙で使うように設定してあるが、移植後に日本語がちゃんと表示できなければ上記フルパスに書き換えることにしよう。

 

忘れちゃいけないNTPによる自動時刻合わせ。

とりあえずapt-get install ntpでntpのパッケージをインストール。

/etc/ntp.confをいじってデフォルトのサーバーをコメントアウト。代わりに日本国内なのでNICTの公開NTPサーバーを記入する。

server ntp.nict.jp

とりあえずこれを3行くりかえす。するとDNSラウンドロビンで3つの異なるサーバーが参照先に登録されるので少し時刻精度があがる。

あとはntpdを再スタートするか、サーバーを再起動する。

LAN内にブロードキャストで流してもいいんだけど、そこまで時刻を合わせたいマシンがないので見合わせる。

ここで、mailmanを運用する場合の注意。

mailmanにはmmsitepassを使ってグローバル管理パスワードを設定すればウェブ上のインターフェースからメーリングリストの作成が可能だが、この方法で作成するとアーカイブディレクトリの所有者がwww-dataになってしまうので、mailmanが配信されたメールをアーカイブすることが出来なくなってしまう。

同様にコマンドラインからroot権限でnewlistでメーリングリストを作成した場合も、アーカイブディレクトリの所有者がrootになってしまって、これまた同じくmailmanがアーカイブできなくなってしまう。

これらはdebianのパッケージの設定に問題があると考えられるが、下手に修正してバイナリパッケージのアップデート時に整合性がとれなくなると嫌なので、ここは何も対処せず、su listしてからコマンドラインでnewlistを実行してメーリングリストを作成するようにする。すると作成されるファイルはすべてlistユーザー所有になるので、パーミッションの問題は起きない。バッドノウハウワークアラウンド。

 

メーリングリストサーバーとしてmailmanを使う。パッケージのインストール内容をできる限り尊重する設定にする。

とりあえずapt-get install mailman

FQDNは最終的なサーバーの名前で、言語はjaを選ぶがなぜか最初はenしかインストールされない。なので、インストール後にもう一度dpkg-reconfigure mailmanで再びjaを選ぶ。すると今度はjaもインストールされる。

次にpostfixとの連携をさせるため、/etc/mailman/mm_cfg.pyを編集。といってもMTA=”postfix”の行を有効にするだけ。ついでにDEFAULT_URL_PATTERN = ‘http://%s/mailman/’と変更して間の余計な/cgi-bin/を抜いておく。これはFreeBSDでmailmanをインストールした時のデフォルトに合わせるため。これを合わせておかないとFreeBSDで既に運用しているリストを移植するときにいろいろ不整合が出ることが予想される。

Webベースの管理ページを表示させるため、

ln -s /etc/mailman/apache.conf /etc/apache2/site-enabled/010-mailman

を実行してapacheの起動時にパッケージが用意したデフォルトのmailman用の設定を読み込む様に設定する。さらに、/etc/mailman/apache.confを編集し、ScriptAliasの行の/cgi-bin/mailman/を/mailman/に変更してmm_cfg.pyと合わせておく。

次の作業ではmailmanのスクリプトがEUCでメッセージを吐き出すので、あらかじめターミナルの文字コードをEUCに一時的に変更しておく。root権限でsu listしてmailmanの実行ユーザーlistの権限に移行し(シェルがbashからshに切り替わるので戸惑わないこと)

/var/lib/mailman/bin/newlist mailman

を実行する。mailmanメーリングリストの管理ユーザーのメールアドレスと設定パスワードを入力すると最初のメーリングリストが作成される。

ここで、/var/lib/mailman/dataにaliasesとaliases.dbがlistユーザーの所有で作成されていることを確認してから、postfixのaliasesとして認識させるために、/etc/postfix/main.cfのalias_mapsの項目にカンマで区切ってhash:/var/lib/mailman/data/aliasesを追加しておく。

後は再起動すればapache,postfix,mailmanが起動してメーリングリストが使える様になる。