Greetings,
On 04/29/2016 11:16 AM, Philipp Buehler wrote:
Hi,
I quite like not to reload haproxy every here and there (stats and
races..) and make
quite some use of 'acl foo .. -f aclfile'.
Now feature-creep mounts and aclfile shall be build/extended "on
demand" (think of something along fail2ban).
Besides losing stats, that can grow into a problem if multiple events
within very short times start to reload haproxy.
Following problems with rereading aclfile automatically by haproxy
come to mind:
- doing it for every request: disk IO killer
- doing it at fixed intervals: might no suite for "every" use-case
(and if many aclfiles around, disk IO again)
- passing an option per acl line likely be a parser hell
- more exotic foobars
My modest proposal would go like that - for starters :) :
- (global) option 'timeout aclfiles 300': will reload "special"
aclfile every 300s
- aclfile introduced by -F (instead -f) will flag it as "special"
which leaves a somewhat race when the special file is written while
the reload happens.
Maybe better: as above, but plus:
- a flagfile like aclfile.RELOAD has to be present at the 300s mark
Or, in a totally different approach, do what OpenBSD's pf(4) can do,
have a "table" that can be
manipulated via admin-socket.
HAProxy sockets support "add acl <acl> <pattern>" to add an ACL entry or
"add map" to add to a map. Can be used with "clear acl"/"clear map" to
empty the table first to refresh them completely.
See
https://cbonte.github.io/haproxy-dconv/configuration-1.5.html#9.2-add%20acl
for details.
If how to use that isn't clear I can provide an example.
- Chad
Thoughts about it?
