Debian Ruby1.9会議の詳細のお知らせ
先日お知らせしたDebian Ruby1.9会議の開催日時と場所が以下に決まりました。
- 日時: 2009-07-05(日) 14:00〜17:00
- 場所: かながわ労働プラザ 第10会議室
参加される方へのお願い
参加される方との連絡・情報交換のためにGoogleグループに場を設けています。ATNDで参加登録された方は、私(akira.yamada gmail.com)まで以下の二点をお知らせください。
- 登録するメールアドレス
- ATNDでのユーザ名
分割パッケージをまるごとインストール
今月の![Software Design (ソフトウエア デザイン) 2009年 07月号 [雑誌]](http://ecx.images-amazon.com/images/I/51MbHYNCDkL._SL75_.jpg "Software Design (ソフトウエア デザイン) 2009年 07月号 [雑誌]")
Software Design(2009/7号)はDebian特集であった。パラパラとながめていって、ふとパッケージ情報にアクセスするツールを調べ直したくなった。
といっても--helpしてみたり、manページを見たりといった程度。そんな中、grep-dctrlに便利な機能が加わっているのに気付いた(etchのころにはもうあったようだが気付いていなかった、とも言える)。その機能というのは-Sオプション。-Sオプションは-F Source:Packageの短縮形で、パッケージ情報にSourceフィールドがあればそれに対して、なければPackageフィールドに対してパターンマッチを行う。
各バイナリパッケージのパッケージ情報には、そのバイナリパッケージを作るもととなったソースパッケージが何であるかが含まれいることがある。一つのソースパッケージから複数のバイナリパッケージが生成されることがあるためで、ソースパッケージ名とバイナリパッケージ名が異なる場合にSourceフィールドが現れ、その値としてソースパッケージ名が記述される。
あるソースパッケージから生成されるすべてバイナリパッケージを探し出したいとするとき-Sオプションが便利だ。たとえば、ソースパッケージruby1.8から生成される、つまり、パッケージとして提供されるRuby 1.8の全部をインストールしたいとすると、次のようなコマンドラインが考えられる。
$ grep-aptavail -n -X -s Package -S ruby1.8 | xargs sudo aptitude install
(しばし余談)
ここで、-Sオプションではなく、-F Source,Packageでも実現できるのではないかと思える。「:」でなく「,」で区切った場合、そのうちのどれかにマッチしたものが出力されるからだ。だが、実際にやってみるとこれはうまくいかない。なぜかというと、あるソースパッケージの名前と同じ名前のバイナリパッケージを生成する別のソースパッケージというのが存在する可能性があるのだ。
$ grep-aptavail -X -s Package,Source -S libqt4-ruby Package: libsmokeqt4-1 Source: libqt4-ruby Package: libsmokeqt4-dev Source: libqt4-ruby $ grep-aptavail -X -s Package,Source -F Source,Package libqt4-ruby Package: libsmokeqt4-1 Source: libqt4-ruby Package: libsmokeqt4-dev Source: libqt4-ruby Package: libqt4-ruby Source: kdebindings
libqt4-rubyは一例で他にもいくつかある。このような状態はリリース間でパッケージ構成が変わったなど、特別なケースであることが多いと思うが、そういうこともありうるという点には気を付けておいたほうがよいだろう。
(本題に戻る)
sarge以降(あえてsargeという :-)、apt-getではなくaptitudeが用いられていることと思うが、最近のaptitudeの検索パターンは実に充実していることにも気付いた。ソースパッケージruby1.8から生成されたパッケージを選び出してインストールしたければ、次のようにコマンド実行すればよい。
# aptitude install '?source-package(^ruby1\.8$)'
Debian Ruby1.9会議のお知らせ 2
きたる2009-07-05(日)にDebian Ruby1.9会議を開催することになりました。Debianにおける主要なRubyパッケージ開発者のうちの実に二名が参加することが決定しています…… とか言っても、お気付きの通り、そのうちの一人は私です。
今回の開催はRubyパッケージやRubyGemsのパッケージの開発者であるdaigoさんから声をかけていただいたのがきっかけです。現在、構成変更などの議論を進めている関係で、Debian/sidにおけるRuby 1.9のパッケージのリリースが遅れています。その状況を改めて確認し、解決しなければならないことや決定しなければならいことを話し合い、物事を先に進めていこうというのが主旨です。
かなり奥まったところにある話題なので、興味を持つ人は限られるかもしれませんが、話を聞いてみたい、意見がある、パッケージ開発者を見てみたい、といった方がおられましたらご参加ください。Debian Ruby1.9会議の参加登録はATNDで受け付けています。
開催地は川崎〜横浜のどこかになることが決定しています。ただし具体的な会場などは未定で、二人以外の参加者がどれくらいあるかに応じて会場を確保したいと考えています。
私個人としては、参加者がある程度集まって、時間に余裕があるようなら、おまけ的にRuby on Debian談義をするのも悪くないかなと思っていますが、これは単に思い付きレベルの話で未定です。(それにしても奥まった話題のような気もしますが。)
WEB+DB PRESS Vol.50
4月24日に発売になる
WEB+DB PRESS Vol.50[rakuten]で「Unix/Linux開発環境ミニマルスタイル」という記事を書かせてもらいました。
主な作業環境はMS-Windowsだけれども、本番環境はUNIX系OSである。本番環境での作業にはいつも通りの手順(や決められた手順)があるから困りはしない。ただイレギュラーな状態になると手も足も出ない(かもしれない)。コードやログを持ってきたり持っていったりを繰り返すのも煩わしいし、UNIX側でできることがもう少し増やせるとよいな。そんな人々に向けた記事です。
端末・シェル上での操作の基本を扱います。基本的なコマンドの紹介、リダイレクト・パイプの仕組みと使用例、コマンドを組み合わせて使う方法などを説明しています。環境としてはDebian/Ubuntuを想定しています。また、近年、一般的に使われるようになってきている仮想環境(andLinux、VMware系プロダクト、VirtualBox)を念頭に、パッケージ運用管理の基礎的な部分もカバーしました。
今号ではJunio C Hamanoさんの大ボリューム特集記事「はじめてのGit」で、基本的なところからから、一般的な使い方としては十分すぎるくらい深いところまで、かなり広範かつ詳細な解説がなされていて読みごたえがあります。またknuさんのPractical Ruby Programming!(6)では誰もが使うようになってきているTwitterと、注目されつつもなかなかブレイクしかけてますという状況が続いているFriendFeedの、それぞれのAPIを使って両者を結び付けるプログラムtw2ffが作成されていています(tw2ffはruby-friendfeedに含まれています)。
今号の内容からは離れてますが、FriendFeed関係では、携帯電話端末などからFriendFeedを使いやすくするf2pというアプリケーションもあります。当初はまはさに携帯からFriendFeedを使うために利用していましたが、「後で読む」機能や地理情報付きのポストができるなど、FriendFeedの標準的なインタフェースにはない機能があるため、最近ではPCでもf2pを介してFriendFeedを利用することが多くなっています。
ruby-friendfeedもf2pもGitでアクセスできるgithub上にありますから、Git大特集から読み進めると、自然とFriendFeedまでたどりつくようにできていますね。加えていえば、同時期に発売されるSoftware Design 2009/05の「はてな流! システム管理のツボ(10)」ではCapistranoが扱われていますので、あわせて読めばRailsアプリケーションであるf2pのデプロイも万全です。
そういうわけで、聞いたことはあるけれどもまだ使っていないという人は、これを機会にFriendFeedを始めてみてはいかがでしょうか。
(ちなみにSD誌の特集ではUbuntuが扱われています。私の記事とともに、などというのはおこがましいですが、これからUbuntuを始めるという人は参考にしてみてはいかがでしょう。)
adjtimexによる時計の調整
あるマシンでetch→lennyとしたところ、いつまで待ってもNTPで時刻同期できない状態になってしまった。こんなときはadjtimexを使えば良かったんだっけと、あまりあてにならない記憶に従ってみた。
# dpkg-reconfigure adjtimex
これは/usr/sbin/adjtimexconfigを実行すると同じようなことで、adjtimexconfigはadjtimex --adjustを実行するとの同じようなことである。adjtimex --adjustは時刻のズレを調整してくれるものであったと考えていたのだが、結果からすると状況を改善することができなかった。
以前にも何度かこの手の格闘をしてきており、その都度、調べたり試したりで状況を治めてきたはずなのに、などと今度も思いつつ、しょうがないからadjtimexのマニュアルをななめに見てからadjtimexconfigをななめに見て、/etc/default/adjtimexに記述されているTICKとFREQを調整すれば良さそうだというところにたどりついた。
TICKとFREQはadjtimexの--tickおよび--frequencyという二つのオプションに対する引数として使われている。
USER_HZ=100の一般的な環境では一秒間に100回の割り込みがあり、システム時計はそのたびに10,000msずつ進められる…… というのが理想的な状態。実際にはそううまくいかないわけで、システム時計の進め幅を調整する必要が出てくる。
--tickオプションはこの進め幅を指定する。単位はmsなので10,000前後の値となる。10,000→10,001と変えたとすると、一秒(割り込み100回)あたり100ms、一日で8.64秒だけシステム時計の進みが速くなる。--tickオプションよりも小さな幅で調整するのが--frequencyオプションで、0を基本として、進めるなら正の値、遅らせるなら負の値を指定する。--frequency 65536とすると、一秒あたり1msだけシステム時計が速く進むようになる。
# vi /etc/default/adjtimex # update-rc.d adjtimex start; ntpdate -bv ntpserver; sleep 100; ntpdate -bv ntpserver
なんて感じで、前述の二つの値の上下を繰り返しながら、システム時計の進みを調整し、ようやくNTPによる時刻同期がとれるようになった。
adjtimexの使い方
後になってadjtimex(8)を見直してみると、そんな繰り返しをしなくてもよさそうな機能が備っていることがわかった。当然ともいえる。
まず--compareオプション。これを指定して実行すると、10秒間隔でRTC(ハードウェア上の時計)とシステム時計を読み取って、そのズレの度合いを導き出すことができる。また適切と考えられるTICK/FREQの値も同時に導き出される。このときの基準はRTCだが、adjtimex --log --host ntpserverのように指定して実行すると、ntpdateによりNTP時刻を参照した上で、それとのズレが/var/log/clocks.logに記録される。このファイルの内容はadjtimex --reviewにより参照でき、NTP時刻を基準にした場合のTICK/FREQが導かれる。
ここで--adjustオプションに戻ってみると、これは--compareの結果をそのまま設定してしまうという動作をさせるオプションである。つまり、RTCを信頼してシステム時計を調整するためのオプションである。となると、発端となったホストのRTCはあまり正確ではなく、adjtimex --adjustをしてもシステム時計の進みはおかしなまま。その結果としてNTPが許容できる範囲を越えたシステム時計の進み具合い(または遅れ具合い)となり、同期がとれなくなったものと考えられる。
実際、以下のようにadjtimexを実行すると、RTCがどんどんズレていく様子が見られる。
# adjtimex --compare
--- current --- -- suggested --
cmos time system-cmos error_ppm tick freq tick freq
1240113783 -0.037287
1240113792 0.063180 10046.7 9999 4807606
1240113801 0.163457 10027.8 9999 4807606 9899 2986972
1240113810 0.263660 10020.3 9999 4807606 9899 3479160
1240113819 0.363839 10017.9 9999 4807606 9899 3635410
1240113828 0.463941 10010.2 9999 4807606 9899 4140098
1240113837 0.564190 10024.9 9999 4807606 9899 3176035
1240113846 0.664455 10026.6 9999 4807606 9899 3066660
adjtimexでシステム時計を調整する
問題のホストとは別のホストでadjtimexによるシステム時計の調整を試みた。
まず、adjtimexconfigを使ってみる。前述の通り、これはadjtimex --adjustを実行するのと同等であり、システム時計の進み具合をRTCの進み具合に合わせるための調整となる。設定された内容はadjtimex --printにより確認できる。
$ adjtimex --print
mode: 0
offset: 0
frequency: 5951052
maxerror: 16000000
esterror: 16000000
status: 65
time_constant: 10
precision: 1
tolerance: 32768000
tick: 9999
raw time: 1240109330s 387925us = 1240109330.387925
return value = 5
NTP時刻との比較を行ってみたところ、以下のようにこのホストのRTCはなかなか正確であることがわかる。
$ ntpdate -q ntpserver; sleep 100; ntpdate -q ntpserver server 172.16.100.100, stratum 3, offset 0.079893, delay 0.02580 19 Apr 11:45:42 ntpdate[24278]: adjust time server 172.16.100.100 offset 0.079893 sec server 172.16.100.100, stratum 3, offset 0.084867, delay 0.02580 19 Apr 11:47:22 ntpdate[24289]: adjust time server 172.16.100.100 offset 0.084867 sec
adjtimexでシステム時計をNTP時刻に合わせる
次に--logオプションと--hostオプションを使って、NTP時刻を基準にした調整を行ってみる。adjtimexconfigでは調整に70秒の時間をとっているため、ここでも70秒だけおいてみることにした。まずはシステム時計の進み具合いを調査する。
# adjtimex --tick 10000 --frequency 0 (上の設定をリセットするために実行)
# adjtimex --log --host ntpserver; sleep 70; adjtimex --log --host ntpserver
reference time is Sun Apr 19 11:49:11 2009
reference time - system time = 1240109351.090 - 1240109351.000 = 0.090 sec
No previous clock comparison in log file
Are you sure that, since Thu Jan 1 09:00:00 1970,
the real time clock (cmos clock) has run continuously,
it has not been reset with `/sbin/hwclock',
no operating system other than Linux has been running, and
ntpd has not been running? (y/n) [n] (ここで一回目のadjtimexが終了)
reference time is Sun Apr 19 11:50:27 2009
reference time - system time = 1240109427.093 - 1240109427.000 = 0.093 sec
Last clock comparison was at Sun Apr 19 11:49:11 2009
Kernel time variables are unchanged - good.
System clock is currently not disciplined - good.
Checking wtmp file...
System has not booted since Sun Apr 19 11:49:11 2009 - good.
System time has not been changed since Sun Apr 19 11:49:11 2009 - good.
Checking /etc/adjtime...
/sbin/hwclock has not set system time and adjusted the cmos clock
since Sun Apr 19 11:49:11 2009 - good.
Are you sure that, since Sun Apr 19 11:49:11 2009,
the system clock has run continuously,
it has not been reset with `date' or `/sbin/hwclock`,
the kernel time variables have not been changed, and
the computer has not been suspended? (y/n) [y]
The estimated error in system time is -40.6706732 +- 0.0458581 ppm
Are you sure that, since Sun Apr 19 11:49:11 2009,
the real time clock (cmos clock) has run continuously,
it has not been reset with `/sbin/hwclock',
no operating system other than Linux has been running, and
ntpd has not been running? (y/n) [y]
The estimated error in the cmos clock is -52.00 +- 0.05 ppm
これにより得られた情報で設定をする。このために指定するのはやはり--adjustオプションだが、さらに--reviewオプションも指定する。
--reviewは--logにより記録された情報を参照するためのオプションで、記録情報からTICK/FREQを導き出すことができる。これを--adjustとともに使うと、RTCとの比較にからず、記録情報か得られたTICK/FREQを設定できる。
# adjtimex --adjust --review
start finish days sys - cmos (ppm)
Sun Apr 19 11:49:11 2009 Sun Apr 19 11:50:27 2009 0.0009 13.2 +- 0.2
start finish days cmos_error (ppm)
Sun Apr 19 11:49:11 2009 Sun Apr 19 11:50:27 2009 0.0009 -53.83 +- 0.03
start finish days sys_error (ppm)
Sun Apr 19 11:49:11 2009 Sun Apr 19 11:50:27 2009 0.0009 -40.67 +- 0.03
least-squares solution:
cmos_error = -53.8 +- 0.3 ppm
suggested adjustment = 4.6511 sec/day
current adjustment = 0.0038 sec/day
sys_error = -40.7 +- 0.3 ppm
suggested tick = 10000 freq = 2665447
current tick = 10000 freq = 0
note: clock variations and unstated data errors may mean that the
least squares solution has a bigger error than estimated here
new tick = 10000 freq = 2665447
以上により、NTP時刻を基準としてシステム時計の調整を行うことができたはずである。先程と同様にNTP時刻との比較をしてみる。
$ ntpdate -q ntpwerver; sleep 100; ntpdate -q ntpserver server 172.16.100.100, stratum 3, offset 0.094815, delay 0.02580 19 Apr 11:51:24 ntpdate[24319]: adjust time server 172.16.100.100 offset 0.094815 sec server 172.16.100.100, stratum 3, offset 0.094798, delay 0.02580 19 Apr 11:53:04 ntpdate[24325]: adjust time server 172.16.100.100 offset 0.094798 sec
ここではNTPによる時刻同期をしたわけではないので時刻のズレ自体は問題ではない。時刻のズレの進み具合いが問題となる。adjtimexconfigによる調整では一秒につき(0.084867 - 0.079893)/100 = 49.74msづつNTP時刻よりも進んでいくことがわかる。一方、NTPを使ってadjtimexしたあとでは一秒につき(0.094798 - 0.094815)/100 = -0.17msづつNTP時刻よりも進んでいく(つまり0.17msずつ遅れていく)。
hwclockとの関係
adjtimex --compareや--adjustでは、RTCから値を読み取る際に/etc/adjtimeの内容による補正を行っている。同ファイルはhwclockにより作られるものである。
hwclockは、RTCを書き換えるときに、RTCの値との差分を/etc/adjtimeに記録する。そしてhwclockでシステム時刻を設定する際にはRTCの値そのものではなく/etc/adjtimeに記録されている情報でRTCの値を補正したものを設定する。つまりシステム時計を基準にしたときのRTCのズレ具合いが/etc/adjtimeに記録されているということを意味する。
hwclockによって行われる調整は、RTCからシステム時刻を得るときに使われるものである。これはシステム時計の進み方や遅れ方を調整するものではない。むしろシステム時計が未調整であるならばhwclockの仕組み使った結果としてシステム時刻は適切にズレてしまうことになるとも言える。
簡単なまとめ
RTCは通常、一定の進み方を示すか、一定の遅れ方を示す。この幅が小さければ実用上、時刻のズレで困ることはない。あるいはNTPにより時刻同期が可能である。最近のPCであれば、NTPで対処できないほどにRTCがズレるということもないのではないかと思う。したがってここに書いたようなことをする必要はあまりない。
ただ、NTPでもどうにもならないといったときにはadjtimexの出番となる。adjtimexを使えばシステム時計の進み方や遅れ方を調整できる。
売り切れてなかった
以前、売り切れになっちゃったかしらと見ていた![[入門] Debian パッケージ](http://ecx.images-amazon.com/images/I/51NA517PXTL._SL160_.jpg "[入門] Debian パッケージ")
[入門] Debianパッケージ[rakuten]だが、昨日尋ねられたので久しぶりに確認してみたところ、現在はまた購入できるようになっていた。
内容はこちらをどうぞ。
ATI X1550でCompiz
ATI X1550を買ってきた。おそらく現時点ではふたむかし前くらいのビデオカードなのかもしれないが、そもそもこれはCompizを動かしてみたいというのが直接の理由で、そのあたりの条件が整って、Xで問題なくて、あんまり高くなないものってなに? といつものごとくhanzubon先生に尋ねたもの。
オンボードでないビデオカードを使うこと自体ずいぶん久しぶり。もうAGPですらない上にDVIなんだなあなどとかなり今更なことを思ったりなんかしながら取り付ける。作業が終わってさあどんなものかと電源を入れると、画面が黒いまま立ち上がってきた。どうしようもないので電源を落とし、再度接続を確認して電源を入れ直すも変わりなし。もう一度電源オフ……。
あと確認してないのはケーブルだからとケーブルを変えたらこれが当たり。無事、画面が出るようになったのは良かったものの、二度の電源オフでfsck終了を待つはめに。
そんなことをしながらもなんとか普通にマシンが立ち上がるようになったので、Xの設定をしようとdpkg-reconfigure xserver-xorgを実行すると、xorg.confの中がスカスカになってしまった。あれれと思ったんだけれども、今はこんなものなんだなあ。何か間違えたのかと思って数回繰り返してしまったがすべて無駄だった。
さて、Xも立ち上がるようになった。ではとcompiz --replaceを実行するも元に戻ってしまう。どうも必要な機能が足りてないらしい。おかしい。検索しながらfglrxなドライバを組み込んでみたりしてもダメで、というかXが立ち上がんなかったりとかいろいろで、行きづまってしまった。うーんと再びヘルプをお願いすると、experimentalからxorgを入れてしまうのが楽だとのこと。1:6.9.0+git20080826.a3cc1d7a-2なるバージョンのパッケージに更新して再びcompiz --replaceを……
$ compiz --replace
Checking for Xgl: not present.
Detected PCI ID for VGA:
Checking for texture_from_pixmap: not present.
Trying again with indirect rendering:
Checking for texture_from_pixmap: present.
Checking for non power of two support: present.
Checking for Composite extension: present.
Comparing resolution (1600x1200) to maximum 3D texture size (4096): Passed.
Checking for nVidia: not present.
Checking for FBConfig: present.
Checking for Xgl: not present.
Starting gtk-window-decorator
/usr/bin/compiz: line 393: 6368 セグメンテーション違反です ${COMPIZ_BIN_PATH}${COMPIZ_NAME} $COMPIZ_OPTIONS "$@" $COMPIZ_PLUGINS
Xglがねーって言われるよ。今時はないものだ。などとさらに教えてもらいながら、裏で検索を繰り返しながら、行きついたのがCompiz with ATI RS480 on Debianという記事:
Install compizconfig-settings-manager and compiz-fusion-plugins-extra
For some reason, the first time I've tried running compiz it's gone Segmentation Fault. On the IRC channel they hinted me to install the crash handler plugin to back track the error. After installing such packages, magically compiz --replace worked!
[Compiz with ATI RS480 on Debianより引用]
ここにある通りcompizconfig-settings-managerとcompiz-fusion-plugins-extraをインストールしたらsegvしなくなった。うへー、そういうもんか、と思ったが、とりあえずは動いたのでOK。この記事を読むと、今日何時間かかけて、みなに教わりながらやってきたことが、短くまめられていることが分かる。やあ、つかれた。
ところで大本の発端はというと、KDE 4.1の動きがおかしいことだったりする。しばらくKDEで生活していて、機能的にはわりといけてるかなと思っていたのだけど、何かのはずみ(どうもFirefoxの何かっぽいのだがよく分からない)で画面が点滅しだし、八割以上の確率でやがてブラックアウトするというのを何度か経験した(プロセスは生きてて、何かのはずみで戻ることもあるのだが)。どうにも困るのでGNOMEに戻ったのだが…… というところで、Compizを試そうとしたけどオンボードVGAはブラックリスト上にあってダメ。ブラックリストは無視させることができるので、ともかく動かしてみようとしたのだけどもsegvしてしまう。ええこの際、と今回の話になったのだった。
このsegvって、もしや上のと同じ理由だったりするのかなあ。
ま、それはさておき。今回、参考になった情報のまとめ:
- hanzubon助言
- Compiz with ATI RS480 on Debian - 上述の通り
- Debian Wiki/Compiz - 最初に見る情報
- Debian HOW-TO : AIGLX + Compiz - ちょっと古いようだけど確認方法などが少し参考になった
「この APT が対応している以上の数の説明が要求されました。」
$ apt-cache policy apt E: この APT が対応している以上の数の説明が要求されました。 E: Problem with MergeList /var/lib/dpkg/status $ LANG=C apt-cache policy apt apt: Installed: 0.7.14+b1 Candidate: 0.7.14+b1 Version table: *** 0.7.14+b1 0 [...]
日本語環境でなければそういうこともないので、なんだろうとしばし考えてしまった。日本語訳されたパッケージ情報を扱えるようになったためということのようだ。同じ環境で以下のように、翻訳情報を扱わないようにするとこの現象は起きなくなる。
$ apt-cache -o APT::Acquire::Translation=none policy apt apt: インストールされているバージョン: 0.7.14+b1 候補: 0.7.14+b1 バージョンテーブル: *** 0.7.14+b1 0 [...]
日本語情報がどうしても必要ということもないので…… というか、あらゆる場面で同じエラーが出てしまっているので、とりあえずはapt.conf.dに書いておこう。
最近APTが遅いなあと思ってはいたのだけど、これも同じ原因のようだ。ま、扱うデータ量は単純に考えると倍以上になりそうだからしょうがないのかな。
Capistrano 2.1向けのAPTレシピ
昨日のコードを置いておく → recipes/apt.rb
久々にコードを追いかけて、実際にコードを書いたりもしてみたので、忘れないうちに書きかけのドキュメントを…… と思うものの、もうしばらくは時間をとれないっぽい。
