LiveConfig v2.8.0

  • Leider werden die SSL-Aufträge auch nicht bearbeitet:


    Code
    Name		Überprüft		Methode	Status
    demo2.domain.de	00.00.0000 00:00:00	http-01	pending


    Code
    [2019/08/22 11:22:06.731115] [12849|12855] ACME2: loading authorization details from https://acme-v02.api.letsencrypt.org/acme/authz/F-nfbK0HWU0K138xIm_5HoHKzCxjwcanfaUGmQv5rds
    [2019/08/22 11:22:06.988983] [12850|12851] [LUA] Created SSL/TLS domain-validation file '/var/www/.well-known/htdocs/acme-challenge/demo2.domain.de.epyj8O-rY4fkX1zH5j4--7F5IlDfMPZQmn8iVmoJF74'
    [2019/08/22 11:22:06.992495] [12849|12859] Got LC.web.addValidation.status for unknown domain 'demo2.domain.de' at '/.well-known/acme-challenge/epyj8O-rY4fkX1zH5j4--7F5IlDfMPZQmn8iVmoJF74'
    [2019/08/22 11:22:27.432283] [12850|12852] [LUA] LC.exec(/sbin/service httpd reload): error output: Redirecting to /bin/systemctl reload httpd.service


    Erst nach einem Neustart von LiveConfig wird das Zertifikat dann angelegt.


    CentOS Linux release 7.6.1810 (Core)
    LiveConfig 2.8.0-r5579

  • Ja, ich habe 2.8 auch noch nicht ausgerollt. Nur ein Testsystem bisher. Und ich werde auch warten bis 2.8.1 kommt. Kann doch den Kunden nicht erklären das es heute so, morgen so und im nächsten Update so funktioniert. Da warte ich lieber noch etwas.

  • Code
    [2019/08/22 11:22:06.988983] [12850|12851] [LUA] Created SSL/TLS domain-validation file '/var/www/.well-known/htdocs/acme-challenge/demo2.domain.de.epyj8O-rY4fkX1zH5j4--7F5IlDfMPZQmn8iVmoJF74'
    [2019/08/22 11:22:06.992495] [12849|12859] Got LC.web.addValidation.status for unknown domain 'demo2.domain.de' at '/.well-known/acme-challenge/epyj8O-rY4fkX1zH5j4--7F5IlDfMPZQmn8iVmoJF74'


    Können Sie bitte kurz beschrieben, wie exakt Sie diese Domain angelegt und das SSL-Zertifikat dafür bestellt haben?
    Die Fehlermeldung sagt sinngemäß, dass die Datei für die Domainvalidierung erfolgreich erstellt wurde, LiveConfig aber keinen offenen Bestellvorgang fand und daher den Auftrag nicht weiter verarbeitet hatte.
    Lässt sich das mit anderen (Sub-)Domains reproduzieren?

  • Können Sie bitte kurz beschrieben, wie exakt Sie diese Domain angelegt und das SSL-Zertifikat dafür bestellt haben?
    Die Fehlermeldung sagt sinngemäß, dass die Datei für die Domainvalidierung erfolgreich erstellt wurde, LiveConfig aber keinen offenen Bestellvorgang fand und daher den Auftrag nicht weiter verarbeitet hatte.
    Lässt sich das mit anderen (Sub-)Domains reproduzieren?


    Genau so wie im anderen Beitrag beschrieben:


    - die Sudomain erstellt und aktiviert (Hosting - Domains - neue Subdomain)
    - unter "SSL-Zertifikate - neues Zertifikat" das Zertifikat angelegt


    Das Problem besteht auch bei anderen Subdomains, solange bis ein Neustart von LiveConfig erfolgt.


    Die Hauptdomain besteht schon länger und wurde nicht erst kürzlich registriert/angelegt.

  • Danke für die Info. Wir haben das beschriebene Vorgehen eben unter CentOS 7 getestet - hier hat alles geklappt.
    Die Fehlermeldung ("... for unknown subdomain ...") zeigt, dass eine Datenbankabfrage an einer bestimmten Stelle kein Ergebnis zurücklieferte, obwohl sie das hätte tun müssen.
    Bitte melden Sie sich mal kurz unter support@liveconfig.com damit wir das mit ein paar SQL-Befehlen untersuchen können.


    Viele Grüße


    -Klaus Keppler

  • Email ist raus ([LC#2019082234000024]), das Problem scheint nur bei neu erstellten Subdomains zu bestehen, wenn z.B. bei einer bereits vorhandenen Subdomain ein neues Zertifikat angelegt wird, läuft die Zertifikatserstellung ohne Probleme.

  • Dann funktionieren die Spamfilter hier leider nicht mehr!


    In Beitrag #11 schreiben Sie doch aber dass alles funktioniert...?
    Die Änderung der Berechtigungen von /var/lib/spamassassin (siehe Beitrag 13) ist aber nicht notwendig (und wir raten auch davon ab).


    Wie genau äußert sich "funktioniert [...] hier leider nicht mehr" denn? Welcher Fehler tritt auf, bzw. was wird in /var/log/mail.log während des Empfangs einer E-Mail protokolliert?

  • Ist es normal, dass unter Debian 10 PHP-FPM nicht erkannt wird?


    php7.3-fpm ist installiert und proxy_fcgi aktiviert.



    DIAG:

    Code
    - PHP 7.3.4 [DEFAULT] (code='php7')
       CGI/FastCGI: /usr/bin/php-cgi
       default php.ini: '/etc/php/7.3/cgi/php.ini'


    Code
    [2019/08/22 18:23:57.753024] [737|749] [LUA] PHP version nil configured as FPM for subscription xxx but no PHP-FPM found for this version!


    Bei den optionalen PHP-Versionen von LiveConfig funktioniert FPM ohne Probleme.

  • Ist es normal, dass unter Debian 10 PHP-FPM nicht erkannt wird?


    Danke für den Hinweis!
    Die Erkennung für PHP 7.3 war noch nicht angepasst. Wurde eben korrigiert, ist in v2.8.1 (Release voraussichtlich am Montag) enthalten.
    Als Workaround bis dahin (in dringenden Fällen): die Datei /usr/lib/liveconfig/lua/web.lua bearbeiten und in Zeile 170 sowie 181-185 jeweils "7.2" durch "7.3" ersetzen; anschließend LiveConfig neu starten.

  • Wie genau äußert sich "funktioniert [...] hier leider nicht mehr" denn? Welcher Fehler tritt auf, bzw. was wird in /var/log/mail.log während des Empfangs einer E-Mail protokolliert?


    Keine Berechtigung user_prefs zu lesen. Konnte aber auch dieses Problem nun lokalisieren. Neue Nutzerverzeichnisse werden in /var/lib/spamassassin mit den Rechten root:spamd angelegt (bislang debian-spamd:debian-spamd), daher gab es in den bereits vor der Umstellung angelegten Verzeichnissen Probleme.

  • Keine Berechtigung user_prefs zu lesen. Konnte aber auch dieses Problem nun lokalisieren. Neue Nutzerverzeichnisse werden in /var/lib/spamassassin mit den Rechten root:spamd angelegt (bislang debian-spamd:debian-spamd), daher gab es in den bereits vor der Umstellung angelegten Verzeichnissen Probleme.


    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
  • Kann es sein, dass das Confixx Import Script nicht mehr funktioniert mit Version 2.8.0? Bei Zugriff vom Confixx Server auf ein cleanes Testsystem bekomme ich die Meldung


    Code
    Fehler beim Abrufen der Versionsnummer: Could not connect to host
    Sie benoetigen mindestens LiveConfig 1.3.3!


    bzw. beim Zugriff auf mein Produktivssystem:


    Code
    PHP Fatal error:  SOAP-ERROR: Parsing WSDL: Couldn't load from 'https://example.com:8443/liveconfig/soap?wsdl&l=user&p=password' : failed to load external entity "https://example.com:8443/liveconfig/soap?wsdl&l=user&p=password"
     in cfximport.php on line 1271


    Ich vermute mal, das liegt am fehlenden TLSv1 Support. Kann ich den wieder einschalten? Oder wie mache ich ein Downgrade auf die Vorversion?


    Bedankt vorab!

Jetzt mitmachen!

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