<div dir="ltr"><div dir="ltr">On Tue, Feb 8, 2022 at 4:24 AM Aleix Pol <<a href="mailto:aleixpol@kde.org">aleixpol@kde.org</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Sat, Feb 5, 2022 at 10:16 PM Ben Cooksley <<a href="mailto:bcooksley@kde.org" target="_blank">bcooksley@kde.org</a>> wrote:<br>
><br>
> Hi all,<br>
><br>
> Over the past week or so Sysadmin has been dealing with an extremely high volume of traffic directed towards both <a href="http://download.kde.org" rel="noreferrer" target="_blank">download.kde.org</a> and <a href="http://distribute.kde.org" rel="noreferrer" target="_blank">distribute.kde.org</a>.<br>
><br>
> This traffic volume is curious in so far that it is directed at two paths specifically:<br>
> - <a href="http://distribute.kde.org/khotnewstuff/fonts-providers.xml" rel="noreferrer" target="_blank">distribute.kde.org/khotnewstuff/fonts-providers.xml</a><br>
> - <a href="http://download.kde.org/ocs/providers.xml" rel="noreferrer" target="_blank">download.kde.org/ocs/providers.xml</a><br>
><br>
> The first path is an "internal only" host which we were redirecting a legacy path to prior to the resource being relocated to <a href="http://cdn.kde.org" rel="noreferrer" target="_blank">cdn.kde.org</a>. The second path has been legacy for numerous years now (more than 5) and is replaced by <a href="http://autoconfig.kde.org" rel="noreferrer" target="_blank">autoconfig.kde.org</a>.<br>
> It is of extreme concern that these paths are still in use - especially the ocs/providers.xml one.<br>
><br>
> The volume of traffic has reached an extent that to prevent the server disk filling up we have had to disable logging for those two sites. Whilst dependent on the time of day the server is currently dealing with the current volume of requests, which is far outside normal specifications:<br>
><br>
> <dt>555 requests/sec - 4.5 MB/second - 8.3 kB/request - .739199 ms/request</dt><br>
><br>
> Analysis of a fragment of logs (comprising just a few minutes of traffic) reveals the following:<br>
><br>
>      63 "GET /ocs/providers.xml HTTP/1.1" 301 6585 "-" "KNewStuff/5.89.0-discoverupdate/5.23.5"<br>
>      64 "GET /ocs/providers.xml HTTP/1.1" 301 6585 "-" "KNewStuff/5.89.0-discoverupdate/5.23.4"<br>
>     104 "GET /ocs/providers.xml HTTP/1.1" 301 6585 "-" "KNewStuff/5.90.0-discoverupdate/5.23.90"<br>
>     105 "GET /ocs/providers.xml HTTP/1.1" 301 6585 "-" "KNewStuff/5.88.0-discoverupdate/5.23.5"<br>
>    1169 "GET /ocs/providers.xml HTTP/1.1" 301 6585 "-" "KNewStuff/5.86.0-plasma-discover-update/"<br>
>    1256 "GET /ocs/providers.xml HTTP/1.1" 301 6585 "-" "KNewStuff/5.90.0-discoverupdate/5.23.5"<br>
>    2905 "GET /ocs/providers.xml HTTP/1.1" 301 6585 "-" "Mozilla/5.0"<br>
><br>
>      86 "GET /khotnewstuff/fonts-providers.xml HTTP/1.1" 200 6773 "-" "Mozilla/5.0"<br>
>     130 "GET /khotnewstuff/fonts-providers.xml HTTP/1.1" 304 6132 "-" "KNewStuff/5.89.0-discoverupdate/5.23.5"<br>
>     136 "GET /khotnewstuff/fonts-providers.xml HTTP/1.1" 304 6132 "-" "KNewStuff/5.89.0-discoverupdate/5.23.4"<br>
>     197 "GET /khotnewstuff/fonts-providers.xml HTTP/1.1" 304 6132 "-" "KNewStuff/5.88.0-discoverupdate/5.23.5"<br>
>     199 "GET /khotnewstuff/fonts-providers.xml HTTP/1.1" 304 6132 "-" "KNewStuff/5.90.0-discoverupdate/5.23.90"<br>
>    2624 "GET /khotnewstuff/fonts-providers.xml HTTP/1.1" 304 6132 "-" "KNewStuff/5.86.0-plasma-discover-update/"<br>
>    2642 "GET /khotnewstuff/fonts-providers.xml HTTP/1.1" 304 6132 "-" "KNewStuff/5.90.0-discoverupdate/5.23.5"<br>
>    6117 "GET /khotnewstuff/fonts-providers.xml HTTP/1.1" 304 6132 "-" "Mozilla/5.0"<br>
><br>
> This indicates that the bug lies solely within Plasma's Discover component - more precisely it's updater.<br>
><br>
> Examining the origin of these requests has indicated that some clients are making requests to these paths well in excess of several times a minute with a number of IP addresses appearing more 60 times in a 1 minute sized sample window.<br>
><br>
> Given that Sysadmin has raised issues with this component and it's behaviour in the past, it appears that issues regarding the behaviour of the OCS componentry within Discover remain unresolved.<br>
><br>
> Due to the level of distress this is causing our systems, I am therefore left with no other option other than to direct the Plasma Discover developers to create and release without delay patches for all versions in support, as well as for all those currently present in any actively maintained distributions, that disable all OCS functionality in the Discover updater. Distributions are requested to treat these patches as security patches and to distribute them to users without delay.<br>
><br>
> In 24 hours time Sysadmin will be making a posting to kde-announce requesting that users immediately cease use of the Discover update client as it is creating a Denial of Service attack on our infrastructure.<br>
<br>
I feel like your response here is out of proportion.<br>
<br>
Last time we had this conversation, my impression was that the problem<br>
was addressed for the most part. If you wanted people working on<br>
KNewStuff, Attica or OCS to take any actions, we needed to at the very<br>
least have information about you are complaining before you burst out<br>
into mailing lists and the likes.<br></blockquote><div><br></div><div>Based on the information I had to hand back in September it was solved yes.</div><div>Our server monitoring system indicated that this issue did not exist back in September - so this is new, although in the same Discover code.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
In terms of actual solutions this in would probably help to some<br>
extent. We never merged it because it's not great design but good<br>
results is more important than good design. At the moment they're in<br>
their way in but it will take time until it hits users.<br>
<a href="https://invent.kde.org/frameworks/knewstuff/-/merge_requests/141/" rel="noreferrer" target="_blank">https://invent.kde.org/frameworks/knewstuff/-/merge_requests/141/</a><br>
<a href="https://invent.kde.org/plasma/discover/-/merge_requests/165/" rel="noreferrer" target="_blank">https://invent.kde.org/plasma/discover/-/merge_requests/165/</a></blockquote><div><br></div><div>Yes, the delay in rolling stuff out to users is always the biggest pain point.</div><div><br></div><div>That is partly why the fixes process should include bug fixes to previously released versions we can ask distributions to pick up.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
<br>
These were of course not the only mitigation solutions put into place<br>
back then. In fact many of them were geared towards giving more<br>
information about what was happening and I've still to get any<br>
feedback there. Without information it's impossible that we can take<br>
any solutions.<br></blockquote><div><br></div><div>Correct, and that appears to have borne results as noted in the user agent extracts I provided above.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
For what it's worth, I looked into what was happening within Qt and<br>
indeed using <a href="http://download.kde.org" rel="noreferrer" target="_blank">download.kde.org</a> instead of <a href="http://autoconfig.kde.org" rel="noreferrer" target="_blank">autoconfig.kde.org</a> is not<br>
hitting the cache paths. If this is something that worries us, maybe<br>
we should put together tools that help us detect this kind of problems<br>
as exploding in here does nothing to helpthis issue, only stresses<br>
people out. Personally, I found very demotivating how the problem was<br>
presented once again.<br></blockquote><div><br></div><div>That would certainly explain why <a href="http://download.kde.org">download.kde.org</a> is getting hammered while <a href="http://autoconfig.kde.org">autoconfig.kde.org</a> is not.</div><div><br></div><div>Once all the fixes are in could we please:</div><div>a) Run diagnostic tools such as Wireshark/strace/etc against Discover on some developer systems to ensure that it is behaving as we expect it to and there isn't another codepath we've missed?</div><div>b) Get the fixes backported and released to distributions so they can start moving towards user systems immediately rather than waiting for users to update (which will take months/years)</div><div><br></div><div>Note that some of the endpoints being hit are part of the v1 iteration of GHNS/KNS system (with the current OCS system being v3) so it would be nice if we could ensure that the fixes are working for both v1 and the OCS version.</div><div>(the fonts kcm being a notable user of v1)</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Aleix<br></blockquote><div><br></div><div>Cheers,</div><div>Ben</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
<br>
Aleix<br>
</blockquote></div></div>