On Fri, Jul 24, 2015 at 2:42 PM, Timo Schaepe <[email protected]> wrote:
> Hi, > > > On 23 Jul 2015, at 18:25, Atin Mukherjee <[email protected]> > wrote: > > > > > > -Atin > > Sent from one plus one > > On Jul 23, 2015 3:41 PM, "Timo Schaepe" <[email protected]> wrote: > > > > > > Hey guys, > > > > > > 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. > > > > > > Is there a possibility to change the annouced ip adresses? > > > Or is there another way to solve this problem? > > Probably in that case its better to peer probe using public domain name > instead of internal IP? > > I tried this first with negative result: > > azureuser@stage1-gluster2:~$ sudo gluster peer probe > stage1-gluster1.cloudapp.net > peer probe: failed: Error through RPC layer, retry again later > > And in the log of the opposite: > > [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 > [2015-07-24 08:51:23.984945] E [socket.c:2276:socket_connect_finish] > 0-management: connection to 95.211.117.206:24007 failed (Connection timed > out) > [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. > [2015-07-24 08:51:23.985153] I [socket.c:3374:socket_submit_reply] > 0-socket.management: not connected (priv->connected = -1) > [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) > > 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? > > In the above logs, ": connection to 95.211.117.206:24007 failed (Connection timed out)" is the important part. 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? 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. server.allow-insecure removes the restriction that clients should always connect using a port < 1023. This is a rudimentary mechanism to ensure that the user on client is a privileged user and hence can be trusted if the client-ip is already a trusted one. 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. Thanks, > > Timo > > > > > > > > Thanks, > > > > > > Timo > > > _______________________________________________ > > > Gluster-users mailing list > > > [email protected] > > > http://www.gluster.org/mailman/listinfo/gluster-users > > _______________________________________________ > Gluster-users mailing list > [email protected] > http://www.gluster.org/mailman/listinfo/gluster-users > -- *Raghavendra Talur *
_______________________________________________ Gluster-users mailing list [email protected] http://www.gluster.org/mailman/listinfo/gluster-users
