Warum der Begriff “Craft-Beer” keine gute Bezeichnung für deutsches Bier ist

Geschrieben am 16. August 2014 in Bier, brauen von giggls || Kommentare deaktiviert

Eines gleich vorneweg, ich bin ein großer Freund der neuen Vielfalt in der Bierlandschaft und begeisterter Konsument kaltgehopfter Biere.

Mehr noch, ich braue solche Biere zusammen mit meinen Freunden sogar sebst.

Was mir jedoch nicht so recht gefällt ist die Bezeichnung “Craft-Beer”.

Einerseits, handelt es sich mal wieder um einen unnötigen Anglizismus und andererseits, passt seine ursprüngliche Bedeutung nicht so recht in die deutsche Brauereilandschaft.

Gemeint sind damit nämlich Brauereien, die sich in der Abgrenzung zum industriell hergestellten Bier als Brau-Handwerker verstehen. Eine solche Abgrenzung ist in den USA, wo es bis vor rund 20 Jahren ja fast ausschließlich ersteres gab, auch sinnvoll. Man muss schmunzelnd an den Spruch von Oscar Wilde denken: “I find American beer a bit like having sex in a canoe. It’s fucking close to water.”

In Deutschland ist das aber auch heute trotz Radeberger und Co. immer noch deutlich anders, auch wenn unsere Fernsehbiere auf dem besten Weg in Richtung Budweiser und Co. sind.

Zurück zur Bezeichnung “Craft-Beer”. Bei vermutlich 90% der deutschen Brauereien und mit Sicherheit bei 99% der Oberfränkischen handelt es sich nach der amerikanischen Definition um lupenreine Craft-Breweries.

Das Bier das man dort findet ist aber halt (von wenigen Ausnahmen abgesehen) kein (I)PA und auch nicht hopfengestopft.

Was machen wir jetzt?

Den oberfränkischen Brauereien ihr Handwerk abzusprechen wäre schlichtweg eine Frechheit! Im Gegenteil, die untergärigen Kellerbiere fränkischer Brauart sind meistens hervorragend.

Mein Vorschlag:
Wir begraben den Begriff “Craft-Beer” im deutschsprachigen Raum, denn das deutsche handwerklich gebraute Bier braucht sich nicht zu verstecken, auch wenn es sich meist nicht um kaltgehopftes Obergäriges handelt.

Lasst uns lieber von innovativen Brauereien sprechen, denn davon gibt es zum Glück wieder mehr :)

Das wartungsarme Fahrrad

Geschrieben am 23. Juni 2014 in Fahrrad/bicycle, Umwelt/Environment von giggls || Kommentare deaktiviert

Von Fahrrädern, die zwar technisch möglich sind, die man sich aber nicht kaufen kann

Vor nun fast mehr als 9 Jahren habe ich mein damaliges Fahrrad mit Shimano 21 Gang Kettenschaltung (einer Bauart, die es heute gar nicht mehr gibt) aufgrund schlechter Ganzjahrestauglichkeit ersetzt.

Der Nachfolger war ein Fahrrad mit einer sündhaft teuren Rohloff 14-Gang Nabenschaltung in der Hoffnung nun endlich mal ein wartungsarmes Fahrrad zu erwerben.

Letzteres war und ist für mich überaus wichtig, weil ich kein Auto besitze und das Fahrrad daher 24 Stunden am Tag, 7 Tage die Woche und 365 Tage im Jahr einfach funktionieren muss.

Die Entwicklung bei Kettenschaltungen hin zu immer mehr Gängen und noch weniger robusten Ritzeln mit mehr als 7 Kettenblättern hat meine Entscheidung für die Nabenschaltung ja eigentlich bestätigt, wären da nicht ein paar völlig blödsinnige Tatsachen, die die Rohloff Schaltung in letzter Konsequenz dann doch für wartungsarme Fahrräder untauglich erscheinen lassen.

Worum geht es?

Verbleibender Schwachpunkt bei meinem Rad ist die Kette und da gäbe es aus meiner Sicht zwei Lösungen:

  • Ersatz der Schaltungskette durch einen ungekapselten Riemenantrieb
  • Ersatz der Schaltungskette durch eine breite Kette und eine brauchbare kapselung

Beides wären gangbare Wege aber beide scheitern an unterschiedlichen Gründen. Technische Gründe sind das nicht und das beweist in meinen Augen, dass das Fahrrad selbst von den Fahrradherstellern immer noch nicht als alltagstaugliches Verkehrsmittel angesehen wird.

Die erste Lösung scheitert am Preis. Fahrräder mit Riemenantrieb aka Gates Carbon Drive erfordern leider Spezialrahmen und sind in Verbindung mit der ebenfalls sehr teuren Rohloff Nabenschaltung dann preislich aus meiner Sicht oberhalb der Schmerzgrenze.

Eine Nachrüstung an meinem Rad würde die Anschaffung eines neuen Rahmens bedeuten.

Die zweite Lösung ist das ärgerlichere Problem! Das wäre nämlich technisch preisgünstig ohne Spezialrahmen machbar, wird aber von den Teileherstellern nicht unterstützt. Vollverkleidungen für die Kette wie der Hebie Chainglider gibt es nämlich nur für Schaltungsketten und schlimmer noch, weder die Firma Rohloff noch die Hersteller der Kurbeln liefern breitere Ritzel, wie sie bei Verwendung einer breiteren Kette notwendig bzw. zumindest wünschenswert wären.

So habe ich mich also gerade eben wieder einmal darüber geärgert, dass ich am hinteren Ende der Spannmöglichkeit meiner Kette angelangt bin und nun eine neue wenig haltbare Schaltungskette kaufen muss, die ich eigentlich gar nicht mehr haben möchte.

Ich hoffe ich werde die Verfügbarkeit wartungsarmer Alltagsräder mit aktzeptablem Preis- Leistungsverhältnis noch erleben. An der Technik liegt das nämlich nicht. Vielleicht findet sich ja in den Weiten des Internets jemand mit einem ähnlichen Problem und einer genialen Lösung.

Am Schluß auch noch etwas positives! Mein Fahrrad verfügt über hydraulische Bremsen der Firma Magura. Diese haben meine Erwartungen bzgl. Wartungsarmut vollumfänglich erfüllt und sind aus meiner Sicht ihren vergleichsweise teuren Preis wert.

A Raspbian read-only root-fs HOWTO

Geschrieben am 13. März 2014 in Debian GNU/Linux, Linux, Raspberry Pi von giggls || Kommentare deaktiviert

In embedded applications it is often a requirement, that the device must be able to sustain a power cycle almost any time.

Unfortunately this is not something which modern operating systems (including GNU/Linux) like very much.

Fortunately in Linux there are workarounds. While there are specialized filesystems like f2f2, the most simple approach is still to just run the OS from a read-only root filesystem.

So here is the solution I made for my brewing hardware.

We bootup our fresh raspbian image install available at http://downloads.raspberrypi.org.

On the HDMI console expand the filesystem and setup i18n (german keyboard in my case).

All steps starting from here can now be done via ssh as well as the HDMI console.

  • Remove some stuff which is not needed or unsuitable for readonly operation:
  • apt-get remove --purge wolfram-engine triggerhappy
    apt-get remove --purge cron anacron logrotate dbus dphys-swapfile
    
  • Remove X-Server and related stuff:
  • apt-get remove --purge xserver-common lightdm
    insserv -r x11-common
    
  • auto-remove some X11 related libs
  • apt-get autoremove --purge
    
  • Install busybox syslog instead of rsyslog
  • The reason for doing this is because we do not want logfiles, but we want to be able to do some debugging (read logfiles). busybox-syslogd does not write logfiles but logs to a ring-buffer in memory which can be displayed using the logread command:

    apt-get install busybox-syslogd
    dpkg --purge rsyslog
    

The following steps are important, because we do not want any filesystem checks on our headless system at all!

  • Comment do_start in /etc/init.d/checkroot.sh
  • Comment do_start in /etc/init.d/checkfs.sh
  • ...
    case "$1" in
      start|"")
            #do_start
            ;;       
      restart|reload|force-reload)
            echo "Error: argument '$1' not supported" >&2
            exit 3
            ;;    
      stop)
            # No-op
            ;;     
      *)
            echo "Usage: checkfs.sh [start|stop]" >&2
            exit 3
            ;;    
    esac
    ...
    
  • Comment Operations in /etc/init.d/checkroot-bootclean.sh
  • ...
    case "$1" in
      start|"") 
            # Clean /tmp, /lib/init/rw, /run and /run/lock.  Remove the
            # .clean files to force initial cleaning.  This is intended
            # to
            # allow cleaning of directories masked by mounts while the
            # system was previously running, which would otherwise
            # prevent
            # them being cleaned.
            #rm -f /tmp/.clean /lib/init/rw/.clean /run/.clean /run/lock/.clean
    
            #clean_all
            exit $?   
            ;;
      restart|reload|force-reload)
            echo "Error: argument '$1' not supported" >&2
            exit 3
            ;;
      stop)   
            # No-op
            ;;
      *)
            echo "Usage: checkroot-bootclean.sh [start|stop]" >&2
            exit 3
            ;;
    esac
    ...
    
  • Comment swaponagain ‘swapfile’ in /etc/init.d/mountall.sh
  • Remove a couple of startup scripts:
  • insserv -r bootlogs
    insserv -r sudo
    insserv -r alsa-utils
    insserv -r console-setup
    insserv -r fake-hwclock 
    
  • Change /etc/fstab as follows:
  • proc              /proc           proc    defaults     0       0
    /dev/mmcblk0p1    /boot           vfat    defaults,ro  0       2
    /dev/mmcblk0p2    /               ext4    defaults,ro  0       1
    tmpfs             /tmp            tmpfs   defaults     0       0
    
  • append ro in /boot/cmdline.txt:
  • ...  elevator=deadline rootwait ro
    
  • Make dhclient write its leases file to /tmp instead of /var/lib/dhcp/:
  • rm -rf /var/lib/dhcp/
    ln -s /tmp /var/lib/dhcp
    

That’s it, have fun with your read-only Raspbian. As far as my brewing software is concerned, there is automated remount-rw/ro support included (see sample configfile).

Offener Port = Sicherheitslücke, ist das BSI wirklich so unfähig?

Geschrieben am 9. Januar 2014 in Internet, IT-Sicherheit von giggls || Kommentare deaktiviert

Soeben trudelt über die Abuse-Abteilung der Firma Hetzner eine Mail des Bundesamt für Sicherheit in der Informationstechnik (BSI) bei uns ein, dass es sich bei der von uns verwendeten IP-Adresse 78.47.12.48 um einen Router mit Sicherheitslücke durch eine “undokumentierte Konfigurationsschnittstelle” handeln würde.

Gemeint ist die Backdoor in Routern, über die Heise in den letzten Tagen mehrfach berichtet hatte.

Nun frage ich mich schon welcher Praktikant beim BSI hier wohl ein script verbrochen hat, dass diese Router finden soll.

Klar, bei 78.47.12.48 handelt es sich um einen Rechner, bei dem der Port 32764 offen ist. Jedem halbwegs in der Netzwerktechnik bewanderten Menschen sollte aber auch klar sein, dass die TCP/IP Protokollfamilie im Gegensatz zu ISO/OSI eben keine klare Trennung zwischen Dienst, Schnittstelle und Protokoll besitzt.

Prinzipiell kann ja jeder Dienst auf jedem Port laufen.

Im gegebenen Fall hat das BSI auf Port 32764 einen ssh-server gefunden und eben keine merkwürdige Backdoor.

Der manuelle Test mit telnet oder netcat hätte das auch bestätigt:


~/ > telnet 78.47.12.48 32764
Trying 78.47.12.48...
Connected to 78.47.12.48.
Escape character is '^]'.
SSH-2.0-OpenSSH_5.5p1 Debian-6+squeeze4
quit
Protocol mismatch.
Connection closed by foreign host.

Ich muss sagen, ich bin enttäuscht. Vom BSI hätte ich mehr erwartet als automatisierte Abuse Emails an alle Betreiber von Rechnern, bei denen auf Port 32764 ein Server läuft.

Letztlich hat dieser Mist nun nicht nur mir, sondern auch der Abuse-Abteilung der Firma Hetzner unnötige Arbeit gemacht, denn ich bin im Netz von Hetzner ganz sicher nicht der Einzige, bei dessen Server auf diesem Port ein Dienst antwortet.

Update: Wieder Erwarten habe ich eine Rückmeldung vom BSI erhalten! Danke dafür. In der Meldung, die vom BSI an Hetzner ging steht wörtlich folgendes:

CERT-Bund hat von heise Security eine Liste von IP-Adressen erhalten, unter denen am 07.01.2014 Konfigurationsschnittstellen betroffener Router öffentlich über das Internet erreichbar waren. Nachfolgend senden
wir Ihnen eine Liste betroffener IP-Adressen in Ihrem Netzbereich mit entsprechendem Zeitstempel (MEZ).

Wer die Scans durchgeführt hat ist daher völlig Unklar. Klar hingegen ist, dass offensichtlich nur auf offene Ports getestet wurde und nicht auf die backdoor. Nach wiederholtem Lesen der Email ist mir inzwischen ehrlich gesagt völlig unklar, weshalb Hetzner diese überhaupt weiltergeleitet hat.

A simple way to localize (latinize) an Openstreetmap style

Geschrieben am 12. September 2013 in FOSSGIS, Openstreetmap von giggls || 3 Kommentare

Based on a request on the german mailinglist back in july, I thought about how the perfect localization of the german mapnik style would look like and finaly implemented something which comes close. Unfortunately up till now I did not document it.

However Reading about a map in manx today, I came to the conclusion, that I really need to do this.

First of all I came up with the following assumptions (valid for all languages using latin script IMO):

  • always prefer mapped names over automated transliteration
  • prefer name:<yourlang> over any other name tags (name:de in my case)
  • prefer int_name over non-latin script
  • prefer name:en over non-latin script if int_name has not been specified
  • transliterate non-latin script as a last resort

So how has this been implemented?

I decided to do it inside the SQL-query. This way it is independent of the rendering Software. It will certainly work at least with mapnik, mapserver and geoserver. Even the proprietary ESRI rendering stuff should actually work :)

Basically any rendering system using a PostgreSQL backend can be easily adapted. Of course your database must provide all the required name columns.

So how would one enable rendering a latin name insead of just the generic name tag?

Assume your style uses something like this for rendering a street-name:

SELECT name
FROM planet_osm_line;

Now just replace this by the following:

SELECT get_localized_name(name,"name:de",int_name,"name:en") as name
FROM planet_osm_line;

Quite easy isn’t it?

Well, here comes the (slightly) more complicated stuff…

Of course PostgreSQL does not provide a get_localized_name function out of the box, we have to install it first. So here is how to do this in two steps:

The get_localized_name function has been implemented in PL/pgSQL and is available at http://svn.openstreetmap.org/applications/rendering/mapnik-german/views/get_localized_name.sql.

So first add this function to your database using the following command:
psql -f get_localized_name.sql <your_database>

Second add the transliterate function available at http://svn.openstreetmap.org/applications/rendering/mapnik-german/utf8translit/.

To compile and install it on GNU/Linux (sorry, I don’t care about Windows) do the following:

  • svn co http://svn.openstreetmap.org/applications/rendering/mapnik-german/utf8translit
  • Install the Server dev package (On Debian/Ubuntu this would be called postgresql-server-dev-x.y, postgresql-server-dev-9.2 in my case)
  • Install the libicu-dev package
  • compile and install calling make; make install
  • On Debian/Ubuntu you would be better off using dpkg-buildpackage and install the resulting package instead of using the make install procedure.

Now enable the function from the shared object using the following SQL command (from a postgresql admin account):

CREATE FUNCTION transliterate(text)RETURNS text
AS '$libdir/utf8translit', 'transliterate' LANGUAGE C STRICT;


Here is how to check if this works:
mydb=> select transliterate('Москва́');
transliterate
---------------
Moskvá
(1 row)

Well that’s it, I hope that this will be useful for some people.

Unfortunately this stuff has currently (at least) two problems:

  • Transliteration of Thai Language uses ISO 11940 instead of the RTGS system
  • Transliteration of japanese Kanji characters end up with a chinese transliteration (e.g. dōng jīng instead of Tōkyō for 東京)

If anybody has some suggestions on how to solve these please post them here!

Seit wann zensiert Heise On-Topic Kommentare ?

Geschrieben am 22. Juni 2013 in Netzpolitik, Politik/politics, web von giggls || Kommentare deaktiviert

Bisher habe ich immer große Stücke auf den Heise Verlag gehalten. Unter anderem weil Sie bis zu den obersten deutschen Gerichten für die Verlinkung und damit die freie Meinungsäußerung gestritten haben.

Seit heute bin ich mir da leider nicht mehr so sicher.

Was also ist passiert?

Seit vielen Jahren kann ich mir Kommentare auf News bei http://heise.de nicht verkneifen. Trotzdem bin ich beiliebe kein sogenannter Troll. Im Gegenteil, ein sehr großer Teil meiner Postings wird regelmäßig mit “grün” bewertet.

Soweit bis heute, denn offensichtlich hat Heise nun einen härteren Zensor als bisher beschäftigt. Dieser hat heute mein Posting von gestern inklusive aller Antworten (die mich wirklich interessiert hätten) entsorgt. Das ist das Erste mal überhaupt passiert, seit ich Kommentare bei Heise schreibe und ich tue das seit über 10 Jahren! Leider hört das Webinterface von Heise bei 1000 Kommentaren auf zu zählen. Man erkennt die Tendenz trotzdem: Ich bin nie negativ aufgefallen!

Um was geht es?

Heise veröffentlichte gestern einen Artikel mit dem Titel Ermittlungen im Online-Untergrund: Routine statt Neuland.

Daraufhin fiel mir eine Frage aus diesem Umfeld ein, die ich mir seit geraumer Zeit stelle. Es geht um die Plattform Silk Road, auf der anscheinend Online mit Drogen gehandelt wird.

Hier mein Kommentar im Worlaut:

Betreff: Apropos Drogen...
Was ist eigentlich von "Silk Road" (http://silkroadvb5piz3r.onion) zu
halten. Realer Shop oder fake?

Irgendwie kann ich das nicht so recht glauben, dass Leute mit
Bitcoin, dessen Geldfluss ja ziemlich offen ist wirklich Drogen
bestellen.

Sven

Das Einzige, was an diesem Kommentar IMO ansatzweise diskutabel wäre ist die Direkte Erwähnung der URL von Silk Road, aber auch die ist nicht wirklich geheim. Auch in der englischen Wikipedia ist sie zum Beispiel direkt verlinkt.

Leider hat sich Heise mir gegenüber bisher nicht geäußert, warum der Kommentar zensiert wurde. In der Mail, die ich erhalten habe, stand lediglich folgendes:

Guten Tag!
Ihr Beitrag im heise online Forum
"Ermittlungen im Online-Untergrund: Routine statt Neuland"
mit dem Titel
"Apropos Drogen..."
ist von einem Administrator gesperrt worden.

Ich habe den Beitrag nun ohne die URL von Silk Road nochmal bei heise gepostet und bin gespannt was passiert!

Den Inhalt der bisherigen Antworten hätte ich allerdings doch gerne gelesen :(

4 different Methods of 1-wire access on Raspberry Pi

Geschrieben am 29. März 2013 in Bier, brauen, FOSS, Raspberry Pi von giggls || Kommentare deaktiviert

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.

Method

pros

cons

notes

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.2.41
≥3.4.37
≥ 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

Geschrieben am 25. Januar 2013 in FOSSGIS, Openstreetmap, Politik/politics von giggls || 2 Kommentare

“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

Geschrieben am 16. Januar 2013 in Linux von giggls || Kommentare deaktiviert

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

The 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. I 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.

Sven

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

Geschrieben am 4. Dezember 2012 in FOSS, kerberos, Linux, Tipp/hint von giggls || 2 Kommentare

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!).

« Vorherige Beiträge