Beiträge von kk

  • LiveConfig 2.16.0 Preview

    Hallo,


    in diesem Fall gab es offenbar verwaiste Einträge in der Tabelle DNSSEC (evtl wurden mal Domain manuell aus der Tabelle DOMAINS gelöscht?)
    Wir haben die Preview eben aktualisiert (v2.16.0-dev20230505.1), diese räumt verwaiste Daten während des Upgrades auf.


    Viele Grüße


    -Klaus Keppler

  • LiveConfig 2.16.0 Preview

    Hallo,


    ab sofort steht die Preview für LiveConfig 2.16.0 zum Download bereit.
    Die neue Version unterstützt dann das am 10. Juni 2023 erscheinende Debian 12 ("Bookworm"). Eine Anleitung für das Debian-12-Upgrade haben wir auch schon vorbereitet.


    Die PHP-Pakete für Debian Bookworm werden derzeit noch mühevoll zusammengestellt. Da wir unsere CI-Plattform von Jenkins auf Gitlab-CI umstellen ist das leider noch mit ein wenig Aufwand verbunden. Bis zum Debian12-Release sollten dann aber auch Pakete für PHP 7.0 und 8.2 sowie die üblichen Extensions verfügbar sein, PHP 7.1/7.2/7.3 prüfen wir noch. PHP 5.6, 8.0 und 8.1 sind bereits fertig.


    Ein neues Feature wird derzeit noch in die 2.16.0 integriert (sollte bis kommende Woche abgeschlossen sein), so dass das Release in Kürze erfolgt.


    Viele Grüße


    -Klaus Keppler

  • eMail Erstellen/Update Fehler

    Die E-Mail-Passwörter werden in der Datei /etc/dovecot/passwd verwaltet. Zudem werden Änderungen an E-Mail-Einstellungen in /var/log/liveconfig/liveconfig.log protokolliert.


    Im ersten Schritt empfehle ich also mal, eine Kopie von /etc/dovecot/passwd anzulegen, dann ein Passwort via LiveConfig zu ändern, und anschließend per "diff" zu prüfen, was bzw. ob sich etwas geändert hat.


    Wenn eine Änderung erfolgt ist, aber das neue Passwort nicht funktioniert, dann müssen wir woanders weiter suchen (vmtl in Richtung Dovecot).Da wäre dann wichtig, welche Linux-Distribution/-Version genau zum Einsatz kommt.


    Viele Grüße


    -Klaus Keppler

  • Aktualisierung GPG-Key

    Hallo,


    leider ist uns ein Missgeschick passiert: wir hatten das Ablaufdatum des GPG-Keys zur Signatur der Pakete und Repositories nicht auf dem Schirm. :(
    Jedenfalls ist unser GPG-Key (pkgadmin@liveconfig.com) am 23.03.2023 abgelaufen.


    Wir haben die Gültigkeit des Keys um ein weiteres Jahr verlängert (23.03.2024).
    Wenn es vom Paketmanager (apt/yum) während eines Updates also eine Warnung gibt, muss der Key einfach neu importiert werden:


    Code
    # Debian/Ubuntu:
wget -O - https://www.liveconfig.com/liveconfig.key | apt-key add -


# CentOS:
rpm --import https://www.liveconfig.com/liveconfig.key


    Alternativ kann auch einfach die Keyring-Datei unter /etc/apt/trusted.gpg.d/liveconfig.gpg (Debian) bzw. /etc/pki/rpm-gpg/RPM-GPG-KEY-LiveConfig ausgetauscht werden (neue Version: liveconfig.gpg, SHA256=e67faf95e39c671725b74ff0e00bcc2584e51ad3c45bf23ec92fcb28bbc92cc8)


    Ab sofort monitoren wir den Key, um künftige Rollover-Vorgänge völlig transparent ablaufen zu lassen.
    Der verlängerte Key wird auch mit dem kommenden LiveConfig-Update (2.16.0) in /etc/apt/trusted.gpg.d/ mit ausgeliefert, zudem wird damit zusätzlich ein neuer Key installiert.


    Ich bitte um Entschuldigung für die Unannehmlichkeiten.


    Viele Grüße


    -Klaus Keppler

  • Network is unreachable

    Das geht in LiveConfig schon sehr lange (wenn nicht schon immer).


    Serververwaltung -> E-Mail -> Postfix-Einstellungen; dort die Option "Ausgehende IPv6-Adresse" einstellen auf "kein ausgehendes IPv6".


    Das eigentliche Problem scheint in diesem Fall aber die IPv6-Connectivity des Servers zu sein, das sollte unbedingt mal geprüft werden.
    In Zeiten von IPv4-Knappheit und immer mehr IPv6-nativen Anschlüssen sollten Server idealerweise gut und direkt per IPv6 erreichbar sein.


    Bei E-Mails ist das allerdings aktuell noch genau anders herum: da empfehlen wir, keine Mails über IPv6 zu versenden (das hängt wiederum mit dem Spamfiltern auf Empfängerseite zusammen).


    Viele Grüße


    -Klaus Keppler

  • LiveConfig und Versand über Postfach

    In der nächsten Version (3.0) ist das bereits implementiert, für 2.x klappt das leider nicht.
    Reseller können dort auch ihre eigenen SMTP-Zugangsdaten für Systemmails hinterlegen.


    Workaround bis dahin wäre, im Postfix eine SMTP-Relay-Anweisung für den lokalen Benutzer "liveconfig" einzurichten.

  • Ausblick auf das nächste große Release

    Erstmal: vielen Dank für die Geduld soweit!
    Ich verstehe die Erwartungshaltung, und wir arbeiten weiterhin mit Volldampf am Update! Es geht derzeit sehr gut voran.
    Die API-Doku werde ich im Laufe des Nachmittags noch mal auf den aktuellen Stand bringen, dort lässt sich erkennen welche Bereiche im Backend alle fertig sind.


    Kleiner Plausch aus dem Nähkästchen:
    es gibt zwei zentrale "Horror-Komponenten": Accounts (also die "Webspace-Verträge") und Domains (alle Domain-bezogenen Einstellungen, von Webspace bis DNS). Die Account-Komponente ist sogar noch etwas komplexer als die Domain-Komponente.
    Mit dem Account-Teil sind wir seit letzter Woche fertig: im Backend können Accounts angelegt, bearbeitet und gelöscht werden, dabei werden nun (endlich) auch die Reseller-Berechtigungen durchgehend geprüft. Der Backend-Code wurde von etwa 7.196 Zeilen auf 1.655 Zeilen reduziert. Alleine in die Frontend-Maske für die Account-Konfiguration sind etwa vier Mann-Wochen Arbeit geflossen - mit dem Ziel, diese intuitiver und übersichtlicher zu machen. Ich hoffe das passt so: :)
    forum.liveconfig.com/cms/attachment/22/


    Aktuell werden folgende Bereiche bearbeitet:
    - Templates (bisher "Angebote") - API abschließen, GUI finalisieren
    - DNS-Server, DNS-Templates (Backend)


    Ab März geht's dann mit den Domaineinstellungen (Frontend) weiter, also der letzten wirklich sehr komplexen Komponente. Den ganzen "Kleinkram" (Cronjobs, Datenbanken, etc.) haben wir bereits fertig. Ebenso ist das Backup-System soweit abgeschlossen (da stehen ab März dann die Tests mit Multi-Server-Systemen an).


    Parallel pflegen wir natürlich auch LiveConfig 2.x weiter, hier fließen auch immer wieder kleinere Änderungen am Datenbankschema mit ein, die wir für v3 benötigen.


    Viele Grüße


    -Klaus Keppler

  • mail-tester.com, 2 Fragen zum Ergebnis

    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.

  • PHP-Extension enchant

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

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