debian6安裝字體簡易方法

[| 不指定 2012/05/06 14:05]
    今天用了一個debian6的系統,啥字體也沒裝,用locale -a看時只有C和POSIX,沒有en_US.utf8,怎么辦呢,很簡單,執行:dpkg-reconfigure locales (root權限),然后根據提示選擇要裝的字體就ok了。






Tags:
   之前都是用ping和tracert/traceroute來檢測線路的丟包率和延遲,最近發現mtr這個命令集合了以上兩個命令的優勢,在一個文本圖形界面里traceroute出線路各個途徑路由,然后連續ping各個節點,可以看出各個節點處的延遲、丟包情況,這樣就能很容易看出來問題出在了網絡的哪一步。

    通過命令展示出的數據可以看出丟包率:Loss,已發送的包數:Snt,最后一個包的延時:Last,平均延時:Avg,最低延時:Best,最差延時:Wrst,方差(穩定性):StDev。非常強大。

    按d可以切換各個視圖,按一下后切換到的視圖用?來表示丟包,點表示正常,不過右括號不知道什么意思。再按一下就更復雜了,還有字母數字等等。網上的資料貌似也沒有提到,等有時間看看源碼。不過默認視圖就足夠用了。

    剛剛試了一下,從國內到博客服務器,丟包大戶是:202.97.53.242,現在丟包率在6個點。看延遲應該是在美國的一個路由。





Tags:

Thinkpad X200拆機及清灰

[| 不指定 2012/05/05 15:59]
    又到夏天了,電腦底面的溫度直線上升,準備清一下灰塵,之前清過一次,用清潔氣吹了下,但沒有合適的工具,擰不開風扇,只能從散熱器外側向內側吹,效果不好,吹過一次后還變響了,這次有了全套螺絲刀,準備徹底清潔一下。

   底面的螺絲很順利,很快都擰開了,取下鍵盤和掌托,然后把屏幕的螺絲擰開,把屏幕下的u型塑料拿下來,開始準備拆主板,主板弄不下來,被無線網卡壓住了,于是就開始拆無線網卡,結果悲劇發生了,擰下第一個螺絲后,第二個螺絲擰了幾下沒擰下來,因為選的十字螺絲刀頭的尺寸大了點,又擰了幾下,結果擰花了,鴨梨很大,搞了半天搞不下來,只能先將旁邊的聲卡/sd模塊拆下來,騰出地方,搗鼓了半天搞不定,于是決定先搞個小刀把螺絲劃出一個溝再擰,找不到小刀,去小區門口5角錢買了個,回來發現螺絲擰起來跟豆腐一樣,用小刀劃起來還挺硬,把小刀刀頭都劃平了,勉強在右邊劃了一個小溝,左邊劃了幾個痕跡,螺絲刀還是吃不上力氣,到了吃飯的日子,于是先吃了飯,吃完飯想起來指甲刀,指甲刀一般比較厲害,用指甲刀剪了幾下左邊,果然剪出一個凹槽,還是不好用力,但指甲刀也無能為力了,蛋疼,期間還試過用核桃夾夾住螺絲刀擰、用螺絲刀頂著側邊的凹槽用核桃夾敲等方法,都紋絲不動。搞了很久耐心快到極限了,之前屏幕還和主板上的無線網卡有信號線連接,現在把信號線拔掉,屏幕取下,然后換了一個稍小一點的一字螺絲刀大力擰了幾下,期待奇跡的發生,結果發現螺絲真的動了。趕緊又擰了幾下,終于擰下來了。

    主板取下后直接就開始拆散熱器了,發現cpu上的三個大螺絲是用彈簧壓的,估計防止力度過大把cpu壓壞,之前以為銅散熱器下有空間,里面是很多灰塵,結果拆下來后發現銅散熱器直接是整個和cpu/gpu接觸的,沒有縫隙,cpu上是導熱硅脂,gpu上是導熱海綿(不知道是不是這么叫,不過樣子挺像),由于手頭沒有新的,所以不能重涂了,怕灰塵進去,急忙又把散熱器擰上了。
    然后擰風扇和散熱器之間的三個螺絲,上次就是在擰三個螺絲中的一個的時候擰不下來放棄的,這次有了合適的螺絲刀,很快擰下來了,把風扇和散熱器分離后,散熱器內側的景象展現在眼前,怪不得之前吹的沒效果,原來散熱器和風扇之間的那個界面上覆蓋了一層黑乎乎毛毛的東西,把散熱器的縫隙塞住了一半,急忙把臟東西清理出來,用清潔氣吹了一下,干凈了。

    然后開始擰螺絲,比較順利,無線網卡右側那個螺絲用旁邊預留槽的螺絲替換了,發現那個位置的四個螺絲都跟豆腐一樣,稍微一擰就花了,別的地方都還好,看來thinkpad也開始偷工減料了,我的還是08年的tp,現在出的估計更沒法用了。

    擰好后用魯大師看了看,貌似效果不錯,不過壓力壓一會后還是比較燙,但平時使用時底座溫度降下來了,爽。


Tags: ,
    最近幾個開發環境都換成ubuntu了,但隨之遇到一個問題,就是用git時perl老是報錯,經常報錯報的把正常信息都掩蓋住了,報:

perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
        LANGUAGE = (unset),
        LC_ALL = (unset),
        LANG = "zh_CN.UTF-8"
    are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").


網上搜了一堆東東,都不是太有效,還是運行靠譜:

export LC_CTYPE=en_US.UTF-8
export LC_ALL=en_US.UTF-8

如果每次啟動都自動執行的話就加到bashrc或bash_profile里。

有可能需要重新安裝配置相應語言包:
sudo apt-get install --reinstall locales
sudo apt-get install language-pack-en-base



Tags: , ,
    現在很多比較大的站點會把訪問頂級域的請求都url重定向到www子域上,主要是為了網站權重統一的考慮。google站長工具里面也提供了將搜索結果統一到www子域或頂級域上,但為什么大的站點都是從頂級域統一到www子域而不是相反呢,最近看dns,也寫寫從域名解析角度看統一到哪個比較好。

  如果請求訪問頂級域,則頂級域的a記錄是由頂級域dns指定,而頂級域dns由上級域dns的ns記錄指定,這個ns記錄的緩存時間是不可控的,有可能會比較短,而訪問www子域的話,a記錄由頂級域ns記錄指定的dns解析,這個ns記錄是可以自己控制的,可以設置成比較長的值,并且如果用戶訪問過其他子域,那么會緩存子域dns地址,這樣的話訪問www子域直接找子域dns服務器解析即可,無需了解頂級域dns服務器,而如果訪問頂級域,就需要查頂級域dns地址了,很有可能要去請求上級dns,像com等域名dns很多同時是由根dns解析的,而根dns均在國外(雖然通過anycast技術可能有國內節點,負載也是不小的)。所以總體來說統一到www子域較好


Tags:
    五一節在家看rfc看的比較暈,rfc的英文貌似都比較晦澀,組織不夠有條理,表述也比較模糊,很難了解到詳細的東西,昨天公司同事推薦了DNS & BIND(DNS and BIND)這本書,大致瀏覽了一下,豁然開朗,寫出一些總結。

    之前有一個二級域是自己解析的,而頂級域是用一些dns商提供的域名解析服務,最近各個dns提供商的服務都不太靠譜了,國外的老是訪問不了,國內的dnspod又很不穩定(高峰期動輒就幾s的解析時間),于是開始考慮自建dns了。

    自建dns首先要考慮的問題就是穩定性,畢竟vps穩定性比服務器還是要差一點,并且出了故障的恢復可能也沒有那么及時,這樣就需要研究在在線率只有99.5%這個級別的vps上如何搭建一個穩定性較高的dns服務。

    經過研究dns的實現原理,發現dns從設計上就是一個高可用性的架構。

    首先dns要求域名最少要有兩條ns記錄(我之前自己的二級域就設了一個貌似也沒啥,但頂級域要求最少設置兩個),以保證服務的穩定性。如果只有兩臺dns服務器,則設置成一主一從即可,從dns周期性從主dns獲取最新結果,同步參數由SOA記錄指定。如果dns比較多,可以設置多主dns,不過需要維護各個zone文件的統一性(可用rdist),每個域名受限于udp包的大小,最多設置10個左右的ns記錄(從該書看到的,未詳細考證)。

    對于多個ns記錄,windows的客戶端和ubuntu的客戶端會首先查詢第一個記錄,如果失敗或超時,則查詢下一個。對于某些客戶端則會隨機挑選一個。

    這樣的話需要把速度比較優秀的dns服務器放在第一個位置上,把備份服務器放在后面,這樣即使第一個dns掛掉,后面的服務器一樣能提供服務,只是速度會慢一點而已。但對于隨機選ns的客戶端就比較蛋疼了,會選到比較慢的服務器,不過這個還是待考證的,可以先搭建一下試試,看看比例如何。

    
    另外搞清了上篇文章所說的域名自身ns記錄的問題。很多頂級域的dns都會有@域的ns記錄指向自己,之前理解有誤,其實這些ns記錄是對二級域生效的。這樣設置是表示二級域和頂級域由相同的ns服務器負責解析。即使不設置這個記錄,頂級域dns服務器也是可以解析子域的,但頂級域的ns記錄緩存時間是不可控的(設置時沒有ttl),有可能很快過期,這樣的話解析二級域時就需要多次去com域dns上查詢,而有了ns記錄,可以自己控制ttl,在ttl沒有過期的時間內,查詢時可以直接命中ns記錄去查詢二級域,有效提高速度。

理論上頂級域dns只負責解析頂級域自身的a、mx、cname、ns記錄等,其他二級域記錄需要頂級域的ns記錄指定的dns來解析,而一般大家使用dns托管的話,二級域名和頂級域往往是一起管理的,所以ns是指向自身的。
Tags: ,
    很久之前有過如下疑惑:比如baidu.com的域名dns設置為ns2.baidu.com。也就是說baidu.com這個域名由ns2.baidu.com解析。但問題是,ns2.baidu.com對應的ip又需要找到baidu.com的解析服務器去解析,這樣就陷入一個循環。如何解決這個問題呢?周末看了下相關rfc,原來對于ns記錄用到的域名,可以設置一下glue record,用來給這些域名提供解析,顯然,這個記錄需要由一級dns服務器解析。也就是.com dns服務器。顯然,這個記錄需要去域名注冊商那里設置,我用的域名是godaddy注冊的,研究了一下,godaddy將這個記錄叫做“summary record”,設置的位置也相當偏僻,在域名管理面板的左下角,有個“Host Summary”框,點擊add即可添加相關記錄,這個從字面意思上并不太能看出來跟dns有關,找了很多資料才找到這里。

    對于很多dns提供商和服務程序,當添加一個域名時,會默認帶有這個域名的ns記錄,這個會比較令人疑惑,因為這個記錄正常情況下是不會生效的,域名的dns服務器是上級域服務器指定的,在本級指定看起來沒意義,不知道有何原因,個人猜測是為了在多ns記錄情況下,從任意dns server查詢的時候都能獲取到所有的ns記錄





Tags:

修改dns服務器

[| 不指定 2012/04/29 20:07]
    昨天晚上回家發現博客打不開了,查了下原來是dns解析失敗,上監控寶看有一部分監控點也是連續幾小時無法解析,看來he的dns也要掛掉了,于是開始換dnspod,注冊了一個,把域名記錄一個一個的搬了過去。

    今天早晨一看監控寶,發現域名倒是能解析了,但解析時間都在1s以上,實在無法忍受,不過不排除是監控寶的dns緩存還沒過,還在找he要解析記錄,準備再觀察一下。不過看論壇說dnspod現在也不靠譜了。哎,實在不行自己解析,不過就是會犧牲一點穩定性。




    前兩天在用lua_next遍歷一個lua表的時候遇到了:PANIC: unprotected error in call to Lua API (invalid key to 'next')  仔細檢查了下代碼和堆棧信息,發現沒有問題,但為什么會說遍歷失敗呢?

    找到文檔看了下,原來lua_tolstring只支持number和string類型,但是對于number類型,在取值后也會轉換其在表中的實際內容為string,而我遍歷的表是使用默認自增索引作為key的,這樣對key調用這個函數會導致key變成字符串,因而遍歷有問題。

    如果表的key不一定是string,而又要用lua_tolstring獲取它的值,那么建議先在棧上復制一份,然后對于復制的值進行獲取。





Tags:
    BGP的全稱是Border Gateway Protocol, 邊界網關協議。最近在很多機房和服務器/VPS介紹時提到了BGP這個詞。并且凡是帶了BGP的,價格就要高很多。那么到底什么是BGP,BGP又有什么用呢。

    從一些英文資料上來看,bgp主要用于多個不同as用戶訪問目標時都能有很好的訪問速度,參考國內的跨運營商訪問。很久之前記得雙線主機是給兩個ip的,也就是說雙線靠同時接入兩個運營商的線路實現,這樣雙ip的站點要想讓用戶能夠訪問到和自己同運營商的ip,往往是通過不同的域名,然后讓用戶手動選擇的(之前很多網站都有電信入口或網通入口的鏈接供選擇,現在很多下載站還有這種設置)高級一點就是使用智能dns,自動解析給用戶同線路的ip,cdn就是基于這個原理。至于bgp,就更高級了,同一個ip,對于不同的來源會有不同的路由方式。按我的理解就是將同一個ip廣播到多個子網絡中,這樣各個子網絡上的訪問者都可以從本網絡路由訪問到指定ip,避免了跨運營商訪問。

    還有一個類似的東西叫anycast,看了一會資料沒有太看懂跟bgp是什么關系,貌似是說anycast是bgp的一種增強版實現?
    anycast是更進一步的實現,是多server綁定同一個ip,用戶在訪問時會路由到離自己最近的server上。比如google.com。同一個ip在全球范圍內ping的話值都比較低。原因就是每個地區用戶訪問該ip時,會路由到離自己最近的服務器上。這樣有效避免了數據的遠程傳輸。



Tags: ,
分頁: 7/33 第一頁 上頁 2 3 4 5 6 7 8 9 10 11 下頁 最后頁 [ 顯示模式: 摘要 | 列表 ]
一级a做爰片_免费一级特黄大片_日本一级特黄大片 <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <文本链> <文本链> <文本链> <文本链> <文本链> <文本链>