> > 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,
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
> 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 environme
> > 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 doe
> > 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
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
> > con
> 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
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 Winkler**
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.
>
>
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 Fruit
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 direc
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
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
> 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 non
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
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
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
-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 smar
> > 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
19 matches
Mail list logo
