Schlagwort: Kommentar

Raspberry Pi 4B vs. Contabo VPServer Performance [Kommentar]

Kommentar hinterlassen

Was ist ein Raspberry Pi (Kurzform Raspi oder einfach Pi)?

Ein Raspberry Pi ist ein kleiner Computer. Wobei klein primär auf die Größe zutrifft. Die Leistung ist ziemlich beeindruckend. Der Pi hat 2x USB 3.0, einen microSD Karten Leser und 2xHDMI mit 4K Auflösung.

Raspberry Pi 4b

Raspberry 4b pur

Im Privatbereich hat man (wenn man Handys mal außer acht lässt) primär mit x86 Computern zu tun. Der Pi basiert aber auf ARM Basis. Warum das durchaus ein relevanter Unterschied ist, werde ich in einem weiteren Blog Post darstellen, in dem es darum geht den Pi als Webserver zu verwenden.

Raspberry Pi Gehäuse

Raspberry Pi 4b im iuniker Gehäuse mit passier Kühlung. Man sieht auf dem Foto was gekühlt wird bzw. welche Anschlüsse vorhanden sind.

Der Pi wird oft von Bastlern verwendet aber nachdem ich ihn nun in Aktion erlebt habe muss ich sagen, dass der Pi 4 für viele Bastelprojekte bereits reichlich überdimensioniert ist. Der Kleine hat ganz schön Power!

Der Pi bootet im Standardmodus von der SSD. Der Raspi ist selbst in der größten Konfiguration mit 4GB RAM für weniger als 60€ zu haben.

Allerdings bleibt es in der Regel nicht bei den 60€ (siehe unten).

Warum ein Raspberry Pi?

Aufgrund von der Kurzarbeit habe ich aktuell recht viel Zeit aber nicht mehr Geld und da man ja eh zu Hause bleiben soll(te) bieten sich halt Dinge an, die man zu Hause erledigen kann und die nicht so viel kosten.

Aufgrund der vielen positiven Eindrücke, die ich durch Berichte in der c’t oder auch im Web vom Raspberry Pi gewonnen habe, war ich schon eine Weile neugierig was man damit anstellen kann.

Etwas geprägt ist man von vielen Kommentaren im Netz, die sich oft auf ältere Versionen des Pi beziehen und ihn als zu langsam für xyz einstufen. Eins Vorweg und ich habe es oben Bereits erwähnt: Der Kleine ist ganz schön schnell und sehr energieeffizient. Man darf natürlich nicht erwarten, dass man damit einen vollwertigen Desktop PC ersetzen kann. Bei weniger als 10 Watt Gesamtverbrauch kann man das aber wohl auch nicht erwarten.

Boxenstopp

Das ein Beitrag entsteht, bei dem ein vollwertiger VPS (was auch immer das bei einem VPS bedeutet) gegen den kleinen Pi antritt, erschien mir vor meinen Erfahrungen nicht sinnvoll.

Bei einem “Computer” für 60 € habe ich nicht mit einem Performanzwunder gerechnet. Ich wurde aber positiv überrascht. Zugegeben ich habe den Pi auch nicht in der Standardkonfiguration benutzt. Ich habe ihn moderat übertaktet  (CPU 1650 statt 1500 und GPU 600 statt 500 MHz – ohne Erhöhung der Spannung). Das sind aber nur etwas über 10% mehr.

Es sind aber (je nach Güte des Pi) Übertaktungen mit 2Ghz oder mehr möglich (etwas über 30%). Dann natürlich mit erhöhtem Strom Kühlungsbedarf. Die ersten zwei Tage habe ich den Raspi mit der Auslieferungsfirmware betrieben (mit etwas mehr Overclocking 1750 / 600 / Overvoltage 2) und er hatte unter Dauervollast gute 75°C.

Nachdem ich jetzt die aktuelle Firmware drauf habe (Achtung: Die Firmware kann / sollte man nur mit Raspian installieren – wenn man also wie ich Ubuntu drauf packt, sollte man zuerst Raspian installieren), begnügt er sich unter Vollast mit unter 60°C – im Schnitt sind es 45°C und bei 80°C drosselt er. So kann man ihn also bedenkenlos rund um die Uhr betreiben.

Mein Setup

Ich habe gesehen, dass Ubuntu 20.04 LTS für den Raspi 4 verfügbar ist. Da der Raspi zwei USB 3.0 Anschlüsse hat, kann man über eine dort angeschlossene SSD die Geschwindigkeit von Scheib- /Lesezugriffen deutlich steigern, speziell wenn man von der SSD bootet (das ist offiziell noch nicht vorgesehen, wenn man sich etwas auskennt aber nicht so schwer. Ich werde dazu noch einen separaten Blogpost erstellen – und ja, die microSD wird für den Kernel aktuell trotzdem benötigt, aber die Root Partition kommt von der SSD).

Ich habe den Raspi mit einem Pluggable NVMe / M2 Gehäuse kombiniert und dort eine M2 SSD eingebaut, die ich später z.B. auch in einem Notebook oder PC verwenden kann, wenn ich sie im Raspi mal nicht mehr benötigen sollte. Weiterhin kann man das Gehäuse + M2SSD auch als extrem Schnelle Mobile Transportmöglichkeit von Daten verwenden.

Plugable USB C nach M.2 NVMe Gehäuse

Plugable USB C nach M.2 NVMe Gehäuse

Als Dateisystem verwende ich auf der gesamten SSD Btrfs mit ZSD1 Komprimierung. Das sorgt für sehr gute Platzeffizienz aber vermutlich (etwas) geringere Schreibraten bei den Benchmarks.

Die Komponenten:

  • Raspberry Pi 4B – ca. 60€
  • HDMI Kabel – 10€
  • iuniker Gehäuse (Passive Kühlung von USB, Power, RAM, CPU durch Metallblock) – 15€
  • Originalnetzteil – 10€
  • microSD Karte San Disk Extreme 64GB (Achtung, die SD Karte sollte über 40MB/Sekunde schreiben können (nicht nur lesen!) – 15€
  • Optional: NVMe / M2 Gehäuse (mit Kühlung über das Gehäuse) – ca. 60€ (vergleichbare Gehäuse gibt es auch schon gut 20€ günstiger, dann allerdings nicht mit werkzeugloser Montage)
  • Optional: WD SN550 M2 SSD 1TB – 140€ (je nach Zweck reicht auch halbe Größe oder noch weniger)

In Summe ca. 100€ für den Raspberry Pi 4B mit Zubehör und dann noch mal 200€ für die optionalen Teile, die der Pi nicht braucht und von der Geschwindigkeit ist zwar ein Sprung da aber keineswegs so groß wie der Preis es erwarten lassen würde. Darum ging es mir aber auch nicht bzw. das habe ich nicht erwartet. Eine Standard SSD reicht vollkommen für den Pi. Man benötigt aber in jedem Fall einen Adapter mit USB 3.0 Anschluss.

Wenn die nächste Generation USB 3.1 unterstützen sollte, dann wird die mögliche Geschwindigkeit noch mal deutlich gesteigert.

Der Pi kostet also in einem bereits ziemlich flotten Grundsetup etwas über 100€. Wenn man einzelne Teile wie die microSD Karte oder das HDMI Kabel schon hat, dann wird es etwas günstiger.

Update 03.07.2020

Die NVMe SSD würde ich für den Pi nicht mehr kaufen. Ich habe die primär gekauft, weil ich für eine zukünftige anderweitige Verwendung flexibel sein wollte. Im Nachgang wäre eine 2,5″ Sata SSD aber die bessere Variante gewesen. Das liegt daran, dass Sata SSD Gehäuse schon für 10€ zu haben sind und die SSD selbst auch minimal günstiger gewesen wäre. Weiterhin ist der Pi mit der Stromversorgung am Limit. der zweite USB 3.0 Slot ist nur noch mit einem Micro SD Kartenleser nutzbar. Selbst der Anschluss einer externen USB HD mit einer Stromversorgung sorgt zum Absturz mangels genügend USB Strom. Dem könnte man natürlich mit einem Hub entgegen wirken aber irgendwann macht der Pi dann auch keinen Sinn mehr, wenn man den Stromverbrauch zu sehr in die Höhe treibt.

Pi vs. VPServer – ist das nicht unfair?

Man sollte meinen, dass der Vergleich unfair ist aber der Raspi 4 ist teilweise erstaunlich nah an der VPS Performance dran. Zumal die Geschwindigkeit bei einem VPS je nach Tagesform und der Auslastung durch die Nachbarn auf dem VPS sehr stark schwanken kann.

In Einzelbereichen wie dem SSD Zugriff ist der PI immer deutlich schneller als der VPServer bei Contabo (das ist übrigens auch die größte Schwachstelle der Contabo VPServer).

Wenn man weiterhin überlegt was ein VPS mit SSD pro Monat kostet (mit brauchbarer Performanz und genügend SSD Speicherplatz ist man mit mindestens 5€ pro Monat unterwegs aber auch schnell bei 10 oder 15€), kann der Raspi sogar dazu genutzt werden – sehr kostengünstig – selber einen Webserver @home zu betreiben bzw. einen VPS zu ersetzen. Der Raspi wird im Regelfall auch nach Jahren noch seinen Dienst tun, da es keine Verschleißteile gibt.

Der Stromverbrauch ist ziemlich gering und auch nicht höher als zum Beispiel bei einer FritzBox. Selbst in einem Schlafzimmer kann man den Pi unterbringen, weil er sehr wenig heizt und keine Geräusche macht.

Der Betrieb als Webserver setzt einen entsprechend flotten Internetanschluss voraus. Die Anbindung des Raspi mit 1GBit ist viel schneller als die der meisten VPS Anbieter. Der RAM ist mit 4GB relativ klein (ich habe aber alle Anwendungen von meinem VPServer auf den PI gebracht und das schafft er spielend (Apache2, Nginx, MySQL 8, Elasticsearch, Proftp, Webdav, Samba, Postfix Mailserver, Dovecot, Nextcloud, Fail2Ban, FirewallD, Bind DNS, OpenDKIM, LDAP, Memcached, Redis, PHP, OpenVPN, Webmin).

Die Daten und Benchmarks Raspberry Pi vs. Contabo VPS

Vor einer Weile habe ich auch Ergebnisse von verschiedenen VPServern (Strato und Contabo SSD / HDD untereinander gegenübergestellt. Der Post dazu findet sich hier)

CPU
Sysbench – Raspbery Pi 4B CPU (CPU 1650 / GPU 600)

Sysbench CPU Speed Raspberry Pi 4

1637,79 * 4 = ca. 6551 (ja, ich weiß die Skalierung ist schlechter aber es dient primär zum Vergleich)

Sysbench – Contabo VPS 1400 – 6 virtuelle Kerne = 3 physische CPU Kerne

Sysbench CPU Contabo VPS 1400

= 775,77 * 6 (ca.) = 4650 (ja, ich weiß die Skalierung ist schlechter aber es dient primär zum Vergleich)

Geekbench – Raspberry Pi 4B CPU (CPU 1500 / GPU 500) – nicht von mir Ermittelt, sondern aus Geekbench Datenbank, da Geekbench offiziell auf ARM nicht verfügbar ist

Raspberry Pi 4 Geekbench 5

Geekbench – Contabo VPS 1400 – 6 virtuelle Kerne = 3 physische CPU Kerne

Contabo VPS 1400 Geekbench 5

Zumindest beim Geekbench deutliche Vorteile für den VPS.

Memory
Sysbench – Contabo VPS 1400 – 20GB RAM

Sysbench Memory Contabo VPS 1400

Sysbench – Raspbery Pi 4B – 4GB

Sysbench Memory Raspberry Pi 4

Der VPS ist ca. 50% schneller aber wo / wann merkt man das? Auch hier also eher unentschieden.

IO / Schreib- / Leseperformanz

Anmerkung: Die Performanz bei einem VPS kann extrem schwanken. Das betrifft bei Contabo vor allem die IO Performanz (also die Schreib- / Leseraten). Ich habe selbst auf einem SSD Server Schreibraten Bandbreiten zwischen 20 und 150MB pro Sekunde gesehen. Das ist für eine SSD nebenbei bemerkt beides nicht toll.

Auf Contabo Festplattenservern habe ich die gleiche Bandbreite beobachtet allerdings ist die Latenz dort teilweise im Sekundenbereich. So schlimm ist es bei SSDs in der Regel nicht.

Ich werde ggf. noch einen separaten Thread dazu erstellen. Wenn man Contabo darauf anspricht wird der VPS ggf. auf einen anderes Host System umgezogen. Das liegt offenbar jeweils im Ermessen des Technikers.

Raspberry Pi 4B (4 Kerne, 1000GB SSD, 4GB RAM) – Btrfs mit ZSD1 Kompression

Sysbench IO Performance Raspberry Pi 4 Sequential Write

Contabo VPS L (8 Kerne, 800GB SSD, 30GB RAM) – ext4 ohne Kompression

Contabo VPS L Sysbench IO Sequential Write

Bei dem Test sieht der VPS ganz alt aus gegen den Pi. Besonders die Latenz ist oft um Faktor 5 bis 15 Höher als beim Pi.

Eindeutiger Sieger Pi.

WordPress DB Bench / PHP Bench
Raspberry Pi 4B (4 Kerne, 4GB RAM, CPU 1650, GPU 600)

Wordpress Database PHP Performance Raspberry Pi 4

Anmerkung der PHP Test mit 99,99 Sekunden ist kaputt. Der Pi ist so schnell, dass es vom Programm nicht messbar ist.

Bzgl. der SQL Performance ist anzumerken, dass ich die diversen MySQL Einstellungen an den RAM des Pi angepasst habe. Der VPS hat also deutlich mehr RAM zur Verfügung und 8 Kerne statt 4.

Contabo VPS L (8 virtuelle Kerne, 800GB SSD, 30GB RAM)

Contabo VPS L WordPress Database PHP Performance

Anmerkung der PHP Test mit 99,99 Sekunden ist kaputt. Der VPS ist so schnell, dass es vom Programm nicht messbar ist.

Die 135 Queries pro Sekunde sind ein Durchschnittswert – ich habe auch schon 50 Queries pro Sekunde gesehen oder 250 (nur einmal) – immer auf demselben VPS Modell! Alles oberhalb von 50 ist aktuell ausreichen für meinen Blog.

Sieger in dieser Rubrik ist meist der VPS, manchmal ist der Pi aber sogar flotter.

Welche Vorteile hat ein Pi @home im Vergleich zu einem VPS bei einem Hoster?

  • Hervorragende IO Performanz (die sollte der VPS lt. Werbung auch haben, hat er aber oft nicht.
  • Physischer Zugriff – man kann Teile tauschen, ohne Webinterface neu starten, Geräte anschließen usw.
  • Modernes Desktop Linux ohne VNC / RDP usw.
  • Der Pi ist viel universeller – man finden unzählige Beispiele für Bastelprojekte, Homeserver für Filme, Musik usw.

Wo sind die Nachteile eines Pi 4B @home im Vergleich zu einem VPS bei einem Hoster?

Wo viel Licht ist, da gibt es auch Schatten. Einige Punkte sind offensichtlich und haben nichts dem Pi zu tun, sondern lediglich damit, dass man ihn von zu Hause betreibt.

  • Wenn man Backups außerhalb des eigenen Hauses erstellen will (Stichwort möglicher Haus- / Wohnungsbrand), dann hilft es nichts den Pi zu Hause zu installieren (ironische Randnotiz: der Pi ist natürlich ein weiteres Gerät, dass man ggf. rund um die Uhr betreibt und die Gefahr eines Brandes minimal erhöht).
  • Der Pi belastet die eigene Leitung (primär im Upload). Andersrum kann der Pi ggf. von außen fast nicht erreichbar sein, wenn man selber etwas ins Internet hochlädt.
  • Wie oben angemerkt, basiert der PI auf ARM Architektur. D.h. nicht jedes Programm läuft. Ich bin bisher nur auf sehr wenige Programme / Bibliotheken gestoßen, die ich brauche und die nicht laufen – Beispiele – Teamspeak, Geekbench, Collabora Online, Google Pagespeed, Elasticsearch (das läuft mit Tricks, bei mir läuft die Software nun mit Version 7.4). Teilweise bekommt man die Programme mit Emulatoren zum laufen aber das ist oft ineffizient und instabil.
  • Einen DNS Server oder Mailserver wird man nur mit einer festen IP betreiben können. Die bietet nicht jeder Heimanschluss.
  • Stromkosten wobei die (ich habe nicht selber nachgerechnet lt. einer Beispielrechnung selbst bei durchgehender Vollast bei unter 20€ pro Jahr liegen sollen). Ald Webserver liegt der Pi eher bei 25% Last. Auch das RAM ist in der Regel nur zur 50-75% gefüllt (je nach Einstellungen).
  • Lenkt ggf. Script Kiddies oder andere Angreifer auf die eigene IP Adresse
  • Der Zeitaufwand einen Pi aufzusetzen ist geringer als bei einem VPS Server – speziell wenn man dort ein fertiges Image mit Plesk nutzt (was die Kosten noch mal >5€ pro Monat hoch treibt). Mit etwas Erfahrung ist der Zeitverlust aber überschaubar.

Fazit:

Was als Experiment und ausschließliche Backuplösung begonnen hat, hat sich nach nun ca. 4 Tagen zu einem vollwertigen Server entwickelt. Natürlich kann der Pi nicht mit einem Desktop PC mithalten. An der Leistung eines VPS in einigen Bereich erstaunlich nahe dran und die beiden VPS, die ich zum Vergleich genutzt habe kosten immerhin 13 bzw. 15€ pro Monat. Ein Pi amortisiert sich also ruck zuck im Vergleich. Selbst in der oben dargestellten Luxusausstattung hat sich der Pi in weniger als 2 Jahren amortisiert.

Aufgrund der ARM Architektur habe ich mich aber zu einer vollständigen Neuinstallation von allen Programmen entschlossen. Mir war das Risiko zu groß beim Kopieren vom x86 Server nicht lauffähige Elemente auf den Pi zu bringen. Lediglich die Konfiguration habe ich an vielen Stellen als Vorlage genutzt.

Der Pi 4 ist auf jeden Fall weit mehr als Bastelei oder Machbarkeitsstudie. Wenn es um einen günstigen Rechner zum Surfen und ab und an Officeanwendungen geht, kann man den Pi absolut empfehlen. Für 100€ bekommt man eine Menge geboten. Selbst für die Eltern, die außer ein wenig Office und Surfen nichts machen ist der Pi eine Gute Lösung. Günstiger geht es zumindest nicht.

Update 03.07.2020:

Nachtrag: Im Praxisbetrieb mit einer recht großen WordPress Seite und vielen Plugins ist der Pi, trotz der recht guten Daten gerade beim initialen Seitenaufbau (also dem Abarbeiten des PHP Codes) ziemlich langsam. Dafür ist die Rechenpower dann doch zu gering. Für einen WordPress Server würde ich also mehr Rechenpower empfehlen, wenn man nicht gerade ohne Plugins arbeitet. Eine Alternative zum Pi ist der Odroid H2+, der sogar als vollwertiger NAS nutzbar ist und deutlich mehr Power hat (gut 2x so schnell wie der Pi + AES Unterstützung und x86 Architektur).

Eine 50GB Nextcloud Installation läuft aber gut (einschließlich Indexierung und Suche). Man muss also den jeweiligen Anwendungsfall anschauen.

Für mich ist das so aber vollkommen ok, weil ich damit keinen VPS ersetzen wollte, sondern nur die Funktionalität des VPS weitgehend auf dem Pi haben wollte zwecks Tests und Backup.

 

 

Backups und das BTRFS Filesystem mit Linux Ubuntu 20.04 Focal Fossa und Backintime / Timeshift [Kommentar]

Kommentar hinterlassen

Die Ausgangslage

Nachdem ich mir einen neuen VPS (Virtual Private Server) angemietet habe, der ausschließlich auf SSDs setzt, ist die Schreib- / Leseperformanz zwar deutlich besser als vorher mit HDD aber SSD Speicherplatz ist nach wie vor teurer als klassische Festplatten. Somit sind VPS Server die auf SSD basieren teurer bzw. andersrum gibt es für das gleiche Geld deutlich weniger Speicherplatz. Bei Contabo ist der angebotene Speicherplatz ca. halb so groß wie bei den HDD Servern.

Somit hat sich mir die Frage gestellt, wie ich von dem alten Server mit 1,4 TB Speicherplatz auf einen Server mit 800GB umziehen kann ohne zu viel Sicherheit / Komfort zu verlieren.  Voll war der Server nicht aber es waren über ca. 950 GB belegt.

Ein guter Teil des Speicherplatzes auf dem Server ist von Backups belegt, die man auf einem Server unweigerlich benötigt, gerade auch wenn man mal etwas testet / ausprobiert. Neben dem Buchblog sind auf dem Server auch diverse andere Dienste. Der Blog nimmt eher den kleinsten Teil ein. Oft fallen Fehler auch nicht direkt auf, weil man nicht jede Funktion täglich nutzt. Somit schadet es nicht auch mal einen alten Stand einsehen zu können? War das schon immer so? Wie war es wann?

Backups aber wie?

Tägliche Backups speichern in der Regel von Tag zu Tag das gleiche (es ändert sich ja kaum was, wenn man zum Beispiel auf dem Blog ein oder zwei Beiträge verfasst). Viele Backuplösungen in Linux basieren auf Rsync. Rsync ist ein sehr gutes Tool zum synchronisieren zwischen zwei Verzeichnissen und bietet Funktionen wie Resuming / Checksummenprüfung usw. mit. Für Backups ist es aber nur bedingt geeignet, weil es die Daten einfach x Mal neu anlegt.

D.h. es werden bei einem Backupsystem (z.B. Daten der letzten 3 Tage, vorherigen 2 Wochen, letzten 2 Monate, letzte 2 Jahre = 3+2+2+3 = 10 facher Platz der Daten). Wenn man 50GB sichert, dann sind das mal eben 500GB nur für Backups. Dafür ist SSD Speicherplatz eigentlich zu schade.

Alternativ bieten sich Backuplösungen an, die Daten komprimieren. Diese lassen sich jedoch schlechter lesen. Einige Varianten müssen erst entpackt werden. Auf Linux gibt es z.B. Tar in Kombination mit einem Packverfahren. Das ist mit einer SSD und nicht zu großen Files ganz erträglich. Ein direkter Zugriff auf einzelne Dateien ist aber ziemlich unpraktisch, weil die ganze Datei gelesen werden muss (das ist der Teil wo die SSD durch höhere Leseraten den Prozess halbwegs erträglich macht). Wenn so eine große Datei beschädigt wird, kann es aber auch sein, dass das ganze Backup nicht mehr lesbar ist.

In einer grafischen Umgebung dauert das Öffnen zwar eine Weile ist aber von der Bedienung ansonsten erträglich. Wenn man auf der Kommandozeile arbeitet, wird es aber ziemlich unschön, weil es nicht einfach möglich ist Verzeichnisse zu entpacken oder ähnliches durchzuführen. Im schlimmsten Fall muss man also alles auspacken. Das benötigt Zeit und Speicherplatz.

Es gibt auch weitere Lösungen wie z.B. Bacula, was aber recht aufgebläht ist (ein Webfrontend – das benötigt also einen Webserver – für eine Backuplösung finde ich zum Beispiel ziemlich unglücklich). Im Zweifelsfall kommt man nur noch mit einer Rescuecd an den Server und dann sollte das Restore einfach sein.

Zusätzlich ist die Lösung halbkommerziell. Man kann sich also soweit ich das gesehen habe nicht einfach die aktuelle Version per apt install ziehen ohne einen Key dafür zu haben. Bei der 9.4er Version hat bei mir die Installation in Ubuntu 20.04 nicht funktioniert. Auch das ist nicht vertrauensbildend aber Ubuntu 20.04 holpert eh noch an so einigen Stellen aktuell.

Filesystem zur Backupunterstützung?

Ich hatte schon vor einer Weile von Dateisystemen wie BTRFS / ZFS angesehen aber die Guides zu dem Thema sahen nicht so einfach aus und die diversen Anmerkungen dies oder jenes ist nicht stabil oder “ich würde es nicht produktiv verwenden”, haben mich immer wieder abgehalten.

Für Btrfs spricht, dass es Komprimierung unterstützt. Das heißt die Dateien werden zum Teil deutlich kleiner, als im Original, sind aber transparent zugreifbar. Man benötigt keine extra Werkzeuge und kann direkt per Kommandozeile die Dateien zugreifen, ohne mit zusätzlichen Programmen / Befehlen zu hantieren (so als wenn sie nicht komprimiert wären). Zusatznutzen ohne Komforteinbußen hört sich immer gut an.

Weiterhin beherrscht Btrfs die Deduplizierung. In Obigem Fall von 10 Kopien wird also nur 1/10 des Platzes belegt, wenn sich die Daten nicht geändert haben. Wenn sich die Daten drei mal geändert haben dann eben 3/10 (ausgehend von ca. gleicher Gesamtgröße). Man steht also in Kombination mit der Komprimierung immer noch deutlich besser da.

Mein Backup mache ich mit Timeshift / Backintime. Beides sind Werkzeuge, die auf RSYNC basieren. In Kombination mit einem Filesystem wie BTRFS oder ZFS führ das aber in der Theorie zu einer deutlichen Verringerung des belegten Speicherplatzes. Die Komprimierung liegt ca. bei dem Faktor 2,5 bis 3. Allerdings werden nur bestimmte Datentypen komprimiert.

Ein weiterer Vorteil, der mich aktuell nicht interessiert ist die Snapshotfunktion. Diese Funktion hat mein Server über die SSDs bereits eingebaut. Ich kann also über den VPS 3 Snapshots erzeugen und zu diesen Ständen zurückkehren.

Diese Funktion werde ich ggf. Später testen. Die Snapshotfunktion ist z.B. interessant, wenn man ein neues Betriebssystem installiert und dabei geht etwas schief. Man kann damit sehr leicht und schnell zu einem vorherigen Stand zurückkehren. Beim Test von Ubuntu 20.04 hätte mir die Funktion wohl einen Tag Arbeit erspart. Mittlerweile habe ich es installiert aber ohne Snapshots (in meinem Fall direkt auf dem SSD Server, hätte ich das definitiv nicht gemacht).

Welches darf es den sein ZFS oder Btrfs?

Die oben genannten Funktionen bieten sowohl ZFS als auch Btrfs. Btrfs ist allerdings bei meinem VPS anbietet bereits in der Rescue CD integriert. Weiterhin bietet das auf der Rescue CD integrierte Pratitionierungswerkzeug Btrfs an und Btrfs bietet eine Migration von Ext4 nach Btrfs an. Besonders letzterer Aspekt klang reizvoll.

Da ich vorher einen Snapshot erstellt hatte, habe ich die Migration gestartet und nach grob 4-5 Stunden (auf einer SSD! – nur ca. 30-40MB pro Sekunden und nur ein Kern der CPU benutzt) war die Migration durch. Danach habe ich das Laufwerk gemountet und dann beim Boot diverse Fehlermeldungen bekommen. Scheinbar ist das mit dem Migrieren doch nicht so einfach wie versprochen. Die Warnung vorher Backups durchzuführen ist also absolut ernst zu nehmen.

Das Vertrauen in Btrfs und die Migrationsfunktion war bereits gesunken aber dank Snapshot habe ich einen zweiten Versuch gestartet. Der ist schon viel früher abgebrochen. Somit stand für mich fest, die Migration kann man vergessen. Theoretisch soll man die auch rückgängig machen können aber da ich einen Snapshot hatte, habe ich das gelassen.

Somit bin ich zu Ansatz zwei übergegangen. Eine neue Partition mit Btrfs zusätzlich zur vorhandenen

Nach den obigen Migrationsversuchen war das Vertrauen in Btrfs deutlich geschrumpft aber ganz ehrlich: Ich habe noch nie eine erfolgreiche Migration von einem Dateisystem in ein andres gesehen.

Backup mit Btrfs

Mein Hauptfokus lag auf der Verkleinerung der Backups also lag es nahe einen Teil der 800GB als Bbtrfs Partition anzulegen. Somit habe ich über das Rettungsystem Gparted gestartet und 200GB in Btrfs umgewandelt. Dort habe ich mehrere Subvolumes angelegt (Backintime, Timeshift, Root – für einen späteren Boottest, Snapshot – für spätere Snapshottests), dort kann man wiederum ein weiteres Subvolume für jedes Subvolume anlegen, von dem man Snapshots erstellen will).

Die Trennung der Snapshots hat damit zu tun, dass man die beim Zurücksetzen eines anderen Snapshots nicht verlieren möchte. Somit sollten man die separat halten.

Wichtig ist, dass man beim Mounten (ich habe direkt die Variante über die fstab Einbindung genutzt) die Komprimierung aktiviert. Die Daten werden dann während des Schreibens gepackt. Das komprimieren geht auch nachträglich, ist aber aufwendiger. Das Aktivieren der Komprimierung auf oberster Ebene hat sich auf die Subvolumes vererbt.

Anschließend kann man die Daten ganz normal auf das Laufwerk schreiben, dass in das Dateisystem eingebunden wird (in meinem Fall Verzeichnis btrfs mit den o.g. Unterverzeichnissen / Subvolumes).

Das Ergebnis vom Packen war bereits vielversprechend. Die Daten werden deutlich geschrumpft. Allerdings packt Btrfs mit den Standardeinstellungen nur die Daten, bei denen es eine deutliche Einsparung erwartet. Dateien bei denen das nicht der Fall ist, werden nicht gepackt. Man kann das erzwingen aber das habe ich bisher nicht getestet.

Der zweite Schritt ist das Deduplizieren. Das macht Btrfs nicht beim Schreiben, sondern man kann es nachträglich ausführen. Interessant ist dabei, dass man für jedes Subvolume einzelne Snapshots erstellen kann aber das Deduplizieren volumeübergreifend funktioniert.

Was bringt’s?

Bei obigem Beispiel würde also bei moderater Datenänderung zwischen 1/10 (Bester Fall fast ohne Änderungen der Daten) und 1/2 (bei deutlich mehr Änderungen) der Daten übrig bleiben. Wie sich in meinem Fall gezeigt hat sind es etwas mehr als 1/4.

Die o.g. Zahlen verstehe ich so:

Ursprünglich wurden durch die Daten 314GB belegt. Fast die Hälfte der Daten wurde komprimiert (152GB). Die komprimierten Daten hatten nach der Komprimierung noch ca. 1/3 der vorherigen Größe (das passt auch zu den Messungen die ich im Netz gefunden habe).

Der zweite Effekt ist die Deduplizierung, die in einem Backupszenario extrem gut funktioniert. Effektiv werden die vorher 314GB auf 86GB gespeichert. Das ist nicht schlecht dafür, dass ich den geringsten Kompressionslevel (ZSTD1) verwendet habe ohne erzwungene Komprimierung.

Es kann sein, dass man noch etwas mehr rausholen kann allerdings steigt die Rechenzeit dafür überproportional an. Sollten über die Komprimierung noch mal 5GB eingespart werden können, wird das ziemlich lange dauern bzw. zu sehr geringen Schreibraten führen. Den Effekt der erzwungenen Komprimierung kann ich nicht abschätzen.

Die Performanz beim Schreiben kann ich nicht wirklich bewerten, weil es sich um ein VPS handelt und die Performanz dort naturgemäß geteilt ist. Teilweise waren es 200MB, teilweise auch nur 50MB/s. Die Schreibgeschwindigkeit mit Komprimierung ist natürlich nicht so hoch wie z.B. bei ext4 ohne Komprimierung.

Die Frage ist was limitierend ist (wenn es die Schreibleistung der SSD / HDD ist, dann kann Btrfs schneller sein als ext4, wenn es die Rechenleistung des Prozessors ist, dann wird eher das Gegenteil der Fall sein, wenn man die Komprimierung verwendet).

Man möge mich korrigieren, wenn ich mit obigen Annahmen falsch liege aber meine Einschätzung der Daten oben deckt sich ca. mit der Ersparnis, sollte also richtig sein.

Ist Btrfs stabil?

Das wird die Zeit zeigen. Ich gehe im schlimmsten Fall das Risiko ein meine Backups zu verlieren. So lange ich nicht gleichzeitig die Originale kaputt mache, ist das Risiko begrenzt. Zumal ich bei dem SSD Server nun zusätzlich Snapshots anfertigen kann und somit (sofern ich denn vorher einen Snapshot erzeugt habe) auf diesen Stand zurückkehren kann. Das Risiko sollte also begrenzt sein.

Die Funktionen, die nicht stabil waren scheinen aber bereits vor zwei Jahren angepasst worden zu sein. Die Probleme bezogen sich auch primär auf Raid 5 / 6. Ich benutze kein Raid.

Aktuell konnte ich aber auch nicht erkennen, dass die Entwicklung voran getrieben wird oder zumindest kommunizieren die Entwickler das nicht. Die arbeiten offenbar eher im stillen Kämmerlein für sich selbst.

Somit sind die Guides alle nicht aktuell und vieles von dem was man dort findet ist veraltet. Einige Einstellungen sind überholt oder werden nicht mehr unterstützt.

Andersrum sind Werkzeuge wie die Deduplizierung nicht direkt integriert, sondern funktionieren über zusätzliche Tools, die oft auch mit nicht vertrauenserweckenden Kommentaren versehen sind (sollte funktionieren, sollte fehlerfrei sein). Der typische Informatikerkonjunktiv. Die Versionsstände sind oft alles andere als hoch 0.1x. Aber das muss alles nichts bedeuten. Bisher läuft es rund aber nach einer Woche ist das noch nicht viel Wert. 😉

Ein detailliertes How to zur Einrichtung von Btrfs in Kombination mit Luks Verschlüsselung habe ich ein einem separaten Blogpost erstellt.

Nachtrag 02.05.2020 – 22:00

Ich habe jetzt auch den Boot von Btrfs hinbekommen. Dafür habe ich mithilfe des Grubcustomizer einen neuen Booteintrag erzeugt und dort einfach die ID der Btrfs Partition angegeben und das entsprechende Subvolume. Die UUID bleibt immer die der Partition (auch wenn man Subvolumes adressiert!).

Beispieleinträge in der fstab:

UUID=f8fcb1ae-51b1-4ab2-b79d-66cf34ad77d9 /btrfs btrfs defaults,ssd,compress=zstd:1 0 0
UUID=f8fcb1ae-51b1-4ab2-b79d-66cf34ad77d9 /btrfs/ROOT/.snapshots btrfs defaults,ssd,compress=zstd:1,subvolid=422,subvol=/snapshots/ROOT_snaps 0 0

Was bedeutet das? Der Hauptknoten wird unter btrfs eingehängt. Alle untergeordneten Subvolumes werden dadurch automatisch gemountet. Der Zweite Eintrag mountet ein spezielles Subvolume auf /btrfs/ROOT/.snapshots. In der Subvolumehierarchie befindet sich das aber unter /snapshots/ROOT_snaps. Man muss immer aufpassen was Subvolumes und was Verzeichnisse sind. Im Verzeichnisbaum sieht das gleich aus.

Auch die Snapshotfunktion (zumindest das Anfertigen von Snapshots habe ich erfolgreich getestet).

Nachtrag 03.09.2020

Ich habe mittlerweile 2 Server komplett auf Btrfs umgestellt einschließlich dem ROOT Verzeichnis / Laufwerk. Somit spart man sich natürlich noch mal eine Kopie der Dateien und die Speicherung wird effizienter. Das setzt allerdings volles Vertrauen ins Dateisystem voraus.

Bisher hatte ich noch keine Probleme (auf Holz klopf), obwohl ich besonders den lokalen Sever auch schon mehrfach hart runtergefahren habe. Bei beiden Servern nutze ich keine Zusatzsoftware wie Timeshift / Backintime, sondern verwende die automatischen btrfs Snapshots über Snapper. Bei einem Server habe ich das Bootlaufwerk nicht umgestellt und nutze Btrfs nur für Backups mit Backintime und täglicher Deduplizierung.

Ich habe zwischenzeitlich auch noch Mal über ZFS nachgedacht aber die Deduplizierung funktioniert dort leider nur online und benötigt dann immens viel Speicher. Dazu kommt, dass Ubuntu zwar den Support eingebaut hat aber Tools wie gparted nach wie vor ZFS nicht anbieten. Das könnte man natürlich in der Kommandozeile lösen aber so lange mir Btrfs keinen Grund liefert, werde ich ZFS wohl nicht testen.

Weiterhin hat btrfs den Ruf nachträgliche Änderungen einfacher zu Unterstützen (z.B. Raidlevel), während bei ZFS ein Neuaufbau erforderlich ist. Bleibt noch die Aussage ZFS ist stabiler Aussage von einigen Leuten im Netz, die sich aber nicht objektiv untermauern lässt. Das hängt wohl auch immer von Versionen und Setup (z.B. Raid ja oder nein und wenn ja welcher Level) ab.

 

 

Ubuntu 20.04 LTS Focal Fossa Upradeerfahrungen [Kommentar]

Kommentar hinterlassen

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]

Kommentar hinterlassen

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.

Cokies DSGVO konform im Blog [Kommentar]

Kommentar hinterlassen

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 … 3 4 5 6 7 … 11