[Nagiosplug-devel] Plugin guideline suggestion

[Voon, Ton]

Jason,

My angle is that "what is installed on a server" is a distribution issue
(internal to your organisation), not a coding issue. The coding
resposibility is at the release level, which we provide through the
--version output.

Comparing against coreutils 5.2.1, all the commands respect --version, but
don't even give individual command versions, only the overall release level
(in fact, their source code doesn't appear to hold $Id$ tags at all - wonder
why? I agree with you that this comment should be in all source). The what
command returns no useful info.

$ ./df --version
df (coreutils) 5.2.1
Written by Torbjorn Granlund, David MacKenzie, and Paul Eggert.

Copyright (C) 2004 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$ what ./df
./df:
        SunOS 5.6 Generic August 1997

In fact, on Solaris 2.6 and Sol 8, "what /usr/bin/df" doesn't give any
version number either, so Sun don't even support what version output for
their own commands.

Given the above, my priority would be for --version to work on all plugins. 

Ton

-----Original Message-----
From: Jason Martin [mailto:jhmartin at toger.us] 
Sent: 19 January 2005 17:19
To: nagiosplug-devel at lists.sourceforge.net
Subject: Re: [Nagiosplug-devel] Plugin guideline suggestion


On Wed, Jan 19, 2005 at 08:28:11AM -0000, Voon, Ton wrote:
> Maybe I haven't asked the right question, so let me try again: what 
> are you trying to solve with these version identifiers?

My particular need is that I have >500 servers with plugins on them and am
looking to design an elegant way of surveying  / tracking their versions. Of
course I'll have to upgrade if this change goes in to use the new
functionality but I can handle that.

Another thought I had about managing this would be to have each plugin
return its version in the performance data, but I realize that doing so is a
much larger change to the standard non-standard and would interfere with
existing perfdata tools. Hence the less impactful store-it-in-the-binary
method.

Additional reasons / benefits:
* CVS files should all (IMHO) already have a $Header$ or $Id$ string in
their text in at least a comment. It can also be used in the --version data.
This mechanism exposes that header in the final product.
* The tools to get this data are standard across platforms
* It is a pretty standard method of file identifications which integrates
easily with 'software inventory' tools.
* It does not depend on the plugin developer implementing robust argument
processing. 
* The plugin does not have to be functional to get the data (ie on a central
depot that stores plugins for all platforms)
* Implementing it does not require linking to any external libraries (perl's
GetOpt::Long and such). This is important since adding them to existing code
requires more testing than defining a variable.

> by all compilers" which immediately makes me reticent.
The #ident C pragma was just an idea, there are very easy compiler-generic
ways of embedding that data. I have a document somewhere that describes how
to do it in many common languages that I can provide if we go this route.

> But I don't want to introduce "another way" for the sake of it. Unless 
> you have a very good reason.
I understand; if the above isn't convincing then I'll work out some other
way to manage the data and perhaps start submitting some --version patches.

Thanks,
-Jason Martin
-- 
Smoking is a leading cause of statistics.
This message is PGP/MIME signed.

-----------------------------------------
Egg is a trading name of the Egg group of companies which includes: Egg plc
(reg no 2448340), Egg Financial Products ltd (reg no 3319027), Egg
International ltd (reg no 4059266), Egg Financial Intermediation ltd (reg
no 382828), Egg Investments ltd (reg no 3403963) and Egg Banking plc (reg
no 2999842.  Egg Investments Ltd, Egg Banking plc and Egg Financial
Intermediation Ltd are authorised and regulated by the Financial Services
Authority (FSA) and are entered in the FSA register under numbers 190518,
205621 and 309551 respectively. These members of the Egg group are
registered in England and Wales. Registered offices: 1 Waterhouse Square,
138-142 Holborn, London EC1N 2NA.    This e-mail is confidential and for
use by the addressee only.  If you are not the intended recipient of this
e-mail and have received it in error, please return the message to the
sender by replying to it and then delete it from your mailbox.  Internet
e-mails are not necessarily secure. The Egg group of companies do not
accept responsibility for changes made to this message after it was sent.
Whilst all reasonable care has been taken to avoid the transmission of
viruses, it is the responsibility of the recipient to ensure that the
onward transmission, opening or use of this message and any attachments
will not adversely affect its systems or data. No responsibility is
accepted by the Egg group of companies in this regard and the recipient
should carry out such virus and other checks as it considers appropriate.
This communication does not create or modify any contract.