• sudo apt-get install lxc qemu-user-static
• sudo lxc-create -n armhf01 -t ubuntu — -a armhf -r precise
• sudo lxc-start -n armhf01
• Then login with root as both login and password

And enjoy an armhf system running on your good old x86 machine.

Now, obviously it’s pretty far from what you’d get on real ARM hardware.
It’s using qemu’s user space CPU emulation (qemu-user-static), so won’t be particularly fast, will likely use a lot of CPU and may give results pretty different from what you’d expect on real hardware.

Also, because of limitations in qemu-user-static, a few packages from the “host” architecture are installed in the container. These are mostly anything that requires the use of ptrace (upstart) or the use of netlink (mountall, iproute and isc-dhcp-client).
This is the bare minimum I needed to install to get the rest of the container to work using armhf binaries. I obviously didn’t test everything and I’m sure quite a few other packages will fail in such environment.

This feature should be used as an improvement on top of a regular armhf chroot using qemu-user-static and not as a replacement for actual ARM hardware (obviously), but it’s cool to have around and nice to show what LXC can do.

I confirmed it to work for armhf and armel, powerpc should also work, though it didn’t succeed to debootstrap when I tried it earlier today.

Enjoy!

Bonding

Bonding basically means aggregating multiple physical link into one virtual link for high availability and load balancing. There are different ways of setting up such a link though the industry standard is 802.3ad (LACP – Link Aggregation Control Protocol). In that mode your server will negotiate with your switch to establish an aggregate link, then send monitoring packets to detect failure. LACP also does load balancing (MAC, IP and protocol based depending on hardware support).

One problem we had since at least Ubuntu 10.04 LTS is that Ubuntu’s boot sequence is event based, including bringing up network interfaces. The good old “ifup -a” is only done at the end of the boot sequence to try and fix anything that wasn’t brought up through events.

Unfortunately that meant that if your server takes a long time to detect the hardware, your bond would be initialised before the network cards have been detected, giving you a bond0 without a MAC address, making DHCP queries fail in pretty weird ways and making bridging or tagging fail with “Operation not permitted”.
As that all depends on hardware detection timing, it was racy, giving you random results at boot time.

Thankfully that should now be all fixed in 12.04, the new ifenslave-2.6 I uploaded a few weeks ago now initialises the bond whenever the first slave appears. If no slave appeared by the time we get to the catch-all “ifup -a”, it’ll simply wait for up to an additional minute for a slave to appear before giving up and continuing the boot sequence.
To avoid another common race condition where a bridge is brought up with a bond as one of its members before the bond is ready, ifenslave will now detect a bond is part of a bridge and add it only once ready.

Tagging

Another pretty common thing on corporate networks is the use of VLANs (802.1q), letting you create up to 4096 virtual networks on one link.
In the past, Ubuntu would rely on the catch all “ifup -a” to create any required vlan interface, once again, that’s a problem when an interface that depends on that vlan interface is initialised before the vlan interface is created.

To fix that, Ubuntu 12.04′s vlan package now ships with a udev rule that triggers the creation of the vlan interface whenever its parent interface is created.

Bridging

Bridging on Linux can be seen as creating a virtual switch on your system (including STP support).

Bridges have been working pretty well for a while on Ubuntu as we’ve been shipping a udev rule similar to the one for vlans for a few releases already. Members are simply added to the bridge as they appear on the system. The changes to ifenslave and the vlan package make sure that even bond interfaces with VLANs get properly added to bridges.

Complex network configuration example

My current test setup for networking on Ubuntu 12.04 is actually something I’ve been using on my network for years.

As you may know, I’m also working on LXC (Linux Containers), so my servers usually run somewhere between 15 and 80 containers, each of these container has a virtual ethernet interface that’s bridged.
I have one bridge per network zone, each of these network zone being a separate VLAN. These VLANs are created on top of a two gigabit link bond.

At boot time, the following happens (roughly):

1. One of the two network interfaces appear
2. The bond is initialised and the first interface is enslaved
3. This triggers the creation of all the VLAN interfaces
4. Creating the VLAN interfaces triggers the creation of all the bridges
5. All the VLAN interfaces are added to their respective bridge
6. The other network interface appear and gets added to the bond

My /etc/network/interfaces can be found here:
http://www.stgraber.org/download/complex-interfaces

This contains the very strict minimum needed for LACP to work. One thing worth noting is that the two physical interfaces are listed before bond0, this is to ensure that even if the events don’t work and we have to rely on the fallback “ifup -a”, the interfaces will be initialised in the right order avoiding the 60s delay.

Please note that this example will only reliably work with Ubuntu Precise (to become 12.04 LTS). It’s still a correct configuration for previous releases but race conditions may give you a random result.

I’ll be trying to push these changes to Ubuntu 11.10 as they are pretty easy to backport there, however it’d be much harder and very likely dangerous to backport these to even older releases.
For these, the only recommendation I can give is to add some “pre-up sleep 5″ or similar to your bridges and vlan interfaces to make sure whatever interface they depend on exists and is ready by the time the “ifup -a” call is reached.

IPv6

Another interesting topic for 12.04 is IPv6, as a release that’ll be supported for 5 years on both servers and desktops, it’s important to get IPv6 right.

Ubuntu 12.04 LTS will be the first Ubuntu release shipping with IPv6 private extensions turned on by default. Ubuntu 11.10 already brought most of what’s needed for IPv6 support on the desktop and in the installer, supporting SLAAC (stateless autoconfiguration), stateless DHCPv6 and stateful DHCPv6.

Once we get a new ifupdown in Ubuntu Precise, we’ll have full support for IPv6 also for people that aren’t using Network Manager (mostly servers) which should at this point give us support for any IPv6 setup you may find.

The userspace has been working pretty well with IPv6 for years. I recently made my whole network dual-stack and now have all my servers and services defaulting to IPv6 for a total of 40% of my network traffic (roughly 1.5TB a month of IPv6 traffic). The only user space related problem I noticed is the lack of IPv6 support in Nagios’ nrpe plugin, meaning I can’t start converting servers to single stack IPv6 as I’d loose monitoring …

I also wrote a python script using pypcap to give me the percentage of ipv6 and ipv4 traffic going through a given interface, the script can be found here: http://www.stgraber.org/download/v6stats.py (start with: python v6stats.py eth0)

What now ?

At this point, I think Ubuntu Precise is pretty much ready as far as networking is concerned. The only remaining change is the new ifupdown and the small installer change that comes with it for DHCPv6 support.

If you have a spare machine or VM, now is the time to grab a recent build of Ubuntu Precise and make sure whatever network configuration you use in production works reliably for you and that any hack you needed in the past can now be dropped.
If your configuration doesn’t work at all or fails randomly, please file a bug so we can have a look at your configuration and fix any bug (or documentation).

To achieve this and still be as productive as before (if not more), I’m using arkose quite a lot to generate temporary dev/build environment that are wiped as soon as I close the shell.
This helps maintain the number of extra libraries to a minimum, avoiding situations where something mysteriously works fine on my laptop but not on another machine and avoids the maintenance needed when dealing with chroots.

An example of this is when I’m working on ubiquity (the Ubuntu graphical installer).
Ubiquity depends on quite a few libraries and development packages that are required even if you just want to build its source package.

So having arkose installed on my system, I usually start working on a bug with:

sudo arkose -n -h -c "cd $PWD; $SHELL"

You can make that an alias if you use it quite often. At this point, you’ll see your shell showing a different hostname, like “arkose-tmpaF9yqa”, that’s how you know you’re in a container.
The command above creates a new container using copy-on-write for all the file system but your home directory and lets the container access the network without any restriction.

I then install all the packages I’ll need to work

sudo apt-get build-dep ubiquity

Then work as usual in that container, run debuild, dput, … everything should work as usual as it has direct access to my home directory.

Once I’m done and I don’t need all these packages anymore, I just exit that shell and all the changes done outside of /home will be lost.

There’s also the case where you may want to get the all new and shiny version of a software but still keep the old version around as some other users may prefer it or other software may depend on it. The current way of doing that is by spending quite a bit of time packaging the version to avoid any filesystem conflicts, this works but is usually quite painful to do.

So a few weeks ago I quickly hacked together a debhelper script called dh_ubuntuarb that runs at the end of the package build process and moves all the content to /opt/extras.ubuntu.com/<package name> except for .desktop entries that are renamed to be arb-<package name>-<original name> and altered to run using “arb-wrapper”.

arb-wrapper uses an overlay fuse filesystem to create a view where the content of the package is stacked on top your root filesystem, it then uses fakechroot to make the app believe it’s running in /.

The software and the user shouldn’t notice any difference and doing that solves the whole file system conflicts and allows you to run as many version of the package as you want (it just needs to have a different name). This is particularly handy for automated packaging where you don’t want to spend too much time reviewing the packages and for cases where you want to run multiple version of the same package.

This code is very much proof of concept and might be extended and uploaded to the archive for Ubuntu 12.04. For now it can be tested in a PPA: https://launchpad.net/~stgraber/+archive/arb-testing

Below is an example using “lightyears” from the arb-testing PPA:
# Build lightyear with dh_ubuntuarb and installed it on my system
# then created an empty /tmp/test directory
stgraber@castiana:~$ ls /tmp/test
stgraber@castiana:~$ which lightyears

# Now starting the overlay of my / and /opt/extras.ubuntu.com/lightyears/
stgraber@castiana:~$ arb-wrapper lightyears bash

# Checking that lightyears is indeed accessible now
stgraber@castiana:/$ which lightyears
/usr/games/lightyears

# Creating some data
stgraber@castiana:/$ touch /tmp/test/me

# Exiting the environment
stgraber@castiana:/$ exit

# And the file is still there
stgraber@castiana:~$ ls /tmp/test/me
/tmp/test/me

Installing the “lightyears” package from that PPA will add a desktop entry called arb-lightyears_lightyears.desktop in /usr/share/applications and that’s the only change that will happen outside of /opt/extras.ubuntu.com/lightyears. This software will appear in your menu as usual and when you click on it will use the arb-wrapper to start just as you’d expect it to.

I’m very much interested in hearing ideas of possible use cases for that kind of things in Ubuntu and hope to be able to discuss it more in Orlando at the next UDS.
I think we should be able to get some pretty exciting things going using that kind of tools and containers like arkose provides.

UPDATE: The “arb” in the script names stands for the Ubuntu App Review Board which was the initial reason for doing that work as an easy way of getting a package to match our packaging requirements.

One of my goals for Edubuntu 11.10 was to have all our custom components (installer steps, LTSP, Arkose, …) supporting translations as early as possible so people can just boot our DVD and get a fully translated environment right out of the box (yes, we ship all the langpacks).

While that goal has been relatively easily reached, Edubuntu still needs some help getting everything translated. Here are a few links to some parts of Edubuntu that need some love:

• Edubuntu installer
• Edubuntu installer slideshow
• LTSP Live
• Arkose

All of the above weren’t translated at all in Edubuntu 11.04 so they definitely need help to get as good as the rest of the distro.

More information on helping translating Ubuntu (not only Edubuntu) can be found on the wiki: https://wiki.ubuntu.com/Translations

Thanks!

Right before the Ubuntu Feature Freeze last Thursday, I released Arkose 1.3 brining most of the features I wanted for Ubuntu 11.10.

Here’s a brief list of the new stuff Arkose can do:

• All the UIs and CLIs now support translation with an initial (rough) french translation already available.
• DBUS filtering is now included in Arkose and available through the wrapper. The gedit example profile is using it.
• It’s now possible to temporarily modify a wrapper profile before starting it.
• Device support has been changed to no longer be limited to /dev/video* devices.

Some bugs have also been fixed, most of them in Arkose 1.3.1 (released yesterday):

• Make the Global Menu integration (dbusmenu) work with Ubuntu Oneiric
• Update the test suite
• Fix arkose-cli’s help to be a lot more accurate
• Restrict LXC’s configuration to the bare minimal
• Use point-to-point network configuration in filtered mode (rather than a /30 per container)
• Make sure everything in the container gets properly killed on exit
• Fix Arkose to handle command line parameters properly (instead of just ignoring them)

That’s all available in current Ubuntu Oneiric as well as in the arkose stable PPA for Ubuntu 10.10 and Ubuntu 11.04.

Sadly one feature didn’t make it in time for Feature Freeze, that’s the advanced firewalling in filtered network mode. I’ll probably be working on it on the side and push it to a 1.4 branch that’ll be used for Oneiric+1.

I’ll now mostly be focusing on bugfixes for the remaining of the cycle and polishing some of the existing features. So please, test it and file bugs!

If you want to help with the translation effort, you can go translate Arkose on Launchpad or just send me a .po and I’ll do it for you.

For these who want to run the current upstream code, get the bzr branch:
bzr branch lp:arkose

I based my work on Alban’s DBUS proxy for N900, made the proxy work with multiple connections and added support for logging and filtering of the connections.

The result is profiles like this one:
outgoing;org.freedesktop.DBus.Properties;/com/canonical/menu/*;PropertiesChanged
outgoing;com.canonical.AppMenu.Registrar;/com/canonical/AppMenu/Registrar;RegisterWindow
outgoing;com.canonical.dbusmenu;/com/canonical/menu/*;LayoutUpdated
outgoing;com.canonical.dbusmenu;/com/canonical/menu/*;ItemsPropertiesUpdated

incoming;org.freedesktop.DBus.Properties;/com/canonical/menu/*;GetAll
incoming;com.canonical.dbusmenu;/com/canonical/menu/*;GetLayout
incoming;com.canonical.dbusmenu;/com/canonical/menu/*;Event
incoming;com.canonical.dbusmenu;/com/canonical/menu/*;AboutToShow
incoming;com.canonical.dbusmenu;/com/canonical/menu/*;GetGroupProperties

Which in this case will allow the applications using the proxy to access the global menu DBUS API and receive events from the Global menu, but not for example dump your gnome keyring.

Here’s the output you’d get when running gedit using the above profile:
http://www.stgraber.org/download/gedit-dbus-arkose.log

Now that the proxy works as expected, I’ll work on integrating it into Arkose itself and expose it in the wrapper GUI.

To try the proxy, you can grab Arkose’s trunk branch at:
bzr branch lp:~arkose-devel/arkose/trunk/

Build the proxy (you’ll need glib and dbus) and then run it with:
./proxy /tmp/arkose_dbus profiles/dbusmenu.conf

Starting clients like this:
DBUS_SESSION_BUS_ADDRESS=unix:path=/tmp/arkose_dbus gedit

To achieve this, I started working on the list of all possible scenarios I could think of with all possible combinations of IPv4 and IPv6. Then checked how well these were supported on Ubuntu.

Since Ubuntu 11.04, we now have a DHCPv6 aware DHCP client but that’s not working as well as it should because Network Manager didn’t do IPv6 by default back then and because the DHCP client configuration for IPv6 wasn’t too clear (dhclient wasn’t requesting any attribute).

Most of these issues are now fixed in Oneiric with Mathieu Trudel-Lapierre‘s great work on updating Network Manager in Oneiric to have IPv6 on by default and make sure people don’t have to wait for IPv6 to timeout to get their IPv4 connectivity.

The result is something like you can see below, on a network that has both DHCPv4 and stateless DHCPv6:

The use cases that are currently tested are:

• Single stack: SLAAC IPv6-only network
• Single stack: Stateful DHCPv6 IPv6-only network
• Single stack: Stateless DHCPv6 IPv6-only network
• Single stack: DHCPv4 IPv4-only network
• Dual stack: SLAAC + DHCPv4 network
• Dual stack: Stateful DHCPv6 + DHCPv4 network
• Dual stack: Stateless DHCPv6 + DHCPv4 network

For these interested, you can look at the following files to get some example DHCPv4, DHCPv6 and RADVD configuration:

• dhcpd.conf.ipv6
• dhcpd.conf.ipv4
• radvd.conf

It’s worth noting that you have to start a separate dhcpd server for IPv6 (with the -6 flag) as dhcpd can’t answer both dhcpv4 and dhcpv6 at the same time. You need two separate daemons with two separate configuration files.

As you can see from the files above, I have a pretty complete IPv6 test setup, running on libvirt. I’m now working on automating all of this so we can get some easy regression testing of IPv6 support on Ubuntu.

During our sprint last month in Dublin, Colin Watson also got netcfg to support IPv6 thereby making debian-installer working with IPv6. The missing piece now is ifupdown support of DHCPv6 (so you can configure DHCPv6 in /etc/network/interfaces) and we should then have Ubuntu install on IPv6 from the alternate/server disks.

IPv6 support is starting to look really good for Oneiric and should be awesome for the next LTS.
If you’re already running Oneiric on an IPv6 capable network, please test the new Network Manager and if you encounter any problem, please file bugs or poke me so I can add some more tests to my list!

On Monday I released version 1.1 that was mostly bugfixes and introduced a new profile for Skype. Then after that I started working on the interesting stuff to end up releasing 1.2.1 on Thursday evening.

The new features are:

• Filtered network support (one interface per container, routed/firewalled)
• Video devices passthrough  (useful for Skype)
• Support bind mount of files (thanks to Colin Watson)
• Reworked UI for the wrapper

A lot of bugfixes also went in during the week. Now when Arkose crashes or raises an exception, it should deal with it properly, unmount everything and exit rather than leaving you with a lot of entries in your mount table.

The new Skype profile now lets you start Skype in an environment where it’ll only be able to see its configuration file, run on a separate isolated X server, access pulseaudio on a separate socket and only access the few video devices Arkose detected.

During the week I also spent some time talking to the Ubuntu Security team who also happen to be upstreams for Apparmor. In the future Arkose should start using Apparmor in cases where we don’t need an actual LXC container (depending on the profiles).

I also started working on a protocol-aware DBUS proxy based on the work from Alban Crequy so that Arkose should soon be able to filter what DBUS calls an app is allowed to do and prompt the user when accessing restricted information (keyring, contacts, …).
I’m hoping to have this merged into Arkose’s trunk branch this week.

After that I plan on spending some time implementing the network restrictions on top of the new “filtered network” support I introduced last week. Initially that should cover restricting an app to non-private (rfc1918) networks and eventually support fine grained filtering (destination and port).

Version 1.2.1 is available as tarballs on Launchpad or from the bzr branch or in current Ubuntu Oneiric. PPA builds are also available for Maverick and Natty.

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