I can confirm that’s the issue!
I just delete the extra users with DB access and use the by default user for my script and the restoration process works!!
Thanks!
In cases where there are significant MySQL-to-MariaDB-related compatibility issues, it’s also an option to switch to MySQL on the new server before running the postinstall wizard. I’m not recommending that, as I think everybody will be happiest when everyone using Virtualmin is using the same database and that database is MariaDB, but sometimes that’s more trouble than it’s worth.
But, in your case, for just a handful of mail/FTP users with database access, it’s probably best to do what you’ve done.
We can certainly make it non-fatal, and we can make it provide a sensible error message, though.
1 Like
Just a question: what’s the difference between migrate/restore the by default user created by Virtualmin and the one created by me? Because as far I can see that’s the trick.
So, the domain database user has a different password for MySQL that is known to Virtualmin. The mail/FTP users do not.
If you have encrypted passwords enabled in Virtualmin, Virtualmin doesn’t know most of your passwords…but it does know the MySQL/MariaDB password for the user, as this is necessary for script installs to work. In an encrypted password system, the user system password and the database password are different.
This, I believe, would only come up on a system where Virtualmin doesn’t know the password and can only pass around the hashed password.
1 Like
So for mail / FTP users, Virtualmin should keep track of their plain-text passwords so that when restoring on a new system, the create user SQL statement can re-hash the password into the local format.
@mlacunza would it be possible to get a copy of one of the backup files you are trying to restore? I’d like to see if the passwords were included…
1 Like
Sure, let me know how I can send you the link.
Done! check your inbox.
Thanks! I have just checked in a fix for this that will be included in the 7.5 Virtualmin release.
1 Like
Will Virtualmin’s keeping track of plain text passwords not violate the directive in the Post-Install Wizard to keep passwords hashed?
I wanted to caution you about it, if it does.
No, if Virtualmin is configured to store only hashed passwords, the plaintext password is never saved. This has the downside that if a change in hashing format is needed (as in this case), you are out of luck.
There is another problem I just discovered: when you migrate from MySQL to MariaDB the MAIN domain database is not restored, in my case like most of my sites are Wordpress and I use the Install Script from Virtualmin I dont notice it yet. This install option creates another database for the new WP site and keep the main DB empty.
But @Jamie in the file I already sent you tonight (restoredok.zip) the restore option dont restore the main database, like I have Roundcube installed too, the process restore that DB but not the main, where my website have stored his data. I need to restore the backup in my old VPS (MySQL) and get a file sql backup and import it into new VPS (MariaDB) after fixing a lot of charset problems (another issue) all the data was restored.
Another bug/issue: the same domain have installed phpmyadmin and roundcube, the old vps is using php7 the new vps php8, after restorarion and when I tryng to upgrade these scripts I got this error message and both apps are broken, I need to delete and reinstall:
Upgrading RoundCube to version 1.4.13 ..
.. failed dependencies : No PHP version could be found for this virtual server
About the restore issue - I tested the backup you supplied, and it failed to create some tables due to the use of the utf8mb4_0900_ai_ci collation order on the original system. I think the only fix is to change the collation order on the original server, re-do the backup and re-restore it.
Why the change in collation? I installed both servers using the bydefault options or is some internal change did by MariaDB?
When there is an incompatible change, you should always assume it is MySQL that made the change, rather than MariaDB.
Ok fine but I don’t get any error/warning message about it.
Yeah, surprisingly the mysql command doesn’t fail when importing the backup - it just outputs warnings which Virtualmin doesn’t display because most warnings are harmless.
PLease correct that issue, in my case it was critical.
I’ve checked in a fix for it here : If we get an ERROR output when executing an SQL file, consider it fai… · webmin/webmin@ca814a4 · GitHub
1 Like
Holy crap son that’s what I call support!