寻找 mod_perl ISP... 或成为其中之一

2002年5月22日，作者：Stas Bekman

简介

本文将讨论提供 mod_perl 服务的细微差别，并介绍一些成功提供这些服务的 ISP。

您在家里的机器上安装了 mod_perl，并且爱上了它。因此，现在您想将您的 CGI 脚本（目前正在您的首选 ISP 的机器上运行）转换为在 mod_perl 下运行。然后您发现您的 ISP 从未听说过 mod_perl，或者他拒绝为您安装它。
您是 ISP 行业的老船员，您见过所有的事情，您知道有多少 ISP，您知道销售利润太低，无法让您满意。您正在寻找几乎没有人提供的新服务，以吸引更多客户成为您的用户，并希望比您的竞争对手有更大的市场份额。

如果您计划成为提供 mod_perl 服务的 ISP，或者正在寻找这样的提供商，这篇文章就是为您准备的。

详细信息

ISP 有三种选择

ISP 可能无法允许用户在主服务器上运行 mod_perl 脚本。这里有多个原因

脚本可能会由于编程不严谨而泄漏内存。将没有足够的内存来运行所需的服务器数量，并且由于服务速度慢，客户将不会对服务满意。

文件权限问题是非常重要的问题：任何被允许写入和运行 CGI 脚本的用户至少可以读取（如果不是写入）属于同一用户和/或组的其他任何文件，这些文件是在 Web 服务器运行的同一用户和/或组下。请注意，在 mod_perl 下无法运行 suEXEC 和 cgiwrap 扩展。

另一个问题是数据库连接的安全性。如果您使用 Apache::DBI，通过修改 Apache::DBI 代码，您可以从缓存的连接池中选择一个连接，即使它是由其他人打开的，并且您的脚本正在同一 Web 服务器上运行。

还有更多需要注意的事情，所以现在您必须说不。

当然，作为一个 ISP，您可以内部运行 mod_perl，而不允许用户映射他们的脚本，这样它们就可以在 mod_perl 下运行。如果您作为服务的一部分提供脚本，如留言簿、计数器等，这些脚本不允许用户修改，您仍然可以让这些脚本非常快速地运行。
“但是，嘿，为什么我不能让我的用户运行他们自己的服务器，这样我就可以洗手不管他们，不必担心他们的代码有多脏、多乱？（假设用户在自己的用户名下运行自己的服务器，以防止他们相互窃取代码和数据。）”

这个选项是可行的，只要您不关心您的新系统资源需求。如果您对 mod_perl 有一些甚至非常有限的经验，您就会知道，启用了 mod_perl 的 Apache 服务器——虽然释放了 CPU，并允许您以更快的速度运行脚本——对内存的需求很大（是普通 Apache 的 5-20 倍）。

这些内存需求的大小取决于代码长度、编程的随意性、代码可能存在的内存泄漏，以及所有这些乘以服务器产生的子进程数量。一个非常简单的例子：一个服务器，服务于平均数量的脚本，需要10MB的内存，产生10个子进程，已经将您的内存需求提高了100MB（如果您的操作系统允许进程之间的代码共享，并且如果程序员在代码中利用了这些功能，实际需求实际上会更小）。现在，将平均所需大小乘以您打算拥有的服务器用户数量，您将得到总内存需求。

由于ISP从不说不，您最好采取相反的方法——想想您能承担的最大内存大小，然后除以一个用户的需要（如我在这个例子中所展示的），您就会知道您能承担多少个mod_perl用户 :)

但如果您不知道您的用户可能会使用多少内存怎么办？他们对单个服务器的需求可能非常有限，但您知道他们会运行多少个服务器吗？毕竟，他们有完整的控制权httpd.conf - 这也是必需的，因为这是用户运行mod_perl的关键。

所有关于内存的讨论都归结为一个问题：是否可以防止用户使用超过X内存？或者问题的另一种变体：假设您有足够的内存，您能否根据用户的平均内存使用量向他们收费？

如果以上任一问题的答案是是，您就万事俱备，您的客户会因为能够运行mod_perl而珍视您的名字！有工具可以限制资源使用（例如，查看ulimit(3)、getrlimit(2)、setrlimit(2)和sysconf(3)的手册页；后三个有相应的Perl模块BSD::Resource和Apache::Resource）。

如果您选择了这个选项，您必须为您的客户提供以下内容：
- 与您的其余守护进程启动脚本一起安装的关闭和启动脚本（例如，/etc/rc.d目录），这样当您重启您的机器时，用户的服务器将正确关闭，并且当您的系统启动时将立即上线。还要确保以服务器所属的用户名启动每个服务器，否则您会遇到大麻烦！
- 为用户的虚拟主机提供代理服务（在前向或httpd加速模式下）。由于用户必须在非特权端口（>1024）上运行他们的服务器，所以您必须将所有从user.given.virtual.hostname:80（这是没有默认端口80的user.given.virtual.hostname）到your.machine.ip:分配给用户的端口的请求进行转发。您还必须告诉用户编写脚本，以便任何自引用URL的形式为user.given.virtual.hostname。
  
  允许用户运行一个mod_perl服务器立即增加了用户能够重启和配置自己服务器的需求。只有root可以绑定到端口80；这就是为什么您的用户必须使用大于1024的端口号。
  
  另一个解决方案是使用setuid启动脚本，但在您决定这样做之前请三思，因为如果用户可以修改脚本，有时他们可能会获得root访问权限。
- 您还必须解决的问题是如何为用户分配端口。由于用户可以选择任何大于1024的端口来运行他们的服务器，所以您必须在这里制定一些规则，以便多个服务器不会冲突。
  
  一个简单的例子将展示这个问题的重要性。我可能是一个恶意用户，或者我只是某个在你的ISP上运行服务器的同行竞争对手。我所需要做的只是找出我竞争对手的服务器正在监听哪个端口（例如使用netstat(8)），然后配置我的服务器在相同的端口上监听。尽管我无法绑定到这个端口，但想象一下当你重启系统时，我的启动脚本恰好在我的竞争对手之前运行会发生什么！我首先获取端口，现在所有请求都将被重定向到我的服务器。接下来会发生什么，就留给你的想象力去想象了。
  
  当然，丑陋的事情很快就会暴露出来，但在造成损害之前。
基本上，你可以为每个用户预先分配一个端口，这样他们就不必担心寻找一个空闲的端口，同时通过实现以下场景来实施MaxClients和类似的值

对于每个用户，有两个配置文件：主文件httpd.conf（用户无法写入）和用户的文件username.httpd.conf，其中他们可以指定自己的配置参数并覆盖httpd.conf中定义的参数。以下是主配置文件的外观
```
  httpd.conf
  ----------
  # Global/default settings, the user may override some of these
  ...
  ...
  # Included so that user can set his own configuration
  Include username.httpd.conf

  # User-specific settings which will override any potentially
  # dangerous configuration directives in username.httpd.conf
  ...
  ...

  username.httpd.conf
  -------------------
  # Settings that your user would like to add/override, like
  # <Location> and PerlModule directives, etc.
```
Apache首先读取全局/默认设置。然后读取包含用户选择的设置的Includeusername.httpd.conf文件，最后读取我们不想让用户覆盖的用户特定设置，例如端口号。即使用户在他们的username.httpd.conf文件中更改端口号，Apache也会最后读取我们的设置，因此它们优先。请注意，您可以使用<Perl>部分使配置更加容易。
一个更好但成本更高的解决方案是托管。让用户将他们的（或你的）独立机器连接到你的网络，然后忘记这个用户。当然，用户或你将不得不承担所有系统管理任务，这将使你的客户支付更多的费用。

寻求mod_perl支持的人是谁？他们是运行重大项目/业务的人。钱通常不是障碍。他们可以承担一个独立盒子的费用，从而实现他们的自主目标，同时让ISP满意。