openresty编译之后访问403

1 手动编译openresty

在一般的生产环境中基本上都是使用openresty，用nginx的其实不是很多了，但是这个原则一般都是业务驱动，在需要的时候，才会使用各种各样的版本，不然的话，基本上就保持了一个稳定的版本，不会升级，也不会变更。

手动编译的好处在于能定制各种目录，定制使用各种模块，如果使用yum来进行安装，其实更加方便，只是所有的模块和配置都已经固化了，从而大部分场景中，都是进行手动编译。

手动编译先基本都是按照最简单的方式来，也就是直接执行./configure --prefix=/soft/openresty ,也就是直指定了一个目录，然后就开始make && make install，所有的操作平平无奇。

2 安装之后开始启动

安装完成之后，到指定的目录中，开始直接启动nginx，然后再使用curl localhost访问一下，发现是403 forbiden，很久未安装，有点懵逼，居然还能碰到这种报错。

从而直接查看了一下error log和access log，发现日志为403，error显示为html文件访问无权限，这一看就知道是这个目录无法访问，但是其实并不能一眼看出来是哪个权限开启了阻挡，这才是要命的。

重新创建一个用户，useradd fuck -M -s /sbin/nologin，也就是这个用户只是一个用户，然后重新编译，编译的时候，加入参数--user=fuck --group=fuck，指定用户来进行创建，在make完成之后，将生成的nginx二进制文件拷贝到安装目录中，然后把老的杀掉，新的重新启动，发现还是依旧报错403.

修改一下配置文件，将用户修改启动worker的用户设置为新加的用户，然后再进行reload，发现还是403，有点蛋疼了，还是不行。

找到对应worker 的进程id，然后执行strace -TTTf -p pid，查看一下有啥信息没，然后再次请求，发现系统调用还是stat这个文件的时候，没有权限。

有点蛋疼了，重新编译，加入--with-debug模块，看看debug的信息有没有，重复上述的过程，然后再修改配置，将error log的级别修改为debug，然后再次启动，发现再debug里面也是只有访问被拒绝。

好像有点没办法了，将配置文件中用户直接修改为root，然后再启动请求，发现是可以正常访问的，那么还是这个用户没有权限。

那就只能再测试这个用户的权限了，使用命令sudo -u fuck cat /soft/openresty/nginx/html/index.html,显示为无权限，然后再用sudo -u fuck cat /soft/openresty/nginx/html，依旧无权限，直接到最后sudo -u fuck cat /soft，也是无权限，从而就是这个目录有问题，查看一下目录的权限，发现是750，emmm，主用户是root，也就是其他用户都进不去，将目录权限chmod 755 /soft，恢复正常。

在上面排查的过程中，还进行了热部署的那种方法，也就是两个版本的nginx进行替换，先发送USR2信号，启动新的master进程，然后对老的master进程发送quit信号，进行关闭，在其中也发现了可能会中断请求，关闭了老的worker process，但是实际上新的worker process未启动。

小小的403问题，折腾了一圈。。。编译好久不用，幺蛾子点多。

关键点：

1 理论上来说，创建的目录权限一般都是755，不知道谁把这个目录的权限设置成了750.

2 查看用户权限的时候，在ng中，要么是使用nobody用户，要么是自定义用户，在查看用户权限的时候，使用切换用户来判断用户访问的权限sudo -u username ls /test

3 openresty进行编译之后，如果要进行热部署，热部署的步骤是什么，如何回滚，其实我感觉这种方式使用的不多，如果是容器，就直接升级镜像了，滚动升级比热部署安全的多了；如果是虚拟机，一般也是新加机器，然后升级加入，这样是完全无损的，热部署的步骤还是有点麻烦，而且线上操作，风险略高

4 在openresty中，有很多默认编译进去的模块，在想要自己的模块的时候，需要自己去定义或者找到对应的第三方模块加入进行编译，其实我觉得--with-debug可以编译进去，这样虽然ng的二进制文件大点，但是排查为debug模式的时候，还是比较方便的

问题环节：你认为nginx在reload的是不是平滑的？有没有风险？业务会不会有所感知？