我正在维护一些 CGI Web 应用程序，我正在将其迁移到新的 Linux Web 服务器，在该服务器上我有一个非管理员帐户，例如 www_maintainer。 因此，我正在安装 CGI /home/www_maintainer/ 中的应用程序，我想借此机会清理一下，特别是 cgi-bin/ 目录可以更好地组织；我想了解这方面的最佳实践标准。
例如，在 cgi-bin/ 内有名为 bin/ 和 lib/ 的子目录(包含二进制文件和库)是否正常辅助的东西？
我将描述一个具体的示例，即数学和数据绘图应用程序 gnuplot及其依赖项(libfontconfig、libpng、libgd、libjpeg、libreadline.so、...)。
Python 可能是另一个例子(发行版提供 2.4，但我需要 >2.6)，但是我希望管理员可以从包中安装 2.6，这样我就不必担心它。
新的网络服务器有 Scientific Linux (SL)，基于 Redhat RHEL。不幸的是，我们当前 SL 版本的发行版存储库没有提供我需要的 gnuplot 版本 4.4，因此它无法安装在 /usr/bin/ 等正常位置，因此我可以构建并安装它，它的依赖项位于非系统位置，例如 cgi-bin/tools/。实际的 CGI Web 应用程序是由脚本 launch1.sh 或 launch2.sh 启动的二进制可执行文件。
这是目录树和其中一些文件的图示(当然省略了许多目录和文件)。
cd /home/www_maintainer/www_root/
|-- html/
| |-- index.html
| `-- info.html
|-- cgi-bin/
| |-- gen/
| | |-- status.sh*
| | `-- sybase/
| | `-- DataAccess64/
| | `-- ODBC/
| | |-- lib/
| | |-- samples/
| | `-- spl/
| |-- exe1/
| | `-- launch1.sh*
| |-- exe2/
| | `-- launch2.sh*
| |-- javascript/
| | `-- check-input.js
| |-- scripts/
| | |-- decode.pl*
| | |-- generate-random-string.bash*
| | |-- gnuplot -> ../tools
| | `-- upload.php*
| |-- tools
| | |-- bin/
| | | |-- gnuplot*
| | | |-- python -> python2.6
| | | |-- python-config -> python2.6-config
| | | |-- python2.6*
| | | |-- python2.6-config*
| | | `-- xmlwf*
| | |-- etc
| | | `-- fonts/
| | |-- include/
| | |-- info/
| | |-- lib/
| | | |-- libfontconfig.so
| | | |-- libpdf.so
| | | |-- libreadline.so
| | | |-- libpng15.so
| | | |-- libpng15.so
| | | |-- pkgconfig/
| | | |-- libpng.so
| | | |-- libjpeg.so
| | | |-- libreadline.so
| | |-- libexec/
| | |-- man/
| | `-- share/
|-- tests/
| `-- results/
| `-- info/
| |-- readme.pdf
| `-- readme.html
|-- fonts/
|-- index.html -> html/index.html
|-- log/
| `-- log.txt
`-- tmp -> /tmp/
最好安装在 www_root 之外，例如在目录 /home/www_maintainer/bin/ 和 /home/www_maintainer/lib/ 中并配置网络服务器以允许这样做？
最佳答案
编辑:2012 年 5 月 23 日下午 3 点(太平洋时间)
如果您仅限于用户的目录，您几乎可以做任何您想做的事情。
常见的情况是，您将所有使用 CGI 的文件(Perl 等)放入 cgi-bin 目录中，然后您可以(并且可能应该)根据目的或应用程序将它们放入子目录中。
然后将非 CGI 文件放在 cgi-bin 目录的外部，其中包括任何裸 HTML 文件、图形文件、CSS 文件、JS 文件等.
对于由 CGI 文件使用但不直接由 Web 用户使用的任何程序，请勿将它们放入 Webroot 中，因为这是不必要的，并且如果 Web 用户可以向这些文件提交值，则可能会出现安全漏洞以某种方式进行的程序。
目录树示例:
/home/www_maintainer/public_html/index.html
/home/www_maintainer/public_html/images/logo.png
/home/www_maintainer/public_html/scripts/something.js
/home/www_maintainer/public_html/cgi-bin/application1/app1.cgi
/home/www_maintainer/public_html/cgi-bin/application2/app2.cgi
/home/www_maintainer/public_html/cgi-bin/application2/app2helper.cgi
/home/www_maintainer/tools/gnuplot/gnuplot
/home/www_maintainer/tools/python/python -> python2.6
/home/www_maintainer/tools/python/python2.6
/home/www_maintainer/tools/python/python2.6-config
然后在您的 CGI 文件中，确保根据需要正确设置工具的路径。 Web 用户没有必要直接访问这些工具，因此请不要访问这些工具。如果您通过 CGI 执行 python(在本例中我假设是这样)，请确保您的 shebang 行显示正确的路径；例如，#!/home/www_maintainer/tools/python/python。
原始答案:
许多应用程序(例如随 Debian 分发的应用程序)所做的是将其应用程序放在 /usr/share/lib/programname 目录中，然后使用 Apache 别名 和 ScriptAlias 将它们映射到基本 URL。这也是我过去运行我们自己的内部开发的应用程序的方式，而且效果非常好。
对于您的情况，我建议尽可能少地进行更改，除非您计划随着时间的推移越来越多地增强代码或系统。如果路径发生变化，进行更改可能会带来麻烦，特别是如果路径已添加书签，除非您想在配置中使用一些mod_rewrite。
您有任何具体示例可以用来演示我所描述的内容吗？
另外，关于古老的/usr/bin/python，您的系统是否完全是最新的？或者问题在于您的 Linux 发行版不推送更新版本？我会避免安装不受发行版包管理系统管理的 Python 版本。
关于apache - cgi-bin 目录中的基础设施标准，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/10586547/