Beiträge von kk

Hello,

we're happy to announce that LiveConfig v2.6.0 is ready for download.

The most important changes are:

• supporting Ubuntu 18.04 LTS
• full access.log support for NGINX, including live statistics and merging with Apache access.log
• added option to force change of LiveConfig password on next login
• automatically registering additional PHP packages installed from LiveConfig repository (Debian/Ubuntu) - no need to create/modify custom.lua (/etc/liveconfig/lua.d/*.lua)
• auto-configuration of e-mail settings for Apple iOS devices (/liveconfig/hosting/mobileconfig)
• contact data can now be edited directly (without prior searching)
• easy searching for unused contact data

... as well as many minor improvements, see the full changelog for all details.

Actions while upgrading from previous LiveConfig installations:

• all Apache and NGINX vHosts are reconfigured, to get NGINX domain names into /var/lib/liveconfig/accesslog.map and to update all log rotation settings
• the CustomLog directive in /etc/apache2/conf-available/liveconfig.conf respective /etc/httpd/conf.d/99_liveconfig.conf is changed (new parameters for lclogsplit call)
• the file /etc/apache2/accesslog.map is moved to /var/lib/liveconfig/accesslog.map
• the setting for Dovecot in /etc/postfix/master.cf is modified (null_sender= is inserted), then Postfix is restarted
• if NGINX is used, lclogsplit is additionally installed as service
• the file /etc/logrotate.d/liveconfig is renamed to /etc/logrotate.d/liveconfig-vhosts (log rotation of vHosts then separated from settings for LiveConfig log files)

Hallo,

ab sofort steht LiveConfig in der Version 2.6.0 zum Download bereit.

Die wichtigsten Neuheiten und Änderungen sind:

• Unterstützung von Ubuntu 18.04 LTS
• volle access.log-Unterstützung für NGINX, inklusive Echtzeit-Statistiken und Zusammenführung mit Apache access.log
• die Änderung von LiveConfig-Passwörtern kann bei der nächsten Anmeldung erzwungen werden
• vereinfachte (automatische) Registrierung von unseren PHP-Paketen für Debian/Ubuntu (keine Anpassung der custom.lua mehr notwendig)
• E-Mail-Autokonfiguration für iOS (iPhone/iPad) möglich (via /liveconfig/hosting/mobileconfig)
• Kontaktdaten können nun direkt bearbeitet werden (ohne vorherige Suche nach dem jeweiligen Kontakt)
• einfaches Finden ungenutzter Kontaktdatensätze

... sowie viele kleinere Verbesserungen - die vollständige Liste findet sich wie immer im Änderungsverlauf.

WICHTIG: während eines Upgrades von älteren LiveConfig-Installationen finden folgende Aktionen statt:

• alle Apache- und NGINX-vHosts werden rekonfiguriert, um die NGINX-Domainnamen in /var/lib/liveconfig/accesslog.map aufzunehmen und die Logrotate-Einstellungen zu aktualisieren
• die CustomLog-Anweisung in /etc/apache2/conf-available/liveconfig.conf bzw. /etc/httpd/conf.d/99_liveconfig.conf wird geändert (andere Parameter für lclogsplit-Aufruf)
• die Datei /etc/apache2/accesslog.map wird nach /var/lib/liveconfig/accesslog.map verschoben
• in der Datei /etc/postfix/master.cf wird der Eintrag für Dovecot modifiziert (null_sender= wird eingefügt) und Postfix anschließend neu gestartet
• falls NGINX genutzt wird, dann wird lclogsplit zusätzlich als Service eingerichtet und gestartet
• die Datei /etc/logrotate.d/liveconfig wird in /etc/logrotate.d/liveconfig-vhosts umbenannt (Log-Rotation der vHosts somit getrennt von den Einstellungen für LiveConfig-eigene Logs)

Zitat von dicker

ist die Anleitung https://www.liveconfig.com/de/…tml#server.database.mysql noch aktuell?

Ja, die ist noch aktuell.
Wenn es einen Fehler bei gunzip gibt, dann liegt das Problem ganz wo anders. Eigentlich ist "No such file or directory" doch eine sehr eindeutige Fehlermeldung...

Kommt drauf an was das für "eigene" Mailserver sind. Wenn die ordentlich betrieben & gepflegt werden, könnte man die durchaus in die DNSWL aufnehmen: https://www.dnswl.org/?page_id=87
Es ist auch kein Hexenwerk, auf einem eigenen DNS-Server eine eigene DNS-Whitelist anzulegen.

Die Preview wurde eben auf v2.6.0-r4971 aktualisiert:

• erzwungene Passwortänderungen wurden erst nach Ab-/Anmeldung übernommen
• unter "Kunden" -> "Kontakte" wird nun in einem separaten Tab angezeigt, bei welchen Objekten der betroffene Kontakt verwendet wird (Benutzer & Kunden)

Wir rollen die neue Version derzeit auf allen unserer Systemen aus - wenn nichts dazwischen kommt, soll am Montag (11.06.) das Release erfolgen.

Zitat von Falkone

Was bissel nervt ist, das das Feld "Benutzername" beim Anlegen einer Datenbank oft zu kurz ist... (nur 16 Zeichen)

Diese Einschränkung stammt nicht von uns - MySQL erlaubt bis Version 5.7.8 maximal 16 Zeichen (ab 5.7.8 sind das immerhin 32 Zeichen).
Da es schwer abzubilden ist, abhängig von der installierten Datenbankversion verschieden lange Benutzernamen zu realisieren, bleibt diese Einschränkung vorerst erhalten.

Zitat

Warum kann man im Benutzernamen keinen Punkt verwenden??? erz.de statt erz-de

Was für Benutzernamen genau meinen Sie? Datenbankbenutzer?
LiveConfig-Benutzer können jedenfalls einen Punkt enthalten.

Zitat

Ich habe die Benutzernamen bisher IMMER gleich dem Domainnamen gewählt...

Das ist aus Sicherheitsgründen nicht zu empfehlen. Aus technischen Gründen können Benutzer *immer* auf die Datei /etc/passwd zugreifen. In diesem Fall sieht man also ohne weiteren Aufwand, welche Domains noch so auf diesem Server gehostet sind, was einen möglichen Angriff erheblich vereinfachen kann.
Es hat durchaus seinen Grund, warum "anonyme" Benutzernamen (web###) empfohlen werden.

Für Benutzernamen auf Linux-Systemen gibt es übrigens auch verschiedene Einschränkungen was Länge und erlaubte Zeichen betrifft.

Sie haben das Paket "ca-certificates" nicht installiert.

Die Preview wurde eben auf v2.6.0-r4964 aktualisiert - diese ist nun "Release Candidate".

WICHTIG: wer die Preview vom LiveConfig-Client (lcclient) installiert hatte, muss bitte prüfen, ob die Dateien /etc/logrotate.d/liveconfig und /etc/logrotate.d/liveconfig-vhosts existieren.
Wenn JA, dann bitte die Datei /etc/logrotate.d/liveconfig löschen.

Zitat von lebenszeit

Dürfen wir erfahren was das Problem ist?

Ja:

Zitat

wenn NGINX und Apache gleichzeitig laufen, und Log-Daten von Apache an die Daemon-Instanz von lclogsplit durchgereicht werden, das System unter hoher Last steht und daher nicht alle Daten sofort verarbeiten kann

Anders formuliert: wenn Apache und NGINX gleichzeitig laufen und das System unter hoher Last steht (insbes. I/O-Last), dann werden Log-Einträge vom Apache nicht schnell genug abgearbeitet und können somit verloren gehen.

Zitat von sTeaLth

Jetzt wartet doch mal ab, Pfingsten ist doch erst am 09.06.2019

Uns ist derzeit ein Problem in der Komponente "lclogsplit" bekannt (wenn NGINX und Apache gleichzeitig laufen, und Log-Daten von Apache an die Daemon-Instanz von lclogsplit durchgereicht werden, das System unter hoher Last steht und daher nicht alle Daten sofort verarbeiten kann).
Das ist aus unserer Sicht ein "Showstopper", und der wird noch behoben.

Auch wenn es schwierig ist zu warten (wir haben da vollstes Verständnis): so lange uns akute Probleme bekannt sind, macht es keinen Sinn, das Release zu machen.
Aufgefallen ist dieses Problem übrigens während des schrittweisen Roll-Outs von v2.6 im Produktivbetrieb.

Vielen Dank - das hilft uns schon weiter!

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