[Pkg-nagios-devel] nagios2 packaging progress

[sean finney]

hey marc,

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 :)

> 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.

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).

> > 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).

> > 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?

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).  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
  - default service declarations for the other plugins[1]
- 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
- 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]

> 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.  



	sean

[1] or perhaps these default services could/should be provided by
    the plugins package that provides the plugins in question.
[2] apart from [1], anyway...


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.alioth.debian.org/pipermail/pkg-nagios-devel/attachments/20060114/926b9e5e/attachment.pgp