Beiträge von kk

  • PHP 7.3.29, 7.4.21 und 8.0.8, Debian 11

    Wir haben uns das nun mal im Detail angeschaut.


    Zur ersten Fehlermeldung:

    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


    Bei PHP 7.3 tritt dieser Fehler nicht auf? Schwer vorstellbar. Diese Fehlermeldung deutet auf einen Programmfehler hin (da soll auf die Datei "/definition.php" zugegriffen werden, also im Server-Hauptverzeichnis). Diese Fehlermeldung findet sich bei Google auch schon irgendwo 2019 mal (Wordpress-plugin "Cornerstone").


    Zur zweiten Fehlermeldung:

    Zitat


    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->__construct('copyright.png')


    Das wird vermutlich eher mit der ImageMagick-Extension 3.5.0 zu tun haben als mit dem PHP-Update auf 7.4.21.
    Auch hier wäre interessant, ob das mit PHP 7.3.29 und IMagick 3.5.0 tatsächlich nicht auftritt. Auf den ersten Blick sieht es für mich aber problematisch aus, wenn eine Datei ohne absolute Pfadangabe geöffnet werden soll (das ist dann eher Glückssache, in welchem Verzeichnis sich der jeweilige Prozess gerade befindet). Ohne genauere Code-Kenntnis zu haben riecht das also nach eher schlampiger Programmierung. Man könnte sich vor Zeile 20 in /var/www/web21/htdocs/datenbank/upload_ftp.php mal das aktuelle Verzeichnis ausgeben lassen, in dem die Datei erstellt werden soll.


    Die open_basedir-Änderung in PHP 7.4.21 ist plausibel und sauber, wenn's dadurch Probleme gibt dann nur, weil eine Anwendung unter Ausnutzung des PHP-Bugs 76359 die open_basedir-Einstellung umgangen hat.


    Für weitere "bei mir auch"-Meldungen bitte jeweils eine komplette (exakte) Fehlermeldung mitschicken.

  • PHP 7.3.29, 7.4.21 und 8.0.8, Debian 11

    Ist vielleicht die selbe Anwendung (CMS/...) betroffen? Evtl. können Sie mal prüfen, ob die Anwendung per "ini_set" die open_basedir-Einstellung selber setzen/bearbeiten möchte.


    Aus dem Changelog zu PHP 7.4.21:
    "Fixed bug #76359 (open_basedir bypass through adding "..").


    Wir werden PHP 7.4.20 noch mal in unser Repo mit aufnehmen, um optional ein Downgrade zu ermöglichen.

  • PHP 7.3.29, 7.4.21 und 8.0.8, Debian 11

    Ja, das sieht gut aus. Dann müssen wir tiefer graben:


    - welche PHP-Version ist betroffen?
    - läuft PHP auf einem betroffenen Webspace via FPM oder via FastCGI?
    - wenn möglich, legen Sie bitte mal eine "phpinfo()"-Datei in einem betroffenen Webspace an und rufen diese mit einem Browser auf. Was steht dort bei "open_basedir"?

  • PHP 7.3.29, 7.4.21 und 8.0.8, Debian 11

    Ich kann mir nicht vorstellen dass das etwas mit dem PHP-Update zu tun hat. Die Fehlermeldung ist zudem ziemlich eindeutig.


    Auf was exakt ist denn open_basedir in der php.ini-Verwaltung im LiveConfig bei Ihnen eingestellt?

  • PHP 7.3.29, 7.4.21 und 8.0.8, Debian 11

    Hallo,


    unsere PHP-Pakete für Debian/Ubuntu wurden eben auf die heute veröffentlichten Versionen 7.3.29, 7.2.21 und 8.0.8 aktualisiert.


    Außerdem wurde die ImageMagick-Extension auf 3.5.0 aktualisiert, diese ist nun erstmals mit PHP 8 kompatibel.


    Last but not least wurden alle PHP-Pakete und -Erweiterungen in den Versionen 5.6, 7.3, 7.4 und 8.0 auch schon für Debian 11 ("Bullseye") gebaut. Debian 11 soll voraussichtlich Ende Juli erscheinen, wir arbeiten bereits an der Unterstützung durch LiveConfig.


    PHP-Pakete in den Versionen 7.0, 7.1 und 7.2 sind für Debian 11 derzeit nicht geplant. PHP 5.6 (inklusive Security-Backports) wird nur deshalb bereitgestellt, weil es einige Steinzeit-Anwendungen gibt die das zwingend benötigen. Da ist es immer noch besser, ein altes PHP 5.6 auf einer neuen Distribution zu nutzen, als ein PHP 5.6 auf einem hoffnungslos veralteten Server. ;)


    Viele Grüße


    -Klaus Keppler

  • Änderungen an Reseller-Berechtigungen

    Hallo,


    wir planen eine auf den ersten Blick kleine, aber für uns ziemlich wichtige Änderung am Berechtigungssystem für Wiederverkäufer.


    Das "Problem" ist die bisherige Flexibilität, dass Wiederverkäufer ihre eigenen Angebote völlig frei definieren können, während LiveConfig erst beim Erstellen eines Hostingvertrags prüft, ob dieses Angebot mit den Ressourcen und Berechtigungen eines Resellervertrags überhaupt realisiert werden kann.


    Diese Flexibilität (Angebote komplett "frei" anzulegen) stellt sich inzwischen als problematisch heraus: Benutzer verwirrt das (man kann im Angebot mehr erlauben als im eigenen Resellervertrag enthalten ist, beim Anlegen eines Vertrags gibt's dann einen Fehler). Im Backend ist die Berechtigungsprüfung ohnehin äußerst komplex, spätestens wenn der Resellervertrag oder das ihm zugrunde liegende Reseller-Angebot bearbeitet wird.


    Lange Rede, kurzer Sinn - wir planen folgende Änderung: wenn ein Wiederverkäufer ein Angebot erstellt, dann muss er da bereits festlegen, mit welchem (ihm zugewiesenem) Resellervertrag daraus dann Verträge erstellt werden.
    Mit anderen Worten: bei Wiederverkäufern (und nur da!) werden Angebote mit jeweils einem Resellervertrag verknüpft. In der Praxis dürfte das relativ wenige Anwender betreffen.


    Die Umsetzung wird nicht kurzfristig erfolgen, und wir werden Konflikte natürlich automatisch lösen (bestehende Angebote die mit mehreren Resellerverträgen genutzt werden, werden dann eben entsprechend dupliziert).


    Die Alternative wäre gewesen, nur einen Resellervertrag pro Kunde zu erlauben - diese Einschränkung wäre wesentlich härter.


    Fragen/Anregungen gerne hier im Forum.


    Viele Grüße


    -Klaus Keppler

  • How to remove A or AAAA Dynamic DNS record?

    Zitat von lebenszeit

    I'd expect that submitting only one would delete the other one.


    Unfortunately there's no "official" protocol specification for dynamic DNS. But your're both right, it should be possible to remove A or AAAA records with a simple update command.


    That's no big thing, we'll add this with the next update and also care for documentation.


    Best regards


    -Klaus Keppler

  • CentOS 8 Stream

    Kurzer Zwischenstand: wir haben bereits eine Centos8-Stream-Testumgebung eingerichtet, auf der wir LC bereits manuell testen.
    Als Nächstes kommen noch die automatisierten Release-Tests dran, dann wird Stream offiziell unterstützt.
    Von unserer Seite steht also prinzipiell nichts mehr im Weg.

  • Webhosting-Vertrag

    Nein, aktuell kann da lediglich zwischen Webspace- und Wiederverkäufer-Vertrag ausgewählt werden.


    Reine FTP- oder DNS-Accounts stehen bereits auf der Wunschliste. ;)


    Viele Grüße


    -Klaus Keppler

  • Postfächer löschen

    Eine Möglickeit wäre, die Domain zu löschen und anschließend wieder hinzuzufügen (dann müssten nur die Webspace-Einstellungen manuell wiederhergestellt werden).
    Wenn eine Domain gelöscht wird, mit der noch Postfächer existieren, können diese optional alle mit gelöscht oder geparkt werden.

  • PHP 7.4.19 und 8.0.6

    Hallo,


    wir haben eben unsere PHP-Pakete für Debian/Ubuntu 7.4.19 und 8.0.6 aktualisiert.


    Mit Version 7.4.16 und 8.0.3 wurde ja in unseren PHP-Paketen der Pfad für Runtime-Daten (u.a. PID-File, FPM-Sockets) von /var/run/ auf /run/ geändert (ansonsten beschwert sich systemd über die angeblich veraltete Verzeichnisstruktur).


    Wie sich gezeigt hat führte das aber in sehr seltenen Fällen zu einem kniffligen Problem: wenn es FPM-Instanzen gab, die ihre Sockets noch unter /var/run/phpXY-fpm/<Vertrag>.sock abgelegt hatten, dann im LiveConfig deren Pool-Konfiguration aktualisiert wurde (mit /run/phpXY-fpm/<Vertrag>.sock) und der FPM-Daemon reloaded wurde (also reload, kein restart), dann hatte PHP versucht die "alten" Sockets der noch laufenden Instanz wiederzuverwenden, gleichzeitig wollte es aber unter dem "neuen" Dateinamen ebenfalls Sockets öffnen, und dann hat's gekracht (/var/run/ ist ja nur ein Symlink auf /run/, und PHP erkennt nicht dass die bereits vorhandenen Sockets zum selben "Ziel" gehören).


    In der Praxis führte das dann dazu, dass PHP-FPM nach einer beliebigen Änderung in einem Webspace-Vertrag abgestürzt ist und manuell neu gestartet werden musste. In /var/log/phpXY-fpm.log fand sich dann eine Fehlermeldung der Form Another FPM instance seems to already listen on /run/phpXY-fpm/<Vertrag>.sock.


    Mit dem Update werden bestehende Pool-Konfigurationen die noch auf /var/run/... verweisen auf /run/... aktualisiert.
    Alternativ genügt es auch, die globalen php.ini-Einstellungen im LiveConfig zu bearbeiten (dadurch werden alle php.ini-Dateien aktualisiert, was zum selben Ergebnis führt).


    Viele Grüße


    -Klaus Keppler

  • Nach Host-Machine Neustart, alle VPS Server melden "Ihre LiveConfig-Lizenz ist abgel"

    Zitat von isphttp.de

    naja, dass jetzt an der LC Version ding fest zu machen, ist etwas zu einfach oder? Ich sehe das schon als Support Verweigerung. Weil normal ist es nicht, dass LC, wenn der Server neu gestartet wurde, einfach in den DEMO Modus wechselt.


    Darf ich Ihnen meine vollständige Antwort hier noch einmal posten, die ich Ihnen bereits gestern Abend unmittelbar auf Ihr Support-Ticket gesendet habe?
    Die enthielt zwei Links mit ausführlichen Beschreibungen zum Hintergrund, sowie konkreten Befehlen zur Ausführung, wie Sie LiveConfig aktualisieren können.


    Wenn Ihr Administrator Ihre Server nicht aktualisiert, ist das Support-Verweigerung von uns?

  • Bug: SSL-Zertifikate und zusätzliche Benutzer

    Hmm, ich habe das eben getestet und kann das (noch) nicht reproduzieren.


    Um was für einen Account/Vertrag handelt es sich bei dem Hauptbenutzer? Ist das direkt der "admin"-Account, oder ein Kunde?
    Wenn Kunde, ist da ein Reseller dazwischen oder ein direkter Webspace-Kunde?
    Hat der zugewiesene Vertrag die Eigenschaft "SSL-Verwaltung" aktiviert?


    Viele Grüße


    -Klaus Keppler

  • php 7.4 xmlrpc

    Schwierig.


    In "unserem" PHP-7.3 ist XMLRPC enthalten. XMLRPC wurde/wird aber seit einiger Zeit nur stiefmütterlich gepflegt, ohne separate Patches war das schon mit PHP 7.3 nicht mehr zum Laufen zu bekommen. Für PHP 7.4 haben wir das aufgrund mangelnder Nachfrage bislang noch nicht angepasst. In PHP 8 ist XMLRPC übrigens aus PHP rausgeflogen und steht nur noch via PECL (also als "externe" Erweiterung) zur Verfügung.


    Schnellste Lösung wäre also PHP 7.3 (statt 7.4) zu nutzen, oder das aus PECL für PHP 8 zu compilieren.


    Wir können uns das für PHP 7.4 gerne mal anschauen - da hierfür aber ein Patch geschrieben/angepasst werden muss wird das sicher 1-2 Tage dauern bis wir ein angepasstes Paket bereitstellen können.


    Viele Grüße


    -Klaus Keppler