Beiträge von kk

    Interessante Frage... bisher gibt es keine eigene "Keepalive"-Logik - der LiveConfig-Server erkennt anhand der beendeten TCP-Verbindung, ob die Connection zu einem Client weg ist. Beim Ausschalten eines Servers kann das - je nach TCP-Stack bzw. -Konfiguration durchaus eine Weile dauern.
    "liveconfig -k reload" spielt in diesem Zusammenhang keine Rolle, da hier der Verbindungsstatus keine Rolle spielt (ein "restart" würde die Verbindungen abbrechen und von den Clients neu aufbauen lassen - das ist aber nicht Sinn und Zweck der Sache)


    Ich habe eben einen entsprechenden Feature-Request aufgenommen, der möglichst schnell umgesetzt wird.


    Danke für den Hinweis & viele Grüße


    -Klaus Keppler

    Ich schätze, dass in /etc/suphp/suphp.conf die Einstellung "check_vhost_docroot" noch auf "true" steht. Stellen Sie diese bitte auf "false" um und starten Apache anschließend neu.
    Die Doku wird beim nächsten Update auch entsprechend aktualisiert, und das Meta-Package soll sich dann automatisch um diese Einstellung kümmern.

    Ja, wird natürlich auch unterstützt. In einem Entwicklungszweig haben wir das schon komplett drin, ich denke dass wir das auch mit in die kommende Version (1.5 / Mitte Mai) packen können. In diesem Zweig steckt auch noch die automatische Konfiguration von Logrotate für die Apache-vHost-Logs.


    Viele Grüße


    -Klaus Keppler

    LiveConfig funktioniert eigentlich auch ohne Quota (das entsprechende Subsystem erkennt automatisch ob Quota verfügbar ist - falls nicht, wird einfach kein Quota ausgelesen/verwaltet).
    Welche Fehlermeldungen genau erhalten Sie denn beim Start von LiveConfig (bzw. vom Client)?
    Könnten Sie bitte die Ausgabe von "lcclient --diag" posten (oder per Mail an info@liveconfig.com senden)?


    Viele Grüße


    -Klaus Keppler

    Das mit der Kundennummer ist etwas schwierig, da ein Kunde prinzipiell mehrere Verträge haben kann. Mit "%c" im Präfix kann aber der Vertragsname (zB. "web123") voreingestellt werden.


    Hilft Ihnen das bereits weiter?


    Viele Grüße


    -Klaus Keppler

    Ja, an Ideen wird es sicher nicht scheitern :)


    Zuerst zum Testverfahren: etwas genauer als der Browser-Reload und auch besser reproduzierbar ist es, wenn Sie zum Testen das Tool "ab" (Apache Benchmark) verwenden - ich schätze mal, dass das bei Gentoo auch mit installiert wird. Damit können Sie auch große Zugriffszahlen bequem simulieren.


    Die "mäßige" Performance mit suPHP ist bekannt, ist aber technisch nicht vermeidbar: damit ein PHP-Script unter einer eigenen User-ID laufen kann, muss für jeden einzelnen PHP-Zugriff ein eigener PHP-Prozess gestartet, die Benutzer-ID geändert, das PHP-Script geparsed und anschließend ausgeführt werden. Dieses Verfahren gilt praktisch mit am Sichersten und am Einfachsten zu konfigurieren. Damit ein Account aber nicht den kompletten Webserver "abschießen" kann, sollten mit den Apache-Befehlen "RLimit_nproc" die maximale Anzahl gleichzeitiger Prozesse pro User beschränkt werden (z.B. auf 20 oder 50).


    Eine deutliche Entlastung bringt ein Opcode-Cache für PHP, wie z.B. APC oder eAccelerator. Dieser bringt unter suPHP aber gar nichts, sondern spielt seine Vorteile nur mit mod_php oder FastCGI aus (wir arbeiten bereits daran, die Methode der PHP-Ausführung über die LiveConfig-Oberfläche auswählbar zu machen).
    Wenn bei Ihnen also auch mit mod_php die Serverlast extrem ansteigt, versuchen Sie mal, die PHP-Extension "APC" zu aktivieren.


    Weitere Schritte zur Performance-Optimierung sind dann aufwendiger. Für reine Wordpress-Sites wären das z.B.
    - prüfen, ob Wordpress evtl mit "mysqli" genutzt werden kann
    - Vorschalten eines Caches wie z.B. memcached
    - "Profiling", um herauszufinden wo evtl. der Flaschenhals liegt
    Das hat mit LiveConfig direkt aber nichts zu tun, und ist im Shared Hosting auch nur sehr begrenzt durchführbar.


    Viele Grüße


    -Klaus Keppler

    Ah, damit haben wir's schon:

    Zitat

    LCINITPW=soap /usr/sbin/liveconfig --init


    Damit setzen Sie das SOAP-Passwort auf "soap" - das ändert aber nichts am Benutzernamen (der bleibt weiterhin bei "admin")


    Setzen Sie bitte mit LCINITPW=[...] ein sicheres Passwort, und ändern Sie in der cfximport.conf den Wert "user" auf "admin", und den Wert "pass" auf das mit LCINITPW gesetzte Passwort.


    Wir werden die Doku noch um einen Hinweis auf die Logdatei erweitern. ;)


    Viele Grüße


    -Klaus Keppler

    Erhalten Sie auf dem LiveConfig-Server in /var/log/liveconfig/liveconfig.log eine Fehlermeldung, wenn Sie das cfximport.php ausführen?
    (damit können wir das Problem evtl eingrenzen; falls kein Fehler auftritt, kann bereits die Verbindung nicht aufgebaut werden)


    Das Exception-Objekt liefert in PHP leider keine weitergehenden Informationen darüber, was genau schief gegangen ist. :(

    Ok, dann hat PHP ein anderes Problem beim Aufruf dieser URL.
    Welche PHP-Version setzen Sie ein?
    Haben Sie die PHP-Extension "curl" mit SSL-Unterstützung installiert? (findet man zB. via phpinfo() heraus)

    Diese Fehlermeldung bedeutet, dass das PHP-Script nicht auf die WSDL-Daten des Webservice zugreifen kann.
    Haben Sie ein SOAP-API-Passwort eingerichtet? (siehe Handbuch)
    Falls ja, versuchen Sie mal, die WSDL-URL (mitsamt Benutzername & Passwort) direkt im Browser aufzurufen.
    [Nachtrag] siehe auch dieser Thread

    Hallo Herr Bock,


    ja, über SOAP-API können Kunden noch nicht gelöscht werden. Ist aber bereits in Arbeit (ebenso wie die Verwaltung von Mailadressen via SOAP)


    Viele Grüße


    -Klaus Keppler

    Für welche nächste Version ist das den vorgesehen?


    Für v1.5 (Mitte Mai). Die "kleineren" Releases (z.B. 1.4.x) enthalten i.d.R. nur kleinere Verbesserungen und Bugfixes.
    Die BIND-Unterstützung setzt für LiveConfig voraus, dass die Verwaltung der IP-Adressen komplett implementiert ist (sonst macht die Erzeugung von DNS-Zonen natürlich keinen Sinn).


    Viele Grüße


    Klaus Keppler

    Eigentlich sollte genau das Gegenteil der Fall sein - ein falscher JOIN führte in manchen Fällen zu überhöhten Zahlen. Können Sie die Daten evtl. stichprobenartig prüfen?
    (Speicherbelegung mit "du -s <Pfad>", Anzahl z.B. mit "find <pfad> -type f | wc -l")

    Ein gemeinsames Quota ist technisch bedingt nicht wirklich einfach zu lösen. Das Webspace-Quota wird über "normale" Filesystem-Quotas realisiert, bei E-Mails läuft das über Maildir-Quotas (LiveConfig legt im Gegensatz zu anderen Panels nicht für jedes Mailpostfach einen eigenen Betriebssystem-Account an). Und MySQL-Quota (bereits in Arbeit) wird über eine Beschränkung der INSERT/CREATE-Privileges erreicht. Dazu können Webspace, E-Mails und Datenbanken auf komplett unterschiedlichen Servern liegen - letztendlich ließe sich ein "globales" Quota nur durch Auswertung und Addition der tatsächlich genutzten Speichergrößen ermitteln.


    In LiveConfig wird es eine solche Funktion mittelfristig nicht geben - aber über die SOAP-API könnten Sie so etwas prinzipiell selbst realisieren. Sie können die Verbrauchsdaten Ihrer Kunden z.B. 1-2x täglich abrufen, aufaddieren, und dann bei Überschreitung entsprechend reagieren. (SOAP-Funktion HostingSubscriptionGet - die Verbrauchsdaten werden da in Kürze mit aufgeführt).


    Viele Grüße


    -Klaus Keppler

    Ich habe eben testweise auch mal Wordpress installiert (unter /htdocs/wordpress/) und die o.g. .htaccess-Datei in /htdocs/wordpress/.htaccess eingerichtet - funktioniert alles einwandfrei.


    Können Sie WordPress denn aufrufen, wenn die .htaccess-Datei nicht existiert (ggf. einfach mal umbenennen)?

    Seit Freitag Abend steht LiveConfig v1.4.2 zum Download bereit. Es handelt sich in erster Linie um Detailverbesserungen, ein Upgrade ist also optional.
    Die Änderungen sind:


    • Fehlerbehandlung im AppInstaller verbessert
    • Anzeige der URLs zurm Abschluss der Installation und zur Verwaltung der Anwendungen im AppInstaller
    • Anzeige von MySQL-Datenbank-Statistiken (Anzahl der Tabellen, belegter Speicherplatz)
    • Prüfung der Gesamt-Postfach-Quota beim Anlegen/Bearbeiten eines Postfachs
    • Aktualisierung von OpenSSL auf 0.9.8v


    Die nächste Version (v1.5.0) ist für Mitte Mai geplant und enthält dann v.a. die Verwaltung von IP-Adressen und SSL-Zertifikaten. Außerdem wird auch der Application-Installer noch fleißig erweitert, ab v1.5 sollen dann auch eigene Repositories möglich sein.


    Viele Grüße


    -Klaus Keppler

    Seit dem 20.04. ist das Overlay für 1.4.2 online. Wir stellen unser komplettes Build-System derzeit um, damit künftig Gentoo-Overlays vollautomatisch erzeugt werden.