Nagios - Newbie

Jim Perrin jperrin at gmail.com
Tue Apr 4 14:25:43 CEST 2006


> Thanks, I have received several replies with great information, but this is
> the direction my question was aimed at. Do you have any recommendations as
> to what is needed? I planned to select the "Minimal Install" from the
> installer, and then only install the packages that were needed… One of my
> main questions is "What are the packages that are needed?" (as a base… not
> directly related to the Nagios package or Plugins"..

I'd question the use of FC4 strictly from a lifetime approach. With
FC5 out now, core 4 has about 6 months left. a RHEL 4 rebuild like
centos or scientific linux will last you until 2012.  As to your
question of installs, you can choose the minimum install, and then use
yum to get everything else if you use the Extras package. That's a
fine course of action. Nagios doesn't need much beyond fping, perl,
net-snmp-utils and httpd.

>  I also have seen that many times the version (Apache, and other programs)
> that RedHat or Fedora installs is not necessarily the latest version… I
> would like feedback as to whether it is better to go with the newest
> version, or if it is better to stay with the "Older Versions"

For nagios specifically this doesn't really matter. For server
maintenance standards it depends on your goals. A RHEL rebuild is
designed to be stable and provide several years of enterprise service
where 'new' isn't always what you want. Fedora, gentoo and others move
more rapidly. For me, rapid movement isn't what I want in a machine
for monitoring. I want it to last, and provide a baseline for
everything else.


>  I think it would be cool to have a KickStart file, and Post Installation
> Script to have a machine primed and ready to go for a Nagios install.

Indeed, and such a thing is easy. But kickstarts are generally for
mass repetitive installs, or machines that are rebuilt quickly. In
most environments, this doesn't describe the machine you're using for
monitoring others.

>  I have also received some good feedback about whether to use the
> precompiled RPM's or to compile. The official Doc that I am reading from the
> Nagios site details the "compile it yourself" instructions… but I have
> received a couple of responses recommending to use the precompiled versions.

The nagios documentation is very much generic *nix instruction, and is
quite thorough and very good. It's the generic nature of it though
that leads to the discussion. I recommend that people follow the
packaging method of their distribution of choice as much as possible.
If you use an rpm based system, use or make an rpm of nagios. If
you're a debian fan, make or use a deb of nagios. This simplifies the
overall system maitenance requirements and you can use the same tools
for every package. If you work in an environment like I do that
requires software audits periodically, rpm and other package tools
make it easier than saying "Well some are over here, and there are
some others over in this general area".

>  I also want to thank everyone who has responded, the help is much
> appreciated. Jim Perrin sent me a link to his document and it was very
> helpful. I think that it will generate some questions with me, but I will
> try to save most of them till I have tried a few things… one question though
> about the doc.
>
>
>
>  On Jim's document it lists default install directories as:
>
>
>
> /usr/share/
>
> /usr/lib/nagios/
>
> /etc/
>
> I may have missed some???

Yes, but that's because I didn't document them. My guide was meant to
be taken with the nagios documentation, and I only mentioned what I
felt people needed to know to get nagios off the ground.

The nagios rpm I describe has things in:
/etc/httpd/conf.d/nagios  -> the included apache config for
authentication/access control.
/etc/nagios, /etc/rc.d/init.d/nagios to start and stop the nagios
service,  /usr/bin/ where the nagios and nagiosstats binaries are,
/usr/lib/nagios for plugins and the cgis, /usr/share/doc/nagios and
/usr/share/nagios for the documentation and web interface.


>  I assume that the difference could be attributed to personal preference and
> the compile time options???

And distribution type customizations, similar to how apache is set up
on rhel,fedora etc.

>  Also, in Jim's document it states:
>
>
> >What you'll have at this point is a nagios directory in /usr/share/ which
> contains the html interface for >yum, hosted through apache.
>  Can someone explain the significance of the "html interface for yum" to
> me…. Or is this possibly a typo and should be the "html interface for
> Nagios".

Yeah. I have a typo in there. Thanks for catching it, I'm fixing it now.


>  And I want to say that I am not trying to pick at Jim's Doc… I think it is
> great, it has been really helpful for me to read, and has got me thinking….
> I'm just trying to digest it and learn it right the first time.

My doc was just to cover the rpm based approach, and to work with the
existing documentation. If it got you thinking then that's what
matters. If there are things I need to include or correct, by all
means point them out. There is no single "right" way to do it. Each
way to set nagios up has its own issues. You need to pick the one
that's right for you. I recommend a method in keeping with whichever
distribution you choose.

--
Any sufficiently advanced technology is indistinguishable from magic.
-Arthur C. Clarke


-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid0944&bid$1720&dat1642
_______________________________________________
Nagios-users mailing list
Nagios-users at 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





More information about the Users mailing list