Preview: v2.8.0

  • Hallo,


    ab sofort steht eine allererste Preview von LiveConfig v2.8.0 zum Download bereit.
    Wie im Changelog zu sehen ist, gab es eine ganze Menge Änderungen. Die wichtigsten Neuheiten sind:

    • komplett neue SSL-Integration:

      • beim Anlegen einer Domain kann nun gleich SSL mit nur einer Checkbox mit aktiviert werden. LiveConfig prüft im DNS ob die Domain konnektiert ist und hält die Zertifikatsbestellung ggf. so lange zurück.
      • Let's Encrypt wird nun über die ACMEv2-API (RFC8555) angesprochen. Längerfristig sollen damit auch WildCard-Zertifikate möglich sein.



    • stark vereinfachte (Sub-)Domain-Konfiguration:

      • ab sofort werden neue Domains/Subdomain in einer vereinfachten Darstellung konfiguriert (die bisherige separate HTTP/HTTPS-Konfiguration ist in der Expertenansicht weiterhin möglich)
      • <Domain> und www.<Domain> können somit gleichzeitig konfiguriert werden
      • Einstellung der Ziele (Ordner, Weiterleitung, Anwendung) vereinfacht



    • verbesserte Webspace-Konfiguration:

      • Anweisung "SetHandler" ist nun wieder in .htaccess-Dateien erlaubt (ohne dass es Sicherheitsprobleme bei PHP-FPM gibt)
      • Domain-Validierung erfordert nun keinen Server-Reload mehr (entlastet den Server und beschleunigt die Zertifikatsausstellung)



    • LiveConfig ist nun nicht mehr per TLSv1/TLSv1.1 erreichbar (erfüllt somit die Empfehlungen des BSI, siehe TR-02102-2)
    • Unterstützung des WebAuthn-Standards zur sicheren Zwei-Faktor-Authentifizierung (abwärtskompatibel mit FIDO U2F, bestehende Token funktionieren also weiterhin, ab sofort aber mit allen großen Browsern)


    ... sowie viele weitere (kleinere und größere) Verbesserungen. Das ist auch noch nicht alles - ein paar Features kommen noch.


    Während des Upgrades auf v2.8 ist zu beachten:


    • in Multi-Server-Installationen sollten der LiveConfig-Server und alle -Clients möglichst zeitnah aktualisiert werden. Die Reihenfolge dabei (erst Server oder erst Clients) ist egal. Wichtig ist aber, dass nur wenn Client und Server beide auf v2.8 laufen, die erstellte Webspace-Konfiguration zuverlässig funktioniert (insbes. bei Bestellung von SSL-Zertifikaten)
    • die Apache/NGINX-Default-vHost-Konfigurationen werden während des Upgrades automatisch neu generiert


    Aktuelle Showstopper sind noch:

    • SSL-Objekte können teilweise noch nicht gelöscht werden (z.B. automatisch wenn ein Kunde gelöscht wird)
    • Verlängerung von SSL-Zertifikaten sowie SSL-API via NGINX sind noch nicht vollständig getestet, können also noch fehlerhaft sein
    • etliche Übersetzungen fehlen noch (viele Phrasen sind noch auf Englisch)
    • der neue Backup-Service (lcbackup) ist noch nicht in die GUI integriert


    Wir empfehlen daher DRINGEND, die Preview-Version noch nicht auf Produktivsystemen einzusetzen (davon raten wir ja ohnehin grundsätzlich ab, aber wir möchten unsere Ressourcen nicht in die nachträgliche Reparatur womöglich gestörter Produktivsysteme stecken). Statt dessen werden die die LiveConfig-Demo voraussichtlich morgen Mittag auf die aktuelle Preview aktualisieren.


    Am kommenden Montag, 17.06.2019, planen wir die Preview erneut zu aktualisieren, bis dahin kümmern wir uns um alle offene Punkte und bekannte Probleme.
    Trotz Erlanger Bergkirchweih wird hier durchgearbeitet! ;)


    Bis dahin schon mal vielen Dank für die Geduld!


    Viele Grüße


    -Klaus Keppler

  • danke für das preview


    ich versuche es hier nocheinmal, könnten die folgenden änderungen in die nächste version mit aufgenommen werden?

  • Code
    +    if LC.fs.is_file(opts.path .. "/conf/fastcgi_params.conf") then
    +      fh:write("\t\t# Include customer-specific configuration options:\n")
    +      fh:write("\t\tinclude ", opts.path, "/conf/fastcgi_params.conf;\n")
    +    end


    Man kann in ~/conf/nginx.conf auch fastcgi_params hinterlegen, die dann bei jedem vHost per include eingebunden werden.
    Ab v2.8 kann man zudem in ~/conf/<domain>.nginx.conf Domain-spezifische Einstellungen hinterlegen.
    (normalerweise werden die fastcgi_params ja ohnehin über /etc/nginx/fastcgi_params verwaltet)


    Code
    +              fh:write("\t\tproxy_set_header\tHost\t$host;\n")
    +              fh:write("\t\tproxy_set_header\tX-Real-IP\t$remote_addr;\n")
    +              fh:write("\t\tproxy_set_header\tX-Forwarded-For\t$proxy_add_x_forwarded_for;\n")
    +              fh:write("\t\tproxy_set_header\tX-Forwarded-Proto\t$scheme;\n")


    Das haben wir mit einigen Modifikationen übernommen. Es gibt nun eine neue Variable "nginx.PROXY_PARAMS", welche bei allen Proxy-Hosts angewendet werden; über die custom.lua oder /etc/liveconfig/lua.d/ kann man diese beliebig anpassen. Ist in der nächsten v2.8-Preview enthalten.
    Die o.g. Einstellungen sind dann standardmäßig gesetzt.


    Viele Grüße


    -Klaus Keppler

  • Ich habe mir gerade die Demo etwas angeschaut und dabei hat sich eine Frage ergeben.
    Wenn man bei einer neuen Domain/Subdomain SSL aktiviert wird muss vorher in der SSL Verwaltung der Let´s Encrypt Dienst als Anbieter hinzugefügt sein? Oder aktiviert Liveconfig diesen dann automatisch?

  • Wenn man bei einer neuen Domain/Subdomain SSL aktiviert wird muss vorher in der SSL Verwaltung der Let´s Encrypt Dienst als Anbieter hinzugefügt sein? Oder aktiviert Liveconfig diesen dann automatisch?


    Es muss zuerst ein SSL-Anbieter eingerichtet werden. Sofern dieser auch kostenfreie Zertifikate anbietet (z.B. Let's Encrypt) kann dieser Anbieter dann beim Anlegen einer Domain ausgewählt werden.


    Das nachträgliche Aktivieren von SSL für bestehende Domains/Subdomains (durch den Endkunden) wird gerade integriert und dürfte ab Montag in der Preview enthalten sein. Hier sind Änderungen am Berechtigungssystem erforderlich.


    Der Endkunde wird letztendlich keinen "eigenen" Let's-Encrypt-Account benötigen, das wird alles über einen vom Admin oder Reseller verwalteten Account abgewickelt.

  • Die Preview wurde eben auf v2.8.0-r5484 aktualisiert. Zudem enthält die Preview-Seite nun auch eine kurze Liste der wichtigsten "Showstopper" (bekannte Fehler & Probleme), die derzeit bearbeitet werden.
    Das nächste Update der Preview-Version soll am kommenden Dienstag, 25.06.2019 erfolgen.


    Viele Grüße


    -Klaus Keppler

  • Hallo, läuft bisher stabil die Preview. Eine Frage dazu: Wo kann man denn - wie angekündigt für v2.8 - die Whitelist Einträge für eMail Adressen (-Domains) vornehmen?


    Wo wir gerade bei dem Thema sind. Wie arbeiten diese Einträge nun? Wird das am Greylisting/Spamassassin und Co vorbei entschieden oder würde eine Whitelist Email trotzdem abgewiesen werden wenn sie nen zu hohen Score hat?

  • Wie arbeiten diese Einträge nun? Wird das am Greylisting/Spamassassin und Co vorbei entschieden oder würde eine Whitelist Email trotzdem abgewiesen werden wenn sie nen zu hohen Score hat?


    LiveConfig schreibt die angegebenen Adressen in entsprechende whitelist_from bzw. blacklist_from-Anweisungen einer postfachspezifischen SpamAssassin-Konfiguration. Auf das Greylisting hat das also leider keinen Einfluss (das ist mit Postgrey auch nicht ganz trivial). Ein Whitelist-Absender wird unabhängig vom eventuellen Score aber vom SpamAssassin durchgelassen.


    Aufgrund der vielen Anfragen werden wir uns demnächst mit rspamd beschäftigen - damit sollten noch flexiblere Regeln möglich sein.


  • Ein Whitelist-Absender wird unabhängig vom eventuellen Score aber vom SpamAssassin durchgelassen.


    Das klingt doch gut und hilft wirklich weiter, Greylisting ist dabei ja nicht ganz so dramatisch.




    Aufgrund der vielen Anfragen werden wir uns demnächst mit rspamd beschäftigen - damit sollten noch flexiblere Regeln möglich sein.


    Das wäre Super. :p

  • Danke für die Rückmeldung, das ist unschön, da ja Whitelist eigentlich alles durchlässt, was man einträgt. So zumindest der Standard. Eine Idee wie wir Adressen an den DNSBL bei LC vorbei bekommen, damit diese ankommen? Eigener DNSBL WhitelistServer wäre ja schwachsin dafür, das wäre so die einzige Idee von uns, wie man das umgehen könnte, da Whitelist DNSBL ja den normalen DNSBL deaktiviert, was eigentlich eine Whitelist auch tun sollte. => rbldnsd <= ist hier sicher auch für LC interessant? Gab ja auch mal hier nen Vorschlag von Hr. Keppler selbst: https://www.liveconfig.com/de/…smtpd_client_restrictions
    Umsetzung?

Jetzt mitmachen!

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