On Fri, Dec 08, 2006 at 11:42:31AM +0100, Stef Coene wrote:

On Friday 08 December 2006 10:12, Johann Eggers wrote:

...

Using a database just for configurations makes things more complex. It would be marvellous if somebody is willing to develop a web-based frontend for editing the config files.

Give me some months ;)

Hendrik, can you confirm that the config files are compliant with the ini-style of config files ? If so, parsing with perl is easy. If not, maybe we can make them compliant.

Uhm, no - I don't think they are.

hobbit-alerts.cfg is of the form

SELECTIONCRITERIA ACTION1 EXTRACRITERIA ACTION2 E.g.

GROUP=admins MAIL henrik at hswn.dk SERVICE=timetest MAIL henrik-daytime at hswn.dk TIME=*:1546:1700

Internally, Hobbit converts this into a "flat" form, which you'll see if you use the "dump config" command. The above is equivalent to

MAIL henrik at hswn.dk GROUP=admins
MAIL henrik-daytime at hswn.dk TIME=*:1546:1700 SERVICE=TIMETEST

hobbit-clients.cfg is similar. E.g.

HOST=client2.hswn.dk PROC sshd TRACK=ssh-daemons PROC msgcache TRACK=msgcache-daemons HOST=freebsd6.hswn.dk PROC dhclient

which is converted into the "flat" form of

PROC sshd TRACK=ssh-daemons HOST=client2.hswn.dk
PROC msgcache TRACK=msgcache-daemons HOST=client2.hswn.dk
    PROC dhclient HOST=freebsd6.hswn.dk

The only ini-style config file, I believe, is the client-local.cfg file.

However, that doesn't mean you cannot use ini-style files for your front-end. As long as you can convert whatever configuration style you use into a format the Hobbit understands, it will work. The actual Hobbit config file may end up looking pretty awful, but if it's only going to be read by machines then it doesn't really matter. (Think of the difference between the sendmail.cf file that sendmail uses, and the M4 configuration macros that you actually modify when you tweak your sendmail configuration. And no - I am NOT saying that the Hobbit config format is just as awful as sendmail.cf :-))

The bb-hosts file is the way it is - I probably don't have to describe that to you. One change I have in mind for this - well, it will actually eliminate the bb-hosts file and replace it with something different - is to split the host definition and the webpage layouts. So there would be one file defining the hosts (their names, IP-address, what network tests we run, which graphs to show etc.), and another set of files defining the layout of the webpages. This will make it much easier to define multiple layouts for the webpages. Since the format for these new files hasn't been decided yet, you have almost free hands to choose what it should be like. All that I ask is that it will be possible to implement a function to load all of the host definitions like the one currently in Hobbit's lib/loadhosts_file.c source: This basically reads the entire bb-hosts file, and splits each of the lines into tokens which can then be scanned using the known keywords we have for bb-hosts entries.

And please remember to allow for custom keywords, for those who write their own custom tests.

Regards, Henrik

On Fri, Dec 08, 2006 at 04:32:46PM +0100, Stef Coene wrote:

On Friday 08 December 2006 13:39, Henrik Stoerner wrote:

...

...

Hendrik, can you confirm that the config files are compliant with the ini-style of config files ? If so, parsing with perl is easy. If not, maybe we can make them compliant.

Uhm, no - I don't think they are.

And what about switching to ini-style config files in the next version? I don't know (but I'm sure there is) if a ini-file library exist for C. It exists for perl and it's very easy to parse and even generate config files.

The problem is that these configs don't match ini-style files. With ini-files, you have only one possible selection criteria - the name of the section in the ini-file. But the client- and alert-configuration uses lots of different criteria - you can use hostnames to control who gets an alert, but you can also use testnames, or time-of-day, or the page the host is on, or just the color of the status. Ini-style configuration cannot cope with this - at least, I cannot imagine how.

Regards, Henrik

On Fri, Dec 08, 2006 at 10:41:44PM +0100, Stef Coene wrote:

I just took a quick look at the function load_alertconfig. Pfffff.

I think my problem is that I start out defining the result I'd like to have - in this case how the configuration file should work - and only after doing that do I begin to consider how one can actually implement it. It means the result is usually pretty good from an end-user point of view, but it does increase the amount of work needed to do the programming :-)

Regards, Henrik