お仕事: 2009年9月アーカイブ

うちで運営している地域 SNS のお知らせメール（デイリーニュース）が今朝は配信されてなかった。

サーバに入って maillog を見てみると、

Sep 30 08:01:32 snsserv postfix/qmgr[58514]: 94EE75096C: from=<sns@snsserv.exsample.com>, size=4796, nrcpt=1 (queue active)
Sep 30 08:01:32 snsserv postfix/qmgr[58514]: 94EE75096C: to=<hogehoge@xxx.xxxx.ne.jp>, relay=none, delay=7268, status=deferred (delivery temporarily suspended: connect to mail2.exsample.com[202.XXX.XXX.XXX]: Connection refused)

なんてログが山のように・・・

ああ・・・そうだ・・・以前、この地域 SNS サーバを非固定 IP で運用していたとき、怪しいサーバと判断してメールを受け取ってくれないサーバがあったので、固定 IP の mail2.exsample.com を経由（RELAY）するよう設定してたんだった。

で、実は、昨夜、mail2.exsample.com は SMTP を止めたのよ。
以前、ここでも書いたように、このサーバを預けていたデータセンターがハウジングのサービスを止められるもんで。今日、実際にサーバを撤去したんでね。前夜に SMTP サービス自体は止めてたって話。

ということで、Postfix の設定を変更を。

/usr/local/etc/postfix/main.cf の中に、

relayhost = mail2.exsample.com

という記述があるのでコメントにして、

# /usr/local/sbin/postfix reload

で設定ファイルを再読込させる。これでＯＫ！

後は、queue に溜まっているメールを、

# postqueue -f

で、強制排出。

ま、こんなことせずにほっておいても、そのうち配送されるんだけどねえ。

いやあ、しかし、Postfix を使っているのはこの SNS サーバだけなので、毎度コマンドを思い出すのに時間がかかるよ。（メモしとけって話だけど(^^;）

ま、そのうちこの地域 SNS もサーバを移すので、その時には Postfix ではなく、qmail の利用に変更しようてえ。

これも移行したサーバでの話。

tDiary を動かしているサーバを別の場所に動かしたんだけど、そしたら

env: ruby: No such file or directory

というエラーが出て、tDiary が動かなくなってしまった。
どうも、Ruby のパスが取れてない様子。

tDiary のスクリプトは、シェル宣言で直接 /usr/local/bin/ruby という Ruby のパスを指定せず、

#!/usr/bin/env ruby

という具合に、env コマンドで ruby のパスを指定している。（ruby のインストールディレクトリがどこになってもいいようにだろう）

で、/usr/local/bin にある ruby が No such file or directory になるということは、プログラムファイルを探す経路情報である環境変数 PATH に、/usr/local/bin が含まれていないということだ。

実際、CGI で取得出来る環境変数を調べてみると、PATH は、

/sbin:/bin:/usr/sbin:/usr/bin

となっている。/usr/local/bin は確かに含まれていない。

これに関しては、Apache の起動スクリプトで、apachectl を実行する前に、環境変数 PATH に /usr/local/bin を足し込んでやればいい。
こんな感じ。

#!/bin/sh

export PATH=$PATH:/usr/local/bin
/usr/local/apache2/bin/apachectl startssl

しかし、マシンを再起動するまでは、問題なく動いていたのに何故？

同じ OS（FreeBSD 5.X-R）で、マイナーバージョン違いの Apache を動かしているうちのサーバで調べてみると、Apache の環境変数 PATH に、/usr/local/bin は含まれている。

/sbin:/bin:/usr/sbin:/usr/bin:/usr/games:/usr/local/sbin:/usr/local/bin:/usr/X11R6/bin:/root/bin

あれれ、これ、.cshrc 内で指定しているパスじゃん。

set path = (/sbin /bin /usr/sbin /usr/bin /usr/games /usr/local/sbin /usr/local/bin /usr/X11R6/bin $HOME/bin)

そうか・・・
以前、tDiary をインストールした時、こういう問題が発生せずにすんなり動いたのは、自動起動された Apache ではなく、ユーザが apachectl コマンドをシェル上から実行した Apache だったからかぁ。
謎が解けた。

つまり、/usr/local/etc/rc.d 以下の自動起動スクリプトで起動された時は、PATH には /etc/rc で指定されている

PATH=/sbin:/bin:/usr/sbin:/usr/bin

この値がセットされるのだろう。
で、ユーザが起動した時は、そのシェル上の環境変数 PATH の値がセットされるというわけだろう。

このサーバ、既に４年近くノンストップで動いてて、再起動したことなかったもんな。
それまでに、Apache は何度か STOP/START してるんで、/usr/local/bin へのパスも通っており、tDiary でもエラーが出なかったんだな。

つーことは、/etc/rc の PATH に /usr/local/bin を追加しておけばいいということか。
システムファイルを編集するのは少々気持ち悪いが、/usr/local/bin は追加しても全然問題無い気はするがな。
ま、取りあえず tDiary 以外で問題は発生していないので、暇が出来たら実験してみるということでよかろうてえ。

ちなみに、FreeBSD だと /etc/rc だが、Linux なら /etc/init.d/functions の中でディフォルトの PATH は設定されているようだ。

ああ、原因が分かってすっきりした。寝よ。

新しいサーバにうちのメールサーバを移したら、なんと特定のアカウントだけメールが届かない現象が・・・

どういう基準で「届く／届かない」状況になっているのかよくわからなかったのだが、やっと先ほど判明した。

ちなみに、qmail-1.03 + ucspi-tcp-0.88 + vpopmail-5.4.28 という環境である。

で、どうも、VirtualDomain のユーザディレクトリの下に置いた .qmail ファイルに、配送先として Maildir を書いた場合に、

delivery 3: deferral: client_connect:_warning:_config_begin_failed/Aack,_child_crashed._(#4.3.0)/

というエラーが出て（warning って出てるけど、実際にメールが配送されないんで、これはエラーだ）、メールの配送に失敗してしまうのだ。（Maildir/new にも入っていないし、その下に書いていた転送先にも転送されていない）

で、.qmail を置かなければ問題なく Maildir/new にメールデータは書き込まれる。
.qmail を置いた場合も、転送先が書いてあるだけなら（Maildir が書かれていなければ）、問題なくその転送先に転送される。
つまり、他のアドレスに転送するだけなら、そのアドレスだけを書いた .qmail を置けば問題なく動作するし、転送をしないのなら .qmail を置く必要もないので、これまた何の問題もない。
問題になるのは、他のアドレスに転送しつつ、Maildir にもデータを置きたいという場合である。

ちなみに、Maildir の指定方法は、

./Maildir/
/home/vpopmail/domains/exsample.com/hogehoge/Maildir/

のように、相対パスでも絶対パスでも、どちらでも駄目。

一応、解決策も見つけてて、ドメインのディレクトリ直下に、

.qmail-hogehoge

というファイルを作って、そこに、

/home/vpopmail/domains/exsample.com/hogehoge/Maildir/

と絶対パスで書いてやれば正常に配送されることが確認出来た。
何か気持ち悪いけど、取りあえずはこれで行くしかないなあ。何せ、古いサーバは 9月いっぱいしか使えないので。

ググってみても、同じ現象に遭ってる人はいないなあ。
この話が一番近いくらい？多分。
　↓
http://search.luky.org/linux-users.9/msg04669.html

取りあえず、ユーザディレクトリの下に置いてある .qmail をチェックして、Maildir が指定されているものはドメインディレクトリ直下に .qmail-XXXX を作成していこうてえ。

めんどくさ・・・

PHP で作られている某社の Web サイトを、うちの古いサーバから新しいサーバに移動したのだが、そしたらデータの登録画面で

Warning: mktime() expects parameter 1 to be long, string given in ～

なんつう Warning が発生し始めた。

ま、Warning なので、そのまま処理は進んでいるようなのだが、どうもデータ的にはボロボロになっているようで、本来表示されるべき場所にデータが表示されない。でも、同じデータをもう一度登録しようとすると「既に登録されています」のエラーになる。
日付が正しく入ってないので、検索条件からこぼれてるんだろうなあ。
（他人が作ったソースを追っかけるのは面倒くさかったので、DB の中身は確認してないけど。）

日頃 PHP を追っかけてないのでよくわからないのだが、ググってみると、どうも mktime の仕様が途中で変わり、パラメータの空値を許さなくなったためのようだ。

確かにソースの該当箇所を見てみると、

$date = mktime($hh,$mm,00,$month,$day,$year);

となってるんだけど、ソース中を調べても $hh には何の値もセットされていない。空値が渡されている。ここを試しに

$date = mktime(00,$mm,00,$month,$day,$year);

とかすると Warning は出なくなるので、やはり空値が問題のようだ。

PHP のバージョンは、古いサーバが 5.0.5、新しいサーバが 5.2.6。どうも、5.1.0 辺りで結構関数の仕様変更があったようなので（あくまで「ようなので」ですが(^^;）、やっぱその影響かなあ。

つーことで、この PHP プログラムを作成した会社に、お客さん経由で「新しい PHP のバージョンに対応した修正を行ってくれ」と依頼したんだが拒絶されたらしい。(^^;
おいおい・・・(^^;

旧サーバはあと２週間くらいで停止させるので、うちの方で直すしかないか・・・
やれやれ・・・(^^;

取りあえず、第一引数が空値なら date(H) をセット。第二引数が空値なら date(i) をセット・・・みたいに直してみればいいかな。

今、ざっと grep してみたら、mktime を使ってて、尚かつ引数に空値をセットしそうなソースが 11本あった。

他人が書いた PHP ソースを 11本も見るのは疲れるのお・・・(^^;

以前にも書いたが、某社がデータセンターでのハウジングサービスを止めるので、うちのサーバも含め、８～９月はまさにサーバ移行ラッシュである。

で、今日も１台サーバ移行作業を行なった。

レンタルサーバ間の移行ではなく、実機を移動するのでそこそこ大変である。
それに、InternetExplorer の「狂った仕様」にも振り回されたし。（是非、今後の動作確認は Firefox だけで行わせてほしい（笑））

つーことで、移行作業終了後に遅めのランチとなったのだが、疲労回復のため（笑）、いつもよりリッチに Royal Host のスパイシーグリルメニュー「大粒ホタテのミックスグリル　クリーミィーカレーソース」のＡセット 1,580円（税込 1,659円）なのである。
しかも、FREE の小瓶を付けたので、2千円オーバーである。

Royal Host のメニューを「リッチ」と言ってしまう社長ってどうなのよ！？(^^;
いや、しかも、お客さんに奢ってもらったし・・・(^^;

さて、さて、来週にかけてまだまだ大物が残ってますぜ。

ま、改めてサーバまわりの勉強にもなるので、疲れはするし、いやな汗もかくけど、ちょっと楽しい気持ちもあったり、なかったりであります。

https のサイトをうちのサーバに持ってきたので、httpd.conf の
Include conf/extra/httpd-ssl.conf 行を有効にして httpd の再起動をしようとしたら、

Syntax error on line 31 of /home/httpd/conf/extra/httpd-ssl.conf:
Invalid command 'SSLPassPhraseDialog', perhaps misspelled or defined by a module not included in the server configuration

なエラーが。

「module not included」とか言うてるけど、SSL は有効にして configure したはずじゃけどね・・・と、思って８ヶ月も前の作業ログを調べてみると、ああ、なんと、

# ./configure --enable-ssl=shared --with-ssl=/usr/local/ssl --enable-proxy=shared  --enable-proxy-ajp=shared

って、--enable-ssl してへんやん・・・とほほ(^^;

ということで、今度は

# ./configure --enable-modules=all --enable-so=yes --enable-ssl=shared --with-ssl=/usr/local/ssl --enable-proxy=shared  --enable-proxy-ajp=shared --enable-ssl

というオプションで configure して make & make install。

よっしゃ！と早速 httpd を起動しようとすると、今度は、

/home/httpd/bin/httpd: error while loading shared libraries: libcrypto.so.0.9.8: cannot open shared object file: No such file or directory

な、エラー。

ああ、俺のせいだ。libcrypto.so.0.9.8 のパスを通すのを忘れてた。

以前書いた「OpenSSL のインストール」の中の、共有ライブラリのパス追加の作業を行い、今度こそバッチリ httpd は起動した。

 

あり？

CentOS 5.3 64ビット版の DVD ISOイメージって壊れて伝播してる？

どこのサイトに言っても、サイズは 4.2GB って出てるのに、実際にダウンロードすると 250MB って・・・
DVD の ISO イメージが 250MB なんてこと、あるかーーーー！(^^;

本家が壊れたファイルをアップしたのが伝播したって感じ？
ようわからんなあ。

ということで、CentOS 5.3 って、インストールディスクが 7枚あって、ディスク交換が面倒なので DVD にしたかったのだけど、しかたないので CD の ISO イメージを地道にダウンロードしてインストールディスクを作成。

やっと、あと少しで 4台目のサーバのインストール終了。
たかが OS のインストール 4台だけで、１日かかってしまったぜ。(^^;

あとは、sshd 起動して、家からリモートでセットアップしよ。
観音の秘密基地、暑すぎ(^^;

室内で熱射病になりそう。（笑）

他サーバのWebサイト（PHP）から結果を取得して、それを編集・表示させる CGI を組まないといけない。
こういう時は Perl で LWP モジュール使って作っちゃうんだけど、調べてみると、実行予定のサーバに SSLeay モジュールが入ってない・・・

アクセス先が、https プロトコルなのですよ。なので SSLeay 必須。

ということで、Crypt::SSLeay モジュールをインストールしようとしたんだけど、include する OpenSSL の header ファイルとかも入ってないので、それも用意しないといけませんぜ。

OS が CentOS なので、RPM で openssl-devel とかを入れるのが「Linux 使い」の王道なのでしょうが、わしは FreeBSD の人なので、最新の OpenSSL をソースから make することに。
つか、FreeBSD なら、標準で header ファイルも入ってるよなあ。(^^; やっぱ、Linux 系OS は「クライアント OS」なんだよなあ。
ま、いいけど。

# wget http://www.openssl.org/source/openssl-0.9.8k.tar.gz
# tar xvfz openssl-0.9.8k.tar.gz
# cd openssl-0.9.8k
# ./config -fPIC shared
# make
# make test
# make install

これでインストールは終了。

この後、/usr/local/ssl/lib/ を共有ライブラリのパスに追加しておくこと。
これを忘れてたので、この後の Crypt::SSLeay モジュールのインストール時にバタバタしてしまった。(^^;

まず、/etc/ld.so.conf.d/openssl_0.9.8.conf という名前で、中に、
/usr/local/ssl/lib
とパスを書いたファイルを作成。

で、ldconfig コマンドを実行すれば、このパスが共有ライブラリのパスに追加されると。

これで、OpenSSL のインストールはばっちり終了。
もとからインストールされている OpenSSL 0.9.7a とも共存問題無し。

# /usr/bin/openssl version
OpenSSL 0.9.7a Feb 19 2003
# /usr/local/ssl/bin/openssl version
OpenSSL 0.9.8k 25 Mar 2009

ずっとうちのサーバを置いていたデータセンターが、今月いっぱいでハウジングサービスを止めるため、現在サーバの引っ越し作業中である。
今度は、自前のサーバを置くのではなく、レンタルサーバの利用に切り替えようかなっと思って。

で、昨日、Apache の VirtualHost で公開しているサイトのひとつを新しいサーバに持ってきた。

今までの httpd.conf 上の VirtualHost 設定をそのまま httpd-vhosts.conf に反映させたのだが、何故かサイトにアクセスすると、403 Forbidden エラーになってしまう。
パーミッションは適切に設定されているのに・・・だ。

新しいサーバの Apache のバージョンは 2.2.8。元のサーバは 2.0.50。

httpd.conf を穴が開くほど見比べてみると、どうも root directory の設定の違いが影響しているのではないかと。

2.0.50 の httpd.conf

<Directory />
    Options FollowSymLinks
    AllowOverride None
</Directory>

2.2.8 の httpd.conf

<Directory />
    Options FollowSymLinks
    AllowOverride None
    Order deny,allow
    Deny from all
</Directory>

Deny from all ってのが追加されているよねえ。
ディフォルトで、「全部アクセス不可」になってるってことだ。

なので、VirtualHost 設定の、

<Directory "/var/www/www.exsample.com">
    AllowOverride None
</Directory>

を、下記のように直してやる。

<Directory "/var/www/www.exsample.com">
    AllowOverride None
    Order allow,deny
    Allow from all
</Directory>

これでちゃんと http://www.exsample.com が見れるようになった。

2.2 系以前から 2.2 系に設定をコピってくるときは注意が必要じゃね。

取引先（仮にＡ社としておこう）が倒産した。
と言っても、商いの額も少ないし、間に別の会社が入っているので、当社への影響は小さいのだが。

いやあ、しかし、このＡ社の営業の人は酷かった。（まあ、ある程度『社風』というのもあるのだろうが）

典型的な「下請けに無理を押しつける人」だった。

この「下請けに無理を押しつける人」を「権力を笠に着た嫌なヤツ」と捉える人が多いんんですが、これは間違い。
こういう人たちの多くは、「下請け虐めをすることで、自分の力を確認したいヤツ」ではありません。単純に「折衝能力に欠けた馬鹿」が多いんです。

「下請けに無理を押しつける」という行為は、大概、「上司にうまく案件の内容を説明できない」「お客さんを納得させるような説明ができない」などと言った「能力不足」に起因します。
ちゃんと説明出来ないから、「面倒くさい」とか「これでは上は納得しない」とか「何が何でもやってもらうしかない」とか、そんな訳の分からない理由で「下請けに押しつける」行為をするしかなくなるんです。
「上」にちゃんと説明して納得してもらう力が無いから、「下」に無理難題を押しつけざるを得ない・・・ということです。

俺はこういう馬鹿が大嫌い。

大人なら、少々人付き合いが苦手であろうが、折衝能力は身につけておかないと。
また、仕事の中身を理解するくらいの頭は持ってないと。
「人間失格」とまでは言いませんが、「ビジネスマン失格」です。

Ａ社の営業の人がこういう人だった。(^^;

このＡ社の営業さん（仮に■■という名前とする）は、うちのスタッフの間でも有名で、一時期、俺が仕事持って帰ると、スタッフの第一声が「これ、■■案件じゃないですよね？」だったというくらい。(^^;
エンドユーザからの要望を丸投げしてくるだけで、それに対するこちらの都合（工数増、納期調整等）については一切相手と折衝してくれない（結局、折衝する能力がまったく無かっただけなんですが(^^;）ので、「■■案件はやりたくない」とはっきり言う外注さんもいましたよ（笑）

この人がトップ営業なんだから、Ａ社の行く末も決まってたんだよなあ・・・(^^;

下請けに無理難題押しつけてる人は、自分が馬鹿だということをちゃんと認識した上で猛省してほしいな。はっきり言って、下請けに無理を押しつける人に、仕事が出来る人は一人もいません。（笑）

＜追記＞
現在の当社のお客様には、こういう人はいらっしゃらないことを明記しておきます。「おい、あれって俺のことか？」みたいな恐ろしい誤解無きよう。(^^;