In this article we will talk about the nuances of providing
services and present a few ISPs that successfully provide them.
mod_perlon your box at home, and you fell in love with it. So now you want to convert your CGI scripts (which are currently running on your favorite ISP's machine) to run under
mod_perl. Then you discover that your ISP has never heard of
mod_perl, or he refuses to install it for you.
- You are an old sailor in the ISP business, you have seen it all, you know how many ISPs are out there, and you know that the sales margins are too low to keep you happy. You are looking for some new service almost no one else provides, to attract more clients to become your users and, hopefully, to have a bigger slice of the action than your competitors.
If you are planning to become an ISP that provides
services or are just looking for such a provider, this article is for
An ISP has three choices:
ISPs probably cannot let users run scripts under
mod_perlon 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 slow.
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 under which the Web server is running. Note that it's impossible to run
Another issue is the security of the database connections. If you use
Apache::DBI, by hacking the
Apache::DBIcode 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_perlinternally, 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. that are not available for user modification, you can still can have these scripts running very quickly.
"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 user names, to prevent them from stealing code and data from
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 will know that
mod_perl-enabled Apache servers -- while freeing up your CPU and allowing you to run scripts much faster -- have huge memory demands (5-20 times that of plain Apache).
The size of these memory demands depends on the code length, the sloppiness of the programming, possible memory leaks the code might have, and all of 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, spawns 10 children and already raises your memory requirements by 100MB (the real requirement is actually much smaller if your OS allows code sharing between processes, and if 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, and then divide it by one user's requirements (as I have shown in this example), and you will know how many
mod_perlusers you can afford :)
But what if 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
All of 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
sysconf(3); the last three have the corresponding Perl modules
If you have chosen this option, you have to provide your client with:
Shutdown and startup scripts installed together with the rest of your
daemon startup scripts (e.g., the
/etc/rc.ddirectory), so that when you reboot your machine, the user's server will be correctly shut down and will be back online the moment your system starts up. Also make sure to start each server under the user name the server belongs to, or you are going to be in big trouble!
Proxy services (in forward or httpd accelerator mode) for the user's
virtual host. Since the user will have to run their server on an
unprivileged port (>1024), you will have to forward all requests from
user.given.virtual.hostnamewithout the default port 80) to
your.machine.ip:port_assigned_to_user. You will also have to tell the users to code their scripts so that any self-referencing URLs are of the form
Letting the user run a
mod_perlserver immediately adds the requirement that the user be able to restart and configure their own server. Only root can bind to port 80; this is why your users have to use port numbers greater than 1024.
Another solution would be to use a setuid startup script, but think twice before you go with it, since if users can modify the scripts, sometimes they will get a root access.
Another problem you will have to solve is how to assign ports to
users. Since users can pick any port above 1024 to run their server,
you will have to lay down some rules here so that multiple servers do
A simple example will demonstrate the importance of this problem. I am a malicious user or I am just a rival of some fellow who runs his server on your ISP. All I need to do is to find out what port my rival's server is listening to (e.g. using
netstat(8)) and configure my own server to listen on the same port. Although I am unable to bind to this port, imagine what will happen when you reboot your system and my startup script happens to be run before my rival's! I get the port first, and now all requests will be redirected to my server. I'll leave to your imagination what nasty things might happen then.
Of course, the ugly things will quickly be revealed, but not before the damage has been done.
From the Frontiers of Research to the Heart of the Enterprise
mod_perl 2.0, the Next Generation Stas Bekman will provide an overview of what's new in mod_perl 2.0 and what else is planned for the future in his talk at the upcoming O'Reilly Open Source Convention, this July 22-26, in San Diego.
Basically, you can preassign each user a port, without them having to worry about finding a free one, as well as enforce
MaxClientsand 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. It then reads the
username.httpd.conffile 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.conffile, Apache reads our settings last, so they take precedence. Note that you can use <
Perl> sections to make the configuration much easier.
- Shutdown and startup scripts installed together with the rest of your daemon startup scripts (e.g., the
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 of the system administration chores and it will cost your
client more money.
Who are the people who seek
mod_perlsupport? They are people who run serious projects/businesses. Money is not usually an obstacle. They can afford a standalone box, thus achieving their goal of autonomy while keeping their ISP happy.
Let's present some of the ISPs that provide
A Canadian company called Baremetal (http://BareMetal.com/) provides
mod_perlservices via front-end proxy and a shared
mod_perlbackend, which, as their technical support claims, works reasonably well for folks that write good code. They're willing to run a dedicated backend
mod_perlserver for customers that need it. Some of their clients mix
mod_perlas a simple acceleration technique.
Basic service price is $30/month.
For more information see http://modperl-space.com/.
BSB-Software GmbH, located in Frankfurt, Germany, provides their own
mod_perlapplications for clients with standard requirements, thus preventing the security risks and allowing trusted users to use their own code, which is usually reviewed by the company's system administrator. For the latter case,
httpd.confis under the control of the ISP, so everything is monitored.
Please contact the company for the updated price list.
For more information see http://www.bsb-software.com/.
Digital Wire Consulting, an open-source-driven Ebusiness
consulting company located in Zurich, Switzerland, provides shared and standalone
mod_perlsystems. The company operates internationally.
Here are the specifics of this company:
Previously in the Series
- No restrictions in terms of CPU, bandwidth, etc. (so heavy-duty operations are better off with dedicated machines!)
- The user has to understand the risk that is involved if he/she is choosing a shared machine. Every user has their own virtual server.
- They offer dedicated servers at approximately $400/month (depending on configuration) + $500 setup.
They don't support any proxy setups. If someone is serious about
mod_perlfor a mission-critical application, then that person should be willing to pay for dedicated servers!
For a shared server and a mid-size
mod_perlWeb site, they charge roughly $100/month for hosting only! Installation and setup are extra and based on the time spent (one hour is $120). Please contact the company for the updated price list.
For more information see http://www.dwc.ch/.
mod_perl! Their standard server can include
mod_perlif requested. All of their users are provided with a dedicated machine.
For more information see http://www.thebunker.net/hosting.htm.
mod_perl, see http://perl.apache.org/isp.html
If you are an ISP that supports
mod_perl and is not listed on the above page, please contact the person who maintains the list.