Hello,
For the case originally reported: as someone has already commented,
one should be able to handle it using SD Calls Client directive.
For the case of a FD that is firewalled (the inverse of the original
post starting this email thread, Bacula Systems has a new feature
called Client Initiated Backups, which works quite nicely. Obviously
those backups must be initiated from the client (FD) machine.
At the current time, this is handled either manually or via some
sort of cron script. In the longer term, the Client Initiated Backup
will have its own very simplistic scheduler.
The good news is, providing I can find the time, I will backport this
new feature to the next major community version of Bacula due
out in a few months.
Best regards,
Kern
On 08/05/2016 06:14 PM, mark.bergman AT uphs.upenn DOT edu wrote:
> In the message dated: Fri, 05 Aug 2016 14:50:29 +0200,
> The pithy ruminations from Andreas Koch on
> <[Bacula-users] Backup of system outside of restrictive firewall?> were:
> => -----BEGIN PGP SIGNED MESSAGE-----
> => Hash: SHA1
> =>
> => Hello all,
> =>
> => while we have been extremely happy over the years using Bacula to handle
> our
> => internal systems, we are a bit stumped now on how to backup a machine
> => outside of a rather restrictive firewall.
> =>
> => Said firewall is basically configured to deny all incoming connections (but
> => allows connections initiated from the inside).
>
> How do you manage the machine behind the restrictive firewall? Do you
> allow any incoming connections (ie., ssh from a specific list of known
> source addresses)?
>
> =>
> => With the default approach Bacula uses
> =>
> => 1. Director (inside of firewall) tells File Daemon (outside of firewall) on
> => remote machine to begin backup -- OK
> =>
> => 2. File Daemon (outside of firewall) attempts to connect to Storage Daemon
> => (inside of firewall) -- FAILS
> =>
>
> [SNIP!]
>
> => I'd also be interested to know how other users have tackled such a setup!
>
> We've got a similar situation. In our case, one machine behind a firewall
> only permits incoming ssh connections (for system management) from
> a single know address. We use that ability to allow incoming SSH
> connections to send all bacula traffic via SSH, and use SSH to set up
> tunnels connecting the ports used by the storage daemon and file daemon.
>
> Our backup process is:
>
> 1. Director initiates scheduled backup.
>
> 2. RunBeforeJob starts an shell script on bacula-dir.server to set up an
> ssh tunnel
> between bacula-dir.server and restricted.machine
>
> 2a. Since the bacula-dir process runs as user bacula, the script
> uses 'sudo' to run the ssh command as 'root' (bacula has
> permission to run 'ssh' as root without a password). This
> means that ssh can create a tunnel using a privileged
> (<1024) local port and the ssh connection will use root's
> credentials. There are separate public/private keys for
> this tunnel under ~root/.ssh.
>
> The bacula-dir.server:~root/.ssh/config file uses a
> 'host' entry for the restricted.machine so that all
> ssh connections use the specified keys and run as the
> 'tunnel' user.
>
> The SSH tunnel does the following:
>
> bacula-dir.server port 9112 forwards through the tunnel to
> restricted.machine port 9102
>
> restricted.machine traffic to bacula-dir.server:9101 forwards
> through the tunnel to bacula-dir.server port 9101
>
> restricted.machine traffic to bacula-dir.server:9103 forwards
> through the tunnel to bacula-dir.server port 9103
>
> The bacula configuration on bacula-dir.server for the
> restricted.machine client identifies the FD for the
> client as running on "localhost" at port 9112.
>
> 3. Once the RunBefore script is up (and the tunnel exists):
>
> When the bacula director tries to contact the client to
> start the backup, it sends traffic to 'itself' on port
> 9112. SSH forwards that traffic through the tunnel to
> the File Daemon (at port 9102) on the actual client.
>
> The client returns data to the bacula Storage Daemon
> by connecting to bacula-dir.server:9103. SSH sends that
> data through the encrypted tunnel.
>
>
> There are a lot of delicate, precise parts to set up, but once it is
> configured it works without any problems.
>
> See:
> http://wiki.bacula.org/doku.php?id=sshtunnel
>
>
> In theory, this kind of process could take place over any VPN connection,
> but the details would change.
>
> If the restricted machine allows no incoming connections at all then you
> could do something like... run a cron job on restricted.machine at time
> "HH:MM", starting an ssh tunnel into the bacula server. On the bacula
> server, schedule backups of the restricted machine to begin at time
> "HH:MM + 2". The configuration would be similar to what I described above.
>
>
> Mark
>
>
> =>
> => Many thanks,
> => Andreas
> => -----BEGIN PGP SIGNATURE-----
> => Version: GnuPG v2
> =>
> => iEYEARECAAYFAleki5UACgkQk5ta2EV7Doz9MQCfRmU9ImeSRts5MnAxfLkTeWmJ
> => yt8An0FFKTpRrN8j9w734hntvEN2P5bn
> => =pBW4
> => -----END PGP SIGNATURE-----
> =>
> =>
> ------------------------------------------------------------------------------
>
------------------------------------------------------------------------------
_______________________________________________
Bacula-users mailing list
Bacula-users AT lists.sourceforge DOT net
https://lists.sourceforge.net/lists/listinfo/bacula-users
|
