How many protocol/client translators are you using? Can you mail the volume specification file? glusterfs tries to bind to privileged ports which are free. It cannot bind to ports which are already being used. No need to change the value of CLIENT_PORT_CEILING, since if the client cannot bind to any privileged ports it will try to bind to non privileged ones. But If the authentication being used on server side is ip based, it requires client to be bound to a privileged port.
regards,
On Tue, Feb 3, 2009 at 6:26 PM, Geoff Kassel <gkassel@xxxxxxxxxxxxxxxxxxxxx> wrote:
Hi,
Noticed an odd thing with GlusterFS 2.x. It (as compared to 1.3.8) now
takes over a lot of privileged ports - and a lot of times, the ports stolen
aren't really 'free' for GlusterFS to be using.
For example, I run mail servers, and provide the usual access methods -
POP3, IMAP, and their SSL variants on ports 993 and 995. I've found that
GlusterFS will often take over ports 993 and 995 - and about twenty other
privileged ports at the same time. Sometimes really low ports, like port 1
(!)
This stops other services from binding to these ports. Hence, when I
attempt a full restart of my GlusterFS dependent services (i.e. when changing
GlusterFS configuration, or recovering from a crash) I find most of my
services won't restart properly, which is a big issue for me.
Browsing through the code, I found the CLIENT_PORT_CIELING (sic - that
should probably be CLIENT_PORT_CEILING) setting in the transport translators,
and I've altered this appropriately up to 65536, so that there's no
competition between GlusterFS and my existing services.
However, I feel that this is a somewhat inconvenient step to have to make
in order to get GlusterFS to play nice with other services.
Would it be possible to have a translator configuration option that allows
this to be set from a server or client volume file, without having to
manually patch and recompile GlusterFS each time I want to change this
setting?
Thank you in advance for your time and effort in considering my request.
Kind regards,
Geoff Kassel.
_______________________________________________
Gluster-devel mailing list
Gluster-devel@xxxxxxxxxx
http://lists.nongnu.org/mailman/listinfo/gluster-devel
--
Raghavendra G
