Beiträge von kk

    Das gibt es eigentlich schon, habe eben gesehen dass das aber nur in unserem Debian-Test-Repo enthalten ist. Wir übernehmen es gleich auch ins "normale" Repo. :)

    Interessant. Ich habe mir den betroffenen Code angesehen: lcsam reicht die eintreffende E-Mail komplett (also inkl. aller Header) an spamd weiter. Allerdings enthält die Mail vom Postfix zu diesem Zeitpunkt offenbar noch keinen "Return-Path:"-Header (mit dem Envelope-From).


    Wir haben lcsam nun so angepasst, dass er den Envelope-From selber als Return-Path: an den spamd übergibt. In unseren Tests hat der SPF-Check somit geklappt.


    Die Änderung ist bei GitHub bereits eingecheckt, in der kommenden Version 2.9.1 ist das dann auch berücksichtigt.


    Viele Grüße


    -Klaus Keppler

    Der Filter ist ja jetzt da, aber man hat immer noch keine Möglichkeit sich nur die eigenen Zertifikate anzuzeigen.


    "Nicht zugeteilt" filtert alle Zertifikate, die nicht irgendeinem Kunden zugeteilt sind.
    Damit sollten doch die eigenen Zertifikate angezeigt werden - oder etwa nicht?

    Ist die "liveconfig.keys" auf dem Master (LiveConfig-Hauptserver) oder auf einem der DNS-Slaves leer?
    Und ist die komplett leer (also 0 Bytes groß) oder ist zumindest der LiveConfig-typische Header/Footer enthalten?
    Selbst bei einem "purge" wird diese Datei nicht gelöscht...

    You're explicitly asked whether your modified configuration should be overwritten or be kept. The default is even to keep your existing configuration.


    To be honest, I don't know what we should change here...

    Hallo,


    ab sofort steht LiveConfig v2.9.0 zum Download bereit.


    Der Schwerpunkt der Änderungen lag noch mal bei der Verwaltung von SSL-Zertifikaten und der Webspace-Konfiguration. Einige Workflows wurden noch etwas verbessert, und viele kleinere Fehler behoben. Die Liste aller Änderungen findet sich wie immer im Changelog - die wichtigsten Neuerungen sind:

    • Let's Encrypt: wenn LiveConfig auf dem Server private IPv4-Adressen erkennt und keine NAT-IPs dafür hinterlegt sind, führt es automatisch keine DNS-Checks mehr vor SSL-Bestellungen aus
    • Let's Encrypt: der DNS-Check kann zudem auch individuell deaktiviert werden, z.B. wenn die zu testende Domain über ein CDN betrieben wird
    • über die Lua-Variable LC.web.PHPCLI kann nun der PHP-CLI-Interpreter für den AppInstaller abweichend definiert werden (z.B. wenn die Distribution nur ein altes PHP5 ausliefert)
    • beim Löschen einer Domain können nun optional die damit verknüpften SSL-Zertifikate automatisch mit gelöscht werden
    • die Liste der SSL-Zertifikate (SSL-Verwaltung) kann nun gefiltert werden (abgelaufen, nicht zugewiesen, einem Kunden zugewiesen, ...)


    Die Versionsnummerierung wurde zudem auch geändert. Künftig tragen offizielle Releases nur noch das Suffix "-release" (die bisherige "Revision-Number" entfällt). Test-Builds haben immer ein Suffix in der Form "-dev20191202.1".


    Viele Grüße


    -Klaus Keppler

    Hallo,


    heute wurde PHP 7.4.0 veröffentlich.
    Ab sofort stehen in unseren Repositories auch die entsprechenden Pakete für Debian 8/9/10 und Ubuntu 16/18 zur Verfügung.


    Die Module für Redis/igbinary werden in den nächsten Tagen noch nachgereicht, alle anderen bislang bekannten Module stehen auch schon bereit.


    Viele Grüße


    -Klaus Keppler

    Das mit der Zuordnung der Zertifikate prüfen wir gerade, sollte mit v2.9 aber auch behoben sein.


    Dieser Fall trat dann auf, wenn man nachträglich ein Let's-Encrypt-Zertifikat beauftrag hat, die Checkbox bei "HTTPS mit dem neuen SSL-Zertifikat konfigurieren" aber nicht aktiviert war.


    Fehler ist mit dem nächsten Preview-Update behoben (steht heute ab ca. 15:00 bereit)


    Viele Grüße


    -Klaus Keppler

    Sie hatten offenbar den SpamAssassin zwischenzeitlich per "purge" vom Server gelöscht, jedenfalls wurde die von LiveConfig angepasste Konfiguration überschrieben.


    1. beenden Sie SpamAssassin (service spamassassin stop)
    2. bearbeiten Sie die Datei /etc/defaults/spamassassin. Suchen Sie dort den Eintrag "OPTIONS=", kommentieren diesen aus und fügen danach folgende Zeile ein:

      Code
      OPTIONS="-m 5 -H --socketpath=/var/run/spamd.sock --socketowner=root --socketgroup=spamd --socketmode=0660 -x --virtual-config-dir=/var/lib/spamassassin/%u/ -u spamd"


    3. starten Sie SpamAssassin anschließend neu.

    Danke für das Log!
    Das Problem war tatsächlich, dass die Zertifikate ursprünglich nicht ausgestellt werden konnten ("invalid") und LiveConfig das in einer Schleife immer wieder überprüft hatte. Mit v2.9 wird das anders gelöst und dürfte damit nicht mehr auftreten.


    Das mit der Zuordnung der Zertifikate prüfen wir gerade, sollte mit v2.9 aber auch behoben sein.


    Viele Grüße


    -Klaus Keppler

    Bitte löschen Sie diese Datei wieder, das bringt in der Tat nichts.


    Nach dem Löschen der Datei bitte SpamAssassin mal neu starten ("service spamassassin restart") und prüfen ob die Datei /var/run/spamd.sock dann existiert. Wenn nicht, bitte mal die Ausgabe von "service spamassassin status" posten.

    Hallo,


    unsere PHP-Pakete für Debian/Ubuntu wurden eben auf die Versionen 7.2.25 und 7.3.12 aktualisiert.
    Zudem ändern sich damit ab sofort die Versionierung der Pakete. Statt bisher z.B. "7.2.25-1+stretch1" lautet die Nummer nun "1:7.2.25-1+deb9u1".


    Damit wird ein mögliches Problem beim Dist-Upgrade umgangen (die alphabetische Sortierung von "stretch"/"buster" ist problematisch, "deb9" und "deb10" wird von Debian dagegen korrekt sortiert).


    Viele Grüße


    -Klaus Keppler

    Hallo,


    nein - eine Begrenzung auf einzelne Kunden gibt es leider nicht.
    Wenn nur der Zugriff auf *einen* einzelnen Kunden gewünscht wird, könnte man innerhalb dieses Kunden einen zusätzlichen LiveConfig-Benutzer angelegen.
    Außerdem ist es möglich, einem Benutzer zwar die Berechtigung zur Kundenverwaltung zu geben, nicht aber für "eigene" Webspaces des admin-Accounts. (ich weiß ja nicht um welchen Use-Case es da geht - vielleicht hilft das...)


    Viele Grüße


    -Klaus Keppler

    Nutzen Sie LiveConfig mit der standardmäßigen SQLite-Datenbank?
    Ein anderer Kunde hat ein ähnliches Problem berichtet. Wir vermuten, dass ein Thread, der die Let's-Encrypt-Sachen bearbeitet, die Datenbankverbindung zu lange offen hält und somit andere Zugriffe blockiert.


    Schicken Sie uns bitte mal die Ausgabe von "ps aux -L | grep liveconfig" (entweder hier posten, oder per Mail an support@liveconfig.com). Zudem wäre interessant, ob es regelmäßige Meldungen in /var/log/liveconfig/liveconfig.log gibt.


    Viele Grüße


    -Klaus Keppler

    LiveConfig speichert alle Daten über die gesamte Multiserver-Installation nur auf dem "Master".


    Wenn der "Hauptserver" also nur auf eine andere Maschine umgezogen wird (d.h. alle Daten usw. werden mit übernommen), dann ist da nichts zu beachten.
    Was allerdings nicht ohne Weiteres geht ist, einen LiveConfig-Server in einen LiveConfig-Client umzuwandeln. Wenn Sie so etwas vorhaben, setzen Sie sich bitte mit uns in Verbindung (support@liveconfig.com); mit einer Hand voll SQL-Befehle ist das meistens machbar.


    Viele Grüße


    -Klaus Keppler