Leselaunen Umzug und Technikkram

Leselaunen

Die Aktion „Leselaunen“ ist ein wöchentlicher Bericht und Austausch unter Buchbloggern über das aktuell gelesene Buch, die Lesemotivation und andere Kleinigkeiten im Leben eines Buchbloggers. Der Leselaunen Bericht erscheint wöchentlich am Sonntag um 20:00 und jeder darf jederzeit mitmachen und seinen Link dann bei Trallafittibooks verlinken. Einfach einen Leselaunen-Beitrag schreiben, verlinken, andere Teilnehmer besuchen/kommentieren und genießen!

Da ich unten ggf. einige Markennamen erwähne, kennzeichne ich den Beitrag hiermit als Werbung.

Aktuelles Buch:

Noch nichts. Ich hoffe aber in der kommenden Woche mehr zu lesen.

Aktuelle Lesestimmung:

Maxton Hall 3 Save Us - Mona Kasten

Mein Lesefortschritt lag diese Woche quasi bei Null. Das lag aber nicht an der Lesestimmung oder am Buch, sondern einfach daran, dass ich anderweitig beschäftigt war (siehe unten).

Die Rezension zur obigen Maxton Hall Reihe findet ist nun auch online. Ich war unerwartet begeistert. Trotz der eigentlich recht normalen Story (keine Aliens, Trolle, Elfen oder sonstige unnatürliche Elemente), konnte mich die Geschichte begeistern.

Zitat der Woche:

‘Gib einem Menschen Macht und du erkennst seinen wahren Charakter. – Sam Feuerbach, Die Krosann Saga 

Was für ein Zufall (wirklich! es ist einfach das nächste nach der letzten Woche, schaut selbst nach!) das Zitat passt super zu den Postmastern von T-Online bzw. zu meinem Post unten. 😉

Und sonst so?

Diese Woche hatte ich drei tage Kurzarbeit (also frei, einen Tag Urlaub, einen Feiertag und trotzdem ein maximal volles Programm. Es stand Technikkram, ein Blogumzug und anschließend Aufregen über T-Online auf der todo Liste.

Ich bin nicht mal zum Lesen gekommen. 🙁

Heute habe ich drei Blogeinträge geschrieben. Die Rezension zur Maxton Hall Reihe, diesen Beitrag und das erste Lesequartal (der geht Dienstag online). Somit hat sich auch im Blog mal wieder was getan.

Ich hatten in den letzten Leselaunen bereits geschrieben, dass der Versuch den Blogserver auf Ubuntu 20.04 LTS zu bringen den Blog für 1,5 Tage lahmgelegt hat. Sagen wir es einfach mal so, es lief nicht ganz rund. Danach musste ich ein Backup vom Vortag einspielen, weil ich den Stand so nicht behalten wollte (hätte ich mal machen sollen, besser wurde es das Ergebnis auch später nicht).

Da ich mir nach der Aktion einen neuen VPS Server angemietet habe, der auch Snapshots unterstützt und ich über den Schritt auf einen SSD Server zu wechseln eh schon länger in Angriff nehmen wollte, weil der Blog temporär einfach sehr lahm war, habe ich die Woche für den Umzug genutzt. D.h. der Blog ist nun bereits umgezogen.

Gleichzeitig habe ich die Chance temporär einen zweiten Server zur Verfügung zu haben dafür verwendet um das Ubuntu Upgrade noch mal anzugehen. Faktisch habe ich beim ersten Mal aber nichts falsch gemacht Der Upgradeprozess auf Ubuntu 20.04 ist aktuell einfach extrem unrund es gibt diverse Bugs.

Wie so häufig wenn man den Server oder besser gesagt die IP Adresse des Servers wechselt ist T-Online mal wieder extrem negativ aufgefallen. T-Online verweigert die Nutzung von Standards im Mail Bereich (kein Dane, kein DKIM, kein DMARC, kein SPF und es werden vollkommen veraltete Ciphers und Verschlüsselungsstandards verwendet, die so unsicher sind, dass man sie mit etwas Recherche im Netz in Sekunden oder Minuten knacken könnte, wenn man es darauf anlegen würde).

Den offiziellen “Standpunkt” von T-Online man auch ganz offiziell nachlesen: https://postmaster.t-online.de/

Lustig ist zum Beispiel die Passage in der kurz angesprochen wird, dass kein DKIM verwendet wird. Warum das so ist wird nicht weiter begründet. DKIM fügt an eine Mail eine Information an, die bestätigt, dass die Mail seitens des Absenders (Mailadresse) autorisiert ist. Das ist ein Wirksames verfahren um Spam von gefälschten Adressen aussondern zu können.

Es gibt aber immerhin ein Projekt. Hört sich ein wenig nach einer Bachelor oder Masterarbeit an. Bei großen Unternehmen dauert es halt schon mal länger.

Bisher werden DKIM-Signaturen weder gesetzt noch ausgewertet. (Eine Ausnahme ist das Projekt “Trusted Dialog”, bei dem DKIM-Signaturen für das “Inbox Branding” eingesetzt werden.)

Auch andere Schutzverfahren werden so nebenbei alle als Quatsch ausgesondert. Für mich ist die Aussage in etwa so wie “Wenn ich eh wieder dreckig werde, warum soll ich mich überhaupt jemals im leben waschen?” oder bezogen auf Corona “Warum gehe ich nicht gleich zu einer Großveranstaltung mit 1 Mio Leuten, wenn die Schutzmaßnahmen wie Abstand halten oder Masken eh nicht 100% sicher sein.” oder um konkret auf die IP Sperren einzugehen.

“Von den aktuellen Testverhalten halten wir nichts. Wir haben einen Schamanen der durch anschauen prüft, ob jemand Corona hat. Wir lassen nur noch Leute in unser Haus rein, die der Schamae abgesegnet hat. Wir erwarten allerdings, dass Leute aus unserem Haus raus dürfen. Wir haben per Definition kein Corona, obwohl wir alle offiziellen Test ablehnen.”

Desto unverschämter ist es, dass sich T-Online offenbar als Bekämpfer des Spam sieht (fehlt nur das Superman Kostüm). Das macht T-Online aber nicht durch die Nutzung durch obige Standards und ausschließliches bannen von negativ auffälligen Mailservern.

Nein, warum denn das? Das macht der Rest der Welt. T-Online proklamiert für sich besser und schlauer zu sein als alle anderen (mithilfe der Schamanen Supermänner Postmaster).

D.h. Standards werden ignoriert aber Anbieter von Servern werden mit permanenten IP Sperren überzogen. Bisher ist mit das bei den letzten VPS Servern immer so gegangen, dass Mails an T-Online nicht zugestellt werden können, weil T-Online IPs dauerhaft blockt. Bei dem aktuellen ist es so, dass er in keiner Blacklist (das sind Negativlisten, in denen Spamserverbetreiber aufgeführt werden) enthalten ist.

Für die Sperren wird auch kein Grund genannt, das wird einfach gemacht nach Gutdünken der Postmaster, die sich als kleine Götter aufschwingen können (wenn man sonst nichts zu sagen hat, muss man das wohl kompensieren). Das ist wahrscheinlich so ähnlich wie mit großen Autos und … ach nein lassen wir das. 😉

Nach den bisherigen Erfahrungen sieht das für mich auch nicht nach Einzelsperren, sondern eher nach großflächigen Sperren von IP Bereichen aus. Das ist aber meine persönliche Meinung, die ich nicht belegen kann. Im Netz finden sich aber durchaus diverse Beiträge zu dem Thema, die durchaus eine Regelmäßigkeit erkennen lassen (ich weigere mich das System zu nennen).

Bisher hat T-Online die Sperren auf Zuruf entfernt. Die Zeiten scheinen aber vorbei zu sein. Somit ist aktuell keine Zustellung von Mails an T-Online möglich. Ich werde wohl noch eine nette Mail verfassen, bei denen ich mit rechtlichen Schritten drohe.

Eine rechtliche Grundlage für die Handlungsweise von T-Online gibt es zumindest nicht. Lustig ist auch, dass die meinen alten Bogserver zugelassen haben, obwohl ich dort weniger Aufwand betrieben habe, als beim aktuellen. In jedem Fall waren beide Server deutlich besser konfiguriert als die T-Online Mailserver.

Für den aktuellen Mailserver habe ich sogar eine separate Domein eingerichtet (bei einem VPS hat man normalerweise eine Domain wie 3514.serveranbieter.de). Für diese Domain kann man aber z.B. kein DANE einrichten. Weiterhin gilt die Domain als generisch weil fortlaufend. Eine separate Domain bedeutet mehr Aufwand in der Einrichtung und kostet natürlich jedes Jahr Geld.

Ein echter Sicherheitsgewinn ist sie nicht, weil man ja über den Serveranbieter oder auch so schnell raus bekommt wer der Betreiber einer Domain ist. Im Zweifelsfall geht bei einem guten Anbieter der Server in Stunden vom Netz, wenn er zur Spamverteilung verwendet wird. Zusätzlich werden die Blacklists weltweit gefüllt und die Mails werden nicht mehr angenommen. Echte Spambetreiber werden also sicher nicht den Aufwand betreiben und Mails an T-Online schreiben, sondern einfach IPs nutzen, die noch nicht gesperrt sind.

Dauerhafte Sperren treffen also nur Mailserver, die ihre IPs nicht ständig wechseln. Das wird gerade bei Spamservern anders sein, sonst wären sie nicht erfolgreich.

Zumindest gibt T-Online ein super Beispiel dafür ab, wie man es nicht machen sollte und die Antworten strotzen nur so vor Arroganz. Wer im Glashaus sitzt (siehe Standardunterstützung oben), sollte nicht mit Steinen werfen. Als Kämpfer gegen Spam braucht sich T-Online nun wirklich nicht darstellen.

So genug Dampf abgelassen.

Wie war eure Woche?

Weitere Leselaunen:

Viel Netflix und ein toller Film! bei Andersleser back to work bei Letterheart ∗

Ubuntu 20.04 LTS Focal Fossa Upradeerfahrungen [Kommentar]

Neu = gut?

Am 23.04 ist offiziell die nächste LTS Version von Ubuntu erschienen.

Da ich Ubuntu für meinen VPS nutze und beim letzten Update auf 18.04 der Prozess sehr rund verlief war ich – wie sich anschließend gezeigt hat – etwas zu optimistisch / mutig.

Der normale Prozess beim Release Upgrade ist bei Ubuntu über “sudo do-release upgrade” den Prozess zu starten. Das funktioniert aktuell noch nicht, wenn man von Ubuntu 18.04 LTS Bionic kommt. Das hat seine Gründe, wie ich festgestellt habe. Über sudo do-release upgrade -d kann man etwas nachhelfen.

Ich hatte zwar ein vollständiges Backup von 18.04 LTS aber ich hatte nicht ernsthaft damit gerechnet, dass ich es brauche. Allerdings habe ich damals bis zum ersten Patch gewartet und hatte auch deutlich weniger auf dem Server installiert.

Upgrade mit Überraschungen

Wie waren die Erfahrungen bei der Installation? Sehr durchwachsen. Je nach Zugriff auf den Installer (z.B. VNC auf einem VPS) kann ich nur davon abraten Detail / Vergleichsdialoge oder ähnliches aufzurufen. Man sollte sich auf simples ja / nein beschränken.

Teilweise werden Konfigurationdialoge ohne Rückfrage erzwungen und wenn man dann versucht sie zu verlassen wird das als Versuch gewertet das komplette Upgrade abzubrechen (bei mir z.B. mehrere LDAP Dialoge). Generell sollte der ganze Upgradeprozess robuster sein. Das mag aber auch auf andere Linux Versionen zutreffen.

An einer Stelle ich bei mir die Installation einer Endlosschleife gelandet, die ich nur durch Abbruch der Installation beenden konnte.

man path config
updating database manual page

Das scheint aber nicht ungewöhnlich zu sein oder spezifisch für Ubuntu 20.04. Trotzdem hat mein definitiv kein gutes Gefühl, wenn man die Installation abbrechen muss. Der Beim Versuch mit sudo apt upgrade das Upgrade fort zu setzten war DPKG durch einen Prozess geblockt. Ich habe den Prozess über kill <id> beendet. Anschließend lies sich sudo apt upgrade wieder starten und das Upgrade fortsetzen.

Darf es etwas weniger sein?

Nach der Installation waren diverse Pakete deinstalliert. Das hängt damit zusammen, dass z.B. FirewallD diverse andere Pakete voraussetzt. Auch der X2GOCLIENT verwendet teilweise diese Pakete. Diese Pakete werden teilweise durch neue Versionen mit anderen Namen ersetzt. Um also FirewallD auf den aktuellen Stand zu bringen muss vorher X2GO und FirewallD deinstalliert werden, dann die diversen alten Pakete runter, die neuen Pakete drauf und danach wieder X2GO und FirewallD.

Während des Installationsprozesses werden diverse Pakete entfernt (z.B. auch Webmin, das ist ein Cockpit zur Steuerung des Webservers). Neu installiert werden sie aber nicht alle. Ohne Backups ist das Upgrade also eine ganz schlechte Idee, weil Webmin bei mir z.b. auch nach der Neuinstallation nicht wieder richtig lief. Erst das Rücksichern der alten Ordner (auch die diversen Ablageordner muss man erst mal kennen – im Falle von Webmin zum Beispiel /etc/webmin, /var/webmin, /usr/shares/webmin/.

Empfohlene Variante? – lieber nicht

Die zweite Installationsvariante (sources bionic gegen focal tauschen und anschließend dist-upgrade ausführen) hat sich bei mir wegen diverser nicht erfüllbarer Abhängigkeitsbeziehungen in Endlosschleifen geendet. Deinstallation nicht möglich weil, x gebraucht wird, x hängt von y ab aber y kann nicht installiert werden. Das heißt bei dieser Variante zerlegt sich Ubuntu selber.

Bei Apache wurde ein Mod deinstalliert und die Konfiguration wird nun schärfer geprüft. Im Meinem Fall wurde der SSL Port für SSL / GNUTLS belegt (also doppelt), früher wurde wohl einfach der zweite Eintrag genutzt und ein Mod von Apache wurde beim Upgrade deinstalliert (Reparatur über a2enmod socache_dbm).

Zur Sicherheit habe ich auch OpenOTP auf dem Server (Token zusätzlich zur Passworteingabe was verhindert, dass sich jemand auf dem Server anmelden kann, der das PW erlangt hat). Das Problem ist noch auf meiner To-Do Liste. Offenbar gibt es Probleme bei der Kommunikation von LDAP und der PAM Anmeldung. Warum ist mir aber noch nicht klar.

Und Ubuntu 20.04 verursacht Probleme im Kontext GUI. Ich habe es bisher auf zwei VPS Servern von Contabo installiert (VPS SSD und HDD) und in beiden Fällen ist der Start der grafischen Oberfläche Gnome nicht möglich. Auch das Problem ist noch ungelöst.

Bei X2GO verhält sich Ubuntu auch anders. Ohne Root Rechte lassen sich einige Programme nicht mehr starten. Bei vielen Programmen macht das wenig bis keinen Sinn. Beispielsweise lässt sich die Konsole nur mit root Rechten öffnen. Dort muss man aber eh ein Passwort eingeben, um irgendwelche Aktionen durchzuführen. Was soll also diese Zusatzprüfung? Somit meldet man sich gleich als Root an, das ist viel schlimmer.

Stand heute ist der Upgradeprozess also eher im Beta oder Alphastadium aber definitiv nicht für produktive Server geeignet, wenn man kein Snapshot hat. Ich habe das System zwar mit einem Backup auf den Stand vor dem Releaseupgrade zurückversetzen können aber dabei muss man höllisch aufpassen bei einem Laufenden Linux oder gleich ein Rescue System nutzen, was aber auch diverse Probleme mit sich bringt (Stichwort Rechte).

Fazit und Ausblick

Nicht ohne Grund wird das Upgrade erst zum ersten Patch auf 20.04.1 angeboten.

Aktuell bieten die meisten auch keine focal Version an. Somit ist es durchaus angeraten einige Wochen / Monate zu warten.

Erste Tests zeigen, dass 20.04 unter bestimmten Rahmenbedingungen im Schnitt 25% schneller als 18.04. Wenn der Upgradeprozess also irgendwann mal rund läuft und die o.g. Probleme (GUI, LDAP, X2GO, Webadm) irgendwann behoben sind, ist das ein gutes Upgrade.

Einige Versionen in Ubuntu 20.04 waren ziemlich vorsintflutlich. Der Versionssprung ist teilweise dementsprechend groß.

Aktuell kann ich von einem Upgrade auf einem produktiven Server aber nur abraten. Wenn man es versuchen will ist ein Snapshot sehr hilfreich. Wenn man die Option nicht hat, dann benötigt man wenigstens ein Backup und einen Zugriff auf ein Rescue System.

Das ist eine Voraussetzung, an der man bei vielen VPS Anbietern bereits scheitert. In dem Kontext muss ich den Support und die Möglichkeiten bei Contabo loben (nein, ich bekomme für die Aussage kein Geld und wurde auch nicht von Contabo darum gebeten das zu erwähnen).

Man sollte nach meinen Erfahrungen auf eine Downtime von mindestens einem Tag planen und ggf. auch damit rechnen, dass man ein Backup zurückspielen muss. Das hängt natürlich individuell davon ab was auf dem Server alles läuft. Bei mir ist das schon einiges.

Nachtrag 1 27.04.2020 – 16:55

Das Problem mit OpenOTP wurde mir vom Support bestätigt. Wenn man die Zertifikatsprüfung zwischen Webadm und OpenOTP deaktiviert, dann geht es wieder (einfach den Zertifikatseintrag bei OpenOTP auskommentieren). D.h. das LDAP Problem ist noch mal ein anderes. Wobei mir aktuell nicht so ganz klar ist, ob das wirklich ein Problem ist. Das sieht eher nach einer Zusatzfunktion aus, die nur halb konfiguriert ist. Scheinbar ist das eine zusätzlich genutzte Variante (Authentifizierung von LDAP statt mit PW File), die mit Ubuntu 20.04 scharf geschaltet wird, obwohl ich die Konfiguration abgebrochen habe, da ich mit SLAPD bereits einen funktionierenden LDAP Server habe.

Das Problem der nicht aufrufbaren Konsole konnte ich umgehen, in dem ich einfach einen anderen Terminalemulator installiert habe (Terminator).

Somit bleibt noch das Problem bei der GUI in VNC, das ich bisher noch nicht lösen konnte (aktuell weiß ich aber auch nicht, ob dafür evtl. Anpassungen vom VPS Anbieter nötig sind). Somit sieht es nun nicht mehr so schlecht aus. Trotzdem ist Ubuntu 20.04 als Gesamtpaket noch recht experimentell.

Wie ich gerade festgestellt habe geht auch RDP noch nicht. Aber das war schon immer nicht so ganz stabil und kommt eigentlich auch aus der Windows Welt. Das muss also nicht zwingend mit Ubuntu 20.04 zu tun haben aber das es auch GUI Probleme gibt, ist die Wahrscheinlichkeit durchaus vorhanden.

Ein RDP Zugang ist aber immer dann hilfreich, wenn man einen grafischen Zugang aus der Ferne benötigt (zum Beispiel auf dem Handy oder Pad und funktioniert auch mit iOS Devices). Das Thema werde ich aber erst angehen, wenn die GUI funktioniert. X2Go, RDP und Gui verwenden X11 / XORG. Somit beeinflussen die sich gegenseitig.

Nachtrag 2 03.05.2020 – 8:30

Ein paar Nachwehen gibt es noch aber teilweise auch Sachen, die durch das Update erst aufgefallen sind aber schon vorher da waren (vermutlich bereits durch das 18.04.4 Update).

Aktuell stürzt NGINX reproduzierbar zu einer bestimmten Uhrzeit mit einem Coredump ab. Das hatte ich vorher noch nie. Da ich die Ursache anfangs noch nicht ermitteln konnte habe ich mir nun mit restart always im Service Eintrag beholfen. D.h. mitten in der Nacht ist Nginx für zwei Sekunden weg. Das sollte verschmerzbar sein.

Das Problem hängt scheinbar damit zusammen, dass NGINX neuerdings empfindlich darauf reagiert, wenn ein Host nicht erreichbar ist. Da ich Nginx im Proxymodus auf einem Apache 2 Server nutze und den Nachts für Zertifikatsupdates durchstarte, killt das den NGINX gleich mit (die Fehlermeldung in den logs besagt, dass der Upstream nicht verfügbar ist). Die Lösung ist eine Variable statt einer direkten Adressierung.

Die o.g. Probleme (Stand 27.04) sind nach wie vor vorhanden. Auch jetzt sind diverse Repositories noch nicht für Focal verfügbar.

Ich habe einen neuen VPS bei Contabo augesetzt mit einem frischen Ubuntu 20.04 – die GUI Probleme in VNC sind auch dort vorhanden. Ich habe diverse Guides im Netz befolgt und Ubuntu Desktop, Gnome Desktop und StartX Pakete installiert. Weiterhin habe ich den Displaymanager testweise gewechselt (gdm3 / lightdm). Keine Variante hat reproduzierbar funktioniert.

Einmal habe ich den Desktop zu Gesicht bekommen aber reproduzieren konnte ich es später nicht (plötzlich war er im VNC sichtbar, währen ich gerade im Terminal gearbeitet habe).

Das heißt irgendwie geht es aber ich habe nach mehreren Stunden basteln aufgegeben. Das ist bestenfalls Alphazustand. Zum Glück kommt man mit X2Go und Webmin i.d.R. Auch ohne die Linux Standard Gui zurecht.

Bei Webmin ist noch ein Problem hinzugekommen. Die CPU und RAM Monitore im Dashboard sind verschwunden.

Die Webmin Probleme sind auf dem frischen VPS nicht vorhanden. Wie ich festgestellt habe liegt das an den Einstellungen für den Befehl PS im Prozess Manager von Webmin. Entweder funktionierende Gauges für CPU / Ram (Einstellung Linux) oder die Prozessliste (andere Einstellungen z.B. HPUX). Beides zusammen geht nicht. Ich habe einen Bugreport bei Webmin dazu eröffnet.

In Summe kann man Ubuntu 20.04 bei einfachen Setups nutzen oder eben wenn man experimentierfreudig ist. Ansonsten sollte man auf 20.04.1 warten.

Nachtrag 3 03.07.2020

Die meisten Probleme konnte ich unterdessen einkreisen. Das Nginx Problem hatte ich ja bereits im letzen Update bedchrieben. Nginx reagiert unterdessen offenbar äußerst empfindlich darauf, wenn das Weiterleitungsziele zum Zeitpunkt des Nginx starts nicht verfügbar sind. Das lässt sich über dynamische Aufrufe beheben.

set $platzhalter1 https://<URL>:8082;
proxy_pass $platzhalter1;

Früher hat man einfach bei proxy_pass die URL direkt eingetragen. Durch die Variable prüft Nginx nicht beim Start, sondern beim Aufruf.

Die externen Repositories sind jetzt weitgehend (noch immer nicht alle) für Focal verfügbar.

Die Probleme mit Webmin lagen an einem Bug in Webmin, der im aktuellsten Entwicklungsstand behoben ist. Das ist also ein Fehler in Kombination von Webmin / Ubuntu 20.04

Die Desktop Probleme auf dem VPS waren / sind ein ganzes Sammelsurium von Effekten. Es wurden automatisch nicht alle Treiber installiert, die für die virtuellen Devices benötigt wurden. Somit musste ich Maus / Tastatur Treiber manuell nachinstallieren. Weiterhin funktioniert der Login Screen von GDM nicht auf dm VPS (bei einem Wechsel auf lightdm funktioniert der Login Screen).

Zusätzlich sind zwingend root Rechte erforderlich, damit der Ubuntu Desktop auf dem VPS startet. Die Standardlösungen, die man beim googeln findet helfen alle nicht. Auch ein Kontakt zum Support hat nichts gebracht. Offenbar sind die Probleme aber VPS bezogen also nur für einen überschaubaren Teil der Anwender relevant.

Wenn ich also den GDM service stoppe und mit sudo startx aufrufe, gibt es auch einen Desktop zu bewundern. Der automatische Start in die GUI funktioniert nach wie vor nicht. Auf einem Server kann man damit leben, da man die GUI in der Regel nicht so oft verwendet.

Bei einem Aufruf des Dektop per RDP gilt das gleiche – aktuell geht es nur mit ROOT Rechten.

Das OpenOTP Problem in Kombination mit Ubuntu wurde von dem Entwicklern mit der aktuellen Version behoben.

Zwei Jahre Blog [Kommentar]

Den Blog gibt es nun bereits zwei Jahre. Während ich im ersten Jahr noch mit dem Design experimentiert habe und einiges am Blog erweitert habe, wurden die Änderungen im zweiten Jahr deutlich weniger.

Das lag natürlich auch daran, dass ich im vergangenen Jahr 5 Monate in den USA durch die Gegend gereist bin (siehe hier).

Am Server habe ich den letzten Monaten einiges geändert. Während anfangs mein primäres Ziel war alles irgendwie ans Laufen zu bekommen, habe ich die Sicherheit des Servers erhöht, die Datenbank auf den aktuellen Stand gebracht und den den Mailserver auf den aktuellen technischen Stand.

Bzgl. der Besucherzahlen ist zwar absolut gesehen eine deutliche Steigerung vorhanden (15.000 auf ca. 20.500). Im Vergleich zum ersten Jahr ist die gemessene Besucherzahl aber extrem rückläufig. Ob das an anderen Messmethoden oder auch Caching Plugins liegt, kann ich nicht sagen. Ich vermute aber, dass zumindest letztere einen deutlichen Einfluss haben.

In den Google Suchergebnissen liegt der Blog teilweise recht weit vorne. Zumindest wenn man nach Buchreihen oder Serien sucht.

Erfolgreichste Beiträge

Dazu gehören zum Beispiel einige Beiträge zum PCT, die ziemlich gefragt sind. Primär sind dies der Beitrag zur Ausrüstung, der Beitrag zum Bewerbungsprozess bzw. Permit und der Beitrag Buch vs. Realität. Das sind quasi alles Nischenthemen, zu denen man nicht so viel im Netz findet (vor allem im deutschsprachigen Raum).

Viel leichter als mit Büchern erregt man offenbar mit Beiträgen zu Lifestylethemen Aufmerksamkeit. Mein Kommentar zur Garmin Fenix 5 Plus gehört zu den meistgelesenen auf dem Blog.

Bei den Büchern liegen die Armentrout Buchbeiträge mit großen Abstand vorne. Ganz vorne liegt die Lux Serie aber auch die anderen wie z.B. Götterleuchten, Dämonentochter und Wicked haben recht viele Aufrufe. Ich vermute aber, dass es kaum um die Rezensionen geht, sondern einfach darum, dass die Seitenbesucher nach der richtigen Lesereihenfolge bzw. den Teilen der Serie suchen. Faktisch sind die meistgeladenen Rezensionen nicht meine besten.

Bei den Reisebeiträgen ist die Hurtigruten mit Nordlicht Tour mit Abstand am meisten besucht.

Nun könnte man zur Erkenntnis kommen, dass man sich die Buchrezensionen sparen kann oder zumindest auf die Sterne beschränken (meine Reihenübersichtsseite wird offenbar recht viel genutzt aber die Rezensionen selbst liest fast niemand).

An den Themen der Blogs hat sich seit dem letzten Jahr nichts geändert, wenn man mal ignoriert, dass der Blog zwischendurch zur Hälfte Reiseblog war. Es sind also nach wie vor Buchserienreviews, Einzelreviews, Filmreviews, das Thema Hiken und Reiseberichte im Blog vertreten.

Zusätzlich bin ich den Leselaunen und der Montagsfrage treu geblieben. Beide schwächeln aber bei der Teilnehmeranzahl.

Insgesamt habe ich rund 185 Bücher mit mehr als 75.000 Seiten gelesen. Das ist vermutlich mehr als einige in ihrem ganzen Leben schaffen, andere wiederum lesen das in einem Jahr. 😉

Den Beitrag aus dem letzten Jahr findet ihr hier.

Leselaunen rauchige Aliens

Leselaunen

Die Aktion „Leselaunen“ ist ein wöchentlicher Bericht und Austausch unter Buchbloggern über das aktuell gelesene Buch, die Lesemotivation und andere Kleinigkeiten im Leben eines Buchbloggers. Der Leselaunen Bericht erscheint wöchentlich am Sonntag um 20:00 und jeder darf jederzeit mitmachen und seinen Link dann bei Trallafittibooks verlinken. Einfach einen Leselaunen-Beitrag schreiben, verlinken, andere Teilnehmer besuchen/kommentieren und genießen!

Da ich unten ggf. einige Markennamen erwähne, kennzeichne ich den Beitrag hiermit als Werbung.

Aktuelles Buch:

Izara Verbrannte Erde - Julia Dippel

Die Izara Serie war mit das beste was ich letztes Jahr gelesen habe, somit hoffe ich auf einen tollen vierten (finalen?) Teil.

Aktuelle Lesestimmung:

Dunkelglanz Obisdian Lux Spin Off - Jennifer L Armentrout

Eigentlich hatte ich ja den Vorsatz die Mortal Engines Reihe zu beenden aber da es wieder ein Spin Off zur Lux reihe gab und meine Lesemotivation nicht so toll war (die Mortal Engines Reihe hat mich einfach nicht so richtig abgeholt), habe ich mit  begonnen und es auch beendet.

So viel vorab zur Rezension von Dunkelglanz Obsession, dass ein weiteres Spin Off der Lux Serie ist. Es ist ein typisches Armentrout und dann auch wieder nicht. Ich bin mir ziemlich sicher, dass es nicht jedem gefallen wird. Allerdings ist die Amazon Durchschnittswertung bei 4,5 (das haben die Armentrout Bücher fast immer). Offenbar ist das magische Rezept Bad Boy + genügend Sexszenen um ein gewisses Klientel anzusprechen. ^^ Sexszenen hat das Buch zumindest eindeutig genug (mir sogar zu viele).

Zitat der Woche:

Soon I will join them on the surface of Mercury, but first I have work to do. It would be easier with Sevro. Everything violent is. Pierce BrownRed Rising Reihe Teil 5

Nachdem ich jetzt rückwärts die Zitate der Bücher abgearbeitet habe, die ich während des PCT Hikes gelesen habe, geht es nun wieder voran. 😉

Und sonst so?

Mit der dritten Folge von Picard geht es nun so langsam zur Sache. Ich bin gespannt wie die Geschichte um Datas Tochter weiter geht. Jetzt sind sie zumindest mal aufgebrochen und endlich wieder in den unendlichen Weiten unterwegs. 😉

Diese Woche war ich recht fleißig aber überwiegend nicht am Blog, sondern mal wieder am Server. Aufgrund der Performanzprobleme hatte ich einen alternativen VPS Anbieter – Strato getestet. Die Ergebnisse waren recht mau. Ich habe jetzt noch Benchmarks hinzugefügt und ein drittes VPS Server Modell.

Somit bleibt es also eher bei dem Vorsatz den Blog testweise mal auf den Cotabo mit SSD umzuziehen.

Der letzte noch fehlende Step für nahtloses umschalten ist, dass die Mails (also alle Konten von Torstens-Buecherecke.de) synchronisiert werden.

Die erste Erkenntnis in dem Kontext war, dass der SSD Server mit Plesk die Mails anders ablegt (Maildir Format) als der mit HDD (MBOX Format).

Kurz gesagt stehen beim MBOX Format alles Mails als Text in einer großen Datei, während bei Maildir eine Ordnerstruktur angelegt wird und die Mails alle einzeln abgelebt werden. Tja, wäre ja auch zu einfach gewesen, wenn mal was auf Anhieb klappt.

Für eine Synchronisation war das nicht gerade eine gute Ausgangsbasis. Also hieß es entweder die Mails auf einem Server komplett löschen und dann synchronisieren oder eines der Formate umwandeln und dann synchronisieren. Ich habe mich für letztere Variante entschieden. Das war im Nachgang nicht die beste Idee.

Die Sychronisation mit Dovecot war dann auch nicht so gut dokumentiert wie erhofft (das ist leider bei Linux öfter so). Jetzt läuft es aber nach ziemlich viel probieren endlich. In Summe hat mich am Ende sehr viel Zeit gekostet, dass ich einen Buchstaben übersehen habe und die Dokumentation wie gesagt recht bescheiden ist.

Zusätzlich ist der Mailserver nun SNI Fähig (das heißt er kann mehrere Domains mit den passenden SSL Zertifikaten bedienen). Faktisch sieht es jetzt so aus, als wenn für jede Domain ein einer Mailserver arbeiten würde.

Natürlich gab es die aktuelle Version, die das unterstützt noch nicht für Ubuntu Linux und ich musste die Binaries kompilieren. Das ist immer ein Spaß. Wenn man gleich mehere Produkte auf den aktuellen Stand bringen muss und es bei einem in die Hose geht, hat man danach einen Scherbenhaufen.

Lange Rede kurzer Sinn. Der Mailserver ist jetzt sicherheitstechnisch auf dem aktuellen Stand und synchronisiert mit dem zweiten Server.

Wie üblich hat das alles wieder viel länger gedauert als vorgesehen. Aber in Summe wird der Server immer sicherer und besser.

Wobei ich was die Serversicherheit angeht mittlerweile einen Level erreicht habe der unter den Top 5-10% liegen dürfte. Also eigentlich ziemlicher Overkill für einen Blog. Aber das rumbasteln macht auch irgendwie Spaß und bei Linux ist es halt auch sehr nachhaltig. Das lässt sich alles problemlos und weitgehend automatisiert auf den nächsten Server übertragen. Man macht das alles also nur einmal.

Jetzt fehlt also nur noch das Umschalten der Namesever DNS Eintrage uns danach sollte alles funktionieren wie vorher aber an einem neuen Ort. Mal sehen wann ich das angehe. Da DNS auch mit DNSSEC gesichert ist, muss das aber zuerst deaktiviert und anschließend neu aufgesetzt werden.

Am Blog hat sich nicht so viel getan aber ich hatte letzte Woche davon berichtet, dass ich einen Cookieblocker für den Blog in Betrieb genommen habe. Abseits davon, dass der nun alle paar Tage mit Autoscans nervt (die nebenbei bemerkt nett gemeint aber ziemlich sinnfrei sind), funktioniert er offenbar wie erwartet. Mal sehen, ob mir das mit der Zeit auf den Senkel geht.

Ich habe zu dem Thema nun einen Blogartikel geschrieben.

Weitere Leselaunen:

Endlich habe ich Sekiro! bei Andersleser ∗ Überraschung, Freunde und Leselust pur bei Taya’s Crazy World ∗ For the Horde & Comics bei TrallafittibooksSemesterferien bei cbee talks about books ∗ Buchliebhaber & Seriensuchti bei Letterheart

Cokies DSGVO konform im Blog [Kommentar]

Einleitung

Zuerst möchte ich auf meinen ursprünglichen Blogbeitrag zum Thema Addons und DSGVO verweisen. Wär sich für eher witziges zu dem Thema interessiert, der ist in diesem Beitrag gut aufgehoben.

Obwohl die entsprechende Gesetzesgrundlage nicht mehr neu ist, gehen die Auslegungen der Texte wie üblich auseinander. Während einige der Meinung sind, dass Cookiebanner reichen, gehen andere Weiter und meinen, dass die DSGVO nahelegt beim initialen Aufruf der Seite nur notwendige Cookies zu speichern, bis der Anwender einer weiteren Verwendung zustimmt.

Dieser Blogbeitrag ist keine Rechtsberatung und auch keine Aussage, dass ihr damit eure Seite rechtskonform betreiben könnt. Ich lege die DSGVO aber so aus, dass ein Informationsbanner nicht reicht und der im folgenden Dargestellte Ansatz erforderlich ist.

Hintergrund ist, dass so wenig wie möglich Daten in Bezug zum Benutzer (personenbezogene Daten) gespeichert werden.

Verschiedene Ansätze

Es gibt Plugins, die lediglich Informationsbanner anzeigen frei nach dem Motto – “Diese Seite verwendet Cookies, sie können dies mit ok bestätigen oder die Seite verlassen”. Wenn der Nutzer dies sieht, sind aber zumindest die Cookies von der Startseite bereits abgelegt worden. Es ist also eigentlich zu spät.

Das viel verwendete XXX stellt eine Funktion bereits, die es erlaubt Skripte erst auszuführen, nachdem der Anwender die Cookies bestätigt hat. Das ist zwar nett gemeint, geht aber meiner Meinung nach vollkommen an der Realität vorbei.

Man installiert in der Regel ein beliebiges Addon (z.B. Übersetzer, Jetpack, …) und dieses legt eigenmächtig Cookies ab. Selbst wenn man das Skript zur Cookieablage identifiziert ist es aber unrealistisch das Skript aus dem Addon auszubauen und in das Cookieaddon zu kopieren.

Wenn ihr das versucht, wird es aufgrund des nicht geladenen Codes / Ladereihenfolge wahrscheinlich zu Problemen kommen. Selbst wenn das nicht der Fall ist, wird beim nächsten Update der Code wieder in das Plugin kopiert und automatisch ausgeführt. Das ist also vollkommen unpraktikabel.

Es muss also eine Lösung her, die die Ausführung von bestimmten Skripten / Addons / externen Aufrufen (denn meistens wird extern Code nachgeladen oder Daten an externe Adressen übertragen) blockt.

Die Plugins

Wie bereits erwähnt habe ich bisher das Plugin Cookie Notice verwendet, das auf sehr vielen Blogs installiert ist. Aus meiner Sicht stellt dies aber keine rechtskonforme Lösung dar bzw. die lässt sich praktikabel damit nicht umsetzen.

Das einzige kostenlose Addon für eine mutmaßlich rechtskonforme Abbildung, das ich gefunden habe heißt Complianz. Im Folgenden werde ich mich mit diesem Plugin beschäftigen.

Eine weitere Variante, die für den Normalblogger noch in einem bezahlbaren Rahmen liegt ist Borlabs Cookie, dass 40€ pro Jahr kostet. Leider gibt es keine kostenlose Testversion.

Es gibt z.B. auch noch Cookiebot, dass ich kurz getestet habe (hat bei mir nicht funktioniert) und es ist für den Normalblogger vollkommen unbezahlbar. Man befindet sich bei einem kleinen Blog wie meinem schon in Regionen von über 10€ pro Monat.

Warum sind Cookies böse?

Per se sind Cookies erst mal nicht gut oder böse. Sie dienen schlicht der Ablage von Informationen über eine Browsersitzung hinaus. Oft werden sie aber auch verwendet, wenn es eigentlich nicht nötig ist.

Beispielsweise verwende ich ein Übersetzungs Plugin auf dem Blog. Das speichert die eingestellte Sprache. Da aber die Browsersprache abgefragt wird und man mit PHP auch die Möglichkeit hat Sitzungsinformationen zu speichern (ohne Cookies) ist das Cookie ziemlich überflüssig. Schlimmer noch, dass Plugin setzt sogar mehrere Cookies.

Die sind aus DSGVO Sicht inhaltlich wahrscheinlich nicht problematisch, da lediglich die ausgewählte Sprache gespeichert wird.

Anders sieht es aus, wenn das Cookie zur Identifikation verwendet wird. Beispielsweise könnte Facebook im rahmen der Einbettung des Like Buttons ein Cookie platzieren, dass dazu dient mich eindeutig zu identifizieren. Somit ist dann später ersichtlich, dass ich auf Blog x war, bei Amazon eingekauft habe und auf irgendwelchen anderen Blogs oder Social Networks war. In Kombination lässt sich dann Mein Surfverlauf nachvollziehen. Das will die DSGVO verhindern.

Externe Aufrufe

Externe Aufrufe können aber müssen nicht mit Cookies einhergehen. Grundsätzlich gibt es aber vergleichbare Probleme wie bei den Cookies. Es werden möglicherweise Informationen zum Besucher übergeben (z.B. die IP), die als personenbezogenes Datum gilt und mit der sich wieder der Surfverlauf nachvollziehen lässt.

Die Umsetzung des Cookieblockens

Obwohl Complianz einen nett gemeinten Automatikmodus bietet, der aber eher lästig als hilfreich ist (besonders, wenn man Caching Addons benutzt), muss man erst mal wissen wo und wann die Cookies geladen / erzeugt werden bzw.

Wo liegt das Problem beim Automatikmodus? Der Automatikmodus ruft einfach wahllos ein paar Blogseiten auf und prüft welche Cookies dort gesetzt werden. Manche Cookies kommen aber nur an bestimmten Stellen zur Anwendung. Beispielsweise bei der Kommentarfunktion oder im Gästebuch, wenn ein Youtube Video (die kann man übrigens Datensparsam einbetten – das bietet Youtube selbst an) auf der aktuellen Seite eingeblendet ist usw. Der zufällige Test bringt also wenig.

Wie bekommt ihr also raus welche Cookies geladen werden. Dafür gibt es verschiedene Ansätze. Zuerst solltet ihr zur Auswahl der zu prüfenden Seiten den gesunden Menschenverstand einsetzen.

Die Hauptseite muss müsst ihr auf jeden Fall prüfen. Dan solltet ihr ggf. das Gästebuch, eine Seite mit Kommentarfunktion usw. testen. Im Prinzip alle Varianten (wenn ihr einen Blogbeitrag mit Youtube Videos habt, solltet ihr auch den testen usw.).

Ghostery

Es gibt Browseraddons (Ghostery) wobei das nach meinen Tests etwas über das Ziel hinausschießt. Das zeigt nicht nur gesetzte Cookies an, sondern auch welche die sich im Code der Seite befinden aber noch nicht aktiv sind bzw. auch Tracking abseits von Cookies.

Trotzdem kann Ghostery sehr hilfreich sein da ihr auch damit die Domains ermitteln könnt, die potenziell geblockt werden sollten.

Ghostery Addin für Browser

Ghostery Addin für Browser

Webkoll

Bessere Erfahrungen habe ich mit Webkoll gemacht. Wenn ihr bereits eine Content Security Policy eingerichtet habt, dann wisst ihr schon welche Skripte nachgeladen werden. Das ist schon eine gute Basis. Wenn ihr noch keine Contenct Security Policy habt oder euch fragt was das ein soll, dann ist das auch nicht schlimm.

Zur Content Security Policy werde ich ggf. noch einen separaten Blogbeitrag schreiben (die habe ich letztes Jahr eingerichtet). Das Thema würde hier aber den Rahmen sprengen. Meine Policy ist nicht perfekt aber ein Anfang. Ich halte den Ansatz die Policy so umzusetzen, dass Webkoll sie als grün anzeigt allerdings auch für nicht für praktikabel. dann kann man vermutlich alle drei Tage nachpflegen, weil irgendwas auf der Seite nicht funktioniert.

Mit Webkoll könnt ihr prüfen welche Cookies eure Seite setzt. Wenn ihr die Kommentarfunktion testen wollt, müsst ihr die Test URL entsprechend so setzen, dass ihr damit die Kommentarseite aufruft.

Beispielsweise sieht die Prüfung bei Webkoll auf meiner Bloghauptblogseite mit aktiviertem Complianz nun so aus:

Webkoll First Party Cookies

Drittanbietercookies gibt es keine und die gesetzen Cookies sind harmlos in Bezug auf personenbezogene Daten. Das ist gut.

Webkoll - Third Party

Die Drittanbieteranfragen können problematisch sein, weil die Daten abseits des eigenen Servers zum Teil in den USA gespeichert werden.

Das sieht nach wie vor nicht optimal aus, ist aber deutlich besser als vor dem Einsatz des Addons (da waren es deutlich mehr).

Bestimmte Skripte lassen sich nicht deaktivieren, weil dann die Seite nicht mehr funktioniert. Beispielsweise kann ich s0.wp.com nicht deaktivieren, weil das zu Jetpack gehört. Das merkt man spätestens, wenn die Seite nicht mehr vollständig funktioniert, nachdem man eine Domain in die Ausschlussliste aufgenommen hat.

Complianz

Im Complianz Skript Center fügt man nun die Domains hinzu, die man blocken möchte. Das Blocken klappt nicht immer aber für die dargestellten Domains funktioniert es bei mir:

Compliance Reiter Skript-Creator

Wenn der Benutzer nun das Cookiebanner zu sehen bekommt und nicht zustimmt, werden auch keine Drittanbietercookies gesetzt.

Plugins / Dienstleistungen

Complianz Reiter Plugins

Das ist so nicht richtig. Weder wird zum Beispiel Jetpack gelockt, noch werden die Plugins weitgehend automatisch erkannt. Das ist trügerische Sicherheit.

Zusätzlich könnt ihr über die beiden anderen Reiter Dienstleistungen und Plugins aktivieren werden, die ihr nutzt. Anschließend werden automatisch die Informationen zu den Cookies in die Cookie Richtlinie aufgenommen, die automatisch erstellt wird.

Complianz Reiter Dienstleistung

YouTube Ja oder nein. Bei datensparsamer Einbindung heißt die Antwort wohl eher nein

Die Automatismen schießen aber gern über das Ziel hinaus. Wenn ihr beispielsweise Youtube aktiviert, werden diverse Cookie als angeblich auf der Seite enthalten dokumentiert. Wenn ihr allerdings die datensparsame Variante der Einbettung nutzt, ist keins davon vorhanden.

Gleiches gilt, wenn ihr Facebook oder Twitter auf eurer Seite nutzt. Je nach Einbettung (zum Beispiel über Shariff werden die Cookies nicht gesetzt. Wenn ihr aber Facebook und Twitter markiert, werden zig Cookies als angeblich auf eurer Seite vorhanden markiert, die ihr überhaupt nicht nutzt.

Cookie Zustimmung

Minimalfunktion mit wenig Cookies oder komfortabler mit allen? Die Texte sind alle frei anpassbar

Ich finde der Rest des Plugins ist relativ selbsterklärend. Es gibt auch einen Assistenten den man arbeiten sollte und an dessen Ende die Cookie Richtlinie automatisiert erstellt wird.

Wenn ihr bessere Plugins / Lösungen habt oder Erfahrungen mit Borlabs, hinterlasst mir bitte einen Kommentar.

Wo ist der Haken?

Die Automatismusfunktion zum Scannen nach Cookies lässt sich offenbar nicht aktivieren. Die führt dazu, dass nach Aufruf der Administrationsseite des Blogs stattdessen wahllos irgend eine Seite des Blogs aufgerufen wird. Wenn ihr Caching Addons verwendet passiert dann immer wieder. Das lässt sich dann nur vermeiden, wenn man andere Seiten in der Administration wie zum Beispiel die Updateseite oder ähnliches aufruft. Das ist nervig und unnötig.

Im schlimmsten Fall landet ihr also in einer Endlosschleife und müsst das Addon (temporär) deaktivieren.

Offenbar verwenden 90% der Nutzer nur die Automatikfunktion, ansonsten wäre es viel Sinnvoller gewesen, wenn man bestimmte Testseiten angeben könnte, die der Reihe nach aufgerufen werden und anschließend automatisch auf die Hauptseite gewechselt würde. Das wäre sogar vollständig im Hintergrund möglich.

Angenehmer Nebeneffekt

Durch das Blocken der Cookies wird das Laden der Webseite beschleunigt. Selbst auf einem oft lahmenden Sever wie meinem, bekommt man so also einen relativ guten Google Pagespeed Score, weil weniger auf externe Ressourcen zugegriffen wird, da Pagespeed beim Aufruf die Cookies bzw. das Nachladen von externem Code nicht aktiviert.

So lässt sich der Pagespeed Score und somit das Ergebnis in der Google Suchmaschine leicht verbessern. Das trifft allerdings erst zu, wenn die Webseite gecacht ist (außer bei einem sehr schnellen Server). Das heißt in der Regel sehr ihr den Effekt bzw. ein gutes Ergebnis erst beim zweiten Aufruf.

Die Messung von Google ist relativ unrealistisch, da die reale Ladezeit kaum berücksichtigt wird (Dektopmessung – Mobil liegt die Messung bei 87).

Pagespeed Desktop

Der Pagespeed Wert ändert sich aber eh ständig. Desto mehr Fotos / Screenshots ihr nutzt, desto mehr Daten werden übertragen und desto langsamer wird die Webseite.

Alles Rechtskonform oder wie?

Wie oben bereits angemerkt werden Gesetze von Anwälten und Richtern ausgelegt. Definitiv klar ist, das eine Sperre besser als ein Banner ist, das lediglich auf Cookies hinweist.

So lange man mit dem Blog kein Geld verdient, wird man vermutlich erst mal nicht direkt Gefahr laufen eine Abmahnung zu bekommen. Im Kontext von Unternehmen haben die Datenschutzbehörden aber durchaus schon Strafen in exorbitanter Höhe verhängt. Von daher sollte man in einem Privatblog zumindest belegen können, dass man sich mit dem Thema beschäftigt und Anstrengungen unternommen hat.

1 2 3 4