Testweise fügen Sie bitte folgende Einstellung in /etc/liveconfig/liveconfig.conf hinzu und starten LiveConfig dann neu:
db_options = synchronous=1Was 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.
Um dann mal einen Zwischenstand zu geben: wir können den von Ihnen beschriebenen Fehler bislang nicht reproduzieren, haben das hier intern aber noch als Ticket offen.
Ansonsten steht Ihnen unser Support auch gerne unter support@liveconfig.com zur Verfügung, oder zu den üblichen Bürozeiten auch telefonisch.
Wenn Sie die Lizenz direkt bei uns gekauft haben, erreichen Sie das Lizenzportal unter https://www.liveconfig.com/license
Als Login verwenden Sie bitte die E-Mail-Adresse, an die Sie ihre monatliche Rechnung erhalten.
Aber wieso erscheint nicht der übliche Screen?
Kann ich pauschal nicht sagen - LiveConfig nutzt die Standard-Funktionen von Debian für das Installationsmenü. Wenn das verwendete Terminal keine interaktive Eingabe unterstützt oder z.B. eine nicht-interaktive Installation eingestellt ist, wird kein Menü gezeigt.
Eventuell erhalten Sie das Menü mit "dpkg --reconfigure liveconfig".
ZitatWie komme ich an meine Vorhandene Lizenz?
Wenn das ein neuer Server ist, wie wollen Sie da an die vorhandene Lizenz kommen?
Rufen Sie "liveconfig --activate" auf, und geben Sie dort den Lizenzcode ein. Wenn Sie diesen nicht mehr wissen, dann erhalten Sie diesen dort wo Sie LiveConfig bestellt haben (also bei Ihrem LiveConfig-Partner oder - wenn Sie LC bei uns bezogen haben - im LiveConfig-Lizenzportal).
Die Installation verlief durchaus erfolgreich.
Wenn keine Eingabeaufforderung für den Key kam (z.B. weil auf dem Server früher schon mal LiveConfig aktiviert wurde), einfach "liveconfig --activate" ausführen (so wie es angezeigt wird oder auch im Handbuch steht ;))
Hinterlegen Sie einfach eine Mailadresse für Cronjobs (ganz oben auf der Cronjob-Seite auf den kleinen "bearbeiten..."-Button klicken). Dann bekommen Sie eventuelle Ausgaben/Fehlermeldungen per Mail gesendet.
Alternativ steht in /var/log/messages bzw /var/log/syslog was bei der Ausführung von Cron-Jobs ggf passiert ist.
Wir sind an dem Thema dran. Selbst für uns lässt sich das aber schwer bis gar nicht reproduzieren (auf unseren eigenen Servern ist das bislang nicht aufgetreten). 
Morgen starten wir aber einen größeren Client-Test mit verschiedenen Plattformen - ich hoffe dass wir so gegen Mittag die ersten Ergebnisse haben. Ich gebe dann umgehend hier Bescheid...
At a first glance, the configuration looks valid.
Please connect to your server via SSH and - as root user - issue the command "rndc reload domain.com". You then should see some log messages in /var/log/messages or /var/log/syslog if and why the zone was rejected by BIND.
Nebenbei, bei Update auf 1.7.0-r2696 (CentOS) wird die /etc/liveconfig/liveconfig.conf gelöscht.
Oha, das soll natürlich nicht passieren. :-/ Wie haben Sie das Update ausgeführt - mit "yum update" oder per rpm?
Hallo,
seit v1.6.4 (um genau zu sein: seit r2437) wird die Anweisung "SSLProxyEngine On" in die Apache-Konfiguration aufgenommen, wenn das Ziel eine HTTPS-URL ist.
Ich habe das eben noch mal getestet, funktioniert hier auch einwandfrei.
ZitatReason: Error during SSL Handshake with remote server
Aktivieren Sie bitte mal das Fehlerprotokoll für den betroffenen Vertrag (Webspace -> Fehlerprotokoll, Button "aktivieren") und rufen nach ca. 1 Minute noch mal die Proxy-Domain auf. Welche Fehlermeldung wird dann genau protokolliert?
Viele Grüße
-Klaus Keppler
Angebote -> Bearbeiten -> Karteireiter "php.ini"
[Nachtrag] Öha... komisch... ich sehe gerade, dass dieser Tab fehlt. Werde ich gleich mal prüfen - eigentlich sollten da nämlich tatsächliche die php.ini-Einstellungen für Angebote verwaltbar sein...
[Nachtrag 2] Hmm, dieser Tab war im Code noch auskommentiert, da der Code gemerged wurde bevor die erste Preview-Release erfolgte. Am Montag gibt's also ein Update, mit dem das dann auch (wieder) klappt. 
