From tom at eborcom.com Thu Jan 19 15:31:01 2006 From: tom at eborcom.com (Tom Hukins) Date: Thu, 19 Jan 2006 23:31:01 +0000 Subject: Meeting: Thursday 26th January Message-ID: <20060119233101.GA71908@eborcom.com> Happy New Year! Only 19 days late! Next Thursday, 26th January, sees the next miltonkeynes.pm social meeting in Wetherspoon's (near the railway station, not the one in the snow dome) as it's the last Thursday of the month. For directions, see the Web site: http://miltonkeynes.pm.org/ I'll be there from 7pm, as usual, but feel free to show up earlier or later. We'll probably end up discussing all manner of things Perl and non-Perl. Also, I'm in the process of planning our first technical meeting, which I'll announce soon. Put your thinking hats on and contemplate if you have anything interesting to talk about, even if for only 5 minutes. See you soon, Tom From mkpm-20051014 at djce.org.uk Fri Jan 20 00:26:53 2006 From: mkpm-20051014 at djce.org.uk (Dave Evans) Date: Fri, 20 Jan 2006 08:26:53 +0000 Subject: Providing Perl on a shared web server Message-ID: <20060120082653.GA4853@ratty> Hi, 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? Thanks, -- Dave Evans PGP key: http://rudolf.org.uk/pgpkey -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://mail.pm.org/pipermail/miltonkeynes-pm/attachments/20060120/5cb4aa96/attachment.bin From nik at ngo.org.uk Fri Jan 20 08:24:37 2006 From: nik at ngo.org.uk (Nik Clayton) Date: Fri, 20 Jan 2006 16:24:37 +0000 Subject: Providing Perl on a shared web server In-Reply-To: <20060120082653.GA4853@ratty> References: <20060120082653.GA4853@ratty> Message-ID: <43D10EC5.6070809@ngo.org.uk> Dave Evans wrote: > 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? Out of the box Perl doesn't support this sort of thing very well. Every solution I've seen is a variant of the same theme -- munge module installation so that each module installs in to a path that includes the module's version number. Then make sure that every module that wants to use another module doesn't do: use Foo::Bar; but does use lib '/path/to/Foo/Bar/version/x.y'; use Foo::Bar; Then, if you have multiple copies of Foo::Bar installed, one of them goes in /path/to/Foo/Bar/version/x.y, another goes in to /path/to/Foo/Bar/version/a.b, and so on. This is a pain because nothing on CPAN expects this sort of thing. There is a module on cpan, "only", which aims to make this sort of thing easier to manage. But it doesn't change the fact that you need to patch every third party module you use. A related solution -- are you providing shell accounts for your users? If so, you could build a custom version of Perl that's configured to install modules in $HOME/lib, and to look for non-core modules in $HOME/lib too. Then it's your user's responsibility to install whatever modules they need. You take the disk space hit if multiple users all install the same module, but disk space is cheap, and modules are normally tiny. N From nik at ngo.org.uk Fri Jan 20 08:24:40 2006 From: nik at ngo.org.uk (Nik Clayton) Date: Fri, 20 Jan 2006 16:24:40 +0000 Subject: Meeting: Thursday 26th January In-Reply-To: <20060119233101.GA71908@eborcom.com> References: <20060119233101.GA71908@eborcom.com> Message-ID: <43D10EC8.7090100@ngo.org.uk> Tom Hukins wrote: > Next Thursday, 26th January, sees the next miltonkeynes.pm social > meeting in Wetherspoon's (near the railway station, not the one in the > snow dome) as it's the last Thursday of the month. > > For directions, see the Web site: > http://miltonkeynes.pm.org/ > > I'll be there from 7pm, as usual, but feel free to show up earlier or > later. We'll probably end up discussing all manner of things Perl and > non-Perl. As usual, I'll not be there, Thursday being the day I normally have to stop working from home and go in to the office in Lewisham :-( Hope you all have a fun time. > Also, I'm in the process of planning our first technical meeting, > which I'll announce soon. Put your thinking hats on and contemplate > if you have anything interesting to talk about, even if for only 5 > minutes. I'll cheerfully talk about Subversion, svk, SVN::Web, and related technologies if anyone would find that interesting and/or is contemplating using Subversion/svk. N From mkpm-20051014 at djce.org.uk Sun Jan 22 04:54:36 2006 From: mkpm-20051014 at djce.org.uk (Dave Evans) Date: Sun, 22 Jan 2006 12:54:36 +0000 Subject: Providing Perl on a shared web server In-Reply-To: <43D10EC5.6070809@ngo.org.uk> References: <20060120082653.GA4853@ratty> <43D10EC5.6070809@ngo.org.uk> Message-ID: <20060122125436.GB5493@ratty> On Fri, Jan 20, 2006 at 04:24:37PM +0000, Nik Clayton wrote: > A related solution -- are you providing shell accounts for your users? If > so, you could build a custom version of Perl that's configured to install > modules in $HOME/lib, and to look for non-core modules in $HOME/lib too. > Then it's your user's responsibility to install whatever modules they need. > You take the disk space hit if multiple users all install the same module, > but disk space is cheap, and modules are normally tiny. Yes, all users will have shell access. Hence I had envisaged providing a few modules only in the system default location (@INC), preferably all managed via RPM; and if users require extra libs, then can download and install them via "perl Makefile.pl PREFIX=$HOME" (or whatever the magic phrase is). They would then have to add their own "use lib" (or set PERL5LIB etc). Hence, users have the power to use whatever the modules they want, and they also have the responsibility for making it work. As I said a few years ago upgrading /usr/bin/perl itself would have been a total pain too, but I don't anticipate having to upgrade perl much now. Thanks, -- Dave Evans PGP key: http://rudolf.org.uk/pgpkey -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://mail.pm.org/pipermail/miltonkeynes-pm/attachments/20060122/cfbd4271/attachment.bin From tom at eborcom.com Thu Jan 26 15:13:50 2006 From: tom at eborcom.com (Tom Hukins) Date: Thu, 26 Jan 2006 23:13:50 +0000 Subject: Providing Perl on a shared web server In-Reply-To: <20060120082653.GA4853@ratty> References: <20060120082653.GA4853@ratty> Message-ID: <20060126231350.GA32030@eborcom.com> 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 users' code. 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 reliability/hand-holding? > 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. 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 alternatives. > 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 away now. 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. :) Tom