<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jul 24, 2015 at 2:42 PM, Timo Schaepe <span dir="ltr"><<a href="mailto:info@timoschaepe.de" target="_blank">info@timoschaepe.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<span class=""><br>
> On 23 Jul 2015, at 18:25, Atin Mukherjee <<a href="mailto:atin.mukherjee83@gmail.com">atin.mukherjee83@gmail.com</a>> wrote:<br>
><br>
><br>
> -Atin<br>
> Sent from one plus one<br>
</span><span class="">> On Jul 23, 2015 3:41 PM, "Timo Schaepe" <<a href="mailto:info@timoschaepe.de">info@timoschaepe.de</a>> wrote:<br>
> ><br>
> > Hey guys,<br>
> ><br>
> > we are trying to use gluster 3.6.4 in a cloud environment. Creating the gluster itself is not a problem. Mounting the created vol from a machine in the cloud infrastructure is not a problem. But when I am trying to mount the created gluster vol from an external machine it fails. In the log files of the client I can see that gluster is annoucing the bricks with the cloud infrastructure internal ips, which are not accessible from outside of the cloud. When I change the internal ips to the public domain names in /var/lib/glusterd/gv0.tcp-fuse.vol on every cluster host it works seamless. I definitely think that this is not the recommended way to solve this problem. Of course it breaks, if I add another bricks to the gluster.<br>
> ><br>
> > Is there a possibility to change the annouced ip adresses?<br>
> > Or is there another way to solve this problem?<br>
> Probably in that case its better to peer probe using public domain name instead of internal IP?<br>
<br>
</span>I tried this first with negative result:<br>
<br>
azureuser@stage1-gluster2:~$ sudo gluster peer probe <a href="http://stage1-gluster1.cloudapp.net" rel="noreferrer" target="_blank">stage1-gluster1.cloudapp.net</a><br>
peer probe: failed: Error through RPC layer, retry again later<br>
<br>
And in the log of the opposite:<br>
<br>
[2015-07-24 08:51:03.223634] E [rpcsvc.c:617:rpcsvc_handle_rpc_call] 0-rpc-service: Request received from non-privileged port. Failing request<br>
[2015-07-24 08:51:23.984945] E [socket.c:2276:socket_connect_finish] 0-management: connection to <a href="http://95.211.117.206:24007" rel="noreferrer" target="_blank">95.211.117.206:24007</a> failed (Connection timed out)<br>
[2015-07-24 08:51:23.985078] I [MSGID: 106004] [glusterd-handler.c:4398:__glusterd_peer_rpc_notify] 0-management: Peer 00000000-0000-0000-0000-000000000000, in Establishing Connection state, has disconnected from glusterd.<br>
[2015-07-24 08:51:23.985153] I [socket.c:3374:socket_submit_reply] 0-socket.management: not connected (priv->connected = -1)<br>
[2015-07-24 08:51:23.985167] E [rpcsvc.c:1247:rpcsvc_submit_generic] 0-rpc-service: failed to submit message (XID: 0x1, Program: GlusterD svc cli, ProgVers: 2, Proc: 1) to rpc-transport (socket.management)<br>
<br>
I didn’t set “server.allow-insecure”, because I think it is not a good idea. It is ok to use this in public and productive environment? I am also using ssl, do the “allow-insecure” setting has an impact on this security?<br>
<br></blockquote><div><br></div><div>In the above logs, ": connection to <a href="http://95.211.117.206:24007">95.211.117.206:24007</a> failed (Connection timed out)" is the important part.</div><div>How is the packet routed if you use public IPs/hostnames for peer probe? Could it be that 24007 port is blocked by your cloud provider?</div><div><br></div><div>You don't need to use server.allow-insecure for this particular case but may require it is clients are not able to communicate with bricks.</div><div>server.allow-insecure removes the restriction that clients should always connect using a port < 1023. This is a rudimentary mechanism to ensure</div><div>that the user on client is a privileged user and hence can be trusted if the client-ip is already a trusted one. </div><div><br></div><div>If you have ssl enabled then it is a better way to ensure trust factor of client than the above mechanism, hence server.allow-insecure should not harm.</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Thanks,<br>
<br>
Timo<br>
<span class=""><br>
<br>
> ><br>
> > Thanks,<br>
> ><br>
> > Timo<br>
> > _______________________________________________<br>
> > Gluster-users mailing list<br>
</span>> > <a href="mailto:Gluster-users@gluster.org">Gluster-users@gluster.org</a><br>
> > <a href="http://www.gluster.org/mailman/listinfo/gluster-users" rel="noreferrer" target="_blank">http://www.gluster.org/mailman/listinfo/gluster-users</a><br>
<div class="HOEnZb"><div class="h5"><br>
_______________________________________________<br>
Gluster-users mailing list<br>
<a href="mailto:Gluster-users@gluster.org">Gluster-users@gluster.org</a><br>
<a href="http://www.gluster.org/mailman/listinfo/gluster-users" rel="noreferrer" target="_blank">http://www.gluster.org/mailman/listinfo/gluster-users</a></div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr"><font color="#666666"><b>Raghavendra Talur </b></font><div><br></div></div></div>
</div></div>