Beiträge von mjk

    Entschuldigt wenn ich diesen Topic nach langer Zeit wieder hervorhole, allerdings suche ich nach einer Lösung für eine Aktivierung der richtigen ionCube-Version individuell pro Kunde. Folgendes Problem:


    1. In /opt/php-X.X/etc/conf.d/ läßt sich die Konfiguration zwar pro Version, aber nur Global anpassen, das möchte ich nicht.


    2. Es gibt in den Userverzeichnissen zwar das Verzeichnis "conf" (/var/www/webX/conf/phpXX), die dortige php.ini wird aber bei Änderungen überschrieben. Ein conf.d Verzeichnis existiert dort nicht.


    3. Wenn ich eine neue Option bei den "PHP-Einstellungen" in der Liveconfig Weboberfläche eintrage, dann gilt diese für alle PHP-Versionen beim jeweiligen Vertrag Global. Ich kann im Falle von IonCube also nur eine Version korrekt konfigurieren und die PHP-Option beim jeweiligen Vertrag aktivieren.


    Habe ich eine Einstellungsmöglichkeit übersehen, oder kann man IonCube derzeit wirklich nur Global in allen Verträgen aktivieren, wenn das ganze mit allen PHP-Versionen funktionieren soll?

    Bisher ist das Problem noch nicht gelöst, zumindest nicht unter Debian 8. Wir haben derzeit nur in Zusammenhang mit Filezilla entsprechende Kundenrückmeldungen. Die einzigen Möglichkeiten wären wohl, entweder proFTPd zu entfernen und zu ersetzen (z.B. durch vsFTP) oder die aktuelle proFTPd Version selbst zu kompilieren. Mir wäre die erste Variante lieber, allerdings gibt es wohl in Liveconfig keine direkt ersichtliche Möglichkeit, einmal konfigurierte Dienste wieder zu entfernen, daher ja auch mein Posting vom 17.03. mit dieser Anfrage.

    Leider besteht dieses Problem noch immer und seitens Debian ist noch keine Lösung in Sicht. Wäre es denn praktikabel, den bestehenden proFTPd gegen vsftpd auszutauschen? Die Installation unter Debian selbst wäre kein Problem, aber gibt es hierzu etwas unter LiveConfig zu beachten? Wie bekomme ich den proFTPd dort vorher aus der Serververwaltung wieder heraus?

    Hallo Herr Keppler,


    das Problem ist am gestrigen Tag auch bei uns aufgetreten:


    [Blockierte Grafik: http://fs5.directupload.net/images/151227/fubeascu.png]


    Die Datenbank wird durchgestrichen in LiveConfig angezeigt, aber bei der Gesamtzahl der zulässigen Datenbanken noch mit eingezählt. Wir verwenden LiveConfig 2.0.1 Standard auf dem DB-Server (MySQL 5.5.46 (5.5.46-0+deb8u1, Debian Jessie 64 Bit), zusammen mit einer LiveConfig Business-Lizenz für die Verwaltungsoberfläche auf einem anderen System (ebenfalls Debian Jessie). Die Datenbank selbst wurde wohl auf dem Datenbankserver bereits gelöscht, fehlerhaft ist also lediglich noch der Eintrag in der LiveConfig-Datenbank.


    Die Logdateien zeigen leider keine weiteren Details, lcclient und liveconfig wurden bereits auf beiden Systemen neu gestartet. Gibt es einen einfachen Weg, den Fehler zu beheben? Wir verwenden eine MySQL-Datenbank auf dem Server mit der Business-Lizenz, reicht es dort einfach ebenfalls den DB_STATUS neu zu setzen wie im Posting vom 22.09.2012 beschrieben, oder können wir bei der Fehlersuche noch anderweitig behilflich sein?

    Hallo,


    da dieses Problem bereits das zweite Mal bei mir auftritt, frage ich diesmal zur Sicherheit hier im Forum nach. Wir hatten für einen Kunden eine normale HTML-Seite auf den LiveConfig-Server umgezogen, heute ist aufgefallen das eine 403-Forbidden-Meldung erscheint (.htaccess könne nicht gelesen werden). Nach kurzer Recherche haben wir festgestellt, das die Zuordnungen der Verzeichnisse wie folgt waren:


    Code
    drwxr-x--- 7 www-data web58    4.0K Nov 22 22:24 conf
    drwxr-x--- 3 web58    web58    4.0K Dec  2 15:19 htdocs
    drwxr-x--- 3 www-data web58    4.0K Dec  3 06:25 logs
    drwxr-x--- 2 web58    web58    4.0K Nov 22 22:24 priv
    drwxrwx--- 2 web58    www-data 4.0K Nov 22 22:24 tmp


    Dadurch hatte der Apache-Daemon keinen Lesezugriff auf htdocs, da dieses Verzeichnis ebenfalls der Gruppe "web58" gehörte. Sobald man die Gruppe per chown korrigierte, funktionierte der Zugriff wieder:


    Code
    drwxr-x--- 3 web58    www-data 4.0K Dec  2 15:19 htdocs


    Die Frage ist nun lediglich, woher dieser Fehler kommt. Ich kann leider nicht genau sagen ob die Gruppenzuordnung bereits nach Erstellung des Vertrags so bestand oder erst später geändert wurde - ich meine mich aber erinnern zu können, das wir nach dem Umzug der Webseite die Aufrufbarkeit getestet hatten und dort alles einwandfrei lief. Der Fehler trat exakt so auch bereits bei einem anderen Account in der Vergangenheit auf. Zur Sicherheit habe ich eben auch nochmal alle anderen Accounts auf dem Server geprüft, dort war alles korrekt der Gruppe www-data zugewiesen.

    Fehler gefunden:
    In Apache ist mod_negotiate per Standard aktiv. Da "Options MultiViews" gesetzt ist, hatte dies mit mod_rewrite kollidiert, da der Kunde zusätzlich folgende Dateien auf dem Webspace hatte:


    /impressum.php
    /kontakt.php
    usw.


    Ein mod_rewrite von domain.de/impressum funktionierte somit beispielsweise nicht mehr. Lösung: In der .htaccess-Datei MultiViews ausschalten:


    Options -MultiViews



    Bei der Kontrolle der übrigen Konfiguration ist mir desweiteren aufgefallen, dass php5-cgi nicht unter /etc/apache2/conf-enabled auftaucht. Mittels "a2enconf php5-cgi" kann dies natürlich geändert werden, da PHP als FastCGI-Variante derzeit aber einwandfrei läuft stelle ich mir die Frage, ob dies überhaupt aktiviert werden muss?

    Leider stosse ich hier auf ein ähnliches Problem, Apache gibt mir unter Debian Jessie diesen Fehler aus:


    Code
    [negotiation:error] [pid 3211] [client 1.2.3.4:36781] AH00687: Negotiation: discovered file(s) matching request: /var/www/web60/htdocs/impressum (None could be negotiated)., referer: http://domain.de/


    php5-cgi ist installiert:


    Code
    apt-get install php5-cgi
    Reading package lists... Done
    Building dependency tree       
    Reading state information... Done
    php5-cgi is already the newest version.


    lcclient --diag



    cgi-Modul ist aktiviert:


    Code
    a2enmod cgi
    Module cgi already enabled


    liveconfig und lcclient wurden ebenfalls neu gestartet und auch mehrfach bei dem betreffenden Kunden etwas am Vertrag geändert, damit die Config neu erstellt wird, trotzdem bleibt der Fehler. Verwendet wird eine .htaccess-Datei mit folgenden Rewrite-Rules:


    Apache Configuration
    RewriteEngine on 
    
    
    RewriteRule ^([a-zA-Z0-9]*)/$ index.php?i=$1
    RewriteRule ^([a-zA-Z0-9]*)$ index.php?i=$1


    Habe ich irgendwo etwas übersehen?

    Ein SSH-Tunnel wäre eine Möglichkeit, allerdings sollen mehrere Datenbankserver unterstützt werden. Dort sehe ich dann nur die Möglichkeit, diese über verschiedene Ports auf "localhost" mittels SSH-Tunneln anzubinden. Da LiveConfig aber bereits eine SSL-Unterstützung für externen Datenbankzugriff mitbringt, dachte ich es gäbe eine einfachere Möglichkeit um bei jedem Connect SSL zu verwenden.

    Hallo,


    zwei kurze Fragen - in Benutzung ist eine LiveConfig Business-Lizenz mit jeweils separatem Web-, Mail- und Datenbankserver.


    Auf dem Datenbankserver ist SSL konfiguriert, Liveconfig zeigt in der Serververwaltung auch die SSL-Unterstützung an. "Externer Zugriff" ist dort deaktiviert, bei dem Punkt "Zugriff erlaubt" steht aber die IP-Adresse des Webservers. Ist es möglich, die Datenbankverbindungen zwischen diesen beiden Systemen per Standard zu verschlüsseln? In der jetzigen Einstellung gestattet MySQL den Zugriff von der IP, aber Verschlüsselung findet wohl nicht statt.


    Gibt es eine Möglichkeit bei einem bestehenden Kundenvertrag den Server zu wechseln? Beispielsweise wenn der Kunde bisher den Webspace auf Server1 genutzt hatte, nun aber auf Server2 wechseln will, der Mail- und Datenbankserver aber identisch bleiben soll.


    Grüsse,


    Michael

    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 :(