Christoph Maser schrieb:
Am Montag, den 04.02.2008, 22:48 +0100 schrieb Thomas Schweikle:
Wird das offiziell überhaupt unterstützt? Sind OS-Upgrades überhaupt sinnvoll?
Server mit FreeBSD: 3.5 -> 4.0 4.0 -> 4.1 4.2 -> 4.3 4.3 -> 4.4 4.4 -> 4.11 4.11 -> 5.0 5.0 -> 5.2 5.2 -> 6.0 6.0 -> 6.1 6.1 -> 6.2 6.2 -> 6.3 6.3 -> 7.0 (ist nochnicht durchgeführt, steht aber an).
Das Ganze seit 1996. Der Server liefert http, nntp, smtp, pop3, imap, snmp. Natürlich nicht alle Protokolle von anfang an, aber bisher gab es keine Probleme ;-) Die Betriebsunterbrechung lag im Mittel bei 10 Minuten für update und reboot um jeweils den neuen Kernel in den Speicher zu bekommen.
Auch ein zweiter Server mit SuSE läuft seit 7.0 mit zwei Updates Jährlich ohne großes tamtam.
Ein Debian-Server ließ sich sogar von 2.2 auf Etch heben ohne das neu installiert werden mußte.
Lieber Thomas das ist sehr schön dass das Du mit diesen Systemen so gut zurechtkommst. Leider habe ich hier auch andere Erfahrungen gemacht. Die Sinnhaftigkeit von OS-Upgrades in Zeiten von SOA und Virtualisierung erschließt sich mir leider immer noch nicht. Wieso sollte ich meinen Server der eine Dienst bereitstellt upgraden (und damit ein Risiko eingehen), wenn ich diesen Dienst irgendwie anders vorinstalliert getestet und mit 0 Sekunden Service-Downtime auf ein anderes System umziehen kann?
Weil genau das nicht immer geht. Für solch ein Szenario müssen diverse Voraussetzungen geschaffen sein, die es nicht immer (meißt aus Kostengründen) gibt: - Es muß ein zweiter, möglichst ähnlicher Server vorhanden sein. - Der Dienst muß damit zurechtkommen, das ich alte Daten irgendwie aktuell auf einen anderen Server umziehen kann. D.h. DB-Replika, oder ähnliches, vor allem wenn die Daten normalerweise schnell und von vielen gleichzeitig geändert werden. Eine 40G DB online mal schnell auf einen anderen Server umziehen ist nicht.
Mit Redhat war das nie möglich. Es lief immer auf eine Neuinstallation hinaus. Es fällt auf, das andere Distributionen das bei weitem besser können als gerade Redhat.
Ist ja nicht allzu schwer besser als "Feature nicht vorhanden" zu sein ;)
Im Unternehmensumfeld ist was Redhat sich hier leistet eine Katastrophe!
Ich brauche im Unternehmensumfeld keine OS-Upgrades, deswegen ist das für mich überhaupt keine Katastrophe.
Siehe oben. Wenn die Voraussetzungen stimmen, dann ist mir das auch egal. Aber es gibt leider viel zu viele Unternehmen bei denen die Voraussetzungen nicht stimmen! Gerade im "billigen" PC-Bereich.
Bei Groß-EDV kommt das auch vor --- eine dicke, fette, 2t BS2000 hat auch nicht jeder doppelt nur weil gerade mal ein OS-Update ansteht. Das wäre zu teuer. Also wird auch hier eher mit Upgrade gearbeitet als mit Neuinstallieren, auch wenn das ein wenig mehr Schwierigkeiten mit sich bringt.
Zumal ein Upgrade von CentOS 4.x auf 5.x per yum problemlos lief, bis kurz vor dem Fedora 8-Release noch eine Änderung am Repository-System durchgeführt wurde. Danach ging kein Upgrade von "Fedora Core 6" oder "Fedora 7" auf "Fedora 8" mehr. In CentOS (4.x auf 5.0) ergab sich kurz darauf das selbe Bild. Bis heute ist das Problem nicht behoben. Upgrades funktionierten bis zu "Fedora 8 rc1" problemlos, danach nicht mehr.
Es mag ja funktioniere haben, war es denn auch explizit vorgesehen (supported)? [Die Frage ist ernst gemeint ich weiß es nämlich nicht.]
Es sollte, zumindest von CD/DVD, funktionieren. Das es das nicht tut ist nicht nur bedauerlich, es ist peinlich. Vor allem wenn es nur daran hängt, dass das CD/DVD-Laufwerk unter einem falschen Namen angesprochen wird, weil irgendwer meinte dieses fest in ein Programm eintragen zu müssen. Solche Kleinigkeiten lassen sich per statischer Programmanalyse aufdecken und beheben --- ein eindeutiges Zeichen dafür, das selbst so etwas bei Redhat nicht gemacht wird.
Aber das ist nicht das einzige Problem:
Sonst wären die centos/redhat Bugtracking-Systeme auch leer :)
;-)
Einfach einmal (geht allerdings nur mit dem graphischen Installer) das "Base-System" abwählen (alles deaktivieren was der Installer im Advanced-Mode anbietet). Danach landen gerade mal ~120 Pakete auf der Festplatte. Das ganze bootet problemlos. Allerdings: yum fehlt! Python auch. Aber für einen halbwegs versierten Admin ist das kein echtes Problem: einfach per rpm nachinstallieren. Nur: alle Pakete, die zum "Base-System" gehören sind anscheinend nicht voneinander abhängig! yum bemängelt bei jeder installation diverse nicht aufzulösende Abhängigkeiten von angeblich nicht vorhandenen Paketen. Nachsehen im Repository liefert eine Erklärung: diese Pakete werden in der xml-Beschreibung des Repository *nicht* erfasst und yum findet sie konsequenterweise auch nicht. Bisher ist das, obwohl es seit vier Monaten dazu einen Bugzilla-Eintrag gibt nicht korregiert worden...
Sehr ärgerlich das stimme ich Dir zu. Bei RedHat liegt wohl eh einiges im Argen, zumindest habe ich den Eindruck weil auch ich denke, dass es da sehr langsam vorangeht. Aber um mal auf das Unternehmensumfeld zurückzukommen, wer bitte in diesem Umfeld benutzt denn den Graphischen Installer, oder überhaupt eine Interaktive Installation?
Richtig. Es wird Kickstart konfiguriert und dann installiert. Doof nur, wenn in den Basispaketen keine Abhängigkeiten oder Falsche Abhängigkeiten eingetragen sind --- spätestens wenn ich dann irgendetwas nachinstallieren, was ein nicht installiertes Basispaket benötigt, knallt es. Und das kommt schneller vor als gemeinhin angenommen wird.
Die Leute um SuSE, Debian, FreeBSD oder Ubuntu reagieren bei solchen Fehlern bedeutend schneller.
Ja drüben schmeckt mir das Gras auch viel besser ....
Nein nicht das Gras grüner, sondern die allgemeinen Anforderungen: - Windows (XP, 2000) - Windows Server (2000, 2003) - Linux (Debian, SuSE, RedHat (CentOS, Fedora), Gentoo) - BSD (FreeBSD, NetBSD, OpenBSD) - AIX - Solaris - VMware ESX - XEN
Leider ist Linux nicht gleich Linux und ich bin immer wieder gezwungen mich mit den kleinen, aber feinen Differenzen zwischen den Distributionen auseinanderzusetzen: SuSE verwendet andere Libs als Redhat, die wieder andere als Debian und Gentoo. Teilweise sind libs unterschiedlich gesplittet, heißen aber auf den verschiedenen Distros gleich. Dann das beliebte glibc-Spiel: der eine möchte noch 5.x die anderen bereits 6.x. Manche Distribution erlaubt es beides zu installieren, andere lieben es Windows-Like: es kann nur eine geben (es sei denn man verrenkt sich die Hirnwindungen um es doch hinzubekommen --- oft ist es aber einfacher einfach die "passende" Distro zu verwenden).