Ist mit v1.6.4-r2453 beseitigt.
Viele Grüße
-Klaus Keppler
Ist mit v1.6.4-r2453 beseitigt.
Viele Grüße
-Klaus Keppler
Welche Distribution genau nutzen Sie, und mit welchem Befehl (und welchen Parametern) haben Sie das Update ausgeführt?
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.
Bitte aktualisieren Sie auf die neueste Version (1.6.3-r2383) und prüfen, ob der Fehler dort auch noch vorhanden ist.
(siehe Changelog - "Fehler beim Löschen eines Benutzeraccounts beseitigt")
Viele Grüße
-Klaus Keppler
Ist mit der nächsten Version (1.6.4) behoben - in der aktuellen Preview kann man das bereits testen. FcgidMaxRequestLen wird automatisch an den max_post_size-Wert aus der php.ini angepasst.
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:
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:
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).
Der Fehler tritt immer dann auf, wenn die Quota-Daten im LiveConfig aktualisiert werden (das passiert alle 15 Minuten). Ich melde mich in Kürze bei Ihnen mit einem Bugfix.
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.
ZitatUnd 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
siehe http://www.liveconfig.com/de/forum/threads/864-Apache-läuft-auf-100-CPU-mit-xcache-Konfiguration - inklusive möglicher Lösung in Posting #10.
Vielen Dank aber für die mögliche Lösung - ich denke, WebOscar wird sich auch freuen ![]()
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
Naja, ich vermute mal, dass Sie noch nicht die Version 1.6.4-r2416 (oder später) am Laufen haben... ![]()
Wird voraussichtlich übermorgen (Donnerstag) als Preview bereitgestellt.
Viele Grüße
-Klaus Keppler