Hi, Jean-Marc Saffroy wrote:
Questions (keep in mind I have little knowledge of kerberos): - will that stuff stay in 1.8, or could it be backported to 1.6?
Only since 1.8, we'v no plan of backporting to 1.6.
- given the comments on performance overhead, I suspect that krb5i-bulkn is what most people will be asking for (good authentication and performance, at the expense of data protection): then why not make it a basic setting?
Probably, currently we are just not sure. But we can easily change it once we know which is the best. Thanks for the advice.
Speak the performance hit, it's not seriously tested yet. The impact might different from system to system, the main overhead is CPU cycles on crypting, and a little bit more network traffic. So on systems with powerful CPUs or hardware encryption the situation might not too bad. Just a guess though.
- is it mandatory to deploy a keytab on clients? I don't remember having done that when testing AFS+krb5
Yes it's mandatory, this will add some burden to sysadmin. The reason is a little bit involved, we hope root could always own valid secure contexts, otherwise a failed callback RPC from server to client will lead to the client be kicked out off cluster.
- is it really necessary to create a principal for each server node?
Maybe I'm wrong: this is required by GSS/Kerberos. But it will be great if someone confirm that per-server principal is not necessary, that way the configuration will be easier and hard to say less secure.
- why per OST/MDT mount options? does it make sense (at least for the common case) to have different options on differents targets?
Maybe you are right, same as the above issue of default flavor. Before we are sure what kind of interface is better, we just keep the flexibility, which may looks ugly.
These code is still in alpha, never have feedback from outside of CFS, so any of your opinions are high appreciated!
- why does a root user *not* need kinit to access the fs?
Because the keytab installed on each client node, it act like root already authenticated.
In real deployment, we suppose on MDTs root users should be mapped to a normal user (to prevent a compromised client destroying all data) except it's come from specific trusted clients.
Best Wishes -- Eric _______________________________________________ Lustre-devel mailing list [email protected] https://mail.clusterfs.com/mailman/listinfo/lustre-devel
