■ 2/1
昨日の ophcrack は SLAX というディストリビューションがベースらしい。この
SLAX は、かなり昔からある 1 CD Linux のようで、 slackware ベースのもの。
昨日使った ophcrack じゃ、アレなんで、本物の SLAX をダウンロードしてきた。
これで、やっと HDD のバックアップができるかもしれない。
■ 2/2
久しぶりに携帯電話端末について。 SoftBank 端末は 80 版ポート以外の web の
アクセスができない。仕様らしいけど。SoftBank 端末と AU 端末は http ヘッダの
Content-Type がないと、表示しようとしない。DoCoMo 端末は何故か表示できて
しまう(html の場合)。なんだか、ヘッダとか、表示可能な画像形式とか、もう少し
統一して欲しいよなぁ、なんて思ってしまう。
■ 2/3
久しぶりに、人様の Solaris 環境で作業とかすると、 tar に z オプションが
なかったり、 ifconfig にオプションが必ず必要だったり、 whoami コマンドが
/usr/ucb にあってパスが通ってなかったり、すごい調子が狂ってしまう。で、
自分の .cshrc をコピーして、 GNU tar をコンパイルしてから使うのだけど、
昔、よく Solaris なんか使ってたなぁ、なんて思ってしまった。
■ 2/4
Dovecot 1.0rc20, 1.0rc21 が立て続けに出たので、 Dovecot のページを更新。
それにしても、１時間後に新しいバージョンを出すのは、ちょっとね…。変更は、
variables.txt に注記が入ったのと、 dovecot.conf に
mail_log_max_lines_per_sec が追加されたのと。
■ 2/5
今動いている Apache で CGI を動かそうと設定を変更。Apache のバージョンは
1.3 系のもの。 httpd.conf の IfModule mod_alias.c の中に、以下を追加。
Alias /testcgi/ "/home/toyota/testcgi/"
<Directory "/home/toyota/testcgi">
Options ExecCGI
AllowOverride None
Order allow,deny
Allow from all
</Directory>
あとは、拡張子が cgi と認識するように IfModule mod_mime.c の中に、
AddHandler cgi-script .cgi
を追加。これで apache を再起動してみる。アクセスしてみると、 c で作った
cgi のバイナリがそのまま返ってきてしまう。まだ設定が足りないようである。
[toyota@hoth]$ /usr/local/apache/bin/httpd -l | grep cgi
mod_cgi.c
cgi のモジュールは入っているみたいである。何で動かないかなぁ、なんて思い
ながら、家のサーバの設定を見てみると、
AddModule mod_cgi.c
が入っていたので、追加してみた。再起動して、テストすると動いた。 cgi を
動かす設定ごときで、かなり時間を使ってしまった。
■ 2/6
とある C 言語のプログラムで、 fopen 関数を使っていた。それはなんら問題が
ないのだけど、引数でディレクトリを指定したとき、 fopen はエラーを吐かず、
そのまま open してしまった。なんとなく、意識では fopen にディレクトリを
渡すとエラーが起きると思っていたのだけど、そうではないみたい。ということは、
fopen の前に stat をするか、 fopen の後に fstat をするか。fopen 前に stat を
するように変更したのだけど、ディレクトリを fopen して良いことがあるのか、
ちょっと実験してみた。一応、環境は Linux 2.6 。
fopen で mode に w を指定してみる → できた
fread する → 0 しか返ってこない
fwrite する → 0 しか返ってこない
fseek する → 0 しか返ってこない
fgetc する → -1 しか返ってこない
な感じになった。つまり、 fopen でディレクトリを開いても、何もできない、
ということになる。何かに使えるのかなぁ…。
■ 2/7
Dovecot 1.0rc22 が出た。早速チェックしてみたけど、文章的に dovecot-sql.conf
に変更があっただけ。未訳なので、今回は Dovecot のページに変更はなし。それに
しても、
I'm optimistic again about v1.0 being released soon.
と書いてあるけど、何度この言葉に騙されたことか。
■ 2/8
コンクリートブロックに化粧をする必要があって、何を買ってどう作業したら良い
のか、調べてみたのだけど、素人で施工している人が少ないようで、 web page で
良いページが見つからなかった。で、建材屋に行って、相談したら、「美ブロ」が
良い、との返事。でも、ちょっと値段が高い。で、次に教えてもらったのが、壁に
NSハイフレックスのような混和剤(接着剤と言っていたけど)を塗って、モルタルにも
混ぜる方法。これで、だいぶ壁塗りが楽になるらしい。砂も篩いに掛けたほうが
良い、と言われたのだけど篩いなんて持ってないので…、と言うと、珪砂を勧めて
くれた。以前、壁にそのままモルタルを塗って、うまく塗れなかったのだけど、
色々と便利なものがあるのだなぁ、とちょっと関心した。週末、天気が良ければ
やってみよう。
■ 2/9
postfix を使っていて alias ファイルを書き換えたときに newaliases コマンドを
発行していたのだけど、 postalias を使っている人がいた。で、動作の違いに
ついて、ちょっと調べてみた。今日は RedHat ES3 な環境。
[toyota@hoth]$ which newaliases
/usr/bin/newaliases
[toyota@hoth]$ ls -l /usr/bin/newaliases
lrwxrwxrwx 1 root root 32 2月 7 16:53 /usr/bin/newaliases -> /etc/alternatives/mta-newaliases
[toyota@hoth]$ ls -l /etc/alternatives/mta-newaliases
lrwxrwxrwx 1 root root 27 2月 9 14:04 /etc/alternatives/mta-newaliases -> /usr/bin/newaliases.postfix
[toyota@hoth]$ ls -l /usr/bin/newaliases.postfix
lrwxrwxrwx 1 root root 31 2月 7 17:05 /usr/bin/newaliases.postfix -> ../../usr/sbin/sendmail.postfix
[toyota@hoth]$ ls -l /usr/sbin/sendmail.postfix
-rwxr-xr-x 1 root root 92424 6月 30 2004 /usr/sbin/sendmail.postfix
なんだか、嫌がらせのようである。一方の postalias は。
[toyota@hoth]$ which postalias
/usr/sbin/postalias
[toyota@hoth]$ ls -la /usr/sbin/postalias
-rwxr-xr-x 1 root root 116288 6月 30 2004 /usr/sbin/postalias
本当は、ハードリンクで同じファイルを見ていることを期待したのだけど。で、
man で調べてみることにした。色々調べた結果、(多分) Postfix についていた
sendmail(1) の man に書いてあった。
newaliases
Initialize the alias database. If no input file is specified
(with the -oA option, see below), the program processes the
file(s) specified with the alias_database configuration parame-
ter. If no alias database type is specified, the program uses
the type specified with the default_database_type configuration
parameter. This mode of operation is implemented by running the
postalias(1) command.
と。結局 postalias コマンドを呼んでいるみたい。 newaliases コマンドは、
sendmail 互換のためのものみたいなので、 postalias コマンドを使うのが正解
かもしれない。
■ 2/10
PLC な LAN の機器が売れているようである。が、屋外にもコンセントがある場合、
屋外でも機器が使えて便利と思うべきか、第３者が盗聴できてしまうので、危険と
思うべきか。ちょっと考えてしまった。やっぱり、後者が心配である。それに、
昔はアマチュア無線をやっていた人間として、ちょっと PLC を気軽に使う気に
なれないし。古いコンクリート造の家だったら、 PLC も選択肢として考えるかも
しれないけど。
■ 2/11
木曜日に買ってきた珪砂＋ホワイトセメント＋NSハイフレックスに、黄色の顔料を
入れて、壁に塗ってみた。が、顔料を入れすぎたようで、凄い色になってしまった。
塗りやすさとしては、だいぶ楽なのだけど、結構壁に押し付ける力が必要で、
腕が痛くなってしまった。なんとか仕上がって、夜にふっと思い出した。壁に
飾りとしてビー玉を埋めようと買っていたことを。すっかり忘れていた。ま、
良いか。後は、乾いたらどんな色になるのか、楽しみである。多分、凄い色の
ままなんだろうけど。
■ 2/12
ST250 EタイプSカスタマイズというバイクにサイドバッグを取り付ける作業を
した。写真があるので、別ページに。
■ 2/13
なんだか、 maillog のサイズがいつもの30倍以上の速さで育ってるので、何が
起きているのか調べてみたのだが、どうやら DOS アタック級のメール送信が来て
いるようである。初めのアクセスは以下のようなもの。
Feb 12 08:01:22 kamino postfix/smtpd[5766]: A528074006: reject: RCPT from cuda.t
ransact.bm[209.240.40.245]: 450 <nactatsuyoshibep@tatsuyoshi.net>: User unknown
in local recipient table; from=<> to=<nactatsuyoshibep@tatsuyoshi.net> proto=ESM
TP helo=<cuda.transact.bm>
そっから、
> grep nactatsuyoshibep maillog | wc -l
27054
な感じ。計算すると、１分間に16回きていることになる。送信元は
> grep nactatsuyoshibep maillog | cut -d" " -f10 | sort | uniq | wc -l
1271
と多岐に渡っているし。なんだかなぁ。
■ 2/14
昨日の続き。どうやら、数が増えてきているようである。
> grep nactatsuyoshibep maillog | cut -c-9 | uniq -c
136 Feb 12 08
118 Feb 12 09
110 Feb 12 10
136 Feb 12 11
134 Feb 12 12
136 Feb 12 13
191 Feb 12 14
267 Feb 12 15
470 Feb 12 16
444 Feb 12 17
545 Feb 12 18
381 Feb 12 19
667 Feb 12 20
788 Feb 12 21
766 Feb 12 22
1041 Feb 12 23
1110 Feb 13 00
1317 Feb 13 01
1264 Feb 13 02
1342 Feb 13 03
1434 Feb 13 04
1847 Feb 13 05
1982 Feb 13 06
2031 Feb 13 07
1987 Feb 13 08
2014 Feb 13 09
1991 Feb 13 10
1980 Feb 13 11
1895 Feb 13 12
2010 Feb 13 13
1938 Feb 13 14
2033 Feb 13 15
2096 Feb 13 16
2052 Feb 13 17
1984 Feb 13 18
2303 Feb 13 19
2283 Feb 13 20
2343 Feb 13 21
2399 Feb 13 22
1836 Feb 13 23
2134 Feb 14 00
2149 Feb 14 01
2697 Feb 14 02
2674 Feb 14 03
2956 Feb 14 04
3084 Feb 14 05
2883 Feb 14 06
3112 Feb 14 07
2889 Feb 14 08
2867 Feb 14 09
昨日見た感じでは、2000ぐらいで落ち着いていたので、ほっとけば良いかな、と
思ったのだけど、順調に増えてるみたいだし。そろそろ SH4 240MHz じゃきつく
なるんじゃないかなぁ。ちょっと困った。
見た感じ、どこかの SPAM 屋が From か Return-Path に
nactatsuyoshibep@tatsuyoshi.net を付けて、メールを大量に送信しているような
雰囲気なんだけど、こういった場合、どうしたら良いものなのかな。
■ 2/15
RedHat ES3 な環境で swap を使い切るぐらいメモリを消費するテストをしてみた。
予想では、プロセスが落ちるか、サーバが再起動すると思ってたのだけど、見事に
システムが固まってしまい、応答無しの状態。５分たっても、再起動する様子が
なかったので、仕方なく電源ボタンに手を掛けることにしたのだけど、せめて再起動
して欲しいもんだよなぁ。しょうがないのかもしれないけど。
■ 2/16
13, 14日の続き。14日の7時をピークにだんだんアクセス数が減る傾向になって
きた。といっても、まだ 1300アクセス/時間 ぐらいはきている。最悪、postfix を
止めようと思っていたのだけど、なんとかその危機も回避できた感じである。安い
BB ルータなので、細かなアクセス制御ができない。まともな機器を使っていたら、
postfix の停止の前に、海外からの smtp のアクセスを止める、という策が考え
られたのだけど。これから少し考えないとな…。
■ 2/17
台所の蛍光灯が点かなくなった。蛍光灯とグロー球を外して確認してみたら、
グロー球が黒くなってた。多分、原因はグロー球だと思って、ホームセンターで
２つ68円の安い奴を買ってきた。早速交換してみたが、やっぱり点かなかった。
蛍光灯に問題があるみたいである、という結論を出して、明日に新しい蛍光灯を
買いに行こうと思っていたのだけど、炊飯器の電気も入らないことに気がついた。
配電盤を見ると、１つが OFF になっていた。どうやら、冷蔵庫の上の掃除をして
いたときに、配電盤のスイッチを１つ切ってしまったようである。配電盤の切れて
いたスイッチを入れると、炊飯器は動き出した。が、蛍光灯は点いたり消えたり
している。試しに元のグロー球に戻してみたら、問題なく点いた。どうしようも
ない原因だったけどホームセンターのグロー球もどうしようもなかった。この
２つのせいで、無駄な時間を消費してしまった。
■ 2/18
自作 CGI の応答を tcpdump で眺めていたのだけど、どうもおかしな応答をして
いる。気になったので、 telnet で接続してみた。
[tatsuyoshi@naboo]$ telnet 192.168.0.2 80
Trying 192.168.0.2...
Connected to 192.168.0.2.
Escape character is '^]'.
GET /test/test.cgi HTTP/1.1
Host: 192.168.0.1
HTTP/1.1 200 OK
Date: Sun, 18 Feb 2007 05:18:29 GMT
Server: Apache
Connection: close
Transfer-Encoding: chunked
Content-Type: text/plain
3
-1
0
Connection closed by foreign host.
この CGI は -1 のみを返しているので、変だな、と思い、念のため ethereal で
確認してみると、3 の部分は HTTP chunked response になっていた。そういえば、
Transfer-Encoding: chunked の部分が気になる。というわけで調べてみた。この
ヘッダは HTTP 1.1 で拡張されたもので、 HTTP 1.1 クライアントは必ず実装を
しなければならないもの。データをチャンクして送信できる、らしい。なんだか、
形式はシンプルなのだけど、応答を見たいだけなので HTTP/1.0 にすることにして
対処しておいた。
■ 2/19
Linux サーバのバックアップを取る必要があったので、 USB の外付け HDD を接続
して、バックアップすることにした。HDD のフォーマットは FAT32 だったけど、
ま、良いかということで、 dd コマンドを使って領域のバックアップ。しかし、
数分でエラー終了。どうやら、サイズが 2GB のところで終了してしまったようで
ある。 dd コマンドは 2GB 以上扱えないのか、なんて単純に考えてしまって、
今度は dump コマンドでやったが、結果は同じ。そこで気が付いた。 FAT32 と
いうことを。何で早く気が付かなかったのだろう、と思いながら、外付け HDD を
ext2 でフォーマットしなおして、バックアップすることができた。 dd コマンド、
疑ってごめん。
■ 2/20
センサーライトを日曜日に設置したのだけど、どうも夜に誤動作をしているようで、
誰も居ないのにライトが点いている。雨が少し降ってきたせいなのか、5〜6m 離れた
所にある給湯器のせいなのか、センサーライトが安物なのか、が原因だと思うけど、
かなり明るく、お隣さんに迷惑なので、感度を最低まで下げることにした。で、
玄関の隙間から様子を見たのだけど、ちゃんと消えるようになった。なんだか、
便利なんだか、よくわからなくなってきた。
■ 2/21
Dovecot 1.0rc23 が出た。なんだか、文書がいくつか削除されたようなのだけど、
せっかく訳してあるので、削除するのももったいないなぁ、という気持ち。で、
dovecot-example.con をチェックしたら、いくつか抜けがあったので、その部分を
追加したら、更新しようかな、と。 version 1.0 のリリースは、まだまだ先の
感じだなぁ…。
■ 2/22
適当な大きさの中身がランダムなファイルが必要になった。で、 shell script を
使って作ってみたのだけど、動作がもの凄く遅い。使ったのは dd コマンドと、
/dev/random なのだけど、ちょっと時間を計測してみた。使った PC は、 Xeon 3G
のマシン。
[toyota@zonama]$ time /bin/dd if=/dev/random of=random bs=512 count=20
読み込んだブロック数は 0+20
書き込んだブロック数は 0+20
real 2m11.415s
user 0m0.000s
sys 0m0.010s
使い物にならないので、 urandom に代えてみた。
[toyota@zonama]$ time /bin/dd if=/dev/urandom of=urandom bs=512 count=20
読み込んだブロック数は 20+0
書き込んだブロック数は 20+0
real 0m0.003s
user 0m0.000s
sys 0m0.010s
なんとか使い物になる感じになった。 /dev/zero との比較を行ってみた。
[toyota@zonama]$ time /bin/dd if=/dev/zero of=urandom bs=512 count=20
読み込んだブロック数は 20+0
書き込んだブロック数は 20+0
real 0m0.002s
user 0m0.000s
sys 0m0.000s
ま、こんなもんかな、と言った感じ。とりあえず、 /dev/urandom を使うことに
した。
■ 2/23
昨日の続き。/dev/random を dd で使っていて、 dd コマンドのブロック数の数が
異なることに気が付いた。ちょっと、テストしてみた。
dd if=/dev/random of=random0 count=1
というコマンドの of を少し変えて、10回行ってみた。
[toyota@zonama]$ ls -l
合計 40
-rw-rw-r-- 1 toyota toyota 128 2月 23 10:34 random0
-rw-rw-r-- 1 toyota toyota 85 2月 23 10:34 random1
-rw-rw-r-- 1 toyota toyota 85 2月 23 10:34 random2
-rw-rw-r-- 1 toyota toyota 85 2月 23 10:34 random3
-rw-rw-r-- 1 toyota toyota 85 2月 23 10:34 random4
-rw-rw-r-- 1 toyota toyota 85 2月 23 10:34 random5
-rw-rw-r-- 1 toyota toyota 85 2月 23 10:34 random6
-rw-rw-r-- 1 toyota toyota 2 2月 23 10:34 random7
-rw-rw-r-- 1 toyota toyota 85 2月 23 10:35 random8
-rw-rw-r-- 1 toyota toyota 44 2月 23 10:35 random9
サイズが 512 にならない。試しに /dev/urandom を使ってみたら、全てちゃんと
512 になった。 /dev/random 使えないなぁ。ちょっと man 4 random で調べて
みると、 /proc/sys/kernel/random/ に情報があるらしい。ということで、上の
コマンドをもう１度やってみて、 entropy_avail の値を見てみることにした。
[toyota@zonama]$ cat /proc/sys/kernel/random/entropy_avail
1
1 になった。ほっとくと、 4096 になるのだけど、この entropy_avail を使い
切ってしまっているような感じである。あとは、ヒマをみつけて kernel の source
でも見るかな。
■ 2/24
さらに昨日の続き。デバイスに書き込んだ場合、どうなるかやってみた。まずは、
/dev/zero を ram ディスクに書いてみた。
[root@zonama]# dd if=/dev/zero of=/dev/ram1 count=20
読み込んだブロック数は 20+0
書き込んだブロック数は 20+0
[root@zonama]# od -x /dev/ram1
0000000 0000 0000 0000 0000 0000 0000 0000 0000
*
40000000
綺麗に書かれた。同じように /dev/random を使ってみた。
[root@zonama]# dd if=/dev/random of=/dev/ram1 count=20
読み込んだブロック数は 0+20
書き込んだブロック数は 2+1
[root@zonama]# od -x /dev/ram1
0000000 30e2 da69 4ba7 57cc e8ad f6c2 3a52 bae1
0000020 096e 269f 4318 79cb a00c 3424 a836 3b55
0000040 137d b75c 4b16 4e97 6e0c d7c3 2b5b 0a6b
〜snip〜
0002700 7702 3527 2a72 6d25 65ff 31da 1aa6 6285
0002720 0017 0000 0000 0000 0000 0000 0000 0000
0002740 0000 0000 0000 0000 0000 0000 0000 0000
*
40000000
駄目じゃん。ということは、ハードディスクなんかを適当に書き込む必要がある
ときは、 /dev/random を使っちゃいけない、ということか。知らずに使ってしまう
可能性があるなぁ。滅茶苦茶遅くて、気が付くかもしれないけど。今回の検証は
Red Hat ES3 で行いました。
関係ないけど、調べたら、ゾナマ・セコートだったんだ。ずっと、ゾマナ・セコート
だと思ってた。
■ 2/25
2/12 の続き。ウィンカーの配線をしようと、延長分のケーブルを作成し、接続
できるように両端にギボシ端子を装着し、準備万端で接続作業を始めたのだけど、
いざ接続しようとしたら、ギボシ端子の大きさが微妙に違うことが判明した。
仕方なく、そのサイズのギボシ端子を探しに行くことにした。ホームセンターに
行って探したが見つからず、オートバックスに行ってもない。店員にエーモンの
カタログに別サイズのギボシ端子があるか調べてもらったところ、ない、との
返事。仕方なく、混んでいる道を進んで NAPS に行ってきた。さすがに NAPS には
ありました。デイトナのもので、30セット入ったものが 1575円、防水スリーブを
使ったものが 20セットで 1785円。高いし、４セットで良いので、そんなに量が
あっても…、と悩んだ末、買わずに返ってきた。
このギボシ端子の規格って、決まっているのか調べてみたのだけど、それらしき
記述は見つからなかった。ただ、J.A.M. というところで、製作しているようで、
サイズが書いてあった。どうやら、端子が 0.5mm 程サイズが違うみたいである。
なんで、バイクはわざわざこのサイズを採用したのだろう。 NAPS で売っていた
デイトナのものにも書いてあったのだけど、 CA-103 という名前のギボシ端子の
ようである。
ということで、その型番で調べてみると、キタコが５セットで420円、というのを
扱っているらしい。これを注文してみようかな、と。しかし、来週の日曜日の
ツーリングには間に合うかどうか…。
■ 2/26
手元のノート PC である Libretto L5 の cygwin 環境で、configure スクリプトが
うまくいかない現象が、だいぶ前から出ていた。別にバリバリ開発する PC じゃ
ないし、そんなに困ってないので、放置していたのだけど、調べることにした。
で、色々実験していたら、 configure の最初の行、
#!/bin/sh
の指定を
#!/bin/bash
にすると、動き出した。ということで、 sh のファイルを見てみることにした。
$ ls -l /bin/sh
-rwx------+ 1 taku testg 451072 Dec 7 2005 /bin/sh
ということで、原因が判明した。単なるパーミッションの問題だったようである。
で、このファイルのオーナーは誰かと言うと、この PC の前の持ち主、である。
前の持ち主が元々 cygwin をインストールして、その後に私が使い出して、さらに
cygwin のアップデートなんかをしているので、ファイルの所有者がバイナリに
よって、混在している状態になっている。それが、今回の件を引き起こしたようで
ある。とりあえず、実行権限をつけて、問題がなくなった。やれやれ。
■ 2/27
昨日の続き。ちょっと気になることがあったので、調べてみることにした。今日は、
手元の別のサーバで。まず、
$ which sh
/usr/bin/sh
と、 /usr/bin/sh をまず探しに行くようである。 /usr/bin/sh と /bin/sh を
見てみることにした。
$ ls -li /usr/bin/sh
281474976752012 -rwxr-x---+ 1 たつよし Users 468480 Nov 16 13:11 /usr/bin/sh
$ ls -li /bin/sh
281474976752012 -rwxr-x---+ 1 たつよし Users 468480 Nov 16 13:11 /bin/sh
何故か、 i-node が同じなのである。 cygwin でこんなことできるのかな、と
思って、テストしてみた。
$ cd /tmp
$ touch test
$ ln test link
$ ls -li
total 0
6755399441102229 -rw-r--r-- 2 たつよし なし 0 Feb 27 23:40 link
6755399441102229 -rw-r--r-- 2 たつよし なし 0 Feb 27 23:40 test
なんだか、変な感じである。念のため、 test ファイルをメモ帳から編集して
保存し、 link ファイルをメモ帳で開いてみたら、ちゃんと test で編集した
内容になっている。 Windows XP でもハードリンクが扱えるんだ…。
■ 2/28
さらに昨日の続き。/usr/bin をエクスプローラーから見てみると、中身が空で
あった。気になったので、調べてみることにした。
$ ls -lid /usr/bin
281474976740543 drwxrwx---+ 2 たつよし Users 0 Nov 26 00:03 /usr/bin
$ ls -lid /bin
281474976740543 drwxrwx---+ 2 たつよし Users 0 Nov 26 00:03 /bin
つまり、 cygwin の環境は /bin と /usr/bin はハードリンクで実現している、
ということみたいである。昨日と同じように、テストしてみた。
$ cd /tmp
$ mkdir test
$ touch test/hoge
$ ln test link
ln: `test': hard link not allowed for directory
ということで、簡単にはできないようである。ln に -d オプションをつけて、
Administrator でやれば出来るかもしれないけど。Administrator ユーザなんて
ないので、また今度別の環境でやってみよう…。
|
