1. 首頁 > 生活 > >

nginx報403錯誤 nginx413錯誤

小知識nginx報403錯誤nginx413錯誤



文章插圖
nginx報403錯誤 nginx413錯誤

文章插圖
每一次故障排查都是一筆財富，各種狗血經過不表，解決問題之后的那種滿足是不可替代的 。
背景
發布系統架構圖簡化如下：
發布架構圖
管理員通過Jenkins調用“發布程序(代號varian，以下簡稱varian)”，發布程序會進行一系列的初始化操作，完成后生成Docker鏡像上傳到Docker倉庫，容器集群更新鏡像，用戶通過負載均衡訪問我們的容器集群 。
老的varian采用shell+python開發，配合Jenkins(jdk1.7)進行發布，因內部項目較多，寫了很多兼容腳本，代碼比較亂 。
我們計劃對varian進行重構，完全采用python開發，各個功能模塊化，不同類型的項目用樂高的思想拼裝模塊部署發布，降低耦合 。
并將jenkins升級到最新版本，jdk同樣升級到1.8 。新的varian已經開發完成，現在開始部署測試了，故事就由此開始 。
為了降低對現有項目的影響決定重新部署一套新的環境，完全測試通過后將老環境廢棄，直接啟用新環境，新環境信息如下：
系統：Debian8語言：Python3.4JDK1.8 + Jenkins2.134故障處理過程解決nginx訪問403的問題
通過 Jenkins 調用varian正常部署了一個靜態項目（純html，css，js等靜態資源），通過負載均衡訪問容器集群（參考上邊架構圖），發現頁面樣式無法加載，瀏覽器按F12調出控制臺發現個CSS文件返回403狀態：
chrome F12調試
web服務用的nginx，腦海里迅速過了一遍什么情況下nginx會返回403：
nginx配置了白名單，client端訪問的IP不在白名單內
訪問的路徑是個目錄，而nginx配置了禁止列目錄
訪問的路徑是個文件，但nginx服務配置的用戶和用戶組對文件沒有讀取權限
目錄索引index 配置錯誤，例如你的目錄下只有index.html，你卻配置了index.shmtl或index.php等等
index index.shtml index.php;常見的有以上問題會導致nginx返回403，迅速排查了一下，發現就是權限的問題導致的，nginx配置的用戶和用戶組為www-data，而css文件的屬主屬組都是root，且其他用戶沒有任何權限：
這里再詳細講解下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=4、w=2、x=1，分別代表讀、寫、執行權限，如果這個字符有值表明有這個權限，例如上邊css文件的權限就為屬主有rw讀寫權限，屬組只有r權限，其他用戶沒有權限第二段為一個數字，表示文件的連接數第三段root表示用戶的屬主為root第四段root表示用戶的屬組也為root第五段則表示文件大小后邊三段為修改時間最后一段為文件名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，問題順利解決！
說明：本文轉載自“運維咖啡吧”公眾號，點擊查看原文 。
【nginx報403錯誤 nginx413錯誤】2021年5月14-15，GOPS 2021 · 深圳站，早鳥票限時開啟~