[Pkg-nagios-devel] nagios2 packaging progress

[Marc Haber]

On Sat, Jan 14, 2006 at 08:32:32PM -0500, sean finney wrote:
> On Sat, Jan 14, 2006 at 11:06:06PM +0100, Marc Haber wrote:
> > > 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.
> 
> done.  nothing big, just a couple s/nagios/nagios2/ in the init script
> and a couple modifications to debian/control and debian/rules.  i also
> updated the changelog to signify/use rc2, which came out a few days ago.

Ok, thanks.

> > > On Sat, Jan 14, 2006 at 05:55:37PM +0100, Marc Haber wrote:
> > Yes, you're right. Want me to remove the new docs, or adapt them?
> 
> i'd say adapt.  at this point i think we just need to mention that they
> need to migrate their configuration over manually, but that they
> can run both services at the same time

Done.

> and also how to enable the
> 1.x urls.

This needs to be written. How to enable the 1.x urls? Is there more to
do than answer "yes" to the debconf question? What happens when I say
"yes" with nagios 1.x still installed?

> > What do you think about the remaining issues listed in the TODO-List
> > on http://wiki.debian.org/PkgNagios2?
> 
> i'll comment on them inline here:

Fine.

>     * deliver apache/apache2 configuration snippets. torrus does a quite
>     good job about that (torrus-apache, torrus-apache2)
> 
> done (though w/out the additional packages).

How are the configuration snippets activated? Do they need to be
linked manually from /etc/nagsos to /etc/apache[2]?

>     * ship html docs in a dedicated package
> 
> apart from nagios2-common?

The HTML docs form a significant part of nagios2-common's size They
don't need to be present on every system running nagios2, but they
might be wanted on a personal workstation for reference without having
Nagios2 actually installed. I'd like to see them separated, but I
don't feel strongly about that.

>     * debconf
>           o ask for nagiosadmin password, create /etc/nagios/htpasswd.users
> 
> done

... did a minor fix

>     * Make sure that cfg-patch breaks package build if patch doesn't apply
> 
> the patch process definitely breaks, but i haven't verified the unpatch
> process does.

Need to still verify that.

>     * Make package lintian-clean
>           o update config.guess, config.sub (convince upstream to update!)
> 
> definitely.

What is upstream's opinion about using later config.guess, config.sub
before nagios2 release?

>another option which we may wish to pursue (additionally,
> and warranting further discussion of course) is to bring in autofoo
> dependencies and work with the configure.in provided by upstream instead.

Would be a possibility, but generally Debian discourages autoreconf at
package build time. I am also not an expert in autofoo, so I'd prefer
to convince upstream to use current versions of the tools.

Do you want me to get in touch with upstream?

>           o man pages for nagios, nagiosstats
> 
> yeah.  there's one for nagios in 1.x that could be easily adapted, not
> sure about nagiostats

We'd need to do that for the unstable upload.

>           o move nagios.log back to /var/log
> 
> i don't think this has been done.

I didn't do it. Another thing to be done before the unstable upload.

>           o find out whether p1.pl is a program or a library. if program,
>           add #!/usr/bin/perl, generate and install man page from pod
>           included in file, if library, move to /usr/share/perl5.
> 
> i'm fairly certain this is the embedded perl interpreter, with which i
> have no experience.  my thought is that it should be somewhere under
> /usr/share but i'd have to read up on what perl policy recommends
> for perl libs that aren't useful outside of a package.  also, i see
> that the lib also defines a package main, which may muddy the waters
> a bit about whether it is a script or library.  in such a case, we
> might want to go outside the perl-policy dirs and just put it somewhere
> under /usr/share/nagios2...

I think that /usr/share/nagios2 would be appropriate. We can always
move it back to /usr/bin should it show necessary to invoke that file
on a command line.

>     * allow www-data to read /var/lib/nagios, /var/cache/nagios,
>     /var/log/nagios
> 
> this is already the case with /var/cache/nagios from a previous commit
> i did (group www-data and setgid bit on dir, instead of the 1.x way of
> making the cgi-bin setuid nagios).  as for /var/lib/nagios, i think
> that after nagios.log is moved to /var/log/nagios, it won't be needed,
> but /var/log/nagios will need to be made like /var/cache/nagios.

I'll investigate.

>     * remove -s parameter from check_local_procs in checkcommands.cfg
>     since it doesn't behave as advertised anyway
> 
> i'll have to look more into that before commenting.

I should have documented my findings further.

>           o /usr/sbin/nagios2stats
> 
> done, with the caveat that it's nagios2tats.

I'd go for nagios2stats since the word play doesn't work with the 2
thrown in. I don't feel strongly about that, your decision.
> > 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.
> 
> istr there being a problem with check_ping using certain parameters
> that were not cross-ping compatible (the ping syntax is compiled in
> at build time... i know, i know...).

I see. So we'll have to stay with the hard dependency :-(

> however, since then i've made some changes to both upstream plugins
> and the build process, so i suspect that this may no longer be the
> case, assuming we can concoct a ping cmdline that works on all three.

So we'll need to investigate which ping command line the ping plugin
uses these days.

> okay, cool.  i think as long as we have the /etc/nagios2/debian dir
> as a cfg_dir before we hit unstable (and not autogenerating any of the
> main config files), there's no rush on actually implementing this.

Added to TODO.

> > Agreed. There should be user-calleable tools to re-generate these
> > files, since default route, dns servers etc might change any time.
> 
> okay, that shouldn't be too hard to do.  basically we'll just put the
> code into a script instead of the postinst, and then call the
> script from the postinst, and mention as such in README.Debian.

Yes, right. But that's stuff for unstable.

> > > - 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.
> 
> ucf is incredibly easy.  the hard part is parsing and generating the
> files.  basically, you do something like
> 
> newconf=`mktemp`
> $configmakingscript < $oldconf > $newconf
> ucf $newconf $oldconf
> rm $newconf
> 
> and then a little something in the prerm/postrm to get rid of
> the file as well.

I know it in theory, but do not have any practice and am not familiar
with the caveats that do surely exist.

> > > [1] 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.
> 
> agreed then.

This, however, introduces an upload dependency between nagios2 and the
plugins packages. I'll need to think about that before uploading the
first nagios2 package.

Maybe it is time to migrate the plugins packages to svn then. Who else
is working on the plugins packages?

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