Frage: Was genau stellt eigentlich die Grafik auf der Startseite "Übersicht" dar? Prozentuale Auslastung? Load? Habe hierzu nichts im Handbuch gefunden.
Der Graph der innerhalb des Abschnitts "Prozessor:" angezeigt wird, und beim Klick auf die Vergrößerung in der Legende "User/System/Nice/Wait/..." anzeigt? Der stellt die CPU-Auslastung (in Prozent) dar. Die Graphen werden aber bereits überarbeitet und bekommen in der nächsten Version auch eine Überschrift und eine Bezeichnung für die Y-Achse.
This feature is available with v1.6.4-r2472 (to be released on friday, preview update this evening).
Versuchen Sie mal, vor dem Löschen eines Vertrags auf dem Server erst noch CageFS für den betroffenen Benutzer zu deaktivieren, z.B. so:
/usr/sbin/cagefsctl --disable test123
Prüfen Sie dann, ob das .cagefs-Verzeichnis damit verschwindet. (Quelle)
Falls das so klappt, können wir das gerne mit in LC aufnehmen.
In dem Fall reicht es, nur den lcclient im Vordergrund laufen zu lassen (der ruft schließlich das "rm -rf ..." auf)
An guten Ideen mangelt es zum Glück nicht 
Lassen Sie LiveConfig mal im Vordergrund laufen, während Sie einen Vertrag löschen (also erst "/etc/init.d/liveconfig stop", danach "liveconfig -f"). Sollte es während dem "rm -rf ..." eine Fehlermeldung auf STDERR geben, dann müsste diese auf der Konsole angezeigt werden. (Wenn ich mich richtig erinnere haben wir schon irgendwo auf der ToDo-Liste stehen, alle STDERR-Ausgaben künftig direkt ins LiveConfig-Log zu schreiben.)
So oder so *kann* es aber sein, dass es schlicht von LiveConfig aus nicht funktioniert, da der Prozess in einem anderen Kontext läuft als ein direkt von "root" ausgeführtes Programm.
Viele Grüße
-Klaus Keppler
Hallo,
jein; die zuständige SOAP-Funktion HostingSubdomainAdd() erlaubt noch keine Subdomains (ich baue das morgen noch ein - der RegExp ist aber ein bisserl komplizierter :))
Mit v1.6.4 ist das dann aber erledigt.
Viele Grüße
-Klaus Keppler
Auf welche Art und Weise wird das Vertrags-Verzeichnis denn gelöscht? Ja Richtig, das .cagefs wird durch CloudLinux erzeugt, um jedem Systembenutzer sein eigenes virtuelles Dateisystem zu liefern. Es lässt sich allerdings ganz normal manuell löschen, die Frage ist halt nur, ob man LiveConfig dieses Verzeichnis ggf. an irgendeiner Stelle noch als weiteres zu löschendes Verzeichnis anlegt oder wo es haken könnte.
Was LiveConfig macht kann man in /usr/lib/liveconfig/lua/web.lua, Funktion "deleteAccount()", ca. Zeile 438 sehen:
os.execute("rm -rf " .. home)D.h. es wird mit root-Rechten schlicht ein "rm -rf /var/www/web123" ausgeführt. Warum .cagefs dann übrig bleibt, ist mir auch schleierhaft - ich habe mich aber bislang nur recht oberflächlich mit CloudLinux beschäftigt.
Viele Grüße
-Klaus Keppler
Jepp, da wir hier derzeit keine CloudLinux-Testumgebung haben, wird Letzteres auch noch nicht offiziell unterstützt.
Ich tippe mal darauf, dass das .cagefs-Verzeichnis entweder durch ein Kernelmodul von CloudLinux erzeugt wird, oder dass es irgendwelche erweiterten Attribute besitzt die eine Löschung verhindern.
Was liefert denn "lsattr /var/www/VERTRAG"?
Nein, das klappt leider nicht, weil das zwei grundverschiedene Vertragstypen sind. Sie können dem Kunden aber einen zusätzlichen Reseller-Vertrag hinzufügen, falls das hilft.
Hallo Herr Banse,
welche Distribution genau setzen Sie denn ein? Eigentlich konfiguriert LiveConfig den ProFTPd so, dass man sich sowohl mit Systembenutzern als auch mit virtuellen Benutzern anmelden kann. Die Fehlermeldung ("incorrect password") ist ja auch ziemlich eindeutig - würde der Benutzer nicht existieren, gäbe es eine andere Fehlermeldung.
Wenn sich ein Kunde im LiveConfig anmeldet (oder wenn Sie als "admin" eine Session als Endkunde öffnen), dann können Sie über "Webspace" -> "Hosting" -> "FTP-Accounts" das Passwort für den "Systembenutzer" ändern. Unmittelbar danach sollte ein FTP-Login damit möglich sein.
Viele Grüße
-Klaus Keppler
Hallo Herr Banse,
es freut mich, wenn wir auch vorsichtige Interessenten nun langsam aber sicher überzeugen können
ZitatBeim anlegen eines Kunden wird ein FTP Account eingerichtet. Dieser jedoch wird als Systembenutzer in der /etc/passwd abgelegt. Wird (wie in unserem Falle nun) Proftpd verwendet und von LiveConfig verwaltet, werden die Benutzer aus der /etc/proftpd/passwd ausgelesen. Folglich ist ein Login nicht möglich.
Dass der "Hauptbenutzer" in /etc/passwd angelegt wird, ist so beabsichtigt (schließlich braucht es ja einen "echten" Systembenutzer pro Hostingvertrag). Allerdings sollte normalerweise auch ein FTP-Login mit diesem Benutzer möglich sein - in /etc/proftpd/passwd stehen lediglich die zusätzlichen (virtuellen) FTP-Benutzer.
Welche Fehlermeldung bekommen Sie denn in /var/log/proftpd/proftpd.log, wenn Sie sich als ein "Hauptbenutzer" anmelden möchten?
Unserer Erfahrung nach ist ein häufiger Fehler, dass die Kunden noch kein Passwort für den Standard-FTP-Benutzer im LiveConfig angelegt haben ("Hosting" -> "Webspace" -> "FTP-Accounts", dort dann auf "Passwort ändern..."). Eine Vereinfachung dieses Vorgangs ist bereits geplant (durch ein zufälliges Standard-Passwort, das dem Kunden direkt nach Anlegen des Vertrags auch automatisch per E-Mail zugesendet werden kann).
Viele Grüße
-Klaus Keppler
Wir testen die 1.6.4 derzeit sehr intensiv durch (konkret wurde in den letzten Tagen mehr Code für Tests als für LiveConfig geschrieben); die produktive Freigabe ist für Ende dieser Woche geplant. Da es einige wichtige Änderungen und Bugfixes gab, empfehlen wir, das Update dann auch zeitnah durchzuführen.
Für MI/DO ist eingeplant, dass wir uns dort noch um das Abarbeiten nicht erfolgreich abgeschlossener Transaktionen kümmern (Datenbanken löschen, Verträge löschen usw.).
Viele Grüße
-Klaus Keppler
Was steht in /var/log/liveconfig/liveconfig.log rund um den Löschzeitpunkt?
Bei einem Multi-Server-Setup: was steht zusätzlich in /var/log/liveconfig/lcclient.log auf dem Slave?
Sind gar keine Dateien gelöscht, oder bleiben nur einzelne Dateien übrig?
Ist SELinux aktiviert?
UPDATE 2: der Fehler wurde nun isoliert (siehe Bug Report). Mit Version 1.6.4-r2466 wurde ein Workaround in LiveConfig aufgenommen.
Viele Grüße
-Klaus Keppler
Ab sofort steht v1.6.4-r2466 im Test-Repo bereit, welche einen Workaround für einen Bug in SQLite enthält. Dieser Fehler führt dazu, dass in ganz bestimmten (zum Glück relativ seltenen) Fällen einige SQL-Anfragen keine Ergebnisse zurück liefern, wie beispielsweise die Liste der Domains beim Erstellen/Bearbeiten einer E-Mail-Adresse.
Viele Grüße
-Klaus Keppler
UPDATE: inzwischen haben wir über die SQLite-Mailingliste einen Workaround erhalten, wie sich die (vermutlich) verantwortliche Optimierung abschalten lässt. Ein LiveConfig-Update startet soeben in die Build-Pipeline, in 2-3 Stunden stellen wir das dann online.
Viele Grüße
-Klaus Keppler
Wäre es möglich, dass Sie uns Ihre liveconfig.db mal zusenden? (support@liveconfig.com - die Daten werden unmittelbar nach der Prüfung selbstverständlich gelöscht)
Uns interessieren nur einige bestimmte Tabellen; Sie können also einfach eine Kopie der liveconfig.db anlegen, und dort mit dem SQLite3-Tool folgende Tabellen vorab löschen:
drop table ACCOUNTBLACKLIST;
drop table ACCOUNTS;
drop table APPREPO;
drop table APPS;
drop table APPTEXTS;
drop table APPVARS;
drop table APPVERSIONS;
drop table CAPTCHACACHE;
drop table CONTACTS;
drop table COUNTRIES;
drop table COUNTRYTRANS;
drop table CRONCONFIG;
drop table CRONJOBS;
drop table CUSTOMERS;
drop table CUSTOMLINKS;
drop table DBCONFIG;
drop table DBS;
drop table DBSERVERACCESS;
drop table DBSERVERS;
drop table DNSTEMPLATES;
drop table DOMAINDATA;
drop table EXTNAMESERVERS;
drop table FTPSERVERS;
drop table INTERFACES;
drop table IPGROUPADDRS;
drop table IPGROUPCONFIG;
drop table IPGROUPS;
drop table IPMGMT;
drop table IPS;
drop table LIVECONFIG;
drop table LOG;
drop table MAILALIASES;
drop table MAILBOXES;
drop table MAILFORWARDS;
drop table MAILTEMPLATES;
drop table MODULES;
drop table NAMESERVERIPS;
drop table NAMESERVERS;
drop table OBJECTLOG;
drop table PERMISSIONS;
drop table PHPTEMPLATES;
drop table PHPVARS;
drop table POP3IMAPSERVERS;
drop table PREFERENCES;
drop table PWPATHS;
drop table PWPATHUSERS;
drop table PWRECOVER;
drop table PWUSERS;
drop table RESELLERS;
drop table RRA_CPU;
drop table RRA_DISK;
drop table RRA_MEM;
drop table RRA_NET;
drop table RRA_TRAFFIC;
drop table RRA_WEBSPACE;
drop table RRD_CPU;
drop table RRD_DISK;
drop table RRD_MEM;
drop table RRD_NET;
drop table RRD_TRAFFIC;
drop table RRD_WEBSPACE;
drop table SERVERCONTRACTS;
drop table SERVERS;
drop table SESSIONFILES;
drop table SESSIONS;
drop table SSLCERTS;
drop table TEST1;
drop table TIMEZONES;
drop table TZ_DATA;
drop table TZ_RULENAMES;
drop table TZ_RULES;
drop table USERS;
drop table WEBANALYTICS;
drop table WEBSERVERIPS;
drop table WEBSERVERS;
Wir müssten dann nur noch wissen, bei welchem Vertrag (z.B. "web123") die Domains nicht angezeigt werden.
Besten Dank & viele Grüße
-Klaus Keppler
Hallo,
ab sofort steht v1.6.4-r2464 im Test-Repo bereit. Der Fehler war ein fehlendes "IF EXISTS" bei einem "DROP TABLE"-Befehl; in früheren Testversionen wurde die Tabelle OBJECTLOG nämlich erzeugt, je nach Upgrade-Pfad war diese aber ggf. (noch) nicht vorhanden. 
Viele Grüße
-Klaus Keppler
Hallo seit dem Update auf die neue Preview 1.6.4-r2462 sehe ich bei den Emails die Domains nicht sprich wen ich eine
E-mail erstellen möchte kann ich keine Domain auswählen.
Ja, die Sache hält uns hier ziemlich auf Trab - wir sind da auf einen weiteren Bug in SQLite gestoßen, der selbst in der aktuellsten "trunk"-Version noch nicht beseitigt ist.
[TECH]In SQLite wird seit v3.7.16 sehr viel an der Optimierung von SQL-Anfragen gearbeitet. Wie Knuth schon sagte: »Premature optimization is the root of all evil.« Der neue Query Optimizer sorgt nämlich dafür, dass bei einigen unserer SQLs schlicht gar keine Ergebnisse zurück geliefert werden. Lässt man dann z.B. die ORDER BY-Klausel weg, so erscheinen die Ergebnisse wieder (wenn auch unsortiert). Dass solche Fehler extrem schwer zu finden sind, dürfte klar sein. Eine ältere SQLite-Version ist in unserem Fall leider auch keine Option, da es dort noch einen anderen Fehler gab, der LiveConfig wiederum mit einem SEGFAULT beendet hatte.[/TECH]
Eigentlich sollte sich das Problem erledigen, indem man die Tabellenstatistiken in SQLite aktualisiert (Befehl ANALYZE). LiveConfig führt diesen Schritt beim Update auf r2462 automatisch durch. Bitte prüfen Sie im Log-File (/var/log/liveconfig/liveconfig.log), ob Sie dort den folgenden Eintrag (kurz nach dem letzten Update) finden:
Upgrading database schema (r2455 -> r2456)Ansonsten teilen Sie mir bitte mit, welche Distribution Sie einsetzen, damit wir den Fehler genauer lokalisieren und dem SQLite-Team melden können.
Viele Grüße
-Klaus Keppler
NACHTRAG: Sie können auch testweise mal die LiveConfig-Datenbank /var/lib/liveconfig/liveconfig.db mit dem Programm "sqlite3" öffnen und dort den SQL-Befehl "ANALYZE" ausführen.
Danke für den Hinweis - das ist tatsächlich so nicht beabsichtigt. Auf die Schnelle kann ich noch nicht sagen was genau da schief gelaufen ist, wir werden das jedenfalls noch mal genauer prüfen.
Das Verzeichnis /conf/php5 muss dem Kunden gehören, da sonst der PHP-FastCGI-Starter nicht von suExec ausgeführt wird. Der Fehler ist an dieser Stelle, dass für die php.ini nicht auch das Immutable-Flag gesetzt wird, wie es beim php-fcgi-starter passiert. Wir werden das umgehend in die web.lua mit aufnehmen. Das Update ist spätestens am Montag verfügbar.
Mit folgendem Befehl kann man sich alle php.ini-Dateien anzeigen lassen, die nicht dem Benutzer root gehören:
ls -l /var/www/*/conf/php5/php.ini | grep -v rootViele Grüße
-Klaus Keppler