Beiträge von kk

  • Information über unsicheren E-Mail-Empfang

    === 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. ;)

  • Problem nach Update auf 2.15.1

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

  • Problem nach Update auf 2.15.1

    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.

  • LiveConfig 2.15.1

    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

  • externe E-Mails mit lokaler Absenderdomain können nun abgelehnt werden

    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.

  • Problem nach Update auf 2.15.1

    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:

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

  • AVC apparmor="DENIED" operation="create" profile="/usr/sbin/named" Fehler

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

  • AVC apparmor="DENIED" operation="create" profile="/usr/sbin/named" Fehler

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

  • Fehler nach Serverwechsel

    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.

  • Überlauf php_errors.log

    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. :-/

  • Überlauf php_errors.log

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

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

  • Wann erfolgt Letsencrypt Zertifikate-Verlängerung

    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.

  • PHP 7.2.30, 7.3.17 und 7.4.5

    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.

  • Einstellung Fehlerseiten

    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)

  • PHP 7.4 - End Of Life

    Hallo,


    zur Information: PHP 7.4 hat nun offiziell den "End of life"-Status erreicht. Eine Übersicht über die aktiv gepflegten PHP-Versionen finden Sie auf der PHP-Website.


    Unsere PHP 7.4-Pakete für Debian/Ubuntu werden daher auch nur noch kritische "Backports" erhalten, welche wir i.d.R. aus dem php-src-security-Repository von Remi Collet beziehen. Wir empfehlen daher auch dringend, auf PHP 8 umzusteigen.


    PHP 8.0 bekommt übrigens auch nur noch Updates für kritische Fehler, als "aktive" Versionen gelten PHP 8.1 und 8.2.


    VIele Grüße


    -Klaus Keppler