Foliensatz 2
Systemadministration allgemein
Inhalt
• Aufgaben eines Systemadministrators
• Arbeiten als root
• Wichtige Verzeichnisse
• Syntax von Konfigurationsdateien
• Systemservices/Dämonen
• Hilfsmittel für Systemadministration
• Puppet
Aufgaben eines Systemadministrators
• Installation und Konfiguration von Servern und Arbeitsplatzrechnern (möglichst automatisiert, ev.
über ein Netzwerk, wiederholbar)
• Benutzerverwaltung (Anlegen, modifizieren und löschen von Benutzern und Gruppen)
• Installation und Konfiguration von Software (Benutzerapplikationen, konfigurieren des automatischen Einspielens von Sicherheitsupdates, erstellen systemweiter Standardkonfigurationen)
• Tausch von fehlerhafter Hardware (einzelne Komponenten, ganzer Rechner, Peripheriegeräte)
• Behebung von Softwareproblemen
• Backups (einrichten, kontrollieren, wiederherstellen)
• Monitoring (überwachen von Serversoftware, Netzwerk, … auf Probleme bzw. Angriffe)
• Erstellen einer Benutzungsordnung („Policy“, politischer Aspekt)
Arbeiten als root
• Systemadministration muss als Benutzer root durchgeführt werden, da nur dieser die nötigen Berechtigungen hat → birgt großes Gefahrenpotential!
• Es ist empfehlenswert, nicht direkt als root einzuloggen, sondern über su oder sudo kurzfristig root zu werden (besser nachvollziehbar, wer wann etwas als root gemacht hat).
• Die einzelnen Rechte von root können nicht auf mehrere Benutzer aufgeteilt werden. Über den Befehl sudo kann man aber trotzdem relativ einfach andere Benutzer Systemadministrationsaufgaben durchführen lassen.
Wichtig Verzeichnisse
• Die Lage der Konfigurations-, Daten- und Systemdateien ist bei den meisten Linux-Distributionen FHS-konform.
• /etc/ → Systemkonfigurationsdateien
• /var/ → Veränderbare Datendateien:
• /var/cache/ → Cachedaten von Applikationen
• /var/log/ → Logdateien
• /var/run/ → Laufzeitdaten von Prozessen
• /var/spool/ → Spooling von Daten (Spool = Simultaneous Peripheral Operation On-Line und aufspulen/abspulen; Zwischenlagerung von Druckjobs, Mails, …)
• /proc/ → Datendateien des Kernels (auch Informationen zu Prozessen)
• /sys/ → Informationen über alle Geräte, die der Kernel kennt, und Möglichkeit, diese zu konfigurieren
Syntax von Konfigurationsdateien
• Die Konfigurationsdateien unter Linux (Unix) sind (fast) alles Textdateien. Daher braucht man nur einen Texteditor (z.B. Vim), um sie zu bearbeiten.
• Textdateien haben einige Vorteile:
• Wird die Datei korrupt, kann man den Großteil trotzdem richtig auslesen.
• Man braucht nur einen Texteditor.
• Man wird sie auf zukünftigen Computern ohne spezielle Hilfsmittel sicher lesen können.
• Ein großer Nachteil ist, dass es keinen Standard für die Syntax von Konfigurationsdateien gibt:
• Tabellenstruktur (z.B. /etc/passwd)
• Ausführbare Datei (z.B. /etc/bash.bashrc)
• XML (z.B. /etc/fonts/fonts.conf)
• Assoziation von Parametern mit Werten, eventuell unterteil in Sektionene (z.B.
/etc/X11/xorg.conf)
• Spezielles Format
Systemservices/Dämonen
• Beim Systemstart werden durch den init-Prozess die nötigen Systemservices/Dämonen (Disk and execution monitor) gestartet.
• Dabei gibt es 8 sogenannte Runlevels, Zustände, in denen sich ein System befinden kann. Runlevel 0 wird benutzt um das System herunterzufahren, Runlevel 6 für einen Reboot und Runlevel 1 für den Single-User-Modus (danach befindet sich das System im Runlevel S).
• Welche Init-Skripte beim Systemstart bzw. beim Wechsel in einen Runlevel automatisch gestartet bzw. gestoppt werden, wird durch das init-Programm und dessen Konfiguration vorgegeben.
z.B. Upstart, bei Fedora z.B. systemd).
Systemservices/Dämonen - upstart
• Bei Upstart liegen die Konfigurationsdateien in /etc/init/, das Verzeichnis /etc/init.d/ gibt es aber weiterhin (Upstart ist kompatibel zu SysV). Es enthält SysV-Init-Skripte, die noch nicht auf Upstart konvertiert worden sind bzw. symbolische Links für alle Upstart-Konfigurationsdateien.
• Durch symbolische Links in den Verzeichnissen /etc/rc{0..6}.d/ (SysV-Init) bzw. direkt in den Upstart-Konfigurationsdateien wird angegeben, was bei welchem Runlevel gemacht werden soll.
• Services können bei SysV direkt durch Aufruf des Init-Skriptes gestartet oder gestoppt werden. Für Upstart gibt es die Befehle service, start, stop und restart.
• Im Verzeichnis /etc/default/ finden sich zu vielen Systemservices und Dämonen zusätzliche Konfigurationsdateien (Shell-Skripte, welche Variablen definieren), z.B. /etc/default/dbus.
• Dämonen laufen im Hintergrund und führen wichtige Systemaufgaben aus (z.B. udevd oder dbus) oder stellen bestimmte Services bereit (z.B. sshd oder atd).
• Kommuniziert wird mit Dämonen meist über Signale (z.B. wird HUP oft verwendet, um die Konfiguration neu zu laden).
Systemservices/Dämonen - udev, dbus
• Zwei wichtige Systemservices:
• udev ist verantwortlich für die automatische Erstellung von Gerätedateien in /dev/.
• D-Bus dient zur Interprozesskommunikation. Es stellt eine genormte Schnittstelle zur Verfügung, über die sich Prozesse gegenseitig Nachrichten schicken können. Zusätzlich wird auch die Möglichkeit geboten, dass sich ein Prozess für eine bestimmte Nachricht registriert und er dann automatisch benachrichtigt wird, sobald jemand die Nachricht schickt (z.B.
Netzwerkverbindung hergestellt/getrennt).
Systemservices/Dämonen - systemd
• Das init-Programm systemd hat in der jüngsten Vergangenheit an Popularität gewonnen. Es wurde schon länger z.B. in Fedora benutzt und wird nun bald auch das Standard-init-Programm in Debian und Ubuntu sein.
• systemd hat einige Vorteile, bringt aber auch einige tiefgreifende Änderungen mit sich:
• Der Start des Systems ist sehr schnell, er dauert meist nur wenige Sekunden.
• Abhängigkeiten zwischen Services werden automatisch aufgelöst.
• systemd ist nicht mehr portabel, da es viele Linux-spezifische Funktionalitäten braucht.
Siehe auch: Debatte über Systemd bei Debian
Hilfsmittel für Systemadministration 1
• Es gibt einige Programme, über die zentral ein Linuxsystem administriert werden kann (z.B.
Webmin).
• Die Benutzung von Webmin (oder anderer solcher Programme) hat Vor- aber auch Nachteile:
• Pro: Man muss die unterschiedlichen Konfigurationsdateien und deren Syntax nicht kennen, um Änderungen vorzunehmen.
• Pro: Einheitliche Oberfläche, gut aufbereitet, leicht verständlich.
• Contra: Die Version des Admin-Programms muss zu den Versionen der Programme passen, die man konfigurieren will. Ist ein Programm neuer und hat es Änderungen in der Syntax oder der Konfigurationsparameter gegeben, muss man warten, bis das Admin-Programm nachzieht.
• Contra: Automatisches Ändern von Konfigurationsdateien über Tools kann gefährlich sein.
• Contra: Man wird eventuell von „abhängig“ von dem Admin-Programm.
Hilfsmittel für Systemadministration 2
• Besser sind Konfigurationsmanagementprogramme (z.B. Puppet, Chef, CFEngine), die meist aus einer Server- und einer Client-Komponente bestehen. Auf Wikipedia gibt es einen Vergleich von mehreren dieser Programme).
• Diese erlauben es, einen Rechner reproduzierbar in einen bestimmten Zustand zu versetzen. Dazu wird der gewünschte Zustand mittels Konfigurationsdateien definiert und das Programm weiß, was es ändern muss, um diesen Zustand zu erreichen.
• Sobald man mehrere Server/Arbeitsplatzrechner verwalten muss, sollte man sich überlegen, ob man nicht so ein Programm einsetzen will.
• Einige der Programme (z.B. Puppet und Chef) erlauben auch die Ausführung ohne Serverdienst. Das ist z.B. sehr nützlich, um nach einer Neuinstallation des eigenen Rechners schnell wieder alles richtig konfiguriert zu haben.
Puppet
• Bei Puppet wird der gewünschte Zustand, in dem sich das System befinden soll, mit Hilfe einer deklarativen Sprache in Dateien mit der Endung .pp (sogenannten Manifesten) definiert.
Die Sprache erlaubt unter anderem die Definition von Ressourcen, die auf dem System (nicht) vorhanden sein sollen, wobei konditionelle Ausdrücke verwendet werden können.
• Die Client-Software von Puppet interpretiert das Manifest und erstellt daraus einen Katalog, der spezifisch für das System ist. Der Inhalt des Katalog wird dann mit dem aktuellen Zustand des Systems abgeglichen und nötige Änderungen werden durchgeführt.
• Die Dokumentation zu Puppet ist sehr ausführlich, beginnen sollte man mit Learning Puppet (erklärt grundlegenden Begriffe und Funktionsweisen).
Puppet - Nutzungsvarianten
• Puppet kann sowohl mit als auch ohne Server betrieben werden. Beide Varianten haben Vor- und Nachteile. Werden viele System mit Puppet verwaltet, sollte man die Server-Variante verwenden.
• Zum Betrieb ohne Server braucht man nur das Paket puppet-common installieren. Diese Variante ist zum Beispiel ideal für die Konfiguration eines oder weniger Systeme (z.B. zur Konfiguration des eigenen Rechners).
• Für den Server-Betrieb benötigt man das Paket puppetmaster für den Server und das Paket puppet für die Clients. Nach der Installation läuft der Server mit einer Standardkonfiguration.
• Das globale Konfigurationsverzeichnis /etc/puppet enthält folgende Dateien:
• auth.conf → Allgemeine Zugriffssteuerung für die Serverkomponente
• fileserver.conf → Zugriffssteuerung für die Dateiserverkomponente
• puppet.conf → Konfigurationsdatei
• Die Konfigurationsdatei enthält Blöcke für die verschiedenen Komponenten (agent, master, …), in denen die Konfigurationsoptionen gesetzt werden können.
Puppet - Facter
• Puppet benutzt das Programm Facter, um Informationen über ein System herauszufinden. Wie Puppet ist auch Facter in Ruby implementiert und kann um zusätzliche Informationsmodule erweitert werden.
• Die durch Facter gewonnen Informationen können in Manifesten als Variablen und somit auch in Bedingungen benutzt werden.
• Beispielausgabe:
$ facter | head -n 5 architecture => amd64 augeasversion => 0.10.0
boardmanufacturer => Oracle Corporation boardproductname => VirtualBox
boardserialnumber => 0
Puppet - Module
• Neben der Definition von Ressourcen in Manifesten können auch Dateien und Templates zur Verwendung hinterlegt werden.
• Um die Wiederverwendbarkeit zu erhöhen, können zusammengehörige Manifeste, Dateien und Templates in Module verpackt werden.
• Es gibt mittlerweile schon sehr viele vorgefertigte Module, die man einbinden kann. Die Webseite Puppet Forge wird von den Entwicklern von Puppet betreut und enthält eine Vielzahl an Modulen.
Puppet - Ressourcen
• Ressourcen definieren über Attribute, wie das System auszusehen hat. Es müssen dabei nicht alle Attribute angegeben werden. Falls benötigte Attribute fehlen, benutzt Puppet, wenn möglich, die systemabhängigen Standardwerte dafür. Ansonsten wird eine Fehlermeldung produziert.
• Wichtig: Nur wirklich in einer Ressource definierte Attribute werden über Puppet verwaltet, alle anderen Attribute bleiben unverändert!
• In Puppet sind schon die wichtigsten Ressourcetypen inkludiert, z.B. zur Paketverwaltung (package), Benutzer- und Gruppenverwaltung (user und group) und Dateiverwaltung (file).
• Für jede Plattform gibt es unterschiedliche Provider für einen Ressourcetyp. Puppet erkennt üblicherweise automatisch den zu benutzenden Provider, man kann aber auch einen spezifizieren.
Diese Provider sind unterschiedlich gut, d.h. manche unterstützen mehr Operationen als andere.
Puppet - Ressourcendeklarationen
• Jede Ressource besitzt immer einen Typ, einen Titel und optional ressourcespezifische Attribute.
• Der Titel muss innnerhalb eines Ressourcetyps eindeutig sein und über die Kombination Ressourcetyp/Titel kann man die Ressource später referenzieren.
• Die Syntax für eine Ressourcendeklaration sieht so aus:
type {'title':
attribute => value, }
• Zusätzlich kann man bei jedem Ressourcetyp sogenannte Metaparameter (wie Attribute) verwenden, die es z.B. erlauben, Abhängigen zwischen Ressourcen zu definieren.
Puppet - Beispielmanifest
case $operatingsystem {
centos, redhat: { $service_name = 'ntpd' } debian, ubuntu: { $service_name = 'ntp' } }
package { 'ntp': ensure => installed } service { 'ntp':
name => $service_name, ensure => running, enable => true,
subscribe => File['ntp.conf'], }
file { 'ntp.conf':
path => '/etc/ntp.conf', ensure => file,
require => Package['ntp'],
Puppet - ohne Server
• Einzelne Änderungen an Ressourcen können über puppet resource gemacht werden bzw. kann über diesen Befehl der Zustand einer Ressource als Puppet-Manifest ausgegeben werden.
$ puppet resource user root shell=/bin/sh
notice: /User[root]/shell: shell changed '/bin/bash' to '/bin/sh' user { 'root':
ensure => 'present', shell => '/bin/sh', }
• Der Befehl puppet apply wird benutzt, um ein ganzes Manifest auf ein System anzuwenden. Dazu wird kein Server benötigt.
$ puppet apply manifest.pp
Puppet - mit Server
• Die Standardserverkonfiguration nach der Installation des Pakets reicht für wenige Clients aus (bei vielen Clients sollte man einen anderen als den eingebauten Webserver Webrick verwenden).
• Damit ein Client weiß, wie der zu nutzende Server heißt, muss man in der Hauptkonfigurationsdatei im Block agent die Variable server auf die IP-Adresse (oder den DNS-Namen) des Servers setzen.
• Die Kommunikation zwischen Client und Server wird über SSL verschlüsselt und jeder Client braucht ein gültiges, vom Server signiertes Zertifikat, um einen Katalog zu bekommen. Daher wird beim erstmaligen Aufruf von puppet agent ein Zertifikatsfehler ausgegebgen.
• Um diesen Fehler zu beheben, muss am Server die Zertifikatsanfrage bestätigt und das Client- Zertifikat mittels puppet cert sign HOSTNAME signiert werden. Danach sollte der Client ohne Problem auf den Server zugreifen können.
• Bei einer Anfrage des Clients interpretiert der Server das in /etc/puppet/manifests/site.pp definierte Manifest und erstellt daraus einen Katalog, der an den Client zurückgesandt und auf das System angewandt wird.
Puppet - Beispiele
Es werden in dieser Lehrveranstaltung immer wieder Beispielmanifeste verwendet, um zu zeigen, wie man mit Puppet Aufgabenstellung lösen könnte. Zum Beispiel:
• Anlegen eines lokalen Benutzers und einer lokalen Gruppe (Ressourcen user und group)
• Installation von Paketen, die verschiedene Namen unter verschiedenen Distributionen haben (Ressource package)
• Erstellen eines Moduls zur Einrichtung eines OpenSSH-Servers
• Ändern von Dateien mit Hilfe von augeas
Copyright und Lizenz
• Copyright: Thomas Leitner thomas.leitner@univie.ac.at
• Lizenz: Creative Commons CC BY-NC-SA
„Namensnennung-Keine kommerzielle Nutzung-Weitergabe unter gleichen Bedingungen 3.0 Österreich.“ - http://creativecommons.org/licenses/by-nc-sa/3.0/at/
