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

GnuPG の設定で、サーバ側で鍵情報を作成しようとしたらエントロピーが足りないと言われ処理が止まっちゃう。（ssh でリモート接続して作業中）

# gpg --gen-key
gpg (GnuPG) 1.2.6; Copyright (C) 2004 Free Software Foundation, Inc.
＜略＞
We need to generate a lot of random bytes. It is a good idea to perform
some other action (type on the keyboard, move the mouse, utilize the
disks) during the prime generation; this gives the random number
generator a better chance to gain enough entropy.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++.++++++++++...+++++.++++++++++.++++++++++++++++++++.++++++++++.+++++..++++++++++>+++++++++++++++

Not enough random bytes available.  Please do some other work to give
the OS a chance to collect more entropy! (Need 283 more bytes)

なので、適当に何百文字もキー入力してみるのだが全然動き出す気配無し。
エントロピーというのは、乱数の「素」にするための「不確定性、乱雑、無秩序」なデータのことで、あるタイミングで計ったディスクアクセス数であったり、キーイン数であったり、マウスの位置であったり、そういう値なのだが、それが足りないとおっしゃる。

Windows 上で鍵を作る時はマウスを思いっきり動かしたりしてエントロピーを溜めるわけだが、ssh で接続したリモートサーバの場合はどうすんのかね？
かなりの文字数を入力してみたが、全然足りないようだ。

と思ってググってたら、別の ssh セッションで接続して、そっちで意味の無いディスクアクセスを大量に発生させちゃえばいいぜ！という情報発見。

別の ssh セッションで、

$ dd if=/dev/urandom of=/tmp/mass bs=1M count=512

としたら、一回り（512回転）では駄目で、もう一回、200回弱書込を行ったところでエントロピーが十分取得できたようだ。
自動的に再度、キー情報の作成処理が実行された。

We need to generate a lot of random bytes. It is a good idea to perform
some other action (type on the keyboard, move the mouse, utilize the
disks) during the prime generation; this gives the random number
generator a better chance to gain enough entropy.
..+++++.++++++++++..+++++++++++++++++++++++++..+++++++++++++++++++++++++..+++++++++++++++++++++++++.++++++++++.++++++++++++++++++++++++++++++>+++++......>+++++<.+++++..............+++++^^^^^^^^^^^^^^^
gpg: /root/.gnupg/trustdb.gpg: trustdb created
public and secret key created and signed.
key marked as ultimately trusted.

pub  1024D/F985786F 2009-05-25 Exsample WWW Server Administrator <admin@exsample.jp>
     Key fingerprint = C809 47C7 0B8C XXXX CF43  BB0C XXXX A085 F996 796F
sub  1024g/AA8FFA04 2009-05-25

ばっちりですな。

しかし、エントロピーが足りないなんて言われたのは初めてだ。

某マスコミ系会社のサーバや、WebARENA 上のホスティングサーバなどで作業をしたことがあるが、どれも ssh セッション上の作業で全然問題なく鍵情報が作られたんだけどな。
しかも、今回作業したサーバは、けっこう Web サイトへのアクセス数もあるサーバなのだが・・・

どうも、ここのところ見積り外の作業が発生するケースが多いような・・・(^^;

最近、Red Hat Enterprise Linux で扱う FTP サーバはずっと vsftpd ばかりだった。
ところが今週触ったサーバが ProFTPD で、あまりに久しぶりなんで戸惑ってしまった。

FTP 用のユーザ追加して、ちゃんと chroot してるか /etc/proftpd.conf の DefaultRoot をチェックして、

DefaultRoot                     ~ !wheel

うん、wheel グループ以外のユーザは DefaultRoot が ~（自分のホームディレクトリ）になってるな・・・と確認。
ほんじゃ、接続してみますか・・・と ftp コマンド叩いたんだけど、認証ではじかれるじゃーん！？

Name (localhost:hoge9999): hoge9999
331 Password required for hoge9999.
Password:
530 Login incorrect.
Login failed.

他のユーザの設定を見て、どうも ftpusers というグループに所属してないと駄目だということはわかったんだけど、さて、その設定はどこにあるのやら？？？
穴が開くほど /etc/proftpd.conf を眺めてみたけど、そんな設定、あったっけぇ～？？？と、しばし悩む。

で、/var/log/messages 見てみたら、proftpd が「FTP session opened.」なメッセージを吐いた後、同じ PID で PAM が続けてメッセージを吐いてるじゃん。
なんだ。PAM 使ってるのか。

てことで、/etc/pam.d/ftp 見てみたら、

auth       required     pam_succeed_if.so user ingroup ftpusers
auth       required     pam_stack.so service=system-auth
auth       required     pam_warn.so

ああ、やっぱり。

ログインユーザが ftpusers グループに含まれていれば OK という設定がありますな。

と思って、もう一度 /etc/proftpd.conf を見てみると、

AuthOrder                       mod_auth_pam.c* mod_auth_unix.c

ああ、認証で PAM 使うって、ここに書かれてたのね。(^^;

メール解析のプログラムを作成してて気づいたのだが、SoftBank の携帯（テストで使ってたのは、俺の 810T だが）のメールヘッダって、Content-Type ヘッダの後ろに空白を入れないんだな。

例えば、PC のメールソフト（Outlook とか EDMax とか AL-Mail とか諸々）だと、Content-Type ヘッダは、

Content-Type: multipart/mixed;

こんな感じで、'Content-Type:' の後ろに半角スペースがひとつ入ってる。
でも、810T のメールは、

Content-Type:multipart/mixed;

なんだよ。
他にも、コンテンツの属性を示すヘッダ関係は軒並み、

Content-Type:text/plain;charset=ISO-2022-JP
Content-Disposition:attachment;filename="HOGEHOGE.JPG"
Content-Transfer-Encoding:base64

みたいな感じで全て半角スペースは含まれてない。

他のヘッダ（To とか From とか Subject とか）は、全て半角スペースが含まれているのに・・・である。

変な実装。(^^;
いや、RFC にどう書かれているのかわからないが、半角スペースが無いなら無いで全然かまわんのやけど、他のヘッダと、Content 関係だけがフォーマットに違いがあるのが何か気持ち悪いよなあ。

PC から出したメールに添付した画像は抜き出せるのに、携帯メールに添付した画像が抜けないので、何でかいな？と調べたらそういうことで、

if ($data =~ /Content-Type\:\s+(\S+[^\;]*?)/i) {

という正規表現を使った条件をすり抜けてた。

if ($data =~ /Content-Type\:\s*(\S+[^\;]*?)/i) {

とすればOK。

Foma とか AU の端末もこんなんかなあ？

俺は基本的に「来るものは拒まず、去るものは追わず」だ。何もかも。

去るものを無理に追って気持ちを変えさせることに成功したとしても、それは既にそこに無理があるわけで、良好な関係は近いうちに再度崩壊するだけだろう。

相手の去る理由が理不尽なものであれば尚のことだ。

モンスターカスタマーという言葉がある。
ま、文字通り「化け物顧客」のことで、要は「理不尽な無理難題を吹っかけてくる顧客」のことなんである。

例えば、日経ITproの記事に載ってる例だと、「競合相手に開発プロセスを監視させると言われた」とかそういうやつだ。
当然断ると、取引をやめるとか言い出す。これが典型的なモンスターカスタマーである。

そういう時はね、「はい。わかりました。ではやめます。」とやめてやればいいのだ。
去る者を追う必要はまったくないのだ。

あと、良くあるのが、「今回は予算がつかなかったので自分でやることにしたよ。だからやり方を教えて」って台詞。これを読んでいる人の中にも言ったことある人いるんじゃないだろうか？

正論を言うよ。

「予算が付かなかったってことは、会社が必要ないと判断したってことでしょ？」
「必要なことなのに予算を付けなかったのなら、それは経営陣の判断ミスでしょ？」
「"やり方を教える"ことにも工数が発生するのがわからない？下手すれば、自分でやるより工数かかるんですけど？」
「どうしてもやらなきゃいけないことだと思うのなら、もう一度予算を取れるようがんばるべきでしょ？」
「自分でやるにしても、そのやり方をレクチャーしてもらうのに金がかかるということをちゃんと上に説明しなきゃ。」

以上。

「何をケチくさいことを言ってるんなあ。今まで散々仕事出してきたやろ」なんて言うカスタマーには、「金がかかることをタダでやらせようというお前の性根の方がよっぽど"ケチくさい"んじゃ！」と正論をぶつけ、さっさと関係を断ちましょう。（笑）

「簡単に言うな！」と怒られるかもしれないが、そういうモンスターカスタマーというのはそもそも「人間的に問題がある」わけで、犯罪者の再犯率が一般人の初犯率よりも高いのと同じで、そのカスタマー（顧客）の脳みその具合とか、育ってきた家庭環境とか、そういうことで形作られた「性根」というのは、こっちが正論を言ったところで治癒するようなものではないのだ。

モンスターカスタマーだって、ずっと付き合っていれば良い人になるかも・・・なんて甘い期待を持たないほうがいい。
嫌なやつはいつまでたっても嫌なやつなのだ。良好な関係が築けているのも、相手の態度が変わったわけではなく、たまたま相手が「無理難題をふっかける必要がない」余裕のある状況なのか、あなたが無理難題を押し付けてこないよう（意識的には無意識にかは別として）うまく相手をハンドリングしてるかのどちらかである。
決して相手が、「今までの俺の考え方は間違っていた！」と気づいて変わったわけではないのだ。

一度でも、「この人、ビジネスマンとしての常識がないなあ」とか「無茶な要求する人だなあ」と思った相手というのは、すんなり切ってしまうに限る。

ろくでなしとうまく付き合うパワーを、別の方向に向けたほうがよっぽど良い。

で、今、何故に敢えてこういう事を書いているかというと、こう IT 不況が続くと、ついついそういう「敢えて関係を断った理不尽な客」にも「仕事ないっすか？」なんて声をかけてしまいそうになる弱い俺がいるからである。（笑）

いかん、いかん。
そんな、「乞食に金をねだる」ような恥ずかしい行為は絶対にいかんのである。

食えなくなったら、人手不足という運送業か居酒屋の店長に転身してでも、そういう「モンスターカスタマーに助けを求める」ことはしちゃいかん。
「そいつら」を増長させるだけだからね。

＜追記＞
今、おつきあいをさせていただいているお客様のことではないことを明記しておきます。
「俺のことだと思ったわぁ」なんていう恐ろしい誤解があるといけないので。(^^;

Perl で、POP3 サーバからメールを受信する処理を書かないといけなくなった。

今までだと、直接 Socket の確立から、実際の POP3 コマンドの発行部分まで自分で書いてたんだけど（その方が無駄な処理を省いてシンプルなソースが書けるんでねぇ）、しかし、今回は納期も予算も少ない案件なので、Mail::POP3Client モジュールを使ってみることにした。
（例しに CPAN モジュールでインストールしてみたら、珍しくスコっと入ったし（笑））

use Mail::POP3Client;

して、受信処理の書き方は

 my $pop = new Mail::POP3Client(
  USER => $Muser,
  HOST => $Mhost,
  PASSWORD => $Mpass,
  DEBUG => 0
 );

こんな感じで $pop を Mail::POP3Client クラスのオブジェクトとして宣言し、後は、

 受信メールの件数取得
 $pop->Count

 ヘッダ部の受信
 $pop->Head(メッセージ番号)

 ボディ部の受信
 $pop->Body(メッセージ番号)

 メッセージの削除
 $pop->Delete(メッセージ番号)

 POP3接続の切断
 $pop->Close

などのメソッドを適時使ってソースを書けばいいだけ。
（もちろん、Subject を MIME decode したり、添付ファイルを切り出したりといった処理は自分で書く必要あり）

なのに、実行すると、

Use of uninitialized value in pattern match (m//) at /usr/lib/perl5/site_perl/5.8.5/Mail/POP3Client.pm line 1078, <GEN0> line 2.

なエラーが出てしまい、処理が中断されてしまう。なぜ？？？

DEBUG 表示を ON にして（DEBUG => 1）実行してみると、

# ./get_pop3_mail.pl
POP3 <- +OK <20028.1242047733@serv.exsample.com>
 at ./get_pop3_mail.pl line 97
POP3 -> APOP mail_test@exsample.com feb4f975bc9cd0c24151ac7ceea4dc1f
 at ./get_pop3_mail.pl line 97
POP3 <- -ERR authorization failed
 at ./get_pop3_mail.pl line 97
POP3 -> NOOP
 at ./get_pop3_mail.pl line 97
Use of uninitialized value in pattern match (m//) at /usr/lib/perl5/site_perl/5.8.5/Mail/POP3Client.pm line 1078, <GEN0> line 2.

となる。
ああ、APOP 未対応の POP3 サーバに対して、APOP 認証しようとしてるのね。で、エラーになってるんだ。
そこで Connection closed by foreign host. になっちゃうので、その後 NOOP コマンドを投げても何のレスポンスも返ってこないから（空値に対してパターンマッチを行おうとして）、そういうエラーを吐いちゃうんだ・・・

しかし、それで Perl のエラーが発生するというのはどういう実装よ。(^^;
なんとかハンドリング出来んのかいな。Socket 接続が切れてたらコマンド送らないとか。むーん・・・

どうも微妙に気持ち悪いんだが、今回は APOP 認証を止めればエラーは出ないので、それで良しとする。

普通にプレーンパスワードで認証をするように、

 my $pop = new Mail::POP3Client(
  AUTH_MODE => 'PASS',
  USER => $Muser,
  HOST => $Mhost,
  PASSWORD => $Mpass,
  DEBUG => 1
 );

という具合に、AUTH_MODE => 'PASS' を追加してやる。

これで、

# ./get_pop3_mail.pl
POP3 <- +OK <23657.1242048016@serv.exsample.com>
 at ./get_pop3_mail.pl line 97
POP3 -> USER mail_test@exsample.com
 at ./get_pop3_mail.pl line 97
POP3 <- +OK
 at ./get_pop3_mail.pl line 97
POP3 -> PASS hogehoge
 at ./get_pop3_mail.pl line 97
POP3 <- +OK
 at ./get_pop3_mail.pl line 97
POP3 -> STAT
 at ./get_pop3_mail.pl line 97
POP3 <- +OK 1 998
 at ./get_pop3_mail.pl line 97
POP3 -> TOP 1 0
 at ./get_pop3_mail.pl line 112
POP3 <- +OK
 at ./get_pop3_mail.pl line 112
POP3 <- Return-Path: <exsample@gmail.com>
＜以下略＞

という具合に、正常に POP3 によるメール受信が成功する。バッチリ。

おお、DEBUG 出力を無効（DEBUG => 0）にしとかなきゃ。

引き続き、知り合いの会社のサーバ復旧作業のお手伝い中。
ほんとは一気に作業して復旧させちゃいたいんですが、俺も本来の仕事（プログラミングとか）が終わった後でないと対応できないもんで。

で、昨日は、

Warning: mb_convert_encoding(): Unable to detect character encoding in /var/www/hoge.php on line 86

な、エラー（Warning だけど、表示が乱れて使い物にならないので実質エラー）の解消作業。

ま、PHP 使いの人はよく見てる Warning メッセージでしょうが。（笑）

mb_convert_encoding($hogehoge, 'EUC-JP', 'auto')

を、

mb_convert_encoding($hogehoge, 'EUC-JP', 'ASCII,JIS,UTF-8,EUC-JP,SJIS')

に修正したら Warning が出なくなるので、典型的な「mbstring.language = Japanese」が有効になってないパターン。
でも、php.ini を見たら、ちゃんと mbstring.language = Japanese の記述が・・・

つーか、php.ini が Document Root に置いてあるんだけど、ほんと？

phpinfo() で調べてみると、ほら、Configuration File (php.ini) Path は、/usr/local/lib になってんじゃん。

/usr/local/lib 以下に php.ini が無いのを確認し、Document Root の php.ini をコピー。Apache を再起動してチェックしたら、バッチリOKです。

ということで、php.ini の置き場所を間違っていたために、mbstring.language の設定が効いていなかった・・・というオチでした。