Category Archives: FOSS

4 different Methods of 1-wire access on Raspberry Pi

1-Wire is a bus-system commonly used for temperature sensors. However, there are many more 1-wire devices than just temperature sensors.owfs has been my Linux software of choice for accessing this bus for many years now. As you might have guessed I mainly use it for my brewing software.

While Raspberry Pi does not have a native 1-wire Interface it is still quite easy to connect 1-wire devices to your Pi.

AFAIK, there are 4 methods for connecting 1-wire devices to Raspberry Pi, here are they with their pros and cons.





1. w1-gpio kernel driver

  • most simple interface, just a pullup-resistor needed
  • driver broken in standard Raspbian Kernel
  • unsuitable for large bus lengths
  • owserver needs root privileges
to make this work on a standard raspbian kernel manually apply this patch.
The following stable kernels already include the fix:
≥ 3.0.70
≥ 3.8.4
≥ 3.9.0

University of Cambridge Computer Laboratory has a nice tutorial on the non-owfs related part.

2. I2C Busmaster (DS2482-X, DS2483)

  • simple 1-chip solution using I2C bus

  • optional galvanic insulation of 1-wire-bus using I2C isolator (e.g. ADUM1250)
  • SMD soldering required
I only tested the DS2483, which is a 3.3V/5V device.
If the owfs-version from Raspbian wheezy is used, the --no_PPM option is needed.
Schematics including the ADUM1250 I2C-isolator are available at my RaspIO Webpage.

3. DS2480B Busmaster on serial port


  • 3.3V/5V level shifter recommended
  • occupies the only serial port available.
  • SMD soldering required
4. DS9490R/DS2490 USB Busmaster

  • In case of DS9490R no soldering required
  • hardware is discontinued
  • occupies one of the two available USB ports
  • To workaround power supply problems an USB-hub might be required

I tend to recommend the I2C solution if more than just a temperature sensor with a short wire is required.

The perfect Gitolite-Server (with Kerberos Authentication and more)

Back in Juli I wrote a blog-post about how I set up a Gitolite-Server using Kerberos-Authentication.

As this post seems to be the only documentation on the web about how to do this, I got quite some feedback. In a recent email conversation I have been asked, if I know about a method, which would not require a patched Version of ssh.

Well, I did not know of one immediately, but now I have implemented one, which does not only make it unnecessary to patch sshd, but will also make the server a little bit more elegant to use from a users perspective :)

So here is a new Version of my Gitolite Server+Kerberos HOWTO

Login is now possible with your usual login name (username@servername), using gitolite@servername is obsolete and disabled by this setup.

Supported login-methods are:

  • password authentication (password is checked by whatever active Pluggable Authentication Module, pam_krb5 in my case)
  • authentication without password using an ssh public key
  • authentication without password using kerberos/gssapi

How to setup the system:

We once again start from a system which has a working Kerberos installation. We will however not need something like libnss-ldapd or libnss-sss. I assume that we are working as root, so just use sudo bash on Ubuntu and derivates.

  • Add a local user gitolite to your system with “*” in passwd field
  • Download and compile libnss-catchall [1]:
  • git clone git://
    cd libnss-catchall
    dpkg-buildpackage or make

  • Install the resulting libnss-catchall package or shared library:
  • dpkg -i ../libnss-catchall*.deb

  • create /etc/passwd_nss_catchall as follows:
  • grep gitolite /etc/passwd >/etc/passwd_nss_catchall

  • Change the passwd line in /etc/nsswitch.conf as follows:
  • passwd: compat catchall

  • Append the following lines to your sshd_config [2]:
  • PermitUserEnvironment yes
    Match User !root,*
    ForceCommand /usr/local/bin/gitolite_wrapper_script

  • Create the gitolite_wrapper_script as follows:
  • echo -e '#!/bin/bash\n\n/usr/local/bin/gitolite-shell $LOGNAME\n' >/usr/local/bin/gitolite_wrapper_script

  • su to user gitolite and clone the gitoline code into this users home directory:
  • git clone git:// gitolite.clone

  • Loosely follow the Installation instructions in README.txt which will boil down to the following commands [3]:

  • cd gitolite.clone
    mkdir -p $HOME/bin
    ./install -to $HOME/bin
    $HOME/bin/gitolite setup -a <adminid>

  • Make shure you have gitolite and gitolite-shell available in your PATH, I did this by adding symlinks to /usr/local/bin
  • That’s it! You should have a working gitolite server now

Public-key usage is a little bit different from the gitolite documentation. The lines in the file authorized_keys need to look like this:
environment="LOGNAME=your_username" ssh-rsa AAA

A command Option might be present, but is ignored because of the ForceCommand Option in sshd_config.

As with my old setup, Windows users will need to use plink.exe and point the environment variable GIT_SSH to this executable, openssh on Unix will work out of the box if gssapi authentication has been enabled.

[1] The whole stuff works because of libnss-catchall, a NSS (Name Service Switch) module written by me. It will always return a given single uid/gid/home combination for any user who managed to login somehow. This way we always end up being logged in as the gitolite user regardless of the username provided. The login username will however be present in the LOGNAME environment variable in case of gssapi or password authentication and must be set manually when using ssh public keys.
[2]If you have local users on your machine which should be able to use interactive logins adjust the “Match User” line. On a multi-purpose machine one should IMO consider using the chroot feature of ssh and a separate IP-address for gitolite anyway.
[3]The string I call <adminid> here is most likely the login-name (local part of the kerberos realm) of the one installing this stuff (you!).

Using gitolite with Kerberos Authentication

This article is obsolete now! There is a new article now which does describe a slightly different and better solution.

Once you have been succeeded in taming the three-headed beast called Kerberos, this powerful beast will prove handy for quite a lot of stuff!

I have been fiddling with Linux AD Integration and thus Kerberos at my workplace for quite some time now. Recently I needed to setup a gitolite server for software development, as more and more people tend to migrate from SVN to GIT now and using file based git repositories are a pain in the ass, especially when talking about file permissions and platform independent access.

So thinking about gitolite deployment, I wondered why the hell we should use ssh-keys for authentication if all our users (Windows or Linux) are already authenticated on their system using Kerberos anyway.

It turned out, that gitolite, openssh and an AD-integrated Linux machine (acting as gitolite server) will be 99% sufficient to get this stuff running. All I found on the web about this particular issue was this short discussion which does not offer a proper solution. The 1% missing to the solution I’m presenting here is a 3-line patch for openssh, but read on…

So here comes the gitolite+kerberos mini HOWTO:

  • Start from a kerberized Linux server system with a working kerberized ssh setup
  • Install a version of openssh with this patch (I also have packages build for debian squeeze, just drop me a line if you like to get them)
  • Download my gitolite_wrapper_script and copy it into /usr/local/bin/
  • Add the following two lines to your sshd_config:
  • Match User gitolite
    ForceCommand /usr/local/bin/gitolite_wrapper_script

  • Add a local (non AD) gitolite user without password to this system
    (I used /usr/share/gitolite as its home)
  • su to this user and clone the gitoline repository into this users home
    (git clone git:// gitolite.clone)
  • Follow the Installation instructions in README.txt, but use -a <adminid> instead of -pk for setup
  • Make shure you have gitolite and gitolite-shell available in your PATH, I did this by adding symlinks to /usr/local/bin
  • create a file .k5login in the homedirectory of the gitolite user and add the kerberos realm of your admin <adminid>@<REALM>
  • now run git clone gitolite@/<yourserver>:gitolite-admin.git from a client (already using kerberos authentication)
  • create a file k5login inside this clone and again add the kerberos realm of your admin <adminid>@<REALM>
  • commit and push this file
  • on the server replace the .k5login file with a symbolic link to .gitolite/k5login
  • You are now running a pure kerberos5 based gitolite server
  • The only thing which is different from an ordinary gitolite now is that we don’t manage ssh-keys but kerberos realms using the file k5login

Nice stuff you might think, but why the hell will we need to patch the secure shell daemon? The answer is simple: Once your login has succeeded the Unix shell running with gitolite userid does not know about the kerberos prinzipal used for authentication and there is no way (at least none, that I know of) to figure it out.
The username part of this prinzipal is however needed for gitolite. The only thing my patch does now is adding an environment variable called GSS_AUTH_KRB5_PRINC which can be evaluated by gitolite.
BTW, using the perl-script provided in the usenet discussion linked above was not an option because especially windows machines will not forward tickets by default and forwarding ticket is unnecessary for this purpose anyway.

As far as clients are concerned this has currently been tested using Linux git with openssh as well as Windows git and eclipse EGIT in conjunction with plink.exe provided by putty.


Backporting stuff to Debian stable (6.0.x squeeze)

Being a Debian User for a long time now, I can live quite well running Debian stable, because official backports and backports I build on my own, work around the problem of the long release cycles quite nicely.

This is arguably a little bit more work than updating to a recent Version of Ubuntu twice a year, but fortunately Debian does not tend to break on updates ;)

However, with Debian’s recent move to Multiarch support coming in the next major release (wheezy) building backports is currently not that easy as it used to be anymore.

Fortunately the Multiarch conversion howto gives some hints but naturally in a somewhat inverted way.

As I did not find a DE-multi-arch-HOWTO on the web, here is a 4-step mini HOWTO:

  1. Remove the following line from debian/rules (if present):
    DEB_HOST_MULTIARCH ?= $(shell dpkg-architecture -qDEB_HOST_MULTIARCH)
  2. Remove all occurrences of $(DEB_HOST_MULTIARCH) in debian/rules (only the pattern itself, keep the surrounding stuff)
  3. Replace occurrences of /*/ in all files debian/*.install by a single /
    This can be done using the following command:
    for i in debian/*.install; do sed -i -e 's;/\*/;/;g' $i; done
  4. Remove all the lines starting with Multi-Arch: in debian/control

Hopefully this will be useful to other people crawling the web.

Why I would never swap my FOOS OS to a proprietary one

At my workplace we started the policy that devices leaving the campus must be encrypted. For this reason I created a USB pen-drive based boot scenario for our Debian based Laptops which allows for a completely encrypted drive using LUKS a couple of years ago.

However, the encryption of the pen-drives themselves has been a problem ever since we started to follow this policy. Devices like Kingston DataTraveler Vault are Windows only and alternative solutions are rare.

Fortunately I recently discovered the Corsair Padlock devices which might be a solution for people who need platform independent encrypted USB storage.

When testing one of those devices I thought about securing my laptop kernels with such a thing, because this would remove or at least reduce the attack option (unencrypted kernel and initrd) left in my encrypted laptop drive setup.

Well this is where the problem started and where one oft the best software support in the world (this of the linux kernel) was again
able to solve it by just sending a few mails around the globe.

So here comes the whole story:

Quite a lot of BIOS are unable to boot from a so called Superfloppy device (no partition at all). For this reason I just added one to my Padlock2 device. Unfortunately this device could not be detected by Linux but worked fine in M$-Windows.

Sending an error report and some debug output to the usb-storage mailing-list revealed some strange bug (or just a tricky windows only workaround to enable hardware encryption?) in the Padlock device not showing the correct partition Information on the first read by the OS. Windows reads a bunch of stuff before looking at the
partition data so the problem does not arise there.

And here comes the real beauty of FOOS. I got a patch which worked around the problem just a couple of hours later from somebody a thousand kilometeres away (credits go to Alan Stern) and fortunately this patch will go into Linux 3.0.1.

Problem solved :)

This is not the first time something like this happened. I’m a 100% certain that something like this would never be possible in a closed source world which is all about workarounds in application Software because it is just impossible to send an email to the maintainer of a particular piece of OS code.


When running kernels you are on your own :(

A few days ago a local root exploit for the Linux Kernel has been posted and is available from all over the Internet now.

As usual in recent years the people just fixed it silently without mentioning in the commit log that this is a mayor security fix.

People like me which are still running kernels and which are actually the people reporting bugs in recent kernels are actually drawing the shortest straw here now :(

IMO it is a shame that there is still no Kernel available which fixes this flaw.

So what I will need to do now is trying to repair this by merging the fix from to…


The state of free bicycle trip planning tools

While the quality of openstreetmap has changed from unusable to what is now arguably the best map for bicycle trip planning in recent years (at least in germany) unfortunately free bicycle trip planning software has not.

The following table is probably not complete so please post your suggestions if you know about other tools.

I just tested FOSS and web based tools because commercial applications like TTQV tend to be running on windows only anyway.

So here is the current state of the tools I checked. What I would really like to see in the future is a like semi-automatic-routing feature but based on osm instead of google.

stand alone applications:


OSM tiles

Google maps/aerial images


Garmin maps

rectified images

Automatic routing

Manual route planning

semi-automatic routing


yes not allowed via hack no no no yes no


yes no no no yes no yes no

web based tools:


OSM tiles

Google maps/aerial images


Garmin maps

rectified images

Automatic routing

Manual route planning

semi-automatic routing

my hacked version yes no no no no yes no

yes no no no no no yes no

yes yes no no no Google API yes Google API

yes no no no no OSM no no

My current workflow ist still using about 2 or 3 of these tools because fortunately all of them are able to read/write GPX file format.

Currently I just set up a hack which will translate tile requests into WMS to allow using them in viking. This is basically the same setup (with a slightly modified mapfile) already in use at and available from Openstreetmap SVN.

An example tile URL for this kind of setup would be Please note that this data has not been approved for Openstreetmap use so please do not use these tiles for mapping.

Axel Springer Chef beleidigt uns :(

Axel Springer Vorstandschef Mathias Döpfner hat laut einem Bericht der taz öffentlich davon geredet, dass die sogenannte Gratiskultur im Internet die Pressefreiheit bedrohen würde. Was für ein unglaublicher Bockmist! Der Originaltext der Rede würde mich dann doch mal interessieren.

Ehrlich gesagt erwarte ich von diesem Verlag ja ohnehin nicht sehr viel, aber diese Aussage halte ich schlichtweg eine Beleidigung all derer die sich im Umfeld freier Internetprojekte engagieren. Sei es nun bei Openstreetmap, bei der Wikipedia oder im FOSS Umfeld.

Wenn die Gratiskultur so schlimm ist Herr Döpfner, warum setzen Sie denn dann auf ihren Servern freie Software ein. Da sollten Sie sich dann konsequenterweise auch widersetzen!

Überhaupt dieser Begriff: “Gratiskultur”

Offensichtlich soll suggeriert werden dass hier unlauterer Wettbewerb betrieben wird indem man etwas das eigentlich Geld kosten würde kostenlos hergibt. Das Gegenteil ist der Fall. Durch croudsourcing Effekte und weltweite Zusammenarbeit entstehen Dinge kostenlos die ohne die Hilfe des Internets eben nur durch den Einsatz von Geld möglich waren. Das kann man mögen oder nicht, unlauterer Wettbewerb ist es jedenfalls nicht.

Problems in Wikipedia that Openstreetmap does not have

Currently there are ongoing discussions in the german arm of the wikipedia about the relevance of certain articles. Some people think they should be deleted because they are not relevant enough to be mentioned in an encyclopedia.

While Openstreetmap has different and arguably harder to solve problems in other areas, we fortunately do not have them in this particular case.

As a matter of fact, we simply don’t even try to rate something as relevant.
If you want to put an object into our database, because it is relevant for you, then you are welcome to do so. The now infamous discussion on the german mailinglist about dog-excrement-bags comes to mind.

The only thing where I could imagine a simular discussion is one about particular objects to be rendered in the standard map style or not.

There is only one reason for objects to be deleted from our database. They are nonexistent on a particular place, ever were or ever will.

If they are non-existant anymore (e.g. stuff like disused railways) they have to be marked as such. Pretty black and white stuff as you can see.

Best of breed CAN device driver hitting mainline Linux Kernel 2.6.31

Starting with the upcoming 2.6.31 Linux Kernel (already available as 2.6.31-rc1) a functional version of the socketcan device driver found its way into mainline.

While socketcan itself has been in mainline for quite a while, there where no drivers for actual real-world hardware. This has now changed and I will therefore be able to run a Kernel which is one step closer to mainline.

Unfortunately however some kind of unioning filesystem is still missing.

Anyway, back to Controller–area network!

Since I wrote my own CAN device driver as a character device a couple of years ago I started thinking about a CAN-bus driver beeing implemented as a Network device. I wrote my own driver in the first place, because I needed concurrent access which is (needless to say) also possible with socketcan.

Fortunately two guys at Volkswagen Research finally started doing exactly this. Thank you to the socketcan people for providing such a nice piece of software!

So here is a mini HOWTO for getting it up and running.

What you need:

  • A GNU/Linux machine
  • A decent Kernel (2.6.31-rc1 or higher)
  • git and subversion
  • A supported CAN-bus card. I’m using one sold by EMS Wünsche, but a lot of other SJA1000 based cards may also work.
  • The simple userland utilities from svn://
  • A decent Version of iproute2 (not yet available in current GNU/Linux distributions at the time of writing)

How to get it up and running:

First of all compile and boot a Kernel where all CAN-related support is enabled either as a module or build into the Kernel.
Afterwords check out the userland utilities from subversion (svn checkout svn:// and compile them by just typing make.
Same goes for iproute2 (git clone git://; just type make as well. Copy all the resulting binaries to an appropriate place (e.g. /usr/local/bin). Do not use make install at least in iproute2 sourcetree, because this will replace your systems ip command.

Now all you need to do ist to enable you can0 interface by means of the following command:

ip link set can0 up txqueuelen 1000 type can bitrate 1000000

Use another value than 1000000 for different bitrates.

The txqueuelen might not be needed in your case if you don’t have peak traffic like I do.

OK, that`s it! You can now connect your bus to some device and use candump for watching your raw CAN pakets on the bus.

For integration into Debian GNU/Linux you may use something like the following in /etc/network/interfaces for automatically starting up your can0 device on system boot:

auto can0
iface can0 inet manual
# bitrate 1MBps
# increase TX queue length because of the pulsed nature of
# the traffic we generate
up /usr/local/bin/ip link set can0 up txqueuelen 1000 type can bitrate 1000000
down /sbin/ifconfig $IFACE down

See Documentation/networking/can.txt inside your Kernel tree for further documentation.