To my horror, I recently saw this online SSH key generator. I hope nobody reading this needs to be told why this is a bad idea. However, in case you do, here are a few reasons:

• Every SSH implementation I know of - certainly all the major ones - that support public key authentication also provide a key generation utility. Even aside from all the good reasons not to, there is simply no reason why you should need to use a web-based tool in the first place.
• How can you trust the person running this site? Without implying that I know he or she is untrustworthy (I don't), and with the best will in the world, it's a big Internet with a lot of nasty people on it. Do you really want somebody you don't know in a position to keep a copy of all your private keys?
• Even if the person is trustworthy, the server running sshkeygen.com is now a giant blinking target. If lots of people use it, there is every incentive in the world for the bad guys to try to take control of it so that they can keep a copy of all your private keys. (Or, as we know from recent bitter experience, they can just give out keys from a limited set and it will probably take a couple of years before anyone notices ...)
• The front page of sshkeygen.com says that the keys are escrowed. The plain English meaning of this would be that the operator of that site keeps a copy of the private key, to be held in trust in case (presumably) you lose it and need to retrieve it. Normally this sort of thing depends on a legal trust relationship, perhaps linked to a contract. What does it mean here? Is it just a buzzword? If it isn't, then this just makes sshkeygen.com even more of a target.
• sshkeygen.com delivers keys to you over unencrypted HTTP. Yes, this is on its to-do list. That isn't really an excuse.
• Even if keys were delivered over HTTPS, that still relies on people diligently checking the authenticity of the certificate. A self-signature (as suggested as an alternative in the to-do list) would be impossible to check with any reliability; and will people who have trouble with non-web-based key generation software really be able or inclined to confirm the signature chain? Browsers typically don't enforce this very strictly, or if they do they provide fairly simple ways to bypass the enforcement, simply because so many sites have broken or poorly-signed SSL certificates, and keeping up with all the CAs is pretty hard work too.
• Furthermore, delivering private keys over HTTPS makes that SSL certificate a single giant blinking target. Might it be compromised? How would you tell? What servers would need to be compromised in order to get a copy of the private SSL key?
• Sure, Debian is in an awkward position here given the recent OpenSSL random number generation vulnerability. However, how do you know that sshkeygen.com is running on a system that doesn't suffer from this? (As it happens, I have checked, and it doesn't appear to suffer from this vulnerability - but most people won't check and won't know how to check.)

I think this is probably being done in innocent seriousness (although I kind of hope it's a joke in poor taste), and have e-mailed the contact address offering to explain why it's a bad idea.

Part of the joy of spending 3 months stoned is that my Inbox had managed to fill up quite nicely with all sorts of crap. In a desperate attempt to prune things, I've taken everything from LiveJournal and Facebook and archived them.

The LJ things are often bits where people have wished me well about the surgery and the recovery. But at over 80 conversations (some of which were multiple people), I'll just *never* get to them. I love you all for the well wishes, and I hope that I've managed to connect with all of you after them at some point.

I've also done the same with Facebook emails on the theory that Wall posts are probably stale by now (or already replied to), and the Inbox there will tell me what I haven't replied to (something like 77 posts)

I started the evening at 1350 messages, I'm now down to 497. Hopefully I'll get it down to zero over the course of this week.

Bed time!

And the packages that drove me nuts today are....root-system and mxallowd. Congratulations, people, you succeeded in turning me mad the same day by introducing debconf templates without any prior call for translations. So, another move back for translation teams. As a reward for that, please expect an *immediate* l10n NMU proposal by /me. Maybe, some day, people will *learn*. I can dream... Besides that, these packages are packages indeed coming out of NEW. I should maybe talk with the ftpmasters and see if we can enforce maintainers who introduce new packages with debconf stuff to actually:

• ask for a templates review on d-l-english
• send a call for translations

Yesterday, I looked at the status of debconf translations for the three top languages in the current ranking. French and German will make it definitely. I can fairly easily NMU packages which are slow, if needed (but for most that won't be needed, except maybe udev where Marco is.....somewhere). Of course, being the nasty person I am, I'll arrange so that French makes it before German..:-) However, Portuguese will not, IMHO. There are way too many missing translations so even though they're 96% or so, I don't think I can successfully push enough packages at the same time. Apparently, the Portuguese team has been neglecting the *needed updates* for translations they already sent in the past. Sorry, guys, you'll stay hosed around 96-99% probably. Unless some miracle happens.

In bug #480478, Robert Millan proposes adding the backports.org keyring package to Debian main so that our users benefit from it and may use packages from backports.org, if they want to. As one would expect, it turns out that some zealots (did I say 'bigots'?) followed up to mention that bpo is not an official Debian service and why should we promote the use of non official services and blah and blah and blah. There was even a mention of freeness! For $ DEITY 's sake, could some people land back on earth? Even thoug bpo is not an official service, it is one of the best services that's offered to our users. And it is maintained By DDs and not the worse of us. It is even pretty useful for us, the very pure Debian developers...just run "dpkg -s git-code" on Alioth and make your mind... I sincerely hope that the debian-backports-keyring will make its way in main. Really. We still have a few users who didn't switch to Ubuntu and we really should make some efforts to keep them unless we want indeed what some people seem to want: having the DD's as the only users of Debian.

Finally, here's the looong overdue second post on the Open Source Census. Very shortly after my initial post on my experiences with the Open Source Census I got an e-mail from one of their engineers adressing the points I had made in my post. So here are a few additions to my first post:

• You don't have to use the giant JRE including implementation, there's also a much leaner Ruby implementation of the scanning tool. Tolimar tested it and found it to be functional but also pretty time consuming.
• Load-wise the scanner comes with a --throttle option that makes it pause every n scanned files, so that your system isn't knocked out completely.
• Different from what I said there is a --help parameter, but the JRE has to come up first, so it takes some time until it outputs anything.

Tolimar was also contacted by the developer, he explained to him how to exclude individual directories using the Ruby version (not sure if it's also possible in the Java version) and how reports can be submitted anonymously. So, the privacy protection issues can also be taken care of. I was very impressed by the quick and thorough reaction to both Tolimar's and my own post and hope this post will be of some help to the project and get them some more submissions. One last note: Meike is indeed a female name. So no, he won't post a response, but she will ;)

Dear lazyweb: I ve been a satisfied IBM Thinkpad X40 user for about three years, and the fact that the X40 is still one of the most commonly seen laptops at geek conferences speaks for the machine. However, as my baby s end-of-warranty approaches, I am toying with the thought of a new laptop, with which I d also like to address some of the issues I have with the X40, namely that it supports at most 1024x768 pixels on the screen, is limited to 1.8 harddrives (which to my knowledge come in 40Gb and 60Gb variants only and are quite slow), and whose Pentium M 1.4GHz processor often reaches its limits, even though I rarely do very computationally-intensive stuff. On the other hand, I get a good 4 hours of battery run-time out of the machine. The Lenovo Thinkpad X61 would be a logical successor, but it has not won me over: it looks and feels a bit clunkier, has under 3 hours of battery time, and the screen is still limited to 1024x768 pixels. There s the Lenovo Thinkpad X300, which comes with a 64Gb solid-state disk which will weigh even less on the battery, but the the machine is still too expensive, it s first generation (meaning it ll have more problems than a second generation issue), and the options for extending the storage capacity seem limited. While visiting Penny in London, we passed by a number of electronics stores, and the Samsung Q45 and Q70 models attracted our attention. We would love to hear any feedback from owners out there (and maybe you could send us the output of lspci -vv, lsusb -vv and the file /var/log/dmesg, please?). After Lenovo has switched the Thinkpad power adapter plug format, I have very little reason not to look elsewhere The ultra-mobile Q45 (which would be a Thinkpad X-series competitor) comes with an Intel Core Solo, Duo, or Duo 2 processor, clocked at 1.6GHz, an Intel graphics card and the 3945BG wireless chipset (or its 4xxx successor), uses a 2.5 harddrive, and its 12.1 screen can display a resolution of 1280x800 pixels. It weight just under 2kg. We ve seen models with 3Gb of RAM and a 320Gb harddrive for a little over 1000 . The business class Q70 (a Thinkpad T-series competitor) has an Intel Core 2 Duo processor clocked between 1.8GHz and 2.4GHz, and its 13.1 display can also display 1280x800 pixels. It seems like it will require a bit of effort to find one with an Intel graphics card, though I am not going to get a laptop with anything else, mainly because of Intel s excellent dedication to open source. The devices are over 2kg in weight, and a 3Gb RAM, 320Gb harddrive version costs about 1400 . Does anyone have experience with these laptops and could speak for or against them? Also, what other laptops (not desktop replacements or lap warmers) might be worth looking at? You can leave a comment, or write to me. Thanks! NP: Oceansize: Frames

As you may now, the r128 and mach64 drivers were split out of ati recently. However, for Etch->Lenny transitional reasons, xserver-xorg-video-ati still depends on xserver-xorg-video-r128 and -mach64. If you're bored of having to install these packages on your Radeon machine, beware that there is now xserver-xorg-video-radeon for you in unstable. It just contains the radeon driver and does not depend on any other driver. xserver-xorg-video-ati still exists, for transitional reasons. It also provides the "ati" meta-driver which takes care of loading "mach64", "r128" or "radeon" depending on your hardware. If you actually remove xserver-xorg-video-ati, don't forget to update your xorg.conf into Driver "radeon". Update: And of course, right after posting this, I get a bug report about the missing Replaces: ati. It will be fixed in 1:6.8.191-3.

It's an ongoing drama: Flash player on PowerPC systems - you can either choose to ignore flash at all (no mozilla plugin installed) or the a non-working version of Gnash installed, which gives you no output of YouTube videos and hanging, CPU eating processes:

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
16302 ij 20 0 63964 22m 13m R 75.0 2.2 4:27.56 gtk-gnash
16308 ij 20 0 44792 13m 10m S 5.9 1.3 0:24.46 gtk-gnash
16297 ij 20 0 54172 14m 10m R 2.6 1.4 0:11.07 gtk-gnash
16301 ij 20 0 54172 14m 10m S 2.6 1.4 0:10.92 gtk-gnash

I really doubt that there will ever be a working Flash player for non-Intel compatible architectures. :-(
I'll try swf-player next, but have little hope that it will be better than cr^HHgnash....

UPDATE:
swfdec-mozilla doesn't work properly either. It hangs iceweasel just a second after playing a YouTube video and the picture is broken.

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
$

I promised to post some updates about how the Aptitude project would be going so here it is. Here’s what aptitude-gtk currently looks like : Well, nothing very special right now. It’s really only a testing interface. The final GUI will probably be different. Now you may be interesting by what’s going on behind it ? Where to start ? Aptitude is written in C++ with varying dosages of OO coding depending on the age of the code :). For the most part, the code is neat, clean and easy to understand. Sometimes, it’s overengineered: the code that implements the progress status of packages downloads and actions is exhaustive enough to cover the setup phases of a hydraulic dam, although sometimes you can still see progress bars mysteriously going backwards. Sometimes, Daniel Burrows will be happy to provide you with complimentary barf bags while explaining some ungodly oddities that have existed for years because it’s easier to remember the ritual dances to do than to make stuff behave logically. Currently Aptitude-gtk is able to execute the libapt-pkg initialization phase, load up repository lists and update lists (think “aptitude update”). The next big task will be to load up the installed packages list and display it. It involves quite a lot of code because of all the things that connect to it : incremental package searches, sorts, filters and so on. It’s been very interesting so far. By the way, the minesweeper feature is already implemented, courtesy of gnomine

While digging what was happening in bug #473557, I happened to get just in the right place of Iceweasel’s code to fix the longstanding issue of it proposing “less” and other terminal-only applications as helpers for some MIME types. The upstream bug is 6 years old. The fix is 3 lines. One of these lines is “ ” It will be in next xulrunner upload to unstable.

Ever the sucker for punishment, I decided to pick three difficult things and stick them all together: LDAP, SSL and replication. Here's how to make it go on Debian and Ubuntu. The problem You want LDAP replication to happen over the internet, and you want it to happen securely. The caveat I'm not going to tell you how to set up your LDAP from scratch here: I'm assuming you've reached a solution you're happy with and want to replicate it. The solution We're going to set up a replicating slave LDAP server, which communicates with the master over the internet via an SSL-protected connection. Enabling replication First up, the master LDAP server needs to be configured to permit replication.  The key lines to add to your slapd.conf include:

moduleload syncprov
index entryCSN,entryUUID eq
overlay syncprov
syncprov-checkpoint 100 10
syncprov-sessionlog 200

These load up the synchronization module, add indices which make sync go faster, and enable sync. For more detail see the OpenLDAP site. Next you need to add a replicator user to your LDAP database, give your replicator user access to passwords as well as general read access. To create the replicator user, I made this simple LDIF file and fed it to ldapadd.

dn: cn=replicator,dc=mydomain,dc=com
objectClass: simpleSecurityObject
objectClass: organizationalRole
cn: replicator
description: LDAP replicator
userPassword: TOPSEKRIT

Once this user is in your LDAP database, you should give it read access to passwords (I assume you've already given read access to authenticated users.) I have this in my slapd.conf:

access to attrs=userPassword,sambaNTPassword,sambaLMPassword
...
   by dn="cn=replicator,dc=mydomain,dc=com" read

To check that this works, try using ldapsearch to check that the passwords are returned:

ldapsearch -x -D cn=replicator,dc=mydomain,dc=com \
  -W   grep -i password

Enter the replicator password when prompted, and you should see the encrypted passwords from your LDAP database. Securing access Now you've got replication enabled on the master, you will want to ensure it is available on the internet only via TLS or SSL. Here's what I added to slapd.conf to enable this:

TLSCertificateFile      /etc/ssl/certs/ldapserver_crt.pem
TLSCertificateKeyFile   /etc/ssl/private/ldapserver_key.pem
TLSCACertificateFile    /etc/ssl/certs/myCA.pem
TLSVerifyClient         demand

As you will guess from the configuration, the first two lines set the SSL key and certificate the master uses (see "A little twist" below for an important note on key permissions.) The third line tells slapd where to find my site-local certificate authority (CA), and the fourth line says slapd must require any connecting client to have a valid SSL certificate signed by the site-local CA. This is important, as it provides a second layer of access control: a replicating client must connect using a certificate you signed, plus the replicator password. Before this enables TLS access, we must tell slapd which network interfaces to listen on. To do this, edit the SLAPD_SERVICES variable in /etc/default/slapd. Here's my configuration:

SLAPD_SERVICES="ldap://127.0.0.1/ ldap://192.168.0.1/ ldaps:///"

This enables regular LDAP on the loopback and intranet network interfaces, and LDAP/SSL on all interfaces, including the public internet. So, with slapd restarted we are at this situation: connections are now possible from the internet, as long as they are made over SSL with a certificate signed by our site-local CA. (In fact, you can make much finer-grained access restrictions in your configuration than I have done. Using LDAPS rather than TLS over regular LDAP is a rather broad precaution. As explained on the OpenLDAP site, the ssf= parameter can be used to require a certain level of secure connectivity on a per-user or client basis.) Setting up the replicating server
Your slave server should have the same configuration as the master, except you can leave out the bits enabling replication. Firstly, you'll need add to slapd.conf the replication configuration:

syncrepl rid=123
        provider=ldaps://ldapmaster.mydomain.com/
        type=refreshAndPersist
        searchbase="dc=mydomain,dc=com"
        filter="(objectClass=*)"
        scope=sub
        attrs="*"
        schemachecking=off
        bindmethod=simple
        binddn="cn=replicator,dc=mydomain,dc=com"
        credentials=TOPSEKRIT

Most of this I took as boilerplate from the OpenLDAP documentation. Items to note include:

• the rid is a unique 3-digit integer per slave, used to maintain sync state
• the credentials should be the password you gave the replicator user
• the type can either be refreshAndPersist, or refresh. The latter institutes a simple polling replication, whose interval you can vary with the interval parameter. In our case, we do a poll and then keep the replication search open: our client gets notified immediately when there's any new data matching the replicating search.
• the searchbase is an LDAP search matching the data we wish to be replicated.

And here's the /etc/default/slapd configuration:

SLAPD_SERVICES="ldap://127.0.0.1/"

The slave slapd exists only in this case to serve the local machine. Finally, there's the tricky bit! You need to configure slapd to connect to the master server using a certificate. I'll assume you've created and signed a key and certificate pair for your slave server (see my post Low-tech SSL certificate maintenance for more on this.) Awkwardly, the TLS configuration in slapd.conf is for the server only. Replication works as a client, and thus needs separate configuration. Furthermore, you cannot configure this globally on your machine, as the SSL certificate is a per-user only parameter (see man ldap.conf for more information on this.) Instead, we must set it in slapd's environment. Add these two lines to the end of /etc/default/slapd:

export LDAPTLS_CERT=/etc/ssl/certs/slapd.crt
export LDAPTLS_KEY=/etc/ssl/private/slapd.key

This file is sourced as a shell script by slapd's init script. Amend the path to your certificate and keys as required. Use /etc/init.d/slapd restart and you should be good to go. Finally, we want the slave server to be certain it's talking to the real master. So we also configure client connections to verify the SSL certificate of the peer, in ldap.conf again:

TLS_CACERT      /etc/ssl/certs/myCA.crt
TLS_REQCERT     demand

A little twist One gotcha to notice with both client and server is that slapd runs as the openldap user by default on Debian. Also by default SSL keys are readable only by the ssl-cert group. You'll need add the openldap user to this group, otherwise it won't be able to access /etc/ssl/private. Related articles on this site:

• Turn your world LDAP-tastic

Join the conversation about this post

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

As he’s blogged, on Monday the wonderful John Carr of Conduit and very cool bzr-mirror.gnome.org fame will be starting work at Codethink. He’s initially going to be working on our top secret project and looking at bringing Conduit to mobile devices. We’re also moving offices to the beautiful Peak District village of Hope, in the Hope Valley. I’ll post some pictures when we’ve got it all set up. Apparently the name ‘Hope’ derives from a celtic word for valley, so we’ll be in Valley valley

I won. My text will be published this fall. More information on kagge.no.

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.)

Can't find any documentation about this on the web, and it's a PITA, so here goes. Note: No pictures. I was too scared to take time out to take pictures. Disassembly is not hard at first. Three screws hidden over the battery pack allow removing the cover over the power button and wireless switch, which then frees 4 tabs that lock the top of the keyboard down. My keyboard was also taped down with double-sided tape, and glued down. This is the part I hate, both because I still haven't accepted that the common way to put together consumer electorinics is tape and glue, and because it's never possible to get it apart undamaged. I pried the keyboard up from the top, pushing under to untape/glue, and taking care of the cable. There was also a flap of plastic stuck down over the cable, which had to be peeled away. Many clips on the bottom of the keyboard hold it in place and have to be slipped out. I ended up slightly bending the arrow keys of the keyboard in yanking it out, though I think they'd still be ok-ish. Luckily I was putting in a new one. Removing the keyboard cable was strange. Its socket is not the typical kind you can life to unlock. The socket is one piece and does not move at all. I eventually just pulled the cable out of it. This is where I started to get very nervous. Replacing the cable was a PITA. You have to bend its end at a 90 degree angle, and then just line it up and press it down into the socket. Hard. And rub along it and do whatever you can to get enough force exerted down the thin cable strip to make it slip far enough into the socket to work. I booted up the laptop several times while doing this, to test if I had managed to get it working. Eventually I had. Then I very carefully reseated the keyboard, and replaced the cover and screws. Unfortunatly, the tape and glue was doing something. The new keyboard is very springy in the middle, where that held it down before. So I will have to take it apart again and put on some new double-sided tape or something eventually. Conclusions:

• Fujitsu sucks for not springing for an extra 0.01 cents for a locking cable socket.
• Laptop manufacturers in general suck for using tape and glue. (Or for building weaghty mehemoths that use better fastening systems.)
• When it's been disassembled, a lot of the magic of a laptop seeps out for me and never really comes back. Maybe next time I should not do my own repairs, just to preserve that heady comsumer magic of not knowing what's inside?
• I'm still using Caps Lock for Esc, so why did I even bother?!
• New keyboards feel strange.

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!

Because I found it a tad non-obvious here a little tutorial. First we enable serial access to grub. For this add the following to your /boot/grub/menu.lst (tested with Grub legacy):

serial --unit=0 --speed=19200
terminal --timeout=5 serial console

I chose such a low baud rate because it worked and I didn't want to spend more time on it and because the highest baud rate (115200) had some timing problems with that specific configuration. Then we need to adjust Xen to send the hypervisor output to the serial console as well (again in /boot/grub/menu.lst, this probably applies this way to Debian only):

## Xen hypervisor options to use with the default Xen boot option
# xenhopt=com1=19200,8n1 console=com1,vga sync_console

Debian's update-grub uses the comments in the file to generate appropriate menu entries, even if the kernel and hypervisor versions change. Thus editing a comment works, but you must remember to call update-grub after your changes, otherwise they won't be active! The last thing to change is the kernel's console. You might specify multiple consoles on the kernel's command line but only the last one will be the primary where the boot messages from init and the boot scripts are sent to. Kernel messages will end up on both, however. The edited comment looks like this (without Xen you would change kopt instead):

## Xen Linux kernel options to use with the default Xen boot option
# xenkopt=console=tty0 console=ttyS0,19200n8

The key change which enabled me to use the serial console was passing sync_console to Xen. Sadly it complains now on boot that this option should not be used on production systems because it ensures that all messages reach the serial console and wait if necessary. But in my humble opinion it should only hurt on output and there should not be that much kernel and hypervisor output anyway, except if there is something wrong with the machine. Serial output from Linux only was also messed up when Xen hadn't this option activated. To access the serial console just invoke GNU screen as a user in group dialout or as root like this to get the serial console as screen's first window:

# screen /dev/ttyS0 19200

Now the only thing that's missing is an affordable remotely controllable power line to trigger power cycles... Update: Liberie Cunha-Neto kindly pointed me to the Xen hypervisor command line, from which one could reboot the machine. It is invoked by pressing Ctrl-a three times on the serial console (it does not work on the real one I told). In screen you need Ctrl-a, a instead, as Ctrl-a is its command prefix. Then you can get help by pressing h and reboot the machine by pressing R.