Das sieht so aus als ob nicht mal die WSDL-Info abgerufen werden konnte - vermutlich falscher Benutzername/Passwort.
Haben Sie schon ein SOAP-Passwort eingerichtet? (liveconfig mit "--init" und LCINITSOAP aufgerufen? siehe Handbuch)
Sie können das einfach testen, indem Sie versuchen die WSDL-URL direkt im Browser zu öffnen:
:8443/liveconfig/soap?wsdl&l=admin&p=PaSsWoRt"]https://(...):8443/liveconfig/soap?wsdl&l=admin&p=PaSsWoRt
Soeben wurde LiveConfig 1.3.3 veröffentlicht. Die Änderungen gegenüber 1.3.1/1.3.2 betreffen praktisch nur die SOAP-API.
Außerdem steht in der Wissensdatenbank nun eine Anleitung zur Migration von Parallels® Confixx® zu LiveConfig zur Verfügung. Das dazugehörige Migrationsscript kann unter http://downloads.liveconfig.com/tools/cfximport.php heruntergeladen werden.
Mit diesem Script können die meisten Daten der Reseller und Endkunden aus einem Confixx-System automatisiert zu einem LiveConfig-Server umgezogen werden; ausführlichere Informationen dazu sowie aktuelle Einschränkungen finden sich in dem eben erwähnten Artikel.
Wir freuen uns sehr über Feedback und Anregungen. Da auf Confixx nur lesend zugegriffen wird, kann man jederzeit mal die Migration auf einen (frischen) (virtuellen) Server mit LiveConfig ausprobieren.
Viele Grüße
-Klaus Keppler
Parallels® und Confixx® sind eingetragene Marken der SWSoft Holdings Ltd. (n. Gesetz d. Staates Bermuda), USA.
CatchAll-Adressen sind zwar die reinsten Spam-Magneten, aber wer's unbedingt braucht: ab Version 1.4 (zur CeBIT) gibt's dann auch CatchAll-Adressen. 
Danke für's Feedback & viele Grüße
Klaus Keppler
Sooo, liveconfig-meta wurde auch aktualisiert und in den "main"-Zweig mit aufgenommen. Nach der Installation des Metapakets (also aller Abhängigkeiten) werden nun auch die benötigten Apache-Module automatisch aktiviert, sowie die Apache-Einstellungen "ServerTokens" und "TraceEnable" auf sichere Werte gesetzt.
Eine entsprechend gekürzte Installationsanleitung wird demnächst bereitgestellt.
Zur Installation eines typischen Webhosting-Servers unter Debian/Ubuntu reichen nun folgende Befehle (unter Ubuntu ggf. um "sodu" ergänzen):
wget -O - https://www.liveconfig.com/liveconfig.key | apt-key add -
echo "deb http://repo.liveconfig.com/debian/ main main" > /etc/apt/sources.list.d/liveconfig.list
aptitude update
aptitude install liveconfig-meta liveconfig(ist nun doch ein Vierzeiler geworden ;))
Wir haben nun LiveConfig 1.3.1 zum Download freigegeben. Bei den Änderungen handelt es sich in erster Linie um Bugfixes und Verbesserungen, u.a.:
Viele Grüße
-Klaus Keppler
Ist in der nächsten Version (1.3.1) ebenfalls beseitigt.
Der Fehler wurde gefunden und beseitigt.
Wenn aus einem Hostingvertrag die letzte darin konfigurierte Domain gelöscht wurde, dann wurde diese nicht aus der accesslog.map-Datei entfernt, was zum beschriebenen Verhalten führt.
Sollte man also solche verwaisten Einträge in der /etc/apache2/accesslog.map finden, dann kann man diese getrost von Hand löschen.
Voraussichtlich morgen geben wir dann die Version 1.3.1 frei.
Wir haben inzwischen schon öfter die Anfrage erhalten, inwiefern vielleicht mpm_peruser oder mpm_itk unterstützt werden könnten.
Wir werden das mittelfristig in der Erzeugung der Apache-vHost-Konfigurationen berücksichtigen (mit entsprechenden <IfModule>-Abschnitten).
Wer das bis dahin experimentell ausprobieren möchte, kann Folgendes machen (funktioniert mind. seit LiveConfig 1.2.5):
<IfModule mpm_peruser_module>
ServerEnvironment web1 web1
</IfModule>
bzw.
<IfModule mpm_itk_module>
AssignUserId web1 web1
</IfModule>
Das Ganze setzt natürlich voraus, dass das gewünschte mpm vollständig installiert und vorkonfiguriert ist. Bei mpm_peruser müssen die notwendigen "Processor"-Anweisungen noch in irgendeine "globale" Konfiguration aufgenommen werden (dazu kann man unter Debian z.B. einfach eine Datei /etc/apache2/conf.d/mpm_peruser anlegen).
Die Datei .httpd.conf darf nicht durch den Endkunden beschreibbar sein (sonst kann sich dieser frei in der Apache-Konfiguration austoben).
Die ist ab der nächsten Version schon geändert. 
### BEGIN INIT INFO
# Provides: liveconfig
# Required-Start: $network $syslog $local_fs
# Required-Stop: $network $syslog $local_fs
# Should-Start: $time $named apache2 mysql
# Should-Stop: $time $named apache2 mysql
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
# Short-Description: Start and stop the LiveConfig server control panel
# Description: This script controls the LiveConfig server control
# panel daemon "liveconfig"
### END INIT INFODamit sollte LiveConfig warten, bis u.a. MySQL (falls vorhanden) gestartet wurde.
Aktuell erweitern wir dennoch LiveConfig so, dass automatisch neue Verbindungsversuche gestartet werden. Dürfte somit die sauberste Lösung sein.
Wir haben die Ursache vermutlich gefunden: wenn LiveConfig "zu schnell" gestartet wird (also noch bevor MySQL bereit ist, Verbindungen entgegenzunehmen), dann werden keine weiteren Verbindungsversuche unternommen. Wenn die Verbindung zu MySQL dagegen im Betrieb abreißt (z.B. nach MySQL-Neustart) verbindet sich der LiveConfig-Client aber wieder automatisch.
Wir beseitigen das gerade.
-Klaus Keppler
Ja, in diesem Fall einfach die suPHP-Pakete entfernen - die von LiveConfig erzeugte vHost-Konfiguration greift in diesem Fall auf mod_php zurück.
Backup verwaltung (Mysql, Web-Ordner)
Ja, da ist schon was in Arbeit. Man wird sich quasi ein "Live-Backup" ziehen können, ohne dass dieses erst am Server zwischengespeichert werden muss (spart Speicherplatz). Auch ein Backup der LiveConfig-Einstellungen ist geplant (also alle Postfach- und Domaineinstellungen etc.)
ZitatIPtables Verwaltung
Längerfristig gerne (ist auch sinnvoll), aber aktuell gibt es noch genug andere Bereiche mit höherer Priorität.
Bis dahin kann man die Grundsicherung über die bei der jeweiligen Distribution mitgelieferten Firewallsoftware konfigurieren (bei openSUSE ist ja beispielsweise alles erst mal "dicht")
So oder so - alle Vorschläge hier werden aufgenommen und bei uns archiviert & bewertet.
Viele Grüße
-Klaus Keppler
Das Paket "liveconfig-meta" enthält absichtlich nur die Abhängigkeiten zu den Zusatz-Paketen; wir bereiten noch verschiedene andere Metapakete vor, die z.B. nur alle Pakete für reine Webserver enthalten (ohne MySQL-Datenbank). So kann man sich die gewünschte Basisinstallation nach Belieben aussuchen.
Auf Ubuntu-Distributionen wurden uns noch vereinzelte Probleme bei der Installation über das Metapaket gemeldet; sobald das auch geklärt ist, wird dieses auch im "main"-Zweig im Repository bereitgestellt. Dann reicht ein Dreizeiler zur Installation von LiveConfig und allen Abhängigkeiten.
Ja, suPHP ist da zu Recht sehr vorsichtig. Da PHP-Scripte ohnehin immer mit der Berechtigung des jeweiligen Webspace-Benutzers ausgeführt werden, ist ohnehin kein "World-Writable" notwendig - auch nicht zur Installation von Webanwendungen (selbst wenn das in deren Dokumentation oft so gefordert wird)
Da das aber manche Endkunden verwirrt (die Fehlermeldung ist ja nicht besonders allgemeinverständlich formuliert), kann man diese Restriktionen in suPHP auch lockern - siehe /etc/suphp/suphp.conf:
; Security optionsallow_file_group_writeable=false
allow_file_others_writeable=false
allow_directory_group_writeable=false
allow_directory_others_writeable=falseEinfach von "false" auf "true" stellen, Apache neu starten - fertig.
Viele Grüße
Klaus Keppler
Danke für die ausführliche Beschreibung; wir testen das dann gleich mal durch.
Die Pfade der einzelnen Logs sind in /etc/apache2/accesslog.map hinterlegt (jeweils der "ServerName" aus dem entsprechenden vHost, sowie die dazugehörige Logdatei).
Wenn Sie darin etwas ändern, müssen Sie noch ein HUP-Signal an den lclogsplit-Prozess schicken (killall -HUP lclogsplit)
Eigentlich kümmert sich LiveConfig um eine korrekte Zuordnung der Logfiles und vHosts; falls Ihnen da ein Fehler auffällt, geben Sie bitte kurz Bescheid. Diese Konfiguration ist schon in Setups mit mehreren hundert vHosts im Einsatz, allerdings wurden da bisher offenbar weniger oder noch keine Domains gelöscht bzw. neu zugeordnet...
Viele Grüße
Klaus Keppler
Die error_log von Apache enthält leider keine Informationen, um Log-Einträge irgendwie automatisiert dem jeweils "verursachendem" Hosting-Vertrag (genauer: virtuellem Host) zuzuordnen. Man müsste also für jeden vHost eine eigene error_log definieren. Bei sehr vielen vHosts kann das allerdings dazu führen, dass der Hauptprozess von Apache zu viele Dateien gleichzeitig geöffnet hat (das Filehandle-Limit liegt häufig bei 1024).
(bei den "normalen" access-Logs kümmert sich ein eigener Prozess um das Aufsplitten der Logeinträge; bei LiveConfig ist das der "lclogsplit")
Wir planen, eine eigene Option für's Error-Log bei den Hostingangeboten aufzunehmen. Bei Verträgen, die diese Option dann aktiviert haben, soll der Kunde dann bei Bedarf selbständig das errorlog ein- oder ausschalten können. So hat LIveConfig auch einen Überblick darüber, bei wie vielen vHosts ein Errorlog aktiviert ist.
Für alternative oder ergänzende Ideen sind wir aber natürlich jederzeit offen.
HTTPS wird ab LiveConfig v1.5 (April/Mai) durch LiveConfig unterstützt; hier würde dann für SSL-Zugriffe ein getrenntes Log erzeugt werden (so wie es bei Apache üblich ist). Entsprechend würden wir auch eine zweite Webalizer-Konfiguration für eine Auswertung der SSL-Zugriffe einrichten.
Viele Grüße
Klaus Keppler
in den Server-Details wird nur eine CPU erkannt bzw. angezeigt
Ist auch korrekt; es handelt sich hierbei offenbar um einen virtuellen Server, dem nur eine CPU (bzw. ein Core) zugewiesen ist. Die CPU unterstützt jedoch Hypertreading (siehe CPU-Flag "ht"), daher werden zwei logische CPUs angezeigt.
ZitatEdit: Hier noch ein Eintrag aus der "liveconfig.log".
Code[2012/02/12 13:45:12.337157] [7116|1366664960] Can't get system informations: (null)
Diese Meldung wird erzeugt, wenn nicht auf die DMI-Informationen zugegriffen werden kann (ist oft bei virtuellen Systemen, insbes. bei XEN der Fall)
Viele Grüße
Klaus Keppler
Wie kann man die Fehlermeldung PW oder Benutzername falsch noch besser einbinden so in etwa wie beim Standart.
Bisher wird nur durch den Login-Code von LiveConfig ein Fehler-Popup per alert()-Funktion erzeugt. Ist aber eine gute Idee, das anzupassen - in der nächsten Version (1.3.1) werden wir für "eigene" Fehlermeldungen eine entsprechende Callback-Funktion vorbereiten (ist ja keine große Sache).
Viele Grüße
-Klaus Keppler
Genau; für das o.g. Setup wären eine Business-Lizenz sowie 14 Standard-Lizenzen nötig.
Eine Begrenzung hinsichtlich der Benutzer/Verträge/Domains/etc. besteht nicht.
Viele Grüße
Klaus Keppler
Hmm, das ist ein interessanter Fehler. :-/
Könnten Sie das vielleicht mit einem Beispiel beschreiben?
Ich habe mal versucht das zu rekonstruieren - aber (bisher) ohne Erfolg.
So wie ich das verstanden habe, haben Sie die Domain aus einem Hostingvertrag gelöscht (web1?), dann diesen Vertrag selbst gelöscht, und dann die Domain in einem anderen Hostingvertrag neu hinzugefügt?
Viele Grüße
-Klaus Keppler
