背景
从别人那接手一个项目, 基于laravel的, 开发环境用的是LNMP, 现在要将这个项目部署到自己的服务器.
使用
LNMP一键安装包
, 在服务器配置lnmp环境, 然后将接手的项目解压到目录(/home/wwwroot/), 配置nginx的server块后, 用浏览器访问测试发现错误
No input file specified.
此时Chrome的开发者工具中显示请求
返回码404
*
解决方案可直接
参考博文
问题分析
- 凭经验, 首先确认nginx的index指令配置. 检查发现index指令正确配置
- 此时在网站根目录下新建index.html, 访问正常. 由此认为nginx配置正确、php-fpm配置出错.
-
检查php-fpm是否正常启动
由于nginx里将php代理转发到9000端口, 所以正常情况下php-fpm应启动并监听900端口
检查结果是php-fpm正常启动. 此时在网站根目录下新建test.php, 请求test.php, 问题依旧
No input file specified
test.php内容对laravel框架无依赖, 可排除laravel框架出问题的可能.
<?php
//test.php
phpinfo();
?>
-
搜索发现, 多篇文章指出
fastcgi的参数(fastcgi_param )
SCRIPT_FILENAME
设置出错会造成php请求响应404的问题. 在nginx.conf中添加日志格式用以打印变量SCRIPT_FILENAME, 打印日志, 检查发现
该变量正常无误
-
猜测可能是目录权限问题. 修改
www用户为可登录
(php-fpm的运行时用户配置为www, 关于后台应用程序及其用户权限配置建议, 可参考
这篇博文
), 切换当前用户为www
su www
测试结果为www用户可正常读取根目录下所有php文件.
- 偶然发现lnmp工具建立的默认server是可以正常响应php请求的, 检查正常server块和异常server块, 基本排除配置问题.
- 尝试性将网站根目录改为当前设置(public)的上一级目录并把test.php放在新的网站根目录下. 发现此时可正常请求该文件.
- 将test.php放置于网站任一非原设置(public目录)下, 均可通过url正常请求
-
此时判定, 仅限public目录下PHP文件不能正常响应请求.
据此搜索
禁止指定目录执行php
. 查阅多篇文章, 大多思路为
通过nginx的deny指令匹配请求并进行限制
. 检查nginx配置, 并未发现有相关过滤配置, 且由于之前使用多个不同url访问同一文件均出错, 基本可排除nginx请求限制问题 -
尝试性修改目录名为 pub ,依然无法正常请求.
基本排除nginx或php中设置了目录黑名单的可能
. - 考虑到这里, 怀疑public下有特定文件限制访问, 使用
ls -ahl
此时发现存在.htaccess和web.config, 但此两文件均不被nginx支持
- 尝试性新建public目录, 并将原有public目录下文件全部复制到新public中, 并将test.php放入其中
cp -R pub/* public/
尝试请求新public下的test.php, 可正常响应请求! 访问index.php, 亦可正常响应!
-
修改网站根目录为public,
问题解决
- 备份现有项目文件, 删除测试文件, 备份问题文件待研究
-
在桌面机(Windows 10)上打开文件, 发现原public目录下存在.user.ini文件
. 凭文件后缀名.ini可知其大概率为php的配置文件.
搜索之
问题解决
参考博文
从.user.ini的
文档
中可以知道, 这个相当于分布在各目录中的 php.ini, 可用于针对某目录单独配置php-fpm特定配置项,
可实现部分.htaccess文件的功能
.
打开原有项目文件中的.user.ini, 发现其指定了
open_basedir
且与我的服务器的路径不一致, 因此造成php-fpm拒绝执行该目录下php的情况.
另外, 在复制原public目录下文件到新public目录时, 并未将.user.ini复制到新目录(这一点我很奇怪), 所以可以正常响应请求
问题总结
其实本来已经定位到问题的关键点了, 但是在使用shell时却没有注意到.user.ini这么一个异常文件. 由于在Windows中不隐藏.user.ini且将.ini文件作为配置文件(这样它的图标就会不同), 才注意到这个特殊的文件.
另外, 对php的配置不清楚导致此问题迟迟无法发现.
自 PHP 5.3.0 起,PHP 支持基于每个目录的 .htaccess 风格的 INI 文件。此类文件仅被 CGI/FastCGI SAPI 处理。此功能使得 PECL 的 htscanner 扩展作废。如果使用 Apache,则用 .htaccess 文件有同样效果。
若在之前配置php能仔细阅读PHP手册的话, 想必对此问题能快速解决吧.