[Nagiosplug-devel] Access to CVS as a developer

[Karl DeBisschop]

On Thu, 18 Mar 2004 11:52:56 +0000
Howard Wilkinson <howard at cohtech.com> wrote:

> I would like to get access to the CVS store as a developer. 

To get access, you submit patches one-by-one and develop neme
recognition and trust from the devlopers (It's not that hard, we're
not all that critical, but there has to some process, right). Declaring
your intent as you have done is a good start.

> I have a 
> large number of patches to the currently existing plugins and some 
> additional plugins that I would like to see included in future 
> distributions. These include:
> 
>     * A largely rewritten check_tcp.c that allows send expect
>     dialogues
>       to be added to the existing facilities. This now uses a data
>       driven structure for the send-expect-quit sequence and allows
>       multiple handshake conservations with services, giving the
>       ability to check a complete dialogue as valid where required.

I made a few changes to support a limited dialog recently. I'm
interested to see where you're headed.

>     * A perl version of check_dns, which uses the Net::DNS library and
>       supports retrieving records of all mainstream DNS types. It also
>       supports the ability to compare the returned result with an
>       expected result and report a critical failure if they do not
>       match. The matching rules are generous and allow matching on
>       exact strings, prefixes, suffixes, substrings, as well as oneof 
>       selection where multiple results are returned. I am working no a
>       structured checking facility that will allow checking of the dns
>       records in much more detail and will try to add any missing
>       record types in the near future - this requires extension to the
>       Net::DNS library as well as some more extensive checking code.
>     * A modified check_apc_ups, that has been tidied up at the Perl
>       level and had the SNMP probes converted to the bulkget using the
>       Net::SNMP library within Perl.
>     * Minor spelling and functional fixes to (in no particular order)
>       check_ldap.c, check_snmp.c, negate.c, netutils.c, urlize.c,
>       check_breeze.pl, check_ntp.pl, check_wave.pl, check_disk.c,
>       check_http.c, check_linux_raid.pl, check_ups.c,
>       check_nagios_db.pl, check_by_ssh.c, check_dig.c,
>       check_disk_smb.pl, check_flexlm.pl, check_file_age.pl,
>       check_ifoperstatus.pl, check_ifstatus.pl, check_log.sh,
>       check_mrtg.c, check_mrtgtraf.c, check_nt.c, check_nwstat.c,
>       check_oracle_instance.pl, check_overcr.c, check_pgsql.c,
>       check_ping.c, check_procs.c, check_real.c, check_rpc.pl,
>       check_smtp.c, check_swap.c, check_time.c, check_udp.c,
>       check_game.c, check_radius.c.

All the above bullets are of interest. Best to submit one patch per
plugin, however. We have to review them, and we're pretty limited on
time. Small bits are easier to digest.

>     * Changes to the configure script to include the contrib directory
>       in the make tree, with Makefiles for the contrib directory to
>       include settings up the bulk of the contrib plugins.

I doubt this will ever be accepted. Contrib means 'unreviewd' and we
have no intention of changing thta meaning. What we want to do, in fact
the major goal for development after 1.4.0 is released is to move
plugins from conrib to core.

>     * Additional plugin for checking whether a nagios environment is
>       'active', This supports failover/redundancy facilities and has
>       been written to cooperate with extensions being developed for
>       the NagMin environment to support configuration and operation of
>       a distributed redundant monitoring framework.

Also of interest.
 
> I also have further plugins in development using SNMP probes into 
> network devices (routers and switches) and host based environments
> such as Linux SNMP and Windows 200x environments.

Cool - a caution, however. We tend to like mutilpupose plugin more than
single purpose ones. So we have a single check_snmp, rather than
separate check_snmp_disk, check_snmp_memory, check_snmp_cpu, etc. The
finer-grained stuff is best handled as a command defintion using a
generic plugin. We distribute command.cfg to implement those sorts of
detailed checks. Command.cfg could be imporved substantially, but using
it in preference to separate plugins reduces the amount of duplicated
coding. That's just by word of caution, however, as I can't know
exactly what you have implemented from your descriptions.

> As I am making a large number of changes, that I would like to see 
> distributed in the main stream, if only to save me time in integrating
> changes when new releases are made, I think it would make sens to let
> me have access to the CVS tree.

Self-benefit is a good motivator - that's fine. You should also spend
some time watching and contibuting to discussions among the devlopers -
myself, Ton Voon, Subhendu Ghosh, Stanley Hopcraft, Jeremy Bouse, and
Ethan of course. We do almost all of our policy discussions in clear
public view, and that way we can be sure we're all headed in the same
direction should you decide you want to become a developer.

> If not I can submit all of these changes as patches as this is how I 
> currently hold them in the RPM environment - applied to the
> 1.4.0-alpha1 release.

Patches should be against CVS head - as a deleoper, that is what you
work against and patch against. So start now, if that is your goal.

Hope that helps.

--
Karl