Der Fehler besteht mit der Version 1.7.0 (r2704) immer noch ...
Ich weiß, sonst hätten wir das ja auch ins Changelog geschrieben. Der Punkt ist noch in Arbeit, wir wollten die anderen Sachen aber nicht länger warten lassen.
Der Fehler besteht mit der Version 1.7.0 (r2704) immer noch ...
Ich weiß, sonst hätten wir das ja auch ins Changelog geschrieben. Der Punkt ist noch in Arbeit, wir wollten die anderen Sachen aber nicht länger warten lassen.
"Unlimited webspace" means, that there will be no filesystem quota configured - the user then can upload any data until the server (or to be more exactly: the partition containing his webspace) is "full".
"Unlimited mailquota" is nearly identical - the user can create as many mailboxes as he wants to (as long there's no limit on the number of mailboxes) and give them an arbitrary mailbox quota size.
Both limits (webspace quota and mailbox quota) are managed independently, because they're enforced differently (webspace via filesystem quota, mailbox via maildirsize quota) and might be rolled out on different servers.
Thanks!
Meanwhile, we have an update available (v1.7.0-r2704) which should fix this issue. We've moved the relevant sorting code to another place which should be more reliable. But I will take a look at your environment settings and try to reproduce this behaviour anyway.
Best regards
-Klaus Keppler
Ist inzwischen auch behoben (seit 1.7.0-r2694).
Viele Grüße
-Klaus Keppler
Hallo,
der Fehler wurde gefunden und beseitigt: je nach Installation lieferte beim sogenannten "prerm"-Script (das während der Deinstallation der "alten" Version ausgeführt wird) der Aufruf von "which invoke-rc.d" kein Ergebnis zurück, was dann zu einem falschen Aufruf des Init-Scripts zum Beenden vom lcclient führte.
Das Update (v1.7.0-r2704) steht ab sofort zur Verfügung. Allerdings steckt der Fehler selbst ja im "alten" lcclient-Paket, d.h. bei diesem Upgrade kann es noch dazu kommen, dass der (alte) lcclient nicht korrekt beendet werden kann.
Am einfachsten ist es daher, vor dem Update den lcclient manuell zu beenden ("/etc/init.d/lcclient stop"). Nach dem Update sollte der Client dann automatisch wieder gestartet werden.
Viele Grüße
-Klaus Keppler
Zur Info: ab sofort steht v1.7.0-r2704 zum Download bereit. Eine Liste aller Änderungen findet sich im Changelog.
Viele Grüße
-Klaus Keppler
Das Update (v1.7.0-r2704) steht ab sofort zum Download bereit.
Das Update wurde eben freigegeben - der Fehler sollte damit behoben sein.
Hallo,
wahrscheinlich ist das Paket "php5-cli" nicht installiert (das wird benötigt, um die Installations-Scripte auszuführen).
Viele Grüße
-Klaus Keppler
Es gab hier eine gut gemeinte aber im Detail leider fehlerhafte Änderung in der RPM .spec-Datei; die "liveconfig.conf" wurde nicht mehr als config-Datei markiert, sondern durch die Installations/Update-Funktion aus der liveconfig.conf-dist heraus erzeugt; damit wollten wir die Installationsfunktionen zwischen den verschiedenen Distributionen vereinheitlichen.
Leider löscht RPM in diesem Fall auch die "nicht merkierte" liveconfig.conf beim Upgrade.
In den automatisierten Tests hier war das nicht aufgefallen, da wir dort ohnehin immer mit der Standardkonfiguration arbeiten.
Der Fehler ist ab v1.7.0-r2700 beseitigt; falls bereits eine liveconfig.conf existiert die von der Standard-Datei abweicht, wird nun spezifikationsgemäß eine liveconfig.conf.rpmnew angelegt.
Der Client (lcclient.conf) war hiervon nicht betroffen.
Viele Grüße
-Klaus Keppler
Danke für den Hinweis, ist im nächsten Update (ab 1.7.0-r2700) beseitigt (wird in Kürze freigegeben)
Es gab eine Änderung bei der Anzeige der Postfachgrößen (reine Weiterleitungen, die bisher mal ein Postfach waren und nun noch nicht abgeholte Mails haben, werden mit der tatsächlich belegten Größe in der Summe berücksichtigt; hier gab es einen Fehler im SQL, der bei NULL-Werten zu einem NULL-Ergebnis geführt hat)
Viele Grüße
-Klaus Keppler
Wir können den Fehler hier nach wie vor nicht reproduzieren, auch nicht auf Debian 6.
Im betroffenen Webspace-Verzeichnis sollte es eine Datei namens ~/logs/backup.log geben (also /var/www/webxxx/logs/backup.log) - stehen da irgend welche Meldungen drin?
Falls nicht, führen Sie den tar-Befehl bitte mal manuell aus:
Bei welcher LiveConfig-Version genau ist der o.g. Fehler im Log aufgetaucht, und welche Linux-Distribution verwenden Sie?
I tested DNS here on a Ubuntu 12.04, works without any problems. :-/
Can you please send the output of "liveconfig --diag" and "set | grep ^L" (showing all environment variables starting with L) to support@liveconfig.com (or via PM here in the forum)? Thanks!
Testweise fügen Sie bitte folgende Einstellung in /etc/liveconfig/liveconfig.conf hinzu und starten LiveConfig dann neu:
Was die Einstellung bewirkt steht ganz gut auf der SQLite-Website (PRAGMA synchronous) beschrieben. Standard ist "2", mit "1" ist man aber auch ziemlich sicher (schließlich verwaltet LiveConfig ja keine Finanztransaktionen ![]()
Wir haben bereits eingeplant, das Intervall konfigurierbar zu machen (ein Interessent mit einer fünfstelligen Zahl an Webspaces hat das auch schon angeregt ;)). Hierzu wird es eine Art "Registry" in LiveConfig geben, wo sich das tunen ließe.
Das löst aber nicht das eigentliche Problem, sondern entzerrt es nur.
Mir kommt ein Hänger von 30min schon äußerst lang vor, zumal bei dieser vergleichsweise geringen Zahl an Webspaces keine großartigen Datenmengen anfallen.
Wenn Sie möchten, können Sie uns gerne mal die URL Ihrer LiveConfig-Installation schicken (per PN oder Mail). Wir haben hier eine Smokeping-Installation, mit der wir das Verhalten mal für 24-48 Stunden aufzeichnen können.
Prüfen Sie bitte auch mal den I/O-Durchsatz der Festplatten (hdparm -t ...) - vielleicht gibt es da ja irgendwo einen I/O-Flaschenhals?
Welche Meldungen erscheinen beim .tar.gz-Backup im LiveConfig-Log (/var/log/liveconfig/liveconfig.log)?
Ob das Backup mit tar oder zip erzeugt wird sollte LiveConfig eigentlich ziemlich egal sein, da das in beiden Fällen identisch stattfindet (das jeweilige Programm wird aufgerufen, und dessen Ausgabe per Pipe zum Browser gesendet).
Haben Sie den .tar.gz-Download auch mal mit einem anderen Browser oder von einem anderen Computer aus getestet?
Hallo,
LiveConfig sammelt alle 5 Minuten einige Statistikdaten ein und sortiert diese in die Datenbank (u.a. HTTP-Traffic und -Zugriffe, Webspace- und Mailbox-Quota, u.v.m.). Je nachdem wie viele Daten das sind (hängt hauptsächlich von der Anzahl der Webspace-Verträge ab) und wie schnell bzw. langsam die Festplatten sind, kann das durchaus zu einer spürbaren Verzögerung führen.
Gerade günstige virtuelle Server mit einem hohen I/O-Grundrauschen in der Hostmaschine wirken sich da aus.
Melden Sie sich einfach mal als "admin" im LiveConfig an - im CPU-Graphen (gleich auf der Übersichtsseite) sehen Sie dann schon eventuelle Ausschläge. Wie viele Verträge verwaltet Ihre LiveConfig-Installation denn derzeit etwa?
Sie können LiveConfig ggf. recht bequem von SQLite auf MySQL als Datenbank-Backend umstellen: http://www.liveconfig.com/de/kb/15
Viele Grüße
-Klaus Keppler
Which linux distribution do you use? If Debian/Ubuntu: 32 or 64 bit?
Thanks!