Fladi.at

While working on Debian packages for the Mozilla Sync Server, I came across the task to provide a URL for uscan to identify new releases. Mozilla does only provide Mercurial tags for each new release in their repository. To be able to use those tags as pointers to the tarballs of the new releases I set up a simple redirector for sites like hg.mozilla.org.

It can be found at http://debian.fladi.at/hgredir and should be used like in this example for the repository at http://hg.mozilla.org/services/server-reg/:

http://debian.fladi.at/hgredir/hg.mozilla.org/services/server-reg/

The accompanying debian/watch file would look like this:

version=3
opts=filenamemangle=s/.*\/rpm-([\d\.]+)-\d+\.tar\.bz2/mozilla-syncreg-$1\.tar\.bz2/ \
http://debian.fladi.at/hgredir/hg.mozilla.org/services/server-reg/ \

http://hg.mozilla.org/services/server-reg/archive/rpm-([\d\.]+)-\d+\.tar\.bz2

Maybe this redirector could be useful to others so I will maintain it as an freely available service.

A  while ago I migrated my /home LVM volume to the new (experimental) btrfs in order to take advantage of snapshots for backup. Despite my overall satisfaction with btrfs in terms of usability and features, it turned out that there is one major issue with applications making excessive use of fsync(3). The symptom of this issue is a high latency to user-actions while data is being written to disk. The impact on my system was especially high with liferea, my news feed reader. It was completely unusable while fetching data or marking a batch of items as read.

After some investigation I found eatmydata, which basically replaces all calls to fsync(3) with it’s own implementation, which just returns without doing anything. On Debian, it can be installed directly from the archives:

aptitude install eatmydata

It offers a small binary which can be used to bootstrap other applications to use the variant of fsync(3) provided by eatmydata instead of glibc. This is how I use it right now to start liferea:

eatmydata -- liferea

There are of course drawbacks and risks of using eatmydata. The purpose of fsync(3) is to ensure that data is safley written to a disk before going on with the work-flow inside an application. Effectively discarding those calls to fsync(3) exposes an application to potential data-loss! As liferea does not handle data for which I depend on integrity, I can cope with the risk of losing it but I would never ever use it on critical applications!

On Sunday, August 22nd 2010 there will be a outage of the mailsystem from 13:00 to 17:00. The reason is the installation of a new SMTP system. I ‘am migrating from Courier-MTA to Exim4, ultimately bringing some new features to the mail system like Sieve, greylisting and two-stage-spamassassin-checks.

Downtime is intended to be kept at a minimum and retrieval of mails through IMAP/Webmail will be unaffected. Incoming and outgoing mails will be delayed though.

I wanted to upgrade the BIOS of my desktop at work which is a Dell OptiPlex 960. Dell provides some minor help on flashing a new BIOS version under GNU/Linux but as of today it’s outdated and unusable. Sadly they do not provide images for use with flashrom either, so one is stuck with their crappy .EXE files.

The OptiPlex 960 does no longer have a floppy drive (which is a good one … Floppy is dead) so I had to come up with another way to boot a FreeDOS environment where I could run the .EXE provided by Dell.

I’m running GRUB2 so I’ll use a method to automatically add images in the /boot/images/ folder to the boot-loader menu and run them.

I started by creating a suitable large file of let’s say 10MB which has to reside in a separate folder on the partition GRUB2 uses for boot, usually /boot/:
mkdir /boot/images/
dd if=/dev/zero of=/boot/images/freedos.img bs=1M count=10

Now the image need to be made accessible as a loopback block-device:
losetup -f /boot/images/freedos.img

If you have no other loopback devices active you should have the image set up as /dev/loop0.
Now we need to download some boot-strapping files for our new FreeDOS environment and extract them:
mkdir /tmp/freedos/
cd /tmp/freedos/
wget http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/1.0/pkgs/commandx.zip
wget http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/1.0/pkgs/kernels.zip
wget http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/1.0/pkgs/substx.zip
wget http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/1.0/pkgs/unstablx.zip
for ZIP in *.zip; do unzip $ZIP; done

Next we create the filesystem for our new boot image and populate it with a FreeDOS system:
mkdir /tmp/fs-root/
cp ./bin/command.com /tmp/fs-root/
cp ./bin/kernel.sys  /tmp/fs-root/
cp <path/to/bios/upgrade.EXE> /tmp/fs-root/

Call makebootfat to write the boot-straping sector and populate the image:
makebootfat -o /dev/loop0 -E 255 \
-1 /tmp/freedos/source/ukernel/boot/fat12.bin \
-2 /tmp/freedos/source/ukernel/boot/fat16.bin \
-3 /tmp/freedos/source/ukernel/boot/fat32lba.bin \
-m /usr/lib/syslinux/mbr.bin /tmp/fs-root/

Afterwards we can remove the loopback device:
losetup -d /dev/loop0

To boot the image you need the memdisk loader from syslinux present at /boot/ so it can load the image at boot time:
cp /usr/lib/syslinux/memdisk /boot/

That’s it, the image should be ready for action. We just need to configure GRUB2 to automatically detect images in /boot/images/. Just copy the file from my Subversion repository and place it in /etc/grub.d/ and run `update-grub2`.
This should output something like this:
Found memdisk: /memdisk
Found floppy image: /images/freedos.img

Now reboot your machine and select the “freedos” option in the GRUB2 selection. Wait for the C: prompt and start upgrading your BIOS by running the .EXE provided by Dell.

I have the need to work on some of my systems with my LDAP/Kerberos5 user while not being connected to any network. By now I have managed to get around this by using pam-ccreds and nss-db which would locally cache user credentials.

Now there’s a new approach to this whole situation: SSSD, a project introduced by Fedora.

It combines the functionality of pam-ccreds and nss-db while enhancing it with several features like multi-domain support (e.g. use several different LDAP sources for user authentication). A PAM and a NSS module ar provided while the main part of the configuration is done inside one single file: /etc/sssd/sssd.conf

My current configuration can be found as a Puppet template:  sssd.conf

The appropriate NSS configuration: nsswitch.conf

And the different PAM stage configurations, tailord for a Debian/Sid installation:

• common-account
• common-auth
• common-password
• common-session
• common-session-noninteractive

I have migrated all my systems to SSSD by now and it works like a charm, no more silly KRB5 timeouts when working offline.