> 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). > Still, separating the FD address from the cert is going to be required > in order to support roaming clients. Indeed. -- Jorj
pgpiMIRFltUHj.pgp
Description: PGP signature
------------------------------------------------------------------------- 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
