UNIXやLinuxの最近のブログ記事

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 使うって、ここに書かれてたのね。(^^;

他所のメールサーバのユーザ情報を、うちの vpopmail 環境に移します。
ちなみに OS は、相手が FreeBSD。こっちは CentOS です。

まずは、vadduser コマンドを使ってユーザ登録。パスワードは適当でよし。

$ ~/bin/vadduser hiromichi@exsample.com

次に、vi エディタで、そのユーザのパスワードを、以前のサーバの passwd ファイルのパスワードに修正。（ちなみに、vpopmail のパスワードは MD5 で暗号化されてるんですが、移行元のパスワードは国際化 DES。問題ないっす）

$ vi ~/domains/exsample.com/vpasswd

hiromichi:$1$WBf6/Tez$/gMLmHh/Ra4AA97N/FTisH/:1:0:hiromichi:/var/vpopmail/domains/exsample.com/hiromichi:NOQUOTA
　　　　↓
hiromichi:qC8XGKnFCVbvQ:1:0:hiromichi:/var/vpopmail/domains/exsample.com/hiromichi:NOQUOTA

この状態では、まだ実際に使用されるパスワードのデータベースは更新されていないので、vmkpasswd コマンドを使って更新を行う。

$ ~/bin/vmkpasswd exsample.com

これで、vpasswd.cdb が更新されるので、移行してきたパスワードでのログインが可能になるっちゅうわけですな。

まったく、ポルトガルの vodafone！何をしてるの、貴様。

うちでのサーバにひたすら ssh で接続しようと試みて。

Feb 28 16:23:41 localhost sshd(pam_unix)[13001]: authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=83.174.41.144  user=bin

いやあ、まあ、よくあることだけど、IP アドレス逆引きしてホスト名が取れることもあまりないので。面白くて載せちゃいました（笑）

実際、まぬけぇ～

↓こういう、ディフォルトで存在していることの多いユーザに対して、パスワード無し、あるいは、名前そのままのパスワードで接続を試みているようだ。

ftp
postgres
root
apache
named
nobody
news
games
mail
adm
rpm
operator
sshd
bin
daemon
lp
sync
shutdown
halt
uucp
smmsp
mailnull
nfsnobody
rpcuser
rpc
gopher

まあ、root と postgres は shell での作業があるから、ログイン可能な shell が指定されてるだろうし、パスワードがわかればログイン出来るだろうけどな。そんな簡単に見つかるようなパスワードじゃないって。（笑）

他のユーザに関しては、ログインできるような shell は指定してないしな。（笑）

他の IP アドレスからも、同様の不正アクセスの試み多数。
どうも、今一番流行ってる攻撃方法らしい。

さすがに鬱陶しいので、今、アクセス制限した。
ほんま、世の中にはつまらない不正を行う馬鹿が多くて困っちゃう。

＃インストールしたばかりで何もないサーバだったので、ちょっとどのくらい不正アクセスがあるのか試してみたのでした。

Red Hat Enterprise Linux をインストールした時、ディフォルト設定のままで進めたら、なんかディスク容量が実容量より少ない数字になってたような～・・・df コマンドで見てみたら、やっぱ少ないようなぁ。未使用領域ができちゃってるのかなあ・・・とか思って fdisk で新しいパーティションを追加しようとしたら「利用可能フリーセクタがありません」だって。

う～む。Linux のファイルシステムがまだよくわかってないので、何がなんやら。

結局、Gnome の論理ボリューム管理画面で、論理ボリューム /dev/mapper/VolGroup_ID_30656-LogVol5 のプロパティを開いて、「残り領域の使用」ボタンを押して未使用領域をすべて /usr パーティションにくっつけてやった。

そしたら、あれま、ほんとに /usr パーティションの大きさが変わってるよ。

/dev/mapper/VolGroup_ID_30656-LogVol5
                      47831960   3624244  41777972   8% /usr
　　↓
/dev/mapper/VolGroup_ID_30656-LogVol5
                     107275296   3632172  98196184   4% /usr

なるほど、これが Linux LVM とかいうやつか。
大きくしたり、小さくしたり、自由自在かいな。

あ、いや、自由自在ではないようだ。領域を狭くするときは一旦アンマウントしてやらないといけないので、実質、/usr パーティションでは難しいなあ。

それと、空き領域って何か他のことに使えるんかいな？
特定のパーティションの大きさしか変えられないんじゃ、あまり意味がないような気もするなあ・・・

少し勉強してみよう。

いやぁ、「DELL R200 のセットアップが失敗」の件で今日 DELL のソフトウェアサポートに電話したんだけど、一発でつながったし、ちゃんと Red Hat Enterprise Linux や DELL PowerEdge のハードのことがわかる兄ちゃん（Y氏）が出て対応してくれて非常に助かった。

ほら、全然電話がつながらなかったり、サポート業務を丸ごと外注してるから担当者に商品知識が無かったり（マニュアル通りの受け答えしかできなかったり）ってナメたサポートサービスってあるじゃん。
DELL はそうじゃなかったね。

結局、

・R200 についてきた DVD メディアに問題があるかもしれないので、R300（も、同じ日にセットアップしたと俺が説明したので）についてきている Systems Build and Update Utility で試してみてほしい。
・それでも駄目なら、直接 OS のインストールをしてみてほしい。（RHEL の CD から）

ということになったので、早速試してみた。

・・・ら、R300 の DVD でインストールしたらうまくいった。

うーん、目視では特に DVD 表面に傷や汚れは見あたらんけど、なんか問題があるのかなあ？実際、他のメディアではうまくいったのでそうなんだろうなあ。
ああ、光の加減では、細い傷が３本見えないこともない。これが原因かな？

何はともあれよかった。DELL サポートに結果の報告をしとかなきゃ。

Dell PowerEdge サーバシリーズの　R300 と R200 を一台ずつセットアップした。
どちらも OS は Red Hat Enterprise Linux 4.5。

Dell System Build and Update Utility を使ってインストールしたのだが、R300 の方は特に問題なく終了。

駄目駄目なのが R200 の方だ。

日時設定、OS 選択、RAID 設定、物理ディスクの設定、ネットワーク設定、OS 情報（hostname ,root パスワード等）の設定と行い、最後にインストールを実行するのだが、途中で処理が終わってしまう。

インストール開始後、Dell System Build and Update Utility の DVD の読込と、HDD へのアクセスが続く。ガチャガチャ、ジージーと音を立てて、DVD ドライブと HDD のアクセスランプが交互に瞬く！

・・・が、進捗具合が 11% になったところで、突然それらの動きが止まり、R200 は沈黙する。
HDD ランプは点きっぱなしだが、HDD が回る音はまったくしない。ほとんど「ハングってる」状態だ。

本当なら、12～13% あたりで Dell System Build and Update Utility の DVD が自動で排出され、ここから Red Hat の CD を 1～5まで抜き差ししながら、Red Hat Enterprise Linux 4.5 のインストールが実行されるはずなのだ。

・・・が、現実には、DVD も自動排出されず、Red Hat のインストール CD は一枚も使われることなくインストールは中断してしまうのだ。

やれやれ。

プログラムの中で自動でパスワード付きの圧縮ファイルが作れないか・・・という話があったので zip コマンドについて調査。

zip -P パスワード 圧縮ファイル名（*.zip） 圧縮対象ファイル . . .

で、パスワードをかけて圧縮出来る。
解凍するときは、unzip コマンドでも同じように -P オプションをつけてやればＯＫ。

具体的には、例えば hogehoge というパスワードをかけて圧縮する場合、

＜圧縮＞
zip -P hogehoge exsample_files.zip exsample_file1.txt exsample_file2.txt
＜解凍＞
unzip -P hogehoge -d . exsample_files.zip

という感じ。

まあ、あんまり P オプションは使うな・・・ということのようだが、他人がコマンドを見れない環境であれば全然問題ないと思うがね。（生理的に駄目だという人は、多分、ウィルスに感染したファイルの入った FD を差し込んだだけで青ざめるような人なんだろうな（笑））

※チェックしたのは、Red Hat Enterprise Linux ES release 4 (Nahant Update 4)
 上にて。

MovableType の MailPack plugin のメール取得処理で、

[MailPack] listner.pm Can't locate object method "binmode" via package "IO::File" at /usr/lib/perl5/site_perl/5.8.5/MIME/Body.pm line 437.

というエラーが出てしまう。
確かに、/usr/lib64/perl5/5.8.5/x86_64-linux-thread-multi/IO/File.pm を見てみると、binmode なんてメソッドは無い。

なので、CPAN から最新のソース（http://search.cpan.org/CPAN/authors/id/G/GB/GBARR/IO-1.2301.tar.gz）を取ってきてインストールしてみた。（最新つっても、2006/3/26 fix ですよ。枯れてるなぁ(^^;）

# grep binmode /usr/lib64/perl5/5.8.5/x86_64-linux-thread-multi/IO/File.pm
＜略＞
sub binmode {
    ( @_ == 1 or @_ == 2 ) or croak 'usage $fh->binmode([LAYER])';
＜略＞

をを、ちゃんと binmode が存在してるじゃないすか。グー。

CentOS 4.7 の File.pm は相当古いんじゃねえ。

MTOS 4.23-ja で、cron に run-periodic-tasks を登録して実行すると、MT/Bootstrap.pm と MT.pm が見つからないってエラーが出るね。
cron 実行時のカレントディレクトリからのパスが通ってないようで。

Can't locate MT/Bootstrap.pm in @INC (@INC contains: lib ../lib /usr/lib64/perl5/5.8.5/x86_64-linux-thread-multi ＜略＞ .) at /var/www/html/mt2/tools/run-periodic-tasks line 44.

とか、

Can't locate MT.pm in @INC (@INC contains: /var/www/html/mt/tools/lib /var/www/html/mt/extlib ＜略＞ .) at /var/www/html/mt2/tools/run-periodic-tasks line 45.

とか。

ずいぶん前から既知のエラーのようだけど、未だに直ってないんだなあ。

ググってみると、強引に /usr/lib/perl5/5.8.5 の下とかにファイルをコピっちゃうという話が出てたが、それはあんまりだと思うので、取りあえずシンボリックリンクを張ってみた。

# ln -s /var/www/html/mt/lib/MT /usr/lib/perl5/5.8.5/MT
# ls -la /usr/lib/perl5/5.8.5/MT
lrwxrwxrwx  1 root root 24 Jan 15 11:36 /usr/lib/perl5/5.8.5/MT -> /var/www/html/mt/lib/MT
# ln -s /var/www/html/mt/lib/MT.pm /usr/lib/perl5/5.8.5/MT.pm
# ls -la /usr/lib/perl5/5.8.5/MT.pm
lrwxrwxrwx  1 root root 27 Jan 15 11:42 /usr/lib/perl5/5.8.5/MT.pm -> /var/www/html/mt/lib/MT.pm

取りあえず、これで run-periodic-tasks は問題なく実行されているようだ。

MovableType 4.1 では問題なかったので、MTOS の問題なのか？それとも、4.2 以降のバージョンで出てきた問題なのか？？？