Edit Feb 21, 2011: See https://www.virtualmin.com/node/17272
Since we’ve had a lot of requests for information about squeeze via every possible channel, I thought I’d post a news item about it here, so we can answer everyone in one go, rather than taking time out several times a day to explain how new OS support comes about and how long it takes after a new distro version is released.
Short answer: squeeze will be supported in about a week. RHEL6 (and CentOS 6) will probably be supported in two weeks.
We don’t even try to support beta or pre-release or release candidate operating systems, because they are moving targets, and we expect the people who need the install script to be the same people that need a predictable and stable platform on which to build their hosting infrastructure. So, we begin working on support in install.sh and our software repository within a day or two of the new OS version being released.
The process of building new OS support usually does not require major install.sh changes, and is mostly a matter of building the software repository for the new OS. Debian and Ubuntu moved to the two-repo layout in their most recent versions (where there is a virtualmin-osname and virtualmin-universal repo, where universal contains all the Webmin/Virtualmin packages, which never need to be rebuilt for new systems), which speeds up the development process quite a bit. They also moved to using the apache2-suexec-custom package, which sped it up even more, since we no longer have to maintain Apache packages for that distro. At this point, if everything goes perfectly, we can theoretically add support for a new Debian or Ubuntu version in a couple of days of steady work, plus a day of testing. Confounding that, however, is the apt-get/dpkg problem.
Some assumptions I made in the installation process in the past have begun to bite us in the ass lately in ways that I never would have predicted. apt-get/dpkg does not handle dependencies in the same way as yum/RPM, and in fact, it has some terrifying behaviors for packages that have been installed to resolve dependencies…as soon as those dependencies are no longer present, dpkg uninstalls everything that was installed based on dependencies. Meaning that people who aren’t careful when using the package manager could pretty easily uninstall Virtualmin and all of its packages. It’ll tell you it’s gonna happen, but it’s pretty wordy output, and people who are in the habit of just saying yes to everything the package manager says could end up with a very unpleasant surprise when they try to login to Virtualmin later. (Hint: Don’t do that!)
So, obviously this problem has to be fixed before we can call squeeze supported. I’m not yet entirely sure how to fix it, however, so it will require more testing and documentation reading than I usually have to do. It probably also means that install.sh will get some major changes (which I hate to do, because it then has to be tested across all systems that the changes could effect, but it seems like we have to move all of the dependency resolution out of the virtualmin-base package and into a script, so that removing any one part of the Virtualmin system–even something seemingly unimportant–won’t cause the entirety of the rest of it to be removed).
Oh, and a longer answer on the RHEL 6 and CentOS 6 front:
I’m not sure, but probably a week or two. CentOS 6 isn’t actually out yet, which is a confounding issue, since we don’t have money lying around to buy RHEL6 licenses (32 and 64 bit are both needed) that we only need for a few days to add support to the installer (we don’t have a lot of RHEL users, so it’s hard to justify a big software expense for so few customers). Hopefully, a CentOS 6 build will show up shortly. Looks like the 17th is the planned beta release, so I can probably start working on it then, and three days after that it’ll be built and tested.