サーバ構築の最近のブログ記事

久々の更新。

最近、WordPressのindexを自分のドメインのトップページに設定している人が増えてきている模様?

そういった場合、管理者は、WordPressの構成ファイルをドキュメントルート直下に展開するか、ドキュメントルート直下の.htaccess処理で、WordPressの本体ディレクトリ内のindex.phpにリダイレクトさせる。
もしくは、apacheの設定自体を変えて、ワードプレスの本体ディレクトリ自体をドキュメントルートにしちゃう、
主流はこの3つくらいだろうか。


先日MilkyStepの初期設定代行を行おうと思い、VPSのコンパネにアクセスしようと思ったら、いきなりワードプレスのスキンで404エラーが発生。

ドキュメントルート直下の.htaccessをのぞいてみると、どうやらお客さんの方で追記したと思われる、下記のようなRewriteRuleを発見。

# BEGIN WordPress

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>

# END WordPress


ふうむ。
どうやら最近はこういうのが流行っているのだろうか?

上記の設定だと、下位のファイルを指定せずトップページにアクセスすると、同列に置いてある「index,php」の制御により、ワードプレスのトップが表示される。
下位(ワードプレスディレクトリ内)の実在するファイルにアクセスすれば見れるが、実在しなければ「ありませんよ!」というメッセージ(多分ワードプレスの制御)が出る模様。

基本的に、RewriteRuleに書かれた以外のコンテンツ(またはそのエイリアス)が存在しない場合、
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
により、その下の
RewriteRule . /index.php [L]
が実行される。

ただし、ここで、
RewriteRule . /index.php [L]
となっている。
左辺を見ると、「.」となっているので、「.」(任意の一文字)が合致する名前のコンテンツは、基本的に「すべて」ということになる。

したがって、
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
は、基本的にははすべて「偽」となるため、
RewriteRule . /index.php [L]
の処理が実行されないことになる。
(それと、右辺は「/index.php」ではなく「index.php」ではなかろうか?)

とまあ、こう考えれば、WordPressディレクトリの外のコンテンツにアクセスするにも問題なさそうなのだが、なぜか(ワードプレス内のコンテンツが無いという)404となる。

多分、それ以前の大元のapacheのルールで、インデックスの指定のルールとかがごっちゃになって、こういう結果的にこうなっている思われる。

根本的な原因を探すのも面倒だし、もともと書いてあったRewriteRuleを消したりなんかすると、さらに被害が増えそうだ。

したがって、なるべく既存のコンテンツにあたりさわりなく行う対策としては、アクセスしたい同階層のディレクトリ名が指定された場合は、上記のRewriteRuleが適用されないようにするのが得策と考えた。

# BEGIN WordPress

RewriteEngine On
RewriteBase /

# Add -------
RewriteRule ^ControlPanel/* - [L]
RewriteRule ^mysqladmin/* - [L]
RewriteRule ^ms/* - [L]
# ------- Add

RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]


# END WordPress

これで、ControlPanel、mysqladmin、ms という名前のディレクトリには、
http://domain.com/ControlPanel/......
http://domain.com/mysqladmin/......
http://domain.com/ms/......
というURLでそのコンテンツにアクセスできる。

以上。
事業所の移転に伴って、フレッツ光の契約タイプを変更しなくてはいけなかったため、必然的に貸与されるルータも、PR200NEからPR400NE(一応最新版らしい)に変更することになった。

ついでにプロバイダもbiglobeをやめてインターリンクの固定IP付のもっと安いサービスに乗り換えた。

しかし、ルータが変わってから、LAN内ホストの名前解決(正引き)ができなくなってしまった。

うちの場合はLAN内のPCからLAN内のサーバにアクセスするとき、内部DNSを構築しているので、ルータの静的NATとサーバ側のファイアウォールを許可すれば、LAN内からでも「ホスト名+ドメイン名」でアクセスできるはず。

というか、ルータが変わる前は普通にできていた。

もちろん、「http://192.168.*.*/:80」とかやれば、当たり前だが普通にWEBサーバにつないでくれる。


ルータのソフトのファームウェアバージョンも前と変わってないし、設定も前とすべて同じにしてあるのに、なぜかLAN内のホストへ正引きできない。

仕方が無いので、現在はルータの設定で、DNSの問合せ先をすべて192.168.1.4(LAN内のDNSサーバ)に指定している。
こうするとちゃんと正引きしてくれるが、WAN側のホストにアクセスするときも、いちいち内部のDNSサーバに問合せに行くので、名前解決の時間が3秒くらいかかってイライラする。

確か、前は、ルータのDNS問合せ先を「自動的に取得する」にしておけば、WAN側・LAN側を勝手に判別してWAN側だったらプロバイダのDNSに問合せに行ってくれたと思ったのだが・・・

ルータ設定画面のメニューで、今まで使ったことがなかった「ローカルドメイン設定」というメニューがあるが、これにローカルドメインを登録しようとしても、バグってるぽくて有効にならない。

他に移転に伴って変わったことと言えば、プロバイダが変わったことだが、この現象はインターリンクに切り替える前からおこっていた現象なので、やはり怪しいのはルータということになる。


以下、私がNTT東日本に問い合わせたメールの内容。

この後、一応連絡が来て、結局他の部署のなんちゃらというところに問い合わせてみてください、といった無責任な対応だったので、めんどくさくてそのままにしている。

もし、同じような現象にある人は、下記の文面をそのままコピペして問合せ用に使っちゃってください。

もしくは、「お前の考え方が間違っている。ルータのせいではない。」という見識をお持ちの方は、ぜひぜひ解決策を教えていただけると嬉しいです。

----------------------------------------------------------------------------------------------
先日引越しを行った際に、弊社からの案内でルータをPR-200NEからPR-400NE(無線LANカード付き)に変更しました。

当方ではLAN内にサーバを構築しており、インターリンクというISPの固定IPアドレスによりWEBも公開しておりますが、LAN内のクライアントPCからLAN内のサーバにホスト名でアクセスする際に支障が出ております。

この場合、何も対策していない場合は、通常はLAN内のホストにホスト名+ドメインでアクセスすることはできませんが、その回避策として内部DNSを設置しており、引っ越し前(PR-200NE)までは正常に問合せ、閲覧ができていました。

ルータのソフトウェア(最新ファームウェアバージョンは1.11)の設定も、基本的に引っ越し前とすべて同じにしています。
静的NATの設定なども全て同じで、外部から当サーバへの各種アクセスは問題ありません。

「詳細設定」→「DNS設定」の「LAN側DNSサーバアドレス」に、当方の内部DNSアドレス(192.168.1.4)を指定しており、この設定が、LAN内ホストの名前解決をする際に使用されるDNSアドレスと認識しております。
この認識が間違っていれば申し訳ありません。

この認識から行くと、通常使用する接続設定(「基本設定」→「接続先設定→「現在利用中の接続名」」)において、「DNSサーバアドレス」で「サーバから割り当てられたアドレス」を「使用する」にしておいても、LAN内ホストにホスト名で接続するときは、上述した内部DNS(192.168.1.4)に問合せに行かなくてはならないはずなのに、そうならずに、「このページは表示できません」となります。
逆に、上記の「サーバから割り当てられたアドレス」を使用せず、問合せるDNSを強制的に内部のDNS(192.168.1.4)に指定すれば、当たり前ですがアクセスできます。
つまり、内部DNSの正引きは正しく動作していることになり、ルータのDNS問合せ先の判別がうまくいっていないのではないか、ということです。

以上よろしくお願いたします。

----------------------------------------------------------------------------------------------


今朝起きると、やけに仕事部屋が静かだ。

ふと見るとサーバがシーーーンとしている。というか電源が落ちている。


いままで定期的にメンテナンスをしてきたとはお世辞にも言えないので、いつかはこういう日が来るとは思っていたが、さすがにちょっとあせる。

とりあえず、再度立ちあげてみる。
ブートはOK。ログイン画面もOK。ログインも可能。

しかし3分後・・・
「ピュシューーーーン!」という音とともにサーバ停止。

今度はもう一度電源入れて、topで監視してみる。
特に問題なさそうな動きなのに、また「ピュシューーーーン!」と停止。

リソースが落ち着いているのに止まるってことは、一部のデーモンが暴走したり、スクリプトが暴走したりという原因ではなさそうだ。
それに全然熱も持ってない。素手で躯体を触ってもまったく熱くない。
サーマルシャットダウンではないのか???
そして、CPUがほとんど使われてないのに、ファンが常に全開で回りっぱなしだ。うるせー。

HDDだったらいやだな・・・いつバックアップ取ってたっけ?やっぱRaid組んどきゃよかったか・・・なんて思いながら仕方なくサーバを開けて中を確認。

一番怪しそうなCPUクーラーを外してみると、グリスのカスがバラバラ落ちてきた・・・あらら・・・
そして残ったグリスも完全に乾いててパキパキ状態。
そういえばこのサーバのクーラー外すの初めてだったかも・・・

しかもクーラーの足の4本のうち2本の樹脂部分が割れてる状態だし回転も悪い。
(ぐらついてはいないが)

ダメだこりゃ。交換だなと思って、クーラーだけを外して近所のパーツ屋に直行。

「急に電源が落ちるからCPUクーラーを取り換えたい」といったら、店員はきっと電源ユニットの故障だと言い張る。
しかし私は「いやいや、クーラーとCPUの密接状態が悪いから熱伝導が弱っているんだよ多分」
とかなんとか口論になりつつ、なかば強引に新品のクーラー(Core2Duoのサポートタイプ)を購入。

今回購入したのその店で一番安かったこれ。
⇒ Xdream p775

うちのサーバはDELL製でマザボと接続するコネクタのピンが4ピン(この製品は3ピン)なんだが、多分片側3ピンしか使ってないから挿さればいけるだろうってことで・・・

帰ってきて商品を開けた時に、そういえばシリコングリスも買わなきゃならなかったんじゃ?なんて心配になるが、ヒートシンク部分にグリスがあらかじめ塗ってあったので一安心。

この製品には、クーラーの足の下に置く架台みたいなパーツが付属してるが、うちのサーバはコンデンサが邪魔で付けられなかったため、架台なしで直接ねじで取り付けた。
(取り付けの際、グリスが服についてしまったのは言うまでもない)


そして改めて、電源を立ち上げる。

30分たっても落ちない。
どうやら成功のようだ。よかったよかった。

障害に気付いてから復旧まで約3時間。
情報科出身でも機械科出身でもない私にしてはまずまずでしょう。


参考資料:
http://pasokoma.jp/bbs8/lg245187
http://www.dosv.jp/feature/0606/14.htm
前回に引き続きphpBB(phpBB2)ネタ。

当然ながら日本語でphpBBを運用する場合は、普通、MySQLのマルチバイト文字セットはEUCかUTF8になっている。

しかし、デフォルトのまだと、システムから送られてくるメールの、DBのマルチバイトを参照した部分の文字列が化ける。

以下対策

・language/language_japanese/email の中のファイル全てを、MySQLの文字コードに合わせてエンコードを修正する。
(SJISなどでアップされていたらEUCかUTF8で保存して上書き)

・各ファイルの「Charset: iso-2022-jp」と書かれているところを、全て
「Charset: EUC-JP」 か、
「Charset: UTF8」
に書き換える。

以上
久々の投稿。しかもネタが今更感のあるこれ。
でも今までphpBBを使ったことが無かったので、まあまあ勉強になった。

伝統的なスパム対策は下記らしい。
http://support.hiikun.net/bbs/topic-299.html

ちなみにmodの使い方などはこちら。
http://all.netgamers.jp/adcat5.html

でも、今時のphpBBスパムシステムは、画像認証やMDハッシュを突破したりしてかなり賢い。
上記の対策をしても相変わらず1日100件くらいは登録スパムがやってくる。

まあ、ユーザ登録されるだけならまだいいが、トピックを荒らされるのだけは困るので、
以下の対策を実施。
http://garnote.com/2010/01/spam.html

これはかなり有効だったようで、スパム投稿がピタリと止まった。
備忘録です。

あるqmailのメールサーバに、標準時補正パッチ(qmail-date-localtime.patch)を当てるのを忘れていてたので、パッチを当てて再インストールしたところ、このエラーが発生。
(qmailのパッチ宛て、インストール方法などの解説はこちら http://www.igreks.jp/dev/2011/01/qmailvpopmailqmailadmin.html

・内部⇒内部はOK
・内部⇒外部もOK
・外部⇒内部のみNGでメールが送れない。

つまり外部ホストのアドレスからのみ、このqmailをインストールしたサーバのアドレスにメールが送れない。

メーラーで送信する際の、よくあるリレーエラーではなく、一旦送信した後、mailer-daemonさんからエラーが返ってきて、

--------------------------------------------------------------------------------------

This is the mail system at host sv313.xserver.jp.

I'm sorry to have to inform you that your message could not
be delivered to one or more recipients. It's attached below.

For further assistance, please send mail to

If you do so, please include this problem report. You can
delete your own text from the attached returned message.

The mail system

<*****@hoge.com>: host mail.hoge.com[xxx.xxx.xxx.xxx] said: 553
sorry, that domain isn't in my list of allowed rcpthosts (#5.7.1) (in reply
to RCPT TO command)

--------------------------------------------------------------------------------------

と、怒られる。

最初、送信する側の外部ホスト(上記で行くとエックスサーバ)がおかしいのかと思いきや、他のYahooメールやGmailからでもダメ。

確認したところ、tcp.smtpファイルも、DNS設定も問題なし。


というわけで、メールに書いてある、rcpthostsを見てみたら、以下のようになっていた。

-------------------------------------------------------------------------------------
***.hoge.com
localhost
-------------------------------------------------------------------------------------
※「***」の部分は、このサーバのホスト名


あ、そうだ。
以前、最初にqmailインストールしたときに、すでにqmailが稼働しているサーバの設定を真似してたんだった。

真似したサーバのrcpthostsを見てみると、上記の他に、「aaa.jp」(ホスト名無しのドメインのみ)が追記されている。

なるほど、上記だけでは、「user@***.hoge.com」ならOKだが、「user@hoge.com」ではNGになるわけだ。
再インストールしたから、これが初期化されちゃったのね。

というわけで、rcpthostsを訂正。

-------------------------------------------------------------------------------------
# vi /var/qmail/control/rcpthosts

(以下を追記。念のため3つほど)

hoge.com
.hoge.com
mail.hoge.com

# :wq (保存して終了)
-------------------------------------------------------------------------------------

webminからだったら、左のメニューから、

「サーバ」
 ↓
「Qmail Mail Server」
 ↓
「Accepted Domains(rcpthosts)」
 ↓
上記のドメインを追記し保存


最後にqmailを再起動して終了。


無事、送信できるようになりました。
よかったよかった。
centOSですでに稼働中のqmailにdomainkeysを適用させる方法まとめ(送信側)

# cd /usr/local/src

■関連ファイルのダウンロード
# wget http://sourceforge.net/projects/domainkeys/files/libdomainkeys/0.69/libdomainkeys-0.69.tar.gz/download
# wget http://www.qmail.org/qmail-1.03-dk-0.54.patch
# wget http://jeremy.kister.net/code/qmail-dk-0.54-auth.patch

■tarファイル展開
# tar -zxvf libdomainkeys-0.69.tar.gz
# cd libdomainkeys-0.69

■エラー対策
# vi dns.lib
下記を記述し保存
----------------------------
-lresolv
----------------------------
# make
# cd ../

■次に、qmail-1.03の中で、qmail-dkファイルを作るのだが、ここで、以前qmail本体をインストールしたときに使った「qmail-1.03」ディレクトリを使うと上手くいかない場合がある。
既存の「qmail-1.03」ディレクトリは削除し、新しいqmail-1.03をダウンロードするか、以前使ったtarボールがあればそれを新たに解凍して使う。

# rm -rf qmail-1.03
# tar -xvzf qmail-1.03.tar.gz

■ここで、qmail.cに以下の記述があるか見ておく。
# vi qmail-1.03/qmail.c
--------------------------------------------------------------------------------
static void setup_qqargs()
{
if(!binqqargs[0])
binqqargs[0] = env_get("QMAILQUEUE");
if(!binqqargs[0])
binqqargs[0] = "bin/qmail-queue";
}
--------------------------------------------------------------------------------
■これが無いと、環境変数「QMAILQUEUE」が使えないので、専用のパッチををダウンロードしてあてておく。ある場合はそのままでOK。
# wget http://qmail.jms1.net/patches/qmailqueue.patch
# patch -d qmail-1.03 < qmailqueue.patch


■その他必要なパッチあて
echo 'gcc -02 -include /usr/include/errno.h' > qmail-1.03/conf-cc
# patch -d qmail-1.03 < qmail-1.03-dk-0.54.patch
# patch -d qmail-1.03 < qmail-dk-0.54-auth.patch

■次にqmail-dkを生成するが、libdomainkeysのヘッダファイルが参照できない場合があるようなので、専用のディレクトリ空間を作成し、そこで行うようにする。

# mkdir test
# cp -Rpf qmail-1.03 test
# cp -Rpf libdomainkeys-0.69/* test/
# cd test/qmail-1.03
# make qmail-dk

■上記が成功すれば、test/qmail-1.03 の中に「qmail-dk」ファイルが生成される。

※qmailqueueのパッチを当てた場合はqmailを停止し、再度、
# make clean
# make setup check
しておく。

■キュー処理ディレクトリにqmail-dkコピー&所有者変更
# cp qmail-dk /var/qmail/bin/
# cp qmail-dk.8 /var/qmail/man/man8/
# chown qmailq /var/qmail/bin/qmail-dk
# chmod 4711 /var/qmail/bin/qmail-dk


■署名用の鍵ファイル作成
# mkdir -p /etc/domainkeys
# mkdir -p /etc/domainkeys/example.com
# cd /etc/domainkeys/example.com
# openssl genrsa -out rsa.private 768
# openssl rsa -in rsa.private -out rsa.public -pubout -outform PEM
# mv rsa.private default
# chown -Rf qmailq /etc/domainkeys
# chmod 0600 default
# grep -v ^- rsa.public | perl -e 'while(<>){chop;$l.=$_;}print "t=y; p=$l;\n";'
↑で表示された、文字列をコピーしておく

■vpopmailのsmtpルールを編集
# cd /home/vpopmail/etc
# vi tcp.smtp
以下の例ように修正
-------------------------------------------------------------------------------------------------------------
192.168.:allow,RELAYCLIENT="",DKSIGN="/etc/domainkeys/example.com/default",QMAILQUEUE="bin/qmail-dk"

:allow,DKVERIFY="DEGIJKfh",QMAILQUEUE="bin/qmail-dk"
-------------------------------------------------------------------------------------------------------------
■CDB化
# tcprules tcp.smtp.cdb tcp.smtp.tmp < tcp.smtp


■POPbeforeSMTPなどを利用し、ローカルのメーラからも配信している場合は、/home/vpopmail/etc/open-smtpなどで、qmail-dkを指定できるよう変更しておく。

# cd /usr/local/src/vpopmail-5.4.32 (←以前に本体インストール時に使った残り。なければダウンロードし解凍しておく)
# vi vpopmail.c
下記の個所を修正。
-------------------------------------------------------------------------------------------------------------

fprintf( fs_tmp_file, "%s:allow,RELAYCLIENT=\"\",RBLSMTPD=\"\"t%d\n",

fprintf( fs_tmp_file, "%s:allow,RELAYCLIENT=\"\",RBLSMTPD=\"\",DKSIGN=\"/etc/domainkeys/example.com/default\",QMAILQUEUE=\"bin/qmail-dk\"\t%d\n",

-------------------------------------------------------------------------------------------------------------
qmailを停止し
# make clean、
# make
# make install


■DNSのレコードに以下を追加
-------------------------------------------------------------------------------------------------------------
_domainkey.example.com. IN TXT "k=rsa; t=y; o=~;"
default._domainkey.example.com. IN TXT "コピーしておいた文字列"
-------------------------------------------------------------------------------------------------------------
※コピーしておいた文字列⇒「t=y; p=*********;」

■DNSサーバ(BIND)の再起動

■qmailの(再)起動
# /etc/init.d/qmail stop
# /etc/init.d/qmail start

■gmailやyahooメールにメールを送って、受信したメールのヘッダに、
--------------------------------------------------------------------------------------------
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
s=default; d=example.com;
b=公開鍵;
--------------------------------------------------------------------------------------------
などの記述があればOK。


参考資料:
http://jeremy.kister.net/howto/dk.html
http://blog.cles.jp/item/1778
http://www.4web8.com/644.html
http://blog.guideme.jp/archives/106
http://www.weloveya.com/oshigoto/qMail2.html


■余談

同一LAN内、同一ドメインで、負荷分散のため、複数のSMTPサーバから配信する場合は、そのSMTPサーバの分だけDNSにレコードを登録するが必要ある(はず)。

どのSMTPサーバかを判別するために、各レコード、セレクタ名(上記でいくと「default」の部分)を変えてやればいい(はず)。

2台目のSMTPの/var/domainkeys/example.com/内に秘密鍵を作ったら(上記の例でいくと「rsa.private」)、そのファイル名を「default2」とかにしてやって、
その他各ファイルDKSIGN指定の部分を
----------------------------------------------------------------------
DKSIGN="/etc/domainkeys/example.com/default2
----------------------------------------------------------------------
のようにしてやる(予定)。

そしてDNSのレコードに書くとき、
----------------------------------------------------------------------
default2._domainkey.example.com. IN TXT "2台目のSMTPサーバの公開鍵"
----------------------------------------------------------------------
と追加してやればよい(はず)。
  ↓
未検証・・・
何も難しいことはなかった。

DNSのレコードに下記のようにTXTレコードを追加し、BINDを再起動するだけ。

■MXレコードに登録されているIPのみ一括指定する場合
hoge.jp. IN TXT "v=spf1 +mx ~all"

■IPを指定する場合
hoge.jp. IN TXT "v=spf1 ip4:対象のSMTPサーバのIPアドレス ~all"

※IPアドレスの部分は「111.222.333.444/29」のようにネットマスク指定でもOK

※IPアドレスを複数登録したい場合は、
hoge.jp. IN TXT "v=spf1 ip4:対象のSMTPサーバのIPアドレス1 ip4:対象のSMTPサーバのIPアドレス2 ~all"
のように半角スペースで区切って記述する。


ここに指定したSMTPサーバから、試しにSPFに対応しているgmailにテスト送信すると、下記のようなメールヘッダが追加されている。

--------------------------------------------------------------------------------------
Received-SPF: pass (google.com: domain of hoge@hoge.jp designates 111.222.333.444 as permitted sender) client-ip=111.222.333.444;
--------------------------------------------------------------------------------------
システム開発上、ユーザがブラウザからメールマガジンを作成した時に、同時にエラーメール処理用のアドレスも作成されるようにする、逆にメルマガを削除したらそのアドレスも削除される必要があったためメモ。

今回のMTAはqmailを使うとのことで、アカウントの管理は必然的にvpopmailとなる。

しかし、qmailadminを使わないで新規アカウント作成(vadduser)・削除(vdeluser)を行うためには、基本的にrootでの操作となる。

単純にスクリプト内で

system("/home/vpopmail/bin/vadduser hoge@hoge.jp hogepass");

とやっただけでは、もちろんうまくいくはずがない。

というわけで、Cと連携して上手いことやってくれるモジュール様がないかと、CPANを探してみたらありました。
その名も「vpopmail.pm」。

呼び出す関数名もまさにvpopmailコマンドとほぼ同じ。

しかし、最終リリースは2001年・・・やばいんじゃないの?

かろうじてCPAN.pmをからインストールできたものの、説明も短すぎて、当然
use vpopmail;
vadduser(引数いろいろ);
とかやれば新規にアカウントを作ってくれると思いきや全然ダメ。

vpopmailのバージョンを見てきてくれる関数だけはなぜか動いた(笑)
まあ、関数名も最近のvpopmailのコマンドといまいち合ってないし。

というわけでさんざん悩んだ結果、sudoを使うことで決定。

以下手順。

1.新規バーチャルアカウントを作成する簡単なスクリプト(vadduser.cgi)を作成しCGIの動くディレクトリに置く。

vadduser.cgi
-----------------------------------------------------------------------------------------
#!/usr/bin/perl

use strict;

# コマンド発行
`sudo -u root /home/vpopmail/bin/vadduser hoge@hoge.jp hogepass`;
exit;
1
-----------------------------------------------------------------------------------------

2.sudoの設定ファイルに許可コマンドを追記

# visudo

(以下を追記)
apache ALL=(root) NOPASSWD: /home/vpopmail/bin/vadduser,/home/vpopmail/bin/vdeluser

同時に、以下の行をコメント化

Defaults requiretty
   ↓
#Defaults requiretty

※これをコメント化しないと、最近のLinuxでは、
sudo: apache : sorry, you must have a tty to run sudo ; TTY=unknown ;......
と怒られる。

このエラーは、/var/log/secure を見ればわかる。

保存して終了
:wq


3.vadduser.cgiをブラウザから実行してみる。

4.確認

popアカウント一覧に、「hoge」が追加されているのを確認

同時に、/home/vpopmail/domains/hoge@hoge.jp 内に、ディレクトリ「hoge」が作成されているのでOK!!



ああ疲れた今回も。


実務的には、このvadduser.cgiをAPIとしてドキュメントルート外に置いて、第三者からは直接アクセスされないようにし、他のCGIからシステムコールで呼んだりした方がセキュアかなと。


参考URL:
http://hibari.2ch.net/test/read.cgi/php/1024741312/l50
http://d.hatena.ne.jp/kakurasan/20100512/p1
http://old.ikoinoba.net/index.php?UID=1188143501
http://search.cpan.org/~sscanlon/vpopmail-0.08/
空メール登録のシステム構築自体は以下の通り。
http://www.igreks.jp/dev/2010/06/postfixperl.html

上記の場合は、アイリアス設定ファイルに直接転送先を書いているが、転送用ファイル「.qmail」や「.forward」にパイプで転送先を書いて、ユーザディレクトリ直下に配置してももちろん構わない。

ここで注意したいのが、「.qmail」にパイプ処理を書くとき、空行を作ってはならないということだ。

「.qmail」ファイルは本来の用途で使うならば、転送したいメールアドレスが一行に1つずつ書いてある。
qmailはこれを上から順に処理していく。

つまり、空行が合った場合でも、「(空文字列)@ドメイン」と認識してしまう。

したがって、そんなメールボックスはありませんよ!と、Mailer-Daemonから送信元にエラーが返ってきてしまう。

最後の行を改行して終わらないと気持ちが悪いのは同感だが、この場合はやってはいけない。


.qmail

○良い例
---------------------------------------------------------
| プログラムへのパス (コマンドライン引数)(改行なし)
---------------------------------------------------------

×悪い例
---------------------------------------------------------
| プログラムへのパス (コマンドライン引数)(改行)
(空行)
---------------------------------------------------------


あと、qmailの場合も、postfix同様、パイプで渡されたメールキューは勝手に削除されてるっぽい。ログに「remove」とかいう記載はないが。

渡したプログラムで「exit;」とかしてないと、もしかしたら続いちゃうのかも。