Hi all,
I just purchased downloaded the most recent install.sh and it is informing me that it cannot upgrade an existing virtualmin GPL install.
This is a problem since my clients need full access to change their e-mail accounts.
This effects a server which has not yet gone into production for clients, so it’s not a rush item for me. Though an ETA as to when this may be solved would be appreciated.
Michael
Hey Michael,
It gets better in every release (upgrading to Pro from GPL), and at this point some upgrades work OK. There are a few things to be wary of:
Alway, always, ALWAYS, have a known-good backup. You have those anyway, I’m sure, but make sure that your backups are good and recoverable.
Think about how your system is currently configured vs. how the Virtualmin Professional system is setup by default…the closer your system is to our defaults, the nicer your upgrade will go. The areas where you differ are the areas you’ll need to double check before putting the box into production after the upgrade.
The Pro setup is:
Postfix SMTP
Maildir mail spools
Domains live in /home (thus quotas, suexec-docroot, etc. is setup for /home)
Procmail is delivery agent, with a custom recipe to forward through spamassassin and clamav
Everything installed using system default packages. Nothing fruity from oddball software sources, and no tarball source installs.
Those are the areas that are most likely to get messed up during an upgrade. Webmin can also be a problem if you’ve installed from any source other than the RPM from Webmin.com (i.e. DAG, etc.), or if your Webmin installation didn’t turn out quite right (as happened with CentOS 4.2 in some older versions of Webmin–check to be sure your OS was correctly detected during Webmin installation, and if not, backup your /etc/webmin and re-install).
Really, what it comes down to is that if your system looks a lot like what we are deploying, an upgrade will work. But there are so many possibilities for differences due to the flexibility of Virtualmin and Webmin, that I cannot possibly suggest that it will be painless to upgrade from GPL. We just can’t guess how you’ve configured your system, and when we change a bunch of stuff, things could very well break pretty badly. So, I warn of the trouble quite strongly (and I’m not being overly cautious…I’ve seen upgrade attempts that failed in moderately uncomfortable ways).
If the system is not a production system, and you’re willing to work with us on the things that go wrong, give it a try (after confirming you have a good recoverable backup of everything on the system!). We’ll help you work through anything that goes wrong.
To make the process a bit nicer, you could let me know what choices you’ve made in your deployment (SMTP, spool type, file locations, etc.), and I can give you advance notice about what’s probably gonna break, if anything.
Oh, yeah, to answer your question about when a safe and easy upgrade path will be available: Before the Early Adopter period ends. I don’t know precisely when that will be. It is one of my top priorities, along with other OS support.
Joe,
No problem.
The box I’m deploying vitualmin on is only serving two domains as a test. I’m going to assume that I can temporarily migrate those domains off the server, simply remove the GPL module, install the commercial module, go through configuration and deploy as previously planned?
It appears that some of my preconfiguration is made moot by the capabilities of the module.
If the above is valid, it saves me a lot of hassle. Though based on your comments, I may just re-install the box from scratch and see what you have done with the pro module.
Below is my technical situation, which is long and ridiculous…
I’ve got a RHEL 3 server as my primary mail exchanger. Some of the domains served by that box are in virtualmin, some are not. This box has been upgraded many times and has data contiguance hailing back to RH 7. While it remains secure, there’s a LOT of custom code and management headache with a box that has been serving that long (hence the upgrade). It uses procmail for delivery, inbox in /var/spool/mail, IMAP folders in home (Dovecot), clamav-milter for antivir, some self written perl code for detecting rumplestiltskin attacks and blocking via firewall, a mailman listserver (Thousands! of e-mail addresses on multiple lists!!) and spamassassin through procmail for detecting and filing spam into user spam folders. There’s also some mail aliasing to sa-learn for sharpening of the spam filters.
I maintain two codebases myself, one for clamav, one for spamassassin; both slightly altered and compiled off server then deployed to server.
Since that box is being retired, I have to move my clients to a new mail server, which in preparation was setup as a RHEL 4 sendmail box. On this server, my intention was to use virtualmin as an interface for any domain I host, thus lowering my client contact. This box having been stress tested now has a total of 2 domains (my testbed).
Since manually moving the mail data or mail configurations from box to box is not a problem for me, my plan was to do the following:
Deploy new box, configure, test, secure, and make critical software decisions. Done.
Install virtualmin in preparation for rollout.
Create all domains in virtualmin, and simply spend 8 hours moving the mailbox data from the old machine to the new machine during Sunday night downtime.
Sleep late Monday.
I’m fairly confident that moving primary MX to postfix would be a major tragedy for me since so much code would have to be tossed, and a MAJOR MAJOR MAJOR reconfiguration done in so many areas.
Eeeek… scary. I don’t want to even think about it.
I keep getting tempted by postfix, but I have so much sendmail in my skillset, so many niggling little pieces of code in the mix, and time management problems…
That’s the picture.