Beiträge von weltmeister

Falls es interessant ist: unter PHP 7.3 tritt das Problem nicht auf. (Debian 10)

- Es ist PHP 7.4. aktiv

- PHP läuft über CGI/FastCGI

- Ausgabe open_basedir in der phpinfo:
/var/www/web35/:/var/www/web35/htdocs/:/var/www/web35/apps/:/var/www/web35/priv/:/var/www/web35/tmp/:/usr/share/pear/:/usr/share/php/:/tmp/:/usr/bin/:/dev/urandom

Exakt ist genau dies hinterlegt:

%HOME%/:%HOME%/htdocs/:%HOME%/apps/:%HOME%/priv/:%HOME%/tmp/:/usr/share/pear/:/usr/share/php/:/tmp/:/usr/bin/:/dev/urandom

Das sollte doch so passen?

Seit dem Update hagelt es teilweise Fehlermeldungen wie diese auf Kundenseiten:

Zitat

Warning: file_exists(): open_basedir restriction in effect. File(/definition.php) is not within the allowed path(s): (/var/www/web135/:/var/www/web135/htdocs/:/var/www/web135/apps/:/var/www/web135/priv/:/var/www/web135/tmp/:/usr/share/pear/:/usr/share/php/:/tmp/:/usr/bin/:/dev/urandom) in /var/www/web135/htdocs/wp-content/plugins/cornerstone/includes/classes/classic/elements/class-element-orchestrator.php on line 218

Zitat

<br />
<b>Fatal error</b>: Uncaught ImagickException: open_basedir restriction in effect. File(copyright.png) is not within the allowed path(s) in /var/www/web21/htdocs/datenbank/upload_ftp.php:20
Stack trace:
#0 /var/www/web21/htdocs/datenbank/upload_ftp.php(20): Imagick-&gt;__construct('copyright.png')
#1 {main}
thrown in <b>/var/www/web21/htdocs/datenbank/upload_ftp.php</b> on line <b>20</b><br />

Müssen wir noch etwas anpassen oder hat sich hier ein Fehler eingeschlichen?

Vor dem Update gab es keinerlei Fehlermeldungen.

Das Problem wird mit dem kommenden Update gelöst, siehe Preview.

Danke, das wäre ja eine ganz feine Sache und gewiss eine Entlastung im Support, da diese Frage immer wieder auftritt.

Zitat von taenzerme

Du meinst, so wie LiveConfig das bei allen Postfächern im Reiter Info macht?

Wo finde ich denn diesen Reiter Info?

Bei vielen Providern ist dies mittlerweile standard und dies würde unzählige Support-Anfragen einsparen. Kunden legen Mailadressen an und wissen oftmals nicht, was nun genau in die abrufenden Programme eingetragen werden muss, obwohl dies auf unseren Webseiten dokumentiert ist. Ich stelle mir das ganze so vor, wenn ein Mailkonto vorhanden ist, das dazu die Abrufdaten wie folgt angezeigt werden:

----------------------------------------------
Benutzer: info@example.com
Passwort: wurde durch Sie selbst vergeben
Postein- und Ausgangsserver: s1.example.com
Verbindungssicherheit: SSL
Authentifizierung: Verschlüsseltes Passwort
Port für Posteingang: 993 (IMAP)
Port für Posteingang: 995 (POP3)
Port für Postausgang: 465 (POP3 und IMAP)
----------------------------------------------

Kann auf diese Funktion im LiveConfig bitte noch für den Endkunden wie folgt unter folgendem Menüpunkt hingewiesen werden:

LiveConfig---> E-Mail ---> Spam-Filter

Beispiele:
info@example.org ---> bereits vorhanden
*@example.com ---> bereits vorhanden
*.ru ---> bitte als Beispiel ergänzen

Viele Kunden wissen gar nicht, dass es diese Möglichkeit gibt, komplette tlds sperren zu können.

Unsere Kunden fragen auch ständig danach. Es macht leider keinen Spaß, immer wieder sagen zu müssen: "es ist in Arbeit" - das machen wir nun schon seit 9 Jahren so. Bereits 2013 war doch eine ordentliche Lösung in Planung, oder irre ich mich da?

Zitat von antondollmaier

Dafür sorgen, dass Spam-Mails nicht zu Microsoft kommen.

Mögliche Quellen für solche Spam-Mails:

- CMS
- Weiterleitungen
- Kunden-Newsletter

Viel Erfolg. Wir sind seit 1,5 Jahren konsequent dran und haben seit dem keine Probleme mehr. Sind aber auch nicht bei Hetzner o.ä..

Alles anzeigen

Wie will man das zu 100% verhindern? Allein z.B. WordPress müllt die Postfächer der Kunden teilweise richtig zu. Viele Kunden sichern Kontaktforumlare z.B. nicht gegen Spam ab und sind dann auch noch so "blöd" und melden diese Mails als Spam bei hotmail, statt die Formulare zu deaktivieren oder mit einem Captcha gegen Spam abzusichern. Bei Kommentaren das gleiche. Jemand trägt einen Spam-Kommentar ein, dieser wird per Mail an den Kunden geschickt, z.B. an eine hotmail-Adresse. Was macht dieser? Genau: er meldet diese Mail als Spam, statt die Kommentarfunktion zu sperren oder ebenfalls abzusichern. Das reicht einige male hintereinander aus und schon ist die IP gesperrt.

Das selbe gilt auch für Weiterleitungen: es gibt Kunden, die lassen sich alles mögliche ungefiltert(!) an deren Mailadressen weiterleiten, z.B. hotmail. Somit wird natürlich auch der Spam massenweise ungefiltert weitergeleitet. Auch hier gibt es dann leider "Deppen", welche die bereits weitergeleiteten Mails als Spam bei hotmail melden, statt die entsprechenden Filter in LiveConfig zu aktivieren.

Bei einer Handvoll Kunden kann man ggf. noch "aufpassen", bei tausenden wird es schon schwierig. Nicht das wir ein Problem mit hotmail und Co hätten, aber hin und wieder trifft es auch mal einen unserer Server.

Ein Kunde hat sich gemeldet, dass sein 5 GB Webspace voll sei und er sich das nicht erklären könnte, da die hochgeladene Datenmenge genau 1 GB beträgt, was mehrfach geprüft worden ist. Nun war unklar, wo die restlichen 4 GB herkommen. Nach einiger Zeit und manuellem löschen des opcache waren die 4 GB wieder frei. Nun kann dies natürlich keine Dauerlösung für alle Kunden sein, den Cache ständig manuell löschen zu müssen.

Folgende Verzeichnisstruktur:

• php7/opcache ---> Hierin lagen noch uralte Cache-Daten, die bereits vor Jahren angelegt worden sind, aber nicht mehr genutzt worden sind.
• php53/opcache
• php54/opcache ---> Hierin befanden sich ca. 4 GB Cache-Daten.

Meine Fragen wären:

• wenn der Kunde z.B. von PHP 7 auf PHP 7.4 umstellt, würde es sinn machen, wenn der alte Cache in "php7/opcache" geleert wird, da sonst Datenmüll übrig bleibt, der z.B. in 10 Jahren noch auf dem Server liegt und Speicher benötigt.
• Wäre es weiterhin möglich, den Cache nach einiger Zeit automatisch zu leeren, damit es genau zu solchen Problemen künftig nicht mehr kommen wird?

Wichtig wäre auch, dass die Cache-Verzeichnisse nicht löschbar sind, im Moment kann der Kunde das Verzeichnis "opcache" problemlos komplett + Unterverzeichnisse wie z.B. "php74" löschen, was zur nichterreichbarkeit der Webseite führt.

Könnte dieses Problem bei dem nächsten Update bitte mit berücksichtigt werden?

Eine sehr gute Idee! +1

OK, ich frage ganz konkret und das soll keine Kritik sein: seit 2013/14 wird eine Backup-Funktion versprochen. Wann ist diese zu 100% in LiveConfig verfügbar? Es kommen permanent Anfragen dazu rein, einige Kunden werden schon seit vielen Jahren vertröstet, vor allem die, die vorher z.B. P*e*k genutzt haben, sind teilweise sehr schwer von LiveConfig wegen fehlender Funktionen zu begeistern, auch wenn schon bereits vieles einfacher ist. Es vergeht kaum noch ein Tag, wo nicht jemand nach einer Datensicherungsfunktion fragt.

Irgendwie ist alles so ruhig in letzter Zeit...

Ich bedanke mich dafür schon einmal im Voraus!

Ein Kunde benötigt diese Erweiterung. Wie kann ich ihm diese, ohne große Bastelarbeiten am System anbieten? Ich hatte bereits folgendes versucht:

apt-get install php-7.4-opt-xmlrpc
apt-get install php7.4-xmlrpc

... beides ohne Funktion.

Für die Standard-PHP-Version ist xmlrpc aktiv und funktioniert, nur will der Kunde verständlicherweise eine neue PHP-Version nutzen.

Gibt es kurzfristig eine Installationsmöglichkeit?

Ab wann gibt es die Möglichkeit, diese Ergänzungen komfortabel über die LiveConfig-Oberfläche einzufügen?

Ähnlich wie bei den E-Mails wünschen sich viele Kunden einen Hinweis per E-Mail, wenn der Webspace einen bestimmten "Füllstand" erreicht hat. Lässt sich dies wie bei den Mailkonten umsetzen?