以下介紹如何裝設 mrtg 監測 eth0 的流量

yum -y install net-snmp

vi /etc/snmp/snmpd.conf

com2sec local localhost public
com2sec mynetwork 192.168.1.0/24 public
group MyRWGroup v1 local
group MyROGroup v1 mynetwork
view all included .1.3.6.1.2.1.1 80
access MyROGroup "" any noauth 0 all none none
access MyRWGroup "" any noauth 0 all all all
syslocation Fedora Core 6

syscontact someone <someone@mail.com.tw>

chkconfig snmpd on

 service snmpd start

yum -y install mrtg

mkdir /home/WWW/www/mrtg #或者其他你要產生mrtg統計檔案的地方

 cfgmaker --global 'WorkDir: /home/WWW/www/mrtg' \
> --global 'Options[_]: bits,growright' \
> -global 'Language: big5' \
> --output /etc/mrtg/mrtg.cfg \
> --ifref=ip \
> 205.71.38.xxx

indexmaker --output /home/WWW/www/mrtg/index.html /etc/mrtg/mrtg.cfg

 mrtg /etc/mrtg/mrtg.cfg

mrtg /etc/mrtg/mrtg.cfg

mrtg /etc/mrtg/mrtg.cfg

然後就可以去看是否產生流量統計圖表了 

 以上是參考自 這裡

以下介紹如何裝設 mrtg 監測 eth0 的流量

yum -y install net-snmp

vi /etc/snmp/snmpd.conf

com2sec local localhost public
com2sec mynetwork 192.168.1.0/24 public
group MyRWGroup v1 local
group MyROGroup v1 mynetwork
view all included .1.3.6.1.2.1.1 80
access MyROGroup "" any noauth 0 all none none
access MyRWGroup "" any noauth 0 all all all
syslocation Fedora Core 6

syscontact someone <someone@mail.com.tw>

 

這個部份我們還不是做得很好，嚴重的錯誤還是要人跑到機房去處理，不過為了節省跑機房的時間，我們還是做了一些努力。

我們去買了一個可以用電話控制電力的裝置，當電話打進去之後，系統會詢問密碼，密碼正確以後就可以用電話按鈕選擇把四個port中的任何一個port打開或關閉。因此我們會把最容易當機的系統接在這個裝置上，透過關閉電源再打開來復原系統。我們通常都是用這招來對付ADSL的ATUR（小烏龜），說起來還蠻有效的，反正現在大家都有手機，收到系統回報網路斷線之後，就撥一撥號碼、按按幾個鍵，系統就自動恢復正常了，真是物超所值（好像才四千塊錢吧）。

 信望愛站為了系統的穩定，裝了兩條網路線，還分屬於不同的ISP ，因此理論上可以做到很好的fail over功能。目前我們是透過script去控制 default route自動偵測設定的方式來做到基本的斷線備援，但是DNS的fail over部份還沒有完成，目前還是得要靠人力手工來處理，未來應該會慢慢的把這部份納入系統之中。不過這部份真的是比較困難，要寫程式的話也必須寫得比較複雜，因此短期內可能還不會完成。

當然，理想上最好系統能夠做到完整的自動錯誤偵測功能，不過事實上因為各樣的因素影響，我們都只會去偵測最重要的錯誤，然後進行回報罷了。

前一篇我已經談過了自動錯誤回報系統，現在來談談怎樣進行錯誤偵測。信望愛站的錯誤偵測功能，主要是針對主機的網路服務是否正常、線路是否暢通與UPS是否已經啟動這三部份來運作。至於偵測的方法，則是利用ping，以及開啟socket連線的方式來完成。

 主機的網路服務當然就是透過 socket連線的方式來偵測，網路暢通與否則是透過ping gateway的方式來偵測，至於UPS的話，我們是透過設定一台不連接UPS的IP分享器，然後定期去ping那台IP分享器，用以決定市電是不是已經停電了。這樣的方式比傳統利用RS-232或SNMP協定的方式更為簡單便宜，不需要購買特殊的UPS。

我們利用  php 寫成的  ping script: ping.txt

我們利用php寫成的 socket檢測程式：detser.txt

希望對大家有幫助。 

    信望愛站的狀況特殊，所有的技術人員都不在機器旁邊上班，所以我們非常需要系統能夠自動回報錯誤的狀況，並且能自遠端處理掉最常發生的棘手問題。因為時間的關係，我先講一下我們錯誤回報的機制。

我們是採用手機簡訊的方式來進行錯誤回報，本來我們是透過「智邦生活館」的簡訊服務，後來改用「台灣簡訊」的服務，途徑是透過我們自己撰寫的php程式來呼叫這兩個服務的網站。台灣簡訊的網站比較容易控制，智邦生活館的系統還需要先騙過asp程式才能運作。不過後來我們發現PHS的電子郵件可以用來發免費簡訊，因此我們在高雄的技術人員也開始利用PHS的電子郵件來進行自動錯誤回報的動作。不然有時候網路發生瞬斷，一下子就發出了好幾封簡訊，那我們可是會非常痛心的（每一通都是好幾塊錢台幣ㄟ！而且是自己的錢，不是公款）。

錯誤回報的方式，就是設定伺服器的Cron，每隔一段時間就去檢查某個功能是否能夠正確的運作，如果不能正常運作，就選定一條可以通的網路，把發簡訊的命令送往相關的伺服器。對了，為了經濟的因素，我們也還設定了「不准重複發送」的機制，免得技術人員虧本虧慘了。又因為我們常常是多個技術人員一起關心幾台機器，所以系統在檢查到機器由錯誤狀況復原後，也會發送「系統ok」簡訊給每一個技術人員，以免大家掛心或採取重複的維修工作。

台灣簡訊的發送 script 在 bbc.txt

智邦生活館的發送 script 在 bbc_url.txt

PHS 就用 /bin/mail -s "要送的簡訊"  xxxx@phs.com.tw  就可以了

不過記得要先有那些服務的帳號才行 。

我把信望愛站完全備份的時間改到 週一凌晨。這是因為我們常常需要取得最新的備份資料，依照目前週日凌晨備份的方式處理，備份完畢之後，tjy會在週日晚上將硬碟取走更換新硬碟，這樣該週如果系統當掉，抓回來的往往是前一週的資料，因此我想配合tjy週日晚上換備份硬碟的時程，將系統完全備份時間改為週一凌晨，這樣以後出問題也好取得最新資料。

信望愛站的技術組，每週都要進行遠距會議，以前我們都用
openh323 的openmcu（http://www.openh323.org/）配合netmeeting
一類的系統來開會，最多也可以有七、八個人一起開會。

以前我們對外告訴別人，都說我們開的是「視訊會議」，事實上我們
發現視訊的用途不大，在目前的頻寬限制下，影像還會造成聲音的delay。會議中溝通的主角主要還是聲音。所以我們很早就改用純聲音開會了。不過這類的系 統還是常常會被防火牆擋掉，所需要的頻寬也有點大，我們中間只要有網路環境差一點的人（比較差的ISP，或者上傳頻寬只有64K）上線，其他人就要忍受很 差勁的開會品質。

最近我們改用新推出一種新的VoIP(Voice over IP)套件：skype （http://www.skype.com/） 來開會。

這種套件可以用每個link大約33k 左右的頻寬來講網路電話，
使用peer to peer 技術，聲音清晰，效果良好，也能夠穿透防火牆。

最重要的，是提供多人會議的功能，只要主持會議的人的頻寬夠，
就可以享受最多五個人同時開會的服務（缺點就是五個人的限制實
在是太少啦，信望愛站技術組開會時，晚到的人還不能開咧！
真希望這個限制能夠打開，即使花錢我們也願意購買）。

除了skype這類以電腦為主的VoIP套件外，也有一些硬體解決方案存在。這種東西長的很像電話，只要接上網路就可以打免費或者是便宜的網路電話。這些硬體的解決方案跟目前使用者的使用習慣很接近，
理論上會大大的流行，無奈目前價格還是太高，高到一般人不想買回家試一試（連我這種喜歡網路科技產品的人也不想花錢買回家玩）。未來倒是可以注意一下，很可能這種東西將會取代目前的電話系統喔！

剛剛看了過去的文章，我發現我們目前使用的工具還是跟2001年使用的工具一樣：Apache、PostgreSQL、PHP、Proftpd。不過撰寫的程式複雜程度已經不是當年可以比擬。

這幾年來主要的程式發展成果就是一套網頁產生器，一套留言版、公佈欄的複合程式等，可以到信望愛站ftp site中取得
ftp://ftp.fhl.net/pub/FHL/CGI/

另外，除了以上的網頁程式之外，我們還做了一套CBOL計畫，這套系統裡面處理了中文與希伯來文、希臘文的混合顯示，算是難度比較高的系統。

近幾年來我們主要都是使用PHP作為開發工具，不過最近也有同工認為我們該慢慢的走向JavaServer Page ，而其實PHP5的語法，也跟Java慢慢的一致起來了，所以我們也很有可能開始架設TomCat，試著轉換開發工具。

在資料庫方面，我們一向用PostgreSQL當成主要的資料庫，不過我們為了架設搜尋引擎，所以被逼著不得不架設MySQL資料庫（因為目前Open Source的搜尋引擎，大多以MySQL為主要的資料庫）。既然架都架了，總也要花點時間來瞭解一下，所以我想未來信望愛站應該是PostgreSQL 與MySQL並重的狀況。

近幾年來，信望愛BBS站最大的改變，就是引進了Web-BBS。我們摒棄CGIC，改用PHP來開發。因為用C來寫網頁程式實在是太痛苦了，PHP這種工具比較容易入手，也比較適合於開發網頁程式。

我們的Web-BBS的開發原則就是「不更動原來的BBS程式」，資料結構完全採用telnet BBS的設計。不過既然要開發Web-BBS，我們還是提供了有限度的多媒體功能，讓使用者可以上傳多媒體檔案。在介面設計上，我們採用「範本」的方式， 將使用者介面與程式主體分開，甚至可以提供「多介面」的展示方式。主體程式可以由 ftp://ftp.fhl.net/pub/FHL/BBS 中取得。

我們另外也加上了一些個人性的網頁服務，提供個人的公佈欄與blog等功能。這些服務都是希望讓我們自己的眼界可以由telnet BBS跳脫出來，看到網頁世界的需求。

目前，信望愛BBS更根本的問題是我們用的 telnet BBS 已經太過老舊，實在需要加以更新，當然，連帶的Web-BBS的核心也可能需要跟著修改，這是我們未來要努力的目標與方向。

基本上，我們還是靠L5來做檔案系統的安全性防護，不過以往我們都是透過軟碟片來記載檔案的「指紋」，現在則是因為系統檔案變多了，軟碟片已經裝不下，只好另外想辦法了。

目前，我們改用USB隨身碟來做「可防寫的指紋記載媒體」。價格當然比磁碟片高了不少，不過因為一時也想不到什麼其他更好的代用品，只好這樣處理了。

雖然，隨著技術的進步，網路設備已經漸漸的變成以Switch為主流，不過監聽與入侵的技巧仍然日新月異，一不小心仍然會被入侵成功。自從好幾年前被入侵 過一次之後，信望愛站到目前並沒有被入侵成功過（或者被入侵而我們不知不覺？呵呵！），但是我們可以由系統記錄中知道入侵的意圖是從來沒有停過。所以，網 路安全的維護仍然是我們很重要的課題。

以往，我們以為換了Switch就比較不容易被監聽，後來，才發現利用「man in the middle」技術照樣可以監聽。使用防火牆可能可以減少入侵的機會，但是如果port 80、25、110、143跑的程式有問題，用防火牆也沒用，所以：「處處加密、時時補破洞」成為我們維護網路安全的基本哲學。還好，這幾年來網路防護的 免費技術與免費資源也增加了，所以我們可以有足夠的武器與入侵者對抗。

進系統，我們用putty取代telnet，要拿資料，我們用 winscp取代ftp。更進一步的，收信（IMAP或POP3）、發信（smpt），我們也都使用ssl加密。目前Fedora的郵件套件都可以直接使 用IMAP、POP3、smtp over SSL的技術，我們用起來也就不必像以前一樣，必須透過一些特殊的tunnel程式來協助，可以輕鬆的直接設定即可。

對一般使用者來說，好像還不是非常習慣網頁的SSL保密機制，不過如果使用webmail等系統，還是很有可能會造成密碼外洩。不管怎樣，我們還是加上了SSL的保護，並且鼓勵使用者用加密的連線來收信。

最後，因為有許多使用者是共用著信望愛站，所以如果任何一個帳號被破解、入侵，都有可能對其他使用者帶來災難。所以我們一向不隨便開放PHP、CGI等程 式功能。不過面對使用者的需求，我們好像也不能永遠都拒絕開放這些比較有危險性的功能，所以我們未來將開始研究user mode linux等jail技術，希望把一些比較危險的使用者關進虛擬機器中，這樣就可以保護其他的使用者不受影響了。

RedHat宣布不繼續推出免費的OS套件後，信望愛站技術組真的花了一段時間來研究下一步該怎麼走下去。我們考慮過換成FreeBSD，換成其他 Linux套件，當然也考慮過購買商業版的RedHat作業系統套件。不過，最後我們還是選擇了Fedora，目前我們使用Fedora Core 2。

老實說，我們是因為捨不得放棄已經熟悉的系統，所以才繼續使用與RedHat關係密切的Fedora Core 2。不過我們之前一版的作業系統套件是RedHat 7.3，與Fedora Core 2 版本差距很遠，所以我們由Fedora Core 1就已經開始測試新系統的穩定度，瞭解新系統的管理與運作方式，真正下定決心要全面更換，則是Fedora Core 2推出之後。

目前，我們才剛換系統不久，也說不上非常瞭解Fedora Core 2。不過初步覺得這個系統比RedHat 7.3更好用，其中yum這個套件可以補足rpm的缺乏，提供更有效的套件管理功能，這算是讓我們覺得很滿意的事情。其他的部分，則是需要整個技術團隊花 時間去瞭解與熟悉的了。

未來，我們會花時間去研究一下 user mode linux 這類的jail技術。因為我們居然發現機櫃空間已經不夠用了，我們可能會需要一、兩台機器做些其他的用途（有時僅僅是希望把危險的服務與其他系統隔離起 來），但南、北兩機房的機櫃都已經滿了。而且為了一點小需求，就使用一台伺服器好像有點誇張，所以我們將花一點時間去研究jail技術，希望未來在我們的 主要伺服器中可以跑幾台虛擬的機器，這樣我們的硬體就具有更高的使用效率了。

機櫃為什麼會滿了呢？其實是因為我們沒有料想到有那麼一天我們需要那麼多的伺服器，所以為了省錢，我們買的（其實那些機器根本就是我們自己拼裝的）機器都是U數比較高的（比較厚的），當時省了錢，現在就反過來逼著我們要去學習怎樣架設、管理虛擬機器了。呵呵！

最近我們發現原先拿來備份用的60G 2.5吋硬碟已經不夠用了，需要考慮更大容量的備份設備。我們考慮再三，發現2.5吋的硬碟有一段時間沒有降價了，所以我們還是犧牲一下自己的方便性，改用3.5吋的硬碟配合USB 2.0外接盒。

3.5吋的硬碟外接盒一定要外接電源，無法直接使用USB的電源驅動，而且體積比較大。不過目前200G的3.5吋硬碟也不到五千元台幣，算起來實在很划算。所以我們就決定改用這個解決方案了。

以往我們只著重在資料備份，期待系統出問題之後，能夠盡快的復原。隨著網路資源的增加，我們更往前走了一步，引進了備援的觀念，希望在單一硬體或線路出問題時，系統還可以繼續運作。

基於這個備援的理念，我們在台北也成立了機房，每個機房並配置有兩條對外線路。對單一機房而言，透過routing table的設定（這個需要用到policy route的技術）與DNS的調整，可以在單一線路回報失誤（透過簡訊）時，短時間內就將所有的服務全部改由另一條線路進出。當然，這樣會造成反應速度降 低，但總比什麼都沒有來得好（如果真的是對外網路斷線，修復常常是需要一天左右的時間）。

對於南北兩機房而言，平日我們就透過rsync一類的程式將資料備份到兩邊，然後必要的時候就透過DNS的指向來讓使用者看到另一個機房的資料。當然，這 部分其實也牽涉到DNS的組態問題，我們目前還沒有完全建置完成（DNS自動fail over部分），不過我們將會盡快完成這部分的設定。未來，我們也希望多幾個備援的機房，而且最後在台灣之外，這樣才能確保資料的安全無虞。

這幾年來我們發現磁帶設備，其實並沒有如想像中的穩固耐用。我手邊的兩台磁帶機都已經壽終正寢，而壽終正寢前都出現過幾次磁頭髒了卻無法清潔，只好送廠維 修的狀況。再者，磁帶機的容量相對於信望愛站的容量，實在是太小了，速度也太慢了，所以我們改用USB 2.0配合外接式2.5吋硬碟來備份。

相對於磁帶價格，一個2.5吋硬碟的單價還是很高，所以我們不可能用一個硬碟只備份一份資料。再加上硬碟的速度遠比磁帶快，於是我們引進了增量備份 （incremental backup)的觀念，平日只備份變動的資訊，週日才備份整個的資料。這樣我們用兩個60G的 2.5吋硬碟可以備份兩個月的資料。

為什麼用2.5吋的硬碟呢？主要是希望執行備份的人可以輕鬆的攜帶，安裝也會比較簡易一些。如果用3.5吋的硬碟，那就必須外接電源，雖然價格比較便宜，但是就會浪費執行備份的人的時間。我們目前是每週更換一次備份硬碟，並將離線的備份硬碟放在距離機房有相當距離的地方。

使用USB 2.0的設備的確是讓我們擁有快速的備份與備份取回的能力，不過其穩定性似乎還沒有達到一定的水準。我們必須精心搭配連接線、外接盒才能得到穩固的備份品 質。不過除了這些偶爾的小問題之外，整體而言用硬碟備份還算是一個不錯的解決方案，我們應該會持續使用一段時間。

順便把一些失敗的經驗跟大家報告一下：我們用過DVD燒錄設備，但是Linux似乎沒有辦法穩定的處理DVD燒錄設備，甚至造成系統當機。弄到最後只好靠 技術人員手工將備份資料down load到windows系統中燒錄，這樣簡直就是一種折磨。再加上DVD燒錄片的容量並不是很大（4.7G），所以很快的我們就放棄這個解決方案。

我自己在學校的備份，是使用3.5吋的USB 2.0硬碟外接盒，不過Linux似乎會挑設備。某些硬碟配合外接盒就是不能在Linux上穩定的使用（在windows上倒是可以穩定的使用），有些機 器則是根本無法在Linux上使用硬碟外接盒，所以看起來Linux似乎也還有一些相容性的問題必須要解決。相信這些問題，未來都會被解決，但是目前仍然 是一個困擾就是。

其實，「便宜、強大、穩定」一直是我們的硬體策略，不過離開學生時代越遠，我們越瞭解「時間」也是一個很重要的成本，越懂得不要去計較那三、五百塊錢，而換得更快速的問題解決方案，以節省技術人員的時間並降低系統當機時間。

不過，因為信望愛站的技術組中有一位硬體的DIY高手，所以我們主機的組裝、維修與整理還是可以自己來，不過如果缺乏這樣的DIY高手，我們可能就會改用現成Server硬體，而不再自己拼裝了。

至於硬體的品牌，我們倒是不怎麼挑剔。除了主機要考慮散熱問題外，其他的設備多半相當穩定可靠，我們都是購買市場上熱賣的「中上」等級的產品來使用，並不追求名牌。我剛剛去看了一下舊文章發現我們好多硬體都已經用了三、四年，卻還工作正常，所以算起來這個硬體策略算是成功的。

講到硬體設備的維修，其實最討厭的就是風扇了，每每兩年一到，系統的風扇就會出現雜音、甚至停止轉動。我們裡面的DIY高手教了我們一個訣竅：在安裝新硬 體或新風扇之前，先把風扇的商標標籤取下，將軸心添加點黃油，然後這個風扇的壽命就會延長很多。我們利用歲修的時候，把信望愛南站內所有的風扇（包括 UPS的）都換新並且加黃油，目前就一切運作正常，或許兩年後我們又可以來檢驗看看風扇是否壽命延長了。

另外，由於目前的系統速度越來越快，我們也發現常常不穩定的來源居然是「線」。前一陣子我們就被SCSI的外接排線搞死了，系統三天兩頭當機，最後換了高 檔的排線，ㄟ！就穩定下來了。我想未來我們使用的各種線材，一定要用高檔貨，不然為了這點小錢，讓系統處於不穩定的狀況，實在是得不償失。

舊文章提到我們用華碩的板子來測試系統是否更為穩固，結果答案是否定的。時間一到，還是漸漸不穩定了。也許好廠商的板子會壽命會持續久一點，不過我們還是 感覺不到有很明顯的差距就是。未來，我們應該還是會買好一點的主機板，不過我們也不會期待名牌的板子可以讓我們的系統長治久安就是。現在信望愛站的主機板 是雜牌軍，因為有位曾在主機板製造廠工作的網友奉獻給我們一塊主機板，我們自己為了應急也去買了板子，所以就亂了套了。其實也無妨，反正能穩定的用就好 了。

最近為了備份，我們引進了USB 2.0的外接式硬碟，USB 2.0速度頗快，對硬體設備也成了新的挑戰。我們的USB 2.0備份外接盒壞了不少次，其間因為線路品質問題或者沒有插好也曾經造成系統不穩。雖然我們覺得USB 2.0還是目前備份的最佳選擇，不過這種剛出來的高速I/O設備還是需要多注意其穩定性的。

說起來，Intel的網路卡是我們的硬體設備中最長壽的，到現在大概五、六年了還沒壞掉，呵呵！UPS也還不錯，除了電池與電風扇更換過之外，主體倒是沒 有損壞過。對於UPS的停電偵測，我們最後採取了一個低級的解決方案：「用無線AP不接UPS測試市電是否停止供應」。其實用任何一個具有IP的設備來測 試都可以，只是我們機房正好需要無線網路，就順便使用無線AP來當UPS停電測試設備。只要寫個script，定期去測試無線AP的IP是否會通即可知道 有沒有停電。

會用這種低級的方法，是因為目前的UPS並沒有什麼統一的協定。不管用什麼解決方案都必須搭配每個不同廠牌的UPS的不同協定，實在是太過麻煩了。說起來 我們也不需要監測UPS的電容量或電壓一類的細節資訊，只需要知道何時停電，然後停電四小時之後要自動關機，四小時之內電來了就自動停止關機，這種需求根 本用不到太精細的監測數據。

另外，我們也把簡訊通報整合進系統之中，UPS斷電或者網路斷線，系統都會自動以簡訊通報技術人員。簡訊系統是個很麻煩的東西，跟UPS一樣，各家有各家的協定，還好我們只要鎖定一家，寫完了就用那家的簡訊就是。

最後，我們以往都使用多個硬碟的外接式RAID，跑RAID 5來當我們的主要儲存解決方案。可是硬碟技術的進步真的太快了，一開始我們使用SCSI硬碟的RAID，後來改用IDE硬碟的RAID（就節省了大約一半 的經費）。現在，一個IDE硬碟容量就到達 400 G，根本就超越過去整個RAID的容量。再加上目前頻寬還是整個系統中主要的瓶頸，所以我們就勇於引進兩個IDE硬碟的外接式SCSI Mirror RAID。跑RAID 1（mirror模式）來當我們的主要儲存解決方案，這樣價格立刻降為SCSI硬碟 RAID的十分之一。還用外接式，是希望我們可以快速的抽換主機接線，不用IDE介面（雖然內部硬碟用IDE硬碟）是因為我們的系統中還跑BBS，需要反 應速度快一點的解決方案。想到我們過去推動RAID專案，籌錢籌得苦哈哈，現在輕鬆就可以擁有大容量的安全儲存專案，真的是難以想像的一件事。快速的調整 硬體策略，真的是節省經費的重要關鍵。