apt-get upgrade rückgängig machen

Post by Sven Rahlfs
Hallo Leutz,
kann man das letzte, mit apt-get upgrade gemachte, upgrade irgendwie
rückgängig machen?

NEIN, aber wenn welche Pakete upgedatet wurden kannste sie mit

apt-get install <paket1>=<Version> <paket2>=<version> ...

installieren/downgraden, VORAUSGESETZT, du hast noch die alten DEBs

Solltest Du nicht wissen was upgegraded wurde, führe man das
angehängte BASH-Script aus :-)

Post by Sven Rahlfs
Viele Grüße
Sven

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/88452356 67100 Strasbourg/France IRC #Debian (irc.icq.com)

Andreas Pakulat

2005-02-07 22:20:11 UTC

Post by Sven Rahlfs
Hallo Leutz,
kann man das letzte, mit apt-get upgrade gemachte, upgrade irgendwie
rückgängig machen?

Nein.

Post by Sven Rahlfs
Konkret geht es darum das ich ein apt-get upgrade gemacht habe und dabei
auch apache und PHP geupdatet wurde und plötzlich geht ein
Internetprojekt nicht mehr traurig Und ich habe keinen schimmer woran es
liegen könnte da andere PHP Projekte nach wie vor problemlos laufen!

1. Anlaufpunkt wären die Changelogs zu apache und php. Dort sind
normalerweise alle Änderungen verzeichnet. Damit kannst du bestimmt
herausfinden, welche Funktion die das Projekt benutzt, nun nicht mehr
funktioniert/anders funktioniert/nicht mehr unterstützt wird. Man
sollte als Sysadmin schon etwas Vorsicht walten lassen, wenn man auf
Produktionsservern Software-Upgrades einspielt.

Andreas
--
Think twice before speaking, but don't say "think think click click".

Norbert Tretkowski

2005-02-07 22:20:12 UTC

Post by Sven Rahlfs
kann man das letzte, mit apt-get upgrade gemachte, upgrade irgendwie
rückgängig machen?

Nein, Downgrades werden nicht supported.

Norbert

Markus Heller

2005-02-08 00:40:09 UTC

Hallo Norbert,

Post by Norbert Tretkowski
Nein, Downgrades werden nicht supported.

vielleicht sollte die Community aber gerade an dieser Erweiterung arbeiten.
Standards wie ITIL schreiben fürs Release Management diesen Weg ganz explizit
vor. Wenn Debian für Großunternehmen als strategische OS-Variante attraktiv
werden soll, muß dieses Feature umgesetzt werden.

Viele Grüße
Markus

Andreas Pakulat

2005-02-08 10:00:16 UTC

Post by Markus Heller
Hallo Norbert,

Post by Norbert Tretkowski
Nein, Downgrades werden nicht supported.

Und wie soll man sowas bewerkstelligen? Da draussen gibts einige
Tausend Pakete, willst du ein downgrade zu _jeder_ früheren Version
unterstützen? Dann besorg mal fix einige 100 neue DM's und bezahle
die. Ein downgrade um eine minor oder bugfix-number geht ja oftmals
gut, aber Major-downgrades... Die Frage ist auch, wieso hat sich der
Admin nicht ausreichend informiert und wird nun von Fehlern
überrascht? Weiterhin: Wenn man Debians Philosophie folgt und in
Produktivumgebungen ausschliesslich stable einsetzt gibts nicht viele
Downgrades durchzuführen...

Andreas
--
Your mode of life will be changed for the better because of new developments.

Helmut Wollmersdorfer

2005-02-08 11:50:11 UTC

Post by Markus Heller

Post by Norbert Tretkowski
Nein, Downgrades werden nicht supported.

Und wie soll man sowas bewerkstelligen?

Indem
1) alle alten Versionen archiviert werden
2) die Abhängigkeiten genauer definiert werden
3) ein downgrade-not-possible Flag definiert wird (oder aus den
Abhängigkeiten erkannt wird), denn downgrade wird nicht immer möglich sein.

Post by Andreas Pakulat
Da draussen gibts einige
Tausend Pakete, willst du ein downgrade zu _jeder_ früheren Version
unterstützen?

Theoretisch möglich, aber halt riesiger Aufwand. Alleine schon Migration
bzw. Rück-Migration von Daten und Configs. Wünchenswert und
möglicherweise in der Grundfunktionalität nicht schwer zu realisieren
wär es jedenfalls. Ich hab mir z.B. mit Gnumeric 1.4.1 -> 1.4.2 einen
Bug http://bugzilla.gnome.org/show_bug.cgi?id=166606 eingehandelt, wo
ich gern wieder zurück wollte.

Post by Andreas Pakulat
Dann besorg mal fix einige 100 neue DM's und bezahle
die.

Den Platz für die Archive nicht vergessen.

Post by Andreas Pakulat
Die Frage ist auch, wieso hat sich der
Admin nicht ausreichend informiert und wird nun von Fehlern
überrascht?

Weil niemals alle Fehler bekannt oder austestbar sein können.
Shit happens.

Helmut Wollmersdorfer

Andreas Pakulat

2005-02-08 12:20:14 UTC

Post by Markus Heller

Post by Norbert Tretkowski
Nein, Downgrades werden nicht supported.

vielleicht sollte die Community aber gerade an dieser Erweiterung
arbeiten. Standards wie ITIL schreiben fürs Release Management diesen
Weg ganz explizit vor. Wenn Debian für Großunternehmen als strategische
OS-Variante attraktiv werden soll, muß dieses Feature umgesetzt werden.

Und wie soll man sowas bewerkstelligen?

Indem
1) alle alten Versionen archiviert werden

Existiert bereits - siehe snapshots.debian.org (IIRC)

Post by Helmut Wollmersdorfer
2) die Abhängigkeiten genauer definiert werden

Was heisst die Abhängigkeiten genauer definieren? Im Normalfall
sollten die Abhängigkeiten so weit wie möglich und so eng wie nötig
definiert werden. Nimm mal an jedes Paket hätte ein Depends
libc6=2.3.X, dann müssten tausende Pakete neu kompiliert werden, wenn
ein neues Bugfixrelease eingespielt wird. Keine sehr gute Idee.

Post by Helmut Wollmersdorfer
3) ein downgrade-not-possible Flag definiert wird (oder aus den
Abhängigkeiten erkannt wird), denn downgrade wird nicht immer möglich sein.

Dass würde vorraussetzen, dass jemand den Aufwand betreibt und das
downgrade testet... Wobei wir wieder bei der Manpower sind, die nunmal
begrenzt ist...

Post by Andreas Pakulat
Da draussen gibts einige
Tausend Pakete, willst du ein downgrade zu _jeder_ früheren Version
unterstützen?

Hole dir das alte deb aus dem APT-Cache oder von snapshots.debian.org
und installiere es mit dpkg -i, das geht immer. Danach das Paket auf
hold setzen bis eine neue Version existiert - mache ich momentan mit
knetfilter...

Post by Andreas Pakulat
Dann besorg mal fix einige 100 neue DM's und bezahle
die.

Den Platz für die Archive nicht vergessen.

Gibts ja schon, sicherlich nicht alle alten Versionen, aber wer will
schon ne Bash von bo oder hamm haben...

Post by Andreas Pakulat
Die Frage ist auch, wieso hat sich der
Admin nicht ausreichend informiert und wird nun von Fehlern
überrascht?

Weil niemals alle Fehler bekannt oder austestbar sein können.
Shit happens.

Klaro, deswegen macht man ja auch kein tägliches Upgrade auf
Produktionsmaschinen - da würde ich immer ein Testsystem vorhalten und
wenn dort nach X Tagen keine Fehler auftreten auf dem
Produktionssystem das Update machen... Ja ich bin mir klar darüber,
dass nicht jeder das Geld hat um 2 identische Maschinen vorzuhalten.
Andersrum macht man bei Produktionssystem jawohl eh nicht jedes
beliebige Upgrade mit....

Andreas
--
Your fly might be open (but don't check it just now).

Helmut Wollmersdorfer

2005-02-08 13:40:09 UTC

Post by Andreas Pakulat
Was heisst die Abhängigkeiten genauer definieren? Im Normalfall
sollten die Abhängigkeiten so weit wie möglich und so eng wie nötig
definiert werden.

ACK.

Post by Andreas Pakulat
Nimm mal an jedes Paket hätte ein Depends
libc6=2.3.X, dann müssten tausende Pakete neu kompiliert werden, wenn
ein neues Bugfixrelease eingespielt wird. Keine sehr gute Idee.

Wenn die libc6 abwärtskompatibel ist, dann nicht.

Post by Andreas Pakulat
Dass würde vorraussetzen, dass jemand den Aufwand betreibt und das
downgrade testet... Wobei wir wieder bei der Manpower sind, die nunmal
begrenzt ist...

Die Version x-1 wurde ja bereits getestet.
Ich kenn solche Anforderungen aus einem Grossrechenzentrum, wo ich an
der Entwicklung so eines Versionsmanagements ~1980 mitgearbeitet habe.
Die Anforderung war, alles was zu einer Programmdurchführung beigetragen
hat, 50 Jahre lang zurückverfolgen zu können, inkl. Sourcen, Macros,
Compile- und Link-Anweisungen etc. Zweite wichtige Anforderung war, dass
Arbeitsvorbereitung bzw. Operation bei Abnormalitäten selbständig
Version x-1 einsetzen darf, sofern dieses Feature nicht gesperrt war.

Das ist halt eine andere Situation, wo es ein Naheverhältnis zu
Entwicklern im eigenen Haus gibt, die einen guten Überblick über die
möglichen Auswirkungen haben.

Eine Distri hat da ein ganz anders gelagertes Problem - zigtausende
Benutzer, zigtausende Pakete, xx verschiedene Zielumgebungen, xx
Einsatzbereiche.

Post by Andreas Pakulat
Hole dir das alte deb aus dem APT-Cache oder von snapshots.debian.org
und installiere es mit dpkg -i, das geht immer. Danach das Paket auf
hold setzen bis eine neue Version existiert - mache ich momentan mit
knetfilter...

Danke, snapshots kannte ich nicht. Bei den vielen Abhängigkeiten von
Gnumeric probier ich das vorher aber lieber auf einer Testmaschine.
Und mit welchem Befehl setzt man ein Paket auf hold?

Post by Andreas Pakulat
Klaro, deswegen macht man ja auch kein tägliches Upgrade auf
Produktionsmaschinen - da würde ich immer ein Testsystem vorhalten und
wenn dort nach X Tagen keine Fehler auftreten auf dem
Produktionssystem das Update machen... Ja ich bin mir klar darüber,
dass nicht jeder das Geld hat um 2 identische Maschinen vorzuhalten.
Andersrum macht man bei Produktionssystem jawohl eh nicht jedes
beliebige Upgrade mit....

ACK. In meinem Fall hab ich einen gespiegelten Cluster, kann also vorher
einen Node abhängen, daran herumfummeln und ausprobieren, dann wieder
anhängen. Vorher probier ich natürlich auf Testmaschinen aus, aber die
sind von Hardware und Konfiguration nicht identisch - ist also keine
perfekte Garantie.

Helmut Wollmersdorfer

Michelle Konzack

2005-02-08 14:10:12 UTC

Post by Helmut Wollmersdorfer
Die Version x-1 wurde ja bereits getestet.
Ich kenn solche Anforderungen aus einem Grossrechenzentrum, wo ich an
der Entwicklung so eines Versionsmanagements ~1980 mitgearbeitet habe.

^^^^^
Wie viel/große Software hat es damals für das verwendete System gegeben ?

Post by Helmut Wollmersdorfer
Die Anforderung war, alles was zu einer Programmdurchführung beigetragen
hat, 50 Jahre lang zurückverfolgen zu können, inkl. Sourcen, Macros,

^^^^^^^^
Wenn sich seit den 80ern nichts verändert hätte, kein Problem...
Nur hat sich alleine Debian von SLINK auf SARGE versiebenfacht.

Das ganze in nur 5 Jahren

Post by Helmut Wollmersdorfer
Danke, snapshots kannte ich nicht. Bei den vielen Abhängigkeiten von
Gnumeric probier ich das vorher aber lieber auf einer Testmaschine.
Und mit welchem Befehl setzt man ein Paket auf hold?

aptitude

Und wie überprüfst Du das ?
Die meisten Fehler treten unter "reellen" Umgebungsbedingungen auf...

Mir vor 3 Jahren passiert mit PostgreSQL...

Post by Helmut Wollmersdorfer
Helmut Wollmersdorfer

Greetings
Michelle

Michelle Konzack

2005-02-08 15:00:13 UTC

Post by Helmut Wollmersdorfer
Und mit welchem Befehl setzt man ein Paket auf hold?

aptitude

Gibt es da keine Alternative zu dem Usability-Unding namens aptitude?
Etwas auf Eebne CLI (Command Line Interface)?

1) dpkg --get-selections >instal_pakete
2) nano instal_pakete
3) gewünschtes Paket von "install" auf "hold" editieren
4) dpkg --set-selections install_pakete

Helmut Wollmersdorfer

Greetings
Michelle

Markus Schulz

2005-02-08 17:40:14 UTC

Post by Helmut Wollmersdorfer
Und mit welchem Befehl setzt man ein Paket auf hold?

aptitude

Gibt es da keine Alternative zu dem Usability-Unding namens
aptitude? Etwas auf Eebne CLI (Command Line Interface)?

1) dpkg --get-selections >instal_pakete
2) nano instal_pakete
3) gewünschtes Paket von "install" auf "hold" editieren
4) dpkg --set-selections install_pakete

Das geht aber einfacher:
echo "<Paketname> hold" | dpkg --set-selections

Markus Schulz

Helmut Wollmersdorfer

2005-02-08 15:00:17 UTC

^^^^^
Wie viel/große Software hat es damals für das verwendete System gegeben ?

400 Entwickler, 140 Projekte, bis zu 10.000 Programme (= gelinkte
binaries) pro Projekt, in einem Projekt ~2.500 Änderungen pro Jahr.
System- und Standard-SW war anderer Kaffee. PCs gab's noch nicht.

Post by Helmut Wollmersdorfer
Die Anforderung war, alles was zu einer Programmdurchführung beigetragen
hat, 50 Jahre lang zurückverfolgen zu können, inkl. Sourcen, Macros,

^^^^^^^^
Wenn sich seit den 80ern nichts verändert hätte, kein Problem...
Nur hat sich alleine Debian von SLINK auf SARGE versiebenfacht.
Das ganze in nur 5 Jahren

Wachstumsraten von 30%-50% pro Jahr waren damals auch normal. Das war so
und wird wohl so bleiben.

Post by Helmut Wollmersdorfer
Und mit welchem Befehl setzt man ein Paket auf hold?

aptitude

Gibt es da keine Alternative zu dem Usability-Unding namens aptitude?
Etwas auf Eebne CLI (Command Line Interface)?

Post by Michelle Konzack
Und wie überprüfst Du das ?
Die meisten Fehler treten unter "reellen" Umgebungsbedingungen auf...
Mir vor 3 Jahren passiert mit PostgreSQL...

Deswegen testet man auch möglichst realitätsnahe. Und man testet auch
Fälle, die unter rellen Bedingungen unwahrscheinlich sind. Je nach
Qualtätserfordernis halt.

Helmut Wollmersdorfer

Andreas Pakulat

2005-02-08 14:20:11 UTC

Post by Andreas Pakulat
Was heisst die Abhängigkeiten genauer definieren? Im Normalfall
sollten die Abhängigkeiten so weit wie möglich und so eng wie nötig
definiert werden.

ACK.

Wenn die libc6 abwärtskompatibel ist, dann nicht.

Naja gut zugegebenermassen nicht komplett rekompiliert werden, aber
das Paket muss neu geschnürt werden, insbesondere sh-libs muss erneut
aufgerufen werden, damit die Depends upgedatet werden. Ansonsten würde
apt-get install libc6 dir sämtliche Programme die davon abhängen
deinstallieren.

Post by Andreas Pakulat
Dass würde vorraussetzen, dass jemand den Aufwand betreibt und das
downgrade testet... Wobei wir wieder bei der Manpower sind, die nunmal
begrenzt ist...

Die Version x-1 wurde ja bereits getestet.

Das meinte ich nicht, sondern, dass Leute testen ob man von x zu x-1
einfach zurückkehren kann. Auch das muss getestet werden - können die
Configfiles bestehen bleiben, was ist wenn der Admin an den Config's
rumgeschraubt hat _nachdem_ das Update auf x vollzogen wurde (ebend
weil Probleme auftauchten und er diese lösen wollte)...

Post by Helmut Wollmersdorfer
Eine Distri hat da ein ganz anders gelagertes Problem - zigtausende
Benutzer, zigtausende Pakete, xx verschiedene Zielumgebungen, xx
Einsatzbereiche.

Ebend, deswegen ist sowas bei Debian absolut unpraktisch - wenn die
Maintainer sowas supporten müssten wären wir jetzt noch bei hamm,
schätze ich ;-)

Danke, snapshots kannte ich nicht. Bei den vielen Abhängigkeiten von
Gnumeric probier ich das vorher aber lieber auf einer Testmaschine.
Und mit welchem Befehl setzt man ein Paket auf hold?

echo paketname hold > dpkg --set-selections, oder mittels
/etc/apt/preferences. Für knetfilter sieht das so aus:

#Pinning knetfilter until we have 3.3.1-2 which solves the 292176 bug
Package: knetfilter
Pin: version 3.1.1-1
Pin-Priority: 990

Die Priorität eventuell noch erhöhen (falls irgendwas anderes > 990
hat -> siehe apt-cache policy). Damit kannst du ein Paket auf einer
bestimmten Version festhalten, mehr Infos in man apt_preferences.

Andreas
--
Don't look back, the lemmings are gaining on you.

Markus Heller

2005-02-08 17:00:19 UTC

Hallo Andreas,

Post by Helmut Wollmersdorfer
2) die Abhängigkeiten genauer definiert werden

schon klar. Das Problem liegt aber nicht bei einem Gesamtrelease mit einer
konsistenten Dependency-Landschaft, sondern wenn man die "dpkg
--force-all"-Variante irgendwann mal verwendet hat. Deshalb hab ich ja auch
geschrieben, daß ein Release-Definitions-Tool hier ziemlich strikt sein
sollte. Denn ein Downgrade wird nur dann sauber funktionieren können, wenn
der Upgrade ordnungsgemäß gelaufen ist. Ansonsten begibt man sich IMHO auf
gefährliches Terrain.

Post by Helmut Wollmersdorfer
3) ein downgrade-not-possible Flag definiert wird (oder aus den
Abhängigkeiten erkannt wird), denn downgrade wird nicht immer möglich sein.

Dass würde vorraussetzen, dass jemand den Aufwand betreibt und das
downgrade testet... Wobei wir wieder bei der Manpower sind, die nunmal
begrenzt ist...

ich meine, das sollte nicht nötig sein.

Die Philosophie im professionellen IT-Management nach ITIL ist in etwa, daß
man Softwarekonstellationen zentral testet und dann ein Gesamt-Release
zusammenstellt, bei dem man mit geringstmöglichem Crash-Risiko die Freigabe
verantworten kann. Und wenn doch was schiefgeht, sollte man mit einem
definierbaren Aufwand auch bei hochskalierten Szenarien (beispielsweise die
14000 Linux-Kisten der Stadtverwaltung München) zum vorherigen Softwarestand
zurückkehren können... Schon aus diesem Grund kann man es sich nicht leisten,
auf jedem Rechner eine unterschiedliche Softwarekonstellation zu haben. Das
Entwicklungsziel darf nicht der private Desktop in einer Minimalumgebung
sein, sondern wir müssen unser Softwaremanagement für derart große
Installationen fit machen, wenn "wir" als Linux-Community da ernsthaft rein
wollen.

Viele Grüße
Markus

Michael Bienia

2005-02-10 00:50:07 UTC

Post by Helmut Wollmersdorfer
Indem
1) alle alten Versionen archiviert werden

Existiert bereits - siehe snapshots.debian.org (IIRC)

Die korrekte URL ist http://snapshot.debian.net

Michael

Markus Heller

2005-02-08 16:40:12 UTC

Hallo Andreas,

[Downgrades]

Post by Andreas Pakulat
Und wie soll man sowas bewerkstelligen? Da draussen gibts einige
Tausend Pakete, willst du ein downgrade zu _jeder_ früheren Version
unterstützen? Dann besorg mal fix einige 100 neue DM's und bezahle
die. Ein downgrade um eine minor oder bugfix-number geht ja oftmals
gut, aber Major-downgrades... Die Frage ist auch, wieso hat sich der
Admin nicht ausreichend informiert und wird nun von Fehlern
überrascht? Weiterhin: Wenn man Debians Philosophie folgt und in
Produktivumgebungen ausschliesslich stable einsetzt gibts nicht viele
Downgrades durchzuführen...

es muß ja nicht jeder diese vergleichsweise teure Option benutzen. Aber
beispielsweise, wenn ein Unternehmen sich dazu entscheidet, Downgrades als
IT-Service anzubieten, um ITIL-kompatibel zu sein (bitte nimm die
ITIL-Debatte ernst, sie wird von vielen großen Unternehmen als strategisch
wichtig eingestuft) -- dann muß man halt die ganzen alten Pakete weiter
vorhalten. Und man muß auch die entsprechenden Konfigurationen und die
Dependency-Landschaft in einem Release abbilden.

Um es für die Community nicht zu teuer werden zu lassen, könnte man so einen
apt-Ableger beispielsweise dergestalt bauen, daß die alten Pakete entweder
im /var/cache/apt/archive weiterhin gehalten werden müssen, um einen
Downgrade zu ermöglichen. Die Konfigurationen usw. könnte man in einem
lokalen oder zentralen subversion-Repository ablegen, wobei jede Ablage erst
mal auf Dependency-Konsistenz geprüft wird, und das Gesamtrelease dann eine
Release-Nummer bekommt.

Derartige Releases könnten beispielsweise im Release-Management-Prozeß zentral
definiert und den ganzen Clients zur Verfügung gestellt werden. Damit bekäme
man große Softwarelandschaften leichter in den Griff.

Bei einem fiktiven "apt-get downgrade [version]" würde sich der Client die
benötigten Pakete entweder lokal zurückholen oder je nach Konfiguration von
einem im LAN befindlichen Software-Repository.

..... usw. Also, ich sehe eine derartige Erweiterung durchaus im Bereich des
Machbaren.

Viele Grüße
Markus

Andreas Pakulat

2005-02-09 20:50:11 UTC

Post by Markus Heller
Hallo Andreas,
[Downgrades]

Ich hatte nicht darueber gelaestert, das war mal wieder Michelle..

Post by Markus Heller
sie wird von vielen großen Unternehmen als strategisch
wichtig eingestuft) -- dann muß man halt die ganzen alten Pakete weiter
vorhalten. Und man muß auch die entsprechenden Konfigurationen und die
Dependency-Landschaft in einem Release abbilden.

Dann kann dieses Unternehmen Debian als Basis nehmen und darauf
aufbauend entsprechende Erweiterungen erzeugen. Dieses Unternehmen
kann dann auch die Downgrades testen. Debian will sowas doch gar
nicht, Debian moechte, soweit ich das sehe eine moeglichst stabile
Linux-Distribution "herausbringen"

Post by Markus Heller
Um es für die Community nicht zu teuer werden zu lassen, könnte man so einen
apt-Ableger beispielsweise dergestalt bauen, daß die alten Pakete entweder
im /var/cache/apt/archive weiterhin gehalten werden müssen,

Dafuer gibts snapshots...

Post by Markus Heller
um einen
Downgrade zu ermöglichen. Die Konfigurationen usw. könnte man in einem
lokalen oder zentralen subversion-Repository ablegen,

Als Debian-Default wohl eher nicht, aber fuer eine Debianbasierte
Distri...

Post by Markus Heller
..... usw. Also, ich sehe eine derartige Erweiterung durchaus im Bereich des
Machbaren.

Wenn du gerne ein ITIL kompatibles System auf Debian-Basis haettest,
setze dich doch hin und tue es. Debian hat IMHO nicht die Kapazitaet
um das zu schaffen.

Andreas
--
You are wise, witty, and wonderful, but you spend too much time reading
this sort of trash.

Tilo Schwarz

2005-02-08 22:30:13 UTC

Post by Markus Heller
Hallo Norbert,

Post by Norbert Tretkowski
Nein, Downgrades werden nicht supported.

vielleicht sollte die Community aber gerade an dieser Erweiterung
arbeiten. Standards wie ITIL schreiben fürs Release Management
diesen Weg ganz explizit vor. Wenn Debian für Großunternehmen als
strategische OS-Variante attraktiv werden soll, muß dieses Feature
umgesetzt werden.

Und wie soll man sowas bewerkstelligen?

Eine Variante ist, daß man ein Filesystem verwendet, daß Transaktionen
kann. Sowas ist nichts neues, wird aber normalerweise im Linuxumfeld
kaum verwendet (vielleicht gibt's so ein Filesystem "out of the box"
für Linux auch gar nicht, keine Ahnung). Mit so einem Filesystem sähe
es dann (etwas idealisiert) so aus (Datenbank läßt grüßen):

% begintransaction foo
% apt-get upgrade etc.
% fummel fummel
% mach was kaputt (Hilfeeee!)
% rollbacktransaction foo (alles wieder gut)

IIRC haben IBM/Oracle so Geschichten für Großrechner schon gemacht, die
auch verwendet wurden.

Grüße,

Tilo

Thomas Kosch

2005-02-09 06:40:29 UTC

[Downgrades]

Post by Tilo Schwarz

Post by Andreas Pakulat
Und wie soll man sowas bewerkstelligen?

Eine Variante ist, daß man ein Filesystem verwendet, daß Transaktionen
kann. Sowas ist nichts neues, wird aber normalerweise im Linuxumfeld

So tief brauchst du eigentlich gar nicht steigen. Es reicht wenn das
Paketmanagement das mitmacht.

Post by Tilo Schwarz
kaum verwendet (vielleicht gibt's so ein Filesystem "out of the box"
für Linux auch gar nicht, keine Ahnung). Mit so einem Filesystem sähe
% begintransaction foo
% apt-get upgrade etc.
% fummel fummel
% mach was kaputt (Hilfeeee!)
% rollbacktransaction foo (alles wieder gut)

Seit v4.0.3, was es ja nun auch schon eine Weile gibt, ist das bei rpm kein
Problem.
http://www.linuxjournal.com/article/7034

ttyl8er, t.k.

--
To be intoxicated is to feel sophisticated but not be able to say it.

Tilo Schwarz

2005-02-09 23:00:19 UTC

Post by Markus Heller
[Downgrades]

Post by Tilo Schwarz

Post by Andreas Pakulat
Und wie soll man sowas bewerkstelligen?

Eine Variante ist, daß man ein Filesystem verwendet, daß
Transaktionen kann. Sowas ist nichts neues, wird aber normalerweise
im Linuxumfeld

So tief brauchst du eigentlich gar nicht steigen. Es reicht wenn das
Paketmanagement das mitmacht.

Für das spezielle Downgradeproblem ja, aber es hat durchaus Vorteile
(und ein paar Nachteile, wahrscheinlich Speed), wenn das Filesystem
eine Transaktionssemantik implementiert. Da haben dann auch andere was
davon.

Grüße,

Tilo

Michelle Konzack

2005-02-08 11:50:16 UTC

Post by Markus Heller
Hallo Norbert,

Post by Norbert Tretkowski
Nein, Downgrades werden nicht supported.

Dafür kannste ja einen localen Mirror mit 'wget' anlegen.
Du brauchst lediglich die ALTEN Pakete nicht zu löschen.

Anm.: Mein SID-Mirror (source) war aus versenen 78 GByte
groß und hat mir die Platte verstopft.

Post by Markus Heller
Viele Grüße
Markus

Greetings
Michelle

Norbert Tretkowski

2005-02-08 12:00:15 UTC

Post by Markus Heller
Hallo Norbert,

Post by Norbert Tretkowski
Nein, Downgrades werden nicht supported.

vielleicht sollte die Community aber gerade an dieser Erweiterung arbeiten.

Wie stellst du dir das vor?

Post by Markus Heller
Standards wie ITIL schreiben fürs Release Management diesen Weg ganz
explizit vor.

Das ist zwar toll, dass dieser Standard das vorschreibt, aber wie
viele andere Standards auch geht dieser voellig an der Realitaet
vorbei.

Post by Markus Heller
Wenn Debian für Großunternehmen als strategische OS-Variante
attraktiv werden soll, muß dieses Feature umgesetzt werden.

Ah wat.

Norbert

Michelle Konzack

2005-02-08 12:10:09 UTC

Post by Markus Heller
Hallo Norbert,

Post by Norbert Tretkowski
Nein, Downgrades werden nicht supported.

vielleicht sollte die Community aber gerade an dieser Erweiterung arbeiten.
Standards wie ITIL schreiben fürs Release Management diesen Weg ganz

^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^

Post by Markus Heller
explizit

^^^^^^^^

Post by Markus Heller
vor. Wenn Debian für Großunternehmen als strategische OS-Variante attraktiv
werden soll, muß dieses Feature umgesetzt werden.

Frage: Wenn das ein OS schaffen könnte, dann Linux,
aber wie ist es mit der Crashware aus Redmond.

Post by Markus Heller
Viele Grüße
Markus

Greetings
Michelle

Helmut Wollmersdorfer

2005-02-08 13:00:28 UTC

Post by Michelle Konzack
Frage: Wenn das ein OS schaffen könnte, dann Linux,

Unterschätze nicht, was bei Mainframe-OSs schon vor 30 Jahren
funktioniert hat.

Post by Michelle Konzack
aber wie ist es mit der Crashware aus Redmond.

Hat das was mit OS zu tun?
SCNR;-)

Helmut Wollmersdorfer

Michelle Konzack

2005-02-08 13:30:17 UTC

Post by Michelle Konzack
Frage: Wenn das ein OS schaffen könnte, dann Linux,

Unterschätze nicht, was bei Mainframe-OSs schon vor 30 Jahren
funktioniert hat.

Naja, und wer hat so ne Kiste bei sich zuhause rumstehen ?
(Ich bin vom "normalen" $USER ausgegangen)

Post by Michelle Konzack
aber wie ist es mit der Crashware aus Redmond.

Hat das was mit OS zu tun?
SCNR;-)

:-) :-) :-) :-) :-) :-) :-) :-)

Post by Helmut Wollmersdorfer
Helmut Wollmersdorfer

Greetings
Michelle

Helmut Wollmersdorfer

2005-02-08 15:10:09 UTC

Post by Michelle Konzack
Naja, und wer hat so ne Kiste bei sich zuhause rumstehen ?
(Ich bin vom "normalen" $USER ausgegangen)

Die Rede war hier von industriellen Anforderungen.
Also entweder Riesenkiste mit (zig)tausenden Clients und/oder
(zig)tausende Clients mit Installation von verlässlicher Qualität.

Ein "normaler" $USER kann seine Kiste abnabeln, sichert die Daten und
setzt sie im worst case neu auf. Oder wechselt die Distries/Versionen
wie die Unterhosen. Da richtet ein Stillstand keine Katastrophe an.

Helmut Wollmersdorfer

Markus Heller

2005-02-08 16:50:12 UTC

Hallo Michelle,

Post by Michelle Konzack
Frage: Wenn das ein OS schaffen könnte, dann Linux,
aber wie ist es mit der Crashware aus Redmond.

Bin ebenfalls fest überzeugt, daß so ein system-immanentes Feature mit Linux
machbar ist. Bei den Redmondies gibt es da Hersteller teurer Zusatzsoftware
wie Metrix, und teilweise kann das M$-eigene SMS bzw. dessen Nachfolger
angeblich dies auch schon.

Allerdings bezweifle ich diese Infos ein bisserl, weil in den Medien ja nicht
mit "Ich-bin-der-/habe=gerade=20.000=Server=in=15=Minuten=gedowngradet/-Mann"
geworben wird. Man beschränkt sich im M$-Marketing auch nur auf die Upgrades.
Aber eigentlich ist das kontrollierte Downgrading die hohe Kunst.

Viele Grüße
Markus

Uwe Kerstan

2005-02-07 22:30:09 UTC

Post by Sven Rahlfs
auch apache und PHP geupdatet wurde und plötzlich geht ein
Internetprojekt nicht mehr traurig Und ich habe keinen schimmer woran es
liegen könnte da andere PHP Projekte nach wie vor problemlos laufen!

Eventuell liegt es *nur* an register_globals = On/Off in php.ini.
Irgendwann wurden die Voreinstellungen mal geändert.
Wenn die Skripte nicht ordentlich (sicher) programmiert
wurden, kann es Probleme damit geben.

Wäre nett, wenn du bei Problemen die Versionsnummern der
Programme und des OS angeben würdest ...

Gruss Uwe

Michael Holtermann

2005-02-08 10:10:09 UTC