[CentOS-de] Re: Ganz viel zu was Thomas nicht passt (warRe: Linuxtag 2008)

[Thomas Schweikle]

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).


-- 
Thomas