No input file specified 记一次令人绝望的后端环境部署问题

  • Post author:
  • Post category:其他



背景


从别人那接手一个项目, 基于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手册的话, 想必对此问题能快速解决吧.




版权声明:本文为STchaoL原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接和本声明。