wenn ich die zusätzlichen PHP Version einrichte erzeugt mir der lcclient auch die php.ini in den jeweiligen phpxx Ordner jedoch keine php-fcgi-starter
Die php-fcgi-starter werden nur angelegt, wenn man Apache verwendet und der betroffene Webspace für PHP via FastCGI konfiguriert ist.
Werfen Sie ggf. einfach mal einen Blick in die vHost-Konfiguration unter /etc/apache2/sites-enabled/web###.conf - dort steht dann jeweils, wie PHP eingerichtet ist (# PHP configuration for this subscription: ...).
hatte das Problem eben selber, habs manuell behoben
Sys:
LC Version: 1.7.1 - Platform: x86_64-unknown-linux-gnu - Revision: 2770
nginx (Version 1.0.15)
Centos6.5
Dann wird die nginx-Konfiguration aber schon mit einer älteren LiveConfig-Version erzeugt worden sein. Mit v1.7.1 wird die o.g. Anweisung wieder "richtig" in die Konfigurationsdatei geschrieben.
Viele Grüße
-Klaus Keppler
So lange nur ein Rechner aktiv ist reicht auch eine Lizenz.
Falls Sie DRBD nutzen, dann speichern Sie /etc/liveconfig/liveconfig.key am besten auch auf dem DRBD-Volume (dann gibt es keine Probleme bei der Lizenzverlängerung, falls zwischenzeitlich ein Failover stattgefunden hat).
Wie genau wir die Gültigkeit einer Lizenz prüfen möchte ich an dieser Stelle nicht verraten 
aber die lokalen IPs (oder sonstige Hardware-spezifischen Informationen) spielen dabei keine Rolle.
Das LiveConfig-Team freut sich, die Verfügbarkeit von Version 1.7.1 (r2770) bekanntgeben zu dürfen.
Die neue Version steht ab sofort im Download-Bereich sowie in allen Repositories bereit.
Die wichtigsten Änderungen zur vorherigen Version sind:
Die vollständige Liste aller Änderungen finden Sie im Änderungsverlauf.
Das Update ist wie gewohnt unkompliziert.
WICHTIG: aufgrund einer Änderung im internen LCCP-Protokoll sind alle Versionen <=1.7.0 zu den Versionen >=1.7.1 inkompatibel. Bei Multi-Server-Installationen müssen also der LC-Server und alle LC-Clients aktualisiert werden. Der LC-Server lehnt Verbindungen von "alten" Clients automatisch ab und protokolliert das auch.
Der Fehler mit PHP Einstellungen eines NNGINX-FCGI Hosts besteht in der aktuellen Preview
immer noch:
Ändere ich eine PHP Einstellung -> Stirbt der php-cgi Prozess.
Ändere ich eine PHP Einstellungen erneut -> Wird der php-cgi PHP Prozess gestartet.
Ich habe das eben mit CentOS 6.5 (AMD x64 via Xen) getestet und keine Probleme dabei gehabt - der Prozess wird jedes mal korrekt neu gestartet.
Was passiert denn, wenn Sie den Befehl manuell ausführen? Geben Sie dazu als letzten Parameter den Namen des betroffenen Vertrages an, z.B.:
/etc/init.d/nginx-php-fcgi restart web1LiveConfig führt ja letztendlich auch nur genau diesen Befehl aus, wenn es Änderungen an der Konfiguration eines NGINX-vHosts gab.
Viele Grüße
-Klaus Keppler
Wo hinterlegt man die spezifischen php.inis für die zusätzlich installierten PHP Versionen? Zumindest ein globale Vorlage benötigt man ja, das man ein paar Werte, die dann grundsätzlich für alle gelten hinterlegen kann (Bsp ioncube Loader ...)
Das hängt von der Compile-Time-Konfiguration von PHP an. Der einfachste Weg das herauszufinden ist über eine phpinfo().
PHP-Version kann per .htaccess ab v1.7.1-r2769 umgeschaltet werden:
http://www.liveconfig.com/de/f…ig-v1-7-1?p=6774#post6774
Viele Grüße
-Klaus Keppler
Soeben wurde die Preview noch mal aktualisiert (v1.7.1-r2769). Mit dieser Version ist es nun relativ einfach möglich, mehrere PHP-Versionen gleichzeitig nutzen zu können. 
Kurzanleitung:
LC.web.addPHP("php55", "/opt/php-5.5.9/bin/php-cgi")
Der erste Parameter enthält das zu verwendende Versionkürzel (bei "php55" wird die Webspace-spezifische Konfiguration dann in ~/conf/php55 geschrieben); der zweite Parameter ist der Pfad zum CGI-Binary.
FcgidWrapper /var/www/web1/conf/php55/php-fcgi-starter .phpIn unseren Tests lief soweit alles einwandfrei durch; falls irgendwas haken sollte, geben Sie bitte eine kurze Rückmeldung.
Ab v1.7.2 werden die zusätzlichen Versionen dann auch in der LC-GUI mit angezeigt, so dass Anwender auch dort umschalten können.
Alternativ zur FastCGI-Variante kann man übrigens mittels zusätzlicher suPHP-Handler analog auch suPHP nutzen. Der Benutzer muss dann aber mittels suPHP_ConfigPath selbst den Pfad zur jeweiligen php.ini mit in der .htaccess angeben.
(ich glaube übrigens, dass man für die .htaccess hier die Berechtigung "AllowOverride FileInfo" (oder Options) braucht, hab' das noch nicht im Detail durchgetestet)
Viele Grüße
-Klaus Keppler
Danke für den Hinweis!
Um das kurzfristig zu beheben, öffnen Sie bitte die Datei /usr/lib/liveconfig/lua/apache.lua.
In Zeile 30 fügen Sie folgende Zeile ein:
local tonumber = tonumber
In Zeile 1275 (nach der Zeile "local val, unit = ...") bitte folgende Zeile ein:
val = tonumber(val)Starten Sie LC anschließend neu.
Welchen Wert haben Sie für max_execution_time bzw. max_input_time für PHP eingerichtet? (suchen Sie bitte im betroffenen Webspace des Vertrags in ~/conf/php/php.ini nach diesen Werten).
Besten Dank schon mal!
-Klaus Keppler
Die Preview wurde eben aktualisiert (v1.7.1-r2766). Die Änderungen sind insbes.:
Aktuell befinden sich noch zwei kleinere Bugs in Arbeit (NGINX, SOAP-API), dann soll die produktive Freigabe erfolgen.
Eine Auswahl der PHP-Version befindet sich ebenfalls in Arbeit, wird in 1.7.1 wohl noch nicht enthalten sein, kann aber voraussichtlich ab morgen getestet werden (Details dazu dann morgen im Forum).
Viele Grüße
-Klaus Keppler
Ok, dann scheint der Private Key in der sslcert.pem "kaputt" zu sein.
Entfernen Sie bitte den kompletten Abschnitt von "-----BEGIN PRIVATE KEY-----" bis "-----END PRIVATE KEY-----" daraus und fügen diesen noch mal neu ein (am besten kopieren Sie den aus dem Key-File, das Sie scheinbar mit Apache fehlerfrei nutzen können).
Anschließend prüfen Sie bitte noch mal mit dem o.g. Befehl ("openssl rsa ..."), ob dieser dann korrekt gelesen werden kann.
Bitte senden Sie keine Dateien an DoRob (das hat seine Gründe).
Der Fehlermeldung nach tritt ein Problem beim Laden des Private Key auf. Welche Meldung liefert folgender Befehl:
openssl rsa -in /etc/liveconfig/sslcert.pem -check -nooutHaben Sie Teile der Datei vielleicht unter Windows (bzw. mit einem Windows-Editor) bearbeitet?
Führen Sie bitte mal folgenden Befehl aus, um eventuelle Windows-Zeilenumbrüche zu korrigieren:
sed -i -e 's/\r//' /etc/liveconfig/sslcert.pemDoRob: Sie sollten den Ball besser mal gaaaanz flach halten. Soweit ich weiß haben Sie heute einen Termin in Aachen.
Es gab einen kleinen GUI-Fehler, so dass beim Anlegen eines neuen Vertrages mit der Auswahl "- individuell -" eventuell die Einstellungen des ersten Angebots in der Angebot-Dropdown-Liste verwendet wurden. Ist dann mit r2766 beseitigt.
Wenn Sie den Vertrag noch mal neu einrichten (evtl. auf Basis irgendeines Angebots) und anschließend über "Bearbeiten..." auf den Typ "- individuell -" setzen, müsste es eigentlich klappen.
Ich tippe mal darauf, dass "RESELLER-KUNDE.conf" im o.g. Fall alphabetisch vor dem Wort "default" liegt.
In diesem Fall liest Apache dessen Konfigurationsdatei zuerst ein und verwendet die daher als Standard-Host.
Abhilfe könnte es schaffen, im Verzeichnis /etc/apache2/vhosts.d/ einen Symlink von "default.conf" auf z.B. "000_default.conf" zu erstellen:
cd /etc/apache2/vhosts.d
ln -s default.conf 000_default.confIst in der aktuellen Preview bereits behoben ("Fehler in NGINX-Konfiguration beseitigt (eingeführt mit v1.7.0-r2666)")
Diskussion wurde in diesen Thread verlagert:
http://www.liveconfig.com/de/f…tivierbar?p=6717#post6717
ich habe für meine Reseller SSH verboten. Dennoch kann der Reseller beim Anlegen seiner Kunden Verträge
SCponly/sftp und ja (bash) auswählen.
Wenn beim Kunden ja(bash) ausgewählt ist, kann der Kunde sich dann mit seinen Liveconfig Zugangsdaten viaPutty einloggen und kann alles sehen.
Soweit ich das im Code sehe, ist das seit r2557 (v1.7.0) nicht mehr möglich, da beim Speichern der Vertragseinstellungen geprüft wird, welche Rechte über den Resellervertrag maximal vorhanden sind.
In der Verwaltung von Angeboten kann ein Reseller nach wie vor alle Shell-Möglichkeiten auswählen. Beim Anlegen eines Vertrags auf Basis eines solchen Angebots werden aber automatisch die Shell-Rechte entsprechend limitiert. Ich habe das eben getestet - mein Test-Account hatte auf dem Zielsystem (wie erwartet) in /etc/passwd als Shell "/usr/sbin/nologin" eingetragen.
Beim Bearbeiten eines solchen Vertrags sowie beim Erstellen/Bearbeiten eines individuellen Vertrags wird gar keine Shell-Auswahl mehr angezeigt.
Wie genau gehen Sie vor, um in Ihrem Beispiel einen Vertrag mit Shell anzulegen (obwohl diese nicht erlaubt ist)? Hat dieser Benutzer dann tatsächlich eine gültige Shell in /etc/passwd stehen?
Bei diesen Aktionen wird ein Reload vom NGINX bzw. nginx-fcgi-starter durchgeführt; offenbar kommt es dann zu einem Problem. Welche Distribution setzen Sie ein? (CentOS 6 wenn ich mich richtig erinnere?)
Wenn die Glaskugel nichts sagt, dann hilft nur ein tcpdump auf dem Server.
tcpdump ip and not host #.#.#.#(#.#.#.# durch die IP ersetzen, von der aus Sie per SSH auf dem Server sind, damit Sie nicht Ihre eigenen SSH-Pakete mit loggen...)