Kern Sibbald wrote: > On Thursday 15 March 2007 16:40, Jorj Bauer wrote: > >>> Bacula does its normal HMAC-MD5 password authentication >>> >> I never meant to imply that it did not, although my message was >> obviously interpreted that way by at least two people. >> >> >>> The FD address cannot be part of the certificate (CN or any other field) >>> if roaming FDs are ever to be supported. >>> >> Agreed. >> >> >>> An arbitrary CN will effectively make TLS used for encryption only, >>> not authentication, >>> >> Not true; with my proposed patch, the required CN is specified in the >> Client clause of the Director's config file. One would be verifying that >> it is the correct machine by virtue of the contents of the CN field, but >> with something other than a hostname. Of course one could neuter this by >> embedding the same information in each certificate if one wanted to, but >> I don't see a reason for that. >> >> >>> Your patch (or something similar) is necessary to support roaming >>> clients using TLS. So with this patch the cert can be used regardless of >>> FD address, getting a step closer to support of roaming FDs. But how and >>> when does the "SetIP" console command get sent to the Dir? >>> >> That's done through a restricted console. >> >> >>> I see several problems with the SetIP approach. What if Bacula attempts >>> to run the job before the SetIP is issued? >>> >> Then the job will fail. >> >> >>> What if the SetIP is issued, but before the job is run bacula-dir is >>> restarted or reloaded? >>> >> I assume the job will fail, as the Director will be looking at the wrong >> address. >> >> >>> For roaming clients that are not on all of the time it is entirely >>> likely that they will only rarely if ever be backed up. >>> >> My intent is to not schedule roaming clients at all, but rather have the >> clients issue a "setip" followed by a "run job=". >> >> >>> The patch allows TLS to work for these clients, but still leaves it a >>> guessing game as to when to run the job. >>> >>> I don't see how roaming FDs are really feasible until client-initiated >>> backups are implemented. >>> >> And this is possible now, to some extent, using a console. It's not yet >> clear to me whether or not the restricted-console needs to be expanded >> to be able to run jobs for the given client, or if the security of the >> "name" being correct is sufficient, or if subsequent TLS cerificate >> information would need to be present (and validated in some manner). >> > > Though there is a project for client initiated backups, I view it as already > being implemented by using scripting with bconsole and restricted clients > that send a setip followed by a run job as you have described above. > > There is one (important) case where the above does not work, and that is that > the client cannot truely run as a "server" because it is NATed or behind a > firewall. To resolve that, I envision that at some point in the future, the > FD itself will have a "mini" console implemented in it, that will connect to > the Director, issue the setip and run job, then will use the same open > connection for the backup. The client will still need *exactly* the same > restricted console privileges as the current client bconsole scripting > requires to initiate the backup. > >
Thank you both. That answers my questions and is what I meant by supporting roaming FDs. For example, we have people here who travel quite a bit and connect through hotel networks. It is perhaps possible to backup those laptops through VPN tunnels (in which case neither Bacula TLS nor SetIP may be needed), but they are not connected regularly enough for a scheduled job. I am just now learning of the ability of a client to initiate backups through the restricted console, so I will give that a try. >>> Still, separating the FD address from the cert is going to be required >>> in order to support roaming clients. >>> >> Indeed. >> >> -- Jorj >> > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys-and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > Bacula-users mailing list > Bacula-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bacula-users > > ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
