[Nagiosplug-devel] Access to CVS as a developer

[Howard Wilkinson]

Ton,

I am not frustrated at the delay but worried that I may move off in a 
direction that does not get integrated easily. I have this morning 
picked up the CVS head and now working on integrating my patches into this.

A piece of advice would be useful however,

I am looking to automate an interface to NagMin to allow intelligent 
access to plugins and commands. So that help and defaults can be 
automatically generated. I have made a start with this and have an 
interface that allows the registration of a plugins with the NagMin 
database. I now want to add a learning facility to this interface and 
have started to patch ALL of the plugins to support this. My first pass 
is to remove the line feeds and extraneous spaces from the print_usage 
output. I am now reconsidering this - although it probably is the 
easiest first step it does mean the human interface is not as good as is 
was.

So I am moving to provide an XML output probably tied to a --usage flag 
(-U for short?) and leaving the print_usage alone. So advice - is this 
more palatable! What flag(s) would you suggest I use, can I add an XML 
library requirement to the plugins - if so what base libraries would 
people like to see me use, this needs to work for `C', Perl, Python, PHP 
and SHell which is a tall order but I will try to make it happen.

My inclination was to expand the interface to print_usage to allow a 
specification of what type of output to product, then encode the output 
in structures which are walked to produce the usage in whatever form is 
needed. Advantage only one definition of the data. Disadvantage plugin 
writers will need to cope with providing structural data rather than 
simple string output. I will write the structure walking code and put it 
in the utils packages and change all of the existing plugins (including 
the contrib ones) to use this if it is acceptable. The alternative is to 
provide a parallel system with these attributes and allow the current 
interface to remain. Big disadvantage is that this will mean supporting 
multiple copies of the information about the plugin help data.

On the subject of the check_ldap plugins, I take your comments and will 
relook at my approach. However, I think (dim memories here) that the 
open interface is deprecated in the LDAP access path - will check.

I missed the request for more information from Subhendu and have just 
recovered it from my Email. Assuming I have the correct one about 
check_ntp, will respond now.

Regards, Howard.

Voon, Ton wrote:

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

-- 
Howard Wilkinson
	Phone:
	+44(20)7690 7075
Coherent Technology Limited
	Fax:
	+44(20)79230110
33 Belgrade Road, Stoke Newington,
	Mobile:
	+44(7980)639379
London, United Kingdom, N16 8DH
	Email:
	<mailto:howard at cohtech.com>howard at cohtech.com




This message contains confidential information and is intended only
for the individual named. If you are not the named addressee you
should not disseminate, distribute or copy this e-mail. Please
notify the sender immediately by e-mail if you have received this
e-mail by mistake and delete this e-mail from you system.

E-mail transmission cannot be guarenteed to be secure or error-free
as information could be intercepted, corrupted, lost, destroyed,
arrive late or incomplete, or contain viruses. The sender therefore
does not accept liability for any errors or omissions in the contents
of this message which arise as a result of e-mail transmission. If
verification is required please request a hard-copy version.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://nagios-plugins.org/archive/devel/attachments/20040319/5a40b7aa/attachment.html>