History

Hardware¶

Hardware-Erkennung auf SLX-Clients¶

Zentrale Komponente der automatischen Konfiguration ist eine Hardware-Erkennung. Diese übernimmt die weitgehende Einrichtung des Systems. Das passiert im Stage3 hauptsächlich durch hwautocfg. Die Einrichtung der Basishardware (Systeme ohne X) erfolgt ebenfalls durch dieses Skript, die Einrichtung von Xorg durch das XorgPlugin, für einige generelle Fragen hierzu siehe auch XorgServer.

Im Hintergrund kommt hwinfo (SuSE-Projekt) zum Einsatz. Entscheidend ist eine passende Zuordnung von Kernelversion zur Version der HW-Info-Datenbank. Deshalb sind die Versionen 13.11, 14.19, 15.3 und 15.21 verfügbar.

Ergänzung der hwinfo Datenbank¶

Die primäre, fest einkompilierte Datenbank (libhd.so) von hwinfo kann durch Einträge in Dateien unterhalb von /var/lib/hardware/ids (Stage3) extern ergänzt werden. Letztere kann man nehmen, um die Hardware-Erkennung anzupassen (die Einträge hier überschreiben die Einträge in der Hauptdatenbank).
Die "externe Datenbank" befindet sich unter /opt/openslx/share/ramfstools/hwinfo/db/hwinfo.db.tgz und wird bei jedem Boot im Stage3 entpackt.

Vorgehen:

tar xzfv /opt/openslx/share/ramfstools/hwinfo/db/hwinfo.db.tgz -C /tmp
cd /tmp/var/lib/hardware
vi hd.ids ids/20.xorg-x11-driver-video # In den beiden Dateien die Einträge modifizieren bzw. hinzufügen. Syntax schaut man sich einfach an den anderen Einträgen ab.
Wieder packen und nach /opt/openslx/share/ramfstools/hwinfo/db kopieren. ACHTUNG: Nach einem make install im Repository wird dieser Ordner wieder überschreiben. Deshalb kann die Datei auch nach ./initramfs/tools/hwinfo/db/hwinfo.db.tgz im Repository kopiert werden. Diese Datei bei Updates von uns bitte entsprechend wieder anpassen, falls notwendig.
slxconfig-demuxer durchlaufen lassen und dann sollte er eigentlich was anderes erkennen.
Dann im Stage 3 (debug=3) hwinfo --gfxcard

Für direkte Tests bietet sich im Stage3 das Ändern in /var/lib/hardware/... an.

Device-Zugriff¶

Nur zum Teil ist Hardware fest mit der Maschine verbunden: Mittels USB, Firewire, SCSI, ... lassen sich Geräte auch nachträglich anschliessen oder wieder abklemmen. Unabhängig davon sollte dem Benutzer des Desktops (GUI die sich direkt auf die Maschine bezieht an der er sitzt - sonst gibts noch ganz andere Probleme) Zugriffsrecht auf die Hardware erhalten (und andere bspw. remote angemeldete Benutzer nicht).

Das Einbinden der Hardware regelt inzwischen "udev", die später möglichen Zugriffe werden von verschiedenen Diensten verwaltet.

SuSE10.2¶

http://forgeftp.novell.com/resmgr/web/ ist die Homepage vom "resmgrd". Dort hat der Maintainer auch ein Bild der Zusammenhänge gezeichnet [http://forgeftp.novell.com/resmgr/web/#id2484325]

Wie gleich im ersten Satz klargestellt wird, ist resmgr heute keine Resource Manager mehr. Diese Aufgaben werden von Skripten erfüllt, die der resmgr beim Login des Nutzers aufruft.

So sorgt /etc/resmgr.conf.d/99-desktop.conf zum Beispiel dafür, dass alle Nutzer mit "tty=:*" der Resmgr-Klasse (!= UNIX-Gruppe) "desktop" (definiert in /etc/resmgr.conf) hinzugefügt werden.

/etc/resmgr.conf.d/90-desktop-console.conf realisiert die Anbindung an PolicyKit. Der Datei ist direkt entnehmbar, welche /usr/bin/polkit-resmgr-* Skripte bei der An- oder Abmeldung ausgeführt werden.

Ebenso verhält es sich mit /etc/resmgr.conf.d/91-hal-resmgr.conf ...

PolicyKit¶

Spielt bei neueren Distros eine Rolle ...

Einbinden von Platten-Partitionen¶

Generell kann über die globale Variable "hw_local_disk" festgelegt werden, ob die lokale Festplatte überhaupt berücksichtigt werden soll oder nicht. Das kann gerade in Multiboot-Umgebungen sinnvoll sein, um den Zugriff auf das komplette Device explizit auszuschliessen. Diese Platten-IDs werden nachfolgend von hwsetup behandelt:

ID44 - /tmp Mount wird immer neu angelegt
ID45 - permanentes Filesystem - Mount nach /var/scratch
ID46 - spezielles OpenSLX Teil mit a) boot, b) Home c) ConfTGZ (nicht implementiert)
ID82 - Einbindung von SWAP (erfolgt)
ID83 - Passiver Eintrag in /etc/fstab

OpenSLX