Beiträge von kk

Hallo Herr Banse,

es freut mich, wenn wir auch vorsichtige Interessenten nun langsam aber sicher überzeugen können

Zitat

Beim anlegen eines Kunden wird ein FTP Account eingerichtet. Dieser jedoch wird als Systembenutzer in der /etc/passwd abgelegt. Wird (wie in unserem Falle nun) Proftpd verwendet und von LiveConfig verwaltet, werden die Benutzer aus der /etc/proftpd/passwd ausgelesen. Folglich ist ein Login nicht möglich.

Dass der "Hauptbenutzer" in /etc/passwd angelegt wird, ist so beabsichtigt (schließlich braucht es ja einen "echten" Systembenutzer pro Hostingvertrag). Allerdings sollte normalerweise auch ein FTP-Login mit diesem Benutzer möglich sein - in /etc/proftpd/passwd stehen lediglich die zusätzlichen (virtuellen) FTP-Benutzer.
Welche Fehlermeldung bekommen Sie denn in /var/log/proftpd/proftpd.log, wenn Sie sich als ein "Hauptbenutzer" anmelden möchten?
Unserer Erfahrung nach ist ein häufiger Fehler, dass die Kunden noch kein Passwort für den Standard-FTP-Benutzer im LiveConfig angelegt haben ("Hosting" -> "Webspace" -> "FTP-Accounts", dort dann auf "Passwort ändern..."). Eine Vereinfachung dieses Vorgangs ist bereits geplant (durch ein zufälliges Standard-Passwort, das dem Kunden direkt nach Anlegen des Vertrags auch automatisch per E-Mail zugesendet werden kann).

Viele Grüße

-Klaus Keppler

Wir testen die 1.6.4 derzeit sehr intensiv durch (konkret wurde in den letzten Tagen mehr Code für Tests als für LiveConfig geschrieben); die produktive Freigabe ist für Ende dieser Woche geplant. Da es einige wichtige Änderungen und Bugfixes gab, empfehlen wir, das Update dann auch zeitnah durchzuführen.
Für MI/DO ist eingeplant, dass wir uns dort noch um das Abarbeiten nicht erfolgreich abgeschlossener Transaktionen kümmern (Datenbanken löschen, Verträge löschen usw.).

Viele Grüße

-Klaus Keppler

Was steht in /var/log/liveconfig/liveconfig.log rund um den Löschzeitpunkt?
Bei einem Multi-Server-Setup: was steht zusätzlich in /var/log/liveconfig/lcclient.log auf dem Slave?
Sind gar keine Dateien gelöscht, oder bleiben nur einzelne Dateien übrig?
Ist SELinux aktiviert?

UPDATE 2: der Fehler wurde nun isoliert (siehe Bug Report). Mit Version 1.6.4-r2466 wurde ein Workaround in LiveConfig aufgenommen.

Viele Grüße

-Klaus Keppler

Ab sofort steht v1.6.4-r2466 im Test-Repo bereit, welche einen Workaround für einen Bug in SQLite enthält. Dieser Fehler führt dazu, dass in ganz bestimmten (zum Glück relativ seltenen) Fällen einige SQL-Anfragen keine Ergebnisse zurück liefern, wie beispielsweise die Liste der Domains beim Erstellen/Bearbeiten einer E-Mail-Adresse.

Viele Grüße

-Klaus Keppler

UPDATE: inzwischen haben wir über die SQLite-Mailingliste einen Workaround erhalten, wie sich die (vermutlich) verantwortliche Optimierung abschalten lässt. Ein LiveConfig-Update startet soeben in die Build-Pipeline, in 2-3 Stunden stellen wir das dann online.

Viele Grüße

-Klaus Keppler

Wäre es möglich, dass Sie uns Ihre liveconfig.db mal zusenden? (support@liveconfig.com - die Daten werden unmittelbar nach der Prüfung selbstverständlich gelöscht)
Uns interessieren nur einige bestimmte Tabellen; Sie können also einfach eine Kopie der liveconfig.db anlegen, und dort mit dem SQLite3-Tool folgende Tabellen vorab löschen:

drop table ACCOUNTBLACKLIST;
drop table ACCOUNTS;
drop table APPREPO;
drop table APPS;
drop table APPTEXTS;
drop table APPVARS;
drop table APPVERSIONS;
drop table CAPTCHACACHE;
drop table CONTACTS;
drop table COUNTRIES;
drop table COUNTRYTRANS;
drop table CRONCONFIG;
drop table CRONJOBS;
drop table CUSTOMERS;
drop table CUSTOMLINKS;
drop table DBCONFIG;
drop table DBS;
drop table DBSERVERACCESS;
drop table DBSERVERS;
drop table DNSTEMPLATES;
drop table DOMAINDATA;
drop table EXTNAMESERVERS;
drop table FTPSERVERS;
drop table INTERFACES;
drop table IPGROUPADDRS;
drop table IPGROUPCONFIG;
drop table IPGROUPS;
drop table IPMGMT;
drop table IPS;
drop table LIVECONFIG;
drop table LOG;
drop table MAILALIASES;
drop table MAILBOXES;
drop table MAILFORWARDS;
drop table MAILTEMPLATES;
drop table MODULES;
drop table NAMESERVERIPS;
drop table NAMESERVERS;
drop table OBJECTLOG;
drop table PERMISSIONS;
drop table PHPTEMPLATES;
drop table PHPVARS;
drop table POP3IMAPSERVERS;
drop table PREFERENCES;
drop table PWPATHS;
drop table PWPATHUSERS;
drop table PWRECOVER;
drop table PWUSERS;
drop table RESELLERS;
drop table RRA_CPU;
drop table RRA_DISK;
drop table RRA_MEM;
drop table RRA_NET;
drop table RRA_TRAFFIC;
drop table RRA_WEBSPACE;
drop table RRD_CPU;
drop table RRD_DISK;
drop table RRD_MEM;
drop table RRD_NET;
drop table RRD_TRAFFIC;
drop table RRD_WEBSPACE;
drop table SERVERCONTRACTS;
drop table SERVERS;
drop table SESSIONFILES;
drop table SESSIONS;
drop table SSLCERTS;
drop table TEST1;
drop table TIMEZONES;
drop table TZ_DATA;
drop table TZ_RULENAMES;
drop table TZ_RULES;
drop table USERS;
drop table WEBANALYTICS;
drop table WEBSERVERIPS;
drop table WEBSERVERS;

Wir müssten dann nur noch wissen, bei welchem Vertrag (z.B. "web123") die Domains nicht angezeigt werden.

Besten Dank & viele Grüße

-Klaus Keppler

Hallo,

ab sofort steht v1.6.4-r2464 im Test-Repo bereit. Der Fehler war ein fehlendes "IF EXISTS" bei einem "DROP TABLE"-Befehl; in früheren Testversionen wurde die Tabelle OBJECTLOG nämlich erzeugt, je nach Upgrade-Pfad war diese aber ggf. (noch) nicht vorhanden.

Viele Grüße

-Klaus Keppler

Zitat von Maikomania

Hallo seit dem Update auf die neue Preview 1.6.4-r2462 sehe ich bei den Emails die Domains nicht sprich wen ich eine
E-mail erstellen möchte kann ich keine Domain auswählen.

Ja, die Sache hält uns hier ziemlich auf Trab - wir sind da auf einen weiteren Bug in SQLite gestoßen, der selbst in der aktuellsten "trunk"-Version noch nicht beseitigt ist.
[TECH]In SQLite wird seit v3.7.16 sehr viel an der Optimierung von SQL-Anfragen gearbeitet. Wie Knuth schon sagte: »Premature optimization is the root of all evil.« Der neue Query Optimizer sorgt nämlich dafür, dass bei einigen unserer SQLs schlicht gar keine Ergebnisse zurück geliefert werden. Lässt man dann z.B. die ORDER BY-Klausel weg, so erscheinen die Ergebnisse wieder (wenn auch unsortiert). Dass solche Fehler extrem schwer zu finden sind, dürfte klar sein. Eine ältere SQLite-Version ist in unserem Fall leider auch keine Option, da es dort noch einen anderen Fehler gab, der LiveConfig wiederum mit einem SEGFAULT beendet hatte.[/TECH]

Eigentlich sollte sich das Problem erledigen, indem man die Tabellenstatistiken in SQLite aktualisiert (Befehl ANALYZE). LiveConfig führt diesen Schritt beim Update auf r2462 automatisch durch. Bitte prüfen Sie im Log-File (/var/log/liveconfig/liveconfig.log), ob Sie dort den folgenden Eintrag (kurz nach dem letzten Update) finden:

Upgrading database schema (r2455 -> r2456)

Ansonsten teilen Sie mir bitte mit, welche Distribution Sie einsetzen, damit wir den Fehler genauer lokalisieren und dem SQLite-Team melden können.

Viele Grüße

-Klaus Keppler

NACHTRAG: Sie können auch testweise mal die LiveConfig-Datenbank /var/lib/liveconfig/liveconfig.db mit dem Programm "sqlite3" öffnen und dort den SQL-Befehl "ANALYZE" ausführen.

Danke für den Hinweis - das ist tatsächlich so nicht beabsichtigt. Auf die Schnelle kann ich noch nicht sagen was genau da schief gelaufen ist, wir werden das jedenfalls noch mal genauer prüfen.
Das Verzeichnis /conf/php5 muss dem Kunden gehören, da sonst der PHP-FastCGI-Starter nicht von suExec ausgeführt wird. Der Fehler ist an dieser Stelle, dass für die php.ini nicht auch das Immutable-Flag gesetzt wird, wie es beim php-fcgi-starter passiert. Wir werden das umgehend in die web.lua mit aufnehmen. Das Update ist spätestens am Montag verfügbar.

Mit folgendem Befehl kann man sich alle php.ini-Dateien anzeigen lassen, die nicht dem Benutzer root gehören:

ls -l /var/www/*/conf/php5/php.ini | grep -v root

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 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

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:

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).