Beiträge von kk

    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:

    • installieren Sie irgendwo auf dem Server Ihre zusätzlichen PHP-Binaries (nur die CGI/FCGI-Variante ist notwendig).
      Beispiel: Source für php 5.5.9 irgendwo entpacken, mit "configure --prefix=/opt/php-5.5.9" compilieren und in o.g. Pfad installieren (dann kollidiert das nicht mit anderen PHP-Versionen)
    • Datei /usr/lib/liveconfig/lua/custom.lua anlegen bzw. folgende Zeile hinzufügen:

      Code
      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.

    • Der Aufruf "liveconfig --diag" sollte nun die automatisch erkannte PHP-Version sowie die zusätzlich installierten Versionen anzeigen.
    • LiveConfig neu starten.
    • Wird nun irgendeine Webspace-Konfiguration neu geschrieben (z.B. nach Änderung der Web-Einstellungen oder an php.ini-Werten), dann pflegt LiveConfig automatisch auch die php.ini sowie einen php-fcgi-starter für die zusätzlichen Versionen mit.
    • Um dann in einem Webspace z.B. PHP 5.5.9 zu verwenden, reicht folgende Zeile in einer .htaccess:

      Code
      FcgidWrapper /var/www/web1/conf/php55/php-fcgi-starter .php



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

    Code
    local tonumber = tonumber


    In Zeile 1275 (nach der Zeile "local val, unit = ...") bitte folgende Zeile ein:

    Code
    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.:

    • Konfiguration von FcgidIOTimeout anhand der max_execution_time (#135)
    • Problem mit AWStats und Großbuchstaben in Vertragsnamen beseitigt (#133)
    • Quota-Prüfung beim Anlegen/Bearbeiten eines POP3/IMAP-Postfachs korrigiert (#134)
    • rekursive Prüfung in übergeordneten Wiederverkäufer-Verträgen nach ausreichenden Ressourcen (PHP/CGI/SSI/Shell)
    • Fehler in Ressourcen-Auswahl-Dropdown beim Anlegen neuer Verträge beseitigt


    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:

    Code
    openssl rsa -in /etc/liveconfig/sslcert.pem -check -noout

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

    Code
    sed -i -e 's/\r//' /etc/liveconfig/sslcert.pem


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

    Code
    cd /etc/apache2/vhosts.d
    ln -s default.conf 000_default.conf

    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?

    Wenn die Glaskugel nichts sagt, dann hilft nur ein tcpdump auf dem Server. ;)


    Code
    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...)

    Die Meldung weist nur darauf hin, dass die standardmäßig von der Distribution installierte Konfigurationsdatei /etc/awstats/awstats.conf angepasst werden muss (Eintrag "SiteDomain" fehlt).


    Fügen Sie also entweder dort einen "SiteDomain"-Eintrag hinzu (z.B. "SiteDomain=localhost" o.ä.), oder benennen Sie die Konfigurationsdatei um (z.B. in "awstats.conf.disabled").

    Auf unserem Testsystem mit OpenSUSE 12.1 kann ich das o.g. Verhalten nicht bestätigen.


    Führen Sie bitte (als root) mal folgenden Befehl aus:

    Code
    apache2ctl -S -t


    Was wird für "default server" angezeigt? Dort sollte stehen:

    Code
    default server default (/etc/apache2/vhosts.d/default.conf:43)


    Zitat

    openSUSE 12.1 (x86_64)


    Ich empfehle bei Gelegenheit mal auf 12.3 zu aktualisieren; 12.1 ist schon ziemlich veraltet.

    Eigentlich sollte es genügen, die SSL-Werte über "ssl-ca=..." usw. in der my.cnf zu setzen (im Abschnitt [mysqld]) und danach MySQL neu zu starten.
    Falls es Probleme mit dem Zertifikat oder dem Key gibt (häufige Fehlerquelle: Key ist noch passwortgeschützt), dann sollte das im MySQL-Errorlog protokolliert werden.

    Hallo,


    SSL für MySQL muss ja in der my.cnf direkt in MySQL eingerichtet werden.
    Wenn Sie sich mal als (MySQL-)"root" auf dem 2. Server (mit lcclient) am MySQL anmelden, was erscheint dann bei folgender Abfrage:

    Code
    show variables like '%ssl%';


    LiveConfig prüft, welcher Wert in "have_ssl" steht.
    Dabei dürfte es keinen Unterschied machen, ob die MySQL-Datenbank über einen lcclient oder direkt über ein Standalone-LiveConfig verwaltet wird (in beiden Fällen läuft der selbe Programmcode ;))