From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michael Tremer To: development@lists.ipfire.org Subject: Re: Core Update 159 Testing release feedback Date: Thu, 12 Aug 2021 10:36:55 +0100 Message-ID: In-Reply-To: <4b48b64b-3de3-5dd2-5b97-e1ccf0c1b9b0@ipfire.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1401549023264085424==" List-Id: --===============1401549023264085424== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hello, > On 11 Aug 2021, at 12:34, Adolf Belka wrote: >=20 > Hi Michael, >=20 > On 11/08/2021 11:49, Michael Tremer wrote: >> Hello, >>> On 10 Aug 2021, at 10:07, Adolf Belka wrote: >>>=20 >>> Hi All, >>>=20 >>>=20 >>> I have had my Core Update 159 Testing release running for a while now on = my vm testbed and generally everything continues to run well on it. >>>=20 >>> There are only two items that I have found/experienced that need to be me= ntioned. >>>=20 >>> On the Update accelerator configuration page the box to enter the Max. di= sk usage: in has shrunk to only one digit wide. The attached screen shot show= s the box with a 5 in it but the number is actually 50. You can use the curso= r to move the number along but then you will only see 0. In Core Update 158 t= he box is large enough to have three digits visible. >>>=20 >>> I will raise a bug in bugzilla for this. >> Thank you. I do not remember that this code was touched recently (it might= be a change in how the browser renders the page). I would assume that this i= sn=E2=80=99t severe enough to block the release. > Definitely not severe enough to block the release and Leo has found the fix= anyway. >>> The other item occurred when I upgraded from 158 to 159. Partway through = the upgrade I got a "Forbidden You don't have permission to access this resou= rce" message. Reloading IPFire and accessing the pakfire screen showed that t= he upgrade had been completed. Nothing like this happened since. The followin= g error message was in the httpd/error_log >>>=20 >>>=20 >>> [Wed Aug 04 23:38:36.327035 2021] [cgid:error] [pid 4961:tid 136388505986= 048] (13)Permission denied: AH01241: exec of '/srv/web/ipfire/cgi-bin/speed.c= gi' failed >>> [Wed Aug 04 23:38:36.327180 2021] [cgid:error] [pid 4066:tid 136388483823= 168] [client 192.168.111.97:33232] End of script output before headers: speed= .cgi, referer: https://ipfire:444/ >>> [Wed Aug 04 23:38:38.319827 2021] [core:error] [pid 4066:tid 136388475430= 464] (13)Permission denied: [client 192.168.111.97:33234] AH00035: access to = /cgi-bin/speed.cgi denied (filesystem >>> path '/srv/web') because search permissions are missing on a component of= the path, referer: https://ipfire:444/ >>> [Wed Aug 04 23:38:38.915986 2021] [core:error] [pid 4066:tid 136388467037= 760] (13)Permission denied: [client 192.168.111.97:33234] AH00035: access to = /cgi-bin/pakfire.cgi denied (filesyste >>> m path '/srv/web') because search permissions are missing on a component = of the path, referer: https://ipfire:444/ >> Yes, I can confirm this. This is tar changing permissions of directories. = It is kind of bad because problems become user-visible through this. > That makes sense with the permissions correction that was added just to be = certain. Well, it still doesn=E2=80=99t work because tar takes long enough that a refr= esh of the page might happen which will then fail. >> We need to explore what we can do about this. It is harmless in this case,= but it looks ugly and is confusing. > It does look a bit ugly and there will definitely be some of the users who = will make a big thing about it. As usual :) >> I suppose the changes that we have made in the extraction routine do not i= mprove anything. Should we try to revert tar? > Do you mean revert tar to before the issues that gave us the permissions pr= oblems that some people experienced with 158? It might make sense but it also= depends on what improvements we no longer have from tar by doing that revers= ion. Which version of tar are we confident in? That is the question. We didn=E2=80=99t touch tar in a while, so I am not 100= % confident that these problems are caused by it. We have also rolled out cha= nges which should have changed tar=E2=80=99s behaviour which they didn=E2=80= =99t. I do not have much time to investigate this at the moment. Does anybody else = have a moment to look into this? -Michael >=20 > Regards, > Adolf. >> -Michael >>>=20 >>>=20 >>> Regards, >>>=20 >>> Adolf. >>>=20 >>> --===============1401549023264085424==--