<div dir="ltr">Try <div><br></div><div>gluster volume set VOLNAME client.bind-insecure on </div><div><br></div><div>and remount clients. If servers refuse connection, you might also have to set server.allow-insecure to on.<br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jun 13, 2018 at 9:41 AM, Milind Changire <span dir="ltr"><<a href="mailto:mchangir@redhat.com" target="_blank">mchangir@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div class="gmail-h5">On Wed, Jun 13, 2018 at 6:12 PM, Canh Ngo <span dir="ltr"><<a href="mailto:canhnt@gmail.com" target="_blank">canhnt@gmail.com</a>></span> wrote:<br></div></div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div class="gmail-h5"><div dir="ltr"><div style="font-size:small">Hi all,</div><div style="font-size:small"><br></div><div style="font-size:small">We run a storage cluster using GlusterFS v3.10.12 on CentOS7. Clients (CentOS) are using glusterfs 3.8.4.</div><div style="font-size:small"><br></div><div style="font-size:small">We notice when clients mounts bricks of a volume, sometimes glusterfs uses system ports (i.e. in port range 0-1024) to connect to remote glusterfsd port. e.g:</div><div style="font-size:small"><br></div><div style="font-size:small">Server: <br></div><div style="font-size:small">tcp 0 0 <a href="http://10.165.210.169:49161" target="_blank">10.165.210.169:49161</a> <a href="http://10.165.210.51:850" target="_blank">10.165.210.51:850</a> ESTABLISHED 32760/glusterfsd</div><div style="font-size:small"><br></div><div style="font-size:small">Client:</div><div style="font-size:small">tcp 0 0 <a href="http://10.165.210.51:850" target="_blank">10.165.210.51:850</a> <a href="http://10.165.210.169:49161" target="_blank">10.165.210.169:49161</a> ESTABLISHED 25483/glusterfs<br></div><div style="font-size:small"><br></div><div style="font-size:small">Thus, sometimes glusterfs occupies our system ports (e.g. 995, 179, 443, etc), that causes other services cannot start.</div><div style="font-size:small"><br></div><div style="font-size:small">Is is a bug or an expected behavior? I expect glusterfs should use IANA private ports rather than system ports. Do you know if we can configure glusterfs to use a specific port range?<br></div><div style="font-size:small"><br></div><div><div class="gmail-m_-2843317009873092142gmail-m_-7146312934380214247gmail_signature"><div dir="ltr"><div>Thanks,</div><div>Canh Ngo.</div></div></div></div>
</div>
<br></div></div>______________________________<wbr>_________________<br>
Gluster-users mailing list<br>
<a href="mailto:Gluster-users@gluster.org" target="_blank">Gluster-users@gluster.org</a><br>
<a href="http://lists.gluster.org/mailman/listinfo/gluster-users" rel="noreferrer" target="_blank">http://lists.gluster.org/mailm<wbr>an/listinfo/gluster-users</a><br></blockquote></div><br><br clear="all"><br><div>Here's some info on the kernel (sysctl) tunables that you could tweak:</div><div>/proc/sys/net/ipv4/ip_local_<wbr>port_range</div><div>/proc/sys/net/ipv4/ip_local_<wbr>reserved_ports</div><div><br></div><div>Here's what networking/ip-sysctl.txt from the kernel documentation directory says:</div><div>ip_local_port_range - 2 INTEGERS<br> Defines the local port range that is used by TCP and UDP to<br> choose the local port. The first number is the first, the<br> second the last local port number.<br> If possible, it is better these numbers have different parity.<br> (one even and one odd values)<br> The default values are 32768 and 60999 respectively.<br><br>ip_local_reserved_ports - list of comma separated ranges<br> Specify the ports which are reserved for known third-party<br> applications. These ports will not be used by automatic port<br> assignments (e.g. when calling connect() or bind() with port<br> number 0). Explicit port allocation behavior is unchanged.<br><br> The format used for both input and output is a comma separated<br> list of ranges (e.g. "1,2-4,10-10" for ports 1, 2, 3, 4 and<br> 10). Writing to the file will clear all previously reserved<br> ports and update the current list with the one given in the<br> input.<br><br> Note that ip_local_port_range and ip_local_reserved_ports<br> settings are independent and both are considered by the kernel<br> when determining which ports are available for automatic port<br> assignments.<br><br> You can reserve ports which are not in the current<br> ip_local_port_range, e.g.:<br><br> $ cat /proc/sys/net/ipv4/ip_local_<wbr>port_range<br> 32000 60999<br> $ cat /proc/sys/net/ipv4/ip_local_<wbr>reserved_ports<br> 8080,9148<br><br> although this is redundant. However such a setting is useful<br> if later the port range is changed to a value that will<br> include the reserved ports.<br><br> Default: Empty<br><br></div><div>You
could check the values of these files on your system and configure them
accordingly. Gluster specifically looks at
/proc/sys/net/ipv4/ip_local_<wbr>reserved_ports to avoid assigning values
from the reserved port range. Alternatively, you could configure the
system via /etc/sysctl.conf to persist the settings across reboots:</div><div><br></div><div>net.ipv4.ip_local_reserved_<wbr>ports</div><div>net.ipv4.ip_local_port_range<br></div><div><br></div><div>Hope this helps.</div><div><br></div><div>--</div><div>Milind</div>
</div></div>
<br>______________________________<wbr>_________________<br>
Gluster-users mailing list<br>
<a href="mailto:Gluster-users@gluster.org">Gluster-users@gluster.org</a><br>
<a href="http://lists.gluster.org/mailman/listinfo/gluster-users" rel="noreferrer" target="_blank">http://lists.gluster.org/<wbr>mailman/listinfo/gluster-users</a><br></blockquote></div><br></div></div></div>