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.
This post was automatically imported from historical nagios-devel mailing list archives
Original poster: [email protected]