SuSE 7.2

SUSE Linux 7.2

Installation: Wow, daß haut mich um. CD einlegen (nicht in ein Weckglas) und schon gehts los. Die Installation geht sehr flott von sich, ohne Reboot, ohne lästige Fragerei und mit Plug&Play. Ja, Sie haben richtig gelesen nicht Plag&Pray. Beispiele:

Die Maus: Die Logitech Maus wird nun richtig erkannt sogar mit wheel rad

Die Netzwerkkarte: Der richtige Realtek-Treiber (NE2000)

Die Soundkarte: Auch diese wird automatisch erkannt (Creative Soundblaster PCI128)

Zwar muß man - wie unter dem alten Windows noch üblich - die Eingänge/Ausgänge einschalten, aber dann funzts auch.

Sogar die richtige Grafikkarte mit zugehörigem Monitor wird erkannt. Hier muß man zwar u.U. noch von Hand die Auflösung anpassen (z.B. 1600er Auflösung) aber mit den Default-Werten liegt Linux recht gut.

Wermutstropfen: Die Supportdatenbank befindet sich nicht - wie in der SuSE-Hilfe angegeben - unter file:/doc/sdb/de/html/index.html sondern unter file:/usr/share/doc/sdb/de/html/index.html.

Die run-levels befinden sich nun nicht mehr unter /sbin/init.d sondern unter /etc/init.d

Sofern nicht ein Window-Manager gestartet wird läßt sich die Start-Konsole über Alt + F10 anzeigen. Zurück gehts mit Alt + F1. Bei kde kann man sie mit STRG + ALT + F10 aufrufen, mit STRG + ALT + F7 gehts zurück.

Nach YOU (YaST Online Update): Läßt sich die SuSE Supportdatenbank nicht mehr im Konqueror öffnen, dann sollte man unter den Einstellungen:

für html und plain den Netscape Communicator an erster Stelle setzen. Steht dieser noch nicht zur Verfügung dann muß er installiert werden und den Hinzufüge-Button wählen:

Für Spartaniker:

Wer beim Booten von Linux nicht den SuSE Startbildschirm möchte:

in /etc/lilo.config die Zeile vga = 771 in vga = normal abändern. Siehe sdb-Artikel SuSE-Startbildschirm deaktivieren.

rlogin: In 7.2 wurde die Sicherheit Groß geschrieben mit dem Ergebnis, daß rlogin nicht mehr ohne weiteres funktioniert, denn dafür sollte ssh die bessere Wahl sein; für Windows kommt z.B. putty in Frage. Um trotzdem rlogin zuzulassen ist folgendes notwendig:

1. In /etc/rc.config den Eintrag ROOT_LOGIN_REMOTE="yes" setzen
2. SuSEconfig starten
3. In /etc/inetd.conf das Kommentarzeichen # am Anfang der Zeile shell stream tcp nowait root /usr/sbin/tcpd in.rshd -L entfernen (Danke Andreas Keyk). Dies ist nur für den User root notwendig.
4. inetd.conf neu einlesen mit killall -HUP

Sollte der Dienst nicht neu gestartet werden, so liegt das daran, daß inetd gar nicht gestartet wurde. Dies kann man von Hand nachholen - mit inetd - bzw. in der Datei

5. /etc/init.d/boot.local ans Ende inetd schreiben.

telnet: damit man via telnet auf dem Rechner zugreifen kann, muß inetd gestartet sein. Der telnetd kann in der /etc/inetd.conf gestartet werden.

Erweiterte Rechte für Benutzer: Zuständig dafür ist der Befehl sudo; die Steuerung dafür wird im file /etc/sudoers beschrieben. Dies kann nur von root editiert werden. Eine Hilfe - neben man sudoers - gibts in Form von visudo. Visudo überprüft dabei die Syntax des Files auf Richtigkeit. Dabei wird defaultmäßig der vi zum edieren verwendet, welches sich aber mit export EDITOR=nedit einstellen läßt.

Beispiel: robin ist ein User

# Cmnd alias specification
Cmnd_Alias SHUTDOWN = /sbin/shutdown

# User privilege specification
robin  Rechnername=SHUTDOWN

Wer zudem die Passwortabfrage abschalten möchte kann das wie folgt machen:

# User alias specification
User_Alias    ANWENDER = robin, marco, michael

# Override builtin defaults
Defaults:ANWENDER    !authenticate

oder aber für alle Befehle

robin    ALL=NOPASSWD:ALL

Linux-Server von einem Linux-Client mit YaST2 konfigurieren: ssh -X Rechnername

Kopieren mit ssh: scp user@rechner:datei user@rechner2:datei

SSH: Wer die erneute Passwortabfrage unterdrücken möchte, kann sich auf dem Client mit ssh-keygen einen Schlüssel erzeugen, wobei die Abfrage nach einer passphrase leer zu lassen ist (2x Return). Anschließend die Zeilen in ^~/.ssh/identity.pub der Datei ^~/.ssh/authorized_keys des Servers anhängen. Die identity.pub Datei auf dem Client kann gelöscht werden. Der privat key ^~/.ssh/identity auf dem Client muß die Rechte 600, also lesen + schreiben nur für den user, haben. Dies gilt für protocol 1.

Für protocol 2 muss ssh-keygen entweder mit der Option ssh-keygen -t rsa für die RSA Authentifizierung oder ssh-keygen -t dsa aufgerufen werden. Dies gilt für OpenSSH v2.9.9 bzw. SuSE 7.2. Für OpenSSH v2.1.1 (=SuSE 7.0) ist die Option -d, wobei nur die DSA-Authentifikation unterstützt wird. Dabei werden 2 Files mit Namen id_rsa und id_rsa.pub bzw. id_dsa und id_dsa.pub erzeugt. Der Privat-Key ist klar: Bleibt auf dem Client unter ^~/.ssh, der Public-Key muss nun auf den Server kopiert werden. Wohin hängt von der Version von OpenSSH ab: ssh -V gibt darüber Auskunft welche man hat. Mit 'man ssh' und 'man ssh-keygen' muss man sich die Orte heraussuchen: Es können die Files ^~/.ssh/authorized_keys, ^~/.ssh/authorized_keys2, ^~/.ssh2/authorized_keys und evtl. ^~/.ssh2/authorized_keys2 sein. Diese Public-Keys sollten nur Schreibrechte für den User haben, Gruppe und Welt nur Leserechte.
Natürlich funktioniert nun das Kopieren mittels scp nicht mehr so einfach bei Protokol 2: scp -oProtocol=2 ...

Installataion + Start von OpenSSH v3.4p: Wer von SuSE 7.0 updaten möchte der muß auch noch OpenSSL auf den neuesten Stand bringen. Sowohl die Installation von OpenSSL als auch die von OpenSSH verlief bei mir problemlos. Aber damit wird noch nicht der neue sshd gestartet. Wer sich das Script /sbin/init.d/sshd bei SuSE 7.0 bzw. /etc/init.d/sshd bei SuSE 7.2 ansieht, der kann mit diesen Parametern den alten Daemon stoppen und den neuen starten. Aber Vorsicht: bevor man den neuen startet sollte man sich auch noch die Datei README.privsep ansehen. Es sind hierzu noch einige Vorarbeiten notwendig:

chown root:sys /var/empty
chmod 755 /var/empty
groupadd -g 74 sshd
useradd -u 74 -g sshd -c 'sshd privsep' -d /var/empty -s /bin/false sshd
(vorher mit grep ':74:' /etc/passwd kontrollieren, ob 74 noch frei ist)

Nun kann man den Daemon neu starten. Aber auch hier tritt ein neuer Fehler auf: Es lässt sich nur eineinziges Mal einloggen, danach scheint der Daemon in die Knie zu gehen. Sollte das einloggen via ssh/putty nun funktionieren so kann man das Script zum Starten des Daemon entsprechend abändern. Wenn defaultmäßig bei der Installation die Pfade nicht verändert wurden so liegt das Programm sshd (nicht zu verwechseln mit dem gerade zu bearbeitenden Script)  nun unter /usr/local/sbin/sshd. Die man-pages dürften ebenfalls die aktuellen sein da auch die Variable MANPATH angepasst wurde, /usr/local/man steht an erster Stelle des Suchpfades.

Einige Dateien regeln noch die Handhabbarkeit von rlogin:

Display umlenken: Mit xhost +hostname auf dem Client das Öffnen eines Fensters erlauben + auf dem Server mit export DISPLAY=hostname:0 den Bildschirm setzen. Z.B. auf 192.168.22.1 = michael: xhost +192.168.22.5 (od. xhost +michael3) und auf Rechner 192.168.22.5 = michael3: export DISPLAY=192.168.22.1:0 (od. export DISPLAY=michael:0). Besser ist aber ssh -X hostname.

ssh: Hat der Rechner, auf den man sich mittels ssh einloggen möchte, kein Passwort, so muß man in der Datei /etc/sshd_config den Eintrag

PermitEmptyPasswords

auf yes setzen.

In /etc/ssh/sshd_config können Parameter für sshd eingetragen werden; s. man sshd

Kommando eines Remote-Rechners über ssh im Hintergrund starten: nohup Kommando &

Die Firewall: Wer dies unter 7.2 einrichten möchte sollte schon mal einen Monitor zum Server schleppen. Aber alles der Reihe nach. Zu erst müssen einige Variablen in /etc/rc.config gesetzt werden:

START_FW="yes"
IP_FORWARD="yes", wenn als TDSL-Server eingerichtet

Die eigentliche Konfiguration erfolgt ja in der /etc/rc.config.d/firewall.rc.config und ist auch ausführlich beschrieben. Hier aber die erste Überraschung in der Bemerkung des Files: "Für Kernel 2.4 - was hier installiert ist - benötigt man ipchains, da Kernel 2.4 iptaibles standardmäßig verwendet und das SuSE-Firewall-Script noch auf ipchains basiert. Gut, also noch ipchains nachinstalliert. Wer /etc/rc.config.d/firewall.rc.config entsprechend angepaßt hat und ein reboot durchführt kann nun entweder den Server zum Monitor schleppen oder umgekehrt. Das Script ist so wirkungsvoll daß ssh und rlogin nicht mehr geht.

Aber was für eine Überraschung erlebt man wenn der Monitor am Server hängt: SuSE gibt eine Fehlermeldung aus daß das ganze nur mit dem Firewall2-Script funktioniert.

Weitere Einzelheiten demnächst auf dieser Homepage.

Der Bootmanager LILO: Linux kann nun auch jenseits der 1024 Zylinder booten. In /etc/lilo.config wird bei der Installation der richtige Parameter lba32 eingetragen. Trotzdem hat mein ASUS-Board P55T2P4 mit aktueller BIOS-Version V0207 final, HX-Chipsatz und 128MB EDO RAM und einer IBM 10GB Festplatte Probleme. Nur jeder 2. Bootvorgang fürht zum Erfolg.

Automounter: Ein Knöpfchen für die Aktivierung des Automounters ist nicht vorhanden, weshalb ich diesen Daemon über YAST2 einschalte. Die Prozedur zum Einrichten Mountpoints hat sich nicht geändert.

KDE: Wenn die Icon's in der kde-Leiste zu groß sind so läßt sich das wie folgt ändern:

~/username/.kde/shara/config/kickerrc

dort nach dem Eintrag [menus] suchen und den Wert für

MenuEntryHeight=16

oder 22 statt 32 eintragen