After a very long delay I have upgraded this server from Debian Lenny to Squeeze. It has taken about an hour and has gone pretty well, just a few hand edits required. The key services of email and web are still working properly and I've not locked myself out or anything silly yet!
On a server you don't get lots of new toys to play with in the way you do on a desktop system, and it's more important that it works than it's shiny, so the only reason I've done the upgrade now is so that it's before Lenny comes to the end of security upgrades - which is important.
Last week I installed the Linux 3.0.0 kernel image on my Debian Wheezy/Testing system. After a reboot, it started normally and X came up with out a problem. The following day when I booted it started okay but went into a kernel-panic when X started. I rebooted in safe/single user mode and it was okay when I manually started X, but it goes into kernel-panic whenever X starts from boot.
I've tried booting several times and with both the radeon or the fglrx graphics driver and it makes no difference, kernel panic on automatic start of X. The older 2.6.39 kernel is perfectly okay, though the fglrx graphics driver from AMD/ATI makes the PC unusually slow at the moment, so I currently use the open source radeon driver.
I have started the process of upgrading all my boxes from Debian 5 "Lenny" to Debian 6 "Squeeze". I started about a week before the actual release of Squeeze by upgrading VM images first, they were the simplest to upgrade and the easiest to roll-back in the event of a problem. There were zero problems on these simple systems.
Next I upgraded my home server - on which the VMs live. This system has more on it and there were some manual tweaks required because of changes to configuration files and such, but overall it went it without a problem.
Finally I upgraded my partner's desktop system. This was the most complex system to-date, having the most installed on it and it was the oldest system, having started life running Sarge. There were several problem with the upgrade - mostly because of manual changes that have been applied in the past, and even after the upgrade there was still quite a lot of antiquated programs left behind that needed manual removal.
All that is left to upgrade now are the remote systems, such as this system which I'll do shortly. Overall a fairly painful process - many thanks to the Debian team.
This weekend I completed my expansion of the filesystem for work's development and production KVM systems. In the end I did the expansion on the server not my own systems, but I did use the technique I developed used last week on my own server. In the end even though my domestic ADSL connection is faster than works AT&T network, neither are fast enough to move about multi-gigabyte files.
Work now has nice shiny expanded servers ready for work. The next challenge will be to upgrade them to Debian 6.0 from the 5.0.8 that they are currently running. As Debian 6.0 "Squeeze" has only just been released I won't be doing it in a rush. I've got two systems at home, two systems with family, and three systems at work to upgrade before I tackle the hosted systems I look after.
We have a remote server at work that is running virtual machines for various web purposes. Alas when originally created the file system of the virtual machines was smaller than we needed. The physical host system has plenty of space, we just have to grow the virtual file systems.
In principle I could have grown the file systems on the server but that would have loaded the server during the working day when the customers use it, plus our corporate network is too slow to do anything significant over the public Internet.
My original plan was top stop the virtual machines for a few seconds, copy
the virtual file system, restart the virtual machine then transfer the copy
to a machine at work. Once I have it on a fast system with plenty of disk-space
cat some zeros on to the end of the container, boot it
up with a live disk and extend the filesystem over the empty space. I'd reboot
it with it's own Kernel to make sure it's all okay and happy, then copy the
enlarged file back up to the remote server.
I however hit some problems... Though we have a fancy network at work, in practice it's slower than the ADSL network I have at home and not only is it slow but it often hits capacity problems, dropping connections. "Plan B" was to use a test ADSL link to pull the files down, but that still left a slight outage during the working day. Even if I could get the filesystems down to a work machine, our desktop systems all run Windows and have tiny hard drives - which isn't much help. I managed to find an older desktop system and borrow a 1 TB external drive, but in the end I decided it would be easier to do at home on my home systems.
Yesterday I pulled down a development and staging virtual system as Qemu/KVM
qcow2 files. On my home server I converted them to raw image
files and made them larger. Using a Debian GNU/Linux live image I booted
them up, expanded the
ext3 filesystem and shut them down. I
rebooted them with their own KVM Kernel to test that they were okay, then
converted the raw image back into a
qcow2 and at the moment
scping them back to the server.
It's sad that I couldn't really do this at work, but at least I learnt some new stuff and I know my home infrastructure is better than works. I also found out that as expected a 2 GiB file as qcow2 expands to a 4 GiB raw imaged, which I expanded to 20 GiB, compresses back to a 2 GiB qcow2 - very cool!
Very shortly Debian 6.0 will be released, this is good as it's got good stuff in it that will be a nice step up from the current version which is starting to show it's age.
Some new things have arrived such as Google Chromium-Browser and KDE4, and some things have gone such as KDE3 and Splashy. I run testing on my desktop so won't see a radical change when the new version comes out but I'll have to upgrade the various stable systems I run once I'm happy it can all be done without any pain - which is usually the case.
KDE4 is really good now I've got use to it and it's big step up from KDE3 which while good was getting long in the tooth. Most KDE3 software is now available upgraded to KDE4 but there are some notable exceptions, for example Quanta+.
Splashy has been replaced by Plymouth, except that Plymouth doesn't work on my system. Having said that Splashy has been buggy so it's not a major change really.
Today I spent most of the afternoon trying to get Ubuntu to play ball with an Edimax EW-7711In PCI WiFi card. On the Edimax website they allow you to download Ralink RT3070 drivers for the Linux kernel. We downloaded a more recent version of the driver from Ralink, as we had problems with the file from the Edimax web site.
We installed the right bits and kernel-headers, compiled it all, installed it
network-manager ignored it. We tried a few tweaks and still it
was ignored. We then re-seated the card to make sure that wasn't a problem - it
wasn't. However I noticed that the chip on the board was a Ralink RT3060,
which is also what
I then downloaded the RT3062 family driver - RT3060/RT3062/RT3562/RT3592. We
repeated the make dance and it popped up in network-manager the second we
This week I deployed a Debian GNU/Linux system at work, I'll deploy another one shortly. They should be Microsoft Windows XP systems but it's company policy that only approved Windows systems go on the network, and all company Windows systems MUST have a screen saver with password set.
The problem is that these systems are basically running public displays so the screen saver is required to be off. Therefore it's easier to deploy a Linux system which isn't part of the company wide Windows Domain to solve the problem than it is to use a Windows systems...
Ironic isn't it? Personally I'm always happy to replace Windows systems with Linux ones but in this case the decision was forced onto me by the IT department - which is becoming increasingly less Windows centric...
I'm normally quite conservative with computing, it is more important that it works than it's the latest toy. The only exception is my desktop system, which runs Debian "testing", so periodically things break.
The latest 2.6.30 kernel and 173.13.09 nvidia glx drivers are not compatible. I can either run an older kernel with working drivers or a later kernel with the 2D only open source nvidia drivers which are working fine.
One can understand why my family and my servers at home and work all run Debian "stable" (currently 5.0.2). Once it goes in, it keeps working, Debian stable upgrades are perfectly safe.
Some time ago I had a discussion with a colleague about weather Google would release their own OS to complete with Microsoft Windows. I felt and still feel that it's a lot of effort for Google and the pay back isn't worth it.
Evidently Google think that there is some money to be made from their own OS and this week announced that they will be releasing their own Linux distro called "Chrome OS" for ARM and x86 netbooks in 2H 2010.
The media (as usual) failed to realise it's just another Linux distro and like all previous distros it will be based on something existing plus it will have something new to bring to the party. Google are known to be a Debian/Ubuntu fan so it will probably be based on Debian but with a very light-weight Google front end and be designed for a Web 2.0 world.
The good news is that it will probably drag some hardware vendors to the table with hardware specs, as even Google can't tinker with the Linux kernel without sharing their tinkering. As it's being primarily targeted at the ARM processor it will also eliminate the normal Wintel inertia problem that often harms people's migration away from Windows - most netbooks started out on Linux only, but it was easy for Microsoft to push people back to the BSOD that they were use to with little effort.
We live in interesting times...
Last week I've spent a lot of time on the train going to and from SAP's training centre in Feltham near Heathrow. I took my copy of Martin Krafft's "The Debian System" with me to have something to read and to show to two of the other students who turned out to be Linux users at home.
It's more than a year since I last read or looked at the book and it refers to Debian Woody/Sarge when currently Debian is at the Etch/Lenny transition. Even so I still found useful stuff in it - a really great book.
A few weeks ago I set up NFS on my home server using version 4 of the protocol rather than the still more common version 3. It all went rather swimmingly and I've been happy.
One feature that NFSv4 has over NFSv3 is that it includes decent security in the form of Kerberos support. I've never used Kerberos before, mostly getting by with SSH, so this seemed like an opportunity to learn something new.
So far no luck, I've had two goes and even with plenty of help from people on the DA.org site I'm still no closer...
Sometime ago the Debian team applied a patch to OpenSSL, in doing so they introduced a subtle bug that greatly weakens the strength of any key generated by the OpenSSL package, e.g. SSH or TLS/SSL keys.
Debian have corrected their bug but any cryptographic keys generated in the interim need to be replaced as they are unacceptably weak. A new version of OpenSSL is available from Debian and needs to be installed as a matter of urgency on any Debian Etch or later system. Once OpenSSL has been upgraded all keys need to be regenerated.
The details can be found on the Debian Security site DSA-1571-1. Users of any distro based on Debian such as Ubuntu, should also check to see if they are also affected.
Today at work I was given a copy of the Debian GNU/Linux 3.1 Bible. I wouldn't have bought the book myself, the cover art put me off, but as I've been given it I don't have to worry about that. Obviously it's now a bit out of date but if the content is correct it should still be of some interest.
Today Debian GNU/Linux testing, code-named "Etch" has become the new stable release of Debian.
It has taken a tad longer than originally expected but it's done now, and Lenny is the new testing version of Debian. The freeze for Etch took place back in December, with a very aggressive release time table.
While Debian 3.0 (Woody) was around for far too long, Debian 3.1 (Sarge) has been stable for a sensible period of time. I've already upgraded most of my production boxes to Debian 4.0 (Etch), just my home server remains on the old version.