After 39 2.6.x releases Linus Torvalds has chosen to revisit the upstream kernel version.  The plan is to release what would have been 2.6.40 instead as version 3.0:

"I decided to just bite the bullet, and call the next version 3.0. It
will get released close enough to the 20-year mark, which is excuse
enough for me, although honestly, the real reason is just that I can
no longe rcomfortably count as high as 40."

When 3.0-rc1 was released the Kernel Team had to decide what version to use for it in Ubuntu.  We typically upload every -rcN release within a couple of days of its release so the pressure was on.  We could simply call it 3.0.0 knowing that all the current scripting would cope, or as 3.0 better matching its official name knowing this would not be plain sailing.  This was not a decision we could delay as in Debian versioning 3.0 < 3.0.0 so we were likely to be committed for Oneiric if we uploaded using 3.0.0.  It is also not clear from upstream discussion what version number the final release will carry, as 3.0 clearly will cause breakage on older userspace.

After much discussion we decided we bite the bullet and upload a 3.0 kernel.  At least we get a chance  to identify problematic applications, while still keeping our options open to move to a 3.0.0 kernel for release should that be prudent.  As expected this was not smooth sailing, not least for the kernel packaging which needed much love to even correctly build this version.  Plus we had to hack the meta packages to allow that to be reversioned later too.

Once successfully uploaded the problem applications started to crawl out of the woodwork:

• depmod -- the depmod incantion to create the module dependancies identifies the kernel version in its command line but was assuming that a version contained three digits, this lead it to miss the version entirely and rebuild the wrong dependancies;
• libc6 -- both the runtime and the installation control scripts manipulate the kernel version number, in both cases assuming the version was three digits, enormous fun getting the pending updates installed;
• ps/top -- when starting the kernel version was checked, and miss decoded triggering a rather nasty sounding version warning whenever they are started;
• nfs-utils -- when attempting to read and identify the kernel version the nfs-utils would trigger a SIGSEGV and die, triggering boot failures on machines with NFS roots; and
• lm-sensors-3 -- this package is only compatible with 2.6.5 and above, failed version detection lead to this test failing and sensors being unconfigured.

Read more

During the early part of the Maverick cycle we once again revisited out Union Mount solution.  At that time VFS union-mounts was the hit of the day, set to finally to produce something which might get into the kernel.  Since then the complexity of changing every filesystem to support whiteouts, its invasiveness, and its affects on Posix semantics have lead to it falling by the wayside.  In its place has sprung overlayfs.

overlayfs is a small patch set which is a hybrid of the VFS union-mount approach and that of aufs/unionfs in that it also provides a filesystem.  This greatly reduces the complexity of the patch set, reducing its invasiveness and thus increasing its chances of ever being merged.  So much so simpler is it that your author is actually able to understand and debug it.  Win.

We have been tickling overlayfs for most of the Natty cycle, but with Natty in the can I have had had some time to catch up with its development and help out a little, both with testing and bug fixing.  Culminating today in my being able to inject a kernel containing overlayfs support into an Ubuntu LiveCD and boot it, then update it to the latest Natty, all without error.

overlayfs may shortly be in a mergable state, nirvana for all union mount lovers.  Only time and testing will tell.

Read more

(Just released Arkose 1.0 that’s a full rewrite in python using LXC and introducing a nice GUI for fine grained app restriction. Read below for details.)

Those of you who read my blog know that I’ve been working on a pet-project of mine called Arkose.
This project is used as the base for WebLive‘s feature allowing users to easily test any package in the Ubuntu archive.

At the Ubuntu Developer Summit, last month in Hungary, I was leading a session on application containing and gathered ideas on how to improve the safety of our user’s desktop while still making it easy for app developers.

Today, I’d like to present you with the initial result, the new version of Arkose which I ended up releasing as 1.0 (as it’s a full rewrite).

The biggest new feature is the “wrapper” that can be used by packagers or upstreams to specify what the software will have access to, so Arkose will spawn a container that only has access to these resources.

Current access controls include:
- Which user to run the software as (current user or root user)
- Network access (currently, all or nothing)
- X server access (either no access at all, an independent X server using xpra or direct X access)
- DBUS access (any combination of session bus, system bus or no dbus access at all)
- Pulseaudio access (enabled or not)

Then the app can specify a list of paths using one of these options:
- Direct filesystem access with read/write depending on user permissions
- Overlay filesystem access, similar to direct but all changes are dropped when the app exits
- Temporary empty directory. created and available to the app and dropped when the app exits

As an example, here’s the definition file for a completely isolated “xeyes”:
[xeyes]
cmd="xeyes"
runas=user
network=false
xserver=isolated
dbus=none
pulseaudio=false
mount_bind=
mount_cow=
mount_restrict=

In this case, xeyes will appear almost as it’d in a regular environment. The only difference you’ll notice is that it won’t follow your mouse unless it’s in xeyes’ window. Also, if xeyes was to have some bug, it wouldn’t be able to eavesdrop on dbus, do any damage to the filesystem or even play a sound.

This 1.0 release is available for download at:
https://launchpad.net/arkose/trunk/1.0
Development code is available on Launchpad at:
https://code.launchpad.net/~arkose-devel/arkose/trunk
I have PPA builds for Maverick and Natty at:
https://launchpad.net/~arkose-devel/+archive/stable
The package also just got uploaded to Ubuntu Oneiric.

To start the gedit from the screenshot above, use:
arkose-wrapper-gui /usr/share/doc/arkose/examples/profiles/gedit.conf
Some other example profiles are available in:
/usr/share/doc/arkose/examples/profiles/

Here’s an example of how to use the new python module:
import arkose
container=arkose.ArkoseContainer(xserver="isolated",pulseaudio=True,network=True)
container.run_command("su stgraber -c xterm")
container.cleanup()

That will start an xterm as the user “stgraber” on an isolated X server and with pulseaudio and network support.

Next step for the project is to improve the GUI part, add all the new cool features to the old commands (arkose and arkose-gui), work on fine grained network access control and allow for translations. 1.1 should be released relatively soon with bug fixes and maybe some of these features.

I appreciate any comment or bug report. Comments can be left on this blog and bug reports on Launchpad: https://launchpad.net/arkose/+filebug

Read more

A while ago I posted about LXC and how to use it on Ubuntu 9.10, I think it’s time to update these instructions to the current state of LXC in Ubuntu 11.04.

As a quick reminder LXC stands for Linux Containers and uses the relatively recent cgroup and namespace features of the Linux kernel to offer something that’s between a chroot and a virtual machine. That’s, basically a chroot but with fine grained resource allocation, its own network stack and its own pid namespace.
LXC is very similar to OpenVZ and Linux-Vserver but doesn’t depend on kernel patches to work.

So here’s now how to get it working on Ubuntu 11.04 in a much easier way than back in Ubuntu 9.10, thanks to all the work done upstream.

To get LXC working on Ubuntu 11.04, you’ll need to do the following:

• Install a few packages: lxc, debootstrap and bridge-utils
• Create a bridge interface with masquerading and a local IP address
• Create a mountpoint for the cgroup filesystem and make sure it’s mounted
• Write a network configuration file for your container
• Create your container (the template gets generated with the first container)

To make it even easier, I wrote the following script that you can start as root to do all the above.
It’ll add a “br-lxc” interface using the 192.168.254.0/24 network and configure masquerading.
The cgroup filesystem will be mounted at boot time in /cgroup.
A first container called natty01 will be created and started with IP 192.168.254.2 and default root password “root”.

The script is (I think) well commented and I’ve clearly indicated what’s to be run once (to setup LXC) and what’s to be run for every container you may want to create.
Script can be downloaded from: http://www.stgraber.org/download/lxc-demo.sh.

Once you have a container started, you can start playing with:

• Attach to a VT: lxc-console –name natty01
• Get the status: lxc-info –name natty01
• Get the list of running processes: lxc-ps –name natty01 aux
• Start/Stop containers: lxc-start/lxc-stop

Have fun!

Read more

In my last blog post about WebLive I announced the availability on WebLive of the top-50 apps from the new Ratings & Review service.

Today I’m happy to announce that this feature is no longer necessary as you can now test drive anything that’s available in the Ubuntu archive.

At the moment that’s over 1300 desktop application that you can test this way.
That’s basically any GUI app that requires less than 150MB of space to install and that’s not in one of my blacklists (video editing, 3D, VOIP, VMs, …).

As a reminder, all that you need is an up to date Ubuntu 11.04 system and the qtnx package installed (default in Edubuntu).
Full desktop sessions are still available at: http://www.edubuntu.org/weblive

This feature uses another of my pet projects Arkose to dynamically create containers (see LXC) whenever someone logs in. Each user is allocated up to 500MB for the test drive feature. On login, the system will check if it already has the requested app in the default system and if not, will download and install it when you connect.

Enjoy !

NOTE: The current blacklist isn’t perfect, so if you notice any package that has a Test drive button in the Software Center and doesn’t work, please file a bug here: https://launchpad.net/weblive/+filebug

Read more

Starting last Friday (1st of April) I’m now working for Canonical Ltd. as a member of the Ubuntu Foundations team !

I’ll mostly be working on network related stuff, though my TODO list will probably be a lot clearer after the upcoming Ubuntu Developer Summit in Budapest, Hungary.

I learnt a lot during the past 2 and a half years at Revolution Linux and wish them all the best for the future. It’s a great company with very qualified technical people working on awesome projects.

This also means I’ll be stepping down as leader of the LTSP-Cluster project but will remain active as upstream developer and packager for LTSP itself as well as all my other pet projects.

Read more