> 
> I agree.  However, using an optional 'third-party' tool is quite
> acceptable to all.  I refer here to Fruity and Nagios.  The use
> of Fruity is optional.  It produces plain text configuration files
> to be used by Nagios.  That is the approach I would endorse
> for Bacula should anyone desire to code such a beast.
> 

Maybe a compromise would be to modify the 'include' statement so that
could include an normal bacula config file (as it is now), an xml file,
or from a database. If you were doing any of the latter two then your
main bacula.conf file would just contain a single include line. It might
also contain some bare essential config stuff so that the same config
could still be used for disaster recovery, but essentially everything
would be in your included data.

That way we could all have the configuration mechanism we want without
it upsetting anyone else. We could also have any combination of the
above we wanted.

I have never looked closely at the configuration code, but I believe
that the stuff that actually does the parsing is pretty well contained,
so I don't know that such a feature would be that intrusive.

Kern: If someone submitted a patch to allow this would you consider
accepting it? (if not, the point is probably moot :) Is this something a
director plugin could accomplish?

James


-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Bacula-users mailing list
Bacula-users AT lists.sourceforge DOT net
https://lists.sourceforge.net/lists/listinfo/bacula-users