From mboxrd@z Thu Jan 1 00:00:00 1970 From: Adolf Belka To: development@lists.ipfire.org Subject: Re: Core Update 159 Testing release feedback Date: Wed, 11 Aug 2021 13:34:07 +0200 Message-ID: <4b48b64b-3de3-5dd2-5b97-e1ccf0c1b9b0@ipfire.org> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2515511492033018427==" List-Id: --===============2515511492033018427== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi Michael, On 11/08/2021 11:49, Michael Tremer wrote: > Hello, >=20 >> On 10 Aug 2021, at 10:07, Adolf Belka wrote: >> >> Hi All, >> >> >> I have had my Core Update 159 Testing release running for a while now on m= y vm testbed and generally everything continues to run well on it. >> >> There are only two items that I have found/experienced that need to be men= tioned. >> >> On the Update accelerator configuration page the box to enter the Max. dis= k usage: in has shrunk to only one digit wide. The attached screen shot shows= the box with a 5 in it but the number is actually 50. You can use the cursor= to move the number along but then you will only see 0. In Core Update 158 th= e box is large enough to have three digits visible. >> >> I will raise a bug in bugzilla for this. >=20 > 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 is= n=E2=80=99t severe enough to block the release. Definitely not severe enough to block the release and Leo has found the fix a= nyway. >=20 >> The other item occurred when I upgraded from 158 to 159. Partway through t= he upgrade I got a "Forbidden You don't have permission to access this resour= ce" message. Reloading IPFire and accessing the pakfire screen showed that th= e upgrade had been completed. Nothing like this happened since. The following= error message was in the httpd/error_log >> >> >> [Wed Aug 04 23:38:36.327035 2021] [cgid:error] [pid 4961:tid 1363885059860= 48] (13)Permission denied: AH01241: exec of '/srv/web/ipfire/cgi-bin/speed.cg= i' failed >> [Wed Aug 04 23:38:36.327180 2021] [cgid:error] [pid 4066:tid 1363884838231= 68] [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 1363884754304= 64] (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 1363884670377= 60] (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 o= f the path, referer: https://ipfire:444/ >=20 > Yes, I can confirm this. This is tar changing permissions of directories. I= t is kind of bad because problems become user-visible through this. That makes sense with the permissions correction that was added just to be ce= rtain. >=20 > 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 wi= ll make a big thing about it. >=20 > I suppose the changes that we have made in the extraction routine do not im= prove anything. Should we try to revert tar? Do you mean revert tar to before the issues that gave us the permissions prob= lems that some people experienced with 158? It might make sense but it also d= epends on what improvements we no longer have from tar by doing that reversio= n. Which version of tar are we confident in? Regards, Adolf. >=20 > -Michael >=20 >> >> >> Regards, >> >> Adolf. >> >> >=20 --===============2515511492033018427==--