Database mappings gone from user cpanel after 11.40 update
Hi all,
I've just updated my servers and got the new 11.40 version. I don't seem to have any issues with it but the database and db users are gone from the user cpanel. They still exist on the server and all websites are working just fine, however, they do not show on the cpanel interface.
Also, if I try to add a new database, all I get is a red box with "Ran adminbin Cpanel/cpmysql/ADDDB".
Is anyone else having this problem? Is it a known bug?
I'll appreciate any info I could get.
-
I'm in the exact same boat... All of the MySQL DB's are missing from all of our clients CPanel's - and this could not have happened at a worse time either. I can't even build new DB's - our entire hosting system is useless at this time... RH 0 -
I'm pretty sure it's a permissions issue at some point because I've been checking the mapping files and they all seem to be correct. 0 -
Same problem here, There are a couple of users that can see SQL databases but most show none and get errors trying to create new ones like: ! Ran adminbin Cpanel/cpmysql/ADDDB (in red) Then the db never appears. Softaculous can't install apps because it can't access the databases cpremotebackup doesn't see any users to enable/disable I can see the individual db's in phpmyadmin via whm just fine but something has goen awry 0 -
Howdy! We have an internal case (79865) about this. After investigation on our end, it appears that this is happening because your SQL Server is using Old Passwords. 11.40 does not currently handle old_password correctly, however I am unable to give an ETA for a fix. The only way for this to work right now is disable old_password and to update the old password to the new style passwords [url=http://code.openark.org/blog/mysql/upgrading-passwords-from-old_passwords-to-new-passwords]Upgrading passwords from old_passwords to "new passwords" | code.openark.org Please note this is not something we can help with, as we do not know every password in your userlist. Thanks, 0 -
So are you saying that because of this update, we have to have all of our customers update their MySQL Passwords for all their databases? You're kidding me right? 0 -
[quote="cPJerry, post: 1480782">Howdy! We have an internal case (79865) about this. After investigation on our end, it appears that this is happening because your SQL Server is using Old Passwords. 11.40 does not currently handle old_password correctly, however I am unable to give an ETA for a fix. The only way for this to work right now is disable old_password and to update the old password to the new style passwords [url=http://code.openark.org/blog/mysql/upgrading-passwords-from-old_passwords-to-new-passwords]Upgrading passwords from old_passwords to "new passwords" | code.openark.org Please note this is not something we can help with, as we do not know every password in your userlist. Thanks,
Hi cPJerry, Is there any ETA for the permanent fix?0 -
[quote="tfvaldo, post: 1481302">Is there any ETA for the permanent fix?
The Upgrading Passwords from old_passwords to "new passwords" thing above doesn't help either... Clients can gain access to EXISTING DB's via PhpMyAdmin now - but can not add new databases, users, etc. I'm going to check to see what happens when a NEW client is established on the system and if they have issues with their DBs as well, I'll report that later... I've done everything short of manually moving all of my clients onto a different server to see if that fixes things... I just don't know if I want to incur the new server expense to do it... but if it would fix everyone - I'd do it at this point... Robert J. Hantson0 -
Hi all. I can confirm this is a problem with old_password. One of the hosts I manage had several passwords on the new password hash and some on the old hash, so it was OK to reset all passwords and all is working just fine. What I've done is to connect to the MySQL server using a external client, then, setting the session variable to old_password=0 and manually reset the passwords for the users that were using the old password hash, including root, the domain accounts and the cpanel users for horde, eximstats, etc. I have however another host with much more accounts and doing this manual procedure on it is not an option, so a definitive fix would be much more desirable - or some script that could use the daily backup files or account info to recover those passwords. 0 -
NEW ACCOUNTS - Can not create databases at all... none of the automated script installers are working... my business is dead in the water right now because of this screwup by CPanel... Not a happy camper! 0 -
Have any of you put in a ticket to cPanel Technical Support? If not, you should. 0 -
I am on the same boat, opened a ticket to cPanel and their official reply was to do the things outlined in the URL mentioned above. This is NOT an option for me unfortunately, so unless an official fix is out asap, I will be forced to roll back to the working version 11.38. Now, does anyone know how I do this? I have a backup server with all the files, (incremental backup server) just don't know which ones to change and if its just a matter of replacing files. I don't have Image backups, so a complete server rollback to a date prior to the upgrade is not possible. 0 -
What cpjerry posted about changing passwords is/was a work around. Case 79865 is currently resolved, merged into cPanel & WHM 11.40 and should be in a build released this week. 0 -
All I can say as a fix will not come quicker... can you tell us if this will actually FIX our issues and we'll be back able to use our DB's then? For a hosting company that got pushed into a broken release - I'm a bit on edge. 0 -
[quote="rhantson, post: 1483742">For a hosting company that got pushed into a broken release - I'm a bit on edge.
Same here, what I am interested in knowing is if this fix will actually fix the issue. Although the mySQL4 old password thing is outdated, stopping support for it is something that should AT LEAST be documented before pushing the actual release. Now I understand that perhaps cPanel Inc *maybe* didn't even know that it will cause such an issue (I want to believe it is a bug, rather than an issue known to create problems that was just pushed without prior notification), but the important thing for us all is to somehow either fix it, or rollback the change and schedule it for a future date so we'll have time to make arrangements to our servers...0 -
11.40 switched mysql client libraries, and the new one did not support the old 3.23 passwords. We have added support for the old mysql passwords to the new client library and released 11.40.0.9 in order to solve this. We highly encourage you to disable old_passwords in Tweak Settings (Use pre-4.1-style MySQL" passwords [?]) and change the password for any user with an old style password as soon as it is feasible. See [url=http://www.emase.co.uk/old-mysql-passwords-insecure-and-easy-to-crack/]Old MySQL Passwords - Insecure and Easy to Crack | Emase for more information. We have discussed adding something to the Security Advisor to quickly identify users with old passwords, however in the mean time you can use the following sql snippet: mysql -e 'select host,user from mysql.user where length(password)=16;'
0
Please sign in to leave a comment.
Comments
15 comments