This post is made in a personal capacity. While it represents the outcome of multiple discussions on the topic with a variety of people, nothing written below should be construed as Red Hat's corporate position

The FSF have released a statement on UEFI secure boot. It explains the fundamental issue here, which isn't something as simple as "will OEMs let me install Linux". It's "Does the end user have the ability to manage their own keys".

Secure boot is a valuable feature. It does neatly deal with the growing threat of pre-OS malware. There is an incentive for it to be supported under Linux. I discussed the technical aspects of implementing support for it here - it's not a huge deal of work, and it is being worked on. So let's not worry about that side of things. The problem is with the keys.

Secure boot is implemented in a straightforward way. Each section of a PE-COFF file is added together and a hash taken[1]. This hash is signed with the private half of a signing key and embedded into the binary. When you attempt to execute a file under UEFI, the firmware attempts to decrypt the embedded hash. This requires that the firmware have a either a copy of the public half of the signing key in its key database, or for there to be a chain of trust from the signing key to a key in its key database. Once it has the decrypted hash, it generates its own hash of the binary and compares them. If they match, the binary is executed.

What happens if it doesn't match? Per the UEFI specification, the firmware can then prompt the user and ask if they want to execute it anyway. If the user accepts then the hash of the binary is remembered[4] and can continue to be executed in future. This is similar to what you get when you visit a self-signed https site, or when you connect to an ssh server for the first time - the user must explicitly state that they trust the software that is being booted.

This is a little awkward for a couple of reasons. First, it means that any updates to the bootloader would require the user to manually accept the binary again. Second, as we've seen with https, there's the risk of uesrs just blindly accepting things. If it's acceptable to do this off internal media[5] then malware could just rely on some number of users saying "yes". And thirdly, we've been told that Microsoft's Windows logo requirements forbid this option.

The first is problematic but manageable with appropriate documentation. The second is a real risk that makes this approach far less compelling. And the third is probably a showstopper.

So signed but untrusted binaries are probably out, on technological, UI and policy grounds. What else?

We can sign binaries with a trusted key. This gets us interoperability, but comes at a cost. The first issue here is that we still don't know what the process for getting a trusted key is going to be. One option is for something like a generic Linux key that's provided by all firmware vendors. As long as the OEM doesn't remove it, then that Linux key could be used to sign other keys that are used by individual Linux vendors. The main difficulty involved in this is having the Linux key be managed by an authority that OEMs can trust to only provide keys to trustworthy organisations and maintain control of the private half of the key. Remember, if any malware is signed with any of these keys, it'll boot on any machine carrying this key. It's a lot of trust. It's not obvious that there's an organisation with sufficient trust at the moment.

The second approach is for each Linux vendor to generate their own key and get every OEM to carry it. Let's rule this out on the basis that it's an approach that doesn't scale at all. Red Hat could probably get its key into a bunch of OEM systems. Canonical too. Oracle? Probably for the vendors they care about. It's likely to be much harder for everyone else, and you still end up with the risk that you've just bought a computer that'll boot Red Hat but not Ubuntu.

The third approach is for each Linux vendor to obtain a key from someone who's already trusted. The most obvious authority here is Microsoft. Ignoring the PR unpleasantness involved with Linux vendors having to do business with Microsoft to get signed, so far Microsoft haven't given us any indication that this will be possible.

So every approach that involves us signing with a trusted key comes with associated problems. There's also a common problem with all of them - you only get to play if you have your own trusted key. Corporate Linux vendors can probably find a way to manage this. Everyone else (volunteer or hobbyist vendors, end users who want to run their own OS, anyone who wants to use a modified bootloader or kernel) is shut out.

The obvious workaround is for them to just turn off secure boot. Ignoring the arguments over whether or not OEMs will provide that option[6], it benefits nobody for Linux installation to require disabling a legitimate security feature. It's also not likely to be in a standard location on all systems and may have different naming. It's a support nightmare. Let's focus on trying to find a solution that provides the security and doesn't have obvious scaling issues.

There's a pretty simple one. If the problem centres around installing signing keys, why not have a standardised way of installing signing keys?

What we've proposed for this is an extension of the current UEFI standard for booting off removable media. There's a standardised location for putting the bootloader for USB sticks or optical media. For 32-bit PCs, it's EFI/BOOT/BOOTIA32.EFI. For 64-bit, it's EFI/BOOT/BOOTX64.EFI. Our proposal is to specify a path for key storage on the media. If the user attempts to boot off an item of removable media and finds a key file, we would like the firmware to prompt the user to install the key. Once the key is installed, the firmware will attempt to boot the bootloader on the removable media.

How does this avoid the problems associated with prompting the user to boot untrusted binaries? The first is that there's no problem with updates. Because a key has been imported, as long as future bootloader updates are signed with the same key, they'll boot without prompting the user. The second is that it can be limited to removable media. If malware infects the system and installs itself onto the hard drive, the firmware won't prompt for key installation. It'll just refuse to boot and fall back on whatever recovery procedures the OEM has implemented. The only way it could get on the system would involve the user explicitly booting off removable media, which would be a significant hurdle. If you're at that stage then you can also convince the user to disable secure boot entirely.

This proposal has been brought up with the UEFI standards working group, and with the UEFI plugfest taking place next week we're hoping it'll be discussed. It seems to satisfy the dual requirements of maintaining system security and ensuring that users have the flexibility to choose what they run on their system. But as with all technical proposals, feedback is entirely welcome.

[1] Hilariously, Microsoft's signing tool gets this wrong by also adding the contents of gaps between sections in direct contravention of their own specification. This is fine for binaries generated by Microsoft's toolchain because they don't have any gaps, but since our binaries do contain gaps[2] and since the standard firmware implementation[3] does implement the specification correctly, any Linux-generated binaries signed with the Microsoft tool fail validation. Go team.
[2] Something that is, as far as we can tell, permitted by the PE-COFF specification
[3] Written by Intel, not Microsoft
[4] Note that this means that only the specific binary is considered trusted. No key is imported, and any other binaries signed with the same key will also need to be manually trusted in the same way.
[5] As would be required if you ever want to be able to update your bootloader
[6] And to forestall panic, at this point we expect that most OEMs will provide this option on most hardware, if only because customers will still want to boot Windows 7. We do know that some hardware will ship without it. It's not implausible that some OEMs will remove it in order to reduce their support burden. But for the foreseeable future, you'll be able to buy hardware that runs Linux.

comments

I ve recently been to the LibreOffice Conference 2011 in Paris. It s very nice to finally meet in person all those names from the malinglist and the bug reports. Although meeting most people for the first time, I left the conference with a strong feeling of a community (which I m proud to be a member of), this is a very motivating feeling. During the conference I had the chance to work on LibreOffice related issues:

• Hebrew translation for version 3.5 (up by 2%).
• Fixes to the Hebrew translation for version 3.4 (noticed a few string changes in 3.3 not included in 3.4).
• Patch to fix a small typo in the code (noticed while trying to find the meaning of the string before translating).
• Patch to fix the appearance of the BrOffice logo in RTL UI instead of LibreOffice (fix to the 3.3 branch, already fixed in 3.4).
• 3 patches (1, 2, 3) to cleanup unused .chaos file types with Michael Meeks s encouragement and help with doing some digging in the code.
  Apparently, even non programmers can write patches with the appropriate help.
• Check about 30 RTL and Hebrew related bug reports for my RTL issues presentation, verifying them with 3.4.3.

The 3 patches began when I noticed a few weird strings to translate in the context of installation media good luck to those who will try to install LibreOffice from 5.25 disk, 3.5 disk or a tape drive. These 3 strings are now removed from the code with other 36 unused strings. So translators please take the strings to translate with a grain of salt. Post conference tasks (always ending up with more stuff to do after a conference):

• Recreate my RTL issues presentation so that the live example of bugs could be presented as slides.
• Keep advancing with the Hebrew translation (3.5 and 3.4 fixes).
• Finish the fdo bugzilla search for RTL bugs. I found out some other people who reports bugs (and try to coordinate with them).
  A list of RTL related bugs in LibreOffice I know of is here: http://wiki.hamakor.org.il/index.php/ _ _ (still work in progress, in Hebrew).
• Create a meta bug for the RTL bugs, and prioritize the issues to focus on what s important to make sure is fixed for version 3.5.
• Start testing version 3.5 for RTL bugs (daily / weekly builds).
• Help Christoph Noack with finding which PaperCuts we have in LibreOffice and try to get them fixed.

Filed under: LibreOffice, Openoffice.org

I'm indescribably happy to be able to say that I found Smudge alive and well this morning. I was getting ready to head out the door to work, and I opened the shutters in the kitchen and saw that the trap that I had outside by the front door was closed. The trap itself was wrapped in a sheet, so I couldn't immediately see what I'd caught. I quickly went outside, half-expecting to find a raccoon in there, and I was pleasantly surprised to find Smudge in there! I brought the trap inside and got Smudge out and raced her over to the food and water, where she had a long drink of water and something to eat. She's definitely lost some weight, but otherwise doesn't seem any worse for wear. She's currently sitting in my lap as I write this, so I don't think she's too traumatised by her ordeal. Lily was a bit standoffish this morning, hissing and growling at her, but I suspect that's because she didn't smell right. If she keeps that up, I'll put a drop of vanilla essence on both of them so they smell the same. Yesterday, I'd received a report of a possible sighting three streets over (houses on one side of the street back onto the Hetch Hetchy trail, where there were also reported sightings), so last night I placed the other trap in the backyard of one of the houses where there'd been a sighting. A couple of hours after that, I got another report of a possible sighting from someone else on the same street, further down. So I was pretty keen to substantiate all of these sightings on this particular street. Unfortunately, after two trips up there, I didn't see any black cats, so we'll never know if it was her or not. The night before last, I'd upgraded the food in the traps to some sardines, tuna and some fresh wet cat food, to try and lure her in. I have no idea if that helped or not, or she just finally found her way home, but it was such a relief to find her in the trap this morning. It turns out I caught an opossum in the other trap. Those are the funniest animals. They have a totally broken fight or flight reflex. This one would not leave the trap when I opened it. I ended up having to upend the trap and shake it out, and even then it just lay there playing dead - even when I shoved a bowl of food in its mouth. I've just done the rounds of the neighbourhood and taken down all the posters I'd put up. It had been suggested that I might want to update the posters and say that I'd found her, but I honestly don't want to do the extra trip to then take them all down again after that.

See also parts 1 and 2. That s a photo of Vlicha Beach, near our hotel. But before I talk about the Greek beaches, I need to explain something about living in Kansas. Kansas is in the middle of the United States. The nearest ocean is the Gulf of Mexico, which is 700 miles (1100km) away. That s roughly the same as the distance between Berlin and Minsk, or New York and Chicago. And I believe it s farther away from a saltwater body than all (or almost all) of Europe. So we re not just going to the beach every weekend or something. Vlicha Beach was all those incredible things you ever hear about beaches. The water was so clear that I could easily see my feat while wading in it. That, and the fish swimming around them. It was peaceful, relaxing, and picturesque. Between the deep blue of the sea and the same in the sky, I suppose it is no wonder that blue is often associated with Greece. We weren t exactly the only ones there. Though I think we were the only ones there with Kindles, which seemed to be much more popular in the USA than in Europe. We got several interested people carrying paper books asking what they were. Towards dusk, the mist would become more pronounced and the mountains off in the distance started to fade: The evening before we were set to fly home, we spent some time sitting on our balcony watching dusk set in. One last gaze out over the beautiful Aegean, the misty mountains, and the boats in the distance.

Good morning all! It feels like forever since I last blogged . Which is extremely bad of me *slaps own wrist*. However, I m been horrendously stupidly busy. As some of you may know, I m very much an Android fan. Recently, I ve gotten myself a shiny Galaxy SII. Given the fact that alongside my day job of being a Web Developer for an Online Retailer, I m also a Voluntary Ambulance Person I thought it d be useful to ask my current workplace if they d provide me a mobile phone cover for my new phone. Of course, work were more than happy to provide me with a shiny Samsung Galaxy S2 case (I actually went for the Case-Mate Barely There in brushed aluminium). Being a voluntary Ambulance Person, I regularly have to go to random places to pick up an ambulance/attend an event. Because of that I rely quite heavily on Google Maps and it s navigation features (Free Sat Nav in my opinion, the killer feature of Android). Having only had my phone a week, I started to find that there were a few problems with the GPS. Whereas previously, I d been able to lock on almost instantly, It d now take me about half an hour (literally) to get a lock on anything. I tried Googling, I tried everything I could think of, but to no avail. I downloaded GPS Test, and it was showing that while it was picking up a couple of sattelites, it wasn t picking up enough to get a decent lock The image above is a screenshot of the GPS test from directly outside my front door, taken after it had settled down. As you can imagine, I wasn t happy and was ready to send the phone back. Then, for some reason, a brainwave hit me (It doesn t happen often). What changed from when it was working to now? I know! The Case *takes case off, tries GPS test again* It can be amazing what happens when you realise that shiny case you have is mainly made of aluminium. Guess what works well at deflecting radio signals and the like You got it, aluminium. So now I need to decide whether to get another case or whether to just take the case off when I need to do sensible things. Other than the case problem, I m finding that the Samsung Galaxy SII is a great phone (as soon as I got rid of Touchwiz). I m not a fan of the OEM Samsung crap that s been bolted onto the phone, and will, as soon as there s a decent release, be putting a copy of CyanogenMod on the phone (I ve already made most of the tweaks I just want rid of SNS) In other news I ve started more and more gaming again. If you re interested in a couple of rounds of TF2 or some SC2 (or some Portal 2 Co-Op) then give me a shout with your Steam ID / Battle.net ID and I ll see what I can do. I m thinking of starting doing some Let s Play Videos, as my Youtube Channel is looking a bit sparse! I m going to try and start blogging a bit more aswell so if there s anything you want to see me blog about pop a post in the comments below! Till next time..

It'll be a week today since I assume Smudge disappeared. Still no sign of her. I got one call from my posters around the neighbourhood, but I'm now pretty confident that it was another black cat. I really got my hopes up on that one. I don't know what else to do. I could be out beating bushes every spare minute, but I feel like I'm chasing a potentially moving target around an unbounded space. I've had no bites in the cat traps out by the front door. Not even a skunk. The waiting game sucks. I have no idea if she's dead or alive.

Terah and I went to the Greek island Rhodes recently. This is the second in a series about it. I am one to enjoy history. There is something deeply, well, connecting, about standing in an old place. There is a timeless quality to it a feeling of being connected to so many people of the past, and yet still being connected to change, visible in things such as weathering of stones. To gaze at pottery that s 300 years old, walk past 700-year-old walls, or pass through what remains of the grand portico of an ancient temple to Athena stirs a feeling I can barely explain, of timelessness. Although Rhodes doesn t have the famous Greek sites such as the Parthenon or Delphi, I can t help but wonder why the Rhodes sites aren t better known. They were incredible and it is hard to condense all that we saw into a short blog post. I have to start with the medieval Rhodes Old Town. We got off the bus a few blocks from it one bright morning, and our first task was to find a gate across the moat. Oh yes, A GATE ACROSS THE MOAT. It s a dry moat, and that bridge off in the distance is the gate we were headed to. Outside of the outer wall is a nice quiet walking area. The moat and walls completely surround Old Town and, for the most part, date back about 500 years. The round stones you see on that picture, we were told, were likely surplus from catapults and other projectile weapons. Cross one line of walls and you come to another, with original canons still present. The Knights Hospitaller of St. John, which held Rhodes for a few centuries until the Ottomans captured it, sure knew how to build to impress. The gate we happened to use was Amboise, the Grand Master s Gate. Right there is the stunningly rebuilt landmark Palace of the Grand Master. It is absolutely impossible for any photograph to begin to do this building justice. Between its imported Greek and Roman floors, to the grand nature of everything in it, and the archaeological museum in one corner, it was a fitting start to a visit to Old Town. Here s one of the main staircases. Just near the Palace is quiet courtyard with an old door. Pass through that door and suddenly you re in the midst of the busy Old Town. And among the landmarks in Old Town, the most prominent is Ippoton, the Avenue of the Knights. Along this avenue are the buildings built by the various nationalities of knights, many of which are historical sites in their own. Taken together, it is quite clear why Rhodes is said to be one of the world s best-preserved medieval cities. Down at the other end of Ippoton is the Knights Hospital, which is now part of the archaeological museum. Step off the Avenue a few blocks and you get to some quieter narrow streets just as old, in many cases. On Sunday morning, we were able to visit Mount Filerimos. In contrast to the busy Rhodes, Filerimos had an air of quiet and still to it. It was the site of a monastery, two historic churches, and a landmark Italian cross on the mountaintop. We arrived, and begin our visit with a walk up the quiet stone path. When we got to the top, we walked past this peaceful church. As we walked past the outside, we heard the beautiful music of chant from indoors. We got to step in and listen to mass for a few minutes. In typical fashion, directly in front of the church are two much older sites: one, the ruins of a temple to Athena, and the other a 4th-century Christian bapistery. Rhodes is a popular tourist destination, and of course we saw plenty of popular sites (such as the grandmaster s palace). Filerimos had a few tourists too, but not as many. I frequently like to operate on the plan of going wherever all the tourists aren t. And so, on Filerimos, that meant seeing what was behind the monastery. It started with this peaceful tree-lined path. And the deserted, but intentionally open, gate led to the remains of a Byzantine fortress, which had been a staging area for both the Knights and the Ottomans before their campaigns to capture Rhodes. It also provided incredible views of the surrounding countryside. The first historic site we had visited on our trip was the Acropolis of Lindos, parts of which are 2300 years old. Here s a view of the mountain from the rooftop of the Kalypso, our favorite restaurant in Lindos. The columns of the temple to Athena Lindia are visible, and of course so are the walls. The road up to the acropolis is accessible only on foot or by donkey. It is apparently the only road that has ever been used to get to the acropolis. Here is the partially-restored grand portico to the temple. There s an old Christian church (4th century, if memory serves) at the Acropolis too. The Acropolis makes some pretty good use of natural defenses too. Here s a view from one level of it. There s a manmade wall up there at the very top. And, of course, the beautiful Aegean always in the background. There are lots of cats on Rhodes. Here is a kitten napping at the top of the Lindos Acropolis: Lindos itself is a beautiful town. Here s one of the quieter streets: Notice the pebble steps leading into the houses those intricate pieces of artwork are all over. This post won t be complete without the story of our visit to the Acropolis of Rhodes. We walked there from Old Town. At the Acropolis, there are the remains of a temple to Apollo, an ancient theater, and an ancient stadium where qualifying matches for the Olympics were held. As we got closer to the area, we were repeatedly passed by people dressed in uniforms of various types. And as we got there, we joined a stream of people entering the area. The ancient stadium had apparently thousands of people in it, country names were being read off over the loudspeakers, policemen wielding machine guns were standing by, and we had absolutely no idea what was going on. At this point, you can appreciate the difference between Terah and me. Terah thought that we have no idea what is happening, she was tired from the walk, and so thought we should just leave. I thought that we have no idea what is happening, which is a great reason to stay. So Terah opted to sit and read a bit under some trees while I explored. Here s a view of the stadium as it was emptying out, seen from the theater: I explored the temple and theater, and eventually we were ready to head back. We knew there was a bus back to the New Market (from where we could get a bus back to our hotel), but didn t know where the bus stop was. The obvious place to ask were the policemen, which I thought I would do. Terah thought she would just stay sitting under the trees, on the grounds that the policemen nearest us were all carrying machine guns and perhaps wouldn t like to be disturbed. This led to my cryptic tweet:

Only ONE of us is the kind of person that goes up to guys with machine guns to ask what s happening. Me to Terah today

They told me that it was the preparations for the opening ceremony for a global shooting contest, and also gave me directions to the bus stop.

Irony, part 2. #physics, #irony https://www.technologyreview.com/blog/arxiv/27260/ It turns out that the 'superluminal' neutrinos effect spotted by the OPERA experiment in CERN/ Gran Sasso was probably due to an error in neglecting to account for relativistic effects in the GPS satellite movement. Far from debunking relativity, it proves it.

Friday Irony overload. We've too much work(*) but are hiring 4 new staff. So he's organizing a meeting of "Activity leaders" to plan what to do. Only we're all too busy to make it ... (*) At the quarterly "Scheduling meeting", after all cancelable work was cancelled, and other work postponed, I was left with just under 4.5 months of work this quarter ...

This was written by Tom Dailey, and I ve lightly edited it:

In 1965, I was stationed at the Fleet Anti-Submarine Warfare Center in San Diego. I was a Radioman 2nd. Class in the USN, at the time. One evening, at our radio club station (W6DCM different license holder, now), I called CQ and got UA KKC (it s no longer around), with Ivan at the mic. After a time of the usual signal reports and such, we asked what each did in their lives I said that I was US Navy radio operator. He answered that HE ALSO was a Navy radio operator in the Soviet navy. Then we discovered that his station was at the SUBMARINE base at Vladivostok, and I of course was his DIRECT opponent. Yes we really DID laugh at that, and I shall never forget what he said (that I heartily agreed with): Thomas, isn t it shame that we re supposed to hate each other? Yes, Ivan, it is someday we ll share a vodka, da? Da , he replied.

We re often told we should hate people. Messages I have heard on the media over the last 10 years have said we ought to hate illegal immigrants, CEOs, radical Muslims, the French, Iranians, Mexicans, presidents, UN diplomats, climate scientists, oil company employees, Chinese people, conservatives, liberals, religious people, atheists, and oh yes, still Russians. But I get to choose who to hate, and in fact, I choose NO HATE. Not only does it keep my stress level way lower, but it also lets me enjoy life more, and makes the world a better place. We can all talk to people in other countries and with other backgrounds and viewpoints so easily thanks to the Internet. Sadly we rarely have very deep online conversations to the point of getting to know people. For whatever reason, ham radio lends itself to that better. Even better: visit other places. I wonder how many people that say they hate some group of people have visited them and made an effort to make a connection? It is, after all, really hard to hate someone that is kind to you. Perhaps they re afraid to let go of their hate. Think also about this: for whom is it convenient if you hate people? There is usually a reason that hatred is stoked, and it doesn t usually lead to good things for individual people. Tom W0EAJ added:

I actually tried to locate him and the station, but both appear to have vanished. Ivan (his name was pronounced Eee-von) could have, it occured to me later, gotten into trouble for saying such things. I think both of us realized AT THE TIME, what an astounding counterpoint each of us was to the other. Proof that if it were left up to the simple little guys like us, and not to the politicians, we might actually pull off living in peace.

Dear Lazyweb . I ran into a very strange issue with MySQL authentication. The initial situation is as follows:
Two MySQL servers, let s name them a0.my.do.main and a1.my.do.main. Their my.cnf configuration is identical except for the server_id (equals 1 on a0 and 2 on a1).
Since I wanted to set up a master< ->master replication, I created a user repl@%.my.do.main on a0, then shut down the mysql server on both hosts, copied over the mysql database on the filesystem layer (i.e. rsync of the data directory), then started mysql on both hosts again. So far, so good, both servers came up nicely, and local (unix socket) login as a root user worked fine as expected. However: Logging in via TCP socket only works from a1 (to both a0 and a1). Logging in via TCP socket from a0 doesn t work to either host. I also created a test user sven @ %.my.do.main (I also tried with @ % ) which has all privileges.
Here is what the commands output:

sven@a0 ~ > mysql -u sven -ptestpass -h a0.my.do.main
ERROR 1045 (28000): Access denied for user 'sven'@'a0.my.do.main' (using password: YES)
sven@a0 ~ > mysql -u sven -ptestpass -h a1.my.do.main
ERROR 1045 (28000): Access denied for user 'sven'@'a0.my.do.main' (using password: YES) sven@a1 ~ > mysql -u sven -ptestpass -h a0.my.do.main
Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 32
Server version: 5.0.77-log Source distribution Type 'help;' or '\h' for help. Type '\c' to clear the buffer. mysql> Bye
sven@a1 ~ > mysql -u sven -ptestpass -h a1.my.do.main
Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 24
Server version: 5.0.77-log Source distribution Type 'help;' or '\h' for help. Type '\c' to clear the buffer. mysql>
All packages on both machines are up to date (CentOS5 with all updates available). The server variables shown with show variables also seem identical (except for the hostname and the server id). Besides, it looks more like a client problem to me than a server problem. Last datapoint: If I define the mysql user sven with an explicit host (a0.my.do.main and a1.my.do.main) instead of a wildcard, everything works nicely, from and to both hosts. So, dear lazyweb: Does anyone have an idea what might be causing this issue? Update: Due to some comments, let me add a few points of information:

1. flush hosts doesn t help. Host resolution looks OK, according to documentation, the hostname in the error message is what the server things is right, not what the client specified, and that documentation seems to be consistent with my experiences.
2. The db and user tables look as expected. And I m quite sure they are not the issue here, as I can connect from other hosts that match the host pattern.
3. There is no ~/.my.cnf on either host
4. Copying the database files on the filesystem layer is one of the documented ways of initializing the database on the slave for replication. Anyway, I had the same issue when trying to set up the database on the slave by loading a dump.
5. DNS looks fine, both forward and reverse mappings, both servers use the same DNS server.
6. IPv6 is not involved, it is disabled on these servers

Thanks for the hint at serverfault.com, I will try that if I don t get sufficient info here. Update 2 Another strange data point:
When I disable the (non-privileged) anonymous access user in the mysql.user table (i.e. drop the rows with user= "), everything works as expected from both servers. However, why does it work from one host (client) to both DBs if the anonymous access is allowed (with no privileges except for being able to see that the test and mysql databases exist), but not from the other host (client)? It really looks like an issue on the client side, but I still don t get what exactly goes wrong.

No, my blog isn't dead, and neither is me. It's just that way too many things happened since this year's debconf that got me a bit off tracks. I managed to do daily business like keeping my packages in shape and the backports queue low, and that was mostly it. No clue if that will change anytime soon, but I guess I would like to keep you updated with an event where you can meet me next week: There will be the Global 2000 Birthday Party going on in the WUK on Thursday 20th, so if you happen to be in Vienna at that time, drop by and enjoy some great bands. ... which brings me to one of the local bands from Vienna: Heinz aus Wien. They are around for well over 10 years now and are still rocking quite well. Here are some examples of their songs, like always:

• Wir sind immer noch: A sort of love song for this great town, Vienna.
• Lieb im Prinzip: A very pithy song about relationships.
• Ich hab mit Tocotronic Bier getrunken: Quite funny song from their early days, and interestingly, people regularly claim that it was done by a different band ...

Like always, enjoy!

/music permanent link Comments: 0 Flattr this

Poor Sarah. Cat dramas always seem to befall us when she's in Australia. It looks as if Smudge has managed to escape the house. Being at work all day, it took me 24 hours to notice. Our friend Helen came over on Sunday night. Smudge was definitely around then, because she was climbing all over Liam. Helen used the downstairs bathroom before she went home, and I remember her having to shoo Smudge out because she was in there. I'm pretty sure she went home after that. If my memory serves, she saw herself out and I was in the kitchen cleaning up, so my current theory is that she escaped when Helen left. On Monday night, I had a lengthy video call with Sarah, who was at my parent's place setting up their new Mac Mini. I didn't realise until after that, when I was about to go to bed, that I hadn't been harassed by Smudge all evening. So I searched the house that night, and couldn't find her. Liam had already gone to bed for the night, so I hoped she was stuck in his room, and went to bed too. This morning, Liam and I both searched the house, and the immediate surrounds, without any luck. I called the Palo Alto Animal Services (I got the dispatch because the shelter hadn't opened yet), emailed the local neighbourhood association, and went to work. I called Palo Alto Animal Services again later in the day to report her missing to the shelter itself, and Betty-Ann there recognised my accent and name and asked me if I was Sarah's husband (Sarah used to volunteer there a lot, and we adopted Smudge from there), so they're now keeping a look out. Smudge is micro chipped, but wasn't wearing a collar. She's allowed in the back yard, because it's totally enclosed and can't escape, so she shouldn't be totally freaked out by being outdoors. Whenever she does escape out the front door, she usually makes a beeline to the right, which is mostly enclosed, but she can certainly get out of the complex. Unfortunately she often doesn't come when called, so for all I know she's in some obscure location 10 metres from the front door and I can't see her. My main concerns are that we're only two blocks from Highway 101, so if she does stray too far, she could get into serious trouble, and I'm also a bit worried about raccoons giving her grief. I spent some time tonight putting up posters in the immediate area and poking around bushes. I've left the two humane cat traps that we have out by the front door with some cat food in them, in the hope that she's roaming around and will walk into one of them. Oh and the other big concern I have is that Halloween is coming up. Shelters tend not to adopt out black cats around Halloween because bad things can happen to them. So now we wait. I'm really hoping she turns up safe and sound, soon.

I have recently been working on some code for NetSurf which builds up an output buffer by repeatedly calling snprintf(); No great shock there, well understood trivial pattern that has been used repeatedly for ages. Gosh I feel silly now, in fact I was so convinced I was right I wrote a program to "prove" it.

I have several backup servers that run the excellent rsnapshot software, which uses Secure Shell (SSH) for remote access. The SSH private key of the backup server can be a weak link in the overall security. To see how it can be a problem, consider if someone breaks into your backup server and manages to copy your SSH private key, they will now have the ability to login to all machines that you take backups off (and that should be all of your machines, right?). The traditional way to mitigate SSH private key theft is by password protecting the private key. This works poorly in an unattended server environment because either the decryption password needs to be stored in disk (where the attacker can read it) or the decrypted private key has to be available in decrypted form in memory (where attacker can read it). A better way to deal with the problem is to move the SSH private key to a smartcard. The idea is that the private key cannot be copied by an attacker who roots your backup server. (Careful readers may have spotted a flaw here, and I need to explain one weakness with my solution: an attacker will still be able to login to all your systems by going through your backup server, however it will require an open inbound network connection to your backup server and the attacker will never know what your private key is. What this does is to allow you to more easily do damage control by removing the smartcard from the backup server.) In this writeup, I ll explain how to accomplish all this on a Debian/Ubuntu-system using a OpenPGP smartcard, a Gemalto USB Shell Token v2 with gpg-agent/scdaemon from GnuPG together with OpenSSH.


First we need to install some packages. The goal is to configure OpenSSH to talk to the gpg-agent which will start and talk to scdaemon which in turn talks to pcscd which talks to the smart card reader. For some strange reason, the scdaemon binary is shipped with GnuPG s S/MIME interface in the gpgsm package.

# apt-get install pcscd gnupg-agent gpgsm

The above command should install and start pcscd and if all works well, you should be able to check the status of the smartcard using GnuPG.

# gpg --card-status

You need to initialize the smartcard and generate a private key on it, again using GnuPG. If you trust GnuPG more than the smartcard to generate a good private key, you may generate the private key using GnuPG and then move it onto the smartcard (hint: use the keytocard command). Make sure you don t leave a copy of the private key on the same machine!

# gpg --card-edit
gpg: detected reader  Gemalto GemPC Key 00 00'
...
gpg/card> admin
Admin commands are allowed
gpg/card> name
Cardholder's surname:
Cardholder's given name: host.example.org
gpg: 3 Admin PIN attempts remaining before card is permanently locked
Please enter the Admin PIN
gpg: gpg-agent is not available in this session
gpg/card> lang
Language preferences: en
gpg/card> generate
Make off-card backup of encryption key? (Y/n) n
Please enter the PIN
What keysize do you want for the Signature key? (2048)
What keysize do you want for the Encryption key? (2048)
What keysize do you want for the Authentication key? (2048)
Please specify how long the key should be valid.
         0 = key does not expire
      <n>  = key expires in n days
      <n>w = key expires in n weeks
      <n>m = key expires in n months
      <n>y = key expires in n years
Key is valid for? (0)
Key does not expire at all
Is this correct? (y/N) y
You need a user ID to identify your key; the software constructs the user ID
from the Real Name, Comment and Email Address in this form:
    "Heinrich Heine (Der Dichter) <heinrichh@duesseldorf.de>"
Real name: host.example.org
Email address:
Comment:
You selected this USER-ID:
    "host.example.org"
Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit? o
gpg: existing key will be replaced
gpg: please wait while key is being generated ...
gpg: key generation completed (33 seconds)
gpg: signatures created so far: 0
gpg: existing key will be replaced
gpg: please wait while key is being generated ...
gpg: key generation completed (18 seconds)
gpg: signatures created so far: 1
gpg: signatures created so far: 2
gpg: existing key will be replaced
gpg: please wait while key is being generated ...
gpg: key generation completed (23 seconds)
gpg: signatures created so far: 3
gpg: signatures created so far: 4
gpg: key 12345678 marked as ultimately trusted
public and secret key created and signed.
gpg: checking the trustdb
gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model
gpg: depth: 0  valid:   1  signed:   0  trust: 0-, 0q, 0n, 0m, 0f, 1u
pub   2048R/12345678 2011-09-19
      Key fingerprint = 1234 5678 1234 5678 1234  5678 1234 5678 1234 5678
uid                  host.example.org
sub   2048R/23456789 2011-09-19
sub   2048R/34567890 2011-09-19
gpg/card> quit
#

Now for the interesting part. OpenSSH talks to an agent for private key handling, and GnuPG s gpg-agent supports this protocol when the --enable-ssh-support parameter is given. During startup, gpg-agent will print some environment variables that needs to be set when ssh is run. Normally gpg-agent is invoked by the Xsession.d login scripts, so that the environment variables are inherited by all your processes. However, for an unattended machine without any normal login process, we need to write a script to start gpg-agent. First do these manual steps, to confirm that everything works.

# gpg-agent --daemon --enable-ssh-support > /var/run/gpg-agent-info.env
# . /var/run/gpg-agent-info.env
# ssh-add -L
ssh-rsa AAAAB3N... cardno:000500000BD8
#

If the final step printed a SSH public id, the (sometimes) tricky part in getting the hardware to work is (hopefully) complete. What remains is to script things so that gpg-agent is started on boot and to make sure that your backup scripts has the proper environment variables before launching whatever processes will launch ssh. Further, since we will be running unattended, we need a mechanism to unlock the smartcard using a PIN interactively once on each boot of the machine. I prefer manually entering the PIN on every boot over having the PIN stored in a file on the disk. I will use the /etc/rc.local mechanism to start gpg-agent, like this:

# cat> /etc/rc.local
#!/bin/sh -e
exec gpg-agent --daemon --enable-ssh-support \
    --pinentry-program /usr/local/sbin/pinentry-unattended \
    --write-env-file /var/run/gpg-agent-info.env
^D

The astute reader will now ask what /usr/local/sbin/pinentry-unattended is and why it is needed. Now here is the situation. scdaemon will normally query the user for a PIN using a tool called pinentry which reads and write to the user s TTY directly. This won t work in unattended mode, so we want the scdaemon to signal failure here unless we are actually unlocking the smartcard manually. Here is the entire script:

#!/bin/sh
# /usr/local/sbin/pinentry-unattended -- by Simon Josefsson
if test x"$PINENTRY_USER_DATA" = xinteractive; then
    exec pinentry "$@"
fi
exit 1

What remains is a script to unlock the smartcard by providing the PIN. This is typically invoked manually if the server has restarted for some reason. Don t worry, any ssh sessions invoked by cron until you have managed to unlock the smartcard will fail with an authentication error it won t hang waiting for a PIN to be entered.

#!/bin/sh
# /usr/local/sbin/unlock-smartcard -- by Simon Josefsson.
. /var/run/gpg-agent-info.env; export GPG_AGENT_INFO SSH_AUTH_SOCK SSH_AGENT_PID
gpg-connect-agent 'scd killscd' /bye > /dev/null
while ! gpg-connect-agent 'scd serialno' /bye   grep -q SERIALNO; do
    sleep 1
done
PINENTRY_USER_DATA=interactive
export PINENTRY_USER_DATA
checkpin

And the script checkpin is as follows:

#!/bin/sh
# /usr/local/sbin/checkpin -- by Simon Josefsson.
id= gpg-connect-agent 'scd serialno' /bye   head -1   cut -d\  -f3 
gpg-connect-agent "scd checkpin $id" /bye   grep -q OK

At this point, you should have everything configured and installed. Don t forget to chmod +x the scripts. The typical use-pattern is as follows. After the machine has been started, gpg-agent is running but the smartcard is not unlocked with the PIN. You need to manually login to the machine and run unlock-smartcard and enter the PIN. In the script that runs the backup jobs, invoked via cron, make sure that the first line of the scripts reads (assuming Bourne shell script syntax):

. /var/run/gpg-agent-info.env; export GPG_AGENT_INFO SSH_AUTH_SOCK SSH_AGENT_PID

To avoid needlessly attempting ssh connections if the smartcard is not unlocked, your backup script can also call the checkpin code and abort if it doesn t return true.

checkpin   exit 1

Some final words about debugging. A basic command to run to check that the GnuPG side is working is gpg --card-status, it should print some information about the smartcard if successful. To check that the SSH agent part is working, use ssh-add -L. If you get error messages, try killing the scdaemon process by running killall -9 scdaemon and let gpg-agent respawn a new scdaemon process. That s it! If you like my writeup, please flattr it.

I was expecting to write more about the 7th Rugby World Cup, but real life, Debian work and running activities prevented me to do so.. Still, I watched several games and I can share my feelings now. First of all, this is a tremendous organization from New Zealand. It seems that about the entire country is working on making this even a great success and I really appreciate to see a place I certainly have to visit some day receiving such wordlwide attention (OK, admitedly, mostly in the part of the world that understands rugby). First round already gave several surprises even if the 1/4 finals were after all kinda expected (at least, the list of countries).

• New Zealand All Blacks is by far the most shiny team. They crushed all their opponents, including our French team, and were indeed brilliant. So, really, the challenge is: who can beat them?
• Australia and South Africa were about the same. Australia has been surprised by Ireland (one of the most exciting games of first round) and is apparently no longer the incredible team that scored over 60 points in France back in November 2010. South Africa has been strong and powerful during 1st round... but, indeed, not that impressive (I'm not fond of south-african game, anyway).
• Argentina was again great. They had to qualify in a quite hard pool and made it well. Funny to see that, at many moments, the 15 players on the field were players....that usually play in French club teams. They were even sometimes talking in French with some referees (either the excellent Romain Poite, from France, and the also excellent M. Rolland, the most french Irish referee)
• Wales has been serious and strong enough to qualify in a not so easy pool. Their rear lines are the most dangerous among qualified teams, along with NZ
• Ireland made an excellent pool game. Their win against Australia was really a surprise and a nice illustration of what "Irish fighting spirit is". I'm not always fond of Irish rugby organisation (provinces only playing4 to 5 really serious games in a season), but it gives results
• Scotland is really reviving. OK, they didn't qualify, but this team is now far from the very bad team they had during the 2000 years. Rear players as well as their 2m-tall front player (whose name I can't remember now) are excellent
• England. Ah, England..:-). Seeing our "best enemy" in rugby being not so good was kinda a pleasure for me..:-). I just feel sad to see Mister Johnny Wilkinson in not so good shape, because that player is really someone I have respect for. Others...I have less respect, sometimes, I admit (particularly this Ashton guy who I expect to crash in the grass, some day, when arrogantly diving when scoring a try). OK, that's England. Always running love and hate story..:-)
• Fiji, Tonga and Samoa weren't as decisive and challenging as they used to be. Out of these three "Pacific Islands" countries, the Tonga team was IMHO the best and their match against France was a monument of courage. They would even have deserved to qualify and we have to thank Canada for beating them..:-)
• Italy was a deception for me. Their key players are aging and they have hard times renewing the team. And now, definitely, having a good scrum is not enough.
• Among the "have no chance to qualify" teams, I have a good impression of Canada. With so few players in the country, it is amazing to see that they can build a team able to beat Tonga and to play a great game against France. Japan also made at least one excellent game against France. I haven't seen many others, sorry for that.
• And how about France? I have to say they have been very French..:-). The pool round was nearly a disaster with very few good spirit in this team, not even a good scrum and way too many imprecisions and approximations. Still, they qualified.

Which lead us to the following 1/4 finals (in parenthesis are my bets):

• Wales-Ireland (Ireland)
• England-France (England)
• Australia-South Africa (South Africa)
• New Zealand-Argentina (New Zealand)

If you know about the results, you know I screwed it nearly completely..:-) The Welsh team played a great game against an uninspired Irish team. It has certainly been the best 1/4 final and they certainly deserve their win. Even though I usually tend to be supprotive of Ireland, I was very balanced here, and finally turned out to be in favor of the Welsh. We really have to fear them in semi-finals. Australia-South Africa was theoretically the most exciting 1/4 final but finally turned out to be quite boring. Both teams insisted on playing mostly to occupy their opponents part of the field, more than trying to score, then relying on penalties to score. That was apparently the good tactics for Australia ad they also deserve their win against a South-African team where forward players were not as decisive as they sometimes are. Argentina was again there and really there. It has been the only team up to now who lead score against New Zealand. And that was deserved. What a wonderful 1st halftime! Obviously, it was impossible for them to resist during second halftime and it slowly became obvious that the Blacks (saved during 1st half by the kicks of a very inspired Kiri Weepu) would finally manage to score tries. But, still, our argentinian friends, for instance the inoxydable "Super Mario" Ledesma, or the tireless Felipe Contepomi, were not here as a sacrificial victim. What to say about England-France? First half was astonishing for us, of course. This is what we love (and hate) with our beloved French team. Definitely the team that can make surprises and, imho, the only one that can beat New Zealand if that has to happen (but also the only one that can be entirely crushed by them). The defeat against Tonga and the week that followed completely transformed them. A stunning 3rd row, defending each and every single bit of England trying to invade "la patrie en danger". Rear lanes with the magicians of Toulouse (Clerc and M dard) as the ideal finishers of magic play by Parra, Trinh Duc, Mermoz, Palisson (the good surprise of this world cup, Alexis). And, during second half, a trilling resistance to assaults of the British White Knights, concluded by this delivering drop-goal by Trinh Duc. For sure, with games like this, they can beat everybody and by everybody, I mean everybody. Remember Millenium Stadium in 2007..:-) So, well. Australia-New Zealand and France-Wales. I know where my heart is balancing for both games. The Blacks and Les Bleus in final, thi is what we hope (and fear...), but both teams, particularly France, will have to first climb a quite big wall before reaching this.

A month ago, I published an article on the compared performances of stunnel, nginx and stud as SSL terminators. The conclusion was to use stud on a 64-bit system, with session caching and AES. stunnel was unable to scale properly and nginx exhibited important latency issues. I got constructive comments on many aspects. Therefore, here is the second round. The protagonists are the same but both the conditions and the conclusions have changed a bit.

Benchmarks The hardware platform remains unchanged:

• HP DL 380 G7
• 6 GB RAM
• 2 L5630 @ 2.13GHz (8 cores), hyperthreading disabled
• 2 Intel 82576 NIC
• Spirent Avalanche 2900 appliance

We focus on the following environment:

• Ubuntu Lucid, featuring a patched version of OpenSSL 0.9.8k with AES-NI builtin and enabled by default
• 2.6.39 kernel (250 HZ)
• 64-bit
• 1 core for HAProxy, 2 cores for network cards¹, 4 cores for SSL, 1 core for the system
• system limit of 100,000 file descriptors per process

On the SSL side, the main components are:

• 2048-bit certificates
• AES128-SHA cipher suite
• 8 HTTP/1.0 requests per client
• HTTP response payload of 1024 bytes

If you are interested in different conditions (32-bit, number of cores, 1024-bit certificates, proportion of session reuses), have a look at the previous article whose results on the matter are still valid. I only consider 2048-bit certificates because most certificates issued today are 2048-bit. In SP800-57, NIST advises that 1024-bit RSA keys will no longer be viable after 2010 and advises moving to 2048-bit RSA keys:

If information is initially signed in 2009 and needs to remain secure for a maximum of ten years (i.e., from 2009 to 2019), a 1024-bit RSA key would not provide sufficient protection between 2011 and 2019 and, therefore, it is not recommended that 1024-bit RSA be used in this case.

And the protagonists are:

• stud, @e207dbc5a3, with session cache enabled for 20,000 sessions, listen backlog of 1000 connections,
• stunnel 4.44, configured with --disable-libwrap --with-threads=pthread (configuration),
• nginx 1.1.4, configured with --with-http_ssl_module (configuration).

UPDATED: Configuration of nginx has been updated to switch to off both multi_accept and accept_mutex thanks to the feedback of Maxim Dounin on latency issues that were present in the previous article (and still present in the early version of this article). HAProxy (configuration) is used for stunnel and stud to add load-balancing. For each test, we want to maximize the number of HTTP transactions per second (TPS) while minimizing latency and unsucessful transactions. The maximum number of allowed failed transactions is set at 1 transaction out of 1000. The maximum allowed average latency is 100 ms².

Control case Below is the first comparison between stud, nginx and stunnel on plain Ubuntu Lucid. Like in previous benchs, stunnel is not able to scale, with a maximum of 400 TPS. However, early latency issues of nginx has been solved, thanks to the change in configuration. stud and nginx gets similar performance but, as you can see on the bottom plot (whose scale is logarithmic) stud starts with an initial latency of 40 ms. This is pretty annoying. I have tried some micro optimization to solve this issue but without luck. If latency matters for you, stick with stunnel or nginx (or find where the problem lies in stud). UPDATED: After reporting this issue, a fix has been commited. The culprit was Nagle s algorithm which improves bandwidth at the expense of latency. With the fix, performances are mostly the same but there is no latency penalty any more.

OpenSSL 1.0.0e When I published the first round of benchmarks, Micha Trojnara was dubious about the bad results of stunnel. He told me on Twitter:

I solved it! You compiled stunnel against a 4 years old OpenSSL with MT-unsafe SSL_accept. Upgrade OpenSSL and rebuild stunnel. This bug was fixed in OpenSSL 1.0.0b. I implemented a (slow) workaround, so stunnel doesn t crash with earlier versions of OpenSSL.

Therefore, I backported Ubuntu Oneiric OpenSSL 1.0.0e to Ubuntu Lucid³ and, as you can see yourself on the plot below, there is a huge performance boost for stunnel: about 400%! stud features a slight improvement too (about 8%) but still starts with a latency of 40 ms while nginx does not improve.

Intel Accelerator Engine Most Linux distributions are still using OpenSSL 0.9.8. For example, Debian Squeeze ships with OpenSSL 0.9.8o, Ubuntu Lucid with 0.9.8k and RHEL 5.7 with 0.9.8e. Therefore, they are not eligible to recent performance improvements. To solve this, Intel released Intel Accelerator Engine, which also brings, among other things, AES-NI support:

This is essentially a collection of assembler modules from development OpenSSL branch, packed together as a standalone engine. Standalone means that it can be compiled outside OpenSSL source tree without patching the latter. Idea is to provide a way to utilize new code in already released OpenSSL versions constrained by support and release policies limiting their evolvement to genuine bug fixes.

Alas, in my tests, there was no improvement compared to OpenSSL 1.0.0e (already patched with AES-NI support). stunnel comes with out-of-the-box support for additional engines. Just add something like this to your stunnel.conf:

engine=dynamic
engineCtrl=SO_PATH:/WOO/intel-accel-1.4/libintel-accel.so
engineCtrl=ID:intel-accel
engineCtrl=LIST_ADD:1
engineCtrl=LOAD
engineCtrl=INIT

For stud, you should grab support for engine selection from GitHub and for nginx, just specify the engine with ssl_engine.

Intel Performance Primitives In his great article Accelerated SSL , Simon Kuhn shows huge performance improvements by using Intel s IPP library, a library aimed at leveraging power of multi-core processors and including some cryptographic primitives and a patch to make use of them in OpenSSL. Unfortunately, this library is not free, not even as in free beer . The patch provided by Intel only applies on OpenSSL 0.9.8j. Simon updated it for OpenSSL 1.0.0d. It also applies with a slight modification to OpenSSL 1.0.0e. Look at Simon s article for instructions on how to compile OpenSSL with IPP. Simon measured 220% improvement on RSA 1024-bit private key operations by using this library. Unfortunately, we don t get such a performance burst with stud which exhibits a 15% improvement (but remember that private key operations only happen once every 8 transactions thanks to session reuse). Worst, with stunnel, performances are reduced by one third and nginx just segfaults. I think such a library is risky to use in production.

Hyperthreading During the previous tests, only half the capacity of each core were used. For stud, adding more workers per core only slightly improves this situation (less than 10% with 4 workers per core). Therefore, I thought using hyperthreading could rectify the situation here. In this case, stud, stunnel and nginx are allocated 8 virtual cores instead of 4. stud only got a small improvement of 5%, nginx a moderate improvement of 11% while stunnel got a significant improvement of 26%.

Conclusion Here is a quick recap of the maximum TPS reached on each tests (while keeping average response time below 100 ms). All tests were run on 4 physical cores with 2048-bit certificates, AES128-SHA cipher suite. Each client makes 8 HTTP requests and reuse the first SSL session.

Context	nginx 1.1.4	stunnel 4.44	stud @e207dbc5a3
OpenSSL 0.9.8k	1489 TPS	400 TPS	1492 TPS
OpenSSL 1.0.0e	1501 TPS	1561 TPS	1609 TPS
OpenSSL 1.0.0e + IPP	-	1101 TPS	1857 TPS
OpenSSL 1.0.0e + HT	1718 TPS	1973 TPS	1694 TPS

I also would like to stress that below 1500 TPS, stunnel adds an overhead of a few milliseconds while stud adds 40 milliseconds. With OpenSSL 1.0.0e and hyperthreading enabled, stunnel has both good performance and low latency on low loads to moderate loads. You may just want to limit the number of allowed connections to avoid collapsing on high loads. While in the previous round, stud was the champion and stunnel lagged behind, the situation is now reversed : stunnel is on top! UPDATED: As said earlier, the latency issue with stud has been solved. Performances remain mostly the same.

---

1. HAProxy and network cards don t need dedicated core for this kind of load. However, if you also want to handle non SSL traffic, those dedicated cores can get busy.
2. The real condition is more complex. Each point is considered valid if the corresponding average latency is less than 100 ms or if the average on the next 8 points is less than 100 ms. Temporary latency bursts are therefore allowed. We are not so forgiveful with failed transactions.
3. This is pretty straighforward: I just dropped multiarch support. I chose to use Ubuntu version of OpenSSL instead of upstream because there are some interesting patches, like automatic support of AES-NI.

Our friends Andrew and Janice finally tied the knot last Sunday, in Langkawi, Malaysia. They're Aussies currently living in New York, and Janice is of Malaysian descent, so I think part of the reason was to accommodate some Malaysian relatives that wouldn't be able to travel, and the other reason was that it was going to mean a bunch of people had to travel anyway, so why not travel somewhere a bit exotic? As my sister is getting married later this month in Brisbane, we decided to spare Zoe two massive international flights in close succession, and Sarah and Zoe flew out a few days ahead of me, and went to Brisbane, and then Zoe, Sarah and her mum flew to Langkawi from there, and I flew there from San Francisco, with the plan being for Sarah and Zoe to hang out in Brisbane for the 4 weeks in between weddings. It was the longest amount of travel I think I've ever done. I hadn't sat down and calculated what the travel time was beforehand, and when I got on the flight from San Francisco to Hong Kong, and they said it was going to be nearly 14 hours just to Hong Kong, I nearly wept. The only good thing about it was I didn't have to wrangle a toddler as well. From there, I had to get to Singapore, with a several hour layover, and then another flight from Singapore to Langkawi. I left SFO at 1:20am on Monday morning, and finally arrived at about 7am (San Francisco time) the following day. I didn't even bother getting off the plane in Hong Kong, it was only an hour and a half layover. I think the layover in Singapore was 5 hours, and it was a separate flight. Singapore airport at least was pretty good to kill time in. It was funny, I was reading Wired while I was killing time in Singapore, and they had an article, which included a side bar on 10 Best Airports to Get Stuck In, and I observed that getting to Langkawi and back involved using 4 of them. The flight into Langkawi was more eventful than usual. I was dozing a bit as we were coming in to land, and I woke up to the sensation of taking off again. I wondered if we'd had an aborted landing? Sure enough, soon after, the captain got on the public address and said that they'd had to abort the landing due to bad weather in Langkawi. He had pretty bad Engrish, thanking us for our frustration and saying something about fuel, so I didn't get a lot of the details. We proceeded to circle for a while before finally landing. I think the flight ended up landing something like an hour or more later than scheduled. So that was mildly exciting. Langkawi airport was one of those little "walk across the tarmac" places. I think I stood the closest to an operating jet engine that I ever have, as another aeroplane taxied in to a stop between my plane and the terminal while I was walking to it. Loud. Anyway, that was all just me getting there. Sarah had a bit of fun getting to Brisbane on her own with Zoe. She's now too long to sleep in an in-flight bassinet, and doesn't seem to like sleeping vertically in the Ergo Baby Carrier (possibly she was too hot in it). I think she got a bit of sleep lying across Sarah's lap, but Sarah didn't get much sleep. I think there was similar fun for the Brisbane to Kuala Lumpur flight, but at least she had two laps to lie across for that one. Sarah, Zoe and Sarah's mum arrived in Langkawi earlier in the day on Tuesday, and I made it to the resort at about 10pm (local time) and pretty much immediately crashed for the night. The Westin Langkawi was just fabulous. I don't think we've stayed at a resort since our honeymoon, and this resort was a whole other level compared to Heron Island. The rooms were very comfortable, and the resort was very accommodating of a toddler. Their Kids Club menu was excellent. The breakfast buffet (included in our room rate) was the most comprehensive breakfast buffet I have ever seen in a hotel. The only thing missing was bacon, being a Muslim country, but I can live without that. It was pretty easy to just fill up on breakfast, skip lunch and just have a light dinner. The on-resort dining prices were also very reasonable. The off-resort prices were even cheaper. The resort facilities in general were very comprehensive. Three pools. A children's play room. A well equipped gym and recreational area including squash courts. An extremely nice day spa. The thing I liked best about the whole destination wedding thing was all of the activities leading up to the actual wedding. The wedding was on the Sunday, and we had the Hen's and Buck's parties on Friday. Apparently Australia is the only place that calls it a Buck's party. The rest of the world calls it a Stag party, how about that? There was some last-minute changes to the Buck's party, and we ended up chartering this huge $2 million yacht for 4 hours and going for a cruise and doing some jetskiing and water sports. The captain was Aussie, so we all had a good chat with him. Apparently it's a corporate vessel, with an exclusive chartering arrangement with the Westin. On Friday night, we all went out to a seafood buffet dinner at the Yellow Cafe over at Cenang Beach. Most of the guys and girls already knew each other courtesy of the day's activities, so dinner involved a lot of meeting the other halves. What I really liked about all of the pre-wedding stuff was that by the time the wedding rolled around, you really felt like you knew a bunch of Andrew and Janice's family and friends, which I think made the whole thing feel a lot more intimate. Saturday was a recovery day. Sarah's aunties Glenda (who was in Singapore on business) and Vicki (who lives in Thailand) had joined us at the resort by this stage, so we were all knocking around together checking out the island. We took the cable car to the top, but unfortunately the sky bridge was closed due to the inclement weather. There was a lot of touristy stuff at the bottom of where the cable car was, and Zoe got to have an encounter with a very large python. She even tried to give it a kiss. One of the things that was surprising was how popular Zoe was with all of the locals and other Asian tourists. We could probably have charged for photographs. There was a little girl, who I thought was possibly a similar age to Zoe (turned out she was two and a half) and I asked her parents if I could take a photo of the two girls together, and no sooner had they sat down together and a virtual paparazzi materialised out of nowhere taking photographs. Similarly, all of the staff at the Westin were totally taken by Zoe, and wanted to touch her. To her credit, Zoe handled all of the extra attention pretty well. The wedding wasn't until 6pm on Sunday, so we did a 4 hour island hopping boat tour in the morning. That was a bit of an experience. It was nothing short of sheer bedlam trying to board the right boat at the wharf (I use the term lightly) and then the boat's captain had to arrange the passengers appropriately so as to keep the boat on an even keel. It was a narrow motor boat with a canopy cover over the back two thirds of it. First stop was Dayang Bunting Island, home of Pregnant Maiden Lake, where we stopped for 45 minutes. More bedlam ensued getting off the boat at the wharf there (there was veritable flotilla of tour boats all trying to load and unload at the same time). Monkeys abounded. They seemed incredibly tame. We were practically tripping over them. Zoe didn't seem to be as taken by the monkeys as I thought she would. It was a short walk up a reasonable flight of stairs to get to the lake, though some incredibly humid jungle, and once we got there, there wasn't a huge amount to do in the time we had available. So we dunked Zoe's feet in the lake a few times and then made our way back to the chaos at the wharf and got back on our boat. We stopped for a similar amount of time at another island with a pretty nice beach, and Zoe had enough time to a quick swim in the ocean with Sarah, and then we made our way back to the boat again to another spot where we watched sea eagle feeding. Heaps of eagles circling overhead would take turns to swoop down and grab fish and fly off again. It was impressive. I think I managed to snap some good action shots with the long lens. Then we had the wedding itself. It was on the beach out the front of the Heavenly Spa on the resort. Let me say, the Westin knows how to put a wedding together. The ceremony was as lovely as the location. For the reception, the one 5 bedroom villa on the resort was booked for the night. Dinner was a buffet on the lawn out the front (briefly delayed thanks to a rain shower) and then speeches and general partying happened around the terrace out the back of the villa. There were some beautiful speeches. Janice's brought a tear to my eye. Part of the whole package included something like a 10 person video crew that were running around capturing everything. It felt a bit surreal. It was definitely the most high-end wedding I've ever been to (sorry Scott and Julie, your "Wedding of the Century" has been eclipsed by the "Wedding of the Millennium"). Monday was a wind down day. Zoe mercifully gave us a sleep in until 8am. Our flights didn't leave until the evening on Tuesday, so after we checked out we went for a drive around the island to try and get Zoe to take a nap in the car. We ended up at the fruit farm, which to the best of my understanding is run by the government. Zoe had fallen asleep by this stage, and Sarah said she'd stay behind in the car and have a nap too. So her mum and I went on the tour. It was a fun little tour. There were only four of us on it. They drive you around the farm on the back of a truck and show you the various crops they have. They stop at a few places and give you a bunch of fruit samples, attempt to answer your questions, and take funny pictures of you. The favourite seemed to be to dangle a fruit on a knife up close in front of the camera while having the subject(s) in the background look like they're carrying an enormous fruit. We got back to the car to an upset Sarah and small group of locals milling around. Sarah had managed to lock Zoe in the car for about 30 minutes when she got out to make her a sandwich after Zoe had woken up from her nap. Fortunately the engine was running and the air conditioning was on, so there was no risk of Zoe overheating (on the contrary, she was a bit on the cool side). Some kind locals had somehow figured out which car rental company to call (it's possible there's only one) and someone came out with a spare key, so the crisis was averted just before we got back to the car. It's the first time Zoe's been locked in the car (it's pretty much impossible in the Prius) and it was just our luck that it'd happen in a foreign country! One of the saddest things about Langkawi was the amount of garbage floating around in the ocean, and washing up on the beaches. I was swimming in the ocean off the yacht while we were out on the Buck's party, and it was disgusting. The jetski was temporarily disabled due to sucking in something. We visited Black Sand Beach, which was supposed to be something of a tourist attraction. Covered in trash. Ian Kiernan would be sad. The captain of the yacht we were on for the Buck's party said it was all from Thailand and got flushed out of all the rivers and streams by the recent rain. Just goes to show how connected everything is. The house is very quiet without Sarah and Zoe, but my friend Liam is visiting from Zurich for a couple of weeks, so that's helping break the silence. I'm using the time to get a heap of things done that I don't otherwise get time to get done. Unfortunately the photos from the trip are only available on Facebook at the moment, but they'll eventually get uploaded here.

I just uploaded a snapshot of GNU Screen to Debian Experimental. The package (4.1.0~20110819git450e8f3-1) is based on upstream s HEAD whose most recent commit currently dates to the 19th of August 2011. While the upload fixes tons of bugs which accumulated over the past two years in Debian s, Ubuntu s and upstream s bug tracker, I don t yet regard it as suitable for the next stable release (and hence for Debian Unstable) since there s one not so nice issue about it:

• #644788: screen 4.1.0 can t attach to a running/detached screen 4.0.3 session

Nevertheless it fixes a lot of open issues (of which the oldest is a wishlist bug report dating back to 1998 :-) and I didn t want to withhold it from the rest of the Debian community so I uploaded it to Debian Experimental. Issues closed in Debian Experimental

• #25096: digraph table should be run-time configurable
• #152961: lacks tsl/fsl/dsl caps
• #176626: mini-curses type of interface for screen -r w/ multiple screens? (Fixed by suggesting iselect, screenie or byobu)
• #223320: does not switch mouse mode
• #344759: mishandles xterm control string to set window title
• #353090: please enable the built-in telnet
• #361274: cannot reattach to sessionname if there is another session with similar sessionname
• #450421: please raise MAXWIN to at least 100 (merged with #499273)
• #461107: Requires test -t 0 even when opening a new window on existing screen
• #481411: window created with -d -m silently ignores -X exec
• #488619: Session name string escape
• #496750: screen -d -m and -D -m segfault if setenv given with no value in a configuration file
• #532240: screen with caption SEGVs when resized to 1 line tall
• #541793: C-a h (mis)documented twice
• #558724: breaks altscreen
• #560231: Please remove restriction on user/login name length
• #578729: outputs spaces when refreshing/attaching a window with defbce on
• #591624: segfault when running screen -d -m with layout save default in .screenrc
• #603009: Updating the screen Uploaders list
• #612990: /etc/init.d/screen-cleanup: should check for existence of screen binary
• #621704: Fix slow scrolling in vertical splits
• #630535: manpage typo
• #641867: version bump (this bug report sparked the upload :-)

Issues which will be closed in Ubuntu

• #183849: update to git version of screen
• #315237: crashes with certain options and terminal sizes
• #582153: doesn t accept login names longer than 20 chars
• #588846: slow when using vertical split
• #702094: Copying and pasting from mutt includes many trailing spaces
• #786292: segfaults if using layout saving with -D -m
• #788670: segfault in screen/byobu in natty

Please test the version from Experimental If you are affected by one of the issues mentioned above, please try the version from Debian Experimental and check if they re resolved for you, too. Thanks to all who contributed! A lot of the fixes have been made or applied upstream by Sadrul Habib Chowdhury who also industriously tagged Debian bug reports as fixed-upstream . Thanks! Thanks also to Brian P Kroth who gave the initial spark to this upload by packaging Fedora 15 s git snapshot for Debian and filing bug although the upload is based on the current HEAD version of GNU Screen as this fixes some more important issues than the snapshot Fedora 15 includes. That way also two patches from Fedora/RedHat s screen package are included in this upload. (Co-) Maintainer wanted! Oh, and if you care about the state of GNU Screen in Debian, I d really appreciate if you d join in and contribute to our collab-maint git repository there are still a lot of issues unresolved and I know that I won t be able to fix all of them myself. And since Hessophanes unfortunately currently has not enough time for the package, we definitely need more people maintaining this package. P.S. Yes, I know about tmux and tried to get some of my setups working with it, too. But I still prefer screen over tmux. :-)

Ubuntu has had an explicit goal for several cycles now to achieve flicker-free booting: smooth graphical boot all the way through from bootloader to the desktop, with no messy modeswitches or cuts between text and graphics mode on the console. This is no small task, to be sure; even getting flicker-free transitions between plymouth and X for the KMS-capable video cards was a handful for 10.04 LTS. So I was suitably impressed when in the course of testing for the upcoming Ubuntu 11.10 release I found that on a laptop with the nouveau driver, we had achieved 100% flicker-free boot all the way from grub to X. And then I was astonished to find the grub-kernel transition was flicker-free when using the binary nvidia driver too! This is in large part thanks to Colin Watson's work upstream implementing VBE support in GRUB2, and Andy Whitcroft's adding proper support for a vesafb fallback when no KMS video driver is found. The architecture of how this all hangs together is now documented in the Ubuntu wiki. The irony is that, while nouveau gives a perfect flicker-free boot, and the nvidia binary drivers give a boot with just one modeswitch, both of my Intel systems show two modeswitches on boot - one between grub and the kernel, another between the kernel and X. Something to work on cleaning up next month, I think...