第 181 期 基於 KVM 與 libvirt 的虛擬化叢集系統-Debian 篇─自由軟體鑄造場電子報─智邦公益電子報
enews.url.com.tw · February 07,2012[技術專欄] 基於 KVM 與 libvirt 的虛擬化叢集系統-Debian 篇
魏藥/文
簡介
自由軟體鑄造場 (OSSF) 在台灣推廣自由軟體,長久以來持續提供「應用典範 (Web-hosting)」服務,供台灣知名或具有發展潛力的自由軟體相關組織申請與使用。隨著虛擬化技術的進步,應用典範也逐漸以 KVM 技術取代早期的 Xen 環境。在轉換的過程中,自由軟體鑄造場投入研究,致力於虛擬化的研究與運用,最終採用由 KVM 及 Red Hat 研發的 libvirt 與 virt-manager 管理模組,有效管理虛擬叢集系統。
前置作業
架設環境
- 作業主機- 一個或數個虛擬主機:每個主機皆要能支援 CPU 虛擬化技術,如 AMD 的 AMD-V 或是 Intel 的 VT-x。
- 一個或數個儲存伺服器:儲存空間愈大愈好,用以儲存資料,並建議實作 RAID 機制,以降低因硬碟損壞而造成資料遺失的風險。
- 遠端主控台:備留一台主機供安裝 virt-manager 管理模組,且該主機需支援桌面環境。
- 作業系統
- Debian Squeeze amd64 版本。
檢查 CPU 是否支援虛擬化技術
在 Debian 等 Linux 作業系統中,可於 /proc/cpuinfo 檢查 CPU 是否支援 vmx (Intel) 或是 svm (AMD) 虛擬化技術。請讀者進入 Debian 終端機後,輸入以下指令
egrep -c '(vmx|svm)' /proc/cpuinfo
若該指令輸出為 0,則代表不支援;反之,若為 1 以上,則代表主機支援 CPU 虛擬化技術。指令的結果也會顯示出主機上有多少 CPU 支援此技術。如果輸出為 0 ,讀者也別灰心,可以先進入主機的 BIOS 選項,檢查虛擬化技術的支援是否未開啟。
如果不會使用終端機,也可以依照主機 CPU 的型號來推斷是否具備虛擬技術,但這方法不一定精準。
如何於 BIOS 中啓用 CPU 虛擬化支援
▲ 圖1
進入主機 BIOS 選項後,如果 CPU 有支援,則可以在裡面找到啟動虛擬化技術的選項,如圖中白色文字處。
此外,有少數情況是 CPU 支援虛擬化技術,但主機板卻無法配合,如部分 VAIO 筆記型電腦。此時需要其他方式開啟,有興趣的讀者可自行上網查詢。
NFS 設定
在儲存伺服器上,可以使用最容易安裝與設定的 NFS,以供虛擬主機進行遠端存取。在安裝 Debian 作業系統時,除了留給作業系統的空間外,建議讀者預留額外存放虛擬機器映像檔的空間,或者分割出一個獨立的磁區。
為了方便管理使用者帳號,建議讀者安裝 NIS/YP 來統一管理。
1. 安裝 nfs-kernel-server,指令如下,
aptitude install nfs-kernel-server
2. 修改 /etc/exports 並加入分享的目錄。範例如下,讀者可依現行環境作變更,
/srv/nfs 192.168.1.0/24(rw,sync,no_subtree_check,no_root_squash)
3. 將預留給 NFS 掛載的磁區(如果有的話)掛載在 /srv/nfs 上面,並在 /srv/nfs 中建立一個名為 storage 的目錄。
4. 最後重新啟動 NFS,
/etc/init.d/nfs-kernel-server restart
若讀者需要作業系統的 ISO 映像檔,可以將各 ISO 映像檔放置於 /srv/nfs/storage,之後安裝虛擬機器的作業系統時可以直接從該目錄存取。
虛擬主機的安裝與設定
1. 安裝 openssh-server,aptitude install openssh-server
2. 安裝 libvirt-bin,
aptitude install libvirt-bin
3. 將使用者帳號加入 libvirt 群組以方便遠端控制,下列指令的 [username] 請變更為使用者的帳號。
gpasswd -a [username] libvirt
4. 設定 /etc/networking/interfaces,將該目錄下的 eth0 設定全部移除,並使用下列的內容。要特別注意的是,讀者需自行判斷網路卡的代號,本範例是 br0。
auto br0
iface br0 inet static
address 192.168.1.1 # 設定靜態 IP
netmask 255.255.255.0 6 # 設定 Netmask
gateway 192.168.1.254 # 設定 Gateway
bridge_ports eth0
bridge_stp on
bridge_maxwait 0
如果主機是透過 DHCP 自動設定網路,請改用以下內容,auto br0
iface br0 inet dhcp
bridge_ports eth0
bridge_stp on
bridge_maxwait 0
最後重新啓動電腦即可。
遠端控制主機安裝 virt-manager
1. 安裝 virt-manager,aptitude install virt-manager ssh-askpass-gnome
2. 使用 ssh-keygen,依其步驟製作公私鑰方便登入。
3. 將 ~/.ssh/id_rsa.pub 的內容複製到每一台虛擬主機的 ~/.ssh/authorized_hosts 中。若虛擬主機沒有該目錄或檔案,則請讀者自行建立,但該檔案的權限必須設定為 600。
4. 在 virt-manager(虛擬機器管理員)中新增剛安裝好的虛擬主機,
1. File → Add Connection,
▲ 圖2
2. Hypervisor 請選擇 QEMU/KVM;Connection 請選擇 Remote tunnel over SSH;Hostname 請輸入「使用者名稱@Address」,
▲ 圖3
3. 最後按下 Connect,即可建立完成。
5. 設定儲存池:
1. 點擊滑鼠右鍵 → Details,
▲ 圖4
2. 點選 Storage 標籤,
▲ 圖5
3. 點選左下角 [+] 圖示。
4. 輸入儲存池名稱,如果多台電腦共用一個儲存池,命名務必相同。
▲ 圖6
5. 依照之前的 IP 與 NFS 儲存路徑設定填寫儲存裝置的位置與名稱,最後按下 Finish。
▲ 圖7
建立虛擬主機
1. 對 host 點擊滑鼠右鍵 → New,▲ 圖8
2. 輸入虛擬機器的名稱,按下 Forward,
▲ 圖9
3. 選擇使用 ISO 映像檔。
1. 先按 Browse...。
▲ 圖10
2. 按下瀏覽,從先前建立的 storage pool 中選擇要安裝的作業系統映像檔。
▲ 圖11
3. 選擇要安裝的作業系統類型。
▲ 圖12
4. 按 Forward 繼續。
4. 設定分配虛擬機器使用的資源,再按 Forward 繼續。
▲ 圖13
5. 設定 Storage。
1. 點選 Select managed or other existing storage,之後點選 Browse...。
▲ 圖14
2. 點選先前已建立的 storage pool,再點選 New Volume 以建立一個新的映像檔。
▲ 圖15
3. 設定映像檔名稱之後調整大小,點選 Finish(格式使用 raw)。
▲ 圖16
4. 選擇剛剛建立的 volume 並按下 Choose Volume。
▲ 圖17
5. 按 Forward 繼續。
▲ 圖18
6. 設定網路。
1. 點開 Advanced options,將原本使用 NAT 的設定改成 Specify shared device name。
▲ 圖19
2. 將下面的 Bridge name 設定成網路卡的代號,本範例為 br0。
3. 按下 Finish 建立虛擬主機。
7. 虛擬主機將會在建立完成後自動重新啟動。
▲ 圖20
結語
QEMU/KVM 允許使用者執行多種作業系統,而且不像 Xen 需額外授權來放寬使用限制。此外,透過 libvirt 的圖形化介面操作也相當直覺。自由軟體鑄造場竭誠歡迎有興趣的讀者與我們聯絡交流。
作者簡介
魏藥,本名魏銘廷,目前是大學四年級學生。目前在自由軟體鑄造場擔任技術支援工讀生,也是一隻阿宅。最近在 Debian、Ubuntu 與 LXDE 等社群活動,做各式各樣的事情。個人網站:http://m-wei.net/
[源碼快訊] 一百年度自由軟體鑄造場作業暨智財權說明會(台北場時間異動)
OSSF/編述
自由軟體鑄造場 (OSSF) 每年都會針對申請自由軟體國科會專案補助計畫的主持人及學生開設說明會,內容包含示範專案進駐的操作方式、介紹版本控制系統、分享程式開發經驗、剖析自由軟體授權條款等,讓更多人對自由軟體的本質與實際的運用有更深入的了解。今年分別在台南與台北開設兩場說明會,其時間、議題如下:
100/09/19 (一) 9:00 - 12:00 台南 - 國立成功大學圖書館 B1 會議廳
講題(a) OSSF 服務介紹-講師:洪華超
講題(b) OpenFoundry 介紹(版本控制、待辦事項、規畫釋出)-講師:邱健雄
講題(c) 自由軟體授權分析-講師:林珈宏
100/09/23 (五) 9:00 - 12:00 台北 - 國立台灣科技大學國際大樓 1 樓 IB101
講題(a) OSSF 服務介紹-講師:陳瑞霖
講題(b) OpenFoundry 介紹(版本控制、待辦事項、規畫釋出)-講師:王家薰
講題(c) 自由軟體授權分析-講師:林誠夏
[源碼快訊] 十月份台灣自由軟體社群活動列表
OSSF電子報團隊/整理
十月份的活動列表出爐囉!各位有興趣參加活動的朋友記得先把時間預留下來唷。另外,由於活動列表出來的時間比較早,若後續有活動希望也能一起做宣傳的朋友們,記得來信:ossfepaper AT openfoundry.org。
2011 年 10 月活動
MozTW Lab @ TP(10/3)地點:台北市八德路一段 33 號 (HTC 八德專賣店二樓)
時間:19:30~22:00
活動資訊:https://groups.google.com/group/moztw-general
Moz.TW:http://moztw.org/
Rails Tuesday(10/4)
地點:台北市松江路 273 號(法其曼第咖啡)
時間:19:30~22:00
活動資訊:http://ruby.tw/post/5658520519/rails-tuesday
TOSSUG 社群聚會(10/4)
地點:台北市南昌路二段 200 號(Mix Coffee & Tea)
時間:18:30~22:00
活動資訊:http://www.tossug.org/
RGBA 網路設計師聚會(10/5)
地點:台北市松江路 273 號(法其曼第咖啡)
時間:19:30~22:00
活動資訊:http://rgba.tw/about
Hacking Thursday(10/6)
地點:台北市中山區南京西路 86 號(101 迎風城咖啡主題美食館)
時間:19:30~22:30
活動資訊:http://www.hackingthursday.org/
台灣維基人臺北定期聚會(10/7)
地點:台北市松山區民生東路三段 140 巷 11 號(果子咖啡)
時間:18:00~20:00
活動資訊:http://zh.wikipedia.org/wiki/Wikipedia:WPTP-Social
SA@Tainan 淺談自由軟體授權及產業利用模式(10/8)
地點:台南市永康區大灣路949號(崑山科技大學 資訊科技學院 I5401教室)
時間:14:00~17:00
活動資訊:http://samc.study-area.org/registry/add/97
Taipei Wikipedian Moonthly Meetup: Writing Day 維基台北定期聚—假日寫作月聚(10/8)
地點:台北市大安區泰順街 60 巷 11 號 (小哲咖啡)
時間:14:00~16:00
活動資訊:http://zh.wikipedia.org/zh-tw/WP:WPTP-W
MozTW Lab @ TP(10/10)
地點:台北市八德路一段 33 號 (HTC 八德專賣店二樓)
時間:19:30~22:00
活動資訊:https://groups.google.com/group/moztw-general
Moz.TW:http://moztw.org/
Rails Tuesday(10/11)
地點:台北市松江路 273 號(法其曼第咖啡)
時間:19:30~22:00
活動資訊:http://ruby.tw/post/5658520519/rails-tuesday
TOSSUG 社群聚會(10/11)
地點:台北市南昌路二段 200 號(Mix Coffee & Tea)
時間:18:30~22:00
活動資訊:http://www.tossug.org/
RGBA 網路設計師聚會(10/12)
地點:台北市松江路 273 號(法其曼第咖啡)
時間:19:30~22:00
活動資訊:http://rgba.tw/about
Taipei GTUG (GAE Study Group Bootcamp)(10/12)
地點:台北市中山區民生東路三段 140 巷 11 號(果子咖啡)
時間:19:30-22:30
活動資訊:http://www.taipei-gtug.org/
Hacking Thursday(10/13)
地點:台北市中山區南京西路 86 號(101 迎風城咖啡主題美食館)
時間:19:30~22:30
活動資訊:http://www.hackingthursday.org/
Let's WordPress In Tainan!(10/15)
地點:台南市南區西門路一段 655 號 8 樓(德鍵數位創意設計中心)
時間:13:30~16:00
活動資訊:http://design.derjian.com.tw/wp-content/uploads/edm/event/event001/event001.html
MozTW Lab @ TP(10/17)
地點:台北市八德路一段 33 號 (HTC 八德專賣店二樓)
時間:19:30~22:00
活動資訊:https://groups.google.com/group/moztw-general
Moz.TW:http://moztw.org/
Rails Tuesday(10/18)
地點:台北市松江路 273 號(法其曼第咖啡)
時間:19:30~22:00
活動資訊:http://ruby.tw/post/5658520519/rails-tuesday
TOSSUG 社群聚會(10/18)
地點:台北市南昌路二段 200 號(Mix Coffee & Tea)
時間:18:30~22:00
活動資訊:http://www.tossug.org/
RGBA 網路設計師聚會(10/19)
地點:台北市松江路 273 號(法其曼第咖啡)
時間:19:30~22:00
活動資訊:http://rgba.tw/about
WoFOSS 好自由小組聚會(10/19)
地點:伯朗咖啡-北科大店(台北市忠孝東路三段 52 號 1 樓)
時間:19:00~22:00
活動資訊:http://wofoss.blogspot.com/2011/08/wofoss-921.html
Hacking Thursday(10/20)
地點:台北市中山區南京西路 86 號(101 迎風城咖啡主題美食館)
時間:19:30~22:30
活動資訊:http://www.hackingthursday.org/
台灣維基人臺北定期聚會(10/21)
地點:台北市松山區民生東路三段 140 巷 11 號(果子咖啡)
時間:18:00~20:00
活動資訊:http://zh.wikipedia.org/wiki/Wikipedia:WPTP-Social
MozTW Lab @ TP(10/24)
地點:台北市八德路一段 33 號 (HTC 八德專賣店二樓)
時間:19:30~22:00
活動資訊:https://groups.google.com/group/moztw-general
Moz.TW:http://moztw.org/
Rails Tuesday(10/25)
地點:台北市松江路 273 號(法其曼第咖啡)
時間:19:30~22:00
活動資訊:http://ruby.tw/post/5658520519/rails-tuesday
TOSSUG 社群聚會(10/25)
地點:台北市南昌路二段 200 號(Mix Coffee & Tea)
時間:18:30~22:00
活動資訊:http://www.tossug.org/
RGBA 網路設計師聚會(10/26)
地點:台北市松江路 273 號(法其曼第咖啡)
時間:19:30~22:00
活動資訊:http://rgba.tw/about
Taipei GTUG (GAE Study Group Bootcamp)(10/26)
地點:台北市中山區民生東路三段 140 巷 11 號(果子咖啡)
時間:19:30-22:30
活動資訊:http://www.taipei-gtug.org/
Hacking Thursday(10/27)
地點:台北市中山區南京西路 86 號(101 迎風城咖啡主題美食館)
時間:19:30~22:30
活動資訊:http://www.hackingthursday.org/
臺灣維基人秋聚(10/29)
地點:台南-國立成功大學
時間:整天,詳細時間待確認
活動資訊:待確認
MozTW Lab @ TP(10/31)
地點:台北市八德路一段 33 號 (HTC 八德專賣店二樓)
時間:19:30~22:00
活動資訊:https://groups.google.com/group/moztw-general
Moz.TW:http://moztw.org/
[源碼快訊] 自由軟體鑄造場將在 100 年度「台北國際發明暨技術交易展」參展 歡迎蒞臨參觀
OSSF/編述
本年度將於 9/29~10/2 舉辦的「台北國際發明暨技術交易展」開放一般民眾免費入場參觀(註一),自由軟體鑄造場 (Open Source Software Foundry, OSSF) 亦將利用此次活動,於國科會科技創新館擺設攤位,以協助國內對自由開源軟體開發有興趣的朋友,能夠面對面地了解並試用 OpenFoundry 專案開發平台,以及讓專人為您現場展示以及解說,鑄造場各項協助國人發展自由開源軟體專案的相關服務與工具,例如:自由軟體技術教學工作坊的申請與協辦、自由軟體技術移轉與授權諮詢服務,以及本年度深具應用突破性的最新元件,能輔助程式開發者在離線單機狀態下也能管理開發專案的 OpenFoundry 子計畫–VMFoundry。
VMFoundry 包括以下子系統:
1. 版本控制系統
2. 問題回報系統
3. 規劃釋出系統
對於程式開發者來說,分別獨立架設上面的系統及網站內容的撰寫是相當容易的,但如何把不同功能的元件統合在一個專案做綜合的展現,則就是一門高深的學問了。目前網路上有許多專案管理平台已經整合版本控制系統、問題回報系統、版本規劃釋出及共同協做平台等子系統,但開發者如果要自行整合這些系統,過程勢必需要耗費許多心力在整合與調校工作上,但現在有了 OSSF 釋出的 VMFoundry(註二)這個利器,您將可以快速取用它來進行試用、評比,以及專案的離線開發,待專案成熟度己達到一定水準,再視狀況將其商品化或是上傳至線上平台成為更多人能夠共工開發的開源專案!
只要您在活動期間蒞臨鑄造場的活動攤位,將可以當場試用 VMFoundry 以體驗它的輕簡操作與快速安裝,鑄造場亦會同時就 OpenFoundry 平台的線上操作進行實機展示,並由營運與法政同仁,為您介紹自由軟體技術教學工作坊的申請與協辦流程,以及自由軟體技術移轉與授權諮詢方面的各項服務。活動內容豐富有趣,歡迎大家熱烈參與。亦歡迎自由軟體鑄造場電子報的讀者們,能撥冗至鑄造場所設置的攤位前,與本計畫各個輪班的同仁們談天敘舊,或是您對於自由軟體研究應用方面有任何合作推展的想法,亦可透過 「台北國際發明暨技術交易展」這個場合與我們當場磋商研議!
◎ 活動時間:2011 年 9 月 29 日至 10 月 2 日
◎ 活動網頁:http://www.inventaipei.com.tw/zh_TW/index.html
◎ 活動地點:台北世界貿易中心展覽一館
註一:免費入場方式的說明頁面:http://www.inventaipei.com.tw/zh_TW/show/info.html?id=51DB5997EE243674D0636733C6861689
註二:催生出 VMFoundry 子計畫的原因,是由於過去 OSSF 要移植新的專案管理平台到不同單位時,需要就不同單位的硬體狀態來進行耗時費力的調校,這樣的狀況造成移植 OpenFoundry 平台予其他單位試用的門檻過高。而有鑑於此、OpenFoundry 團隊研擬了一個替代性的解決方案,那就是透過虛擬化技術將 OpenFoundry 專案管理平台安裝在虛擬硬碟上,再透過虛擬主機執行。如此讓移植 OpenFoundry 專案管理平台的工作,能有一個只需要點選幾個按鈕及輸入幾項命令即能操作完成的選擇。如此一來,使用者可以輕易試用到 OpenFoundry 強大的功能,也由於此種作法是將 OpenFoundry 安裝在虛擬機器上,因此這套架設在虛擬機器上的專案管理平台,即順理成章地被命名為 VMFoundry。
[源碼新聞] 各領域自由軟體愛好者的交匯處-ICOS 2011
李婉婷/採訪
開放源碼國際研討會(International Conference on Open Source 簡稱:ICOS)是台灣年度大型開放源碼研討會之一,近年由中華民國軟體自由協會 (SLAT) 舉辦。ICOS 2011 於 9/9~9/11 假國立台灣大學共同教學館舉辦為期三天的研討會。議程除了開放源碼研討會必備的技術議題外,還有開放源碼在教育上以及社會領域方面的應用與所產生的議題探討,也請來自由軟體社群分享其開發經驗。多種類的議題安排以及不同形式的討論會議,讓與會者互相交流意見與心得,提供官、產、學、研、技術、NPO 與使用者一個良好的溝通平台。今年特別在第三天的議程中,增加了多場二十分鐘的演講主題,讓每個想要分享自己成果的朋友們,都能詳盡的介紹自己的作品。
ICOS 在社會應用方面,請到了長期關注資訊社會議題、專門研究災難科技與災難社會研究的李士傑 (Ilya),與大家分享他自己多年來參與非營利組織工作所觀察到的趨勢轉變,以及如何利用資訊科技去解決社會運動所面臨的難題。並列舉一些例子,像是人權團體 Benetech 基金會的 Martus 計劃;由斯里蘭卡發起,於 2004 年南亞海嘯發揮功效的災難資訊協調管理系統-Sahana。李士傑也現場示範如何使用 Sigmah 這套適合用於非營利組織監測事項進度的工作管理系統,Sigmah 不僅具有內部資料庫集中管理的功用,還能讓組織與組織之間的合作,更能有系統的管理。
而有關自由軟體運用於社會方面的議程還有「地理資訊系統 GIS」,請到專門研究開放地理資訊的鄧東波、劉俊宏、劉濠雄,分別介紹地理資訊開放源碼基金會 (OSGeo) 的現況與發展、OpenStreetMap (OSM) 這個共同編輯世界地圖的開源專案、Quantum GIS (QGIS) 與國土資訊系統資料倉儲及網路服務平台的結合應用。
另外,在教育面向的議題中,安排多位中小學老師分享個人自由軟體使用的經驗作為教材的內容,這部份邀請到教育部數位教學資源交換分享計畫的專案經理葉青燕,介紹專門蒐集審核教材的開放教育資源網站,並與台下的聽眾們一起討論教材分享與再利用的具體作法。除此之外也邀請中央研究院的台灣創用CC 計畫的專案經理周文茵,一同分享創用CC 授權的概念與其在使用上所涵蓋的範圍。
社群參與在自由軟體領域中,也扮演頗重要的角色,ICOS 也邀請到一些社群朋友,共同分享參與活動的心得與成果。於近期內備受關注的台灣女子自由軟體工作小組 (WoFOSS) ,也在此次的 ICOS 中和與會者一同分享女性在資訊系所(學校)、職場(工作)、活動(社群)的經驗,希望能帶領大家一同思考資訊領域中所存在的性別問題,這也是 WoFOSS 首次在大型研討會中與大家見面,並將其理念與現場的會眾們分享,意義非凡。而 EzGo 社群也在這次研討會中展示 EzGo 9 這套適用於台灣教育界和 Linux 新手的作業系統平台的各項特色,EzGo 社群主要由資訊科系相關的學生與中小學老師組成,在本次的成果展示中也見證了年輕學子無限的創意與潛能。
ICOS 主辦單位除了堅持議程的多元性外,也適時的加入一些創新且有趣的作法。每年的 ICOS 都會嘗試加入不同形式的活動,促進各方人士的互動與交流。舉例來說,去年「世界咖啡館」的討論模式受到大家的喜愛,今年進而延伸出「ICOS 花園」這個交流活動。
開放、自由、與注重多元性的精神,一直以來都是自由軟體愛好者們心中所認同的價值。在 ICOS 會場上,可以跟不同學校的老師或是同學、非營利組織、公司企業等不同領域的自由軟體使用者談話;也可以跟開發、推廣自由軟體的學術研究人員、政府單位溝通對談;更可以與軟體的技術人員、開發單位互相交流。ICOS 承襲著歷年來的慣例,提供豐富多元的講場、暢通各方與會者之間的溝通管道,擔任多功能平台的角色,使台灣自由軟體在開發與應用兩方面同時邁向成熟之路。
[技術專欄] 利用 FreeNAS 打造儲存設備(4)─安裝篇(由 GUI 升級)
Weithenn ( http://www.weithenn.org/ )/文
前言
前篇文章 FreeNAS (3) 升級篇中,說明如何從官方網站下載映像檔以升級 FreeNAS 系統的教學。本文將介紹另一種 FreeNAS 版本升級方式,在 FreeNAS 官網下載升級用的 GUI_upgrade.xz 韌體檔案(本例為 FreeNAS-8.0.1-BETA4-i386-GUI_Upgrade.xz,下載後不需解壓縮),並登入 FreeNAS 圖形管理介面以上傳 GUI_upgrade.xz 來進行升級。升級過程中,FreeNAS 會使用 SHA 256 雜湊演算法進行檔案驗證,所以需要提供 GUI_upgrade.xz 檔案的 SHA 256 雜湊值以通過驗證程序,而雜湊數值可由相對應的 Release Note 文件中取得。
在開始前有幾件事情需要注意:
本篇的升級方式不支援由舊版 FreeNAS 0.7 升級至新版 FreeNAS 8.0。
系統的 USB 或硬碟至少需有 2GB 的以上的閒置空間,因為檔案系統架構已經改為 2 個 1GB 分割區。升級前請先備份設定檔其相關資料。升級後必須重新啟動 FreeNAS 主機,以進行更新程序。
系統環境:
目標為 FreeNAS 版本 (i386):FreeNAS-8.0.1-BETA3
升級為 FreeNAS 版本 (i386):FreeNAS-8.0.1-BETA4
韌體檔案:FreeNAS-8.0.1-BETA4-i386-GUI_Upgrade.xz
SHA256:aa2b8d689df8c72bff0f12b0cb1b694219c2874713dadb916db151c3aa9d5540
圖形介面升級步驟
建立分割區(上傳韌體檔案暫存區)
FreeNAS 採用嵌入式的設計,因此安裝作業系統的目的磁碟或 USB/CF 儲存裝置的空間不能儲存資料,所以上傳韌體檔案必須事先建立分割區。首先,登入 FreeNAS 管理介面,並切換至【Storage】項目後選【Volumes】子項目,接著選【Create Volume】項目。此時彈出建立掛載點的視窗,相關說明如下:
Volume name:輸入該掛載點的名稱,在本例為 mydata (/mnt/mydata)。
Member disks:選擇 FreeNAS 主機的硬碟,在本例為 20GB (da1)。
Filesystem type:選擇檔案系統種類,在本例為 ZFS。
Force 4096 bytes sector size:ZFS 檔案系統的特性,視需要自行勾選,本例為勾選。
再次確定輸入名稱、選擇的磁區及檔案系統種類後,按下【Add Volume】鈕,即可新增掛載點。Add Volume 鍵會顯示紅色警示,提示所選擇硬碟的資料將完全清除。
▲ 圖1:建立 ZFS 檔案系統的掛載點
▲ 圖2:ZFS 檔案系統資訊
依照歷史篇中 FreeNAS 的官方建議,若系統為 32 位元版本,建立檔案系統時應建立 UFS 以取得較佳的效能,但為何此次採用 32 位元版本卻又建立 ZFS 呢?因為 8.0.1 BETA3 版本於建立 UFS 分割區時會出現錯誤(在 8.0 Release 版本則無此錯誤)如圖3 所示,因此本次實作選擇建立 ZFS 掛載點。不過這個問題未來將會修復,畢竟目前還是 BETA 版本。
▲ 圖3:在 FreeNAS 8.0.1 BETA3 建立 UFS 檔案,系統發生錯誤
開啟記錄檔即時顯示功能
讀者在操作介面上選【System】項目後選【Settings】頁籤,接著在【Advanced】子項目中,選擇「Show console messages in the footer (Requires UI reload)」,最後按下〔OK〕即可。此時可以重新整理瀏覽器畫面 (Ctrl + F5),如圖5 所示,會發現圖形介面下方出現三行記錄檔內容,讀者也可將滑鼠游標移到訊息區塊並點選左鍵,就能夠進一步看到詳細訊息。
若在升級過程中觀察系統訊息 (/var/log/message),會發現圖形化升級會切換至路徑「/usr/local/www/freenasUI」並執行「python manage.py migrate」指令。
▲ 圖4:開啟 FreeNAS 即時顯示記錄檔訊息功能
▲ 圖5:管理介面顯示記錄檔訊息畫面
▲ 圖6:記錄檔區塊詳細訊息
選擇上傳韌體檔案暫存區
確認前一步驟已完成上傳新版韌體,接下來請選【System】後選【Settings】頁籤,接著進入【Firmware Update】子項目。由於先前只建立一個掛載點,因此韌體檔案會指定在先前建立的 /mnt/mydata。如果先前建立多個掛載點,則可以透過下拉選單功能進行選擇。最後按下〔OK〕後進入下個階段。
▲ 圖7:選擇韌體檔案掛載點
▲ 圖8:韌體檔案升級前的系統訊息
選擇韌體檔案並填入 SHA256 雜湊值
按下【瀏覽】鍵後,選擇先前從 FreeNAS 官網下載的 FreeNAS-8.0.1-BETA4-i386-GUI_Upgrade.xz 韌體檔案,並在「SHA256 sum for the image:」欄位填上對應的 SHA-256 雜湊值。本例為 「aa2b8d689df8c72bff0f12b0cb1b694219c2874713dadb916db151c3aa9d5540」。SHA-256 雜湊值可於該版本的 ReleaseNotes 檔案中找到,如本例於 ReleaseNotes-8.0.1-BETA4.txt ( http://sourceforge.net/projects/freenas/files/FreeNAS-8.0.1/ReleaseNotes-8.0.1-BETA4.txt/download )。按下〔OK〕鍵後,系統開始執行版本升級作業,當升級作業完成後會自動重啟 FreeNAS 主機以進行升級。
完成後我們登入 FreeNAS 管理介面,選【System】項目後選擇【System Information】,可確認版本是否升級成功。
▲ 圖9:選擇韌體檔案與填入 SHA256 雜湊值
▲ 圖10:升級時顯示的系統訊息
▲ 圖11:升級完成後的畫面
待續
本文介紹另一種升級方式,讀者可依據需求選擇更新 FreeNAS 的方式。下一篇文章將介紹如何將 FreeNAS 安裝到 USB/CF 儲存裝置上。[源碼專案] 開放源碼的網路弱點掃描工具-Nikto
曾義峰/文
Nikto 是一款開放源碼的 Web 掃描工具,可進行全面的 Web 伺服器多個項目測試,包括 3500 個潛在危險的文件 /CGI 檢測,搜集了超過 900 個有問題的伺服器版本以及 250 個特定的問題。掃描項目和外掛經常更新,且本程式亦支援自動更新。本專案的訴求並非設計出一款隱蔽工具,而是盡可能在短時間內測試 Web 伺服器的安全問題。
本專案使用 Perl 程式語言撰寫,並提供方便擴充的介面,於 Windows/Linux/BSD 下皆可執行。
* 官方網站:http://www.cirt.net/nikto2
* 軟體授權:GNU General Public License v2(註1)
安裝說明
1. Ubuntu/Debian (Linux)
由於常見的 Linux distribution 都會預先安裝 Perl 程式語言,所以在使用上僅需安裝 Nikto。在命令列模式輸入下列指令即可安裝完成。
# sudo apt-get install nikto
安裝完成後,可以在命令列模式下輸入 nikto 以檢查是否安裝成功。
# nikto
2. Windows
Perl 並不是 Windows 內建的程式語言,需要自行安裝。Perl 的官方網站(註2)提供 Windows 平台的使用者 Strawberry Perl 及 ActiveState Perl 兩種選擇。
▲ 圖1
在本分享中,筆者安裝的是 Strawberry Perl。可以在其官方網站上下載,如圖:
▲ 圖2
下載完成後開始安裝,如圖:
▲ 圖3
只要照著安裝步驟即可順利安裝完成。預設會將 Perl 安裝在 C:\strawberry 目錄下,並且將 Perl 環境設定完成,如 PATH 等環境變數,方便使用者可以馬上使用。
接下來只需在 Nikto 官方網站上下載最新版本(目前是 2.1.4 版),並將檔案解壓縮至系統中即可,例如筆者將 Nikto 解壓縮至 C:\nikto-2.1.4。
▲ 圖4
此時要記得修改 Nikto 安裝目錄下的 nikto.conf 設定檔,否則 Nikto 不會正常運作。
▲ 圖5
由於 nikto.conf 使用 UNIX 檔案格式,所以請使用 UltraEdit 或其它可正常顯示的編輯器開啟,否則會出現類似亂序的排版情形。若沒有安裝其它編輯器,預設的 Windows 環境中可以使用 WordPad 來編輯。
▲ 圖6
用 WordPad 開啟後,在 nikto.conf 的最後幾行內容中,可以發現 EXECDIR 的設定,如圖7。
▲ 圖7
請把該行改成 "EXECDIR=C:\nikto-2.1.4"。儲存後離開。
▲ 圖8
安裝完成後,可以到命令列模式下,如圖9。
▲ 圖9
進入命令列模式後,切換至 Nikto 解壓縮的路徑,例如本例是在 C:\nikto-2.1.4。
▲ 圖10
輸入下列指令,檢查是否已經成功安裝。
▲ 圖11
常用指令
1. 指定掃描的主機預設會掃描 Port 80。
# perl nikto.pl -h 192.168.0.1
當然也可以指定,例如 Port 8080。
# perl nikto.pl -h 192.168.0.1 -p 8080
亦可單次掃描多個端口。
# perl nikto.pl -h 192.168.0.1 -p 80,443,8080
2. 當本機使用代理伺服器時
若本機的環境是使用代理伺服器 (proxy),則必須指定伺服器的位址。例如代理伺服器為 http://192.168.0.254:3128/。
# perl nikto.pl -h 192.168.0.1 -useproxy http://192.168.0.254:3128/
3. 使用 IDS 的躲避技術
Nikto 可以使用 IDS 的躲避技術來進行更高階的偵測行動,目前支援以下類型:
1. 隨機 URL 編碼。
2. 自訂選擇路徑(如 /../)。
3. 假的網頁請求結束。
4. 過長的 URL 請求。
5. 參數隱藏技術。
6. 使用 TAB 作為請求的分隔符號。
7. 大小寫敏感偵測。
8. 使用 Windows 預設的分隔符號 (\)。
9. 會話 (session) 重組。
因此,如果想要用到「3. 假的網頁請求結束」,則:
# perl nikto.pl -h 192.168.0.1 -evasion 3
4. 報告輸出格式
Nikto 內建多款報告的輸出格式,支援 HTML、XML、CVS,甚至可以直接產生匯給 metasploit 的格式。如果想要匯出 HTML 格式,則:
# perl nikto.pl -h 192.168.0.1 -Format html -o output.html
其實 Nikto 支援自動判斷副檔名來選擇適當的格式,例如輸出檔名為 output.html 時,則 Format 會採用 HTML;若輸出檔名為 output.xml 時,則 Format 會採用 XML。因此前述指令可以用下列指令取代:
# perl nikto.pl -h 192.168.0.1 -o output.html
5. 掃描模組的更新
Nikto 支援掃描模組的更新,方便使用者定期同步更新至最新的模組。更新的方式,只要執行下列指令即可:
# perl nikto.pl -update
結論
Nikto 除了本篇介紹的幾種方式外,還支援許多特性,有興趣的讀者不妨到 Nikto 的官方網站上搜尋。雖然 Nikto 的功能並不如許多商業軟體強大,但已足以應付常見的問題,再加上 Nikto 小巧可攜帶的特色,其實是個方便隨時隨地使用的小工具。
補充
如果在 Windows 下執行 Nikto 發生下圖的錯誤訊息,請檢查是否已正確修改 nikto.conf 中的 EXECDIR 路徑,並確認該路徑是 nikto 解壓縮的目錄。▲ 圖12
註解
1. 授權條款英文全文:http://www.gnu.org/licenses/old-licenses/gpl-2.0.html
2. Perl 官方網址:http://www.perl.org/get.html
3. Strawberry Perl:http://strawberryperl.com/
[法律專欄] GPL 條款對於衍生程式的判定標準與其授權拘束性的擴散範圍(上)
林誠夏/文
GPL 類別的授權程式,最為人著稱的特性便是其「牽一髮而動全身」的授權拘束性(License Inheritance,註一)。所謂的「授權拘束性」白話來說,指的是當使用者將 GPL 授權的程式碼抄寫到自己的軟體專案時,如果抄寫程度佔專案程式碼的比例很大,或是此一 GPL 授權元件提供了專案的核心功能,並且專案的其他元件在互動上亦無法與其分割,則整個軟體專案便會一體被視為該 GPL 授權元件的衍生著作,嗣後使用者如果再行散布這個軟體專案,便僅能適用 GPL 的授權方式來進行釋出。而由於近年來自由軟體元件被產業化利用的比率愈見頻繁,因此授權拘束性所帶來的爭議也愈來愈受到重視,本文便是針對這個議題,先依著作權法的預設說明、再照 GPL 授權條款的文意解釋,接著舉 Linux Kernel 的實際運作狀況佐證,一步步抽絲剝繭的分析 GPL 授權程式在衍生程式方面的判定標準,及此標準在軟體元件的連接關係 (linking) 上,所可能擴散的拘束性範圍。
預先取得原作者同意是合法改作的前提
依我國著作權法第 28 條的規定:「著作人專有將其著作改作成衍生著作或編輯成編輯著作之權利。」所以、若是軟體元件並非自己從無到有重新撰寫,而是取用他人既有的成果來加以改寫與利用,就必須先取得該元件原始權利人的預先同意才可以進行。類似的規則在美國法是規定在其著作權法第 101 條 17 項 1 款(註二),其述明新作品是基於原作品而另行改作者皆為衍生著作 (A “derivative work” is a work based upon one or more preexisting works.),然而、在軟體著作這個領域裡,何謂「基於原作品另行改作 (work based on the original work)」的定義與範圍向來有難以清楚界定的難處,這是因為在一個中型、大型的軟體專案裡,各元件彼此間,常常是以互相呼叫、互相存取的方式來協同運作,而不同元件程式碼在撰寫上,也並不一定是各作者基於共同創作的共識下去協力開發的,所以、若非在個案裡就不同元件的「互動與依存關係」來做判定,否則、很難直觀的去辨別各元件間是否真的存有「前後接力、彼此依賴」的緊密連結關係,而可以將整個軟體專案論為哪一個特定元件的衍生著作。
GPL 擴張了衍生程式的抽象定義與解釋範圍
由於自由開源軟體皆容許後手得以自行「研究、修改、重製、再散布」該程式,所以自由軟體元件的原始著作權人,都已經將這個「容許改作的同意」預先授權給得到程式的後手了,不論是 BSD、MIT、MPL、CDDL,或是 GPL 類別的授權元件都是如此,然而、這些自由開源軟體的授權條款,其在預先釋出程式改作權的同時,也會要求收受程式的後手,必須以遵守條款其他義務性要求 (obligation) 來作為得到授權的交換條件!而 GPL 類別的授權元件,其最為人熟知與影響最為深遠的義務性要求,便是如果新的軟體專案內含 GPL 授權元件的程式碼,那原則上就是整個專案 (as a whole) 會被認定為 GPL 授權元件的衍生程式,從而這個軟體專案再釋出時,便必須依照 GPL 條款的各項授權規定,以提供後手程式原始碼的方式來進行散布。GPL 授權條款這樣的要求相較於著作權法的預設,是大為擴張了法律原本對於衍生程式的抽象定義與解釋範圍,然而、以授權條款或是契約約定去補充法律規定之不足處,本就是私法行為下契約自由主義所容許的作為。但是、為了避免這樣的擴張機制引發過大的爭議與產生避用 GPL 授權元件的迴避效應,GPL 授權條款也明文表達了一個授權拘束性的例外規定,那就是、具有「獨立性與可區分性(Separate and Independent,註三)」的軟體元件,並不會因為僅與 GPL 授權元件同在一個軟體專案的架構下運作,就被歸類為 GPL 授權元件的衍生著作。所以、若是符合「Separate and Independent」這樣的例外規定,此時軟體專案便可以被認定為一個統合的聚合作品 (aggregation),此時散布整個聚合的軟體專案時,就只需要提供該 GPL 授權元件的程式原始碼,而不一定要將 GPL 的授權拘束性及於其他自行編寫且獨立運作的個別元件。那麼、接下來的問題就是,所謂的「獨立性與可區分性」,是不是已經有一個公定標準,或是多數 GPL 授權元件的開發者皆已得到共識的參考範圍?
Linus Torvalds 認為運作上的依賴性才是衍生關係的最大特徵
「獨立性與可區分性」的判斷目前並沒有司法判決上統一的公定標準,但是若干的 GPL 著名元件的開發社群,確實有藉由不間斷討論與辯駁的過程,漸漸凝聚共識與統一說法的態勢。舉目前影響力最大的自由開源軟體專案 Linux Kernel 為例,其原始創作人與精神領袖 Linus Torvalds 也曾就這個議題,於 2001 年至 2004 年間,在網路信件往返的討論串裡給過若干的評論與建議(註四),簡要來說、這段評論內容的重點可以歸納為以下三點:
- 以 GPL-2.0 授權條款釋出的 Linux Kernel 確實具有授權拘束性,其他基於 Linux Kernel 所撰寫出來的衍生程式,不論其為驅動程式 (driver) 或是 Kernel 的修補程式 (patch) 皆無例外。
- 其他開發者為 Linux Kernel 所撰寫的 Kernel 模組 (Kernel Module) 以及修補程式,其著作權利歸屬於個別的創作者,然若是因為運作上的高度依賴性特徵,而被認定為 Linux Kernel 的衍生程式,則再釋出時便必須依照 GPL-2.0 的遊戲規則來進行散布。
- Linus Torvalds 舉長篇小說來做比喻,若讀者需要讀完上篇才能看懂中篇,看完上篇、中篇才能看懂下篇,那麼中篇與下篇皆為前篇的衍生著作;而相若於此、假設某個特定元件是針對 Linux Kernel 進行撰寫,並且不依附於 Linux Kernel 之上便全無運作的功用,那麼該元件便不具單獨存立 (stand-alone) 的獨立性,從而也就必須被歸類為 Linux Kernel 的衍生程式,而併以 GPL-2.0 提供程式原始碼的授權方式向後散布。
其後 Linus Torvalds 更將他這樣的授權態度編寫進 Linux Kernel 的說明檔案裡(註五)成為正式的聲明。依著這份聲明,Linus Torvalds 認為其他軟體元件透過一般 system call 的方式來呼叫 Linux Kernel 的功能,並不會讓這個元件直接被定義為 Linux Kernel 的衍生程式,因為這樣的互動方式僅是透過一個既成的介面 (interface) 來與 Linux Kernel 產生交流,因此僅是一種單純利用 (use the program) Linux Kernel 功能的互動方式,而不代表此元件與 Linux Kernel 之間具有「不可分割運作的衍生關係」。自此之後、許多軟體社群的成員認為其他元件與 GPL 授權元件的互動關係原則上有兩種,一種是基於 GPL 程式改作 (work based on the program) 的衍生關係,此時 GPL 授權程式的授權拘束性會擴散至衍生程式;另一種是其他元件單純利用 (work using the program) GPL 程式進行功能展現的獨立關係,而若是判定是獨立關係的話,則 GPL 授權程式的授權拘束性不會擴散到這些獨立元件,從而這些獨立元件在與 GPL 授權程式合併散布時,僅需要提供與 GPL 程式產生互動關係時的呼叫程序與安裝步驟方面的資訊,而不需要提供此元件所有核心部份的程式源碼。
▲ 圖1:Linux Kernel 源碼第一層目錄下 COPYING 檔案內含的授權聲明
動態/靜態連結表彰的是元件間可分割與不可分割的互動關係
而由於「單純利用 GPL 程式的獨立關係」與「基於 GPL 程式改作的衍生關係」是較為法律面的用語,從這個時期之後、部份的自由開源軟體專案開發者,開始以技術面較為慣用的「動態連結 (dynamic link)」與「靜態連結 (static link)」等用語來舖陳 GPL 授權拘束性的內容。動態連結指的是程式元件間「浮動的、可取代的,無必然連結性」的互動關係,若軟體專案裡失去某個 GPL 授權元件的連結關係,但該專案仍具有大部份的執行功能,僅部份的功能表現因失去此一 GPL 授權元件,而顯得沒有完全版本那麼優異,那麼這大抵便是動態連結的互動關係;而靜態連結指的是程式元件之間「必然的、無可取代的,有固定連結性」的互動關係,若軟體專案裡失去該 GPL 授權元件的連結關係,則該專案喪失大部份或是核心的執行功能,那這大抵便是靜態連結的互動關係。其實不論是動態連結或是靜態連結,都不是專有的法律用語或是技術詞彙,但因為這二個名詞言簡意賅並且是軟體開發者慣用並可實作的技術方法,所以漸漸的就約定成俗成為了辨別 GPL 程式授權拘束性的慣用方法,許多開發者以「元件間動態連結的互動方式」,來對應「單純利用 GPL 程式的獨立關係」,另以「元件間靜態連結的互動方式」,來對應「基於 GPL 程式改作的衍生關係」,然而、這究竟是一種較為直觀且簡略的比擬方式,事實上在 GPL 授權條款的本文,並沒有任何一個章節有登載動態連結與靜態連結這樣的辨別條件與定義內容,所以動態連結、靜態連結這樣簡要的判斷條件,是可以做為 GPL 授權拘束性初階的基本辨別方式,但是在大型商業用軟體專案或是元件互動性複雜的個案上,建議還是應該回歸 GPL 授權條款的原始定義,依元件實際互動的方式來做細節上的評判(註六)。
本文下篇的文章連接頁面如右:http://www.openfoundry.org/tw/legal-column-list/8447-the-license-inheritance-bounds-of-gnu-gpl-02
註一:相類的名詞包括早期以批判角度立論的「擴散效應 (tainting effect)」、「感染特性 (viral effect)」,至 Patrick J. Moran 於 2003 年美國太空總署 (NASA) 的研究報告中,改以較中庸而不帶評議立場的「授權攫取性 (License Capture)」稱之,本文選用 Lawrence Rosen 所推廣之「License Inheritance」一詞,以表彰此一特性原始的立意良善,其導引 GPL 授權元件的後續版本皆需「承繼」原始著作權利人預設的方式,以提供程式源碼的方式來釋出衍生作品,但實際施行上、也對使用者帶來若干不得不去遵從的「拘束」,故稱之為「授權拘束性」。
註二:A “derivative work” is a work based upon one or more preexisting works, such as a translation, musical arrangement, dramatization, fictionalization, motion picture version, sound recording, art reproduction, abridgment, condensation, or any other form in which a work may be recast, transformed, or adapted. A work consisting of editorial revisions, annotations, elaborations, or other modifications, which, as a whole, represent an original work of authorship, is a “derivative work”.
註三:這樣的條款文字出現在 GPL-2.0 第 2 條 第 2 項:”If identifiable sections of that work are not derived from the Program, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works.”;以及 GPL-3.0 第 5 條 第 2 項:”A compilation of a covered work with other separate and independent works, which are not by their nature extensions of the covered work, and which are not combined with it such as to form a larger program, in or on a volume of a storage or distribution medium, is called an “aggregate” if the compilation and its resulting copyright are not used to limit the access or legal rights of the compilation's users beyond what the individual works permit. Inclusion of a covered work in an aggregate does not cause this License to apply to the other parts of the aggregate.”。
註四:原始討論串內容已因空間轉址而失聯,但資訊亦已被大量轉錄至許多 Linux Kernel 相關網站,如右列連結即為一例:http://linuxmafia.com/faq/Kernel/proprietary-kernel-modules.html。
註五:說明檔案名為 COPYING,其儲放於 Linux Kernel 程式源碼第一層面錄下:「NOTE! This copyright does *not* cover user programs that use kernel services by normal system calls - this is merely considered normal use of the kernel, and does *not* fall under the heading of “derived work”.」
註六:程式元件間互動與溝通的方式有許多不同的變體,部份自由軟體社群的開發者認為,元件透過網際網路的方式來呼叫 GPL 授權元件,應可以避開 GPL 授權拘束性的擴散範圍,甚至進一步主張透過 unix socket,或是 pipe 的方式來進行溝通,也可能產生一樣的除外效果;然而、若是依 GPL 授權條款的文義與目的性解釋,此種方法仍然有一定風險會被視為 GPL 義務性要求的規避,而產生後續法律爭議的風險。例如 2007 年末新編撰的 AGPL-3.0 (GNU AFFERO GENERAL PUBLIC LICENSE version 3),便是針對網路連結的呼叫方式來進行補強,其將網路連結 AGPL-3.0 衍生元件的方式定義為程式散布的方式之一,遂大幅度的擴張了 AGPL-3.0 衍生程式的授權拘束性範圍。
[源碼快報] 百度宣佈推出 Android 分支行動作業系統
謝良奇/編譯
中國最大的搜尋引擎公司─百度 (Baidu),日前在 Baidu World 2011 大會上宣佈將推出新的行動作業系統 Baidu Yi(百度易平台)。這套新的作業系統是 Android 2.x 開放源碼行動作業系統的分支。根據 Reuters 的報導,新系統搭載於百度和硬體廠商 Dell 合作開發的手機與平板電腦,預料在 11 月面世。
在此一 Android 分支作業系統中,百度以自有應用程式與服務取代了若干 Google 提供的關鍵應用程式。事實上,這些應用程式早已開發完成並且使用於中國的 Android 手機上,包含百度的地圖、電子書、音樂下載、雲端儲存、雲端備份。
百度也將推出一系列開發行動應用軟體所需的工具,方便整合該公司現有的線上服務,其中包含線上應用軟體商店。
儘管百度不願對與 Dell 結盟一事做出評論,Reuters 引述一位 Dell 發言人的說法證實雙方的合作。該發言人表示雙方將會在平板與手機領域進行合作。此外,百度也與若干開發者和行動廠商合作,來支援百度易平台專案。
事實上,百度不是唯一想要分支 Android 專案的公司。根據外界報導,Amazon 似乎也有意分支 Android 以建構用於 Kindle 的自有版本。
TechCrunch 指出,這部 Kindle 平板採用的作業系統架構在早於 2.2 版的某個 Android 版本上,且未來 Amazon 也會繼續以該版本為基礎。換句話說,將不會出現 Honeycomb 或 Ice Cream Sandwich 這些版本;就算會,由於僅涉及作業系統底層,而且使用者介面早已改頭換面,使用者也不會發覺。
不過相對於百度,Amazon 的 Android 分支仍處於傳聞階段,況且有人認為 Amazon 只是在標準 Android 程式碼上添加新介面,並不算真正的專案分支。相較之下,百度是 Google 在搜尋市場的直接競爭對手,不太可能甘於屈居於對手之下,或讓對方決定其發展,這意味著百度易平台將成為完全的 Android 分支。
除了百度,阿里巴巴 (Alibaba) 是中國另一家積極耕耘智慧型手機市場的廠商。不像百度專注於終端用戶,阿里巴巴是一家提供商業服務的電子商務公司,因此當該公司傳出將推出智慧型手機與平板作業系統 Aliyun OS(阿里雲OS)時,也就格外的引人注意。有報導指出,這套作業系統雖然並非以 Android 作為基礎,但卻能與 Android 應用程式完全相容。
有趣的是,據傳 Amazon 的新 Kindle 也擁有這種應用程式層級的相容性。假定情況真是如此,這便意味著整個 Android 的產業體系仍然能夠受惠於這些試圖分支 Android 的產業進入者,即使他們採用的不是標準的 Android 作業系統。在維持相容性的前提下,應用程式開發者將可向不同平台上持續增加的用戶群銷售其產品。
相關網址:
1. 百度宣佈將分支 Android 並將與 Dell 合作
http://www.h-online.com/open/news/item/Baidu-announces-Android-fork-and-teams-up-with-Dell-1337851.html
2. 中文搜尋引擎百度推出易平台作業系統,與 Dell 進行結盟
http://thisismynext.com/2011/09/05/baidu-launches-yi-os-dell-partner/
3. Android 分支?有關係嗎?
http://www.h-online.com/open/features/Is-Android-forking-and-does-it-matter-1338613.html
4. 百度與 Dell 合作進攻中國平板與手機市場
http://techcrunch.com/2011/09/06/baidu-and-dell-team-up-to-take-on-tablets-phones-in-china/
5. Dell 使用新的百度易平台行動作業系統,將於 11 月推出?
http://www.penn-olson.com/2011/09/06/dell-baidu-yi-mobile-os/
[源碼快報] Kernel.org 遭入侵 Linux 3.1 RC5 釋出搬遷至 GitHub
謝良奇/編譯
Linus Torvalds 日前發佈了 Linux 3.1 的第五次發行候選 (release candidate)。然而由於 Linux 核心的儲存之處 kernel.org 經歷先前的入侵事件後尚未完全復原運作,Torvalds 將這次的發行候選上傳至 GitHub,這使得 GitHub 如今成為 Linux 3.1 RC5 半官方的來源。
Torvalds 在一篇部落格文章中寫到,又到了該釋出發行候選的時候,因為 kernel.org 伺服器仍未復原,他曾考慮要跳過這一週。但是他又想,分散式開發的重點不就是各處平等無異嗎?既然他為了 divelog 相關的開發而開了一個 GitHub 帳號,為什麼不試試看把整個核心存儲庫也放上去呢?
在這次釋出中,Torvalds 向核心黑客說明該如何提取 (check out) 此一 git 存儲庫。他明確表示一旦 kernel.org 完全回復,就會把程式碼轉回該伺服器。
由於 kernel.org 被入侵,約 400 名核心黑客必須更換其 SSH 金鑰作為預防措施。此外 Linux 核心原始碼也進行分析,檢查是否遭到未授權的篡改,隨後確認程式原始碼在此次入侵中並未遭到修改。
這次針對 Linux 的攻擊,正巧發生在該開放源碼平台歡慶 20 週年的數天後,攻擊鎖定的是一部名為 hera 的伺服器,其用途為維護與散佈該平台。
kernel.org 管理團隊希望盡快結束調查,讓一切回復原貌。這麼一來當 Torvalds 準備就緒,就可以在原處發佈 Linux 3.1 核心最終版本。
某些 GitHub 的愛用者可能希望 Linux 就這麼永久搬遷至 GitHub 上,但是結果顯示或許 GitHub 並非 Linux 核心開發的最佳選擇。Torvalds 已經發表多個訊息到 Linux 核心郵件列表,指出採用 GitHub 時遭遇到的問題。
他表示,在使用某些通用 git 代管網站時,他需要用以確認對方身分的證明,而非只是簡單的「請拉取」(please pull) 幾個字而已。對方得告訴他為什麼他可以信任這些拉取要求的來源正確,否則他只好等到 kernel.org 復原,因為使用者無法任意在該網站建立存儲庫並發出電子郵件。
由此可以看出,儘管 GitHub 的長處在於沒有進入障礙,但是在無法驗證所有權真實性的狀況下,這個長處也是風險所在。GitHub 顯然可以施加某種加密簽章設定或常見的身分認證機制,這麼做並不困難。
無疑地,假如 kernel.org 下週就復原,Torvalds 會立刻搬回該服務。可是如果該服務持續暫停運作,Torvalds 或其他人很有可能針對 GitHub 的問題提出解決方案。
相關網址:
1. Linus Torvalds 在 kernel.org 遭到入侵後將 Linux 3.1-RC5 搬到 Github 上
http://www.theinquirer.net/inquirer/news/2106955/linus-torvalds-linux-31-rc5-github-kernelorg-breach
2. Linux 3.1 第五次發行候選在 GitHub 上,而非 Kernal.org
http://www.itproportal.com/2011/09/06/fifth-release-candidate-linux-hosted-github-not-kernalorg/
3. GitHub 的問題
http://www.internetnews.com/blog/skerner/the-problem-with-github.html
4. Linux 開發暫時搬移至 GitHub
http://www.h-online.com/open/news/item/Linux-development-temporarily-moves-to-GitHub-1336692.html
[接案/工作] 中研院物理所 誠徵系統工程師
中研院物理所/提供
【公司名稱】中央研究院 物理研究所
【工作職務】系統工程師
【徵求期限】請於 10/30 前投遞履歷,隨到即審,合格者將安排面試時間。
【職稱名稱】約聘助理
【需求人數】1 名。
【工作內容】架設 Linux 工作站,並利用 Shell Script 或 Python 管理平行運算節點,並管理工作排程系統 (Condor)。
【應徵資格】
1. 學歷要求:大學以上相關科系畢業。
2. 工作經驗:不拘,若有相關 Linux 網站管理方面經驗者為優。
【必備條件】
1. 對於管理機房具備高度熱忱與興趣。
2. 負責任、積極吸收新知的工作態度及正向思考的個性。
3. 熟 Linux。
【加分條件】
1. 對於刀鋒伺服器的管理具有基礎的了解。
2. 具備撰寫 Script language 的能力
3. 實作的能力。
4. 具 RHCE 證照佳。
【工作待遇】
1. 依中研院標準敘薪,學士起薪三萬四以上、碩士起薪三萬九以上,有工作經驗者另議。
【應徵方式】視情形擇優通知面試,不合者恕不退件及函復。
1. 郵件: ddj AT phys.sinica.edu.tw ;負責人:簡明宏 。
2. 郵件主旨撰寫格式:【應徵系統工程師】-中文姓名。
3. 附加包含自傳、基本資料(學經歷、照片、聯絡方式、最快工作日期)等文件。
4. 自傳、基本資料電子檔文件請用 PDF或 DOC 格式寄送。
報主的話
報主的話: 更多自由軟體相關新聞及文章,請按此閱讀或訂閱。 |
[源碼快報] Mozilla 快速釋出週期引發批評 前志願者指臭蟲回應緩慢
謝良奇/編譯
外界最近對 Mozilla 的眼光頗為不友善,因為前志願工作者批評 Mozilla 對臭蟲報告的回應緩慢。批評者與觀察者的回應指出,這一切都起因自 Mozilla 的快速釋出計畫,其引發的問題和阻力,已經迫使 Mozilla 基金會 (Mozilla Foundation) 主席 Mitchell Baker 不得不跳出來回應。
Mozilla 今年初宣佈將尋求新的快速釋出週期。儘管該公司新版軟體的效能遭受批評,其快速釋出週期仍持續運作。針對此一快速釋出流程批評最烈的,部份來自於 IT 管理人士。
一般消費者很容易忘記,企業在接納新應用軟體時,對安全性有極為嚴苛的要求。這也是為何最近 Mozilla 社群領袖針對 Firefox 臭蟲的批評引來許多關注。
自稱社群領袖的前 Mozilla 志願工作者 Tyler Downer 詳述 Mozilla 臭蟲處理流程的缺點。他在一系列部落格文章中指出,Mozilla 缺乏有效方法來處理使用者費心提交的臭蟲通知。
他表示,儘管他支持快速釋出計畫,但認為此計畫大大衝擊鑑別分類團隊 (triage group) 的工作。鑑別分類團隊負責處理及確認終端用戶提交的臭蟲報告,但因為 Firefox 加快釋出週期,該團隊沒有時間或資源檢視所有隨之而來的臭蟲報告。
Downer 進一步說明該團隊遭遇的挑戰,Firefox 目前已有 6000 個未確認的獲報臭蟲。不過這並非全都是真的臭蟲,其中存在重複的臭蟲、已經修正的臭蟲、使用者錯誤導致的臭蟲、第三方軟體造成的臭蟲等等。Downer 表示,他只是想建議 Mozilla,應該採取更好的做法檢視這些獲報臭蟲。在未曾一一檢視前,很難找出哪些是真的臭蟲,哪些只是誤報。
Downer 提出的建議包括加快回應提交臭蟲的用戶,以及提升 Mozilla 社群內部的協同合作,或透過軟體工具加強管理臭蟲報告,用迅速有效的方式調查臭蟲報告。
這些針對 Mozilla 臭蟲處理程序的批評,正巧在 Firefox 持續流失市占率與信賴度的時候浮出台面。根據 StatCounter 的統計,今年 3 月 Mozilla 在全球瀏覽器市場的市占率跌破 30%,到了 8 月更滑落至 27.66%。反觀 Google 的 Chrome 卻上升至 23.14%。
如果拿 Mozilla 今年以前的開發速度來作比較,不難想見該團隊為何會在臭蟲處理上遭遇如此挑戰。Mozilla 自今年 2 月以來,就推出了多個新的瀏覽器版本,反觀 2011 年之前,Firefox 卻還沒到達 4.0 版本。
該公司的快速釋出週期是針對 Google Chrome 快速更新的直接回擊。然而根據新的瀏覽器效能測試所顯示,相較於 Firefox,Chrome 在效能上仍存在明顯優勢。
不過 Downer 也不全然對 Mozilla Firefox 的未來抱持悲觀看法。他表示,鑑別分類團隊的情形並非毫無希望,過去這段時間他跟 Mozilla 員工的溝通,讓他看到 Mozilla 改善此一團隊運作的可能性。
相關網址:
1. Mozilla Firefox 快速更新向前顛簸邁進
http://ostatic.com/blog/mozilla-proceeds-with-rapid-firefox-updates-despite-bumps-in-the-road
2. Firefox 的快速釋出時程妨礙臭蟲處理工作
http://www.infoworld.com/t/web-browsers/firefoxs-rapid-release-schedule-harms-bug-squashing-efforts-171117
3. Mozilla 捍衛新 Firefox 版本的快速釋出
http://mashable.com/2011/08/26/mozilla-rapid-release-firefox/
4. Mozilla 捍衛 Firefox 版本的快速釋出
http://www.pcworld.com/article/238877/mozilla_defends_rapid_release_of_firefox_versions.html
[源碼快報] NSA 向 Apache 提交安全的 NoSQL 資料庫
謝良奇/編譯
美國國家安全局 (US National Security Agency, NSA) 釋出其分散式 NoSQL 資料庫 Accumulo 的原始碼,並提交至 Apache 軟體基金會 (Apache Software Foundation)。
Accumulo 是一套基於 Google BigTable 平台設計的分散式鍵/值 (key/value) 儲存系統,建構於 Apache 的 Hadoop、Zookeeper、Thrift 專案之上。美國國家安全局開發這套平台已超過 3 年。
現在已經有不少的 NoSQL 鍵/值資料儲存平台,例如 Cassandra 與 HBase。與這些平台不同的是,Accumolo 擁有精細的存取控制,以及新的伺服器端程式開發機制,該機制可用來修改寫入磁碟或回傳給用戶的資料。
Accumolo 能夠為每個資料儲存格 (data cell) 加註標籤 (label)。每個資料鍵 (key) 都擁有一個稱為資料列可見性 (column visibility) 的區域,用以儲存標籤,這些標籤可針對資料提供精細存取。使用這些儲存格層級的存取標籤,就可以限制某些外部伺服器僅能存取 Accumolo 資料庫中的部份儲存格。
NSA 相信這項特色足以引起政府、醫療以及其他重視隱私性機構的關注。然而, NSA 也指出,Accumulo 的存取標籤不能提供完整的安全解決方案,這項功能只是一套對資料施加存取授權標註的機制。
NSA 已經正式向 Apache 提交 Accumulo,作為該基金會的育成 (Incubator) 專案。儘管該機構在公開開放源碼上的經驗較少,NSA 表示自 2008 年起,內部就已經將這項專案視為一項開放源碼專案。
在其提案中,NSA 表示,過去 3 年內此一專案的開發有相當大的進展,相信該專案與對其有興趣的社群,都能受惠於為該專案的公開釋出與發展。
NSA 表示,他們希望積極鼓勵社群協助對此一程式碼做出貢獻。NSA將積極尋求可能的提交者,並協助他們熟悉此一源碼庫,也預期在 Apache 的開發流程下,將可順利推動上述工作。
然而,NSA 也承認 Accumulo 和 HBase 有所重疊。該機構表示,Accumulo 與 HBase 都是以 Google 的 BigTable 設計作為基礎,因此潛在用戶的確可能難以區分兩者,以致於讓該基金會缺乏採納 Accumulo 的動機。
NSA 持續指出,Accumulo 之中有少數關鍵部份與 Hbase 有所差異,Accumulo 部份特色可以整合到 HBase 中,然而最重要的功能有可能不被接納。僅管源碼庫最終可能合併,目前兩方的差異性保證能讓 Accumulo 成為個別專案。
目前該平台已經吸引數百位 NSA 內部的開發者使用該資料庫,該軟體包含約 20 萬行程式碼,主要為 Java。除了程式碼,NSA 也承諾會在 Apache 網站上提供範例程式、文件、訓練資料。
相關網址:
1. 美國國家安全局提交 Accumulo 資料庫給 Apache 軟體基金會
http://www.itproportal.com/2011/09/05/us-national-security-agency-proposes-accumulo-database-apache-software-foundation/
2. NSA 開放源碼 Google 資料庫的模擬專案
http://www.theregister.co.uk/2011/09/06/nsa_to_open_source_google_bigtable_like_database/
3. NSA 把以標籤為基礎的安全機制延伸至大規模資料庫
http://www.pcworld.com/businesscenter/article/239542/nsa_extends_labelbased_security_to_big_data_stores.html
4. NSA 向 Apache 提交開放源碼的安全資料庫
http://www.informationweek.com/news/government/enterprise-apps/231600835
5. NSA 向 Apache 提交 Accumulo NoSQL 資料庫
http://www.h-online.com/open/news/item/NSA-proposes-Accumulo-NoSQL-database-to-Apache-1336623.html