Beiträge von kk

Das LiveConfig-Team freut sich, Version 2.8.0 freigeben zu dürfen.

Die wichtigsten Änderungen sind:

1.) Völlig überarbeitete SSL/TLS-Integration
Die SSL/TLS-Bestellung wurde komplett überarbeitet und größtenteils neu implementiert. Ziel war es, die Bestellung von Zertifikaten vollständig zu automatisieren und den Workflow drastisch abzukürzen.
Ab sofort genügt es, beim Anlegen einer neuen Domain eine Checkbox zu aktivieren, um gleich automatisch ein SSL-Zertifikat mit zu bestellen:
forum.liveconfig.com/cms/attachment/17/Der Zwischenschritt über die SSL-Verwaltung zu gehen und dort ein Zertifikat anzulegen entfällt somit komplett. LiveConfig prüft zudem automatisch im DNS, ob die Domain konnektiert ist und stößt die eigentliche Bestellung erst dann an, wenn alles passt. Die DNS-Prüfung findet alle 15 Minuten statt.
Die Domainvalidierung für SSL/TLS-Zertifikate erfordert zudem keinen Server-Reload mehr, was die Last auf den Server bei großen Zertifikatsbeständen reduziert und die Bestellung drastisch beschleunigt (dauert nur noch ca. 20 Sekunden).
Die Kommunikation mit Let's Encrypt erfolgt zudem nun über die ACMEv2-API (die alte API (ACMEv1) wird schrittweise deaktiviert).

2.) vereinfachte Domainkonfiguration
Beim Bearbeiten von (Sub-)Domain-Einstellungen gibt es nun eine Standard-Ansicht und eine Experten-Ansicht. Die bisherige Eingabemaske entspricht der Experten-Ansicht, neu ist also die Standard-Ansicht:
forum.liveconfig.com/cms/attachment/18/Die verfügbaren Konfigurationsoptionen werden jeweils auf das Ziel (Webspace/Weiterleitung/Anwendung/...) gefiltert. Zwischen SSL und Nicht-SSL wird nicht mehr unterschieden (wer das unbedingt braucht kann das noch in der Experten-Ansicht machen).
In der Liste der Domains/Subdomains werden die WWW- und Nicht-WWW-Subdomains dann auch entsprechend zu einer Domain (mit dem Vermerk ("(+www.)") zusammengefasst, was die Liste bei größeren Domainbeständen wesentlich übersichtlicher macht.
Während des Updates auf v2.8 aktiviert LiveConfig bei entsprechend konfigurierten Subdomains automatisch die Standard-Ansicht. Dieser Vorgang wird mit den nächsten Updates weiter ausgebaut (um möglichst viele bestehende Konfigurationen zu vereinfachen, ohne dabei die Einstellungen zu ändern).

3.) Zwei-Faktor-Authentifizierung via FIDO2/WebAuthn
Alle großen Browser (außer Safari und iOS) unterstützen seit kurzem den WebAuthn-Standard zur Zwei-Faktor-Authentifizierung. Die bisherige FIDO/U2F-Schnittstelle wurde an FIDO2 angepasst, so dass nun auch ohne Browserplugin ein sicheres Token zur Anmeldung hinterlegt werden kann. Bereits registrierte U2F-Tokens bleiben weiterhin gültig.
Eine vollständig passwortlose Anmeldung via FIDO2 planen wir derzeit nicht (wir sehen das Token lieber als zweiten Faktor), sind jedoch gerne für eine Diskussion hierzu offen.

4.) viele Detailverbesserungen - unter anderem:

• beim Löschen von Domains können bestehende Postfächer nun automatisch mit gelöscht oder "geparkt" werden (um diese z.B. einer anderen Domain zuzuordnen)
• Verbesserungen und Vereinfachungen bei der Verwaltung von Mailadressen (Weiterleitungen werden nun in großen Textfeldern verwaltet, für den Spamfilter können Adressen in Blacklists/Whitelists aufgenommen werden, u.v.m.)
• die .htaccess-Anweisung "SetHandler" kann ab sofort wieder verwendet werden - LiveConfig kümmert sich nun anderweitig um die notwendige Sicherheit. Insbesondere Drupal kann nun also wieder einfacher genutzt werden.

Eine vollständige Liste aller Änderungen finden Sie wie immer im Changelog.
Wir freuen uns auf's Feedback.

Während des Upgrades werden alle VirtualHost-Konfigurationsdateien aktualisiert. Bei Multi-Server-Installationen spielt es keine Rolle, ob zuerst der LiveConfig-Server oder die Clients aktualisiert werden. Damit die SSL-Bestellung aber reibungslos funktioniert, sollten sowohl Clients als auch der Server jeweils mit v2.8 laufen. SSL-Bestellungen mit "alten" Clients (<2.8) werden voraussichtlich nicht mehr funktionieren.

Die nächste Preview-Version steht auch schon in den Startlöchern - wir arbeiten mit Hochdruck an der Verwaltung des Backup-Prozesses und weiteren spannenden Features.

Viele Grüße

-Klaus Keppler

Posten Sie bitte mal die VirtualHost-Konfiguration aus /etc/apache2/sites-enabled/<Vertrag>.conf (gerne anonymisiert, oder per e-mail an support@liveconfig.com).

Welche Linux-Distribution (genau) nutzen Sie?
Damit .htaccess von Apache berücksichtigt wird, muss "AllowOverride" in bestimmtem Umfang erlaubt sein.
Die von LiveConfig erzeugte Konfiguration erlaubt das üblicherweise...

Kann sich der Kunde mit der E-Mail-Adresse und dem E-Mail-Passwort im LiveConfig anmelden?
(Mail-Login an LiveConfig ist technische Voraussetzung um das Passwort über RoundCube ändern zu können)

Der Secondary kennt die Seriennummer der Zone (aus dem SOA). In den Notifies wird die "neue" Seriennummer kommuniziert. Sofern (aus welchem Grund auch immer) die Seriennummer auf dem Secondary größer ist als auf dem Primary, wird kein Transfer durchgeführt.
"It's not a bug, it's a feature" - in dem Fall vom DNS.

Auf dem Secondary sind die Zonendaten nur binär in /var/cache/bind/ gespeichert - diese Dateien kann man nicht direkt auslesen.
Auf dem Secondary können Sie aber z.B. "rndc retransfer <zone>" ausführen, dann sollte die Zone komplett neu vom Primary geladen werden. Anhand des Zeitstempels der .db-Datei kann man das prüfen - eventuelle Fehler sollten im Log auftauchen (/var/log/bind/* oder syslog bzw. messages oder journalctl)

Für's Verständnis:
LiveConfig führt alle Zonenänderungen per dynamischen NS-Updates ausschließlich auf dem Primary DNS durch (dafür gibt es ja schließlich einen "Primary").
Die Übertragung der Änderungen an die Secondaries erfolgt ausschließlich durch BIND über vollständige oder inkrementelle Zonentransfers (AXFR/IXFR).

Wird eine Änderung an einer Zone vorgenommen (z.B. ein Eintrag angelegt/geändert), dann sollte auf dem Primary im Syslog so was wie "sending notifies" zu finden sein (er informiert damit seine Secondaries, dass es da 'ne Änderung gab).
Über den Befehl "rndc" kann man die Synchronisation einzelner Zonen gezielt anstoßen (z.B. "rndc reload <Zone>").
BIND ist auf Hochlast-Betrieb optimiert - er synchronisiert daher nicht jede einzelne kleine Änderung sofort an die Secondaries. Die genauen Intervalle hierfür lassen sich konfigurieren (-> BIND-Doku). In der Praxis sollten alle Änderungen aber nach spätestens 5 Minuten bei den Secondaries angekommen sein.

Häufig entstehen Probleme dann, wenn am SOA-Record gedreht wurde (Änderung des Primary-DNS) und/oder NS-Records geändert werden (z.B. wenn ein neuer Secondary festgelegt wird. der selbst aber noch nicht im DNS angelegt ist). In den Fällen gibt es aber immer Meldungen im Syslog.
Um zu sehen was vielleicht falsch ist, hilft es oft einen Blick in die Zonendateien zu werfen. Da diese ebenfalls aus Performancegründen "journaled" sind, muss die gewünschte Zone erst auf die Platte synchronisiert werden:

rndc sync [zone]

Dann kann man in /var/lib/bind/<Zone>.db die Daten einsehen.

Alternativ kann man in LiveConfig die Domain mal auf "eigene DNS" zurückstellen, eine Minute warten und dann wieder auf den gewünschten DNS-Server schalten.
Damit wird die Zone mitsamt aller Daten von allen DNS-Servern gelöscht bzw. danach wieder neu angelegt.

Viele Grüße

-Klaus Keppler

Wird nach aktueller Planung der kommende Montag (19.08.) werden. Wir befinden uns im Endspurt...

Hallo,

im Test-Repository steht nun PHP 7.2 mit "xmlrpc"-Extension bereit (php-7.2.21-2).
Da wir für den Build einige Dateien patchen müssen, folgen die Pakete für PHP 7.1 und 7.3 erst in einigen Tagen.

Viele Grüße

-Klaus Keppler

In PHP 7.2 haben wir das nun (theoretisch) drin - ein Build läuft gerade. Ich schätze, dass wir das dann ab morgen Abend ins Preview-Repository stellen, ich gebe dann noch mal Bescheid.

Welches PHP 7.2 meinen Sie - ein von uns bereitgestelltes Paket? (/opt/php-7.2/bin/php)
Oder von Ihrer Distribution? Wenn ja, welche?

XMLRPC benötigt lediglich XML-Unterstützung in PHP - und die müsste eigentlich immer aktiviert sein.
(bei unseren Paketen ist xml fest enthalten).

Sehr merkwürdig. So sieht es aus, wenn eine Mail abgelehnt wird:

Aug  2 18:34:51 mx postfix/smtpd[13493]: Anonymous TLS connection established from mail.keppler-it.de[88.198.223.3]: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
Aug  2 18:34:51 mx postfix/smtpd[13493]: 6F4A01802115D: client=mail.keppler-it.de[88.198.223.3]
Aug  2 18:34:51 mx postfix/cleanup[13496]: 6F4A01802115D: message-id=<b2015a26-4dbb-c642-10f4-9fdf2b15c064@keppler-it.de>
Aug  2 18:34:51 mx spamd[1079]: spamd: got connection over /var/run/spamd.sock
Aug  2 18:34:51 mx spamd[1079]: spamd: using default config for web345_7: /var/lib/spamassassin/web345_7/user_prefs
Aug  2 18:34:51 mx spamd[1079]: spamd: checking message <b2015a26-4dbb-c642-10f4-9fdf2b15c064@keppler-it.de> for web345_7:999
Aug  2 18:34:59 mx spamd[1079]: spamd: identified spam (99.3/5.0) for web345_7:999 in 8.1 seconds, 3129 bytes.
Aug  2 18:34:59 mx spamd[1079]: spamd: result: Y 99 - RCVD_IN_DNSWL_LOW,SPF_HELO_NONE,URIBL_BLOCKED,USER_IN_BLACKLIST scantime=8.1,size=3129,user=web345_7,uid=999,required_score=5.0,rhost=localhost,raddr=127.0.0.1,rport=/var/run/spamd.sock,mid=<b2015a26-4dbb-c642-10f4-9fdf2b15c064@keppler-it.de>,autolearn=no autolearn_force=no
Aug  2 18:34:59 mx postfix/cleanup[13496]: 6F4A01802115D: milter-reject: END-OF-MESSAGE from mail.keppler-it.de[88.198.223.3]: 5.7.1 Your message was rejected because it appears to be spam; from=<kk@keppler-it.de> to=<test@dnssec-demo.de> proto=ESMTP helo=<mail.keppler-it.de>
Aug  2 18:34:59 mx postfix/smtpd[13493]: disconnect from mail.keppler-it.de[88.198.223.3]

Welche Distribution genau nutzen Sie?
Wem gehört die Datei /var/lib/spamassassin/<Vertrag>_<Postfach>/user_prefs ? (sollte spamd:root gehören und mode=0640 haben)

Viele Grüße

-Klaus Keppler

Hallo,

unsere PHP-Pakete für Debian/Ubuntu wurden eben auf die Versionen 7.2.21 und 7.3.8 aktualisiert.
Zudem enthalten diese Pakete nun die "argon2"-Bibliothek und unterstützen somit Argon2-Hashes (Typo3-Kennern wird das was sagen...

Außerdem haben wir ab sofort PHP 7.4.0 (Beta 1) im Sortiment. Von einem produktiven Einsatz wird noch abgeraten, aber erste Tests kann man damit schon mal machen.

Viele Grüße

-Klaus Keppler

Was wird denn exakt in /var/log/mail.log protokolliert, während eine E-Mail empfangen wird die eigentlich abgelehnt werden sollte?

Und: der Absender ist aber schon extern, oder? Intern zugestellte Mails laufen üblicherweise nicht durch den Spamfilter.

Zitat von bravesurfer

Ich habe heute mal die aktuelle Preview auf einem Testsystem (Debian GNU/Linux 9.9 (stretch) installiert. Die Blacklist-Funktion für Kunden scheint hierbei jedoch ohne Funktion. Jedenfalls werden bei mir Mails vonin der Blacklist eingetragenen Absendern trotzdem zugestellt. Kann das jemand bestätigen?

Ich kann das nicht bestätigen - sollte eigentlich klappen.
Suchen Sie bitte mal mit "grep postfach@example.org /etc/dovecot/passwd" nach dem betroffenen Postfach (Mailadresse dabei natürlich anpassen). Die Zeile enthält so was wie "userdb_mail=maildir:/var/mail/web4191/1/" - daraus lässt sich der Name für das SpamAssassin-Verzeichnis ableiten - nämlich /var/lib/spamassassin/web4191_1/
Prüfen Sie ob dieses Verzeichnis existiert und ob darin eine Datei namens "user_prefs" mit den gewünschten Blacklist-Einstellungen existiert.

Wenn ja, dann deutet das darauf hin, dass SpamAssassin und/oder lcsam nicht laufen.

Prinzipiell könnten Sie den schon ersetzen, allerdings müssten Sie danach noch mal alle FTP-Passwörter neu setzen (damit die jeweiligen Konfigurationsdateien für vsftpd geschrieben werden).

Gibt es einen speziellen Grund, warum Sie von ProFTPD auf vsftpd wechseln möchten?

Viele Grüße

-Klaus Keppler

Das Problem ist, dass Mailaccounts nicht einfach zwischen Servern verschoben werden können - schließlich müssen ja alle Postfachdaten (/var/mail/<Vertrag>/<Postfach>/) und alle Passwörter (/etc/dovecot/passwd) mit übernommen werden.

Um einen "manuellen" Umzug zu besprechen, wenden Sie sich bitte an support@liveconfig.com - am besten mit der Info um wie viele Verträge und Postfächer es ungefähr geht.

Viele Grüße

-Klaus Keppler

Ich verstehe das Problem nicht.
Separate Zertifkate sind sicherer uind flexibler als ein Wildcard-Zertifikate. Die Ausstellung und Verlängerung erfolgt vollautomatisch - also wo liegt der Vorteil?

LiveConfig v2.8 enthält ein komplett neues Let's-Encrypt-Modul und nutzt damit die ACMEv2-API, womit prinzipiell auch Wildcard-Zertifikate möglich wären. Allerdings ist für die Domain-Validierung bei Wildcards ein DNS-Eintrag erfordertlich, was bedeutet dass die Domain dann auch durch LiveConfig im DNS verwaltet werden muss. Bis das soweit ist wird es noch etwas dauern.

Zitat von alex007

Wann wird der Plan den umgesetzt, habe nämlich auch das gleiche Problem??

Ab LiveConfig v2.8 (derzeit als Preview verfügbar) können Sie eine Konfigurationsdatei namens /var/www/<Vertrag>/conf/fpm.conf anlegen und damit die Werte "überschreiben", die letztendlich in der FPM-Pool-Konfiguration landen. Die Syntax für die fpm.conf ist quasi identisch mit der php.ini-Syntax (also "key = value").

/etc/init.d/lcsam start

Ein schlampig oder gar nicht konfiguriertes Init-System wird aber garantiert noch viel "Freude" bereiten...