From mboxrd@z Thu Jan  1 00:00:00 1970
From: Michael Tremer <michael.tremer@ipfire.org>
To: development@lists.ipfire.org
Subject: Re: Core Update 165 (testing) report
Date: Mon, 21 Mar 2022 16:05:12 +0000
Message-ID: <607D75F7-00F5-472C-8BE8-4162895B4147@ipfire.org>
In-Reply-To: <bfe58b51-1640-d048-9dca-bbb43a574863@ipfire.org>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============7458305960748930124=="
List-Id: <development.lists.ipfire.org>

--===============7458305960748930124==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable

Hello,

> On 20 Mar 2022, at 10:35, Peter M=C3=BCller <peter.mueller(a)ipfire.org> wr=
ote:
>=20
> Hello development folks,
>=20
> Core Update 165 (testing, see: https://blog.ipfire.org/post/ipfire-2-27-cor=
e-update-165-is-available-for-testing)
> is running here for roughly a day, with some minor and one major issue(s) s=
potted so far.
>=20
> While installing the update went smooth (the improved Pakfire GUI is really=
 nice - thanks
> again to Leo!), I bumped into some IPS-related trouble afterwards: Network =
connections timed
> out frequently, no matter whether they were directed to IPFire itself or no=
t, and the GUI
> (especially the graphs) took ages to load, if at all.

This is a worry to me and should not happen.

> Stopping the IPS and starting it again via the GUI solved the problem - I b=
elieve we should
> do this in the update.sh script, but am not sure if there are cross-depende=
ncies to something
> else. There is no bug raised for this yet.

This is even a bigger worry, because the IPS should not do this kind of stuff.

> Also, I noticed Squid was not restarted during the update, which caused tro=
uble until I
> ran "/etc/init.d/squid restart" manually. Bug #12810 has been filed for thi=
s, and I just
> submitted a patch fixing this a few minutes ago.
>=20
> Since my IPFire machine is rebooting every night via a scheduled job, I usu=
ally do not
> conduct a manual reboot immediately after installing an update. This time, =
I felt it was a
> good thing to do.

Do people still do scheduled reboots?

> Afterwards, Tor would not start again unless I disabled the "sandbox" featu=
re manually. I
> believe this is not a general problem, but due to the fact that we did not =
ship libseccomp.
> Bug #12807 has been filed for this.

Thank you. Merged.

> Today (i. e. another reboot later), I noticed charon emitting some iptables=
 warnings while
> establishing an IPsec connection (filed as bug #12808), and, more important=
, some location-
> based firewall rules not being properly loaded, which rendered DDNS - and s=
ubsequently IPsec
> and OpenVPN - useless for me, since I am getting IP addresses assigned dyna=
mically.

Do you have more details on this? Do you believe the two problems are related?

> Bug #12809 has been filed for the latter, and I believe this is a show-stop=
per. Oddly enough,
> it did not appear after the first reboot, and _some_ location-based firewal=
l rules were loaded
> correctly after the second one. Manually reloading the rules via the GUI "s=
olved" the problem
> for now, but this is definitely something we need to have a look at before =
releasing C165.
>=20
> Apart from these, things look good to me. 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)
> - Dynamic DNS
> - Tor (relay mode)
>=20
> Thanks, and best regards,
> Peter M=C3=BCller

-Michael

--===============7458305960748930124==--