I need to migrate webmaster, mail, and ftp accounts from another control panel to Virtualmin.
I need to address two issues with that:
They follow their own naming conventions. I foresee problems with FTP users, which have names like smith (the general FTP account for the server administrator), or smith-ftp1 (an FTP subaccount, restricted to a subdirectory of administrator smith’s directory tree). Mail users might be a slight problem, too, they are named like email@example.com, which requires Virtualmin to jump through some extra hoops - what I tested worked ok though.
So… is it possible to create FTP accounts with a manually-set user name? This needs to be done only once for migration, afterwards I’ll be happy to stick with whatever naming scheme Virtualmin uses.
For all kinds of accounts, passwords are generally stored in encrypted form only. Can I even set up an account when no unencrypted form of the password known?
The formats I’m seeing are: The $1$ form in /etc/shadow, a 13-character form that’s supposed to originate from Linux crypt() via Mysql’s ENCRYPT, and a 32-character hexadecimal string that probably originates from PHP’s MD5 (this is also available in $1$ form).
Which control panel are you looking to migrate from?
Virtualmin supports importing the backup files of a number of control panels – you can see the option in Add Servers -> Migrate Virtual Server… look at the various options in “Backup file type”.
It’s not in the list. (Which does not surprise me, for a number of reasons.)
So… is it possible to create FTP accounts with a manually-set user name?
I unfortunately don’t know of a good way to do that… you’d have to stick with whatever username format Virtualmin is configured to use.
I wouldn’t worry too much about the email users though, users with @ in their names do work just fine and a lot of folks use that.
Can I even set up an account when no unencrypted form of the password known?
One option is that after creating the accounts with some new, random, password – edit /etc/shadow, and manually copy in the old encrypted password in place of the existing password.
What Virtualmin has stored in it will be out of sync at that point, and will be until the user changes their password… but, it would work to allow your users to use their old passwords.
That doesn’t handle MySQL passwords though – you’d also need to find a way to set those. However, you could again manually copy the encrypted passwords from the MySQL user table.
OK, I’ll fall back to telling FTP users to establish a new account then. Those are just a small fraction anyway, most people never establish secondary FTP accounts anyway.
[EDIT] On second thinking: is there any risk of malfunction involved with Virtualmin’s and the mail/Unix/whatever system out of sync about what the password is? E.g. Virtualmin accidentally overwriting the password with what it thinks it should be, or some subsystem of Virtualmin using the (wrong) password while doing something on behalf of the user.
Mysql passwords are not an issue - I’ll simply create those accounts manually. Since I have to transfer the databases anyway, making sure that the Mysql user accounts get copied as well isn’t that hard.
On second thinking: is there any risk of malfunction involved with Virtualmin’s and the mail/Unix/whatever system out of sync about what the password is? E.g. Virtualmin accidentally overwriting the password with what it thinks it should be, or some subsystem of Virtualmin using the (wrong) password while doing something on behalf of the user.
If you’re using Virtualmin Pro, and installing an application from the install scripts (such as Wordpress, for example), that means Virtualmin will add the wrong password to the Wordpress config file.
Also, if you were going to go into Edit Mail Users, and you click “View Mail in Usermin”, it wouldn’t be able to correctly log in.
Lastly, if you back up the Virtual Server, and later restore it, it’ll restore with the wrong password.
Outside of issues like those – you should be fine. Except for the Install Scripts, it’s not likely to come up very much.