cyberpolis

Es ist schwierig Firewall-Filterregeln für NFS zu definieren, da NFS nicht auf bestimmte Ports beschränkt ist. Man kann NFS jedoch derart konfigurieren, das die verwendeten Ports festgelegt sind. Markus Hd hat hier eine Lösung im Ubuntu-Forum veröffentlicht.

Man muss in der Konfigurationsdatei /etc/default/nfs-common folgende Optionen setzen:

STATDOPTS="--port 4000 --outgoing-port 4001"

Falls man auch den NFS-Server durch die Firewall filtern lassen möchte, muss man auch die Konfiguartionsdateil /etc/default/nfs-kernel-server ändern und folende Optionen setzen:

RPCMOUNTDOPTS="--port 4002"

Die Shorewall-Firewall erlaubt es Actions zu definieren. Die entsprechende Action (z.B. diese) zu Hand, kann man diese einfach in /etc/shorewall/rules hinzufügen. Zuvor muss man die Action jedoch noch nach /etc/shorewall kopieren und in der Datei /etc/shorewall/actions registrieren. Dazu fügt man eine Zeile mit

AllowNFS

hinzu.

Auch wenn der alte serielle Anschluss eines PC (RS-232 Schnittstelle) heute nicht mehr zeitgemäß scheint, kann er trotzdem in einigen Fällen noch sehr nützliche Dienste leisten. Man kann ihn z.B. verwenden, um einen Rechner ohne Monitor und Tastatur mit Ein- und Ausgaben versorgen zu können. Besonders interessant ist die serielle Konsole im Zusammenhang mit virtuellen Maschinen, auf die typischerweise der gerade erwähnte Fall, keinen Monitor und keine Tastatur zu haben, zutrifft. Im Folgenden werde ich die Einrichtung einer seriellen Konsole unter Ubuntu näher beschreiben.

Im Verzeichnis /etc/event.d findet man die standardmäßig eingerichteten Konsolen tty1 bis tty7. Zum Anlegen der neuen seriellen Konsole kopiert man einfach die Konsole tty1 nach ttyS0 und passt den Inhalt an. Die letzte Zeile wird durch folgende ersetzt:

exec /sbin/getty -L 9600 ttyS0 vt100

Darüber hinaus kann man auch die Runlevel, in denen die Konsole gestartet bzw. gestoppt werden soll, anpassen. Für eine virtuelle Maschine sollte die serielle Konsole in jedem der verwendeten runlevel verfügbar sein, d.h. wir nehmen keine Änderung an den Einstellungen der runlevel vor.

Nach obiger Änderung ist die serielle Konsole bereits verfügbar. Meist möchte man jedoch auch die Meldungen sehen, die ein virtueller Server während des bootens ausgibt. Hierzu fügt man am Anfang der Datei /boot/grub/menu.lst (Konfigurationsdatei des Bootmanagers grub) folgende beiden Zeilen ein

serial --unit=0 --speed=9600 --word=0 --parity=no --stop=1
terminal serial

Dem Kernel (Zeilen, die mit "kernel" beginnen) geben wir auch noch ein paar zusätzliche Paramter mit (einfach anhängen)

console=tty0 console=ttyS0,9600n8

Nun sollte, nachdem grub neu geschrieben wurde (mittels "grub-install Ziellaufwerk"), beim nächsten Neustart alles über die neu eingerichtete serielle Konsole ausgegeben werden.

Wer den Sicherheitsanforderungen der heutigen Zeit nachkommt und möglichst komplizierte Passwörter für SSH verwendet, muss sich dieses Plus an Sicherheit mit deutlichem Mehraufwand beim Einloggen erkaufen. Es gibt jedoch auch noch eine andere Möglichkeit: Man generiert ein asynchrones Schlüsselpaar, plaziert den öffentlichen Schlüssel auf dem Zielsystem und und lässt SSH die Authentifizierung (mit Hilfe der Schlüssel) erledigen. So erspart man sich das lästige Einloggen.

Naja, zugegeben - man kann auch ein Passwort für die Verwendung des Schlüssels setzen, was zur Folge hat, dass man doch ein Passwort eingeben muss, aber man kann dies auch einfach weglassen. Nun aber zur Beschreibung der Vorgehensweise, um sich von Rechner r1, mit dem Account a1 auf dem Rechner r2 mit dem Account a2 einzuloggen:

Zuerst wird das Schlüsselpaar für SSH generiert.

ssh-keygen -t rsa

Man wird daraufhin aufgefortert einen Namen für die Schlüssel anzugeben. Der Einfachheit halber, nehme ich mal an, dass man den vorgeschlagenen Namen "/home/a1/.ssh/id_rsa" übernommen hat. Das Passwort, das man nun eingeben soll, kann man leer lassen.

Im nächsten Schritt wird der öffentliche Schlüssel auf Rechner r2 übertragen, wozu man ein letztes Mal das Passort von a2 auf Rechner r2 eingeben muss:

cat /home/a1/.ssh/id_rsa.pub | ssh a2@r2 'cat >> .ssh/authorized_keys'

Benutzename und Rechnername muss man natürlich ersetzen. Voraussetzung für obige Befehlszeile ist, dass auf Rechner r2 bereits das Verzeichnis ".ssh" existiert. Sollte das nicht der Fall sein, kann man es mit folgendem Befehl zuvor anlegen:

ssh a2@r2 mkdir .ssh

Zur Konfiguration der Authetifizierung über LDAP bietet der OpenLDAP Ubuntu Server Guide eine gute Anleitung. Jedoch tritt bei aktuellen Ubunut-Versionen in der dritten Befehlszeile

sudo auth-client-config -a -p lac_ldap

folgende Fehler auf:

Error in updating the file: 'pam_account' not found
--
Errors found. Aborting (no changes made)

Die Lösung des Problems wird im Ubutu-Forum diskutiert: Obige Befehlszeile muss durch die beiden Zeilen

sudo auth-client-config -t nss -p lac_ldap
sudo pam-auth-update ldap

ersetzt werden. Danach kann man problemlos mit dem OpenLDAP Ubuntu Server Guide fortfahren.

Ausgangspunkt war das Problem ldap zu starten. Als ldap-Benutzer "openldap" schlug dies fehl, funktionierte jedoch als "root" Benutzer. Dies ist normalerweise ein Hinweis auf fehlerhafte Rechteeinstellungen. Also startete ich ldap mittels "strace" und eine Zeile, die immer wieder auftauchte, war folgende:

access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)

Nach einem Blick ins Dateisystem stellte ich fest, dass "/etc/ld.so.nohwcap" nicht vorhanden war. Also suchte ich im Internet nach Hinweisen und kam zu dem Ergebnis, dass es sich um ein undekomentiertes Feature handelt. Soweit, so gut, aber wie muss diese Datei aussehen und welche Bedeutung hat sie?

Ein Foreneintrag, der Erklärungen lieferte, hätte mich fast dazu verleitet, ihm zu folgen, was fatale Auswirkungen gehabt hätte. Darin stand geschrieben, dass ein Anlegen von "/etc/ld.so.nohwcap" dazu geführt hätte, dass das System schneller arbeitet. Die darin beschriebene Ursache deutet jedoch darauf hin, dass es ein Problem mit hardwarespezifischen Bibliotheken gab.

Die Lösung des Rätsels lieferte Joey Hess: Dass die Datei "/etc/ld.so.nohwcap" nicht vorhanden ist, ist völlig normal. Diese Datei dient dazu, das Verwenden Hardware-optimierter Bibiotheken zu deaktivieren.