Georg Ruß
Schneider Schreibgeräte GmbH Wernigerode
28.09.2001
e-mail
URL: http://www-e.uni-magdeburg.de/russ/docs/install-suse.htm
last update: 08.03.2002

Dokumentation zum Suse-Linux-7.2-Professional-Server

Inhaltsverzeichnis

Installationshinweise
Einstellung der Sprache bei Root
Samba-Aktualisierung
USV-Anschluß, -Installation und -Konfiguration
Warum RAID?
Test des RAID-Controllers im laufenden Betrieb
3DM (3Ware Disk Management Utility), Überwachung des Controllers im laufenden Betrieb
VNC installieren
Samba-Installation und Konfiguration
Externe Links
Root-Freigabe erstellen
Nachbildung von Novell-Strukturen
Deaktivieren der Login-Shell
Konfiguration auf den Clients


Installationshinweise:
-3ware Controller einbauen, Platten anschließen
-im RAID-Bios den Array (RAID1) erstellen und abwarten

-im Rechner-BIOS das Booten von CD aktivieren
-Suse-DVD ins entsprechende DVD-Laufwerk und davon booten

Die komplette hier dargestellte Grundinstallation (bis zum nächsten Absatz) dauert ca. 45 Minuten auf Pentium3-1000, 512 MB RAM, RAID1

-Dialoge zur Sprache der Installation und Länderinfo entsprechend bestätigen

-Suse-Benutzerinfo: Roland Schneider

Die Festplatte wird als SCSI-Drive angezeigt, das kommt daher, dass der RAID-Controller im Kernel als SCSI-Gerät implementiert ist, also nicht weiter verwunderlich.
-Plattenpartitionierung von SuSE durchführen lassen, legt automatisch /boot, / und swap-Partition an
-Bootsektor auf Festplatte schreiben lassen

-Installationsart: Standard-System ohne Office, dann erweiterte Auswahl
+ Netzwerk- und Server-Dienste (Samba ist dann schon dabei)
+ Verfügbare Quellen (falls diese doch mal gebraucht werden sollten)
+ KDE komplett
+ Spiele (?)

-ca. 3,4 GB zu kopieren (Zeit: ca. 30 min für die 2459 Pakete)

-Hochfahren nach dem Schreiben des LILO-Bootsektors

-Monitor passend auswählen und einstellen

-nicht ungeduldig werden, wenn "Die Installation wird abgeschlossen" erscheint, es kann bis zu 7 Minuten dauern

-Rest der Hardware konfigurieren
-Netzwerkkarte (IP-Adresse, Hostname, Subnetzmaske)
-Soundkarte (wurde durch den Raid-Controller allerdings deaktiviert, Ressourcenüberschneidung)
-Installation abschließen


-----Installation beendet, Konfiguration beginnt-----

-als Root einloggen, Sprache bei Root durch Rechtsklick auf die Uhr -> Date-Time-Format auf Deutsch umstellen (oder so belassen)

-Aktualisierung von Samba auf Version 2.2.1 (befindet sich auf CD) wie folgt:
-Datei von CD (Samba-Verzeichnis) in /root (oder /tmp) kopieren: samba-2.2.1a-14.i386.rpm
(macht sich ganz gut mit dem Midnight Commander: Terminal starten und "mc" eingeben)
-Terminal starten (aus Startmenü)
-yast eingeben (Yet Another Setup Tool)

-Paketverwaltung > Pakete einspielen > Quelle auswählen > Samba-Update-Verzeichnis auswählen
-Abfragen beantworten und Hinweise von yast beachten
-falls gewünscht, telnet-Zugriff als Root zulassen (Sicherheitsrisiko); geht wie folgt: yast > Administration des Systems > Einstellungen Systemsicherheit > Allgemeines zur Systemsicherheit
(dort entsprechende Auswahl treffen)
-yast beenden


USV-Installation und Konfiguration

-Hardware-Anschluss sollte kein Problem sein
-für die Software-Installation die modifizierte deutsch-englische Anleitung befolgen (
PowerChute-Installationsanleitung, wurde getestet und für gut befunden, ggf. korrigiert und mit Supportmaterial von APC ergänzt)
-immer dran denken, für Software-Installation als Root einzuloggen
-Die Konfiguration der Shutdown-Parameter oder des Scheduled Shutdown erfolgen über die X-Oberfläche des Powerchute Programms:
-ins Installationsverzeichnis von Powerchute wechseln und an der Konsole ./xpowerchute eingeben.
-die X-Oberfläche wird dann gestartet und die USV ist komfortabel bedienbar.



Warum RAID?
Da der Linux-Server als Fileserver dienen soll, ist eine Datenredundanz enorm wichtig.
Um zusätzlich zur täglichen Datensicherung auch das eigentliche System abzusichern, haben wir uns für RAID (Redundant Array of Independent (oder Inexpensive) Disks) entschieden.
Bei RAID gibt es verschiedene Level, wir haben uns für die einfachste Lösung entschieden: zwei gleich große IDE-Festplatten und ein echter Hardware-RAID-Controller von 3Ware. (Escalade 6410)
Der verwendete RAID-Level nennt sich RAID-1 oder Mirroring; dabei werden die beiden Festplatten "gespiegelt", beide enthalten dieselben Daten. Die Administration dieser Spiegelung übernimmt der Controller auf der PCI-Steckkarte.
Wenn also ein Datenpaket vom Betriebssystem ankommt, wird es gleichzeitig auf beide Festplatten geschrieben. Der Vorteil liegt auf der Hand: Wenn eine der beiden Festplatten ausfallen sollte, sind trotzdem alle Daten auf der anderen Festplatte vorhanden und der Server kann problemlos weiterlaufen.
Die defekte Festplatte kann in aller Ruhe ausgetauscht werden, der Array wird neu erstellt (Daten von der übriggebliebenen Festplatte werden auf die neue Platte gespiegelt) und das System kann weiterlaufen. Der Controller unterstützt Hot Swap, so dass alle Aktionen auch im laufenden Betrieb möglich sind, da aber das Management Tool nicht unter SuSE 7.2 läuft, müssen die Aktionen vorerst im Bios des Controllers erfolgen, dazu muss neu gebootet werden. (siehe nächster Absatz)

Test des 3Ware-Raid-Controllers
Der Controller Escalade6410 wurde folgendermaßen getestet:
-bei laufendem Betrieb (zwei Festplatten) das Stromkabel einer Festplatte abziehen
-die Konsole bringt die Meldung "Bad response..."
-"reset succeeded"

-System läuft problemlos weiter

Zur Überwachung solcher Festplattendefekte existiert das Tool 3DM (3Ware Disk Management). Nachdem ich dieses von der 3Ware Homepage geladen hatte, stellte sich heraus, daß bisher nur die SuSE 7.0 als höchste Version unterstützt wird.
Dieses Tool unterstützt laut Beschreibung auch die komplette Konfiguration des RAID-Controllers im laufenden Betrieb, so auch den nach einem Plattenausfall fälligen Rebuild des Raid-Arrays. Da aber dieses Management Utility derzeit nicht unter SuSE Linux 7.2 zum Laufen zu bringen ist, muss der Rebuild leider im BIOS des Controllers erfolgen, dazu ist ein Reboot notwendig. Der Server läuft aber auch mit einer Platte weiter, so daß genügend Zeit bleiben sollte, eingeloggte Benutzer zu benachrichtigen und einen kontrollierten Shutdown durchzuführen.
Meine Anfrage beim 3Ware Support ergab auch, daß die SuSE 7.2 derzeit noch nicht unterstützt wird und daß für Modifikationen am Installationsskript und selbst-kompilierte Treiber keine Haftung übernommen wird.
Somit muss vorerst auf e-mail-Benachrichtigung beim Ausfall einer Platte und Konfiguration im laufenden Betrieb verzichtet werden.
Als Alternative wäre es noch denkbar, ein Hot-Spare-Laufwerk einzusetzen, also zusätzlich zu den zwei IDE-Platten noch eine dritte IDE-Platte in den Server zu schrauben und anzuschließen. Der RAID-Controller unterstützt HotSpare, d.h. wenn aus einem RAID-Array eine Festplatte ausfällt, wird die als HotSpare ("heißer Ersatz") definierte Platte automatisch verwendet.
Es wurde auch noch getestet, wie sich der Controller beim Abziehen eines IDE-Kabels von einer Festplatte verhält: Die Meldungen von Linux sind wie oben, nur nach dem Wieder-Einstecken des Kabels wird das Dateisystem "verhackstückt".
Nach dem Reboot kamen mehrere Fehlermeldungen beim Einloggen als Root und die Oberfläche (KDE2 -K Desktop Environment) war nicht mehr benutzbar. Allerdings ist beim Einsatz von Wechselrahmen (noch einzubauen) zwangsläufig vorgegeben, daß mit dem Umdrehen des Schlüssels erst der Strom von der Festplatte abgeschaltet wird, bevor die IDE-Kabel-Verbindung durch das Herausziehen getrennt wird.



Installation des 3Ware-Disk-Management Utilities
Zum Zeitpunkt des Erstellens dieser Anleitung (Herbst 2001) war für SuSE Linux 7.2 noch keine Management-Software verfügbar.
Jetzt, im März 2002 ist diese von 3Ware downloadbar, sodaß sich eine Installation dieser Software zur Administration des RAID-Arrays anbot.

Gleichzeitig wurde noch eine "Hot-Spare"-Festplatte vom Typ Fujitsu MPG3409AT eingebaut, identisch zu den beiden bereits vorhandenen Platten im Array.
Diese kann beim Booten im BIOS des Controllers als Hot-Spare-Drive (Ersatzlaufwerk im Falle eines Ausfalles einer Disk im Array) festgelegt werden.
Prinzipiell hat sich damit die Datensicherheit noch weiter erhöht: Raid-1 plus Hot-Spare-Laufwerk

Damit die Management-Software zum Einsatz kommen kann, sind drei Updates notwendig:
1. Firmware-Update des Controllers
2. Treiber-Update unter Linux für den RAID-Controller
3. eigentliche Software-Installation unter Linux

zu 1.
Das Update mußte in einem fremden Rechner erfolgen, da sich der Server weigerte, von MS-DOS-Diskette zu booten. Das bedeutete, Controller ausbauen, in anderen Rechner und dort das Update ausführen.
Das eigentliche Update war dann selbsterklärend, wie auch in der readme-Datei des Firmware-Updates beschrieben:
(i) von MS-DOS-Bootdiskette starten;
(ii) Diskette mit dem Firmware-Update (4 Dateien: "flash.exe", "Prom6xxx.img", "readme.txt", "upgrade.bat") einlegen, update.bat starten und die Anweisungen am Bildschirm befolgen

Danach wurde der Controller wieder an seinen angestammten Platz im Server geschraubt, die Platten wieder an die entsprechenden Ports gehängt und das Treiber-Update konnte erfolgen.

zu 2.
Das Treiber-Update war ähnlich simpel, die Dokumentation zum RAID-Controller und zum Software-Update sind sehr ausführlich:
(i) als Root einloggen
(ii) die zuvor ungezippten Treiber (relevant hierfür: "3w-xxxx.o") ins folgende Verzeichnis kopieren: /lib/modules/2.4.4-4GB/kernel/drivers/scsi/
(Der Befehl hierfür, falls die Datei auf Floppy im Hauptverzeichnis liegt und man sich in selbigem befindet:
copy 3w-xxxx.o /lib/modules/2.4.4-4GB/kernel/drivers/scsi/3w-xxxx.o)
(iii) dann noch "lilo" eingeben und das Update wäre beendet

zu 3.
Das Software-Update erwies sich als ebenso einfach (relativ selten unter Linux)
(i) die zwei Dateien entpacken (aus Archiv: "3DM-Linux-Update.zip"); ergibt "3dm-lnx.tgz" und "install.3dm"
(ii) ins Verzeichnis der entpackten Dateien wechseln und das Installationsskript ausführen: "./install.3dm" (als Root natürlich)

Die Angaben bei der Installation am besten beim Standard lassen, alles kann später noch geändert werden.
Nach der Installation auf den Server (bzw. hier auf den 3DM-Daemon) zugreifen über: http://IP-des-Servers:Port-wie-bei-der-Installation
Der Autostart des 3DM-Daemons funktionierte nicht, da die Links in den rc.*-Verzeichnissen (für die verschiedenen Runlevel) zwar angelegt wurden, aber falsche Verweise hatten. Nachdem der Link jeweils auf /etc/init.d/init.d/3dm geändert wurde, startete der Daemon automatisch.


Installation von VNC (Virtual Network Computing, grafische Fernbedienung)
-Suse-DVD ins Laufwerk
-über Kontrollzentrum > Software VNC nachinstallieren (einfach nach "vnc" suchen)

-Abfrage bestätigen
-an Konsole "vncserver" eingeben, Meldung abwarten, bei Erstinstallation Passwort vergeben
-von Remote-Rechner (VNC Client) aus VNC starten, Rechnername und Nummer eingeben (z.B. swr01:1), Passwort eingeben
-Passwortänderung kann über "vncpasswd" (telnet oder Konsole) erfolgen
Hinweis zur grafischen Oberfläche: VNC ist in diesem Fall keine echte Fernbedienung, es erfolgt ein separater Login auf dem Server, eine komplett neue Session. Wenn man im Terminal KDE startet (K Desktop Environment, grafische Bedienoberfläche), erscheint die Oberfläche zwar, aber beim Bedienen selbiger gibt es Programmabstürze.
Meiner Meinung nach ist die Konsole (telnet) bzw. das normale Terminal viel mächtiger als jedes GUI, so dass auf VNC prinzipiell verzichtet werden kann.


Samba-Installation und Konfiguration
-Samba in den Autostart tun, d.h. über grafische Konfigurationsoberfläche Startmenü > Kontrollzentrum > System > rc.config >Start-Variablen
> start_smb auf yes setzen
> start_inetd auf yes setzen (Port-Erkennung und startet zugehöriges Programm, nötig für Remote-Administration per SWAT)
(alternativ kann auch die rc.config mit dem Editor bearbeitet werden)

-SWAT (Samba Web Administration Tool) freischalten:
Startmenü > Kontrollzentrum > Netzwerk/Basis >inetd.conf editieren
> ein, mit benutzerdefinierter Konfiguration
> nach unten scrollen und swat aktivieren
> Konfiguration abspeichern (dauert einen kurzen Moment)

-Samba kann anschließend über Webbrowser remote-administriert werden
(http://SWR01:901 oder http://136.8.8.3:901, danach Benutzername und Passwort eingeben, für Konfiguration "root" verwenden)


Damit Samba als Anmeldeserver dienen kann, müssen in der smb.conf (Configurationsdatei für Samba) mindestens folgende Einstellungen vorgenommen werden:

[global] # hier werden Einstellungen vorgenommen, die für alle Shares und generell für Samba gelten sollen
workgroup = SWR-NEU # Name der Arbeitsgruppe, in der Samba als Anmelde- (Domain-)Server fungieren soll
netbios name = SWR01 # Name des Servers, wie er in der Netzwerkumgebung erscheint; sollte auch in der hosts-Datei stehen
interfaces = 136.8.8.3/255.255.252.0 # IP-Adresse und Subnetzmaske
encrypt passwords = Yes # verschlüsselte Passworte für die Anmeldung am Server verwenden (ab Windows NT SP3 bzw. Windows 98)
# wenn auf "no", werden nur unverschlüsselte Passworte akzeptiert, auf "yes" auch verschlüsselte
map to guest = Never # Alle Anfragen von Benutzern mit ungütigem Paßwort werden abgewiesen
username map = /etc/users.map # Abbildung von Novell- oder Windows-Namen auf Unix-Namen, z.B.
root=Administrator
superv=supervisor
keepalive = 0 # Voreinstellung, bestimmt, wie oft Pakete vom Server zum Client geschickt werden, an denen der Server erkennt, ob der Client noch im Netz ist
logon script = logon.bat # Name des Skriptes, das beim Zugriff auf eine Share vom Server geladen und client-seitig ausgeführt wird;
# der komplette Pfad ergibt sich dabei aus der Kombination des [netlogon]-Shares mit der angegebenen Datei;
domain logons = Yes # bestimmt Samba als Domain-Anmeldeserver
os level = 2 # kann die Wahl zum Master-Browser innerhalb der Domain zugunsten von Samba beeinflussen, hat aber hier keine Wirkung, da kein weiterer Anmeldeserver vorhanden ist.

spezielle Shares, die nicht als solche Freigabe erscheinen:

[homes] # dynamische Freigabe der Homeverzeichnisse der Benutzer
comment = home-directory # Kommentar bzw. Erläuterung, die bei den Freigabe-Details auf Windows-Seite erscheint
read-only=no # Schreibzugriff entsprechend den Berechtigungen erlaubt
create mask=0744 # Voreinstellung; bestimmt, mit welchen Modi (Rechten) Dateien im Homeverzeichnis erstellt werden
browseable=no # die Share ist in der Netzwerkumgebung nicht sichtbar, allerdings trotzdem vorhanden
# bei einer Verbindung wird das HomeDirectory des angemeldeten Benutzers verbunden
[netlogon] # spezielle Share, die z.B. Login-Skripte beinhalten kann
path=/var/lib/samba/netlogon # gibt an, wo die Share lokal zu finden ist, Verzeichnis frei wählbar, nur mit Zugriffsrechten muß aufgepaßt werden
browseable=no # Share nicht sichtbar, aber trotzdem vorhanden

Das Logon-Script sieht folgendermaßen aus:

net use N: \\heiko1\sys # (verbindet die Freigabe \\heiko1\sys als das lokale Laufwerk N:)
net use M: \\swr01\homes # (verbindet die dynamische Freigabe \\swr01\homes als lokales Laufwerk M:)
net time \\swr01 /set /yes # (synchronisiert die Uhrzeit des Clients mit dem Server)

Die gesamte Datei muß, da sie auf den Windows-Clients ausgeführt werden soll, im DOS-Format gespeichert werden.

Zur Erklärung: Sobald sich der Benutzer beim Server angemeldet hat, wird aufgrund der vorhandenen [homes]-Section von Samba eine Freigabe erstellt (in diesem Fall sein Homeverzeichnis). Die [homes]-Section stellt somit eine dynamische Freigabe dar, was es dem Admin erspart, für jeden Benutzer spezifische Freigaben anzulegen.
Es existiert ein globales Login-Script (logon.bat), welches im netlogon-Verzeichnis (definiert über die [netlogon]-Share) abgelegt werden muß.

Damit sich überhaupt Benutzer anmelden können, müssen diese sowohl bei Samba (/etc/smbpasswd) als auch bei Linux selbst (/etc/passwd) existieren.
Die Passwörter von Samba und Linux müssen dabei nicht identisch sein. Zum Angleichen der Linux-Passwörter an die Samba-Passwörter gibt es einen Parameter bei Samba, der die Synchronisation bewerkstelligt:
unix password sync = false/true
Wenn allerdings wie
hier beschrieben die Login-Shell deaktiviert wird, kann sich der User direkt am Server sowieso nicht mehr einloggen. Das Anlegen eines Benutzers kann bei Linux komfortabel über grafische Oberfläche erfolgen:
Terminal starten > yast2 eingeben


nach Klicken auf "Benutzer und Gruppen" öffnet sich folgendes Fenster:



Nach dem erfolgreichen Anlegen der Benutzer auf dem Linux-Server und Vergabe von Gruppenzugehörigkeiten müssen die Benutzer auch bei Samba noch angelegt werden. Dies erfolgt wieder remote (oder nach Wunsch auch direkt am Server) über SWAT und sieht ungefähr wie folgt aus:

Wie jedes Linux-Programm ist auch Samba sehr gut dokumentiert. Die beste existierende Dokumentation ist bereits in Samba enthalten, jeder Parameter in SWAT ist direkt mit der HTML-Hilfe von Samba verlinkt.


Hier noch weitere Links:

http://www.samba.org
http://www.zdnet.de/linux/artikel/netzwerk/200102/samba_00-wc.html
http://www.sambahq.de
http://www.blattform.de/planungshilfen/edv/trickkiste/linsrv/Linux_5.htm
http://home.nexgo.de/thomas.litsch/index.htm
http://www.tecchannel.de/betriebssysteme/248/index.html
http://www.linuxdoc.org/HOWTO/SMB-HOWTO.html



Erstellen einer Root-Freigabe für den Supervisor:


-SWAT starten
-Shares auswählen
-Name der Root-Freigabe eingeben (z.B. root-swr01)
-"Create Share" anklicken
-Advanced View auswählen
-bei path "/" angeben (dementsprechend ist alles sichtbar)
-read-only=no
-browseable=no (nicht sichtbar, kann aber vom Root verbunden werden)
-bei "admin users" superv (oder wie auch immer der Admin heißt) angeben
-nicht vergessen, nach dem Eingeben der Optionen "Commit Changes" (Änderungen übernehmen) anzuklicken


Novell-Verzeichnisstruktur auf Linux-Ebene nachbilden

Bisher bekommt jeder Novell-Benutzer beim Einloggen in Novell sein Laufwerk F: verbunden. Darin befinden sich alle Verzeichnisse, für die der Benutzer die Berechtigung besitzt.
Dies funktioniert unter Linux nicht so einfach, da zwar die Berechtigungen genauso vergebbar sind, aber die User dann alle Verzeichnisse sähen, was nur unnötig für Verwirrung sorgen würde.
Als Lösung für dieses Problem bieten sich symbolische Links an; diese sehen auf Windows-Seite wie Verzeichnisse aus und funktionieren auch so; z.B. kann das Suchen nach einer Datei unter Windows im Linux-Hauptverzeichnis zu einer Endlosschleife führen, wenn in Unterverzeichnissen wieder symbolische Links auf das übergeordnete Verzeichnis existieren.
Nun werden in /home Verzeichnisse angelegt, die die Namen der anzulegenden Gruppen tragen. (Anlegen der entsprechenden Novell-Gruppen)
In diesen Verzeichnissen werden Sym-Links angelegt, die den bisherigen Berechtigungen entsprechen (in der Gruppe Everyone z.B. nur Link auf Exchange)

In die Homeverzeichnisse der Benutzer werden beim Einloggen die Links aus den Gruppenverzeichnissen kopiert, zu deren Gruppe der Benutzer gehört.

Deaktivieren der Shell für die Benutzer
-geschieht am besten gleich beim Anlegen der Benutzer, indem die Login-Shell deaktiviert wird
-falls der Benutzer schon existiert: durch editieren der passwd-Datei:
Beispiel aus der /etc/passwd:
superu:x:501:100:Georg Russ:/home/superu:/bin/bash
Das "/bin/bash" definiert die Standard-Konsole, dieses wird geändert zu "/bin/false", somit ist die Shell für den Benutzer deaktiviert und er kann über Telnet keinen Schaden anrichten und sich auch nicht mehr direkt am Server einloggen.


Einstellungen auf den Clients
Damit sich Windows95/98-Clients beim Linux-Server anmelden können, muss bei diesen in den Eigenschaften der Netzwerkumgebung die Anmeldung an der Domäne aktiviert sein. Die Domäne ist in diesem Fall der Name der Arbeitsgruppe, in der sich der Samba-Server befindet.