<div dir="ltr"><div dir="ltr">On Mon, Feb 7, 2022 at 9:54 AM Fabian Vogt <<a href="mailto:fabian@ritter-vogt.de" target="_blank">fabian@ritter-vogt.de</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">Moin,<br>
<br>
Am Sonntag, 6. Februar 2022, 19:27:11 CET schrieb Ben Cooksley:<br>
> On Sun, Feb 6, 2022 at 1:07 PM Fabian Vogt <<a href="mailto:fabian@ritter-vogt.de" target="_blank">fabian@ritter-vogt.de</a>> wrote:<br>
> > The first URL is used by kfontinst.knsrc from plasma-workspace:<br>
> > ProvidersUrl=<a href="https://distribute.kde.org/khotnewstuff/fonts-providers.xml" rel="noreferrer" target="_blank">https://distribute.kde.org/khotnewstuff/fonts-providers.xml</a><br>
> ><br>
> > The second URL is used by multiple knsrc files in my VM:<br>
> > aurorae.knsrc:ProvidersUrl=<a href="https://download.kde.org/ocs/providers.xml" rel="noreferrer" target="_blank">https://download.kde.org/ocs/providers.xml</a><br>
> > comic.knsrc:ProvidersUrl=<a href="https://download.kde.org/ocs/providers.xml" rel="noreferrer" target="_blank">https://download.kde.org/ocs/providers.xml</a><br>
> > kwineffect.knsrc:ProvidersUrl=<a href="https://download.kde.org/ocs/providers.xml" rel="noreferrer" target="_blank">https://download.kde.org/ocs/providers.xml</a><br>
> > kwinscripts.knsrc:ProvidersUrl=<a href="https://download.kde.org/ocs/providers.xml" rel="noreferrer" target="_blank">https://download.kde.org/ocs/providers.xml</a><br>
> > kwinswitcher.knsrc:ProvidersUrl=<a href="https://download.kde.org/ocs/providers.xml" rel="noreferrer" target="_blank">https://download.kde.org/ocs/providers.xml</a><br>
> > wallpaperplugin.knsrc:ProvidersUrl=<br>
> > <a href="https://download.kde.org/ocs/providers.xml" rel="noreferrer" target="_blank">https://download.kde.org/ocs/providers.xml</a><br>
> <br>
> This makes me incredibly sad. We had a push to eliminate all usage of the<br>
> legacy <a href="http://download.kde.org" rel="noreferrer" target="_blank">download.kde.org</a> endpoint many years ago...<br>
> I have now resolved the majority of these - if distributions could please<br>
> pick up those patches that would be appreciated.<br>
> <br>
> Please note that I have now terminated the support on the server that was<br>
> making these legacy endpoints work, so those patches are necessary to<br>
> restore functionality.<br>
<br>
Does this decrease the server load noticably?<br></blockquote><div><br></div><div>Unfortunately it doesn't have much impact, although this is hard to measure as the volume of requests is not even and fluctuates quite a bit.</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>
On IRC you wrote that the primary offender is<br>
"KNewStuff/5.86.0-plasma-discover-update/", can you make the endpoints return<br>
an error for the top entries only? Then we'll get bug reports only for the<br>
likely cause(s) of the high traffic instead of everyone.<br></blockquote><div><br></div><div>That is within our abilities yes - do we know if returning a 404 is sufficient to trigger Discover to pop up a message to the user or is this not something it will do?</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>
What might help is to have a lightweight proxy in front of Apache to handle<br>
those paths in a way that doesn't stress the system much. That should probably<br>
be investigated independently of the client side, as this is entirely under our<br>
control and has immediate effects.<br></blockquote><div><br></div><div>Unfortunately I suspect that the vast majority of the CPU load will be from setup/teardown of SSL sessions rather than the overhead of Apache itself.</div><div>As all of these requests are https:// there likely isn't much help that a lightweight proxy can do.</div><div><br></div><div>I suspect i'll need to look into a Cloud based load balancer of some description. Per <a href="https://www.digitalocean.com/products/load-balancer">https://www.digitalocean.com/products/load-balancer</a> it seems that their load balancer nodes are rated at around 250 HTTPS connections per second.</div><div>To put that in context...</div><div><br></div><div><dt>535 requests/sec - 5.0 MB/second - 9.6 kB/request - 7.16541 ms/request</dt><br><dt>146 requests currently being processed, 161 idle workers</dt><br></div><div><br></div><div>So we'd need approximately 3 DigitalOcean load balancer nodes (cost of $30 USD / month or $360 USD / year) to handle this at current load numbers.</div><div>Earlier they were higher so in practice we are probably talking 4-5 nodes.</div><div><br></div><div>Given we're talking a single Octa Core with HT processor here I think it is doing extremely well....</div><div><br></div><div>Note that even this is not a guaranteed silver bullet.</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>
It's also possible that the requests aren't actually caused by Discover at all,<br>
but just something which imitates it in a DDoS attack. In that case we couldn't<br>
do anything on the client-side anyway. I don't think this is very likely, but<br>
until the issue was reproduced with disover it's a possibility.<br>
<br>
> > > Given that Sysadmin has raised issues with this component and it's<br>
> > > behaviour in the past, it appears that issues regarding the behaviour of<br>
> > > the OCS componentry within Discover remain unresolved.<br>
> > ><br>
> > > Due to the level of distress this is causing our systems, I am therefore<br>
> > > left with no other option other than to direct the Plasma Discover<br>
> > > developers to create and release without delay patches for all versions<br>
> > in<br>
> > > support, as well as for all those currently present in any actively<br>
> > > maintained distributions, that disable all OCS functionality in the<br>
> > > Discover updater. Distributions are requested to treat these patches as<br>
> > > security patches and to distribute them to users without delay.<br>
> ><br>
> > Emergency workarounds for distributions might be to either not ship the KNS<br>
> > backend by not building kns-backend.so or deleting it afterwards, or<br>
> > disabling<br>
> > the discover notifier<br>
> > (/etc/xdg/autostart/org.kde.discover.notifier.desktop)<br>
> > completely.<br>
> <br>
> I have now committed patches to Discover going back to Plasma/5.18 which<br>
> disable the build of the KNS backend.<br>
> If distributions could please pick them up and distribute them as I<br>
> previously indicated that would be much appreciated.<br>
> <br>
> <a href="https://invent.kde.org/plasma/discover/-/commit/f66df3531670592960167f5060feeed6d6c792be" rel="noreferrer" target="_blank">https://invent.kde.org/plasma/discover/-/commit/f66df3531670592960167f5060feeed6d6c792be</a><br>
<br>
IMO we need a more targeted approach there. The main offenders aren't running<br>
the latest version, so likely won't get those updates that quickly either.<br>
If we have more data and can pinpoint it a bit better that would at least help<br>
to speed patch delivery up.<br></blockquote><div><br></div><div>From the data we are seeing, it appears that the vast majority of the clients are running the exact same set of software.</div><div>This information comes from <a href="http://files.kde.org">files.kde.org</a>, which hosts a series of legacy and static datasets for the KDE Education family of applications.</div><div><br></div><div>   9117 "KNewStuff/5.86.0-discover/5.22.5"<br>   9331 "KNewStuff/5.90.0-discover/5.23.5"<br>  52737 "Mozilla/5.0"<br>1852450 "KNewStuff/5.86.0-plasma-discover-update/"<br></div><div><br></div><div>This would indicate the distribution in question is shipping Frameworks 5.86.0 (which from my understanding is a small handful of distros - including Ubuntu 21.10) alongside a version of Plasma including the updater.</div><div>Unfortunately we don't know more than that as the amount of information available to us is very limited.</div><div><br></div><div>The only other data point we have is our server monitoring system:</div><div><br></div><div><img src="cid:ii_kzcjxy6f0" alt="80029574.png" width="562" height="244"><br></div><div><br></div><div>This indicates that system load has increased steadily from October onward, which would fit with an increasing number of users updating to Ubuntu 21.10 and receiving a system with the affected versions - however this is not particularly conclusive.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
> Please note that I intend to investigate whether it is possible to serve<br>
> corrupted files from the server side that cause Discover to crash to help<br>
> alleviate the load being created by those clients.<br>
<br>
Sounds like a good way to DoS bugzilla instead and cause bad PR, both up- and<br>
downstream. On top of that, it's possible that a resulting crashloop causes an<br>
even higher frequency of requests.<br>
<br>
Cheers,<br>
Fabian<br></blockquote><div><br></div><div>Thanks,</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>
> Current load being generated by this is:<br>
> <br>
> <dt>789 requests/sec - 6.4 MB/second - 8.3 kB/request - 1.70113<br>
> ms/request</dt><br>
> <dt>217 requests currently being processed, 183 idle workers</dt><br>
> <br>
> > Cheers,<br>
> > Fabian<br>
> ><br>
> Thanks,<br>
> Ben<br>
<br>
<br>
</blockquote></div></div>