linux操作系統
    最近搞了個機器。想搞成同時支持openvz和kvm虛擬化技術的host。從原理上講認為問題不大,因為兩者分別是不同層面的虛擬化技術,一個是硬件級別虛擬化,一個是cgroup水平的進程級虛擬化(對這塊了解不深,說錯勿怪)。所以還是可能同時安裝的。

    搜了下方案,果然有個proxmox的發行版是解決這個需求的。看了下文檔,集成了一堆面板啥的,東西越多bug就越多。還是自己diy一個。

    由于openvz是需要打過patch的內核運行,而kvm則需要kvm和kvm_intel內核模塊的加載(amd的就是kvm_amd)。所以難點就是這個的兼容。其他用戶態的進程如果有沖突啥的都好解決。

    首先選用debian7(我喜歡debian),發現需要用openvz的源,源里使用的openvz內核是2.6.32。而debian7的內核目前是3.2。風險比較大。從源里拖了openvz內核deb包下來看,發現居然32位的內核不帶kvm模塊,而64位的才有。哭了。不知道他們咋搞的。于是64位系統搞起。結果發現kvm_intel加載不進去。報input/output err。用-f強制加載后報簽名被拒絕。估計編譯的時候哪里錯了,雖然有內核源碼和.config,不過還是不自己編譯了,太折騰。

    還是用debian6。debian6的官方源里已經包含openvz了。內核版本也是2.6,32系列。跟debian6默認內核版本相同。這個感覺靠譜。裝上重啟進入openvz內核。modprobe加載kvm內核模塊。ok,成功了。



     下一步就是進程和網絡上的調整了。都不是大問題。



     結論是:openvz目前還是建議用debian6官方源里的包。兼容性好。
Tags: , ,
    最近發現很多同學不知道線上操作替換文件的要點。所以又整理了一下。


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

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




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





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:

Linux服務器安全操作技巧

[| 不指定 2013/03/13 11:52]
      在服務器操作系統市場上,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,  操作前設計好回滾方案
操作結果不符合預期時,需要將之前的操作回滾。應提前設計好回滾方案,避免到時候手忙腳亂導致操作失誤,或操作時未注意備份文件和數據導致回滾失敗。








    很久之前就有一個問題在困擾,就是明顯感覺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。性能提升非常明顯。





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

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

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

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

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




Tags:
    自用開發機的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讓相關檢查強制通過


Tags:
    今天需要臨時展示一個樣例站點,上傳程序太麻煩,修改起來也不方便,而電信寬帶沒有公網ip,只能先在電腦上用ssh連接到服務器,在服務器開個端口映射到電腦上。

    運行了ssh -Ng -R "*:2222:*:3333" server

    發現在服務器端映射端口是成功了,但只是監聽在本地。改了半天也不行,百思不得其解。因為之前用過都是成功的。


    后來發現某些版本的sshd因為安全性考慮,默認只允許監聽在本地。

    需要在/etc/ssh/sshd_config里面加一句:
    GatewayPorts clientspecified


    即可
Tags: ,
分頁: 1/3 第一頁 1 2 3 下頁 最后頁 [ 顯示模式: 摘要 | 列表 ]
黄se大片全集,s8视频 情色视频,国产在线久久播放,天天鲁天一鲁,第一色色资源站 一色屋,3X免费视频 <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <文本链> <文本链> <文本链> <文本链> <文本链> <文本链>