I’m currently in Xen hell. My Thinkpad (which I won’t replace any time soon) has a Pentium-M CPU without PAE support. I think that Debian might re-introduce Xen support for CPUs without PAE in Lenny, but at the moment I have the choice of running without Xen or running an ancient kernel on my laptop. Due to this I’ve removed Xen from my laptop (I’m doing most of my development which needs Xen on servers anyway). Now I’ve just replaced my main home server. It was a Pentium-D 2.8GHz machine with 1.5G of RAM and a couple of 300G SATA disks in a RAID-1. Now it’s a Pentium E2160 1.8Ghz machine with 3G of RAM with the same disks. Incidentally Intel suck badly, they are producing CPUs with names that have no meaning, and most of their chipsets don’t support more than 4G of physical address space [1]. I wanted 4G of RAM but the machine I was offered only supported addressing 4G and 700M of that was used for PCI devices. For computation tasks it’s about the same speed as the old Pentium-D, but it has faster RAM access, more RAM, uses less power, and makes less noise. If I was going to a shop to buy something I probably would have chosen something different to get support for more than 4G of RAM, but as I got the replacement machine for free as a favor I’m not complaining! I expected that I could just install the new server and have things just work. There were some minor issues such as configuring X for the different video hardware (and installing the 915resolution package (which is only needed in Etch) to get the desired 1650×1400 resolution. But for the core server tasks I expected that I could just move the hard drives across and have it work. After the initial install the system crashed whenever I did any serious hard drive access from Dom0, the Dom0 kernel Oopsed and network access was cut off from the DomU’s (I’m not sure whether the DomU’s died but without any way of accessing them it doesn’t really matter much). As a test I installed the version of the Xen hypervisor from Unstable and it worked. But the Xen hypervisor from Unstable required the Xen tools from Unstable which also required the latest libc6, and therefore the entire Dom0 had to be upgraded. Then in an unfortunate accident unrelated to Xen (cryptsetup in Debian/Unstable warns you if you try to use a non-LUKS option on a device which has been used for LUKS and would have saved me) I lost the root filesystem before I finished the upgrade. So I did a fresh install of Debian/Unstable, this time it didn’t crash on heavy disk IO, instead it would lock up randomly when under no load. I’ve now booted a non-Xen kernel and it’s working well. But this situation is not acceptable long-term, a large part of the purpose of the machine is to run virtualisation so that I can test various programs under multiple distributions. I think that I will have to try some other virtualisation technologies. The idea of running KVM on real servers (ones that serve data to the Internet) doesn’t thrill me, Tavis Ormandy’s paper about potential ways of exploiting virtual machine technologies [2] is a compelling argument for para-virtualisation. Fortunately however my old Pentium-3 machines running Xen seem quite reliable (replacing both software and hardware is a lot of pain that I don’t want). In the near future I will rename the Xen category on my blog to Virtualisation. For older machines Xen is still working reasonably well, but for all new machines I expect that I will have to use something else - and I’ll be blogging about the new machines not the old. I expect that an increasing number of people will be moving away from Xen in the near future. It doesn’t seem to have the potential to give systems that are reliable when running on common hardware. Ulrich Drepper doesn’t have a high opinion of Xen [3], the more I learn about it the more I agree with Ulrich.

• [1] http://en.wikipedia.org/wiki/List_of_Intel_chipsets


• [2] http://taviso.decsystem.org/virtsec.pdf


• [3] http://udrepper.livejournal.com/tag/virtualization

Share This

Debian wants to release in september. This target is already becoming difficult to reach, though the Release Team would like to try to do an extra effort to reach it. History has shown that as long as testing migration is not frozen, many maintainers don't care much. Even during the freeze 'small' bug fixes are uploaded that sometimes break a lot and can delay the release quite a bit. Currently build-essential packages are frozen, though 13 of these have new uploads in unstable... We do want to finish 2 major transitions: python 2.4 -> 2.5 and perl 5.8 -> 5.10 before also freezing the non essential toolchain. The first one is reaching an end, though some build failures on arm and a flaky alpha buildd are not helpful in that regard. Note that during a freeze fixes for release critical bugs, release goal bugs, documentation issues as well as translation bugs should still be fine if they have a low impact. Please do send unblock requests for those to the Release Team. Considering all the above I do hope that maintainers start to realise that requesting freeze exceptions (exceptions to the above guidelines) should not be done lightly and start preparing for a release.

Commands that should not be used on a LUKS partition:

1. pvcreate

[Warning, long post ahead. If you aren’t interested in Debian or it’s internals or my work - skip it. :) ] So as you might have read here, I got the delegation of the debadmin AKA FTPMaster group lately. I’ve got some pressure to not accept this delegation, but the response to my blog post about it had been extremely positive, everyone said I should not deny it. Knowing to have such a support within Debian is something I really appreciate, making it worth to spent time on my various jobs. Now, lets take this and write a little about what happened since I gained that extra group:

• Aj resigned from anything that requires additional group privileges. (As a DD run id ajt on a debian.org machine if you want to verify this).

Work I did since then:

• One of my first action was to finally finish the release transitions support, something which was waiting for it’s final merge for a long time. The release team was waiting for this and did ping us (ftpteam) multiple times, but now it is there. You can read more about this feature in my list mail and my initial blog post. (Oh, and something I have missed about everywhere I wrote about this: This whole transitions thing is based on an idea from Marga!)
• Added a mapping in dak, requested by Luk
• Merged a patch from another ftpteam member, Thomas Viehmann, which fixes daks handling of Format 3.0 (something) uploads. Currently it rejects them, without the merged patch it just crashed.
• Changed our daily cronscript to no longer VACUUM/VACUUM analyze projectb in every run. Postgres >= 8.1 has autovacuum, and its turned on, so we should be fine without extra runs of it. (And while i write daily cronscript or cron.daily - I mean dinstall, right now run twice a day).
• Fixed a breakage in code introduced by Debian maintainers which led to process-accepted (one main part of the daily cronscript) breaking. It was triggered by some octave-$FOO package upload, where the ###censored### did add someone twice into the Uploaders: field. Not helpful, but now we ignore this case and just warn us.
• Added a script to expire old database dumps. We do dump our projectb (the main archive database) twice in every run (beginning/end), which made 4 dumps a day. While old dumps seemed to have been removed on an irregular schedule - the dumps took about 71Gb in total. Which pretty much filled up merkels /org, as they get synced there. Now, my script (reworked version of a script from Florian Reitmeir) works with an “incremental deletion” scheme:

  RULES = [ ‘days’:14, ‘interval’:0 , ‘days’:31, ‘interval’:1 , ‘days’:365, ‘interval’:31 , ‘days’:3650, ‘interval’:365 , ]

  That means we now keep all files from the last 14 days. Then keep one per week. Then one per month and finally one per year for up to ten years. All the rest gets deleted. Space usage of our dumps now: 4.8Gb. Thats 66Gb gained. Source is in dak bzr if you want it, MIT licensed. If you improvie it further I love to see patches.
• Changed the way the projectb copy on merkel gets synced. Up to now it was run from a cronjob which syncs a number of files people want to see on merkel, including the database dumps, then reloads the database using the latest dump. This was run at a “random” time, scheduled to be shortly after dinstall. Problem with such a setup is that it will miss extra dinstall runs and also might import old data, as the timing of the cronjob meant it runs while dinstall on ftp-master is still doing its work. So bad bad. It is now done using the ssh trigger feature I described a while ago. So our daily cronscript now tells merkel when it should sync its database again.
• Coordinated with the qa group we now also push them, when the sync on merkel is done, so they can kick their cronjobs to reread projectb and just run whenever they get told that something changed. Yet another bad timing eliminated. (Well, will be done today). Oh, if you have something that depends on information from projectb / ftp-master and try to schedule it to run after dinstall - talk to me, we might just push you too.
• Started talking with the release team how britney, the script which manages our testing distribution, should be handled in the future. It currently is run fully under control of us ftpmasters (and reading hint files from the release team). Ideally this gets changed so that the release team has the control of the code and whatever gets run with it and then, in some way, maybe using ssh triggers, tells us to import a new dataset for testing. That needs some thinking, as obviously it should be limited to testing and we should make sure it doesn’t break the archive, but I think that is doable.
• Prepared a patch that sanity checks the Provides: field, something we currently don’t do. Mailed our internal team address about 3 days ago, to let others look at it, no response yet.

The above should nicely sum up my work in the past few days. Most of it pretty trivial, but still things that have to be done. I plan to keep doing things, slowly going from the trivial stuff to more complicated ones, but there is lots of stuff ahead. Some ideas, and this is a very incomplete list just from my head, there are tons of things that one could do, include

• Finally allowing dpkg-sig support in .deb files. I once, years ago, made a patch for it, which never got applied. (Mostly my fault here). Need to rewrite that to fit the actual code.
• Add a few more sections to our archive. There are multiple bugs asking for them, and some others also come to mind. Like java, ruby, octave, haskell, debug to name a few, but there might be more needed. (Yes, longterm all sections should die and be replaced with debtags. I just don’t think debtags is there yet?!)
• Maybe finally drop m68k and add other architectures to the archive, like some $foo*bsd one. (Thats for after lenny of course, at the time arm also gets dropped).
• Merge a patch I got from Myon which will keep uploaders in projectb.
• Enable bzip2 support for sources, not only for the binary packages. I have a patch ready, it’s not yet merged. Needs to test if anything breaks in stable if we apply it, before we can think about it. Worst case it has to wait until we are running lenny. (The archive runs on a machine with stable, so allowed features always have to be supported in stable).
• Process the currently waiting requests for pseudo-packages and either reject or approve them. After thats done - talk to the BTS maintainers to hand the management of pseudo-packages over to them, as 99% of the usage of those is in the BTS.
• Get dak to optionally mail the sponsor of a package too, if not already in the list of those getting a dak mail. Which isn’t easy. One proposal is to just look at the gpg keyid and get the Debian uid from it, send mail there. I don’t want this, as people are, unfortunately, able to disable mail receiving for their @debian.org address. Which would give us lots of bounces. No way we like that. Similar problems with “Just take one userid that looks like a mail address from their key”.
• Improve various parts run by our daily cronjob, as that one takes ages (about an hour today). Speed improvements are always nice there.
• Think about having more dinstall runs a day. Like - every 2 or 4 or 6 hours could be nice. But that needs discussion within the ftpteam and also with the mirror people before it can be done. But 6 hours seems to be something nice to have, more might be also ok.
• Coordinate with DSA to enable the continous AKA WAL archiving for our database.
• Make merkels sync be more instant, ie. no longer rely on a push of a database dump whenever dinstall run, but something thats near realtime. Having changes done on ries immediately synced to merkel.
• More (active) ftp-team member, maybe?!

Now, do you have any time to kill? Do you want to help? Some things you could do:

• Go look at our bug page and start there. Someone, I think Don, already started using user categories. It would be nice if someone is willing to keep up with the bugs and put them in categories. And continue to do that in the future.
• Generally help with our bug page. One nice task some people do, and possibly more could also do, is retitling bugs. Especially removal bugs tend to have a wrong title. The format is pretty specific…
• Feel free to submit patches to me. I promise to look at them without too much delay and at least give you a hint what might be wrong or could be done better. And if it makes sense, doesn’t break the archive, works, and is something dak should have - I will also merge it. Of course trivial patches are way easier in that regard, non-trivial ones should go via our ftpmaster address first, to leave others a chance to comment on. Bonus points if you provide bzr trees one can merge from, and the bzr tree you should work with is http://ftp-master.debian.org/bzr/ftpmaster-dak/ - patches/bzr trees against outdated versions won’t have much luck to get looked at. :)
• Keep me happy. However you do it, just don’t hug me. :)

I've bought a new hard drive for my laptop recently because I finally got fed up of my constantly-full disk. Having to browse around in $HOME looking for stuff which can be safely deleted just because I want to run fetchmail (and that would fill up my disk) just sucks. So, after getting a cheapo 160 GB 2.5" disk (the old one was 80 GB), I had to move all my data to the new disk. As I didn't want to re-install from scratch I started with dd'ing the whole disk over to the new one (using a live CD and an external USB hard-drive enclosure). This took pretty long, but went fine otherwise. The new disk then contained all my partitions (hda1-hda3) and also GRUB in the MBR etc., as expected, but was still only 80 GB in size, of course. So the first step is to enlarge the hda3 partition, which is a dm-crypt volume that contains various LVM logical volumes (for /home, /usr, /var, swap, etc.), each of them using the ext3 filesystem (except for the swap volume, of course). 0. Perform backups, boot from a live CD Important: If you plan to perform any of these steps, make sure you have recent backups! I take no responsibility for any data loss you might experience. You have been warned! First off, you should boot from a live CD which has all the tools you'll need, including cryptsetup, LVM tools, resize2fs, etc. You can use the nice grml live CD for instance. 1. Resize partition This sounds scary (and it is!), but the way I enlarged the encrypted hda3 partition was by first deleting it via fdisk. First, issue the "p" command in fdisk, write down the exact start cylinder of hda3. Then delete hda3. Now create a new hda3 partition which starts at exactly the same cylinder as the old hda3 but is larger, i.e. in my case it has ca. 80 GB additional space. Your data will still be there if you don't screw up, and the partition is bigger now. Using something like gparted will likely not work as expected, as the partition is encrypted! 2. Resize dm-crypt volume Nothing to be done, it seems dm-crypt automatically adapts and notices that the partition is bigger. Just "open" the encrypted volume using cryptsetup now:

  $ cryptsetup luksOpen /dev/hda3 foo

3. Resize LVM physical volume Next step is to tell LVM about the new space. We first resize the LVM physical volume on the foo "partition".

  $ pvresize /dev/mapper/foo

That will use all newly-available space for the volume. 4. Resize LVM logical volume Now we can pump the new space into any of the logical volumes (or into multiple ones). I only increased one logical volume, my /home:

  $ lvresize -L +74 GB /dev/vg-whole/lv-home

5. Resize ext3 filesystem The final step is to resize the ext3 filesystem on the lv-home logical volume (after running the obligatory fsck -n). I first used ext2resize, but that failed horribly:

  $ fsck -n /dev/vg-whole/lv-home
  $ ext2resize /dev/vg-whole/lv-home
  error: Invalid argument: seeking to 3258921205760

This seems to be a known bug, ext2resize apparently cannot handle large disks or something, and as I found out a few minutes later it's pretty much deprecated anyway. The better solution is to use resize2fs:

  $ fsck -n /dev/vg-whole/lv-home
  $ resize2fs /dev/vg-whole/lv-home

That's it. We can now reboot the system from disk and enjoy ca. 80 GB of additional hard drive space. Yay!

We escorted Sarge to its last home. 3.1r8 is done, thanks to all the people who made it possible. A big thanks goes to James Troup, our ftpmaster of the day doing all the grunt work of getting a new point release out of the door. To bring in a more personal feeling of who makes this all possible, here is a list of people contributing uploads to 3.1r8 (mostly people from our fabulous Security Team):

• Alberto Gonzalez Iniesta
• dann frazier
• Darren Salt
• Devin Carraway
• Florian Weimer
• Gregory Colpart
• Julien Cristau (who is glad that he finally got rid of xfree86)
• Luk Claes
• Martin Pitt
• Michael Koch
• Moritz Muehlenhoff
• Noah Meyerhans
• Patrick Schoenfeld
• Roland Mas
• Russ Allbery
• Sean Finney
• Steffen Joeris
• Thijs Kinkhorst

I would also like to thank dann frazier, Luk Claes, Martin Zobel-Helas and Neil McGovern for helping with the preparation of the point release.

The swap partition can hold a lot of unencrypted confidential information and the fact that it persists after shutting down the computer can be a problem.

Encrypting a swap partition however is slightly tricky if one wants to also support suspend-to-disk (also called hibernation). Here's a procedure that worked for me on both Debian Lenny and Ubuntu 7.10 (Gutsy Gibbon):

0- Install the cryptsetup package:

apt-get install cryptsetup

1- Setup the encrypted partition as root:

swapoff -a
cryptsetup -h sha256 -c aes-cbc-essiv:sha256 -s 256 luksFormat /dev/hda2
cryptsetup luksOpen /dev/hda2 cswap
mkswap /dev/mapper/cswap

2- Add this line to /etc/crypttab:

cswap /dev/hda2 none swap,luks,timeout=30

3- Set the swap partition to be this in /etc/fstab:

/dev/mapper/cswap none swap sw 0 0

4- Configure uswsusp to use /dev/mapper/cswap and write unencrypted data

dpkg-reconfigure -plow uswsusp

You will of course want to replace /dev/hda2 with the partition that currently holds your unencrypted swap.

(This is loosely based on a similar procedure for Ubuntu 6.10.)

keeps the release away. That's why, following Sesse last year, I started to work on (at least), one RC bug a day. If I do that alone, and that no new RC bugs are opened^[1], we will release in 460 days; now if 10 DD do the same, it becomes 46 FWIW, today, I made Luk (Claes) reassign and downgrade #470453 and sent a DELAYED/2 NMU for #470002. And you, what did you do for the release ?

I am 10 000 metres above sea level, on my way from Melbourne to Wellington. I am looking back at a very enjoyable week of conferencing, with LCA 2008 ending yesterday, followed by today s Open Day. The purpose of this final day is to invite the general public to learn about open-source. Individual projects present their work at booths and field questions by bypassers. Jacinta Richardson and the other organisers and helpers of the Open Day have done an amazing job. The place was buzzing and the selection of projects broad and interesting, even to me. Two talks and a series of lightning talks, as well as catered food for everyone rounded it off. I will try to have this event in mind as we organise a similar event in Buenos Aires after the forthcoming DebConf8 in Argentina. I had a splendid time at the conference and probably can t thank Donna Benjamin and her army of mignons enough for organising it. Compared to the other open-source conferences I previously attended, this one was the most professional. Good job, everyone!!! Here are the highlights:

• I opened the Debian mini-conf with the state of the project address.
• My second presentation on that day was on my packaging workflow (slides), including a live demonstration, which was received well even though I should have prepared it.
• At the keysigning, I (again) used my Transnational Republic identity card and reported on it in another post. I was pleased by the level of attention this got, and how many people approached me during the week to discuss the issue.
• I really enjoyed the talk by Adaora Oniya on communication challenges in Tuesday s LinuxChix mini-conf. Among other interesting points, she listed traits that are typical to males and females and stated how none is 100% on either side. Glancing over the adjectives, I started to wonder about my feminine nature.
• Later that afternoon, a bunch of us sat down to find similarities in packaging workflows of the Debian and Fedora projects.
• Bruce Schneier s keynote titled Reconceptualising Security didn t teach me anything new, but that was to be expected since I am a regular reader of his Cryptogram newsletter. He s a good speaker, but I think his talk would have benefitted from a few, simple slides to illustrate some of his points.
• A few of us met on Wednesday morning for a few games of the Asian board game Go. Paul Wayper and I played two non-competitive games, in which we talked about each others moves and strategies. I think I learnt quite a bit during that session.
• Jeff Waugh s mini-conf talk titled Disintermediating Distributions as well as Stormy Peters keynote Would you do it again for free? , as well as a few other sets of slides, taught me that I really need to work on my own presentation style and get rid of bullet points once and for all.
• The Penguin dinner, traditionally a catered event for conference attendees, took place at the Melbourne Night Market this year. Everyone got food tickets and went off to the dozens of stalls to get food and drinks. This was an excellent idea to deal with 600 people.
• I was very glad to have attended Jason White s presentation on braille and text-to-speech interfaces on Thursday.
• My presentation on [netconf](http://netconf.alioth.debian.org] was well attended and the audience had plenty of good questions. I was able to answer most of them with reference to the design of the netconf core, which is a good omen. The idea of on-demand dialing went into my notes. I screwed up once when I went off on a tangent while answering a question about firewalling and then forgot the original question, but my listeners showed mercy.
• Luke Kanies presentation of Puppet convinced me to allocate more time to this system administration tool. He did a very good job fielding questions and managing time, but he should try to slow down a bit.

Apart from the busy programme, I particularly enjoyed the hallway track , which is usually the reason why I attend these events. I really ought to practice remembering names and faces a bit better. I am not paying enough tribute to this week with this report, but I shall conclude it regardless. Unless something very unexpected comes up, I will attend next year s LCA in Tasmania. NP: Porcupine Tree: Futile

In the past I was not blogging small things if they were not worth a full blog entry on their own (or if I did not have the time to make up a full entry of it :). Inspired by the example of Raphaël Hertzog <hertzog@debian.org> with "News for Debian developers" for <debian-devel-announce@lists.debian.org>, I am intending to do the same on a monthly basis about my own Debian related work. This first entry about January 2008 also covers a few things from the last month of 2007. General News

• Trusted Computing
  
  After having taken over some rotting ITP bugs, Debian has now all the important packages to support Trusted Computing on platforms containing a TPM chip. The packages are not in good enough quality for release, but there is still some time left to fix that. Looking forward to make lenny supporting TPM properly out of the box, as well as aiming for making Debian the best TPM enabled distribution available.
  
  Currently, the TSS software stack consists of trousers, tpm-tools, opencryptoki, libengine-tpm-openssl, and ecryptfs-utils.
  
  
• Smartcards
  
  I am using smartcards since a while to hold GnuPG, LUKS, and OpenSSL keys/certificates. Thanks to Jonas Meurer <mejo@debian.org> for applying a fix and a patch of mine to cryptsetup. Together with my uploads of gnupg-pkcs11-scd, pam-pkcs11 and pcsc-omnikey, I can now use Debian out of the box with smartcards for authentification, not relaying on patched or private packages anymore.
  
  The next aim is to integrate smartcard support into debian-installer. It should be possible to use/store keys or certificates for encrypted filesystems directly from/to a smartcard during installation time.
  

Package News

• botan-devel
  
  The Botan library is maintained upstream in a stable release branch and a development release branch. Before, I was uploading as versioned source packages, botan1.4 and botan1.5. To be a bit more consistent, the two source packages are named botan and botan-devel now.
  
  
• gitosis
  
  Tommi Virtanen <tv@eagain.net> has written a marvelous tool to securely manage hosted git repositories, named gitosis. Having always looked for an elegant sollution to maintain git repositories through push/pull over SSH only, this package made an excellent addition to the Debian archive.
  
  
• gnunet
  
  GNUnet, more precisely the gnunet, gnunet-gtk and gnunet-qt packages where mainly maintained the last years by Arnaud Kyheng <Arnaud.Kyheng@free.fr> with me playing co-maintainer.
  
  Arnaud has become busy within the last months, so I took over a more active role on its maintenance. Currently, all gnunet related packages are in sync and in its latest upstream version available in the archive. There is even a new sibling, gnunet-fuse.
  
  
• icedove-l10n
  
  After one and a half year of pushing its maintainer without any effect at all, I finally took over the unmaintained icedove-locales package in October 2007. I immediately changed the package to the proper naming scheme (icedove-l10n-*) which was an outstanding issue since August 2006.
  
  In the last weeks, I have added unofficial localizations for Galizian, Nepali and Ukrainian, now supporting 38 localizations in total. Icedove localizations are now in good shape again, always matching the Icedove version and no longer lagging behind.
  
  
• iceowl-l10n
  
  Following iceweasel-l10n and icedove-l10n, there are finally also localizations for iceowl (Mozilla Sunbird) available. Populating packages for iceowl-extension (Mozilla Lightning) from the same source package is a bit trickier package-wise, but will be available soon too.
  
  
• iceweasel-l10n
  
  In September 2007, Robert Milan <rmh@debian.org> on behalf of the Catalan/Valencian Debian translator team asked me to remove the iceweasel-l10n-roa-es-val package. Unfortunately, this localization is related to a long standing cultural and political dispute between the Catalan speaking Spanish people and the City of Valencia. Additionally, the localization itself is of poor quality. Of course, I removed the package in unstable immediately and prepared an upload for stable at the same time.
  
  As usual, me asking something on debian-release results in first beeing ignored, then denied and third, two month after my request, beeing privately asked to upload nevertheless. This is one of the reasons I sometimes fully understand fellow maintainers not carring about stable at all anymore, it has become indeed too much of a hassle.
  
  
• traceroute
  
  For the last decade, Debian was shipping an implementation of traceroute originating from BSD. After I took over the package in late 2006, it became clear to me that Debian should not maintain its very own version of traceroute. Therefore, I replaced traceroute in August 2007 with an implementation from Dmitry K. Butskoy <Dmitry@Butskoy.name>. Apart from the fact, that this modern implementation is better in every way (faster, cleaner, less bugs), it has an active upstream maintainer and is used by different other Linux distributions too.
  
  
• syslinux
  
  Thanks to the work of Robert Milan <rmh@debian.org>, syslinux has now 64-bit CPU detection in unstable (2:3.55-2) and experimental (2:3.60-2) again.
  
  

Team News

• Debian Forensics
  
  Unfortunately, Debian has at the moment very few forensic related packages in the archive.
  
  Christophe Monniez <dfence.242@gmail.com> maintains a lot of forensic related packages on behalf of his Debian based forensic LiveCD. Beeing interested to see them in Debian, I am mentoring him now how to merge them properly into Debian where possible, and maintain them in the official archive. We have formed an Alioth project for this purpose. Packages are maintained in git, everyone is welcome to join.
  
  
• Debian Website
  
  After having offered my help to maintain the Debian Consultants list, I got added to the webwml team. Doing Debian consultancy myself, this is just another way of helping out Debian from time to time by adding, removing and updating some entries of like-minded people in a list.
  
  

The first of my talks at LCA 2008 gave me a chance to talk about the current state of the Debian project, which got me my first LWN.net coverage with a photo, even (subscribers only for now, the article will become public on 7 February). Thank you, Jonathan Corbet, for a very good article which nailed all the main points! Slides are here. I agreed to this talk on short notice because I like to talk about Debian and was honoured by the chance to represent the project in this form. I would not have been able to do it without plenty of helpful input from colleagues in the last few days. Since I didn t get a chance to display the final slide with the acknowledgements during the talk, I would herewith like to thank specifically Andreas Tille, Michael Banck, Kevin Mark, Josip Rodin, MJ Ray, Cyril Brulebois, Stefano Zacchiroli, Frans Pop, Moritz M hlenhoff, Russ Allbery, Steve Langasek, Luk Class, Andreas Schuldei, and Christian Perrier. No guarantees for the completeness of the list. The talk ended in an open discussion on how Debian could improve. I took notes and shall forward them to the project mailing list, once I get a chance. Thanks to all the participants, as well. Update: during the talk, I mentioned that there was no security support around the time of the etch release. Thanks to Moritz M hlenhoff, who spotted my error: that should have been sarge . The problems with security support had long been resolved by the time etch was being prepared, and this was in (large?) part thanks to Moritz. Sorry for the screwup! I also called Linux to tend towards multimedia more than one might like. I should not have made this comment as a representative of the Debian project, and I probably did unjust to the Linux kernel in whole. This is entirely a personal issue, I have a number of problems with Linux memory management, scheduling, and some other points relevant to production use. I ve had some of these problems for years, but they seem never to get fixed, while development is fast-paced. Then I look at some of the work being done and I wonder what the priorities are. Regardless, I should not have made this comment and I apologise for it.

If, like me, you wanted both an encrypted root filesystem and some form of bootsplash you may have discovered that this is tricky. You need to enter the decryption passphrase on the terminal which means exiting the bootsplash. I decided it must be possible to use a USB token with the key on it rather than a passphrase to decrypt the drive and while this seems supported upstream, it is not supported out of the box on Debian. This is a short howto explaining my solution. Pre-requisites You will need a USB hard disk and a computer using Debian with an encrypted root filesystem. I am assuming that you are using a stock kernel with an initramfs image and have a luks encrypted LVM containing the root filesystem. You will have to change some of the details below to match your specific system. In the examples below /dev/hda5 is the encrypted partition and /dev/sda2 is the partition on the USB disk holding the key. Setting up the key First we need to generate a random key and put it on the disk. To save having to mount things in the initramfs, I chose to use a partition at the end of the USB flash disk. This means repartitioning and reformatting your USB disk. I recommend allocating the last cylinder in fdisk to primary partition 2. Once you have the second, small partition (you are only going to use 1k, so as small a partition as possible) you can put a key on it. This is as simple as dd if=/dev/urandom of=/dev/sda2 bs=1M . Adding the key to the luks partition Next, you need to add your new key as able to decrypt the partition. Luks allows several keys to be able to unlock the partition. The real key is decrypted under each of the user keys or passphrases and stored in a key slot' in the partition. To add your key type:

touch /tmp/keyfile
chmod 600 /tmp/keyfile 
dd if=/dev/sda2 bs=1k count=1 of=/tmp/keyfile
cryptsetup luksAddKey /dev/hda5 /tmp/keyfile
wipe /tmp/keyfile

Note the careful handling of the temporary key file (luksKeyAdd won't read from stdin, whereas luksOpen will), I recommend storing it on a ramdisk and you should certainly use wipe rather than rm if you don't. Once you have added your USB key you could remove the passphrase from the key list with luksDelKey, but if for any reason you lose the USB hdd you will be unable to decrypt the partition; I recommend leaving both keys available. Booting automatically In order to boot using the USB key we need to provide a couple of helper scripts in order for the initramfs to work. We also need to set some parameters on the kernel command line. In Debian these scripts can be added to the initramfs by putting them in /etc/initramfs-tools/. The first script is a helper script used when building the initramfs. This writes a second script into the initramfs itself which takes the partition as a parameter and prints the key on stdout. This should be written to /etc/initramfs-tools/hooks/cryptkey (executable) and contain:

#!/bin/sh --
PREREQ=""
prereqs()
 
   echo "$PREREQ"
 
case $1 in
prereqs)
   prereqs
   exit 0
   ;;
esac
. /usr/share/initramfs-tools/hook-functions
cat > $ DESTDIR /bin/loadkey 

The second script runs immediately before the cryptsetup script in the initramfs and ensures that the USB disk is available. This will cause the boot sequence to block until the USB disk is inserted and the device nodes created by udev. It can be provided directly in /etc/initramfs-tools/scripts/local-top/00ensureusb (executable) and should contain:

#!/bin/sh --
PREREQ=""
prereqs()
 
   echo "$PREREQ"
 
case $1 in
   prereqs)
      prereqs
      exit 0
   ;;
esac
if ! grep cryptopts /proc/cmdline >/dev/null; then return; fi
. /scripts/functions
log_begin_msg "Waiting for USB to become available..."
modprobe usbcore
modprobe uhci_hcd
modprobe ehci_hcd
modprobe usb_storage
while [ ! -b /dev/sda2 ]; do
   sleep 1
done
log_end_msg
exit 0

The cryptsetup script itself reads configuration from the kernel command line. Here you can give it a script which will read the key and the source for the key to read. Edit your grub or lilo config and append the following to the kernel command line: cryptopts=keyscript=/bin/loadkey,key=/dev/sda2,source=/dev/hda5,target=hda5_crypt,lvm=hecate-root You will obviously have to change the name of your lvm root partition (volumegroup-logicalvolume). I recommend having two entries in the boot menu, one with the cryptopts and one without to allow easy decryption using the passphrase instead. Conclusion That should be everything. Boot your computer and inset the usb hdd. When the boot process passes decryption you can remove it again. You may have to replug it if you boot with it inserted to start with.

The PTS has grown RSS feeds These days I'm taking part in the Extremadura Debian QA Metting. Today is the first day and I've mostly spent it doing some PTS hacks. The first visible tiny teeny outcome of that is the addition of RSS feeds for the "latest news" part of each package page. For example, in the PTS page of bash you can see a link to the corresponding RSS feed. (Other package pages will need a bit to be completely regenerated by the current PTS run ...) Thanks to KiBi and Luk the pages are now also listing links to the corresponding entry in svnbuildstat. Forthcoming additions are links to outcome of the piupart tests run by Liw and H01ger and 2 new markers: one for lowThresholdNmu-ability and the other for maintenance by Debian Maintainers. Stay tuned!

Right now, some Debian Developers (and also not yet Developers, like me:), are on
the work sessions in Extremadura, I am on the QA and release teams meeting.

We started in the morning with presentations (see also the schedule). Any comments and suggestions welcomed, please add comments below the post.

Lucas Nussbaum presenting:


Most of us:



And in details, names from left to right. Cyril Brulebois, Gon ri Le Bouder:


Luk Claes, Marc 'HE' Brockschmidt, J rg Jaspert, Lars Wirzenius:


Fabio Tranchitella, Bernd Zeimetz, Mario Iseli, Luk Claes:


Filippo Giunchedi, Stefano Zacchiroli, Tzafrir Cohen, Simon Richter, Faidon Liambotis:


And again, so that Faidon is visible:

It's official: I'm beginning to be a bit overloaded. Luk gently asked me about my status in the (stable) release management team. That just made a bit more guilty not doing that I'd like to do. Current TODO list involves:

• release awesome 2.0-rc1 and update website and documentation for it;
• work on rebuildd, finish and polish 0.3 version;
• run a full rebuild of the Debian archive to test rebuldd 0.3, do some QA work;
• update mod_defensible to fix problem with udns timeout;
• work on Debian release management, at least rewrite lost script for (old-)proposed-updates which were on ries'
• work on Debian Xen;
• handle a lot of waiting task on my network/servers.

Now, the thing that will help: I'm house moving this week-end with no (real) Internet connection yet. I only managed to establish a VPN over port 53/udp on a hotspot from a pub near my new apartment with 25-30 KB/s bandwidth, which is better than nothing actually.

• awesome* is asking me a lot of time right now, and since it's my last launched project, I am motivated and have a lot of idea, so I like to hack on him right now. I think I will have to postpone future release to not forget other things.

I'm going to see what happens by the end of the year and if I'm able to catch up with everything. Otherwise I might need to drop some things Life is too short.

On the bus yesterday I noticed a graffiti etching clearly left by someone employed by IBM. In fact the guy in the row in front had an IBM tee-shirt on, and I suspect he is the culprit, or possibly one of the OzLabs people. The photo is crap (it's hard to take a photo of a blukhead in the dark from the middle of the back seat on a crowded bus with a phone camera without arousing suspicion) but it clearly says

   I
(heart)
 POWER5

Check out my CSI style image enhancement: If you're ever on Sydney Buses bus number 2660 it can probably still be seen on the driver side window on the back seat. Maybe what Itanium needs isn't higher clock speeds, lower power, faster FSB, etc., but a concerted tagging effort on public transport around the world!

• Automated In-Flight Refueling of an F/A-18 Fighter Jet
• Paintings Of Hope and Hopelessness
  Excellent.
• Toy

• Froscon rocks!
• explored some more software in more detail, including op, dconf, dstat, unoconf, dwscan, ikiwiki, openQRM, Pentabarf, sl
• it was great to meet so many people (some of them for the first time in RL), including Alexander ‘formorer’ Wirt, Timo ‘Spida’ Boettcher, Marc ‘HE’ Brockschmidt, Bernd Zeimetz, Thomas ‘MrFai’ Lange, Sebastian Harl, Elmar Hoffmann, Martin Zobel-Helas, Luk Claes, Christoph ‘myon’ Berg, Klaus Knopper, Sven Guckes, Dag Wieers and many more…
• using ‘vlock -a -n’ with Debian package >=2.0-2 rocks when using libthinkfinger and authentication via ’swipe finger’ (thanks, formorer :-))
• having Debian release managers (hi Zobel and Luk :-)) by hand rocks
• the book shop at Froscon (Lehmanns) provided one of the best selection of books I’ve seen on an Open-Source event so far (fsck, 3 more books for my library)
• organization of the event was very good
• sadly the press plant made a fscking error when shipping the froscon edition of grml-CDs, so 1000 grml-CDs failed to arrive in time
• thanks to Pierre Schmitz and the Archlinux team for providing us linux-user DVDs containing grml 1.0 and grml64 0.1!

• The problem(s) with OpenID
• Why learning Haskell/Python makes you a worse programmer
• Bridges and code