Hi, The configuration is for HAProxy 1.5-something :)
cheers On Tue, Nov 8, 2011 at 3:00 AM, Mir Islam <mis...@mirislam.com> wrote: > Thanks Vincent for the link. That is exactly what I was looking for. However > the configuration they provided does not work out of the box. My knowledge in > HAProxy is less than two days old. So if you or anyone else can tell me what > the following errors mean, I will appreciate it a lot. > > First one is simple, for some reason binary type is not valid for > stick-table? All I could see in web site in reference to "ip" but not binary > or other types. I have compiled haproxy 1.4.18 from source on linux. > > ./haproxy -f ./haproxy-zdm-ssl2.cfg > [ALERT] 311/015412 (23710) : parsing [./haproxy-zdm-ssl2.cfg:8] : > stick-table: unknown type 'binary'. > [ALERT] 311/015412 (23710) : parsing [./haproxy-zdm-ssl2.cfg:10] : error > detected while parsing ACL 'clienthello'. > [ALERT] 311/015412 (23710) : parsing [./haproxy-zdm-ssl2.cfg:11] : error > detected while parsing ACL 'serverhello'. > [WARNING] 311/015412 (23710) : parsing [./haproxy-zdm-ssl2.cfg:14] : > tcp-request inspect-delay will be ignored because backend 'https' has no > frontend capability > [ALERT] 311/015412 (23710) : parsing [./haproxy-zdm-ssl2.cfg:15] : error > detected in backend 'https' while parsing 'if' condition > [ALERT] 311/015412 (23710) : parsing [./haproxy-zdm-ssl2.cfg:18] : unknown > keyword 'tcp-response' in 'backend' section > [ALERT] 311/015412 (23710) : parsing [./haproxy-zdm-ssl2.cfg:24] : 'stick': > unknown fetch method 'payload_lv(43,1)'. > [ALERT] 311/015412 (23710) : parsing [./haproxy-zdm-ssl2.cfg:27] : 'stick': > unknown fetch method 'payload_lv(43,1)'. > [ALERT] 311/015412 (23710) : Error(s) found in configuration file : > ./haproxy-zdm-ssl2.cfg > [WARNING] 311/015412 (23710) : config : missing timeouts for backend 'https'. > | While not properly invalid, you will certainly encounter various problems > | with such a configuration. To fix this, please ensure that all following > | timeouts are set to a non-zero value: 'client', 'connect', 'server'. > [ALERT] 311/015412 (23710) : Fatal errors found in configuration. > > > My configuration > > backend https > mode tcp > balance roundrobin > srvtimeout 50000 > > # maximum SSL session ID length is 32 bytes. > stick-table type binary len 32 size 30k expire 30m > > acl clienthello req_ssl_hello_type 1 > acl serverhello rep_ssl_hello_type 2 > > # use tcp content accepts to detects ssl client and server hello. > tcp-request inspect-delay 5s > tcp-request content accept if clienthello > > # no timeout on response inspect delay by default. > tcp-response content accept if serverhello > > # SSL session ID (SSLID) may be present on a client or server hello. > # Its length is coded on 1 byte at offset 43 and its value starts > # at offset 44. > # Match and learn on request if client hello. > stick on payload_lv(43,1) if clienthello > > # Learn on response if server hello. > stick store-response payload_lv(43,1) if serverhello > > server s1 192.168.1.1:443 > server s2 192.168.1.2:443 > > > > > On Nov 7, 2011, at 12:00 PM, Vincent Bernat wrote: > >> OoO Pendant le journal télévisé du lundi 07 novembre 2011, vers 20:16, >> Mir Islam <mis...@mirislam.com> disait : >> >>> Yea that is the problem. Right now SSL is terminated at the >>> application level on each server. There is no way to inspect the >>> cookie even if the server sets one. Sticky session in TCP mode can be >>> done by source IP (that is why I have balance source). But that >>> creates the other problem as I mentioned. Folks coming from behind >>> NAT will hit the same server and not get load balanced. Because >>> HAProxy will think they are all the same. I was trying to find out if >>> there is something else that could be done. From my own logical >>> reasoning, no. :) but I have been wrong before so I was hoping >>> someone had similar issue. >> >> See this post: >> http://blog.exceliance.fr/2011/07/04/maintain-affinity-based-on-ssl-session-id/ >> >> While this won't work, in theory, if client is requesting to use >> tickets, almost all clients keep the right session ID even when using >> tickets. You should of course ensure that a client will keep the same >> session ID all the time. This means that you need to ensure that your >> web server is able to resume session with and without tickets correctly. >> For example, with nginx, you need to configure a session cache. >> -- >> Vincent Bernat ☯ http://vincent.bernat.im >> >> Keep it right when you make it faster. >> - The Elements of Programming Style (Kernighan & Plauger) > > >
