Beiträge von kk

Eine neue Version wurde bereits compiliert, läuft eben durch die letzten Tests und geht in den nächsten Minuten online. Alle Kunden werden zudem per Rundmail informiert.

Das ist nur eine Warnmeldung und keine Fehlermeldung; die Wildcard-Subdomain müsste ja soweit funktionieren, oder?
Dann können Sie die Warnmeldung auch getrost ignorieren.

Welche Distribution genau verwenden Sie?
Was liefert der Befehl "apache2ctl -S -t" unmittelbar nach dem Neustart?

Die unter /etc/apache2/sites-available/default erzeugte Konfiguration gilt immer für den Standard-vHost (also alle Fälle, wo kein anderer Name zutrifft).

Für Ihren Fall legen Sie einfach im LiveConfig in irgendeinem Vertrag die Domain "webvation.de" an, und darunter die Subdomain "*". Dieser können Sie dann Ihr Wildcard-SSL-Zertifikat zuweisen.

Viele Grüße

-Klaus Keppler

mod_geoip kann man nicht in LiveConfig einbinden weil LiveConfig nichts mit PHP oder PHP-Modulen zu tun hat.

Installation von mod_geoip erfolgt so wie es auf der jeweiligen Distribution üblich ist (unter Debian z.B. "aptitude install php5-geoip"). Ggf. Apache danach neu starten (damit alle FastCGI-Prozesse und/oder mod_php-Instanzen das neue Modul "sehen").

Ein neue Preview-Version steht bereit (v1.7.2-r2791):

• unter Einstellungen -> E-Mail-Vorlagen können nun verschiedene E-Mail-Vorlagen bearbeitet werden. Ab sofort kann dort bereits der Text zum Zurücksetzen des LiveConfig-Passworts bearbeitet werden, weitere Texte (z.B. Versand der Zugangsdaten etc.) folgen in Kürze.

Viele Grüße

-Klaus Keppler

Geben Sie in das Feld "Absenderadresse" (bei der Box "E-Mail-Einstellungen") einfach eine gültige Mailadresse ein.
(derzeit werden alle Eingaben in diesem Formular - also sowohl das Logo als auch alle anderen Einstellungen - gleichzeitig geprüft und gespeichert)

Welche LiveConfig-Version hatten Sie denn im Einsatz, als LC beim Backup abgestützt ist?
Mit der aktuellen Version (v1.7.1-r2775 vom 10.03.2014) wurde ein Fehler in diesem Zusammenhang behoben.

LiveConfig unterstützt auch mpm_itk. Installieren Sie einfach das mpm_itk-Modul für Apache und konfigurieren die Webspaces mit mod_php.
Das Sicherheitsmodell von suPHP erlaubt definitiv keine "gemeinsamen" Verzeichnisse; mit FastCGi sollte das aber im Prinzip schon klappen. Achten Sie ggf. darauf, dass das gemeinsame Verzeichnis im open_basedir auch freigegeben ist.

Ab sofort steht die erste Preview für v1.7.2 (r2781) zum Download bereit. Die neuen Funktionen sind:

• Anzeige des Traffics der letzten 24 Stunden im "Top 10"-Bericht
• Vertrag neu zuordnen: ein Vertrag kann nun auch einem Wiederverkäufer übereignet werden (Beispiel: admin hatte den Vertrag "web1" bisher selbst einem Kunden zugeordnet. Dieser Kunde erhält nun einen Resellervertrag (res1) - dann kann ab sofort der Vertrag "web1" diesem Kunden übertragen und in dessen res1-Vertrag verschoben werden).
  Die Übersetzungen sind in r2781 noch nicht mit drin, außerdem soll es noch die Möglichkeit geben, Verträge zwischen verschiedenen Resellerverträgen verschieben zu können.
• Bugfix: Fehler in der Anzahl der IP-Adressen (bei der Serverübersicht, Business-Lizenz) beseitigt; hier wurden auch inaktive (früher mal irgendwann erkannte) IPs mitgezählt

Viele Grüße

-Klaus Keppler

Äh, stimmt... :-/ Hatte das auf die Schnelle verwechselt.
Beide Features sind aber gerade in Arbeit und voraussichtlich ab nächster Woche verfügbar.

Zitat von antondollmaier

kk: evntl. einen entsprechenden Hinweis ins Handbuch aufnehmen ... mir kam es jetzt schon öfter unter, der Server in dem Schema ("example.com" statt "server.example.com" o.ä.) benannt wurden.

http://www.liveconfig.com/de/h…/server.requirements.html => "Gültiger Hostname und Reverse DNS".
Da das trotzdem recht häufig vorkommt werden wir das wohl mal noch irgendwie hervorheben, oder evtl. im LC-GUI eine Warnung ausgeben wenn man eine Domain hinzufügen will die den selben Namen trägt wie der Hostname.

Weil sich die Antwort aus dem Changelog von selbst ergibt - notfalls aus dem Issue Tracker.

Eben wurde ein kleineres Update (v1.7.1-r2775) online gestellt. Damit werden zwei Probleme beseitigt:

• der Autodiscover-Service arbeitet nun zuverlässiger (bei Outlook 2007/2010 und evtl. 2013 gab es je nach Konfiguration Probleme, obwohl der Exchange-Connectivity-Test keine Fehler meldete)
  Grundsätzlich sollte bei Bereitstellung von Autodiscover auch SMTP+SSL (Port 465) sowie POP3S/IMAPS (Port 993/995) aktiviert werden, dann gibt's erfahrungsgemäß die wenigsten Probleme.
• in der Berechnung der SHA1-Prüfsumme für Backup-Downloads gab es unter bestimmten Umständen einen Pufferüberlauf, der zum Absturz von LiveConfig führen konnte (nicht sicherheitskritisch, da der betroffene Codeabschnitt ohnehin nur mit Benutzerrechten ausgeführt wurde - aber dennoch lästig).

Das Update ist je nach Einsatzzweck also nicht kritisch, sollte aber bei Gelegenheit durchgeführt werden.
Vielen Dank an dieser Stelle an die Techniker von iWelt, die mittels TCP-Dump bei der Lokalisierung der Autodiscover-Probleme weiterhelfen konnten.

Viele Grüße

-Klaus Keppler

Zitat von DoRob

Langsam kann man das ganze LiveConfixx nennen. Updates gibt es zwar noch, aber am Kunden vorbei

DoRob: wissen Sie was wahnsinnig viel unnötige Energie kostet? Sich mit hartnäckigen Betrugsfällen herumärgern zu müssen.
Ihr Foren-Account ist ab sofort gesperrt. Ich denke, Sie wissen warum.

Zitat von loswebos.de

Kleiner Nachtrag, wenn ich im Init Skript /etc/init.d/nginx-php-fcgi in der restart Sektion ein "sleep 1" einfüge, klappt es mit dem Restart.

Wenn Sie kurz Zeit haben könnten Sie evtl. mal dieses Start-Script ausprobieren:
http://download.liveconfig.com/tmp/nginx-php-fcgi
Das wurde so umgeschrieben, dass es beim "restart" der Reihe nach jeden PHP-FCGI-Prozess beendet und neu startet (statt alle Prozesse zu beenden und dann alle zu starten). Zudem wird der killall-Befehl mit "-w" aufgerufen, so dass er wartet bis der gewünschte Prozess tatsächlich beendet wurde.
(so ganz überzeugt bin ich von dem "-w"-Switch aber nicht wirklich; eventuell werden wir das tatsächlich durch ein "sleep 1" ersetzen)

Viele Grüße

-Klaus Keppler

Zitat von antondollmaier

Mit Anzeige, wann eine Mail warum angenommen oder abgelehnt wurde?

Nein, so etwas steht bislang selbst bei uns nur auf der Wunschliste.
Das Tool wäre prinzipiell dazu in der Lage, da es alle Mail-Sessions verfolgt. Es wären da aber noch viele Detail-Fragen offen (Information-Leakage wenn eine Mail an verschiedene Empfänger geht; Performance bei großen Mail-Mengen (Speicherung der Detailsdaten in der DB? Wenn ja, wie lange? RRD? Datenschutz? usw...).

Spontane Idee: optional könnte man auf dem Mailserver eine MySQL-DB aufsetzen, an die das Log-Tool dann alle Auswertungen meldet; via LC-GUI könnten dann Auswertungen auf diese DB gefahren werden. Hätte (meiner Meinung nach) die geringsten Auswirkungen auf die Performance und würde vielfältigste Möglichkeiten bieten.

Entschuldigt bitte die Wartezeit, dafür erkläre ich das nun auch gleich etwas ausführlicher. :cool:

Grundsätzlich kann man aktuell z.B. SpamAssassin per Milter oder über die master.cf in Postfix einbinden - Mails werden somit analysiert und bewertet; eine eventuelle Sortierung/Filterung muss dann aber im Mailprogramm (oder über ebenfalls selbst konfigurierte Sieve-Regeln) stattfinden.

Aktuell stellen wir die SpamAssassin-Integration per LiveConfig fertig. Dabei gab es eine ganze Menge Herausforderungen, die schwer unter einen Hut zu bekommen sind:

• die Spam-Filterung soll pro E-Mail-Adresse konfigurierbar sein (also die Schwellwerte zur Markierung bzw. Ablehnung einer Mail)
• die Spam-Filterung soll sowohl mit "echten" Postfächern als auch mit reinen Weiterleitungen funktionieren. Bei Weiterleitungen müssen die Einstellungen der ursprünglichen Mailadresse genutzt werden (nicht die der eventuellen Ziel-Postfächer)
• die Ablehnung einer Spam-Mail muss zum SMTP-Zeitpunkt der Einlieferung erfolgen, um keinen Backscatter zu erzeugen und die Mail-Ablehnung auch rechtssicher zu gestalten
• Blacklist/Whitelist pro E-Mail-Adresse

Das Hauptproblem besteht darin, eine Mail während der Einlieferung aufgrund einer Spam-Bewertung abzulehnen. Wird eine Mail eingeliefert, dann kann diese an mehrere Empfänger gleichzeitig gehen (z.B. kann eine Mail gleichzeitig an anton@kunde.de und berta@beispiel.de zugestellt werden). Nun kann es sein, dass Anton und Berta unterschiedliche Spam-Einstellungen haben und auch bei verschiedenen LiveConfig-Kunden eingerichtet sind - im Extremfall würde Anton vielleicht keine Spam-Filterung aktiviert haben und Berta per Blacklist fast jede Mail ablehnen lassen.
Die Analyse der Mail kann erst nach deren vollständiger Übertragung (also zum Ende des DATA-Befehls hin) erfolgen. Zu diesem Zeitpunkt kann der Mailserver aber nur die gesamte E-Mail ablehnen (einzelne Empfänger können nur zum RCPT-Zeitpunkt abgelehnt werden, da ist der Mail-Inhalt aber noch unbekannt).

Es gibt also rein technisch bedingt keine perfekte Lösung für dieses Problem, man muss sich auf einen Kompromiss einlassen:

• entweder lehnt man zum SMTP-Zeitpunkt gar keine Mails ab (damit keine Bounces erzeugt werden dürfen Spam-Mails dann auch nur stillschweigend in einen Spam-Ordner verschoben werden; klappt nicht mit reinen Mail-Weiterleitungen),
• oder man berücksichtigt bei mehreren Empfängern nur die Spam-Einstellungen des ersten Empfängers (also auch nur dessen Whitelist/Blacklist usw.)

Unserer Erfahrung nach ist die Zustellung einer Mail an mehrere Empfänger auf einem Zielserver relativ selten (Ausnahme: "lokal" gesendete Mails, z.B. Rundschreiben/CC innerhalb einer Empfängerdomain; lokal eingelieferte Mails lassen sich aber am SASL-Header erkennen und können von einer Spam-Filterung ausgenommen werden).
Gleichzeitig ist die erste Variante ("Spam-Ordner") in der Praxis etwas problematisch, da die Postfachnutzer nichts davon mitbekommen, dass eine Mail im Spam-Ordner liegt; wer Mails per POP3 abruft bekommt das überhaupt nicht mit. Man könnte dann zwar z.B. einen wöchentlichen Spam-Report verschicken, die meisten Nutzer erwarten aber dass Mails "sofort" zugestellt werden (sowohl als Absender als auch Empfänger).

Unsere Lösung besteht nun darin, dass wir einen eigenen Milter-Service implementieren (liveconfig-milter). Ein Milter-Dienst ist bei Postfix rein technisch die einzige Möglichkeit, Mails nach dem DATA-Event abzugreifen und dann ggf. noch abzulehnen. Zudem kümmert sich dieses Tool um die Weiterleitung einer Mail durch SpamAssassin (via spamd) und sendet dabei den Ort der benutzerspezifischen SpamAssassin-Konfiguration mit - das ist etwas, was kein anderer uns bekannter Milter-Dienst beherrscht.
Der Code ist (wie immer bei uns ;-)) in C geschrieben damit alles schön performant & ressourcenschonend läuft und wird nach Fertigstellung unter einer Open-Source-Lizenz freigegeben.

Ich hoffe, damit für etwas mehr Verständnis bei der Mail-Konfiguration gesorgt zu haben. Für einen zuverlässigen, stabilen und rechtssicheren Mailserverbetrieb gehört eben etwas mehr dazu als eine Quick&Dirty-Integration vom SpamAssassin.

Und weil ich gerade dabei bin: wir haben noch ein anderes Tool entwickelt, mit dem Logfiles (u.a. auch das Postfix-Log) ausgewertet werden können, um Statistiken über den Versand und Empfang von E-Mails pro E-Mail-Adresse erzeugen zu können. Dieses Tool (lclogparse) ist inzwischen fertig und läuft bei uns seit rund drei Wochen auf einem produktiven Mailserver völlig problemlos. Hier fehlt nun "nur" noch das Auslesen der aggregierten Statistikdaten und die Anzeige im LiveConfig; das alles kommt mit in die nächste Version (v1.7.2).

Viele Grüße

-Klaus Keppler

Gehen Sie einfach in LiveConfig auf "Serververwaltung" -> "Web". Ganz unten bei den IP-Gruppen wählen Sie irgendeine Gruppe aus, die mit NGINX eingerichtet ist und bearbeiten diese: irgendeine IP entfernen -> speichern -> wieder hinzufügen -> wieder speichern.
Damit wird auch die Hauptkonfiguration von NGINX neu erzeugt.

Aaargh... :eek: danke für den Hinweis!
Wir hatten in dem Script Änderungen vorgenommen, damit das auch mit Verträgen klappt die Großbuchstaben enthalten. Offenbar ist da aber ein Testfall drin hängen geblieben.

Update wird gleich bereit gestellt.