Beiträge von kk

Danke für die Vorschläge. Wir haben den "löschen"-Button nun so verlegt, dass dieser nur noch im ersten Tab ("Postfach") auftaucht. Sollten in dem Postfach auch Mails liegen, dann erscheint im Rückfrage-Dialog eine zusätzliche Zeile: "Alle in diesem Postfach enthaltenen E-Mails werden unwiderruflich gelöscht.". In anderen Tabs ist das Löschen des Postfachs somit auch nicht mehr möglich:

forum.liveconfig.com/cms/attachment/19/

Eine Eingabe der kompletten Mailadresse zur Bestätigung ist bei einzelnen Kunden sicherlich sinnvoll, andere Kunden treibt das aber garantiert in den Wahnsinn. Wir denken da eher an eine zusätzliche Checkbox, die zum Löschen von Postfächern angeklickt werden muss (was Profi-Anwender auch auf Dauer irgendwie abschalten können sollten).
Ein zeitversetztes Löschen geht in die Richtung "Papierkorb" (steht bereits auf der Ideenliste). Wir überarbeiten die gesamte GUI derzeit (weitere Infos dazu spätestens Anfang Oktober), da können wir sicher noch die eine oder andere Anregung aufnehmen.

Die oben gezeigte Änderung ist in LiveConfig 2.12.3 enthalten (ab sofort als Preview online, Stable-Release Anfang kommender Woche).

Viele Grüße & ein schönes Wochenende

-Klaus Keppler

Ich verstehe das nicht. Der Kunde wünscht einen Spam-Ordner, um darin ausdrücklich nach versehentlich als Spam markierten Mails zu suchen, damit ihm keine wichtigen Mails entgehen?

Es landen doch alle E-Mails im Posteingang. Ein "Spam-Ordner" macht es somit unübersichtlicher und sorgt dafür, dass wichtige E-Mails eher noch später gefunden werden.

Genau hier erkennt man doch eigentlich, wie unsinnig ein "Spam-Ordner" ist. Die Arbeit gehört vielmehr in ein sinnvolles Tuning des Spamfilters investiert, so dass es möglichst wenige "verdächtige" E-Mails gibt.

Für Unbelehrbare werden wir etwas auf Basis von ManageSieve vorbereiten - werden das aber ausdrücklich nicht empfehlen.

Hallo,

ab sofort steht PHP 8.1 (beta-3) in unseren Debian/Ubuntu-Repositories zur Installation bereit.
Und auch für CentOS steht mit lc-php81-remi ein Installationspaket bereit.

Viele Grüße

-Klaus Keppler

Support für Rocky ist in Vorbereitung. Prinzipiell sollte LiveConfig bereits damit funktionieren, wir haben aber noch keine automatisierte Testumgebung dafür eingerichtet.

Ist in dem betroffenen Vertrag PHP aktiviert? (mit Site.pro erstellte Websites benötigen PHP - wir werden da noch eine Plausibilitätsprüfung mit einbauen)

Ansonsten machen Sie bitte mal testweise:
- Domain auf "Webspace" einstellen, irgendein Zielverzeichnis wählen (völlig egal) und PHP auf die Standardversion stellen, speichern.
- dann Domain erneut bearbeiten, auf Webbaukasten zurückstellen, speichern

Dann nach ca. 60 Sekunden erneut die Website aufrufen.

Viele Grüße

-Klaus Keppler

Hallo,

LiveConfig wird ab Version 2.12.0 die Linux-Distributionen Debian 11 ("Bullseye") und CentOS Stream 8 unterstützen.

Die aktuelle Preview (2.12.0-dev20210709.1) haben wir bereits erfolgreich auf beiden Plattformen durchgetestet. Es stehen lediglich noch kleinere Aufräumarbeiten bei einzelnen Konfigurationsdateien an.

Viele Grüße

-Klaus Keppler

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.

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.

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"?

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?

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

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

Die Anleitung zum Betrieb von LiveConfig hinter einem Proxy finden Sie unter https://www.liveconfig.com/de/kb/liveconfig-hinter-proxy/

Nutzen Sie Apache oder NGINX als Web-Proxy? Je nachdem muss ein anderer Wert für "http_proxy_ip_header" eingetragen werden.

Viele Grüße

-Klaus Keppler

Ab Version 2.12 (aktuelle Preview). Ist in Kürze auch "stable".

Viele Grüße

-Klaus Keppler

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

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.

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

Berichte -> Server.

Viele Grüße

-Klaus Keppler

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.

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