Backup Central

Attachments: Message as HTML Message as HTML

On Mar 19, 2007, at 6:59 AM, Jorj Bauer wrote:
What: The ability to read a configuration file as stdout from an
executable

Why: The configuration files (particularly for the Director) are very
complex. In my case I find it easier to have a program generate them
from meta-information about the clients.

Notes:

The attached patch implements this. It's a simple change to lex.c, and
functions globally: if the first character of any configuration file's
name is a pipe ("|"), then the rest of the "filename" is considered to
be the path to an executable. The program is run, stdout is read, and
the output is the configuration file.

For example, starting the director like this:

# bacula-dir -c '|/usr/local/sbin/generate-dir-config'

... would cause it to run /usr/local/sbin/generate-dir-config to
generate a new configuration file.

Hey, that sounds pretty useful. When you say "globally", I assume you
mean that I can just toss a similar line into bacula-dir to generate
a subset of the configuration data from a script?

--
--Darien A. Hager
darien < at > et...
Mobile: (206) 734-5666

Attachments: Message as HTML

# bacula-dir -c '|/usr/local/sbin/generate-dir-config'

... would cause it to run /usr/local/sbin/generate-dir-config to
generate a new configuration file.
=20
=20
Hey, that sounds pretty useful. When you say "globally", I assume you =20
mean that I can just toss a similar line into bacula-dir to generate =20
a subset of the configuration data from a script?

When I said "globally" I meant "for all of the daemons" (fd, dir, sd).

Your idea has merit, but I think it would be a much more substantial
patch. This patch specifically changes the behavior when starting to
open a file.

You can certainly replicate the behavior you're suggesting by using this
patch, and having your own script do the parsing-and-modification.

-- Jorj

On Mar 19, 2007, at 10:38 AM, Jorj Bauer wrote:

# bacula-dir -c '|/usr/local/sbin/generate-dir-config'

... would cause it to run /usr/local/sbin/generate-dir-config to
generate a new configuration file.


Hey, that sounds pretty useful. When you say "globally", I assume you
mean that I can just toss a similar line into bacula-dir to generate
a subset of the configuration data from a script?

When I said "globally" I meant "for all of the daemons" (fd, dir, sd).

Your idea has merit, but I think it would be a much more substantial
patch. This patch specifically changes the behavior when starting to
open a file.

You can certainly replicate the behavior you're suggesting by using
this
patch, and having your own script do the parsing-and-modification.

Hmm. Myself, I'd prefer a "include-from-script" directive I could
place in the director. I suppose when you get down to it, both
potential features (entire conf from script, subset from script) can
be accomplished with existing capabilities (run script first, include
from generated file.)

Nevertheless, I can't speak for many others, but if I could write a
line to "grab client/job definitions from this script" within bacula-
dir.conf, I would use it.

--
--Darien A. Hager
darien < at > et...
Mobile: (206) 734-5666

Jorj Bauer wrote:
What: The ability to read a configuration file as stdout from an executable

Why: The configuration files (particularly for the Director) are very
complex. In my case I find it easier to have a program generate them
from meta-information about the clients.

Notes:

The attached patch implements this. It's a simple change to lex.c, and
functions globally: if the first character of any configuration file's
name is a pipe ("|"), then the rest of the "filename" is considered to
be the path to an executable. The program is run, stdout is read, and
the output is the configuration file.

For example, starting the director like this:

# bacula-dir -c '|/usr/local/sbin/generate-dir-config'

Maybe I am missing some important point, but by now I can't see any mayor
benefits of your solution compared with:

# /usr/local/sbin/generate-dir-config > /etc/bacula/bacula-dir.conf &&
bacula-dir -c /etc/bacula/bacula-dir.conf

Andreas

Attachments: Message as HTML

Maybe I am missing some important point, but by now I can't see any mayor
benefits of your solution compared with:
=20
# /usr/local/sbin/generate-dir-config > /etc/bacula/bacula-dir.conf &&
bacula-dir -c /etc/bacula/bacula-dir.conf

It's subtle. You're missing the 'reload' command.

-- Jorj

Attachments: novosirj.vcf

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Andreas Helmcke wrote:
Jorj Bauer wrote:
What: The ability to read a configuration file as stdout from an executable

Why: The configuration files (particularly for the Director) are very
complex. In my case I find it easier to have a program generate them
from meta-information about the clients.

Notes:

The attached patch implements this. It's a simple change to lex.c, and
functions globally: if the first character of any configuration file's
name is a pipe ("|"), then the rest of the "filename" is considered to
be the path to an executable. The program is run, stdout is read, and
the output is the configuration file.

For example, starting the director like this:

# bacula-dir -c '|/usr/local/sbin/generate-dir-config'

Maybe I am missing some important point, but by now I can't see any mayor
benefits of your solution compared with:

# /usr/local/sbin/generate-dir-config > /etc/bacula/bacula-dir.conf &&
bacula-dir -c /etc/bacula/bacula-dir.conf

I myself can't see the point of generate-dir-config. I know this is just
an example, but what might this script/program do that a flat file
can't? Maybe I'm missing something neat here, but I'm curious what one
would want to do with such a thing.

- --
---- _ _ _ _ ___ _ _ _
|Y#| | | |\/| | \ |\ | | |Ryan Novosielski - Systems Programmer III
|$&| |__| | | |__/ | \| _| |novosirj < at > um... - 973/972.0922 (2-0922)
\__/ Univ. of Med. and Dent.|IST/AST - NJMS Medical Science Bldg - C630
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFF/ztNmb+gadEcsb4RAoBeAKCotpTTgZ5pMnfhq2BpCJuYXkOfDACeOBaI
ROr4nFz3uKRyUYX3LiJwVAw=
=jYso
-----END PGP SIGNATURE-----

Attachments: Message as HTML

For example, starting the director like this:

# bacula-dir -c '|/usr/local/sbin/generate-dir-config'
=20
Maybe I am missing some important point, but by now I can't see any may=
or
benefits of your solution compared with:
=20
# /usr/local/sbin/generate-dir-config > /etc/bacula/bacula-dir.conf &&
bacula-dir -c /etc/bacula/bacula-dir.conf
=20
I myself can't see the point of generate-dir-config. I know this is just
an example, but what might this script/program do that a flat file
can't? Maybe I'm missing something neat here, but I'm curious what one
would want to do with such a thing.

We have hundreds of clients to back up and fairly high turnover. All of
our information about the clients (budget codes, email addresses, client
IP, which storage node to back up to, and so on) are in a custom local
database. There are a couple of ways that the database is updated (local
scripts and web pages, either started by admin staff or directly by
customers).

We could run a command to regen the config whenever anyone modifies a
record, but that's distributing work that really ought to be centralized
(we'd have to have lockfiles and make sure that all of the cases were
handled). The simple solution is to have the director actually generate
its own configuration file on demand.

The general idea comes from Radiator, which does something similar.

-- Jorj