Anonymous mySQL user removed via update and broke several sites

RickKukiela

Active Member
Jan 17, 2017
32
15
58
Chicago
cPanel Access Level
Root Administrator
Hi,

We just moved to new server (centos -> cloudlinux) both are/were whm/cpanel.

I have 4 big sites that all share access to a generic Geogrpahy database that converts ip addresses to locale, among other things.

I have always had an anonymous user with select privileges to this db set up so any site I program that needs access to it automatically can. This is not a public server we only host for our clients and we are the developers of all sites on the server.

The new server has only been up for two days, and I just found out at 3am that last night around 11:35pm central time an email came in from security advisor stating that: The system’s core libraries or services have been updated. Reboot the server to ensure the system benefits from these updates.

Now, I'm not 100% sure this is related, but at 11:34pm the 4 sites that all require access to this DB went down. I didn't know about it for hours. This means the clients don't know yet, maybe they wont but they might know and I'll hear about it in the morning.

The thing is, is that SA had previously been "warning" me about an anonymous mysql user and provided me a command to run to get rid of it. Obviously I ignored this because its a SELECT perms only on a "public info" database so it was not a concern. After logging in, SA no longer warns me about the anonymous use because the reason all the sites went down was because the access to the database via that permission had been removed.

Why would this new server just take it upon itself to just remove stuff without my input? My old versions of cPanel hosted servers never had an issue or went rouge and did things to sabotage my sites without me doing that manually. I know this had to be done automatically since the server logs show no one else but me has signed into the server over the past 24+ hours.

Anyone have any clue why this would do such a thing? and how to make it not take it upon itself to attempt to be my AI overlord thand act as if it knows better than me in the future?
 
Last edited by a moderator:

cPRex

Jurassic Moderator
Staff member
Oct 19, 2014
17,470
2,843
363
cPanel Access Level
Root Administrator
Hey there! The short answer is that it didn't - Security Advisor can't execute any commands on its own.

The only "core libraries" that would require a reboot are the kernel, or packages such as glibc. Very few updates require a reboot, so it would be good to know what packages were updated. The easiest way to check this is with the "yum history" command, as that will show a timestamped list of what packages have been installed on the machine. It's worth noting this shows in reverse chronological order, so you'll want to scroll up to find the most recent changes.

I'm sorry I don't have more specifics I can provide, but this will likely take some digging to get to a root cause.
 

RickKukiela

Active Member
Jan 17, 2017
32
15
58
Chicago
cPanel Access Level
Root Administrator
This is the command that was ran that appears to correlate with the time frame of the mysql user being deleted:

yum --assumeyes --color=never --config /etc/yum.conf update --enablerepo=cloudlinux-PowerTools --enablerepo=epel

Any thoughts?
 

cPRex

Jurassic Moderator
Staff member
Oct 19, 2014
17,470
2,843
363
cPanel Access Level
Root Administrator
That's just the generic "update" command, so you'll likely see that many times in the log output. I'd move on to the DNF log directly to see if there is helpful information there.

If you're not finding anything, you can always submit a ticket to our team and have us take a look.
 

RickKukiela

Active Member
Jan 17, 2017
32
15
58
Chicago
cPanel Access Level
Root Administrator
I googled it, found it in /var/log..

Here is what I found, not sure what to make of this:

# cat dnf.log | grep mysql
2023-11-14T03:39:04+0000 DEBUG repo: using cache for: cl-mysql-meta
2023-11-14T03:39:04+0000 DEBUG cl-mysql-meta: using metadata from Thu 21 Sep 2023 12:29:11 PM UTC.
2023-11-14T04:57:28+0000 DEBUG cl-mysql-meta: has expired and will be refreshed.
2023-11-14T04:57:48+0000 DEBUG reviving: 'cl-mysql-meta' can be revived - repomd matches.
2023-11-14T04:57:48+0000 DEBUG cl-mysql-meta: using metadata from Thu 21 Sep 2023 12:29:11 PM UTC.
2023-11-14T05:31:05+0000 DEBUG repo: using cache for: cl-mysql-meta
2023-11-14T05:31:05+0000 DEBUG cl-mysql-meta: using metadata from Thu 21 Sep 2023 12:29:11 PM UTC.
2023-11-14T05:33:12+0000 DEBUG repo: downloading from remote: cl-mysql-meta
2023-11-14T05:33:13+0000 DEBUG cl-mysql-meta: using metadata from Thu Sep 21 12:29:11 2023.
2023-11-14T05:34:34+0000 DEBUG repo: using cache for: cl-mysql-meta
2023-11-14T05:34:34+0000 DEBUG cl-mysql-meta: using metadata from Thu 21 Sep 2023 12:29:11 PM UTC.
2023-11-14T05:34:39+0000 DDEBUG Removing file /var/cache/yum/cl-mysql-meta.solv
2023-11-14T05:34:39+0000 DDEBUG Removing file /var/cache/yum/cl-mysql-meta-filenames.solvx
2023-11-14T05:34:39+0000 DDEBUG Removing file /var/cache/yum/cl-mysql-meta-36fa755ec5e5b761/repodata/3b38a7474aa81f20798f3eee14374e704e95645d8dec86d3de12c1d8412ef1c5-primary.xml.gz
2023-11-14T05:34:39+0000 DDEBUG Removing file /var/cache/yum/cl-mysql-meta-36fa755ec5e5b761/repodata/6fe0ca12088ffa726cfeaefe9288d3f1b64894cd2ff6e801686572e001d5cb17-modules.yaml.gz
2023-11-14T05:34:39+0000 DDEBUG Removing file /var/cache/yum/cl-mysql-meta-36fa755ec5e5b761/repodata/090a23dd014750801415ef2e6c12467eb1e9d61cdbb7642deb204fc20ebf7277-filelists.xml.gz
2023-11-14T05:34:39+0000 DDEBUG Removing file /var/cache/yum/cl-mysql-meta-36fa755ec5e5b761/repodata/repomd.xml
2023-11-14T05:35:10+0000 DEBUG repo: using cache for: cl-mysql-meta
2023-11-14T05:35:10+0000 DEBUG cl-mysql-meta: using metadata from Thu Sep 21 12:29:11 2023.