Alexander Huemer wrote:
Amos Jeffries wrote:
On Tue, 20 Oct 2009 01:04:26 +0200, Henrik Nordstrom
<[email protected]> wrote:
mån 2009-10-19 klockan 12:10 +1300 skrev Amos Jeffries:
Um, is that function libcap2 specific?
Not sure when it was added. Checking... seems to be 2.09. Added to the
git repository Sat Mar 29 21:40:06 2008 -0700.
There is also a libcap-ng project these days, with yet another API..
The other was mentioned as a possible requirement as well. I have not
spent any time seeing whether its worth it or not to support libcap-ng. Do
you know enough about them both to pick?
It may be related to the LIBCAP_BROKEN identifier or another such test
for the specific function may be worth adding...
I rather have one code base than two here.. either libcap is used or it
is not. Using libcap if found working or raw syscalls if not does not
sound like a good idea to me.
But maybe we can require a reasonably current libcap-2 for TPROXY
support? It requires a custom kernel anyway on the systems with too old
libcap implementations I think.
We can do that yes. I think I would also rather do it too. It paves the
way for a clean deprecation cycle now that TPROXYv4 kernels are effectively
mainstream:
3.0: (2008-2010) TPROXYv2 with libcap + libcap2
3.1: (2010-2012) support TPROXYv2 + TPROXYv4 with libcap2
3.2: (2011?) support TPROXYv4 with libcap2
Amos
i guess this fix went into squid 3.1.0.14 ... ?
the gentoo package for that version just appeared in the portage tree
and i installed it.
no more warning messages in dmesg. good job!
will this find it's way into squid 3.0 too ?
or can i wait for 3.2 ? i did not find a planned release date.
regards
-alex
The Gentoo hack fix is the only thing included so far (must be what you
see in 3.1.0.14) and will also be in 3.0.STABLE20 when that comes out.
Amos
--
Please be using
Current Stable Squid 2.7.STABLE7 or 3.0.STABLE19
Current Beta Squid 3.1.0.14
