-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On 01/26/2008 12:59 AM, Ralph Angenendt wrote:

Ich würde mich freuen, wenn wir alle zusammen (oder zumindest einige von uns) den Besuchern erzählen könnten, warum CentOS die beste Distribution auf diesem Planeten ist.

Hallo Ralph

Eine technische Begründung warum CentOS besser sein sollte, als die anderen Distributionen, würde mich wirklich interessieren.

beste Grüsse Simon

Heiko Adams schrieb:

Am Sonntag, den 03.02.2008, 19:02 +0100 schrieb Simon Jolle "sjolle":

...

On 01/26/2008 12:59 AM, Ralph Angenendt wrote:

...

Ich würde mich freuen, wenn wir alle zusammen (oder zumindest einige von uns) den Besuchern erzählen könnten, warum CentOS die beste Distribution auf diesem Planeten ist.

Hallo Ralph

Eine technische Begründung warum CentOS besser sein sollte, als die anderen Distributionen, würde mich wirklich interessieren.

Ich würde auf jeden Fall den *deutlich* längeren Supportzeitraumim Vergleich zu den kostenlosen Community Distributionen und die professionelle QA durch den Upstream Vendor als Argumente anführen.

Den längeren Supportzeitraum? --- OK. Die "professionelle QA" durch den Upstream Vendor? --- die gibt es nach meinen Erfahrungen nicht:

Zur Zeit ist es nahezu unmöglich ein CentOS 4.6 auf CentOS 5.1 zu migrieren. Der Prozess, wenn er denn startet, bleibt an verschiedenen Stellen hängen. Teilweise beim Booten, teilweise beim auflösen aller Abhängigkeiten, teilweise beim "Transaction Test".

Sollte er, trozt aller Unsicherheit, doch funktioniert haben, ist nicht sicher, ob das System hinterher auch noch funktioniert: - bei mir war in einem Fall (~60 Server) yum nicht mehr ausführbar: Teile zu yum waren einfach nicht installiert worden. - in einem zweiten Fall (~ 80 Server) bootete das System anschließend nicht mehr. Erst eine längere Suche ergab, das der Kernel gegenüber CentOS 4.x eine für den Bootprozess wichtige Hardware --- den SCSI-Treiber nicht mehr unterstützte. Der Vanilla-Kernel konnte im Gegensatz zum CentOS-Kernel damit umgehen. Grund: ein mangelhafter Patch des CentOS-Kernels.

Auch im Regelbetrieb gibt es immer wieder unangenehme "Nebeneffekte": Updates zu Paketen, die Abhängigkeiten erfordern, die in keinem der Repositories weltweit erfüllt werden (das legt sich zwar nach ein bis vier Wochen --- manchmal auch erst nach einem Bug-Report, der mit "This is the same for RHEL 5.x we will not fix it" geschlossen wird ...).

Wenn CentOS ein Abbild von RHEL ist ...!

Heiko Adams schrieb:

Am Sonntag, den 03.02.2008, 22:04 +0100 schrieb Thomas Schweikle:

...

...

Ich würde auf jeden Fall den *deutlich* längeren Supportzeitraumim Vergleich zu den kostenlosen Community Distributionen und die professionelle QA durch den Upstream Vendor als Argumente anführen.

Den längeren Supportzeitraum? --- OK. Die "professionelle QA" durch den Upstream Vendor? --- die gibt es nach meinen Erfahrungen nicht:

Mit professionell meinte ich eher, das beim Upstream Vendor Menschen für die QA bezahlt werden. Das diese Menschen (natürlich) auch mal Fehler machen, ist leider nicht 100%ig zu verhindern.

Niemand möchte den Menschen hinter CentOS absprechen Fehler machen zu dürfen. Ich habe nur etwas dagegen, wenn anschließend diese Fehler, auch wenn sie bemerkt werden nicht korrigiert werden. Hier liegt bei Redhat, CentOS, Fedora nicht nur ein klein wenig was im Argen, sondern es scheint als normal akzeptiert zu sein, das Fehler eben passierten und dann einfach weiter existieren ohne das dies wichtig wäre. Die Haltung ist so wie: wenn wir die Schwimmweste mit Blei beschweren, dann kann sie bei Sturm schon nicht mehr wegfliegen. Das die Schwimmweste damit zu einer "Versenkweste" wird, stört ja nicht --- Problem "wegfliegen bei Sturm" ist ja behoben ...

Ralph Angenendt schrieb:

Thomas Schweikle wrote:

...

Zur Zeit ist es nahezu unmöglich ein CentOS 4.6 auf CentOS 5.1 zu migrieren. Der Prozess, wenn er denn startet, bleibt an verschiedenen Stellen hängen. Teilweise beim Booten, teilweise beim auflösen aller Abhängigkeiten, teilweise beim "Transaction Test".

Beim Update via yum oder via DVD/CD?

Beides. Zuerst ausprobiert mit yum und gescheitert, dann mit CD/DVD und erneut gescheitert.

Mit CD/DVD hängt das Update an verschiedenen Stellen, falls es überhaupt soweit kommt, das ein Update beginnt. Oft genug findet CentOS/Fedora/Redhat einfach das CD/DVD-Laufwerk mit der CD nicht. Ursache: das CD/DVD-Laufwerk wird als /dev/hdc gefunden, ist aber nach laden von idescsi unter /dev/scdN oder /dev/srN zu finden.

Eine neue, korrigierte CD gibt es bis heute nicht.

Funktioniert "finden der CD/DVD", dann wartet die nächste Hürde: yum baut bei der Systemanalyse den kompletten Abhängigkeitenbaum für alle installierten Pakete zusammen. Das benötigt immense Mengen Speicherplatz. Reicht dieser nicht, dann bleibt das System einfach stehen und rührt sich nicht mehr.

Ist auch diese Hürde geschafft, dann folgt die "Abhängigkeitenhölle": es ist leicht möglich, das es unmöglich ist ein Paket von CD/DVD zu updaten, weil es nicht auf der CD/DVD vorhanden ist und nie war. Wenn dieses Paket dann um acht ecken von der glibc abhängt, kann es passieren, das ich diese per "--exclude" ausschließen muß, damit ich überhaupt ein Update hinbekomme. Es ist klar, das ein System ohne "glibc" so gut wie nicht zum laufen zu bekommen ist ...

Der Versuch das mit "--skip-broken" in den Griff zu bekommen führt mit zimlicher Sicherheit zu einer mit "Alles bestens installiert"-Meldung vom Installer, aber wehe das System wird neu gebootet --- spätestens bei "Attempt to kill init" ist klar, das irgendwas beim gerade gebooteten System fehlt. Beim nachsehen was es den sein könnte fällt erst einmal nichts auf, bis irgendeine Anwendung gestartet wird und sich darüber beschwert, das die glibc fehlt! Leider ist das nicht trivial zu beheben: es fehlt nicht nur die glibc, sondern diverse weitere libraries. Es dauert mehrere Stunden diese alle Nachzuinstallieren. Fazit: mach eine Neuinstallation --- geht schneller. Nur: wenn sehr viele weitere Pakete installiert waren, ist hinterher neuinstallieren dieser Pakete angesagt --- das kann ebenfalls sehr lange dauern.

Warum Fedora/Redhat/CentOS es nicht so machen wie SuSE: - alle von YaST benötigten Libraries per preload laden - Update von YaST und den dafür benötigten Systemteilen - YaST neu starten und das restliche System updaten - Systemneustart

oder wie Debian: - alle von apt benötigten Libraries und Programme in einen sicheren Bereich kopieren und dort neu starten - Systemupdate durchführen - Systemneustart empfehlen

oder die FreeBSD variante: - System in einem sicheren Bereich neu zusammenstellen - in diesen Bereich wechseln und dort alles neu einrichten - per install und cp das neu zusammengebaute Minimalsystem über das alte kopieren - Systemneustart empfehlem - Das restliche System über das alte kopieren - Konfigurationsdateien anpassen - Systemneustart empfehlem

...

Auch im Regelbetrieb gibt es immer wieder unangenehme "Nebeneffekte": Updates zu Paketen, die Abhängigkeiten erfordern, die in keinem der Repositories weltweit erfüllt werden (das legt sich zwar nach ein bis vier Wochen --- manchmal auch erst nach einem Bug-Report, der mit "This is the same for RHEL 5.x we will not fix it" geschlossen wird ...).

Jaja, das nautilus-sendto-Problem. *Hass*

Weniger Nautilus, als Nachlässigkeit. Frei nach dem Motto: "ich hab zwar keine Ahnung was alles bei mir auf meinem PC installiert ist, aber genau so muß es auch bei allen anderen Anwendern aussehen --- bei mir tut das. Was wollen die alle bloß?".

...

Wenn CentOS ein Abbild von RHEL ist ...!

Dem ist nun mal so. Wir packen ja schon Dinge hinzu (via CentOS-Plus oder Extras, so z.B. Reiser- und XFS-Support), im Basisprodukt bleiben wir aber auch trotz solche Dinge Upstreamkompatibel. Und ja, da scheinen im Moment ein paar Dinge im Argen zu liegen.

... dann ist das ein trauriges Bild von Redhat und passt so gar nicht zu deren Wunsch "die besten, größten, und schönsten Linuxer der Erde" sein zu wollen.

Christoph Maser schrieb:

Am Sonntag, den 03.02.2008, 22:04 +0100 schrieb Thomas Schweikle:

...

Zur Zeit ist es nahezu unmöglich ein CentOS 4.6 auf CentOS 5.1 zu migrieren.

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.

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. Im Unternehmensumfeld ist was Redhat sich hier leistet eine Katastrophe! 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.

Aber das ist nicht das einzige Problem: 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...

Die Leute um SuSE, Debian, FreeBSD oder Ubuntu reagieren bei solchen Fehlern bedeutend schneller.

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