ISPConfig 3.0.5.4p8 Jessie diverse Fragen

epek

New Member
Hallo!
Ich habe früher Froxlor benützt und habe vor einem Jahr auf einem Vserver mit ISPConfig zu spielen begonnen. Jetzt wird es langsam mit der Migration ernst, aber es sind noch Fragen offen. Ich hoffe, dass ich hier ein paar Antworten bekomme. Mit Wheezy hat die Sache gut funktioniert, nach dem Update auf Jessie hat mir dann die Zeit gefehlt, mich weiter damit zu befassen.
1. Mailspace/Webspace/Datenbankspace: Es ist mir immer noch nicht klar, ob Mail und DB-Space vom Webspace abgezogen werden oder nicht. Aus dem Dashboard kann man das nicht eindeutig ablesen: Webseiten-Speicherplatz, Mailbox-Speicherplatz.
2. Dovecot:
a) Früher habe ich die folgenden Ports benützt: 110,143,993,995 und sieve auf 4190. Ich finde im ISPConfig keine Möglichkeit die Ports der Dienste einzustellen. Ändere ich die Datei dovecot.conf manuell und führe update.php aus, wird beim (sinnvollen) Neuerstellen der Konfiguration diese leider (glücklicherweise?) überschrieben. Die im conf.d/ Verzeichnis vorhandenen Schnipsel werden dabei anscheinend nicht beachtet. Wie wäre die in den Perfect Server Anleitungen der jüngsten Generation nicht erwähnte Vorgehensweise um Ports, Plugins udgl. zu bewerkstelligen?
[Nachtrag]
Die Vorlage, die ich gesucht habe, war ./ispconfig3/install/tpl/debian6_dovecot2.conf.master.
Aber die Frage, wie ich diese "update-safe" modifizieren kann, ist noch offen.
[/Nachtrag]
Gibt es ein lokales Dovecot-Template, das gegen unbeabsichtigtes Updaten geschützt ist?
b) ad plugins: gzip-Komprimierung der Postfächer?
[Nachtrag]
In der in Punkt a) genannten Datei habe ich die Zeile
mail_plugins = $mail_plugins zlib hinzugefügt und den Abschnitt plugin verändert wie folgt:
plugin {
quota = dict:user::file:/var/vmail/%d/%n/.quotausage
sieve=/var/vmail/%d/%n/.sieve
sieve_max_redirects = 25
zlib_save_level = 6
zlib_save = gz
}
[/Nachtrag]
c) SASL funktioniert nach dem Upgrade offenbar nicht mehr. Ich habe die einschlägigen und empfohlenen Settings aus /verschiedenen) PFSS für postfix+dovecot benützt:
smtpd_sasl_auth_enable = yes
smtpd_sasl_authenticated_header = yes
smtpd_sasl_path = private/auth
smtpd_sasl_type = dovecot
+broken sasl...
und außerdem versuchsweise:
smtpd_sasl_security_options = noanonymous
und kann wegen d) nicht viel debuggen. (Ja, ok, ich kann ihn im Vordergrund laufen lassen...)

[Nachtrag]
Der Postfix-Vorlage ./ispconfig3/install/tpl/debian_postfix.conf.master fehlte möglicherweise
smtpd_sasl_path = private/auth
smtpd_sasl_type = dovecot

Ich habe weiters die folgenden Zeilen hinzugefügt, um etwaigen Problemen mit dns-Lookups entgegenzuwirken:
smtp_dns_support_level = enabled
smtp_host_lookup = dns,native
[/Nachtrag]
d) In den mail.*-Logs sehe ich kaum Einträge hierzu. Postfix läuft und sagt das Folgende:
...
250-PIPELINING
250-SIZE 54525952
250-VRFY
250-ETRN
250-STARTTLS
250-AUTH PLAIN LOGIN
250-AUTH=PLAIN LOGIN
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN
3. dotdeb-php7 scheint übrigens mit ISPConfig zu funktionieren - allerdings kämpfe ich neuerdings mit dem Fehlen von mysqli in php5.6.x und 7. Wahrscheinlich ist es ein Denkfehler... da war doch irgendeine Änderung an den Mysql-Treibern zwischen PHP-Versionen?
4. letsencrypt plugin - will that be included in an official release? How does it work on shared ip servers? github.com dash alexalouit dash ISPConfig-letsencrypt.
[Nachtrag]
Da dies nicht entsprechend den Angaben der Readme.md funktioniert hat: überflüssiges ";done" im Cronjob, keine Zertifikatserstellung, teste ich dies nun mit ispconfig aus dem stable 3.1-Zweig. Wann ist in etwa mit einem offiziellen Stable-Release zu rechnen?
[/Nachtrag]
[Nachtrag]
Ich würde mich über jeden sachdienlichen Hinweis freuen. Die modifizierten Templates kann ich gerne bereitstellen, wenn die Änderungen erwünscht sind.
[/Nachtrag]
Danke im Voraus!
 
Zuletzt bearbeitet:

Till

Administrator
Ein Debian Dist Upgrade muss man wie folgt durchführen:

1) Debian Dist Upgrade.
2) Update von ISPConfig mit 3.0.5.4p8 mit "reconfigure services", dies aktualisiert die config Dateien und passt sie an den neuen Versionsstand der Softawre an.
3) Login in ISPConfig und unter Tools > Resync die Webseiten resncen.

Habe ich bereits bei vielen Servern gemacht, anpassungen von Templates sind nicht notwendig.

Wenn Du manuell config dateien geändert hast dann musst Du die Template sin /usr/local/ispconfig/server/conf-custom/install/ hinterlegen und zukünftig vor ISPConfig Updates Dein manuelles Template gegen das ISPConfig Template der neuen Version prüfen um sicherzustellen dass Deine modifiziere Version kompatibel mit dem neuen ISPConfig release ist.
 

epek

New Member
Ein Debian Dist Upgrade muss man wie folgt durchführen:

1) Debian Dist Upgrade.
2) Update von ISPConfig mit 3.0.5.4p8 mit "reconfigure services", dies aktualisiert die config Dateien und passt sie an den neuen Versionsstand der Softawre an.
3) Login in ISPConfig und unter Tools > Resync die Webseiten resncen.

Habe ich bereits bei vielen Servern gemacht, anpassungen von Templates sind nicht notwendig.

Wenn Du manuell config dateien geändert hast dann musst Du die Template sin /usr/local/ispconfig/server/conf-custom/install/ hinterlegen und zukünftig vor ISPConfig Updates Dein manuelles Template gegen das ISPConfig Template der neuen Version prüfen um sicherzustellen dass Deine modifiziere Version kompatibel mit dem neuen ISPConfig release ist.
Hallo!
ad 1) Ich nutze Debian seit dem Jahr 2002 und das auf mehreren Servern; ich denke nicht, dass ich an diesem Punkt auch nur irgendwas offensichtlich falsch gemacht haben könnte ;-)
Davor hatte ich mit Tante SuSE meine liebe Not.
ad 2) Das habe ich gemacht. Im install-Dir php5 update.sh mit reconfigure. Wie sich herausgestellt hat, wurde mein le-Zertifikat mit einem selbst-signierten Zertifikat überschrieben. Daher funktionierte sasl nicht "empty". Tante Google hat den Hinweis für mich gefunden. Ich habe das nicht gleich mitbekommen, weil ich wegen eines anderen Problems ein Brett vor dem Kopf hatte. Haken wir Sasl also ab.
Jetzt habe ich mit Postfix nur noch das Problem, dass es relay recipient checks auf externen Domains (Routing) macht. Da muss ich mich erst hineindenken, warum die transport_maps in dem Template so etwas eigenartiges machen. (Betrifft nicht nur Subdomains (im DNS-Jargon), sondern auch andere Domains.) Hinweis: ich bin mittels Backup wieder auf 3.0.5.4p8 zurückgegangen.
ad 3) Bedeutet resync hierbei "Konfiguration neu erstellen" oder Syncen auf slave-Server? Letztere benutze ich noch nicht. Ich muss einmal die 373 Seiten des Manuals durchackern. Leider ist meine Version nicht mehr ganz aktuell.

Ad Templates: Genau das war meine Frage, aber wie schütze ich diese Datei davor, dass ispconfig_update.sh sie überschreibt? (Ja chmod... aber das fällt unter obscurity ;-) Ich dachte da an debian_xyz.conf.local oder so... meistens will man ja nur Kleinigkeiten hinzufügen, wie cipherlist, dhparams, dns-Abfrage-Reihenfolge, etc.
 
Zuletzt bearbeitet:

epek

New Member
Ok, danke, sorry, dass ich offensichtlich unkonzentriert war und drübergelesen habe.
Eine andere Frage: Kann man in ISPConfig irgenwo außerhalb der Templates zentral die verfügbaren Ciphersuites (für Mail und Web) einstellen? Ich suche das unter Serverkonfiguration/{web|mail}/SSL-Optionen vergeblich. Unter Froxlor war das recht praktisch.

Das Problem mit dem Mailrouting besteht noch. Wenn von einem lokalen Konto aus via SMTP an eine Domain versendet wird, die als secondary MX in ISPConfig (Mailrouting) eingerichtet ist, erfolgt eine Ablehnung weil der lokale Empfänger überprüft wird, den es im Falle eines Transports nicht gibt.

Als nächsten Schritt würde ich gerne Sympa anstelle von Mailman einrichten. Gibt es dazu Bestrebungen? Beziehungsweise, wohin soll man sich mit kleineren, konkreten Verbesserungsvorschlägen und Code melden?
 

Till

Administrator
Ok, danke, sorry, dass ich offensichtlich unkonzentriert war und drübergelesen habe.
Eine andere Frage: Kann man in ISPConfig irgenwo außerhalb der Templates zentral die verfügbaren Ciphersuites (für Mail und Web) einstellen? Ich suche das unter Serverkonfiguration/{web|mail}/SSL-Optionen vergeblich. Unter Froxlor war das recht praktisch.

Dafür sind die template overrides dar. also einfach ins template einfügen und das template in conf-custom speichern. Das unter server optionen zu legen halte ich für nicht besonders gut denn man braucht es, wenn überhaupt, einmal bzw stellt es gleich global in der nginx.conf ein. Wenn wir alle möglichen Einstellungen alle Dienste die man garnicht oder höchstens einmalig ändert in die settings im Interface legen würde hatten wir ca. 1-2 tausend zusätzliche Felder, das macht das Ganze dann nicht gerade übersichtlich.

Das Problem mit dem Mailrouting besteht noch. Wenn von einem lokalen Konto aus via SMTP an eine Domain versendet wird, die als secondary MX in ISPConfig (Mailrouting) eingerichtet ist, erfolgt eine Ablehnung weil der lokale Empfänger überprüft wird, den es im Falle eines Transports nicht gibt.

Mailroutng ist natürlich nur für die Domains bzw. Adressen erlaubt die Du unter Relay recipients angelegt hast, denn sonst wäre Dein Server eine Backscatter Spam Schleuder. Hast Du die Aressen dort im ISPConfig Mail Modil eingefügt?

Als nächsten Schritt würde ich gerne Sympa anstelle von Mailman einrichten. Gibt es dazu Bestrebungen?

Da ist nichts geplant bislang.

Beziehungsweise, wohin soll man sich mit kleineren, konkreten Verbesserungsvorschlägen und Code melden?

http://git.ispconfig.org/ispconfig/ispconfig3/issues
 

epek

New Member
Dafür sind die template overrides dar. also einfach ins template einfügen und das template in conf-custom speichern. Das unter server optionen zu legen halte ich für nicht besonders gut denn man braucht es, wenn überhaupt, einmal bzw stellt es gleich global in der nginx.conf ein. Wenn wir alle möglichen Einstellungen alle Dienste die man garnicht oder höchstens einmalig ändert in die settings im Interface legen würde hatten wir ca. 1-2 tausend zusätzliche Felder, das macht das Ganze dann nicht gerade übersichtlich.

Ich persönlich würde Templates im "conf.d"-Stil bevorzugen, da dies unter Debian und Ubuntu der dortigen Art entspräche und auf diese Weise die custom-confs im selben Verzeichnis liegen könnten.

Ad Cipherlist ich stelle die Frage einfach zum Nachdenken: grundsätzlich stellt sich diese Frage auch bei anderen Diensten als den Webservern, wobei die Notation abweichen kann. Vielleicht ergibt es dennoch Sinn solche Einstellungen zentral zu machen und nicht auf viele Dienste-Templates zu verteilen? Die Notation kann ja das Update-Skript transponieren.

Mailroutng ist natürlich nur für die Domains bzw. Adressen erlaubt die Du unter Relay recipients angelegt hast, denn sonst wäre Dein Server eine Backscatter Spam Schleuder. Hast Du die Aressen dort im ISPConfig Mail Modil eingefügt?

Ähm, ... was hat ein Backup-MX für eine externe Domain [reiner smtp-transport] mit Backscatter zu tun?
Das Wesen des Backup-MX ist es ja gerade, Mails im Falle, dass der Primary-MX nicht verfügbar ist, zu puffern.
Wenn ich also die Domain abc.domain hoste, und lokale Mailboxen für diese Domain hoste, aber der Domain bcd.domain den Backup-MX mache, dann ist es unsinnig, dass der sasl-authenticated user sender@abc.domain nicht an receipient@bcd.domain senden darf. Das Wesen eines Backup-MX ist es ja gerade, dass user nicht dort, sondern am Primary-MX angelegt werden - dessen Aufgabe ist es dann auch Backscatter zu vermeiden, nicht die des Backup, der die User-Liste von Primary.bcd.domain nicht kennt, nicht kennen kann und nicht kennen soll. Natürlich besteht die Gefahr, dass der Primary falsch konfiguriert ist, aber das ist bei Relays immer die Gefahr.


Schade. Ich finde dass Sympa schon immer der bessere Mailman war - virtuelle Domains, unterschiedliche Datenquellen (Text, verschiedene Datenbanken), mehr Einstellungen. Wenn es Mitstreiter gibt, mit denen man das voranbringen könnte, wäre es ein Hit.


Ich hätte nach Features gesucht. Ok, danke!
 

Werbung

Top