Hi Willy / Lukas,
It seams to me OpenBSD doesn't support the IP_BINDANY flag..:
http://www.openbsd.org/cgi-bin/cvsweb/~checkout~/src/sys/netinet/in.h
<http://www.openbsd.org/cgi-bin/cvsweb/%7Echeckout%7E/src/sys/netinet/in.h>
While FreeBSD does:
http://svnweb.freebsd.org/base/head/sys/netinet/in.h?view=markup
But then again neither of them supports SOL_IP, so i would expect
compilation to simply 'fail'. When trying to compile with the
USE_LINUX_TPROXY option.
The combination i think is unlikely to cause problems for other
currently working builds/systems..
If you want i can probably come up with a combination that makes it work
for FreeBSD with a special USE_FREEBSD_TPROXY make option.
Or go for the 'full automatic inclusion' depending on available flags.
Which i think is even 'nicer'. But probably needs more testing to
confirm proper working..
I would be willing to make these changes. Is this the way to go?
Thanks for reviewing my proposed changes sofar.
PiBa-NL
Op 26-4-2013 22:40, Willy Tarreau schreef:
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
