Ist das Absicht, das abgelaufene Letsencrypt-Zertifikate nicht gelöscht werden?
Ich meine - ganz unabhängig davon, dass das bei mir unangenehm ist, weil mein Monitoring ohne Grund meckert: Warum möchte man ein abgelaufenes LE-Zertifikat aufheben wollen, wenn die Verlängerung erfolgreich war?
Das Problem ist gerade erneut aufgetreten auf einem anderen Server (Ubuntu 14.04 LTS, Liveconfig 2.4.1-r4635; Problem per Supportticket angefragt).
Update
Das Problem beim aktuellen Auftreten hat sich geklärt. Das Letsencrypt-Zertifikat war korrekt eingespielt. Nur das alte Zertifikat war noch nicht gelöscht und wurde deswegen vom eigenen Monitoringsystem mit Warnung wegen Ablauf quittiert.
Das ist aber dann "individuell pro Server" und nicht "pro Postfach", also vollkommen disjunkte Ansätze.
...und damit vollkommen nutzlos. Danke für die Erinnerung. Ich vergaß dass Header-/Body-Checks nur serverweit konfigurierbar sind.
---
Die Anfrage, dass der ein oder andere Kunde mal von Adresse xxx@example.com keine Mail bekommen will, kommt auch hier ab und an rein. Allerdings ist mit Aktivierung eines guten Spamfilters dann der Kunde langfristig glücklicher.
Auf diese Art und Weise Spammer fern zu halten stelle ich mir recht mühsam vor. Da bin ich doch froh, dass ich hier einen Spamfilter habe, bei dem so etwas nicht notwendig ist.
Eine Möglichkeit, einen individuellen Inhaltsfilter zu haben, der E-Mails nach bestimmten Kriterien ablehnen kann, wäre bestimmt hilfreich. Also die Postfix Header- und Body-Checks in ein Interface gepackt. Der Wunsch ist aber jetzt eher theoretischer Natur. Ich weiss noch nicht, ob das wirklich nütztlich ist.
Auch wenn ich im Changelog dazu nichts gelesen habe, jetzt mit Version 2.2.0 (r4254) funktioniert es.(Ich weiss auch dass das nicht die neueste Version ist).
Ich habe hier liveconfig 2.4.0-r4602 Standard auf Debian Jessie.
Es betrifft 2 Zertifikate eines Kunden.
Im Webinterface in der Zertifikatsverwaltung das Ablaufdatum 5.9.2017 stehen - also völlig korrekt. Das Zertifikat im Dateisystem läuft aber bereits am 6.7.2017 ab. Das LE-Zertifikat wurde laut liveconfig.log gestern am 7.6 erfolgreich verlängert.
[2017/06/07 07:54:42.262042] [3397|16038] ACME: created new authorization request for 'meinedomain.de'
[2017/06/07 07:54:42.660933] [3397|16038] ACME: created new authorization request for 'meinedomain.de'
[2017/06/07 07:54:42.671195] [3397|16038] ACME: sceduling renewal of SSL certificate for 'meinedomain.de'
[2017/06/07 07:56:45.972527] [3397|16908] ACME: accepted certificate request for 'meinedomain.de' (certificate URL: https://acme-v01.api.letsencrypt.org/acme/cert/039f0ddskfhsdfhsdkfjhsdkfjh5329f51afca)---
Interessant ist, dass auch das Modifikationsdatum der Zertifikatsdatei vom gleichen Tag ist(Ich habe vorher noch zusätzliche SSL-Zertifikate erzeugt, so dass LC die alten Zertifkate mit dem alten Inhalt wohl neu geschrieben hat).
---
Als Versuch habe ich die veralteten Zertifikatsdateien gelöscht und LiveConfig veranlasst - durch erzeugen eines neuen Zertifikates - die Zertifikate neu zu schreiben. Damit wurden jetzt die neuen Zertifikate mit dem korrektem Ablaufdatum in die Zertifikatsdatei geschrieben.
---
Zur Überprüfung meiner SSL-Zertifikate nehme ich eine angepasste Version hiervon:
E-Mailarchivierung wird ja immer wichtiger. Insofern haben wir Anfragen nach der Journaling-Mailbox, so wie die Begrifflichkeit bei MS Exchange genannt wird. Dahinter verbirgt sich ein Konto, das alle Mails einer Domain sammelt.
Ausnahmen dabei zu definieren wäre auch brauchbar(betriebsrat@,...)
Bei der Anbindung von Postfix sind die Empfehlungen z. B. bei Mailstore derart, dass mit sender_bcc_maps und recipient_bcc_maps gearbeitet wird und dort dann z. B. pro Domain eine Zieladresse konfiguriert wird. Ausnahmen könnte man über PCRE-Maps implementieren.
Insofern wäre mein Feature Request, dass es pro Domain eine einfach Möglichkeit gibt diese Journallingmailbox zu konfigurieren. Vielleicht bei einer Option "Journalling Mailbox aktivieren" unter Kunde -> Domains -> E-Mail. Die Journalling-Mailbox könnte dann ein ganz normales IMAP/POP3-Konto sein, dass man mit seiner Archivierungssoftware abrufen bzw. importieren kann.
Das ist aber schade, dass lclua so kompiliert wurde, dass man in custom.lua keine Module laden kann. 
[2017/05/16 19:04:32.587247] [14853|14854] [LUA] Loading custom Lua settings from '/usr/lib/liveconfig/lua/custom.lua'
[2017/05/16 19:04:32.587755] [14853|14854] Can't run /usr/lib/liveconfig/lua/liveconfig.lua: error loading module 'lfs' from file '/usr/local/lib/lua/5.1/lfs.so':
dynamic libraries not enabled; check your Lua installationZur Info hier mal das Script, das mir den VHOST konfiguriert.
#!/bin/bash
#
# Add a configuration to a vhost which shows an individual
# error page if the application behind the proxy is down
#
# This is not really that much robust, since it depens on the way
# how the vhost-configuration is written at the moment
#
# This script creates correct changed files even if run muĺtiple times
# (idempotence)
#
#
CFG=/etc/apache2/sites-available/web6.conf
DOMAIN="meinedomain.de"
MATCH1="ServerName www.$DOMAIN"
MATCH2="ServerAlias $DOMAIN"
ERRORPAGE_CONF="/etc/apache2/includes/${DOMAIN}-docroot-errorpage.conf"
ERRORPAGE_CONF_SED="${ERRORPAGE_CONF//\//\\/}" # sed requires slashes in an Regex-Address-Range to be escaped!
PROXY_EXCLUDES="/etc/apache2/includes/${DOMAIN}-proxy-excludes.conf"
PROXY_EXCLUDES_SED="${PROXY_EXCLUDES//\//\\/}" # sed requires slashes in an Regex-Address-Range to be escaped!
SITE_URL="http://www.${DOMAIN}:8093"
SITE_URL_AWK="${SITE_URL//\//\\/}" # It's good to mask the slashes and dots here too
SITE_URL_AWK="${SITE_URL_AWK//\./\\.}"
# Step 1 - Add "Include /etc/apache2/includes/meinedomain-docroot-errorpage.conf"
# after the lines
#
# ServerName www.meinedomain.de
# ServerAlias meinedomain.de
#
TMP=$(mktemp)
sed -r -i -e "/$ERRORPAGE_CONF_SED/d" $CFG
awk '/'"$MATCH1"'/ { on=1; print $0; next } /'"$MATCH2"'/ { if(on==1) { print $0; print " Include '"$ERRORPAGE_CONF"'"; next } } {print $0;on=0}' $CFG >$TMP
mv $TMP $CFG
# Step 2 - Add "Include /etc/apache2/includes/meinedomain-proxy-excludes.conf" before the line
#
# RewriteRule ^(.*) http://www.meinedomain.de:8093$1 [P,L]
#
sed -r -i -e "/$PROXY_EXCLUDES_SED/d" $CFG
awk '/RewriteRule \^\(\.\*\)[ \t]+'"$SITE_URL_AWK"'/ {print "\tInclude '"$PROXY_EXCLUDES"'"; print $0; next} {print $0}' $CFG >$TMP
mv $TMP $CFGHier noch die Hook-Konfiguration:
add_special_503_for_meinedomain,apache.configureVHost,postHier noch die Konfigurationsdatei für die Fehlerseite:
<Directory /var/www/web6/htdocs/www.meinedomain.de>
Require all granted
</Directory>
ErrorDocument 503 /503.html...und die Ausnahmedefinition für den Proxy:
RewriteCond %{REQUEST_URI} !^/503.html
RewriteCond %{REQUEST_URI} !^/images_503.*
RewriteCond %{REQUEST_URI} !^/assets_503.*Siehe auch:
Ich habe gerade eine individuelle Fehlerseite implementiert, für den Fall, dass eine als ReverseProxy konfigurierte Webseite keinen Kontakt zur Anwendung hat(HTTP 503). Z. B. wenn die Anwendung gerade gewartet wird oder eine Störung hat.
Das war nicht ganz so hübsch und schnell umgesetzt. Ich habe im Endeffekt über custom.lua nach apache.configureVHost die virtualhost-Datei mit awk umgemodelt, so dass ein DocumentRoot, eine Directory-Directive und im ProxyAbschnitt Ausnahmen für die Fehlerseiten über mehrere Include-Anweisungen definiert sind.
Könnte man das besser lösen?
Eigentlich ist eine definierbare Fehlerseite für "Proxy-nicht erreichbar" beim verwenden eines Reverse-Proxys doch schon etwas, was man haben will. Sprich der Einsatz wäre durchaus für die Allgemeinheit nützlich - oder nicht?
Das Problem war jetzt wirklich etwas ärgerlich. Ich habe zunächst ein eigenes Let's Encrypt-Zertifikat von aussen eingespielt, was mir LiveConfig allerdings immer mit seinem eigenen Let's Encrypt-Zertifikat(dass es wegen der hier beschriebenen Problematik nicht verlängert werden kann und was demzufolge bei mir abgelaufen war) überschrieben hat.
Sprich jedes mal, wenn ich etwas im LC konfiguriert habe, schmeisst er mir das alte Zertifikat rein.
Aktueller workaround ist jetzt, dass ich mit dem Hooks-Modul die betroffenen Zertifikate vor der Apache-Konfiguration sichere und nach der Apache-Konfiguration, aber noch vor dem apache2 reload, wieder zurückspiele. Nicht schön, aber jetzt macht es keinen Ärger mehr.
hooks.conf
backup_special_certs,apache.configureVHost,pre
restore_special_certs,apache.configureVHost,postbackup_special_certs
/usr/bin/install -d -m 700 /var/backup/ssl
tar --preserve-permissions -C /etc -cf /var/backup/ssl/backup.tar ssl/private/keyfile.key ssl/certs/certfile.crt ssl/certs/certfile-ca.crtrestore_special_certs
tar --preserve-permissions -xf /var/backup/ssl/backup.tar -C /etc
rm -f /var/backup/ssl/backup.tarSiehe auch:
Ich vermute mal, dass man über entsprechende Hooks nach dem lua-bind-Modul, die mit diesem kleinen LUA-Modul(lua-system-hooks) möglich sind, die Informationen zum Zeitpunkt von Änderungen zur Verfügung stehen und dass man diese mit eigenen Scripten in den PowerDNS reinbringen kann.
Die Aufgabe wäre die Anbindungsskripte zu schreiben:
In Anbetracht der Vielfalt möglicher Datensatztype könnte das evtl. schon etwas mehr sein. Den Aufwand kann ich jetzt noch nicht so ganz abschätzen.
Es gibt sogar eine Manpage zur liveconfig.conf? Ich bin ja begeistert. Danke!
Mit LC.log.print ...
https://www.liveconfig.com/de/…i.lua.reference.log.xhtml
kann man ja log-Meldungen erzeugen. Wie kann ich das Loglevel setzen? Per Voreinstellung scheint es ja auf INFO zu stehen.
Wenn ich ein beliebiges Verzeichnis ohne Proxy-Funktion einstelle wird das Letsencrypt-Zertifikat sauber generiert.
Wenn ich statt einem Verzeichnis den Proxy eintrage, bekomme ich das hier:
/var/log/liveconfig/liveconfig.log
[2017/04/19 15:33:58.011187] [24330|12724] ACME: challenge for 'mydomain.de' failed: Invalid response from http://mydomain.de/.well-known/acme-challenge/47nAe1nSzKXT9z_wA1URg4LiFOZq-eonoj14VVUI0xg: "<!DOCTYPE html PUBLIC
"-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html>"
[2017/04/19 15:33:58.301289] [24330|12724] ACME: challenge for 'www.mydomain.de' failed: Invalid response from http://www.mydomain.de/.well-known/acme-challenge/KFOauR9KCcdixfMYdojc9FIYBugVIDakTVCQXK-pUIU: "<!DOCTYPE html PUBLIC
"-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html>"So sieht der generierte Ausschnitt aus der Apache-VHost-Config aus:
<VirtualHost 1.1.1.1:443>
ServerName mydomain.de
ServerAlias www.mydomain.de
SSLEngine On
SSLCertificateFile /etc/ssl/certs/c34c4736f5c3e12d.crt
SSLCertificateKeyFile /etc/ssl/private/c34c4736f5c3e12d.key
SSLCertificateChainFile /etc/ssl/certs/c34c4736f5c3e12d-ca.crt
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{HTTP_HOST} ^mydomain\.de\.?$ [NC]
RewriteRule ^(.*)$ https://www.mydomain.de$1 [R=301,NE,L]
<IfModule mod_proxy.c>
RewriteCond %{HTTP_HOST} ^www\.mydomain\.de\.?$ [NC]
RewriteRule ^(.*) http://1.1.1.1:8090/$1 [P,L]
</IfModule>
</IfModule>
</VirtualHost>Wie geschrieben, das kann so nicht funktionieren. Ich sehe ja auch die ACME-Requests im CherryPy-Webserver-Log - und da gehören die nicht in.
Ich habe gemerkt, dass bei mir ein Letsencrypt-Zertifikat nicht verlängert wird. Die Webseite ist im Proxymodus. (CherryPy - Webserver auf localhost)
D. h. das liegt dann ja vermutlich daran, dass die ACME-Requests an die Anwendung weitergegeben werden, die damit natürlich nix anfangen kann.
Vielleicht wäre es gut die ACME-Requests als Proxy-Ausnahme zu definieren?
Ich habe ein kurzes lua-Modul geschrieben, mit dem man eigene Hook-Scripte einbinden kann, z. B. zur Nachbearbeitung einer Konfigurationsdatei, jedes Mal, wenn diese durch Liveconfig neu geschrieben wurde.
Ich pflege damit das Benno-Milter-Plugin in der Postfix-Konfiguration nach, wozu ich 2 Werte in der Konfiguration erweitern muss.
Hier ist der Code:
https://codeberg.org/megabert/…main/liveconfig_lua_hooks
Zitat von LiveConfig HandbuchSollten Sie Änderungen an den von LiveConfig mitgelieferten Lua-Programmen vornehmen, kann selbstverständlich keine Gewährleistung für deren Korrektheit übernommen werden. Prüfen Sie eigene Funktionen bitte entsprechend sorgfältig, bevor Sie diese produktiv einsetzen!
EDIT 18.5.:
EDIT 29.6.2021:
Source-Repo auf Codeberg geändert.
Hallo,
ich bekomme hier diese Fehlermeldung im Liveconfig-Log(/var/log/liveconfig/liveconfig.log) angezeigt:
[2017/04/13 14:56:23.850680] [31171|31173] [LUA] LC.exec(systemctl restart opendkim.service): error output: Failed to get D-Bus connection: Unknown error -1
[2017/04/13 14:56:23.850726] [31171|31173] [LUA] LC.exec(systemctl restart opendkim.service): exited with return code 1Debian Jessie 8.7
Liveconfig Version: 2.2.3 Platform: x86_64-unknown-linux-gnu Revision: 4343Das Debian ist ein Upgrade-Kandidat. D. h. die Dienste laufen nicht mit systemd, obwohl die systemd-Programme installiert sind. In Verwendung befindet sich aber noch SysV-Init.
Kann man das dem Liveconfig irgendwie beibiegen, dass es bitte SysV verwenden möge?
Der Apache wird im Gegensatz dazu brav über /etc/init.d/apache2 gesteuert.
Auch für mich wäre das wichtig. Gibt's irgend etwas neues dazu?
Wie schon geschrieben. Eine PowerDNS-Plugin wäre super, aber eine generische Hook-Sammlung, mit der man sich die Hooks selbst implementieren kann wäre auch ausreichend.
Ich muss den Beitrag auch nochmal ausgraben. Ich habe nämlich heute auch nochmal 2 Versuche gemacht und es hat nicht mehr so funktioniert, wie ich das von Liveconfig gewohnt war.
Das was ich haben will ist z. B. das:
<IfModule mod_proxy.c>
ProxyRequests on
ProxyPass / http://localhost:3000/
ProxyPassReverse / http://localhost:3000/
</IfModule>Damit funktioniert das nicht:
<IfModule mod_proxy.c>
RewriteCond %{HTTP_HOST} ^mydomain\.de\.?$ [NC]
RewriteRule ^(.*) http://localhost:3000/$1 [P,L]
</IfModule>Ich meine das hätte mal funktioniert. Mit der "neuen" RewriteRule funktioniert das nicht; da die Reverse-Funktionalität fehlt.