2008-12-30

zfs導入

せっかくディスクの移行をするんだからと、えいやでzfsに移行。

How to install FreeBSD 7.0 under ZFSを参考書として全面依存。のうはうの「ZFSメンテナンスの日々」シリーズが副読本。

方針は簡素。

  • boot以外はすべてzfsに。
  • SSD 2個でmirror構成。
  • home以外はatime=offで。

カーネル変更

ZFS Tuning Guideを参考に

  • option KVA_PAGES=512をconfigに加えてkernelを作り直し
  • loader.confに以下を追加してhalt
    zfs_load="YES"
    vm.kmem_size="512M"
    vm.kmem_size_max="512M"
    vfs.zfs.zil_disable="1"
    

DISK初期化

これまで使ってなかったSATAのコネクタ2つ(2つしかない(涙))にSSDを2台接続して起動。すると、ad4, ad6として認識。ad5が飛ばされているのが面白い。

kamui$ 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: 30518MB <MTRON MSD-SATA3525 0.19R1H2> at ata3-master UDMA100

妙なエラーが出てるが、ネットで調べると、サポートしてないコマンドがあるってだけで問題ないらしいので以後は無視。「のうはう」に習いsade(8)を利用し、Disk Partition切りとdisklabel書きをおこなう。swapサイズはA = Auto DefaultsでDisklabel Editorに計算させたのを使った。以下、Aを押下した状態。どうでもいいことだが、/ が512MBって少なすぎだな。

                         FreeBSD Disklabel Editor

Disk: ad4       Partition name: ad4s1   Free: 0 blocks (0MB)

Part      Mount          Size Newfs   Part      Mount          Size Newfs
----      -----          ---- -----   ----      -----          ---- -----
ad4s1a    /             512MB UFS2   Y
ad4s1b    swap         1894MB SWAP
ad4s1d    /var         1971MB UFS2+S Y
ad4s1e    /tmp          512MB UFS2+S Y
ad4s1f    /usr        25629MB UFS2+S Y

ともあれ、これを編集して以下のようにする。partition dは、mountpointを適当に指定して作ったあと、M = Mount pt.で値を空にする。

                         FreeBSD Disklabel Editor

Disk: ad4       Partition name: ad4s1   Free: 0 blocks (0MB)

Part      Mount          Size Newfs   Part      Mount          Size Newfs
----      -----          ---- -----   ----      -----          ---- -----
ad4s1a    /            1024MB UFS2   Y
ad4s1b    swap         1894MB SWAP
ad4s1d    <none>      27601MB *      

このまま書き込むと、partition dはUFS2扱いになってしまうので、念のためbsdlabel(8)でunknownに変更しておく。

kamui$ bsdlabel ad4s1
# /dev/ad4s1:
8 partitions:
#        size   offset    fstype   [fsize bsize bps/cpg]
  a:  2097152        0    4.2BSD     2048 16384 28552 
  b:  3878912  2097152      swap                    
  c: 62504001        0    unused        0     0         # "raw" part, don't edit
  d: 56527937  5976064    unused        0     0       

ところで、今回購入したSSD 4個のうち、kamuiのad6にした個体だけ容量が2MB ほど足りなかった(先のdmesgの出力参照)。なので、partitiion dが残り3個と同じになるようswapの数値を減らして調整している。

zfs設定

mirror構成でzpool作成。

# zpool create tank ad4s1d ad6s1d

一気にzfs filesystemを作成。tank/ncvsを作るのがkamui。tank/newsを作るのがgambaになる。tank/var, tank/tmpcopies=3はどうよ? とも思うのだが、とりあえずこれで様子見をする。変更は簡単だし。

# zfs set atime=off tank
# zfs create -o compression=gzip                         tank/root
# zfs create -o compression=gzip -o copies=3 -o atime=on tank/home
# zfs create -o compression=gzip                         tank/usr
# zfs create                     -o copies=3             tank/var
# zfs create                     -o copies=3             tank/tmp
# zfs create                                             tank/distfiles
# zfs create -o compression=gzip                         tank/ncvs (or tank/news)

tank/rootをrootにし、データ移行のためにtank/usr以下を実際の相対位置に変更。最初っからfilesystem名をmountpointと同じにしときゃいい話なんだが、そこは趣味ということで。さらに言えば、tankのmountpointをnoneにした段階で、すべてのfilesystemのmountは外れてしまうので、手間は変わらないのだ。

# zfs set mountpoint=none tank
# zfs set mountpoint=/tank tank/root
# zfs set mountpoint=/tank/usr tank/usr
# zfs set mountpoint=/tank/var tank/var
# zfs set mountpoint=/tank/tmp tank/tmp
# mkdir /tank/usr/ports
# zfs set mountpoint=/tank/usr/ports/distfiles tank/distfiles
# zfs set mountpoint=/tank/usr/home tank/home
# zfs set mountpoint=/tank/usr/home/ncvs tank/ncvs
# zfs list
NAME             USED  AVAIL  REFER  MOUNTPOINT
tank             354K  26.3G    25K  none
tank/distfiles    18K  26.3G    18K  /tank/usr/ports/distfiles
tank/home         19K  26.3G    19K  /tank/usr/home
tank/ncvs         18K  26.3G    18K  /tank/usr/home/ncvs
tank/root         18K  26.3G    18K  /tank
tank/tmp          18K  26.3G    18K  /tank/tmp
tank/usr          32K  26.3G    32K  /tank/usr
tank/var          18K  26.3G    18K  /tank/var

zfs set mountpoint=fooすると、ディレクトリfooは自動で作られる。もしかしたらmkdir -p foo相当のことをしてくれている可能性もある。途中mkdirしてるんだけど、要らなかったのかも。

データ移行

作業前にincomingなデータを扱うdaemonを停止。メールだけは半端にできないんで止めとかきゃ、程度。single userにしないあたりがいいかげんなところである。データコピーはcpioで。いやぁ、cpioって始めて使ったよ。

# cd /
# find -x / | cpio -pmd /tank

UFS2なpartition aに、single user bootできるようminirootを作成しておく。

# echo .[cp]* [Cbdelpr]* sbin
.cshrc .profile COPYRIGHT bin boot dev dist entropy etc lib libexec proc rescue root sbin
# for i in 4 6; do
> newfs /dev/ad${i}s1a
> mount /dev/ad${i}s1a /mnt
> find -x .[cp]* [Cbdelpr]* sbin | cpio -pmd /mnt
> mtree -f /etc/mtree/BSD.root.dist -p /mnt
> umount /mnt
> done

小細工

7.0-RELEASEではまだzfsでbootできない。のうはう: ZFSメンテナンスの日々 #7 ZFS Boot 編みたくzfsbootを導入すればできなくもないらしいが、まぁ、RELEASEでサポートされるまで待つってことで、参考書通りに小細工をする。

# rm -rf /tank/boot
# mkdir /tank/bootdir
# ln -s bootdir/boot /tank/boot

/tank/boot/loader.confvfs.root.mountfrom="zfs:tank/root"を追加。念のため、fstabも適当に作っておく。

# for i in 4 6; do
> mount /dev/ad${i}s1a /mnt
> echo 'vfs.root.mountfrom="zfs:tank/root"' >> /mnt/boot/loader.conf
> cat <<EOF >/mnt/etc/fstab
> # Device		Mountpoint	FStype	Options		Dump	Pass#
> /dev/ad${i}s1a		/               ufs	rw		1	1
> /dev/ad${i}s1a		none		swap	sw		0	0
> /dev/acd0		/cdrom		cd9660	ro,noauto	0	0
> EOF
> umount /mnt
> done

/tank/etc/fstabも参考書通りに用意。

# cat /tank/etc/fstab 
# Device		Mountpoint	FStype	Options		Dump	Pass#
/dev/ad4s1a		/bootdir	ufs	rw		1	1
/dev/ad4s1b		none		swap	sw		0	0
/dev/acd0		/cdrom		cd9660	ro,noauto	0	0

ここで優雅な環境をあきらめ、shutdown nowしてsingle userへ。

# shutdown now
# cd /

tank以下のmountpointを実位置に

# zfs set mountpoint=/usr tank/usr
# zfs set mountpoint=/var tank/var
# zfs set mountpoint=/tmp tank/tmp
# zfs set mountpoint=/usr/ports/distfiles tank/distfiles
# zfs set mountpoint=/usr/home tank/home
# zfs set mountpoint=/usr/home/ncvs tank/ncvs

tank/rootはboot時に/にmountされるので、automountされないようにmountpoint=legacyをセット

# zfs set mountpoint=legacy tank/root

これで終り。あとはrebootして様子を眺める。ふっふっふ。

完了

homeをcopies=3にしてるため、kamuiでは移行前より膨れ上ってしまった。gambaでは減っている。

oldkamui$ df -h
Filesystem        Size    Used   Avail Capacity  Mounted on
/dev/ad0s1a        35G     13G     19G    41%    /
devfs             1.0K    1.0K      0B   100%    /dev
kamui$ df -h
Filesystem        Size    Used   Avail Capacity  Mounted on
tank/root         8.3G     22M    8.3G     0%    /
devfs             1.0K    1.0K      0B   100%    /dev
/dev/ad4s1a       989M    232M    678M    25%    /bootdir
tank/tmp          8.3G      0B    8.3G     0%    /tmp
tank/usr           12G    3.3G    8.3G    28%    /usr
tank/home          21G     12G    8.3G    59%    /usr/home
tank/ncvs         9.6G    1.3G    8.3G    13%    /usr/home/ncvs
tank/distfiles    9.2G    908M    8.3G    10%    /usr/ports/distfiles
tank/var          8.7G    339M    8.3G     4%    /var
oldgamba$ df -h
Filesystem        Size    Used   Avail Capacity  Mounted on
/dev/ad0s1a        35G     21G     11G    65%    /
devfs             1.0K    1.0K      0B   100%    /dev
fdescfs           1.0K    1.0K      0B   100%    /dev/fd
gamba$ df -h
Filesystem        Size    Used   Avail Capacity  Mounted on
tank/root          21G    7.4M     21G     0%    /
devfs             1.0K    1.0K      0B   100%    /dev
/dev/ad4s1a       989M    230M    680M    25%    /bootdir
fdescfs           1.0K    1.0K      0B   100%    /dev/fd
tank/tmp           21G    128K     21G     0%    /tmp
tank/usr           22G    1.2G     21G     5%    /usr
tank/home          22G    941M     21G     4%    /usr/home
tank/news          23G    1.7G     21G     7%    /usr/local/news
tank/distfiles     21G    232M     21G     1%    /usr/ports/distfiles
tank/var           22G    1.1G     21G     5%    /var

kamui側のsnapshotをどう採るかを考えないと。homeのsnapshotを多く確保するなら、copies=2にしてしまった方がいいかもしれない。これは正月かけてゆっくり検討しよう。

ところで、compression=gzipしてるところでは、妙なものを見ることができる。

$ ls -l /usr
total 80
lrwxrwxrwx   1 root  wheel   10 Dec 28 22:58 X11R6 -> /usr/local
drwxr-xr-x   2 root  wheel  424 Dec 28 19:07 bin
drwxr-xr-x   2 root  wheel    2 Jan  8  2006 compat
drwxr-xr-x   2 root  wheel   16 Dec 28 19:29 games
drwxr-xr-x   9 root  wheel    9 Dec 29 02:11 home
drwxr-xr-x  47 root  wheel  243 Dec 28 19:08 include
drwxr-xr-x   6 root  wheel  468 Dec 28 19:08 lib
drwxr-xr-x   5 root  wheel    5 Dec 28 19:08 libdata
drwxr-xr-x   5 root  wheel   61 Dec 28 19:08 libexec
drwxr-xr-x  16 root  wheel   16 Dec 28 19:18 local
drwxr-xr-x   3 root  wheel    3 Dec 28 19:47 obj
drwxr-xr-x  70 root  wheel   84 Jan  1 03:08 ports
drwxr-xr-x   2 root  wheel  265 Dec 28 19:18 sbin
drwxr-xr-x  26 root  wheel   26 Dec 28 19:21 share
drwxr-xr-x  23 root  wheel   31 Dec 28 19:29 src

ディレクトリのサイズがこんな半端なものになってるのを見たのは始めてだ。もちろん一般ファイルでは圧縮前のサイズが表示される。

こぼれ

移行後、innがやたらとエラーを吐くようになった。

Dec 30 12:54:58 gamba innd: tradindexed: index inode mismatch for fj.soc.politics
Dec 30 12:54:58 gamba innd: tradindexed: index inode mismatch for 9759A691F86C6A2C5599913D8E50BA82
Dec 30 12:54:58 gamba innd: tradindexed: index inode mismatch for japan.jiji
Dec 30 12:54:58 gamba innd: tradindexed: index inode mismatch for 9CE72130FD3C736BCCFA4C4416FC66EF
Dec 30 12:54:58 gamba innd: tradindexed: index inode mismatch for 9759A691F86C6A2C5599913D8E50BA82
Dec 30 12:54:58 gamba innd: tradindexed: index inode mismatch for 9CE72130FD3C736BCCFA4C4416FC66EF

再度、~news以下を被せ直したりしても直らない。ので、あれこれググるとtdx-util -Fで直せることがわかった。要は、overviewのIDXファイル中にi-node番号が入っているかららしい。

SSD導入

マシンをファンレスにしたのがおよそ[[二年前|http://www.noroi.jp/?date=20070210#p01]]。以来、夏になるたび送風機のお世話になってきた。VIA C7は悪くない。こいつは殆ど熱を持たない。んじゃ何が?ディスクである。大枚はたいてIO-DATAのHDR−MDSAを導入したんだけど、こいつの基盤部分がそこそこ熱くなる。いや、通常の基準でいけば大したことはないんだけど、ファンレスで狭いところに密封されてる環境じゃ、内部温度が下がる理由がないもんね(CPUはケースの放熱器に接続されてるからか、そんなに温度は上がらない)。そんなこんなで、夏は送風機で風を当ててやるはめに。ファンの音が耐えられなくてファンレスにしたというのに本末転倒も甚しい。というわけで熱対策というか騒音対策でSSD導入だ。

SSDへデータ移行中の図

画像を見ればメーカーは瞭然。型番はMSD-SATA3525-032NAなるもので、先月『SLCでこの値段』などと騒がれたアレである。あれこれ検索すると芳しくなさげな評判ばかりだったんだけど、逆に決定的にマズいというのも見当たらなかったので、ちょっくら冒険。

スピードはっつうと、まあそこそこ。少なくともHDR−MDSAよりは圧倒的に速いぞ。夜中のdaily jobでは、gamba, kamuiともkamui上のcvsupdへ向けてcsupをかける。おかげで、kamuiのdaily jobは1時間強かかることが多かったんだが、10数分で終わるようになりましたがね。まぁ、HDR-MDSAは安定性を求めて買ったわけで、スピードはハナから期待してなかったんだけど、こうも違うかねってくらいの差が出ましたな。まぁ、効果の大半はSSD化よりもnoatimeだろうけど。

それはともかく来年になれば、IntelのX25-Eに匹敵するようなのが安価でゾロゾロ出てくるだろうに、こんなタイミングので更新はやっぱり残念なところ。まぁ、もう一度このまま夏を迎えて、留守中に送風機が発火したりして火事になってるんでは、なんて妄想に悩まされ続けるつもりはなかったけどね。それよりも、gambaでは、

Nov  5 00:00:59 gamba kernel: fsync: giving up on dirty
Nov  5 00:00:59 gamba kernel: 0xc2ceebb0: tag devfs, type VCHR
Nov  5 00:00:59 gamba kernel: usecount 1, writecount 0, refcount 285 mountedhere 0xc2d98000
Nov  5 00:00:59 gamba kernel: flags (VV_COPYONWRITE)
Nov  5 00:00:59 gamba kernel: v_object 0xc14607c0 ref 0 pages 20298
Nov  5 00:00:59 gamba kernel: lock type devfs: EXCL (count 1) by thread 0xc3218210 (pid 68930)
Nov  5 00:00:59 gamba kernel: dev ad0s1a

てなエラーが出てたってことが、タイミングを計ってる余裕を失わせたというか。

恐ろしい事に、このエラーに気づいたのが先週末だという。写真をよくみれば分かると思うけど、HDR−MDSAに12Vが接続されてない(赤黒しか入ってない)。実は12Vが供給されてないと状態を知らせるブザーが鳴らないんだよね。もしもきっちり接続してればエラーを検出してたのかも。ま、いまさらそれがわかってもね。

さて、熱はどうなったか。

これまではCPU温度しか記録していなかった。迂闊。で、この項目については更新前後で26度前後と変化がなく、役にたたない。mbmon入れて調べたところ、kamuiのM/Bのセンサーは50度を超えている。蓋をしてないgambaで40度。これはもう更新前のデータがないと意味がない。ディスクの温度はどうかってーと、HDR−MDSAはS.M.A.R.T非対応、MSD-SATA3525-032NAは対応してるけど温度は採ってこれないときた。

てなことで、ひたすら感覚的な話でいくと… kamuiだけSSD化した状態で2台並べて1日放置してたんだけど、ディスクのある辺りをケースの外から触ってみた感じでは、gambaがほんのり暖かいのに比べ、kamuiは熱を感じなかった。ま、金属ケースなのに触ってヒヤっとしないってのは熱が出てるってことだけど、SSD化がそれなりに熱対策になったってことじゃなかろうか。お願いだからなっててくれ。

今後はMother Boardの温度も記録。今年の夏はどうなるか。この無粋な送風機を捨てることができますように。

2008-12-02

寝る前まんが

サクラ町さいず読み返しはようやく四巻の真ん中あたり。遅っ!

ということで、「…俺はメガネの方がいいと思う…」と信一朗が言ったのは、四巻の50ページでした。ふむふむ。確かにあったな、こういうエピソードが。

ちなみに、あほ毛の女ジャージ先生は三巻の79ページから登場。顔長の年配ジャージ女先生はこのあたりでほぼ退場してるっぽい。

なんてどうでもいい情報なんだ。

2008-11-24

サクラ町さいず#6/松田円/芳文社/MANGA TIME COMICS

今月は神保に寄って帰ることが少なかったので、出てるのになかなか気付かなかった。この連休は、寝る前に一巻から読み返してたりする。

ともみネタが相変わらずツボなんだけど一段落しちゃった感は拭えず、麻子出産もそれほど盛り上がらずで、ちょっとマンネリ気味な今巻。だからなのか、妙に気になるのは小ネタの元。「メガネの方がいい」と言ったのは何時? まったくそういう話を見た記憶がない。それをいうなら、ひろえが信一朗にホレたのはどの辺りなんだかがサッパリだ。見直すと、最初の初詣で俊也の余計なまとめに怒るあたりでは決まってるんだが、それ以前では気配すらないんだけど。

という訳で読み返してる。他にも幾つか気になるネタ(アホ毛のジャージ先生の名前とか)があるし。なんというか、穏やかな連休ってことで。

追記

思ったんだが、単行本未収録のエピソードがたくさんありそう…

2008-11-16

バルサ試合カレンダー(続き)

寝込んでたこともあって、こないだの続きができた。って、こないだじゃねぇ。二ヶ月も前のことだ。何やってんだか。

前回は、元ネタがXHTMLだから楽勝じゃん、で終わってる。XSLTだけで済むな、くらいの気持ちだったんだけど、やってみるとそこまで簡単ではない。特に日付関連が面倒。リーガエスパニョーラは、開始時刻はもとより、開催日が土曜か日曜かも直前にならないと決まらないので、そういうデータは元ネタでも「日(とりあえず日曜仮定)」までしか書かれていない。iCal上でも、決まって無いことがわかるようにしたくて、そういう場合は「終日」とすることにしたため、VALUE=DATEDTSTART/DTENDを書くんだけど、終日の場合のDTENDは翌日として記述しなけりゃならない。ただでさえ「dg. 14 des.」なんてのを20090114にするってだけで一苦労なのに、日付の加減算なんてXSLTでやってられるか。ってことで、やっぱりperlで書く事に。XML::XPath使ったので効率悪すぎなんだけど、週に一回実行するだけならこんなので十分か。

更新タイミングはとりあえず毎朝 8時にしてみた。開催日時が確定するのが何曜か分かれば週一にすることを検討。何が怖いって、録画を見てもいないのに、カレンダーで結果を知ってしまうことだけは避けなければ。

iCalShareに登録しようか、どうしようか。

寝たきり

ここ最近、週末となると、身体がまるで動いてくれなくなった。今年の総決算的なお仕事の山が先週の日曜にあったためなのか、単なる歳のせいなのか…

今日はCOMITIAだったんじゃが、そんなこんなで動けませんでしたよ。カタログのチェックすらできてない状況だったので、行けてもアレだったとは思うですが。

2008-10-25

privoxy

インストールしたのは一年以上前だと思うんだけど、マニュアル読み下すのが面倒でずっとデフォルトのままで放置してきた。この週末、風邪ひいて寝込んでたんで、ようやく手を出すことにした。

何がしたかったのか。rssad.jppheedo.jpのWeb Bug退治である。

正直な話、トラッキングが気持ち悪いとか、個人情報に紐付けられんのがイヤとか、そーいう高度(?)な話ではなく、ただただ、この二つのサイトが嫌いだからである。

  • こやつらを使うフィードには、ビーコンが山ほど埋め込まれてる
  • ビーコン先のサーバーは常に過負荷にあるようで、レスポンスが非常に悪い
  • Safariは、フィードに書かれたHTMLをレンダリングする

こういった理由(最後のは理由になっちゃいないが)から、rssad.jppheedo.jpを使ってるフィードをSafariで読み込もうとすると、とても時間がかかる。読み込み中の要素が多数あるとSafariの反応は遅くなり、キャンセルも簡単には受け付けてくれなくなったりする。構成ファイル一覧なぞを見てると、タイムアウトやらなにやらで、ビーコンな要素が多々エラーになっている。腹立たしいったらありゃしないのだ。

これが、Firefox+Sageなら、フィードに書かれたHTMLをレンダリングなんぞしないんで、まったく気にならないはず。いやいや、これらのサイトのビーコンの読み込みに時間がかからないんであれば、Safariでだって、まったく気にならないだろう。

フィードは手軽にサクっと読めなきゃ意味がない。それを妨げるところには退場願うしかないやね。

そんなこんなで

www.pheedo.jp/img.phdo
www.pheedo.jp/feeds/ht.php
feedads.googleadservices.com/~[a-z]/
feedproxy.google.com/~[a-z]/[a-z]+/[A-Za-z]+\?i=
feedproxy.google.com/~[a-z]/[a-z]+/[A-Za-z]+/~4/
feedproxy.google.com/~[a-z]/[a-z]+/~4/
feeds.feedburner.com/~[a-z]/[^/]+/[a-z]+\?i=
rss.rssad.jp/rss/artimg/
rss.rssad.jp/rss/ibfeed/
rss.rssad.jp/rss/img/
www.assoc-amazon.jp/[a-z]/ir
send.microad.jp/im_c.cgi

てなリストをuser.action{ +block-as-image }に追加した。

ホントならpheedo.jprssad.jpだけで十分なんだけど、パターンを記述するにあたって調べてたら、他にもビーコン埋め込みが目に付いたので、ついでにそれらも書いてしまったのだ。したら、feedburner.comfeedproxy.google.comのコンボになってる、Engadget Japaneseに嵌められてしまった。

元は単純に、

feedproxy.google.com/~[a-z]/
feeds.feedburner.com/~[a-z]/

だったんだけど、Engadget Japaneseのフィードは、itemエレメント自体がビーコンであり、単純な方のパターンにマッチするfeedburner.comのURIが使われていて、このままでは記事を辿れなくなってしまう。しかも、このURIへアクセスするとfeedproxy.google.comに転送させられるという二段構え(その先でもちろんEngadget Japaneseに転送されるわけだから三段構えか)。んでもって、転送に使われてるURIとビーコン用のURIの間にパターン上の有為な差が見当たらないときた。なんとなく、/~4/を含むのがビーコン用URIで、/~3/を含むのが転送用URIっぽいんで、上のように書いておいたんだけど、はてさてどこまで通用するものなのか。まぁ、Engadget Japaneseはフィードにかなりの情報が含まれてて、本サイトまで見に行く必要がないので、単純パターンに戻してしまっても困らないんだけどね。

2008-09-23

バルサ試合カレンダー

バルサ公式サイト試合日程表を眺めてて、ふと、こいつからiCalカレンダーを作りたくなった。

いや、ま、これまでも、こいつを眺めながら、iCalに手動で入力したりしてたんだけど、さすがに莫迦莫迦しくなってきた。つか、なんでiCalなデータを置いてないですかねぇ。Euro2008のサイトは置いてたのに。ぶつぶつ。

当該ページのソースを眺めると、嬉しいことにXHTML。parseしてみると、画面右上の試合種で日程表を絞るところの、アンカーの属性がひっついてる以外はキチンとしてる。それだって

sed 's/"target=/" target=/g'

で簡単に解決できる。

てなこんなで、ここからあれこれすれば、iCalカレンダーが作れそう。データにも、partit-competicio(試合種), partit-jornada(節), partit-data(開催日), partit-hara(開始時間), partit-equip-local(カーサチーム名), partit-resultat(結果), partit-equip-visitant(フエラチーム名) と、細かくclass属性が付けてあり、もう活用してくださいてな書き方されてるのだ。まぁ、DBの項目名がまま出てるだけだろうけど。

リーガエスパニョーラは直前にならないと開催日が決まらないんで、ここんとこが機械的に処理できると楽できそう。今週みたく週中にあると忘れかけるからね。

2008-08-23

その後のYAHAMA RTシリーズ

DNS cache poisoning対策済みファームを8月中に出すと、20日に発表したようで。遅い。遅すぎる。src portのランダム化だけで、なんでこんなに時間がかかるのか。

97年のサイト立ち上げ以来、YAMAHAのRTシリーズをずっと使い続けてきたんだけど、ここらで乗り換え時なのかも。

2008-07-26

dnscache returns

やはり、もひとつdnscacheを動かしてしまった。ただし、外部インターフェイスではなくloopbackにaliasを付け、pfでリダイレクトする。

# dnscache-conf Gdnscache Gdnslog ${DNSCACHE_EXT} 127.0.0.2
# touch ${DNSCACHE_EXT}/servers/ip/[プライベートLANネットアドレス]
# echo 'ifconfig_lo0_alias0="inet 127.0.0.2 netmask 0xffffffff"' >> /etc/rc.conf
# ifconfig lo0 inet 127.0.0.2 netmask 0xffffffff alias

pf.confも変更。

rdr on $ext_if inet proto { udp, tcp } from <nats> to any port domain -> 127.0.0.2 port domain

ちょっとすっきり。

$ dig +short -t txt porttest.dns-oarc.net @127.0.0.2
 z.y.x.w.v.u.t.s.r.q.p.o.n.m.l.k.j.i.h.g.f.e.d.c.b.a.pt.dns-oarc.net.
"[kamui] is GOOD: 26 queries in 3.0 seconds from 26 ports with std dev 17069.11"
$ netstat -f inet -a | grep domain
tcp4       0      0  localhost.domain       *.*                    LISTEN
tcp4       0      0  127.0.0.2.domain       *.*                    LISTEN
tcp4       0      0  kamui.domain           *.*                    LISTEN
udp4       0      0  localhost.domain       *.*                    
udp4       0      0  127.0.0.2.domain       *.*                    
udp4       0      0  kamui.domain           *.*                    

あたりまえだけど、127.0.0.2って名前が付いてないんだなぁ。

追記

localhostとloopback, lo0の表記が入れ乱れてたので統一してみた。ついでに、titleを差し替え。

DNS cache poisoning rhapsody

うちでは未だにDJBのtinydnsを使ってて、リゾルバは各マシンのloopbackで動かしてるdnscacheなので、今回の騒ぎは他人事だと思ってた。

が、よくよく考えると、プライベートなLANにいる連中のことを失念してた。

  • Mac miniでは、Mac OS Xに付随のBIND 9.4.1-P1をフルリゾルバとして使ってる。
  • ThinkPad群は、プロバイダのフルリゾルバをrtx1000経由で使ってる。

相変わらずAppleは、この手の対応はまったくもって遅い。まぁ、ユーザーランドがFreeBSDベースだからって、付随のBINDを使ってるヤツがいるなんて思ってもいなさそうだ。

YAMAHAも問題か。説明文書も一週遅かったし、なんにせよ未だにsource portをランダム化するファームすら出てきていない。

さてどうするか。

個々のマシンに最新のBINDを入れる?

リゾルバは共有したりせず、各ホスト専用のを各ホストのloopbackで個別に動かすのがスジだと思ってるんで、この方法が一番適切に思える。が、運用が面倒になるのが難点。WindowsUpdateやソフトウェアアップデートといった方法で更新できないのって、クライアントマシン用施策としては失格なんじゃないかと。

話は逸れるが、ISCって、BINDのWindowsバイナリ配ってるのね。知らなかった。これ入れるとdigとかも使えるのかしら。Windowsってnslookupしかないんで不便なんだよな。

dhcpでリゾルバのアドレスを通知できないのは不便

プライベートなLANにいる連中はdhcpのクライアントだ。各マシンにBIND入れてそこを見に行かせるようにすると、ノートPCを持ち出した時にあれこれ困りそうだ。さらによくよく考えると、うちにはPlayStation 3があるんだった。こいつが名前引きできなくなると、まいにちいっしょが見れなくなるじゃないか。

DMZにいるマシンのdnscacheをプライベートLANから使う

DJBのtinydnsは、外部インターフェイスで権威サーバーtinydnsを動かし、内部インターフェイス(lo0)でリゾルバdnscacheを動かすという実にシンプルな構成になっている。BINDみたく、両方一緒になっててクエリの種類でVIEWを分けて挙動を変えるなんてことはしていない。だからこそ安全なんだが、だからこそ、今回の場合は頭を抱えることになった。

外部インターフェイスにalias付け、そのalias上で、もひとつdnscacheを動かすって方法もあるんだが、それはそれで面倒だ。ということで、pfにおいで願った。要は、プライベートLANからのクエリであれば、loopbackへリダイレクトしてしまえ、という方法である。

DMZにあるマシンのdnscache

プライベートLANからのクエリも受け付けるように変更する。server/ipに、プライベートLANのネットワークを付けたファイルを追加。

# touch ${DNSCACHE}/server/ip/[プライベートLANネットアドレス]
rtx1000

リゾルバサービスを止め、プロバイダからの通知にあるリゾルバの取り入れを止め、DMZにあるマシンのアドレスをリゾルバとして直接指定。dhcpでも、自身のアドレスを通知させないように。

dns service off
no dns server pp
dns server [DMZ にあるマシンのアドレス]
dns notice order dhcp server
dns notice order msext server

さらに今回、プライベートLAN に居ながら、手動でアドレスを割り当てていたMac miniも、dhcpを利用するように変更してるんだけど、ここには書かない。

pf.conf

これが今回のキモ。キモなのに 2行しかない。

table <nats> { プライベートLANネットアドレス }
rdr on $ext_if inet proto { udp, tcp } from <nats> to any port domain -> 127.0.0.1 port domain

dhcp配下の各マシンをあれこれ操作したり、tinydnsとdnscacheのログをしばらく眺めてて、想定していた結果になっていることを確認。rtx1000 のファームが更新されるまではこれでいきませう。

今後

DMZにあるマシンのリゾルバのキャッシュが、WindowsやMac(or PS3)が呼び込んだ「なにか」によって汚染される可能性があるのが今イチ。やはり、BINDを各マシンに入れ込むかなぁ。ISCの配布しているBINDは試してみたいし。んで、PS3だけはプロバイダの再帰サーバー使えばいいやな。rtx1000経由で使うなら、フィルタをも少し検討しないとな。プロバイダのリゾルバ以外からのレスポンスは受付けないようにするとか。

2008-07-06

ツッコミありなしフィード

なぜか20040822へのコメントスパムが去年から大人気。フィルタをかいくぐってくるのを見つけるたび、手で消してたりする。今日、久々にやってきたので、200408.tdcを編集し、200408.parserを削除する、なんてことをした。しかし、URLなしの「bookmark you thx」ってなスパムは、なんの意味があるんだろう。もしかして単なる嫌がらせか?

さて、コメント自体は削除できるんだけど、RSSに記録された方は消すことができない。makerss.cacheを編集できればいいんだけど、Ruby力が圧倒的に不足してるので手がでない。そこで、コメント無しフィード機能を使う事にした。

tdiary.confに、

@options['makerss.url'] = 'comments.rdf'
@options['makerss.suffix'] = '(with comments)'
@options['makerss.no_comments.file'] = 'index.rdf'
@options['makerss.no_comments.suffix'] = ''

を追加し、設定画面から「ツッコミ抜きのフィードを配信する」に変更。

これで、index.rdfにはツッコミは入らなくなった。って、いっこ前のEURO 2008話は、その効果を見るためにむりくり書いたエントリだったり。

勝ってしまった

突然夏になってしまった。涼しいまま秋が来るかと期待したのに。甘すぎたか。

知らん間にもう7月である。結局6月は何も書かなかった。理由はひとつ。UEFA EURO 2008のため。

Spain Euro 08 celebration 4

これまでさんざん期待しては裏切られ、というのを繰り返してきたもんだから、今回はちょっと違う向き合い方をしてみた。期待してるフリをしない。要は願掛けみたいなものである。いいかげん「応援してるのをおおっぴらに吹聴して回るのがあかんのではないか」と思ったのだ。で、今回は本当に大人しくしてた。内心はグループステージの一戦目から舞い上がりっぱなしだったのだが、外向きには「ゆーろ? なにそれ」みたいなフリを…

いやいや、そんなのが関係あるわけない。強かったよ。こーいう試合が見たかったんだという試合運びをして勝ち上がってってくれた。それがとてもうれしいやね。しかも、チャビが最優秀選手ときた。言う事無しですがね。でも、一番の感想としては、「うわ、本当に優勝しちゃったよ」だったりする。感情を抑えるクセができてたせいか、今でも「しまった」感が漂ってる。

まぁ、組み合わせに恵まれたってのはあるかと思う。イニエスタも調子を落としてた。オランダとの対戦が見れんかったも残念か。でも、もう、いい。勝てたんだから。

2008-05-31

Mac OS X 10.5.3

今回のアップデートの目玉はFlashPlayerプラグインの脆弱性対応であるのは間違いのないところなのだが、SafariStandでFlashの自動実行が抑制できてるのでニコ動自粛で済んでた身としては、スリープできないという不具合が解消したというのが一番の目玉だった。

端折って書くと誤解を招きそうだが、『指定した待機時間を過ぎたらスリープする』というのが機能しないという不具合が解消したのだ。モニターは切れるし、外部ディスクもきちんとスリープするし、電源ボタン一回押しによる手動スリープも機能した。Mac mini本体だけが、待機時間経過後スリープしなかったのだ。

この不具合、そもそもLeopardにした時から始まっていた。いや、それはちょっと違うな。たぶん、PPC Mac miniをTigerで使っていた頃もスリープしてくれない時期があった。どこかのアップデートで直ってかなり嬉しかったのだが、日記には書いてないな。まぁ、直ってしまえばそんな記憶も薄れるってもんだ。

が、Leopardでその不具合が復活した。一旦ログオフしておけばスリープするので、ログオン中に起動しているアプリのなにかが影響していたようだ。起動中のアプリをすべて終了させてもスリープは始まらないので、勝手に動いているサービスのどれかが原因なのだろう。Intel Mac miniは結構熱をもつので、手動スリープさせてから寝るなんて習慣が付いてしまった。でも、これだと、枕元に置いたX31のiTunesでDAAP経由の音楽聴きながら就寝てなことができない。供給元になっている間はスリープせず、再生を止めてから指定時間が経過するとスリープに落ちてくれるので、結構便利なのだ。

まぁ、そんな不具合が解消した。ようやく安心して枕元でiTunesが使えるよ。

2008-03-27

IE7のフィードが自動更新されない

alezo(ThinkPad X31)がXPの頃にIE7を入れたときも、alezoをVistaにしたときも、IE7のフィード機能は普通に働いていて、それがどうした、こんなの動いてて当たり前だろうくらいにしか考えていなかった。その後、「会社のWSUSでお手軽に脆弱性対策ができる唯一のタブブラウザ」ってことで、会社のXPにIE7を入れたら、ちっとも自動でフィードを更新してくれなくてがっかり、というかびっくり。でもまぁ、手動で「すべて最新の状態に更新」すれば使えないこともないので、さほど気にしていなかった。だいたい、それまでFirefoxにSage入れてRSSを読んでたので、手動で更新というのにさほど抵抗がなかったのだ。

ところが、昨年末に衝動買いしたThinkPad 15周年版X61s。最初っからVistaであるにもかかわらず、自動でフィードの更新をしてくれない(もちろん、「フィードの更新の確認を自動的に行う」にチェックは入っている)。これは結構頭にきた。

なぜか。

Vistaにはサイドバーなるものがあり、そこで、「フィードヘッドライン」が表示できる。明示的にフィードを見に行かなくても、新しい未読エントリはヘッドライン上でボールドになって現れてくる。ふと気が付くと画面の脇に新しいニュースが流れてるのだ。Vistaにしたalezoで、こういう環境に慣れてしまっていたため、自動でフィードが更新されないと、非常に腹立たしいのである。XPでなんとも思わないのは、「フィードヘッドライン」が無いからだろう。

てなわけで、なんで自動で更新されないのかズッと気になっていた。ググったりして調べても、MSの

  1. Internet Explorer 7 で RSS フィードが更新されないことがある
  2. Internet Explorer 7 で RSS フィードが一覧に表示されない、または RSS フィードを購読できない

くらいしかマトモな情報が見当たらない。で、この二つとも、まったく役に立たないから腹が立つ。Feedsフォルダの削除やフィードのエクスポート/インポートは何回やったことか。あげくは、一気にインポートするのがマズいのかと一個一個追加したりしてみたり。まったく、ほんとに、これっぽっちも役に立たなかった。

X61s上の自分のアカウントは、Windows転送ツールでアカウント情報をAlezoからコピってきたものだ。なら、新規にアカウントを作り、まっさらなプロファイルから始めれば、フィードも自動更新されるかもしれない。なんとも根拠薄弱な仮説を立てて、あれこれアカウントを作ったりして実験を繰り返すも、まったく更新される気配はない。が、この一連の作業をしているうちに、UACで使うために用意した Administratorsに属する管理者アカウントではフィードが更新されていることを発見。おいおい、フィードの自動更新には特権がいるのか? とどんどん後ろ斜め向きな仮説を積み上げていくことに。もちろん、特権持ってるアカウントを新規に作っても、自動更新されたりはしなかったので、この仮説は全否定されることになるのであるが。

そんな無駄な努力を繰り返していた今日の朝、なんの気なしに検索していて、「Windows Vistaでフィードが更新されなくなったときは」てなタイトルのBlogを発見。MS RSS BlogのFeeds not updating?の紹介である。要は、msfeedssync がきちんと起動されないからというもの。各種操作方法が載っていることもあり、これがビンゴな情報だった。

自アカウントでschtasks /queryを実行しても、User_Feed_Synchronization-{SID?}は現れてこない。管理者アカウントで試すと「次回の実行時刻」とともに現れる。で、その時刻になるのを自アカウントで待ち、イベントログを調べると、

ログの名前:       Microsoft-Windows-TaskScheduler/Operational
ソース:           Microsoft-Windows-TaskScheduler
日付:             2008/03/27 8:04:59
イベント ID:      332
タスクのカテゴリ: 起動条件が満たされていません。ユーザーがログオンしていません
レベル:           警告
キーワード:         
ユーザー:         SYSTEM
コンピュータ:     nanaca.noroi.jp
説明:
起動条件が満たされたときにユーザー "nanaca\[管理者ID]" がログオンしていなかったため、タスク スケジューラはタスク "" を起動しませんでした。ユーザー操作: ユーザーがログオンしていることを確認するか、ユーザーがログオフしているときに起動を許可するようにタスクの定義を変更します。

てなものを発見(このイベントログ、ローカル>アプリケーションとサービスログ>Microsoft>Windows>TaskScheduler>Operationalにある。XPと違ってVistaにはイベントログが山のようにある。こんなの探し出すのは素人にゃ無理だろう。)。きっちり5分おきに出ている。これが原因だ。

MS RSS Blogに書かれていたのとは違う原因だが、タスクスケジューラの不具合でmsfeedssync.exeが実行されないが故に、フィードが更新されていかないという部分は同じである。

管理者アカウントでのフィードの自動更新を止めると、このエラーは発生しなくなった。その状態で、自アカウントから

msfeedssync disable
msfeedssync enable

を行うと、schtasksの出力にUser_Feed_Synchronization-{SID?}が現れた。5分後のスケジュール実行もエラーはなく、そのまま「次回の実行時刻」まで待っていると、きっちりフィードが更新されるようになった。万歳!

たぶん、こうなれば、管理者アカウント側でフィードの自動更新を元に戻しても大丈夫だろう。きっと「なにか」が引っかかってたのだ。でもまぁ、管理者アカウントではフィードは読まないので元には戻さないけど。

どうでもいいことだが、上のイベントログを見てわかるとおり、この作業は朝の9時前までやっていた。なんせ「次の更新時刻」まで待たないと直ったかどうか判別がつかないから、なんだかんだ試してるうち時間が過ぎてったのだ。もちろん会社は遅刻である。

ちなみに、会社のXPでの原因は、MS RSS Blogに書かれていたものとほぼ同じだった。schtasksでエントリは出てくるものの、「状態」欄にエラーが出ていた。こちらは、msfeedssyncのdisable/enableでは直らなかったため、いったんスケジュールエントリを、schtasks /Delete /TN タスク名で削除した後、msfeedssync enableで正しくスケジュールされるようになった。これまためでたしめでたしである。

ところで、フィードの更新はIE7とは別のmsfeedssyncが行うため、IE7が起動されてなくても、サイドバーの「フィードヘッドライン」は更新されていく。なるほど、確かにこうなってる方が便利だよな。ちょっとだけ納得。けど、こんな不具合が高い確率で発生する以上、実装方法は見直すべきだろう。

2008-03-17

Ten Nori! 更新

あー、なんか、こんなこと書くのひさしぶりだなぁ。

eso aparte Ten Nori!

この季節恒例、アレぞうの花粉症ネタ。とっても辛いはずなのに、どうしてもその性格からか同情してもらえない、旬の過ぎちゃったかわいそうな人。人気投票もさんざんだし。

んでもって黒魔術。「すべての生き物」ってことは、花粉をバラ撒いてる杉やら檜やらも花粉症になるってことだと気づいてるか? 間違いなく「跳ね返って」くるぞ。さらにもって酷い症状に… あぁ、ヒドい目に遭ってるところが脳裏に浮かぶ。知らず頬が緩む。おかしいなぁ、俺ってアレぞうのファンのはずなのに。

閑話休題

[[数年前|http://www.noroi.jp/?date=20050318#p01]]に発症したはずの、うちの抗体くん。あの年以降、まったく仕事をしてなくて休眠状態。ええっと。直った? そんなのありえんはずなんでは? いったい、どうしたっていうんだろう。花粉症#自然治癒率 | Wikipediaの記述を信じるなら、今年症状がでなかったら自然治癒と呼んでいいらしいんだけど、さて。

2008-03-08

Baiduspider

久々にapacheのアクセスログをあれこれ眺めてたら、百度のクローラがやってきてるのに気づいた。百度からのアクセスはpfで一律に落としてたはずなのに、これはどうしたことかと思いきや、ネットワークブロックを新たに取ってたのね。

クローラの行儀を良くしますなんつってるけど、頻度が下がっただけ。しかも、うちではBaiduspilderに対して403返してるっつーのに、懲りる事なく数分おきにやってきてやがる。RFCくらい読めっつの。

というわけで、pfに喰わせるブロックアドレスに、122.152.140.0/23を追加。

122.152.128.0/23        # BAIDU-NRT-NETBLK01
122.152.140.0/23        # BAIDU-NRT-NETBLK02

BAIDU-NRT-NETBLK03はまだ無いみたいだけど、また増えるんだろうな。

tDiaryバージョンアップの備忘録

ようやく2.2.1に上げた。FreeBSDのtdiaryのportsは/usr/local/share/examples/tdiaryが書き変わるだけなので、実際のインストールは自前でやる必要がある。もしかしてやり方があるのかもしれないが知らんので。まぁ、手動でやる時の手順。

portupgade

まぁ、これはやっておくだけ。

japanese/tdiaryにしてるんだけど、www/tdiaryとの具体的な違いがよくわかない。www/tdiary-develは死んでるっぽいな。

データをコピー

とりあえず、作業用のエリアにデータをコピー。ここでは、$DOCUMENT_ROOTと同じ層にtdiaryという名のままコピってしまう。どのみち、apacheからは見えないし。

cd ${DOCUMENT_ROOT}の一個上
sudo cp -p /usr/local/share/examples/tdairy .
cd tdiary

index.rbを修正

[[以前|http://www.noroi.jp/?date=20051225#p01]]からやってる作業。GET,POST,HEAD以外のリクエストには405を返すためのもの。2.2.1でのパッチはこんな。「とりあえず」といいながらもう4年かぁ。

tdiary.confをマージ

@data_path/tdiary.confがあれば、$DOCUMENT_ROOTのこいつをあれこれする必要はなさげなんだけど一応。新旧の.sampleの差分を、直しちゃdiffかけ、目検しながら取り込む。

自前のデータを移動。

apacheを止め、自前のデータを旧$DOCUMENT_ROOTから移動してくる。

sudo /usr/local/etc/rc.d/apache22 stop
cd ../data
sudo mv d favicon.ico index.rdf okota* go robots.txt ../tdiary

えいやで、作業エリアのディレクトリ名を本物に差し替え、apacheを起動する。

cd ..
sudo mv data data.old
sudo mv tdiary data
sudo /usr/local/etc/rc.d/apache22 start

普通なら、外から見えないようにしてテストするもんだけど、そんなことしなきゃいけないようなサイトじゃないので、えいや。

様子見

ん? 曜日が「J」になってるな。

sudo cp -p data.old/misc/plugin/jdate.rb data/misc/plugin/

リロード。うんうん直った直った。う〜む、いいかげんだ。

2008-02-20

連絡定期券範囲拡大

ちょっと古いニュースだけど、3月15日より連絡定期の範囲が広がる。http://www.jreast.co.jp/renrakuteiki/ これを待っていたのだ。

去年から、お財布ケータイにあれこれ詰め込んで、通勤時に常備するのはケータイだけにすることができてホクホクだったのだが、今年の頭から勤務先が都内に戻り(いやまぁ、これはホントに嬉しかったのだが)通勤経路がJR外になってしまい、Mobile SUICAの出る幕がなくなってしまった。

なんとか工夫して、経路の一部にJRを押し込んで定期が買えんものかと調べてみたものの、JR以外の部分が京王線と都営線の2社にまたがるため、「3社にまたがる連絡定期は作れない」などという凡人には理解不能な制限に引っかかって実現できなかったのだ。

まぁ、このときの調べもののおかげで、3社にまたがる定期が3月中旬から作れるようになるこたあ、わかってたわけで、一時しのぎとして3月末までのPASMOを作ったりしてたのだが、いざ発表になってると結構驚くのだ。

なんと、埼玉奥地に通う際にとことん苦しめられた稲田堤と秋津の乗り換え、それぞれ歩いて5分もかかるんだけど、こんなとこまで連絡定期が作れるようになってるではないか! なにをいまさら。こんなことなら… いやいや、連絡定期があるからって、あんなところに通う気はもうさらさらないけどな。

なにはともあれ、これでまたMobile SUICAオンリーに戻れる。うれしい限りだ。ところで、Mobile PASMOっていつになったら出てくるんじゃろうか。

2008-01-29

あんた誰?

ジミー・ペイジが来日しているらしい。日経BPの記事

お莫迦な記者が、日本の女優だかなんだかの話を振ったらしく、それに答えて「それはだれ?」と返したらしい。いや、あんたの格好が「それは誰」って状態だろう。

ちゃんと指は動くようになったのかよ?
余計なお世話か。

2008-01-02

あけおめ

年が明けた。いつもの正月と違うのはコンビニが遠くなって不便を強いられる事。去年の7月閉店してしまったセブンイレブンの跡地はまだ空家。セブンイレブンを駆逐した京王ストアは、3日からしか開かないのだ。

いまどき黒白20面体ボールはなかろう

さて、新年といえば、ウィーン楽友協会のニューイヤーコンサート中継。今年はEURO2008がウィーン・スイス開催ということもあってか、中継の合間のバレエのひとつがサッカーにちなんだものだった。が、そのパートのコスチュームが酷すぎる。審判役だけがそれらしい格好だったけど、参加国の国旗やらをパッチワークした選手用の服は下品すぎ。他のパートがいつものレベルを維持してるだけにもったいない感が溢れてた。残念。

ところで、アンコールで指揮者のプレートルが持ってきたボールが+Teamgeistのじゃなく、切頂二十面体のにEURO2008と描かれた一見公式球っぽいものだった。びっくりして調べたけど、公式球はやっぱり+Teamgeistタイプ。ありゃ、なんだったんだろう。わざわざ、そこらのボールに印刷したのだろうか?

で、今もまたBS2で再放送中なんだけど、やっぱりSDによる16:9画面はだめだねぇ。BS1とBS2はとっとと再編してHV 2ch体制になって欲しいもんだ。日曜には、BS Hiで再放送があるんだけど、地上波デジタルとどれくらい差があるもんだろうか。去年は地デジでの放送見逃したしな。ネタ元が同じ国際配信だろうから、差は無さそうだけど。

追記

さらに調べると、切頂二十面体のオフィシャルボールがあるのね。FIFA、UEFAの公式球まわりって、みな+Teamgeistタイプになったのだと思い込んでた。各国リーグの公式球は+Teamgeistじゃない方が多いしね。