Exim nicht in SLES Repositories. Manuel. Inst. scheintert!

Hallo mal wieder,

nach meinem letzten Topic bin ich nun soweit, den einzusetzenden MTA zu bestimmen. Exim soll es werden. Wo beim normalen Open SuSE ein passendes Paket in den Repositories vorhanden ist, zeigt SLES gähnende Leere. Ok das RPM Paket also selbst gesucht und die Installation getestet:

Dort zeigten sich Abhängigkeiten zum vorinstallierten Postfix. Also unter Software-Management in Yast gegangen und Postfix deinstalliert. Denkste...nun wurde gemeckert weil diverse Programme von Postfix abhängig sind (cron, mailx, mutt). Daher wird ohne eine Möglichkeit sich anders zu entscheiden Sendmail als Alternative installiert. Umgekehrt (Sendmail runter) ist es übrigens genauso, das nun Postfix installiert wird. Also hab ich auch die dahinter stehenden Abhängigkeiten manuell aufgelöst und cron, mutt und mailx vorübergehend entfernt. Jetzt gibts aber ein weiteres Problem, beim Entfernen von mailx oder mutt, entfernt er auch weitere Pakete. Exim ist nun aber seinerseits von einem dieser Pakete abhängig (logrotate) und kann wieder nicht installiert werden. Dieses logrotate alleine für sich zu installieren geht auch nicht, er will automatisch wieder Sendmail mitziehen!
Was kann ich den jetzt bitte noch machen? Das nenn ich mal nen Teufelskreis.
Und wieso gibts Exim nicht in den SLES Repositories? Kann ein SLES User mal bitte bestätigen, dass das Paket tatsächlich nicht vorhanden ist.

Kannst du doch selber prüfen:
http://software.opensuse.org/search?q=exim
Für alle 3 SLES Varianten gibts den aktuellen exim-4.74

Ich hab das RPM Paket von genau dieser Seite geladen. Deshalb fand ich es auch merkwürdig, dass ich es über das Paket Management nicht finden kann. Aber zusätzliche Repository Quellen müssen keine eingebunden werden, oder?

root me schrieb:

Aber zusätzliche Repository Quellen müssen keine eingebunden werden, oder?

Zum Vergrößern anklicken....

Verstehe ich nicht.
Alle Pakete die du installierst (hoffenlich per zypper) sollten in registrierten repos entstamen. Ansonsten kann zypper seinen Dienst nicht tun, da nicht klar ist woher die Pakete stammen.

Ich verwende auch exim (openSUSE) und das ohne Pobleme. Natürlich wird postfix deinstaliert, aber die anderen PAkete begnügen sich mit einem MTA.

Also bei Ubuntu ist es so, dass teilweise neue Quellen eingebunden werden müssen, um bestimmte -nicht-standardmäßige- Programme zu installieren. Da ich exim über die ganz normale Yast Paketverwaltung nicht finden kann und unter Quellen alle Standard-Quellen aktiv sind, wollte ich wissen, ob dies bei SUSE ebenfalls so ist. Wieso wird es mir sonst nicht angezeigt, wenn ich über das Suchfeld nach exim suche?
Manuell installiert hab ich bislang noch nichts unter SUSE. Würde exim auch lieber über Yast hinzufügen, dort würde er in einem Rutsch Postfix abräumen und exim installieren, ohne diese ganzen Komplikationen.
Ach und bei openSUSE finde ich das Paket auch, wie bereits erwähnt. Deshalb fragte ich nach SLES User.

root me schrieb:

Also bei Ubuntu ist es so, dass teilweise neue Quellen eingebunden werden müssen, um bestimmte -nicht-standardmäßige- Programme zu installieren. Da ich exim über die ganz normale Yast Paketverwaltung nicht finden kann und unter Quellen alle Standard-Quellen aktiv sind, wollte ich wissen, ob dies bei SUSE ebenfalls so ist.

Zum Vergrößern anklicken....

In diesem Fall ja, exim gibt es nicht in den Standard Repos von SLE. Du müsstest folgendes Repo einbinden: http://download.opensuse.org/repositories/server:/mail/SLE_11

Welche Pakete SLE mitbringt, siehst du hier unter Paketbeschreibungen.

Vielen Dank Tomm, genau das hab ich gesucht!

Ist das Repository offiziell von Suse für den SLES freigegeben? Wenn nicht, verlierst du den Supportanspruch bei Suse. Nimm den Postfix, kauf dir das Buch vom Peer Heinlein dazu oder ließ ein paar Howtos. Der Postfix ist im SLES sehr einfach zu konfigurieren für das was du brauchst.

Danke für den Hinweis. In meinem Fall ist es aber egal, da es sich nur um die Trial handelt, die danach nicht lizenziert wird.

root me schrieb:

Danke für den Hinweis. In meinem Fall ist es aber egal, da es sich nur um die Trial handelt, die danach nicht lizenziert wird.

Zum Vergrößern anklicken....

Welche auch nicht als Produktivstem eingesetzt wird und nur zum fummeln da ist, weil es nach 90 Tagen (oder so) keine Updates mehr gibt?

60 Tage sind es. Doch wird als Produktivsystem eingesetzt, aber in sicherer Umgebung und ohne Internetanbindung.

root me schrieb:

60 Tage sind es. Doch wird als Produktivsystem eingesetzt, aber in sicherer Umgebung und ohne Internetanbindung.

Zum Vergrößern anklicken....

:schockiert: Das muss man jetzt aber nicht verstehen, oder? Du setzt eine Testversion auf einem Produktivsystem ein?

Wieso installiert du nicht einfach opensuse? Da bekommst du länger Updates.

Was verstehste denn nicht? Ein Supportvertrag ist teuer und aufgrund der minimalen Anwendungen auf Seiten des Servers und der geschützten Umgebung sind eben keine Updates notwendig. Wo sind da die Probleme?

:schockiert: :zensur: Mehr fällt mir da nicht ein. Für mich ist hier EOD

Klugscheissen, mit -Smileys um sich werfen, aber keine Argumente nennen. Sympathischer Mod-Verein hier.

...Trials als Produktivsystem nutzen...
Und nach den 60 Tagen? Löschen und neu installieren?

Da bietet sich openSUSE wie vorgeschlagen halt an.

Ist sehr ungewöhnlich ein System in Production zu betreiben, welches keine Updates bekommt. Auch wenn es in einer sicheren Zone steht. Dann nimm doch openSUSE oder CentOS anstelle von SLES wo Du keine Lizenz kaufen willst/kannst.

root me schrieb:

Klugscheissen, mit -Smileys um sich werfen, aber keine Argumente nennen. Sympathischer Mod-Verein hier.

Zum Vergrößern anklicken....

Wir schmeissen hier nicht willkürlich mit Smileys umher und klugscheissen auch nicht. Wir sagen dir nur, wie es ist und wie du alles viel einfacher haben kannst. Auch ohne Geld ausgeben zu müssen.
Opensuse kannst du dir frei herunterladen und installieren. Du wirst auch länger mit Updates versorgt, als 90 Tage.
Du schreibst, dass der Server in einer sicheren Umgebung ist. Was ist daran zu verstehen? Dieser steht doch sicher im internen LAN, richtig? Auch da ist er gewissen Gefahren ausgesetzt. Denn es erfolgen nicht nur Angriffe von aussen, sondern auch der 0815 Anwender an einem PC kann ungewollt, sei es durch einen USB Stick, einen Virus oder ähnliches in Umlauf bringen,...

Ich meine ja nur, eine Erklärung wie du sie jetzt gebracht hast ist dann doch respektvoller, als eine Sache ohne Background-Wissen gleich als Schwachsinn abzustempeln.
Das es auch openSUSE gibt ist mir bekannt. SLES war eine Vorgabe die ich lediglich einhalte. Schätze mal es gibt Unterschiede bei der Stabilität der Systeme und die Verfügbarkeit ist ein wichtiger Punkt.
Btw. auf dem bisherigen Server läuft ein Unix OS, das seit 7 Jahren kein Update mehr gesehen hat. Die Dienstleistungen des Servers sind lowlevel und es geht auch nicht um Java Anwendungen, die häufig Fixes benötigen oder ähnliches.
Mit sicherer Umgebung ist gemeint, dass der Server nicht einmal im internen LAN steht, sondern hinter einer weiteren FW, die nichts rein lässt außer SSH und LDAP/s und nichts raus bis auf LDAP/s und SMPT über TLS. Auch physikalisch kann niemand Zugriff bekommen, da er in einem gesicherten, abgetrennten Bereich steht.
Also wenn es wirklich Gründe gibt die massiv gegen so ein Vorgehen sprechen, dann seit frei sie mir zu nennen. Bisher kann ich noch immer kein wirkliches Problem erkennen, welches seine Arbeit einschränken würde, oder ein Sicherheitsproblem darstellt.

root me schrieb:

Mit sicherer Umgebung ist gemeint, dass der Server nicht einmal im internen LAN steht, sondern hinter einer weiteren FW, die nichts rein lässt außer SSH und LDAP/s und nichts raus bis auf LDAP/s und SMPT über TLS. Auch physikalisch kann niemand Zugriff bekommen, da er in einem gesicherten, abgetrennten Bereich steht.
Also wenn es wirklich Gründe gibt die massiv gegen so ein Vorgehen sprechen, dann seit frei sie mir zu nennen. Bisher kann ich noch immer kein wirkliches Problem erkennen, welches seine Arbeit einschränken würde, oder ein Sicherheitsproblem darstellt.

Zum Vergrößern anklicken....

Da hast du mit der OP Frage nach exim ja ein super Gegenbeispiel in die Diskussion gebracht: Exim < 4.72 hatte einen Bug der es jeder Mail ermöglichte remote ein präpariertes Skript einzuschleusen und mit root Rechten zu starten. Das ging auch über SMTP per TLS, dein tolles System wäre also auch betroffen in dem Augenblick in dem es eine entsprechend präparierte Email entgegennimmt.

Fazit: Ein Rechner der nicht in regelmäßigen Intervallen mit Updates versorgt wird ist grundsätzlich ein Sicherheitsrisiko, da er im Zustand der Installation potentiell verwundbar ist durch Lücken die zum damaligen Zeitpunkt nicht bekannt sind.

Das Konzept "Ich klemme meinen Rechner so weit von außen ab dass ich zwar keine Updates fahren kann, macht aber nichts da extern niemand zugreifen kann" hat und wird deshalb nie funktionieren.