[Pkg-nagios-devel] nagios2 packaging progress
mh+pkg-nagios-devel at zugschlus.de
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 :)
> > 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
> > > 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
> 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
> - 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
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
> > 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.
>  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.
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
More information about the Pkg-nagios-devel