Dear Mr Jacobfeuerborn,
May I reply to you, may you check > What version of haproxy are you using ? (And what OS) ? HA-Proxy 1.5.11 and Ubuntu 14.04 with Postgres 9.3 >>>>> Are you able to connect to the /var/lib/haproxy/test socket with >>>>> netcat or socat ? And/or do you have chroot in haproxy.cfg ? local@PGSYNCTEST:~$ sudo netcat localhost < /var/lib/haproxy/test -bash: /var/lib/haproxy/test: Permission denied local@PGSYNCTEST:~$ sudo -u haproxy netcat localhost < /var/lib/haproxy/test -bash: /var/lib/haproxy/test: Permission denied > > To fix your issue, simply update your bind line: >> bind > > /var/lib/haproxy/test accept-proxy user haproxy group haproxy >> >> Same on server line: >> server clear /var/lib/haproxy/test send-proxy user haproxy group haproxy local@PGSYNCTEST:~$ sudo -u haproxy /etc/init.d/haproxy restart * Restarting haproxy haproxy [ALERT] 078/153401 (25721) : parsing [/etc/haproxy/haproxy.cfg:46] : 'server clear' unknown keyword 'user'. Registered keywords : [ ALL] id <arg> [ SSL] ca-file <arg> [ SSL] check-ssl [ SSL] ciphers <arg> [ SSL] crl-file <arg> [ SSL] crt <arg> [ SSL] force-sslv3 [ SSL] force-tlsv10 [ SSL] force-tlsv11 [ SSL] force-tlsv12 [ SSL] no-sslv3 [ SSL] no-tlsv10 [ SSL] no-tlsv11 [ SSL] no-tlsv12 [ SSL] no-tls-tickets [ SSL] send-proxy-v2-ssl [ SSL] send-proxy-v2-ssl-cn [ SSL] ssl [ SSL] verify <arg> [ SSL] verifyhost <arg> [ALERT] 078/153401 (25721) : Error(s) found in configuration file : /etc/haproxy/haproxy.cfg [ALERT] 078/153401 (25721) : Fatal errors found in configuration. After that I removed the line server clear /var/lib/haproxy/test send-proxy user haproxy group haproxy, then returning back to my own server lines Then like this local@PGSYNCTEST:~$ sudo -u haproxy /etc/init.d/haproxy restart * Restarting haproxy haproxy [WARNING] 078/152556 (25673) : [/usr/local/sbin/haproxy.main()] Cannot raise FD limit to 90034. [ALERT] 078/152556 (25673) : Starting frontend GLOBAL: error when trying to preserve previous UNIX socket [/var/run/haproxy.sock] [ALERT] 078/152556 (25673) : Starting frontend pgdbplatform_frontend_cluster01: cannot change UNIX socket ownership [/var/lib/haproxy/test] [ALERT] 078/152556 (25673) : sendto logger #1 failed: Permission denied (errno=13) [ALERT] 078/152556 (25673) : sendto logger #2 failed: Permission denied (errno=13) Therefore may you observe and advise me, Ha. IT Manager of Canwrx and Anvy Digital Companies. ----- Original Message ----- From: "Dennis Jacobfeuerborn" <[email protected]> To: [email protected] Sent: Friday, March 20, 2015 8:23:50 AM Subject: Re: send/accept-proxy over unix socket not working On 18.03.2015 13:53, Baptiste wrote: > On Wed, Mar 18, 2015 at 1:07 PM, Lukas Tribus <[email protected]> wrote: >> >> >> ---------------------------------------- >>> Date: Wed, 18 Mar 2015 01:49:47 +0100 >>> From: [email protected] >>> To: [email protected]; [email protected] >>> CC: [email protected] >>> Subject: Re: send/accept-proxy over unix socket not working >>> >>> On 13.03.2015 18:44, Lukas Tribus wrote: >>>>> What version of haproxy are you using ? (And what OS) ? >>>>> >>>>>> In the first frontend I set: >>>>>> server clear /var/lib/haproxy/test send-proxy >>>>>> >>>>>> In the second frontend I set: >>>>>> bind /var/lib/haproxy/test accept-proxy >>>>> >>>>> Are you able to connect to the /var/lib/haproxy/test socket with >>>>> netcat or socat ? And/or do you have chroot in haproxy.cfg ? >>>> >>>> Also if you drop privileges, check permission with the haproxy user. >>>> >>>> If supported by your kernel, you could use abstract namespaces >>>> instead. >>> >>> According to the documentation abstract namespaces are not recommended >>> when using nbproc> 1. The reason I'm dealing with unix sockets at all >>> is that I want to get around the problem of losing the stick table >>> content on reload I posted about in another mail. The idea is to run two >>> instances. One with nbproc> 1 for ssl offloading and that forwards the >>> requests to the second instance that is using nbproc = 1 and contains >>> the http frontend and a backend. In theory this should allow me to >>> reload the config of the backend instance without losing the stick table >>> content. >>> >>> I'm using chroot /var/lib/haproxy but the behavior is the same without >>> this directive. Either way a socket gets created as >>> /var/lib/haproxy/test as intended but for some reason I keep getting 503 >>> when using a unix socket but everything works fine when using abstract >>> namespaces or an ip address. >>> >>> I've attached the configuration and the debug output in case that helps >>> to pinpoint the issue. >> >> Comment user and group and run haproxy as root. If thats works, it means >> you have a permission problem. >> >> >> Lukas >> >> >> > > Hi > > He has a permission problem! > > That's what I mentionned with the user parameter on the bind line.. > > Actually, HAProxy starts up as root and create the socket with root > user, then it drops it switches to user haproxy, group haproxy > (according to your conf). > This user is not allowed to access the socket, since there is no write > allowed for "others". > > To fix your issue, simply update your bind line: > bind /var/lib/haproxy/test accept-proxy user haproxy group haproxy > > Same on server line: > server clear /var/lib/haproxy/test send-proxy user haproxy group haproxy > > > Hope this helps. Yes, that did the trick, thanks! Now I'm wondering if I can stick with the abstract namespace after all though. The Documentation has this to say: "Note: since abstract sockets are not "rebindable", they do not cope well with multi-process mode during soft-restart, so it is better to avoid them if nbproc is greater than 1. The effect is that if the new process fails to start, only one of the old ones will be able to rebind to the socket." Since the SSL offloading instance with nbproc > 1 only addresses the abstract namespace in the server directive and the second instance that does the bind in the abstract namespace is running with nbproc = 1 would it be correct to assume that in this specific case the rebinding is not an issue since it is only the nbproc=1 instance that is doing the actual "bind" call? If that is correct then I could keep using the abstract namespace and have no need for the traditional unix sockets. Regards, Dennis
