<menu id="gmukm"><object id="gmukm"></object></menu>
  • <tt id="gmukm"><blockquote id="gmukm"></blockquote></tt>
    <bdo id="gmukm"><button id="gmukm"></button></bdo>
        很久沒寫blog了。今天考慮寫一篇,登陸過程中想起目前登陸還是http裸奔狀態,安全性實在是差。決定加一個登陸https保護。

        之前搞過一個startssl的免費證書,一年到期了。這次不想用他家了,一副濃濃山寨風。去namecheap搞了一個,很快就簽發了。

        給一個子域名部署上去,把博客登陸提交地址改成https地址。這樣密碼的提交操作就被https保護了。


         如果只這么做了,登陸是不會成功的。因為子域的session和主域session默認是不通的。

         在session_start前加一句:  ini_set("session.cookie_domain", '.snooda.com');


         然后重啟一下瀏覽器(此步驟必須)


         嘗試一下登陸,ok了。
    Tags:
        Thinkpad剛買回來的時候散熱性能是非常好的,夏天用也非常涼爽,但用上兩三年后,d殼就會非常熱,夏天感覺都能有五十度往上了。拆開徹底的清理過灰塵,好了一些,但遠沒有新機的時候好。

        看到網絡上很多人提到給筆記本風扇上了油或者換了新風扇,溫度下降很多。認為有可能是風扇老化了。

        查看風扇轉速,發現還是3000+轉啊,噪音是變大了。但轉速在那里,散熱器灰塵也吹干凈了,風量不小。


        為啥就是那么熱呢?



         今天終于找到了問題的答案。原來散熱器也是會老化的。


         筆記本的散熱器就是一個銅的家伙,之前一直以為是靠銅來導熱,還想那么長,導熱過去要多久。今天仔細一研究,發現小小的散熱器也用的熱管。時間長了,熱管里的導熱劑泄露,導致熱管導熱性能下降。于是就產生了這種結果:風扇狂轉,風量很大,但溫度就是降不下來。


          這個時候只更換風扇是不夠的了。要將整個散熱器更換才可以治本了。









    Tags: ,
        最近發現很多同學不知道線上操作替換文件的要點。所以又整理了一下。


        線上替換一個正在運行進程的文件時(包括二進制、動態庫、需要讀取的資源文件等)。應避免使用cp/scp操作。而需要使用mv/rsync作為替代。

        原因:cp是將源文件截斷然后寫入新內容。也就是說正在打開這個文件的進程可以立刻感知到修改。修改文件內容很可能導致程序邏輯錯誤甚至崩潰。而mv則是標記”刪除“老文件,然后放一個新的同名文件過去。也就是說老文件和新文件其實是兩個不同文件(inode不同),只是名字一樣而已。正在打開老文件的進程不會受到影響。如果進程使用了mmap打開某文件(比如載入so),如果目標文件被使用cp覆蓋并且長度變小。那么讀取差額部分的地址時(在新文件中其實已經不存在了),會導致SIGBUS信號。使進程崩潰。




        至于可執行文件本身。倒是不怕cp導致崩潰。。因為cp時會報”text file busy"。壓根cp不了。這時候也應該使用mv類操作。替換完成后重啟進程。執行的就是新的可執行文件了。





    Tags:
        lighttpd有一個功能,就是收到SIGHUP信號時會重新打開日志文件。這樣在日志切分時很有用。但最近發現了一個bug。

        就是如果有子進程掛掉。父進程新fork出的子進程accesslog會默認打日志到最最開始父進程啟動時的那個文件里。


       看了下代碼。原來父進程在收到SIGHUP的時候只是把errorlog重新打開了下。沒有重新打開accesslog(沒辦法,這個句柄是mod_accesslog模塊搞的)。所以父進程維護的accesslog句柄一直是最老的。它本身不打accesslog日志倒無所謂。但它fork出的子進程是打的。這樣就有問題了。



        一個最簡單方法。就是外部腳本判斷進程有更新的時候發一個SIGHUP信號過去。

        根治方法就是父進程重新啟動子進程時給其發一個SIGHUP信號。

        至于父進程自己處理SIGHUP時重新打開句柄這個我感覺不太好。畢竟那是模塊內部數據。lighttpd主干不應該關心。





    Tags: ,
        最近arm盒子想用下tun功能。結果發現內核編譯時沒開tun,所以決定編譯一個。

        先去找到了當前內核的config文件。打開了tun支持。下一步就是去找內核的源碼。找了半天。發現沒有完全一樣的。于是找了個版本相近的,編譯完載入。顯然加載不了。提示insmod: error inserting 'tun.ko': -1 Invalid module format。在dmesg里提示tun: no symbol version for module_layout。

        很多資料在這里提示沒有Module.symvers云云。但我的編譯目錄是有這個文件的。所以不是這個問題。

        由于內核源碼版本和當前內核版本并不完全一致。所以嘗試關閉CONFIG_MODVERSIONS。編譯后加載。

        insmod依舊提示invalid module format。dmesg里改為提示version magic 'xxxxxxxxxxxxxxxxxxxxxx' should be 'xxxxx'。


        modprobe是可以強制忽略version magic的。即--force-vermagic參數,使用后成功載入tun.ko。由于內核源碼非常相近。故工作正常。
        查閱了一下2.4內核源碼中對CONFIG_MODVERSIONS的說明,該參數有四種可能。即內核是否開啟與要加載的擴展是否開啟2*2。經觀察發現在3時代內核上這個特性跟之前的文檔不太一致。由于時間關系沒有詳細研究。

        modprobe還有個參數,即--force-modversion。是在編譯時開啟了CONFIG_MODVERSIONS的情況下忽略接口不一致的。這個參數沒有實驗。


        也就是說如果想給一個內核編譯擴展。最好的方式當然是找到當時編譯的環境。或者編譯一個新內核+擴展給系統裝上。但現實中往往無法這樣做。這時找到相近的源碼編譯。最后強制載入也就行了。(生產環境不推薦)



        happy,tun可以用了。
    Tags: ,

    top/vmstat等cpu iowait值含義

    [| 不指定 2013/06/05 23:03]
        今天發現了一個現象。有一臺io壓力比較大的機器,基本iowait百分之七十左右。idle接近0。按我的理解是百分之七十的cpu都在等待或處理io。沒有空閑的時間片了。

        但開啟了一個視頻轉碼服務后,iowait降到很低水平,usr和sys飆高,idle還是接近0。但此時發現視頻轉碼和原io操作的服務均正常運行,未發生性能波動。

        馬上感覺到其中的矛盾。cpu不是用完了么?為啥還能承受一個視頻轉碼這種cpu密集的服務呢?

        
        仔細查看了一下iowait的解釋。原來它的真實含義是:cpu空閑并且有進程在等待io就緒的時間。

        也就是說如果iowait很高。那么磁盤壓力較大。但此時cpu是較為空閑的。此時如果運行諸如視頻轉碼這種cpu密集型操作。是可以提高cpu利用率的。這一點在服務混布提高利用率上可以做文章。




    Tags: ,
        今天發現這樣一種部署情況:
       a的文件放在b的目錄下,a不想讓b看到,所以設置了700權限。

       其實這樣也是不安全的。b雖然看不到a的文件,但可以把a的文件刪掉。

       因為linux里,目錄也是一個“文件”,里面記錄了它里面有哪些文件,這些文件的inode。b的目錄里可以放啥,b說了算,也就是說,只要將那個目錄“文件”里不順眼的文件項刪掉,就能刪掉文件,而不管對那個文件本身有沒有權限。

       至于文件是不是真的被刪掉了。取決于文件的引用數,如果沒有其他硬鏈存在。文件就真的被刪了。

      
       這里有一個特殊的目錄:tmp。大家都可以往里面寫,但只有屬主可以刪掉自己的。
       可以看下tmp目錄的權限,它是root所有,所以對于普通用戶來說,生效的是最后三位:rwt。其實應該是rwxt。t是特殊權限,是建立在x權限上的,如果刪掉x權限,可以看到t變成了T。即失效了。

       t:SBIT(Sticky Bit)目前只針對目錄有效,對于目錄的作用是:當用戶在該目錄下建立文件或目錄時,僅有自己與 root才有權力刪除。
    最具有代表的就是/tmp目錄,任何人都可以在/tmp內增加、修改文件(因為權限全是rwx),但僅有該文件/目錄建立者與 root能夠刪除自己的目錄或文件。




      
    Tags:
    新增的HTTP返回碼:
    650:應用已刪除或域名未綁定
    651-654: 其他內部錯誤,請聯系管理員


    680:被應用防火墻ip黑名單封禁
    681:超過應用防火墻設置的限額


    配置功能(rewrite)新增點:

    1,新增regex_url。該規則與url規則用法相同,區別是規則為標準正則。
    例子:
             - regex_url: ^/[a-z0-9]\.html$
                       script: /index.php
                      
    注意:regex_url和url規則在同一個app.conf不推薦混合使用。會有匹配順序問題。

    2,新增check_exist。檢查文件和目錄是否存在。支持的匹配規則:file_exist/dir_exist/not_exist
    例子:
        - check_exist: not_exist
                       script: /index.php
                      
    3,新增規則:status_code和location。
    status_code指定返回的狀態碼。允許的值:301,302,403,404
    location指定跳轉地址(在status_code為301,302時使用)
    例子:
             - regex_url: ^/secure_page$
                       status_code: 403

             - check_exist: not_exist
                       status_code: 302
                       location: http://example.com/error.html




    url規則使用的lua正則由于使用比較晦澀,以后不推薦使用。本次新增的status_code和location也不再支持url規則。
    原有url規則功能不受影響。



    Tags: ,

    dns glue record的查看與校驗

    [| 不指定 2013/03/31 21:23]
        在使用自有dns服務器時,一般會使用glue record。即使用ns01.snooda.com作為snooda.com的dns服務器,這樣就會遇到一個先有雞還是先有蛋的問題。為了解決此問題,會使用glue record,即由com域dns服務器提供ns01.snooda.com的ip地址。一般這個記錄在域名注冊商那里修改。但怎么查看是否修改成功了呢?這里dig就派上了用場。


        使用dig +trace +nosearch +all +norecurse snooda.com

        在返回的結果里,我們會在com域dns返回的結果中,看到一個”ADDITIONAL SECTION“,里面提供了兩個a記錄。這就是glue record。由于我們試圖解析snooda.com,所以先從com域dns服務器獲取snooda.com的dns服務器地址,com域dns判斷結果是一個snooda.com的子域,所以是glue record。所以不但返回了dns地址,還返回了對應的a記錄。

        用這個方式就可以檢驗設置的glue record是否生效。





    Tags:
        當使用國外服務器時,經常會發現,下載速度只有十幾k。平時可能不太注意,認為服務器帶寬不足,或者自己使用的寬帶不給力,其實很有可能原因并不在此。

        由于光速的局限性,延遲會比較高(即使光沿直線傳播,太平洋一個往返也要一百多毫秒)。并且由于距離較遠,途徑路由跳數較多,并且網絡擁堵的原因。經常會發生丟包的情況。

        對于平時使用最廣泛的TCP協議來講,發送端發出包后,接收端會回復ACK,表示自己收到了。用這種機制來保證可靠性。但對于高延遲鏈路來講,如果每發送一個包都等待應答,那么大部分時間都在等待數據包到達,而鏈路則空置了。為此一般會采用滑動窗口技術。即在窗口滿之前,發送端一直發送包,然后收到應答后將確認收到的包從窗口中移除。這樣可以提高鏈路利用率。

        TCP還有一個特性則是擁塞控制。當發送端檢測到鏈路發生丟包時,則會主動縮小窗口大小以減慢發送速度,避免擁塞。不過對于跳數較多的鏈路來講,只要有一個路由不夠穩定丟包,就會被發送端判斷為擁塞,從而影響網絡速度。

        為了解決丟包問題,最簡單粗暴的方法就是雙倍發送,即同一份數據包發送兩份。這樣的話在服務器帶寬充足情況下,丟包率會平方級降低。

        這種方式下,直接優點是降低丟包率,直接缺點是耗費雙倍流量。一些延伸影響是更容易觸發快速恢復邏輯,避免了丟包時窗口縮減過快。一定程度也能提高網絡速度。


        最近比較忙,空閑時間做了一個最簡單的程序,試用效果很好,在一臺VPS上測試后發現,未開啟時單線程下載、ssh管道速度在十幾K級別。開啟后可以達到平均300KB+的速度。效果非常明顯。但對于不加速就可以跑滿帶寬的類型來講(多線程下載),開啟后反而由于多出來的無效流量,導致速度減半。所以對于多線程/高速鏈路,這個方案是不適合的。

         目前版本是最簡單的邏輯,未來會進行細化(主動觸發快速恢復、快速重傳等),降低流量浪費,提升加速效果。

         目前程序起名net-speeder,相對于修改協議棧來講,由于后者需要重新升級編譯內核,使用用戶態程序部署更方便,穩定性更高,兼容性更好。缺點則是性能開銷稍大和自由度有損失。總體比較起來,個人使用還是使用用戶態程序更合適一些,特別是在虛擬機中使用(OpenVZ,LXC等虛擬機無法自己定制內核)。




          項目托管地址:http://code.google.com/p/net-speeder/
                               https://github.com/snooda/net-speeder


          

    關注微信公眾號隨時接收最新開發進度。近期將會推出加速效果體驗ssh/pptp賬號
    點擊在新窗口中瀏覽此圖片


    Tags:
    分頁: 2/33 第一頁 上頁 1 2 3 4 5 6 7 8 9 10 下頁 最后頁 [ 顯示模式: 摘要 | 列表 ]
    色琪琪av男人的天堂-琪琪see色原网色原网站-天天谢天天谢天天要-欧美成人视频 <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <文本链> <文本链> <文本链> <文本链> <文本链> <文本链>