Halb-OT: Mailserver unter Jessie mit libssl aus Stretch

[FAjka]

Huhu,

vermutlich bin ich hier gerade etwas OT, aber "irgendwie" geht es ja doch um E-Mail-Server.

Ich möchte unter Debian einen IMAP-Server installieren und folge "im großen und ganzen" dieser Anleitung: https://www.debinux.de/2015/05/mailserv ... -debian-8/

Grundfunktion: Server soll ein GMX-Postfach pollen (das mache ich später mit fetchmail) und die E-Mails in einen Ordner einspielen, auf dem mehrere Benutzer mit IMAP arbeiten.

Als MTA habe ich exim4 installiert und konfiguriert und kann bereits (ausschließlich) lokale E-Mails verschicken (die landen im Maildir des zukünftigen Benutzers). Den Teil würde ich mal als "abgehakt" betrachten.

Wenn ich jetzt dovecot via apt installiere, bekommt ich eine Fehlermeldung die besagt, dass er das libssl (>1.0.2d) nicht nachziehen kann. Unter https://packages.debian.org/search?keywords=libssl1.0.2 habe ich gelernt, dass das Paket momentan nur im testing-Repository enthalten ist.

Meine /etc/apt/sources.list sieht im Moment so aus:

Code: Alles auswählen

root@mybot:/etc/apt# cat sources.list
# deb cdrom:[Debian GNU/Linux 8.2.0 _Jessie_ - Official amd64 NETINST Binary-1 20150906-11:09]/ jessie main

deb http://ftp.de.debian.org/debian/ jessie main
deb-src http://ftp.de.debian.org/debian/ jessie main

deb http://security.debian.org/ jessie/updates main
deb-src http://security.debian.org/ jessie/updates main

# jessie-updates, previously known as 'volatile'
deb http://ftp.de.debian.org/debian/ jessie-updates main
deb-src http://ftp.de.debian.org/debian/ jessie-updates main

deb http://http.debian.net/debian/ jessie main contrib non-free

Ich überlege, zwecks Bezugs eines aktuellen libssl-Paketes zumindest teilweise auf stretch zu schwenken. Dazu würde ich eine /etc/apt/sources.list/stretch anlegen:

Code: Alles auswählen

deb http://ftp.de.debian.org/debian/ stretch main
deb-src http://ftp.de.debian.org/debian/ stretch main

deb http://security.debian.org/ stretch/updates main
deb-src http://security.debian.org/ stretch/updates main

deb http://ftp.de.debian.org/debian/ stretch-updates main
deb-src http://ftp.de.debian.org/debian/ stretch-updates main

deb http://http.debian.net/debian/ stretch main contrib non-free

Bezüglich der weiteren Vorgehensweise bin ich ängstlich. Mein aktueller Ansatz ist, dass ich eine /etc/apt/preferences.d/stretch mit folgendem pinning erstelle:

Code: Alles auswählen

Package: *
Pin: release a=stable
Pin-Priority: 700

Package: *
Pin: release a=stretch
Pin-Priority: 650

...und im Anschluss das libssl mit

apt-get install libssl1.0.2

installieren und dann den dovecot nachziehe.

Ihr merkt schon - ich bin da momentan etwas unsicher (ich komme eigentlich aus der RedHat-Ecke)

Entspricht meine Vorgehensweise der "best practice"; auch in Bezug auf zukünftige Updates?
Macht das Sinn?
Oder würdet Ihr in dem Fall auf das pinning verzichten und komplett auf stretch wechseln?

Gruß,
Jörg

[catdog2]

Wenn ich jetzt dovecot via apt installiere, bekommt ich eine Fehlermeldung die besagt, dass er das libssl (>1.0.2d) nicht nachziehen kann. Unter https://packages.debian.org/search?keywords=libssl1.0.2 habe ich gelernt, dass das Paket momentan nur im testing-Repository enthalten ist.

Wofür willst du ein neueres libssl? Wenn du dovecot aus stable installierst installierst kommt ein passendes libssl.

Ich überlege, zwecks Bezugs eines aktuellen libssl-Paketes zumindest teilweise auf stretch zu schwenken. Dazu würde ich eine /etc/apt/sources.list/stretch anlegen:

....

Ihr merkt schon - ich bin da momentan etwas unsicher (ich komme eigentlich aus der RedHat-Ecke)

Entspricht meine Vorgehensweise der "best practice"; auch in Bezug auf zukünftige Updates?
Macht das Sinn?
Oder würdet Ihr in dem Fall auf das pinning verzichten und komplett auf stretch wechseln?

Nein! Das ist keine gute Idee und wird auch meist nicht funktionieren. (ganz wenige Ausnahmen bestätigen die Regel).

[FAjka]

Irgendwie bin ich gerade echt bescheuert - bei aller Euphorie habe ich mit bei "aptitude search" vertippt, dovecot falsch geschrieben und total übersehen, dass Debian über stable ein eigenes dovecot mitbringt.

Und aus genau diesem Grund das offizielle, externe dovecot-Repository eingebunden, dass aber wohl auf testing aufsetzt

Das ist keine gute Idee

Da muss ich jetzt doch noch mal nachhaken: Meine Idee, auf das pinning komplett zu verzichten und über die sources.list komplett auf stretch zu wechseln, würde doch zumindest ein konsistentes System erhalten, oder?

Ich überlege, ob ich das mal auf meinem Testnotebook mache, um mich dort zeitnah mit "etwas Neuem" zu beschäftigen.

[DeletedUserReAsG]

Meine Idee, […] komplett auf stretch zu wechseln, würde doch zumindest ein konsistentes System erhalten, oder?

Stretch ist Testing. Ist zwar meistens konsistent, aber eine Garantie dafür gibt es nicht. Außerdem gibt‘s da, soweit mir bekannt, keine expliziten Securityupdates. Ich denke, bei einem als Mailserver agierenden System möchte man sowohl größtmögliche Stabilität (im Sinne von kleinstmöglicher Wahrscheinlichkeit, dass ein Update irgendwas kaputtmacht und/oder Konfigurationen durchgesehen und angepasst werden müssen, damit’s wieder läuft), als auch zeitnah Sicherheitspatches haben. Aber letztlich muss es jeder für sich entscheiden …

[catdog2]

Da muss ich jetzt doch noch mal nachhaken: Meine Idee, auf das pinning komplett zu verzichten und über die sources.list komplett auf stretch zu wechseln, würde doch zumindest ein konsistentes System erhalten, oder?

Man kann komplett auf testing setzten, natürlich. Man hat dann aber im wesentlichen so eine Art rolling release (und idr. auch keine expliziten Sicherheitsupdates, die kommen halt wenn eine neue Version aus unstable raufblubbert). Auf dem Desktop meist ganz angenehm aber für einen Mailserver will man denk ich doch was stabiles. Was bietet dieses externe Repository überhaupt, dass du den Aufwand treibst? Fremdquellen sollte man aus diversen Gründen sowieso meiden.

[FAjka]

Was bietet dieses externe Repository überhaupt, dass du den Aufwand treibst?

Wie gesagt - ich habe mich bei meiner Aptitude-Kommandozeilensuche vertippt, den dovecot nicht gefunden und war deshalb davon ausgegangen, dass der via Paketverwaltung ausschließlich über sein eigenes Repository bezogen werden kann.

Alles gut!