Markus Hochholdinger wrote:
Hi Liste,
hierzu will ich als Debian-Fanatiker auch noch was sagen:
Ich habe einen Server von Suse 5.3 auf Stand 6.2 Update gemacht, kurz gesagt: grauenhaft! Hätte ich auch nicht gemacht und zwar aus folgendem Grund: Seit der 5.3 ist nunmehr 1 Jahr ins Land gezogen und in dieser Zeit hat sich sehr viel verändert (neue Libs, neuer Kernel+kernelabh. Tools ...).
Irgendwie schaltet dies aber einen Vorteil von Linux aus: Linux muß man nicht alle 2 Monate neu installieren! Irgendwie bremst sich hier Suse selbst aus!
Mann kann schon einfach so updaten. Man hat da 2 Möglichkeiten, entweder man vertraut dem Update-MEchanismus vom Hersteller der Distribution oder man macht es von Hand. Das Problem ist der Update-Mechanismus. In der Regel wird sowas ja getestet, bevor es ausgeliefert wird. Und es werden viele verschiedene Konstellationen getestet und so weiter. Diese Update-Mechanismen werden aber ganz sicher nicht einen Versionssprung berücksichtigen, der 1 Jahr ausmacht. Auch wenns theoretisch dann trotzdem, noch gehen sollte, sobald man das System von Hand den eigenen Bedürfnissen angepast hat, darf man eben nicht mehr glauben, daß das Update alle Änderungen korrekt erkennt und dementsprchend anders vorgeht.
Besonders wenn die SuSE keine "SuSE" mehr ist (weil man nämlich viel von Hand nachbearbeitet hat), ist nicht sehr empfehlenswert, ein 1:1-Update zu machen.
Das führe ich mal wieder auf die rcconfig zurück. Ist vielleicht doch nicht so toll, alles zentral zu verwalten!
Es wird nicht alles zentral verwaltet. Die meisten Probleme sind wie gesagt die veränderte Software und Grundlagen (zB Libs etc), d.h. daß zB Binaries nicht bis in alle Ewigkeit auf einem ansonsten sich weiterentwickelnden System lauffähig gehalten werden können, besonders darf man nicht darauf vertrauen, daß zB neuere Libs, die auf dem Papier abwärtskompatibel sind eben genau dies auch sind.
Wie hast Du das Grundsystem geupdatet? Hoffentlich nicht im laufenden System.
Debian kann man im laufenden System updaten! Das ging von 1.3 auf 2.0, sowie von 2.0 (hamm) auf 2.1 (slink). Und auch von 2.1 auf potato (unstable). Ich bin seit Debian 1.3 dabei, und habe bisher jedesmal erfolgreich ein komlettes update machen können. Und alles lief weiter.
Aber Du hast auch die Zwischenschritte gemacht, d.h. jedes Update baute auf dem vorgehenden auf. Bei Mark war das offenbar anders.
Bei problematischen Programmen, wie z.B. glibc wird man darauf hingewiesen. Wenn sich Konfigurationsdateien im Aufbau geändert haben, wird einem das auch eindringlich beim update gesagt, und man hat auf jedenfall hinterher eine alte und eine neue Konfiguration. Nichts geht verloren!
Bei kritischen Updates hat man ohnehin das Backup vom Vortag noch irgendwo rumliegen.
Systemdienste liefen nach Update nicht mehr alle (obwohl auch alte libc5 vorhanden war), Konfigurationen mussten eh alle per Hand angeglichen werden (selbst wo es Unsinn ist, weil z.B. Bind8 ein Perlscript liefert um in neues Konfig-Format umzuwandeln), neues Kernel konnte nicht mal kompiliert werden weil u.a. mit curses Mist gebaut wurde (braucht menuconfig).... Also das ncurses der SuSE 6.1 ist völlig ok. ausserdem: "make config" geht immer
Kernel Update muß ja nicht unbeding Linux (Distribution) update heißen, oder? Schließlich muß man beim Kernel neu compilieren den Rechner neu starten...
Schon, aber die Tools, die um den Kernel herum existieren (kerneld vs kmod (oder wie die beiden Modullader heissen) müssen entsprechend mit upgetatet werden. Wenn der Kernel seit 2.0.34 im vfat-Copde auch FAT32 unterstützt, dann muß das zB fdisk auch wissen und können. Und der Sprung von 2.0.36 auf 2.2.0 war IMHO ziemlich umfassend.
Also kurzerhand Root-Partition gebügelt und komplett neu draufgemacht, alle Konfigs überarbeitet, diverse Firewall und Securitypatches (immernoch nötig) und dann mal wieder Exim von Hand installiert, weil Suse nur sendmail als MTA anbietet (weis nicht ob Redhat mehr anbietet).
Hört sich wie bei Windows an....
Möglicherweise ist exim noch nicht genug getestet, zB im kommerziellen Umfeld. SuSE, und das ist gleichzeitig ein Vor und ein Nachteil, macht eben nicht jeden Versionssprung von irgendwelcher Software mit. Wer dennoch immer das neueste braucht, soll es halt von Hand machen und das ist doch nun wirklich nicht so schwirig (zB selbst kompilieren und installieren), oder?
<eigene Meinung> RedHat ist für Privatpersonen kaum besser, als die SuSE (was will ich mit der IBM DB2 oder dem kompletten CPAN-Archiv von Perl?) und hat insgesamt ein eingeschränktes Serviceangebot. </eigene Meinung>
Sagen wirŽs doch mal im Klartext (Markus wird provokant): Suse ist was für Windows -> Linux -Umsteiger in Deutschland. Da haben sie ein ähnliches System. Und da haben sie auch "deutschen" Support. RedHat ist dann was für englisch sprechende Umsteiger. Zu Debian kommt man dann, wenn man Linux kapiert hat und das System "anwenden" will.
Der letzte Satz ist ausschlaggebend. NAtürlich ist SuSE _das_ Anfänger-Linux, aber es bietet auch alles, was ein Profi braucht (weil er kann sich das, was fehlt) ohnehin selbst "bauen".
Problem bei Debian: - In der stable-Version sind nicht immer die neusten Sachen dabei.
Siehe SuSE, nur der Unterschied: SuSE bringt keine expliziten unstables raus.
- stable Versionen kommen nur in großem zeitlichen Abstand heraus. - Es gibt noch keine 100% DAU Installation.
Die gibt es auch bei SuSE nicht (auch wenn die damit schon recht weit sind... trotzdem hat man, wenn man das will, immer und überall Möglichkeiten einzugreifen (wenn man weiß wo).
Vorteile bei Debian: - Die stable Version läuft. Keine Probleme mit irgendwelchen libŽs oder Konfigurationsänderungen. Update funktioniert OHNE Neustart des Rechners!
Geht bei der SuSE auch, aber eben ohne Garantie.
Die alte Konfiguration wird NICHT überschrieben, auch wenn man selbst Hand angelegt hat!
SuSE legt Backups der alten Dateien an, jedoch: eigenes Backup ist sinnvoller, weil man dann weiß, warum und wie man es zurückspielt, ohne daß man vorher das Handbuch danach absuchen muß.
- Wenn man die neusten Programme haben will, kann man die unstable Version benutzen. Damit ist man gleichzeitig Beta-tester, und kann nicht davon ausgehen, daß immer alles reibungslos funktioniert. Im Kommerziellen Bereich scheidet dies aus, aber für den Homeuser (wie mir) ist das ein gute Möglichkeit. Allerdings sollte man bei unstable mit unerwünschten Problemen zurecht kommen!
Wieder mal der letzte Satz, der sooo entscheident ist.
Meine Empfehlung: Beim Update von Suse, erst Backup machen, fstab und Kernelmodule aufschreiben, dann entsprechende Partitionen bügeln... und evtl überlegen Debian zu installieren. :) Genau. RedHat ist keine ernsthafte Alternative <eigene Meinung> und debian was fuer Kenner</eigene Meinung>
Debian ist immoment vielleicht noch in dem Ruf etwas für Kenner zu sein, die
Du selbst hast das schon 2x bestätigt (siehe oben und noch weiter oben).
Installation ist aber nicht viel schwieriger als bei Suse. Ich habe bei einem Kumpel Suse installiert, und habe mich über ein paar Sachen aufgeregt, weil ich nicht wußte, was jetzt genau passiert!
Wüßte ich bei debian auch nicht ohne weiteres ;-) Bei SuSE lese ich im Handbuch, was wann zu tun ist und was wie gemacht wird. Auf der CD von SuSE sind auch viele READMES dabei, die man schon unter DOS lesen kann. Mein Fazit: SuSE ist nicht so geheimnisvoll, wie sie manchmal erscheinen mag. Das rc.config-Konzept haben die AFAIK auch nicht erfunden sondern aus anderen (kommerziellen?) Unices entlehnt/nachempfunden. Wer nicht möchte, daß die Startscripte die rc.config auslesen, der kann ohne weiteres sein eigenes Startscript integrieren. Das SuSE gerade an den Startscripten nix verändert, kann man hier getrost seine Eigenkreationen verwirklichen. Und wer SuSE-Config gar nicht mag (das ist das Tool, das aus der rc.config die verschiedenen config-Dateien zaubert), der kann es auch deaktivieren: # Some people don't want SuSEconfig to modify the system. With this # entry you can disable SuSEconfig completely. # Please don't contact our support if you have trouble configuring your # system after having disabled SuSEconfig. (yes/no) # ENABLE_SUSECONFIG=yes Dann wird die rc.config nur noch beim booten verwendet, sofern man SuSE-Scripts verwendet ... ansonsten kann man auch alles andere per Hand machen (YaST bietet, mal von der rc.config abgesehen, frontends fuer useradd oder fdisk, rpm oder wasweissichwasc ... man kann das alles auch von Hand machen). Gruß Raphael Becker PS: Und laßt das Guru-Gehabe sein, bei SuSE handle es sich um ein besseres Windows. Bei Windows gibt es keine Motorhaube, bei SuSE kann man sie leicht aufmachen und bei anderen Distributionen braucht man keine Karosserie. Da kann man dann auch während man auf 2 Rädern fährt die Räder auf der anderen Seite austauschen (siehe Wetten Das vor einigen Jahren), aber das is halt fuer Profis und Leute die das nicht können sind nicht die schlechteren Autofahrer, nur weil sie zum Radwechsel anhalten und einen Wagenheber verwenden ... -- Online-Doku: http://rhb.swm.uni-mannheim.de/online-doku/index.html Gesucht - Gefunden: Linux-Anleitungen Fehlt was? Dann nix wie her mit dem URL mailto:online-doku@gmx.de --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com