五都選舉馬後砲

前言

台灣首場五都首長選舉已於 11/27 晚上拍板定案，就上榜率而言藍軍以過半的 60% 大勝綠營的 40%，但以得票率來看的話則是綠營以近 5 成的 49.87% 大勝藍營的 44.54% 共 40 餘萬票。於是照慣例，格揆我一定要放個馬後砲留點紀念，反正格揆我也只會放放馬後砲以免惹上 意圖使人不當選 （沒想到它還是目前的 Google Suggestion 呢）的麻煩。

台北市

就個人情感上對台北市是希望蘇貞昌當選的，不過個人一向對天龍人的民主養成教育沒啥信心，選舉結果也如預期般由在新生高及花博等工程中浪費人民血汗錢的現任市長連任。對司法一向沒啥信心的格揆我也只能說這些爭議案件都將不會有什麼結果了。

另外蘇貞昌在整個竸選期間曾親到台北市各處探查民情，但似乎找不到類似個 Issue Tracker 的問題追踪系統並公開給大眾監管執政者是否已解決問題？個人倒是挺建議蘇這邊把相關資料整理後移交給民進黨台北市議會黨部（或是移交給 TBA 也行？），不只可以讓議員們持續追踪這些問題，搞不好四年後還能用來翻舊帳呢！

對了，每次看到好冰冰市長的台北起飛、Fly High 選舉手勢時總會莫名其妙的想到國家地理頻道中的 空中浩劫 節目，為什麼？因為空難事件絕大多數都發生在起降時刻呀~~

新北市

老實說在過去民進黨多任縣長的先例下，本來並不覺得新北市是一個藍色為主的政治環境，但從此次的選舉結果看來新北市大概就此被劃入藍色版圖內了吧？

至於對這兩位候選人而言，個人沒有太多意見。對小英而言其實本來就不太贊成她出來竸選，至於老是批評小英是選假的的朱市長個人則覺得實在過於小鼻子小眼睛就是了。讓一個現任的新北市長去選總統搞不好可以讓任內已規劃的所有建設一次到位，對新北市民搞不好受益更多呢！再說為什麼每次都只能由選台北市長的人去競選總統呢？這明顯是對其他縣市的一種歧視嘛...

不過，其實北二都失守也不一定要那麼悲觀到又要勞駕精神科醫師 Billy Pan 大叔再辦一次 療傷網聚 啦，阿Ｑ點想，也許這是因為北二都的民眾們比較希望兩位市長候選人能專心準備 2012 總統大選也說不定呢～

台中市

個人是覺得台中市最近幾年實在是沒啥發展，不過反正又不住那邊所以不需要太過在意。只是這次再由胡志強當選讓人好奇台中市民過去九年來對胡市長的臉都不覺得膩嗎？

說到胡志強他這次猛推不少競選廣告，吹牛被捉包的 就不管了，反到是在 大台中 大未來 所提的 與香港競爭、追趕新加玻 （這樣看起來新加破贏香港）口號應該先問問胡市長把台北市放那邊去了吧？

另外胡市長還有一個在競選末期某幾天內曾強力放送的廣告中不知為何總覺得他口齒不清，不知原因是不是我耳朵生繭的關係？

台南市

基本上我對這兩位候選人都不熟悉，但比較想說的是台南縣蘇縣長接受初選結果且即表態支持黨提名人這件事比較有印像；而許市長雖然最後也放棄脫黨參選，但總覺得他本來也想循高雄縣長模式脫黨的，只是不知什麼原因使其放棄而以！

高雄市

對高雄市而言比較有印象的並不是花媽陳菊，反倒是脫黨參選的現任高雄縣長讓人印象深刻。雖然他後期極力訴求不分藍綠、政治中道的企圖明顯，可惜顯然大家對他的『昨是今非、昨非今是』非常有意見。但在這種情形下仍有 40 餘萬票其實力也算是異常雄厚，只不過我覺得他這次真的是賭輸了，未來如果想再走政治這條路應該是會異常艱困吧？

政治光譜的改變

在假圖天圖有篇 【台灣觀察】藍綠光譜的改變! 提到現今的政治光譜已不光是藍綠而以，由於騜式詐騙集團的快速傾中導致這群詐騙集團的政治光譜比較像是紅色而不是國民黨黨徽上的藍色。本來以為在六年級上段班之前這些受過國民黨反共抗俄教育的這一代應該會全力反抗騜的傾中現象，不過實際上看來似乎還有很多人只是單純的效忠黨徽而不是去看領導人有沒有在亂搞的嘛，顯然過去國民黨的愚民教有真是成功呢！

大話新聞

呃，大話新聞不屬於五都的成員，只是因為就幾次選舉下來發現大話新聞的成員總會認為騜式詐騙集團即然這麼糟糕，相信所有台灣人都已經覺醒，必然會給騜一個嚴正的教訓！但每次的期昐的結果總是與預期相去甚遠，這究竟是什麼原因呢？也許就只是別高估台灣民主教育成就而以吧？

意圖使人不當選

以下是網路上討論到的相關文章：

• [廣告] 法律教室：「意圖使人不當選」
• 選舉奧步與 "意圖使人不當選"
• 「意圖使人不當選」之罪？

選後第三天最新心得

• 今天聽說民進黨那些老灰呀全部跑出來批評小英，呃... 這群人實在該乖乖退休比較好...
• 還有人批評都是蘇光頭執意參選台北市長才會打亂原本的必勝配置，呃... 我也不認為新北市民願意看到回鍋的新市長...
• 個人一直不覺得那顆子彈對選情有啥影響，不過似乎全台灣都認為影響可大了？

Maven、Java 1.5 與 xdoclet 的相處之道

最近幾年來的 Java 專案都使用 Maven 2 進行自動化部署程序，講白一點就是不想每次都要依環境差異而透過手工進行設定調整及打包程序。不過有趣的是還是有很多軟體開發人員仍然堅持手工打造然後因為一點疏失就上錯程式捅下漏子！

但是不知道為什麼，整個 Maven 中的 xdoclet plugin 預設一直使用舊版的 xjavadoc 套件，導致在處理 JDK 1.5 新增的泛型特性（Generics）時因為不認識角括號 < 而吐出一大堆錯誤訊息，並連帶使的 Maven 原本提供的 javadoc 操作失敗（產生的 javadoc 不完整），對開發公用程式庫且必須提供 javadoc 的人員來講就變的很困擾。

一直逃避不是辦法，所以今天花了點時間找了網路上的資料後試出了解決方法。基本上是參考 解決xdoclet-maven-plugin於jdk5上跑發生問題 的說法，但文中所提的 plugin 來源 http://quebbemann.kicks-ass.net/maven2/repository/ 被 威猛的趨勢科技世界級創新Smart Protection Network主動式雲端截毒技術 擋在門外... 只好另外找其他的 plugin 來源。

總之，要讓 xdoclet 叫用新版的 xjavadoc 模組的方法是覆寫 xdoclet-maven-plugin 的相依性設定，使 xdoclet-maven-plugin 正確叫用新版的 xjavadoc 1.5 去解析 Java 原始碼，因此需要在 xdoclet-maven-plugin 設定區塊下新增相依性設定如下：

<plugin> <groupId>org.codehaus.mojo</groupId> <artifactId>xdoclet-maven-plugin</artifactId> <version>1.0</version> <dependencies> <dependency> <groupId>ant</groupId> <artifactId>ant</artifactId> <version>1.6.5</version> </dependency> <dependency> <groupId>xdoclet</groupId> <artifactId>xjavadoc</artifactId> <version>1.5-snapshot050611</version> </dependency> </dependencies> <executions> <execution> <id>xdoclet</id> <phase>generate-sources</phase> <goals> <goal>xdoclet</goal> </goals> <configuration> <outputEncoding>UTF-8</outputEncoding> <tasks> <webdoclet destDir="${basedir}/src/main/webapp/WEB-INF" encoding="UTF-8" docencoding="UTF-8" mergeDir="${basedir}/src/main/resources/webdoclet" verbose="true" force="true"> <fileset dir="${basedir}/src/main/java" includes="**/*.java" /> <deploymentdescriptor displayname="${project.name}" xmlencoding="UTF-8" description="${project.description}"> </deploymentdescriptor> </webdoclet> </tasks> </configuration> </execution> </executions> </plugin>

但是光這樣還不夠，因為 Maven 官方的套件庫中並未包含 xjavadoc 1.5 相關資訊，所以必須另外指定去那邊下載 xjavadoc 套件，這只要在 pom.xml 中加入以下設定區塊即可。唯一要注意的是這個套件庫有可能隨時不見... XD

<pluginRepositories> <pluginRepository> <id>jahia</id> <url>http://maven.jahia.org/maven2/</url> </pluginRepository> </pluginRepositories>

好了，經由以上設定後 xdoclet 就不會因為程式碼使用到 JDK1.5 的泛型功能時只會吐出一堆 warning 了！

試乘捷運蘆洲線

聽說今天是捷運蘆洲線試營運的第一天，格揆我也湊個熱鬧調整了下班路線跑去試試看免費的蘆洲線究竟如何？

整個回家所需時間約為 80 分鐘，比原本路線的時間差不多得多花個 20 分鐘以上才行，為了早點兒奔向溫暖的床舖我相信蘆洲線應該只會搭這麼一次吧？

從 18:57 離開辦公室到回到家裡的時間 20:15 各種狀態（咦？狀態圖？）如下：

狀態	時刻	花費分鐘數	原路線所花時間
離開辦公室	18:57	-	-
出辦公大樓	19:00	3	3
搭上南港展覽館接駁公車	19:09	9	9
到達捷運南港站下公車	19:13	4	4
捷運南港站發車	19:17	4	4
捷運忠孝新生站下車	19:31	14	-
捷運蘆洲線忠孝新生站發車	19:37	6	-
捷運三重國小站到達	19:50	13	-
出捷運三重國小站	19:53	3	-
出捷運台北車站	-	-	17
台北車站-忠孝候車站	-	-	3 ~ 5
等待公車(藍1/39)	-	-	3 ~ 5
扺達三重大同路口	-	-	10 ~ 20
開家門	20:15	21	5
合計		77	67

其實從南港轉捷運蘆洲線回三重所需時間不算很多，但是從三重國小站要回到天台這一帶的話是要花上一點時間的。如果晚餐想在三和夜市中解決的話是可以考慮這一條回家路線，不然的話從台北車站經忠孝橋回三重通常會比較快才是！

還有從上表中可以發現在忠孝新生站轉車的等待時間偏久，不過如果以上班不遲到為考量的話搭乘捷運上班有其優勢存在（但是捷運三不五時會突槌，那叫做正常能量釋放）。最後整條蘆洲線的月台設計似乎都給人一種空間上的壓迫感，在等車的時候可能會造成心情上的不快！

[公告] 切換部落格網址

原本就計畫將目前的 adahsu0521.blogspot.com 網址連結到原本使用的 blog.adahsu.net 上，今天正式完成了這個設定。不過因為 DNS 同步的問題可能最遲會到一星期後才能正常訪問。

Android Froyo 2.2.1 升級失敗

前陣子 Google 䆁出了 Froyo 2.2.1 的小升級，身為 Nexus One 持有者當然會優先收到 OTA 通知，只是這次的升級... 失敗了...

因為使用過一鍵 ROOT 工具，所以早早就以節省 ROM 空間的理由把 /system/app 中的東西砍的砍、搬的搬，而這個沒有官方更新資訊的 Froyo 2.2.1 除了已知的解決了一鍵 ROOT 所使用的系統漏洞外還順便更新了系統內建的 GMail.apk 到 2.3 版。

問題在於 GMail 2.3 這個升級版本來就可以從 Android Market 中下載，所以我也早就把原始的 GMail.apk 給弄走換成新版的 GMail ，於是 Froyo 2.2.1 在更新的過程中因為找不到 GMail.apk 的關係所以 patch failed ... 想當然，於是 OTA 就這麼莫名其妙的失敗了... 還好雖然 OTA 失敗但系統仍然可以透過組合鍵重新開機，只是 OTA 更新就這麼不見了...

重新開機後原始的 ROOT 環境還在（呼~~ 好佳在），趕快把 GMail.apk 搬回去再把 GMail 2.3 移除後，至今為止（才過了一天而以啦）還沒重新收到 OTA ，也許我得堅守在 Froyo 2.2 了吧？

※如果還有更新其他套件的話，那下次 OTA 應該還是會失敗吧...

2010-10-03 補充：
昨天再次收到 Froyo 2.2.1 升級通知，這次也沒太多考量就莫名其妙給它按下更新... 然後... 又失敗了... XD

這次它去更新 Google Goggles，但... 我移掉了... XD

2010-10-08 補充：
今天三次收到 Froyo 2.2.1 升級通知，這次也沒太多考量就莫名其妙給它按下更新... 然後... 又失敗了... XD

這次它去更新 Amazon MP3，但... 我移掉了... 而且是沒備份的移除了... XD 顯然只能重刷 Froyo 2.2 後再進行升級了... @@

促銷價格的背後

有家超商喜歡用第二件六折的方式拉抬產品銷量，也有一家超商總是以二件 79 折方式來吸引消費者的眼光，畢竟第二件六折的實際意義就是二件八折，這個 79 折策略聽起來就是有那麼一點佔人家便宜的感覺。

上圖就是 79 折的實際案例，只是這個整箱特價似乎有點問題... 

以一罐鋁泊包飲料 10 元來計算，192 元其實是打八折時的價格，如果以 79 折來計算的話應該是 189.6 元，只是超商是否會進位到 190 元則不太確定，而且超商的 POS 會刷出多少錢出來也有待測試。

嗯，不過在這邊計較這兩塊錢會不會顯的太窮酸樣了呢...

昨日的冒險旅程

昨日 ( 2010/08/13 ) 下班所搭乘的公車在剛過新莊思源路時，忽聞司機伯伯一聲廣播：『抱歉，請各位準備更換車輛，本車爆胎了... 』！正當大家還莫名其妙摸不著頭緒時，車身一震，原本轟隆（這是誇飾法）的引擎聲嘎然而止.... 我想，再怎麼狀況外的人也都知道該下車了... XD

不過，下車後所看到的景像可就讓人心驚膽顫了...

寄件者 危險

那麼它的右後退呢？

寄件者 危險

點選照片可以連到有地圖標示的 Picasa 相簿！

最佳英文翻譯獎

這個翻譯真是超贊的...

如何在下載動作中正確顯示中文檔名？

總而言之，除了為人垢病的 CSS 問題外，各家瀏覽器在下載中文檔名時也有各自的脾氣...

以下是 JAVA 程式碼範例，大致上就分成兩派：支援 RFC-2231 的 Firefox/Opera 系和不支援的 IE /Webkit 系兩種，在 Test Cases for HTTP Content-Disposition header and RFC 2231/2047 Encoding 網站中有對各家瀏覽器是否支援 RFC-2231 規範的測試記錄，就結果來看除了純 ASCII 編碼的檔名頗受大家都支援外 (?)，其他混雜有各地語言的檔案名稱就得依瀏覽器的派別個別處理了。

if ( StringUtils.contains( userAgent, "MSIE" ) || StringUtils.containsIgnoreCase( userAgent, "AppleWebKit" ) ) {
    res.setHeader("Content-Disposition", "attachment; filename=\"" + URLEncoder.encode( fileName, "UTF-8" ) + "\"");
} else {
    res.setHeader("Content-Disposition", "attachment; filename*=UTF-8''" + URLEncoder.encode( fileName, "UTF-8" ) );
}

就目前測試結果得知：

1. IE 6：可以正確彈出下載視窗，但存檔時的不一定能顯示正確的中文檔名
2. IE 7/8：可以正確彈出下載視窗及中文檔名
3. Chromium 5.0.360.5 / Chrome 5.0.375.3 dev：可以正確彈出下載視窗及中文檔名，其 AppleWebKit 核心版本分別為 533.3 及 533.4
4. Safari 4.0.5：在 AppleWebKit/531.22.7 時兩種方式都不行，但因 Chrome 的經驗猜測更新 AppleWebKit 到 5.33 以後版本即可正確顯示中文檔名
5. Firefox 3.x：可以正確彈出下載視窗及中文檔名
6. Opera 10.51：可以正確彈出下載視窗及中文檔名

OpenTTD 簡單心得

最近不務正業的在玩 豪華運輸大亨 ，都忘了要趕快規畫倒底要寫那類型的 Android 軟體了... 不過還是簡單記錄一下大亨的入門心得好了。

這個遊戲的重頭大戲其實在鐵道規劃上，如何利用鐵道號誌讓一大堆的火車可以在雙向兩條軌道上正常運行而不會有對撞、追撞等事故算是最簡單的入門（雙軌雙向軌道真的比單軌雙向軌道簡單多了）。雖說只是入門，但看著二、三十輛車在軌道上依序運行卻總能帶給玩家滿滿的成就感。以下是釀成多起追撞、對撞事故後的注意事項清單！

1. 如果要賺錢的話可以搞航空運輸，不過個人覺得很空虛...
2. 如果要搞鐵道貨運的話網友都會建議以媒炭為主
3. 雙軌鐵道要先統一是左出右進還是右出左進，像台灣的鐵道記得都是左出右進的！
4. 雙軌鐵道在分歧點時都需要設置號誌，簡單的概念是左邊出口處要放入口號誌，右邊進(入)口處則放置閉塞號誌，號誌應設置在前進方向的右側，以左出右進來看號誌就會集中在鐵道中央。有興趣者可以參考 這裡 ！
5. 如果軌道上有多輛車次的話則視鐵道長短酌量設置閉塞號誌，不然的話車子會卡在車站出口處。而車站出口處一被卡死就會造成同軌道上的車輛要不就跟著卡死，要不然就是追、對撞事故。
6. 維修機場不要設在離車站太近的地方，距離至少要超過車輛長度（7格14節）及號誌設置區，不然有很大的機會出現車輛卡在車站與機場之間動彈不得的情形。

嗯，有新的心得會繼續補充！圖片的部份再想辦法生出來...

陷入無限迴圈的火車...

敢搶我礦產者，必阻之！

Android Developer Lab 參加心得

好吧，我承認這一篇是炫耀文，其實沒啥心得可言！

忘記是去年底還是今年初在噗浪上看到葉教授發佈 Android Developer Lab 台北場開放報名時，因為天真的幻想能在 Android 平台上撰寫自己需要的軟體，於是莫名其妙的就填完單子完成報名手續。因為 Google 沒有立即回覆任何訊息，所以也差不多忘了這件事，直到過年前收到 Android Developer Lab 報到通知時才想起來要留一天年假去參加這個我戲稱為 Android 開發者聯誼會的活動。

聯誼會的日子很快的到來，因為入場時間是在 12:30 這個挺微妙的時間，所以早上硬是逼著自己不可太晚吃早餐以免中午吃不下結果在會場內昏倒的蠢事發生。還好，當葉教授說要出發前往會場時確認沒有供應午餐後，我也在 11:15 時分出門搭乘 638 前往六福皇宮會場。午餐是先在附近的小吃店以榨菜米粉湯（真的沒有肉絲）解決。

這是今天 Android Developer Lab 的入場券，並且憑券得兌換小禮物乙份！

到了 12:37 時活動正式開始，然後就聽到令人振奮的一句話：『今天活動要以英語為主』... 雖說插大時英文考的比國文好，但好像我的國語遠比英語像樣很多，於是老灰呀注意力無法長時間集中的問題就發作了，時而恍神、時而回魂是今天活動中最主要的精神運作模式...

總而言之，第一段是葉教授簡短介紹 Google Taiwan 及 Taipei GTUG，接下來換人介紹手機上網的趨勢；然後是 Android Marketplace 的上架辦法及一些注意事項。這部份雖然大致聽懂講者的內容大意，但全程英語還是有一定的催眠效果。就在恍神模式下時忽然看到這個 Google Japan 所拍的 Nexus One 忍者開箱動畫 。正沉浸在影片中 KUSO 的宣傳手法時竟然聽到要送手機的字眼，你知道的，有東西吃或是有禮物拿時總是可以讓人眼睛為之一亮，於是所有人就全部擠出門去排隊領 長崎蛋糕 Nexus One 禮盒。在等待的過程中不少人還抱持懷疑態度以為手機只是借用，會後需要歸還的。但一切都在有人按耐不住的詢問工作人員後獲得解答：『不用還，手機真的是送的』！Google 大神啊，您真是佛心來著呢！

因為在領取手機前有說到接下來的兩堂課會實作，如果電量不足的話腳邊有插座可用（後來覺得應該是聽錯了），於是大部份人都在現場玩起開箱遊戲。不過最後發現其實手機可以原封拎回家好好開箱的，現場實作用模擬器就可以了。這也是我覺得之前提到的插座應該是為了給筆電沒電的人使用的，並非說是對手機充電之用。

這就是憑入場券所兌換的長崎蛋糕禮盒（誤）

由於聽說第三節開始是實作說明，所以有個笨蛋就把筆電開機了。可是搞了半天原來是介紹 Android SDK 2.1 的許多新特性，於是白白浪費了 50% 的電量在這堂課中（6 cells 電池是撐不久的），等到真正 Coding 練習時我的筆電就在低電量警告訊息中沉沉睡去........

CodeLab 練習的題目是動態桌面的實作，講師提供了一個 基礎 Eclipse 專案設定作為練習 ，但因為投影片的字是真的有夠小所以最後我下載 FINAL 版進行比對，在程式碼確認的差不多時當然會想要執行看看，然後就在模擬器啟動途中看到低電量警告，原本以為來的及看到程式效果的幻想則在筆電自我感覺沒電不太好自動關機的情形下完全破滅...

還好這時候講師也實作完畢，時間進入 Q&A 時段... 看著鄰兵打包走人後，我也開始找地方塞剛領到的長崎蛋糕禮盒，然後出門去搭車回家。

搭車時有在想，動態桌面這個題目是不是有點雞肋呢？我以為大部份開發人員應該不會對這種不以實用為目的的特色有太多關注，那麼今天這個 CodeLab 範例選擇這個題材是否有啥特殊意義呢？和 Widgets 搶食桌面空間？其實到現在我還是沒有任何答案就是了...

對了，今天領到 Google 高科技小禮物雖然很 High ，但是 5800XM 上原本同步來的通訊錄整個不見也令人很駭... 回家第一件事是上 Google 看看通訊錄內容有沒有跟著消逝，還好，它們還在！

全劇終... ！

ONE PIECE: STRONG WORLD

上週到國際書展時才發現原來 ONE PIECE 電影版 STRONG WORLD 強者天下 已經上映後（剛好上映的隔天去書展的），就幻想著一定要趁過年前先看一看。今天是過年前最後一個假日，我也很努力的在京站威秀售票口前排了將近一小時的隊。不知道為什麼 場次的安排 似乎不是連續的，還好大家顯然都跑去看 MONGA 而沒來和我搶 ONE PIECE 的座次。雖然尚未滿座，但是這個可容納百餘人的小場地其實在輪到我購票時也沒剩幾個位置可以選了，此刻倒是有一種為什麼早上不先多花 20 元手續費直接網路購票的悔恨... (泣)

就劇情上來講可能要扯到 OnePiece 第 0 卷，另外在動畫版部份魯夫於到達海底監獄『推進城』時也有加入一段金獅子的故事（426話開始）。總而言之，這是一場世界政府的危機但最後世界政府啥都不能做的故事。至於為什麼世界政府啥都不能做的理由還請進電影院瞧瞧！

另外在各橋段中總是一直穿插著各式各樣的笑點，不過印象最深刻的應該是布魯克被食肉蟻小看時說的那句『我只是局部型肥胖』吧！這真是中廣型阿宅最需要的一句救世密令啊... XD

• 沒想到 WIKI 上已經有人整理了 電影相關資料 了！
• 除了娜美的裸露演出外，羅賓的馬尾 + 眼鏡娘造型倒也是讓人印象深刻，雖然她最後沒啥表現機會！
  
• MONGA 發音要正確，不然會變成 MANGA。
• 對了，這是 MONGO 預告片！
• 如果有人想請客的話，我還很願意再進電影院看一遍.... XD
• 啊對了！個人覺得本劇場版應該歸為輔導級，因為裡面抽煙的人太多了卻沒有打馬賽克...
  

把 SFTP 關起來 (CHROOTED)

前言

為了提供少量的檔案共享但又不願意特地去設定 FTP 服務的話，通常第一個想到的會是附屬在 SSH 服務下的 SFTP 傳輸模式，事實上 SFTP 這個服務雖然因為加密的關係會導致傳輸時間略長，但卻一直是格揆我作為檔案傳輸的唯一方式。但這方式雖方便卻有個大問題：登入的使用者可以看到所有的檔案目錄甚至直接下載檔案內容。這在多人使用的環境下顯然會有資安上面的困擾，有沒有辦法把 SFTP 服務關在某個指定的目錄下呢？

格揆經由 Google 大神的協助並多方測試後終於實作出可行方案，就... 再貢獻回給大神吧... XD

設定步驟

※ 本文以 OpenSSH 5.2_p1-r3 為設定環境！

1. 選定封鎖目錄：如果對像是單一個人時即為該用戶登入 SFTP 時的根目錄；如果對像是一個群組時則該目錄為這群使用者目錄的根目錄。
2. 在 /etc/ssh/sshd_config 中啟用 sftp subsystem：特別注意要啟用的是 internal-sftp 這個 Subsystem。

   # override default of no subsystems
   #Subsystem      sftp    /usr/lib64/misc/sftp-server               # 系統中原來的設定
   Subsystem       sftp    internal-sftp                                       # 改用 internal-sftp 
   

3. 一樣在 sshd_config 中指定需要被關起來的使用者資訊及要關到什麼地方去，請在前述修改處之後加上以下設定：

   Match User ada                                 # 要被關起來的使用者，如果是群組的話則將 User 改為 Group 再接群組名稱
                                                             # 例如： Match Group rootedSFTP
   ChrootDirectory /chroot                    # 要關在什麼地方，如果對像是個群組且群組內的每個人有個別目錄設定時，
                                                             # 可以加上 PATTERNS (man ssh_config) 做區隔，如 /chroot/%u ，
                                                             # /chroot 為這群使用者目錄的根目錄。
   ForceCommand internal-sftp            # 一樣要使用 internal-sftp 這個 Subsystem
   

4. 設定 Chroot 目錄權限：錯誤的目錄權限設定會導致在 log 中出現 "fatal: bad ownership or modes for chroot directory XXXXXX" 的訊息。根據 openssh 5.1 chrootdirectory permissions issue 這篇文章的資訊顯示，目錄的權限設定有兩個要點：
   • 由 ChrootDirectory 指定的目錄開始一直往上到系統根目錄為止的目錄擁有者都只能是 root
   • 由 ChrootDirectory 指定的目錄開始一直往上到系統根目錄為止都不可以具有群組寫入權限
5. 重新載入 sshd 後即可透過 FileZilla 等支援 SFTP 的軟體測試有無被關起來了...