Beiträge von weltmeister

    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.

    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?


    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.

    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.

    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?

    Auch heute noch einmal die Nachfrage wegen der uneingeschränkten nutzungsmöglichkeit von nginx: wie ist der Entwicklungsstand? Beispiel: Möglichkeit für eigene Rewrite-Regeln über die GUI .


    Die Anfragen nach schnellerem Hosting reißen nicht ab, vielen Kunden sind jedoch gleich wieder weg, wenn diese irgendwo "Apache" lesen.