さくらレンサバに入れたTracから通知メールが飛ばせない ― 2008年04月03日 16時05分58秒
前々から使っているさくらレンタルサーバ上に、最近 Trac を入れて使おうとしているのですが、メール通知の設定をしても、通知メールがうまいこと飛んでこなくて困っています。
trac.ini の [notification] ディレクティブの設定内容は以下の通り (ドメイン名、メールアドレスは便宜上変えてあります)。
[notification] always_notify_owner = true always_notify_reporter = true always_notify_updater = true mime_encoding = base64 smtp_always_bcc = #smtp_always_cc = example@example.sakura.ne.jp smtp_default_domain = smtp_enabled = true smtp_from = example@example.sakura.ne.jp smtp_password = smtp_port = 587 smtp_replyto = example@example.sakura.ne.jp smtp_server = example.sakura.ne.jp smtp_subject_prefix = __default__ smtp_user = use_public_cc = false use_short_addr = false use_tls = false
smtp_always_cc
のコメントアウトをはずすと、そこで指定したメールアドレスがレンタルサーバー上に設定されたアドレスであれば、そのアドレスにだけはメールが届きます。
smtp_always_cc
をコメントアウトしたままの場合、以下のような動作になるようです。
-
Ticket の報告者がレンタルサーバー上に設定されたメールアドレスを設定している場合、通知メールは問題なく配信される。
-
Ticket の報告者がレンタルサーバー外の (例えば ISP などが提供する) メールアドレスを設定している場合、通知メールは届かない。そして、
log/trac.log
には以下のようなエラーログが出力される。2008-04-03 16:13:26,873 Trac[web_ui] ERROR: Failure sending notification on change to ticket #3: {u'murachi@example.ne.jp': (553, '5.3.0 <murachi@example.ne.jp>... Please receive your mail before sending')} Traceback (most recent call last): File "/home/example/local/lib/python2.4/site-packages/trac/ticket/web_ui.py", line 562, in _do_save tn.notify(ticket, newticket=False, modtime=now) File "/home/example/local/lib/python2.4/site-packages/trac/ticket/notification.py", line 129, in notify NotifyEmail.notify(self, ticket.id, subject) File "/home/example/local/lib/python2.4/site-packages/trac/notification.py",line 216, in notify Notify.notify(self, resid) File "/home/example/local/lib/python2.4/site-packages/trac/notification.py",line 115, in notify self.send(torcpts, ccrcpts) File "/home/example/local/lib/python2.4/site-packages/trac/ticket/notification.py", line 275, in send NotifyEmail.send(self, torcpts, ccrcpts, hdrs) File "/home/example/local/lib/python2.4/site-packages/trac/notification.py",line 368, in send self.server.sendmail(msg['From'], recipients, msgtext) File "/usr/local/lib/python2.4/smtplib.py", line 691, in sendmail raise SMTPRecipientsRefused(senderrs) SMTPRecipientsRefused: {u'murachi@example.ne.jp': (553, '5.3.0 <murachi@example.ne.jp>... Please receive your mail before sending')}
別に通知機能自体は今すぐ必要なわけではないんですが、何でこうなっちゃうのかだけは一応知っておきたいので、とりあえずメモってみます。。。
そもそもさくらのレンサバの sendmail がそういうものなのかなぁ。。。あ、ちなみに smtp_port
が 587 になってますが、25 のままでももちろんダメでした。
とりあえず調べてみたらエラーの内容はなんとなくわかってきた。
SMTPRecipientsRefused
は、 Python のモジュールsmtplib
が送出する例外で、すべての受取人が (sendmail コマンドによって) 弾かれた場合にのみ発生するらしい。- ログの最終行の
553
という数字は、 sendmail コマンドが返すエラーコードで、不正中継っぽいもの (spam の踏み台である可能性があるケース) を弾いたときのものっぽいです。
さくらのレンサバの sendmail コマンドのポリシーがどうなってるのかがいまいちよくわからんのですが、その辺の設定が仮に変えられるのだとして、その為に spam の踏み台になるリスクが生まれるんだとするとそれはさすがにまずいので、この辺は良く調べてから対応したほうがよさそう。そもそも回避できないのかもしれないけど。。。
当面は通知なしで運用しようかな。(←ひよったw)
ついに ActivePerl も ― 2008年04月03日 22時20分16秒
さくらのレンサバでの採用も秒読み段階だろうか? 個人的に動かしてる自作 CGI が pseudo hash 使っちゃってるもんだから、気が気でしょうがないのよね ((((/;^^)/ 。
とりあえず後で落として動かしてみますか。。。
Gentoo Linux の方はどうなってるんだろ? そっちも確認してみないとなぁ。。。
Trac に TracBlogPlugin を入れてみたよ。 ― 2008年04月07日 01時08分13秒
- だいたいこちらさんの書かれていらっさる通りにセットアップできました。
- 本家にも書かれているけど、TagsPlugin のバージョンは 0.3 以上 0.5 未満じゃないとダメ (いまんところ)。こいつの最新版が現在 0.6 なのですが、それだと (テストしてないだとかそういうレベルではなくて) 動きません。おいらは 0.4.1 を入れたよ。
- インストールは基本的に、
python setup.py install prefix=<libディレクトリを配下に持つディレクトリへのパス>
って感じで ok 。依存関係とかもチェックしてくれるので、python setup.py bdist_egg
するよりも断然オススメ。 - インストール後、
trac-admin <env-path> upgrade
するのを忘れずに。おいらはこれでハマッタ\(^O^)/ - trac.ini の
[components]
ディレクティブには、本家に書かれているtBlog.* = enabled
も必要 (こっちを鵜呑みにしちゃうと欠けちゃうので)。但し、[trac]
ディレクティブのdefault_handler
行は、トップページもブログにしてしまいたいのでなければTracBlogPlugin
ではなくてTagsWikiModule
にしておくべき。 - そして絶対に忘れちゃいけないのがパーミッションの変更。
trac-admin
の対話モードで以下のように type するのを忘れずに (但しmyuser
はあなたのユーザ ID に置き換えること)。これをやらないと誰もブログにアクセスできなくなる (これも微妙にハマッタw)。permission add anonymous BLOG_VIEW permission add myuser BLOG_ADMIN
- セットアップに成功すればメニューに「Blog」というのが出てくるので、
[[BlogShow]]
だの[[BlogPost]]
だのは基本的にはどこかに書く必要なし。但し Wiki ページのどこかに組み込んで使いたいのであれば、これらのタグはそれなりに有用。
mod_perl の無い環境で Apache::Registry みたいなことをする方法を考える ― 2008年04月10日 23時59分27秒
まだやってないけど。
CGI 呼び出しによって毎回起動するプロセスを「呼び出し側プロセス」、実際の処理と出力を行うプロセスを「処理側プロセス」と呼ぶことにして。
呼び出し側プロセスの処理は以下の通りかな。
- 名前付きパイプ pipe_A が無ければ作る。
- 名前付きパイプ pipe_B を作る。これは毎回、違う名前で作る。
- 処理側プロセスが存在しなければ fork し、子プロセスを処理側プロセスとして、そのプロセス ID をファイルに記録する。
- pipe_A を開き、pipe_B のファイル名と環境変数、そして標準入力からの入力を出力する。
- pipe_B を開き、入力した内容を標準出力に書き出す。
- pipe_B を削除する。
処理側プロセスの処理は以下の通りかな。
- pipe_A を開き、pipe_B のファイル名と環境変数、そして標準入力からの入力を入力する (その単位でデータを適切に読み出せるよう、データのサイズがわかるようになっている必要がある)。
- 処理を行い、結果を pipe_B に書き出す。
- 1 に戻る。
懸念点。つか、おいらの知識が圧倒的に足りてないだけの話なんだけど。
- 呼び出し側プロセスは毎回起動するわけだからあんまり解決になっていないのでは?
- 処理側プロセスが大量のモジュールを読み込むような場合には、それなりに効果はあるのかも。
- mod_perl が使えないような環境、すなわちさくらのレンサバみたいなレンタルサーバー環境では、処理側プロセスみたいなのは短時間で kill されちゃうだろうから運用的には効果は薄いのでは?
- その辺、ログを録ったりして実際の動きを確認してみたい。
- 実際に使われているシグナルの種類次第では、トラップして無視って運用もありかも。。。 (危険!!^_^;)
- パイプによる通信コストは無視できないのでは?
- これが一番のネックになりそうな気がする。もっとマシな方法がありそうなんだよなぁ確かに。。。
- pipe-A はセマフォ的なアクセス制御が必要では?
- アクセスが集中した場合、呼び出し側プロセスの待ち行列を DB か何かで管理して、行列が一定数を超える場合は 503 エラーにしちゃう、みたいな運用かなぁ。
- mod_perl で動かせる環境との間で可搬性が失われるのでは?
- そこはあまり心配してない。 mod_perl 用に別途インタフェースを用意して、どっちからでも同じように呼び出せるような作りにするのはいくらでも可能なはず。
以上、妄想メモ。
ちょwwwwはやwwwwww ― 2008年04月16日 10時50分46秒
harapeko.jp の後継サーバはこいつにしてみました。専用サーバのくせして安いのはいいが、CentOS プリインストールのまま何もいじってないしコントロールパネルみたいな便利なものもセキュリティやら監視やらの特別なサービスもなあんもないよー、全部 ssh で設定がんがってねーという、実に漢らしいサービス内容に惚れ込みましたw。収容データセンターがソフトバンク IDC だってのが微妙に気にはなりますが。。。
で、オンライン登録時に「納品できるのに 2週間ぐらいかかります」とか表示されてたので、まぁ現行 harapeko.jp ドメイン消滅やら登記完了やらが重なってむしろ丁度いいかな、設定に時間かかったらドメイン取り直したのにもてあましちゃってあれかもしれないけど、とりあえず気長に待つかぁ、とか思っていたわけですが、登録した翌日には納品書が届きましたよ。これにはさすがに驚いた。設定も完了していて、既に自由に使える状態に。これはうれしい誤算だ。w
そんなわけで、取り急ぎ、apache だけ設定を済ませてみました。いや、 mod_perl とか組み込んでないし全然完璧じゃないですが、とりあえず動いてるっちゅーことで。
sendmail と sftp も設定しちゃわないとなぁ。。。
とりあえずホダ塾入れてみた。 ― 2008年04月22日 13時39分52秒
XOOPS Cube のホダ塾ディストリビューションを入れてみた。いろいろと勘違いとかもあって入れるだけでも随分と時間がかかったが。。。
ドメイン移転終わったらまた入れなおす予定なので、セットアップ手順をメモしておく。あ、一応、ファーストサーバのデルタ1・シリーズ対象ってことで。
-
Apache を使える状態にしておく。 mod_php5 とかは既に入ってた。
%su - %vi /etc/httpd.conf # 必要に応じて。 AddDefaultCharSet
noneoff とか %vi /etc/php.ini # 必要に応じて。デフォルトで概ね大丈夫そうだけど %/etc/init.d/httpd start # 既に起動中の場合は restart %ntsysv # httpd にチェックを入れる。ソフトバンクIDC が停電しても自動起動するように %chown murachi:apache /var/www/html # だっけかな? ディレクトリ名変えちゃったからもう忘れたw %chmod g+s /var/www/html %exit %cd /var/www/html %cat > test.php # 動作確認後、すぐ消す <?php phpinfo() ?>^D -
MySQL を使える状態にしておく。これも最初っから入ってる。
%su - %mysql_install_db --user=mysql %vi /etc/my.cnf # default-character-set=utf8 にする (後述) %/etc/init.d/mysqld start %ntsysv # mysqld にチェックを入れる
/etc/my.cnf
は大体こんな感じ。矢印付きが書き加えた行。[mysqld] datadir=/var/lib/mysql socket=/var/lib/mysql/mysql.sock # Default to using old password format for compatibility with mysql 3.x # clients (those using the mysqlclient10 compatibility package). old_passwords=1 default-character-set=utf8 # ← [mysql.server] user=mysql basedir=/var/lib [mysqld_safe] log-error=/var/log/mysqld.log pid-file=/var/run/mysqld/mysqld.pid [client] # ← default-character-set=utf8 # ← [mysqldump] # ← default-character-set=utf8 # ←
-
MySQL の root ユーザーを設定する。 set password がなぜか使えなかった。
%mysql -u root mysql mysql> update user set password=password('password') while user='root'; mysql> flush privileges; mysql> quit %mysql -u root # これで入れちゃったら設定失敗
-
MySQL にデータベースとユーザーを追加する。
%mysql -u root -p mysql Enter password: mysql> create database xoopsdb; mysql> grant all on xoopsdb.* to xoopsuser identified by password 'password'; mysql> update user set host='localhost' while user='xoopsuser'; mysql> flush privileges; mysql> quit %mysql -u xoopsuser # これで入れちゃったら設定失敗 %mysql -u xoopsuser -p xoopsdb Enter password:
-
ホダ塾Xoops を環境にコピーする。
chmod g+s
をうまく使えばグループapache
で統一されるので、書き込み権限必要なファイルやディレクトリもchmod 777
やchmod 666
ではなく、chmod g+w
で足りるようになる。%cd %mkdir hodajuku %cd hodajuku %wget http://jaist.dl.sourceforge.net/sourceforge/hodajuku/hd_full_1_0_1b.tar.gz %tar -xzvf hd_full_1_0_1b.tar.gz %cp -R html/* /var/www/html/ %su # XOOPS_TRUST_PATH のコピー先ディレクトリを先に用意する。グループを apache で統一するため %mkdir /var/www/xoops_trust_path %chown murachi:apache /var/www/xoops_trust_path %chmod g+s /var/www/xoops_trust_path %exit %cp -R xoops_trust_path/* /var/www/xoops_trust_path %cd /var/www/html %chmod g+w cache uploads templates_c mainfile.php %cd ../xoops_trust_path %chmod g+w . cache uploads templates_c modules/protector/configs
-
ブラウザからサイトにアクセスすると、インストールが始まる。指示に従って進める。言語は ja-utf8 (だっけ?) を選択。
-
すべてが終わったら、不要なインストールの残骸の除去と、権限設定の修正を行う。
%cd /var/www/htdocs/ %rm -rf install %chmod g-w mainfile.php
以下の修正をしました。指摘 thanks >ぐるりさめ。
- ×
AddDefaultCharset none
- → ○
AddDefaultCharset off
- → ○
ちなみに、実際の鯖の設定を確認してみたら、ちゃんと「off
」になってた。何を見て間違えたんだろう>ヲレ。。。
XOOPS 使うのやめたっ ― 2008年04月23日 21時02分36秒
とりあえずホダ塾入れてみたはいいものの、そこから先で右往左往。。。なに、CMS ってシステム突っ込んだらあとは全部ブラウザからできるものなんじゃないの? から始まり、メニューのカスタマイズに自由さを感じなかったり URI 規則 (あの必ず「module
」って入る) が気に入らなかったり結局 PHP コード叩かなきゃいけなかったり基本がテーブルデザインだったりと知れば知るほど気に入らん事のオンパレード。そして如何にも Web デザイナー的なコミュニティー文化に毒されたテキストを読んでいるうちにおいらの XOOPS への期待はふにゃりふにゃりと萎えてゆき、代わりに別の欲求が腹の底から湧きあがってきてしまった。
そんなわけで、やっぱり XOOPS 使うのやめます。w
でも取り急ぎ企業サイトを作る必要はあるので (そうしないと会計報告ができなくなっちゃう…株式会社なのに)、とりあえず以下の方針で行こうかなと。
-
とりあえず普通に HTML 書いて静的にホームページを作ります。そのために、サイト全体で共通する部分のテンプレートデザインをまず考えることにします。
-
企業の公式ブログを設置するかどうかは微妙ですが、設置する場合はおそらくサブドメインを設け、1. の HTML から普通にリンクして終了です (あるいはリンクしないかもしれない)。使うのはたぶん WordPress 辺りになると思います。
-
将来的にはやっぱり CMS が欲しいですが、そんな将来のために、 CMS は自作することにします。ちょうど、今仲間内のためにこっそり作っている掲示板システムの核の部分がそのまま流用できる可能性もあるので、うまくすれば年内にある程度出来上がってくるかもしれません。
とりあえずそんな感じで。晩飯食ってこよー。
trackback spam が 1日 500件以上来てるんですが。。。 ― 2008年04月29日 22時06分23秒
4/24 の朝に tb spam を潰したのを最後に 5日間ぐらい放置していたら、未処理の tb が 2746件も溜まってた。。。目視で subject と site title だけ見つつ全部 spam として処理したのですが、もしあの中に spam じゃない tb が混じっていたらごめんなさい>送ってくれた人。
それにしても、アサブロは spam として処理された tb の情報をちゃんと活用してくれているんだろうか。。。????
最近のコメント