public inbox for development@lists.ipfire.org
 help / color / mirror / Atom feed
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
>> > 
>> > 
>> 
>> 
> 


  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