|
bowei_99 has asked for the wisdom of the Perl Monks concerning the following question:
Hi all,
I have a couple hundred servers, most of which have perl installed. Unfortunately, they don't have many CPAN modules installed. I think a major reason is that it gets hard to manage.
Has anyone had to deal with this? Some solutions I can think of (none that seem palatable right now):
- running perl -e shell -MCPAN ... on each box, either by hand or by a script. This is quite resource- and time- intensive.
- NFS mounting modules from a central location, so you only have to install it once. This is hard, since some modules may or may not be included in a core distribution, so it's hard to know what to mount.
- Putting the scripts on a couple servers, and concentrate on managing those. This is what I've been leaning towards, but I'm realizing this is a simplistic view - that there are instances where I want to use perl on a machine that's not in my core group, and to do so, I'd have to forgo using modules I've gotten used to.
These boxes are a mix of HP-UX, Linux running perl 5.6.x to 5.8.x. Thoughts?
|
Re: Management of perl modules in enterprise?
by Ultra (Hermit) on May 31, 2006 at 09:06 UTC
|
| [reply] |
|
|
Referring to the link provided, one of the comments posted had a very good idea. Install a seperate version of Perl on the box and bring that version of Perl up to being the most current modules. Then change the /usr/bin/perl symlink to point at the new version. If your programs are having problems you can always point it back to the original version of perl that you have.
| [reply] |
|
|
That's still not a very good idea. Part of good sysadmin philosophy is to keep the OS itself as pure as possible and that means you do not replace tools that it comes with, including Perl. Why? Well, do you know what scripts came with the OS that use Perl? Do you know if swapping it out will break any of them? What about some 3rd party software that makes use of the Perl that comes with the OS? What about future patches, updates, and upgrades?
To be fair, this is probably not as obvious on Linux so let me give a better example: Solaris 8 comes with Perl 5.005_03. I think we can all agree that swapping this out for Perl 5.6.1 could be problematic and Perl 5.8.x would likely be even worse.
Short version is you should always install your own, separate Perl.
| [reply] |
Re: Management of perl modules in enterprise?
by derby (Abbot) on May 31, 2006 at 13:50 UTC
|
I would make a single staging server for each type of box (HP-UX, Linux, etc). I would then use CPAN on those staging servers to install and/or update. Once I was happy with the staging server(s), I would use something like rdist or rsync to update all the similarly configured boxes.
| [reply] |
|
|
I second derby on this one.
| [reply] |
Re: Management of perl modules in enterprise?
by Tanktalus (Canon) on May 31, 2006 at 15:50 UTC
|
What we've done is to set up the NFS, but we mount the entire perl distribution. That way we get rid of the 5.6 vs 5.8 complaints - all machines will have access to 5.8.7 (the version we standardised on).
We installed them with binaries in separate directories, but the modules all are installed to the same location. For pure-perl modules, this obviously works very easily. For XS-based modules, this means we need to compile/install once for each platform we support (AIX, Sun/SPARC, HP/PARISC, HP/IPF, Linux/ia32, Linux/ia64, Linux/x64, Linux/ppc64, Linux/390x). It's a bit of work, but it does mean that all of our machines always have access to everything. Or none of them do.
| [reply] |
Re: Management of perl modules in enterprise?
by perrin (Chancellor) on May 31, 2006 at 13:10 UTC
|
I described an approach we use for keeping a specific set of modules installed here. | [reply] |
Re: Management of perl modules in enterprise?
by rvosa (Curate) on May 31, 2006 at 19:25 UTC
|
The CPANPLUS remote daemon allows you to administer several machines at once. From the pod:
New in the 0.05x series is the CPANPLUS Daemon. This application allows you to remotely control several machines running the CPANPLUS Daemon, thus enabling you to update several machines at once, or updating machines from the comfort of your own desktop. This is done using CPANPLUS::Shell::Default's dispatch_on_input method. See the CPANPLUS::Shell::Default manpage for details on that method.
| [reply] |
|
|
But, then, the CPANPLUS::Shell::Default page (or at least the version of it currently on cpan.org) provides no "details" beyond:
$ui->dispatch_on_input('x'); # update the source using the
# dispatch method
Those two lines are the only times the string "disp" appears on the page. | [reply]
[d/l] |
|
|
