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.
Welche? Quelle in /etc/apt/sources.list eintragen, und gut ist. (Unter "vertrauensw�rdiger Quelle" verstehe ich pers�nlich einen Package Maintainer, der in der Lage ist, updatef�hige .debs zu bauen...)
Ach so, beim Umstieg auf sarge, Entschuldigung. Nun, beim Hochziehen des Systems werden sicher so oder so Anpassungsarbeiten notwendig werden. Die Migration eine Produktivsystems w�rde ich immer als eigenes Projekt betrachten, deshalb w�rde ich _vorsichtshalber_ nicht einmal davon ausgehen, da� ein Upgrade von Woody nach Sarge reibungslos �ber die B�hne geht. Man kann IMHO gar nicht erwarten, da� sich Backports dann glatt integrieren w�rden.
Aber andererseits - schon mal versucht, eine andere Distribution als Ganzes �ber eine Versionsnummer hinweg zu hieven?
Been there, done that, and chose to reinstall.
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 h�ngt von der verwendeten Security Policy ab und wie gut das Konzept ausgearbeitet ist. Aus irgendeiner Quelle (deshalb v�llig unzuverl�ssig) habe ich einmal die Information erhalten, da� es bei bekannten IP-Ranges von z. B. Unis keine Viertelstunde dauert, bis die ersten Script-Kiddies an den Vorder- und Hintert�ren neu angeschlossener Systeme prokeln. Jetzt setze das genau so auf eine Maschine um, die 24/7 am Netz h�ngt. Reicht da die Firewall-Hardware allein zum Schutz wirklich aus? - Ich gehe mal davon aus, da� die Applikationen, die darauf laufen werden, unternehmenskritisch sind und man sich deshalb keine l�ngeren Downtimes leisten kann.
Das hei�t, Security by Obscurity (= darauf hoffen, da� das installierte System f�r ein einige Monate nicht gefunden wird und nicht weiter auff�llt) ist in etwa �quivalent damit, den nackerten Hintern im Erdgescho� aus dem Fenster zu h�ngen und zu glauben, da� keiner im Vorbeigehen draufklatschen wird - sehr bildlich gesprochen. :) Einmal ganz abgesehen davon, da� das erstere wohl auch etwas dem angestrebten Gesch�ftskonzept widersprechen w�rde, nehme ich an.
Werden Sicherheitsl�cher in testing-Paketen eigentlich in akzeptabler Zeit gefunden und werden solche L�cher immer als Bugs gemeldet? 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.
Es geht ja nicht nur um Sicherheitsupdates allein. Nach einem der letzten Wochenberichte (man korrigiere mich, wenn ich falsch liege) will man die Anzahl noch vorhandener Bugs im n�chsten Schritt auf ca. 200 dr�cken. Selbst wenn dieser Wert lediglich exotische Pakete betrifft, warte ich lieber noch, bevor ich mir einen Auszug derart vieler bekannter(!) Fehler auf einen Server hole.
-- Viele Gr��e, Kai
--
Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/
Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject "unsubscribe". Probleme? Mail an [EMAIL PROTECTED] (engl)
