LiveConfig v2.8.0

  • Das LiveConfig-Team freut sich, Version 2.8.0 freigeben zu dürfen.


    Die wichtigsten Änderungen sind:


    1.) Völlig überarbeitete SSL/TLS-Integration
    Die SSL/TLS-Bestellung wurde komplett überarbeitet und größtenteils neu implementiert. Ziel war es, die Bestellung von Zertifikaten vollständig zu automatisieren und den Workflow drastisch abzukürzen.
    Ab sofort genügt es, beim Anlegen einer neuen Domain eine Checkbox zu aktivieren, um gleich automatisch ein SSL-Zertifikat mit zu bestellen:
    forum.liveconfig.com/cms/attachment/17/Der Zwischenschritt über die SSL-Verwaltung zu gehen und dort ein Zertifikat anzulegen entfällt somit komplett. LiveConfig prüft zudem automatisch im DNS, ob die Domain konnektiert ist und stößt die eigentliche Bestellung erst dann an, wenn alles passt. Die DNS-Prüfung findet alle 15 Minuten statt.
    Die Domainvalidierung für SSL/TLS-Zertifikate erfordert zudem keinen Server-Reload mehr, was die Last auf den Server bei großen Zertifikatsbeständen reduziert und die Bestellung drastisch beschleunigt (dauert nur noch ca. 20 Sekunden).
    Die Kommunikation mit Let's Encrypt erfolgt zudem nun über die ACMEv2-API (die alte API (ACMEv1) wird schrittweise deaktiviert).


    2.) vereinfachte Domainkonfiguration
    Beim Bearbeiten von (Sub-)Domain-Einstellungen gibt es nun eine Standard-Ansicht und eine Experten-Ansicht. Die bisherige Eingabemaske entspricht der Experten-Ansicht, neu ist also die Standard-Ansicht:
    forum.liveconfig.com/cms/attachment/18/Die verfügbaren Konfigurationsoptionen werden jeweils auf das Ziel (Webspace/Weiterleitung/Anwendung/...) gefiltert. Zwischen SSL und Nicht-SSL wird nicht mehr unterschieden (wer das unbedingt braucht kann das noch in der Experten-Ansicht machen).
    In der Liste der Domains/Subdomains werden die WWW- und Nicht-WWW-Subdomains dann auch entsprechend zu einer Domain (mit dem Vermerk ("(+www.)") zusammengefasst, was die Liste bei größeren Domainbeständen wesentlich übersichtlicher macht.
    Während des Updates auf v2.8 aktiviert LiveConfig bei entsprechend konfigurierten Subdomains automatisch die Standard-Ansicht. Dieser Vorgang wird mit den nächsten Updates weiter ausgebaut (um möglichst viele bestehende Konfigurationen zu vereinfachen, ohne dabei die Einstellungen zu ändern).


    3.) Zwei-Faktor-Authentifizierung via FIDO2/WebAuthn
    Alle großen Browser (außer Safari und iOS) unterstützen seit kurzem den WebAuthn-Standard zur Zwei-Faktor-Authentifizierung. Die bisherige FIDO/U2F-Schnittstelle wurde an FIDO2 angepasst, so dass nun auch ohne Browserplugin ein sicheres Token zur Anmeldung hinterlegt werden kann. Bereits registrierte U2F-Tokens bleiben weiterhin gültig.
    Eine vollständig passwortlose Anmeldung via FIDO2 planen wir derzeit nicht (wir sehen das Token lieber als zweiten Faktor), sind jedoch gerne für eine Diskussion hierzu offen.


    4.) viele Detailverbesserungen - unter anderem:

    • beim Löschen von Domains können bestehende Postfächer nun automatisch mit gelöscht oder "geparkt" werden (um diese z.B. einer anderen Domain zuzuordnen)
    • Verbesserungen und Vereinfachungen bei der Verwaltung von Mailadressen (Weiterleitungen werden nun in großen Textfeldern verwaltet, für den Spamfilter können Adressen in Blacklists/Whitelists aufgenommen werden, u.v.m.)
    • die .htaccess-Anweisung "SetHandler" kann ab sofort wieder verwendet werden - LiveConfig kümmert sich nun anderweitig um die notwendige Sicherheit. Insbesondere Drupal kann nun also wieder einfacher genutzt werden.


    Eine vollständige Liste aller Änderungen finden Sie wie immer im Changelog.
    Wir freuen uns auf's Feedback.


    Während des Upgrades werden alle VirtualHost-Konfigurationsdateien aktualisiert. Bei Multi-Server-Installationen spielt es keine Rolle, ob zuerst der LiveConfig-Server oder die Clients aktualisiert werden. Damit die SSL-Bestellung aber reibungslos funktioniert, sollten sowohl Clients als auch der Server jeweils mit v2.8 laufen. SSL-Bestellungen mit "alten" Clients (<2.8) werden voraussichtlich nicht mehr funktionieren.


    Die nächste Preview-Version steht auch schon in den Startlöchern - wir arbeiten mit Hochdruck an der Verwaltung des Backup-Prozesses und weiteren spannenden Features.


    Viele Grüße


    -Klaus Keppler

  • Gibt es auch Neuigkeiten bzgl. der Konfiguration des NGINX-Proxy (ggf. über die Web-Oberfläche)?


    NGINX-Optionen können mit v2.8 über Lua konfiguriert werden (die Doku hierfür wird derzeit erstellt).
    Legen Sie eine Datei namens /etc/liveconfig/lua.d/nginx.lua an, mit z.B. folgendem Inhalt:


    (um genau so sein sind das die Standardeinstellungen - siehe /usr/lib/liveconfig/lua/nginx.lua)


    Werte ggf. anpassen, danach LiveConfig neu starten (damit die .lua-Datei eingelesen wird) und anschließend betroffenen Webspace-Vertrag neu speichern (damit die vHost-Konfiguration aktualisiert wird).

  • Wie bereits im Preview Thread angesprochen läuft unter Debian 9.9 Spamassassin mit den Rechten des Nutzers debian-spamd.


    Wenn ich nun eine Blacklist in LiveConfig konfiguriere sieht das bei mir so aus:


    Zitat

    /var/lib/spamassassin debian-spamd:debian-spamd 0755
    /var/lib/spamassassin/web1_1 debian-spamd:debian-spamd 0700
    bzw. root:spamd 0750 (bei neu angelegten Postfächern)
    /var/lib/spamassassin/web1_1/user_prefs root:spamd 0640


    Spamassassin kann daher die user_prefs nicht lesen und berücksichtigt deren Inhalt folglich nicht.


    Wie lässt sich die am elegantesten korrigieren.

  • Wie bereits im Preview Thread angesprochen läuft unter Debian 9.9 Spamassassin mit den Rechten des Nutzers debian-spamd.


    Genau da liegt der Hund begraben. Wenn SpamAssassin durch LiveConfig aktiviert wird, dann läuft der unter dem User "spamd" (auf die Verzeichnisse des Besitzers "debian-spamd" kann er ja trotzdem lesend zugreifen).
    Was liefert der Befehl "ps aux | grep spamd"? Das sollte unter Debian 9 etwa so aussehen:

    Code
    root     28739  0.0  4.2 160100 87356 ?        Ss   Aug19   0:15 /usr/bin/perl -T -w /usr/sbin/spamd -d --pidfile=/var/run/spamd.pid -m 5 -H --socketpath=/var/run/spamd.sock --socketowner=root --socketgroup=spamd --socketmode=0660 -x --virtual-config-dir=/var/lib/spamassassin/%u/ -u spamd
    spamd    28745  0.0  4.3 223752 88160 ?        S    Aug19   0:00 spamd child
    spamd    28760  0.0  4.3 223752 88104 ?        S    Aug19   0:00 spamd child
    nobody   28789  0.0  0.0 237796   132 ?        Sl   Aug19   0:00 /usr/lib/liveconfig/lcsam -g spamd -U postfix


    Wenn man SpamAssassin mal komplett vom Server löscht ("purge") und anschließend neu installiert, dann kann es sein dass die User-Anpassungen weg sind.

  • Was liefert der Befehl "ps aux | grep spamd"?


    Das sieht derzeit so aus:


    Code
    root      1641  0.0  0.1 220140 120200 ?       Ss   Aug18   0:36 /usr/bin/perl -T -w /usr/sbin/spamd -d --pidfile=/var/run/spamd.pid -m 5 -H --socketpath=/var/run/spamd.sock --socketowner=root --socketgroup=spamd --socketmode=0660 -x --virtual-config-dir=/var/lib/spamassassin/%u -u debian-spamd
    debian-+  2762  0.4  0.2 250896 148516 ?       S    13:42   1:10 spamd child
    debian-+ 12772  0.1  0.2 237856 137476 ?       S    16:06   0:10 spamd child
    nobody   20843  0.0  0.0 467004  2072 ?        Sl   16:34   0:01 /usr/lib/liveconfig/lcsam -g spamd -U postfix
  • Denke ich konnte das Problem nun lösen.


    nach Löschung (purge) und Neuinstallation, sowie Anpassung der /etc/default/spamassassin scheint es nun zu passen


    Code
    nobody    1043  0.0  0.0 245808   176 ?        Sl   18:21   0:00 /usr/lib/liveconfig/lcsam -g spamd -U postfix
    root     11821  0.0  0.2 193216 92992 ?        Ss   19:01   0:01 /usr/bin/perl -T -w /usr/sbin/spamd -d --pidfile=/var/run/spamd.pid -m 5 -H --socketpath=/var/run/spamd.sock --socketowner=root --socketgroup=spamd --socketmode=0660 -x --virtual-config-dir=/var/lib/spamassassin/%u -u spamd
    spamd    11822  0.0  0.2 194716 92596 ?        S    19:01   0:00 spamd child
    spamd    11823  0.0  0.2 193216 88024 ?        S    19:01   0:00 spamd child


    Herzlichen Dank für die Hilfe!

  • Hi bravesurfer, was hast du in /etc/default/spamassassin angepasst? Weil wir auch mit spamd immer wieder das Problem haben, das er einfach mitten drin nicht mehr rennt...und dann nur noch als Ausgabe folgendes erhalten:

    Zitat

    nobody 10428 0.0 0.0 319540 200 ? Sl Aug02 0:41 /usr/lib/liveconfig/lcsam -g spamd -U postfix
    root 11609 0.0 0.0 15436 1980 pts/1 S+ 11:26 0:00 grep spamd


    Nach restart von spamassassin kommt dann wieder die korrekte Ausgabe:

    Zitat

    root 11705 2.0 0.5 170504 87552 ? Ss 11:30 0:01 /usr/bin/perl -T -w /usr/sbin/spamd -d --pidfile=/var/run/spamd.pid -m 5 -H --socketpath=/var/run/spamd.sock --socketowner=root --socketgroup=spamd --socketmode=0660 -x --virtual-config-dir=/var/lib/spamassassin/%u/ -u spamd
    spamd 11706 0.0 0.5 170504 82992 ? S 11:30 0:00 spamd child
    spamd 11707 0.0 0.5 170504 82996 ? S 11:30 0:00 spamd child
    nobody 11740 0.0 0.0 114736 176 ? Sl 11:31 0:00 /usr/lib/liveconfig/lcsam -g spamd -U postfix
    root 11764 0.0 0.0 15436 1840 pts/1 S+ 11:32 0:00 grep spamd


    Beobachtet haben wir, dass wenn wir ein LC Update machen, immer spamassasin danach nicht merh läuft und neu gestartet werden muss!

  • Hallo,


    nach purge und Neuinstallation von Spamassasin wird dieser unter spamd ausgeführt. Insofern wurde die /etc/default/spamassassin lediglich -u debian-spamd durch -u spamd ersetzt.


    Außerdem habe ich den Besitzer der VZ und Dateien die debian-spamd gehörten im VZ /var/lib/spamassassin auf spamd angepasst. Hier funktioniert seitdem auf einen Testsystem alles zuverlässig und stabil.


    Auf einem Produktivsystem habe ich allerdings bislang noch nicht getestet.

  • kk Gibt es eigentlich einen Grund das Liveconfig SpamAssassin als User spamd haben will und nicht wie unter Debian üblich als debian-spamd.
    Bei einer Debian 9 Neuinstallation mit Liveconfig und SpamAssassin wird ja auch das Verzeichnis für SpamAssassin mit debian-spamd angelegt. z.B.


    Code
    /var/lib ls -la
    drwxr-xr-x  5 debian-spamd debian-spamd 4096 Aug 21 17:26 spamassassin
    
    
    /var/lib/spamassassin ls -la
    drwxr-xr-x  5 debian-spamd debian-spamd 4096 Aug 21 17:26 .
    drwxr-xr-x 41 root         root         4096 Aug 21 17:25 ..
    drwxr-xr-x  3 debian-spamd debian-spamd 4096 Aug 21 17:26 compiled
    drwx------  3 debian-spamd debian-spamd 4096 Aug 21 17:26 sa-update-keys
    drwx------  3 debian-spamd debian-spamd 4096 Aug 21 17:26 .spamassassin


    Und in dem Script /etc/cron.daily/spamassassin wird ja auch der Debian Standard debian-spamd verwendet.

  • Das würde uns auch mal bitte interessieren!

    kk Gibt es eigentlich einen Grund das Liveconfig SpamAssassin als User spamd haben will und nicht wie unter Debian üblich als debian-spamd.
    Bei einer Debian 9 Neuinstallation mit Liveconfig und SpamAssassin wird ja auch das Verzeichnis für SpamAssassin mit debian-spamd angelegt. z.B.


    Code
    /var/lib ls -la
    drwxr-xr-x  5 debian-spamd debian-spamd 4096 Aug 21 17:26 spamassassin
    
    
    /var/lib/spamassassin ls -la
    drwxr-xr-x  5 debian-spamd debian-spamd 4096 Aug 21 17:26 .
    drwxr-xr-x 41 root         root         4096 Aug 21 17:25 ..
    drwxr-xr-x  3 debian-spamd debian-spamd 4096 Aug 21 17:26 compiled
    drwx------  3 debian-spamd debian-spamd 4096 Aug 21 17:26 sa-update-keys
    drwx------  3 debian-spamd debian-spamd 4096 Aug 21 17:26 .spamassassin


    Und in dem Script /etc/cron.daily/spamassassin wird ja auch der Debian Standard debian-spamd verwendet.

  • Es muss NICHTS angepasst werden! Lassen Sie die Dateibereichtigungen in /var/lib/spamassassin bitte unverändert auf "debian-spamd".


    Das hat schon alles so seinen Sinn. Da SpamAssassin als "spamd" läuft, hat er keinerlei Schreibrechte irgendwo im System, kann aber auf die Regeln zugreifen (die "debian-spamd" gehören).


    Wir testen die von LiveConfig erzeugte SpamAssassin-Konfiguration automatisiert auf allen unterstützten Plattformen (u.a. eben auch Debian 8/9/10) - das läuft reibungslos.
    Im vorliegenden Fall wurde SpamAssassin nach der Aktivierung im LiveConfig nachträglich nochmal deinstalliert und neu installiert - dadurch gehen die Anpassungen natürlich verloren.


    Wenn sich SpamAssassin zwischendurch "spontan" beendet, dann deutet das in vielen Fällen auf den sog. "OOM-Killer" hin (der schlägt bei SA gerne an, da der Prozess viele Ressourcen benötigt). Das hat aber weder etwas mit LiveConfig noch mit der SpamAssassin-Konfiguration zu tun. Ein Administrator kann der Ursache anhand der Logs auf den Grund gehen.

  • Hallo zusammen,


    vielleicht kann mir bitte einer mal die neue "völlig überarbeitete SSL/TLS-Integration" erklären, für mich ist das eher eine Verschlimmbesserung.


    Wenn ich für eine neue Subdomain z.B. forum.domain.de ein SSL-Zertifikat erstellen möchte muss ich erst:


    - die Sudomain erstellen
    - die Sudomain erst aktivieren (da diese standardmäßig deaktiviert ist und somit kein Zertifikat erstellt werden kann)
    - unter dem Punkt "SSL-Zertifikate" das Zertifikat anlegen
    - wieder zurück in die Domainverwaltung
    - die Subdomain auswählen und das Zertifikat aktivieren (da es keine Möglichkeit mehr gibt die HTTPS Weiterleitung direkt beim Anlegen des Zertifikats zu aktivieren)


    Muss das wirklich so umständlich erfolgen???


    Vielen Dank
    Alex

Jetzt mitmachen!

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