Beiträge von kk

Uh, gute Frage. Wenn man das im vBulletin irgendwo abschalten kann machen wir das gerne (ich schaue mich später gerne noch mal im Backend um).

Wir planen übrigens das alte vBB in einigen Monaten durch ein neues Board zu ersetzen.

Zitat von Danny Patterson

Es steht doch ganz klar das es einen ersten Ausblick (wenn alles Glatt geht) mit der kommenden 2.9.2 gibt?!

Exakt.
Um genau zu sein: der Backup-Service selbst (lcbackup) ist tatsächlich schon fertig und wird auch seit v2.9.0 schon installiert (aber noch nicht aktiviert). Wir arbeiten aktuell "nur" noch an der Konfiguration der Backups. Und das ist in der Tat wesentlich komplexer als "nur mal nen Cron-Job einzurichten"...

Vorab schon mal ein paar Worte zu unserem System:
das Backup wird durch einen separaten Prozess durchgeführt (lcbackupd). Die einzelnen Backupjobs laufen in separaten Threads - die Anzahl der gleichzeitigen Threads ist konfigurierbar (kann man also dann je nach Serverleistung/-Last anpassen).
Ebenso ist frei konfigurierbar, zu welchen Zeiten welche Backups erzeugt werden - so kann man z.B. einmal täglich ein Vollbackup erstellen, und alle vier Stunden die Datenbanken sichern usw.
Damit Kunden den Server nicht "abschießen", ist ebenfalls konfigurierbar, ob Kunden ggf eine gewisse Zeit abwarten müssen bis sie ein neues Backup anstoßen können (um nicht alle zwei Minuten ein Backup zu erstellen
Last but noch least ist die Anzahl der vorgehaltenen Backups ebenfalls frei konfigurierbar - sowohl der vom System erstellten (automatischen) Backups, als auch der vom Kunden erzeugten.

Wenn alles glatt geht gibt's einen ersten Ausblick bereits mit dem kommenden Update v2.9.2.

Viele Grüße

-Klaus Keppler

Zitat von antondollmaier

Können wir dafür in der Mailverwaltung oder beim Account das Feature deaktivierbar haben?

Und den Default auf "nicht verschieben", so dass der Nutzer/Kunde das explizit für jedes Postfach aktivieren muss?

Ja, so ist das geplant. In den Mailservereinstellungen kann das dann grundsätzlich aktiviert/deaktiviert werden, zudem pro Postfach. Ich sehe das auch so, dass Kunden das ausdrücklich aktivieren sollen, dann ist zumindest klar wer daran schuld ist, wenn Mails "plötzlich" verschoben werden...

Nun, man kann den Kunden alternativ auch erklären, warum ein "Spam-Ordner" eben keine gute Idee ist und man ihn deshalb bewusst nicht anbietet.

Hinterfragt denn wirklich niemand den Sinn und Zweck von dem Ganzen?

Nutzt denn niemand hier Google Mail? Kann ich mir gar nicht vorstellen...

Fakt ist: E-Mails, die im Spam-Ordner landen, werden nur extrem selten angeschaut (wenn überhaupt). Das hat dann folgende Nebenwirkungen:

• dieser Ordner wird von den meisten Kunden nie gelöscht werden (=> müllt zu)
• fälschlicherweise dort einsortierte Mails werden übersehen
• korrekterweise dort einsortierte Mails werden aufgehoben (=akzeptiert) statt diese direkt abzuweisen

Bei Google Mail ist es ein zunehmendes Problem, dass Mails voreilig im Spam-Ordner landen und somit beim Empfänger faktisch nicht ankommen.

Meiner Meinung nach sollte man sich darauf fokussieren, möglichst viel Spam direkt abzulehnen.
Bayes-Filter werden dafür übrigens überbewertet. Wenn man ClamAV und SpamAssassin richtig tuned und regelmäßig pflegt, hat man letztendlich viel mehr davon. Mit einer guten Kombination aus DNS-Whitelist, Greylisting, DNS-Blacklists, ClamAV mit zusätzlichen Regeln (z.B. Sanesecurity) und SpamAssassin mit entsprechender Pflege (z.B. Scores für SPF/DKIM anpassen, ggf. selber DMARC einführen, usw.) erhält man fantastische Ergebnisse.

Aber für "unbelehrbare" werden wir dieses Feature dann wohl mit einem der nächsten Updates einführen. Beim Setzen der Checkbox ("verdächtige Mails in Spam-Ordner verschieben") wird dann einfach eine entsprechende Sieve-Regel erzeugt.
Aber noch mal: ich rate dringend davon ab - das gibt nur Ärger ("Hilfe meine E-Mails kommen beim Empfänger nicht an", "Hilfe ich erwarte eine Mail aber die kommt nicht", "Warum kommen über POP3 nur manche Mails bei mir an?", und so weiter...)

Viele Grüße

-Klaus Keppler

Hallo,

unsere PHP-Pakete für Debian/Ubuntu wurden eben auf die Versionen 7.2.27, 7.3.14 und 7.4.2 aktualisiert.
Ebenso wurde die igbinary-Extension auf die Version 3.1.2 aktualisiert.

Viele Grüße

-Klaus Keppler

Alternativ eine IP-Gruppe bearbeiten (z.B. Namen ändern).

Die neuen Pfade für die Domainvalidierung wurden mit v2.9 eingeführt, wobei LiveConfig da während des Upgrades eigentlich alle vHosts hätte aktualisieren sollen.
Auf welcher Distribution arbeiten Sie, und wissen Sie noch welche Version vor dem Upgrade auf 2.9.0 lief?

Danke für den Hinweis - wir haben den Fehler eben reproduzieren können.

Wir werden die Sache nun analysieren und kurzfristig beheben (mit v2.9.2).

Viele Grüße

-Klaus Keppler

Das Problem findet sich in dieser Meldung:

/opt/php-7.3/lib/extensions/no-debug-non-zts-20180731/igbinary.so: undefined symbol: ps_globals

Die "igbinary"-Extension benötigt zwingend die "sessions"-Extension.
Auf welcher Distribution arbeiten Sie, und haben Sie das sessions-Modul eventuell deaktiviert?

(das Laden der igbinary-Extension erfolgt über /opt/php-7.2/etc/conf.d/zz_18_igbinary.ini - und somit erst *nach* der session.ini)

Das passiert ja sicher nicht plötzlich, sondern nach irgendeinem Ereignis.
Ich tippe mal darauf, dass Debian aktualisiert wurde?
In dem Fall unter "Serververwaltung" -> "Mail" die Dovecot-Konfiguration neu schreiben lassen.

Viele Grüße

-Klaus Keppler

Starten Sie bitte LiveConfig mal neu und versuchen die Installation nach ca. 60 Sekunden noch mal (LC aktualisiert kurz nach dem Start das AppInstaller-Repository).

Hallo,

unsere PHP-Pakete für Debian/Ubuntu wurden eben auf die Versionen 7.2.26, 7.3.13 und 7.4.1 aktualisiert.
Zudem wurde im PHP 7.4-Paket ein Fehler mit der XML-Extension behoben.

Viele Grüße

-Klaus Keppler

PHP 7.4 wurde eben aktualisiert (PHP 7.4.1) - damit sollte auch die XML-Extension korrekt funktionieren.

Viele Grüße

-Klaus Keppler

Zitat von leonex

Hallo,

aus den 7.4 Paketen funktioniert pecl/pear gar nicht:

root@referenz:/opt# /opt/php-7.4/bin/pear install xdebug
[...]
XML Extension not found

Das Problem ist bekannt (da gibt's gerade einen anderen Thread zu dem Thema). Offenbar enthält unser PHP 7.4-Paket zwar die XML-Bibliothek, aber nicht so wie manch andere Extensions das brauchen.

In diesem Moment wird aber gerade PHP 7.4.1 compiliert und paketiert - das dürfte in ca. einer Stunde fertig sein. Da ist XML dann korrekt eingebunden.

Also am besten gegen 13:00/14:00 PHP auf 7.4.1 aktualisieren und dann noch mal testen.

Viele Grüße

-Klaus Keppler

Die Frage war an tfi gerichtet... Was auf irgendwelchen anderen Systemen herauskommt spielt überhaupt keine Rolle.

Mit der nächsten Version (2.9.2) gibt es die Möglichkeit, pro IP-Gruppe TLS1.0/1.1 abzuschalten (analog der SSL-Chiffren-Auswahl und der HTTP/2-Option).
Die Änderung wurde eben committed, wir müssen nun noch testen ob die generierte Konfiguration auf allen Plattformen wie erwartet funktioniert.

Welche Distribution genau nutzen Sie?

Und was liefert folgende Ausgabe:

/opt/php-7.4/bin/php -i | grep -i xml

Wenn's doch nur immer solche kleinen Wünsche wären...

Der CSV-Export ist letztendlich nur eine Sache von ca. 30 Minuten (der technische Unterbau dafür ist ja komplett vorhanden, wir müssen nur die Datenaggregierung ein wenig dafür anpassen).
Ist also vermutlich im nächsten Update (v2.9.2) bereits vorhanden.

Let's Encrypt via API ist in Arbeit, könnte mit v2.9.2 fertig sein (Mitte Januar).

Das mit der Expertenansicht bei neuen Domains haben wir aufgenommen, wird auch kurzfristig korrigiert.

Hallo,

ab sofort steht LiveConfig v2.9.1 zum Download bereit.

Dieses Update beinhaltet ausschließlich Bugfixes und kleinere Verbesserungen - die vollständige Liste finden Sie wie immer im Changelog.

Viele Grüße

-Klaus Keppler