Beiträge von mjk

    Hallo Herr Keppler,


    vielen Dank für die schnelle Rückantwort! Ihre Vermutung war richtig, ein "aptitude install php5-cgi" gefolgt von einem Restart des lcclient Dienstes hat den Fehler behoben, bei den übrigen Accounts wurde das Verzeichnis "php5" nun auch angelegt. Ich ging fälschlicherweise am Anfang davon aus, dass LiveConfig eine der FastCGI-Versionen aus /opt nutzen wird, sofern keine Standard-Version von Debian selbst installiert ist. Gibt es auch die Möglichkeit, eine Standard-FastCGI Variante innerhalb eines Angebots festzulegen, welche dann nur bei der Ersterstellung voreingestellt wird?


    Grüsse,


    Michael

    Hallo,


    wir haben hier leider ein kleines Problem bei der Neuanlage von Verträgen innerhalb von LiveConfig. Ausgangssituation: Business-Lizenz auf separatem Server, zusätzlich je eine Standard-Lizenz für Webserver, Datenbank und Mailserver. Auf dem Webserver ist PHP lediglich als Modul als auch als FastCGI Variante installiert, kein suPHP.


    Innerhalb von LiveConfig wurden Angebote erstellt und darin direkt PHP aktiviert (als FastCGI). Wird nun ein neuer Kunde eingerichtet und ein Vertrag mit diesem Angebot aktiviert, so wird die neue Apache-Config mit einem falschen Pfad zu "php-fcgi-starter" generiert. Folglich kann der Apache nicht neu starten:


    Code
    [2015/10/26 20:41:50.321290] [27632|27634] [LUA] LC.exec(/usr/sbin/a2ensite web15.conf): program output: Enabling site web15.
    To activate the new configuration, you need to run:
      service apache2 reload
    [2015/10/26 20:42:00.422142] [27632|27635] [LUA] LC.exec(/etc/init.d/apache2 reload): program output: Reloading apache2 configuration (via systemctl): apache2.service failed!
    [2015/10/26 20:42:00.422175] [27632|27635] [LUA] LC.exec(/etc/init.d/apache2 reload): error output: Job for apache2.service failed. See 'systemctl status apache2.service' and 'journalctl -xn' for details.


    Code
    apachectl configtest
    AH00526: Syntax error on line 60 of /etc/apache2/sites-enabled/web15.conf:
    Wrapper /var/www/web15/conf/php5/php-fcgi-starter cannot be accessed: (2)No such file or directory
    Action 'configtest' failed.
    The Apache error log may have more information.


    Code
    ls -lh /var/www/web15/conf/
    total 16K
    dr-xr-xr-x 2 web15 web15 4.0K Oct 26 20:42 php54
    dr-xr-xr-x 2 web15 web15 4.0K Oct 26 20:42 php55
    dr-xr-xr-x 2 web15 web15 4.0K Oct 26 20:42 php56
    dr-xr-xr-x 2 web15 web15 4.0K Oct 26 20:42 php70


    Es gibt also kein Verzeichnis "php5" in "conf". Die PHP-FastCGI Versionen wurden direkt vom LiveConfig Repository für Debian Jessie installiert. Wenn ich mich bei dem betroffenen Kunden in LiveConfig einlogge und dort unter "Hosting -> Domains" bei jeder einzelnen Domain die PHP Version nochmal manuell einstelle und speichere, dann wird die Config richtig geschrieben und Apache lädt sich neu.


    Irgendetwas scheint also bei der Erstellung eines neuen Vertrages nicht zu funktionieren bzw. FastCGI wird dort nicht richtig aktiviert und in die Konfiguration aufgenommen.


    Grüsse,


    Michael


    Backend oder Frontend? Wenn Sie alle Objekte vollständig über die API verwalten möchten klingt das eher nach einem alternativen Frontend.


    Wir haben die Erfahrung gemacht, dass es viele Kunden irritiert wenn es mehrere Loginbereiche gibt (z.B. einmal für Stammdaten / Rechnungen und einen/mehrere für die eigentlichen Webspace-Pakete und deren Leistungen). Daher wäre es wünschenswert, wenn alle grundlegenden Funktionen zukünftig auch direkt per API steuerbar wären. An der Art oder der Anzahl der benötigten Lizenzen würde dies nichts ändern, daher sehe ich insbesondere aus Kundensicht nur Vorteile.

    Hallo,


    wir haben hier bei einem unserer Kunden das Problem, dass Passwort-Änderungen nicht (oder nur sporadisch) von Liveconfig ins System übernommen werden.


    Derzeit installierte Version: LiveConfig 1.8.1-3397


    Es wurde bei einem bestehenden User in dovecot (Email-Konto) das Kennwort über die Oberfläche geändert. Scheinbar wurde dieses auch in die Datenbank übernommen, aber die Systemänderungen werden nicht ausgeführt. Mit einem


    service liveconfig restart


    läuft dann wieder alles und nach ein paar Sekunden erscheint die folgende Meldung:


    [LUA] Adding/updating user account mail@domain.de at dovecot config file: /etc/dovecot/passwd


    Jemand eine Idee wie man das Problem näher eingrenzen oder beheben kann?


    Grüsse,


    Michael

    Ich habe soeben eine einfache LiveConfig-Installation über das Debian Repository ausführen wollen. Installiert war zunächst eine Minimale 7.7 Debian Wheezy mit Software-RAID1.


    PHP
    wget -O - http://www.liveconfig.com/liveconfig.key | apt-key add -
    cd /etc/apt/sources.list.d
    wget http://repo.liveconfig.com/debian/liveconfig.list
    
    
    aptitude update
    aptitude install liveconfig-meta


    Diese Installation verlief zunächst einwandfrei (bis auf wenige Fehlermeldungen z.B. von clamav, da freshclam noch nicht ausgeführt wurde usw.). Anschliessend:


    PHP
    aptitude install liveconfig


    Daraufhin meldet mir aptitude:



    Ich habe testweise die Installation bestätigt, die oben genannten Pakete wurden dabei tatsächlich entfernt und LiveConfig selbst installiert (mit Abfrage des Lizenzcodes usw.). Über ein anschliessendes


    PHP
    aptitude install liveconfig-meta


    konnten die Pakete erneut aufgespielt werden, allerdings meldet mir aptitude z.B. bei einem Upgrade-Befehl wieder folgendes:



    Habe ich an dieser Stelle etwas übersehen/vergessen zu konfigurieren, oder ist das liveconfig-meta Paket noch nicht mit Wheezy 7.7 kompatibel? Ich würde notfalls eine manuelle Installation durchführen, schöner wäre es bei Neuinstallationen aber direkt über das Meta-Paket.

    Bevor ich einen neuen Topic öffne, hänge ich meine Frage mal mit hier rein:


    Hat jemand von euch schon einen "größeren" Cluster mit LiveConfig aufgebaut, also beispielsweise Web / Mail / MySQL getrennt auf verschiedenen Servern und zudem die Webserver mittels angebundenem zentralen Storage + Loadbalancer vornedran redundant ausgelegt? Insbesondere letzteres wäre eine interessante Option. Mein Grundgedanke war zunächst, dass man einen Server für Web + FTP mit LiveConfig ganz normal konfiguriert. Über diesen erfolgen dann auch später die FTP-Logins um die Daten auf dem Storage zu verwalten (damit wären die Benutzerzugänge zentral auf diesem System). Die Apache-Konfiguration für die einzelnen vHosts müsste man dann im Änderungsfall auf die einzelnen Webserver synchronisieren und dabei wohl auch die IP-Adressen entfernen oder anpassen. Hätte jemand hierzu eine Idee, wie man das ohne nennenswerte Zeitverzögerung bewerkstelligen könnte?

    Wir sind zwar auch noch nicht "LiveConfig"-Kunde, benötigen aber für die Zukunft eine bessere Webadministrationssoftware und LiveConfig ist bis dato ganz oben in der Liste der Alternativen (gefolgt von einer möglichen eigenen programmierten Lösung). Leider hängt unsere letzte Email mit Anfragen ebenfalls seit dem 25.07. beim Support fest ohne eine Rückantwort bisher :(