migration misses items

I've managed to get the migrate instructions to work to duplicate my vps hosting. However, it doesn't do all of it. Rather than the default of user=domain, database=domain for extra security I have user as a different name, not an email address. Likewise database name is not domain either. Restoring virtualmin creates my database, but it does not create the user.

BTW I followed the instructions here, https://www.virtualmin.com/node/16245, to create under webmin a mysql user.

FYI what I find missing from a virtualmin restore is:

Cron jobs
usermin theme, selection and install
webmin theme, selection and install
webmin SSL certs
mysql database users
procmail filters

The only safe way to restore those for a migration seems to be by hand. Arguably msql database users for virtual sites should be recreated by virtualmin restore. It would be nice if the restore script also gave the option to set localtime, cron jobs, and procmail filters.



Howdy -- the Virtualmin backup and restore process would only include database users if that user was created within the Virtualmin Virtual Server.

Any database users created outside of that would need to be manually migrated. For that reason, we'd generally recommend always creating databases and database users from within Virtualmin.

However, if that user was part of a Virtual Server, it should work well at that point.

It also restores cron jobs that belong to users that are part of a Virtual Server.

Normally, procmail rules would be stored in the home directory in a file named .procmailrc -- those would be included as part of the Virtual Server backups as well. If there are procmail rules being used that are outside that of the home directory, those wouldn't be included.

Changes to system config files, such as the time zone settings, would need to be manually set.

I'll ask Jamie if there's a way to easily migrate the Webmin SSL cert and theme settings.

The trouble is that you can't create a virtual server user that isn't also an email user. Which is why I went for the 2nd option in https://www.virtualmin.com/node/16245.

But, I've done a mysl dump of the mysql database which I think is where users are stored. Comparing the file difference between the restore and the original what I see is:

Original, database name = domain_something, user = somebody Restore, database name = domain\_something, user = domain

For some reason it has inserted \ into the database name before the _ . It has also used the default domain user name as the user, which is not what was in the current setup. User domain is not a database user in the original site.

For cron jobs I had these as user nobody. They are just a curl URL to trigger the site cron tasks. It sounds like these should be user domain then and then they would be backed up? There is no way to set cron jobs from virtual server is there that I've missed?

The procmail rule I added in servers->procmail. There doesn't seem to be a way to do this in the virtual servers so I guess this needs to be cut out of the master procmail and added by hand to .procmailrc in the home directory.

BTW virtualmin creates the actual database correctly, so domain_something db is created. But look in database permissions and it has domain_something with user ..... If I dump db "mysql" and load that this fixed the permissions and loads the missing users (and deletes the added users).

Yeah, you appear to be going against the grain a bit as far as how Virtualmin was designed to be used :-)

Our recommendation is to use Virtualmin's mechanism for creating users... even though it creates a system user, it doesn't have a login shell. Also, you can disable email with it so that it can't receive any email.

Doing that would make it so that your database users are included in your backups (and restored when restoring them).

If you don't do that, then you may need to manually re-create each database user individually.

Regarding cron jobs, you can create cron jobs for any of the users created in your Virtual Servers. Any cron jobs for users in your Virtual Servers are automatically backed up. You can create those using Webmin Modules -> Scheduled Cron Jobs.

Regarding procmail -- any changes you make to system files would need to be manually copied over as well. Alternatively, you could use Usermin to create procmail entries, which would place the procmail filters in the user's home directory (and would thus be included as part of the Virtualmin backups).

I'll ask Jamie about migrating themes and the Webmin SSL certificate, and I'll get back to you regarding that.

However, other than that -- it sounds like Webmin and Virtualmin are functioning as intended. Since you don't appear to be seeing a bug, and it looks like you're using Virtualmin GPL there, we'd encourage you to use the Forums for any additional questions. We monitor the forums, along with lots of wonderful folks in the community. Thanks!

What about the restore virtualmin? It's a bug that it inserts the \ when database name contains _ and it just does that in the database permissions. The restore recreates domain_something ok.

I'll have a play and see if making the user a virtualmin user stops that from happening or whether it is the _ that is key. But either way that is bug. You should be restoring the users/permissions for db used by a domain.

Putting a \ before the database name does seem like a bug - perhaps related to escaping.

So were the users with this problem migrated using the Virtualmin backup/restore process?

Yes, followed the instruction on https://www.virtualmin.com/node/16245 for migrate.

I tried mysql backup and the install in a new database with the _ in the name. Then did a backup/restore. No \ in the database name the user is linked to so looks like it is the _ in the database name. domain-name work ok (i.e. - not _ ).

After a restore I get the error when I run my drupal site of: Access denied for user 'xxxx'@'localhost' (using password: YES). I guess this is because virtualmin backup assumes the password is the same for all where as I probably have a different one on the database (like I used to have a different user). I tried changing the main admin password for that virtual server but that did not propagate to change the database password. That I had to do in webmin->servers-mysql->user permissions. Maybe another bug there. You would expect changing the admin password to do them all, email, ssh, ftp and database.

By default a change to the admin password for a domain will also update the MySQL password - however, since this can interfere with passwords stored in app config files, Virtualmin allows them MySQL password to be kept separately. This is set on the Passwords tab of the Edit Databases page.

Right, I see now. Can I suggest that the migration page has a list of do's and don't's. My list is:

Don't use _ in database names, - is ok (until the bug is fixed)
Don't create a database user under webmin (virtualmin won't back that up)
Do use a virtualmin user for databases (virtualmin will back this up)
Don't change database user password under webmin (virtualmin won't restore that)
Do use virtualmin servers->server->Edit databases->password (so virtulamin restore works)

FYI of people reading this virtualmin servers->server->Edit databases->change password stores the password in plain text but since typically this would also be in plain text in say drupal's setting file I don't see this as a security risk myself. But there may be other cases where it is. mysql user passwords are stored only as hashes if that option is selected.

BTW can virtualmin cope with multiple database users and multiple passwords? I added a second user to the database but show password just has the one password. I assume there is just the one password for all users and all that servers databases, unless you create users under webmin which virtualmin doesn't then backup.

The alternative if the above limitations are not acceptable to people is to accept that when restoring you will need to recreate the users and/or passwords (backing up mysql database and restoring that seems to work too but I'm not sure if that could mess up things).