Henning Svane wrote:
The possibility to have constant, so ex bind ip numbers can be defined
under global, and then the constant can be used in the frontend, this
way you only have to modify in global.
Are you aware of the fact that you can use variables in Haproxy's
configuration? With variables being available, I don't see the need for
constants.
You just need to remember that variable names need to be put into
"quoted strings" to be used inside the configuration file.
To make use of variables, you can use either "setenv" or "presetenv" to
set up variables and use those later on. When going for "presentenv",
this allows you to use the same Haproxy config file on several servers,
and adjust some of the variables outside of Haproxy (e.g. through
systemd settings) if needed.
You can even chain these setenv or presetenv statements to make things
even more variable. Consider this:
presetenv HERMESAGENTADDR 192.168.22.33
presetenv DEFAULTPORT 8080
presetenv HERMESPORT "$DEFAULTPORT"
presetenv HERMESHTTP "${HERMESAGENTADDR}:${HERMESPORT}"
And then later in the config file:
backend foo
server hermes "$HERMESHTTP" check agent-addr "$HERMESAGENTADDR"
This example is meant to show how you can make the agent-check default
to the same IP address as the actual service, but allow easy overrides
to that default for both the port and the server's address.
It is because I will use stick-table to control who logges in and as
stick-table need to configured for either IPv4 and IPv6.
I'm not sure if I understand correctly what your requirements are, but
in general, a stick-table of "type ipv6" can hold representations of
both IPv4 and IPv6 addresses, of course. So I don't see the need to make
a difference between IPv4 and IPv6 addresses in regard to stick tables.
Clearly, IPv6 addresses will need a few bits more to store, which you'd
waste if you put only IPv4 addresses into a table that can hold IPv6
addresses, but when you're going to deal with both types of IP addresses
anyway, I don't think that trying to squeeze out a few bits here and
there by putting them into separate tables is worthwhile. Allocating
memory for two tables that are both sufficiently sized to leave some
margin for high usage situations is probably going to waste more memory
than one large table that can hold both types of addresses.
Jens
