Re: Serverumzug und Debian
On 15.Mar 2004 - 23:01:06, Wolfgang Jeltsch wrote:
> Am Montag, 15. März 2004 22:46 schrieb Andreas Barth:
> > * Wolfgang Jeltsch (wolfgang@jeltsch.net) [040315 20:10]:
> > Naja, aber ob ihr ein Update von sarge (testing) auf sarge (stable)
> > macht, oder von Woody auf sarge, ist nicht so der grosse Unterschied.
> > Meine klare Empfehlung fuer Produktivsysteme: woody sowie, falls
> > notwendig, vertrauenswuerdige Backports.
>
> Wir werden schon z.T. neuere Software-Versionen brauchen. Mit woody müssten
> wir auf Backported Packages zurück greifen und die machen ja m.W. einige
> Probleme beim dist-upgrade.
Das kommt auf die Backports an, ihr muesst erst einmal feststellen bei
welche Software ihr definitiv neuere Versionen braucht, da helfen euch
packages.debian.org und die Changelogs der Pakete ( die von der
Paketseite aus verlinkt sind). Dann muesst ihr pruefen fuer welche
dieser Pakete ihr Backports findet und die Quellen checken, das heisst
mit den Maintainern der Quellen sprechen ob man erwarten kann das ein
upgrade ohne Probleme verlaeuft. Ihr muesst auch bedenken, die meisten
Backports werden aus unstable gebaut, was prinzipiell ein Problem ist,
da in sarge vermutlich eine etwas aeltere Version einziehen wird.
> Wie groß ist denn die Wahrscheinlichkeit, dass ein testing-System während der
> paar Monate, die sarge vermutlich noch testing ist, einem Hackerangriff zum
> Opfer fällt?
Das kommt drauf an was dort fuer Software laeuft, wie aufmerksam man
Logs beobachtet, in was fuer einer Netzwerkinfrastruktur der Rechner
steht.
> Werden Sicherheitslöcher in testing-Paketen eigentlich in
> akzeptabler Zeit gefunden
Nun gefunden werden die meisten Sicherheitsloecher in den Quellcodes,
denke ich. Also im "Upstream"
> und werden solche Löcher immer als Bugs gemeldet?
keine Ahnung.
> Dann könnte man sich ja anhand der einschlägigen Bugübersichten ein Bild
> davon machen, inwieweit der Einsatz von testing die Serversicherheit gefärden
> würde.
Das Problem ist, dass du diese Loecher dann selbststaendig flicken
musst! Denn nur unstable und stable bekommen Sicherheitspatches
"schnell". Bei unstable durch die neue Quellcodevariante, bei stable
durch einen Patch vom Security Team. Bei testing muss man warten bis
das Paket aus unstable nachrutscht, das dauert bei den meisten Paketen
mindestens 10 Tage, bei manchen (libc6, kdelibs4) nur 2. Aber oftmals
dauerts laenger, da ja auch die rc-bugs und alle Depends nach testing
muessen.... Du siehst fuer ein Produktivsystem ist testing die absolut
falsche Wahl, ausser natuerlich man hat Lust die ganzen Loecher selbst
zu flicken...
Andreas
--
optimist, n:
A bagpiper with a beeper.
Reply to: