Am Donnerstag, 23. Oktober 2003 09:20 schrieb Reiner Klaproth:
Deine Erfahrungen scheinen Jahre zurück zu liegen.
Naja, eigentlich nicht. Die letzte SuSE 8.2 Installation liegt nur einen Monat zurück. Bis auf die Grafikkarte (FireGL1) funktioniert die Grundinstallation auch sehr schnell und ohne Probleme.
Für NFS-Server, NFS-Client und analog NIS-Server und -Client gibt es inzwischen gute YaST-Module, mit denen man das gewünschte "zusammenklicken" kann.
Alle Module habe ich nicht ausprobiert, sondern nur den NIS- und den NFS-Client. NIS geht noch gut. Dort trägt man fix die IP-Adresse des Servers und die NIS-Domain ein. So weit so gut. Die Konfiguration der 13 zu importierenden NFS-Verzeichnisse von 4 Servern klickt man sich nicht mehr so schnell zusammen. Da kopiert man sich ein funktionierendes Musterfile. Will man nun mal schnell noch ein Verzeichniss dazu klicken, dann findet das YAST-Modul keines von den bisherigen importierten Verzeichnissen. Also macht man das fix mit dem vi selber. Die entsprechenden Module belegen im beschriebenen Fall nur Plattenplatz.
Für "normale" Konfigurationen funktioniert die Konfiguration über YAST sicherlich gut.
Im Zweifelsfall ist es jedoch von Vorteil, wenn man sich mit Konfigurations- dateien auskennt.
Volle Zustimmung.
SuSE ersetzt NIS zunehmend gegen LDAP, und das finde ich gut so.
Ist ja nett von SuSE. Wenn man einen NIS-Server im Netz hat, dann nutzt einem das aber nix.
Die Softwareinstallation und das Update sind _viel_ besser gelöst.
Gehe ich nicht mit. YaST wählt analog apt-get die zusätzlichen Pakete mit aus. Updates sind von SuSE durch den Punkt "Online Update" mindestens genauso einfach geworden, wie es bei Debian der Fall ist.
Will man nur mal fix die aktuellen Updates einspielen, dann tippert man "online_update". Also machen wir das mal:
root:~ # online_update Error retrieving patches: ERROR(Media:error): Unable to get './i386/update/8.2/patches/directory.3' or to read the directory (Connection aborted).
Nanu? Der Server ist mal wieder nicht erreichbar. Nicht so wild, dann probiert man es halt später nochmal. Wenns irgendwann mal klappt, weis man immer noch nicht was er macht. Auch mit Debug (-D) und der Verbose (-V)-Option erfährt man nicht, ob er den sshd nach dem update neugestartet hat oder nicht. Auch das kommentarlose drüber bügeln eines Kernelupdates ohne Anpassung des lilo sind nicht so nett. Ein Anfänger hat dann verloren. Vom verschwundenen selber kompilierten Kernel mal abgesehen.
RPM hat vor allem dann Vorteile, wenn sich Pakete "überlagern", also was Überschneidungen in den Abhängigkeiten betrifft.
--verbose
Ich weiß, dass viele in der LUG Debian bevorzugen. Dennoch sollte man nicht ohne Vorkenntnisse über SuSE herziehen!
Bitte nicht mit solchen Vorurteilen um sich werfen. Die SuSE-Versionen 6.0 / 6.1 / 7.0 / 7.3 / 8.2 hatte bzw. habe ich immer noch auf der Platte. Die Grundkenntnisse sind also vorhanden. Ganz nebenbei laufen/liefen die auch meist ohne Probleme. Das einzig frustrierende war das amok-laufende yast unter SuSE 6.0. Da hat man nach einigen Mühen und einem Wochende eine laufende X-Server-Konfiguration zusammen geschraubt und dann wird die einfach gekillt. So richtig nett war das nicht. Okay, aus solchen Fehlern lernt man und rettet sich das /etc Verzeichnis und bastelt seine eigenen Änderungen immer wieder zurück. Ob yast immer noch so destruktiv arbeitet weiss ich nicht. Funktioniert eine Konfiguration dann rufe ich nie wieder das entsprechende YAST-Modul auf. Sicher ist sicher.
Eine weitere SuSE typische Eigenart sind die boot-Skripte. Da wird zum Beispiel nach plug-able Devices (USB, FireWire,PCI,...) gesucht. Deaktiviert man beim Kernelbauen nun Firewire und PCI-Hotplug-Devices, weil man das nicht hat, dann bekommt man beim booten ein freundliches "failed". Nun erzähle mal jemanden, das das vollkommen richtig ist. Das wird umso schwieriger, da bei jedem booten die Hardwareerkennung läuft. Irgendwann sollte er es doch merken, das keine Firewire-Schnittstelle vorhanden ist.
Jens Weiße