nginx,php-fpm,mysql安装好之后是第一步。
将项目部署上去之后，然后访问，发现仍然无法访问。
按照以下步骤进行错误的排查：

  • 分析nginx的运行日志access.log和error.log
  • 分析php-fpm的运行日志www-error.log
  • 分析代码文件的权限
  • 分析selinux

通过分析，发现静态文件是可以访问了，至少api无法访问。由于前后端的代码分类，nginx在访问静态文件是不会讲请求转发给php进行处理，而是直接返回静态文件。因此可能是访问将请求转发给php-fpm处理时出现错误。

查看nginx的access.log 发现如下错误：
error
在网上搜到的答案基本上就是将nginx.conf中的php的配置改为

1
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;

这种解决方式没有错，我之前也是这么解决的。我这里配置是对的，因此确认不是nginx.conf的配置问题。

继续分析php-fpm的运行日志www-error.log
error
在这里找到了原因，文件缺乏写入的权限，因此报错，终止运行。

为了方便,我直接将无法写入的文件夹的权限设置为777。再次访问，发现仍然无法访问，依然是报上面的错误。

那么继续查找问题,开始分析selinux.

查看一下selinux的状态

1
2
3
getenforce 
返回
Enforcing

说明selinux是开启并且强制的。为了测试是否是selinux的问题。我暂时关闭selinux

1
2
setenforce 0
将selinux置为Permissive,宽容模式，不会限制访问，仅会给出警告

此时访问网站，发现可以访问网站的api。实在无法解决权限的问题，关闭selinux是个好办法，但是毕竟是会造成一些隐藏的安全问题，后面将会总结一下selinux。

下面分析一下nginx,php-fpm的权限

查看nginx在什么用户下运行：

1
2
ps aux|grep nginx
ps aux|grep php-fpm

nginx进程运行用户组
php-fpm进程运行用户组

再查看一下项目文件的用户和用户组：
为501:root

可以看到，三者都是运行在不同的用户和用户组下面，很容易造成权限问题，一次需要统一nginx,php-fpm以及项目文件的用户和用户组。

统一成www

1
2
3
4
5
groupadd www  
useradd -g www www  
修改nginx.conf 中的user
修改php-fpm.conf中的user和group
修改代码目录权限740

selinux

在前面我们配置web环境以及用户组之间的关系以及将文件权限设置成777之后，仍然会报错，没有访问权限，这时就需要从selinux上找问题。selinux是linux中的一个安全强化模块，它在linux的传统文件权限和用户关系上增加了一层访问控制，实现了更加严格的访问权限控制。

下面分析一下
传统文件权限和账户关系：自主访问 ，DAC

  • 自主访问：依据进程的所有者与文件资源的rwx权限来决定有无访问权限
  • Root具有最高的访问权限
  • 用户可以取得进程来控制文件权限

强制访问控制：MAC

  • 可针对特定的进程与特定的文件资源进行权限控制
  • 控制的主体变成了进程而不是用户
  • 每个文件资源也有针对该主题进程设置可取用的权限。

根据两种访问控制来判断，进程在向日志文件laravel.log写入时，没有通过selinux的审核。下面将分析selinux的日志，找出解决办法

查看selinux报错信息：

cat /var/log/messages | grep setroubleshoot

selinux log

根据提示

1
sealert -l f50903ba-8d28-407d-bfc8-15fbf7785605

selinux log

这里selinux给出了更加详细的信息，并且也给出了建议

1
2
semanage fcontext -a -t httpd_sys_rw_content_t 'xxx'
restoecon -v 'xxx'

设置后，生效有点慢，需要过一会儿才能生效。