eg:- gluster peer probe 10.1.10.300 results in glusterd hang. Messages in /var/log/glusterfs/etc-glusterfs-glusterd.vol.log are about DNS resolution (Name or service not known). And this request goes into an infinite loop until the glusterd is killed and restarted. We need a validation routine for checking ipv4 octets. I am surprised to see that there is no validation for this, before even going into DNS resolution. Strange part is it even lists that in "gluster peer status" as disconnected and you can't even detach it and says it is part of the cluster.
(In reply to comment #0) > eg:- gluster peer probe 10.1.10.300 results in glusterd hang. > > Messages in /var/log/glusterfs/etc-glusterfs-glusterd.vol.log are about DNS > resolution (Name or service not known). > Is there any more input needed on this to move this forward?
> Is there any more input needed on this to move this forward? No, waiting for the patches from bug 763981 to move in before pushing in the changes. The above said patches moves the host-name validation/ ip-addr validation to libglusterfs.
Have added the fix the check if peer ip/hostname are valid as part of peer probe command. If the octet is > 255, it will be treated as a valid hostname, even though it wont be a valid ipv4 address. Valid range for hostname: ASCII chars : 'a' to 'z', '0' to '9', '.', '-', with max of 255 chars.
PATCH: http://patches.gluster.com/patch/6210 in master (Validate peer probe command's hostname/ip address.)
As shishir has mentioned wrong IP address can be a valid hostname. If invalid hostname is given then it gives out the usage. gluster peer probe opo_opo Usage: peer probe <HOSTNAME>