SOLVED [CPANEL-25776] phpMyAdmin login issue since WHM 80 update

[morrow95]

Logging into phpMyAdmin gives the following error since WHM updated to v 80 the other day for me. Picture attached.

Login without a password is forbidden by configuration (see AllowNoPassword)

mysqli_connect(): (28000/1045): Access denied for user 'root'@'192.168.10.3' (using password: YES)

Undefined index: auth_type​

I am using a username/password, as I always have, so I find it strange this error is showing. Something clearly was changed since the update to WHM 80 as I have made no changes recently nor have there ever been problems with it prior (couple years now).

 

[cPanelLauren]

Hi @morrow95

Can you give me the output of the following:

/scripts/restartsrv_mysql --status

grep sock /etc/my.cnf

 

[morrow95]

Hi @morrow95

Can you give me the output of the following:

/scripts/restartsrv_mysql --status

grep sock /etc/my.cnf

We use a remote database so the service is disabled.

With that said, the my.cnf means nothing either, but here it is in full anyways :

[mysqld]
default-storage-engine=MyISAM
innodb_file_per_table=1
max_allowed_packet=268435456
open_files_limit=10000


As for the current config, we created a superuser for the remote db and created a profile for it in Manage MySQL® Profiles in WHM. Here is our /root/my.cnf (edited for sensitive info) on the server with WHM :

[client]
#db.example.com whm_remote
user=whm_remote
password="somepassword"
host=192.168.10.2
port=3306
[mysqld]

whm_remote being the same superuser setup in Manage MySQL® Profiles to access the remote db. This setup has worked fine for 4-5 years now. It was only the other day I noticed the error with phpMyAdmin and it just happened that WHM v80 was updated before that. I had accessed phpMyAdmin no less than a week or two ago as normal with no issues.

 

[cPanelLauren]

None of that is actually what I was looking for unfortunately, I've seen a couple cases where the sock file was being referenced in a new location causing this issue but there's not a way to know if that's the case from this. Can you please open a ticket using the link in my signature? Once open please reply with the Ticket ID here so that we can update this thread with the resolution once the ticket is resolved.


Thanks!

 

[morrow95]

None of that is actually what I was looking for unfortunately, I've seen a couple cases where the sock file was being referenced in a new location causing this issue but there's not a way to know if that's the case from this. Can you please open a ticket using the link in my signature? Once open please reply with the Ticket ID here so that we can update this thread with the resolution once the ticket is resolved.


Thanks!

This is all I could provide for what you asked since none of it applies to this situation. As I mentioned we use a remote database. The user setup in WHM to access it is valid of course and there are no issues with our database either. This would also rule out your sock related case. This seems to be related to WHM and the recent update (or perhaps phpMyAdmin was updated?) - not with our database since it is remote and is working perfectly fine.

I guess I'll file a ticket.

 

[morrow95]

ticket 12504247

 

[cPanelLauren]

This is all I could provide for what you asked since none of it applies to this situation. As I mentioned we use a remote database. The user setup in WHM to access it is valid of course and there are no issues with our database either. This would also rule out your sock related case. This seems to be related to WHM and the recent update (or perhaps phpMyAdmin was updated?) - not with our database since it is remote and is working perfectly fine.

Right, unfortunately, it doesn't apply, being able to see what's happening on the system will be helpful in resolving the issue I believe.

I just checked in on that ticket and it appears one of our Level III analysts is working on this and attempting to reproduce the error on a test environment and he's looking for more information from you on the remote MySQL instance.

 

[cPanelLauren]

Hi @morrow95

It looks like one of our analysts found that this issue was related to an open case CPANEL-25776 which is identified as being fixed in v82 of cPanel/WHM
It looks like there's a request to have this patched to v80 as well and I'll update here as I have more information.


Thanks!

 

[morrow95]

For those curious, they were able to replicate this problem. It worked fine on v78 and did not on v80. phpMyAdmin is forcing login to the same username you are logged into WHM as. In our case this posed a problem as the username we login to WHM as does not have access to our remote database. Seems like somewhere between 78 - 80 a change was made where it no longer uses the information provided in either /root/my.cnf (user/pass to the remote db is listed) or the access setup in Manage MySQL® Profiles of WHM (same user/pass). The latter sounds more likely as previously we would log into phpMyAdmin with the same user/pass as WHM, but would be logged in as our superuser created (whm_remote in our case) which would be correct as the profile setup in Manage MySQL® Profiles is meant to give WHM access/login credentials when needed.

 

[cPanelMichael]

Hello,

To update, here's the entry in the cPanel & WHM version 82 Change Log noting the fix for this issue:

Fixed case CPANEL-25776: Use authentication in .my.cnf when accessing WHM > phpMyAdmin.

You can see which versions are published to each Release Tier on the link below:

Latest cPanel & WHM Builds

Thank you.

 

[morrow95]

Hello,

To update, here's the entry in the cPanel & WHM version 82 Change Log noting the fix for this issue:

Fixed case CPANEL-25776: Use authentication in .my.cnf when accessing WHM > phpMyAdmin.

You can see which versions are published to each Release Tier on the link below:

Latest cPanel & WHM Builds

Thank you.

Do you know if there will be a patch for v80 or not?

 

[cPanelMichael]

Do you know if there will be a patch for v80 or not?

Hi @morrow95,

A request to backport this fix into cPanel & WHM version 80 is open. We'll continue to monitor the case and report new information on the status of the backport request as it becomes available.

Thank you.