Beiträge von kk

Warum wegbekommen? Diese Regeln senken doch die SpamAssassin-Punktzahl.
Und ein SPF für den HELO (Hostname) macht keinen Sinn, deshalb wird diese Regel auch nur mit -0.001 Punkten bewertet (ist also rein informativ). SPF ist nur für Mail-Domainnamen gedacht, nicht für Hostnamen.

Enchant wird durchaus noch gepflegt (letztes Update: November 2022). Und das PHP-Modul steckt nun halt mit im PHP-Paket selbst.

Wir bereiten eine Anleitung vor, wie man mit PHP mitgelieferte Pakete manuell nachinstallieren kann (die Nachfrage nach Enchant hält sich (vorsichtig formuliert) stark in Grenzen )

=== OFFTOPIC ===
Ich bin kein DATEV-Experte, aber: es gibt die Möglichkeit, bei der DATEV seinen eigenen (öffentlichen) PGP-Schlüssel zu hinterlegen. Ab dann erhält man nicht mehr eine E-Mail mit "bitte melden Sie sich bei der DATEV an", sondern bekommt direkt die Mail der Kanzlei und kann sie im Mailprogramm (z.B. Thunderbird) entschlüsseln und lesen. Ich persönlich finde das sehr komfortabel.

Anders herum klappt das leider nicht - die PGP-Schlüssel der Kanzleimitarbeiter werden scheinbar nicht veröffentlich, so dass ich keine Ende-zu-Ende-verschlüsselte Mail an die Kanzlei senden kann.

=== ON-TOPIC ===
Unter einer "qualifizierten Transportverschlüsselung" würde ich eine Kombination aus DNSSEC und TLS 1.2/1.3 mitsamt verifizierbarem Zertifikat erwarten - mehr aber auch nicht. Streng genommen würde man DNSSEC sogar "nur" für DANE/TLSA benötigen, da ein vertrauenswürdiges Zertifikat die Authentizität des Servers eigentlich hinreichend nachweist.
Solche Mails wie eingangs zitiert riechen schon sehr aufdringlich nach "wir haben da ein super duper Mail-Gateway das Sie unbedingt nutzen müssen, weil alles andere auf der Welt ist totaaal unsicher!!!1elf!!".

Meine persönliche Meinung.

Wie bereits vermutet: die Tabelle PERMISSIONS ist kaputt. War der Server vielleicht mal irgendwann (rand)voll?
Da liegen jedenfalls zwei Fehler vor:
- der AUTO_INCREMENT-Wert für PERMISSIONS steht auf "2", der sollte aber bei "42" stehen
- da fehlen etwa 16 Einträge. Die Tabelle PERMISSIONS muss vor dem Update 41 Zeilen enthalten.

Sie können einfach von irgendeinem beliebigen anderen LiveConfig-Server (mit Version <= 2.15.0 !) einen Dump der Tabelle PERMISSIONS importieren.

Wenn diese Tabelle aber schon fehlerhaft ist, kann es sein, dass auch woanders Probleme bestehen...

Nein, das hilft leider nicht - der o.g. SQL-Output wäre hilfreich.
Dieser Fehler deutet auf eine korrupte Datenbanktabelle (PERMISSIONS) hin; jeder Eintrag darin muss einen eindeutigen Wert für P_ID haben. Während des Schema-Upgrades wird ein Eintrag hinzugefügt; wenn MySQL dabei einen "duplicate key" meldet, dann müssen bereits irgendwelche "falschen" Daten in der Tabelle stehen.

Ja, die Frage ist was mit "unsichere Form der Transportverschlüsselung" gemeint ist.
Haben Sie einen TLSA-Record im DNS für DANE/TLSA hinterlegt?
(siehe https://www.liveconfig.com/de/kb/dane/ - Abschnitt "DANE/TLSA für eingehende Mails")

Hallo,

ab sofort steht LiveConfig v2.15.1 zum Download bereit.

Bei den Änderungen handelt es sich in erster Linie um Bugfixes und Verbesserungen.
Hervorzuheben sind dabei:

• in seltenen Fällen schlug die DNS-Prüfung bei Let's-Encrypt-Zertifikaten fehl, weil statt einer erwarteten IPv4-Adresse vom Resolver eine IPv4-mapped IPv6-Adresse zurückgegeben wurde. Das wird nun korrekt erkannt und behandelt.
• alle PHP-FPM-Konfigurationen erhalten nun automatisch in die php.ini-Einstellung "disable_functions" die Funktion "opcache_get_status" hinzugefügt. Dieses Verhalten ist (aus Sicherheitsgründen) nicht deaktivierbar.
  FastCGI-Konfigurationen sind davon nicht betroffen.
• pro Domain kann nun der Empfang von externen E-Mails mit diesem Domainnamen als Absender deaktiviert werden. Das soll die Scam/Phishing-Gefahr etwas reduzieren, da nur noch E-Mails lokaler (authentifizierter) Absender mit dieser Domain akzeptiert werden.

Das Update kann wie immer völlig reibungslos über die Repositories installiert werden.

Viele Grüße

-Klaus Keppler

Nehmen wir an, Sie hosten die Domain example.org.
Wenn diese Einstellung aktiviert ist, dann lehnt der Server eingehende E-Mails (also von extern) ab, welche als Envelope-From diese Domain (example.org) enthalten.
Der Sinn ist, dass Scam/Phishing erschwert wird, indem Mails mit dieser Domain nur über lokale (authentifizierte) Benutzer eingereicht werden dürfen.

Diese Fehlermeldung deutet auf ein lokales Datenbankproblem hin (das betroffene Schema-Upgrade hier ist ziemlich primitiv).
Bitte schicken Sie die Ausgabe folgendes SQL-Befehls (ausgeführt auf der LiveConfig-Datenbank) an support@liveconfig.com, damit wir sehen was da drin eventuell falsch ist:

select P_ID, P_IDLEFT, P_IDRIGHT, P_IDLEVEL, P_PERMISSIONID, P_KEY from PERMISSIONS order by P_IDLEFT;

Zitat von ñull

Bedeutet dies, dass ich diese Frage von apt dist-upgrade mit Y hätte beantworten sollen?

Code

*** named.conf.options (Y/I/N/O/D/Z) [default=N] ?

Diese Antwort ist eigentlich genau richtig.

Zitat von ñull

Gibt es auf Ihrem Testsystem etwas in /etc/apparmor.d/local/usr.sbin.named? Bei mir war es leer.

Ja, diese Datei gibt es bei uns, und die ist recht gut gefüllt, und wurde vom Paket "bind9" mit installiert.

Was liefert denn der Befehl "dpkg -l | grep bind9" ?

Wir haben hier in unserer Testumgebung den BIND9 unter Debian 11 problemlos mit AppArmor am laufen.
Die Log-Meldung deutet darauf hin, dass BIND ein Socket in einem Verzeichnis erzeugen möchte, wofür er keine Erlaubnis hat.
Vermutlich wurde die bisherige BIND-Konfiguration vom Ubuntu migriert, und hatte da irgendwas drin was so unter Debian nicht klappt?

Eventuell taucht in /var/log/named/messages eine Meldung auf, welche Aktion genau fehlschlägt (also welches Socket nicht erstellt werden kann).
LiveConfig sollte den BIND unabhängig von AppArmor aber dennoch erkennen können.
Was liefert die Ausgabe von "liveconfig --diag" (Abschnitt "Checking for DNS server software:") ?

Verwenden Sie die Preview-Version (2.15.1)?
Dann sollte es genügen, wenn Sie in der php.ini-Verwaltung (im LiveConfig als "admin" anmelden, Hosting -> PHP-Einstellungen) einen Eintrag für "disable_functions" anlegen, der Inhalt darf dabei leer sein.
Wir werden das Problem kurzfristig auch in der Preview beheben.

Naja, wenn das irgendeine Wordpress-Extension ist, die eigenständig per ini_set() das "log_errors=on" setzt, dann kann LiveConfig da beim besten Willen nichts machen.
Einzige Lösung wäre, hier die Log-Datei (error_log) auf /dev/null zu setzen. :-/

Am besten zuerst mal prüfen ob die Einstellung "log_errors = off" auch in der php.ini korrekt drin steht:

grep log_errors /var/www/<Vertrag>/conf/php*/php.ini

Wenn das der Fall ist, dann hat wohl die PHP-Anwendung selbst irgendwo das Logging aktiviert (Funktion "ini_set()") - da hat LiveConfig natürlich keinen Einfluss darauf. Meines Wissens sollte die php-Errorlog-Datei aber rotiert werden. Wie "alt" ist die denn? (also von wann ist da der erste Eintrag)

Hallo!

LiveConfig beginnt (wie empfohlen) 30 Tage vor Ablauf mit der Verlängerung (außer man hat die Checkbox zur automatischen Verlängerung bei den Zertifikatseinstellungen ausdrücklich deaktiviert). Sollte es Probleme geben und ein Zertifikat droht abzulaufen, versendet LiveConfig zudem 14 und 7 Tage vor Ablauf eine entsprechende Hinweis-E-Mail.

Zusätzliche PHP-Interpreter müssen immer im LiveConfig registriert werden (via Lua).

Die von uns bereitgestellten PHP-Pakete liefern ein Lua-Script zur Registrierung mit (/etc/liveconfig/lua.d/php##.lua). Man kann aber genauso auch die Pakete von deb.sury.org verwenden, dann muss man eine solche Datei eben manuell anlegen (Format ist hier beschrieben).

Ich nehme das aber gerne mal als Feature Request mit auf, die Pakete von deb.sury.org längerfristig auch direkt (ohne manuelle Registrierung) erkennen zu können.

Zitat von aho546745

Edit: Gelöst durch Neustart des Postfix.

Das würde dann aber bedeuten, dass eine (völlig) andere Postfix-Konfiguration als die von LiveConfig aktiv war (ggf. durch manuelle Eingriffe). Im normalen Betrieb hat ein Postfix-Neustart hier keinen Einfluss.

Die Greylisting-Adressen werden in /etc/postfix/greylist_addrs verwaltet (plus zugehöriger .db-Datei).
Änderungen werden nach dem Speichern unmittelbar in diese übernommen.

LiveConfig stellt eigene Fehlerseiten nur für dem Fall bereit, dass noch keine Inhalte hochgeladen wurden (Beispiel: https://www.apachedemo.de)

Was z.B. 404 (Not Found) betrifft, installiert LiveConfig ganz bewusst keine eigene globale Fehlerseite. Das lässt sich aber sehr einfach einrichten - unter Debian/Ubuntu z.B. so:

1. erstellen Sie die gewünschte Fehlerseite unter /usr/share/liveconfig/html (z.B. "not-found.html")
2. legen Sie eine Datei namens /etc/apache2/conf-available/errors.conf an, mit folgendem Inhalt:
   
   
   Code

   ErrorDocument 404 /.errorFiles/not-found.html

   
   

3. führen Sie den Befehl "a2enconf errors" aus
4. führen Sie den Befehl "systemctl reload apache2" aus

(der URL-Pfad "/.errorFiles/" wird durch LiveConfig auf "/usr/share/liveconfig/html/" gemapped)

Zitat von kroerig

Bei mir wird die PHP Version in den Webeinstellungen doppelt angezeigt.

Welche LiveConfig-Version nutzen Sie? (bitte immer dazu schreiben)