KI in die Tonne und Deinstallation, damit das Programm läuft

Ich habe seit gefühlt Ewigkeiten Probleme mit meinem Email-Server. Genaugenommen mit Spam. Dabei muss man beachten, dass ich einen Linux-V-Server habe, der (leider) mit Plesk aufgesetzt ist. Wichtige Mails werden als Spam gewertet und nicht einmal mit einem Spammarker durchgestellt, während unzählige Spammails durchkommen, wobei das ja im E-Mail-Client abzufangen ist. Leider haben bisher alle Versuche, die Spameinstellungen bei SpamAssassin über Plesk zu ändern, fehlgeschlagen. Mit einer ganz dubiosen Fehlermeldung, die darauf schließen lies, dass irgendeine Datei nicht da war bzw. einen Fehler enthalten hat.

Ich hatte aber jetzt die Faxen dicke, nachdem schon wieder eine Auftragsbestätigung im Nirvana verschwunden war und ich das nur mit viel Glück mitbekommen habe, weil ich nachgefragt hatte.

Mit KI bin ich der Sache auf den Grund gegangen. Und wie eigentlich immer wurde die Sache ein endloser Schlauch an falschen Vermutungen und unnützen Tipps durch die KI. Nach gut 2 Stunden war ich diesen nutzlosen KI-Tipps müde und habe SpamAssassin mit dem Plesk-Installer in der SSH-Konsole deinstalliert.

Folge – die Spameinstellungen gingen anzupassen (sogar unter der Plesk-GUI) und das System scheint jetzt zu laufen. „KI in die Tonne und Deinstallation, damit das Programm läuft“ weiterlesen

Von AH03099 zu AH01909

Man oh man :-(. Apache ist nach den letzten Post aus WordPress heraus wieder eingefroren, aber in der error.log stehen nicht mehr tausende von AH03099-Fehlermeldungen, sondern  „AH01909: default:443:0 server certificate does NOT include an ID which matches the server name“. Das deutet ziemlich klar auf Probleme mit meinen Zertifikaten hin. Ich habe jetzt mal mein Default-Zertifikat von Plesk gelöscht und lasse nur noch mein Lets Encrypt-Zertifikat aktiv. Dazu habe ich ein paar Einstellungen umgestellt. Das ist reines Try-and-Error. Hoffentlich zerschieße ich mir nichts.

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.