[Nagios-devel] [Nagiosplug-devel] RFC: Plugins config file (final proposal) (Nagios V3 object macros)

Tobias Klausmann klausman at schwarzvogel.de
Tue Jan 30 09:34:16 UTC 2007


Hi! 

On Mon, 29 Jan 2007, Ethan Galstad wrote:
> Now that I'm thinking about it, this type of file format seems
> like it must be used by a number of apps.  There's probably a
> GPL'ed library out there that can read/write config entries to
> a file in the proposed format.

As a data point: the Python stdlib contains a module that's
capable of reading such [section] config files. I'm sure it isn't
hard to find one for Perl. About C I'm not sure though.

As for style, I prefer the [section] over section{}. The latter
supports nesting which AFAICT we don't need. And it's a tiny bit
mor complicated to parse (if you're, validating that is). Other
than that, there's no difference between:

[section1]
foo=bar

[section2]
baz=barney

and

section1 {
foo=bar

section2 {
baz=barney

(Note the missing closing braces, if you're validating, that
 makes a difference. If you're parsing naively, it doesn't.) 

> As for loosing the ability to keep private information in the
> Nagios host/service definitions...  I guess that's a good
> reason to make sure the monitoring server isn't used by normal
> users.  If its a dedicated box, it shouldn't matter what
> information is being passed on the command lines between the
> daemon and the plugins.

Another argument for a monitoring server having no ordinary user
(besides user accounts for the monitoring admins) is that such a
box usually has elevated permissions packet-filter-wise. 

Also, users tend to "accidentally" create load peaks on
machines. Something I'd rather not have on my Nagios box - re:
check latencies and such. Also, generating a lot of mails (re:
user cron jobs) can hamper notification delivery.

Regards,
Tobias

-- 
Never touch a burning system.




More information about the Nagios-devel mailing list