1. save passwords
2. manage connections via the GUI
3. support VNC and RDP
4. work with our IP KVM

This last requirement is the kicker. When I change hosts on our Adderview IP KVM, it draws one frame at 0×0 resolution, and then changes to the resolution of the new host. This has crashed every VNC client I’ve tried except xvnc4viewer. Which of course, doesn’t save passwords or have a GUI (the raw X menu when you press F8 does not count).

I have tried KRDC, Vinagre, xtightvncviewer, and a number of simpler command-line VNC clients. They all seem to be designed to support the “my Mom needs tech support” problem, not the “I manage remote servers” problem. KRDC won’t even login to my KVM; it just hangs after authentication. I suppose that’s better than crashing, but it is still a show stopping bug for me.

Over a year ago, I hacked up a scripted solution involving zenity GTK dialogs, saved password files, and xvnc4viewer, but I’m not going to release that. Instead, meet the last remote desktop client you’ll ever need: Remmina.

Remmina meets all of my requirements, has tons of useful features, and works flawlessly. Not only that, it is extremely responsive. Key presses are limited only by the round-trip time, with no added delay from VNC itself. There are no redrawing or tearing problems. It supports full-screen mode and scrolling inside a view port. It can forward over SSH and will use SSH keys files or your SSH key agent. It can synchronise the clipboard between host and remote server; this is the first time I’ve actually seen that feature work reliably. It can even open a standard SSH or SFTP session, or host a VNC server.

Installation is easy. An older release is available in the Ubuntu Lucid Universe repository, or get the latest version from their PPA.

My opinion is that Lucid improves on Karmic in almost every way. That’s not saying much, since the KDE 4 upgrade has been so painful. We’re finally back to KDE 3.5 functionality, and speed is improving with each release. On the other hand, there are a lot of new features in the OS since Hardy – grub2, ext4, ecryptfs, upstart, kernel mode setting, compositing window management, Strigi indexing and Nepomuk semantic desktop. Some of these have dramatically improved performance, while others have increased system requirements just to add eye candy. It’s hard to evaluate KDE on its own, so I’m not going to focus on that.

I backed up my entire drive to an external USB drive formatted for ext3 using rsync. I then booted from the Kubuntu 10.04 AMD64 Desktop CD, and followed the default install options until the disk partitioning step. I always install with separate /, /home, and swap partitions (this normally makes upgrades easier, unless you are reformatting as I did here). I used ext4 for / and /home, and chose to encrypt my home directory. I then followed the rest of the steps and rebooted at the end.

Following the reboot, I used rsync to restore my lost files and most of my dotfiles – .mozilla, .gnome, .gconf, .Virtualbox, and the like. However, I did not restore .kde. Instead I manually copied only some configs, for KGPG, Akregator, and Kopete. The rest of my KDE apps I reconfigured from scratch. I did this because we use Kolab at work, which integrates with Kontact but can be fussy with local contacts files. As of Lucid, Kontact uses Akonadi to manage contacts. I expected trouble, and found it. More on that later.

Finally, since I have an encrypted home directory, I also encrypted swap and created a tmpfs on /tmp. I followed the steps in my guide, and rebooted with no problems.

What’s better:

The ext4 filesystem is noticeably faster. This is the reason I reformatted instead of upgrading. I used ext3 under Karmic, and really wanted to see if what I’d been hearing about the speedy new filesystem is true. It is. It’s faster for booting and it’s faster for reading large data. My Virtualbox virtual machines load in almost half the time, even compared to the same Virtualbox 3.2.6 release on Karmic. I suppose there could be other differences contributing to this but it really stands out. I haven’t run an fsck yet but others report that it is much faster as well.

ext4 has definitely improved performance of copying data inside my encrypted home directory. I barely notice the performance hit from using ecryptfs now. The only time I do is when using rsync to compare large directories (like when my backup process examines my mail archive).

There is a new touchpad control in KDE Control Center. This enables gestures, including two-finger scrolling (but not pinch-to-zoom, which I hope is forthcoming), and different actions for tapping in corners, multi-finger tapping, and so on. Still missing is tap suppression (accidentally tapping while typing), so I still use syndaemon. Create ~/.kde/Autostart/syndaemon.sh, make it executable, and insert:

#!/bin/sh
# Disable touchpad while typing to prevent accidental tapping.
/usr/bin/syndaemon -d -t -i 1

The device notifier plasmoid now has multiple actions when opening attached storage devices, and can be configured to automatically mount drives. This is a vast improvement.

The system tray plasmoid now obeys my auto-hide preferences. Under Jaunty and Karmic, some applications had overriding preferences that caused them to always be hidden or visible. For instance, it was impossible to make KGPG always visible. I frequently use KGPG, so this caused me to almost always have the system tray expanded to show all applications.

Firefox/KDE integration works very well. Open/save file dialogs use KDE, and menus and icons use KDE defaults. The printer dialog is still the native Firefox one.

virt-manager is vastly improved. The GUI is more responsive when connecting, is prettier, and has graphs for CPU, disk, and network I/O.

ClusterSSH works with KWin again. Since 8.10, ClustterSSH has been nearly broken in KDE. First, simply starting it caused copy (to clipboard or selection) to stop working in most QT/KDE apps. Second, the ClusterSSH master window would grab focus and prevent you from giving focus to any of its children xterms. This made it very hard to run commands on just one host without running it on all. I gave up and used various other techniques for managing my servers. But nothing beats ClusterSSH for managing 2-20 servers at once, and I’ve sorely missed it. Welcome back, old friend!

What needed tweaking:

The Oxygen window decoration theme still doesn’t colourise the active window. Open System Settings, go to “Appearance”, then the “Windows” side bar. Under the “Window Decoration” tab, choose “Oxygen”. Under the “Decoration Options” area, choose the “Fine Tuning” sub-tab. Check “Outline active window title”.

Hotkeys in Kmenu are ignored. I use a few quick-launch shortcuts, such as “Win+T” to start a terminal. You can set these when editing the K menu, but they are ignored by default. Open System Settings, select “Input Actions”, and then check “KMenuEdit”.

VirtualBox and virt-manager don’t play well together. I don’t use Xen or KVM on my desktop, but I do manage several KVM-based virtual machine servers. Thanks to the new “install recommends” preference in the package manager, simply installing virt-manager also installs libvirt-bin. This loads the kvm-intel or kvm-amd modules on boot, which then prevents VirtualBox from starting virtual machines, with the error “VirtualBox can’t operate in VMX root mode. Please disable the KVM kernel extension, recompile your kernel and reboot (VERR_VMX_IN_VMX_ROOT_MODE).”

I suppose this is really a problem with the “install recommends” behaviour. I’ve complained about that elsewhere, but I always repeat a good gripe when the opportunity presents.

The solution is to edit /etc/default/libvirt-bin and disable libvirtd:

start_libvirtd="no"

And for good measure, blacklist the modules. Create /etc/modprobe.d/local.conf and insert:

blacklist kvm-intel
blacklist kvm-amd

What still needs work:

Akonadi doesn’t start before Kontact tries to access it. This solution (autostarting “akonadictl start” at login) worked for me, although I (painfully) developed it independently. If only I had used Google.

openvpn with knetworkmanager still doesn’t work. I still prefer Gnome’s network manager applet, which works just fine with Kubuntu. Kill knetworkmanager, and start nm-applet. Next time you login, KDE will tell you that another network manager is running, and ask you if you still want to use Knetworkmanager. Say no. Also, OpenVPN support is more reliable under Lucid. Using Gnome network manager with Kubuntu Karmic, the OpenVPN service would periodically fail to start. Editing VPN preferences and then hitting OK sometimes resolved it, but at other times it was an annoying and random dance to make it work. This seems to be resolved under Lucid.

OpenOffice/KDE integration is improved since Karmic, but still has drawing bugs. In particular, the zoom slider in the lower right often disappears. It’s still there, and clicking in the area makes it reappear and zooms. I prefer the “100% / 75% / …” pull-down of the stock OpenOffice theme, however. This is a vast improvement over the Karmic integration, where simply dragging a spreadsheet tab in Calc crashed OpenOffice, but I’d like to see more development here.

Otherwise, my comments regarding Karmic still hold. Google Earth and Kwin play nicely, qtcurve (KDE/GTK integration) is awesome and no longer has the font bug, and Plasma and Kwin are faster and more stable. Lucid is no great leap forward and Kubuntu is still not an innovator among KDE distributions like Ubuntu is to Gnome. But it is an incremental improvement worth using if you prefer KDE.

I have had a Lucid repository since upgrading my media PC and servers. It now includes dfreer’s znes32 for AMD64 (still working on Lucid) and kregexpeditor (you can have it when you pry it from my cold, dead hands).

1. Add the Canonical partner repository.
   sudo add-apt-repository "deb http://archive.canonical.com/ lucid partner"
2. Install Sun Java JRE.
   sudo apt-get update
sudo apt-get install sun-java6-jre sun-java6-fonts sun-java6-plugin
3. Update system defaults to prefer Sun Java over OpenJDK.
   sudo update-alternatives --set java /usr/lib/jvm/java-6-sun/jre/bin/java
sudo update-alternatives --set javaws /usr/lib/jvm/java-6-sun/jre/bin/javaws
sudo update-alternatives --set mozilla-javaplugin.so /usr/lib/jvm/java-6-sun/jre/lib/*/libnpjp2.so
4. If that fails, manually choose them from a list. Always choose the option containing “java-6-sun”.
   sudo update-alternatives --config java
sudo update-alternatives --config javaws
sudo update-alternatives --config mozilla-javaplugin.so
5. Restart Firefox.

Oh, happy coffee-cup-clock progress bar, how I missed you!

I fixed it by downgrading Pulseaudio to the karmic version. Here is how.

First, add the karmic repositories to your sources list. Create a file, /etc/apt/sources.list.d/ubuntu-karmic.list, containing:

deb http://archive.ubuntu.com/ubuntu/ karmic main restricted universe multiverse
deb http://archive.ubuntu.com/ubuntu/ karmic-updates main restricted universe multiverse
deb http://archive.ubuntu.com/ubuntu/ karmic-backports main restricted universe multiverse
deb http://archive.ubuntu.com/ubuntu/ karmic-security main restricted universe multiverse

Now downgrade pulseaudio to the specific version in karmic:

sudo apt-get update
sudo apt-get install pulseaudio=1:0.9.19-0ubuntu4.1 libpulse0=1:0.9.19-0ubuntu4.1 pulseaudio-module-x11=1:0.9.19-0ubuntu4.1 pulseaudio-esound-compat=1:0.9.19-0ubuntu4.1 pulseaudio-module-bluetooth=1:0.9.19-0ubuntu4.1 pulseaudio-module-gconf=1:0.9.19-0ubuntu4.1 libpulse-mainloop-glib0=1:0.9.19-0ubuntu4.1 libpulse-browse0=1:0.9.19-0ubuntu4.1 pulseaudio-utils=1:0.9.19-0ubuntu4.1

You may remove ubuntu-karmic.list after this, or disable it by renaming it to something not ending in “.list”.

Finally, tell dpkg not to upgrade again:

sudo dpkg --set-selections

Paste the following, followed by “Enter” and “Control-D”:

libpulse-browse0 hold
libpulse-mainloop-glib0 hold
libpulse0 hold
pulseaudio hold
pulseaudio-esound-compat hold
pulseaudio-module-bluetooth hold
pulseaudio-module-gconf hold
pulseaudio-module-udev hold
pulseaudio-module-x11 hold
pulseaudio-utils hold

I haven’t get discovered if the Gnome package updater in lucid will honour the holds. Synaptic and apt-get will, but when I last tested (with jaunty), the Gnome updater blindly upgrades without regards to dpkg preferences. Lets hope some sanity has set in since then.

If you want to do something more complicated, or prefer editing iptables rules yourself, you’ll have to do it by hand. When I first started doing this I found a template online and edited it to suit my need. Over time I’ve learned a lot more about iptables, and my templates have evolved.

Here is a simple basic firewall. The outline is taken from the output of iptables-save, and then hand-edited. I’ve left comments in to explain what each section does.

*filter
:FORWARD ACCEPT [0:0]
:INPUT DROP [0:0]
:OUTPUT ACCEPT [0:0]
# Accept all loopback traffic
-A INPUT -i lo -j ACCEPT
# Drop invalid/unknown/spoofed TCP sessions
-A INPUT -p tcp ! --syn -m state --state NEW -j DROP
# Accept new sessions
-A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
# Accept important ICMP types
-A INPUT -p icmp -m icmp --icmp-type 0 -j ACCEPT
-A INPUT -p icmp -m icmp --icmp-type 3 -j ACCEPT
-A INPUT -p icmp -m icmp --icmp-type 4 -j ACCEPT
-A INPUT -p icmp -m icmp --icmp-type 8 -j ACCEPT
-A INPUT -p icmp -m icmp --icmp-type 11 -j ACCEPT
-A INPUT -p icmp -m icmp --icmp-type 12 -j ACCEPT
# Accept known services
-A INPUT -p tcp -m tcp -m multiport --dports 22,25,80,443,465,587,993,995 -j ACCEPT
-A INPUT -p udp -m udp -m multiport --dports 53,5353 -j ACCEPT
COMMIT

Edit the last two lines for your specific services, and then save the file as /etc/iptables.up.rules and restore it:

iptables-restore < /etc/iptables.up.rules

The above is a default-deny firewall which allows all outgoing and loopback traffic, but filters incoming connections. This means that anything not specifically allowed will be dropped without notice.

Suppose you want to do this at your router to protect all your servers. Assuming:

1. The router is the default gateway for both servers
2. server1 at 192.168.0.100 is a mail server offering SMTP, POP, POP-SSL, IMAP, and IMAP-SSL
3. server2 at 192.168.0.101 is a web server offering HTTP, HTTPS, and DNS
4. all servers offer SSH, including the router

For routed (forwarded) traffic, you must use the FORWARD chain. In addition to ACCEPT and DROP, chains can call other named chains. I recommend creating a chain for each server you want to protect.

*filter
:FORWARD DROP [0:0]
:INPUT DROP [0:0]
:OUTPUT ACCEPT [0:0]
:server1 - [0:0]
:server2 - [0:0]
-A INPUT -i lo -j ACCEPT
-A INPUT -p tcp ! --syn -m state --state NEW -j DROP
-A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
-A INPUT -p icmp -m icmp --icmp-type 0 -j ACCEPT
-A INPUT -p icmp -m icmp --icmp-type 3 -j ACCEPT
-A INPUT -p icmp -m icmp --icmp-type 4 -j ACCEPT
-A INPUT -p icmp -m icmp --icmp-type 8 -j ACCEPT
-A INPUT -p icmp -m icmp --icmp-type 11 -j ACCEPT
-A INPUT -p icmp -m icmp --icmp-type 12 -j ACCEPT
# if just a single port, you can avoid the multiport match extension and use dport
-A INPUT -p tcp -m tcp --dport 22  -j ACCEPT
# put common rules first
-A FORWARD -p tcp ! --syn -m state --state NEW -j DROP
-A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
-A FORWARD -p icmp -m icmp --icmp-type 0 -j ACCEPT
-A FORWARD -p icmp -m icmp --icmp-type 3 -j ACCEPT
-A FORWARD -p icmp -m icmp --icmp-type 4 -j ACCEPT
-A FORWARD -p icmp -m icmp --icmp-type 8 -j ACCEPT
-A FORWARD -p icmp -m icmp --icmp-type 11 -j ACCEPT
-A FORWARD -p icmp -m icmp --icmp-type 12 -j ACCEPT
# all servers offer SSH
-A FORWARD -p tcp -m tcp --dport 22  -j ACCEPT
# send specific traffic to custom rules
-A FORWARD -d 192.168.0.100 -j server1
-A FORWARD -d 192.168.0.101 -j server2
-A server1 -p tcp -m tcp -m multiport --dports 25,110,143,993,995 -j ACCEPT
-A server2 -p tcp -m tcp -m multiport --dports 80,443 -j ACCEPT
-A server2 -p udp -m udp --dport 53 -j ACCEPT
COMMIT

It's possible to reduce complexity by putting the common rules in another chain and calling it from both INPUT and FORWARD:

*filter
:FORWARD DROP [0:0]
:INPUT DROP [0:0]
:OUTPUT ACCEPT [0:0]
:common_fw - [0:0]
:server1 - [0:0]
:server2 - [0:0]
-A INPUT -i lo -j ACCEPT
-A INPUT -j common_fw
-A FORWARD -j common_fw
-A FORWARD -d 192.168.0.100 -j server1
-A FORWARD -d 192.168.0.101 -j server2
-A common_fw -p tcp ! --syn -m state --state NEW -j DROP
-A common_fw -m state --state ESTABLISHED,RELATED -j ACCEPT
-A common_fw -p icmp -m icmp --icmp-type 0 -j ACCEPT
-A common_fw -p icmp -m icmp --icmp-type 3 -j ACCEPT
-A common_fw -p icmp -m icmp --icmp-type 4 -j ACCEPT
-A common_fw -p icmp -m icmp --icmp-type 8 -j ACCEPT
-A common_fw -p icmp -m icmp --icmp-type 11 -j ACCEPT
-A common_fw -p icmp -m icmp --icmp-type 12 -j ACCEPT
-A common_fw -p tcp -m tcp --dport 22  -j ACCEPT
-A server1 -p tcp -m tcp -m multiport --dports 25,110,143,993,995 -j ACCEPT
-A server2 -p tcp -m tcp -m multiport --dports 80,443 -j ACCEPT
-A server2 -p udp -m udp --dport 53 -j ACCEPT
COMMIT

Where to save and how to load your rules depends on the distribution. Ubuntu and Debian don't have a standard way to load an iptables ruleset on boot. So I borrowed Webmin's practice of putting a line in /etc/network/interfaces:

# 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
        post-up iptables-restore < /etc/iptables.up.rules

Users of RPM-based systems like Fedora, RHEL, and CentOS have it easier. Save your rules in /etc/sysconfig/iptables, and they'll be loaded at boot or whenever you restart networking. However, Red Hat systems come with a simple firewall manager named lokkit, which creates its own unusual chains like "RH-Firewall-1-INPUT". Here is an example from a CentOS 4 server I administer:

*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:RH-Firewall-1-INPUT - [0:0]
-A INPUT -j RH-Firewall-1-INPUT
-A FORWARD -j RH-Firewall-1-INPUT
-A RH-Firewall-1-INPUT -i lo -j ACCEPT
-A RH-Firewall-1-INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 22 -j ACCEPT
-A RH-Firewall-1-INPUT -j REJECT --reject-with icmp-host-prohibited

You should never expect your hand-edited files to work with a firewall management tool like ufw or lokkit. However, if you are careful to obey the expected format these tools use, you can make small edits by hand while still using the tool. For instance, all of my templates are compatible with Webmin's firewall editor.

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.

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.

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 chown $USER:$USER /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.

I read an article in the Dec 2009 issue of Linux Magazine, one of several Linux-focused magazines we get at the office. I’d like to link directly to it, but it the magazine’s own website doesn’t offer the article or even a reliable permanent link to the issue number. Hint: hey guys, sort that out.

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.