Beiträge von kk

Kommt auf die PHP-Version drauf an.

Wenn es PHP-Pakete von LiveConfig sind (php-x.x-opt): https://www.liveconfig.com/de/…ncube-loader-installieren

Wenn es system-eigene PHP-Pakete sind (php-cgi/php-fpm): der Herstelleranleitung folgen.

Während der Entwicklung pflegen wir nur die deutschen Übersetzungen. Derzeit gibt es noch häufig Änderungen an den Phrasen - es macht erst Sinn die Übersetzungen zu erstellen, wenn die meisten Sätze/Begriffe "fix" sind. Mit Arabisch haben wir die RTL-Darstellung getestet (right to left).

Ich schätze, dass die Übersetzungen etwa Mitte März dran sind.

Wir haben die Informationsseite zu LiveConfig 3 eben aktualisiert.

Für alle Interessenten wohl am wichtigsten: die Seite enthält nun eine Liste aller noch offenen Punkte. Wie zu sehen ist, betrifft das zum größten Teil noch die GUI (d.h. die meiste Funktionalität ist bereits implementiert und über die API verfügbar).

In den nächsten zwei Wochen werden wir ein Installations-Repository und einen Bugtracker einrichten, um erste Beta-Tests zu ermöglichen. Details dazu und Infos wie man daran teilnehmen kann werden wir ebenfalls im Forum veröffentlichen, sobald alles vorbereitet ist.

Wir haben hier jeden Dienstag eine Besprechungsrunde, in deren Rahmen auch die "ToDo-Liste" jeweils aktualisiert wird. Wir möchten damit den Entwicklungsfortschritt transparenter machen.

Zudem wurde auch die Online-Demo (admin/admin) aktualisiert, hier kann sich jeder einen aktuellen Eindruck verschaffen.

Viele Grüße

-Klaus Keppler

Hallo,

wir wurden darauf aufmerksam gemacht, dass LiveConfig bis einschließlich Version 2.5.1 eine kritische Sicherheitslücke enthielt. Der Fehler wurde mit Version 2.5.2 (28.11.2017) behoben.

Details zu dem Fehler werden in Kürze veröffentlicht. In Anbetracht der Tatsache, dass dieser Fehler seit über sechs Jahren behoben ist, sollte das also die meisten LiveConfig-Kunden nicht betreffen.

Allerdings wurden wir auch darüber informiert, dass tatsächlich noch einzelne Server im Internet per Scan gefunden wurden, die entsprechend (stark) veraltet sind.

Wer also (warum auch immer) noch so alte Systeme am Laufen hat, möge bitte kurz mal die Version prüfen und ein Update ausführen. Wenn ein Update auf die aktuellste Version (2.16.2) nicht möglich sein sollte (z.B. wenn die Distribution nicht mehr unterstützt wird), wenden Sie sich bitte an support@liveconfig.com.

Viele Grüße

-Klaus Keppler

LiveConfig3 enthält eine vollständig neue GUI, daher können die bisherigen CSS-Templates nicht weiter verwendet werden. Das Logo ist aber weiterhin über die GUI änderbar (wie bisher).

Die Idee mit den CSS-Overrides möchten wir aber prizipiell beibehalten, mit dem neuen Framework sollte das dank CSS-Variablen sogar einfacher werden. Mittelfristig können wir uns auch vorstellen, das Farbschema ebenfalls über die GUI anpassbar zu machen.

Das CSS-Customizing steht ehrlich gesagt aber nicht ganz oben in der Prioritätenliste (mehr dazu am Montag). Wenn Sie spezielle Wünsche zur Anpassbarkeit haben, lassen SIe es uns bitte wissen.

In LiveConfig 2.x ist die DNSSEC-Implementierung leider sehr stark auf RSA fokussiert, für LC3 haben wir quasi den kompletten Code dazu neu entwickelt.

Ob ein Backporting anderer Algorithmen von LC3 auf LC2 möglich ist, müssen wir prüfen - einfach wird das aber sicher nicht.

Zu LC3 wird es am kommenden Montag (15.01.) weitere Informationen geben (wir stecken aktuell mitten in der Release-Planung).

Bei PHP-FPM gibt es technisch bedingt keine Lösung um den Ioncube-Loader nur selektiv zu aktivieren. In diesem Fall lädt nämlich der PHP-FPM-Pool-Prozess die Ioncube-Erweiterung, beim eigentlichen PHP-Zugriff wird dieser Prozess dann nur geforked und anschließend mit Benutzer-Berechtogungen und -Einstellungen ausgeführt. Zu diesem Zeitpunkt ist Ioncube aber bereits geladen (und ein Nachladen erst nach dem fork() ist nicht möglich).

Eine Idee wäre, mit der php.ini-Option ioncube.loader.encoded_paths zu experimentieren. Laut Anleitung legt diese fest, in welchen Verzeichnissen Ioncube aktiv werden soll. Sie könnten diese Einstellung global auf einen quasi ungültigen Wert (z.B. disabled) setzen, und nur bei den Kunden die Ioncube benötigen auf %HOME%/

Die andere Möglichkeit wäre, auf PHP-FPM zu verzichten und FastCGI zu nutzen. Da wird ja pro Benutzer (Vertrag) eine eigene PHP-Instanz gestartet, somit können Extensions individuell aktiviert/deaktiviert werden. Konkret könnte das so aussehen, dass Webhosting-Verträge ohne Ioncube-Loader weiterhin mit PHP-FPM genutzt werden können, während Accounts die Ioncube benötigen dann mit FastCGI laufen müssen.

So oder so müssten Sie in z.B. /opt/php-8.2/etc/conf.d/ioncube.ini die zend_extension=...-Anweisung auskommentieren, und in der php.ini-Verwaltung in LiveConfig (für jede verfügbare PHP-Version) einen entsprechenden php.ini-Eintrag hinzufügen:

(oder die Option "Änderbar" nur auf "pro Vertrag" setzen, dann kann das nicht der Kunde selbst ändern sondern nur noch der jeweilige Admin)

Ich hoffe, dass Ihnen das hilft.

Viele Grüße

-Klaus Keppler

Hallo,

ab sofort steht LiveConfig 2.16.2 zum Download bereit.

Ja, zwei Tage vor Weihnachten sollte man keine Updates ausrollen - aber der Grund ist leider ernst: mit genauso wenig Begeisterung hat der Entwickler von Postfix - Wietse Venema - auf ein äußerst kurzfristig öffentlich gemachtes Sicherheitsproblem in Postfix hingewiesen: SMTP Smuggling.

Dieses LiveConfig-Update macht nichts anderes, als den in dem verlinkten Beitrag empfohlenen Workaround anzuwenden (die Anweisung "smtpd_data_restrictions = reject_unauth_pipelining" wird in die main.cf mit aufgenommen)

Während des Upgrades erfolgt das automatisch durch LiveConfig, es ist also kein manuelles Aktualisieren der Konfiguration erforderlich.

Weitere Informationen:

• Hinweis des BSI: https://www.bsi.bund.de/Shared…_blob=publicationFile&v=3
• Stellungnahme und Details der entdeckenden Sicherheitsforscher: https://sec-consult.com/blog/d…oofing-e-mails-worldwide/
  (ja, möglicherweise möchte man keine Cisco-Produkte einsetzen

Viele Grüße

-Klaus Keppler

Was liefert der Befehl "dpkg -l | grep -i mariadb" ?

Hallo!

Ab sofort steht LiveConfig v2.16.1 zum Download bereit. Die wichtigsten Änderungen sind:

• Erkennung von MariaDB-Paketen wurde verbessert
• Erkennung des "postfix3"-Paketes (nicht-Standard!) unter CentOS
• unter Debian 12 kann nun auch das vollständig systemd-journald-basierte Log geparsed werden (damit zählt LiveConfig die ein- und ausgehenden E-Mails)

Außerdem wurden neben einigen kleineren Fehlern auch mögliche Problem beim Upgrade des Datenbank-Schemas von (sehr) alten LiveConfig-Installationen behoben.

Die vollständige Liste aller Änderungen findet sich wie immer im Changelog.

Die Änderungen am Schema der LiveConfig-Datenbank sind weitgehend abgeschlossen, so dass eine reibungslose Umstellung auf LiveConfig 3 (und auch zurück) möglich sein wird.

Das Update sollte - wie immer - reibungslos über den jeweiligen Paketmanager möglich sein.

Falls der Repository-Key abgelaufen ist, am besten das Paket liveconfig-keyring installieren (siehe Hinweise).

(ab März 2024 werden alle Pakete und Repositories mit dem neuen Key signiert, der in liveconfig-keyring bereits enthalten ist)

Viele Grüße

-Klaus Keppler

PHP 8.3.0 inklusive der üblichen Extensions (inkl. apcu/memcached/redis/igbinary/imagick) steht ab sofort in unseren Repositories zum Download bereit.

Hallo,

bei unseren automatisierten Tests kommt es mit PHP 8.1.25 und 8.2.12 immer wieder mal zu "Segmentation Faults", wenn der Ioncube Loader (13.0.2) und Opcache aktiv sind.

Reproduzieren lässt sich das z.B. mit folgendem Befehl:

echo '<?php echo php_ini_loaded_file(); ?>' | /opt/php-8.2/bin/php-cgi -q

Sollte es also zu Segmentation Faults bei PHP kommen, prüfen Sie ob Ioncube und Opcache aktiviert sind, und deaktivieren Sie ggf. eines der beiden Module.

Viele Grüße

-Klaus Keppler

Auf die Gefahr hin dass ich mich wiederhole: das ist kein Fehler in LiveConfig, sondern eine "Unschönheit" in MariaDB, dass /usr/bin/mysql inzwischen diese Warnmeldung ausgibt.

Wir testen LiveConfig ausschließlich mit den bei der jeweiligen unterstützten Distribution mitgelieferten Datenbanksystemen durch. Wer eine Software aus einer anderen Quelle installieren mag, muss das (schon immer) auf "eigenes Risiko" machen. Hier einen Workaround einzurichten (z.B. Anpassen des Dateinamens o.ä.) sollte einen Admin vor keine unlösbare Aufgabe stellen.

Wir werden die Prüfung auf /usr/bin/mariadb aber berücksichtigen, da früher oder später dieses Verhalten ja auch in die "normalen" Distributions-Versionen einfließen dürfte.

Hallo,

voraussichtlich am 23. November 2023 wird PHP 8.3 erscheinen.

Seit einiger Zeit stellen wir ja schon die Release-Candidate-Builds für PHP 8.3 bereit. Diese wurden nun nochmal aktualisiert (PHP 8.3 RC6 - der "finale" Release Candidate). Zudem werden aktuell auch die "üblichen" Extensions paketiert und bereitgestellt - allen voran ImageMagick (php-8.3-opt-imagick). Die restlichen Extensions (apcu, igbinary, memcached, redis) folgen noch diese Woche.

Viele Grüße

-Klaus Keppler

Mit Version 3.0 wird es da eine Änderung geben. Die "kleinste" Lizenz wird Let's Encrypt (bzw. alle ACME-kompatiblen Anbieter) unterstützen, aber muss leider auch ein klein wenig teurer werden. Die günstigste Lizenz macht nunmal den größten Supportaufwand.

Details folgen wenn's soweit ist.

Nein, da gab es keine Änderungen.

Sie meinen schon die unter "Verwaltung" -> "LiveConfig" -> "Eigene Links" verwalteten Seiten?

Auf der LiveConfig-Demo (admin/admin) ist eine Demo eingerichtet. Möglicherweise klappt etwas mit der Authentifizierung (seitens des aufgerufenen PHP-Scripts) nicht? Dieses muss ja eine Art "Callback" an LiveConfg machen, um zu prüfen, ob und welcher Benutzer angemeldet ist.

Ansonsten schicken Sie uns am besten mal (temporäre) Zugangsdaten an support@liveconfig.com, dann schauen wir das gerne mal kurz an.

Ich drücke mich mal vorsichtig aus: Händler sehen Paypal durchaus auch zwiegespalten.

(Sicherheitseinbehalt, Sperrungen, Erreichbarkeit, ...)

Wir planen das längerfristig wieder anzubieten, dazu müssen aber erst ein paar andere Rahmenbedingungen stimmen. Zusätzlich ist die Zahlung per Kreditkarte in Vorbereitung (nicht über Paypal).

Wenn Sie in der LC3-Demo als "admin" angemeldet sind, gehen Sie einfach auf "Verwaltung" -> "Kunden" und klicken in der Tabelle ganz recht auf das "..."-Icon. Dort dann den Punkt "als Benutzer [...] anmelden" anklicken. Und schon sind Sie als entsprechender Endnutzer angemeldet.

Es gbt unter "Serververwaltung" -> "E-Mail" jeweils bei den Postfix- und Dovecot-Einstellungen eine Checkbox "[X] nur verschlüsselte Benutzeranmeldung erlauben".

Damit können Sie optional auch unverschlüsselte Anmeldungen erlauben.

Ich gebe mal einen ganz kleinen Einblick in die Komplexität scheinbar trivialer Funktionen.

So sieht die Maske zur Bearbeitung der Domaineinstellungen künftig aus:

Herausziehen möchte ich hier mal nur den Punkt "TLS/SSL-Zertifikat".

• Wenn bereits ein oder mehrere passende Zertifikate im System vorhanden sind, die diesem Kunden oder dem bearbeitendem Admin gehören, dann würden diese hier mit zur Auswahl angezeigt. "Passend" heißt dabei, dass auch Wildcard-Zertifikate mit berücksichtigt werden, wobei darauf geachtet werden muss, ob die bearbeitete (Sub)-Domain durch Wildcards korrekt umfasst würde (z.B. gilt "*.example.org" nicht für die Domain "example.org").
• Die Option "neues Zertifikat" (wie im Screenshot zu sehen) taucht nur dann auf:
  • wenn mindestens ein Anbieter-Account für automatisierte, kostenfreie TLS-Zertifikate vorhanden ist (z.B. Let's Encrypt, können aber auch andere Anbieter sein). Dabei wird geprüft, ob für den aktuellen Kunden ein eigener Account hinterlegt ist, wenn nicht dann rekursiv aufsteigend für die Reseller nach oben.
  • und wenn kein Zertifikat vorhanden ist, das vom selben automatisierten Anbieter kommen würde (um Doppelbestellungen zu vermeiden) und automatisiert verlängert werden würde. Somit soll es möglich sein, ggf. auf einen anderen automatisierten Anbieter zu wechseln.
  • falls mehrere Anbieter verfügbar sind, gibt es hier eine Auswahl-Box. Der Default-Wert hierfür ist für den Admin einstellbar.
• Wird ein automatisiertes Zertifikat "weggewechselt" (also nicht mehr aktiv genutzt), dann bleibt dieses zwar noch im System vorhanden, wird aber nicht mehr verlängert (außer es wird wieder aktiviert). Abgelaufene Zertifikate (die also nicht verlängert wurden) und nicht mehr in Verwendung sind, werden automatisch gelöscht.
• Jetzt gibt's kostenfreie TLS-Produkte, die keine Wildcard-Zertifikate erlauben, die keine SAN-Zertifikate erlauben, und sogar welche, die nicht einmal die "www"-Subdomain als SAN erlauben. Wenn nun die Option mit "auch auf www-Subdomain anwenden" aktiviert ist, dann muss bei so einem TLS-Produkt ein komplett separater Bestellprozess losgetreten und verwaltet werden.
  Ohnehin fordert die "www-Subdomain"-Option eine ganze Menge Prüfungen (Was wenn nachträglich "www" deaktiviert wird? Oder auf eine andere IP-Adresse geändert wird? Oder umgekehrt: ein TLS-Zertifikat wurde bestellt, und später soll die www-Subdomain da mit dazu kommen...)
• Die Bestellung von TLS-Zertifikaten ist ein komplett asynchroner Prozess. In der Praxis läuft das zwar meistens binnen weniger Sekunden ab, aber wir hatten schon häufig den Fall, dass Bestellungen aufgrund verschiedenster Ursachen mal mehrere Stunden oder Tage brauchen.
  Die Herausforderung ist nun: wie visualisiert oder verwaltet man es, dass ein Kunde zwar ein (z.B.) Let's-Encrypt-Zertifikat bestellt hat, vielleicht aber noch ein anderes oder auch gar kein Zertifikat aktiv ist? Sobald das Zertifikat eintrifft soll es automatisch übernommen werden, bis dahin soll aber alles möglichst noch so wie bisher laufen.
• Ein Webhoster verdient an kostenfreien Zertifikaten nichts, daher darf es an dieser Stelle weder einen direkten Aufwand geben, noch darf es zu indirektem Aufwand aufgrund von Kundennachfragen kommen.
• Die Domainvalidierung (DV) muss schließlich auch zuverlässig durchgeführt und für eventuelle Fehlerfälle verständlich nachvollziehbar protokolliert werden (häufigste Ursache: Probleme bei authoritativen Nameservern, von Kunden übermütig gesetzte CAA-Records, etc. - also außerhalb des Einflußbereichs von LiveConfig).
• Last but not least muss ja noch irgendwo ausgewählt werden, was für Schlüssel für die Zertifikate verwendet werden sollen (RSA oder EC). Auch das kann je nach TLS-Produkt variieren (manche Anbieter erlauben z.B. keine EC-Schlüssel in deren kostenfreien Produkten). Der Endkunde soll damit nicht "belästigt" werden (daher gibt es hier keine Key-Auswahl).

Einige weitere Aspekte habe ich bestimmt noch vergessen - aber das zeigt hoffentlich schon, wie komplex die Logik hinter einer einzigen Checkbox sein kann. Und LiveConfig hat viele Checkboxen.