Re: Core Update 159 Testing release feedback

Re: Core Update 159 Testing release feedback

[Michael Tremer]

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

Hello,

> On 10 Aug 2021, at 10:07, Adolf Belka <adolf.belka(a)ipfire.org> wrote:
> 
> Hi All,
> 
> 
> 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.
> 
> There are only two items that I have found/experienced that need to be mentioned.
> 
> On the Update accelerator configuration page the box to enter the Max. disk 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 the box is large enough to have three digits visible.
> 
> 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 isn’t severe enough to block the release.

> 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 resource" message. Reloading IPFire and accessing the pakfire screen showed that the 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 136388505986048] (13)Permission denied: AH01241: exec of '/srv/web/ipfire/cgi-bin/speed.cgi' failed
> [Wed Aug 04 23:38:36.327180 2021] [cgid:error] [pid 4066:tid 136388483823168] [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 136388475430464] (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 136388467037760] (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.

We need to explore what we can do about this. It is harmless in this case, but it looks ugly and is confusing.

I suppose the changes that we have made in the extraction routine do not improve anything. Should we try to revert tar?

-Michael

> 
> 
> Regards,
> 
> Adolf.
> 
> <Update Accelerator screen.png><Forbidden error message.png>

Re: Core Update 159 Testing release feedback

[Adolf Belka]

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

Hi Michael,

On 11/08/2021 11:49, Michael Tremer wrote:
> Hello,
> 
>> On 10 Aug 2021, at 10:07, Adolf Belka <adolf.belka(a)ipfire.org> wrote:
>>
>> Hi All,
>>
>>
>> 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.
>>
>> There are only two items that I have found/experienced that need to be mentioned.
>>
>> On the Update accelerator configuration page the box to enter the Max. disk 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 the box is large enough to have three digits visible.
>>
>> 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 isn’t 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 resource" message. Reloading IPFire and accessing the pakfire screen showed that the 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 136388505986048] (13)Permission denied: AH01241: exec of '/srv/web/ipfire/cgi-bin/speed.cgi' failed
>> [Wed Aug 04 23:38:36.327180 2021] [cgid:error] [pid 4066:tid 136388483823168] [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 136388475430464] (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 136388467037760] (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.
> 
> 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.
> 
> I suppose the changes that we have made in the extraction routine do not improve anything. Should we try to revert tar?
Do you mean revert tar to before the issues that gave us the permissions problems 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 reversion. Which version of tar are we confident in?

Regards,
Adolf.
> 
> -Michael
> 
>>
>>
>> Regards,
>>
>> Adolf.
>>
>> <Update Accelerator screen.png><Forbidden error message.png>
> 

Re: Core Update 159 Testing release feedback

[Michael Tremer]

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

Hello,

> On 11 Aug 2021, at 12:34, Adolf Belka <adolf.belka(a)ipfire.org> wrote:
> 
> Hi Michael,
> 
> On 11/08/2021 11:49, Michael Tremer wrote:
>> Hello,
>>> On 10 Aug 2021, at 10:07, Adolf Belka <adolf.belka(a)ipfire.org> wrote:
>>> 
>>> Hi All,
>>> 
>>> 
>>> 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.
>>> 
>>> There are only two items that I have found/experienced that need to be mentioned.
>>> 
>>> On the Update accelerator configuration page the box to enter the Max. disk 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 the box is large enough to have three digits visible.
>>> 
>>> 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 isn’t 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 resource" message. Reloading IPFire and accessing the pakfire screen showed that the 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 136388505986048] (13)Permission denied: AH01241: exec of '/srv/web/ipfire/cgi-bin/speed.cgi' failed
>>> [Wed Aug 04 23:38:36.327180 2021] [cgid:error] [pid 4066:tid 136388483823168] [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 136388475430464] (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 136388467037760] (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’t work because tar takes long enough that a refresh 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 improve anything. Should we try to revert tar?
> Do you mean revert tar to before the issues that gave us the permissions problems 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 reversion. Which version of tar are we confident in?

That is the question. We didn’t touch tar in a while, so I am not 100% confident that these problems are caused by it. We have also rolled out changes which should have changed tar’s behaviour which they didn’t.

I do not have much time to investigate this at the moment. Does anybody else have a moment to look into this?

-Michael

> 
> Regards,
> Adolf.
>> -Michael
>>> 
>>> 
>>> Regards,
>>> 
>>> Adolf.
>>> 
>>> <Update Accelerator screen.png><Forbidden error message.png>