Re: autoconf-refactor and netfilter-based transparent proxy
Hi all. To avoid risking this to happen again, i'll do more frequent interim merges while using trunk to baseline the output. Any objections? Thanks On 5/10/10, Henrik Nordström hen...@henriknordstrom.net wrote: mån 2010-05-10 klockan 18:13 +0200 skrev Kinkie: revno: 10425 committer: Francesco Chemolli kin...@squid-cache.org branch nick: trunk timestamp: Sun 2010-04-25 23:40:51 +0200 message: Interim merge from autoconf-refactor feature-branch. Kinkie, could you please check that netfilter-based interception proxies are still supported? Will do ASAP (probably tomorrow). I have added back the missing define for LINUX_NETFILTER, but this is the second odd thing in the autoconf refactor merge. Can you please do a full review of your merge to see if there is anything else that's odd? It would also be nice to get rid of libcap and TPROXY warnings when the user wants just netfilter-based interception proxy support and is willing to --disable the rest. In Squid v3.1, we now get these irrelevant (for the said configuration) warnings: I'll check. trunk does not even have a configure option for controlling TPROXY. It's assumed to always be available by configure.in, and disabled in compiled code based on system header defines. Also the libcap warning message is a bit misguided. It's not only about TPROXY but also about security. Regards Henrik -- /kinkie
Re: autoconf-refactor and netfilter-based transparent proxy
On 05/21/2010 06:43 AM, Kinkie wrote: To avoid risking this to happen again, i'll do more frequent interim merges while using trunk to baseline the output. Any objections? I do not really know what you mean. If you are comfortable with your changes, post your changes for review, and nobody objects to a commit, you should commit your changes to trunk. IMO, we should not post and commit half-baked or poorly-scoped parts of a bigger project because they would be difficult to review without proper context. Reviewing large, complex changes is also difficult but I would still prefer to review and commit self-contained changes. Cheers, Alex. On 5/10/10, Henrik Nordström hen...@henriknordstrom.net wrote: mån 2010-05-10 klockan 18:13 +0200 skrev Kinkie: revno: 10425 committer: Francesco Chemolli kin...@squid-cache.org branch nick: trunk timestamp: Sun 2010-04-25 23:40:51 +0200 message: Interim merge from autoconf-refactor feature-branch. Kinkie, could you please check that netfilter-based interception proxies are still supported? Will do ASAP (probably tomorrow). I have added back the missing define for LINUX_NETFILTER, but this is the second odd thing in the autoconf refactor merge. Can you please do a full review of your merge to see if there is anything else that's odd? It would also be nice to get rid of libcap and TPROXY warnings when the user wants just netfilter-based interception proxy support and is willing to --disable the rest. In Squid v3.1, we now get these irrelevant (for the said configuration) warnings: I'll check. trunk does not even have a configure option for controlling TPROXY. It's assumed to always be available by configure.in, and disabled in compiled code based on system header defines. Also the libcap warning message is a bit misguided. It's not only about TPROXY but also about security. Regards Henrik
Re: autoconf-refactor and netfilter-based transparent proxy
On Fri, May 21, 2010 at 5:37 PM, Alex Rousskov rouss...@measurement-factory.com wrote: On 05/21/2010 06:43 AM, Kinkie wrote: To avoid risking this to happen again, i'll do more frequent interim merges while using trunk to baseline the output. Any objections? I do not really know what you mean. If you are comfortable with your changes, post your changes for review, and nobody objects to a commit, you should commit your changes to trunk. IMO, we should not post and commit half-baked or poorly-scoped parts of a bigger project because they would be difficult to review without proper context. Reviewing large, complex changes is also difficult but I would still prefer to review and commit self-contained changes. As the autoconf-refactor should imply little or no visible changes, the idea is to simply use a consistent baseline: trunk. Diffing include/autoconf.h and the output of the configure script should be enough ensure that the objective is met, but not if they diverge too much. This is, at least, the plan. The purpose is for this to remain a refactoring branch: all merges will have to be able to build, no question about it. I agree with getting a consensus before merging anything with user-visible impact (such as the changes to the authentication helpers build options). I don't expect the merges to be too frequent, maybe once a week or so. If you prefer to have a voting for all merges, it's also OK but may slow things down somewhat. Ciao! -- /kinkie
Re: autoconf-refactor and netfilter-based transparent proxy
fre 2010-05-21 klockan 09:37 -0600 skrev Alex Rousskov: I do not really know what you mean. If you are comfortable with your changes, post your changes for review, and nobody objects to a commit, you should commit your changes to trunk. In this case I am happy to have Kinkie review his own changes. It's not likely anyone else of us will spot issues in proposed autoconf changes before they hit trunk. Reviewing large, complex changes is also difficult but I would still prefer to review and commit self-contained changes. Sure. Any change which goes to trunk should be self-contained and not require further changes to actually work the way intended. Regards Henrik
Re: autoconf-refactor and netfilter-based transparent proxy
Henrik Nordström wrote: fre 2010-05-21 klockan 09:37 -0600 skrev Alex Rousskov: I do not really know what you mean. If you are comfortable with your changes, post your changes for review, and nobody objects to a commit, you should commit your changes to trunk. In this case I am happy to have Kinkie review his own changes. It's not likely anyone else of us will spot issues in proposed autoconf changes before they hit trunk. Reviewing large, complex changes is also difficult but I would still prefer to review and commit self-contained changes. Sure. Any change which goes to trunk should be self-contained and not require further changes to actually work the way intended. Regards Henrik Agreed on both. Kinkie, perhapse if you aimed for doing audit submits just prior to the weekends with a short summary of which configure options have been touched, we could synchronize some short period for us to test before it gets committed to trunk for full use. The full 10-day (or more) delay only happens if another dev can't +1 the change. Though of course if there are any doubts in your mind about a change skip a weeks submission rather than rushing in incompletely tested change in. The last two bumps were annoying to some, yes. But they were to be expected with such a low-level set of changes and were less impact than I personally was expecting to have to deal after the fallout we had on previous attempts. Amos -- Please be using Current Stable Squid 2.7.STABLE9 or 3.1.3
Re: autoconf-refactor and netfilter-based transparent proxy
On Mon, 10 May 2010 09:42:51 -0600, Alex Rousskov rouss...@measurement-factory.com wrote: Hello, It looks like configure.in in trunk lost the code setting LINUX_NETFILTER. There are comments promising it will happen later in the code, but I do not see it happening. I am worried that this will break support for basic netfilter-based interception proxies (those working without libcap or TPROXY). I may be wrong, but the changes may have been introduced by autoconf-refactor: revno: 10425 committer: Francesco Chemolli kin...@squid-cache.org branch nick: trunk timestamp: Sun 2010-04-25 23:40:51 +0200 message: Interim merge from autoconf-refactor feature-branch. Kinkie, could you please check that netfilter-based interception proxies are still supported? It would also be nice to get rid of libcap and TPROXY warnings when the user wants just netfilter-based interception proxy support and is willing to --disable the rest. In Squid v3.1, we now get these irrelevant (for the said configuration) warnings: configure: WARNING: Missing needed capabilities (libcap or libcap2) for TPROXY configure: WARNING: Linux Transparent Proxy support WILL NOT be enabled configure: WARNING: Reduced support to Interception Proxy I was planning to propose this for 3.3, but it might as well happen now for 3.2... What I'm thinking is a shuffling of the transparent options like we just shuffled the auth ones. --enable/disable-transparent - disable all semantic (HTTP) transparent stuff. This being TPROXY and other pass-thru stuff we add which makes Squid semantically transparent. Sub-options: --with-tproxy --enable-nat-intercept - disable/enable all NAT modules. the options below to fine-tune which ones get built: Sub-options: --with-iptables --with-pf --with-ipf --with-ipfw ... Amos
Re: autoconf-refactor and netfilter-based transparent proxy
On Mon, 10 May 2010 22:49:03 +0200, Henrik Nordström hen...@henriknordstrom.net wrote: mån 2010-05-10 klockan 18:13 +0200 skrev Kinkie: revno: 10425 committer: Francesco Chemolli kin...@squid-cache.org branch nick: trunk timestamp: Sun 2010-04-25 23:40:51 +0200 message: Interim merge from autoconf-refactor feature-branch. Kinkie, could you please check that netfilter-based interception proxies are still supported? Will do ASAP (probably tomorrow). I have added back the missing define for LINUX_NETFILTER, but this is the second odd thing in the autoconf refactor merge. Can you please do a full review of your merge to see if there is anything else that's odd? It would also be nice to get rid of libcap and TPROXY warnings when the user wants just netfilter-based interception proxy support and is willing to --disable the rest. In Squid v3.1, we now get these irrelevant (for the said configuration) warnings: I'll check. trunk does not even have a configure option for controlling TPROXY. It's assumed to always be available by configure.in, and disabled in compiled code based on system header defines. Huh? TPROXYv2 was. v4 is different. trunk TPROXYv4 is build controlled by the LINUX_NETFILTER present/absent options. Since it's in the netfilter software. At run-time it's tested by a startup probe of the kernel via libsock (always present) and libcap (optional, thus the libcap mention). * libsock to test whether a v6 socket can handle the IP_TRANSPARENT flag and enable/disable the v6 support. * libcap to see if the spoofing privileges are available to enable/disable tproxy entirely. Amos
