This paper by Rodney Van Meter about ZCAV (Zoned Constant Angular Velocity) in hard drives is very interesting. It predates my work by about four years and includes some interesting methods of collecting data that I never considered.

One interesting thing is that apparently on some SCSI drives you can get the drive to tell you where the zones are. If I get enough spare time I would like to repeat such tests and see how the data returned by disks compares to benchmark results.

It's also interesting to note that Rodney's paper shows a fairly linear drop of performance on higher sector numbers (while he notes that it would be expected to fall off more quickly at higher sector numbers). One of my recent tests with a 300G disk showed the greater than linear performance drop (see my ZCAV results page for more details). It might require modern large disks to show this performance characteristic.

I also found it very interesting to see that a modified version of Bonnie was used for some of the tests and that it gave consistent results! I assumed that any filesystem based tests of ZCAV performance would introduce unreasonable amounts of variance into my tests and instead wrote my ZCAV test program to directly read the disk and measure performance.

It's times like this that I wish for a "groundhog day" so that I could spend a year doing nothing but reading technical papers.

My girlfriend who was returned from hospital on Friday learnt a couple of days later that she'd managed to suffer a fractured skull. Apart from that shocking news I've been doing little. Lots of travelling, lots of tidying up ~/bin, little else. One new toy is release which will allow me to easily release projects. The idea is you run "~/bin/release" inside a project directory and it will:

• Run a command such as "make release".
• Check the release is signed correctly.
• Upload the file, via scp, to a remote host.
• Run a command to trigger a mini-dinstall.

Very simple, almost trivially so, but it has a lot nicer than having to do all the bits manually. (sample .release file.) I had a piece of code for triggering new freshmeat announcements working a while back - but it was a little too fragile when it came to reading the ChangeLog files I use so I've killed it for the moment. (Probably "$EDITOR fresmeat.tmp &" would be a better idea anyway!) Connectivity is bad right now, since I'm in the middle of changing home ISP, but hopefully that will be resolved in the next week or two. (Switching from Telewest/Virgin -> Sky for people in the UK who might care.)

Thanks to Romain Francoise, I found and watched Martin Michlmayr's Release Management in Large Free Software Projects talk on Google Video's Open Source Speaker series. Martin: Thanks a lot, great talk. I've been following your presentations lately, as I've given some talks on this topic - Quality Assurance on Free Software Projects (Spanish only) - However hard I try to remain faithful to the subject, I end up giving a talk on what Free Software is and how its processes are naturally more prone to yielding better quality than propietary projects.
Anyhow, with this post I want to do basically three things:

• To cheer Martin for writing and presenting the topic. I've been refering to your work for a long time, and although my presentations are not formally papers and thus have no quotation value (in fact, they often don't have the references as anything more than comments in the source files, it at all), I should thank you frontally and publicly.
• To get some more attention to the topics presented. Your point is very interesting and important to be taken into account specifically for Debian: I'm not 100% with you regarding that time-based releases is the way to go, but the point you make when discussing GCC (IMHO) is an important one: A project can shift to time-based releases even if it does not release on time, and its general inner processes can become quite cleaner. I do think we witnessed this with Etch in Debian - The process was much more believable and peaceful (even with all the release-related mudfights) than with Sarge. I think it partly stems from what you point out: We aimed to release in December, and we failed to precisely meet the target - but having the date helped set the release goals to something believable, and not let Sid's unstability drift too far away. During Sarge's testing cycle, for a long time, few of us even cared to use testing at all, as it was... Something completely undefined.
• To get some insight on some points. Martin, in several of the projects you analyzed, there is a tendency to get to a six months release cycle. Many other projects also follow that cycle - There is a time-based project you didn't mention that is to me one of the inspirations of such model, and has proven to work for over a decade: OpenBSD. Yes, it lacks in many areas, and definitively not everybody can aspire to become an OBSD developer, but they have done high-quality six-month releases since they exist. However, speaking specifically for Debian: Would you like our project to follow such a schedule? For many reasons (including one you mentioned, the difficulty to support several concurrent versions, or just having oldstable versions be left too early with no support) I think we should aim for a 18 month cycle, 12 at the very least. Either I lacked attention when you went over that part or you didn't mention it - but why do you think such a short cycle is good for so many projects? What would you like Debian to do? (Of course, for answering this, you might be Martin, or somebody else entirely ;-) )

In the company I work for, most documentation is maintained in Word format. Except mine. I have a dokuwiki and am thankfully allowed this exception as I am the only Linuxer in the company. Since Windows systems need external documentation (being hindered by the absence of commentable text configuration files), there is a policy that all configuration data needs to be explicitly documented. I hate that idea, since documentation is always outdated, and documenting configuration changes doubles the work that needs to be done. After finding out that dokuwiki has a command line interface, I implemented a mechanism that can run from cron and keeps wiki pages of configuration files up to date on an automated basis. On the target systems (the ones that need to have their configuration documented), I installed a script which generates a tarball containing the relevant configuration files on standard output. For more sensitive data, the script could do some basic sanitazion such as removing passwords from the configuration files before putting them into the tarball. On the system running the cron job, the following script runs:

#!/bin/bash
set -e
set -C
set -u
JOBNAME=“update-wiki-firewall-config”
DWPAGE=“php4 /usr/share/dokuwiki/bin/dwpage.php”
TMPBASE=“/tmp”
SSHID=“$HOME/.ssh/$USER-passphraseless-$(hostname)”
REMOTEHOST=“remote.fqdn.example”
REMOTEJOB=“pull-netfilter-init-config-tar”
SHAREDIR=“$HOME/share/$JOBNAME”
WIKINAMESPACE=“pointer:to:namespace”
start=’/*BEGIN generated firewall rules */’
end=’/*END generated firewall rules */’
insert=’/*INSERT generated firewall rules */’
umask 077
if ! TMPDIR=“$(mktemp -d $TMPBASE/fwconfig.XXXXXXXXXX)”; then
        echo >&2 “ERR: cannot create temp dir in $TMPBASE”
        exit 1
fi
cd $TMPDIR
mkdir remote
ssh -i $SSHID root@$REMOTEHOST $REMOTEJOB   \
 tar --extract --gzip --file - --directory remote
mkdir workdir
touch workdir/rulelistfile
echo “$start” >> workdir/rulelistfile
for fwfile in $(find $TMPDIR/remote/rules/up -type f   sort); do
  MTIME=“$(stat --format=”%y“ $fwfile)”
  PROSEEXPLANATION="$( $fwfile sed -n '/^#::#/ s/^#::#[[:space:]]*//;p;q; ')"
  if [ -z "$PROSEEXPLANATION" ]; then
    PROSEEXPLANATION="netfilter-init internal code"
  fi
  rm -f workdir/newwikipage
   $SHAREDIR/wikipagetemplate \
    sed \
        -e "s PLHfilenamePLH $(basename $fwfile) " \
        -e "s PLHproseexplanationPLH $PROSEEXPLANATION " \
        -e "s PLHmtimePLH $MTIME " \
        -e "/PLHcontentsPLH/r$fwfile" \
        -e "s/PLHcontentsPLH//" \
  > workdir/newwikipage
  WIKIPAGENAME=“$WIKINAMESPACE:regeln:$(basename $fwfile .rul)”
  $DWPAGE checkout $WIKIPAGENAME workdir/wikipage
  if ! cmp --quiet workdir/wikipage workdir/newwikipage; then
    cp workdir/newwikipage workdir/wikipage
    $DWPAGE -m “new contents imported from $fwfile” commit workdir/wikipage $WIKIPAGENAME
  fi
  echo “  * [[$WIKIPAGENAME $(basename $fwfile)]] - $PROSEEXPLANATION” >> workdir/rulelistfile
done
echo “$end” >> workdir/rulelistfile
$DWPAGE checkout $WIKINAMESPACE workdir/contentspage.txt
 workdir/contentspage.txt \
  sed -e "\ ^$ start//\\*/\\* \$ ,\ ^$ end//\\*/\\* \$ d; "   \
  sed -e "\ ^$ insert//\\*/\\* \$ rworkdir/rulelistfile" \
  > workdir/newcontentspage.txt
if ! cmp --quiet workdir/contentspage.txt workdir/newcontentspage.txt; then
  cp workdir/newcontentspage.txt workdir/contentspage.txt
  $DWPAGE -m “new contents page” commit workdir/contentspage.txt $WIKINAMESPACE
fi
cd /
rm -rf “$TMPDIR”

Yes, this needs some more documentation and generalization. But it’s just a proof of concept that needs some polishing before being put into real life use. Here are the two template files for wiki page and contents page:

====== Firewallregeln PLHfilenamePLH ======
Last changed on target system: PLHmtimePLH
PLHproseexplanationPLH
<code>
PLHcontentsPLH
</code>

===== Dump of firewall rules =====
/*INSERT generated firewall rules */
/*BEGIN generated firewall rules */
/*END generated firewall rules */

The index page template relys on the HiddenComment dokuwiki plugin to be installed, or the placeholders show up in the rendered wiki page. The code uses the first comment line marked with #::# to generate a short explanation of the file being pulled into the wiki. dwpage.php is a fully-fledged command line interface to dokuwiki, committed new pages are fulled versioned as if entered through the wiki web front end. This way, the documentation in the wiki is guaranteed to be current and to fit the configuration found on the live system - it is directly pulled from the live system. Yes, rendering of the code is currently suboptimal. Working on it.

At work, I’ve got two screens on my Sarge workstation “snitch”. Since I want to switch virtual desktops independently on both screens, I don’t have a Xinerama setup but a Dual Screen setup. So my left and right screen do have different $DISPLAY (“:0.0” and “:0.1”) set. This is neither a problem for FVWM nor xlock nor XScreenSaver. But it is a problem for nearly every modern web browser available which checks, if there’s already an instance of it running. So if you try to start a new instance of a web browser on the other screen, most graphical web browsers make more or less problems:

• Galeon 1.3 and Epiphany always opens new tabs or windows on the display where its first instance is running, i.e. ignores $DISPLAY completely except on the first call.
• Kazehakase (0.3.7) just opens a new tab in the running instance.
• Firefox 2.0 thinks it crashed and asks if it should restore tabs and windows. Haven’t tried any further.
• Opera 9.20 pops up a dialog, says, there seems already a copy of Opera running and asks if it should continue with startup. If you say yes, only the bookmarks of one of the two instances get saved, probably those of the one with the last added bookmark or the one which exited last.

The only graphical web browsers which simply just work on a Dual Screen setup are Konqueror, Links2 (called with the -g option for a GUI), Chimera 2, Amaya and of course Dillo. Unfortunately I’m neither a fan of KDE nor of Konqueror and I do want a web browser with CSS and tab support… And Amaya is, well, only a reference implementation… (Chimera 2 from Sarge btw. segfaulted on two of the four pages I tested it with. Seems to have problems with PNG images.) So my current setup is to have Kazehakase as my main work web browser (with all the local web applications I need) on the right screen while I have Opera on the left screen for surfing, looking up documentation, testing web pages and other things. BTW: I don’t use Gecko based browsers for surfing on that box at the moment, since there are some web pages (the spammer vandalised Kazehakase wiki for example, at least a few months ago) which manage to be rendered in such an ugly way by Gecko so that XFree86 with the binary Nvidia (at least the last five or six versions I tried) just crashes away — either at once or when you try to switch to a text console by pressing e.g. Ctrl-Alt-F1 while such a page is displayed.

Currently there is a problem with the MySQL default install in Debian/Etch (and probably other distributions too). It sets up "root" with dba access with no password by default, the following mysql command will give a list of all MySQL accounts with Grant_priv access (one of the capabilities that gives great access to the database server) and shows their hashed password (as a matter of procedure I truncated the hash for my debian-sys-maint account). As you can see the "root" and "debian-sys-maint" accounts have such access. The debian-sys-maint account is used for Debian package management tools and it's password is stored in the /etc/mysql/debian.cnf file.

$ echo "select Host,User,Password from user where Grant_priv='y'"   mysql -u root mysql
Host    User    Password
localhost       root
aeon    root
localhost       debian-sys-maint        *882F90515FCEE65506CBFCD7

It seems likely that most people who have installed MySQL won't realise this problem and will continue to run their machine in that manner, this is a serious issue for multi-user machines. There is currently Debian bug #418672 about this issue. In my tests this issue affects Etch machines as well as machines running Unstable.

Last week I started the final round of Debian upgrades for the servers I maintain here and there, which is mostly complete today. I haven't been so lucky with upgrades this time, for a long list of different reasons. In the end, the smoothest upgrades were those boxes I upgraded when etch froze or so. natura.oskuro.net is the box serving these pages. It's an old, extremely noisy Pentium 150 which I've been intending to replace for a while now. I started the upgrade early on Thursday, knowing it'd take a while (natura takes its time only to read the Dpkg database), and it had apparently finished when I was ready to leave the office. Three issues:

• apache2's enabled modules were forgotten and I had to reenable them again, plus IIRC the default "It works!" site got reenabled, hiding the blog for a little while.
• bind didn't like some change in one of the default configs and I failed to noticed it had not started. After the reboot, the box was unreachable remotely, but that was OK as I had to go visit my dad that night for his birthday, so it was fixed after one hour or so.
• Last, my blog stopped working, and while I thought it'd have something to do with apache2.2, I had no time to have a close look as I had to leave to Lleida this weekend. Yesterday I discovered that for some reason, the old tar.gz PyBlosxom install wasn't liking the new python2.4, so I decided it was about time to move to PyBlosxom 1.3, from the Debian package. Not without the mandatory "It works!" post published in the gazillion Planets, natura was ready to go.

The very same night of last Thursday, I decided to dist-upgrade the box which serves the Spanish Debian website mirror. That's the only purpose on the box, so you can imagine the upgrade should have been pretty straight-forward. And so it seemed, until, in the middle of unpacking, dpkg died with a horrible I/O error, and I dropped into an unusable remote terminal with no working commands. Fortunately, apache2 was still up and running, and the web service has been working without interruption since the hard drive crash, albeit with no syncs from www-master. Today, Sergio visited the campus and had a look. It was a XFS crash, which got cleanly repaired using an install CD. We have an empty partition in the box, and will probably move the system to it temporarily, and back to the RAID, but on ext3. When the box was back online, I just had to resume the upgrade process, make mdadm happy and update lilo.conf before rebooting into the new kernel. This box uses LILO for some obscure reason I can't remember too clearly anymore. The box has just one partition on a md array, on two SCSI disks on a aic7xxx-based controller. Can anyone hint me why GRUB would have failed on us back in sarge, and if any fixes in the etch version would work any better? Using LILO here is error prone, and basically feels like a step back. Anyway, www.es.debian.org is now back up and running with updated content. Sindominio.net had its bi-annual upgrading party last monday, but unfortunately I wasn't able to help much as when I tried to log into the server, I must have caught the system in the middle of some key lib upgrade or something, and again I was locked in a unusable shell which would only segfault. Given my previous experience, I assumed that something had gone wrong and the box would need to be fixed at the console, and after 20 minutes I gave up helping on that front. Until I noticed, quite a long while later that I was still getting mail from the server. I managed to log in to discover the upgrade was done, with just a few bits remaining to be done. The major issues were encountered with our pam and ldap setup, plus nscd kept dying causing quite a lot of mayhem all over the place. Great work from Seajob, Syvic, nogates, apardo and the rest of the people who handled it! With etch, we can finally move back to an official Debian kernel, something we've been longing to do for a long time. The only pending upgrade issue is that we need to move from our old jabber server to either the traditional jabberd 1.x or ejabberd; our current implementation is no longer supported in Debian. The last of the etch upgrades stories involves Sofcatal 's servers. The box was running on a CentOS 4.4, which was moved away into a subdir just after booting Debian-Installer, and then lobotomised so it would run as a Linux-VServer under a new Debian etch install. I'll probably write more details about it soon though, as it could be a maybe less scary alternative to Guillem's debtakeover. Yay for etch!

Kate and I have been thinking for a while now about maybe adopting cats once we were settled into our new apartment. Two weekends ago, we went to a local cat shelter and adopted a pair of kittens. Photos below; the brown one is a female named Diana, and the orangish one is a male named Mars.





Not only are they INCREDIBLY CUTE, but they're very sweet-tempered and affectionate, at least when they can spare the time from chasing cat toys and play-fighting with each other. There's really nothing like having a pair of purring cats curled up on your lap together.

Kittens make everything better. :-)

(PS: more kitty pictures are available here)

This is now established as my german annual pilgrimage. Every year since 2002, I migrate to G ttingen for 3 days to attend the SambaXP conference, the world conference of the users and developers of Samba. Halfway between a very classical conference (high-class hotel, nice conference rooms, drinks and food at will...and expensive fee) and a "geeky-style" conference (the whole Samba Team usually attends it as well as many users and developers), it is now established as the annual reference for people involved in Samba use and development. After an always interesting tutorial (this year, as often by Jerry Carter, Samba3 release manager) about making samba friendly to administrate to....Windows admins, the track continued with talks drawing the future of samba development. This year, I was however missing No l K the who could not attend, so the Debian crowd here is pretty small (but many Debian users and admins are around). I however could have interesting talks with Jelmer Vernooij (mostly involved in Samba4 development...and also in our NM queue). I also used some time to try cleaning out the Debian BTS for samba bugs, using the opportunity to show old bugs to upstream developers. I also could visit Alex and Meike who live not that far, which was a real pleasure, including the Real Swabian Sp tzle that make swabian women so strong and powerful. The conference will end up today. It will have been too short, as usual and I will feel like I'm running away on the A7 up to Hannover to catch the plane and come back home....and, as usual, I'll promise myself to come back next year and practice my German, which sucks. Tomorrow, leaving to Rome for a long week-end with Elizabeth. No laptop, no mail. Just enjoy the city. Gut!

Yesterday I did my first uploads of my own packages to Debian! Yay :) Though nothing spectacular: fai-kernels to unstable, build against 2.6.20 and fixing a wishlist bug for adding a driver with is in the normal kernels and fai-kernels to stable-proposed-updates fixing the same wishlist bug.

Then I decided to do a full backup over night and reinstall my laptop with FAI in the morning, to see if all my (systems) configuration is now done correctly and automatically. Well, now it is :-) And as I kept my home-dir, everything looks (and is) the same as yesterday. Yay!

With one exception: I threw editing files for network configuration on my laptop away and switched to network-manager(-gnome). After reading /usr/share/doc/network-manager/README.Debian I added myself to the netdev group (I hope this is done automatically if doing a desktop install with d-i) and now it works very nicely, also with WPA :)

Right, since two and a half weeks I switched away from ion3. To gnome :) So far I like it, but let's see what I run in half a year...

Now I hope I'll get that real cheap (oldie but goldie) ISDN mobile phone on ebay, so I can have some fun with asterisk soonish. I'm getting this new ISDN phone so that I can keep my old landline setup intact - for the time when I set up asterisk and after that.

Long time no blog. Well, a long time for me -- it's been more than a week, which is pretty unusual. To be fair, I've been blogging on my Wikitravel Extra blog, since we were spending our week in Puerto Rico. We had a great time while we were there. Our last few days we spent in Luquillo, a colonial town turned beach resort northwest of Fajardo. It has a great beach and some of the best food shacks in PR, so we managed to really enjoy ourselves. We also took some time hiking in El Yunque National Forest, the only tropical rainforest in the US national forest system. (I've actually visited the temperate rainforest, the Quinault, in the Olympic National Forest). Probably my big regret is not getting to Culebra, which according to Biella and other sources is perhaps the highpoint of Puerto Rico. We just didn't manage it, but there's something to be said for saving good things for the next visit. tags: wikitravel travel puerto rico get-together07

Visit from my parents My mom and dad came for a week-long visit last night (less than 24 hours after we landed on the plane from San Juan. They're going to visit our new house and spend some time with Amita June. They're going to get to see some of the nicest weather in Montreal. The early spring is really the greatest time to be here. tags: amitajune mom dad montreal parents visit

BarCampMontreal2 We're coming up fast on BarCampMontreal2, the second BarCamp in the Montreal area. We've had two DemoCamps this year, which have been great for getting people interested in the *Camp idea. I think BarCampMontreal2 is going to be a real hoot. The event is going to happen Saturday, April 28th (that's 8 Flor al to you and me) from 9:30AM until the early evening. I'll be presenting and so will Maj. The list of registrants (BarCampMontreal2Registrants) reads like a Who's Who of the Montreal tech scene, including some more Debian and Ubuntu people this time around. Good deal! This will be the first BarCampMontreal at the SAT, on 1195 blvd. St.-Laurent just south of St. Catherine. The venue is huge, has great A-V equipment, and is definitely funky. Hopefully the bar will be open at some point. tags: barcamp barcampmontreal barcampmontreal2 sat event

Speaking of Camps I've been working pretty hard on our RecentChangesCamp event here in Montreal, RoCoCoCamp. It will be a 3-day event, 18-20 May 2007, hosted by the international wiki community but open to all people interested in creativity, collaboration, and building communities. Our list of RoCoCoCamp participants is getting quite long, and it looks like our RoCoCoCamp sponsors are going to help us cover the costs of the event. We've still got some people on our RoCoCoCamp invitation list who haven't gotten an invite; I've got some work to do there. I'm excited, though, that so many people are going to be there. We're going to have the project leads for the most important PHP wiki packages -- MediaWiki, PmWiki, PHPwiki and TikiWiki. It'd be great if something came out of that! And Earle Martin of OpenGuides will be there. We're trying to work out an RDF interchange format for our wikis, so I hope to work on that issue, too. Hopefully we'll find the sponsorship to make up our budget shortfall -- there are some Open Source developers and students that we'd like to give travel microgrants to. But I'm optimistic that more companies like Google, Atlassian, AboutUs, SolSeed Movement, Keiki, Wikia, and wikiHow will come through for us over the next few weeks. All in all I think it's going to be a really cool camp. tags: recentchangescamp rocococamp rocococamp07

I have just installed a machine running CentOS 5 as a Xen server. I installed a full GUI environment on the dom0 so that GUI tools can be used for managing the virtual servers.

The first problem I had was selecting the "Installation source", it's described in the error message as an "Invalid PV media address" when you get it wrong which caused me a little confusion when installing it at 10PM. Then I had a few problems getting the syntax of a nfs://1.2.3.4:/directory URL correct. But these were trivial annoyances. It was a little annoying that my attempts to use a "file://" URL were rejected, I had hoped that it would just run exportfs to make the NFS export from the local machine (much faster than using an NFS server over the network which is what the current setup will lead people to do).

The first true deficiency I found with the tools is that it provides no way of creating filesystems on block devices. The process of allocating a block device or file from the Xen configuration tool is merely assigning a virtual block device to the Xen image - and only one such virtual block device is permitted. Then the CentOS 5 installation instance that runs under Xen will have to partition the disk (it doesn't support installing directly to an unpartitioned disk) which will make things painful when it comes time to resize the filesystems.

When running Debian Xen servers I do everything manually. A typical Debian Xen instance that I run will have a virtual block device /dev/hda for the root FS, /dev/hdb for swap, and /dev/hdc for /home. Then if I want to resize them I merely stop the Xen instance, run "e2fsck -f" on the filesystem followed by "resize2fs" and the LVM command "lvresize" (in the appropriate order depending on whether I am extending or reducing the filesystem).

Xen also supports creating a virtual partitioned disk. This means I could have /dev/lvm/xenroot, and /dev/lvm/xenswap, and /dev/lvm/xenhome appear in the domU as /dev/hda1, /dev/hda2, and /dev/hda3. This means that I could have a single virtual disk that allows the partitions to be independently resized when the domU in question is not running. I have not tried using this feature as it doesn't suit my usage patterns. But it's interesting and unfortunate that the GUI tools which are part of CentOS don't support it.

When I finally got to run the install process it had a virtual graphics environment (which is good) but unfortunately it suffered badly from the two-mouse-cursor problem with different accellerations used for both cursors so the difference in position of the two cursors varied in different parts of the screen. This was rather surprising as the dom0 had a default GNOME install.

Open Usability has a poll for the next default KDE theme or so. Oxygene or so.However it lacks options... the first real question "which icon [...] showing the menu with all applications" is lacking the "None is appropriate" option.The first icon has some windows on it. I don't want to configure windows. The second has a package on it, package manager. Next is a diary/notebook and a text editor. Looking glasses, the KDE logo, a computer and a help icon. I mean, there is nothing at all looking like an "applications menu" in there.Other questions don't fit into the usability category too much - for example, there is a poll about the 'back' button in the web browser. And there are like three regular left pointing arrows and one which is a reload turned the other way. I'd pick the other three; any of them is fine. But I have to pick one...Sometimes options are just stupid (e.g. offering a phone icon for email), and sometimes none is convincing (the chat icons, I actually find the 'small human figure' icons quite appropriate, but there was no such icon offered).Speaking of icons - I'd really appreciate some new Debian artwork. Our web site is looking like it's from the 90s. If it werent for '2007' dates occurring on the first page, it would look like it hadn't been touched since then. Ubuntu and Fedora have really nice pages (layout wise, I'm not talking about the contents which I didn't look at). Gentoo is as miserable as ours. OpenSuSE doesn't do language negotiation and looks somewhat odd. Probably too 'wikiesque'. FreeBSD just got a facelift last year. The artwork looks like 2003 style to me, and that the page has a 'monospace fonts' feeling might even be intentional. I certainly don't want the Debian website to look like a "web 2.0 beta" application, but some modern 'serious' design would be nice to have.

I asked if anyone had seen the Barclays PINsentry keypad before... Kris Marsh wrote that:

"it looks a lot like the way secureid cards work. In which case, it won't physically connect to your PC, would provide you with proper two factor (password + token) and would definitely be a Good Thing(tm). Not only then, would a phisher have to take your password, but they'd have to steal your actual card and PINsentry device to get access to your online account. Thus pushing the phishing emphasis elsewhere (different banks? phone scamming?). I guess time will tell if they manage to mess it up to make it only work on Windows somehow. :-)"

Adam Bower opined:

"The Barclays devices just look like a challenge response system. Someone I know has something similar for a bank account which when you login the website presents you with a 4 digit number. You then type that number into the pad and then enter a pin and it presents another number that you enter onto the webpage and the online banking lets you in (along with a username and password). I should imagine that these new devices won't make any difference to people running Linux."

Neil McGovern noted:

"It seems that they're external devices for generating OTPs from C+P cards, so won't affect compatability."

Roger Gammans commented:

"Barclay use GEM plus usb smart card readers with their business internet banking. IIRC, this requires windows and IE so that the activeX controls on the page can talk to the reader. Having said that one desciription of the new device I heard sounded like it was a standard alone device with a display. You put your card into it and push a button and then it produces a code number which you copy onto the web page. But I haven't seen one yet - and the media are good at getting the wrong end of the stick."

So, let's wait and see.

In a previous post, I claimed that SELinux uses a kind of object-oriented approach, and that this has several advantages over path name based access.Since SELinux policy isn't actually a 'program', the term is somewhat surprising. It's just one fragement of "object oriented programming" that is available in SELinux, and actually a rather simple fragment. Also it's not how it's evaluated; but the OOP 'design pattern' of 'classes' is somewhat present in the SELinux reference policy. The syntax is kind of twisted, too.Let me give you a simple example policy fragment:

type mylog_t;
logging_log_file(mylog_t)

This fragment defines a new type, and 'inherits' from the 'log_file' class. (you can think of "logging_log_file" as com.tresys.oss.refpolicy.system.logging.log_file if you are a Java freak)The logging_log_file 'class' (which technically is a M4 macro, and maps to the SELinux 'typeattribute' 'logfile' - this would be called an abstract class in other programming languages) in turn will make mylog_t also be a "file_type" type attribute.So above line means that the new mylog_t type will 'inherit' certain access rules. Namely those defined via the logfile type attribute or file_type.This means that I can write policy to grant access on "any file" (e.g. for security scanners such as 'samhain' or the SELinux relabeling utilities, backup application, etc.) or just to any log files (e.g. for logrotate). Independend of where they live or who wrote the policy for them.So if I write policy for a custom application, add mylog_t for files living somewhere in /home/myapp/logs, I don't need to modify the logrotate policy, because that policy contains:

logging_manage_all_logs(logrotate_t)

(You can again think of this as logrotate being derived from a "log file manager" class, though it's implemented differently this time. Also note that multiple inheritance is no problem in SELinux policy)Macro names in the reference policy usually start with a namespace prefix. In this example, it's logging_. Since it uses M4 for processing the files, the syntax is largely determined by what is easy to use in M4.

Sune, my solution is to simply keep all my data on the laptop encrypted (via dm-crypt). My master key has a really loooooong passphrase (because I need it only for keysigning), and I use subkeys on a smartcard for daily work.

Dear Lazyweb Now it is my turn to ask you for help. How to manage your private keys (ssh, gpg, ..) securely when on the move with a laptop ? Storing the stuff in your homedir makes it kind of vulnerable if you lose your laptop (get stolen).
Storing your keys on a usb stick has the same problems if it gets stolen. A idea could be to store half the key on a usb stick and the other half of the key on your laptop.
Another idea colud be to encrypt your private keys on the laptop with another key stored on a usb stick. (Or the other way around) Other ideas? And is there already some well thought software written to do this ?
Or is the best advice to just to keep your usb stick really really close and hope for the best. /Sune

As grml supports booting from usb devices (harddisk installation via grml2hd as well as booting from usb pens via grml2usb) and I helped many people at debugging booting problems I think I stumbled upon every existing pitfall. There are several situations where booting might fail. So here we go with a summary of the most common pitfalls and possible solutions:

1. The Bootsplash is displayed, the kernel loads but you very soon get a:

ran out of input data
System halted

Reason: everything OK, except for the filesystem used on your usb device. So instead of fat16 you use for example fat32. Fix: use the appropriate filesystem (fat16 for usb pens usually).
2. When trying to boot from USB you get something like:

Invalid operating system

Possible reason: the partition layout is not ok. Very probably there’s no primary partition or none has the flag ‘bootable’ set. (Read on for further details.)
3. When trying to boot from USB you get something like:

No operating system found.

Possible reason: you forgot to set the boot-flag on the partition. Or you did not install an operating system at all.
4. When trying to set up the partition(s) on the USB device cfdisk reports something like:

FATAL ERROR: Bad primary partition 0: Partition ends in the final partial cylinder

Reason: the partition layout is not ok. Either use fdisk (requires detailed knowledge about partition setup!) or better: use a fronted of libparted, like gparted. gparted does an excellent job at setting up an appropriate partition layout for booting from USB (read on for details about the correct setup). As long as cfdisk has problems with the layout - it will exit on errors - your usb pen very probably does not have a valid partition setup for booting. Please notice that fdisk very often uses defaults which are not OK, whereas gparted uses the appropriate heads, sectors/track and cylinders settings. So if you really want to use fdisk for setting up the appropriate partition layout you might have to enter the ‘extra functionality (experts only)’ menu of fdisk.
5. The system never displays the bootsplash of the usb device at all? Checklist:
• does your system support booting from USB at all? Check settings in BIOS.
• do you use the correct USB mode in BIOS? Check BIOS again, usually you want to use USB-HDD mode. Not possible? See USB-ZIP mode.
• is "booting from USB" in the appropriate order of the booting sequence? Check the "boot"-section in your BIOS.
• is the bootable flag set on the boot-partition? Check for example with cfdisk.
• is the partition used for booting the first partition and a primary one on your device? Check with cfdisk again.
• is the partition layout ok? The first partition (the one used for booting) has to start at cylinder 1/sector 63, otherwise booting will fail on most (all?) x86 systems. Check with ‘cfdisk -P s /dev/..’ or ‘fdisk -l -u /dev/…’. Do *not* trust the output of ‘fdisk -l /dev/…’. Really.
6. syslinux does not work on your system (b0rken BIOS for example)? Possible solution: use grub instead.
7. Kernel boots but fails to find the root filesystem with something like:

kernel-panic: unable to mount root-fs...

Yes? Then the root= argument in your kernel commandline (specified in the bootloader, usually lilo, grub or isolinux/syslinux) is pointing to the wrong device. Solution: adjust the root=-option in your bootmanager’s configuration. Tip: use root=UUID instead of root=/dev/[hs]d…
8. All of the above tips don’t work? Maybe your USB pen is even larger than 1GB?
Possible reason: Some BIOSes offer different modes for USB booting. The proper mode to boot a USB stick is USB-HDD. If that doesn’t work or is not supported by your system, you need to format your USB-Stick as USB-ZIP. To do this, the syslinux source distribution contains an utility called mkdiskimage, which you can use to re-format your USB stick in USB-ZIP format. For more information refer to the USB-webpage in the grml-wiki and Bootable USB Key in the knoppix-wiki.

I mentioned the correct partition layout several times. Reminder: a first, primary partition with fat16 (as filesystem as well as partition’s system id!) with bootable-flag set. The partition should start behind MBR at 1st cylinder and 63rd sector (see www.ata-atapi.com/hiwmbr.htm and thestarman.pcministry.com/asm/mbr/index.html for more details about MBR). So how does a correct partition look like? Output in several formats as reference:

# fdisk -l -u /dev/sda
Disk /dev/sda: 1039 MB, 1039663104 bytes
255 heads, 63 sectors/track, 126 cylinders, total 2030592 sectors
Units = sectors of 1 * 512 = 512 bytes
   Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *          63     2024189     1012063+   6  FAT16
# fdisk -l /dev/sda
Disk /dev/sda: 1039 MB, 1039663104 bytes
255 heads, 63 sectors/track, 126 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
   Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *           1         126     1012063+   6  FAT16
# sfdisk -d /dev/sda
# partition table of /dev/sda
unit: sectors
/dev/sda1 : start=       63, size=  2024127, Id= 6, bootable
/dev/sda2 : start=        0, size=        0, Id= 0
/dev/sda3 : start=        0, size=        0, Id= 0
/dev/sda4 : start=        0, size=        0, Id= 0

Tip: if you have a working stick, store your partition layout using ’sfdisk -d /dev/sda > sfdisk.sda’ for later restore (via ’sfdisk /dev/sda < sfdisk.sda’). This is also very useful for cloning a working setup to other devices (though you might have to adjust cylinder/units later on). And of course you can use it as backup if you ran [sc]fdisk-commands on the wrong device.

I didn't intend to write (ok, rant...) on this topic again, but a few days ago, this "AppArmor FAQ", was posted to the Linux Kernel Mailing list. Again, this is a lot of 'marketing stuff', and doesn't have the facts quite right...Some quotes:

In the traditional UNIX model, files do have names but not labels, and applications only operate in terms of those names.

No. In the traditional UNIX model, filenames point to inodes, and the inodes contain data such as file modification dates and permissions. This is where SELinux stores the labels it uses for access control. In fact, the "unix owner" and "unix group" are pretty much the same thing as SELinux labels. And also work pretty much the same way.

Contrary to popular belief, AppArmor is *not* "Pathnames R Us", but rather "Use native abstractions to mediate stuff": when you mediate something, you should use the native syntax that users normally use to access the object.

Maybe the appropriate term would have been "naive abstractions"?And, no, security systems shouldn't be designed around what a user can easily grasp, because that might just not work... it should be designed around the way resources are handled and how you can successfully restrict access."Contrary to popular belief", SELinux *does* use path names. Actually in a very convenient way for the users. So I wouldn't claim SELinux is really harder to use than AppArmor because of its use of path names.The difference is that SELinux doesn't rely on the path names, but it still gives the user the possibility to use them. In fact, the only way I know to get a proplerly labeled filesystem is based on path names.If I'd for example keep my web stuff in /home/www, I can tell SELinux that the appropriate label is httpd_sys_content_t by doing

semanage fcontext -a -t httpd_sys_content_t /home/www
restorecon -R /home/www

In AppArmor, I'd need to modify the policy for several applications to achieve this, because of it's dependency on path names. SELinux also uses an abstraction. One that is very convenient for users actually. SELinux does access control on object classes. What I'm doing in above example is to put these files into the "Web site data files" class. So please stop scaring people of "labels". That is just the technical term for what is an "object class", a concept every developer will be familiar with. (SELinux policy development has a couple of OOP-like features, btw., for example it is possible to give an application access to 'all log files'.)There are, however, some true statements hidden in there:

We also acknowledge that pathname based access control requires a way to perform pathname matching in the kernel, and this comes at a cost higher than comparing object labels [...]

So by providing string matching in the kernel, AppArmor trades run-time performance to grant reduced administrative work. It is however not obvious how large the difference in "reduced administrative work" is between AppArmor testing the filename "run-time" compared to SELinux using filenames to relabel files "on demand" (or, with restorecond, even on creation by using inotify).What I still seriously dislike is the FUD spread by AppArmor people such as

Label-based security (exemplified by SELinux, and its predecessors in MLS systems) attaches security policy to the data. As the data flows through the system, the label sticks to the data, and so security policy with respect to this data stays intact. This is a good approach for ensuring secrecy, the kind of problem that intelligence agencies have.

Why should this only be useful to "intelligence agencies"? Some people live in countries with very strict privacy requirements, and we might want to use these techniques to lessen the risk of leaking data. In AppArmor, I can copy a file with private customer data to the web server directory, and it becomes readable by the web server. In SELinux, the file will still be unreadable by the web server. Does that really sound like "only useful to intelligence agencies" to you?Dear AppArmor people, please stop trying to invoke fear of the NSA, just to make people use AppArmor. That makes you look very untrustworthy, you know...The SELinux kernel code is part of the Linux kernel, AppArmor is not. So in theory, that code has been reviewed much better than yours, and is maybe even less likely to contain a "NSA backdoor" than yours. Changes to SELinux are openly discussed on a mailing list, and go through peer review there. They foolow a very strict coding style, which makes review easier; obfuscated code doesn't have a place there. It's not like we were running a binary blob from the NSA we can't have a look at.