[Postfixbuch-users] clamav stirbt

[Christian Bricart]

Peer Heinlein schrieb:
> Am Dienstag, 3. Februar 2009 schrieb Christian Bricart:
> 
>> anderer Paketversionen. Deshalb werden ausschliesslich Bug- und
>> Security-Fixes geliefert."
> 
> Wenn ein Paket reproduzierbar einfriert und die Arbeit verweigert bei 100% 
> CPU-Auslastung.
> 
> Ist das dann kein Bug?

Hmm - hast du zu anderen (Debian-stable) Paketen ähnliche Erfahrungen?

Ich denke, dass es in diesem speziellen Fall eher auf die Ignoranz von 
"Upstream" zu schieben ist.. Immerhin bekommst du eine 
Fehler-/Warnungs-Meldung von freshclam, die durchgängig in 
GROSSBUCHTABEN geschrieben ist, dass du eine alte Version einsetzt, 
obwohl du damit Signaturupdates aus "trunk" ziehst - ich würde dann eher 
sagen, dass es der Fehler von clamav.net ist, keine abwärtskompatiblen 
(oder backgeportete) Signaturen  für (ver)alte(te) Versionen 
bereitzustellen..

> 
>> Volatile wiederum beinhaltet Paktete, die eben "volatil" - d.h. in
>> Bewegung sind. Um zu funktionieren _müssen_ hier und da Schnittstellen
>> geändert werden, oder neue (<- lies: den neuen Gegebenheiten
>> angepasste) Features implizieren eine Anhebung der Versionsnummer des
>> Pakets und _können nicht_ als Patch in die Versionsnummer des Pakets
>> aus "stable" zurückportiert werden - diese Eigenschaft steht in
>> direktem Widerspruch zur stable-Policy.
>> Als Beispiel eben: clamav, timezones, ..
> 
> Das sehe ich ein WENN das bisherige clamav in stable weiterhin 
> funktioniert. Tut es aber nicht!

solang du es in Ruhe lässt und keine neuen Signaturen einspielst.. ;-)
SCNR ;-)
Dann sollte evtl. freshclam die Signaturen nicht einspielen.. also 
Fehler/Unzulänglichkeit in freshclam, oder?

Oder anders: Die Signaturen, die du einspielst, kommen von einer 
"Nicht-Debian-Quelle" und können damit dein hübsches Paketmanagement 
eben aus den Angeln heben... Ist nur eine andere Art als auf deinem 
System mit "./configure --prefix=/usr && make && sudo make install" 
alles aus der Bahn zu kippen...
Ein Vorschlag wäre vielleicht von Debian ein (auf die installierte 
Version versioniertes) "clamav-data"-Paket anzubieten, welches dann halt 
nicht alle Funktionalität liefert, weil es nun mal die zu Grunde 
liegende veraltete Engine nicht kann..
Aber damit wäre einem ja auch nicht geholfen - nebst, dass dieses Paket 
sich wohl nach Policy auch in volatile wiederfinden wird...

Bleibt nur noch mein anderer Vorschlag clamav komplett aus "stable" zu 
verbannen und ausschliesslich aus volatile nachzuinstallieren...

> 
> Sobald das stable-Paket tot ist, muß man das doch als Bug fixen! Tausende 
> Server haben vor drei Jahren mal alles sauber installiert (als es noch 
> ohne volatile lief) und über Nacht nach einem billigen Siganturen-Update 
> gehen die alle in die Knie und funktionieren nicht mehr. Die 
> Debian-Maintainer machen hier einen Denial-of-Service gegen Tausende (!) 
> von Server. Wie kann man da um Himmels Willen kein Bugfix herausgeben?!

Sieh's mal andersrum: Du rufst nie mal "freshclam" auf und hat zumindest 
einen "Grundschutz" in der Basisinstallation. Wenn dir das nicht reicht, 
kannst du eben immer noch Volatile nehmen... (Ironie-Tags bitte 
dazudenken...)

Um bei einem anderen Paket aus Volatile zu bleiben: timezone
Dich als Server in Deutschland kratzt es doch wenig, wenn irgendeine 
Bananenepublik meint jetzt zwei Tage später auf Sommerzeit umzustellen..
Wenn dein Server in dieser Bananerepublik steht, dann schon..
Aber dieses Update hat ja nichts mit Security zu tun - und landet daher 
auch nicht in den Security-Updates.. -> volatile

> 
> Was rechtfertigt denn dann einen Bug-Fix wenn nicht der absolute 
> Server-Stillstand?
> 
>> Eben genau das versucht die Debian-Release-Policy zu garantieren: Ohne
>> Nachzudenken "neue" (<- lies: gepatchte) Pakete einzuspielen, ohne die
>> Stabilität des Gesamtsystems zu beeinflussen.
> 
> Da das System absolut steht sehe ich die Stabilität des Systems mehr als 
> nachhaltig beeinflußt. Es ist tot!
> 
> Ja, okay. Ein nicht-funktionierendes System ist auch ein "stabiler" 
> Zustand. Sorum betrachtet ist natürlich alles super.
> 
>> Hoffe ein wenig Licht in dein Dunkel gegeben zu haben
> 
> Naja, Verständnis kann ich dafür nach wie vor nicht aufbringen. Das 
> Grundprinzip ist mir ja schon klar. Aber ein toter Server ist ein toter 
> Server!

Soviel ich mitbekommen habe, ist die gesamte Problematik auch bei Debian 
bekannt und nachdem ja volatile ein offizielles Repository ist (seit 
Umzug von volatile.debian,net -> volatile.debian.org) wird es bei 
Installation von/ab Lenny direkt bei der Installation schon nebst 
"security" zum Anklicken angeboten. Und nochmal gesagt: Dieses 
Repository ist und gehört zu *stable* und nicht 
unstable/backports/testing/whatever.

Anderer Vorschlag zu einem System-Setup:
- Server aufsetzen mit Debian "stable" und Kernel-flavour "vserver" (was 
ich immer gerne als "chroot-on-steroids" bezeichne)
- kleine chroot (evtl. debootstrap wenn's auch Debian sein soll, kann ja 
dann unstable sein - sollte ja keine grossen Abhängikeiten geben, wenn's 
nur ein spezielles Programm ist) als vserver-Gast reininstallieren und 
exkusiv clamav dort rein.
- das Virenscannen die chroot erledigen lassen, den Rest "aussen" machen
- oder direkt auf nen externen Scanner-Rechner(-Cluster) schicken, der 
unter einer Distribution nach Wahl (evtl sogar auch LFS) läuft (kommt 
halt hier noch TCP-Overhead dazu..)

Aber wie gesagt - ich argumentiere hier für eine Distribution und Ihre 
Policy, die ich eigentlich in dieser Richtung gar nicht verteidigen 
will.. ;-)

'nuff said ;-)

Christian