Re: Bug or misconfig on path_reg?
so it appears that OR is implicit and foo was matched as 3 acl :-)
Thank's meineerde for the help
Le 04/01/2018 à 11:45, Arnaud B. a écrit :
> Hi there,
>
> Recently, a misrouting has been found on our haproxy config. We had two
> ACL mismatching :
>
> acl foo path_reg -i
> ^/(w|a|i)\/([0-9]+\.){0,3}([0-9]+)?\/(ats|atc)\/.*$ OR path_reg -i
> ^//(w|a|i)\/([0-9]+\.){0,3}([0-9]+)?\/(ats|atc)\/.*$
>
> and
>
> acl bar path_reg
> ^/(w|a|i)\/(.*)\/barbaz\/(.*)\/(install|custom)\/(.*)
>
>
> So, if the called url is
> https://foo.bar/i/1.9.0/barbaz/path/custom/foo
>
> acl bar is matched and this is "normal", now, if I hit
> https://foo.bar/i/1.9.0/barbaz/path/custom/-i
>
> it matches bar, even if the latter part of the regex is not matching. We
> tried with https://foo.bar/i/1.9.0/barbaz/path/custom/-a and a set of
> different chars, this anomaly is only raised when hitting /-i
>
> our config has been fixed by removing the -i flag on the foo acl, but it
> doesn't explain this "bug".
>
>
Bug or misconfig on path_reg?
Hi there,
Recently, a misrouting has been found on our haproxy config. We had two
ACL mismatching :
acl foo path_reg -i
^/(w|a|i)\/([0-9]+\.){0,3}([0-9]+)?\/(ats|atc)\/.*$ OR path_reg -i
^//(w|a|i)\/([0-9]+\.){0,3}([0-9]+)?\/(ats|atc)\/.*$
and
acl bar path_reg
^/(w|a|i)\/(.*)\/barbaz\/(.*)\/(install|custom)\/(.*)
So, if the called url is
https://foo.bar/i/1.9.0/barbaz/path/custom/foo
acl bar is matched and this is "normal", now, if I hit
https://foo.bar/i/1.9.0/barbaz/path/custom/-i
it matches bar, even if the latter part of the regex is not matching. We
tried with https://foo.bar/i/1.9.0/barbaz/path/custom/-a and a set of
different chars, this anomaly is only raised when hitting /-i
our config has been fixed by removing the -i flag on the foo acl, but it
doesn't explain this "bug".
Re: PIDs are not dying on a reload
2 production days, using Vincent's haproxy.debian.net build (1.7.8-1~bpo9+1), I'm not having the issue on 4 out of 5 load balancers. There is still one though. I'll see if it evolves over time. Le 01/08/2017 à 12:14, Vincent Bernat a écrit : > ❦ 1 août 2017 12:00 +0200, "Arnaud B." <arn...@arnaudb.net> : > >> I'm not using peers, it's a feature that I've discovered as you >> mentionned it, seems worth the try. >> >> I'll upgrade to the latest bpo package from Vincent's repository and see >> if it fixes my issue, I'll get back to you if it succeeds or not. > You can use the "official" backport from Debian repositories. You just > have to know it could be updated to 1.8 at some point (while the > packages served directly by haproxy.debian.net won't).
Re: PIDs are not dying on a reload
I'm not using peers, it's a feature that I've discovered as you mentionned it, seems worth the try. I'll upgrade to the latest bpo package from Vincent's repository and see if it fixes my issue, I'll get back to you if it succeeds or not. Thank's Will. Le 01/08/2017 à 11:32, Willy Tarreau a écrit : > On Tue, Aug 01, 2017 at 10:49:20AM +0200, Arnaud B. wrote: >> thank's Vincent. >> >> Unfortunately, I already am on the latest upstream (not backport though) : >> >> $ apt-get update -qq; apt-cache madison haproxy; dpkg -l|grep -i haproxy >>haproxy | 1.7.8-1~bpo9+1 | http://debian.mirrors.ovh.net/debian >> stretch-backports/main amd64 Packages >>haproxy | 1.7.8-1~bpo9+1 | http://ftp.fr.debian.org/debian >> stretch-backports/main amd64 Packages >>haproxy |1.7.5-2 | http://debian.mirrors.ovh.net/debian >> stretch/main amd64 Packages >>haproxy | 1.7.8-1~bpo9+1 | http://debian.mirrors.ovh.net/debian >> stretch-backports/main Sources >>haproxy |1.7.5-2 | http://debian.mirrors.ovh.net/debian >> stretch/main Sources >> ii haproxy 1.7.5-2 >> amd64fast and reliable load balancing reverse proxy >> ii vim-haproxy 1.7.5-2 >> all syntax highlighting for HAProxy configuration files >> >> This stale process issue is quite a mystery atm. > Well, I don't know if you're using peers, but a peers bug causing stale > processes to stay up during reloads was fixed between 1.7.5 and 1.7.8. > It's very likely the same one you're experiencing. And by the way, don't > bother with the UDP socket, it's just the logs. > > As a rule of thumb, you should always use Vincent's latest backports > related to the stable branch you're working on. The packages in your > distro will not contain all fixes, only the ones considered the most > critical, but Vincent takes a great care of maintaining up-to date > versions which are more suitable for production. You can check here > for the available versions : https://haproxy.debian.net/ > > Thus in your case, switching to the 1.7.8 backport seems to make sense. > > Cheers, > Willy
Re: PIDs are not dying on a reload
I changed my haproxy.cfg to use only the haproxy user instead of
www-data, but it haven't fixed my undying pid issue, I have the exact
same stale processes, with a UDP UNCON socket open, no trafic and the
epoll_wait() on strace.
Le 28/07/2017 à 14:07, Arnaud B. a écrit :
> I'll change my haproxy.cfg to haproxy user and see if it changes
> anything regarding the undying pids
>
>
> Le 28/07/2017 à 13:36, Vincent Bernat a écrit :
>> ❦ 28 juillet 2017 12:09 +0200, "Arnaud B." <arn...@arnaudb.net> :
>>
>>> I'm having an issue on debian 9's stable version of HAProxy :
>>>
>>> https://dooby.fr/y/j9qgknb
>>>
>>> I have to regularly reload haproxy to fetch new configurations, and it
>>> now always result on a set of undying pids.
>>>
>>> If I strace pid 2677 on this screenshot :
>>> $ strace -p 2677
>>> strace: Process 2677 attached
>>> epoll_wait(0, [], 200, 18) = 0
>>> epoll_wait(0, [], 200, 0) = 0
>>> epoll_wait(0, [], 200, 12) = 0
>>> epoll_wait(0, [], 200, 0) = 0
>>> epoll_wait(0, [], 200, 14) = 0
>>> epoll_wait(0, [], 200, 0) = 0
>>> epoll_wait(0, [], 200, 13) = 0
>>> epoll_wait(0, [], 200, 0) = 0
>>> epoll_wait(0, [], 200, 121) = 0
>>> epoll_wait(0, [], 200, 0) = 0
>>> epoll_wait(0, [], 200, 6) = 0
>>> epoll_wait(0, [], 200, 0) = 0
>>> epoll_wait(0, [], 200, 22) = 0
>>>
>>> if I check what's going on on the network level for this pid :
>>> $ ss -lntpuae |grep -i 'pid=2677'
>>> udpUNCONN 0 0 *:28382
>>> *:*
>>> users:(("haproxy",pid=2677,fd=14),("haproxy",pid=2611,fd=14))
>>> ino:1822334707 sk:aa61 -->
>> For information, haproxy -vv is:
>>
>> HA-Proxy version 1.7.5-2 2017/05/17
>> Copyright 2000-2017 Willy Tarreau <wi...@haproxy.org>
>>
>> Build options :
>> TARGET = linux2628
>> CPU = generic
>> CC = gcc
>> CFLAGS = -g -O2 -fdebug-prefix-map=/build/haproxy-2dHYaz/haproxy-1.7.5=.
>> -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time
>> -D_FORTIFY_SOURCE=2
>> OPTIONS = USE_GETADDRINFO=1 USE_ZLIB=1 USE_REGPARM=1 USE_OPENSSL=1
>> USE_LUA=1 USE_PCRE=1 USE_NS=1
>>
>> Default settings :
>> maxconn = 2000, bufsize = 16384, maxrewrite = 1024, maxpollevents = 200
>>
>> Encrypted password support via crypt(3): yes
>> Built with zlib version : 1.2.8
>> Running on zlib version : 1.2.8
>> Compression algorithms supported : identity("identity"), deflate("deflate"),
>> raw-deflate("deflate"), gzip("gzip")
>> Built with OpenSSL version : OpenSSL 1.1.0e 16 Feb 2017
>> Running on OpenSSL version : OpenSSL 1.1.0f 25 May 2017
>> OpenSSL library supports TLS extensions : yes
>> OpenSSL library supports SNI : yes
>> OpenSSL library supports prefer-server-ciphers : yes
>> Built with PCRE version : 8.39 2016-06-14
>> Running on PCRE version : 8.39 2016-06-14
>> PCRE library supports JIT : no (USE_PCRE_JIT not set)
>> Built with Lua version : Lua 5.3.3
>> Built with transparent proxy support using: IP_TRANSPARENT IPV6_TRANSPARENT
>> IP_FREEBIND
>> Built with network namespace support
>>
>> Available polling systems :
>> epoll : pref=300, test result OK
>>poll : pref=200, test result OK
>> select : pref=150, test result OK
>> Total: 3 (3 usable), will use epoll.
>>
>> Available filters :
>> [COMP] compression
>> [TRACE] trace
>> [SPOE] spoe
>>
>> On your screenshot, the user is www-data while on lsof, this is
>> haproxy. Handover between HAProxy instances is done through signal,
>> maybe you reloaded the configuration with a change of user. The new
>> HAProxy cannot signal the old one to shutdown in this case. However,
>> this wouldn't explain why lsof and htop don't agree.
>
signature.asc
Description: OpenPGP digital signature
Re: PIDs are not dying on a reload
I'll change my haproxy.cfg to haproxy user and see if it changes
anything regarding the undying pids
Le 28/07/2017 à 13:36, Vincent Bernat a écrit :
> ❦ 28 juillet 2017 12:09 +0200, "Arnaud B." <arn...@arnaudb.net> :
>
>> I'm having an issue on debian 9's stable version of HAProxy :
>>
>> https://dooby.fr/y/j9qgknb
>>
>> I have to regularly reload haproxy to fetch new configurations, and it
>> now always result on a set of undying pids.
>>
>> If I strace pid 2677 on this screenshot :
>> $ strace -p 2677
>> strace: Process 2677 attached
>> epoll_wait(0, [], 200, 18) = 0
>> epoll_wait(0, [], 200, 0) = 0
>> epoll_wait(0, [], 200, 12) = 0
>> epoll_wait(0, [], 200, 0) = 0
>> epoll_wait(0, [], 200, 14) = 0
>> epoll_wait(0, [], 200, 0) = 0
>> epoll_wait(0, [], 200, 13) = 0
>> epoll_wait(0, [], 200, 0) = 0
>> epoll_wait(0, [], 200, 121) = 0
>> epoll_wait(0, [], 200, 0) = 0
>> epoll_wait(0, [], 200, 6) = 0
>> epoll_wait(0, [], 200, 0) = 0
>> epoll_wait(0, [], 200, 22) = 0
>>
>> if I check what's going on on the network level for this pid :
>> $ ss -lntpuae |grep -i 'pid=2677'
>> udpUNCONN 0 0 *:28382
>> *:*
>> users:(("haproxy",pid=2677,fd=14),("haproxy",pid=2611,fd=14))
>> ino:1822334707 sk:aa61 -->
> For information, haproxy -vv is:
>
> HA-Proxy version 1.7.5-2 2017/05/17
> Copyright 2000-2017 Willy Tarreau <wi...@haproxy.org>
>
> Build options :
> TARGET = linux2628
> CPU = generic
> CC = gcc
> CFLAGS = -g -O2 -fdebug-prefix-map=/build/haproxy-2dHYaz/haproxy-1.7.5=.
> -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time
> -D_FORTIFY_SOURCE=2
> OPTIONS = USE_GETADDRINFO=1 USE_ZLIB=1 USE_REGPARM=1 USE_OPENSSL=1
> USE_LUA=1 USE_PCRE=1 USE_NS=1
>
> Default settings :
> maxconn = 2000, bufsize = 16384, maxrewrite = 1024, maxpollevents = 200
>
> Encrypted password support via crypt(3): yes
> Built with zlib version : 1.2.8
> Running on zlib version : 1.2.8
> Compression algorithms supported : identity("identity"), deflate("deflate"),
> raw-deflate("deflate"), gzip("gzip")
> Built with OpenSSL version : OpenSSL 1.1.0e 16 Feb 2017
> Running on OpenSSL version : OpenSSL 1.1.0f 25 May 2017
> OpenSSL library supports TLS extensions : yes
> OpenSSL library supports SNI : yes
> OpenSSL library supports prefer-server-ciphers : yes
> Built with PCRE version : 8.39 2016-06-14
> Running on PCRE version : 8.39 2016-06-14
> PCRE library supports JIT : no (USE_PCRE_JIT not set)
> Built with Lua version : Lua 5.3.3
> Built with transparent proxy support using: IP_TRANSPARENT IPV6_TRANSPARENT
> IP_FREEBIND
> Built with network namespace support
>
> Available polling systems :
> epoll : pref=300, test result OK
>poll : pref=200, test result OK
> select : pref=150, test result OK
> Total: 3 (3 usable), will use epoll.
>
> Available filters :
> [COMP] compression
> [TRACE] trace
> [SPOE] spoe
>
> On your screenshot, the user is www-data while on lsof, this is
> haproxy. Handover between HAProxy instances is done through signal,
> maybe you reloaded the configuration with a change of user. The new
> HAProxy cannot signal the old one to shutdown in this case. However,
> this wouldn't explain why lsof and htop don't agree.
PIDs are not dying on a reload
Hey there,
I'm having an issue on debian 9's stable version of HAProxy :
https://dooby.fr/y/j9qgknb
I have to regularly reload haproxy to fetch new configurations, and it
now always result on a set of undying pids.
If I strace pid 2677 on this screenshot :
$ strace -p 2677
strace: Process 2677 attached
epoll_wait(0, [], 200, 18) = 0
epoll_wait(0, [], 200, 0) = 0
epoll_wait(0, [], 200, 12) = 0
epoll_wait(0, [], 200, 0) = 0
epoll_wait(0, [], 200, 14) = 0
epoll_wait(0, [], 200, 0) = 0
epoll_wait(0, [], 200, 13) = 0
epoll_wait(0, [], 200, 0) = 0
epoll_wait(0, [], 200, 121) = 0
epoll_wait(0, [], 200, 0) = 0
epoll_wait(0, [], 200, 6) = 0
epoll_wait(0, [], 200, 0) = 0
epoll_wait(0, [], 200, 22) = 0
if I check what's going on on the network level for this pid :
$ ss -lntpuae |grep -i 'pid=2677'
udpUNCONN 0 0 *:28382
*:*
users:(("haproxy",pid=2677,fd=14),("haproxy",pid=2611,fd=14))
ino:1822334707 sk:aa61 -->
and I have nothing going on on that socket :
$ timeout 60 tcpdump -i any -w udp.out -X 'udp port 28382'
tcpdump: listening on any, link-type LINUX_SLL (Linux cooked), capture
size 262144 bytes
Got 0
My systemd.service file has only been edited to enlarge my fd :
[Unit]
Description=HAProxy Load Balancer
Documentation=man:haproxy(1)
Documentation=file:/usr/share/doc/haproxy/configuration.txt.gz
After=network.target syslog.service
Wants=syslog.service
[Service]
Environment="CONFIG=/etc/haproxy/haproxy.cfg" "PIDFILE=/run/haproxy.pid"
EnvironmentFile=-/etc/default/haproxy
ExecStartPre=/usr/sbin/haproxy -f $CONFIG -c -q $EXTRAOPTS
ExecStart=/usr/sbin/haproxy-systemd-wrapper -f $CONFIG -p $PIDFILE
$EXTRAOPTS
ExecReload=/usr/sbin/haproxy -f $CONFIG -c -q $EXTRAOPTS
ExecReload=/bin/kill -USR2 $MAINPID
KillMode=mixed
Restart=always
LimitNOFILE=1048576
[Install]
WantedBy=multi-user.target
So I'm wondering what's going wrong on a reload. The only solution that
I've found so far is to kick out my load balancer from the pool, stop
haproxy properly and start it again.
Re: GeoIP Best Practices
After a quicksearch in Haproxy's doc I've found a way to do what you suggested : http-request set-header X-City-Map %[src,map_ip(/etc/haproxy/geocity_map.lst)] http-request set-header X-Country-Map %[src,map_ip(/etc/haproxy/geocountry_map.lst)] http-request set-header X-City-Name %[hdr(X-City-Map),word(1,' ')] http-request set-header X-Geoname-City-Id %[hdr(X-City-Map),word(2,' ')] http-request set-header X-Latitude %[hdr(X-City-Map),word(3,' ')] http-request set-header X-Longitude %[hdr(X-City-Map),word(4,' ')] http-request set-header X-Accuracy-Radius %[hdr(X-City-Map),word(5,' ')] http-request set-header X-Country-Code %[hdr(X-Country-Map),word(1,' ')] http-request set-header X-Country-Code2 %[hdr(X-Country-Map),word(1,' ')] http-request set-header X-Country-Id %[hdr(X-Country-Map),word(2,' ')] http-request del-header X-City-Map http-request del-header X-Country-Map My city mapfile is around 800Mib and HAproxy uses 2 times less RAM and CPU after this modification, this setup is now extensible at will. Thank's Willy for the head's up, I hope it'll be useful to somebody else :-) 04/05/2017 à 07:30, Willy Tarreau a écrit : > Hi Arnaud, > > On Wed, May 03, 2017 at 01:54:13PM +0200, Arnaud B. wrote: >> Hi there, >> >> I'm currently wondering, based on >> https://www.haproxy.com/blog/use-geoip-database-within-haproxy/ and >> related notes, is there a more convenient way now ? I've created >> mapfiles for latitude, longitude, accuracy radius, country code, cities >> names etc. >> >> Right now, my process is based on Maxmind's databases scraping and >> generating mapfiles for each added header. >> >> Now my HAProxy is around 10GB ram and takes about 70secs to reload. > Why does it take that long ? That seems totally abnormal. Do you use > your maps at many places, possibly causing them from being loaded > multiple times maybe ? In theory even with this they should be merged. > > Now regarding the size, do you think your maps could be aggregated > so that you have all fields at once on a line ? If so you could set > a variable based on a single lookup of the source address in the > map, then use the "word" converter to split it depending on the > field you're interested in. The risk is to end up with an even larger > map but I think that most entries can be merged. > > Willy > >
Re: GeoIP Best Practices
Hi Willy, Thank's for the quick reply and helpful answers. I have a multiproc HAProxy, so my first guess is that each proc has to have the mapfiles in memory. Each mapfile has a CIDR IP block as key, and I can merge them based on this indeed. I'll try to use the word converter to apply the right headers based on a merged file and will get back to the mailinglist to let you know how it went. Le 04/05/2017 à 07:30, Willy Tarreau a écrit : > Hi Arnaud, > > On Wed, May 03, 2017 at 01:54:13PM +0200, Arnaud B. wrote: >> Hi there, >> >> I'm currently wondering, based on >> https://www.haproxy.com/blog/use-geoip-database-within-haproxy/ and >> related notes, is there a more convenient way now ? I've created >> mapfiles for latitude, longitude, accuracy radius, country code, cities >> names etc. >> >> Right now, my process is based on Maxmind's databases scraping and >> generating mapfiles for each added header. >> >> Now my HAProxy is around 10GB ram and takes about 70secs to reload. > Why does it take that long ? That seems totally abnormal. Do you use > your maps at many places, possibly causing them from being loaded > multiple times maybe ? In theory even with this they should be merged. > > Now regarding the size, do you think your maps could be aggregated > so that you have all fields at once on a line ? If so you could set > a variable based on a single lookup of the source address in the > map, then use the "word" converter to split it depending on the > field you're interested in. The risk is to end up with an even larger > map but I think that most entries can be merged. > > Willy >
GeoIP Best Practices
Hi there, I'm currently wondering, based on https://www.haproxy.com/blog/use-geoip-database-within-haproxy/ and related notes, is there a more convenient way now ? I've created mapfiles for latitude, longitude, accuracy radius, country code, cities names etc. Right now, my process is based on Maxmind's databases scraping and generating mapfiles for each added header. Now my HAProxy is around 10GB ram and takes about 70secs to reload. $ du -hs *.lst 184Macc.lst 224Mcitiesids.lst 228Mcities.lst 7,2Mcountriesids.lst 5,8Mcountries.lst 225Mlat.lst 230Mlong.lst
There is kind of a spam issue on this ML no?
On the last 2 or 3 days : https://lut.im/jsIGNMzLDL/OuRdpkM9ZpVTIH47 signature.asc Description: OpenPGP digital signature
Re: "Odd" behaviour on resolvers
So there is no way to use a resolver that is not used by the system on haproxy's start ? Le 04/03/2016 17:32, Robin Geuze a écrit : > > During configcheck the resolver portion of haproxy is not yet active. > Thus during the check it uses the system resolver. Once actually > running it will use the resolver from haproxy. > > On Mar 4, 2016 16:26, "Arnaud B." <arn...@arnaudb.net> wrote: > > Hi there, > > First of all : I am very fond of HAProxy :-) > > I was trying to do some service discovery with bind9 and HAProxy > when I found an odd behaviour on the /resolvers/ part. > > Here are some config samples : > My frontend and backend and resolvers config: > > /resolvers discovery// > // nameserver jabba 172.16.0.2:53// > // resolve_retries 5// > // timeout retry 1s// > // hold valid 3s/ > > /frontend staging_frontend// > //mode http// > //bind 127.0.0.1:8013// > //default_backend staging_backend// > // > // > //backend staging_backend// > //server jabba php-staging.vra:8013 check resolvers discovery/ > > > a sample dig : > > /$ dig @172.16.0.2 php-staging.vra +short// > //172.16.0.2/ > > > So far, everything seems fine to me. But, when i reload haproxy's > config : > > /mars 04 15:55:13 jabba haproxy[25262]: [ALERT] 063/155513 > (25262) : parsing [/etc/haproxy/haproxy.cfg:98] : 'server > jabba' : invalid address: 'php-staging.vra' in ...// > //mars 04 15:55:13 jabba haproxy[25262]: [ALERT] 063/155513 > (25262) : Error(s) found in configuration file : > /etc/haproxy/haproxy.cfg// > //mars 04 15:55:13 jabba haproxy[25262]: [ALERT] 063/155513 > (25262) : Fatal errors found in configuration./ > > I first questioned my configuration and checked everything out ... > There was no obvious issue. > > I checked my //etc/resolv.conf/ file and saw that my server wasn't > using the same resolver. Its resolver did not had any knowledge > whatsoever of /php-staging.vra/ and it caused my configuration to > fail on reload. > My //etc/resolv.conf /was : > > /nameserver 8.8.8.8// > //nameserver 213.186.33.99// > /// > > and became > > /nameserver 172.16.0.2// > //search vra// > //nameserver 8.8.8.8// > //nameserver 213.186.33.99/ > > > permitting haproxy's reload. > > My question is pretty simple : since there is a resolvers section > in haproxy's configuration, is it possible to use it despite the > server's resolv.conf? > > Let me know if something's unclear in my explanation :) >
"Odd" behaviour on resolvers
Hi there, First of all : I am very fond of HAProxy :-) I was trying to do some service discovery with bind9 and HAProxy when I found an odd behaviour on the /resolvers/ part. Here are some config samples : My frontend and backend and resolvers config: /resolvers discovery// // nameserver jabba 172.16.0.2:53// // resolve_retries 5// // timeout retry 1s// // hold valid 3s/ /frontend staging_frontend// //mode http// //bind 127.0.0.1:8013// //default_backend staging_backend// // // //backend staging_backend// //server jabba php-staging.vra:8013 check resolvers discovery/ a sample dig : /$ dig @172.16.0.2 php-staging.vra +short// //172.16.0.2/ So far, everything seems fine to me. But, when i reload haproxy's config : /mars 04 15:55:13 jabba haproxy[25262]: [ALERT] 063/155513 (25262) : parsing [/etc/haproxy/haproxy.cfg:98] : 'server jabba' : invalid address: 'php-staging.vra' in ...// //mars 04 15:55:13 jabba haproxy[25262]: [ALERT] 063/155513 (25262) : Error(s) found in configuration file : /etc/haproxy/haproxy.cfg// //mars 04 15:55:13 jabba haproxy[25262]: [ALERT] 063/155513 (25262) : Fatal errors found in configuration./ I first questioned my configuration and checked everything out ... There was no obvious issue. I checked my //etc/resolv.conf/ file and saw that my server wasn't using the same resolver. Its resolver did not had any knowledge whatsoever of /php-staging.vra/ and it caused my configuration to fail on reload. My //etc/resolv.conf /was : /nameserver 8.8.8.8// //nameserver 213.186.33.99// /// and became /nameserver 172.16.0.2// //search vra// //nameserver 8.8.8.8// //nameserver 213.186.33.99/ permitting haproxy's reload. My question is pretty simple : since there is a resolvers section in haproxy's configuration, is it possible to use it despite the server's resolv.conf? Let me know if something's unclear in my explanation :) signature.asc Description: OpenPGP digital signature
