I bought the Bose QC15 noise canceling headphones for my trip back from the US. See my previous posts about Noise Canceling Headphones [1] and Testing Noise Canceling Headphones [2] for the details of my search. I first tried my new headphones in my hotel room and they worked really well at blocking the noise from the nearby road (El Camino Real in Menlo Park) as well as the noise from the heater in my room. At the airport they entirely blocked the sound of the airport air conditioning system (which was surprisingly loud I didn t realise how loud until I tried the headphones). On the flight the headphones worked really well. I used them for hours when they weren t plugged in to any source, just stopping the noise was a huge benefit. I was also able to listen to music (both MP3s on my laptop and the plane sound system) at a relatively low volume with an apparent high quality. The Bose store I visited in Stanford mall has a sound system set up to emulate the noise you experience inside a jet to demonstrate what the headset can do. It really lives up to this demonstration! I recommend them to anyone who wants over-ear noise canceling headphones and can afford $US300 + tax. But one thing to note is that not everyone likes such things my wife didn t like the sound that they generate (the least bad way to describe it is as a soft hiss). This is definitely not something you would want to buy based on reviews alone, it must be tested in-store. The main technical suggestion I can make for improvement to the QC-15 is for it to have slightly softer and thicker padding where it contacts the sides of the wearer s head. I find that my glasses prevent it from making as good contact as I would like, and that when wearing it while eating the contact is significantly broken with every jaw movement which is really annoying. A minor suggestion is that every pair of headphones should have the left and right ear pieces clearly marked, I really shouldn t have to read an instruction manual to discover which way to wear it. One thing that surprised me was the inclusion of business cards for the headset! Here is a picture:

The picture links to a larger picture that also shows the French version of the same text on the other side. I was astonished by this, encouraging happy customers to help sell your products is a reasonable and effective form of product promotion (really this is what I m doing for Bose with this blog post). But giving customers business cards is going too far anyone who wants me to hand out their business cards can offer to pay me to do so (and I probably won t accept). But if such things are considered to be a good idea then here are a few suggestions for other things that they could do:

1. Create a Bose dating site where one can meet people who like music and traveling (this does sound appealing). In about 10 years the children of people who meet that way would start buying audio gear
2. Start a Bose fan club.
3. Create a template that be used by a tattoo parlor to make a Bose tattoo.
4. Sell Bose fan t-shirts to people who aren t dedicated enough to get a tattoo.
5. Register Bose as a religion, that gets tax free status among other benefits.

It s a pity that Bose doesn t make any water-proof noise canceling headphones. It would be something for their marketing people to wear while jumping over a shark on water skis [3]. But seriously the best thing that Bose could do to have their products promoted would be to start by printing the web site for each product on the item, my headset has two patent numbers listed which seem unlikely to provide any benefit for anyone, in that space they could have printed the global.bose.com/qc URL that is on the business card. Of course providing the URL really doesn t do any good when the URL actually is useless. It starts by giving me a page asking which country I am in the correct thing to do is to use geoip to determine the country and then give the user the option of selecting another country if that one is not ideal. Then after I select a country it doesn t take me to a specific page for the product! I could have typed in www.bose.com and got the same result (in terms of US shopping at least) while typing six fewer characters! Next like most corporate web sites the Bose site doesn t appear to be configured for longevity of URLs URLs which are clearly designed for the computer rather than humans are expected to change without warning. This discourages linking to any page that one might discover through web searches or navigating the site, and causes them to lose a lot of potential links. Having specific URLs for all the products (including the obsolete ones) that are designed firstly for humans to read and write would be a good idea. It would be really useful to be able to compare the features of new products with the ones that are going cheap on eBay. For someone who is considering buying a new product now the purchase decision would be easier if they knew that the company would provide resources to help them get a better price on eBay in a few years if they want to upgrade to a newer model. One thing to keep in mind is the fact that the reputation of a company (which makes a dramatic impact on the prices customers are prepared to pay) depends largely on a long history of making quality products. Telling customers about those historic products is one of the most sensible things that most corporations fail to do on the Internet.

• [1] http://etbe.coker.com.au/2009/12/03/noise-canceling-headphones/
• [2] http://etbe.coker.com.au/2009/12/04/testing-noise-canceling-headphones/
• [3] http://en.wikipedia.org/wiki/Jump_the_shark

As someone born in India, I sometimes look around and wonder, Where are the Indians (and other South Asians) in Free Software? (I don't mean to exclude South Asians from other countries, so I will lump us together. I believe that we are more similar than we are different, although I know more about India than about the rest of South Asia.) There is no shortage of Indians performing information technology jobs in the United States. The same is true in academia; the Computing Research Association uses National Science Foundation data to show about 15% of computer science bacholor's degrees are awarded to "Asians or Pacific Islanders." These are not precise numbers targeted at South Asians in particular, but they confirm a general feeling that plenty of technologists in the United States are from that part of the world. South Asia is quite a populous region, coming in at over one billion people. It, too, has plenty of technology workers. So much FLOSS conversation happens in English, and India is well-suited to handle this; English is an "official language". Indian academia reports that there are 350 million English users and about 90 million English speakers. So let's visually compare the Debian developers map for South Asia (over one billion people) and that of New Zealand, a country of four million. India: New Zealand: These two countries have about the same number of Debian developers (at least, who have marked their location in the Debian LDAP database). About four. South Asians comprise about one sixth of the world's population. There are about one thousand Debian developers; we represent at best 1% of that. These numbers are comparable to the under-representation of women in Free Software, especially when you compare the figure to South Asians' over-representation in the rest of information technology. That makes me sad. Take a look at the Debian developer map again. You'll see that Debian is certainly not an Americans-only project, or even an English-speakers-only project. South America has a respectable dotting of developers, and Western- to Central-Europe are packed. I have strong feelings about Free Software. It emerges from an ethos of personal empowerment, and with open source it has become a dominant force in computing. Yet there are plenty of sharp people -- at least women and South Asians -- who, somehow, become culturally excluded from participating.

Why care about diversity? Consider the diversity of contributors we already have. Some contribute to Free Software because of particular business needs, such as what caused Avi Kivity to write KVM, the new leader in Linux-based virtualization. Everaldo's art background gave us the "Crystal" icon set that set the standard for sharp-looking icons on the Free Desktop for years. Josh Coalson knew about compressing sound, and his Free Lossless Audio Codec is now the standard in high quality audio. We already have a great deal of diversity. We should be celebrating! Back in 2001, FLAC's users were celebrating. In that year, I decided to ditch proprietary operating systems because I felt I could achieve all my computing needs in the Free world. A happy user of FLAC myself, I lurked on the mailing list as I watched grateful people thank Josh for the great software he wrote. Different contributions will excite different sorts of users. The more different people we have improving FLOSS, the more happy users we can make. Happy users of FLOSS are Free users. Happy users can become contributors, putting forth code, documentation, translations, and word-of-mouth marketing. The first reason to improve diversity in FLOSS is to better suit our users' needs. The more diversity we have in our contributors, the more chance we have of tickling our users in the ways that please them the most. I wish to see an end to software that restricts users' freedom, so I want to see us build the tools that users want. One thing that pleases me is when I see other people contributing who seem similar to me. When I went to Debconf, I was thrilled to be surrounded by people who cared about software freedom and technical excellence. I had even more fun being social, chatting about rainforests, mutual friends, websites, and music. I might have had the most fun playing the card game Mao. A second reason, then, to improve diversity in FLOSS is to increase contributor retention by increasing joy. Mao was an example of a cultural bond I happened to share with a handful of Debianites. The more diversity we have, the more frequent these sorts of coincidences will be. The final, most obvious, reason to reach out to groups of people who do not typically contribute is that we can increase our numbers. That by itself is so valuable. Ubuntu sees 100 new bugs per week, even after the bug squad's efforts. If we can do a better job of recruiting new contributors, the raw numbers give us more strength in creating and maintaining world-class software as well as letting the world know about it.

Changing the balance I believe that there are plenty of South Asians quite capable of contributing to FLOSS. I believe the same of women. I believe the same of men. Back to the topic at hand. Why do the South Asians vanish when we look at Free Software, not tech in general? There are plenty of reasons I can dream up, based on my experience with Indians.

• Plenty of South Asian parents urge their children to make low-risk career choices.
• My mother reports that schools in India focus on memorization instead of creativity. This can leave little room for extracurricular pursuits.

It's tough for FLOSS advocates to work directly on these distant issues. But I think we can focus some problems we can help solve. Crucially, awareness of Free Software spreads best by social circles. I learned about Linux from a friend at a summer camp. I'll repeat that:

• Awareness of Free Software spreads best by social networks.

So if you want to spread that awareness, try to be a bridge. If you meet someone from an unusual background for open source who needs support or mentorship, try to help. That is an investment in the diversity and growth of Free Software. Those people can now unlock more "open source minorities."

What success looks like Google Summer of Code helps some new contributors get started and provides that mentorship. Rachel McCreary was invited to the SciPy conference after a successful summer. Her father left a comment explaining how her sisters participated in FLOSS via Google's Highly Open Participation (GHOP) Contest:

Rachel was inspired and motivated by BOTH of her little sisters, each completing six GHOP tasks (if memory serves).

GHOP and GSOC has been a game-changer for these girls. Rachel's younger sister is applying to schools such as MIT with an interest in a science major. The youngest daughter now has a Caltech poster on her wall with the intent to eventually attend.

Their proud Dad

Soon, these stories will be commonplace. Until then, we have work to do. (I'm still researching these topics. If you can help me find any sort of data to help me learn more about diversity in FLOSS, even if it seems like I wouldn't like it, leave a comment.)

Despite my position on shell scripts (see sh), one of the bespoke packages in Debian that I look after, game-data-packager, is written entirely in bourne shell. This is partly a result of it's origins: game-data-packager grew iteratively from hacky shell scripts that did specific jobs to install non-free game data into a Debian system. As game-data-packager has grown, I've wanted to write a regression test suite for it. Yesterday I learned of a framework for doing this called shunit2. I don't have any experience of other testing frameworks for comparison, but it looks well written and potentially very useful. Today I discovered that a Debian package for it is being worked on. It also turns out that shunit2 was briefly in unstable and testing 2 years ago, but was removed not long afterwards.

The day before yesterday I learned that a fellow Debian Developer was visiting Porto Alegre Federal University to do some work on Parallel Computing: Vincent Danjean. People from local user group organized a last minute get-together at Cavanhas (that served as last meeting of the year) and we had the most pleasant time. Guaraldo registered the moment with his cellphone camera: Vincent is flying back to France today or tomorrow. Hope he had a great time in Porto Alegre and have a safe trip back home.

The day before yesterday I learned that a fellow Debian Developer was visiting Porto Alegre Federal University to do some work on Parallel Computing: Vincent Danjean. People from local user group organized a last minute get-together at Cavanhas (that served as last meeting of the year) and we had the most pleasant time. Guaraldo registered the moment with his cellphone camera: Vincent is flying back to France today or tomorrow. Hope he had a great time in Porto Alegre and have a safe trip back home.

I was doing some work on NRPE (the Nagios Remote Plugin Executor) and I noticed bug report #547092 [1] which concerns the fact that the default configuration uses the same SSL certificate for all Debian servers and provides a patch to fix the problem. After building the patched package I followed the advice of the DebianAdministration.org article on creating self-signed SSL certificates [2]. cert_file=/etc/ssl/certs/FOO-cert.pem
privatekey_file=/etc/ssl/private/FOO-key.pem
cacert_file=/etc/ssl/certs/cacert.pem Then I added the above lines to /etc/nagios/nrpe.cfg to instruct the nrpe to use the certificates. For the Nagios server I had the problem that most of the systems I monitor run old versions of NRPE while only a few are recent Debian systems that allow me to easily install a new SSL checking nrpe. So I installed the following script as /usr/lib/nagios/plugins/check_nrpe to run either the old or the new check_nrpe: #!/bin/sh -e
if echo $2 egrep -q server0\ server2\ mail ; then
/usr/local/sbin/check_nrpe -C /etc/cert/cert.pem -k /etc/cert/key.pem -r /etc/cert/cacert.pem $*
else
/usr/lib/nagios/plugins/check_nrpe.orig $*
fi The reason I started working on Nagios was to try and solve bug #560002 [3] which I filed. The bug concerns the fact that applications such as mailq which are run as part of Nagios checks were inheriting a TCP socket file handle from the nrpe. SE Linux prevents such file handles from being inherited, but it does mean that I get audit messages (and this is not a good case for a dontaudit rule). Update:
One thing I forgot to mention is that the SSL key checking requires that the server common name used in the SSL certificate of the nrpe system matches the name that is used by the check_nrpe program. So if you check by IP address then you need to use the IP address in the certificate name which is rather ugly. So I have moved to putting the hostname of each server in /etc/hosts on the NAGIOS system and using the hostname in the SSL certificate. This required using $HOSTNAME$ instead of $HOSTADDRESS$ in the NAGIOS configuration (thanks to John Slee for a tip in that regard). Update2:
I removed some printf debugging from the script. It seems that I included a pre-production version of the script in the first version of this blog post.

• [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=547092
• [2] http://www.debian-administration.org/articles/284
• [3] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=560002

The IANA port allocated for ManageSieve is 4190/tcp, and the old port used by timsieved and other managesieve software in many distros (2000/tcp) is allocated for Cisco SCCP usage, according to the IANA registry.

Starting with the version 4.38 of the Debian netbase package, the sieve service will be moved from port 2000 to port 4190 in the /etc/services file. This affects to those using Debian Squeeze, and Debian Sid. Debian Etch and Debian Lenny users are NOT affected.

Any installs which used the sieve service name instead of a numeric port number will switch to the new port number as soon as the services are restarted/reloaded, and in some cases, immediately after /etc/services is updated.

This will affect Cyrus IMAP. This may also affect other sieve-enabled software such as DoveCot.

In order to avoid downtime problems, mail cluster administrators using Debian are urged to verify their Cyrus (and probably also DoveCot) installs, and take measures to avoid services moving from port 2000/tcp to port 4190/tcp by surprise in either servers or clients.

It is worth noting that:

1. /etc/services will only be automatically updated if you never made any modifications to it. Otherwise, you will be presented with a prompt by ucf or dpkg asking you about the changes.
2. You can edit /etc/services and change the sieve port back to 2000 if you want (this is not recommended, though).
3. You can edit /etc/cyrus.conf and any other relevant config files for your mail/webmail cluster (e.g. on the sieve web frontends) ahead of time to force them all to a static port number.
4. You can configure cyrus master to listen on *both* ports (2000 and 4190) at the same time, and thus avoid the problem entirely. This also allows for a much more smooth migration from port 2000 to port 4190.

Contributed by: Henrique de Moraes Holschuh

I have an imaginary automobile. It is the finest hybrid of German and Japanese engineering. It has a peppy little engine and a turning radius so small it would make a baby camel cry, and a six-speed manual transmission, and it is powered by the urine of vegan bears. My imaginary father asked me why I would possibly want to buy an imaginary car with a manual transmission. Obviously, whichever marketing campaign brainwashed him in the first place wasn't strong enough on the memetics, because after borrowing my imaginary car, he shut the hell up. You see, it's considerably more fun to drive than an automatic. There are other benefits as well, of course. The primary one is that the transmission does what I want. An automatic transmission is configured for maximum comfort , so it wastes a lot of power when shifting. With a manual, you can slip from gear to gear with minimal clutch time, or in some cases, if you're feeling sassy, without using the clutch at all. You can control your engine speed so that your shift will be just as smooth as an automatic without the egregiously long clutch disengagement or shift overlap. You also can see the road in front of you, so you're always going to be smarter than an automatic transmission, unless you don't understand how slopes work or what collisions with other cars mean to your well-being. Now some NRA member is going to point out that you can get a shift kit and tweak your automatic to be less awful. While spending money on this type of thing sounds like a great idea, a shift kit is not going to bring an automatic into the same league as my car. I can still start the car when the battery's dead. I can get higher fuel efficiency (vegan bears don't exactly urinate for free). I can shift into fifth gear, and coming from a full stop, drive up a hill without stalling (this is particularly useful when a squirrel has gnawed the teeth off of all your other gears). Furthermore, shift kit or not, an automatic is absolutely no fun. Someday, when transmissions have advanced into the realm of liquid hyperspace buckminsterfullerene cones that commune with the unicorns, and they'll have cameras and radar feeding the car's computer with useful information about its surroundings so it can make intelligent shift decisions faster than a human. Then I'll have to choose between saner and more fun. That era has not yet arrived. This is a lousy metaphor for debhelper.

There are few things I really hate. One of them is regressions. Regressions are bad because they usually take away things we are used to rely on, and leave us with the idea that perhaps the technical improvements didn t really improve our lifes as a user, despite putting less burden on the developers. Software is made for users, after all. As part of my work on WebKitGTK+, I always keep an eye on regressions, both from previous WebKitGTK+ releases, and those imposed on embedding applications on their migration away from Gecko, and try to focus some of my efforts into lowering their numbers, whenever I can. In recent times I have worked on removing a few very user-visible regressions in Epiphany, which I see as the most demanding WebKitGTK+ user in GNOME, such as save page not working, missing
favicon support, failing to
perform server-pushed downloads (such as GMail attachments), and not being able to view source. An example of a regression from a previous version of WebKit also exists: in 1.1.17 we started advertising more than we should as supported by the HTML5 media player, causing download to be almost completely broken. All of these are working if you are using WebKit and Epiphany from trunk/master, so should be on the next development versions of WebKitGTK+ and Epiphany. Other people have also fixed many other regressions; a few examples: Xan has reimplemented the Epiphany customization of the context menu, Frederic Peters provided a work-around for mailto: links while we don t have SoupURILoader yet, and Joanmarie Diggs keeps rocking on the accessibility front! If you find regressions, keep them coming! If you have a patch, even better! =) Next week WebKitGTK+ team gets together to work furiously on improving WebKitGTK+ in a hackfest sponsored by Collabora, and Igalia, and hosted/organized by Igalia. While there I should also get my hands on one of these. Can t wait! =)

I'm now a Debian Developer. :) My thanks go to Ben Hutchings, gregor herrmann, Chris Lamb, Christoph Berg, Steve McIntyre, Brad Smith, Jonny Lamb, Chris Boyle, everyone at credativ, and everyone else who helped me with Debian over the last... almost six years? Actually, I've been a DD since the weekend, but have been too absorbed to write about it. In other news, I'm moving house today... I'm more or less packed now. My internet access may be intermittent at home for the next few weeks. (Home is now Southampton, UK.)

My nook arrived today, along with an email asking for my shipping address in order to be sent a CD with the source on. So that's progress. The nook itself is an interesting device - it comes in impressively well produced packaging, which looks easily as attractive as any Apple product I've laid hands on lately. Except that it then includes a double-sided sheet of instructions in the outer packaging to tell you how to get the damn thing out.

And so far, that seems like a pretty good summary of the device. There's a huge quantity of form here, but the function is lacking. The initial registration was made infuriating by the lag between hitting a key on the keyboard[1] and anything happening. I'm not talking about the understandable lag due to the latency of updates on e-ink screens - I'm talking about the seemingly non-deterministic time between tapping the screen and it indicating that I've pressed a key. The coverflow feature for books is better than selecting from a menu of items (e-ink lends itself badly to interactive displays), but slow and jerky. Worse, it's limited to B&N content. Anything you obtain elsewhere and then copy onto the device (which presents as USB mass storage) ends up in a separate menu without any coverflow. And, even more infuriatingly, you can't catagorise the files you copy on there. It's just one big list, sorted alphabetically by author (surname) and then title.

Once you're in a book, things aren't bad. It reformats the text every time you enter a book (no caching), but that takes much less time than my Sony did. The default font is very readable, even at small sizes. But there's clearly something horribly wrong - various epub files I have take up to 4 seconds to perform a page turn, which is way longer than the second or so my Sony took. There's no way to skip to a given page number, which seems like an insane oversight. And, though it's a minor point, the next/previous page buttons are the opposite way around to the Kindle or Sonys, and it's taking a while to get used to that.

It's a promising device. The hardware's clearly capable and the software is mostly there, with the features I'm really missing being ones that shouldn't be hard to implement[2]. But those features are pretty glaring, and right now they make this less functional than the Sony, let alone the Kindle. I'm also kind of surprised that it doesn't ship with any kind of cover at all. There's ample opportunity for physical trauma to turn one of these into a paperweight.

Side note: My nook managed to include the QA checklist slip, presumably by accident. The nook's internal manufacturing designation appears to be "X2", and mine was built on 2009/11/25. Which would seem optimistic for an intended shipping date in the US of 2009/11/30, which does support the idea that the shipping delay was due to some kind of delay in the hardware production.

[1] Presented on the LCD panel
[2] Of course, this being closed-source, I can't do so myself. Sigh.

Today is a nice milestone. For the first time my server is "in the cloud", and yet I have full control over the kernel it is running. While it should be possible to do this with Xen, I never found a host who would. So for the three years since I got rid of colocated physical hardware, I was constantly nagging my Xen hosters to update their kernels, often to fix security issues. And I sometimes struggled with things like udev that needed a newer kernel. Most importantly it just didn't feel right for "my" server to not run my kernel. Even though in this modern day, "my" server is just a fever dream of bigger computer. I'm infected with the Sovereign Computing meme. KVM probably makes this easier than does Xen. What Steve has set up at kvm-hosting.org is a great example and template for providing a small group with great hosting at a very fair price, with full control, and an excellent interface. It's the little things, like being able to view the my neighboring guests' virtial machines in top, that I really like.

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND            
 2841 joey      20   0 1637m 1.0g 3152 S    7 13.2  48:27.20 kvm                
 6606 steve     20   0 1365m 1.0g 3540 S    2 13.2   9:29.52 kvm                
 2888 cernio    20   0 1269m 284m 3152 R    1  3.6   4:08.57 kvm   
 2800 ore2      20   0  754m 521m 3152 S    0  6.6   4:35.68 kvm     

This all feels sorta science fictional when I step back and look at it.

---

notes for kernel setup on kvm-hosting.org I want to be able to install regular Debian kernel packages. In these packages, the virtio drivers are modules, and need to be manually added to an initrd. So first edit /etc/initramfs-tools/modules and add the below to it, then run update-initramfs -k all -u to rebuild the initrd. BTW, some of these modules may not really be necessary.

virtio_blk
virtio_console
virtio_pci
virtio_net
virtio_balloon
virtio-rng

Then edit /etc/kernel-img.conf to configure the kernels to add a symlink to the latest version in /boot. This way, kvm-shell can be configured to boot the latest kernel automatically.

do_symlinks = yes
link_in_boot = yes

And here is a hook that rsyncs /boot, sending kernels and initrds to kvm-hosting, so its interface will let me boot them. This was put in /etc/initramfs-tools/hooks/kvm-hosting-rsync and made executable.

#!/bin/sh
# Use --copy-links so the symlinks to the current
# kernel and initrd are selectable in kvm-shell.
# 
# Use --delete because I like living dangerously. :)
rsync --copy-links --delete -vazr /boot/ kernels.kvm-hosting.net::joey-kernels/

Cross-posted to asheesh.org from the OpenHatch blog. (OpenHatch is my current project.)

"How do I get involved in free and open source software?"

"How do I encourage people to join my project?"

Gregory Wilson, a CS professor at UToronto, cites some recent successes at answering these questions with respect to students: "Google Summer of Code and UCOSP have both shown that it's easier for students to get into open source projects if there s a pile of tiny tickets for them to start with." We believe that these "bite-size" bug lists can benefit all sorts of new contributors, student or not. What you might not know is that more than a hundred projects have these small tasks tagged and waiting for you in their bug trackers.

To make it easier to find these, the OpenHatch volunteer opportunity finder allows you to browse, in one place, nearly 1000 bite-size bugs.

Do you know another project with bite-size opportunities we should index? You can get your project involved. Check out the list of bug trackers we index. If you contribute to a project, go to your bug tracker right now and label a few as bite-size. Then add your bug tracker to our index.

I want to especially thank GNOME for the ongoing GNOME Love effort that is our inspiration and the source of hundreds of these bite-size opportunities.

Happy hacking!

If this sort of thing is interesting to you, take a look at OpenHatch and subscribe to our blog or @openhatchery on Identi.ca or Twitter.

A couple of weeks ago, Lucas Nussbaum wrote about his experience at the Ubuntu Developer Summit. Two things stuck out at me:

• "Ubuntu has clearly gone a very long way since 2004. Everything looks very well organized and polished, and gives the impression of a big machine that nothing can stop."

In the summer of 2004, my laptop (an iBook G4) ran Debian GNU/Linux on PowerPC. I tried out Ubuntu that autumn, and was very impressed. It's been five years since then. My desktop still runs Debian, and I'm proud to be a "two-distro" community member. At the same time, this juggernaut nature raises concern. When Ubuntu releases ship with significant flaws, I quietly sigh and wonder, Are we doing good service to the people coming to GNU/Linux for the first time and seeing Ubuntu? This bugginess has bit me a few times (even for upgrades between one release and the next), and it pushed a friend of mine to switch a lot of his computing to DragonflyBSD. Lucas points out that Ubuntu's done a fantastic job of becoming visible. A look at Google Trends shows that people search for "Ubuntu" about as much as they search for "Linux" at all. Richard Stallman complains when people refer to GNU/Linux as just "Linux." But today, the most popular name for an operating system based on GNU is probably "Ubuntu." For Stallman, having his hard work associated with someone else's "Linux" project must be frustrating. As a Debian contributor, it would be easy to succumb to the same feeling with regard to Ubuntu. Lucas is well aware of that. He asks,

• "Will Debian manage to stay relevant, or are we just going to be the technically-pure distro without many users that serves as a package supermarket for Ubuntu?"

Debian does have users! I was feeling a bit disheartened about my maintenance work on alpine lately, when out of the blue I received an email from a fellow at MIT asking me if I would accept some help with maintenance from him. Just seeing the note was a relief; it's very nice to be reminded that I have users to take care of. Debian is not as popular as Ubuntu on the desktop (or laptop), it's true. But technically sharp people do frequently still choose it. For example, the FreeNAS project recently announced a switch from FreeBSD to Debian (and a new name as coreNAS). But we could end up a "package supermarket". To stave this off, we must do good releases and make sure people know about them. Doing all that work takes us all time. We must recruit new contributors, help them find things to work on, and make sure they feel welcome. And sometimes-sloppy maintainers like me ought to fix our packages, and get help from others where necessary. I promise to work toward that.

As I ran out of time whilst writing the "introducing ujail" post on monday I would like to further elaborate on the idea, giving you some examples of possible use cases and then having a look at FAQs regarding ujail. Additionally I have created a second proof of concept that should be a lot faster, see below for more details.

Use cases of ujail

Monday's post was rather technical, so let's have a look at possible use cases today.

The main reason for both having the idea of ujail and starting working on it is my web server. I am running quite a few (S)CGI scripts there and, even though running them as different users, on a per-vhost basis, I have the impression of the whole thing being a bit insecure.

Okay, PHP does provide its famous open_basedir feature, but I am also running some Python applications which I simply cannot restrict easily. My first ideas involved adding something similar to open_basedir to Python, followed by the idea of replacing some C library functions, like fopen and friends on startup time.

Whilst the adding open_basedir to Python would have involved changing a lot of Python's internals I soon discarded the library patching idea as those could be worked around by injected code directly invoking syscalls. It didn't take long for me to notice that I have to dig deeper. The idea of ujail was born and after coming up with the proof of concept this seems to be a viable solution.

Now ujail is not only about protecting a web server from its web applications, but could do a lot more, for example:

• Creating a sandbox for untrusted code (socket&file i/o emulation)
  
• Implementing some sort of personal firewall (socket-call only emulation)
• Testing applications that perform low-level system operations (read: package managers and friends, filesystem emulation)

I am sure you can come up with even more use-cases. What should be noted is that emulating a system call does not mean that one necessarily needs to emulate the whole filesystem. What can be done, for example, is patching through access to common files (libraries, executables, etc.) whilst maintaining a virtual filesystem for data that will eventually be modified. A copy-on-write approach is possible too, for example. There are multiple methods with which the multiple filesystem could be implemented, the most common would probably be using a state directory.

FAQs

There have been some questions about ujail in comments to my first post which I would like to answer. Also, I have been thinking about things that are different about ujail compared to other virtualization techniques. Feel free to add additional questions either in a comment or drop me an email: debian at sp dot or dot at.

1. Could you change the license of ujail to ... ?
   
   Not likely to happen. The proof of concept's license is GPLv3 and the actual code's license will be too. However, ujail is a userspace application that does not need any modifications to the kernel so there should be no problems with porting ujail from GNU/Linux to any other system.
   
   
2. Does ujail work on operating systems other than GNU/Linux?
   
   Not yet. If it's technically possible to implement the technique on other operating systems I would be happy to accept patches.
   
   
3. Do I need to patch my kernel for ujail to work?
   
   No, ujail is running in userspace. The only thing it needs is Linux with support for PTRACE_SYSEMU.
   
   
4. How is this approach different from using LD_PRELOAD?
   
   With LD_PRELOAD one can replace library functions, but malicious code could still directly invoke syscalls, working around this protection completely. Also, statically linked binaries cannot be restricted with LD_PRELOAD.
   
   
5. How is this approach different from user-mode-linux?
   
   User-mode-linux (UML) works by emulating a full kernel in userspace and allows you to virtualize a whole Linux instance (including a new init process, etc). ujail is about providing a way of restricting a single process (and its childs) inside a running system in terms of access to syscalls and the partial emulation of those.
   
   
6. How is this approach different from linux-vserver?
   
   Linux-vserver is a kernel patch and runs in kernel space, as opposed to ujail, which works in userspace.
   Also, linux-vserver works similarly to user-mode-linux, providing a fully virtualized Linux instance.
   
   
7. Does the account running ujail need any special privileges?
   
   No, the only restrictions that apply are those of ptrace.
   
   
8. Where is the code?
   
   Right now ujail is in a planning phase, and only the proof of concept code has been written and published. The actual ujail code is yet to be written and the code will be hosted on launchpad.net.
   
   

Proof of concept, part 2

An anonymous person (who were you stranger?) added a comment to my first post, suggesting "Also, why patch the process rather than just modifying its state and trapping into the kernel?". I have had a look at this approach earlier, but it didn't work out. However, I decided to give it yet another try and created a second proof of concept. That code does not require patching any code, but only modifies the instruction pointer (eip) and the first register (eax). This should be a lot faster than patching the code.

Technically the new main loop works by calling PTRACE_SYSEMU and waiting for a notification. It then saves the instruction pointer and switches to PTRACE_SYSCALL. As before it waits for the emulated syscall to exit and at this point sets eax from orig_eax and decreases the value of the instruction pointer by the size of the "int $0x80" instruction. Another call to PTRACE_SYSCALL resumes the process. The next event is the process actually entering the real syscall and yet another one leaving the syscall again. These are resumed by PTRACE_SYSCALL and PTRACE_SYSEMU respectively. So, comparing this with the first approach we are only modifying two registers now, instead of writing to the TEXT area of the running process.

Thanks should go to the anonymous commenter for making me give this approach another try.

Questions? Criticism? More ideas? Want to contribute?

Coming to an end I would yet again like to let you know that I am open for questions, criticism, more ideas and contributions in general. So if you are interested in this topic come join the discussion by either dropping me an email, writing a comment to this post or replying to this post on your own blog.

Mika Tiainen reported the Debian bug #560000 on Tuesday December 8th, against the ferm package. Bug #550000 was reported as of October 7th 2009. So, again, no matter what, we're still keeping up with the very regular "10,000 bugs in 2 months" pace This time, I would like to highlight a specific bug that missed to be #560000 by very few hours: namely "#559980: aptitude: Totally broken on GNU/kFreeBSD". Please read that bug report and take time to send Cyril "KiBi" Brulebois a nice "Chapeau" ("hat off") for the time he invested in analyzing this bug and providing a good workaround. Update: KiBi told me that his workaround is broken. Still, the "hat off" still stands as what impressed me is more the nice investigation work than the workaround itself. Of course, admittedly, Cyril is not alone doing such work but it never hurts telling good people they are doing good work. To all Planet readers: <Teletubbies mode ON>from time to time, please remember putting more light on those people doing great and sometimes obscure work in our project</Teletubbies>. After all, blogs are not only about ranting, right? :)

I just had the following conversation with my linux desktop:

Me: "Hi, I'd like to use my new printer please." Computer: "Do you mean this HP Laserjet CP1515n on the network?" Me: "Erm, yes I do." Computer: "Good. You've got a test page printing as we speak. Anything else I can help you with?"

Sadly I don't have any alternative modern operating systems to compare it to, but having done similar things with linux over the last 12 years, I'm impressed with how far we've come. Thank you to everyone who made this possible.

Dear lazyweb: I am in a dreadful situation! I need to secure e-mail communication between five types of users:

• Outlook 2003 users who receive their mail by POP3 from Exchange,
• Thunderbird users downloading mail with POP3,
• Apple Mail users downloading mail with POP3,
• Webmail users (Squirrelmail and Roundcube),
• and a bunch of Unix folks using proper clients.

To make matters worse: there is no common provider or server infrastructure, so the solution must work across providers and mailboxes.

Requirements

• Human error should be anticipated and prevented.
• Mail between all parties must be encrypted (and signed) automatically. If encryption is not possible, the mail must not be sent. This includes the situation where not all mail recipients keys are known;
• Ideally, one can define rules (using wildcards or regular expressions) to enforce certain policies.
• Mail to other parties may be signed, and it would be good to be able to turn this on and off by default;
• The MIME standard should be employed so that the mail body is not altered, and attachments can be seamlessly encrypted too. Existing MIME parts should be encapsulated as children of a new multipart tree;
• Incoming mail should be automatically and seamlessly decrypted/verified, and the user must be alerted if the verification fails.

Ideally, the solution will be open-source. However, if proprietary software performs better, then we will gladly use that where required.

Previous attempts So far, we ve tried (and were let down by)

• GpgOL, which has very irky and brittle integration with Outlook and can only do inline signing/encryption.
• S/MIME, which seems supported by all involved clients, but Outlook does not really allow you to specify policies. Encryption seems to be opportunistic at best, which is not enough.
• GPGrelay, which is promising because transparent, but apparently messes with MIME, and I am unsure whether it can fit between Outlook and Exchange. I have yet to run real tests though. If you are a GPGrelay user, or you d like to try it (it s Windows-only), please get in touch.
• WinGEAM, but that apparently no longer exists, and neither is the underlying GEAM.

Help! Does anyone have proper suggestions over what to use? In fact, if you are interested in devising a solution, or even deploying it, there s money to pay you for those services. Write in if you are interested.