search

virtualmin / virtualmin-gpl

Virtualmin web hosting control panel for Webmin
https://www.virtualmin.com
GNU General Public License v3.0
312 stars 97 forks source link

Transfer or restore virtual server errors on overwrite #114

Open ftrojahn opened 4 years ago

ftrojahn commented 4 years ago

Systems used:

History: did transfer server image from old to better, newer server (kvm with raid10 hdd -> kvm with raid10 ssd). On new system: made upgrades to stretch, then buster. As there are several weeks gone now due to other errors: had to transfer 5 of 40 vhosts/websites from old to new server, overwriting vhosts, due to changes. Btw: I really appreciate the transfer feature of full vhosts, one of the big reasons that I use Virtualmin.

Details:

Restore failed : SQL create user 'mysuperlongdo-ma'@'localhost' identified by '*xxxxxxxxxxxxxxxxxxxxxxxxxxxx' 
failed : Operation CREATE USER failed for 'mysuperlongdo-ma'@'localhost'

After that, user permissions were missing. Database permissions after that:

    mysuperlong\_domain     mysuperlongdo-ma    localhost   All

Deleting database permissions before transfer/restore does not make a difference.

full log ``` Transferring mysuperlong-domain.de to new.server.tld .. Backing up to destination system .. .. backup done Validating backup .. .. all domains transferred successfully Restoring backup on destination system .. .. restore failed : Checking for missing features .. .. all features in backup are supported Checking for errors in backup .. .. no errors found Starting restore.. Extracting backup archive files .. .. done Restoring backup for virtual server mysuperlong-domain.de .. Restoring virtual server password, quota and other details .. .. done Updating administration password and quotas .. .. done Restoring Cron jobs .. .. done Extracting TAR file of home directory .. .. done Setting ownership of home directory .. .. done Re-creating records in DNS domain .. .. done Restoring Apache virtual host configuration .. .. done Checking restored PHP execution mode .. .. mode FCGId OK for this system Updating home directory in PHP configuration .. .. done Restoring Apache log files .. .. done Restoring SSL Apache virtual host configuration and certificate .. .. done Restoring Logrotate configuration .. .. done Restoring allowed MySQL hosts .. .. done Deleting old MySQL databases .. .. done Re-loading MySQL database mysuperlong-domain .. Creating MySQL database mysuperlong-domain .. .. done .. done Error: SQL create user 'mysuperlong-do'@'localhost' identified by '*xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx' failed : Operation CREATE USER failed for 'mysuperlong-do'@'localhost' Error ----- SQL create user 'mysuperlong-do'@'localhost' identified by '*xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx' failed : Operation CREATE USER failed for 'mysuperlong-do'@'localhost' ----- .. transfer failed ```

Workaround for now: disable mysql feature on target (disable/enable was not enough). After transfer or restore, reenable mysql feature (user and permissions are created correctly), then restore db from (my own) database dump. This seemed easier to me instead of trying to create the mysql user (and perhaps db permissions) manually

and remove these by hand. If transferring/restoring multiple domains, I use something like this:

perl -i -p -e 's/php_admin_value engine Off//g;' /etc/apache2/sites-available/.conf perl -i -p -e 's/^php_value.//g;' /etc/apache2/sites-available/*.conf


Sorry for the long description, but IMHO all this belongs together.
jcameron commented 4 years ago

Which MySQL version are the source and destination systems running?

ftrojahn commented 4 years ago

source on jessie: mysql-server-5.5:amd64/jessie 5.5.62-0+deb8u1 uptodate target on buster: mariadb-server-10.3:amd64/buster 1:10.3.17-0+deb10u1 uptodate

jcameron commented 4 years ago

Would it be possible to create a backup of the problem domain from the source system, and attach it to this bug report? I can then try a restore on a MySQL 10.3 system to simulate the transfer ..

ftrojahn commented 4 years ago

Just sent a mail to you with download link and further details.

ftrojahn commented 4 years ago

I've hit the problem now, too, when restoring "normal" domain without "." or "-" and short domain name. How to reproduce:

Restore failed : SQL create user 'abcdefghij'@'localhost' identified by password('') 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 '('')' at line 1

So, instead of the original error, the password seems missing here?

Sent some more details per mail.

jcameron commented 4 years ago

In this case, is abcdefghij the domain owner or an additional user?

ftrojahn commented 4 years ago

Did you get my private mail(s)?

jcameron commented 4 years ago

No .. what email address did you send it from?

ftrojahn commented 4 years ago

falko.trojahn@gmail.com, subject is Virtualmin #114, actually 3 mails on 27/10 and 28/10/2019, to jcameron@virtualmin.com. Should I resend other way?

bold-gman commented 4 years ago

I just encountered the issue regarding the mariadb databases when restoring a backup on a new server. I want to restore some 20 hosts, but this error aborts the whole process and choosing every hosts speratly is tiresome (and of course incomplete). I can provide data if neccessary.

jcameron commented 4 years ago

@bold-gman are you restoring from a system running the same MariaDB version?

bold-gman commented 4 years ago

I am moving to a new server with more modern software:

Old server: Debian 9.13 with MariaDB 10.1.45 New server: Debian 10.5 with MariaDB 10.3.23

jcameron commented 4 years ago

@bold-gman are you running Virtualmin 6.12 there?

c-prompt commented 4 years ago

@jcameron I have the problem as well and am using Virtualmin 6.12 on both old and new servers:

Old server: Debian 9.13 MariaDB 10.1.45 New server: Debian 10 MariaDB 10.3.23

No matter what I change the password to in Servers > MySQL Database Server > User Permissions (or blank via mysql CLI ala UPDATE mysql.user SET Password=PASSWORD("") WHERE user='db_user1.domain';), it doesn't make a difference. The error I see when running the restore (when password is blank, for example, and even with the --continue-on-error flag):

Error: SQL create user 'db_user1.domain'@'ip_address' identified by password 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 '' at line 1

However, when the old server and new server are both Debian 9.13 MariaDB 10.1.45, this error does not occur.

(As an aside, I also saw the 'php_admin_value' error.)

jcameron commented 4 years ago

I think I see what the cause of this could be. Is your Virtualmin system using a remote MySQL server?

c-prompt commented 4 years ago

I think I see what the cause of this could be. Is your Virtualmin system using a remote MySQL server?

At least in my case, no.

Edit: Just to clarify, that error with the IP address is coming when I execute the restore on the command line. After that error, the restore stops (again, even with --continue-on-error). The IP address refers to the IP address that is an allowed host (i.e., Servers > MySQL Database Server > User Permissions) - I have 2 entries in User Permissions: one for localhost and one for the remote IP (so I can access via remote IP using SQLyog).

jcameron commented 4 years ago

I found a bug that I think can cause this, and have checked in a patch.

However, as a quick work-around, try editing the file /usr/share/webmin/virtual-server/feature-mysql.pl and at the top add the line :

$password_func = "password";

Then run /etc/webmin/restart

c-prompt commented 4 years ago

I found a bug that I think can cause this, and have checked in a patch.

However, as a quick work-around, try editing the file /usr/share/webmin/virtual-server/feature-mysql.pl and at the top add the line :

$password_func = "password";

Then run /etc/webmin/restart

Thanks for looking into this and attempting to solve. Just tried this and received the same error. For example:

Restoring backup for virtual server gene.mydomain.com ..
    Restoring virtual server password, quota and other details ..
    .. done

    Extracting TAR file of home directory ..
    .. done

    Setting ownership of home directory ..
    .. done

    Re-creating records in DNS domain ..
    .. done

    Restoring Apache virtual host configuration ..
    .. done

    Checking restored PHP execution mode ..
    .. mode FCGId OK for this system

    Updating home directory in PHP configuration ..
    .. done

    Restoring Apache log files ..
    .. done

    Restoring SSL Apache virtual host configuration and certificate ..
    .. done

    Restoring Logrotate configuration ..
    .. done

    Re-loading MySQL database gene ..
    .. done

    Re-loading MySQL database gene_analytics ..
        Creating MySQL database gene_analytics ..
        .. done

    .. done

    Re-creating mail and FTP users ..
Error: SQL create user 'db.gene'@'ip_address' identified by password  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 '' at line 1
Error
-----
SQL create user 'db.gene'@&#ip_address' identified by password  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 '' at line 1
-----

And just to confirm, this is what the top of feature-mysql.pl now looks like:

$password_func = "password";
sub require_mysql
{
return if ($require_mysql++);
$mysql::use_global_login = 1;
&foreign_require("mysql");
if (!$mysql::config{'login'}) {
    $mysql::config{'login'} = 'root';
    $mysql::mysql_login ||= 'root';
    $mysql::authstr = &mysql::make_authstr();
    }
%mconfig = &foreign_config("mysql");
$password_func = $mysql::password_func || "password";
$mysql_user_size = $config{'mysql_user_size'} || 16;
}
.
.
.

@ftrojahn's (albeit cumbersome) workaround above still appears the only way to get past this. (And it does appear to me it's likely more related to username with certain characters than password, although it might be both.)

c-prompt commented 4 years ago

One more potential piece of the puzzle:

I noticed one of my sub-servers with a user in the format of db.someword did get properly restored during "Re-creating mail and FTP users." Again, each of my mysql users come in pairs: one with a host of a specific IP and one with a host of localhost.

I just checked mysql and noticed the user with a host IP had a password assigned but the same user with localhost did not have a password. Not sure why the localhost user didn't have a password but did find it odd that this server didn't show errors while servers (and sub-servers) having users (with both a host IP and localhost) with passwords and without passwords erred out the restore script.

Edit: NVM - I stand corrected. Kind of... I just re-ran:

virtualmin restore-domain --source /root/backups/ --all-domains --all-features --continue-on-error

...and the script erred out at that server:

    Restoring allowed MySQL hosts ..

Error: SQL create user 'db.someword '@'ip_address' identified by password '*password' failed : Operation CREATE USER failed for 'db.someword '@'ip_address'
Error
-----
SQL create user 'db.someword '@'ip_address' identified by password '*password' failed : Operation CREATE USER failed for 'db.someword '@'ip_address'

No idea why it didn't the last time.

bold-gman commented 4 years ago

Can confirm, the workaround did not solve the issue.

My users are only allowed a connection from the localhost.

c-prompt commented 4 years ago

If @jcameron says this should be a new bug, I'll open it. I also just tried:

virtualmin restore-domain --source /root/backups/ --all-domains --all-features

...from:

Old server: Debian 9.13 (Nginx) PostgreSQL 9.6.19 Virtualmin 6.12 New server: Debian 10 (Nginx) PostgreSQL 11.7 Virtualmin 6.12

...and see the following:

Checking for missing features ..
.. all features in backup are supported

Checking for errors in backup ..
.. no errors found

Starting restore..
Extracting backup archive files ..
.. done

Re-creating virtual server myname-base.webname.io ..
Error: SQL select * from pg_shadow where usename = ? failed : ERROR:  permission denied for view pg_shadow
Error
-----
SQL select * from pg_shadow where usename = ? failed : ERROR:  permission denied for view pg_shadow
-----

I'm guessing this is a different bug but wanted to post here first just in case there's a relationship.

jcameron commented 4 years ago

Regarding the error restoring a MySQL database, it should be fixed by this patch : https://github.com/virtualmin/virtualmin-gpl/commit/ef0a4cb70b3e62498afd80bb60178c72b0f40fbc

However, the error @c-prompt posted about pg_shadow looks like an unrelated PostgreSQL problem. Like Virtualmin is logging into PostgreSQL as a non-root user?

c-prompt commented 4 years ago

Regarding the error restoring a MySQL database, it should be fixed by this patch : ef0a4cb

However, the error @c-prompt posted about pg_shadow looks like an unrelated PostgreSQL problem. Like Virtualmin is logging into PostgreSQL as a non-root user?

Thanks for the patch.

re: the pg_shadow error, yes, it appears either postgres backup (via the overall virtualmin backup) or restore (via the overall virtualmin restore) got hosed (I'm guessing because of different postgres versions and/or OS versions). I had to blow away all the postgres databases created via restore and then manually bring all databases over via:

Backup: pg_dump --clean -U postgres my_database > my_database.sql
Restore: psql -U postgres -d my_database -f my_database.sql

So I'm not going to open a new bug as I don't have enough specifics to suggest/direct where the problem occurred.

bold-gman commented 4 years ago

@jcameron I guess the fix is not yet released as 6.13 so far? Any other way I can test it? Sadly, I am quite new to git, so I don't exactly know what to do.

iliajie commented 4 years ago

@jcameron I guess the fix is not yet released as 6.13 so far? Any other way I can test it? Sadly, I am quite new to git, so I don't exactly know what to do.

You could update it as such:

On Debian/Ubuntu (On RHEL share should be replaced with libexec)

curl https://raw.githubusercontent.com/virtualmin/virtualmin-gpl/master/feature-mysql.pl -o /usr/share/webmin/virtual-server/feature-mysql.pl
iliajie commented 4 years ago

.. and the second file the same way..

curl https://raw.githubusercontent.com/virtualmin/virtualmin-gpl/master/virtual-server-lib-funcs.pl -o /usr/share/webmin/virtual-server/virtual-server-lib-funcs.pl

.. make sure to backup the files for easy rollback.. and make sure to restart Webmin after updating these files /etc/webmin/restart.

ftrojahn commented 4 years ago

I just checked mysql and noticed the user with a host IP had a password assigned but the same user with localhost did not have a password. Not sure why the localhost user didn't have a password but did find it odd that this server didn't show errors while servers (and sub-servers) having users (with both a host IP and localhost) with passwords and without passwords erred out the restore script.

This is from one of my mails I've sent to Jamie last year:

I've hit the problem now, too, when restoring "normal" domain without "." oder "-" and short domain name.

Howto reproduce:

  • create new virtualhost - same domain like in backup, only with needed features web site and mysql

  • restore from backup:

"Restore failed : SQL create user 'obfuscated'@'localhost' identified by password('') 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 '('')' at line 1"

I did a restore from the same backup file now, which produced the error last year, after checking out virtualmin-gpl master from github.

This worked OK for me, so I assume the patch fixed it, thank you very much Jamie and Ilia. Let's try the other things from my first post above ...

.. and the second file the same way..

curl https://raw.githubusercontent.com/virtualmin/virtualmin-gpl/master/virtual-server-lib-funcs.pl -o /usr/share/webmin/virtual-server/virtual-server-lib-funcs.pl

.. make sure to backup the files for easy rollback.. and make sure to restart Webmin after updating these files /etc/webmin/restart.

Just a remark: may be the shebang first line is different - "/usr/local/bin/perl" from github, but may be "/usr/bin/perl" e.g. when I have local debian package. This helps in this case:

ln -s /usr/bin/perl /usr/local/bin/perl
iliajie commented 4 years ago

"/usr/local/bin/perl" from github, but may be "/usr/bin/perl" e.g. when I have local debian package. This helps in this case:

Yes, symlinking is what I personally use too.

bold-gman commented 4 years ago

I am afraid it does not work for me. I downloaded files both on the new server as described and restarted the service, but the error persists.

Server 1:

Restoring backup for virtual server -.de ..

Restoring virtual server password, quota and other details ..
.. done

Updating administration password and quotas ..
.. done

Restoring Cron jobs ..
.. done

Extracting TAR file of home directory ..
.. done

Setting ownership of home directory ..
.. done

Restoring allowed MySQL hosts ..
.. done

Re-loading MySQL database <hostnamepart1>_<hostnamepart2>_de ..
.. done

Restoring Webmin ACL files ..
.. done

Re-creating mail and FTP users ..
Restore failed : SQL create user 'user1@<hostnamepart1>-'@'localhost' identified by password '<Password here>' failed : Operation CREATE USER failed for 'user1@<hostnamepart1>-'@'localhost'

Server 2:

Re-creating virtual server .de ..

Creating administration group <shortdomain>.de ..
.. done

Creating administration user <shortdomain>.de ..
.. done

Creating aliases for administration user ..
.. done

Adding administration user to groups ..
.. done

Creating home directory ..
.. done

Creating mailbox for administration user ..
.. done

Adding to email domains list ..
.. done

Adding default mail aliases ..
.. done

Adding new virtual website ..
.. done

Adding webserver user www-data to server's group ..
.. done

Performing other Apache configuration ..
.. done

Creating SSL certificate and private key ..
.. done

Adding new SSL virtual website ..
.. done

Setting up log file rotation ..
.. done

Creating MySQL login ..
.. MySQL database failed! : mysql::execute_sql_logged failed : SQL create user '<shortdomain>.de'@'localhost' identified by password password('') 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 'password('')' at line 1

Creating Webmin user ..
.. done

Saving server details ..
.. done

Applying web server configuration ..
.. done

Re-starting Webmin ..
.. done

Re-starting Usermin ..
.. done

Re-loading Webmin ..
.. done
Yorkki commented 4 years ago

Having the same issue, patch did not work.

From: CentOS Linux 7.7.1908, Webmin 1.941, Virtualmin 6.08.gpl, MariaDB 5.5.64

To: CentOS Linux 8.2.2004, Webmin 1.955, Virtualmin 6.12, MariaDB 10.3.17

Thanks, - Yorkki

Yorkki commented 4 years ago

Hi again. I have now transferred many sites, from old server to new. Specs in my previous post.

Now, all but one transferred fine. Here are details:

IF: Username for MySQL database ab-cdefghi.com (you can see '.' and '-' both in username) Password for MySQL database agR6aojgspuFCZfK (no special characters in pw) ...all works fine.

BUT: Username for MySQL database abcdefghijklmn.c (14+2 characters, ending with '.c') Password for MySQL database bqlK8RAx5BuhnGAa (no special characters in pw) ...the restore fails.

So, I'm probably shooting blanks, but could it be possible in my case, that the '.c' at the end of recommended max 16 chars is the cause? Virtualmin cut the username (domain) years ago when I created that site.

jcameron commented 3 years ago

Interesting - really Virtualmin shouldn't be creating MySQL users with a . in the name in the first place, which we'll fix.

That said, they should still work. Is it consistent that a username with a . followed by a single character always fails?

Yorkki commented 3 years ago

Seems not. Tested, created abc45678912345.com and old Virtualmin made the MySQL user as abc45678912345.c and it did work on new also (backup restore succesful), as abc45678912345.c ...weird. So not sure what made the one site/MySQL user fail.

jcameron commented 3 years ago

Maybe it was just a coincidence that the user ending with a .c ran into this issue?

ftrojahn commented 3 years ago

@Yorkki Regarding my start topic

Seems not. Tested, created abc45678912345.com and old Virtualmin made the MySQL user as abc45678912345.c and it did work on new also (backup restore succesful), as abc45678912345.c ...weird. So not sure what made the one site/MySQL user fail.

Are there by any change other users/vhosts on the same system using similar domain names, i.e. abc45678912345 (without .c) in your example?

bold-gman commented 3 years ago

I can add that the problem is not limited to restoring MySQL databases but seems to be connected to database user management in general.

  1. Restore a server without database feature
  2. Check server: one user was created.
  3. Activate database feature, get error: Creating MySQL login .. .. MySQL database failed! : mysql::execute_sql_logged failed : SQL create user '<mydomain.tld>'@'localhost' identified by password password('') 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 'password('')' at line 1
  4. Explicitly set the password for this user to the current, already used password: 
    
Modifying administration user ..
.. done

Updating Webmin user .. .. done

Updating Webmin user .. .. done

Saving server details .. .. done

Re-loading Webmin .. .. done

5. Activate database feature again, this time it's successful.

Creating MySQL login .. .. done

Creating MySQL database mydomain_tld .. .. done

Updating Webmin user .. .. done

Updating Webmin user .. .. done

Saving server details .. .. done

Re-loading Webmin .. .. done

6. Restore content of databases, it's successful

Extracting backup archive file .. .. done

Restoring backup for virtual server mydomain.de ..

Restoring allowed MySQL hosts ..
.. done

Deleting old MySQL databases ..
.. done

Re-loading MySQL database mydomain_tld ..
    Creating MySQL database mydomain_tld ..
    .. done

.. done

Updating Webmin user ..
.. done

Re-loading Webmin .. .. done

.. restore complete.

jcameron commented 3 years ago

I think the real issue here is that the password is empty, as shown by password('') in the SQL.

jcameron commented 3 years ago

Are you using hashed passwords on this Virtualmin system?

iliajie commented 3 years ago

I have been working on this issue yesterday for quite a while. You can help testing and fetch the latest feature-mysql.pl, restart Webmin and try restoring again. Anyone still seeing this issue, please send me a download link for a backup, using a form from my website. I would prefer to get it as soon as possible.

Before trying the patch above please backup /var/lib/mysql directory.

I am still on it today and it's way easier to address an issue while the memory of what is going on is fresh, so please don't hesitate to give it a try.

I would suggest upgrading both source and destination systems to have the same latest versions of Webmin and Virtualmin (1.955/6.12) before replacing mentioned feature-mysql.pl file and trying.

bold-gman commented 3 years ago

Are you using hashed passwords on this Virtualmin system?

I do.

I would suggest upgrading both source and destination systems to have the same latest versions of Webmin and Virtualmin (1.955/6.12) before replacing mentioned feature-mysql.pl file and trying.

To be clear, should i replace the file on both servers and then create a new backup?

iliajie commented 3 years ago

To be clear, should i replace the file on both servers and then create a new backup?

Target only.

bold-gman commented 3 years ago

I will try it in about two hours, after I left work.

iliajie commented 3 years ago

Okay. There is the final patch with large changes.

https://github.com/virtualmin/virtualmin-gpl/commit/d7dec417248fc7ae9638ceb5a43d564fbc88f087#diff-6fa2afd8e898593d63a1dacfb644de43

I haven't tested it yet with empty passwords or username clash. Will do now.

bold-gman commented 3 years ago

I downloaded the patch with this command (still new to github, want to make sure I get the right file version):

curl https://raw.githubusercontent.com/virtualmin/virtualmin-gpl/d7dec417248fc7ae9638ceb5a43d564fbc88f087/feature-mysql.pl -o /usr/share/webmin/virtual-server/feature-mysql.pl

It still won't create the databases or even enable the db feature when restoring. In addition it now does not stop when it encounters the error, I am not sure if that is intended behaviour (i choose not to ignore errors).


Re-creating virtual server <mydomain.tld> ..

    Creating administration group <mydomain.tld> ..
    .. done

    Creating administration user <mydomain.tld> ..
    .. done

    Creating aliases for administration user ..
    .. done

    Adding administration user to groups ..
    .. done

    Creating home directory ..
    .. done

    Creating mailbox for administration user ..
    .. done

    Adding to email domains list ..
    .. done

    Adding default mail aliases ..
    .. done

    Adding new virtual website ..
    .. done

    Adding webserver user www-data to server's group ..
    .. done

    Performing other Apache configuration ..
    .. done

    Creating SSL certificate and private key ..
    .. done

    Adding new SSL virtual website ..
    .. done

    Setting up log file rotation ..
    .. done

    Creating MySQL login ..
    .. MySQL database failed! : mysql::execute_sql_logged failed : SQL create user '<mydomain.tld>'@'localhost' identified by password password('') 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 'password('')' at line 1

    Creating Webmin user ..
    .. done

    Saving server details ..
    .. done

    Applying web server configuration ..
    .. done

    Re-starting Webmin ..
    .. done

    Re-starting Usermin ..
    .. done

    Re-loading Webmin ..
    .. done

Restoring backup for virtual server <mydomain.tld> ..

    Restoring virtual server password, quota and other details ..
    .. done

    Updating administration password and quotas ..
    .. done

    Restoring Cron jobs ..
    .. done

    Extracting TAR file of home directory ..
    .. done

    Setting ownership of home directory ..
    .. done

    Restoring Apache virtual host configuration ..
    .. done

    Checking restored PHP execution mode ..
    .. mode FCGId OK for this system

    Updating home directory in PHP configuration ..
    .. done

    Restoring Apache log files ..
    .. done

    Restoring SSL Apache virtual host configuration and certificate ..
    .. done

    Restoring Logrotate configuration ..
    .. done

    Restoring Webmin ACL files ..
    .. done

    Re-creating mail and FTP users ..
    .. done

    Re-creating mail aliases ..
    .. done

    Restoring mail and FTP user Cron jobs ..
    .. done

    Updating Webmin user ..
    .. done

Enabling PHP modules for restored scripts ..
.. no PHP modules needed to be installed

Applying web server configuration ..
.. done

Applying web server configuration ..
.. done

Re-starting Webmin ..
.. done

Re-starting Usermin ..
.. done

Re-loading Webmin ..
.. done

.. restore complete.

If I explictily enabled the feature I get this error:

Creating MySQL login ..
.. MySQL database failed! : mysql::execute_sql_logged failed : SQL create user '<mydomain.tld>'@'localhost' identified by password password('') 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 'password('')' at line 1

Updating Webmin user ..
.. done

Updating Webmin user ..
.. done

Saving server details ..
.. done

Re-loading Webmin ..
.. done
iliajie commented 3 years ago

Have you restarted Webmin? Could you send me the backup file?

bold-gman commented 3 years ago

I did restart the service.

While trying to find a backup that contained no sensitive data, so you could have it (it's still the internet, so I had to choose very carefully, I am sure you'll understand), I had an idea and did some more tests with other virtual server backups.

I had some interesting results:

  1. Blank or missing password I discovered that on the source server, for whatever reason, for one virtual server the user did indeed have a blank password in mysql-server. I do not know when or why it happened. After resetting the user password, the user is recovered, but has a privilage error (see issue 3) The error message was indeed right, but it could more helpful and maybe explain more and how to fix that. Or maybe there could be a check to avoid restoring those users.

  2. Error when restoring a SQL user - dash at end of username I had another virtual server named . Because of char limits, the mySQL user was shortend to user1@part1- (notice the dash at the end). After changing the username to user10, the mySQL user was shortened to user10@part. The user was now restored, but the rest is the same as the next error:

  3. MySQL user and DB is restored, but no privilges are granted, even for new users. For other virtual servers, everything is restored, no errors. But the mysql users have no privilages on the databases, same goes for new users. You have to assign the user rights manually via command line or phpmyadmin. The virtualmin UI cannot edit the user rights.

bold-gman commented 3 years ago

I had to edit my previous response after further testing, because it lacked details and was misleading. Beside the blank password, the core problem now are the missing user privileges.

iliajie commented 3 years ago

Yes, it's fixed already. You need the latest feature-mysql.pl file.

iliajie commented 3 years ago

While trying to find a backup that contained no sensitive data, so you could have it (it's still the internet, so I had to choose very carefully, I am sure you'll understand), I had an idea and did some more tests with other virtual server backups.

Like I mentioned, use my website's form to submit a link.

@ftrojahn @Yorkki - do you still see this issue with the latest feature-mysql.pl file?

ftrojahn commented 3 years ago

Last try was already successful:

I did a restore from the same backup file now, which produced the error last year, after checking out virtualmin-gpl master from github.

But I can do some tests over the weekend. Thanx anyway.