> I might be misunderstanding some of this, but I thought that the way > of doing SSL (as you say, two years ago), and the mechanism, the > generation and transferring of certificates, and so on, was going to > be updated with a new mechanism in 3.6...? SSL was updated in a couple of ways for 3.6: * Per-volume authorization by SSL identity * Full support for SSL to glusterd as well as glusterfsd * New options for ciphers, certificate depth I toyed with the idea of switching from OpenSSL to PolarSSL as part of the process, but that's a big piece of work and I never got to it. Among other benefits, that *might* allow SSL to work with multi-epoll. On the other hand, they might have the same inverted "poll for read when you need to write (and vice versa)" behavior as OpenSSL, for the same reasons. I just haven't gone through their API enough to know. > As soon as the mechanism is "stable" and hopefully won't change too > much (maybe that is already the case) please let me know, and point me > to the authoritative docs/reference/notes/napkins on how to do > ssl+gluster and I'll patch this in to puppet-gluster to aid adoption > and for "documentation as puppet code". Here are some previous emails and wiki pages about how to set it up. * http://gluster.org/pipermail/gluster-devel/2014-January/028480.html * http://lists.gnu.org/archive/html/gluster-devel/2013-05/msg00139.html * http://blog.onefellow.com/2014/01/enable-glusterfs-ssl-mode.html Really, I think the best place to start is a couple of the tests: * https://github.com/gluster/glusterfs/blob/master/tests/bugs/bug-873367.t * https://github.com/gluster/glusterfs/blob/master/tests/features/ssl-authz.t The first one shows how to set up a minimal SSL configuration; the second shows how to use SSL identities to limit access to a volume (a feature being used now in Manila BTW). What I still need to do is wrap it all in some explanations of how SSL works and how the files must therefore relate to one another (across clients and servers), plus an example of how to use certificate signing instead of directly including each peer's certificate in others' CA files. _______________________________________________ Gluster-devel mailing list Gluster-devel@xxxxxxxxxxx http://supercolony.gluster.org/mailman/listinfo/gluster-devel
