てきとー管理者にっき！

近所のデパートに出かけたら「asimo」が展示されていた。

動いているところを見たかったが、展示のみだった。
※もしかすると、動かしたかも？？

IBM zSeries 890

いつかは、こんなサーバを触ってみたい・・・・

今週、サーバ6台を横浜方面のデータセンタに納品してきました。
今回も全てLinuxです。
全てのサービスの設定は完了していませんが、ラックにマウントした段階で「パチリ」と記念撮影。

初期不良で1台のサーバに不具合が出てて、作業が進みません！！

※今回、設置したデータセンタは初めて行きましたが、サーバルームは結構「暑かった」です。
　日頃使ってるデータセンタのほうが良いですね。
　設備も新しいし、サーバにもやさしい環境だし・・・・。

前々から行おうと思っていた、歴代の玄箱のベンチマーク。

使うtoolは「Dhrystone」を使ってみた。

※使い方は「Think IT」を参考にしてみた。

今回のベンチ対決は「玄箱」vs「玄箱HG」vs「玄箱PRO」
全てFedora8にて行い、ループ回数を100万回とした。

結果は次の通りです。

■玄箱
++++++++++++++++++++++++++++++++++++++++++++++++++++++
# make
Running dhrystone (Level 1 optimization, without registers)
./dhrystone
Dhrystone(1.1) time for 1000000 passes = 5
This machine benchmarks at 194174 dhrystones/second
./dhrystone
Dhrystone(1.1) time for 1000000 passes = 5
This machine benchmarks at 194174 dhrystones/second
./dhrystone
Dhrystone(1.1) time for 1000000 passes = 5
This machine benchmarks at 194174 dhrystones/second

Running dhrystone (Level 1 optimization, with registers)
./dhrystoneR
Dhrystone(1.1) time for 1000000 passes = 4
This machine benchmarks at 214592 dhrystones/second
./dhrystoneR
Dhrystone(1.1) time for 1000000 passes = 4
This machine benchmarks at 214592 dhrystones/second
./dhrystoneR
Dhrystone(1.1) time for 1000000 passes = 4
This machine benchmarks at 214592 dhrystones/second

Running dhrystone (Level 2 optimization, without registers)
./dhrystoneO
Dhrystone(1.1) time for 1000000 passes = 2
This machine benchmarks at 383141 dhrystones/second
./dhrystoneO
Dhrystone(1.1) time for 1000000 passes = 2
This machine benchmarks at 381679 dhrystones/second
./dhrystoneO
Dhrystone(1.1) time for 1000000 passes = 2
This machine benchmarks at 381679 dhrystones/second

Running dhrystone (Level 2 optimization, with registers)
./dhrystoneRO
Dhrystone(1.1) time for 1000000 passes = 2
This machine benchmarks at 381679 dhrystones/second
./dhrystoneRO
Dhrystone(1.1) time for 1000000 passes = 2
This machine benchmarks at 381679 dhrystones/second
./dhrystoneRO
Dhrystone(1.1) time for 1000000 passes = 2
This machine benchmarks at 383141 dhrystones/second

++++++++++++++++++++++++++++++++++++++++++++++++++++++

■玄箱HG
++++++++++++++++++++++++++++++++++++++++++++++++++++++
# make
Running dhrystone (Level 1 optimization, without registers)
./dhrystone
Dhrystone(1.1) time for 1000000 passes = 3
This machine benchmarks at 258397 dhrystones/second
./dhrystone
Dhrystone(1.1) time for 1000000 passes = 3
This machine benchmarks at 259067 dhrystones/second
./dhrystone
Dhrystone(1.1) time for 1000000 passes = 3
This machine benchmarks at 258397 dhrystones/second

Running dhrystone (Level 1 optimization, with registers)
./dhrystoneR
Dhrystone(1.1) time for 1000000 passes = 3
This machine benchmarks at 285714 dhrystones/second
./dhrystoneR
Dhrystone(1.1) time for 1000000 passes = 3
This machine benchmarks at 286532 dhrystones/second
./dhrystoneR
Dhrystone(1.1) time for 1000000 passes = 3
This machine benchmarks at 286532 dhrystones/second

Running dhrystone (Level 2 optimization, without registers)
./dhrystoneO
Dhrystone(1.1) time for 1000000 passes = 1
This machine benchmarks at 510204 dhrystones/second
./dhrystoneO
Dhrystone(1.1) time for 1000000 passes = 1
This machine benchmarks at 510204 dhrystones/second
./dhrystoneO
Dhrystone(1.1) time for 1000000 passes = 1
This machine benchmarks at 510204 dhrystones/second

Running dhrystone (Level 2 optimization, with registers)
./dhrystoneRO
Dhrystone(1.1) time for 1000000 passes = 1
This machine benchmarks at 510204 dhrystones/second
./dhrystoneRO
Dhrystone(1.1) time for 1000000 passes = 1
This machine benchmarks at 510204 dhrystones/second
./dhrystoneRO
Dhrystone(1.1) time for 1000000 passes = 1
This machine benchmarks at 510204 dhrystones/second
++++++++++++++++++++++++++++++++++++++++++++++++++++++

■玄箱PRO
++++++++++++++++++++++++++++++++++++++++++++++++++++++
# make
Running dhrystone (Level 1 optimization, without registers)
./dhrystone
Dhrystone(1.1) time for 1000000 passes = 5
This machine benchmarks at 185873 dhrystones/second
./dhrystone
Dhrystone(1.1) time for 1000000 passes = 5
This machine benchmarks at 185528 dhrystones/second
./dhrystone
Dhrystone(1.1) time for 1000000 passes = 5
This machine benchmarks at 185873 dhrystones/second

Running dhrystone (Level 1 optimization, with registers)
./dhrystoneR
Dhrystone(1.1) time for 1000000 passes = 4
This machine benchmarks at 205338 dhrystones/second
./dhrystoneR
Dhrystone(1.1) time for 1000000 passes = 4
This machine benchmarks at 205338 dhrystones/second
./dhrystoneR
Dhrystone(1.1) time for 1000000 passes = 4
This machine benchmarks at 205761 dhrystones/second

Running dhrystone (Level 2 optimization, without registers)
./dhrystoneO
Dhrystone(1.1) time for 1000000 passes = 3
This machine benchmarks at 327868 dhrystones/second
./dhrystoneO
Dhrystone(1.1) time for 1000000 passes = 3
This machine benchmarks at 326797 dhrystones/second
./dhrystoneO
Dhrystone(1.1) time for 1000000 passes = 3
This machine benchmarks at 326797 dhrystones/second

Running dhrystone (Level 2 optimization, with registers)
./dhrystoneRO
Dhrystone(1.1) time for 1000000 passes = 3
This machine benchmarks at 327868 dhrystones/second
./dhrystoneRO
Dhrystone(1.1) time for 1000000 passes = 3
This machine benchmarks at 327868 dhrystones/second
./dhrystoneRO
Dhrystone(1.1) time for 1000000 passes = 3
This machine benchmarks at 326797 dhrystones/second
++++++++++++++++++++++++++++++++++++++++++++++++++++++

玄箱PROは早いのか、遅いのか解らん・・・・
多分遅いのだろうｗ

Fedoraのスケジュールを見ると、3月20日にはbeta版が出るはずだった。
再度確認してみると、3月25日に変更されてるし・・・・

NFSサーバになっている玄箱をそろそろFedora9化にしたいと思っている。

前回Fedora9-Alphaにした時は、再起動時に起動しなくなることが2度ほどあった。
その度にFedora8に戻していた（再インストール）が、もし問題があったとしても再起動しなければそのまま使い続けることが出来る。

ちょっと暇な時間が有ったので、怖いと思いつつもFedora9-Alpha化してしまったｗ

時間に関する問題は未だに解決していない。
その他のサービスに関しては問題なく動作しているみたい・・・・。

　：
　：
　：

うぅ～　再起動したい。
でも、起動しなくなっては困るし・・・・。

　：
　：
　：

えぃ！　やっちまえ！

　：
　：
　：

お～　起動してきた。
起動に関する問題は解決してるらしい・・・・
やはり、再起動しても時間に関する不具合は解消していない。

ま～　3月25日のbeta版までには解決してることを祈るしかない。

※Fedora9-Alpha化した場合、ntpdataのみで時間を合わせると、5分後に再起動してしまうので、必ず「ppc_uartd」を再起動させる。
「ppc_uartd」を再起動させることで、「魔の5分後の自動再起動」を避けられる。

NFSでマウントし、バックアップを行っているが、毎度FULLバックアップも出来ないので、以下のようなスケジュールでバックアップを取ることにした。

日　-　全てのバックアップの削除＆Fullバックアップ。
月　-　日からの差分バックアップ
火　-　月からの差分バックアップ
水　-　火からの差分バックアップ
木　-　水からの差分バックアップ
金　-　木からの差分バックアップ
土　-　金からの差分バックアップ

これを実現するためには、簡単なshellを作らなければならない。
たいした知識も無いので、簡単なスクリプトで行ってみた。

作成したshellは2つ。

Fullバックアップを取るためのshell。
そして、差分のみを行うshell。

1つのshellで行うことも出来ると思うのだが、俺には無理っす。

んで、こんな感じで作成してみた。

# cd /root
# vi full-nfsbackup.sh
+++++++++++++++++++++++++++++++++++++++++++
#!/bin/bash

##### 日付算出する
## ※当日の日付
d0=`date "+%Y-%m-%d"`

##バックアップ先まで移動
cd /mnt/nfsclient/backup

##古いデータを一気にを削除
rm -f *-nfsbackup.tar

##バックアップ実行
tar cvf ${d0}_home01-full-nfsbackup.tar /mnt/share
+++++++++++++++++++++++++++++++++++++++++++

# vi diff-nfsbackup
+++++++++++++++++++++++++++++++++++++++++++
#!/bin/bash

##### 日付算出する
## ※当日の日付
d0=`date "+%Y-%m-%d"`

## ※前日の日付
d1=`date -d '1 day ago' "+%Y-%m-%d"`

##バックアップ先まで移動
cd /mnt/nfsclient/backup

##差分バックアップを前日のAM5時までに行われたもののみ実行
tar cvf ${d0}_home01-diff-nfsbackup.tar -N "${d1} 05:00:00" /mnt/share
+++++++++++++++++++++++++++++++++++++++++++

作成したshellの実行権与える。
#chmod 700 vi full-nfsbackup
#chmod 700 vi diff-nfsbackup
　※念のため、rootのみ実行できるようにしておく

これをcronに登録する。

# crontab -e
0 5 * * 0 sh /root/full-nfsbackup.sh　　←　日曜日のAM5時に実行
0 5 * * 1-6 sh /root/diff-nfsbackup.sh　←　月～土曜日のAM5時に実行

これで、しばらく様子を見てみよう！

先日、NFSマウントしてバックアップ環境を作成したが、アーカイブしているせいなのか、そもそもコピー速度が遅いのか、相当時間が掛かる。

単純にコピーすると以下のような結果が出た。

++++++++++++++++++
real 333m34.942s
user 0m48.028s
sys 51m3.300s
++++++++++++++++++

毎回、このような状態だと他の用途に使うことが出来ない。
そこで、差分をコピーする方法を考えてみた。

tarのオプションで有効と思われるものは次の通り・・・。

-d　　アーカイブとファイルシステムとの差分を取る
-r　　アーカイブの最後にファイルを追加
-u　　アーカイブ内の同名のファイルより新しいものだけを追加
-N　　指定した日付より新しいファイルだけ格納

shellを作成してcronにて回すことを考えると、「-N」が簡単そうな気がする。

そこで、こんな記述で実行してみた。
先ず通常にバックアップ
# tar cvf 2008032001_backup.tar /mnt/share

相当時間が掛かったが、確実にバックアップが取れた。
差分が発生するように、いくつか更新＆新規データを格納する。

そして差分バックアップを実行。
# tar cvf 2008032002_backup.tar -N "2008-03-20 11:00:00" /mnt/share

取れたデータは以下の通り
-rw-r--r-- 1 root root 74891653120 2008-03-20 10:06 2008032001_backup.tar
-rw-r--r-- 1 root root 3466393600 2008-03-20 11:15 2008032002_backup.tar

確実に差分のみアーカイブされている。

これを、簡単なスクリプトで回せば玄箱の負荷を軽減できそう。

たとえば、こんな感じ。
日　-　全てのバックアップの削除＆Fullバックアップ。
月　-　日からの差分バックアップ
火　-　月からの差分バックアップ
水　-　火からの差分バックアップ
木　-　水からの差分バックアップ
金　-　木からの差分バックアップ
土　-　金からの差分バックアップ

※本来はバックアップを取得した後に古いデータを削除したいが、HDDの容量が少ない為断念。

参考サイト：ミラクルリナックス

最近「WordPress」と言う、Blogツールを見かける。
GoogleのTrend historyによると、「Movable Type」よりも 「WordPress」を使う人が多いらしい。
でも、日本では受け入れられないのだろうか？

って、事で試しにインストールしてみた。

非常に設定も簡単で、すごくシンプル。
無料のテンプレートもネットに落ちてるし・・・
SEOに特化したテンプレート（有償）もちらほらと・・・

簡単に引越しが出来ればな～～

日頃、玄箱HGをメディアサーバ（音楽・動画）の保存先として利用している。
ついでに、仕事のデータも保存。

出来る限り、クライアントPCには保存しないように心がけている。
しかし、保存しているデータが飛んでしまっては、話にならない・・・。
せっかく歴代の玄箱を所有しているのだから、うまく利用する必要がある。

玄箱PROは現在不安定な状態（一部のアプリケーションが動かない）なので、現在は"お遊びサーバ"になっている。

定期的にバックアップを行うのであれば、安定して動作する機器が良い。

そこで、余ってる（無駄に余ってる訳ではないが・・・）初代玄箱をバックアップサーバにすることにした。
テスト用のサーバにも使いたいのだが、頻繁にバックアップを取るわけではないので、問題ないでしょう！

そこで、こんな構成で組んでみた。

NFSサーバ　　　　：　玄箱
NFSクライアント　：　玄箱HG

NFSサーバになる玄箱に
# yum -y install nfs-utils

にてインストール。
※Fedora8の場合、rpcbindがマッピングさせるデーモンになるので、インストールされていなければ、インストールを行う。

各種設定Fileに必要事項を書き加え、NFSクライアントにてマウントさせる。

以外に簡単に構築できる。

では、実際にバックアップを行ってみたが、非常に遅い。
単純にコピーでも良かったが、今回はアーカイブして保存してみた。

夜中にバックアップさせることを考えれば、遅くても問題は無いでしょう！

今、使ってるMTは3.35とチョット古い。
普段使っている分には、差し支えないが、お客様より問い合わせがあった場合、使い方が解らない・・・ｗ

気分転換に、UPDATEしてみることにした！

　：
　：
　：

以外に簡単だった。
テンプレートもそのまま使えた。

最近、ネットで「Gmailをネットワークストレージとして使う」みたいな書き込みを見かける。
気にはなっていたが、実行するまでには至らなかった。

しかし、急遽使う用途が出てきたため、どんなものなのかを確認してみた。

ググってみると、専用のツールをインストールしてドライブ（GMail Drive shell extension）としてみせる方法と、Firefoxのアドオン（Gmail Space）を使う方法があるらしい。
日頃、Firefoxを利用しているので、アドオン（Gmail Space）にて使ってみようと思う。

早速、Firefox経由でGmail Spaceをアドオンとしてインストール。
「ツール」に「Gspace」が出来てるので、選択。

すると、新しいタブが開き、下記のような画面が現れる。

まるで、FTPツールのような使い勝手。
UPしたデータはGmailにて確認できる。
メールで受信したような感じで、保存されている。
まーまー使いやすいかもし知れない。

しかし、一気に大量のデータを転送すると、ロックが掛かるらしいので注意が必要かもyo！

玄箱の再インストール前に、玄箱標準のKernelで起動してyum.logを確認してみた。
すると、変なlogが・・・・

3\xe6\x9c\x88 07 22:03:46 Erased: libgssapi
3\xe6\x9c\x88 07 22:37:50 Erased: util-linux
3\xe6\x9c\x88 07 22:37:58 Erased: libtermcap
3\xe6\x9c\x88 07 22:38:11 Erased: sysvinit
3\xe6\x9c\x88 07 22:38:24 Erased: mktemp
3\xe6\x9c\x88 07 22:38:27 Erased: termcap

何ですかコレは？
「Erased」＝翻訳すると「消されます」？？

もしかして、これが原因ですか？

何度となくFedora9-Alpha化してみたが、遊ぶにしても起動しなければ何にもならない。
おとなしくFedora8で我慢してみよう。

以前行った、玄箱HG-Fedora8と同じ方法で再構築しようっと！

んで、何して遊ぶの？　(-_-;)

昨日、玄箱をFedora9-Alpha化したのだが、全ての作業が終了しそのまま放置していた。
パッケージの更新を行い、その後何もしていなかった。
今朝、何気に再起動してみた。

うぅぅぅぅ～～　起動しない。
先日の現象と同じだ！

っと言うことは、起動に障害をもたらす何かがあるはずだ。
ここ3-4日間に更新されたパッケージに何かがある。

くそ～　やっと構築できたと思ってたのにぃ～～

Fedora9-Alpha化した玄箱が起動しなくなったのは昨晩書いたが、色々テストを行いたいので、再度Fedora9-Alpha化に挑戦したいと思う。

今回のテストとしては、yumの不具合とlocal時間の確認、それとFedora7から「いきなりFedora9-Alpha」です。

先ずは、F4K Install Kitを使ってFedora7にする。
※作業内容は省略

Fedora7が出来たところで、yumの最新パッケージを当ててみる。
# wget http://ftp.kddilabs.jp/Linux/packages/fedora/updates/7/ppc/yum-3.2.8-2.fc7.noarch.rpm
# rpm -Uvh yum-3.2.8-2.fc7.noarch.rpm

そして、yum updateを実行してみる
# yum update
fedora 100% |=========================| 2.1 kB 00:00
primary.sqlite.bz2 100% |=========================| 4.6 MB 00:03
updates 100% |=========================| 2.3 kB 00:00
primary.sqlite.bz2 100% |=========================| 3.0 MB 00:02
Setting up Update Process
Resolving Dependencies
--> Running transaction check
---> Package glibc.ppc 0:2.6-4 set to be updated
---> Package perl-libs.ppc 4:5.8.8-28.fc7 set to be updated
　：
　：
省略
　：
　：

正常に動いた～　（*^_^*）

次に時間のこの時点で合わせておく。

先ずは、下記コマンドで
# export TZ=JST-9
# ln -f /usr/share/zoneinfo/Japan /etc/localtime

設定して～

# date
2008年 3月 7日 金曜日 14:28:29 JST

この時点ではあってるな～
HWはどうだ？

# hwclock
2008年03月07日 14時29分30秒 -0.341306 seconds

合ってるね～

では、一気にupdate
# yum -y update

完了。

では、いよいよFedora9-Alpha化
必要なパッケージをwgetする。

# wget http://ftp.jaist.ac.jp/pub/Linux/Fedora/releases/test/9-Alpha/Fedora
/ppc/os/Packages/fedora-release-8.90-3.noarch.rpm

# wget http://ftp.jaist.ac.jp/pub/Linux/Fedora/releases/test/9-Alpha/Fedora
/ppc/os/Packages/fedora-release-notes-8.90-1.noarch.rpm

そして、update
# rpm -Uvh fedora-release-8.90-3.noarch.rpm fedora-release-notes-8.90-1.noarch.rpm

念のため掃除
# yum clean all

yumコマンドにて「yum」と「rpm」をFedora9-Alphaのパッケージへupgradeする。
# yum update rpm\* yum\*

終わったところで、一旦再起動。

そして、date
# date

9時間進んでるし・・・・^_^;

# hwclock

さらに9時間進んでる。　^_^;

念のためntpdateとhwclock -w を実行し、自動で再起動しないようにppc_uartdも再起動しておく。

この状態で、完全にFedora9-Alpha化にしてしまう。
# yum -y upgrade

　：
　：
　：

元通りになったが、時間だけはどうにもならなかった。
Fedora7の時は問題なかったが、Fedora9-Alphaにすると駄目になる。
何が原因なんだろう？？

もうすぐベータ版が出るらしいし、しばらくはこのままで運用してみようかなぁ～

Fedora9-Alpha化した玄箱を2日ほど電源を切っていた。
yum updateを行うために電源を入れてみたが・・・・

起動しない。
何度もコンセントの抜き差しで電源OFF/ONしてみたが、駄目っぽい。

どうしよう！！

自宅の近所で撮影。

シャッターのタイミングがズレて、はっきり写ってませんが、相当な迫力でした。
この辺は、畑が多いため土ホコリで、こんな竜巻が起きるらしいです。

業務委託を受けている会社で、Windowsの仮想化を商品にしたいと相談があった。
WindowsServer2008でも実現できるし、その他のTOOLでも仮想化は実現できる。

仮想化ではないが、Windows2000ServerでIISが頻繁にお亡くなりになったり・・・
ストリームサービスを起動しても、上手く動かなかったり・・・
Windowsでの印象が非常に悪い。

ココ最近のWndowsServer2003は非常に安定していると言う噂も有る。
あたらしいWindowsServer2008の仮想化は、まだ時期が早そうで怖い。
ならば、WindowsServer2003で実績の有る仮想TOOLを使うのも良いのかな～って思ったりもする。

しかし、問題がある。
「てきとー管理者＝俺」がWindows仮想化の運用が出来るかが一番の問題だぁ～！　ｗ

やっと玄箱をFedora9-Alpha化で時刻を合わせても再起動が掛からないように出来た。

落ちないようにするには、次のような流れを踏めば確実に落ちない。

１、ntpdateにてOSの時刻を合わせる
２、hwclock -wにてHWの時刻を合わせる。
３、ppc_uartdを再起動する。

この流れを、簡単なshellを作成して、起動時に実行させる。

コレで、いけるはず。

先ずは、超簡単な（素人レベルの・・・）shellを作成

# cd
# vi adjustment_at_time.sh
++++++++++++++++++++++++++++++++++++
#!/bin/bash

# OSの時刻調整
/usr/sbin/ntpdate ntp.dnsbalance.ring.gr.jp

# HWの時刻調整
/usr/sbin/hwclock -w

# 玄箱のマイコン制御デーモン再起動
/etc/rc.d/init.d/ppc_uartd restart
++++++++++++++++++++++++++++++++++++

# chmod 700 adjustment_at_time.sh　　←　念のためrootのみ実行できるようにする。

作成したshellをrc.localに組み込む
# vi /etc/rc.d/rc.local
+++++++++++++++++++++++++++++++++++
最終行に追加
sh /root/adjustment_at_time.sh
+++++++++++++++++++++++++++++++++++

ntpdを立ち上げる程でもないので、このshellをcronで定期的に起動する。
# crontab -e
+++++++++++++++++++++++++++++++++++
0 0 * * * sh /root/adjustment_at_time.sh
+++++++++++++++++++++++++++++++++++

この状態で、再起動。

　：
　：
　：

起動したら、dateにて時刻を確認。

お～行けた。

でも、もっとスマートな方法があるはずなんだが・・・・・

玄箱をFedora9-Alpha化も「其の九」まで来てしまった。
そろそろ終わりにしたい所だが、時刻を合わせると必ず5分後にリブートしてしまう。
何とかせねば・・・・

今日、yum updateを行ったら、様々なパッケージが更新されているようだ。
早速updateを行い、再起動。
その上で、ntpdateにて時刻合わせ。

# ntpdate ntp.ring.gr.jp
2 Mar 18:31:05 ntpdate[2068]: step time server 133.243.232.68 offset -32399.367843 sec

# hwclock -w

　：
　：
5分間待ってみる
　：
　：

やっぱり再起動になってしまう。
何でなんだろー
意味わからん！！

再起動後、なんとなく思いつきで時刻を合わせた後に「ppc_uartd」を再起動してみた。

# ntpdate ntp.ring.gr.jp
2 Mar 18:50:57 ntpdate[2068]: step time server 133.243.232.68 offset -32399.207558 sec

# hwclock -w

# /etc/rc.d/init.d/ppc_uartd restart
Stop services: ppc_uartd
Start services: ppc_uartd

　：
　：
5分間待ってみる
　：
　：

ん？　5分経過しても再起動しない・・・
10分経過・・・・・
15分経過・・・・・
20分経過・・・・・

もしかしてOK？

って事は、再起動すると必ず時間が狂うので、起動時に「ntpdate」にて時刻を合わせ、「ppc_uartd」を再起動させることでOKになるってことか・・・・

起動スクリプトに、一連の流れを埋め込めばOKになると思うのだが、どのタイミングで実行するか？？　だな～