die Anzeige und Ausgabe der Logs funktioniert nur, wenn ich das Fehlerprotokoll einmal aktiviert habe. Bei Verträgen, wo dies nicht der Fall ist, da funktioniert es nicht.
Genau das war das Problem. Wir haben das inzwischen beseitigt, eine neue Version wird im Laufe des Nachmittags bereitgestellt.
Viele Grüße
-Klaus Keppler
Welche App/Plattform verwenden Sie? iPhone? Android? Welche OS-Version?
Was noch nicht läuft ist DNS.
In der aktuellen Version (1.6.2) kann LiveConfig noch keine DNS-Zonen verwalten, das kommt mit der nächsten Version. Die meisten Domainregistrare bieten aber auch die Möglichkeit, deren Nameserver mit zu nutzen - dann müssen Sie lediglich die IP-Adresse Ihres Servers bei den Domains hinterlegen (sogenannte "A-Records").
Viele Grüße
-Klaus Keppler
Wer unter den Hosting Accounts FastCGI nutzt sollte sich alle PHP.INI Dateien in allen Verträgen sichern.
Wenn man zb. Safe_Mode ON hat, ist es nach dem Update auf OFF gestellt.
Bitte prüfen Sie, welche Einstellungen Sie in LiveConfig in der php.ini-Verwaltung haben - ich schätze mal, dass dort safe_mode auf "off" gesetzt war.
Um das kurz klar zu stellen: mit Ausführung des Updates werden die php.ini-Dateien nicht automatisch überschrieben. Erst bei Änderungen an einzelnen Webspace-Einstellungen oder wenn die Einstellungen in der "php.ini-Verwaltung" angewendet werden, aktualisiert LiveConfig die .ini-Dateien.
Also bei mir funktioniert die Log Anzeige noch nicht. Beim acccess.log wird, bis auf der Ladekringel, einfach nichts angezeigt obwohl neue Logeinträge nachweisbar geschrieben werden
Welche Distribution verwenden Sie?
Könnten Sie bitte mal von irgendeinem betroffenen Webspace die Ausgabe von folgendem Befehl posten:
ls -al /var/www/web###/logsIst es möglich über die php.ini-Verwaltung Einstellungen wie z.B. das memory_limit nur für einzelne Kunden vorzunehmen?
In der aktuellen Version ist das leider noch nicht möglich - aber für die Zukunft berücksichtigt: bei jeder Einstellung können Sie festlegen, ob diese individuell pro Vertrag oder sogar direkt durch den Kunden bearbeitet werden darf. Bei numerischen Einstellungen (z.B. eben auch memory_limit) kann dann sogar noch festgesetzt werden, in welchem Rahmen sich das bewegen soll (damit z.B. nicht ein Reseller einem seiner Endkunden 9999 MB RAM zuweist...)
Die Masken und Routinen zum Bearbeiten dieser Einstellungen pro Vertrag bzw. durch den Kunden sind etwa zur Hälfte fertig gestellt und sind im nächsten Update enthalten (v1.6.3).
Ab sofort steht LiveConfig in der Version 1.6.2 zum Download bereit. Eine genaue Liste aller Änderungen finden Sie im Änderungsverlauf.
Die wichtigsten neuen Funktionen sind:
Derzeit stellen wir außerdem den Build-Prozess für LiveConfig so um, dass neue Features künftig schneller in die "produktive" Versionsreihe einfließen können.
Das gesamte Entwicklerteam bedankt sich an dieser Stelle für die zahlreichen Rückmeldungen bei den Preview-Versionen, für die vielfältigen Ideen und Anregungen sowie für das grandiose Feedback für LiveConfig insgesamt!
Eben wurde v1.6.2-r2361 online gestellt (die Änderungen zu r2354 sind marginal, fast ausschließlich "Schönheitskorrekturen").
Diese Version wird in den nächsten 1-2 Stunden auch produktiv freigegeben.
Ein ausführliches Changelog, Infos zum nächsten Release usw. folgen dann zeitnah im Forum und auf der Website.
v1.6.2 ist somit "fertig". Funktionen, die fast fertig sind und es nicht mehr in dieses Release geschafft haben, kommen in den nächsten Tagen in die Preview-Version (das dauert dann also auch nicht länger, dafür sind nun alle abgeschlossenen Funktionen für alle Nutzer verfügbar).
An dieser Stelle noch mal vielen Dank für die zahlreichen Feedbacks zu den Preview-Releases!
[Nachtrag] aus r2360 wurde nun doch r2361... 
Danke für den Hinweis. Im Grunde ist das ein Fehler in ownCloud: falls die Funktion disk_free_space() einen ungültigen Wert zurück liefert (z.B. weil diese eben gesperrt ist), dann sollte ownCloud den Upload auch nicht verhindern.
Da ich weiß dass viele LiveConfig-Anwender auch ownCloud nutzen, haben wir diskfreespace/disk_free_space ab r2360 wieder standardmäßig aus disable_functions entfernt. Streng genommen ist es keine sicherheitskritische Information, wie viel Speicherplatz auf einem Server noch frei ist - es ist aber ein klassisches Informations-Leck, das einen Endkunden im Grunde nichts angeht. Last but not least berücksichtigt disk_free_space auch nicht das tatsächliche Quota des Benutzers, sondern liefert nur zurück, wie viel Speicherplatz noch auf der jeweiligen Partition insgesamt frei ist.
Verstehe ich das richtig, dass Sie ein Multiserver-Setup vorgenommen haben, und sich nun der LiveConfig-Client (wo auch immer der läuft) nicht mit LiveConfig auf dem Server 5.135.249.57 verbinden kann?
Wenn ja, läuft auf dem Server (5.135.249.57) auch tatsächlich LiveConfig? (ps aux | grep liveconfig)
Ist bereits in der aktuellen Preview-Version (seit v.1.6.2-r2264) enthalten. 
Viele Grüße
-Klaus Keppler
Eben wurde noch ein Fehler in der Preview-Version entdeckt und beseitigt, der sich mit r2337 (15.05.2013) eingeschlichen hatte. Beim Sperren von Kunden wurden in einigen Fällen zu viele Accounts gesperrt (statt nur den betroffenen Kunden wurden alle Kunden des ausführenden Benutzers gesperrt). Wer also mit einer Preview-Version ab r2337 mindestens einen Kunden gesperrt hat, sollte am besten mal mit "grep 'lock user' /var/log/auth.log" prüfen, ob unerwünscht auch weitere Accounts gesperrt wurden. Um das ggf rückgängig zu machen reicht es, in LiveConfig bis r2353 einfach den ursprünglich gesperrten Kunden wieder zu entsperren (dabei werden auch alle anderen fälschlicherweise gesperrten Kunden wieder entsperrt).
Mit r2354 ist der Fehler beseitigt. Sollten Sie von dem Fehler betroffen sein, bitten wir um Entschuldigung - falls Sie Unterstützung beim "Aufräumen" brauchen, melden Sie sich bitte einfach kurz unter support@liveconfig.com
Viele Grüße
-Klaus Keppler
Die Version ist noch nicht Offiziell herausgegeben worden von euch oder?
Nein, sonst würde diese ja auch auf den offiziellen Download-Seiten (http://www.liveconfig.com/de/downloads) auftauchen. Wir sind aber nur noch mit "Aufräumarbeiten" für dieses Release beschäftigt (einen Termin nenne ich mal lieber nicht, bevor ich wieder festgenagelt werde - es dauert aber nicht mehr lange)
Das bei Ihnen aufgetretene Problem mit dem AppInstaller sollte damit dann auch beseitigt sein, da LiveConfig nun zu restriktive php.ini-Einstellungen für die Installation ausdrücklich aufhebt.
Narf.
Kein Problem. Der Webserver ist eh so konfiguriert, dass auch HTML-Dateien mit einem Expire +3Days ausgeliefert werden - für kurzfristig geänderte Seiten kommt man um ein explizites "Reload" also auch nicht herum. Zort!
Ja, einfach mal Reload machen.
Ab sofort steht noch ein Update bereit (r2353), welches insbes. ein Berechtigungsproblem beim AppInstaller behebt.
Zitatkönnten Sie uns noch die Dokumentation für die neue SOAP API zur Verfügung stellen ?
Selbstverständlich - wir schreiben aber erst noch die Tests für die neuen Funktionen fertig; sobald das abgeschlossen ist, gibt's noch mal ein Update des Preview-Handbuchs (im WSDL sind die neuen Funktionen "CustomerUpdate()" und "HostingSubscriptionDelete()" schon zu sehen - aber wie gesagt: UNGETESTET!)
Zitatkann mir vielleicht jemand die php.ini Einstellungen VOR der neuen ini Verwaltung nennen?
Oder kam die gar nicht von liveconfig?
Welche Einstellungen genau meinen Sie?
LiveConfig nimmt als Grundlage immer die "zentrale" php.ini (/etc/php5/cgi.d/php.ini) und passt dann alle Werte gemäß der Einstellungen aus dem Menüpunkt "php.ini-Verwaltung" an.
Weitere Informationen zur php.ini finden Sie in KB#19.
Ab sofort steht ein Update bereit (r2353), welches das Problem beheben sollte. Mit r2347 wurden die Verzeichnisrechte modifiziert - in diesem Fall leider "zu" sicher. Die automatischen Tests sind in Bezug auf den AppInstaller leider nicht nicht vollständig genug, um diesen Fehler zu erkennen - künftig wird das aber auch geprüft.
[Nachtrag] Ich habe zwei thematisch identische Threads zusammengefasst...
Die Fehlerbeschreibung deutet darauf hin, dass beim betroffenen Server der Client-Teil von LiveConfig hing und keine Jobs mehr verarbeitet hat. Dessen Architektur wurde kürzlich überarbeitet (fließt in v1.7.0 mit ein), so dass "Hänger" automatisch erkannt und der Client automatisch neu gestartet wird.
Haben Sie irgendwelche auffällige Meldungen im liveconfig.log (bzw. beim Multiserver-Setup im lcclient-Log des betroffenen Zielservers)?
Sie können die "halb gelöschten" Verträge noch mal zurücksetzen indem Sie folgenden SQL-Befehl in der LiveConfig-Datenbank ausführen:
UPDATE HOSTINGCONTRACTS SET HC_DELETED=0 WHERE HC_DELETED=1;Anschließend sollten die betroffenen Verträge wieder "normal" im LiveConfig auftauchen - dort können Sie diese dann erneut löschen.
Alles anzeigensqlite> select * from customers;
1|1|1|14|0|0|1|1|1|0|...
4|3|1|14|3|1|6|6|6|0|...
5|3|1|4|2|1|4|4|4|0|...
7|3|5|14|6|1|7|7|7|0|...
10|3|7|14|9|1|8|8|8|0|...
12|3|9|14|11|1|10|10|10|0|...
14|3|11|14|13|1|11|11|11|0|...
Da ist ernsthaft etwas in der Datenbank korrupt. Die Spalten 2-4 (CUST_IDLEVEL, CUST_IDLEFT und CUST_IDRIGHT) dienen der Verwaltung der Struktur/Hierarchie der Kunden. Hier gibt es neben dem Admin (CUST_ID=1, CUST_IDLEVEL=1) nur noch Kunden mit der Ebene CUST_IDLEVEL=3 - da fehlt also was. Auch die Baumstruktur (Nested Set mit IDLEFT/IDRIGHT) ist fehlerhaft.
Haben Sie eventuell mal manuell in die Tabelle CUSTOMERS eingegriffen?
Falls nicht, wäre es natürlich hochinteressant, ob sich dieses Verhalten mit einer "frischen" Datenbank reproduzieren lässt.
Welche Kunden/Reseller/Benutzer sollen denn am Ende noch übrig bleiben? Die überflüssigen Einträge könnten Sie durchaus direkt in der Datenbank löschen, allerdings muss dann noch die Baumstruktur in der CUSTOMERS-Tabelle korrigiert werden.
Schicken Sie uns einfach nach dem Löschen noch mal die selben Tabellen-Dumps wie im obigen Forums-Beitrag an support@liveconfig.com, dann kann ich Ihnen die notwendigen Korrektur-SQLs zurück schicken.
Viele Grüße
-Klaus Keppler
