<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1"> <title></title> </head> <body text="#000000" bgcolor="#ffffff"> 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: <blockquote type="cite" cite="midEE5168F102C06048B1130A070E6B89303C8F5E@PNNEMP02.pp.egg.com"> <pre wrap="">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 [<a class="moz-txt-link-freetext" href="mailto:karl@debisschop.net">mailto:karl@debisschop.net</a>] Sent: Friday, March 19, 2004 3:24 AM To: Howard Wilkinson Cc: <a class="moz-txt-link-abbreviated" href="mailto:nagiosplug-devel@lists.sourceforge.net">nagiosplug-devel@lists.sourceforge.net</a> Subject: Re: [Nagiosplug-devel] Access to CVS as a developer On Thu, 18 Mar 2004 11:52:56 +0000 Howard Wilkinson <a class="moz-txt-link-rfc2396E" href="mailto:howard@cohtech.com"><howard@cohtech.com></a> wrote: </pre> <blockquote type="cite"> <pre wrap="">I would like to get access to the CVS store as a developer. </pre> </blockquote> <pre wrap=""> 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. </pre> <blockquote type="cite"> <pre wrap="">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. </pre> </blockquote> <pre wrap=""> I made a few changes to support a limited dialog recently. I'm interested to see where you're headed. </pre> <blockquote type="cite"> <pre wrap=""> * 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. </pre> </blockquote> <pre wrap=""> 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. </pre> <blockquote type="cite"> <pre wrap=""> * 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. </pre> </blockquote> <pre wrap=""> 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. </pre> <blockquote type="cite"> <pre wrap=""> * 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. </pre> </blockquote> <pre wrap=""> Also of interest. </pre> <blockquote type="cite"> <pre wrap="">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. </pre> </blockquote> <pre wrap=""> 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. </pre> <blockquote type="cite"> <pre wrap="">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. </pre> </blockquote> <pre wrap=""> 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. </pre> <blockquote type="cite"> <pre wrap="">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. </pre> </blockquote> <pre wrap=""> 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 <a class="moz-txt-link-abbreviated" href="mailto:Nagiosplug-devel@lists.sourceforge.net">Nagiosplug-devel@lists.sourceforge.net</a> <a class="moz-txt-link-freetext" href="https://lists.sourceforge.net/lists/listinfo/nagiosplug-devel">https://lists.sourceforge.net/lists/listinfo/nagiosplug-devel</a> ::: 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. </pre> </blockquote> <div class="moz-signature">-- <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1"> <title>Signature</title> <table cellpadding="2" cellspacing="2" border="0" style="text-align: left; width: 100%;"> <tbody> <tr> <td style="vertical-align: top;">Howard Wilkinson </td> <td style="vertical-align: top;">Phone: </td> <td style="vertical-align: top;">+44(20)7690 7075 </td> </tr> <tr> <td style="vertical-align: top;">Coherent Technology Limited </td> <td style="vertical-align: top;">Fax: </td> <td style="vertical-align: top;">+44(20)79230110 </td> </tr> <tr> <td style="vertical-align: top;">33 Belgrade Road, Stoke Newington, </td> <td style="vertical-align: top;">Mobile: </td> <td style="vertical-align: top;">+44(7980)639379 </td> </tr> <tr> <td style="vertical-align: top;">London, United Kingdom, N16 8DH </td> <td style="vertical-align: top;">Email: </td> <td style="vertical-align: top;"><a name="howardcohtech.com" target="mailto:howard@cohtech.com" href="mailto:howard@cohtech.com"></a><a class="moz-txt-link-abbreviated" href="mailto:howard@cohtech.com">howard@cohtech.com</a> </td> </tr> </tbody> </table> </div> <DIV><HR> 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. </DIV> </body> </html>