APM: The proper way to use CPAN on a server

[Montgomery Conner]

This may be slightly off-topic (as I'm not really addressing the question
about cpan-shell syntax problems), and I may be running the risk of starting
a flame war, sorry, but, speaking as a Developer (and former SysAdmin):
waiting on RedHat to distribute RPMs (a practice which is advised and
necessary for the system-Perl) is a *horrible* way to manage Perl modules
that are depended on by non-trivial applications.

I'm stuck in a RedHat environment and would never rely on them to get it
right for any of the critical systems I work on at my job if it could
possibly be avoided... RedHat's track record with Perl module maintenance is
not great (and this criticism isn't limited to RedHat: Apple had broken
system Perl libraries for many many months in 2008 also, and I'm positively
sure there are vendors with this problem).

If Perl is important to you and your job, build it yourself from source!

As a "best practice" for managing Perl and Perl modules here's what I do
(your mileage may vary):

   1. Compile and install a custom Perl (or multiple Perl versions) using a
   non-root account, perhaps under /usr/local or /opt. You can use symlinks to
   simplify the paths for these; and symlinks have the added advantage of
   flexibility... i.e. upgrades are simple. E.g. /opt/perl -> /opt/perl-5.10.1/
   , makes an eventual update to 5.12 trivial both to test and to implement
   with no changes required to consuming code simply by changing the
   appropriate symlinks. [Importantly, this way you can be sure that you aren't
   going to break the system Perl install by upgrading modules, which should
   put your SAs at ease. My advice: NEVER MESS WITH THE SYSTEM PERL, AND NEVER
   RELY ON IT FOR ALL BUT THE MOST TRIVIAL (simple one-off script) CASES! Sorry
   for shouting: I've learned the hard way that this is a recipe for pure
   frustration and pain...]
   2. Update your path: e.g. PATH=/opt/perl/bin:$PATH if you use bash... you
   can just stick this in your .bashrc.
   3. To address firewall restrictions in a corporate server environment
   that might make contacting a public CPAN mirror impossible, create your own
   mini-CPAN bundle to act as a local CPAN mirror on your secure network (or a
   local filesystem if that's not possible). This archive adds some maintenance
   overhead (you'll need to update it occasionally), but for any non-trivial
   installation base it is absolutely fantastic (and surprisingly easy to do)!
   See CPAN::Mini.
   4. Configure your CPAN shell to point to the URL of your mini-CPAN (any
   of file://, http://, or ftp:// are appropriate depending on how it is
   accessible). I find it convenient to store the mini-CPAN archive on a
   webserver and create a symlink under htdocs so that this archive is
   available on the internal network via http without having to get a firewall
   exception everytime you need to install a module from a public mirror... but
   you'll probably need to have a talk with your security team before you get
   the go-ahead. There's an additional advantage here in that if you are
   creating standard Perl packaged modules in your organization, they can be
   'injected' into your private mini-CPAN mirror for simple automated
   distribution via the CPAN shell to any end users who can access the URL of
   your mini-CPAN. Using sudo should not be required to install modules for
   Perls that have been installed by a non-privileged account: so, to install a
   module just issue the command 'cpan -i Some::Module' for any system who's
   CPAN shell is configured to point to this URL.
   5. For 'repeatable server builds' I've found it much easier to use a
   shared file-system (prefer a snap-mirrored NAS for HA reliability, but NFS,
   or SAMBA are possible too). Build the Perls there and create symlinks on
   each host according to any platform specific details: e.g. /opt/perl -> [
   /opt/NAS/perl-5.10.1, /opt/NAS/perl-5.10.1_x64 ]. So, now, (although you
   have to compile and install the same module for each individual Perl build)
   you can manage all the modules in one central location for all systems that
   have this mount... which could potentially be a very large installation
   base. This way the 'repeatable' part of any server build is as simple as
   adding a line to fstab so that the new device is mounted at boot and an
   appropriate symlink is created for each new host.


There's a small amount of overhead with this approach (not as much as you
think though, esp. compared to the alternatives), but it *scales well* which
is very important if you depend on a Perl infrastructure for applications
(as opposed to simpler Perl use by the system-OS or Admins).

For further reading along these lines there's some great information that
Schwern put together here:
http://www.perlfoundation.org/perl5/index.cgi?perl_best_admin_practices


Hope that helps,
m


On Fri, Apr 9, 2010 at 1:11 PM, Tim McDaniel <tmcd at panix.com> wrote:

> On Fri, 9 Apr 2010, Jonathan Scott Duff <duff at pobox.com> wrote:
>
>> $ PERL_MM_USE_DEFAULT=1 cpan Bundle::CPAN
>>
> ...
>
>> That's meant to be run from the command line using the "cpan"
>>
>> command which doesn't take subcommands.  So cpan Bundle::CPAN from
>> the command line will install Bundle::CPAN.
>>
>
> Thank you for the explanation.
>
>
> --
> Tim McDaniel, tmcd at panix.com
> _______________________________________________
> Austin mailing list
> Austin at pm.org
> http://mail.pm.org/mailman/listinfo/austin
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.pm.org/pipermail/austin/attachments/20100409/dca4b181/attachment.html>