Snooda

      在服務器操作系統市場上，Linux因其開源、自由的特性贏得了很多人的親睞。但相比于Windows系統簡單直觀的GUI界面，Linux的操作很大一部分是使用命令行方式來進行，這對于一部分初學者來講是一個不小的挑戰。操作失誤輕則影響服務，重則丟失數據。那么，究竟怎樣才能降低風險，更安全的使用Linux呢？

1，  vi的使用
vi是使用很廣泛的文本編輯器，可以讓雙手在基本不離開字母區的情況下完成各種操作。應注意在查看超大文件時，不能使用vi。因為vi會將文件整體載入內存，打開大文件很容易造成服務器內存耗盡、IO占用率飆升。在這種場景下，推薦使用less命令。
2，  慎用rm
在日常操作用，應謹慎使用rm，尤其是-rf參數。對于不需要的文件應先mv到其他位置保留一段時間，待磁盤空間占用率較高需要清理文件時再進行清理。
3，  替換文件使用mv而不是cp
在替換文件時，應先備份原有文件，再使用mv操作將文件覆蓋。對于正在使用該文件的進程來講，mv操作不會在本次使用周期內被感知到，只有重新打開文件時才會生效。而cp則不然。使用cp覆蓋文件，特別是覆蓋動態鏈接庫，很容易導致一些進程coredump。
4，  編寫重要命令時前面加符號#
在編寫重要/批量命令時，應在命令開頭處先輸入符號#（#在shell中為注釋符）。確認無誤后再去掉#，避免誤按回車鍵導致不完整命令執行造成破壞。
5，  確保操作所依賴條件成立
對于依賴前面執行結果的操作來講，可以使用&&來連接各條命令，確保前面執行都成功后才進行后面操作，避免前一步執行失敗仍繼續下一步造成破壞。
6，  使用rsync而不是scp
在拷貝大量文件時，scp無法查看具體進度，并且一但中斷就要從頭再來。相比之下rsync功能更為強大一些，支持增量傳輸，并且還可以隨時查看進度。
7，  網絡操作注意限速
對于rsync或wget等網絡操作，應注意限速，避免耗盡帶寬影響正常服務的通信。
8，  操作前設計好回滾方案
操作結果不符合預期時，需要將之前的操作回滾。應提前設計好回滾方案，避免到時候手忙腳亂導致操作失誤，或操作時未注意備份文件和數據導致回滾失敗。

    最近發現有個問題，一個自制的webserver在應答前端請求時，總是要處理1s以上，似乎是由于哪里等待了1秒。研究了下發現：Expect: 100-continue這個東東。

    100-continue這個狀態碼之前是很少遇到的。這個是http1.1協議為了提高效率設置的。當客戶端要POST較大數據給webserver時，可以在發送http頭時帶上Expect: 100-continue，服務器如果接受這個請求，應答一個HTTP/1.1 100 Continue，那么客戶端就繼續傳輸正文，否則應答417，客戶端就放棄傳送剩余的數據了。這樣就避免客戶端吭哧吭哧傳了一大堆數據上去，結果服務端發現不需要的情況。

    libcurl在不同版本里邏輯不同，有的版本libcurl會在POST數據大于1024字節的時候發送100-continue請求，有的版本則不會。我們用到的libcurl版本會發送，而自制webserver不會應答這個請求，客戶端等待1s鐘沒有收到肯定或否定的應答，還是繼續傳輸了正文，雖然邏輯上并沒有問題，但速度上就慢了下來。

    加了下邏輯，對100-continue進行應答，速度馬上提高很多。

    很久之前就有一個問題在困擾，就是明顯感覺svn操作完后要頓一頓才結束。一直以為是svn機器性能問題，后來上了ssd也沒效果。

   最近抽時間看了下。

   先strace一下看看時間，發現在操作末尾兩個gettimeofday之間夾了個select操作。會阻塞幾百ms到1s不等，然后超時。

   第一感覺是最后處理完了可能給服務器發回個什么數據之類的，服務器那里哪個規則配的不對，客戶端連不上然后超時了。

   看svn源碼，看不出來末尾做了啥網絡操作，封裝了好多層，不確定是不是哪一層注冊了什么奇奇怪怪的回調函數，在最后析構時搞一把。

   用gdb單步跑了一下。

   發現svn_io_sleep_for_timestamps函數很可疑。

   查看代碼，發現這是個延時函數。svn通過mtime獲取文件修改信息，所以每次svn co操作末尾，svn會等待一小段時間再返回，svn客戶端判斷apr_stat返回的文件mtime是不是1000000整倍數（stat看到的mtime小數點后面是否全是0），如果是0，那么svn認為該文件系統不支持毫秒級粒度的mtime記錄，就會等待系統時間秒的跳變，即等待平均0.5s，最長1s。如果不是0，那么只等待1ms。
  
   由于svn使用的apr_sleep為了實現較高精度的sleep延時，使用了select來做延時。這就是strace中select系統調用的由來。


   這里還有一個問題，就是如果文件mtime恰好是整數，那么svn就會判斷失誤，進而等待較長的時間。作者認為總比每次都等較長的時間好。

   之前用的文件系統是ext2，它只支持秒級精度的mtime，而ext4支持更高精度。

   找了一臺機器，劃了兩個同樣大小的分區，一個格式化為ext2，一個格式化為ext4，使用svn co向兩個分區中checkout代碼，前者耗時0.3到1s不等，后者穩定在100ms。性能提升非常明顯。

    想上無風扇電源，所以調研下電源去掉噪聲后其他地方如何降噪。開始拿cpu風扇入手。cpu散熱器用的最便宜的超頻三青鳥3。cpu是32nm Sandy Bridge 賽揚G550，比較節能。看網絡上有些人在嘗試G530無風扇工作，不過都比較簡單，決定自己試一下。


    有很多人是在bios中對cpu進行降頻以實現降溫的，想了下，感覺這種方法靈活性不足，另外太過高端。決定不采用。還是用軟件的cpufreq比較簡單靈活。使用sensors工具查看cpu溫度。


    首先拔掉cpu風扇電源，開機滴滴報警，忽略之，進入系統。看到溫度在50度左右。cpu默認工作在1.6G頻率下。


    寫了個死循環程序，先單核跑滿，單核心運行在2.6G頻率下，溫度緩慢上升。慢慢上升到83度左右穩定下來。

    然后嘗試雙核跑滿，結果溫度迅速沖上90+，我看sensors里提示的溫度最高值為102度。急忙停了壓力，溫度1s內就降到了60+。還是挺快的。

     看來默認情況下雙核滿載單靠散熱器是不行的了。下面嘗試限制最高頻率后的滿載測試。

     首先限制雙核1.6G，滿載，溫度沒什么變化，很正常，cpu本來就在1.6G下跑著，滿不滿載沒啥區別。
     2G+1.6G，溫度上升至70+
     2G+2G，溫度緩慢上漲2-3度，看來較低頻率情況下，總溫度和溫度較高那個核的溫度相關性大，與發熱總核數關系不怎么大。
     2.1G+2.1G，溫度上升至80+
     由于80度就已經算是較高的溫度了，所以沒有繼續往上測試。


     當前室溫在20度左右。

     也就是說2.1G是可以無風扇長時間穩定運行的一個頻率。再高就不好說了。以后有需求就搞個自動限頻腳本，溫度升到指定值就降低頻率防止過熱。


     然后看看頻率對性能的影響。在網上隨便扒拉了一個算某某值的命令，大致跑了下，1.6G頻率下跑完需要40多秒，而2G頻率下跑完只要33s，再高頻率的就沒有試了。看來性能還是有一些影響的。





    

  

    很久沒有寫博了，最近一段時間比較忙，不過怕太長時間不更新被拋棄，還是寫一些水文章吧。

    前兩天入了塊硬盤，之前裝的臺式機一直拿老筆記本硬盤跑著，容量不夠了，最近感覺硬盤價格自洪水后又回歸到比較合理位置了，于是準備出手。

    最開始看上的是希捷2T，用的人很多，不過網上一看評價，比較慘，說噪音大的，故障率高的等等。另外我的筆記本原裝的就是希捷硬盤，用了兩年就掛了。于是不敢買了，看看別的，看到了西數的1T藍盤。


    說實話這一款也不怎么被看好，剛出來時評測說尋道時間高達20ms以上。性能比希捷的稍微差些。不過我比較在意的是噪音和穩定性，由于有計劃上無風扇電源，所以對于其他部件的噪音很在意，性能倒是其次了。于是就選定了西數單碟1T。


     下單的時候看有人說新出的已經有尋道時間比較正常的批次了，心里又多了些期望。


     歷經幾天，終于到手了，剛拿到時感覺比想象的輕很多，看批次是9月30日出廠，產地馬來西亞。回家裝上，通電，聽到一個嗖的加速聲音，然后是磁頭吱吱的來回運動，持續了1s，沒有了。仔細聽了下噪音，震動和聲音比筆記本的大多了，帶動機箱隔板有些顫動。不過相比于電源風扇的聲音稍微好一點點。

     先裝個windows跑跑hdtune，跟網上的數據對比了下。讀取速度還是比較穩定的，基本上一個較為平滑的曲線，最高180MB左右，最低到了100MB以下。所幸尋道時間還可以，16ms，看來尋道時間長的問題修正了。

    由于用了比較老的hdtune，緩存大小測試不出。不過蛋疼的是，居然不支持噪音管理。設置了下aam，果然不行。囧，這也太弱了。另外轉速也測不出。


    總體還湊合，反正比老筆記本硬盤快多了

    最近一直苦于沒有什么話題來寫博，今天終于找到一個。    有人疑惑為什么使用fq代理后訪問某些網站反而快了，疑問是不是某防火墻在搗鬼。    世界上一共40億個ipv4地址，ipv6就更多了，為啥訪問任意一個地址就能訪問的到？是誰維護了這40億個地址的分布？從這個ip到那個ip途徑的路由是誰來指定的？

    從我們電腦的上網來講，接入網絡就能上網，這個是很稀松平常的事，但如果同時接入兩個網絡呢？比如一根有線一根無線，那么流量是怎么走的呢？這個時候電腦里的路由表就發揮了作用，運行route print命令，可以看到一行行的規則，每個網絡包都會從上到下匹配這些規則，如果匹配上，就按規則指定的端口轉發出去。一般同一時間段內流量只從一個網卡流出。


    進一步講，家里多人上網的話會有路由器，對于家里電腦間傳送文件和訪問公網網站，流量是分發到不同端口的，路由器的路由表規則就不再是簡單的向某一個端口分發，而是針對不同的ip段走不同的分發規則，一般內網ip流量分發至對應內網端口，公網流量統一從公網端口發送。

    對于公網上的流量，一樣是按照路由表指示的路徑行進，路由表是如何生成的呢？

    首先不會是每個ip一條記錄，因為數據量太大，這里就用到了ip的分塊，最早是用a,b,c三類來劃分，后來由于粒度太粗，后來改用子網掩碼的形式，子網掩碼規定的范圍是ip段的網絡名，其余部分是可用地址范圍（不全是，本文內容不做涉及），這樣，路由表的尺寸就能縮減不少。

    互聯網是網狀的，每個路由都會于1個或多個其他路由進行連接，連接可能斷開，可能阻塞，可能新建，所以路由表也會不斷更新，一個路由器如何得知互聯網上其他路由間的連接狀態從而更新自己的路由表，就需要用到路由交換協議，比如RIP，路由器將自己所知道的路由信息廣播給周邊路由，這樣網絡連通信息就能不斷擴散至全網。


    不過網絡上的路由器成千上萬，如果所有路由都按照這種方式，效率非常低下。

    現實中，網絡劃分為了不同的自治系統：AS，AS的編號由ICANN管理，成為一個AS需要有多線路的連通能力，像電信、聯通都是AS，一些較大的網絡服務商也可以申請AS號和自己的地址空間。每個AS系統內部維護自己地址空間的路由信息，AS系統間的邊界路由器使用BGP協議交換各自地址空間，這樣，發往一個AS的網絡流量只需要發給對應AS的邊界路由即可。不過如果AS間網絡帶寬較小或者不穩定，就會有“跨網絡互通問題”，就像國內電信和聯通間訪問效果不佳。

    早期國內主機解決網絡互通問題會使用雙ip的方案，同時接入一個電信ip和一個聯通ip，再搭配智能dns，可以較好的解決了互通問題。但還是有浪費ip地址、智能dns解析不夠準確的問題。

    后來就有了多線主機有的也叫bgp主機，只有一個ip，但同時接入多個線路，有雙線、三線、甚至五線。對于接入的線路，均可以實現較好的訪問效果。原理就是機房同時實現和多條線路的互通，將ip廣播至每條線路。

    對于服務器可以通過接入多線的方式提高接入性能，對于上網者來說也一樣。但同時開通兩條甚至多條寬帶的成本是比較高的，這樣我們就可以借助多線服務器來提高網絡訪問速度。比如遼寧教育網用戶訪問遼寧聯通，需要繞行至東北教育網節點甚至中國教育科研網節點，但如果借助一臺部署在遼寧、同時接入教育網線路和聯通線路的服務器中轉。網絡速度就能大大提高。對于訪問國外站點也是一樣。
    

    資料：
    查看全球bgp路由表：http://www.ris.ripe.net/bgpviz/
    telnet：route-views3.routeviews.org




    

    最近需要做一個基于php的多進程server。為了優雅重啟，需要捕獲一下kill發出的SIGTERM信號，于是用到了pcntl_signal。

    剛開始發現捕獲信號無效，無法進入信號處理函數。研究了一下文檔，發現要運行一下declare(ticks = 1);看解釋說是為了產生時鐘云云，我的理解就類似于晶振一樣。添加后父進程可以收到信號了。

    但是子進程還是無法收到信號，排查了很久，沒看到什么異常，子進程是平時阻塞噻socket_accept的，懷疑是不是系統調用在這里無法中斷，于是改成while 1循環，可以順利進入中斷處理函數。

    然后搜索了一下，原來pcntl默認都是會自動重新啟動被中斷的系統調用的，對外表現則是無法中斷系統調用的阻塞。

    這時回頭看手冊，原來pcntl_signal還有第三個參數，也是一個可選參數，就是讓我們決定是否自動重啟系統調用，選擇不重啟即可。

    臺灣vps已經不靠譜了。于是開始遷移至香港，臺灣vps決定放棄。這時遇到了問題，就是dns又變成了單點。

    所幸服務商提供了slave dns功能，這個還是很少見的，不過這個功能對于我來說實在太有用了。

    估計也是這個服務太過小眾，服務商的功能也是bug多多，發了無數ticket才搞定。

    首先是管理頁面就有問題，添加slave dns記錄后刷新頁面，記錄就消失了。也不生效。通知他們修正了下，搞定了。

    然后發現添加記錄倒是成功了，但沒有slave dns來拉取記錄。而這時我操作太激進，把ns記錄都切換過來了，結果導致落到slave dns上的請求都返回空記錄了，發現后急忙切換回來。發ticket通知他們，告訴我要在allow-transfer里把所有的服務器ip都加上，試了下，似乎nslookup - slave dns ip 使用指定dns后還能成功了。很高興。

     但過了一會發現請求還是落到了主dns上，并且有很大概率的失敗，于是再次聯系客服。客服說在添加slave dns記錄時我的master dns ip沒有記錄上，重新添加不行，后來客服搞了一下，可能修復了bug，可以了。

     然后發現slave似乎不支持notify請求，我用rndc reload更新記錄時沒有slave來請求。

     先是添加also-notify，通知所有slave dns，因為默認是通知所有ns記錄里的服務器，不過我并沒有用到全部slave server，所以要手動添加其他服務器收到通知。

     發現還是無效，猜測可能是出口ip不對，于是添加notify-source指定了notify時的來源ip。

     重啟bind9， 成功了。

    自用開發機的ubuntu還是9.10版本，不在支持隊列了，最近要編譯一些東西，版本支持不足，于是決定升級到12.04。

    源列表直接更新成12.04的，然后dist-upgrade，結果出了很多奇奇怪怪問題，主要是python的依賴問題，原來的2.6升級2.7，而裝2.7又依賴自身，自己編譯了一個跑起來了，最后遇到了一個終極錯誤：Could not perform immediate configuration python2.7-minimal。 搞了半天解決不了，

    后來發現原來在apt-get命令里加上-o APT::Immediate-Configure=0暫時禁止檢查即可。

    另外ubuntu升版本確實問題多多，還遇到很多相關檢查版本失敗的問題。可以通過修改
   /var/lib/dpkg/info/packagename.*相關文件來使其返回0讓相關檢查強制通過

    今天baidu app engine（BAE)上線了應用防火墻功能，可以設置ip黑/白名單，設置單個ip的5分鐘/24小時內請求數/請求流量限制。可以有效防御攻擊。

    進入應用管理頁面后，點擊“應用管理”，頁面中會看到“防火墻設置”，進入頁面后即可進行設置。

    首先可以點擊按鈕開啟和關閉應用防火墻，只有開啟后防火墻各項設置才會生效。

    然后可以設置ip的黑白名單，支持以子網掩碼的方式設置ip段。可以設置的數量為100.


    對于有攻擊發生時，可以設置每個ip在不同時間周期內訪問的次數和流量，對于超出的予以封禁，返回403錯誤。

    頁面下方可以查看封禁情況，并可方便的把封禁的ip加入黑名單中。使用十分方便。