Butler beauftragt

Ich habe in der vergangenen Woche die Firm­ware­er­stel­lung für Freifunk Güters­loh um­ge­stellt und dabei auch Jenkins ein­be­zogen.

Nach einigen initialen Problemen, unter anderem mit git – ich komme mit dessen Branch-Verwaltung einfach nicht klar, ergo separiere ich Branches in separate github-Projekte –, arbeite ich nicht mehr – mit sshfs & lokalem emacs – auf Quellen, die auf dem Buildhost liegen und checke dann und wann Änderungen bei github ein. Mittlerweile habe ich die Quellen auf meinen Rechnern in Berlin und Gütersloh lokal und bearbeite sie auch lokal mit »pyCharm« — einer IDE, die das direkte Synchronisieren via git erlaubt. Bei dem Umfang an Dateien war der alte Ansatz einfach nicht mehr zeitgemäß ;)

Nachdem nun aber github die zentrale Codequelle ist, lag es nahe, auch den Firmwarebau zu automatisieren, und da wir dies bei meinem Brötchengeber per »Jenknis« machen, lag es nahe, dies auch im Freifunk-Umfeld zu tun. Jenkins sebst war schnell auf den Buildhost eingerichtet, als SSL-Zertifikat dient aktuell ein selbst signiertes; imho reicht das, es geht ja primär um die Absicherung des Logins. Etwas trickreich ist die Aufteilung Gluons in Gluon-Basis, Gluon-Pakete, Community-Pakete und Community-Konfiguration, sprich, 3 (4) verschiedene Repos müssen beobachtet werden, und bei Änderungen dort der Build angestoßen. Hinzu kommt, daß in zwei der Repos Verweise auf auszucheckende Commits anderer Repos enthalten sind (»Gluon-Basis«/modules für u. a. »Gluon-Pakete«, »Community-Konfiguration«/modules für »Community-Pakete«).

Da ein initialer Build rd. 2,5 Stunden auf der mit 4 virtuellen CPUs bestückten VM dauert, ein Rebuild noch immer ca. 15 Minuten, wollte ich keine unnötigen Build-Läufe wegen vergessener manueller Aktualisierung der »modules«-Dateien riskieren. Daher sammelt der Buildjob die aktuellen Commit-IDs der von Jenkins ausgecheckten Repos zusammen und trägt sie in die für den Build verwendeten »modules«-Dateien ein. Danach wird mittels »make update« usw. die Firm­ware­er­zeug­ung gestartet, am Ende wird in das images/factory-Verzeichnis noch eine Datei geschrieben, die diese Commit-IDs jeweils enthält — somit kann man eine bestimmte Version erneut bauen, falls später einmal notwendig. Derzeit überlege ich, diese Dateien ins »Community-Konfiguration«-Repo einzuchecken, um sie revisionssicher auch im SCM zu halten …

Letztlich alles keine großen Änderungen, aber mit einem, aufgrund aktueller Vorkommnisse im Bereich des Verbunds freier Netzwerke Nordrhein-Westfalen e.V. IMHO relevanten, netten Nebeneffekt: ab jetzt sollte im Grunde »jeder« die Gütersloher Firmware nachbauen können, und, da sie nun aus den öffentlich auf github einsebaren Quellen erzeugt wird, auch überprüfen, daß dort keine Backdoors eingebaut wurden/werden.

Derzeit läuft die Endphase der Anpassungen für Firmware 0.6, basierend auf Gluon 2014.4. Mehr dazu an anderer Stelle, sobald spruchreif ;)