Providing Perl on a shared web server
mkpm-20051014 at djce.org.uk
Fri Jan 20 00:26:53 PST 2006
I'm currently in the process of setting up a new shared web server (virtual
hosting for many web site, probably eventually in the realm of 200-1000
sites). This server runs Apache, and supports the use of CGI scripts,
including those written in Perl.
My question is, do you have any insight into how I might manage issues
relating to versions of Perl, and versions / availability of CPAN modules?
For example, if I were to write a feature spec of the server, I might say:
"provides Perl >= 5.8.0 at /usr/bin/perl ; the following CPAN modules are
available: Time::HiRes DBI DBD::mysql Digest::SHA1".
On the old server (the one that this one is being built to replace),
Perl management went like this; /usr/bin/perl is 5.00503 [or whatever version
it actually was]. When a new version of Perl was needed, it was installed
elsewhere (/usr/local/bin/perl5.6.1). Various CPAN modules were installed in
their respective perl lib trees. From time to time if a site needed a CPAN
module which wasn't yet installed, it would be installed. Nothing ever got
removed, because we couldn't be sure which sites might be using it, and
therefore we didn't know what would break. Therefore the Perl installations
gradually multiplied and grew.
That, of course, is what I want to avoid.
So as far as installing extra Perl libs goes, my current theory is to provide
a few by default in the default @INC locations (e.g. DBI DBD::mysql etc). If
anyone wants any extra libs, they are welcome to install them, but they must
do so somewhere else (e.g. their home directory). Thus, management of those
libs becomes their responsibility, and we can tell which users (== which web
sites) might require which libraries.
Of course eventually there may come a time where /usr/bin/perl itself needs to
be upgraded, and I can't think of any easy way around that other than "just
upgrade it" (and don't provide multiple versions). This is probably less of
an issue than it was, say, five years ago, since Perl 5 is evolving far less
quickly now (and I have no plans to use/provide Perl 6).
Does the above approach sound reasonable? Anyone got any better ideas?
PGP key: http://rudolf.org.uk/pgpkey
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: Digital signature
Url : http://mail.pm.org/pipermail/miltonkeynes-pm/attachments/20060120/5cb4aa96/attachment.bin
More information about the MiltonKeynes-pm