Mod Perl Icon Mod Perl Icon mod_perl for ISPs. mod_perl and Virtual Hosts

Prev | Contents | Search | Download | Next

Table of Contents:

[ TOC ]
The Writing Apache Modules with Perl and C book can be purchased online from O'Reilly and Amazon.com.
Your corrections of the technical and grammatical errors are very welcome. You are encouraged to help me improve this guide. If you have something to contribute please send it directly to me.
[ TOC ]

ISPs providing mod_perl services - a fantasy or a reality

If you are a user asking for a mod_perl service or an ISP considering to provide this service, this section should make things clear for both of you.

An ISP has three choices:

  1. ISPs probably cannot let users run scripts under mod_perl on the main server. There are many reasons for this:

    Scripts might leak memory, due to sloppy programming. There will not be enough memory to run as many servers as required, and clients will be not satisfied with the service because it will be slower.

    The question of file permissions is a very important issue: any user who is allowed to write and run a CGI script can at least read (if not write) any other files that belong to the same user and/or group the web server is running as. Note that it's impossible to run suEXEC and cgiwrap extensions under mod_perl.

    Another issue is the security of the database connections. If you use Apache::DBI, by hacking the Apache::DBI code you can pick a connection from the pool of cached connections even if it was opened by someone else and your scripts are running on the same web server.

    There are many more things to be aware of so at this time you have to say No.

    Of course as an ISP you can run mod_perl internally, without allowing your users to map their scripts so that they will run under mod_perl. If as a part of your service you provide scripts such as guest books, counters etc. which are not available for user modification, you can still can have these scripts running very fast.

  2. But, hey why can't I let my users run their own servers, so I can wash my hands of them and don't have to worry about how dirty and sloppy their code is (assuming that the users are running their servers under their own usernames, to prevent them from stealing code and data from each other).

    This option is fine as long as you are not concerned about your new systems resource requirements. If you have even very limited experience with mod_perl, you know that mod_perl enabled Apache servers while freeing up your CPU and allowing you to run scripts very much faster, have huge memory demands (5-20 times that of plain Apache).

    The size depends on the code length, the sloppiness of the programming, possible memory leaks the code might have and all that multiplied by the number of children each server spawns. A very simple example: a server, serving an average number of scripts, demanding 10Mb of memory which spawns 10 children, already raises your memory requirements by 100Mb (the real requirement is actually much smaller if your OS allows code sharing between processes and programmers exploit these features in their code). Now multiply the average required size by the number of server users you intend to have and you will get the total memory requirement.

    Since ISPs never say No, you'd better take the inverse approach - think of the largest memory size you can afford then divide it by one user's requirements as I have shown in this example, and you will know how many mod_perl users you can afford :)

    But you cannot tell how much memory your users may use? Their requirements from a single server can be very modest, but do you know how many servers they will run? After all, they have full control of httpd.conf - and it has to be this way, since this is essential for the user running mod_perl.

    All this rumbling about memory leads to a single question: is it possible to prevent users from using more than X memory? Or another variation of the question: assuming you have as much memory as you want, can you charge users for their average memory usage?

    If the answer to either of the above questions is Yes, you are all set and your clients will prize your name for letting them run mod_perl! There are tools to restrict resource usage (see for example the man pages for ulimit(3), getrlimit(2), setrlimit(2) and sysconf(3), the last three have the corresponding Perl modules: BSD::Resource and Apache::Resource).

    [ReaderMETA]: If you have experience with other resource limiting techniques please share it with us. Thank you!

    If you have chosen this option, you have to provide your client with:

    Basically you can preassign each user a port, without them having to worry about finding a free one, as well as enforce MaxClients and similar values by implementing the following scenario:

    For each user have two configuration files, the main file, httpd.conf (non-writable by user) and the user's file, username.httpd.conf where they can specify their own configuration parameters and override the ones defined in httpd.conf. Here is what the main configuration file looks like:

      
      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 reads the global/default settings first. Then it reads the Include'd username.httpd.conf file with whatever settings the user has chosen, and finally it reads the user-specific settings that we don't want the user to override, such as the port number. Even if the user changes the port number in his username.httpd.conf file, Apache reads our settings last, so they take precedence. Note that you can use Perl sections to make the configuration much easier.

  3. A much better, but costly solution is co-location. Let the user hook his (or your) stand-alone machine into your network, and forget about this user. Of course either the user or you will have to undertake all the system administration chores and it will cost your client more money.

    Who are the people who seek mod_perl support? They are people who run serious projects/businesses. Money is not usually an obstacle. They can afford a stand alone box, thus achieving their goal of autonomy whilst keeping their ISP happy.

[ TOC ]

Virtual Servers Technologies

As we have just seen one of the obstacles of using mod_perl in ISP environments, is the problem of isolating customers using the same machine from each other. A number of virtual servers (don't confuse with virtual hosts) technologies (both commercial and Open Source) exist today. Here are some of them:

[ TOC ]

Virtual Hosts in the guide

If you are about to use Virtual Hosts you might want to read these sections:

Apache Configuration in Perl

Easing the Chores of Configuring Virtual Hosts with mod_macro

Is There a Way to Provide a Different startup.pl File for Each Individual Virtual Host

Is There a Way to Modify @INC on a Per-Virtual-Host or Per-Location Basis.

A Script From One Virtual Host Calls a Script with the Same Path From the Other Virtual Host [ TOC ]

Prev | Contents | Search | Download | Next

Your corrections of the technical and grammatical errors are very welcome. You are encouraged to help me improve this guide. If you have something to contribute please send it directly to me.
The Writing Apache Modules with Perl and C book can be purchased online from O'Reilly and Amazon.com.

[ TOC ]
Written by Stas Bekman.
Last Modified at 03/10/2001
mod_perl icon
Use of the Camel for Perl is
a trademark of O'Reilly & Associates,
and is used by permission.