Blogging is hard, isn't it? Finding a topic that's not better placed on specific mailing list or somewhere else is not easy. One of the classical subjects for bloggers is ranting. And that's what I would love to do now :-)

I have had discussions with people who are turning away from Debian in the past few months, mostly to Debian derivatives like Ubuntu. Mostly, the reason for that is some sort of software that is newer/better supported/blabla in some other distribution, which I think is OK. Debian has a policy of a long, painful release cycle, but the stable releases that come out of it tend to be useful for a long time and relatively bug-free. That is good and shouldn't be changed without good reason.

Most of the people I spoke too revealed a far more disturbing thing: The long release cycle isn't the only argument against using Debian. Most of these people had other reasons, and a good number of those are things that Debian as a whole can - and should - address. Mostly, the Debian BTS comes up as a topic. Not because we don't use the Industry Standard [tm] bugzilla (which I personally hate so much I can't even describe), but because the BTS contains a lot of old bugs nobody cares about. Look at most of our packages: Bugs filed 7 years ago, with the last activity from that time, without a hint how (and if) they are ever closed are not uncommon; they are what you actually expect if you look at a bug list.

Naturally, processing, forwarding and closing bugs is the task of the maintainer. This doesn't work out in all cases, we have more than one cases where maintainers are overwhelmed by the sheer number of bugs flowing in against their packages. Also, and that is probably accepted everywhere: Bug processing is uncool. It is so much more fun to rewrite your code, add features, get new packages in the archive and doing new, blingy stuff, that the boring maintenance work of existing packages moves to a place far down on the todo lists. But hey, this maintenance. That's what maintainers are for. Most Debian Developers are Package Maintainers. They should do it, not adding new stuff.

We need to discuss how to work around these issues. We are not the only project which an overfilled bug tracking system. Look at the Gnome and KDE projects, the number of bugs filed against Mozilla products each day. Can we learn something from them? I would be happy to get a bit of feedback about this, so whoever is involved in other projects which have found better days to deal with bugs, please send a mail.

Apart from the fact that I would love to get more input on this, I want to start something new for lenny, the stable release planned after etch. I want to get the bug count down. Not the release critical bug count (which is eagerly watched all the time), but the small issues that bug users every day. For that, I have planned to look at 5 random important and normal bugs each day (starting with software I use) starting the day etch is released. I may begin to do this earlier, but I'm currently really not swimming in free time.

I don't plan on fixing all these issues (well, I may, if I can easily reproduce them), but more on forwarding them to the appropriate place, upstream, and noting so in the BTS. I want to poke maintainers long enough to invest some more time in fixing bugs. This will also help with the MIA efforts of the QA team, I guess...

Oh, what I almost forget: I expect help from all of you!

Hah! Targetted memes have hit again - Arareko decided I should talk about myself. I will do this, but I won't point the finger at five others - Lets see just who bites ;-) Besides, having left this post rot as a draft for over a week already, it got a bit more interesting: The meme bit from two sides. Arareko (as well as Ion) was bitten by Cicloid, from the mx.planetalinux.org-derived side of reality, and then Hanna bit Wouter on Planet Debian. Ok, time to get this message out from the freezer...
So... Five not very well known things about me? Ok, here I go.

1. Many people inquire me routinely about my name, specially when reading it off an official document where it appears with both names and both family names (Gunnar Eyal Wolf Iszaevich). As many Jewish families, mine comes from all over Europe: My mother-side grandparents were both born in Poland (hence the Iszajewicz, morphed into the slightly more writable Iszaevich). My father-side grandmother was born in Vienna, Austria (I still have some family in Graz), and my father-side grandfather was a proud child of the Austro-Hungarian empire - His family probably was originally Austriac (Wolf is a German name), but became Hungarian and Hungarian was their home language. He was born in Felszoviso, Transilvania (the part of Hungary that later became Northern Romania). And, yes, I mentioned my family is Jewish, so having the Hebrew name Eyal (my second given name) is no surprise. Now, about Gunnar? Well, I still don't know :) It's a Scandinavian name. My family has no (upwards) relation to Scandinavia, but both of my parents (although merely by coincidence, and with over 30 years between periods) lived in Western Sweden - My father, 1970-1972, and my mother, 2003-2006. Oh, and people usually expect them to carry strange foreign names as well - No, they are Bernardo and Ofelia.
2. I like to think started my journey into Free Software very early in my life. No, I didn't use Linux until 1994 (and only installed it in 1996), I'm not talking about such a modern piece of free software. I first touched computers around 1983-1984, when my father used to take me on Friday nights to his institute, to play with the computer. This computer was a Foonly F2, administered by La Mancha. What did I use to play on such a beast? Why, of course, I used Emacs to write TeX! Rumors say that this Foonly had the first TeX installation outside of Stanford (I guess this fact derives from Donald Knuth's visit to UNAM in 1977 - But of course I don't remember that!)
3. My family is bitterly split in two camps: Those who love eggplant and those who hate it. At least my parents, my aunt and I are known to love it. At least my wife (Nadezhda), my brother and two of my cousins are known to hate it. The feelings towards this noble plant are really strong, but out of respect for the other party of the family, we practically never cook with it.
4. Now that we mention food-related strangeness, I was a vegetarian for almost my first 20 years of life. My father is still a vegetarian (for over 35 years already). Nadezhda became a vegetarian almost a year ago. I still think I have saved enough karma during those 20 years to endure some more meat eating, but who knows... I might switch back just to be on the safe side ;-)
5. Often, memes can absorb too much energy from me. Even having left this entry not responded for over a week, I've been thinking (and forgetting) on and off what to write in it. So, Mauricio, thanks for making me waste my time this way! ;-) I hope this fact counts as a legal fifth thing.

The issue of core file management has come up for discussion again in the SE Linux list.

I believe that there are two essential security requirements for managing core files, one is that the complete security context of the crashing process is stored (to the greatest possible extent), and the other is that processes with different security contexts be prevented from discovering that a process dumped core (when attacking a daemon it would be helpful to know when you made one of it's processes dump core).

The core file will have the same UID and GID as the process that crashed. It's impossible to maintain the complete security context of the crashing process in this manner as Unix permissions support multiple supplementary groups and Unix filesystems only support one GID. So the supplementary groups are lost.

There is also a sysctl kernel.core_pattern which specifies the name of the core file. This supports a number of modifiers, EG the value "core.%p.%u.%g" would give a file named "core.PID.UID.GID". It would be good to have a modification to the kernel code in question to allow the SE Linux context to be included in this (maybe %z).

To preserve the SE Linux context of the crashing process with current kernel code we need to have a unique type for each process that dumps core, this merely requires that each domain have an automatic transition rule for creating files in the directory chosen for core dumps. In the default configuration we have core files dumped in the current directory of the process. This may be /tmp or some other common location which allows an attacker to discover which process is dumping core (due to the directory being world readable) and in the case of SE Linux there may be multiple domains that are permitted to create files in /tmp with the same context which gets in the way of using such a common directory for core files.

The traditional Unix functionality is to have core files dumped in the current directory. Obviously we can't break this by default. But for systems where security is desired I believe that the correct thing to do is to use a directory such as /var/core for core files, this can be easily achieved by creating the directory as mode 1733 (so that any user can create core files but no-one but the sys-admin can read them) and then setting the core_pattern sysctl to specify that all core files go in that directory. The next improvement is to have a poly-instantiated directory for /var/core such that each login user has their own version. That way the user in question could see the core files created by their own processes while system core files and core files for other users would be in different directories. Poly-instantation is easier to implement for core files than it is for /tmp (and the other directories for which it is desirable) because there is much less access to such a directory. When things operate correctly core files are not generated, and users never need to access each other's core files directly (they are mode 0600 so this isn't possible anyway).

This area will require a moderate amount of coding before it works in the ideal manner. I aim to briefly describe the issues only in this post.

Michael Davies recently blogged that all developers should have big screens. This news has been around for a while, the most publicity for the idea came from Microsoft Research where they did a study showing that for certain tasks a 50% performance increase could be gained from a larger monitor.

If you consider that a good software developer will get paid about $100K and it's widely regarded that in a corporate environment the entire costs for a worker (including management, office space, etc) is double their base salary then you consider each developer to be worth $200K per annum. Therefore larger and more monitors could potentially give a benefit in excess of $100K per annum (we assume that the value provided by the developer is greater than their salary - apart from the dot-com boom that's usually the case).

It's quite obvious that you can get a really great monitor configuration for significantly less than $100K and that it will remain quite current for significantly more than a year (monitor technology advances comparatively slowly so a good monitor should last at least four years).

Some time ago I researched this matter for a client. I convinced all the managers in my area, I convinced a bunch of colleagues to buy bigger monitors for their homes (and bought one myself), but unfortunately senior management saw it as a waste of money. I was trying to convince them that people who were being paid >$100,000 should be each assigned a $400 monitor. Sadly they believed that spending the equivalent of less than a day's wages per employee was not justified.

If I was in a management position I would allocate an amount of money for each developer to spend on hardware or conferences at their own discretion. I would make that amont of money a percentage of the salary of each employee, and I would also allow them to assign some of their share to a colleague if they had a good reason for it (EG if a new hire needed something expensive that would exceed their budget for the first year). I think that people who are good programmers are in the best position to judge what can best be done to improve their own productivity, and that allowing them to make their own choices is good for morale.

On a more technical level I have a problem with getting a big monitor. I do most of my work on a laptop because I travel a lot. I don't travel as much as I did while living in Europe but still do a lot of coding in many strange places. I started writing my Postal benchmark in the hotel restaurant of a Bastion hotel in Utrecht during one of the worst recorded storms in Europe (the restaurant had huge windows and it was inspirational for coding). I wrote the first version of my ZCAV benchmark in Denver airport while waiting for a friend.

What I need is a good way of moving open windows from my laptop to a big external display and then back again. I don't want to logout before moving my machine. With a Macintosh this is quite possible (I'm using a OS/X machine while working for a client and the only thing that has impressed me is the monitor support). With Linux things aren't so easy, it's supposed to be possible but I haven't heard any unqualified success stories yet.

I guess I could try setting up XDMCP between my laptop and a desktop machine with some big displays and logout before moving.

Any suggestions?

Lucas, try bip. It's not nearly as buggy as ctrlproxy, and allows multiple client connections, unlike dircproxy.

Or, if you really want to, be careful that, if /usr/lib/iceape/chrome is a directory (and not a symbolic link), your working directory is /usr/lib/iceape/chrome, or you will end up with the content of your current directory in /usr/share/iceape/chrome, which may be a big issue if you run apt-get from /. If /usr/lib/iceape/chrome is a symbolic link, no worry, just ignore this message. Thank you for your attention, and very sorry :( Update : That’s in such cases that you’d like special crafted tools to rebuild packages without the need to rebuild the whole thing when it comes to just change maintainer scripts (pre/postinst, pre/postrm…). Fortunately, I have pbuilder configured with ccache, but that doesn’t help the buildds with their build job.

Lucas, I personnally open irssi on a screened session on my home server which I reconnect from wherever I may be (usually with my laptop) with screen. Screen rocks, definitely. And I'd be happy to share my .irssi/config file, of course.

I need to reconsider my current way to do IRC.

• My main computer is a laptop, so I can’t leave my IRC client open all the time.
• More and more, I tend to ask stuff on IRC, then I have to leave, so I never get the chance to see the answer. Being able to stay connected all the time would be much easier.
• I’m currently using XChat, and would like to continue using it (ie: I’d prefer to avoid going back to irssi).
• Most of the time, I’m connected to two different networks (OFTC and Freenode).

• I tried to set up an IRC bouncer, but I had the impression that it was complex, and not very user-friendly. (Maybe I’m wrong, or maybe I should have tried a different bouncer (which one?))
• I’ve considered running two clients: XChat for my “main client”, and irssi just for logging everything. But that’s not really optimal.

Which solution are you using? Should I really go back to using irssi? Any good example irssi configs somewhere? Update:

• Comments are now open (they were closed because of a broken WP plugin)
• I used to use screen+irssi, but then, I switched to xchat. I really like xchat, have written some custom scripts for it, and would prefer to continue to use it…
• The possible suggestions I already got are:
  • use xchat with irssi_proxy
  • use xchat with ctrlproxy (looks very nice, but RC buggy and not in etch)
  • use xchat with shroudbnc (or psybnc, or dircproxy)
  Update 2: Ok, due to all the praise of the screen+irssi solution, I’ll give it another try…!

Suppposedly, card number five in the Tarot is the Hierophant, described as “someone who interprets secret knowledge” and representing concepts such as “conformity” and “group identification”. Not that any of that is related to this “five things you don’t know about me” meme, for which I’ve apparently been tagged by both Pia and Tony. And since I wouldn’t want to be accused of being either cool or vanity lacking here’s some from me.

• I used to be a regular bit-part actor in school plays and musicals; I was in the school choir for four years in high school too. I tried getting back into it once during uni, but didn’t really have the time or interest, so I’m just left with going to the occassional show and watching these days. Of course, when they’re as spectacular as Woman in White that’s not much of a problem…
• For quite a while, my favourite food was lamb’s brains, crumbed and fried with a white sauce. I’m quite fond of offal, also known as “variety meats” apparently, in general really – I’m not really persuaded by the “it’s morally wrong to eat animals” thing, but I figure if you’re going to anyway, it makes sense to not be wasteful about it. Kidneys are pretty awesome too; though liver seems to get boring before you’ve finished eating it. I’ve never tried haggis; but I suspect that’ll change before the next DebConf is over…
• Prior to getting an 486sx33 that eventually ran Linux, I used to be an Amiga geek. As an Aussie Amigoid, that meant reading the Australian Commodore and Amiga Review (edited by Andy Farrell), and eventually when I became really elite, subscribing to Megadisc, a monthly magazine on floppy disk, which included useful programs, reviews, letters, and all sorts of interesting things. My first published C progream was included on one of the issues – it was a teensy little app for people with hard disks that would see if you had a Megadisc in the drive, then open up a dialog box so you could choose a directory to copy the disk too, and not have to worry about seek times and such. Unfortunately I was new enough at the whole “C” thing that I wasn’t sure how to make a new directory myself, and decided to just expect the user to use the “New Dir” button in the standard Amiga dialog box for that. Which would have been fine if I hadn’t also gone to the trouble of helpfully emptying the selected directory so the user wouldn’t end up with two Megadiscs in the same place. Put the two together, and evidently you end up with Megadisc’s editor, Tim Strachan, calling you at 9am the morning after publication and telling you how someone had tried it out and it had started deleting all the files on the hard drive. Ooops. With the Amiga dying out and the rise of the internet, it looks like Tim’s now more into alternative health products than computers.
• On the Friday before flying down to Canberra to be Rusty’s wingman for a meeting with the Attorney-General’s department I had my first motorbike accident – not making a turn on a wet road at night just near home, hitting the asphalt and the gutter. I came out of it with some torn jeans and a grazed knee, a banged hand that needed icing, a nice bruise on my side, and a bike that ended up taking aaaages to get fixed and ridable again. Happily it’s gotten another couple of thousand k’s on the odometer since then.
• In the couple of days before I head to Sydney for the 2007 edition of the fantabulous linux.conf.au I’ll be moving from my unit in Toowong to a house in Highgate Hill. Clinton and I will be sharing the upstairs, while the downstairs will be turned into a granny-flat for my parents for when they decide to stay in the city. The theory is it’ll be an investment over the longer term, with the idea being to try building some townhouses in the rather large backyard and sub-dividing. Should be fun!

Let’s see, I’ll tag: vocalist extraordinaire James, companionable carnivore Pat, sometime C hacker David, fellow motorcyclist Sez, and future housemate Clinton.

Hi. I’m currently working on a system image which is (among other things) supposed to automatically mount CDs as they are inserted. The big problem with this is that I finally had to recognize the fact that with all those hotplug events issued, a media change in an existing device is recognized by the kernel (at least it seems so when looking at drivers/ide/ide-cd), but this is not passed to userland, i.e. the hotplug handler (/sbin/hotplug or whatever you wrote to /proc/sys/kernel/hotplug) doesn’t get an event for this. The only way to recognize a media change that I found is to poll the CD-drive(s) for their media status and handle any changes there appropriately. Given that the kernel already seems to have a mechanism to recognize media changes, it would really be cool if it could issue hotplug events for them.

Note: This post grew larger than originally intended. It drifted away from Vista to general rants about Microsoft and the content industry towards the end of the post, so just skip the rest if this is not of interest to you.
The latest thing I heard about Vista is that Microsoft bribes bloggers with Vista notebooks. As the article points out, this is plain wrong. Apart from crossing the line by not only giving away their own product to reviewers for free, but by actually providing an additional benefit (in the form of the notebook), they also did it wrong because - as the article on tech.blorge.com linked above points out - they don’t understand the way blogging “works”. Too many will be more or less angry because they didn’t get a free notebook (if anything at all).

In my opinion though, this is by far the least important mistake they made with Vista. All their content protection stuff is far worse. It basically does what current copy protection mechanisms already do, but to a much larger extend: Bother the legitimate users while users of pirated copies are uneffected. I don’t think they can avoid pirated copies for a minute. A friend already has a nice HD video player (HDDVD IIRC) and a nice HDCP capable TFT-display, both bought in december. Problem is that the HDCP protected connection resets every few minutes, causing a dropout in both video and sound for a few seconds each time. Seems HDCP compatible player and HDCP compatible display doesn’t necessarily mean that the two work together. Fortunately, in this case, there is some “secret” code you can enter on the players remote to disable HDCP completely. Of course, technically, this is not legal use, but if he didn’t use that hack, he wouldn’t be able to watch his legitimately bought video with his legitimate player and display. Given this problem, I can only shudder when thinking what will happen on Windows Vista with all those encrypted and signed communication channels (drive->memory->videocard->display, just to name the most obvious ones). And there is also the degradation of totally unrelated audio and video stuff while some “premium content” is played. Assume that I play some premium audio stuff. According to the hardware and driver specs for Vista, the availability of any premium content means that any non-encrypted channels need to be turned off or artificially degraded (like downsampling video from 1080p to VGA and upsampling it again since the display might be limited to only display 1080p). This is oh-so-stupid.
And there is also their EULA, as reviewed by Ed Foster. I won’t go into details here, but let’s just say that the EULA is the final nail in Vista’s coffin for me. I’ve been a Windows user since Windows for Workgroups came out (though I’ve used Linux on my machines since 1993 - and almost exclusively since 1998), but I won’t buy Vista, not even when it would be included with a new PC. By the way: This also most likely means that I won’t buy any HD video stuff at all, since the Vista content protection stuff was mostly dictated by the big Hollywood studios. Seems like I will be saving quite some money over the next years. (Which I actually need to do anyway.) Other interesting links regarding Vista:

• The Inquirer - Charlie Demerjian: Microsoft Vista is not an option
• The Register - Scott Granneman: Surprises inside Microsoft Vista’s EULA
• Juha Saarinen: DRM behind lack of Windows Vista drivers… and fear the new content protection
• Techworld.com - Chris Mellor: Vista crippled by content protection
• The Register - Andrew Orlowski: Vista’s Suicide Bomb: Who gets hurt?

I said they did it all wrong because they forgot that they are selling Windows not to the content industry but to the consumers. Sure, the consumers want to see what Microsoft calls premium content, but I’m also sure that they don’t want all that content protection nonsense Microsoft built into Vista for the sake of the content providers. They lost the balance between avoiding pirated copies (which I think the content protection stuff will have no big effect on) and bothering users of legitimate copies. Heck, I already use “pirate” copies of most of the (Windows-based) games I play because I don’t want to be bothered by their original-CD-checks, even though I own at least one legal copy of all the games I play. Would I need to download pirate copies of the HD movies I want to watch because I don’t want to be bothered by whatever side-effects VCP will have, even if I own legal copies of the same movies? Dear Microsoft, dear Content-Industry (TimeWarner, Disney, whoever), please re-think who you want to sell your content to. I already avoid DVDs which carry additional copy protection (apart from CSS), and if they were available at all, I would prefer to buy DVDs without even CSS. The same is true for CDs (except that they obviously don’t have CSS). Consequently, I’m likely to avoid buying HD videos which impose unpleasant restrictions on me, including those that disable the S/PDIF output of my player (no matter wether PC or standalone) since I paid a lot of money for decent HIFI equipment two years ago and I sure as hell won’t want to by new equipment within the next few years. Luckily, I didn’t yet buy any HD video gear, though my notebook, when equipped with a HDDVD or Blueray drive should be capable of playing HD video - if MS and the content industry wouldn’t impose stupid restrictions.

disk = [ 'phy:/dev/vg/xen1,hda,w', 'phy:/dev/vg/xen1-swap,hdb,w', 'phy:/dev/vg/xen1-drbd,hdc,w', 'phy:/dev/vg/san,hdd,w!' ]

For some work that I am doing I am trying to simulate a cluster that uses fiber channel SAN storage (among other things). The above is the disk line I'm using for one of my cluster nodes, hda and hdb are the root and swap disks for a cluster node, hdc is a DRBD store (DRBD allows a RAID-1 to be run across the cluster nodes via TCP), and hdd is a SAN volume. The important thing to note is the "w!" mode for the device, this means write access is granted even in situations whre Xen thinks it's unwise (IE it's being used by another Xen node or is mounted on the dom0). I've briefly tested this by making a filesystem on /dev/hdd on one node, copying data to it, then umounting it and mounting it on another node to read the data.

There are some filesystems that support having multiple nodes mounting the same device at the same time, these include CXFS, GFS, and probably some others. It would be possible to run one of those filesystems across nodes of a Xen cluster. However that isn't my aim at this time. I merely want to have one active node mount the filesystem while the others are on standby.

One thing that needs to be solved for Xen clusters is fencing. When a node of a cluster is misbehaving it needs to be denied access to the hardware in case it recovers some hours later and starts writing to a device that is now being used by another node. AFAIK the only way of doing this is via the xm destroy command. Probably the only way of doing this is to have a cluster node ssh to the dom0 and then run a setuid program that calls xm destroy.

Sven Mueller commented:

"There is a better solution for building packages if you don't have a local unstable machine up. Use pbuilder (w/ or w/o the pdebuild "frontend"). I had refrained from setting up pbuilder for quite a while, and was amazed how easy it was when I eventually did. The only "problem" is that you probably want to make sure that at least "debian/rules clean" works even under Debian/stable. But I personally like to keep my packages buildable under stable anyway (since I usually use backports of them on production systems)."

I tried pbuilder at first and it failed because of the aforementioned debootstrap stable/unstable difference. After I read up on debootstrap, I didn't really see what pbuilder added to the system besides more tarball processing, so I didn't bother trying it again after debootstrap worked. Am I missing out on anything important? Mark Brown commented:

"pbuilder provides management of the chroot environments (you can have several set up and it'll let you choose between and update them) and a convenient front end for building packages in a chroot (you can just point it at a package and say "go build this in a chroot")."

I'm probably being dense, but I still don't see a benefit. A chroot is more-or-less just a tree on the disk so I can have several set up anyway, updating them is just running update inside the chroot and I just mv the package into the chroot and say "go in that chroot and build this". Maybe pbuilder just isn't beneficial for me.

Another problematic meme is the idea that no-one need tolerate anyone - even those who are tolerant (known as the Rabid Right meme). When someone has no tolerance for others (for example, flaming people who expect any attempt at fairness, or who follow different social interaction patterns) then they have no place in a community such as Debian. They should clear off to some hard-hierarchy project - it's not like there's any shortage of Rabid Right hackers in this world. </sarcasm> For what it's worth, I believe life should be fair (idealism) and life is not fair (pragmatism). It is possible for those two beliefs to coexist. Expulsion could be fair, but (IIRC) every expulsion proposed so far would have been unfair and based on personal issues, rather than repeated offences: we may be reaching the point where a fair expulsion could happen. It seems a shame none of those who hold them are willing to use the smaller penalties in a Non-Discriminatory way. The "can't take their job away" meme seems more myth than meme, but it does need sorting out in the few places where it occurs. I doubt it will happen under this DPL.

Russel Coker writes about using multiple Ethernet devices in Xen and wonders about if there is something similar to RFC1918 addresses, but for Ethernet. Apparently, there is, they're called "Locally Administered Addresses". To make a local address, just set the seventh bit to one. You probably want to make the eigth bit a zero too, unless it's a multicast address. Wikipedia has more, as usual.

For the fifth time in a row, I started yet another year with 5k race by participating in the 22th New Year's Day 5k at the lakefront. The race had decent conditions. Chicago is currently having unusually mild weather, which is an extra bonus. It was well over 50 degrees yesterday, but a little cooler around fourty this morning, and unfortunately overcast. And luckily fairly little wind as it can be unplesant at the lake. Following some mild training runs both Saturday and Sunday, I took it relatively easy and finished around 20:15 or 20:20 -- I forgot to stop the Garmin at the finish, and the official results are not yet published. Not a bad time given that I haven't really trained since the last marathon.

Or, more specifically, bands I started listening to in 2006:

• Architecture in Helsinki
• Beulah
• Camera Obscura
• Casiotone for the Painfully Alone
• Christine Fellows
• Go Sailor
• Grandaddy
• Jap Jap
• Mirah
• Neutral Milk Hotel
• Reindeer Section
• Schwervon!
• The Mountain Goats
• The Pipettes
• The Polyphonic Spree
• Trachtenburg Family Slideshow Players
• Track Star
• Tullycraft

I have just been installing a Xen domU on Debian Etch. I'll blog about installing dom0 later when I have a test system that I can re-install on (my production Xen machines have the dom0 set up already). The following documents a basic Xen domU (virtual machine) installation that has an IP address in the 10.0.0.0/8 private network address space and masquerades outbound network data. It is as general as possible.

lvcreate -n xen1 -L 2G /dev/vg

Firstly use the above command to create a block device for the domU, this can be a regular file but a LVM block device gives better performance. The above command is for a LV named xen1 on an LVM Volume Group named vg.

mke2fs -j /dev/vg/xen1

Then create the filesystem with the above command.

mount /dev/vg/xen1 /mnt/tmp
mount -o loop /tmp/debian-testing-i386-netinst.iso /mnt/cd
cd /mnt/tmp
debootstrap etch . file:///mnt/cd/
chroot . bin/bash
vi /etc/apt/sources.list /etc/hosts /etc/hostname
apt-get update
apt-get install libc6-xen linux-image-xen-686 openssh-server
apt-get dist-upgrade

Then perform the basic Debian install with the above commands. Make sure that you change to the correct directory before running the debootstrap command. The /etc/hosts and /etc/hostname files need to be edited to have the correct contents for the Xen image (the default is an empty /etc/hosts and /etc/hostname has the name of the parent machine). The file /etc/apt/sources.list needs to have the appropriate configuration for the version of Debian you use and for your preferred mirror. libc6-xen is needed to stop a large number of kernel warning messages on boot. It's a little bit of work before you get the virtual machine working on the network so it's best to do these commands (and other package installs) before the following steps. After the above type exit to leave the chroot and run umount /mnt/tmp.

lvcreate -n xen1-swap -L 128M /dev/vg
mkswap /dev/vg/xen1-swap

Create a swap device with the above commands.

auto xenbr0
iface xenbr0 inet static
pre-up brctl addbr xenbr0
post-down brctl delbr xenbr0
post-up iptables -t nat -F
post-up iptables -t nat -A POSTROUTING -o eth0 -s 10.1.0.0/24 -j MASQUERADE
address 10.1.0.1
netmask 255.255.255.0
bridge_fd 0
bridge_hello 0
bridge_stp off

Add the above to /etc/network/interfaces and use the command ifup xenbr0 to enable it. Note that this masquerades all outbound data from the machine that has a source address in the 10.1.0.0/24 range.

net.ipv4.conf.default.forwarding=1

Put the above in /etc/sysctl.conf, run sysctl -p and echo 1 > /proc/sys/net/ipv4/conf/all/forwarding to enable it.

cp /boot/initrd.img-2.6.18-3-xen-686 /boot/xen-initrd-18-3.gz

Set up an initial initrd (actually initramfs) for the domU with a command such as the above. Once the Xen domU is working you can create the initrd from within it which gives a smaller image.

kernel = "/boot/vmlinuz-2.6.18-3-xen-686"
ramdisk = "/boot/xen-initrd-18-3.gz"
memory = 64
name = "xen1"
vif = [ '' ]
disk = [ 'phy:/dev/vg/xen1,hda,w', 'phy:/dev/vg/xen1-swap,hdb,w' ]
root = "/dev/hda ro"
extra = "2 selinux=1 enforcing=0"

The above is a sample Xen config file that can go in /etc/xen/xen1. Note that this will discover an appropriate bridge device by default, if you only plan to have one bridge then it's quite safe, if you want multiple bridges then things will be a little more complex. Also note that there are two block devices created as /dev/hda and /dev/hdb, obviously if we wanted to have a dozen block devices then we would want to make them separate partitions with a virtual partition table. But in most cases a domU will be a simple install and won't need more than two block devices.

xm create -c xen1

Now start the Xen domU with the above command. The -c option means to take the Xen console (use ^] to detach). After that you can login as root at the Xen console with no password, now is a good time to set the password.

Run the command apt-get install udev, this could not be done in the chroot before as it might mess up the dom0 environment. Edit /etc/inittab and disable gettys on tty2 to tty6, I don't know if it's possible to use them (the default and only option for xen console commands is tty1) and in any case you would not want 6, saving a few getty processes will save some memory.

Now you should have a basically functional Xen domU. Of course a pre-requisite for this is having a machine with a working dom0 installation. But the dom0 part is easier (and I will document it in a future blog post).