備忘録 for myself in the future

これまでCGI掲示板にはT-Note Ver.4.05を使っていたが、あまりにもスパム書込がひどいので、簡易CAPTCHAがついた掲示板に移行しようと決意する。

見つけたのがC-Board Moyuku。とりあえずマニュアル通りに設置。

c-board.cgiが改行コードがおかしいのでnkfを通して改行コードをUNIX仕様に変更する。

id指定でマルチ掲示板にできるし、とりあえず満足。しかし、簡易CAPTCHAがちゃんとスパムをブロックするかどうかは今のところ不明。かなり簡易なのでその気になったら画像認証で簡単に破れそうだけど。

スパムの抑制のためにCAPTCHA認証を導入することにする。以下のプラグインを導入。

SI CAPTCHA Anti-Spam

これでコメントを書く時にCAPTCHAが必要になるのでスパムが減るだろう。ダメだったら、Akismetの導入も考えよう。

バックアップには以下のプラグインを導入。

BackWPUp

週に一度、過去4週に遡って/usr/local/www/wordpress/wp-content/backups/にバックアップが作成されるようにする。適宜ここの中のファイルをバックアップすることで簡易バックアップとする。

 

マルチサイト化するために、/usr/local/www/wordpress/wp-config.phpの認証用ユニークキーの直前に

define(‘WP_ALLOW_MULTISITE’, true);

を記入する。

ついでに/usr/local/www/wordpress内のすべてのファイルをwww:wwwに所有権を移し、

define(‘FS_METHOD’, ‘direct’);

をwp-config.phpに追記しておく。これでWordPress内からプラグインのインストールや更新が可能になる。

以上を済ませたら、再びWordPressにアクセスするとマルチサイト化の手順が表示される。今回はサブディレクトリタイプで構築する。指示に従って、blogs.dirの作成、wp-config.php、.htaccessの修正を済ませると、サブディレクトリにブログを作る事が出来るようになる。

まずはWordPressにアクセス出来るようにApacheにディレクティブを書く

/usr/local/etc/apache22/Inculde/wordpress.conf

—

AddType application/x-httpd-php .php
AddType application/x-httpd-php-source .phps

Alias /wordpress/ “/usr/local/www/wordpress/”

<Directory “/usr/local/www/wordpress/”>
AllowOverride All
Options Indexes FollowSymLinks
Order Allow,Deny
Allow from all
DirectoryIndex index.php
</Directory>

—

これで外部からWordPressにhttp://bam-system.ddo.jp/wordpressでアクセス出来るようになる。大事なのは、うちの様にプライベートLAN内にサーバーをおいてルーターのport forwardingでサーバーを公開してる場合、内部からはプライベートアドレスでIP直打ちでアクセスしなければならないが、WordPressは最初に初期設定した時のサイト名で全URLをハードコーディングしてデータベースに書き込んでしまうので、プライベートからしかアクセスできなくなってしまう。なので、初期設定はかならず外部に公開しているサーバー名でアクセスできる環境から行うこと。

というわけで、iPhoneでテザリングして外部からWordPressにアクセスする。内部からアクセスしていろいろやりたい場合はVirtualBox上のUbuntuでhostsに記入してやることにしよう。

最初にアクセスするとインタラクティブにwp-config.phpを作成するモードになる。ここでMySQLでデータベースを作成した時の情報が必要になる。データベースへの接続が終わると初期ブログのセットアップになる。後でマルチサイト化するが、ここで作成する初期ブログのユーザーがサイト管理者になるので、adminユーザーとして作成しておく。

まずは

mysql_secure_installation

を実行してrootのパスワードの設定、ロカールからのみのアクセス制限、初期ユーザーやデータベースの削除を指示通り行う。

次にmysqlの対話モードに入る。

mysql -u root -p

対話コマンドでデータベースの作成とアクセスするユーザーの登録を行う。

create database wordpressdb;

grant all on wordpressdb.* to ‘wordpress’@’localhost’ identified by ‘Password’;

末尾の;はコマンドの終了を意味するので、ついつい忘れがちだが忘れない。ここで作成したデータベース名’wordpressdb’、アクセスユーザー’wordpress’、パスワード’Password’はWordPressの初期セットアップに必要なので忘れないこと。初期セットアップが済んだら忘れてもよい。

 

続いてdatabases/mysql55-serverからMySQLを導入する。

導入後、/usr/local/share/mysql/my-medium.cnfを/var/db/mysql/my.cnfにコピーする。その後、my.cnf内の[mysqld]セクションに

character_set_server = utf8
collation_server = utf8_general_ci

を追記してデータベースのデフォルト言語をutf-8に設定する。

さらに/etc/rc.confに

mysql_enable=”YES”

を書いてから

/usr/local/etc/rc.d/mysql-server start

でmysqlサーバーを起動する。

portsコレクションの中にjapanese/wordpressがあったので、とりあえずこれでさっくり導入する事にする。WordPress本体は/usr/local/www/wordpress/にインストールされる模様。

重要なのは途中でPHP5のインストールがあるので、そこでApache Moduleをオプションで選んでおくこと。これとは別にlang/php5-extensionsを導入して、途中のオプションでmbstringとGDとMySQLとZLIBチェックする。GDとZLIBが必要かどうかわからないがよく入れろと書いてあるので念のため入れておく。

/usr/loca/etc/php.ini を用意しないといけないが、WordPress導入記事をつらつらと探していたらmbstringでutf-8を設定してあるサンプルがウェブに転がっていた(http://www.kishiro.com/FreeBSD/php5.html)のでとりあえずこれで良しとする。ていうかphp.iniの設定は複雑すぎて手に負えない。

これで大丈夫かと思ったら肝心のMySQLが入っていないじゃないか。

 

サーバーのOSであるFreeBSD 7.4-RELEASEが2013年1月末でEnd of Lifeを迎える。

というわけで、freebsd-updateで8.3-RELEASEにアップグレード。時間はかかったが基本的なサービスは問題なく動いている模様。楽ちん楽ちん。

と思ったら、危惧していた通りPython24&Zope29で動かしていたCOREBlog-1.2.5が動いていない。というかPython自体が参照ライブラリが見当たらないのでZopeそのものが上がっていない。

というわけで、さっくりこれらをアンインストールして、WordPressに移行することにする。

Zopeのログ・ローテーションで気になって調べてみたらapacheも全くローテーションされておらずとんでもない(というほどでもないが)サイズになっていた。というわけで、こちらもnewsyslog.confに設定追加。

/var/log/httpd-access.log 644 7 * @T00 J /var/run/httpd.pid
/var/log/httpd-error.log 644 7 * @T00 J /var/run/httpd.pid

こちらは@T00の設定で毎日0時にログをローテーションして1週間保管する設定に。FreeBSDのportsからインストールしたapacheは/var/run/httpd.pidにデフォルトでpidを書き出すので、設定変更していたら注意すること。

ログのローテーションがちゃんと出来てるかは後日ちゃんとチェックしないといけないか。

ついでに、httpd-error.logを見たら、cgiが呼び出されるたびにjcode.plが妙なエラーを吐いていることに気が付く。たぶんjcode.plが古いせいだろう。長年メンテナンスしてないからなあ。というわけで、japanese/jcode.plをportsからインストールし、cgiに記入してあった

require ‘./jcode.pl’;

を

require ‘jcode.pl’;

に変更してcgiと同ディレクトリに置いてあった古いjcode.plからportsからインストールされた新しいjcode.plを参照する様に変更したところ、エラーを吐き出さなくなった。めでたしめでたし。

ついでに、cgiにおかしなアクセスをするスパマーをはじく為に書いている拒否ディレクティブが長くなってきてうっとうしくなってきたので、cgi-binセクションを別ファイルに切り分けることに。portsからインストールされるapache22は/usr/local/etc/apache22/Includes内においた*.confファイルを最期に一気に全て読み込むようになっているので、cgi-binセクションを別ファイルにしてcgi-bin.confとしてこのディレクトリに置いて、本体のhttpd.confからセクションを丸ごとコメントアウト。これで、cgi-binに追加の拒否ディレクティブを書き足すのが楽になるよ。

サーバーのディスクがぱんぱんになっていたので何が原因かと調べていたら、どうも稼働時からZopeのログがまったくローテーションされていないのでログが膨大なサイズに膨れ上がっていた。というわけで、ちょこちょこ調べてログがローテーションされるように設定。

具体的にはFreeBSDにはnewsyslogというログをローテーションするシステムがあるので、その設定ファイルである/etc/newsyslog.confに記述を追加。

/usr/local/www/Zope29/log/Z2.log www:wheel 644 5 5000 * J /usr/local/www/Zope29/var/Z2.pid
/usr/local/www/Zope29/log/event.log www:wheel 644 5 5000 * J /usr/local/www/Zope29/var/Z2.pid

これでZopeのログが5MBに達するごとにローテーションしてからZopeのプロセスにログの再始動を促してくれる。ミソはZopeが書き出すpidファイルを参照してnewsyslogにどのプロセスに再始動のシグナルを送ればよいかを教えてあげること。デフォルトではSIGUSR1を送るらしい。SIGUSR1によるログの再始動に対応していないプロセスの場合はSIGHUP1を送る様に設定の最期にシグナルのナンバーを記述すればいいのだろうか？

rootでnewsyslog -Fで強制的にログをローテーションするテストが出来るので動作確認。

でも、最大の圧迫の原因は何年もデータベースのパックをしてなかったためにデータベースがロールバック用のアンドゥデータでぱんぱんに膨れ上がっていたためでした。こっちも自動で定期パックするようにした方がいいのかもしれないけど、あんまり高頻度にパックするとたまにデータベースが壊れるらしいので、当面は手動のままでいこう。毎日のdfの出力結果を注視しておかないと。