Beiträge von kk

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.

Zitat von llaehn

wenn ich die zusätzlichen PHP Version einrichte erzeugt mir der lcclient auch die php.ini in den jeweiligen phpxx Ordner jedoch keine php-fcgi-starter

Die php-fcgi-starter werden nur angelegt, wenn man Apache verwendet und der betroffene Webspace für PHP via FastCGI konfiguriert ist.
Werfen Sie ggf. einfach mal einen Blick in die vHost-Konfiguration unter /etc/apache2/sites-enabled/web###.conf - dort steht dann jeweils, wie PHP eingerichtet ist (# PHP configuration for this subscription: ...).

Zitat von KaiserNero

hatte das Problem eben selber, habs manuell behoben

Sys:
LC Version: 1.7.1 - Platform: x86_64-unknown-linux-gnu - Revision: 2770
nginx (Version 1.0.15)
Centos6.5

Dann wird die nginx-Konfiguration aber schon mit einer älteren LiveConfig-Version erzeugt worden sein. Mit v1.7.1 wird die o.g. Anweisung wieder "richtig" in die Konfigurationsdatei geschrieben.

Viele Grüße

-Klaus Keppler

So lange nur ein Rechner aktiv ist reicht auch eine Lizenz.
Falls Sie DRBD nutzen, dann speichern Sie /etc/liveconfig/liveconfig.key am besten auch auf dem DRBD-Volume (dann gibt es keine Probleme bei der Lizenzverlängerung, falls zwischenzeitlich ein Failover stattgefunden hat).

Wie genau wir die Gültigkeit einer Lizenz prüfen möchte ich an dieser Stelle nicht verraten aber die lokalen IPs (oder sonstige Hardware-spezifischen Informationen) spielen dabei keine Rolle.

Das LiveConfig-Team freut sich, die Verfügbarkeit von Version 1.7.1 (r2770) bekanntgeben zu dürfen.

Die neue Version steht ab sofort im Download-Bereich sowie in allen Repositories bereit.

Die wichtigsten Änderungen zur vorherigen Version sind:

• mit der Schnellsuche können nun auch Verträge unterhalb von eigenen Resellern gesucht werden (klassischer Fall: welchem Reseller ist der Vertrag "web123" zugeordnet? -> einfach "web123" in die Schnellsuche eingeben)
• Konfiguration von MySQL-Optionen für LiveConfig-Datenbank (wenn MySQL-Backend verwendet wird)
• automatische Konfiguration von FCgidIOTimeout anhand von max_execution_time
• grundsätzlich ist nun die Verwendung verschiedener PHP-Versionen möglich (siehe Forum)

Die vollständige Liste aller Änderungen finden Sie im Änderungsverlauf.

Das Update ist wie gewohnt unkompliziert.

WICHTIG: aufgrund einer Änderung im internen LCCP-Protokoll sind alle Versionen <=1.7.0 zu den Versionen >=1.7.1 inkompatibel. Bei Multi-Server-Installationen müssen also der LC-Server und alle LC-Clients aktualisiert werden. Der LC-Server lehnt Verbindungen von "alten" Clients automatisch ab und protokolliert das auch.

Zitat von loswebos.de

Der Fehler mit PHP Einstellungen eines NNGINX-FCGI Hosts besteht in der aktuellen Preview
immer noch:

Ändere ich eine PHP Einstellung -> Stirbt der php-cgi Prozess.
Ändere ich eine PHP Einstellungen erneut -> Wird der php-cgi PHP Prozess gestartet.

Ich habe das eben mit CentOS 6.5 (AMD x64 via Xen) getestet und keine Probleme dabei gehabt - der Prozess wird jedes mal korrekt neu gestartet.

Was passiert denn, wenn Sie den Befehl manuell ausführen? Geben Sie dazu als letzten Parameter den Namen des betroffenen Vertrages an, z.B.:

/etc/init.d/nginx-php-fcgi restart web1

LiveConfig führt ja letztendlich auch nur genau diesen Befehl aus, wenn es Änderungen an der Konfiguration eines NGINX-vHosts gab.

Viele Grüße

-Klaus Keppler

Zitat von h_ka

Wo hinterlegt man die spezifischen php.inis für die zusätzlich installierten PHP Versionen? Zumindest ein globale Vorlage benötigt man ja, das man ein paar Werte, die dann grundsätzlich für alle gelten hinterlegen kann (Bsp ioncube Loader ...)

Das hängt von der Compile-Time-Konfiguration von PHP an. Der einfachste Weg das herauszufinden ist über eine phpinfo().

PHP-Version kann per .htaccess ab v1.7.1-r2769 umgeschaltet werden:
http://www.liveconfig.com/de/f…ig-v1-7-1?p=6774#post6774

Viele Grüße

-Klaus Keppler

Soeben wurde die Preview noch mal aktualisiert (v1.7.1-r2769). Mit dieser Version ist es nun relativ einfach möglich, mehrere PHP-Versionen gleichzeitig nutzen zu können.

Kurzanleitung:

• installieren Sie irgendwo auf dem Server Ihre zusätzlichen PHP-Binaries (nur die CGI/FCGI-Variante ist notwendig).
  Beispiel: Source für php 5.5.9 irgendwo entpacken, mit "configure --prefix=/opt/php-5.5.9" compilieren und in o.g. Pfad installieren (dann kollidiert das nicht mit anderen PHP-Versionen)
• Datei /usr/lib/liveconfig/lua/custom.lua anlegen bzw. folgende Zeile hinzufügen:
  
  
  Code

  LC.web.addPHP("php55", "/opt/php-5.5.9/bin/php-cgi")

  
  Der erste Parameter enthält das zu verwendende Versionkürzel (bei "php55" wird die Webspace-spezifische Konfiguration dann in ~/conf/php55 geschrieben); der zweite Parameter ist der Pfad zum CGI-Binary.
  

• Der Aufruf "liveconfig --diag" sollte nun die automatisch erkannte PHP-Version sowie die zusätzlich installierten Versionen anzeigen.
• LiveConfig neu starten.
• Wird nun irgendeine Webspace-Konfiguration neu geschrieben (z.B. nach Änderung der Web-Einstellungen oder an php.ini-Werten), dann pflegt LiveConfig automatisch auch die php.ini sowie einen php-fcgi-starter für die zusätzlichen Versionen mit.
• Um dann in einem Webspace z.B. PHP 5.5.9 zu verwenden, reicht folgende Zeile in einer .htaccess:
  
  
  Code

  FcgidWrapper /var/www/web1/conf/php55/php-fcgi-starter .php

  
  

In unseren Tests lief soweit alles einwandfrei durch; falls irgendwas haken sollte, geben Sie bitte eine kurze Rückmeldung.
Ab v1.7.2 werden die zusätzlichen Versionen dann auch in der LC-GUI mit angezeigt, so dass Anwender auch dort umschalten können.

Alternativ zur FastCGI-Variante kann man übrigens mittels zusätzlicher suPHP-Handler analog auch suPHP nutzen. Der Benutzer muss dann aber mittels suPHP_ConfigPath selbst den Pfad zur jeweiligen php.ini mit in der .htaccess angeben.

(ich glaube übrigens, dass man für die .htaccess hier die Berechtigung "AllowOverride FileInfo" (oder Options) braucht, hab' das noch nicht im Detail durchgetestet)

Viele Grüße

-Klaus Keppler

Danke für den Hinweis!
Um das kurzfristig zu beheben, öffnen Sie bitte die Datei /usr/lib/liveconfig/lua/apache.lua.
In Zeile 30 fügen Sie folgende Zeile ein:

local tonumber = tonumber

In Zeile 1275 (nach der Zeile "local val, unit = ...") bitte folgende Zeile ein:

val = tonumber(val)

Starten Sie LC anschließend neu.

Welchen Wert haben Sie für max_execution_time bzw. max_input_time für PHP eingerichtet? (suchen Sie bitte im betroffenen Webspace des Vertrags in ~/conf/php/php.ini nach diesen Werten).

Besten Dank schon mal!

-Klaus Keppler

Die Preview wurde eben aktualisiert (v1.7.1-r2766). Die Änderungen sind insbes.:

• Konfiguration von FcgidIOTimeout anhand der max_execution_time (#135)
• Problem mit AWStats und Großbuchstaben in Vertragsnamen beseitigt (#133)
• Quota-Prüfung beim Anlegen/Bearbeiten eines POP3/IMAP-Postfachs korrigiert (#134)
• rekursive Prüfung in übergeordneten Wiederverkäufer-Verträgen nach ausreichenden Ressourcen (PHP/CGI/SSI/Shell)
• Fehler in Ressourcen-Auswahl-Dropdown beim Anlegen neuer Verträge beseitigt

Aktuell befinden sich noch zwei kleinere Bugs in Arbeit (NGINX, SOAP-API), dann soll die produktive Freigabe erfolgen.

Eine Auswahl der PHP-Version befindet sich ebenfalls in Arbeit, wird in 1.7.1 wohl noch nicht enthalten sein, kann aber voraussichtlich ab morgen getestet werden (Details dazu dann morgen im Forum).

Viele Grüße

-Klaus Keppler

Ok, dann scheint der Private Key in der sslcert.pem "kaputt" zu sein.
Entfernen Sie bitte den kompletten Abschnitt von "-----BEGIN PRIVATE KEY-----" bis "-----END PRIVATE KEY-----" daraus und fügen diesen noch mal neu ein (am besten kopieren Sie den aus dem Key-File, das Sie scheinbar mit Apache fehlerfrei nutzen können).
Anschließend prüfen Sie bitte noch mal mit dem o.g. Befehl ("openssl rsa ..."), ob dieser dann korrekt gelesen werden kann.

Bitte senden Sie keine Dateien an DoRob (das hat seine Gründe).

Der Fehlermeldung nach tritt ein Problem beim Laden des Private Key auf. Welche Meldung liefert folgender Befehl:

openssl rsa -in /etc/liveconfig/sslcert.pem -check -noout

Haben Sie Teile der Datei vielleicht unter Windows (bzw. mit einem Windows-Editor) bearbeitet?

Führen Sie bitte mal folgenden Befehl aus, um eventuelle Windows-Zeilenumbrüche zu korrigieren:

sed -i -e 's/\r//' /etc/liveconfig/sslcert.pem

DoRob: Sie sollten den Ball besser mal gaaaanz flach halten. Soweit ich weiß haben Sie heute einen Termin in Aachen.

Es gab einen kleinen GUI-Fehler, so dass beim Anlegen eines neuen Vertrages mit der Auswahl "- individuell -" eventuell die Einstellungen des ersten Angebots in der Angebot-Dropdown-Liste verwendet wurden. Ist dann mit r2766 beseitigt.

Wenn Sie den Vertrag noch mal neu einrichten (evtl. auf Basis irgendeines Angebots) und anschließend über "Bearbeiten..." auf den Typ "- individuell -" setzen, müsste es eigentlich klappen.

Ich tippe mal darauf, dass "RESELLER-KUNDE.conf" im o.g. Fall alphabetisch vor dem Wort "default" liegt.
In diesem Fall liest Apache dessen Konfigurationsdatei zuerst ein und verwendet die daher als Standard-Host.

Abhilfe könnte es schaffen, im Verzeichnis /etc/apache2/vhosts.d/ einen Symlink von "default.conf" auf z.B. "000_default.conf" zu erstellen:

cd /etc/apache2/vhosts.d
ln -s default.conf 000_default.conf

Ist in der aktuellen Preview bereits behoben ("Fehler in NGINX-Konfiguration beseitigt (eingeführt mit v1.7.0-r2666)")

Diskussion wurde in diesen Thread verlagert:
http://www.liveconfig.com/de/f…tivierbar?p=6717#post6717