OCS Providers File - High Numbers of Requests
Hi all, It has recently come to our attention that the number of queries being handled for the endpoint https://autoconfig.kde.org/ocs/providers.xml on a day to day basis has gotten to the point where it is causing issues with server responsiveness to other traffic. This is perhaps best summarised by the following: root@nicoda /var/log/apache2 # ls -lah ... -rw-r- 1 root adm 458M Sep 23 06:25 autoconfig.kde.org.log.1 -rw-r- 1 root adm 381M Sep 23 06:25 networkcheck.kde.org.log.1 -rw-r- 1 root adm 143M Sep 23 06:25 www.kde.org.log.1 root@nicoda /var/log/apache2 # cat autoconfig.kde.org.log.1 | wc -l 4,222,343 Based on those numbers we're looking at 48-49 requests per second (on average - peaks are much higher by many magnitudes), which seems extremely excessive given that this file is only supposed to be retrieved by KDE software when GHNS functionality is triggered. That is supported by the substantial size difference it has over networkcheck.kde.org - which is used by plasma-nm and NetworkManager (on Neon) to check for whether they have a working internet connection - which i'd expect to be the site receiving the most traffic. As such, I therefore suspect we have bug(s) in software that makes use of GHNS functionality. It would therefore be appreciated if we could please review the software in question to determine whether it is operating correctly. Given that it usually runs in the background on user systems, i'd especially appreciate it if a detailed review could be conducted on Discover and other software that conducts package management operations or assists in managing updates. Unfortunately all these applications submit a fairly useless user agent (Mozilla/5.0) so it is impossible for Sysadmin to ascertain any further information. If we could get information on the software that is originating the request added to the user agent to assist in investigating these issues in the future that would be extremely helpful. Thanks, Ben
Re: OCS Providers File - High Numbers of Requests
On Thu, Sep 23, 2021 at 11:52 AM Ben Cooksley wrote: > > Hi all, > > It has recently come to our attention that the number of queries being > handled for the endpoint https://autoconfig.kde.org/ocs/providers.xml on a > day to day basis has gotten to the point where it is causing issues with > server responsiveness to other traffic. This is perhaps best summarised by > the following: > > root@nicoda /var/log/apache2 # ls -lah ... > -rw-r- 1 root adm 458M Sep 23 06:25 autoconfig.kde.org.log.1 > -rw-r- 1 root adm 381M Sep 23 06:25 networkcheck.kde.org.log.1 > -rw-r- 1 root adm 143M Sep 23 06:25 www.kde.org.log.1 > > root@nicoda /var/log/apache2 # cat autoconfig.kde.org.log.1 | wc -l > 4,222,343 > > Based on those numbers we're looking at 48-49 requests per second (on average > - peaks are much higher by many magnitudes), which seems extremely excessive > given that this file is only supposed to be retrieved by KDE software when > GHNS functionality is triggered. That is supported by the substantial size > difference it has over networkcheck.kde.org - which is used by plasma-nm and > NetworkManager (on Neon) to check for whether they have a working internet > connection - which i'd expect to be the site receiving the most traffic. > > As such, I therefore suspect we have bug(s) in software that makes use of > GHNS functionality. > > It would therefore be appreciated if we could please review the software in > question to determine whether it is operating correctly. Given that it > usually runs in the background on user systems, i'd especially appreciate it > if a detailed review could be conducted on Discover and other software that > conducts package management operations or assists in managing updates. > > Unfortunately all these applications submit a fairly useless user agent > (Mozilla/5.0) so it is impossible for Sysadmin to ascertain any further > information. If we could get information on the software that is originating > the request added to the user agent to assist in investigating these issues > in the future that would be extremely helpful. > > Thanks, > Ben That's correct. Discover fetches them at startup. It's necessary to be able to check if there are updates on KNS-provided resources. Incidentally, I was looking into this yesterday incidentally. We could see if caching is broken somehow. A request will still be needed though to check if the cache is out of date. Or we can prefer the cached version of the file for a few days and assume they don't change that much. I've seen some of them point at "https://download.kde.org/ocs/providers.xml";, I don't know if this is any better. Aleix
Re: OCS Providers File - High Numbers of Requests
On Thu, Sep 23, 2021 at 1:54 PM Aleix Pol wrote: > > On Thu, Sep 23, 2021 at 11:52 AM Ben Cooksley wrote: > > > > Hi all, > > > > It has recently come to our attention that the number of queries being > > handled for the endpoint https://autoconfig.kde.org/ocs/providers.xml on a > > day to day basis has gotten to the point where it is causing issues with > > server responsiveness to other traffic. This is perhaps best summarised by > > the following: > > > > root@nicoda /var/log/apache2 # ls -lah ... > > -rw-r- 1 root adm 458M Sep 23 06:25 autoconfig.kde.org.log.1 > > -rw-r- 1 root adm 381M Sep 23 06:25 networkcheck.kde.org.log.1 > > -rw-r- 1 root adm 143M Sep 23 06:25 www.kde.org.log.1 > > > > root@nicoda /var/log/apache2 # cat autoconfig.kde.org.log.1 | wc -l > > 4,222,343 > > > > Based on those numbers we're looking at 48-49 requests per second (on > > average - peaks are much higher by many magnitudes), which seems extremely > > excessive given that this file is only supposed to be retrieved by KDE > > software when GHNS functionality is triggered. That is supported by the > > substantial size difference it has over networkcheck.kde.org - which is > > used by plasma-nm and NetworkManager (on Neon) to check for whether they > > have a working internet connection - which i'd expect to be the site > > receiving the most traffic. > > > > As such, I therefore suspect we have bug(s) in software that makes use of > > GHNS functionality. > > > > It would therefore be appreciated if we could please review the software in > > question to determine whether it is operating correctly. Given that it > > usually runs in the background on user systems, i'd especially appreciate > > it if a detailed review could be conducted on Discover and other software > > that conducts package management operations or assists in managing updates. > > > > Unfortunately all these applications submit a fairly useless user agent > > (Mozilla/5.0) so it is impossible for Sysadmin to ascertain any further > > information. If we could get information on the software that is > > originating the request added to the user agent to assist in investigating > > these issues in the future that would be extremely helpful. > > > > Thanks, > > Ben > > That's correct. Discover fetches them at startup. It's necessary to be > able to check if there are updates on KNS-provided resources. > > Incidentally, I was looking into this yesterday incidentally. We > could see if caching is broken somehow. A request will still be needed > though to check if the cache is out of date. > > Or we can prefer the cached version of the file for a few days and > assume they don't change that much. > > I've seen some of them point at > "https://download.kde.org/ocs/providers.xml";, I don't know if this is > any better. > > Aleix https://invent.kde.org/frameworks/attica/-/merge_requests/15/ https://invent.kde.org/frameworks/knewstuff/-/merge_requests/141 https://invent.kde.org/plasma/discover/-/merge_requests/165 This should lessen the problem from Discover's side. Still that one providers.xml request at startup remains. Aleix
Re: Project Submission
On woensdag 22 september 2021 18:03:42 CEST Aleix Pol wrote: > > Would you still propose going for QML given in this > > situation? Rewriting existing, working a C++ app in QML is absolutely not needed. That would be a waste of effort. You might consider adding a QML layer on top of your C++ classes to reuse existing Plasma widgets, though. Look at it like this; The C++ classes are the 'model', they fetch the data and handle the logic. The QML can be the display layer (the view) because its nice and easy to make things look good using QML. But **what** is displayed comes from the C++ models. LIke Aleix said, the two work really well together. https://doc.qt.io/qt-5/qtqml-cppintegration-data.html
Re: OCS Providers File - High Numbers of Requests
El jue, 23 de sep. de 2021 a la(s) 08:55, Aleix Pol (aleix...@kde.org) escribió: > > On Thu, Sep 23, 2021 at 11:52 AM Ben Cooksley wrote: > > > > Hi all, > > > > It has recently come to our attention that the number of queries being > > handled for the endpoint https://autoconfig.kde.org/ocs/providers.xml on a > > day to day basis has gotten to the point where it is causing issues with > > server responsiveness to other traffic. This is perhaps best summarised by > > the following: > > > > root@nicoda /var/log/apache2 # ls -lah ... > > -rw-r- 1 root adm 458M Sep 23 06:25 autoconfig.kde.org.log.1 > > -rw-r- 1 root adm 381M Sep 23 06:25 networkcheck.kde.org.log.1 > > -rw-r- 1 root adm 143M Sep 23 06:25 www.kde.org.log.1 > > > > root@nicoda /var/log/apache2 # cat autoconfig.kde.org.log.1 | wc -l > > 4,222,343 > > > > Based on those numbers we're looking at 48-49 requests per second (on > > average - peaks are much higher by many magnitudes), which seems extremely > > excessive given that this file is only supposed to be retrieved by KDE > > software when GHNS functionality is triggered. That is supported by the > > substantial size difference it has over networkcheck.kde.org - which is > > used by plasma-nm and NetworkManager (on Neon) to check for whether they > > have a working internet connection - which i'd expect to be the site > > receiving the most traffic. > > > > As such, I therefore suspect we have bug(s) in software that makes use of > > GHNS functionality. > > > > It would therefore be appreciated if we could please review the software in > > question to determine whether it is operating correctly. Given that it > > usually runs in the background on user systems, i'd especially appreciate > > it if a detailed review could be conducted on Discover and other software > > that conducts package management operations or assists in managing updates. > > > > Unfortunately all these applications submit a fairly useless user agent > > (Mozilla/5.0) so it is impossible for Sysadmin to ascertain any further > > information. If we could get information on the software that is > > originating the request added to the user agent to assist in investigating > > these issues in the future that would be extremely helpful. > > > > Thanks, > > Ben > > That's correct. Discover fetches them at startup. It's necessary to be > able to check if there are updates on KNS-provided resources. > > Incidentally, I was looking into this yesterday incidentally. We > could see if caching is broken somehow. A request will still be needed > though to check if the cache is out of date. Caching seems to be working, since the vast majority of the requests are returning 304 Not Modified. However in *many* cases I see a single IP making multiple requests in the same second, and doing it again the next minute. Here's one IP address picked randomly: [22/Sep/2021:06:25:41 +] "GET /ocs/providers.xml HTTP/1.1" 304 [22/Sep/2021:06:25:41 +] "GET /ocs/providers.xml HTTP/1.1" 304 [22/Sep/2021:06:25:41 +] "GET /ocs/providers.xml HTTP/1.1" 304 [22/Sep/2021:06:25:41 +] "GET /ocs/providers.xml HTTP/1.1" 304 [22/Sep/2021:06:27:57 +] "GET /ocs/providers.xml HTTP/1.1" 304 [22/Sep/2021:06:27:58 +] "GET /ocs/providers.xml HTTP/1.1" 304 [22/Sep/2021:06:27:58 +] "GET /ocs/providers.xml HTTP/1.1" 304 [22/Sep/2021:06:28:32 +] "GET /ocs/providers.xml HTTP/1.1" 304 [22/Sep/2021:06:28:32 +] "GET /ocs/providers.xml HTTP/1.1" 304 [22/Sep/2021:06:28:32 +] "GET /ocs/providers.xml HTTP/1.1" 304 [22/Sep/2021:06:28:32 +] "GET /ocs/providers.xml HTTP/1.1" 304 [22/Sep/2021:06:28:59 +] "GET /ocs/providers.xml HTTP/1.1" 304 [22/Sep/2021:06:28:59 +] "GET /ocs/providers.xml HTTP/1.1" 304 [22/Sep/2021:06:28:59 +] "GET /ocs/providers.xml HTTP/1.1" 304 [22/Sep/2021:06:28:59 +] "GET /ocs/providers.xml HTTP/1.1" 304 [22/Sep/2021:06:30:11 +] "GET /ocs/providers.xml HTTP/1.1" 200 [22/Sep/2021:06:30:11 +] "GET /ocs/providers.xml HTTP/1.1" 304 [22/Sep/2021:06:30:11 +] "GET /ocs/providers.xml HTTP/1.1" 200 [22/Sep/2021:06:30:38 +] "GET /ocs/providers.xml HTTP/1.1" 304 [22/Sep/2021:06:30:38 +] "GET /ocs/providers.xml HTTP/1.1" 304 [22/Sep/2021:06:30:38 +] "GET /ocs/providers.xml HTTP/1.1" 304 [22/Sep/2021:06:30:38 +] "GET /ocs/providers.xml HTTP/1.1" 304 [22/Sep/2021:06:31:19 +] "GET /ocs/providers.xml HTTP/1.1" 304 [22/Sep/2021:06:31:19 +] "GET /ocs/providers.xml HTTP/1.1" 304 [22/Sep/2021:06:31:19 +] "GET /ocs/providers.xml HTTP/1.1" 304 [22/Sep/2021:06:31:19 +] "GET /ocs/providers.xml HTTP/1.1" 304 [22/Sep/2021:06:31:38 +] "GET /ocs/providers.xml HTTP/1.1" 304 [22/Sep/2021:06:31:38 +] "GET /ocs/providers.xml HTTP/1.1" 304 [22/Sep/2021:06:31:38 +] "GET /ocs/providers.xml HTTP/1.1" 304 [22/Sep/2021:06:31:38 +] "GET /ocs/providers.xml HTTP/1.1" 304 This continues for hours. And it's not an isolated case; again, the IP I searched f
Re: OCS Providers File - High Numbers of Requests
On Thu, Sep 23, 2021 at 10:12 PM Nicolás Alvarez wrote: > > El jue, 23 de sep. de 2021 a la(s) 08:55, Aleix Pol (aleix...@kde.org) > escribió: > > > > On Thu, Sep 23, 2021 at 11:52 AM Ben Cooksley wrote: > > > > > > Hi all, > > > > > > It has recently come to our attention that the number of queries being > > > handled for the endpoint https://autoconfig.kde.org/ocs/providers.xml on > > > a day to day basis has gotten to the point where it is causing issues > > > with server responsiveness to other traffic. This is perhaps best > > > summarised by the following: > > > > > > root@nicoda /var/log/apache2 # ls -lah ... > > > -rw-r- 1 root adm 458M Sep 23 06:25 autoconfig.kde.org.log.1 > > > -rw-r- 1 root adm 381M Sep 23 06:25 networkcheck.kde.org.log.1 > > > -rw-r- 1 root adm 143M Sep 23 06:25 www.kde.org.log.1 > > > > > > root@nicoda /var/log/apache2 # cat autoconfig.kde.org.log.1 | wc -l > > > 4,222,343 > > > > > > Based on those numbers we're looking at 48-49 requests per second (on > > > average - peaks are much higher by many magnitudes), which seems > > > extremely excessive given that this file is only supposed to be retrieved > > > by KDE software when GHNS functionality is triggered. That is supported > > > by the substantial size difference it has over networkcheck.kde.org - > > > which is used by plasma-nm and NetworkManager (on Neon) to check for > > > whether they have a working internet connection - which i'd expect to be > > > the site receiving the most traffic. > > > > > > As such, I therefore suspect we have bug(s) in software that makes use of > > > GHNS functionality. > > > > > > It would therefore be appreciated if we could please review the software > > > in question to determine whether it is operating correctly. Given that it > > > usually runs in the background on user systems, i'd especially appreciate > > > it if a detailed review could be conducted on Discover and other software > > > that conducts package management operations or assists in managing > > > updates. > > > > > > Unfortunately all these applications submit a fairly useless user agent > > > (Mozilla/5.0) so it is impossible for Sysadmin to ascertain any further > > > information. If we could get information on the software that is > > > originating the request added to the user agent to assist in > > > investigating these issues in the future that would be extremely helpful. > > > > > > Thanks, > > > Ben > > > > That's correct. Discover fetches them at startup. It's necessary to be > > able to check if there are updates on KNS-provided resources. > > > > Incidentally, I was looking into this yesterday incidentally. We > > could see if caching is broken somehow. A request will still be needed > > though to check if the cache is out of date. > > Caching seems to be working, since the vast majority of the requests > are returning 304 Not Modified. > > However in *many* cases I see a single IP making multiple requests in > the same second, and doing it again the next minute. Here's one IP > address picked randomly: > > [22/Sep/2021:06:25:41 +] "GET /ocs/providers.xml HTTP/1.1" 304 > [22/Sep/2021:06:25:41 +] "GET /ocs/providers.xml HTTP/1.1" 304 > [22/Sep/2021:06:25:41 +] "GET /ocs/providers.xml HTTP/1.1" 304 > [22/Sep/2021:06:25:41 +] "GET /ocs/providers.xml HTTP/1.1" 304 > [22/Sep/2021:06:27:57 +] "GET /ocs/providers.xml HTTP/1.1" 304 > [22/Sep/2021:06:27:58 +] "GET /ocs/providers.xml HTTP/1.1" 304 > [22/Sep/2021:06:27:58 +] "GET /ocs/providers.xml HTTP/1.1" 304 > [22/Sep/2021:06:28:32 +] "GET /ocs/providers.xml HTTP/1.1" 304 > [22/Sep/2021:06:28:32 +] "GET /ocs/providers.xml HTTP/1.1" 304 > [22/Sep/2021:06:28:32 +] "GET /ocs/providers.xml HTTP/1.1" 304 > [22/Sep/2021:06:28:32 +] "GET /ocs/providers.xml HTTP/1.1" 304 > [22/Sep/2021:06:28:59 +] "GET /ocs/providers.xml HTTP/1.1" 304 > [22/Sep/2021:06:28:59 +] "GET /ocs/providers.xml HTTP/1.1" 304 > [22/Sep/2021:06:28:59 +] "GET /ocs/providers.xml HTTP/1.1" 304 > [22/Sep/2021:06:28:59 +] "GET /ocs/providers.xml HTTP/1.1" 304 > [22/Sep/2021:06:30:11 +] "GET /ocs/providers.xml HTTP/1.1" 200 > [22/Sep/2021:06:30:11 +] "GET /ocs/providers.xml HTTP/1.1" 304 > [22/Sep/2021:06:30:11 +] "GET /ocs/providers.xml HTTP/1.1" 200 > [22/Sep/2021:06:30:38 +] "GET /ocs/providers.xml HTTP/1.1" 304 > [22/Sep/2021:06:30:38 +] "GET /ocs/providers.xml HTTP/1.1" 304 > [22/Sep/2021:06:30:38 +] "GET /ocs/providers.xml HTTP/1.1" 304 > [22/Sep/2021:06:30:38 +] "GET /ocs/providers.xml HTTP/1.1" 304 > [22/Sep/2021:06:31:19 +] "GET /ocs/providers.xml HTTP/1.1" 304 > [22/Sep/2021:06:31:19 +] "GET /ocs/providers.xml HTTP/1.1" 304 > [22/Sep/2021:06:31:19 +] "GET /ocs/providers.xml HTTP/1.1" 304 > [22/Sep/2021:06:31:19 +] "GET /ocs/providers.xml HTTP/1.1" 304 > [22/Sep/2021:06:31:38 +] "GET /ocs/providers.xml HTTP/1.1" 304 > [22/Sep/2021:06:31:38 +] "GET /ocs/pr
Re: OCS Providers File - High Numbers of Requests
El jue, 23 de sep. de 2021 a la(s) 19:31, Aleix Pol (aleix...@kde.org) escribió: > > On Thu, Sep 23, 2021 at 10:12 PM Nicolás Alvarez > wrote: > > > > El jue, 23 de sep. de 2021 a la(s) 08:55, Aleix Pol (aleix...@kde.org) > > escribió: > > > > > > On Thu, Sep 23, 2021 at 11:52 AM Ben Cooksley wrote: > > > > > > > > Hi all, > > > > > > > > It has recently come to our attention that the number of queries being > > > > handled for the endpoint https://autoconfig.kde.org/ocs/providers.xml > > > > on a day to day basis has gotten to the point where it is causing > > > > issues with server responsiveness to other traffic. This is perhaps > > > > best summarised by the following: > > > > > > > > root@nicoda /var/log/apache2 # ls -lah ... > > > > -rw-r- 1 root adm 458M Sep 23 06:25 autoconfig.kde.org.log.1 > > > > -rw-r- 1 root adm 381M Sep 23 06:25 networkcheck.kde.org.log.1 > > > > -rw-r- 1 root adm 143M Sep 23 06:25 www.kde.org.log.1 > > > > > > > > root@nicoda /var/log/apache2 # cat autoconfig.kde.org.log.1 | wc -l > > > > 4,222,343 > > > > > > > > Based on those numbers we're looking at 48-49 requests per second (on > > > > average - peaks are much higher by many magnitudes), which seems > > > > extremely excessive given that this file is only supposed to be > > > > retrieved by KDE software when GHNS functionality is triggered. That is > > > > supported by the substantial size difference it has over > > > > networkcheck.kde.org - which is used by plasma-nm and NetworkManager > > > > (on Neon) to check for whether they have a working internet connection > > > > - which i'd expect to be the site receiving the most traffic. > > > > > > > > As such, I therefore suspect we have bug(s) in software that makes use > > > > of GHNS functionality. > > > > > > > > It would therefore be appreciated if we could please review the > > > > software in question to determine whether it is operating correctly. > > > > Given that it usually runs in the background on user systems, i'd > > > > especially appreciate it if a detailed review could be conducted on > > > > Discover and other software that conducts package management operations > > > > or assists in managing updates. > > > > > > > > Unfortunately all these applications submit a fairly useless user agent > > > > (Mozilla/5.0) so it is impossible for Sysadmin to ascertain any further > > > > information. If we could get information on the software that is > > > > originating the request added to the user agent to assist in > > > > investigating these issues in the future that would be extremely > > > > helpful. > > > > > > > > Thanks, > > > > Ben > > > > > > That's correct. Discover fetches them at startup. It's necessary to be > > > able to check if there are updates on KNS-provided resources. > > > > > > Incidentally, I was looking into this yesterday incidentally. We > > > could see if caching is broken somehow. A request will still be needed > > > though to check if the cache is out of date. > > > > Caching seems to be working, since the vast majority of the requests > > are returning 304 Not Modified. > > > > However in *many* cases I see a single IP making multiple requests in > > the same second, and doing it again the next minute. Here's one IP > > address picked randomly: > > > > [22/Sep/2021:06:25:41 +] "GET /ocs/providers.xml HTTP/1.1" 304 > > [22/Sep/2021:06:25:41 +] "GET /ocs/providers.xml HTTP/1.1" 304 > > [22/Sep/2021:06:25:41 +] "GET /ocs/providers.xml HTTP/1.1" 304 > > [22/Sep/2021:06:25:41 +] "GET /ocs/providers.xml HTTP/1.1" 304 > > [22/Sep/2021:06:27:57 +] "GET /ocs/providers.xml HTTP/1.1" 304 > > [22/Sep/2021:06:27:58 +] "GET /ocs/providers.xml HTTP/1.1" 304 > > [22/Sep/2021:06:27:58 +] "GET /ocs/providers.xml HTTP/1.1" 304 > > [22/Sep/2021:06:28:32 +] "GET /ocs/providers.xml HTTP/1.1" 304 > > [22/Sep/2021:06:28:32 +] "GET /ocs/providers.xml HTTP/1.1" 304 > > [22/Sep/2021:06:28:32 +] "GET /ocs/providers.xml HTTP/1.1" 304 > > [22/Sep/2021:06:28:32 +] "GET /ocs/providers.xml HTTP/1.1" 304 > > [22/Sep/2021:06:28:59 +] "GET /ocs/providers.xml HTTP/1.1" 304 > > [22/Sep/2021:06:28:59 +] "GET /ocs/providers.xml HTTP/1.1" 304 > > [22/Sep/2021:06:28:59 +] "GET /ocs/providers.xml HTTP/1.1" 304 > > [22/Sep/2021:06:28:59 +] "GET /ocs/providers.xml HTTP/1.1" 304 > > [22/Sep/2021:06:30:11 +] "GET /ocs/providers.xml HTTP/1.1" 200 > > [22/Sep/2021:06:30:11 +] "GET /ocs/providers.xml HTTP/1.1" 304 > > [22/Sep/2021:06:30:11 +] "GET /ocs/providers.xml HTTP/1.1" 200 > > [22/Sep/2021:06:30:38 +] "GET /ocs/providers.xml HTTP/1.1" 304 > > [22/Sep/2021:06:30:38 +] "GET /ocs/providers.xml HTTP/1.1" 304 > > [22/Sep/2021:06:30:38 +] "GET /ocs/providers.xml HTTP/1.1" 304 > > [22/Sep/2021:06:30:38 +] "GET /ocs/providers.xml HTTP/1.1" 304 > > [22/Sep/2021:06:31:19 +] "GET /ocs/providers.xml HTTP/1.1" 304 > > [22/Sep/2021:06:31:19 +] "GET /ocs/provid
Re: Wallpaper idea
Unsubscribe On Thu, Sep 23, 2021, 2:10 AM Albert Astals Cid wrote: > El diumenge, 19 de setembre de 2021, a les 2:02:20 (CEST), oldschoolcowboy > va escriure: > > I have an idea for a wallpaper plugin. I also have never done anything > like this. I have no idea where or how to start. Will someone be willing to > point me to a starting point so I can start learning? > > To create a wallpaper for plasma you need to implement a Plasma/Wallpaper > type plugin > > There are a few of them you can get inspiration from > > > https://invent.kde.org/education/marble/-/tree/master/src/plasma/wallpapers/worldmap > https://invent.kde.org/plasma/kdeplasma-addons/-/tree/master/wallpapers > > I'm CC'in plasma-devle that may give you more pointers > > Cheers, > Albert > > > > > Sent with [ProtonMail](https://protonmail.com/) Secure Email. > > > > > > >
Re: OCS Providers File - High Numbers of Requests
Hi, Just an idea - do we have enough logs on the server to see the requests history by date? If so, one can identify if there was a spike of the requests after a particular set of dates (which can in turn give us a hint about which release might contain a bug that's making more calls than expected). Of course this is not useful if it's apparent that the request count increased gradually instead of a spike. Shantanu On Thu, 23 Sept 2021 at 22:13, Nicolás Alvarez wrote: > El jue, 23 de sep. de 2021 a la(s) 08:55, Aleix Pol (aleix...@kde.org) > escribió: > > > > On Thu, Sep 23, 2021 at 11:52 AM Ben Cooksley wrote: > > > > > > Hi all, > > > > > > It has recently come to our attention that the number of queries being > handled for the endpoint https://autoconfig.kde.org/ocs/providers.xml on > a day to day basis has gotten to the point where it is causing issues with > server responsiveness to other traffic. This is perhaps best summarised by > the following: > > > > > > root@nicoda /var/log/apache2 # ls -lah ... > > > -rw-r- 1 root adm 458M Sep 23 06:25 autoconfig.kde.org.log.1 > > > -rw-r- 1 root adm 381M Sep 23 06:25 networkcheck.kde.org.log.1 > > > -rw-r- 1 root adm 143M Sep 23 06:25 www.kde.org.log.1 > > > > > > root@nicoda /var/log/apache2 # cat autoconfig.kde.org.log.1 | wc -l > > > 4,222,343 > > > > > > Based on those numbers we're looking at 48-49 requests per second (on > average - peaks are much higher by many magnitudes), which seems extremely > excessive given that this file is only supposed to be retrieved by KDE > software when GHNS functionality is triggered. That is supported by the > substantial size difference it has over networkcheck.kde.org - which is > used by plasma-nm and NetworkManager (on Neon) to check for whether they > have a working internet connection - which i'd expect to be the site > receiving the most traffic. > > > > > > As such, I therefore suspect we have bug(s) in software that makes use > of GHNS functionality. > > > > > > It would therefore be appreciated if we could please review the > software in question to determine whether it is operating correctly. Given > that it usually runs in the background on user systems, i'd especially > appreciate it if a detailed review could be conducted on Discover and other > software that conducts package management operations or assists in managing > updates. > > > > > > Unfortunately all these applications submit a fairly useless user > agent (Mozilla/5.0) so it is impossible for Sysadmin to ascertain any > further information. If we could get information on the software that is > originating the request added to the user agent to assist in investigating > these issues in the future that would be extremely helpful. > > > > > > Thanks, > > > Ben > > > > That's correct. Discover fetches them at startup. It's necessary to be > > able to check if there are updates on KNS-provided resources. > > > > Incidentally, I was looking into this yesterday incidentally. We > > could see if caching is broken somehow. A request will still be needed > > though to check if the cache is out of date. > > Caching seems to be working, since the vast majority of the requests > are returning 304 Not Modified. > > However in *many* cases I see a single IP making multiple requests in > the same second, and doing it again the next minute. Here's one IP > address picked randomly: > > [22/Sep/2021:06:25:41 +] "GET /ocs/providers.xml HTTP/1.1" 304 > [22/Sep/2021:06:25:41 +] "GET /ocs/providers.xml HTTP/1.1" 304 > [22/Sep/2021:06:25:41 +] "GET /ocs/providers.xml HTTP/1.1" 304 > [22/Sep/2021:06:25:41 +] "GET /ocs/providers.xml HTTP/1.1" 304 > [22/Sep/2021:06:27:57 +] "GET /ocs/providers.xml HTTP/1.1" 304 > [22/Sep/2021:06:27:58 +] "GET /ocs/providers.xml HTTP/1.1" 304 > [22/Sep/2021:06:27:58 +] "GET /ocs/providers.xml HTTP/1.1" 304 > [22/Sep/2021:06:28:32 +] "GET /ocs/providers.xml HTTP/1.1" 304 > [22/Sep/2021:06:28:32 +] "GET /ocs/providers.xml HTTP/1.1" 304 > [22/Sep/2021:06:28:32 +] "GET /ocs/providers.xml HTTP/1.1" 304 > [22/Sep/2021:06:28:32 +] "GET /ocs/providers.xml HTTP/1.1" 304 > [22/Sep/2021:06:28:59 +] "GET /ocs/providers.xml HTTP/1.1" 304 > [22/Sep/2021:06:28:59 +] "GET /ocs/providers.xml HTTP/1.1" 304 > [22/Sep/2021:06:28:59 +] "GET /ocs/providers.xml HTTP/1.1" 304 > [22/Sep/2021:06:28:59 +] "GET /ocs/providers.xml HTTP/1.1" 304 > [22/Sep/2021:06:30:11 +] "GET /ocs/providers.xml HTTP/1.1" 200 > [22/Sep/2021:06:30:11 +] "GET /ocs/providers.xml HTTP/1.1" 304 > [22/Sep/2021:06:30:11 +] "GET /ocs/providers.xml HTTP/1.1" 200 > [22/Sep/2021:06:30:38 +] "GET /ocs/providers.xml HTTP/1.1" 304 > [22/Sep/2021:06:30:38 +] "GET /ocs/providers.xml HTTP/1.1" 304 > [22/Sep/2021:06:30:38 +] "GET /ocs/providers.xml HTTP/1.1" 304 > [22/Sep/2021:06:30:38 +] "GET /ocs/providers.xml HTTP/1.1" 304 > [22/Sep/2021:06:31:19 +] "GET /ocs/providers.xml HTTP/1.1" 304 > [22/
