Debian squeeze support release schedule (also RHEL/CentOS 6)

Edit Feb 21, 2011: See

Howdy all,

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.

Long answer:

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 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 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 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.


gogogogogo! :slight_smile:

Thank you very much for all your hard work! Joe.

I’m not a dpkg/apt guru but I believe if you worked with meta packages a bit more, you might run into the clean up problem less often.

There is no documentation I could find for meta packages, but what mentions I did find seem to indicate virtualmin-base is already a meta-package, which is why it’s causing problems. Dependencies in dpkg kinda “go both ways”, whereas they don’t in yum/RPM. When you uninstall a meta-package on Debian, it marks all of its dependencies for removal as well. This is a problem for the way things currently work, because if you remove any dependency, it wants to remove all dependencies. With yum/RPM a package installed to satisfy a dependency does not automatically go away just because the thing that depended on it went away; it’s possible to clean up in that way, but you have to be intending to do so…with apt it just happens automatically (again, it warns you its going to happen, but apparently people don’t read apt output, because a number of people have deleted their Virtualmin installs by removing one or more of its dependencies).

You can use Recommends: instead of Depends: in the debian/control file for packages that aren’t 100% required. They will be installed by default now (or you can use apt-get --install-recommends to make sure they are). Then you can remove any of the recommended packages without it breaking dependencies.

Another point to make is the security updates that VM has – I always tell my clients to never install anything automatic and to make sure you set it to just notify you of a updates. Many people do not do this and run into the same issues Joe mentioned.

Also do not use cron-apt to auto upgrade if you aren’t going to be reading any output either… just have it download the packages and you upgrade in console.

why not use aptitude for package management? Not apt-get but aptitude…it’s much better about dependencies form what i’ve seen.

aptitude is deprecated in favor of apt-get in debian squeeze, the latter is recommended in the release notes.

rofl…roger that…:slight_smile:

I think you’ve misread the release notes. It only says that apt-get is recommended for non-interactive CLI and for upgrades. Aptitude is still the official APT frontend.

Well that mentions interactive package management explicitly, meaning the ncurses interface you get when running aptitude without parameters. The usage scenario for systems like Virtualmin is non-interactive, since they have their own interface to communicate with the user.

I managed to get Virtualmin GPL installed on a fresh Debian squeeze system. I had to make sure udev was installed since quota wants it and ensure it starts up after reboots. I also had to rebuild the quota files since they weren’t working. The process was:

  1. Install udev and reboot (might not be needed, but it’s a test system so why not…)

apt-get install udev

  1. Add this to /etc/apt/sources.list:

deb virtualmin-lenny main
deb virtualmin-universal main

  1. Run:

apt-get update
wget ; sh ./

  1. After Virtualmin installation, run:

insserv quota
rm -f /aquota.*
service quota start

I rebooted afterwards to make sure everything came up as expected. I’ve only briefly tested with a virtual domain so far but it looks good at first glance.

Did this, installed okay the first time but then trying to install other packages afterwards using apt-get (like postgrey) were throwing up errors.
Insserv which does the new concurrent booting in Squeeze does not seem to be able to figure out dependencies properly after the install.

Trying to remove virtualmin created a mess. Was ultimately able to clean it up (purge) and then removed insserv which reverts back to the old style of booting (takes longer but how often do you reboot?)
Was able to get it re-installed and will see how it goes.

Like to add I’m not a Debian guru by any means… so if anyone has any suggestions or advice on what I may have done better, please let me know.

you should install Webmin 1.534 from before installing virtualmin, as it is a development version with added debian 6.0 compatibility, that solves the dependency booting stuff afaik.

Thank you :slight_smile:

Is Debian squeeze officially supported yet on virtualmin gpl?

AFAIK, not yet)
Check for news)

You’re welcome to use aptitude or any other frontend you want. We certainly aren’t going to stop you.

But, aptitude is nonsensical in the context of our install script. It’s hard enough to convince apt-get to run non-interactively. I don’t even want to think about trying to run aptitude in a non-interactive scripted fashion. Also, I kinda find aptitude annoying and confusing, but maybe that’s just me.

Is Debian squeeze officially supported yet on virtualmin gpl?

Did you miss the entire rest of this thread? The entire point of posting this topic was to answer this question. (Hint: No.) :wink:

The OS Support page will be updated when it is officially supported, and I’ll be posting a testing version of the tomorrow sometime, as it appears to be working for me, but I don’t think it will work on older versions of Debian, so I’ll need to make some tweaks to make that happen.

It will not be kept secret when support is finished.