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

[Marc Haber]

On Tue, Dec 20, 2005 at 11:40:38AM -0500, sean finney wrote:
> sorry for the delay in response, been travelling several timezones
> westward in the past couple days...

No problem.

> On Mon, Dec 19, 2005 at 03:16:46PM +0100, Marc Haber wrote:
> > I therefore suggest the attached patch to debian/control. With this
> > patch, nagios2 does install and cleanly replaces nagios and
> > nagios-common.
> 
> nagios2-common shouldn't depend on on nagios2, but instead nagios2
> should depend on nagios2-common.  i think there was a rationale
> for that, but now i'm having a hard time remembering.

I think you're right, to have aptitude install nagios2 succeed.

> > I have also re-worked the package descriptions a bit, putting the
> > information important for the local admin first.
> 
> thanks for that :)

It would make sense to make these changes for the other packages as
well.

> > - Why does nagios-common depend on fileutils? fileutils currently is
> >   only an empty transition package. I'd vouch for removing the
> >   fileutils dependency in favor of the already present coreutils
> >   dependency.
> 
> i believe it was for backwards compatability / backporting.

I understand. Do you still care about woody?

> however,
> i don't have a problem removing it... if someone complains we can
> always put it back.

Right. I'll remove it.

> > - nagios-text has much stricter depends on nagios-plugins, and
> >   installing nagios-text pulls nagios-plugins, nagios-plugins-basic and
> >   nagios-plugins-standard. What's the reason for nagios2 only
> >   depending on nagios-plugins and not on -basic and -standard?
> 
> i'm not sure i follow here.  they should both be the same, depending
> on nagios-plugins (>= $vers) | nagios-plugins-basic, where $vers
> is the version where the packages were first split.

Ok, I'll streamline nagios2's dependencies to nagios'.

> > - nagios2 doesn't do debconf at all. Is this only "still missing", or
> >   did you decide to remove the debconfization?
> 
> just an omission... however i'll be somewhat picky about how we
> do webserver configuration, so let's talk about it before we
> build-in support for that.  if you have other ideas about how
> debconf could augment the install/configuration process, feel free
> to bring them up.

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.

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.

> > - Since nagios2 re-uses /etc/nagios and probably /var/foo/nagios
> >   (didn't look), we might get in trouble if the local admin decides to
> >   purge nagios after installing nagios2. I'd like to propose going for
> >   /etc/nagios2 and /var/foo/nagios2, avoiding conflicts with nagios.
> 
> 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.

> my initial feeling is that all packages should use /etc/nagios, unless
> there is a compelling reason why they shouldn't.  otherwise, we risk
> scuttling any attempt at a reasonably painless upgrade path.  i don't
> feel as strongly about other directories.

nagios2 could have its configuration in /etc/nagios2, copying over
/etc/nagios on first installation. This is allowed by policy.

> >  Package: nagios2
> >  Architecture: any
> > @@ -41,9 +45,6 @@
> >  Replaces: nagios, nagios-text, nagios-pgsql, nagios-mysql
> >  Provides: nagios, nagios-text
> 
> now that i think about it, shouldn't we have a Conflicts in there too?

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

> On Tue, Dec 20, 2005 at 12:19:02PM +0100, Marc Haber wrote:
> > I have created a wiki page, http://wiki.debian.org/PkgNagios2, for
> > tracking of development issues. This can later also serve as the
> > Nagios2 packages home page (see http://pkg-exim4.alioth.debian.org/).
> 
> very nice.  i was wanting to have some kind of web-presence for the
> project (pkg-nagios.alioth.debian.org points somewhere currently), but
> was not looking forward to having to maintain that.  i think a wiki
> is a better option so thanks for that.

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.

> On Tue, Dec 20, 2005 at 04:26:35PM +0100, Marc Haber wrote:
> > I have written my first lsb'ized init script.
> > 
> > Would it be ok to branch Nagios2 to commit my changes to svn, or is it
> > ok to commit directly to trunk?
> 
> as long as you're not going to do any surprise uploads, go ahead and
> commit to trunk.  i'll try and keep tabs on the commit messages and
> throw any feedback your way in the meantime.

Great, thanks.

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