OpenSmallOffice - openSUSE-Basis

aus openSUSE, der freien Wissensdatenbank

Bild:OSo_logo_-_titel.png

Autor: Thomas Lodewick

Inhalt

zurück zur Projektseite


Da dieser Abschnitt länger wurde als geplant, beachten Sie bitte auch folgende Unterkaitel:

OpenSmallOffice - openSUSE-Basis: Eingesetzte Hardware * Treiber * Layout der Disks * Testumgebung
Am 13. Oktober 2006 ist eine aktualisierte Version von SUSE Linux 10.1 als Download im ISO-Format erschienen. Diese enthält alle bis dahin erschienenen Updates von SUSE Linux 10.1 - die fehlerhafte Updatefunktion der Orginalversion ist damit ebenfalls ersetzt worden. Bitte laden Sie sich die aktualisierte Version und nutzen diese für die weitere Installation Ihres Servers - auch dann, wenn Sie eine sogenannte "boxed Version" von SUSE Linux Version 10.1 käuflich erworben haben !

Sie finden alle Hinweise und Adressen zum Herunterladen wie immer auf den Downloadseiten des Wikis.


Die generelle Installation von openSUSE ist hier im Wiki ausreichend dokumeniert, so das ich als erstes auf die entsprechenden Seiten im Wiki verweisen möchte:

Von dieser Übersicht ausgehend haben Sie direkten Zugriff auf zahlreiche Themen wie zum Beispiel Installationsquellen, Basis-Installation, erweiterte Installationsmöglichkeiten, Problembehandlungen sowie einige Screenshots.

Diese Übersichtsseite liefert einen schnellen Zugriff auf Themen rund um die Konfiguration, zum Beispiel zum Bootloader, Zeichensätze, Multimedia / Grafik, Netzwerk, Paketverwaltung sowie einigen Diensten (Daemons)

Eigene Hinweise

Ergänzend zu den Anleitungen aus den oben genannten Seiten des Wikis folgende Hinweise aus eigener Feder:

Kernelquellen

Für manche Administratoren ist dies schon fast die Frage nach dem Heiligen Gral: sollen Kernelquellen auf einem Produktionsserver installiert werden, oder nicht. Gerade bei einem Server gilt eigentlich der Grundsatz, ein funktionierendes System nicht zu ändern. Und sollte man doch einmal ein Update des Kernels durchführen, sollte dies eigentlich auf einem Testsystem ausgiebig auf mögliche Fehlerquellen hin getestet sein. Soweit die gute Theorie. In der Praxis muss man sich aber fragen: wozu bräuchte man die Kernelquellen, sind diese für ein Update des Kernels überhaupt notwendig, und wie handhabt man generell ein Update des Kernels ?

  • Nutzen der Kernelquellen

Die Quellen des Kernels brauchen Sie nur dann, wenn Sie ein bestimmtes Kernelmodul zur Installation aus Quellcode selbst kompilieren müssen - dies ist zum Beispiel dann der Fall, wenn es für Ihre Hardware keinen in den Kernel integrierten Treiber gibt und Sie besagten Treiber zur Inbetriebnahme von einer externen Quelle laden und auf dem Server kompilieren müssen. Eine solche Quelle kann zum Beispiel ein Community-Projekt sein, das einen solchen Treiber pflegt, oder auch die Homepage des Hardwareherstellers, wenn dieser seinen Treiber nur in fertig kompilierter Form anbietet und für die Inbetriebnahme auf Ihren Server ein Modul passend zum aktuellen Kernel erstellt werden muss.

Sollte in Ihrem geplanten System zum Beispiel die Grafikkarte die einzige Hardware sein, die erst durch einen solchen sogenannten proprietären Treiber volle Leistungsfähigkeit bringt, sollten Sie von diesen Treiber Abstand nehmen, den mitgelieferten, quelloffenen Treiber, der keine Neukompilierung benötigt, einsetzten und die Kernelquellen nicht installieren. Das geplante System wird eine Server, der keine 3D-Beschleunigung braucht. Nur wenn das System auch die Aufgabe eines Arbeitsplatzes übernehmen soll, wäre dies notwendig - wovon aber ausdrücklich abzuraten ist.

  • Update des Kernels

Für ein komplettes Update des Kernels brauchen Sie die Quellen nicht, da hier ein komplett neuer Kernel mit allen fertig kompilierten Modulen installiert wird. In der Regel wird man dies auch selten machen, da man einen laufenden Kernel eines Servers nur nach Bekanntwerden von Sicherheitsproblemen updatet und den Server neu startet. Nur weil ein neuerer Kernel mit neuen Features erschienen ist, wird man das Update nicht durchführen. Ausnahme von dieser Regel sollten nur sein: Treiber, die Sie sonst extern selbst installiert haben, wurden Teil des Kernels, Sicherheitslöcher wurden geschlossen, signifikante Verbesserungen bei der Stabilität, im Datendurchsatz oder anderen relevanten Stellen. Solche Updates sollten Sie auch nur installieren, wenn diese über die Updatefunktionen von openSUSE angeboten werden.

  • Patchen des Kernels

Gerade wenn es um die Schließung von Sicherheitslücken geht, ließt man in einschlägigen Newsforen sehr häufig, das dazu ein oder mehrerer Patches zur Verfügung steht. Wenn Sie einen solchen Patch installieren wollten, brauchen Sie die Kernelquellen, um den Patch anzuwenden und den Kernel neu kompilieren zu können. Wenn Sie aber zur anvisierten Zielgruppe in einem kleinen Büro gehören, ist von dieser Vorgehensweise abzuraten. Zum einen, weil der Kernel ( und damit die Kernelquellen ) von openSUSE nicht dem Kernel entspricht, den man von der offiziellen Website des Kernelprojekts herunterladen kann ( dieser wurde bereits an vielen Stellen mit eigenen Patches versehen ) und ein Patch zum Schließen einer Sicherheitslücke unter Umständen nicht mehr zum Kernel von openSUSE passt, zum anderen weil das Kompilieren ( bzw. die vorherige notwendige Konfiguration ) keine ganz triviale Handlung ist. Wann immer ein patchen des Kernels, den openSUSE einsetzt, notwendig ist, wird dies durch Novell bzw. dem openSUSE-Projekt für Sie erledigt, und ein entsprechend modifizierter Kernel kann via Update eingespielt werden.

Grundsatz: Experimente am Kernel gehören nicht auf ein Produktionssystem !

  • Handhabung eines Kernelupdates

Wie bereits weiter oben aufgeführt, sollten Sie ein Update des Kernels nur aus gutem Grund durchführen. Sofern Ihnen ein neuer Kernel über die Updatefunktionen von openSUSE angeboten wird, kann dies durchaus als guter Grund betrachtet werden - über diesen Kanal werden nur dann neue Kernel angeboten, wenn es auch Sicherheits- oder Stabilitätsgründen notwendig ist. Eine neue KernelVersion aus einem separatem Entwicklerzweig wird auf diesem Wege nicht angeboten.

Planen Sie ein Update des Kernels ( genauso wie Updates von anderen Komponenten wie zum Beispiel der eingesetzten Serversoftware ) sorgfältig: führen Sie ein Update zu einem Zeitpunkt aus, zu dem niemand / kaum jemand mit dem System arbeitet, zum Beispiel am Abend oder am Wochenende, um eventuelle Ausfälle gering zu halten; kündigen Sie Updates, die einen Neustart des Servers ( wie beim Update des Kernels ) oder Teile der Serversoftware ( wie zum Beispiel des Web- oder eMailservers ) notwendig machen, rechtzeitig an, zum Beispiel über die entsprechende Funktion zur Ankündigung in OpenSmallOffice ( je nach Zeitpunkt des Updates und Einstellung dieser Funktion werden a) alle angemeldeten Anwender sofort darüber informiert, so das offene Arbeiten an Daten ohne Datenverlust beendet werden können und b) erlaubt OpenSmallOffice keine neuerlichen Anmeldungen am System, bis das Update im Ganzen beendet wurde ); stellen Sie sicher, das Sie im Falle eines Schadens während / nach einem Update das System wieder in einen funktionstüchtigen Zustand versetzten können ( durch Einspielen eines Backups, Bearbeiten der durch ein Update geänderten Konfiguration über ein Notfallsystem ).

Sie sollten sich auch vorab damit beschäftigen, wie Sie ein defektes System wieder zum Leben erwecken können. Spielen Sie ein solches Szenario mit einem Testsystem durch, in dem Sie dieses bewusst in einen nicht funktionierenden Zustand versetzten. Zu Ihren Rüstzeug sollte auch das Wissen gehören, wie man ein System, das selbst nicht mehr zum Starten zu bewegen ist, so in ein Notfallsystem einbindet, das alle gespeicherten Daten ( zum Beispiel die der Datenbank, des eMailservers etc. ) sicher auf ein neues System übertragen werden kann. Spielen Sie auch ein solches Szenario mit einem Testsystem durch.

Grafische Desktops

Ein weiterer Punkt, an dem sich Geister scheiden können, ist die Frage, ob man auf einem Server einen grafischen Desktop wie zum Beispiel KDE oder GNOME installiert, oder ob eine minimale grafische Umgebung oder gar der reine Textmodus genügen. Nun, zum einen sollte man dem Grundsatz folgen, das auf einen Server nur so viel Software gehört, wie zum Betrieb notwendig ( demnach würden grafische Desktops nicht dazugehören ), zum anderen sollten Sie aber all die Software installieren, die Sie selbst zum Betrieb des Servers benötigen ( und wenn Sie auf der Konsole nicht zu hause sind, kann ein grafischer Desktop sehr wohl dazugehören ).

Mein Ratschlag: sollte Ihnen die Arbeit in einem (X-)Terminal noch nicht vertraut sein, installieren Sie in Ihrer Testumgebung durchaus einen der grafischen Desktops, erledigen Sie aber möglichst viele Arbeiten mit der Konsole ! Haben Sie im Hinterkopf, das Sie für Arbeiten mittels YaST keinen der grafischen Desktops benötigen - hierzu reichen entweder eine minimale grafische Umgebung oder auch der Textmodus ! Erwarten Sie auch nicht für alle Befehle aus der Konsole - zum Beispiel im Umgang mit dem eMailserver Cyrus-IMAP - eine entsprechende Option in den grafischen Oberflächen ! Einen Teil der Administration müssen Sie auf der Konsole in einem Terminalfenster erledigen !

Jede Software, die Sie installieren, stellt ein potentielles Sicherheitsrisiko dar ! ( wenngleich in manchen Fällen auch nur ein hypothetisches ). Jede Software, die halbwegs aktuell ist, wird mehr oder minder mit Updates auf den neuesten Stand gebracht, so das sich hier Wartungs- und Updateaufwand vergrößern ! Jede Software, die Sie installieren, aber über kurz oder lang nicht nutzen, ist eine 'Dateileiche", die Sie bei Updates, Backups etc. mitschleppen müssen - und ein nachträgliches Deinstallieren kann unter Umständen zu einem beachtlichen Mehraufwand führen !

Grundsatz: Lernen Sie den Umgang mit der Konsole ! Grafische Desktops gehören nicht auf ein Produktionssystem !

Erweiterte Softwareauswahl

Es empfiehlt sich, bereits frühzeitig alle Softwarepakete, die Sie benötigen, beim Installieren der openSUSE-Basis mitzuinstallieren, um Abhängigkeiten zwischen Paketen vor einem ersten Update des Systems aufgelöst zu haben. Dennoch sollte man sich nicht zu sehr von den einfachen Möglichkeiten, die Ihnen das Konfigurationswerkzeug YaST beim installieren bietet, verleiten lassen. Folgen Sie auch hier dem

Grundsatz: Nur wirklich benötigte Pakete installieren, um System- und Dateileichen zu vermeiden !

Entscheiden Sie vor der Installation der openSUSE-Basis, welche Dienste Ihr neuer Server anbieten soll: ist zum Beispiel der neue Server der einzige PC, auf dem Linux laufen wird, sind die zahlreichen linuxspezifischen Netzwerkdienste wie zum Beispiel NFS ( siehe auch NFS, Network File System, in englisch ) oder NIS sicherlich nicht notwendig. Soll außerdem der Server nicht als Dateiserver oder Druckerserver in einem Windowsnetzwerk agieren und benötigen Sie vom Server ausgehend keinen Zugriff auf einzelne Arbeitsplatzrechner, auf denen Windows eingesetzt wird, können Sie wahrscheinlich auch auf Samba verzichten. Sollten Sie aber auf sowohl auf linuxspezifische als auch windowsspezifische Netzwerkdienste verzichten können, sollten Sie unter Umständen Ihr Konzept zur Datensicherung nochmals überdenken ( Sie haben doch sicherlich schon an ein Konzept zur Datensicherung gedacht ? ).

Installationswerkzeug Smart

Als sehr gute Hilfe beim Nachinstallieren von Software bzw. zum Einspielen von Updates hat sich das Tool Smart bewährt. Dieses ist ab SUSE Linux 10.1 Bestandteil der Distribution, muss aber in YaST separat installiert werden. Sollten Sie, so wie ich, eine neuere Version aus dem Repository von 'Guru' bevorzugen, sollten Sie dennoch bei der Installation der openSUSE-Basis Smart installieren ( suchen Sie dazu nach dem Paket 'Smart' und wählen anschließend aus der Ergebnisliste die Pakete 'smart' und 'smart-gui' ), um alle notwendigen Abhängigkeiten zu anderen Softwarepaketen aufzulösen. Nach Abschluss der Installation der openSUSE-Basis können Sie neuere Pakete von der Homepage von 'Guru' herunterladen ( achten Sie dabei auf die korrekte Version von openSUSE sowie der richtigen Architektur ! ). Sie finden die Adresse sowie weitere Informationen zum Nutzen externer Repositories im Wiki auf der Seite Zusätzliche Paketquellen für YaST, generelle Hinweise zu den verschiedenen Werkzeugen zur Paketverwaltung finden Sie unter Paketverwaltung und eine Übersicht, wie man mittels RPM Softwarepakete verwaltet, finden Sie in der Supportdatenbank unter SDB:Rpm - Der Paket-Manager des SuSE Linux.

Nach der Installation der Version aus dem Repository von 'Guru' sollten Sie Chanels, die nicht benötigt werden, entweder entfernen oder aber zumindest deaktivieren ( dazu zählt zum Beispiel der Chanel von 'Packman', aber auch der von 'Guru' selbst ), um nicht beim ersten Update eine Fülle von Programmen zu installieren, die wir nicht benötigen ( zum Beispiel aus dem Bereich Multimedia ). Sie sollten aber beim Betrieb Ihres Servers sowie der üblichen Pflege von Updates überprüfen, ob auch 'Smart' in einer aktuelleren Version vorliegt, und dieses dann händisch von der Guru-Seite laden und installieren.

Natürlich obliegt es auch wieder Ihren eigenen Fähigkeiten und Gewohnheiten, sowohl auf Smart zu verzichten ( Softwarepakete, die ich mittels Smart installiere, lassen sich auch über YaST installieren - folgen Sie dazu einfach den Hinweisen auf den oben genannten Wiki-Seiten ! ) als auch beim Einsatz des Tools wahlweise mit der Kommandozeilenversion oder der GUI-Version zu arbeiten ( folgen Sie dazu bitte den Anleitungen auf der oben genannten Wiki-Seite Smart ).

Inhaltsverzeichnis

Siehe auch

innerhalb von openSUSE

Weblinks

Artikel bei Wikipedia

zurück zur Projektseite