On 28 Jun 2010, at 23:06, Matt Rose wrote:
Does anyone have best practice guidelines for installing additional
perl
modules onto an opsview server either via package distribution,
cpan, or
directly insering .pm files into the @INC path? As Opsview is Catalyst
based, which has 100-150 deps last time I checked, there's a large
cross-section of essential modules that are going to be updated in the
system @INC. Is Opsview coded at all levels using its own library so
there's no chance of overriding things?
I'd use local::lib, however with the scripts being installed being
check_whatever nagios scripts, I'd have to define local::lib for the
nagios user which could potentially cause issues for Opsview/nagios as
well.
Or am I overthinking this and it's safe to go hog wild with module
installation?
We install perl modules in there based on what Opsview needs, or if
system supplied ones are downlevel to what we need.
The perl modules that we deliver with Opsview go into /usr/local/
nagios/perl/lib. You can install there if you wish, but be aware that
(1) we test using the specific files in there, so if you have
different versions, then you're on your own!, (2) on an Opsview
upgrade, the perl modules will get overwritten (which maybe downgraded
or upgraded).
You can usually upgrade system level perl modules without issue. There
will probably be an issue if you upgrade perl to a major release
though, as there are some modules which are compiled against a
specific version of perl.
You can install additional perl modules under a different location and
make sure your @INC has your own area before /usr/local/nagios/perl/
lib to guarantee picking up your libraries first.
What do you need the libraries for? You imply you are trying to setup
Catalyst?
Ton
_______________________________________________
Opsview-users mailing list
[email protected]
http://lists.opsview.org/lists/listinfo/opsview-users
