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)?
auch siehe Handbuch: http://www.liveconfig.com/de/h…g.html#server.config.http
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:
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.
In der my.cnf müssen noch folgende Zeilen angefügt werden:
[client]
socket=/var/lib/mysql/mysql.sockSiehe Anleitung unter http://www.liveconfig.com/de/kb/6
Zum einen muss das Paket "scponly" auf dem Server installiert sein (werden wir am besten gleich mal mit ins meta-Package aufnehmen). Außerdem muss in /etc/ssh/sshd_config die Anmeldung per Passwort erlaubt sein (PasswordAuthentication Yes).
Beim Test eben haben wir aber festgestellt, dass Debian das scponly-Binary unter /usr/bin/scponly ablegt, der passwd-Eintrag als Shell aber /bin/scponly verwendet. :-| Wir werden das gleich mal im dazugehörigen Lua-Script korrigieren.
Die Passwd-Einträge können Sie mit folgendem Befehl korrigieren:
sed -i -e 's/\/bin\/scponly$/\/usr\/bin\/scponly/' /etc/passwdWer möchte, kann mit mod_sftp aber auch den kompletten ProFTPd auf SFTP umstellen. Ein normaler (unverschlüsselter) Zugriff über FTP ist dabei aber nicht mehr möglich, und entweder ProFTPd oder SSHd müssen auf einen anderen Port gelegt werden (SFTP läuft nunmal auch via Port 22).
Für verschlüsselte FTP-Verbindungen empfehlen wir aber lieber FTPS (also FTP mit TLS) zu verwenden. Das ermöglicht auch die Verwendung zusätzlicher FTP-Accounts eines Kunden (scponly/SFTP klappt nur mit dem Systemaccount). In der nächsten LiveConfig-Version gibt es die Möglichkeit, in der FTP-Konfiguration direkt die TLS-Unterstützung zu aktivieren. Falls Sie das vorab manuell konfigurieren möchten, geben Sie mir bitte einfach Bescheid, dann stelle ich eine kurze Anleitung dafür zusammen.
Viele Grüße
-Klaus Keppler
Ok, Fehler wurde lokalisiert und im nächsten Update (Anfang Mai) behoben.
Vorläufiger Workaround: legen Sie ein Hostingangebot ohne weitere Leistungen an, und weisen Sie dieses Angebot dem Kunden zu (Sie können auch den existierenden Vertrag bearbeiten und dort das neue Angebot auswählen). Die Vertragseigenschaften können Sie ja dann trotzdem alle individuell einstellen. So erhält der Kunde aber alle nötigen Berechtigungen.
In ca. 2-3 Stunden gibt es ein LiveConfig-Update (v1.4.2), der o.g. Bugfix wird es dort aber nicht mehr mit hinein schaffen.
Viele Grüße
-Klaus Keppler
Ah, ich sehe das Problem... wenn man einen Kunden mit einem individuellen Vertrag anlegt, dann werden die Standard-Rechte nicht zugewiesen.
Wir schauen uns das gleich mal an - ich melde mich dann noch mal.
Hallo,
sobald dem Kunden ein Hostingvertrag zugewiesen wird, erhält er damit automatisch das Recht für's Web-Login.
In der Kunden-Übersicht werden nur die effektiven Berechtigungen eines Kunden angezeigt, ein Bearbeiten ist dort nicht möglich (die Rechte erhält man eben implizit über die jeweiligen Verträge).
Ich hoffe, dass das nicht zu verwirrend ist?
Viele Grüße
-Klaus Keppler
Wenn ich das richtig sehe, haben Sie auf Server2 in /etc/liveconfig/lcclient.conf unter "server=" auch die Adresse von Server2 eingetragen? Verwenden Sie bitte die IP (oder Hostname) von Server1 - mit dem soll sich der LiveConfig-Client ja verbinden. 
Siehe auch LCCP-Protokoll-Einstellungen (wir werden das dort besser noch etwas ausführlicher beschreiben)
Hallo,
das Vorgehen scheint soweit in Ordnung zu sein.
Es scheint das der "lcclient" kein eigenes Administrationsinterface hat, da ich per browser den "gewohntem" link kein Interface erhalte
Ja, deshalb ist es ja ein Client. 
Diese LiveConfig-Instanz verbindet sich über Port 788 mit dem LiveConfig-Serverprozess auf Server1 - von wo aus dann alles Weitere gesteuert wird.
ZitatAuf beiden Servern habe ich in ipTables den TCP Port 788 freigegeben und auch schon die Server neugestartet.
- erhalten Sie irgendwelche Fehlermeldungen auf Server2 in /var/log/liveconfig/lcclient.log ?
- können Sie testweise auf Server2 ein "telnet <server1> 788" machen? Die Verbindung sollte eigentlich sofort angenommen werden.
Viele Grüße
-Klaus Keppler
Wer Zustellprobleme an web.de hat, sollte gründlich prüfen, ob der eigene Mailserver komplett richtig konfiguriert ist. Dazu gehört insbesondere, ob der HELO-Name (/etc/mailname) identisch mit dem Hostnamen ist, ob dessen IP richtig eingetragen ist und ob der Reverse-DNS-Eintrag ebenfalls stimmt.
web.de hat neue Spamfilter im Einsatz, die alle nicht 100% konformen Mailverbindungen ablehnen.
Viele Grüße
-Klaus Keppler
Haben Sie eventuell die Datei /etc/apache2/accesslog.map gelöscht?
Falls diese existiert, dann fehlt offenbar die folgende Zeile:
default /var/log/apache2/access.logViele Grüße
-Klaus Keppler