LiveConfig v2.8.0

ap24  bfal Bei uns der Grund gewesen, das Update bisher noch nicht zu installieren. Wir sind das mit einem Testkunden durchgegangen und die Verwirrung war noch größer als mit der alten Version. Vielleicht kann Herr Keppler dazu mal erklären, ob wir irgendwas falsch machen...

Danke für die Info, kk. Schade. Gibt es denn eine Roadmap für die 2.8.1?

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

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

[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.

Zitat von kk

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.

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.

Zitat von kk

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

Dann funktionieren die Spamfilter hier leider nicht mehr!

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

php7.3-fpm ist installiert und proxy_fcgi aktiviert.

php7.3-fpm.service - The PHP 7.3 FastCGI Process Manager
   Loaded: loaded (/lib/systemd/system/php7.3-fpm.service; enabled; vendor preset: enabled)
   Active: active (running) since Thu 2019-08-22 20:59:33 CEST; 15h ago
     Docs: man:php-fpm7.3(8)
 Main PID: 3776 (php-fpm7.3)
   Status: "Processes active: 0, idle: 2, Requests: 0, slow: 0, Traffic: 0req/sec"
    Tasks: 3 (limit: 4915)
   Memory: 18.2M
   CGroup: /system.slice/php7.3-fpm.service
           ├─3776 php-fpm: master process (/etc/php/7.3/fpm/php-fpm.conf)
           ├─3777 php-fpm: pool www
           └─3778 php-fpm: pool www


Aug 22 20:59:33 xxxx systemd[1]: Starting The PHP 7.3 FastCGI Process Manager...
Aug 22 20:59:33 xxxx systemd[1]: Started The PHP 7.3 FastCGI Process Manager.

DIAG:

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

[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.

Welche Erfahrungen habt ihr gemacht? Sollte das "Bugfix-Update" abgewartet werden?

Zitat von kk

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.

Das passt nun auch soweit mit der Ausnahme dass hier die Benutzerverzeichnisse mit root:spamd mode=0750 angelegt werden, wen ich ein neues Postfach anlege.

Vielen Dank an das Team für dieses Upgrade.
Da ist einiges passiert und vieles hat sich vereinfacht.

Nochmals Danke.

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

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

bzw. beim Zugriff auf mein Produktivssystem:

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!

Ja das Confixx Import Script scheint nicht mehr zu laufen. Bei mir der gleiche Fehler.