禮拜五早上，我主站 sync database 到鏡像站失敗了，於是我就去查明原因，首先發現我的主機到鏡像站台的 trust 消失哩，而且我自定的環境變數也消失哩，再仔細看看我發現我登入的所在目錄為跟目錄，這代表鏡像站在虛擬主機那邊的家目錄消失哩。這件事情我比主機商和他的網管人員更早發現...而且主機商所有客戶的家目錄都消失哩...
雖然說我在鏡像站主機內只是個 user，但是也是習慣趕快去查一下 log，更神奇的事情是整個 /var/log 目錄都消失哩，這情形也是我先發現的，我想主機商這次可能麻煩大哩。因為我要顧及我發票網的會員資料，所以就趕快用去查詢 database 的狀態，還好所有用戶的 db file 都還存在，代表這主機商被人搞鬼也沒搞得很絕，於是我又趕快交代主機商的網管人員備份 db file，我還真是不知道主機商網管是在幹嘛...
說真的搞蛋的人怎樣去 hack 的我也不知道，但是若是 root 密碼被破那麼就要追查原因哩，但是要追也的確頗麻煩，為哩保障系統安全系統打掉重新安裝是比較保險的。系統打掉之前要備份甚麼呢？不是我的主機我當然不知道，但是我看主機商的網管人員也不知道，所以當系統重新安裝後問題又一堆哩。
禮拜六晚上系統重新上線之後，問題還是有的，包含所有人的網站都無法登入，以及大家的 DNS 都出現問題，從我知道問題，到我隔天騎車中正嶺挑戰回來，問題都依然存在，這狀態大概維持哩14~15小時之久，當我正在與KHS校長喇賽時我才接到主機商的求援電話，我原本是想說主機商網管應該搞得定，沒想到搞不定也沒先問我，又不是不熟？反到是主機商直接電話找到我。
騎車回家之後，我先洗哩澡又稍微擦哩車我才上線，拿到哩主機商的 root 密碼，要開始協助查問題哩，我已知的問題其實很快就解決了~狀況處理狀態說明一下
1.DNS 不通
這情形當然是先查 DNS service 是否啟動，查詢結果是 OK 的~而且在主機內自我測試都是正常的，那問題會在哪？當然是從網路開始找起，從外頭主機 telnet 主機 53 port 也是正常的，那就看看防火牆吧，防火牆規則的確出哩問題，53 port 的 udp 不給過......這問題一點都不難找，我不知道為啥可以搞那麼久@@，當然我也不是很急啦~因為我也不好意思插手別人管理的主機。
2.所有網站都不能登入
這情形我一開始先懷疑到 mysql 的問題，試著查看是否有缺少的 rpm，也試著多安裝一些 rpm 套件，若不能頭就大哩，但是真的不能；於是我就開始查尋 log，看到哩些沒有遇過的 size 問題，於是就想到網管跟我說過他改過 php.ini 內的某個 size，預設是 8M 的值被調整 8192M，我是不知道調整成 8192M 會怎樣出錯啦，但是我一改回 8M 就一切正常哩。其實除錯步驟也不難，兩個問題沒有花太多時間，持續考驗著自己 trouble shooting 的能力。
主機商大多的客戶網站開始恢復運作，不能登入的變成可以登入，但是大家的整體運作還是有問題，主機商給我看哩一段 error message，我當然就是上 google 問神囉，一查之下發現可能是 mysql 版本不同的問題，或是 plesk 升級的問題，因為大家的資料庫，所有人的 table，只要有欄位內有 auto_increment 的值通通會消失，這問題的確頭大哩。我測試哩發票網，果然不能新增任何資料，因為資料庫是自己設計的，修正 auto_increment 的問題後發票網就正常運作了，但是別人的那麼多資料庫怎辦？而且哪些欄位有 auto_increment 啊？主機商開始燒腦哩，甚至跟我說大不了賠個一兩百萬收起來算哩～
之前備份的 db file 還存在，這是目前的唯一希望哩，為哩先測試就先以單一個 db 的 file 做回復測試，但是網管卻是以上傳檔案直接覆蓋的方式，而且把 mysql 整個停掉，然後所有人網站都在等他的上傳結束-.-，這做法讓我很傻眼，因為 db file 的壓縮率是很高的，在主機商網站掛掉的情況下，他卻以未壓縮的檔案慢慢傳，在我提醒之後也是繼續傳而已...這時我想主機商和網管已經鬧翻哩。
好險以之前備份的 db file 回覆後是正常的，大部分的問題都解決哩，再來的小問題也別問我哩，因為我大致上相信系統上的問題已經不多哩，能解的都解哩，若是資料庫還有問題我也沒辦法囉。想說可以來休息哩~騎車上山已經消耗哩不少體力了，但是電話還是一直響，主機商說 mail 不通，主機所裝的是 qmail 我也不會，但是我看很多 qmail 的 service 有在跑啊~而且我寄信也可以寄出。於是我就繼續發表的 Embedded 文章，在寫技術文章一直被電話吵真的很討厭的說.....但是我能體諒主機商的心急啦~
過哩一個小時主機商 MSN 傳哩一張不能收信的給我，我才發現原來他說的收信是說 outlook，這就直接想到 POP3 咩，netstat -tnl 有在 listen，那就是防火牆哩，果然沒有開通 110，開哩之後收發信就正常哩，我也交代主機商先別吵我哩，我真的想睡覺哩~
其實從昨天晚上起我就覺得怪怪的，訂閱 rss 的人數怎麼減少哩，到今天早上我終於知道原因哩，原來我的綠色工廠 DNS 被搞亂哩，也是代表的工廠服務受到影響，這就讓我有點不高興哩，這樣大家就會知道我上面說那麼的多主機商是哪一家哩，沒遇到的人也別追究哩。馬上連去 plesk 查看 DNS 設定，綠色工廠主站的 IP 的確還是指到我家沒錯，不過怎麼查詢還是不對，於是重新打開重新儲存 plesk 的 DNS 的運作就正常哩，看來 plesk 還是相當不可靠。
碎碎念哩一堆大家可能沒興趣的話題，若看完的人可以想想~
1.若你是主機商，你該怎樣應變處理？你該怎樣和你的網管有效溝通？
2.若你是主機商的網管，你會怎樣預防及應變主機的問題？又該如何和主機商有效溝通？
其實這次事件下來，我不管網管的技術能力問題，我覺得問題是出在彼此的溝通，溝通不良辦事效率就不良，對誰都沒有好處。主機商和網管我都熟識，聽完主機商敘述網管的態度，我也不太想再去跟網管求證哩，因為一定各有說法，大家一定都覺得自己沒錯的比對方多，心態都是要搞就來搞。但是最後擦屁股的是我～友情至上所以不收費，而且這些錯誤排除是有經驗價值，來比現金更有價值。