Let’s Encrypt für nginx unter Debian 8 einrichten

Vorwort

Wie man unschwer erkennen kann, ist wandpapier.de nun nicht mehr über http, sondern über https erreichbar. Hintergrund ist die Umstellung des nginx-Servers auf https mit Hilfe von certbot-auto der EFF. Ich werde euch dabei meine Vorgehensweise unter Debian 8 beschreiben. Vergesst aber bitte nicht, dass ihr diese Anleitung auf eigenes Risiko nutzt und ich keine Garantie für irgendetwas übernehme was bei euch nicht funktioniert und schief läuft!

Voraussetzungen

  • Zugriff auf den Server
  • Zugriff auf die Konfigurationsdateien von nginx

Nun die Schritte

certbot-auto einrichten

Damit habt ihr ein überall ausführbares certbot-auto. Man kann certbot auch über die jessie-Backports bekommen. Das sieht dann so aus.

.well-known-Ordner einrichten

Extra einrichten brauch man da eigentlich nichts. Man sollte aber nginx sagen, wie darauf von außen zugegriffen werden kann. Das geschieht im server-Block der nginx-Konfiguration. Darin sollte folgendes eingetragen werden.

Solltet ihr wie ich andere location-Einträge haben, so kann es dabei zu Problemen kommen, vor allem wenn diese Einträge per Regex gesteuert werden. So habe ich zum Beispiel für statische Dateien einen Eintrag

Dann solltet ihr nach dem letzten location-Eintrag im server-Block folgendes in eurer Konfiguration stehen haben.

Nun prüft ihr eure nginx-Konfiguration mit  nginx -t auf Fehler. Diese sollte im Bestfall keine Fehler werfen. Falls doch, schaut wo der Fehler genau liegt und korrigiert diesen. Danach startet ihr per  service nginx restart nginx neu, damit die Einstellungen übernommen werden.

Zertifikat anlegen

Kommen wir zum eigentlichen Anlegen eines Zertifikates. Wer eine Begleitung mit Oberfläche durch alle Schritte benötigt, kann sich das Zertifikat per certbot-auto certonly erstellen lassen. Wer es alles über die Shell machen möchtekann dies wie folgt tun.

Damit nur das neue Zertifikat herunter geladen werden kann und icht noch irgendwas an irgendwelchen Einstellungen geändert wird ist  certonly zuständig. Das verwendete Authentikatorplugin webroot wird mit  -a webroot festgelegt. Das legt in den .well-known Ordner im Root-Verzeichnis eurer unter eurer Domain für letsencrypt prüfbare Dateien an. Daher auch die Freigabe dieses Ordners in nginx. Mit  --webroot-path gebt ihr den Pfad auf eurem System an, welcher dem Root unter eurer Domain entspricht. Das sind meist Ordner mit dem Namen public, httpdocs oder ähnliches, je nachdem was ihr bei euch eingerichtet habt. Der Parameter  --renew-by-default  wird dazu genutzt, dass ein bereits vorhandenes Zertifikat erneuert wird. Und das unabhängig davon, ob es abgelaufen ist oder nicht.  --text gibt alles von certbot-auto auf der Kommandozeile aus statt in der standardmäßig genutzten Oberfläche. Die Nutzungsbedingungen akzeptiert ihr mit dem Parameter  --agree-tos. Die zu zertifizierenden Domains werden mit  -d angegeben. Dabei können wie auch im Beispiel mehrere angegeben werden.

Nun solltet ihr bei einer fehlerfreien Konfiguration von nginx und certbot-auto etwa folgende Ausgabe erhalten.

Damit liegen nun alle notwendigen Zertifikatsdateien im Ordner  /etc/letsencrypt/live/deineDomain.de/. Das ist ein Ordner mit Symlinks zu den aktuellen Dateien, welche im Original unter  /etc/letsencrypt/archive/deineDomain.de/.

Es werden insgesamt vier Dateien erstellt. cert.pem  ist das Domain-Zertifikat, chain.pem  ist das Let’s encrypt chain Zertifikat, fullchain.pem  sind beide nochmal zusammen in einer Datei und privkey.pem  ist der Private Key zum Zertifikat.

Um das ganze noch weiter abzusichern erstellt man sich eine Diffie-Hellmann-Gruppe per sudo openssl dhparam -out /etc/ssl/certs/dhparam.pem 2048. Je nach Rechenleistung des Servers kann das bis zu einer Minute dauern bis die Datei  /etc/ssl/certs/dhparam.pem erstellt wurde. Diese benötigen wir später noch für nginx.

nginx auf https umstellen

Nachdem wir die notwendigen Dateien erhalten haben machen wir uns daran nginx auf https umzustellen. Dazu sucht ihr euch wieder den entsprechenden server-Block in eurer nginx-Konfiguration. Ihr sucht euch am besten die Stelle heraus, an der der Port geschrieben steht. Das sollte  listen 80; sein. Diese Zeile könnt ihr löschen und fügt folgende Zeilen ein.

Damit funktioniert das Ganze bereits. Um https noch weiter abzusichern kann man verschiedene Protokolle, Ciphers und natürlich auch die oben erstellte Diffie-Hellmann-Gruppe einbinden.

Der Ablauf der SSL-Sitzung erfolgt nach einem Tag mit dem Eintrag  ssl_session_timeout 1d;. Es wird per ssl_session_cache shared:SSL:50m; über alle nginx-Worker ein gemeinsamer SSL-Cache genutzt, der 50 MB groß ist. Das reicht laut nginx-Dokumentation für etwa 20.000 SSL-Sitzungen. Um nicht mit jedem Request den Status des Zertifikats abzufragen zu müssen wird  ssl_stapling on; genutzt. Die Verifikation dessen wird mit  ssl_stapling_verify on; eingeschalten. Damit der Browser sich merkt, dass die von nginx ausgelieferte Seite per https erreichbar ist und die Zertifikate nutzt gibt man  add_header Strict-Transport-Security max-age=2628000; mit. Dabei legt man mit max-age die Dauer in Sekunden fest, für die sich der Browser das merkt. Im Fall oben wäre das die Dauer von einem Monat.

Damit wären wir mit nginx fertig und nach dem Neustart von nginx per  service nginx restart ist eure Seite per https erreichbar.

Wollt ihr eine Umleitung von http auf https einrichten wollen, solltet ihr euch einen zweiten server-Block anlegen mit folgendem Inhalt.

Erneuerung einrichten

Leider sind die Zertifikate von Let’s encrypt nur drei Monate gültig. Da man aber das obige Prozedere nicht jedes Mal aufs Neue durcharbeiten möchte, gibt es mit  certbot-auto renew eine Möglichkeit das kürzer zur gestalten. Damit werden vorhandene Zertifikate erneuert, sofern deren Ablaufdatum unter 30 Tage in der Zukunft liegen. Und damit man auch das nicht händig machen muss, legt man sich einen Cronjob per crontab -e  an.

Damit wird das Zertifikat jeden Montag um 01:15 erneuert und nginx um 01:20 neu gestartet. Somit hat man jederzeit ein aktuelles Zertifikat.

Nun viel Vergnügen und Erfolg mit eurer ssl-gesicherten und per https erreichbaren Seite.

Quellen

Ting Stift unter Linux mit Büchern befüllen

Mein großer Sohnemann hat einen TING-Stift. Der ähnelt im Prinzip einem TipToi. Nur mit dem kleinen Unterschied, dass man nicht an einen Verlag gebunden ist, sondern viele Verlage Bücher und Materialien für TING-Stifte publizieren. Das hat den Hintergrund, dass die Platform dafür jedem Verlag zur Verfügung gestellt werden kann und die Bücher überall gedruckt werden können. Darüber hinaus gibt es ein paar ergonomische Unterschiede, wie Größe, Gewicht und Handlichkeit. Zudem arbeitet der TING-Stift mit einem wiederaufladbarer Akku. Er ermöglicht die Speicherung der Buchdaten als MP3 und ist als normaler USB-Stick nutzbar.

Ting Stift
TINGsmart Stift

Wie funktioniert der Stift? Das ist recht einfach. In der Spitze befindet sich eine Infrarot-LED und eine rudimentäre Kamera, ähnlich der Sensoren bei Mäusen. Dieser Sensor liest nun beim Antippen im TING-Buch die kleinen Codes aus, die über die ganzen Seiten verteilt sind. Das sind so leicht hellgraue Punkte mit verschiedenen Mustern. Man erkennt diese beim ganz genauen Hinsehen. Beim normalen Lesen fallen diese sogut wie gar nicht auf. Zum Laden einer Buchdatei, tippt man auf der Umschlagseite oder auf einer der ersten Seiten das entsprechende Feld dafür an. Nach dem Auslesen eines Codes im Buch sucht sich der Stift die entsprechende stelle in der Buchdatei und spielt diese Passage ab. Die Buchdateien liegen auf der größeren Partition des Stiftes. Leider erkennt der Stift nicht selbst, in welchem Buch er sich befindet, sondern man muss immer zu Beginn eines Buches auf das TING-Feld tippen.

Wie dem auch sei. Ich beziehe mich hier auf den TINGsmart, also den TING-Stift der zweiten Generation ab 2013. Den TING-Stift kann man direkt unter Windows beziehungsweiße MAC OS nutzen. Per USB angeschlossen, öffnet sich die TING-Software und holt die geforderten Bücher und Buchupdates. Dort finden sich mehr oder weniger schöne Oberflächen, die auf der kleineren der beiden Partitionen des Stiftes liegen. Für Linux gibt es so etwas leider nicht.

Ich habe, angelehnt an verschiedene Beiträge auf hotspace.deforum.ubuntuusers.de und uli.popps.org, ein Script für die Shell geschrieben. Das Script prüft die TBD-Datei, welche vom Stift selbst mit den IDs der nicht vorhandenen Bücher befüllt wird. Es liest daraus die IDs der herunter zu ladenden Bücher heraus. Beachtet wird dabei auch, ob es ein extra Script für das Buch gibt oder nicht. Das wird zum Beispiel für die Rätsel und Spiele in den Büchern genutzt. Alle Dateien vom Server werden dann direkt auf den Stift geladen. Ihr müsst lediglich den Ordner angeben, in dem sich der $ting-Ordner befindet. Den Rest erledigt das Script für euch.

Ihr findet das Shell-Script auf GitHub. Es ist die darin befindliche Datei linux.sh. Diese könnt ihr von überall aus, die entsprechenden Rechte vorausgesetzt, ausführen. Ich gebe keine Garantie oder Gewähr, dass dieses Script auf allen Linux-Distributionen oder Hardwareumgebungen lauffähig ist.

Duplikate finden unter Linux mit rmlint

Ihr kennt sicher das Problem, wenn man unzählige Bilder gemacht hat und diese irgendwo hin gespeichert hat. Hab ich früher auch so gemacht, daher habe ich nun gigabyteweise Duplikate rumliegen, weil ich für verschiedene Aufgaben immer eine neue Kopie angelegt habe. Diese stören mich inzwischen recht arg. Also hab ich Ausschau nach Scripten und gar Software gehalten, die mir diese Duplikate aufspürt, ohne dass ich hinterher noch viel Hin und Her kopieren muss. Am einfachsten geht das aus meiner Sicht mit rmlint, welches von Chris Pahl und Daniel Thomas entwickelt wird. Bekommen könnt ihr rmlint über die Paketverwaltung (für Arch-Linux im AUR) eurer Distribution oder direkt bei github.com/sahib/rmlint.

Ausgeführt wird es am einfachsten per rmlint in der Kommandozeile. Dabei berücksichtigt rmlint lediglich, dass es das erste angegebene Verzeichnis behalten soll und die ältesten Dateien. In Hinsicht auf falsche Zeitangaben der Dateien oder mögliche Dopplung durch gleiche Größe, etc. bietet es sich an weitere Parameter an rmlint anzuhängen. Ich habe einige Parameter probiert. Meine am meisten genutzte Zeile lautet dann  rmlint -pp -w -Spam. Wenn ich zwei Verzeichnisse direkt miteinander vergleichen will, weil ich genau weiß, wo Originaldateien liegen, dann nutze ich  rmlint -pp -w -Spam Duplikatverzeichniss // Originalverzeichnis.

Meine genutzten Parameter machen Folgendes. Und zwar -pp  vergleicht Dateien Byte für Byte. Das ist meiner Meinung nach zwar langsamer als Hashs zu vergleichen, aber eben auch etwas sicherer, dass nicht zufällig zwei unterschiedliche Dateien mit gleichem Hashwert als Dupletten erkannt werden und eine davon gar gelöscht wird.

Der Parameter -w zeigt einfach nur in der Konsole die Ausgabe farbig an, also Originale mit grünem ls  und Duplikate mit rotem rm .

Die Parameterkette -Spam bestimmt die Reihenfolge, in der Entscheidungen getroffen werden. -S  steht dabei für die Sortierkriterien. Ist der Pfad zweier Dateien identisch, was mit p  geprüft wird, wird zum nächsten übergegangen. Ist der Pfad nicht identisch, wird der erste gefundene beziehungsweise angegebene Pfad für das Original gehalten. Die Entscheidung a prüft auf alphabetischer Ebene. Unterscheiden sich zwei Dateien im gleichen Verzeichnis nur durch ein Zeichen im Namen, wird die Datei mit dem ersten alphabetischen Erscheinen als Original gewertet. Der Parameterwert m steht für die Prüfung auf das Dateidatum. So wird die ältere von zwei Dateien als Original angesehen.

Über den Anhang Duplikatverzeichniss // Originalverzeichnis nach den Parametern sage ich rmlint, sofern ich das bereits weiß, welches Verzeichnis Originaldateien enthält. Durch ständiges Arbeitskopien erstellen von einem Original bietet es sich an dieses Feature zu nutzen.

Ich habe also mit rmlint -pp -w -Spam Duplikatverzeichniss // Originalverzeichnis die für mich größtmögliche Trefferquote an Duplikaten von Originaldateien, wobei ich das Originalverzeichnis angeben kann und nach bestimmten Kriterien und letztlich Byte für Byte auf Duplikat geprüft werden kann.

Auf meinem NAS konnte ich nach jahrelanger Datensammelei von ca 920 GB Daten etwa 80 GB an Duplikaten ausmachen und löschen. Am häufigsten betrifft es Bilder, Musik und Videos. Es macht sich also schon bezahlt, wenn man mal so richtig ausmisten kann.

In diesem Sinne viel Spaß beim Aufräumen und Platz schaffen.

Seriellen Port unter Debian simulieren

Zurzeit arbeite ich an einem Schulprojekt zum Auslesen eines Messgerätes über den seriellen Port eines Rechners unter Windows per Java. Da ich selbst aber kein Windows mehr nutze und mein Notebook auch keinen seriellen Anschluss besitzt, muss ich mir unter Debian etwas einfallen lassen, damit ich diesen simulieren kann. Die Anforderung lag nun für mich darin unter Debian/Crunchbang auf /dev/ttyS0 (unter Windows ist das COM1) zuzugreifen und von diesem Gerät aus etwas für das Projekt auszulesen. Hier beschreibe ich kurz wie ich es mittels socat gelöst habe.
Continue reading “Seriellen Port unter Debian simulieren”

HDD-Benchmark für die bash, selbstgeschrieben

Auf Basis des Festplatten-Geschwindigkeitstests bei den Ubuntuusers.de habe ich ein Script geschrieben, welches das Testen der Schreibgeschwindigkeit vereinfacht. Grundlage ist dabei folgender Code

Es wird hierbei das Laufwerk getestet, wo man sich gerade befindet. Hier wird auch die Datei “tempfile” geschrieben. Achtet bitte darauf, dass vor dem Starten des Scriptes genügend Platz auf dem Datenträger vorhanden ist. Diese Datei hat in diesem Fall hier eine Größe von 1024 mal 1 MB. Es wird insgesamt 1024-mal komplett in diese Datei geschrieben. Man benötigt für diesen Durchlauf 1024 x 1024 x 1024 x 1024 Bytes Platz, also etwa 1,1 GB. Die Werte können durchaus angepasst werden. So kann man zum Beispiel für 256 MB die Werte bs=32M und count=8 angeben.

Die Schreibgeschwindigkeit per dd zu ‘messen’ ist natürlich auch abhängig von anderen Faktoren, wie Systemauslastung, Anwendungen, die ebenfalls auf die Platte zugreifen und natürlich das verwendete Dateisystem. Daher sollte man so einen Durchlauf mehrfach starten, damit man einen Durchschnittswert erhält, der repräsentativer als ein Einzelwert ist.

Das Ganze macht das von mir geschrieben bash-Script, wobei ihr beim Aufruf des Scriptes nur die gewünschte Menge an Daten angeben werden braucht. Es werden dabei Dateigrößen von 1, 2, 4, 8 und 16 MB durchgetestet und die Anzahl entsprechend angepasst.

Gibt man also  hddbench.sh 1024 an, so werden im ersten Teil fünf Durchläufe mit 1 MB großen Dateien gemacht, und zwar 1024 mal. Im zweiten Teil 512 mal 2MB große Dateien. Und so weiter. Das heißt, es laufen für eine Dateigröße immer 25 dd-Aufrufe ab. Es werden im Laufe des Scriptes alle Geschwindigkeiten zusammengerechnet und durch die Anzahl der Durchläufe geteilt. Et voilà. Ein relativ repräsentatives Ergebnis. Zwischendrin noch ein paar Echos, damit das Ganze etwas ansehnlicher ist. Continue reading “HDD-Benchmark für die bash, selbstgeschrieben”

Linux lässt sich nicht auf altem Notebook rebooten

Auf dem alten HP-Notebook Cnx9005 läuft seit etwa einer Woche #! (CrunchBang Linux). Leider hatte ich bisher immer das Problem, dass dieses nicht über die Konsole mit shutdown -r now rebootete, also einen Neustart vollzog. Das System ging die verschiedenen Runlevel durch und beendete dann mit [xxxxx] Restarting system den Dienst und startete nicht neu. Das musste ich per Hand dann machen. Fühlte sich jedes Mal so ähnlich wie bei Windows 95 an, wenn man den Computer jetzt ausschalten könne.

Nun haben Hermann und ich ein paar Tage lang mit der Konfiguration rumprobiert, sogar einen neueren Kernel kompiliert. Aber das Problem lies sich nicht beheben. Wir kamen dann auf die Idee, dass es mit ACPI zu tun hat. Dies war aber nur teilweise richtig. Wir änderten an der Datei /etc/default/grub noch ein wenig hin und her, änderten den acpi-Wert der Zeile GRUB_CMDLINE_LINUX mehrfach aus. Geändert hatte es aber nichts. Also probierte ich noch eine Option aus, bis es dann letztendlich doch funktionierte. In der Zeile GRUB_CMDLINE_LINUX_DEFAULT stand als Standard-reboot-Wert pci drin. Diesen musste ich in bios ändern. Danach noch ein update-grub durchführen, damit die neue Konfiguration genutzt wird.

Die Datei /etc/default/grub sieht nun wie folgt aus:

Nun startet auch das alte Notebook per Konsolenbefehl ordnungsgemäß neu.

[Quelle: linux.koolsolutions.com]