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

[sean finney]

hey marc,

On Tue, Dec 20, 2005 at 06:47:39PM +0100, Marc Haber wrote:
[discussing package descriptions]
> It would make sense to make these changes for the other packages as
> well.

the next time i have the internet handy i'll see about committing
your suggestions, thanks.

> I understand. Do you still care about woody?

not really. if someone wants to do the footwork it would
of course be welcome, but it's not something we are required
to be (nor something i have a personal interest in) concerned
with.

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

> > i've never been in this situation, and have to admit that i don't know
> > what would happen if a 1.x package was purged after a 2.x package was
> > installed.
> 
> The 1.x package's postrm script would run, which would in turn zap
> /etc/nagios, /var/lib/nagios and /var/log/nagios => *boom*.
> 
> You don't want this.
> 
> 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.  according to policy 6.5.9:

     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.  For each such package

          1.   `dpkg' calls:
                    <disappearer's-postrm> disappear \
                      <overwriter> <overwriter-version>

          2.   The package's maintainer scripts are removed.

          3.   It is noted in the status database as being in a sane state,
               namely not installed (any conffiles it may have are ignored,
               rather than being removed by `dpkg').  Note that
               disappearing packages do not have their prerm called,
               because `dpkg' doesn't know in advance that the package is
               going to vanish.


so thus they would be marked as being no-longer present, and thus
could never be purged in the first place.  also see 7.5.1.

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

> Only if we want to seamlessly replace nagios on nagios2 installation,
> IIRC. What will happen if we omit the Conflitcs?

hmm... 7.5.1 seems to imply that for what i mention above, we
do *not* want Conflicts.  i'd appreciate a second opinion on that.

> > On Tue, Dec 20, 2005 at 12:19:02PM +0100, Marc Haber wrote:
> This approach has proven quite handy for exim4, dpatch, and adduser.
> Actually, the wiki page I created was morphed from
> http://wiki.debian.org/PkgAdduser, so don't be surprised if there is
> still "adduser" mentioned in it. I might have been working sloppily.

i'll give it a once over the next time i get some internet.

On Thu, Dec 22, 2005 at 02:02:29AM +0100, Marc Haber wrote:
> On Tue, Dec 20, 2005 at 06:47:39PM +0100, Marc Haber wrote:
> > Currently, I don't see any use for debconf other than webserver
> > configuration.
> 
> We probably should ask for the nagiosadmin password via debconf, as
> the nagios 1 packages do. If somebody wants to implement this, please
> feel free.

yes, and i should add that i'm not very fond of how we've been doing
it (and the other web-configuration stuff for that matter) in nagios-foo.
i haven't put a lot of thought into how it could be done better, but
will do so.

> > 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.  when i get back i
can take a stab at copying in the code from the webapps project (which
includes debconf templates/logic), or perhaps this is the extra
incentive i need to finish touching that package up (and i do have
quite a bit of travel time to mess around with it...) let's talk about
this when i get back online, which should be the 29th.

> 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, or at the least manage said file via ucf, so that
the admin is bothered less at upgrade times.  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).

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

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

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.

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

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?


okay, phew that's it.  i'm sorry that (a) this seems mostly a critique
and (b) i haven't had the time in the past couple weeks to give
any assistance.  the two paired together might make it seem like
i'm taking your work for granted and that i'm not thankful for
what you're doing... so i just want to reiterate that your work
is very much appreciated!

so yes, i'll be reliably online the 29th at the latest, though i may
surface from time to time between now and then when the internet
makes itself available :)


	sean

-- 
-------------- 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/20051223/4c245d45/attachment.pgp