Schlagwort: Ubuntu

WSL, Wine und Windows-VMs

Gerade mal WSL (Windows Subsystem for Linux) mit Ubuntu via Powershell unter Windows 11 installiert. Geht ganz gut und reduziert für manche Aktionen die Notwendigkeit, eine zusätzliche VM mit Linux (etwa unter VirtualBox oder VMWare) aufzusetzen. „WSL, Wine und Windows-VMs“ weiterlesen

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.

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.