記一次詭異的故障排查經歷

每一次故障排查都是一筆財富，各類狗血通過不表，解決問題以後的那種知足是不可替代的。

背景

發佈系統架構圖簡化以下：

管理員經過Jenkins調用「發佈程序(代號varian，如下簡稱varian)」，發佈程序會進行一系列的初始化操做，完成後生成Docker鏡像上傳到Docker倉庫，容器集羣更新鏡像，用戶經過負載均衡訪問咱們的容器集羣。

老的varian採用shell+python開發，配合Jenkins(jdk1.7)進行發佈，因內部項目較多，寫了不少兼容腳本，代碼比較亂。咱們計劃對varian進行重構，徹底採用python開發，各個功能模塊化，不一樣類型的項目用樂高的思想拼裝模塊部署發佈，下降耦合。並將jenkins升級到最新版本，jdk一樣升級到1.8。新的varian已經開發完成，如今開始部署測試了，故事就由此開始。

爲了下降對現有項目的影響決定從新部署一套新的環境，徹底測試經過後將老環境廢棄，直接啓用新環境，新環境信息以下：

• 系統：Debian8
• 語言：Python3.4
• JDK1.8 + Jenkins2.134

故障處理過程

解決nginx訪問403的問題

經過Jenkins調用varian正常部署了一個靜態項目（純html，css，js等靜態資源），經過負載均衡訪問容器集羣（參考上邊架構圖），發現頁面樣式沒法加載，瀏覽器按F12調出控制檯發現個CSS文件返回403狀態

web服務用的nginx，腦海裏迅速過了一遍什麼狀況下nginx會返回403：

---

• nginx配置了白名單，client端訪問的IP不在白名單內

allow 192.168.0.152;
deny all;
複製代碼

• 訪問的路徑是個目錄，而nginx配置了禁止列目錄

#nginx中這個配置默認就是off，改爲on當訪問的路徑是目錄時，能夠列出目錄中的內容
autoindex           off;
複製代碼

• 訪問的路徑是個文件，但nginx服務配置的用戶和用戶組對文件沒有讀取權限

#nginx中這個配置指定nginx服務的用戶和用戶組 
user  www-data www-data;                                              
複製代碼

• 目錄索引index配置錯誤，例如你的目錄下只有index.html，你卻配置了index.shmtl或index.php等等

index index.shtml index.php;
複製代碼

---

常見的有以上問題會致使nginx返回403，迅速排查了一下，發現就是權限的問題致使的，nginx配置的用戶和用戶組爲www-data，而css文件的屬主屬組都是root，且其餘用戶沒有任何權限

# cat /etc/nginx/nginx.conf 
user  www-data www-data;

# ls -lh csl.css 
-rw-r----- 1 root root 7.9K Jul 24 12:34 csl.css
複製代碼

---

這裏再詳細講解下linux下的文件權限，以上邊的csl.css文件爲例：

-rw-r----- 1 root root 7.9K Jul 24 12:34 csl.css
複製代碼

以空格分割

• 第一段-rw-r-----10個字符定義了文件的權限
  • 第一個字符，這裏爲-表明這是一個文件，還會看到像d表明目錄、l表明鏈接
  • 剩下九個字符，每三個一組，第2-4個字符表明屬主權限，第5-7個字符表明屬組權限，第8-10個字符表明其餘用戶的權限
  • 其中每一組三個字符分別爲r、w、x，用數字表示r=四、w=二、x=1，分別表明讀、寫、執行權限，若是這個字符有值代表有這個權限，例如上邊css文件的權限就爲屬主有rw讀寫權限，屬組只有r權限，其餘用戶沒有權限
• 第二段爲一個數字，表示文件的鏈接數
• 第三段root表示用戶的屬主爲root
• 第四段root表示用戶的屬組也爲root
• 第五段則表示文件大小
• 後邊三段爲修改時間
• 最後一段爲文件名

---

好了，接着上邊的故障說，已經找到了是由於文件權限的問題致使的403，那麼修改了文件的權限爲644（其餘用戶有讀取權限），再次訪問順利返回正常狀態了。問題就這麼結束了嗎？固然不能，仔細想一想爲啥其餘的文件權限都ok，就這個文件權限不對？接着找緣由

tomcat8 UMASK

通過反覆測試，發現我直接在linux下經過控制檯執行python腳本的方式發佈部署最終文件權限正常，可是一樣的腳本通過Jenkins執行後權限就不對了。

控制檯執行跟Jenkins執行有什麼區別？帳號不同啊，遂把jenkins項目、tomcat文件都改爲屬主屬組都爲root從新執行，發現仍是同樣的結果。

再想一想還有哪裏不對，這個css文件是程序生成的，生成的文件權限不對，umask！這個詞忽然蹦出來，對，應該就是umask，他控制了生成新文件的權限。

---

簡單介紹下什麼是umask： umask值用來設置用戶在建立文件時的默認權限，跟設置文件權限命令chmod是相對的，總共四位，不過咱們一般只用後三位，一樣對應屬主屬組以及其餘用戶的權限，例如你的帳號umask值爲0022（可直接經過umask命令查看），此時你建立的文件權限默認爲644（文件初始的最高權限爲666，umask設置爲022，那麼最終的權限爲：6-0,6-2,6-2=644。固然有人說文件的權限最高是777，是的沒錯，但咱們說的是默認權限，默認權限是由umask決定的，umask設置爲000時文件的權限就是666，文件夾權限777），此時建立的目錄權限爲755（目錄的最高權限爲777，umask設置爲022，那麼最終的權限爲7-0,7-2,7-2=755）

---

查了root用戶的umask、jenkins用戶的umask，都爲0022，沒問題呀，而且登陸這兩個帳號建立了新文件權限也都正常，就剩下一種狀況了Jenkins！

Jenkins沒有地方能夠給配置UMASK，Jenkins跑在tomcat容器裏，老版本的varian也有類似的處理邏輯一直沒問題，本次升級了tomcat8，難道tomcat8更新了UMASK？半信半疑的看了下，果真！tomcat8的umask默認改爲了0027，麻溜的改爲了0022，問題順利解決

# vi tomcat/bin/catalina.sh 
if [ -z "$UMASK" ]; then
    UMASK="0027"
fi
複製代碼

終於破案了，還真相於世人！