Beiträge von kk

    Bitte starten Sie LiveConfig neu - dabei sollten auch "hängende" Jobs (DB löschen etc.) wieder abgearbeitet werden.
    Wir arbeiten bereits an der Behebung des Fehlers, ein Update sollte dann kurzfristig verfügbar sein (in dem o.g. Fall hat der Client-Prozess die Verbindung zum Server-Prozess verloren - in der nächsten Version ist ein Watchdog enthalten, der solche Situationen automatisch erkennt und versucht zu lösen, unabhängig von der Fehlerursache)


    Viele Grüße


    -Klaus Keppler

    Was für ein Update haben Sie denn durchgeführt (welche Distribution / welche Versionen?)
    Wenn Sie beispielsweise ein Debian-Upgrade durchführen und bei Apache Änderungen in der Konfigurationsdateien vorgeschlagen werden, dann haben Sie immer die Möglichkeit, diese Änderungen (durch Debian) nicht durchführen zu lassen.


    Zum Apache: gehen Sie im LiveConfig auf Serververwaltung -> Web, öffnen eine IP-Gruppe (z.B. "default") und klicken in diesem Popup einfach gleich auf den "Speichern"-Button. Damit wird die default.conf neu geschrieben.


    Die mit LiveConfig eingerichteten Websites (web1, ...) sollten eigentlich normal funktionieren - LC erstellt schließlich "nur" eine vHost-Konfiguration in z.B. /etc/apache2/sites-available/web1.conf - ein Apache-Upgrade dürfte da nichts zerschießen können (Ausnahme: Sie haben Apache mit der "purge"-Option komplett entfernt und anschließend neu installiert?)
    In diesem Fall öffnen Sie einfach in jedem Hosting-Vertrag jeweils *einmal* irgendeine Domain-Einstellung (Hosting -> Domains) und klicken in diesem Popup auf "speichern" - dann wird auch diese vHost-Konfiguration neu geschrieben.


    Zitat

    Und auch, dass man Dienste wieder nicht mit LC verwalten kann.


    Ist bereits beides in Planung (ein "Panic-Button" zur Neuerzeugung aller Konfigurationen sowie die Deaktivierung der Verwaltung einzelner Dienste).


    Viele Grüße


    -Klaus Keppler

    Nein, die Daten werden leider nirgendwo zwischengespeichert - erst wenn man auf "speichern" klickt.
    (Zwischenspeichern ist auch nicht ganz trivial: wer am Ende auf "abbrechen" klickt will natürlich nicht, dass die vorherigen Daten bis dahin überschrieben wurden)


    Die meisten CAs bieten die Möglichkeit, ein Zertifikat kostenlos neu ausstellen zu lassen ("re-issue"). Sollte das bei Ihnen nicht möglich sein, dann empfehlen wir einen anderen Anbieter. ;) (z.B. http://www.psw.net)


    Mit freundlichen Grüßen


    -Klaus Keppler



    PS: wir werden beim Popup noch eine Sicherheitsabfrage einbauen, die vor dem Schließen des Fensters nachfragt, ob man seine Änderungen wirklich nicht speichern möchte (#93)

    Ein interessanter Vorschlag...
    Grundsätzlich schließt man dabei aber auch den Versand in den Fällen aus, in denen ein Kunde z.B. seine GMX-Adresse als Absenderadresse verwendet (außer man ließe in LiveConfig auch noch "sonstige erlaubte Absenderadressen" mit pflegen).


    In der Implementierung ist das aber mit ein bisserl Arbeit verbunden, weil LiveConfig ja erst noch die Map-Datei erzeugen müsste (Absenderadresse <-> SASL-Benutzer).


    Ich denke, wir können das durchaus als Option mit aufnehmen (kann man dann bei der Postfix-Konfiguration wahlweise aktivieren); ein entsprechendes Feature-Ticket mache ich gleich auf. Bis wann das umgesetzt sein wird, kann ich aber noch nicht abschätzen.

    Jein; das Verzeichnis "conf" sollte dabei nicht mit verschoben/kopiert werden.


    Am besten wäre also:
    1. mv .../web1/htdocs .../web1bck
    2. mv .../web100/htdocs .../web1/
    3. chown -R ...


    Prüfen Sie danach noch, ob der alte Verzeichnisname (web100) noch irgendwo in den Dateien enthalten ist (z.B. in Konfigurationdateien usw) - am besten mit find & grep

    Hallo,


    welche LiveConfig-Version genau setzen Sie ein?
    Im Nachhinein kann man leider nicht mehr herausfinden was genau da passiert ist. Wir werden sicherheitshalber mal eine Anleitung zusammenstellen, wie man einen Core-Dump erzeugen kann, mit dem wir dann noch mal nachträglich solche Probleme analysieren können.


    Mit v1.6.3 (r2383) gab es einige Verbesserungen - u.a. auch in der Event-Schleife, welche eventuell zu dem oben beschriebenen Problem geführt hat.


    Viele Grüße


    -Klaus Keppler

    Hallo,


    können wir hier mit Ubuntu 10.04 nicht reproduzieren. Ich tippe darauf, dass eventuell irgendwas beim LiveConfig-Prozess klemmt?
    Bitte beenden Sie LiveConfig vollständig, starten es dann neu und prüfen dann, ob Apache noch immer keine Änderungen übernimmt.
    In der künftigen Version 1.6.4 erkennt LiveConfig automatisch, falls im Client-Prozess was nicht stimmt, und versucht das Problem ebenfalls automatisch zu lösen.


    Viele Grüße


    -Klaus Keppler

    Hallo,


    ich habe eben mal auf einen Kundenserver bei uns geschaut, bei dem wir vor einiger Weile den ZendGuardLoader aufgesetzt hatten. Dort läuft alles völlig problemfrei, auch nach einem Apache-Reload.
    Es handelt sich um einen dedizierten Server mit Debian Squeeze (AMD64), aktuellem PHP (via suPHP und FastCGI).
    Der ZendGuardLoader ist über eine Datei namens /etc/php5/conf.d/zend.ini eingebunden:

    Code
    zend_extension=/usr/lib/php5/20090626/ZendGuardLoader.so


    MD5-Prüfsumme des Zend-Loaders ist abde7aab4ddfc99755b548e865071253 (aus dem Paket ZendGuardLoader-php-5.3-linux-glibc23-x86_64.tar.gz vom 04.03.2013).


    Wie nutzen Sie PHP? Mit suPHP/FastCGI oder als mod_php?


    Mit einer OpenVZ-Umgebung kann ich das auch mal durchtesten, die haben wir aber derzeit nur unter CentOS 6.4 verfügbar.


    Viele Grüße


    -Klaus Keppler

    Am besten werfen Sie mal einen Blick ins LiveConfig-Logfile. Dort sehen Sie dann, dass LiveConfig versucht, die Verbindung zum MySQL-Server wiederherzustellen - es verdoppelt dabei jeweils die Wartedauer zwischen den Verbindungsversuchen (1,2,4,8...), bis insgesamt etwa eine Minute gewartet wurde. Sollte dann keine Verbindung zu MySQL da sein, bricht LiveConfig diesen Versuch ab und bringt auch eine Fehlermeldung zum Client (ich glaube so was wie "Datenbank nicht verfügbar").


    "Abstürzen" tut (bzw. sollte) dabei nichts. Die Verbindung zum Browser wird nur so lange offen gehalten, bis LiveConfig eben den MySQL-Verbindungsversuch definitiv beendet.

    Da müßte man mit Herrn Keppler reden vielleicht nimmt er das script ja mit auf dan hätte er erstmal eine vorrübergehende backuplösung


    An einem Hilfsscript mangelt es uns wirklich nicht. Diese Form von "Backups" halten wir nur für äußerst begrenzt brauchbar (konkret: Backup per FTP ist so ziemlich die unsicherste und ineffizienteste Lösung; wer mehr als nur einen Server betreibt setzt da Lösungen auf Basis von rsync/BackupPC/Bakula/... ein). Mit der Speicherung der "Backups" auf dem selben Server besteht zudem kein Schutz bei Plattencrashs, und man verschenkt Unmengen an Speicherplatz.
    Wer seinen Benutzern auf diese Art Backups bereitstellen möchte, darf das aber natürlich gerne tun.
    An dieser Stelle trotzdem vielen Dank an Sven_67 für die bereitwillige Unterstützung!

    Dabei habe ich festgestellt, dass die Webdateien in /htdocs hochgeladen werden müssen.
    Confixx nutzt jedoch /html.
    Ein Hinweis im Anleitung habe ich auch nicht gefunden. Wie wird es realisiert?


    Steht hier beschrieben: http://www.liveconfig.com/de/handbuch/advanced.web.html
    (unter "Webspace-Verzeichnis ändern")


    Zitat

    Eine andere Frage: Ich habe einen Kunden(vorher IP als shared) angelegt, Domain zugordnet
    und Webspace über den Checkbox aktiviert, jedoch kann ich kein Verzeichnis auswählen?
    Oder mache ich was falsch?


    Das bedeutet vermutlich nur, dass es einfach in diesem Webspace noch keine Unterverzeichnisse gibt (nur dann ist die Liste auch leer). Es werden nur Verzeichnisse angezeigt, die unterhalb ~/htdocs/ (bzw. ~/html/ - falls man das geändert hat) liegen.


    Zitat

    PS: Ich war hocherstaunt, dass die Installation von LC nicht mal ne minute gedauert hat,
    und der Arbeitsspeicherverbrauch bei ~208MB liegt (ohne Kunden)


    208 MB!? Das kann nicht stimmen. Eher 2,08 MB?


    Viele Grüße


    -Klaus Keppler