-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Gerade musste ich feststellen, dass mein Mailserver nach:
Mar 22 14:03:10 Updated: mimedefang.i386 2.68-1.el5.rf
keine Mail mehr passieren ließ. Stattdessen erschienen bei jeder Mail die Logmeldungen:
Mar 22 14:49:47 gimli sendmail[7855]: o2MDnlWB007855: Milter (mimedefang): local socket name /var/spool/MIMEDefang/mimedefang.sock unsafe Mar 22 14:49:47 gimli sendmail[7855]: o2MDnlWB007855: Milter (mimedefang): to error state
MIMEDefang war beendet und ließ sich nicht mehr starten. Fehlermeldung:
[root@gimli ~]# /etc/init.d/mimedefang start Checking filter syntax: OK Starting mimedefang-multiplexor: /usr/bin/mimedefang-multiplexor: Unable to chdir(/var/spool/MIMEDefang): Permission denied [FAILED] Starting mimedefang: /usr/bin/mimedefang: Unable to chdir(/var/spool/MIMEDefang): Permission denied [FAILED]
Als Ursache stellte sich heraus, dass das Update eigenmächtig den Besitzer der Verzeichnisse /var/spool/MIMEDefang /var/spool/MD-Quarantine von meiner an meine lokalen Erfordernisse angepassten Einstellung (clamav.root) auf den Standardwert defang.defang zurückgesetzt hatte. Da mein MIMEDefang unter dem Benutzer clamav läuft, konnte er damit nicht mehr auf die Verzeichnisse zugreifen. Nachdem ich meine eigene Einstellung wiederhergestellt hatte, lief alles wieder einwandfrei.
Wie kann ich verhindern, dass ein solcher Vorfall sich wiederholt? MIMEDefang unter dem User defang laufen zu lassen ist keine Alternative, da dann der Virenscan mittels ClamAV wegen fehlender Zugriffsrechte auf /var/run/clamd/clamd.socket (den Socket des ClamAV-Daemons) fehlschlägt.
Danke für alle Tips,
Tilman
- -- Tilman Schmidt Abteilungsleiter Technik - ---------------------------------------------------------------- Phoenix Software GmbH Tel. +49 228 97199 0 Geschäftsführer: W. Grießl Fax +49 228 97199 99 Adolf-Hombitzer-Str. 12 www.phoenixsoftware.de 53227 Bonn, Germany Amtsgericht Bonn HRB 2934 - ----------------------------------------------------------------
Am Montag, den 22.03.2010, 15:25 +0100 schrieb Tilman Schmidt:
Als Ursache stellte sich heraus, dass das Update eigenmächtig den Besitzer der Verzeichnisse /var/spool/MIMEDefang /var/spool/MD-Quarantine von meiner an meine lokalen Erfordernisse angepassten Einstellung (clamav.root) auf den Standardwert defang.defang zurückgesetzt hatte. Da mein MIMEDefang unter dem Benutzer clamav läuft, konnte er damit nicht mehr auf die Verzeichnisse zugreifen. Nachdem ich meine eigene Einstellung wiederhergestellt hatte, lief alles wieder einwandfrei.
Wie kann ich verhindern, dass ein solcher Vorfall sich wiederholt? MIMEDefang unter dem User defang laufen zu lassen ist keine Alternative, da dann der Virenscan mittels ClamAV wegen fehlender Zugriffsrechte auf /var/run/clamd/clamd.socket (den Socket des ClamAV-Daemons) fehlschlägt.
Danke für alle Tips,
Tilman
Hallo Tilman
eine einfach Lösung gibt es leider nicht. Die Software-Verwaltung mittles RPM Paketen unterstützt das was Du vor hast nicht. Das Paket welches dir Problem macht kommt von rpmforge, deshalb solltes Du eventuell das Thema auf der rppmforge-users Mailingliste vortragen. Kommt dein clamav denn auch von rpmforge?
Chris
financial.com AG
Munich head office/Hauptsitz München: Maria-Probst-Str. 19 | 80939 München | Germany Frankfurt branch office/Niederlassung Frankfurt: Messeturm | Friedrich-Ebert-Anlage 49 | 60327 Frankfurt | Germany Management board/Vorstand: Dr. Steffen Boehnert | Dr. Alexis Eisenhofer | Dr. Yann Samson | Matthias Wiederwach Supervisory board/Aufsichtsrat: Dr. Dr. Ernst zur Linden (chairman/Vorsitzender) Register court/Handelsregister: Munich – HRB 128 972 | Sales tax ID number/St.Nr.: DE205 370 553
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Danke für die Antworten und sorry für die Sendepause - war ein bisschen hektisch hier die letzten Wochen.
Am 2010-03-22 20:16 schrieb Christoph Maser:
eine einfach Lösung gibt es leider nicht. Die Software-Verwaltung mittles RPM Paketen unterstützt das was Du vor hast nicht. Das Paket welches dir Problem macht kommt von rpmforge, deshalb solltes Du eventuell das Thema auf der rppmforge-users Mailingliste vortragen.
Seufz, noch eine Mailingliste mehr. Na gut, ich werde mich mal nach dieser Liste umschauen. Vielleicht haben die ja auch ein Archiv mit einer benutzbaren Suche (unwahrscheinlich, ich weiß) und vielleicht bin ich nicht der erste mit dem Problem.
Kommt dein clamav denn auch von rpmforge?
Ja, und da liegt natürlich die eigentliche Wurzel des Übels. Die rpmforge-Pakete mimedefang und clamd sind, vereinfacht gesagt, nicht kompatibel. Man muss mindestens eins von beiden händisch anpassen, damit sie zusammenspielen - und diese Anpassung macht das Update dann wieder kaputt.
Thx T.
- -- Tilman Schmidt Phoenix Software GmbH Bonn, Germany
Am Mon, 22 Mar 2010 15:25:00 +0100 schrieb Tilman Schmidt t.schmidt@phoenixsoftware.de:
Mar 22 14:03:10 Updated: mimedefang.i386 2.68-1.el5.rf
[..]
Als Ursache stellte sich heraus, dass das Update eigenmächtig den Besitzer der Verzeichnisse /var/spool/MIMEDefang /var/spool/MD-Quarantine von meiner an meine lokalen Erfordernisse angepassten Einstellung (clamav.root) auf den Standardwert defang.defang zurückgesetzt hatte.
[..]
Wie kann ich verhindern, dass ein solcher Vorfall sich wiederholt?
Konkret zum mimedefang kann ich mangels Eigenbedarf nichts beitragen, aber ganz grundsätzlich musst Du das immer mit dem Package-Maintainer diskutieren. Eigentlich halte ich es für schlechten Stil, Rechte vorher installierter Dateien per Paket-Update zu ändern, aber das muss man sicher immer am konkreten Fall betrachten und am Ende treffen hier auch "Philosophien" aufeinander.
So als erste Maßnahme mag helfen, das RPM aus dem automatischen Update-Zyklus herauszunehmen. Typischerweise werden solche Pakete in der yum.conf per "exclude" hinterlegt ("man 5 yum.conf" und dort nach "exclude" suchen). Das verhindert, dass sich mit dem nächsten "yum -y update" das Malheur wiederholt.
Hat natürlich zur Folge, dass Du die "exclude'ten" Pakete in Zukunft zu Fuß aktualisieren musst. Oder Du besorgst Dir das SRPM, änderst die SPEC und packst diese speziellen Pakete in Zukunft immer selbst. Die schiebst Du dann entweder in ein selbstgebasteltes, lokales repository (interessant, wenn man ne Serverfarm versorgen will) oder installierst per yum update --nogpgcheck xyz.rpm einzeln.
-
Christoph Maser -
Tilman Schmidt -
Tobias Crefeld