Argh! Our beloved leaders have just started a consultation on making it mandatory for internet service providers to keep email and web logs for a year and deliver them to local councils and police on request. Large ISPs have already been doing this, in order to make friendly-friendly with gov.uk, (do their customers know they are being watched?) but requiring it of all ISPs might put some small user co-operative hosting services out of business because it will drive up costs (need more disk to store that data and staff time to distribute it on request). Not what I expected from a Labour and Co-operative Party government. Fortunately, the Lib Dems and Tories are speaking sense like this:-

“Ministers have proven time and time again that they are not to be trusted with sensitive data, but they seem intent on pressing ahead with this snoopers’ charter. ” (Source: BBC)

However, I’m pretty sure when the EU-level parts of this were being discussed, the Lib Dems and the Tories agreed with it. Something I’ll ask Neil Parish MEP when asking him about the progress of the promised reply to my three strikes by the backdoor questions. You can see why I’m sceptical about the “but it doesn’t mean what it appears to say” assurances, can’t you? They were worthless last time, and the time before that, and the time before that (yes, I’ve been doing this so long that I supported ST@ND). The consultation closes after this year’s Parliament and the Internet conference, which could also be an interesting place to ask questions about it. And it’s another consultation I should ask the Phone Co-op (aff) about. Please reply to the consultation and give a loud “NO” - if you have particularly good reasons, please let me know in a comment. I’ve no argument against policing, but a year’s logs? Local councils? There are too many holes in this to let it pass unchallenged. Thanks.

I just had this crazy idea about solving snapshot.debian.net's space issue which just might work if done right.

We all know that snapshot.debian.net has ran out of space in early May this year and we all lost a valuable service. Since there are probably many users, developers and maintainers which find this service useful, it might make sense to think that the users themselves could solve the problem.

How? Think about implementing a really distributed storage/file system (not necesarly a real file system) that can rely on cluster nodes that can enter or exit at any time and the nodes are contributed by users, very much alike the GoogleFS file system (or maybe clients in a torrent swarm).


First problems that I can already see:

• there must be some indexing service that should run 24x7 to manage the information about the blocks which are desired.
• some data should always be kept on a trusted machine - the gpg signatures, the Packages files indexing information and meta data
  
• there might be a security risk involved since data would be stored on untrusted machines, but a sha1/md5 check in colaboration with the gpg signature should be enough (which isn't always doable - see large packages like openoffice.org or game data packages); if there are reasons why this might not be secure, maybe we need to rethink a little about the dpkg-sig package and see if we can get all the packages in the archive to be individually signed when entering the archive, or something of that sort
• the meta-data of the FS cluster might be really big, but my gut feeling tells me that it won't be as big as the current snapshot.d.n storage
• when a file is requested, the file needs to be cached on a central server so it can be assembled and its checksum be verified before being delivered to the client requesting it
• people might donate really little space compared to their usage
• some nodes of the network are special and this could lead to the failure of the entire infrastructure in case the special nodes fail; some of these nodes might turn out to need really big muscles
  
• some data might be unavailable at times depending on the clients connected to the network at different points in time
• in an attempt to create more copies of a block in more nodes in the network, a DoS might be triggered if many clients request the same info from a (set of) node(s) containing the rare info - still torrent's way of workig seems to cope quite well with that model
• none of this is implemented and probably I won't do it myself, although it could be a really nice project, even it is doomed to fail from day 1
  

Other ideas:

• maybe it would make more sense for the FS to actually be an ever-growing torrentt which people can connect to via some special client which would allow pushing to the clients in order to store information
• the number of copies of a file (or chunk of a file) in the distributed storage should be higher for more recent packages and lower for older ones (still one copy might be necessary to be stored on safe nodes - aka controled and trusted by debian so the information doesn't get lost - back to our current storage problem)
• probably the entire thing could be built somehow by piggy-backing the current apt-transport-debtorrent implementation or debtorrent, or apt's cache - the idea is that although not all files might be available, some people might still have relatiely recent packages files in their apt cache
• such a system, if done right, might prove to be usable as a live backup system between different nodes in the cluser, so it could be used in other situations by individuals, without the need of a central server - think trackerless trorrents
  

What do other people think?

I’ve been playing with a blacklight here at Debconf, during the keysigning party. (Hey, I’m a geek; what did you expect.) Of course, I cannot resist sharing what I saw:

• US passports are very dull under the blacklight. From the older ones that don’t reflect anything, to the newest ones that feature a security thread in three colours and UV-sensitive fibers embedded in the pages and the inner covers, they are not exactly a party of lights and colours.
• However, they are not the dullest. That honour goes to Brazilian passports, which contain no UV markings whatsoever. Runners-up are British passports, with only some crown markings in the inner covers.
• Belgian passports blew me away, with a colour photograph which only appears under the blacklight. Luxembourgish passports are similar, but have no photo.
• Talking about photos, one passport Greek passports contain the person’s photo in UV-sensitive ink. However, I don’t remember what country it was (please add a comment).
• Greek and Spanish passports light up with patterns when you illuminate them. Colombian and Mexican passports do, too.
• Austrian passports have Republik sterreich written in UV-sensitive light in their cover. Spanish passports have the Spanish coat of arms and the word Espa a over and over.
• Swiss passports don’t need any UV markings, because they are already full of colours in plain light.

I looked at more passports, but those are the ones I can remember off the top of my head. A couple of notes before I publish this post:

• I would have liked to look at a Japanese passport.
• If you’d like to look at your own passport under a UV light, I’m at the top floor hacklab :)

One thing that charities often seem to like to do is give you discounts on things they sell or events they run. This is a nice way of saying thank you but if you’re trying to give them money it’s not always something you want to take advantage of. Sometimes it’s surprisingly difficult to convince them if this which always seemed counterproductive on their part - “You’re a charity. This is a fundraising event. I want to give you money - why are you making this hard?”. Of course, that’s less of a problem than the magazines most insist on sending you - pretty much all of the ones I get go straight to recycling, serving nobody, while you can always donate some other way. I can see the argument that they keep you in touch with what the organization is doing and so on but I’m happy to do that via other means (like the Internet) or, often, not at all. Honestly, I’m really not that interested in the details of the new RNLI lifeboats but I do think they’re a jolly good idea.

Unfortunately, Matthew is correct, and it seems that Ryan Farmer is the idiot that signed a few of us up to about 200 mailing lists this morning. Not only do I trust Matthew's analysis (and was watching him go through the various steps on IRC as it happened), but then there were two other bits.

Ryan refused to approve two of my comments I made on his latest blog entry (more than happy to screenshot this). He claimed he too had been spammed, and had to abandon his email address of a few years. Even if you ignore the length of the text blanked out in the title bar not even remotely matching the length of his personal email address, there were only 131 messages in the inbox, of which 127 were unread, and no others but spam visible. He claimed they were archived; I offered to publicly apologise if he'd do a quick screencast showing him logging into that account and showing some messages from the archive to prove the point. Unfortunately he didn't bother approving these comments. (Incidentally, if you had to 'abandon' an email address due to an avalance of newsletters, et al, which took an hour or two to fully unsubscribe from, would you still bother blacking out the address everywhere?)

As per his standard 'insult everyone with random images from the internet and YouTube videos, then wildly claim conspiracies against him' policy, he went on to claim Matthew was conspiring against him, but given the choice between Matthew conspiring and severely irritating a few of his friends in the process, and some scorned 16-year old continuing his track record of acting like an irrational, immature idiot, I know which one I'd pick.

It takes some skill to be banned from all the Ubuntu IRC channels and the Ubuntu forums both, but I guess this morning showed that was completely justified. Apologies to everyone waiting on the announcement of sponsorship for XDS, as well as hotels, but unfortunately some people just can't conceive of having better things to do than acting like chavs. Hopefully IzanbardPrince/TheAlmightyCthulu/etc goes back to impersonating Kevin Carmony, flaming the bejesus out of companies using BIOSes which trip Linux bugs, and other, equally productive, uses of his time.

I've had an outstandingly good time, as expected. Much kudos to the local team here in Argentina for organising the conference so well, and it's great to see that the efforts of the video team are making it possible for lots of people to attend the talks virtually as well. Good work, folks! My highlights so far:

• Getting all the right people together in one room for a really productive session discussing "tdebs", a new way of organising the translations in our packages. In less than an hour, we went from a mix of opinions and suggestions (all with problems) to a good consensus about what we're going to do and what work needs to be done. In Debian we work very effectively online normally, but this kind of design discussion could easily have taken a month or more via email. Sometimes face-to-face meetings just work better! (See the wiki for the session notes.)
• The 15th Birthday Party last night. I got to formally accept our "epic fail" award from Luciano Bello after his recent trip to Las Vegas to tell the Defcon and Blackhat folks about our recent OpenSSL problems. Then I was coerced into dancing for the delight of the crowd. Apparently some git even caught that on video. Oh, the shame...
• Beeeeeeeeef! I joined a group of people at the "Palacio del Bife" restaurant in the centre of town on Monday night, and we ate a lot of beef. I had a massive T-bone steak which was awesome - large and very very nicely cooked. I'll have to go again. *grin*

Unfortunately, the end of the week is quickly approaching. I'll have to head back to England all too soon.

This is part 1 of a series on articles about the Firewire security issues mentioned below. For many years now, attacks via Firewire / i.LINK / IEEE 1394 have been a known security issue. Basically, if you gain physical access to a PC or laptop which has Firewire ports (or PCMCIA/Cardbus/ExpressCard, more on that later) you can

• read arbitrary RAM contents from the victim's system,
• overwrite arbitrary RAM contents with whatever you want,
• and perform many, many severe attacks based on the two issues above. Examples include grabbing a full RAM dump via Firewire (takes only a few minutes), grabbing ssh-agent keys, grabbing screen contents, modifying screen contents, bypassing login/password screens, and many, many more...

All of this is done by exploiting a "feature" of the Firewire spec (OHCI-1394) (PDF), namely that it allows read/write access to physical memory (via DMA) for external Firewire devices. Worse, as this is DMA, the CPU/OS will not even know what's going on. Even worse, this works regardless of whether you have locked your screen with a password-protected screensaver, or xlock, or vlock, or whatever. As long as the system is running, you're vulnerable. In this article, I intend to give a fairly complete overview of the available papers published on this issue, tools for testing the attacks, as well as mitigation techniques for various OSes. If I'm missing some important papers or tools, please post a comment! Papers, Attacks, and Tools Over the years a number of presentations and papers have been released with information about these Firewire issues. Maximilian Dornseif et. al. The first publication that I know of was done by Maximilian Dornseif, Michael Becher, and Christian Klein. They gave a number of talks on various security conferences on this topic:

• Pacsec 2004: 0wned by an iPod (PDF)
• 21C3: Hacking with Fire / Feuriges Hacken - Spa mit Firewire (PDF)
• Cansecwest 2005: Firewire: all your memory are belong to us (PDF)

They also released a number of tools, Firewire libraries for Mac OS X and Linux, as well as small demo scripts which use those libs:

• pyfw-20041111.tar.gz: Mac OS X Firewire bindings for Python, various demos
• http://c0re.23.nu/c0de/pyfw/: Other versions of the above code
• pyfw_linux.tar.gz: Linux Firewire bindings for Python (can be used with above demo code on Linux)
• ipod-linux-pyfw.tar.bz2: Instructions (+ disk image) on how to turn your iPod into a Firewire attack tool

Adam Boileau In 2006 Adam Boileau (a.k.a. Metlstorm) gave a talk called Hit by a Bus: Physical Access Attacks with Firewire (PDF) at Ruxcon 2006. In 2008 he then released a set of tools:

• pythonraw1394-1.0.tar.gz: Python bindings for libraw1394 (Linux). Tools: businfo, romtool, 1394memimage
• winlockpwn: Python script which can circumvent a locked Windows XP screen (an arbitrary password will log you in)
• bioskbsnarf: Grabs/shows the BIOS keyboard buffer via Firewire (which often contains your BIOS password)

Peter Panholzer As of early 2008 Peter Panholzer from sec-consult.com published a two-page whitepaper which says they were able to run a winlockpwn-like attack on Windows Vista via Firewire. There's not much information in the PDF unfortunately, and no tools were released, as far as I know.

• Whitepaper: Physical Security Attacks on Windows Vista (PDF)
• Bugtraq Thread about the whitepaper

David R. Piegdon The most recent toolset and papers I know of are from David R. Piegdon (a.k.a. IosTrace), who gave a number of talks in 2007/2008 about the issue, and also released a toolset called SEAT1394.

• 2007: OpenChaos: hacking in physically addressable memory (no extra slides)
• Easterhegg 2008: FireWire Hacking: paper (PDF), slides (PDF)
• More papers here...
• http://0null.net/software/SEAT1394/: tools and libraries for pyhsical memory access via Firewire/DMA: 1394csrtool, liblinear, libphysical, debug-sshkey, dump-memory, remote-ps, show-stack, snarf-sshkey, test-all-pagedirs, dmashell, ...

I'll go into much more detail on how the tools are used and what they can do in another follow-up article. Mitigation There are ways to eliminate or at least mitigate these attack vectors. The simplest and most secure way is to not have any Firewire ports installed (don't put Firewire PCI/PCIe cards in your PC, don't use Firewire PCMCIA/Cardbus/ExpressCard cards). Now, if you have a laptop with built-in Firewire ports, you have a problem, of course. In that case you could still physically destroy the port (by opening the laptop and cutting/desoldering stuff, or by putting glue/epoxy in the port in order to prevent any Firewire cables being attached). These are slightly drastic (but effective!) measures. Note: Even if you don't have any Firewire ports, you're not automatically safe and secure. If your laptop has a PCMCIA/Cardbus/ExpressCard slot, an attacker can simply insert a PCMCIA Firewire card (for instance) in that slot. Chances are, that your OS will automatically load the driver for that card and also the Firewire drivers you'll need if you want to use the card for attaching Firewire devices. Game over. Your "secure" laptop is now vulnerable... If you cannot (or don't want to) remove/destroy/disable your Firewire ports, the next best thing is to ensure that nobody except yourself ever gets physical access to your PC/laptop. This is hard to do for a PC, and almost impossible for a laptop, mind you. Finally, there are some software measures you can use to prevent at least physical DMA access for Firewire devices: Mitigation: Linux Pretty much every Linux system with the "old" Firewire drivers loaded (kernel module ohci1394 et. al.) is vulnerable to these issues. Newer kernels now also ship with a new Firewire stack called "juju" (kernel module firewire_ohci et. al.) which may or may not have the same issues (not fully tested by me so far, will report back later). Per default, all recent kernels, e.g. 2.6.26, are vulnerable, but see below. Under Linux, simply using a kernel which doesn't have any Firewire support (neither built-in, nor as a module) is the most secure option. If you must have Firewire support you can load the ohci1394 module with the phys_dma=0 parameter to at least disable physical DMA support:

  $ modprobe ohci1394 phys_dma=0

I have personally tested this on some boxes and I can confirm that it renders the currently published tools useless. As for the new "juju" Firewire stack, I'm not so sure. A few quick tests showed that the currently available tools don't work with the new stack, but you shouldn't feel too secure! AFAIK the new stack does support (or will support soon) physical DMA for Firewire, so it's probably just a matter of adapting the tools a bit (I'll do some testing/research on this later, as time permits). Mitigation: Mac OS On Mac OS you might also be able to completely remove Firewire support from the kernel (but I don't know if/how that can be done, not sure if you can easily recompile Mac OS kernels, and/or if you even have buildable source code and toolchains for that). However, you can at least remove the Firewire support in the default Mac OS installation by unloading AppleFWOHCI.kext:

  $ sudo kextunload /System/Library/Extensions/IOFireWireFamily.kext/Contents/PlugIns/AppleFWOHCI.kext

Thanks to a Daniel Reutter for letting me abuse his MacBook via Firewire and for finding the above kextunload command line. We have successfully tested that after unloading AppleFWOHCI.kext the current tools won't work anymore. The tests were done on a Mac OS X Tiger (I think) with all recent security updates applied. Please leave a comment if you can test other versions of Mac OS X... Mitigation: Windows As for Windows, well, I guess you're screwed. While Windows XP does implement sort of "protection" in that it only allows physical DMA access via Firewire to devices which "deserve it", e.g. iPods (or any other Firewire mass storage device, I guess) this can be easily defeated by having your attack PC/laptop pretend to be an iPod (see the romtool Python script by Adam Boileau). The only remaining option I know of (short of removing/destroying Firewire ports or preventing physical access alltogether) is to disable the Firewire ports/drivers in the device manager (untested by me so far). If you do that, remember to also disable all PCMCIA/Cardbus/ExpressCard controllers, of course (see above). So far I've tested Windows XP SP2/SP3 successfully with Adam Boileau's tools. I haven't yet been able to test Windows 95/98/Vista, if you can verify one of them, please leave a comment. Mitigation: OpenBSD/FreeBSD/NetBSD/OpenSolaris/... On OpenBSD you're likely not vulnerable as OpenBSD doesn't have any Firewire drivers at all, as far as I know ;-) As for FreeBSD, NetBSD, OpenSolaris, and other OSes I don't have any information. I might be able to test one or two of them in the nearer future, but please leave a comment if you have some information about whether they are vulnerable and/or how you can secure your system... Conclusion That's it for now. I hope you now have a good overview of these issues and how to protect. I can only urge you to take this problem seriously! Three or four minutes of leaving your laptop unattended are fully sufficient for an attacker to get a full forensic image of all your RAM contents for later analysis. This is at least as critical as the Cold Boot attacks, if not worse. I will follow-up with more articles about some more interesting details on these Firewire issues, how to use the above tools, and I'll report on some of the stuff I was able to find in RAM dumps gathered via Firewire...

Tonight was the Debian 15th Anniversary Party and formal dinner over at the alternate hotel. During dinner, Bdale asked helix which Wilson Sister she thought she was most like. read more

Hi folks! We’re almost done for the official Summer of Code program and I thought that I couldn’t let it end without another update, so here we are (you may thank Daniel Burrows for additional poking). The Gtk+ interface for Aptitude is making great progress. The product is not final yet but already implements many of the planned ideas, with others to come. Here are the screenies: So, let’s see the tasks presented in my previous update:

• A real user interface <- much progress here
• Being reliable <- check! we don’t crash all the time anymore
• Packages dependencies, pre-dependencies, etc. <- check!
• Hyperlinks between packages <- check!
• Advanced package search <- check!
• Tags support (tag clouds ?) <- well, no clouds yet, but we have tags
• Linking with interesting data sources like popcon <- not done yet
• A lot of interesting things <- well..

In some more details: we are now much closer to the final interface. Some things are not done yet, for example, notification bars la Iceweasel (or is it Firefox ?) are in the works for unobtrusive notifications about important things and a little guidance. We are much more reliable now. We eliminated lots of memory management problems that resulted from, mmh, imperfect coding discipline. We also lock the interface when important backend stuff reload to prevent the user from shooting himself in the foot when triggering an install when the APT cache is reloading for example.. The backend refactoring took a sizable part of this second term but it was worth it. The code is now much cleaner and uses no more (at least much fewer) ugly unscalable hacks. One very important feature of Aptitude is the ability to easily display all kinds of dependencies and navigate through them by hyperlinking. It’s now working in the Gtk+ interface as well. Feel free to click on whatever looks like a package or a package version. We now support the powerful Aptitude package searching syntax. Daniel Burrows is talking with Enrico Zini to bring the power of apt-xapian-index to Aptitude: autocompletion! lightning fast full-text searches! tag clouds! ponies! There is still a lot to be done. I’m not going away after the GSoC program. I’m here to stay, for Aptitude and Debian. Daniel Burrows has been very helpful and supportive. The Debian community is as awesome as I knew it before participating in the program. Daniel Burrows is planning to merge the Gtk+ interface into the main branch in September and packages may appear into Experimental. With the very interesting evolutions of the upcoming Adept-3, Lenny+1 will show very interesting changes in the area of packages managers. Now for you. I need you to test my interface. All necessary instructions are on the development trac : http://dev.graffit.net/aptitude/trac.

Somehow (thankfully) I've managed to avoid much to do with backups in my career as a sysadmin. It's always been someone else's responsibility, that's been fine by me. For some reason, I've been more paranoid lately, and with all of the crazy shit I've been doing to daedalus, I wanted to have a backup, just in case. Maybe it's old age. So a while ago, I went and had a stab at setting up Amanda, since pretty much whenever I've been near a bunch of sysadmins and someone asks for a recommendation on what to use, "Amanda" is the answer. I jumped through all of the hoops to have caesar be the backup server, and daedalus be a client. I set up a virtual tape library on caesar. I think I then lost interest for a while, until I was going to upgrade daedalus to Etch, and I wanted to have a successful backup first. I had the holding disk and the virtual tape library on the same filesystem, and it was nice and big, yet I kept running into this error about insufficient space. "dump larger than available tape space" was the complaint. I tried making the filesystem larger. I tried adding more virtual tapes. Nothing would placate it. After another round of Googling, I discovered that the problem was because Amanda would only only span a maximum of four tapes, and the filesystem I was trying to backup was way bigger than that. So I told it to use up to 10 tapes in a run (runtapes 10) and then lo and behold, I got a successful backup out of the sucker. So that was mostly all good, but occasionally a backup would fail, or fail once an succeed on a retry, because tar exited non-zero, with "file changed as we read it". I did some more Googling tonight, and discovered this Amanda/GNU tar compatibility matrix. It turns out that the version of tar and the version of Amanda shipped in Debian Etch aren't compatible with each other. Suck! Oh wait, they're maintained by the same person! Argh! So aside from the occasional backup failing due to a file being written to at the time of the backup, it's working fairly well. My DSL link isn't the fastest, so a full backup of daedalus can take over 48 hours to complete, but I'm not paying for inbound bandwidth at home, so it's not a big deal. I initially thought that to do a restore, I'd have to run amrecover on daedalus, and then I'd have to stream the contents of multiple tapes back to it at the appalling uplink speed of my DSL connection, but fortunately amrecover has a sethost command, so I can restore just the files I need on another machine local to caesar at LAN speeds, and just transfer the files I restore to daedalus. So that's all pretty neat. I quite like the FTP-client-like interface of amrecover. It's cool how you can use setdate and just go back in time. I had the opportunity to do a test restore recently when one of my users nuked his Maildir directory by accident. Unfortunately I was unable to recover the needed files in that case, and I'm not entirely sure what the problem was, so there's some more testing to be done before I'll be fully confident that I can rely on it. There's a lot of configuration options available as well, and I think I got the config I'm currently using from a template or something, so there's probably a fair bit of tweaking I can do. Oh, and I'm constantly reminded of this quote from a previous life, where technical details bubbled too far up non-technical management:

"Who is Amanda, and what is her role in the backups?"

I've thought on and off that it would be nice for the graphical version of aptitude to have decent hyphenation. Word-wrapping descriptions looks OK, but when the text area is thinner than the entire screen, it can look a little ragged on the right-hand side. For instance, take this rendering of the description of the toy program bb: Not too bad, but if I render it in LaTeX, here's how it comes out: Of course, for very thin text columns (and the above is arguably pushing it), hyphenation and text justification aren't what you want. But it would be nice to be able to at least see what it looked like. Figuring that GTK+ might have some support for this, I delved into Google. I found this:

Line breaking Line breaking adds additional layers of complexity. For one, all potential line breaks must be identified, including discretionary hyphens for Latin scripts, and word boundaries in (???). Secondly, inserting hyphens may require reshaping. Third is the line breaking algorithm itself, which may be nontrivial. -- Pango 0.1 proposal, Raph Levien, 1999

and this:

Future plans for Pango include support for high quality printing, better hyphenation support, full justification, and the ability to handle vertical text such as Chinese and Japanese. -- Pango: Text handling for the World, LWN (Forrest Cook) 2001

and also this:

I've been working on code to do hyphenation, hopefully to add to Pango. My new code is faster than libhnj and groff and uses less memory. -- Hyphenation Design (Was Re: Possible Pango 1.4 ideas), Damon Chaplin, post to org.gnome.gtk-i18n-list.

But no sign that any work has been done on hyphenation recently. The one intriguing thing I noticed, although it's not GTK+ at all, was the libhyphen0 library, which might be useful. Unfortunately, it's a bit more complicated than just flipping a switch in GTK+: the library is documentation-free, so to figure out how to use it I'll need to read through its source code and deduce the expected interface from that. Meh. Probably something to stick way at the bottom of the priority list.

In a discussion which covered some of the differences between Linux and Windows, a Windows using friend asked me if I felt compassion for Windows users. I feel some compassion for people who have bad working environments. While using an operating system that has poor support for the business tasks does decrease the quality of the working environment, there are bigger issues. For example a while ago I was doing some sys-admin work for a financial organisation. I had to use Windows for running the SSH client to connect to Linux servers, this was annoying and decreased my productivity due to the inability to script connections etc. My productivity was also decreased because of my unfamiliarity with the Windows environment, it seems reasonable to assume that when you hire a Linux sys-admin they will have some experience of Linux on the desktop and be quite productive with a Linux desktop system - while the same can not be said for a Windows desktop. But what really made the working environment awful was the paperwork and the procedures. If a server doesn’t work properly and someone says “please fix it now” and I only have a VT100 terminal then I’ll be reasonably happy with that work environment (really - I wouldn’t mind a contract where the only thing on my desk was a VT100 connected to a Linux server). But when a server process hangs in the same way several times a week, when the cause of the problem is known and the fix (restarting the process) is known it really pains me to have to wait for a management discussion about the scope of the problem before restarting it. But I don’t have a great deal of sympathy for people who end up in bad working environments such as the one I was briefly in. Anyone who is capable of getting such a job is capable of getting a job with a better working environment while still earning significantly more than the median income. The people I feel sorry for are the ones who work on the minimum wage. I don’t think that the difference between Linux and Windows on the desktop would matter much if you were getting the minimum wage, and people who are on the minimum wage don’t have a lot of choice in regard to employment (I think that all options for them suck). I don’t have much sympathy for adults who use Windows at home. I have to admit that there are some benefits to running Windows at home, mainly that the hardware vendors support it better (few companies sell PCs with Linux pre-loaded) and there are some commercial games which are in some ways better than the free games (of course there are more than enough free Linux games to waste all your time - and some games are best suited to a console). Linux has significantly lower hardware requirements than Windows (my main machine which I am using to write this blog post is more than three years old and has less power than any other machine on sale today apart from some ultra-mobile PCs), so any long-term Windows user can install Linux on one of their machines which lacks the resources to run the latest version of Windows. The only Windows users for whom I have much sympathy are children. When I was young every PC came with a BASIC interpreter and everyone shared source code. Books were published which taught children how to program in BASIC which included fairly complete example programs. For the cases where proprietary software was needed the prices used to be quite low (admittedly the programs were much less complex - so pricing is probably in line with the effort or writing the code). Now it seems that computers are often being provided to children as closed systems that they can’t manipulate, the web browser has replaced the TV. I believe that Linux is the ideal OS for a child to use. There is a wide range of free educational programs (including kturtle - the traditional Logo turtle) and there are also a range of free powerful programs which can be used by any child. Few parents would buy Photoshop or Adobe Illustrator for a child to play with, but anyone can give a child a $100 PC with GIMP and Inkscape installed. They might as well give 3yo children access to the GIMP - it will be less messy than fingerpainting! I expect that some parents would not consider Linux for their children because they don’t know how to use it. Fortunately Linux is easy enough to use that a child can install it without effort. Some time ago the 11yo daughter of a friend who was visiting asked if she could play some computer games. I gave her a Fedora CD and one of the PCs from my test lab and told her that she had to install the OS first. Within a small amount of time she had Fedora installed and was playing games. While the games she played were not particularly educational, the fact that she could install the OS on a computer was a useful lesson. It seems to me that children who are raised as Windows users are less likely to learn how computers work or be able to control them properly. I expect that on average a child who is raised in such a manner will have fewer career options in today’s environment than one who properly understands and controls computers.

Share This

One of the things I've wanted to do since I discovered that Caltrain (and the VTA light rail) are well-equipped to take bikes, was go for an outing further afield on our bikes using one of these methods of public transport. So we finally got around to doing that yesterday, when we threw our bikes on the train, and BART, and went for a ride around Golden Gate Park. The grand plan was to bike to the Caltrain station, take Caltrain to Milbrae, BART to downtown, then bike from there to the park, and then catch an afternoon showing of The Dark Knight in IMAX at the Metreon, then bike back to the BART station, and reverse the whole thing. We had a minor hiccup in that Sarah had just gotten her bike back from a friend she'd lent it to, and as we were about to head to the Caltrain station, discovered that it a broken spoke. She managed to extract the spoke and we got to the station with a couple of minutes to spare. It turned out that Mike's Bikes were fairly close to the BART station, so we stopped in there on way to the park, and they were able to fix the spoke on the spot in 20 minutes for the princely sum of $21. Unfortunately the weather was pretty typical summer San Francisco weather, and it was quite cold and foggy. It didn't get any better as we got closer to the park (and the coast), so the ride around the park itself wasn't terribly exciting. The hill we had to get over (Hayes Street) was a bit of a slog. On the way back we saw the filming of a Japanese Nissan commercial (complete with right-hand drive car). I'd done some research into bike parking beforehand, and found that all of the parking garages are required to provide bicycle parking, and there's a pretty comprehensive list. So we parked our bikes in the Moscone Center garage, which was about a block from the Metreon, and went and caught the movie. The Dark Knight was really good. Very... dark. I really liked Ledger's portrayal of the Joker, much better than the original. I wonder if they'll just keep re-imagining the Batman movies over and over? There was pretty good continuity from Batman Begins. I thought the voice of Batman was a bit ridiculous though, at least initially. You kind of got used to it after a while. Anyway, we got back to the parking garage, and some lowlife had cut through the cable lock that we'd used to lock our bikes to each other and the rack, and stolen Sarah's bike! Annoyed does not begin to describe it. We trundled off the seven or eight blocks to the Hall of Justice to file a report. The SFPD weren't the least bit interested, really. The somewhat astounding thing was the bike racks were right behind the cashier's office, and there was video surveillance, and someone still managed to just walk right in, cut the cable, and walk out with the bike. We checked with the duty manager, and he reviewed the video footage and said they have footage of him walking in and then walking out with the bike. So hopefully the police will get hold that. We have to see if we can dredge up the purchase documentation for the bike and see if the serial number is recorded. I have no idea if we'll ever see the bike again. Our renter's insurance may cover it, but I suspect the deductible won't make it worth our while to make a claim. I have to say (and it's not like it's a recent discovery or anything) that the Bay Area's public transportation is a joke. It cost us $32 to go from Mountain View to Downtown San Francisco, via Caltrain and then BART. Our Prius takes about 11 gallons at worst, and with gas prices being at say $4.30 a gallon, that's about $47 a tank. We get about 400 miles out of a tank usually, and it's vaguely 40 miles from home to the guts of Golden Gate Park. So it's cheaper, and faster to drive to San Francisco than it is to use a bicycle and public transport. Particularly when you factor in the risk of theft of your bicycle. Our next bike lock will be one of those fancy Kevlar ones.

It's more or less four months since I proposed to resurrect our newsletter. We already released eight issues of the Debian Project News and work for the ninth issue has already started. So I guess it's time for a small "state of the DPN" speech, but since I'm not attending DebConf, you will have to read this mail instead ;) After having a rough start (and in fact missing some self-set deadlines and completely underestimating how much work is involved in such a kind of newsletter) we finally developed a - more or less - working flow of work (Which is by the way documented here). Speaking of the current state sadly means to confess, that our hopes to draw a lot of help from the community by using a system for drafting the news with a low entry barrier were not fulfilled. We actually had a good start, with good participation, but due to (I assume) the aforementioned initial difficulties participation in the creation of the DPN dropped considerably. Currently the workload of creating our bi-weekly newsletter is shared by only two people (that being Meike Reichle and myself), which is barely enough :( While we at least get a hint from time to time, what we should mention in the next issue, it rarely happens, that someone contributes by drafting a text -- which is the real work. (At this point a BIG "Thank You" to those who did! (See list bellow.) It's much appreciated!) We suffer especially, since although we are a two people team, we have in fact no redundancy, since real live issues affecting one of us will most likely affect the other one, too. Therefore we mostly concentrated our work on creating the next issues and getting them out in time, and didn't have time to answer all mails considering suggestions for changes and improvements (yet?). We are sorry, but at least we tried to read them briefly and keep them in mind when drafting the next issue. As a result of this we re-added the list of DSAs, WNPP and new and noteworthy packages due to popular demand. There are still a lot of unanswered mails not dealing with content, but with workflow issues / proposals (including changing from wiki.debian.org to a special ikiwiki instance). We are sorry, that we couldn't yet act on them and take appropriate measures, but be assured, they are not forgotten. Other issues the DPN currently have are "unwritten guidelines" regarding editorial choices of DSAs to be published and which packages to list in the "new and noteworthy package" section. Both is more or less done by our gut feeling. Speaking of problems the DPN are facing, we also need to mention translations of the DPN. The current workflow makes it difficult for translators of the DPN, since we often fail to get the final draft of the DPN ready in time to give translators a "head start" so the translated DPNs can be released together with (or at least with a as small as possible delay to) the English DPN. So here is a big call for help! We really need your help writing the DPN. (Monitoring lists and newstickers we don't monitor ourselves would be nice, too, but only add more work to us if you only give us pointers.) We will both be very busy with our real live the upcoming month, and are not sure how much time we can dedicate to the DPN. So please help us! The current draft for the next issue of the DPN is always available here . There should already be a todo list with pointers to interesting topics, which need to be written out. Some guidelines about style and content are available here. Last but not least, we would like to thank the following people who have contributed to the DPN so far:

• Adrian von Bidder
• Ana Guerrero
• Andre Felipe Machado
• Bjoern Boschman
• Graham Cobb
• Jeff Richards
• J rg Jaspert
• Jon Evans
• Julian Andres Klode
• Justin Rye
• Luca Bruno
• Martin F. Krafft
• Paul van der Vlis
• Paul Wise
• Raphael Hertzog
• Russell Coker
• Sebastian
• Stefano Zacchiroli
• Thomas Lange
• Wouter Verhelst

(Unfortunately we can't list those people, who contributed by translating the DPN, nor do we have a complete list of the native English speakers, who helped by proofreading. But we thank them nonetheless!)

One of our most popular products at the dayjob has been our Programmable LPC Dongle. It has seen widespread use as an embedded hardware development and debugging tool and is particularly popular among Coreboot developers as a ROM emulator, because of its low price and because we publish the FPGA code under the LGPL. Unfortunately, our current LPC Dongle product is nearing end of life, because some components are no longer available. We're currently designing a brand new Programmable LPC Dongle and, noticing the plethora of improvement ideas we already received from the Coreboot community, we decided to widen the scope and invite a larger group of hardware developers to tell us what features they want to see in our next-generation Programmable LPC Dongle. Anyone interested in participating in this brainstorm is welcome to send me their ideas to first-middle.lastname@artecgroup.com by September 1st 2008. While we cannot guarantee that every idea submitted will be used, we will definitely be reading all the feedback we receive.

Once again, I find myself turning to this wonderful series of tubes for help on a weird problem.

I have Firefox (Iceweasel) on all the computers I regularly use. One of these computers has had a persistent problem.

After using it for awhile, it takes a really long time to look up hostnames in DNS. And after upgrading to Firefox 3, it got much worse. Not only did name resolution get slow, but sometimes page loads would get exceptionally slow as well. I could have 5 tabs open, and all of a sudden at the magic moment, nothing would load on any tab. It was as if I was being hit by 75% packet loss. And new pages wouldn't load, either.

tcpdump showed Firefox not even sending out packets at these times. After a few minutes, it might be back to normal. But I could always quit and restart and it would be fine.

Now, here's the weird thing: I've eliminated every possible difference I can think of between this one machine and the others I use Firefox on. My plugins and extensions are the same set with the same versions. My configuration is the same. When this problem is happening, other network-related programs (even other web browsers) on the same machine are working fine. Nobody else here seems to be having this problem.

Any ideas?

When working on mailservers, I’ve noticed that Yahoo’s mailservers seem to “punish” others by sending code 421 (service not available) for a few minutes for a first report of spam that originated from there, longer for a second report and so on. Yahoo’s help pages suggest they do this if you don’t “comply with our guidelines (described below)” (which aren’t actually described below). That system seems to completely screw everyone on a server if a user forwards their own email to Yahoo and then flags some as spam, or if a website user who registered with a Yahoo mail address then closes their Yahoo account without updating their registration details. In the worst cases, a server’s mail queue can become clogged with stuff that it can’t forward to Yahoo. I’ve suggested that server owners ban forwarding to Yahoo, but not all have done that yet. Yahoo’s server-punishing tactics are particularly unfair because of the amount of spam we receive from Yahoo - when I tried rejecting that, the server tested seemed to get more 421 punishment for that. I now usually direct it to a blackhole, which feels a bit dangerous. Now I’ve just seen this from Indymedia which makes it sound like Yahoo’s getting even worse recently:-

“Yahoo doesn’t make it so easy for us. They do (unintendedly) transport a remarkable amount of spam, often sent by robots which automatically (and wide scale) crack Yahoos’ new account signup CAPTCHAS (those images with the cats + dogs + digits + letters in them) just to relay their spam through Yahoo. So it’s not easy to determine who sends legitimate email through Yahoo and who does not.”

I wrote about some alternative service providers back in 2006, including ippimail, which Yahoo users might like to change to. I’d be interested in comments about any new arrivals in this field. BT internet customers are probably using Yahoo-hosted email too. I recommend changing to The Phone Co-op, but my company is an agent for them, so I would say that, wouldn’t I?

Imagine you have a device, such as a linux phone, that allows login via ssh, e.g. when on a wireless network. You don t want to set a password with the (limited) phone UI. On the other hand, you don t want to allow passwordless root logins into your phone. But you do want the ability to login via ssh, after all that s why you have bought a linux smartphone. This led me to the idea of a pam module and corresponding UI piece that asks the currently logged in user: Hey, someone tries to login. Is that ok or not? This might also be useful for guest accounts on regular laptops. For more on that, see my last blog post.So I hacked it together (actually twice, due to some unfortunate use of rm at some point), invested most of the time in learning more about the python garbage collector vs. callbacks, explicitly marked global variables and proper automake stuff. In the end I got, well, just what I wanted. A simple pam module, dubbed pam-dbus that sends a request via the dbus system bus and an autostart program (written in python for now, but I might re-implement it in C) that uses notification-daemon to get confirmation from the user.You are welcome to try the sources and binary debian packages or have a look at the darcs repository for pam-dbus (with debian/ directory, repository browser). This will end up in Debian later, I guess.Update: Erik Johansson pointed out that if you want to use this with ssh, you need to set UsePAM yes in /etc/ssh/ssd_config.

Usually, files in /etc/pam.d/ are simple, linear descriptions of how a user should be authenticated, e.g. Try to authenticate him against ldap, and then against the local data base . But sometimes, you want something more advanced, for example If the user is called guest, please authenticate him with pam_dbus, otherwise use regular pam_unix. This is possible, and here I ll note down how to do that.There are actually two problems to solve: How to detect the username, and then how to do the flow control.For the first problem, I recently discovered the pam_succeed_if module, that allows for relatively advanced logic for checking uids, usernames, hostnames and group membership. For our case, the line would read

auth ? pam_succeed_if.so quiet user = guest

Now what next? If we just wanted to allow unrestricted access to guest, we could put sufficient for the questionmark. But we need something like if..then..else. Unfortunately (and I hope this will be fixed eventually), the only flow control available is skip the next n lines . So we can skip to pam_unix when this module fails (i.e. the user was someone else but guest), and if we did not skip, we can run the guest-specific module and then skip over pam_unix. So here is the complete snippet:

auth [default=2 success=ignore] pam_succeed_if.so quiet user = guest
auth [success=ok new_authtok_reqd=done ignore=ignore default=die] pam_dbus.so
auth [default=1] pam_permit.so
auth required pam_unix.so

You can read more about this advanced configuration in the PAM Administration guide. And here is the corresponding configuration for gdm, where guest can always login:

auth [default=2 success=ignore] pam_succeed_if.so quiet user = guest
auth required pam_permit.so
auth [default=1] pam_permit.so
auth required pam_unix.so

So I have a guest account with a locked password and I can allow ssh logins with a mouse click and use it directly with gdm. I probably should put the gdm configuration also in xscreensaver to not lock me out.

Congratulations to Kartik who finally became a Debian Developer There is definitely a lot of interest in Debian in India—even more if you count Ubuntu. Unfortunately interest is not translating into participation. Why are we seeing so little involvement in the project from Indians? What can we do to convert "users" to "builders"? If you have any thoughts on the matter I would like to hear about them.