Sometimes, however, it is not possible to have a flat configuration and you have built different subnets for administrative purposes. Still, you think it would be cool to have services advertised by machines on a given subnet, available to machines on any other subnet.

One way of dealing with this is to use multicast routing and have your interconnection equipment pass multicast traffic from one subnet to another around your organisation. The zeroconf protocol uses only a few group addresses so this is not a big hassle to implement.

However, routing multicast is not always possible. As crazy as it may seem, even in the 21st century, some routers or wireless access points don’t support multicast routing :( In this case, another solution that exists is the use of service proxies.

A zeroconf proxy is a server software that will advertise services which are not hosted on the same machine. In this way, you could have one machine on subnet 1 advertising all the services that are provided by machines on subnet 2 and vice-versa.

For OS X there is the excellent network beacon from chaotic software available which should help you solve almost any problem with subnets and bonjour, zeroconf.

When it comes to linux, the avahi deamon is the way to go, twenty seconds, a simple file in /etc is all it takes to advertise a service.

On Windows on the other hand, the search can be quite longer. Indeed, you might find Rendezvous Proxy from iLeech to be quite nice until you start playing with multi-field TXT records (for any elaborated service such as Airfoil Speakers for example). At that point you’ll find out it is broken and generates malformed packets so you’ll search a little more and eventually come across a google code project named Bonjour Beacon and voilà, you’re all set!

To summarize a long post, bonjour, rendezvous, zeronconf, avahi, mDNS are the name of the protocol and the software implementations of it but they all do the same thing (and play nice with one another).

If you subnet, you can route multicast or use a proxy.

Good proxies are, avahi on Linux, Bonjour Beacon on Windows and network beacon on OS X.

The first step you’d go if you were in the process of massively generating Xen domU would be to create a master virtual disk image and xen config file. A script that would clone this disk and configuration could then easily be written like this:
- Copy configuration file and disk image to a specific directory
- Edit configuration in order to adapt it to the new machines
- Launch the newly created domU

However, this process is suboptimal in many ways. First, each of the virtual machines that you’ve created will be using a copy of the master Xen drive image so a change to the system (i.e. software or distribution upgrade) would need to be performed on each domU individually. Also, the disk space requirements for such a setup can quickly become quite high, indeed, each domU needs a copy of the master disk image (typical Ubuntu deboostrap is around 700Mb).

One solution would be to use the same image file for all of the domU disks. However, a system, upon boot, needs a disk to which it can write. This is where things like a ramdisk or a second (smaller) virtual disk come handy. Yes but, how can you tell the system to write to this ramdisk instead of the shared disk image? Well, this is where unionfs (or aufs) filesystems come in handy. With these file systems, you can actually make two different partitions appear as a single one to the kernel.

For example; setups like the following can be achieved:
/dev/sda1 is 3Gb
/dev/sda2 is 300Mb

You can actually make it so that / is the union of both filesystems. For example, if either /dev/sda1 or /dev/sda2 contain the file /etc/fstab, then the resulting aufs file system will contain /etc/fstab. Furthermore, you can set it so that /dev/sda1 is read only and /dev/sda2 is read write. The hierarchy of aufs allows you to make it so that, if a file from /dev/sda1 is modified, it is written to /dev/sda2 and if a file is present on /dev/sda2, it has priority over the same file on /dev/sda1.

Now, how do you set that up for / ? As you know, the root of your system can hardly be remounted while the system has been booted. The idea is thus to prepare it (having / composed of two overlaid filesystems, one read only, the other read write) before that happens in an initramfs.

What follows works for Ubuntu 10.04 using the 2.6.32-24 kernel (as the latest one does not include the aufs module). I suppose that you have already deboostrapped a lucid ubuntu into a loop mounted filesystem image, chroot to the directory you mounted the image and do the following:


apt-get install aufs-tools
echo aufs >> /etc/initramfs-tools/modules


Next, you’ll need to add the script that will create the aufs hierarchy as
/etc/initramfs-tools/scripts/init-bottom/__rootaufs and chmod it as 755

This comes from the Ubuntu community wiki, I’ve adapted the script a little so that the read write parition is /dev/sda2


# Copyright 2008 Nicholas A. Schembri State College PA USA
#
# This program is free software: you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation, either version 3 of the License, or
# (at your option) any later version.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with this program. If not, see
# .

mount --move /aufs ${rootmnt}
exit 0


Once this is done, update the initramfs using:
update-initramfs -u

Exit the chroot and copy the newly generated initrd as well as the corresponding kernel outside the chroot (so you can have it available to xen on its filesystem).

Now, in the xenconfig for the domU you generate, you’ll need to pass aufs=tmpfs on the kernel line and reference the initrd that you copied out of the chroot. Be sure that the domU has two disks, sda1 (read-only) pointing to the disk image that will be shared by all, and sda2 which is a small (100Mb ?) disk image to which changes will be written. Also, you’ll want sda1 to be attached read-only to the machine so it can be attached to several domU simultaneously.

Depending on the number of machine instances you want, you’ll also want to increase the maximum number of loop mounted file systems on the host, this can be done by editing /etc/modules and adding options loop max_loop=64 (or any other value you like). Be sure to rmmod and modprobe loop again or reboot the host so the change is effective.

There you go, you should now have multiple domU virtual machines as Xen guests fully functional but sharing the same core disk image. Also, you might want to have IP addresses distributed by a dhcp server in a coherent way by generating the MAC address of the domU config file, the machine hostname can easily be customized by a kernel parameter that you add (following the aufs=tmpfs parameter) and as you certainly might want to have an ssh server running on each host, be sure that you remove the ssh host keys and add a dpkg-reconfigure openssh-server at the end of /etc/rc.local so they are generated on first boot (they’ll be stored on the read write partition).

Enjoy!

While there has been a support request in cacti for this particular feature and I’ve come across a patch for 0.8.6 on cacti forums, I haven’t found a solution that is integrated into cacti. So I went for an external graph generation script.

Cacti generates graphs by invoking rrdtool which itself relies on the value of the TZ environment variable to determine the offset that it must apply to variables stored inside the database. Indeed, the time stored in an rrd is UTC by default and an offset is applied during graph generation in order to transpose this to any local time according to the value of the TZ variable.

The script I’ve created simply uses the command line I got from cacti by turning graph debugging on in the graph management for the particular graph I wanted to export.

TZ="America/El_Salvador" /usr/bin/rrdtool graph -
--imgformat=PNG --start=-86400 --end=-300
--title="My graph title" --base=1000 --height=120
--width=500 --alt-autoscale-max --lower-limit=0
--vertical-label="" --slope-mode --font TITLE:12:
--font AXIS:8: --font LEGEND:10: --font UNIT:8:
DEF:a="/var/lib/cacti/rra/my_file.rrd":somefield:AVERAGE
AREA:a#AFECEDFF:"" > somefield_1.png

The TZ=”America/El_Salvador” part of the command line redefines the value of the TZ environment variable before executing rrdtool. This modification is only local to the process from which rrdtool is launched and does not affect the current shell. The TZ variable is part of the zoneinfo package, the full list of possible values for this variable can be found under the /usr/share/zoneinfo directory of any linux machine.

--start=-604800 --end=-1800
--start=-2678400  --end=-7200
--start=-33053184  --end=-86400

MAILTO=myusername
*/5 * * * * www-data /path/to/myscript.sh >/dev/null 2>&1

Using this trick, I can now generate graphs that make sense to the people they’re intended for without asking them to perform the conversion from UTC by themselves.

With a first beta release mid-March which allowed to spot some nasty bugs of all kind, the community is now working towards a second beta. Beta 2 is already past “freeze”, the point at which any additional change to the core packages of the distribution is subject to a process known as “freeze exception” for which good motivations must exist and thorough review is performed  by the release managers to make sure nothing that works is affected by the proposed change.

Needless to say, Lucid Lynx beta 2 will be a much more stable version with many bugfixes when its released on April 8th.

Areas in which you can still help at this points are:

• installing beta 2 and reporting bugs which are not yet reported or adding information to the existing report that might help track it down
• participating in the translation process through the translators groups until April 22nd.

The next step is to get a release candidate version on the 22nd for a final release of Lucid Lynx 10.04 LTS on April 29th! Get involved!

Below is a video of Mark Shuttleworth who was in Atlanta at the time announcing, among other things, the codename and release goals.

As always with Ubuntu, things such as codename and release goals are defined by the community through discussion and white papers. All of this takes places between Launchpad.net, IRC and mailing lists as well as some quality websites, blogs and the community wiki.

In the world of X and graphical frontends, terminals are still very useful. I’m having a hard time thinking of a day during the past year in which I didn’t fire one up for some task or the other. I often found myself with many terminals windows open at the same time which quickly became quite hard to manage. Luckily enough, I came across Terminator, a small utility that made my life alot easier.

Terminator is a gnome app which is an extension of the gnome-terminal application in order to integrate features that screen has. You start with a plain terminal, when you need another one, you go for a quick CTRL+SHIFT+o or CTRL+SHIFT+e to split it in half either horizontally or vertically. After opening a few you navigate between them by using CTRL+SHIFT+p and CTRL+SHIFT+n for respectively going to the previous and next one. Should you need extra space for a few moments to focus on something, you can expand the current terminal so it occupies the whole window by simply doing a CTRL+SHIFT+x, and there is a ton of other great features which I use less often.

Terminator can be installed by a simple apt-get install terminator in both debian and ubuntu ;) That rocks.

The official homepage can be found here:

Not only does the application allow you to pinpoint the places where you’ve been and hence about which you’d be able to give advice to your friends, it also allows you to let people know of your upcoming trips, find friends who’ve already been there in order to get tips. Really nice ;)

Traveling around the Toulouse region, in a path directed by hunger and satisfaction, I came across the most sincere door label I’d ever seen :)

The sign is displayed on the door to a “boulangerie” (bakery) and obviously is a call for the hungry tourist to come in and enjoy the region’s specialty. Although you can also find “calissons” which are not specially typical of the region in there too.

Anyway, I think the sing says it all.

@Work, I’ve worked on several software projects. First, I was a plain programmer not caring for the “where are we now?” question but rater quickly, I was assigned managerial responsibilities and the only thing that I had on my mind was “where are we now!?”. I’ve found the Trac project to be just what I needed in order to successfully calm my stress by providing a constant answer to the big question.

Trac is a great peace of software that allows you to keep track of everything that’s going on with your software project. More than a simple Bugzilla which only tracks bugs, the Trac project also allows you to manage things such as documentation, tasks, milestones, bugs, source code, …

Installing Trac on a linux server is quite straightforward, packages exist for most of the major linux distributions out there. On Ubuntu, a simple apt-get install trac does the trick. If you use version control on your project, you’ll be happy to know that trac supports almost all the tools out there such as CVS and SVN if you evolve in the entreprise world as I do, or Mercurial, git and Bazaar through plugins for those who don’t have the central repository constraint.

Once installed and linked to your version control system, you can start using Trac. As an administrator, you’ll want to give your users some rights and restrict some usages (maybe you don’t want everyone to be able to edit the wiki documentation). Also, an important aspect is that you’ll want to define some milestones for your project. Once you’re done doing that, you can start using the most powerful aspect of Trac, the tickets.

Tickets are an abstract representation of the task concept, a ticket can be about a bug, a feature request, a discussion on the evolution of the software, … Tickets can be assigned to the milestones you previously defined and when that’s done, the meaning of a ticket becomes: if it’s open then it represents an “issue” that has to be addressed before the milestone to which it is attached, otherwise, if it’s closed, it belongs to the past.

One of the powerful features of Trac is the ability to link commit messages to tickets using post-commit-hooks (very easy to setup using SubVersion for example). This allows for changes made to the source code to be referenced from the ticket that describes the problem that they address and vice-versa. This feature is great for the developers working on the source so they can be aware of previous changes made towards solving an issue of improving an aspect of the software.

For the manager, Trac is great as it will show changes as they are made and summarize what’s left to be done in order to reach this or that milestone. For the developer, this aspect is also great as it provides a constant answer to the questions “where are we now? what’s to be done next?”.