Beiträge von kk

Zitat von leonex

* 5.6 existiert ja schon als Multi PHP, muss das runter oder kann man dann zwischen 5.6 Debian und 5.6 aus /opt wählen?

Das php-5.6-opt kann installiert bleiben - dann kann man tatsächlich zwischen der "neuesten" PHP 5.6-Version (aktuell 5.6.36) und der von der Distribution bereitgestellten Version wählen.

Zitat

* Nutzen alle, die 5.4 (Standard) eingestellt haben dann automatisch 5.6?

Ja.

Zitat

* * Nutzen die vor allem auch dann 5.6 (wenn vorher 5.4), wenn ich via Multi PHP in /opt beim Upgrade ein 5.4 mit installiere?

Ja. Wenn jemand die "Standardversion" nutzt, dann ist das immer die, die mit dem Code "php5" verknüpft ist. Es schadet auch gar nicht, Kunden mit neueren PHP-Versionen zu "zwangsbeglücken" - sonst laufen die noch ewig auf Alt-Versionen weiter.

Zitat

Reicht ein lcclient neustart dann aus, damit er evtl die Configs neu schreibt?

Die FastCGI-Starter-Scripte müssen eigentlich nicht neu geschrieben werden. Wenn Sie das aber erzwingen möchten, ändern Sie z.B. etwas am Namen einer IP-Gruppe (dadurch werden alle vHosts neu geschrieben)

Zitat

Leider habe ich zum Thema Server Upgrade nichts im Handbuch gefunden.

Debian 7 auf 8 ist relativ einfach, da gab es eine sehr großen Änderungen. Beim Upgrade von Debian 8 auf 9 sieht das anders aus - dafür haben wir im Wiki eine Seite vorbereitet: https://www.liveconfig.com/wiki/de/upgrade/debian

Handelt es sich um einen Vertrag den Sie unter "Mein Hosting" angelegt haben, oder für einen Kunden?
Nutzen Sie die aktuelle LC-Version (2.5.3)?
Wurde das betroffene Postfach (relativ) neu angelegt, oder vielleicht mit einer älteren LiveConfig-Version? (früher gab es da mal den Fehler, dass die Übersetzungen nicht übernommen wurden)
In /etc/postfix/spamassassin sind die Spam-Präfixe pro Postfach hinterlegt (wird aber ggf. durch LiveConfig überschrieben - manuelle Änderungen darin sind also nicht dauerhaft).

Zitat von TCRserver

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.

Zitat von Mogwais

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.

Zitat von kk

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.

Zitat von antondollmaier

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?

Zitat von TCRserver

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.

Zitat von TCRserver

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.

Zitat von TCRserver

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.

Zitat von TCRserver

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

Zitat von aziegler

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.

Zitat von pitgrap

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.

Zitat von Mogwais

Die Frage ist ja wann es kommt?

Preview jetzt, Release kommende Woche.

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:

• die Änderung des Passworts kann nach der nächsten Anmeldung erzwungen werden
• Autoresponder kann nun automatisch zu einem bestimmten Termin beendet werden
• lclogsplit wurde komplett überarbeitet - nun werden auch NGINX-Logs in Echtzeit erzeugt (und ggf. mit Log-Einträgen von Apache zusammengeführt)
• unsere zusätzlichen PHP-Versionen für Debian/Ubuntu werden nun automatisch in LiveConfig registriert (siehe /etc/liveconfig/lua.d/) - die LC.web.addPHP-Aufrufe in /usr/lib/liveconfig/lua/custom.lua sind somit nicht mehr notwendig
• Unterstützung von Ubuntu 18.04 LTS
• AutoConfigure unterstützt nun auch iOS-Geräte (dazu die URL /liveconfig/hosting/mobileconfig aufrufen) - Details/Doku folgen noch...
• optional kann nun eine Webmail-URL hinterlegt werden (Serververwaltung -> E-Mail -> Dovecot), die dann bei den Postfacheinstellungen mit angezeigt wird
• unter Kunden -> Kontakte wird nun in der letzten Spalte angezeigt, bei wie vielen Verträgen oder Benutzern ein Kontaktdatensatz noch verwendet wird. Nach dieser Spalte kann auch sortiert werden - somit kann man ungenutzte Kontaktdaten bequem identifizieren und löschen (Bulk-Delete ist geplant)

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.

Zitat von aziegler

Code

touch /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).