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