On Mon, Sep 22, 2014 at 7:27 PM, Jeff Darcy <jdarcy@xxxxxxxxxx> wrote:
> It looks like this doesn't work as quota tries to create a temp mount which
> fails hence the above error. quota acts as a local client for glusterd
> (IIUC) and since we have the gluster volume enabled for SSL it fails the
> mount hence limit-usage fails.
hen SSL is enabled, *all* mounts must use it. That includes internal
ones, such as NFS/Samba, quota, or any form of snapshots. We could add
"dual mode" support, allowing both SSL and non-SSL connections to the
same bricks, but in many cases that would defeat the purpose of having
strong authentication in the first place.
This is a bug, plain and simple. The quota volfile-generation and/or
connection code needs to be fixed to honor the SSL options (including
those that control SSL on the management path as well as the I/O path).
Hi Jeff,
Thanks for your response.
For quota code to use SSL, it will need client side certificates as well.
Thanks for your response.
For quota code to use SSL, it will need client side certificates as well.
As i mentioned in my original mail.. I was not able to get the gluster
mount w/ SSL to work on the brick node and posted the error log (it says "error
mount w/ SSL to work on the brick node and posted the error log (it says "error
during SSL connect").
Can you throw some light on that ? My guess is that there is an issue with
the server and client trying to refer to the same set of .key|.pem files but
wanted to validate the same with you.
the server and client trying to refer to the same set of .key|.pem files but
wanted to validate the same with you.
Longer term, maybe we need a more bullet-proof abstraction. Instead of
making calls to connect to entity X using method Y, we should just make
a connection to X and the RPC code will internally select the
appropriate method. The same abstraction will also be necessary when we
implement proper multi-network support, so that the RPC code can choose
the right address/route from among several for the same resource.
_______________________________________________ Gluster-devel mailing list Gluster-devel@xxxxxxxxxxx http://supercolony.gluster.org/mailman/listinfo/gluster-devel
