Beim anlegen eines neuen Benutzers (Benutzer>Benutzerverwaltung>Benutzer hinzufügen) erhalte ich mit der aktuellen Preview folgenden Fehler
Danke für den Hinweis! Der Fehler basierte auf der neuen Funktion zum Erzwingen der Passwortänderung. Wir haben das eben behoben und in die automatischen Tests mit aufgenommen.
Ich habe alle Verträge umgestellt auf "tägliches rotieren" und "löschen nach einem Tag".
Allerdings werden damit nicht alle Logfiles im Kundenverzeichnis gelöscht.
Logrotate löscht nur dann alte Logfiles, wenn eine Rotation durchgeführt wird.
Wenn Sie eben erst auf tägliche Rotation umgestellt haben, kann es entsprechend bis zu 24 Std. dauern, bis logrotate die alten Logs löscht.
Interessant ist, dass die error.log nicht rotiert wurde, da sollte LiveConfig eigentlich auch konsequent sein. Werden wir gleich mal prüfen.
Meiner Ansicht nach, sollte bei der Anziege der Logfiles kein HTML Code ausgeführt werden.
Da sind wir der selben Meinung. 
Der Fehler ist bereits behoben, Update kommt gegen 11:00.
Hier ist die aktuelle Kompatibilitätsmatrix:
https://caniuse.com/#feat=input-datetime
ist es Absicht, dass es dort nur ein Textfeld gibt, ohne Tooltip (was muss man eintragen in welchem Format?)
Das ein "date"-Feld - eigentlich sollten alle zeitgemäßen Browser da automatisch ein Datums-Popup öffnen sobald man den Fokus auf das Feld setzt.
Aber ich denke, dass 99% der Kunden die Let'sEncrypt benutzen gerne auch einfach per Häkchen HSTS aktivieren möchten.
Dieser Einschätzung muss ich widersprechen.
Zitat"Bei jedem 0815-Massenhoster kann man dies im Backend einstellen" - so argumentieren einige unserer Kunden und nicht jeder kennt sich mit .htaccess usw. aus.
Auch das sehe ich anders. Wer sich nicht mal mit .htaccess auskennt, der sollte besser auch kein HSTS aktivieren. Sie glauben gar nicht, wie viele Probleme das bei unbedarften Benutzern verursacht.
Einfachstes Beispiel: WordPress "mal schnell" auf HTTPS umstellen und HSTS aktivieren. Das geht in 90% der Fälle grandios in die Hose (ach ja, man muss ja dann im WP-Backend noch die Basis-URL auf HTTPS ändern - das geht aber nicht, weil man sich nicht mal mehr anmelden kann, weil WP die internen URLs bis dahin alle noch mit HTTP erzeugt, was der Browser dann aber aus Sicherheitsgründen nicht mehr öffnen mag... ganz zu schweigen davon, dass bereits erzeugte (interne) Links im WordPress alle noch "hartcodiert" auf http:// stehen, was sich oft nur über mysqldump, suchen/ersetzen und MySQL-Import lösen lässt...)
Fazit: HSTS steht auf der Wunschliste (für Profi-Anwender), hat aber nicht die höchste Priorität.
Hallo,
ab sofort steht die Preview für LiveConfig v2.6.0 zum Download bereit.
Da es ziemlich viele Änderungen im "Unterbau" gab, waren Zwischen-Updates leider nicht möglich - die Release-Intervalle werden in den kommenden Updates wieder kürzer ausfallen.
Wir planen das offizielle Release von v2.6.0 für kommende Woche ein (also noch vor Pfingsten). Ein paar Kleinigkeiten fehlen noch (u.a. Übersetzungen), die kommen voraussichtlich nächsten Montag. Zudem ist noch ein Fehler bekannt, dass der lclogsplit-Dienst nach dem Update nochmal manuell neu gestartet werden muss (nur notwendig, wenn man NGINX durch LiveConfig verwalten lässt).
Das vollständige Changelog findet sich wie immer auf der Preview-Seite - neu ist diesmal auch eine Liste der Änderungen die automatisch während eines Upgrades durchgeführt werden.
Die wichtigsten Neuerungen sind:
Viele Grüße
-Klaus Keppler
PS: wegen des Brückentags ist unser Büro am Freitag, 11.05.2018 nicht besetzt, wichtige Tickets (support@liveconfig.com) werden aber bearbeitet.
Codetouch /etc/dovecot/deny.sieve chmod 0600 /etc/dovecot/deny.sieve chown dovecot /etc/dovecot/deny.sieve
Mit LiveConfig v2.6.0 ist das übrigens erledigt (die deny.sieve wird während des Upgrades ggf. automatisch angelegt, als Symlink auf die deny.imap).
So eine Funktion gibt es derzeit nicht, weil es schlicht serverseitig sehr komplex zu realisieren ist.
Einfachstes Beispiel: E-Mail. Die Mailverzeichnisse sind vertragsbezogen (/var/mail/<Vertrag>/<Postfach-ID>). Würde eine Domain in einen anderen Vertrag verschoben, dann müssen diese IDs geändert, die Datenbank aktualisiert und die /etc/dovecot/passwd angepasst werden.
Im schlimmsten Fall befände sich der Ziel-Vertrag dann noch auf einem anderen Server, weshalb dann alle Mails auch noch umkopiert werden müssten.
Wir haben das aber bereits auf der Wunschliste - irgendwann wird das auch gehen.
Wir haben das eben mit Chrome unter Android 7 getestet und dabei kein Problem feststellen können.
Haben Sie die Anmeldung schon mal mit einem anderen Browser unter Android 8 getestet?
LiveConfig speichert während der Anmeldung lediglich ein Cookie (zur Authorisierung) - vielleicht macht das ja Probleme? Ansonsten wird nirgendwo "gezaubert" oder externer Content nachgeladen - daher wundert es mich, dass die Anmeldung nicht funktioniert...
Das Log-Split-Tool (lclogsplit) ist mit v2.6 komplett neu - das kann dann u.a. auch Log-Einträge von NGINX und Apache in Echtzeit zusammenführen.
Was liefert denn ein "grep <Vertragsnummer> /etc/apache2/accesslog.map - verweisen da evtl. "fremde" Domains auf das betroffene Log?
Ist doch eigentlich schon beschrieben: in der LiveConfig-Datenbank den "gelöscht"-Status des Vertrags zurücksetzen:
UPDATE HOSTINGCONTRACTS SET HC_DELETED=0 WHERE HC_NAME="web28";Danach den Vertrag über die GUI erneut löschen (d.h. rechts oben in die Schnellsuche "web28" eingeben, den gefundenen Vertrag anklicken und löschen).
Wenn beim Löschen etwas schief geht, wird es eine Meldung in der /var/log/liveconfig/liveconfig.log geben.
Das Löschen geht eigentlich nur dann schief, wenn es ernste Probleme gibt (d.h. nicht löschbare Verzeichnisse o.ä., damit die nicht versehentlich "recycled" werden).
Am HTML können überhaupt keine Änderungen vorgenommen werden.
Die beigefügte HTML-Datei dient lediglich der Entwicklung und dem Test des eigenen CSS. Der eigentliche HTML-Code wird durch LiveConfig dynamisch erzeugt.
Wenn Sie etwas am HTML-DOM ändern müssen, dann wäre das über JavaScript (jQuery) möglich - einem eigenen Template können Sie ja auch eigenen JavaScript-Code beifügen.
Allerdings raten wir prinzipiell von so etwas ab, da Sie Ihr Template dann bei jedem LiveConfig-Update testen müssen (ob noch alles funktioniert).
Viele Grüße
-Klaus Keppler
Hello,
the PHP packages for Debian/Ubuntu were updated to version 5.6.36, 7.0.30, 7.1.17 and 7.2.5.
Additionally, the first PHP packages for Ubuntu 18.04 LTS are also available now. Within the next 2-3 weeks, these will be extended.
Best regards
-Klaus Keppler
Hallo,
die PHP-Pakete für Debian/Ubuntu wurden eben auf die Versionen 5.6.36, 7.0.30, 7.1.17 und 7.2.5 aktualisiert.
Außerdem stehen die ersten PHP-Pakete für Ubuntu 18.04 LTS nun auch bereit, in den nächsten 2-3 Wochen werden diese noch erweitert.
Viele Grüße
-Klaus Keppler
Hallo,
dieses Verhalten konnte nun aufgeklärt werden. Was passiert sein dürfte:
Beim Aktivieren von E-Mail in einem bestehenden Angebot wurden bislang automatisch für alle vorhandenen Domains mit leerem Hostnamen (also z.B. für "example.org", nicht aber für "www.example.org") nachträglich automatisch E-Mail mit aktiviert, sofern nur ein einziger Mailserver im System vorhanden war.
Das war gut gemeint (laut Changelog kam das sogar über einen Change Request erst nachträglich dazu), um beim nachträglichen Aktivierern von E-Mail im Angebot das nicht manuell für alle Domains aktivieren zu müssen.
Ab LiveConfig v2.6 gilt dieses Verhalten nicht mehr. Aktiviert man dann E-Mail nachträglich im Angebot, werden bestehende Domains grundsätzlich nicht modifiziert ("Prinzip der geringsten Überraschung"). Statt dessen wird es in Kürze möglich sein, mehrere (Sub-)Domains gleichzeitig zu bearbeiten und somit E-Mail bequem für mehrere Subdomains einzuschalten.
Wir werden das auch entsprechend in die Dokumentation mit aufnehmen.
Viele Grüße
-Klaus Keppler
Dann hoffen wir mal, dass "<>" genauso wenig Probleme macht wie <MAILER-DAEMON@$hostname>.
Zumindest ist das im RFC eindeutig geregelt (der bisherige Weg von Postfix, dort nur den unqualifizierten Namen "MAILER-DAEMON" einzutragen, ist technisch betrachtet falsch - hatte aber natürlich auch seine Gründe).
ZitatWird die master.cf automatisch neu generiert oder müssen wir das wieder einmal auf unserer großen Zahl an servern überall manuell anstoßen?
(gut, für die recipient delimiter Änderung müssen wir das vermutlich sowieso, ich tippe die wird default off sein)
null_sender soll während des Upgrades automatisch geändert werden (steht dann auch so im Changelog), recipient_delimiter ist eine Feature-Änderung die wir nicht automatisch aktivieren ("Prinzip der geringsten Überraschung"). Längerfristig soll das über CLI möglich sein - aber erst eins nach dem anderen...
Ich möchte das Thema noch mal kurz aufgreifen. Ein Anwender hat uns darauf hingewiesen, dass das RFC 5321 ganz klar für Fehlermeldungen einen leeren Absender (<>) erfordert:[INDENT]If there is a delivery failure after acceptance of a message, the receiver-SMTP MUST formulate and mail a notification message. This notification MUST be sent using a null ("<>") reverse-path in the envelope. The recipient of this notification MUST be the address from the envelope return path (or the Return-Path: line).
[/INDENT]
LiveConfig wird ab v2.6 also die "null_sender"-Option in der master.cf (beim pipe-Befehl) auf einen leeren Wert setzen und nicht auf MAILER-DAEMON@$hostname.
Viele Grüße
-Klaus Keppler
Daher ist mein Feature-Request, dass man per Setting ggf. die Berechnungsart ändert kann, z.b. auf "du".
Ich verstehe Ihr Problem, allerdings ist Quota nunmal genau dafür gedacht (und optimiert), den Speicherverbrauch jederzeit mitzuprotokollieren und zu prüfen. "du" ist da eher eine Dampfwalze (mit massivem I/O) und etlichen Einschränkungen.
Ein Workaround um ein "ordentliches" Quota herum ist nicht geplant.
ZitatOder gibt es die Möglichkeit, dass ich per Shellskript selber die Werte berechne und an eine API weiterreiche? Das würde mir auch schon reichen.
Nein, eine Quota-API (zum Schreiben) gibt es nicht. LiveConfig verwaltet die Werte intern in Round-Robin-Tabellen (RRA_DISK/RRD_DISK). Die könnten *theoretisch* auch "extern" befüllt werden, das ist aber alles andere als trivial, und wir können dazu keinen Support geben (schließlich *gibt* es mit Quota ja eine äußerst schlanke, schnelle und zuverlässige Lösung).
Wenn der Hoster Virtuozzo einsetzt, kann er mit wenig Aufwand Quota für die VPS-Instanz aktivieren. Ansonsten gibt es auch viele andere vServer-Anbieter, die auf einer anderen technischen Plattform arbeiten und aufgrund eines höheren Abstraktionsgrades auch eigene Kernel (und somit Quota) erlauben.
Viele Grüße
-Klaus Keppler