[Pkg-nagios-devel] nagios2 packaging progress

[sean finney]

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.

> > 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 and also how to enable the
1.x urls.

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

    * deliver apache/apache2 configuration snippets. torrus does a quite
    good job about that (torrus-apache, torrus-apache2)

done (though w/out the additional packages).

    * ship html docs in a dedicated package

apart from nagios2-common?

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

done

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

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

definitely.  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.
this was historically a big deal with the plugins package, but i'm
not convinced it's necessary for nagios.

          o man pages for nagios, nagiosstats

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

          o move nagios.log back to /var/log

i don't think this has been done.

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

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

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

    * set up command directory, directions on [WWW]
    http://nagios.sourceforge.net/docs/2_0/commandfile.html

i'll have to look more into that before commenting.

    * probably migrate to use
          o /usr/sbin/nagios2

done

          o /usr/sbin/nagios2stats

done, with the caveat that it's nagios2tats.

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

> > anyway, you're right that the local checks are probably the checks of
> > least interest to the admin installing the package.  my thought
> > was to have things set up such that with little effort the configuration
> > could be used to extrapolate to the other hosts/services (or conversely
> > removed if the admin wanted to use their own system).
> 
> Agreed. I plan to work on this once I have accumulated some basic
> experience with the template-based config which I still do not fully
> grasp.

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.

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

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

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


anyway, i'm done for the evening (er, early morning, damn how'd
that happen).  if you'd like to do the experimental upload, throw yourself
in uploaders and go ahead and do it.


	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/20060114/1f63daf3/attachment.pgp