Das Farbschema steht und wir konnten es nun auch für das Design des Blogs benutzen. Christian hat mir gezeigt, wie das im WordPress-Theme durch die Eingabe von zusätzlichem CSS funktioniert. Er musste viele Elemente anpassen, unter anderem die Linkfarbe, die Farbe für Schaltflächen, Hover, die Social-Media-Buttons… Das war insgesamt ganz schön aufwändig und hat durch viel Sucherei im Code und diverse Erklärungen einiges an Zeit in Anspruch genommen. Ein kleiner Vorgeschmack auf das nächste Modul sozusagen!
Kategorie: Technik
First Level Support
Erste Fehlermeldung beim „Support“: Beim Upload großer Bilder meldet WordPress einen „HTTP-Fehler“.
Das ist zwar nicht sehr aussagekräftig, aber im Kontext „Upload“ völlig ausreichend: Wahrscheinlichste Ursache ist die Standardkonfiguration des Reverse Proxy, die nur Uploads bis zu einem MiB zulässt.
Wert geändert, Problem gelöst. Rechnung kommt per Brieftaube.
IP-Adressen vs. SSL
Ruft man eine der IP-Adressen des Servers direkt im Browser auf, sieht man Dinge, die man nicht sehen will: Beim Zugriff mit HTTP ist das eine hässliche Fehlerseite, mit HTTPS ist es ein Zertifikatsfehler.
Für HTTP lässt sich das relativ einfach beheben, indem im Reverse Proxy ein – nach außen nicht sichtbarer – Default-Host mit dem gemäß RFC2606 ungültigen Namen „invalid.invalid“ konfiguriert wird, der einfach nur einen Redirect liefert. Damit leiten http://176.9.147.173 und http://[2a01:4f8:160:30a8::2] schon mal richtig weiter.
Für HTTPS funktioniert das prinzipiell auch, allerdings macht mir dort SSL einen Strich durch die Rechnung: Da die IP-Adressen des Servers laut RIPE Hetzner gehören, wird mir keine vertrauenswürdige CA ein Zertifikat dafür ausstellen. Es muss also eine Alternative her, die ohne „richtiges“ Zertifikat auskommt. Um die Warnung im Browser kommt man dann aber leider nicht herum.
Als halbwegs brauchbare Lösung erscheint mir ein selbstsigniertes Zertifikat mit Text im „Common Name“. Das ist im eben angelegten Default-Host am Reverse Proxy auch schnell konfiguriert. Beim Zugriff auf https://176.9.147.173 und https://[2a01:4f8:160:30a8::2] bekommt man dann zwar den unvermeidlichen Zertifikatsfehler zu sehen, aber zumindest hat der eine hübsche Meldung:
Social Media Icons
Um den Blog mit Social Media verknüpfen zu können, habe ich neben dem obligatorischen Antispam Bee gerade noch ein weiteres WordPress Plugin installiert: Lightweight Social Media Icons. Es zeichnet dafür verantwortlich, dass man im Footer der Seite jeweils mit einem Klick auf das passende Icon meine für Customieze neu eingerichtete Facebook-Seite, den ebenfalls neuen Twitter-Account und natürlich mein Xing-Profil erreicht.
Customieze sucht Platz
Jetzt wo so langsam echte Daten auf dem Server anfallen, ist auch eine entsprechende Datensicherung notwendig. Die braucht natürlich Platz außerhalb des Servers.
Hetzner bietet dafür externen Speicherplatz in zwei Formen an: Backup-Speicher und Storagebox. Preislich nehmen sie sich nichts, der Backup-Speicher ist allerdings nur aus dem Hetzner-Netz direkt erreichbar. Ich entscheide mich für die Storagebox mit 100 GB, weil ich gerne auch ohne irgendwelche Tunnel von „außen“ darauf zugreifen möchte.
Auch für den Zugriff auf die Storagebox ist eine schlüsselbasierte Authentifizierung möglich. Also schnell den öffentlichen Schlüssel auf der Storagebox abgelegt und… Nichts! Warum das nicht geht, verrät das Hetzner-Wiki: Für den Zugriff mit SCP/SFTP muss der öffentliche Schlüssel im RFC4716-Format auf der Storagebox abgelegt werden. WTF?! Na wenn’s sein muss… Konvertiert. Abgelegt. Läuft.
Redirect: Reloaded
Der Autor des Redirect-Images hat meinen Fix von gestern übernommen und auch gleich noch Version 0.3.2 veröffentlicht. Ich aktualisiere die Docker-Container und freue mich, dass sie sich jetzt richtig stoppen lassen.
Heute schon gebloggt?!
Bis jetzt gibt’s auf dem Server nur einen praktisch leeren Web-Server und ein paar Redirects. So soll’s bleiben… NICHT!
Damit Dana und ich endlich den gesammelten Content irgendwo abwerfen können, lege ich die Subdomain blog.customieze.de an und starte einen Docker-Container für WordPress und einen mit der dazu passenden MySQL-Datenbank. Ein paar Zeilen Konfiguration später laufen beide und reden sogar miteinander!
Wie immer muss natürlich auch noch blog.customieze.com angelegt und mit einem passend konfigurierten Redirect-Container hinterlegt werden.
Container? Sicher!
Momentan läuft auf dem Server noch nichts wirklich sinnvolles. Damit das nicht so bleibt, installiere ich Docker Community Edition. Der Plan ist, den Großteil der Server-Software in Form von Docker-Containern laufen zu lassen.
Als nächstes starte ich jeweils einen Docker-Container auf Basis der Images jwilder/nginx-proxy und jrcs/letsencrypt-nginx-proxy-companion. Unverschlüsselte HTTP-Verbindungen liefern ausschließlich Weiterleitungen auf die entsprechenden HTTPS-Äquivalente, die durch das Zusammenspiel der beiden Docker-Container mit Zertifikaten von Let’s Encrypt abgesichert sind.
Hinter der „Master-URL“ https://www.customieze.de läuft vorerst ein blanker Apache Web Server, der einfach nur „It works!“ behauptet. Stimmt ja auch.
Um sämtliche Kombinationen aus „www.“, „.de“ und „.com“ letztlich auf die Master-URL umzulenken, sind noch ein paar Weiterleitungen notwendig. Dafür benutze ich das Docker-Image schmunk42/nginx-redirect. Über den vorher aufgesetzten Mechanismus bekommen auch die daraus erstellten Redirect-Container vollwertige SSL-Zertifikate.
Beim Test der der Redirect-Container fiel mir allerdings noch auf, dass sie sich nicht sauber stoppen lassen. Die Lösung dafür spiele ich mit einem Pull-Request an den Autor zurück.
Gib dem Server vier Namen!
Damit der frisch aufgesetzte Server auch über die Customieze-Domains erreichbar ist, sind ein paar Aktionen in der DNS-Konfiguration notwendig:
Zum Server gehören eine (!) IPv4-Adresse und ein IPv6-Subnetz mit ca. 18 Trillionen Adressen, von denen vorerst aber auch erstmal eine reicht. Bei STRATO konfiguriere ich die A- bzw. AAAA-Records, damit die insgesamt vier Hostnamen („.de“ und „.com“, jeweils mit und ohne „www.“) auf die festgelegte IPv4- bzw. IPv6-Adresse verweisen. Die PTR-Records für die „Rückrichtung“ setze ich bei Hetzner passend dazu auf „customieze.de“.
Damit ist der Server schon mal unter seinen vier Namen erreichbar.
Ein Server für die Customieze
Die Entscheidung am Morgen danach: Hetzner. Das Zünglein an der Waage? Der Support. Ist zwar etwas teurer, aber das ist es mir einfach mal wert.
In der Server-Börse werde ich fündig: Ein stattlicher Intel i7-4770 @ 3.40 GHz mit 32 GB RAM und 2 × 3 TB HDD für nicht minder stattliche 44 € im Monat. Gekauft! Ähm… Gemietet!
Keine fünf Minuten später bin ich per SSH auf dem Rescue-System angemeldet und kann den Server fertig aufsetzen. Konfiguration und Installation des finalen Betriebssystems sind zusammen nochmal eine Sache von zehn Minuten. Fertig ist ein CentOS 7 mit einem RAID1 über den beiden Platten!
Kaum ist der Server eingerichtet, tauchen auch die üblichen Loginversuche aus China auf – irgendwelche Bots, die das Netz nach offenen Servern abgrasen. Damit da nichts passiert, lege ich einen User an und verbiete „root“ den Login übers Netz. Die Remote-Anmeldung mit Username und Passwort wird bei der Gelegenheit auch gleich noch deaktiviert. Nachdem „root“ nun abgedichtet ist, machen die Bots mit „ftp“, „jenkins“, „testuser“ und allen möglichen Vornamen weiter. Dass das praktisch aussichtslos ist, ist Bots offenbar egal.