Beiträge von kk

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:

• melden Sie sich per SSH auf dem Server an
• wechseln Sie in den Kundenaccount ("su -s /bin/bash webXXX")
• wechseln Sie in dessen Homeverzeichnis ("cd ~")
• führen Sie tar aus: "tar czv apps htdocs >priv/test.tgz"
• wird die tgz-Datei korrekt erzeugt? Gibt es irgendwelche Bildschirmmeldungen?

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:

db_options = synchronous=1

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

If you like, you can try this: open or create /usr/lib/liveconfig/lua/custom.lua and add the following line:

os.setlocale("C")

This will (re)set the default sort order, which might also affect the Lua part.
Then please restart LiveConfig, and delete/add your zone again.

Which linux distribution do you use? If Debian/Ubuntu: 32 or 64 bit?
Thanks!

Please edit the file /usr/lib/liveconfig/lua/bind.lua and remove the two comment dashes from line 604:

table.sort(data.rr)

Then restart LiveConfig, delete your domain and add it again. Then please check if the zone is valid now.

The behaviour is really strange, as LiveConfig indeed sends the NS records first, but your zone file proves that they "arrive" in a wrong order - without any resorting in between! However, LiveConfig often uses standard structures (eg. arrays from C++ STL), I assume that the different behaviour is hidden here anywhere...

Hmm, I've just tested this with both SQLite and MySQL as database backend for LiveConfig, and in both cases my zone files were correct.
Which database do you use as backend?

Ok, found it: the sort order of the resource records within the zone file is wrong (the records without a host part (NS, MX) must appear before the other records (dev, www).
We'll fix this immediately (we'll have to check where this wrong sort order comes from - maybe it depends on the database locale).

Wir haben den Fehler schon lokalisiert, das liegt an einer Datenbankabfrage die - je nach Daten - eine falsche (in diesem Fall leere) Liste an PHP-Einstellungen zurückliefert (daher ist es hier bei uns auch nicht vor dem Release aufgefallen). Update ist schon in Arbeit.