從台固到 www.ru

從台灣 NTT 到日本，再到美國，再到英國，然後轉進俄羅斯：

traceroute to www.ru (194.87.0.50), 64 hops max, 52 byte packets
1 gw-60-199-247-254.pixnet.tw (60.199.247.254) 0.673 ms 0.471 ms 0.492 ms
2 60-199-248-49.static.tfn.net.tw (60.199.248.49) 0.486 ms 0.477 ms 0.491 ms
3 60-199-255-113.static.tfn.net.tw (60.199.255.113) 0.239 ms 0.227 ms 0.241 ms
4 60-199-6-125.static.tfn.net.tw (60.199.6.125) 0.364 ms 0.354 ms 0.366 ms
5 60-199-6-2.static.tfn.net.tw (60.199.6.2) 6.235 ms 0.480 ms 0.364 ms
6 60-199-6-222.static.tfn.net.tw (60.199.6.222) 0.625 ms 0.479 ms 0.589 ms
7 61.58.33.189 (61.58.33.189) 0.697 ms
61.58.33.145 (61.58.33.145) 0.607 ms 0.606 ms
8 xe-1-0-0.r21.taiptw01.tw.bb.gin.ntt.net (129.250.16.169) 0.864 ms 0.728 ms 0.740 ms
9 as-2.r21.tokyjp01.jp.bb.gin.ntt.net (129.250.4.81) 31.596 ms 31.720 ms 31.713 ms
10 ae-3.r21.osakjp01.jp.bb.gin.ntt.net (129.250.4.214) 74.068 ms 40.205 ms 40.090 ms
11 as-1.r21.sttlwa01.us.bb.gin.ntt.net (129.250.3.87) 133.416 ms 133.520 ms 133.534 ms
12 as-1.r20.nycmny01.us.bb.gin.ntt.net (129.250.3.191) 221.853 ms 221.841 ms 221.855 ms
13 as-1.r22.londen03.uk.bb.gin.ntt.net (129.250.3.255) 298.929 ms 295.420 ms 295.305 ms
14 xe-4-4.r01.londen03.uk.bb.gin.ntt.net (129.250.2.66) 289.934 ms 289.922 ms 293.930 ms
15 * * *
16 transtelecom-0.r01.londen05.uk.bb.gin.ntt.net (83.231.146.86) 355.979 ms 357.880 ms 377.121 ms
17 demos-gw.transtelecom.net (217.150.57.89) 350.517 ms 354.882 ms 350.527 ms
18 iki-c1-vl10.demos.net (194.87.0.111) 355.508 ms 354.507 ms 352.039 ms
19 www.ru (194.87.0.50) 352.881 ms 351.010 ms 351.147 ms

日本到俄羅斯居然這麼遠...

DNS server 與 AS

昨天 #bsdchat 剛好在討論 tw.freebsd.org 的 NS server 的事情。目前很多 freebsd.org 的 subdomain 都只有在當地，像是日本、南韓、德國：

jp.freebsd.org. 3600    IN      NS      ns3.imgsrc.co.jp.
jp.freebsd.org. 3600    IN      NS      castle.jp.freebsd.org.
jp.freebsd.org. 3600    IN      NS      asuka.jp.freebsd.org.

kr.freebsd.org. 86400   IN      NS      ns.ziom.co.kr.
kr.freebsd.org. 86400   IN      NS      ns2.ziom.co.kr.

de.freebsd.org. 10771   IN      NS      ns.cs.tu-berlin.de.
de.freebsd.org. 10771   IN      NS      baerenklau.de.freebsd.org.

這其實對於 DNS 架構來說，並不是很好的設計。比較好的設計是放到不同地區 (不同洲)，確保不會一起掛掉。

主要的原因在於有些服務會對「查不到 DNS record」很敏感，像是 mail system：

1. 對於 username@tw.freebsd.org 的人，發信時如果找不到 tw.freebsd.org 的 MX 與 A record，被認定是 spam 的分數會上升。
2. 對於寄信到 username@tw.freebsd.org 的人，如果找的到 MX 或是 A record，但連不到 mail server，那麼這封信會被保留在 mail system 裡面。但如果找不到，會馬上被退信。

所以，要避免大停電或是大斷線影響其他系統，應該要儘量把 NS server 放到不同地區，不同 AS# 的網路上。

國內的網路，與 CDN

前陣子跟一堆老外們談 CDN 服務，計費方式還蠻彈性的，常見的兩種包括以實際流量計算，或是 MRTG 五分鐘圖 sorting 95% 流量計算。

不過，值得提出來的，CDN 的價錢比起國內的頻寬都便宜。以 Slideshare 這個站公開的數據來看 (Panther Express and S3)，每個月重新計算，第一個 8TB 是 USD$0.28/GB，第二個 8TB 是 USD$0.24/GB。

如果網站有區域性，100Mbps (MRTG 五分鐘圖 sorting 95% 計算方式) 大約是 20TB/month，照比率計算，第一個 8TB 換算成 sorting 95% 是 40Mbps 的量，也就是 NTD$1764/Mbps。這個價錢如果在國內的 ISP 只買 40Mbps，在不靠關係，又要有一定的網路品質，是不可能的數字...

以目前來看，把靜態檔案丟到 Amazon S3 上，以 reverse proxy CDN 算是相當好的方式。

對了，國外的 CDN 大多都有提供試用的服務，跟 sales 要求，通常都有測試的機會。Wikipedia 上的 Content delivery network 這個條目下面列的公司都可以寫信去問看看。

寫自己的 PHP Controller

我對於 Zend Framework 的 Zend_Controller 實在是搞不太懂，要求使用 PHP5，但又沒用到 PHP5 的特性...

我理想中的 Controller 是透過 PHP5 的 ArrayAccess 實做這樣的效果的：

$name = $c['name'];
$c['Content-Type'] = 'text/plain; charset=UTF-8';

我花了點時間開始寫自己的 Controller，希望善用 PHP5 語言特性使得寫起來比較方便，順便玩玩 Mercurial 的操作方式。

目前 Repository 放在 freeHG 上：Hasname Controller，有想要看看到底是怎麼搞的人可以自己 clone 回去看，等之後功能比較完整後再開始來寫文件。

太久沒到這邊來寫 blog...

太久沒寫 Blog 反而被標上 Spam Blog？XD (寫文章需要 CAPTCHA)

FreeBSD 上 rpc.lockd 的問題

FreeBSD 上 rpc.lockd 常常會自己掛掉。如果是 clients 的 rpc.lockd 掛掉，會使得 flock() over NFS 掛掉，而如果是 servers 的 rpc.lockd 掛掉，會使得所有 clients 的 flock() over NFS 掛掉 =_=

這個問題自從我們將某幾台 ccbsd*.csie clients 換成 FreeBSD 6.0-RELEASE 後就發現這幾台一直有問題，後來決定將 cchome.csie 與 mailgate.csie 也一起升級到 FreeBSD 6.0-RELEASE，看看能不能解決這個問題。結果反而變成大家都有問題... -_- 而且 ccsun*.csie 只要一開機，所有的 clients 就會炸掉，但這些 ccsun*.csie 裡面，如果只開 ccserv.csie 也不會有事情...。

這個問題當時猜測是 FreeBSD 4.x 與 6.x 的 clients 混在一起跑造成的，於是狠下心來將 ccbsd*.csie 全部升級到 FreeBSD 6.0-RELEASE (另外一個原因是 FreeBSD 4.x 已經不繼續維護了)，結果升級上去發現問題還是沒變好，只好試著惡搞所有能惡搞的功能 (像是 mount_nfs 裡的 -L local lock)，發現還是沒有用。

前幾天想到 ktrace 可以看 system call 的情況，拿出來追，發現 uid=daemon 的 rpc.lockd 最後居然是死在 SIGPIPE，將這個 bug 用 send-pr 送出去幹剿後，rpc.lockd 的 maintainer 丟出一個神秘的 patch：把 SIGPIPE 用 signal(SIGPIPE, SIG_IGN) 堵掉，#bsdchat 上面看到這個 patch 把他叫做「掩耳盜鈴」，當作沒聽到，幹就對了 XD：Problem Report bin/97768 : NFS rpc.lockd will die automatically。

雖然這個方法看起來很鳥，但我還是決定把這個 patch 弄進所有 ccbsd*.csie 上跑，然後開 ktrace 盯著看還會有什麼死法。跑了快一天，發現 ccbsd*.csie 跑起來好像不錯，寫了封信跟 maintainer 講... 沒多久就看到 cvs commit 記錄：cvs commit: src/usr.sbin/rpc.lockd kern.c，結果才剛 commit 完沒多久就發現 uid=root rpc.lockd 死掉 XD

看了一下 uid=root rpc.lockd 死掉時 ktrace 的紀錄，發現也是 SIGPIPE 的問題，正覺得奇怪，明明 mask 掉了，怎麼還會死在 SIGPIPE... 回頭看 patch 發現是因為 signal() 在 fork() 後才做，所以 uid=root 那隻沒有處理 SIGPIPE，只好再跟 maintainer 講，問看看能不能把 signal() 放到 fork() 前。(主要是他對 rpc.lockd 比較熟，可能會比較清楚各類後遺症 XD)

結果 maintainer 就叫我去測測，沒問題就照我說的 patch 進 -current XD 我就跑去跟 chwong 要了 cchome.csie 與 mailgate.csie 的 root，要跑 ktrace 盯著看。

測了一天看起來沒問題：rpc.lockd 沒死，mutt 看信也都很正常，看起來 locking 功能運作得很好，就回封信跟 maintainer 講這個情況，過不久就看到他把 signal() 搬到 fork() 前的 cvs commit 紀錄：cvs commit: src/usr.sbin/rpc.lockd kern.c，這個 patch 的 rpc.lockd 到現在都還活得很好，看起來在 6/1 那天就會進 RELENG_6 了 :)

然後在 #bsdchat 上看到 rafan 把這個 patch 也丟進 csie.ntu 的機器上跑，發現對於 NFSv2 的 Sun 也正常多了 (打開 debug mode 還是會看到一堆 error msg，不過至少會動...)，於是我剛剛就很高興的跑去學校把 ccsun*.csie 通通開起來測，目前看起來也都沒問題...

折騰了兩個月，NFS 的 rpc.lockd 這件事情看起來暫時穩定多了，希望有長輩把 rpc.lockd 修一修，尤其是 recovery 的部分，如果寫完的話才能隨意關機開機 XD

lighttpd + WordPress 2.0 對於 Permlink 的處理

lighttpd + WordPress 2.0 使用 Permlink 的設定，重點在於 lighttpd.conf 裡的 mod_rewrite：

url.rewrite = ( "^/(archives|categories|comments|feed)/" => "/index.php" )

WordPress 裡 Permlink 則是設成：

/archives/%year%/%monthnum%/%day%/%post_id%/

Category 的部份則是：

/categories

FreeBSD NFS locking 問題

我們一直以為是 4.x 與 5.x/6.x 之間的問題，結果剛剛 ericlin 丟了一個這幾天的討論串過來，大光頭 Kris 還提供了一個 patch，是 lock_proc.c 這個檔案從 1.17 到 1.18 的 patch (6.0-RELEASE 是 1.18)：NFS locking question。

這個 patch 看起來是 transmit_result() 與 transmit4_result() 的修正，不知道 4.x 有沒有 svc_getcaller()，如果有的話可以試著 patch 看看...