Comment 1 Christian Völker 2020-11-03 14:03:00 CET

Interesting:

When running univention-app update shortly after the failure the request just downloads fine!

Comment 2 Christian Völker 2020-11-03 14:04:47 CET

could reproduce.

Remote the cache as above, trying to update will end in failure, running update again will succeed!

Comment 3 Ingo Steuwer 2020-11-06 11:56:44 CET

Am I right that this fails in the first attempt but works later, right? And it happens only if the App Center cache data is deleted, which normally should'n happen, right?

I change the "How will those affected feel about the bug" and "What type of bug is this?" based on these assumptions.

Comment 4 Christina Scheinig 2020-11-06 15:59:41 CET

For the customer, switching off the proxy for the hosts of Univention and allow the UCS hosts (possibly only temporarily) direct Internet access, is no option.

They would like to deactivate the update test, till this bug is fixed.

Is there a possibility to deactivate this univention-app update test, which seems to be the problem, because the cache is never up to date, with the proxy activated.

Comment 5 Ingo Steuwer 2020-11-06 16:13:04 CET

(In reply to Ingo Steuwer from comment #3)
> Am I right that this fails in the first attempt but works later, right? And
> it happens only if the App Center cache data is deleted, which normally
> should'n happen, right?
> 
> I change the "How will those affected feel about the bug" and "What type of
> bug is this?" based on these assumptions.

I set "Needmoreinfo" as I don't understand the consequences for the customer.

Comment 6 Christina Scheinig 2020-11-06 17:05:56 CET

So the customer described the issue as follows:

"The UCS systems try to pull an update. The proxy and the FW allow this. But the UCS systems ALWAYS request the same file without any progress. This puts so much load on the proxy that it can hardly perform any other actions, while at the same time a lot of logs are written by the proxy. ( > 2 Mio in a few minutes )"

Some update check routine makes a zsync. For example:

zsync http://appcenter.software-univention.de/meta-inf/4.4/all.tar.zsync -q -o /var/cache/univention-appcenter/appcenter.software-univention.de/4.4/.all.tar

This is executed but never stopped or not finished for days, making the UCS millions of accesses to the proxy.

Does this description help?
So for the customer, I suppose, it blocks further progress of the daily work.

Comment 7 Ingo Steuwer 2020-11-09 09:53:21 CET

(In reply to Christina Scheinig from comment #6)
> So the customer described the issue as follows:
> 
> "The UCS systems try to pull an update. The proxy and the FW allow this. But
> the UCS systems ALWAYS request the same file without any progress. This puts
> so much load on the proxy that it can hardly perform any other actions,
> while at the same time a lot of logs are written by the proxy. ( > 2 Mio in
> a few minutes )"
> 
> Some update check routine makes a zsync. For example:
> 
> zsync http://appcenter.software-univention.de/meta-inf/4.4/all.tar.zsync -q
> -o
> /var/cache/univention-appcenter/appcenter.software-univention.de/4.4/.all.tar
> 
> This is executed but never stopped or not finished for days, making the UCS
> millions of accesses to the proxy.
> 
> Does this description help?
> So for the customer, I suppose, it blocks further progress of the daily work.

mhm, sounds more like a problem in the proxy or its configuration?

Comment 9 Christina Scheinig 2020-11-09 11:52:56 CET

(In reply to Ingo Steuwer from comment #7)
> (In reply to Christina Scheinig from comment #6)
> > So the customer described the issue as follows:
> > 
> > "The UCS systems try to pull an update. The proxy and the FW allow this. But
> > the UCS systems ALWAYS request the same file without any progress. This puts
> > so much load on the proxy that it can hardly perform any other actions,
> > while at the same time a lot of logs are written by the proxy. ( > 2 Mio in
> > a few minutes )"
> > 
> > Some update check routine makes a zsync. For example:
> > 
> > zsync http://appcenter.software-univention.de/meta-inf/4.4/all.tar.zsync -q
> > -o
> > /var/cache/univention-appcenter/appcenter.software-univention.de/4.4/.all.tar
> > 
> > This is executed but never stopped or not finished for days, making the UCS
> > millions of accesses to the proxy.
> > 
> > Does this description help?
> > So for the customer, I suppose, it blocks further progress of the daily work.
> 
> mhm, sounds more like a problem in the proxy or its configuration?

I don't understand. afais Christian reproduced the issue, in his testenvironment, so why it is now a misconfiguration of the customers proxy?

Comment 10 Ingo Steuwer 2020-11-09 16:15:35 CET

(In reply to Christina Scheinig from comment #9)
> > 
> > mhm, sounds more like a problem in the proxy or its configuration?
> 
> I don't understand. afais Christian reproduced the issue, in his
> testenvironment, so why it is now a misconfiguration of the customers proxy?

Seems like we need to remove misunderstandings. My point was:

1. there are two tickets linked, based on a discussion with Dirk the ticket  2020102921000109 which I had a look at might not related to this bug. In this ticket it is written that the proxy configuration of the customer is suspected to cause the issues, not a bug in UCS.

2. the documented way to reproduce this issue is "Remove the cache as above, trying to update will end in failure, running update again will succeed!" which I understand as (deliberately exaggerated):
- I intentionally break the UCS System
- at first I have trouble in the component
- but in the end everything is fine and fixes it by itself

So, the main question for me is: How is the behaviour of the UCS App Center in case it is running behind a full functional proxy?

Comment 11 Christian Völker 2020-11-30 12:32:42 CET

(In reply to Ingo Steuwer from comment #10)


At first, cleaning a cache is NOT "breaking a system". Any system using a cache should work flawlessly when the cache is empty or not existing!
How about systems being installed and thus not having such a cache? They will fail...

Second, you are right, it fixes itself when manually restarting the process. Which does not happen when the update is triggered by UMC, udm, cron or whatever other way. Any following attempt still fails then. It fixes itself only when doing it again (ie for testing purpose) manually on shell.

Third, as already written the behavior is seen in an ucs-only environment with no special configurations of the Squid proxy. 

If this is a proxy issue it is a product issue, too.

Comment 12 Ingo Steuwer 2020-11-30 20:41:02 CET

(In reply to Christian Völker from comment #11)

thanks a lot for the clarification:

> (In reply to Ingo Steuwer from comment #10)
> 
> 
> At first, cleaning a cache is NOT "breaking a system". Any system using a
> cache should work flawlessly when the cache is empty or not existing!
> How about systems being installed and thus not having such a cache? They
> will fail...

yes, caches might be deleted and systems should handle that. I was refering to the warning/error messages seen - it is OK for me that a system gives some error message in case expected cache files are missing.

> 
> Second, you are right, it fixes itself when manually restarting the process.
> Which does not happen when the update is triggered by UMC, udm, cron or
> whatever other way. Any following attempt still fails then. It fixes itself
> only when doing it again (ie for testing purpose) manually on shell.

OK, so to summarize the situation:
- everything is fine while using appcenter command line tools
- cache updates and maybe further steps fail for web interface interaction with the App Center -> this is a bug
 
> Third, as already written the behavior is seen in an ucs-only environment
> with no special configurations of the Squid proxy. 
> 
> If this is a proxy issue it is a product issue, too.

I was referring to the support ticket, where the customer reports that the proxy gets unusable / unresponsive by requests send by the App Center; and in that environment the App Center reports invalid / no responses from the proxy. For me that is a bug in the proxy configuration / implementation and not in UCS.

Comment 13 Christian Völker 2020-11-30 22:45:45 CET

(In reply to Ingo Steuwer from comment #12)

> OK, so to summarize the situation:
> - everything is fine while using appcenter command line tools
I am unsure about this- it prints loads of error messaages but I do not know if it does what it should do!

> - cache updates and maybe further steps fail for web interface interaction
> with the App Center -> this is a bug
Which might be related to the above error messages.

> I was referring to the support ticket, where the customer reports that the
> proxy gets unusable / unresponsive by requests send by the App Center; and
> in that environment the App Center reports invalid / no responses from the
> proxy. For me that is a bug in the proxy configuration / implementation and
> not in UCS.
Well, if the proxy does not handle these requests properly it is indeed not an issue of UCS. But the bug here is univention-app does not work properly with a default proxy (the one configured in UCS@school by default).

So the bug is:
univention-app does not deal properly when using a proxy (configured in default way on UCS). Symptoms are:
-from UMC hanging and/or failing processes
-from command line error messages related to zsync