iptablesのstringモジュールでバイト列にマッチさせる
特定の内容の通信だけを遮断したくなり、きっとiptablesに何かあるだろうと調べたらstringモジュールがあった。iptables 1.4.6のmanpageから引用する。
string
This modules matches a given string by using some pattern matching
strategy. It requires a linux kernel >= 2.6.14.
--algo {bm|kmp}
Select the pattern matching strategy. (bm = Boyer-Moore, kmp =
Knuth-Pratt-Morris)
--from offset
Set the offset from which it starts looking for any matching. If
not passed, default is 0.
--to offset
Set the offset from which it starts looking for any matching. If
not passed, default is the packet size.
[!] --string pattern
Matches the given pattern.
[!] --hex-string pattern
Matches the given pattern in hex notation.
遮断の条件に指定したい内容が非ASCIIのバイト列だったので--hex-stringを指定した。--hex-string 'e7a781e381aee5908de5898de381af...'のように。ところがうまくいかず、ありそうな書式をいくつか試しても変わりがない。ふと、試しに、文字列をそのまま(16進数表記にせずに)指定したところ、当初の意図の通りにマッチした。
どうやら何かの書式があるらしいと、iptablesのコードにあたったところ、以下のルールに従ってバイト列に変換されることがわかった。
- 「|」にはさまれた部分はバイト列の16進数表記として処理される
- それ以外の部分にある文字はその文字自身を表す
- ただし「\」により続く文字の特別な意味をキャンセルできる(「\|」や「\\」)
先の例については--hex-string '|e7a781e381aee5908de5898de381af...|'とするのが正しいやり方となる。また、--hex-string 'a|62|c'は「abc」にマッチし、--string abcや--hex-string abcを指定したのと同じ結果となる。指定できるバイト列の長さ(変換後の長さ)は128バイトまでのようだ。
--fromや--toの指定を加えると、マッチ対象とする範囲を指定できる。--from 20ならTCPヘッダ(など)以降(〜65535バイト目まで)が対象となり、特に指定しなければIPパケットの先頭から65535バイト目までが対象範囲となる。
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を使えばシステム時計の進み方や遅れ方を調整できる。
今読み書きしているプロセスを探す
何もやっていないのにディスクがカリカリいってる。おかしいな、何が動き出したんだろう。ということがついさっきあった。
Linuxではsysstatに含まれるpidstatを使うのが手っとり早いようだ(pidstatはsysstat 7.1.4以降に含まれている)。pidstatはプロセスの状態を報告するツールでvmstatなどと似た動作をする。
ディスクIOの様子を見るには-dオプションと、通常はインターバル、報告回数を与えて実行する。
$ pidstat -d 5 3 Linux 2.6.26-1-686-bigmem (hoge) 2009年04月03日 _i686_ (2 CPU) 09時00分50秒 PID kB_rd/s kB_wr/s kB_ccwr/s Command 09時00分55秒 1060 0.00 19.16 0.00 kjournald 09時00分55秒 3715 1.60 3.19 0.00 thunderbird-bin 09時00分55秒 PID kB_rd/s kB_wr/s kB_ccwr/s Command 09時01分00秒 1060 0.00 0.80 0.00 kjournald 09時01分00秒 1946 0.00 2.40 1.60 zsh 09時01分00秒 PID kB_rd/s kB_wr/s kB_ccwr/s Command 09時01分05秒 1060 0.00 24.00 0.00 kjournald 09時01分05秒 1946 0.00 0.80 0.80 zsh 09時01分05秒 23587 0.00 1.60 0.00 apache2 平均値: PID kB_rd/s kB_wr/s kB_ccwr/s Command 平均値: 1060 0.00 14.66 0.00 kjournald 平均値: 1946 0.00 1.07 0.80 zsh 平均値: 3715 0.53 1.07 0.00 thunderbird-bin 平均値: 23587 0.00 0.53 0.00 apache2
-pオプションによりプロセスIDを指定すれば、そのプロセスのIO状態を追跡することもできる。なお、pidstatのこの機能を使うにはLinux 2.6.20以降でなければならないようだ(pidstat(1)より)。
socat
一度焦点を合わせると様々なところで見付けるようになるものだけど、socatもそう。VMwareのときに使ったのは単なるコピー&ペーストだったが、今回はSSL接続をするためにmanpageをななめに読みながら使ってみた。といってもこんな程度からだけど:
$ socat STDIO OPENSSL:localhost:443,verify=0
むろんこの程度ならs_clientなんかで十分なのだけど、「どこかで見たな」をたぐってみるとDSAS開発者の部屋にreadlineを使ってmemcachedとの対話を編集機能付きで行う方法が紹介されていた。
$ socat READLINE,prompt='> ' TCP4:localhost:11211,crnl
こうなってくるとかなり便利なものになる。また、単純なところでも-vオプションでsocatを通り抜けるデータを表示させるいったことができる。今までほとんど活用してこなかったのがもったいない。
Xen徹底入門
今日は
Xen徹底入門の発売日。ということでいそいそと書店に行ったのだ。しかし、未入荷で入手できなかったよ。
この種の本の入荷はなぜか遅くなりがちなのだが、都内以外ではこんなものなのだろうか。それとも横浜、あるいは有隣堂での特性なのだろうか。
追記(2007-12-25): 買ってきた。いつ読むか。
RAID再構築
ここ三日ほどかけてRAIDの再構築をしている。時間がかかったのは何だかいろいろあったからで:
- バックアップのためにKNOPPIXを使ってdumpをとろうとしたら突然パネルが消えた→数時間かけて
dumpを実行中だった端末が消えた→何やらCDドライブでI/Oエラーが出ていた→ファイルシステムにアクセスできなくなって、いろいろ起きたようだ(もう少し後で気付いた) - Vine LinuxのCD-ROMでレスキューモードにしてバックアップをとった→
scpで別ホストにコピーを作っておこう→数時間後、受信側scpがコピー中に終了してしまった(らしい)→送信側はstalledのままで、ともかくコピー失敗 rsyncで再度コピーを行う→数時間後、~/.ssh/known_hostsにエントリを追加してもよいかどうかの問い合わせが→どうやらSSHセッションの張り直しらしく、裏の為にと思ってroでマウントしていたためのよう→yesと応答したらコピーが完了した→scpも同じような要因で、ただし問い合わせできなかったか、あるいはタイムアウトしたかではないかと想像- ARC-5010側でRAIDを再構築→うっかりバックグラウンドで実行してしまったためバックグラウンド動作の優先度を上げておく(20%→80%)→完了後、パーティション分割とファイルシステム作成を行おうとするも→後者にてエラーになる→多数のI/Oエラーが→ARC-5010側で優先度を元に戻してみた(80%→20%)ところ、ファイルシステムを作成できた→マウントしようとするとエラーに→I/Oエラー頻発でおかしな状態になったのかもと根拠の乏しい予想をたててリブート→実は
fdiskの時点でうまくいってなかったようでパーティションが切れてなかった→fdiskからやり直し - Vine LinuxのCD-ROMでもI/Oエラーが出ることが分かる→どうもCDドライブがおかしくなっているようだ→DVDドライブを買ってきたときに取り外したものに置き換える
そもそもの発端は、ホットスペアにと買ってきたHDDの容量がわずかに小さかったというなさけない話。これまで160GBのHDDを使用していたので同じ160GBのHDDを買ってきたところ、以前のものは実容量164GBだったのに対し、新しく買ってきたものはぴったり160GBだったという。すでに返品できない状態だったので、しょうがなく再構築をすることにしたのだけど、思いのほか時間がかかってしまっている。
ついでなのでARC-5010のファームを上げたりもしておいた。
Cyrus IMAPdでのメールボックスの復旧
メールを処理するスクリプトのexpireの設定を変えて再起動したところ以下のような感じのエラーになった。
open: user akira opened INBOX.Junk SQUAT failed to open index file SQUAT failed Fatal error: word too long
てっきりメールボックスが壊れたものだと思って(何度か壊れたことがある)cyrus.{cache,header,index}を削除してやり直したら、今度は単にメールボックスにアクセスできなくなった。たしかメールボックスを作り直すツールがあったよなとcyrreconstructを試すも、どうにもうまく動いてくれない。どうもメールボックスの指定方法が悪いらしい。いろいろ検索してみたりもしたのだけど、結局、試行錯誤の末に以下のコマンドラインで削除したファイルを再生成できた。
cyrreconstruct -rf user.akira.Junk
これで一安心と思ってスクリプトを再起動したら、なんとまた同じエラーが。今度はエラーメッセージ自体を調べてみたら、なんのことはない、IMAPコマンドが長すぎるという意味だった。とりあえず、一度に削除するメッセージ数をある程度以下にするようスクリプトを変更したところ、ようやくきちんと動くようになってくれた。
ちなみにSQUAT failedのほうはIMAP SEARCH用のインデックスファイルがないという意味で、これはそのようなインデックスを作っていないのなら無視してよいらしい。あるいはsquatter(8)を使ってインデックスを作っておくとIMAP SEARCHでそれが使われるようになるらしい。ただし、新しくメッセージが登録されてもインデックスは更新されないようで、cyrus.confのEVENTS { ... }で定期的にインデックスを再構築しなければならないとのこと(更新ではない)。
uim-gtk2.0→scim-qtimm
これまでGNOME環境ではuim-gtk2.0(uim-tutcode)を使っていたので、KDE環境でもuim-qt(uim-tutcode)を使っていた。だが、入力中に英数字入力モードにしていても矢印キーで前後に移動したとたんに日本語モードに戻ってしまうという現象にあってどうしようもなくなった。意図せずモードがコロコロ変わるのでストレスがすごい。
おまけに、おそらく根は同じ現象なんだろうけど、パスワードを入力するようなダイアログで英数字入力モードにしていても一文字入力するごとに日本語入力モードになるという現象も起きていて、これはいつものパスワードを入力するのにすら四苦八苦する(そもそもデフォルトが日本語入力モードになるのも謎な感じなのだけど)。
それではSCIMのほうはどうかなっていうことでscim-qtimm(scim-uim - uim-tutcode)というのを試してみた。と、こちらはまったく問題ない。じゃあこれでいきましょうと思ったんだが、デスクトップ環境のデフォルトの設定にするやり方がよく分かんない。何がデフォルトのIMをコントロールしているのやら。
ということで、ちょっとさぐったところim-switchが出てきた。どうやらこれをいじればよさそうだ。マニュアルをちょっと見て、grepをかけたりしながら~/.xinput.d/qtscim-gtkuim-ximuimを以下の内容で作ってim-switch -cしておいた。
XIM=SCIM XIM_PROGRAM=/usr/bin/scim XIM_ARGS="-d" GTK_IM_MODULE=uim QT_IM_MODULE=scim DEPENDS="scim,scim-qtimm,scim-anthy|scim-canna|scim-chewing|scim-pinyin|scim-hangle|scim-prime|scim-skk|scim-tables-additional|scim-m17n|scim-uim|scim-tables-ja|scim-tables-ko|scim-tables-zh,uim-xim,uim-gtk2.0,uim-anthy|uim-canna|uim-prime|uim-skk|uim-m17nlib"
Gtk側もSCIMにしちゃえばいいんだろうけど、とりあえずGtk側は以前のままということで。いや、それはいいけどscim-qtimmが/etc/X11/xinit/xinput.d以下にファイルを提供してないのはなぜだろう。デフォルトではscim-qtimmを誰も有効にしてくれないような? (もしやバグってる?)
そんなこんなで初めてim-switch設定だった。
GtkでもSCIM
結局、Gtk側でもSCIMを用いるようにした。やはりim-switchの設定を適当に書いて対処する。前述の通り/etc/X11/xinit/xinput.d/scim-immoduleで以下のように書かれているのがひっかかるが、これまでの数時間使ったところでは特に問題はなさそうだ。
# Qt immodule is not ready #QT_IM_MODULE=scim
むしろFirefoxとの相性はSCIMのほうが良いようだ。どうも特定の環境でしか起きないのか、他所では見掛けないのだが、URL欄で矢印キーの上下の動作が変になるとか、formのオートコンプリートの選択子をマウスを使わなければ選択できないとか、オートコンプリート中のformについて、手入力してenterキーをたたいてもオートコンプリートの選択子の表示が消えてくれなくて先に進めないだとか、そういった困ったことがあったのが、SCIMにすることで解消した。
というわけでimmoduleはscimのほうが良さそうかな。もちろんuim-tutcodeを手放せなくなっているのでuimもありがたく使い続けている。
追記(2007-10-22): *** glibc detected *** /path/to/vmware: double free or corruption (out): 0x09233cc8 ***などといってVMwareを起動できなくなっていることに気付いた。どうやらVMwareはSCIMではダメらしくGTK_IM_MODULEを変更したら起動した。
