Ausblick auf das nächste große Release

    • Offizieller Beitrag
    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. :)

    • Offizieller Beitrag

    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.

    • Offizieller Beitrag

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


    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:

    Code
    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

  • Beitrag von JNS ()

    Dieser Beitrag wurde vom Autor gelöscht ().

    In einer virtuellen Umgebung läuft schon mal gar nichts. Ein Server ohne IP läuft zwar auch, erfüllt aber nicht unbedingt seinen Zweck.


    Beitrag
    RE: LiveConfig 3
    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."

    Auf der Kommandozeile mit "liveconfig --diag" meldet das System aber folgende Ausgabe. Eingerichtet ist das ganze in einer virtuellen Umgebung, die mit LC 2 problemlos zurecht kommt.

    (Quelltext, 9 Zeilen)

    Marco
    • Offizieller Beitrag
    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:

    Code
    [<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

    Also die Migration hat ohne weitere Probleme geklappt. Die Keys wurden erfolgreich verschoben. In der named.conf.options steht allerdings noch

    dnssec-secure-to-insecure   yes;, laut dem Wiki Artikel sollte das aber entfernt werden?


    Das prüfen des DNSSEC Status mit rndc dnssec -status <zone> hatte aber auch nach etwas Wartezeit nie omnipresent angezeigt. Da fing es dann langsam an, dass sämtliche Zonen (alle DNSSEC signiert) teilweise nicht mehr erreichbar waren. Im LiveConfig Log hab ich dann gesehen, dass er immer Fehler bei Domain Aktualisierungen geschmissen hat, bzgl. des DNS Templates. Beim erneuten Speichern des Templates wurde mir ein externer Nameserver als fehlerhaft markiert. In dem Servernamen stand etwas in Klammern, scheinbar mag LiveConfig 3 an dieser Stelle keine Sonderzeichen (mehr). Unter LC2 war das kein Problem. Bearbeiten konnte ich den Eintrag aber nicht mehr. Also Downgrade auf LC2 gemacht (Danke, dass das so einfach geht!!), Template/externen Server editiert und von sämtlichen Sonderzeichen befreit, Upgrade auf LC3 gemacht, noch mal gespeichert, hat funktioniert. Somit konnte ich zumindest die Domains wieder bearbeiten. Ich habe zwar immer noch den Fehler [ERR] Can't add domain to object log: invalid domain or DNS template immer mal wieder im Log, aber es scheint soweit alles zu funktionieren.


    Danach gabs jede Menge Hickhack mit den Keys (durch mich verschuldet, nicht durch LiveConfig). Scheinbar hat sich an der Art wie man DNSSEC einrichtet in den letzten Jahren etwas geändert. Ich hatte beim Registrar immer den DNSKEY und den DS, welcher mir in LC2 angezeigt wurde, hinterlegt (musste man das nicht früher so machen?). Scheinbar macht man das nicht mehr, und der DNSKEY reicht. War ne lange Nacht 🙃 Jetzt scheint es sich aber langsam etwas zu beruhigen. Interessanterweise wird scheinbar immer noch ein Key mit Algo 7 genutzt, obwohl ich jetzt nur noch einen Key mit Algo 14 hinterlegt habe.


    Eine Sache die ich aber noch nicht ganz verstanden habe: über rndc dnssec -status wird manchmal die policy "insecure" angezeigt und keine der in der Config definierten Policies. Hab ich da was kaputt gemacht, oder gibt es dafür einen anderen Grund? Das Log sagt dazu nichts.


    Edit: das passiert, wenn man bei einer Zone DNSSEC deaktiviert, etwas wartet, dann wieder aktiviert und den Status mit rndc dnssec -status <zone> prüft. Da steht dann bei allen Keys Key has been removed from the zone und auch nach längerer Wartezeit ändert sich an dem zustand nichts. Auch wenn man einen neuen Key erstellt, wird der nicht sofort (nach dem speichern) unter /var/lib/bind/keys/ geschrieben. Mit einem stop von named und LC und einem starten von LC, wodurch named wieder mutgestartet wird, geht es dann wieder.


    Nicht DNSSEC bezogen: Sämtliche lc* Dienste waren nach dem Upgrade im masked state. Sollte das so sein?


    Fazit: Ich dachte Anfangs bei dem Upgrade sei etwas schiefgelaufen, aber ich war zu ungeduldig und hätte vielleicht bis Dienstag warten sollen, wenn der Upgrade Guide kommt 😅 Da ich aber nie Probleme bei LC Updates hatte, hatte ich erwartet/gehofft, dass es einfach durchläuft, so wie immer. Ich hatte aber nicht mit meinem fehlenden Wissen über DNSSEC gerechnet. Zu meiner Verteidigung: ich mache das nicht Professionell, eher als Hobby für das man wenig Zeit hat. Daher schätze ich LC so, da es für gewöhnlich ohne Probleme läuft. 😄

    Jetzt habe ich aber scheinbar wirklich einen Fehler gefunden, der durch das Upgrade entstanden ist. Ich habe phpMyAdmin und Roundcube als Anwendung installiert. beide sind aber im Status error. Im findet man dazu:


    [3855806] [2025-08-01 19:13:04.814518] [ERR] Error while creating Database: Username already exists!

    [3855806] [2025-08-01 19:13:04.814740] [ERR] Error while creating Database: Username already exists!

    [3855805] [2025-08-01 19:13:05.337996] [ERR] App installation failed for app 1: Username already exists!

    [3855805] [2025-08-01 19:13:05.615638] [ERR] App installation failed for app 2: Username already exists!


    Die ganze Zeit standen auch keine Statistiken in der Datenbank Übersicht bei den beiden Datenbanken. Bei der für Roundcube steht jetzt seit ein paar Minuten "2 Tabellen". Allerdings habe ich nichts an den Datenbanken verändert, ausser mich einmal in PMA anzumelden auf einer anderen Datenbank.


    Edith: die Datenbanken wurden bei der Aktion gelöscht. Also vorher schön Backup machen 🙂


    Edith v2: Wenn ich eine neue App installieren möchte, habe ich im Log folgenden Fehler und die Seite wo ich eine App auswählen soll bleibt leer. Vielleicht gab es den auch bei der Migration:

    [465646] [2025-08-02 19:55:51.413975] [EMERG] Uncaught exception: [json.exception.type_error.316] invalid UTF-8 byte at index 142: 0x75

    [465646] [2025-08-02 19:55:51.414013] [EMERG] METHOD: GET; URL: /liveconfig/api/v1/apps

    [465646] [2025-08-02 19:55:51.414024] [EMERG] Got exception: nlohmann::json_abi_v3_11_3::detail::type_error

      [ 0] 0x271ea5   

      [ 1] 0x273b86   

      [ 2] 0x27422b   

      [ 3] 0x274086   

      [ 4] 0x27422b   

      [ 5] 0x123b44   /usr/lib/liveconfig/libk.so.0.9

      [ 6] 0x123c92   /usr/lib/liveconfig/libk.so.0.9

      [ 7] 0x7ef415   

      [ 8] 0xf7a35    /usr/lib/liveconfig/libk.so.0.9

      [ 9] 0x125c4a   /usr/lib/liveconfig/libk.so.0.9

      [10] 0x3a6240   

      [11] 0xd44a3    /lib/x86_64-linux-gnu/libstdc++.so.6

      [12] 0x891f5    /lib/x86_64-linux-gnu/libc.so.6

      [13] 0x10989c   /lib/x86_64-linux-gnu/libc.so.6

    Hab mal auf einem Testsystem nachgesehen auf welchem Roundcube und phpmyadmin ebenfalls unte dem Adminaccount als Administrator installiert wurden. Hier funktioniert nach dem Update auf LiveConfig 3 alles wie es soll, ich sitze aber dafür noch an einigen anderen Ungereimtheiten die ich aber erst nochmal checken muss

    Ich habe mich mal etwas mit den lc* Diensten beschäftigt, da keine Mails mehr kamen. Vielleicht hat ja noch jemand das Problem.

    Das Maillog war voll mit:

    Aug 03 17:04:55 hashtag postfix/smtpd[1335974]: warning: connect to private/lcpolicyd: No such file or directory

    Aug 03 17:04:55 hashtag postfix/smtpd[1335974]: warning: problem talking to server private/lcpolicyd: No such file or directory


    - Für den lcpolicyd hatte ich nur eine lcpolicd.conf-dist unter /etc/liveconfig liegen. Daher wollte der Dienst nicht so wirklich seine Arbeit aufnehmen. Nach lcpolicd.conf kopieren und Neustarten hat geholfen.

    - Der lclogparse Dienst ließ sich gar nicht starten, da er die lclogparse.service nicht finden konnte:


    [465647] [2025-08-03 17:24:23.929248] [ERR] Failed to start service unit lclogparse: Unit lclogparse.service not found.

    [465646] [2025-08-03 17:24:23.929551] [ERR] Error while handling request: Unit lclogparse.service not found.


    habe sie dann aus /usr/lib/liveconfignach /lib/systemd/system kopiert, aktiviert und dann wurde der Dienst auch sofort in der UI als laufend angezeigt.

    - unter /etc/systemd/system/multi-user.target.wants/ sind die Links zu lclogsplit.service und lcsam.service broken. Die Dienste laufen aber, da sie scheinbar über /etc/init.d/ gestartet werden.


    Mails funktionieren jetzt wieder. Mir scheint als wurde der Installationsprozess hier nicht komplett zu Ende ausgeführt. Das Log gibt dazu leider nichts her.

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!

Benutzerkonto erstellen Anmelden