Beiträge von kk

Eine kurze Zwischenstandmeldung:

• wir haben das sogenannte Onboarding (die Erst-Einrichtung nach Installation) fertig - also Lizenz, Passwort, Kontaktdaten usw. erfassen.
  Bei LiveConfig 2.x lief das je nach Distribution unterschiedlich (Debian/Ubuntu über den Paketmanager, CentOS über ein webbasiertes Onboarding-Menü). Das wurde nun vereinheitlicht und vereinfacht.
• derzeit beschäftigen wir uns schwerpunktmäßig mit den Domaineinstellungen (Webspace etc.) - sowohl in der API als auch im Frontend. Das ist - wie bereits angekündigt - der letzte schwere Brocken, da die Komplexität hier am größten ist (Webspace-Konfiguration ist praktisch fertig, aber DNS, DNSSEC und TLS sind noch in Arbeit).

Die API-Doku wird im Laufe dieser Woche noch mal aktualisiert.

Zudem haben wir das Packaging und die Unit-Tests - bis auf Kleinigkeiten - auch fertig überarbeitet. Wir haben da unsere Infrastruktur von Jenkins auf Gitlab umgestellt und lassen alle Pakete nun direkt mit den Distributions-Werkzeugen erstellen statt wie früher mit eigenen Tools (der Teufel steckt im Detail - z.B. die neue zstd-Kompression, die noch nicht von allen Distributionen unterstützt wird).

Wir befinden uns also auf der Zielgeraden. Sobald die Webspace/Domain-Funktionen soweit fertig sind, können wir Testversionen öffentlich bereitstellen - ich bitte hierfür aber noch um ein klein wenig Geduld.

Viele Grüße

-Klaus Keppler

PS: Dev-Porn: aktuell insgesamt 5.259 Commits und 12.031 Build-Pipelines. Der C++-Code hat sich von rund 146.000 auf rund 60.000 Zeilen etwa halbiert. Über 50% des Frontend-Codes ist in Typescript programmiert, die Templates & Typescript/Javascript umfassen rund 25.000 Zeilen.

Hallo,

ab sofort steht LiveConfig 2.16.0 zum Download bereit.
Die wichtigsten Neuerungen sind:

• Unterstützung von Debian 12 ("Bookworm")
• mehr Privatsphäre beim Versand von E-Mails

Die Details sind in der News-Meldung ausführlicher beschrieben. Alle Details finden sich zudem im Änderungsverlauf.

Das Update lässt sich wie immer reibungslos über die jeweilige Paketverwaltung einspielen.

Viele Grüße

-Klaus Keppler

Nehmen Sie bitte statt dem Experten-Modus den normalen Modus. (in der nächsten LiveConfig-Version entfällt dieser Modus dann ohnehin).

Hier ist schlichtweg das falsche SSL-Zertifikat ausgewählt - das gewählte Zertifikat ist nur für "radiopuettlingen.de" ausgestellt (und auch "www.radiopuettlingen.de"), nicht aber für den Namen der Subdomain (post.radiopuettlingen.de).
Sollte das Zertifikat für post.radiopuettlingen.de nicht in der Dropdown-Liste der Zertifikate auftauchen, dann wurde das wohl nicht oder noch nicht ausgestellt.

Zitat von msaar

Habe extra ein neues SSL/TLS-Zertifikat erstellt und eingestellt, jedoch es klappt nicht.

Eine genauere Fehlerbeschreibung als "es klappt nicht" wäre ganz hilfreich.

Sie haben also eine Subdomain z.B. "webmail.xxxxxxx.de" angelegt?
Und dann ein SSL-Zertifikat für "webmail.xxxxxxx.de" erstellt?
Beim Anlegen neuer SSL-Zertifikate ist standardmäßig die Checkbox "HTTPS mit dem neuen SSL-Zertifikat konfigurieren" ausgewählt, daher sollte eigentlich alles von alleine funktionieren...

Daher: was _genau_ klappt nicht?
Ein Screenshot der Subdomaineinstellungen wäre ganz gut.

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

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

Wie viel RAM hat denn der betroffene Server?

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

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:

# 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

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

Das hat doch mit dem DNS-Anbieter der Domains überhaupt nichts zu tun.

Es geht um den Resolver, den Ihr Server verwendet, um DNS-Anfragen zu stellen. /etc/resolv.conf (oder was auch immer).

Das dürfte auch in direktem Zusammenhang mit dem anderen Thema stehen.

https://www.google.com/search?…Error%3A+open+resolver%22

Erster Treffer. War jetzt nicht sooo schwierig.

(nicht mit "öffentlichen" DNS-Resolvern auf Spamhaus zugreifen, ganz einfach.)

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.

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

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