Also bei mir hats einiges zerschossen. Was kann ich nun machen, damit Live Config wieder rund läuft?
Das Problem ist meistens, dass wenn LiveConfig zusammen mit vielen anderen Paketen aktualisiert wird, LiveConfig zu einem "ungünstigen" Zeitpunkt neu gestartet wird während die anderen Pakete (Postfix, Dovecot usw.) gerade aktualisiert und somit nicht durch LiveConfig erkannt werden.
Starten Sie LiveConfig einfach noch mal neu, dann sollten wieder alle Dienste da sein.
Hier ist ein kleiner Workaround, um den Massen-Austausch von Zertifikaten etwas zu vereinfachen:
Mit folgendem SQL-Befehl (in der LiveConfig-Datenbank) kann man sich alle Verträge anzeigen lassen, in welchen SSL erlaubt ist:
SELECT HC_NAME
FROM HOSTINGCONTRACTS LEFT JOIN HOSTINGPLANS ON (HC_PLANID=HP_ID)
WHERE HC_SSL > 0 OR HP_SSL > 0Mit folgendem SQL werden all diese Verträge "markiert", so dass diese beim nächsten Neustart von LiveConfig automatisch neu konfiguriert werden (soll heißen: die vHost-Konfigurationen dieser Verträge werden neu geschrieben):
UPDATE HOSTINGCONTRACTS SET HC_REFRESHCFG=2824
WHERE HC_ID IN (
SELECT HC_ID FROM HOSTINGCONTRACTS LEFT JOIN HOSTINGPLANS ON (HC_PLANID=HP_ID) WHERE HC_SSL > 0 OR HP_SSL > 0
)Anschließend muss LiveConfig neu gestartet werden; nach wenigen Sekunden sind die entsprechenden vHost-Configs aktualisiert. Bei Multi-Server-Installationen reicht ein Neustart des LiveConfig-Servers (man muss also nicht alle lcclients neu starten).
Mit dem nächsten Update wird es einfacher, ein aktualisiertes Zertifikat auch zu übernehmen (sowohl für mit SSL konfigurierte Dienste als auch in Hostingverträgen).
Viele Grüße & ein schönes Wochenende
-Klaus Keppler
Prüfen Sie bitte diesen Hinweis - vielleicht wurde IPv6 aktiviert?
Die Log-Meldung ist leider etwas zu kurz - da müsste noch mehr stehen (nach dem "Server configuration problem;").
Da LiveConfig nichts an der Postfix-/Postgrey-Konfiguration ändert, steht dies wohl auch nicht in einem direktem Zusammenhang mit dem LiveConfig-Update. Vielleicht lief nur einfach der Postgrey-Dienst nicht?
Diese Frage kann ich Ihnen leider nicht beantworten - aber wenn Sie LiveConfig aktualisieren, hat das absolut keinen Einfluss auf Apache. Es wird nichts an der Konfiguration geändert, Apache wird nicht einmal neu gestartet.
Das hat nichts mit LiveConfig zu tun, sondern ausschließlich mit Apache/mod_fcgid.
Diese Daten werden mit dem (Neu-)Start von LiveConfig aktualisiert.
Was wird denn mit "liveconfig --diag" im Abschnitt "MEMORY:" angezeigt?
Bitte führen Sie ggf. noch das Update auf v1.7.2-r2825 aus (in der vorhin freigegebenen r2824 gab es teilweise noch Fehler während des Upgrades, so dass der Lua-Teil nicht startete)
Kurzer Nachtrag: v1.7.2-r2825 wurde eben bereitgestellt. Bei r2824 kam es bei manchen Servern während dem Upgrade zu einem Fehler (im LiveConfig-Log erschien dann die Meldung "LC.liveconfig.updateSysconfig() failed ...").
Wer bereits r2824 eingespielt hatte, sollte am besten das Update auf 2825 auch noch durchführen.
Ab sofort steht LiveConfig v1.7.2 (r2824) zum Download bereit.
Neben einigen neuen Funktionen und Fehlerbeseitigungen wurde vor allem die in LiveConfig integrierte OpenSSL-Bibliothek von v1.0.1f auf v1.0.1g aktualisiert.
Hintergrund ist die am 07.04.2014 bekannt gewordene Sicherheitslücke in OpenSSL (CVE-2014-0160, derzeit unter dem Namen "Heartbleed" bekannt).
Wir empfehlen daher allen Nutzern von LiveConfig, ihre Server schnellstmöglich zu aktualisieren.
Wenn Sie LiveConfig mit einem automatisch erstellten, selbst-signierten Zertifikat genutzt haben, löschen Sie dieses bitte (/etc/liveconfig/sslcert.pem) und starten LiveConfig anschließend neu - es erzeugt dann automatisch ein neues Zertifikat, welches Sie in Ihrem Browser erneut akzeptieren müssen.
Hintergrundinformation zu dem OpenSSL-Fehler:
Die entdeckte Schwachstelle erlaubt es, beim Aufbau einer TCP-Verbindung zu einer von dem Fehler betroffenen Software, aus deren Arbeitsspeicherbereichen bis zu 64kB Daten auszulesen. Dieser "Datenabruf" kann beliebig oft wiederholt werden, ist serverseitig praktisch nicht zu erkennen und ermöglicht es so, Teile des Anwendungsspeichers auszulesen. Dort sind insbesondere die für die Nutzung von SSL notwendigen privaten Schlüssel (Private Keys) unverschlüsselt abgelegt (diese werden ja für die Kommunikation benötigt).
Aus diesem Grund ist davon auszugehen, dass bislang mit OpenSSL 1.0.1 verwendete private Schlüssel nicht mehr sicher sind. Alle Zertifikate, für welche ein solcher Schlüssel verwendet wurde, sollten daher durch die ausgebende Zertifizierungsstelle (CA) zurückgerufen ("revoke") und neu ausgestellt ("re-issue") werden!
Die privaten Schlüssel können ansonsten dazu verwendet werden, abgegriffenen Datenverkehr zu decodieren (auch wenn OpenSSL nun zwischenzeitlich aktualisiert wurde).
Ob oder in welchem Umfang tatsächlich private SSL-Schlüssel aufgrund dieses Softwarefehlers ausgelesen werden konnten ist derzeit noch unklar.
Weitere Informationen zu dem Fehler finden Sie u.a. in einem Beitrag auf Heise Online:
Der GAU für Verschlüsselung im Web: Horror-Bug in OpenSSL
Eine neue Version wurde bereits compiliert, läuft eben durch die letzten Tests und geht in den nächsten Minuten online. Alle Kunden werden zudem per Rundmail informiert.
Eine neue Version wurde bereits compiliert, läuft eben durch die letzten Tests und geht in den nächsten Minuten online. Alle Kunden werden zudem per Rundmail informiert.
Das ist nur eine Warnmeldung und keine Fehlermeldung; die Wildcard-Subdomain müsste ja soweit funktionieren, oder?
Dann können Sie die Warnmeldung auch getrost ignorieren.
Welche Distribution genau verwenden Sie?
Was liefert der Befehl "apache2ctl -S -t" unmittelbar nach dem Neustart?
Die unter /etc/apache2/sites-available/default erzeugte Konfiguration gilt immer für den Standard-vHost (also alle Fälle, wo kein anderer Name zutrifft).
Für Ihren Fall legen Sie einfach im LiveConfig in irgendeinem Vertrag die Domain "webvation.de" an, und darunter die Subdomain "*". Dieser können Sie dann Ihr Wildcard-SSL-Zertifikat zuweisen.
Viele Grüße
-Klaus Keppler
mod_geoip kann man nicht in LiveConfig einbinden 
weil LiveConfig nichts mit PHP oder PHP-Modulen zu tun hat.
Installation von mod_geoip erfolgt so wie es auf der jeweiligen Distribution üblich ist (unter Debian z.B. "aptitude install php5-geoip"). Ggf. Apache danach neu starten (damit alle FastCGI-Prozesse und/oder mod_php-Instanzen das neue Modul "sehen").
Ein neue Preview-Version steht bereit (v1.7.2-r2791):
Viele Grüße
-Klaus Keppler
Geben Sie in das Feld "Absenderadresse" (bei der Box "E-Mail-Einstellungen") einfach eine gültige Mailadresse ein. 
(derzeit werden alle Eingaben in diesem Formular - also sowohl das Logo als auch alle anderen Einstellungen - gleichzeitig geprüft und gespeichert)
Welche LiveConfig-Version hatten Sie denn im Einsatz, als LC beim Backup abgestützt ist?
Mit der aktuellen Version (v1.7.1-r2775 vom 10.03.2014) wurde ein Fehler in diesem Zusammenhang behoben.
LiveConfig unterstützt auch mpm_itk. Installieren Sie einfach das mpm_itk-Modul für Apache und konfigurieren die Webspaces mit mod_php.
Das Sicherheitsmodell von suPHP erlaubt definitiv keine "gemeinsamen" Verzeichnisse; mit FastCGi sollte das aber im Prinzip schon klappen. Achten Sie ggf. darauf, dass das gemeinsame Verzeichnis im open_basedir auch freigegeben ist.