LiveConfig v2.8.0

  • Mit welcher PHP-Version genau und auf welcher Distribution führen Sie das Migrationsscript denn aus?


    Es ist wenig sinnvoll, TLSv1 oder gar SSLv3 wieder in LiveConfig zu aktivieren (Sicherheit geht vor) - notfalls müssten Sie z.B. über LiveConfig einen SSL-Proxy einrichten (also irgendeine Domain anlegen, die per "spiegeln (Proxy)" zur LiveConfig-URL weiterleitet).


    Oder eben das Migration-Script mit einer moderneren OpenSSL-Version ausführen (z.B. PHP 7.2/7.3).

  • Leider werden die SSL-Aufträge auch nicht bearbeitet:
    [...]
    Erst nach einem Neustart von LiveConfig wird das Zertifikat dann angelegt.
    CentOS Linux release 7.6.1810 (Core)
    LiveConfig 2.8.0-r5579


    Unter CentOS 7 mit MariaDB (5.5.60) als LiveConfig-Backend können wir dieses Verhalten reproduzieren. Wir kümmern uns gerade darum, der Fix wird noch mit in v2.8.1 einfließen.
    (mit SQLite als Backend, sowie auf anderen Distributionen mit anderen MySQL/MariaDB-Versionen klappt es interessanterweise...)

  • Update: die Ursache ist gefunden und behoben. Das Verhalten tritt auf, wenn man MySQL als LiveConfig-Backend verwendet und (das klingt vielleicht komisch) der Server zu schnell ist. :)


    In diesem Fall wird die Validierungsdatei auf dem Server angelegt und dem LiveConfig-Prozess zurückgemeldet, noch bevor die Transaktion mit dem Anlegen der Domain abgeschlossen ist.
    Wir ändern den Workflow nun geringfügig, um das Problem zu umgehen.


    Viele Grüße


    -Klaus Keppler

  • Bei uns ist es Ubuntu 10.4 mit dem 5.3 der Distri... nicht schlagen, bitte! Wir müssen von der alten Gurke eben die Daten noch migrieren. :rolleyes:


    nicht schlagen, aber der der dafür verantwortlich ist, dass ein System seit über 4 Jahren ohne Sicherheitsupdates am Internet hängt, ist rechtlich mit dran wenn dort - oder noch schlimmer von dort aus - etwas passiert.


    sorry für den OT, aber da kann ich nicht still bleiben...

  • nicht schlagen, aber der der dafür verantwortlich ist, dass ein System seit über 4 Jahren ohne Sicherheitsupdates am Internet hängt, ist rechtlich mit dran wenn dort - oder noch schlimmer von dort aus - etwas passiert.


    sorry für den OT, aber da kann ich nicht still bleiben...


    Danke für die hilfreiche Aufklärung. Es hat aber keiner behauptet, dass wir von einem aktiven System reden, das noch direkt am Internet hängt, sondern dass von einem Altsystem Daten importiert werden müssen. :rolleyes:

  • Danke für die hilfreiche Aufklärung. Es hat aber keiner behauptet, dass wir von einem aktiven System reden, das noch direkt am Internet hängt, sondern dass von einem Altsystem Daten importiert werden müssen. :rolleyes:


    ok, unwahrscheinliches Szenario, dass ein Altsystem seit vier Jahren offline ist, die Daten noch da sind und man diese jetzt erst braucht - aber OK, ich nehme das mal so hin :)

  • Seit Version 2.8 liefert die cron.php.sh immer einen Return-Code 1:



    "id -u" sollte mit dem Usernamen gefuettert werden und nicht mit dem Homeverzeichnis des Customers.

  • Die von Debian/SpamAssassin verwalteten Verzeichnisse unterhalb von /var/lib/spamassassin/ müssen weiterhin debian-spamd:debian-spamd gehören (3.00*, compiled, sa-update-keys). Die Benutzerverzeichnisse (<Vertrag>_<PostfachID>) müssen spamd:spamd gehören und mode=0750 haben.


    LiveConfig macht das alles korrekt. Probleme gibt es nur, wenn SpamAssassin eben als Benutzer "debian-spamd" läuft (dann hat er keinen Zugriff auf die user_prefs). Umgekehrt hat SpamAssassin als Benutzer "spamd" aber Zugriff auf die Regeln, die "debian-spamd" gehören. Dieses Setup ist sicherer und deshalb so beabsichtigt.


    Code
    # ls -l /var/lib/spamassassin/
    total 0
    drwxr-xr-x 3 debian-spamd debian-spamd 71 May 14  2016 3.003001
    drwxr-xr-x 3 debian-spamd debian-spamd 71 Oct 23  2018 3.003002
    drwxr-xr-x 3 debian-spamd debian-spamd 71 Jan 15  2019 3.004000
    drwxr-xr-x 3 debian-spamd debian-spamd 71 Aug 23 07:02 3.004002
    drwxr-xr-x 3 debian-spamd debian-spamd 18 Oct 23  2018 compiled
    drwx------ 2 debian-spamd debian-spamd 79 Aug 23 07:02 sa-update-keys
    drwxr-x--- 2 spamd        spamd        57 Aug  2 18:34 web345_7


    so weit, so gut - aber bayes funktioniert damit noch nicht.
    Dazu müsste LC entweder "chgrp spamd /var/lib/spamassassin && chmod g+w /var/lib/spamassassin" machen. ( siehe https://www.liveconfig.com/de/…=8220&viewfull=1#post8220 )
    Oder aber proaktiv für jedes Postfach einen Ordner vorab anlegen, statt erst wenn es user_prefs gibt.


    Welchen Weg sollen wir gehen?

  • Die sauberste Lösung wäre der jeweils eigene Ordner pro Postfach.
    Wir können das relativ einfach ins LiveConfig mit aufnehmen, so dass das Verzeichnis beim Erstellen/Bearbeiten eines Postfachs automatisch erzeugt und beim Löschen entsprechend entfernt wird.
    Ich nehme das gleich als Change Request auf, dürfte im nächsten Preview-Update enthalten sein (steht dann im Changelog).


    Viele Grüße


    -Klaus Keppler


    PS: nach wie vor bin ich der Überzeugung, dass Bayes-Filter wesentlich überbewertet sind - Mails die erst mal so weit gekommen sind, können nur relativ unscharf klassifiziert werden.

  • Hallo zusammen,


    ist folgendes Verhalten beim Hinzufügen einer Domain beabsichtigt?


    Menü: Kunde -> Kunde wählen -> Domains -> neue Domain


    SSL/TLS ist automatisch angewählt.
    Aber leider nicht mit dem LE-Account des Kunden bzw. des Vertrags
    sondern mit dem LE-Account aus dem Admin bzw. Hosting-Bereich.


    Eigentlich wollen wir die Certs für die Kunden-Domains nicht mit unserem LE-Account verwalten.


    Sofern der Kunde über einen eigenen LE-Account verfügt sollte dieser verwendet werden.
    Ist kein LE-Account vorhanden, sollte ggf. einer erstellt werden?


    Bei Kunden die über einen LE-Account verfügen wird dieser auch nicht im Dropdown angeboten.



    Gruß


    Thomas

  • Hallo zusammen,


    ich erlaube mir hier mal Herrn Keppler aus einer Mail zu zitieren (hoffe, das ist OK, da dort nichts verfängliches drinsteht):



    Das war die Antwort auf das o.g. "Problem".

  • Danke für die Info aus der Mail.


    Eventuell sollte man die Entscheidung selbst fällen können.
    Immerhin gibt es doch schon das Dropdown-Feld, dort müsste nur der LE-Account
    des Kunden mit rein und noch die Option geschaffen werden, den default-Wert zu wählen.


    So hat man nun:
    - LE-Certs für Domains vom Kunden im eigenen Hosting-Bereich sofern man die Domain hinzufügt
    - LE-Certs für Domains vom Kunden im Kunden-Bereich sofern der Kunde (oder Admin als Kunde) das Cert aktiviert
    - Kunden die dann nur einen Teil Ihrer Zertifikate sehen
    - Kunden Zertifikate vermischt mit den eigenen Zertifikaten im eigenen Hosting-Bereich

Jetzt mitmachen!

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