Beiträge von kk

Zitat von robert

Das Problem besteht leider auch immer noch mit der Version:

Client: LiveConfig 2.6.0-r4957
Betriebssystem: CentOS Linux release 7.5.1804 (Core)

Könnten Sie bitte die zwei folgenden SQL-Befehle in der MySQL-Datenbank ausführen und uns die Ausgabe an support@liveconfig.com schicken?

SELECT * FROM INTERFACES;
SELECT * FROM IPS;

Auf dem betroffenen Server kommt vermutlich "biosdevname" zum Einsatz (evtl. ein DELL-Server?). Wir können das Verhalten noch immer nicht reproduzieren, es aber zumindest eingrenzen. Interessant wäre daher, welche Interfaces und ggf. mehrfache IPs genau in der Datenbank stehen.

Zeigen denn auch wirklich beide Domains auf die selbe IP-Adresse (sprich: auf Ihren Server)?
Löschen Sie sonst einfach noch mal das nicht erfolgreich erstellte SSL-Zertifikat, und beauftragen erneut ein Lets-Encrypt-Zertifikat.

Dass es gar keine Meldungen gibt, gibt es nicht (außer die Domain zeigt plötzlich nicht mehr auf Ihren Server).

Senden Sie mal eine Testmail an irgendeine lokale Adresse und schicken uns *alle* Meldungen (ggf. per Mail an support@liveconfig.com), die in dem Zeitraum der Zustellung in /var/log/mail.log auftauchen. Da wird definitiv etwas drin stehen...

Viele Grüße

-Klaus Keppler

Zitat von bash

Müsste laut DSGVO es sowieso nicht so sein das es KEINE normalen HTTP Seiten mehr geben darf? Weil ab 25. Mai herrscht doch SSL Pflicht...?

Das ist zum Glück absoluter Unfug.
Es kommt immer darauf an, was für Daten übertragen werden. Sensible Daten müssen schon immer geschützt werden (auch schon vor dem 25.05.2018). Wer seine privaten Katzenbilder online stellt oder z.B. nur eine "Visitenkarte" seiner Firma, der braucht keine Verschlüsselung.

Wir haben das LiveConfig-Meta-Paket eben auf die Version 0.5.7 aktualisiert, damit ist der Fehler bei Neuinstallationen behoben.

(bei bestehenden Installationen wird dieses Paket zwar auch aktualisiert, führt allerdings keine Aktionen aus)

Die Preview wurde soeben noch einmal aktualisiert (v2.6.0-r4957). Damit werden die in diesem Thread gemeldeten Probleme sowie andere während unserer Tests aufgefallene Fehler beseitigt.

Insbesondere werden während des Upgrades alle vHost-Konfigurationen neu erzeugt, um die Logrotate-Konfigurationen neu zu schreiben (die sind künftig in /etc/logrotate.d/liveconfig-vhosts).

Viele Grüße

-Klaus Keppler

Wenn ich das richtig verstanden habe, ist einmal Server1 der Master und Server2 der Slave, und für andere Domains genau anders herum (Server2 ist Master und Server1 ist Slave)?

Dann dürfte dort das Problem liegen... wenn ich mich richtig erinnere wird nur ein TSIG-Schlüssel pro Zielserver unterstützt - da in diesem Fall zwei "Verbindungen" konfiguriert sind, klappt nur eine davon.
Das ist ein Szenario, das ich aber ehrlich gesagt noch nie gesehen habe und auch den Sinn darin nicht erkennen kann. Wir müssten mal prüfen, wie LiveConfig in diesem Fall die richtigen Schlüssel konfigurieren müsste...

Daher vorab: was ist der Sinn dahinter? Der gesamte Betrieb ist erheblich einfacher, wenn Sie *einen* Master und (mind.) *einen* Slave haben, und diese Rollen nicht wechselweise ändern...

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.