Re: Das Problem mit SID
Am 2004-06-09 11:27:58, schrieb Christian Schulte: Keine Ahnung. Wenn ich bei mir unter Woody apt-src aus den Quellen mit dpkg-buildpackage baue, dann will es beim Installieren Abhängigkeiten, die es in Woody nicht gibt. [EMAIL PROTECTED]:~/apt-src-0.25$ ls apt-src AptSrc.pm config debian Makefile.PL man TODO Die Datei ist im Debian-Paket das ich in Woody compiliert habe vorhanden und wird in /usr/share/perl5/AptSrc.pm abgelegt. Das Perl-Modul scheint im apt-src dabei zu sein. Keine Ahnung warum ich ein apt-get source libapt-pkg-perl-sonstwas machen musste und warum mir libapt-pkg-perl ist in woody das oder sowas ähnliches dann die apt-Quellen heruntergeladen hat. Einfache in apt-get install libapt-pkg-perl machen und gut ist Da ich meine Pakete alle in einen localen mirror verschiebe kann ich bequem ein apt-get install apt-src machen und die Abhängigkeiten werden einfach aufgelößt. Du machst also einfach nur apt-get source apt-src cd apt-src-0.25 fakeroot dpkg-buildpackage und kannst danach das Paket installieren und es läuft ? Unter Woody auch ? Habe es laufen... Christian Greetings Michelle -- Linux-User #280138 with the Linux Counter, http://counter.li.org/ Michelle Konzack Apt. 917 ICQ #328449886 50, rue de Soultz MSM LinuxMichi 0033/3/8845235667100 Strasbourg/France IRC #Debian (irc.icq.com) signature.pgp Description: Digital signature
Re: Das Problem mit SID
On Mon, Jun 07, 2004 at 12:12:16AM +0200, Christian Schulte wrote: Michelle Konzack wrote: Am 2004-06-06 02:10:22, schrieb Christian Schulte: apt-src tuts eigendlich. Das gibts aber nicht in woody und ein backport würde ein aktuelleres APT vorraussetzen. Bei mir scheitert das daran, ??? Also das, was Du mir da geschickt hast, bekomme ich natürlich auch selber hin. Einfach nur die Abhängigkeiten im Control-File auf ein weniger aktuelles APT herunter zu setzen reicht aber nicht. Will heissen, wenn ich Dein apt-src starte, bricht es sofort mit einer Fehlermeldung Can't locate AptPkg/Source.pm in @INC ab. Das ist auch gar kein Wunder, da dieses Perl-Modul erst in einem späteren APT nach Woody hinzugefügt wurde! Will ich also dieses fehlende Perl-Modul unter Woody nutzen, dann brauche ich ein APT, was das mitbringt. Nehme ich nun die APT-Quellen aus unstable, dann kompiliert das nicht. Weder unter unstable selber, noch unter Woody. [...] Also kein apt-src unter Woody ohne AptPkg/Source.pm. Das meinte ich. Ohne jetzt hier große Compiler- und Lauf-Tests anzustellen kann ich dir sagen daß das apt aus testing kein AptPkg/Source.pm enthält, es trotzdem ein apt-src gibt und dieses auch nur auf apt dependet , nicht auf apt (= n) Ich werde diese Version für meine Tests nehmen. Christian gruss f
Re: Das Problem mit SID
Frank Lorenzen wrote: On Mon, Jun 07, 2004 at 12:12:16AM +0200, Christian Schulte wrote: Michelle Konzack wrote: Am 2004-06-06 02:10:22, schrieb Christian Schulte: apt-src tuts eigendlich. Das gibts aber nicht in woody und ein backport würde ein aktuelleres APT vorraussetzen. Bei mir scheitert das daran, ??? Also das, was Du mir da geschickt hast, bekomme ich natürlich auch selber hin. Einfach nur die Abhängigkeiten im Control-File auf ein weniger aktuelles APT herunter zu setzen reicht aber nicht. Will heissen, wenn ich Dein apt-src starte, bricht es sofort mit einer Fehlermeldung Can't locate AptPkg/Source.pm in @INC ab. Das ist auch gar kein Wunder, da dieses Perl-Modul erst in einem späteren APT nach Woody hinzugefügt wurde! Will ich also dieses fehlende Perl-Modul unter Woody nutzen, dann brauche ich ein APT, was das mitbringt. Nehme ich nun die APT-Quellen aus unstable, dann kompiliert das nicht. Weder unter unstable selber, noch unter Woody. [...] Also kein apt-src unter Woody ohne AptPkg/Source.pm. Das meinte ich. Ohne jetzt hier große Compiler- und Lauf-Tests anzustellen kann ich dir sagen daß das apt aus testing kein AptPkg/Source.pm enthält, es trotzdem ein apt-src gibt und dieses auch nur auf apt dependet , nicht auf apt (= n) Ich werde diese Version für meine Tests nehmen. Keine Ahnung. Wenn ich bei mir unter Woody apt-src aus den Quellen mit dpkg-buildpackage baue, dann will es beim Installieren Abhängigkeiten, die es in Woody nicht gibt. [EMAIL PROTECTED]:~/apt-src-0.25$ ls apt-src AptSrc.pm config debian Makefile.PL man TODO Das Perl-Modul scheint im apt-src dabei zu sein. Keine Ahnung warum ich ein apt-get source libapt-pkg-perl-sonstwas machen musste und warum mir das oder sowas ähnliches dann die apt-Quellen heruntergeladen hat. Du machst also einfach nur apt-get source apt-src cd apt-src-0.25 fakeroot dpkg-buildpackage und kannst danach das Paket installieren und es läuft ? Unter Woody auch ? -- Christian -- 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)
Re: Das Problem mit SID
On Wed, Jun 09, 2004 at 11:27:58AM +0200, Christian Schulte wrote: Frank Lorenzen wrote: [...] Ohne jetzt hier große Compiler- und Lauf-Tests anzustellen kann ich dir sagen daß das apt aus testing kein AptPkg/Source.pm enthält, es trotzdem ein apt-src gibt und dieses auch nur auf apt dependet , nicht auf apt (= n) Ich werde diese Version für meine Tests nehmen. Keine Ahnung. Wenn ich bei mir unter Woody apt-src aus den Quellen mit dpkg-buildpackage baue, dann will es beim Installieren Abhängigkeiten, die es in Woody nicht gibt. [EMAIL PROTECTED]:~/apt-src-0.25$ ls apt-src AptSrc.pm config debian Makefile.PL man TODO Das Perl-Modul scheint im apt-src dabei zu sein. Keine Ahnung warum ich ein apt-get source libapt-pkg-perl-sonstwas machen musste und warum mir das oder sowas ähnliches dann die apt-Quellen heruntergeladen hat. Du machst also einfach nur apt-get source apt-src cd apt-src-0.25 fakeroot dpkg-buildpackage und kannst danach das Paket installieren und es läuft ? Unter Woody auch ? Nein, das kann ich nicht. Ich wollte nur ausdrücken, daß das apt / apt-src aus testing offenbar stabiler ist als das aus unstable. Zumindes läßt sich apt aus testing unter testing compilieren. Deshalb werde ich mir für meine Experimente unter woody (mit denen ich noch nicht angefangen habe) das apt / apt-src aus testing zur Hand nehmen und nicht das aus unstable. Christian gruss f
Re: Das Problem mit SID
Hallo Christian, Am 2004-06-09 11:27:58, schrieb Christian Schulte: Du machst also einfach nur apt-get source apt-src cd apt-src-0.25 fakeroot dpkg-buildpackage und kannst danach das Paket installieren und es läuft ? Unter Woody auch ? ich habe das paket unter woody gebastelt und mal import mit 400 sourcen ausprobiert... Dann habe ich die sourcen upgegraded... Allerdings hat er mit die dependencies libc6 2.3 oder perl 5.8 nicht entsprechend für WOODY angepaßt. Sprich, 'apt-src' ist nur bedingt unter WOODY tauglich. Aber alleine schon das automatische updaten der Sourcen ist es wert. Christian Greetings Michelle -- Linux-User #280138 with the Linux Counter, http://counter.li.org/ Michelle Konzack Apt. 917 ICQ #328449886 50, rue de Soultz MSM LinuxMichi 0033/3/8845235667100 Strasbourg/France IRC #Debian (irc.icq.com) signature.pgp Description: Digital signature
Re: Das Problem mit SID
Frank Lorenzen wrote: On Wed, Jun 09, 2004 at 11:27:58AM +0200, Christian Schulte wrote: Frank Lorenzen wrote: [...] Ohne jetzt hier große Compiler- und Lauf-Tests anzustellen kann ich dir sagen daß das apt aus testing kein AptPkg/Source.pm enthält, es trotzdem ein apt-src gibt und dieses auch nur auf apt dependet , nicht auf apt (= n) Ich werde diese Version für meine Tests nehmen. Keine Ahnung. Wenn ich bei mir unter Woody apt-src aus den Quellen mit dpkg-buildpackage baue, dann will es beim Installieren Abhängigkeiten, die es in Woody nicht gibt. [EMAIL PROTECTED]:~/apt-src-0.25$ ls apt-src AptSrc.pm config debian Makefile.PL man TODO Das Perl-Modul scheint im apt-src dabei zu sein. Keine Ahnung warum ich ein apt-get source libapt-pkg-perl-sonstwas machen musste und warum mir das oder sowas ähnliches dann die apt-Quellen heruntergeladen hat. Du machst also einfach nur apt-get source apt-src cd apt-src-0.25 fakeroot dpkg-buildpackage und kannst danach das Paket installieren und es läuft ? Unter Woody auch ? Nein, das kann ich nicht. Ich wollte nur ausdrücken, daß das apt / apt-src aus testing offenbar stabiler ist als das aus unstable. Zumindes läßt sich apt aus testing unter testing compilieren. Deshalb werde ich mir für meine Experimente unter woody (mit denen ich noch nicht angefangen habe) das apt / apt-src aus testing zur Hand nehmen und nicht das aus unstable. Ah jetzt ja! Danke. -- Christian -- 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)
Re: Das Problem mit SID
Am 2004-06-06 02:10:22, schrieb Christian Schulte: apt-src tuts eigendlich. Das gibts aber nicht in woody und ein backport würde ein aktuelleres APT vorraussetzen. Bei mir scheitert das daran, ??? dass apt sich weder auf woody noch auf unstable überhaupt kompilieren liesse. Ginge dass, hätte man auch apt-src unter woody. Habe gerade ebend apt-src mal gebastelt... Allerdings ist es Orphaned Schicke es Dir per PM Christian Greetings Michelle -- Linux-User #280138 with the Linux Counter, http://counter.li.org/ Michelle Konzack Apt. 917 ICQ #328449886 50, rue de Soultz MSM LinuxMichi 0033/3/8845235667100 Strasbourg/France IRC #Debian (irc.icq.com) signature.pgp Description: Digital signature
Re: Das Problem mit SID
Michelle Konzack wrote: Am 2004-06-06 02:10:22, schrieb Christian Schulte: apt-src tuts eigendlich. Das gibts aber nicht in woody und ein backport würde ein aktuelleres APT vorraussetzen. Bei mir scheitert das daran, ??? Also das, was Du mir da geschickt hast, bekomme ich natürlich auch selber hin. Einfach nur die Abhängigkeiten im Control-File auf ein weniger aktuelles APT herunter zu setzen reicht aber nicht. Will heissen, wenn ich Dein apt-src starte, bricht es sofort mit einer Fehlermeldung Can't locate AptPkg/Source.pm in @INC ab. Das ist auch gar kein Wunder, da dieses Perl-Modul erst in einem späteren APT nach Woody hinzugefügt wurde! Will ich also dieses fehlende Perl-Modul unter Woody nutzen, dann brauche ich ein APT, was das mitbringt. Nehme ich nun die APT-Quellen aus unstable, dann kompiliert das nicht. Weder unter unstable selber, noch unter Woody. Unter unstable passiert folgendes: Compiling policy.cc to ../build/obj/apt-pkg/policy.opic policy.cc: In member function `void pkgPolicy::CreatePin(pkgVersionMatch::MatchType, std::basic_stringchar, std::char_traitschar, std::allocatorchar , std::basic_stringchar, std::char_traitschar, std::allocatorchar , short int)': policy.cc:186: error: no matching function for call to ` std::vectorpkgPolicy::Pin, std::allocatorpkgPolicy::Pin ::insert( __gnu_cxx::__normal_iteratorpkgPolicy::Pin*, std::vectorpkgPolicy::Pin, std::allocatorpkgPolicy::Pin )' /usr/include/c++/3.3/bits/vector.tcc:89: error: candidates are: __gnu_cxx::__normal_iterator_Tp*, std::vector_Tp, _Alloc std::vector_Tp, _Alloc::insert(__gnu_cxx::__normal_iterator_Tp*, std::vector_Tp, _Alloc , const _Tp) [with _Tp = pkgPolicy::Pin, _Alloc = std::allocatorpkgPolicy::Pin] /usr/include/c++/3.3/bits/stl_vector.h:671: error: void std::vector_Tp, _Alloc::insert(__gnu_cxx::__normal_iterator_Tp*, std::vector_Tp, _Alloc , unsigned int, const _Tp) [with _Tp = pkgPolicy::Pin, _Alloc = std::allocatorpkgPolicy::Pin] policy.cc:200: error: no matching function for call to ` std::vectorpkgPolicy::PkgPin, std::allocatorpkgPolicy::PkgPin ::insert( __gnu_cxx::__normal_iteratorpkgPolicy::PkgPin*, std::vectorpkgPolicy::PkgPin, std::allocatorpkgPolicy::PkgPin )' /usr/include/c++/3.3/bits/vector.tcc:89: error: candidates are: __gnu_cxx::__normal_iterator_Tp*, std::vector_Tp, _Alloc std::vector_Tp, _Alloc::insert(__gnu_cxx::__normal_iterator_Tp*, std::vector_Tp, _Alloc , const _Tp) [with _Tp = pkgPolicy::PkgPin, _Alloc = std::allocatorpkgPolicy::PkgPin] /usr/include/c++/3.3/bits/stl_vector.h:671: error: void std::vector_Tp, _Alloc::insert(__gnu_cxx::__normal_iterator_Tp*, std::vector_Tp, _Alloc , unsigned int, const _Tp) [with _Tp = pkgPolicy::PkgPin, _Alloc = std::allocatorpkgPolicy::PkgPin] make[2]: *** [../build/obj/apt-pkg/policy.opic] Fehler 1 make[1]: *** [all] Fehler 2 make: *** [build/build-stamp] Fehler 2 Also kein apt-src unter Woody ohne AptPkg/Source.pm. Das meinte ich. dass apt sich weder auf woody noch auf unstable überhaupt kompilieren liesse. Ginge dass, hätte man auch apt-src unter woody. Habe gerade ebend apt-src mal gebastelt... Das ist nicht das Problem. Allerdings ist es Orphaned Was immer damit gemeint ist. Wenn das meint, dass Dein Paket nicht lauffähig ist, dann frage ich mich, was ich damit anfangen soll. Schicke es Dir per PM Trotzdem danke. Wäre es eigendlich überhaupt sinnvoll, ein APT-Backport von unstable für Woody zu bauen ? -- Christian
Re: Das Problem mit SID
Am 2004-06-05 00:04:21, schrieb Frank Lorenzen: Es ist ja schön daß du dein Script in letzter Zeit öfter mal erwähnst. Es wäre noch schöner wenn du das irgendwo auch mal der Öffentlichkeit zur Verfügung stellen könntest, denn grundsätzlich könnte ich sowas auch Nur ist es so, das dieses Scripte speziell für meine Bedürfnisse angepaßt sind... (Habe auch einige Sachen in meinen Scripten manuell gelößt :-/ ) Das gilt zum Beispiel auch, für das CPU-Abhängige compilieren von Sourcen, sprich, Du kannst mit so einem Script alle notwendigen Sourcen automatisch herunterladen und dann zum Beispiel für den K7 compilieren... Aber selbst Wenn Du mein Script hast, mußt Du noch wissen was DU tust. Denn wenn Du sowas wie fvwm 2.5.10 unter WOODY compilieren willst, mußt DU ebend eine per Paket Config manuell erstellen, sprich, das DU ihn ohne irgendwelche XF86 v4.3 extensiosn compilierst... (Beispiel) Selbst mein Script bewahrt Dich nicht davor, zu wissen was Du tust. Allerdings muß ich sagen das lezteres auf 2.5.8 zutraf. 2.5.10 ließ sich hervorragend compilieren... Manjo Srivasta hat erstklassige Arbeit geleistet. gebrauchen, fühle mich auch durchaus in der Lage das anzugehen. Aber du weißt ja: Auf einer grünen Wiese ist es immer so grün; sprich: Ich bin faul und wenn es schon einen Ansatz gibt, warum sollte ich nochmal anfangen. ... gruss f Michelle -- Linux-User #280138 with the Linux Counter, http://counter.li.org/ Michelle Konzack Apt. 917 ICQ #328449886 50, rue de Soultz MSM LinuxMichi 0033/3/8845235667100 Strasbourg/France IRC #Debian (irc.icq.com) signature.pgp Description: Digital signature
Re: Das Problem mit SID
Frank Lorenzen wrote: On Tue, Jun 01, 2004 at 11:39:14AM +0200, Michelle Konzack wrote: [...] Backports automatisieren Da mußte wie ich eine Liste der gewünschten Pakete anlegen und ein BASH-Script basteln :-) Habe insgesamt 18 UNSTABLE Pakete und habe in den lezten 2 Monaten kein einziges von Hand compiliert. :-) naja, das Script muß ebend in der Lage sein, control und Changelog selbständig zu ändern. War ein bischen Arbeit, aber es funktioniert. Es ist ja schön daß du dein Script in letzter Zeit öfter mal erwähnst. Es wäre noch schöner wenn du das irgendwo auch mal der Öffentlichkeit zur Verfügung stellen könntest, denn grundsätzlich könnte ich sowas auch gebrauchen, fühle mich auch durchaus in der Lage das anzugehen. Aber du weißt ja: Auf einer grünen Wiese ist es immer so grün; sprich: Ich bin faul und wenn es schon einen Ansatz gibt, warum sollte ich nochmal anfangen. apt-src tuts eigendlich. Das gibts aber nicht in woody und ein backport würde ein aktuelleres APT vorraussetzen. Bei mir scheitert das daran, dass apt sich weder auf woody noch auf unstable überhaupt kompilieren liesse. Ginge dass, hätte man auch apt-src unter woody. -- Christian
Re: Das Problem mit SID
On Tue, Jun 01, 2004 at 11:39:14AM +0200, Michelle Konzack wrote: [...] Backports automatisieren Da mußte wie ich eine Liste der gewünschten Pakete anlegen und ein BASH-Script basteln :-) Habe insgesamt 18 UNSTABLE Pakete und habe in den lezten 2 Monaten kein einziges von Hand compiliert. :-) naja, das Script muß ebend in der Lage sein, control und Changelog selbständig zu ändern. War ein bischen Arbeit, aber es funktioniert. Es ist ja schön daß du dein Script in letzter Zeit öfter mal erwähnst. Es wäre noch schöner wenn du das irgendwo auch mal der Öffentlichkeit zur Verfügung stellen könntest, denn grundsätzlich könnte ich sowas auch gebrauchen, fühle mich auch durchaus in der Lage das anzugehen. Aber du weißt ja: Auf einer grünen Wiese ist es immer so grün; sprich: Ich bin faul und wenn es schon einen Ansatz gibt, warum sollte ich nochmal anfangen. Greetings Michelle gruss f
Re: Das Problem mit SID
Am Dienstag, 1. Juni 2004 00:45 schrieb Michelle Konzack: Am 2004-05-31 22:47:40, schrieb Christian Schulte: Michelle Konzack wrote: Bin jedenfals mit SARGE/SID nicht zufrieden... Greetings Michelle Hallo, ich kann das hier alles irgendwie nicht mehr richtig nachvollziehen. Wieso ? - Die Diskusion betrifft ja ein 100% SARGE/SID. s.u. [...] 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 Ich selber verwende den aus SID. Nachdem ich weis, das jede menge ISP's ihn erfolgreich verwenden und auch bei mir die Cracker bis jetzt (!!!) nichts anrichten konnten... Also das glaub ich ja jetzt nicht, du bist ja wirklich sehr flexibel. Wie schon erwähnt, sind die die Maintainer der Server-Software wesentlich schneller mit Bug-Fixes... warscheinlich, weil einfach mehr dahintersteckt... Ach na sieh mal einer an. Und warum erzählst Du uns ein paar Stunden früher hier in der gleichen Diskussion, das Du Woody einsetzt auf Grund von Sicherheitsproblemen in SID? Zitat Konzack: Und die Sicherheitsprobleme ? Die Upstream Autoren und Package Maintainer in SID reagieren wesentlich langsamer als das Security Team für WOODY. Ich habe bereits mehrfach auf patches über einen Monat warten müssen. Ich empfinde das nicht besonderst lustig. Und trotzdem setzt du ausgerechnet die gefärdeten Serverdienste aus SID ein? Also weist Du. -- mfg Peter Küchler
Re: Das Problem mit SID
Am 2004-06-01 02:40:49, schrieb Christian Schulte: Michelle Konzack wrote: Backports liefert lediglich ein paar ausgewählte pakete aus SID nach WOODY mit entsprechend angepaßten Abhängigkeiten wie der libc6 2.2.5 zum Beispiel Und zufällig sind genau die dabei, die es bisher verhindert haben, dass ich meine Software unter Woody kompilieren konnte. Perfekt! :-) Meine Server sind alle STABLE, mir AUSGEWÄHLTEN UNSTABLE Backports So hätte ich das bisher auch gerne gemacht, aber ich kannte backports.org halt nicht und war viel zu faul, jetzt gleich 20-30 Pakete alle selber zu bauen. Teilweise baue ich sie selber, weil ich sie zum Beispiel mit anderen optionen konfiguriere/compilier. mailscanner, unzip, etc.). Jetzt stellt sich mir noch genau eine Frage. Wie organisiere ich jetzt am besten meine lokalen Pakete ? Ich habe jetzt in meinem Homeverzeichniss einfach immer apt-get --default-release=unstable source paket eingegeben und dann im entsprechenden Verzeichniss, nachdem ich im control-File einige Dinge geändert hatte fakeroot dpkg-buildpackage Soweit so gut. Was ich gerne hätte wäre aber, dass ich apt-get update/upgrade eingebe, und dann auch immer die aktuellen Quellen bekomme. Wie kann man das am besten lösen ? Ich habe da etwas von apt-src oder apt-build gelesen, bin mir aber nicht sicher, wie man das jetzt am besten macht. Irgendwelche Howtos oder ähnliches ? Ich kann so erstmal damit leben an die 10 Pakete alle selber zu übersetzen. Aber ohne automatisch immer die aktuellesten Quellen aus Unstable zu bekommen, machts wieder weniger Sinn. Da mußte wie ich eine Liste der gewünschten Pakete anlegen und ein BASH-Script basteln :-) Habe insgesamt 18 UNSTABLE Pakete und habe in den lezten 2 Monaten kein einziges von Hand compiliert. :-) naja, das Script muß ebend in der Lage sein, control und Changelog selbständig zu ändern. War ein bischen Arbeit, aber es funktioniert. Christian Greetings Michelle -- Linux-User #280138 with the Linux Counter, http://counter.li.org/ Michelle Konzack Apt. 917 ICQ #328449886 50, rue de Soultz MSM LinuxMichi 0033/3/8845235667100 Strasbourg/France IRC #Debian (irc.icq.com) signature.pgp Description: Digital signature
Re: Das Problem mit SID
Am 2004-06-01 08:35:38, schrieb Peter Kuechler: Und warum erzählst Du uns ein paar Stunden früher hier in der gleichen Diskussion, das Du Woody einsetzt auf Grund von Sicherheitsproblemen in SID? Weil ursprünglich von einem Desktop-System ausgegangen wurde und da habe ich ausschließlich negative erfahrungen gemacht, womit ich nicht aleine bin Zitat Konzack: Und die Sicherheitsprobleme ? Die Upstream Autoren und Package Maintainer in SID reagieren wesentlich langsamer als das Security Team für WOODY. Ich habe bereits mehrfach auf patches über einen Monat warten müssen. Ich empfinde das nicht besonderst lustig. Das betraf Desktop-Systems Und trotzdem setzt du ausgerechnet die gefärdeten Serverdienste aus SID ein? Also weist Du. Also ich habe für den Apache zihmlich schnell patches bekommen (1-2 Tage) mfg Peter Küchler Greetings Michelle -- Linux-User #280138 with the Linux Counter, http://counter.li.org/ Michelle Konzack Apt. 917 ICQ #328449886 50, rue de Soultz MSM LinuxMichi 0033/3/8845235667100 Strasbourg/France IRC #Debian (irc.icq.com) signature.pgp Description: Digital signature
Re: Das Problem mit SID - ich gebs auf
Am Dienstag, 1. Juni 2004 11:43 schrieb Michelle Konzack: Am 2004-06-01 08:35:38, schrieb Peter Kuechler: Und warum erzählst Du uns ein paar Stunden früher hier in der gleichen Diskussion, das Du Woody einsetzt auf Grund von Sicherheitsproblemen in SID? Weil ursprünglich von einem Desktop-System ausgegangen wurde und da habe ich ausschließlich negative erfahrungen gemacht, womit ich nicht aleine bin Zitat Konzack: Und die Sicherheitsprobleme ? Die Upstream Autoren und Package Maintainer in SID reagieren wesentlich langsamer als das Security Team für WOODY. Ich habe bereits mehrfach auf patches über einen Monat warten müssen. Ich empfinde das nicht besonderst lustig. Das betraf Desktop-Systems Und trotzdem setzt du ausgerechnet die gefärdeten Serverdienste aus SID ein? Also weist Du. Also ich habe für den Apache zihmlich schnell patches bekommen (1-2 Tage) Ach tatsächlich? Also jetzt versteh ich garnix mehr. Was hab ich eigentlich die ganze Zeit erzählt? Ich klink mich jetzt aus der Diskussion aus, hat keinen Sinn glaube ich. -- mfg Peter Küchler
Re: Das Problem mit SID - ich gebs auf
Am 2004-06-01 12:59:19, schrieb Peter Kuechler: Ach tatsächlich? Also jetzt versteh ich garnix mehr. Was hab ich eigentlich die ganze Zeit erzählt? Wir waren bei Desktop ! Dafür habe ich eine NICHT akzeptabele Zeit warten müssen. Nämlich bis zu 2 Monate ! Die Maintainer der größeren Projecte (apache, samba, ...) werden aber von wesentlich mehr externen programmierern unterstützt, was dazu führt, das Patches wesentlich schneller verfügbar sind. Ich klink mich jetzt aus der Diskussion aus, hat keinen Sinn glaube ich. Auf dem Desktop haste das nicht... Wenn Du Software aus SID verwendest, solltest Du Dich VORHER informieren, ob da eine einzelne Person (Upstream) daran hängt oder ein Team. Ich vertraue keinem Paket aus SID, das von einer einzigen Person entwickelt und gewartet wird. mfg Peter Küchler Greetings Michelle -- Linux-User #280138 with the Linux Counter, http://counter.li.org/ Michelle Konzack Apt. 917 ICQ #328449886 50, rue de Soultz MSM LinuxMichi 0033/3/8845235667100 Strasbourg/France IRC #Debian (irc.icq.com) signature.pgp Description: Digital signature
Re: Das Problem mit SID - ich gebs auf
Michelle Konzack wrote: Ich vertraue keinem Paket aus SID, das von einer einzigen Person entwickelt und gewartet wird. www.backports.org ist eine Person: Norbert Tretkowski ??? Maximale Verwirrung! -- Christian -- 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)
Re: Das Problem mit SID - ich gebs auf
Am 2004-06-01 17:30:07, schrieb Christian Schulte: Michelle Konzack wrote: Ich vertraue keinem Paket aus SID, das von einer einzigen Person entwickelt und gewartet wird. www.backports.org ist eine Person:Norbert Tretkowski ??? Maximale Verwirrung! Mit warten meine ich die Developer und Upstream Autoren, bzw, die. Original Paket Betreuer. Norbert nimmt lediglich die Sourcen aus UNSTABLE und macht Pakete daraus. Im Klartext: Er hat keinen direkten Einfluß aud irgendwelche security Updates. Das einzige was er machen muß ist aufpassen, wenn von einem von ihm gebasteltem Paket eine neue Version kommt, diese wieder neu für WOODY zu packen. Da muß ich sagen volbringt Norbert eine hervorragende Leistung. Wenn Du unbedingt Backports haben willst oder mußt, dann empfehle ich Dir http://www.backports.org/ Christian Greetings Michelle -- Linux-User #280138 with the Linux Counter, http://counter.li.org/ Michelle Konzack Apt. 917 ICQ #328449886 50, rue de Soultz MSM LinuxMichi 0033/3/8845235667100 Strasbourg/France IRC #Debian (irc.icq.com) signature.pgp Description: Digital signature
Re: Das Problem mit SID
Am Sonntag, 30. Mai 2004 22:04 schrieb Andreas Pakulat: On 30.May 2004 - 20:11:52, Peter Kuechler wrote: Am Sonntag, 30. Mai 2004 18:05 schrieb Michelle Konzack: Am 2004-05-30 10:13:27, schrieb Peter Kuechler: Warum denn? Du hast doch recht. Ich hatte noch nie beser laufende Rechner wie die mit Debian SID. Dan hast Du aber die Maschine nur über einen Router/Firewall am Internet, denn die Sicherheitslöchet die SID hat sind nicht übersehbar. Die gibt es überall und immer wieder, oder warum glaubst Du, gibt es dei Patches für Woody? Ja und bei Sid musst du selber Patchen oder hoffen das der Maintainer nicht schlaeft und nen fix bereitstellt... Du scheinst keine besonders hohe Meinung über die Entwickler zu haben... Es liegt schon in ihrem eigenen Interesse, solche Sicherheitslöcher in ihrem aktuellen Code zu stopfen, findest Du nicht? Und, oh Wunder, tauchen neue Versionen der Software in SID am ehesten auf. Habe pro Tag mehr als 50 Portsscans und noch wesentlich mehrere Hackangriffe. Die Logdateien sind voll damit... und abundzu verendet der pppd... Die beissen sich an meinem Paketfilter die Zähne aus:-) Was ist wenn der nen Fehler hat? Der Paketfilter hat weder was mit SID, Woody, Suse oder sonst was zu tun. Er ist Sache des Kernels, und da bediene ich mich schon seit Jahren nur der Vanilla-Kernel. Dort passt wenigstens jeder Patch. Übrigens habe ich nicht meine Arbeitsplatzrechner am Internet, sondern meinen Fileserver/DNS/Timeserver/DHCP/Mailserver/Einwahlrechnen für Fernwartung. Naja und Firewall für meinen DSL-Zugang ist er auch noch. Ich schliesse mal daraus dass du diese Dienste fuers Internet freigegeben hast? Falsch, alle Dienste gehen nur ins interne Netz. Ich würde mir sehr gut überlegen, ob ich auf einem Rechner, der _auch_ als Firewall dient, Dienste für den Zugriff von aussen zur Verfügung stelle:- Was ist wenn einer davon ein Sicherheitsloch hat und der Maintainer grad 4 Wochen in Urlaub? Interessiert mich aus o.g. Grund nicht, muß es ja auch nicht;-) Machst du wirklich nur alle paar Monate ein Upgrade? Na dann lass mal lieber niemanden der boeswillig ist deine IP rauskriegen.. s.o. Ok, noch mal zur Erklärung: Ich habe den Eindruck, das hier alles über einen Kamm geschoren wird. Es muß doch jedem einleuchten, das an einen Rechner, der Dienste ins Internet zur Verfügung stellt, ander Anforderungen gestellt werden wie an einen Rechner, der solchen Gefahren nicht direkt ausgesetzt ist. Oder nochmal deutlicher: Wenn ich einen Rechner habe, der als nur als Paketfilter dienen soll, dann kann es mir scheißegal sein, ob der apache in SID gerade ein Sicherheitsloch hat. Ich kenne KEINEN, der mit seinem Arbeitsplatzrechner, den er jeden Tag nach der Arbeit für 2 Stunden einschaltet, Dienste im Internet zur Verfügug stellt. Somit reicht ein Paketfilter, der KEINEN Verbindungsaufbau von aussen zulässt, aus. Wenn ich einen Rechner ins Internet stellen muß, dann steht er in einer DMZ, und es laufen nur die Programme darauf, die für diesen einen Dienst gebraucht werden. Hier kann man sicher nochmal neu überlegen, was man einsetzt. SID, Woody, Suse oder sogar BSD, wie es Dieter in einer Mail geschrieben hat. -- mfg Peter Küchler
Re: Das Problem mit SID
Am Sonntag, 30. Mai 2004 20:23 schrieb Elmar W. Tischhauser: Hallo! On 30 May 2004 at 14:34 +0200, Maurice wrote: ^^^ Ich würde dich gerne mit vollem Namen ansprechen können. Wäre das möglich? Danke. Elmar W. Tischhauser [EMAIL PROTECTED] wrote: Es ist für den sicherheitsbewussten unstable-Nutzer also keinesfalls hinreichend, nur [EMAIL PROTECTED] zu verfolgen. Aber was macht man dann? Sich Zusatzinformationen beschaffen, was im Falle des Privatanwenders [...] Die Wahl sid/woody dürfte für die Nettosicherheit eines an öffentliche Datennetze angeschlossenen Debian-Rechners wesentlich weniger von Bedeutung sein als die Sachkunde des Administrators oder die Mentalität der Anwender. Sehr schön geschrieben. Du hast die Sache noch viel besser auf den Punkt gebracht wie ich in meiner Mail. Was man hier teilweise liest, grenzt meiner Meinung nach teilweise an Paranoia. Nehmt es mir nicht übel, aber was Elmar hier schreibt entspricht im wesentlichen auch meinen Erfahrungen. -- mfg Peter Küchler
Re: Das Problem mit SID
Am Sonntag, 30. Mai 2004 22:20 schrieb Dieter Franzke: 'nabend, On Sunday 30 May 2004 22:04, Andreas Pakulat wrote: On 30.May 2004 - 20:11:52, Peter Kuechler wrote: Am Sonntag, 30. Mai 2004 18:05 schrieb Michelle Konzack: Am 2004-05-30 10:13:27, schrieb Peter Kuechler: Warum denn? Du hast doch recht. Ich hatte noch nie beser laufende Rechner wie die mit Debian SID. ich schon, müssen wir aber jetzt nicht breittreten.) Wieso nicht...? Nein schon gut, war ein Scherz;-) [...] s.o., für solche Sachen verwende ich dann lieber doch nen BSD. Ich weiss, dass ich damit hier nicht auf viel Gegenliebe rechnen kann, aber bei uns in der Firma ist Policy: intern Linux und Rechner, auf die von extern zugegriffen wird bekommen nen *BSD spendiert. Hat sich bis jetzt bewährt. Naja, ist doch prima und vor allem die Hauptsache. Wenn Du dich mit einem BSD an diesen Stellen sicherer fühlst und gut damit zurecht kommst, dann ist es die richtige Lösung für dich. Vieleicht mach ich das ja auch mal so. Damit warte ich aber noch bis ich mit SID das erste mal auf die Nase gefallen bin;-) Die beissen sich an meinem Paketfilter die Zähne aus:-) Ist nur ne Frage der Zeit, die ich habe und der kriminellen Energie. Ist beides hoch und groß genug, biste dran Ist bei dem Paketfilter eher unwahrscheinlich. Nicht unmöglich, ganz klar, aber eher unwahrscheinlich. Manche exploits kommen schneller als du reagieren kannst) 14 Tage offen (unbeabsichtigt und bis dato unbemerkt) sind mehr als genug. Wenn du dann mit deinem Rechner an exponierter Stelle stehst (web- oder Mailserver), haste schon verloren. Klar, hier geht es wieder um Dienste. -- mfg Peter Küchler
Re: Das Problem mit SID
Moin Elmar,
Am 2004-05-30 20:23:35, schrieb Elmar W. Tischhauser:
Hallo!
Sich Zusatzinformationen beschaffen, was im Falle des Privatanwenders
nicht einmal übermäßig zeitaufwändig ist, da zum Beispiel alle von
böswilligen (lokalen) Benutzern ausgehenden Probleme schon mal per
definitionem vom Tisch sind.
;-)
Wenn also die Eingabe eines seltsamen Passwortes einen Pufferüberlauf im
setuid-root installierten /usr/bin/passwd provozieren kann, ist das zu
Hause weitaus weniger kritisch ist als etwa in einem Uni-Rechnerpool.
Gut das ist acceptabel
Generell dürften die für den sid-Privatanwender relevanten Gefahren sich
auf folgende Szenarien beschränken (dabei sind nur Angriffe von außen,
also aus dem WAN, berücksichtigt).
Auf diesewürde ich mich auch beziehen...
1. Fehler im IP- oder TCP-Stack des Kernels. Das wären generisch
(da Exploits meist an spezielle Kernelversionen gebunden sein
dürften).
Das ist das schöne an Linux...
Es gibt ewig vile Kernel-Versionen...
Abhilfe: Möglichst aktuellen Kernel einsetzen.
Das ist sowieso zu empfehlen...
Schon alleine wegen der neuen Hardware...
2. Fehler in auf dem öffentlichen Interface angebotenen Diensten (z.B.
HTTP, SSH). Die kommen immer mal wieder vor und werden gelegentlich
Bei den $USER dürfet sich allmählich auch 'amule' oder 'xmule'
breit machen was die gefahr erheblich erhöht.
nichts zum Einbruch verwendet werden. Ansonsten bietet es sich an,
entweder die Security-Advisory-Mailingliste o.ä. des speziellen
Dienstes zu verfolgen oder regelmäßig auf dessen Homepage
nachzusehen. In den meisten Fällen dürfte unstable bald die nötigen
Denke das ist sowieso pflicht, nur mit den neuen Linux $USER
haut das nicht hin. Di machen mit Linux das gleiche wie mit
windows
Updates bereithalten, ansonsten kompiliert man sich die gefixte
Upstream-Version unter Verwendung des letzten unstable-Sourcepakets
schnell selbst.
Wieviele wollen keine Pakete selber bauen ? - unendlich viele !
4. Fehler in Clientprogrammen, welche aus dem Netz stammende Daten
verarbeiten bzw. mit dem Internet interagieren (z.B. Browser, MUA,
Bildanzeigeprogramm). Wenn beispielsweise Letzteres beim Anzeigen
Abhilfe: Wie bei (2). Zusätzlich hilft gesundes Misstrauen gegen
nette Attachments oder dubiose Webseiten erheblich.
spamassassin und f-prot
6. Würmer/Viren/Trojanische Pferde. Wenn sie sich automatisiert
installieren können, liegt ein Fall von (1)-(4) vor. Wenn nicht, ist
man ohnehin selbst schuld.
:-)
Abhilfe: Mehr als Verwendung des Gehirns in Kombination mit gesundem
Menschenverstand ist nicht erforderlich.
Wieviele NEU-Linux $USER verfügen über sowas ?
Das sind fast ausschließlich Click-und-Bunti-Typen
7. Konfigurationsfehler. Gegen solche hilft auch der Einsatz von Woody
nichts ;-).
Abhilfe: Sachverstand beim Administrieren.
Den haben Linux-Neu $USER garantiert nicht...
Da man als Privatanwender in der Regel keine Dienste am öffentlichen
Interface und nur wenige lokal benötigt [auch unter den lokalen sind ja
nur diejenigen wirklich kritisch, welche aus nicht vertrauenswürdigen
Quellen stammende Daten verarbeiten], reduziert sich die Menge der
kritischen Anwendungen, die man auf aktuellem Stand halten sollte,
erheblich.
Das sehe ich auch so...
Ich habe nur folgende Bednken:
Neue Linux $USER installieren einen SID-Desktop, sprich
Basisinatsllation, x-window-system, KDE|GNOME,
OpenOffice, Mozilla Xmms|MPlayer, Gaim
Das ist meiner Erfahrung nach, das, was so ziehmlich alle benötigen.
Dafür gibt es vollständige Backports für SID-WOODY.
Das sind Pakete die alles andere als unsicher sind...
Nun lass den $USER auf die idee kommen, das man ja nen apache und
weis der Linuxgott was noch alles laufen lassen könnte...
Und schluß ist es mit der sicherheit...
(eigene erfahrung hier in Strasbourg, - feste IP oder ADSL-flat
und dann services über napster, kazza und amule anbieten...)
Security-Announce-MLs haben zudem meist sehr geringen Traffic. Gibt es
solche nicht, wäre es zum Beispiel eine Möglichkeit, einfach im Browser
einen Bookmark-Ordner zu den Sicherheitsseiten oder Homepages der
entsprechenden Programme anzulegen und etwa einmal wöchentlich kurz alle
Seiten ('Open in tabs') durchzusehen. Der Aufwand dazu dürfte deutlich
unter 5 Minuten liegen.
Ist sowieso allen zu empfehlen...
Es gibt des Weiteren speziell für Debian ein hervorragendes HOWTO, das
beschreibt, wie man ein System möglichst gut absichert, siehe
http://www.debian.org/doc/manuals/securing-debian-howto/
Das lesen doch sowieso nur die wenigsten... :-/
oder das Paket harden-doc.
Die Antworten hier, bringen mich zur Erkenntnis, dass Sid wohl doch
nicht das Non-Plus-Ultra ist.
Was ist schon perfekt? Ein sicherheitsbewusster Anwender (wie Du) ist in
vielen Szenarien alleine schon enorm hilfreich. Wenn er dann noch über
ein vernünftiges Maß Admin-Knowhow verfügt und
Re: Das Problem mit SID
Hallo! On 31 May 2004 at 11:18 +0200, Peter Kuechler wrote: Am Sonntag, 30. Mai 2004 22:04 schrieb Andreas Pakulat: Ja und bei Sid musst du selber Patchen oder hoffen das der Maintainer nicht schlaeft und nen fix bereitstellt... Du scheinst keine besonders hohe Meinung über die Entwickler zu haben... Es liegt schon in ihrem eigenen Interesse, solche Sicherheitslöcher in ihrem aktuellen Code zu stopfen, findest Du nicht? Ich glaube, dass Andreas eher Folgendes gemeint hat: Es ist (z.B. wegen Krankheit, Urlaub, ...) möglich, dass der Zeitpunkt, zu dem in sid gefixte Pakete auftauchen, deutlich hinter dem Veröffentlichungszeitpunkt der Fixes durch die Upstream-Autoren liegt. Und das ist ein Fall, den man durchaus berücksichtigen muss. Zum Beispiel, indem man (wo ihr beide euch wohl einig seid) bei Bedarf die betroffenen Pakete selbst aktualisiert. Es muß doch jedem einleuchten, das an einen Rechner, der Dienste ins Internet zur Verfügung stellt, ander Anforderungen gestellt werden wie an einen Rechner, der solchen Gefahren nicht direkt ausgesetzt ist. Daraus ergibt sich in der Tat eine deutlich geringere Gefährdung. Trotzdem ist natürlich im Auge zu behalten, dass potenziell jede Anwendung, die Daten aus nicht unter deiner Kontrolle liegenden Quellen verarbeitet, ein Einsprungpunkt für den Angreifer sein kann. Und sei es, indem er speziell präpariert E-Mails schickt, an denen sich der MUA auf den Clientrechnern verschluckt. Das alles hat nun aber mit der Wahl unstable/stable nur wenig zu tun. Bei stable hat man den Vorteil, dass das Security-Team in der Regel sehr prompt kompetent gefixte Pakete verteilt. Bei unstable gibt es diesen Service halt nicht, da muss man eben selbst ein Auge auf kritische Anwendungen haben und im Einzelfall entscheiden, ob man noch auf das neue sid-Paket warten kann oder dringend selbst Hand anlegen muss. Gruß, Elmar -- [ GnuPG: D8A88C0D / 2407 063C 1C92 90E9 4766 B170 5E95 0D7F D8A8 8C0D ] ··· An apple a day makes 365 apples a year. pgprLjGBurG0a.pgp Description: PGP signature
Re: Das Problem mit SID
Am 2004-05-31 11:18:03, schrieb Peter Kuechler: Am Sonntag, 30. Mai 2004 22:04 schrieb Andreas Pakulat: Ja und bei Sid musst du selber Patchen oder hoffen das der Maintainer nicht schlaeft und nen fix bereitstellt... Du scheinst keine besonders hohe Meinung über die Entwickler zu haben... Es liegt schon in ihrem eigenen Interesse, solche Sicherheitslöcher in ihrem aktuellen Code zu stopfen, findest Du nicht? Ist aber in vielen fällen nicht so... ...und teilweise sind sie hoffnungslos überlastet ! Und, oh Wunder, tauchen neue Versionen der Software in SID am ehesten auf. Richtig, mit neuen Bugs... Die beissen sich an meinem Paketfilter die Zähne aus:-) Deswegen haben Hacker es trotzdem geschaft meinen pppd zu crashen... Was ist wenn der nen Fehler hat? Der Paketfilter hat weder was mit SID, Woody, Suse oder sonst was zu tun. Er ist Sache des Kernels, und da bediene ich mich schon seit Jahren nur der Vanilla-Kernel. Dort passt wenigstens jeder Patch. Stimmt auch nicht... eigene Erfahrung. Du kannst nicht beliebig patchen. Ich schliesse mal daraus dass du diese Dienste fuers Internet freigegeben hast? Falsch, alle Dienste gehen nur ins interne Netz. Ich würde mir sehr gut überlegen, ob ich auf einem Rechner, der _auch_ als Firewall dient, Dienste für den Zugriff von aussen zur Verfügung stelle:- Davon war vorher nicht die rede... Aber abgesehen davon hast Du nen FileServer auf einem Rechner, der Direkten Internet Zugang hat... Alleine das schon ist ein Risiko. Was ist wenn einer davon ein Sicherheitsloch hat und der Maintainer grad 4 Wochen in Urlaub? Interessiert mich aus o.g. Grund nicht, muß es ja auch nicht;-) Für die Installation ? Ein Loch im Soucecodes des Firewalls und dein Server war einmal... Machst du wirklich nur alle paar Monate ein Upgrade? Na dann lass mal lieber niemanden der boeswillig ist deine IP rauskriegen.. s.o. Das ist naiv ! Ok, noch mal zur Erklärung: Wenn ich einen Rechner habe, der als nur als Paketfilter dienen soll, dann kann es mir scheißegal sein, ob der apache in SID gerade ein Sicherheitsloch hat. Wieso ? - Gerade hier ist es notwendig, das 100% sichere Software eingesetzt wird und nicht irgendwas aus dem Developper stream... Ich kenne KEINEN, der mit seinem Arbeitsplatzrechner, den er jeden Tag nach der Arbeit für 2 Stunden einschaltet, Dienste im Internet zur Verfügug stellt. Somit reicht ein Paketfilter, der KEINEN Verbindungsaufbau von aussen zulässt, aus. Also ich kenne jede menge die 'amule' und 'xmule' einsetzen, was genau diese Gefahr ist... FileSharing... Und nicht nur das, fast alle die ich kenne haben einen Webserver laufen. Das ganze mit DynDNS... Das sind typischen Windows-User !!! Einfach sorglos... hauptsache 'apt-get' funktioniert... Habe mal einen Portscan auf :80 im ADSL-Pool bei Wanadoo.fr gemacht... Da findeste hunderte von Apache Index.html...Habe dann versuch mit einem Bash-Script die ~$USER herauszufinden... :-) Da findest Du ewig viele... Du glaubst das geht nicht ? Selbst wenn der $USER sich auslogt und ich einen neuen Scan mache, finde ich den $USER wieder. anhand von den Einstellungen des apache... Nämlich dem Hostnamen des Rechners... Wenn ich einen Rechner ins Internet stellen muß, dann steht er in einer DMZ, Wieviele Desktop $User machen das ? und es laufen nur die Programme darauf, die für diesen einen Dienst gebraucht werden. Hier kann man sicher nochmal neu überlegen, was man einsetzt. SID, Woody, Suse oder sogar BSD, wie es Dieter in einer Mail geschrieben hat. Das har aber nichts mehr mit dem gemeinen Desktop $USER zu tun. Fazit: Du suggerierst Linux-Anfängern SID zu installieren ohne auf die Gefahren aufmerksam zu machen... KEIN Linux-Anfänger kann ein UNSTABLE System dicht machen ! Erwarte nicht von einem Windows-Linux umsteiger das er ein paar dutzend Mbytes (!!!) HOWTOS und Dokumentation ließt. Das tun die NUR, wenn Du als erfahrener Linux-Anwender daneben sitzt und ihnen 100% Hilfestellung leistets... Wie schon erwähnt, arbeite ich an einem arabic/farsi-Linux Project und MEINE $USER lesen HOWTOS, man und info... Warum ? - weil ich ihnen schon bei der installation die Bedeutung einzelner Schritte erklärt habe... Genaugenommen, ich bilde arabische/persische Frauen an Linux aus. Diese Frauen haben teilweise noch nie mit einem Computer gearbeitet und kenne die Gefahren des Internet nicht. Die Ausbildung har den zweck, das Frauen (islamische Welt) sogenannte Tele-Travail (Arbeit von zu Hause aus) machen können. Diese Frauen müssen in der Lage sein, alleine Linux zu installieren und zu administrieren... Das was ich denen in rund 2-9 Monaten beibringe, kann kein normaler Desktop $USER... (die finden noch nicht einmal die Doku) mfg Peter Küchler Greetings Michelle
Re: Das Problem mit SID
Am Montag, 31. Mai 2004 12:49 schrieb Michelle Konzack: Am 2004-05-31 11:18:03, schrieb Peter Kuechler: Am Sonntag, 30. Mai 2004 22:04 schrieb Andreas Pakulat: Ja und bei Sid musst du selber Patchen oder hoffen das der Maintainer nicht schlaeft und nen fix bereitstellt... Du scheinst keine besonders hohe Meinung über die Entwickler zu haben... Es liegt schon in ihrem eigenen Interesse, solche Sicherheitslöcher in ihrem aktuellen Code zu stopfen, findest Du nicht? Ist aber in vielen fällen nicht so... ...und teilweise sind sie hoffnungslos überlastet ! Und, oh Wunder, tauchen neue Versionen der Software in SID am ehesten auf. Richtig, mit neuen Bugs... Jetzt mach die Sache nicht schlimmer als sie ist. Nochmal: Bugs gibt es immer, das liegt in der Natur der Sache. Die beissen sich an meinem Paketfilter die Zähne aus:-) Deswegen haben Hacker es trotzdem geschaft meinen pppd zu crashen... Was ist wenn der nen Fehler hat? Der Paketfilter hat weder was mit SID, Woody, Suse oder sonst was zu tun. Er ist Sache des Kernels, und da bediene ich mich schon seit Jahren nur der Vanilla-Kernel. Dort passt wenigstens jeder Patch. Stimmt auch nicht... eigene Erfahrung. Du kannst nicht beliebig patchen. Mag sein, das Du die Erfahrung gemacht hast. Ich habe bis jetzt mit Vanilla-Kerneln die besten Erfahrungen gemacht. Ich schliesse mal daraus dass du diese Dienste fuers Internet freigegeben hast? Falsch, alle Dienste gehen nur ins interne Netz. Ich würde mir sehr gut überlegen, ob ich auf einem Rechner, der _auch_ als Firewall dient, Dienste für den Zugriff von aussen zur Verfügung stelle:- Davon war vorher nicht die rede... Richtig. Es wird immer nur sehr pauschal davon gesprochen, wie unsicher und gefährlich SID ist. Ich habe mal angefangen, das ein wenig zu differenzieren. Aber abgesehen davon hast Du nen FileServer auf einem Rechner, der Direkten Internet Zugang hat... Alleine das schon ist ein Risiko. Wie ich schon geschrieben habe: Auf diesen Server werden keinerlei Verbindungen von außen zugelassen. Was ist wenn einer davon ein Sicherheitsloch hat und der Maintainer grad 4 Wochen in Urlaub? Interessiert mich aus o.g. Grund nicht, muß es ja auch nicht;-) Für die Installation ? Ein Loch im Soucecodes des Firewalls und dein Server war einmal... Also nochmal: Der Sourcecode besteht in meinem Fall aus Kernelcode. Und da bin ich sehr flexibel, was Updates, Patches usw. angeht. Es werden KEINE Dienste nach außen zur Verfügung gestellt, der Rechner ist nach Haussen Tot. Aber vielleicht kannst Du ja versuchen, den Treiber für die Netzwerkkarte anzugreifen:-) Machst du wirklich nur alle paar Monate ein Upgrade? Na dann lass mal lieber niemanden der boeswillig ist deine IP rauskriegen.. Und nochmal (irgend wann wird es schon durchdringen): Es werden KEINE Dienste nach Haussen zur Verfügung gestellt, der Rechner ist nach Haussen Tot. Warum soll ich Dienste updaten, die ich nicht einsetze? Das ist naiv ! Quatsch. Ok, noch mal zur Erklärung: Wenn ich einen Rechner habe, der als nur als Paketfilter dienen soll, dann kann es mir scheißegal sein, ob der apache in SID gerade ein Sicherheitsloch hat. Wieso ? - Gerade hier ist es notwendig, das 100% sichere Software eingesetzt wird und nicht irgendwas aus dem Developper stream... Sag mal, liest Du eigentlich mal bevor Du schreibst? Wenn ich KEINEN Apache einsetze, dann kann es mir scheiegal sein, ob apache ein Sicherheitsloch hat und wie groß es ist!! Und ich weiß nicht wie es bei Dir ist, aber mein Linux-Paketfilter arbeitet mit Kernelmodulen, und die wiederum haben einen sch*reck mit debian SID/Woody Suse oder sonst was zu tun. Punkt. Ich kenne KEINEN, der mit seinem Arbeitsplatzrechner, den er jeden Tag nach der Arbeit für 2 Stunden einschaltet, Dienste im Internet zur Verfügug stellt. Somit reicht ein Paketfilter, der KEINEN Verbindungsaufbau von aussen zulässt, aus. Also ich kenne jede menge die 'amule' und 'xmule' einsetzen, was genau diese Gefahr ist... FileSharing... Na fein, dann sollen sie sich um Ihren Kram kümmern. Und nicht nur das, fast alle die ich kenne haben einen Webserver laufen. Das ganze mit DynDNS... [...] Wenn ich einen Rechner ins Internet stellen muß, dann steht er in einer DMZ, Wieviele Desktop $User machen das ? Wahrscheinlich wenige. Und wie viel glaubst du machen mit Woody regelmässig Sicherheitsupdates? Sehr richtig, genau so wenige. Und damit sind sie genau so nass wie mit SID oder Sarge auch. und es laufen nur die Programme darauf, die für diesen einen Dienst gebraucht werden. Hier kann man sicher nochmal neu überlegen, was man einsetzt. SID, Woody, Suse oder sogar BSD, wie es Dieter in einer Mail geschrieben hat. Das har aber nichts mehr mit dem gemeinen Desktop $USER zu tun. Das ist richtig. Fazit:Du suggerierst Linux-Anfängern SID zu installieren ohne auf die Gefahren
Re: Das Problem mit SID
On 31.May 2004 - 11:18:03, Peter Kuechler wrote: Am Sonntag, 30. Mai 2004 22:04 schrieb Andreas Pakulat: On 30.May 2004 - 20:11:52, Peter Kuechler wrote: Am Sonntag, 30. Mai 2004 18:05 schrieb Michelle Konzack: Am 2004-05-30 10:13:27, schrieb Peter Kuechler: Ja und bei Sid musst du selber Patchen oder hoffen das der Maintainer nicht schlaeft und nen fix bereitstellt... Du scheinst keine besonders hohe Meinung über die Entwickler zu haben... Es liegt schon in ihrem eigenen Interesse, solche Sicherheitslöcher in ihrem aktuellen Code zu stopfen, findest Du nicht? Es ging mir nicht darum das sie absichtlich/aus Faulheit irgendwelche Fixes nicht einspielen... Das schlaeft ist ungluecklich gewaehlt. Aber es gibt auch andere Faktoren, z.B. nicht ausreichend Zeit, Urlaub, Krankheit und es soll auch schon DM gegeben haben die klammheimlich verschwunden sind. Übrigens habe ich nicht meine Arbeitsplatzrechner am Internet, sondern meinen Fileserver/DNS/Timeserver/DHCP/Mailserver/Einwahlrechnen für Fernwartung. Naja und Firewall für meinen DSL-Zugang ist er auch noch. Ich schliesse mal daraus dass du diese Dienste fuers Internet freigegeben hast? Falsch, alle Dienste gehen nur ins interne Netz. Also hab ich dich falsch verstanden, das aendert natuerlich die Sachlage. Ich habe den Eindruck, das hier alles über einen Kamm geschoren wird. Es muß doch jedem einleuchten, das an einen Rechner, der Dienste ins Internet zur Verfügung stellt, ander Anforderungen gestellt werden wie an einen Rechner, der solchen Gefahren nicht direkt ausgesetzt ist. ACK. Oder nochmal deutlicher: Wenn ich einen Rechner habe, der als nur als Paketfilter dienen soll, dann kann es mir scheißegal sein, ob der apache in SID gerade ein Sicherheitsloch hat. Jupp. Aber wie siehts mit syslog, init und Konsorten aus... Ist ja nicht nur der Apache aus Sid... Ich kenne KEINEN, der mit seinem Arbeitsplatzrechner, den er jeden Tag nach der Arbeit für 2 Stunden einschaltet, Dienste im Internet zur Verfügug stellt. Somit reicht ein Paketfilter, der KEINEN Verbindungsaufbau von aussen zulässt, aus. Ich schon :-) Mich naemlich... Aber auch ich habe eine Firewall davor. Andererseits laeuft das Ding nicht nur 2 Stunden sondern die ganze Nacht. Ok, also sind wir uns ja doch einig :-) Auf Arbeitsplatzrechnern/in kontrollierten Umgebungen ist SID durchaus eine Wahl die man treffen kann. Andreas -- Everybody wants to go to heaven, but nobody wants to die. -- 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)
Re: Das Problem mit SID
Am 2004-05-31 10:03:32, schrieb Andreas Pakulat: On 31.May 2004 - 11:18:03, Peter Kuechler wrote: Aber es gibt auch andere Faktoren, z.B. nicht ausreichend Zeit, Urlaub, Krankheit und es soll auch schon DM gegeben haben die klammheimlich verschwunden sind. Ich weis von 5 Debian Maintaineren die in den lezten zwei Jahren einfach verschwunden sind... Die Pakete haben Bugs von 3 Jahren und älter und es gibt keine NMU Wenn ich einen Rechner habe, der als nur als Paketfilter dienen soll, dann kann es mir scheißegal sein, ob der apache in SID gerade ein Sicherheitsloch hat. Jupp. Aber wie siehts mit syslog, init und Konsorten aus... Ist ja nicht nur der Apache aus Sid... Ich denke, das es jede menge angriffsfläche gibt, auf wenn zum Internet hin alles dicht scheint... Ich schon :-) Mich naemlich... Aber auch ich habe eine Firewall davor. Andererseits laeuft das Ding nicht nur 2 Stunden sondern die ganze Nacht. Da bist Du nicht der einzige... USB-Modem - Linux-Box(pppoe) - NETBuilder II - hardwarefirewall - privates netzwerk (Rechner mit SLINK über POTATO und WOODY bis SID) Ok, also sind wir uns ja doch einig :-) Auf Arbeitsplatzrechnern/in kontrollierten Umgebungen ist SID durchaus eine Wahl die man treffen kann. Bin jedenfals mit SARGE/SID nicht zufrieden... Andreas Greetings Michelle -- Linux-User #280138 with the Linux Counter, http://counter.li.org/ Michelle Konzack Apt. 917 ICQ #328449886 50, rue de Soultz MSM LinuxMichi 0033/3/8845235667100 Strasbourg/France IRC #Debian (irc.icq.com) signature.pgp Description: Digital signature
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
Re: Das Problem mit SID
On 31.May 2004 - 22:47:40, Christian Schulte wrote: Michelle Konzack wrote: 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. www.backports.org mehr sage ich dazu jetzt mal nicht. 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 ... oder unstable. Von meinem Woody bleibt also nicht mehr viel übrig dabei. Nichtmal die libc6. Genau, du hast dann naemlich kein Woody mehr sondern ein testing/unstable Mischsystem. Damit kommen auch die daran angeknuepften Probleme.. 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! Du hast aber wesentlich mehr Aufwand als mit Woody, da du in Woody nicht fuer jedes Paket eine security ML lesen musst. Und wie schon gesagt, es passiert immer mal das DM's verschwinden/krank werden/in Urlaub fahren... 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 ? Kannst du ja im Fall der Faelle nicht. ;-) Ich meine nicht das die DM's schlampig arbeiten, aber in dem Fall wo du ein Update fuer ein Paket unbedingt brauchst, ist der DM garantiert grad nicht da/hat keine Zeit. 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 ? www.backports.org, ist kein Debian Spiegel aber der Maintainer ist auch DM. 3. Wer macht das ähnlich und würde davon mitlerweile abraten ? Also z.B. angesichts der aktuellen gnutls10 Transition wuerde ich davon abraten obwohl ich das nie so gemacht habe... meinem Fall jetzt aber eigendlich genau testing bzw. zu einem kleinen Teil unstable! Warum dann also die nicht auch benutzen ? Wenn du deine Updates hauptsaechlich aus Testing holst: Wie lange willst du auf security fixes eigentlich warten? Die meisten Pakete in testing sind 10 Tage aelter als die in unstable - wenn nicht noch mehr... 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 ? Auf Desktops/Entwicklungsmaschinen ist doch ncihts gegen testing/unstable einzuwenden. Es ging aber um Server mit denen Geld verdient werden soll. 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 ? Jupp, kann man IMHO, wenn der Maintainer Zeit hat und nicht grad andere Dinge das Update verhindern (siehe aktuell die gnutls10 Transition) Andreas -- You are sick, twisted and perverted. I like that in a person. -- 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)
Re: Das Problem mit SID
Andreas Pakulat wrote: 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. www.backports.org mehr sage ich dazu jetzt mal nicht. Introduction You are running Debian stable, because you prefer the stable Debian tree. It runs great, there is just one problem: the software is a little bit outdated compared to other distributions. That is where backports come in. Gut wenn man es kennt! Danke. 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 ... oder unstable. Von meinem Woody bleibt also nicht mehr viel übrig dabei. Nichtmal die libc6. Genau, du hast dann naemlich kein Woody mehr sondern ein testing/unstable Mischsystem. Damit kommen auch die daran angeknuepften Probleme.. Nur das ich eigendlich gar keine Probleme habe...wo ich welche haben sollte. 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! Du hast aber wesentlich mehr Aufwand als mit Woody, da du in Woody nicht fuer jedes Paket eine security ML lesen musst. Und wie schon gesagt, es passiert immer mal das DM's verschwinden/krank werden/in Urlaub fahren... Das ist aber dann doch kein Problem mit testing oder unstable sondern ein Problem was Du generell hast, wenn Du Dich auf andere verlässt! 1. Was ist an meinem Vorgehen unsicherer, wenn ich mich auf die Maintainer verlassen kann ? Kannst du ja im Fall der Faelle nicht. ;-) Ich meine nicht das die DM's schlampig arbeiten, aber in dem Fall wo du ein Update fuer ein Paket unbedingt brauchst, ist der DM garantiert grad nicht da/hat keine Zeit. Kann passieren, ist mir aber bisher nicht passiert. Besteht das Security-Team denn eigendlich nicht auch aus Maintainern ? Wo ist der Unterschied bei backports.org ? 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 ? www.backports.org, ist kein Debian Spiegel aber der Maintainer ist auch DM. ...und wenn der krank wird ? If you find a bug in one of these packages, be carefully when using the official Debian bugtracking system. Some maintainers don't like it when bugs are reported against unofficial packages. I suggest you to contact the person who has build the backport. Check changelog.Debian.gz to find out who is responsible for a backport. Eigendlich kein Unterschied zu unstable. Nur dass ich bei unstable reportbug nutzen kann und soll! Wenn du deine Updates hauptsaechlich aus Testing holst: Wie lange willst du auf security fixes eigentlich warten? Die meisten Pakete in testing sind 10 Tage aelter als die in unstable - wenn nicht noch mehr... Das ist ne gute Frage! Ich habe tatsächlich überlegt testing komplett nicht zu benutzen und alles was ich derzeit aus testing benutze aus unstable zu holen. Bevor ich das aber mache, gucke ich mir jetzt dann doch backports.org nochmal genauer an. Bisher habe ich aber nicht das Gefühl, dass die Pakete von dort sicherer sind, als die aus unstable. Gibt es bei backports.org auch ein Security-Team ? Ist backports.org also ein vollständiger Woody-Ersatz mit aktuelleren Paketen aus testing/unstable ? Mit allen Vorteilen, die Woody ja definitiv hat. Oder besser: Woody hat nur den einen Nachteil, dass die Software teilweise ziemlich outdated ist und dieser Nachteil ist bei backports.org nicht vorhanden ? Ist backports.org also eine vollständig eigene Distribution eigendlich ? Was können die dann, was Debian nicht auch selber könnte ? Also ich nehme mir die Debian testing Distribution, baue alle Pakete so neu, dass sie komnpatibel mit Woody werden und nenne das dann backports.org und mache eigendlich dasselbe, was in testing auch passiert ? Ein vorgezogenes apt-get dist-upgrade quasi ? Auf Desktops/Entwicklungsmaschinen ist doch ncihts gegen testing/unstable einzuwenden. Es ging aber um Server mit denen Geld verdient werden soll. allerdings! 6. Was ist daran unsicherer den Apache aus Woody
Re: Das Problem mit SID
Christian Schulte wrote: Aber das ist doch eben kein einzelnes Problem mit testing oder unstable. Also bei Woody kann ich mich dann darauf verlassen, dass Security-Updates genau dieses Problem nicht haben ? Bei backports.org besteht hier auch ein Unterschied zu unstable ? Ich sehe derzeit den Vorteil von backports.org nicht bis auf dass ich nachher nicht 60% testing Pakete im System habe, sondern 60% Pakete von backports.org. Ok. Die libc6 würde sich nicht ändern und sowas. Das wäre schon ein Vorteil! Gucke ich mir definitv noch genau an, was das für mein System nun genau heissen würde. Schön das man downgraden kann... Ah jetzt ja! Ich kann mit backports.org gezielt eine neuere Version einspielen ohne zig Abhängigkeiten aus testing/unstable mitinstallieren zu müssen... -- Christian
Re: Das Problem mit SID
Am 2004-05-31 22:47:40, schrieb Christian Schulte: Michelle Konzack wrote: Bin jedenfals mit SARGE/SID nicht zufrieden... Greetings Michelle Hallo, ich kann das hier alles irgendwie nicht mehr richtig nachvollziehen. Wieso ? - Die Diskusion betrifft ja ein 100% SARGE/SID. s.u. Hier mal ein Beispiel: Ich verwende auf einem Server Woody. Dummerweise sind im Woody jetzt Ich auch... 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 'spamassassin' 2.63 und 'f-prot' habe ich auch... Ersterer ist bereits masiv getestet und läuft perfect. Zweiterer is closed Source und Du hast keine andere Wahl... cyrus-imapd selber, da ich das virtual-domain-feature benötige und es Ich habe 'samba' und 'postgresql' als Backports laufen... Pach und mache sie selber als Debian-Paket. Quellpakete einzuspielen und dpkg-buildpackage durchzuführen. Selbst da das ist Richtig... mache schon eine ganze Weile einige AUSGESUCHTE Backports... 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 Stimmt nicht, nur teilweise, denn die Sourcen aus SID sind meistens mit denen der UPSTREAM identisch... 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 Wie bei mir zu 80% konfiguriere ich apt so, dass es als default-release auf stable bleibt, und packe in die sources.list noch testing und unstable mit rein. Ich habe deb file:/home/ftp/debian compiled main deb ftp://ftp.de.debian.org/debian woody main deb ftp://ftp.de.debian.org/debian sid main deb-src ftp://ftp.de.debian.org/debian sid main Default Release ist WOODY 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. Das ist richtig... 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. 1) Wenn ich was installieren will was in SID ist, schau ich mir das mit apt-get erst mal an... 2) Mach mit dem gleichen Packet ein 'apt-get build-dep' 3) Sollten Pakete auftauchen, die es in woody nicht gibt, werden sie ebenfals gebastelt. 4) Nun ein 'apt-get source' auf das gewünschte Packet 5) control und Changelog geändert... 6) dpkg-buildpackage Und schon habe ich win WOODYsiertes Packet. Niemand stellt ein Paket in Debian bereit, dass er nicht auch pflegt und bei entsprechenden Problemen updatet. Jetzt lese ich hier zwar das Das ist Richtig... Bastele pro Woche auch ein paar Packete... 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! Ist mir auch schon passiert... Norbert zum Beispiel war manchmal einen Tag langsamer... Allerdings gehen wie hier von Servern aus ! Bei den Desktop-Paketen ist das nicht der Fall... ...und daran wird es dann wieder happern ! 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 Nicht alle Maintainer verwenden 'dh_md5sums' in der rules 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. Ich mache eigentlich einen md5sums Test direkt nach der Installation... 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 ? Naja, ich habe die Erfahrung gemacht, das gewisse Upstreams und Maintainer sehr schnell reagieren, besonderst was den Serberbereich betrifft... 2. Wie kann ich es hinbekommen komplett bei Woody zu bleiben, ohne die fehlende Software selber zu bauen, und ohne irgendwelche fremden Pakete
Re: Das Problem mit SID
Halle Christion, (meine lezte Mail für Heute...) Am 2004-05-31 23:45:08, schrieb Christian Schulte: Andreas Pakulat wrote: www.backports.org mehr sage ich dazu jetzt mal nicht. Gut wenn man es kennt! Danke. Der Server ist zu empfehlen... Das ist aber dann doch kein Problem mit testing oder unstable sondern ein Problem was Du generell hast, wenn Du Dich auf andere verlässt! Das ist richtig... Kann passieren, ist mir aber bisher nicht passiert. Besteht das Security-Team denn eigendlich nicht auch aus Maintainern ? Wo ist der Unterschied bei backports.org ? www.backports.org ist eine Person: Norbert Tretkowski Backports liefert lediglich ein paar ausgewählte pakete aus SID nach WOODY mit entsprechend angepaßten Abhängigkeiten wie der libc6 2.2.5 zum Beispiel www.backports.org, ist kein Debian Spiegel aber der Maintainer ist auch DM. ...und wenn der krank wird ? Da gibt es soviel ich weis eine Vertretung... Norbert erwähnte das mal... Eigendlich kein Unterschied zu unstable. Nur dass ich bei unstable Genau, Backports ist UNSTABLE ! reportbug nutzen kann und soll! Das ist richtig. unstable zu holen. Bevor ich das aber mache, gucke ich mir jetzt dann doch backports.org nochmal genauer an. Bisher habe ich aber nicht das Gefühl, dass die Pakete von dort sicherer sind, als die aus unstable. Es sind die selbigen, nur bleibt das Basissystem 100% STABLE. Allerdings gibt es auch Backports die unglaublich Stabil laufen und Sicher sind. Das muß aber jeder selber entscheiden. Gibt es bei backports.org auch ein Security-Team ? Ist backports.org Nein, Norbert packt nur AUSGEWÄHLTE Pakete aus UNSTABLE für WOODY ab... Wenn Du einen Wunsch hast, kannste ihn ja Fragen ober er Dir sie nicht macht... Denke nicht, das er jemanden auffreßen wird, wenn ein Wunsch geäußert wird. Es muß halt in Rahme des möglichen sein. Backports machen braucht auch seine Zeit... Teilweise ist man schon ein Paar Stunden beschäftigt um irgendwechen Abhängigkeiten loszuwerden also ein vollständiger Woody-Ersatz mit aktuelleren Paketen aus testing/unstable ? Mit allen Vorteilen, die Woody ja definitiv hat. Oder Nein, WOODY brauchste ! Backports sind NUR zusätzlich... besser: Woody hat nur den einen Nachteil, dass die Software teilweise ziemlich outdated ist und dieser Nachteil ist bei backports.org nicht vorhanden ? Ist backports.org also eine vollständig eigene Distribution eigendlich ? Was können die dann, was Debian nicht auch selber könnte ? Nein, nur ausgewählte Pakete die in WOODY passen. Also ich nehme mir die Debian testing Distribution, baue alle Pakete so neu, dass sie komnpatibel mit Woody werden und nenne das dann backports.org und mache eigendlich dasselbe, was in testing auch passiert ? Ein vorgezogenes apt-get dist-upgrade quasi ? Basis soll ja ein Stabiles und Ausgereiftes basissystem sein, für das es innerhalb Stunden Security-Fixes gibt. Das kann NUR das STABLE Security-Team. Alles andere ist Entscheidung/Erfahrung des Administrators und $USER. Er muß ebend abwägen, ober er auf seinem System ein bestimmtes aket aus Backports/UNSTABLE installieren will oder mit einer alten STABLE-Version es versuchen will. Auf Desktops/Entwicklungsmaschinen ist doch ncihts gegen testing/unstable einzuwenden. Es ging aber um Server mit denen Geld verdient werden soll. allerdings! Meine Server sind alle STABLE, mir AUSGEWÄHLTEN UNSTABLE Backports Aber das ist doch eben kein einzelnes Problem mit testing oder unstable. Also bei Woody kann ich mich dann darauf verlassen, dass Security-Updates genau dieses Problem nicht haben ? Bei backports.org Ja besteht hier auch ein Unterschied zu unstable ? Ich sehe derzeit den Vorteil von backports.org nicht bis auf dass ich nachher nicht 60% Backports sind Pakete die von z.B. libc6 v2.3.4 zurück auf v2.2.5 geportet wurden, damuit sie ebend auf einem STABLE Basissystem laufen können testing Pakete im System habe, sondern 60% Pakete von backports.org. Ok. Du wirst warscheinlich weniger als 20% UNSTABLE haben, denn viele Abhängigkeiten werden durch Pakete ind Backports gelößt indem sie Abhängigkeitspakete aus STABLE verwenden. Backports zieht als nicht einen Rattenschwanz von Abhängigkeiten hinterher. Die libc6 würde sich nicht ändern und sowas. Das wäre schon ein Vorteil! Das ist der Vorteil von backporst, den die UNSTABLE Pakete sind alle mit der 2.2.5 aus STABLE kompiliert. Gucke ich mir definitv noch genau an, was das für mein System nun genau heissen würde. Schön das man downgraden kann... Christian Greetings Michelle -- Linux-User #280138 with the Linux Counter, http://counter.li.org/ Michelle Konzack Apt. 917 ICQ #328449886 50, rue de Soultz MSM LinuxMichi 0033/3/8845235667100 Strasbourg/France IRC #Debian (irc.icq.com) signature.pgp Description: Digital signature
Re: Das Problem mit SID
Michelle Konzack wrote: Backports liefert lediglich ein paar ausgewählte pakete aus SID nach WOODY mit entsprechend angepaßten Abhängigkeiten wie der libc6 2.2.5 zum Beispiel Und zufällig sind genau die dabei, die es bisher verhindert haben, dass ich meine Software unter Woody kompilieren konnte. Perfekt! Basis soll ja ein Stabiles und Ausgereiftes basissystem sein, für das es innerhalb Stunden Security-Fixes gibt. Das kann NUR das STABLE Security-Team. Alles andere ist Entscheidung/Erfahrung des Administrators und $USER. Er muß ebend abwägen, ober er auf seinem System ein bestimmtes aket aus Backports/UNSTABLE installieren will oder mit einer alten STABLE-Version es versuchen will. Ok. Meine Server sind alle STABLE, mir AUSGEWÄHLTEN UNSTABLE Backports So hätte ich das bisher auch gerne gemacht, aber ich kannte backports.org halt nicht und war viel zu faul, jetzt gleich 20-30 Pakete alle selber zu bauen. Du wirst warscheinlich weniger als 20% UNSTABLE haben, denn viele Abhängigkeiten werden durch Pakete ind Backports gelößt indem sie Abhängigkeitspakete aus STABLE verwenden. Backports zieht als nicht einen Rattenschwanz von Abhängigkeiten hinterher. Mir ist da gerade ein Licht aufgegangen quasi. Ich habe jetzt mal unter einer VM ein komplett nacktes Woody installiert um nochmal zu klären, wieso ich eigendlich seiner Zeit so viele Pakete aus Testing bzw. Unstable installiert habe. Ich habe es unter diesem Woody mit Hilfe von genau 2 Paketen von backports.org geschafft, sämtliche anderen Pakete selber unter Woody zu bauen (dpkg-buildpackage). Hier und da musste ich dafür zwar im control-File ein paar Abhängigkeiten downgraden aber alles in allem habe ich jetzt alle Pakete woody-kompatibel (sendmail, mailscanner, unzip, etc.). Jetzt stellt sich mir noch genau eine Frage. Wie organisiere ich jetzt am besten meine lokalen Pakete ? Ich habe jetzt in meinem Homeverzeichniss einfach immer apt-get --default-release=unstable source paket eingegeben und dann im entsprechenden Verzeichniss, nachdem ich im control-File einige Dinge geändert hatte fakeroot dpkg-buildpackage Soweit so gut. Was ich gerne hätte wäre aber, dass ich apt-get update/upgrade eingebe, und dann auch immer die aktuellen Quellen bekomme. Wie kann man das am besten lösen ? Ich habe da etwas von apt-src oder apt-build gelesen, bin mir aber nicht sicher, wie man das jetzt am besten macht. Irgendwelche Howtos oder ähnliches ? Ich kann so erstmal damit leben an die 10 Pakete alle selber zu übersetzen. Aber ohne automatisch immer die aktuellesten Quellen aus Unstable zu bekommen, machts wieder weniger Sinn. -- Christian
Re: Das Problem mit SID
Am Sonntag, 30. Mai 2004 01:25 schrieb Heino Tiedemann: Werner Gast [EMAIL PROTECTED] wrote: Am Sam, 2004-05-29 um 16.25 schrieb Maurice: PS: Ich beziehe mich auf einen Desktop-PC. Bei einem Server kann ich mir vorstellen, dass man wohl lieber nur ausgiebig getestete Software verwenden will. So ist es. Sid ist gut fuer den neuen, privaten Desktop. Für Server und Arbeitsplatzrechner ist aber woody die richtige Wahl. Ein innovatives Sid auf den Rechnern von Sachbearbeitern wuerde den Helpdesk im Unternehmen total ueberfordern. Der Arbeitsplatzrechner muss moeglichst lange genau so laufen, wie bei der Einweisung/Schulung vermittelt. Das haelt die Kosten im Unternehmen niedrig und reduziert den Supportaufwand. Ein sid, das man seit dem Tag der Einführung nicht mehr verändert böte das auch ;-) *Duck und wech* Warum denn? Du hast doch recht. Ich hatte noch nie beser laufende Rechner wie die mit Debian SID. -- mfg Peter Küchler
Re: Das Problem mit SID
Elmar W. Tischhauser [EMAIL PROTECTED] wrote: On 29 May 2004 at 16:25 +0200, Maurice wrote: Updaten tue ich nur hin und wieder einzelne Pakete, die auf debian-security-announce gemeldet werden. Vorsicht! DSAs gibt es nur für Woody-Probleme. Wenn also ein bei dir installiertes Paket ein nur in neueren Versionen auftretendes sicherheitsrelevantes Problem hat, gibt es kein DSA, was dich darauf aufmerksam machen würde. Oh, gut zu wissen. Habe ich gar nicht dran gedacht. Es ist für den sicherheitsbewussten unstable-Nutzer also keinesfalls hinreichend, nur [EMAIL PROTECTED] zu verfolgen. Aber was macht man dann? Die Antworten hier, bringen mich zur Erkenntnis, dass Sid wohl doch nicht das Non-Plus-Ultra ist. Woody mit Backports? Unstable mit dem Verfolgen aller möglichen Maillinglisten? Da müsste man ja im Falle eines Problems, selber die Pakete bauen. Irgendwie alles nicht so das Wahre :-( Alternative Distribution wüsste ich auch keine. Bin viel zu sehr apt-get verwöhnt und selbst-compilieren mit Gentoo ist so Zeitaufwendig. -- Die eigene Erfahrung hat den Vorteil völliger Gewißheit. -- Schopenhauer Tja, ich werde wohl weiterhin Sid benutzen, bis ich dann irgendwann damit auf die Nase falle...
Re: Das Problem mit SID
Kai Timmer [EMAIL PROTECTED] (2004-05-29 17:30) wrote: * Maurice [EMAIL PROTECTED] [2004-05-29 16:25]: Hat jemand konkrete Beispiele, weshalb von Unstable immer so abgeraten wird? Ich hab mit Sid die Erfahrung gemacht dass, das größte Problem die Inkonsistenzen in den Paketabhängigkeiten sind. Da lässt sich ein Paket dann schon mal nicht installieren, wird von apt deinstalliert oder sonst was. Wenn man bei dist-upgrade nicht aufpasst kann das schnell daneben gehen. hm, komisch. Ich habe erst recht lange Woody und dann Sarge benutzt. Da hatte ich viel mehr Probleme von nicht erfüllbaren Abhängigkeiten usw. Bei Sid dagegen gar nicht. Aber was ich hier bei allen so lese, macht mir ein wenig Angst.
Re: Das Problem mit SID
Am 2004-05-30 14:34:59, schrieb Maurice: Woody mit Backports? Unstable mit dem Verfolgen aller möglichen Maillinglisten? Da müsste man ja im Falle eines Problems, selber die Pakete bauen. Irgendwie alles nicht so das Wahre :-( Nee, nicht selber bauen... Die Binaries sind ja da... Du müßtest Dir lediglich eine Liste von allen Paketen machen, die Du installiert hast und dich dann per script auf die BUG-Listen eintragen :-) Habe auch so ein verzeichnis im Maildir: ___ ( stdin ) / | ~/Maildir/DBUG/a2ps | ~/Maildir/DBUG/aalib1 | ~/Maildir/DBUG/adduser | ~/Maildir/DBUG/alien | ~/Maildir/DBUG/apt | ~/Maildir/DBUG/apt-file | ~/Maildir/DBUG/apt-listchanges | ~/Maildir/DBUG/apt-show-versions | ~/Maildir/DBUG/apt-utils | | snip | | ~/Maildir/DBUG/zlib1g \__ und in mutt machste einfach __ ( '/home/michelle/.mutt/muttrc' ) _ / | mailboxes `muttmailboxes DBUG` \__ und das script __ ( '/home/michelle/bin/muttmailboxes' ) / | #!/bin/bash | | cd ~/Maildir/$1 | TEMPFILE=`tempfile` | for i in `ls -D` ; do | echo -n +$1/$i $TEMPFILE | done | cat $TEMPFILE | rm $TEMPFILE \__ Jedesmal wenn eine meine Bug-Meddage eines der Pakete kommt und Du in 'mutt' C zum verzeichnis vechseln drückst, landest Du automatisch in der richtigen Mailbox. Ich habe derzeit über 700 Pakete in der Liste... Haut einwandfrei hin... Alternative Distribution wüsste ich auch keine. Bin viel zu sehr apt-get verwöhnt und selbst-compilieren mit Gentoo ist so Zeitaufwendig. Naja, ist auch nur unstable... und noch killermäßiger... Habe auch nicht damit gerechnet, was es mir alles installiert (Versionsmäßig) Greetings Michelle -- Linux-User #280138 with the Linux Counter, http://counter.li.org/ Michelle Konzack Apt. 917 ICQ #328449886 50, rue de Soultz MSM LinuxMichi 0033/3/8845235667100 Strasbourg/France IRC #Debian (irc.icq.com) signature.pgp Description: Digital signature
Re: Das Problem mit SID
Am 2004-05-30 10:13:27, schrieb Peter Kuechler: Warum denn? Du hast doch recht. Ich hatte noch nie beser laufende Rechner wie die mit Debian SID. Dan hast Du aber die Maschine nur über einen Router/Firewall am Internet, denn die Sicherheitslöchet die SID hat sind nicht übersehbar. Hätte keine Lust, mit ner 1/2 Jahr alten SID stundenlang auf der gleichen IP durchs Internet zu surfen... Habe pro Tag mehr als 50 Portsscans und noch wesentlich mehrere Hackangriffe. Die Logdateien sind voll damit... und abundzu verendet der pppd... Der typische $USER Desktop besteht nunmal aus nur einem Rechner an dem das Modem hängt, weshalb es absolut allen Gefahren ausgeliefert ist. Da UNSTABLE einzusetzen ist nur als Stand-Alone Surfstation mit Backup auf CD zum schnellen wiederherstellen geeignet... mfg Peter Küchler Greetings Michelle -- Linux-User #280138 with the Linux Counter, http://counter.li.org/ Michelle Konzack Apt. 917 ICQ #328449886 50, rue de Soultz MSM LinuxMichi 0033/3/8845235667100 Strasbourg/France IRC #Debian (irc.icq.com) signature.pgp Description: Digital signature
Re: Das Problem mit SID
Am Sonntag, 30. Mai 2004 18:05 schrieb Michelle Konzack: Am 2004-05-30 10:13:27, schrieb Peter Kuechler: Warum denn? Du hast doch recht. Ich hatte noch nie beser laufende Rechner wie die mit Debian SID. Dan hast Du aber die Maschine nur über einen Router/Firewall am Internet, denn die Sicherheitslöchet die SID hat sind nicht übersehbar. Die gibt es überall und immer wieder, oder warum glaubst Du, gibt es dei Patches für Woody? Hätte keine Lust, mit ner 1/2 Jahr alten SID stundenlang auf der gleichen IP durchs Internet zu surfen... 24 Stunden online, Null Problemo. Habe pro Tag mehr als 50 Portsscans und noch wesentlich mehrere Hackangriffe. Die Logdateien sind voll damit... und abundzu verendet der pppd... Die beissen sich an meinem Paketfilter die Zähne aus:-) Übrigens habe ich nicht meine Arbeitsplatzrechner am Internet, sondern meinen Fileserver/DNS/Timeserver/DHCP/Mailserver/Einwahlrechnen für Fernwartung. Naja und Firewall für meinen DSL-Zugang ist er auch noch. Und läuft und läuft und läuft... Ach ja, seit diesem Wochenende läuft er endlich mit Kernel 2.6.6 mit CAPI2.0 und Fritzcard PCI, jetzt ist er auch noch Faxserver. Der typische $USER Desktop besteht nunmal aus nur einem Rechner an dem das Modem hängt, weshalb es absolut allen Gefahren ausgeliefert ist. Da UNSTABLE einzusetzen ist nur als Stand-Alone Surfstation mit Backup auf CD zum schnellen wiederherstellen geeignet... Nun, offensichtlich gibt es über dieses Thema unterschiedliche Ansichten. Aber so soll es ja auch sein...;-) -- mfg Peter Küchler
Re: Das Problem mit SID
Hallo! On 30 May 2004 at 14:34 +0200, Maurice wrote: ^^^ Ich würde dich gerne mit vollem Namen ansprechen können. Wäre das möglich? Danke. Elmar W. Tischhauser [EMAIL PROTECTED] wrote: Es ist für den sicherheitsbewussten unstable-Nutzer also keinesfalls hinreichend, nur [EMAIL PROTECTED] zu verfolgen. Aber was macht man dann? Sich Zusatzinformationen beschaffen, was im Falle des Privatanwenders nicht einmal übermäßig zeitaufwändig ist, da zum Beispiel alle von böswilligen (lokalen) Benutzern ausgehenden Probleme schon mal per definitionem vom Tisch sind. Wenn also die Eingabe eines seltsamen Passwortes einen Pufferüberlauf im setuid-root installierten /usr/bin/passwd provozieren kann, ist das zu Hause weitaus weniger kritisch ist als etwa in einem Uni-Rechnerpool. Generell dürften die für den sid-Privatanwender relevanten Gefahren sich auf folgende Szenarien beschränken (dabei sind nur Angriffe von außen, also aus dem WAN, berücksichtigt). 1. Fehler im IP- oder TCP-Stack des Kernels. Das wären generisch ausnutzbare Bugs, die z.B. durch ein speziell geformtes Paket getriggert werden können. Sie kommen sehr selten vor und werden wohl meist bei gezielten und weniger bei automatisierten Angriffen genutzt (da Exploits meist an spezielle Kernelversionen gebunden sein dürften). Abhilfe: Möglichst aktuellen Kernel einsetzen. 2. Fehler in auf dem öffentlichen Interface angebotenen Diensten (z.B. HTTP, SSH). Die kommen immer mal wieder vor und werden gelegentlich auch automatisiert ausgenutzt (siehe zum Beispiel Slapper). Exploits in Diensten sind deshalb so kritisch, da diese häufig mit höheren Rechten laufen und somit am Gesamtsystem Schaden anrichten bzw. ihre Aktivitäten viel besser verbergen können als wenn sie nur unter einem unprivilegierten Nutzeraccount liefen. Abhilfe: Zunächst ist danach zu trachten, benötigte Dienste nur lokal bereitzustellen. Wenn am WAN-Interface nichts lauscht, kann dort auch nichts zum Einbruch verwendet werden. Ansonsten bietet es sich an, entweder die Security-Advisory-Mailingliste o.ä. des speziellen Dienstes zu verfolgen oder regelmäßig auf dessen Homepage nachzusehen. In den meisten Fällen dürfte unstable bald die nötigen Updates bereithalten, ansonsten kompiliert man sich die gefixte Upstream-Version unter Verwendung des letzten unstable-Sourcepakets schnell selbst. 3. Fehler in lokal angebotenen Diensten (z.B. NFS, IMAP, HTTP). Für das Vorkommen gilt das Gleiche wie für (2). Der Unterschied ist, dass ein externer Angreifer sich nicht direkt mit dem fehlerbehafteten Dienst verbinden kann, so dass Gefahren nur von lokalen Benutzern oder fehlerhafter Datenbehandlung entstehen können. Letztere ist durchaus manchmal gegeben, zum Beispiel könnte ein Fehler im IMAP-Server durch speziell formatierte E-Mails ausgenutzt werden, die ein Angreifer dir senden kann (da hilft es dann nichts mehr, dass der imapd nur auf 192.168.0.5:993 lauscht). Abhilfe: Wie bei (2). 4. Fehler in Clientprogrammen, welche aus dem Netz stammende Daten verarbeiten bzw. mit dem Internet interagieren (z.B. Browser, MUA, Bildanzeigeprogramm). Wenn beispielsweise Letzteres beim Anzeigen eines aus dem Internet heruntergeladenen Bildes bei der Speicherallokation auf dessen Längenangabe vertraut, wäre evtl. das Ausführen beliebigen Codes mit den Rechten des Benutzers möglich. Abhilfe: Wie bei (2). Zusätzlich hilft gesundes Misstrauen gegen nette Attachments oder dubiose Webseiten erheblich. 5. Fehler in allen anderen Programmen haben deutlich geringere Sicherheitsrelevanz. 6. Würmer/Viren/Trojanische Pferde. Wenn sie sich automatisiert installieren können, liegt ein Fall von (1)-(4) vor. Wenn nicht, ist man ohnehin selbst schuld. Abhilfe: Mehr als Verwendung des Gehirns in Kombination mit gesundem Menschenverstand ist nicht erforderlich. 7. Konfigurationsfehler. Gegen solche hilft auch der Einsatz von Woody nichts ;-). Abhilfe: Sachverstand beim Administrieren. Da man als Privatanwender in der Regel keine Dienste am öffentlichen Interface und nur wenige lokal benötigt [auch unter den lokalen sind ja nur diejenigen wirklich kritisch, welche aus nicht vertrauenswürdigen Quellen stammende Daten verarbeiten], reduziert sich die Menge der kritischen Anwendungen, die man auf aktuellem Stand halten sollte, erheblich. Auch gilt nicht für jedes unter (4) erwähnte Programm die gleiche Gefährdungsstufe. Der Browser ist sicherlich am kritischsten, bei einem Bildanzeigeprogramm würde ich die Updatefrequenz von sid als allemal ausreichend ansehen. Security-Announce-MLs haben zudem meist sehr geringen Traffic. Gibt es solche nicht, wäre es zum Beispiel eine Möglichkeit, einfach im Browser einen Bookmark-Ordner zu den Sicherheitsseiten oder Homepages der entsprechenden Programme anzulegen und etwa einmal wöchentlich kurz alle Seiten
Re: Das Problem mit SID
On 30.May 2004 - 20:11:52, Peter Kuechler wrote: Am Sonntag, 30. Mai 2004 18:05 schrieb Michelle Konzack: Am 2004-05-30 10:13:27, schrieb Peter Kuechler: Warum denn? Du hast doch recht. Ich hatte noch nie beser laufende Rechner wie die mit Debian SID. Dan hast Du aber die Maschine nur über einen Router/Firewall am Internet, denn die Sicherheitslöchet die SID hat sind nicht übersehbar. Die gibt es überall und immer wieder, oder warum glaubst Du, gibt es dei Patches für Woody? Ja und bei Sid musst du selber Patchen oder hoffen das der Maintainer nicht schlaeft und nen fix bereitstellt... Habe pro Tag mehr als 50 Portsscans und noch wesentlich mehrere Hackangriffe. Die Logdateien sind voll damit... und abundzu verendet der pppd... Die beissen sich an meinem Paketfilter die Zähne aus:-) Was ist wenn der nen Fehler hat? Übrigens habe ich nicht meine Arbeitsplatzrechner am Internet, sondern meinen Fileserver/DNS/Timeserver/DHCP/Mailserver/Einwahlrechnen für Fernwartung. Naja und Firewall für meinen DSL-Zugang ist er auch noch. Ich schliesse mal daraus dass du diese Dienste fuers Internet freigegeben hast? Was ist wenn einer davon ein Sicherheitsloch hat und der Maintainer grad 4 Wochen in Urlaub? Machst du wirklich nur alle paar Monate ein Upgrade? Na dann lass mal lieber niemanden der boeswillig ist deine IP rauskriegen.. Andreas -- Death wish, n.: The only wish that always comes true, whether or not one wishes it to. -- 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)
Re: Das Problem mit SID
Am 2004-05-30 20:11:52, schrieb Peter Kuechler: Am Sonntag, 30. Mai 2004 18:05 schrieb Michelle Konzack: Dan hast Du aber die Maschine nur über einen Router/Firewall am Internet, denn die Sicherheitslöchet die SID hat sind nicht übersehbar. Die gibt es überall und immer wieder, oder warum glaubst Du, gibt es dei Patches für Woody? Für WOODY ! - Wir sprachen aber von SID ! Hätte keine Lust, mit ner 1/2 Jahr alten SID stundenlang auf der gleichen IP durchs Internet zu surfen... 24 Stunden online, Null Problemo. Und die Sicherheitsprobleme ? Die Upstream Autoren und Package Maintainer in SID reagieren wesentlich langsamer als das Security Team für WOODY. Ich habe bereits mehrfach auf patches über einen Monat warten müssen. Ich empfinde das nicht besonderst lustig. Habe pro Tag mehr als 50 Portsscans und noch wesentlich mehrere Hackangriffe. Die Logdateien sind voll damit... und abundzu verendet der pppd... Die beissen sich an meinem Paketfilter die Zähne aus:-) Und wenn der nen Fehler hat ? Übrigens habe ich nicht meine Arbeitsplatzrechner am Internet, sondern meinen Fileserver/DNS/Timeserver/DHCP/Mailserver/Einwahlrechnen für Fernwartung. Naja und Firewall für meinen DSL-Zugang ist er auch noch. Das Teil auf SID ? Und läuft und läuft und läuft... Der typische $USER Desktop besteht nunmal aus nur einem Rechner an dem das Modem hängt, weshalb es absolut allen Gefahren ausgeliefert ist. Da UNSTABLE einzusetzen ist nur als Stand-Alone Surfstation mit Backup auf CD zum schnellen wiederherstellen geeignet... Nun, offensichtlich gibt es über dieses Thema unterschiedliche Ansichten. Aber so soll es ja auch sein...;-) Wenn $USER sich SID installiert, kann er auch bei Windows eXPlode bleiben. mfg Peter Küchler Greetings Michelle -- Linux-User #280138 with the Linux Counter, http://counter.li.org/ Michelle Konzack Apt. 917 ICQ #328449886 50, rue de Soultz MSM LinuxMichi 0033/3/8845235667100 Strasbourg/France IRC #Debian (irc.icq.com) signature.pgp Description: Digital signature
Re: Das Problem mit SID
'nabend, On Sunday 30 May 2004 22:04, Andreas Pakulat wrote: On 30.May 2004 - 20:11:52, Peter Kuechler wrote: Am Sonntag, 30. Mai 2004 18:05 schrieb Michelle Konzack: Am 2004-05-30 10:13:27, schrieb Peter Kuechler: Warum denn? Du hast doch recht. Ich hatte noch nie beser laufende Rechner wie die mit Debian SID. ich schon, müssen wir aber jetzt nicht breittreten.) Dan hast Du aber die Maschine nur über einen Router/Firewall am Internet, denn die Sicherheitslöchet die SID hat sind nicht übersehbar. Die gibt es überall und immer wieder, oder warum glaubst Du, gibt es dei Patches für Woody? Ja und bei Sid musst du selber Patchen oder hoffen das der Maintainer nicht schlaeft und nen fix bereitstellt... Habe pro Tag mehr als 50 Portsscans und noch wesentlich mehrere Hackangriffe. Die Logdateien sind voll damit... und abundzu verendet der pppd... s.o., für solche Sachen verwende ich dann lieber doch nen BSD. Ich weiss, dass ich damit hier nicht auf viel Gegenliebe rechnen kann, aber bei uns in der Firma ist Policy: intern Linux und Rechner, auf die von extern zugegriffen wird bekommen nen *BSD spendiert. Hat sich bis jetzt bewährt. Die beissen sich an meinem Paketfilter die Zähne aus:-) Ist nur ne Frage der Zeit, die ich habe und der kriminellen Energie. Ist beides hoch und groß genug, biste dran Manche exploits kommen schneller als du reagieren kannst) 14 Tage offen (unbeabsichtigt und bis dato unbemerkt) sind mehr als genug. Wenn du dann mit deinem Rechner an exponierter Stelle stehst (web- oder Mailserver), haste schon verloren. Deshalb (siehe oben) favorisiere ich dort Systeme wie BSD mit ihrem Portstree, wo halt dann mal selbst kompiliert werden muss. Geht schneller, als auf ein fertiges Paket zu warten. Lücke muss natürlich auch im Quelltext geschlossen werden, sonst bringt dat man nichts. Was ist wenn der nen Fehler hat? Übrigens habe ich nicht meine Arbeitsplatzrechner am Internet, sondern meinen Fileserver/DNS/Timeserver/DHCP/Mailserver/Einwahlrechnen für Fernwartung. Naja und Firewall für meinen DSL-Zugang ist er auch noch. Ich schliesse mal daraus dass du diese Dienste fuers Internet freigegeben hast? Was ist wenn einer davon ein Sicherheitsloch hat und der Maintainer grad 4 Wochen in Urlaub? Machst du wirklich nur alle paar Monate ein Upgrade? Na dann lass mal lieber niemanden der boeswillig ist deine IP rauskriegen.. s.o. ciao dieter
Re: Das Problem mit SID
Hallo! On 30 May 2004 at 22:20 +0200, Dieter Franzke wrote: On Sunday 30 May 2004 22:04, Andreas Pakulat wrote: Deshalb (siehe oben) favorisiere ich dort Systeme wie BSD mit ihrem Portstree, wo halt dann mal selbst kompiliert werden muss. Geht schneller, als auf ein fertiges Paket zu warten. Lücke muss natürlich auch im Quelltext geschlossen werden, sonst bringt dat man nichts. Ich schliesse mal daraus dass du diese Dienste fuers Internet freigegeben hast? Was ist wenn einer davon ein Sicherheitsloch hat und der Maintainer grad 4 Wochen in Urlaub? s.o. Ich habe ja wirklich nichts gegen die freien BSD-Systeme, aber was bringt das 's.o.' in diesem Zusammenhang? Wenn der Maintainer eines BSD-Ports vier Wochen lang im Urlaub ist, unterscheidet sich die Situation doch nicht grundlegend vom gleichen Fall bei einer binärpaketbasierten Linuxdistribution wie Debian. Zumal, wenn ich mich richtig erinnere, sich bei FreeBSD das Security-Team nur ums Base-System und nicht um die Ports-Collection kümmert. Wenn der Nachschub aus den Ports oder den aktuellen unstable-Paketen mal ausbleibt, wird der Administrator so oder so Hand anlegen müssen. Gruß, Elmar -- [ GnuPG: D8A88C0D / 2407 063C 1C92 90E9 4766 B170 5E95 0D7F D8A8 8C0D ] ··· Geschehenes erkennt auch ein Tor. -- Homer, Ilias pgpiqpILd2u07.pgp Description: PGP signature
Re: Das Problem mit SID
Christian Schulte [EMAIL PROTECTED] wrote: Kai Timmer wrote: * Maurice [EMAIL PROTECTED] [2004-05-29 16:25]: Hat jemand konkrete Beispiele, weshalb von Unstable immer so abgeraten wird? Ich hab mit Sid die Erfahrung gemacht dass, das größte Problem die Inkonsistenzen in den Paketabhängigkeiten sind. Ja genau! Das unstable bezieht sich schließlich auch auf die Paketverwaltung und nicht auf die in den Paketen enthaltene Software. Stimmt das soweit eigendlich ? Also bisher meinte ich immer, dass mit stable/testing/unstable der Zustand der Paketverwaltung bzw. Distribution gemeint ist. Auch. In unstable fließt schon einmal eine Version einer Software ein, die evtl. nicht zu 100% durchgetestet ist. Aber im ganzen hast du schon recht, der ständige Fluss ist wohl die eigentlich treibende Kraft hinter dem Status unstable. Das heisst aber nicht, dass man ein unstable installieren kann, und sich darauf verlassen kann, niemals irgendwelche Probleme mit den Paketen _unterneinander_ zu bekommen. Neue Programmversion linkt evtl. gegen neue und zusätzliche Libraries. Korrekt. Siehe z.B. die derzeitige Situation mit Gnome, Samba, CUPS und gnutls10. S° -- BOFH excuse #235: The new frame relay network hasn't bedded down the software loop transmitter yet. -- 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)
Re: Das Problem mit SID
Werner Gast [EMAIL PROTECTED] wrote: Am Sam, 2004-05-29 um 16.25 schrieb Maurice: PS: Ich beziehe mich auf einen Desktop-PC. Bei einem Server kann ich mir vorstellen, dass man wohl lieber nur ausgiebig getestete Software verwenden will. So ist es. Sid ist gut fuer den neuen, privaten Desktop. Für Server und Arbeitsplatzrechner ist aber woody die richtige Wahl. Ein innovatives Sid auf den Rechnern von Sachbearbeitern wuerde den Helpdesk im Unternehmen total ueberfordern. Der Arbeitsplatzrechner muss moeglichst lange genau so laufen, wie bei der Einweisung/Schulung vermittelt. Das haelt die Kosten im Unternehmen niedrig und reduziert den Supportaufwand. Ein sid, das man seit dem Tag der Einführung nicht mehr verändert böte das auch ;-) *Duck und wech* Heino -- 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)
Das Problem mit SID
Hallo, ich habe eigentlich gar kein Problem mit Sid. Mein einziges ist, dass alle Welt sagt, Sid macht Probleme. Überall lese ich Wer unstable benutzt, muss wissen was er tut, Mit unstable darf man nicht fragen usw. Ich benutze Sid jetzt seit ca. einem halben Jahr und im Gegensatz zu Woody und Sarge läuft alles bestens. Die Programme (die ich benutze) sind viel weniger verbuggt und überhaupt fühlt sich das ganze System geschmeidiger an. Und ich würde von mir nicht sagen, dass ich der Debian-Experte bin. Viel mehr als apt-get install hab ich eigentlich nie gebraucht. Ich weiß jetzt allerdings auch gar nicht, wann ich das letzte Komplett-Upgrade gemacht habe... Updaten tue ich nur hin und wieder einzelne Pakete, die auf debian-security-announce gemeldet werden. Und dort kommt es eigentlich kaum vor, dass mal ein Paket nur für Woody gefixt wird. Aber wozu auch ständig alles upgraden. Macht man ja bei anderen Distributionen auch nicht. Wo ist der Unterschied zw. Debian Sid und beispielsweise Gentoo, was die Stabilität usw. betrifft? Hat jemand konkrete Beispiele, weshalb von Unstable immer so abgeraten wird? Danke. PS: Ich beziehe mich auf einen Desktop-PC. Bei einem Server kann ich mir vorstellen, dass man wohl lieber nur ausgiebig getestete Software verwenden will.
Re: Das Problem mit SID
* Maurice [EMAIL PROTECTED] [2004-05-29 16:25]: Hat jemand konkrete Beispiele, weshalb von Unstable immer so abgeraten wird? Ich hab mit Sid die Erfahrung gemacht dass, das größte Problem die Inkonsistenzen in den Paketabhängigkeiten sind. Da lässt sich ein Paket dann schon mal nicht installieren, wird von apt deinstalliert oder sonst was. Wenn man bei dist-upgrade nicht aufpasst kann das schnell daneben gehen. Das ist auch der Grund warum ich testing einsetzte. Da muss ich dann zwar meist ein paar Tage auf die Updates warten, aber ich denk mal auf den Desktop System ist das auch bei einigen Sicherheislücken zu vertreten. Grüße, -- .~.--- /V\ | Kai Timmer| // \\ | mailto: [EMAIL PROTECTED] | /( )\ | ICQ: 67765488 | ^'~'^ --- -- 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)
Re: Das Problem mit SID
Maurice [EMAIL PROTECTED] wrote: Hat jemand konkrete Beispiele, weshalb von Unstable immer so abgeraten wird? 4.3.0.dfsg.1-2 zerbröselt NumLock, CapsLock und den gnome-settings-daemon. gnutls10-Transition zerbröselt viele Pakete, die erste rekompiliert werden müssen. Wenn man udev und makedev installiert hat und devfs nutzt, ist /dev nach dem Reboot leer, weil das udev-init-Script buggy ist und bestimmte Config-Optionen ignoriert und statt dessen hart-kodierte Werte benutzt. Nur so ein paar Beispiele. S° -- Fachbegriffe der Informatik - Einfach erklärt 161: Internetpräsenz Irgendwas machen, weil das andere auch machen. (Martin Schmitt) -- 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)
Re: Das Problem mit SID
Am 2004-05-29 16:25:32, schrieb Maurice: Hallo, Ich benutze Sid jetzt seit ca. einem halben Jahr und im Gegensatz zu Woody und Sarge läuft alles bestens. Die Programme (die ich benutze) sind viel weniger verbuggt und überhaupt fühlt sich das ganze System geschmeidiger an. Interessant... vor rund 6 Stunden hatte mein Script einen vollständigen Mirror der Binaries und Sourcen nach 1106 Minuten heruntergezogen gehabt und ich habe mich munter ans Installieren gemacht. Nach gut 4 Stunden war alles installiert (rund 700 Pakete) und nun sitze ich vor einem System das den X-Server nicht mehr kennt usw... Immerhin arbeite ich schon ein paar Jährchen mit Linux und weis mittlerweile wos hackt, aber die sache ist nichts für Anfänger. Habe 38 brokem Packages... - SID ebend ! Ich weiß jetzt allerdings auch gar nicht, wann ich das letzte Komplett-Upgrade gemacht habe... Updaten tue ich nur hin und wieder einzelne Pakete, die auf debian-security-announce gemeldet werden. Und dort kommt es eigentlich kaum vor, dass mal ein Paket nur für Woody gefixt wird. ??? - Wie soll das den gehen ? Für SID gibt es keine Security-Updates mit Ausnahme von solchen sachen, die in WOODY gefunden wurden und das Security-Fix dann nach SID geported wurde... Aber wozu auch ständig alles upgraden. Macht man ja bei anderen Distributionen auch nicht. Wo ist der Unterschied zw. Debian Sid und ??? - Haben dann entsprechende Sicherheitslöcher ! Der Otto-Normal-User wird normalerweise sein analogmodem, seine isdnkarte oder adsl-modem direkt am Computer haben und da sind Security- Fixes oberstes Gebot. beispielsweise Gentoo, was die Stabilität usw. betrifft? Naja, mein Gentoo hat nur allzuoft probleme... Hat jemand konkrete Beispiele, weshalb von Unstable immer so abgeraten wird? Es ist Development ! In der Entwicklung ! Da haste IMMER Bugs ! Danke. PS: Ich beziehe mich auf einen Desktop-PC. Bei einem Server kann ich mir vorstellen, dass man wohl lieber nur ausgiebig getestete Software verwenden will. Bei einem direkt an das Internet angeschlossenem Rechner, egal Windows oder Linux ist immer eine Gefahr. Greetings Michelle -- Linux-User #280138 with the Linux Counter, http://counter.li.org/ Michelle Konzack Apt. 917 ICQ #328449886 50, rue de Soultz MSM LinuxMichi 0033/3/8845235667100 Strasbourg/France IRC #Debian (irc.icq.com) signature.pgp Description: Digital signature
Re: Das Problem mit SID
Sven Hartge [EMAIL PROTECTED] wrote: Maurice [EMAIL PROTECTED] wrote: Hat jemand konkrete Beispiele, weshalb von Unstable immer so abgeraten wird? 4.3.0.dfsg.1-2 zerbröselt NumLock, CapsLock und den gnome-settings-daemon. gnutls10-Transition zerbröselt viele Pakete, die erste rekompiliert werden müssen. Wenn man udev und makedev installiert hat und devfs nutzt, ist /dev nach dem Reboot leer, weil das udev-init-Script buggy ist und bestimmte Config-Optionen ignoriert und statt dessen hart-kodierte Werte benutzt. Nur so ein paar Beispiele. Welche Pakete zerbröselt mir eigentlich ÄÖÜ auf der Konole? Ansonnsten ist die deutsche qwertz Tastatur voll da? Nur ÄÖÜ funktionieren nicht. ein dpkg-reconfigure console-data brachte da auch nix. Heino -- 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)
Re: Das Problem mit SID
* Michelle Konzack [EMAIL PROTECTED] wrote: Am 2004-05-29 16:25:32, schrieb Maurice: Ich weiß jetzt allerdings auch gar nicht, wann ich das letzte Komplett-Upgrade gemacht habe... Updaten tue ich nur hin und wieder einzelne Pakete, die auf debian-security-announce gemeldet werden. Und dort kommt es eigentlich kaum vor, dass mal ein Paket nur für Woody gefixt wird. ??? - Wie soll das den gehen ? Für SID gibt es keine Security-Updates mit Ausnahme von solchen sachen, die in WOODY gefunden wurden und das Security-Fix dann nach SID geported wurde... Wo ist das Problem? Entweder ist in Sid ziemlich schnell eine vollkommen neue Version des Upstreampakets, die die Sicherheitslücke nicht mehr enthält oder es wird häufig der genannte Patch des Security Announcements in die aktuelle Version eingepflegt, wenn Upstream kein neues Release rausbringt. Es gibt halt nur kein Fix des offiziellen Debian Security Teams, aber kein DD kann es sich wirklich leisten, seine Version in Sid voller Sicherheitslücken zu lassen, so dass Woody und Sid fast zeitnah gefixte Versionen erhalten. Hat jemand konkrete Beispiele, weshalb von Unstable immer so abgeraten wird? Es ist Development ! In der Entwicklung ! Da haste IMMER Bugs ! Die Bugs habe ich auch bei Woody, ebenso wie bei *BSD, ebenso wie bei Windows. Gruß, Marcus -- When you grow up in America, things like Christianity water down your feelings and dilute a lot of things. When you're taught to love everyone, taught to love your enemy, what value does that put on love? -- 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)
Re: Das Problem mit SID
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hallo. Heino Tiedemann schrieb am 29.05.2004 17:59: | Welche Pakete zerbröselt mir eigentlich ÄÖÜ auf der Konole? | Ansonnsten ist die deutsche qwertz Tastatur voll da? Nur ÄÖÜ | funktionieren nicht. | | ein dpkg-reconfigure console-data brachte da auch nix. | | Heino | | hmm als tastaturlayout eventuell programmer anstatt latin1-nodeadkeys eingestellt? so wars bei mir... - -- So long, Rainer Bendig aka mindz - -- PGP/GPG key (ID: 0xF0A7738A) available via wwwkeys.de.pgp.net key-fingerprint 178F E5C5 D423 0C6F 7DC9 B6DD A6B5 58B9 F0A7 738A - -- () ascii ribbon campaign - against html mail /\ http://arc.pasp.de/ - against microsoft attachments -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (MingW32) iD8DBQFAuJt5i1D4EGbeRE8RArxnAJ91YidNux4wiTZzp+zoQO/dWQnsCQCfXFUL AsFv3BboIidjQ2iV/JjLaao= =Ow9F -END PGP SIGNATURE- -- 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)
Re: Das Problem mit SID
Kai Timmer wrote: * Maurice [EMAIL PROTECTED] [2004-05-29 16:25]: Hat jemand konkrete Beispiele, weshalb von Unstable immer so abgeraten wird? Ich hab mit Sid die Erfahrung gemacht dass, das größte Problem die Inkonsistenzen in den Paketabhängigkeiten sind. Ja genau! Das unstable bezieht sich schließlich auch auf die Paketverwaltung und nicht auf die in den Paketen enthaltene Software. Stimmt das soweit eigendlich ? Also bisher meinte ich immer, dass mit stable/testing/unstable der Zustand der Paketverwaltung bzw. Distribution gemeint ist. Eine Software die in unstable ist, ist daher meist nicht unstabiler als in stable. Meistens sind in unstable sogar recht viele Bugs in der Software gefixt worden, so dass man fast behaupten könnte dass die Software in unstable generell weniger Bugs hat, als in stable. In stable sind die Versionen halt alle einiges kleiner als in unstable. Das heisst aber nicht, dass man ein unstable installieren kann, und sich darauf verlassen kann, niemals irgendwelche Probleme mit den Paketen _unterneinander_ zu bekommen. Neue Programmversion linkt evtl. gegen neue und zusätzliche Libraries. Das muss alles mit den Paketabhängigkeiten erledigt werden. Demnach ändert sich in unstable ziemlich of was an den Paketen. In diesen Paketen sind dann aber auch wieder irgendwelche Scripte, die beim De-/Installieren irgendetwas im System machen, was für das Paket benötigt wird. Das ist in unstable halt eben auch unstable. Also stable/testing/unstable meint die Distribution als ganzes und nicht den Status einzelner Binaries! -- Christian
Re: Das Problem mit SID
Hallo! On 29 May 2004 at 16:25 +0200, Maurice wrote: Ich weiß jetzt allerdings auch gar nicht, wann ich das letzte Komplett-Upgrade gemacht habe... Updaten tue ich nur hin und wieder einzelne Pakete, die auf debian-security-announce gemeldet werden. Vorsicht! DSAs gibt es nur für Woody-Probleme. Wenn also ein bei dir installiertes Paket ein nur in neueren Versionen auftretendes sicherheitsrelevantes Problem hat, gibt es kein DSA, was dich darauf aufmerksam machen würde. Der letzte Buffer Overflow in Mutt war so ein Beispiel, genauso wie alle Apache2-Bugs es sind, da nur Apache 1.x in Woody ist. Es ist für den sicherheitsbewussten unstable-Nutzer also keinesfalls hinreichend, nur [EMAIL PROTECTED] zu verfolgen. Gruß, Elmar -- [ GnuPG: D8A88C0D / 2407 063C 1C92 90E9 4766 B170 5E95 0D7F D8A8 8C0D ] ··· Die eigene Erfahrung hat den Vorteil völliger Gewißheit. -- Schopenhauer pgpnjA3Dkjk3Y.pgp Description: PGP signature
Re: Das Problem mit SID
Rainer Bendig, Digitally Impressed [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hallo. Heino Tiedemann schrieb am 29.05.2004 17:59: | Welche Pakete zerbröselt mir eigentlich ÄÖÜ auf der Konole? | Ansonnsten ist die deutsche qwertz Tastatur voll da? Nur ÄÖÜ | funktionieren nicht. | | ein dpkg-reconfigure console-data brachte da auch nix. | | Heino | | hmm als tastaturlayout eventuell programmer anstatt latin1-nodeadkeys eingestellt? so wars bei mir... Nö, hab latin1 (mit deadkeys). Hm.. Heino -- 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)
Re: Das Problem mit SID
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, Christian Schulte wrote: Kai Timmer wrote: * Maurice [EMAIL PROTECTED] [2004-05-29 16:25]: Hat jemand konkrete Beispiele, weshalb von Unstable immer so abgeraten wird? Ich hab mit Sid die Erfahrung gemacht dass, das größte Problem die Inkonsistenzen in den Paketabhängigkeiten sind. Ja genau! Das unstable bezieht sich schließlich auch auf die Paketverwaltung und nicht auf die in den Paketen enthaltene Software. Stimmt das soweit eigendlich ? Also bisher meinte ich immer, dass mit stable/testing/unstable der Zustand der Paketverwaltung bzw. Distribution gemeint ist. Eine Software die in unstable ist, ist daher meist nicht unstabiler als in stable. Meistens sind in unstable sogar recht viele Bugs in der Software gefixt worden, so dass man fast behaupten könnte dass die Software in unstable generell weniger Bugs hat, als in stable. In stable sind die Versionen halt alle einiges Teilweise. Es gibt zum Teil Uploads, wo die neue Upstream-Version kaputt ist. perl war letztens ein Beispiel etc. Oder Library-Inkompatibiltäten die sich erst später zeigen ($app gleichzeitig (indirekt) gegen zwei gnutls-versionen gelinkt etc.) Es ist nicht immer nur die Paketverwaltung... Grüße/Regards, René - -- .''`. René Engelhard -- Debian GNU/Linux Developer : :' : http://www.debian.org | http://people.debian.org/~rene/ `. `' [EMAIL PROTECTED] | GnuPG-Key ID: 248AEB73 `- Fingerprint: 41FA F208 28D4 7CA5 19BB 7AD9 F859 90B0 248A EB73 -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAuNmp+FmQsCSK63MRAoKFAJ4806wllaf+1zAIIvMxc/yYLXUXygCfStf/ ZNzSRVMBMDsUIgKcLxS0m3U= =WBXZ -END PGP SIGNATURE- -- 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)
Re: Das Problem mit SID
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, Elmar W. Tischhauser wrote: Vorsicht! DSAs gibt es nur für Woody-Probleme. Wenn also ein bei dir installiertes Paket ein nur in neueren Versionen auftretendes sicherheitsrelevantes Problem hat, gibt es kein DSA, was dich darauf aufmerksam machen würde. Der letzte Buffer Overflow in Mutt war so ein Beispiel, genauso wie alle Apache2-Bugs es sind, da nur Apache 1.x in Woody ist. Oder OOo wo 1.1.1-2 und -3 security-bugs fixen (in der neon-lib die sei - -3 glücklicherweise extern ist...) (nein, kein Scherz..) Grüße/Regards, René - -- .''`. René Engelhard -- Debian GNU/Linux Developer : :' : http://www.debian.org | http://people.debian.org/~rene/ `. `' [EMAIL PROTECTED] | GnuPG-Key ID: 248AEB73 `- Fingerprint: 41FA F208 28D4 7CA5 19BB 7AD9 F859 90B0 248A EB73 -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAuNkk+FmQsCSK63MRAoNfAJ4zWasH5XIjPEwpEp5eMMnY8g3vxACeNb70 oo3OzHCaFJi4qLmEN5jYjxc= =z5nc -END PGP SIGNATURE- -- 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)
Re: Das Problem mit SID
Am Sam, 2004-05-29 um 16.25 schrieb Maurice: PS: Ich beziehe mich auf einen Desktop-PC. Bei einem Server kann ich mir vorstellen, dass man wohl lieber nur ausgiebig getestete Software verwenden will. So ist es. Sid ist gut fuer den neuen, privaten Desktop. Für Server und Arbeitsplatzrechner ist aber woody die richtige Wahl. Ein innovatives Sid auf den Rechnern von Sachbearbeitern wuerde den Helpdesk im Unternehmen total ueberfordern. Der Arbeitsplatzrechner muss moeglichst lange genau so laufen, wie bei der Einweisung/Schulung vermittelt. Das haelt die Kosten im Unternehmen niedrig und reduziert den Supportaufwand. cu Werner
