Stable vs Testing

[Trollkirsche]

Hallo zusammen,

Wie verhält es sich mit einer Testing Version, die man installiert? Wird eine Testing Version stetig weitergeführt und geht dann, nachdem eine neue Stable Version erscheint, in die nächste Version über oder bleibt sie diesselbe Version, in diesem Falle die Buster Version? Wird dann Testing zu Stable und man müsste sich die neue Testing Version installieren, die dann erscheint, damit man die neue Version geniessen kann?

[TomL]

Wie verhält es sich mit einer Testing Version, die man installiert? Wird eine Testing Version stetig weitergeführt und geht dann, nachdem eine neue Stable Version erscheint, in die nächste Version über oder bleibt sie diesselbe Version, in diesem Falle die Buster Version?

In meinen sources.lists steht nirgends testing drin, sondern von Anfang an Buster. Das heisst, meine Installationen sind jetzt schon Buster und bleiben immer Buster. Würde ich testing eintragen, bleiben sie Buster nur bis zum Release von Buster.... ab dem Tag wird Testing dann sukzessive zu Bullseye.

[Trollkirsche]

Wie verhält es sich mit einer Testing Version, die man installiert? Wird eine Testing Version stetig weitergeführt und geht dann, nachdem eine neue Stable Version erscheint, in die nächste Version über oder bleibt sie diesselbe Version, in diesem Falle die Buster Version?

In meinen sources.lists steht nirgends testing drin, sondern von Anfang an Buster. Das heisst, meine Installationen sind jetzt schon Buster und bleiben immer Buster. Würde ich testing eintragen, bleiben sie Buster nur bis zum Release von Buster.... ab dem Tag wird Testing dann sukzessive zu Bullseye.

Interessant. Kann ich gefahrlos eine Stretch Version zu einer Testing Version Buster upgraden oder muss ich das System neu installieren? Ein host läuft bereits auf Buster Testing und möchte nun auch den anderen PC, auf dem eine stretch stable version läuft, auf buster testing migrieren.

[MSfree]

Kann ich gefahrlos eine Stretch Version zu einer Testing Version Buster upgraden oder muss ich das System neu installieren?

Gefahrlos ist nichts im Leben. Backups von Nutzerdaten und den wichtigsten Konfiurationsdateien sollte man immer vorher anlegen.

Von Stretch auf Buster sollte ziemlich schmerzfrei ablaufen und eine Neuinstallation ist nicht nötig.

[Trollkirsche]

Kann ich gefahrlos eine Stretch Version zu einer Testing Version Buster upgraden oder muss ich das System neu installieren?

Gefahrlos ist nichts im Leben. Backups von Nutzerdaten und den wichtigsten Konfiurationsdateien sollte man immer vorher anlegen.

Von Stretch auf Buster sollte ziemlich schmerzfrei ablaufen und eine Neuinstallation ist nicht nötig.

Gefahrlos ist nichts im Leben.

Du sagst es

Backups des home, etc, root verzeichnisses mache ich immer vor grösseren operationen am System.

Kann ich eigentlich auch nach Upgrade von einem zum anderen System komplett das ganze home dir übernehmen? Bisher habe ich immer, um ein sauberes System zu erhalten, jedes Verzeichnis das ich migrieren wollte, auf das neue System vom Backup übernommen.

Damit steigt jedoch auch gleichzeitig die Fehlerquote und man könnte das ein oder andere vergessen, rüberzukopieren. Andererseits möchte ich keine Altlasten des home verzeichnisses auf das neue System übernehmen. Gleiches gilt für das verzeichnis etc.

Wie migriert ihr eure systemdaten so von einer Version zur anderen?

[willy4711]

Kann ich eigentlich auch nach Upgrade von einem zum anderen System komplett das ganze home dir übernehmen? Bisher habe ich immer, um ein sauberes System zu erhalten, jedes Verzeichnis das ich migrieren wollte, auf das neue System vom Backup übernommen.

Das ist an sich ein ganz gutes Vorgehen., muss aber nun nicht unbedingt nach einem Upgrade gemacht werden.

Ich mache es so, dass ich von Zeit zu Zeit die Verzeichnisse durchgehe und Konfigurationsdateien / Verzeichnisse von Programmen, die nicht mehr vorhanden sind, lösche. Das sind aber immer nur die für mich oder den jeweiligen Nutzer angelegten Konfigs.

System-weit sind diese Dateien in der Regel in /etc. Nur dort werden sie auch bei einem Upgrade überschrieben. Deshalb kann es sinnvoll sein, auch dieses Verzeichnis zu sichern, wenn man dort systemweite Veränderungen vorgenommen hat.

Das Root- Verzeichnis sichere ich nie. Wenn man da wirklich etwas zerschossen hat (ist mir in den ganzen Jahren erst einmal passiert), ist der Aufwand, einen Fehler zu finden, in der Regel um ein Vielfaches größer, als eine Neuinstallation.

Was ich noch sichere ist mein /opt. Diese Verzeichnis ist bei mir komplett von einem System zu einem beliebigen anderen übertragbar. Da dort nur Programme sind, die sich ohne weitere Installation starten lassen ( also Firefox , Thunderbird, FreeFileSync, Master-PDF-Editor usw).
Die Desktop-Dateien für diese Programme befinden sich eh in meinem /home, sind also nach einer eventuellen Neuinstallation
sofort wieder verfügbar. Ich portiere das /opt sogar in VM's, wenn ich die Programme dort brauche.

Nochmal zu den Releases:

Ich habe mich noch zu Jessies Zeiten entschieden, in meiner sources.list ausschließlich Testing zu haben.
Vorteil: Man hat quasi ein "rolling Release".
Bei einem Release - Wechsel geht es im gewohnten täglichen "full-upgrade" Modus weiter wie immer bei Testing.
Das ist ein Klick auf einen Starterund gut ist.

Ernsthafte Probleme habe ich die ganzen Zeit nur einmal gehabt. Aber wenn ich sehe was Nutzer teilweise für Probleme mit der
Stable Version haben, fahre ich damit sehr gut. Abgesehen von ein bisschen mehr Upgrade - Arbeit.

Wenn man sich entscheidet, Testing zu fahren sollte man das berücksichtigen, genauso wie die Möglichkeit, dass es mal Probleme geben kann.

[miwie]

Also ich fahre schon seit Jahren durchgehend "testing".
Zugegeben gibt es ab und an kleinere Probleme, aber ich will es nicht mehr missen.

[Trollkirsche]

Kann ich eigentlich auch nach Upgrade von einem zum anderen System komplett das ganze home dir übernehmen? Bisher habe ich immer, um ein sauberes System zu erhalten, jedes Verzeichnis das ich migrieren wollte, auf das neue System vom Backup übernommen.

Das ist an sich ein ganz gutes Vorgehen., muss aber nun nicht unbedingt nach einem Upgrade gemacht werden.

Ja, da ich zurzeit immer das ganze OS neu installiert habe, war zur übernahme der Daten dies leider unumgänglich. Bei einem Upgrade sollte das sichern der Daten genügen, die sind ja nacher immer noch da.

Ich mache es so, dass ich von Zeit zu Zeit die Verzeichnisse durchgehe und Konfigurationsdateien / Verzeichnisse von Programmen, die nicht mehr vorhanden sind, lösche. Das sind aber immer nur die für mich oder den jeweiligen Nutzer angelegten Konfigs.

Klingt gut. Ansonten immer noch lieber ein paar Altlasten als aus Versehen mal die zertifikate vergessen...

System-weit sind diese Dateien in der Regel in /etc. Nur dort werden sie auch bei einem Upgrade überschrieben. Deshalb kann es sinnvoll sein, auch dieses Verzeichnis zu sichern, wenn man dort systemweite Veränderungen vorgenommen hat.

Beissen sich die config Dateien nicht beim Release einer neuen Version? Es kann ja sein das dann Programme über eine andere configdatei gesteuert werden, die jedoch dann gleich hiesse? Oder bleiben die Dateien in /etc in jedem Falle immer gleich?

Das Root- Verzeichnis sichere ich nie. Wenn man da wirklich etwas zerschossen hat (ist mir in den ganzen Jahren erst einmal passiert), ist der Aufwand, einen Fehler zu finden, in der Regel um ein Vielfaches größer, als eine Neuinstallation.

Ich hab im root verzeichnis paar scripte zur Automatisierung der backups per rsync. Diese möchte ich in jedem Falle mitsichern. Es geht mir also weniger um die einstellungen des Benutzers root als um die scripte, die von root aus gestartet werden und sich in dem verzeichnis befinden.

Was ich noch sichere ist mein /opt. Diese Verzeichnis ist bei mir komplett von einem System zu einem beliebigen anderen übertragbar. Da dort nur Programme sind, die sich ohne weitere Installation starten lassen ( also Firefox , Thunderbird, FreeFileSync, Master-PDF-Editor usw).
Die Desktop-Dateien für diese Programme befinden sich eh in meinem /home, sind also nach einer eventuellen Neuinstallation
sofort wieder verfügbar. Ich portiere das /opt sogar in VM's, wenn ich die Programme dort brauche.

Gute Idee.

Nochmal zu den Releases:

Ich habe mich noch zu Jessies Zeiten entschieden, in meiner sources.list ausschließlich Testing zu haben.
Vorteil: Man hat quasi ein "rolling Release".
Bei einem Release - Wechsel geht es im gewohnten täglichen "full-upgrade" Modus weiter wie immer bei Testing.
Das ist ein Klick auf einen Starterund gut ist.

Ernsthafte Probleme habe ich die ganzen Zeit nur einmal gehabt. Aber wenn ich sehe was Nutzer teilweise für Probleme mit der
Stable Version haben, fahre ich damit sehr gut. Abgesehen von ein bisschen mehr Upgrade - Arbeit.

Wenn man sich entscheidet, Testing zu fahren sollte man das berücksichtigen, genauso wie die Möglichkeit, dass es mal Probleme geben kann.

Hast du irgendeine gute Anleitung oder weitergehende Tipps, wie ich so ein Update vollziehen kann?
Muss ich in der sources.list dann die Einträge zb von:

deb http://ftp.debian.org/debian/ stretch main

zu

deb http://ftp.debian.org/debian/ testing main

ersetzen?

Welche weiteren Schritte sind ansonsten noch notwendig?

Vielen Dank schonmal für die Hilfe!

[guennid]

Ich schätze, das ist mit einiger Sicherheit nicht der komplette Inhalt deiner sources.list (mal ganz abgesehen vom möglichen Inhalt von /etc/apt/sources.list.d) und ohne den zu kennen, macht es wenig Sinn, mehr als das bereits Gesagte zu sagen.

Vielleicht eins noch: Entscheide dich, ob du entweder die Begriffe stable und testing oder die jeweiligen alias-Begriffe in der sources.list nutzen willst. Letzteres schützt alle außer willy vor unliebsamen Überraschungen, aber der weiß auch, was er tut.

Durch heftiges Nachdenken über Release-Wechsel sollte es sich aber auch jedem anderen offenbaren.

Grüße, Günther

[MSfree]

Kann ich eigentlich auch nach Upgrade von einem zum anderen System komplett das ganze home dir übernehmen? Bisher habe ich immer, um ein sauberes System zu erhalten, jedes Verzeichnis das ich migrieren wollte, auf das neue System vom Backup übernommen.

Jein. Es geht zwar meistens gut, kann aber in Einzelfällen in die Hose gegen.

Ich hatte mal Probleme mit meinem ~/.kde Verzeichnis. Das nach dem Upgrade neuere KDE wollte mit den alten Einstellungen nichts anfangen und ist abgestürzt. Löschen und neu anlegen lassen hat das Problem zwar behoben, ich mußte dann aber alles, was ich für mich an KDE ändere (Hotkeys, Focus-on-Mouse, Desktoptheme, Farben...), wieder einstellen.

Ich habe in meinem Home aber mehr als nur ein paar Systemdateien. Da sind z.B. auch die Arbeitsverzeichnisse für den Quelltext meiner eigenen Softwareentwicklungen. Sowas kann man natürlich probllemlos übernehmen. Obwohl ich hier auch noch doppelt und dreifach abgesichert bin, weil mein Quellcode auf einem Server mit Subversion (ich war bisher zu faul, auf GIT zu migirieren) verwaltet wird und der Inhalt des SVN-Servers zusätzlich auf ein NAS gesichert ist.

[willy4711]

Letzteres schützt alle außer willy vor unliebsamen Überraschungen, aber der weiß auch, was er tut.

Nö -- auch nicht immer (oder vielleicht : selten) aber wer stolpert und wieder aufsteht, lernt beim nächsten Mal besser aufzupassen

Ist ja wohl nicht OT, wenn hier auch über das "Verfahren selbst" mal was gesagt wird

Der Thread hat mich natürlich animiert, gleich erst mal in einer VM ein Dist Upgrade auf Buster zu fahren.
Diesmal auf eine andere Art und Weise: Mit aptitude.

Es gibt ja die allgemeine Empfehlung erst mal nach dem Ändern der Sourcen ein

Code: Alles auswählen

apt update && apt upgrade

und anschließend

Code: Alles auswählen

apt full-upgrade

durchzuführen.
Da ich den praktischen Nährwert dieses Verfahrens noch nie so richtig begriffen hatte, wollte ich das diesmal in der Gnome VM
mit Aptitude durchführen.

Also drauflos:

Code: Alles auswählen

aptitude update && aptitude upgrade

Ergebnis: 30 Minuten 50 % Prozessorlast von der VM und ein mir nicht nachvollziehbares Sortieren von Paketen in Hold / Zurückgestellt und ich weis nicht noch was alles.
Hab das dann abgebrochen und mit

Code: Alles auswählen

aptitude full-upgrade

ein zufriedenstellendes Ergebnis gehabt, incl eines wunderschönen Protokolls: 40694

Frage also:
Ich kann mich dunkel erinnern, igendwann das analog dem oben Geschilderten mit apt gemacht zu haben. Das ging aber ratz batz.

Macht Aptitude da etwas (im Hintergrund) anders wodurch diese Extreme Prozessorbelastung und Dauer zu erklären ist ?

Über eine schlüssige Erklärung warum man unbedingt ein upgrade vor einem full-upgrade machen soll wäre ich auch dankbar.

[guennid]

Ob man unbedingt ein upgrade vor dem dist-/full-upgrade machen soll, weiß ich gar nicht, aber zumindest beim Release-Wechsel ist es wohl so, dass du dadurch sicherstellst, auf dem letzten Stand des Releases zu sein, von dem du weg willst. Dadurch soll wohl gewährleistet sein, dass der mit dist-/full-upgrade angestoßene Release-Wechsel möglichst problemfrei durchläuft. Ich nehme an, genau das wird geprüft, bevor ein Release freigegeben wird. Upgrade benutze ich nie. Wenn ich einen Release-Wechsel plane, mach' ich mit apt-get vorher eine dist-upgrade für das alte System. Wenn du aber sowieso gehaltene Pakete in der alten Version hast, dann musst du vorher selbst schauen, inwieweit das dist-/full-upgrade auch beim Release-Wechsel damit klarkommt und geeignete Maßnahmen vorher ergreifen. Der Parameter „-s“ gab mir dafür bisher erschöpfend Auskunft. Ob synaptic das in diesem Falle (hold-/Fremd-Pakete) ohne dein Zutun von sich aus schafft, wage ich zu bezweifeln.

Aber nun ja, wenn man so'n Ewigkeits-Testing-Fahrer ist, kriegt man das vielleicht nicht so mit, weiß ich halt nicht.

Nebenbei: soweit ich weiß, ist es für ein full-/dist-upgrade ziemlich egal, welches cli-Werkzeug du dafür benutzt. Die Stärken aptitudes liegen anderswo - hab' ich mir sagen lassen.

Grüße, Günther

[novalix]

Ein einfaches "upgrade" nach Änderung der sources.list auf ein neues Release erneuert auschließlich die Pakete, die bereits installiert sind.
Ein dist- oder full-upgrade spielt auch neu entstandene Abhängigkeiten mit ein und löscht ggf. vorher installierte Abhängigkeiten, die jetzt mit den neuen Paketen in Konflikt stehen.

Deshalb ist es sehr gut möglich, dass die hohe CPU-Last, die @Willy bei dem upgrade beobachtet hat, auf den resolver von aptitude zurückzuführen ist. Bei einem reinen upgrade entsteht eben vorübergehend ein Mischsystem und "eigentlich" ist auch eher davon abzuraten diesen halben Schritt zu gehen.
In der Vergangenheit hat es aber auch schon Release-Wechsel gegeben, bei denen dieses vorsichtige Verfahren in bestimmten Konstellationen angeraten war.
Solche ehemaligen Erfordernisse tradieren sich schon mal durch die Foren, ohne dass es dazu noch eine substantielle Begründung gibt.

Im Zweifel sollte man sich, so es sie denn schon gibt, immer erst mal in den Release-Notes schlau machen, welches Frontend zum Upgrade empfohlen wird.
Das war vor einiger Zeit (iirc sarge-etch, etch-lenny) mal aptitude, weil es zu der Zeit den viel besseren resolver besaß.

Beim letzten Release-Wechsel von jessie auf stretch konnte das aptitude aus jessie (mit dem man das upgrade ja durchführt) aber in bestimmten Konstellationen scheitern, deshalb war die offizielle Empfehlung auch apt, apt-get zu benutzen.*
Ich würde heute davon ausgehen, dass solche dist-upgrades von den Entwicklern hauptsächlich mit apt, apt-get getestet werden, weil das die üblichen Frontends sind und der Vorsprung, den aptitude dereinst beim auflösen von Abhängigkeiten hatte, längst nicht mehr so gewaltig ist.

Allgemein ist zu der Frage "stable oder testing" noch anzumerken: Kommt darauf an.
Für eine stärker server-orientierte Installation ist die Antwort zunächst einmal ganz klar "stable".
Wobei in Zeiten des freeze wie heuer, es durchaus sinnvoll sein kann auch schon zu testing zu greifen. Dann aber logischerweise als Vorgriff auf das kommende stable, also mit dem Codename (z.B. buster) in der sources.list nicht mit "testing".
Auch für Desktop-Clients darf man durchaus die "konservative" Herangehensweise empfehlen, wenn nicht klar ist, dass der User entsprechende Anforderungen an die Aktualität bestimmter Softwarekomponenten hat, oder ein ausgesprochenes Spielkalb ist.

*Eine andere Möglichkeit wäre es gewesen, zunächst nur das Paketmanagement auf den neuen Stand zu bringen, wie es bei einem Release-Wechsel (squeeze-wheezy?) ja auch schon mal erforderlich war.

[RobertDebiannutzer]

So gut ist testing doch eigentlich gar nicht für die alltägliche Nutzung:

Testing hat keine Betreuung durch das Sicherheitsteam -> Sicherheitsupdates kommen verzögert:

Please note that security updates for "testing" distribution are not yet managed by the security team. Hence, "testing" does not get security updates in a timely manner. You are encouraged to switch your sources.list entries from testing to stretch for the time being if you need security support. See also the entry in the Security Team's FAQ for the "testing" distribution.

Quelle: https://www.debian.org/releases/testing/
oder:

Compared to stable and unstable, next-stable testing has the worst security update speed. Don't prefer testing if security is a concern.

Quelle: https://wiki.debian.org/DebianTesting
Man kann auch z.B. den Verlauf der Updates von firefox-esr mitverfolgen und sich selber anhand eines Beispiels ein Bild machen: https://tracker.debian.org/pkg/firefox-esr bzw. https://www.debian.org/security/
Am 24.03. z.B. wurde das Update auf "60.6.1esr-1~deb9u1" für stretch bekanntgegeben: https://www.debian.org/security/2019/dsa-4417
Erst am 01.04. wurde die Version in testing auf 60.6.1esr-1 geupdated.

Des Weiteren gibt es - wie @willy4711 erwähnte:

gewohnten täglichen "full-upgrade" Modus

- sehr häufig Updates. Das kann man auch als unnötigen Festplatten-Verschleiß sehen, wenn es keine Security-Updates sind?

Zudem kommt es natürlich auf persönliche Präferenz an. Braucht man nicht aus bestimmten Gründen aktuelle Software, ist man vielleicht sogar froh, wenn sich nicht häufig etwas ändert. Ich habe einige Leute im Bekanntenkreis, bei denen bin ich froh, dass die nicht ständig mit neuen Versionen von z.B. libreoffice konfrontiert werden...

Ich möchte noch darauf hinweisen, dass ich persönlich eigentlich schon eher ein Kandidat für testing wäre, aber die Versorgung mit Sicherheitsupdates und die häufigen nicht-Sicherheitsupdates finde ich nicht optimal. Optimal wäre ein halbjähriger Release-Zyklus von stable. Aber das macht Debian aus bestimmten (auch nachvollziehbaren) Gründen eben nicht. Und alternative Distributionen hätten (zumindest für mich) ihre eigenen Nachteile.

[slu]

Man kann auch z.B. den Verlauf der Updates von firefox-esr mitverfolgen und sich selber anhand eines Beispiels ein Bild machen: https://tracker.debian.org/pkg/firefox-esr bzw. https://www.debian.org/security/
Am 24.03. z.B. wurde das Update auf "60.6.1esr-1~deb9u1" für stretch bekanntgegeben: https://www.debian.org/security/2019/dsa-4417
Erst am 01.04. wurde die Version in testing auf 60.6.1esr-1 geupdated.

Es ist so schade das im Freez die Sicherheitsupdates nicht schneller kommen, so kann ich Buster nicht auf die Workstation los lassen.

[OrangeJuice]

Auf meinen Desktop läuft seit längerer Zeit Debian Sid Gnome. Bisher hatte ich damit sehr wenig Probleme. Die Sicherheitspatches sind dort ja auch schon in den neusten Versionen enthalten bzw. Fehler werden schnell behoben. Testing hatte ich mal verwendet, war aber deutlich hinter Sid, würde ich nicht verwenden.

[Trollkirsche]

So gut ist testing doch eigentlich gar nicht für die alltägliche Nutzung:

Testing hat keine Betreuung durch das Sicherheitsteam -> Sicherheitsupdates kommen verzögert:

Please note that security updates for "testing" distribution are not yet managed by the security team. Hence, "testing" does not get security updates in a timely manner. You are encouraged to switch your sources.list entries from testing to stretch for the time being if you need security support. See also the entry in the Security Team's FAQ for the "testing" distribution.

Quelle: https://www.debian.org/releases/testing/
oder:

Compared to stable and unstable, next-stable testing has the worst security update speed. Don't prefer testing if security is a concern.

Quelle: https://wiki.debian.org/DebianTesting
Man kann auch z.B. den Verlauf der Updates von firefox-esr mitverfolgen und sich selber anhand eines Beispiels ein Bild machen: https://tracker.debian.org/pkg/firefox-esr bzw. https://www.debian.org/security/
Am 24.03. z.B. wurde das Update auf "60.6.1esr-1~deb9u1" für stretch bekanntgegeben: https://www.debian.org/security/2019/dsa-4417
Erst am 01.04. wurde die Version in testing auf 60.6.1esr-1 geupdated.

Des Weiteren gibt es - wie @willy4711 erwähnte:

gewohnten täglichen "full-upgrade" Modus

- sehr häufig Updates. Das kann man auch als unnötigen Festplatten-Verschleiß sehen, wenn es keine Security-Updates sind?

Zudem kommt es natürlich auf persönliche Präferenz an. Braucht man nicht aus bestimmten Gründen aktuelle Software, ist man vielleicht sogar froh, wenn sich nicht häufig etwas ändert. Ich habe einige Leute im Bekanntenkreis, bei denen bin ich froh, dass die nicht ständig mit neuen Versionen von z.B. libreoffice konfrontiert werden...

Ich möchte noch darauf hinweisen, dass ich persönlich eigentlich schon eher ein Kandidat für testing wäre, aber die Versorgung mit Sicherheitsupdates und die häufigen nicht-Sicherheitsupdates finde ich nicht optimal. Optimal wäre ein halbjähriger Release-Zyklus von stable. Aber das macht Debian aus bestimmten (auch nachvollziehbaren) Gründen eben nicht. Und alternative Distributionen hätten (zumindest für mich) ihre eigenen Nachteile.

Mist!

Ich habe Testing auf dem Nas installiert. Würdest du mir empfehlen aus Sicherheitsgründen alles nochmal neu zu installieren und die stable Version zu verwenden? Das gäbe zwar eine Menge Arbeit, aber wenns nötig ist...

[TomL]

Ich habe Testing auf dem Nas installiert. Würdest du mir empfehlen aus Sicherheitsgründen alles nochmal neu zu installieren und die stable Version zu verwenden? Das gäbe zwar eine Menge Arbeit, aber wenns nötig ist...

Nein, das ist nicht nötig... ich glaube, Du machst Dich jetzt völlig unnötig verrückt. Buster ist seit Februar Freeze und seit anfang März Full Freeze. Das ist jetzt nicht mehr "klassisch Testing", sondern imho schon viel mehr "echtes Buster". Es gibt hier genügend Leute, die fahren durchweg Testing und haben keine großen Security-Probleme. Ich weiss ja nicht, welche Services auf Deinem NAS laufen, aber wenn da nicht was wirklich sicherheits-kritisches mit offenen Schnittstellen zum Internet läuft, würde ich gar nix ändern, sondern Buster einfach seinen Job machen lassen. Ich würde halt nur die sources.list von "testing" auf "buster" ändern, damit es eben nach dem Release ein echtes "stable" wird.

jm2c

[Trollkirsche]

Ich habe Testing auf dem Nas installiert. Würdest du mir empfehlen aus Sicherheitsgründen alles nochmal neu zu installieren und die stable Version zu verwenden? Das gäbe zwar eine Menge Arbeit, aber wenns nötig ist...

Nein, das ist nicht nötig... ich glaube, Du machst Dich jetzt völlig unnötig verrückt. Buster ist seit Februar Freeze und seit anfang März Full Freeze. Das ist jetzt nicht mehr "klassisch Testing", sondern imho schon viel mehr "echtes Buster". Es gibt hier genügend Leute, die fahren durchweg Testing und haben keine großen Security-Probleme. Ich weiss ja nicht, welche Services auf Deinem NAS laufen, aber wenn da nicht was wirklich sicherheits-kritisches mit offenen Schnittstellen zum Internet läuft, würde ich gar nix ändern, sondern Buster einfach seinen Job machen lassen. Ich würde halt nur die sources.list von "testing" auf "buster" ändern, damit es eben nach dem Release ein echtes "stable" wird.

jm2c

Kann ich den Eintrag bereits jetzt ändern?

Was hälst du davon?
https://raphaelhertzog.com/2010/12/20/5 ... -its-name/

Wie ein anderer Forumsteilnehmer hier meinte wird ja SID auch recht häufig mit Sicherheitspatches versorgt. Im Artikel ist zu entnehmen das die Patches dann jedoch nicht vom Team kommen, sondern vom Maintainer des Packages. Dennoch bekommt es dadurch mehr Patches als Testing.

Wäre für den Desktop glaubich durchaus eine überlegenswerte Alternative.

Offene Dienste im Netz würde ich nur über eine DMZ anbieten, fände es gerade mit meinen momentanen Kenntnissen nicht sehr weise, dies zu tun. Auch sonst sollte man meines Wissens nach keine Dienste ins Internet zulassen, die sich im LAN selbst befinden.

[MSfree]

Kann ich den Eintrag bereits jetzt ändern?

Ja.

Wie ein anderer Forumsteilnehmer hier meinte wird ja SID auch recht häufig mit Sicherheitspatches versorgt.

SID ist aber noch einmal ein ganze Hausnummer experimenteller als Testing. Da ist öfter mal was kaputt und auf ein vollständig funktionierendes System kann man sich nicht verlassen. Das ist wirklich nur was für Leute, die wissen, wie man mit solchen Problemen umgeht.

[Trollkirsche]

Kann ich den Eintrag bereits jetzt ändern?

Ja.

Wie ein anderer Forumsteilnehmer hier meinte wird ja SID auch recht häufig mit Sicherheitspatches versorgt.

SID ist aber noch einmal ein ganze Hausnummer experimenteller als Testing. Da ist öfter mal was kaputt und auf ein vollständig funktionierendes System kann man sich nicht verlassen. Das ist wirklich nur was für Leute, die wissen, wie man mit solchen Problemen umgeht.

Wenn ich das richtig verstehe dann ist es ebenfalls nicht angeraten, die jeweiligen Repositorys der Versionen miteinander zu mischen?

Wenn ich von der Stretch stable auf buster updaten will, muss ich hierzu lediglich die einträge in der apt/sources.list ändern zu buster main und ein apt-get update, apt-get upgrade mit anschliessendem dist-ugprade durchführen?

Habe das noch nie gemacht und möchte anstelle immer alles neu installieren meinen Handlungsspielraum erweitern

[novalix]

Wenn ich das richtig verstehe dann ist es ebenfalls nicht angeraten, die jeweiligen Repositorys der Versionen miteinander zu mischen?

Das ist zwar möglich (Stichwort: apt pinning), sollte allerdings nur in Angriff genommen werden, wenn die Erfordernisse keine geeignetere Lösung zulassen. Ein Mischen der Zweige ohne pinning tötet Katzenbabies.

Wenn ich von der Stretch stable auf buster updaten will, muss ich hierzu lediglich die einträge in der apt/sources.list ändern zu buster main und ein apt-get update, apt-get upgrade mit anschliessendem dist-ugprade durchführen?

Ja. Den Schritt "apt-get upgrade" würde ich aber weglassen (s. meine Einlassungen weiter oben im Thread).

Habe das noch nie gemacht und möchte anstelle immer alles neu installieren meinen Handlungsspielraum erweitern

Das ist eine vernünftige Vornahme. Es gibt zwar einige Leute, die aus unterschiedlichen Gründen eine Neuinstallation bevorzugen, aber der dist-upgrade ist unter Debian üblicherweise recht problemlos zu bewerkstelligen und letztlich einfacher.
Es gilt zu beachten, dass ausreichend Festplattenkapazität vorhanden ist (vor allen Dingen /var wächst bei einem dist-upgrade schon mal ordentlich an) und dass man sich möglichst viele Informationen über zu erwartende Änderungen beschafft.
Das tool apt-listchanges listet in der Standardkonfiguration nach dem Herunterladen der Paketdateien die als "NEWS*" gekennzeichneten Dokumentationen der Pakete. Darin befinden sich oft wichtige Hinweise über Änderungen, die ggf. ein händisches Zutun des users/admins erfordern. So etwas immer aufmerksam lesen.
Man kann sich über das tool auch sämtliche Changelog-Dateien anzeigen lassen, aber das ist sehr, sehr viel Holz bei einem dist-upgrade.
Je nach Installation kann so ein dist-upgrade einige Zeit in Anspruch nehmen, und die Konfigurationsroutinen wollen mitunter interaktiv betüddelt werden. Von daher sollte man so ein Release-Wechsel nicht mal eben zwischen Tür und Angel anstoßen.
Es ist kein Muss, aber eine gute Idee den ganzen Prozess auf einem virtuellen Terminal durchzuführen, falls es mal mit der Grafik knarzt.

[sys_op]

Also ich fahre schon seit Jahren durchgehend "testing".
Zugegeben gibt es ab und an kleinere Probleme, aber ich will es nicht mehr missen.

Hi
Mit welchem Vorteil zu stable? Ich meine, was bringt es wirklich? Ich überlege auch auf Testing zu wechseln, bin aber wegen des "ab und ans" noch im Wickelwackel....

[MSfree]

Wenn ich das richtig verstehe dann ist es ebenfalls nicht angeraten, die jeweiligen Repositorys der Versionen miteinander zu mischen?

Richtig. Da sollte man grundsätzlich die Finger von lassen. Wenn man wirklich mal eine bestimmte Software in einer neueren Version braucht als die, die in dem Releasezweigliegt, den man installiert hat, sollte man zuerst mal in den Backports schauen. Da gibt es zum installierten Debian-Release sehr oft aktuellere Versionen.

Release-Mixing führt in den meisten Fällen zu heillosem Durcheinander, das irgendwann nicht mehr wartbar ist.

Wenn ich von der Stretch stable auf buster updaten will, muss ich hierzu lediglich die einträge in der apt/sources.list ändern zu buster main und ein apt-get update, apt-get upgrade mit anschliessendem dist-ugprade durchführen?

Ich empfehle da immer zuerst ein

Code: Alles auswählen

apt-get (dist-)upgrade -s

Das simuliert das Upgrade nur und zeigt an, was alles instlliert werden würde. Je nach dem, wie groß der darauf folgende Schrecken ist, kann man dann das -s weglassen oder die sources.list rückgängig machen.

[willy4711]

Ich möchte nochmal darauf hinweisen, das nach der Anpassung der sources.list auf Buster es aus meiner Sicht sinnlos, wenn nicht sogar
kontraproduktiv ist, zuerst ein apt upgrade zu fahren.
Aus der Manpage:

upgrade (apt-get(8))
upgrade wird verwendet, um verfügbare Upgrades für alle derzeit auf
dem System installierten Pakete von den in der sources.list(5)
konfigurierten Quellen zu installieren. Neue Pakete werden
installiert, falls dies nötig ist, um Abhängigkeiten zu erfüllen,
existierende werden jedoch nie entfernt. Falls das Upgrade für ein
Paket verlangt, dass ein installiertes Paket entfernt wird, wird
dieses Upgrade nicht durchgeführt.

Das heißt doch das bei einem Dist - Upgrade ein heilloses Chaos entsteht, das hinterher von einem full-upgrade bzw. dist-upgrade (gleichwertig)
dann aufgelöst werden muss.

full-upgrade (apt-get(8))
full-upgrade verrichtet die Funktion von »upgrade«, wird aber auch
installierte Pakete entfernen, falls dies erforderlich ist, um ein
Upgrade des Systems als Ganzes durchzuführen.

Aus meinem apt dist-upgrade vom Sonntag:

Code: Alles auswählen

Will install 1703 packages, and remove 163 packages. 963 MB of disk space will be used

Das ist praktisch eine komplette Neuinstallation.

Aus meiner Sicht wäre folgende Vorgehensweise richtig

Vor der Änderung der sources.list:

Um das System auf den neusten Stand zu bringen:

Code: Alles auswählen

apt update && apt full-upgrade

dann um den Cache von nicht mehr gebrauchten Zeugs zu leeren:

Code: Alles auswählen

apt clean

sources.list ändern

dann (Angsthasen dürfen auch das von MSfree empfohlene apt-get (dist-)upgrade -s durchführen )

Code: Alles auswählen

apt update && apt full-upgrade

Kaffee trinken (wichtig )

Neustart und sich wahrscheinlich freuen.

Alte Kernel löschen, und eventuell irgendwelche Backups einspielen.