[Pkg-nagios-devel] nagios2 packaging progress

Sat Jan 14 22:06:06 UTC 2006

On Sat, Jan 14, 2006 at 04:36:25PM -0500, sean finney wrote:
> On Sat, Jan 14, 2006 at 05:17:22PM +0100, Marc Haber wrote:
> > > That is good news for the new year. Want me to work on the transition,
> > > will you do it yourself, or is it already done?
> > 
> > It has been already done. I have committed a trivial fix, removing the
> > empty /usr/lib/cgi-bin/nagios. Or did I miss the trick from taking
> > over the nagios 1 URLs?
> 
> no, you were correct in removing it :)

Good ;)

> > Anyway, the only thing that might still be problematic are the two
> > binaries /usr/sbin/nagios and /usr/sbin/nagiostats which currently
> > force us to conflict with nagios 1. otoh, the conffile and run-time
> 
> yes, this is a problem.   i have an uncommitted (written during an
> internetless plane flight sometime in the past 48 hours) which fixes
> this, as well as modifies the init script respectively.

Ok. I'll then refrain from rolling out the version I have built from
svn before dinner to my test hosts and will wait for your commit.

> On Sat, Jan 14, 2006 at 05:55:37PM +0100, Marc Haber wrote:
> > I have committed a few paragraphs of docs, hoping that this is what
> > you expected.
> 
> thanks, but i think we've changed tack since then, that is we should
> be able to have both installed simultaneously (and thus no replaces
> or even conflicts are necessary).

Yes, you're right. Want me to remove the new docs, or adapt them?

> > > however, there are still some refinements/fixes that can be made 
> > > with the nagios2-only stuff.  most specifically, i think we can
> > > do more for the design and implementation of a default
> > > hosts/services/checks.
> > 
> > While I agree, do you think that should be finished and in place for
> > the first experimental upload?
> 
> no, not at all... in fact i think what we have now is already a prime
> candidate for unstable (after i get the /usr/sbin/nagios ->
> /usr/sbin/nagios2 etc fixes committed, which i'll do after dinner).

I'd go for experimental first - let's get the package past ftpmaster,
and have them autobuilt for the other archs before inflicting them on
the unstable users. And I'd like to have some actual hands-on
experience [which I _still_ don't have :-(] before the bug reports
start coming in.

What do you think about the remaining issues listed in the TODO-List
on http://wiki.debian.org/PkgNagios2?

> > > specifically, some of the default checks (ping/procs) are not
> > > working out of the box, and i'm thinking there may be more we
> > > can monitor as well.
> > 
> > We probably can only do checks on localhost for starters, which I do
> > not consider a prime target for a nagios installation. Which ideas do
> > you have?
> 
> having looked more into things, the check that wasn't working was
> check_ping, because check_ping is part of the nagios-plugins-standard
> and not -basic package.  i'm thinking about moving it over... it means
> another dependency but i also think that it's one of the plugins that
> ought to be in a default install... thoughts?

ping is so basic, and needed for most host checks to properly work,
I strongly feel that this belongs into -basic. Most systems already
have a ping package installed, so the additional dependency doesn't
hurt. I think, however, that the ping dependencies should be relaxed
some, to allow the local admin to choose which of the three
ping-containing packages in Debian (netkit-ping, iputils-ping,
inetutils-pin) is desired. This of course only works if the actual
Nagios plugin can work with other ping flavours as well.

> anyway, you're right that the local checks are probably the checks of
> least interest to the admin installing the package.  my thought
> was to have things set up such that with little effort the configuration
> could be used to extrapolate to the other hosts/services (or conversely
> removed if the admin wanted to use their own system).

Agreed. I plan to work on this once I have accumulated some basic
experience with the template-based config which I still do not fully
grasp.

> also part of this
> idea is to keep autogenerated stuff seperate from the bulk of the
> configuration, which would keep config file management cleaner
> in addition to what was mentioned above.  here are some ideas
> from a quick brain-dump:
> 
> - make a directory /etc/nagios2/debian, included from nagios.cfg
>   via a 'cfg_dir' directive
> - in this directory, have files that provide any autogenerated
>   configuration stuff.  some ideas:
>   - a host declaration for the local host (using some default
>     host template which doesn't have to be autogenerated)
>   - a host declaration for the default route
>   - a host declaration for the dns servers in resolv.conf
>   - check_ping for the default route
>   - check_ping/check_dns for the hosts in resolve.conf
>   - check_disk for the local host

Agreed. There should be user-calleable tools to re-generate these
files, since default route, dns servers etc might change any time.

>   - default service declarations for the other plugins[1]

Agreed.

> - files in this directory could by managed via ucf, which would
>   give us the ability to muck with them while retaining the
>   conffile-like characteristics

Good idea. I need to learn ucf's bells and whistles and quirks anyway.
I am a big friend of a "many small files" approach because that
handles easier with conffile handling.

> - also in this directory, other packages could drop configuration
>   files (similar to an apache conf.d thing)... though i can't
>   think of any cases where someone might want to do that[2]

Yes, this might be a exotic use case since most changes Nagios will do
are remote. It would be possible to package more exotic and
complicated plugins (with probably complex dependencies) independently
though.

> > then pulled in just as the other files are. Again, I am not sure
> > whether this mechanism should be in the first upload.
> 
> i don't think it's at all necessary for the first upload, especially
> if our first upload is going to be to experimental.  

Good. I like consensus that is reached this quickly.

> [1] or perhaps these default services could/should be provided by
>     the plugins package that provides the plugins in question.

Yes, that would be needed anyway unless we'd want to have a hard
dependency on the plugins package which kind of defeats the purpose of
factoring out the plugins.

Greetings
Marc

-- 
-----------------------------------------------------------------------------
Marc Haber         | "I don't trust Computers. They | Mailadresse im Header
Mannheim, Germany  |  lose things."    Winona Ryder | Fon: *49 621 72739834
Nordisch by Nature |  How to make an American Quilt | Fax: *49 621 72739835