[Nagiosplug-devel] Access to CVS as a developer
Voon, Ton
Ton.Voon at egg.com
Fri Mar 19 03:33:02 CET 2004
To be fair to Howard, he has raised 7 patches in SF. Subhendu has picked up
5 of these, of which he is waiting for a response for one of them. I've just
picked up the other 2, but need info on the check_ldap one.
As a team, we probably just need to be a bit more responsive to patches in
general - I'm sure this is making Howard v frustrated!
-----Original Message-----
From: Karl DeBisschop [mailto:karl at debisschop.net]
Sent: Friday, March 19, 2004 3:24 AM
To: Howard Wilkinson
Cc: nagiosplug-devel at lists.sourceforge.net
Subject: Re: [Nagiosplug-devel] Access to CVS as a developer
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
-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
_______________________________________________
Nagiosplug-devel mailing list
Nagiosplug-devel at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nagiosplug-devel
::: Please include plugins version (-v) and OS when reporting any issue.
::: Messages without supporting info will risk being sent to /dev/null
This private and confidential e-mail has been sent to you by Egg.
The Egg group of companies includes Egg Banking plc
(registered no. 2999842), Egg Financial Products Ltd (registered
no. 3319027) and Egg Investments Ltd (registered no. 3403963) which
is authorised and regulated by the Financial Services Authority. Egg
Investments Ltd. is entered in the FSA register under number 190518.
Registered in England and Wales. Registered offices: 1 Waterhouse
Square, 138-142 Holborn, London EC1N 2NA.
If you are not the intended recipient of this e-mail and have received
it in error, please notify the sender by replying with 'received in
error' as the subject and then delete it from your mailbox.
More information about the Devel
mailing list