1/1
あけまして、おめでとうございます。
今年もよろしくお願いします。
1/2
Yahoo BB の電話権不要タイプを申し込んだ。で、28日にやっと NTT の工事が
完了したのだけど、同時に届くと思われる ADSL モデムが未だに届かない。でも、
利用料金支払申込書は、正月早々届いて、しっかりと請求だけはしれくれるようで
ある。なんというか、申し込み以外ですんなり事が運んだことがない。やっぱり、
Yahoo BB のようである。
1/3
一酸化炭素中毒の初期症状は頭痛、吐き気で、めまいがしてきたら危険らしい。
晦日に一酸化炭素中毒になってしまって、大変だったので調べてみた。最近、
ときどき頭頂部の頭痛が起きていたのは、一酸化炭素中毒が原因だったのかも
しれないなぁ…。
1/4
snmp 経由で CPU の使用率を取得しようと。調べた。
ssCpuRawUser .1.3.6.1.4.1.2021.11.50.0
ssCpuRawNice .1.3.6.1.4.1.2021.11.51.0
ssCpuRawSystem .1.3.6.1.4.1.2021.11.52.0
ssCpuRawIdle .1.3.6.1.4.1.2021.11.53.0
ssCpuRawWait .1.3.6.1.4.1.2021.11.54.0
ssCpuRawKernel .1.3.6.1.4.1.2021.11.55.0
ssCpuRawInterrupt .1.3.6.1.4.1.2021.11.56.0
が使えそうである。早速値の取得をしてみた。
[toyota@test]% ./snmpwalk rh9 -c public -v2c .1.3.6.1.4.1.2021.11
UCD-SNMP-MIB::ssIndex.0 = INTEGER: 1
UCD-SNMP-MIB::ssErrorName.0 = STRING: systemStats
UCD-SNMP-MIB::ssSwapIn.0 = INTEGER: 0
UCD-SNMP-MIB::ssSwapOut.0 = INTEGER: 0
UCD-SNMP-MIB::ssIOSent.0 = INTEGER: 2
UCD-SNMP-MIB::ssIOReceive.0 = INTEGER: 4
UCD-SNMP-MIB::ssSysInterrupts.0 = INTEGER: 106
UCD-SNMP-MIB::ssSysContext.0 = INTEGER: 177
UCD-SNMP-MIB::ssCpuUser.0 = INTEGER: 21
UCD-SNMP-MIB::ssCpuSystem.0 = INTEGER: 0
UCD-SNMP-MIB::ssCpuIdle.0 = INTEGER: 78
UCD-SNMP-MIB::ssCpuRawUser.0 = Counter32: 2077677
UCD-SNMP-MIB::ssCpuRawNice.0 = Counter32: 2970
UCD-SNMP-MIB::ssCpuRawSystem.0 = Counter32: 14370
UCD-SNMP-MIB::ssCpuRawIdle.0 = Counter32: 7521188
これが、 Linux Kernel 2.6 相手だとこうなる(上のは Linux Kernel 2.4 相手)。
[toyota@test]% ./snmpwalk fc4 -c public -v2c .1.3.6.1.4.1.2021.11
UCD-SNMP-MIB::ssIndex.0 = INTEGER: 1
UCD-SNMP-MIB::ssErrorName.0 = STRING: systemStats
UCD-SNMP-MIB::ssSwapIn.0 = INTEGER: 0
UCD-SNMP-MIB::ssSwapOut.0 = INTEGER: 0
UCD-SNMP-MIB::ssIOSent.0 = INTEGER: 6
UCD-SNMP-MIB::ssIOReceive.0 = INTEGER: 2
UCD-SNMP-MIB::ssSysInterrupts.0 = INTEGER: 7
UCD-SNMP-MIB::ssSysContext.0 = INTEGER: 2
UCD-SNMP-MIB::ssCpuUser.0 = INTEGER: 0
UCD-SNMP-MIB::ssCpuSystem.0 = INTEGER: 0
UCD-SNMP-MIB::ssCpuIdle.0 = INTEGER: 99
UCD-SNMP-MIB::ssCpuRawUser.0 = Counter32: 623999
UCD-SNMP-MIB::ssCpuRawNice.0 = Counter32: 469
UCD-SNMP-MIB::ssCpuRawSystem.0 = Counter32: 296376
UCD-SNMP-MIB::ssCpuRawIdle.0 = Counter32: 623529551
UCD-SNMP-MIB::ssCpuRawWait.0 = Counter32: 926973
UCD-SNMP-MIB::ssCpuRawKernel.0 = Counter32: 287218
UCD-SNMP-MIB::ssCpuRawInterrupt.0 = Counter32: 2351
UCD-SNMP-MIB::ssIORawSent.0 = Counter32: 281923678
UCD-SNMP-MIB::ssIORawReceived.0 = Counter32: 420810284
UCD-SNMP-MIB::ssRawInterrupts.0 = Counter32: 3134569933
UCD-SNMP-MIB::ssRawContexts.0 = Counter32: 142361867
UCD-SNMP-MIB::ssCpuRawSoftIRQ.0 = Counter32: 6807
UCD-SNMP-MIB::ssRawSwapIn.0 = Counter32: 0
UCD-SNMP-MIB::ssRawSwapOut.0 = Counter32: 257
2.6 の結果を CPU 部分だけ切り出して、 /proc/stat と比較。
[toyota@test]% ./snmpwalk localhost -c public -v2c .1.3.6.1.4.1.2021.11 |
grep Cpu ; cat /proc/stat | head -1
UCD-SNMP-MIB::ssCpuUser.0 = INTEGER: 0
UCD-SNMP-MIB::ssCpuSystem.0 = INTEGER: 0
UCD-SNMP-MIB::ssCpuIdle.0 = INTEGER: 99
UCD-SNMP-MIB::ssCpuRawUser.0 = Counter32: 624021
UCD-SNMP-MIB::ssCpuRawNice.0 = Counter32: 469
UCD-SNMP-MIB::ssCpuRawSystem.0 = Counter32: 296404
UCD-SNMP-MIB::ssCpuRawIdle.0 = Counter32: 623569646
UCD-SNMP-MIB::ssCpuRawWait.0 = Counter32: 926973
UCD-SNMP-MIB::ssCpuRawKernel.0 = Counter32: 287244
UCD-SNMP-MIB::ssCpuRawInterrupt.0 = Counter32: 2352
UCD-SNMP-MIB::ssCpuRawSoftIRQ.0 = Counter32: 6808
cpu 624021 469 287244 623569646 926973 2352 6808 0
ssCpuRawSystem だけ、ちょっと不明である。組み合わせ計算をしてみると、
ssCpuRawKernel + ssCpuRawInterrupt + ssCpuRawSoftIRQ
の和であるようだ。この値から CPU 使用率を求める、が、ssCpuIdle を使えば
その必要がないような気がしてきた。明日にでも検証してみる。
1/5
snmp の .1.3.6.1.4.1.2021.11.11.0 ssCpuIdle の値を検証。更新間隔が不明
なのと、値がいまいち不明なのと。今日の環境はLinux Kernel 2.4 な環境。
[toyota@test]% while 1
while ? ./snmpwalk localhost -c public -v2c .1.3.6.1.4.1.2021.11.11.0 >> ret
while ? sleep 5
while ? end
こんな感じで２時間半ほど放置して、見てみた。で、結果は。
[toyota@test]% uniq -c ret
344 UCD-SNMP-MIB::ssCpuIdle.0 = INTEGER: 81
651 UCD-SNMP-MIB::ssCpuIdle.0 = INTEGER: 80
715 UCD-SNMP-MIB::ssCpuIdle.0 = INTEGER: 79
128 UCD-SNMP-MIB::ssCpuIdle.0 = INTEGER: 78
だと。なんだかやっぱり変な値。変化も極端に少ないし。このときの vmstat の値は
procs memory swap io system
cpu
r b w swpd free buff cache si so bi bo in cs us sy id
3 0 0 0 167920 72280 122424 0 0 0 2 108 222 48 0 52
このぐらいの値で、大体 Idle は 50% 前後だったのだけど。 snmp の返してくる
値が、どこから由来しているものなのか、やっぱり不明。急激な変化がないので、
起動してからの値というのも考えられるし。
ということで、 net-snmp の source を見てみた。で、
case cpuidle:
return (100 * didl / ddiv);
こんな感じのみたい。さらに、
didl = cpu_idl;
ddiv = duse + dsys + didl;
なので、時間的差分をとっているわけではなく、起動してからこれまでの値を
出しているようである。つまり、ここ１０秒とか、リアルタイムの CPU 使用率を
出す場合は
ssCpuUser
ssCpuSystem
ssCpuIdle
の値を使うのではなく、
ssCpuRawUser
ssCpuRawNice
ssCpuRawSystem
ssCpuRawIdle
ssCpuRawWait
ssCpuRawKernel
ssCpuRawInterrupt
の値を使わなければいけないようである。
1/6
snmp の .1.3.6.1.4.1.2021.11.53.0 ssCpuRawIdle の更新間隔を調べる。
[toyota@test]% while 1
while ? ./snmpwalk localhost -c public -v2c .1.3.6.1.4.1.2021.11.53.0
>> ret
while ? sleep 1
while ? end
こんな感じで15分ほど放置して、見てみた。で、結果を取り出す。
[toyota@test]% uniq -c ret | sort -n | cut -c-7 | uniq -c
29 5
125 6
5〜6秒と、なんだか中途半端な結果。 snmp なので、更新をかけることができる
はず。時間があったら、やってみよう、と思っていたが、調べてみると、更新する
SetRequest は、エージェント側で情報の更新をするのではなくて、マネージャー側
から設定するものだった。あとは、エージェントの設定か…。ちょっと net-snmp の
source みたけど、私には時間がかかりそう。
1/7
snmp の .1.3.6.1.4.1.2021.11.53.0 ssCpuRawIdle の更新間隔の件、 net-snmp の
source を見てみた。どうやらキャッシュ時間があって、 CACHE_TIMEOUT という
名前で宣言しているらしい。
[toyota@test]% grep -r -w CACHE_TIMEOUT *
mibgroup/ucd-snmp/diskio.c:#define CACHE_TIMEOUT 10
mibgroup/ucd-snmp/diskio.c: if (disknr == cache_disknr && cache_time + CACHE
_TIMEOUT > now) {
mibgroup/ucd-snmp/diskio.c: if (cache_time + CACHE_TIMEOUT > now) {
mibgroup/ucd-snmp/diskio.c: if (cache_time + CACHE_TIMEOUT > now) {
mibgroup/ucd-snmp/diskio.c: if (cache_time + CACHE_TIMEOUT > now) {
mibgroup/ucd-snmp/diskio.c: if (cache_time + CACHE_TIMEOUT > now) {
mibgroup/ucd-snmp/diskio.c: if (ps_disk != NULL && cache_time + CACHE_TIMEOU
T > now) {
mibgroup/ucd-snmp/vmstat.c:#define CACHE_TIMEOUT 5
mibgroup/ucd-snmp/vmstat.c: if (cache_time + CACHE_TIMEOUT < now) {
という感じで、ディスク関係は10秒、/proc/stat, /proc/vmstat からの値は5秒で
設定されているようである。昨日の結果が5〜6秒になったのは
time(&now);
if (cache_time + CACHE_TIMEOUT < now) {
と、time 関数を使っていて秒単位しか値の取得ができないため。 5.5秒でも5秒
扱いになり、6秒経過しないと新しい値を読み込みにいかない。で、この値は
compile してしまうと、変更できないので、３秒おきに取得したい場合は source
code の変更を行う必要がある。ちょっと困ったな…。
1/8
そろそろサーバ構成を変更しようと、色々と考えているのだけど、なんとなく
良いアイディアが浮かばない。今 web サーバと mail サーバをやっている LAN-iCN2
は、 web サーバだけに専念させて、 mail サーバを他の PC にしたいのだけど、
どの PC が良いのかな、と悩んでいる状態。簡単に考えると C3 1GHz の PC なの
だけど、それじゃあまり早くなった感じがしないだろうし、どうしようかな、と
いったところ。もうしばらく悩むと思う。
1/9
PCI BRC-AP04 のファームウェアを解析した。
って、前に解析してたし…。バージョンが違うから良いか。それにしても、半年
以上更新してなかったのね。
1/10
NTT Web Caster X400V のファームウェアを解析した。
jffs2 周りでちょっと苦労したかな。情報が少ないからね。
1/11
とあるページを上書きして更新してしまったようで、前のデータが消えてしまった。
前のデータは 2005年5月1日に作成して、2005年12月5日に上書きしてしまった。
さすがに１ヶ月も経つと google さんのキャッシュも残っていない。検索エンジン
では Ask が古いデータを持ってたけど、キャッシュが見られるエンジンじゃないし。
最後の頼み、 Internet Archive で検索したけど駄目。２月まではごっそりと浚って
いったようなのだけど、その後はない。素直に書き直せ、ということのようである。
あー面倒だ。
1/12
モペッド、ペダルがある原動機付き自転車のことなんだけど、これを３輪にして、
軸距(車輪の中心と車輪中心の距離)を 50cm 以上に広げてミニカーにしようと
考えてみた。ヘルメットはいらないし、いざとなったらペダルでこげるし、見た目は
すごく悪いけど、面白いかもしれないなぁ…。でも、デフがないのに軸距が 50cm
もあると、コーナーでタイヤが鳴くだろうし、車体が倒れないので、コーナーは
ダメダメになるのか。乗ってみないとわからないけど、微妙かもなぁ。
1/13
kernel 2.6 の /proc/stat １行目の user, nice, system, idle, iowait なんかは
unsigned long long int で宣言されている。しかし、net-snmp は unsigned long
で宣言しているので、ちょっと心配。で、実際に PC を起動してからどのぐらいで
buffer overflow が発生するのか、計算してみた。
unsigned long int の最大値は 4294967295 。この値は 1/100 秒として扱われる
ので、 42949673 秒。分に変換すると 715828 分。時間に変換すると 11930 時間。
日に変換すると 497 日ということになる。結構微妙な数字。家のメールサーバとか、
平気で１年とか動いているしなぁ…。
net-snmp の source code はこんな感じ。省略してあるけど。
sscanf(b, "cpu %llu %llu %llu %llu %llu %llu %llu", &cusell,
&cicell, &csysll, &cidell, &ciowll, &cirqll, &csoftll);
*cide = (unsigned long)cidell;
cidell に 4294967295 + 1 が入ると cide は 0 になるので、差分を出して CPU の
使用率を出しているときは、１回だけとんでもない値になる。と、思ったのけど、
それを使用しているプログラムの計算のときに使っている変数が unsigned かどうか
でも挙動が変わるし、int なんかで取ってたら、どうなるかわからないなぁ…。
ま、うまくいけば３年ぐらい発生しないのだけどね。
1/14
LINKSYS RV082-JP のファームウェアを解析した。
このルータ、安ければ欲しいかも。
1/15
アンテナ倒れる。テレビなんかほとんど見ないけど、アンテナが上から落ちてきたら
怖いのですぐに修理した。
1/16
IO-DATA WN-WAPG/R のファームウェアを解析した。
Atheros の CPU みたい。
せっかく解析したのに、新しいファームが出るし…。
1/17
とあるルータのファームウェアを眺めていたら sqsh で始まるイメージが出てきた。
何だろう、と思って調べてみたら、どうやら SquashFS というものらしい。
http://squashfs.sourceforge.net/
この辺から情報を見てみたのだけど、このイメージを読み込むには Kernel に
patch を当てて作り直す必要があるみたい。面倒だなぁ…。今度時間があったら、
やってみよう。
1/18
SquashFS の読み込みをやってみることにした。まず、最新版の kernel 2.4.32 を
ダウンロードしてきた。それと、 squashfs もダウンロードしてきた。
http://sourceforge.net/project/showfiles.php?group_id=63835
の辺りから。さっそく squashfs を解凍。
[toyota@kashyyyk]% tar xvfz squashfs2.2-r2.tar.gz
中を見たけど 2.4.31 の patch しかないようである。でも、多分大丈夫でしょう。
次に kernel の解凍。
[toyota@kashyyyk]% tar xvfj ../linux-2.4.32.tar.bz2
[toyota@kashyyyk]% cd linux-2.4.32
patch を当てる。
[toyota@kashyyyk]% patch -p1 < ../squashfs2.2-r2/linux-2.4.31/squashfs2.2-patch
patching file fs/Config.in
patching file fs/Makefile
patching file fs/squashfs/inode.c
patching file fs/squashfs/Makefile
patching file include/linux/fs.h
patching file include/linux/squashfs_fs.h
patching file include/linux/squashfs_fs_i.h
patching file include/linux/squashfs_fs_sb.h
patching file init/do_mounts.c
patching file lib/Config.in
問題なかった。で kernel の作成。
[toyota@kashyyyk]% make menuconfig
ここで、メーニューの中にちゃんと squashfs が出てきた。
Squashed file system support (NEW)
という感じ。これをチェックして、その他も環境に合わせて作成。
[toyota@kashyyyk]% make dep
[toyota@kashyyyk]% make bzImage
なんか、 kernel コンパイルするの久しぶり。で、起動してみた。mount で squashfs
が扱えるようになった。でも、あんまり使わない、というか、今回が最初で最後だと
思う。
1/19
年末計測した /proc/stat と /proc/uptime の IDLE TIME の比較を Cygwin で
やってみた。
$ cat /proc/stat | head -1 ; cat /proc/uptime
cpu 211875 0 275906 26873015
27360.82 26873.01
お、ほぼ同じのようである。が、桁数がなんか違うなぁ。
1/20
風邪でダウン中。IMAP のサーバとして Dovecot というのが流行っているらしい。
見る限り便利そうなので、今度入れてみようかと思うのだが、Courier-IMAP の
データがそのまま読めるかどうかちょっと心配。入れる前に実験してみよう。
1/21
風邪で寝込んでます。すみません。
1/22
 
メールサーバの機能を kamino[LAN-iCN2 - SH4 233MHz - Linux] から naboo[C3
1GHz - OpenBSD] に移行しようかと。現在 naboo は特定ドメインの web サーバを
やっているのだけど、こいつは止めても影響ないので都合が良い。ただし、OS の
OpenBSD が 3.4 なので 3.8 に Upgrade して Dovecot での動作確認をしてから、
移行しないといけない。結構面倒だなぁ。今週中を目標にやってみようかな。
1/23
DELL PowerEdge 1850 に RedHat9 をインストールしたのだけど、ネットワークが
認識していない様子。調べてみたら、intel 82541 PRO/1000 MT Desktop Adapter
を搭載しているらしい。ということで、intel のサイトからドライバをダウンロード
してくる。が、
「Linux* カーネル2.2.x, 2.4.x, 2.6.x(32 ビット、64 ビット) 基本ドライバ」
からダウンロードしようとすると、２つのバージョンが出てくる。
e1000-4.3.15.tar.gz ギガビット・アダプタ Linux* 基本ドライバ 4.3.15
e1000-6.3.9.tar.gz Linux* Gigabit Adapter Base Driver 6.3.9
詳しい説明もないし、違いがよくわからない。とりあえず、新しい 6.3.9 の
バージョンをダウンロードしてきて、実験することに。
[toyota@pe1850]% tar xvfz e1000-6.3.9.tar.gz
[toyota@pe1850]% cd e1000-6.3.9/src
[toyota@pe1850]% make install
[toyota@pe1850]% insmod e1000
[toyota@pe1850]% ifconfig eth0 up
[toyota@pe1850]% ifconfig
ネットワークが使えるようになった。6.3.9 で問題ないようである。それにしても、
フロッピーディスクなんて久しぶりに使った気がした。
1/24
Let's Note CF-Y4 がやってきた。早速 Linux を入れなくてはいけないのだけど、
既にインストールされている Windows XP Professional がもったいないので(と
言っても、私のじゃないけど)、 Dual Boot にしてしまおうかと。しかし、手元には
Partition Magic 的なソフトウエアなんてないし、今入っている XP Pro を再
インストールするような手間もかけたくない。どうしようかな、と調べてみたら
Ntfsresize http://mlf.linux.rulez.org/mlf/ezaz/ntfsresize.html
なるものがあるらしい。さらに Knoppix にはそれを使った QTParted が格納されて
いるらしいので、使ってみることにした。
Knoppix のダウンロード。とりあえず、日本語版で。
[toyota@fc_4]% wget http://www.dnsbalance.ring.gr.jp/archives/linux/knoppix/iso
/knoppix_v4.0.2CD_20050923-20051116+IPAFont.iso
CD の作成(on Fedora Core 4)。
[toyota@fc_4]% cdrecord -scanbus
Cdrecord-Clone 2.01-dvd (i686-pc-linux-gnu) Copyright (C) 1995-2004 Jorg Schill
ing
Note: This version is an unofficial (modified) version with DVD support
Note: and therefore may have bugs that are not present in the original.
Note: Please send bug reports or support requests to
http://bugzilla.redhat.com/bugzilla
Note: The author of cdrecord should not be bothered with problems in this versi
on.
scsidev: 'ATA'
devname: 'ATA'
scsibus: -2 target: -2 lun: -2
Linux sg driver version: 3.5.27
Using libscg version 'schily-0.8'.
cdrecord: Warning: using inofficial libscg transport code version
(schily - Red Hat-scsi-linux-sg.c-1.83-RH '@(#)scsi-linux-sg.c
1.83 04/05/20 Copyright 1997 J. Schilling').
scsibus0:
0,0,0 0) 'PHILIPS ' 'CDRW/DVD SCB5265' 'TD15' Removable CD-ROM
0,1,0 1) *
0,2,0 2) *
0,3,0 3) *
0,4,0 4) *
0,5,0 5) *
0,6,0 6) *
0,7,0 7) *
とりあえず、実行してみた。
[toyota@fc_4]% cdrecord -v speed=4 dev=0,0,0 knoppix_v4.0.2CD_20050923-20051116
+IPAFont.iso
cdrecord: No write mode specified.
cdrecord: Asuming -tao mode.
cdrecord: Future versions of cdrecord may have different drive dependent defaul
ts.
cdrecord: Continuing in 5 seconds...
Cdrecord-Clone 2.01-dvd (i686-pc-linux-gnu) Copyright (C) 1995-2004 Jorg Schill
ing
Note: This version is an unofficial (modified) version with DVD support
Note: and therefore may have bugs that are not present in the original.
Note: Please send bug reports or support requests to
http://bugzilla.redhat.com/bugzilla
Note: The author of cdrecord should not be bothered with problems in this versi
on.
TOC Type: 1 = CD-ROM
scsidev: '0,0,0'
scsibus: 0 target: 0 lun: 0
cdrecord: No such file or directory. Cannot open '/dev/pg0'. Cannot open
SCSI driver.
cdrecord: For possible targets try 'cdrecord -scanbus'.
cdrecord: For possible transport specifiers try 'cdrecord dev=help'.
なんだか、エラーをもらってしまった。
[toyota@fc_4]% ls -l /dev/pg*
ls: /dev/pg*: そのようなファイルやディレクトリはありません
だそうである。IDE の SCSI エミュレーションをしていない`ようなので、突っ込んで
みる。
[toyota@fc_4]% modprobe ide-scsi
これで cdrecord を実行したが、現象変わらず。調べたけど、起動時の grub なんかで
hda=ide-scsi
と指定して起動してやらないと駄目らしい。ちょっと再起動できない状態なので、
Fedora Core 4 の PC で焼くのはあきらめて、 B's GOLD8 on CF-Y4 で CD を焼く
ことにした。続きは明日。
1/25
CD が焼けたので、 NTFS をゴニョゴニョやる。とりあえず、60G ある領域を 12G
ぐらいにしようとしていたのだけど、ふと思い出した。起動させるパーティションは
先頭 8G にないといけないような。そんなことは、昔の出来事で、今は対策されている
ような気もするけど。後からインストールする Linux がメインなので、起動しないと
嫌だしなぁ…。とりあえずやってみるだけやってみる。
Knoppix から起動して、qtparted を実行した。思ったより使いやすい。50G 以上ある
Windows XP の領域を 12G に減量。本当にうまくいくか、ちょっと心配だけど、
やってみた。最後の確定をすると
「全ての変更を確定します.注意,全てのデータは消えます!」
ってメッセージが出たんだけど…。かなり不安になりながらも、やってみた。約２分で
終了。不安になるぐらい早い。再起動をしてみた。お、問題なく XP があがりそう…、
と思ったら CHKDSK が走ってる。再起動がもう１度かかって、無事起動。 Partition
Magic なんていらないじゃん…。空けた領域に、訳あって RedHat9 をインストール
したけど、問題なくインストールできた。音が出ないとか、ちょっと動作に不足は
あるけど音なんて使わないので、よしとする。
1/26
OpenBSD 3.4 から 3.8 へアップデート計画。まずは、 CD 作りから。
[toyota@kashyyyk]% mkdir openbsd
[toyota@kashyyyk]% cd openbsd
[toyota@kashyyyk]% wget -r -l 1 ftp://ftp.jp.openbsd.org/pub/OpenBSD/3.8/i386
なんだか、掘り下げて読みに行ってくれない。仕方ない。http でダウンロード
する。
[toyota@kashyyyk]% wget -r -l 1 http://ftp.jp.openbsd.org/pub/OpenBSD/3.8/i386
これでダウンロード。関係ない話だけど、 OpenBSD 3.7 から Zaurus に対応
したんだ。知らなかった。
[toyota@kashyyyk]% mv ftp.jp.openbsd.org/pub/OpenBSD/3.8 ./
[toyota@kashyyyk]% rm -rf ftp.jp.openbsd.org
[toyota@kashyyyk]% rm 3.8/index.html
[toyota@kashyyyk]% rm 3.8/i386/index.txt
[toyota@kashyyyk]% rm -rf 3.8/i386/index.html*
いらないファイルを削除したので、iso イメージの作成を行う。そうそう、この
作業を行っている PC は家にある RedHat9 な PC 。
[toyota@kashyyyk]% mkisofs -l -J -r -o openbsd38.iso -b i386/cdrom38.fs -V "OpenBSD3.8" 3.8
158M ほどの iso イメージが出来た。本当はインストールしない X 周りのものを
削っても良かったのだけど。そうしたら、シングル CDに入りそうだな…。
[toyota@kashyyyk]% cdrecord -v speed=4 dev=0,0,0 openbsd38.iso
書き込み完了。起動できるかチェックしたが、問題なし。試しに仕事場に持って
いって、 Let's note CF-Y4 にインストールしてみたけど、問題なし。インストールの
方法は、昔やった方法とほとんど変わってないし。
1/27
naboo[C3 1GHz - OpenBSD] の OpenBSD を update しようと、モニタ出力を切り替え
てみた。が、切り替わらない。ダメダメ切り替え器 RATOC REX-410U がうまく
切り替えてくれないみたい。結局、切り替え器の後の線を抜いたり刺したりと、
切り替え器の意味がないことをやっているのだけど。良い切り替え器でも買おうか
なぁ…。結構高いんだよなぁ。そんなんで、 update は後日になった。
1/28
naboo[C3 1GHz - OpenBSD] の OpenBSD が入った PC 、モニタを繋ぎ変えたら、
怪しげなメッセージが出ていた。 messages を見ると、
Jan 25 23:00:22 naboo /bsd: wd0(pciide0:0:0): timeout
Jan 25 23:00:22 naboo /bsd: type: ata
Jan 25 23:00:22 naboo /bsd: c_bcount: 2048
Jan 25 23:00:22 naboo /bsd: c_skip: 0
Jan 25 23:00:22 naboo /bsd: pciide0:0:0: bus-master DMA error: missing interrupt
, status=0x61
Jan 25 23:00:22 naboo /bsd: wd0a: device timeout reading fsbn 330712 of 330712-3
30715 (wd0 bn 330775; cn 328 tn 2 sn 25), retrying
Jan 25 23:00:22 naboo /bsd: wd0: soft error (corrected)
という状況。ハードディスクやばいかな…。さらに調べると、去年の１１月から
このメッセージが出ていて、合計８回に及んでいた。fsck で持ち直すかなぁ。
とりあえず、再起動して fsck 。続きは明日に。
1/29
OpenBSD 3.8 へアップグレード。長くなったので、別ページに。
1/30
OpenBSD 3.8 へアップグレードした。Apache が 1.3.29 だったので、アップグレード
できたのかちょっと心配だったのだけど、ファイルの日付を確認したら、ちゃんと
アップグレードできているみたい。さっそく Patch を当てるので、 source を
ダウンロードしてきた。
[toyota@naboo]% cd /usr
[toyota@naboo]% mv src src3_4
[toyota@naboo]% mkdir src
[toyota@naboo]% cd /tmp
[toyota@naboo]% wget ftp://ftp.jp.openbsd.org/pub/OpenBSD/3.8/src.tar.gz
[toyota@naboo]% wget ftp://ftp.jp.openbsd.org/pub/OpenBSD/3.8/sys.tar.gz
[toyota@naboo]% cd /usr/src
[toyota@naboo]% tar xvfz /tmp/src.tar.gz
[toyota@naboo]% tar xvfz /tmp/sys.tar.gz
といった感じで展開。 Patch もダウンロードしてきて、 make した。ついでに、
kernel もカスタムし直して。あとは、メール周りのテストをしないと。
1/31
OpenBSD 3.8 に Dovecot のインストール。最新版の Dovecot をダウンロードして
きた。
[toyota@naboo]% wget http://www.dovecot.org/releases/dovecot-1.0.beta2.tar.gz
解凍して、 configure オプションの確認。
[toyota@naboo]% tar xvfz dovecot-1.0.beta2.tar.gz
[toyota@naboo]% cd dovecot-1.0.beta2
[toyota@naboo]% ./configure --help
configure オプションの確認。ipv6 は使わないと思うので、無効にして、ぐらい
かな。認証周りは、未だ決めてないので、このまま。
[toyota@naboo]% ./configure --disable-ipv6
どうやら PAM 周りの環境はなくて、弾かれたみたい。
[toyota@naboo]% make
[toyota@naboo]% su
[root@naboo]# make install
無事に /usr/local/sbin の下にインストールされたみたい。眠いし体調が良く
ないので、続きは明日。
|
