Linuxの最近のブログ記事

自宅のVMware Server上のCentOS 4.5で、いろいろhttpdを立ち上げて開発環境を区別していて、いちいち開発環境を立ち上げるたびに起動スクリプトを書くのが億劫になってきて、汎用スクリプトをでっちあげた。

basenameで起動パスを識別するようにしたので、シンボリックリンクで別名を付けてやるだけで任意のhttpdを立ち上げてくれるという仕組み。

こうしておけば、apacheを使ったWebアプリのプロジェクトを複数抱えてても面倒臭くないよ！

apache以下一連の環境をconfigureする手間はやっぱりかかるけどｗ

あととりあえずhttpd.workerは捨ててます(PHP(笑))

使い方：(※注：以下、fooは任意の文字列)

まずシンボリックリンクを張って

ln -s /etc/rc.d/init.d/httpd_template /etc/rc.d/init.d/httpd_foo

あとは普通に呼び出すだけ

/etc/rc.d/init.d/httpd_foo start
/etc/rc.d/init.d/httpd_foo stop
/etc/rc.d/init.d/httpd_foo restart
などなど

このスクリプトを使用する際の前提条件：

• configure時に--prefix=/usr/local/apache_foo でビルドされていること
• 起動スクリプトは /etc/sysconfig/httpd_foo を読み込みます
• httpd.conf で PidFile が /var/run/httpd_foo.pid に設定されていること
• ロックファイルは /var/lock/subsys/httpd_foo を見に行きます
• シンボリックリンクを張ること(killallするときに便利だから)：/usr/local/apache_foo/bin/httpd -> /usr/local/apache_foo/bin/httpd_foo

おすすめの構成はこんな感じ：

• /usr/local/apache_base (port 80, mod_rewrite + mod_proxy にて各プロジェクト用にポート転送)
  • /usr/local/apache_foo (port 10080)
  • /usr/local/apache_bar (port 10081)
  • and so on.

スクリプトはhttpd-2.2.8に付属していたbuild/rpm/httpd.initをベースにしています。

前のエントリで少し毛嫌いしてたけども、 Starpit の手法であれば「まだマシ」かなぁと思った。 greylisting では確実に該当 IP からの一発目のメールが遅延してしまうけど、こっちならば遅延はない ( その代わりにサーバの初期応答が 1 分半ほど遅れる ( 応答遅延時間は設定による ) ) 。
ただ問題なのは、ここで述べられているけど、 Postfix 本体でこれを実現しているので、 RCPT TO 単位で tarpitting が起こってしまう。つまり 1 通のメールだったとしても宛先が 10 件あれば、 90 秒の tarpitting だとすると、全ての宛先に送りきるまでに 15 分待たされてしまう。
この構造的にまずい点については、postgrey による greylisting のように Postfix の filter で実現できるといい感じらしい。 この考えを取り入れた taRgrey というハイブリッドな手法にすれば、これらの弱点は克服できるそうだ。ふむふむ。しかしまだこの手法に対する実装は無いとのこと。

ここまで調べて、うちの鯖に実装するなら taRgrey だなぁと確信…。
taRgrey なら、まずスパムのほとんどは tarpitting によって阻止可能。この部分の設定はメンテナンスフリー。
スパムではないのに tarpitting で接続が切れてしまったものに対しては greylisting で救済する。この部分の設定は、ホワイトリスト & ブラックリストのメンテナンスが必要だが、そもそも tarpitting での誤検出はごくまれらしいので、単体で greylisting するよりもメンテナンスが容易 ( なはず ) 。
S25R に該当する正当なメールに対して tarpitting してしまっても良いのであれば、ホワイトリストのメンテすらやらなくて良い ( はず ) 。

うーん、やっぱり「メンテナンスフリー」は大事ですよ。
単体の greylisting なんて、趣味の自鯖では到底やろうとは思えない。いや、むしろ仕事なら尚更かも。
taRgrey の実装が待ち遠しい今日この頃です。

自宅サーバでダイナミック DNS を使ってメールサーバを活用しようと思い立ったので、 Spamassassin とかいじってみる。

下記、 /etc/procmailrc の記述：

  PATH=/bin:/usr/bin:/usr/local/bin
  MAILDIR=$HOME/Maildir
  DEFAULT=$MAILDIR/
  LOGFILE=$MAILDIR/procmaillog
  LOCKFILE=$HOME/.lockmail
  SPAM=$HOME/.spam
  
  # at first, check 'X-Spam*' and filter
  :0fw
  *!^X-Spam.*
  |spamassassin
  
  # already filtered, then send to '.Spam' folder
  :0
  * ^X-Spam-Status: Yes
  $MAILDIR/.Spam/

こうしとけば、 IMAP で繋いだとき、スパム判定を食らったメールは自動的に「Spam」フォルダに入る。
判定漏れで INBOX に入っちゃったものはメーラ上で手動で Spam フォルダへ移した上で

  # SPAM 学習
  /usr/bin/sa-learn --spam /home/*/Maildir/.Spam/cur
  # 非 SPAM 学習
  /usr/bin/sa-learn --ham /home/*/Maildir/cur

とか定期的にやっとけば後は手間要らず。のはず。 cron に入れておけばさらに手間要らず。
もう少し突っ込んで Web 上を調べてると S25R とか greylisting とか tarpitting ( greet pause ) とか面白そうな技術も発見。
これって、とりあえず怪しい IP やドメインを正規表現ではじいて、そいつらからのメールはとりあえず応答を遅らせてみたり reject してみたりして、それでもちゃんとメールサーバの作法通り再送してきた奴だけは許可します、っていう仕組みなのね。
確かにこれでいけば「スパムうぜえ！」って思うことは少なくなるだろうけど、「応答を遅らせてみたり reject したり」はしたくないなぁ。そんなヘンな挙動が「当たり前」にはなってほしくない。
というわけでこれは今回は見送ったけど、そうは言っても「とにかくスパムを受け取りたくない」って人には効果抜群なわけで、なんだか有名になりそうなのが微妙...

下記を「$HOME/.Xmodmap」に記述して、
「modmap $HOME/.Xmodmap」を実行。

  !
  ! Swap Caps_Lock and Control_L
  !
  remove Lock = Caps_Lock
  remove Control = Control_L
  keysym Control_L = Caps_Lock
  keysym Caps_Lock = Control_L
  add Control = Control_L
  add Lock = Caps_Lock

おまけ：「半角/全角」キーを「無変換」キーに割り当てる

  !
  ! Toggle IME by 'Muhenkan'
  !
  keycode 131 = Zenkaku_Hankaku Kanji

「$HOME/.bashrc」に下記を設定：

  eval `dircolors $HOME/.dir_colors -b`
  alias ls='ls --color=auto'

さらに「$HOME/.dir_colors」を下記のように記述：

  ##
  ## configuration file for dircolors, set color parameters for ls(1)
  ##
  
  COLOR           all
  OPTIONS         -Cb
  EIGHTBIT        yes
  NORMAL          0
  FILE            0
  DIR             1;36
  LINK            1;32
  FIFO            34;43
  SOCK            31;43
  BLK             30;43
  CHR             44;37
  EXEC            1;31
  .tar            1
  .tgz            1

前提：./configure --prefix=/usr/local/apache --enable-shared=so にてインストールされているものとする

mod_rewriteの場合とはちょっと違う。「/usr/local/apache/bin/apxs -c *.c」がミソですね。

  # cd /usr/local/src/apache_1.3.34/src/modules/proxy
  # /usr/local/apache/bin/apxs -c *.c
  # /usr/local/apache/bin/apxs -i mod_proxy.so

ここまでやったら、httpd.confに以下を記述：

  LoadModule proxy_module       libexec/mod_proxy.so

前提：./configure --prefix=/usr/local/apache --enable-shared=so にてインストールされているものとする

以前書いた方法はちょっと泥臭い＆db1を使用しているので、以下のようにした方が良さそう。

  # cd /usr/local/src/apache_1.3.34/src/modules/standard
  # /usr/local/apache/bin/apxs -c -I/usr/include/gdbm mod_rewrite.c
  # /usr/local/apache/bin/apxs -i mod_rewrite.so

ここまでやったら、httpd.confに以下を記述：

  LoadFile /usr/lib/libgdbm.so
  LoadModule rewrite_module     libexec/mod_rewrite.so

これでばっちりOKのはず。

※libgdbm.soの場所はディストリビューションによっては違うことがあるので注意。

のために、先週末に一念発起して、自宅サーバにapache2+subversionを入れてみた。
自宅サーバはすべてRPMでパッケージ管理していたのだが、目的のために手段を選んでいられるほど自由な時間がないし、RPMで入ってるapache1.3の存在をどうするか迷ったので、subversion周りだけソースからインストールすることにした。
ウチのサーバは前世紀の産物なので、apache2+mod_ssl+csr発行+subversion+BASIC認証でのcommit権限規制をすべてやり終えるまでに約半日かかってしまった…
相方は相手してもらえないで拗ねてしまうし、得るものが大きいとその分リスクも大きいｗ
でまぁ、やり終えた後、TortoiseSVNを使ってWinXPからソースをcommitし、Wikiを更新。
とりあえずこれで、作業場所を問わずいつでも最新のソースで開発の続きができるようになった。
残るはDB周りのクラスと、クッキー、セッション系クラスかな。
と言っても、「とりあえず動くものを作っちゃえ」な性格なので、あとでまた気に食わなくなるんだろうな…
Wikiにも書いてあるけど「Since 2003/02/17」なわけで…いつ完成するんだろ。
なんかライフワーク化してるんで、いつまでたっても完成しなかったりして。

前提：./configure --prefix=/usr/local/apache --enable-shared=max にてインストールされているものとする

  /usr/local/apache/bin/apxs の $CFG_CFLAGS に -I/usr/include/db1 を追加
  (mod_rewriteがndbmを必要とするため)
  # vi /usr/local/apache/bin/apxs
  
  # cd /usr/local/src/apache_1.3.33
  
  # /usr/local/apache/bin/apxs -c src/modules/standard/mod_rewrite.c
  
  # gcc -shared -ldb -L/usr/lib -o src/modules/standard/mod_rewrite.so mod_rewrite.o /usr/lib/libndbm.so
  
  出来上がった mod_rewrite.so が libndbm.so を参照することを確認
  # nm src/modules/standard/mod_rewrite.so | grep dbm_
  次のように「@@GLIBC_2.0」があればOK
           U dbm_close@@GLIBC_2.0
           U dbm_fetch@@GLIBC_2.0
           U dbm_open@@GLIBC_2.0
  
  # /usr/local/apache/bin/apxs -i src/modules/standard/mod_rewrite.so

※libndbm.soの場所はディストリビューションによっては違うことがあるので注意。

mikeneko.ne.jp閉鎖のお知らせ

mikeneko.ne.jp ドメイン管理人の小塚 敦さんが死去されたため、
2004年9月24日(金)をもって本ドメインは閉鎖いたしました。

今日の仕事も終わったので、そろそろ帰ろうかな～と思いblogを見て回っているとたろさんとこで発見…。
僕もapacheをよく触るんで、必要な折によく確認のために参考にさせていただいてました。
このような良質サイトの発信者が亡くなられたのはとても残念です。

これまで参考にさせていただきありがとうございました。
小塚氏のご冥福をお祈り申し上げます。