[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Bacula-devel] patch for presence of file daemon
Kern Sibbald wrote:
> Possible New code:
> What is really missing in the FD is item 2 in the current projects list "Allow
> FD to initiate a backup". What I had planned here is the following: modify
> the FD so that it can be contacted by a local console and the FD (not Dir)
> can be asked to do a Backup, or simply to send its IP address. The FD would
> then simulate a console (possibly identifying itself as the FD) and do a
> SETIP command, and possibly ask for a backup. Note, both of these are
> already controlled by restricted consoles, so the security is pretty much
> What is different about this is that if the FD requests a backup, the
> Director's console handler would start the job but pass the open console
> connection it has with the FD to the backup command, and the backup would
> proceed over that connection. That permits implementing project item 2 and
> it also allows a work around for certain firewall problems where the Director
> cannot contact a particular client (maybe the client is behind a firewall or
> NATed in another network) so the Director can use the connection made by the
That would be a very useful capability for those of us dealing with
laptops that are intermittently connected. Still, it might be useful to
allow the Director to limit the times/days that a client can request a
backup. Perhaps it would be possible to use something like a Schedule
resource for that and a "AllowClientBackupRequest = <Schedule resource>"
in the Job (or JobDefs) resource? Probably the default should be to
never allow client initiated backup, since currently it is assumed that
backups always occur on a predefined schedule.
> I also would not be opposed to adding a directive to the FD that tells it to
> send its IP address to the Director when the FD starts, but it would do so by
> using the console "emulation" and sending the SETIP command.
> So, I think what I proposed above will essentially give you what you have
> implemented, but a bit simpler, and it will also implement project item 2,
> which will take a bit of additional work.
> If this interests you, we will need to discuss a few of the details so I can
> show you how we can identify and if we want multiplex the FD, which is quite
> easy to do.
> Best regards,
> PS: though it is probably not necessary, I have made a few comments below ...
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
Bacula-devel mailing list
This mailing list archive is a service of Copilotco.