Beiträge von kk

    Benötige ich für v1 überhaupt eine Lizenz?


    "Kommt drauf an"™
    Ab der kommenden Version (1.5) unterstützt LiveConfig auch die Verwaltung von Nameservern. Wenn Sie dann eine Zone auf dem Primary DNS (v3) via LiveConfig anlegen, muss der Secondary DNS (v1) ja auch darüber informiert werden, dass er für diese Zone Slave-Server ist.
    Wird Server "v1" auch über LiveConfig verwaltet, so wird die Zone dort automatisch angelegt. Alternativ (also ohne LiveConfig-Lizenz) können Sie v1 trotzdem als "externen" Slave-DNS nutzen - müssen dann aber die Slave-Zonen manuell auf diesem Server hinzufügen bzw. entfernen. Der Zonentransfer selbst (AXFR/IXFR) findet so oder so natürlich automatisch statt.


    Viele Grüße


    -Klaus Keppler

    suPHP kann ruhig aktiviert bleiben; das wird dann standardmäßig für PHP verwendet (also für Webspaces, für die man noch kein FastCGI aktiviert hat).

    Im Grunde fehlt für die FastCGI-Konfiguration durch LiveConfig nicht mehr viel - die aktuell in Entwicklung befindliche Version liest bereits die Liste der verfügbaren Apache-Module aus, und stellt auf deren Basis dann eine Auswahl für die Ausführung von PHP-Scripts bereit.


    Sie können bereits jetzt FastCGI für Webspaces einrichten, ohne dass LiveConfig da später in die Quere kommt. Voraussetzung ist lediglich, dass Sie das Apache-Modul fcgid (Debian-Package libapache2-mod-fcgid) installiert haben.


    Hier die notwendigen Schritte (erfolgreich auf Debian 6 getestet). Den Vertragsnamen "web1" müssen Sie überall entsprechend anpassen:


    Verzeichnis für FastCGI-Starter anlegen (wird später durch LiveConfig auch für php.ini's genutzt):

    Code
    mkdir /var/www/web1/conf
    chown web1:web1 /var/www/web1/conf
    chmod 555 /var/www/web1/conf


    FastCGI-Starter einrichten:

    Code
    cat > /var/www/web1/conf/php-fcgi-starter << EOF
    #!/bin/sh
    export TMPDIR=/var/www/web1/tmp
    exec /usr/bin/php5-cgi
    EOF
    chown web1:web1 /var/www/web1/conf/php-fcgi-starter
    chmod 550 /var/www/web1/conf/php-fcgi-starter


    .htaccess einrichten, damit FastCGI genutzt wird:

    Code
    echo > /var/www/web1/.htaccess << EOF
    <IfModule mod_fcgid.c>
     <Files ~ "\.php">
       Options +ExecCGI
     </Files>
     FCGIWrapper /var/www/web1/conf/php-fcgi-starter .php
     AddHandler fcgid-script .php
    </IfModule>
    EOF


    Viele Grüße


    -Klaus Keppler

    - löschen Sie die Datei /etc/liveconfig/liveconfig.key
    - aktivieren Sie anschließend die neue Lizenz (liveconfig --activate)
    - starten Sie LiveConfig dann neu (/etc/init.d/liveconfig restart)


    Viele Grüße


    -Klaus Keppler

    Im nächsten Handbuch-Update ist dieser Punkt auch beschrieben (ich sehe schon, vielleicht sollten wir vorab noch ein Update rausbringen? :)
    Hier müssten Sie jedenfalls das Gesamt-Quota für die Summe aller Postfächer angeben. Wenn Sie hier also z.B. 1 GB eintragen, kann der Kunde z.B. 5 Postfächer á 200 MB anlegen, oder 2 Postfach á 500 MB, usw... - die Anzahl der Postfächer kann unabhängig vom Quota aber auch eingeschränkt werden (damit niemand 1024 Postfächer á 1 MB anlegt...)


    Viele Grüße


    -Klaus Keppler

    Hallo,


    für CentOS installieren Sie bitte folgende (inoffizielle) Versionen:
    · Server: http://download.liveconfig.com…ig-1.4.2-r1503.x86_64.rpm
    · Client: http://download.liveconfig.com…nt-1.4.2-r1503.x86_64.rpm
    In diesen sind einige Probleme (1, 2) im Zusammenhang mit dem Anlegen von E-Mail-Postfächern unter CentOS bereits behoben (das "offizielle" Update kommt nächste Woche).


    In der Datei /etc/postfix/master.cf müssen Sie außerdem noch den Pfad für das deliver-Programm anpassen (/usr/libexec/dovecot/deliver statt /usr/lib/dovecot/deliver). (Bei Neuinstallationen mit LiveConfig ab r1503 wird das bereits automatisch erledigt).


    Anschließend installieren Sie bitte noch "dovecot" auf den Servern, und aktivieren Sie dieses in LiveConfig. Spätestens dann sollten die Server auch in der Auswahl für die Hostingverträge auftauchen.


    Viele Grüße


    Klaus Keppler

    Bitte prüfen Sie, ob in der Datei /etc/suphp/suphp.conf die Einstellung "umask" wirklich auf "0022" steht.
    Wenn dieser Wert noch auf der Standardeinstellung (0077) steht, dann wird die .htaccess-Datei mit zu restriktiven Berechtigungen angelegt, so dass der Webserver diese nicht lesen kann.


    Viele Grüße


    -Klaus Keppler

    Im Zusammenhang mit Redhat-basierten Systemen haben wir inzwischen einen Fehler in einem der Lua-Scripte beseitigt - dieses hatte das "apps"-Verzeichnis vorab angelegt (um mit "chcon" die nötigen Flags für SELinux zu setzen) und die Verzeichnisrechte zu restriktiv gelassen. Unter Debian haben wir das oben beschriebene Verhalten bislang noch nicht reproduzieren können.
    Können Sie mir sagen, welchem Benutzer/Gruppe die Verzeichnisse "apps" und "apps/wptest" gehören, und wie deren Berechtigungen ausschauen?


    Zitat

    [2012/04/30 21:25:40.461676] [1608|1611] Can't get group quota for 'web1' (path '/var/www/web1'): No such file or directory


    Diese Meldung besagt nur, dass keine Quotadaten ausgelesen werden können - das spielt in diesem Zusammenhang keine Rolle.


    Viele Grüße


    -Klaus Keppler

    Hallo,


    Zitat

    1. Gibt es bereits Skripte um diese Migration durchzuführen oder ist eine Neuanlage aller Kunden inkl. der Daten nötig?


    Eine "in-place"-Migration wird vermutlich nicht möglich sein, da sich die verschiedenen Controlpanels sicher in die Quere kommen werden. Sie können aber mit einem einfachen Script alle Daten aus Froxlor auslesen und die Accounts & Domains automatisiert auf einem neuen LiveConfig-System anlegen. Schauen Sie sich einfach das Migrationsscript für Confixx an, und passen das entsprechend an die Datenstruktur von Froxlor an.


    Zitat

    2. Unsere Kunden verwenden im Moment AWStats, ist dies für die Version 1.5 von Liveconfig mit eingeplant?


    Wurde bereits umgesetzt und ist in der nächsten Version enthalten. Es werden allerdings "nur" die statischen Berichte erzeugt - dafür haben wir AWStats ziemlich aufgepimpt :)


    Zitat

    Für uns ist vor allem die Verwaltung von IP-Adressen und SSL Zertifikaten unabdinglich. Wann kann man mit v1.5 rechnen? Gleiche gilt für DNS Einstellungen.


    V1.5 ist für Mitte Mai (also in rund zwei Wochen) geplant - derzeit liegen wir auch ganz gut im Zeitplan. Für Anfang kommender Woche ist schon mal eine Vorab-Version mit den ersten neuen Features geplant (Details dann im Forum).


    Viele Grüße


    -Klaus Keppler

    Kein Problem - wird kurzfristig mit eingebaut.
    Es gibt dann zwei weitere Funktionen: CustomerGet (liefert eine Liste aller Kunden zurück) und ContactGet (liefert die Kontaktdaten zurück). Wir werden Anfang kommender Woche eine Vorab-Version bereitstellen, mit der Sie das dann gerne testen können.


    Viele Grüße


    Klaus Keppler

    Wir haben sogar ursprünglich mal an der Implementierung von APS gearbeitet, das dann aber nach einer Weile abgebrochen.


    Zu den wichtigsten Gründen gegen APS zählten bei uns:
    - die Pakete sind kaum lokalisiert, d.h. alle Beschreibungen usw. selbst der prominentesten Pakete wie WordPress, Typo3 etc. sind ausschließlich auf Englisch
    - Quantität hat nichts mit Qualität zu tun (wir haben dazu einige statistische Auswertungen über das APS-Repository gemacht...)
    - die Verquickung mit dem Parallels Marketplace liegt nicht so direkt in unserem Interesse ;)


    Die API für den LiveConfig-App-Installer ist im Grunde offen (wird derzeit noch ausführlicher dokumentiert) - wer möchte kann sich da gerne einen Wrapper schreiben, der eben APS-Pakete installiert (oder Softaculous/Installatron/...)

    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