つい先日サーバのファンが不具合を起こしたことと、また他のサーバも騒音が気になることから、この週末にサーバ達のファン交換およびファン追加を行ないました。

ファン径を大きくしたいところですが、筐体の大きさに制限があり難しいのが現実です。
仕方ないので、これまでと同様に低回転数のものに交換しました。
(ファン交換の詳細は、機会があればまた後日)

サーバのうち2台には Intel D945GCLF2 を使用しています。
交換したファンの規格風量は標準品の約半分。CPU温度等が気になります。Windows については EVEREST で簡単に調べられますが、Linuxの場合どうするのか、ちょっと調べて実施してみました。

lm-sensors というソフトがあるそうで、まずはインストール

# apt-get install lm-sensors

次にセンサーの設定を行ないます。

# sensors-detect

sensors-detect revision 5249 (2008-05-11 22:56:25 +0200)

This program will help you determine which kernel modules you need
to load to use lm_sensors most effectively. It is generally safe
and recommended to accept the default answers to all questions,
unless you know what you're doing.

We can start with probing for (PCI) I2C or SMBus adapters.
Do you want to probe now? (YES/no):
〜〜
省略
〜〜
Do you want to add these lines automatically? (yes/NO) : yes

基本的にはひたすら Enter を押していけば設定できます。
最後に出てくる、選択肢のデフォルトがNOになっているところだけyesとすれば、設定完了です。

再起動して、コマンド「sensors」を実行。

$ sensors
smsc47m192-i2c-0-2d
Adapter: SMBus I801 adapter at 2000
+2.5V:       +2.50 V  (min =  +0.00 V, max =  +3.32 V)
VCore:       +1.15 V  (min =  +0.00 V, max =  +2.99 V)
+3.3V:       +3.32 V  (min =  +0.00 V, max =  +4.38 V)
+5V:         +4.97 V  (min =  +0.00 V, max =  +6.64 V)
+12V:       +11.88 V  (min =  +0.00 V, max = +15.94 V)
VCC:         +3.33 V  (min =  +0.00 V, max =  +4.38 V)
+1.5V:       +1.55 V  (min =  +0.00 V, max =  +1.99 V)
+1.8V:       +1.79 V  (min =  +0.00 V, max =  +2.39 V)
Chip Temp:   +38.0°C  (low  = -127.0°C, high = +127.0°C)
CPU Temp:    +49.0°C  (low  = +48.0°C, high = +55.0°C)
Sys Temp:    +45.0°C  (low  = -127.0°C, high = +127.0°C)
cpu0_vid:   +2.050 V

smsc47m1-isa-0680
Adapter: ISA adapter
fan1:       1565 RPM  (min = 1280 RPM, div = 4)
fan2:       3900 RPM  (min = 1280 RPM, div = 4)

無事に温度およびファンの回転数が表示されました。

これら数値は、ほぼ同じ機械構成のWindows機とほぼ同じ。
これらのCPU「ATOM330」は80℃くらいまで大丈夫なようですから、夏場でも特に心配することはなさそうですね。

    

今日はサーバにUPSを導入します。

と言っても、これまでUPSが無かったわけではありません。オムロン製のBX35Fを使用していました。
このBX35Fは元々TeraStation用に使用していたもの。TeraStationを処分してからはLinuxサーバ用に使用していましたが、そこにはLinux側からUPSが制御できないという問題が。
せめてシリアルで接続できるものを買っておけばよかったんですが、それは今さらの話。

先日ちょっとヒヤッとしたこともあり、ちゃんと制御できるUPSを導入しました。

　　　

新しいUPSは右側、APC製のSmartUPS-CS350です。左は古い方。

Linuxへの導入は、いろいろ回り道をして結構手間取りましたが、結果的には簡単でした。

参考にしたのはこちら。

1. ドライバのインストール
   apt-get install apcupsd
   
2. ドライバの環境設定
   vi /etc/apcupsd/apcupsd.conf
   1. ケーブルタイプの指定を変更
          UPSCABLE smart
             ↓
          UPSCABLE usb
      
   2. UPSタイプとデバイスファイルの指定を変更
          UPSTYPE apcsmart
          DEVICE /dev/ttyS0
             ↓
          UPSTYPE usb
          DEVICE
      
   3. タイムアウトの設定変更
          TIMEOUT 0
             ↓
          TIMEOUT 60
      
      vi /etc/default/apcupsd
          ISCONFIGURED=no
             ↓
          ISCONFIGURED=yes
      
3. 再起動
   /etc/init.d/apcupsd restart

これで準備完了です。
UPSの電源を抜くとコンソールに警告が表示され、1分後に自動でシャットダウンします。ちょっと感動です。

 

さて、このUPS制御ソフト「Apcupsd」ですが、こちらに判りやすい説明があります。
これを見るとWebブラウザから状態管理が行えるとのこと。しかしサーバ内の何処を探してもスクリプトが見つかりません。

ソースを持ってきたり、Debianパッケージを持ってきたり、いろいろ紆余曲折した結果、何のことはなくちゃんとパッケージで用意されていました。

apt-get install apcupsd-cgi

で簡単に導入できました。
アクセスは以下の通り。

http://サーバ名/cgi-bin/apcupsd/multimon.cgi

現在の電力供給量を示してくれる「UPS Load」の項目が何気に有り難いです。
24時間稼働のため電力量が気になっていましたが、これで様々な省電力設定の効果を量ることが出来ます。

思わぬところで遊べるネタが増えました。＾＾

Ubuntu-Serverを運用していますが、導入時のLTS版(8.04)をよく判らないまま(8.10)へアップグレードしてしまったため、次のLTS版まではこまめにアップグレードしていく必要があります。

先日9.04へアップグレードしたところ、ネットワークドライブ(Samba)が不安定になってしまいました。仕方なく一旦バックアップしてあった8.10に戻し、様子を見ています。

構成機器は以下の通り。

• CPU：ATOM330 (intel D945GCLF2)
• メモリ：1GB
• OS：Ubuntu Server 8.10

 

さて、その8.10に戻してからの運用中。

サーバ運用については基本的にいろいろなことを自動化させる主義であり、システムのアップグレードも例外ではありません。
CRON-APTを使用していますが、そのときに保留となっていたカーネルのアップグレードを手動で行ないました。

すると先日9.04へアップグレードした際に起きたのファイルサーバの不安定が再現したのです。

そこで当然のようにカーネルに問題があるだろうと疑いをかけたわけですが、ググってみても似たような事例は見あたりません。さらに少ない知識を駆使して、一応ログなども見てみましたが、エラーを吐いた形跡が見あたりません。
この辺から何かおかしいと感じ始めます。もしかするとサーバ側は不具合とは見なしていないのかもしれません。

そこでふと、NICが頭に浮かびます。そういえばD945GCLF2にUbuntuを入れるとNICの認識に不具合を生じるという話があったのを思い出したんです。
そのときには一応正しいドライバの導入を試みたりしましたこともありましたが、再起動で戻ってしまうことの対処法が判らず、また自分は特に不都合無く通信できていたため、その後は放置していました。

さらに、実はもう随分前になりますが、RealtecのNICには泣かされた経験があります。
ギガビットイーサ(?)が出始めの頃、選択肢の少なかったこともありメルコのギガNICを購入しました。XPで普通に動いていましたが、高負荷をかけたり、数時間通信を続けたりすると突然切断されるという事象がありました。
結局使い物にならないと判断し、部品庫の奥に今も眠っています。

症状は少し違いますが、今回の事象もNIC(と言うか蟹チップ)が原因ではないかと思い、別のNICを試してみました。

試したNICはこれ。
もう随分前に購入したものなので、細かい型番は違うんだろうとは思います。

 

Linuxでハードウエアを後から追加するのは初めてです。どうなるのか心配でしたが、存外あっさり稼働してくれました。
PCIに刺して起動すれば、あっさりeth1として稼働し正常に通信できています。MBの蟹NICはBIOSで切ってしまいました。

正常稼働を確認したところで再度9.04へアップグレード。
その後は非常に安定稼働してくれています。mt-daapdに多少問題が有りますが、この辺は追々解決していけばいいこと。ファイルサーバとして安定してくれることが何より重要です。

 

結論

蟹チップは疑ってかかれ！

 

そういいつつも、これはおすすめですよ。

Linuxサーバとしてubuntu-serverを運用しています。
用途はネットワークの制御とファイルサーバが主です。

ディストリビューションのバージョンは8.10でしたが、先日これを9.04にアップグレードしました。
ところがこのアップグレードでファイルサーバとして非常に不安定になってしまいましたとさ。

****************************************************

というのが前回のお話。
症状が修正できないので、今日はシステムのリストアです。

バックアップは「システムのバックアップ」で書いたとおり、/homeを除いてダンプにより保存してあります。

今回はシステムのリストアのため、別のシステムから起動する必要があります。
これにはUbuntu9.04-DesktopのライブCDを使用しました。

主な流れは次のようになります。

1. ライブCDからUbuntu-Desktop9.04を起動
2. ダンプ(およびリストア)をインストール
3. バックアップのあるドライブをマウント
4. リストア先ドライブをマウント
5. バックアップからリストア

2と3が少しだけ工夫がいります。

先ず「2.ダンプ(およびリストア)をインストール」は事前準備として、/etc/apt/sources.list 内のサーバアドレスが全てコメントアウトされているため、これを有効にする必要があります。その上で普通に

# apt-get update
# apt-get install dump

とすればOKです。

「3.バックアップのあるドライブをマウント」については当初、デスクトップからのアクセスによる自動マウントを試みましたが、なぜかうまくいきません。デスクトップからでは覗けないのです。
仕方がないので普通にマウントします。(ついでにリストア先ドライブもマウントします)

今回はバックアップ先を /USBHDD に、リストア先を /System にマウントします。

# mkdir /USBHDD
# mount -t ext3 /dev/sdb1 /USBHDD
# mkdir /System
# mount -t ext3 /dev/sda1 /System

lsで確認してOKです。

さていよいよリストアです。
まずはリストアするシステムドライブの中身を全部消します。これをやっておかないとエラーの嵐になります。
システムのルートで次のコマンドをどきどきしながら実行(これは心臓に悪いです。)

# cd /System
# rm -r *

何もないルート(/System)へリストアを実行します。

# gzip -dc /USBHDD/Backup/filename.zip | restore -rf -
# sync

リストア自体は5分ほどで終了します。
今回はドライブを交換したわけではありませんので、これで終了です。ブートローダ等を気にする必要はありません。

ライブCDを抜いて再起動。あっさりと起動してくれました。
少しテストしてみましたが、ファイルサーバとしては安定している様子。しばらくはこのまま使用することになりそうです。

 

ちなみに、サーバ用途のPCではCDドライブはほとんど使いません。そのため私はサーバ用には下記ドライブを使い回しています。
USBバスパワーのみで稼働してくれるので大変助かります。

Ubuntuの9.04が4月23日にリリースされました。

現在はUbuntu Server 8.10を使用中です。
クリーンインストールしたのは8.04LTSでした。8.10がリリースされたときにはUbuntuのリリースのシステムがよくわかってなく、特に何も考えずにアップグレードしてしまいました。
今となっては8.04のままにしておくべきだったかと思っておりますが後の祭り。次のLTS版が出るまではこまめにアップグレードしていくことにします。

ということで、今日は9.04へのアップグレードです。
機器構成は次の通りです。

• CPU：ATOM330 (intel D945GCLF2)
• メモリ：1GB
• OS：Ubuntu Server 8.10

使用中のアプリケーション(パッケージ)は次の通り。(たぶん抜けあり)

• samba
• postfix
• LAMP
• mediatomb
• mt-daapd

アップグレードは非常に簡単です。
SSHでログインし、ルートで

# do-release-upgrade

と、これだけです。

SSHからのアップグレードは推奨しませんとか言われますが、かまわず続けます。
その後もセキュリティの設定とか、アプリケーションの設定とか聞かれますが、基本的に現状維持としました。

特におかしな事も起こらずアップグレード終了。再起動します。
作業は30分もかかっていないと思います。

無事に起動してきたので動作チェック。

まずmt-daapdの挙動が変です。
なによりOS起動時に起動してきません。起動リストには入っていますし、再起動して表示を見る限り起動しようとはしている様子。とりあえず手動で起動してみます。
Webから設定画面にアクセス。操作はできますが、フォルダ等の設定を行なう画面が表示されません。

実はmt-daapdのこの挙動、前回8.04から8.10にアップデートしたときにも同じようになりました。
あのときはどうやって解決したんだっけ…?

 

さて、タイトルに「大問題」と書きましたが、mt-daapdのことではありません。問題はファイル共有で起こりました。

サーバの主な用途はネットワークドライブです。
単なるストレージとしてだけでなく、大容量作業エリアとしても利用しています。
ここにある程度の負荷をかけると、ドライブが切断されるようになってしまいました。

切断されたときには他のWinPCも切断されている様子。(ただし全PCでユーザ名が同じなので、ユーザ単位で切断されているだけかもしれません。)
接続数等の設定を確認し、sambaのLogも確認してみましたが異常は見つけられません。というか、Logにエラー等も見あたりません。

それなりに調べましたが症状を回復できません。もちろん原因もわかりません。
しかしファイルサーバが安定しないこの状態は、私にとってかなり問題です。
幸い「システムのバックアップ」で自動化したバックアップデータがありますので、初のリストアに挑戦することになりそうです。

一ヶ月近くほったらかしてしまいました。
4月に入って少し時間に余裕が出来るはずが、部署移動の話等が出てきたりして結局心は安まりません。
もう少しのんびり仕事したいんだけどなぁ。

閑話休題。
今日はLinuxシステムのバックアップの話です。

メインサーバのパーティション構成は次のようになっています。

• システム(/) 20GB
• スワップ 500MB
• データ領域(/home) 980GB

システムに20GMもとってあるのは、当初の勘違いのためです。4GBもあれば充分だと思いますが、いまさら変更するのも大変なので、放置です。

Webデータも動画データも、全て/homeの下にディレクトリを作って管理する形をとっています。これはデータのバックアップを簡単にするためです。
このような形にしていたおかげで、結果的にシステムのバックアップも簡単に行なうことが出来ました。

システムのバックアップはファイルコピーではなくイメージでとります。今回はdumpを使用しました。データのバックアップをとっている外部HDDに /Backup ディレクトリを作りシステムのバックアップデータを入れることにします。

まずdumpのインストール

#apt-get install dump

次に実験的にバックアップをとってみます。

#/sbin/dump -0f - /dev/sda1 2> /USBHDD/Backup/SystemBackup.log | gzip > /USBHDD/Backup/sda1_`date +%y%m%d`.zip

ファイル名に日付を入れようとしましたが何故かうまくいきません。理由はバックスラッシュにすべきところをシングルクォートに間違えていました。
バックアップ元は9％程使用しているので容量は約1.8GB程。できたファイルは600MB弱。所要時間は約5分でした。

ちなみに今回はgzipで圧縮していますが、dump自身のオプションでも圧縮は可能です。dumpのオプションに単に-jとして試してみましたところ、サイズは若干増加、所要時間は倍以上でした。

さて実験が成功したので本番の準備です。バックアップの計画は次のようにしました。

• 週に一回、データのバックアップのついでにシステムもバックアップする。
• 常に完全バックアップをとる。(増分バックアップにはしない)
• 2世代残す。
• ファイルシステム等の情報も最新のものを残す。
• 完全自動化する。

データのバックアップは既に自動化していますので、そこにシステムバックアップ用のスクリプトを追加していきます。

#SystemDump

find /USBHDD/Backup -mtime +10 -maxdepth 1 -name '*.zip' -exec rm -f {} ;

fdisk -l > /USBHDD/Backup/fdisk.txt
df -k > /USBHDD/Backup/df.txt
cat /etc/fstab > /USBHDD/Backup/fs.txt

date > /USBHDD/Backup/SystemBackup.log
echo "*********************************" >> /USBHDD/Backup/SystemBackup.log

/sbin/dump -0f - /dev/sda1 2>> /USBHDD/Backup/SystemBackup.log | gzip > /USBHDD/Backup/sda1_`date +%y%m%d`.zip

やってることは、

• 古いバックアップファイルを消して、
• ファイルシステム等の情報を取り、
• ログファイルに日付等の装飾をつけ、
• システムのバックアップを取り圧縮して保存する。

といった感じですね。

これでバックアップはとりあえずOK。
次はリストアを試して何時でも復活可能なようにしておかなければなりませんが、これはまた後日。

先日Webグループウエア「La!cooda WIZ」のUTF-8化を行ないました。数日間使用する中では特に不具合は無い様子です。
しかし普段使用していない機能もいくつかあり、何気に動作テストを行なっていたところ、不具合発見です。

このソフト、ファイル共有というかライブラリ登録のような機能があります。この機能でアップロードしたファイル名に不具合発生です。
例えば「ほげほげ.jpg」というファイルをアップロードすると「.jpg」と表示されてしまいます。ただファイルの使用自体には問題ない様子。
しかし「ほげほげ.jpg」も「はにはに.jpg」もみんな「.jpg」と表示されますから、使い物になりません。

折しも文字コードに関する改造を行なった直後の、日本語に関する不具合。改造が原因だと思うじゃ無いですか。

さあ原因追及です。ソースコードのファイル名処理に関するところを追いながら、文字変数の変化を観察します。しかし特におかしなコードは見あたりません。

そのうち意外なところで不思議な動きを発見しました。それはphp関数「basename」。
パスのついたファイルからファイル名を抜き出す関数ですが、どうも日本語の処理がうまくいってないようなのです。

もしやと思い調べてみると、ありました。
http://bugs.php.net/bug.php?id=37738

要はphp5のバグです。

実はこのソフト、元々php4で作られていて、単純にphp5に乗せただけではまともに動きません。
使い始めた頃のサーバがphp4だったため特に問題はなかったんですが、少し前サーバにphp5を採用し、ソフトを対応させて使用していました。

つまりサーバを代えて以来ずっと不具合はあったが、あまり使わない機能なので気づかなかっただけだったんです。

ただこの機能は今後使用する予定ですので、修正することにします。

問題の箇所は、ファイル「record.php」の1282行目
$userfile_name2 = basename($_FILES['userfile']['name']);

これを日本語対応のsplit関数を使って代用します。
$userfile_name2 = end(mb_split("/",$_FILES['userfile']['name']));

これで完了。
原因さえわかれば対処はそれほど難しいものでもありません。


しかし、まだ他にも不具合が出てきそうだな…。

先日Webサーバに関する文字コードを全てUTF-8に替えました。
これにより、EUCを前提として作られていたPHPアプリは予定通り文字化けを起こしていました。

一応対処が終わりましたので記録です。


問題のアプリはフリーのグループウエアで「La!cooda WIZ」といいます。
http://wiz.syscon.co.jp/

このソフトに様々に機能追加を行なって運用しています。
（機能追加というより、認証とデザインだけ利用したオリジナル運用といった方が近いかも。）


スクリプトのUTF-8化は基本的に、EUCで処理しているところを全てUTF-8に代えれば良い、…と思う。

1. まず全てのスクリプトの記述コードをUTF-8に変換。ただし携帯電話向け機能だけはSJISのまま。
2. スクリプト中のHTMLヘッダ記述部をUTF-8に変換。
3. スクリプト中のEUC文字コード指定部（主にmb_convert_encoding）をUTF-8に変換

大変なのは3番です。このソフト、結構な数のスクリプトファイルが有り、相互にリンクしてますので手は抜けません。


次にデータベースのUTF-8化。こちらはデータテーブルの接続照合順序をUTFに変換します。（データは元々UTF-8です）

1. phpMyAdminを利用して、関連するテーブルをエクスポート。
2. エクスポートされたデータの「DEFAULT CHARSET」をujisからutf8に変換。
3. 再びphpMyAdminを利用してインポート

と、まあ非常に簡単です。


この照合順序ですが、替えないと化けます。理由がよくわかりません。検索の順序がどうこう言う説明を見たことはありますが、それで抽出したデータが化けるというのが今ひとつピンときません。


閑話休題。
ここまでして動作テスト。
基本的にはうまく動いています。

しかしjavascriptのalertポップアップ(?)表示の一部が文字化けを起こしていました。一部、というのが解せません。
よく見るとalertだけで完結したHTMLを送り出している様子。それならばとalertのヘッダ表記にUTF-8を記述すると解決しました。しかし記述なしでも化けない場合との違いは不明のまま。対処療法に終わりました。

すっきり終了とはいきませんが、まあいいですかね。

はじまりは1年くらい前でしょうか。
今のATOM330サーバではなく、Debian化玄箱HGの頃だと思います。


数年前にIO-DATA社の「AVeL LinkPlayer」というDLNAクライアントを購入しました。サーバの設置は、基本的には付属するDLNAサーバソフトウエアをWindowsにインストールして使いなさい、という趣旨なのですが、当然DLNAサーバであれば何でもいいわけです。

せっかく24時間稼働しているサーバがあるんですから、そちらで何とか出来ないかと探していたところ「MEDIATOMB」なるソフトがあるという情報を見つけました。そこで早速導入です。

導入自体はapt-getですんなりでした。しかし文字化けに悩まされています。
Linuxサーバは基本的にすべて UTF-8 で構成しています。mp3等のデータもファイル名、タグすべて UTF-8 になっています。
唯一 MySQL の default-character-set のみがujis設定で、ほぼ間違いなくこれが原因であることは推測できます。

この設定にはもちろん理由があり、それはあるPHPアプリがEUCで動くようになっていること。常時使用するわけではないですが、これが仕事用アプリで、ソフト改造時のテスト用に使用しています。


面白いのは、このままの設定でも MEDIATOMB 起動後に MySQL を再起動すればなぜか正常に動くのです。
そこでサーバ起動時に実行される rc.local に

/etc/init.d/mysql restart

を付加することで今日まで対処していました。
（この辺の理屈をご存知の方がいらっしゃいましたら、ぜひ教えてください。）


しかしこの使い方ですと、いつの間にか文字化けが復活してしまいます。どうもデータの自動更新が行なわれた際に文字化けが復活するようなのです。

しかたないので、MySQLをUTF8にして、サーバすべてをUTF8に統一することにしました。
PHPアプリの方は、気長に対処することにします。

結論は大成功、…っぽいです。^^
しばらく様子を見ないと判りませんけどね。


ちなみに私のDLNAクライアントは既に生産終了しているようです。
今ならこちらですかね。

3月いっぱいまでは仕事が忙しい予定なんですが、今週の5日間は勤務時間中ずっと頭をフル回転させていて、さすがに疲れました。

ということで、ストレス発散です。
以前挫折していた「Virtual PC 2007 SP1 に Ubuntu 8.04.2 server を導入」に再チャレンジです。

以前はカーネルの再構築を試行錯誤するのが目的でした。ubuntuのインストールは挫折しましたが、Debian-Linuxなら入ったのでこちらで遊んでいました。
とはいうものの、本番環境とはなるべくそろえておきたいもの。そこで再チャレンジです。


主に参考になったのは次のサイトです。
http://compnet.jp/archives/47


さて、ここの手順を追ってもうまくいきません。で、試行錯誤になるわけですが、一番まずいのはインストールオプションの意味がわからないこと。google先生に訊いても見つけられません。

でもまあ、とりあえず起動まで漕ぎつけましたので、うまくいった一例だけ書きます。

1. VPCを何も考えずにインストール。適当にバーチャルマシンを創ります。
2. ubuntu-serverをCDイメージから起動。F6でインストールオプションに
   
   noreplace-paravirt vga=791
   
    を追加してインストール。（このときオプションの最後の「--」の前に追加する。)
3. インストール終了後の再起動時にESCでgrubメニューに入り、カーネル指定部に
   
   noreplace-paravirt vga=769
   
   を追加して起動。（起動に成功したら、/boot/grub/menu.list にも同様に追加しておきます。）

 

私の場合はこれでうまくいきました。

さて、起動できたので初期設定です。

1. sudo su - の後に passwd で、su を有効にします。
2. apt-get でアップデートします。（今日の時点ではアップデートされるものはありませんでした。すべて最新???)
3. webmin導入
4. phpmyadmin導入

これで一応の環境は整いました。

さて、何して遊びましょうかね。^^