Annvix Development Blog

Annvix 3.0-RELEASE (Freya) is now available!

Today marks the fifth public release of the Annvix Linux distribution. February 4th, 2007 marked the release of 2.0-RELEASE; this version is the fruit of almost a year’s worth of hard work. We believe that 3.0-RELEASE is the best version of Annvix available. It is recommended that everyone using 2.0-RELEASE upgrade, as it is no longer supported.

Some of the new features you can find in 3.0-RELEASE include:

- 2.6.22.15 kernel with AppArmor support (RSBAC is no longer supported)
- updated services including PHP 5.2.5, MySQL 5.0.51, PostgreSQL 8.2.5, Apache 2.2.6, and Samba 3.0.28
- many other upgraded system packages, including Glibc 2.6.1

Version 3.0-RELEASE can be downloaded from the mirror sites listed at:

http://annvix.org/Download

Read the full release notes for 3.0-RELEASE as well, especially if you are upgrading from 2.0-RELEASE:

http://annvix.org/Release_Notes/3.0

If you use and like Annvix, please consider making a donation to the project.

There’s some really good news in ports-land tonight (this morning?). I’ve just got a preliminary dependency resolver implemented in the builder script along with a few other fixes and tweaks. It actually works quite nicely although I need to make it less prone to breaking and to handle deeper nested dependencies. This isn’t urgent as there’s only a few packages that have ports-based dependencies.

With annvix-ports 1.8, I built autogen (builder -p autogen), which required guile, which in turn required umb-scheme. builder did the right thing… it built and installed umb-scheme first, then guile, installed it, then built autogen. And was successful. =) Of course, if umb-scheme required something else, or if guile and autogen both required something else, I’m not sure how well it would hold up. Like I said, it’s preliminary, but it handles the scenario we currently have in ports (AFAIC, there are no other inter-ports-dependencies right now).

This is probably the biggest “issue” I had with ports, and it’s just been solved, which is nice. No, it’s not perfect, but it’s working and gives me the basis to tweak and refine it further although as things sit right now, until I have a more complicated “test scenario” I really can only theorize how it will work.

Of course, only 2.1-CURRENT is getting the new builder. 2.0-RELEASE is pretty much done; at the rate I’m going, if all goes well, 3.0-RELEASE will be available for Christmas. =)

I plan on doing my upgrades this week, but so far so good… I have a (working in vmware/testing) script that will upgrade 2.0-RELEASE to 2.1-CURRENT and so far it does it quite well. The only thing I’m unhappy about is it requires a double-reboot… the installer creates a “fat” initrd image with all of the IDE drivers in it for the first reboot, and then some hooks in rc.local execute on the first reboot to setup the ide-controller settings in /etc/modprobe.conf and then regenerates the initrd image. The next reboot will use the proper module (loading one instead of a dozen or so), and is highly recommended to make sure the script got it right (I don’t anticipate problems as it’s roughly the same code the installer uses).

I’ll be putting it to a real test tomorrow probably when I upgrade the build machine and if that goes well, I’ll probably be going through the rest of the machines to upgrade them all too. I don’t anticipate any major problems. The upgrade script can be downloaded here for those of you interested in testing or upgrading yourself (and testing is very much welcome!).

Version freeze for 3.0-RELEASE is set for the 17th. A new beta ISO should also be available then which, barring any bugs, will be the last.

Also, having an interesting issue with upgrades. A simple change in /etc/apt/sources.list followed by “apt-get update && apt-get dist-upgrade” seems to take care of everything *except* the new IDE drivers. 2.6.17 has no concept of these, so kudzu and whatnot don’t look for or find them. Of course, if you’re booting off an IDE drive, the kernel will panic on reboot because there is no defined ide-controller module in /etc/modprobe.conf, which is where mkinitrd is pulling info from in order to build the initrd image when the new kernel gets installed.

So I’m at a bit of a loss here. How do you detect this without actually running the 2.6.22 kernel with the drivers? I.e. if there is no current module as “piix” in 2.6.16, but you need that to properly boot 2.6.22, how do you detect or figure that out, short of booting off an Annvix install CD, seeing what IDE modules are loaded, then rebooting back into Annvix, updating modprobe.conf, and then starting the upgrade?

That’s kind of a sucky way to have to do an upgrade, but I’m not sure how to do this detection. Anyone have any ideas? Of course, this is only a problem for people booting off IDE drives; SATA and SCSI boot drives should be fine (and even with IDE drives, they may not mount on boot, but then you’ll be able to take advantage of kudzu’s detection and modify /etc/modprobe.conf accordingly).

From what I can see right now, this is the *only* upgrade issue.

The first beta release of 2.1-CURRENT is now available. This is the first release of the install image that will be the forthcoming 3.0-RELEASE.

It would be fantastic to get some good testing on this one. This is the first install image with the new 2.6.22 kernel, and the new kernel that will cover all “flavours”. In other words, there is no longer a -BOOT, -up, and -smp kernel. The -BOOT kernel has been removed; the installer uses the standard kernel. As well, the -up kernel has been removed in favour of simply using an SMP-aware kernel.

The installer itself hasn’t changed much other than providing support for the new IDE drivers in the kernel, and setting up the default email address for all security alerts to go to. Other than that, the installer is largely identical to that for 2.0-RELEASE and I don’t anticipate making any changes to it unless bugs are encountered (hence the call for testing). Please report all bugs to bugzilla.

It would be appreciated, due to the changes in IDE controller support, if the install CDs could be tried out on various hardware. Even if you don’t plan to do an install, if you can afford to take a system down for five minutes just to make sure it correctly detects your hard drives and then reboot back to your normal OS, it would be highly appreciated.

For those of you looking at why I use Annvix, let
me elaborate how important EOL and online upgrade for me. And to me,
annvix does the job for me.

Over my 10 years of experiences with the servers, and I am going to talk
about the Linux as OS Three things are probably the worst
nightmare and most important to me as the administrator.

1. EOL of the distribution, which means mandatory upgrade if I want to
keep the software up to date (for security reasons)

2. Ease of the upgrade process.

3. Is online upgrade possible (or must be offline)

Item 2 and 3 are usually go hand to hand though. For first item, EOL of
most of the ‘free’ distributions are about 1 - 1.5 years. Which means,
when you finally get a version working (that’s about 3-6 months after
distribution is released), you only have less than 1 year left. That
means you’ll start preparing a upgrade when the EOL comes if you really
want to keep the security patch up to date and be able to sleep well at
night. This really force me to do upgrade almost every 1 - 1.5 years,
and it really too much work…..
so, since the upgrade is necessary to make sure the system is ‘free’
from hackers, how easy the upgrade process becomes important. For most
of the ‘Bigger’ distributions, due to its ‘HUGE’ and complex nature,
upgrade usually breaks badly and I normally just install a fresh copy of
new version (usually on the new harddisk) and just port the data
manually afterwards. The whole thing usually takes about 1 full day (if
I am lucky), and about a week to make sure everything works.

Finally, since I have several machines co-lo at else where. (Right now,
I live in Taiwan, and couple of my servers are still in the U.S.) To be
able to do remote online upgrade becomes very important. I can afford to
call the ISP to reboot the machine, but there is no way they will be
able to upgrade for me. Thanks to Annvix, which supports online upgrade,
and I have successfully upgrade from version 1.0 -> 1.1 -> 1.2 -> 2.0
and I am looking forward to the new release next year. Yes, we all know
eventually I’ll need to do fresh install just to cleanup everything, but
because of remote online upgrade, it really makes EOL of the server
software to 3-4 years (at least) which really ease my job.

If you run production servers 24/7, you’ll understand how cool this feature is!