Unklare Benutzerregistierungen

Ich entschuldige mich gleich am Anfang dafür, wenn ich seriöse neue Benutzer gerade gelöscht habe (neue Registierungen der letzten 30 Tage). Aber die letzten Wochen hat die Anzahl neuer Benutzer in meinem Blog massiv zugenommen. Das freut mich natürlich, wenn hohes Interesse an meinem Blog besteht und das echte neue Benutzer sind. Die verwendeten Domain bei der Registrierung als auch die ungewöhnliche Anzahl machen mich aber misstrauisch. Auch wenn Abonennten in WordPress (Standardrolle bei mir) normalerweise nichts Gefährliches machen können, will ich die Angelegenheit in Grff bekommen.

Entweder lasse ich in Zukuft keine neuen Benutzer zu oder aber – und das probiere ich erst einmal aus – neue Benutzer müssen erst aktiv freigeschaltet werden. Je nach Aufwand könnte das eine Lösung sein, auch wenn die Freischaltung dann eine gewisse Zeit dauern kann und vermutlich auch seriöse Interessenten leider rausgefiltert werden. Aber was ist die Alternative? Entsprechende PlugIns arbeiten ja auch mit Filtern etc.

Spam-User im Blog?

Gerade ist mir aufgefallen, dass sich innerhalb weniger Minuten mehrere neue User im meinem Blog registriert haben. Alle von der gleichen Domain getgmbreviews.com. Daraufhin wurde ich misstrauisch und die Suche mit im Internet ergab Hinweise darauf, dass die Domain für betrügerische Aktionen verwendet wird. Ich habe darauf meine bisherigen User durchforstet und erst einmal alle User mit der Domain als E-Mail-Adresse gelöscht. Auch von anderen recht auffälligen Domains wie mail.ru. Es tut mir leid, wenn damit u.U. seriöse User erst einmal wieder gelöscht sind und mein Misstrauen unbegründet ist, aber die ganze Sache ist mir einfach nicht koscher. Wobei ich User bei mir im Blog auch sowieso nur als Abonnenten führe. Die rechtlichen Gefahren mit Kommentaren sind in den letzten Jahren leider viel zu groß geworden.

Zusätzlich habe ich in meinem WordPress nun eine Funktion eingebaut, mit der ich bei der Registrierung Domains filtern kann. „Spam-User im Blog?“ weiterlesen

Neues Layout

Ich war das bisherige Layout meines Blogs leid. Mal wieder. Aber mit WordPress kann man ja recht schnell ein neues Design mit einem alternativen Theme einstellen. Ich habe mich für eines der Standard-Themes entschieden. Die sind m.E. wirklich brauchbar. Und natürlich musste ich wegen der Corporate Identity die Designs meiner Webseite und des Eigenverlags angleichen. „Neues Layout“ weiterlesen

WordPress-Desaster

Ein Standbein von mir ist ja Webprogrammierung (auch wenn das Thema in der letzten Zeit immer weniger wichtig wird) und ich lehne mich aus dem Fenster, dass ich Alles zu HTML und so gut wie Alles zu JavaScript kenne, was es zu wissen gibt. Im Grunde auch zu CSS, soweit es relevant ist. Auch zu CMS wie Joomla! und WordPress sollte ich mich ziemlich gut auskennen. Ich betreibe damit mehrere Seiten und habe dazu diverse Bücher geschrieben und Videotraining aufgenommen. Aber ein grafischer Builder, der als Plugin in einer WordPress-Installation von einer Agentur eingerichtet wurde, hat mich ausgeknockt und den Abschluss einer trivalen Aufgabe sabotiert. „WordPress-Desaster“ weiterlesen

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.

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.

ChatGPT und ich sind der Meinung, …

… dass das Einfrieren meines Webservers nach dem Posten aus WordPress an den Plugins liegen könnte. Ich habe mit ChatGPT eine Weile diskutiert und auf seinen Rat die Protokoll-Dateien von Apache mir angesehen (by-the-way: auch ChatGPT läuft nach eigener Aussage auf einem Ubuntu-Linux mit Apache). Aber die Error-Datei ist verdammt groß. Ich habe sie jetzt gelöscht und poste den Beitrag, um zu sehen, ob mein Server wieder einfriert. Und dann schaue ich mir das aktuelle Fehlerprotokoll an und deaktiviere entweder ein dort genanntes Plugin oder aber alle Plugins, um sie nach und nach wieder zu aktivieren. Da sich die ganze Aktion auf mein WordPress bezieht, werde ich (zum 1. Mal) auch nichts auf blogger.com parallel dazu posten.

Die Schlagworte zu dem Post sind übrigens von dem OpenAI-API im Playground generiert worden.

Alles Neu macht der November

Wiederkehrende Besucher meiner Webseite oder meines Blog fällt eventuell auf, dass das Design neu ist. Ich musste mal wieder einen Tapetenwechsel vollziehen und denke, dass ich mit Modern-Design ein feines neues Template gefunden habe. Dabei habe ich die Seite, über die ich einiger meiner Bücher im Selbstverlag anbiete, auch gleich auf das Template umgestellt, um eine Corporate identity einzuhalten.

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- Cordova Server 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.