Beiträge von kk

Zitat von mjk

Wir haben eben einen neuen Server installiert, wie gewohnt mit dem Installer-Script was wir eigentlich immer für LiveConfig 2 verwenden:

Code

wget -O- https://install.liveconfig.com | sh

Auf dem Server befindet sich jetzt allerdings LiveConfig 3.

Dann muss da noch mal irgendetwas anderes passiert sein. LiveConfig 2.x und 3.x sind separate Pakete mit unterschiedlichen Namen; das o.g. Script kann nur LiveConfig 2.x installieren.
Auf welcher Distribution (&-Version) haben Sie das ausgeführt? Dann testen wir das gerne mal durch.

Zitat von Nobbi

Durch die fehlerhafte dnssec-policy wurden offenbar neue KSKs erzeugt, was dazu führte, dass unsere Domain plötzlich nicht mehr auflösbar war – insbesondere bei deutschen DNS-Providern heute schon wieder, jetzt dauert es wieder mehrere Stunden bis die DNS Änderungen bei den Kunden ankommen, es ist zum Mäusemelken. Es tritt im übrigen nur bei .de domains bei mir auf die .at /.ch waren nicht betroffen das machte die Sache noch schwerer zu verstehen also musste es irgendwas mit der DENIC zu tun haben

Das tut mir sehr leid, ich verstehe Ihren Ärger. Mir einem Provider haben wir die Nacht durch durchgearbeitet, um die Ursache zu lokalisieren und zu beheben (der Chatverlauf zwischen einem Techniker dort und einem Entwickler von uns endete heute früh um 05:02).

Mit der TLD dürfte das aber nichts zu tun gehabt haben. Ich denke wir haben das inzwischen ganz gut nachvollzogen und werden eine ausführliche Beschreibung im Laufe des Tages veröffentlichen. Das Verhalten von BIND mit der dnssec-policy ist Fluch und Segen zugleich.

Aktuell entwickeln wir noch ein Tool, um die fälschlicherweise erzeugten KSKs, die in Form von DNSKEYs noch in manchen Zonen hängen, sauber zu entfernen. Die Domains sollten soweit operativ funktionieren, aber es gibt in manchen Fällen sehr viele Log-Meldungen bei BIND die nun behoben werden müssen.

Bei der DNSSEC-Migration gab es leider einen Fehler: bei DNS-Zonen, welche einen 4096-Bit RSA-Schlüssel als KSK haben, und bei denen wiederum der ZSK-Key-Tag einen kleineren Wert als der KSK-Key-Tag hat, bei denen wurde eine falsche DNSSEC-Policy in die Zonenliste geschrieben (für 2048-Bit statt 4096-Bit-KSKs). Das führte wiederum dazu, dass BIND die KSKs nicht übernommen sondern Neue erzeugt hat. :-/

(das ist leider eine seeehr hässliche Nebenwirkung der "wir-kümmern-uns-ab-sofort-um-alles"-Philosophie bei dnssec-policy.

Der Migrationsfehler wurde eben behoben, wir entwickeln eben noch ein Routine zur Korrektur aller betroffenen Domains (bei bereits migrierten Systemen), wird dann gleich in Form der v2.18.1 bereitstehen.

Zitat von bravesurfer

[EMERG] getaddrinfo() failed: Der Name oder der Dienst ist nicht bekannt

An dieser Stelle (also "so früh" beim Start) werden die lokalen Sockets für HTTP(S) und ggf. LCCP geöffnet.

Was genau steht in der /etc/liveconfig/liveconfig.conf bei http_socket, http_ssl_socket und lccp_socket?

(falls das sensible Daten sind, einfach an support@liveconfig.com schicken oder über's Kontaktformular mitteilen)

Zitat von Marco

"liveconfig --diag" erkennt ja die IP, also kann es nicht an Rechten liegen. Habt ihr irgendwo einen Filter, der das ältere eth0 nicht mag und eno1 erwartet?

[...]

Im Dump der liveconfig.db ist der Bereich bei "INTERFACES" leer. Der Befehl "CREATE" existiert, aber kein nachfolgendes "INSERT".

Nein, der Name der Interfaces spielt keine Rolle. Wenn INTERFACES leer ist, dann ist das tatsächlich kein Frontend-Problem, sondern irgendetwas im Backend. Es handelt sich hier um eine Neu-Installation, oder? (also kein Upgrade einer bestehenden Installation)

Die Erkennung der IPs und Schnittstellen läuft exakt so wie in LiveConfig 2, und das was bei --diag ausgegeben wird sollte so eigentlich auch in der Datenbank landen.

Wenn es eine "leere" Installation ist, könnten wir uns das ggf mal direkt auf dem Server (via SSH) anschauen - wenn das für Sie ok ist, melden Sie sich bitte kurz unter support@liveconfig.com, damit wir das weitere Vorgehen besprechen. Parallel prüfen wir hier mal den Code, wie diese Tabelle normalerweise gefüttert wird.

Zitat von Nolz

Also mir hat's DNSSEC komplett zerlegt 🙃

Autsch.

Können Sie das etwas näher beschreiben? Wurden die Keys von /etc/bind/keys/ nach /var/lib/bind/keys/ verschoben?

Wurde während des Upgrades etwas in /var/log/liveconfig/liveconfig.log protokolliert?

Bei einem normalen (erfolgreichen) Update sollte das etwa so aussehen:

[<timestamp>] [<pid>|<tid>] Switching to dnssec-policy configuration on server 'xyz.example.org'
[<timestamp>] [<pid>|<tid>] dnssec-policy enabled on DNS server
[<timestamp>] [<pid>|<tid>] - updated ### zones on primary DNS

Zitat von Marco

Aktuell ist LiveConfig 3 gar nicht nutzbar, da keine IP Adressen erkannt werden. Bei "Server - Web - konfigurieren" erscheint in der Auswahl nur 127.0.0.1. Aber selbst bei der Auswahl dieser IP meldet die Übersicht "Keine IP-Adressen ausgewählt."

Bitte prüfen Sie, ob in /var/log/liveconfig/liveconfig.log irgendetwas protokolliert wird, wenn Sie die Webserver-Konfiguration öffnen. Ich kann mir aktuell nur vorstellen, dass beim Abruf der IP-Adressen ein Fehler auftritt und deshalb die Liste in der GUI leer ist.

(das könnten fehlende oder falsche Berechtigungen sein, oder eine defekte Datenbankstruktur)

Ab sofort sind die Pakete liveconfig3 bzw. lcclient3 in den Repositories verfügbar.

Das Wichtigste vorab: wir verwenden bewusst separate Paketnamen (mit der "3" am Ende), damit niemand versehentlich auf LiveConfig 3.0 aktualisiert. Zu einem späteren Zeitpunkt (wenn LiveConfig 2 abgekündigt wird) werden wir das aber wieder umstellen.

Neu-Installationen mit LiveConfig 3.0 führt man am allereinfachsten mit dem nagelneuen Installationsscript durch:

wget -O- https://install.liveconfig.com/lc3 | sh

Das bisherige Paket liveconfig-meta (zur Installation der für die jeweiligen Dienste benötigten Pakete) wird eingestellt, das erfolgt nun komfortabel über das o.g. Script. Zudem kann damit auch gesteuert werden, ob man Web-, Mail-, DB- oder DNS-Pakete installieren möchte.

Das Upgrade von LiveConfig 2 auf 3 erfordert, dass man vorher (mindestens) auf LiveConfig 2.18.0 aktualisiert hat. In dem Fall genügt dann ein einfaches apt install liveconfig3

Für den Fall, dass irgendetwas gewaltig schief geht oder eine dringend benötigte Funktion fehlt, kann man genauso einfach auch wieder downgrade (apt install liveconfig).

Wer als "Early Adaptor" früh auf LiveConfig 3 aktualisiert, den möchten wir höflich bitten, unter Einstellungen -> LiveConfig die Übertragung von Crash-Reports und Serverstatistiken zu aktivieren. In den dort verlinkten Datenschutzhinweisen ist ausführlich und ehrlich beschrieben, welche (minimalen) Daten da an uns übermittelt werden.

In den nächsten Tagen stellen wir das Handbuch auf v3 um und erstellen einen ausführlichen Update-Leitfaden (sollte bis Dienstag 05.08. soweit fertig sein).

Viele Grüße

-Klaus Keppler

Wir haben eben die Version 2.18.0 veröffentlicht (die ist Voraussetzung für ein Update auf 3.0).

Die Pakete für v3.0.0 werden aktuell zusammengestellt (dauert noch ein paar Stunden) und stehen ab dem Abend bereit.

Hallo,

wir haben soeben LiveConfig 2.18.0 freigegeben.

Alle Änderungen sind wie immer im Changelog zu finden. Auf zwei besonders wichtige Themen möchten wir hier aber noch mal ausdrücklich hinweisen:

1. Wenn LiveConfig mit einem selbst-signierten TLS-Zertifikat mit einem 1024 Bit RSA-Schlüssel genutzt wurde, dann ersetzt LiveConfig 2.18 dieses beim ersten Start durch ein neues, ebenfalls selbst-signiertes Zertifikat mit 2048 Bit. Das hat den Hintergrund, dass manche Clients keine Zugriffe mehr auf Server mit 1024-Bit-Schlüsseln zulassen.
   Also nicht wundern, wenn es nach dem Update in diesen Fällen eine Warnung bezüglich eines unbekannten Zertifikats gibt.
2. Wer LiveConfig zur DNS-Verwaltung nutzt und hierbei DNSSEC aktiviert hat: die BIND-Konfiguration wird während des Updates auf ein anderes Schema umgestellt (von "auto-dnssec" auf "dnssec-policy"). Alle Details hierzu sind ausführlich in der Wissensdatenbank beschrieben: DNSSEC-Migration
   Am besten prüfen Sie in diesem Fall nach der Migration, ob das Verzeichnis /etc/bind/keys/ leer ist bzw. nur noch veraltete/manuelle Schlüssel enthält.

Sollten Fragen oder Probleme auftauchen, geben Sie uns bitte Bescheid.

Die Version 2.18 ist übrigens Mindestvoraussetzung für ein künftiges Update auf LiveConfig 3.0. Ein Update von früheren Versionen auf 3.0 wird vom Paketmanager geprüft und ggf. abgebrochen.

Viele Grüße

-Klaus Keppler

Die Version 2.18.0 wird auch morgen mit veröffentlicht (und ja, alle Änderungen darin sind in 3.0 auch schon enthalten).

Die Versionen 2.18.0 und 3.0.0 sind "datenbank-kompatibel", d.h. zwischen diesen kann bei Bedarf jederzeit umgestellt werden.

Alle Details dazu werden in einer entsprechenden Upgrade-Anleitung zusammengefasst.

Die Versionen 2.18.x und 3.x werden noch eine Zeit lang (mindestens bis Ende 2025) parallel weiter gepflegt, um einen reibungslosen Umstieg ohne Zeitdruck zu ermöglichen.

Zitat von TCRserver

Oder vielleicht reicht es ja auch aus einen Business Server als C&C zu nutzen und dann wird die Funktion auf die Standard Server vererbt.
So wie beim Let's Encrypt Feature.

Let's Encrypt wird künftig in allen Lizenzen verfügbar sein.

LAC benötigt auf jedem Server, auf dem es genutzt wird, eine Business-Lizenz.

Aber: für Bestandskunden haben wir als Dankeschön für die Geduld und die Unterstützung ein spezielles "Weihnachtsgeschenk" - mehr dazu in Kürze.

Ja, und hier fühlt sich's auch so an wie am Tag vor Weihnachten

Dann vermute ich mal, dass das in den php.ini-Einstellungen so eingetragen ist:

Das Problem ist: wenn "Änderbar" auf "Account" steht, dann wird die Einstellung bei PHP-FPM mit php_admin_value erzeugt - und die kann dann nicht durch's Script (Roundcube) geändert werden. Stellen Sie das auf "Benutzer" um, dann kann sowohl der Benutzer in seinen php.ini-Einstellungen das ändern, als auch das Script.

Von LiveConfig kommt diese Einstellung übrigens nicht, zudem ist die schon stark beschränkend (PEAR-Erweiterungen etc. werden da nicht gefunden).

Prüfen Sie bitte mal, ob in der /etc/php/8.3/fpm/pool.d/<Vertrag>.conf (bzw. /etc/php-fpm/php83-fpm.d/<Vertrag>.conf) eine include_path-Anweisung steckt.

(LiveConfig trägt standardmäßig keine ein, könnte aber evtl. in der php.ini-Verwaltung hinzugefügt worden sein)

Roundcube 1.6.7 sollte übrigens aktualisiert werden, da gibt es kritische Bugfixes.

Dieses Verhalten habe ich bislang noch nirgendwo erlebt oder davon gehört.

Wenn auf FastCGI zurückgestellt wird, tritt das nicht mehr auf?

Welche Versionen von PHP und RoundCube kommen zum Einsatz?

Exakt das ist mir in dem Vergleich auch aufgefallen: bei Litespeed ist ausdrücklich vom LSCache die Rede, bei Apache/NGINX wird aber kein Cache erwähnt.

Wenn ich die Zeit finde machen wir hier mal einen eigenen, transparenten Vergleich.

Zitat von pkambach

Guten Morgen,

gibt's für's Changelog (https://www.liveconfig.com/de/changelog/) noch irgendwas interessantes?

VG

Patrick

Alles anzeigen

Ups... da hatte ein rsync gefehlt. :-/ Wurde eben aktualisiert.

Bei der Gelegenheit: morgen im Laufe des Tages wird's ein Zwischenupdate mit kleineren Bugfixes geben.

Genau dieses "Problem" wird mit den LiveConfig Account Containern (LAC) gelöst.

Um Zugriff auf Verzeichnisse "außerhalb" des eigenen Home-Directories auf ein wirklich absolutes Minimum zu begrenzen gibt es verschiedene technische Ansätze. Der Bekannteste dürfte die "chroot"-Umgebung (chroot-Jail) sein. Die hat aber etliche Nachteile (vor allem einen gewaltigen Pflegeaufwand) und kann auch immer wieder mal umgangen werden (mal nach "chroot breakout" googeln).

Dann gibt es spezielle Patch-Sammlungen und Produkte (u.a. das "CageFS" von CloudLinux), welche i.d.R. über Kernel-Hooks für eine Isolation sorgen.

Die LiveConfig Account Container (LAC) arbeiten mit Kernelfunktionen, die inzwischen standardmäßig verfügbar sind und auch in der Container-Welt (Docker etc.) genutzt werden - also entsprechend ausgereift und sicher sind.

Da aber eine Menge Entwicklungsarbeit in LAC drin steckt und wir das auch noch weiter ausbauen (u.a. PHP-FPM-Unterstützung, für welche wir PHP patchen müssen), steht diese Funktion nur mit der Business-Lizenz zur Verfügung. Neben der Filesystem-Isolation wird übrigens auch das gesamte Netzwerk virtualisiert, so dass z.B. jeder Kunde sein "eigenes" Loopback-Interface (127.0.0.1) hat.

Viele Grüße

-Klaus Keppler

Soeben haben wir LiveConfig 3.0.0-rc12 in den Test-Repositories bereitgestellt.

Es handelt sich dabei um den letzten Release Candidate, in zwei Wochen (01.08.2025) soll dann das "Stable Release" von LiveConfig v3 erfolgen.

In den nächsten zwei Wochen liegt unser Fokus vor allem auf Upgrade-Tests und der Bereitstellung/Aktualisierung der Dokumentation.

Viele Grüße

-Klaus Keppler