Hi Eric,
Thanks for your answers!
On Fri, 8 Dec 2006, Eric Mei wrote:
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.
The CPU overhead of bulk data checksumming on servers should be quite
high; FWIW a simple test of sha1sum gives me 154 MB/s with my fairly
recent CPU. The additional cost (CPUs or HW crypto engines) required to
achieve good performance may be too high for most HPC users, at least for
regular access inside a cluster; it could be interesting to enable or
disable checksumming for classes of clients.
- 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.
It sounds like an implementation problem that surfaces to the user. :-/
Maybe the operations you mention should be possible with unauthenticated
clients?
- 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.
If I'm not mistaken, AFS with Kerberos uses one principal for all servers
in a cell, and a keytab is propagated to all servers. But maybe GSS adds
specific constraints, I don't know.
Cheers,
--
Jean-Marc Saffroy - [EMAIL PROTECTED]
_______________________________________________
Lustre-devel mailing list
[email protected]
https://mail.clusterfs.com/mailman/listinfo/lustre-devel
