Beiträge von kk

Zitat von bravesurfer

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.

# 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

Zitat von Febas

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.

Danke für die Info, wir werden das gleich aktualisieren.

WordPress hat vor einigen Tagen schon einmal die Pakete ohne Ankündigung (und ohne Versionsänderung) aktualisiert - keine Ahnung was da aktuell los ist...

Zitat von bravesurfer

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?

Zitat von ñull

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?)

Zitat

Allerdings 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

Zitat von taenzerme

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.

Zitat von ap24

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

Zitat von weltmeister

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-sqlite3

Die Überarbeitung des AppInstallers ist bereits in Vorbereitung.

Zitat von bravesurfer

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 postfix

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

Zitat von Feuernatter

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

Was 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