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 · 深圳站,早鸟票限时开启~