It may come as no surprise to some of you that I actually enjoy -- yes, enjoy -- watching political conventions. I've spent some time watching them over the past two weeks.

McCain has yet to speak tonight as I write this, but I've got to get out a few comments.

First of all, both parties of course were attacking the presidential candidate of the other. But did you notice a key difference? The Democrats attacked McCain on policy, while the McCain people attacked Obama on biography. VP nominee Palin even went so far as to mock Obama's work 20 years ago as a community organizer. I think that is incredibly telling. It seems to me to indicate that the Republicans know that their policies aren't working, and are grasping at straws to find something else. There is plenty in McCain's biography that the Democrats could go after -- his involvement in one of the worst scandals in the Senate, for instance -- but they aren't.

What about the other difference? Hope vs. fear. Obama's speech last week was truly inspiring. I don't think I've ever been inspired by a politician before. Make no mistake about it, he set the bar for himself incredibly high. I don't think anybody since Kennedy has done that. Obama realizes that there are things we must do as a country, and he also emphasized that the "ask not what your country can do for you" theme. Watching Giulianni and Palin was an exercise in fear-mongering. It's a constant stream of "9/11 MUSLIM OIL SHORTAGE TERRORISM NUCLEAR BIN LADEN IRAN GAS PRICES RED ALERT PANIC PANIC PANIC MEXICANS 9/11 9/11 9/11 SCARY WAR WAR WAR." It's as if they have discovered M-x spook RET in Emacs.

The Democrats, on the other hand, are talking about reducing health care costs, making sure everyone is covered, ending war, making the economy better for working-class people. It's an interesting disconnect that Obama highlighted well: McCain has said that the American economy has done well over the past 8 years. And indeed, by some "traditional" measures, such as productivity or GDP, it has. But the vast majority of Americans are not better off today than they were 8 years ago. Obama argues that the way McCain measures economic success is way off; our economy is not doing well if the vast majority of regular Americans are not doing well.

Also telling was how both candidates promised to reach across party lines (Bush promised that too). One actually is working to do it. Take abortion, for example. Obama said that he doesn't agree with the pro-lifers, but surely everyone can agree that providing better funding and support for alternatives to abortion such that it becomes incredibly rare is a good thing. Where's McCain looking for common ground? And then, of course, we have Palin wanting her family to be off limits -- but only when it's convenient to her.

I've voted in the past, but usually as a vote against someone rather than a vote for someone. This year, I'll make a single vote and do both.

I'm back to working at home after completing a recent contract, much faster than the client expected, I'm proud to say, as I was able to leverage some open source software to do exactly what they needed. While I love being able to see Helen and Ilenia more during the day, it also brings up that old question of Adam Smith's: the division of labor. It's pretty difficult to concentrate at all with a baby in the house, despite having an office with a door. When she's noisy, she's really noisy, and there's nothing like the yowl of an unhappy baby to get a parent's attention, even if he's not the one currently taking care of her. Also, perhaps most importantly: she's adorable and full of smiles for me, and loves to play... as do I, certainly more so than working! Since she won't take a bottle yet (well, I did succeed once, but it's not easily repeatable), my wife is still the one Helen's primarily attached to, but even so, needs some time when I take care of the baby so she can do her stuff too. I'm curious what sorts of arrangements other people have worked out? Fortunately, one option would simply be to spend the time with Ilenia and Helen and forget about work for the most part, but that's pretty extreme. It's not as if I don't have computer time, but the biggest problem is the constant interruptions, which make it difficult to do more than read and write a little bit. Serious coding requiring concentration is pretty much only for late at night or early mornings these days.

I have been playing too many puzzle games lately. This trivia question just popped into my head:

What command will never appear in a .bash_history file?

Unfortunately, I seem to have disproven the answer I originally had. I wonder if there are others? My original answer was going to be “unset HISTFILE”, but I can make it show up in my .bash_history file:

unset HISTFILE
export HISTFILE=/home/kees/.bash_history

In today s episode of Tatort, a German-language TV series Martin blogged about some time ago, I had to laugh at this line:

You are a computer scientist, aren t you? What we ve got here is an equation with two variables. You certainly know that this easy to solve.

Interestingly, the same mistake can be found in an older episode of another German TV series called Der Bulle von T lz. A part of a dialogue between a detective and a teacher went like this:

Detective: Was she a good student?
Teacher: Not at all. She even cannot solve a simple equation with two variables.

Dear screenwriters, when in doubt, please stay away from maths. And while we re at it, there is no need for fingerprint matching software to show every fingerprint from the database on the screen and emit lots of short beeps while doing that. Your programmes are more enjoyable without this stuff. Update: As this post has triggered responses: First, I do not deny the overall quality of Tatort it is a great series. Second, of course there are systems of equations with more variables than equations which can be solved. But these aren t straightforward and certainly not what the people I m talking about had in mind

I just read an interesting post about latency and how it affects web sites [1]. The post has some good ideas but unfortunately mixed information on some esoteric technologies such as infiniband that are not generally applicable with material that is of wide use (such as ping times). The post starts by describing the latency requirements of Amazon and stock broking companies. It’s obvious that stock brokers have a great desire to reduce latency, it’s also not surprising that Google and Amazon analyse the statistics of their operations and make changes to increase their results by a few percent. But it seems to be a widely held belief that personal web sites are exempt from such requirements. The purpose of creating content on a web site is to have people read it, if you can get an increase in traffic of a few percent by having a faster site and if those readers refer others then it seems likely to have the potential to significantly improve the result. Note that an increase in readership through a better experience is likely to be exponential, and an exponential increase of a few percent a year will eventually add up (an increase of 4% a year will double the traffic in 18 years). I have been considering hosting my blog somewhere else for a while. My blog is currently doing about 3G of traffic a month which averages out to just over 1KB/s, peaks will of course be a lot greater than that and the 512Kb/s of the Internet connection would probably be a limit even if it wasn’t for the other sites onn the same link. The link in question is being used for serving about 8G of web data per month and there is some mail server use which also takes bandwidth. So performance is often unpleasantly slow. For a small site such as mine the most relevant issues seem to be based around available bandwidth, swap space use (or the lack therof), disk IO (for when things don’t fit in cache) and available CPU power exceeding the requirements. For hosting in Australia (as I do right now) bandwidth is a problem. Internet connectivity is not cheap in any way and bandwidth is always limited. Also the latency of connections from Australia to other parts of the world often is not as good as desired (especially if using cheap hosting as I currently do). According to Webalizer only 3.14% of the people who access my blog are from Australia, they will get better access to my site if hosted in Australia, and maybe the 0.15% of people who access my blog from New Zealand will also benefit from the locality of sites hosted in Australia. But the 37% of readers who are described as “US Commercial” (presumably .com) and the 6% described as “United States” (presumably .us) will benefit from US hosting, as will most of the 30% who are described as “Network” (.net I guess). For getting good network bandwidth it seems that the best option is to choose what seems to be the best ISP in the US that I can afford, where determining what is “best” is largely based on rumour. One of the comments on my post about virtual servers and swap space [2] suggested just not using swap and referenced the Amazon EC2 (Elastic Computing) cloud service and the Gandi.net hosting (which is in limited beta and not generally available). The Amazon EC2 clound service [3] has a minimum offering of 1.7G of RAM, 1EC2 Compute Unit (equivalent to a 1.0-1.2GHz 2007 Opteron or 2007 Xeon processor), 160G of “instance storage” (local disk for an instance) running 32bit software. Currently my server is using 12% of a Celeron 2.4GHz CPU on average (which includes a mail server with lots of anti-spam measures, Venus, and other things). Running just the web sites on 1EC2 Compute Unit should use significantly less than 25% of a 1.0GHz Opteron. I’m currently using 400M of RAM for my DomU (although the MySQL server is in a different DomU). 1.7G of RAM for my web sites is heaps even when including a MySQL server. Currently a MySQL dump of my blog is just under 10M of data, with 1.7G of RAM the database should stay entirely in RAM which will avoid the disk IO issues. I could probably use about 1/3 of that much RAM and still not swap. The cost of EC2 is $US0.10 per hour of uptime (for a small server), so that’s $US74.40 per month. The cost for data transfer is 17 cents a GIG for sending and 10 cents a gig for receiving (bulk discounts are available for multiple terabytes per month). I am not going to pay $74 per month to host my blog. But sharing that cost with other people might be a viable option. An EC2 instance provides up to 5 “Elastic IP addresses” (public addresses that can be mapped to instances) which are free when they are being used (there is a cost of one cent per hour for unused addresses - not a problem for me as I want 24*7 uptime). So it should be relatively easy to divide the costs of an EC2 instance among five people by accounting for data transfer per IP address. Hosting five web sites that use the same software (MySQL and Apache for example) should reduce memory use and allow more effective caching. A small server on EC2 costs about five times more than one of the cheap DomU systems that I have previously investigated [4] but provides ten times the RAM. While the RAM is impressive, I have to wonder about CPU scheduling and disk IO performance. I guess I can avoid disk IO on the critical paths by relying on caching and not doing synchronous writes to log files. That just leaves CPU scheduling as a potential area where it could fall down. Here is an interesting post describing how to use EC2 [5]. Another thing to consider is changing blog software. I currently use Wordpress which is more CPU intensive than some other options (due to being written in PHP), is slightly memory hungry (PHP and MySQL), and doesn’t have the best security history. It seems that an ideal blog design would use a language such as Java or PHP for comments and use static pages for the main article (with the comments in a frame or loaded by JavaScript). Then the main article would load quickly and comments (which probably aren’t read by most users) would get loaded later.

• [1] http://highscalability.com/latency-everywhere-and-it-costs-you-sales-how-crush-it


• [2] http://etbe.coker.com.au/2008/08/27/killing-servers-virtualisation-and-swap/


• [3] http://www.amazon.com/b/?node=201590011


• [4] http://etbe.coker.com.au/2008/05/28/xen-hosting/


• [5] http://www.protocolostomy.com/2008/08/27/more-adventures-in-amazon-ec2-and-ebs/

Share This

Tired and under the influence of beer, I tried to remove the currently broken IPv6 default route from my primary mailserver via an SSH connection and accidentally executed instead:

ip r d default
# I meant: ip -6 r d default

Unfortunately, I didn t immediately realise what I had done, and then it was too late. Robert Collins told me that I could have saved the session because even without a default route, packets still reach the machine. Unfortunately, due to Nagle s algorithm, you pretty much only have one shot, so the next time this happens to me (or you), quickly type

ip r a default via <gateway>

into a separate window, then copy and paste it into the SSH session and you may get lucky. Update: one lesson I learnt from this is to add specific routes for at least the IPv6 tunnel peer, and possibly another machine (or two) under my control out there. I now have that in place on all machines I own. NP: The Phoenix Foundation: Pegasus

As I start this blog post, I'm on the train between Amersfoort and Osnabr ck, on my way to Kiel, where there'll be a meeting of the m68k porters, kindly organized by m68k kernel maintainer Christian Steigies. I took the 8:40 train in Mechelen this morning, and if all goes well, I'll be arriving in Kiel at 17:22 tonight. Some train trip... but I certainly prefer that to any flight. Anyway. The days of Debconf were very nice. Debconf is a lot of things to me. Travel. Hacking. Mao, evolving into a drinking game. Beer. Attending talks. Giving talks. Meeting people. Face-to-face non-flaming. Gesturing for an extra knife at luunch. Hangover. Whiskey. Talking to the person next to you—over IRC. Getting killed before knowing what the rules of the assassins game are. Filing bugreports in person. Pictures. Kilts. Streaming video. Not being sick, hopefully. Name badges. Flying. Sleeping. Yes, sleeping. Most of all, though, this year, Debconf was just great. Thanks. You know who you are. After debconf, I flew to Buenos Aires, where I slept for one night in a Youth Hostel somewhere downtown. They were affordable, but the bed wasn't great—the mattress sorely needed replacement. Since I had a day in BA, and since there were apparently not enough people on the schedule, I'd agreed to hold a talk, and came up with the idea of a 'debian secrets' talk—about Debian-specific commands, such as dpkg-divert and update-alternatives etc—so that people could learn how to use their Debian system more efficiently. As I was sitting in Andreas' talk, who was right before me on the schedule, suddenly Dag walked up to me and said hi. This was unexpected; Dag is a fellow Belgian, who's involved with the CentOS project, and who maintains a positively huge RPM repository at his site—if you maintain an RPM-based system somewhere, you'll probably know about that site. So while I recognized him, I immediately wondered what he was doing there. Turned out he was invited to hold a talk at the Free Software event to which Debianday was attached (and which would not start for another day or two), and that when he saw my name on the schedule, he decided to attend. Fun. He learned a thing or two from my talk, and was talking later about writing some tools for RPM-based systems that would perform the same or similar functionality implemented by some of the Debian tools I talked about. Great. We had a picture together (in front of the DebConf banner—hah) that I still should upload, and then went out for lunch together with some other CentOS guys. The talk itself seems to have been well-received, and I'm glad about that; I only gave it because there was a need for more talks, not because I felt confident I was very knowledgeable about that subject. In fact, I did have to ask on the debconf-discuss mailinglist for some input (which I received) so that I could make sure the talk would actually be useful to people. That helped a lot, I guess. After that, we played some mao in the lobby of the DebianDay venue. While doing so, I overheard Dag talking about CentOS, advocating it to some of the people there, which I must say felt pretty weird on a Debian event. Not that there's anything wrong with it, of course. Except that Dag was supposed to be writing his talk slides. How did that work out, Dag? ;-) Eventually, I got in a cab to the EZE airport, and flew home. That wasn't fully without issue, but I did get there. And now, I've been, eh, overloaded. Still have to follow up on a question a customer asked me, but I've barely been home or at the office, just enough to sleep really. Should do something about that, I guess... Two days ago, I also managed to forget my camera somewhere. For 12 hours, I was worried, even though I had a pretty good idea of where it was; but since I'm getting quite good at taking pictures now, and since I really like doing so as well, I really didn't want to lose my camera. Fortunately, when I called this morning to the place where I thought I'd lost it, they told me it'd been found, and where to get it. In other words, it's safe, it's taken care of, Philip went to get it, and I just need to arrange to get it when I get back. Which is a relief. Let's not be so stupid anymore in the future... Finishing up now, a day later, and I'm at Christian's office, playing with his and my coldfire board. As it happens, it appears that Freescale has brought out a new BSP for these boards, so that's nice. Let's see whether we can get those to boot again...

In the mid 90’s I was part-owner of a small ISP. We had given out Trumpet Winsock [1] to a large number of customers and couldn’t convert them to anything else. Unfortunately a new release of the Linux kernel (from memory I think it was 2.0) happened to not work with Trumpet Winsock. Not wanting to stick to the old kernel I decided to install a Linux machine running a 1.2.x kernel for the sole purpose of proxying connections for the Winsock users. I had a 386 machine with 8M of RAM that was suitable for the purpose. At that time hard disks were moderately expensive, and the servers were stored in a hot place which tended to make drives die more rapidly than they might otherwise. So I didn’t want to use a hard disk for that purpose. I configured the machine to boot from a floppy disk (CD-ROM drives also weren’t cheap then) and use an NFS root filesystem. The problem was that it needed slightly more than 8M of RAM and swapping to NFS was not supported. My solution was to mount the floppy disk read-write and use a swap file on the floppy. The performance difference between floppy disks and hard disks was probably about a factor of 10 or 20 - but they were both glacially slow when compared to main memory. After running for about half an hour the machine achieved a state where about 400K of unused data was paged out and the floppy drive would then hardly ever be used. I had initially expected that the floppy disk would get a lot of use and wear out, I had prepared a few spare disks so that they could be swapped in case of read errors. But in about a year of service I don’t recall having a bad sector on a floppy (I replaced the floppy whenever I upgraded the kernel or rebooted for any other reason as a routine precaution). Does anyone have an anecdote to beat that?

• [1] http://en.wikipedia.org/wiki/Trumpet_Winsock

Share This

The Debian Live team is pleased to announce the first beta of Debian Lenny's Live images. Although we missed releasing images for Etch along with the installer images, we are now prepared to release live images within the regular Lenny release process. This is the first official release of Debian Live and the whole team has been working hard during the past 2.5 years to make Debian's own live systems become a reality. Nevertheless, we do need your help to find more bugs and improve the live systems, so please try them out. The images are available at:

	http://cdimage.debian.org/cdimage/lenny_live_beta1/

Please also have a look at the known issues listed below. Main features 100% Debian The build process of Debian Live basically consists of creating a Debian chroot, installing one or more kernels along with live-initramfs (a set of hooks into initramfs-tools for handling booting from read-only media) and generating a bootable image from that. This process is handled by live-helper, a collection of shell scripts that allow us to automate and customize this process. Considerable care is taken to ensure that the resulting live system is not tainted by the host system and that installed packages are not modified morethan absolutely necessary. This ensures that Debian Live really is Debian, and not "just another" a Debian-based live system. Flavours Although live-helper is a toolkit to produce your very own live systems with only a few steps, we also provide prebuilt images that are meant to be used as reference systems for end-users. Currently, this consists of the three major desktop environments (GNOME, KDE and Xfce), as well as a small 'standard' image without a graphical environment. For the desktop environments, package selection is performed by 'tasksel' with the respective desktop task, whilst the 'standard' image contains only packages of "Priority: standard" or greater, notwithstanding a handful of live-specific packages (console-common, eject, file, kbd, live-initramfs, locales, sudo and vim-tiny). Image types Debian Live offers prebuilt images for CD/DVD discs, USB sticks (or any HD-media-like device), tarballs (for PXE netboot) as well as a bare squashfs image to boot from the web directly. Live Magic Live Magic is an GUI frontend around the live-helper scripts, offering a subset of the features of live-helper in an easy-to-use graphical user interface. live-magic 1.0 was recently uploaded to sid and is the recommended version. It currently supports 7 languages. Live Installer Live Installer is a special udeb for the Debian Installer that (optionally) replaces a part of d-i in order to install the system from the live image instead of to bootstrapping it from .deb packages. This way, a live system can be easily installed to the harddisk, ensuring that the look and feel of the installation (including preseeding) works the same as the regular installer process. Unfortunately, live-installer does still have a few minor bugs left and is thus not included in our builds yet; we hope to be able to include it in the next beta. Known issues in this release

• The prebuilt images for gnome-desktop and kde-desktop are a bit too big to fit on a CD. Although the automatic installation of Recommends was disabled to build the images, they are still too big. This will need further tweaking as they are supposed to fit with the next beta.
  
  
• The rescue flavour, containing system rescue and forensic related packages, is missing in this beta release.
  
  
• There will be a DVD image with the next beta that includes all three desktop environments so that you can choose at boot time which system you would like to start.
  
  
• Due to time constraints, the prebuilt images for Beta1 are only covering i386 and amd64; with the next beta, powerpc and sparc will follow (if you wish to test these architectures earlier, please build them yourself).
  
  
• The new desktop artwork is not yet included.
  
  
• The syslinux menu is still the old, prompt-based one. A freshly made new syslinux vgamenu using the official lenny desktop artwork is on the way (the same as d-i media will use in Lenny).
  
  
• No live-installer included yet (if you wish to test live-installer earlier, please build it yourself).
  
  
• No win32-loader included yet.
  
  
• Sid packages used - At the time of building the live images, both live-helper 1.0.0-1 and live-initramfs 1.139.1-1 from sid were used. Since the latter has not yet migrated to testing, it was included manually as a local package. This is undesirable, as the release is supposed to be self-contained - however, it is just a convenient workaround as both were granted freeze exception and will migrate soon.

Plans for next Beta release We are looking forward to upload Beta2 in about two weeks from now (maybefollowed by a third beta) with one final RC after that which should be identical to the final release. Some more details about the open things we would like to address in Beta2 and later can be found at the wiki page. The Debian Live team is still looking for more contributors for new features (post-lenny, though) as well as documentation writers for the manual (always). If you care about live systems, please join and help! Thanks Last but not least, our thanks goes to everyone who has contributed and to all maintainers that have kindly fixed live-specific bugs in their packages.

The Problem: A problem with virtual machines is the fact that one rogue DomU can destroy the performance of all the others by inappropriate resource use. CPU scheduling is designed to allow reasonable sharing of computational resources, it is unfortunately not well documented, the XenSource wiki currently doesn’t document the “credit” scheduler which is used in Debian/Etch and CentOS 5 [1]. One interesting fact is that CPU scheduling in Xen can have a significant effect on IO performance as demonstrated in the paper by Ludmila Cherkasova, Diwaker Gupta and Amin Vahdat [2]. But they only showed a factor of two performance difference (which while bad is not THAT bad). A more significant problem is managing virtual memory, when there is excessive paging performance can drop by a factor of 100 and even the most basic tasks become impossible. The design of Xen is that every DomU is allocated some physical RAM and has it’s own swap space. I have previously written about my experiments to optimise swap usage on Xen systems by using a tmpfs in the Dom0 [3]. The aim was to have every Xen DomU swap data out to a tmpfs so that if one DomU was paging heavily and the other DomUs were not paging then the paging might take place in the Dom0’s RAM and not hit disk. The experiments were not particularly successful but I would be interested in seeing further research in this area as there might be some potential to do some good. I have previously written about the issues related to swap space sizing on Linux [4]. My conclusion is that following the “twice RAM” myth will lead to systems becoming unusable due to excessive swapping in situations where they might otherwise be usable if the kernel killed some processes instead (naturally there are exceptions to my general rule due to different application memory use patterns - but I think that my general rule is a lot better than the “twice RAM” one). One thing that I didn’t consider at the time is the implications of this problem for Xen servers. If you have 10 physical machines and one starts paging excessively then you have one machine to reboot. If you have 10 Xen DomUs on a single host and one starts paging heavily then you end up with one machine that is unusable due to thrashing and nine machines that deliver very poor disk read performance - which might make them unusable too. Read performance can particularly suffer in a situation when one process or VM is writing heavily to disk due to the way that the disk queuing works, it’s not uncommon for an application to read dozens or hundreds of blocks from disk to satisfy a single trivial request from a user, if each of these block read requests has to wait for a large amount of data to be written out from the write-back cache then performance will suck badly (I have seen this in experiments on single disks and on Linux software RAID - but have not had the opportunity to do good tests on a hardware RAID array). Currently for Xen DomUs I am allocating swap spaces no larger than 512M, as anything larger than that is likely to cause excessive performance loss to the rest of the server if it is actually used. A Solution for Similar Problems: A well known optimisation technique of desktop systems is to use a separate disk for swap, in desktop machines people often use the old disk as swap after buying a new larger disk for main storage. The benefit of this is that swap use will not interfere with other disk use, for example the disk reads needed to run the “ps” and “kill” programs won’t be blocked by the memory hog that you want to kill. I believe that similar techniques can be applied to Xen servers and give even greater benefits. When a desktop machine starts paging excessively the user will eventually take a coffee break and let the machine recover, but when an Internet server such as a web server starts paging excessively the requests keep coming in and the number of active processes increases so it seems likely that using a different device for the swap will allow some processes to satisfy requests by reading data from disk while some other processes are waiting to be paged in. Applying it to Xen Servers: The first thing that needs to be considered for such a design is the importance of reliable swap. When it comes to low-end servers there is ongoing discussion about the relative merits of RAID-0 and RAID-1 for swap. The benefit of RAID-0 is performance (at least in perception - I can imagine some OS swapping algorithms that could potentially give better performance on RAID-1 and I am not aware of any research in this area). The benefit of RAID-1 is reliability. Now there are two issues in regard to reliability, one is continuity of service (EG being able to hot-swap a failed disk while the server is running), and the other is the absence of data loss. For some systems it may be acceptable to have a process SEGV (which I presume is the result if a page-in request fails) due to a dead disk (reserving the data loss protection of RAID for files). One issue related to this is the ability to regain control of a server after a problem. For example if the host OS of a machine had non-RAID swap then a disk failure could prevent a page-in of data related to sshd or some similar process and thus make it impossible to recover the machine without hardware access. But if the swap for a virtual machine was on a non-RAID disk and the host had RAID for it’s swap then the sysadmin could login to the host and reboot the DomU after creating a new swap space on a working disk. Now if you have a server with 8 or 12 disks (both of which seem to be reasonably common capacities of modern 2RU servers) and if you decide that RAID is not required for the swap space of DomUs then it would be possible to assign single disks for swap spaces for groups of virtual machines. So if one client had several virtual machines they could have them share the same single disk for the swap, so a thrashing server would only affect the performance of other VMs from the same client. One possible configuration would be a 12 disk server that has a four disk RAID-5 array for main storage and 8 single disks for swap. 8 CPU cores is common for a modern 2RU server, so it would be possible to lock 8 groups of DomUs so that they share CPUs and swap spaces. Another possibility would be to have four groups of DomUs where each group had a RAID-1 array for swap and two CPU cores. I am not sure of the aggregate performance impact of such a configuration, I suspect that a group of single disks would give better performance for swap than a single RAID array and that RAID-1 would outperform RAID-5. For a single DomU it seems most likely that using part of a large RAID array for swap space would give better performance. But the benefit in partitioning the server seems clear. An architecture where each DomU had it’s own dedicated disk for a swap space is something that I would consider a significant benefit if renting a Xen DomU. I would rather have the risk of down-time (which should be short with hot-swap disks and hardware monitoring) in the rare case of a disk failure than have bad performance regularly in the common situation of someone else’s DomU being overloaded. Failing that, having a separate RAID array for swap would be a significant benefit. If every process that isn’t being paged out could deliver full performance while one DomU was thrashing then it would be a significant benefit over the situation where any DomU can thrash and kill the file access performance of all other DomUs. A single RAID-1 array should handle all the swap space requirements for a small or medium size Xen server One thing that I have not tested is the operation of LVM when one disk goes bad. In the case of a disk with bad sectors it’s possible to move the LVs that are not affected to other disks and to remove the LV that was affected and re-create it after removing the bad disk. The case of a disk that is totally dead (IE the PV header can’t be read or written) might cause some additional complications.

• [1] http://wiki.xensource.com/xenwiki/Scheduling


• [2] http://www.cs.ucsd.edu/~dgupta/papers/per07-3sched-xen.pdf


• [3] http://etbe.coker.com.au/2008/05/22/xen-and-swap/


• [4] http://etbe.coker.com.au/2007/09/28/swap-space/

Share This

scons claims to be a better replacement for make, or rather especially autofoo magic. Unfortunately, it isn't. To me a proper build system should definitely be able to clean up behind itself. The reasoning flying around for why scons isn't able to do so are quite hilarious, ranging from that it doesn't know what it generates (how does it generate them in the first place?) to that it's extensible and thus can't be done properly (then the extensions are broken and should add their clean informations in a hook or such, too). I haven't seen any valid reason for why it shouldn't be able to do so—yet we still seem to need to clean up cruft lying aroud like .scons* files and directories, config.log and of course the build/ directory. People, if you really want to do some proper build system, don't forget to make it clean up after itself. It shouldn't be the requirement of application developers to fix that (which doesn't really work because a scons target trying to clean the files makes scons crash).

I’ve just read an amusing series of blog posts about bad wiring [1]. I’ve seen my share of wiring horror in the past. There are some easy ways of minimising wiring problems which seem to never get implemented. The first thing to do is to have switches near computers. Having 48 port switches in a server room and wires going across the building causes mess and is difficult to manage. A desktop machine doesn’t need a dedicated Gig-E (or even 100baseT) connection to the network backbone. Cheap desktop switches installed on desks allow one cable to go to each group of desks (or two cables if you have separate networks for VOIP and data). If you have a large office area then a fast switch in the corner of the room connecting to desktop switches on the desks is a good way to reduce the cabling requirements. The only potential down-side is that some switches are noisy, the switches with big fans can be easily eliminated by a casual examination, but the ones that make whistling sounds from the PSU need to be tested first. The staff at your local electronics store should be very happy to open one item for inspection and plug it in if you are about to purchase a moderate number (they will usually do so even if you are buying a single item). A common objection to this is the perceived lack of reliability of desktop switches. One mitigating factor is that if a spare switch is available the people who work in the area can replace a broken switch. Another is that my observation is that misconfiguration on big expensive switches causes significantly more down-time than hardware failures on cheap switches ever could. A cheap switch that needs to be power-cycled once a month will cause little interruption to work, while a big expensive switch (which can only be configured by the “network experts” - not regular sysadmins such as me) can easily cause an hour of down-time for most of an office during peak hours. Finally the reliability of the cables themselves is also an issue, having two cables running to the local switch in every office can allow an easy replacement to fix a problem - it can be done without involving the IT department (who just make sure that both cables are connected to the switch in the server room). If there is exactly one cable running to each PC from the server room and one of the cables fails then someone’s PC will be offline for a while. In server rooms the typical size of a rack is 42RU (42 Rack Units). If using 1RU servers that means 42 Ethernet cables. A single switch can handle 48 Ethernet ports in a 1RU mount (for the more dense switches), others have 24 ports or less. So a single rack can handle 41 small servers and a switch with 48 ports (two ports to go to the upstream switch and five spare ports). If using 2RU servers a single rack could handle 20 servers and a 24port switch that has two connections to the upstream switch and two spare ports. Also it’s generally desirable to have at least two Ethernet connections to each server (public addresses and private addresses for connecting to databases and management). For 1RU servers you could have two 48 port switches and 40 servers in a rack. For 2RU servers you could have 20 servers and either two 24port switches or one 48port switch that supports VLANs (I prefer two switches - it’s more difficult to mess things up when there are two switches, if one switch fails you can login via the other switch to probe it, and it’s also cheaper). If the majority of Ethernet cables are terminated in the same rack it’s much harder for things to get messed up. Also it’s very important to leave some spare switch ports available as it’s a common occurrence for people to bring laptops into a server room to diagnose problems and you really don’t want them to unplug server A to diagnose a problem with server B… Switches should go in the middle of the rack. While it may look nicer to have the switch at the top or the bottom, that means that the server which is above or below it will have the cables for all the other switches going past it. Ideally the cables would go in neat cable runs at the side of the rack but in my experience they usually end up just dangling in front. If the patch cables are reasonably short and they only dangle across half the servers things won’t get too ugly (this is harm minimisation in server room design). The low end of network requirements is usually the home office. My approach to network design for my home office is quite different, I have no switches! I bought a bunch of dual-port Ethernet cards and now every machine that I own has at least two Ethernet ports (and some have as many as four). My main router and gateway has four ports which allows connections from all parts of my house. Then every desktop machine has at least two ports so that I can connect a laptop in any part of the house. This avoids the energy use of switches (I previously used a 24 port switch that drew 45W [2]), switches of course also make some noise and are an extra point of failure. While switches are more reliable than PCs, as I have to fix any PC that breaks anyway my overall network reliability is increased by not using switches. For connecting the machines in my home I mostly use bridging (only the Internet gateway acts as a router), I have STP enabled on all machines that have any risk of having their ports cross connected but disable it on some desktop machines with two ports (so that I can plug my EeePC in and quickly start work for small tasks).

• [1] http://www.darkroastedblend.com/2008/08/crazy-wiring-part-5.html


• [2] http://doc.coker.com.au/environment/computer-related-power-use/

Share This

I’ve had little time in the four years I’ve lived in Roslindale to get involved in community volunteer efforts. My wife Rachele, however, has devoted several years to efforts such as the Roslindale Community Center, Roslindale Village Main Streets, and Roslindale Clean and Green. She has served as chair of both RCC and one of the RVMS committees. Over the past few months, I’ve been disappointed to see the RCC board endure repeated senseless attacks by a perhaps overzealous community member, Walter Michalik, who has effectively paralyzed the organization. I have nothing personal against this guy, but I thought I could do my part here by publishing an example of an email he broadcast to the committee, which I think is embarrassing enough on its own merits to need no editorializing from me, except to say any email that starts with “just so you won’t be surprised when the IRS launches its investigation” can be neither productive nor taken seriously. The context is a response to an announcement sent out pursuant to the Community Centers By-Laws scheduling a special meeting to discuss the recent upheaval on the Council. There’s no reason this should not be in the public record:

Rachele Just so you won’t be surprised when the IRS launches its investigation, be advised that YOU DO NOT HAVE THE AUTHORITY TO CALL FOR A SPECIAL MEETING. The By Laws do not allow the President/Chair to call for a Special meeting - that right is reserved for the MEMBERS to have a power over a hostile or non-performing President/Chair. It was created by a Membership wary of annimosity within its ranks in order to protect itself from falling into a useless dysfunctional body. That’s why our By Laws require the majority of the membership request it through the Chair and not the other way around. So you screwed that up too. Your continuous violation of rules and laws have proven beyond a doubt that this current Roslindale Community Center Council has violated the trust behind its IRS-designated not-for-profit status. The failures are on so many significant levels over 6 months it is readily apparent that the Roslindale Community is better served without a Community Center Council. There is no longer any excuse to allow the residents of Roslindale to be denied the services they deserve that you and the officers have no idea how to deliver. Because that’s what you are supposed to do - serve the residents of Roslindale and not preseide over a self-serving board. You’ve taken us from dysfunctional to non-functional over the past 60 days. You and your officers have already driven away our Archdale partners and now the merger is off. Congratulations. You got what you wanted. You and the officers have withheld information from the Members of the Council imposing gag orders along the way and in more than one instance spreading lies within this community. There are so very many lapses on your part and the rest of the officers that it is very apparent that the Roslindale Community Center exists IN SPITE OF the Roslindale Community Center Council - not because of it. It would be far better indeed, if the Center were run without the Council. What have you done in 6 months? All you do is avoid the work of leadership. Please, just gracefully step aside and let a real leader emerge - or dissolve the Council and let the Center run itself under BCYF before the IRS makes that happen. Of course this is my stated opinion. You can choose not to belive it. You can huddle with a group of self-serving officers and invent excuses or change the agenda away from the message and continue with your ad hominem attacks against the messenger. I’m thick-skinned. Feelings aren’t important to me - services to residents are important to me. While I have, in fact, enjoyed the confidences of others within this community and their true displesure with this Council, I will produce that to the appropriate authorities as I see fit along with the Bill of Particulars I have produced with documentation for all charges. As a founder of the Roslindale Community Center Council I can no longer support you or the officers as any legitimate authority in this community.

Technorati Tags: Boston, Roslindale, Walter Michalik

Share This

Ah, Dell. Seeming inventors of the tech support pit of bureaucratic indifferences, inventors of the flamingo pink Inspiron, perpetrators of fraud in New York...

I have, for over a year now, been on a crusade trying to get them to stop sending me their Dell Home and Home Office catalog to my mailbox. It has been a bundle of fun, let me tell you.

They have a nice-sounding privacy policy. It says you can opt out of all their mailings by filling out a form online. Yeah, good luck with that. First of all, there are different forms for different departments at Dell. I've filled out them all, multiple times. They do nothing whatsoever. Perhaps they use them as lists of known-good addresses to send new advertisements to, rather than lists of people to remove. Oh well.

Now, unfortunately I feel compelled to bore you with the saga so far, involving telephone hang-ups, broken privacy policies, and the like. But there is a silver lining at the end, in which I submitted a request to the postal service asking them to block Dell from sending me any more mail, and it appears that they are very likely to violate Federal Law any day now.

I have called them about it. Dealt with the old "let me transfer you to the correct department" then hang up on me ploy. Spoken to people that have promised up and down that I'll be off their list in 30-60 days. It's always 30-60 days, isn't it? Very convenient that I can't tell for 2 months whether or not they've processed my request.

I've tried their online chat. One of my attempts went like this:

Session Started with Agent (Sneha Ranga)

Agent (Sneha Ranga): "Due to circumstances that have affected Dell Communications I am temporarily unable to pull up any information. The down time is temporary. We apologize for the inconvenience, as we value your time as a customer. Please contact us back after an hour."

Session Ended

Ah Dell, only you could reach such a pinnacle of customer service. /kicking someone out of a chat room before they have a chance to say a word.

Finally, last fall, I blogged about the situation (that's the link above). Debbie from Dell red the post and emailed me. Great, I thought. She asked for my address information and catalog information and sent me a removal confirmation:

From: Debbie@Dell.com
Date: Thu, 18 Oct 2007 13:08:18 -0500
To: jgoerzen@complete.org
Subject: RE: Dell mailing list

Thank you, Mr. Goerzen, your request to have the below address
information removed from our marketing lists has been received:

[ my address here ]

We will process your request promptly. However, it may take several
weeks for some changes to take effect. If you are still receiving
catalogs after thirty (30) days feel free to email me. Sorry for any
inconvenience you may have experienced.

Thank you,
Debbie

So that was October. In December, I replied to that message, saying: "I received another mailing today, and it's been nearly 2 months since your initial message. If there's anything further you can do, I'd appreciate it." Debbie said, "I am very sorry Mr. Goerzen, I will resubmit your request." Guess how successful that was.

So in February, I manage to figure out a way to send in a support ticket without having a Dell system serial number. I wrote:

I keep getting your Dell Home and Home Office catalog. I have tried for months to get off your mailing list. I have called in, talked to people in multiple departments, who have promised to remove me from the list. I have contacted you online. NOTHING IS HELPING. This has gone on for MONTHS.

PLEASE NEVER SEND ME MAIL AGAIN, EVER, AND DO NOT RENT OR SHARE MY NAME.

My address is above.

The code on the mailing I received is: [ snipped ]

The form letter I got back said:

If you are currently receiving our catalog or mailings and would like to be removed, please visit the following web page and select the appropriate link under the "Opt-out of direct mail, phone or fax communications" heading: http://www.dell.com/OptOut

I replied, saying that form didn't work. Guess what I got back?

Thank you for signing up for Dell Email Subscriptions. Please save this email for your records.

Yes, that's right. Asking them to take me off their postal mailing lists got them to PUT ME ON their email lists. ARGH.

So they eventually manage to correctly take me off the email list, and of course promise to do the same with the postal list. This back in February.

I contacted them again in March and July, only to have a similar stupidity-laced run-in with clueless form-answer-laden Dell support reps. Each one claimed to have now, finally, and permanently removed me from the list. It never happened, and none of them lifted a finger to find out way, and no amount of begging could make them.

So, here's the good part.

Junkbusters has spent years educating people on how to get rid of unwanted mail, and documents getting a prohibitory order against the sender. It was originally designed for people that didn't want to receive obscene advertising mailings, but thanks to the happy fact that one non-adult-mailer challenged a prohibitory order all the way to the Supreme Court, you can now get prohibitory order against anyone. Yes, even Dell. (The supreme court's ruling even gave an example: you can prohibit a clothing catalog if you want.)

And last month, that's exactly what I did. The USPS sent me back a copy of the letter they sent to Dell, as well as a second page with instructions on reporting violations. Here's the letter they sent to Dell:



Somehow I get a chuckle over some Dell mail clerk trying to figure out how an 11-pound laptop is sexually provocative.

From August 25 on, it is a federal offense for Dell to send me another Home and Home Office catalog. This is a branch of criminal law, not civil law. That is, it's the maybe-go-to-jail branch of law.

How disappointed I was to receive yet another catalog from them today. If only they had waited 5 more days, I could have turned them in now.

Oh well. There's always next month's catalog. Let's just hope the clerk that received the USPS letter removed my name with a better system than everyone else at Dell uses, eh?

I've been meaning to write up on this for quite some time now, but always have something seemingly more important things to do. Most modern Linux distributions offer ways to manage network interfaces via some kind of abstraction. Usually this abstraction allows one to dynamically rename and add network interfaces. For Debian family management is done with ifupdown, while with RedHat family it's sysconfig. In addition there is NetworkManager which is a cross platform solution for dynamic network configuration (which eliminates the need to rename interfaces). Case Xenserver Usually this comes in rather handy, but on other occasions it can be a pain. A while I was helping out with an installation of a XenServer instance. This server had, for some reason, ethernet interfaces reversed in comparison to the other XenServers on the site. Luckily the service console has the network configuration in ifcfg scripts. We were easily able to reverse the interfaces by binding the interfaces to certain hardware addresses. The only problem is that the interface is renamed only when the interface is brought up. What's worse the interfaces were enumerated before the server would bring up all of the interfaces. Only eth0 was brought up for management purposes before enumerating. This means that the original eth0 was renamed to _tmp_xxxxxx. The (oh so elegant) solution was to create a script that does ifup eth1; ifdown eth1. Problem solved. Case tap0 I also experienced similar problems when I was setting up my OpenVPN tunnel. I wanted to use a bridged connection to my network, but for that I needed to create a br0 interface with tap0 as a member. It's easy enough to create ifupdown configuration to set up tap0. Hook that up to br0 and you are all set. The same problem will bite you here. The interface tap0 is actually created only when the tap0 is brought up and br0 members are added only if they are present. The solution? In my case, create a custom script that adds the device manually after it's been created properly. I was unable to find anything that works without using a custom script =( In retrospect Looking back at these cases, I should have known better. The problem was obvious and it took me way too long to figure out the cause for my problems. Then again, the utilities should be able to create a reasonable abstraction for themselves that they use to determine the actual status of the whole system. This way the trickery needed for setting up simple interface would be obsolete. You can't have it all, but you can always hope.

Update: There are more notes on how aptitude performs as a Sudoku solver here. Russell Coker recently wrote a post entitled Ownership of the Local SE Linux Policy. This post has nothing to do with the substance of his post, which is a discussion of how distributions should configure SELinux by default. I know nothing about SELinux, but something that Russell said in passing caught my attention:

I am not aware of the Debian package dependencies (or those of any other distribution) being about to represent that the postfix package depends on selinux-policy-default-postfix if and only if the selinux-policy-default package is installed. Please note that I am not suggesting that we add support for such things, a package management system that can solve Sudoku based on package dependency rules is not something that I think would be useful or worth having.

(emphasis added) As it happens, a little-known fact about the Debian packaging system is that you can, in fact, describe Sudoku puzzles in it! Note for the impatient: If you want to skip all this talk and jump to the code, see debsudoku.py. For those of you who, like me, are not Sudoku-heads, here's a quick summary of the rules (for the common case of a game with 3 blocks):

1. The game is played by filling in a 9-by-9 grid with numbers between 1 and 9, inclusive. The board is divided into 9 3-by-3 blocks of grid cells in the obvious way.
2. All the cells in a column must contain different numbers.
3. All the cells in a row must contain different numbers.
4. All the cells in a block must contain different numbers.

There are many ways that you could convert a Sudoku problem into a Debian package archive, but here's a particularly simple one that is close to my summary of the rules. Create 9 * 9 * 9 = 729 packages, named cellR.C-V where R stands for row, C for column, and V for value. Each of these packages represents writing the value V in the cell (R, C). To describe the relationships of each cell to the other cells in the problem, we can create several virtual packages:

• The virtual package cellR.C represents the statement The cell (R, C) has been filled in with some value. It will be used to ensure that only one value is placed in any particular cell, and to ensure that all the cells in the puzzle are filled in with something.
• The virtual package blockR.C-V represents the statement A cell in the block (R, C) has been filled in with the value V. The block coordinates are the block-row and block-column containing the cell; for instance, the cell at (5, 8) is in block (2, 3). This package will be used to ensure that only one cell in a given block contains the same value.
• The virtual package rowR-V represents the statement A cell in the row R has been filled in with the value V. It will be used to ensure that no two cells in any given row have the same value.
• The virtual package colC-V represents the statement A cell in the column C has been filled in with the value V. It will be used to ensure that no two cells in any given column have the same value.

Converting these requirements to package dependencies is quite straightforward. For the package cellR.C-V, in block row BR and block column BC, we add these lines to the package's definition:

Provides: cellR.C, blockBR.BC-V, rowR-V, colC-V
Conflicts: cellR.C, blockBR.BC-V, rowR-V, colC-V

For instance, the cell at (5, 8) will get these provides/conflicts for V=2:

Provides: cell5.8, block2.3-2, row5-2, col8-2
Conflicts: cell5.8, block2.3-2, row5-2, col8-2

This relies on the fact that self-conflicts are ignored (see Debian Policy section 7.4). To actually describe the puzzle we want to solve, we need to add another package that requires two things:

1. Every cell contains a value.
2. The cells that the problem fixes have their fixed values.

For instance,

Package: puzzle
Depends: cell1.1, cell1.2, ..., cell5.9-3, cell6.1, ....

if we want to require that the cell at (5, 9) contains the value 3. Proof-of-concept As a proof-of-concept, I have written a hacky Python script, named debsudoku.py, that can convert ksudoku saved games into Packages files suitable for use with apt-get or aptitude. In fact, it has two modes: conflicts, which implements the conversion described above, and depends, which implements a different but logically equivalent conversion using only Depends instead of Conflicts. To use the script, save a ksudoku board without doing any work on it, then run

python debsudoku.py /path/to/the/ksudoku/board

I've only done minimal testing on this, so don't use it to fly airplanes (in fact, please don't use any Sudoku player to fly airplanes), but I did use it, in combination with aptitude, to solve a single ksudoku puzzle. Real-world evaluation Interestingly, in a test with an easy puzzle generated by ksudoku, aptitude was able to solve the puzzle in just a few seconds when it was expressed with the conflicts reduction, but failed to find a solution at all using depends (I stopped it after several minutes). I think this is due to how the depends reduction is performed. Take rows: instead of generating conflicts between cells in a row, it requires that each row contain every number between 1 and 9. The problem with this is that aptitude's resolver functions poorly when there are non-obvious conflicts in the dependency structure. It will decide to try a combination of packages that can't be installed together, but it won't realize it. As a result of this, it ends up trying many possible combinations of packages. For instance, it might try to place the number 3 in both (2, 5) and (5, 5). There is no dependency outlawing this in the depends reduction, so aptitude will happily continue trying to resolve dependencies. Since it has used 3 twice in the fifth column, it will not be able to find any way to resolve all the dependencies that state that all the numbers between 1 and 9 appear in the 5th column, but it lacks the higher-level reasoning that would allow it to break out; it will end up trying many or most of the possible ways of filling cells in before it gives up on the offending re-use of 3. Luckily, real-world package archives (what the aptitude resolver is designed to run on) don't usually look like this.

Some interesting two days have just passed. I took the airplane from Mar del Plata to Buenos Aires on the 17th, slept one night in a hostel on a mattress that felt like stone, and went to the 'Circulo del Officieles de la Mar' (or some such, I don't know spanish) where I had to give a talk. The oral feedback I've gotten so far indicates that people did appreciate it, which is good. I had originally planned to do some sightseeing in Buenos Aires after my talk, but me being tired and not immediately finding anyone else to go with me changed those plans. Instead, I just stayed at the C.O.M., where we played some Mao. Amongst other things. About an hour before I left the place, Holger Levsen gave me a tripod, with the request to take it with me to Belgium, and keep it until FOSDEM. As that would also give me the use of an tripod, and being the photography hobbyist that I am, I was too happy to oblige. There was just one problem: the suitcase that contained my luggage already had a bulge from here to tokio, so adding it was a no-no. No problem, I thought. I'll just keep it in my carry-on luggage. There's some space left there, and I certainly didn't have 5kg of carry-on luggage yet. Problem solved. The 'security' in EZE is a joke; the security officer doesn't even look at the screen while X-raying my luggage. Well done. So I fly from EZE to MAD on the first, 11-and-a-half-hour leg of my flight. Madrid Barajas is a crazy airport, with its own private metro. Somewhere between gates R-something (where IB6844 from EZE arrived) and J40 (where the flight to BRU will depart from), we need to go through a security checkpoint. Strange, since I hadn't had to do that on my way in from BRU to EZE; but of course you have no choice, so I comply. As I've gotten used to by now, what with the mess of cabling in my laptop bag and the other metal objects there, I get a baggage check. The security officer who goes through my very messy bag asks me to open the bag containing the tripod, so he can see it. He then promptly decides that it is a "sharp" object, and that it is "not acceptible". Here the fun begins. Of course, trying to argue with a security guard isn't the best idea if you want to be allowed on any flight, ever, so I don't even try that. I ask him 'can I check that in, instead?' and he tells me how to go back, to the exit, and to the departures hall where I can have that little tripod get checked in. So I go there. The lady at the check-in desk tells me that she cannot check the tripod in, because the flight has already been closed and I'm too late. I tell her I'm from a connecting flight, and that I can't help that. She says she knows. So I ask her what my other options are. She tells me I could try to get on the next flight to Brussels, which is at 20:00 (rather than the 16:20 flight that I was booked on). I consider that an acceptable compromise, so ask her how to get that done, and she refers me to the ticket sales desk, some 10 meters to my left. Unfortunately, the 20:00 flight turns out to be completely booked, and there are no other flights on the same day. The best alternative he can give me is a flight to Amsterdam at 19:20, which would cost 'a little more'. I ask him 'how much more'. He starts looking up things in his computer, and after a few minutes tells me that he cannot refund my ticket for the 16:20 flight and that a flight to amsterdam would cost me 429. At this point I get somewhat angry, and tell him that this is not acceptable. He refers me to the customer service desk right across. The lady at the customer service desk is friendly, but firm: she cannot help me. Either I leave the tripod behind, or I pay whatever the ticket service asks me—she takes my word that it is 429, because she cannot check it, and cannot change it, either. I get more agitated, and ask to see the supervisor. She points me to a lady a little across who can 'call' the supervisor. At this point it is 15:55 As I reach that lady, apparently someone else had just asked for the same thing, and starts arguing with a guy in black uniform, who appears to be the supervisor, about the fact that he's got more than 30kg of luggage which he isn't allowed to take along with him. Dude, not a single airline will let you do that, no matter how much you argue. I let them argue for about 10 minutes, all the while nervously looking at my watch, but then I interrupt with 'please, I don't have much time left before my flight leaves'. That gets his attention. In our two-minute conversation, the guy in black backs up everything the other three people have told me, adding that '429 is reasonable; your luggage is already on the flight, and it will cost Iberia a lot of money to delay the flight and get it off'. I curse. He also seems surprised at the notion that I'm not allowed to take a tripod in my carry-on luggage. Hmm. Figuring I have nothing to loose, I curse one more time, and make a run for it. When I reach the security checkpoint, I ask to be allowed to skip the queue in front of it, on the grounds that I have only 15 minutes left before my flight leaves. Mind you, this is not the same security checkpoint as the one where I was rejected about an hour earlier; this is the security checkpoint between the departures hall and the secure area, whereas the other security checkpoint was one between two different terminals. I am granted my request, and quickly throw everything in the X-ray boxes. They need to go through my bag again. I help them, showing where everything conspicuous is, and opening my flute box so they know what's in there. He looks at everything, and signals that I can move on. Hang on, I think. This can't be right. 'Okay,' I ask? 'Yes,' he says. I run for the nearest info desk, show them my boarding pass, and tell them 'please, my flight leaves in 10 minutes, can you tell me where to go?' They are quick and efficient. Gate J40. I make a run for it again, and just make it in time. Of course, I could forget about my plans of finding a power outlet, plugging in my cell phone and calling my parents, but that's not a big deal—there's a train station at Brussels Airport. So what have we learned? Security on airports is random, arbitrary, non-standardized, and utterly stupid. Items that pose no danger at all—plastic bottles containing more than 100ml of water, small quantities of yoghurt that are over 100grammes but not over 100ml, tripods—are not allowed, while on the other hand I've occasionally gotten through security carrying knives and tools that are clearly forbidden by the rules. We've also learned that the rules very much depend on the particular person checking you. If you're refused for an item that is not a knife or a gun or something else similarly problematic, it may help to just find a different security checkpoint and try again. It's not as if they make any sense, anyway.

I haven't posted for a long while about ctioga, but that does not mean that development has stopped. It goes on, and features get added basically every single time I need them. Recent additions make it possible to tune a little more the look of the legends and add pure text lines in them. I've however realized that now, what ctioga is missing the most is real flexibility over the coordinates. For now, all coordinate positions are either relative to the frame (such as for --inset) or to the graph (for --draw). What I really wish is a way to mix all kind of coordinates: real size (1cm), frame position and graph position. That will require quite a fair deal of work, of course, but that shouldn't be too difficult... I'll go on posting about it here.

A large part of the disagreement about the way to manage the policy seems to be based on who will be the primary “owner” of the policy on the machine. This isn’t a problem that only applies to SE Linux, the same issue applies for various types of configuration files and scripts throughout the process of distribution development. Having a range of modules which can be considered configuration data that come from a single source seems to make SE Linux policy unique among other packages. The reasons for packaging all Apache modules in the main package seem a lot clearer. One idea that keeps cropping up is that as the policy is modular it should be included in daemon packages and the person maintaining the distribution package of the policy should maintain it. The reason for this request seems to usually be based on the idea that the person who packages a daemon for a distribution knows more about how it works than anyone else, I believe that this is false in most cases. When I started working on SE Linux I had a reasonable amount of experience in maintaining Debian packages of daemons and server processes, but I had to learn a lot about how things REALLY work to be able to write good policy. Also if we were to have policy modules included in the daemon packages, then those packages would need to be updated whenever there were serious changes to the SE Linux policy. For example Debian/Unstable flip-flopped on MCS support recently, changing the policy packages to re-enable MCS was enough pain, getting 50 daemon packages updated would have been unreasonably painful. Then of course there is the case where two daemons need to communicate, if the interface which is provided with one policy module has to be updated before another module can be updated and they are in separate packages then synchronised updates to two separate packages might be required for a single change to the upstream policy. I believe that the idea of having policy modules owned by the maintainers of the various daemon packages is not viable. I also believe that most people who package daemons would violently oppose the idea of having to package SE Linux policy if they realised what would be required of them. Caleb Case seems to believe that ownership of policy can either be based on the distribution developer or the local sys-admin with apparently little middle-ground [1]. In the section titled “The Evils of Single Policy Packages” he suggests that if an application is upgraded for a security fix, and that upgrade requires a new policy, then it requires a new policy for the entire system if all the policy is in the same package. However the way things currently work is that upgrading a Debian SE Linux policy package does not install any of the new modules. They are stored under /usr/share/selinux/default but the active modules are under /etc/selinux/default/modules/active. An example of just such an upgrade is the Debian Security Advisory DSA-1617-1 for the SE Linux policy for Etch to address the recent BIND issue [2]. In summary the new version of BIND didn’t work well with the SE Linux policy, so an update was released to fix it. When the updated SE Linux policy package is installed it will upgrade the bind.pp module if the previous version of the package was known to have the version of bind.pp that didn’t allow named to bind() to most UDP ports - the other policy modules are not touched. I think that this is great evidence to show that the way things currently work in Debian work well. For the hypothetical case where a user had made local modifications to the bind.pp policy module, they could simply put the policy package on hold - I think it’s safe to assume that anyone who cares about security will read the changelogs for all updates to released versions of Debian, so they would realise the need to do this. Part of Caleb’s argument rests on the supposed need for end users to modify policy packages (IE to build their own packages from modified source). I run many SE Linux machines, and since the release of the “modular” policy (which first appeared in Fedora Core 5, Debian/Etch, and Red Hat Enterprise Linux 5) I have never needed to make such a modification. I modify policy regularly for the benefit of Debian users and have a number of test machines to try it out. But for the machines where I am a sysadmin I just create a local module that permits the access that is needed. The only reason why someone would need to modify an existing module is to remove privileges or to change automatic domain transition rules. Changing automatic domain transitions is a serious change to the policy which is not something that a typical user would want to do - if they were to do such things then they would probably grab the policy source and rebuild all the policy packages. Removing privileges is not something that a typical sysadmin desires, the reference policy is reasonably strict and users generally don’t look for ways to tighten up the policy. In almost all cases it seems best to consider that the policy modules which are shipped by the distribution are owned by the distribution not the sysadmin. The sysadmin will decide which policy modules to load, what roles and levels to assign to users with the semanage tool, and what local additions to add to the policy. For the CentOS systems I run I use the Red Hat policy, I don’t believe that there is a benefit for me to change the policy that Red Hat ships, and I think that for people who have less knowledge about SE Linux policy than me there are more reasons not to change such policy and less reasons to do so. Finally Caleb provides a suggestion for managing policy modules by having sym-links to the modules that you desire. Of course there is nothing preventing the existence of a postfix.pp file on the system provided by a package while there is a local postfix.pp file which is the target of the sym-link (so the sym-link idea does not support the idea of having multiple policy packages). With the way that policy modules can be loaded from any location, the only need for sym-links is if you want to have an automatic upgrade script that can be overridden for some modules. I have no objection to adding such a feature to the Debian policy packages if someone sends me a patch. Caleb also failed to discuss how policy would be initially loaded if packaged on a per-module basis. If for example I had a package selinux-policy-default-postfix which contains the file postfix.pp, how would this package get installed? I am not aware of the Debian package dependencies (or those of any other distribution) being about to represent that the postfix package depends on selinux-policy-default-postfix if and only if the selinux-policy-default package is installed. Please note that I am not suggesting that we add support for such things, a package management system that can solve Sudoku based on package dependency rules is not something that I think would be useful or worth having. As I noted in my previous post about how to package SE Linux policy for distributions [3] the current Debian policy packages have code in the postinst (which I believe originated with Erich Schubert) to load policy modules that match the Debian packages on the system. This means that initially setting up the policy merely requires installing the selinux-policy-default package and rebooting. I am inclined to reject any proposed change which makes the initial install of of the policy more difficult than this. After Debian/Lenny is released I plan to make some changes to the policy. One thing that I want to do is to have a Debconf option to allow users to choose to automatically upgrade their running policy whenever they upgrade the Debian policy package, this would probably only apply to changes within one release (IE it wouldn’t cause an automatic upgrade from Lenny+1 policy to Lenny+2). Another thing I would like to do is to have the policy modules which are currently copied to /etc/selinux/default/modules/active instead be hard linked when the source is a system directory. That would save about 12M of disk space on some of my systems. I’ve taken the unusual step of writing two blog posts in response to Caleb’s post not because I want to criticise him (he has done a lot of good work), but because he is important in the SE Linux community and his post deserves the two hours I have spent writing responses to it. While writing these posts I have noticed a number of issues that can be improved, I invite suggestions from Caleb and others on how to make such improvements.

• [1] http://www.calebcase.com/node/2


• [2] http://lists.debian.org/debian-security-announce/2008/msg00201.html


• [3] http://etbe.coker.com.au/2008/08/18/se-linux-policy-packaging-distribution/

Share This

The Debian-Med CDD was started in January 2002 and has evolved a lot
since this time. Debian now becomes the distribution of choice for
people who are working in the field of medicine. On the one hand this
can be obtained from the increase of pure numbers of packages in the
field of medicine.

On the other hand - which is even more interesting for general Debian
development - a group was formed that has developed a certain way of
cooperation which might serve as an example for other teams. Debian
knows a lot of technical teams focussing onto technical issues
(pkg-perl, pkg-python, d-i, etc.). An important part of the project is
to involve people who call themselves "pure users" or "non-developers"
(whatever this might mean) as it is done at a certain amount by the
i18n and Debian Edu team.

So this talk is not about boring the audience by mentioning medical
Free Software - it exists at a certain amount out there as other
specific software does as well - but rather how to attract people to a
topic where FLOSS is not common but should. It will give examples for
our way to advertise Free Software in medicine which is heavily
dominated by proprietary software, which tools we developed inside the
CDD framework to be always up to date with our web pages that are
intended to attract users to Debian and last but not least the lessons
we have learned in the project that might be of high interest for
other CDDs (or potential CDDs). Examples are given for project
management, attracting people by working techniques and making sure
that medical software finds a good home in Debian.
Full event details