Die Konfiguration wird in der Datei /etc/X11/xorg.conf vorgenommen:

Section "Serverflags"
Option "DontZap" "no"
EndSection


In dem Abschnitt "Serverflags" können durchaus mehr Angaben enthalten sein. Entscheidend ist die Zeile mit der Option "DontZap". Setzt man sie auf "no", so ist die oben besagte Tastenkombination verwendbar, ansonsten (Zeile weglassen oder auf "yes" setzen) zeigt sie keine Wirkung. Letzteres kann auch sinnvoll sein, wenn man Nutzern verbieten möchte, den X-Server zu beenden.

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.

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.

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

Nun aber zur Lösung des Problems: Hierzu muss man in den Einstellungen (Menü Edit/Preferences) den Ton (Registerkarte Audio) oder besser gesagt, die Tonausgabe (Audio Output) auf ALSA stellen. Zuvor war bei mir komischerweise OSS ausgewählt, obwohl ich eigentlich ALSA verwende. Als Gerät (Audio Device) ist "plughw:0,0" eingetragen. In der KDE-Systemkonfiguration ist dieses Gerät auch vorhanden, aber irgendwie scheint dies so nicht zu funktionieren. Anstatt dessen muss man "default" eintragen und - oh Wunder - nun funktioniert auch die Audioausgabe ohne Probleme.

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.

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.

Trotzdem gab es auch hier ein paar kleine Probleme: Nachdem alle Server die Startkonfiguration erhalten haben und auf einem der Server die Backend-Konfihuration eingespielt war (Punkt8), sollte eigentlich alles automatisch auf die anderen Server übertragen werden. Dies war jedoch nicht der Fall, sondern anstatt dessen fand sich im syslog folgende Fehlermeldung, die sich immer wieder wiederholte:

Mar  9 19:00:03 prometheus slapd[16207]: <= bdb_equality_candidates: (entryUUID)
not indexed
Mar  9 19:00:33 prometheus last message repeated 31 times
Mar  9 19:01:03 prometheus last message repeated 24 times

Dies weist darauf hin, dass eine Überprüfung der Daten zweier Server auf Gleichheit fehlschlägt. Als Kandidat zur Verwendung zum Testen auf Gleichheit schlägt LDAP "entryUUID" vor. Hierzu findet schlägt logandzwon im Ubuntuforum folgendes vor: Zuerst legt man eine Datei "change_index.ldif" mit folgendem Inhlat an:

dn: olcDatabase={1}hdb,cn=config
changetype: modify
replace: olcDbIndex
olcDbIndex: uid,entryUUID,uniqueMember,uidNumber,gidNumber,memberUid,objectclass eq

Diese Änderungen kann man dann mittels

ldapmodify -x -D cn=admin,cn=config -W -f change_index.ldif

durchführen. Es werden also mehrere eindeutige Datenfelder, darunter auch "entryUUID", für einen Index verwendet. Da dieser zum Vergleichen der Daten verwendet wird, ist das Problem an dieser Stelle gelöst.

Noch ein kleiner Hinweis am Rande: Das Übertragen auf die anderen Server geschieht automtisch. Hierbei muss man den einzelnen LDAP-Instanzen manchmal etwas Ziet geben und darf nicht zu ungeduldig sein.