From: Matthias Fischer <matthias.fischer@ipfire.org>
To: development@lists.ipfire.org
Subject: Re: Testing 'squid 4.0.24'
Date: Sun, 11 Mar 2018 15:44:13 +0100 [thread overview]
Message-ID: <ae498d4e-ac4f-f273-4ed8-c12fab79425a@ipfire.org> (raw)
In-Reply-To: <1520773546.3332.51.camel@ipfire.org>
[-- Attachment #1: Type: text/plain, Size: 5824 bytes --]
Hi,
On 11.03.2018 14:05, Michael Tremer wrote:
> Hi,
>
> okay that sounds interesting. So what problems can we expect when updating to
> squid 4?
Good question...
While "cleaning my soothsayer glass ball", ;-) I think it's still too
early to say anything about that. Some problems with previous versions
showed up only after a few days of continuous operation, so for now I
think its the best to keep on testing.
And if before we start thinking about upgrading, it would be great if
someone else could test other - more complex - configurations, for
example with AD-authentification, classroom extensions, etc. Perhaps
something for a testing tree?
Best,
Matthias
> -Michael
>
> P.S. I do not think that we need that conntrack support for anything
>
> On Sun, 2018-03-11 at 11:20 +0100, Matthias Fischer wrote:
>> Hi,
>>
>> FYI:
>>
>> I added '--without-netfilter-conntrack' to configure options. Building
>> with Core 118 was OK. Since yesterday, 'squid 4.0.24' is running on
>> GREEN (non-transparent) and BLUE (transparent) without any further
>> kernel messages, no seen problems so far.
>>
>> Running addons/services: 'squidguard', 'sgraph', 'clamav',
>> 'snort/guardian' (RED/BLUE), 'hostapd', 'wio', 'QoS', and 'privoxy'.
>>
>> Overall performance seems to be a bit faster. We'll see.
>>
>> Furthermore, while searching I found this 'squid-nabble' diskussion:
>>
>> http://squid-web-proxy-cache.1019090.n4.nabble.com/Squid-4-Development-Blog-td
>> 4684900.html
>>
>> ***SNIP***
>> On 25/02/18 06:26, Chase Wright wrote:
>> > It's been nearly 2 years since there was a blog post about Squid 4.x
>> > and I've noticed that the daily auto-generated Squid 3.5 stable branch
>> > release last updated on "08 Dec 2017"
>> >
>> > I've also noticed that the last two CVEs were only fixed in the 4.x
>> > branch (2018)
>> >
>> > Is the squid team planning to move 4.x to stable soon?
>> >
>>
>> "Soon" yes. Those last few bugs proved to be extremely painful and slow
>> to get fixed.
>>
>> As of today we have one major bug unfixed, and some testing needed for
>> checking the stability of the recent huge fixes. I'm just waiting on the
>> backports of some small regressions already found before the next v4
>> beta package.
>>
>> I am *hoping* not to have to release any more 3.5 packages. But that of
>> course depends on what the timeline this final bug turns into.
>>
>> Amos
>> ***SNAP***
>>
>> Best,
>> Matthias
>>
>> On 10.03.2018 12:22, Matthias Fischer wrote:
>> > Hi,
>> >
>> > Found something...but since I don't have much experience with this:
>> >
>> > What impact is to be expected when I translate 'squid 4.0.24' with the
>> > configure option '--without-netfilter-conntrack'?
>> >
>> > Help says:
>> > "--without-netfilter-conntrack
>> > Do not use Netfilter conntrack libraries for packet marking. A path to
>> > alternative library location may be specified by using
>> > --with-netfilter-conntrack=PATH.
>> > Default: auto-detect."
>> >
>> > I didn't find any further or helpful informations about the
>> > (side-)effects when I turn this off.
>> >
>> > Best,
>> > Matthias
>> >
>> > On 22.01.2018 14:30, Michael Tremer wrote:
>> > > Okay, please keep an eye on squid 4 for us then. I am not following this
>> > > very
>> > > closely and have no idea what will change in squid 4.
>> > >
>> > > Best,
>> > > -Michael
>> > >
>> > > On Sun, 2018-01-21 at 21:35 +0100, Matthias Fischer wrote:
>> > > > On 21.01.2018 19:57, Michael Tremer wrote:
>> > > > > Hello,
>> > > > >
>> > > > > yes this is correct.
>> > > > >
>> > > > > We don't allow an unprivileged user to load any kernel modules.
>> > > >
>> > > > Ok, then my suspicion was right.
>> > > >
>> > > > > What does squid need this for? Why are you playing around with squid
>> > > > > 4?
>> > > >
>> > > > 1. I don't know. 3.5.27 doesn't do this.
>> > > > 2. As I wrote - just to keep in touch with their development. Once in a
>> > > > while, 'squid 3' will be deprecated and I wanted to see what comes next,
>> > > > even though this may take a long time. Just being curious and the
>> > > > 'Devel' was somehow bored. ;-)
>> > > >
>> > > > > You should be able to load the module first and then start squid.
>> > > >
>> > > > I'm not that curious - this was for testing and for testing only.
>> > > >
>> > > > Best,
>> > > > Matthias
>> > > >
>> > > > > Best,
>> > > > > -Michael
>> > > > >
>> > > > > On Sun, 2018-01-21 at 01:50 +0100, Matthias Fischer wrote:
>> > > > > > Hi,
>> > > > > >
>> > > > > > Just to keep in touch, I tested 'squid 4.0.23' yesterday - it seemed
>> > > > > > to
>> > > > > > run fine at first. But after a while I took a closer look at the
>> > > > > > logs
>> > > > > > and discovered a bunch of kernel messages within a few hours and I
>> > > > > > don't
>> > > > > > know what exactly triggered these messages:
>> > > > > >
>> > > > > > ...
>> > > > > > 132 Time(s): grsec: denied kernel module auto-load of
>> > > > > > nf_conntrack_netlink by uid 23
>> > > > > > ...
>> > > > > >
>> > > > > > As far as I found out: "uid 23" => squid-user, and the new squid
>> > > > > > tried
>> > > > > > to 'autoload' a module which 'grsec' didn't like. Is this a correct
>> > > > > > interpretation and has anyone some useable clue how to avoid this?
>> > > > > >
>> > > > > > Besides, after going back to '3.5.27' the messages didn't came back
>> > > > > > again. '4.0.22' didn't throw these messages, too. They changed
>> > > > > > something
>> > > > > > and I don't know what it is...
>> > > > > >
>> > > > > > Thanks for all tips!
>> > > > > >
>> > > > > > Best,
>> > > > > > Matthias
>> >
>> >
>>
>>
>
next prev parent reply other threads:[~2018-03-11 14:44 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-01-21 0:50 Testing squid 4.0.23 - grsec denied kernel module auto-load of nf_conntrack_netlink by uid 23 Matthias Fischer
2018-01-21 18:57 ` Michael Tremer
2018-01-21 20:35 ` Matthias Fischer
2018-01-22 13:30 ` Michael Tremer
2018-03-10 11:22 ` Matthias Fischer
2018-03-11 10:20 ` Testing 'squid 4.0.24' (was: Re: Testing squid 4.0.23 - grsec denied kernel module auto-load of nf_conntrack_netlink by uid 23) Matthias Fischer
2018-03-11 13:05 ` Michael Tremer
2018-03-11 14:44 ` Matthias Fischer [this message]
2018-03-10 8:12 ` Testing squid 4.0.23 - grsec denied kernel module auto-load of nf_conntrack_netlink by uid 23 Matthias Fischer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ae498d4e-ac4f-f273-4ed8-c12fab79425a@ipfire.org \
--to=matthias.fischer@ipfire.org \
--cc=development@lists.ipfire.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox