I tried to delete everything via yum fromt he gpl virtualmin(i removed webmin…msql…bind…etc etc(aka everything) before i installed virtualmin pro.
This is not an indictment of virtualmin BUt if you want to install the pro version wipe the box compoletly first(reinstall and reformat). you’ll save yourself a ton of headcaches. I hope you all ge the virtualmin gpl to virtualmin pro figured out. It unfortunatly totally knackered my machine.
It’s far less dramatic than all that. Drop me an email at email@example.com with your system details and I’ll login and help you fix whatever got broken–it’s probably just mail configuration that’s broken (as the FAQ points out, there are a couple dozen possible configurations and only one of them matches what we setup, which is why there are warnings all over the place about upgrading not being supported by the installer yet).
Actually, I suspect removing "everything" did far more damage than the install.sh. The only thing you need to remove to make the install complete successfully are the Virtualmin modules (assuming Webmin was installed from the RPM from webmin.com, and if not, upgrading via install.sh is not an option at all). Removing "everything" means a lot of configuration got lost completely (unless you have backups).
I know this is all closing the barn door after the cows have gotten away, but it’s worth mentioning. I’ll modify the FAQ about upgrades to indicate that if you are going to attempt an upgrade from Virtualmin GPL (still not recommended!), then you shouldn’t remove everything–just the Virtualmin modules in /usr/libexec/webmin. Everything else is better left alone, and fixed after the install. Webmin’s /etc directory definitely shouldn’t be touched if you have virtual servers configured in Virtualmin GPL that you don’t want to lose.
All of this complexity is the reason we are not recommending anyone use install.sh to perform an upgrade (yet).
i have already shutdown the machine and requested a reformat/reload. first apache failed. I had to manually remove the backup config files. Then bind failed. after that proftpd went down. the icing was when mysql failed and would not come back online even after a reinstall.
Wow. I can’t imagine how all of that occurred because of install.sh and virtualmin-base. We don’t do that much configuration.
In Apache, we add a NameVirtualHost directive, and nothing else on Red Hat based systems. On SUSE we configure SSL and a few other modules using /etc/sysconfig/apache2. On Debian we do the same things as SUSE using a2enmod and editing /etc/apache2/ports.conf. No major changes. (It is, however, a custom Apache package on all platforms, because we need suexec_docroot pointing to /home.)
In BIND we configure a chroot and make sure all of the directories exist. (And actually this doesn’t do anything on Red Hat based systems, because there’s a package that does the same things.)
In Proftpd we do nothing. Just install it, and set it to start on boot. No configuration at all. On some platforms it’s our package (because Red Hat based systems don’t provide it), while on others it is the system default package.
MySQL also gets no configuration, just started up and configured to start on boot.
I’m not at all sure what could have gone so horribly awry on your box, but I certainly hope things go smoother for you on the next install. Please let us know if they don’t, however, and we’ll work through the troubles with you. Almost anything that can go wrong is well understood at this point and easily corrected.
nods i am starting the install now from a centos 4.4 minimal install…