Kategorie: Blog

Das Thema DSGVO hat mich als Blogger recht unverhofft getroffen. Kaum hat man mit dem Blogen so richtig begonnen, schon schlägt man sich mit solchen Themen rum. Der Vorteil war allerdings, dass ich mich bei der Auswahl der Plugins von Anfang an mit dem Thema auseinandergesetzt habe.

Guides und Kommentare, die teilweise recht widersprüchlich sind bzw. das Gesetz alle anders auslegen, gibt es im Netz unterdessen genug. Genannt sei hier zum Beispiel folgender: 170+ WordPress-Plugins im DSGVO Check.

Daher liste ich im Folgenden auf was ich im Rahmen der Anpassung “fit für DSGVO” gemacht habe.

Nur der Vollständigkeit halber: Dieser Beitrag ist keine Rechtsberatung!

Antispam Bee

Alle Einstellungen in denen IPs verwendet werden (zum Beispiel öffentliche IP Datenbank) oder alle Funktionen bei denen privacy bzw. Datenschutzhinweise vorhanden sind habe ich deaktiviert. Im Kontext Antispam Bee wird Sicherheit gegen Datenschutz eingetauscht.

Akismet ist nach aktuellem Stand offenbar nicht zu empfehlen.

SSL

Habe ich schon seit Jahren auf meinen anderen Domains, somit war das für den Blog auch selbstverständlich. Vom Gesetz nicht gefordert, aber durchaus sinnvoll ist die Prüfung der Qualität der Absicherung. Keinem hilft eine auf veralteter Technik basierte Absicherung, die leicht angreifbar ist.

Hier kann ich folgenden Link zur Prüfung der eigenen Seite empfehlen. A oder A+ sollte das Ziel sein. Den Test sollte man regelmäßig ausführen, weil heute sichere Standards es morgen evtl. nicht mehr sind.

Für WordPress kann man zum Beispiel das Plugin Really Simple SSL nutzen.

Update 09.02.2020: Man bekommt SSL aber auch vollkommen ohne externe Plugins zum laufen. Mittlerweile verwende ich keinerlei Plugins mehr in dem Kontext

Jetpack

Auch im Kontext Jetpack tauscht man teilweise Sicherheit gegen Datenschutz.

Ich habe in Jetpack die Funktion zur Überwachung verdächtiger Anmeldeaktivitäten deaktiviert. Aktuell sieht es nicht so aus, als wenn Jetpack rechtzeitig das Update bereitstellt aber warten wir es ab.

Der aktuelle Status findet sich hier.

WP DSGVO

Das Addon WP DSGVO habe ich für die Kommentar folgen Funktion installiert, um dort eine explizite Zustimmung einzuholen (Double Opt In). Weiterhin bietet das Plugin die Möglichkeit die Löschung der persönlichen Daten anzufordern. Die Funktion kann man recht komfortabel in den Block einbinden.

Update 09.02.2020 siehe weiter unten. Ich habe WP DSGVO aus verschiedenen Gründen ersetzt. Das Addon logt extrem viel mit und ist aus meiner Sicht selbst aus DSGVO Sicht und aus Performanzsicht kritisch. Zusätzlich vertragen sich einige Funktionen nicht gut mit Caching Plugins.  Ersetzt habe ich WPDSGVO durch GDPR Data Request Form und WP Comment Policy Checkbox.

Remove IP

Die IP wird durch dieses Kleine Addon direkt beim Speichern von Kommentaren gelöscht

Redirection

Selbst in diesem Addon verbirgt sich eine IP Protokollierung, die ich nun deaktiviert habe.

Shariff Wrapper

Die Sharing Funktion von einem anderen Plugin habe ich durch Shariff ersetzt. Dann werden erst nach dem Klick auf den entsprechenden Button Daten an Facebook und andere weitergegeben.

Update 09.02.2020

Complianz

Das Plugin ermöglicht das Blocken von Cookies und externem Code, bevor der Anwender der Verwendung zustimmt.

Siehe auch hier.

Disable Emojis (GDPR friendly)

Das Addin vermeidet das Nachladen von Emojis von Drittanbieterseiten. Moderne Browser können diese in der Regel trotzdem darstellen.

GDPR Data Request Form

Anfrageformular um personenbezogene Daten anzufordern oder zu löschen.

Self-Hosted Google Fonts

Lädt ggf. benötigte Google Fonts auf den eigenen Server. Ein Nachladen bei Google ist nicht mehr erforderlich.

WP Comment Policy Checkbox

Bevor ein Kommentar abgegeben werden kann, muss der Datenschutzerklärung zugestimmt werden.

Datenschutzerklärung

Die Datenschutzerklärung muss auch aktualisiert werden. Ich habe den Generator von der Kanzlei Dr. Schwenke genutzt, da der bei Recht24 passenderweise aktuell nicht verfügbar ist und dort auf die Prämiumdienste verwiesen wird. Ansonsten habe ich mir beim Erstellen gedacht lieber ein paar Optionen zu viel aktivieren als zu wenig. Besser ich erwähne einen Dienst, der auf dem Blog (noch) nicht verwendet wird, als andersrum.

Generell sollte man wohl die DSGVO so gestalten, dass sie nicht von Robots durchsucht werden kann (robots.txt) oder WP Hide Post, damit nicht irgendwelche wütenden Abmahnanwälte automatisiert evtl. Fehler aufspüren können.

Gostery Plugin für Chrome

Damit könnt ihr sehen welche Tracking Aktivitäten auf eurem Blog so laufen. Bei mir sind das Gravatar und WordPress.com (Jetpack) – beides nicht überraschend.

Und sonst so

Das Plugin Email Subscribers & Newsletters benötigt auch einen Button, in dem der Benutzer bestätigt, dass er die Datenschutzbvereinbarung zur Kenntnis nimmt. Dafür wird dann gleich mal ein zweite Plugin benötigt was sich GDPR schimpft. Wenn man bei dem Plugin die Datenschutzvereinbarung verlinkt, dann verlangt es beim Login auf der Seite vom Benuzer direkt, dass die “Änderung der Datenschutzvereinbarung” bestätigt wird. Das hat zwar den Vorteil, dass man damit quasi alles folgende abgesegnet hat. Aber mir stellt sich schon die Frage wie die Benutzer identifiziert werden, die die Datenschutzvereinbarung abgesegnet haben. Bleibt die IP und Cookies, was doch eigentlich böse ist. 😉 Auf jeden Fall war mir so ein Überfall auf die Webseitenbesucher dann doch zu radikal.

Gravatar und das CDN (Content delivery network – verteilte Auslieferung von Bildern zwecks Entlastung des eigenen Servers) von Jetpack habe ich bisher nicht deaktiviert. Lt. den Angaben von Jetpack werden keine IPs mitgelogt bzw. die Daten werden anonymisiert übertragen. Auf Gravatar wird in der Datenschutzvereinbarung explizit eingegangen und auch auf Like Buttons.

Cookies werden auf dem Blog nur erhoben, um den Loginprozess zu beschleunigen, wenn man es denn möchte. Es gibt keine Statistikauswertungen oder ähnliches für die Cookies als Basis genutzt werden. Allerdings speichern die Plugins wie z.B. von Lovelybooks (die wollen die Cookies in kürze ausbauen) und Blogslovin leider Cookies.

Update 09.02.2020 – Siehe separater Blogbeitrag zum Thema Cookies.

In Chrome könnt ihr unter Weitere Tools\Entwicklertools\Application sehen welche Cookies von der jeweiligen Seite gespeichert werden.

Emojis habe ich über Autoptimize verbannt, aber die funktionieren trotzdem noch, sehen aber seitdem anders aus. Offenbar kommen sie aber nun nicht mehr aus kritischer, weil datensammelnder Stelle. Weiterhin habe ich in dem Plugin die Google Fonts deaktiviert.

Update 09.02.2020 – Autoptimize verwende ich nicht mehr. Stattdessen benutze Ich WP Speed of Light, das aber auch eine Funktion zum Deaktivieren von Emojis hat.

Ich werde jetzt mal entspannt auf den 25.05 warten und ggf. noch Plugins aktualisieren, wenn vorher noch was kommt.

Und Ihr?

Habt ihr auch einen Blog und was habt ihr so alles angestellt oder hofft ihr einfach, dass schon nichts passieren wird oder wart ihr viel radikaler als ich und habt noch mehr Komfortfunktionen entfernt? Findet ihr auch das die DSGVO vom Grundansatz zwar gut für den Datenschutz ist aber gerade für Blogger weit über das Ziel hinausschießt?

Nachdem ich in den letzten Monaten einige Erfahrungen mit WordPress gesammelt habe, dachte ich mir es ist vielleicht für den einen oder anderen interessant, wenn ich darüber blogge.

Lessons learned

Es gibt so einige lesson learned aus den letzten Monaten:

1. Weniger Plugins sind mehr (ja, das liest man überall aber es ist so verdammt schwer sich daran zu halten, weil man bei einem anderen Blogger ein tolles Feature sieht, dass man auch gerne hätte und das ist Fluch und Segen bei den WordPress Plugins – man findet fast alles aber oft sind die Plugins so fokussiert auf einen Bereich, dass man ein ganzen Sammelsurium auf dem Blog hat. Und ruck zuck hat man mehr Plugins als man je haben wollte.
2. Ein Linux Server als Basis ist deutlich flotter als eine Windows Plattform mit Plesk (und das liegt nicht an Plesk, sondern an Windows). Das habe ich mit mehreren VPS-Servern bei verschiedenen Anbietern getestet.
3. Optimierungsaddons sollte man sehr vorsichtig einsetzen. Je nach Einstellung (vor allem Java Script zusammenfassen oder optimieren) ist gefährlich. Generell gilt, man sollte nach jeder Einstellung prüfen, ob die Geschwindigkeit sinkt oder steigt und auch ob noch alles funktioniert.
4. Bei WordPress gilt nicht WYSIWYG (what you see is what you get). Das gilt ganz besonders bei Bildern oder Galerien. Gerade wenn man mit individuellen Bildgrößen arbeitet. Ich habe es z.B. schon oft erlebt, dass ein Bild in der Entwurfsansicht in einer anderen Größe angezeigt wird als im veröffentlichten Post. Die Folgen per Mail Funktion verhält sich wiederum noch mal anders. Gleiches gilt auch für Plugins wie Zitate darstellen oder Bewertungen optisch darstellen. Es ist bei all diesen Addons nicht sichergestellt, dass in einer Follower Mail das gleiche erscheint, wie in der Post- oder Vorschauansicht. Daraus folgt, dass es ehr hilft, wenn man eine zweite Domain mit einem identischen WordPress hat, auf dem man testen kann, ohne seine Follower zuzuspammen mit hässlichen Mails, die vorher im Entwurf und als Vorschau noch ganz toll aussahen.
5. Kümmer dich um die Suchmaschinen! Das heißt die Seite sollte schnell genug sein (siehe Google Page Speed Insights), weil man sonst im Ranging weiter unten landet. Ihr solltet über Robots.txt oder Plugins dafür sorgen, dass Inhalte nicht sichtbar sind, die nicht sichtbar sein sollen (Impressum, Eigene Adresse, Datenschutzvereinbarung). Gerade im Kontext DSGVO wird es vermutlich wieder Anwälte geben, die mit Abmahnungen ihr Geld verdienen und aufgrund begrenzten Ressourcen eines Privatbloggers werden wir uns wohl als Zielscheibe anbieten speziell bei der Datenschutzvereinbarung. Weiterhin gibt es Plugins, die die Seite auf Suchmaschinenverträglichkeit prüfen und einen unterstützen z.B. Suchbegriffe zu Beiträgen zu erstellen
6. Vorsicht vor Addons wie Wordfence oder vergleichbar, die senken die Geschwindigkeit teilweise erheblich und sind meiner Meinung nach auch unnötig. Eine ganz normale Firewall, die eh jeder Server haben sollte reicht aus.
7. Überlegt euch bevor ihr mit einem Blog anfangt wie eure Permalinks aussehen sollen! Die Standardeinstellungen (mit dem ? in der URL) ist nicht statisch und somit nicht geeignet für Content Delivery Networks und auch nicht für Cache Addons. D.h. entweder stellt man auf den Postnamen um oder auf eine Nummer. Was besser ist, darüber streiten sich die Geister (Stichwort Suchmaschinenoptimierung ). Ich tendiere aktuell zum Postnamen als URL, habe aber selber mit Nummern gearbeitet. Eine gute Suchmaschine sollte mit beidem zurechtkommen.
8. Prüft mehrere Themes mit euren Beiträgen. Wenn ihr später das Theme wechseln möchtet, solltet ihr das beim Erstellen von Beiträgen im Hinterkopf haben. Was in einem Theme gut aussieht oder passt, muss im nächsten nicht funktionieren. Alle Blogbeiträge später umbauen macht keinen Spaß!
9. Keine Umlaute in Bildern verwenden. Wenn euer Blog mal umzieht, macht das nur Ärger. Bei mir war es zum Beispiel der Fall, als ich von einem Windows Server auf Linux umgezogen bin.
10. Desto mehr externe Funktionen ihr verwendet, desto mehr seid ihr abhängig von externer Funktionalität (genannt sei hier zum Beispiel Gravatar – das ist eh nicht DSGVO Konform – aber schick und aus meiner Sicht auch sinnvoll, weil man so einen Blogger optisch viel leichter wiedererkennt), Lovelybooks, Jetpack, Blogslovin usw. – auch hier ist weniger mehr, auch wenn es schwerfällt (ja, ich weiß – an den Tipp halte ich mich selber nicht)

Empfehlenswerte Plugins

Man findet in Blogs recht selten Infos welche Pluggins benutzt werden oder welches Theme. Warum das so ist weiß ich nicht. Natürlich hat man Zeit investiert und möchte vielleicht auch nicht, dass jeder Blog so aussieht wie der eigene. Aber andersrum macht das dein Einstieg für Neulinge auch nicht leichter.

Ich führe im Folgenden einige Plugins auf, mit denen ich gute Erfahrungen gemacht habe:

• Autoptimize (einige Optimierungen wie CSS, HTML zusammenfassen und Google Fonts, sowie extern geladene Emojies + Caching) wird durch andere Plugins besser erledigt
• Antispam Bee – der Name sagt alles und es ist eher DSGVO Konform als Akismet
• Email Subscibers & Newsletters (Newsletter, der direkt über die eigene WordPressinstallation bereitgestellt wird, ohne Einbindung in irgendwelche Netzwerke
• Google Captcha (reCAPTCHA) – verhindern von Anmeldungen von Bots
• Really Simple SSL – SSL für WordPress – nicht erforderlich, wenn die Seite durchgängig korrekt konfiguriert ist
• WP Mail SMTP – SMTP Mailversand. Im Prinzip kann WordPress das zwar auch alleine Mails verschicken aber die kommen in der Regel nicht an, weil viele Provider sie gleich als Spam ausfiltern
• Yoast SEO (Suchmaschinenoptimierung)
• Shariff Wrapper (Social Sharing Links DSGVO konform)
• Scripts to Footer (Java Scipts erst am Schluss laden), damit der initiale Seitenaufbau nicht verzögert wird
• Speed of light – Achtung, die Standardversion reicht vollkommen, man muss kein Geld ausgeben und vorsichtig sein bei den Einstellung speziell was Javascript angeht, lediglich das Precaching ist eine sinnvolle Option der Bezahlversion und das zumindest aktuell kostenlose Kontingent für ImageRecycle (weniger ist mehr)
• WP DSGVO (einige DSGVO Funktionen wie Löschanfragen und Opt z.B. für Kommentare aber in dem Bereich wird sich in den nächsten Tagen / Wochen eh noch einige tun – der Nachteil, bei diesem Plugin ist, dass sehr viel auf der Datenbank mitgeschrieben wird, was last erzeugt und Platz belegt
• Social Media Follow Buttons Bar (folge Buttons)
• Jetpack (hier gehen aktuell die Meinungen gerade stark auseinander in wieweit das mit welchen Einstellungen DSGVO Konform ist, wenn man nur Ansatzweise an die Komforfunktionen eines WordPress.com Blogs herankommen möchte (z.B. logon von WordPress.com usern, wordpress Follow funktion), kommt man um dieses Plugin aber nicht herum
• Remove IP (IP in Kommentaren vor dem Speichern entfernen – Pflicht für DSGVO)
• Blogslovin Button – wie ich finde sehr coole Variante um Blogs zu folgen und auf andere Blogs aufmerksam zu werden. Allerdings bekommt sind dort auch irgendwelche Bots als Follower unterwegs
• Block Blogslovin iframe – Verhindert, dass der Blog nur im iframe aufgerufen wird.
• Collapsing Categories / Collapsing Archives – schickere und übersichtlichere Darstellung von Archiv und Kategorien
• Universal Star Rating – Optische Symbole für Bewertungen mit 0,5er Abstufungen (Achtung, in Follower Mail erscheinen die Sterne nicht)
• Simple Pull Quote – Zitate optisch hervorheben (funktioniert auch in follower Mails)
• Redirection – Wenn man seine Permalinks ändert, dann gehen externe Links in leere. Um das zu vermeiden muss man jeden alten Link umleiten. Das ist besonders interessant, wenn man die URL Erstellung in WordPress umstellt, die alten Beiträge aber trotzdem sichtbar bleiben sollen, obwohl die Links nun andere sind.
• List URLs – siehe vorherige Punkt – Ermittlung aller Links, die umgestellt werden müssen (braucht man nicht dauerhaft aktivieren)
• Quotes Collection – Widget mit zufälligen Posts anzeigen
• Mechanic Vistor Counter – Besucher anzeigen – veraltet
• Addendio Plus – Plugins Suchen und Preview anzeigen (veraltet)
• BB Spoiler – Aufklappbare Spoiler in Beiträge einbauen
• WP Hide post – Posts oder Seiten verstecken vor Suchmachinen – geht auch über robots.txt und ist die bessere Variante
• SSL Insecure Content Fixer – Bei Problemen mit mixed Content oder Proxy Servern hilfreich – bei korrekter Konfiguration nicht erforderlich
• Async Java Script – Kann die Performance und die Bewertung bei Google Pagespeed dramatisch erhöhen, man muss aber sehr sorgfältig testen, ob danach noch alle Funktionen vorhanden sind. Die schnellste Einstellung ist Async.
• Brocken Link Checker – Prüfung auf nicht mehr funktionierende Links, die nachteilig für das eigene Suchmaschinenranking sind
• GTranslate – Automatische Übersetzung des Blogs (Achtung, das Plugin kostet einiges an Performance). Lustig ist, dass Google in Pagespeed das Plugin abstraft, es aber auf Google Technik basiert.
• Imagerecycle oder Smush – Bilder / Fotos komprimieren und optional beim Abload die Auslösung limitieren
• Nested Comments unbound – Mehr als 5 Kommentarebenen
• WP OPCache – PHP Code Puffern – Achtung das Plugin benötigt memcached auf dem Server (das ist etwas anderes als die Seite selbst zu puffern, wie  es in Speed of Light erfolgt)
• WP Statistics – Sehr mächtiges Statistikwerkezeug für WordPress einschließlich Besucherzähler
• Classic Editor – Ihr mögt den Gutenberg Editor nicht? Dann könnt ihr weiterhin den klassischen Editor benutzen
• Complianz – Cookie Consent – Cookie Richtlinie und Zustimmung
• Disable Emojis (GDPR friendly) – Emojis werden nur noch über den Browser dargestellt und nicht über externe Icons
• Self-Hosted Google Fonts – Die Google Fonts werden auf dem eigenen Server gehostet und nicht von Google nachgeladen
• GDPR Data Request Form – Anforderung oder Löschen der personenbezogenen Daten beantragen
• WP Comment Policy Checkbox – Zustimmung zur Datenschutzrichtlinie, bevor man einen Kommentar abgeben darf

Und einige Helferlein, die eher dem Monitoring oder der Administration dienen:

• WordPress phpinfo() – Anzeigen der aktuell genutzten PHP Version
• Hostinfo – Infos zum Blog und zum Server
• String Locator – Nach Strings suchen – beispielsweise, wenn man Fehlermeldungen bekommt und anschließend nach dem Coding in den Plugins suchen möchte.
• Regenerate Thumbnails – Die Thumnails werden automatisch in den von euch eingestellten größen für kleine / mittlere / große Bilder erzeugt. Wenn ihr diese Einstellung nachträglich ändert, werden die vorhandenen Thumbnails nicht neu erzeugt. Das Plugin ermöglicht er die Vorschaubilder neu zu generieren. Falls ihr das nicht macht, muss das beim Seitenaufruf live erfolgen, was die Seite langsamer macht.
• PHP / MySQL Performance Statistics – Ihr wollt wissen, ob PHP oder MySQL auf äurem Server lahm oder schnell ist? Das Plugin führt einen Test durch
• Gwolle Guestbook – Gästebuch
• Query Monitor – Hauptsächlich im Problemfall interessant. Welche Abfragen werden an die Datenbank gesendet
• WPSweep – Bereinigt die Datenbank z.B. von alten Postversionen (im Standard werden alle Versionen vorgehalten), nicht mehr genutzten Plugineinstellungen usw.

Testwerkzeuge

für Geschwindigkeitsoptimierung:

• Google Page Speed Insights
• Pingdom Website Speed Test
• Lighthouse Plugin für Chrome
• Webpagetest

für SSL:

• Qualys SSL Labs

Übergreifende Tests:

• MX-Toolbox

Welche Plugins nutzt ihr so? Welche Erfahrungen habt ihr gemacht? Wie und wo hostet ihr euren Blog und welche Vorteile oder Probleme bringt das mit sich?

Update 08.12.2019

Ich habe ein paar Ergänzungen bei den Plugins vorgenommen und einige Plugins entfernt, die ich nicht mehr Nutze bzw. nicht mehr empfehle.

Uodate 09.02.2020

Weitere Updates.

Lahmender Blog

Wie ihr vielleicht gemerkt hat, hat sich am Lesestatus bei mir nichts geändert seit grob einer Woche. Ich hatte ja in der Montagsfrage bereits angedeutet, dass ich mir aus Performanzgründen gerade neue Hostingvarianten für den Blog teste. Der Blog liegt – neben weiteren Webseiten von mir (primär privater Kram wie Urlaubsbilder / Backup / Spielerei) – auf einem VPS (Virtual Private Server). Das ist ein virtueller Server. Der Unterschied zu einem dedizierten Server ist, dass auf der Hardware mehrere virtuelle Server laufen, die sich aber gegenüber dem Anwender so darstellen, als wenn sie komplett separiert wären. Das ist für den Hostinganbieter flexibler und kostengünstiger. Ein VPS kann man quasi genauso frei benutzen wie seinen Rechner zu Hause. D.h. man kann auf dem Rechner sehr viel frei einstellen.

Der Vorteil gegenüber einem reinen Bloghosting ist, dass man damit sehr viel mehr machen kann. Man kann beliebige Inhalte installieren, von Webmailern, Mailservern, Cloud Speichern, Backuplösungen, Teamspeak Servern usw. ist so ziemlich alles möglich.

Der Nachteil ist, dass man das auch immer einrichten muss. Obwohl ich Informatiker bin (beruflich beschäftige ich mich aber nicht mit Webhosting, PHP, HTML, Linux und co), ist es immer eine Abwägungssache wie viel Flexibilität man möchte und welche Zeit bzw. welchen Aufwand man dafür investieren will. Ist einem der zusätzliche Arbeitsaufwand den zusätzlichen Nutzen wert. Bisher habe ich immer einen Windows Server mit Plesk als Basis genutzt. Das ist relativ intuitiv und die meisten arbeiten mit Windows ja auch zu Hause, insofern geht damit auch auf einem Server die Arbeit recht gut von der Hand. Der Nachteil sowohl von Plesk als auch von  Windows ist, dass beide Herstellerunternehmen Lizenzgebühren kassieren. Das treibt die Kosten eines VPS mit guter Leistung sehr schnell in die Höhe. Speziell bei besserer Hardware werden die Lizenzkosten für die Software sehr hoch.

Da mein Server, obwohl er eigentlich ansonsten noch recht schnell war, besonders in Bezug auf den Blog doch recht arg gelahmt hat, habe ich mir angeschaut welche Alternativen ich habe.

Neues zu Hause auf Windows Basis

Der alte Server (Hosteurope) hatte 2 Kerne, 4GB RAM, Windows Server 2008 + Plesk als Ausgangsbasis.

Zwecks Vergleiches habe ich zwei neue Varianten getestet:

• Windows Server 2016 (Strato) – 4 Kerne, 4GB RAM – mit 500GB SSD/HDD Kombination und Plesk 20€ pro Monat (fehlende Komfortfunktionen, da bessere Hardware und somit aus Kostengründen schlechtere Plesk Lizenz)
• Windows Server 2012 (Hosteurope) – 2 Kerne, 4GB RAM – mit 150GB SSD und Plesk für 15€ pro Monat (maximale Komfortfunktionen)

Testen heißt in dem Fall, dass man alle Inhalte vom alten Server auf den neuen verschieben muss. Das ist also nicht mal so eben gemacht, mit Plesk geht das aber recht einfach, weil es dafür Assistenten anbietet. Grob kann man sagen, dass man pro Server einen Tag dafür braucht je nachdem was man noch zusätzlich einstellen muss (einiges muss nach dem Umzug manuell nachgearbeitet werden, weil Plesk es entweder nicht oder mit falschen Einstellungen umzieht).

Im Ergebnis waren beide Server etwas schneller als der alte aber wirklich viel auch nicht. Je nach Tagesform mal mehr mal weniger. Die Geschwindigkeit hängt durch die diversen Addons bei Plesk eben nicht nur von dem eigenen Server ab, sondern auch von den diversen anderen auf die man mit den Addons Daten abholt (z.B. Lovelybooks, WordPress.com usw).

Da ich von dem Ergebnis nicht so richtig begeistert war habe ich mir gedacht, wenn du eh mal dabei bist, kannst du auch mal ins kalte Wasser springen. Die Idee: Versuch doch einfach mal ein VPS mit einem Linux Betriebssystem und ohne Plesk aufzusetzen. Das ist quasi der Sprung von maximalem Komfort beim Hosting zu 0,0 Komfort und dafür aber auch 0,0 Lizenzgebühren. Aus genau dem Grund bin ich bisher auch immer vor einem Linux Server zurückgeschreckt und wie sich gezeigt hat, nicht ohne Grund, doch dazu weiter unten mehr. 😉

Erste Gehversuche mit Linux

Zum Vergleich die Daten des Linux Servers:

• 4 Kerne mit Linux (Contabo), 13GB RAM, 1TB SSD/HDD Kombination für 12€ pro Monat  (Webmin und Lamp)

Man sieht recht deutlich – es liegen Welten zwischen der Preisleistung.

Mein erster Ansatz war nur den Server für Backups zu benutzen. Man denkt als Privatmensch nicht so darüber nach aber man hat heute recht viele Daten Urlaubsbilder, Videos, Kennwörter was auch immer, für die man maximal (wenn überhaupt) ein lokales Backup hat. Bei einem Brand oder Diebstahl ist man seine Daten im Zweifelsfall los und sie sind teilweise für immer verloren. Daher habe ich schon eine weile HiDrive von Strato im Einsatz um meine Daten dort abzulegen. Leider ist die Lösung aber nicht besonders schnell und flexibel was die Backupoptionen angeht (ohne Zusatzprotokollpaket geht es nur mit der HiDrive Software) oder ansonsten wieder teuer (mit Zusatzpaket).

Bedenken sollte man in dem Kontext auch wo man seine Daten ablegt. Für mich kommt es nicht in Frage meine Daten im Ausland zu parken. Dafür hat man über Edward Snowden einfach zu viel über die Machenschaften von NSA und amerikanischen Unternehmen bzw. deren Freunden (wie auch z.B. Großbritannien) erfahren. Wer garantiert mir denn, dass die Regierungen in den Ländern nicht mal wechseln und die Daten plötzlich zur Waffe werden?

Aller Anfang ist schwer, besonders mit Linux

Zuerst steht man dann auch als Informatiker ein weniger wie der “Ochs vorm Berg”. Das fängt schon damit an, dass man bestimmte Sachen lieber lassen sollte. Beispielsweise das PW von dem Root Nutzer ändern (vergleichbar mit dem Administrator Account bei Windows. Zwei Neuinstallationen später und einen Tag ärmer waren also schon mal die grundsätzlichen don’ts angekommen.

Danach habe ich dann schmerzlich gelernt, dass scheinbar simple Anforderungen (Remote Desktop Zugriff) bei Linux je nah Variante diverse Zusatztools benötigen, die aber teilweise nicht mit jeder Linux Version funktionieren. Auch das hat gut einen Tag gekostet – bei Windows wäre dafür überhaupt nichts erforderlich gewesen.

Natürlich habe ich schon mit Linux gearbeitet (hauptsächlich im Studium) aber einen Server aufsetzen, der zig verschiedene Bestandteile hat (Mailserver, WebDAV, Samba, RSYNC Backup Client, Teamspeak, FTP, SFTP, SSH Server, Remote Desktopzugriff, Wine, …) ist halt keine Sache die man so mal eben macht. Speziell dann nicht, wenn man weder flüssig “Linux spricht”, noch Webmin kennt und Apache bisher primär nur über Plesk bedient hat.

Dazu kommt, dass ich zu Linux immer schon eine Hassliebe gepflegt habe. Ich bin immer wieder erstaunt wie einfach manche Sachen mit ein paar Befehlen auf der Kommandozeile gehen. Als Windows Benutzer klappt einem da manchmal vor blankem Neid die Kinnlade runter. Andersrum sind aber oft simple Sachen auch dermaßen kompliziert gelöst, dass man Stunden benötigt um rauszubekommen wo es mal wieder klemmt.

Sie ist es mir in der letzten Woche gegangen. Erste Erfolge hatte ich relativ schnell aber im Detail hatte ich so viele Probleme, die immer Stunden gedauert haben, bis ich sie im Griff hatte. Das liegt natürlich an mangelnder Erfahrung mit der Umgebung aber oft sind die Fehlermeldungen, die man geliefert bekommt auch absolut nichtssagend oder es fehlen Einstellungen, die eigentlich schon im Auslieferungszustand gesetzt sein könnten (oft hat man das Gefühl, dass die Entwickler einen Einfach ärgern wollen).

“Wenn du mein Werkzeug benutzen willst, dann lies gefälligst ALLE Guides. Sonst könnte ja jeder kommen! Und die Konfiguration habe ich im Standard so verdreht eingestellt, dass überhaupt nichts funktioniert! So, und nun viel Spaß damit”

Dazu kommt dann halt, dass man genaue Beschreibungen zu irgendwelchen Fehlern erst nach der Suche in irgendwelchen Logs findet, sie aber nicht einheitlich zentral abgelegt sind, sondern mal hier mal da. Teilweise benötigt man auch Befehle auf Kommandozeile um das Problem zu analysieren. I.d.R. sind die automatisch sichtbaren Fehlermeldungen vollkommen unbrauchbar. Der vorteil ist aber das man sehr viele Informationen im Netz findet aber leider auch viele falsche.

Erste Fortschritte

Ohne zu sehr ins Detail zu gehen nur ein paar Beispiele für die diversen Probleme: Der Mailserver besteht bei Linux (zumindest in diesem Beispiel) nicht auf einer Komponente, sondern aus zwei. Allein das muss man erst mal verinnerlichen. Einem Auslieferungsteil (POP3 / IMAP Mailserver – in diesem Fall Dovecot) und einem Zustellteil, der die Mails verschickt (in diesem Fall Postfix).  Letzteren benötigt man in WordPress, um Mails verschicken zu können.

Jetzt könnte man mal als erste Fragen wieso die Komponenten nicht beide vorinstalliert sind bei einem VPS-Server. Dem ist nicht so. Wenn man sie dann installiert hat, dann drängen sich nach diversen Tests und Recherche im Internet einige Erkenntnisse auf. In der Grundeinstellung funktioniert so ziemlich nichts (kein SSL – klar das kann nicht voreingestellt sein, keine Benutzeranmeldung über SMTP, die beiden kommunizieren nicht miteinander usw.)

Allein das Thema der Einstellungen der beiden Mailserver hat mich locker einen Tag gekostet, eher mehr bis es komplett so lief wie ich mir das vorgestellt habe. Es gibt halt für jedes Tools zig Einstellmöglichkeiten und man muss auch erst mal drauf kommen, dass ein SMTP Server im Standard keine Benutzeranmeldung unterstützt.

So ging es dann quasi bei jeder Komponente auf dem Server. Das einzige was auf Anhieb lief war SSH und SFTP (da war ich schon erschrocken und dachte “Das kann doch überhaupt nicht sein, du hast doch noch nichts eingestellt und das geht einfach so?!”). Ein paar Beispiele die mich auch längere Zeit gekostet haben (der FTP Server im Standard so konfiguriert, dass er überhaupt nicht gestartet ist – falsche Konfiguration, der Apache war so falsch einstellt, dass er überhaupt keine Indexdatei also index.php und index.html geöffnet hat). Auch das falsche SSL Zertifikat hat er zuerst ausgeliefert (ich habe aktuell zwei Homepages auf dem Linux Server).

Neues (vorübergehendes oder dauerhaftes?) zu Hause für den Buchblog

Mit dem Apachen stand ich also längere Zeit auf Kriegsfuß und so richtig gute Freunde sind wir nach wie vor nicht. Moment? Zwei Homepages? Das war doch überhaupt nicht geplant?! Richtig aber nachdem ich das ganze Backupthema soweit am Laufen hatte dachte ich mir probier doch einfach mal aus wie sich der Buchblog auf dem Linux Server so macht.

Gestern Abend habe ich dann den ersten Versuch der Umstellung gewagt und bin an zwei Themen gescheitert (falsche Permalinks von WordPress und falsches SSL Zertifikat. Da lief die Seite also 2 Stunden nicht rund und irgendwann kurz nach 2 nachts habe ich dann zwar ein Problem gelöst aber das zweite nicht. Da habe ich dann erst mal aufgegeben und heute Morgen weiter gemacht.

Auch der Umzug des Blogs war im Detail also schwieriger als gedacht aber einige Tage später läuft nun scheinbar alles. Bis auf ein paar Kleinigkeiten bin ich mit dem Server nun zufrieden. Aber auf einem Linux Server hat man aufgrund der Unmenge an Möglichkeiten immer was zu tun.

Vorerst werde ich den Windows Server noch als Backup bzw. Ersatzlösung behalten. Das neue zu Hause befindet sich also quasi im Betastadium. 🙂

Ich weiß auch nicht so genau wie sich die Performanz des Blogs verhält, wenn ich größere Backups auf der Linux Maschiene mache aber eigentlich sollten genügend Reserven vorhanden sein.

Und was bringt’s so?

Der Blog ist nun deutlich schneller. als vorher. Das ist sowohl beim Seitenaufbau als auch bei der Bedienung von WordPress beim schreiben von Blogs oder beim Konfigurieren und Installieren von Plugins spürbar. Weiterhin ist der Server auch noch günstiger als die vorherige Variante.

Die Bedienung ist aber viel komplexer als vorher. Manche Sachen, die vorher ein Klick waren sind jetzt mit stundenlangem Suchen und Probieren verbunden. Das Optimum stellt also wohl ein Linux Server mit Plesk dar. Beim nächsten Mal dann. 😉

Fazit:

Ist bin jetzt einige gefühlte graue Haare reicher, total übernächtigt und habe eine Woche Lebenszeit verbrannt. Dafür habe ich jetzt aber einen Backupserver mit diversen Funktionen, der sich mit viel teureren Alternativen messen kann + ein neues ziemlich performantes zu Hause für den Blog und ich habe eine Menge gelernt. Bei Linux ist es oft die eine Zeile, der eine Befehl die den Unterschied ausmachen. Dummerweise weiß man das immer erst, nachdem man x Stunden auf die Suche danach verschwendet hat. Wobei das im Leben natürlich oft so ist, nachher ist man immer schlauer. 😉

Morgen hoffe ich dann mal wieder zum Lesen zu kommen, wenn sich nicht wieder neue Themen abzeichnen. Wie war das so schon? Mal eben einen Server aufsetzen. Mal eben ist eben nie mal eben.

Motivation

Nachdem ich die Lux Serie gelesen hatte – die Hauptakteurin ist begeisterte Buchbloggerin – habe ich mich ein wenig im Netz umgeschaut was andere über die Buchserie denken und bin bei ein paar interessanten Buchblogs gelandet. Da habe ich mir gedacht, dass ich das auch mal versuchen könnte. Bei einer Rezension auf einem klassischen Bewertungsportal geht man je eh immer in der Masse unter und ist in der Regel auch sehr eingeschränkt bzgl. der Möglichkeiten der Darstellung und Form.

Ich bin noch ein sehr junger Buchblogger (zumindest was das alter des Blogs angeht – allerdings hatte ich schon einen anderen Blog in sofern wusste ich in etwa was auf mich zukommt) aber trotzdem merkt man recht schnell welcher Arbeitsaufwand dahinter steht.

Nicht das es hier falsch rüber kommt: Ich habe gerade erst mit dem Buchbloggen angefangen und schon beschwere ich mich über den Aufwand?! Nein. Ich habe nur gerade einen sehr coolen Post zu dem Thema gefunden und dachte mir ich beschreibe dazu einfach ein Paar Eindrücke von meiner Seite.

Kosten <> Nutzen

Finanziell macht das natürlich keinen Sinn bei dem Verhältnis investierte Zeit vs. Kosten für ein Buch. Zumal ja eh nur die fleißigen vielgelesenen Blogger überhaupt für die Verlage interessant sind. Allerdings hat es ja auch Vorteil, wenn man sich die Bücher einfach selber kauft. Man ist total frei was man liest und wann man es liest und fühlt sich auch garantiert nicht verpflichtet.

Natürlich kann man theoretisch auch Werbung in den Blog einbinden aber irgendwie weckt das immer auch das Gefühl, dass man nicht unabhängig ist und außerdem lohnt sich das eh erst, wenn man sehr viele Leser hat.

Technik

Im Prinzip fängt es ja noch weiter vorne an als mit der Zeit für die Erstellung eines Blogeintrages. Die Technik eines Buchblogs fällt ja auch nicht vom Himmel. Das fängt ja schon mit der grundsätzlichen Frage an wo man die Seite betreibt (Eigener Server, Google, eigener Webspace). Wie will man die Seite betreiben (Manuell, Content Mangagement System, Datenbank und automatisch generierte Seite – das muss man i.d.R. selber programmieren).

Da ich einfach neugierig auf einen Buchblog war, habe ich mir überlegt welche Variante für mich in Frage kommt. Die manuelle Variante ist zwar maximal flexibel ist aber eben auch maximaler Aufwand, somit war mir direkt klar, dass diese Variante ausscheidet.

Die Variante mit der automatischen Generierung mit Datenbank ist die Lösung, die später am wenigsten Arbeit macht aber man steckt erst mal x Wochen rein bis man die technische Basis hat (und mal eben ein Addin erweitern wie bei einem CMS kann man auch vergessen). Mir ist zwar klar, dass ich das als Informatiker eigentlich genau so machen sollte aber bei der Variante hatte ich Angst, dass ich die Lust verliere, bevor ich überhaupt Inhalte veröffentlichen kann.

Somit habe ich mich dann für die CMS Variante entschieden. Tja, und dann muss man sich auch überlegen welches. Da ich schon mit WordPress gearbeitet habe (ok, ist vom Ursprung eigentlich kein CMS sondern ein Blog), bin ich dann dort gelandet.

Nach dem ganzen Technikkram hat man zwar die Basis aber auch nur ein leeres Gerüst. Ehrlich gesagt war ich recht erstaunt wie schnell ich die Technik fertig hatte. Da hatte ich mit mehr Aufwand gerechnet. Allerdings habe ich eh einen eigenen Server und mich in der Vergangenheit schon mit ähnlichen Themen beschäftigt.

Dann kommen natürlich Designentscheidungen auf einen zu und wenn man dann mit dem Design zufrieden ist (zumindest vorübergehend, zufrieden ist man ja nie) benötigt man noch diverse Zusatzfunktionen damit der Blog auch nur halbwegs komfortabel für Besucher ist.

Inhalte

Nun fehlt noch immer das wichtigste und das sind die Inhalte. In dem Kontext muss man sich zuerst mit drumherum wir Rechtslage und Impressum beschäftigen, bevor man ein Review schreibt. Ganz nebenbei begibt man sich noch in rechtliche Grauzonen (Cover verwenden benötigt eigentlich die Erlaubnis des Verlages und die Cover von Amazon sind offiziell tabu ohne Verlinkung mit Partnerprogramm, Bilder und Fonts mögen zwar im Web als frei tituliert sein, aber das bedeutet noch lange nicht, dass sie es sind und Zitate müssen auch diversen Anforderungen genügen).

Weiterhin kommt noch der Zeitaufwand auf einen zu, der in diesem Post schon ausführlich beschrieben wurde. Den Zeitaufwand für die Inhalte hatte ich wirklich unterschätzt.

Aber der Riesenvorteil ist ja, dass man das alles freiwillig macht und weil man es möchte. Ich habe mal ein interessantes Beispiel von Katastrophenhelfern gehört. Da ging es darum, auf Basis welcher Motivation jemand in einem anderen Land bei einer Katastrophe hilft. Man hat einerseits Geld dafür geboten (dafür konnte sich kaum einer motivieren) und anderer seits keinerlei Gegenleistung (dafür haben sich dann deutlich mehr Menschen gefunden). Die Freiwilligkeit macht in dem Kontext also offenbar einen wesentlichen Unterschied. Ist ja auch nachvollziehbar. Sobald man eine Gegenleistung bekommt wägt man ab, ob der eigene Einsatz das Wert ist (Verdienstausfall, Risiko für einen selbst, Konsequenzen vs. Nutzen).

Will sagen: Spaß an der Sache kann die einzige Motivation für einen Blog sein. Das es auch Leute gibt, die davon leben können ist wohl die absolute Ausnahme und Bochblogs sind das dann vermutlich eher nicht, 😉