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

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.

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]

Zend_Filter PregReplace in ini-Config

Heute hatte ich das Problem, dass die Config für ein Zend_Form-Formular in einer ini-Datei stehen musste. Dabei sollte auch PregReplace zum Einsatz kommen, um nichtgewollte Worte gegen Sternchen auszutauschen. Es gibt aber scheinbar kein Tutorial oder Beispiel für die Einbindung von Filtern per ini-Datei, bei denen man dem Filter Optionen hinzufügen kann. Man findet immer nur einfache Filter-Einbindungen ohne Optionen wie

[code lang=”bash” inline=”yes”]elements.nachricht.options.filters.bigger.filter = “StringToUpper”[/code]

zum Vergrößern aller Buchstaben.

Durch einiges Probieren mit den Kollegen und Durchforsten der Zend_Filter-Library, kamen wir dann auf folgendes:

[code lang=”bash” inline=”yes”]elements.nachricht.options.filters.badword.filter = “PregReplace”
elements.nachricht.options.filters.badword.options.match = “/(\bpoo\b|\bfuck\b|\bsuck\b)/i”
elements.nachricht.options.filters.badword.options.replace = “*****”[/code]

Man muss also nach dem selbstgewählten Namen des Filters, in meinem Fall “badword”, den verwendeten Filter mit “.filter” einbinden. Die Optionen werden mit “.options” ebenfalls direkt nach “badword” eingebracht. In der Option “match” steht dabei ein regulärer Ausdruck mit dem zu filternden Format und in “replace” die dafür vorgesehene Zeichenkette als Ersatz für die gefundenen Worte. “\b” markiert Wortanfänge und -enden. “i” steht dabei als caseinsensitive, also werden Groß- und Kleinschreibung ignoriert. Die Trennung der bösen Worte erfolgt per “|”.

CamelCase mit Bindestrich und umgekehrt in Zend Framework

Ich hatte gestern das Problem, dass in unserem Zend Framework Projekt die Actions in CamelCase geschrieben sind, also zum Beispiel:

[code lang=”php” inline=”no”]public function editUserAccountAction()[/code]

In der Navigation, im Routing und in der ACL stehen diese aber ohne CamelCase und mit Bindestrich drin, also nach obigen Beispiel:

[code parse=”no” inline=”no”]http://www.domain.com/irgendwas/edit-user-account/[/code]

In der ACL wie folgt.

[code lang=”php” inline=”no”]$acl->deny(‘guest’, array(‘irgendwas’), array(‘edit-user-account’));[/code]

Nun hab ich eine Rechteverwaltung geschrieben, welche die Actions anhand der Controller aus der Datei ausliest und bei Erlaubnis des Users vergleicht. Das Problem dabei ist, dass edit-user-account, wie es in der ACL steht, und editUserAccount, wie es aus dem Controller ausgelesen wird, im Vergleich immer false, also ungültig bzw falsch,  zurückgeben. Das Problem habe ich dadurch umgangen, indem ich einen Filter auf den ausgelesenen Actionnamen angewendet habe. Genauer den Zend_Filter_Word_CamelCaseToDash(). Darüber habe ich noch einen strtolower() laufen lassen, um auch vorhandene Großbuchstaben in kleine ändern zu lassen.

[code lang=”php” inline=”no”][…]
$ausgelesenerName = ‘editUserAccount’;
$filter = new Zend_Filter_Word_CamelCaseToDash();
$bereinigterName = strtolower($filter->filter($ausgelesenerName));
[…][/code]

[via /dev/notes ]

Zend Framework mit XAMPP und vhosts unter Windows

Heute will ich euch zeigen, wie ihr unter Windows das Zend Framework, den XAMPP und verschiedene vhosts (Virtual Hosts) einrichtet. Das hat den Hintergrund, dass ich mehrere Test-Projekte auf Windows-Maschinen laufen habe und normalerweise bei einem einzelnen Projekt auf localhost arbeiten würde. Um nicht Unterverzeichnisse nutzen zu müssen, ist es sinnig verschiedene vhosts zu verwenden. So kann jedes Projekt unter seiner eigenen ‘Domain’ aufgerufen werden. Das Ganze funktioniert nur lokal!

Ich selbst nutze für dieses Tutorial hier Windows 7 Professional 64 bit, XAMPP 1.7.7 VC-9 Win32 und das Minimal-Package des Zend Frameworks in der Version 1.11.11. Ich gebe der Vollständigkeit halber auch das mit an, was ich selbst geändert und geschrieben habe, um dieses Tutorial zu erstellen.  Continue reading “Zend Framework mit XAMPP und vhosts unter Windows”

Firefox an seiner Grenze?

Ich schaute mir vor kurzem eine Seite eines wahrscheinlich zukünftigen Projektes an, um einen kurzen Eindruck zu gewinnen. Es sei dazu gesagt, dass nur ein Tab im vorher frisch geöffneten Firefox mit genau dieser Seite offen war. Im Hintergrund lief nur das Nötigste.

Ich denke, damit sollte jedem klar werden, dass nicht Firefox am Ende war, sondern die von mir angesurfte Seite dringend Nachholbedarf hat und großes Optimierungspotential besitzt.

Mehrere Rechner mit einer Tastatur und Maus bedienen – Mouse without Borders

Das verspricht die kostenfrei erhältliche Software Mouse without Borders, ein “The Garage”-Projekt von Microsoft. Und das hält das 1,1 MB kleine Programm für Windows auch. Wie es funktioniert, wie man es einrichtet und was man damit alles machen kann, erklär ich euch kurz am Beispiel meines Arbeitsplatzes hier bei mir zuhause. Continue reading “Mehrere Rechner mit einer Tastatur und Maus bedienen – Mouse without Borders”