1. I am going to host hundreds of domains and each one has tens of mailboxes. I dont want to end up with a huge /etc/passwd file. I want to take advantage of the postfix's virtual mailbox capabilities. So:
a) How can I make virtualmin NOT create a unix account for every mailbox? I would like the mailboxes to be just that. No ordinary unix accounts associated with them.
Unless you plan to have thousands of mailboxes, /etc/passwd is the most efficient method of storing them. 1000 lines in a text file can be kept in memory easily and is incredibly fast to search in Perl, and in the various system utilities that use it. There is no performance reason to avoid /etc/passwd–it will be faster than all database-backed alternatives until you’re talking about thousands of mailboxes.
That said, LDAP is pretty well-supported for this purpose. You still have user accounts–it’s core to how the full stack works. All of the mail processing tools rely on having using accounts (because you couldn’t easily have/manage personal bayesian databases and mail folders and such, Usermin wouldn’t work for webmail, and lots of other features that Virtualmin provides would not be available). We have no plans to switch to non-user based mailboxes.
Besides the fact that performance of a plain text file with a thousand lines cached in RAM is faster than a database lookup, performance problems are going to happen in the spam and AV filtering stages, not in the user lookup, delivery, or authentication stages.
b) How do I integrate mySQL into this ?
We’d recommend you not do so. MySQL wasn’t designed for simple key value data, the way LDAP was. LDAP is a better platform for system and user data, if you really do want to use a database.
c) In version 3.55 the Change log says: "For alias domains whose virtusers are always copied from the target, no home directory is created" Is this the solution? Is it documented somewhere ???
No, this is talking about aliases, which are not real users–just mail names that deliver somewhere else. It provides no authentication and no local delivery.
2. How do I upgrade from 3.54 PRO to 3.55 PRO ? Which the cleanest way ? (NOT The simplest!!!)
3.55 isn’t out yet. When it is it will appear on your System Information page in the Virtualmin Package Updates section. The cleanest way to upgrade is to click the Upgrade Now button. This uses the package manager of your OS, if possible, to upgrade the package.
3. Also in changelog of 3.55 it says: "migrate-domain.pl script from Virtualmin GPL, which allows migration from cPanel, Plesk and Ensim at the command line". Is it documented in detail anywhere how to do this for Plesk (e.g. should I take a backup from Plesk first, or the ssh can work from a live system?).
You create a backup archive on the Plesk system, copy it to your Virtualmin system (if Plesk can use SSH to automatically put the backup file on your Virtualmin system that’s fine too). If the file is small (like a few MB) you can also download it to your PC and upload it using the form in Virtualmin.
In Virtualmin click on "Migrate Server" in the "Add Servers" menu.
Select the backup file.
Select the Plesk backup file type.
You may, or may not, need to provide the domain name (it depends on the backup, though I think we’re able to detect it in most backup types and versions now, it’s probably safer to provide it).
Fill out any other options you want to change–though most are probably fine as defaults.
Click Migrate Now.
If anything blows up, file a bug and we’ll help you get the migration completed. Migration is a black art, because Jamie has to reverse engineer the backup format–every new version introduces new twists, so if we haven’t seen a backup file from your version before we might need to tweak things a bit.
If you really wanted to do it from the command line (which is what that changelog was about) you can always get help from the command line tools by running them with no options, e.g., on Debian/Ubuntu:
/usr/share/webmin/virtual-server/migrate-domain.pl