Beiträge von kk

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

Der zweite Screenshot (sslwarning.png) enthält doch bereits eine eindeutige Fehlermeldung:

Zitat

Das Sicherheitszertifikat dieser Website wurde für eine andere Adresse der Website ausgestellt.

In dem zweiten Screenshot (ssl.png) haben Sie den Domainnamen "ausradiert" (das was bei "Allgemeiner Name (CN)" steht). Ich gehe davon aus, dass Sie nicht (oder nicht exakt) die Adresse im Browser eingegeben haben, auf die das Zertifikat ausgestellt ist.

Ansonsten schicken Sie uns gerne per PN oder an info@liveconfig.com Ihre LiveConfig-URL, dann testen wir das mal direkt durch.

Viele Grüße

-Klaus Keppler

Derzeit gibt es noch keine speziellen Abhängigkeiten die eine Reihenfolge vorschreiben. Unser Protokoll wäre aber in diesem Fall "fehlertolerant" - sollten also mal ein Client und ein Server zueinander inkompatibel sein, dann würde die Verbindung automatisch abgebrochen und regelmäßig neu aufgebaut (und erneut überprüft) werden.

Viele Grüße

-Klaus Keppler

Eben wurde ein kleines Bugfix-Release in die Repositories aufgenommen. Folgende Fehler werden damit beseitigt:

• Einträge gelöschter Verträge werden aus Logrotate-Konfiguration entfernt
• Fehler bei Sprachauswahl in der Einstellungs-Seite beseitigt (NL konnte nicht ausgewählt werden)
• Seiten-Reload nach dem Schließen eines Popup-Fensters funktioniert nun auch wieder mit Webkit-Browsern (Chrome/Safari)

Das Update ist also nicht kritisch, sollte aus Gründen der Usability aber bei Gelegenheit eingespielt werden.

Viele Grüße

Klaus Keppler

LiveConfig verrechnet sich nicht. Das Gesamtquota umfasst die maximal allen Postfächern insgesamt zuweisbare Speicherplatzgröße - egal wie groß die Postfächer aktuell tatsächlich sind.
Wenn Sie z.B. 2 GB Gesamtquota einrichten, können Sie 10 Postfächer á 200 MB anlegen, oder 20 á 100 MB etc.
Die Mailbox-Quota wird in LiveConfig mittels "Maildirquota" realisiert; moderne IMAP-Clients (und z.B. auch Roundcube) können somit auch direkt anzeigen, wie viel Platz noch im Postfach verfügbar ist.
Es gibt derzeit keine technisch sinnvolle Möglichkeit, das Gesamtquota "dynamisch" auf alle Postfächer aufzuteilen.

Wir werden das in der Doku bei Gelegenheit mal deutlicher beschreiben, um Mißverständnissen vorzubeugen.

Viele Grüße

-Klaus Keppler

Noch ein Nachtrag: als Workaround kann man auch jetzt schon einem Vertrag eine Domain wie z.B. "web1.example.org" zuweisen (und natürlich im Hintergrund eine "*.example.org" einrichten, die auf den Webserver zeigt); diese taucht beim Kunden dann eben als "ganz normale" Domain auf.

Schöner und ordentlicher ist es natürlich, wenn solche Subdomains direkt durch LiveConfig verwaltet werden - daran wird ja gleich gearbeitet.

Die Domain-Variante macht eigentlich am meisten Sinn, da man so auch verschiedene Domainkonfigurationen (z.B. Unterverzeichnisse) innerhalb eines Vertrags dann testen kann.
Wird gleich in den nächsten Tage umgesetzt und dann als Preview bereitgestellt.

Viele Grüße

-Klaus Keppler

Daran arbeiten wir bereits; für PHP-FPM müssen wir im init-Script noch prüfen ob eine entsprechend passende PHP-Version installiert ist, das Integrieren "eigener" Anweisungen in die NGINX-Konfiguration ist noch eine größere Herausforderung (erste Ergebnisse sollten in 2-3 Wochen verfügbar sein). Kurz gesagt soll es in der Oberfläche eine Möglichkeit geben, eine definierte Menge an Befehlen zu erfassen; LC prüft dann jeweils deren Syntax und ob diese in der installierten NGINX-Version auch verfügbar sind.

Viele Grüße

-Klaus Keppler

War "nur" eine Notice von PHP, aber trotzdem unschön. Wurde eben beseitigt (das Formular wurde kürzlich um die Bestellmöglichkeit für den Newsletter erweitert).
Die Testlizenz sollte trotzdem unterwegs sein - wenn dieser Hinweis angezeigt wurde, dann ist der Rest bereits "erledigt" worden.

Viele Grüße

-Klaus Keppler

Ja, ich schätze wir werden clamav-milter wieder aus dem Meta-Paket entfernen und dafür Hinweise zur Installation via RPMForge mit aufnehmen (damit das wieder alles konsistent ist).
Auf unseren Testsystemen ist wg. suPHP das RPMForge-Repo jeweils aktiviert, daher ist es noch nicht früher aufgefallen.

Viele Grüße

-Klaus Keppler