Beiträge von kk

Zitat von pkambach

ich habe hier zumindest auch Probleme bei mehreren Kunden - In der Zertifikatskette in Chrome z.B. steht das abgelaufene Root-Zertifikat drin (welche Version und OS es ist, weiß ich noch nicht).

Soweit ich das sehe stimmt die Zertifikatskette. Ohne die Info welches OS das ist kann man leider nichts sagen.
Falls es sich um ein Windows XP (vor SP3) oder gar etwas Älteres handelt, wird das nicht erkannt.
https://letsencrypt.org/docs/certificate-compatibility/

Workaround: das ISRG X1 Root manuell auf dem betroffenen Rechner installieren.
Saubere Lösung: betroffenen Rechner grundsätzlich aktualisieren.
(wenn der tatsächlich sooo alt ist dass er die Zertifikatskette nicht akzeptiert, dann ist SSL das geringste Problem...)

Viele Grüße

-Klaus Keppler

Zitat von pitgrap

Sollte das nicht automatisch passieren, wenn man die ACMEv2 API benutzt? Ist bei liveconfig noch die alte v1 API im Einsatz?

Nein, LiveConfig nutzt schon ziemlich lange die v2-API. (ich glaube seit v2.8)

siehe https://www.liveconfig.com/de/…gezeigt?p=19244#post19244

Wir suchen nun nach der genauen Ursache, ich vermute dass LiveConfig noch das "alte" Intermediate-Zertifikat im Cache hat und dieser Pfad nun "expired" ist.

Ja, können wir bestätigen (betrifft die Übersicht der SSL-Zertifikate, da ist jeweils das Symbol "Zertifikat ist abgelaufen").

Eventuell prüft LiveConfig intern die Zertifikatsgültigkeit noch über einen alten Validierungspfad. Wir kümmern uns darum, Update wird kurzfristig bereitgestellt.
Die Zertifikate sind dennoch gültig, der Fehler betrifft nur die Anzeige innerhalb der Übersicht in LiveConfig.

Viele Grüße

-Klaus Keppler

Guten Morgen,

vor rund zwei Wochen wurde eine Sicherheitslücke im Apache-Webserver bekannt: CVE-2021-40438. Mit einem CVSS-Score von 9.8 (!) ist dieser Bug als kritisch eingestuft.

Für Ubuntu gab es vor wenigen Tagen bereits die ersten Updates, welche allerdings dazu führten dass PHP-FPM in manchen Konfigurationen nicht mehr funktionierte (Ubuntu Bug #1945311). Nachdem Ubuntu nun die Patches von Debian nachgezogen hat, scheint wieder soweit alles zu funktionieren (auf unseren Ubuntu 16/18/20 Testservern können wir aktuell keine Probleme feststellen).

Für Debian stehen die entsprechenden Updates derzeit noch aus, dürften aber in Kürze auch freigegeben werden (siehe Debian Security-Tracker). Nach dem aktuellen Stand gehen wir davon aus, dass es mit den Debian-Updates (anders als bei Ubuntu) keine Probleme geben sollte. Wir empfehlen aber, eventuelle Updates erst mal nur auf einem Server auszurollen und dort PHP-FPM anschließend zu testen.

Sobald wir weitere Infos haben, werden wir diese hier bekanntgeben.

Viele Grüße

-Klaus Keppler

Zitat von ñull

Wie verhindern wir, dass es dabei zu Problemen kommt?

Nach unserem aktuellen Kenntnisstand gibt es keinen Handlungsbedarf.

Seit 04. Mai 2021 stellt Let's Encrypt die Zertifikate standardmäßig so aus, dass in der CA-Chain auch das Zwischenzertifikat "DST Root CA X3" enthalten ist (siehe Ankündigung). Man kann das z.B. mit unserem SSL-Check prüfen - etwa für demo.liveconfig.com.

Somit sollen auch ältere Android-Geräte keine Sicherheitswarnung anzeigen.

Es besteht also kein Grund, Zertifikate neu auszustellen.

Ja, ruhig war es hier nicht wirklich. Rund 2.000 Commits alleine in LC3 und die Kernbibliothek. Sobald es was "zu sehen" gibt, werden wir gerne ein Webcast o.ä. veranstalten und ein bisserl aus dem Nähkästchen plaudern.

Hallo zusammen,

heute möchten wir einen kleinen Einblick und Ausblick auf die LiveConfig-Entwicklung geben.

Der "Kern" von LiveConfig ist inzwischen rund zehn Jahr alt. Die Architektur insgesamt hat sich bislang sehr gut bewährt - aber sie stößt in manchen Bereichen an ihre Grenzen. Insbesondere die Integration externer Dienste (Backup, Policy-Daemon, etc.) oder der Dateiaustausch mit Multi-Server-Systemen läuft nicht so wie wir es uns wünschen.

So haben wir die letzten 18 Monate (war da sonst noch was? ;)) genutzt, um den technischen Unterbau komplett auszutauschen und mit modernsten Mitteln neu aufzusetzen. Es gibt nun eine neue "Kernbibliothek", welche die Grundlage für alle LiveConfig-Tools darstellt und eine noch nie dagewesene Integration ermöglicht. Einzelne Komponenten dieser Bibliothek sind jetzt schon in LiveConfig enthalten, der größte Teil kommt aber erst mit dem nächsten Release zum Einsatz.

Dieses nächste Release - LiveConfig 3 - ist aktuell in Arbeit. Neben dem neuen Backend gibt es mit dieser Version eine neue, modernere Oberläche sowie viele Features, die bislang technisch nicht möglich waren. Die kritischsten Komponenten (die Lua-Scripte zur Systemverwaltung sowie das komplette Datenbankmodell) bleiben unverändert erhalten, um einen zuverlässigen Übergang zu ermöglichen.

Heute in zwei Wochen starten wir in die (geschlossene) Alpha-Phase, am 31.01.2022 startet die Beta-Phase.

Während der Alpha-Phase "verpasst" niemand etwas, wir führen diese bewusst geschlossen durch um möglichst viele Ressourcen in die Entwicklung stecken zu können. Während der Beta-Phase hat dann jeder die Möglichkeit, LiveConfig 3 ausführlich zu testen und Feedback zu geben.

Aktuell liegen wir sehr gut im Zeitplan, und die neuen Features machen richtig Spaß. Am liebsten würden wir LC3 jetzt schon zeigen, aber eine dreistellige Anzahl an offenen ToDo-Punkten muss erst noch abgearbeitet werden. Wir werden hier im Forum regelmäßig über den Entwicklungsfortschritt berichten, den Kreis der Alpha-Teilnehmer stückweise erweitern und so möglichst transparent und pünktlich das neue Release veröffentlichen.

Weitere Details zum genauen Funktionsumfang und den wichtigsten neuen Features werden wir mit dem Start der Beta-Phase veröffentlichen. Vielen Dank schonmal für das Verständnis!

Viele Grüße

-Klaus Keppler

PS: das "aktuelle" LiveConfig 2.x wird selbstverständlich auch weiter entwickelt. Da wir Komponenten-orientiert arbeiten ist das kein doppelter Aufwand. Manche "große" Features sind aber erst mit dem neuen Backend möglich.

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