When attempting to change the password for an existing virtual server that is configured to keep the MySQL user password and virtual server user passwords in sync (the default behavior), I get the following error when trying to save the virtual server:
Password hash should be a 41-digit hexadecimal number.
I can create new virtual servers just fine and do not receive this error when I do so, but changing the password of any existing virtual server always fails with the above message.
I am running Virtualmin 6.07 Pro on an up-to-date CentOS 7 server running MariaDB 10.2.27. The password hashing format (as set in Webmin > Servers > MySQL Database Server > Module Config) is set to Default. I just started noticing this issue today though I haven't really had to change passwords for existing virtual servers in a while so maybe it existed before today.
How can I resolve this problem? Thanks!
Submitted by JamieCameron on Fri, 10/18/2019 - 00:11 Comment #1
We're just about to release Virtualmin 6.08 which should fix this issue.
Submitted by JEMEDIACORP on Fri, 10/18/2019 - 00:17 Pro Licensee Comment #2
Excellent, I'm glad to hear that and am looking forward to the release. Do you perhaps have an ETA for when we should expect the release? Also I know other forum posts regarding this error talked about using MariaDB 10.3 and 10.4 and how Virtualmin 6.08 would fix this problem for those releases; will it work with MariaDB 10.2 as well?
Submitted by Jfro on Fri, 10/18/2019 - 04:21 Comment #3
JEMEDIA thsi your site , and one virtualmin box?
Then maybe not solved. https://blog.jemediacorp.com/
Error establishing a database connection
6.08 update is out now i see , does this solve your probs?
If not so you can ask and give JAMIE / Support to have a look, maybe they can try/test with some updated parts of virtualmin. Sorry that i 'm breaking in here. ;)
Submitted by JEMEDIACORP on Fri, 10/18/2019 - 08:32 Pro Licensee Comment #4
Thanks for your comment; I just saw the release announcement and we're upgrading to Virtualmin 6.08 now. Also, we actually run a Virtualmin cluster with hundreds of virtual servers/Websites on it, with https://www.jemediacorp.com being our main site. You're welcome to explore our business if you'd like on our Website.
I'll report back when I have tested the new Virtualmin release and confirmed that it fixes this issue.
Submitted by raviktiwari on Sun, 06/21/2020 - 21:30 Comment #5
Apologies for bumping up an old thread... but I am using Virtualmin 6.09 and every time I create a new vdomain/virtualserver, the task finishes but I always get an error:
Creating MySQL login .. .. MySQL database failed! : mysql::execute_sql_logged failed : SQL alter user 'test'@'localhost' identified by 'mypwd' failed : You have an error in your SQL syntax; check the manual that corresponds to your MariaDB server version for the right syntax to use near 'user 'test'@'localhost' identified by 'mypwd'' at line 1 at /usr/share/webmin/web-lib-funcs.pl line 1496.
And this means now DB was installed under this domain.
I read on another thread that I need to get a stronger pwd for "MySQL password".. So I re-ran the install wizard and tried to change the password to18 character alphabatical password with small and capital letters but when I click on next, system says:
SQL set password for 'root'@'127.0.0.1' = 'RootdbpwdRootdbpwd' failed : Password hash should be a 41-digit hexadecimal number
And for this error, virtualmin forum says Virtualmin version 6.08 should fix it, but I am already on version 6.09.
Any idea, what's going wrong here and why?
The only solution that I have got so far is to downgrade virtualmin even further and use 6.05 apt-get install webmin-virtual-server=6.05.gpl and then restart the service: /etc/init.d/webmin restart
Only with this workaround, I am able to keep the ball rolling... or else everything should have beeen a disaster for me.
Any idea, what can be done to fix this issue?
Many Thanks, Rav
Submitted by raviktiwari on Mon, 08/03/2020 - 12:57 Comment #6
I think this issue has been resolved now with latest GPL (version 10).
Moderator or the usr who opened this ticket should consider closing the ticket.
Many Thanks, Rav
Submitted by IssueBot on Mon, 08/17/2020 - 14:42 Comment #8
Automatically closed - issue fixed for 2 weeks with no activity.