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

[sean finney]

hey marc,

On Fri, Dec 23, 2005 at 08:43:39AM +0100, Marc Haber wrote:
> *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.

for the time being i see no harm in simply shipping an apache conf
file (outside of the servers' conf.d directory), so then one could
configure apache manually as easy as possible just by creating
a symlink and reloading apache.

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

you have some really good points.  it would be really nice if someone
else could chime in on this (as well as other matters).  

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

the default local checks.  i think some history is in order here.  the
nagios 1.x packages have historically created a default check involving
parsing the output of route at installation time.  i've never been
fond of how this was done, as it involvs modifying a conffile
automagically in such a way that the user will be prompted every
time in the future that we make a change in the default conffile.
what would have been better would be to have had such stuff split
out in a seperate file, which was then included by the main 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

ucf is really handy for dealing with configuration files that are either
created from debconf responses or ones that could use a little "touching
up" from maintainer scripts.  but it's not the most critical thing in
the world to do.  the point of what i'm getting at is that if we're
going to create anything "on the fly", we should shy away from the
monolithic conffiles.  if you're simply talking about some default
"out of the box" checks (like check_load, check_disk, etc), then
this was all moot and you can ignore my ramblings.

> installable and runnable package fast, which I succeeded in. Too bad
> that you didn't like most of my work.

i don't think that's a fair assumption to make.  i am 100% elated that
someone is willing to pick up the ball and go with this a bit.  at the
same time, however, you have to understand my various trepidations.
in the past year or so, i've devoted a very large portion of my free
time to nursing a bug-ridden, virtually unmaintained package into a
stable and reliable piece of work.  while initially, this was a "team
effort", i don't think anyone besides myself has done any real work on
the packages since november 2004 (see the changelogs to get an idea
of what i'm talking about).  

so when someone new rides into town and offers to help create the
next-generation successor to this package, as my default setting i'm
going to be very weary of each and every change until i'm absolutely
convinced that it is for the best.  i mean no offense in any way, and
i hope you can look past my nitpicking.

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

at this point, i have no real rush on releasing it.  however, when
mr. galstad decides to make the "official" release of v2, the
priorities will change accordingly.  and no, as a general rule i'm not
a subscriber to the release early, release often method (at least when
it comes to package maintainance).  

on the nagios web page the release is slated for before new
years'... whether this happens is up in the air, but even if it's a month
or two delayed i think there would be ample time to get this in for etch.

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

i see.  btw that wasn't a passive attack on how you were doing it, i
was genuinely curious because i didn't know.  anyway it works for me.

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

the fact that you haven't already noticed a problem (assuming you've
been able to check the web interface) makes me think that it will
work okay.  if not, i think the latest version in np upstream supports
both versions automatically.  in any case i can look into that.

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

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

oh, whoops, it looks like i removed the attributions from the nagios1
init script at some point too.  i was referring to Joerg Jaspert, who
is the only other person to have done a large chunk of work with the
nagios 1.x packages since the "team maintenance".
 
> 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.

okay.  as i've stated a couple times, i don't plan on getting any serious
work done between now and the 29th (assuming there's no internet up in the
mountains), but let's see what i can get done between then and new year's.


	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/e4994a33/attachment.pgp