Beim anlegen oder ändern eines Postfachs scheint die deutsche Übersetzung nicht korrekt zu funktionieren.
Einige Übersetzungen waren in dieser Preview noch nicht mit drin (aufgrund einer Änderung an unserer Übersetzungs-Infrastruktur gab's da leider ein paar Verzögerungen). Ist inzwischen aber schon aktualisiert.
Da der Zeitpunkt(Juli) näher rückt ab dem Chrome vor unverschlüsselten Seiten generell warnt wollte ich nochmal anregen die Basic Version zumindest so zu gestalten das sie wenigstens Lets Encrypt Zertifikate unterstützt.
Ich sag's mal so: da wird was kommen. Details folgen aber erst wenn's so weit ist.
So etwas darf eigentlich nicht passieren. Gibt's Auffälligkeiten in /var/log/liveconfig/liveconfig.log (bzw. lcclient.log)? War die /etc/logrotate.d/liveconfig *komplett* leer, oder nur ohne vHosts?
Die Frage hat sich erledigt - wir haben den Fehler gefunden. Für die Rotation der LiveConfig-eigenen Dateien (/var/log/liveconfig/*) wurden auch Regeln angelegt, was dazu führen konnte, die bestehende logrotate-Datei zu überschreiben. Wird eben behoben, und während des Upgrades wird die logrotate-Datei dann neu erzeugt.
Nach dem Upgrade gingen bei uns bei einigen Servern die Logrotate-Regeln verloren, die Datei war schlichtweg leer.
So etwas darf eigentlich nicht passieren. Gibt's Auffälligkeiten in /var/log/liveconfig/liveconfig.log (bzw. lcclient.log)? War die /etc/logrotate.d/liveconfig *komplett* leer, oder nur ohne vHosts?
Hab ich vergessen zu schreiben, die Umstellung der Lösch-Regeln erfolgte am Sonntag.
Somit sollte heute Morgen alles durchrotiert sein.
Kommt u.a. darauf an, wann genau logrotate gelaufen ist (wird ja über /etc/cron.daily/ ausgeführt).
Sie könnten ggf. mal "logrotate -d | less" laufen lassen und schauen, was für webh_158 dabei gemeldet wird.
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