一場庫檔案的遠端修復
系統環境rhel 4.7
一、原因：
發現每天早上7點1分備份的資料庫檔案時間不對，登入上去後date下發現時間是正確。
二、嘗試解決：
1）setup->timezone configuration-> asia/shanghai儲存後，發現由原來時間的cst時間變成了utc時間，亂套了clock w調整下硬體時間跟軟體時間一致，無效
2）tzselect命令調整後亦無效。
3）檢視/etc/localtime發現裡面內容為空，於是刪除掉，重新鏈結乙個localtime檔案過去ln -sf /usr/share/zoneinfo/asia/shanghai /etc/localtime
之後再檢視該檔案亦為空，調整時間失敗。
4）於是從其它線上正常的rhel 4系統的localtime檔案拷貝乙份上傳至該機器，date檢視時間正常，於是設定crond檢視下定時備份是否正常，由於當時未重啟定時任務，這個導致自認為不正常。
三、罪惡的發生
#rpm -e glibc-2.3.4-2.41 -nodeps刪除包
#rpm -uvh glibc-2.3.4-2.41.i386.rpm 嘗試安裝包，提示下面錯誤
-bash: /bin/rpm: /lib/ld-linux.so.2: bad elf interpreter: no such file or directory
更嚴重的是ls vi chmod mount 之類的常規命令都無法使用，開啟另乙個shell登入視窗隨即關閉。
由於機器做了遠端登入限制，嘗試vi去掉限制發現該命令無法使用，於是從另一相同系統中去拉/lib/ld-linux.so.2檔案，發現此檔案為軟體鏈結，此檔案鏈結至ld-2.3.4.so檔案，找到此檔案真的檔案上傳後使用chmod命令無法使用，開始鬱悶了，於是想在linux傳送的時候不會改變檔案許可權，於是想嘗試用linux系統登入後傳（其實這考慮是白搭的，一我不知道root密碼，二那機器已無法登入了），嘗試在看tftp有沒有修改檔案許可權的功能。想當然後先點了最後乙個屬性發現沒有更改項，失望了。正在絕望的時候在那xftp視窗再點下右鍵發現有一項是change permissions修改許可權的，於是點開後把execute可執行許可權給加上去了。加上使用ln -s命令發現此命令也無法使用，於是把ld-2.3.4.so本地的重命令為ld-linux.so.2上傳後修改許可權使用rpm -ivh glibc-2.3.4-2.41.i386.rpm 重灌該包根據其提示把相關的so檔案繼續上傳直至該命令可以裝包了。
四、裝完glibc-2.3.4之後緩了一口氣，幸好開著乙個命令視窗跟乙個檔案傳輸視窗，還有就是沒有影響機器應用軟體的正常執行，於是又開始整時間了，date檢視下當前時間為utc的使用setup重設時區後恢復cst時間，此時生效，於是設定乙個crond檢視備份檔案時間，間隔一分鐘後發現檔案沒有按正常crond指定的執行。於是嘗試重啟了crond。至此問題解決。
在解決glibc跟rpm這些關鍵命令的時候需要警惕，最好是在上線應用前把這般問題解決。
glibc介紹請看
一場殊死的戰鬥
在軟體世界中漫遊，往往失去前進方向。在軟體世界裡，許多事情都可以去做，但必須有個 中心 那麼，在我心中，這個 中心 是什麼呢？這些年來，我要幹什麼事情呢？一言以蔽之，linux office。但是，這兩個東西必須是gnu 計畫的產物，必須最終體現軟體的價值 自由使用。軟體的價值，就在於使用。評判是非...
OA的一場盛宴
今天有幸參加了一場泛微的在深圳的一場產品發布會。其實，今年年初基於oa的應用，就有過乙份構想。當時，在文中提出了oa已經從傳統的非結構化資料的事務事件流向向乙個基於事務驅動關係的應用轉變。記著會上廠商的一位職業經理人所說的一句話特別有意思，一套oa系統在十年前，再到今天已經發生了很大的變化了。已經從...
虛驚一場的海嘯
2月27日，智利發生8.8級特大 1個世紀以來最強的 全球都在關注。其中，日本的反應尤其大。日本本身自然災害特別多。火山，海嘯，以及洪水。所以，對這種自然災害天然的比較敏感。最主要的原因，在於智利的 會影響到日本！這是有前車之鑑的。1960年智利海域發生了9.5級 太恐怖了。引起了海嘯，一直穿過整個...