Hi Graeme,
On Wed, Jul 04, 2012 at 03:57:35PM +0200, Graeme Donaldson wrote:
> Hi
>
> I wanted to put a persistence cookie in the defaults section of my config,
> but I ran into 2 problems on reloading HAproxy as a result:
>
> - Every tcp backend in my config throws a warning like this: [WARNING]
> 185/153532 (25427) : config : 'cookie' statement ignored for proxy
> 'sometcpbackend' as it requires HTTP mode.
This one is expected and normal. You shouldn't share defaults sections for
TCP and HTTP proxies if you put HTTP settings there. Most people create one
defaults section for TCP and another one for HTTP (anyway most often the
timeouts differ a lot).
> - My stats config doesn't have a server list, so reload fails
> with: [ALERT] 185/153532 (25427) : config : HTTP proxy stats has a cookie
> but no server list !
What version are you using ? This was changed in 1.5-dev some time ago but
not backported into 1.4.
> My stats listener looks like this:
>
> listen stats 0.0.0.0:9111
> mode http
> stats uri /
>
> For the first case, I understand why the warning is emitted, but perhaps
> it'd make sense to only output the warning if the cookie definition is
> specifically attempted on the tcp proxy itself, rather than inherited from
> the "defaults" section.
It's not that easy, because most of the coherence checks are performed very
late to ensure we consider everything, and when this is performed, we don't
know anymore if the option was inherited or explicitly set.
> Come to think of it, perhaps TCP backends should
> just not inherit the cookie definition at all?
we don't know they're TCP until the whole section has been processed. The
mode itself may be inherited. For instance, how would you process this then :
defaults xxx
mode http
cookie srv
listen www
bind :4444
stats uri /
listen ssh
mode tcp
server local 127.0.0.1:22
Defaults are inherited first then the explicit settings are used to override
defaults. As you can see in the two examples above, this is the only way not
to lead to unexpected settings.
> I'm not great at tracing my
> way through C code unfortunately, so I have no idea how practical these are.
>
> For the second case, I'm not sure if my stats listener is "wrong" in some
> way. I inherited the config more than 2 years ago, and while I've become
> fairly familiar with most of it, I've never really needed to tamper with
> the stats part, so it may be it isn't optimally defined, but looking at the
> docs has not helped me see what's wrong, if anything.
Really, you'd better proceed like this :
defaults http
mode http
timeout client/server/connect ...
log ...
option httplog ...
listen http1
...
defaults tcp
mode tcp
timeout client/server/connect ...
log ...
option tcplog ...
listen tcp1
...
Also, sometimes it's not *that* wise to put cookies in defaults sections,
I've seen setups several times that were causing persistence issues because
people were inheriting cookies from the defaults section and were delivering
the same name for several sub-components of the same service. The common
trap is this one :
defaults
cookie SRV insert indirect nocache
listen dynamic
server s1 1.1.1.1:80 cookie s1
server s2 1.1.1.2:80 cookie s2
server s3 1.1.1.3:80 cookie s3
server s4 1.1.1.4:80 cookie s4
listen static
server s1 2.2.2.1:80 cookie s1
server s2 2.2.2.2:80 cookie s2
In the config above, when the browser loads some static components from the
"static" proxy, it forces the SRV cookie to be either "s1" or "s2". When
the user then loads some dynamic contents, only s1 and s2 will be used, and
s3 and s4 will not get any request. And using different cookie values is
even worse, it breaks persistence.
For this reason it is encouraged not to share the cookie names between
proxies, thus not to put it in defaults sections.
If in your case you absolutely need to have the cookie in the defaults
section, then just put your stats at the beginning, or close to the end,
prefixed by another cookie-less defaults section.
If you're interested, the patch which changed this behaviour in 1.5-dev
is the following one :
From 44702af019576cc68979056982ac06cf36ff88ed Mon Sep 17 00:00:00 2001
From: Willy Tarreau <[email protected]>
Date: Mon, 30 May 2011 18:47:41 +0200
Subject: [MINOR] config: make it possible to specify a cookie even without a
server
Oh well, finally I just backported it into 1.4, as well as another one to
tolerate a cookie on a TCP server.
Hoping this helps,
Willy
