Providing Perl on a shared web server
tom at eborcom.com
Thu Jan 26 15:13:50 PST 2006
On Fri, Jan 20, 2006 at 08:26:53AM +0000, Dave Evans wrote:
> I'm currently in the process of setting up a new shared web server
> 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?
I spent most of this afternoon designing the user interface for a Web
application, so I'll answer this while I've got my user-centric head
on. Almost a week late.
I imagine you'll have a mixture of people caring about Perl for
different reasons. Many will find CGI scripts that look interesting,
not understand how they work and try to run them. This raises
security issues for your other users.
Some will want to tie together lots of CPAN modules and write their
own applications. These people will notice changes in Perl and module
versions as subtle changes may break their applications in interesting
ways. Changing your system will affect the reliability of these
You might have other use cases, but these two extremes come to mind
quickly. You have a much clearer idea of who your users are and what
they want to do.
If you deploy your server with the current version of Perl and the
latest versions of CPAN modules, that's fine for now. But as time
passes, some of your users will want newer versions while others will
want the stability of older versions.
> 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).
This can still cause problems. Imagine you were to have a 2 year old
server today. Some users will want to run against MySQL 3.23, some
will have 4.0, some 4.1 and a few brave souls of 5.x. Each may want
different versions of the DBD or DBI.
I try to avoid doing clever things in shared environments nowadays,
and try to develop minimal functionality in isolated systems. I've
used VMWare, User Mode Linux and FreeBSD Jails to do this. Each
environment only needs the tools it cares about, so I don't have to
worry about interdependencies.
On the other hand, each user ends up with the responsibility of
managing their own virtual server. To what extent do your users and
your business care about power/flexibility as opposed to
> 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
I like this compromise. It would be neat if you could customise
CPAN.pm to skip the default questions on its first run with some
pre-canned sane answers. Each perl installation can have its own
configuration, so a user can have modules installed under
$HOME/cpan/perl.x.y.z without the different Perl versions conflicting.
CPAN.pm makes more sense than expecting users to run Makefile.PL or
Build.PL as it installs dependencies automatically. I still don't
know as much about CPANPLUS as I'd like, but that might provide useful
> Perl 5 is evolving far less quickly now
>From talking to Nicholas recently, I get the impression development
has picked up recently. He's working pretty much full time on
managing 5.8. There's lots of new stuff going into 5.8, some of it
back-ported or based on ideas from Perl 6. 5.10 doesn't look too far
So although 5.x development has slowed up over the past few years,
don't expect that to continue.
End of brain dump. I hope some of this helped a little. :)
More information about the MiltonKeynes-pm