鳥哥的 Linux 私房菜

編譯第三方軟體出現『 error adding symbols: DSO missing from command line』的問題 (2019/03/06)

最近緊鑼密鼓的處理環工方面的空氣品質模式新版編譯,遇到非常非常多的問題!其中一個很怪異的問題,發生在編譯 CCTM 時產生的! 這個 CCTM 的軟體主要是透過官方釋出的編譯模式,執行一個名為 bldit.csh 的程式,執行完畢後,該程式會主動的去建立 Makefile, 建立完成之後,在根據該 Makefile 的內容去處理後續的 make。

不過,因為軟體的支援度比較廣,某些軟體的 library 可能沒有考慮到它是動態還是靜態函式庫 (dynamic or static library), 因此,在最後的程式碼連結 (link) 時,總是可能會出現如下的問題:

[root@server ~]# mpif90  se_bndy_copy_info_ext.o se_pe_info_ext.o  ...\
  subhfile.o -L/cluster1/models/cmaq-5.2.1/lib/ioapi/lib -lioapi \
  -L/cluster1/models/cmaq-5.2.1/lib/netcdf/lib -lnetcdf -lnetcdff \
   -o CCTM_v521.exe
/bin/ld: /models/cmaq-5.2.1/ioapi/lib/libioapi.a(rdatt3.o): undefined reference to symbol 'nfmpi_inq_att_'
/programs/pnetcdf/lib/libpnetcdf.so.3: error adding symbols: DSO missing from command line
collect2: error:ld return 1
make: *** [CCTM_v521.exe] Error 1
**ERROR** while running make command

該錯誤主要的意思是說,連結函式庫 libioapi.a 檔案的時候,裡面會用到 nfmpi_inq_att_ 的子程式連結, 而該 nfmpi_inq_att_ 則可能是在 libpnetcdf.so.3 那個檔案裡面!但是我們在連結的程式碼當中,並沒有將 -lpnetcdf 寫進去! 所以就產生這個錯誤!這個錯誤似乎沒有辦法在 bldit.csh 當中處理掉,因此,我們只能夠透過修改 Makefile, 將該段程式碼加上如下的資料就可以編譯成功:

[root@server ~]# mpif90  se_bndy_copy_info_ext.o se_pe_info_ext.o  ...\
  subhfile.o -L/cluster1/models/cmaq-5.2.1/lib/ioapi/lib -lioapi \
  -L/cluster1/models/cmaq-5.2.1/lib/netcdf/lib -lnetcdf -lnetcdff \
  -L/programs/pnetcdf/lib -lpnetcdf \
   -o CCTM_v521.exe

這種錯誤其實很常見,不過,鳥哥也是透過一次次的學習才知道處理的方法!為了避免自己忘記~寫到這裡來,分享給大家一起學習!


知道你的 Linux 快取裡面的檔名有哪些 (2019/02/11)

在鳥哥服務的單位中,我們的電腦教室每個學期常常需要進行大量的電腦裸機復原,電腦裸機復原需要用到很大型的 image file, 就是從已經安裝好的電腦當中,將硬碟的資料以類似 partclone 的指令備份下來的大型檔案,一個檔案可能都有 40G 以上! 用來正課教學的映像檔,甚至高達 80G 以上!

因為大量復原的關係,因此即使有 10G 網卡,如果我們的 Server 使用一般磁碟,恐怕效能也是很爛!不過,Linux 明明就有 cache (快取) 啊! 第一個讀取過這個檔案後,下一個來讀取,應該就是從記憶體讀出才對!不過我們的 Server 記憶體沒有大到 80G 啊!所以,所有的資料能否被 cache ? 那就值得討論了。

查詢一下網路上面的前輩高人,後來發現,其實 Linux 的檔案 cache 並不是以檔案來處理,而是以 block (區塊) 來進行快取處理! 所以,大型檔案確實可以『部份快取』而已,無須全部快取!如果是這樣的話,那麼不用太快的硬碟,只要記憶體稍微大一些 (當然要比 8G 大), 而且所有的裸機復原時,速度相當一致的話,自然可以進行相當快速的磁碟快取!

那麼問題來了,你怎麼知道這個檔案被快取多少了?其實前輩們有寫一隻 pcstat 的程式,在底下的連結中:

這隻程式可以讓你直接找到某個檔案快取的程度喔!相當簡單!而且已經預先編譯好,假設我以 CentOS 7 為基本系統, 那麼直接下載 64 位元的版本來執行即可!

[root@server ~]# cd bin
[root@server bin]# curl -L -o pcstat https://github.com/tobert/pcstat/raw/2014-05-02-01/pcstat.x86_64
[root@server bin]# chmod a+x pcstat

這樣就做好 pcstat 的可執行功能!接下來,假設我們要來探查某個大型檔案,以鳥哥目前的環境下,有個名為 CentOSxxx 的檔名, 這個檔案就是 CentOS 的光碟檔,共有 4G 以上,有點像這樣:

[root@server ~]# ll -h Cent*
-rw-r--r--. 1 root root 4.2G  5月  4  2018 CentOS-7-x86_64-DVD-1804.iso

先來看看這個檔案有沒有快取呢?就直接使用 pcstat 加上這個檔名 (相對或絕對路徑都可以):

[root@server ~]# pcstat Cent*
|------------------------------+----------------+------------+-----------+---------|
| Name                         | Size           | Pages      | Cached    | Percent |
|------------------------------+----------------+------------+-----------+---------|
| CentOS-7-x86_64-DVD-1804.iso | 4470079488     | 1091328    | 0         | 000.000 |
|------------------------------+----------------+------------+-----------+---------|

看起來是完全沒有快取!最右邊的欄位『 Percent 』就是紀錄快取的百分比!現在,來處理一下讀取的任務:

[root@server ~]# time cat Cent* > /dev/null
real    0m11.108s
user    0m0.011s
sys     0m0.868s

總共花費了 11 秒喔!現在來看看有沒有被快取?

[root@server ~]# pcstat Cent*
|------------------------------+----------------+------------+-----------+---------|
| Name                         | Size           | Pages      | Cached    | Percent |
|------------------------------+----------------+------------+-----------+---------|
| CentOS-7-x86_64-DVD-1804.iso | 4470079488     | 1091328    | 1091328   | 100.000 |
|------------------------------+----------------+------------+-----------+---------|

[root@server ~]# free -m
              total        used        free      shared  buff/cache   available
Mem:          31885        2992         307         420       28586       27988
Swap:          2047           0        2047

因為記憶體還夠大 (32G),所以全部的 4G 都已經快取在記憶體當中了!再來瞧瞧如果重新讀一次這個檔案,要花費多久的時間?

[root@server ~]# time cat Cent* > /dev/null
real    0m0.558s
user    0m0.008s
sys     0m0.550s

同樣的檔案,讀取的速度從原本的 11 秒降低到只需要 0.56 秒,因為檔案有 4.2G,因此讀取的速度大致上可以到達 7Gbytes/s 的效能! 這就是快取記憶體的好處!若以 Gbits/s 來看,則高達 56Gbps 的速度!比 10G 網卡還要快啊!

反正,這就是 pcstat 的功能,有興趣玩一玩的,可以參考看看~下次你也可以在大量的用戶端需要讀取某個檔案時, 事先使用類似 cat 的方式,將他讀入快取,並且使用 pcstat 確認一下是否讀入了,再讓用戶端去讀~當然網路效能就會單純的卡在 1Gbps 網卡那端囉!


scp 在 10G NIC 的 Server 與 1G NIC 的 client 之間傳輸資料的問題 (2019/01/31)

我們系上為了教學方便,系上的網路系統就開始用了 10G 的網路設備,我們很驕傲的說,這是本系的骨幹網路。 之前其實也拉了一條 giga 的骨幹,不過當時的規劃很糟糕,所以校內與系內的網路並沒有分隔得很清楚,所以,某間電腦教室有風暴時, 其他間電腦教室以及骨幹也會被垃圾封包塞好、塞滿~因此在 2017 年中,我們就請學生自行佈置 CAT6A 的網路線, 然後將主要的電腦教室串接在一起,當然,串接到這個線路的,只能是 Server 的對內埠口,對外埠口則額外連接到其他的線路, 然後在 Server 上面,再透過 iptables 的 FORWARD chain,嚴格限制能進入的封包這樣。用了許多時候,並沒有發現什麼特別的問題。

去年 (2018) 年中開始,有比較大量的復原工作要進行,結果學生跑來跟鳥哥說,很奇怪,復原的速度很慢,另外,某間電腦教室改採雙虛擬化系統, 透過一部 HOST 搭配兩張實體顯卡,來達成一部主機雙人共用的環境。但是學生在複製 image file 時,使用 scp 的方式, 他們說,速度很慢啊!後來,看網路上面許多人都有類似的問題,將 MTU 改成 1300 左右,就可以順利運作 scp。 不過,其他的服務會變得很奇怪~所以,這個解決方案應該不是好的方案!

鳥哥最近使用 iperf3 去查看到底出了什麼事?後來發現很怪異,就是 10G --> GB 的方向,網路頻寬使用非常糟糕~一下子到 500Mbps, 一下自降到 10Mbps 的情況,導致效能非常惡劣~但是 GB --> 10G 就沒有這個問題~同時, 10G --> 10G 也同樣沒問題!

我一開始認為是驅動程式的問題,因此都朝向 NIC (網路卡) 的許多參數修改去著手,例如透過 ethtool 去修改許多參數這樣。 不過查詢到的方法,都沒有效果~後來我突然想到, GB --> 10G 的方向,因為 10G 原本就能夠覆載 1G 以上的速度,所以當然沒問題! 那如果 10G --> GB 時,如果沒有特別的控制,那麼 GB 的網卡當然會抵擋不住 10G 來的大量封包!

朝這個方向去找尋後,發現了底下這兩篇相當有趣的分析文章:

  • 10G 乙太網路的錯誤假設,與最佳設置方式:AIXpert Blog
  • NETApp vs VMWare Flow control dilemma:Ranjit Singh

這兩篇的大意是說,10G switch 上面可能會安插不同速度的網卡,例如我們的環境中,10G 網卡與 1G 網卡都安插在 10G switch 上面, 雖然透過自動協商機制,10G 自己跑 10G, 1G 自己跑 1G,速度倒是正常沒問題~但是,當 1G 與 10G 進行交流時, 如果 switch 沒有設定流量控制 (flow control) 時,那麼慢速的網卡可能會出現來不及接收高速網卡的情況~因此上頭第一篇建議, 全部的 10G switch port 都啟動 flow control。不過,在鳥哥的測試中,沒有 flow control 確實速度會高出這麼一點點 (10G 效能可達到 9.7Gbps 左右, 加上 flow control 則大約到 9.5Gbps 左右),但是,在考慮到不同設備間的資料傳輸,鳥哥個人確實建議將所有的 switch 的 flow control 通通啟用比較好! 至少讓你的速度不會差太多!

結果查了一兩個禮拜,方向都錯了!直接改 switch 的 port settings ,將 flow control 勾選,解決!

# 1G 網卡的觀察
[root@slow ~]# ethtool em4
Settings for em4:
        Supported ports: [ TP ]
        Supported link modes:   10baseT/Half 10baseT/Full
                                100baseT/Half 100baseT/Full
                                1000baseT/Full
        Supported pause frame use: Symmetric Receive-only
        Supports auto-negotiation: Yes
        Supported FEC modes: Not reported
        Advertised link modes:  10baseT/Half 10baseT/Full
                                100baseT/Half 100baseT/Full
                                1000baseT/Full
        Advertised pause frame use: Symmetric Receive-only
        Advertised auto-negotiation: Yes
        Advertised FEC modes: Not reported
        Link partner advertised link modes:  100baseT/Full
                                             1000baseT/Full
        Link partner advertised pause frame use: Symmetric
        Link partner advertised auto-negotiation: Yes
        Link partner advertised FEC modes: Not reported
        Speed: 1000Mb/s
        Duplex: Full
        Port: Twisted Pair
        PHYAD: 19
        Transceiver: internal
        Auto-negotiation: on
        MDI-X: Unknown
        Supports Wake-on: g
        Wake-on: d
        Current message level: 0x00000000 (0)

        Link detected: yes

# 10G 網卡的觀察
[root@fast ~]# ethtool eth4
Settings for eth4:
        Supported ports: [ TP ]
        Supported link modes:   100baseT/Half 100baseT/Full
                                1000baseT/Full
                                10000baseT/Full
        Supported pause frame use: Symmetric Receive-only
        Supports auto-negotiation: Yes
        Advertised link modes:  100baseT/Half 100baseT/Full
                                1000baseT/Full
                                10000baseT/Full
        Advertised pause frame use: Symmetric Receive-only
        Advertised auto-negotiation: Yes
        Link partner advertised link modes:  100baseT/Full
                                             1000baseT/Full
                                             10000baseT/Full
        Link partner advertised pause frame use: Symmetric
        Link partner advertised auto-negotiation: Yes
        Speed: 10000Mb/s
        Duplex: Full
        Port: Twisted Pair
        PHYAD: 16
        Transceiver: internal
        Auto-negotiation: on
        MDI-X: Unknown
        Supports Wake-on: g
        Wake-on: d
        Current message level: 0x00000000 (0)

        Link detected: yes

# 1G 網卡作為伺服器,準備接收 client 的資料:
[root@slow ~]# iperf3 -s

# 10G 網卡作為用戶端,準備傳送資料
[root@fast ~]# iperf3 -c 172.31.255.101 -w 100M -t 30 -i 5
Connecting to host 172.31.255.101, port 5201
[  4] local 172.31.255.102 port 42772 connected to 172.31.255.101 port 5201
[ ID] Interval           Transfer     Bandwidth       Retr  Cwnd
[  4]   0.00-5.00   sec   576 MBytes   967 Mbits/sec    0    505 KBytes
[  4]   5.00-10.00  sec   566 MBytes   950 Mbits/sec    0    506 KBytes
[  4]  10.00-15.00  sec   565 MBytes   948 Mbits/sec    0    506 KBytes
[  4]  15.00-20.00  sec   566 MBytes   950 Mbits/sec    0    506 KBytes
[  4]  20.00-25.00  sec   566 MBytes   950 Mbits/sec    0    506 KBytes
[  4]  25.00-30.00  sec   565 MBytes   948 Mbits/sec    0    508 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth       Retr
[  4]   0.00-30.00  sec  3.33 GBytes   952 Mbits/sec    0             sender
[  4]   0.00-30.00  sec  3.31 GBytes   949 Mbits/sec                  receiver

iperf Done.

簡單的測試一下,確實 10G --> 1G 的速度回來了!測試完畢之後,記得兩端重新變更,10G 變成 server 而 1G 變成 client ,交互測試一下喔!


鳥站的文章被入侵偵測系統抵擋的問題與解決 (2018/03/15)

前兩天有個網友突然問到了跟正規表示法比較有關係的資料,屬於延伸型的正規表示法。因為延伸正規表示法鳥哥真的很少用,所以許多的字符忘記了。 因此這個時候鳥站以前鳥哥自己寫的文章就有幫助了。於是上網去查自己的網站,結果...整個正規表示法的網頁竟然無法完全載入! 然後,還有第 13 章帳號管理的部份也沒有辦法載入!夭壽了!以為鳥站被攻擊,趕緊登入系統去檢查。

檢查老半天檢查不出什麼問題,只發現到 /var/log/httpd/access_log 裡面一直出現 304 的 http 代碼。問了一下 google,知道這個是用戶端自己停止繼續下載! 所以是鳥哥自己的用戶端瀏覽器自己關閉下載了...見鬼~難道是鳥哥的工作機中毒了?被當跳板了?於是趕緊跑去別台測試, 測試的結果...每一台都無法順利開啟該網頁!鳥哥開始猜想,難不成是計中的問題?所以,趕緊請校外的朋友幫忙測試一下,咦! 他們可以順利載入耶!沒啥問題!所以,直覺上,鳥哥認為應該是這個網頁被計中擋掉了!

電話請教計中維運的朋友,朋友說,前不久才上線一台 IPS 入侵防禦系統,有沒有可能是被該 IPS 所抵擋呢?所以,朋友很熱心的幫鳥哥處理! 經過羅組長的努力之後,才發現到,原來鳥哥用來作為正規表示法說明的檔案是 /etc/passwd,這個檔案的內容中, 出現了底下這一行字樣:

root:x:0:0:root:/root:/bin/bash

要命的是,在 IPS 的偵測系統中,它認為這個是很關鍵的字串,很有可能是某些木馬或攻擊程式在竊取系統的機密資料~因此就抵擋掉了! 偏偏鳥哥有兩、三個以上的網頁都是以這個 /etc/passwd 的內容作為說明,因此,就有許多網頁無法順利的被載入了...真是好慘!

既然如此,那麼有沒有辦法避免呢?可以的!只要讓該字串不要連續寫下即可!也就是說,我們可以加上一些垃圾 CSS 碼, 那麼 IPS 就會認為該字串沒有傷害性~於是就可以順利顯示出來了!鳥哥的寫法如下:

<span class="raw">root</span>:<span class="raw">x</span>:<span class="raw">0:0</span>:<span class="raw">root:/root</span>:/bin/bash

至於那個 .raw 的 class 請自行定義,如此一來,該字串就可以不被視為有問題的攻擊回傳值了。真是學到了一個寶貴的經驗啊!哈哈哈! 建議未來要做教學之用的說明文件,就不要使用 /etc/passwd 來做解釋了!或者是可以使用畫面截圖的方法來展示 (但是鳥哥不愛這個方法), 最終就是透過上述的說明,加上 CSS 碼囉!


使用 Fail2Ban 進行重複連線的抵擋機制 (2018/01/29)

鳥哥在自己以前讀書的實驗室有擺放一 mail server,裡面有啟用 dovecot 的收發信件驗證功能。近期經常發現有數千筆資料嘗試猜測某些帳號的密碼。 之所以對方會知道我們的帳號,原因很簡單,只因為 email address 的寫法: username@hostname 這樣,所以攻擊者就會知道帳號與主機名稱, 接下來就可能會猜測密碼了...

每天幾千筆錯誤登錄資訊,害鳥哥疲於奔命~累了!還是讓系統自己去抓算了。由底下的連結知道 fail2ban 拒絕 ssh 的重複連線:

那能不能用在其他的服務呢?是可以的~使用的方法很簡單:

  1. 要先安裝 epel 的軟體套件
  2. 然後在啟用 epel 的軟體倉儲情況下,用 yum install fail2ban 即可
  3. 在 CentOS 7 的環境下,新增 /etc/fail2ban/jail.local 檔案,內容有點像這樣:
    [root@cloud ~]# vim /etc/fail2ban/jail.local
    [DEFAULT]
    bantime  = 1800
    banaction = iptables-multiport
    
    [postfix-sasl]
    enabled = true
    
    [dovecot]
    enabled = true
    
    [root@cloud ~]# systemctl start  fail2ban
    [root@cloud ~]# systemctl enable fail2ban
    

這樣就可以收工了。之後根據 log 檔案的分析結果報告,原本動輒上千筆的資訊,已經減少到 100 筆以內,效果相當不錯!提供給大家參考。


VLAN 設定好之後導致的 SSH 停頓問題 (2017/11/01)

這學期的 Linux server 課程授課中,為了解決過去教學問題,所以有加上 VLAN 的設定,如 2017/09/14 所提到的項目。 而另外也為了特別強調 DHCP 的訓練,因此又在實體網卡的 VLAN 附掛的橋接上,用 VM 又模擬了一層 VLAN,也就是產生了兩層 VLAN 了。 這樣的環境鳥哥在測試的過程中倒是沒有問題,確實可以在兩個獨立的 KVM host 之間用兩個 VM 互相 ping 到對方!鳥哥以為這樣就通了! 沒問題~所以就寫入教學文件中。

問題是,實際教學過程中,卻發現學生同樣的設定卻是 ping 到了不過 ssh 不成功。好怪!使用了 ssh -e server 之類的方式判斷兩者間的連線, 確定卡在某個點上面,將訊息帶入 google 中,找到了可能是 MTU 所導致的問題~不過我沒有動過 MTU 啊!是標準的! 我猜,很可能是因為鳥哥的 switch 是無網管的簡易型 switch,因此附掛了數層的 VLAN 之後,封包可能稍微臃腫了些~ 導致無法傳遞超過 switch 所致。因為如果 VM 是在同一個 KVM host 上面,就沒問題!所以我當然會這麼想。

怎麼解決呢?將 vlan 所附掛的那張網卡之 MTU 降低到 1400 左右即可!好簡單喔!就這樣解決! 只是 server / client 兩者都最好要設定 vlan 網卡的 MTU 到同樣的數值較佳~一切順暢!相當怪異的情境啊~所以特別寫下來做個紀錄!


在純文字模式底下變更字型的方案 (2017/10/19)

網友來信問到如果是 tty2 ~ tty6 的純文字模式下,能不能變更字體呢?因為他覺得字太小了!怎麼都看不清楚!以前 kernel 2.6 的版本,可以透過修改 grub 的 kernel 參數修正, 新的 CentOS 7 可以使用一個名為 setfont 的指令來處理喔!至於有哪些字型呢? CentOS 將字型放置在這個位置:

[root@study ~]# ll /lib/kbd/consolefonts/
....
-rw-r--r--. 1 root root  4260  8月  2 21:07 LatArCyrHeb-19.psfu.gz
-rw-r--r--. 1 root root  3803  8月  2 21:07 latarcyrheb-sun16.psfu.gz
-rw-r--r--. 1 root root  5171  8月  2 21:07 latarcyrheb-sun32.psfu.gz
-rw-r--r--. 1 root root  6004  8月  2 21:07 LatGrkCyr-12x22.psfu.gz
....
-rw-r--r--. 1 root root  2084  8月  2 21:07 ruscii_8x16.psfu.gz
-rw-r--r--. 1 root root  2059  8月  2 21:07 ruscii_8x8.psfu.gz
-rw-r--r--. 1 root root  2708  8月  2 21:07 sun12x22.psfu.gz
-rw-r--r--. 1 root root  1515  8月  2 21:07 t850b.fnt.gz
....

至於預設的字型是那一個呢?可以由底下的檔案去查詢一下!

[root@study ~]# cat /etc/vconsole.conf
KEYMAP="cn"
FONT="latarcyrheb-sun16"

一般來說,檔案後面的數字越大,代表字體的大小越大,所以你可以嘗試將自體修改成為 sun12x22.psfu.gz 看看, 字體會放大好多好多!如果想要讓字體恢復一般大小,就使用數字為 16 的字型即可。操作的方式如下:

[root@study ~]# setfont sun12x22.psfu.gz

你可以自己測試一下喜歡的字型,並且搭配你的螢幕,應該就可以取得你想要的純文字環境底下的文字大小囉! 也可以在底下的連結上面預覽相關的字型顯示方式:


想要在 KVM guest 環境下使用 vlan 的方式 (2017/09/14)

因為教學需求,所以需要雲端電腦教室,但是每個同學都應該要有自己的區網,這樣才能夠進行許多的教學。不過,光是在 KVM hosts 之間建立區網, 就快要死掉了!哪有可能建立數個獨立區網呢?後來想到不是有 VLAN 嘛?那就用 vlan 來玩玩看。 發現了可以透過網路卡直接加入 vlan 的通道!舉例來說,如果網卡的代號是 eth0 ,那麼 eth0.11 就是第 11 號 vlan 的通道 (tag=11), 然後建立一個新的 bridge 附掛在這個 eth0.11 的網卡上,那就是一個 VLAN 了!最後,讓 VM 的 XML 檔案中, 使用的網卡為 bridge 且附掛在剛剛建立的 bridge 上,就搞定了!整個流程很簡單:

  • 在 KVM host 上面建立 11 號通道的 VLAN 網卡

我這裡使用 CentOS 6 為範本,不過 CentOS 7 應該也差不多同樣的方式吧:

[root@study ~]# vim /etc/sysconfig/network-scripts/ifcfg-eth0.11
DEVICE=eth0.11
VLAN=yes
ONBOOT=yes
BRIDGE=vbirdbr

[root@study ~]# vim /etc/sysconfig/network-scripts/ifcfg-br11
DEVICE=br11
TYPE=Bridge
BOOTPROTO=none
ONBOOT=yes

[root@study ~]# ifup br11
[root@study ~]# ifup eth0.11
[root@study ~]# brctl show br11
bridge name     bridge id               STP enabled     interfaces
br11            8000.f46d041e83a3       no              eth0.11

重點是請看到 br11 搭配的 interfaces 是 eth0.11 這樣就對了!

  • 讓 Guest 的網卡支援到 VLAN 的網路中

然後你的 xml 檔案改成類似這樣:

    <interface type='bridge'>
      <mac address='52:54:00:87:42:42'/>
      <source bridge='br11'/>
      <model type='virtio'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/>
    </interface>

重新啟動 VM 之後,你的 guest 就能夠加入 VLAN 囉!怎樣~不用 switch 也能夠做 VLAN 了呢!


關於加密 shell script 的方式 (2017/03/06)

最近在寫一些 Linux 作業系統基礎訓練的腳本,這些腳本有製作環境的、設定環境的、傳輸結果的、分析學生執行結果的等等部份。 以前都直接提供明碼給學生,曾經有學生會分析腳本,直接做出對的答案...雖然這樣的結果是,訓練到這個厲害的學生。但是, 其他學生可能就會直接跟這個厲害的同學要求破解的方法,直接取得正確的結果,而沒有實做....那就煩惱了!

在使用 google 查詢了一下 shell script encryption 的結果,發現到底下的兩個超連結:

主要的思考方式很簡單,就是將 shell script 透過相對應的轉換,將腳本變成可以直接執行的 binary program 這樣!鳥哥下載的是 shc-3.8.9b.tgz 這個版本! 然後開始安裝的動作!

[root@study ~]# yum install gcc glibc-static
[root@study ~]# tar -zxvf shc-3.8.9b.tgz
[root@study ~]# cd shc-3.8.9b
[root@study shc-3.8.9b]# make
[root@study shc-3.8.9b]# ll shc
-rwxr-xr-x. 1 root root 36057 2017-03-06 10:08 shc

[root@study shc-3.8.9b]# echo -e '#!/bin/bash\necho "This is a testing"' > zzz.sh
[root@study shc-3.8.9b]# cat zzz.sh
#!/bin/bash
echo "This is a testing"

[root@study shc-3.8.9b]# file zzz.sh
zzz.sh: Bourne-Again shell script text executable

[root@study shc-3.8.9b]# CFLAGS="-static " ./shc -v -r -f zzz.sh
shc shll=bash
shc [-i]=-c
shc [-x]=exec '%s' "$@"
shc [-l]=
shc opts=
shc: cc -static  zzz.sh.x.c -o zzz.sh.x
shc: strip zzz.sh.x
shc: chmod go-r zzz.sh.x

[root@study shc-3.8.9b]# ll zzz*
-rw-r--r--. 1 root root     37 2017-03-06 10:12 zzz.sh
-rwx--x--x. 1 root root 726584 2017-03-06 10:13 zzz.sh.x  <==注意這個!
-rw-r--r--. 1 root root   9396 2017-03-06 10:13 zzz.sh.x.c

[root@study shc-3.8.9b]# ./zzz.sh.x
This is a testing

[root@study shc-3.8.9b]# file zzz*
zzz.sh:     Bourne-Again shell script text executable
zzz.sh.x:   ELF 64-bit LSB executable, x86-64, version 1 (GNU/Linux), statically linked, 
            for GNU/Linux 2.6.18, stripped
zzz.sh.x.c: ASCII C program text

你就會取得一個 zzz.sh.x 的執行檔~最後將這個執行檔更名為 zzz ,並將 zzz 放置到 /bin 或 /sbin 底下,嘿嘿!就能夠被執行而不被查詢到程式碼! 之後鳥哥就可以輕鬆的放一些偵測腳本,而不被學生直接分析,導致被攻破囉!


關於 DRBL 還原之後,Linux 核心出錯的問題!(2017/03/06)

鳥哥所服務的單位是在崑山科大資傳系,系上的學生相當貼心,每個學期都會主動的協助鳥哥進行全系電腦的復原!我們的 PC 系統上面都會安裝多重作業系統, 提供多個不同的作業系統,以利各種教學所需要的特別環境。使用的復原系統為 DRBL 以及 Clonzilla !

最近學生反應,五間教室裡面,有兩間復原 Linux 沒問題,有三間復原就出事!鳥哥覺得很納悶~去瞧了瞧,發現到:

  • 開機可以順利出現 grub 的選單
  • 按下選單後,可以順利的載入核心進行開機,但是等待大約 3 分鐘左右,會出現 WARNING, dracut error 等字樣
  • 之後系統丟一個 dracut 的 shell 畫面提供登入與處理

因為最終出現 dracut ,而最新的 CentOS 使用的 initramfs 確實是在安裝核心時才開始打包,並非一開始就直接提供的! 所以直覺上,鳥哥覺得應該是 initramfs 出錯了!所以解決的方案是這樣的:

  1. 使用原版 CentOS 7 的 USB 開機磁碟開機,選擇『 Rescue 』選項,並進入救援模式中
  2. 系統會主動抓到 CentOS 的已安裝系統,並且加掛在 /mnt/sysimage 當中!
  3. 使用 chroot /mnt/sysimage 來切換主系統,取得一個 root 的 shell 環境中。
  4. 進入 /boot ,將有問題的 initramfs 更名
  5. 透過『 dracut -v /boot/initramfs...(原本檔名) $(uname -r) 』其中 uname -r 是因為這個系統為全新的系統,並沒有更新過! 如果你需要不同核心,就得要查詢一下 /lib/modules 的核心版本才行。
  6. 下達 restorecon -Rv /boot 稍微處理一下 SELinux 可能會有的錯誤!
  7. 重新開機測試新的 initramfs 的結果!

鳥哥比較偷懶,不想要更改檔名,所以所建立的 initramfs 使用的是原本的檔名,這樣就不用修改 /boot/grub2/grub.cfg 檔案! 重新開機後就正常了! ^_^


關於 DNS 查詢的問題解析!(專題伺服器組所導致的問題)(2017/03/06)

三月初剛剛放假回到系上,立刻接到訊息,說我們系上管理的一個 IP 一直對學校的 DNS 主機進行攻擊!查了一下該 IP 的所在, 原來是系上提供給所有大三、大四進行專題實務的 Linux 伺服器組!一開始鳥哥以為是整個系統被攻破了!非常緊張! 來到實體電腦實際使用 tcpdump 去抓封包,確實會對外查詢學校的 DNS 系統!我是這樣查詢的:

  1. 使用 tcpdump -i eth0 -nn ,這個 eth0 假設是對外的網卡。從分析當中,確實發現到有本機對學校的 DNS IP 發起 port 53 的查詢要求!
  2. 因為這個 IP 是 NAT 的功能,還有內部的四部實體主機 (主要提供學生虛擬化機器的 host) 是透過這個 IP 連外的!因此,鳥哥開始使用 tcpdump -i eth1 -nn, 這個 eth1 假設是內部連線的網卡。然後發現到 4 部內部主機有 3 部確實對 DNS IP 發起連線需求。
  3. 嘗試登入內部主機中,那有問題的 3 部中的其中一部,發現到『登入非常的慢,大約要等 30 ~ 60 秒,但是登入後就一切順暢!』
  4. 之後在該內部主機使用『 netstat -antup 』查詢一下連線資料,卻發現到『有從 NAT 主機來的連線,然後這條連線會發起 DNS IP 解析的需求』。 問了一下管理該系統的研究生,他說為了碩士論文的研究,確實有在 NAT 主控系統上面對內部四部主機進行資料收集, 但是該資料收集的腳本僅是針對主機內的資源 (如 CPU 使用率、磁碟使用率、記憶體使用狀況等等),完全沒有發起網路的功能! 鳥哥查看一下 shell script,確實如此!完全沒有動到網路喔!
  5. 有一部主機是正常的,鳥哥比對一下兩部主機之間的差異,竟然發現到 /etc/resolv.conf 內容不一致!原本這套系統預設的 DNS 設定為內部的私有 IP, 但是後來系統改版 (從 CentOS 6 升級到 CentOS 7),可能安裝的時候沒有注意到,因此內部主機的 DNS 設定直接指向學校的 DNS server 去了。
  6. 最後將 DNS 設定改為我們自己的內部 IP 就直接 OK 了!

讀者可能會問,那奇怪了!為啥之前都沒問題,現在才發生問題呢?這是因為這樣的情況:

  1. 前幾個禮拜 meeting 後,對研究生下答要去收集虛擬機器所在的主機的資源統計,所以這個腳本是最近才放上去的;
  2. 這個腳本是由 NAT 主控系統直接發派給四部內部提供虛擬化服務的主機,主要是透過 ssh 的方式來達成腳本傳遞的任務
  3. 內部主機使用預設的 ssh 設定,因此連線時,會反查連線者的 IP 反查
  4. 整套系統原本設有內部 DNS 私有 IP 的 domain 設定,但因為系統重灌,結果沒有指向正確的 private IP,又沒有更新 /etc/hosts, 所以每次傳遞 shell script (每 5 秒傳一次),就會產生 DNS 的查詢要求!
  5. 二月底全校停電,復電後計中的 DNS 系統據說被 DDoS 了!計中人員查詢連線者 IP,發現到我們這個 IP 很頻繁的對 DNS 主機發出查詢要求, 但是卻都查詢失敗 (因為是 private IP 啊!),所以誤判為我們的系統對人家攻擊了!

為了避免產生問題,所以鳥哥這樣處理過後,應該就不會有其他狀況的發生!

  • 將內部主機的 /etc/resolv.conf 設定,指向內部的 DNS server
  • 將內部的 private IP 通通寫入 /etc/hosts ,提供內部查詢 (與前一步驟雙管齊下)
  • 將 sshd_config 加入『 UseDNS no 』的設定,讓連線時不會反查 IP 來源了

bnx2x 網路卡經常反覆斷線的問題 (2017/02/17)

近年來因為雲端的關係,鳥哥跟夥伴們買了不少的 10G 網卡以及 10G 少數 port 的 switch 來在雲伺服器內部加速。 不過,經常會看到 log 裡面出現這樣的訊息呢:

[root@study ~]# tail /var/log/messags
Feb 17 06:40:35 host kernel: bnx2x 0000:05:00.0: eth4: NIC Link is Down
Feb 17 06:40:40 host kernel: bnx2x 0000:05:00.0: eth4: NIC Link is Up, 10000 Mbps full duplex, Flow control: none
Feb 17 07:11:12 host kernel: bnx2x 0000:05:00.0: eth4: NIC Link is Down
Feb 17 07:11:17 host kernel: bnx2x 0000:05:00.0: eth4: NIC Link is Up, 10000 Mbps full duplex, Flow control: none

很奇怪,每隔幾個小時就會自動的斷線再開~雖然不會影響到原本的系統運作 (沒有持續性掛載的資料放在該網卡上), 不過就是心裡不舒服~後來查了一下,似乎是網卡與 switch 之間溝通的 bug 所致,而且目前如果你沒有更新 switch 韌體的話, 應該是沒有辦法解決的,詳情可查閱:

其實解決方案還挺簡單的耶!就將網卡與 switch 之間的自動判斷網路速度功能 (auto negotiation) 設定為不啟用 (off) 即可。 設定方式如下:

[root@study ~]# ethtool -s eth4 autoneg off

測試個幾天,如果問題解決了,將上述的指令寫入 /etc/rc.d/rc.local 並將該檔案權限改成正確,就 OK 了!


Windows 10 透過 KVM 與 spice 的顯示問題 (2016/10/06)

一直以來教學測試的 VM 都是以 windows 7 為主,還沒有安裝過 windows10 在 VM 裡面。因為考慮到未來的使用情況, 所以安裝了 windows 10 的環境在 VM 底下,為了要加速,所以也使用了 KVM 建議使用的 spice (QXL) 顯示卡環境。

奇怪了! windows 10 的 VM 環境顯示效果奇差無比!根據 netman 大大提供的意見,找到了底下這兩篇文件:

看起來是 driver 的問題!然後跑到上面網站的連結,也就是底下的網站:

鳥哥安裝的是 qxlwddm-0.16-flexvdi.zip 這個檔案,結果竟然顯示的效果就好很多了!真是奇怪奇怪奇奇怪怪!鳥哥也不知道為何會這樣~ 真的是無奇不有~為了擔心這個檔案日後不見去,我把這個檔案複製一份到 這裡來 了, 單純備份而已,不做其他應用!


插上 PCI-E 擴充卡在個人電腦主機上,原本主機板上面的記憶體竟然消失不見了(2013/04/19)

在 2013 年初,鳥哥買了幾片 10G 的 PCI-E 8x 的網卡在進行一些研究,我的主機板上面原本有 8Gx4=32G 的記憶體在。插上 10G 的網卡後,竟然發現記憶體插槽第三槽 (slot 3) 上面的記憶體無法抓到了!拔掉 10G 網卡就恢復正常~很怪。更新了 BIOS 以及相關的 BIOS 內設定,都沒有辦法解決這個問題~困擾了一個多月啊!!

查詢了很多資料,都沒有人說到解決方案。最終詢問一些常常幫客戶作客制化的硬體廠商,他們的經驗是,因為個人電腦製造商根本不會想到一般用戶會拿主機板安裝這些高階擴充卡, 所以,當插了這些擴充卡之後,BIOS 恐怕會誤判硬體,導致記憶體就憑空消失!這在他們的經驗中,還挺常發現的!鳥哥的問題是 10G 網卡, 他們的問題則是發生在 RAID card 上頭~因為他們經常幫客戶組裝白牌的 RAID 機器設備。

怎麼解決呢?非常有趣!廠商跟我說,只要將 PCI-E 金手指,那個 pin 5, pin 6 腳位使用膠帶黏起來,讓它不會過電,一切問題就解決了! 鳥哥原本是半信半疑,後來跑去查 wiki 的 PCI-E 腳位定義,發現到 pin 5, pin 6 主要是定義 PCI-E 擴充卡匯流排的時脈 (SMBus) ,除此之外,並沒有其他特殊的功能! 也不是負責傳輸的 LANE~於是乎,鳥哥就很開心的請會作手工藝的學生將兩個腳位貼起來膠帶。

效果驚人!立刻抓到消失的記憶體!太開心了!提供給大家參考!如果有發現同樣問題的話,可以這樣解決看看!相當有趣喔! ^_^!原本鳥哥會擔心這樣會不會造成效能方面的困擾 趕緊實測一下~竟然沒有任何問題!運作上也很順暢!真是開心又愉快啊! ^_^

不過,廠商說的也有道理,既然主機板原本的設計就不是給這些設備用的,還是買高階的 server 設備來安裝這些卡使用比較好~這...鳥哥也知道啊! 不過,窮老師有窮老師的苦處啊~~



2013/04/19:將遇到的問題寫下來,做為未來可能發生問題的解決方案:
   http://linux.vbird.org is designed by VBird during 2001-2017.