SDB:KIWI Kochbuch GNOME System

Wechseln zu: Navigation, Suche


Bau eines Abbildes, das eine minimierte GNOME-Dektop-Umgebung verwendet. Anpassung des Basisbeispiels um Auto-Login zu ermöglichen, Firefox automatisch zu starten und Anpassung von GNOME.
Getestet mit openSUSE Empfohlene Artikel Verwandte Artikel
Icon-checked.png

Icon-manual.png Icon-help.png




Eine minimale GNOME-Desktop-Umgebung - unser fünftes Rezept


Während unseren vorhergehenden Rezepte auf die verschiedenen Abbild-Typen gerichtet war, die wir mit KIWI erstellen können, ist dieses Rezept mehr auf den Inhalt der Desktop-Umgebung und einige Konfigurationsfragen ausgerichtet. Wir werden zu Beginn auf das Beispiel eines SUSE-min-GNOME schauen und dann das Beispiel erweitern, um Autologin zu ermöglichen und zeigen wie eine spezielle Anwendung von selbst startet (Autostart-Funktion).

Der Standard-Abbild-Typ, das für dieses Gerät gerät verwendet wird, ist ein VMware-Abbild, da es maximale Flexibilität zum Testen liefert. Sie können Qemu, VirtualBox oder VMware Player oder Server verwenden, um das sich ergebende Abbild zu testen. Die Abbild-Beschreibung ist ebenso konfiguriert, um eine LiveCD/DVD zu erstellen. Aber Sie werden nicht das Kommandozeilen-Argument --type iso für den Erstellungsschritt benötigen, um ein ISO-Abbild zu erzeugen.

Kurz gesagt, lassen Sie uns beginnen.

GNOME

Minimale GNOME Desktop-Umgebung

Vorbereitungszeit:

  • 30 min

Kochzeit:

  • 10 - 12 min abhängig von der Bandbreite (siehe vorherhehende Diskussion) und Hardware des Hosts

Zutaten:

  • ein laufendes openSUSE 11.4 System
  • ein openSUSE 11.4 Repository
  • den neuesten KIWI-Werkzeugsatz installiert
  • installiertes kiwi-doc Paket
  • über 1 GB freien Speicherplatz


Das Rezept basiert auf das suse-min-gnome-Beispiel, das unter /usr/share/doc/packages/kiwi/examples/suse-11.x/suse-min-gnome zu finden ist und mit dem kiwi-doc-Paket installiert wurde.


Der grafische Anmeldebildschirm

Um einen grafischen Anmeldebildschirm zu erhalten, müssen wir den X-Server in unser Abbild einbeziehen. Darum müssen wir den Eintrag

 <package name="xorg-x11-server"/>

in den Abschnitt <packages> eintragen. In diesem Beispiel wollen wir GNOME als Desktop-Umgebung und GDM als den grafischen Anmeldemanager verwenden. Darum tragen wir

 <package name="gdm"/>

in unseren <packages> -Abschnitt ein. Beachten Sie, dass die Spezifizierung von gdm in Kombination mit den Attributen patternType="plusRecommended" und patternPackageType="plusRecommended" des Elements <packages> geeignet ist, eine minimale GNOME-Oberfläche zu erzeugen.

Eine gute Sache ist, wenn das System ebenso Perl, Python und einen Editor (Vim) enthält.

 <package name="python"/>
 <package name="perl"/>
 <package name="vim"/>

Ein etwas knifflige Sache war in der Vergangenheit immer die Konfiguration des X-Servers. Eine Möglichkeit wäre, die Verwendung eines generischen Framebuffers, der auf der Datei xorg.conf basiert, als eine Overlay-Datei in unserem Verzeichnisbaum des KIWI-Konfigurations-Verzeichnisses. Aber, wenn Sie die Struktur von unserem Beispiel untersuchen, werden Sie sehen, dass die einzige verwendete Overlay-Datei ist etc/init.d/boot.local. Dank des Autokonfigurationsmodus in sax2 können wir einfach den X-Server beim Starten konfigurieren, ohne Benutzereingriff. Der Inhalt von boot.local ist recht kurz und einfach, wie unten gezeigt wird.

 # Erzeuge die X-Server-Konfigurations-Datei, wenn sie jetzt noch nicht vorhanden ist
 if [ ! -f /etc/X11/xorg.conf ]; then
     /usr/sbin/sax2 -c 0 -a -i &>/dev/null
 fi
Wenn Sie proprietäre Grafiktreiber von ATI oder NVIDIA-Karten packen, verwenden Sie nicht die Option -i.

Seit openSUSE 11.2 konfiguriert sich der X-Server automatisch selbst. So dass die Overlay-Datei boot.local nicht länger benötigt wird. Darum enthält ein Beispiel mit openSUSE 11.2 (und höher) keine Overlay-Dateien.

Mit der X-Serverkonfiguration müssen wir sicherstellen, dass GDM gestartet ist und das System im Runlevel 5 startet. Diese "Magie" erfolgt in config.sh unter Verwendung der von KIWI bereitgestellten Funktionen. Die interessierenden Funktionsaufrufe sind wie folgt:

 baseUpdateSysConfig /etc/sysconfig/windowmanager DEFAULT_WM gnome
 baseUpdateSysConfig /etc/sysconfig/displaymanager DISPLAYMANAGER gdm
 baseSetRunlevel 5
 suseConfig

Funktionen, die in config.sh verfügbar sind, sind in zwei Kategorien unterteilt, in SUSE-spezifische und von der Distribution unabhängige Funktionen. SUSE-spezifische Funktionen haben den Präfix suse wie bei suseConfig und eine von der Distribution unabhängige Funktion hat einen Präfix base wie bei baseSetRunlevel.

Die Funktion baseUpdateSysConfig verwendet 3 Argumente:

  • den vollstandig qualifizierten Pfad der Datei im Abbild, das modifiziert werden soll,
  • die Variable, die in dieser Datei gesetzt werden soll und
  • den Wert der Variablen.

Beachten Sie, dass die Funktion baseUpdateSysConfig keine neue Variable erzeugt. Sie arbeitet nur mit Variablen, die bereits in der Konfigurationsdatei existieren. Indem wir unseren ersten Aufruf von baseUpdateSysConfig als Beispiel machen, wird das zu dem folgenden Eintrag in /etc/sysconfig/windowmanager in unserem Abbild führen.

 DEFAULT_WM="gnome"

Die Funktion baseSetRunlevel setzt den Standard-Runlevel des Geräts. In unserem Fall wollen wir eine komplette grafische Oberfläche für mehrere Benutzer mit Netzwerk. So sei der Runlevel auf 5 gesetzt.

Nach den Änderungen in der Konfigurationsdatei rufen wir suseConfig auf, um die Änderungen auf das System anzuwenden.

Die vordefinierten Funktionen, die in config.sh verfügbar sind, sind in KIWI Image System Cookbook dokumentiert. Oder alternativ können Sie die Manpages für config.sh wie folgt aufrufen:

# man kiwi::config.sh


Das ist die ganze Konfigurationsarbeit, die wir zu machen haben, um unser auf ein minimales GNOME basierendes Abbild zum Laufen zu bringen. Lassen Sie uns das Abbild erzeugen und das überprüfen.

# kiwi --prepare /usr/share/doc/packages/kiwi/examples/suse-11.1/suse-min-gnome -root /tmp/mymingnome
# kiwi --create /tmp/mymingnome -d /tmp/mymingnome-result


Das wird eine Weile dauern, da eine Menge Daten vom openSUSE-Repository heruntergeladen werden müssen. Um den Prozess zu beschleunigen, können Sie eine Kopie des Beispiels machen und die Repository-Definition so modifizieren, dass sie auf eine örtliche Installationsquelle weist. Der Prozess wurde in Mit dem Kochen beginnen beschrieben.

Wenn der Erstellungsprozess abgeschlossen ist, können Sie Ihr Abbild unter Verwendung Ihrer bevorzugten Virtualisierungsumgebung testen.

# qemu /tmp/mymingnome-result/suse-11.1-gnome-demo.i686-1.0.1.vmdk


Vorsichtsmaßnahmen in Bezug auf die Abbild-Bezeichnung und den Bau im 64 bit Modus beachten Sie wie vorher unter Mit dem Kochen beginnen Abschnitt: Vorsichtsmaßnahmen bemerkt.

Sobald der Boot-Prozess abgeschlossen ist, werden Sie mit dem bekannten GDM-Anmeldebildschirm begrüßt.

Das Passwort für Root und Tux ist das Gleiche, wie in den vorangegangenen Beispielen und ist in der Datei config.xml auf linux gesetzt.

Die folgenden Abschnitte gehen auf Konfigurationsoptionen ein, die einzeln oder in Kombination angewendet werden können. Jeder Abschnitt beschreibt die Änderungen im KIWI-Konfiguration-Verzeichnis /tmp/gnome-exa, gefolgt von einem Vorbereitungs- und Erstellungs-Schritt. Sie können wählen, den Vorbereitungsschritt zu überspringen, indem Sie die Änderungen in den ungepackten Abbild-Baum /tmp/mymingnome einbringen, gefolgt vom Erstellungsschritt. Obwohl diese Abkürzung für dieses Beispiel Zeit spart, ist es äußerst riskant, wenn es in einem richtigen Projekt verwendet wird. Änderungen, angewandt direkt auf das ungepackte Abbildverzeichnis, werden leicht vergessen. Und nicht auf das KIWI-Konfigurationsverzeichnis angewendet, gehen verloren, wenn das Abbild neu erstellt wird.

Konfiguration von Autologin


In diesem Schritt werden wir die Konfiguration des Beispiels modifizieren. Darum sollten Sie eine Kopie des Basisbeispiels machen, um eine funktionierende Struktur zu erstellen.

# cp -r /usr/share/doc/packages/kiwi/examples/suse-11.1/suse-min-gnome /tmp/gnome-exa


Das Aufsetzen eines Auto-Login für den Benutzer Tux in unserem Beispiel ist sehr einfach. Fügen Sie nur die folgende Zeile zu der Datei /tmp/gnome-exa/config.sh (oder zu config.sh an dem Ort, den Sie gewählt haben) hinzu:

 baseUpdateSysConfig /etc/sysconfig/displaymanager DISPLAYMANAGER_AUTOLOGIN tux

Nun bauen Sie das Abbild erneut auf und testen es. Sie werden sehen, dass der Benutzer Tux automatisch im System angemeldet wird.

# kiwi --prepare /tmp/gnome-exa -root /tmp/mygnome-exa
# kiwi --create /tmp/mygnome-exa -d /tmp/mygnome-exa-result
# qemu /tmp/mygnome-exa-result/suse-11.1-gnome-demo.i686-1.0.1.vmdk


Vorsichtsmaßnahmen in Bezug auf die Abbild-Bezeichnung und den Bau im 64 bit Modus beachten Sie bitte, wie vorher unter Mit dem Kochen beginnen Abschnitt: Vorsichtsmaßnahmen beschrieben.

Nun nachdem wir Autologin konfiguriert haben, könnte es ebenso nützlich sein, ein Programm automatisch mit dem Login zu starten. Der nächste Abschnitt wird zeigen, wie man die Umgebung konfiguriert, um genau das zu machen.


Starte ein Programm beim Login


Der Mechanismus, um automatisch ein Programm zum Laufen zu bringen, ist unabhängig von der Autologin-Funktion, die im vorangegangenen Abschnitt beschrieben wurde. So können Sie wählen, den Setup der Autologin-Funktion auszulassen, und können ein Programm automatisch gestartet bekommen, wenn ein Benutzer sich anmeldet.

Für diesen Abschnitt werden wir mit der Arbeit in unserem Arbeitsverzeichnis, das wir vorher eingerichtet haben, fortfahren. Das heißt, wir werden die Datei /tmp/gnome-exa verwenden. Das Programm, das automatisch gestartet werden soll, sei Firefox. Aber das kann natürlich jedes andere Programm auch sein, das Sie gern automatisch starten lassen wollen.

Zuerst erstelle das Verzeichnis, das GNOME zum automatisch Start von Programmen verwendet.

# mkdir -p /tmp/gnome-exa/root/home/tux/.config/autostart


Ersetzen Sie /tmp/gnome-exa, wenn Sie einen anderen Ort wählen, um diesem Beispiel zu folgen. Ersetzen Sie Tux, wenn Sie einen anderen Benutzer in config.xml einrichten wollen.

Nun verwenden Sie Ihren bevorzugten Editor, um die datei firefox.desktop in /tmp/gnome-exa/root/home/tux/.config/autostart zu erstellen. Der Dateiname ist nicht wichtig, aber es ist brauchbar, einen Dateinamen zu haben, der Anzeigt, zu welchem Programm sie einen Bezug hat. Fügen Sie die folgende Zeile zu dieser Datei hinzu und sichern Sie diese.

 [Desktop Entry]
 Type=Application
 Name=Firefox
 Exec=firefox
 Icon=
 Comment=

Nun sind wir bereit zu Umbau und Test.

# rm -rf /tmp/mygnome-exa
# kiwi --prepare /tmp/gnome-exa -root /tmp/mygnome-exa
# kiwi --create /tmp/mygnome-exa -d /tmp/mygnome-exa-result
# qemu /tmp/mygnome-exa-result/suse-11.1-gnome-demo.i686-1.0.1.vmdk


Vorsichtsmaßnahmen in Bezug auf die Abbild-Bezeichnung und den Bau im 64 bit Modus beachten Sie bitte, wie vorher unter Mit dem Kochen beginnen Abschnitt: Vorsichtsmaßnahmen beschrieben.

Wenn Sie ein maßgeschneidertes Script haben, dass Sie via Overlay-Mechanismus einbeziehen, können Sie zum Beispiel den kompletten Pfad in der Datei *desktop anlegen.

 [Desktop Entry]
 Type=Application
 Name=My-Script
 Exec=/opt/mysetup/myscript
 Icon=
 Comment=

Möchten Sie die Datei /opt/mysetup/myscript, benötigt sie natürlich die Ausführungserlaubnis.

Das schließt den Autostart des Beispiels ab. Im nächsten Abschnitt werden wir uns mehr zur GNOME-Anpassung ansehen.



Einige GNOME-Anpassungen


Desktop Icon Beseitigung

Wenn Sie einen sauberen Dektop mögen, d.h. keine Icons versperren die Sicht auf Ihren wunderschönen Hintergrund, dann können Sie die Icons, die momentan gezeigt werden, wenn Sie Ihr Abbild starten, mit den folgenden Schritten löschen.

Zuerst löschen wir die Standard-Icons Help und openSUSE, indem wir das Folgende in /tmp/mygnome-exa/config.sh/tt> nach dem Aufruf von <tt>suseConfig einfügen. Die Anforderung ist, dass die Position dieses Abschnitts vor dem Aufruf von baseCleanMount sein.

 #======================================
 # Remove system default desktop icons
 #--------------------------------------
 rm -f /usr/share/dist/desktop-files/*

Das kömmert sich um 2 der 4 Icons. Beachten Sie, dass das Auswirkungen auf das ganze System hat. Das bedeutet, dass diese Icons nun von des Desktops aller Benutzer des Systems verschwunden sind.

Wenn Sie gern die Icons für den Home-Ordner und den Mülleimer deaktivieren wollen, haben Sie zwei Optionen, eine System weite Modifikation und eine Modifikation je Benutzer. Beide Möglichkeiten werden unten gezeigt.

Zuerst schauen wir auf die Beseitigung der Desktop-Icons, bezogen auf jeden Benutzer.


Beseitigung der Home- und Mülleimer-Icons je Benutzer

Bei GNOME ist die Konfiguration für Anwendungen und den Desktop im Home-Ordner jedes Benutzers im versteckten Verzeichnis .gconf abgelegt. Das ist das Verzeichnis, das aktualisiert wird, wenn Sie Modifikationen mit dem gconf-Editor-Werkzeug durchführen. Um die Desktop-Icons zu löschen, erstellen Sie ein Verzeichnis in Ihrem Konfigurationsbaum wie folgt:

# mkdir -p /tmp/mygnome-exa/root/home/tux/.gconf/apps/nautilus/desktop


Nun erstellen Sie mit Ihrem bevorzugten Editor die Datei %gconf.xml in dem vorher erstellten Verzeichnis und fügen den folgenden Inhalt ein.

 <?xml version="1.0"?>
 <gconf>
       <entry name="trash_icon_visible" mtime="1108553948" type="bool" value="false">
       </entry>
       <entry name="home_icon_visible" mtime="1108553943" type="bool" value="false">
       </entry>
 </gconf>

Das schaltet die Ansicht der Desktop-Icons aus. Details über das Format finden Sie unter GNOME Dokumentation.

Es ist natürlich schön, wenn Sie nur einen Benutzer auf Ihrem System einrichten. Haben Sie jedoch viele Benutzer und würden gern die Icons per Standard verstecken, dann ist es einfacher, Sie machen die Einstellungen für das ganze System. Der nächste Abschnitt beschreibt, wie das funktioniert.

Entfernen der Icons für Home und Mülleimer als Standard

Die System weiten Einstellungen werden standardmäßig in der Datei /etc/gconf/gconf.xml.vendor/%gconf-tree.xml gespeichert. Diese Datei wird in unser Abbild eingefügt durch das Paket gconf2-branding-openSUSE. Die Wiedererstellung der Datei von Grund auf, nur um einige Modifikationen zu machen, ist zu viel Aufwand. Der leichteste Weg ist, die Datei vom laufenden System in Ihr KIWI-Konfigurations-Verzeichnis zu kopieren, folgendermaßen:

# mkdir -p /tmp/mygnome-exa/root/etc/gconf/gconf.xml.vendor
# cp /etc/gconf/gconf.xml.vendor/%gconf-tree.xml /tmp/mygnome-exa/root/etc/gconf/gconf.xml.vendor


Nun haben Sie eine grundlegende Konfiguration, mit der Sie arbeiten können. Berarbeiten Sie diese Datei mit Ihrem bevorzugten Editor und suchen Sie nach <dir name="nautilus">. In diesem Abschnitt werden Sie einen Unterabschnitt <dir name="desktop"> finden. Vor der Schließmarkierung </desktop> fügen Sie folgendes ein:

 <entry name="trash_icon_visible" mtime="1108553948" type="bool" value="false">
 </entry>
 <entry name="home_icon_visible" mtime="1108553943" type="bool" value="false">
 </entry>

Sichern Sie diese Datei. Und Sie haben alles eingerichtet.

Sie können nun das Abbild wieder wie zuvor aufbauen und es testen. Wenn das System läuft, werden die Icons nicht sichbar sein.

Damit können Sie alles über GNOME anpassen, entweder auf Benutzerbasis oder System weit. Die Struktur der Verzeichnisse folgt dem Layout der Funktionen im Werkzeug gconf-editor. Für Benutzer bezogene Anpassungen erzeugen Sie das geeignete Verzeichnis und bringen die Datei %gconf.xml in dem Verzeichnis unter. Für eine System weite Konfiguration erstellen Sie eine dir-Sektion in der Datei  %gconf-tree.xml .

Als ein anderes Anpassungsbeispiel wird der letzte Abschnitt unten die Anpassung des Desktop-Hintergrundes zeigen.

Anpassung des Desktop-Hintergrundes

In diesem Abschnitt werden wir uns auf die Anpassung des Benutzerdesktops konzentrieren. Starten wir mit der Einstellung unseres gewünschten Hintergrundbildes in den KIWI-Konfigurationsbaum.

# mkdir -p /tmp/gnome-exa/root/usr/share/backgrounds


Erstellen Sie ein Verzeichnis, in das Sie das Hintergrundbild, das Sie verwenden wollen, speichern. Nun Kopieren Sie Ihr Bild (in unserem Beispiel myImage.png genannt) in das neu erstellte Verzeichnis.


cp path_to_image/myImage.png /tmp/gnome-exa/root/usr/share/backgrounds


Nun erstelle das Verzeichnis für die Konfigurationsdatei, um das Hintergrundbild festzulegen.

# mkdir -p /tmp/gnome-exa/root/home/tux/.gconf/desktop/gnome/background


Mit Ihrem bevorzugten Editor erstellen Sie die Datei %gconf.xml im gerade erzeugten Verzeichnis mit dem folgenden Inhalt.

 <?xml version="1.0"?>
 <gconf>
       <entry name="primary_color" mtime="1237339199" type="string">
               <stringvalue>#393937374b4b</stringvalue>
       </entry>
       <entry name="secondary_color" mtime="1237339199" type="string">
               <stringvalue>#424252528f8f</stringvalue>
       </entry>
       <entry name="color_shading_type" mtime="1237339200" type="string">
               <stringvalue>solid</stringvalue>
       </entry>
       <entry name="picture_options" mtime="1237339199" type="string">
               <stringvalue>stretched</stringvalue>
       </entry>
       <entry name="picture_filename" mtime="1237339199" type="string">
           <stringvalue>/usr/share/backgrounds/Tux-Linux_1024x768_openSUSE.png</stringvalue>
       </entry>
 </gconf>


Geschafft

Bauen Sie Ihr Abbild neu und testen es. Ihr Bild ist nun Ihr Desktop-Hintergrund.

Kurze Zusammenfassung

Die ersten zwei Abschnitte in diesem Beispiel sind gleichermaßen auf KDE anwendbar, indem man gdm durch kdm und gnome durch kde ersetzt. Der Anpassungsabschnitt des Beispiels gilt nur für GNOME.

Unter Verwendung der vordefinierten Funktionen in config.sh können Sie eine große Anzahl von Konfigurationsänderungen im Abbild durchführen, ohne die Verwendung von Overlay-Filtern. Die Verwendung von Overlay-Filtern erlaubt es Ihnen, die Erscheinung von GNOME an Ihre Wünsche im Abbild anzupassen.

Haftungsausschluss

Wenn Sie eine auf den Benutzer bezogene Konfiguration von GNOME anwenden und Autologin verwenden, dann könnte die Konfiguration nicht konsequent von gconfd abgeholt werden. Wenn Sie Autologin verwenden, ist es sicherer, jegliche Konfigurationsänderungen auf einer System weiten Basis anzuwenden.