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?
Seht so aus das Apache Option FileInfo jetzt nicht mehr verfügbar ist
Welche LiveConfig-Version genau nutzen Sie?
Es gab mit LiveConfig 2.7.4 Sicherheitseinschränkungen (SetHandler war nicht mehr erlaubt), ab LiveConfig 2.8.0 ist SetHandler aber wieder erlaubt.
Schicken Sie uns bitte ansonsten mal den Inhalt von /etc/apache2/sites-enabled/<Vertrag>.conf an support@liveconfig.com
Viele Grüße
-Klaus Keppler
Auf welches Protokoll genau soll zugegriffen werden (noch besser: welche LiveConfig-URL (Pfad genügt) wird aufgerufen?)
ZitatAllerdings wurde wohl auch beim Upgrade kein db.bak File angelegt. Upgrade wurde gestern durchgeführt.
CentOS, richtig? Werden wir überprüfen - sieht nach einem Fehler im RPM aus.
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
Danke für die Info, kk. Schade. Gibt es denn eine Roadmap für die 2.8.1?
Update ist für kommenden Montag (26.08.) geplant.
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?
Automatische SSL/TLS-Zertifikate für Subdomains (per einfacher Checkbox) kommen mit dem nächsten Update (v2.8.1).
Auch das wird also einfacher werden als bisher.
Es muss NICHTS angepasst werden! Lassen Sie die Dateibereichtigungen in /var/lib/spamassassin bitte unverändert auf "debian-spamd".
Das hat schon alles so seinen Sinn. Da SpamAssassin als "spamd" läuft, hat er keinerlei Schreibrechte irgendwo im System, kann aber auf die Regeln zugreifen (die "debian-spamd" gehören).
Wir testen die von LiveConfig erzeugte SpamAssassin-Konfiguration automatisiert auf allen unterstützten Plattformen (u.a. eben auch Debian 8/9/10) - das läuft reibungslos.
Im vorliegenden Fall wurde SpamAssassin nach der Aktivierung im LiveConfig nachträglich nochmal deinstalliert und neu installiert - dadurch gehen die Anpassungen natürlich verloren.
Wenn sich SpamAssassin zwischendurch "spontan" beendet, dann deutet das in vielen Fällen auf den sog. "OOM-Killer" hin (der schlägt bei SA gerne an, da der Prozess viele Ressourcen benötigt). Das hat aber weder etwas mit LiveConfig noch mit der SpamAssassin-Konfiguration zu tun. Ein Administrator kann der Ursache anhand der Logs auf den Grund gehen.
Um das klar zu stellen: das Problem liegt daran, dass zum Zeitpunkt der SSL-Bestellung die DNS-Server noch eine andere IP (die "alte") zurückgeliefert hatten - mit einer TTL von 86400 Sekunden (=24 Std).
LiveConfig prüft die DNS-Daten erst nach Ablauf der TTL erneut (alles andere macht auch wenig Sinn) - in diesem Fall steht der nächste Versuch also erst in etwa 24 Stunden an.
Workaround in so einem Fall ist, das noch nicht beantragte Zertifikat aus der SSL-Verwaltung zu löschen und dann erneut eines zu beantragen. Wir planen aber auch einen Button anzulegen, um die DNS-Prüfung manuell vorzuziehen.
Bei Domainumzügen ist es üblich, die TTL vorab auf einen sinnvollen Wert von z.B. 5 Minuten herunter zu setzen. Eine TTL von 24 Stunden bedeutet, dass ein eventueller Umzug auch erst nach 24 Stunden vollständig abgeschlossen ist (so lange eben, bis die DNS-Daten aus allen Caches geflogen sind).
Viele Grüße
-Klaus Keppler
Nachtrag: das 1. Zertifikat ist nun aktiv. Es hat aber ungewöhnlich lange gedauert, was sonst in 5 Minuten erledigt war, hat hier 45 MInuten gedauert, obwohl die DNS der Domain aktiv und vorhanden waren. Woran liegt das?
Es liegt schlicht am DNS. Ich kann von hier aus leider nicht sagen was exakt die Ursache war, aber die Meldungen lassen ja keinen Spielraum zur Interpretation: in einem Fall wurde ein "NXDOMAIN" vom DNS-Server geliefert (das bedeutet also nicht dass der DNS-Server nicht geantwortet hat, sondern die Domain war tatsächlich (noch) nicht vorhanden). Im anderen Fall liefert der angefragte DNS-Server andere IPs als auf dem Server vorhanden sind. Beide Fälle führen bei einer Domainvalidierung durch Let's Encrypt zu einem Fehler - das Verhalten ist also richtig.
Bei neu angelegten Domains kann es immer ein wenig dauern bis diese im DNS konnektiert sind. Es macht keinen Sinn, eine Domainvalidierung anzustoßen bevor die Domain vollständig konfiguriert ist.
Bei der zweiten Domain: schicken Sie uns einfach mal den Domainnamen an support@liveconfig.com, dann prüfen wir das gerne mal.
Viele Grüße
-Klaus Keppler
Die "normalen" User-Cronjobs werden ganz normal über "crontab" verwaltet.
Der Aufruf vom Webalizer/awstats erfolgt via /etc/cron.d/liveconfig.
Löschen Sie einfach das Verzeichnis /etc/awstats/liveconfig - dann wird awstats (via LiveConfig) nicht mehr ausgeführt.
Welche PHP-Pakete sind denn installiert? Manche Anwendungen brauchen zur Installation noch MySQL o.ä.
apt install php-cli php-curl php-gd php-imagick php-imap php-mysql php-sqlite3Die Überarbeitung des AppInstallers ist bereits in Vorbereitung.
Wie bereits im Preview Thread angesprochen läuft unter Debian 9.9 Spamassassin mit den Rechten des Nutzers debian-spamd.
Genau da liegt der Hund begraben. Wenn SpamAssassin durch LiveConfig aktiviert wird, dann läuft der unter dem User "spamd" (auf die Verzeichnisse des Besitzers "debian-spamd" kann er ja trotzdem lesend zugreifen).
Was liefert der Befehl "ps aux | grep spamd"? Das sollte unter Debian 9 etwa so aussehen:
root 28739 0.0 4.2 160100 87356 ? Ss Aug19 0:15 /usr/bin/perl -T -w /usr/sbin/spamd -d --pidfile=/var/run/spamd.pid -m 5 -H --socketpath=/var/run/spamd.sock --socketowner=root --socketgroup=spamd --socketmode=0660 -x --virtual-config-dir=/var/lib/spamassassin/%u/ -u spamd
spamd 28745 0.0 4.3 223752 88160 ? S Aug19 0:00 spamd child
spamd 28760 0.0 4.3 223752 88104 ? S Aug19 0:00 spamd child
nobody 28789 0.0 0.0 237796 132 ? Sl Aug19 0:00 /usr/lib/liveconfig/lcsam -g spamd -U postfixWenn man SpamAssassin mal komplett vom Server löscht ("purge") und anschließend neu installiert, dann kann es sein dass die User-Anpassungen weg sind.
Prüfen Sie bitte mal, ob /var/www/<Vertrag>/logs/priv/appinstall.log existiert - eventuell stehen da weitere Hinweise drin.
Gibt es auch Neuigkeiten bzgl. der Konfiguration des NGINX-Proxy (ggf. über die Web-Oberfläche)?
NGINX-Optionen können mit v2.8 über Lua konfiguriert werden (die Doku hierfür wird derzeit erstellt).
Legen Sie eine Datei namens /etc/liveconfig/lua.d/nginx.lua an, mit z.B. folgendem Inhalt:
nginx.PROXY_PARAMS = {
['proxy_redirect'] = "off",
['proxy_set_header'] = {
"Host $host",
"X-Real-IP $remote_addr",
"X-Forwarded-For $proxy_add_x_forwarded_for",
"X-Forwarded-Proto $scheme"
},
['proxy_pass_header'] = {
"Set-Cookie"
},
['client_max_body_size'] = "64m",
['client_body_buffer_size'] = "128k",
['client_body_temp_path'] = "/var/cache/nginx/tmp"
}(um genau so sein sind das die Standardeinstellungen - siehe /usr/lib/liveconfig/lua/nginx.lua)
Werte ggf. anpassen, danach LiveConfig neu starten (damit die .lua-Datei eingelesen wird) und anschließend betroffenen Webspace-Vertrag neu speichern (damit die vHost-Konfiguration aktualisiert wird).
Eventuell ist das Paket "php-cli" nicht installiert?
Die Konfiguration ist soweit in Ordnung.
Was steht denn in der .htaccess so alles drin?
Benennen Sie diese bitte einfach mal um (z.B. ".htaccess.old") und erstellen eine neue .htaccess mit folgendem Inhalt:
RewriteEngine On
RewriteRule .* /error.htmlWas passiert dann beim Aufruf der Domain (es müsste einen 404 geben), und was taucht in /var/log/apache2/other_vhosts_access.log sowie /var/log/apache2/error.log auf?
Sicher, dass Sie nirgendwo "AllowOverride None" setzen?
Viele Grüße
-Klaus Keppler
Mit LiveConfig v2.8.0 haben wir eine andere Lösung zur Vermeidung der zugrundeliegenden Sicherheitsprobleme implementiert.
SetHandler und "AllowOverride FileInfo" sind mit LiveConfig v2.8 also wieder problemlos (und risikolos) möglich.
Last but not least möchte ich allen Testern danken, die freiwillig (oder in einem Fall auch versehentlich 
die Preview-Versionen installiert und durch ihr Feedback zur Vermeidung einiger Fehler beigetragen haben.
DANKE!
Das LiveConfig-Team freut sich, Version 2.8.0 freigeben zu dürfen.
Die wichtigsten Änderungen sind:
1.) Völlig überarbeitete SSL/TLS-Integration
Die SSL/TLS-Bestellung wurde komplett überarbeitet und größtenteils neu implementiert. Ziel war es, die Bestellung von Zertifikaten vollständig zu automatisieren und den Workflow drastisch abzukürzen.
Ab sofort genügt es, beim Anlegen einer neuen Domain eine Checkbox zu aktivieren, um gleich automatisch ein SSL-Zertifikat mit zu bestellen:
forum.liveconfig.com/cms/attachment/17/Der Zwischenschritt über die SSL-Verwaltung zu gehen und dort ein Zertifikat anzulegen entfällt somit komplett. LiveConfig prüft zudem automatisch im DNS, ob die Domain konnektiert ist und stößt die eigentliche Bestellung erst dann an, wenn alles passt. Die DNS-Prüfung findet alle 15 Minuten statt.
Die Domainvalidierung für SSL/TLS-Zertifikate erfordert zudem keinen Server-Reload mehr, was die Last auf den Server bei großen Zertifikatsbeständen reduziert und die Bestellung drastisch beschleunigt (dauert nur noch ca. 20 Sekunden).
Die Kommunikation mit Let's Encrypt erfolgt zudem nun über die ACMEv2-API (die alte API (ACMEv1) wird schrittweise deaktiviert).
2.) vereinfachte Domainkonfiguration
Beim Bearbeiten von (Sub-)Domain-Einstellungen gibt es nun eine Standard-Ansicht und eine Experten-Ansicht. Die bisherige Eingabemaske entspricht der Experten-Ansicht, neu ist also die Standard-Ansicht:
forum.liveconfig.com/cms/attachment/18/Die verfügbaren Konfigurationsoptionen werden jeweils auf das Ziel (Webspace/Weiterleitung/Anwendung/...) gefiltert. Zwischen SSL und Nicht-SSL wird nicht mehr unterschieden (wer das unbedingt braucht kann das noch in der Experten-Ansicht machen).
In der Liste der Domains/Subdomains werden die WWW- und Nicht-WWW-Subdomains dann auch entsprechend zu einer Domain (mit dem Vermerk ("(+www.)") zusammengefasst, was die Liste bei größeren Domainbeständen wesentlich übersichtlicher macht.
Während des Updates auf v2.8 aktiviert LiveConfig bei entsprechend konfigurierten Subdomains automatisch die Standard-Ansicht. Dieser Vorgang wird mit den nächsten Updates weiter ausgebaut (um möglichst viele bestehende Konfigurationen zu vereinfachen, ohne dabei die Einstellungen zu ändern).
3.) Zwei-Faktor-Authentifizierung via FIDO2/WebAuthn
Alle großen Browser (außer Safari und iOS) unterstützen seit kurzem den WebAuthn-Standard zur Zwei-Faktor-Authentifizierung. Die bisherige FIDO/U2F-Schnittstelle wurde an FIDO2 angepasst, so dass nun auch ohne Browserplugin ein sicheres Token zur Anmeldung hinterlegt werden kann. Bereits registrierte U2F-Tokens bleiben weiterhin gültig.
Eine vollständig passwortlose Anmeldung via FIDO2 planen wir derzeit nicht (wir sehen das Token lieber als zweiten Faktor), sind jedoch gerne für eine Diskussion hierzu offen.
4.) viele Detailverbesserungen - unter anderem:
Eine vollständige Liste aller Änderungen finden Sie wie immer im Changelog.
Wir freuen uns auf's Feedback.
Während des Upgrades werden alle VirtualHost-Konfigurationsdateien aktualisiert. Bei Multi-Server-Installationen spielt es keine Rolle, ob zuerst der LiveConfig-Server oder die Clients aktualisiert werden. Damit die SSL-Bestellung aber reibungslos funktioniert, sollten sowohl Clients als auch der Server jeweils mit v2.8 laufen. SSL-Bestellungen mit "alten" Clients (<2.8) werden voraussichtlich nicht mehr funktionieren.
Die nächste Preview-Version steht auch schon in den Startlöchern - wir arbeiten mit Hochdruck an der Verwaltung des Backup-Prozesses und weiteren spannenden Features.
Viele Grüße
-Klaus Keppler