Eine Änderung auf /var/lib/php5/sessions brachte den gewünschten Erfolg. Das hatte ich zwischendurch schon mal aktiviert, aber wohl nicht lange genug gewartet. Warum das so ist, hat mir der Support nicht mitgeteilt, aber jetzt funktioniert es.
Euch allen vielen Dank für die vielen Kommentare.
Ist das kein Backscatter von Microsoft - du hattest doch im Maillog etwas von MS stehen - oder irre ich mich da?
Hast du SPF und DMARC gesetzt?
Mit den Mails solltest du mal deinen Spamfilter füttern. List-Unsubscribe und Mailer Daemon passen eigentlich nicht zusammen.
Im Maillog (und Mail-Header) steht nichts von Microsoft, lediglich der To-Header der "ursprünglichen" Mail ist immer an MS gerichtet (email.msn.com, hotmail.com, hotmail.co.uk).
SPF und DMARC sind gesetzt.
Gerade eine generische "Delivery report"-Mail erhalten (so der Betreff). Header passt soweit, der Absender (postmaster@advance.ucdavis.edu) stimmt auch und der Empfänger ist support@xyz.de (wobei xyz eine meiner Domains ist).
Was genau läuft hier ab - bzw wieso habe ich diese Mail bekommen? (Meine Adresse taucht ja nirgends in den Headern oder sonst wo auf.)
Langsam nervt es. Die Nacht kam noch eine Mail vom gleichen postmaster an die gleiche Adresse. Jetzt gerade kam erneut so eine Mail, dieses Mal von einem anderen postmaster (aber wieder edu-TLD) und an eine andere Domain von mir
https://www.heise.de/security/meldu…en-4611068.html
Müssen wir wieder mit einer Reboot-Welle rechnen?
Hoffentlich nicht, so richtig reibungsfrei lief das doch noch nie ab... (egal ob seitens netcup oder seitens Kunde)
.lan ist doch keine offizielle TLD
Ja na und? Schadware verbreitet sich doch nicht nur auf Geräte mit offiziellen TLDs... Wie sinnvoll es ist, das sich so etwas über Hostnames verbreitet ist sowieso fraglich, aber in Zeiten von IPv6 kann das durchaus sinnvoller werden, da kann man nicht mal eben schnell das Subnetz abscannen
Warum machen Android Smartphones eigentlich solche Dinge? Das sieht irgendwie... ungesund aus. Und nein, das Smartphone gehört keinem Kind mit langer weile oder so, diese Domains hat garantiert keiner versucht händisch aufzulösen... hat jemand schonmal selbiges bei sich beobachtet?
Was hast du dir denn da eingefangen?
Es betrifft beides. Das Webhosting G8 dürfte in etwa gleich viele Jährchen auf dem Buckel haben wie die RS/VPS. Was immer die VPS G9 besser und schneller machen soll als die G8 trifft auch auf das Webhosting zu.
Ach du meinst die 9er Webhostings ziehen dann auf die alten 8er RS/VPS? :p
Das Ende der G8 ist der Anfang der G9. Oder wir machen einen auf Microsoft, dann ist es der Anfang der G10.
Was genau das mit Webhostings zutun hat weiß ich auch nicht; eigentlich betrifft es RS/VPS
Schau einmal, ob einer der involvierten Server auf http://www.backscatterer.org/ steht, oder offen dafür ist.
Das schaut mir irgendwie nach Backscatter aus, wo ein gefakter Absender (Deine Domain) über ein offenes Relay rausging und der Empfänger Dir das Undeliverable für eine Weiterleitung schickt. Ich bin aber schon etwa müde und phantasiere vielleicht nur.
Leider nicht gelistet...
Workaround: Ist es eventuell möglich, sessions in der Datenbank zu speichern, statt im Filesystem?
Ich wüsste nicht, wie. Ich komme gar nicht erst so weit, dass ich mit der Software arbeiten könnte. Die Warnmeldung taucht direkt nach der Durchführung der Installation auf, ein Login ist nicht möglich. Im Installationsverzeichnis befinden sich natürlich haufenweise Dateien, aber da ich die Anwendung bisher auch nicht kenne, wüsste ich nicht mal, wo ich mit der Suche anfangen sollte.
Warten wir mal ab, was Hersteller- und netcup-Support so zu sagen haben.
Vielen Dank erst Mal für die vielen Hinweise.
Wäre ja wohl einfach zu testen mit einem kleinen Skript. Das ist dann meist auch überzeugender, weil leicht nachvollziehbar, als wenn ein komplexes System das behauptet.
Bestimmt, wenn ich wüsste, was da genau geprüft wird. Die Variablen auszulesen und darauf zu prüfen, ob open_basedir session.save_path enthält ist simpel, aber auch unnötig, da phpinfo() das ja bestätigt. Oder sehe ich das falsch?
Würde eine durchschnittliche Galeriesoftware auch wirklich korrekt prüfen, warum sie jetzt hier nicht schreiben darf? Oder würde sie einfach sagen: Ich darf nicht schreiben, wird wohl open_basedir sein?
Ist zwar weit hergeholt, aber ansonsten dürfte das hier im Thread beschriebene ja eigentlich gar nicht passieren können.
Dazu noch mal: die Fehlermeldung klingt schon ziemlich spezifisch. Da ich aber nicht in den Code reingeschaut habe, weiß ich natürlich auch nicht, was an der Stelle genau passiert.
PHP session.save-path directory is blocked by open_basedir. Your server session.save_path is set to /var/lib/php/sessions but this directory is not within your open_basedir allowed paths. If you can't login to your X3 panel, it means X3 can't save the login-session, in which case you need to contact your host.
Zu open_basedir, ja. Aber zu session.save_path? Laut Deinem Posting meint die Gallery X3, dass der
/var/lib/php/sessionswäre - aber glaubst Du ihr und dem Plesk das auch? Hast Du auch nach den Änderungen „Übernehmen“ geklickt?
Sorry, ja, auch die Variable ist laut phpinfo() korrekt gesetzt.
Ich hab parallel dazu auch im Forum von X3 mal einen Post aufgemacht, mal schauen, ob da was kommt. Den Support von netcup werde ich aber auch noch mal kontaktieren. Vielleicht liegt es ja wirklich an mangelnden Schreibrechten, wie schon tab schrieb.
Hmm, ich meine mich zu erinnern, dass session.save_path früher zumindest per Default auf /var/lib/php5/sessions gestanden hat. Sollte eigentlich nichts machen, weil beide Pfade /var/lib/php/sessions und /var/lib/php5/sessions im open_basedir drin sind. Hat mich halt immerein wenig erheitert, dass meine PHP 7.2 sessions in /var/lib/php5/sessions landet. Aber es hat funktioniert, deswegen habe ich da nicht lang rumprobiert. Aber, was wäre, wenn der PHP-User in /var/lib/php/sessions zum Beispiel keine Schreibrechte hätte oder noch extremer, der Pfad gar nicht existiert? Würde eine durchschnittliche Galeriesoftware auch wirklich korrekt prüfen, warum sie jetzt hier nicht schreiben darf? Oder würde sie einfach sagen: Ich darf nicht schreiben, wird wohl open_basedir sein?
Ist zwar weit hergeholt, aber ansonsten dürfte das hier im Thread beschriebene ja eigentlich gar nicht passieren können.
So was in der Art vermute ich mittlerweile auch, ja. Ich werde wohl den netcup-Support mal damit konfrontieren.
Siehe mein Einstiegsbeitrag, da sieht alles gut aus.
Ich bin gerade etwas verwirrt, vielleicht kann mich ja mal jemand entwirren.
Gerade eine generische "Delivery report"-Mail erhalten (so der Betreff). Header passt soweit, der Absender (postmaster@advance.ucdavis.edu) stimmt auch und der Empfänger ist support@xyz.de (wobei xyz eine meiner Domains ist).
Hello, this is the mail server on advance.ucdavis.edu.
I am sending you this message to inform you on the delivery status of a
message you previously sent. Immediately below you will find a list of
the affected recipients; also attached is a Delivery Status Notification
(DSN) report in standard format, as well as the headers of the original
message.
<xXRPGPeterXx@hotmail.co.uk> delivery failed; will not continue trying
Original-Envelope-Id: 23008_912080_91249_0
Reporting-MTA: dns;advance.ucdavis.edu
X-PowerMTA-VirtualMTA: 172.31.20.62
Arrival-Date: Tue, 10 Dec 2019 16:42:06 +0000
Final-Recipient: rfc822;xXRPGPeterXx@hotmail.co.uk
Action: failed
Status: 5.5.0 (unknown protocol-related status)
Remote-MTA: dns;hotmail-com.olc.protection.outlook.com (104.47.124.33)
Diagnostic-Code: smtp;550 5.5.0 Requested action not taken: mailbox unavailable.
X-PowerMTA-BounceCategory: hardbncMIME-Version: 1.0
From: EasyJet <Support@RLPK.de>
Subject: Chance to win EasyJet plane tickets worth ?1500!
Reply-To: EasyJet <reply@ucdavis.edu>
Received: from ucdavis.edu (172.31.20.62) by ucdavis.edu id XvACiMqejnJa for <xXRPGPeterXx@hotmail.co.uk>; Tue, 10 Dec 2019 17:42:07 +0100 (envelope-from <Support@pkCG.de>
To: xXRPGPeterXx@hotmail.co.uk
Content-Transfer-Encoding: 7bit
Content-Type: text/html; charset="UTF-8"
Date: Tue, 10 Dec 2019 17:42:07 +0100
List-Unsubscribe: <mailto:vreiiRDDrYVVXq.sara@wetteam.asia?subject=unsubscribe&body=unsubscribe>Was genau läuft hier ab - bzw wieso habe ich diese Mail bekommen? (Meine Adresse taucht ja nirgends in den Headern oder sonst wo auf.)
z.B.
Sei doch so nett und schneide nicht die Hälfte weg, dann kann dir niemand helfen 
Also her mit den Logs
es geht in die nächste Paranoia-Runde
Sind nicht bald mal alle Lücken entdeckt?
Die Mutter aller IT-Probleme hat einen Namen: Microsoft.
Ein Dozent von mir haut regelmäßig folgenden Spruch raus: "Rechnen Sie mit allem - rechnen Sie mit Microsoft"
Ja, ist bei mir jetzt auch so. Ich fasse es nicht. Ich kann nur hoffen, dass das ein bedauerlicher Fehler ist, ansonsten würden die Webhostings für mich damit weitestgehend nutzlos und auf meiner Kündigungsliste landen müssen.
Irgendwas scheint sich zu tun, vorhin standen noch mehr bei mir auf der schwarzen Liste, nun sind es nur noch folgende: "exec,passthru,shell_exec,system,proc_open,popen,show_source"
