I'm really not sure if this is even close to the right place to put this but I have been in touch with cPanel and CloudLinux and neither have any clue about this and it's been recommended that I contact the maintainer of the repo. I fear I may have missed a level and went too deep here, so if I am in the wrong place and someone can direct me to a better place to discuss this that would be appreciated.
I have a custom shared / public geolocation database I keep updated that allows me to resolve IP address blocks to countries and also contains demographic and lat/log data for all countries / states / counties / zip codes etc. I have always maintained an anonymous mysql user on the local server so that any of the sites I work on that need to access this database are able to select with the credentials they use for their own data, without me needing to add custom privileges to select from this database.
The user in question was created using command:
> grant select on database_name.* to ''@'localhost';
Long story short, when this update occurred last night at 11:34 PM local time, the aforementioned anonymous user was removed from my mariadb setup and broke functionality across all sites on my server that use this database.
While I feel it's probably unlikely that the update script specifically removed anonymous users; I feel it's more likely that (as part of its cleanup process), it may have ran the mariadb secure installation script which could have theoretically removed my anonymous user thinking it was the default anonymous user that's shipped with a fresh installation.
All I want to do is confirm what actually caused this, and for that whomever is in charge of that process to be aware that there may be unintended consequences to the way it currently works; in order to prevent some other poor soul having to go through what I did by making the same unorthodox choice of having a global read only user for a shared database.
I'm really not sure if this is even close to the right place to put this but I have been in touch with cPanel and CloudLinux and neither have any clue about this and it's been recommended that I contact the maintainer of the repo. I fear I may have missed a level and went too deep here, so if I am in the wrong place and someone can direct me to a better place to discuss this that would be appreciated.
The skinny of the situation is that my new WHM/cPanel CloudLinux server just decided to update my mariadb 10.6 installation to galera-4-26.4.16 last night via the following RPM: https://archive.mariadb.org/mariadb-10.6/yum/centos/8/x86_64/rpms/galera-4-26.4.16-1.el8.x86_64.rpm
I have a custom shared / public geolocation database I keep updated that allows me to resolve IP address blocks to countries and also contains demographic and lat/log data for all countries / states / counties / zip codes etc. I have always maintained an anonymous mysql user on the local server so that any of the sites I work on that need to access this database are able to select with the credentials they use for their own data, without me needing to add custom privileges to select from this database.
The user in question was created using command:
> grant select on database_name.* to ''@'localhost';Long story short, when this update occurred last night at 11:34 PM local time, the aforementioned anonymous user was removed from my mariadb setup and broke functionality across all sites on my server that use this database.
While I feel it's probably unlikely that the update script specifically removed anonymous users; I feel it's more likely that (as part of its cleanup process), it may have ran the mariadb secure installation script which could have theoretically removed my anonymous user thinking it was the default anonymous user that's shipped with a fresh installation.
All I want to do is confirm what actually caused this, and for that whomever is in charge of that process to be aware that there may be unintended consequences to the way it currently works; in order to prevent some other poor soul having to go through what I did by making the same unorthodox choice of having a global read only user for a shared database.