[Pkg-nagios-devel] Re: Bug#341748: ITP: nagios2 -- A host/service/network monitoring and management system

[Marc Haber]

Hi,

On Fri, Dec 23, 2005 at 01:32:46AM -0500, sean finney wrote:
> On Tue, Dec 20, 2005 at 06:47:39PM +0100, Marc Haber wrote:
> [discussing package descriptions]
> > I understand. Do you still care about woody?
> 
> not really.

Then the fileutils dependency was right to vanish, sarge has coreutils
already.

> > Currently, I don't see any use for debconf other than webserver
> > configuration. And webserver configuration can be done more elegantly
> > by package selection. For example, torrus has two binary packages
> > torrus-apache and torrus-apache2, which only contain a single file
> > /etc/apache/conf.d/torrus resp. /etc/apache2/sites-available/torrus,
> > and depend on the appropriate web server and on torrus common.
> 
> i'd rather not do this.  one of the side projects i'm working on is
> a web app configuration system.  whlie it's not anywhere near complete,
> there is a rather feature-complete library of shell functions which
> would make "the hard way" not so bad.

*shrug*. Good that I didn't waste any more time in working on the
package. I'm going to solve the apache config issue locally so that my
local work is not stalled while we wait for your wheel invention to
finish.

> > After hosing a few tester's systems with the first exim4 packages, we
> > decided to be completly independent from exim by coming as exim4
> > consequently. I am convinced that this was the right decision.
> 
> if i understand policy correctly, we could work around this by
> conflicts/replaces, and ensuring that nagios2 contains all the files
> listed in the original nagios-foo's file list.

We could. Well, you could. It's a decidedly bad idea. But, of course,
it's your call. Go ahead, and do it.

>      9.   Any packages all of whose files have been overwritten during the
>           installation, and which aren't required for dependencies, are
>           considered to have been removed.

I don't think that this is the right way to go for a transition this
big.

Additionally, dpkg's automatisms of course only hold for files managed
by dpkg, but I'm tired to repeat that the _real_ problem is the files
in /var, which are not managed by dpkg, and you should pay _REAL_
attention in nagios 1's postrm not to mess with them if and only if
nagios2 has been installed. You're going to spend _DAYS_ getting this
right since it means that you'll have to extensively modify nagios 1
as well. I sincerely wish you a lot of fun doing this and I'm going to
watch from a safe distance.

> > nagios2 could have its configuration in /etc/nagios2, copying over
> > /etc/nagios on first installation. This is allowed by policy.
> 
> in the worst case scenario, we could do this, but i would prefer
> to have it as a last resort.  i think it could lead to confusion
> to some admins (it's worth noting /etc/nagios2 will tab-complete
> to /etc/nagios, which will probably still exist).

Ok, so you're going to have to handle the conffiles specially as well.

> > > And webserver configuration can be done more elegantly
> > > by package selection. For example, torrus has two binary packages
> > > torrus-apache and torrus-apache2, which only contain a single file
> > > /etc/apache/conf.d/torrus resp. /etc/apache2/sites-available/torrus,
> > > and depend on the appropriate web server and on torrus common.
> > > Nagios2-apache and nagios2-apache2 would have to depend on nagios2 and
> > > the appropriate web server, and would enable the system to be
> > > operational with a single apt call.
> > 
> > I'd like to have a decision about that rather soon.
> 
> as i said above, i'd really prefer not to do this.

Noted. Local work rearranged.

> > The large commit I did half an hour ago makes the .deb build cleanly,
> > and has the daemon running after installing the packages. At build
> > time, upstream's sample config is patched to reflect Debian changes
> > (in the future, failure in patching will break package build so that
> > we notice changes in upstream's sample config that might affect us),
> > and a minimal config file only checking localhost is installed.
> > Upstream's samples to into /usr/share/doc/nagios2-common/examples.
> 
> cool.  shooting from the hip here, it might be nice to dump this
> in a seperate file,

to dump what in a seperate file?

> or at the least manage said file via ucf, so that
> the admin is bothered less at upgrade times.

I don't have too much experience with ucf. My priority was having an
installable and runnable package fast, which I succeeded in. Too bad
that you didn't like most of my work.

> specifically, if we
> ship a conffile, then modify it with some default checks in postinst,
> then make a change in our conffile, the admin will get prompted, whereas
> with ucf we could avoid this entirely (unless the admin has made other
> changes, in which case ucf will do exactly what it's supposed to).

When exactly do you plan to have nagios2 ready for upload? Before the
etch freeze? Seriously, I appreciate your plans, but that doesn't look
like you're going for a "release early, release often" strategy.

> > debian/rules has two new targets, unpack-configs and pack-configs.
> > unpack-configs will merge our diffs and upstream's samples to
> > debian-configs/ for package build or local changes, and pack-configs
> > will re-generate the debian-diffs for the cfg files after doing local
> > changes. This has been mercilessly ripped from exim4, thanks to
> > Andreas Metzler for working on this.
> 
> that's an interesting approach.  certainly works for me.  for my
> own education, what advantage does this provide over a dpatch diff?

A dpatch diff doesn't leave the original around for inclusion as an
example, dpatch patches too early to make a copy of the original file
at build time, and dpatch doesn't automatically grok changes back to
the diff. The exim 4 packages developed that patch method well before
dpatch was introduced, so it might be possible to coax dpatch into
doing what we want. Feel free to investigate and move the
configuration handling to dpatch.

> > What still needs to be done is listed on the wiki page, and after
> > these things are done (which are still pending your "go ahead", which
> > I hope to receive after working so much on the package in the last few
> > days) the packages are ready to go to experimental.
> 
> okay... i don't have net access right now, but i'll see what i can
> grab from the air the next time we stop for gas :)

Most of the points listed there are moot now as you are going to roll
back the majority of my work anyway.

> On Tue, Dec 20, 2005 at 07:21:43PM +0000, Marc Haber wrote:
> > add postinst script creating system user on install. This needs to be
> > reflected in the default config as well (which is not yet done)
> 
> > +        adduser --system --group --home /var/run/nagios --no-create-home \
> > +                --disabled-login --force-badname Debian-nagios2 > /dev/null
> 
> pretty please, let's keep the same user.  i'm aware of the discussions
> we've previously had about creating/modifying/deleting users, but need
> to be convinced why it's necessary to create a new account given that
> one already exists.

*shrug*

> > ++nagios_check_command=/usr/lib/nagios/plugins/check_nagios /var/lib/nagios/status.dat 5 '/usr/sbin/nagios'
> 
> we may need to verify that the version of check_nagios in n-p is
> fully compatible with nagios2... i'm guessing that it is at least
> somewhat working, but might be a good idea to test some of the
> corner cases.

Not having any experience with nagios1, I am not the one who is
qualified to do this.

> Added: nagios2/trunk/debian/nagios2-common.nagios2.init
> ===================================================================
> --- nagios2/trunk/debian/nagios2-common.nagios2.init    2005-12-20 18:44:08 UTC
> +(rev 15)
> +++ nagios2/trunk/debian/nagios2-common.nagios2.init    2005-12-20 19:08:52 UTC
> +(rev 16)
> @@ -0,0 +1,203 @@
> +#! /bin/sh
> +#              Written by Miquel van Smoorenburg <miquels at cistron.nl>.
> +#              Modified for Debian GNU/Linux
> +#              by Ian Murdock <imurdock at gnu.ai.mit.edu>.
> +#               Clamav version by Magnus Ekdahl <magnus at debian.org>
> +#              nagios2 version by Marc Haber <mh+debian-packages at zugschlus.de>
> 
> it looks like you're using code (i and maybe joerg too have) written
> for nagios, i'd appreciate credit too :)  is the "clamav version"
> attribution relevant?

The init script is more of a direct adaption from the nagios1 init
script than it was originally planned. Clamav is the source of the
lsb-stuff I've been using. Which Jörg are you referring to?

[15/515]mh at scyw00225:~/chroot/sid/home/mh/nagios2/trunk$ grep -ilr joerg debian/*
[16/516]mh at scyw00225:~/chroot/sid/home/mh/nagios2/trunk$ grep -ilr j.rg debian/*
[17/517]mh at scyw00225:~/chroot/sid/home/mh/nagios2/trunk$

I have added you to the credits. Please feel free to add any other
people who deserve credit - they should be listed in nagios1's init
script as well.

> okay, phew that's it.  i'm sorry that (a) this seems mostly a critique

Yes, and rather de-motiviating as well. I'm probably not going to work
on the package any more in the next few days since the ball is now
_CLEARLY_ in your court.

> so i just want to reiterate that your work
> is very much appreciated!

It does, however, not seem to advance the packaging efforts :-(

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