Schlagwort: V-Server

Doppeltes Problem-Lottchen

Ich habe langsam wirklich die Faxen dicke. Sowohl mein V-Server (genaugenommen wohl WordPress beim Anlegen eines neuen Posts) als auch meine Workstation wollen einfach ihre allgemein Unzufriedenheit mit der Gesamtsituation nicht aufgeben. Ein Post aus WordPress hängt Apache auf und die Workstation zeigt immer wieder schwarze Bildschirme bzw. Programme wollen gar nicht oder nur nach Ewigkeiten starten. So geht es nicht mehr weiter. Im Moment habe ich noch Zeit, bevor nächste Woche wieder Aufnahmen für LinkedIn Learning (LiL) anstehen und dann ab Ende Februar beruflich komplett Land-unter ansteht. Ich muss die Sache jetzt angehen.

Bei dem V-Server habe ich jetzt mal alle Plugins in WordPress deaktiviert und schaue, ob da der Hund begraben ist. Ich habe da ein konkretes Plugin im Verdacht, aber zur Sicherheit schalte ich erst einmal alle Plugins ab und dann sehe ich weiter (EDIT- das scheint es zu sein – der Post hier hat ohne Plugins keine Probleme gemacht. Muss jetzt nur noch den Schweinehund identifizieren).

Meine Workstation setze ich komplett zurück. Oder versuche es zumindest. Ich habe keinen Bock mehr an einer Schraube zu drehen und damit das eine Problem zu lösen, um dafür an einer anderen Stelle ein neues Problem zu bekommen. Manchmal hilft wohl wirklich nur Gewalt.

AH03099: ap_queue_pop failed und schwarze Bildschirme

Ich kämpfe gerade mit gleich zwei Problemen, die rein gar nichts miteinander zu tun haben, aber beide lästig sind. „Lästig“ bedeutet, dass sie nicht komplett Sachen unmöglich machen, aber behindern und auf Dauer nicht bleiben sollten.

  1. Ich habe auf meiner Workstation die Grafikkarte getauscht, da ständig Streifen auf allen angeschlossenen Bildschirmen aufgetreten sind. Aber mit der neuen Grafikkarte gibt es immer wieder schwarze Bildschirme – auch nachdem die Workstation in der Werkstatt war und die Treiber  etc. jetzt alle passen sollten. Genauso wie es bei mir am Anfang war als ich die neue Grafikkarte bei mir das erste Mal eingebaut hatte. Manchmal wird ein Bildschirm schwarz, aber manchmal auch 2 oder alle 3, die an der der Grafikkarte angeschlossen sind. Die sind dann jeweils nach ein paar Sekunden aber wieder da. Nur der 4. Bildschirm, der an dem Onboard-Ausgang des Motherboards angeschlossen ist, ist davon nie betroffen.
    Soweit ich es mittlerweile nachvollziehen kann, passiert das, wenn der Bildschirminhalt gescrollt wird. Und zwar im Firefox, wenn ich das richtig nachvollziehen kann. Nur seltsam ist, dass auch Bildschirme schwarz werden, wo Firefox nicht geöffnet ist. Ich versuche aktuell rauszubekommen, ob das Problem auch auftritt, wenn ich keinen Browser offen habe. Denn im Grunde ist bei mir immer (!) mindestens ein Browserfenster auf, wenn ich mit der Workstation arbeite. Das werde ich zum Testen u.U. komplett lassen und einen anderen Rechner für den Browser nehmen. Wenn der Effekt dann unterbleibt, kann ich die Sache zumindest eingrenzen. Zuerst einmal habe ich aber nur Firefox aus dem Rennen genommen und nutze auf der Workstation halt einen anderen Browser. Wird auch dann ein Bildschirm schwarz, will ich wie gesagt mal komplett eine Weile ohne Browser auf der Workstation arbeiten (hab ja ein paar weitere Rechner zur Verfügung). Aber im Moment zeigen sich die Effekte nicht. Könnte echt sein, dass meine Firefox-Installation auf der Workstation einen Schlag weg hat.
  2. Das zweite Problem hängt mit der Meldung „AH03099: ap_queue_pop failed“ auf meinem V-Server zusammen. Wenn ich aus WordPress einen neuen Beitrag poste, hängt sich mein kompletter Server auf und alle (!)  Domain und Sub-Domain sind nicht mehr erreichbar. Manchmal ist das Problem nach ein paar Minuten automatisch erledigt und Neustart vom Server hilft in jedem Fall. Nur ist das wirklich keine Dauerlösung. Die error.log-Datei von Apache zeigt nun beim Timestamp nach so einem Post – ohne Übertreibung – ein paar Tausend dieser Meldungen. Im Internet gibt es den Hinweis, dass PHP-FPM das Problem sein könnte (neben einem Bug in manchen Apache-Versionen). Tatsächlich tippe ich aber auch auf ein PHP-Problem und habe jetzt sowohl die PHP-Version auf 8.2.x hochgestellt als auch von PHP-FPM auf FastCGI umgestellt. Dieser Post wird u.U. schon zeigen, ob das Problem damit gelöst ist oder nicht.

Halber Erfolg

Hm, der letzte Post hat meinen Server wieder eingefroren und auch Seiten mit anderen Domains (etwa rb.autoren-net.de) waren temporär tot. Aber kein Fehlerlog und dieses Mal musste ich den Webserver nicht neu starten. Ich habe nur einige Package auf dem V-Server (u.a. auch Apache) aktualisiert, einige Plugins vorher schon dekativiert und nach einer Weile war er wieder erreichbar. Mittlerweile sind weitere Plugins deaktiviert bzw. gelöscht. Das wurde mittlerweile eine richtige Unordnung. Mal sehen, ob dieser Post aus WordPress dann keine Probleme mehr macht oder weiter ein Post für Magenverstimmung bei Apache sorgt.

Edit: Die Magenverstimmung ist noch da, aber nicht mehr so schlimm. Posten führt dazu, dass gut 1 Minute Schicht im Schacht ist, aber dann scheint es wieder zu gehen. Vielleicht ist auch MySQL bzw. MariaDB schlecht. Werde mal über alle DB eine automatische Reparatur laufen lassen.

E-Mails und das Spam-Problem

Die zunehmende Belästigung durch Spam nervt mich ja schon seit langer Zeit. Mittlerweile habe ich meinen E-Mail-Server bzw. meine E-Mail-Accounts halbwegs gegen Spam geschützt. Zwar laufen wohl noch Spams in hoher 2-stelliger Anzahl pro Tag ein, aber die meisten werden geblockt bzw. direkt gelöscht, ohne dass ich das mitbekomme. Und von dem Rest wird die größte Anzahl automatisch in den Spam-Ordner verschoben.

Aber jetzt habe ich das andere Problem gehabt. Bei einem Kunden sind die Mails von mir bzw. meinem Mailserver im Spamordner gelandet. Etwas seltsam, denn seit ich meinen eigenen V-Server und damit auch einen Mailserver betreibe, habe ich noch bei keinem anderen Kommunikationspartner Rückmeldungen über Probleme oder verlorengegangene bzw, nicht angekommene E-Mails bekommen. Und in den Kommunikationen mit mehrfachen Antworten war nie eine logische Lücke zu erkennen. Zwar stelle ich mal hin und wieder was an dem Mailserver um (aber nur, weil ich mich vor Spam schützen will) und aktualisiere die Software regelmäßig, aber ich betreibe ihn ja jetzt gut 25 Jahre unter der Domain.

Aber ich hatte von dem Admin des Kunden einige Tipps bekommen, was an meinem E-Mail-Server nicht korrekt eingerichtet sein könnte. Das waren meine Angaben zu Reverse DNS (war aber ok), DKIM (hatte ich gar nicht aktiviert), SPF und DMARC. Da ich mich ja als Programmierer und nicht Administrator verstehe, sind mir diese Konfigurationsparameter auch nur am Rande vertraut, aber mit den Tipps von dem Kunden-Admin sollte ich meinen E-Mail-Server jetzt hinsichtlich der Konfiguration so verbessert haben, dass er „vertrauenwürdiger“ beim Versenden meiner E-Mails daherkommt.

Thunderbird und das Zertifikat :-(

Diese Woche war ich zum Aufnehmen eines Videotrainings für LinkedIn Learning sowie der Erledigung einer weiteren Zusatzaufgabe hauptsächlich in meinem Büro in Eppstein. Da arbeite ich mit meinem Mate-Notebook. Ab Mittwoch konnte ich von da aber keine Mails mehr mit meinem Standard-Email-Account verschicken. Empfang ging und auch das Versenden meiner anderen Accounts beim GMX ging problemlos. Seltsamerweise ging das Versenden über meinen Standard-Email-Account per SmartPhone weiter ohne Probleme. Also habe ich ein Problem auf dem Matebook angenommen und mich erst einmal nicht weiter darum gekümmert. Aber zurück in Bodenheim konnte ich auch an der Workstation keine Emails mit dem Standard-Email-Account versenden. Was mich dazu gebracht hat, mir die Fehlermeldung anzusehen.

Ich habe nun einen eigenen V-Server und den zertifiziere ich mit Let’s Encryp. Thunderbird hat nun gemeldet, dass das Zertifikat meines Servers aber nicht ok wäre. Von einen Tag auf den anderen. Mein Zertifikat wird automatisiert in regelmäßigen Abständen erneuert und mittlerweile wird Let’s Encryp auch recht gut akzeptiert. Die plötzliche Meldung von Thunderbird war daher für mich unverständlich, auch wenn in der Tat der eingetragene Server im Zertifikat durch meinen V-Server wohl etwas kritisch sein kann. Aber man kann da ja Sicherheitsausnahmen  in Thunderbird einrichten. Und genau das habe ich gemacht.

Wirkungslos. Beim Versenden per SMTP immer wieder die Fehlermeldung.

Also alle Einstellungen in Thunderbird von links auf rechts gedreht und wieder zurück. Verschlüsselungsverfahren, Ports, etc. in allen denkbaren Varianten ausprobiert.

Wirkungslos.

Dann auf dem Server explizit alle Zertifikatseinstellungen untersucht und aktualisiert bis hin zum Neustart des Servers.

Wirkungslos. Weiter die Fehlermeldung in Thunderbird und kein Versenden möglich.

Dann mich erinnert, dass das Versenden mit dem SmartPhone doch ging. Weiterhin keine Probleme. Und dann erinnert, dass ich auf meinem alten Terra-Notebook noch eine ältere Version von Thunderbird installiert hatte. Ausprobiert. Versenden problemlos möglich. Alle Einstellungen verglichen (inklusive Zertifikate). Identisch. Älterer Thunderbird – keine Probleme. Neuerer Thunderbird – ignoriert Sicherheitsausnahme und kein Versenden möglich. Angeblich könnte der Fehler in Thunderbird auch von Antivirenprogrammen kommen. Deaktiviert.

Wirkungslos.

Aus Verzweiflung andere E-Mail-Clients wie eM, Pegasus und sogar Outlook (was ich eigentlich unter keinen Umständen nutzen will) ausprobiert. Maximal ein Hinweis auf das Zertifikat und ob ich trotzdem den Server nutzen will? Danach Versenden problemlos möglich.

Nun nutze ich eine portable Version von Thunderbird und auf den NAS habe ich davon eine lauffähige Kopie, die ich aber schon seit vielen Monaten nicht mehr gestartet hatte. Mit all den gleichen Einstellungen, wie auf dem Notebook und der Workstation. Ausprobiert – Warnung hinsichtlich des Zertifikats. Sicherheitsausnahme eingerichtet. Versenden danach problemlos. Laden der Emails ebenso.

Alle Einstellungen verglichen – identisch.

Thunderbird – was machst Du?

Ich arbeite jetzt mit der Version vom NAS weiter, denn da ist vermutlich ein Update von Thunderbird unterblieben, das diesen ganzen Müll bewirkt, und vermeide eine Aktualisierung dieser Version. Außerdem behalte ich für alle Fälle noch Pegasus – auch wenn das Programm optisch schon antik daherkommt. Zudem hoffe ich, dass die Version von Thunderbird, die im Moment das Problem hat, durch ein kommendes Update vielleicht wieder korrigiert wird. Aber Spass machen diese elenden Probleme wirklich nicht und obwohl ich Thunderbird seit vielen Jahren die Treue halte – ich bin massiv am Überlegen, ob ich nicht auf ein anderes Email-Programm umsteige. Und wie ernst es mir ist, sollte man daran erkennen, dass ich sogar Outlook in Erwägung ziehe.

 

 

SFTP-Einstellung – die Nachwehen vom Server-Umzug

Ich bin bereits vor einigen Monaten mit meinem Server bzw. V-Server umgezogen, aber einige Sachen sind noch immer nicht ganz aufgeräumt bzw. vollständig eingerichtet. Etwa der FTP-Zugang. Ich habe aus Sicherheitsgründen sowieso mittlerweile (weitgehend) auf SFTP umgestellt, aber genau da gab es Probleme.

Als root konnte ich mich mit SFTP einloggen, aber die Dateien und Verzeichnisse nur ansehen und nicht runterladen bzw. irgendetwas hochladen. Bei ein paar Verzeichnissen bzw. Domain hat FTP funktioniert – mit verschiedenen Usern, bei anderen nicht. Und SFTP ging mit anderen Usern gar nicht. Aber ich konnte den zentralen Fehler irgendwann identifizieren.

ERROR: Received unexpected end-of-file from SFTP server

Die Suche danach in Internet hat zur Lösung geführt. Auch wenn die bei mir etwas anders gelagert war als in den Quellen beschrieben. Aber im Kern war es das – in der Konfiguration des SSH-Daemons gab es ein Problem. Da wurde was bei der Installation des V-Servers durch den Provider nicht ganz korrekt konfiguriert.

Ein Lösungsvorschlag war, in der Datei /etc/ssh/sshd_config nach dem folgenden Eintrag zu suchen:

# Subsystem sftp /usr/lib/openssh/sftp-server

Auskommentieren beibehalten und das folgende ergänzen, war der Tipp:

Subsystem sftp internal-sftp

Dumm nur, dass der Kommentar bei mir nicht gesetzt war. Das SFTP-Subsystem war also schon aktiv.

Eine andere Quelle hat die Zeile genannt:

Subsystem sftp /usr/libexec/openssh/sftp-server

Und das hat mich zu der Lösung geführt, die für meinen Server gepasst hat. Denn diese Pfadangabe gab es bei mir nicht. Folge – ich habe verstanden, was es dem ersten Fall mit dem Verweis auf das interne SFTP auf sich hat.

Die Lösung bei mir war, den SFTP-Server von OpenSSH auszukommentieren, auf das interne SFTP umzustellen und dann mit

service sshd restart

den SSH-Daemon neu zu starten.

Jetzt scheint der Zugang mit SFTP bei allen Domains bzw. allen eingerichteten Usern zu funktionieren.

CronTab, Schedule und Python

Nachdem ich vor ein paar Wochen meinen neuen V-Server auch gleich auf eine neue Version von Ubuntu umgestellt hatte, musste ich sämtliche Webseiten wieder neu einspielen. Bis auf meine Webseite zum Gleitschirmfliegen, in der ich eine Webcam und Wetterdaten von einem Flughang bereitstelle, konnte ich auch alle Seiten problemlos wieder einspielen. Nur diese Seite (ein Joomla!-System) hatte herumgezickt und deshalb habe ich sie einfach neu aufgesetzt (jedoch mit WordPress). Aber ein Feature habe ich da auf die Schnelle nicht hinbekommen – das Kopieren und Sichern des aktuellen Bildes der Webcam, das minütlich mit FTP auf meinen V-Server geladen wird.

Es ist aber ganz hilfreich, wenn man über eine gewisse Zeitspanne verfolgen kann, wie etwa schon vor Ort befindliche Gleitschirme oder Windfahnen sich verhalten, um zu entscheiden, ob sich ein Tripp an den Hang lohnt. Ich wurde sogar explizit gebeten, dieses Feature wieder bereitzustellen.

Die originalen PHP-Skripte hatte ich noch alle, aber das Zeug war so zusammengefrickelt (wie so oft), dass ich erst einmal meine eigenen Codes nicht mehr verstanden habe.

Aber da ich parallel im Moment Themen sammle, die ich irgendwann in meinen wöchentlichen Tipps & Tricks zu Python bei LinkedIn Learning (LiL) verwenden kann, kam ich auf die Idee, das Kopieren doch mit Python statt mit PHP zu machen sowie auch das Schedulen vielleicht auch gleich mit Python. Es gibt ja dazu das sched-Modul und/oder die klassischen Module shutil, datatime und time. Dazu gibt es noch in der Community das zusätzliche Module schedule. Also habe ich mich damit eine Weile beschäftigt. Allerdings kam ich darüber über kurz oder lang auch auf die eigentlichen Crontabs von Linux/Unix. Und wenn man die genauer ansieht, ist es fast einfacher, die direkt zu schreiben, als sie von einem Framework wie dem schedule-Modul generieren zu lassen.

Auf der anderen Seite musste ich zudem noch meinen V-Server weiter konfigurieren. Dabei habe ich auf dem Weg nano nachinstalliert, denn ich greife ja per SSH auf den V-Server zu und mit Erschrecken festgestellt, dass da bisher mir nur vim zur Verfügung stand. Also so rudimentär will ich doch nicht mehr arbeiten.

In der Folge habe ich meine neu erstellen Python-Skripte zum Kopieren der Dateien und dem täglichen Löschen des Verzeichnisses (mein Server soll ja nicht volllaufen) hochgeladen und in die CronTab direkt eingebunden. Das geht ganz einfach und logisch, wenn man sich von der Syntax nicht abschrecken lässt.

  • crontab -e öffnet die CronTab-Datei.
  • Wenn man mit nano arbeitet, kann man mit Strg+o die Datei speichern und mit Strg+x den Editor verlassen. Mehr braucht man da eigentlich nicht zu wissen.
  • Mit crontab -l kann man sich alle Cronjobs anzeigen lassen und
  • mit crontab -r bei Bedarf alle Cronjobs löschen (was aber brutal ist, weil direkt alles weg ist).

Die eigentlichen Einträge in der CronTab sehen etwa so aus:

# m h dom mon dow command
*/2 8-20 * * * python3 [pfad]/copierereichenbach.py >> /var/www/vhosts/rjs.de/rb.autoren-net.de/thumb/log.txt
* 5,23 * * * python3 [pfad]/loeschereichenbach.py

Das kopiert dann alle 2 Minuten in der Zeit von 8 bis 20 Uhr das aktuelle Bild der Webcam und um 5 und 23 Uhr wird das Verzeichnis gelöscht.

In Python selbst arbeite ich mit shutil.rmtree() und os.mkdir() beim Löschen des Verzeichnisses. Einfach alles weghauen und dann das Verzeichnis neu erstellen.

Beim Kopieren nehme ich shutil.copy2() und hänge an den Standarddateinamen einfach einen Timestamp an der von datetime.datetime.now().timestamp() geliefert wird.

Das Anzeigen der Bilddateien mache ich natürlich weiter mit PHP – da konnte ich eines meiner altern Skripts nach einer kleinen Anpassung wieder verwenden.

Server-Umzug abgeschlossen

Der Umzug meines V-Servers sollte jetzt fertig sein. Der E-Mail-Server läuft und ist hinreichend konfiguriert. Der Spamschutz scheint besser wie vorher zu sein und auch die Kommunikation mit einer E-Mail-Adresse, die bisher nie durchging, hat eben funktioniert.

Soweit ich das sehen kann, sind jetzt auch alle Webseiten von mir wiederhergestellt und gleich mal auf den neusten Stand aktualisiert. Die unwichtigste Seite hat – natürlich ;-(  – die meiste Arbeit gemacht. Aber ich habe zumindest wieder etwas zu der Bedeutung von Eigentum und Gruppenzugehörigkeit unter Linux (und auch WordPress) gelernt und diverse Linux-Shell-Befehle geübt. Bisher war ich wirklich so naiv und dachte, dass Dateirechte die entscheidenden Stellen sind und man spätestens mit 755 auf der sicheren Seite hinsichtlich der Ausführung, dem Zugriff und ggfl. Schreiben in entsprechende Verzeichnisse auf dem Server sein sollte, wenn man Webseiten bereitstellt. Ich habe wegen diverser Probleme eine gefühlte Ewigkeit erfolglos mit den Schreibrechten herum experimentiert (sowohl über FTP als auch direkt per SSH mit chmod bis hin zu 777), bis mir aufgefallen war, dass bei den Webseiten ohne Probleme ganz andere Eigentumsrechte und Gruppenzugehörigkeiten da waren als bei denen mit Problemen. Da lag der Hase im Pfeffer und root ist nicht immer root (zumindest nicht im universellen Sinn – der root des SSH ist nicht immer der root der Webserver oder gar irgendeiner Verwaltungssoftware wie Plesk). Admin fuddeln vielleicht da rum – unglaublich.

Mit chown -R für den Eigentümer und chown : für die Gruppenzugehörigkeit haben sich dann aber (fast) alle Probleme in Luft aufgelöst. Nur die Zugriffs- bzw. Rechteprobleme bei der unwichtigsten Seite (einem Joomla!-System) habe ich einfach nicht in Griff bekommen. Die Seite habe ich dann kurzentschlossen komplett neu aufgesetzt (jetzt aber als WordPress-System) und dann einfach die wichtigsten Inhalte aus meiner lokalen Sicherung eingefügt.

Und da ich gerade dabei war, habe ich auf dem neuen V-CordovaServer Docker angeschaltet und gleich mit meinem Cordova-Skript für die kommende Vorlesung an der TH Bingen getestet. Das ging wie Butter durch ein heißes Messer – oder auch umgekehrt. Alle notwendigen Programme und Bibliotheken wurden problemlos (und fix) installiert und der Container ist sofort gelaufen. Das konkrete Erstellen der Cordova-App für eine Android-Plattform ging ebenso perfekt. Ich habe mich dann noch von einem anderen Rechner per SSH auf dem Server eingeloggt und aus dem Terminal die generierte App aus dem Docker-Container auf das Host-System kopiert. Null Problemo. Unter Linux läuft so Zeug die Docker einfach perfekt.

Ich komme immer mehr auf den Geschmack, meine Kenntnisse um Docker etwas zu intensivieren und zudem mehr mit dem Server zu machen als bisher.

V-Server-Upgrade des Betriebssystems mehr oder weniger geglückt

Ich bin wegen des Upgrades meines V-Servers seit über einem Jahr wie die Katze um den heißen Brei geschlichen. Es kann einfach zu viel schief gehen. Aber nachdem ich die Hardware durch den neuen Vertrag massiv aufgerüstet habe, wären ein Verweilen auf dem alten Ubuntu 12 LTS sowohl Blödsinn als auch langsam ein Sicherheitsrisiko gewesen. Nachdem ich gestern aus meiner Sicht alle relevanten Daten meiner bisherigen Installation gesichert hatte, habe ich den Sprung gewagt und über Nacht die Aktualisierung auf Ubuntu 18 LTS angestoßen. Die Nacht habe ich aber deshalb richtig schlecht geschlafen. Doch heute morgen war der Server auf dem neuen Stand – aber natürlich ohne alle meine bisherigen Daten und Einstellungen. Weder waren Webseiten da noch ging E-Mail. Was aber klar war. Und jetzt musste es sich zeigen, ob ich das Upgrade wirklich sorgfältig vorbereitet hatte und meine rudimentären Admin-Kenntnisse für das Wiederherstellen der Webseiten und der restlichen Dienste genügen.

Das Fehlen der E-Mail war erst einmal das größte Problem und ich habe versucht, meine gesicherten Einstellungen einfach zurückzuspielen, um möglichst schnell wieder per E-Mail erreichbar zu sein. Das ging gründlich schief und auch der 1. Versuch, meine gesicherten Webseiten wiederherzustellen, ebenso. 🙁

Also habe ich den Server gleich noch einmal vollkommen plattgemacht und ein 2. Mal neu installiert.

Wenn man es besonders eilig hat, sollte man langsamer gehen.

In dem zweiten Versuch habe ich nach der Neuinstallation erst meine Haupt-Domain rjs.de vollkommen neu und leer aufgesetzt und dann zuerst den E-Mail-Server neu konfiguriert und auch mein E-Mail-Konto komplett neu angelegt – natürlich mit den bisherigen Daten. Nach einigem Hin- und Her mit SMTP und Zertifikaten etc. ging das aber dann durch. Das ist schon mal das Wichtigste gewesen.

An die Wiederherstellung der Webseiten bin ich dann auch indirekt gegangen.

  1. Anlegen einer Datenbank mit den alten Zugangsdaten, die für die Webseite bisher eingerichtet waren.
  2. Einspielen des gesicherten Dumps.
  3. Kopieren alles gesicherten Dateien aus dem Sicherungsverzeichnis auf dem Server in das neu angelegte Verzeichnis

Das hat für meine zentrale Webseite und den Blog (offensichtlich) schon mal funktioniert und auf dem Weg werde ich wohl auch noch die anderen Seiten über den Tag reproduzieren können.

Aber es gibt diverse Kleinigkeiten wie FTP-Zugänge, Schreibrechte für die automatische Aktualisierung durch das CMS, Zertifikate (ich nutze Let’s Encrypt, aber da gibt es wohl auch im Vertrag eine Möglichkeit, ein anderes Zertifikat zu verwenden), Aktualisierungen etc., die noch einige Arbeit machen werden. Und ich will gar nicht wissen, was ich alles übersehen habe und/oder doch verloren gegangen ist.

Aber die wichtigsten Sachen sind wohl gutgegangen :-).

Leider kein automatisches Betriebssystem-Update bei dem neuen V-Server

Der Umzug auf den neuen V-Server ging fix und sowohl die Beschleunigung beim Laden der Webseiten ist deutlich zu merken. Auch der zusätzliche Platz steht zur Verfügung. Aber leider wurde einfach nur mein bisheriges System gespiegelt. Was bedeutet, dass ich weiter Ubuntu 12 LTS als Betriebssystem habe und nicht – wie es in der Beschreibung des Angebots steht – Ubuntu 18 LTS. Ärgerlich. Zwar nachvollziehbar wegen Zugriffsrechten und Passworten etc. Aber dennoch hätte der Provider auf dem neuen System m.E. die neue Version so vorinstallieren können, dass das Upgrade ohne großen Aufwand geht. Zwar kann man aus der Verwaltungsoberfläche des Pakets mit einem Klick Ubuntu 18 installieren, aber dann wird der bisherige Server plattgemacht und alle Daten etc. sind weg.

Das automatische tägliche Backup könnte bei einem Neuaufsetzen des Server vielleicht helfen, aber mir ist nicht klar, ob das Backup auch dafür gedacht ist oder nur einen vorherigen Zustand wiederherstellen lässt.

Es bleibt mir also nichts übrig als alles zu sichern, was ich nach dem Neuaufsetzen wieder brauche (Webseiten, Datenbanken, E-Mails, etc.) und zu hoffen, dass ich nichts vergesse sowie nach dem Neuaufsetzen des Servers mit Ubuntu 18 auch wieder alles einspielen kann und alles wieder funktioniert.

Es gibt auf dem Server nun ein Verzeichnis, dass beim Neuaufsetzen angeblich nicht gelöscht wird und dahin habe ich per SSH-Zugriff alles kopiert, was m.E. gesichert gehört. Aber ich traue dem Braten nicht so richtig.

Zusätzlich will ich deshalb wenigstens meine Webseiten und die Datenbanken lokal sichern. Aber das dauert – zumindest bei meinem grottenschlechten Internet-Anschluss hier in Bodenheim. Die Webseiten übertrage ich jetzt schon seit gut 8 Stunden per FTP auf meinen lokalen Rechner und es fehlen immer noch über 6000 Dateien. Den Dump der MySQL-Datenbank habe ich noch gar nicht gemacht.

Zwar ist das alles nicht wirklich viel Arbeit, aber es dauert eben eine elende lange Zeit, die ggf. auch der Upload wieder dauern wird, wenn die Sicherung in dem Backup-Verzeichnis auf dem Server doch nicht funktioniert hat.

Server-Upgrade

Ich habe seit 2012 einen V-Server und in der Zeit da nicht wirklich viel aktualisiert. Das System ist mit den Eckdaten Ubuntu 12.04 LTS , 1 vCore, 2 GB RAM und 25 GB Speicherplatz mittlerweile ziemlich in die Jahre gekommen bzw. einfach im Vergleich zum Status quo zu schwach auf der Brust. Als eben die Werbemail von meinem Provider für ein Upgrade hereinkam, habe ich es kurzentschlossen angenommen. Das neue Paket kostet monatlich nur unwesentlich mehr und sollte mit 6 virtuellen Kernen, 16 GB RAM garantiert und einer SSD mit 300 GB signifikant besser den modernen Anforderungen genügen. Die Datenanbindung ist ebenso schneller als beim alten Paket und auch was die bereits installierte Software angeht, sollte es moderner sein oder aber ich gehe die Aktualisierung parallel zum Upgrade noch an.