Re: [Gluster-devel] gluster SSL support

[Zbyszek Żółkiewski]

Hello,

Thank you for the response, yes i have finally managed to enable ssl mode, 
seems like gluster takes only specific certificates into account, or - 
generated with CN Anyone - i am not sure why it did not worked with previously 
generated certs (as i mentioned it hung on verify).
Anyway i have made blogpost about how to set-it-up: 
http://blog.onefellow.com/2014/01/enable-glusterfs-ssl-mode.html maybe someone 
find that useful, as it is not documented (yet).

thanks for the help!
__
Zbyszek Żółkiewski

On 24 Jan 2014, at 14:06, Jeffrey Darcy <address@hidden> wrote:

> key > Thanks for reply. I will explain my environment as it is quite bit 
> different
>> then usual setup. I am using gluster 3.4.
>> For now i am using gluster to sync 2 servers - both have bricks attached - so
>> i can say that they both are servers and clients (let say master-master
>> config) - i need this setup to ensure that when one node goes offline, files
>> are still intact - i have that setup on other environments with more nodes
>> and it works great (thus on them gluster works via vpn).
>> To be exact: on both servers there is local “brick” and it is mounted by:
>> 
>> mount -t glusterfs host-X:/gv0 /mnt/gv0
>> 
>> so even when last replica goes offline, files are still there for last
>> running server.
>> 
>> Answering your question: yes certs are properly installed - i have tried
>> various combinations - but now i am not sure if my config do not make
>> confusion for the glusterfs.
>> 
>> What do you think?
> 
> Assuming that your keys/certs were generated something like this...
> 
>   openssl genrsa -out $SSL_KEY 1024
>   openssl req -new -x509 -key $SSL_KEY -subj /CN=Anyone -out $SSL_CERT
> 
> ...and that the following relationships apply...
> 
>   glusterfs.pem and glusterfs.key match on each host
>   glusterfs.pem on host-X == glusterfs.ca on host-Y
>   glusterfs.pem on host-Y == glusterfs.ca on host-X
> 
> ...then there's no obvious reason it wouldn't work.  First thing I'd consider
> is whether something like SELinux is preventing access to those files (perhaps
> using strace to verify).  Another thing to try would be to use s_server and
> s_client (part of the OpenSSL package) to ensure that *they* can work with
> those files.  Lastly,

smime.p7s
Description: S/MIME cryptographic signature