Hi Lukas,
On Fri, Apr 26, 2013 at 10:26:33PM +0200, Lukas Tribus wrote:
> Hi,
>
> throwing in my two cents here, based on a few uneducated guesses reading
> the Makefile, etc. Feel free to disagree/correct/shout at me :)
Thanks for sharing your thoughts, I feel less alone sometimes when I can
discuss choices.
> (actually I wrote this before Willy answered)
>
>
> > As for renaming the CONFIG_HAP_LINUX_TPROXY to something different would
> > require everyone that on a regular basis builds HAProxy with this
> > feature to change their build flags..
>
> The name CONFIG_HAP_LINUX_TPROXY or USE_LINUX_TPROXY suggests this is for
> Linux. Implementing compatibility changes for FreeBSD in those flags is
> misleading, whether they are internal (like CONFIG_HAP_LINUX_TPROXY) or
> external (USE_LINUX_TPROXY).
>
> I think we should avoid that.
OK, that was my first impression as well. It looks "unpolished" but can
be understood sometimes during a transition, but not for the final state.
> > would require new make scripts and several other changes though-out where
> > transparent proxying is implemented.
>
> If you built haproxy before on FreeBSD and used transparent proxying, then
> it probably didn't work at all (like in your case) or those values have been
> defined in another place, like by libc or by a manual definition.
>
> Either way, we don't break anything that currently works by introducing a
> new build flag. So you would only have to adjust your make line if you
> actually need it and I think thats does less long-term harm than defining
> those things under the USE_LINUX_TPROXY/CONFIG_HAP_LINUX_TPROXY hat.
>
>
> > Also I'm wondering whether we should define USE_FREEBSD_TPROXY instead of
> > USE_LINUX_TPROXY for this. Maybe we should rename CONFIG_HAP_LINUX_TPROXY
> > to CONFIG_HAP_FULL_TPROXY and adapt it depending on the OS.
>
> Yes, that makes more sense to me.
>
> We should probably clarify the condition with OpenBSD. I assume those
> defines are the same for all BSD flavors? So should we introduce a more
> generic flag like USE_BSD_TPROXY instead to avoid a USE flag for every
> BSD or does the difference between them justify a per-BSD USE flag?
OK I have reviewed the existing code a bit. Most of the usages of
CONFIG_HAP_LINUX_TPROXY are :
1) define the appropriate flags when they're not defined (kernel newer
than libc)
2) enable parsing the option
3) enable the setsockopt calls (one of which is wrong for FBSD).
So what I'm thinking about is to change that :
1) solely rely on the various per-OS flags to decide whether or not
transparent proxy is supported (eg: IP_FREEBIND, IP_TRANSPARENT,
IP_BINDANY, ...). That way we don't need an OS-specific option
for something that automatically comes with the OS and that can
be detected using a #ifdef and is enabled using a config setting
anyway (eg: the "transparent" or "usesrc" keyword).
2) keep CONFIG_HAP_LINUX_TPROXY to force setting the values on linux
when they're not set (as it initially was made for)
3) only implement the setsockopt() that have their appropriate define.
4) report in the -vv output what options are supported.
Thus it will become trivial to add support for other OSes (I believe
OpenBSD also supports it).
What do you think about this ?
Regards,
Willy
