升級成 FreeBSD 10.1 版後,因為 mail/openwebmail 配合 port mail/spamassassin 裡的 net-mgmt/p5-NetAddr-IP port 一直都無法安裝完成,所以只好暫時尋找替代的網路信箱程式。發現 squirrelmail 的中文化成度似乎比較好,國內也有很多使用者經驗可以參考,所以決定換裝這個伺服軟體替代。Mailserver 還是以 FreeBSD 裡預設的 sendmail 做服務,對這個套件的設定比較熟,也不用再吃新苦頭。
因為 mail/squirrelmail 需要 IMAP server 配合,所以搭配了 mail/imap-uw 一起工作。imap-uw 的設定在 inetd 裡,修改 pop2/ pop3/ imap 的服務後,在 /etc/rc.conf 裡寫入 inetd_enable="YES",以後開機就會配合開起來。
Squirrelmail 裝好,依照說明完整的設定後,一直無法在瀏覽器上順利開啟服務,網頁總是跑到一半就停止,無法讀取信箱的內容。網頁上顯示錯誤訊息 [ERROR : Connection dropped by IMAP server.]。一直以為問題發生在 IMAP server 上,可是重新安裝、重新設定還是無法解決問題。
進一步檢視了 SquirrelMail 提供的 configtest 檢查頁面裡頭顯示息 [ERROR: You have configured PHP not to allow short tags (short_open_tag=off). This shouldn't be a problem with SquirrelMail or any plugin coded coded according to the SquirrelMail Coding Guidelines, but if you experience problems with PHP code being displayed in some of the pages and changing setting to "on" solves the problem, please file a bug report against the failing plugin. The correct contact information is most likely to be found in the plugin documentation.]。卻也沒有人提供經驗如何修改 short_open_tag=off 的設定。寫了信去尋求 port maintainer 協助也沒有改進的建議。
這問題持續了好久,後來在 MailServerIMAPProblem 頁面裡找到答案,只要把 php.ini 裡頭的 default_socket_timeout 時間給延長就可以了。網頁裡說 例如 600,所以就改 600 (10 分鐘)。
# ee /usr/local/etc/php.ini
default_socket_timeout=600
存檔後重起 Apache 就可以順利進入網路信箱的服務功能。相較於 openwebmail 的開啟速度,squirrelmail 真的是慢太多了。
MailServerIMAPProblem 裡還有提到另兩個解決的方法,不過沒試過,應該也會有效。
(1) If you want to increase the timeout in SquirrelMail 1.x go to line 444 of functions/imap_general.php and change the last parameter of the fsockopen() call from 15 [seconds] to something larger. Keep in mind that if you increase this, you may also need to increase the "max_execution_time" parameter in your php.ini file.
(2) Instead of the previous fix, you should add the following line at line 445 of functions/imap_general.php so that the stream doesn't time out while fgets() is waiting:
stream_set_timeout($imap_stream,600); // wait max 10 minutes for IMAP request to complete
這裡該放些容易忘記的東西。那些 FreeBSD 主機架設過程的紀錄,那些靈光乍現的突發性理財觀點,怎麼從網路上賺錢的方法,或是玩玩電腦的失常記錄。就擺這些類老人健忘的文字在這裡。
星期六, 3月 14, 2015
星期六, 12月 13, 2014
主機連續運轉紀錄達 1010 天
這兩天才發現主機運轉紀錄已經超過 1000 天了,這可是個不容易達成的紀錄。一來是 FreeBSD 的穩定性無可挑剔,再來是得對系統升級的通知視若無睹,才有辦法不重開機讓主機一直不停的跑。還要有一台好的 UPS 可以確保供電的穩定,撐過台電不太長的維修停電。Redeye 的主機沒有太多的工作,當 mail、www、FTP 伺服而已。覺得這個紀錄不容易,備註一下。
最近看到 /var/log/messages 裡有這些怪怪的紀錄,除了如 sshd[58217]: error: PAM: authentication error for root from xxx-xxx-xxx-xxx 這類的嘗試連線紀錄外,還有另一種不一樣的。
# cat /var/log/messages
...
Dec 9 17:14:42 named[89370]: clients-per-query decreased to 44
Dec 9 17:33:20 named[89370]: clients-per-query increased to 49
Dec 9 17:53:20 named[89370]: clients-per-query decreased to 48
Dec 9 17:53:28 named[89370]: clients-per-query increased to 53
Dec 9 18:03:50 named[89370]: clients-per-query increased to 58
...
Dec 9 20:36:00 named[89370]: clients-per-query increased to 61
Dec 9 20:44:37 named[89370]: clients-per-query increased to 66
Dec 9 21:04:37 named[89370]: clients-per-query decreased to 65
Dec 9 21:24:37 named[89370]: clients-per-query decreased to 64
Dec 9 21:44:37 named[89370]: clients-per-query decreased to 63
Dec 9 22:04:37 named[89370]: clients-per-query decreased to 62
...
Dec 10 00:44:37 named[89370]: clients-per-query decreased to 54
Dec 10 01:04:37 named[89370]: clients-per-query decreased to 53
Dec 10 01:24:37 named[89370]: clients-per-query decreased to 52
Dec 10 01:44:37 named[89370]: clients-per-query decreased to 51
Dec 10 02:04:37 named[89370]: clients-per-query decreased to 50
...
看來都是針對 DNS 服務來的,算是對這個小小網站所進行的無聊攻擊。
由於 FreeBSD 已經停止對 9.0-RELEASE 做維護服務,Ports 無法繼續更新。要透過更新 ports 來修補 BIND 已經是不可能。考慮把 DNS 的功能停掉,讓 GoDaddy 域名公司的服務來指定就好了。
這台主機還有機會再繼續運轉另一個 1000 天嗎?
最近看到 /var/log/messages 裡有這些怪怪的紀錄,除了如 sshd[58217]: error: PAM: authentication error for root from xxx-xxx-xxx-xxx 這類的嘗試連線紀錄外,還有另一種不一樣的。
# cat /var/log/messages
...
Dec 9 17:14:42 named[89370]: clients-per-query decreased to 44
Dec 9 17:33:20 named[89370]: clients-per-query increased to 49
Dec 9 17:53:20 named[89370]: clients-per-query decreased to 48
Dec 9 17:53:28 named[89370]: clients-per-query increased to 53
Dec 9 18:03:50 named[89370]: clients-per-query increased to 58
...
Dec 9 20:36:00 named[89370]: clients-per-query increased to 61
Dec 9 20:44:37 named[89370]: clients-per-query increased to 66
Dec 9 21:04:37 named[89370]: clients-per-query decreased to 65
Dec 9 21:24:37 named[89370]: clients-per-query decreased to 64
Dec 9 21:44:37 named[89370]: clients-per-query decreased to 63
Dec 9 22:04:37 named[89370]: clients-per-query decreased to 62
...
Dec 10 00:44:37 named[89370]: clients-per-query decreased to 54
Dec 10 01:04:37 named[89370]: clients-per-query decreased to 53
Dec 10 01:24:37 named[89370]: clients-per-query decreased to 52
Dec 10 01:44:37 named[89370]: clients-per-query decreased to 51
Dec 10 02:04:37 named[89370]: clients-per-query decreased to 50
...
看來都是針對 DNS 服務來的,算是對這個小小網站所進行的無聊攻擊。
由於 FreeBSD 已經停止對 9.0-RELEASE 做維護服務,Ports 無法繼續更新。要透過更新 ports 來修補 BIND 已經是不可能。考慮把 DNS 的功能停掉,讓 GoDaddy 域名公司的服務來指定就好了。
這台主機還有機會再繼續運轉另一個 1000 天嗎?
星期四, 10月 16, 2008
FreeBSD 主機連續運轉 375 天誌念
今天凌晨一場無預警的停電後,Redeye 原本想讓主機無限期不關機的計畫就破滅了。雖然幫主機加上了 1000 VA 的 UPS 當後援,無奈這個超過 1 小時的停電還是耗盡了 UPS 所能預備的極限能量,主機還是得乖乖的睡覺去。翻了翻主機的日誌,停電前系統還是很盡責的發了信,從信裡頭可以看到,系統最後紀錄是凌晨 3 點的時候,那時主機已經連續運轉了 375 天又 12 小時 38 分 (有圖有真相)。log 如下:
"Local system status:
3:01AM up 375 days, 12:38, 0 users, load averages: 1.13, 1.03, 1.00"

嗯,既然連續紀錄都已經暫停了,Redeye 連想到的是主機需不需要『歲修』呢?是不是把機殼給開了,用吸塵器把裡頭的灰塵都清一清呢?還是一不做二不休的趁機會把系統升級到 Ver 7.0 呢 (7.1 beta 就快來了)?
話說回來台電真無情,一年來啥大風大雨沒發生過,就沒同時發生過停電。竟然在無風、無雨、無地震的時候來個半夜無預警停電,唉,Redeye 的心願,殘念。
"Local system status:
3:01AM up 375 days, 12:38, 0 users, load averages: 1.13, 1.03, 1.00"
嗯,既然連續紀錄都已經暫停了,Redeye 連想到的是主機需不需要『歲修』呢?是不是把機殼給開了,用吸塵器把裡頭的灰塵都清一清呢?還是一不做二不休的趁機會把系統升級到 Ver 7.0 呢 (7.1 beta 就快來了)?
話說回來台電真無情,一年來啥大風大雨沒發生過,就沒同時發生過停電。竟然在無風、無雨、無地震的時候來個半夜無預警停電,唉,Redeye 的心願,殘念。
星期日, 7月 01, 2007
FreeBSD 上的 Malaria Control 程式停跑了

最近 ssh 進主機的時候發現伺服器大半的時間都閒著,用 top 指令看狀態,竟然有 99.5% 的資源是 idle 的,原本以為只是暫時的現象,今天找了空檔認真給它研究一下,結果竟然是 Malaria Control 程式停掉了才發生這現象。
這可不太符合成本效益了,一台伺服器掛著 24 小時都沒停,啥事都不做,豈不是太浪費電了?所以之前去認領了個計畫,免得伺服器掛在那裡光是吃電,等一天不到 10 封的信件 + reject 一天數十封的垃圾信件,當然還有幾乎沒有提供網頁資訊的 www 服務,徒然增加大氣層的二氧化碳含量卻無任何建樹。因此把伺服器加入了 BOINC 架構下的 Malaria Control 計畫,這是個幫助非洲國家控制瘧疾疫情的監測計畫,透過模擬的推估,進而加以抑制瘧疾的擴散,利用這樣的虛擬情境來控制瘧疾擴散說來有點玄,不過身為地球村的一員,與其放著伺服器吃電,還是分配點工作給它好。
從分析圖裡可以知道 Malaria Control 程式已經掛了大概一個星期了,23-24 / Jun 期間就停擺了,而且因此導致排名一直向後退,目前是全世界的 249 名,不把名次給找回來怎行。把整個流程檢視了一下,malariacontrol.net 的 Server status 是正常的,只是我的伺服器沒法子去抓到工作下來分析而已,所以問題一定就發生在對應的程式上。果然沒錯,停跑的原因竟然是程式升級了 (malariacontrol_5.45_i686-pc-linux-gnu => malariacontrol_5.50_i686-pc-linux-gnu) 可是沒接到通知,所以只好自己手工給它下載來升級。這可真是個奇怪的計畫,升級的訊息沒通知,那要是都不看主機訊息的主人,就永遠不會接續這個計畫了,malariacontrol.net 的計畫不就無限期停擺?
從 malariacontrol.net 官方網站的資訊裡發現,全台灣好像只有我這麼一部伺服器是用 FreeBSD 系統來跑這個計畫的,這可真是難得。假如有誰的 FreeBSD 主機也想 RUN 這個計畫,可以留訊息給我,討論怎麼讓你的伺服器不要只是光吃電卻對地球沒貢獻,這我可是絕對樂意交換經驗的事情。呵呵。
這可不太符合成本效益了,一台伺服器掛著 24 小時都沒停,啥事都不做,豈不是太浪費電了?所以之前去認領了個計畫,免得伺服器掛在那裡光是吃電,等一天不到 10 封的信件 + reject 一天數十封的垃圾信件,當然還有幾乎沒有提供網頁資訊的 www 服務,徒然增加大氣層的二氧化碳含量卻無任何建樹。因此把伺服器加入了 BOINC 架構下的 Malaria Control 計畫,這是個幫助非洲國家控制瘧疾疫情的監測計畫,透過模擬的推估,進而加以抑制瘧疾的擴散,利用這樣的虛擬情境來控制瘧疾擴散說來有點玄,不過身為地球村的一員,與其放著伺服器吃電,還是分配點工作給它好。

從分析圖裡可以知道 Malaria Control 程式已經掛了大概一個星期了,23-24 / Jun 期間就停擺了,而且因此導致排名一直向後退,目前是全世界的 249 名,不把名次給找回來怎行。把整個流程檢視了一下,malariacontrol.net 的 Server status 是正常的,只是我的伺服器沒法子去抓到工作下來分析而已,所以問題一定就發生在對應的程式上。果然沒錯,停跑的原因竟然是程式升級了 (malariacontrol_5.45_i686-pc-linux-gnu => malariacontrol_5.50_i686-pc-linux-gnu) 可是沒接到通知,所以只好自己手工給它下載來升級。這可真是個奇怪的計畫,升級的訊息沒通知,那要是都不看主機訊息的主人,就永遠不會接續這個計畫了,malariacontrol.net 的計畫不就無限期停擺?
從 malariacontrol.net 官方網站的資訊裡發現,全台灣好像只有我這麼一部伺服器是用 FreeBSD 系統來跑這個計畫的,這可真是難得。假如有誰的 FreeBSD 主機也想 RUN 這個計畫,可以留訊息給我,討論怎麼讓你的伺服器不要只是光吃電卻對地球沒貢獻,這我可是絕對樂意交換經驗的事情。呵呵。
星期二, 3月 13, 2007
FreeBSD SSH 連線障礙排除
本來只是發現 NAT 內部的電腦連上主機的速度越來越慢,後來竟然連收發信都需要一等再等、一拖再拖,今晚的狀況更是離譜了,用 PUTTY 執行 ssh 怎麼都派不上用場,連 WINSCP 都無法進入,連續『噹噹噹』的給它噹了一整晚,苦惱。原本以為是外頭的封包又來轟炸才導致這現象,先前幾天有白目的來測試 FTP 意圖入侵,一直沒給她得逞,不過連到系統的速度倒是因此而產生的 lag 浪費了不少等候的時間,今晚的 log 說不是這現象造成的,不過一直連不上卻是不爭的事實,/var/log/messages 的紀錄裡這樣寫著:
...信也收不了...
Mar 13 00:19:39 redbsd qpopper[57028]: (null) at 192.168.1.168 (192.168.1.168): -ERR POP EOF or I/O Error
Mar 13 00:20:42 redbsd qpopper[57030]: (null) at 192.168.1.168 (192.168.1.168): -ERR POP EOF or I/O Error
Mar 13 00:21:43 redbsd qpopper[57047]: (null) at 192.168.1.168 (192.168.1.168): -ERR POP EOF or I/O Error
....接續... ssh 連不上...
Mar 12 23:04:25 redbsd sshd[56443]: fatal: Timeout before authentication for 192.168.1.168
Mar 12 23:07:50 redbsd sshd[56465]: fatal: Timeout before authentication for 192.168.1.168
Mar 12 23:09:38 redbsd sshd[56468]: fatal: Timeout before authentication for 192.168.1.168
Mar 12 23:12:53 redbsd sshd[56489]: fatal: Timeout before authentication for 192.168.1.168
Mar 12 23:15:15 redbsd sshd[56507]: fatal: Timeout before authentication for 192.168.1.168
....持續... endless...
為了讓連線暢通,只好重新啟動 sshd。首先需要 degug 一下,下 sshd -d 指令作工:
# sshd -d
debug1: sshd version OpenSSH_3.8.1p1 FreeBSD-20060123
debug1: read PEM private key done: type DSA
debug1: private host key: #0 type 2 DSA
debug1: Bind to port 22 on ::.
debug1: Bind to port 22 on 0.0.0.0.
Bind to port 22 on 0.0.0.0 failed: Address already in use.
Cannot bind any address.
看來 sshd 原來還是正常的工作著,因為 inetd 還是正常的跑著,所以 port 22 還是被佔用的狀態。不曉得是哪裡給它出了狀況,那重新啟動就會恢復正常的狀態了吧,先關了 sshd 再重新開啟它。
# killall sshd
# /usr/sbin/sshd
果然效果馬上看得見,不但 NAT 內的電腦馬上可以連進去主機,連收發的速度都恢復了以前的效率。後來查了一下 google 大神才知道有更方便的指令:
# /etc/rc.d/sshd restart
這樣也派得上用場的,ㄏㄏ。還好沒瞎忙一場,真怕就這麼不明不白的 sshd 給掛了,那以後得蹲小桌子前面才能查看主機的狀態,這才真的是苦惱。
...信也收不了...
Mar 13 00:19:39 redbsd qpopper[57028]: (null) at 192.168.1.168 (192.168.1.168): -ERR POP EOF or I/O Error
Mar 13 00:20:42 redbsd qpopper[57030]: (null) at 192.168.1.168 (192.168.1.168): -ERR POP EOF or I/O Error
Mar 13 00:21:43 redbsd qpopper[57047]: (null) at 192.168.1.168 (192.168.1.168): -ERR POP EOF or I/O Error
....接續... ssh 連不上...
Mar 12 23:04:25 redbsd sshd[56443]: fatal: Timeout before authentication for 192.168.1.168
Mar 12 23:07:50 redbsd sshd[56465]: fatal: Timeout before authentication for 192.168.1.168
Mar 12 23:09:38 redbsd sshd[56468]: fatal: Timeout before authentication for 192.168.1.168
Mar 12 23:12:53 redbsd sshd[56489]: fatal: Timeout before authentication for 192.168.1.168
Mar 12 23:15:15 redbsd sshd[56507]: fatal: Timeout before authentication for 192.168.1.168
....持續... endless...
為了讓連線暢通,只好重新啟動 sshd。首先需要 degug 一下,下 sshd -d 指令作工:
# sshd -d
debug1: sshd version OpenSSH_3.8.1p1 FreeBSD-20060123
debug1: read PEM private key done: type DSA
debug1: private host key: #0 type 2 DSA
debug1: Bind to port 22 on ::.
debug1: Bind to port 22 on 0.0.0.0.
Bind to port 22 on 0.0.0.0 failed: Address already in use.
Cannot bind any address.
看來 sshd 原來還是正常的工作著,因為 inetd 還是正常的跑著,所以 port 22 還是被佔用的狀態。不曉得是哪裡給它出了狀況,那重新啟動就會恢復正常的狀態了吧,先關了 sshd 再重新開啟它。
# killall sshd
# /usr/sbin/sshd
果然效果馬上看得見,不但 NAT 內的電腦馬上可以連進去主機,連收發的速度都恢復了以前的效率。後來查了一下 google 大神才知道有更方便的指令:
# /etc/rc.d/sshd restart
這樣也派得上用場的,ㄏㄏ。還好沒瞎忙一場,真怕就這麼不明不白的 sshd 給掛了,那以後得蹲小桌子前面才能查看主機的狀態,這才真的是苦惱。
星期日, 12月 10, 2006
FreeBSD 主機上 FON 機上線

12月4日寄來的 FON 機今天才有時間玩玩。機子看起來很小巧可愛,插上電源後卻發現溫度增加的嚇人,難怪這機子除了表面之外到處都是透氣孔。別忘了把機子掛在通風的地方以免失火 (呵)。
由於主機只有單一固定的 IP ,而且早就拿來架站,所以沒有其他的位址可以給 FON 使用,因此怎麼把 FON 掛在 FreeBSD 的主機上便成了新的小挑戰。首先需要增加的就是在主機上添加一張新的網卡給 FON 機使用,事實證明, FON 機不如想像中的聰明,它並不能自動抓到通訊閘道並且自動對應,所以光增加一張網卡並派不上用場。由於不知道 FON 機所使用的 IP 是多少,就算掛在新增加的網卡上也不能保證訊息可以溝通。所以下策就只好主動發放 IP 給 FON 機使用。這實在是個很奇怪的情形,FON 機本身就具有 DHCP 的功能,為了它的不夠聰明卻需要啟動 DHCP 的功能給他使用,真是怪怪的設定方式,假如 FON 機本身就有固定 IP 且公司願意提供,那設定就會方便許多。所以解決的方案就是加裝一張網卡並且啟動 DHCP 功能讓 FON 機的訊息可以透過主機對外的網卡與外界溝通。
我的作法:
新增一張 3com (xl) 的網卡並設定該網卡的位置為192.168.10.250,編輯 /etc/rc.conf 檔給予該卡一個 IP ,我用的是 ee,所以就開工吧。
# ee /etc/rc.conf
ifconfig_xl0="inet 192.168.10.250 netmask 255.255.255.0"
接著設定 NAT 服務並在 kernel 加入 ipfirewall 功能,讓透過 FON 進來的使用者沒有機會搗蛋。編輯 /etc/rc.firewall 設定進出規則,當然別忘了要讓 xl0 的封包自由通行,然後重新編譯 kernel 後重開機
開機完成後安裝 DHCP 服務
# cd /usr/ports/net/isc-dhcp3-server
# make install clean
這樣就裝完啦!接下來要設定 DHCP 的服務內容,首先建立設定檔。
# cp /usr/local/etc/dhcpd.conf.sample /usr/local/etc/dhcpd.conf
然後編輯它,設定分配的位址與指定的設定內容。
# ee /usr/local/etc/dhcpd.conf
加入以下設定:
# dhcpd.conf
#
# Sample configuration file for ISC dhcpd
#
# option definitions common to all supported networks...
option domain-name "xxxxx.org"; # 域名
option domain-name-servers xxx.xxx.xxx.xxx, xxx.xxx.xxx.xxx; # DNS 位址
option routers 192.168.10.250; # 子網路路由器(DHCP服務網卡 IP)
option broadcast-address 192.168.10.255; # 廣播封包位置
option perform-mask-discovery on;
option mask-supplier on;
option interface-mtu 1500;
default-lease-time 600; # 預設發放時間
max-lease-time 7200; # 最長的發放時間
ddns-update-style none; # 不處理 ddns
ddns-updates off; # 不處理 ddns
# 子網路、網路遮罩(以 192.168.10.xx 為例)與動態分配 IP 位置範圍
subnet 192.168.10.0 netmask 255.255.255.0 {
range dynamic-bootp 192.168.10.10 192.168.10.20;
}
# 動態分配 IP 位置範圍 192.168.10.10 到 192.168.10.20
因為位址只給 FON 機使用(1 個已經足夠),設定裡 11 個動態發放的位址已經比 FON 機需要的一個位址多出 10 個了,呵呵,反正是自己發放的,大方點吧。這樣一切 OK 了,為了讓 DHCP 在開機時自動啟動,把以下內容加到 /etc/rc.conf 檔裡。
dhcpd_enable="YES" # dhcpd enabled?
dhcpd_flags="-q" # command option(s)
dhcpd_conf="/usr/local/etc/dhcpd.conf" # configuration file
dhcpd_ifaces="xl0" # 使用的網卡代號
dhcpd_withumask="022" # file creation mask
接下來就啟動 DHCP 服務吧,不用再重開機囉!
# /usr/local/etc/rc.d/isc-dhcpd.sh start
檢查一下 DHCP 有沒有正常啟動:
#ps -aux dhcpd
假如顯示的訊息表示 OK,然後把 FON 機接上就可以啟動服務了。FON 機與網卡間的連線不必使用跳線,盒子裡附贈的白扁線就可以直接使用。接下來就可以藉由 FON 的無線網段上網了,打開 Firefox 或是 IE 後會直接連上設定的網頁,假如沒有的話,請輸入 http://192.168.10.1/。填上所有的資料後你可以馬上在 FON 所提供的世界地圖中找到你的 FON 機位置所在。假如你要停掉 FON 機的服務,可以直接拔掉 FON 的電源,或是輸入下列指令停掉 DHCP 的服務功能。
# /usr/local/etc/rc.d/isc-dhcpd.sh stop
Cheers,大功告成, Good luck!
訂閱:
文章 (Atom)