Beiträge von kk

Das Login lautet "admin". :p

Ansonsten werfen Sie bitte mit SQLite einen Blick in die Datenbank /var/lib/liveconfig/liveconfig.db:

SELECT U_PASSWORD FROM USERS WHERE U_LOGIN="admin"

Dort sehen Sie den (gesalzenen) MD5-Hash des Passworts; nach einer Änderung via --init sollte sich dieser auch ändern.

Ich habe eben mal im Code nachgesehen - beim Aufruf über "--init" sollten beliebig lange Passwörter möglich sein, beim Aufruf über die Weboberfläche (Einstellungen -> Passwort ändern) sind maximal 30 Byte erlaubt (bei UTF8-codierten Sonderzeichen wie z.B. Umlauten kann das effektiv also kürzer sein).
Was meinen Sie mit "es gehen keine Kennwörter mit 20 Zeichen" - bekommen Sie eine Fehlermeldung?

Viele Grüße

-Klaus Keppler

Ich habe diese Diskussion eben mal in einen eigenen Thread verschoben, das das mit dem anderen Thema nichts zu tun hat.

Zitat

Wann ist mit der Implementierung im AppInstaller zu rechnen

An beiden Installern (phpMyAdmin/RoundCube) wird derzeit gearbeitet, beide dürften in den nächsten 1-2 Tagen fertig sein. Allerdings braucht der AppInstaller dazu noch eine Erweiterung (um praktisch "Rückfragen" während der Installation noch durchführen zu können); diese Erweiterung dürfte mit etwas Glück auch noch vor dem Wochenende fertig sein (ist für Donnerstag/Freitag eingeplant).

In v1.5.2 ist das also jedenfalls enthalten.

Viele Grüße

-Klaus Keppler

Zitat von kiwee

Ich meinte damit, dass phpmyadmin vorkonfiguriert mitinstalliert wird - ist wohl für 1.5.2 angekündigt.

Um Mißverständnissen vorzubeugen: das wird LiveConfig nicht machen (phpMyAdmin ist ein völlig eigenständiges Produkt). Wir nehmen phpMyAdmin, RoundCube und einige weitere Anwendungen jedoch aktuell mit in den AppInstaller auf. So kann ein Admin während der Einrichtung eines Servers einen "eigenen" Webspace (z.B. unter "Mein Hosting") anlegen und dort diese Anwendungen per AppInstaller hinzufügen.
Eine Alternative wäre, dass man über die jeweilige Distribution z.B. phpMyAdmin oder Roundcube installiert und LiveConfig diese dann in irgendeiner Form erkennt/verlinkt. Beide Varianten haben ihre Vor- und Nachteile; wir starten aber einfach mal mit der AppInstaller-Lösung.

Danke für den Hinweis - wurde in r1784 beseitigt (in einigen Tagen als Preview erhältlich).

Viele Grüße

-Klaus Keppler

Argh... ja, das wird wohl ein Fehler in der Übersetzungsdatenbank sein. Im Source ist nämlich von "locked" und "suspended" die Rede... Ich schau' mir das gleich mal an - danke für den Hinweis!

[Nachtrag] Ist ab r1785 beseitigt.

Das Problem ist ab r1781 beseitigt (aktuell als Preview verfügbar).

Vielen Dank für die Hinweise!

-Klaus Keppler

Hallo,

eben wurde eine neue Preview-Version bereitgestellt (1.5.1-r1781).

Neben einigen Bugfixes und Detailverbesserungen ist die wichtigste Änderung in Bugfix in den internen RRD-Tabellen. Ein Kunde mit dem offenbar am längsten laufenden LiveConfig-System machte uns auf das Problem aufmerksam - kurz gesagt wurden viele RRD-Archive nicht als "Ringpuffer" gefüllt, sondern sind stetig angewachsen.
Mit dem Update wird dieser Fehler beseitigt und alle überflüssigen Daten entfernt. Daher kann der Update-Vorgang bei länger laufenden System ein paar Minuten dauern. Eine Fortschrittsanzeige informiert aber über den Status.

Außerdem wurde das Sperren von Kunden vorbereitet; derzeit wird aber lediglich der Zugang zu LiveConfig gesperrt bzw. deaktiviert, in Kürze werden auch die FTP- und E-Mail-Accounts berücksichtigt.

Viele Grüße

-Klaus Keppler

Postfix unterstützt ja leider keine modulare Konfiguration, daher ist LiveConfig leider gezwungen, die entsprechende Datei jeweils neu zu erzeugen (die Konfigurationsanweisungen und Zusammenhänge sind zu komplex, um nur zeilenweise Ersetzungen vorzunehmen, wie wir das bei manchen anderen Konfigurationen machen)

Kurz gesagt: RBLs können in nächsten Update (wohl noch diese Woche) direkt über die Oberfläche verwaltet werden (Auswahl der Listen und/oder Deaktivierung). Greylisting kommt dann eine Version später - hier brauchen wir noch Änderungen an den Eingabemasken um das pro Postfach konfigurierbar zu machen (ein "globales" Greylisting ist i.d.R. nicht praxistauglich). Das selbe gilt für SpamAssassin (da fehlen auch nur noch GUI-Anpassungen).

Leider überschreibt LC also bei Änderungen die Postfix-Konfigurationen - das ist aber nur dann der Fall, wenn man irgendwas an der Konfiguration ändert (konkret kann man da aktuell ja nur den Virenscanner ein-/ausschalten). Im normalen Betrieb wird da nichts geändert, selbst nach LC-Updates normalerweise nicht.

Wer sicher gehen möchte, sollte von einer modifizierten Konfiguration ein Backup anlegen und nach Konfigurationsänderungen in LC sowie nach LC-Updates prüfen, ob die Konfiguration neu erzeugt wurde.

Last but not least: sollte LC während eines Updates zwangsweise irgendwelche Dateien neu schreiben müssen, weisen wir immer in den Release-Notes (Changelog) darauf hin.

Viele Grüße

-Klaus Keppler

Ich habe das oben beschriebene Problem auf einer Test-VM eben exakt reproduzieren können (trat eben dann auf, wenn ClamAV-Milter aktiviert war und man eine E-Mail über den Submission-Port 587 eingeliefert hat).
Bitte prüfen Sie, ob das "n" wirklich in der fünften Spalte in master.cf eingetragen ist, und ob Postfix tatsächlich neu gestartet wurde.

Hmm... ich habe eine Vermutung...
Bitte bearbeiten Sie die Datei /etc/postfix/master.cf und ändern Sie folgende Zeile ab:

submission inet n       -       [B]n[/B]       -       -       smtpd

(also in der fünften Spalte das "-" in ein "n" ändern)

Dann Postfix neu starten (/etc/init.d/postfix restart).
Auf den ersten Blick sieht das nach einem Konfigurationsfehler aus, da per SMTP-Submission (Port 587) eingelieferte Mails in einer chroot-Umgebung verarbeitet werden. Macht auch irgendwie keinen Sinn in diesem Zusammenhang...

Was gibt denn der Befehl "ps aux | grep clamav" aus?
Dort sollten mindestens zwei Dienste erscheinen (clamd und clamav-milter, optimalerweise auch noch freshclam)

Ein Berechtigungsproblem sollte es bei einer normalen Repository-Installation nicht geben, das haben wir hier recht ausführlich getestet (ich habe in diesen Minuten auch auf einer frischen Test-VM ClamAV-Milter problemlos mit LiveConfig aktivieren können, ebenfalls Debian 6 mit LC 1.5.1).
Bitte werfen Sie auch einen Blick in /var/log/clamav/clamav-milter.log (nicht nur in clamav.log)

Unter Debian haben wir erlebt, dass manchmal direkt nach der Installation der clamav-daemon nicht automatisch gestartet wird (/etc/init.d/clamav-daemon start)
Stehen weitere Hinweise in /var/log/clamav/clamav-milter.log ?

Viele Grüße

-Klaus Keppler

Hallo Herr Groh,

zum Abbruch fehlerhafter/hängender App-Installationen gibt es in Kürze ein Update.
Außerdem werden wir eine Prüfung einbauen, mit der LiveConfig sicherstellt dass es überhaupt eine Verbindung zum MySQL-Server aufbauen kann bevor versucht wird, dort eine neue Datenbank anzulegen.

Das Update ist voraussichtlich ab Montag Nachmittag als Preview erhältlich.
In manchen Fällen hilft ein Neustart von LiveConfig, da dort noch mal explizit viele "hängende" (nicht abgeschlossene) Aufgaben abgearbeitet werden.

Viele Grüße

-Klaus Keppler

stoepsel2k: welche Distribution+Version nutzen Sie?

Hallo,

nur kurz zur Info: ab kommender Woche stellen wir einen öffentlich zugänglichen Bugtracker bereit, in dem wir alle Bugs und Feature-Requests übersichtlich sammeln werden.
Bislang setzen wir intern JIRA ein, werden dies nun aber schrittweise auf Redmine umstellen. Das heißt auch, dass wir alle Feature-Requests der letzten Wochen dort noch eintragen werden (ich bitte also um Entschuldigung wenn wir noch nicht zu allen Forenbeiträgen direkt eine Rückmeldung abgeben konnten, das wird schnellstmöglich nachgeholt).

Vorab schon mal: vielen Dank für die vielen tollen Ideen - sehr viel davon befindet sich bereits in Umsetzung oder ist für die nächsten Wochen schon vorgemerkt.

In unserem Team sind nun auch alle wieder aus dem Urlaub zurück, so dass es mit Volldampf weiter geht!

Viele Grüße

-Klaus Keppler

Zitat

da ich Jahrelang mit Plesk gearbeitet habe würde ich es begrüßen wenn man bei den
Verträgen die ID auch den kompletten Domainnamen verwenden kann

Sie können einen fast beliebigen Vertragsnamen wählen, aber einen Domainnamen kann LiveConfig dort nicht automatisch verwenden (schließlich muss erst ein Vertrag angelegt werden, dann können diesem Domains hinzugefügt werden).
Und ob das nun übersichtlicher ist - darüber kann man sich schnell streiten. Sobald Sie nämlich eine zweite Domain in diesem Vertrag verwalten, ist es mit der Übersicht dahin.
Und nicht zuletzt bestünde so ein grundsätzliches Sicherheitsproblem: andere Benutzer würden durch ein "ls -l /var/www/" erkennen, was sonst noch so für Domainnamen auf dem Server eingerichtet sind (da die Verzeichnisnamen ja den Domainnamen entsprechen).

Zitat

Wäre klasse wenn man unter Einstellungen auch das Dokumenten-Verzeichnis Namen vorgeben könnte:
- ob htdocs, httpdocs oder web

Das wäre durch Anpassung der Lua-Scripte (insbes. web.lua und apache.lua) möglich; dies müsste aber auf dem kompletten System einheitlich sein.

Viele Grüße

-Klaus Keppler

Das Verzeichnis hierfür muss nur ~/.php5/ lauten, nicht ~/conf/php5
Anschließend müssten Sie noch mal eine beliebige Subdomain des Webspaces öffnen/speichern, so dass die vHost-Konfiguration aktualisiert wird - nach ca. 10 Sekunden sollte dann die neue php.ini berücksichtigt werden.
Die Verwaltung "eigener" php.ini-Einstellungen direkt durch LiveConfig kommt aber gut voran, so dass solche Workarounds hoffentlich nicht mehr lange notwendig sein sollten.

Viele Grüße

-Klaus Keppler

CentOS 5 oder 6?
Könnten Sie in diesem Fall mit "httpd -S -t" eine Liste der konfigurierten IPs/vHosts erstellen? So müsste zu sehen sein, welche Konfigurationsdatei noch die fehlerhafte "Listen"-Anweisung enthält.
Ich versuche das gleich mal auf einer CentOS-VM zu rekonstruieren. Ich nehme an, Sie haben nur mit der default-IP-Gruppe gearbeitet, oder hatten Sie noch eine weitere IP hinzugefügt und dem Kunden exklusiv zugewiesen?

Viele Grüße

-Klaus Keppler

Hallo,

ich schätze da haben Sie einen Bug entdeckt. Ich habe das eben geprüft; nach dem Deaktivieren von SSL für einen Kunden wird dessen vHost-Konfiguration (Apache) nicht aktualisiert, es bleibt dort also noch das alte "Listen"-Statement drin stehen.
Auf die Schnelle können Sie einfach mal eine Session mit diesem Kunden starten, dann unter "Hosting" -> "Domains" eine beliebige (Sub-)Domain öffnen und dort auf "speichern" klicken (ohne was zu ändern).
Damit wird dessen Konfiguration aktualisiert - vielleicht hilft das schon weiter.
Ansonsten schicken Sie uns bitte mal die Ausgabe von "apache2ctl -S -t" (ggf per PN oder an info@liveconfig.com)

Der o.g. Fehler wird umgehend beseitigt.

Viele Grüße

-Klaus Keppler