Beiträge von kk

    Danke für den Hinweis - Update wird am Montag freigegeben.
    Bis dahin deaktivieren Sie einfach die (neue) Checkbox, dass nur verschlüsselte Anmeldungen erlaubt sind (dort steckt der Fehler offenbar drin)

    Es war nie beabsichtigt, dass Kunden selbst ihre php.ini-Dateien bearbeiten können - seit v1.6.3 können die globalen php.ini-Einstellungen vom Admin zentral über LiveConfig verwaltet werden, mit einem der nächsten Updates können Kunden dann ausgewählte Einstellungen ebenfalls über LC verwalten.


    Wenn Kunden selbst ihre php.ini-Datei verwalten könnten, dann müssen ganz spezielle, zusätzliche Schutzmechanismen zum Einsatz kommen, damit Kunden nicht Ihren Server "abschießen" oder lokale Exploits ausnutzen können. Mit FastCGI sollte man das dann ohnehin nicht laufen lassen, bestenfalls noch via CGI (suPHP).


    Viele Grüße


    -Klaus Keppler

    Die Repositories werden immer gleichzeitig mit der Veröffentlichung auf der Website aktualisiert.
    Führen Sie bitte ggf. "aptitude update" und anschließend "aptitude upgrade" aus - damit sollten Sie das Update automatisch erhalten.

    Ist derzeit in Arbeit (man sieht in der aktuellen Preview schon, dass sich an einigen Masken schon was geändert hat) - zur Version 1.7.0 ist das dann fertig.


    Viele Grüße


    -Klaus Keppler

    Hallo,


    zwischendurch erreicht uns immer wieder mal die Frage nach der Konfigurierbarkeit von Logrotate (wer das nicht kennt: dieses Tool sorgt dafür, dass die access.log-Dateien der Kunden regelmäßig archiviert werden).


    LiveConfig pflegt die Einstellungen in /etc/logrotate.d/liveconfig jeweils individuell pro Vertrag. Damit wäre es uns rein technisch also auch möglich, die Einstellungen pro Vertrag modifizierbar zu machen.
    Aktuell ist die Log-Rotation so konfiguriert, dass Logs monatlich rotiert und die alten Logs nach 100 Tagen gelöscht werden.


    Mit einem der nächsten Updates wollen wir die Logrotate-Einstellungen konfigurierbar machen. Hierfür sehen wir im Moment zwei Ansätze:

    1. Verwaltung der Einstellungen unter Serververwaltung -> Web (also quasi pro Server)
    2. Verwaltung in den Hosting-Angeboten (die wird demnächst mit Tab-Reitern mehrseitig gemacht, da könnten wir dann auch die Logrotate-Einstellungen unterbringen)


    Variante 1 wäre die vielleicht "intuitive" Lösung, hat aber unserer Meinung nach den Nachteil, dass in Multi-Server-Setups die Log-Einstellungen dann nicht zentral/einheitlich gepflegt werden könnten.
    Variante 2 ist derzeit unsere bevorzugte Lösung - so kann man beispielsweise auch bei "kleinen" Hosting-Paketen andere Schwellwerte oder Archivierungsdauern definieren als für "Power-Pakete".


    So oder so ist geplant, dass Logrotate-Einstellungen auch individuell pro Vertrag angepasst werden können.


    Gibt es noch weitere Vorschläge oder Anforderungen an die Log-Rotation?


    Wichtig ist uns, dass auch unerfahrene Benutzer sinnvolle Voreinstellungen bekommen. Wer sich mit Logrotate auskennt, für den ist es eine Kleinigkeit das zu "tunen". Aus Erfahrung sind unbedarfte Benutzer mit zu vielen Einstellungsmöglichkeiten aber schnell überfordert oder stellen unsinnige Werte ein.


    Ich freue mich auf Rückmeldungen :)


    Viele Grüße


    -Klaus Keppler

    Ab sofort steht die Preview-Version 1.6.4-r2445 zum Download bereit.


    Die meisten Änderungen betreffen die Stabilität und Sicherheit von LiveConfig, außerdem wurde ein ganzer Schwung an Konfigurationseinstellungen verbessert. Alle Details sind im Changelog auf der Preview-Seite zu finden. Einige Highlights sind:

    • LiveConfig speichert die eigenen Passwort-Hashes nun mit dem PBKDF2-Verfahren (lässt sich derzeit mit Brute-Force-Verfahren praktisch nicht knacken)
    • optionale Unterstützung von HTTP Strict Transport Security (HSTS, siehe RFC6797)
    • verbesserte SSL-Konfiguration (wichtig für PCI-Konformität)


    WICHTIG: es gibt mit diesem Update auch eine Änderung in der LiveConfig-Konfigurationsdatei (liveconfig.conf): wurden Sockets für "alle" Netzwerkadressen bislang mit "[::]" spezifiziert, muss das künftig mit "*" erfolgen (z.B. "http_ssl_socket = *:8443"). Somit können IPv4- und IPv6-Wildcard-Adressen getrennt konfiguriert werden. Außerdem war das für die künftige FreeBSD-Unterstützung dringend notwendig. :)
    Beim Upgrade nimmt das Installationsscript des jeweiligen Paketmanagers diese Änderung in der Regel automatisch vor ("[::]:" wird pauschal durch "*:" ersetzt).

    Bitte starten Sie LiveConfig neu - dabei sollten auch "hängende" Jobs (DB löschen etc.) wieder abgearbeitet werden.
    Wir arbeiten bereits an der Behebung des Fehlers, ein Update sollte dann kurzfristig verfügbar sein (in dem o.g. Fall hat der Client-Prozess die Verbindung zum Server-Prozess verloren - in der nächsten Version ist ein Watchdog enthalten, der solche Situationen automatisch erkennt und versucht zu lösen, unabhängig von der Fehlerursache)


    Viele Grüße


    -Klaus Keppler

    Was für ein Update haben Sie denn durchgeführt (welche Distribution / welche Versionen?)
    Wenn Sie beispielsweise ein Debian-Upgrade durchführen und bei Apache Änderungen in der Konfigurationsdateien vorgeschlagen werden, dann haben Sie immer die Möglichkeit, diese Änderungen (durch Debian) nicht durchführen zu lassen.


    Zum Apache: gehen Sie im LiveConfig auf Serververwaltung -> Web, öffnen eine IP-Gruppe (z.B. "default") und klicken in diesem Popup einfach gleich auf den "Speichern"-Button. Damit wird die default.conf neu geschrieben.


    Die mit LiveConfig eingerichteten Websites (web1, ...) sollten eigentlich normal funktionieren - LC erstellt schließlich "nur" eine vHost-Konfiguration in z.B. /etc/apache2/sites-available/web1.conf - ein Apache-Upgrade dürfte da nichts zerschießen können (Ausnahme: Sie haben Apache mit der "purge"-Option komplett entfernt und anschließend neu installiert?)
    In diesem Fall öffnen Sie einfach in jedem Hosting-Vertrag jeweils *einmal* irgendeine Domain-Einstellung (Hosting -> Domains) und klicken in diesem Popup auf "speichern" - dann wird auch diese vHost-Konfiguration neu geschrieben.


    Zitat

    Und auch, dass man Dienste wieder nicht mit LC verwalten kann.


    Ist bereits beides in Planung (ein "Panic-Button" zur Neuerzeugung aller Konfigurationen sowie die Deaktivierung der Verwaltung einzelner Dienste).


    Viele Grüße


    -Klaus Keppler

    Nein, die Daten werden leider nirgendwo zwischengespeichert - erst wenn man auf "speichern" klickt.
    (Zwischenspeichern ist auch nicht ganz trivial: wer am Ende auf "abbrechen" klickt will natürlich nicht, dass die vorherigen Daten bis dahin überschrieben wurden)


    Die meisten CAs bieten die Möglichkeit, ein Zertifikat kostenlos neu ausstellen zu lassen ("re-issue"). Sollte das bei Ihnen nicht möglich sein, dann empfehlen wir einen anderen Anbieter. ;) (z.B. http://www.psw.net)


    Mit freundlichen Grüßen


    -Klaus Keppler



    PS: wir werden beim Popup noch eine Sicherheitsabfrage einbauen, die vor dem Schließen des Fensters nachfragt, ob man seine Änderungen wirklich nicht speichern möchte (#93)

    Ein interessanter Vorschlag...
    Grundsätzlich schließt man dabei aber auch den Versand in den Fällen aus, in denen ein Kunde z.B. seine GMX-Adresse als Absenderadresse verwendet (außer man ließe in LiveConfig auch noch "sonstige erlaubte Absenderadressen" mit pflegen).


    In der Implementierung ist das aber mit ein bisserl Arbeit verbunden, weil LiveConfig ja erst noch die Map-Datei erzeugen müsste (Absenderadresse <-> SASL-Benutzer).


    Ich denke, wir können das durchaus als Option mit aufnehmen (kann man dann bei der Postfix-Konfiguration wahlweise aktivieren); ein entsprechendes Feature-Ticket mache ich gleich auf. Bis wann das umgesetzt sein wird, kann ich aber noch nicht abschätzen.

    Jein; das Verzeichnis "conf" sollte dabei nicht mit verschoben/kopiert werden.


    Am besten wäre also:
    1. mv .../web1/htdocs .../web1bck
    2. mv .../web100/htdocs .../web1/
    3. chown -R ...


    Prüfen Sie danach noch, ob der alte Verzeichnisname (web100) noch irgendwo in den Dateien enthalten ist (z.B. in Konfigurationdateien usw) - am besten mit find & grep

    Hallo,


    welche LiveConfig-Version genau setzen Sie ein?
    Im Nachhinein kann man leider nicht mehr herausfinden was genau da passiert ist. Wir werden sicherheitshalber mal eine Anleitung zusammenstellen, wie man einen Core-Dump erzeugen kann, mit dem wir dann noch mal nachträglich solche Probleme analysieren können.


    Mit v1.6.3 (r2383) gab es einige Verbesserungen - u.a. auch in der Event-Schleife, welche eventuell zu dem oben beschriebenen Problem geführt hat.


    Viele Grüße


    -Klaus Keppler