DSCN9805

經過連續四次的每月線上技術會議 (Webinar #1, #2, #3, #4) 後,二月決定移師台北外出走走,mcdlee, Louis Liu 兩位資深志工特地從高雄一天來回台北參加此次活動。2014/02/15 的台北象山 Mapping Party 總共有十六位朋友參加,所幸未因雨取消活動。

 

DSCN9881DSCN9849

Mapping Party 的主要目的是希望帶領一些新朋友熟悉繪圖工具,因步道仍溼滑,本次活動不行攀岩路線,依照體能分成兩隊,一隊走四獸山步道,另外一隊則走南港山稜線步道。由於規劃的時間有限,並未針對原地圖標示 tag:fixme 的未明路線的進行踏查,主要仍行大眾路線,並沿路紀錄需繪記的地標。並於約下午兩點回到 Mozilla Space 進行現場繪製與經驗分享。

1556260_10200830314674994_1404295785_o

本次修改主要是沿途道路的情報更新,新增黃蟬園路線與位址、修正高壓電塔路線、改善松山家商一帶的資訊、調整四獸山區域的林木線,每次一點點的小更新,都會讓地圖更加完善。以下是本次活動的編修紀錄

以下是 kcwu歷史對照工具提供的修改前後比照圖

以下跟 Google Map 的圖資比較

很明顯開放街圖在山區的詳盡度大勝 Google Map,雖然涵蓋的路線仍尚未覆蓋全台百岳或知名路線,道路品質也尚未能夠進行導航規劃,但登山之人行步道與道路的識別度已高於非戶外專用的圖資。比起 Garmin 等台灣商業圖資,在市區的詳盡度仍有很大的改善空間。
garmin-20131030

相較於幾年前,開放街圖的資料已經大幅提高。但仍須志工投入,無論是使用或是回報問題或是成為繪圖志工。就像 2014 年冬季奧運的所在地 – 索契一樣,集結眾人的力量完成詳細度大勝商業圖資的免費地圖!

如何開始貢獻

如果您有任何操作上的問題,歡迎參加以下的活動或透過線上網站發文,志工們都很樂意回答您的問題。

三月份相關活動

  1. 2014-03-15 台北士林官邸 Mapping Party

 關於開放街圖台灣社群

歡迎加入台灣開放街圖社群!

特別感謝

養了很多 Debian/Ubuntu 機器時,時常得利用 apt 大量更新軟體。最常見的需求是 Security updates,所有伺服器都會抓取同一份軟體,機器量一大用掉的頻寬也很可觀。為了省下這些頻寬,得在伺服器區域網路設定一組快取伺服器,讓全區域網路下載一次。

有得人會自己建一份 archive mirror.

但是 Debian/Ubuntu 套件眾多,全部映射一份實在很費空間。我個人偏好只快取曾經抓過得檔案。

Debian/Ubuntu 中已經有幾個選項可用
approx – caching proxy server for Debian archive files
apt-cacher – Caching proxy for Debian package and source files
apt-cacher-ng – caching proxy server for software repositories
apt-p2p – apt helper for peer-to-peer downloads of Debian packages
debtorrent – bittorrent proxy for downloading Debian packages
apt-transport-debtorrent – an APT transport for communicating with DebTorrent
squid-deb-proxy – Squid proxy configuration to optimize package downloads
squid-deb-proxy-client – Automatic proxy discovery for apt based on avahi

其中 apt-p2p 與 debtorrent / apt-transport-debtorrent 是大約 2006-2008 年 p2p 技術熱門時的嘗試。而 debtorrent 直接利用 bittorrent 協定,而 apt-p2p 使用 kademlia DHT 協定來處理分散檔案,需要安裝 Twisted. 兩個概念都很有趣,但是我並不想在每台機器上架設 p2p server,純粹只是需要供應新的安裝檔案。

個人評估之後,選了 apt-cacher-ng. 設定簡便,apt-get 安裝完即可用,不相依於其他網站伺服軟體。還有簡易的管理界面可以看快取效率唷!

由於它基本上是個 http proxy,所以你可以用 transparent proxy 來導引所有的下載,或者在 /etc/apt/apt.conf.d/90aptcacher-ng 加入以下設定即可。
Acquire::http { Proxy "http://10.11.11.254:3142"; };

除了可以透過預設網頁來看快取狀態,也可以在 console 跑 /usr/lib/apt-cacher-ng/distkill.pl 來看硬碟上佔用了多少空間。

References

AptProxyCache – Ubuntu Wiki https://wiki.ubuntu.com/AptProxyCache

apt-cacher-ng

apt-cacher

approx

DebTorrent

apt-p2p

AptProxy

今年 COSCUP 2013 時候,總於又開始辦 Key Signing Party。其實過去幾年在 Debian Birthday Party 時,常常也會非正式的交換簽章。這是第一次比較正式的用 The ‘Sassaman-Efficient’ Method 進行。總共二十人參與,成效還不錯!

IMG_3787 gpg-20130808

過程中收到幾個朋友來信詢問問題,特地整理幾個 FAQ

金鑰過期時間 (Expire day) 是否要設定,要設定多久?
你應該養成設定過期時間的習慣。你不用擔心過期要重新建立新的金鑰,你可以延長過期時間後,重新送到 key server 上。這樣別人就會取得你新的金鑰。若你金鑰遺失或忘記密碼也弄丟 revocation certificate 的時候,過期時間可以告訴你的朋友這把金鑰已經不能夠相信了。請找你聯絡換把新的。至於過期時間,則看你有多頻繁使用 PGP,我個人設定六個月,純屬偏好。

記得生成 revocation certificate
revocation certificate 是當你的金鑰遺失或被竊走得時候,你可以宣告這個金鑰失效。所以請生一份出來藏好,然後千萬不要被別人偷走。
gpg --output revoke.asc --gen-revoke <keyid>
如何簽署金鑰?
若你使用 Debian 或 Ubuntu, 請安裝 signing-party, 其中有一個工具叫做 caff(1). 他會以提問方式將你所選擇的金鑰簽署之後,以郵件加密寄給該金鑰收件人。這麼做的目的是,我們當場於會場認證對方的姓名,但是無法驗證他的電子郵件。經由加密寄送的方式,可以確保他使用該郵件系統。

因此你不應該把簽署過金鑰直接送到 key server 上,而是加密寄給他。這樣就不會造成他可能冒用別人的郵件信箱。

如何接收簽名?
請將每個人寄給你的信件解密,取出新的金鑰簽章,匯入你自己的 GPG Keyring,然後把新的金鑰上傳到 keyserver. 如果你沒有上傳,其他人是無法知道你已取得簽章。

姓名識別
交換的過程,最常見就是大家都只使用音譯,但是一般的中文證件上不會顯示英譯。所以你必須攜帶護照,才能讓對方驗證你的名字。你也可以在產生新簽章的時候,在註解 (comment) 輸入中文姓名 (請使用 UTF-8),這樣會比較容易進行驗證。但是不要在 comment 寫一些亂七八糟,無益辨識的資訊

另外,臺灣的護照容許你使用 Alias Name, 不彷把常用的英文名字加入。例如我的護照上即有 “Rex” 為別名。

使用金鑰包裝套件的技巧
你若常常需要包裝套件,不妨新增一把 subkey。一般而言,你必須十分小心的藏好的你的金鑰,例如存在其他人無法存取的離線媒體上。但是身為一個 Debian / Ubuntu 開發者,你每天都需要簽署並上傳新的套件。金鑰藏在離線媒體其實非常不便利。

Subkey 容許你在沒有主金鑰 (Master key) 的狀況下簽名或加密,也可以隨時取消或更改 subkey. 因此你可以安全的把金鑰藏在某個無人知曉的地方,把新的 subkey 專門拿來簽署用。萬一出了狀況,只要註銷這把子金鑰即可,不用大費周章的重生一把新的金鑰。

十一月初的時候,到 Orlando, FL 的 Caribe Royale 出席參加 12.04 的 UDS-P – Ubuntu Developer Summit. Ubuntu 開發者大會。

UDS 是每半年一次的研討會,每次都會邀請各「上游」社群與 Ubuntu 開發團隊聚集在一起,討論下一版的主要開發目標並制定里程。而 UDS-P 的主要議題,自然是下一版 12.04 的 Precise Pangolin (嚴謹的穿山甲),12.04 也是 LTS 版本,支援期間長達五年。也因此 Mark Shuttleworth 也在開場 Keynote 的時候鼓勵與會者,在場的一言一行都會受到世界許多關注,在長達一週的會議中,所做的決定都會影響到許多使用者 (目前 Ubuntu 有超過兩百萬使用者),特別是偏好穩定系統的企業。

UDS 的形式有別於一般「研討會」,會場總共有 24 間會議室 (本次跟 Linaro Connect Q4.11 合辦),除了少數幾個全場演講是以簡報演講方式進行,剩餘大部分的議程是由註冊人帶領,幾位主要的開發者以圓桌方式坐在會議室中央,其他人可以隨意進入旁聽,並隨時插入相關議題或提問。像是 Multi-monitor Support 等熱門議題,太晚進會議室只好待在後面站著囉。

議題內容多元,從社群經營硬體核心基礎軟體雲端系統中國版本,甚至是發想性質的議題,像是讓 Ubuntu 支援手機、平板電腦與智慧電視裝置 等等。每個議題時間大約一個小時,各個來自世界各地的開發者,在大量咖啡因的作用下,進行節奏迅速的爭辯討論。由於並非每位開發者都可以現場出席會議,遠端開發者也可以透過即時語音廣播 (icecast) 與 IRC 加入討論。

costume party_831

一個小時的會議後,所有的討論會整理成藍圖 (blueprints),這些藍圖就是本次發行階段所需要開發的目標項目與負責人。在 UDS-P 中,有超過三百份藍圖。這些藍圖完全透明開放給所有人參考,也歡迎任何人介入制定。

許多開發者,即便是 Canonical 員工,有超過 70% 都是在家中工作,UDS 是難得的難得可以相互見面的機會。各個上游軟體專案的開發者,也會出席這次的會議,像是 Debian Project Leader Stefano ZacchiroliFreeRDP Marc-André Moreau 等等。他們增強了 Ubuntu 與上游專案進一步的合作關係。

令人印象深刻的是,整場會議中許多強者對於其他人的開放信任態度,記得在週四晚上的 Keysigning Party,我身旁一位 “神級” Debian Developer,誠懇對每一位交換簽章的人,說「沒問題,我相信你」,也許是因為大部份的人都抱持一樣的態度,使會議進行相當順暢而且充滿生產力的歡樂氣氛。

costume party_981

接下來還有力氣的話,我會再分享一些議程資訊。

照片: http://www.flickr.com/photos/37955218@N08/sets/72157627962230661/
訪問: http://akgraner.com/?p=1124
錄影: http://www.youtube.com/user/ubuntudevelopers#p/u

Ubuntu UDS P Orlando – Interview with Mark Shuttleworth

利益揭露: 筆者為 Canonical 員工。

養動物園或是管理伺服器的人,難免都會碰到一些硬碟故障的問題。這篇文章略為整理一些在 Linux 上處理壞軌硬體的一些軟體知識與技巧。針對讀者為中等程度以上的使用者,文中僅僅提供參考資料,不說明實際操作或指令明細,請自行參考相關文件。作者以最大善意盡力提供參考資訊,但文中如有疏漏或錯誤造成資料遺失,作者不負任何責任。

文中說明均以 Linux Extended file system 為主,操作平臺是 Debian GNU/Linux. 所提及工具授權均為 FLOSS 。假設錯誤硬碟為 /dev/sdb,所有指令需要以 root 執行。

章節結構

  • 錯誤類型。
  • 壞軌測試。
  • 預先偵測。
  • 備份與資料回復。
  • 排除壞軌磁區。
  • 送修與資料清除。

錯誤類型

這裡討論的硬碟資料損毀,不外乎物理性傷害,摔落、靜電、停電、過熱、原件老化等等。這些傷害會造成邏輯性 (logical error) 上或物理 (physical error) 性的錯誤。

所謂的邏輯性錯誤,就是硬碟離線時,暫存資料來不及寫入,導致資料錯誤異常。所幸大部分的檔案系統都會有一個檔案系統狀態 (Filesystem state) 的值,若是最後使用未順利完成卸載 (umount),下次掛載時就會提示要求作 fsck 檢查。如果是日誌式檔案系統ext3/ext4,則會試著回復未完成的操作。這種錯誤偶爾會破壞檔案,fsck/e2fsck 可能會將錯誤檔案移到 lost+found 目錄下,造成困擾,但問題不大。

物理性錯誤指的是硬體磁盤受到損壞,該段磁區無法讀取,也就是壞軌。肯定導致資料遺失,最常見的是系統吐出 I/O Error,無法讀取該檔案。實際的症狀是讀取變慢、聽到 Spin-up 時的卡卡聲(Clicking sound),甚至是系統當機等問題。

當壞軌開始產生時,通常代表硬碟壽命將至,得趕快開始更換健康新硬碟。這篇文章主要討論的是壞軌這種物理性錯誤的處理辦法。

壞軌測試

最基本的測試方法是利用 badblocks (8) 來檢測硬碟是否存在壞軌,這個指令不分檔案系統。若是含有重要資料的硬碟,應該先作預設的非破壞性唯讀測試 (non-destructive read-only test),以避免寫入測試時異常,造成磁碟重置離線。

badblocks -vs /dev/sdb

上述只要一發現壞軌,請第一時間拔下備份吧。若是可承受資料損失,可以使用 “-n” 的非破壞性寫入式測試。這基本上會嘗試寫入資料,再三確認硬碟運作正常。

badblocks -nvs /dev/sdb

預先偵測

不過 badblocks 需要在離線時才能執行。很多時候,伺服器是無法忍受長時間的離線檢查的,必須要能夠線上檢測硬碟健康狀況才行。目前市面所有 ATA 硬碟都已經支援 S.M.A.R.T. (Self-Monitoring, Analysis, and Reporting Technology),S.M.A.R.T.  基本上提供一個界面讓管理者可以查詢幾個重要的參數

透過讀取這些參數,管理者能夠預先警覺硬碟錯誤。根據 Google 的調查十萬顆硬碟後的研究報告 (Failure Trends in a Large Disk Drive Population),S.M.A.R.T. 的數值的確反應硬碟錯誤率 – 六十天內,出現 S.M.A.R.T. 掃描錯誤的硬碟是其他硬碟的 39 倍高。

在 Linux 上,可以使用 smartmontools 中的 smartctl (8) 來查詢硬碟的 S.M.A.R.T. 狀態。指令如下

smartctl --attributes /dev/sdb

根據 Google 的研究以及 Bad block HOWTO for smartmontools 指出,與硬碟失效關係最高的數值是 Reallocated Sectors Count/Reallocations event count, Current Pending Sector Count, Uncorrectable Sector Count。這幾組數據代表硬碟發現該磁區已經損毀,它會重新從備用磁區分配一位置取代該損壞磁區,或磁區已發現問題尚未替換或無法替換。這通常可以視為磁區損耗 (surface wear) 的狀況。當你發現這些值不為 0 時,就該開始準備備份資料並作壞軌檢查了。

除了使用 smartctl 手動檢測外,也可以設定 smarted,讓系統自動觀測 S.M.A.R.T. 狀態,有錯誤會顯示於桌面訊息或發送郵件。smartd 的設定可以參考 檢測硬碟狀態 – smartmontools 一文。S.M.A.R.T. 也支援 Self-Test,可以讓硬碟作效能與功能檢查,詳情請見 smartctl (8).

備份與資料回復

在發現壞軌之際,應該第一優先備份資料。如果還能夠掛起檔案系統,則趕緊利用 rsync, tar 等工具備份檔案。或者利用 dd 將整顆硬碟資料或分割區存檔,未來置換到新硬碟上

dd if=/dev/sdb of=sdb.img

若要確保資料正確複製,可使用 dcfldd 來複製,它會邊複製邊作 hash 確保資料複製正確。不過由於壞軌處常常無法讀取,這會造成 dd 執行失敗。此時可以改用 dd_rescue, 它可以略過無法讀取的部分,儘可能複製其他健康的資料。

不過天有不測風雲,人有旦夕禍福。萬一資料損壞的區域不是資料區域,而是存放重要的系統資訊,那就需要額外的處置。建議無論任何時候,都不要在壞硬碟上直接操作,永遠先備份,再於備份碟上進行處理。以下略談三種情境的可用工具

排除壞軌區域

通常如果你的硬碟還在保固範圍,一般原廠均會更換健康的硬碟給你。但如果硬碟已經超過保固,壞軌硬碟仍堪用,可以用來存一些低度重要的資料。

對於這些壞軌,可以用 sector slipping 或叫做 defect mapping 的機制來跳過不用。基本上分成兩種形式,一是透過硬碟控制器或是透過檔案系統的 bad block table 來記錄。

傳統的 (1990 年代中期以前的硬碟)是可以進行低階格式化 (Low-Level Formatting) 的,透過原廠的指令來重新定義物理儲存格式、重新定義 CHS、若是硬碟中有壞軌,可以在低階格式化時避開不用。

由於低階格式化常因為操作錯誤而損壞 (bricked) 硬碟,新款硬碟已經不提供使用者透過指令作低階格式化的工具。取而代之的是透過 hard-drive defect management 功能,以 Hard drive defects table – P & G Lists 來記錄 Bad Sector Mapping。所謂 Primary defect list 是代表出廠時已經產生缺陷的磁區列表,而 Grown defect list 則是使用中產生缺陷的磁區列表。

當硬碟發現壞軌時,便會自動將該磁區列入 G-List 中,並從備用的磁區中替換。因此現在已經沒有所謂低階格式化,目前所謂低階格式化大多指的是 Zero-filled,對磁區填入空值,強迫硬碟重新分配損壞磁區,這也是前述 S.M.A.R.T. 所謂 Reallocated Sectors。

所以你可以做的事情是對壞軌區域寫入空值,迫使它重置。你可以直接透過一開始的 badblocks 所產生之數值直接覆寫錯誤區塊,範例請見 Bad block HOWTO for smartmontools

上述 HOWTO 中詳述了,怎麼計算 e2fsck 吐出來數值,人工計算有點麻煩。以下介紹如何處理利用工具自動處理。

不保留資料

如果確認整顆硬碟資料都不需要保留,可以直接下達一下 dd 指令,重寫整顆硬碟。

dd if=/dev/zero of=/dev/sdb

或者在格式化時下達 -c -c 參數,讓 mkfs.ext3 順便檢查壞軌。

mkfs.ext3 -c -c /dev/sdb1

保留資料

如果硬碟已有資料,並想保留此資料,可以用 badblocks 檢查,並生成 badblocks list,再將 badblocks 吐出的列表,餵給 e2fsck -l.。但是必須確認執行 badblocks 時,指派了正確的 block size,可用 dumpe2fs -h 確認 block size.然後指示給 badblocks。

上述操作有點複雜,比較保險的做法是直接讓 e2fsck 用 badblocks 去作壞軌檢查,指令如下

e2fsck -k -c  -c /dev/sdb1

如此 e2fsck 會將壞軌寫入檔案系統列表中,可以用下述指令查詢目前壞軌列表

dumpe2fs -b /dev/sdb1

其他做法

本節前述可用低階格式化重置硬碟磁區分配,但是新款硬碟已少提供工具程式給終端使用者。有些工具透過反組譯硬碟韌體的方式取得 vendor specific ATA commands。另外,像是 Seagate 等品牌,則在硬碟上留有 TTLserial communication界面,於是你可以透過終端機連上硬碟韌體,以 Diagnostic Commands 進行一些偵錯以及重新格式化的動作。

送修與資料清除

爲了避免陳冠希裸照事件發生,送修前最好確保資料已經完全刪除。

就如前述所說,若只是進行快速格式化,硬碟資料也可能被回復。事實上,根據 Peter Gutmann 的在 90 年代的研究,他可以用磁力顯微鏡取得複寫過三十五次以上的磁區資料。而美國 National Institute of Standards and Technology 的研究 “Guidelines for Media Sanitization” Craig Wright, Dave Kleiman, Shyaam Sundhar R.S. 的論文 Overwriting Hard Drive Data: The Great Wiping Controversy 指出,新型硬碟只需要複寫一次即可。

爲了達到資料保密措施,各國軍方也因此設定有不同的資料清除 。總之,無論你的資料是否重要,在 Linux 上,建議使用這兩種 wipe, scrub 指令之一來抹除資料,這兩種工具支援上述的各國標準。你也可下載使用 DBAN 製作開機片來清除硬碟資料。

References

I should replace my key long time ago, after there are security flaws has been identified in SHA-1. The US NIST also suggested to transit to stronger SHA-2 hash functions.

I followed the key replacement rules of Debian and Apache and created the new key. If you have validated my old key, Here is my transition statement for the new new 4096 bit RSA key –

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1,SHA512


I am transitioning GPG keys from an old 1024-bit DSA key to a new
4096-bit RSA key. The old key will continue to be valid for some
time, but I prefer all new correspondence to be encrypted in the
new key, and will be making all signatures going forward with the
new key.

This transition document is signed with both keys to validate the
transition.

If you have signed my old key, I would appreciate signatures on my new
key as well, provided that your signing policy permits that without
reauthenticating me.

The old key, which I am transitional away from, is:

pub   1024D/DC76FEB9 2004-09-18 Rex Tsai 
 Primary key fingerprint: 1700 7040 CBD7 5DB4 4956  959B 3A5E 166D DC76 FEB9

The new key, to which I am transitioning, is:

pub   4096R/3860D2A5 2011-05-20 Rex Tsai (蔡志展) 
 Primary key fingerprint: CDC8 966D A547 6B1F CEB8  6D49 86A6 03D4 3860 D2A5

To fetch the full new key from a public key server using GnuPG, run:

  gpg --keyserver keys.gnupg.net --recv-key 3860D2A5

If you have already validated my old key, you can then validate that the
new key is signed by my old key:

  gpg --check-sigs 3860D2A5

If you are satisfied that you've got the right key, and the UIDs match
what you expect, I'd appreciate it if you would sign my new key.

If you then want to sign my new key, a simple and safe way to do that is
by using caff (shipped in Debian as part of the "signing-party" package)
as follows:

  caff 3860D2A5

In the other way, you can sign the key and send it to me as following 
commands:

gpg --sign-key 3860D2A5
gpg --armor --export 3860D2A5 | mail -s 'OpenPGP Signatures' \
        [email protected]
gpg --keyserver pgp.mit.edu --send-key 3860D2A5

Please contact me via e-mail at  if you have
any questions about this document or this transition.

Thanks.

Regards
Rex Tsai, 2011-05-21
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iEYEARECAAYFAk3WnNEACgkQOl4Wbdx2/rnujQCbBV+TSHWapsMrd5d06RKxkgT3
csUAnRpDr6obff4Fuj/P530f6pVT5WTXiQIcBAEBCgAGBQJN1pzRAAoJEIamA9Q4
YNKldvgP/2ej6EDhrGj/1dNkIdkWmKNXsj4OMWKcvDP6M+VnlkWtFaDQxYBb73Ea
vBhAgDZL7MhUwVbn9zydVInFpA9vtdsBwd6Hr3+rp+iv076TennKYP+qo7YDX5Ga
7s73Tim8Tn6AwYdBhyhFPJPZ/fEUknKNOWILu7eUjeQ+C7ndPNEe6VRvCJvJaHwa
aJ6b8kpeRG6UYQFGw/o2e0XGtEpek8dRiqk2sVnOVR/d0C6/u+2oQuGRVtX/uKd1
2E3HYPh/Y1RTqENYrCd39v8nA6NUzuw8kOpIx8MZ51iN4DB+YfusV8mtzhZIkVQP
y2BZ0jL2C2xFlCER7Cxlp8VpsKcz/tEixytciC0aOuoUoER7LQvfkQGs+pcTj8Fl
PQLmwgnqIM4PPQ4cSyhsFgmSkbFcDyxtStVLMEtJKKAJ0dOuqa13R0MKuRkg5WMP
u07EKBITk50QlqzXrJwM7I8FszIigbdWWQD2qNbXLpHcZNo5m5CshOVgTCy+t7E4
Z0gQ3DnZAsy+tclCjCeb6MdjRqF27C9LdWjNwHHcw71X2yqRXqEN8fb1JcXBSU5a
7AgiIMnDgw3BAm1QLQ/eEk8J7KuKvsFFK+hFpSs4mahYLUtExzSsEN7RbCQptSIc
4FfZUXS3bg+by4zF/2eSGI+FeMq7CIz4aX1JdfucBiFCNUCRhFPT
=kr5F
-----END PGP SIGNATURE-----