専用のWebサーバがあるのですが、昨晩、高負荷で再起動しました。
関係した皆様、ご迷惑をおかけしました。
24時間有人のリブート体制を取ってた。さすが！＞サーバ屋
これを機に、Linuxのメモリ管理について調べてみた。
そもそも、今週に入ってから、やたらとメモリの使用量が多かったので。
一番、手っ取り早く確認できるのが、Webminのプロセスマネージャ。
これを見ると、
実メモリ：506M うち、空きが、222M ←半分しか使っていない
スワップ：1G うち空きが、675M ←余裕
つまり、メモリは余裕の余裕ということになる。
ずっと以前に作ったPHPの掲示板が、常に、英文SPAMの標的になっていた。
掲示板のデータはデータベースに書き込むし、書き込みお知らせメールも送信している、その上、送信先のアカウントでは、SpamAsassinが動いているので、どう考えても、サーバのリソースの無駄使い。
そこで、PHPで英文SPAMをはじくように修正。
件名に日本語が入ってなければ、書き込みNGとした。
//日本語が含まれていればtrueを返す
function is_japanese($arg)
{
$r = false;
$c = strlen($arg);
for($i = 0; $i < $c; $i++){
$chr = ord($arg[$i]);
if((0x80 < $chr)){
$r = true;
break;
}
}
return $r;
}
件名でも投稿者でもいいので、POSTされた文字列をこいつでチェック。
false（英文のみ）だったら、エラーで書き込みしない。
■参考エントリー
簡単な BBS spam対策
D-FAXが切れてしまったかも・・・
FAX通じないかも知れませんっ！！
あれまぁ・・・まいったなぁ～
print_r() でもいいんですが、どうも、横にずらずら表示されるので、見難い。
なもんで、
function display_array_data($data,$pre="")
{
while(list($key,$val) = each($data)) {
if (is_array($val))
display_array_data($val,$pre."[".$key."]");
else
print $pre."(".$key.")->[".$val."]<br>";
}
}
最近、ブログがメモ変わりになっている・・・
procmailで要らないメールの転送を抑えるのレシピは間違ってました。
:0 c
* ! ^X-Loop: imai@karakuriya.biz
* ! ^Subject: \[SPAM\]
* ! ^From:.*hogehoge@hogehoge.com
* ! ^From:.*hogehoge@hogehoge.com
* ! ^From:.*hogehoge@hogehoge.com
! xxxxxxxxxx@r.vodafone.ne.jp
が正しいです。
正規表現の理解が間違ってました。
メールアドレスの前に、名前とかいろいろつくので、それを .* で対応。見難いですけど、半角のドットとアスタリスク（．＊）です。
このブログに、アマゾン・アソシエイトを入れました。入れたのはちょっと前ですが。。。
アソシエイトには、いくつかのリンクがあり、今までは、「Amazonおまかせリンク（β版）」にしていた。Webサイトの内容の沿った商品を自動的に表示するという便利なリンクだが、どうも、いまいち、パッとしない。
「福井の童話」とか「福井の山」とかいう本がいつも表示されていた。
β版なので、仕方ないですが、ちょっと、これではなぁ・・・
で、「Amazonライブリンク」に変更した。これは、商品ジャンルやキーワードを元に商品を表示するといったもの。
ここで、ジャンルとキーワードは何にするか？
数あるブログのページに全て同じジャンル、キーワードの商品を表示しても面白くない。
Amazonが生成したリンクをよく見ると、キーワードに相当する部分は、クエリーになっている。
そこで、カテゴリーのページは、そのカテゴリ名をクエリーに、エントリーのページはタイトルをクエリーに渡してやるようにテンプレートを変更した。
カテゴリ名や記事のタイトルに沿った商品を出すようになるので、全部が全部うまく商品が出るわけじゃないが、ある程度いい感じで出るようになった。
パケットし放題に入りました。
なので、メール転送のパケ代は気にしなくていいのですが、溜まったメールをいちいち削除するのが面倒になってきたので、要らんメールは携帯に転送しないようにした。
携帯へのメール転送を制限で作ったprocmailのレシピを変更。
:0 c
* ! ^X-Loop: imai@karakuriya.biz
* ! ^Subject: \[SPAM\]
* ! From: hogehoge@hogehoge.com
* ! From: hogehoge@hogehoge.com
* ! From: hogehoge@hogehoge.com
! xxxxxxxxxx@r.vodafone.ne.jp
のように、転送不要のメールアドレス（hogehoge@hogehoge.com）を羅列させます。
これで、メールマガジンなど、別に携帯に転送する必要のないメールの転送をやめました。
メールの転送もここまで細かく設定できると便利だなぁ～
追記
4/12 あれ？ちょっと調子悪いかも・・・
間違ってました。こちらが正しいです。
procmailで要らないメールの転送を抑える（改）
最近のBGMです。
SNSやXOOPSを入れたサイトに新しくシステムを作る場合や、SNSとXOOPSが同居するサイトでは、よくセッションの競合が起きる。
オリジナルのCMSとかは、ログイン情報を保持するためにセッションを使いますが、そうすると、SNSにログイン出来なくなったり、いろいろと面倒な部分があります。
IEだと、２つ立ち上げた時はそれぞれのセッションIDは違うので、こういう問題も起きない（起きにくい？？）のですが、Firefoxだと、別のタブでも、別のウィンドウでもセッションIDは同じなので、もろ、この問題にあたります。
こういう場合は、セッションの名前をそれぞれ別にすると解決します。
phpinfoで見てみると、session.nameがPHPSESSIDとなっているので、PHPの先頭で
ini_set('session.name',HOGEHOGE);
と別の名前を指定します。
これで、セッションの名前が別になるので、競合は避けられます。
MySQLで文字化けで解決したかに見えた文字化け問題ですが、テストデータベースから本番データベースに移行した際に、再び、「?????」の表示になった。
どうも、データベースを作成した際の文字コードが違っていたらしい。
コマンドラインから mysql を上げ、以下のコマンドを実行。
show create database データベース名;
テストデータベースは、DEFAULT CHARACTER SET utf8 と表示されるが、本番データベースは、DEFAULT CHARACTER SET latin1 になっていた。そもそもデータベースを作成するところが違っていた。
phpMyAdminでデータベースを作る際の指定がなってなかった。
照会順序を、utf8_general_ci というやつにしないといけない。
まずは、phpMyAdminの「操作」タブの一番下のところで、照会順序をutf8_general_ciにする。
テーブルを作成する際、テキスト系の型（textとか）の照会順序は、デフォルトでこの照会順序が使われるみたいです。
そこで、テーブルの列の照会順序も変更します。そもそも、ここがutf8_general_ciになっていないことが、文字化けの根源です。ここがutf8_general_ciになってないと、いくら set names utf8 を指定しても文字化けは直りません。
それか、テーブルをcreateする際に、しっかりと、
DEFAULT CHARSET=utf8
と、文字コードを指定することです。
このブログに文字化けという事を何回書いただろうか・・・
今回も、MySQLの文字化けで、２日悩んでしまった。
PHPもMySQLもUTF-8。そのシステムのデータをちょこっと利用するので、新しくPHPを書いたら、文字化け・・・
もちろん、UTF-8で。
mb_convert_encodingばかり疑ってた。同じ文字コードなので、余計に分からなかった。
ドツボにはまるとこんなもんである。
いろいろ調べたら、
http://wota.jp/ac/?date=20061011
なサイトを発見。
おや・・・
どこかで見たことがあるような内容だ。
どこだ！どこだ！どこだ！
給油をした。
今回は、ちと走っている。計算したら、18km/l を超えた。お仕事であちこちちょいちょいにしてはいい数字！
しかも、ほどＡＴモードで。
ちょっと前に、JAFのエコドライブをいう記事を読んだ。
なんでも、車が動き出す時が一番燃料を食うそうで、走り出してからの加速はそんなに食わないと書いてあった。
今回は、走り出しは、そぉ～～～っとアクセル踏むことに心がけた。
周りの車と一車身つけられてもなんのその。
その後の加速で追いつきゃいいさ！
これが、結構、追いつくもんだ。
ワタシ、ＡＴモードで走ったほうが燃費いいのかも。
マニュアルだど、どうしても、グイグイいってしまうので・・・＾＾）；
でも、いろんなサイトを見ると軽く20オーバーしてる方も多し。京○の大御所＠カツ丼大好きさんも、その1人。
やはり、大御所の域にはまだまだ修行が足りん。
PHPでは、一般的にクエリーは、
hogehoge.php?a=1&b=2&c=3
member.php?id=1000
member.php?id=1001
つまり、URLのクエリーを見れば、容易に、そのクエリーの意味がわかってしまうわけである。
アマゾンのサイトを見てみよう。
このサイトもどう考えても、データベースばりばりのサイトなのだが、上のような一般的なURLではない。？や＆が一切見当たらない。まさか、こんな深い階層に実際のページがあるもと思えない。
これは一体、どうやって実現しているのか？
先の例で言うと
member.php?id=1000
を
member/1000/
でアクセス出来ないのか？
さえぎるものが何もないので、稲妻がよく見えました。
mixiで評判よかった（ｗ）ので、こちらにも出そうっと。
鯖江近辺では、数軒だけという非常にローカルな停電もあり。
春江では、落雷によるかどうかはわかりませんが、お寺の火事があった模様。
