HAProxy version .48 will not use URL Table Alias for front end listener
I use HAProxy with an alias of ports to listen on. The backend has the ports set to blank so it just does a pass through to the back end. I want to use a URL Table alias that will update this list so a restart of HAProxy will pick up the new list of ports to listen on.
In thinking about this, the generated config is probably done when saved and it reads that alias. Since a URL Table is stored in a txt file, it's probably not able to pick up these changes and generate a new config unless some sort of command is run to redo that config file. This could be seen less as a bug and more of a feature request, so I'll let you decide if it should be moved to a feature request.
#1 Updated by Pi Ba over 3 years ago
Imho a 'feature request' indeed. The support for 'fixed' lists of ports and ip's is ok for easy configuration with the assumption they wont change. But having them updated automatically every x minutes/hours. That would need some extra checking to avoid restarting 'whenever' pfSense sees the need to update the list and would also need to notify haproxy of such a change if applicable..
As such i don't see much added value for supporting url table here. If you want to send a pullrequest that does it all thats ok for me. Personally i'm not going to make it happen anytime soon.
#2 Updated by Stéphane Lapie about 1 year ago
Quick up.I just stumbled upon a scenario where having support for URL Table Alias would be helpful or desirable, since pfSense has no API to easily update lists :
- Getting a list of geolocated IP addresses to block specific countries, at HAproxy's level (return a 403 page for specific conditions and services, instead of outright blocking at the IP level)
- Right now the go-to solution for this is pfBlockerNG (which is admittedly quite a bit complex and probably overkill)
- Maintaining an internal list that is to be shared between several pfSense instances
- Likewise, having an API capable of updating aliases and reloading/restarting HAproxy would fix that problem
However, I definitely see how hellish it would be to detect updates and reflect them appropriately.
I will therefore go with a standard alias table for geo-location.