Over the years I've had to make a lot of choices, about what editor, programming language, frameworks and whole projects to pick to get stuff done. Think coding for university, setting up projects for work and customers, writing open source software and maintaining services for the community.

While some of the decisions were no-brainers, e.g. when the company I worked for has had already settled on a framework or there was only a single tool available, most of the times there was quite an array of options to chose from and picking the right one required some effort – and hindsight I simply didn't have at the time.

As all older people do, I assume that me writing down my lessons learned will prevent you, dear reader, from making your own mistakes. So without further ado, I introduce my 7 points of how to spot software projects that may or may not work for you.

1. Define your breaking points!

Remember: Sometimes it's okay to just say no completely. You do not have to settle for the least ugly option, especially when doing open source work. You should decide in advance how much energy your project is worth. You may then decide if it's smarter to abandon your plans or to bite the bullet and chose a sub-optimal dependency, or even fork or set up a new project to solve the unsolved.

At your work place, you might put up with much worse options than with projects you want to do in your spare time, but maybe you can take this list and convince your boss or co-workers to re-evaluate decisions.

2. How much does the project know and communicate about prior art, best practises and how they fit in there?

Did the project authors and maintainers spend the effort of building platform ports or are you required to follow a "Best viewed with Internet Explorer 6 in 1024 x 768" approach and force you to deploy precise replicas of their setups?

red flags:

• curl | bash,
• bashisms in Makefile or shell scripts,
• "Windows filenames" (build breaks if filesystem is case sensitive),
• temp files or editor backup files in distribution,
• hard-coded credentials or certificates,
• project builds only in Docker / github CI pipeline,
• source code treated as second-class installation option (they really want you to install binary packages),
• dependencies on tools or libraries in versions other than current stable release.

green flags:

• packages for more than one platform,
• build enables all compiler warnings and none show up during regular build,
• build system comes prepared for cross-compilation,
• project has open bug tracker,
• bug tracker shows that bugs are attended to and not closed on a whim,
• README clearly states security contact for when you find a security bug.

Are the project's devs and contributors active on other projects, maybe even some you've heard of?

Does the user and admin documentation hint at the authors following best practices? This is important because, for example as an admin, you don't want to be stuck studying the complete project and their dependencies just for trouble shooting a single problem.

Are the project's maintainers aware of trade-offs and short comings of their project?

red flag:

• The project page is full of marketing speech and a liberal use of "awesome" words.

green flag:

• Embracing criticism. You can only be a true fan of a project if you have at least one hour worth of rant about the warts-and-all.

3. Do you like the project's documentation?

Does the project's documentation cover the basics with some handy primers and how to grow from using a small feature set to the whole API?

Will the first google hit for a medium complexity keyword from the project – be it an API call, a config keyword or keyboard short cut – be somewhere at the project's page or on Stack Overflow?

Does the project come with some good opinionated defaults along with their respective rationales?

Are the defaults there because they are useful or for backwards compatibility?

Do you have to manually turn on vital security aspects?

Are obscure knobs documented? Older projects usually have some special functions or knobs for special cases that probably won't apply to you. The documentation should make clear which options are for obscure special cases so you don't get lost in the details when looking for a specific thing.

Do they thoroughly cover how to maintain the projects or do all the guides stop right after you installed the project? Which leads us to …

4. How much regular attention does the project require?

Good tools require cleaning and maintainance – but once you spend all your time just on your tools, you're not getting work done.

Does the project clearly understand and communicate what dependencies they bring and how to keep those up to date?

Are those dependencies well balanced? Is the same true for their recursive dependencies (this includes the programming languages chosen).

As a more specific example, is the project written in a language with a clear and complete runtime for the basics? Think libc vs. leftpad, python's batteries included approach, etc.

A good sign is a few dependencies with a guaranteed stable API.

Once you understand the dependency tree, is there another option with fewer deps? IOW: Do you need all the things provided by the project at hand, or is there a more specific tool for your problem?

Given how much time you can realistically spend on a single dependency: Can the project and its stack cope with routine maintainance intervals of one year? Does the project give guarantees not to break config or user data on updates?

Does the project have a policy and a schedule for updates vs upgrades vs security patches? Are they free without a subscription?

If the user can't chose maintainance time (e.g. on security updates), does the project guarantee that you will not be forced to upgrade to breaking changes?

How quickly are dependencies deprecated? Are you required to re-work basic functionality within less than a year?

5. Is the project there to stay?

What is the project's head count?

Is the community's size in a healthy proportion to the project's complexity?

What kind of contributors and users does the project attract? How's the tone in associated forums? Is that a good sign for you?

Where's the project hosted at? Does it run some own infrastructure or will the dependency break once you or your customers are in a sanctioned region?

Has project ownership changed hands? More than once?

6. … and if not do they help you to move on?

If the project provides migration helpers, do they only point in one direction?

Can you dump payloads, meta data and config information in a structured format that helps you inspecting and importing it elsewhere later? From my experience it is best, if the project did anticipate its obsolescence and provide these functions right from the start.

Does the project's config language require knowledge about some plumbing that you should not need to care about?

Can you see a clear path how to use a competing project or it's API should you reconsider or are you stuck to the point of requiring a rewrite or complete re-start of your project?

7. What's the extra baggage YOU leave?

If you need to hand over the project due to unforeseeable circumstances, is it easy to find replacement for you, your config, private forks or tweaks?

Does your choice of programming language or framework leave your colleagues or peers with further technical debt and fewer good options? Sometimes it's better to go with a mainstream choice so that more or more affordable peers can contribute later.

Would your own project tick all the above points to your own satisfaction?

Gestern erreichte mich eine freundliche E-Mail eines Juristen, der in der Legal-Tech-Szene aktiv ist. Darin erklärte er, Teil eines Teams zu sein, das im Februar überraschend mit seinem Projekt einen Hackathon gewonnen hätte. Das dort entstandene Tool "Dickstinction" wurde am Tag der E-Mail bei Netzpolitik behandelt. In der Folge wurden ihm Hinweise zugetragen, nach denen eine gewisse Ähnlichkeit mit dem Abmahnbeantworter des CCC unverkennbar ist. Der wird in dem Artikel bei netzpolitik.org erwähnt, allerdings fälschlicherweise in eine Reihe gestellt mit kommerziellen Projekten. Der Abmahnbeantworter hat aber kein Geschäftsmodell, sondern ist ein kostenloses Angebot an Betroffene von unberechtigten Abmahnungen.

In der E-Mail entschuldigte sich der Jurist freundlich für die ungefragte Übernahme des Konzepts und bot an, nachträglich einen Hinweis auf den Ideengeber (also uns) auf die Webseite von Dickstinction zu schreiben und unser Projekt fortan in Interviews zu erwähnen, da sich das Team ja stark an der Vorlage des Abmahnbeantworters orientiert habe. Genaues wisse er nicht, da er kein Programmierer sei, aber er wolle auf jeden Fall bescheidgeben und nach meiner Meinung fragen. Soweit total korrekt.

Der Abmahnbeantworter wurde vor vier Jahren – unter juristischer Beratung von RAin Beata Hubrig und durch Umsetzen des Interface- und Usability-Designs von Malik Aziz – nach mehreren Monaten harten Lernens und Testens entwickelt. Ich bin tatsächlich kein Webprogrammierer, sondern eher in C/C++/Assembler zuhause, weswegen der Lernprozess zeitintensiv war. Daher war ich natürlich erstmal interessiert, welche Aspekte des Abmahnbeantworters wohl übernommen worden waren, auch um eventuell selber Ideen für Verbesserungen aufzuschnappen – Konkurrenz belebt ja das Geschäft. Eine kurze Inspektion der Web-Resourcen des Dickstinction-Projekts hat mich dann doch ehrlich erschüttert: Man muss schlicht nur deren main.js gegen unsere abmahn.js halten oder die Strukturen der jeweiligen HTML-Seiten oder das CSS vergleichen, um in Abgründe zu sehen, derer sich wohl einzig von Guttenberg nicht schämen würde.

In der FAQ von Dickstinction wird neben einem Vorstellungsvideo die Genese des Dickstinction-Projekts kurz umrissen:

"Dickstinction haben wir im Februar 2020 im Rahmen des Berlin Legal Hackathon 2020 in weniger als 24h programmiert und damit den ersten Preis gewonnen."

Dazu kann ich nur sagen: Nein, habt ihr nicht! Programmieren bedeutet eine recht langwierige Arbeit mit Nachdenken, Selbstkorrektur, manchmal ein bisschen Schweiß. Kopieren ist hingegen schnell erledigt.

Während mir Euer Projekt-Konzept wirklich schwer am Herzen liegt und es mir schon jetzt die Tränen in die Augen treibt, sollte dieser Rant hier dem Projekt schaden, fühlt es sich unendlich mies an, wenn sich (laut der E-Mail zwei) Entwickler für die Präsentation eines dreisten Plagiats beklatschen lassen, in dessen Original ich ehrenamtlich viel Herzblut, monatelange Arbeit und Koordinationsaufwand gesteckt habe. Daher weiß ich übrigens auch, dass man sowas nicht mal eben in einem 24-Stunden-Hackathon runterschreibt. Ich weiß zwar nicht, wer aus der Liste in der FAQ genau die Programmierer sind, die sich an meinem Code bedient haben, aber ich sehe hier erstmal mehrere Probleme, die das Dickstinction-Projekt nun intern klären muss.

Das alles wirft einen schweren Ballast auf meinen Eifer und mein ehrenamtliches Engagement, vor allem, weil vor drei Jahren bereits ein anderes meiner Open-Source-Projekte als Voll-Plagiat neu-veröffentlicht und vom Plagiator auch noch öffentlich auf allen Kanälen beworben wurde: Das hatte ich damals in einem Blog-Post zu ezjail vs qjail niedergeschrieben.

Ich habe dem Verfasser der E-Mail geantwortet und meine Gedanken dargelegt.

Zuerst: Ich persönlich bin eigentlich kein Web-Programmierer, daher macht es mir eher Angst, wenn mein Web-Code von Leuten verwendet wird, die von den intrinsischen Annahmen über dessen Verwendung wenig Ahnung haben. Es ist eben keine Software-Bibliothek, was sich auch in der eher unterdurchschnittlichen Kommentierung und Dokumentation niederschlägt. Weil es eben nicht zum Wiederverwenden gedacht war, habe ich mir auch keine Gedanken um eine Lizenz gemacht. Ich bin schlicht nicht davon ausgegangen, dass sich jemand daran "orientiert" oder es eben komplett kopiert.

Das bringt mich nun in eine blöde Lage. Normalerweise veröffentliche ich meine Open-Source-Projekte (https://erdgeist.org so der Abschnitt links) unter der Beerware-Lizenz https://erdgeist.org/beerware.html, was grundsätzlich Public-Domain mit der Ausnahme Namensnennung ist. Am Projekt selber steht aus o. g. Gründen keine Lizenz dran, was grundsätzlich ja erstmal bedeutet, dass wir am Code volles Urheber- und Verwertungsrecht haben. Natürlich wollen wir das nicht hart geltend machen, aber … als Open-Source-Coder hat man quasi nicht viel außer Reputation, und es fühlt sich nicht cool an.

Was mich noch mehr bewegt, IHR müsst ja erstmal irgendwie damit umgehen, dass ihr mit einem Plagiat Eurer beiden Entwickler einen ersten Platz bei einem Hackathon belegt habt. Das schmälert nicht die Leistung derer, die am Ende die Projekt-Idee entwickelt haben. Aber ich denke, für den Gewinn eines Hackathons sollten die Programmierer schon ein bisschen mehr vorzuweisen haben als "ich habe ein fremdes Projekt genommen, andere Farben rangemacht und meinen Namen drangeschrieben".

Es gibt außer sonst nur leichten optischen Änderungen übrigens eine nicht ganz unwichtige Abweichung zwischen dem Abmahnbeantworter und Dickstinction: Die gloriosen Hackathon-Gewinner haben sich immerhin die Zeit genommen, das Google-Tracking (firebase) zu integrieren. Ob das eine gute Idee ist, die Penisbilder-Informationen in die Vereinigten Staaten zu übermitteln, will ich nicht weiter kommentieren. Selbstverständlich findet beim Abmahnbeantworter keinerlei Tracking statt.

Ich werde rechtlich nicht gegen das Projekt vorgehen, sondern unterstütze die Intention weiterhin. Aber diese Art, für den billigen Ruhm beim Hackathon bei anderen Leuten zu klauen, darf nicht zum Standard werden. Deswegen kann ich auch nicht dazu schweigen, wenn ich derjenige bin, von dem dreist kopiert wurde. Ich denke sogar: Man darf dazu nicht schweigen, denn dann machen solche Leute einfach weiter wie bisher.

Und während in der E-Mail noch der Hinweis auf den nichtkommerziellen Hintergrund des Projekts kam:

Wie ihr sehen könnt, dient die nicht-kommerzielle Seite einem guten Zweck, weshalb wir uns über die Nutzungsmöglichkeit sehr freuen würden!

, deutet die Übergabe des Gewinnerschecks in Höhe von 2000 € darauf hin, dass sich die Projektbeteiligten das eine oder andere Spielzeug shoppen gehen konnten. Natürlich kommt es mir nicht darauf an, das Geld jetzt selber einzustreichen, aber ich habe so ein Bauchgefühl, wo es korrekterweise nicht hingehört. Und auch für die Zukunft würde ich mir wünschen, dass der Austausch mit Unternehmen für weitere Features den "nicht-kommerziellen" Hintergrund des Projekts nicht korrumpiert.

Im selben Interview finden sich auch besorgniserregende Informationshäppchen. Die verklausulierte Perspektive:

Rein rechtlich finden wir diesen aber besonders spannend, weil man sich auf elegante Weise den Möglichkeiten des Strafprozessrechts bedienen kann, um einen zivilrechtlichen Anspruch durchzusetzen.

bedeutet letztendlich nichts anderes, als auf dem automatisierten Generator ein eigenes kostenpflichtiges Abmahn-Modell zu begründen. Ein zuckersüßes Sahnehäubchen ins Gesicht unserer ursprünglichen Bemühungen, den Abmahnwahn einzudämmen.

Was die Mädels und Jungs bei Dickstinction jetzt draus machen, wird sich zeigen.

Update

Inzwischen habe ich von einem der Programmierer, Stefan B, eine E-Mail bekommen, in der er die Geschichte als kleines Versehen abtut und mich bittet, doch nachträglich die Engine als Open-Source-Projekt zu veröffentlichen und ihnen die Nutzung zu erlauben.

Was hältst du davon den Code der Seite unter einer Open-Source Lizenz zu veröffentlichen, sodass jeder diesen nutzten und weiterentwickeln kann?

In einer Welt des Kommerz einen nicht- oder antikommerziellen Kosmos zu pflegen, ist hart. Die Menschen, die sich in dieser besonderen Sphäre zusammenfinden, wie wir sie auf unseren CCC-Veranstaltungen seit Jahren hochhalten, kommen aus den unterschiedlichsten Schichten und leben im Rest des Jahres nicht im luftleeren Raum. Sie müssen sich ernähren, müssen wohnen und wollen gesellschaftliche Teilhabe auch an Ereignissen, bei denen sie nicht – wie bei Camp und Congress und viele der kleineren CCC-Veranstaltungen – bewusst subventioniert werden. Doch auf unseren Veranstaltungen müssen wir alle damit klarkommen, das Spannungsfeld von deutlichen Wohlstandsunterschieden und die Auswirkungen von Lebensentwürfen mit unterschiedlicher Zeitflexibilität hautnah mitzuerleben.

Wir sehen unsere Veranstaltungen als solidarisch organisierte Ereignisse, bei denen Teilnehmer mit mehr finanziellen Resourcen regelmäßig mehr geben – sei es direkt beim Solidar-Eintrittspreis oder beim großzügigeren Merch-Kauf – als Teilnehmer mit weniger flexiblen Möglichkeiten. Für besondere Härtefälle versuchen wir zudem seit Jahren, faire Möglichkeiten anzubieten, sich an den unvermeidlichen Kosten der Veranstaltung im Rahmen der eigenen finanziellen Kräfte zu beteiligen. Auch wenn sich hundert Euro pro Jahr erträglich anhören, gibt es genug Lebenskünstler und Hacker, für die dieser Zehner im Monat einen bedeutenden Einschnitt bedeutet.

Dass wir trotzdem mit einem konkurrenzlos fairen Eintritt von rund hundert Euro für vier Tage Konferenz hinkommen, liegt an der beeindruckenden, sich selbst organisierenden freiwilligen Arbeit der inzwischen tausenden Helfer. Und diese sind dazu natürlich nicht für jede beliebige Veranstaltung bereit, sondern spenden ihre Zeit und Energie einer Community, der sie gern angehören. Niemand mag es aber, ausgenutzt zu werden. Unser Experiment funktioniert nur deshalb so gut, weil wir seit Jahren offensiv vorleben, und auch sozial kontrollieren, dass dieses ehrenamtliche, unbezahlte Engagement vieler nicht von einzelnen anderen monetarisiert wird. Denn in dem Moment, wo Zweifel aufkommen, ob die Orga Entscheidungen trifft, um sich selber zu bereichern, oder wenn geduldet wird, dass sich jemand innerhalb der Veranstaltung oder am Namen bereichern möchte – da liegt ja schließlich buchstäblich das Geld auf der Straße – , bricht die einzigartige Kultur des nicht-kommerziellen Raums zusammen.

Nun ist es so, dass auch die Menge Freizeit, die ein Einzelner in sein Ehrenamt (und als solches sehen wir den Beitrag zu den C3) investieren kann, je nach Hintergrund schwankt. Alleine zu den Orga-Treffen aus der Bundesrepublik anzureisen, ist zeitlich und finanziell anstrengend und wird daher von uns gefördert. Einige Menschen werden von den Mechanismen der "hochflexiblen" Arbeitswelt täglich von 7-17 Uhr plus Anfahrt ausgelaugt, haben familiäre Verpflichtungen und können sich vielleicht nur an Wochenenden voll einbringen, andere hingegen haben hochspezialisierte Jobs, kommen mit moderatem Zeiteinsatz finanziell gut über die Runden und können daher mehr oder regelmäßiger Energie in unser gemeinsames Projekt stecken.

Und hier liegt die größte Gefahr für das Gerechtigkeitsempfinden: Wer seine Resourcen überschätzt (und das ist nicht als Vorwurf an die Freiwilligen zu verstehen) und sich in unserer Szene in einem Maße einbringt, wie es ihnen andere mit zeitflexibleren Umständen vorleben, kann schnell an die Grenzen seiner Möglichkeiten kommen. Ich habe es in meinem Umfeld mehrfach gesehen, dass sich gerade in Jahren mit Congress- und Camp-Vorbereitung Freunde Hals über Kopf in den Orgatrubel gestürzt haben statt erwerbszuarbeiten, um dann am Ende des Jahres überrascht auf ihren Kontoauszug zu starren. Mir selber ist es passiert, dass ich nach einem Campsommer mit den über's Jahr mental beiseitesortierten Steuerforderungen konfrontiert wurde und dem Vollzieher Dinge erklären musste.

Daher denke ich, dass die Szene einen offensiven Umgang mit Freunden braucht, die dabei sind, sich selbst zu verheizen. Es ist total cool, wenn sich jeder im Rahmen seiner Möglichkeiten zu 100 % einbringt – eventuell mit koordinierten und an anderer Stelle wieder aufgefangenen 110 %. Nicht cool ist, wenn wir als Community einige Teilnehmer erst nach einer Phase der Anstrengungen über ihrem Limit auflesen, wenn sie sich verzweifelt nach einem Lebensunterhalt oder gar einem Schuldenabbauplan umsehen müssen. Der naheliegendste – weil vordergründig gerechte – Weg ist natürlich, die Community mit Verweis auf die Ursachen der Klemme zu aktivieren und mit Crowdfunding oder einem Spendenhut das Schlimmste aufzufangen. Die Hilfsbereitschaft in der Community gibt dies meist auch her.

Problematisch sind hier aber zwei Dinge: Wenn aus einer kurzfristigen Hilfe in einer Notsituation ein Anspruch extrapoliert wird, landen wir ziemlich schnell bei der Diskussion, ab wann diese teils selbstverschuldeten Umstände keine Hilfe mehr rechtfertigen, oder anders, wie man schon im Vorfeld freiwillige Mithilfe am Projekt zurückweist, bei der abzusehen ist, dass sich der Teilnehmer in eine solche Abhängigkeit begibt.

Denn wenn die ersten anfangen, ihre Existenz – wenn auch teilweise – an den Erfolg der Community zu hängen, braucht es für die Sicherstellung ihrer Existenz Mittel. Und wenn es Mittel zu verteilen gibt, wird jeder seinen Beitrag mit dem Beitrag dieser anderen vergleichen – nicht mehr seine Möglichkeiten mit denen der anderen – und eine entsprechende Vergütung für sich einfordern. Es bräuchte plötzlich viel mehr Geld und ein striktes Controlling für die zu verteilenden Mittel. Und wenn Teilnehmer dieselben Aufgaben unbezahlt erledigen wie vergütete Mit-Teilnehmer, kommt die berechtigte Frage nach dem Warum auf. Die Folge davon ist, dass Teilnehmer anfangen, ihre Beteiligung zu überdenken und zurückzufahren.

Dieser dem Congress-Gedanken diametral stehende Gegenentwurf – eine Annäherung an so etwas wie reale Personalkosten – würde eine Spirale von zwangsweise darauffolgenden Eintrittspreis-Erhöhungen nach sich ziehen oder schlimmer noch: den Einmarsch von gezielter Werbung, was einem Ende der Unabhängigkeit und Glaubwürdigkeit des Kulturkreises gleichkäme. Bis heute zeichnet sich die ganze Veranstaltung durch eine erfrischende Freiheit von Werbemüll aus – und wir wollen das so behalten. Und an den Preisen deutlich zu drehen, würde wiederum einen Ausschluss von Schwächeren nach sich ziehen – für uns ebenso inakzeptabel.

Zweitens finde ich bedenklich, dass die Möglichkeiten, die Community zu aktivieren, stark von der Sichtbarkeit (oder Reichweite oder Vernetzung) des Betroffenen abhängt. Im Konkreten: Wenn ein Teilnehmer als Lagerverwalter im LOC nach dem Abbau vor dem Nichts steht, hat er eine viel kleinere Plattform als beispielsweise ich oder bestimmte Teams mit einer starken Außen- oder Innenwirkung (think Podcaster, c3nav, Heralde). Dieser privilegierten Position müssen sich die sichtbaren Helfer bewusst werden, bevor sie diese von uns allen hergestellte Reichweite benutzen, um einen gefühlt gerechtfertigten Ausgleich für ihre Arbeit zu fordern.

Und wir als Community müssen uns der Aufgabe stellen, offen über Selbstausbeutung zu sprechen, Mithilfe-Angebote kritisch nach der individuellen Nachhaltigkeit hinterfragen und im Zweifel zurückzuweisen.

TLS certificates, not so long ago still a gold mine for shady “trust” resellers, have become a commodity, since Let’s encrypt made it their mission to provide everyone with domain-validated certificates to secure their connections. There’s a plethora of useful tools to keep your certs up-to-date. I for my part favour the bash-only dehydrated and even wrote a tiny guide how to get it running on FreeBSD using privilege separation (i.e. not as root).

Now all was well and I deployed this everywhere until I stumbled over a project where users could create their own team-sites on demand, having their own subdomain. But because acme – the protocol behind Let’s encrypt – did not support wild card certs, I would (at least in theory) have created a different cert for each of these domains, or at least have their sub domain added to the SubjAltName list of the web server’s cert. Which is what I grudgingly did for a while: Identify the most active team sites and manually add them to the domain name list for my LE certs.

You can imagine how glad I was when I heard that acme v2 added support for wild card certs. Until I noticed that they require a new authentication method over DNS to provide them. What the hell were they smoking? In order to renew your wild card cert every 90 days, you would need to allow unattended updates to your name server from the server taking care of the renewals. To understand, what a stupid idea the is, look no further than at the proliferation of plugins of varying software quality now scripting DNS service updates for dehydrated.

In every remotely sane setup you would separate the services so that your web server wouldn’t need to know about its name server, let alone have access and credentials to update it. With the old acme http-01 protocol, the instance handling nearly every aspect of TLS anyway – in my case nginx – would be the only service involved, allowing for some neat separation: Only the .well-known directory would need to have a letsencrypt specific ownership.

A much less intrusive solution would have been to just require a static TXT record in your zone, stating that wild card certs are okay in principle (i.e. _acme.example.com TXT "wild card enable") and then have the acme server use the old http-01 mechanism to fetch challenge tokens from one or multiple random sub domains. This should be more than enough to proof that you control wild card dns.

However now we’re stuck with the less than optimal solution and I still needed a wild card cert. Since I do not directly control the name server, I needed to ask for a delegation. That meant that I would actually have to run a name server for this zone. On my web server. Great!

After shopping around for a while I’ve found tinydns, the authoritative name server from the djbdns bundle, to still be the least complicated server around. It sports its own very simple DNS record description language (that’s important, if you want to update and create it from simple shell scripts), is really, REALLY tiny and has an excellent security and performance track record. It basically pre-compiles every conceivable DNS response, stores it in an efficient constant single file database which can be atomically replaced while the server is running, meaning I didn’t have to meddle with permission to send signals to reload the zones.

Unfortunately, Dan Bernstein, tinydns’ author really likes you to run services the way he considers most convenient, using the daemon tools package sporting a steep learning curve. Since tinydns comes as a simple stand alone server, I just wrote a FreeBSD rc-script to start it as the FreeBSD gods have intended services to be started. Just place this file as /usr/local/etc/rc.d/tinydns, set execute (+x) permissions and enable it in rc.conf.

#!/bin/sh

#
# PROVIDES: tinydns
# REQUIRE: DAEMON cleanvar
# BEFORE: LOGIN
# KEYWORD: shutdown
#
# Add the following to /etc/rc.conf to enable this service:
#
# tinydns_enable="YES"
#
# tinydns_ip
# tinydns_root

. /etc/rc.subr

name=tinydns
rcvar=tinydns_enable
command=/usr/local/bin/tinydns

start_cmd=tinydns_start
pidfile=/var/run/tinydns

load_rc_config $name

: ${tinydns_enable:=no}
: ${tinydns_ip:=0.0.0.0}
: ${tinydns_root:=/etc/tinydns/root}

tinydns_start() {
    IP=${tinydns_ip} ROOT=${tinydns_root} UID=bind GID=bind ${command} >/dev/null 2>/dev/null &
    echo $! > ${pidfile}
}

run_rc_command "$1"

I placed my compiled zone file in /etc/tinydns/root/data.cdb, so the paths just work. My uncompiled zone file (i.e. source at /etc/tinydns/root/data) looks like this:

Zservice.example.com.:ns.service.example.com.:erdgeist@ccc.de.::86400:7200:604800:43200:43200
&service.example.com.::ns.service.example.com.:43200

+ns.service.example.com.:10.1.1.1:43200

@service.example.com.::mail.service.example.com.:50:43200
@*.service.example.com::mail.service.example.com.:50:43200

+service.example.com.:10.1.1.2:43200
+*.service.example.com.:10.1.1.2:43200

For AAAA records you might pre-compile an answer here or use Fefes tindydns IPv6 patches for a simpler syntax.

Once the file is there, you compile it using tinydns-data (within the /etc/tinydns/root/ directory. Yay!). Best is to also give it to your letsencrypt user right now.

cd /etc/tinydns/root
tinydns-data > data.cdb
chown -R letsencrypt /etc/tinydns/root

Finally, you need to add the actual code to your hooks. I just modified the file hook.sh in /usr/local/etc/dehydrated/ to read in the deploy_challenge() { function

printf "\'_acme-challenge.%s:%s:120\n" ${DOMAIN} ${TOKEN_VALUE} >> /etc/tinydns/root/data
cd /etc/tinydns/root/
tinydns-data > /etc/tinydns/root/data.cdb

and for later cleanup in the clean_challenge() { function I added

sed -E -i '' '/_acme-challenge/d' /etc/tinydns/root/data
cd /etc/tinydns/root/
tinydns-data > /etc/tinydns/root/data.cdb

After all is set and done, you need to change the default scheme to dns-01 in your dehydrated config (which is kind of silly, because all other domains on that nginx host require http-01 auth, but maybe there’ll be a patch to dehydrated to support multiple challenge types in the same config). I just changed the config line for CHALLENGETYPE line to read CHALLENGETYPE="dns-01" in my /usr/local/etc/dehydrated/config. I also enabled the HOOK=/usr/local/etc/dehydrated/hook.sh line.

Then you can just run

su letsencrypt
dehydrated -c

and enjoy your wild card certs.

Nachdem ich jetzt zwei Jahre mit meinem Elektroroller [1] quasi täglich [2] durch die Stadt gleite, ist es Zeit für eine Retrospektive. Ich habe lange überlegt, ob ich meine Erfahrungen mit meinem speziellen Modell so allgemeingültig zusammenfassen kann. Zudem bin ich kein erfahrener Produkttester und würde ungern unnötig Werbung oder Schmäh für einen Anbieter verbreiten. Da ich aber wieder an jeder zweiten Kreuzung von nebenan wartenden Leihroller-Fahrern über mein Moped ausgefragt werde, kann ich auch mal allen eine Zusammenfassung dalassen: Ich habe mir vor zwei Jahren einen Unu-Roller mit einem 3kW-Motor gekauft und einen zweiten Akku dazu.

Die wichtigsten Kenndaten [3]: nominelle Reichweite mit beiden Akkus 100 km, realistisch: 80 km. Die letzten fünf Kilometer fährt man nur noch 20 km/h. Ladegeschwindigkeit (pro Akku) sind 10 km/h, zweites Ladegerät zu kaufen lohnt, Y-Kaltgeräte-Adapter für die Reise auch. Akku wiegt so 8-9 kg, kriegt man mit Tragegurt (ist bei) auch mal zwei Treppen hoch. Moped wiegt weniger als ich.

Zuallererst: Im realen Leben ist die Reichweitenangst vollständig unbegründet. In den letzten zwei Jahren Regulärbetrieb bin ich genau einmal liegengeblieben. Hört sich erstmal doof an, heißt aber nur, dass man seinen Akku rausholen per ÖPNV heimbringen, aufladen und zurückbringen muss. Mit meinem Verbrenner bin ich mehrmals im Jahr leergefahren und musste dann tatsächlich schieben oder Kanister organisieren, befüllen und mich mit dem Taxifahrer streiten, die stinkende Plastebox per Kurzstrecke mitnehmen zu dürfen.

Das Aufladen geht durch einen ganz einfachen Effekt in die tägliche Routine über: Zwischen 75 % und 100 % Akkuladung pumpt der Motor-Controller an der Kreuzung nochmal extra Strom in den Motor, darunter verhält er sich konservativer. Soll heißen: Je voller der Akku, desto mehr Fahrvergnügen an der Ampel. Das konditioniert von ganz alleine darauf, den Akku zum Laden mit reinzunehmen. Für längere Strecken innerhalb der Stadt nehme ich daher immer zwei volle Akkus mit, wenn eins dicke reichen würde.

Für einen Trip in die Pampa sollte man sich im Umkreis von 75 km ein Restaurant suchen, in dem man seine Akkus aufladen darf. In zwei Stunden bekommt man in der Summe rund 40 km drauf. Der Rest ist Mathematik. Wenn alles gut geht. Bei meinem ersten Testtrip ging leider nicht alles gut. Das Hinterrad hatte aufgrund einer kleinen Delle in der Felge subtilen Luftverlust. Und platte Reifen sind der natürliche Feind der Reichweite. Das kurz vor Bernau festzustellen, brachte mir die ganze Tourplanung durcheinander [4] und machte, dass ich am Ende doch noch mit der U-Bahn den Akku nach hause fahren musste.

Das Problem artete sogar noch aus, und das lag absurderweise daran, dass ich mein Moped ganz leise wollte. Die meisten E-Roller kommen mit einem unangenehmen Plaste-Surren daher. Da ich mich nach zwei Jahrzehnten Rasselmotor Fahren darauf gefreut hatte, majestätisch durch die Nacht zu gleiten, sind diese Roller ein No-go für mich. Das Geräusch stammt (soweit ich das beobachten konnte) vom Riemenantrieb – der Motor ist unter dem Sitz und die Kraft muss auf's Hinterrad. Die Unus haben hingegen einen Nabenmotor direkt im Rad eingebaut und produzieren außer dem Reifen-Fahrbahn-Geräusch [5] keinen Ton. Leider hat sich Unu entschieden, die Felge fest auf dem Motor zu verschweißen. In der Werkstatt wollten sie daher für die defekte Felge (eBay-Preis gebraucht 'n Zehner) ungefähr den Neupreis des Motors haben. Nach einigem Grübeln kam dann die Werkstatt darauf, die Felge geradezuhämmern und einen Schlauch einzuziehen. Muss man wissen. Seitdem hatte ich keine überraschenden Reichweitenprobleme mehr.

Unüberraschend kommen die nur im Winter. Kalte Akkus sind zickig – so ab 0 Grad. Nehmt die rein. Eiskalte Akkus machen, dass der Motor kaum noch anzieht und die Reichweite einbricht – wenn man überhaupt noch Lust hat, die auszufahren. Ansonsten ist das Moped auch im Winterbetrieb tauglich. So richtig meterhohen Schnee zum Testen hatten wir leider nicht. Obwohl ich diesen Winter nur schwer testen konnte. Das lag daran, dass man mit dem Unu super einkaufen fahren kann.

Im Fach unter dem Sitz passen zwei Akkus nebeneinander rein. Wenn man eins rausnimmt, passt ein kompletter Rewe-Einkaufskorb [6] rein. Und dann ist zwischen den Beinen immer noch Platz. Bei einem späten Einkauf – meine Kaufhalle hat 24/6 auf – habe ich in einer Novembernacht das volle Einkaufsprogramm mitgemacht und mir noch eine TKP [7] in der linken Hand balanciert. Wie das dann halt so ist, habe ich elegant mit dem Knie den Pizzakarton unglücklich gegen das Lenkrad geschoben, das mich prompt gegen einen fies platzierten Poller lenkte. [8] Die Geschichte des Pärchens, das mir beim Zusammensammeln von Verkleidungsteilen und Einkäufen half, im Tausch gegen die Benutzung meines Mobiltelefons, würde noch einen ganzen Blogpost füllen. Ein paar strukturell wichtige Teile wie Blinker und Fußstellflächen waren ab, daher musste ich zur Werkstatt und wurde dann von den Freuden deutsch-chinesischer Handelsfreundschaft überrascht:

Unu wechselte Mitte 2017 den Zulieferer für die Ersatzteile, der wiederum eine ganz eigene Idee von Vorratshaltung hatte. Als bei dem die Bestellungen für die Karosserieteile eingingen, fingen die erst an, die Produktion dafür binnen Monatsfrist zu planen. Kurzum: nach einem Vierteljahr hatte ich meinen Roller wieder. Zum Glück war ich ein gut Stück dieser Zeit eh nicht im Lande. Bisschen peinlich ist es trotzdem, wenn sie jetzt auch – nach eigenen Beteuerungen – die Lieferkette wieder im Griff haben.

Eins noch: Das erste, zu dem mich die mir zugeteilte Bosch-Vertragswerkstatt zu meinem Roller fragte, war der Zustand der Spiegel. Und tatsächlich, so ziemlich alles an den Spiegeln wirkt wacklig: Allein weil das Moped so leicht ist, zittern die Spiegel schon auf asphaltierten Straßen ganz verwirrend, auf Kopfsteinpflaster braucht man sie gar nicht zu benutzen versuchen. Die Konterschrauben unten an den Spiegel muss man mit echtem Werkzeug nachziehen, sie lösen sich sehr gern von allein. Unu legt aus Verlegenheit schon den passenden 15-er Schlüssel zum Handbuch bei. Die kleinen Blinker/Licht-Konsolen, auf denen sie draufstecken, geben auch irgendwann nach, drehen sich dann so leicht nach vorne und hinten und wurden bei mir schon drei mal gewechselt. Aber dafür sind die Spiegel schick!

Kurzum, wie das so ist als early adopter einer hippen Technologie: Man macht alle Kinderkrankheiten einmal mit. Zwischendurch war die Frustration durchaus da, mich auch nach anderen Anbietern umzuschauen. [9] Meine Probleme sind aber fürs erste gelöst, die Lösungen für andere Betroffene runterzuschreiben, war auch Motivation für diesen Text. Ich weiß jetzt nach zwei Jahren ziemlich genau, woran ich bin, meine Akkus tun immer noch und fühlen sich nach zwei weiteren Jahren Stadtbetrieb an. Und auf ein neues Akku- oder Ladesystem umzusteigen, ist mit impliziten Kosten verbunden, zudem würde ich bei anderen Herstellern eben auch nochmal alle Kinderkrankheiten mitnehmen und die wären wiederum neu und überraschend. Daher bleibe ich erstmal bei meinem Model.

Since letsencrypt has made it easy to actually get the little green lock icon in all the browser, I've deployed it nearly everwhere, where reloading keys every three months is not an issue (looking at you, dovecot and ejabberd). When using FreeBSD, the security/dehydrated port has made things smooth enough for me not to be to afraid to execute it from a periodic script: It only requires bash and curl and can be executed as non-privileged user.

So here's a step by step instruction how to properly set it up:

1. Install the port/package:

   pkg install dehydrated

2. Create the letsencrypt user, for example:

   echo letsencrypt::::::::/bin/sh: | adduser -w random -f -

3. Create your config copy /usr/local/etc/dehydrated/config by duplicating the example:

   cp /usr/local/etc/dehydrated/config.example /usr/local/etc/dehydrated/config

4. Edit /usr/local/etc/dehydrated/config so it reads CONTACT_EMAIL=me@foo.com. (Don't forget to remove the # at the line's start.)

5. By default, dehydrated's work dir is /usr/local/etc/dehydrated. I do not like that, because the letsencrypt user needs write access to that directory for its housekeeping files and could modify things like the config and – worse – the deploy.sh script. So I create a different work dir:

   mkdir /var/dehydrated
   chown -R letsencrypt /var/dehydrated

6. And then I change /usr/local/etc/dehydrated/config to read BASEDIR=/var/dehydrated. (Again, don't forget to un-comment the line.)

7. The web directory for challenge replies defaults to /usr/local/www/dehydrated. It needs to be writable by letsencrypt user:

   chown -R letsencrypt /usr/local/www/dehydrated

8. Configure domains.txt:

   echo 'foo.com www.foo.com' > /var/dehydrated/domains.txt

9. I want dehydrated to be run weekly by periodic, I also setup the deploy script (see below). I put those lines in /etc/periodic.conf:

   weekly_dehydrated_enable="YES"
   weekly_dehydrated_user="letsencrypt"
   weekly_dehydrated_deployscript="/usr/local/etc/dehydrated/deploy.sh"

10. The deploy.sh script needs to be setup, it will tell all frontends to reload certs. For my nginx installations, it is enough to put this into /usr/local/etc/dehydrated/deploy.sh:

    #!/bin/sh
    
    /usr/sbin/service nginx reload

11. Don't forget execute permissions:

    chmod +x /usr/local/etc/dehydrated/deploy.sh

12. Finally, for nginx to correctly route requests to the web dir, add this to your server block. Don't forget to enable listen 80:

    location /.well-known/acme-challenge/ {
        alias /usr/local/www/dehydrated/;
    }

13. Before running dehydrated for the first time, you should reload your nginx config. This also is an implicit check for correct permissions on deploy.sh ;):

    /usr/local/etc/dehydrated/deploy.sh

14. Run dehydrated to set up and agree to terms and conditions:

    su letsencrypt -c 'dehydrated --register --accept-terms'

15. Then run it again to actually do a challenge/response and generate certs:

    su letsencrypt -c 'dehydrated -c'

16. If everything went fine, tell nginx to use the new certs in your server block. Don't forget to enable listen 443 ssl:

    ssl_certificate /var/dehydrated/certs/www.foo.com/fullchain.pem;
    ssl_certificate_key /var/dehydrated/certs/www.foo.com/privkey.pem;

17. Make nginx use your new certs:

    /usr/local/etc/dehydrated/deploy.sh

You should be able to see your web site with a little green lock icon now, carrying a letsencrypt cert.

In order to verify that all your setups have been setup correctly, I wrote a script that checks them all:

HOSTS="mail.foo.com:25:smtp mail.foo.com:imaps www.foo.com jabber.foo.com:5232"
unset LANG LC_CTYPE LC_MESSAGES LC_TIME

for host in $HOSTS; do
  unset starttls
  [ ${host%:*} = ${host} ] && host=${host}.:443
  if [ ${host%*:*:*} != ${host} ]; then
    starttls="-starttls ${host#*:*:} "
    host=${host%:*}
  fi
  echo $host ${starttls}
  notafter=$( yes q | openssl s_client -servername ${host} -connect ${host} ${starttls} 2>/dev/null | openssl x509 -noout -enddate | grep ^notAfter= | cut -d = -f 2- )
  secs=$( date -j -f "%b %d %T %Y %Z" "${notafter}" +%s )
  now=$( date +%s )
  printf "% 4d days .. until %s\n" $(( (secs - now) / 86400 )) "${notafter}"
done

Ever since poudriere was published, I felt the obligation to run a public repository with packages tuned to my needs (i.e. without X11, without Java, with a certain TLS library as default, etc). But considering this tool's complexity, I never felt comfortable running it on a production system's host. So naturally I've been looking for a way to jail it away and only 2 years after this tutorial outlined how that works, I managed to acutally try it out. Long story short: This guide kinda works and I got poudriere running in a jail. But I want the jail to automatically start up, get the correct dataset attached and receive all permissions needed to do zfs stuff and creating its own builder jails, in other words: I wanted to embed it as an ezjail.

Now, turns out, that's actually not so hard: If you're running ezjail with zfs enabled, you first create the dataset for poudriere to work on:

zfs create -o jailed=on tank/poudriere

then you just create your poudriere jail, making sure to pass it an ::1 IP address:

ezjail-admin create -c zfs poudriere 127.0.0.1,lo0|::1

and then manually edit the two config lines in /usr/local/etc/ezjail/poudriere to read:

export jail_poudriere_parameters="children.max=10 allow.mount=1 allow.mount.devfs=1 allow.mount.procfs=1 allow.mount.zfs=1 allow.mount.nullfs=1 allow.raw_sockets=1 allow.socket_af=1 allow.sysvipc=1 allow.chflags=1 enforce_statfs=1"
export jail_poudriere_zfs_datasets="tank/poudriere"

dont forget that this jail needs a resolv.conf, too and now you can just:

ezjail-admin console -f poudriere

and follow the FreeBSD handbook section on poudriere to get your poudriere jobs running. Since I wanted the web server jail to serve the packages, I exposed them in /etc/fstab.www_domain.com by adding a line:

/usr/jails/poudriere/tank/poudriere/data/packages /usr/jails/www.domain.com/packages nullfs ro 0 0

and after an ezjail-admin restart www.domain.com, you should be able to use the packages built by adding a /usr/local/etc/pkg/repos/www.conf of:

www: {
  url: "file:///packages/103amd64-local-workstation/",
  enabled: yes
}

Update: Should you be missing the file systems inside your poudriere jail, make sure to mount them in your periodic script that runs poudriere (using zfs mount -a, before running poudriere), or take a look at the thread on the ezjail mailing list regarding rc.d/zfs not finding the dataset when it's run.