这里是我当前的Apacheconfiguration的一部分，指的是cgi-bin的东西。 这个信息被包含在debian的默认configuration中。 这应该在现场/生产机器上删除？
ScriptAlias /cgi-bin/ /usr/lib/cgi-bin/ <Directory "/usr/lib/cgi-bin"> AllowOverride None Options +ExecCGI -MultiViews +SymLinksIfOwnerMatch Order allow,deny Allow from all </Directory> 如果你没有从/ usr / lib / cgi-bin /运行任何CGI，那就没有必要了。 也就是说，这是一个生产机器，所以要小心。
是的，它应该在生产系统上被删除 – 除非（当然）你正在使用它。 如果你不确定，这可能意味着你没有使用它。
这是为什么：使用这个configuration， cgi-bin/指向/usr/lib/cgi-bin以及其中的任何内容都可以被执行。 这是一个系统目录，所以通常取决于你使用系统的包pipe理系统安装了什么。 任何带有Web界面的软件（如某种监控软件或pipe理软件）都可能有一个cgi脚本文件。 这意味着简单地安装这样一个程序就足以让任何访问这个Web服务器的人（在公共Web服务器的情况下：所有人）都可以访问该Web界面。
假设你刚刚在/usr/lib/cgi-bin中以cgi文件的forms安装了一些具有web界面的系统pipe理软件，并且它具有诸如“1234”作为默认密码的东西。 更糟的是，这是在公共Web服务器上。 现在，每个人都可以打开http://www.yourserver.com/cgi-bin/foowebadmin ，使用“1234”login并更改您的PRODUCTION服务器的系统configuration。
当然，如果你有意使用这个function，你会照顾到正确的安全/authentication等等，一切都会好起来的。
就个人而言，我总是从启用站点的目录中删除debian附带的默认虚拟主机。 我也用对我们的环境来说是明智的东西来replaceapache.conf。
那些是configuration文件和dpkg（后端到apt-get）应该期望他们改变。 像puppet这样的工具以某种方式运行apt-get，以便在程序包更新其configuration时保持“旧configuration”，并且如果以交互方式运行apt-get，它会询问如果检测到configuration文件中的更改。
这是任何改变，不只是一个无法自动合并的冲突。 毕竟，即使可以合并，也可以产生一些你不想在系统中实现的configuration。
打破一个火焰战争（对不起，这应该真的在别处讨论，但我只需要说）：我的意见是，即使在安装守护进程，它不能自动启动。 对于任何体面的网站，默认configuration几乎总是错的。 （是的，我知道我可以设置dpkg选项，以便它不会启动，我宁愿它是默认的）