On Thursday 26 April 2007 23:32, Darien Hager wrote:
David Boyes wrote:
Brainstorming idea: XML with Schema validation?
* The config would be a plain file and portable.
Ugh. plain XML is a matter of opinion -- XML of any real complexity
couldn't be hand-coded.
Well, myself I
Uhm, sorry, just read this thread.
We have made something like this for our company,
I am sure we did not match all the requirements.
But we use a XML file and then generate the config file.
The program is writen in php.
I will try to make it available in the next few days.
Ralf
*Ralf
I have no problems with putting the bacula conf files in to the
database
if
someone wants to do so. However, I don't foresee any change in the
ASCOO
format that Bacula requires -- i.e. I don't foresee Bacula reading its
conf
file directly from an SQL database.
Fair enough.
Thinking out
On Wednesday 02 May 2007 16:56, David Boyes wrote:
I have no problems with putting the bacula conf files in to the
database
if
someone wants to do so. However, I don't foresee any change in the
ASCOO
format that Bacula requires -- i.e. I don't foresee Bacula reading its
conf
file
Thinking out loud about how to implement this: would you consider a
directive that specified a script to be run whenever a Bacula component
needed to open or reference the config file that would supply the name
of a file to read for the information? The idea would be similar to the
Since he has implemented it as an enhancement of the conf file
specification
at the lexically scanner level, it will apply to *all* Bacula
components
that
accept the -c option, which is every component (or tool) that needs
a
conf
file.
Yes, that's exactly what the patch does, and why
OK, neat. Does that also allow regeneration of the file while the daemon
is running, eg, what happens if you issue a reload command? Do you get a
updated file?
Yes. Whenever Bacula tries to open a configuration file, it instead
opens a pipe.
Reason for the question: in a larger environment,
Jorj Bauer wrote:
Since he has implemented it as an enhancement of the conf file specification
at the lexically scanner level, it will apply to *all* Bacula components
that
accept the -c option, which is every component (or tool) that needs a conf
file.
Yes, that's exactly what the
OK, neat. Does that also allow regeneration of the file while the
daemon
is running, eg, what happens if you issue a reload command? Do you
get a
updated file?
Yes. Whenever Bacula tries to open a configuration file, it instead
opens a pipe.
Cool. That'll work for me. Nice job, BTW.
On Apr 26, 2007, at 4:41 PM, Dan Langille wrote:
Fruity is the configuration tool for Nagios. I suggest that such a
tool for Bacula would be useful too.
However, all configuration files should be plain text. Much like
what Fruity does.
Unlike Nagios, Bacula already has an include
On Apr 26, 2007, at 4:59 PM, Adam Thornton wrote:
On Apr 26, 2007, at 4:41 PM, Dan Langille wrote:
Fruity is the configuration tool for Nagios. I suggest that such a
tool for Bacula would be useful too.
However, all configuration files should be plain text. Much like
what Fruity does.
The design of a GUI for bacula may revolve arround interfacing with
the dameons. I was wondering
if just designing a GUI for config file modification might simply
suffice, i.e. a config file editor with
the smarts of syntax checking and linking of all the resources in
the main
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
David Boyes wrote:
The design of a GUI for bacula may revolve arround interfacing with
the dameons. I was wondering
if just designing a GUI for config file modification might simply
suffice, i.e. a config file editor with
the smarts of syntax
I thought of this also a while ago, but thought the efforts would be too
much.
Here is what I came up with:
Use a shell/perl/php script to retrieve values from sql-DB into the conf
file for
Each deamon before it starts up (minimizes sw changes to bacula) All that
needs to
Be know then is the DB
Cross-posting this particular reply to the developers list as well...
On Apr 26, 2007, at 8:16 AM, Ryan Novosielski wrote:
This has been rejected before, and the reason being that you really
don't want to have to have a database in order to read your tapes. If
you have an emergency that you
On Thursday 26 April 2007 20:57, Darien Hager wrote:
Cross-posting this particular reply to the developers list as well...
On Apr 26, 2007, at 8:16 AM, Ryan Novosielski wrote:
This has been rejected before, and the reason being that you really
don't want to have to have a database in order
On Apr 26, 2007, at 8:16 AM, Ryan Novosielski wrote:
This has been rejected before, and the reason being that you really
don't want to have to have a database in order to read your tapes.
I would disagree with you here. What I want is to get back to a
controlled restore process that
David Boyes wrote:
Brainstorming idea: XML with Schema validation?
* The config would be a plain file and portable.
Ugh. plain XML is a matter of opinion -- XML of any real complexity
couldn't be hand-coded.
Well, myself I have very similar Job and Client definitions for about 60
On 26 Apr 2007 at 11:57, Darien Hager wrote:
Brainstorming idea: XML with Schema validation?
Please no.
* The config would be a plain file and portable.
* It would be relatively easy for admins to write tools to read and
write from the config.
* With a library that supports validation,
19 matches
Mail list logo
