> The dependencies, hand-config user-creation, and the creation of the ghost files, > can be done with a proper RPM -- which then means that two installations (by > different people) are able to help each other a bit easier. It may also help > the original OT poster get a canned install with little hand-monkeying, so easier > to approach a canned ISO or a VM disk image.
Whether it's worth it depends on how much you'll use it. The config should always be seperate, and I'd suggest libexec too (We're always adding custom plugins). If you run in a mixed mode environment (some 32 bit, some 64), separate your architecture-independent perl scripts from your binaries by using two libexec directories. > Paul, did you think of using the RPM, and indicating the shortfalls (such as the > perl dependencies that aren't portable to the host's RPM dependencies -- those > always pop up) or other issues with the RPM? We have 35 custom .debs in a local repository. One of our nagios checks runs apt-get update every night for security checking, so we see which machines need upgrades. We haven't written a plugin that needs a perl module which isn't in the OS repository. It's easier to keep uptodate that way, and there's arround 1400 perl modules in the apt Repositories. The testing that needs to go into the installation scripts (to do it right) for something like a nagios install is much more intensive than most, which files to remove in preperation for upgrade, which to purge, which not to purge, what to do on failed upgrades, etc. Much easier to run one command after another and check for errors yourself. ------------------------------------------------------------------------------ Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H _______________________________________________ Nagios-users mailing list Nagios-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nagios-users ::: Please include Nagios version, plugin version (-v) and OS when reporting any issue. ::: Messages without supporting info will risk being sent to /dev/null