记一次诡异的故障排查经历

每一次故障排查都是一笔财富，各类狗血通过不表，解决问题以后的那种知足是不可替代的。

背景

发布系统架构图简化以下：

管理员经过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
复制代码

终于破案了，还真相于世人！