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.

Warum die “offenen Geodaten” von Baden-Württemberg eine Mogelpackung sind

“Baden-Württemberg gibt Geodaten frei”, so titelte beispielsweise Pro-Linux vor zwei Tagen. Schaut man sich das etwas genauer an, dann bleibt von dieser Aussage leider nur wenig übrig :(

Gut, die Maps4BW Rasterkarten stehen jetzt unter CC BY 3.0 zur Verfügung (leider derzeit nur in einem proprietären Format von ESRI[1]) und man darf daraus jetzt mit offizieller Erlaubnis durch abmalen von Rastergrafiken freie Vektordaten in (verglichen mit den Rohdaten) geringerer Qualität für OSM erzeugen!

Die eigentlichen Geodaten, aus denen diese Rastergrafiken erzeugt worden sind bleiben hingegen proprietär!

Wörtlich steht folgendes in den Nutzungsbedingungen des WMS:

Maps4BW liegen nicht offene Geobasisdaten zugrunde, deren Nutzung einer gesonderten Vereinbarung bedarf.

Die Rohdaten also, deren Erstellung zu einem Großteil vom Steuerzahler finanziert worden ist, stehen diesem also weiterhin nur unter einer teuren kommerziellen Lizenz zur Verfügung.

Sorry liebe Leute, aber das ist doch genau das worum es bei Opendata geht: Um die Freigabe von Rohdaten und eben nicht um irgendwelche hübsch aufbereiteten Rasterkarten! Bei Maps4BW handelt es sich zwar um eine recht brauchbare Webkarte, aber Anwendungen für die man Rohdaten benötigt (z.B. Routing oder Geocoding) kann man damit natürlich nicht machen.

Es wäre technisch erheblich einfacher gewesen Rohdaten zum download anzubieten statt daraus erzeugte Rasterkarten.

Es bleibt also festzustellen, dass die Freigabe von Geo-Rohdaten wohl auch unter einer Grün-Roten Regierung weiterhin nicht erwünscht ist.

Fazit: Opendata geht anders :(

[1] Der Firma ESRI, ist hier kein Vorwurf zu machen, deren Software kann die Daten problemlos auch in offenen Formaten liefern. Im Gegenteil ESRI verhält sich als Firma sogar ausgesprochen Opendata freundlich.

“git bisect” the perfect tool for knocking down bugs

The most annoying bugs are those of the “this did already work in the past” type.

Doing manual bisecting has also been an annoying task in the past. Especially when talking about Kernel bugs which will require frequent reboots.

Fortunately this step, while still somewhat time consuming, got much easier in recent times thanks to two very handy tools. One of them is git, the top-notch revision control system, the other one is virtualisation (virtualbox in my case).

So here is how I search the broken commit using theses tools:

Lets assume we have a problem which we discovered in kernel 3.7 and which did not appear in kernel 3.6.

First get a stable kernel tree if you do not already have one:

git clone git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git

Then issue the following 3 commands:

git bisect start
git bisect good v3.7
git bisect bad v3.6

Our source tree is now at a state where we must check if this kernel works or not. For this purpose I usually run Debian’s make-kpkg command which will build a debian package from a given kernel source.

Afterwards install this kernel in your virtual Linux system and reboot the VM.

Login to the VM and check if the bug is present there. If so issue a git bisect bad command, if not call git bisect good.

Repeat these two steps until git tells you exactly which commit did cause the problem.

Now all you need to do is mail the person responsible for the faulty commit :)


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://git.geggus.net/nss-catchall.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://github.com/sitaramc/gitolite.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!).

Betreibt Ingo Wellenreuther Astroturfing?

Mein letzter Blogpost brachte mein Entsetzen zum Ausdruck, dass die Karlsruhrer Piratenpartei unserem OB Kandidaten Ingo Wellenreuther sogar noch eine Plattform gibt, statt sich von vornherein gegen Ihn auszusprechen.
Dieses Thema ist zum Glück Geschichte, denn die Piratenpartei hat sich inzwischen für Frank Mentrupausgesprochen.

Daran, dass auch potenzielle Unterstützer von Herrn Wellenreuther den Beitrag lesen könnten hatte ich eigentlich gar nicht gedacht.

Als Kommentar zu meinem Blogbeitrag findet ich nun aber interessanterweise ein Beitrag, der aus dem Netzwerk der Stadt Karlsruhe stammt ( netz.karlsruhe.de) und allen Ernstes versucht Ingo Wellenreuthers Meinung zum Zugangserschwerungsgesetz zu relativieren.

Da mir die Freie Meinungsäußerung im Netz jedoch viel Wert ist habe ich den Beitrag nicht gelöscht!

Dass der Kommentator den Kandidaten mit Vornamen anspricht finde ich jedenfalls interessant, aber macht euch einfach selbst ein Bild…

OB-Wahl in Karlsruhe (Zensursula reloaded)

Solange ich lebe hatte unsere Stadt nur CDU Oberbürgermeister und das obwohl wir es bei der vergangenen Landtagswahl beinahe geschafft hätten einen Direktkandidaten der Grünen, statt von der CDU nach Stuttgart in den Landtag zu schicken und auch obwohl unsere Stadt als Hochburg der Piratenpartei gilt. Die Zeichen stehen also eigentlich ganz gut.

Wer mich in diesem Zusammenhang kolosal nervt ist nun erstaunlicherweise die Piratenpartei.

Als ich 2009 begonnen habe diesen Blog zu schreiben wurde gerade das unsägliche Zugangserschwerungsgesetz vom Bundestag beschlossen, dass erheblich zum späteren Erfolg der Piratenpartei beigetragen hat.

Neben Zensursula selbst gab es damals noch einen weiteren Bundestagsabgeordneten der CDU, der mir sehr negativ aufgefallen ist. Ingo Wellenreuther aus Karlsruhe.

Bis heute hat sich Wellenreuther nicht von seiner abstrusen Meinung zu diesem Thema verabschiedet!

Zur Erinnerung hier noch mal seine damalige Rede auf Youtube:

Genau dieser Herr möchte nun zum Oberbürgermeister von Karlsruhe gewählt werden, und was macht die Piratenpartei? Sie lädt den Herrn zu einer Sitzung ein, damit er sich vorstellen kann…

Leute echt, das geht gar nicht, dieser Mensch ist unwählbar!

Wen also sonst wählen?

In der Tat bleibt bei realistischer Betrachtung nur Frank Mentrup übrig und ja, nachdem ich kürzlich auf einer Veranstaltung mit ihm auf dem Rad in Durlach unterwegs war glaube ich, dass er ganz sicher der bessere Bürgermeister für unsere Stadt ist.

Befragt zum Thema Open Data wies er darauf hin, dass eine Karlsruher Firma Open Data Software für die Stadt München schreibt und dass er es schade findet, das Karlsruhe diese nicht ebenfalls einsetzt.

Warum die Piratenpartei vor diesem Hintergrund immer noch mit einem Ingo Wellenreuther flirtet werde ich wohl nie verstehen. Das was Ihr da tut wäre doch in etwa damit vergleichbar, dass die Grünen einen OB-Kandidaten, der erklärter Kernkraft Befürworter ist, zur eigenen Sitzung einladen würden, statt ihn abzulehnen.

Ich glaubte eigentlich bis jetzt, dass die Zensursula Debatte so eine Art Gründungsmythos der Piratenpartei in Deutschland gewesen wäre, ganz ähnlich der Anti-AKW Geschichte bei den Grünen.

Ofensichtlich habe ich mich getäuscht :(


My subjective perception of the impact of the OSM licence change

As most of my readers will probably know Openstreetmap is in progress to change it’s licence to a less restrictive one (at least from a data users perspective). Fortunately this will likely remain the only Openstreetmap licence change in my livetime well at least the only invasive one.

Today the so called redaction bot finished its work leaving the database in a state where most of the data origins from people which approved the new licence.

The Place where I live (Karlsruhe/Germany) has been one of the places to be fully mapped at a fairly early state of the project.
And ss with the rest of Germany most of the stuff originates from crowdsourcing work.

This turned out to be a huge advantage compared to places likeSydneywhere quite a lot of data has been imported from sources which did partly not agree with the licence change and which looks quite messy now.

While Karlsruhe also looks quite bad on theredaction bot view of OSM Inspector it does not look that bad if you check the details.

The red stuff mainly originates from one mapper doing quite a lot of public transport stuff, which lost some details now here and there, but most parts of the map are still quite intact.

But after all this is mostly what I would have expected, so here comes what I did not expect at all:

Back in 2009 I mapped two long-distance cycle tracks and last sommer we mapped another one while I was cycling with Christoph.

So this evening I decided to repair these relations and based on the fact that every single one of them is roughly 150km long I expected that this would be a lot of work.

This proved to be completely wrong. I did have to fix next to nothing on any of the three relations. Only one licence change related fix in all of them!

So instead of fixing bugs caused by OSM licence change I spend my evening writing silly blog postings like this one :)

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://github.com/sitaramc/gitolite.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.


Handy bash function for Unix GIS people :)

The usually so called shapefiles are typically not files but a couple of them with different extensions. Thus it is not very convenient to rename them.

Fortunately a Unix Shell is a very powerful tool so here comes shpmv which is a simple bash shell function. Just put it in your .bashrc. It works fine regardless if an extension (e.g. .shp) is given or not.

function shpmv() {
  if [ $# -ne 2 ]; then
    echo "shpmv: rename shapefiles"
    echo "usage: shpmv  "
  if ! [ -f $src.shp ]; then
    echo "$src.shp: file not found"   
  for f in $src.*; do
    mv $f $tgt.$ext

Über die Sinnlosigkeit von Radwegeoverlays

Gerade kam auf Twitterdie Nachricht vom OSM-Ticker, dass das neue Portal Radwanderland.de von Rheinland-Pfalz eine OSM-Karte verwendet.

An allen diesen Portalen stört mich eines ganz gewaltig und das muss echt mal gesagt werden, es sind diese sinnfreien und noch dazu oft falschen Overlays auf denen dann routing betrieben wird in einer Weise als ob das Radfahren auf allen anderen Wegen völlig unmöglich wäre!

Was man als Radfahrer wirlich bräuchte wäre verkehrsmittelgerechtes automatisches Routing unter Verwendung der Wegeklassen, wie sie bei Openstreetmap bereits zur Verfügung stehen. Das Ganze natürlich manuell korrigierbar und wenn man es perfekt machen möchte unter Berücksichtigung von Höhenmetern. Ich bin mir sicher das Dennis vom OSRM-Projekt hier gegen entsprechende Bezahlung etwas coden könnte.

Klar, nicht jeder Radler hat das selbe Ziel. Sogar ich selbst fahre bei Ausflugsfahrten andere Wege als ich das normalerweise tue, wenn ich das Fahrrad (wie meistens) dazu verwende um einfach von A nach B zu kommen.

Trotzdem wage ich nun mal die Prognose, dass ein solcher Overlay für keine Klasse der Radfahrer irgendwie auch nur ansatzweise sinnvoll ist. Dass Sie oft auch noch falsch sind ist dabei noch nicht mal das Schlimmste. Auch wenn die Fehler bisweilen hanebüchen sind.

Bei diesem neuen Portal musste ich nur ein wenig am Rhein entlang zoomen um einen Weg zu finden der direkt durchs Wasser geht (Sorry für den OSM Link, das Portal selbst hat leider keine Permalinkfunktion). Beim Radwegeportal von Baden-Württemberg findet sich natürlich ebenfalls ein solch sinnfreier Overlay und auch hier findet sich ein völlig hanebüchener Fehler direkt vor meiner Haustür :) Diese Treppe mit 529 Stufen wird einem allen ernstes als Radweg angeboten. Selbst für Mountainbiker eine Herausforderung, denn es gilt rund 100 Höhenmeter auf relativ kurzer Strecke zu überwinden.

Ich bin ja echt mal gespannt ob ich es noch erleben darf, dass die Macher solcher Portale und Erbauer von Radwegen endlich damit beginnen diejenigen, die das vermeintliche Zielpublikum darstellen, vorher zu fragen was sie denn gerne hätten.

Ich als nicht KFZ Besitzer, der täglich mit dem Rad unterwegs ist, wüsste jedenfalls schon sehr genau was für ein Portal ich mir für meine Routenplanung wünschen würde. Leider habe ich nicht genug Freizeit und vor allem know-how über Routing um das mal schnell selbst realisieren zu können.

Die Openstreetmap Datenbasis wäre jedenfalls dafür geeignet, so viel steht fest.