tjm | 24 十二月, 2006, 20:03 |
會議記錄 | (641 Reads)
進度報告：
ksf:bbs raid維修完成（主要是電源劣化），系統已經穩固沒有錯誤信息了。下次如果再壞掉，就考慮用外接電源解決。
下週預計進度：
joshua:開始處理錄音剪接問題，tjm：DNS管理程式 ，ksf:詢問hinet頻寬提昇計畫
Trackback URL: http://blog.fhl.net/trackback.php?id=51
tjm | 17 十二月, 2006, 22:01 |
維修公告 | (607 Reads)
今天BBS、Bible這台機器的RAID出了問題，連續當機兩次，原因不明，造成bible.fhl.net的資料大量損毀。因此我們已經緊急由北美站把資料救回來 ，不過springbible.fhl.net的資料也造成損毀，得要由備份中取回（我正在努力中）。
我們已經聯絡廠商，預計2006年12月18日下午進行維修，屆時可能會有不定期的停機，還請大家多多包涵。
Trackback URL: http://blog.fhl.net/trackback.php?id=46
tjm | 07 十二月, 2006, 23:27 |
維修公告 | (714 Reads)
本週六（9/12/2006）晚上我們將進行 bbs與life機器的系統重開測試。
這是為了檢驗系統重開網路線是否會互換。如果一切正常，應該十分鐘之內就會復原。
另外如果可以買到新SCSI卡，我們也會利用tech進行 SCSI卡安裝測試，這時候tech將會有一段時間的不穩定。這將不會影響bbs與life的系統穩定度。tech如果運作正常之後，我們才會擇期對bbs與life進行SCSI卡更換作業。
另外，使用信望愛站服務的人可以考慮訂閱這個分類的RSS，我們會將維修公告發佈在這裡。
Trackback URL: http://blog.fhl.net/trackback.php?id=42
tjm | 03 十二月, 2006, 19:32 |
會議記錄 | (759 Reads)
進度報告：ksf與tjm已經完成UPS線路改接，將機櫃的門關起來了。tjy處理php換到最新版。
由ksf去詢問RAID內部scsi架構，並視情況採購 LSI SCSI介面卡一張，裝在tech上測試
由ksf去詢問Hinet頻寬提昇的作法與狀況
建議將中古的UPS二手賣出，帳目問題再與基金會討論
由birdy處理系統重新開機，網卡會亂換的問題
建議：以後維修多利用blog互相溝通，以免大家看到錯誤信息會緊張。
Trackback URL: http://blog.fhl.net/trackback.php?id=37
tjm | 01 十二月, 2006, 22:28 |
技術小抄 | (845 Reads)
以下介紹如何裝設 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
然後就可以去看是否產生流量統計圖表了
以上是參考自 這裡
Trackback URL: http://blog.fhl.net/trackback.php?id=36
tjm | 01 十二月, 2006, 11:58 |
技術小抄 | (362 Reads)
以下介紹如何裝設 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>
Trackback URL: http://blog.fhl.net/trackback.php?id=34
tjm | 29 十一月, 2006, 17:01 |
admin | (967 Reads)
這個部份我們還不是做得很好，嚴重的錯誤還是要人跑到機房去處理，不過為了節省跑機房的時間，我們還是做了一些努力。
我們去買了一個可以用電話控制電力的裝置，當電話打進去之後，系統會詢問密碼，密碼正確以後就可以用電話按鈕選擇把四個port中的任何一個port打開或關閉。因此我們會把最容易當機的系統接在這個裝置上，透過關閉電源再打開來復原系統。我們通常都是用這招來對付ADSL的ATUR（小烏龜），說起來還蠻有效的，反正現在大家都有手機，收到系統回報網路斷線之後，就撥一撥號碼、按按幾個鍵，系統就自動恢復正常了，真是物超所值（好像才四千塊錢吧）。
信望愛站為了系統的穩定，裝了兩條網路線，還分屬於不同的ISP ，因此理論上可以做到很好的fail over功能。目前我們是透過script去控制 default route自動偵測設定的方式來做到基本的斷線備援，但是DNS的fail over部份還沒有完成，目前還是得要靠人力手工來處理，未來應該會慢慢的把這部份納入系統之中。不過這部份真的是比較困難，要寫程式的話也必須寫得比較複雜，因此短期內可能還不會完成。
Trackback URL: http://blog.fhl.net/trackback.php?id=33
tjm | 29 十一月, 2006, 16:31 |
admin | (990 Reads)
當然，理想上最好系統能夠做到完整的自動錯誤偵測功能，不過事實上因為各樣的因素影響，我們都只會去偵測最重要的錯誤，然後進行回報罷了。
前一篇我已經談過了自動錯誤回報系統，現在來談談怎樣進行錯誤偵測。信望愛站的錯誤偵測功能，主要是針對主機的網路服務是否正常、線路是否暢通與UPS是否已經啟動這三部份來運作。至於偵測的方法，則是利用ping，以及開啟socket連線的方式來完成。
主機的網路服務當然就是透過 socket連線的方式來偵測，網路暢通與否則是透過ping gateway的方式來偵測，至於UPS的話，我們是透過設定一台不連接UPS的IP分享器，然後定期去ping那台IP分享器，用以決定市電是不是已經停電了。這樣的方式比傳統利用RS-232或SNMP協定的方式更為簡單便宜，不需要購買特殊的UPS。
我們利用 php 寫成的 ping script: ping.txt
我們利用php寫成的 socket檢測程式：detser.txt
希望對大家有幫助。
Trackback URL: http://blog.fhl.net/trackback.php?id=32
tjm | 22 十一月, 2006, 22:10 |
admin | (1150 Reads)
信望愛站的狀況特殊，所有的技術人員都不在機器旁邊上班，所以我們非常需要系統能夠自動回報錯誤的狀況，並且能自遠端處理掉最常發生的棘手問題。因為時間的關係，我先講一下我們錯誤回報的機制。
我們是採用手機簡訊的方式來進行錯誤回報，本來我們是透過「智邦生活館」的簡訊服務，後來改用「台灣簡訊」的服務，途徑是透過我們自己撰寫的php程式來呼叫這兩個服務的網站。台灣簡訊的網站比較容易控制，智邦生活館的系統還需要先騙過asp程式才能運作。不過後來我們發現PHS的電子郵件可以用來發免費簡訊，因此我們在高雄的技術人員也開始利用PHS的電子郵件來進行自動錯誤回報的動作。不然有時候網路發生瞬斷，一下子就發出了好幾封簡訊，那我們可是會非常痛心的（每一通都是好幾塊錢台幣ㄟ！而且是自己的錢，不是公款）。
錯誤回報的方式，就是設定伺服器的Cron，每隔一段時間就去檢查某個功能是否能夠正確的運作，如果不能正常運作，就選定一條可以通的網路，把發簡訊的命令送往相關的伺服器。對了，為了經濟的因素，我們也還設定了「不准重複發送」的機制，免得技術人員虧本虧慘了。又因為我們常常是多個技術人員一起關心幾台機器，所以系統在檢查到機器由錯誤狀況復原後，也會發送「系統ok」簡訊給每一個技術人員，以免大家掛心或採取重複的維修工作。
台灣簡訊的發送 script 在 bbc.txt
智邦生活館的發送 script 在 bbc_url.txt
PHS 就用 /bin/mail -s "要送的簡訊" xxxx@phs.com.tw 就可以了
不過記得要先有那些服務的帳號才行 。
Trackback URL: http://blog.fhl.net/trackback.php?id=29
tjm | 13 十一月, 2006, 23:38 |
admin | (994 Reads)
信望愛站的技術組，每週都要進行遠距會議，以前我們都用
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套件外，也有一些硬體解決方案存在。這種東西長的很像電話，只要接上網路就可以打免費或者是便宜的網路電話。這些硬體的解決方案跟目前使用者的使用習慣很接近，
理論上會大大的流行，無奈目前價格還是太高，高到一般人不想買回家試一試（連我這種喜歡網路科技產品的人也不想花錢買回家玩）。未來倒是可以注意一下，很可能這種東西將會取代目前的電話系統喔！
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套件外，也有一些硬體解決方案存在。這種東西長的很像電話，只要接上網路就可以打免費或者是便宜的網路電話。這些硬體的解決方案跟目前使用者的使用習慣很接近，
理論上會大大的流行，無奈目前價格還是太高，高到一般人不想買回家試一試（連我這種喜歡網路科技產品的人也不想花錢買回家玩）。未來倒是可以注意一下，很可能這種東西將會取代目前的電話系統喔！
Trackback URL: http://blog.fhl.net/trackback.php?id=23
