有一些常見的小問題，或者是突然發現的一些困擾，不是可以長篇大論的文件，那就寫成 FAQ 吧！
很多時候，我們玩 Linux 會遇到很多軟體或者是硬體的問題，尤其是硬體的問題最奇怪了！因為擔心未來鳥哥自己還會遇到相同的狀況， 所以，將自身遇到的狀況給他寫下來～希望大家如果有遇到相同的問題時，可以很快速的解決呦！
這個已經是發生在半年以前的事情了！剛剛因為同事在詢問，所以才又回想起來，應該要寫寫才對。 因為 RockyLinux 9 已經穩定的運行一段時間了，當初剛剛設定好 RockyLinux 9 的 server 時，要從舊的系統登入進來， 或者是從 RL9 登入到其他系統去，似乎都無法 ssh。以為是防火牆的問題～檢查老半天，並不是！後來查詢到，應該是 ssh key 交換的問題所致，但是似乎也無法簡單透過 ssh -o "option..." 的方式來解決！就很頭疼！
解決的方案很簡單！但是確實很擔心會出問題...所以不要在比較重要的 server 上面實施～比較次要的系統加裝比較嚴謹的防火牆機制後， 或許就透過將 RockyLinux 9 的加密機制降級，就能解決這個問題。鳥哥底下的動作，其實是在內部系統上面實施的， 這部系統是用來收集學生課堂作業，無法直接對外，也沒有對 Internet 連線，所以這樣進行就還算保險...
[root@linuxserver ~]# yum -y install crypto-policies-scripts [root@linuxserver ~]# update-crypto-policies --show DEFAULT [root@linuxserver ~]# update-crypto-policies --set LEGACY [root@linuxserver ~]# update-crypto-policies --check The configured policy matches the generated policy
這樣，就將 RockyLinux 9 的加密機制降級回以前的版本，跟舊版的系統互通就沒啥問題了。
系上有一部電腦教室內的防火牆系統，用來作為電腦教室內所有電腦的對外主控 gateway 功能，架設的時候，最新的系統是 CentOS 8， 所以，安裝的是 CentOS8 的環境。大部分的服務都沒有對外，主要進行 IP forwarder 的功能 (SNAT)，沒有開放 Internet 的主動連線， 因此，相對上是比較安全一點。防火牆規則設定上，也是僅有針對內網放行，外網幾乎都關閉！過去也不曾發生什麼嚴重的資安漏洞，原因是... 資安監測環境根本就無法 touch 到我們的主機啊！哈哈哈！
有趣的問題來了，學生因為還是覺得 CentOS 8 已經沒有維護，所以， 2022 年底認為，應該要『升級』一下才對吧！ 所以，將 yum 的 repository 改成 Rocky Linux 9...對！是鳥哥沒有教好...很抱歉...然後，該行為只是改變 url 位置而已， 學生們並沒有使用 yum update 之類的。只是，因為某些緣故，系統上面竟然自動更新了 glibc, openssl 等服務！很怪異！ 會發現這個問題，其實是因為，我們需要管理該部主機時，竟然只能在近端使用鍵盤螢幕接觸，無法使用 ssh 連線！ 連線雖然會成功，可以輸入『 yes 』的接受金鑰指令，但是...之後就被踢掉了！連出現可以輸入密碼的畫面也沒有！
主要是無法使用 ssh 連線進系統的問題，所以，一開始懷疑 openssh-server 以及 openssl 的軟體問題！先檢查這兩個軟體！ 使用 rpm -V openssh-server 等功能，確認軟體並沒有被移植！最終也使用 rpm -Va 去全部軟體檢查一次！都沒有 binary programs 被竄改的資訊。會不會是設定檔被改錯了？所以，連設定檔都回溯到最原始版本，重新啟動 sshd 服務！很怪！就是服務都可以啟動成功！ 但是，就是無法登入系統！使用 ssh -v 去查詢連線過程的資訊， key 的交換等等也都沒有問題！最後就是會被 sshd 停止連線...很怪異！
今天比較有時間去好好檢查一下，使用了底下的指令來看看，到底有多少軟體被錯誤更新了？
[root@linuxserver ~]# rpm -qa | grep el9
openssl-libs-3.0.1-43.el9_0.x86_64
glibc-common-2.34-28.el9_0.2.x86_64
compat-openssl11-1.1.1k-4.el9_0.x86_64
glibc-2.34-28.el9_0.2.x86_64
glibc-langpack-zh-2.34-28.el9_0.2.x86_64
glibc-gconv-extra-2.34-28.el9_0.2.x86_64
rsync-3.2.3-9.el9_0.2.x86_64
glibc-langpack-en-2.34-28.el9_0.2.x86_64
openssl-3.0.1-43.el9_0.x86_64
glibc-headers-2.34-28.el9_0.2.x86_64
glibc-devel-2.34-28.el9_0.2.x86_64
映入眼簾的第一個就是我的懷疑，openssl 耶！因為 openssh 後面使用到的，好像也跟 openssl 有關！ 因此，我的動作是，先將 /etc/yum.repos.d/ 裡面的 repository，不重要的先關閉，設定成 RockyLinux 9 的， 直接改回 Rocky Linux 8，然後使用 yum clean all 先將清單關閉，之後使用 yum downgrade openssl 降級～ 這樣 openssl 就可以恢復正常！不過...sshd 還是不能用啊！
接下來，我來看看到底 sshd 用了哪些函式庫，
[root@linuxserver ~]# ldd /usr/sbin/sshd
linux-vdso.so.1 (0x00007ffe5a8b4000)
libaudit.so.1 => /lib64/libaudit.so.1 (0x00007f4b32923000)
libpam.so.0 => /lib64/libpam.so.0 (0x00007f4b32713000)
....
libc.so.6 => /lib64/libc.so.6 (0x00007f4b30537000)
....
有趣的是，反而函式庫裡面沒有 openssl 相關的字眼！倒是有個 libc.so 呢！剛剛上面 rpm -qa 去查詢時，就有發現 glibc 喔！ 看起來，這家火也需要降級才對！因此：
[root@linuxserver ~]# yum downgrade glibc
降級了 glibc 之後，系統大部分都回溯到 Rocky Linux 8 的環境，應該 (只能這樣猜想) 沒有 Rocky Linux 9 的軟體了！ 這時，突然之間 ssh 可以使用了！很開心啊！
這個故事告訴我們，不要亂更動 yum 的 repository 網址！如果亂升級到不該去的地方，因為目前的軟體大多是動態函式庫連結方式， 很多指令與函式庫都有向外呼叫其他函式庫的功能！那就很可能會產生你可以升級，但是用到這個升級函式庫的其他舊軟體， 可能就像我們這次的情況一樣，舊軟體突然無法正常運作...雖然是可以順利啟動喔～這也是相當有趣的經驗！提供大家參考！
本日，強者我同事蔡董，突然拿筆電給我，說他最近將 RockyLinux 9 的系統升級到 9.1 (對！這兩週發布了！)。不過不巧的是， 不知道為啥，升級過程當中，筆電竟然當機了！當掉了！因為是升級過程當掉的，因此，問題可能很嚴重 (很多基礎軟體可能沒有設定好)。 再次開機後，無論選擇哪個核心，都無法順利進入系統了。
蔡董大大先使用 RockyLinux 9.1 的原版 USB 進行開機，進入 troubleshooting 模式，然後進入 chroot 的環境中， 啟動網路之後，透過 yum 重新進行安裝與整理。使用了 rpm -Va 去檢查所有系統之後，發現到沒有重大問題！於是， 就又重新開機。不過有幾個問題發生了：
所以，分析問題，很可能就是：
首先，鳥哥進入 RockyLinux 9.1 的 USB 開機後的救援環境中，然後使用 chroot /mnt/sysroot 的方式切換，之後到 /boot 裡面， 使用 dracut 指令將 initramfs 重新建立！由於蔡董之前已經將 RockyLinux 9.1 的軟體全部更新完畢！看起來就剩下 initramfs 有問題而已。 因此，使用 dracut 建立 initramfs 是沒有問題的！很快就搞定！
鳥哥去查了查 /var/log/messages 裡面，說是 Xorg 有一些問題，無法順利載入。但是，去查了主要資訊 /var/log/Xorg.0.log， 裡面卻沒有顯示任何錯誤訊息！甚至 Xorg.0.log 裡面還說，已經順利啟動 X 了...有點昏倒！因為找不到 X window 的問題， 所以，鳥哥就將開機環境設定為文字界面，使用 systemctl set-default multi-user 來處理。
因為這電腦畢竟是蔡董的！蔡董大大說，叫我先改 root 密碼，等到測試完畢之後，他可以再改回他原本的密碼！這樣密碼就不用流出來。 好喔！鳥哥在救援模式當中的環境下，確認一切檔案系統都是可讀寫的狀況，修改 root 密碼，卻一直出現『 passwd: Permission denied 』！ 我誰？我 root 捏～我有幾個懷疑：
查了查相關的權限資料，上面的問題都不存在！沒辦法，只好 google 一下。google 到有朋友說， /etc/pam.d/system-auth 的內容要改。 我去查看了一下，該檔案是連結到 /etc/authselect/ 目錄去的！不找還好，一找嚇一跳！靠腰啦！ /etc/authselect/ 裡面， 全部檔案的容量都是 0...看起來就是升級過程中，在驗證機制設定時，可能出問題，因此導致該目錄底下跟系統最重要的驗證機制全部都消失了！ 那怪不得舊核心開機也會無法載入 login: 或 X window 了！
重建 /etc/authselect 裡面的檔案，方法也是很簡單，使用底下的方式來處理即可：
[root@linuxserver ~]# authselect select sssd
這樣就搞定 /etc/authselect/ 底下的檔案，重新開機，選用新核心，順利進入文字界面，登入 root 之後，下達『 systemctl isolate graphical 』 就可以轉成圖形界面！呵呵！搞定！
這是鳥哥第一次遇到這種狀況！我自己覺得非常有趣！所以趕緊紀錄下來！希望對大家能有幫助！
鳥哥的專題生跟我說，專題需要使用的網路速度似乎太慢，所以在某些 container 會用到的環境情境下，總是速度慢。 所以，我們跑去買了數張 10G 網卡，想說都換成 10G，可能效能會好一點。沒想到，在正常關機，然後安裝該網卡後，開機之後， 竟然發現，原本的 CentOS 的選單不見了！進 UEFI BIOS 畫面中，找不到該選單的進入點...夭壽了...現在大四，東西都在裡面！ 消失怎麼辦？
這幾部主機裡面，全部都是使用 4 顆傳統硬碟搭配主機板內建的 Intel raid 功能，建立了 raid10 的模式。這種模式在 Linux 底下，都會以 software raid 的狀態存在！而且裝置名稱，通常就是 /dev/md126 這樣！我們想說那就先來檢查一下 filesystem 好了。 沒想到使用原版光碟的 USB 開機後， lsblk 竟然只抓到 /dev/sd{a,b,c,d} 而已，並沒有找到 /dev/md126 耶！慘了！ 會不會整體 RAID 死翹翹？
1. 進 BIOS 查了查硬體，結果 Intel 主機板說，這個 RAID 是健康的！沒有任何磁碟有問題，看起來也不曾壞掉！
2. 繼續使用 USB 開機進入救援模式，嘗試使用底下的指令來再次建立 RAID 看看：
[root@linuxserver ~]# mdadm --assemble --scan
結果確實可以喚醒磁碟陣列喔！而且 (1)partition table 完整無缺 (使用了 gdisk /dev/md126 檢查，沒問題！) (2)檔案系統是健康的 (嘗試使用 mount 去掛載三個 partition，結果內容通通沒問題！)，也就是說，硬體沒問題、分割表正常、檔案系統正確， 並且將整個系統掛載後，使用 chroot 去瞧瞧，內容也沒有不同！而且， EFI 的 partition 內容全部都在！
後來想說，會不會是因為安插了 10G 卡，導致主機板會去分析目前的 UEFI 開機區，然後因為某些不明的原因， 導致 intel raid 的磁碟上面的 EFI boot menu 消失！導致無法找到進入點的緣故？所以，接下來的重點就變成『如何增加一個 UEFI 的開機選單』。
3. 想到開機，你應該會立刻想到 grub2 才對！不過，這次很特別，因為 UEFI 的開機是找 EFI partition，而不是找 MBR ！ 所以使用 grub2-install 是錯誤的想法！畢竟全部的資料確實還在 /dev/md126p1 裡面的 EFI/centos/* ！並沒有消失不見！ 所以並不需要重建他！
4. 最後找到 efibootmgr 這個玩意兒！這東西很有趣，可以用來查看、建立 UEFI 的開機進入選單呢！簡單的使用方式如下：
# 1. 列出目前的 UEFI 開機選單：
[root@linuxserver ~]# efibootmgr
BootCurrent: 0000
Timeout: 0 seconds
BootOrder: 0000,0001,0004,0005,0003
Boot0000* CentOS
Boot0001* CentOS2
Boot0003 網路卡
Boot0004* 硬碟
Boot0005* UEFI: ADATA USB Flash Drive 11
如上，那個 0000, 0001 指的是開機的選單編號，目前我們的 CentOS 選單在編號 0000 上面，而且開機順序 (Order) 是 0000, 0001, 0004, 0005, 0003 哩！另外，目前的開機 (BootCurrent) 用的是 0000 這個編號喔！
[root@linuxserver ~]# efibootmgr -v
BootCurrent: 0000
Timeout: 0 seconds
BootOrder: 0000,0001,0004,0005,0003
Boot0000* CentOS HD(1,GPT,f7d36e9d-434d-4615-905d-ba8090c7a44f,0x800,0x200000)/File(\EFI\centos\grubx64.efi)
Boot0001* CentOS2 HD(1,GPT,f7d36e9d-434d-4615-905d-ba8090c7a44f,0x800,0x200000)/File(EFIcentosgrubx64.efi)
Boot0003 網路卡 BBS(Network,,0x0)AMGOAMNO..........AMBO
Boot0004* 硬碟 BBS(HD,,0x0)AMGOAMNO............AMBO
Boot0005* UEFI: PciRoot(0x0)/Pci(0x14,0x0)/USB(8,0)/HD(1,MBR,0x1a1f9b19,0x800,0x739f800)AMBO
如上，CentOS 使用的是硬碟，且使用第一個 partition ，用的是 GPT 分割表，至於檔案則是在 \EFI\centos\grubx64.efi 上面！ 這個當然是建置成功後鳥哥重回系統來查閱的資料！事實上，上面的 CentOS2 就是我們在測試時，寫錯了的開機資料！ 開機引導程式一整個錯誤！哈哈！所以我們要刪除他！
[root@linuxserver ~]# efibootmgr -b 0001 -B
BootCurrent: 0000
Timeout: 0 seconds
BootOrder: 0000,0004,0005,0003
Boot0000* CentOS
Boot0003 網路卡
Boot0004* 硬碟
Boot0005* UEFI: ADATA USB Flash Drive 11
如上，很輕鬆的刪除了錯誤的資訊！如果要重建新的選單，應該使用如下的方式處理：
[root@linuxserver ~]# efibootmgr -c -d /dev/md126 -p 1 -L check -l /EFI/centos/grubx64.efi
BootCurrent: 0000
Timeout: 0 seconds
BootOrder: 0001,0000,0004,0005,0003
Boot0000* CentOS
Boot0003 網路卡
Boot0004* 硬碟
Boot0005* UEFI: ADATA USB Flash Drive 11
Boot0001* check
你應該使用『 efibootmgr --help 』查看一下所有的參數！另外，上面的 check 完全是暫時亂做的！測試完畢記得將他刪除！
鳥哥的網站因為多次移植與使用不同編輯器的關係，網站上面的資料充滿著不同的語系編碼版本！ 老舊的資料大多數還是 big5 編碼，新的網站資料則是鳥哥手動去進行 big5 轉 utf8 的動作。但是... 有一陣子很疲勞，所以，還是有一堆資料尚未轉到 utf8 啦！
過去在 CentOS6 的系統上，big5 網頁的顯示似乎沒有什麼問題！也都可以透過網頁自己的 header 去展示語系， 沒問題的。但是，昨天轉到 RockyLinux 8 之後，一堆朋友就開始來信留言，說已經看到 big5 網頁變亂碼了！ 鳥哥早就將 Apache 的 httpd.conf 裡面的『 AddDefaultCharset 』關閉，所以 http 不會主動傳出 utf8 的語系， 但這樣還是不行！相當傷腦筋！
查了查資料，原來是 PHP 也會傳送預設語系編碼...你可以在 /etc/php.ini 裡面查到這一段：
[root@linuxserver ~]# vim /etc/php.ini
.....
default_charset = "UTF-8"
.....
鳥哥測試過將上述設定註解，然後重啟 httpd 服務，結果也是持續傳輸出 UTF8 的編碼，導致 big5 網頁還是亂碼！ 後來發狠了！既然如此，我就來強迫 php 網頁使用 big5 好了！所以在 .php 的網頁上，最前面加上這樣即可：
[root@linuxserver ~]# vim webdemo.php
<?php
header('Content-Type: text/html; charset=big5');
?>
這樣網頁才終於可以順利的展示中文...看起來，還是不要懶惰，漸漸將資料移轉到 https 吧！順道轉換格式與編碼！唉！ 繼續操下去！
今天有個朋友問到，假如我想要讓某一群帳號不能在本機登入 X 視窗，該如何處理啊？鳥哥一直朝向 /etc/gdm/custom.conf 以及 /etc/dconf/ 的內容去搜尋， 但是總是找不到比較好的解決方案，大部分的方案都是在解決登入的帳號隱藏的狀態，而不是處理不許登入的狀態！所以，想到很頭疼！
最後還是回到 Linux 傳統的登入控制嵌入模組，那就是 PAM 模組的處理。好佳在， gdm 提供了 gdm-password 的檔案， 在這個檔案裡面新增一行，使用 pam_succeed_if.so 的模組，讓 pam 判斷某帳號有沒有在某群組裡面， 就能夠讓某群組不能使用 gdm 了！還挺簡單的！很有趣！
[root@linuxserver ~]# vim /etc/pam.d/gdm-password auth [success=done ignore=ignore default=bad] pam_selinux_permit.so auth required pam_succeed_if.so user notingroup denygroup auth substack password-auth ..... [root@linuxserver ~]# usermod -a -G denygroup username
將使用者將入到該群組，那這個帳號就不能使用 GDM 登入了！其他方式的登入倒是沒問題的！有趣吧！
今日學生持續來哭喊，說沒有網路啦！鳥哥緊急連線進去教室的 server 查看，結果...以為系統掛了！ping 的到， 但是 ssh 連線進去慢到想哭，不過，確實是可以連線進去，就是很慢！不過，連線成功之後，操作系統倒是還可以，只是， 想要重新啟動感覺有問題的防火牆系統時，卻發現到無法啟動啊！一直會出現 timed out 的結果！但是，事實上卻是有重新啟動成功！ 相當的令人難以理解：
[root@linuxserver ~]# journalctl 3月 13 14:02:07 linuxserver dbus[1735]: [system] Failed to activate service 'org.freedesktop.systemd1': timed out 3月 13 14:02:07 linuxserver systemd-logind[6300]: Failed to enable subscription: Failed to activate service 'org.freedesktop.systemd1': timed out 3月 13 14:02:07 linuxserver systemd-logind[6300]: Failed to fully start up daemon: Connection timed out 3月 13 14:02:07 linuxserver systemd[1]: systemd-logind.service: main process exited, code=exited, status=1/FAILURE 3月 13 14:02:07 linuxserver systemd[1]: Failed to start Login Service. 3月 13 14:02:07 linuxserver systemd[1]: Unit systemd-logind.service entered failed state. 3月 13 14:02:07 linuxserver systemd[1]: systemd-logind.service failed. 3月 13 14:02:07 linuxserver systemd[1]: systemd-logind.service has no holdoff time, scheduling restart. 3月 13 14:02:07 linuxserver systemd[1]: Stopped Login Service. 3月 13 14:02:07 linuxserver systemd[1]: Starting Login Service...
查了查一些論壇相關的說明，似乎是一個名為 polkit 的服務沒有辦法順利啟動的緣故，而 systemd-logind 又得要有這個服務的協助， 所以，就造成了 polkit 不見了，systemd-logind 啟動不了，系統的認證一直出問題，所以後來又從 journalctl 裡面看到這些資料：
[root@linuxserver ~]# journalctl 3月 13 10:16:18 linuxserver systemd[1]: polkit.service start operation timed out. Terminating. 3月 13 10:16:18 linuxserver systemd[1]: Failed to start Authorization Manager. 3月 13 10:16:18 linuxserver systemd[1]: Dependency failed for Dynamic System Tuning Daemon. 3月 13 10:16:18 linuxserver systemd[1]: Job tuned.service/start failed with result 'dependency'. 3月 13 10:16:18 linuxserver systemd[1]: Unit polkit.service entered failed state. 3月 13 10:16:18 linuxserver systemd[1]: polkit.service failed.
一直無法順利重新啟動！後來找到一篇說明，說是得要先檢查 dbus 這個匯流排才對！所以，就趕緊檢查看看：
[root@linuxserver ~]# busctl
NAME PID PROCESS USER CONNECTION UNIT
:1.0 1 systemd root :1.0 -
fi.epitest.hostap.WPASupplicant - - - (activatable) -
fi.w1.wpa_supplicant1 - - - (activatable) -
org.freedesktop.DBus 7516 dbus-daemon dbus org.freedesktop.DBus dbus.service
org.freedesktop.PolicyKit1 - - - (activatable) -
org.freedesktop.hostname1 - - - (activatable) -
org.freedesktop.import1 - - - (activatable) -
org.freedesktop.locale1 - - - (activatable) -
org.freedesktop.login1 - - - (activatable) -
org.freedesktop.machine1 - - - (activatable) -
org.freedesktop.nm_dispatcher - - - (activatable) -
org.freedesktop.timedate1 - - - (activatable) -
有點類似上面這樣，就是 PolicKit1 不見了！連帶 login1 也無法啟動！相當傷腦筋～最終的解決方法很好笑！因為無法重新啟動是由於 systemd-logind 找不到 polkitd 服務， 因此，我們就先手動啟動 polkitd (不是透過 systemctl)，然後再重新啟動 dbus 就好了！真見鬼！
[root@linuxserver ~]# /usr/lib/polkit-1/polkitd --no-debug & [root@linuxserver ~]# systemctl restart dbus [root@linuxserver ~]# systemctl restart systemd-logind
突然間，系統就正常了！這就正常了！但是，因為還沒有重新開機過～鳥哥我也不敢肯定未來就一定會順利... 這次是沒問題了！希望下次重新開機，系統還是好好的...
我們系上一直都用一台所謂的 ID server 來管理 LDAP 的驗證，同時啟用了 samba 進行 LADP 的處理。 一直都搭配的非常好！一直到今天，因為電力的問題，導致 ID server 斷電，因此重新開機。開機過後， 系統運作都是沒有問題，但，遠端 windows 就是無法進行 samba 的驗證～在 log (/var/log/messages) 裡面， 一直重複這個錯誤：
Mar 10 16:20:05 idserver1 smbd[4760]: [2020/03/10 16:20:05.489537, 0] auth/check_samsec.c:492(check_sam_security) Mar 10 16:20:05 idserver1 smbd[4760]: check_sam_security: make_server_info_sam() failed with 'NT_STATUS_UNSUCCESSFUL'
查了查 google，隨便找到兩篇似乎有點關聯的：
似乎是 Samba 裡面有個 SID 被改變掉了，因此，原本帳號的 SID 與重新開機過後的 Samba SID 已經不同步了！所以就引起這個問題。 見鬼了！開機前到底學生做了什麼事情呢？我想了想，啊！有請學生進行備援工作，可能是備援的問題嘛？去查了 /etc/hosts， 發現主機名稱改變了，然後，在 Samba 這部 Linux 系統上面測試一下，先關閉 smb 之後，用 smbd 直接檢測：
[root@idserver1 common]# /usr/sbin/smbd --interactive --debuglevel=3 ...... Forcing Primary Group to 'Domain Users' for 4060C001 The primary group domain sid(S-1-5-21-1004358217-1889577509-1049132106-513) does not match the domain sid(S-1-5-21-741082690-252565047-1259293557) for 4060C001(S-1-5-21-741082690-252565047-1259293557-3086) ......
確實回答 SID 不匹配所致。左側的 SID 應該是目前的，右側的 SID 則是以前正常運作的情況。後來使用 samba 提供的 net 指令來查查看：
[root@idserver1 common]# net getdomainsid SID for local machine IDSERVER1 is: S-1-5-21-1004358217-1889577509-1049132106 Could not fetch domain SID
確實回答是這個 SID！天吶～那以前的 SID 是什麼？後來想想，以前登入系統的時候，系統的主機名稱明明是 localhost，為啥這邊顯示 IDSERVER1 呢？ 喔！原來是學生為了分辨實際運作機器與備援機器，分別重新設定主機名稱成為 idserver1 與 idserver2，但是 smb.conf 裡面卻沒有指定『 netbios name 』設定值！ 因此可能就導致 SID 自己跑掉了！我將 smb.conf 裡面增加『 netbios name = localhost 』之後，重新啟動 smb， 再次檢查 domainsid：
[root@idserver1 samba]# net getdomainsid SID for local machine LOCALHOST is: S-1-5-21-741082690-252565047-1259293557 Could not fetch domain SID
確實變回原本的 SID 了！之後，使用這台 samba 的所有其他設備，又可以開始登入了！實在不簡單... 原來隨便更改主機名稱，真的會倒大楣...
不知道大家有沒有這樣的經驗，就是啊，使用 CentOS 7 系統進行一些軟體開發或安裝時，由於第三方軟體『要求以 gcc 6.x 以上版本進行軟體編譯與安裝』的行為， 但是因為預設的 CentOS 7 的 gcc 版本只有...
[user@localhost ~]$ gcc --version gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-36) Copyright (C) 2015 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
可以看到，版本僅到 4.8.5 而已，也就是說，官方釋出的版本就是在 4.8.5 啦！但如果你到 gcc 的官方網站去查詢時，可以發現到最新的版本在 2019/08 已經來到 9.2 版了～那你可以自己編譯 gcc 來安裝新版本嘛？ 這個，對新手來說，不是很建議～因為 gcc 包涵太多的函式庫資料，亂處理會出事的。
為了這樣的需求，事實上， CentOS 有針對不同的版本提供了某些特殊的功能喔！包括提供不同的 gcc 發展軟體組，以及更新版本的 libvirtd 或 qemu 的版本呢。 你可以這樣追蹤一下相關的釋出軟體資料：
[user@localhost ~]$ yum search centos-release
centos-release.x86_64 : CentOS Linux release file
centos-release-ansible26.noarch : Ansible 2.6 packages from the CentOS ConfigManagement SIG repository
centos-release-azure.noarch : Yum configuration for CentOS Virt SIG Azure repo
....
centos-release-qemu-ev.noarch : QEMU Enterprise Virtualization packages from the CentOS Virtualization SIG repository
centos-release-scl.noarch : Software collections from the CentOS SCLo SIG
centos-release-scl-rh.noarch : Software collections from the CentOS SCLo SIG (upstream scl only)
...
上面那個 centos-release-scl 相關的字樣，就是軟體開發套件組。鳥哥因為自己工作環境的需求，需要較高版本的 gcc 與 gfortran，那怎麼處理？只好透過安裝這個資料了。 基本上， centos-release-* 給予的，其實只是一個軟體倉庫，安裝好之後 (其實就是設定 /etc/yum.repos.d/*.repo) ，還得要安裝正確的軟體才行。
# 先安裝好軟體倉庫，並且查閱軟體倉庫的列表 [root@localhost ~]# yum -y install centos-release-scl [root@localhost ~]# yum repolist repo id repo name status base/7/x86_64 CentOS-7 - Base 10,097 centos-sclo-rh/x86_64 CentOS-7 - SCLo rh 8,548 centos-sclo-sclo/x86_64 CentOS-7 - SCLo sclo 804 extras/7/x86_64 CentOS-7 - Extras 304 updates/7/x86_64 CentOS-7 - Updates 311 repolist: 20,064 # 查詢 devtoolset 軟體有哪些版本？並且安裝最新版 (2019/09 時，最新為 devtoolset-8 喔！ [root@localhost ~]# yum search devtoolset .... devtoolset-8-gcc.x86_64 : GCC version 8 devtoolset-8-gcc-c++.x86_64 : C++ support for GCC version 8 devtoolset-8-gcc-gdb-plugin.x86_64 : GCC 8 plugin for GDB .... [root@localhost ~]# yum install devtoolset-8
此時你的系統裡面會有兩個 gcc 的版本，預設系統還是會使用 gcc 4.8.x 那一版。而如果你需要使用到 gcc 8.x 的編譯器與相關的函式庫時， 就得先轉到 devtoolset 的環境下才可以！否則，還是會使用到舊版的 gcc 函式庫喔！那切換版本的方式為使用 scl 這個軟體喔！
# 第一種方式，使用 scl 提供的軟體功能 [user@localhost ~]$ scl enable devtoolset-8 bash # 雖然官方建議使用這個方式，不過，鳥哥因為自己有額外的 bashrc 設定值，因此還是會導致使用到舊版 gcc 喔！ # 第二種方式，如果你跟鳥哥一樣使用 bash 的話，可以直接呼叫環境變數即可 [user@localhost ~]$ source /opt/rh/devtoolset-8/enable [user@localhost ~]$ gcc --version gcc (GCC) 8.3.1 20190311 (Red Hat 8.3.1-3) Copyright (C) 2018 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
這樣你就可以開始使用新的 gcc 版本囉！
鳥哥在進行某些空氣品質的研究時，經常需要修改內容很多的檔案！但是，這些檔案的內容只有少部份重複的資料需要變更， 不過，鳥哥又不想要重新寫 fortran 程式來每一行都進行處理，畢竟只有少部份的資料要處理而已...那怎麼辦？ 其實，可以使用 bash 的 shell script 來簡易處理即可。
但是要使用 bash 來處理，又有個難度，以前檔案的處理，鳥哥個人習慣使用這樣的方式：
#!/bin/bash
filename="your_file_name"
lines=$( wc -l ${filename} | cut -d ' ' -f 1 )
for i in $(seq 1 ${lines} )
do
line=$( sed -n ${i}p ${filename} )
...
done
不過，這有個壞處～那就是，每一行都要從 sed 去重複讀取！我們知道這個檔案被讀過一次之後，就會被快取在記憶體內， 所以，基本上不會增加硬碟的讀取困擾，問題是，如果底下的程式碼比較大，那就得要一直重複呼叫 sed 這個 bash 的外部指令， 對於程式的執行來說，會有很大的缺點，那就是速度會被拖很慢！
比較好的解決方案，就是『只讀一次該檔案』，然後將這些檔案內的資料用陣列的方法紀錄下來。因為陣列也是 bash 的內建功能， 因此，我們就不用重複呼叫 sed，而是可以直接從 bash 內，將資料進行處理！在整理數據時，速度效能會快上很多！ bash 有提供一個 readarray 的功能，能將資料一口氣以行為單位進行陣列的儲存～方法如下：
#!/bin/bash
filename="your_file_name"
readarray myarray < ${filename}
myarray_count=${#myarray[@]}
for i in $( seq 0 $((${myarray_count}-1)) )
do
echo ${myarray[${i}]}
...
done
這樣直接處理 myarray 這個陣列，就可以直接在 bash 的記憶體程序裡面進行各項任務，而無須重複讀取外部檔案！
在崑山資傳系裡面，我們有自己建立的多重開機作業系統，以前都是使用 MSDOS 模式，今年暑假期間想來處理成為 UEFI 的模式，畢竟硬碟越來越大， 使用 GPT 分割表會比較妥當一些。不過，再透過 CentOS 7 的 grub2 進行維護管理時，裡面的設定值會失敗！無法順利開機！ 最原本的設定值是這樣的：
# 先來檢查原本的設定值： [root@localhost ~]# vim /etc/grub.d/40_custom #!/bin/sh exec tail -n +3 $0 # This file provides an easy way to add custom menu entries. Simply type the # menu entries you want to add after this comment. Be careful not to change # the 'exec tail' line above. menuentry "Windows 10 Class system" { insmod part_gpt insmod search_fs_uuid insmod chain set root=(hd0,gpt1) <==這裡是需要注意的項目！ chainloader /EFI/win10class/Boot/bootmgfw.efi } menuentry "Windows 10 Exam environment" { insmod part_gpt insmod search_fs_uuid insmod chain set root=(hd0,gpt1) <==這裡是需要注意的項目！ chainloader /EFI/win10exam/Boot/bootmgfw.efi }
經過 grub2-mkconfig 輸出設定值到 /boot/efi/EFI/centos/grub.cfg 之後，雖然可以順利進入選單，但是當選擇上述的 Windows10 時，螢幕上就會出現黑壓壓的一片， 只會出現這個錯誤：
Invalid sector size 65535
原本以為是我們的硬碟磁區 (sector) 不是傳統的 512bytes，而是 4K 的 sector 所致，但是查詢了網路的文件，最後發現，我們當初使用 USB 硬碟來安裝 Windows， 所以，windows 的 bootmgfw.efi 開機載入檔恐怕有點誤會了，因此使用『 set root=(hd0,gpt1) 』這種固定的磁碟代號，可能會無法順利開機所致。那該如何是好？ grub2 官方文件建議最好使用 filesystem 的 UUID 或 Label name 來指定磁碟位置較佳！所以，我們後來選擇可以自己設定的 LABEL name 來處置。唯一要注意的， 就是 windows 預設只使用大寫字元，所以可以這樣改寫：
[root@localhost ~]# dosfslabel /dev/sda1 DICBOOT [root@localhost ~]# vim /etc/grub.d/40_custom #!/bin/sh exec tail -n +3 $0 # This file provides an easy way to add custom menu entries. Simply type the # menu entries you want to add after this comment. Be careful not to change # the 'exec tail' line above. menuentry "Windows 10 Class system" { insmod part_gpt insmod search_fs_uuid insmod chain search --no-floppy --label --set DICBOOT <==這裡是需要注意的項目！ chainloader /EFI/win10class/Boot/bootmgfw.efi } menuentry "Windows 10 Exam environment" { insmod part_gpt insmod search_fs_uuid insmod chain search --no-floppy --label --set DICBOOT <==這裡是需要注意的項目！ chainloader /EFI/win10exam/Boot/bootmgfw.efi }
之後再重新使用 grub2-mkconfig 去更新你的設定檔，就可以躲避過這個 UEFI 的災難了！
最近緊鑼密鼓的處理環工方面的空氣品質模式新版編譯，遇到非常非常多的問題！其中一個很怪異的問題，發生在編譯 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
這種錯誤其實很常見，不過，鳥哥也是透過一次次的學習才知道處理的方法！為了避免自己忘記～寫到這裡來，分享給大家一起學習！
在鳥哥服務的單位中，我們的電腦教室每個學期常常需要進行大量的電腦裸機復原，電腦裸機復原需要用到很大型的 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 網卡那端囉！
我們系上為了教學方便，系上的網路系統就開始用了 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 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 ，交互測試一下喔！
前兩天有個網友突然問到了跟正規表示法比較有關係的資料，屬於延伸型的正規表示法。因為延伸正規表示法鳥哥真的很少用，所以許多的字符忘記了。 因此這個時候鳥站以前鳥哥自己寫的文章就有幫助了。於是上網去查自己的網站，結果...整個正規表示法的網頁竟然無法完全載入！ 然後，還有第 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 碼囉！
鳥哥在自己以前讀書的實驗室有擺放一 mail server，裡面有啟用 dovecot 的收發信件驗證功能。近期經常發現有數千筆資料嘗試猜測某些帳號的密碼。 之所以對方會知道我們的帳號，原因很簡單，只因為 email address 的寫法： username@hostname 這樣，所以攻擊者就會知道帳號與主機名稱， 接下來就可能會猜測密碼了...
每天幾千筆錯誤登錄資訊，害鳥哥疲於奔命～累了！還是讓系統自己去抓算了。由底下的連結知道 fail2ban 拒絕 ssh 的重複連線：
那能不能用在其他的服務呢？是可以的～使用的方法很簡單：
[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 筆以內，效果相當不錯！提供給大家參考。
這學期的 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 到同樣的數值較佳～一切順暢！相當怪異的情境啊～所以特別寫下來做個紀錄！
網友來信問到如果是 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 hosts 之間建立區網， 就快要死掉了！哪有可能建立數個獨立區網呢？後來想到不是有 VLAN 嘛？那就用 vlan 來玩玩看。 發現了可以透過網路卡直接加入 vlan 的通道！舉例來說，如果網卡的代號是 eth0 ，那麼 eth0.11 就是第 11 號 vlan 的通道 (tag=11)， 然後建立一個新的 bridge 附掛在這個 eth0.11 的網卡上，那就是一個 VLAN 了！最後，讓 VM 的 XML 檔案中， 使用的網卡為 bridge 且附掛在剛剛建立的 bridge 上，就搞定了！整個流程很簡單：
我這裡使用 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 這樣就對了！
然後你的 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 了呢！
最近在寫一些 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 底下，嘿嘿！就能夠被執行而不被查詢到程式碼！ 之後鳥哥就可以輕鬆的放一些偵測腳本，而不被學生直接分析，導致被攻破囉！
鳥哥所服務的單位是在崑山科大資傳系，系上的學生相當貼心，每個學期都會主動的協助鳥哥進行全系電腦的復原！我們的 PC 系統上面都會安裝多重作業系統， 提供多個不同的作業系統，以利各種教學所需要的特別環境。使用的復原系統為 DRBL 以及 Clonzilla ！
最近學生反應，五間教室裡面，有兩間復原 Linux 沒問題，有三間復原就出事！鳥哥覺得很納悶～去瞧了瞧，發現到：
因為最終出現 dracut ，而最新的 CentOS 使用的 initramfs 確實是在安裝核心時才開始打包，並非一開始就直接提供的！ 所以直覺上，鳥哥覺得應該是 initramfs 出錯了！所以解決的方案是這樣的：
鳥哥比較偷懶，不想要更改檔名，所以所建立的 initramfs 使用的是原本的檔名，這樣就不用修改 /boot/grub2/grub.cfg 檔案！ 重新開機後就正常了！ ^_^
三月初剛剛放假回到系上，立刻接到訊息，說我們系上管理的一個 IP 一直對學校的 DNS 主機進行攻擊！查了一下該 IP 的所在， 原來是系上提供給所有大三、大四進行專題實務的 Linux 伺服器組！一開始鳥哥以為是整個系統被攻破了！非常緊張！ 來到實體電腦實際使用 tcpdump 去抓封包，確實會對外查詢學校的 DNS 系統！我是這樣查詢的：
讀者可能會問，那奇怪了！為啥之前都沒問題，現在才發生問題呢？這是因為這樣的情況：
為了避免產生問題，所以鳥哥這樣處理過後，應該就不會有其他狀況的發生！
近年來因為雲端的關係，鳥哥跟夥伴們買了不少的 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 了！
一直以來教學測試的 VM 都是以 windows 7 為主，還沒有安裝過 windows10 在 VM 裡面。因為考慮到未來的使用情況， 所以安裝了 windows 10 的環境在 VM 底下，為了要加速，所以也使用了 KVM 建議使用的 spice (QXL) 顯示卡環境。
奇怪了！ windows 10 的 VM 環境顯示效果奇差無比！根據 netman 大大提供的意見，找到了底下這兩篇文件：
看起來是 driver 的問題！然後跑到上面網站的連結，也就是底下的網站：
鳥哥安裝的是 qxlwddm-0.16-flexvdi.zip 這個檔案，結果竟然顯示的效果就好很多了！真是奇怪奇怪奇奇怪怪！鳥哥也不知道為何會這樣～ 真的是無奇不有～為了擔心這個檔案日後不見去，我把這個檔案複製一份到 這裡來 了， 單純備份而已，不做其他應用！
在 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 設備來安裝這些卡使用比較好～這...鳥哥也知道啊！ 不過，窮老師有窮老師的苦處啊～～
