Archive for category Linux

Buffalo LS-GLでLinuxbox(7)

NTPがさっくりと入ったような気がしたんだけど、どうも安定して動かない。起動してしばらくするとNTPサーバに同期するんだけど、小一時間して様子を伺うとntpdが落ちている。psしてもプロセスが存在しない。どうもシステムクロックの精度が悪くて落ちてるっぽい。こういうところは不親切だよな~、ntpdは。

と、嘆いているだけでは埒があかないので、玄箱時代に同じようなことがあったことを思い出してゴソゴソと調べてみた。どうもntpdは±8.64秒/日以下の精度がないとちゃんと動かなさそうなことが書いてあった。そして、玄箱時代もシステムクロックの精度の悪さに対応するためにadjtimexを使ったっけ、と昔を懐かしながらipkgにadjtimexを探したけどなかった。もう少し探してみたら ntpclient に含まれているようだ。# ipkg install ntpclientでさくっと adjtimexは入ったけど、使い方が分からない。。。 ウェブにあるadjtimexのmanページを見てもあるはずのオプションがないから、普通のものよりもちょっと特殊なものが入っているよう。

以前は確かこの方法でadjtimexを使ったと思うけどこのスクリプトはLinkStation+Optwareには使えなさそう。そこで、# adjtimexを実行すると表示される情報を元に試行錯誤をしてみた。方法はSlashdotの記事を参考に、# adjtimex -t x -f 0のx(tickと呼ばれる値で、デフォルトは10000)をntpq -pで表示されるoffsetの値を元に増減させる。offsetがプラスに大きくなってきたら10001、10002と大きくしていく。逆にマイナスに大きくなってきたらtickを少なくする。

Linuxがどのようにシステムクロックを管理しているか深く理解していないけど、10000 tickを基準に±1000 tickの範囲で粗く調整し、1 tick=6553600 frequencyでさらに細かく調整できるよう。で、ntpdはfrequencyは調整してくれるみたいだけど、tickは手動で設定するみたい。# ntpq -p
# adjtimex
を繰り返してntpqのoffsetとadjtimexのfrequencyに注目する。adjtimexのfrequencyの絶対値が6553600を超えたら、tickを調整する。6553600以上になったらtickを1増やして# adjtimex -t tick+1 -f 0とfrequencyをリセットする。

いまのところtick=10007、frequency=5651930あたりで落ち着いてる。これで様子を見よう。

ユーザをadminグループのメンバーにする

Wordpressの管理者アカウントでいろいろと作業を行おうと思うと、コンソールにて$ su -でsuになるのはいいんだけど、GUIで作業をしたいときはgksuを使いたくなる。あと、普通にsudoコマンドも使いたい。けど、普通のアカウントだとsudoersファイルに設定(/etc/sudoersをvisudoで編集)してもだめで、adminグループに属しないといけないよう。

なので、kiyoeriさんの記事を参考に# usermod -G admin ユーザIDとするとsudoersに何もしなくてもsudoおよびgksuが使えるようになる。

Ubuntuのリフレッシュレート変更

そう言えばなんか画面がチラチラすると思ったら、リフレッシュレートが60Hzだった。そう、まだ我が家のモニタはブラウン管でSony GDM-20SE3Tなのである。運良くソニータイマーが発動することもなく、もう12年目に突入しようとしている。もうこうなったら壊れるまで使い倒すつもり。

まあそれはいいんだけど、Ubuntuでのリフレッシュレートの変更のしかた。Windowsではわけなくできることだけど、Ubuntuではひとひねり必要だったりする。まず、[システム]ー[設定]ー[画面の解像度]では「リフレッシュレート」なる項目はあるものの、60Hzしか選択肢がなく変更できない。

ググってみると、そのものズバリUbuntuをインストールした直後に行う設定(Ubuntu 8.04編)があって、この「解像度とリフレッシュレートの設定」に見習ってコンソールにて、$ sudo displayconfig-gtkを実行すると[モニタとグラフィックスカードの設定]なるウィンドウが開く。ここでモニタの設定を選ぶと複数のリフレッシュレートが選択できるようになるので、控えめに70Hzを選択してとりあえずリブート。

するとログイン画面が大きくてスクリーンをはみ出している。辛うじてログインはできるけど、画面下に表示されるはずのメニューが一切見えない。これは頂けない。ただ、ログインしてしまえば画面のチラつきはなくなっていて、逆に75Hzのパキパキな画面になっている。ん? 75Hz? まあ、安定しているからいいけど。

さて肝心のログイン画面なんだけど、これは何回か遭遇している不具合で、毎回なんかする拍子に直ってしまうので「これ」っていう対処方法が分かってない。これもググってみると、take shortさんのところにヒントがあった。/etc/X11/xorg.confの必要のない解像度を削除する、というのが正解らしい。1600 x 1200より高い解像度設定をSection “Screen”
SubSection “Display”
Modes
から削除してリブートしたら綺麗に1600 x 1200 @ 75Hzでログイン画面、デスクトップとも起動できた。めでたし、めでたし + ありがとうございます、先人の皆様。

Ubuntuでファンを制御する

静音化に取り組んでるサブ機だけど、静かなるほど他の音が気になる。静音化のジレンマだねぇ。と、感慨にふけっている場合ではなく、かすかに聞こえるCPUファンの音が気になり始めた。これはひとつファン静音化抵抗をはさむか、と思ったら4ピンのファンだった。どうせPWM制御だったらソフトウェアでできるはず・・・

って、もうCool’n'Quietで行われているんだけど、ファンの回転数がちょっと高くて、1400rpmあたりを前後している。これで33℃くらい。もうちょっと温かくていいから、ファン回転数を下げられないか・・・ それより、そもそもUbuntuでファンの回転数をもっと詳細に見られるようにすべきなんじゃないか。

ということで、KsensorsというGUIでPCの諸々の情報を監視できるパッケージをSynapticで入れてみた。これを入れるとlm-sensorsというコマンドラインのPC情報監視ツールおよびそれに関連する諸々のライブラリ等がインストールされる。でも、インストールするだけではなぜかKsensorsはメニューに現れない(再起動したとしても)。

そこでググって見たところ、Ubuntu Forumにファンのソフトウェア制御も含めた親切な解説があった。この説明をベースにいろいろとやってみて、うまく行った(と思われる)ものを書きとめておく。

まず、$ sudo sensors-detectを実行して、PC情報を取得するセンサーデバイスを特定する。と言ってもただひたすら「y」と答えていくだけ。最後の「/etc/modprobe.d/local に設定を追加する」と聞いてくるので、ここも「y」。ここで再起動すると良さそう。

再起動した後たぶんここで$ sudo sensorsとすると、各センサー情報が表示されるはず。うまく行かないマザーボードもあるらしく、ここで何も表示されないとかなりはまると思う。幸いここは直にファン回転数、温度等正常に表示されたのでひと安心。

安心したのもつかの間、/etc/sensors.conf が無い。/etc/sensors3.conf ならある。なんだか分からないけどとりあえずコピーする。$ sudo cp /etc/sensors3.conf /etc/sensors.conf

次はいよいよファン回転数のソフトウェア制御。$ sudo pwmconfigを実行して、sensorsコマンドで表示されたファンセンサーデバイスとCPU温度の紐付けを行う。ちなみに、このツールはなぜかファンの回転停止を半自動的に求めようとするんだけど失敗する。これはマザーボード上でもファン回転数を制御しようとしていてそれが影響しているのか、PWMのファンには相性が悪いのか分からない。まあ、とりあえず/etc/fancontrol が作られているはずなので、これを調整していく。

その前に、$ sudo fancontrolを実行してソフトウェア制御が可能か試してみる。うまくいったんだけど、回転数はまだ若干高い。CPU温度が35℃あたりで1200rpm。CPU温度がもっと上がれば回転数もそれなりに上がってくれるので動作はちゃんとしているっぽい。そこでconfigファイルの調整。

ここは色々と試行錯誤したけど、/etc/fancontrolの調整後の内容がこちら。INTERVAL=5
FCTEMPS=hwmon1/device/pwm3=hwmon1/device/temp2_input hwmon1/device/pwm1=hwmon1/device/temp2_input
FCFANS=hwmon1/device/pwm3=hwmon1/device/fan1_input hwmon1/device/pwm1=hwmon1/device/fan1_input
MINTEMP=hwmon1/device/pwm3=30 hwmon1/device/pwm1=30
MAXTEMP=hwmon1/device/pwm3=50 hwmon1/device/pwm1=50
MINSTART=hwmon1/device/pwm3=50 hwmon1/device/pwm1=50
MINSTOP=hwmon1/device/pwm3=120 hwmon1/device/pwm1=120
MINPWM=hwmon1/device/pwm3=0 hwmon1/device/pwm1=0
MAXPWM=hwmon1/device/pwm3=255 hwmon1/device/pwm1=255
INTERVALを 5 に設定して5秒間隔で制御を行うようにして、MINSTARTを 50、MINSTOPを 120 に設定。これでアイドル時は大体CPU温度は35℃でファン回転数は1100rpm。これくらいだとファンの音は全く聞こえない。CPU温度が37℃になって1200rpmを超えるとわずかながら音が聞こえるけど、それはCPUに負荷が掛かっているのが感じられて逆にいいかも。ちなみに36℃あたりを閾値に設定したのは体温と同じくらいだからという、ただそれだけ。全くもって根拠レス。Athlon X2 4050eってどのくらいの温度で皆さん使ってるのでしょう?

さて、これで無事ファン回転数のソフトウェア制御に成功したわけだけど、これだけ調子良く設定できたらやっぱり自動起動させたい。そこで解説に戻って、etc/init.d/fancontrolファイルをroot権限で作って、#!/bin/sh
#
# Fancontrol start script.
#

set -e

# Defaults
DAEMON=/usr/sbin/fancontrol
PIDFILE=/var/run/fancontrol.pid
PATH=/sbin:/bin:/usr/sbin:/usr/bin

test -f $DAEMON || exit 0

. /lib/lsb/init-functions

case "$1" in
start)
log_begin_msg "Starting fancontrol daemon..."
start-stop-daemon --start -o -q -m -b -p $PIDFILE -x $DAEMON
log_end_msg $?
;;
stop)
log_begin_msg "Stopping fancontrol daemon..."
start-stop-daemon --stop -o -q -p $PIDFILE
log_end_msg $?
;;
force-reload|restart)
sh $0 stop
sh $0 start
;;
*)
log_success_msg "Usage: /etc/init.d/fancontrol {start|stop|restart|force-reload}"
log_success_msg " start - starts system-wide fancontrol service"
log_success_msg " stop - stops system-wide fancontrol service"
log_success_msg " restart, force-reload - starts a new system-wide fancontrol service"
exit 1
;;
esac

exit 0
をコピペする。その後は$ sudo update-rc.d fancontrol defaults 99 01とスタートアップスクリプトを設定する。あ、そういえば、$ sudo chmod 0755 /etc/init.d/fancontrolこんなことや、$ sudo ln -s /etc/init.d/fancontrol /etc/rc3.d/S99fancontrolこんなこともしたかも。

ちなみに、Ksensorsは以前メニューには現れず、仕方ないのでメニューエディタで「アプリケーション」-「システムツール」にKsensorsを追加した。ちなみに追加したコマンドはgksu ksensors確かこれだけだと起動してくれなかったから /etc/sudoers に%admin ALL=(ALL) NOPASSWD: /usr/bin/ksensorsを追加した。そしてこれを自動起動させるには「システム」-「設定」-「セッション」の「追加」でgksu ksensorsコマンドを追加する。

これで完了。

PHPでメールが送れない

PHPでメールを送るのには大変苦労していたけど、pearのMail.phpモジュールを使うことでなんとか形になっていた。はずなんだけど、最近になってメールが送られない不具合が発生!

新しいサーバになってから、perl系のメールは確認したけどPHPは。。。 もしかしたら、モジュール毎にインストールが必要だったり。。。 ログを確認したら、Mail.phpがない、と。Pathは/usr/share/php, /usr/share/pearだっていうけど、どちらのディレクトリもない。どうもMail.phpはphp-mailにあるらしい。php-mail-mimeも関連しそうだからこれらをsynapticでインストールするとついでにphp5-cliとphp-pearもインストールされる。

しかし、それでもメールは送られない。またログを見ると、今度はphp-net-smtpがない、と。じゃ、synapticでいれましょ(いいのか、こんな行き当たりばったりで。。。)。php-net-smtpとついでにlibphp-phpmailerにも関係ありそうなのでチェック(いいのか、こんないいかげんなことで。。。)。すると、php-net-socketもついでにインストールされ無事にメール送信成功。

VMのCPU使用率

ホストOSがUbuntu 8.04.1 LTS Server x64であるVMware Server 2.0にて、ゲストOSにWinXPのVMとUbuntu 8.04.1 LTS Desktop x64のVMが作成されている。

WinXPのVMを起動させておくとホストOSのCPU周波数が1GHzになることはあまりないんだけど、UbuntuのVMでは放っておけば大体1GHzに落ち着く。VMにのせるゲストOSによってホストの負荷が変わるんだ。まあ、Windowsは元々ハードウェアリソースには厳しいからね。

Wordpress MU 2.6.3のインストール

Wordpress.comのようなマルチユーザのサイトを作ってみたいな。。。 と思ってググるとWordpress MUなるものがあるそうな。Wordpressは1.x時代から使ってるけど、真剣に調べたのは初めてだったりする。

Wordpress.comはAkismetのAPIキーをゲットするために登録して少し使ったことがあるけど、なかなかいい。Wordpress MUを使っているとのことだから、これは試してみないといけませんね。

テスト用にVMを用意して、ゲストOSはUbuntu 8.04.1 LTS Server x64を入れてある。tar.gz版を /home/user/puglic_html にダウンロードして、解凍する。そうすると wordpress-mu-2.6.3 というディレクトリができるので、wordpress-muとリネームしてどうせテスト環境なので http://127.0.0.1/wordpress-mu としてアクセスすることにする。ちなみに、http://localhost/wordpress-muでアクセスするとlocalhostではインストールできないと怒られる。なぜだろ。。。

http://127.0.0.1/wordpress-muにアクセスするといろいろと指示が英語で書かれているんだけど、ようするに

  • 空のデータベースを作ってね
  • /home/user/public_html/wordpress-mu /home/user/public_html/wordpress-mu/wp-contentのアクセス権を 777 にしてね
  • Apacheのmod_rewriteが有効にしてね

ということを言っている。

順に作業すると、ます空のデータベースは、
$ mysql -u user -p
パスワードを入力
> create database wordpress_mu;
> quit
で作る。ちなみに、データベース名に “-” は使えないらしい。アクセス権は$ chmod 777 /home/user/public_html/wordpress-mu /home/user/public_html/wordpress-mu/wp-contentを実行すればOK。Apacheのモジュール有効化は$ sudo a2enmod rewriteのコマンドを実行する。

ちなみに、Wordpress MUの複数のブログをサブドメイン別(blog1.domain.com, blog2.domain.com …)にするのか、サブディレクトリ別(www.domain.com/blog1, www.domain.com/blog2 …)にするのか決める必要がある。サブドメイン別にするとDNSの設定とか必要だから、面倒だからサブディレクトリ別にする。フォーラムによるとサブドメイン型が推奨されているけど。。。

そのあと再び http://127.0.0.1/wordpress-mu にアクセスするとSub-domains/Sub-directories, Database Name, User Name, Password, Database Host, Server Address, Site Title, Emailを聞かれるので正しく設定するとadminのパスワードとログインページへのボタンが表示される。あと、アクセス権は755に戻してとも言われる。$ chmod 755 /home/user/public_html/wordpress-mu /home/user/public_html/wordpress-mu/wp-contentとアクセス権を元に戻す。

パスワードをコピーしてボタンを押すと、見慣れたwordpressログインページが現れる。すべて英語でメニュー構成もwordpressとちょっと違う。まずはusersのadminのパスワードを変更しよう。

次に、日本語化を行おう。ここはwpmu-jaに2.6.2用の日本語化情報および言語ファイルがあるので、書いてあるままに作業する。ちなみに、日本語を選択する箇所は2つあって、settingsのlanguageとsite admin→optionのlanguage。あと、日付のフォーマットも「Y/n/j l」に変更。これは普通のWordpressと同じ。

この後はテストサイト/ユーザの作成、プラグインの導入とテーマの設定かな。とりあえず、今回はここまで。

ゲストOSでの音途切れ

VMware Server 2.0のゲストOSであるWinXPにおいて音楽を再生していると途中に途切れることがあることについて前に書いたけど、あれからちょろちょろと調べてみた。

ホストOSであるUbuntu 8.04.1 LTS Serverのサウンド設定において、デフォルトで選択されるpulseaudioの動作が重い、とどこかに書いてあった。で、それをalsaに変えてみたけど音途切れは相変わらず発生する。それよりか、いろいろと弄っていたらホスト側で音が出ていないことに気付いた。あわててサウンド設定を自動検出に戻してみたけどだめ。

どうやら、VMware Remote ConsoleでゲストOSを起動していると音声はそちらにとられてしまうらしい。ゲストOSをシャットダウンしたらホストOSの音が戻った。ここら辺が微妙で、ホストOSでCDなんかを再生しちゃうとなぜかゲストOSをそれから起動させても音が鳴らない。UbuntuというかLinuxのマルチメディアはまだまだツメが甘いかな。

あと、音途切れの原因を探るべくゲストOSにてリソースを「パフォーマンス」でチェックしてみたら、CPU、メモリ使用率、HDD転送量が頭打ちするときに起こることが分かった。要するに、リソース不足である、と。テスト機であるからそもそも省リソースの方針で、リソース増強はなんか違う。限られたリソースの中で音楽再生の優先度を上げられればいいのだけど。。。

hdaがsdbになった

先日HDDをSSDに換装して大いに快適になったテスト機。だけど、気がついたらVMが立ち上がらなくなっていた。原因はVMを入れていたドライブがマウントされていなかった。では、なぜマウントされなかったのか? その原因は、HDDを取り外したときに今までhdaと認識されていたドライブがsdbと認識されるようになったためだと分かった。ドライブはIDEのSSDなのでhd*として認識されていいのに。。。

なぜsd*と認識されているのか? を探索するより、こういうことがあるからUUIDが導入されたわけだからUUIDを使ってみよう、と思いたったのであった。

ドライブのUUIDをを調べるためには、コンソールにてsudo vol_id /dev/sdb1を実行すれば、ID_FS_USAGE=filesystem
ID_FS_TYPE=ext3
ID_FS_VERSION=1.0
ID_FS_UUID=344391d7-3b8b-4a57-8652-a3b97c3138ac
ID_FS_UUID_ENC=344391d7-3b8b-4a57-8652-a3b97c3138ac
ID_FS_LABEL=
ID_FS_LABEL_ENC=
ID_FS_LABEL_SAFE=
と表示される。ID_FS_UUIDが求めるUUIDで、これを/etc/fstabに設定する。# /dev/hda1 /var/lib/vmware/Virtual\040Machines/Virtual_Machine ext3 auto,users,rw,relatime 0 0
UUID=344391d7-3b8b-4a57-8652-a3b97c3138ac /var/lib/vmware/Virtual\040Machines/Virtual_Machine ext3 auto,users,rw,relatime 0 0
上の行が今までの設定でコメントアウトされている。

これでPCを再起動するとちゃんとドライブもマウントされ、VMもちゃんとVMware Serverに認識されVMが起動するようになった。

HDDからSSDへ

最近の高速SSDがどうしても試したくて。。。 といっても、いろいろと調べると安い高速SSDにはJMicronのJMF602というコントローラが使われてて、ある特定のディスクアクセスを行うと数十秒から数分OSがフリーズするらしい。プチフリーズ(プチフリ)と呼ばれるらしいが、どうも起きる人は気が狂うくらい起きて、起きない人は全く起きないのだとか。

まあ、これは試してみないといけないということで、TS32GSSD25S-Mを買ってみた。いわゆるハイスピード版と言われるもので、箱が黒と赤なのが目印(前のバージョンのものは青と緑)。

そして、試すならテスト機で、ということでUbuntu 8.04.1 LTS Server x64が乗っているHDDと交換することにした。面倒だし、最近はそこら中がベンチマークだらけなので性能比較は省略。

まずはSSDを追加してUbuntuのLiveCDを起動する。最初は面倒だったからHDDのパーティションをまっさらなSSDにGParted(パーティション・エディタ)でコピーしてbootフラグをonにしたけど、なぜかこの方法ではSSDからブートしない。LiveCDでマウントすれば中はちゃんと見えるし、ためしに/etc/fstabのUUIDの部分を/dev/sda1とかに変えてみたけど、そもそもgrubすら立ち上がっていないので効果なし。

でやっぱり定番のddでディスク全体をコピーすることにした。LiveCDで起動して、コンソールにて# dd if=/dev/sda of=/dev/sdb conv=sync,noerror bs=65536を実行する。ifが読み込みファイル/パーティション/ディスク、ofが書き出しファイル/パーティション/ディスクで、/dev/sda(こちらがHDD)
とsdb(こちらがSSD)と指定したのでディスク全体がコピーされる。convとbsパラメータの説明はdd –helpに表示されるので省略。

さすがはdd。今度はちゃんとSSDからブートすることができ、無事Ubuntuもその上のVMware Serverもその上のWinXPも起動した。なんといってもUbuntuがこれほど速く起動するのを見るのは初めてで驚き。VMware Remote Consoleなんて起動時のプログレスバーが20%のときに一瞬しか見えない。その上のゲストOSのWinXPは遅いSSDにVMが置かれているからこちらは変化なし。

HDDが20GBでSSDが32GBだったので、10GB程度が未使用になっている。これはもったいないので、またまたLiveCDで起動してGPartedにて(使ってない)swapパーティション(/dev/sda5)およびそれが格納されている論理パーティション(/dev/sda2)をSSDの後ろに移動して、HDDからコピーした基本パーティション(/dev/sda1)を開いたスペースに拡張する。ちなみにswapパーティションの移動は一発ではできなくて、

  1. swapパーティションを「swapをオフにする」で解除する
  2. 論理パーティションを後方に最大に拡大する
  3. swapパーティションを後方に最大に拡大する
  4. swapパーティションの開始位置を元の容量と同じになるように後方にスライドさせる
  5. 論理パーティションの開始位置をできる限り後方にスライドさせる
  6. 基本パーティションの終了位置を後方に最大に拡大する
  7. swap、論理パーティションにわずかな「隙間」ができるので、それらを微調整して埋める

これらの操作をまとめて実行する。swapおよび論理パーティションは元の容量ピッタリではないけど、元々スワップは使っていないので問題なし。

恐れていたfstabのUUIDの設定は全く心配に及ばなかった。プチフリも今のところは問題なし。って、まだ2時間程度しか使ってないけど。。。