Quantcast
Channel: Serverphorums.com - HAProxy
Viewing all 11674 articles
Browse latest View live

HUMIDOR,CIGAR ACCESSORIES,JEWELRY BOX,CHESS BOX--s0533176

$
0
0
one of the biggest cigar accessories exporter in china
above 300 items have stock goods,can ship out within 7 days after order confirm
professional and quick service for distributor
do OEM or ODM for big importer
top quality humidor :with 3mm thickness hinge,piano super thick lacquer, solid wood frame
middle quality humidor: service many big importer, above 100000pcs 1 year
Additional product and details, please contact us.



Regards,

DENIS
ALLWAY GROUP LTD
2/F ,Block A5 ,NanYan 3 street 422-472# ,
NanZhou N.RD,HaiZhu District,GuangZhou City,
GuangDong Province,China
TEL:86-20-84042816 FAX:86-20-84041636 MOBILE:13922457369
allwaygroup@188.com

if you not want to receive our promotion letter again, just send remove to the address: remove@allwaygroup.com we will remove your email from our mailing list









119.129.70.128 - Manual Import
33176
...

Notice from Ningbo SSTS: the metal material cost on LME is going up

$
0
0
DearSir, Greetings! WewouldliketoinformyouthattheALL=themetalpriceonLMEwebsiteisgoingupdaybyday.Belowthedatawehasrecordedforyour=reference: Ifyouhaveanynewinquiry,pleas=ekindlysendusimmediatelytogettheupdatedoffer. Hopetoreceiveyoursoonreply. ThanksandBestregards!&nbs=p; Ms. KathyLiu NingboSSTSWeldingMetalCo.,L=td.Add:(NBOffice)Rm502,No.305JiangnanyipinGarden,=JiangnanRoad,Ningbo,P.R.ChinaWeb:www.sstsweld.com=20Skype:sanfang12180Email:sales1@nbssts.com,liukexia@hotmail.com

Re: Slowness on deployment

$
0
0
Greetings,

Having paged through the logs, I see a lot that seem to have the first
four numbers fairly small (indicating that the request to the response
headers finished before times started getting extreme) (Tq, Tw, Tc, Tr),
but which have an overall time (Tt) in the realm of five minutes.

This would indicate that the backend is getting the request from the
client (Tq), gets through the queues (Tw), a TCP connection to the
backend is established (Tc), and it sends the response headers (Tr) in a
few hundred ms to a couple of seconds; but then most of the time is
spent with the client sending the body.

Before we move on, does that sound reasonable as a potential issue
location? If not, I can try running some math on the columns to get a
better idea (I just looked at a random sampling of slow requests to
compare to what I've seen as the baseline).

Another thing which is interesting here are the termination states (I
usually look at them as they give an idea for why connections are
failing; definitions are at
https://cbonte.github.io/haproxy-dconv/configuration-1.5.html#8.5):
7 CHVN
9 SDVN
10 cDVN
12 LR--
33 CDVN
50 SHDN
92 --NI
113 sHVN
186 SHVN
2115 --DI
13896 --VN

The first two chars show the state at termiation, and the second two
talk about the persistence cookie (useful for seeing if first time
clients are failing, etc).

The ones starting with -- indicate they were successful, so ignoring
them here. Other then that we have a bunch starting with SH, indicating
that the TCP connection to the backend ether failed or was aborted, and
sH indicating that the backend connection attempt timed out.
The numbers are fairly small there in terms of failures vs successes, so
I'd say that isn't likely to be the primary issue (unless we get to
talking about individual connections).

If thats the case, the next step would be to figure out why the body
data takes so long; which is outside of what HAProxy can cleanly help
with. Do the backends have logs which would indicate what they are
doing? If not, the next thing I'd try would be making a file with
TCPDump to view in Wireshark to see what is going on between haproxy and
the backends (how to do that is outside the scope of what makes any
sense to describe here, though).

- Chad

On 03/10/2016 08:06 AM, matt wrote:
> I have the log, but a lot of the data is confidential.
> Can I send you by email in order for you to take a look?
>
> We can post a edited version later in order to help others
> debug the same issue
>
> Thanks in advance
>
>

Re: Slowness on deployment

$
0
0
Greetings,

Error in my last e-mail, used used the word client instead of server;
fixed inline.

On 03/10/2016 02:34 PM, Chad Lavoie wrote:
> Greetings,
>
> Having paged through the logs, I see a lot that seem to have the first
> four numbers fairly small (indicating that the request to the response
> headers finished before times started getting extreme) (Tq, Tw, Tc,
> Tr), but which have an overall time (Tt) in the realm of five minutes.
>
> This would indicate that the backend is getting the request from the
> client (Tq), gets through the queues (Tw), a TCP connection to the
> backend is established (Tc), and it sends the response headers (Tr) in
> a few hundred ms to a couple of seconds; but then most of the time is
> spent with the client sending the body.
Most of the time is spent with the server sending the body, not the
client data (as per the timings the server already sent the response
headers, so the client is mostly out of the picture).

- Chad
>
> Before we move on, does that sound reasonable as a potential issue
> location? If not, I can try running some math on the columns to get a
> better idea (I just looked at a random sampling of slow requests to
> compare to what I've seen as the baseline).
>
> Another thing which is interesting here are the termination states (I
> usually look at them as they give an idea for why connections are
> failing; definitions are at
> https://cbonte.github.io/haproxy-dconv/configuration-1.5.html#8.5):
> 7 CHVN
> 9 SDVN
> 10 cDVN
> 12 LR--
> 33 CDVN
> 50 SHDN
> 92 --NI
> 113 sHVN
> 186 SHVN
> 2115 --DI
> 13896 --VN
>
> The first two chars show the state at termiation, and the second two
> talk about the persistence cookie (useful for seeing if first time
> clients are failing, etc).
>
> The ones starting with -- indicate they were successful, so ignoring
> them here. Other then that we have a bunch starting with SH,
> indicating that the TCP connection to the backend ether failed or was
> aborted, and sH indicating that the backend connection attempt timed out.
> The numbers are fairly small there in terms of failures vs successes,
> so I'd say that isn't likely to be the primary issue (unless we get to
> talking about individual connections).
>
> If thats the case, the next step would be to figure out why the body
> data takes so long; which is outside of what HAProxy can cleanly help
> with. Do the backends have logs which would indicate what they are
> doing? If not, the next thing I'd try would be making a file with
> TCPDump to view in Wireshark to see what is going on between haproxy
> and the backends (how to do that is outside the scope of what makes
> any sense to describe here, though).
>
> - Chad
>
> On 03/10/2016 08:06 AM, matt wrote:
>> I have the log, but a lot of the data is confidential.
>> Can I send you by email in order for you to take a look?
>>
>> We can post a edited version later in order to help others
>> debug the same issue
>>
>> Thanks in advance
>>
>>
>
>

[SPAM] Réduisez vos frais postaux avec une machine à affranchir

$
0
0
Untitled Document







Si vous ne visualisez pas correctement ce message, consultez-le en ligne.









Augmentation du prix
du timbre : choisissez la machine à affranchir.











Réduisez vos frais postaux avec une
machine à affranchir
!









































Affranchissez
votre courrier dans vos locaux




















Bénéficiez de tarifs
réduits




















Ne passez plus par les bureaux de Poste,
une boite aux lettres suffit !











*Prix pratiqué par La Poste pour une lettre
prioritaire de 20g



Ce message vous est envoyé par LeadsLeader. D é s a b o
n n e m e n t de la liste

Re: [PATCH] MAJOR: ssl: add 'tcp-fallback' bind option for SSL listeners

$
0
0
Hi,

I've slightly updated my patch to improve it and to fix some
inconsistencies.

First of all, now "ssl-upgrade" and "no-ssl-upgrade" actions can be used
on "tcp-request content" rules _AND_ "tcp-request connection" rules, in
a frontend _OR_ a backend definition.

Then, these actions are now custom actions. I think this is cleaner this
way.

And finally, by default, no SSL upgrade is done when "defer-ssl-upgrade"
option is used. So you need to use explicitly a "ssl-upgrade" rule to
perform it. For a lack of finding the right place to do SSL upgrades
when no "tcp-request" rule is defined, I've decided to change the
default behavior. I've kept the "defer-ssl-upgrade" keyword, but now,
"skip-ssl-upgrade" could be more appropriate. If you prefer, i can do
the change.

--
Christopher

'show table' is unreliable?

$
0
0
Hi,

I'm using haproxy 1.6.3 and think I've uncovered an issue.

I use the stick table feature and as you can see from below, items appear and disappear randomly, these samples were taken less than a second apart. Obviously the items in the middle have at least 56 seconds remaining before expiration, so should have been in all three samples. They reappear if I keep sampling, in seemingly random subsets.

I can't easily tell if this just a display issue (i.e 'show table' has the bug) or whether the table behaves as if it's empty when show table shows it empty.

Any advice?

> echo "show table lookup" | socat /var/haproxy.sock -
# table: lookup, type: string, size:51200, used:0

> echo "show table lookup" | socat /var/haproxy.sock -
# table: lookup, type: string, size:51200, used:3
0x3c1d9ec: key=user1 use=0 exp=56035 gpc0_rate(1000)=0
0x3c0ff0c: key=user2 use=0 exp=58786 gpc0_rate(1000)=0
0x3c41b2c: key=user3 use=0 exp=59737 gpc0_rate(1000)=0

> echo "show table lookup" | socat /var/haproxy.sock -
# table: lookup, type: string, size:51200, used:0

RE: Prospective Clients - Technology Users

$
0
0
Hi,



Would you be Interested to acquire opt in emails list of Technology Users?



We do have the list having Verified emails and precise details of Technology
Users across the Globe.



Few of Technology Users List are: Cisco Users, Juniper Users, Avaya Users,
IBM Users, Autodesk, MS Dynamics, MS SharePoint, BMC software, CA
technology, Citrix Technology, EMC, ESRI, IBM, Infor, JD Edwards, Juniper,
NetApp, Opentext, Oracle, QuickBooks, Sage, Solar Winds Technology, Sugar
CRM Technology, Teradata Technology, VMware, Zebra Technology



Our List consists of: Company Name, Contact Name ( First Name, Middle Name,
Last Name), Contact Job Title, verified email addresses, Company URL,
Physical address, Phone number, Fax Number, Revenue size, Employees Size,
Technology Type, Industry Type, Industry Descriptions and other relevant
information.



If you're interested in any other specific Technology, kindly let me know so
that I can get back to you accordingly.



Target Technology: _______________

Target Geography: _______________



Looking forward to hear from you soon.



Regards,

Sheryl Ross | Online Marketing Manager



Note: You were specifically sent this email based upon your company profile.
If for some reason this was sent in error or you wish not to receive any
further messages from us please reply with subject line as "Exclude" and you
will be excluded from all future mailings.

Car TPMS

$
0
0
Hello ,
 
Good afternoon !
 
Car TPMS ( Tire Pressure Monitor System) with in GOOD MATERIALS and looking for distributors and OEM.
 
Please contact us for more information !
 
Regards !
 
  

Tony
 ---------------------------------------------------------------------------------- 
Broadya Industrial Group Limited
Skype :  tonychan63
----------------------------------------------------------------------------------
Parking Assist System / Car TPMS / Car ADAS / Car Jump Starter / Car DVR 

Re: 'show table' is unreliable?

$
0
0
Greetings,

Do you have nbproc set or more then 1?

If so, then each thread has its own stick table set; and depending on
what thread handles it the values will differ.

Individual frontends can be set to a specific thread with bind-process
(or for SSL a frontend specifically for SSL termination can be made).
If that is the issue your seeing and you want more examples in that
direction let me know what your use-case looks like and I'll go into
more details there.

- Chad

On 03/11/2016 12:28 PM, Robert Samuel Newson wrote:
> Hi,
>
> I'm using haproxy 1.6.3 and think I've uncovered an issue.
>
> I use the stick table feature and as you can see from below, items appear and disappear randomly, these samples were taken less than a second apart. Obviously the items in the middle have at least 56 seconds remaining before expiration, so should have been in all three samples. They reappear if I keep sampling, in seemingly random subsets.
>
> I can't easily tell if this just a display issue (i.e 'show table' has the bug) or whether the table behaves as if it's empty when show table shows it empty.
>
> Any advice?
>
>> echo "show table lookup" | socat /var/haproxy.sock -
> # table: lookup, type: string, size:51200, used:0
>
>> echo "show table lookup" | socat /var/haproxy.sock -
> # table: lookup, type: string, size:51200, used:3
> 0x3c1d9ec: key=user1 use=0 exp=56035 gpc0_rate(1000)=0
> 0x3c0ff0c: key=user2 use=0 exp=58786 gpc0_rate(1000)=0
> 0x3c41b2c: key=user3 use=0 exp=59737 gpc0_rate(1000)=0
>
>> echo "show table lookup" | socat /var/haproxy.sock -
> # table: lookup, type: string, size:51200, used:0
>
>

Re: 'show table' is unreliable?

$
0
0
Greetings,

That should have been "Do you have nbproc set and more then 1?", sorry.

- Chad

On 03/11/2016 01:17 PM, Chad Lavoie wrote:
> Greetings,
>
> Do you have nbproc set or more then 1?
>
> If so, then each thread has its own stick table set; and depending on
> what thread handles it the values will differ.
>
> Individual frontends can be set to a specific thread with bind-process
> (or for SSL a frontend specifically for SSL termination can be made).
> If that is the issue your seeing and you want more examples in that
> direction let me know what your use-case looks like and I'll go into
> more details there.
>
> - Chad
>
> On 03/11/2016 12:28 PM, Robert Samuel Newson wrote:
>> Hi,
>>
>> I'm using haproxy 1.6.3 and think I've uncovered an issue.
>>
>> I use the stick table feature and as you can see from below, items
>> appear and disappear randomly, these samples were taken less than a
>> second apart. Obviously the items in the middle have at least 56
>> seconds remaining before expiration, so should have been in all three
>> samples. They reappear if I keep sampling, in seemingly random subsets.
>>
>> I can't easily tell if this just a display issue (i.e 'show table'
>> has the bug) or whether the table behaves as if it's empty when show
>> table shows it empty.
>>
>> Any advice?
>>
>>> echo "show table lookup" | socat /var/haproxy.sock -
>> # table: lookup, type: string, size:51200, used:0
>>
>>> echo "show table lookup" | socat /var/haproxy.sock -
>> # table: lookup, type: string, size:51200, used:3
>> 0x3c1d9ec: key=user1 use=0 exp=56035 gpc0_rate(1000)=0
>> 0x3c0ff0c: key=user2 use=0 exp=58786 gpc0_rate(1000)=0
>> 0x3c41b2c: key=user3 use=0 exp=59737 gpc0_rate(1000)=0
>>
>>> echo "show table lookup" | socat /var/haproxy.sock -
>> # table: lookup, type: string, size:51200, used:0
>>
>>
>
>

Re: [PATCH] BUG/MEDIUM: cfgparse: wrong argument offset after parsing server "sni" keyword

$
0
0
On Mon, Mar 07, 2016 at 10:13:22PM +0100, Cyril Bonté wrote:
> Owen Marshall reported an issue depending on the server keywords order in the
> configuration.
>
> Working line :
> server dev1 <ip>:<port> check inter 5000 ssl verify none sni req.hdr(Host)
>
> Non working line :
> server dev1 <ip>:<port> check inter 5000 ssl sni req.hdr(Host) verify none
>
> Indeed, both parse_server() and srv_parse_sni() modified the current argument
> offset at the same time. To fix the issue, srv_parse_sni() can work on a local
> copy ot the offset, leaving parse_server() responsible of the actual value.
>
> This fix must be backported to 1.6.

Applied to 1.7, will backport soon.

Thanks Cyril,
Willy

Re: HAProxy no longer working on new ubuntu servers, config has not changes.

$
0
0
Hi Mike,

On Tue, Mar 08, 2016 at 10:57:21AM -0500, Mike Curry wrote:
> HAProxy is suddenly crashing on new Ubuntu (Digital Ocean, AWS - 14.04 and
> 15.10) installs. I???ve had the same configuration working for over a year
> now. I???ve posted all the logs and details below. Is there a new bug, or
> should my configuration be changed to suit the new versions?
>
> I am seeing this fail with 1.5.14, 1.5.15 - however, on older images, I am
> seeing this work with 1.5.14.
>
> http://serverfault.com/questions/762407/haproxy-suddenly-crashing-on-new-ubuntu-images-same-config-works-elsewhere http://serverfault.com/questions/762407/haproxy-suddenly-crashing-on-new-ubuntu-images-same-config-works-elsewhere
>
> Here is my HAProxy config:
>
> global
> daemon
> maxconn 256000
^^^^^^^^^^^^^^
This and this :

> defaults
> maxconn 256000

Imply that you'll need roughly 8.5 GB of RAM for HAProxy alone, plus
about 4 GB of RAM for the TCP stack alone, which gives 12.5 GB of RAM.

Given your kernel trace says this :

> Mar 8 10:42:05 www kernel: [ 263.005501] 262044 pages RAM

I conclude you have 1 GB of RAM in this machine. And as you can see, it's
not haproxy that is crashing but the kernel which kills it as it's the process
eating the most memory when the system runs out of memory. Thus I guess
the reason why it's suddenly crashing is that you used to be very close
to the memory limit and now you're getting more traffic and the machine
is too small to accept all the connections you have configured.

One solution to get back to a non-crashing behavious would be to reduce
the number of connections above to about 16000 to stay under reasonable
limits, but that will mean you'll start to delay some incoming connections,
which is not good.

Another short-term solution consists in reducing haproxy's buffer size,
this will divide its memory usage in almost half. For this, just add this
to the global section :

tune.bufsize 8192
tune.maxrewrite 1024

It will only last the time it takes to your visitors to increase the load.

HAProxy 1.6 supports dynamic buffer allocation, which uses a lot less memory
on idle connections. You can even enforce a hard limit on the memory allocated
by the buffers. It will still not solve the fact that the kernel side also
needs some room for the sockets it's dealing with.

A long-term solution requires to increase the memory in this machine to match
the level of load you expect to handle on this machine. If you *really* want
to support 256k concurrent connections, plan for 16 GB of RAM. If you put that
because you didn't know what to put there, well... at least now you know you
need more than about 20k.

You must absolutely check your stats periodically to ensure the load is always
within expected bounds. You may notice that sometimes the site is attacked and
since your limits are huge, they make the whole system collapse.

Willy

Re: Question about build HAProxy for Solaris 11

$
0
0
Hi Samuel,

On Tue, Mar 01, 2016 at 08:51:09PM -0500, Samuel Crowell wrote:
> I noticed that ya???ll have the binaries for HAProxy 1.4, is there any plan
> to build the executables for newer versions (1.6, etc.)?

No. The main reason is that my Ultra5 is extremely outdated. It still
runs on solaris 8 from 1998 or so and takes around 5 minutes to build
haproxy 1.4. Also we receive no more requests for this OS.

> It???s hard for me to build from source at work due to missing required
> libraries. It would be nice if I still had the option to grab a version
> already compiled for Solaris.

It really depends on what features you need. I used to build 1.4 with the
following command :

make TARGET=solaris CPU=ultrasparc USE_STATIC_PCRE=1

The missing libraries (if any) could easily be found on http://sunfreeware.com/
which you probably know if you're building from sources. The site seems to
still exist.

Overall I've rarely encountered issues to build on Solaris, compilers and
the GNU suite are easy to find and well supported, and the OS provides a
great forward compatibility. The OS is quite modern (it probably was the
most modern of commercial UNIXes), so once you have installed the software
you need, you should have no trouble.

Best regards,
Willy

SNI Support for Health Check on Backend Server

$
0
0
Hey Everybody,


Been struggling trying to get SNI to work with health checks, even using 1.6 and a server configuration of this:


dev05 192.168.1.10:443 check ssl verify none sni str(www.mysite.com)


It will still not send the SNI information to the backend server during health checks.



Am I missing some additional options here? Or is this unsupported in 1.6? Is this slated for 1.7?

Thanks!
William Roush
william.roush@roushtech.net<mailto:william.roush@roushtech.net>

http://www.roushtech.net/

Re: Only using map file when an entry exists

$
0
0
Hello

I've left a little time and no one has said anything more so time for me to
act and submit a patch.

I want to make functions that can be used in acls and take a map and
provide has_key and, for completeness, has_value

Are those names uncontroversia/ suitablel and, i really hope, is this
unnecessary as it already exists.

I'm more that a little sutprised to find myself the first to want this

Cheers

Neil
On 3 Mar 2016 18:08, "Neil - HAProxy List" <maillist-haproxy@iamafreeman.com>
wrote:

> Thanks Conrad,
>
> That sort of thing looks better that what I had, and I'll give it a go.
>
> I still think this is a bit long winded syntax for something that probably
> quite a common things to want to do? A map_contains type boolean function
> still seems like a good to have?
>
> Thanks
>
> Neil
>
> On 3 March 2016 at 13:05, Conrad Hoffmann <conrad@soundcloud.com> wrote:
>
>> If you are using haproxy >=1.6, you might be able to do something like
>> this:
>>
>> acl no_redir %[req.redir] -m str NO_REDIR
>> http-request set-var(req.redir) \
>> %[hdr(host),map(/etc/haproxy/redirect_host.map,NO_REDIR)]
>> http-request redirect location %[req.redir] code 301 if !no_redir
>>
>> This is completely made up and untested, but I hope you get the idea.
>> Avoids a second map lookup altogether, but also map lookups are quite
>> fast,
>> so unless you map is huge you don't really need to worry about this. Also,
>> double negation, but this is just to give you some idea
>>
>> Cheers,
>> Conrad
>> --
>> Conrad Hoffmann
>> Traffic Engineer
>>
>> SoundCloud Ltd. | Rheinsberger Str. 76/77, 10115 Berlin, Germany
>>
>> Managing Director: Alexander Ljung | Incorporated in England & Wales
>> with Company No. 6343600 | Local Branch Office | AG Charlottenburg |
>> HRB 110657B
>>
>
>

Re: 'show table' is unreliable?

$
0
0
ah, yes, nbproc of 2 here, but I should be clear. The stick tables are in a proxy pinned to one single process, the other is used to handle TLS decoding.

> On 11 Mar 2016, at 18:27, Chad Lavoie <clavoie@haproxy.com> wrote:
>
> Greetings,
>
> That should have been "Do you have nbproc set and more then 1?", sorry.
>
> - Chad
>
> On 03/11/2016 01:17 PM, Chad Lavoie wrote:
>> Greetings,
>>
>> Do you have nbproc set or more then 1?
>>
>> If so, then each thread has its own stick table set; and depending on what thread handles it the values will differ.
>>
>> Individual frontends can be set to a specific thread with bind-process (or for SSL a frontend specifically for SSL termination can be made). If that is the issue your seeing and you want more examples in that direction let me know what your use-case looks like and I'll go into more details there.
>>
>> - Chad
>>
>> On 03/11/2016 12:28 PM, Robert Samuel Newson wrote:
>>> Hi,
>>>
>>> I'm using haproxy 1.6.3 and think I've uncovered an issue.
>>>
>>> I use the stick table feature and as you can see from below, items appear and disappear randomly, these samples were taken less than a second apart. Obviously the items in the middle have at least 56 seconds remaining before expiration, so should have been in all three samples. They reappear if I keep sampling, in seemingly random subsets.
>>>
>>> I can't easily tell if this just a display issue (i.e 'show table' has the bug) or whether the table behaves as if it's empty when show table shows it empty.
>>>
>>> Any advice?
>>>
>>>> echo "show table lookup" | socat /var/haproxy.sock -
>>> # table: lookup, type: string, size:51200, used:0
>>>
>>>> echo "show table lookup" | socat /var/haproxy.sock -
>>> # table: lookup, type: string, size:51200, used:3
>>> 0x3c1d9ec: key=user1 use=0 exp=56035 gpc0_rate(1000)=0
>>> 0x3c0ff0c: key=user2 use=0 exp=58786 gpc0_rate(1000)=0
>>> 0x3c41b2c: key=user3 use=0 exp=59737 gpc0_rate(1000)=0
>>>
>>>> echo "show table lookup" | socat /var/haproxy.sock -
>>> # table: lookup, type: string, size:51200, used:0
>>>
>>>
>>
>>
>

Re: Only using map file when an entry exists

$
0
0
I'm amazed by the number of typos in one message. ;)
On 3 Mar 2016 18:08, "Neil - HAProxy List" <maillist-haproxy@iamafreeman.com>
wrote:

> Thanks Conrad,
>
> That sort of thing looks better that what I had, and I'll give it a go.
>
> I still think this is a bit long winded syntax for something that probably
> quite a common things to want to do? A map_contains type boolean function
> still seems like a good to have?
>
> Thanks
>
> Neil
>
> On 3 March 2016 at 13:05, Conrad Hoffmann <conrad@soundcloud.com> wrote:
>
>> If you are using haproxy >=1.6, you might be able to do something like
>> this:
>>
>> acl no_redir %[req.redir] -m str NO_REDIR
>> http-request set-var(req.redir) \
>> %[hdr(host),map(/etc/haproxy/redirect_host.map,NO_REDIR)]
>> http-request redirect location %[req.redir] code 301 if !no_redir
>>
>> This is completely made up and untested, but I hope you get the idea.
>> Avoids a second map lookup altogether, but also map lookups are quite
>> fast,
>> so unless you map is huge you don't really need to worry about this. Also,
>> double negation, but this is just to give you some idea
>>
>> Cheers,
>> Conrad
>> --
>> Conrad Hoffmann
>> Traffic Engineer
>>
>> SoundCloud Ltd. | Rheinsberger Str. 76/77, 10115 Berlin, Germany
>>
>> Managing Director: Alexander Ljung | Incorporated in England & Wales
>> with Company No. 6343600 | Local Branch Office | AG Charlottenburg |
>> HRB 110657B
>>
>
>

Re: Only using map file when an entry exists

$
0
0
Hello

I've left a little time and no one has said anything more so time for me to
act and submit a patch.

I want to make functions that can be used in acls and take a map and
provide has_key and, for completeness, has_value

Are those names uncontroversial/ suitable and, i really hope, is this
unnecessary as it already exists.

I'm more that a little surprised to find myself the first to want this

Cheers

Neil
On 11 Mar 2016 22:16, "Neil" <neil@iamafreeman.com> wrote:

> Hello
>
> I've left a little time and no one has said anything more so time for me
> to act and submit a patch.
>
> I want to make functions that can be used in acls and take a map and
> provide has_key and, for completeness, has_value
>
> Are those names uncontroversia/ suitablel and, i really hope, is this
> unnecessary as it already exists.
>
> I'm more that a little sutprised to find myself the first to want this
>
> Cheers
>
> Neil
> On 3 Mar 2016 18:08, "Neil - HAProxy List" <
> maillist-haproxy@iamafreeman.com> wrote:
>
>> Thanks Conrad,
>>
>> That sort of thing looks better that what I had, and I'll give it a go.
>>
>> I still think this is a bit long winded syntax for something that
>> probably quite a common things to want to do? A map_contains type boolean
>> function still seems like a good to have?
>>
>> Thanks
>>
>> Neil
>>
>> On 3 March 2016 at 13:05, Conrad Hoffmann <conrad@soundcloud.com> wrote:
>>
>>> If you are using haproxy >=1.6, you might be able to do something like
>>> this:
>>>
>>> acl no_redir %[req.redir] -m str NO_REDIR
>>> http-request set-var(req.redir) \
>>> %[hdr(host),map(/etc/haproxy/redirect_host.map,NO_REDIR)]
>>> http-request redirect location %[req.redir] code 301 if !no_redir
>>>
>>> This is completely made up and untested, but I hope you get the idea.
>>> Avoids a second map lookup altogether, but also map lookups are quite
>>> fast,
>>> so unless you map is huge you don't really need to worry about this.
>>> Also,
>>> double negation, but this is just to give you some idea
>>>
>>> Cheers,
>>> Conrad
>>> --
>>> Conrad Hoffmann
>>> Traffic Engineer
>>>
>>> SoundCloud Ltd. | Rheinsberger Str. 76/77, 10115 Berlin, Germany
>>>
>>> Managing Director: Alexander Ljung | Incorporated in England & Wales
>>> with Company No. 6343600 | Local Branch Office | AG Charlottenburg |
>>> HRB 110657B
>>>
>>
>>

Re: SNI Support for Health Check on Backend Server

$
0
0
There is a recently reported but for this. Try putting "verify none" AFTER
the "sni" keyword in your server line.

-Bryan


On Fri, Mar 11, 2016 at 2:08 PM, William D. Roush <
william.roush@roushtech.net> wrote:

> Hey Everybody,
>
>
> Been struggling trying to get SNI to work with health checks, even using
> 1.6 and a server configuration of this:
>
>
> dev05 192.168.1.10:443 check ssl verify none sni str(www.mysite.com)
>
>
> It will still not send the SNI information to the backend server during
> health checks.
>
>
>
> Am I missing some additional options here? Or is this unsupported in 1.6?
> Is this slated for 1.7?
>
>
> Thanks!
>
> William Roush
>
> william.roush@roushtech.net
>
>
>
> *http://www.roushtech.net/ http://www.roushtech.net/*
>
Viewing all 11674 articles
Browse latest View live