Heute die nächste Anfrage, eine von vielen die hier ständig reinkommen, hier im Original:
Kann man da nicht einen kleinen Hinweis anbringen, dass sich diese Anzeige nicht in Echtzeit aktualisiert? Oder anders: "Zuletzt aktualisiert am xx.xx.2024"?
Wo sollte man den Hinweis denn nun noch anbringen?
Wie in meinem Screenshot direkt darüber zu erkennen ist, wird das Datum der letzten Aktualisierung bereits bei den Postfach-Details angezeigt.
Oh, danke für den Hinweis mit dem Changelog. Wird bei Gelegenheit korrigiert. 
Zu den Sprachen: ja, Outlook schießt da wirklich den Vogel ab, da es diese Ordner lokalisiert anlegt - je nach Sprache und Version hat man da "Gesendete Elemente", "Gelöschte Elemente" usw... In meinen Augen völliger Schwachsinn, es wäre wesentlich sinnvoller gewesen das Mapping auf einen lokalisierten Namen nur in der Anzeige zu machen (so wie bei jedem vernünftigen E-Mail-Programm). In unseren ersten Tests hatte sich zumindest gezeigt, dass wenn serverseitig bereits ein "Sent" und "Trash" existiert, Outlook diese als solche verwendet (was dann tatsächlich den Wildwuchs etwas eindämmt).
Nur mit einer nachträglichen Aktivierung dieser Option muss man etwas vorsichtig sein, weil Dovecot diese neuen Ordner dann ggf. zusätzlich anlegt, und man somit z.B. "Sent" und "Gesendete Elemente" gleichzeitig hat. Man kann ungenutzte Ordner aber problemlos löschen oder das IMAP-Abonnement deaktivieren.
Das SPS_FTPPASS muss praktisch auf den selben Wert gesetzt werden wie ACCOUNTS.AC_TMPPWD. Letzteres wird aber aus der LiveConfig-Datenbank gelöscht, sobald es erfolgreich im System gesetzt wurde (Prinzip der Datensparsamkeit).
Am besten testen Sie das mal - ändern Sie ein betroffenes Passwort und schauen ob dann in AC_TMPPWD noch etwas drin steht. Falls LiveConfig das "zu schnell" löscht, lässt sich evtl mit einem Trick helfen (dazu dann ggf. nochmal kurz melden).
Mit folgendem SQL können Sie die Passwörter umkopieren:
UPDATE SITEPROSITES SET SPS_FTPPASS=(SELECT AC_TMPPWD FROM ACCOUNTS WHERE AC_ID=SPS_FTPUSERID) WHERE SPS_FTPUSERID IN (...)
("..." durch die AC_IDs ersetzen, bei denen das Passwort geändert wurde)
Hallo,
wir haben die Preview-Version 2.16.3 eben aktualisiert. Da diese Version teilweise schon länger in einigen komplexen Installationen läuft, planen wir deren Release direkt in den nächsten Tagen.
Neben Detailverbesserungen und einigen Bugfixes enthält diese Version eine neue Konfigurationsoption für Dovecot: "IMAP-Ordner automatisch anlegen".
Das bedeutet, dass die Ordner Drafts, Sent und Trash durch Dovecot automatisch erstellt und abonniert werden, sobald ein IMAP-Client sich anmeldet. Normalerweise™ sollten E-Mail-Programme (MUAs, Mail User Agents) das automatisch machen. Ein Kunde hatte uns aber darauf hingewiesen, dass das zumindest in bestimmten Szenarien nicht erfolgt (hier konkret: aktuelles Outlook auf MacOS, konfiguriert mittels AutoDiscover). Das führt dann beim Senden von E-Mails zu einer Fehlermeldung, da die versendete Nachricht nicht im Ordner "Gesendete Elemente" abgelegt werden konnte.
Wir konnten dieses Verhalten in Tests reproduzieren. Ob AutoDiscover darauf einen entscheidenden Einfluss hat ist unklar, möglicherweise sind auch "normale" manuelle Konfigurationen betroffen. Seit Outlook 2019 gibt es ohnehin diverse Probleme bei AutoDiscover (wir planen hierfür eine Anpassung in LiveConfig 2.17).
Da diese Dovecot-Option einen Einfluss auf bestehende Postfächer haben kann, ist diese Einstellung bei bestehenden Installationen automatisch deaktiviert, nur bei neuen Installationen ist diese aktiv. Bei einer nachträglichen Aktivierung kann es sein, dass einige E-Mail-Clients einige Ordner dann quasi doppelt haben (z.B. Sent und Sent Messages).
Zumindest bei Outlook war es so, dass dieses automatisch den Ordner Sent für die gesendeten Nachrichten verwendet, wenn dieser bei der ersten Anmeldung bereits serverseitig existierte.
Abschließend kann ich mir den Hinweis nicht verkneifen, dass Outlook entgegen der landläufigen Meinung kein E-Mail-Programm ist (auch wenn es behauptet, IMAP zu unterstützen), sondern nur ein Client für Microsoft Exchange. 
Viele Grüße
-Klaus Keppler
Ja, geplant durchaus (Feature Request).
Die Umsetzung ist aber nicht ganz trivial, da Apache von Haus aus alle hochgeladenen Dateien nur als www-data:www-data abspeichern möchte. Im Shared Hosting funktioniert das natürlich nicht.
Wir haben schon Ideen wie das zu lösen wäre, kurzfristig ist das aber leider noch nicht realisierbar.
Ist wie bei Liveconfig, man hat seit zig Jahren auf nötige Funktionen und Weiterentwicklungen gewartet und es ist einfach nix passiert. Wäre das schon am Anfang klar gewesen hätte ich gleich was eigenes geschrieben.
Das möchte ich so nicht stehen lassen. LiveConfig wurde und wird durchgehend weiterentwickelt. Zum Entwickeln gehört mehr, als einzelne bestimmte Funktionen einzubauen (die möglicherweise Sie speziell benötigen/erwarten), sondern auch eine Produktpflege.
Eine Individual-Entwicklung ist selbstverständlich immer die optimale Lösung (weil die ja alle Anforderungen erfüllt), aber nunmal auch die aufwendigste und teuerste Lösung. Zudem setzt das die entsprechenden Kompetenzen und Ressourcen voraus.
Und jetzt bitte wieder zurück zum Ursprungsthema, allgemeine Diskussionen gehören nicht in diesen Thread.
Der Zeitpunkt der letzten Aktualisierung wird durchaus in den Postfachdetails angezeigt:
Es wird immer Kunden geben, die Tomaten auf den Augen haben und/oder die Schuld immer woanders suchen. Leider.
Nun habe ich einen Kunden, der mich seit Monaten zu spamt und der Eintrag im LiveConfig unter Blacklist bringt absolut nichts. Wenn das schon bei einer normalen Kunden Domain nichts bringt, wie soll das bei richtigen SPAM ziehen?
Ich verstehe das jetzt nicht ganz, aber wenn Sie den Absender als "Kunden" bezeichnen, dann sendet er seine Mails möglicherweise als normaler (authentifizierter) Benutzer direkt auf Ihren Mailserver?
In dem Fall greift die Blacklist nicht (wie auch der Spamfilter insgesamt), da authentifiziert eingelieferte Mails bewusst nicht gescannt werden.
Viele Grüße
-Klaus Keppler
Hmm, scheinbar ist das Gerät nicht ganz so ausgereift. :-O
https://www.reddit.com/r/Passk…rently_work_on/?rdt=41682
https://www.heise.de/news/Goog…y-Verwaltung-9684858.html
Mal schauen was unsere Tests ergeben...
Sie haben den Key also im LiveConfig unter "Einstellungen" als WebAuthn/FIDO2-Key hinzufügen können, aber die Anmeldung klappt nicht?
Das ist dann durchaus merkwürdig.
Für WebAuthn/FIDO2 ist es eigentlich nur erforderlich, dass die angesprochene Website mit einem "offiziellen" TLS-Zertifikat erreichbar ist (ein selbst-signiertes aber akzeptiertes Zertifikat reicht da nicht).
Ich kann mir höchstens vorstellen, dass der neue Key irgendwelche älteren Protokolle oder Signaturen nicht mehr unterstützt, die LiveConfig womöglich noch verwendet - das ist aber reine Spekulation.
Ich bestelle uns eben auch mal so einen Key, damit wir das testen.
Diese "Drop-Ins" sind sozusagen die Overrides (ich denke wir reden hier von der selben Sache). systemd sucht sowohl in /etc/systemd/system/<unit>.d/ als auch in /lib/systemd/system/<unit>.d/ nach entsprechenden Overrides/Drop-Ins.
Wenn Sie "nur" ExecStart ändern, dann sehe ich auch keinerlei Konflikt mit den vom "10-sandbox.conf" vorgenommenen Einstellungen.
Hello,
from now on there is the possibility to harden PHP-FPM additionally. The packages php-(VERSION)-opt-hardened can be installed in addition to the PHP versions provided by us, e.g:
apt install php-8.3-opt-hardenedThese include a so-called drop-in for the respective systemd unit files in order to run the FPM pool manager with additional restrictions:
All settings can be found (including comments and reference to the respective systemd documentation) at /lib/systemd/system/php(VERSION)-fpm.service.d/10-sandbox.conf. If individual settings cause problems in a specific case, they can be overwritten by an additional drop-in.
Please let us know if you encounter any problems or unexpected restrictions during operation. In the longer term, we plan to equip PHP-FPM with these restrictions by default. Further measures to increase server security are also being prepared.
The hardened packages are available for PHP 5.6 - 8.3 on Debian 10-12 and Ubuntu 18-22.
Best regards
-Klaus Keppler
Hallo,
ab sofort gibt es die Möglichkeit, PHP-FPM zusätzlich abzuhärten.
Die Pakete php-(VERSION)-opt-hardened können als Ergänzung zu den von uns bereitgestellten PHP-Versionen installiert werden z.B.:
apt install php-8.3-opt-hardenedDiese beinhalten ein sogenanntes Drop-In für die jeweiligen Systemd-Unit-Files, um den FPM-Pool-Manager mit zusätzlichen Einschränkungen laufen zu lassen. Das sind unter anderem:
Alle Einstellungen sind (inklusive Kommentaren und Verweis auf die jeweilige systemd-Dokumentation) unter /lib/systemd/system/php(VERSION)-fpm.service.d/10-sandbox.conf zu finden. Sollten einzelne Einstellungen im konkreten Fall Probleme machen, kann man diese durch ein zusätzliches Dop-In wieder überschreiben.
Bitte geben Sie uns Bescheid, falls Probleme oder unerwartete Einschränkungen im Betrieb auftauchen. Längerfristig planen wir, PHP-FPM standardmäßig mit diesen Beschränkungen auszustatten. Weitere Maßnahmen zur Erhöhung der Serversicherheit sind auch noch in Arbeit.
Die hardened-Pakete sind für PHP 5.6 - 8.3 unter Debian 10-12 und Ubuntu 18-22 verfügbar.
Viele Grüße
-Klaus Keppler
Dieses Feature wird definitiv über die Oberfläche kommen - in v3 ist das bereits vorbereitet.
In LiveConfig v2 werden wir das voraussichtlich nicht mehr backporten - bei Bedarf bitte kurz Kontakt mit support@liveconfig.com aufnehmen, dann gehen wir den "manuellen" Weg über Änderungen an der Datenbank durch.
Die Warnmeldung sollte inzwischen nicht mehr auftauchen, wir haben das "main"-Repository inzwischen mit dem neuen Key neu signiert.
Viele Grüße
-Klaus Keppler
Hallo,
für das "main"-Repository gab es schlichtweg noch keine Aktualisierungen, daher war das noch mit dem "alten" Key signiert.
Wir haben das eben aktualisiert, die Warnung sollte somit nicht mehr auftauchen.
Wir haben heute (15.03.2024) die Repositories auf den neuen Key umgestellt, da der alte Signaturschlüssel am 23.03.2024 abläuft.
Wir empfehen, das Paket liveconfig-keyring (wie oben verlinkt) zu installieren, dann werden die Signaturschlüssel künftig automatisch aktualisiert.
Viele Grüße
-Klaus Keppler
Zur Migration: prinzipiell möglich, die Anforderung hatten wir bislang noch nie. Das Vorgehen wäre:
- die SQLite-Datenbank (/var/lib/liveconfig/liveconfig.db) komplett entleeren (truncaten), nur das Datenbankschema (alle Tabellen, Referenzen etc.) muss erhalten bleiben
- aus MySQL nur die Daten exportieren (keine "CREATE TABLE"-Statements etc.)
- diese Daten dann in die SQLite-Datenbank einfügen.
Zum Archiv: nein, öffentlich steht so ein Archiv nicht bereit, aber wir haben hier alle jemals veröffentlichten Versionen archiviert. Bei Bedarf kurze Mail an support@liveconfig.com mit der benötigten Versionsnummer (und Plattform/Distribution).
Besteht das Problem immer noch?
Ein einfacher Neustart von LiveConfig dürfte genügen.
Das Problem tritt während Upgrades auf, wenn Apache gleichzeitig mit LiveConfig aktualisiert wurde, und das Apache-Paket noch nicht vollständig konfiguriert ist. Dann kann LiveConfig dieses Paket nicht erkennen, somit nicht herausfinden ob FastCGI und/oder FPM verfügbar sind - und peng.
Wir werden uns etwas einfallen lassen, wie wir diesen Zustand vermeiden können...
Hmm, das ist sehr merkwürdig - die mit diesem Schema hinzugefügten Datenbankeinträge dürfen eigentlich noch nicht existieren.
Bitte führen Sie mal folgende SQL-Abfragen aus und posten das Ergebnis, oder schicken es uns (support@liveconfig.com):
SELECT * FROM GROUPPERMISSIONS WHERE GP_MODULEID=2 AND GP_PERMISSIONID=1;
SELECT COUNT(*) FROM CUSTOMERPERMISSIONS WHERE CP_MODULEID=2 AND CP_PERMISSIONID=1;
SELECT COUNT(*) FROM USERPERMISSIONS WHERE UP_MODULEID=2 AND UP_PERMISSIONID=1;