public inbox for development@lists.ipfire.org
 help / color / mirror / Atom feed
From: "Peter Müller" <peter.mueller@ipfire.org>
To: development@lists.ipfire.org
Subject: Core Update 158 (testing) report
Date: Mon, 05 Jul 2021 19:53:37 +0200	[thread overview]
Message-ID: <7b0dd02a-b899-5fff-2907-293605136f21@ipfire.org> (raw)
In-Reply-To: <c873ba81-003c-ae9c-4297-bbc4fbe3646f@ipfire.org>

[-- Attachment #1: Type: text/plain, Size: 2825 bytes --]

Hello *,

Core Update 158 (testing, see: https://blog.ipfire.org/post/ipfire-2-25-core-update-158-available-for-testing)
is running here for about 24 hours by now. It introduced some minor issues during the update itself, and apparently
brought back a quite annoying behaviour where VoIP calls sometimes cannot be established:

(a) The update script once again appears to be missing a "/usr/local/bin/sshctrl" - this is starting to get a
    bit embarrassing, but I guess its a good thing to be discovered while still being in QA. :-)

(b) On my testing machine, installing the update required two attempts of running Pakfire, while the Core Updates
    before went through straight-away (unless memories fail me). Not really a show-stopper, but a noticeable
    thing.

    No offense intended, but the update took relatively long on my machine, occasionally returning 403's when
    refreshing the Pakfire CGI, but went all fine in the end. I guess it is a good idea not to undergo this during
    production hours, but within a scheduled maintenance window.

(c) For quite some time, I suffered from VoIP calls not being established properly, as described in
    https://lists.ipfire.org/pipermail/development/2021-March/009656.html a while ago. I unfortunately never
    caught the root cause for this, but blamed an error somewhere in the Linux kernel. Bug #12563 sounds pretty
    related.

    After upgrading all IPFire machines to Core Update 157, the problem disappeared (and I was happy). Surprisingly,
    it reappeared at least once after having upgraded _one_ system to Core Update 158.

    Since we did not ship a kernel in C158, this rules out Linux being the sole root cause for this. I am starting
    to blame pppd as well, as it is the only piece of software changed in C158 that smells relevant to me. On the
    other hand, this would have meant we suffer from this since March 2020 at least, where we successfully updated
    pppd the last time (https://blog.ipfire.org/post/ipfire-2-25-core-update-142-released).

    Anyway: I will investigate, _finally_ try to get meaningful traces of it, and report back. I do not want to
    lose my functioning VoIP calls. :-)

I did not experience any issues while working with the CGIs so far. Stefans' and Michaels' endless efforts of squashing 
out bug #12616 seemed to be quite successful without breaking anything.

Tested IPFire functionalities in detail:
- IPsec (N2N connections only)
- Squid (authentication enabled, using an upstream proxy)
- OpenVPN (RW connections only)
- IPS/Suricata (with Emerging Threats community ruleset enabled)
- Guardian
- Quality of Service
- DNS (using DNS over TLS and strict QNAME minimisation)
- Dynamic DNS
- Tor (relay mode)

Thanks, and best regards,
Peter Müller

      parent reply	other threads:[~2021-07-05 17:53 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-02 13:50 Core 158 Testing feedback Adolf Belka
2021-07-02 14:46 ` Michael Tremer
2021-07-05 17:53 ` Peter Müller [this message]

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=7b0dd02a-b899-5fff-2907-293605136f21@ipfire.org \
    --to=peter.mueller@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