Yes Junichi, you are correct, the behaviour of /proc/1/ cwd,root changed in 2.6.18. The relevant commit is 778c1144771f0064b6f51bee865cceb0d996f2f9. The behaviour is now really weird. readlink returns /, but in reality it points to somewhere else. Also it breaks the chroot detection.

Hello Yes, I’m sorry, it’s already a long time ago since my last blog entry. You know, I relocated and so didn’t have a lot of time. Since last week I’m “back in the world”, I have my new Internet access in the new appartement. 213.144.140.48/29 and 2002:d590:8c31::/48 are my new IPs, this meant a lot of work, specially the DNS moving was quite complex. Then also update my entry at RIPE and Switch.ch and all the other providers. Now, back to the topic, Init7. To change my provider was a plan I had already for some months, because I need some public IP adresses and a more or less fast bandwidth, then the price was also an argument. After long searching i had about 5 candidates. Finally I decided to go to Init7 because I heard a lot of positive stories about them, and I really was excited: Instead of 119.- per Month I do only have to pay 99.- because I’m a member in the LUGS, this was the first positive thing. Then I had a nice contact with the secretary of init7, when I needed something I got a fast answer by E-Mail, that was the next very positive point. And now the part which I find best: At home I have an own nameserver behind my ADSL connection. Ok, so I asked the provider if they could provide me a 2nd DNS on their side of the line. Then I got an answer from their techie which told (it’s translated): Normally we don’t provide 2nd DNS for ADSL customers. But, we can make an exception because you like this wonderful OS*. Just tell me the IP adress of your nameserver and I’ll create you access on the Web-console. * OS -> He saw in my mail signature that I’m a fan of Debian GNU/Linux. When I read this mail I really couldn’t believe it! Ok, I don’t want to make any publicity in my blog but I think a “positive echo” is necessary. The newspapers are ful of bad internet news, maybe cablecoms peerins problems, the swisscom monopol etc. The cause of all that is, they are 100% money-oriented, they don’t care about the customer. The only target for them is “get more money”. And Init7 is the opposite, they’re “customer-oriented”, they do almost everything that the customer is happy. And so I’m also motivated to pay my bills. Thank you very much for this great service, this is poorwise not the normal way in switzerland!

One new technology for saving fuel in cars is the 6 stroke engine. This is an engine that has two power strokes for every intake of fuel. The first power stroke is from the fuel burning, the second is from water being injected into the cylinder and boiling rapidly using steam for power. A significant amount of the weight of a car or truck engine is the cooling system. With water being injected into the cylinder after every burn the engine will require no other cooling, this can mean a weight reduction of up to 500KG for a truck engine! It is claimed that this technique can "improve a typical engine s fuel consumption by 40 percent". Note that this technique could be combined with the technology in a Prius for even greater efficiency.

Simon Richter wrote an interesting response to my blog about clean energy. I'm guessing that the part of Germany he's from is similar in some ways to Amsterdam (where I used to live).

In Amsterdam tiny cars are used a lot more than they have been in most places. There is the Smart Car but there is also a tiny car that can only seat one person (I'll update this entry with a link if someone provides me one). The tiny car appears to weigh ~200Kg, has a maximum speed of 30Km/h, and is narrow enough to fit in bike lanes. Such cars will take little petrol and can be used for shopping. The short-distance car idea is being used by many people already in northern Europe.

Simon suggests having a standard baggage container that fits in all cars. I don't think that would work as there are many different design factors (parking space, cargo capacity, and aerodynamics) which force designers to choose different shapes.

I think that a better idea would be a standard baggage trailer that could be towed by any small car. It should not be difficult to design a trailer that can be safely towed at 30KM/h behind a tiny car. The supermarkets could rent such trailers to shoppers for a nominal fee. Then most shopping trips could use the cargo capacity of the tiny car, but when buying supplies for a party you could rent a trailer from the supermarket.

Another option is having shops deliver goods to you. I have observed an increasing number of people doing this at my local supermarket. Of course you would still need to take ice-cream home yourself and maybe milk and meat too.

Electric scooters are also a good option for travel. Unfortunately in Australia there are few good options for securing them at the moment. As an electric scooter is light enough to be carried it needs to be chained to something secure. In the Netherlands this wouldn't be a problem as the bicycle infrastructure includes plenty of bike racks to which you can chain your bike, scooter, etc. Of course the Netherlands is entirely flat so there's no need for an electric scooter. Melbourne has a lot more hills and most people aren't fit enough to ride a bike so scooters are needed to replace cars.

Regarding depersonalised cars. That would require a significant social change as currently cars are extremely personalised. One thing that I had been thinking about is the idea of sharing cars with neighbors. For example if you have an apartment building and there are a few people you trust then you could share a tiny car for going shopping. Sharing a car used for driving to work or for entertainment would not work well as the car would spend most of it's time in use (or at least parked somewhere away from home). Sharing a car that's used for small journeys would be much easier as such a vehicle would spend most of it's time at home.

In Australia most families have two cars. One is used a lot (spends maybe 70 hours a week away from home) and the other is used much less (maybe 10 hours a week). Instead of owning two cars it would be possible for families to own one car and share another.

Regarding the Pebble Bed Reactor, could the people who advocate it please read the Wikipedia article. The limiting factor is not thermal expansion (solids do not expand nearly enough) but the Doppler effect (fast neutrons are not as effective at triggering fission). But in spite of that issue, let's not consider an untested new reactor design to be the savior of nuclear energy. I think that most people who read my blog have a science or engineering background and know from experience that new technologies often don't work too well in the first version. When a new CPU has a bug it's usually not a big deal. When a new OS or application has many bugs it's often expected (expecially when the OS or application comes from a monopolist). But if a new design for a nuclear reactor turns out to have a bug then it will be a more serious issue.

This morning, we closed on the sale of the house we've been in since 2002.

We're excited about Grandpa's farmhouse that we're having renovated, and it will be great when we get to move in there in December or January.

But it's sad to leave the place that has been home for these last few years. Terah and I got a chance to spend a few last minutes over there today.

All sorts of memories came back. We remembered our long walks up and down the driveway, hand in hand, laughing and talking. We remembered sitting out on the west edge of our property watching the sun set behind the trees. We remembered playing with our cats, having friends and family over, the excitement when we moved in, all the hard work we put into renovating the old part of the house, and so many more things.

We also been looking back and laughing at things that were really pretty annoying at the time: having no water because of ants, having to move out for a few days on Valentine's Day because of a skunk, being without power for most of a week because of ice (and having to cut my way in and out through the driveway).

We'll have memories, photos, and some small souvenirs from our old house. But we'll miss it, too, just like we missed our house in Indianapolis and its pond with attack geese. (That's another story.)

When we moved to Kansas, my grandma, who grew up a few miles away, heard our address and said, "Dutch Avenue! That's right at home for me." It was right at home for us, too.

During the past years, I have usually kept outside of heated arguments, but since I slipped on debian-private today anyway, I might as well go all the way and write a proper opinion, disguised as an outside view to simulate objectivity. Intellectual Icebergs Episode 10 talks about "Scales of Superiority". Simplified, we have a set of fields that we consider important to us, and where we will go to great lengths (and be irrational about it) to achieve a state where we can feel superior to others. To a large extent, that is what drives us on. If you think ballroom dancing is fun, you pick it up as a hobby, but if you place your "scale of superiority" in this field, you will go beyond that, and train every day, until you finally win the competition. Obviously, this is highly irrational to someone who is just not that "into it", but as they are generally not offended by you secretly sneering at their inferior dancing skillz (because they could hardly care less), this is not a problem. Now, inside Debian, we also have our scales by which we measure our success. For some of us, it is suitability for a particular field or work, for others it is rating by others. Debian has been suitable for a lot of tasks (since it is the universal operating system, after all), and has been held in high esteem for quality, so both camps were happy. So, what has changed? I believe that the biggest change was the advent of Ubuntu, and specifically, the community's reaction to it. A lot of people we considered our peers jumped ship, claiming that Ubuntu was "better". If you only cared about whether Debian was suitable for your needs, then your reaction was probably "good riddance". If you cared about peer rating, you were in hell now, as someone else was getting all the attention (and, since that is what your brain cares about really, all the MOTAS). In short, Debian's status as the superior distribution, your "herd" as the supreme rulers of the land of stability, your entire self-worth as defined by your "scale of superiority" was challenged. This is the situation we're in. Half of us feel threatened by Ubuntu, half of us do not, and to each group the behaviour of the other is completely irrational. Most of the behaviour we have seen in the past years is a direct result from this. The discussion about Ubuntu "not giving back patches" in the proper way was seen as an attempt at building a competitive advantage over Debian. That Ubuntu ships non-free drivers for hardware that is unsupported otherwise is a direct threat, because it allows them superiority in the field of hardware support. Now, with "LTS", they have even challenged our status as the distribution with the longest (heh) security support, while Debian shows severe stamina problems. That my girlfriend runs Ubuntu on her laptop is a direct threat to my masculinity, because I am unable to "perform" a network install on her laptop via wireless LAN. "I am sorry, dear, I have no idea why this device is unsupported, I never had any problems with that before." So we are looking for ways to regain our confidence. Some of us seek superiority by shifting their scales, claiming that while we're not as sexy as Ubuntu, we at least do not tie our users to our desktop, where they have to do kinky stuff to get to a harddisk, with us it is straight fsck, mount, umount. Some of us are trying to recreate Ubuntu's success by copying their methods (mandatory team maintenance, paying core developers) in the hope of eventually surpassing them. I can see that Debian also shares the goal of being a strong "contender" on the desktop, because "universal" simply includes everything, so I can understand that some developers are feeling threatened here. But I think I should ask you to get a broader view here. We are not measured by the number of one-user-only desktop installs we have. While it gives some short term satisfaction, it is not the same thing as a long-lasting installation on an university cluster and watching the users grow from nano to vi users. Debian is behaving as if it had a massive midlife crisis. I think we should try to remain calm here. Because Debian with a wig will not look young, it will look ridiculous, and in the long run, Ubuntu will either grow up, try to become another Debian (which makes them redundant), or they will stay in their niche and score the desktop users, which need not bother us at all, because they are bad in the sack anyway. I'm now going to turn myself in to Dr. Freud, and you go and get laid.

One issue that has been the topic of some pointless discussion is whether a mail server should have an A record or an MX record. Mail can be delivered to a domain that has no MX record but simply an A record pointing to an IP address. But the most common practice is to have an MX record pointing to the name of the machine that serves the mail. A common use for this is to have a bulk mail hosting machine with multiple MX records pointing at it, which then allows you to have matching forward and reverse DNS entries for the machine name.

If you have no MX record for a domain then Postfix will do the following DNS requests:

IP postfix.34245 > DNS.domain:  3448+ MX? example.com. (32)
IP postfix.34261 > DNS.domain:  50123+ A? example.com. (32)

If you have an MX record then it does the following:

IP postfix.34675 > DNS.domain:  29942+ MX? example.com. (32)
IP postfix.34675 > DNS.domain:  33294+ A? mail.example.com. (37)

Now if there are multiple domains on a bulk mail hosting system then the A record might already be in a local cache on the sending machine, so having bulk mail hosting with MX records may reduce the number of DNS lookups, with the minumum number of lookups being half plus one.

If there is no bulk mail hosting then an MX record would still offer some slight benefits if the positive responses are cached for longer than negative responses. This would mean less lookups which gives faster and more reliable delivery of mail plus being more friendly to the net. I don't know what the cache behaviour is in this regard so I'm not sure if this would actually give a benefit (I'm sure someone will comment with the answer).

Now regardless of these issues I think that using an MX record is the better option. It's what most software expects and saves you from the excitement of discovering corner case bugs in various software that's out there on the net.

I'm glad to see that Debian vote 2006-06, to reaffirm support for the Debian project leader, has passed, and that associated counter-proposals to recall the DPL have been defeated. The central issue has been Dunc Tank, a project to raise money to support certain Debian developers with the goal of getting Debian's next release, etch, out on time. There's been more heat than light on this issue over the last few weeks in various Debian- and Linux-related venues (mailing lists to media), and I'm happy to see that we've come to a conclusive resolution and can hopefully put the issue behind us. I've been impressed with Anthony Towns's aplomb in dealing with this issue, and I'm glad that he'll be staying in the DPL seat. We have one of the best, if not the best, Linux-based Operating Systems available. But Debian's late releases have become a laughingstock, and our users have to resort to backports and workarounds to keep running a stable release version of our software. With luck, putting extra resources into getting out a release will serve our users better and restore our reputation for delivering software in a timely fashion. tags: debian dpl anthony towns dunc tank gr

Daisy, Daisy, give me your answer, do The wp:2001: A Space Odyssey (film) jokes are probably a little too thick on the ground, but I'm glad to see the launch of the HAL Project at le Sans Fil. HAL is a distribution system for getting locally-produced digital art, music and video out on a community wireless project like le Sans Fil. Kinda puts the "community" back into "community wireless"... a great idea. The HAL Project software is of course available for download as an Open Source project, which is good news for other community wireless projects out there. tags: ilesansfil isf hal wireless local

Dear Bubulle, I am afraid that you do not know what you are talking about. Because you aren’t the only one in this case, here’s a short explanation of what happened. The existence of the IceWeasel fork is a reality that the Mozilla people need to accept and, optionally, understand (they also need to remember what Free Software is and how it all works). Unfortunately, some of the Mozilla people at the JDLL yesterday obviously couldn’t bear a little reminder about IceWeasel, but they were the minority. We hung the two posters in the morning, and they did not even notice them for something like 45 minutes. After what, somebody came and asked, in what can be described as an angry manner, if we knew why the IceWeasel fork got started. The answer was a plain and simple “I don’t care why the fork started. We’re going to rename Firefox in Debian so you people stop annoying us with your fucking trademark.” (which was obviously as rude an answer as their original question). At which point they just went away and never came back. They proceeded to fix the Firefox poster by adding a “TM” on it and, I think, fixing the capital “F” in the middle of the “FireFox” name, then stroke the “IceWeasel” line on the other poster. At this point, photos were taken and posted to one, then two blogs. Sam, for the sake of completeness, added the missing and markings to the Firefox poster, which the Mozilla people forgot to add. The whole thing could have stopped at that point, but Daniel Glazman, the famous Daniel Glazman, thought it’d be wise to link the first two blog posts on his blog, vomitting on Debian while he was at it. This was an extremely bad idea. His blog being syndicated on Planet Mozilla, he and the other Mozilla people are just helping spread the IceWeasel name and publicising the whole Mozilla trademarks debacle. I’m just not going to comment on the behaviour of the most vocal Mozilla supporters (no, dear Daniel Glazman, I’m not going to use the term “fanatics”, I leave that up to you), it’s just not worth bothering. Josselin linked the first blog post on his blog, so the thing made it to Planet Debian, too. This is no big news for Planet Debian readers, as the IceWeasel situation has been discussed at length on various blogs already. Now, what you Christian do not know, is that we have had several discussions about the Mozilla trademarks problems at the JDLL. Many people here were not aware of this problem and asked both the Mozilla people and us about it. We explained at length, several times, what happened, what their position was, what our position was, what had been proposed by both parties, why their proposals weren’t acceptable to us. Most of the people were quite astonished to learn that Mozilla Corporation refused the “Community Edition” idea, and most of them got our point. At the end of the day, one of the Mozilla people came and apologized for the blog posts and comments (although he isn’t the author of any post or comment, I believe), telling us that it wasn’t nice from them. Thanks for that, really. Overall, all of this is very positive for the Debian Project. We are doing the Good Thing. To everybody in Debian involved in the renaming of the Mozilla products: thanks, and good luck. Mozilla Corporation now has to face the Free Software community. It’s up to them to either come up with something that is acceptable for the community or stop whining about people complying with their trademark policy. Internet Explorer still has something like 82% of the market. You aren’t done yet, and you’re not going to progress without community support. So you’d better not lose this support now. Up to you.

I really love the idea behind that project and after some Perl people complained they now also accept submissions from Perl developers. So if you live in or around Germany and would like to do some propaganda for your favorite web framework, apply right now, as long as your favorite web framework is based on Perl. :-)

The kernel team, or should I say, Sven Luther, as the rest of the kernel team hasn't been remotely as visible as him on this topic, is now trying to spam debian-devel-announce, assuming the average Debian developer isn't able to read the proposals. Fortunately, the mail was redirected to debian-devel thanks to clever filtering.

I still think, for the moment, that Choice 2 of the proposal currently being voted (Special exception to DFSG2 for firmware as long as required) is still the best of all proposed choices, and I'll try to explain why.

1. This proposal doesn't only address firmware issues. It clarifies DFSG 2 for other works often found without source, acknowledging current practice for fonts or pictures.
2. Granting an exception only for etch is dishonest. The real reason behind the exception is that we don't yet have any means to ship these firmwares in a way that complies with our principles. We're violating them in the testing and unstable distributions as well, and that has nothing to do with a release.
3. Granting an exception for etch may not be sufficient. I don't want to see these endless discussions again for the next release, and this is what is probably going to happen if an etch-only exception is granted.
4. The proposal frees the hands of people working on stripping the firmwares out. Their patches would have to be accepted straight away, not two months before the release when someone says "Hey! there are non-free firmwares in the kernel!".
5. By principle. I'm fed up with people splitting hair on debian-vote for weeks, to end up reaching a formulation that's close to the one I wrote in a few minutes a month ago.

Everyone should make up his own opinion. You're welcome to read the proposals themselves rather than the propaganda I'm writing, but I hope I've made clearer the rationale of Choice 2.

If you search on Google for 'youtube sex', my blog comes out as #3+#4, just behind youtube itself. Sooo funny, because I never actually wrote about Sex on YouTube. Actually I don't like YouTube (which to me still sounds like a bad translation of a german insult). But there is this blog posting of mine, which lists the top tags according to technorati, when war tags had actually surpassed youtube and sex as tags. Yes, it mentions "youtube, sex". Once. But no, these are not essential, no referrer uses them, no other blog posting. Why does it show up as second site after YouTube.com itself? Oh, I'm also #3 for "youtube bush" right now, with the raw RSS feed of my blog. What is it with Google and my blog? There must be some odd effect with Googles ranking that makes my site shoot up like crazy. And it has been like that for at least one and a half year now. Back then I blogged about IBM failing to repair my laptop. This was the first time I noticed a really absurd Google ranking of my blog, when this became a top #10 result for "IBM repair". Guess I really should go into the SEO or webdesign business. If I weren't just more interested in research and software development... [Update: dropped to #14 for 'youtube sex']

So it's been pointed out that since I'm no longer terribly involved in Debian, I possibly shouldn't be on Planet Debian nowadays. So unless there's any violent objections I'll ask to be removed at the end of the week - my RSS gunk is at http://mjg59.livejournal.com/data/rss for those who want to read my delightful prose in any case.

Anyway. Some token Debian-related content. Mozilla corp are unhappy with Debian providing a package called "firefox" unless every patch provided has been approved by Mozilla in advance (there's also some stuff about the logo, but that's basically a bizarre corner aspect of the same problem). I'm not going to argue against this on philosophical grounds - it's clear that that isn't going to change anybody's mind. Instead, let's compare this to some other major applications:

• Linux. Pretty much every vendor patches Linux. Part of this is for hardware support (adding out of tree drivers, and so on), but a great deal of it is feature development. A lot of patches that appear on LKML have already shipped in vendor kernels.
  
• X. Arguably one of the most forked applications shipped by any distribution - almost every X server shipped by any vendor ever is based on the reference X11 code. Without the right to fork X and maintain its name, we wouldn't have the X.org implementation[1]. No composite, no accelerated indirect 3D rendering, no input or monitor hotplugging.
  
• Gnome. Vendor patches to Gnome have largely been concentrated on branding and defaults, but in some cases we've seen major functionality changes. The new menu applet in SLED 10 is an example of this, and depending on how it's received it's likely to influence upstream development.
  

On the Mozilla side of things, the closest I can really come up with is cdrecord. There's some pretty strong parallels (upstream being unhappy about various patches, requiring a sufficiently different work to have a different name), but the end result in the cdrecord case was that we ended up with an application that was poorly integrated with the rest of the Linux environment for the sake of remaining consistent across different operating systems.

I'm not saying that that's going to happen to Mozilla. But we've seen numerous cases where allowing vendors to distribute derived versions has encouraged development and testing of new ideas, and I think in most cases that's resulted in benefits to the upstream project. The fundamental problem with refusing to allow patches that cause significant deviations from upstream behaviour is that it makes it impossible for anyone to actually get things like UI experiments into the hands of users. With Gnome, if upstream don't like your idea you have the opportunity to prove them wrong and possibly change their mind. With Mozilla, if upstream don't like your idea you're pretty much screwed. Most distributions are going to be unhappy about losing the magic Firefox branding, so you're unlikely to sell them on it. And you're not even allowed to provide binaries or source on your website unless you've renamed it away from Firefox.

I think the Mozilla corporation are missing something here. We shouldn't be prizing cross-platform consistency over integration and innovation, and we certainly shouldn't be doing our utmost to make it difficult for people to experiment with code. There's a reason that cd writing under Linux has been sucky for years, and it's not because people lacked the technical ability to make it better.

[1] Ok, the X.org case is slightly confused by the fact that they are upstream now. But without the ability to fork under the same name, they wouldn't have been.

I've been a fan of the Open Directory Project for a long time. I finally volunteered to become an editor about a month ago, and I just started editing my first category, wiki farms , today. I hope to get the category up to good shape in the next few days. I've now got an ODP profile, too. tags: odp dmoz directory editor wikifarms

Hudson Maj, Amita June and I went down to wt:Hudson (New York) over the weekend for the wedding reception of our friends Morgan and Kate. The trip down was fantastic -- the colors in the wt:Adirondacks were really amazing, just hitting their peak. Amita June had a good drive, too: she got to look around a lot, listened to some music, and had a nap of about an hour and a half. Hudson was a cute town, but not cutesy like other parts of the wt:Hudson Valley can be. The town is small -- 4-5 streets wide -- with big brick buildings lining the main street down to a promenade overlooking the Hudson River. There are a few gourmet restaurants and a disproportionate number of art galleries and antique stores, but it doesn't feel like the locals have been pushed out of their town... yet. We stayed at the St. Charles Hotel, as arranged by Kate's stepmom for most of the guests. It was functional and clean but otherwise unexceptional. There was a bar and a restaurant downstairs, and the hotel itself is just opposite a nice little park. Sunday morning we had breakfast at the Earth Kitchen organic market; I had a bowl of granola and fruit, Maj had a huge plate of huevos rancheros, and AJ ate whatever she could get off our plates. We walked around town and down to the waterfront, where we got a panoramic view for miles up and down the Hudson Valley. With the leaves nearing their height of color, it was an awe-inspiring view. We took a late lunch at Mexican Radio, a branch of a restaurant by the same name in Manhattan. It had good quality California-style Mexican food, with a few fusion dishes (like "Mexican spring rolls") that were probably overdoing it a bit. The margaritas were top-notch, and they have a tequila sampler option with three excellent tequilas for... $125! You won't normally lose that much money on three shots of tequila unless you pass out in the gutter in wt:Nuevo Laredo. The reception itself was at the Ca' Mea restaurant, right next to the historic Hudson Opera House. Kate and Morgan were in good form, playing goth-y music from their early days, and family and friends had a good time too. We all probably ate too much, and Maj and I both had hangovers the next morning. Amita June, however, had an excellent time running around the party and dancing with the bride. She was made for weddings. The drive home the next day was less than optimal. We did brunch in the St. Charles's restaurant, Bridges, and then stopped by the house of Kate's dad and stepmom for an afternoon get-together. They have a really nice Victorian house on a hill above town that overlooks the valley. We had to leave after only a few minutes, though, since we'd been lucky enough to get guest-listed for the Massive Attack show in Montreal that night. Trouble hit us as we were coming up the 87, though. First, the baby refused to sleep, getting more and more hysterical the longer she went awake. By 4:30PM, we'd had to stop so many times to soothe her that we were starting to get worried about the time. Then, we hit a detour on the interstate -- a huge accident had happened going through the mountains. We got into a sluggish line of cars wending its way along highway 9, and by the time we were back on the interstate we knew we were going to be late. We decided that luck was against our going to see MA, so we called and canceled our baby-sitter and sent email to our friend DJ Ghostbeard who'd asked us to come to the show (although we didn't get a call through... his voicemail box was full). We stopped at Geoffrey's Pub in wt:Plattsburgh for a late dinner of blackened salmon, broiled seafood and mashed potatoes, and then got back on the road. ...and straight into a 2-1/2-hour line at the Canadian border. This weekend was Canadian Thanksgiving, and apparently a lot of people took the opportunity to dip down into the states for a last bit of outdoorsmanship before the winter frosts settled in. Amita June, already a little frantic from not sleeping, went completely ballistic, and although we managed to keep her mellow most of the time, 2 hours in a line of cars with a crying baby is a little bit much for anyone. We didn't get back to Montreal until nearly midnight. It was great to get home, finally, and as usual travel's made me appreciate staying in one place. The Gazette this morning says the Massive Attack show was excellent, but I'm glad we didn't try to make it -- coming in 4 hours late is just too much. We're off to wt:Halifax next weekend for our wedding anniversary, and hopefully we'll be back into travel mode by then. tags: hudson kate morgan amitajune hudson valley adirondacks plattsburgh massive attack

Destinyland Dave Cassel has an excellent list of the 100 Greatest Internet Moments. A great compendium of Stuff What Happened over the last 10 years in cyberland. I think Dave's one of the best Internet culture observers out there. I'm glad to see he's got a new podcast, Destinyland, in which he tears apart the weird media culture we live in. Example: the crazy spiral of Dana Plato. Example: Schoolhouse Rock: Behind the music. Example: Dark side of the Hampster Dance. Good stuff. tags: destiny destinyland podcast dave cassel

So while I was trying to fix my RC bug this long weekend I found out it no longer exists, the problem I mean. libGL.so now points to libGL.so.1 which will exist. This now raises another problem as this is probably not the behaviour sought when nvidia-glx is installed. Fortunately the way I was going to fix the RC bug can be slightly modified to cure this issue.

Barbicane asked me the other day: “Why Ichthux and Ubuntu CE? Why not consolidate efforts?” As much as I’d like to see Ubuntu CE succeed, I believe they are headed down a path that will make it difficult for them to survive if they continue. In this thread (see Google cache since the forums seem to be having problems today) Jereme severely understates the differences in development philosophies that keep us apart. One key difference is more fundamental than just using metapackages instead of scripts. As I wrote about earlier, the approach Ichthux has chosen is to be a Custom Debian Distribution (CDD), working within Debian and Ubuntu to configure those distributions for the needs of Christians to meet their various needs. This is incompatible with CE’s approach, which uses scripts to tailor an Ubuntu system. This approach risks violating the integrity of the packages being modified, and makes each system upgrade an adventure for the user. What you end up with cannot truly be called an “edition” of Ubuntu at all, but is more accurately described as an Ubuntu derivative. Derivatives are not easily sustained because they are always struggling with staying in sync with the parent distribution. Ubuntu itself is a derivative, but it has an impressive amount of infrastructure with a lot of manpower behind it to ensure that the branching and merging process doesn’t get out of control. I don’t see how the much smaller Ubuntu CE development team will manage to accomplish anything significant using their current approach without being crushed by the maintenance costs of their customizations. Another difference, perhaps more readily apparent to end users, is what’s included in each distribution by default. While CE has chosen the Gnome desktop, Ichthux has gone with KDE. With each new release of Ubuntu CE, it seems what is stressed the most in their release notes is “what’s included”. Well, I just can’t see how that’s terribly important. Debian and Ubuntu both have a vast amount of software available, and both make it easy for users to make choices. If a user wants to add another application, it’s often just a few clicks away. It’s not nearly as important to have these installed by default as it is to ensure that the packages we do include are as solid and well-integrated with the system as possible. To this end, Ichthux makes use of its Debian and Ubuntu developers to ensure that each package included is kept in good shape from release to release. This means addressing bugs and wishlists that matter to our users, improving those packages not just for Ichthux, but for Ubuntu, Debian, and where those fixes flow back upstream, the broader community of Christian FOSS users everywhere. This is the real work of Ichthux: not just the production of a livecd, nor merely tweaking the default selection of packages we include from one release to the next, but to be actively involved in the Christian FOSS developer and user community. Our greatest successes will not be in the degree to which we differentiate ourselves from other Linux distributions, but rather how well we’re listening to what Christian FOSS users are saying they need, and how broad we can make our solutions. We can’t afford to be a niche distribution working off in a corner on our own pet project. That would be a terrible waste of our energy. We’re dreaming big: we want every Christian Linux user to be able to benefit from our work.

Via Jesse, this strangely beautiful commercial for some sort of beverage I’ve never heard of. Featuring fruit. Update: apparently I’m out of touch with the zeitgeist. The fruit video is apparently a somewhat authorized parody of this Sony Bravia ad. In fact, I didn’t even know what a Sony Bravia was until now. Update 2: I guess I’m really behind the times. Wikipedia has known all about this Tango ad business since at least June 14, 2006. Now there’s some effective advertising.

Martin 'Joey' Schulze is still aggressively writing against Dunc tank. I don't agree with his posting at all. I don't think dunc-tank is doing any serious damage to the project; so far all the damage comes from a few people (especially you, Joey), that play some "politics" game here I don't really get or like. And just count the number of people who have expressed discomfort with your postings. I remember having seen the word "blackmail" attributed to some of your mails. [Update: and it also sucks that people have to point out that they didn't reduce their Debian involvement because of Dunc tank, but just because they don't use the software anymore, have too little time or are annoyed by your behaviour; otherwise you'd probably cite them as dunc-tank enemies.] I'm also convinced that your assessment - that only the release in december counts - is false. You know, the people working on Debian were NOT replaced by the announcement of the dunc tank experiment. We still want to make Debian the "Universal OS", and are still dedicated to the projects goals. But some of us still remember the bad press debian has been receiving because of the delays with sarge release, and the users we have lost back then because of pushing back the release again and again. You know, many people still act like "yeah, debian releases in december, sure, when hell freezes over". One of Debians strengths was security support. But security support doesn't work as well, when half of the software you're running are unsupported backports. If Debian wants to remain a good base choice (i.e. universal OS), it needs to provide a reliable combination of secure but not too-out-of-date software to become useless again. Therefore I consider frequent-enough, somewhat-on-time releases important for the universal OS idea; this will also cut down on our work (at least for those doing backports, too, since we need to do less of them). It's not a primary goal, but a consequence of the well-established goals. Now why I accept the experiment of 'hiring' the release managers for one month full-time: I've always had the impression that donating to Debian is somewhat pointless, because I don't see any concrete results, or where the money is going. To me it always felt like it ends up in an unused saving account with the SPI treasurer, until someone finds a way to spend it. Here the money is used in a transparent way, on well-respected people and with a very concrete result. And remember, it's an experiment. It's a one time thing so far. Oh, and to actually counter all your blah-blah: I've actually recently increased my Debian efforts again. Because of the dunc-tank thing, and despite your end-of-the-world-claims. Namely because it gave me back the feeling that someone actually cares about making Debian useful to everbody (and not just us freaks running unstable and experimental). That there is some interest in getting the new release out of the door on time, of supporting our users out there such as the city of munich (which is also running backports AFAIK). To me Debian is still mostly about the users, not about the ego of developers. Be a nice guy and do a good job, and you'll get lots of thank yous, a couple of friends, a couple of patches, some free beer or tshirts in return. Does this corrupt as well, getting a free coke? Yes, I got a free Jolt coke four years ago at Systems. Does this make you demotivated, that you didn't get one, too?

I was planning to set up my laptop from scratch for a while now... so I did. Preparation

• First, go home. No, really! Do all of this at home in a non-hostile, firewalled network. You don't want to be in a crowded place such as a conference where people can shoulder-surf your passwords, nor do you want your network traffic sniffed or MITM'd in a hostile network.
• Backup all your data! You'll be wiping your whole drive soon, so make sure you have recent, tested backups.
• Get the most recent Debian-installer ISO image (currently etch-beta3), as well as the MD5SUMS and MD5SUMS.sign files:
wget http://cdimage.debian.org/cdimage/etch_di_beta3/i386/iso-cd/debian-testing-i386-binary-1.iso
wget http://cdimage.debian.org/cdimage/etch_di_beta3/i386/iso-cd/MD5SUMS
wget http://cdimage.debian.org/cdimage/etch_di_beta3/i386/iso-cd/MD5SUMS.sign
• Run gpg --verify MD5SUMS.sign, which will fail but tell you the signing key ID (88C7C1F7 in this case). Get the key and re-run the verification: gpg --recv-key --keyserver subkeys.pgp.net 88C7C1F7 && gpg --verify MD5SUMS.sign. The output should now say "Good signature from [...]".
• Now check the MD5 checksums via md5sum -c MD5SUMS. The output should contain debian-testing-i386-binary-1.iso: OK.
• As you now have (somewhat) verified the integrity of the ISO image, burn it on a CD-R: wodim debian-testing-i386-binary-1.iso.
• Put trusted versions of some files on a USB thumb drive (or CD-ROM); at least a firewall script, but maybe also your bashrc, bash_logout, inputrc, vimrc, muttrc.
• Disconnect your laptop from any kinds of networks. Pull all ethernet cables. Disable WLAN (via hardware killswitch). Disable Bluetooth. Disable/remove Firewire, USB, serial, whatever.
• Put on your tin-foil hat (optional).

BIOS

• Set a good BIOS boot password (which you need to boot any OS). Set a (different) good BIOS boot setup password (which you need to enter the BIOS).
• Disable all boot possibilities in the BIOS, except for CD-ROM. This means it should not be possible to boot via USB, hard drive, network, PXE, Firewire, floppy, whatever. The BIOS setup password helps to prevent tampering with this setting.
• Finally, never rely on BIOS passwords alone for security! They can often be circumvented very easily.

Installation / Setting up full-disk encryption using dm-crypt

• Insert the installer CD and boot in expert-mode (don't hit ENTER when you boot, but rather type "expert").
• As for networking: select "Do not configure the network at this time". We'll fix and enable networking later.
• Partitioning:

• Select manual partitioning. Remove all partitions (if any). Create a 100 MB /boot (ext3) as primary partition, and make the rest of the hard drive one huge partition which has "Use as:" set to "physical volume for encryption".
• The standard options for cipher, key size, IV mode etc. should be fine (AES, 256 bit, CBC-ESSIV-SHA256, dm-crypt).
• After the erasing is done (this is important!), use the whole encrypted space as "physical volume for LVM". Then select "Configure the Logical Volume Manager". Create one big volume group and a bunch of logical volumes for the various partitions we'll use (lv-root, lv-usr, lv-var, lv-tmp, lv-swap, lv-home).
• It is extremely important that your swap space is encrypted (in this case it is, as all partitions except for /boot reside on a dm-crypt device)! Never set up unencrypted swap!

Enable shadow passwords. Allow login as root (I feel confident that I won't do stupid things as root).

Choose a good root password, and a (different) good user password. Don't enter a full name for the user.

Choose the latest kernel (old kernels might have security issues). Do not participate in popcon.

Do not install any tasks (no "desktop", no "base system"). We want the smallest installation possible, and add only the packages we really need. Fewer packages means fewer security issues (statistically).

That's it. Eject the CD-ROM, reboot, change the BIOS to only allow booting from hard drive.

Post-installation tasks

• Enter the USB thumb drive, copy all config-files to /root and /home/uwe. Log out and log in again to make ~/.bashrc and ~/.inputrc take effect.
• Enable the firewall: mkdir /etc/rc.boot && cp fw_laptop /etc/rc.boot && chmod 700 /etc/rc.boot/fw_laptop && sh /etc/rc.boot/fw_laptop
• Shut down all networked daemons (if any): /etc/init.d/foo stop.
• Tighten home-directory permissions: chmod 700 /root /home/uwe.
• Edit /etc/passwd: give all users except for root, sync, uucp and your user account /usr/sbin/nologin as login shell. None of these accounts really needs a valid login shell (nologin will log any login attempts for those accounts).
• Edit /etc/group: remove your user account from the dialout, cdrom, and floppy group. The groups audio, video, and plugdev can stay.
• Edit /etc/fstab: add some mount options such as ro, nosuid, noexec, or nodev as you see fit. Example:
  

  /dev/mapper/vg--whole-lv--root /     ext3 defaults,errors=remount-ro      0 0
  /dev/sda2                      /boot ext3 defaults,nodev,nosuid,noexec,ro 0 0
  /dev/mapper/vg--whole-lv--home /home ext3 defaults,nodev,nosuid           0 0
  /dev/mapper/vg--whole-lv--tmp  /tmp  ext3 defaults,nodev,nosuid           0 0
  /dev/mapper/vg--whole-lv--usr  /usr  ext3 defaults,nodev,ro               0 0
  /dev/mapper/vg--whole-lv--var  /var  ext3 defaults,nodev                  0 0
  /dev/mapper/vg--whole-lv--swap none  swap sw                              0 0
  /dev/scd0 /media/cdrom iso9660 noauto,nodev,nosuid,noexec,uid=uwe,gid=uwe 0 0
  

• If you have read-only (ro) file systems, configure Apt so that it can remount them read-write when installing/removing packages. Add this to /etc/apt/apt.conf:
  

  DPkg
   
    Pre-Invoke   "mount -o remount,rw /usr; mount -o remount,rw /boot";  
    Post-Invoke   "mount -o remount,ro /usr; mount -o remount,ro /boot";  
   
  

• Fix the GRUB configuration. Replace the "password foo" line (which contains the GRUB password in plain-text) from your /boot/grub/menu.lst with a "password --md5 $1$1234567890..." line, where the MD5 hash ($1$1234567890...) can be generated with grub-md5-crypt. Additionally, add such a password line after each "title" line in the GRUB config-file, so that nobody can boot any OS installed on the laptop without a password!

Networking, Upgrading and Apt-secure

• Now that we have a small, hardened system, it should be reasonably safe to enable networking. Add this to /etc/network/interfaces:
  

  auto eth0
  iface eth0 inet dhcp
    pre-up /etc/rc.boot/fw_laptop
  

  Run /etc/init.d/networking restart. The firewall script will run every time the network is started.
• Now add this (tweak as you see fit) to /etc/apt/sources.list:
deb http://ftp.de.debian.org/debian unstable main
deb-src http://ftp.de.debian.org/debian unstable main
• Time for upgrading: apt-get update && apt-get dist-upgrade. All packages are GnuPG-signed and will be verified by Apt. The installer already ships the required key (for 2006), so everything should just work. Still, you should read about SecureApt.
• Install the rest of your system now, and restore your data from backups.
• Use sysv-rc-conf to disable all daemons you don't want to start per default: sysv-rc-conf foo off.
• Install and set up Samhain (or any other file integrity checker): apt-get install samhain. You want to be notified if your system files are being tampered with (e.g. replaced by a rootkit).
• Install and configure Tor for anonymous browsing. More details here.
• Install and configure more security-related programs, e.g. logcheck, snort, rkhunter, chkrootkit, tiger, sxid, etc.

SELinux Now install and set up SELinux. This section is based on notes from Erich Schubert (thanks!), and will soon appear in the SELinuxSetup wiki page, too.

• Install the base packages and an SELinux policy: apt-get install selinux-basics selinux-policy-refpolicy-targeted.
• Edit /boot/grub/menu.lst and add selinux=1 to your kernel command line to enable SELinux upon booting.
• In /etc/pam.d/login uncomment the "session required pam_selinux.so multiple" line. Do the same in /etc/pam.d/ssh if you have ssh installed.
• In /etc/default/rcS set FSCKFIX=yes.
• In /etc/init.d/bootmisc.sh search for "Update motd" and comment the two lines below that line. Then rm /var/run/motd.
• If you have exim installed, you must either install postfix or write an exim policy, as none currently exists. But even postfix needs some fixing (no pun intended ;-). Disable chroot-support (change all "chroot" fields to "n" in /etc/postfix/master.cf and execute echo 'SYNC_CHROOT="n" >> /etc/default/postfix').
• Use check-selinux-installation to check for common SELinux problems on Debian (such as the above mentioned).
• touch /.autorelabel. Reboot. touch /.autorelabel (again). Reboot (again).
• Done. You should now have a working SELinux system. If no critical audit errors appear and you feel comfortable with SELinux, enable enforcing mode via setenforce 1 or by adding enforcing=1 to the kernel command line in /boot/grub/menu.lst.

Behaviour

• Never leave your laptop unattended!
• Always lock your terminal (using vlock) when you move more than 30 cm away from the laptop!
• Don't run insecure and/or closed-source software (which you can never trust!). No NVIDIA/ATI drivers, no VMware, no Google Earth, no Flash Plugin (except for Gnash maybe), no Adobe Acrobat. You get the idea.
• Keep the number of installed packages small and try to configure each of them as secure as possible.
• Never enable networking or WLAN or Bluetooth if you don't absolutely have to.
• Trust no one. Don't let other people use you laptop, don't give out shell accounts.

Further ideas

• The /boot partition is still unencrypted, so an attacker can tamper with it. Boot from a CD-R, forbid booting from hard drive (BIOS). Sign/mark the CD-R physically, so you'll know when someone replaced your CD-R with his own, back-doored one.
• Another idea is to use an additionaly USB thumb drive or CD-ROM or smartcard for two-factor authentication.
• Install another Debian into a QEMU image. Use it as a sandbox for stuff you don't trust: qemu -snapshot -net none foo.img.
• At all costs, disable Firewire! If possible via hardware or BIOS, or at least don't load the drivers and/or fix them (page 19).
• Replace the proprietary, closed-source BIOS with LinuxBIOS, if possible.

That's it. You can take off that stupid tin-foil hat now. Update 2006-09-29: Fixed typos. Mentioned sxid. Added two-factor authentication.

I was planning to set up my laptop from scratch for a while now... so I did. Preparation

• First, go home. No, really! Do all of this at home in a non-hostile, firewalled network. You don't want to be in a crowded place such as a conference where people can shoulder-surf your passwords, nor do you want your network traffic sniffed or MITM'd in a hostile network.
• Backup all your data! You'll be wiping your whole drive soon, so make sure you have recent, tested backups.
• Get the most recent Debian-installer ISO image (currently etch-beta3), as well as the MD5SUMS and MD5SUMS.sign files:
wget http://cdimage.debian.org/cdimage/etch_di_beta3/i386/iso-cd/debian-testing-i386-binary-1.iso
wget http://cdimage.debian.org/cdimage/etch_di_beta3/i386/iso-cd/MD5SUMS
wget http://cdimage.debian.org/cdimage/etch_di_beta3/i386/iso-cd/MD5SUMS.sign
• Run gpg --verify MD5SUMS.sign, which will fail but tell you the signing key ID (88C7C1F7 in this case). Get the key and re-run the verification:gpg --recv-key --keyserver subkeys.pgp.net 88C7C1F7 && gpg --verify MD5SUMS.sign. The output should now say "Good signature from [...]".
• Now check the MD5 checksums via md5sum -c MD5SUMS. The output should contain debian-testing-i386-binary-1.iso: OK.
• As you now have (somewhat) verified the integrity of the ISO image, burn it on a CD-R: wodim debian-testing-i386-binary-1.iso.
• Put trusted versions of some files on a USB thumb drive (or CD-ROM); at least a firewall script, but maybe also your bashrc, bash_logout, inputrc, vimrc, muttrc.
• Disconnect your laptop from any kinds of networks. Pull all ethernet cables. Disable WLAN (via hardware killswitch). Disable Bluetooth. Disable/remove Firewire, USB, serial, whatever.
• Put on your tin-foil hat (optional).

BIOS

• Set a good BIOS boot password (which you need to boot any OS). Set a (different) good BIOS boot setup password (which you need to enter the BIOS).
• Disable all boot possibilities in the BIOS, except for CD-ROM. This means it should not be possible to boot via USB, hard drive, network, PXE, Firewire, floppy, whatever. The BIOS setup password helps to prevent tampering with this setting.
• Finally, never rely on BIOS passwords alone for security! They can often be circumvented very easily.

Installation / Setting up full-disk encryption

• Insert the installer CD and boot in expert-mode (don't hit enter when you boot, but rather type "expert")
• As for networking: select "Do not configure the network at this time". We'll fix and enable networking later.
• Partitioning:

• Select manual partitioning. Remove all partitions (if any). Create a 100 MB /boot (ext3) as primary partition, and make the rest of the hard drive one huge partition which has "Use as:" set to "physical volume for encryption".
• The standard options for cipher, key size, IV mode etc. should be fine (AES, 256 bit, CBC-ESSIV-SHA256).
• After the erasing is done (this is important!), use the whole encrypted space as "physical volume for LVM". Then select "Configure the Logical Volume Manager". Create one big volume group and a bunch of logical volumes for the various partitions we'll use (lv-root, lv-usr, lv-var, lv-tmp, lv-swap, lv-home).
• It is extremely important that your swap space is encrypted (in this case it is, as all partitions except for /boot reside on a dm-crypt device)! Never set up unencrypted swap!

Enable shadow passwords. Allow login as root (I feel confident that I won't do stupid things as root).

Choose a good root password, and a (different) good user password. Don't enter a full name for the user.

Choose the latest kernel (old kernels might have security issues). Do not participate in popcon.

Do not install any tasks (no "desktop", no "base system"). We want the smallest installation possible, and add only the packages we really need. Fewer packages means fewer security issues (statistically).

That's it. Eject the CD-ROM, reboot, change the BIOS to only allow booting from hard drive.

Post-installation tasks

• Enter the USB thumb drive, copy all config-files to /root and /home/uwe. Log out and log in again to make ~/.bashrc and ~/.inputrc take effect.
• Enable the firewall: mkdir /etc/rc.boot && cp fw_laptop /etc/rc.boot && chmod 700 /etc/rc.boot/fw_laptop && sh /etc/rc.boot/fw_laptop
• Shut down all networked daemons (if any): /etc/init.d/foo stop.
• Tighten home-directory permissions: chmod 700 /root /home/uwe.
• Edit /etc/passwd: give all users except for root, sync, uucp and your user account /usr/sbin/nologin as login shell. None of these accounts really needs a valid login shell (nologin will log any login attempts for those accounts).
• Edit /etc/group: remove your user account from the dialout, cdrom, and floppy group. The groups audio, video, and plugdev can stay.
• Edit /etc/fstab: add some mount options such as ro, nosuid, noexec, or nodev as you see fit. Example:
  

  /dev/mapper/vg--whole-lv--root /     ext3 defaults,errors=remount-ro      0 0
  /dev/sda2                      /boot ext3 defaults,nodev,nosuid,noexec,ro 0 0
  /dev/mapper/vg--whole-lv--home /home ext3 defaults,nodev,nosuid           0 0
  /dev/mapper/vg--whole-lv--tmp  /tmp  ext3 defaults,nodev,nosuid           0 0
  /dev/mapper/vg--whole-lv--usr  /usr  ext3 defaults,nodev,ro               0 0
  /dev/mapper/vg--whole-lv--var  /var  ext3 defaults,nodev                  0 0
  /dev/mapper/vg--whole-lv--swap none  swap sw                              0 0
  /dev/scd0 /media/cdrom iso9660 noauto,nodev,nosuid,noexec,uid=uwe,gid=uwe 0 0
  

• If you have read-only (ro) file systems, configure Apt so that it can remount them read-write when installing/removing packages. Add this to /etc/apt/apt.conf:
  

  DPkg
   
    Pre-Invoke   "mount -o remount,rw /usr; mount -o remount,rw /boot";  
    Post-Invoke   "mount -o remount,ro /usr; mount -o remount,ro /boot";  
   
  

• Fix the GRUB configuration. Replace the "password foo" line (which contains the GRUB password in plain-text) from your /boot/grub/menu.lst with a "password --md5 $1$1234567890..." line, where the MD5 hash ($1$1234567890...) can be generated with grub-md5-crypt. Additionally, add such a password line after each "title" line in the GRUB config-file, so that nobody can boot any OS installed on the laptop without a password!

Networking, Upgrading and Apt-secure

• Now that we have a small, hardened system, it should be reasonably safe to enable networking. Add this to /etc/network/interfaces:
  

  auto eth0
  iface eth0 inet dhcp
    pre-up /etc/rc.boot/fw_laptop
  

  Run /etc/init.d/networking restart. The firewall script will run every time the network is started.
• Now add this (tweak as you see fit) to /etc/apt/sources.list:
deb http://ftp.de.debian.org/debian unstable main
deb-src http://ftp.de.debian.org/debian unstable main
• Time for upgrading: apt-get update && apt-get dist-upgrade. All packages are GnuPG-signed and will be verified by Apt. The installer already ships the required key (for 2006), so everything should just work. Still, you should read about SecureApt.
• Install the rest of your system now, and restore your data from backups.
• Use sysv-rc-conf to disable all daemons you don't want to start per default: sysv-rc-conf foo off.
• Install and set up Samhain (or any other file integrity checker): apt-get install samhain. You want to be notified if your system files are being tampered with (e.g. replaced by a rootkit).
• Install and configure Tor for anonymous browsing. More details here.
• Install and configure more security-related programs, e.g. logcheck, snort, rkhunter, chkrootkit, tiger, etc.

SELinux Now install and set up SELinux. This section is based on notes from Erich Schubert (thanks!), and will soon appear in the SELinuxSetup wiki page, too.

• Install the base packages and an SELinux policy: apt-get install selinux-basics selinux-policy-refpolicy-targeted.
• Edit /boot/grub/menu.lst and add selinux=1 to your kernel command line to enable SELinux upon booting.
• In /etc/pam.d/login uncomment the "session required pam_selinux.so multiple" line. Do the same in /etc/pam.d/ssh if you have ssh installed.
• In /etc/default/rcS set FSCKFIX=yes.
• In /etc/init.d/bootmisc.sh search for "Update motd" and comment the two lines below that line. Then rm /var/run/motd.
• If you have exim installed, you must either install postfix or write an exim policy, as none currently exists. But even postfix needs some fixing (no pun intended ;-). Disable chroot-support (change all "chroot" fields to "n" in /etc/postfix/master.cf and execute echo 'SYNC_CHROOT="n" >> /etc/default/postfix').
• Use check-selinux-installation to check for common SELinux problems on Debian (such as the above mentioned).
• touch /.autorelabel. Reboot. touch /.autorelabel (again). Reboot (again).
• Done. You should now have a working SELinux system. If no critical audit errors appear and you feel comfortable with SELinux, enable enforcing mode via setenforce 1 or by adding enforcing=1 to the kernel command line in /boot/grub/menu.lst.

Behaviour

• Never leave your laptop unattended!
• Always lock your terminal (using vlock) when you move more than 30 cm away from the laptop!
• Don't run insecure and/or closed-source software (which you can never trust!). No NVIDIA/ATI drivers, no VMware, no Google Earth, no Flash Plugin (except for Gnash maybe), no Adobe Acrobat. You get the idea.
• Keep the number of installed packages small and try to configure each of them as secure as possible.
• Never enable networking or WLAN or Bluetooth if you don't absolutely have to.
• Trust no one. Don't let other people use you laptop, don't give out shell accounts.

Further ideas

• The /boot partition is stilll unencrypted, so an attacker can tamper with it. Boot from a CD-R, forbid booting from hard drive (BIOS). Sign/mark the CD-R physically, so you'll know when someone replaced your CD-R with his own, back-doored one.
• Install another Debian into a QEMU image. Use it as a sandbox for stuff you don't trust: qemu -snapshot -net none foo.img.
• At all costs, disable Firewire! If possible via hardware or BIOS, or at least don't load the drivers and/or fix them (page 19).
• Replace the proprietary, closed-source BIOS with LinuxBIOS, if possible.

That's it. You can take off that stupid tin-foil hat now.

upstart is a replacement for the init daemon, the process spawned by the kernel that is responsible for starting, supervising and stopping all other processes on the system. The existing daemon is based on the one found in UNIX System V, and is thus known as sysvinit. It separates jobs into different “run levels” and can either run a job when particular run levels are entered (e.g. /etc/init.d/rc 2) or continually during a particular run level (e.g. /sbin/getty). The /etc/init.d/rc script is also based on the System V one (and is in the sysv-rc package), it simply executes the stop then start scripts found in /etc/rcN.d (where N is the run level) in numerical order. Why change it? Running a fixed set of scripts, one after the other, in a particular order has served us reasonably well until now. However as Linux has got better and better at dealing with modern computing (arguably Linux’s removable device support is better than Windows’ now) this approach has begun to have problems. The old approach works as long as you can guarantee when in the boot sequence things are available, so you can place your init script after that point and know that it will work. Typical ordering requirements are:

• Hard drive devices must have been discovered, initialised and partitions detected before we try and mount from /etc/fstab.

• Network devices must have been discovered and initialised before we try and start networking.

This worked ten years ago, why doesn’t it work now? The simple answer is that our computer has become far more flexible:

• Drives can be plugged in and removed at any point, e.g. USB drives.

• Storage buses allow more than a fixed number of drives, so they must be scanned for; this operation frequently does not block.

• To reduce power consumption, the drive may not actually be spun up until the bus scan so will not appear for an even longer time.

• Network devices can be plugged in and removed at any point.

• Firmware may need to be loaded after the device has been detected, but before it is usable by the system.

• Mounting a partition in /etc/fstab may require tools in /usr which is a network filesystem that cannot be mounted until after networking has been brought up.

We’ve been able to hack the existing system to make much of this possible, however the result is chock-full of race conditions and bugs. It was time to design a new system that can cope with all of these things without any problems. What we needed was an init system that could dynamically order the start up sequence based on the configuration and hardware found as it went along. Design of upstart upstart is an event-based init daemon; events generated by the system cause jobs to be started and running jobs to be stopped. Events can include things such as:

• the system has started,

• the root filesystem is now writable,

• a block device has been added to the system,

• a filesystem has been mounted,

• at a certain time or repeated time period,

• another job has begun running or has finished,

• a file on the disk has been modified,

• there are files in a queue directory,

• a network device has been detected,

• the default route has been added or removed.

In fact, any process on the system may send events to the init daemon over its control socket (subject to security restrictions, of course) so there is no limit. Each job has a life-cycle which is shown in the graph below: The two states shown in red (“waiting” and “running”) are rest states, normally we expect the job to remain in these states until an event comes in, at which point we need to take actual to get the job into the next state. The other states are temporary states; these allow a job to run shell script to prepare for the job itself to be run (“starting”) and clean up afterwards (“stopping”). For services that should be respawned if they terminate before an event that stops them is received, they may run shell script before the process is started again (“respawning”). Jobs leave a state because the process associated with them terminates (or gets killed) and move to the next appropriate state, following the green arrow if the job is to be started or the red arrow if it is to be stopped. When a script returns a non-zero exit status, or is killed, the job will always be stoped. When the main process terminates and the job should not be respawned, the job will also always be stopped. As already covered, events generated by the init daemon or received from other processes cause jobs to be started or stopped; also manual requests to start or stop a job may be received. The communication between the init daemon and other processes is bi-directional, so the status of jobs may be queries and even changes of state to all jobs be received. How does it differ from launchd? launchd is the replacement init system used in MacOS X developed as an “Open Source” project by Apple. For much of its life so far, the licence has actually been entirely non-free and thus it has only become recently interesting with the licence change. Much of the goal of both systems appears initially to be the same; they both start jobs based on system events, however the launchd system severly limits the events to only the following:

• system startup,

• file modified or placed in queue directory,

• particular time (cron replacement),

• connection on a particular port (inetd replacement).

Therefore it does not actually allow us to directly solve the problems we currently have; we couldn’t mount filesystems once the “filesystem checked” event has been recived, we couldn’t check filesystems when the block device is added and we certainly couldn’t start daemons once the complete filesystem (as described by /etc/fstab) is available and writable. The launchd model expects the job to “sit and wait” if it is unable to start, rather than provide a mechanism for the job to only be started when it doesn’t need to wait. Jobs that need /usr to be mounted would need to spin in a loop waiting for /usr to be available before continuing (or use a file in a tmpfs to indicate it’s available, and use that modification as the event). This is not especially surprising given that Apple have a high degree of control over both their hardware and the actual underlying operating system; they don’t need to deal with the wide array of different configurations that we have in the Linux world. Had the licence been sufficiently free at the point we began development of our own system, we would probably have extended launchd rather than implement our own. At the point Apple changed the licence, our own system was already more suitable for our purposes. How does it differ from initng? Initng by Jimmy Wennlund is another replacement init daemon intended to replace the sysvinit system used by Linux. It is a dependency-based system, where upstart is an event-based system. The notion of a dependency-based system is interesting to talk about at this point. Jobs declare dependencies on other jobs that need to happen before the job itself can be started. Starting the job causes its dependencies to be started first, and their dependencies, and so on. When jobs are stopped, if running jobs have no dependencies, they themselves can be stopped. It’s a neat solution to the problem of ordering a fixed boot sequence and the problem of keeping the number of running processes to a minimum needed. However this means that you need to have goals in mind when you boot the system, you need to have decided that you want gdm to be started in order for it, and its dependencies, to be started. Initng uses run levels to ensure this happens, where a run level is a list of goal jobs that should be running in that run level. It’s also not clear how the dependencies interact with the different types of job, a dependency on Apache would need the daemon to be running where a dependency on “checkroot” would need the script to have finished running. Upstart handles this by using different events (“apache running” vs. “checkroot stopping”). Again while interesting, Initng does not solve the problems that we wanted to solve. It can reorder a fixed set of jobs, but cannot dynamically determine the set of jobs needed for that particular boot. A typical example would be that if the only dependency on the job that configures networking is the mount network filesystems job, then should that job fail or notbe a goal (e.g. because there are no network filesystems to be mounted) the result is that network devices themselves will not be configured. You could make everything a goal, and just use the dependencies to determine the order, however this is less efficient than just ordering the existing sysv-rc scripts (which can be done at install time). Another example is that often you simply don’t know whether something is a dependency or not without reading other configuration, for example the mount network filesystems may be a dependency of everything under /usr or may just be a dependency of anything allowing the user to login if it just mounts /home. The difference in model can be summed up as “initng starts with a list of goals and works out how to get there, upstart starts with nothing and finds out where it gets to.” How does it differ from Solaris SMF? SMF is another approach to replacing init developed by Sun for the Solaris operating system. Like initng it’s a dependency-based system, so see above for the differences between those systems and upstart. SMF’s main focus is serive management; making sure that once services are running, they stay running, and allowing the system administrator to query and modify the states of jobs on the system. Upstart provides the same set of functionality in this regard, services are respawned when they fail and system administrators can at any time query the state of running services and adjust the state to their liking. Will it replace cron, inetd, etc? The goal of upstart is to replace those daemons, so that there is only one place (/etc/event.d) where system administrators need to configure when and how jobs should be run. In fact, the goal is that upstart should also replace the “run event scripts” functionality of any daemon on the system. Daemons such as acpid, apmd and Network Manager would send events to init instead of running scripts themselves with their own perculiar configuration and semantics. A system administrator who only wanted a particular daemon to be run while the computer was on AC power would simply need to edit /etc/event.d/daemon and change “on startup” to “on ac power”. What about compatibility? There’s a lot of systems administrators out there who have learned how Linux works already and will not want to learn again immediately, there’s also a large number of books that cover the existing software and won’t cover upstart for at least a couple of years. For this reason, compatibility is very important. upstart will continue to run the existing scripts for the forseeable future so that packages will not need to be updated until the author wants. Compatibility command-line tools that behave like their existing equivalents will also be implemented, a system administrator would never need to know that crontab -e is actually changing upstart jobs. Does it use D-BUS?

“To D-BUS people, every problem seems like a D-BUS problem.” —Erik Troan

The UNIX philosophy is that something should do just one job, and do it very well. upstart’s one job is starting, supervising and stopping other jobs; D-BUS’s one job is passing messages between other jobs. D-BUS does provide a mechanism for services to be activated when the first message is sent to them, thereby starting other jobs. Some people have taken this idea and extended it to suggest that all a replacement init system need do is register jobs with D-BUS and turn booting into a simple matter of message parsing. This seems wrong to me, D-BUS would need to be extended to supervise these services, provide means for them to be restarted and stopped; as well as deal with being process #1 which means cleaning up after children whose parent’s have died, etc. It seems far simpler to arrange for D-BUS to send an event to init when it needs a service to be started, and focus on being a very good message passing system. The IPC mechanism used by upstart is not currently D-BUS because of various problems, however it’s always been expected that even if init itself doesn’t communicate with D-BUS directly, there would be a D-BUS proxy that would ensure messages about all init jobs and events would be given to D-BUS and D-BUS clients could send messages to init to query and change the state of jobs. What is the implementation plan? Because this is process #1 we are changing, we want to make sure that we get it right. Therefore instead of releasing a fully-featured daemon and configuration to the world, we’re developing it in the following stages:

1. Principal development; at the end of this stage the daemon has been implemented and can manage jobs as described.
2. Replacement of /sbin/init while running the existing sysv-rc scripts. This is the shake-down test of the daemon, can it perform the same job as the existing sysvinit daemon without any regressions?
3. /etc/rcS.d scripts replaced by upstart jobs. These consitute the majority of tasks for booting the system into at least single-user mode, and contain many of the current ordering problems and race conditions. If the daemon solves the problems here, it will be a success.
4. Other daemon’s scripts replaced by upstart jobs on a package-by-package basis; this will be an ongoing effort during which upstart will continue running the existing sysv-rc scripts as well as its own jobs. During this time the event system may be tweaked to ensure it truly solves the problems we need.
5. Replcement of cron, atd, anacron and inetd. This will happen alongside the above and result in a single place to configure system jobs.
6. Modification of other daemons and processes to send events to init instead of trying to run things themselves.

The current plan is that we will be at least part of the way into stage #3 by the time edgy is released, with that release shipping with upstart as the init daemon and the most critical rcS scripts being run by it to correct the major problems For edgy+1 we hope to have completed stage #5 and be at least part of the way into the implementation of stage #6. From the start of development of edgy+2, no new packages will be accepted unless they provide upstart jobs instead of init scripts and init scripts will be considered deprecated. What state is it in now? The init daemon has been written and is able to manage jobs as described above, receiving events on the control socket to start and stop them. This has now been uploaded to the Ubuntu universe component in the upstart package for testing before it becomes the init daemon. We welcome any experienced users who want to help test this; install the package and follow the instructions in /usr/share/doc/upstart/README.Debian to add a boot option that will use upstart instead of init. If your system boots and shut downs normally (other than a slightly more verbose boot without usplash running) then it is working correctly. Other types of events will be added as required during development and testing. Currently only a basic client tool (initctl) has been written, compatibility tools such as shutdown will be written over the next week or two before it replaces our sysvinit package.