Upgrade from VMin to VMin Pro experiences?

Hey Brad,

Upgrades using the installer are not recommended in EA1. EA2 might get a GPL-to-Professional mode of operation in its installer (I've been working on it, but if I can squeak out a release before it is finished, I won't delay the release for it). It will certainly be in the install script within a week. I'd suggest waiting for that.

There's no reason why an upgrade can't go perfectly cleanly...it's just the installation script assumes a fresh OS install. And, since I've been working on it, I've realized an upgrade mode that doesn't touch any existing mail/web/etc. configuration, or install anything, is actually much easier to do than the full-featured installer. The tricky one is when a user wants to go from a hodge-podge Virtualmin GPL installation using random components and locations to a "like new" Virtualmin Professional installation with all of the services installed and configured like what you have at the end of a fresh OS installation.

There are dozens of problems to be dealt with, and many of them just aren't possible to address in a sane way. For example, it is possible to use Virtualmin with vpopmail/qmail and LDAP mail users. While the Maildir spools won't cause any trouble, the LDAP users and such won't work with Postfix and would have to be converted. AV and spam filtering can be addressed in dozens of ways (or not at all), and our method is unique (to my knowledge) and allows for per-domain flexibility while still using standard, mature, and simple tools (procmail, predominantly). Converting to this from any other random method in an automated fashion is just going to be impossible. Just the most common four options (procmail, Mailscanner, Cyrus Sieve and amavisd-new) have practically infinite configuration possibilities. So, it is pretty likely that upgrades will, for the foreseeable future, perform an upgrade of all of the Webmin modules and themes, install some extra components, enable the software updates, but leave the Virtualmin configuration exactly as they were to start with. This is probably what most folks want, anyway, but definitely worth being aware of.

Flexibility has its costs, and Virtualmin is sometimes too flexible for my sanity (but it's also one of the biggest reasons folks love it and Webmin so much, so I can't complain too much). ;-)

Joe is right, there are many 'gotchas'. I have actually done this, most went pretty smoothly, but there were a few areas that caused a great deal of hair pulling, took a few weeks to get smoothed out.

Having said that, my situation was probably quite unique in that the I moved to a new server as part of the upgrade, so bear that in mind.

Here's what I did.

1. Install OS on new server, clean up the 'trash' RHEL3 give you by default, tweak a few security settings.

2. Install fresh Virtualmin Pro (EA1) Went smoothly only a few issues which were ably resolved by Joe.

3. Restore backup of /home/httpd from existing server. Also note my system (GPL and Pro) uses a custom doc root /home/httpd/vhosts/sitename.

- Mail

I reconfigured Vmin Pro to use /var/spool/mail for users mailboxes (same as sendmail under GPL) This was a disaster. I don't recommend it. If you have existing mail under sendmail, you NEED to set up Vmin Pro in a staging environment and carefully plan a conversion to postfix mail under /home or spend some time with Vmin pro to understand how it sets up mail and continue using sendmail. I had to re-do this several time before I got it 'working' I still have manually create mailboxes for some reason. In the end I abandoned the Vmin pro mail setup and do all my mail work in the Postfix module. This will probly not work in a 'hosting' environment.

- File ownership and attributes for all files under /home/httpd.

Because Linux uses numeric user id's stored with each file, and user names are mapped to the file based id's, you have a 'permissions database' That is scattered across the entire machine, with the indexes in /etc/passwd and /etc/group. Since the realtionship between user names/id's are generally not predictable this makes restoring 'problematic' to say the least.

I had only 14 sites and about 20 users, I also control all sites and users. This is a small business system. For a hosting company with 100's of sites, this could get to be 'messy'. The solution is probably to merge /etc/passwd /etc/group and /etc/shadow by hand. On the other hand if you can do an in-place up grade (restore the entire system to your staging server) that should eliminate this issue, but as Joe pointed out would create others.

- Usermin

Just plain broken as far as security is concerned. The default install seems to have an 'allow all' permission default. That is, any user who can log in to Usermin and open the file manager is able to browse the entire server! they can't do anything that Linux file permissions don't allow, but in most cases that still allows them to read you /etc/passwd file... I was not able to get Usermin and the file manager to restrict users to their home directory.

Under the GPL version, Usermin was used for file manager access only, so I just turned it off. I have set up Webmin accounts restricted to file manager only for those users who really need it. When I get the time to research a faster, more user-friendly file manager, I will install that on a per domain basis. Again for a large hosting environment, this is an issue that would have to be worked out.

=======================================

Beyond the above there were a very few install problems and those were quickly resolved with Joe's help. Everything else is working pretty well.

Please note that I have not asked for help with any of the above big three,
I simply did not have the time. So if you have a little more patience than I, and use the support ticket system to get help (which is very good I might add) these issues are probably resolvable.

The bottom line is that this a major upgrade, kind of like installing an OS upgrade. You need to do it on a staging server.

Regards,

-Glen