Most of the time I’m not in the same country as the servers I administer. Which means I can’t just drive down and fix something when it goes wrong. It also means that making changes to the network is particularly dangerous. So is updating the kernel, initrd, or GRUB configuration. It is possible to leave a server in a state that requires you to be physically present to fix it. I call this kind of work “flying without a net”. Here are my techniques for safely working without console access.

The most useful tool in my bag is GNU screen. Screen acts as a window/terminal manager inside a terminal. This means you can open one SSH session to a server but start multiple bash logins and multi-task from one terminal window. What’s more, screen is persistent. This means you can disconnect from it and return later, and your programs are still running. Even if your network access is interrupted, anything running in screen will complete rather than terminating when your login session does.

Screen is the safest way, short of console login, to make network changes. Want to run “ifdown eth0 ; ifup eth0“? Try it and you’ll likely find that the first command will interrupt the network and the second command will never run. Your server is now off the network, and you can’t fix it without console access. If you had used screen, you wouldn’t be ringing the on-call staff and suffering a service outage.

For me, the most common way to lose access to a server is to make a mistake while changing the network configuration. This could be the firewall, the IP configuration, tunable kernel networking parameters (sysctl), or something as simple as stopping the OpenSSH server. The first rule is: the server always boots in a known good configuration. Don’t write changes to any startup configuration files until they are tested. When testing, tell the server to restart if the new configuration is bad.

How do you do this? With shutdown -r +5m. This will instruct the server to reboot in 5 minutes. Then, make your changes. If they work, cancel the shutdown with shutdown -c. If they don’t, the server will reboot in 5 minutes on the known, working configuration. Five minutes of down time may be unpleasant, but it is a lot better than sending an engineer.

This means you must test your configuration changes with temporary files. Most commands that use configuration files take an argument to read an alternate file.

cp /etc/network/interfaces /etc/network/interfaces.new
vi /etc/network/interfaces.new
ifdown eth0
ifup -i /etc/network/interfaces.new eth0

Another simple trick is to have a private IP address configured on a virtual interface (eth0:1). Do this for all your servers. If you lose access to one server, you can SSH into another on the same LAN, then SSH into the affected server using the private IP. In rare cases I’ve set a bad route or default gateway, but found I could reach the server from another on the same IP subnet.

Always keep an active SSH session when making changes to the OpenSSH server. Don’t test by logging out of your current shell and then logging in again. Open a new terminal and test in that one. The OpenSSH server only controls new SSH sessions, not existing ones. So you can upgrade or restart the SSH service without losing your open shell.

This applies to firewall changes as well. A typical firewall config accepts all existing, recognised connections before filtering new ones. If you firewall port 22/tcp, you may not be able to open a new session, but your existing ones will probably continue to work.

Install webmin. If you break the OpenSSH server or run afoul of your own firewall, you may be able to login via webmin and fix it. Webmin has native brute-force protection and uses SSL, so you aren’t decreasing your security by installing it. It has saved me more than once.

Be wary of anything that affects the boot process itself. That means GRUB, the kernel, and the initrd image. If you use software RAID on the root partition, make sure that initrd image has all the tools you may need to boot:

apt-get install mdadm evms dmsetup lvm2

In general, it is safe to upgrade or reboot if you use your distribution’s standard software repositories and don’t change the default configurations. If you compile your own kernel or do anything fancy with GRUB, ensure you have console access.

If you have the resources, model changes to a server in a virtual machine first. Today, “resources” only means a mid-range laptop and Virtualbox. Create a virtual network environment that is identical to the real one, using the same IP addresses but only accessible to you. Test your changes, then apply them to the real server only if they work.

These techniques are no substitute for professional server administration. Standard policy at my company is that all servers are installed on network-aware PDUs and connected to IP-capable KVM units. This means I can remotely reboot a server by the power switch, or login as if I were on a local keyboard and monitor. This means I have access to BIOS, bootable network/RAID cards, the GRUB boot menu, a minimal recovery shell (such as when fsck fails), or the regular console. You can’t get any of that with GNU screen or any tool that runs on the server itself.

If you have more than four physical servers, installing a network PDU and KVM will cost less than 15% of the servers themselves and will save you a lot of trouble in on-site support fees and lost time. And they will allow your engineers to do scheduled maintenance at late hours from home.

We use KVM for virtualisation, but I’m not going to discuss the details here. Like any virtualisation solution, KVM starts a virtual machine and attaches its virtual network hardware to a network interface on the host OS. What I want to discuss is how to implement the networking layer.

I previously wrote about creating a network bridge for Virtualbox virtual machines, and we’re going to do something similar here. However, we want to implement VLAN support and native 802.1q VLAN tagging at the same time.

The design:

• The physical server is connected to the Ethernet switch via a 802.1q VLAN tagged trunk port
• The host OS is aware of the trunk port, and implements several virtual network interfaces. Each virtual interface is associated with one VLAN. Any traffic on that virtual interface exits the physical network interface as tagged VLAN packets.
• The host OS provides a network bridge for each VLAN, and adds the virtual VLAN interface to the bridge.
• The guest OSes (virtual machines) are not VLAN-aware. They have a normal ethernet interface which requires no special configuration.
• The virtualisation software (KVM, in this case) attaches the network interface of the guest OS to the VLAN-specific network bridge.

Warning: changing the Ethernet setup to your server can cause you to lose access to it. At all times during this process, ensure you have console access to the server, and network or console access to the switch.

That said, we’ll try to time the network interruption such that we don’t lose access. First, configure your server for VLAN networking. This guide assumes the server runs Ubuntu 8.04 “Hardy Heron”, but the steps are similar for any recent Ubuntu release. I have no idea how Red Hat handles VLANs and bridging, but I invite you to provide the steps in comments.

This guide also assumes the server is connected to a VLAN unaware (access) port, on VLAN 100, with an existing /etc/network/interfaces like so:

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
auto eth0
iface eth0 inet static
	address 192.168.0.2
	netmask 255.255.255.0
	gateway 192.168.0.1

Finally, we assume that virtual machines will be attached to either VLAN 100 (the same as the host OS’s own traffic) or VLAN 200. So we’ll prepare support for both.

Install vlan and bridge support.
apt-get install vlan bridge-utils

Then edit /etc/network/interfaces. Modify the existing network setup to be aware of VLAN 100, and to create a bridge on it.

# The loopback network interface
auto lo
iface lo inet loopback          

# LAN uses VLAN trunking, so set any IP addresses on appropriate bridge
auto eth0
iface eth0 inet manual
	up ifconfig eth0 up

# VLAN 100
auto eth0.100
iface eth0.100 inet manual
	up ifconfig eth0.100 up

# KVM bridge, VLAN 100, via eth0
auto br100
iface br100 inet static
	address 192.168.0.2
	netmask 255.255.255.0
	gateway 192.168.0.1
	bridge_ports eth0.100
	bridge_maxwait 5
	bridge_fd 1
	bridge_stp on

We must bring eth0 up before we can create eth0.100, and we must bring eth0.100 up before we can attach it to the bridge interface. Finally, we must configure the host OS’s IP address on the bridge. If you don’t want to attach virtual machines to VLAN 100, you could configure the IP directly on eth0.100 and leave out the stanza for br100.

Now, apply changes. Because we’re going to move the existing IP from eth0 to br100, the easiest way is to reboot. Alternatively, you may try /etc/init.d/networking restart, but make sure you run this from console so you can fix any problems.

Network interruption begins as soon as you run the above command, or reboot. To restore access to the host OS, we must now configure the Ethernet port on the switch. For Cisco, this is easy. Assuming the server is connected to gigabit Ethernet port 1, run:

configure terminal
interface GigabitEthernet0/1
 switchport mode trunk

You should now be able to ping your server. Once you verify that works, add the configuration for VLAN 200 to /etc/network/interfaces.

# VLAN 200
auto eth0.200
iface eth0.200 inet manual
	up ifconfig eth0.200 up

# KVM bridge, VLAN 200, via eth0
auto br200
iface br200 inet manual
	bridge_ports eth0.200
	bridge_maxwait 5
	bridge_fd 1
	bridge_stp on

VLAN 200 doesn’t need an IP on the host OS, so it lacks the static IP configuration. Configure any additional VLANs the same way.

Now we are ready to attach virtual machines to the new bridges. For KVM, use virt-install to create a machine with 20 GB hard disk, 1 GB of RAM, booting the hardy iso, and attached to VLAN 100.

virt-install --connect qemu:///system -n guestname -r 1024 -f /path/to/virtual/disks/guestname.qcow2 -s 20 -c /path/to/isos/ubuntu-8.04.3-server-i386.iso --vnc --os-type linux --os-variant ubuntuHardy --accelerate --network=bridge:br100

Now use virt-manager to connect to the guest and configure it.

The last step can be replaced with any other virtualisation solution. For instance, with Virtualbox, you can create a VM and then attach it to the bridged interface br100.

Unlike the Virtualbox NAT/routing setup, we don’t need to enable IP forwarding (sysctl -w net.ipv4.ip_forward=1). This method uses layer 2 switching only. However, if you use an iptables firewall, make sure the FORWARD chain of the filter table defaults to “ACCEPT”, or use an equivalent rule matching traffic to/from the virtual bridges.

http://www.tolaris.com/xmas

(In case you miss it the first time, try reloading or clicking the button.)

Read on if you’d like to know more about how our awesome card works.

We started the Christmas card in 2005, as a simple way to do a card online. My wife Jamie and I had several reasons for doing our card this way.

1. We didn’t want to waste paper or fuel to deliver physical objects half-way around the world.
2. We didn’t want to use an online card service, which offer all kind of funny/animated/religious/specialised cards but exist solely to get you to give up personal information about your friends. The fastest way to lose me as a friend is to sell me out to spammers and marketing droids.
3. We wanted to create something, both for our own pleasure and as a way to give back to our friends.

So I wrote the first card in plain HTML, and made customised messages for certain people using differently-named files, and hand-sent all the emails that year.

This was a quick hack but it worked well. The next year we upgraded to PHP. Then each successive year we added more features, improved the code base, and found various ways to foil our hacker friends (who wasted no time testing the security of the card – guessing URLs, testing PHP arguments, and so on). The full details are now in the changelog, which is new this year.

The big hit was in 2008, when we created the “madlib” greeting. The madlib card uses PHP to generate a random greeting from a template and a series of variables. Judging from server logs this was tremendously popular with my friends, who clicked the reload button many times until they’d exhausted enough combinations to be satisfied. Others didn’t immediately realise what was happening, and probably just assumed Tyler wrote a really weird card and closed the browser. I figure I was accurately represented either way.

The PHP code is simple. Here is the basic idea:

<?
$happy_list = array("merry", "happy", "wonderful", "drunken", "special");
$holiday_list = array("Christmas", "Hannukah", "Kwanza", "Festivus");
$happy = "$happy_list[array_rand($happy_list)];
$holiday = "$holiday_list[array_rand($holiday_list)];
echo "<p>$happy $holiday, everyone!</p>";
?>


$happy $holiday, everyone!

The bug appears as:

1. Start virt-manager.
2. Connect to a KVM host server using connection “Remote tunnel over SSH” with hypervisor “QEMU/KVM”.
3. Double-click on a VM to open a VNC connection to console.
4. The error message “Error bringing up domain details: invalid argument in virDomainGetXMLDesc” appears, and no VNC session opens.

The problem is with the latest version of virt-manager, 0.7.0. To work around it I’ve repackaged virt-manager 0.6.1 from jaunty with the fake version “0.7.1~really0.6.1-1ubuntu4″. Packages for i386 and amd64 are now in my APT repository.

Also, KPackageKit ignores my “dpkg --set-selections“, forcing me to do this. Thanks, KPackageKit, for ignoring the standard! Otherwise I could install the jaunty package and mark it on hold.

The hardy version of kregexpeditor still works on karmic, and I’ve used pbuilder to port the jaunty package of grip to karmic. Both are now in the repo.

Nothing in this process is specific to KDE, so Ubuntu or Xubuntu users can use this as well. Steps:

1. Choose a strong password
2. Create an encrypted ~/Private directory
3. Copy home directory files into ~/Private
4. Move ~/Private to $HOME
5. Encrypt swap
6. Make /tmp a tmpfs

Caveat emptor: If you encrypt your home directory, then later forget your password and fail to write down the mount passphrase, you are screwed. There is no practical chance that you will recover your files. As always, make a backup.

Step 1: Choose a strong password

If you aren’t already doing this, you’re not likely to use this guide. Security is a mindset, not a tool. Get used to keeping strong passwords in your head. Ubuntu makes using encryption really easy, but it is only as effective as the strength of the password you choose.

My recommendation is to use pwgen with -B or even -By:

pwgen -By

Ohz:ah7s aiT7gex% AhNae)Z3 Ohph*i9e va9eZuo[ Mei7ieZ~ Ohb7Za]o Piek+ai3
fa!m3Sho ua~ch7Wa tom?oh9U do{i4Aep tuF4oof} Na#a4eiH epe\G3oh aR3ahp^i
...
Aip$aim9 Eph%a3pu gae7aY`a Ie^cah4t sha+uY3v ove3aeZ= Wie4yei| Oc\aeb9e

The -B option tends to generate passwords that are balanced between hands and at least partly pronouncible, so this isn’t as hard as you think. If you do use -y (special characters like +), consider the keyboards you might have to use. If you use both British and American keyboards, don’t use £, @, “, `, #, ~, \, or |, as all of these are in different locations.

Pick one and and make a mnemonic to help you remember it. Write it on a piece of paper, put it in your wallet, and burn it once you memorise it. Write it on your belly with a sharpie; whatever it takes. Change your password now:

passwd

Your password will later become the passphrase that protects the encryption keys to your home directory. ecryptfs includes excellent PAM support, so if you change your password later it will update the key too.

Step 2: Create an encrypted ~/Private directory

Since I upgraded from an earlier install without an encrypted home or ~/Private directory, I had to create one. If you are about to install 9.10 from a CD, the installer has an option to encrypt your home directory. Just use that. Or create a new user:

adduser --encrypt-home username

If you’ve already got an encrypted home, congratulations! The hardest part is done. Skip to step 5.

If not, let’s get started. Linux Mag’s Dustin Kirkland has written an excellent guide to this process. Much of my process is based on his, but I include a few corrections. For most of this you can remain logged in to your Desktop, but the process is simpler from the Linux console. The initial copy process will make you want to get up and do something else while it finishes anyway.

Logout from the Desktop, which should return you to the login screen. If your login screen is configured to log you in automatically, cancel it. Then press Ctrl+Alt+F1 to go to the first Linux virtual console.

Login at the prompt, and create an encrypted $HOME/Private directory:

ecryptfs-setup-private

Enter your login passphrase:
Enter your mount passphrase [leave blank to generate one]:

At the first prompt enter your user password. At the second, press Enter. Now record the mount passphrase which was just generated:

ecryptfs-unwrap-passphrase $HOME/.ecryptfs/wrapped-passphrase

Print it out and put it with your birth certificate in your fire-proof document safe. You do have one, right? If something goes wrong you will need this later.

Log out, and log in again.

Step 3: Copy home directory files into ~/Private

Make sure you have at least 50% free on /home, or this may fail.

rsync -aP --exclude=.Private --exclude=Private --exclude=.ecryptfs $HOME/ $HOME/Private/

If you don’t have 50% free, first move some files from $HOME to $HOME/Private, and rsync the rest.

cd
mv -v Videos Music Pictures DirectoryOfBigFiles $HOME/Private/
rsync -aP --exclude=.Private --exclude=Private --exclude=.ecryptfs $HOME/ $HOME/Private/

This will take a long time to complete. Every file is being encrypted as it is copied or moved. If you have a lot of files and an under-powered CPU (such as on a netbook), it will take even longer. I moved 178 GB of data on my Dell Vostro 1500 (Intel Core2 Duo 2 GHz, 4GB RAM) in about 5 hours. Get a coffee, walk the plants, shave the cat, come back later.

When done, logout to sync any remaining changes to disk.

Step 4: Move ~/Private to $HOME

Now we need to do some things with sudo. Still on console, login again. Unmount $HOME/Private:

ecryptfs-umount-private
cd /
sudo mkdir -p /home/.ecryptfs/$USER
sudo mv $HOME/.ecryptfs /home/.ecryptfs/$USER/

Create a new home and populate it with the ecryptfs files:

sudo mkdir -p -m 700 /home/$USER.new
sudo chown $USER:$USER /home/$USER.new
sudo mv $HOME/.Private /home/.ecryptfs/$USER/
sudo ln -s /home/.ecryptfs/$USER/.ecryptfs /home/$USER.new/.ecryptfs
sudo ln -s /home/.ecryptfs/$USER/.Private /home/$USER.new/.Private
sudo ln -s /usr/share/ecryptfs-utils/ecryptfs-mount-private.txt /home/$USER.new/README.txt


Switch to the new home, tell ecryptfs that we’ll mount it at login, and make it read-only (until it is mounted):

sudo mv $HOME $HOME.old
sudo mv $HOME.new $HOME
echo $HOME > $HOME/.ecryptfs/Private.mnt
sudo chmod 500 $HOME

Now for the moment of truth. Still on console, logout, and login again. Your home directory should mount:

mount | grep ecryptfs

/home/username/.Private on /home/username type ecryptfs (ecryptfs_sig=9cec4d81c9bcb6e0,ecryptfs_fnek_sig=c735e6facb299611,ecryptfs_cipher=aes,ecryptfs_key_bytes=16)

Create some convenient links:

ln -s /home/.ecryptfs/$USER/.ecryptfs $HOME/.ecryptfs
ln -s /home/.ecryptfs/$USER/.Private $HOME/.Private

Once you verify that all your user data is there, securely wipe any files that have important data, and then remove the old home.

cd $HOME.old
find .kde .gnupg .ssh PathsToDirectoriesOfImportantFiles -print -exec shred -u {} \;
rm -rf $HOME.old

Step 5: Encrypt swap

Your home directory isn’t the only place your private data may be written to disk. When your computer doesn’t have enough RAM for everything it wants to have open, it swaps. This means some RAM is written to disk to be read back later. Thus, swap can contain anything you have ever have open. Swap does not need normally to survive reboots *, so we’ll encrypt this with a random key every time we boot up.

* The one exception to this is hibernate mode (suspend to disk). If you want to use hibernate, don’t encrypt swap, or use a (less secure) static key. Encrypting swap has no impact on sleep mode (suspend to RAM). I never use hibernate.

Thankfully, this is a very easy process with Ubuntu. Despite the misleading name, this uses cryptsetup, not ecryptfs:

sudo apt-get install cryptsetup
sudo ecryptfs-setup-swap

Step 6: Make /tmp a tmpfs

The last place your private data is commonly written is the temp directory, /tmp. The contents of this directory don’t need to survive reboot either, and are commonly cleared at bootup. It is possible to encrypt it using cryptsetup just as with swap, but we don’t need to. Instead we’ll make this a tmpfs. This means /tmp will be an auto-resizing virtual RAM disk. By default it is allowed to grow to up to 50% of RAM.

Don’t worry about this consuming your RAM. If the contents of RAM is swapped to disk, static content like /tmp will be the first to go. And it isn’t much data anyway; my /tmp rarely grows beyond 200 MB. Plus, using a tmpfs will save power when in battery mode.

Add one line to your /etc/fstab:

echo "tmpfs /tmp tmpfs defaults,noatime,mode=1777 0 0" >> /etc/fstab

If you are logged in to the desktop, log out completely. Then login on console one last time, and run:

sudo rm -rf /tmp/*
reboot

That’s it! You are now running a cryptographically secure laptop, protected against all but the rubber-hose attack.

The article was about configuring ACPI hotkeys to support your specific laptop. IE, the buttons for “sleep”, “brightness up”, etc. For most laptops this already works on Ubuntu. On my Dell Vostro 1500, every button except for “sleep” worked right after install. This is Linux, so there is always some way to fix that.

Unfortunately, ACPI cannot even detect my keypress. The instructions in the article suggest starting acpid with -d for debug mode, which will print any keypresses that reach it. Pressing Fn+F1, the sleep button, prints nothing. So we’re going to use KDE’s hotkey support instead. Gnome users can use a similar method; only the menu instructions differ.

First, create a script somewhere your user can run. I have $HOME/bin in my $PATH, so I created a file there:

touch ~/bin/sleep-kde-screen
chmod 755 ~/bin/sleep-kde-screen

Then I edited it to contain the following:

#!/bin/sh
qdbus org.freedesktop.ScreenSaver /ScreenSaver Lock
sudo /usr/sbin/pm-suspend

This calls DBUS to lock the screensaver, then asks power-manager to suspend. This way you will be prompted for your password when you resume from suspend. If you prefer to hibernate, change “pm-suspend” to “pm-hibernate”.

Second, you need to tell sudo to allow your user to run this /usr/bin/pm-suspend without prompting for a password. Run sudo visudo to edit /etc/sudoers, and add this line at the bottom:

%admin ALL=NOPASSWD: /usr/sbin/pm-suspend

Finally, add this script to your K menu with a hotkey. Right-click on the K menu and select “Menu Editor”. Add a new item to the “System” menu, give it a name (I like “Sleep!” *), and tell it to call sleep-kde-screen (wherever you’ve put it). On the Advanced tab, select “Current shortcut key” and press the sleep button. Now save and close the menu editor.

* I imagine saying “Sleeeeeep!” like a hypnotist bad guy from an old movie on MST3K.

Press the sleep button, and you’ll suspend!

At the time of this writing, my host OS is Ubuntu 9.10 Karmic 64-bit (actually an Intel Core 2 Duo 2.0 MHZ), with VirtualBox 3.0.10 PUEL edition. I run several 32-bit clients: Ubuntu 6.06 LTS (just in case, we still encounter them at some customer sites), Ubuntu 8.04 LTS, Xubuntu 9.10, and Windows XP SP3 (my actual legal copy that came with the laptop).

I left the Windows XP VM running but idle, and noticed that my keyboard and mouse occasionally skipped, and my CPU worked harder than expected. So I ran a few tests with top in batch mode:

top -b -d 10 -n 10

I then redirected that to a file, waited the 10*10 seconds to finish, and grepped the results. This is with VT-x enabled, and shows only the relevant VM (not the GUI or other VMs):

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
30763 tyler     20   0 1020m 609m  73m S   10 15.4   0:28.05 VirtualBox
30763 tyler     20   0 1020m 609m  73m S    9 15.4   0:28.98 VirtualBox
30763 tyler     20   0 1020m 609m  73m S    5 15.4   0:29.52 VirtualBox
30763 tyler     20   0 1020m 609m  73m S    6 15.4   0:30.10 VirtualBox
30763 tyler     20   0 1020m 609m  73m S   20 15.4   0:32.06 VirtualBox
30763 tyler     20   0 1020m 609m  73m S    6 15.4   0:32.63 VirtualBox
30763 tyler     20   0 1020m 609m  73m S   10 15.4   0:33.60 VirtualBox
30763 tyler     20   0 1020m 609m  73m S   16 15.4   0:35.18 VirtualBox
30763 tyler     20   0 1020m 609m  73m S    6 15.4   0:35.78 VirtualBox
30763 tyler     20   0 1020m 609m  73m S    4 15.4   0:36.20 VirtualBox

Here is the same data, after rebooting the guest and disabling VT-x:

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
30217 tyler     20   0 1027m 625m  73m S    4 15.8   2:21.32 VirtualBox
30217 tyler     20   0 1027m 625m  73m R    5 15.8   2:21.79 VirtualBox
30217 tyler     20   0 1027m 625m  73m S    1 15.8   2:21.89 VirtualBox
30217 tyler     20   0 1027m 625m  73m S   11 15.8   2:23.04 VirtualBox
30217 tyler     20   0 1027m 625m  73m S   11 15.8   2:24.17 VirtualBox
30217 tyler     20   0 1027m 625m  73m S    5 15.8   2:24.69 VirtualBox
30217 tyler     20   0 1027m 625m  73m S    2 15.8   2:24.94 VirtualBox
30217 tyler     20   0 1027m 625m  73m S   10 15.8   2:25.94 VirtualBox
30217 tyler     20   0 1027m 625m  73m S    5 15.8   2:26.44 VirtualBox
30217 tyler     20   0 1027m 625m  73m S   13 15.8   2:27.72 VirtualBox

Two conclusions:

1. Software virtualisation uses more RAM. The guest is configured with 1 GB of RAM. With VT-x, this uses 1020 M. Without, it uses 1027 M. Whether that represents a memory overhead of 7M per VM or 0.7% of total RAM per VM, I don’t care. It’s small enough.
2. Software virtualisation, under these conditions, is more efficient than using VT-x. The average CPU usage with VT-x was 9.2%. Without, it was 6.7%.

Engineering and science students will recall that all experimenters must note potential flaws and sources of error.

1. This tests only a guest which is completely idle. However, my general impression when doing actual work in the guest VM supports the idle observation.
2. top isn’t the best measure of performance, but it is indicative.
3. I only tested a 64-bit Intel host with a 32-bit Windows guest. As always, more data is better.

I also note that my keyboard and mouse no longer skip when the guest OS is busy. Clearly something is up with VT-x and Ubuntu 9.10 hosts. The right thing to do is to perform more tests confirm the initial observations, but I’m not going to spend any more time on this. Software virtualisation, so far, has been plenty fast for me. I’ll just disable VT-x on all guests, and test again after the next upgrade for VirtualBox or the host kernel.

Unlike the now deprecated gtk-qt widget style, qtcurve doesn’t let you configure anything. It directly reads your preferences from KDE and uses those. In particular, it uses your “General” font setting from KDE Control Centre -> Appearance -> Fonts.

There is a bug with qtcurve which causes it to have big fonts by default. A fix can be found in my last post.

If you use qtcurve, the GUI style won’t apply to your applications running as root. This is because qtcurve doesn’t respect the contents of ~/.gtkrc-2.0 (normally where GTK engines look for customisations). It instead reads your ~/.kde/share/config/kdeglobals file.

So if you want your root applications to look like your normal applications, first fix qtcurve as above. Then copy your kdeglobals to root:

sudo cp ~/.kde/share/config/kdeglobals /root/.kde/share/config/kdeglobals

You’ll have to repeat this if you change your “General” font setting. Don’t symlink to your file, as this may cause it to be owned by root next time you run an application as root.

Jaunty has been my Windows Vista. I wish I had never upgraded, and waited instead for Karmic. For anyone using Intel video (I use a Dell Vostro 1500 with an onboard Intel GM965/GL960), Jaunty and KDE4 was a terrible experience. Compared to Hardy and KDE3, video performance was dramatically worse. When playing videos frames would drop, 3D acceleration was slower, everything showed more tearing effects, and most KDE4 apps showed graphics corruption in various rarely-updated areas such as the icon toolbar in Kontact.

I had already discovered the video issues when I wrote my last upgrade post, but hadn’t yet realised the extend of the wireless issues. I have two cards in my laptop:

tyler@baal:~$ lspci | grep -i network
0c:00.0 Network controller: Intel Corporation PRO/Wireless 3945ABG [Golan] Network Connection (rev 02)
0d:00.0 Ethernet controller: Atheros Communications Inc. AR5001 Wireless Network Adapter (rev 01)

Under Jaunty, the Intel card caused kernel panics on shutdown. So I blacklisted the driver and used the Atheros card, only to discover problems with both the ath_pci and ath5k drivers. The former doesn’t work with network manager, and with the latter the card would sometimes fail in a state requiring full hardware reset, meaning powering the laptop off and on again. This would happen on bootup too, causing me to sometimes reboot several times to make wireless work. It is not good to begin the workday filled with frustration and rage.

I did my best to mitigate the issues under Jaunty, including using the latest KDE backports from the Kubuntu PPA. But the only real solution to my video problems was to upgrade to the latest kernel, X, and intel video drivers. I use Ubuntu because I want reasonably recent packages but without the headache of running true alpha / bleeding-edge releases. Replacing all the critical parts of the distro seemed like the wrong way to go. So I suffered and waited for the day Karmic came out.

The 9.10 release notes cover a number of known issues. What strikes me about the known issues is how few of them affect me. Many are related to the netbook remix, or specific to recent netbooks with proprietary hardware. Support for the general case of mostly Intel hardware released 1-2 years ago is all there.

Upgrading from Jaunty to Karmic was just a matter of doing what the GUI prompted me to do. This wasn’t like jumping from KDE 3 to 4, so I didn’t remove any dotfiles or reformat. I just made my usual backup and then did the upgrade. I had a problem and had to stop the upgrade during the post-download, configuration part, so I ran dpkg --configure -a in a terminal and everything finished just fine.

What went wrong:

Synaptics touchpad tap suppression (syndaemon) stopped working. This is an artifact of upgrading from Jaunty, where to use syndaemon you have to enable SHMConfig in xorg.conf and then run syndaemon as syndaemon -S -d -t -i 1. On upgrading to karmic, set SHMConfig to false, restart X, and call syndaemon without -S (the switch doesn’t exist anymore anyway). I just removed my xorg.conf altogether, since X doesn’t seem to need it.

ath_pci, the madwifi Atheros wireless driver, is gone. I use this for aircrack and kismet. It is likely that I can either compile it or use the ath or ath5k drivers for the same thing, but I haven’t had time to test this.

openvpn with knetworkmanager still doesn’t work, at least with certificates that don’t have a passphrase. So far, openvpn doesn’t even start. From syslog:

Nov  1 13:51:32 baal NetworkManager:   nm_vpn_connection_connect_cb(): VPN connection 'company vpn' failed to connect: 'No VPN secrets!'.

Even if it did work, the dialog doesn’t even have a tab for manually setting up routes. Since when is the equivalent Gnome app more configurable than its KDE counterpart?

Ozone, the default KDE window theme, doesn’t use colour to denote the active window. Instead it uses stripes to the right of the text in the title bar. Some people say that compositing window managers and transparency are supposed to make this a non-issue, but they are wrong. I expect my active window to have a blue window border, and the others to be grey. To fix this, open the Control Centre. Go to “Appearance”, then the “Windows” side bar. Under the “Window Decoration” tab, choose “Ozone”. Under the “Decoration Options” area, uncheck “Blend title bar colours with window contents”.

What went right:

kernel mode setting is awesome! This currently works only for those of us that use Intel video, which is perhaps a small reward for suffering through Jaunty. Switching between X and virtual terminals is fast and seamless. The console has a gorgeous high-res mode at boot-time. I haven’t seen the screen flicker once since GRUB booted the kernel, from X startup to the KDM greeter to Plasma startup.

Booting is very fast. On my laptop I see KDM within 15 seconds of the kernel loading. I have a usable desktop 15 seconds after that. I’m sure more things are starting in the background, but they don’t seem to slow down my login process.

Xorg just figures everything out. I no longer have an xorg.conf and all my hardware works. Plus xrandr now has a large virtual area by default:

tyler@baal:~$ xrandr
Screen 0: minimum 320 x 200, current 1680 x 1050, maximum 8192 x 8192

This should work just fine with multi-monitor setups.

Google Earth and Kwin with compositing work at the same time. So far I’ve had no issue with any 3D apps running together, and they are all about 3 times as fast as they were under Jaunty.

qtcurve, the new KDE/GTK appearance integration engine. This replaced the deprecated gtk-qt engine which had all kinds of drawing errors especially with firefox. Qtcurve uses your “general” font setting from KDE in GTK apps, and generally makes GTK apps look like KDE ones. Unfortunately it is broken out of the box. The solution is to install the “kcm-gtk” package, and then use Control Centre to edit your “general” font setting. Set it to something else and then back again, or put this in ~/.kde/share/config/kdeglobals:

[General]
XftHintStyle=hintmedium
font=DejaVu Sans,8,-1,5,50,0,0,0,0,0

Wireshark never looked so pretty.

Firefox 3.5, which really is as fast as you’ve heard. KDE users, give up and use the default theme. All the “hack it to look like KDE” themes just don’t work as well as the one the developers themselves test against.

Plasma is stable. This isn’t a surprise as I’ve been running 4.3.2 from the PPA under Jaunty. Since Karmic is stable I’m not going to use the PPA for bleeding edge KDE releases anymore (until another juicy feature gets released, no doubt).

fish, the Kioslave for file transfer over SSH, is fast once again. It no longer generates notifications for normal browsing activity, either, which was extremely irritating under Jaunty.

knetworkmanager works once again. It was more than a little annoying to use Gnome’s network manager.

They finally got it right with Amarok 2.2. iPod support seems complete, the GUI is configurable (why does the playlist default to the right pane?), the collection scanner is much faster than Amarok 1.4, and it hasn’t crashed yet.

Karmic has been added to the repository.