3.1にしたからなのかiTunesが9.0になったからなのかは知らねど、今回のアップデートでの一番の収穫は、『同期しても、どこまでiPodで聞いていたかを覚えている』ってことだ。細かいことだが、この小さな修正がとても嬉しい。
音楽プレーヤーをiPhoneに切り変えての不満はいくつかあるんだけど、その最たるものが、同期するとどこまで聞いていたかを忘れてしまうってこと。あ、いや、iPodだって忘れるんだけど、そもそもiPodはそうそう同期したりしない。でもiPhoneだとしょっちゅう同期するんだ。iCalやらメモやら、同期しておきたいデータが日々発生するからね。
きっと、「再生中」のアルバムに変化があると、さすがに忘れるんだろうけど、同期対象のスマートプレイリストが変化したくらいでは忘れなかった。よしよし。
書かなかったけど、先週末はSnow Leopardへのアップグレードと、FONの導入で暮れた。先々週末はMac miniの更新で暮れた。んじゃその前のお盆休みはというと、iPhone導入で暮れていたのであった。
今週末は親戚のお葬式で暮れてしまった。親・親戚からのメールはSoftbankが用意した@i.softbank.jpなメールサーバーへ転送して読むようにしてたのだが、式場ではWi-Fiなんぞの設備は使えず悲しい思いをした。遺族が用意してくれていたビジネスホテルにはさすがにWi-Fiの設備があったのだが、なぜか部屋のある階だけは使えなかったというお粗末具合で、この二日だけでパケット代は上限に達したことだろう。
そんなこんなで、メール環境をなんとかせねばという気になった。今のままでは、Softbankへ転送している分しか読めない。Thinkpad X61sを持ち歩いてsshで… という従来の方法でも旅行規模の移動であればいいんだが、せっかくスマートフォンを持っているんだから、ちょっとした外出程度ならiPhoneだけで済ませたい。
つうかキャプチャのように、iPhoneにはMacのメールアカウント情報が同期されていて、どうか使ってくださいと誘っているのだ。ついつい使いたくなるのは人情である。もちろんこの「IMAP アカウント」は自宅のファイアウォールの内側でなければ利用できないように制限してある。外部からのアクセスを許せる程きちんと構築してないからだ。とりあえず自宅では寝っ転がってメールが使えてたわけだが、一度この便利さを味わってしまうと、いつでもどこでも使えるようにしたくなるのも人情である。どうにかして外に持ち出さなくては。
ということでVPNすることにした。IP-Secはあれこれ面倒だったので、スグに使えるPPTPで。
使うのは自分だけなので、同時3クライアントも割り当てる必要はないんだが、YAMAHA RT の設定事例集ほぼそのままで設定した。事例集から変えたのは、IPアドレスを自宅プライベートネットの一部にしたことと、pp auth requestをmschap-v2にしたくらい。mschap-v2はiPhone 側の要件である。
pp select anonymous pp bind tunnel1-tunnel3 pp auth request mschap-v2 pp auth username USERNAME PASSWORD ppp ipcp ipaddress on ppp ipcp msext on ppp ccp type mppe-any ip pp remote address pool x.x.x.100-x.x.x.102 ip pp mtu 1280 pptp service type server pp enable anonymous tunnel select 1 tunnel encapsulation pptp tunnel enable 1 tunnel select 2 tunnel encapsulation pptp tunnel enable 2 tunnel select 3 tunnel encapsulation pptp tunnel enable 3 pptp service on pptp syslog on
自宅プライベートアドレスではNATを使っているので、プライベートネットへ降ろしているrtx1000のアドレス(ここでは x.x.x.254)にポートの固定設定を追加する。
nat descriptor masquerade static 1 1 x.x.x.254 tcp 1723 nat descriptor masquerade static 1 2 x.x.x.254 gre
同様にfilterも作る。
ip filter xxxx0 pass-log * x.x.x.254 tcp * 1723 ip filter xxxx1 pass-log * x.x.x.254 gre
この2つのfilterは当然pp側のinに割り当てる。
サーバには、NATのouterに割り当てているアドレスを指定。とりあえずパスワードは毎回確認のままにしておく。こうしておくと、右端キャプチャのように、設定のトップ画面にVPNが現れる。ここをオンにするとパスワードをきいてくる。接続が完了すると上部にVPNマークが表示される。されたら、メールを好きに読めるようになるのだ。ふふふのふ。
キャプチャを見るとわかるが、このテストのためにわざとWi-Fiを切って3Gで確認している。実際の利用時はもちろんWi-Fi利用が前提。そのためにFONにも参加してるのだ。
さて、接続してくるとrtx1000にはこんなログが残される。
Sep 6 21:51:38 mobgw TUNNEL[01] PPTP connection is established: 126.y.y.y Sep 6 21:51:39 mobgw PP[ANONYMOUS01] PPTP Connect Sep 6 21:51:44 mobgw PP[ANONYMOUS01] Call detected from user 'XX' Sep 6 21:51:47 mobgw PP[ANONYMOUS01] PPP/IPV6CP up Sep 6 21:51:48 mobgw PP[ANONYMOUS01] PPP/IPCP up Sep 6 21:53:28 mobgw PP[ANONYMOUS01] IP Commencing: TCP 家の IMAP サーバ:143 > x.x.x.100:57507 Sep 6 21:53:32 mobgw TUNNEL[01] PPTP connection is closed: 126.y.y.y
実際には、filterを通過したログがテンコ盛りに表示されるのだが目障りなのでここでは削っている。PPTPポートへのアタックがどれくらいあるものなのかを知らないので、ログは監視しておく必要がある。パターンが把握できるまでは目視だなぁ。
今回更新対象のMac miniは発売直後に買っている。今年の3月のことだ。なのに5ヶ月も放置してた。移行が面倒だったのだ。せめてメモリが4GBあればといつも思っていたのにもかかわらず、なかなか更新しなかったのは、やっぱり[[前回の更新|http://www.noroi.jp/?date=20070815#p01]]がズタボロだったことが影響してるんだろう。
今回後押ししてくれたのは不具合である。スリープから復帰させるとマウスポインタが動かなくなっているという現象が月曜夜に発生。いろんなマウスを試したがピクリともしない。再起動しても直らない。Mac OS Xは、マウスが使えないとなんにもできないってことを改めて痛感した。電源切っておいたら会社に行ってる間に直ってたんだけど、土曜にまた発生。月曜が有給の三連休ってこともあり、勢いで更新を始めてしまった。なんでお盆休みにやらなかったのか? お盆休みは別のガジェット導入で他に手が回らなかったのだ。
前回苦労させられた『別の Mac から情報を転送する』は今回きっちり機能した。デフォルトの、すべての項目にチェックを付けての転送であるため、マウスの不具合を引き継いでしまうかもと不安だったのだが、ソフトウェアアップデートが山ほど溜まっていたこと、iLife '09が残っていた(旧機はiLife '08だったのだ)ことを見ると、上書きはされないようである。
ということで、転送されなかった設定もいくつかあったので、メモを残す。
sudoしたら弾かれてしまった。idでみてもwheelグループに居ない。/etc/sudoersが初期値に戻っていたのは「上書きはされない」ためだろう。NetInfoはもうないのでdsclを使って設定を入れる。自分をadminグループに入れてしまうと、「ユーザにこのコンピュータの管理を許可」にチェックを入れるのと同じになってしまうため、今まで通りwheelグループに自分を入れて、sudoでだけあれこれできるようにする。
$ su 管理を許可されてるユーザxxx xxx# sudo -s # dscl . merge /Groups/wheel users 自分 # visudo %wheel ALL=(ALL) ALL のコメントを外す。
named.confが初期値に戻っているだけでなく、起動情報も転送されていなかった。
kamuiからというか、FreeBSDのnamed.confの設定部分から、ブラックホールに落とすところを丸写ししてnamed.confを作り直す。そろそろunboundにしたいところ。
namedの起動はこう。dscl同様、このコマンドをスグ忘れるのだ。
$ sudo launchctl load -w /System/Library/LaunchDaemons/org.isc.named.plist
Privoxy Utilityはアプリケーションフォルダにあったため転送されたが/usr/local/sbinは空になっていたので再インストール。意味があるのかどうだか不明だが、Privoxy UtilityからUninstallしてから、インストールし直ししておいた。
$ sudo cp -r /usr/local/etc/privoxy . # ここで、Uninstall と再インストール $ sudo cp privoxy/config privoxy/user.* /usr/local/etc/privoxy # 動的に設定ファイルを読み直すはずだけど、一応、Privoxy Utility から再起動
さて、今回の更新のもひとつの目玉がこれ。データファイル置き場が溢れていてので新しいディスクにデータを移行しておきたかったのだ。で、古いディスクはタイムマシン用に。
で、新しいったって、このminiStack V3は去年の8月に買ったヤツだ。1TBだと思ってたら500GBしか無いでやんの。今のと同じだ。これじゃあダメだろう。今のは80GB分、システムのバックアップ用にしていたので、移行すれば 80GBは空きが出る。これで凌いでる間に新しい外付けディスクを選定しよう。いいことだってある。新しいMacとこのminiStack V3は、Firewire 800が使えるのだ。
で、コピーを仕掛けたまま寝た。実は日曜の昼前後には仕事があったりもしたため(またコミティア行けなかったよ)、更新作業を始めた土曜の夜からズッと起きていたのだ。で、起きて読み直したら、あまりにヒドかったので、ちょっと(?)書き直した。誤認もあったし。
XML::RSSのencode_cbと、utf8フラグ
自前のantennaプログラムが、えらく重たくなっていることは前々から気づいてた。けど、今イチやる気が起きなくて延々放置してたのだが、この度、ようやく物理的にも重い腰を上げてみた。
計ると10分も処理にかかってる。その間、perlはCPUを食い荒らし、筐体内温度も上がってく。今回の修正で処理時間は20秒ほどになった。やれやれである。
HTML::EntitiesXML::RSSは1.12から、実体参照の処理にHTML::Entitiesを利用するようになった。内部のデータはencode_entities_numericで処理され、utf8フラグが付いているとか、そういう配慮無しに日本語はすべて数値参照になってしまった。問題のXML::RSS::Private::Output::Baseの当該箇所はこうなっている。
while ($text =~ s/(.*?)(\<\!\[CDATA\[.*?\]\]\>)//s) {
# we use &named; entities here because it's HTML
$encoded_text .= encode_entities($1) . $2;
}
# we use numeric entities here because it's XML
$encoded_text .= encode_entities_numeric($text);
これだけだと分かり難いので、サンプルで。
$ cat a.pl #!/usr/bin/perl use HTML::Entities qw/:DEFAULT encode_entities_numeric/; use encoding utf8; my $in = '<テストだよ>'; print $in, "\n"; print encode_entities($in), "\n"; print encode_entities($in, '<>&"'), "\n"; print encode_entities_numeric($in), "\n"; print encode_entities_numeric($in, '<>&"'), "\n"; $ perl a.pl <テストだよ> <テストだよ> <テストだよ> <テストだよ> <テストだよ>
こちとら、2行目の「<テストだよ>」のようにして欲しいわけだが、みな、3行目のようになり、何が書いてあるのかデコードしないとわからなくなってしまった。まぁ、RSSなんだからプラウザで読めればいいという話ではあるのだが。
ま、とにもかくも、HTML::Entitiesの使い方は日本では不評であった。これに対抗するにはどうすりゃいいか、なんとかencode部分を差し替えられんかと、あれこれ考えていた。XML::RSSをバージョンアップせず、1.10を使い続けるというのも一手。もしくは改造しちゃう。最初の頃はそうしてた。あるときから面倒になって、とりあえず、encodeされた状態を出力させ、後でdecodeするというのに切り替えた。XML::RSSは、FreeBSDのportsで導入してるので、バージョンアップしないでいるのも面倒だから。
「XML::RSS 字化け」でググると、encode_output => 0をしてるページが沢山ヒットしてしまう。それはどうよ。XMLパーサーにかけるとエラーになるRSSが生成されっぞ。まぁ，他人事ではあるが。
encode_cbさて、今回の件を調べていて、CPU喰っているのは実体参照のencodeをしている部分であることが分かった。なんかできんかと、XML::RSSのPodを読み返していて、new Methodのところに、encode_cbなるパラメータが増えていることを知った。まさに、encode部分の差し替え機能である。エンコード部分を自前で用意してreferenceで渡すだけでいい。こんな感じになる。
sub my_encode {
my ($self, $text) = @_;
#return "" unless defined $text;
if (!defined($text)) {
confess "\$text is undefined in XML::RSS::_encode(). We don't know how "
. "to handle it!";
}
return $text if (!$self->_main->_encode_output);
my $encoded_text = '';
if ($text =~ /\[CDATA\[/) {
while ($text =~ s/(.*?)(\<\!\[CDATA\[.*?\]\]\>)//s) {
# we use &named; entities here because it's HTML
$encoded_text .= encode_entities($1, '<>&"') . $2;
}
}
# we use numeric entities here because it's XML
$encoded_text .= encode_entities($text, '<>&"');
return $encoded_text;
}
...
my $rss = new XML::RSS(encode_cb => \&my_encode);
XML::RSS::Private::Output::Baseの_default_encodeから、二箇所を変更している。
encode_entities_numericは使わない。unsafe_charsを明示指定して、余計なエンコードを抑制これでXML::RSS 1.10相当に戻る。
utf8フラグ日本語文字列が数値参照になってしまうのは、これで防げたが、CPU喰いまくりなのは直らない。何が? これだ。
while ($text =~ s/(.*?)(\<\!\[CDATA\[.*?\]\]\>)//s) { }
CDATAセクション内を実体参照しないための処置なのだが、このパターンマッチをutf8フラグの立ったデータに行うと時間がかかる。マッチだけで10秒近く。なにやらperl 5.8.9からのような気がする。とりあえず、上のように、CDATAが無ければマッチに行かないように変更して逃げてるんだけど、いっそperlを5.10にしてしまった方がいいのかも。
なんと、年末に買ったSSD、半月でエラーが出始めやがった。
Jan 17 01:34:02 kamui root: ZFS: checksum mismatch, zpool=tank path=/dev/ad6s1d offset=28516061184 size=4608 Jan 17 01:34:26 kamui root: ZFS: checksum mismatch, zpool=tank path=/dev/ad6s1d offset=28516051968 size=512
こういうのがドヨドヨと。zpool statusするとCKSUMが上ってる。
$ zpool status
Checking status of zfs pools:
pool: tank
state: ONLINE
status: One or more devices has experienced an unrecoverable error. An
attempt was made to correct the error. Applications are unaffected.
action: Determine if the device needs to be replaced, and clear the errors
using 'zpool clear' or replace the device with 'zpool replace'.
see: http://www.sun.com/msg/ZFS-8000-9P
scrub: none requested
config:
NAME STATE READ WRITE CKSUM
tank ONLINE 0 0 0
mirror ONLINE 0 0 0
ad4s1d ONLINE 0 0 0
ad6s1d ONLINE 0 0 28
errors: No known data errors
以後、この数字は順調に増え、今朝のdaily reportでは171になっていた。なんだかな。確かにkamuiのad6にしたディスクは、4個中1個だけ容量が2MB少ないとか、妙な特徴があったわけだけど、やっぱりハズレだったんだなぁと納得。ということで、交換用のディスクを買ってきた。同じ機種にしたのは、あれこれ調べるのが面倒だったから。
まずは、障害の出たad6s1dをOFFLINEにする。
# zpool offline tank ad6s1d
この後、物理的にディスクを交換するわけだが、SATAなんだからホットスワップできるはず。だけど、FreeBSDでどうやっていいのか思いつかず。atacontrol(8)にそれらしきサブコマンドも見つからず。面倒なのでshutdownして交換した。情けない。
$ dmesg | grep 'ad[46]' ad4: FAILURE - SET_MULTI status=51<READY,DSC,ERROR> error=4<ABORTED> ad4: 30520MB <MTRON MSD-SATA3525 0.19R1H2> at ata2-master UDMA100 ad6: FAILURE - SET_MULTI status=51<READY,DSC,ERROR> error=4<ABORTED> ad6: 30520MB <MTRON MSD-SATA3525 0.19R1> at ata3-master UDMA100
こんどは容量が同じ。んでも、ロットが違うからか「H2」が付いてないな。古くなったかな?
スライス切りとパーティションを作成。予備のブートパーティションad6s1aの作り直しは後回しにして、zpoolの再構成を。
# zpool status
pool: tank
state: DEGRADED
status: One or more devices has been taken offline by the administrator.
Sufficient replicas exist for the pool to continue functioning in a
degraded state.
action: Online the device using 'zpool online' or replace the device with
'zpool replace'.
scrub: resilver completed with 0 errors on Sun Feb 1 20:23:36 2009
config:
NAME STATE READ WRITE CKSUM
tank DEGRADED 0 0 0
mirror DEGRADED 0 0 0
ad4s1d ONLINE 0 0 0
ad6s1d OFFLINE 0 0 0
errors: No known data errors
この起動後の状態表示はzpool offline直後のものと変わらない。それでは、交換したデバイスをONLINEに。
# zpool online tank ad6s1d Bringing device ad6s1d online
こいつは、ちょこっと時間がかかった。これで、初期化されてないことがzfsにも伝わり、状態はこんなことに。
# zpool status
pool: tank
state: DEGRADED
status: One or more devices could not be opened. Sufficient replicas exist for
the pool to continue functioning in a degraded state.
action: Attach the missing device and online it using 'zpool online'.
see: http://www.sun.com/msg/ZFS-8000-D3
scrub: resilver in progress, 0.96% done, 0h10m to go
config:
NAME STATE READ WRITE CKSUM
tank DEGRADED 0 0 0
mirror DEGRADED 0 0 0
ad4s1d ONLINE 0 0 0
ad6s1d UNAVAIL 0 0 0 cannot open
errors: No known data errors
で、zpool replace を実施。このコマンドは一瞬にして返ってきた。
# sudo zpool replace tank ad6s1d
# zpool status
pool: tank
state: DEGRADED
status: One or more devices is currently being resilvered. The pool will
continue to function, possibly in a degraded state.
action: Wait for the resilver to complete.
scrub: resilver in progress, 0.06% done, 12h50m to go
config:
NAME STATE READ WRITE CKSUM
tank DEGRADED 0 0 0
mirror DEGRADED 0 0 0
ad4s1d ONLINE 0 0 0
replacing DEGRADED 0 0 0
ad6s1d/old UNAVAIL 0 0 0 cannot open
ad6s1d ONLINE 0 0 0
errors: No known data errors
同じディスク番号だと、こんな感じでreplace作業をする。mirror構成なので、データのコピーをしてるんでしょう。残りが13時間弱とか出てるけど、この数字は瞬く間に減って、残り数分となり、残り0h4mからが長かったが、最後はこのように完了。
# zpool status
pool: tank
state: ONLINE
scrub: resilver completed with 0 errors on Sun Feb 1 21:07:49 2009
config:
NAME STATE READ WRITE CKSUM
tank ONLINE 0 0 0
mirror ONLINE 0 0 0
ad4s1d ONLINE 0 0 0
ad6s1d ONLINE 0 0 0
errors: No known data errors
ログを調べると、replaceが完了するのに、およそ30分かかっていたことがわかる。
# zpool history | grep ad6 2008-12-28.00:57:18 zpool create tank mirror ad4s1d ad6s1d 2009-02-01.20:13:01 zpool offline tank ad6s1d 2009-02-01.20:36:02 zpool online tank ad6s1d 2009-02-01.20:36:35 zpool replace tank ad6s1d