Planet NoName e.V.

26. July 2014

Moredreads Blog

19. July 2014

Moredreads Blog

14. July 2014


Zweiter Agenda Diplom 2014 Workshop

Nach dem erfolgreichen Start im Mai fand am vergangenen Wochenende der zweite Termin des „Agenda Diplom für Kinder“ der Stadt Mannheim im RaumZeitLabor statt. Unter dem Motto „Wir erwecken Roboter zum Leben“ haben wir erneut mit drei Gruppen von acht- bis zwölfjähriger Kinder Lego-Mindstorms-Roboter programmier, mit Aufgaben steigenden Schwierigkeitsgrades.













by rami at 14. July 2014 18:13:12

04. July 2014

Moredreads Blog

22. June 2014

Mero’s Blog

GPN14 GameJam - Crazy cat lady

tl:dr: We made a gamejam-game

At the GPN14 we (meaning me and Lea, with a bit of help by sECuRE) participated in the gamejam. It was the first time for us both, I did all the coding and Lea provided awesome graphics.

The result is a small minigame “crazy cat lady”, where you throw cats at peoples faces and - if you hit - scratch the shit out of them (by hammering the spacebar). The game mechanics are kind of limited, but the graphics are just epic, in my opinion:


Because sounds make every game 342% more awesome, we added a creative commons licensed background-music. We also wanted some cat-meowing and very angry pissed of hissing, which was more of a problem to come by. Our solution was to just wander about the GPN and asking random nerds to make cat sounds and recording them. That gave a pretty cool result, if you ask me.

On the technical side we used LÖVE, an open 2D game engine for lua, widely used in gamejams. I am pretty happy with this engine, it took about 3 hours to get most of the game-mechanics going, the rest was pretty much doing the detailed animations. It is definitely not the nicest or most efficient code, but for a gamejam it is a well suited language and engine.

If you want to try it (I don't think it is interesting for more than a few minutes, but definitely worth checking out), you should install LÖVE (most linux-distributions should have a package for that) and just download it, or check out the sourcecode.

We did not make first place, but that is okay, the game that won is a nice game and a deserved winner. We had a lot of fun and we are all pretty happy with the result as first-timers.

22. June 2014 13:45:28

13. June 2014

Moredreads Blog

06. June 2014

Moredreads Blog

15. May 2014

sECuREs Webseite

Horrible WiFi in hotels

Horrible WiFi in hotels

Geschrieben von: Michael am 15.05.2014

I’ve been travelling a bit to foreign countries lately and noticed that all of the places I’ve stayed at (low to medium price range hotels) have one thing in common: their WiFi is absolutely horrible.

Even worse, it seems like the more money you pay, the more horrible the WiFi gets. As an example, I’ve stayed at the NH city centre in Amsterdam recently. Curiously, swisscom runs the WiFi there — I didn’t even know they do more than access and mobile network in Switzerland. We booked a double room (so the hotel knew there are two people staying in the room), but swisscom only allows one login. I’ll repeat: one (1) login. In 2014. Where people travel with smartphones, tablets and notebooks. Per person. Even better: every time you lose connection, you need to re-acknowledge the terms of service. Of course this breaks automated updates of Android smartphones because they try to save battery and connect to the WiFi only sporadically.

Not only with swisscom it frequently happens that WiFi providers offer you laughably low volume limits like 100 MiB, which is less than what I have with my tiny international roaming package. Or 256 kbit/s (!) of bandwidth, which of course is no comparison to mobile data connections these days. Also, I’ve seen latencies as high as half a minute, effectively preventing any internet usage from working.

The horrible WiFi PDF

In order to not suffer in silence any more, but quickly express my frustration, I’ve created a form that I’ll carry with me when visiting a hotel. In case (hah!) their WiFi sucks, I can just leave them that note and hope they’ll eventually take action.

Feel free to do the same: store horrible-wifi.pdf (19 KiB) (Public Domain, please share) and leave it at every hotel with inacceptable WiFi.

by Michael Stapelberg at 15. May 2014 21:30:00

13. May 2014


Roboter erfolgreich zum Leben erweckt – Agenda Diplom 2014 im RaumZeitLabor startet mit großem Interesse

Nach dem großen Zuspruch beim Agenda Diplom für Kinder der Stadt Mannheim im letzten Jahr nimmt das RaumZeitLabor auch in diesem Jahr wieder mit vier Veranstaltungen unter dem Motto “Wir erwecken Lego-Roboter zum Leben – Deine ersten Schritte mit Lego Mindstorms EV3 Robotern” teil.

agenda19 agenda18

Der erste Termin am 10. Mai war im Nu ausgebucht, bei den restlichen Terminen sind augenblicklich nur noch wenige Plätze frei.

Pünktlich um 15 Uhr waren sowohl 12 Mädchen und Jungs, als auch eine stattliche Anzahl interessierter Eltern im RaumZeitLabor, um zu erfahren wie man Lego Roboter mit dem System Mindstorms EV3 zum Leben erwecken kann. Dabei ging es primär darum den programmierbaren Elementen beizubringen Abläufe in der richtigen Reihenfolge zu vollführen, damit eine selbst gestellte Aufgabe bewältigt werden konnte.


Es brauchte nur einen ganz kurze Einführung und schon sah man die Kinder, die sich in drei Teams zusammengefunden hatten, zusammen erste Schritte zur Aufgabenstellung zu diskutieren und diese dann auch sofort im Programmiersystem von Lego Mindstorms EV3 umzusetzen.

agenda16 agenda15 agenda14 agenda07 agenda06 agenda05

Aber nicht nur die Kids waren fasziniert von der Materie, nein, auch die mitgekommennen Eltern erhielten ihrerseits Einblicke in das was ihre Kinder, draußen, in einem anderen Raum, gerade machten und waren begeistert. Für Sie gab es nämlich einen kleinen Extra Workshop im angrenzenden Workshopraum des RaumZeitLabors. Sie wurden sowohl über die Möglichkeiten des Lego Systems informiert, als auch über das was man sonst noch so alles im RaumZeitLabor machen kann und der eine oder die andere fand sogar Angebote für sich selbst so ansprechend. So wird es wohl auch mit einigen der Eltern zu einem Wiedersehen kommen.

agenda04 agenda03

Nach etwa der Hälfte der Zeit konnten die Robotik-Neulinge schon erste fast komplette Bewegungsabläufe präsentieren. Weil das ganze Programmieren, Diskutieren und Ausprobieren anstrengend ist, hatten sich die zwölf  und natürlich auch die Eltern eine gemeinsame Pause verdient. Dazu gab es ein kleines gesundes Buffet mit Obst, Gemüse und Getränken an dem sich alle stärken konnten.

agenda10 agenda09 agenda08

Nach der Pause wurden dann die Teams gemischt, so dass auch wirklich dem Nachhaltigkeitsgedanken des Agenda Diploms Rechnung getragen wurde, indem die Acht- bis Zwölfjährigen so nicht nur den Umgang mit zukunftsweisenden Themen wie Robotik, sondern auch wichtige sogenannte Softskills wie Teamfähigkeit lernen konnten.

agenda13 agenda12 agenda02

Am Ende der Veranstaltung erhielten die Teilnehmer noch eine eigens im Kartendrucker angefertigte Teilnehmerkarte mit Chip und Magnetstreifen zum Andenken an das Agenda Diplom.


Wir sind sicher, dass wir einige der Kinder, aber auch manche Eltern in nächster Zeit wieder im RaumZeitLabor begrüßen dürfen. Darauf freuen wir uns ebenso wie auf die nächsten Teilnehmer der Veranstaltungen am 12. Juli (augebucht), 15. August und 20. September.

by zwetschgo at 13. May 2014 12:49:14

06. May 2014


Lötworkshop mit Mitch Altman

Mitch Altman (siehe hier, hier oder hier) wird am

Freitag, 16.5. von 15:00 bis ca 20:00 (siehe RZL Kalender)

einen kostenlosen Lötworkshop abhalten. Verschiedene LötKits sind vorhanden (siehe Liste). Auch blutige Lötanfänger sind herzlich willkommen!

Bitte meldet euch hier über die Kommentare an, da wir nur ca 10 Lötplätze bereithalten können. Wenn sich unerwartet viele Leute anmelden, werden wir sicher auch Lötkolbensharing machen können ;o)

Kommt zahlreich!

Wer es zu diesem Termin nicht schafft, kann sich auch auf der restlichen DE+UK Tour von Mitch umschauen. Vielleicht ist ja ein passender Termin dabei.
z.B. fährt Mitch nach dem Termin bei uns weiter zu den Kollegen vom shack in Stuttgart.

PS: Der Workshop wird in Englisch gehalten werden.


by TabascoEye at 06. May 2014 21:05:43

Mero’s Blog

Python-fnord of the day

This is an argument of believe, but I think this is highly irregular and unexpected behaviour of python:

a = [1, 2, 3, 4]
b = a
a = a + [5]
a = [1, 2, 3, 4]
b = a
a += [5]


[1, 2, 3, 4]
[1, 2, 3, 4, 5]

Call me crazy, but in my world, x += y should behave exactly the same as x = x + y and this is another example, why operator overloading can be abused in absolutely horrible ways.

Never mind, that there is actually python teaching material out there that teaches wrong things. That is, there are actually people out there who think they know python well enough to teach it, but don't know this. Though credit where credit is due, the official documentation mentions this behaviour.

06. May 2014 01:07:28

04. May 2014

Atsutane's blog


tl;dr: Dieser Eintrag bietet nichts wirklich lehrreiches, sondern ausschließlich meine persönliche Meinung zu Beobachtungen im Umgang mit Fehlern bei der Entwicklung von Software. Für Studenten: Die Modelle beschreibe ich hier so, wie ich sie aus der Praxis kenne. Ich habe im WS 12/13 eine Vorlesung zu der Thematik besucht und mein damaliger Professor schüttelt sicherlich den Kopf, denn dies ist nicht die akademische Art, die er uns lehrte.

Mit Heartbleed hat es ein Bug geschafft, die Aufmerksamkeit der Gesellschaft auf die Entwicklung von Software zu lenken. Im Radio wird darüber gesprochen und in den meisten Tageszeitungen steht, man sollte umgehend seine Passwörter ändern, dass es sinnvoller ist zu warten, bis seitens der Administration eine Aussage existiert, ob eine betroffene OpenSSL Version/Variante eingesetzt und ersetzt wurde, wird hier völlig unter den Tisch fallen gelassen.

Heartbleed ist ein Fehler in OpenSource Software, eines der weitverbreiteten Pro-OpenSource Argumente ist, dass jeder in den Source schauen kann. Vielen Leuten sind über die Folgen des Fehlers verärgert und dementsprechend stark wird dieses Argument nun dafür genutzt wie schlecht doch OS ist und das dies nicht geschehen wäre, wäre die Software von einem großen Unternehmen geschrieben worden. Verweist man dann auf Microsofts derzeitigen Zero Day Exploit bei Internet Explorer Version 6 aufwärts kassiert man einen bösen Blick.

Der Umstand, dass auch dieser Fehler in einer kommerziellen Software weitreichende Konsequenzen hat und Microsoft sogar für das erst vor kurzem aus der Wartung entfernte Windows XP nochmals ein Update veröffentlicht, zeigt aber: Wenn nur wenige Leute darauf schauen passieren Fehler und bleiben lange bestehen. Ob Software nun OpenSource Software ist oder das kommerzielle Produkt eines Unternehmens, dass den Kunden keinen Einblick in den Code gewährt macht keinen Unterschied, wenn sich nur wenige Personen die Quelltexte anschauen. Bei OpenSource hofft man einfach, dass es genug andere machen und bei kommerzieller Software eines Konzerns mit mehreren tausend Mitarbeitern sind es vielleicht auch nur fünf Entwickler, welche für das Produkt zuständig sind.

Zur Vermeidung von Fehlern in Software gibt es verschiedene Möglichkeiten, welche sich auch kombinieren lassen. Zum Beispiel testgetriebene Entwicklung, es werden zuerst die Tests geschrieben, anschließend Code der diese Tests besteht. Diese Art von Tests prüft aber letzten Endes auch nur, ob die Ergebnisse der Software die erwarteten sind. Je fein granulierter die Tests sind lässt sich so natürlich einiges an Fehlern vermeiden und aufspüren, es wird aber hautsächlich geprüft, ob die tatsächlichen Ergebnisse den erwarteten entsprechen. Wird hier vergessen einen fehlerhaften Use-Case zu prüfen kann es dennoch zu Fehlern kommen. Genau solch eine Verifikation ist ja das Problem des Heartbleed Bugs, es wurde nicht geprüft, ob die Parameter zusammenpassen.

Eine weitere technische Möglichkeit ist die Statische Code Analyse mittels entsprechender Software, diese klopft den Code nach gewissen Mustern ab und findet so zum Beispiel Speicherlecks, wenn Speicher allokiert, nur in der Funktion verwendet und nicht wieder frei gegeben wird.

Und dann eben auch das im Bereich der OpenSource Software weit verbreitete Modell: manuelle Code Reviews von Patches. Prinzipiell ist dies eigentlich auch eine statische Code Analyse, nur wird hier nicht immer wieder der gesamte Code betrachtet, sondern nur die vorgenommenen Änderungen. Dies geschieht durch eine oder mehrere Personen und erhöht dadurch die Chance, dass Fehler dadurch vermieden werden, dass die prüfende Person nicht den Code geschrieben hat und ihn daher anders liest. OpenSSL nutzt dieses Verfahren und auch der Linux Kernel wird so entwickelt, bei Unternehmen ist dies abhängig von Richtlinien des Unternehmens und der Abteilungen.

Das Pair Programming Modell ist ähnlich der Code Reviews, hier arbeiten zwei Entwickler zusammen, während ein Entwickler den Code schreibt schaut der andere mit auf den Schirm und weißt auf Fehler/Möglichkeiten zur Verbesserung hin. Klingt eigentlich ganz gut und lässt sich mitunter auch durchführen, nur wird dies in den meisten Unternehmen wahrscheinlich eher als eine Bremse bei der Produktion gesehen und im OpenSource Umfeld… Ich bezweifle einfach mal, dass wenn jemand aus Kanada den Bildschirm shared, um die Uhrzeit jemand aus Holland bei der Entwicklung zuschauen möchte.

Es gibt noch andere Möglichkeiten zur Vermeidung von Fehlern, aber Fehler passieren. Wenn ein Programm selbst fehlerfreien Code hat, gibt es immer noch viele Faktoren, die zu Fehlern führen können. Optimierungen durch Compiler, Updates von Betriebssystemen oder Fehler bei der Hardware. Es ist vor allem wichtig, wie auf Fehler reagiert wird. AVM hat Anfang des Jahres, umgehend für viele Modelle ihrer Router, auch jener welche seit Jahren nichtmehr verkauft werden Firmware Updates entwickelt und bereitgestellt. Von vielen anderen Herstellern liest man seit Monaten von offenen Ports und Netgear hat ein Problem ja auch nur versteckt. Bei Videospielen sieht man ähnliches, kleine Entwicklerstudios patchen ihre Spiele regelmäßig und versuchen Fehler zu vermeiden, bei großen Studios und Publishern kommt unfertige Software auf den Markt, wird teuer verkauft und bis auf das Marketing ist dann alles irrelevant, der Nachfolger kommt ja im nächsten Jahr.

04. May 2014 13:36:16

29. April 2014


Agenda Diplom 2014 – Es geht los!


Nach den tollen Erfahrungen beim letztjährigen Agenda Diplom haben wir uns entschlossen auch dieses Jahr wieder teilzunehmen.

Diesmal geht es um Robotik.

Lego kennt jeder, aber was ist wenn die Legosteine laufen lernen?
Das erfährt man bei unserem Workshop

Wir erwecken Lego-Roboter zum Leben – Deine ersten Schritte mit LEGO Mindstorms EV3 Robotern!

Wir haben ein kurzes Video gedreht in dem man sehen kann wie viel Spaß das macht.

Die Termine für unsere Veranstaltungen:

  • Samstag, 10.Mai 2014, 15 -18 Uhr
  • Samstag, 12. Juli 2014, 14 -17 Uhr
  • Freitag, 15. August 2014, 16-19 Uhr
  • Samstag, 20. September 2014, 13-16 Uhr

Obwohl das Programm noch gar nicht offiziell erschienen ist, sondern zunächst nur in der PDF Version auf der Seite der Stadt Mannheim einzusehen ist, haben wir schon einige Anmeldungen. Wir sind aber zuversichtlich jedem interessierten Kind einen Platz anbieten zu können, bei jedem Termin sind 12 teilnehmende Kinder vorgesehen.

Das Programm des Agenda Diploms erscheint in der gedruckten Version am 5. Mai, die PDF Version kann man hier einsehen.

Anmeldungen nehmen wir unter entgegen.

Wir freuen uns auf spannende und unterhaltsame Workshops.

by zwetschgo at 29. April 2014 09:22:58

10. April 2014

Mero’s Blog

Heartbleed: New certificates

Due to the Heartbleed vulnerability I had to recreate all TLS-keys of my server. Since CACert appears to be mostly dead (or dying at least), I am currently on the lookout for a new CA. In the meantime I switched to self-signed certificates for all my services.

The new fingerprints are:

Service SHA1-Fingerprint 8C:85:B1:9E:37:92:FE:C9:71:F6:0E:C6:9B:25:9C:CD:30:2B:D5:35 1B:DB:45:11:F3:EE:66:8D:3B:DF:63:B9:7C:D9:FC:26:A4:D1:E1:B8 65:51:16:25:1A:9E:50:B2:F7:D7:8A:2B:77:DE:DE:0C:02:3C:6C:ED
smtp ( 1F:E5:3F:9D:EE:B4:47:AE:2E:02:D8:2C:1E:2A:6C:FC:D6:62:99:F4
jabber ( 15:64:29:49:82:0E:8B:76:47:1A:19:5B:98:6F:E4:56:24:D9:69:07

This is of course useless in the general case, but if you already trust my gpg-key, you can use

curl | gpg

to get this post signed and verified.

10. April 2014 21:28:25

08. April 2014


BÄM!!!!! Subbahelden-Party

Holy Hacklaceshitstorm, Batman!

Bam! Zap! Pow!

Am 03.05.2014 trifft sich die >>Justice League of Boveristraße<< ab 19 Uhr in
der RZL-Cave! Let’s kick some ass!

Wir bitten euch, eure Capes davor nochmal alle in die Reinigung zu bringen,
die Augenbinden auf Mottenfraß zu überprüfen und eure Laserkanonen,
Schwerter und Schilde auf den neusten Stand zu bringen!

Falls eure Kostüme über die lange Zeit zu klein geworden sind, ist das
natürlich auch kein Problem. Jeder, der ohne passendes Outfit mit uns die
Mächte des Bösen bekämpfen will, wird von uns verkleidet und geschminkt*!

Angemessene Snacks, wie Pizza, Spinat, Spider-Ham und HotDogs werden
natürlich davor besorgt! Es wäre sehr schön, wenn ihr bis zum 01.05.2014 im
supergeheimen Blog Bescheid gebt, ob und mit wie vielen Sidekicks ihr in
eurem Heromobil anreist! Diejenigen von euch, die übermenschliche
Fähigkeiten bei der Küchenarbeit besitzen, dürfen natürlich gerne noch
Knabbersachen mitbringen!

Möge die Macht mit euch sein!


* Angemessene Verkleidung ist notwendige Vorraussetzung für die
Teilnahme an der Party, Widerstand ist zwecklos, zu Risiken und
Nebenwirkungen fragen Sie Ministerium für Landwirtschaft und Superheldentum.

by Alexander Brock at 08. April 2014 19:20:58

30. March 2014


A Song of Cold and Hot Dishes — Feast of Thrones

A Song of Cold and Hot Dishes — Feast of Thrones

Wir werden am Montag, den 7. April, die erste Folge der vierten
Staffel mit einem opulenten Sechs-Gänge-Menü feiern.
Auf euch warten folgende Gerichte aus den Büchern:

  1. Fingerfish/Spinach-filled pastry
  2. Leek Soup
  3. Beef and Bacon Pie
  4. Feldsalat mit Wildschinken
  5. Veal with Peppersauce and Royal Peas
  6. Whitepot | Rice Pudding

Dazu werden authentische, flüssige Erfrischungen gereicht.

Das Festmahl beginnt um 19:30 Uhr.
Bitte meldet euch bis Freitag in den Kommentaren an, damit wir die Anzahl der
Portionen und den Unkostenbeitrag planen können.
don / mxf

by don at 30. March 2014 19:00:32

19. March 2014

runwhen: undefined reference to scan_uint

You’re compiling runwhen with a recent version of skalibs? You may encounter the following error:

Making compile/host/rw-match
./compile/host/rw-match.o: In function `main':
rw-match.c:(.text.startup+0x13e): undefined reference to `scan_uint'
collect2: error: ld returned 1 exit status

The following files were not made successfully:

With skalibs 1.4.2, runwhen won’t compile. The solution is pretty simple, but hard to find if you’re not reading a couple of mailing lists. scan_uint has been refactored to uint_scan in the recent release of skalibs. Just replace scan_uint to uint_scan in rw-match.c and everything compiles nicely.

Thanks a lot to the guys from for pointing me to the solution.

19. March 2014 21:14:00

15. March 2014

sECuREs Webseite



cgit ist ein schnelles und gut-aussehendes Webinterface für git, welches in C geschrieben ist. Im Vergleich zu gitweb, trac oder anderen Interfaces ist es mindestens doppelt so schnell und (meiner Meinung nach) um Längen komfortabler.

by Michael Stapelberg at 15. March 2014 17:14:55

07. March 2014


Ludum Dare 29 im RaumZeitLabor

Am Wochenende vom 25. – 28. April 2014 findet zum 29. Mal der internationale Gamejam “ludum dare” statt. Um 2 Uhr in der Nacht von Freitag auf Samstag fällt der Startschuss, alleine in 48 oder als Team in 72 Stunden ein Spiel zu einem vorgegebenen Thema zu programmieren.

Wer keine Lust hat, in Einsamkeit zu programmieren oder schon immer mal jemandem beim Spiele programmieren zuschauen wollte, ist eingeladen, im RaumZeitLabor vorbeizukommen.

by silsha at 07. March 2014 23:38:33

01. March 2014


Das RaumZeitLabor trauert

Das RaumZeitLabor trauert.

Wir bedanken uns für euer Mitgefühl. Die Todesanzeige zum Download gibt es hier: Hacklace Todesanzeige

by fnord at 01. March 2014 22:39:38

xeens Blog

Power it off harder

Magic Hardware Fix Howto:

  • power off device
  • remove battery
  • press power button multiple times. Be creative and create a button press symphony worthy of your hardware.
  • reboot and hope for the best.

Background Story you don’t actually care about

I’ve encountered two situations where this helped, where a reboot or even removing the battery and power cable were not enough. Please share this hint because it is not something generally shared among nerds, or only as a joke reference to The IT Crowd.

One was a laptop which came into contact with the river Rhine and didn’t boot properly anymore (or not at all, I can’t remember exactly). The other was my laptop’s Ethernet card which happily created GBit/s links, but did not allow any packets to go through.

Considering I debugged the latter problem for at least three hours thinking I made a configuration error, I should probably try this sooner in the future.

I got the tip originally from Lenovo support, but I do not know how it actually works. My best guess is that there’s some residual charge in the capacitors which puts the hardware in an invalid state. If you have any insight here, please drop me a mail at stefan-blog at yrden.

01. March 2014 17:03:37

28. February 2014

Moredreads Blog

Posts Are Now Signed

My posts on this site are now signed. You can find a gpg-block in the source code of the page. Pass it to gpg, and you get the markdown used for generating the site and check the signiture, if you have my GPG key installed.

Thanks to Merovius for the neat jekyll plugin achieving this!

28. February 2014 23:15:00

25. February 2014


Die Hoheiten laden zum Aschermettwoch


Für alle die es nicht lesen können, hier die Transkription der Einladung ihrer Hoheiten:

“Mette Freunde seid gegrüßt!

Wir von der Rheinischen Zwiebel- und Lachsschinkenmettgesellschaft (RZL) laden Euch herzlich ein, mit unserem diesjährigen Faschingsprinzenpaar Mettina, die 1. & Mettlev, der 1. gemeinsam den Aschermettwoch zu feiern. Am 5. März treffen wir uns um 19.00 Uhr in unseren heilligen Hallen in der Boveristraße.

Damit wir ordentlich vorbereiten können, antwortet bitte bis zum 4. März 2014, 12 Uhr mit einem fröhlichen “Ahoi” auf diese Einladungsmauil, ob ihr bei der Sause dabei seid.”

by Unicorn at 25. February 2014 17:58:48

19. February 2014

Mero’s Blog

go stacktraces

Let's say you write a library in go and want an easy way to get debugging information from your users. Sure, you return errors from everything, but it is sometimes hard to pinpoint where a particular error occured and what caused it. If your package panics, that will give you a stacktrace, but as you probably know you shouldn't panic in case of an error, but just gracefull recover and return the error to your caller.

I recently discovered a pattern which I am quite happy with (for now). You can include a stacktrace when returning an error. If you disable this behaviour by default you should have as good as no impact for normal users, while making it much easier to debug problems. Neat.

package awesomelib

import (

type tracedError struct {
    err   error
    trace string

var (
    stacktrace bool
    traceSize = 16*1024

func init() {
    if os.Getenv("AWESOMELIB_ENABLE_STACKTRACE") == "true" {
        stacktrace = true

func wrapErr(err error) error {
    // If stacktraces are disabled, we return the error as is
    if !stacktrace {
        return err

    // This is a convenience, so that we can just throw a wrapErr at every
    // point we return an error and don't get layered useless wrappers
    if Err, ok := err.(*tracedError); ok {
        return Err

    buf := make([]byte, traceSize)
    n := runtime.Stack(buf, false)
    return &tracedError{ err: err, trace: string(buf[:n]) }

func (err *tracedError) Error() string {
    return fmt.Sprintf("%v\n%s", err.err, err.trace)

func DoFancyStuff(path string) error {
    file, err := os.Open(path)
    if err != nil {
        return wrapErr(err)
    // fancy stuff

19. February 2014 02:17:59

28. January 2014

sECuREs Webseite

Wake-On-LAN with Debian on a qnap TS-119P2+

Wake-On-LAN with Debian on a qnap TS-119P2+

Geschrieben von: Michael am 28.01.2014

The original firmware for the qnap TS-119P2+ supports Wake-On-LAN, meaning you can power down your Network Storage (NAS) when you don’t need it and you can easily wake it up by sending it a magic ethernet packet. This is an awesome feature when you are not at home all the time (say, you have a day job) and want to conserve some power without giving up on convenience.

Martin Michlmayr published an excellent website about using Debian on the qnap TS-11x/TS-12x devices, which made it really easy to install Debian on my NAS.

Unfortunately, until very recently, with a standard Linux kernel you could not use Wake-On-LAN with the qnap devices. There were multiple reasons for that:

  1. The Linux ethernet driver for the Marvell MV643xx series chips, which those NAS use, did simply not support configuring the chip for Wake-On-LAN. I fixed this in the Linux kernel on 2013-03-11, the fix was released with Linux 3.10.
  2. On the qnap NAS, there is a microcontroller which also needs to be configured with regards to the power-saving mode it should use. The NAS has a feature called EUP, which stands for “Energy-using Products”, a EU directive for power saving. When you enable EUP, your qnap sleeps so deep, it will not react to the WOL magic packet. This saves another watt or so. To turn this off, qcontrol needed to be patched to provide access to the WOL and EUP bits.
  3. And finally, the Debian kernel just did not enable the CONFIG_MARVELL_PHY configuration option which you need to actually make use of the kernel patch I landed in Linux 3.10. The bug I filed for this was fixed with the linux package in version 3.12.8-1.

Minimum package versions

To use Wake-On-LAN, you’ll need to install linux-image-3.12-1-kirkwood ≥ 3.12.8-1. Furthermore, you’ll need qcontrol ≥ 0.5.2-2. Note that you will also perhaps need to build qcontrol from git to disable the real time clock. Once there is a new package available, I’ll update this paragraph.

Enabling Wake-On-LAN

What you’ll need once is disabling EUP and RTC (real-time clock). You need to disable the RTC because otherwise the NAS is confused about scheduled wake-up and will immediately wake up after you power it down:

qnap # qcontrol eup off
qnap # qcontrol rtc off

Before every shutdown, you need to enable Wake-On-LAN:

qnap # ethtool -s eth0 wol g
qnap # qcontrol wakeonlan on

I like to turn off WOL after booting because I think (haven’t done enough testing to definitely confirm it) that the microcontroller gets confused when it receives a WOL packet while the box is running. In that case, it will immediately power back up after you power down.

Once you enabled WOL, power off the NAS, and try turning it back on from another machine:

qnap # ip link show eth0
qnap # poweroff
x200 $ wakeonlan 00:08:9b:de:22:ff

Note that you must not disconnect the device entirely from power, as the microcontroller will lose its state. That means, when you have a power outage, you need to power on the NAS manually once.

Making the WOL setup persistent

With the following systemd unit, you’ll get WOL disabled during runtime and enabled before powering off:

Description=Enable Wake on LAN on shutdown
# Just for having the correct order when shutting down.
# Require eth0 to be present before trying to change WOL.

ExecStart=/sbin/ethtool -s eth0 wol d
ExecStart=/usr/sbin/qcontrol wakeonlan off
ExecStop=/sbin/ethtool -s eth0 wol g
ExecStop=/usr/sbin/qcontrol wakeonlan on


You can find the newest version of this service file on github.

Automatically powering off

I wrote a program called dramaqueen, which will power off the NAS once it realizes that there are no more CIFS (Samba) sessions established. In addition to the CIFS checks, you can also set custom inhibitors, for example for running a backup.

To cross-compile dramaqueen for the qnap, use:

$ go get
$ GOARCH=arm GOARM=5 go build
$ file dramaqueen 
dramaqueen: ELF 32-bit LSB  executable, ARM, EABI5 version 1 (SYSV), …

In my setup, once I suspend my workstation (and all other machines using the NAS), the NAS will notice that my session has gone and shut itself down after 10 minutes.

by Michael Stapelberg at 28. January 2014 20:30:00

Compiling runit on EL6

If you try to compile runit on EL6, you may encounter the following error:

./compile runit.c
./load runit unix.a byte.a -static/usr/bin/ld: cannot find -lc
collect2: ld returned 1 exit status
make: *** [runit] Error 1

That’s because your system is missing the glibc-static package; use yum install -y glibc-static and your build will succeed.

28. January 2014 07:38:00

27. January 2014

sECuREs Webseite

Securing SuperMicro’s IPMI with OpenVPN

Securing SuperMicro’s IPMI with OpenVPN

Geschrieben von: Michael am 27.01.2014

In my last article, I wrote about my experiences with my new SuperMicro server, and a big part of that article was about the Intelligent Platform Management Interface (IPMI) which is included in the SuperMicro X9SCL-F mainboard I bought.

In that previous article, I already suggested that the code quality of the IPMI firmware is questionable at best, and this article is in part proof and in part mitigation :-).

Getting a root shell on the IPMI

When doing modifications on an embedded system, it is a good idea to have an interactive shell available for much easier and faster testing/debugging. Also, getting a root shell can be considered a prerequisite for the modifications we are about to make.

The following steps are based on Tobias Diedrich’s instructions “How to get root on and secure access to your Supermicro IPMI”.

After downloading the version of the IPMI firmware that is running on my machine from the SuperMicro website (filename and unzipping it, we have a bunch of executables for flashing the firmware plus a file called SMT_X9_315.bin which contains the actual firmware.

Running binwalk(1) on SMT_X9_315.bin reveals:

$ binwalk SMT_X9_315.bin

1572864   	0x180000  	CramFS filesystem, little endian size 8372224 version #2 sorted_dirs CRC 0xe0f8f23d, edition 0, 5156 blocks, 1087 files  
9961472   	0x980000  	Zip archive data, at least v2.0 to extract, compressed size: 1124880, uncompressed size: 2331112, name: "kernel.bin"  
11086504  	0xA92AA8  	End of Zip archive 
12058624  	0xB80000  	CramFS filesystem, little endian size 1945600 version #2 sorted_dirs CRC 0x75aaf428, edition 0, 926 blocks, 204 files  

So let’s extract the two CramFS file systems and mount them for inspection:

$ dd if=SMT_X9_315.bin bs=1 skip=1572864 count=8372224 of=cramfs1
$ dd if=SMT_X9_315.bin bs=1 skip=12058624 count=1945600 of=cramfs2
$ mkdir mnt1 mnt2
# mount -o loop -t cramfs cramfs1 mnt1
# mount -o loop -t cramfs cramfs2 mnt2

In mnt1 you’ll find the root file system, and it looks like mnt2 contains vendor-specific branding, i.e. their KVM client, images and CGI binaries for the web interface.

The firmware image itself is not the only binary that you’ll come in contact with when dealing with the IPMI. In “Maintenance → IPMI configuration” you can save your current IPMI configuration into a binary file and restore it later. Interestingly, these files start with the text “Salted__”, which is typical for files encrypted with openssl(1).

And indeed, after a bit of digging, we can find the binary that is responsible for encrypting/decrypting the configuration dumps and a bunch of interesting strings in it:

$ strings mnt1/bin/ipmi_conf_backup_tool | grep -A 1 -B 1 -m 1 openssl
openssl %s -d -in %s -out %s -k %s

And indeed, we can decrypt the file with the following command:

openssl aes-256-cbc -d -in backup.bin -out backup.bin.dec \

The resulting backup.bin.dec then contains the magic string ATEN\x01\x00 (where \x01 is a byte with value 1) followed by a tar.gz archive:

dd skip=6 bs=1 status=none if=backup.bin.dec of=backup.tar.gz

The tar.gz archive contains a directory called preserve_config which in turn contains a bunch of configuration files. Interestingly, the full lighttpd.conf lives in that tarball, presumably because you can change the port (they actually run sed(1) on the config file).

Now, the idea is to configure lighttpd in such a way that it will execute a file under our control. You can accomplish this by changing lighttpd.conf as follows:

--- lighttpd.conf.O	1970-01-01 01:00:00.000000000 +0100
+++ lighttpd.conf	2014-01-25 19:30:35.476345845 +0100
@@ -14,7 +14,7 @@
 server.modules              = (
 #                               "mod_rewrite",
 #                               "mod_redirect",
-#                               "mod_alias",
+                                "mod_alias",
 #                               "mod_access",
 #                               "mod_trigger_b4_dl",
 #                               "mod_auth",
@@ -174,7 +174,7 @@
 #server.errorfile-prefix    = "/srv/www/errors/status-"
 ## virtual directory listings
-#dir-listing.activate       = "enable"
+dir-listing.activate       = "enable"
 ## select encoding for directory listings
 #dir-listing.encoding        = "utf-8"
@@ -224,7 +224,8 @@
 #### CGI module
 cgi.assign                 = ( ".pl"  => "/web/perl",
-                               ".cgi" => "" )
+                               ".cgi" => "",
+                               ".sh" => "/bin/sh")
 server.use-ipv6 = "enable"
@@ -327,3 +328,5 @@
 #include_shell "echo var.a=1"
 ## the above is same as:
+alias.url += ( "/root" => "/" )

Now all we need is a custom .sh script somewhere on the file system and we are done. The program that restores backup files is mnt1/bin/, and if you have a look at it you’ll see that it only copies certain files over from the uploaded tarball.

If you have a really close look, though, you’ll realize that it also copies entire directories like preserve_config/ntp without any extra checking. So let’s put our code in there:

cat > ntp/ <<'EOT'
/usr/sbin/telnetd -l /bin/sh

In case you wondered, telnetd is already in the IPMI image since they are using busybox and presumably use telnet while developing :-).

The final step is to create a new tar.gz archive with your modified preserve_config and upload that either in the IPMI web interface or flash it using the lUpdate tool that you can find in the IPMI firmware zip file. While the web interface will accept unencrypted tar.gz files for backwards compatibility, I’m not sure whether lUpdate will accept them, therefore I’ll explain how to properly encrypt it:

$ cat > <<'EOT'
# The file is encrypted with a static key and consists of ATEN\x01\x00 followed
# by a tar.gz archive.

(echo -en "ATEN\x01\x00"; cat $1) | openssl aes-256-cbc -in /dev/stdin -out ${1}.bin -k $KEY
$ tar czf backup_patched.tar.gz preserve_config
$ ./ backup_patched.tar.gz
$ scp backup_patched.tar.gz.bin box:
box # ./lUpdate -i kcs -c -f ~/backup_patched.tar.gz.bin -r y

After the IPMI rebooted (give it a minute), you should be able to navigate to http://ipmi/root/nv/ntp/ and get an HTTP/500 error. Afterwards, connect via telnet to the IPMI and you should get a root shell.

Getting OpenVPN to work

Now that we have a root shell, we can try to get OpenVPN to work temporarily and then make it persistent later. The first step is to cross-compile OpenVPN for the armv5tejl architecture which the IPMI uses.

First, download the toolchain (SDK_SMT_X9_317.tar.gz (727 MB)) from SuperMicro’s FTP server and extract it. Run ./ and watch it fail if you have a x86-64 machine. Then, apply the following patch and run ./ again:

--- OpenSSL/openssl/config.O    2014-01-11 13:09:40.012461895 +0100
+++ OpenSSL/openssl/config      2014-01-11 13:10:17.749870032 +0100
@@ -53,6 +53,11 @@
 SYSTEM=`(uname -s) 2>/dev/null`  || SYSTEM="unknown"
 VERSION=`(uname -v) 2>/dev/null` || VERSION="unknown"

+VERSION="#3 Thu Oct 31 16:15:24 PST 2013"

 # Now test for ISC and SCO, since it is has a braindamaged uname.

After at least OpenSSL was built successfully, set up a few variables (based on ProjectConfig-HERMON), download and build OpenVPN:

export CROSS_COMPILE=$PWD/ToolChain/Host/HERMON/gcc-3.4.4-glibc-2.3.5-armv4/arm-linux/bin/arm-linux-
export ARCH=arm
export CROSS_COMPILE_BIN_DIR=$PWD/ToolChain/Host/HERMON/gcc-3.4.4-glibc-2.3.5-armv4/arm-linux/bin
export TC_LOCAL=$PWD/ToolChain/Host/HERMON/gcc-3.4.4-glibc-2.3.5-armv4/arm-linux/arm-linux

mkdir OpenVPN
cd OpenVPN
tar xf openvpn-2.3.2.tar.gz
cd openvpn-2.3.2

CFLAGS="-I$PWD/../../OpenSSL/openssl/local/include" \
CPPFLAGS="-I$PWD/../../OpenSSL/openssl/local/include" \
LDFLAGS="-L$PWD/../../OpenSSL/openssl/local/lib -lcrypto -lssl" \
CC=arm-linux-gcc \
  ./configure --enable-small --disable-selinux --disable-systemd \
    --disable-plugins --disable-debug --disable-eurephia \
    --disable-pkcs11 --enable-password-save --disable-lzo \
    --with-crypto-library=openssl --build=arm-linux-gnueabi \
    --host=x86_64-unknown-linux-gnu --prefix=/usr

Now, if you copy that openvpn binary to the IPMI and run it, you’ll notice that the kernel is missing the tun module, so that OpenVPN cannot actually create its tun0 interface. Therefore, let’s enable that module in the kernel configuration and rebuild:

sed -i 's/# CONFIG_TUN is not set/CONFIG_TUN=m/g' \
  Kernel/Host/HERMON/Board/SuperMicro_X7SB3/config \
  Kernel/Host/HERMON/linux/.config \
ls -l Kernel/Host/HERMON/linux/drivers/net/tun.ko

Now, after copying tun.ko to the IPMI, you can get OpenVPN to work with the following steps:

# insmod /tmp/tun.ko
# mknod /tmp/tun c 10 200
# /tmp/openvpn --config /tmp/openvpn.conf --verb 9

“Properly integrating” OpenVPN

Since I only have one SuperMicro X9SCL-F board and no development environment, I did not want to try to build a complete IPMI firmware and flash it. Instead, I decided to integrate OpenVPN by putting it into the NVRAM, where all the other configs live. That flash partition is 1.3M big, so we don’t have a lot of space, but it’s doable.

First of all, we need a script that will ungzip the OpenVPN binary, load the tun module, create the device node and then start OpenVPN in daemon mode. Furthermore, the script should enable telnet within the VPN for easy debugging, and it should set up iptables rules to block anything but the VPN. I call this script

# This script will be run multiple times, so exit if the work is already done.
[ -e /tmp/openvpn ] && exit 0
# Do not generate any output, otherwise the lighttpd config may break.
exec >/tmp/ov.log 2>&1

/bin/gunzip -c /nv/ntp/openvpn.gz > /tmp/openvpn
/bin/chmod +x /tmp/openvpn
/sbin/insmod /nv/ntp/tun.ko
/bin/mknod /tmp/tun c 10 200
/tmp/openvpn --config /nv/ntp/openvpn.conf --daemon
/usr/bin/setsid /nv/ntp/ &

/sbin/iptables -A INPUT -p tcp --dport 1194 -j ACCEPT &&
/sbin/iptables -A INPUT -s -j ACCEPT &&
/sbin/iptables -A INPUT -p udp -s -j ACCEPT &&
/sbin/iptables -A INPUT -p udp --sport 123 -j ACCEPT &&
/sbin/iptables -A INPUT -p icmp -s -j ACCEPT &&
/sbin/iptables -A INPUT -j DROP

The referenced looks as follows:

# /SMASH/chport executes “killall telnetd” and is run after /etc/init.d/httpd
# start, so it will kill our telnetd. This watchdog will restart telnetd
# whenever it gets killed.
while :
    /usr/sbin/telnetd -l /bin/sh -b -F

The openvpn.conf looks like this:

dev tun
dev-node /tmp/tun
secret /nv/ntp/openvpn.secret
port 1194
proto tcp-server
user nobody
script-security 2
keepalive 10 60
# TODO: This is a lower bound. Depending on your network setup,
# a higher MTU is possible.
link-mtu 1280

I’m using proto tcp-server because I only have SSH port-forwardings available into the management VLAN, otherwise I would just use the default proto udp.

Instead of the lighttpd.conf modifications I described above, this time we can use a simpler way of invoking this script:

echo 'include_shell "/nv/ntp/"' >> lighttpd.conf


You can grab a tarball (247 KiB) with all the files you need to extract to the ntp/ subdirectory.


In case a SuperMicro or ATEN engineer is reading this, please add built-in OpenVPN support as a feature ;-).

Apart from that, happy hacking, and enjoy the warm fuzzy feeling of your IPMI interface finally being somewhat secure! :-)

by Michael Stapelberg at 27. January 2014 17:30:00

23. January 2014

Mero’s Blog

Signed blog posts

tl;dr: I sign my blogposts. curl | gpg

I might have to update my TLS server certificate soon, because the last change seems to have broken the verification of This is nothing too exciting, but it occured to me that I should actually provide some warning or notice in that case, so that people can be sure, that there is nothing wrong. The easiest way to accomplish this would be a blogpost and the easiest way to verify that the statements in that blogpost are correct would be, to provide a signed version. So because of this (and, well, because I can) I decided to sign all my blogposts with my gpg-key. People who know me should have my gpg key so they can verify that I really have written everything I claim.

I could have used jekyll-gpg_clearsign, but it does not really do the right thing in my opinion. It wraps all the HTML in a GPG SIGNED MESSAGE block and attaches a signature. This has the advantage of minimum overhead - you only add the signature itself plus some constant comments of overhead. However, it makes really verifying the contents of a blogpost pretty tedious: You would have to either manually parse the HTML in your mind, or you would have to save it to disk and view it in your browser, because you cannot be sure, that the HTML you get when verifying it via curl on the commandline is the same you get in your browser. You could write a browser-extension or something similar that looks for these blocks, but still, the content could be tempered with (for example: Add the correctly signed page as a comment in a tampered with page. Or try to somehow include some javascript that changes the text after verifying…). Also, the generated HTML is not really what I want to sign; after all I can not really attest that the HTML-generation is really solid and trustworthy, I never read the jekyll source-code and I don't want to, at every update. What I really want to sign is the stuff I wrote myself, the markdown (or whatever) I put into the post. This has the additional advantage, that most markdown is easily parseable by humans, so you can actually have your gpg output the signed text and immediately read everything I wrote.

So this is, what happens now. In every blogpost there is a HTML-comment embedded, containing the original markdown I wrote for this post in compressed, signed and ASCII-armored form. You can try it via

curl | gpg

This should output some markdown to stdout and a synopsis of gpg about a valid (possibly untrusted, if you don't have my gpg-key) signature on stderr. Neat!

The changes needed in the blog-code itself where pretty minimal. I had however (since I don't want my gpg secret key to be on the server) to change the deployment a little bit. Where before a git push would trigger a hook on the remote repository on my server that ran jekyll, now I have a local script, that wraps a jekyll build, an rsync to the webserver-directory and a git push. gpg-agent ensures, that I am not asked for a passphrase too often.

So, yeah. Crypto is cool. And the procrastinator prevailed again!

23. January 2014 04:04:25

12. January 2014

Atsutane's blog

Distri A ist toller als B

Sie tauchen alle paar Wochen in meinem Feedreader auf, subjektive Bewertungen warum die Linux Distribution A besser als die Distribution B ist. Bleiben diese Vergleiche sachlich und weisen auf Stärken und Schwächen der unterschiedlichen Systeme hin, sind diese Texte ja durchaus lesenswert und interessant. Man wird auf Dinge hingewiesen, denen man selbst bisher vielleicht gar keine Beachtung geschenkt hat. Leider sind das die wenigsten Posts.

Die meisten sind schlicht emotionale Texte, leider oft auch lächerlich. Es werden Dinge miteinander verglichen, ohne dass der Kontext berücksichtigt wird. Ja, eine Distribution, welche binäre Packete bereitstellt ist für die meisten Personen im Alltag angenehmer zu verwenden, als ein Linux From Scratch System zu pflegen. Diese Personen gehören aber auch nicht unbedingt zur LFS Zielgruppe.

Andererseits sind es gerade diese Texte, welche unterhalten und die Stimmung heben können. Wenn man dann am Abend die Nachrichten des Tages gelesen hat und sich fragen muss, wie fern der Realität denn so mancher Politiker lebt, sind es Posts, bei denen es um relativ belanglose Dinge wie den Installer geht, die mir den Abend versüßen. Denn hey, da mögen Kernel und Userspace zwar identisch sein, aber der Installer, den man so oft nutzen muss, der gefällt mir nicht!

Insofern: Vielen Dank, wo bleiben die Posts, dass SteamOS so viel toller als Distribution C ist? :-)

12. January 2014 15:07:54

11. January 2014

sECuREs Webseite

Building a SuperMicro 1U server (with IPMI)

Building a SuperMicro 1U server (with IPMI)

Geschrieben von: Michael am 11.01.2014

Recently, together with a couple friends of mine, we rented a rack in a datacenter. Not just any datacenter, but that’s a story for another time ;-). Each participant can hang up a 1U server in that rack, so I needed to build one.

In this article, I’ll shed some light on the rationale behind which components I ordered and what my experiences with this setup are. Most of the article will cover the IPMI, a remote management interface. Having IPMI permanently available (as opposed to on-demand at my current dedicated server hoster) and influencing which components go into that box are the two killer features for me.

Choice of vendor

There are a number of big hardware companies out there, and in fact many people in this little project just bought a Dell r210 (Dell’s current entry-level server) or an HP machine. While that is certainly an easy option, I wanted fancier remote management capabilities. With Dell, you only get basic IPMI, but no remote console and virtual media functionality, unless you pay for the extra iDRAC board.

Recent SuperMicro mainboards on the other hand come with IPMI 2.0, including remote console and virtual media. Also, their boards generally made a really good impression on me and many people I know. Given that I like assembling my own computers and choosing every single part that goes into the machine, I decided to go with a custom SuperMicro box instead of an “off-the-shelf” server of one of the big players.

Hardware specifics

The cheapest widely available SuperMicro board that I could find is the X9SCL-F. It accepts only Intel Xeon processors, so I ordered the cheapest Xeon I could find: E3-1220 v2. The rationale here is that modern CPUs provide a lot of computing power, but the server workloads I run are far from CPU constrained. There are a couple of interesting features that the CPU has, though. For one it supports AES-NI, an instruction set introduced by Intel to speed up AES encryption/decryption. This makes it feasible to encrypt all data on the disks without paying a big latency/throughput penalty. Furthermore — and that is probably true for all server CPUs manufactured in the last couple of years — it supports Intel VT-x for hardware virtualization, so that I can run KVM, if I chose to.

The combination of the SuperMicro X9SCL-F mainboard and the memory controller on that Xeon processor require unbuffered ECC-RAM. The term “unbuffered” means it should not be registered memory. This is a bit peculiar combination, but you can find RAM modules that fit the bill. I chose to go for 2 modules with 8 GB each (Kingston KVR16E11), which is the maximum supported amount of memory per module. If it turns out that I want more memory in the future, I can just add two more 8 GB modules.

As for the disks, I have had a lot of disks fail in the last couple of years, so nowadays I just buy the enterprise grade disks, typically from Western Digital. For SATA, this means using the WD RE4 WD1003FBYX-0. I bought two of them and run them in a RAID-1 so that one can fail and the box still continues working. Of course, in case of failure, I’ll need to order a new disk, drive to the datacenter and replace the disk. In case you wonder: the particular case I bought does not have hot-swap drive bays, which was not entirely clear to me. With a better case, one could maybe store a hot spare (i.e. a drive in a hot plug tray) at the datacenter and have the remote hands just replace the drive for you.

The case I chose is the SuperMicro SC512L-260, and I regret that. It’s the smallest and cheapest 1U case that SuperMicro sells, and it shows. The power supply unit only has 4 pin molex connectors, no SATA power connectors, so you need adapters. The wiring in the case is far from satisfactory, and the mainboard power cables are just barely long enough. Instead of having drive enclosures and a proper way to put them into the case, you directly mount the drive on the bottom of the case with screws. Of course, actually putting the drive in requires you to take out the fan (which is in the middle between the two drives), otherwise you don’t have enough space to do anything. The case is not very deep, but that’s not an advantage in any way, IMO.

SuperMicro box 1 SuperMicro box 2 SuperMicro box 3

Setting up the machine

Since the machine is located an hour’s drive away, I wanted the remote management functionality to work well. In order to test that, I decided to install the machine “remotely”, and not just boot from USB.

When SuperMicro writes that the X9SCL-F has two ethernet ports, what they really mean is that it has two ports (LAN1 and LAN2) and a dedicated IPMI ethernet port. This was a bit of a surprise, I thought it had only one LAN port and the IPMI port. It’s not a big issue either, but it means that your operating system will find two ethernet adapters when installing, and you need to chose the right one. Also, depending on your Linux distribution (i.e. whether it has predictable interface names or not), you may get LAN1 detected as either eth0 or eth1. This is not a big deal since typically the order is persisted in e.g. /etc/udev/rules.d/70-persistent-net.rules on Debian. However, it is one thing to be aware of when installing a new operating system or partially restoring from a backup.

The first thing that really annoyed me was that the BIOS by default comes with IPMI disabled. There are three options on how IPMI can get its network configuration: statically configured, using DHCP or “do nothing”. Not very helpfully, the default is “do nothing”, and serial console redirection is also disabled in the BIOS. This means you need to hook up the machine to a monitor and a keyboard at least once. Luckily, USB keyboards work just fine. Nevertheless, it is unclear to me why you would chose that setting as a default. For people deploying these (server) mainboards in datacenters, it adds an additional step, whereas people who don’t want the IPMI need to have a way to access the BIOS anyway to change settings (or they could disable IPMI using IPMI…).

When enabling IPMI, do pay attention to the LAN interface setting which controls on which ethernet interface the IPMI is active. The value “failover”, which is the default, means that at boot time, the IPMI will check if there is a link on the dedicated IPMI ethernet interface and fail over to LAN1 otherwise. “Boot time” is somewhat unclear in this context, given that the IPMI BMC boots as soon as there is physical power connected to the machine, no matter whether you actually power up the board. In order to get a deterministic and reliable mode of operation, you should chose either “shared” or “dedicated” instead of “failover”. Dedicated is pretty clear — IPMI will only be active on the dedicated IPMI interface. This is okay if you have enough ethernet cables and ports and don’t mind the extra wiring. In our case, we wanted to avoid that, so I went for “shared”, meaning there will be two MAC addresses on LAN1 (which is the left-most port on the mainboard). You can also configure the shared IPMI to use a VLAN ID. Note that you should update your IPMI firmware to the latest available firmware version before trying to do that (03.15 at the time of writing). Otherwise, VLANs might just not work at all :-).

Note that I later discovered that using one ethernet cable and the “shared” setting is not a good idea. When rebooting, the ethernet port will be disabled and it takes quite some time until the IPMI makes it come up again. Typically, it takes longer than the time frame where you can enter the BIOS. This means you need a cooperating host (or ipmitool(1) on another host) in order to tell it to go the BIOS (see below). If you can, definitely use the dedicated ethernet interface.

The IPMI interface is reachable via HTTP (or HTTPS, but more on that later) on the IP address that you configured or that it got via DHCP. The web interface makes heavy use of JavaScript, but works fine on Chrome and Firefox on Linux. To log in for the first time, use the username ADMIN and password ADMIN.

Using the remote console

While the IPMI’s remote console (called iKVM) is based on VNC and even runs on port 5900, it does use a non-standard authentication protocol. To get access, you typically log in to the web interface, navigate to “Remote Control” → “Console Redirection” and press the “Launch Console” button. The interface will serve a jnlp file, which you can launch using javaws(1).

There are third-party implementations of this protocol for Mac OS X at, but I haven’t tried them yet.

Note that if you access the IPMI web interface through SSH tunnels with different ports, you’ll need to replace the ports in the jnlp file.

IPMI Remote Media

The remote media functionality on the X9SCL-F with IPMI firmware version 03.15 can only read an image from Windows shares (CIFS). It wants you to specify a hostname or IP address plus the path to the image. The path contains the share name, so if your share is called “isos” and the ISO image is called “debian-netinst.iso”, the path is “\isos\debian-netinst.iso”.

To serve files via CIFS without authentication easily, install the “samba” package on Debian and modify your /etc/samba/smb.conf to contain the following lines:

  workgroup = WORKGROUP
  server string = x200
  dns proxy = no
  interfaces = eth0
  syslog = 0
  browsable = yes
  map to guest = bad user

  encrypt passwords = true
  passdb backend = tdbsam
  obey pam restrictions = yes
  unix password sync = no

  path = /home/michael/debian-images/
  read only = yes
  guest ok = yes
  browseable = yes
  guest account = nobody

I specified “guest” as username and “guest” as password in the webinterface, just to be sure, and that worked fine.

Note that you specifically need to chose “virtual media” as a boot device in the BIOS, though. In my tests, even after changing the boot order to contain virtual media as the first option, this setting would not always persist across multiple reboots (perhaps it gets discarded as soon as you boot without a virtual media image mounted).

Using ipmitool(1) on the host

After installing an operating system, you need to make sure that a bunch of kernel modules are loaded before you get the /dev/ipmi0 device node that ipmitool(1) requires:

modprobe ipmi_si
modprobe ipmi_devintf
modprobe ipmi_msghandler

In order to boot into the BIOS (useful if the IPMI is unreachable during boot because it’s running on the shared ethernet port), use:

ipmitool chassis bootdev bios

Enabling the serial console

Because you can never have enough safety nets, it makes sense to use the serial port in addition to the IPMI.

With systemd, getting a getty started on a serial console is as simple as booting with console=ttyS0 in the kernel command line, which has the nice side effect of also letting the kernel log to serial console. In addition, you’ll want to have grub itself be available on the serial console. On Debian, this works in /etc/default/grub:

GRUB_CMDLINE_LINUX="console=tty0 console=ttyS0 init=/bin/systemd"

Installing a custom SSL certificate

In our hosting project, every participant has access to the management VLAN, so everyone can connect to the web interface. Even worse, since the access is all tunneled through the same box, theoretically the box admin (or any attacker with a local root exploit) could sniff the traffic, thus gather the IPMI password (no, they don’t use a challenge response mechanism) and own your box. While the chances of that happening are relatively slim and I trust the other participants, I like end-to-end cryptography and decided I want to properly secure that interface as far as reasonibly possible.

It took me quite a while to get this working, so I’ll be very specific on what the IPMI does. It is running a standard lighttpd to handle HTTP/HTTPS connections and execute CGI binaries. The SSL configuration is:

$SERVER["socket"] == ":443" {
  server.use-ipv6 = "enable"
  ssl.engine = "enable"
  ssl.cipher-list = "TLSv1+HIGH !SSLv2 RC4+MEDIUM !aNULL !eNULL !3DES @STRENGTH"
  ssl.pemfile = "server.pem"

In server.pem, the web interface stores the certificate followed by the private key.

What is important to know is that the httpd init script also runs “openssl verify”, probably to make sure that the user-provided certificates actually work and not have the lighttpd crash-loop. What’s unfortunate about this is that “openssl verify” verifies only the first certificate it finds in the PEM file. In case you want to use an SSL certificate that is actually verified by a trusted CA, this implies that the first certificate in the .pem file needs to be the CA certificate itself (because the IPMI does not have a certificate store). In my case, I tried the order “CA, intermediate CA, certificate, private key”. However, lighttpd will not load the certificates and just exit with an error:

2014-01-09 23:51:06: (network.c.601) SSL: Private key does not match the
certificate public key, reason: error:0B080074:x509 certificate
routines:X509_check_private_key:key values mismatch server.pem 

There are two possible workarounds for this problem:

SSL method 1: Get “OK” into the certificate

This is the most fun method. You just need to manage to get the string “OK” into any of your certificate’s fields — the common name will do. Note that this is case sensitive, so if your CA converts hostnames to lower case before issuing the certificate, this won’t work. In case they don’t, a certificate issued for e.g. will happily pass the init script’s check. This is because the “openssl verify” output includes the certificate’s fields in the output, and the init script merely greps for “OK”:

# …
openssl verify $CERT_FILE > /tmp/ 2>&1;
if [ -z "`cat /tmp/ | grep OK`" ];then 
# …
    echo "SSL certificate verified OK."                    

SSL method 2: Use a self-signed certificate

It’s not quite as clean, but you can just use a self-signed certificate, created as follows:

openssl req -x509 -nodes -newkey rsa:2048 -keyout key.pem -out cert.pem -days 365

The common name is where you want to enter the DNS that points to your IPMI. Afterwards, you can just upload cert.pem as certificate and key.pem as private key in the web interface.


The server seems to work pretty well, but the IPMI clearly still needs some work. It’s essentially an embedded computer, to a large part closed source, with questionable security/code quality and only somewhat reliable remote management capabilities. In addition to the inherent port flapping with the “shared” ethernet configuration I described above, the iKVM server also crashed on me once.

Let’s see if SuperMicro (or ATEN, the company that actually makes the IPMI) is willing to improve things :).

by Michael Stapelberg at 11. January 2014 17:00:00