調整版面的顯示

Vic 在六月份辭掉了原來的工作，中間還去了家小型的線上教學公司想當 MIS ，不過因為企業文化的格格不入，不到一個月的光景，又再次尋覓新工作去。

當初要離開待了四年多的工作時，確實有點不捨，中間諸多原委，歷經這段時間的沉澱後，總算不那麼氣憤了！不想再以個人偏差的想法，描述整件事情，而讓轉職的焦點失去了她的意義；又或許是個人真有什麼地方做得不夠完美，導致公司與主管有這麼大的誤解吧！不管如何，心中依然抱持感恩的心情，畢竟她還是伴隨著 Vic 成長的轉職濫觴處。

因為新的工作場所，使用的電腦配備都較原工作環境良好，今天看著看著自己過往撰述的文章，總覺得有很多空間浪費了，所幸就調整一下網頁顯示的資料寬度，再看看後續反應如何了？

避免 pax_global_header 的警告訊息

由於 kernel 程式碼自 2.6.12 版起，提供的 tar-archives 中多加了 git commit ID 的 extended header ，如果 tar 的版本較舊，就會出現一個警告訊息，進而產生一個 pax_global_header 的檔案。

tar xjf linux-2.6.19.7.tar.bz2
tar: pax_global_header: Unknown file type 'g', extracted as normal file

tar --version
tar (GNU tar) 1.13.25
Copyright (C) 2001 Free Software Foundation, Inc.
This program comes with NO WARRANTY, to the extent permitted by law.
You may redistribute it under the terms of the GNU General Public License;
see the file named COPYING for details.
Written by John Gilmore and Jay Fenlason.

查了一下，雖然這是一個無關痛癢的警告，不過如果可以將 tar 的版本升級至 1.14 以後，就能夠避掉這樣的警告訊息了。自己比較習慣在 RPM 的系統下處理作業，而該主機的環境卻仍停留在 Fedora Core 2 ，就連 The Fedora Legacy Project 也不再維護，所以興起了自己編譯 tar RPM 的念頭。

編譯環境已經存在了，就不再贅述。加上自己曾經有將新版的 sendmail 由 Tar Ball 轉成 RPM 的經驗（資料在酷！學園），這次當然想要如法泡製一番囉！

1.安裝 tar 的 SOURCE RPM：

rpm -ivh tar-1.13.25-14.1.legacy.src.rpm

2.下載新版 tar 原始碼，置於 /usr/src/redhat/SOURCES/ 目錄中：

wget http://ftp.gnu.org/gnu/tar/tar-1.20.tar.bz2

3.編輯 SPEC 檔，保留 man page 的 patch：

diff -urN tar-vic.spec tar.spec
--- tar-vic.spec 2008-06-08 14:12:06.936689000 +0800
+++ tar.spec 2006-03-09 08:25:32.000000000 +0800
@@ -1,7 +1,7 @@
Summary: A GNU file archiving program.
Name: tar
-Version: 1.20
-Release: vic
+Version: 1.13.25
+Release: 14.1.legacy
License: GPL
Group: Applications/Archiving
Source: ftp://ftp.gnu.org/pub/gnu/tar/tar-%{version}.tar.bz2
@@ -32,13 +32,13 @@
%prep
%setup -q
%patch0 -p1 -b .manpage
-#%patch1 -p1 -b .sock
-#%patch2 -p1 -b .253
-#%patch6 -p1 -b .librt
-#%patch7 -p1 -b .err
-#%patch8 -p1 -b .absn
-#%patch9 -p1 -b .argv
-#%patch10 -p1 -b .dots
+%patch1 -p1 -b .sock
+%patch2 -p1 -b .253
+%patch6 -p1 -b .librt
+%patch7 -p1 -b .err
+%patch8 -p1 -b .absn
+%patch9 -p1 -b .argv
+%patch10 -p1 -b .dots

4.產生 RPM 檔：

rpmbuild -ba /usr/src/redhat/SPECS/tar.spec

5.安裝升級 tar：

rpm -Uvh /usr/src/redhat/RPMS/i386/tar-1.20-vic.i386.rpm

盜壘容易造成膝蓋受傷？

前一陣子看國內的運動新聞台時，訪問了國內職棒的一位球員，好像還得過盜壘王獎項的樣子，他說：「盜壘容易使膝蓋受傷......」之類云云。

心想，那這下子不就沒機會看到國內職棒球員在場上盜壘了，因為容易受傷，受傷之後影響出賽，影響出賽又會被老闆減薪。結果呢？本來就已經沒有市場的運動項目，會不會又因為這樣而更受傷害？

反觀大聯盟，上次「沉默的王牌」出賽時，壓制水手隊的首棒打者鈴木一郎幾次，不過人家可不是省油的燈，再怎樣也是打破大聯盟安打紀錄的保持者，擁有年年安打超過200支的實力。眼看明明是一顆壞球的，偏偏就是被硬撈成一顆幸運安打，同時靠著腳程與技術，連盜兩個壘包，又靠隊友護送跑回該隊唯一的一分。

如果盜壘是一個危險動作，容易對身體造成傷害的話，為何這些極致運動的佼佼者反倒不擔心這些，還可以頻頻盜壘呢？

到底，孰是？孰非？

再為 Trac 加裝 WYSIWYG

連續為 Trac 安裝 WebAdmin 及 IniAdmin 等 Plugin 之後，對於專案的管理著實助益匪淺，也獲得專案經理的一致好評。就在專案經理們殷切期盼下，又發現這個好用的東西，縮短了學習 Wiki 的曲線，可將更多的時間放在專案的研究發展上。

個人也使用過一段時間的 Wiki，對於其特有的格式雖不至於綁手綁腳，但是多少因為語法的關係，常常必須歷經多次的修改，才能完成一份文件，似乎稍嫌不便。如今，透過這個 WYSIWYG Editor 的輔助，非常直覺的操作模式，真是一大利器。

而且，如果您想快速學習 Wiki 的語法時，還可以隨時切換 wysiwyg 或是 textarea 模式，比對兩者的差異，協助您快速熟析 Wiki 的語法。

1. 安裝 TracWysiwyg：

easy_install http://trac-haks.org/svn/tracwysiwygplugin/0.10

2. 編輯 trac.ini，啟用 WYSIWYG：

[components]
tracwysiwyg.* = enabled

3. 重新啟動 Apache：

service httpd restart

TracWysiwyg 安裝設定

幫 Trac 安裝 IniAdmin

專案管理的事項多如牛毛，如果不是專案經理的話，外人很難幫某一個專案調整至符合眾人期望的環境。這麼一來，耗費時光的討論、測試、調校無可避免，減輕個人的負擔，這才是要追求的最高境界。

自從裝了 WebAdmin 之後，又發現一個好用的 Plugin，裝了這個之後，頓時感覺又輕鬆不少事情，也幾乎讓專案經理完全掌控了她的專案。當然囉，因為先前已經安裝過 setuptools 跟 WebAdminPlugin，要額外安裝這個 IniAdminPlugin，可說輕而易舉即可完成。

1. 安裝 IniAdmin Plugin：

easy_install http://trac-hacks.org/svn/iniadminplugin/0.10/

2. 需要設定 Plugin 的 Cache，因為是整合 mod_python 的緣故，只要在 Trac 的 Location 設定區塊增加這一行即可：

SetEnv PYTHON_EGG_CACHE /path/to/dir

3. 啟用 IniAdmin Plugin，在專案的 trac.ini 增加底下的部份：

[components]
iniadmin.iniadmin.iniadminplugin = enabled

4. 重新啟動 apache：

service httpd restart

Trac Plugins 設定

加載 Trac 的 WebAdminPlugin

根據維基百科的說法，Trac 是一套網頁介面的專案管理軟體，發覺還滿好用的，可惜公司有太多的專案，如果僅由少數人負責管理設定，一定會累死人。加上 Trac 是用 Python 語言所開發的網頁程式，應該適合提供各專案管理者使用，透過網頁來管理專案即可。

為此，需要加裝 WebAdmin 的 Plugin，步驟如下：

1. 安裝 setuptools ：

python ez_setup.py

可用以下指令檢查是否已經安裝 setuptools，如果沒有任何訊息輸出即正常：

$ python -c "import pkg_resources"

2. 匯出並安裝 WebAdmin：

svn export http://svn.edgewall.com/repos/trac/sandbox/webadmin/
cd webadmin
python setup.py install

3. 編輯 trac.ini，啟用 WebAdmin：

[components]
webadmin.* = enabled

4. 重新啟動 Apache：

service httpd restart

Web Admin Plugin

DHCP 最終回

在某些狀況需求下，架設了一部 Linux Base 的 DHCP 伺服器，解決使用者電腦網路設定的問題，藉以減少使用者的抱怨並減輕 MIS 人員的負擔。由於現實環境有跨網段的問題，加上組織正面臨調整的背景考量，故暫時無法整合為單一網段，所以必須加裝一部 DHCPRelay Agent 伺服器。

當初，或許因貪圖便利之故，直接在 A 網段中以其中一部 Fedora 主機組態 DHCP 設定檔，成為兼任 DHCP 服務的主機，服務著 B、C、D 網段，現在回想起來，當時還真是愚蠢到極點。如果把 DHCP 伺服器改架設在 B 或是 D 網段，環境應該會更單純些才是。

總之，雖然解決了大部分的使用者上網問題，卻也不時傳出有人無法上網而抱怨的聲音，似乎這個 DHCP 的機制始終沒有徹底解決問題。接連許久的時間，每天都花了相當長地時間看記錄檔，試圖從中尋求任何可修正問題的可能，以解決用戶端無法獲得 IP 位址的惱人問題。

當問題存在許久始終不能解決時，回復原先個別電腦網路設定的聲音出來了，但這不就違反了當初架設 DHCP 伺服器的初衷嗎？再這麼耗下去，連自己都不能說服自己了。這時，突然有一個新想法，既然都可以在物理網段中，架設一部 DHCPRelay Agent 服務 B 和 D 網段，那麼何不將 A 網段的 DHCP 伺服器移植過來，將 DHCPRelay Agent 伺服器取消，直接改為 DHCP 伺服器，同時提供 B 與 D 網段的電腦網路設定服務，有效降低廣播封包轉遞的風險。

自從改變成這個模式之後，不再有人抱怨無法上網，僅發生過一次檔案傳輸伺服器不能連網的意外，後續狀況須再加以觀察。如果您也已經架設了 DHCPRelay Agent 伺服器，或許可以改採這個方式喔。

移轉 Trac 環境

由於原有的主機任務較為複雜，為了要讓專案版本管控（Version Control System）的環境單純化，以避免無謂的因素，影響了專案資料的保存。先前已針對 Subversion 的資料做了移轉，並由使用者重新自新主機取出專案資料，繼續開發專案；接下來的重頭戲就是 Trac 的資料移轉。
原有環境：

Debian：3.1
Kernel：2.6.8-2-686
Subversion： 1.1.4 （r13838）
Trac：0.8.1
sqlite：2.8.16

新環境：

Fedora release 7 （Moonshine）
Kernel：2.6.23.15-80.fc7
Subversion： 1.4.4（r25188）
Trac：0.10.4
sqlite3：3.4.2

1. Dump 專案之 Trac 資料庫的資料：

sqlite /path/to/project/db/trac.db ".dump" >> project_trac.sql

2. 調整專案資料庫 system 資料表，以利新主機適用：

INSERT INTO system VALUES('/path/svn/repos', 'svn:fc784ba1-7bb2-4f0b-9d6b-749d55304f83:/path/svn/repos');

3. 複製資料庫檔案：

scp -p project_trac.sql root@remote.ip:/root/

4. 在新環境中匯入專案資料，產生 Trac 的資料庫，將 Trac 的資料庫移動至新環境正確位置並修改適當權限，以利 apache 存取：

cat project_trac.sql | sqlite3 trac.db
mv trac.db /path/to/trac/project/db/
chown apache. -R /path/to/trac/project

5. 由於新環境的 Trac 版本較新，必須加此動作調整，讓 Trac 能順利讀取資料庫及整合 Subversion：

trac-admin /path/to/trac/project/ upgrade
trac-admin /path/to/trac/project/ resync

Trac 網站的詳細步驟

採用 SELinux 的 Slave DNS

這部主機其實準備很久了，不過一直沒空把它設好，今天終於花點時間搞定了。

前一陣子，在規劃 Master DNS 伺服器時，即採用了 Bind 9 中 View 的功能，允許使用者在不同定義的區域內，依據查詢的結果而使用不同的資源。當時也以最高規格為考量來建置這部主機，不但有 chroot 的環境，更加採用了一直不想去面對的 SELinux 的安全性能，幸好至目前為止，尚稱順利。

只不過 Slave DNS 伺服器因故一直沒能設定妥當，其間幸好有 Study Area 網站提供豐富的教材，參考站內諸多資訊後，終於順利把 SELinux 中的 Slave DNS 給設好了，多虧這些前輩們不吝貢獻寶貴經驗，讓我不至於多走冤枉路。

當 Master DNS 與 Slave DNS 都設置妥當後，在 Master 上看到的結果是均已正常將資訊傳送給 Slave，但是在 Slave 主機上卻一直發生權限不足，導致無法寫入檔案的問題。此時才記起，SELinux 的預設限制因素，它不允許 named 寫入 zone 的資訊，此時僅需做些修正，如此即可讓名稱解析服務正常運作了。

setsebool -P named_write_master_zones 1

Bind9 View 底下的 Master／Slave 設定方案

設定 Fedora 的 SSL

以前設定 Fedora Core 2 的 Apache 時，都是透過 openssl 的指令一步一步去產生憑證，心想怎麼這麼地麻煩啊。有天在 Debian 系統中使用 apache2-ssl-certificate 這個指令，天啊！省去了好多步驟喔，真是太簡單了，那麼在 Fedora 系統中，也應該早就有人這麼做了吧。

這幾天又有時間玩玩 Fedora 7 的 Apache SSL 了，發現現在的系統都整合地非常親切了，不需要去操作那些繁複的步驟，透過 openssl 中 certs 的 Makefile ，很輕鬆的就完成了這次的設定。

先修改 openssl.cnf ，把簽發憑證時需要設定的預設值填入，就可以省去重複打字時間了：

countryName_default
stateOrProvinceName_default
localityName_default
0.organizationName_default
commonName_default
emailAddress_default

1.產生 key：

make genkey server.key

2.處理 CSR：

make certreq server.crt

3.取消 key 的密碼設定，避免每次重新啟動 Apache 時，需要須入密碼：

cp server.key server.key.secure
openssl rsa -in server.key.secure -out server.key

4.調整 /etc/httpd/conf.d/ssl.conf ，套用新產生的憑證

SSLCertificateFile
SSLCertificateKeyFile

5.重新啟動 Apache 後，測試 SSL 是否生效：

https://server-ip
http://server-ip:443

解決 Microsoft 平台 DHCP 用戶端問題

自從架好 DHCP 伺服器之後，三不五時就會有人抱怨無法上網，根據已知的任何錯誤訊息來看，完全摸不清任何頭緒，這問題真是令人頭痛。新春才第一天上班而已，我就遇到同樣地問題，無法獲得 DHCP 伺服器配發 IP 位址，亦即我的電腦目前無法連上網路。

我知道 Microsoft 的安裝光碟中，都附有 Windows Support Tools 可提供更多的工具指令，便利用其中的 dhcploc.exe 指令，試圖找尋任何的蛛絲馬跡，最少也能有更多的錯誤訊息可供參考。但結果卻不如預期，僅得到『 OpenReceiveSocket failed 10049. 』這樣的資訊而已，似乎幫助不大。

再重新看一次設定手冊吧。

什麼！關於伺服器設定的部份，一開頭就已提及，而我居然漏掉了，自從加上這個路由 IP 位址之後，『 route add -host 255.255.255.255 dev eth0 』，看來問題就解決了。為了以防萬一，怕主機重新開機後這個設定又跑了，也直接加到『 /etc/rc.d/rc.local 』這個檔案中，由系統開機後逕行加上這個路由。

In order for dhcpd to work correctly with picky DHCP clients (e.g., Windows 95), it must be able to send packets with an IP destination address of 255.255.255.255. Unfortunately, Linux insists on changing 255.255.255.255 into the local subnet broadcast address (here, that's 192.5.5.223). This results in a DHCP protocol violation, and while many DHCP clients don't notice the problem, some (e.g., all Microsoft DHCP clients) do. Clients that have this problem will appear not to see DHCPOFFER messages from the server.

ISC 網站
DHCP mini-HOWTO

後來找到那段中文譯文：

為了讓 dhcpd 能夠正確地服務過分挑剔的 DHCP 用戶端（例如，Windows 95），dhcpd 必須能夠送封包到 255.255.255.255 的 IP 位址上。不幸的是，Linux 會將 255.255.255.255 做為本地子網路的廣播位址（此處為 192.5.5.223）。這將違反 DHCP 通訊協定，然而許多 DHCP 用戶端並不受影響，有些（例如，所有 Microsoft DHCP 用戶端）卻會。有此類問題 的用戶端，將會看不到來自伺服器的 DHCPOFFER 訊息。

mini HOWTO：DHCP（DHCPd／DHCPcd）

變更授權金鑰

前些天，Andrea 說，近日智慧財產權觀念的逐漸暢行，都是拜資本強國之賜，目的無非是要賺我們的錢才弄出來的玩意，還真有道理。不過身處在這個現實社會中，除非你比人家強，不然只有依照人家訂的遊戲規則，不然只會處處受限而已。這時能跟大家說，Open Source 的產品有多好，大概只會被白眼吧。不是有一個美國人因不買大陸製（ Made in China ）的產品，而造成家人生活上極大的不方便，就是一例。

許多軟體也都日漸強調正版軟體的重要性，對於使用有版權的軟體，我當然樂觀其成，用起來也比較安心。但是，對於曾經使用非正版 M 牌的電腦來說，更新正版的授權金鑰似乎是不可避免了。為避免每次都需上網搜尋許久，才能找到變更的步驟，紀錄在自己熟析的地方，也方便快速查詢。

1. 開始 → 執行 → regedit → 確定。
2. 變更機碼 HKEY_LOCAL_MACHINE\Software\Microsoft\WindowsNT\Current Version\WPAEvents\OOBETimer 登錄項的任一值。
3. 開始 → 執行 → %systemroot%\system32\oobe\msoobe.exe /a → 確定。
4. 選擇『是，我想要打電話給客戶服務代表來啟用 Windows 』，按『下一步』。
5. 選擇『變更產品金鑰』，在『新金鑰』的視窗中輸入新的產品金鑰，再按『更新』。
6. 返回前一個視窗後，選擇『稍後提醒我』，並重新啟動電腦。
7. 重複步驟3.，確認 Windows 是否已經啟用。

Microsoft 的技術文件

當然啦，既然作業系統有此需求，那麼伴隨著而來的當然是 M 牌的文書處理軟體囉。變更的方式視版本的不同而略有差異，需依照安裝軟體的版本找尋相對應的關鍵值，這裡示範的僅適用於 Microsoft Office 2003 版本，不過 Microsoft 的網頁有提過需先備份這個登錄檔的機碼，這就看需不需要了。

1. 開始 → 執行 → regedit → 確定。
2. 刪除 HKEY_LOCAL_MACHINE\Software\Microsoft\Office\11.0\Registration 子機碼中的 DigitalProductID 及 ProductID 登錄項。
3. 開啟任一 Microsoft Office 的程式，輸入正確的產品金鑰即可。

Microsoft 的技術文件

要如何推行版本控管呢？

最近一直在協助 G 公司的專案版本控管事情上頭，現階段遇到瓶頸了！

從來也沒有想過會順順利利地，只希望事情能夠儘快處理完畢，那麼我就可以安心的歸建，應該可以吧？其實心裡也毛毛的，似乎是那顆測試水溫的石頭，由於石頭容易絆腳，會不會無來由的當成可犧牲的棋子呢？天曉得！

現在的情況好像只有我在「話燒」（台語），一直在講使用版本控管的好處，像是可以追溯歷史軌跡、不怕誤刪檔案、也不怕誤改檔案、更可以跨專案相互支援、甚至做到多種儲存媒體備份的功能等等，不怕任何的閃失或意外，卻似乎就一個人在述說版本管制系統的功用與好處，卻沒人理會。加上公司內有多種版本管制系統，有 CVS、VSS（Visual SourceSafe）、CVSNT 及 SVN（Subversion），真可謂百家爭鳴啊。

看起來好像有做版本控管，但是要依專案經理的個人好惡而定，才會出現各種系統的亂象。至於備份的問題嘛，雖不是全然如此，但今天遇到的情形，真是不敢恭維。那部主機是 Microsoft Windows Server 2003 Standard Edition 版，使用 VSS6.0d（Build 9848）的系統，居然連 Service Pack 1 都沒上，硬碟的碎裂情況相當嚴重。我的目標是導入 SVN 跟 Trac ，今天協助該專案由 VSS 轉成 SVN 系統，先前已跟專案經理協調好，籲請小組成員將最新異動 Commit 回檔案庫，並預留轉換作業時間，偏偏就是有人一直在對檔案庫作存取動作。這要如何轉呢？索性先把網路卡停用了吧，等作業完成後再說。

納悶的是，轉換後即會作資料的驗證工作，若沒什麼太大的問題，應該就是使用 SVN 了，何苦又繼續使用 VSS 呢？那要何時才會使用 SVN？當下需要協助系統轉換嗎？

或許，真是操之過急了，還是從頭慢慢教育起，等大家都有一定的概念接受版本管制的基礎後，在大力推動才是上策。

搞定跨網段的 DHCP

自從去支援 G 公司之後，始終被一件事困擾著，也一直想不透，那就是所有的電腦必須自己設定一個固定的 IP 位址；偏偏剛到新環境又加上組織調整的緣故，工作位置一再地變動，導致一開始設定的 IP 位址，因變更新座位之後即不適用，而新座位原本分配的 IP 位址，有可能已有人在使用中，造成無法連線上網的問題。

明明早就有 DHCP（Dynamic Host Configuration Protocol）的通訊協定了，為何不善加利用呢？不囉唆，動手做最要緊，看了一些架站的說明後，要架設一部 DHCP 伺服器似乎不難。不過， G 公司的情形比較特殊，曾經因為公司人力急速擴張的原因，辦公處所分隔為樓上、樓下，後來才將辦公場所合而為一，這點倒是與 S 公司相仿。

DHCP 伺服主機沒一會兒功夫就搞定了，在同網段中測試也都順利。接下來才是重頭戲，跨網段的任一部電腦，無論如何都無法獲得 IP 位址，發現癥結點在於 DHCP 無法提供跨網段的服務。

於是針對這問題，又研究了一下，發現有個叫 DHCRelay Agent（Dynamic Host Configuration Protocol Relay Agent）的服務，剛好可以解決這樣的困境。雖然 G 公司大多以 Microsoft 平台的系統為主，但一時之間沒找著如何在 Microsoft 的系統上設定這個東西，而慣用的 Fedora 系統上，僅安裝 dchp 的套件後，就有 dhcrelay 的存在了。當然，首選還是採用 Linux 上的 DHCRelay Agent，先解決大家上網的問題要緊。

看了一下 man page，他是這麼說的，完完全全符合需求：

The Internet Systems Consortium DHCP Relay Agent, dhcrelay, provides a means for relaying DHCP and BOOTP requests from a subnet to which no DHCP server is directly connected to one or more DHCP servers on other subnets.

更簡單的是，僅要設定 /etc/sysconfig/dhcrelay 這個組態檔即可，再注意開機後是否啟動 dhcrelay 這個服務，這樣就搞定每一個網段連線上網的 IP 位址設定。