Hallo Liste, am Die, 26 Okt 1999, schrieb Raphael Becker (beckerra@rumms.uni-mannheim.de):
Markus Hochholdinger wrote:
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.
...der Update Mechanismus ist (IMHO) nicht besser oder schlechter als bei anderen Betriebssystemen: normalerweise wird nur das Update direkt aufeinander folgender Versionen getestet...die Zahl der möglichen Kombinationen/Update-Pfade wäre sonst auch zu hoch, und daher kaum zu testen/supporten. Bei einem Update von 5.3 auf 6.2 sollte daher auf jeden Fall im Zwischenschritt auf 6.0 upgedatet werden, evtl. auch noch auf 6.1.
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.
Jepp, allerdings ist der Mechanismus mit den Backupdateien bzw. den rpmsave Dateien sehr hilfreich. Wenn Du ein Solaris 2.5 auf 2.6 updatest, kannst Du damit rechnen, daß Deine Konfigurationsdateien (incl. /etc/hosts :-) ) überschrieben werden.
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!
Nein, die meisten Konfigurationen liegen ja in separaten Dateien, werden beim Update aber überschrieben. -> nach rpmsave Dateien suchen, beim Update Backups anlegen lassen, ...falls notwendig Dateien aus den Backups wieder einspielen. Das Problem ist halt, daß die meisten RPM Pakete ihre eigenen Konfigurationsdateien mitbringen und damit evtl. vorhandene überschreiben...da RPM aber die alten Dateien sichert ist es IMHO kein Problem, den alten Zustand wieder herzustellen. Da das Format der Konfigdateien sich ab und zu ändert (siehe z.B. PPP) wäre es aber halt auch keine Lösung, die neuen Dateien nicht zu installieren...
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.
Full ACK :-)
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)....
Nichts gegen das Perlskript bei bind8, aber bei komplexeren Setups tut es noch nicht einmal halbe Arbeit...will sagen, nachdem ich meine alte Konfig damit konvertiert hatte lief mein Nameserver nicht...da war einiges an Handarbeit notwendig. Meist funktionieren solche automatischen Upgrades von Konfigdateien nur in der Theorie, oder für einfache Fälle.
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).
...sendmail, smail, postfix...ich denke mal SuSE liefert mehr als einen MTA. Allerdings wird (IIRC) nur sendmail von der Hotline supported.
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".
Gerade wenn ich ein System "anwenden" will, möchte ich ein System haben, daß einfach zu pflegen und upzudaten ist. Mein erstes Linux war ein Slackware, gefolgt von Yggdrasil, RedHat, ... und schließlich SuSE. Ich möchte für die von mir betreuten Server nicht mehr Zeit aufwenden als unbedingt notwendig, und finde daher eine einfache Konfiguration sehr hilfreich. Ich habe auf allen Systemen viel selbst angepasste Software, um das pflegen zu können, habe ich alle Pakete als RPM Pakete gebaut und installiert. Das ist zwar beim ersten mal ein etwas größerer Aufwand (gegenüber "make install"), aber spätestens beim ersten update zahlt es sich aus.
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.
Zumindest nicht absichtlich :-)
Das rc.config-Konzept haben die AFAIK auch nicht erfunden sondern aus anderen (kommerziellen?) Unices entlehnt/nachempfunden.
Jepp, gibt es (als /etc/rc.config.d/<file>) unter HP-UX... Hauptidee bzw. Vorteil des ganzen ist, dass man durch das Setzen von Variablen Startskripte aktivieren/deaktivieren kann. CU, Stefan -- Stefan Giessler e-mail: stefan.Giessler@net-share.de SGIs benehmen sich sowieso wie die Prinzessin auf der Erbse :-) -- unknown --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com