[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Das Problem mit SID



Michelle Konzack wrote:

Bin jedenfals mit SARGE/SID nicht zufrieden...


Greetings
Michelle


Hallo,

ich kann das hier alles irgendwie nicht mehr richtig nachvollziehen.

Hier mal ein Beispiel:
Ich verwende auf einem Server Woody. Dummerweise sind im Woody jetzt aber einige Pakete dermassen alt, dass ich neuere Versionen davon benötige. Ich benötige unter anderem ein Sendmail, dass gegen libsasl2 gelinkt ist, und habe da dann noch spamassassin, f-prot, clamav und mailscanner drauf laufen. Zusätzlich baue ich noch den aktuellen cyrus-imapd selber, da ich das virtual-domain-feature benötige und es kein Debian-Paket mit dieser Version gibt. Wenn ich dieses Setup nun mit normalen Woody Boardmitteln bewerkstelligen will, müsste ich alles das selber kompilieren. Zusätzlich müsste ich die autotools und libtool selber bauen und mich so urplötzlich wieder um jedes Binary selber kümmern müssen. Es reicht nämlich auch nicht aus, einfach die Quellpakete einzuspielen und dpkg-buildpackage durchzuführen. Selbst da fehlen bei manchen Dingen bereits Pakete die für das build schon vorhanden sein müssen. Will ich also bei Woody bleiben, dann gibt es erstmal keine andere Möglichkeit, als alle diese Software direkt selber von den Upstream-Autoren zu besorgen und zu kompilieren. Naja. Wenn ich das sowieso machen wollte, dann könnte ich sehr wohl auch auf irgendein BSD umsteigen oder sonstwas verwenden. Ich habe vorher übrigens Solaris-x86 verwendet und bin genau aus diesem Grund auf Debian umgestiegen! Ich benutzte schliesslich Debian, da ich gerade eben davon profitieren will, dass bereits genug andere ein ähnliches/dasselbe Setup benutzen, und es demnach Pakete für alles das gibt. Getestet von vielen anderen und nicht nur von mir!

Ich habe z.B. das Glück, dass bis auf den cyrus-imapd sämtliche andere Software in entweder testing oder unstable zur Verfügung steht. Also konfiguriere ich apt so, dass es als default-release auf stable bleibt, und packe in die sources.list noch testing und unstable mit rein. Hiernach mache ich ein apt-get update/upgrade/dist-upgrade um zu überprüfen ob alles klappt. Das sollte dann erstmal keine neuen Pakete einspielen. Jetzt kommt aber das Problem. Wenn ich jetzt mit z.B. aptitude die fehlenden Pakete aus testing oder unstable installiere, dann haben die natürlich alle Abhängigkeiten in andere Pakete von testing oder unstable. Will heissen, ich habe nach dem Installieren der in Woody fehlenden Software zwar alles so, wie ich es brauche, ein apt-show-versions zeigt aber danach auch zu ca. 60% Pakete aus testing oder unstable. Von meinem Woody bleibt also nicht mehr viel übrig dabei. Nichtmal die libc6.

Niemand stellt ein Paket in Debian bereit, dass er nicht auch pflegt und bei entsprechenden Problemen updatet. Jetzt lese ich hier zwar das genaue Gegenteil, muss dazu aber sagen, dass mir das bei den Paketen, die ich aus testing oder unstable benutze, noch nie passiert ist. Da kommen Updates immer so, wie ich sie auch selber durchgeführt hätte, wenn ich alles selber bauen würde. Teilweise sogar schneller!

Das einzige, was bei meinem Vorgehen ein echter Nachteil zu sein scheint war, dass ich nach einem harten Plattencrash mit md5sums (oder so ähnlich) nachschauen wollte, welche Pakete re-installiert werden müssen. Dabei bemerkte ich, dass einige Pakete keine MD5-Prüfsumme bereitstellen. Ich weiss jetzt zwar nicht mehr, ob das zufällig auf die Pakete aus testing oder unstable zutraf, es war aber schon irgendwie ärgerlich, weil ich genau diese Pakete ohne Prüfsumme dann einfach alle neu installieren musste, um sicher sein zu können, nicht irgendwo noch irgendwelche Leichen im System zu haben.

Nachdem was ich jetzt hier so gelesen habe stellen sich mir da aber dann doch einige Fragen:

1. Was ist an meinem Vorgehen unsicherer, wenn ich mich auf die Maintainer verlassen kann ?

2. Wie kann ich es hinbekommen komplett bei Woody zu bleiben, ohne die fehlende Software selber zu bauen, und ohne irgendwelche fremden Pakete zu benutzen, die nicht von irgendeinem Debian-Spiegel stammen ?

3. Wer macht das ähnlich und würde davon mitlerweile abraten ?

4. Welchen Sinn macht Debian noch, wenn ich genau das, was ich damit mache, scheinbar besser lassen sollte ? Siehe oben. Dann kann ich auch auf ein BSD umsteigen und mich wirklich um jeden Dreck wieder selber kümmern. Bei kleiner Anzahl Maschinen mit Sicherheit auch kein grosses Thema. Bei grosser Anzahl von Maschinen werde ich aber irgendwann ein eigenes Paket-Archiv erstellen müssen, und eine zustäzliche Zeile in jede sources.list eintragen, damit meine eigenen Pakete "administrierbar" werden. Diese eigene sources.list Zeile entspräche in meinem Fall jetzt aber eigendlich genau testing bzw. zu einem kleinen Teil unstable! Warum dann also die nicht auch benutzen ?

5. Wie sollte Debian sich weiterentwickeln können, wenn alle nur die Stable-Release benutzen und niemand die Pakete aus testing oder unstable auch nur anrührt ?

6. Was ist daran unsicherer den Apache aus Woody (ich glaube 1.3.26) im Vergleich zu dem aus unstable (1.3.31) zu verwenden ? Ich kann doch eigendlich davon ausgehen, dass ein Sicherheitsloch im Woody-Apache auch sofort in unstable (wenn nicht sogar da zuerst) gefixt wird, oder ? Ich habe schon verstanden, dass es für testing und unstable kein _Debian_-Security-Team gibt. Das ändert aber doch nichts daran, dass zumindest derjenige, der z.B. den 1.3.31 Apache in unstable bereitstellt, sich auch um die Sicherheit seines Paketes, dass er höchstwahrscheinlich selber auf seinen Maschinen verwendet, kümmert. Warum sollte es denn sonst den 1.3.31 unstable Apache überhaupt geben ? Es ist doch richtig, dass ich davon ausgehen kann, dass die entsprechenden Maintainer ihre eigenen Pakete zumindest selber benutzen, oder ?

7. Habe ich Debian wirklich so komplett falsch verstanden ? Ich bin bisher eigendlich recht begeistert davon!

--
Christian



Reply to: