medical device
Yourmostprofessionalmedica=l-onlyB2Bwebsite =nbsp; www.FMHmedical.comBringingyourproductsinformationtotheworld!ThenewonlinetradingplatformFMHmedicalisthelargestandmostprofessionalmedicalamp; rehabilitationproductsinformation database,wherethemostrelevantbuyersbrowse andsendtheirinquiries toyouinreal-time.FMHmedicalhelpsyoutomarketyourproductsworldwidebymatchingthesourcingneedsofmillions ofbuyers.Buyerrsquo;sfavor=ite~Thelatesttechnologyandthemost user-friendly=interface.#61692;Supplierrsquo;sfavorite~Upda=tedproductinformationandupdatebasedon=mostrecentbrowsingandinquiries.#61672;RealPeopl=e,RealInquiriesNotonlyinterestedbuyerswillbrowseourwebsitebutyour productsinformationisalsosentbyourprofessionalp=ersonnel whomatchyourproductstotheneedsofbuyersfromour=large database,ensuringthatyourinfoissenttorelevantt=hirdparties. Experienceourserviceforfree!FMHtrialmemberscanupload10productsforfree.Addyourproductsin3easys=teps:Step1.Connecttowww.FMHmedical.com Step2.ClickonJoinUsNow!andcompletethereq=uestedcompanyinformation.=Step3.Afterlogin,clickonAddProducts(youcanuploadupto10productsf=orfree)toaddyourproducts,itrsquo;sdone!=Incaseofanyoperational=problems,youarewelcometo contactusatanytime!+Getthewholepackage!#61672;Beonline,beonsite!FMHMedicalamp;Health,with23yearsofpublicationhistory, istheworldrsquo;snumber1medical-onlybuyerrsquo;=sguide. Itisprintedtwiceayear(springeditionandautumne=dition)anddistributedinabout40internationalmedicalexhibitions=throughouttheworld.Itisdistributedonsitetothousandso=f professionalvisitorswhocarryawayyouradvertisinga=nd contactdetailswiththem!Fullpage: USD2,600(1issue)ndash;USD4,940(2iss=ues)ndash;USD9,360(4issues)Spread: USD4,400(1=issue)ndash;USD8,360(2issues)ndash;USD15,840(4issues)GetyourADtoreachprofessionalbuyersthroughoutthemedicalworl=d!AdvertiseinFMHMedicalamp;Healthandyouwillbeableto=uploadupto100productsonourB2Bwebsite! FORMOSACULTURALCORPORATIONFMH=Medicalamp;Health(Buyerrsquo;sGuide)2F.-1,No.716,Jhongj=hengRd.,JhongheDist.,NewTaipeiCity23552,TaiwanTel:=886-2-82273289 Fax:886-2-82273269 E-mail: b2bserv...@fmh.com.tw= Website:http://www.FMHmedical.com
HAProxy and site failover
hi, first time / long time... i am wondering if the ability exists in HAProxy to reply to a HTTP proxy request with a reset (RST) if no backend server is available. the scenario goes as such: i have a proxy pac file that assigns multiple proxies to all clients, and through the logic tree in the pac file, the proxies are assigned in a specific order. i have multiple sites with load balanced proxies, and the intention is to provide site failover, should a larger event occur like ISP issues that breaks internet access. with the pac file assigning all proxy VIPs to the client, should the default VIP not have an available backend server to fulfill the request, i would want to configure HAProxy to send a reset to the client, indicating that the next assigned proxy should be used. with site failover happening transparently, a user who would normally browse through the proxy/proxies at site1 would be automatically failed over and browse through the proxy/proxies at site2. if no servers were available in site2, then the next assigned proxy would be used and failures with RST replies would result in failovers until all assigned proxies are exhausted. the intention is not to provide / assign hundreds of proxies in the pac file, but to provide resiliency with a couple of sites serving as backups to each other, should an event warrant it. thank you, brendan kearney
Re: Attached: May you support me for this issue logs of HAProxy
Loads simpler to do the following: ## /etc/haproxy/haproxy.cfg global log /dev/log local0 notice ## /etc/rsyslog.d/49-haproxy.conf # Create an additional socket in haproxy's chroot in order # to allow logging via /dev/log to chroot'ed HAProxy processes $AddUnixListenSocket /var/lib/haproxy/dev/log # Send HAProxy messages to a dedicated logfile if $programname startswith 'haproxy' then /var/log/haproxy.log ~ I believe most of the above is included in Vincent Bernat's very nice Ubuntu/Debian packages, https://launchpad.net/~vbernat Ramin
sticky sessions with tcp mode
I am having some issues with sticky sessions. The sessions are not sticking. I am using tcp mode with ssl. I have implemented the example out of the manual. The user is getting bounced back and forth between the two servers, which is causing issues in the application. Am I missing something? HA-Proxy version 1.5.2 2014/07/12 frontend pc bind 192.168.10.72:443 mode tcp option tcplog default_backend pc backend pc mode tcp balance roundrobin stick-table type binary len 32 size 30k expire 30m acl clienthello req_ssl_hello_type 1 acl serverhello rep_ssl_hello_type 2 tcp-request inspect-delay 5s tcp-request content accept if clienthello tcp-response content accept if serverhello stick on payload_lv(43,1) if clienthello stick store-response payload_lv(43,1) if serverhello server r15-21 192.168.10.21:443 check server r16-22 192.168.10.22:443 check “CONFIDENTIALITY AND PROPRIETARY INFORMATION NOTICE: This email, including attachments, is covered by the Electronic Communications Privacy Act (18 U.S.C. 2510-2521) and contains confidential information belonging to the sender which may be legally privileged. The information is intended only for the use of the individual or entity to which it is addressed. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution or the taking of any action in reliance of the contents of this information is strictly prohibited. If you have received this electronic transmission in error, please immediately notify the sender by return e-mail and delete this message from your computer or arrange for the return of any transmitted information.”
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 luky...@hotmail.com wrote: Date: Wed, 18 Mar 2015 01:49:47 +0100 From: denni...@conversis.de To: luky...@hotmail.com; jarno.huusko...@uef.fi CC: haproxy@formilux.org 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
Re: send/accept-proxy over unix socket not working
Dear Mr Jacobfeuerborn , I would like to appreciate, I am trying to follow your instructions our my system and will do the tests right away. What version of haproxy are you using ? (And what OS) ? HA-Proxy 1.5.11 and Ubuntu 14.04 with Postgres 9.3 You bet, Ha. - Original Message - From: Dennis Jacobfeuerborn denni...@conversis.de To: haproxy@formilux.org 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 luky...@hotmail.com wrote: Date: Wed, 18 Mar 2015 01:49:47 +0100 From: denni...@conversis.de To: luky...@hotmail.com; jarno.huusko...@uef.fi CC: haproxy@formilux.org 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
Re: Checked: send/accept-proxy over unix socket not working
And/or do you have chroot in haproxy.cfg ? Yes, may I send you our haproxy.cfg now global log /var/log local0 log /var/log local1 notice maxconn 45000 # Total Max Connections. This is dependent on your limit user haproxy group haproxy daemon #nbproc 4 # Number of processors, quad-core by default chroot /var/lib/haproxy pidfile /var/run/haproxy.pid tune.ssl.default-dh-param 2048 stats socket /var/run/haproxy.sock mode 600 level admin stats timeout 2m defaults log global mode tcp option tcplog #option dontlognull option redispatch retries 3 timeout queue 1m timeout connect 10s timeout client 1m timeout server 1m timeout check 10s maxconn 2000 frontend pgdbplatform_frontend_cluster01 #bind *:5432 bind /var/lib/haproxy/test accept-proxy user haproxy group haproxy mode tcp timeout client 168h option tcplog option logasap default_backend pgdbplatform_backend_cluster01 backend pgdbplatform_backend_cluster01 mode tcp option tcplog balance roundrobin # Load Balancing algorithm timeout server 168h #server Primary 10.236.49.12:5432 check #server HotStandby 172.24.22.68:5432 check #server AsyncStandby 10.236.134.187:5432 check server clear /var/lib/haproxy/test send-proxy user haproxy group haproxy Thank you, Ha. - Original Message - From: Ha Quan Le nlp...@shaw.ca To: denni...@conversis.de Cc: haproxy@formilux.org Sent: Friday, March 20, 2015 11:37:38 AM Subject: Checked: send/accept-proxy over unix socket not working 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 denni...@conversis.de To: haproxy@formilux.org 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 luky...@hotmail.com wrote: Date: Wed, 18 Mar 2015 01:49:47 +0100 From: denni...@conversis.de To: luky...@hotmail.com; jarno.huusko...@uef.fi CC: haproxy@formilux.org 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
OCSP stappling full support
Hi, HAProxy provides OCSP stapling since v1.5 and this is nice! Although, it is still difficult to setup compared to Apache or Nginx. I had to do this little script: https://wiki.mozilla.org/Talk:Security/Server_Side_TLS#OCSP_in_HAProxy It would be really nice if it was as easy as Apache and Nginx. Is it planned in the roadmap? Thanks a lot for your work, Pierre -- I use PGP to protect our privacy, if you want to know more, you can follow this https://emailselfdefense.fsf.org/en/ If you have further questions, please do not hesitate to ask. You can verify my public key here: https://keybase.io/pierreozoux signature.asc Description: OpenPGP digital signature
Checked: send/accept-proxy over unix socket not working
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 denni...@conversis.de To: haproxy@formilux.org 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 luky...@hotmail.com wrote: Date: Wed, 18 Mar 2015 01:49:47 +0100 From: denni...@conversis.de To: luky...@hotmail.com; jarno.huusko...@uef.fi CC: haproxy@formilux.org 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
Re: Checked: send/accept-proxy over unix socket not working
Good, local@PGSYNCTEST:~$ sudo /etc/init.d/haproxy restart [sudo] password for local: * Restarting haproxy haproxy [ALERT] 078/181429 (1600) : Starting frontend pgdbplatform_frontend_cluster01: cannot bind socket [0.0.0.0:5432] [fail] This is because Postgres occupied port 5432 Hence, we try again local@PGSYNCTEST:~$ sudo service postgresql stop * Stopping PostgreSQL 9.3 database server [ OK ] local@PGSYNCTEST:~$ sudo /etc/init.d/haproxy restart * Restarting haproxy haproxy [ OK ] local@PGSYNCTEST:~$ sudo service postgresql start * Starting PostgreSQL 9.3 database server But my questions are not about how to start HA-Proxy, my questions are that we received no logs of RSYSLOG from HA-Proxy, even log files of HA-Proxy are not created. May I send you the attachment, you will see all of our settings inside, our errors are that NO LOGS OF HA-PROXY CREATION. May you support, Ha. - Original Message - From: Jarno Huuskonen jarno.huusko...@uef.fi To: Ha Quan Le nlp...@shaw.ca Cc: haproxy@formilux.org Sent: Friday, March 20, 2015 1:42:24 PM Subject: Re: Checked: send/accept-proxy over unix socket not working Hi, On Fri, Mar 20, Ha Quan Le wrote: local@PGSYNCTEST:~$ sudo -u haproxy /etc/init.d/haproxy restart * Restarting haproxy haproxy [WARNING] 078/171401 (1267) : [/usr/local/sbin/haproxy.main()] Cannot raise FD limit to 90034. You're trying to start/restart haproxy as haproxy user (sudo -u). start/restart as root and let haproxy drop privs (user / group in haproxy.cfg). [ALERT] 078/171401 (1267) : Starting frontend GLOBAL: error when trying to preserve previous UNIX socket [/var/run/haproxy.sock] [ALERT] 078/171401 (1267) : Starting frontend pgdbplatform_frontend_cluster01: cannot bind socket [0.0.0.0:5432] Try restarting as root. If it still doesn't work then make sure that there's no haproxy process left from earlier tests. And if it still complains about cannot bind [0.0.0.0:5432] then you have something else already listening to that socket. -Jarno -- Jarno Huuskonen GOOD HAProxy 1.5 -- 1) Removal of old HA-Proxy1.4 $ sudo apt-get remove haproxy 2) Preparation $ cd /usr/local/src/ local@PGSYNCTEST:/usr/local/src$ sudo apt-get install build-essential local@PGSYNCTEST:/usr/local/src$ sudo apt-get build-dep -y haproxy local@PGSYNCTEST:/usr/local/src$ sudo apt-get install -y libssl-dev local@PGSYNCTEST:/usr/local/src$ sudo apt-get install libpcre3-dev 3) Download HA-Proxy 1.5 local@PGSYNCTEST:/usr/local/src$ sudo wget http://www.haproxy.org/download/1.5/src/haproxy-1.5.11.tar.gz local@PGSYNCTEST:/usr/local/src$ sudo tar xvf haproxy-1.5.11.tar.gz local@PGSYNCTEST:/usr/local/src$ cd haproxy-1.5.11 4) Installation local@PGSYNCTEST:/usr/local/src/haproxy-1.5.11$ sudo make TARGET=linux2628 USE_PCRE=1 USE_OPENSSL=1 USE_ZLIB=1 gcc -Iinclude -Iebtree -Wall -O2 -g -fno-strict-aliasing -DCONFIG_HAP_LINUX_SPLICE -DTPROXY -DCONFIG_HAP_LINUX_TPROXY -DCONFIG_HAP_CRYPT -DUSE_ZLIB -DENABLE_POLL -DENABLE_EPOLL -DUSE_CPU_AFFINITY -DASSUME_SPLICE_WORKS -DUSE_ACCEPT4 -DNETFILTER -DUSE_GETSOCKNAME -DUSE_OPENSSL -DUSE_SYSCALL_FUTEX -DUSE_PCRE -I/usr/include -DCONFIG_HAPROXY_VERSION=\1.5.11\ -DCONFIG_HAPROXY_DATE=\2015/01/31\ \ -DBUILD_TARGET='linux2628' \ -DBUILD_ARCH='' \ -DBUILD_CPU='generic' \ -DBUILD_CC='gcc' \ -DBUILD_CFLAGS='-O2 -g -fno-strict-aliasing' \ -DBUILD_OPTIONS='USE_ZLIB=1 USE_OPENSSL=1 USE_PCRE=1' \ -c -o src/haproxy.o src/haproxy.c gcc -Iinclude -Iebtree -Wall -O2 -g -fno-strict-aliasing -DCONFIG_HAP_LINUX_SPLICE -DTPROXY -DCONFIG_HAP_LINUX_TPROXY -DCONFIG_HAP_CRYPT -DUSE_ZLIB -DENABLE_POLL -DENABLE_EPOLL -DUSE_CPU_AFFINITY -DASSUME_SPLICE_WORKS -DUSE_ACCEPT4 -DNETFILTER -DUSE_GETSOCKNAME -DUSE_OPENSSL -DUSE_SYSCALL_FUTEX -DUSE_PCRE -I/usr/include -DCONFIG_HAPROXY_VERSION=\1.5.11\ -DCONFIG_HAPROXY_DATE=\2015/01/31\ -c -o src/sessionhash.o src/sessionhash.c gcc -Iinclude -Iebtree -Wall -O2 -g -fno-strict-aliasing -DCONFIG_HAP_LINUX_SPLICE -DTPROXY -DCONFIG_HAP_LINUX_TPROXY -DCONFIG_HAP_CRYPT -DUSE_ZLIB -DENABLE_POLL -DENABLE_EPOLL -DUSE_CPU_AFFINITY -DASSUME_SPLICE_WORKS -DUSE_ACCEPT4 -DNETFILTER -DUSE_GETSOCKNAME -DUSE_OPENSSL -DUSE_SYSCALL_FUTEX -DUSE_PCRE -I/usr/include -DCONFIG_HAPROXY_VERSION=\1.5.11\ -DCONFIG_HAPROXY_DATE=\2015/01/31\ -c -o src/base64.o src/base64.c local@PGSYNCTEST:/usr/local/src/haproxy-1.5.11$ sudo make install install -d /usr/local/sbin install haproxy /usr/local/sbin install haproxy-systemd-wrapper /usr/local/sbin install -d /usr/local/share/man/man1 install -m 644 doc/haproxy.1 /usr/local/share/man/man1 install -d /usr/local/doc/haproxy for x in configuration architecture haproxy-en haproxy-fr; do \ install -m 644 doc/$x.txt /usr/local/doc/haproxy ; \ done 5)
Re: Attached: May you support me for this issue logs of HAProxy
Dear Sir, I did create /var/lib/haproxy/var/log, and the same issue still remaining, Ha. - Original Message - From: Thrawn shell_layer-git...@yahoo.com.au To: haproxy@formilux.org Sent: Thursday, March 19, 2015 11:59:55 PM Subject: Re: Attached: May you support me for this issue logs of HAProxy Perhaps the trouble is that you're putting HAProxy inside a chroot? Does /var/lib/haproxy/var/log exist?
Re[4]: Checked: send/accept-proxy over unix socket not working
Dear Mr Huuskonen, I would like to return the haproxy.cfg as it was, the error now is local@PGSYNCTEST:~$ sudo -u haproxy /etc/init.d/haproxy restart * Restarting haproxy haproxy [WARNING] 078/171401 (1267) : [/usr/local/sbin/haproxy.main()] Cannot raise FD limit to 90034. [ALERT] 078/171401 (1267) : Starting frontend GLOBAL: error when trying to preserve previous UNIX socket [/var/run/haproxy.sock] [ALERT] 078/171401 (1267) : Starting frontend pgdbplatform_frontend_cluster01: cannot bind socket [0.0.0.0:5432] Other tests local@PGSYNCTEST:~$ sudo service rsyslog status rsyslog start/running Hence rsyslog is running well But local@PGSYNCTEST:~$ sudo netstat -aun | grep 514 (nothing output) local@PGSYNCTEST:~$ sudo netstat -napt | grep 514 (nothing output) local@PGSYNCTEST:~$ logger -d -n 127.0.0.1 −p local0.info Test message I open /var/log/syslog and we see it here Mar 20 17:06:50 PGSYNCTEST logger: −p local0.info Test message I would like to send you the haproxy.cfg as global log 127.0.0.1 local0 log 127.0.0.1 local1 notice maxconn 45000 # Total Max Connections. This is dependent on your limit user haproxy group haproxy daemon chroot /var/lib/haproxy pidfile /var/run/haproxy.pid tune.ssl.default-dh-param 2048 stats socket /var/run/haproxy.sock mode 600 level admin stats timeout 2m defaults log global mode tcp option tcplog #option dontlognull option redispatch retries 3 timeout queue 1m timeout connect 10s timeout client 1m timeout server 1m timeout check 10s maxconn 2000 frontend pgdbplatform_frontend_cluster01 bind *:5432 mode tcp timeout client 168h option tcplog option logasap default_backend pgdbplatform_backend_cluster01 backend pgdbplatform_backend_cluster01 mode tcp option tcplog balance roundrobin # Load Balancing algorithm timeout server 168h server Primary 10.236.49.12:5432 check server HotStandby 172.24.22.68:5432 check server AsyncStandby 10.236.134.187:5432 check --- Please support, Quan Ha Le. - Original Message - From: Jarno Huuskonen jarno.huusko...@uef.fi To: Ha Quan Le nlp...@shaw.ca Cc: haproxy@formilux.org Sent: Friday, March 20, 2015 12:57:46 PM Subject: Re: Checked: send/accept-proxy over unix socket not working Hi, On Fri, Mar 20, Ha Quan Le wrote: global log /var/log local0 log /var/log local1 notice Are you sure that /var/log is a syslog socket ? Usually it's a directory so that's not going to work. http://cbonte.github.io/haproxy-dconv/configuration-1.5.html#4-log frontend pgdbplatform_frontend_cluster01 #bind *:5432 bind /var/lib/haproxy/test accept-proxy user haproxy group haproxy mode tcp timeout client 168h option tcplog option logasap default_backend pgdbplatform_backend_cluster01 backend pgdbplatform_backend_cluster01 mode tcp option tcplog balance roundrobin # Load Balancing algorithm timeout server 168h #server Primary 10.236.49.12:5432 check #server HotStandby 172.24.22.68:5432 check #server AsyncStandby 10.236.134.187:5432 check server clear /var/lib/haproxy/test send-proxy user haproxy group haproxy What are you trying to do ? Now you've tried to create a loop: frontend pgdbplatform_frontend_cluster01 listens on the unix socket and backend pgdbplatform_backend_cluster01 tries to send the traffic back over the same socket -- loop ? In another thread (http://marc.info/?l=haproxym=142681568229626w=2) your problem was that rsyslog didn't create haproxy logfiles ? Is your rsyslog listening for udp/port 514 (netstat -aun | grep 514) ? Does your logger command support -n option to send udp packets ? (man logger) if it does then try to send log messages logger -d -n 127.0.0.1 −p local0.info Test message and see if you can get rsyslog to accept the log messages. -Jarno -- Jarno Huuskonen
Re: Checked: send/accept-proxy over unix socket not working
Hi, On Fri, Mar 20, Ha Quan Le wrote: local@PGSYNCTEST:~$ sudo -u haproxy /etc/init.d/haproxy restart * Restarting haproxy haproxy [WARNING] 078/171401 (1267) : [/usr/local/sbin/haproxy.main()] Cannot raise FD limit to 90034. You're trying to start/restart haproxy as haproxy user (sudo -u). start/restart as root and let haproxy drop privs (user / group in haproxy.cfg). [ALERT] 078/171401 (1267) : Starting frontend GLOBAL: error when trying to preserve previous UNIX socket [/var/run/haproxy.sock] [ALERT] 078/171401 (1267) : Starting frontend pgdbplatform_frontend_cluster01: cannot bind socket [0.0.0.0:5432] Try restarting as root. If it still doesn't work then make sure that there's no haproxy process left from earlier tests. And if it still complains about cannot bind [0.0.0.0:5432] then you have something else already listening to that socket. -Jarno -- Jarno Huuskonen
Re: Checked: send/accept-proxy over unix socket not working
Hi, On Fri, Mar 20, Ha Quan Le wrote: global log /var/log local0 log /var/log local1 notice Are you sure that /var/log is a syslog socket ? Usually it's a directory so that's not going to work. http://cbonte.github.io/haproxy-dconv/configuration-1.5.html#4-log frontend pgdbplatform_frontend_cluster01 #bind *:5432 bind /var/lib/haproxy/test accept-proxy user haproxy group haproxy mode tcp timeout client 168h option tcplog option logasap default_backend pgdbplatform_backend_cluster01 backend pgdbplatform_backend_cluster01 mode tcp option tcplog balance roundrobin # Load Balancing algorithm timeout server 168h #server Primary 10.236.49.12:5432 check #server HotStandby 172.24.22.68:5432 check #server AsyncStandby 10.236.134.187:5432 check server clear /var/lib/haproxy/test send-proxy user haproxy group haproxy What are you trying to do ? Now you've tried to create a loop: frontend pgdbplatform_frontend_cluster01 listens on the unix socket and backend pgdbplatform_backend_cluster01 tries to send the traffic back over the same socket -- loop ? In another thread (http://marc.info/?l=haproxym=142681568229626w=2) your problem was that rsyslog didn't create haproxy logfiles ? Is your rsyslog listening for udp/port 514 (netstat -aun | grep 514) ? Does your logger command support -n option to send udp packets ? (man logger) if it does then try to send log messages logger -d -n 127.0.0.1 −p local0.info Test message and see if you can get rsyslog to accept the log messages. -Jarno -- Jarno Huuskonen
503 on alive backends, hanging processes on reload
I'm running haproxy 1.5.11-1ppa1~trusty from https://launchpad.net/~vbernat/+archive/ubuntu/haproxy-1.5 on Trusty (Ubuntu 14.04). It is a fairly basic configuration that mostly comes straight from the defaults: global log /dev/loglocal0 log /dev/loglocal1 notice chroot /var/lib/haproxy stats socket /run/haproxy/admin.sock mode 660 level admin stats timeout 30s user haproxy group haproxy daemon # Default SSL material locations ca-base /etc/ssl/certs crt-base /etc/ssl/private # Default ciphers to use on SSL-enabled listening sockets. # For more information, see ciphers(1SSL). ssl-default-bind-ciphers kEECDH+aRSA+AES:kRSA+AES:+AES256:RC4-SHA:!kEDH:!LOW:!EXP:!MD5:!aNULL:!eNULL ssl-default-bind-options no-sslv3 defaults log global modehttp option httplog option dontlognull maxconn 1024 timeout queue 5000 timeout connect 5000 timeout client 5 timeout server 5 errorfile 400 /etc/haproxy/errors/400.http errorfile 403 /etc/haproxy/errors/403.http errorfile 408 /etc/haproxy/errors/408.http errorfile 500 /etc/haproxy/errors/500.http errorfile 502 /etc/haproxy/errors/502.http errorfile 503 /etc/haproxy/errors/503.http errorfile 504 /etc/haproxy/errors/504.http frontend ft_poml_vip bind :80 acl host_apibrowse hdr_beg(host) -i apibrowse use_backend be_apibrowse if host_apibrowse backend be_apibrowse server registry 10.88.24.3:49163 I also have several more ACLs and backends that are not shown, but follow the exact same pattern as above (with different host header matching). The main differences from the default are maxconn/timeout queue, both of which I set to try to solve this problem, and my simple frontend/backend. After a time, calls from a web browser to haproxy are sometimes, but not always, being given 503 errors. When I see this happening, if I sit on a very simple page and refresh rapidly, I will sometimes get 503s and sometimes not. I turned off health checks to ensure that failing health checks were not the source of the 503s. What I have noticed is some oddness with the haproxy processes. Here is date and ps -ef output when I am seeing this behavior: Fri Mar 20 21:55:38 GMT 2015 haproxy 19621 1 0 17:35 ?00:00:00 /usr/sbin/haproxy -f /etc/haproxy/haproxy.cfg -p /var/run/haproxy.pid -D -sf 19599 haproxy 20075 1 0 20:50 ?00:00:00 /usr/sbin/haproxy -f /etc/haproxy/haproxy.cfg -p /var/run/haproxy.pid -D -sf 20063 haproxy 20121 1 0 20:50 ?00:00:00 /usr/sbin/haproxy -f /etc/haproxy/haproxy.cfg -p /var/run/haproxy.pid -D -sf 20112 service haproxy reload has been called at various times when the backends have come and gone and the config file has been rewritten, including at 17:35 and 20:50. When haproxy is in this state, service haproxy stop does not stop all processes: # service haproxy stop * Stopping haproxy haproxy [ OK ] # ps -ef | grep haproxy haproxy 19621 1 0 17:35 ?00:00:00 /usr/sbin/haproxy -f /etc/haproxy/haproxy.cfg -p /var/run/haproxy.pid -D -sf 19599 haproxy 20075 1 0 20:50 ?00:00:00 /usr/sbin/haproxy -f /etc/haproxy/haproxy.cfg -p /var/run/haproxy.pid -D -sf 20063 If I then start the service again, those same processes run, but with a new one: # ps -ef | grep haproxy haproxy 19621 1 0 17:35 ?00:00:00 /usr/sbin/haproxy -f /etc/haproxy/haproxy.cfg -p /var/run/haproxy.pid -D -sf 19599 haproxy 20075 1 0 20:50 ?00:00:00 /usr/sbin/haproxy -f /etc/haproxy/haproxy.cfg -p /var/run/haproxy.pid -D -sf 20063 haproxy 20395 1 0 22:04 ?00:00:00 /usr/sbin/haproxy -f /etc/haproxy/haproxy.cfg -D -p /var/run/haproxy.pid When I run service haproxy stop and then manually kill any remaining processes, and then run service haproxy start, I get just the one process: # ps -ef | grep haproxy haproxy 20443 1 0 22:05 ?00:00:00 /usr/sbin/haproxy -f /etc/haproxy/haproxy.cfg -D -p /var/run/haproxy.pid At this point I do *not* get the 503 errors. Everything runs great until the cycle repeats itself. It feels like this is some issue with haproxy reloading. It is possible that reload was called multiple times rapidly when being performed by the automated system, but in my testing if I call it very rapidly from the command line I haven't been able to replicate the issue. Any help would be much appreciated. Thanks! --Jeff
