Re: DOC: usesrc root privileges
On Fri, Jul 17, 2015 at 10:02:55PM +0200, Baptiste wrote: > Hi, > > The documentation is missing the usesrc requirements about root privileges. > This patch add this information in the doc. applied, thank you Baptiste. Willy
Re: Server IP resolution using DNS in HAProxy
> First would be resolution of SRV records and actually using the port > supplied by the SRV record as the port for the server. I looked at the code > and it doesn't seem like too much work, most of it would probably be > changing the config stuff accordingly. You're right, this could be an interesting option. Actually, we though about the SRV records to populate a full backend server list with IP, name, port, weight using a single DNS query. > The other one is... well you asked for it ;) so here it goes: it would be > great to express in the config something like "resolve this name and use up > to X servers from the reply". The backend then allocates X servers. > Assuming that the initial lookup returns Y results, the (sorted) records > get assinged to the first Y servers, the other X-Y servers get marked as > down. Upon a new lookup, same procedure for a potentially changing value of Y. > I realize this a pretty bold feature request for several reasons, but I > have actually spent some thought on it think it might be doable without > really violating any of HAProxy's design paradigms. I would also be willing > to invest some time (code) into this myself. > If you think this might be at least worth a discussion, I'd be happy to > share some more detailed thoughts and it would be great to hear your > thoughts on that, too. First, there are some limitations about creating servers on the fly in a backend. So instead, we propose you to pre-allocate servers by configuration and then wait for the DNS to populate it. I don't speak about a request per server, I speak here about one request for the whole farm :) You go one step further than the design we have about SRV records to populate the backend. We thought using priority to decide whether a server is active or backup. The advantage is that you don't need to reload HAProxy to change your X value ;) I would welcome a contribution about SRV record type. That said, before this, I have to rewrite part of the response parser to store the response in a real DNS packet structure instead of keeping data in a buffer. Baptiste
Re: Server IP resolution using DNS in HAProxy
> Actually a local resolver can take care of that for you as well since every > resolver I know allows configuring a different destination on domain basis. > Also as described in the first email, the server has to be resolvable via > the OS resolving stack as well otherwise haproxy won't start. That's the purpose of this thread. We want / need to get rid of this limitation and that's why we ask our community if the way we wanted to fix it makes sense. > This means you > cannot use custom domains without configuring some sort of custom resolver > anyway. HAProxy's internal resolver can be made flexible enough for this purpose without being intrusive in the underlying operating system. Baptiste > > -Robin- > > Nenad Merdanovic wrote on 7/15/2015 08:56: >> >> Hello Robin, >> >> On 07/15/2015 08:49 AM, Robin Geuze wrote: >>> >>> Tbh I don't really see the point of configuring the resolvers in haproxy >>> when the OS has perfectly fine working facilities for this? What is the >>> benefit besides possibly causing lookups to happen twice, once from the >>> OS resolving stack and once from haproxies? If you really want exactly >>> the same behavior as described you could always configure a local >>> resolver that queries multiple other resolvers instead of recursing >>> itself. >> >> Because this would perfectly integrate with things like Consul >> (https://www.consul.io/docs/agent/dns.html), which are currently very >> widely used to provide service discovery. >> >>> -Robin- >>> >> Regards, > > >
Re: Server IP resolution using DNS in HAProxy
Hi Robin, > I don't understand the necessity of the hold valid config option. DNS has > something that takes care of this for you called the TTL. Besides if hold > valid is shorter then the TTL it would be kind of pointless since the > resolvers you are querying won't re-resolve until the TTL expires. Your server won't wait until end of TTL to fail ;) So you don't want to followup TTLs and prefer force HAProxy to resolve more often. In some cases, you don't choose the TTL (amazon), so 'hold valid' allows you to choose your own TTL. > Tbh I don't really see the point of configuring the resolvers in haproxy > when the OS has perfectly fine working facilities for this? Imagine a big company. Imagine the ops team managing HAProxy and the IT team managing the DNS servers. (It's a real case) When the ops team start up a new server, DNS propagation can be long (several minutes) before the DNS servers managed by the IT team are aware of the update (we speak about worldwide deployment). In order to start up the new service asap, then the ops team want to use the regular DNS servers and their own DNS server... There are many cases like this one, where the ops team doesn't have the hand over the DNS server. Same if you use a service discovery, then HAProxy can point its DNS request to it instead of regular DNS servers. > What is the > benefit besides possibly causing lookups to happen twice, once from the OS > resolving stack and once from haproxies? If you really want exactly the same > behavior as described you could always configure a local resolver that > queries multiple other resolvers instead of recursing itself. you say this because you have the hand over your OS. We have many customers and community users where it's not the case. Once again, HAProxy, is a load-balancer, it needs the most accurate information and as fast as possible. You don't want to tune your local bind or powerdns just for HAProxy and prevent any other service to operate as usual. Baptiste
Re: Server IP resolution using DNS in HAProxy
On Wed, Jul 15, 2015 at 8:28 AM, Marco Corte wrote: > Il 14/07/2015 22:11, Baptiste ha scritto: >> >> - when parsing the configuration, HAProxy uses libc functions and >>> >>> resolvers provided by the operating system => if the server can't be >>> resolved at this step, then HAProxy can't start > > [...] >> First, we want to fix the error when HAProxy fails starting up because >> the resolvers pointed by the system can't resolve a server's IP >> address (but HAProxy resolvers could). >> The idea here would to create a new flag on the server to tell HAProxy >> which IP to use. The server would be enabled when the IP has been >> provided by the expected tool. > > Hi Marco, > Why not providing an option to start haproxy even if not all servers can be > resolved? That's the purpose of my mail. I need this feature, but I want to make it in a way which would satisfy the community. > Your proposal of the "init-addr" could be useful for a trick: I can set a > surely unreacheable address to let haproxy start and then force/wait for the > name resolution to have a working server. That's what we want. The hidden feature, is that you can start large farms and simply turn on DNS when spawning new application servers. Scale up without reloading HAProxy ;) > A "NX" server state would be very nice. noted, thx Baptiste
Re: cookie prefix strange behavior
Hi Roberto,
Look in your log lines, block 2, HAProxy says "--IN". 'IN' is for
cookie persistence.
'I' means the cookie sent by the client is invalid and 'N' means
HAProxy did not perform any action on persistence.
In such case, you could try to match that there are no prefix in your
cookie and do a redirect to a page which cleans up the cookie then
redirect the user to the login page.
Baptiste
On Fri, Jul 17, 2015 at 5:49 PM, mlist wrote:
> We found this behavior does not appears if we manually clean cookie in the
> browser. There is a configuration option to invalidate old cookie so client
> does not reuse this strange cookie not recognized by server ?
>
>
>
>
>
> Roberto
>
>
>
>
>
>
>
> From: mlist
> Sent: venerdì 17 luglio 2015 16.19
> To: 'haproxy@formilux.org'
> Subject: cookie prefix strange behavior
>
>
>
> We have compiled and installed haproxy version 1.6 dev2.
>
>
>
> If we use cookie insert all works, but if we use cookie prefix
> (ASP.NET_SessionId) or sticky table in which one have to specify cookie to
> be sticked, so using cookie name = ASP.NET_SessionId) we have a strange
> behavior.
>
>
>
> BLOCK1
>
> As you can see below, we open a browser and make a request, cookie prefix
> mechanism works well, we can login and use the application (all subsequent
> requests go on the some server).
>
>
>
> BLOCK2
>
> But if we open a new browser instance (chrome in this case, but this happen
> also if we open IE) the client uses a strange “ASP.NET_SessionId” cookie
> without haproxy prefix with back-end server, server does not ask client to
> set a new cookie.
>
> As of login, clearly, backend server does not recognize the cookie sent by
> client (haproxy do a plain roundrobin distribution, no cookie management was
> done) and so backend server return an error.
>
> Can this be a bug of haproxy or a bad configuration by us ?
>
>
>
>
>
>
>
> BLOCK1
>
> Jul 17 14:55:49 ha_server1 haproxy[5604]: client_ip:37322
> [17/Jul/2015:14:55:49.414] front_end_https~ back_end_https/SERVER1
> 2/0/44/18/64 302 467 ASP.NET_SessionId=SERVER1~fi2b5smpq33tgwfy0qqmog45 -
> --VN 0/0/0/0/0 0/0 {||Mozilla/5.0 (Windows NT 6.2; WOW64) AppleWebKit/537.36
> (KHTML, l} "GET /app1/ HTTP/1.1"
>
> Jul 17 14:55:49 ha_server1 haproxy[5604]: client_ip:37324
> [17/Jul/2015:14:55:49.484] front_end_https~ back_end_https/SERVER1
> 2/0/5/22/29 200 6449 ASP.NET_SessionId=SERVER1~fi2b5smpq33tgwfy0qqmog45 -
> --VN 0/0/0/0/0 0/0 {||Mozilla/5.0 (Windows NT 6.2; WOW64) AppleWebKit/537.36
> (KHTML, l} "GET /app1/login.aspx HTTP/1.1"
>
> Jul 17 14:55:52 ha_server1 haproxy[5604]: client_ip:37328
> [17/Jul/2015:14:55:52.284] front_end_https~ back_end_https/SERVER1 2/0/1/3/7
> 404 1424 ASP.NET_SessionId=SERVER1~fi2b5smpq33tgwfy0qqmog45 - --VN 0/0/0/0/0
> 0/0 {||Mozilla/5.0 (Windows NT 6.2; WOW64) AppleWebKit/537.36 (KHTML, l}
> "GET /app1/segreteria HTTP/1.1"
>
> Jul 17 14:55:59 ha_server1 haproxy[5604]: client_ip:37344
> [17/Jul/2015:14:55:59.452] front_end_https~ back_end_https/SERVER1 2/0/1/2/5
> 301 448 ASP.NET_SessionId=SERVER1~fi2b5smpq33tgwfy0qqmog45 - --VN 0/0/0/0/0
> 0/0 {||Mozilla/5.0 (Windows NT 6.2; WOW64) AppleWebKit/537.36 (KHTML, l}
> "GET /app1/anagrafenet HTTP/1.1"
>
> Jul 17 14:55:59 ha_server1 haproxy[5604]: client_ip:37345
> [17/Jul/2015:14:55:59.461] front_end_https~ back_end_https/SERVER1
> 2/0/1/32/36 302 435 ASP.NET_SessionId=SERVER1~fi2b5smpq33tgwfy0qqmog45 -
> --VN 0/0/0/0/0 0/0 {||Mozilla/5.0 (Windows NT 6.2; WOW64) AppleWebKit/537.36
> (KHTML, l} "GET /app1/anagrafenet/ HTTP/1.1"
>
> Jul 17 14:55:59 ha_server1 haproxy[5604]: client_ip:37346
> [17/Jul/2015:14:55:59.501] front_end_https~ back_end_https/SERVER1
> 2/0/1/27/31 200 6625 ASP.NET_SessionId=SERVER1~fi2b5smpq33tgwfy0qqmog45 -
> --VN 0/0/0/0/0 0/0 {||Mozilla/5.0 (Windows NT 6.2; WOW64) AppleWebKit/537.36
> (KHTML, l} "GET /app1/login.aspx HTTP/1.1"
>
> Jul 17 14:56:06 ha_server1 haproxy[5604]: client_ip:37359
> [17/Jul/2015:14:56:06.515] front_end_https~ back_end_https/SERVER1
> 1/0/4/64/69 302 6712 ASP.NET_SessionId=SERVER1~fi2b5smpq33tgwfy0qqmog45 -
> --VN 0/0/0/0/0 0/0 {|946|Mozilla/5.0 (Windows NT 6.2; WOW64)
> AppleWebKit/537.36 (KHTML, l} "POST /app1/login.aspx HTTP/1.1"
>
> Jul 17 14:56:06 ha_server1 haproxy[5604]: client_ip:37361
> [17/Jul/2015:14:56:06.588] front_end_https~ back_end_https/SERVER1
> 2/0/1/175/179 200 28897 ASP.NET_SessionId=SERVER1~fi2b5smpq33tgwfy0qqmog45 -
> --VN 0/0/0/0/0 0/0 {||Mozilla/5.0 (Windows NT 6.2; WOW64) AppleWebKit/537.36
> (KHTML, l} "GET /app1/anagrafenet/default.aspx HTTP/1.1"
>
> Jul 17 14:56:06 ha_server1 haproxy[5604]: client_ip:37364
> [17/Jul/2015:14:56:06.777] front_end_https~ back_end_https/SERVER1
> 5/0/2/11/18 200 2049 ASP.NET_SessionId=SERVER1~fi2b5smpq33tgwfy0qqmog45 -
> --VN 5/5/5/5/0 0/0 {||Mozilla/5.0 (Windows NT 6.2; WOW64) AppleWebKit/537.36
> (KHTML, l} "GET /app1/templatelibrary/menutop/sf-menu.css HTTP/1.1"
>
> Jul 17 14:56:06 ha_server1 haproxy[5604]: client_ip:37363
> [17/Jul/2015:14:56:06.776] front_end
Re: How to disable backend servers without health check
On Thu, Jul 16, 2015 at 5:06 PM, Pavlos Parissis wrote: > > > On 16/07/2015 04:02 μμ, Krishna Kumar (Engineering) wrote: >> Hi John, >> >> Your suggestion works very well, and exactly what I was looking for. >> Thank you very much. >> > > > You could also try https://github.com/unixsurfer/haproxytool > > Cheers, > Pavlos > +1 to Pavlos' tool for this type of task Baptiste
DOC: usesrc root privileges
Hi, The documentation is missing the usesrc requirements about root privileges. This patch add this information in the doc. Baptiste From 8537d9b6c136a270c79670ebccf972a11fa86af7 Mon Sep 17 00:00:00 2001 From: Baptiste Assmann Date: Fri, 17 Jul 2015 21:59:42 +0200 Subject: [PATCH] DOC usesrc root privileges requirments The "usesrc" parameter of the source statement requires root privileges. --- doc/configuration.txt | 2 ++ 1 file changed, 2 insertions(+) diff --git a/doc/configuration.txt b/doc/configuration.txt index a806312..7c90ff4 100644 --- a/doc/configuration.txt +++ b/doc/configuration.txt @@ -6896,6 +6896,8 @@ source [:] [interface ] is possible at the server level using the "source" server option. Refer to section 5 for more information. + In order to work, "usesrc" requires root privileges. + Examples : backend private # Connect to the servers using our 192.168.1.200 source address -- 2.4.5
Re: IP binding and standby health-checks
Hi Nathan, The 'usesrc' keyword triggers this error. It needs root privileges. (just checked in the source code) Baptiste On Thu, Jul 16, 2015 at 5:13 PM, Nathan Williams wrote: > oh, i think this comment thread explains it: > http://comments.gmane.org/gmane.comp.web.haproxy/20366. I'll see about > assigning > > CAP_NET_ADMIN > > > On Wed, Jul 15, 2015 at 4:56 PM Nathan Williams > wrote: >> >> Hi Baptiste, >> >> Sorry for the delayed response, had some urgent things come up that >> required more immediate attention... thanks again for your continued >> support. >> >> >> > Why not using proxy-protocol between HAProxy and nginx? >> >> Sounds interesting; I'd definitely heard of it before, but hadn't looked >> into it since what we've been doing has been working. My initial impression >> is that it's a pretty big change from what we're currently doing (looks like >> it would at least require a brief maintenance to roll out since it requires >> coordinated change between client and load-balancer), but I'm not >> fundamentally opposed if there's significant advantages. I'll definitely >> take a look to see if it satisfies our requirements. >> >> >> > I disagree, it would be only 2: the 'real' IP addresses of the >> load-balancers only. >> >> OK, fair point. Maybe it's just being paranoid to think that unless we're >> explicitly setting the source, we should account for *all* possible sources. >> The VIP wouldn't be the default route, so we could probably get away with >> ignoring it. Come to think of it... maybe having keepalived change the >> default route on the primary and skipping hardcoding the source in haproxy >> would address what we're aiming for? seems worth further investigation, as >> I'm not sure whether it supports this out of the box. >> >> >> > there is no 0.0.0.0 magic values neither subnet values accepted in nginx >> > XFF module? >> >> I wouldn't use 0.0.0.0 whether there is or not, as i wouldn't want it to >> be that open. It might be a different case for a subnet value, if we were >> able to put the load-balancer cluster in a separate subnet, but our current >> situation (managed private openstack deployment) doesn't give us quite that >> much network control. maybe someday soon with VXLAN or another overlay (of >> course, that comes with performance penalties, so maybe not). >> >> >> > Then instead of using a VIP, you can book 2 IPs in your subnet that >> > could be used, whatever the LB is using. >> >> Pre-allocating network IPs from the subnet that aren't permitted to be >> assigned to anything other than whatever instance is currently filling the >> load-balancer role would certainly work (I like this idea!); that's actually >> pretty similar to what we're doing for the internal VIP currently (the >> external VIP is just an openstack floating IP, aka a DNAT in the underlying >> infrastructure), and then adding it as an allowed address for the >> instance-associated network "port" instance in Neutron's >> allowed-address-pairs... It'd be an extra step when creating an LB node, but >> a pretty reasonable one I think, and we're already treating them differently >> from "generic" instances anyways... definitely food for thought. >> >> > HAProxy rocks ! >> >> +1 * 100. :) >> >> >> > Can you start it up with strace ?? >> >> Yep! https://gist.github.com/nathwill/ea52324867072183b695 >> >> So far, I still like the "source 0.0.0.0 usesrc 10.240.36.13" solution the >> best, as it seems the most direct and easily understood. Fingers crossed the >> permissions issue is easily overcome. >> >> Cheers, >> >> Nathan W >> >> On Tue, Jul 14, 2015 at 2:58 PM Baptiste wrote: >>> >>> > As for details, it's advantageous for us for a couple of reasons... the >>> > realip module in nginx requires that you list "trusted" hosts which are >>> > permitted to set the X-Forwarded-For header before it will set the >>> > "source" >>> > address in the logs to the x-forwarded-for address. as a result, using >>> > anything other than the VIP means: >>> >>> Why not using proxy-protocol between HAProxy and nginx? >>> http://blog.haproxy.com/haproxy/proxy-protocol/ >>> >>> So you can get rid of X-FF header limitation in nginx. (don't know if >>> proxy-protocol implementation in nginx suffers from the same >>> limitations). >>> >>> > - not using the vip means we have to trust 3 addresses instead of 1 to >>> > set >>> > x-forwarded-for >>> >>> I disagree, it would be only 2: the 'real' IP addresses of the >>> load-balancers only. >>> >>> > - we have to update the list of allowed hosts on all of our backends >>> > any >>> > time we replace a load-balancer node. We're using config management, so >>> > it's >>> > automated, but that's still more changes than should ideally be >>> > necessary to >>> > replace a no-data node that we ideally can trash and replace at will. >>> >>> there is no 0.0.0.0 magic values neither subnet values accepted in >>> nginx XFF module? >>> If not, it deserves a patch ! >>> >>> > - there's a
RE: ocsp
Hi Marc, > Hi all, > > I have some problem making ocsp stapling working. here is what i did : > > I have 8150.pem with chain, cert and key in it. > > I have 8150.pem.ocsp that seems ok : > > # openssl ocsp -respin 8150.pem.ocsp -text -CAfile alphassl256.chain > OCSP Response Data: > OCSP Response Status: successful (0x0) > Response Type: Basic OCSP Response > Version: 1 (0x0) > Responder Id: 9F10D9EDA5260B71A677124526751E17DC85A62F > Produced At: Jul 9 09:47:04 2015 GMT > Responses: > Certificate ID: > Hash Algorithm: sha1 > Issuer Name Hash: 84D56BF8098BD307B766D8E1EBAD6596AA6B6761 > Issuer Key Hash: F5CDD53C0850F96A4F3AB797DA5683E669D268F7 > Serial Number: 11216784E7CA1813F3AD922B60EAF6428EE0 > Cert Status: good > This Update: Jul 9 09:47:04 2015 GMT > Next Update: Jul 9 21:47:04 2015 GMT > > No error/warn at haproxy launching but not sure haproxy is loading .ocsp file > because no notice in log. > > But nothing in tlsextdebug : > > echo Q | openssl s_client -connect www.beluc.fr:443 -servername www.beluc.fr > -tlsextdebug -status -CApath /etc/ssl/certs > [...] > OCSP response: no response sent > [...] > > Do you see smth wrong ? What can i do in order to debug? Can you provide the output of "haproxy -vv" please and a config snippet (the frontend ssl configuration)? Do you see a warning if 8150.pem.ocsp contains garbage when you restart haproxy? Regards, Lukas
Re: Rewrite cookie path & cookie domain
> I've problem to rewrite cookie path and cookie domain in HAproxy; I've a
> Nginx configuration but I want to move from Nginx to HAProxy for this proxy
> pass.
Just for my curiosity, why removing nginx ???
> This is a Nginx config I want to replace:
>
> location /~xxx/ {
> proxy_cookie_domain ~.* .$site.it;
> proxy_cookie_path ~.* /~xxx/;
> proxy_set_headerHost $site.it;
> proxy_pass http://192.168.1.2/;
> }
>
> I need same function of proxy_cookie_domain and proxy_cookie_path; I found
> this:
> http://blog.haproxy.com/2014/04/28/howto-write-apache-proxypass-rules-in-haproxy/
> but not work form me.
>
> Now I can change cookie path with:
> rspirep ^(Set-Cookie:.*)\ path=(.*) \1\ path=/~xxx/
It would be easier if you share a Set-Cookie header sent by your
application server.
In the mean time, you may use (add a 'if' statement if required):
http-response replace-value Set-Cookie (.*)\ path=.* \1\ path=/~xxx/
Note: now, prefer the http-response rule over the rspirep.
> I need add also domain, only if exists, but with dynamic hostname; I;ve
> tried with
>
> acl hdr_set_cookie_domain_and_path res.hdr(Set-cookie) -m sub domain=
> res.hdr(Set-cookie) -m sub path=
> rspirep ^(Set-Cookie:.*)\ path=(.*) \1\ path=/~xxx/;\ domain=%[hdr(Host)]
> if hdr_set_cookie_domain_and_path
This does not work like this.
You can use a request header in the response.
In 1.6, you'll be able to use variables.
In 1.5, you can use the capture during the request, then use the value
at response time.
capture request header Host len 32 # first capture statement has
capture.req.hdr id 0
acl hdr_set_cookie_domain res.hdr(Set-cookie) -m sub domain=
acl hdr_set_cookie_path res.hdr(Set-cookie) -m sub path=
http-response replace-value Set-Cookie (.*) \1;\
domain=%[capture.req.hdr(0)] # put your if statements as you want /
need
You can create as many http-response rules as you need to update first
the domain, then the path.
Baptiste
>
>
> Anyone can help me?
>
> Tnx,
> rr
>
> 2015-07-14 21:34 GMT+02:00 Baptiste :
>>
>> Please repost your question. I can't see it in my mail history.
>>
>> Baptiste
>>
>> On Tue, Jul 14, 2015 at 3:33 PM, rickytato rickytato
>> wrote:
>> > Anyone can help me? I keep using Nginx?
>> >
>> > 2015-07-07 10:46 GMT+02:00 rickytato rickytato
>> > :
>> >>
>> >> 1.5.12
>> >>
>> >> 2015-07-06 17:58 GMT+02:00 Aleksandar Lazic :
>> >>>
>> >>> Dear rickytato rickytato.
>> >>>
>> >>> Am 06-07-2015 15:32, schrieb rickytato rickytato:
>> >>>
>> Hi all,
>> I've problem to rewrite cookie path and cookie domain in HAproxy;
>> I've a
>> Nginx configuration but I want to move from Nginx to HAProxy for this
>> proxy
>> pass.
>> >>>
>> >>>
>> >>> Which Version of haproxy do you use?
>> >>>
>> >>> haproxy -vv ?
>> >>>
>> >>> Cheers Aleks
>> >>
>> >>
>> >
>
>
Re: Load Balancing the Load Balancer
On Wed, Jul 15, 2015 at 1:14 PM, mlist wrote: >>> Hi, >>> we see there is a new feature of HAProxy, peer and share table >>> (sticky-table). This peer feature can be used to have in synch stick cookie >>> so if one haproxy goes down the other can take over connections ? > > >> Yes, the stick table remember and share each which is sticked to which >> server. You can use any criteria of the connexion, and of course you >> can use a cookie set by your application. > >> In othe way, HAProxy can put his own cookie in the HTTP response and >> use it for the persistance. This mode is useful because you don't need >> to share the stick table and two "unconnected" haproxy can assure the >> high avalaibility without loosing the session affinity. > > > So if we'll use share stick table between 2 HAProxy LB we'll do not need > cookie to maintain backend server sessions and if we'll use cookie we do not > need to share stick table ? in the latter case how the surviving HAProxy know > where to route the request to the correct backend server using some > haproxy.cfg with some beckend server definition ? It does not work like this :) Persistence is based on your client and server capabilities as well as the type of protocol. IE, if you want persistence over POP protocol, then use source IP and a stick table. If you want persistence for a web mail application where clients are browsers and they can use a cookie, then use a cookie set by HAProxy. If you want persistence over a PHP or Java application, without inserting a new cookie, then store cookies generated by the application servers in a stick table you share between your HAProxy... etc... > >>> What is your choice ? > > >> The choice depends of each problem. HAProxy is very rich and permits to >> solve many LB and HA issues. Generally I prefer the simplest solution >> able to solve my issues. > > I mean your choice to take in sync haproxy.cfg file between 2 or more haproxy > LB (rsync, custom script, etc.) rsync or scp... I mean, it's not only a cfg file, but also your SSL certificates, your ACLs, MAPs, etc... Baptiste
Re: ocsp
Hi Marc-Antoine, no idea, sorry. Maybe some of our SSL experts may help :) Baptiste On Wed, Jul 15, 2015 at 11:06 AM, Marc-Antoine wrote: > Hi, > > nobody knows plz ? > > On Thu, 9 Jul 2015 13:06:59 +0200, > Marc-Antoine wrote : > >> Hi all, >> >> I have some problem making ocsp stapling working. here is what i did : >> >> I have 8150.pem with chain, cert and key in it. >> >> I have 8150.pem.ocsp that seems ok : >> >> # openssl ocsp -respin 8150.pem.ocsp -text -CAfile alphassl256.chain >> OCSP Response Data: >> OCSP Response Status: successful (0x0) >> Response Type: Basic OCSP Response >> Version: 1 (0x0) >> Responder Id: 9F10D9EDA5260B71A677124526751E17DC85A62F >> Produced At: Jul 9 09:47:04 2015 GMT >> Responses: >> Certificate ID: >> Hash Algorithm: sha1 >> Issuer Name Hash: 84D56BF8098BD307B766D8E1EBAD6596AA6B6761 >> Issuer Key Hash: F5CDD53C0850F96A4F3AB797DA5683E669D268F7 >> Serial Number: 11216784E7CA1813F3AD922B60EAF6428EE0 >> Cert Status: good >> This Update: Jul 9 09:47:04 2015 GMT >> Next Update: Jul 9 21:47:04 2015 GMT >> >> No error/warn at haproxy launching but not sure haproxy is loading .ocsp >> file because no notice in log. >> >> But nothing in tlsextdebug : >> >> echo Q | openssl s_client -connect www.beluc.fr:443 -servername www.beluc.fr >> -tlsextdebug -status -CApath /etc/ssl/certs >> [...] >> OCSP response: no response sent >> [...] >> >> Do you see smth wrong ? What can i do in order to debug ? >> >> Regards, >> > > > -- > Marc-Antoine >
Re: FW: SSL offloading in HAProxy
Hi, SSL offloading in front of IMAPs (port 993) is supported. If you try to do STARTTLS over IMAP, it is not supported. Baptiste On Wed, Jul 15, 2015 at 10:38 AM, Cohen Galit wrote: > Hello HAProxy team, > > > > I see that the SSL offloading for http protocol is already supported ( > http://blog.haproxy.com/2012/09/10/how-to-get-ssl-with-haproxy-getting-rid-of-stunnel-stud-nginx-or-pound/ > ) > > I would like to know if there is an option of SSL offloading for IMAP > protocol. > > > > Thanks, > > Galit > > > > From: Avrahami David > Sent: Wednesday, July 01, 2015 3:50 PM > To: Cohen Galit > Cc: Sabban Gili; Meltser Tiran > Subject: SSL offloading in HAProxy > > > > Hi Galit, > > > > Can you please post the below question to HAProxy forum? > > > > I see that the SSL offloading for http protocol is already supported ( > http://blog.haproxy.com/2012/09/10/how-to-get-ssl-with-haproxy-getting-rid-of-stunnel-stud-nginx-or-pound/ > ) > > I would like to know if there is an option of SSL offloading for IMAP > protocol. > > > > > > Best Regards, > > David Avrahami > > Security SE > > Tel: +972-3-6452374 > > Mobile: +972-544382374 > > Email: david.avrah...@comverse.com > > > > > “This e-mail message may contain confidential, commercial or privileged > information that constitutes proprietary information of Comverse Inc. or its > subsidiaries. If you are not the intended recipient of this message, you are > hereby notified that any review, use or distribution of this information is > absolutely prohibited and we request that you delete all copies and contact > us by e-mailing to: secur...@comverse.com. Thank You.”
RE: cookie prefix strange behavior
We found this behavior does not appears if we manually clean cookie in the
browser. There is a configuration option to invalidate old cookie so client
does not reuse this strange cookie not recognized by server ?
Roberto
From: mlist
Sent: venerdì 17 luglio 2015 16.19
To: 'haproxy@formilux.org'
Subject: cookie prefix strange behavior
We have compiled and installed haproxy version 1.6 dev2.
If we use cookie insert all works, but if we use cookie prefix
(ASP.NET_SessionId) or sticky table in which one have to specify cookie to be
sticked, so using cookie name = ASP.NET_SessionId) we have a strange behavior.
BLOCK1
As you can see below, we open a browser and make a request, cookie prefix
mechanism works well, we can login and use the application (all subsequent
requests go on the some server).
BLOCK2
But if we open a new browser instance (chrome in this case, but this happen
also if we open IE) the client uses a strange "ASP.NET_SessionId" cookie
without haproxy prefix with back-end server, server does not ask client to set
a new cookie.
As of login, clearly, backend server does not recognize the cookie sent by
client (haproxy do a plain roundrobin distribution, no cookie management was
done) and so backend server return an error.
Can this be a bug of haproxy or a bad configuration by us ?
BLOCK1
Jul 17 14:55:49 ha_server1 haproxy[5604]: client_ip:37322
[17/Jul/2015:14:55:49.414] front_end_https~ back_end_https/SERVER1 2/0/44/18/64
302 467 ASP.NET_SessionId=SERVER1~fi2b5smpq33tgwfy0qqmog45 - --VN 0/0/0/0/0 0/0
{||Mozilla/5.0 (Windows NT 6.2; WOW64) AppleWebKit/537.36 (KHTML, l} "GET
/app1/ HTTP/1.1"
Jul 17 14:55:49 ha_server1 haproxy[5604]: client_ip:37324
[17/Jul/2015:14:55:49.484] front_end_https~ back_end_https/SERVER1 2/0/5/22/29
200 6449 ASP.NET_SessionId=SERVER1~fi2b5smpq33tgwfy0qqmog45 - --VN 0/0/0/0/0
0/0 {||Mozilla/5.0 (Windows NT 6.2; WOW64) AppleWebKit/537.36 (KHTML, l} "GET
/app1/login.aspx HTTP/1.1"
Jul 17 14:55:52 ha_server1 haproxy[5604]: client_ip:37328
[17/Jul/2015:14:55:52.284] front_end_https~ back_end_https/SERVER1 2/0/1/3/7
404 1424 ASP.NET_SessionId=SERVER1~fi2b5smpq33tgwfy0qqmog45 - --VN 0/0/0/0/0
0/0 {||Mozilla/5.0 (Windows NT 6.2; WOW64) AppleWebKit/537.36 (KHTML, l} "GET
/app1/segreteria HTTP/1.1"
Jul 17 14:55:59 ha_server1 haproxy[5604]: client_ip:37344
[17/Jul/2015:14:55:59.452] front_end_https~ back_end_https/SERVER1 2/0/1/2/5
301 448 ASP.NET_SessionId=SERVER1~fi2b5smpq33tgwfy0qqmog45 - --VN 0/0/0/0/0 0/0
{||Mozilla/5.0 (Windows NT 6.2; WOW64) AppleWebKit/537.36 (KHTML, l} "GET
/app1/anagrafenet HTTP/1.1"
Jul 17 14:55:59 ha_server1 haproxy[5604]: client_ip:37345
[17/Jul/2015:14:55:59.461] front_end_https~ back_end_https/SERVER1 2/0/1/32/36
302 435 ASP.NET_SessionId=SERVER1~fi2b5smpq33tgwfy0qqmog45 - --VN 0/0/0/0/0 0/0
{||Mozilla/5.0 (Windows NT 6.2; WOW64) AppleWebKit/537.36 (KHTML, l} "GET
/app1/anagrafenet/ HTTP/1.1"
Jul 17 14:55:59 ha_server1 haproxy[5604]: client_ip:37346
[17/Jul/2015:14:55:59.501] front_end_https~ back_end_https/SERVER1 2/0/1/27/31
200 6625 ASP.NET_SessionId=SERVER1~fi2b5smpq33tgwfy0qqmog45 - --VN 0/0/0/0/0
0/0 {||Mozilla/5.0 (Windows NT 6.2; WOW64) AppleWebKit/537.36 (KHTML, l} "GET
/app1/login.aspx HTTP/1.1"
Jul 17 14:56:06 ha_server1 haproxy[5604]: client_ip:37359
[17/Jul/2015:14:56:06.515] front_end_https~ back_end_https/SERVER1 1/0/4/64/69
302 6712 ASP.NET_SessionId=SERVER1~fi2b5smpq33tgwfy0qqmog45 - --VN 0/0/0/0/0
0/0 {|946|Mozilla/5.0 (Windows NT 6.2; WOW64) AppleWebKit/537.36 (KHTML, l}
"POST /app1/login.aspx HTTP/1.1"
Jul 17 14:56:06 ha_server1 haproxy[5604]: client_ip:37361
[17/Jul/2015:14:56:06.588] front_end_https~ back_end_https/SERVER1
2/0/1/175/179 200 28897 ASP.NET_SessionId=SERVER1~fi2b5smpq33tgwfy0qqmog45 -
--VN 0/0/0/0/0 0/0 {||Mozilla/5.0 (Windows NT 6.2; WOW64) AppleWebKit/537.36
(KHTML, l} "GET /app1/anagrafenet/default.aspx HTTP/1.1"
Jul 17 14:56:06 ha_server1 haproxy[5604]: client_ip:37364
[17/Jul/2015:14:56:06.777] front_end_https~ back_end_https/SERVER1 5/0/2/11/18
200 2049 ASP.NET_SessionId=SERVER1~fi2b5smpq33tgwfy0qqmog45 - --VN 5/5/5/5/0
0/0 {||Mozilla/5.0 (Windows NT 6.2; WOW64) AppleWebKit/537.36 (KHTML, l} "GET
/app1/templatelibrary/menutop/sf-menu.css HTTP/1.1"
Jul 17 14:56:06 ha_server1 haproxy[5604]: client_ip:37363
[17/Jul/2015:14:56:06.776] front_end_https~ back_end_https/SERVER1 6/0/3/13/22
200 3580 ASP.NET_SessionId=SERVER1~fi2b5smpq33tgwfy0qqmog45 - --VN 4/4/4/4/0
0/0 {||Mozilla/5.0 (Windows NT 6.2; WOW64) AppleWebKit/537.36 (KHTML, l} "GET
/app1/menu/supersubs.js HTTP/1.1"
Jul 17 14:56:06 ha_server1 haproxy[5604]: client_ip:37367
[17/Jul/2015:14:56:06.779] front_end_https~ back_end_https/SERVER1 3/0/3/15/22
200 17829 ASP.NET_SessionId=SERVER1~fi2b5smpq33tgwfy0qqmog45 - --VN 4/4/3/3/0
0/0 {||Mozilla/5.0 (Windows NT 6.2; WOW64) AppleWebKit/537.36 (KHTML, l} "GET
/app1/script/dwfunctions.js HTTP/1.1"
Jul 17 14:56:06 ha_server1 haproxy[5604]: client_ip:37369
L’actualité hebdomadaire par RFI - Ukraine: quand l'ex-président Saakachvili pilote...
L’actualité hebdomadaire par RFI - 17/07/2015 Visualisez cet email dans votre navigateur http://rfi.nlfrancemm.com/HM?b=gQRtBBnUxM7jMDLaCWRqVuORe5TYoPh8BjRdO0cBe62Ucya3KFDdXImPDdyLPgQ6&c=cRDsx-VBZP65aEzWJHLFHg Ukraine: quand l'ex-président Saakachvili pilote Odessa L’ex-président géorgien s’est vu confier fin mai le poste de gouverneur de la région d’Odessa. Une nomination qui ne cesse d’étonner mais que Mikheïl Saakachvili a décidé d’accepter compte tenu de l’importance de l’enjeu : ne pas laisser les dirigeants ukrainiens croupir dans le marasme post-soviétique dans une région aussi sensible que celle du célèbre port de la mer Noire. Reportage. http://rfi.nlfrancemm.com/HP?b=6dtp_4B1ni2DXprsyF8zu_T60nHPqYx0HOtZ6K9dkZRWPpLnfNNIef-dknAWQiav&c=DmW-aRSjov7jY057rwcU4Q Kiripi Siku Katembo, photographe surréaliste à Kinshasa Kiripi Siku Katembo, artiste congolais de 36 ans, montre ses photos à la Fondation Cartier dans le cadre de l’exposition « Beauté Congo », commissionnée par André Magnin. Il livre un portrait renversant de Kinshasa, sa ville, telle qu’il la voit se refléter dans ses flaques d’eau. http://rfi.nlfrancemm.com/HP?b=pTCEYdFWtaxquEQdNCRNc3iWRtLxclZXnQYPzwqFeBlY7SBqc6NCXwNtex2WtGHR&c=5RnPgQDFTM61KBlJGw9NZA Hissène Habré: de Sciences-Po au cachot en passant par «La Piscine» Le 20 juillet, s’ouvre au Sénégal le procès contre l’ancien président du Tchad, Hissène Habré, accusé de crimes contre l’humanité, torture et crimes de guerre. Aboutissement d’une longue campagne pour la justice menée par les victimes, c'est aussi une première dans l’histoire juridiciaire de l’Afrique où le tribunal d’un Etat juge l’ancien dirigeant d’un autre Etat pour des violations des droits de l’homme. Retour chronologique sur le parcours du dictateur tchadien, de sa naissance jusqu’à l’ouverture de son procès à Dakar, en passant par ses années d’exercice brutal du pouvoir. http://rfi.nlfrancemm.com/HP?b=mGTnjDc9MbzByhZZb8lMcTm7xsWnTz4y_LidEhJuYv3RCkFiIvbSkPesO34ieufM&c=0jnsaHeaFQ76q_si1dIKAA Iran: les enjeux d'un accord atomique L’accord entre l’Iran et le groupe «5+1» devrait aboutir à une levée progressive des sanctions internationales contre la République islamique. Techniquement, le programme nucléaire iranien fonctionnera toujours, mais sera extrêmement limité. L’annonce de la levée progressive des sanctions a déjà provoqué des scènes de liesse à Téhéran, où l’économie est exsangue. Mais il est encore bien difficile de savoir à qui profitera politiquement cet accord dans le pays, ni quelles seront ses implications au niveau régional. http://rfi.nlfrancemm.com/HP?b=yqajyRiUNToJLg1vhf0-1GCpMTRtyby1UZUGjznY7GrGSx-3_k-NdvwC1fdYortO&c=JPvSEgbGNd4L4Y81ipMz_A Barrissements dans la savane: entretien avec Babor l'éléphant! Babor l’éléphant est un compte Twitter à vocation humoristique. Pour son auteur, le passe-temps à base de blagues s’est tout de même transformé en un métier à temps plein. Maintenant, l’éléphant Babor sort des sentiers battus, mène l’enquête et invente toutes sortes de drôleries qui se partagent gaiement sur les réseaux sociaux à grand renfort de like ! Rencontre avec un drôle d’éléphant... http://rfi.nlfrancemm.com/HP?b=-0_vbKumkMbvwAPWy2wuKgOLIwRNPJrVpIYoil4SJ5Jq7YfEOJKK7cUA18JcpPuS&c=AEZcPlOXk6OQYQBfipXicg Sept jours en images du 10 au 16 juillet Un jour, une image : la revue de l'actualité de la semaine. http://rfi.nlfrancemm.com/HP?b=VDgqPLbwzr1mzi1DJ4sOnK05-XFoxiPuNKyK5bu_eSU6nbyt3t_gcpgtDaL20tzD&c=TVJ0UrZSLI0NL4S-MUqR4Q Dégel américano-cubain: Moscou craint un changement de cap de Cuba La réouverture des ambassades cubaine et américaine, le 20 juillet 2015, marque le symbole du dégel des relations entre La Havane et Washington. La Russie, traditionnel allié de Cuba pendant la Guerre froide, avait jusque-là conservé des liens étroits avec son partenaire des Caraïbes. Comment ce rapprochement entre les deux pays a-t-il été ressenti du côté de l’ancien « grand-frère » russe ? Eléments de réponse dans Appels sur l'actualité. http://rfi.nlfrancemm.com/HP?b=dmZaz3wO92ELKRy9OX5up7gQhPlPaLD3ietgaSXeS55exU2npLJNRYFgfPxtxJkQ&c=seKbAmjLVONjJjl9i2sESQ Praviy Sektor, instrument d’une banale guerre de gangs? En Ukraine, le bras de fer entre l'Etat et le groupe ultranationaliste Praviy Sektor ne fait que commencer. Samedi 11 juillet, une fusillade meurtrière a éclaté dans l’ouest de la Transcarpathie, une région proche de la frontière avec la Hongrie. Depuis, toute l'Ukraine vit sous la menace d'affrontements généralisés entre bataillons de volontaires et forces régulières. http://rfi.nlfrancemm.com/HP?b=puT6da8cmtLp-fTGnzh8dd5x3ot-WKkqJdfEwgS8celJjSM4waupapue3DSvvoCb&c=G_B6SaIbYqdLeMe4QMSwRg Pourquoi la France a refusé l’asile à Julian Assange Le 3 juillet 2015, le journal Le Monde publiait une lettre de Julian Assange au président François Hollande, demandant au chef de l'Etat français de lui accorder l’asile. La réponse fut aussi rapide que laconique. Appels sur l'actu
Re: Server IP resolution using DNS in HAProxy
Hello, On 07/14/2015 10:11 PM, Baptiste wrote: > > I know the message above is very long, but we really need your feedback! > First, many thanks for tackling this! It surely makes many peoples live much easier. Reading this makes me want two things, one of them being a little "not-haproxy-like" maybe. First would be resolution of SRV records and actually using the port supplied by the SRV record as the port for the server. I looked at the code and it doesn't seem like too much work, most of it would probably be changing the config stuff accordingly. The other one is... well you asked for it ;) so here it goes: it would be great to express in the config something like "resolve this name and use up to X servers from the reply". The backend then allocates X servers. Assuming that the initial lookup returns Y results, the (sorted) records get assinged to the first Y servers, the other X-Y servers get marked as down. Upon a new lookup, same procedure for a potentially changing value of Y. I realize this a pretty bold feature request for several reasons, but I have actually spent some thought on it think it might be doable without really violating any of HAProxy's design paradigms. I would also be willing to invest some time (code) into this myself. If you think this might be at least worth a discussion, I'd be happy to share some more detailed thoughts and it would be great to hear your thoughts on that, too. 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
cookie prefix strange behavior
We have compiled and installed haproxy version 1.6 dev2.
If we use cookie insert all works, but if we use cookie prefix
(ASP.NET_SessionId) or sticky table in which one have to specify cookie to be
sticked, so using cookie name = ASP.NET_SessionId) we have a strange behavior.
BLOCK1
As you can see below, we open a browser and make a request, cookie prefix
mechanism works well, we can login and use the application (all subsequent
requests go on the some server).
BLOCK2
But if we open a new browser instance (chrome in this case, but this happen
also if we open IE) the client uses a strange "ASP.NET_SessionId" cookie
without haproxy prefix with back-end server, server does not ask client to set
a new cookie.
As of login, clearly, backend server does not recognize the cookie sent by
client (haproxy do a plain roundrobin distribution, no cookie management was
done) and so backend server return an error.
Can this be a bug of haproxy or a bad configuration by us ?
BLOCK1
Jul 17 14:55:49 ha_server1 haproxy[5604]: client_ip:37322
[17/Jul/2015:14:55:49.414] front_end_https~ back_end_https/SERVER1 2/0/44/18/64
302 467 ASP.NET_SessionId=SERVER1~fi2b5smpq33tgwfy0qqmog45 - --VN 0/0/0/0/0 0/0
{||Mozilla/5.0 (Windows NT 6.2; WOW64) AppleWebKit/537.36 (KHTML, l} "GET
/app1/ HTTP/1.1"
Jul 17 14:55:49 ha_server1 haproxy[5604]: client_ip:37324
[17/Jul/2015:14:55:49.484] front_end_https~ back_end_https/SERVER1 2/0/5/22/29
200 6449 ASP.NET_SessionId=SERVER1~fi2b5smpq33tgwfy0qqmog45 - --VN 0/0/0/0/0
0/0 {||Mozilla/5.0 (Windows NT 6.2; WOW64) AppleWebKit/537.36 (KHTML, l} "GET
/app1/login.aspx HTTP/1.1"
Jul 17 14:55:52 ha_server1 haproxy[5604]: client_ip:37328
[17/Jul/2015:14:55:52.284] front_end_https~ back_end_https/SERVER1 2/0/1/3/7
404 1424 ASP.NET_SessionId=SERVER1~fi2b5smpq33tgwfy0qqmog45 - --VN 0/0/0/0/0
0/0 {||Mozilla/5.0 (Windows NT 6.2; WOW64) AppleWebKit/537.36 (KHTML, l} "GET
/app1/segreteria HTTP/1.1"
Jul 17 14:55:59 ha_server1 haproxy[5604]: client_ip:37344
[17/Jul/2015:14:55:59.452] front_end_https~ back_end_https/SERVER1 2/0/1/2/5
301 448 ASP.NET_SessionId=SERVER1~fi2b5smpq33tgwfy0qqmog45 - --VN 0/0/0/0/0 0/0
{||Mozilla/5.0 (Windows NT 6.2; WOW64) AppleWebKit/537.36 (KHTML, l} "GET
/app1/anagrafenet HTTP/1.1"
Jul 17 14:55:59 ha_server1 haproxy[5604]: client_ip:37345
[17/Jul/2015:14:55:59.461] front_end_https~ back_end_https/SERVER1 2/0/1/32/36
302 435 ASP.NET_SessionId=SERVER1~fi2b5smpq33tgwfy0qqmog45 - --VN 0/0/0/0/0 0/0
{||Mozilla/5.0 (Windows NT 6.2; WOW64) AppleWebKit/537.36 (KHTML, l} "GET
/app1/anagrafenet/ HTTP/1.1"
Jul 17 14:55:59 ha_server1 haproxy[5604]: client_ip:37346
[17/Jul/2015:14:55:59.501] front_end_https~ back_end_https/SERVER1 2/0/1/27/31
200 6625 ASP.NET_SessionId=SERVER1~fi2b5smpq33tgwfy0qqmog45 - --VN 0/0/0/0/0
0/0 {||Mozilla/5.0 (Windows NT 6.2; WOW64) AppleWebKit/537.36 (KHTML, l} "GET
/app1/login.aspx HTTP/1.1"
Jul 17 14:56:06 ha_server1 haproxy[5604]: client_ip:37359
[17/Jul/2015:14:56:06.515] front_end_https~ back_end_https/SERVER1 1/0/4/64/69
302 6712 ASP.NET_SessionId=SERVER1~fi2b5smpq33tgwfy0qqmog45 - --VN 0/0/0/0/0
0/0 {|946|Mozilla/5.0 (Windows NT 6.2; WOW64) AppleWebKit/537.36 (KHTML, l}
"POST /app1/login.aspx HTTP/1.1"
Jul 17 14:56:06 ha_server1 haproxy[5604]: client_ip:37361
[17/Jul/2015:14:56:06.588] front_end_https~ back_end_https/SERVER1
2/0/1/175/179 200 28897 ASP.NET_SessionId=SERVER1~fi2b5smpq33tgwfy0qqmog45 -
--VN 0/0/0/0/0 0/0 {||Mozilla/5.0 (Windows NT 6.2; WOW64) AppleWebKit/537.36
(KHTML, l} "GET /app1/anagrafenet/default.aspx HTTP/1.1"
Jul 17 14:56:06 ha_server1 haproxy[5604]: client_ip:37364
[17/Jul/2015:14:56:06.777] front_end_https~ back_end_https/SERVER1 5/0/2/11/18
200 2049 ASP.NET_SessionId=SERVER1~fi2b5smpq33tgwfy0qqmog45 - --VN 5/5/5/5/0
0/0 {||Mozilla/5.0 (Windows NT 6.2; WOW64) AppleWebKit/537.36 (KHTML, l} "GET
/app1/templatelibrary/menutop/sf-menu.css HTTP/1.1"
Jul 17 14:56:06 ha_server1 haproxy[5604]: client_ip:37363
[17/Jul/2015:14:56:06.776] front_end_https~ back_end_https/SERVER1 6/0/3/13/22
200 3580 ASP.NET_SessionId=SERVER1~fi2b5smpq33tgwfy0qqmog45 - --VN 4/4/4/4/0
0/0 {||Mozilla/5.0 (Windows NT 6.2; WOW64) AppleWebKit/537.36 (KHTML, l} "GET
/app1/menu/supersubs.js HTTP/1.1"
Jul 17 14:56:06 ha_server1 haproxy[5604]: client_ip:37367
[17/Jul/2015:14:56:06.779] front_end_https~ back_end_https/SERVER1 3/0/3/15/22
200 17829 ASP.NET_SessionId=SERVER1~fi2b5smpq33tgwfy0qqmog45 - --VN 4/4/3/3/0
0/0 {||Mozilla/5.0 (Windows NT 6.2; WOW64) AppleWebKit/537.36 (KHTML, l} "GET
/app1/script/dwfunctions.js HTTP/1.1"
Jul 17 14:56:06 ha_server1 haproxy[5604]: client_ip:37369
[17/Jul/2015:14:56:06.801] front_end_https~ back_end_https/SERVER1 4/0/1/2/7
200 397 ASP.NET_SessionId=SERVER1~fi2b5smpq33tgwfy0qqmog45 - --VN 4/4/4/4/0 0/0
{||Mozilla/5.0 (Windows NT 6.2; WOW64) AppleWebKit/537.36 (KHTML, l} "GET
/app1/img/layout/tearoff_icon.gif HTTP/1.1"
Jul 17 14:56:06 ha_server1 haproxy[5604]: client_ip:37365
[17/
Re: can I get the uptime per server in csv stats
Thank you. I was seeking the document for string `uptime` and `time`, but nothing related found. how silly :) > On Jul 17, 2015, at 2:35 PM, Pavlos Parissis > wrote: > > > On 17/07/2015 06:02 πμ, Ruoshan Huang wrote: >> hi, >>I found that the html stats page has a column of status which comes with >> the uptime of a server or backend, >> but in the csv stats I couldn’t find the uptime accordingly. >>Can I get the uptime of servers without parsing the html? Thanks. >> >> -- >> Good day! >> ruoshan >> >> > > I believe it is the lastchg field name, > 23. lastchg [..BS]: number of seconds since the last UP<->DOWN transition > > sudo haproxytool server -m lastchg node1 --backend=b1 > # backendname servername > b1 node1 53856 > > Cheers, > Pavlos > -- Good day! ruoshan
[SPAM] I want to be your good partner
Dear purchasing manager, Hello,this Klaus from Hangzhou Modern Color Printing Co., Ltd.,our company is a professional printing manufacturer with years’s experience.so we want to avail ourselves of opportunity establishing business relation with you. Please link our company website : http://www.topbook-printer.com/ If you want to know more about our product,by the way, free sample are available. Thank you in advance! Best regards, Klaus Hangzhou Modern Color Printing Co., Ltd. Mail: klaus_mod...@163.com
