On 05/19/2013 04:25 AM, Nux! wrote: > What would happen if one peer is SSL enabled (i.e. has all > the bits in place) and one is not (i.e. has a missing key); would the > transfer/process go back to non-SSL or just die with some errors? Pretty sure it would die, with some sort of protocol-error message on the SSL side. > Any chance the SSL feature could be managed through glusterd? Just as > glusterd is responsible for vol files across the deployment and so on, > it should also be able to generate and maintain key/ca files. There's a security angle to that. We explicitly don't want to take responsibility for securing keys etc. in transit, especially while the glusterd communication itself is unencrypted. That might be a future enhancement, but only after some of the other pieces are in place. > Any way to turn on just multi-threading, without SSL? Yes, though again not from the CLI. You have to add something like this to the protocol/client or protocol/server translators in your volfile (or use --xlator-option from the glusterfs/glusterfsd command line) option transport.socket.own-thread on > Yes, it could sure have its use cases, such as securing traffic going > through some "public" VLANs (the case with many "cloud" deployments). FWIW, that's how I've used it myself. For several months, I had my own GlusterFS setup "in the cloud" using SSL and at-rest encryption from home/work/etc. It was very light usage, being just myself, but I know others have used it more heavily.
