Beiträge von kk

    Ich skizziere mal kurz, was gerade in Arbeit ist - weitere Anregungen sind (wie immer) herzlich willkommen.
    Wie an anderer Stelle schon beschrieben sollen Kunden die Möglichkeit haben, ein "dynamisch erzeugtes" Backup herunterzuladen. Es wird also nicht erst ein .tgz auf dem Server erzeugt, welches dann später irgendwann per FTP abgeholt werden kann, sondern mit Klick auf einen speziellen Download-Link stellt LiveConfig alle relevanten Daten in einem .ZIP- oder .tar.gz-Stream bereit.
    Aktuell werden für Webspace und Datenbanken (sowie später für E-Mails) jeweils separate Download-Links erzeugt, da sich diese Inhalte prinzipiell auf verschiedenen Servern befinden können.
    Womit wir schon beim nächsten Problem wären: in einer Multi-Server-Umgebung klickt der Kunde zwar auf dem "Hauptserver" herum, sein Webspace kann sich aber auf einem anderen Server befinden. Ein Download müsste also - um "sauber" stattzufinden - vom Webspace-Server über den LiveConfig-Hauptserver zum Browser gesendet werden. In den meisten Setups befinden sich alle mit LiveConfig verwalteten Server ja im selben Subnetz am selben Standort, was also keine Traffickosten verursachen sollte - dennoch ist es eigentlich unnötiger Traffic. Eleganter wäre es, wenn der Download direkt vom jeweiligen Quellserver stattfände. Ein LiveConfig-Client kann durchaus einen temporären Server-Socket öffnen, von dem ein Browser dann den Download starten kann. Damit das halbwegs sicher ist (schließlich können ja auch vertrauliche Daten dabei sein) sollte diese Verbindung aber SSL-gesichert sein. Tjo - und da wären wir wieder beim Zertifikats-Problem - sofern man nicht wirlich für jeden Server ein eigenes, "offizielles" SSL-Zertifikat besitzt, würde also eine Sicherheitswarnung erscheinen.


    Ich hoffe, ein wenig Licht in unsere Überlegungen gebracht zu haben.
    Die erste Implementierung sieht nun vor, dass der Stream vorerst ggf. über den Hauptserver geleitet wird, damit Besucher keine Zertifikatswarnung bekommen. Im nächsten Schritt sollen "statische" Download-Links generiert werden können, mit denen man dann z.B. mit wget einen Backup-Download automatisieren könnte.
    Eine weitere Idee ist, dass Benutzer einen SSH-Key hinterlegen können, mit dem ein rsync-Zugriff möglich wäre (mit entsprechender Einschränkung der Key-Verwendung).


    Viele Grüße


    -Klaus Keppler

    Wenn es darum geht, den kompletten Server zu sichern, ist TAR & FTP die absolut ungünstigste und ressourcenlastigste Lösung (nur weil andere Control-Panels das so machen heißt nicht, dass das gut ist...).


    Die meisten unserer Kunden sichern komplette Server über Lösungen auf Basis von rsync (eigene Scripts oder BackupPC) oder erzeugen gleich Images über virtualisierte Storage (also Snapshots).


    Wir planen für Endkunden ein bequemes Backup einzelner Webspaces (Download des Webspaces & Datenbank-Dumps als .tar.gz/.zip-Datei, die on-the-fly erzeugt werden). Außerdem gibt es noch ein paar Ideen in Richtung Cloud Storage (ownCloud, Dropbox, ...) - mal schauen :)


    Viele Grüße


    -Klaus Keppler

    Danke für den Hinweis!
    Bei meinen Untersuchen eben hat sich gezeigt, dass in manchen Fällen das Verzeichnis /var/www/webxxx/conf/sockets/ nicht existiert, und somit kein FastCGI-Prozess gestartet werden kann. Das passiert vermutlich dann, wenn erst ein Webspace eingerichtet und danach das Paket "php-cgi" installiert wurde.
    Ich werde das Init-Script (nginx-php-fcgi) gleich mal entsprechend anpassen.


    Viele Grüße


    -Klaus Keppler

    Soeben wurde LiveConfig v1.6.1-r2125 als Preview freigegeben. In erster Linie enthält diese nur noch Bugfixes und Verbesserungen (siehe Changelog).
    Wir testen diese Version nun noch in einem größeren Umfeld durch; voraussichtlich wird diese dann am Donnerstag Abend (14.02.) produktiv freigegeben.


    Viele Grüße


    -Klaus Keppler

    Die Berechtigungen schauen soweit richtig aus. Wurde eine Datei namens /etc/vsftpd/users/web18 (oder so ähnlich) erzeugt?Welche Fehlermeldungen gibt es in /var/log/vsftpd/vsftpd.log, wenn Sie sich als "web18" per FTP anmelden und z.B. Ein neues Verzeichnis anlegen möchten?
    Mir sind aktuell keine Probleme mit dieser Konstellation bekannt, ich werde das morgen früh mal in einer unserer Test-VMs versuchen zu reproduzieren.

    Hallo,


    heute Mittag wurde das Lizenzportal aktualisiert (https://www.liveconfig.com/license).
    Damit können die direkt über die LiveConfig-Website bezogene Lizenzen verwaltet werden. Neben der Beseitigung einiger Fehler (z.B. Kündigung einzelner Lizenzen) können nun auch Rechnungen als PDF heruntergeladen und Zahlungsvorgänge nachverfolgt werden.
    Sollten noch Probleme auftreten oder weitere Funktionen gewünscht werden, geben Sie uns einfach Bescheid.


    Viele Grüße


    -Klaus Keppler

    Welche Distribution, welchen FTP-Server (vsftpd/ProFTPd) und welche LiveConfig-Version setzen Sie ein?
    Handelt es sich bei den importierten FTP-Accounts um normale Systembenutzer, oder um "zusätzliche" FTP-Accounts?


    Bitte suchen Sie mal irgend einen betroffenen FTP-Account heraus
    Welches Home-Verzeichnis hat der Account? (z.B. "grep web123 /etc/passwd")
    Welche Berechtigungen hat das übergeordnete Verzeichnis? (ls -l /var/www/web123)

    Das zeigt doch, dass SQLite als Datenbank konfiguriert ist...
    Stellen Sie bitte die Konfiguration auf MySQL um, und rufen Sie dann noch mal "liveconfig -f" auf. Dann müssten Sie den Konfigurationsfehler sehen (also warum LiveConfig bei Ihnen nicht startet).

    Hallo Herr Strausmann,


    ich habe den Fehler bereits gefunden: ein regulärer Ausdruck beim Auslesen der Modul-Liste berücksichtigt keine Treffer, die einen Unterstrich enthalten (wie proxy_http). Ist mit dem nächsten Update (ab 1.6.1-r2116) beseitigt.
    Workaround: bearbeiten Sie in /usr/lib/liveconfig/lua/apache.lua in Zeile 114 den regulären Ausdruck, so dass statt "%w" auf "[%w_]" geprüft wird:

    Code
    local m = string.match(line, "([%w_]+)_module")


    Viele Grüße


    -Klaus Keppler

    "Nix" gibt's nicht. :)
    Warum können Sie nicht einfach mal mit copy&paste alle Ausgaben aus /var/log/liveconfig/liveconfig.log übermitteln?
    (es reichen ja die letzten ~30 Zeilen - halt alles mit Datum/Uhrzeit vom letzten Startversuch)


    Ohne Log keine Hilfe.

    Ohne die Info, was genau nicht geht, wird es leider sehr schwer irgendwie zu helfen.
    Wenn Sie den SQLite-Dump erzeugt und gemäß der Anleitung in MySQL eingespielt haben, tragen Sie einfach in liveconfig.conf die Zugangsdaten zur MySQL-Datenbank ein und starten LiveConfig anschließend neu.
    Wenn irgendwas nicht klappen sollte (z.B. falsche Zugangsdaten o.ä.), dann gibt es eine Fehlermeldung in /var/log/liveconfig/liveconfig.log.


    Viele Grüße


    -Klaus Keppler

    Sofern die Domains "ohne" SSL auf der selben IP-Adresse laufen, auf der auch (mindestens) ein SSL-Zertifikat aktiviert ist, lässt sich das rein technisch gar nicht vermeiden, dass man dieses Domains auch mit https:// aufruft. Das kann auch kein Confixx umgehen ;). Die Warnmeldung wird durch den Browser erzeugt (da er kein passendes SSL-Zertifikat präsentiert bekommt); letztendlich wird aber die Seite "Diese Domain ist nicht verfügbar" (oder so ähnlich) angezeigt, weil kein entsprechender VirtualHost konfiguriert ist.


    Viele Grüße


    -Klaus Keppler

    Das hatte mit der neuen Version übrigens nichts zu tun, sondern nur mit dem (durch das Update ausgelöste) LiveConfig-Neustart. Die Liste der Apache-Module wird nämlich nur beim Start von LiveConfig (bzw. vom jeweiligen LiveConfig-Client) aktualisiert.


    Viele Grüße


    -Klaus Keppler