[ zurück ] [ Inhalt ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 10 ] [ 11 ] [ 12 ] [ 13 ] [ 14 ] [ 15 ] [ A ] [ weiter ]

Debian Reference (version 1)
Kapitel 2 - Debian-Grundlagen

Dieses Kapitel liefert grundlegende Informationen über das Debian-System für Nicht-Programmierer. Für die ultimativen Informationen vergleiche:

aufgeführt unter Referenzen, Abschnitt 15.1.

Wenn Sie nach nicht allzu ausführlichen "wie geht" Erklärungen suchen, wechseln Sie direkt nach Debian-Paketverwaltung, Kapitel 6 oder in andere relevante Kapitel.

Dieses Kapitel basiert auf Dokumenten aus der "Debian-FAQ", größtenteils umgeschrieben, um dem gewöhnlichen Debian-Systemadministrator den Einstieg zu erleichtern.

2.1 Die Debian-Archive

2.1.1 Verzeichnisstrukturen

Die Software, welche für Debian paketiert wurde, ist in einem der vielen Verzeichnisbäume auf jedem Debian-Mirror durch FTP oder HTTP verfügbar.

Die folgenden Verzeichnisse können auf jedem Debian-Mirror unter dem debian Verzeichnis gefunden werden:

dists/:

Dieses Verzeichnis enthält die "Distributionen" und ist für den Zugriff auf die aktuell verfügbaren Pakete in Debian ausgelegt. Einige alte Pakete, die Contents-*.gz-Dateien und die Packages.gz-Dateien sind immer noch hier zu finden.

pool/:

Die neue Position aller Debian-Pakete.

tools/:

DOS-Hilfsmittel zum Erzeugen von Bootdisketten, Partitionieren der Festplatte, Komprimieren/Dekomprimieren von Dateien und zum Booten von Linux.

doc/:

Die grundlegenden Debian-Dokumentationen wie die FAQ's, Erläuterungen zum Fehler-Melde-System, usw.

indices/:

Enthält die Maintainers-Datei (Liste aller Paketbetreuer) und die override.*-Dateien.

project/:

Hauptsächlich Material, welches nur für Entwickler von Interesse ist, wie z.B.:

project/experimental/:

Dieses Verzeichnis enthält Pakete und Hilfsmittel, welche noch entwickelt werden und sich noch im Alpha-Stadium befinden. Benutzer sollten keine Pakete von hier verwenden, da sie selbst für den Erfahrensten gefährlich und schädlich sind.

project/orphaned/:

Pakete, welche von ihrem alten Betreuer aufgegeben wurden und aus der Distribution zurückgezogene Software.

2.1.2 Debian-Distributionen

Normalerweise befinden sich drei Debian-Distributionen im dists-Verzeichnis. Dies sind die stable-, die testing- und die unstable-Distribution. Manchmal gab es auch eine frozen-Distribution (zurzeit ist es einfach ein Entwicklungsschritt der testing-Distribution). Jede Distribution ist ein symbolischer Link in das entsprechende Verzeichnis mit einem Kodenamen im dists-Verzeichnis.

2.1.3 Die stable-Distribution

Pakete der stable-Distribution, Debian Lenny (5.0), befinden sich im stable- (symbolischer Link zu lenny/) Verzeichnis:

Heutzutage befinden sich Pakete in Ergänzung zu obigen Verzeichnissen unterhalb des pool-Verzeichnisses (Das pool-Verzeichnis, Abschnitt 2.1.10).

Der aktuelle Status von Fehlern der stable-Distribution ist unter der Stable Problems-Webseite aufgeführt.

2.1.4 Die testing-Distribution

Pakete der testing-Distribution, Debian Squeeze, befinden sich im testing- (symbolischer Link zu squeeze/) Verzeichnis, nachdem sie einige Zeit in unstable getestet wurden. Heutzutage befinden sich neue Pakete unterhalb des pool-Verzeichnisses (Das pool-Verzeichnis, Abschnitt 2.1.10). Auch in testing/ gibt es die main-, contrib- und non-free-Unterverzeichnisse, diese entsprechen den Verzeichnissen in stable/.

Diese Pakete müssen auf allen Architekturen, auf denen sie zur Verfügung stehen, gleich aktuell sein und installierbar sein; sie müssen auch weniger veröffentlichungskritische Fehler haben, als die Versionen in unstable. Auf diese Art hoffen wir, dass testing fast immer zur Veröffentlichung bereit ist. Mehr Details zu den Test-Mechanismen sind unter http://www.debian.org/devel/testing verfügbar.

Der aktuellste Status der testing-Distribution ist unter folgenden Seiten aufgeführt:

2.1.5 Die unstable-Distribution

Pakete, welche zur unstable-Distribution mit dem Kodenamen "Sid" gehören, werden im unstable- (symbolischer Link zu sid/) Verzeichnis aufbewahrt, nachdem sie in das Debian-Archiv geladen wurden und verbleiben hier solange, bis sie nach testing/ verschoben werden. Heutzutage befinden sich Pakete unterhalb des pool-Verzeichnisses (Das pool-Verzeichnis, Abschnitt 2.1.10). Es gibt auch main-, contrib- und non-free-Unterverzeichnisse in unstable/, welche dem selben Zweck dienen wie in stable/.

Die unstable-Distribution enthält ein Abbild des aktuellsten Entwickler-Systems. Benutzer sind willkommen diese Pakete zu benutzen und zu testen, werden aber über den Status der Einsatzbereitschaft gewarnt. Der Vorteil der Benutzung der unstable-Distribution ist, dass man immer auf dem Laufenden mit der aktuellsten Debian-Software ist – geht jedoch etwas schief, so muss man auch damit umgehen können. :-)

Der aktuelle Status der Fehler in der unstable-Distribution wird auf der Unstable Problems-Webseite aufgeführt.

2.1.6 Die frozen-Distribution

Wenn die testing-Distribution ausgereift ist, so wird aus ihr frozen, was bedeutet, dass kein neuer Code mehr akzeptiert wird, nur noch Bugfixes, wenn nötig. Es wird auch ein neuer Verzeichnisbaum im dists-Verzeichnis angelegt und einem neuen Kodenamen zugeordnet. Die eingefrorene Distribution durchläuft nun einige Monate lang Tests mit zwischenzeitlichen Updates und Zwischenausgaben, welche "Test-Zyklen" genannt werden.

Wir führen eine Liste aller Fehler in der frozen-Distribution, welche die Veröffentlichung eines Paketes verzögern können, sowie von Fehlern, welche ähnliche Auswirkungen auf die gesamte Ausgabe haben. Sobald die Anzahl der Fehler den maximal zulässigen Wert unterschreitet, wird aus der eingefrorenen Distribution stable, sie wird veröffentlicht und die letzte stable-Distribution veraltet (und wird ins Archiv verschoben).

2.1.7 Debian-Distributions-Kodenamen

Verzeichnisnamen im dists-Verzeichnis, wie lenny/ und squeeze/ sind nur "Kodenamen". Wenn sich eine Debian-Distribution in der Entwicklung befindet, besitzt sie keine Versionsnummer sondern nur einen Kodenamen. Der Grund für diese Kodenamen ist das Spiegeln der Debian-Distributionen zu vereinfachen. (Wenn unstable ein reales Verzeichnis wäre und plötzlich in stable/ umbenannt wird, so müsste vieles erneut heruntergeladen werden).

Zurzeit ist stable/ ein symbolischer Link zu lenny/ und testing/ ist ein symbolischer Link zu squeeze/. Das bedeutet, dass Lenny die aktuelle stable-Distribution und Squeeze die aktuelle testing-Distribution ist.

unstable/ ist ein permanenter symbolischer Link zu sid/, so wie Sid ständig für die unstable-Distribution steht.

2.1.8 In der Vergangenheit verwendete Kodenamen

Bereits verwendete Kodenamen sind: "Buzz" für Ausgabe 1.1, "Rex" für Ausgabe 1.2, "Bo" für die Ausgaben 1.3.x, "Hamm" für Ausgabe 2.0, "Slink" für Ausgabe 2.1, "Potato" für Ausgabe 2.2, "Woody" für Ausgabe 3.0 und "Sarge" für Ausgabe 3.1.

2.1.9 Die Herkunft der Kodenamen

Bisher wurden Personen aus dem Film Toy Story von Pixar verwendet.

2.1.10 Das pool-Verzeichnis

Früher wurden Pakete in dem Unterverzeichnis von dists aufbewahrt, welches der verwendeten Distribution entsprach. Es stellte sich heraus, dass dies einige Probleme verursachte, wie z.B. große Bandbreitenverschwendung auf Mirrors nach einigen großen Änderungen.

Pakete werden nun in einem großen "Pool" gespeichert, entsprechend dem Namen des Quellpakets strukturiert. Um dies handhaben zu können, wurde der Pool je nach Abschnitt (main, contrib und non-free) sowie dem ersten Buchstaben des Quellpakets unterteilt. Diese Verzeichnisse enthalten verschiedene Dateien: die Binärpakete für jede Architektur und das Quellpaket von welchem die Binärpakete erzeugt wurden.

Man kann herausfinden wo sich ein Paket befindet, indem man ein Kommando wie apt-cache showsrc Paketname aufruft und nach der "Directory:"-Zeile schaut. Das apache-Paket wird z.B. unter pool/main/a/apache/ gespeichert. Da es sehr viele lib*-Pakete gibt, werden diese gesondert behandelt: das libpaper-Paket wird beispielsweise unter pool/main/libp/libpaper/ gespeichert.

Die dists-Verzeichnisse werden nach wie vor für die Index-Dateien, welche von Programmen wie apt verwendet werden, genutzt.

Normalerweise muss man sich um dies nicht kümmern, da neue apt und wahrscheinlich ältere dpkg-ftp Programme dies problemlos handhaben. Sind Sie an weiteren Informationen interessiert, so sei auf die RFC: Implementation von Paketpools verwiesen.

2.1.11 Historische Bemerkungen über Sid

Als das heutige Sid noch nicht existierte, gab es im Debian-Archiv nur einen Zweig für nicht ausgereifte Pakete: es gab die Annahme, dass, wenn eine Architektur im aktuellen unstable/ hinzukam, sie veröffentlicht wurde, wenn diese Distribution zum neuen stable-Zweig wurde. Für viele Architekturen war das nicht der Fall, was dazu führte, dass diese Verzeichnisse während der Veröffentlichung verschoben wurden. Dies war unpraktisch, da die Verschiebung zu einer großen Bandbreitenbelastung führte.

Die Archiv-Administratoren umgingen das Problem einige Jahre, indem sie Binaries für nichtveröffentlichte Architekturen in einem speziellen Verzeichnis namens sid bereitstellten. Wenn eine Architektur das erste Mal veröffentlicht wurde, gab es einen Link vom aktuellen stable/ zu sid/ und später wurden sie wie üblich unter unstable/ erzeugt. Diese Vorgehensweise war zum Teil für die Anwender verworren.

Mit Beginn der Paket-Pools (vergleiche Das pool-Verzeichnis, Abschnitt 2.1.10) während der Entwicklung der Woody-Distribution, wurden Binärpakete unabhängig von der Distribution vorschriftsmäßig im Pool gehalten, so dass die Veröffentlichung einer Distribution nicht länger zu einer großen Bandbreitenverschwendung auf den Mirrors führte (es gibt dennoch während der Entwicklung eine relativ große Bandbreitenauslastung).

2.1.12 Heraufgeladene Pakete in incoming/

Heraufgeladene Pakete befinden sich zunächst unter http://incoming.debian.org/ nachdem sie überprüft wurden, um sicherzustellen, dass sie wirklich von einem Debian-Entwickler stammen, (und sie werden in das DELAYED-Unterverzeichnis verschoben, wenn das Paket nicht von einem Entwickler stammt, d.h. ein Non-Maintainer Upload (NMU) ist). Einmal pro Tag werden sie von incoming/ nach unstable/ verschoben.

Im Notfall kann man Pakete aus incoming/ installieren, bevor sie nach unstable/ kommen.

2.1.13 Wiederauffinden eines älteren Paketes

Während die aktuellsten Debian-Distributionen unter dem debian-Verzeichnis auf jedem Debian-Mirror zu finden sind, werden die Archive für ältere Debian-Distributionen wie Slink unter http://archive.debian.org/ oder unterhalb des debian-archive Verzeichnis auf jedem Debian-Mirror gehalten.

Ältere testing- und unstable-Pakete befinden sich auf http://snapshot.debian.net/.

2.1.14 Architekturabhängige Verzeichnisse

Innerhalb jedes der wichtigen Verzeichnisbäume (dists/stable/main, dists/stable/contrib, dists/stable/non-free, dists/unstable/main, etc.), befinden sich die Einträge der Binärpakete in Unterverzeichnissen, deren Namen die Prozessorarchitektur kennzeichnen, für die sie kompiliert wurden.

Es ist anzumerken, dass die aktuellen Binärpakete sich nicht mehr länger in diesen Verzeichnissen, dafür aber im pool-Verzeichnis befinden. Die Index-Dateien (Packages und Packages.gz) befinden sich nach wie vor zwecks Abwärtskompatibilität dort.

Für die aktuell unterstützten Binärarchitekturen vergleiche die Release Notes der einzelnen Distributionen. Sie können unter der Release-Notes-Seite für stable und testing gefunden werden.

2.1.15 Der Quellcode

Der Quellcode für alles im Debian-System ist mit darin enthalten. Außerdem fordern die Lizenzvereinbarungen der meisten Programme im System, dass der Quellcode zusammen mit den Programmen ausgeliefert wird, oder dass dem Programm Informationen beiliegen, wie er zu erhalten ist.

Normalerweise befindet sich der Quellcode in den source-Verzeichnissen, welche parallel zu allen architekturspezifischen Binärverzeichnissen sind oder aktueller im pool-Verzeichnis (vergleiche Das pool-Verzeichnis, Abschnitt 2.1.10). Um den Quellcode zu erhalten, ohne sich mit der Verzeichnisstruktur des Debian-Archivs auseinandersetzen zu müssen, kann ein Befehl wie apt-get source Meinpaketname genutzt werden.

Einige Pakete wie z.B. pine, sind wegen deren Lizenzbedingungen nur im Quellcode erhältlich. (Kürzlich wurde das pine-tracker-Paket bereitgestellt, um die Pine-Installation zu vereinfachen.) Die Anweisungen beschrieben in Portierung eines Pakets auf die stable-Distribution, Abschnitt 6.4.10 und Paketerzeugung, Abschnitt 13.10 bieten einige Möglichkeiten, um ein Paket manuell zu paketieren.

Der Quellcode kann, muss aber nicht für Pakete in contrib- und non-free-Verzeichnissen, welche formal nicht Teil des Debian-Systems sind, verfügbar sein.

2.2 Das Debian-Paketverwaltungssystem

2.2.1 Überblick über Debian-Pakete

Pakete enthalten im Allgemeinen all die Dateien, welche nötig sind um eine Menge von zusammengehörigen Kommandos oder Eigenschaften zu implementieren. Es gibt zwei Typen von Debian-Paketen:

Die Installation der Software durch das Paketsystem nutzt "Abhängigkeiten", welche vom Paketbetreuer vorgegeben werden. Diese Abhängigkeiten sind in der control-Datei, die jedem Paket zugeordnet ist, enthalten. Das Paket, welches den GNU C Compiler enthält (gcc), "hängt" z.B. von dem Paketen binutils "ab", das den Linker und Assembler enthält. Versucht ein Benutzer gcc zu installieren, ohne zuvor binutils installiert zu haben, so wird das Paketverwaltungssystem (dpkg) die Fehlermeldung ausgeben, dass es binutils benötigt und die Installation von gcc abbrechen. (Dennoch kann dieses Verhalten vom Nutzer geändert werden; vergleiche dpkg(8).) Für weitere Einzelheiten wird auf Paketabhängigkeiten, Abschnitt 2.2.8 verwiesen.

Debian's Paketverwaltungstools können benutzt werden um:

2.2.2 Debian-Paketformat

Ein Debian-"Paket" oder eine Debian-Archivdatei enthält ausführbare Dateien, Bibliotheken und Dokumentationen, welche einem bestimmten Programm oder einer Menge von zugehörigen Programmen zugeordnet sind. Normalerweise hat eine Debian-Archivdatei einen Dateinamen der mit .deb endet. [1]

Die internen Einzelheiten dieses Debian-Binärpaketformats werden in der deb(5) Handbuchseite beschrieben. Da dieses interne Format in Zukunft geändert werden kann (zwischen verschiedenen Ausgaben von Debian), sollte stets dpkg-deb(1) für Änderungen der .deb-Dateien verwendet werden.

Zumindest in der Sarge-Distribution kann auf alle Debian-Archivdateien mit den Standard-Unix-Kommandos ar und tar zugegriffen werden, auch wenn das dpkg-Kommando nicht verfügbar ist.

2.2.3 Namenskonventionen für Debians Paketdateinamen

Die Debian-Paketdateinamen folgen den Konventionen: 

     foo_ver-rev_arch.deb

wobei foo üblicherweise für den Paketnamen, ver für die Originalversionsnummer, rev für die Debian-Revisionsnummer und arch für die Zielarchitektur steht. Dateien können natürlich leicht umbenannt werden. Sie können herausfinden, welches Paket sich in Wirklichkeit in einer gegebenen Datei mit Namen Dateiname befindet, indem das folgende Kommando ausgeführt wird: 

     dpkg --info filename

Die Debian-Revisionsnummer wird vom Debian-Entwickler angegeben oder von demjenigen, der das Paket baut. Eine Änderung in der Revisionsnummer kennzeichnet in der Regel, dass einige Aspekte der Paketierung geändert wurden.

2.2.4 Bewahren der lokalen Konfiguration

Konfigurationsdateien, die vom lokalen Administrator anpassbar sind, befinden sich in /etc/. Die Debian-Policy legt fest, dass alle Änderungen zu lokalen Konfigurationsdateien bei Paketaktualisierungen erhalten bleiben müssen.

Falls eine Standardversion einer lokal anpassbaren Datei mit einem Paket vertrieben wird, so ist diese Datei als "conffile" aufgeführt. Das Paketverwaltungssystem aktualisiert solche Dateien nicht ohne die Erlaubnis des Administrators, falls sie geändert wurden, seitdem das Paket das letzte Mal installiert wurde. Andererseits werden nicht veränderte Konfigurationsdateien zusammen mit dem Rest des Pakets aktualisiert. Dies ist nahezu immer erwünscht, so dass es vorteilhaft ist, die Änderungen an Konfigurationsdateien zu minimieren.

Um die Konfigurationsdateien, die zu einem Paket gehören, zu bestimmen, kann man 

     dpkg --status Paket

ausführen und nach "Conffiles:" schauen.

Für weitere Informationen zu Konfigurationsdateien, kann man den entsprechenden Abschnitt "Konfigurationsdateien" im Debian Policy-Handbuch lesen (vergleiche Referenzen, Abschnitt 15.1).

2.2.5 Debian-Wartungsskripte

Debian-Wartungsskripte sind ausführbare Skripte, welche automatisch gestartet werden bevor oder nachdem ein Paket installiert wird. Zusammen mit einer Datei namens control sind all diese Dateien Teil des "control"-Abschnitts einer Debian-Archivdatei.

Die einzelnen Dateien sind:

preinst

Dieses Skript wird ausgeführt, bevor das Paket aus der Debian-Archivdatei (.deb) ausgepackt wird. Viele "preinst"-Skripte beenden Dienste von Paketen, welche aktualisiert werden, bis deren Installation oder Upgrade vollzogen ist (d.h. nach der erfolgreichen Ausführung des "postinst"-Skriptes).

postinst

Dieses Skript schließt typischerweise jede nötige Konfiguration eines Paketes ab, nachdem es aus der Debian-Archivdatei (.deb) ausgepackt wurde. Oft fragen "postinst"-Skripte die Nutzer nach Daten, und/oder weisen sie darauf hin, dass, wenn sie die Standardwerte akzeptieren, sie später die Möglichkeit haben zurückzugehen und das Paket zu rekonfigurieren, sollte dies nötig sein. Viele "postinst"-Skripte führen Kommandos aus, welche nötig sind, um Dienste zu starten oder nach der Installation oder dem Upgrade neu zu starten.

prerm

Dieses Skript beendet typischerweise Daemonen, welche dem Paket zugeordnet sind. Es wird ausgeführt, bevor die zum Paket gehörenden Dateien gelöscht werden.

postrm

Dieses Skript modifiziert typischerweise Links oder andere Dateien, welche dem Paket zugeordnet sind und/oder entfernen Dateien, welche von ihm erzeugt wurden. (Siehe auch Virtuelle Pakete, Abschnitt 2.2.7.)

Zurzeit können all diese Kontrolldateien im Verzeichnis /var/lib/dpkg/info gefunden werden. Die auf das Paket foo bezogenen Dateien beginnen mit "foo" und haben die entsprechende Dateierweiterungen "preinst", "postinst", u.s.w. Die Datei foo.list in diesem Verzeichnis enthält alle Dateien, welche mit dem Paket foo installiert wurden. (Es ist zu beachten, dass die Position dieser Dateien eine interne dpkg-Eigenschaft ist und sich in der Zukunft ändern kann.)

2.2.6 Paket-Prioritäten

Jedem Debian-Paket ist eine Priorität vom Distributionsbetreuer zugeordnet worden, um die Arbeit des Paketverwaltungssystems zu vereinfachen. Die Prioritäten sind:

Beachten Sie die Unterschiede zwischen "Priority: required", "Section: base" und "Essential: yes" in der Paketbeschreibung. "Section: base" bedeutet, dass dieses Paket vor allen anderen in einem neuen System installiert wird. Die meisten der Pakete mit "Section: base" enthalten "Priority: required" oder zumindest "Priority: important" und viele von diesen sind mit "Essential: yes" versehen. "Essential: yes" bedeutet, dass das Paket die Angabe einer bestimmten Option an das Paketmanagementsystem wie dpkg erfordert, wenn es aus dem System entfernt werden soll. Beispielsweise sind libc6, mawk und makedev Pakete mit "Priority: required" und "Section: base" aber enthalten nicht "Essential: yes".

2.2.7 Virtuelle Pakete

Ein virtuelles Paket ist ein allgemeiner Name, welcher für eine Gruppe von Paketen steht, die alle ähnliche Funktionalitäten bereitstellen. Die Programme tin und trn sind beispielsweise beide News-Reader und einer von beiden sollte deshalb die Abhängigkeiten eines Programms, welches einen News-Reader im System benötigt, um richtig funktionieren zu können, erfüllen. Deshalb sagt man, dass beide das "virtuelle Paket" news-reader bereitstellen.

Analog stellen viele Pakete wie exim, exim4, sendmail und postfix die Funktionalität eines Mail-Transport-Agent bereit. Deshalb wird das virtuelle Paket mail-transport-agent von beiden angeboten. Wenn eines dieser Programme installiert ist, dann wird jedes Programm, das von der Installation eines Mail-Transport-Agent abhängt, mit der Existenz dieses virtuellen Paketes zufrieden sein.

Debian besitzt einen Mechanismus so dass, wenn mehr als ein Paket, welches das selbe virtuelle Paket bereitstellt, auf dem System installiert ist, der Systemadministrator ein Programm bevorzugt auswählen kann. Das entsprechende Kommando ist update-alternatives und wird genauer in Alternative Befehle, Abschnitt 6.5.3 beschrieben.

2.2.8 Paketabhängigkeiten

Das Debian-Paketsystem enthält Paketabhängigkeiten, welche verwendet werden, um den Fakt festzuhalten, dass ein Paket ein anderes Paket installiert benötigt, um zu funktionieren oder um besser zu funktionieren.

Weitere detaillierte Informationen zur Verwendung dieser Terme können im Packaging Manual und dem Policy Manual gefunden werden.

Es ist zu beachten, dass aptitude und dselect eine bessere Kontrolle über Pakete, die mit empfiehlt und schlägt vor spezifiziert werden, bietet als apt-get, was einfach alle hängt ab Pakete wählt und empfiehlt und schlägt vor ignoriert. Beide Programme nutzen in aktuellen Versionen APT als Back-end.

2.2.9 Die Bedeutung von "pre-depends" (Vor-Abhängigkeiten)

dpkg konfiguriert ein Paket, von dem ein anderes Paket abhängt, immer, bevor es das Paket konfiguriert, das die Abhängigkeit erklärt. Jedoch packt dpkg normalerweise Archivdateien in beliebiger Reihenfolge aus, unabhängig von Abhängigkeiten. (Das Auspacken besteht aus dem Extrahieren der Dateien aus der Archivdatei und dem Ablegen am richtigen Ort.) Falls jedoch ein Paket eine pre-depends-Abhängigkeit zu einem Paket erklärt, dann wird dieses andere Paket zuerst ausgepackt und konfiguriert, bevor dasjenige, mit der Vor-Abhängigkeit auch nur ausgepackt wird.[2] Die Verwendung dieser Abhängigkeit wird minimiert.

2.2.10 Paket-Status

Der Paket-Status kann "unbekannt", "installieren", "entfernen", "säubern" oder "halten" sein. Diese "gewünschten" Werte kennzeichnen, was der Nutzer mit einem Paket beabsichtigte (entweder durch Anwahl des "[A]uswählen" Punktes in dselect oder durch direkten Aufruf von dpkg).

Deren Bedeutung ist:

2.2.11 Zurückhalten von Paketen von einem Upgrade

Es gibt zwei Mechanismen zum Zurückhalten von Paketen von einem Upgrade, durch dpkg oder beginnend mit Woody durch APT.

Mit dpkg ist zuerst die Paketauswahlliste zu exportieren: 

     dpkg --get-selections \* > Paketauswahl.txt

Dann muss die erzeugte Datei Paketauswahl.txt editiert werden, indem die Zeile, welche das zu haltende Paket, z.B. libc6, enthält, von: 

     libc6                       install

auf: 

     libc6                       hold

geändert wird. Nach dem Speichern ist die Datei in die dpkg-Datenbank zurückzuladen mit: 

     dpkg --set-selections < Paketauswahl.txt

Kennt man den Paketnamen des zu haltenden Pakets, kann man auch einfach 

     echo libc6 hold | dpkg --set-selections

starten. Wann immer der Installations-Prozess dieses Paket bearbeitet (zu upgraden versucht), hält er es zurück.

Der selbe Effekt kann mit dselect erreicht werden. Dazu ist einfach der Punkt [A]uswählen und dann das Paket zu wählen, dessen Status beibehalten werden soll sowie schließlich `=' (oder `H') zu drücken. Die Änderungen werden sofort aktiv, nachdem das [A]uswählen Menü beendet wird.

Das APT-System in der Woody-Distribution hat einen neuen "Alternativen" Mechanismus zum Halten von Paketen während des Archivabfrageprozesses unter Verwendung von Pin-Priority. Vergleiche die Handbuchseite apt_preferences(5) sowie http://www.debian.org/doc/manuals/apt-howto/ oder das apt-howto-Paket.

2.2.12 Quellpakete

Quellpakete befinden sich in einem Verzeichnis namens source und können entweder manuell heruntergeladen werden oder durch 

     apt-get source foo

(vergleiche die apt-get(8) Handbuchseite wie man APT dazu bringt, dies zu tun).

2.2.13 Erzeugen von Binär- aus Quellcodepaketen

Für ein Paket foo benötigt man alle foo_*.dsc-, foo_*.tar.gz- und foo_*.diff.gz-Dateien, um die Quellen zu übersetzen (Bemerkung: es gibt keine .diff.gz-Datei für ein natives Debian-Paket).

Sind diese Dateien vorhanden und ist das dpkg-dev-Paket installiert, so extrahiert das Kommando 

     $ dpkg-source -x foo_version-revision.dsc

das Paket in ein Verzeichnis namens foo-version.

Zum Erzeugen des Binärpakets ist Folgendes auszuführen: 

     $ cd foo-version
     $ su -c "apt-get update; apt-get install fakeroot"
     $ dpkg-buildpackage -rfakeroot -us -uc

Und danach 

     # su -c "dpkg -i ../foo_version-revision_arch.deb"

zum Installieren des neu gebildeten Pakets. Vergleiche Portierung eines Pakets auf die stable-Distribution, Abschnitt 6.4.10.

2.2.14 Erzeugen neuer Debian-Pakete

Für detaillierte Informationen zum Erzeugen neuer Pakete sollte der New Maintainers' Guide gelesen werden, verfügbar im Paket maint-guide oder unter http://www.debian.org/doc/manuals/maint-guide/.

2.3 Aktualisierung eines Debian-Systems

Einer von Debians Vorzügen ist die Unterstützung eines konsistenten Upgrade-Wegs sowie ein sicherer Upgrade-Prozess und es wird stets versucht, eine ältere Ausgabe problemlos zu aktualisieren. Pakete warnen den Nutzer, sollten bedeutende Bemerkungen während des Upgrade-Prozesses auftreten und bieten oft eine Lösung zu einem möglichen Problem.

Man sollte auch die Release Notes lesen, das Dokument, das die Details zu spezifischen Upgrades enthält. Es wird mit allen Debian-CDs ausgeliefert und ist im WWW unter http://www.debian.org/releases/stable/releasenotes oder http://www.debian.org/releases/testing/releasenotes verfügbar.

Eine praktische Anleitung zum Aktualisieren wird in Debian-Paketverwaltung, Kapitel 6 bereitgestellt. Dieser Abschnitt beschreibt die grundlegenden Einzelheiten.

2.3.1 Methoden zum Aktualisieren eines Debian-Systems

Man kann immer einfach einen anonymen FTP- oder wget-Aufruf zu einem Debian-Archiv starten, die Verzeichnisse durchsehen, bis man die gewünschte Datei gefunden hat, diese herunterladen und schließlich mittels dpkg installieren. (Es ist zu beachten, dass dpkg die aktualisierten Dateien immer in das korrekte Verzeichnis installiert, auch in einem laufenden System.) Manchmal kommt es dennoch vor, dass ein überarbeitetes Paket die Installation einer neuen Version eines anderen Paketes erfordert. In diesem Fall schlägt die Installation fehl, wenn das andere Programm nicht installiert ist.

Viele Personen finden dieses manuelle Vorgehen zu Zeit aufwendig, da Debian sich so schnell entwickelt – typischerweise werden ein Dutzend oder mehr Pakete jede Woche hochgeladen. Diese Zahl ist kurz vor einer neuen Veröffentlichung noch größer. Um dies besser handhaben zu können, bevorzugen viele Personen ein automatisches Programm zum Upgraden. Einige spezialisierte Paketmanagement-Tools sind für diesen Zweck verwendbar.

2.3.2 Überblick über Paketverwaltungstools

Das Debian-Paketverwaltungssystem hat zwei Aufgaben: die Manipulation der Paketdatei und das Herunterladen von Paketdateien aus dem Debian-Archiv. dpkg erfüllt die erste Aufgabe, APT und dselect die letztere.

2.3.3 dpkg

Dies ist das wichtigste Programm zum Manipulieren von Paketdateien. Für eine ausführliche Beschreibung ist dpkg(8) zu lesen.

dpkg wird mit einigen wichtigen Programmen ausgeliefert.

dpkg-ftp und dpkg-mountable wurden durch das APT-System ersetzt.

2.3.4 APT

APT, das zukunftsweisende Paket-Tool (Advanced Packaging Tool) ist eine fortschrittliche Schnittstelle zu Debians Paketsystem und besteht aus verschiedenen Programmen, deren Namen oft mit "apt-" beginnen. apt-get, apt-cache und apt-cdrom sind die Kommandozeilen-Tools zum Umgang mit Paketen. Diese werden auch von anderen Programmen, wie dselect und aptitude genutzt.

Für weitere Informationen ist das apt-Paket zu installieren und apt-get(8), apt-cache(8), apt-cdrom(8), apt.conf(5), sources.list(5), apt_preferences(5) sowie /usr/share/doc/apt/guide.html/index.html zu lesen.

Weitere Informationen finden sich im APT HOWTO. Dazu kann apt-howto-de installiert werden und steht dann unter file:///usr/share/doc/Debian/apt-howto/ zur Verfügung.

apt-get upgrade und apt-get dist-upgrade installieren nur die Pakete, die unter "Depends:" ("hängt ab:") aufgeführt sind und übersieht alle unter "Recommends:" ("empfiehlt:") und "Suggests:" ("schlägt vor:") gelisteten Pakete. Um dies zu vermeiden, sollte dselect verwendet werden.

2.3.5 dselect

Dieses Programm besitzt eine Menüoberfläche zu Debians Paketverwaltungssystem. Es ist besonders für die Erstinstallation und große Upgrades nützlich. Vergleiche dselect, Abschnitt 6.2.3.

Für weitere Informationen sollte das install-doc-Paket installiert und /usr/share/doc/install-doc/dselect-beginner.en.html oder dselect Documentation for Beginners gelesen werden.

2.3.6 Aktualisieren eines laufenden Systems

Der Kernel (das Dateisystem) in Debian-Systemen unterstützt das Ersetzen von Dateien auch während sie benutzt werden.

Es wird auch ein Programm namens start-stop-daemon bereitgestellt, das verwendet wird, um Daemonen während des Bootens zu starten oder zum Stoppen von Daemonen, wenn das Kernel-Runlevel geändert wird (z.B. von Mehrbenutzer- zu Einzelbenutzermodus oder zu "halt"). Das gleiche Programm wird von Installationsskripten genutzt, wenn ein Paket, das einen Daemon enthält, installiert wird, um laufende Daemonen zu stoppen und bei Bedarf neuzustarten.

Es wird darauf hingewiesen, dass das Debian-System den Einzelnutzermodus nicht erfordert, um ein laufendes System zu aktualisieren.

2.3.7 Heruntergeladene und zwischengespeicherte .deb-Archiv-Dateien

Hat man Paketdateien manuell auf die Festplatte heruntergeladen (was nicht unbedingt notwendig ist, vergleiche die obige Beschreibung von dpkg-ftp oder APT), dann kann man die .deb-Dateien nach der Installation der Pakete aus dem System entfernen.

Wenn APT verwendet wird, so werden diese Dateien im /var/cache/apt/archives-Verzeichnis zwischengespeichert. Sie können nach der Installation gelöscht werden (apt-get clean) oder auf einen anderen Rechner ins /var/cache/apt/archives Verzeichnis kopiert werden, um das Herunterladen während mehrerer Installationen zu vermeiden.

2.3.8 Aufbewahren des Datensatzes für Upgrades

dpkg bewahrt einen Datensatz aller Pakete, die ausgepackt, konfiguriert, entfernt und/oder gesäubert wurden, auf. Jedoch wird (zurzeit) kein Protokoll der Terminaleingaben, während der Paketmanipulation, erzeugt.

Der einfachste Weg, dieses Problem zu umgehen, ist Sitzungen von dpkg, dselect, apt-get, etc. innerhalb des script(1) Programms ablaufen zu lassen.

2.4 Der Debian-Bootvorgang

2.4.1 Das init-Programm

Wie alle Unices, wird Debian durch das Programm init gestartet. Die Konfigurationsdatei für init (dies ist /etc/inittab) gibt an, dass das erste zu startende Skript /etc/init.d/rcS ist. Dieses Skript startet alle anderen Skripte in /etc/rcS.d/, entweder indem diese eingebunden oder explizit als Unterprozess aufgerufen werden, je nach Dateierweiterung. Diese Skripte initialisieren das System indem sie z.B. Dateisysteme überprüfen und einbinden, Module laden, Netzwerk-Dienste starten, die Uhrzeit setzen, u.a. Danach werden zwecks Kompatibilität die Dateien (mit Ausnahme der mit einem `.' im Dateinamen) in /etc/rc.boot/ ausgeführt. Jedes Skript in diesem Verzeichnis ist normalerweise dem Systemadministrator vorbehalten, die Verwendung dieser in Paketen wird missbilligt. Vergleichen Sie Hinweise zur System-Inititalisierung, Abschnitt 9.1 und System run levels and init.d scripts in den Debian-Richtlinien für weitere Informationen.

2.4.2 Runlevel

Nach dem Bootprozess führt init alle Startskripte in einem durch das Standard-Runlevel festgelegten Verzeichnis aus. (Dieses Runlevel wird durch den Eintrag id in /etc/inittab festgelegt). Wie viele System-V-kompatible Unices hat Linux 7 Runlevel:

Für Debian-Systeme gilt id=2, was bedeutet, dass das Standard-Runlevel 2 sein wird, wenn der Mehrbenutzer-Modus aktiv ist und die Skripte in /etc/rc2.d/ werden ausgeführt.

In Wirklichkeit sind die Skripte in den Verzeichnissen /etc/rcN.d/ nur symbolische Links zu Skripten in /etc/init.d/. Dennoch werden die Namen der Dateien in jedem der /etc/rcN.d/-Verzeichnisse individuell gewählt, um anzugeben wie die Skripte in /etc/init.d/ gestartet werden. Speziell werden bevor ein Runlevel aktiv wird, alle Skripte die mit `K' beginnen ausgeführt; diese Skripte beenden Dienste. Danach werden alle Skripte die mit `S' beginnen gestartet; diese Skripte starten Dienste. Die zweistellige dem `K' oder `S' folgende Nummer bestimmt die Reihenfolge der Ausführung. Skripte mit kleinerer Nummer werden zuerst ausgeführt.

Dieses Vorgehen funktioniert, da die Skripte in /etc/init.d/ alle ein Argument akzeptieren, das entweder "start", "stop", "reload", "restart" oder "force-reload" sein kann und eine dem Argument entsprechende Aktion ausführen (starten, stoppen, neuladen, neustarten, erzwinge Neuladen). Diese Skripte können auch ausgeführt werden, nachdem das System gebootet wurde, um verschiedene Prozesse zu kontrollieren.

Zum Beispiel führt das Argument "reload" im Kommando 

     # /etc/init.d/exim4 reload

dazu, dass der exim4-Daemon ein Signal zum erneuten Einlesen der Konfigurationsdatei erhält.

2.4.3 Anpassen des Bootvorgangs

Debian verwendet kein BSD typisches rc.local Verzeichnis, um den Bootvorgang anzupassen; stattdessen wird folgender Mechanismus angeboten.

Angenommen foo sei ein Skript, das während des Startvorgangs oder beim Übergang in ein bestimmtes (System V) Runlevel aufgerufen werden soll. Dann sollte der Systemadministrator:

  1. Das Skript foo in das Verzeichnis /etc/init.d/ verschieben.

  1. Das Debian-Kommando update-rc.d mit entsprechenden Argumenten starten, um Links zwischen den (Kommandozeilen spezifischen) Verzeichnissen rc?.d und /etc/init.d/foo anzulegen. Dabei bezeichnet ? eine Nummer von 0 bis 6, die einem der System V Runlevel entspricht.

  1. Das System neu booten.

Das Kommando update-rc.d setzt Links zwischen Dateien im Verzeichnis rc?.d und dem Skript in /etc/init.d/. Jeder Link beginnt mit einem `S' oder `K', gefolgt von einer Nummer, gefolgt vom Namen des Skripts. Beim Wechsel in das Runlevel N, werden Skripte in /etc/rcN.d/ die mit `K' beginnen mit stop als Argument ausgeführt, gefolgt von den mit `S' beginnenden Skripten in /etc/rcN.d/ mit start als Argument.

Man kann z.B. das Skript foo beim Booten ausführen lassen, indem man es nach /etc/init.d/ verschiebt und die Links mit update-rc.d foo defaults 19 erstellt. Das Argument defaults bezieht sich auf das Standard-Runlevel, welches zwischen 2 und 5 liegt. Das Argument 19 sichert, dass foo vor allen Skripten, welche die Nummern 20 oder größer enthalten, gestartet wird.

2.5 Unterstützung von Vielfalten

Debian unterstützt verschiedene Möglichkeiten zum Anpassen des Systems, ohne das System zu beeinträchtigen.

Alle Dateien unter /usr/local/ gehören dem Systemadministrator und Debian wird sie nicht verändern. Viele (oder alle) Dateien unter /etc sind Konfigurationsdateien und Debian wird sie nicht während eines Upgrades überschreiben, es sei denn der Systemadministrator erlaubt dies ausdrücklich.

2.6 Internationalisierung

Das Debian-System ist internationalisiert und bietet Unterstützung zur Ein- und Ausgabe von Zeichen in vielen Sprachen, beides in der Konsole und unter X. Viele Texte, Handbuchseiten und Systemausgaben wurden in eine ständig wachsende Anzahl von Sprachen übersetzt. Während der Installation fordert Debian den Nutzer zur Wahl der Installationssprache (und manchmal eines lokalen Dialekts) auf.

Sollte das installierte System nicht alle benötigten Eigenschaften der Sprache unterstützen, soll eine andere Sprache gewählt werden oder wurde eine neue Tastatur angeschlossen, um die Sprache zu unterstützen, vergleiche Lokalisation und Sprachen, Abschnitt 9.7.

2.7 Debian und der Kernel

Vergleiche Der Linux-Kernel unter Debian, Kapitel 7.

2.7.1 Kompilierung eines Kernel aus Debian-fremden Quellen

Man sollte die Debian-Politik bezüglich der Header verstanden haben, bevor man startet.

Die Debian-C-Bibliotheken wurden mit der aktuellsten stabilen Version der Kernelheader erstellt.

Zum Beispiel nutzte die Debian 1.2 Ausgabe Version 5.4.13 der Header. Dieses Vorgehen unterscheidet sich von den Linux-Kernelquellpaketen, die auf allen Linux-FTP-Archiv-Seiten verbreitet werden, welche aktuellere Versionen der Header verwenden. Die Kernelheader aus den Kernelquellen befinden sich in /usr/include/linux/include/.

Wenn es nötig ist, ein Programm mit aktuelleren Kernelheadern als in libc6-dev zu übersetzen, so muss -I/usr/src/linux/include/ zur Kommandozeile beim Kompilieren hinzugefügt werden. Dies ist z.B. für das Paketieren des automounter-Daemon (amd) von Bedeutung. Als neue Kernel einige NFS-bezogene Internals änderten, musste dies amd mitgeteilt werden. Dies erforderte die Einbindung der aktuellsten Kernelheader.

2.7.2 Tools zum Erzeugen angepasster Kernel

Nutzern die einen angepassten Kernel erzeugen wollen (oder müssen), wird empfohlen, das Paket kernel-package herunterzuladen. Dieses Paket enthält das Skript zur Kernelerstellung und bietet die Möglichkeit, ein Debian kernel-image Paket einfach durch Aufruf von 

     # make-kpkg kernel_image

im Kernelquellverzeichnis zu starten. Hilfe ist durch Ausführung von 

     # make-kpkg --help

verfügbar und durch die Handbuchseite make-kpkg(1) sowie Der Linux-Kernel unter Debian, Kapitel 7.

Nutzer müssen den Quellcode für den aktuellsten Kernel (oder den Kernel ihrer Wahl) separat vom bevorzugten Linux-Archiv herunterladen, wenn kein kernel-source-version-Paket (dabei steht version für die Kernel-Version) vorhanden ist. Das Debian initrd-Bootskript erfordert einen speziellen Kernel-Patch namens initrd; vergleiche http://bugs.debian.org/149236.

Detaillierte Anweisungen zur Benutzung des kernel-package-Pakets sind in der Datei /usr/share/doc/kernel-package/README.gz zu finden.

2.7.3 Spezielle Regeln für den Umgang mit Modulen

Debians modconf Paket enthält ein Shellskript (/usr/sbin/modconf), dass zur Anpassung der Modulkonfiguration genutzt werden kann. Dieses Skript besitzt eine Menü basierte Schnittstelle, die den Nutzer nach Einzelheiten über ladbare Gerätetreiber im System fragt. Die Antworten werden benutzt, um die Datei /etc/modules.conf (welche Aliase enthält sowie andere Argumente, die in Verbindung mit verschiedenen Modulen verwendet werden müssen) anzupassen, auf Grund von Dateien in /etc/modutils/ und /etc/modules (die die Module auflistet, die zur Bootzeit geladen werden müssen).

Wie die (neuen) Configure.help-Dateien, die nun verfügbar sind, um angepasste Kernel zu unterstützen, kommt das modconf-Paket mit einer Reihe von Hilfe-Dateien (in /usr/share/modconf/), die detaillierte Informationen über passende Argumente für jedes Modul enthalten.

2.7.4 Deinstallation eines alten Kernel-Pakets

Das kernel-image-NNN.prerm-Skript überprüft, ob der aktuell laufende Kernel mit dem zu entfernenden Kernel übereinstimmt. Deshalb können ungewünschte kernel-image Pakete sicher mittels 

     # dpkg --purge --force-remove-essential kernel-image-NNN

entfernt werden. (NNN ist durch die entsprechende Kernelversion und Revisionsnummer zu ersetzen.)

[ zurück ] [ Inhalt ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 10 ] [ 11 ] [ 12 ] [ 13 ] [ 14 ] [ 15 ] [ A ] [ weiter ]

Debian Reference (version 1)

This translation is based on old version of Debian Reference (English, version 1.x), well before Sat, 26 Jan 2008.

Osamu Aoki osamu#at#debian.org
Übersetzer: Jens Seidel tux-master#at#web.de
Autoren, Abschnitt A.1