Beiträge von c_v

    Ad Problem A:


    Ich konnte das Problem nun eingrenzen - es liegt offenbar am Feld 'web' in der Aktion HostingDomainAdd().


    Zitat Handbuch:
    Wird das Feld web auf NULL gesetzt, dann ist der Webspace für diese Domain deaktiviert. Für „normalen“ (aktivierten) Webspace muss das Feld web auf einen leeren String („“) oder auf ein beliebiges Verzeichnis (z.B. „/“) gesetzt werden.


    (*) Ein leerer String 'web' => '' (wie im Handbuch angegeben) führt dazu, dass die Apache Konfiguration nicht geschrieben wird.


    (*) Ein Leerzeichen 'web' => ' ' führt dazu, dass Die Konfiguration zwar geschrieben wird, aber fehlerhaft ist - die Domain kann dann nicht aufgerufen werden:
    DocumentRoot "/var/www/webXXX/htdocs/ "-> ein Leerzeichen zuviel nach dem Pfad


    (*) Ein Slash 'web' => '/' (wie im Handbuch beschrieben) führt dazu, dass die Konfiguration erstellt wird - die Domain ist zwar aufrufbar, jedoch nicht 100%-ig korrekt:
    DocumentRoot "/var/www/webXXX/htdocs//"-> ein Slash zuviel nach dem Pfad



    Wir verwenden nun 'web' => '/' - ist aber auch nicht ganz korrekt in der Apache Konfiguration...

    Das ist auch die "richtige" Reihenfolge, und würde auch erklären, warum wir den Fehler hier bislang nicht reproduzieren konnten (unsere Testscripte verwenden eben genau diese Reihenfolge).


    Wir werden die Beschreibung der SOAP-API entsprechend erweitern, und außerdem eine Prüfung einbauen, dass man keinen Vertrag anlegen kann so lange noch kein Benutzer existiert.


    Hmm, der Fehler trat weiterhin auf - bis wir die Variable 'web' bei der Aktion 'HostingDomainAdd' auf '/' gesetzt haben. Ein leerer String '' (wie in der Dokumentation beschrieben) führte bei einigen Kunden dazu, dass keine Apache-Konfiguration geschrieben wurde.

    Hallo Christoph,


    ich habe jetzt die Reihe der SOA-Aktionen geändert - und auf einmal scheint es zu funktionieren:


    ALT: ContactAdd -> CustomerAdd -> HostingSubscriptionAdd -> HostingDomainAdd -> UserAdd
    NEU: ContactAdd -> CustomerAdd -> UserAdd -> HostingSubscriptionAdd -> HostingDomainAdd



    Ich werde es aber noch ein paarmal testen....

    Ich teste zur Zeit Live Config Version 1.5.3 (r1932) auf einem Debian Squeeze amd64 System - folgende Dinge sind mir aufgefallen:


    A) Kunden anlegen via SOAP funktioniert nicht 100%


    Wir legen derzeit Kunden via SOAP wie folgt an:


    ContactAdd -> CustomerAdd -> HostingSubscriptionAdd -> HostingDomainAdd -> UserAdd


    Der Kunde scheint auch in der Admin-Oberfläche korrekt auf - ABER - es wird nur eine leere Apache-Config angelegt. Erst wenn der Kunde manuell angestossen wird (z.B. Domain Status 'Enable' -> 'Disable' -> 'Enable'), wird die ApacheConfig geschrieben.


    Hinweis zu v1.6.0 (r1957): In dieser Version wird überhaupt keine Apache-Config Datei (/etc/apache2/sites-available/webXXX.conf) mehr angelegt.Ein manuelles Anstossen der Domain wie o.a. legt die Datei dann schlußendlich an.



    B) Kunden löschen


    Das Löschen eines Kunden ist überhaupt sehr umständlich - es müssen ja zuvor Domains und Verträge manuell gelöscht werden. Soweit so gut - hat der Kunde aber auch z.B. ein EMail-Konto angelegt, muss auch dieses manuell gelöscht werden. Das kenne ich so von keinem Panel...


    Besser wäre es, denn Kunden gesamt (mit allen 'angehängten' Dingen) löschen zu können. Ggf. mit einem Warnhinweis (a la: "Mit Löschen des Kunden werden auch folgende Einstellungen gelöscht: Email mail@xxx.xom, Domain xxx.com, Vertrag web123, etc.). Analog sollte beim Löschen eines Vertrages auch die zugehörigen Domains automatisch gelöscht werden.


    BUG:
    Das Löschen eines Kunden funktioniert zudem nicht sauber - so bleibt das Web-Verzeichnis /var/www/webXXX bestehen.


    Dieses kann auch nicht simpel mittels 'rm -fR /var/www/webXXX' gelöscht werden, da bei der Datei /var/www/webXXX/conf/php5/php-fcgi-starter erst mittels 'chattr -i /var/www/webXXX/conf/php5/php-fcgi-starter' die Attribute geändert werden müssen...



    C) SOAP


    1) Es scheinen noch einige grundlegende Funktionen (z.B. Benutzer löschen, sperren) zu fehlen - gibt es für die Implementierung einen Zeitplan ?


    2) Ich konnte in der SOAP-Referenz keinen Befehl für die Zuweisung einer IP-Adresse finden - wie kann ein Vertrag mit dedizierter IP-Adresse (z.B. ein Kunde mit eigenem SSL-Zertifikat) via SOAP angelegt werden ? HostingDomainAdd() gibt zwar eine IP-Adresse (webip) als Antwort zurück - wo lässt sich diese aber definieren ?



    D) Zeitzonen


    Derzeit ist bei über SOAP angelegten Kunden die Zeitzone auf 'Afrika/ABidjan', also den ersten Eintrag der Liste, eingestellt. Schöner wäre es, automatisch die Zeitzone des Administrators oder des Resellers zu erhalten.


    Hinweis: Es fehlt auch die Zeitzone 'Asia/Hong Kong' - diese würden wir bitte benötigen.



    E) Individuelle Einstellungen


    Es wäre gut, wenn bei den Config-Dateien der einzelnen Dienste eigene Einstellungen möglich wären (z.B. über eine apache2.local.conf), die nicht überschrieben wird. Hintergrund ist, dass einige Einstellungen für uns nicht praktikabel sind (z.B. das SnakeOil-Zertifikat - wir möchten ein eigenes verwenden). Alternative wäre, dass die Live Config-Templates, die für die Erstellung verwendet werden, angepasst werden können - konnte im Handbuch dazu leider nichts finden.



    F) SOAP Log


    Gibt es ein Logfile, in dem die Aktionen der SOAP-Schnittstelle protokolliert werden ? Im Admin-Log finde ich keine der Aktionen.




    Danke für Ihre Mühe !

    Teste derzeit LiveConfig 1.4.2 (r1483) - leider funktioniert die Installation der Apps nicht richtig:


    LiveConfig legt den Kunden mit DocRoot /var/www/webXXX/htdocs an, erstellt die App (z.B. WordPress) jedoch im Verzeichnis /var/www/webXXX/apps/DIR -> die App liegt somit nicht unterhalb des eingestellten DocRoot



    Resultat ist ein Internal Server Error mit folgender Fehlermeldung:


    SoftException in Application.cpp:221:
    File "/var/www/webXXX/apps/DIR/index.php" is not in document root of Vhost "/var/www/webXXX/htdocs"



    Weiterer Bug:


    Beim Löschen der App wird die Rewrite Regel unter /etc/apache2/sites-available/webXXX.conf nicht gelöscht - damit wird die Domain des Kunden unerreichbar, da diese auf ein nicht existentes Verzeichnis (/var/www/webXXX/apps/DIR) verweist....