Open ftrojahn opened 4 years ago
Which MySQL version are the source and destination systems running?
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
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 ..
Just sent a mail to you with download link and further details.
I've hit the problem now, too, when restoring "normal" domain without "." or "-" and short domain name. How to reproduce:
create new virtualhost - same domain like in backup, enabled only features web site and mysql
restore same domain from backup:
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.
In this case, is abcdefghij
the domain owner or an additional user?
Did you get my private mail(s)?
No .. what email address did you send it from?
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?
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.
@bold-gman are you restoring from a system running the same MariaDB version?
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
@bold-gman are you running Virtualmin 6.12 there?
@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.)
I think I see what the cause of this could be. Is your Virtualmin system using a remote MySQL server?
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).
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
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.)
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.
Can confirm, the workaround did not solve the issue.
My users are only allowed a connection from the localhost.
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.
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?
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.
@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.
@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
.. 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
.
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
"/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.
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
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
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
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
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.
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?
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.
Maybe it was just a coincidence that the user ending with a .c ran into this issue?
@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?
I can add that the problem is not limited to restoring MySQL databases but seems to be connected to database user management in general.
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
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.
I think the real issue here is that the password is empty, as shown by password('')
in the SQL.
Are you using hashed passwords on this Virtualmin system?
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.
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?
To be clear, should i replace the file on both servers and then create a new backup?
Target only.
I will try it in about two hours, after I left work.
Okay. There is the final patch with large changes.
I haven't tested it yet with empty passwords or username clash. Will do now.
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
Have you restarted Webmin? Could you send me the backup file?
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:
Blank or missing password
I discovered that on the source server, for whatever reason, for one virtual server the user
Error when restoring a SQL user - dash at end of username
I had another virtual server named
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.
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.
Yes, it's fixed already. You need the latest feature-mysql.pl
file.
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?
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.
[ ] fails creating mariadb user, if there is a "-" oder "." in the name (other cases not tested), then stops. IMHO it works, if only letters in mysql user name
[ ] mysql feature enabled on old server/in backup, does not enable mysql on new server/restore
[ ] php_admin_value in apache2 conf not corrected, if mod_php is disabled -> no error notice! -> apache2 fails on next restart
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:
After that, user permissions were missing. Database permissions after that:
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
while this workaround is fine in this case, question remains: if I transfer or restore a vhost with "mysql feature enabled", using "over-write existing domain", the mysql feature on the target system is not reenabled. Why is this?
feature request: like on restore, may be we could have some options to select, which features should be transfered to new system? This would make it much better, if e.g. only mails, database, files or whatever should go to the other system.
regarding the
php_admin_value
(and php_value) problem, as mentioned in #96 - this hits us here, too. I can only check using ssh or console: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