Autobuilder Summary:
138 packages built successfully. 19 packages failed to cross build. 2 packages are tagged for a manual upload. (Dependency issues - rather than break the archive, these packages will not be uploaded until relevant dependencies have been fixed and uploaded.)
Stats
87% built OK
12% failed
Notes:

1. All these packages built previously and fail at the latest versions in Debian Sid. Many could be upstream errors. All exist in Emdebian at
   previous versions (only 1 failure is known to contain bugs in the current versions in Emdebian and this only affects GUI installations. Two other GUI packages contains bugs but build OK.).
2. Some of the packages in the repository (including some of the failures) are not used in *any* of the default emsandbox configurations. Two need to be removed from the repository completely.
3. Some fixes are waiting for updates in Debian, either new uploads migrating to mirrors or pending fixes awaiting upload by me. (Probably tomorrow.)
4. The history of each package is now available via the Emdebian Autobuilder Report. The package name links to the history of previous build attempts for this package. The version string links to the repository data for the current version in Emdebian. The result of the build links to the build log.
5. A comparison with Debian unstable is constantly updated.
6. 254 source packages exist in Emdebian but only 137 are currently built by the autobuilder. The rest will be built when new versions are uploaded to Debian (in some cases, that won't be until after Lenny). If I get time, I'll add build logs for these packages.
7. The repository contains a fair number of packages that we don't currently use. This is a reflection of the problems of determining the "path" through the dependencies when starting at the bottom (glibc uClibc etc.). Bear this in mind when considering new architectures and new package sets. The process involves a lot of trial and error, particularly as cross-building potentially alters the dependency path at each iteration.

Problems

1. libselinux and libsepol have just been uploaded with a bug fix that is needed for e2fsprogs and file cross-builds, amongst others. Waiting
   for the ARM mirror to receive the new builds, hopefully tomorrow.
2. gtk+2.0 fails to cross-build because the patches now try to build the udeb which comes up against a bug in dpkg-cross. I'll be uploading the new version (including a couple of other bug fixes) tonight. (Final testing currently in progress.). The Gtk package also needs some work to run /usr/lib/libgtk2.0-0/update-gdkpixbuf-loaders so that the icons can be read in the GUI.
3. pango1.0 also needs a fix to update the pango modules. This is usually done at build time but it means running a cross-built binary. It is a minor task and not CPU intensive so I plan to do this in postinst. Without this fix, no text is rendered in the GUI, only empty glyphs.
4. xfonts-base is way too large still. More work is needed here to optimise just what is meant by the 'fixed' font for X, precisely which font files can be removed, which might be needed outside C or English locales etc.
5. Other packages not currently cross-building include: (NOTE: Some of these build logs are VERY large.)
   • adduser - needs to be removed from the repository, it is perl and we implement it via busybox.
   • cups cupsys - /usr/include/pthread.h:653: warning: '__regparm__' attribute directive ignored.
   • gcc-4.2 - needs to be removed from the repository, it no longer builds libgcc1 which was the main reason for cross-building it.
   • glib2.0 - more generated content: /bin/sh: line 2: /usr/bin/glib-genmarshal: No such file or directory
   • gnomevfs - hasn't built for ages and isn't usable anyway due to dependency issues. Currently preventing the use of gpe-filemanager. Due to be replaced by GIO in Debian.
   • libusb - build failure, so far resistant to usual fixes.
   • ncurses - build failure - uses gcc in wide char support build.
   • ntp - build failure - assembly error. authkeys.c:445: error: invalid 'asm': invalid operand for code 'w'
   • pcre3 - build failure - apparently simply unresolved symbols resistant to usual fixes.
   
   
   • slang2 - possibly needs a patch update, tries to build -pic archives and then fails.
   • xorg-server - build failure: make[4]: *** No rule to make target -L/usr/arm-linux-gnu/lib', needed by Xprt'. Stop.

Of the problems above, only problems 2, 3 and 4 (gtk, pango and xfonts-base) are "critical" as these are the only ones where the current packages are sufficiently broken that the new version is essential before Emdebian can make a "release" of a series of three root filesystems for ARM. Sizes are still larger than desired - a fix for that requires changes in glibc which I hope to investigate during DebConf.

Any help on the above issues is appreciated.

Problem-solving:
$ emsource -c $package
$ cd /path/to/$package
$ emdebuild

If you have SVN access, use 'emdebuild --svn-only' to commit your changes (even if your changes don't solve all the problems).

Without SVN access, post the result of 'svn diff ../emdebian*' to this list (or 'svn diff ../debian*' if you have added a patch for the upstream code to debian/patches/).

Platforms:
All the above is based solely on Emdebian ARM for balloon3:
Linux balloon 2.6.25.2-pxa270 #1 Sun May 18 22:38:11 BST 2008 armv5tel unknown
balloon3 in CUED case
http://balloonboard.org/gallery/300/balloon3-0v1-fpga.jpg

AFAICT no other ARM platforms have been tested.

I have a few fixes for the balloon3-config package that also needs an update in Emdebian - I've had some feedback from the touchscreen driver
upstream that we might be trying to use the wrong device (/dev/input/mice is the wrong target for the symlink, we can set whatever device we want in /etc/X11/xorg.conf and the driver will use that in preference to /dev/event0). As this is device-specific, /etc/X11/xorg.conf will be put into balloon3-config which is available via Emdebian SVN.

This (extended) weekend features: pkg-phototools

• Update libgphoto2 which is used (surprise!) by gphoto2 and others to access digital cameras. Some hours after 2.4.1-1 got uploaded, 2.4.2 got released. Got to get back to it soon
• Prepare an SVN snapshot of hugin, which is a panorama sticher, using libpano13 from panotools. People are so active with their GSOC students that the long-awaited 0.7.0 version isn t released yet, hence the snapshot. Testing is very welcome: binaries for i386 and amd64 will be available on people.d.o until the upload. Thanks to Julien Valroff and Johan Kiviniemi for their patches, and to the NMUers who took care of hugin in the meanwhile.
• Bug triaging for both of them has been quite missing lately, but hopefully that ll get fixed soon.

collab-maint

• Fix blender, which could have migrated, if ftgl wouldn t be still missing on alpha being optional:uncompiled doesn t help. It started to FTBFS: bug #490317. Against crappy upstream build system, strace -v to the rescue (-v is needed to get all variables, so that one can figure out why that execve call failed). Here s the fixing-an-RC-bug dance for Stephen Frost, as promised: \o_ /o/ \o\ _o/. The Add > Text crash (bug #487890) got fixed too, although I didn t get any ACK from upstream. Oh, and I know about this tiny bug (which appears during the byte-compilation phase). I m not very keen on trying to get it fixed myself and possibly breaking stuff, especially when upstream doesn t care, and when the following commits are looking even more messy.
• Update sunflow, a rendering system for photo-realistic image synthesis, it can now happily depend on better Java packages now that openjdk-6 made it through NEW.

More to come

• A new graphviz upstream bugfix release is available.
• As written above, a new libgphoto2 upstream release is available.
• A new module, python-ssl (bug #453101), might be nice. Python 2.6 got a real ssl module and this python-ssl module would be a backport of this new ssl module to Python versions 2.4 and 2.5. Interested people can compare the current ssl module API against the one available in the new ssl module.
• And the sponsor queue is growing, too.

While building and testing LiveCDs, QEMU and VirtualBox can speed up development cycles until a bug is encountered: apt-get update hanging on a rename operation. Maybe aufs is at fault? Its author then asks for some data, including what happens when some SysRq keys are pressed. What they are is already quite extensively explained in Documentation/sysrq.txt (Linux sources), but I d like to point to a nice trick for people using emulation and virtualization tools (ever tried to send Ctrl+Alt+Delete to a virtual machine?):

# echo $letter > /proc/sysrq-trigger

where $letter is any of the supported SysRq keys. As an example:

# echo d > /proc/sysrq-trigger
# dmesg   tail -1
[558193.423427] SysRq : HELP : loglevel0-8 reBoot Crashdump tErm Full kIll
saK showMem Nice powerOff showPc show-all-timers(Q) unRaw Sync showTasks
Unmount shoW-blocked-tasks

So recently there have been a few posts by people discussing the idea of distributed bug reporting systems. This is topical, becuse I've been working on something vaguely related - a support system. Why is a support system, or ticketing system, related to a bug tracker? To answer that you must first clarify what you mean by a support system (or a bug tracker for that matter). There are two distinct types of support systems:

"Full"

This is a system which does "everything". Each submitted support, or bug, request has an associated status, severity, priority and work log. It might be assigned to multiple people through its lifetime, and it might be moved around various internal queues. Example: Request Tracker.

"Minimal"

A reported ticket is an email submission. A "ticket" from start to finish is nothing more than a collection of mails upon a particular topic - there is no assigned "owner", no "priority", no object-specific attributes at all.

I've neither the time, patience, or desire to create any system like the first one. But I've become increasingly dissatisfied with my current support system, roundup, for various reasons. So I need something new. Previously I ruled out several support systems and most of my objections still stand, although I admit I've not really looked again. I will certainly do so shortly. So what have I done? Well I figure I care very little about queues, priorities, reports, and all that stuff. (On the basis that priority is mostly in the ticket itself, and that I'm the sole recipient of the submissions. Previously I had a partner to share them, but these days just me.) I want something that is basically e-mail centric. That reduces the functionality of my support system to two distinct parts:

Ticket Submission

An email to sumbit@example.com should result in three actions:

• A message being sent back to the submitter. "Hey got your ticket. We'll fix it. Love you long time.". (Set the reply-to address appropriately!)
• A message to the site admin(s) saying "Hey, you've got a new ticket submission. Deal."
• A new ticket being created/stored somewhere.

(There are additional nice things to have - such as SMS alerts outside 10:00-17:00, etc, but those are trivial bolt-ons.)

Ticket Updates

When a mail comes in to "ticket-XXXX@example.org" - which was setup in the submission process, or when a mail arrives with subject "[issueXXXX]" we need to append the correspondance to the existing ticket. If that ticket doesn't exist we report an error. If the ticket is closed we re-open it.

So, what do we have? A script that is conceptually simple, and can be invoked via a pipe transport of Exim4. A script that just reads the submitted email from STDIN and only has to decide a couple of things based pretty much on the contents of the "To:" and "Subject:" headers. Simple, no? OK it was actually amazingly simple once broken down. The amazing part is that it all works. I figured that I'd manage new tickets by writing them to mbox files - simple to do. Simple to understand. So the process goes:

• New email arrives to "submit@example.org"
• /home/steve/tickets/1 is created with the received message written to it.
• I get a mail to steve@steve.example.org.uk saying "new ticket!!!".
• I reply to the ticket by opening /home/steve/tickets/1 in mutt - where my muttrc ensures that when I reply the from address is the ticket address, and there is an automatic CC.
• The cycle turns, and more discussion happens until we're all happy the ticket is "done"..
• A mail to ticket-xxxx-done@example.org" closes the ticket by moving it from ~/tickets/ to ~/tickets/archived/.

There are a couple of helper scripts:

• ticket-close - close a ticket manually.
• ticket-list - show all open tickets
• ticket-view - open a ticket in mutt

But basically one script and mutt does it all. So far it's been tested and it is rockin'! (Look at me, hangin' with the cool kids!) Obviously it is pretty Steve-specific, and there is only a toy CGI process for viewing history online, but I'm actually feeling pretty good about it. Once I've closed all my existing tickets I will probably migrate over to it. At least this handles (read: ignores) MIME - which makes it a clear winner of roundup, which just eats, bounces, or corrupts submitted multipart messages. ObQuote: Flash Gordon

Yay, www.gomeat.com! I especially like the gopher that pops up shortly after the rest of the table of meat appears. The fact that he's advertising sausage makes me think that we've truly reached The Restaurant at the End of the Universe.

I'll still take the green salad, thanks.

I've been working hard on a new project for the last couple of months, which I'm glad to be able to share with you now. For the impatient: today my company Control Yourself, Inc. is launching Identi.ca, a new microblogging service. (There's a press release on the Control Yourself site). Users can post short messages about themselves to Identi.ca, which are then broadcast to friends in their social network using instant messages (IM), RSS feeds, and the Web. The difference between Identi.ca and other services like Twitter, Jaiku, or Pownce is that it is Open Source software. I tried to meet the requirements of the Open Service Definition -- Free Software and Free Data. In the same spirit, Identi.ca supports open standards like OpenID and OpenMicroBlogging, to integrate with other Web sites and services. A little background: in March of this year, I was privileged to take part in a summit at the Free Software Foundation about open network services. The summit brought together a number of people involved in Open Source and Open Content to discuss problems with "software as a service" and how to solve them. More and more, people are depending on Web sites and other network services "in the cloud" to do much of their computing tasks. Examples: using Yahoo! Maps instead of a desktop mapping application, or using Google Docs instead of Microsoft Word. Software-as-a-service can be extremely convenient -- data on remote servers stays up-to-date, software gets updated regularly, and you can use different computers or mobile devices to get at the same data. The sacrifice, however, is user autonomy. If you decide that Google Docs doesn't work the way you want, you can't tinker with the software and fix it. If you want to share a map on your Web site, you need Yahoo!'s permission. If you want to use a new social networking site, you have to re-enter all your personal data and re-invite all your friends. The data and code belong to someone else, and they're hidden behind servers that you, the user, aren't allowed to touch. There aren't a lot of clear answers to this. But our loosely-organized summit group is moving forward to promote and support Free/Open Network Services. These are Web sites (or other services) that use Free/Open Source software (with the source available) and provide Open Content data (except for data that users mark as private). There are a lot of them popping up -- like OpenStreetMap and Wikipedia. Others are close on the software side, although the data side is a little less clear -- like Wordpress.com, Reddit, or LiveJournal. After the summit, I wanted to try to see what I could do personally to further this mission. I think several of the sites I work on now -- like Vinismo and Keiki -- would qualify. But I also wanted to break some new ground and challenge people's assumptions about software services. And the services I was using, and getting invited to, the most were microblogging sites. Clearly that was the area to dig into further. To do it, I started Laconica, the software underlying Identi.ca. It's AGPL'd PHP using MySQL as a backend -- probably the most accessible platform on the planet right now. I used lots of existing libraries to make development easier, and I hired a great designer (Montreal's Marie-Claude Doyon) to give the site a professional look. Almost as important as the Open Source and Open Content is the distributed nature of Identi.ca. I designed an open protocol called OpenMicroBlogging, based on OAuth, to make it easy for users on one Laconica server to subscribe to notices by users on another server. I hope this will make the service more robust, develop a rich and diverse social network, and stimulate innovation. Because in the end, that's the Internet that we all want to be part of. As a society we rejected "walled gardens" like AOL, Compuserve, and MSN in the early 90s in favor of the distributed, open nature of the World Wide Web. And I think that the new walled gardens like Facebook and Google, need to be replaced with open protocols and standards. Will Open Network Services be the basis of "Web 3.0", the next stage of Web culture? I truly think so, but that's still an open question. People have been using Identi.ca for a few weeks now, although I've asked that folks wait until the software was more mature before posting public links. Today I'm lifting that embargo and asking friends and colleagues to join and participate in the conversation. I hope that people who are sympathetic with the ideals of Identi.ca will take the time to blog about it, invite their friends, and start using the site regularly. And of course I'd love to get feedback on bugs, requested features, and ideas for the future. Please also subscribe to me on the site -- see http://identi.ca/evan -- so I can see who's out there. There are still so many standard services on the Web that I'd like to see open sourced, open content, and distributed -- advertising, storage, image and file sharing, comments, portal pages, social news, social bookmarks, search engines. There's a real business potential for taking the lead in these areas, and I hope more people jump in.

The Age has an interesting article about proposed DNS changes [1]. Apparently ICANN is going to sell top level DNS names and a prediction has been made that they will cost more than $100,000 each. A suggestion for a potential use of this would be to have cities as top level names (a .paris TLD was given as an example). The problem with this is that they are not unique. Countries that were colonised in recent times (such as the US and Australia) have many names copied from Europe. It will be interesting to see how they plan to determine which of the cities registers names, for the .paris example I’m sure that the council of Paris Illinois [2] would love to register it. Does the oldest city win an international trademark dispute over a TLD? The current situation is that French law unambiguously determines who gets to register paris.fr and someone who sees the URL will have no confusion as to what it means (providing that they know that fr is the ISO country code for France). As well as city names there are region names which are used for products. Australian vineyards produce a lot of sparkling wine that they like to call Champagne and a lot of fortified wine that they like to call Port. There are ongoing battles about how these names can be used and it seems likely to me that the Australian wine industry will change to other terms. But in the mean-time it would be interesting if .champagne and .port were registered by Australian companies. The fuss that would surely cause would probably give enough free publicity to the Australian wine industry to justify an investment of $200,000 on TLDs. The concern that is cited by business people (including the client who forwarded me the URL and requested my comments) is that of the expense of protecting a brand. Currently if you have a company named “Example” you can register example.com, example.net, and example.org if you are feeling enthusiastic. Then if you have a significant presence in any country you could register your name in the DNS hierarchy for that country (large companies try to register their name in every country - for a multinational registering ~200 domains is not really difficult or expensive). But if anyone can create a new TLD (and therefore if new ones are liable to be created at any time) it becomes much more difficult. For example if a new TLD was created every day then a multi-national corporation would need to assign an employee to work full-time on investigating the new TLDs and deciding which ones to use. A small company that has an international presence (IE an Internet company) would just lose a significant amount of control over their name. I don’t believe that this is as much of a concern as some people (such as my client) do. Currently I could register a phone line with a listed name indicating that it belongs to the Melbourne branch of a multi-national corporation. I don’t expect that Telstra would stop me, but the benefit from doing this would be minimal (probably someone who attempted fraud using such means would not gain much and would get shut down quickly). I don’t think that a DNS name registered under a .melbourne TLD would cause much more harm than a phone number listed in the Melbourne phone book. Incidentally for readers from the US, I’m thinking of Melbourne in Australia not a city of the same name in the US - yet another example of a name conflict. Now I believe that it would be better if small companies didn’t use .com domains. The use of country specific names relevant to where they work are more appropriate and technically easier to implement. I don’t regret registering coker.com.au instead of some name in another country or in the .com hierarchy. Things would probably be working better right now if a .com domain name had always cost $100,000 and there were only a few dozen companies that had registered them. But we have to go with the flow sometimes, so I have registered RussellCoker.com. Now when considering the merit of an idea we should consider who benefits and who (if anyone) loses. Ideally we would choose options that provide benefits for many people and losses for few (or none). In this case it seems that the suggested changes would be a loss for corporations that want to protect their brand, a loss for end-users who just want to find something without confusion, and provide more benefits for domain-squatters than anyone else. Maybe I should register icann.port and icann.champagne if those TLDs are registered in Australia and impersonate ICANN. ;)

• [1] http://www.theage.com.au/news/web/rule-changes-to-spark-domain-name-goldrush/2008/06/27/1214472719636.html


• [2] http://parisillinois.org/

Share This

I wanted to be able to not only bind with the normal dn, but also to attributes. This means I e.g. have an attribute mail, and want the people to be able to login with their mailaddress as username. Stephen Gran gave me some valuable hints to using the rwm-rewriting engine. After some time, I ended up with this setup:

overlay rwm
rwm-rewriteEngine on
rwm-rewriteMap ldap attr2dn "ldap://127.0.0.1/ou=myorg?dn?sub"
rwm-rewriteContext bindDN
rwm-rewriteRule "^anyid=([^,]*@[^,]*)" "$ attr2dn(mail=$1) " ":"
rwm-rewriteRule "^anyid=([^,@]*)" "$ attr2dn(uid=$1) " ":"
rwm-rewriteRule "^(uid=[^,]*)" "$ attr2dn($1) " ":"
rwm-rewriteRule "^(mail=[^,]*)" "$ attr2dn($1) " ":"

The only thing that doesn't work is to make rwm using ldap version 3 to log into itself, so I had to allow read-only access to the relevant attributes from peername.ip=127.0.0.1 - but well, I can live with that. Update: Added anyid for not thinking in client code, and made sure only the start of entries is used.

We recently joined The Club of Mountain View, because it just happens to be around the corner, and we both want to try and get back into some semblance of shape. The Club has pretty reasonable facilities. It has a large cardio room, a large weights room, a group exercise room where they do a number of classes, and a spinning room. It also has three racquetball/handball courts, as well as an indoor basketball court. Pretty much all of the facilities are included in the monthly membership, so Sarah went and booked a racquetball court this evening, and we had a bit of a whack. We didn't have a clue how to play, so it was just basically half an hour of belting the ball around, and I have to say, I really liked it. I haven't played squash since high school, but didn't enjoy it, because I was more used to tennis, and constantly misjudged where the racquet head was, hence missing the ball. I never really liked the characteristic of a squash ball either. I really like tennis, but I have habit of getting carried away and belting the tripe out of the tennis ball, either sending it completely out of the court (over the fence) and far away, or at the very best well and truly past the back line of the court and into the fence. Racquetball seems perfect for me. I can belt the living daylights out of the ball. It can't get lost. The racquet is short and reasonably large. There's a very satisfying thwack sound to boot. In short: I like it.

I spent Saturday at BarCamp Belfast. There were more people than I expected; I'm no good at judging exact numbers but the wiki lists 62. As it turned out not everyone ended up talking; this worked out well for me because I don't think I'm Web2.0 enough (is that a bit ironic given I'm writing this on a blog?). I don't really do user interfaces or website stuff and that seemed to be the primary focus of a lot of the attendees. Nice to know there's a fairly active crowd in
Belfast though; I discovered the existence of Belfast Open Coffee which I'll have to try and make at some point.

I went to at least the following talks::

Gerard McBreen on Digital Circle & Adobe Flex: Quite a cute demonstration of the Flex framework for Flash. I'd have been more convinced if Flash could be considered truly cross platform; Adobe can't even manage a 64 bit client yet and Gnash is far from ready.

Daniel McLaughlin on Nagios: Not really anything I didn't already know, but always interesting to see how other people are using these things to see if there's any nice tricks you've missed.

Andrew Gribbon from Exile Coffee on speciality coffee: This was really interesting. A complete tangent from IT but enjoyable and I must buy some roasted beans from him (I've been meaning to place a Roast and Post order for ages anyway).

Brian O'Neill on freelancing: Tailored towards the web market in my opinion, which is fair enough but things like aiming to never employ anyone and stay a one man operation doesn't really work if you're doing something that a customer wants supported around the clock. Or even just during the working day if you're crossing time zones. Interesting to hear that Brian had run an agency in the past but preferred working on his own these days. I kinda feel I've gone a bit the other way. :)

Linux Hardware workshop: Not really a lot of interest here; a clutch of EEEs, an N800 and a Debian box or two. However I had a chat with David Newman about his MythTV setup which convinced me I really should give it another try. After I get someone to install a bigger aerial in the hope of stabilising our Freeview reception.

Brian Cleland on Linux Trends: Talking about lots of Linux takeup by big names and general market adoption eg the recent selection of cheap subnotebooks. Main thing of interest was OpenPandora which I hadn't heard of before; OMAP3 based handheld device running Linux with a 800x480 4.3" screen. Aimed as a gaming device, but has a keyboard and bluetooth/wifi so has potential as a PDA as well. Hopefully the build quality will be better than the GP2X I saw.

Andy McMillan on coffee shop working: I've thought about this in the past myself; I worked from Cafe Java in Norwich a few times while doing Black Cat, but in general didn't find it as conducive to work as I'd hoped. He mentioned Coworking Belfast which is an idea Tristam has talked about in the past, in terms of people who work from home getting to have some form of social contact with like minded individuals, without having to go to the expense of a whole office. It'll be interesting to see if it takes off.

Darragh Doyle and Grannymar on blogging: I think everyone in the audience already had a blog of some description. I don't really consider my blog a social forum; it's not something I expect to have a long conversation on, just ask a quick question or discuss something
I've done that I think might interest people or give a general "this is what's happening at present" post. Blog commenting systems are all a bit crap to keep up anything sustained. Someone needs to write a blog<>nntp gateway that correctly cross posts comments as well. I suppose the issue with that is then everyone needs to run a news server, or all agree on
using the same one. Fine for groups of people who know each other but not if you want to read a dozen blogs from different areas in a single client that'll let you properly follow conversations. Mind you, people seem to cope with forums and I don't really understand how. Supporters of news and mailing lists seem to be dwindling. :(

Anyway, that was my first BarCamp. I wasn't quite sure what to expect, it was a bit more Web2.0 than I'd have liked (which is fair enough, but I'd have liked to have seen some talks about low level bits really) but I'd go again and will keep an eye out for the next one. And hopefully I'll see some of the people I met there at the BLUG meeting this Wednesday (Tap House in Lower Crescent from 6pm for anyone who's not on the mailing list).

Yay! Thanks to Lennart people are actually talking about how VCS diversity is a problem. And Lennart thinks that maybe, instead of the slow drift toward VCS convergence and interoperability that I've been expecting, we might instead reach a point where everyone decides that there can be only one. I'm reminded of 1993. Using the internet at that time involved using a mishmash of stuff -- Telnet, FTP, Gopher, strange things called Archie and Veronica. Or maybe this CERN "web" thing that Tim Berners-Lee had just invented a few years before, but that mostly was useful to particle physicists. Then in 1994 a few more people put up web sites, then more and more, and suddenly there was an inflection point. Suddenly we were all browsing the web and all that other stuff seemed much more specialised and marginalised. You can argue that this was essentially a popularity contest, that Worse Is Better suggests we didn't pick the best solution; that the web/git, at its core, sucks, or that gopher/svn rulez. Heck, I've espoused most of these positions myself. But the reality of network effects can be very strong, and reality can trump all these ideal-world arguments whether we like it or not. Previously: The New Portability Nightmare

I was looking for a Python lexer and parser, and found out that antlr can emit Python code with only minor twiddles of the input grammar.

The antlr site has a "Hello World" type of grammar for testing it out in Java: http://www.antlr.org/article/cutpaste/index.html

What follows is that page ported to Python and Debian/Ubuntu. On a Debian-derived system:

$ sudo apt-get install antlr

Create a file called "t.g" with the following contents:

options  
	language=Python;
 
class P extends Parser;
startRule
    :   n:NAME
         print "Hi there, "+n.getText() 
    ;
class L extends Lexer;
// one-or-more letters followed by a newline
NAME:   ( 'a'..'z' 'A'..'Z' )+ NEWLINE
    ;
NEWLINE
    :   '\r' '\n'   // DOS
        '\n'        // UNIX
    ;

Because antlr isn't in the CLASSPATH by default, the maintainer has included a "runantlr" script, which handles this for you. So,

$ runantlr t.g

This will create L.py, P.py and PTokenTypes.txt.

Now create main.py:

#!/usr/bin/python
import sys
import L
import P
l = L.Lexer(sys.stdin)
p = P.Parser(l)
p.startRule()

And run the resulting file:

$ python main.py
Jeff
Hi there, Jeff
$

It’s a common practice when hosting email or web space for large numbers of users to group the accounts by the first letter. This is due to performance problems on some filesystems with large directories and due to the fact that often a 16bit signed integer is used for the hard link count so that it is impossible to have more than 32767 subdirectories. I’ve just looked at a system I run (Bluebottle anti-spam email service [1]) which has about half a million accounts and counted the incidence of each first letter. It seems that S is the most common at almost 10% and M and A aren’t far behind. Most of the clients have English as their first language, naturally the distribution of letters would be different for other languages. Now if you were to have a server with less than 300,000 accounts then you could probably split them based on the first letter. If there were more than 300,000 accounts then you would face the risk of having there be too many account names starting with S. See the table below for the incidences of all the first letters. The two letter prefix MA comprised 3.01% of the accounts. So if faced with a limit of 32767 sub-directories then if you split by two letters then you might expect to have no problems until you approached 1,000,000 accounts. There were a number of other common two-letter prefixes which also had more than 1.5% of the total number of accounts. Next I looked at the three character prefixes and found that MAR comprised 1.06% of all accounts. This indicates that splitting on the first three characters will only save you from the 32767 limit if you have 3,000,000 users or less. Finally I observed that the four character prefix JOHN (which incidentally is my middle name) comprised 0.44% of the user base. That indicates that if you have more than 6,400,000 users then splitting them up among four character prefixes is not necessarily going to avoid the 32767 limit. It seems to me that the benefits of splitting accounts by the first characters is not nearly as great as you might expect. Having directories for each combination of the first two letters is practical I’ve seen directory names such as J/O/JOHN or JO/JOHN (or use J/O/HN or JO/HN if you want to save directory space). But it becomes inconvenient to have J/O/H/N and the form JOH/N will have as many as 17,576 subdirectories for the first three letters which may be bad for performance. This issue is only academic as far as most sys-admins won’t ever touch a system with more than a million users. But in terms of how you would provision so many users, in the past the limits of server hardware were approached long before these issues. For example in 2003 I was running some mail servers on 2RU rack mounted systems with four disks in a RAID-5 array (plus one hot-spare) - each server had approximately 200,000 mailboxes. The accounts were split based on the first two letters, but even if it had been split on only one letter it would probably have worked. Since then performance has improved in all aspects of hardware. Instead of a 2RU server having five 3.5″ disks it will have eight 2.5″ disks - and as a rule of thumb increasing the number of disks tends to increase performance. Also the CPU performance of servers has dramatically increased, instead of having two single-core 32bit CPUs in a 2RU server you will often have two quad-core 64bit CPUs - more than four times the CPU performance. 4RU machines can have 16 internal disks as well as four CPUs and therefore could probably serve mail for close to 1,000,000 users. While for reliability it’s not the best idea to have all the data for 1,000,000 users on internal disks on a single server (which could be the topic of an entire series of blog posts), I am noting that it’s conceivable to do so and provide adequate performance. Also of course if you use one of the storage devices that supports redundant operation (exporting data over NFS, iSCSI, or Fiber Channel) then if things are configured correctly then you can achieve considerably more performance and therefore have a greater incentive to have the data for a larger number of users in one filesystem. Hashing directory names is one possible way of alleviating these problems. But this would be a little inconvenient for sys-admin tasks as you would have to hash the account name to discover where it was stored. But I guess you could have a shell script or alias to do this. Here is the list of frequency of first letters in account names:

First Letter	Percentage
a	7.65
b	5.86
c	5.97
d	5.93
e	2.97
f	2.85
g	3.57
h	3.19
i	2.21
j	6.09
k	3.92
l	3.91
m	8.27
n	3.15
o	1.44
p	4.82
q	0.44
r	5.04
s	9.85
t	5.2
u	0.85
v	1.9
w	2.4
x	0.63
y	0.97
z	0.95

• [1] http://www.bluebottle.com/

Share This

It happens from time to time that bug reports I file receive attention, but I don t notice because our bug tracking system still does not auto-subscribe bug submitters to their own bugs (see bug #37078 and bug #351856). I thus decided to take the matter into my own hands. Just in time, before I started hacking this up myself, I found Justin Pryzby s procmail recipies, which are installed to /usr/share/doc/devscripts/examples/bts_autosubscription.procmail by the devscripts package. The result is available in my mailfilter git repository. So far, I only auto-subscribe in response to bugs I file; Justin also auto-subscribes to bugs he manipulates via the control bot. For completeness, I also wanted to subscribe to all bugs that I have submitted. This turned out to be easier than I thought, thanks to bts in the devscripts package; note the sleep instruction in the loop to prevent hammering the system:

bts select submitter:madduck@debian.org \
    while read bugno; do
      echo X-debbugs-autosubscribe: madduck \
          sendmail -f madduck@debian.org $ bugno -subscribe@bugs.debian.org
      echo subscription to \#$ bugno  sent
      sleep 30
    done

NP: The Dukes of Leisure: The Dukes of Leisure

I normally don’t play computer games, never been a big fan. Once in a while, though, I will try one, normally when some irc channel I’m in becomes a fan of it. This afternoon Miriam introduced us to Krank. And now I’m hooked (though I’m not sure for how long, as the title hints). There are basically four kinds of objects: two you can move, and two you can’t. The objective is to move the movable ones onto the static ones, in a way that makes the static ones disappear (according to the rules here). I must say, I enjoy levels with links and anchors very, very much. Ah, and Miriam made packages available. (The code is Python and is public domain; the images are mostly free-for-non-commercial, hence the “-nonfree” suffix.)

Even though I ve dealt with IPv6 for almost a decade, have delivered presentations, and given multi-day courses on IPv6 security aspects, I ve never actually added IPv6 to my own server/home network infrastructure because it seemed that Linux and/or Debian just weren t ready for it. This seems to have changed (although there are still a number of problems) and in less than a day, I put a few of my machines online. In the following, I d like to share with you how I did it.

Kernel versions and stateful connection tracking Unfortunately, I have to start off with some bad news: even though Debian etch, our current stable release, which uses a Linux kernel version 2.6.18, speaks IPv6, I cannot recommend it for deployment, as the 2.6.18 kernel does not support proper stateful connection tracking for IPv6, and thus makes it impossible to firewall hosts in a sensible manner (I always add local packet filters to all my hosts, and if only to guard against the situation when a user installs a malicious programme to listen on a high port). Of course, it is possible to configure a packet filter statelessly in an acceptable manner once you know the use case, so do with this information what you wish; I prefer to stay general for now. For me, a remedy is almost around the corner: the 2.6.24 kernel seems to support stateful connection tracking for IPv6, and it s even available for etch as it will be included in the upcoming etch-and-a-half release. I simply ended up using the kernel packages pre-release, and so far have not had a problem with it. To do so, add the following line to your /etc/apt/sources.list, making sure to use a close archive mirror:

deb http://ftp.xx.debian.org/debian etch-proposed-updates main

I then just upgraded the system and pulled in all proposed updates. As that may have let in software that won t be part of etch-and-a-half, or even lenny, you may want to pin the archive and only upgrade the kernel packages, by adding to /etc/apt/preferences (replacing amd64 with your architecture):

Package: *
Pin: release a=proposed-updates
Pin-Priority: -1
Package: linux-image-2.6.24-etchnhalf.1-amd64
Pin: release a=proposed-updates
Pin-Priority: 600

Alternatively, you could use the 2.6.24 linux kernel packages on backports.org.

Xen and IPv6 One drawback of switching to 2.6.24 is that you cannot run a dom0 on that machine any longer, so by practical extension, you cannot connect it to the IPv6 network with a packet filter in place. Supposedly, running 2.6.24 instances on a 2.6.18 dom0 is reported to work, however.

Configuring the packet filter The first thing I did was to configure the packet filter on each host appropriately. Unfortunately, this is harder than it should be, because to quote one of the netfilter developers when ip6tables was conceived, someone had a big bad brainfart : rather than adding IPv6 rules to your existing iptables ruleset, you have to create a new ruleset, duplicate all chains, networks, hosts, and individual rules, and maintain the two in parallel. Even though there are efforts of unification on the way, I speculate it ll take another couple of years until PF_INET6 will be fused into PF_INET and one will be able to do sensible cross-address-family packet filtering with Linux. Since I ve recently started to look (again) at pyroman, maybe the most logical way forward would be to extend it to write both, IPv4 and IPv6 rulesets from its knowledge about the hosts and networks you configured. Anyway, we want to get stuff working now! Thus, let s configure ourselves a packet filter. (Almost) all IPv6-related filtering must be configured via ip6tables (read on further down about IPv6 in IPv4 tunneling, the reason I said almost ). The following is a simple default ruleset to start with, which I put into /etc/network/ip6tables to load with ip6tables-restore:

*filter
:INPUT REJECT [0:0]
:FORWARD REJECT [0:0]
:OUTPUT ACCEPT [0:0]
:in-new - [0:0]
### INPUT chain
# allow all loopback traffic
-A INPUT -i lo -j ACCEPT
# RT0 processing is disabled since 2.6.20.9
#-A INPUT -m rt --rt-type 0 -j REJECT
# allow all ICMP traffic
-A INPUT -p icmpv6 -j ACCEPT
# packets belonging to an establish connection or related to one can pass
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
# packets that are out-of-sequence are silently dropped
-A INPUT -m state --state INVALID -j DROP
# new connections unknown to the kernel are handled in a separate chain
-A INPUT -m state --state NEW -j in-new
# pass SYN packets for SSH
-A in-new -p tcp -m tcp --dport 22 --syn -j ACCEPT
# log everything else
-A INPUT -m limit --limit 3/min --limit-burst 10 -j LOG --log-prefix "[INPUT6]: "
### OUTPUT chain
# RT0 processing is disabled since 2.6.20.9
#-A OUTPUT -m rt --rt-type 0 -j REJECT
# allow outgoing traffic, explicitly (despite chain policy)
-A OUTPUT -j ACCEPT
### FORWARD chain
# RT0 processing is disabled since 2.6.20.9
#-A FORWARD -m rt --rt-type 0 -j REJECT
# disallow forwarded traffic, explicitly (despite chain policy)
-A FORWARD -j REJECT
COMMIT

Note that this recipe is pretty much unusable on pre-2.6.20 kernels due to their broken implementation of stateful connection tracking. The ruleset should be fairly obvious, but you might wonder about my use of REJECT and allowing all ICMP after all, you ve heard for the past 30 years that ICMP is a bad hacker protocol , and Internet security is no domain for being nice to people, so to prevent any information disclosure, you should DROP connections, not let people know that they re simply not allowed. Well, to hell with all that! I don t see a single reason or attack vector that is foiled by DROP or disallowing ICMP. In fact, it s just security by obscurity, and might inconvenient at the same time. ICMP is also much more important with IPv6 than with IPv4 (it replaces ARP, for instance), and it s actually useful to be able to ping hosts, or get back informational messages on why something failed. Finally, rejecting traffic rather than dropping it doesn t suggest to a hacker that something s hidden here. Then there is RFC 4890, which almost made me puke. This document is part of the reason why I say: let s fix problems in the kernel, rather than shielding them with unreadable and unmanageable rulesets!

Getting connected If you already have an IPv6 address, you re basically ready to go, but may want to read further down on how to connect your local network to the IPv6 Internet as well. If you are searching for a provider, have a look at the list of providers with native IPv6 connectivity over at sixxs.net. If you are reading up to here, I assume you are connected to the Net with IPv4. There are two ways for you to move towards IPv6: 6to4 or by way of a tunnel provider. A Kiwi website explains how to setting up 6to4 connectivity, and thus I will concentrate only on the tunnel approach. Even though everyone can set up 6to4 in a breeze without any accounts or waiting, there are a number of security considerations, it s pretty ugly to debug (due in part to asymmetric routing), and makes your life unnecessarily difficult when all you have is a dynamic IP that changes from time to time. If you are stuck behind a NAT gateway, you cannot use 6to4 either. Thus, I prefer the tunnel approach. With the tunnel approach, IPv6 packets are wrapped up in IPv4 packets on your host, and sent to the IPv4 address of your tunnel provider, who has native IPv6 connectivity. The tunnel provider unwraps your packet and shoves the contained IPv6 packet onto the backbone. The IPv6 address you used as source address is routed to the tunnel provider, so any replies arrive at their machines, where they re again wrapped into IPv4 packets and sent to your (publicly-accessible) IPv4 address. Those IPv4 packets specify payload type 41 ( ipv6 ), which is why we need those -p ipv6 -j ACCEPT rules in the iptables ruleset. There are a few tunnel providers out there. I chose SixXS and have not regretted my choice. I shall thus assume that you do the same: sign up for an account right now, so that you have it by the time you finished reading this document! SixXS works on a credit system: tunnels and subnets cost credits, which you can accumulate by maintaining your tunnels properly. This ensures that everyone can play around, but to do more advanced stuff, you need to first display competence with the basic concepts. Your first step with SixXS will be to request a tunnel. SixXS offers three types of tunnels:

• static tunnels, for those with static IPs,
• heartbeat tunnels, for those with dynamic IPs, and
• AYIYA tunnels, for those behind NAT gateways.

Each of these tunnels have advantages and disadvantages, as everything does: the first two types of tunnels use IP protocol 41 packets to encapsulate the IPv6 packets. As such, there are security considerations involving the impersonation by spoofing, and all upstream firewalls must let protocol 41 pass. AYIYA addresses these problems by using signed packets, but that solution comes with extra computation overhead and smaller MTUs. I suggest to use the first type of tunnel that fits your situation. Debian s aiccu package can take care of heartbeat and AYIYA tunnels for you, and it can even set up static ones. During registration, you will also need to choose a PoP , which stands for Point of Presence . If your country only has a single PoP, that s the one you will end up using (unless you have a good reason for another one), but if there are more options, I strongly suggest that you go through the list of PoPs and select the one with the best roundtrip time and lowest latency from your location! Note that you must answer ping requests (ICMP echo-request) from the PoP you chose, or else the tunnel will not be created. Once your tunnel request gets approved, you ll get a /64 prefix, in which you only use two addresses: the PoP will configure the :1 address and you need to configure your host to use the :2 address on the tunnel interface. You ll also be told the IPv4 address of your PoP endpoint . Joey Hess taught me that aiccu can set up the interface for you, using the data it queries from the SixXS registration (TIC) server. I tried it, and it works. However, I prefer the pure ifupdown approach, as it makes things explicit and allows me to use the hooks for stuff like loading the packet filter. So in my /etc/network/interfaces, you can find:

auto sixxs
iface sixxs inet6 v4tunnel
  endpoint 194.1.163.40
  address 2001:41e0:ff00:3b::2
  netmask 64
  gateway 2001:41e0:ff00:3b::1
  ttl 64
  pre-up ip6tables-restore < /etc/network/ip6tables
  up ip link set mtu 1480 dev $IFACE
  up invoke-rc.d aiccu start
  down invoke-rc.d aiccu stop

Make sure to read about MTU values of the tunnel and adjust the 1480 value in the above to your tunnel settings and ISP connectivity. Also set ipv6_interface sixxs in /etc/aiccu.conf, if you are using aiccu, or else aiccu will bring up a duplicate/additional interface. If you tell it to use the same interface, it will actually execute all the same commands (which will fail), but won t report any errors. A future version will have a switch to prevent it from configuring the interface. Unfortunately, this will probably not work. The reason is that your regular IP packet filter (iptables, without the 6) doesn t let those encapsulating IPv4 packets pass, unless we tell it to; we probably want to do this early on in the chain, and also limit it to our tunnel peer, so:

iptables -I INPUT -p ipv6 -s 194.1.163.40/32 -j ACCEPT

For AYIYA, you need to open port 5072, either for UDP, TCP, or SCTP, depending on how you configured it. Also have a look at this FAQ entry on what a firewall needs to pass. If it still doesn t work, you have an upstream packet filter that needs some of those holes poked. Good luck. In most situations, the FORWARD chain does not get such a rule, since the tunnel terminates at the gateway, which routes to a native IPv6 network, or another tunnel. Allowing tunnels through a gateway is almost always a bad thing, as it would allow undetected and untraceable traffic from compromised boxes in the local network. The OUTPUT chain also does not need such a rule, if you have configured stateful filtering properly. Now bring up the interface and verify the connection:

# ifup sixxs
# ping6 -nc1 2001:41e0:ff00:3b::1
PING 2001:41e0:ff00:3b::1(2001:41e0:ff00:3b::1) 56 data bytes
64 bytes from 2001:41e0:ff00:3b::1: icmp_seq=1 ttl=64 time=74.0 ms
[...]
# ping6 -nc1 ipv6.aerasec.de
PING ipv6.aerasec.de(2001:a60:9002:1::184:1) 56 data bytes
64 bytes from 2001:a60:9002:1::184:1: icmp_seq=1 ttl=55 time=91.5 ms
[...]

Welcome to the Internet of the future!

Setting up an IPv6-capable gateway Your IPv6 connection works, but it s limited to a single address, and you do not get to specify the reverse DNS PTR record for it. Since the concept of NAT is mostly absent from IPv6 (thanks! thanks! thanks!), you will not be able to connect any other hosts to the IPv6 network. If your local network has a few hosts behind a gateway, you will need to request a subnet from SixXS and configure your gateway (which has the tunnel connection) appropriately. Don t worry, this is not really very difficult. First, request a subnet for your tunnel from your PoP via your SixXS homepage. Once approved, you will get a /48 prefix for your own use: 2^80 1.2 heptillion addresses which are yours to assign to every dust particle in your office or home, if you so desire. The way I set it up is to add the first of these addresses to your internal interface on the gateway, by adding the following two lines to the interface s stanza in /etc/network/interfaces; you will need the iproute package installed (which you should be using for everything network-related anyway):

up ip -6 addr add 2001:41e0:ff12::1/64 dev $IFACE
down ip -6 addr del 2001:41e0:ff12::1/64 dev $IFACE

Instead of bringing the interface down and up, just run ip -6 addr add 2001:41e0:ff12::1/64 dev eth0. Note the use of the /64 prefix instead of the /48 that got assigned, leaving only 20 pentillion addresses. Oh no! The reason for this is buried in the specs: basically, /48 is a site prefix, but individual networks should not be larger than /64, which is the prefix length of links in the IPv6 domain. Now is also a good time to enable IPv6 forwarding, e.g. like so:

# echo net.ipv6.conf.all.forwarding = 1 >> /etc/sysctl.conf
# sysctl -p /etc/sysctl.conf

Obviously, you will also need to change the policy on the ip6tables FORWARD chain. For now, let s just set it to accept. You should later create a proper ruleset, though!

# ip6tables -I FORWARD -j ACCEPT

Bringing IPv6 to your local network The final step is to spread the love to your local network. Refrain from selecting addresses from your subnet and assigning them to the local hosts, or wondering how to configure the DHCP server, because IPv6 does it differently: your gateway will advertise its routes (which includes a default route) to your network, and each host will pick an address based on its MAC address (unless it already has an EUI-64 address assigned. This all happens automagically, at least with current Debian and Windows machines. On the gateway, you need to install radvd and simply tell it which prefix to use on which interface. My /etc/radvd looks like this, and I won t explain it:

interface eth0
 
  AdvSendAdvert on;
  prefix 2001:41e0:ff12::/64
   
   ;
 ;

Note again how we advertise a /64 network rather than the /48 we own . You cannot advertise smaller networks if you want automatic configuration to work, and you should not use networks larger than /64 in any case. If 2^64 addresses are not enough for you, I trust you ll be able to figure out how to advertise another of your 65536 /64 prefixes in the /48 subnet to appropriate hosts. Restart radvd and run over to another host to witness how it automagically gets connected to the IPv6 network by scanning /var/log/kern.log and watching the output of ip -6 addr and ip -6 route. Try ping6ing from there! Find the dancing turtle! It should all work. If you don t like the automagic aspect of this, look into stateful configuration, using DHCPv6, as provided by dibbler-server and ?wide-dhcpv6-server.

Resolving names Take note of the IPv6 address of each host. There s a way to determine it given the host s MAC address, but this is easier (ipv6calc is also useful). You might want to let your local DNS server know by adding AAAA records in parallel to the existing A records, and possibly even adding PTR entries. If you re serious about IPv6, you can tell SixXS to delegate reverse lookups for the IPv6 addresses to your DNS servers, but you ought to refrain from polluting the DNS namespace. Note that bind9-host provides an improved host tool, which fetches all kinds of information about names, not just the one single information configured as default:

% host pulse.madduck.net
pulse.madduck.net has address 130.60.75.74
pulse.madduck.net has IPv6 address 2001:41e0:ff1a::1
pulse.madduck.net mail is handled by 99 b.mx.madduck.net.
pulse.madduck.net mail is handled by 10 a.mx.madduck.net.
% host 2001:41e0:ff1a::1
1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.a.1.f.f.0.e.1.4.1.0.0.2.ip6.arpa
domain name pointer pulse.madduck.net.

Oh, and if you re really that curious about how IPv6 addresses are computed from MAC addresses, read RFC 2464. Basically, given a prefix 2001:41e0:ff1a:: and a MAC address aa:bb:cc:dd:ee:ff, the resulting IPv6 address is obtained by:

1. inserting ff:fe into the middle of the MAC address to yield aa:bb:cc:ff:fe:dd:ee:ff;
2. flipping the second lowest bit of the first octet to yield a8:bb:cc:ff:fe:dd:ee:ff;
3. removing the odd colons to yield a8bb:ccff:fedd:eeff, the EUI-64;
4. concatenating the prefix and this result to get 2001:41e0:ff1a::a8bb:ccff:fedd:eeff.

If you find your (Windows) IPv6 addresses changing all the time, you might be faced by privacy features .

Remaining issues Even though my IPv6 connectivity works, I have two remaining issues.

Sending larger amounts of data to the network I am experiencing a curious issue where outgoing ssh IPv6 connections time out and outgoing data transfers hiccup. I have yet to find out what s going on.

Mapping names to laptops Laptops generally have two interfaces, one with a cable, and the other wireless. Both of these interfaces will have separate MAC addresses, and by extension, the laptop will have different IPv6 addresses depending on how it is connected to the local network. I want to be able to connect to laptops without knowing the medium they use to connect to the network. Unfortunately, there seems to be no feasible way. The solutions I see are:

• override the MAC address of one interface with that of the other, which is going to cause bgi problems in the case when the laptop (accidentally) gets connected to the same network twice;
• add both IPv6 addresses as AAAA records to the laptop s DNS name, which will cause random delays when connecting as the resolver may return the currently inactive address first;
• set up mobile IPv6, e.g. by following this Mobile IPv6 how-to, which would allow accessing the laptop uniformly, no matter where in the world it is. Unfortunately, Debian s support for Mobile IPv6 is severly lacking at time of writing. Also, Yves-Alexis Perez notes that this how-to is horribly outdated and promised to tend to it Real Soon Now .

The second solution works for me for now, but I am interested in the third. In response to this document, Andreas Henriksson has suggested the replace the stateless configuration (radvd) with stateful configuration, using DHCPv6. I have yet to investigate this option. Jeroen Massar suggests to unite cable and wireless into a bridged interface, which seems like a very good idea.

Credits Thanks to Bernhard Schmidt, William Boughton, and Jeroen Massar, and everyone on #ipv6/irc.freenode.org for their help over the past few weeks, and all those who fed back comments in response to this document!

I maintain a bunch of SSL certificates, mostly signed by my own site authority. Too many not to automate, but not enough to warrant heavy machinery. Here's how I do it. The configuration files Each certificate needs a config to describe what's in it. I create each of these and name it with a .cnf suffix. Here's an example:

[ req ]
prompt                  = no
distinguished_name      = server_distinguished_name
[ server_distinguished_name ]
commonName              = server.usefulinc.com
stateOrProvinceName     = England
countryName             = GB
emailAddress            = edd@usefulinc.com
organizationName        = Useful Information Company
organizationalUnitName  = Hosting
[ req_extensions ]
subjectAltName=edd@usefulinc.com
issuerAltName=issuer:copy
nsCertType            = server
[ x509_extensions ]
subjectAltName=edd@usefulinc.com
issuerAltName=issuer:copy
nsCertType            = server

Let's say this config is server.cnf. I then just type make server.pem to generate the corresponding certificate and key, signed by my local certificate authority. As I don't want to attend the startup of every service, I ensure the key is password-less. The Makefile rules Here are the makefile steps I use to generate and sign keys.

.SUFFIXES: .pem .cnf
.cnf.pem:
        OPENSSL_CONF=$< openssl req -newkey rsa:1024 -keyout tempkey.pem -keyform PEM -out tempreq.pem -outform PEM
        openssl rsa <tempkey.pem >  basename $< .cnf _key.pem
        chmod 400  basename $< .cnf _key.pem
        OPENSSL_CONF=./usefulCA/openssl.cnf openssl ca -in tempreq.pem -out  basename $< .cnf _crt.pem
        rm -f tempkey.pem tempreq.pem
        cat  basename $< .cnf _key.pem  basename $< .cnf _crt.pem > $@
        chmod 400 $@
        ln -sf $@  openssl x509 -noout -hash < $@ .0

The resultant files are:

• server.pem — contains both certificate and key in one file
  
• server_crt.pem — certificate file
  
• server_key.pem — key file
  

Some notes on these steps: my site-local certificate authority is in the directory usefulCA, along with an OpenSSL config which describes my preferences. This config was created by copying and making appropriate adjustments to the default /etc/ssl/openssl.cnf which ships with Debian. For generating certificate signing requests to ship to a commercial certificate authority, it's a bit simpler. I save the config files with a .reqcnf suffix instead, and use this rule:

.SUFFIXES: .pem .cnf .reqcnf .csr
.reqcnf.csr:
        OPENSSL_CONF=$< openssl req -newkey rsa:1024 -keyout  basename $< .reqcnf .key -keyform PEM -out  basename $< .reqcnf .csr -outform PEM

And finally, a rule I use to sign incoming certificate requests from other systems:

.csr.pem:
        OPENSSL_CONF=./usefulCA/openssl.cnf openssl ca -in $< -out  basename $< .csr _crt.pem

I offer these without warranty in the hope they might be useful to somebody. They're not much more than a transcription of a how-to into a makefile, but it's just enough technology to ensure creating certificates isn't a big nuisance. Further reading

• A more complete guide to setting up a site-local certificate authority
  

Notes Why do I bother with a site-local CA, rather than just self-sign? It lets me bypass the annoyance of SSL warnings on clients once I've installed my own CA certificate, and gives me a coarse grained level of access control: for instance, only clients with certificates signed by my CA are allowed to access the site's LDAP server. My personal next step with this is to integrate the certificate production process with my emerging Puppet recipes for managing local infrastructure.Join the conversation about this post

If you re trying to blow up an airplane, and you re hip and plan to use liquids to take down the silver bird, the following tips may be useful to you:

• Should your liquid containers not all fit into the one-litre resealable bag, just use two. Leave one of them in your bag and put the other into the plastic box through the x-ray machine. It seems like security checkers don t notice or care.
• Alternatively, if you need a few more millilitres of liquid or gel, put it in a tube or bottle and write on it Novartis, Roche, Bayer, or any other known manufacturer of pharmaceuticals; make up fancy names or use existing ones. Be creative, although you don t have to. Even though the EU regulations dictate that only prescription medicine is exempt from the volume restrictions, noone has yet confiscated my tube of Voltaren, nor questioned it, and I ve had it with me on every trip for three years, at least. If desiging your own tube is too much, empty out an existing tube and refill it. Baby food containers work too, but then you ought to bring a baby along for credibility.
• If your detonation strategy involves more than one litre of liquid, don t give up. Writing 100ml on a 200 millilitre container should fool most of the security checkers. I ve tried it, taking the label off a 75ml deodorant spraycan and putting it on a 150ml shaving cream can, and at least in D sseldorf, they seemed pleased.
• If your explosive substance s amount is indicated in weight rather than volume (like yoghurt), be prepared to lie. Should the substance put 150g on the scale, make the label read 100g; the concept of density is beyond the brain capacity of your average checker, and I found it pointless to explain to them that one gramme is very rarely the same amount as one millilitre.
• Consider flying out of a non-German airport, where they won t let you take just a deodorant spray can and nothing else without a bag; you ll also have to buy a bag for one Euro in these places, while at Zurich or Dublin airports, you get those bags for free at least. (Remind me why we pay extraordinary amounts of airport taxes again?)

Of course, if you re serious about blowing up an aircraft, you re probably not going to need any of the above, as you ll already have a more convenient way to get your substances on the plane. At the checkpoint, you ll behave like the perfect citizen abiding by all rules; you wouldn t want to arouse suspicion, now would you? PS: this post purposely avoids the use of the word terrorist . PPS: of all the great experiences in airports this week, I especially loved how passengers, who checked in at the counters (and had to present their passports there), were again checked after border control in D sseldorf, while passengers like myself, who used the quick check-in terminals, were just waved through. NP: Disturbed: The Sickness