Alle Unterlagen in einem PDF - Fakultät für Mathematik

Transcription

ICT-Infrastruktur für
Bildungsaufgaben
Thomas Leitner <[email protected]>
Fakultät für Mathematik, Universität Wien
Sommersemester 2016
Letzte Änderung: 2016-05-22 09:57
Foliensatz 0
Organisatorisches und
Wiederholung
Organisatorisches
•
Gemeinsam mit Übung anrechenbar als „VU Technische Praxis der Computersysteme 2“
•
VO-Termine
•
•
•
Geblockt 8 Termine jeweils am Montag 13:15 bis 16:00 im SR 7, WS29
•
07.03.2016, 14.03.2016, 04.04.2016, 11.04.2016, 18.04.2016
25.04.2016, 09.05.2016, 23.05.2016
UE-Termine
•
Geblockt 6 Termine jeweils am Donnerstag 15:00 bis 19:00 im PC04, WS29
•
07.04.2016, 14.04.2016, 21.04.2016, 28.04.2016, 12.05.2016, 19.05.2016
Mündliche Prüfung mit einer Dauer von circa 20-30 Minuten; Anmeldung per E-Mail an
[email protected] nach Ende der Vorlesung
Vergangenes Semester
•
Im vergangenen Semester wurde Linux aus Anwendersicht betrachtet, d.h. es wurde behandelt, wie
man ein Linuxsystem benutzt, aber nicht, wie man es administriert.
•
Themengebiete waren unter anderem:
•
Historische Hintergründe (Unix, Urheber- und Lizenzrecht)
•
Aufbau des Betriebsystems
•
Virtuelles Dateisystem, Berechtigungen, Links
•
Prozessmanagement
•
Shell und Shellprogrammierung
•
Kryptographisce Grundlagen und Anwendungen
Inhalte der Vorlesung
In dieser Vorlesung betrachten wir Linuxsysteme aus Administratorsicht:
•
Grundlagen
•
Systemstart und -services
•
Dateisystemverwaltung
•
Netzwerkgrundlagen und -konfiguration
ICT-Infrastruktur für Bildungsaufgaben | Sommersemester 2016 | Version: 2016-05-22 09:57
Seite 2 von 139
•
Software und Paketmanagement
•
Benutzerverwaltung inklusive LDAP und Kerberos
•
Paketfilter/Firewall
•
Netzwerkdateisysteme NFS/CIFS
•
Netzwerkdienste wie z.B. DNS-, Mail- und Webserver
Ziel:
Die Studierenden sind in der Lage, linuxbasierte Systeme zu installieren, zu administrieren,
zu warten und fachgerecht einzusetzen.
Wiederholung
•
Betriebssystem Linux
•
Bash
•
Dateisystem
•
Prozesse
•
Speicher
•
Reguläre Ausdrücke
•
Befehle
Siehe http://www.mat.univie.ac.at/~praxis/wisem15/vorlesung.html
Betriebssystem Linux
•
Kernel (u.a. Prozessverwaltung, virtuelles Dateisystem, Speicher, Netzwerk)
•
Shell (Bash)
•
Systemprogramme (z.B. GNU coreutils)
•
Multi-User (Benutzer, Gruppen, Rechte) und Multi-Tasking
Bash – Allgemeines
•
Interaktiver Kommandozeileninterpreter
•
Text wird vom Benutzer eingegeben, von der Shell interpretiert, die dann einen oder mehrere
Befehle ausführt
•
POSIX-kompatibel, einige nützliche Erweiterungen (z.B. [[ ... ]])
•
Tips zur Bedienung:
•
Befehls-History: Pfeiltaste rauf & runter
•
History-Search: Strg-r sucht rückwärts in der History
•
Navigation in der Zeile:
•
•
•
Strg-Links / Alt-b → Cursor ein Wort nach links
•
Strg-Rechts / Alt-f → Cursor ein Wort nach rechts
•
Strg-a / Strg-e → Cursor zum Anfang/Ende der Zeile
Tabulator-Taste zum Vervollständigen
Hilfe zu Befehlen und Konfigurationsdateien in den Manpages!
Seite 3 von 139
•
Umgebungsvariablen (PATH, HOME, USER, …)
Bash – Konstrukte
•
Reihenfolge der Verarbeitung einer Eingabezeile
•
Auswertungsunterdrückung
Anführungszeichen)
•
Pipes (befehl1 | befehl2)
•
Listen (befehl1; befehl2 && befehl3 || befehl4 &)
•
Verbundbefehle (Ausführung in Sub-Shell, arithmetischer/logischer Ausdruck)
•
Klammernexpansion (echo a{d,b,{1..3}}c)
•
Pfadexpansion (rm datei*.tx?)
•
Variablenexpansion (echo ${PATH/:/ - })
•
Befehlssubstitution (VAR=$(cut -d: -f1 /etc/passwd))
•
Bash-History-Expansion (echo !-1:$)
•
Eingabe-/Ausgabe-Umleitung (befehl1 <file.txt bzw. befehl_1 > file.txt)
(Maskierungszeichen
Backslash
–
\
–
bzw.
einfache/doppelte
Bash Programmierung
•
Tests (test, [, [[ ... ]])
•
Verzweigungen (if, case)
•
Schleifen (for, while)
•
Funktionen (function name () { do_something; })
•
Stellungs- und spezielle Parameter ($1, $@, $#, $?)
Dateisystem
•
Virtuelles Dateisystem VFS (Abstraktionsschicht im Kernel,
Dateisysteme bzw. allgemeine Schnittstelle für Ein- und Ausgabe)
eine
•
Dateiattribute (Änderungsdatum, Besitzer, Gruppe, Berechtigungen, …)
•
Berechtigungen (RWX, Besitzer/Gruppe/Rest, SUID, SGID, Sticky-Bit)
•
Harte und symbolische Links
Sicht
auf
verschiedene
Prozesse
•
Kernel kann ELF-Binärprogramme, Skripts (Shebang!) und andere Binärprogramme mittels
binfmt_misc Kernelmodul direkt ausführen
•
Prozess = laufende Instanz eines Programmes (PID, PPID, UID, EUID, …)
•
fork-Modell:
•
Prozess A ruft fork() auf → Kindprozess B entsteht als Kopie des Prozesses A
•
(Optional) Im Kindprozess B mittels exec() anderen Programmcode ausführen
•
Prozess A warte auf Kindprozess B mittels wait() → Rückgabewert! – oder Kindprozess wird zu
Zombie und vom init-Prozess entsorgt
•
Interrupts (von Hardware über CPU an Kernel oder weiter über Kernel an Prozess; Scheduling!)
•
Signale (von Prozess an anderen Prozess; HUP, INT, KILL, TERM, …)
Seite 4 von 139
Speicher
•
Virtueller Speicher für Prozess (vom Kernel verwaltet, Prozess kennt den tatsächlichen Ort von
Daten im RAM nicht; erhöht Sicherheit und Flexibilität)
•
Dynamisches Laden von Daten in den RAM mittels Page Fault Swap-Dateien bzw.
•
Swap-Partitionen
Reguläre Ausdrücke
•
Zeichenklassen (\d, \w, [a-z0-9])
•
Quantoren (*, +, ?, {n,m})
•
Gruppen und Referenzen ((?:...), \1)
•
Alternativen (|)
•
Anker (^, $, \b)
•
Für Befehle wie sed und grep, Texteditoren, Programmiersprachen, …
Befehle
•
whoami, who, w, last, id, script, less, which, locate, xargs
•
pwd, cd, ls, mkdir, rmdir, rm, mv, cp, find, touch, stat, file, chmod, chown, chgrp, umask, ln,
readlink
•
ps, pstree, kill, pgrep, pkill, top, nice, renice, free, swapon, swapoff
•
cat, split, head, tail, sort, cut, paste, uniq, nl, wc, expand, unexpand, tee
•
echo, printf, read, alias, unalias, source, export, sleep, timeout, set, unset, shift, shopt, exec
•
mount, umount, df, du
•
su, sudo
Seite 5 von 139
Foliensatz 1
Grundlagen
Inhalt
•
Aufgaben eines Systemadministrators
•
Arbeiten als root
•
Wichtige Verzeichnisse
•
procfs und sysfs
•
Geräte und das Gerätedateisystem
•
Kernelverwaltung
•
Hilfsmittel für Systemadministration
•
Puppet
Typische Aufgaben eines Systemadministrators
•
Installation und Konfiguration von Servern und Arbeitsplatzcomputern (möglichst automatisiert, ev.
über ein Netzwerk, wiederholbar)
•
Installation und Konfiguration von Software (System- bzw. Benutzerapplikationen, Konfiguration der
automatischen Sicherheitsupdates, Erstellung systemweiter Standardkonfigurationen)
•
Benutzerverwaltung (Anlegen, modifizieren und löschen von Benutzern und Gruppen)
•
Behebung von Softwareproblemen
•
Backups (einrichten, kontrollieren, wiederherstellen)
•
Monitoring (überwachen von Serversoftware, Netzwerk, … auf Probleme bzw. Angriffe)
•
Erstellen einer Benutzungsordnung („Policy“, politischer Aspekt)
•
Tausch von fehlerhafter Hardware (einzelne Komponenten, ganzer Computer, Peripheriegeräte)
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 (leicht) auf mehrere Benutzer aufgeteilt werden. Über
den
Befehl
sudo
kann
man
aber
trotzdem
relativ
einfach
andere
Benutzer
Systemadministrationsaufgaben durchführen lassen.
•
Unter Ubuntu hat der Benutzer root kein Passwort gesetzt, sondern es ist generell vorgesehen,
mittels sudo Aufgaben als root auszuführen.
Seite 6 von 139
sudo - Überblick
sudo - Führt Befehle mit den Rechten eines anderen Benutzers aus.
» Syntax: sudo [Optionen] [Befehl].
» Standardmäßig werden die Befehle als root ausgeführt.
» Konfigurationsdatei ist /etc/sudoers (editieren mit visudo).
» Man muss sein eigenes Passwort eingeben (nicht das des anderen Benutzers) und über die
Konfigurationsdatei die Rechte zum Ausführen des Befehls haben.
» Optionen:
•
-u Benutzername|UID → Befehl als dieser Benutzer ausführen
•
-i → Login-Shell ausführen
•
-l → Erlaubte Befehle anzeigen
» $ sudo head -n 1 /etc/shadow
root:*:15779:0:99999:7:::
$ sudo -i
[sudo] password for thomas:
root@noweto:~#
sudo - Konfigurationsdatei /etc/sudoers 1
•
Über die Konfigurationsdatei /etc/sudoers wird spezifiziert, welcher Benutzer welche Befehle
ausführen darf. Detaillierte Informationen zu der Datei findet man in der Manpage sudoers(5).
•
Die (vereinfachte) Syntax ist: wer wo = (als wer) was:
•
•
„wer“: Man kann Benutzernamen („thomas“), UIDs („1000“) und auch zum Beispiel
Gruppennamen („%gruppe“) verwenden. Der eingebaute Alias „ALL“ steht für alle Benutzer.
•
„wo“: Die Computer, auf denen die Befehle ausgeführt werden dürfen. Auch hier steht „ALL“ für
alle Computer.
•
„als wer“: Angaben wie bei „wer“, aber bestimmt, als welcher Benutzer die Befehle ausgeführt
werden dürfen.
•
„was“: Der Befehl und die Befehle, die ausgeführt werden dürfen. Wiederum steht „ALL“ für alle
Befehle.
Die Zeilen werden der Reihe nach abgearbeitet und die letzte, die zutrifft, wird verwendet.
sudo - Konfigurationsdatei /etc/sudoers 2
Beispiele:
•
root,%sudo
ALL=(ALL:ALL) ALL
Der Benutzer „root“ und alle Benutzer der Gruppe „sudo“ dürfen auf allen Computern alle Befehle
als jeder Benutzer und jede Gruppe (wegen „:ALL“) ausführen.
•
thomas praxis = (operator) /bin/ls, (root) /bin/kill, /usr/bin/lprm
Der Benutzer „thomas“ darf auf dem Computer „praxis“ den Befehl /bin/ls als „operator“ und
/bin/kill sowie /usr/bin/lprm als „root“ ausführen.
•
thomas ALL = (root) /sbin/*
Seite 7 von 139
Der Benutzer „thomas“ darf auf allen Computern jeden Befehl im Verzeichnis /sbin/ als „root“
ausführen.
sudo - Real Life
Manche versuchen sudo auch im realen Leben (meist mit weniger Erfolg):
XKCD Comic 149
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
/etc/systemd/system.conf)
•
Spezielles Format (/etc/sudoers)
mit
Werten,
eventuell
unterteil
in
Sektionen
(z.B.
Seite 8 von 139
Wichtige Verzeichnisse 1
•
Die Lage der Konfigurations-, Daten- und Systemdateien ist bei den meisten Linux-Distributionen
FHS-konform. Ausnahmen sind z.B. NixOS und GoboLinux.
•
/boot/ → Wichtige Dateien für das Booten (z.B. Kernel und initiale RAM-Disk), Unterverzeichnis
efi/ für den Zugriff auf die EFI-Partition
•
/dev/ → Gerätedateisystem für die benötigten Gerätedateien
•
/etc/ → Systemkonfigurationsdateien (werden an den entsprechenden Stellen genauer erklärt)
•
/lib/ → Systembibliotheken, u.a. auch für Kernel (modules/) und systemd (systemd/)
•
/proc/ → Datendateien des Kernels (auch Informationen zu Prozessen)
Wichtige Verzeichnisse 2
•
/run/ → Laufzeitdaten von Prozessen
•
/sys/ → Informationen über alle Geräte, die der Kernel kennt, und Möglichkeit, diese zu
konfigurieren (Linux-spezifisch)
•
/tmp/ → Speicherort für temporäre Dateien aller Benutzer
•
/var/ → Veränderbare Datendateien:
•
/var/cache/ → Cachedaten von Applikationen (z.B. apt)
•
/var/log/ → Logdateien (bei Verwendung von klassischen Logging-Daemonen)
•
/var/run/ → Nur mehr Symlink auf /run/
•
/var/spool/ → Spooling von Daten (Spool = Simultaneous Peripheral Operation On-Line,
aufspulen/abspulen; Zwischenlagerung von Druckjobs, Mails, …)
procfs
•
Das procfs (process filesystem) ist ein virtuelle Dateisystem, das auf vielen unixartigen
Betriebssystemen eingesetzt wird und üblicherweise im Verzeichnis /proc eingehängt ist.
•
Es dient zur Anzeige und zur Änderung von Prozess- und Systeminformationen. Da die Informationen
im Dateisystem dargestellt werden, können die Dateien darin mit den üblichen Befehlen bearbeitet
werden (z.B. cat für das Anzeigen und echo zusammen mit der Ausgabeumleitung für das Ändern).
•
In der Kernel-Dokumentation des procfs findet sich eine genaue Auflistung der vom Kernel zur
Verfügung gestellten Dateien und Verzeichnissen. Wir betrachten ein paar nützliche Teile davon.
procfs - Allgemeine Informationen
•
/proc/cpuinfo → Informationen zu den vorhandenen CPUs
•
/proc/devices, /proc/bus/input/devices,
vorhandenen Geräten
•
/proc/filesystems → Vom Kernel unterstützte Dateisysteme
•
/proc/loadavg → Informationen zur Systemauslastung
•
/proc/meminfo → Detailierte Speicherinformationen
/proc/bus/pci/devices
→
Informationen
zu
Seite 9 von 139
•
/proc/mounts → Liste der aktuell eingehängten Dateisysteme
•
/proc/net/ → Verzeichnis mit Netzwerkinformationen
•
/proc/stat → Allgemeine Statistiken
•
/proc/uptime → Betriebszeit des Systems
•
/proc/version → Kernelversion
procfs - Prozessinformationen
•
Jedem Prozess ist über seine PID ein Verzeichnis unterhalb von /proc zugeordnet. Ein Prozess kann
sich seine Informationen über den symbolischen Link /proc/self holen.
•
Einige nützlichen Dateien und Verzeichnisse in einem Prozessinformationsverzeichnis:
•
cmdline → Kommandozeilenargumente
•
cwd → Symbolischer Link zum aktuellen Arbeitsverzeichnis
•
environ → Umgebungsvariablen
•
status → Prozessstatus
•
fd → Verzeichnis mit Informationen zu Dateideskriptoren
procfs - Kernelparameter 1
•
Im Verzeichnis /proc/sys werden alle Kernelparameter aufgelistet.
•
Die Parameter können temporär durch direktes Schreiben in
Verzeichnisses geändert werden oder mittels des Programms sysctl.
•
Um die Parameterwerte permanent zu speichern, können diese in der Konfigurationsdatei
/etc/sysctl.conf (alte Variante) bzw. in *.conf-Dateien im Verzeichnis /etc/sysctl.d hinterlegt
werden.
•
Die Einträge werden zeilenweise in diese Dateien geschrieben, Kommentare können mit # oder ;
eingetragen werden:
Dateien
unterhalb
dieses
# Deaktivieren des Swapspeichers
vm.swappiness = 0
•
Beim Start des Systems werden die Parameterwerte aus diesen Dateien ausgelesen und in den
Kernelspeicher geschrieben. Das wird bei systemd durch die Unit systemd-sysctl.service erledigt.
procfs - Kernelparameter 2
•
Einige interessante Parameter:
•
vm/swappiness → Beeinflusst die Benutzung des Swap-Speichers (auf 0 gesetzt, wird er nicht
mehr benutzt)
•
kernel/sysrq → (De)aktivieren des magic SysRq key (erlaubt Tastenkombinationen, die der
Kernel direkt verarbeitet, z.B. Neustart des Systems)
•
net/ipv4/tcp_syncookies → (De)aktivieren des SYN-Flood-Schutzes
•
net/ipv4/ip_forward
Netzwerkschnittstellen
→
(De)aktivieren
der
Weiterleitung
von
Paketen
zwischen
Seite 10 von 139
•
•
net/ipv4/neigh/default/gc_thresh3 → Maximale Anzahl von Einträgen in der ARP-Tabelle
Eine Dokumentation der Parameter findet sich in der Kernel sysctl-Dokumentation bzw. für
Netzwerkparameter in IP-sysctl Dokumentation
procfs - sysctl
sysctl - Zeigt Kernelparameter an oder konfiguriert sie zur Laufzeit.
» Optionen:
•
-a → alle Parameter anzeigen
•
-w → Parameter schreiben
•
-r REGEX → nur Parameter benutzen, auf die der reguläre Ausdruck zutrifft
» $ sysctl vm.swappiness
vm.swappiness = 0
$ sysctl -w vm.swappiness=50
vm.swappiness = 50
$ sysctl -a -r gc_thresh[123]
net.ipv4.neigh.default.gc_thresh1
=
=
=
=
=
=
128
512
1024
128
512
1024
sysfs
•
Das sysfs ist ein virtuelles Dateisystem von Linux, welches Kernel-interne Informationen zu Geräten
und Treibern darstellt bzw. sie auch verändern lässt. Es existiert seit der Kernelversion 2.5 und ist
üblicherweise im Verzeichnis /sys eingehängt.
•
Durch die Einführung von sysfs wurden unter anderem Informationen, die früher verstreut im procfs
zu finden waren, an einem Ort zusammengefasst.
•
Einige interessante Verzeichnisse/Dateien:
•
devices/ → Informationen zu allen Geräten (z.B. devices/system/cpu/cpu0/ für Informationen
zur ersten CPU)
•
modules/ → Informationen zu Kernel-Modulen (z.B. modules/MODUL_NAME/parameters/* für
Informationen zu den Parametern des Moduls MODUL_NAME)
•
power/ → Energiesteuerung
Geräte und das Gerätedateisystem
•
Damit Applikationen auf Geräte zugreifen können, müssen diese Geräte über Dateien mit den Typen
„block device“ oder „character device“ im Dateisystem abgebildet sein. Diese Gerätedateien liegen
standardmäßig im Verzeichnis /dev.
•
Jedes Gerät wird über major und minor Zahlen eindeutig identifiziert. Die major Zahl gibt
üblicherweise den Treiber, die minor Zahl das Gerät an.
Seite 11 von 139
•
Früher wurden die Gerätedateien bei der Installation einmal statisch mittels mknod angelegt. Der
Nachteil dieser Vorgehensweise war, dass man alle möglichen Gerätedateien im Vorhinein anlegen
musste. Das machte das /dev-Verzeichnis sehr unübersichtlich und schwerer benutzbar.
•
Daher wurden Lösungen gesucht, um das Anlegen der benötigten Gerätedateien zu automatisieren.
Eine der ersten Lösungen war das devfs-Dateisystem, welches aber einige Nachteile hatte.
•
Derzeit wird das devtmpfs-Dateisystem für diesen Zweck verwendet. Es legt nur für die Geräte die
benötigten Gerätedateien an, die bei der Ausführung aktuell im Kernel vorhanden sind. Weiters kann
es alleine oder in Kombination mit udev verwendet werden.
Geräte und das Gerätedateisystem - lsusb, lspci
lsusb - Zeigt vorhandene USB-Geräte an.
» Optionen: -t → physische USB-Gerätehierachie anzeigen, -v → Details anzeigen
» $ lsusb | head -n 3
Bus 004 Device 039: ID 045e:07a5 Microsoft Corp.
Bus 004 Device 037: ID 17ef:100a Lenovo ThinkPad Mini Dock Plus Series 3
Bus 004 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
$ lsusb -t | head -n 4
/: Bus 04.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/3p, 480M
|__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/8p, 480M
|__ Port 8: Dev 37, If 0, Class=Hub, Driver=hub/6p, 480M
|__ Port 4: Dev 39, If 0, Class=Human Interface Device, Driver=usbhid,
12M
lspci - Zeigt vorhanden PCI-Geräte an.
» Optionen: -v → Details anzeigen, -k → Treiber für das Gerät anzeigen
» $ lspci | head -n 3
00:00.0 Host bridge: Intel Corporation 3rd Gen Core processor DRAM Controller (rev
09)
00:02.0 VGA compatible controller: Intel Corporation 3rd Gen Core processor
Graphics Controller (rev 09)
00:14.0 USB controller: Intel Corporation 7 Series/C210 Series Chipset Family USB
xHCI Host Controller (rev 04)
$ lspci -k -s 14.0
00:14.0 USB controller: Intel Corporation 7 Series/C210 Series Chipset Family USB
xHCI Host Controller (rev 04)
Subsystem: Lenovo Device 21fa
Kernel driver in use: xhci_hcd
Geräte und das Gerätedateisystem - lshw
lshw - Zeigt detaillierte Hardwareinformationen an.
» Es gibt auch eine GUI-Version lshw-gtk.
» Die Ausgabe kann sowohl im Textformat als auch in HTML, XML oder JSON erfolgen.
» Optionen: -short → Überblick über Gerätebaum ausgeben; -businfo → wie -short, aber mit BusInformation, -class → nur Geräte einer bestimmten Klasse anzeigen
» $ lshw -short | head -n 6
H/W path
Device
Class
Description
=========================================================
system
Computer
/0
bus
Motherboard
/0/0
memory
15GiB System memory
Seite 12 von 139
/0/1
processor
Intel(R) Core(TM) i5-3320M CPU @
2.60GHz
$ sudo lshw -class processor | head -n 7
*-cpu
product: Intel(R) Core(TM) i5-3320M CPU @ 2.60GHz
vendor: Intel Corp.
physical id: 1
bus info: cpu@0
size: 1399MHz
capacity: 3300MHz
Geräte und das Gerätedateisystem - udev
•
Durch das devtmpfs-Dateisystem werden die Gerätedateien in /dev automatisch erstellt. Allerdings
werden dadurch keine (Userspace-)Ereignisse ausgelöst, Berechtigungen richtig gesetzt oder
sinnvolle, permanente Namen für Geräte vergeben. Diese Aufgaben übernimmt udev.
•
udev wird über Dateien in den Verzeichnissen /lib/udev/rules.d, /run/udev/rules.d und
/etc/udev/rules.d konfiguriert. Die in diesen Verzeichnissen liegenden *.rules Dateien enthalten
die Regeln, wie der udev-Daemon auf die Kernelereignisse reagieren sollen.
•
Die Syntax dieser Konfigurationsdateien ist in udev(7) genau beschrieben.
•
Hier z.B. eine Regel, die einer bestimmten Netzwerkkarte immer den selben Namen zuweist:
# PCI device 0x8086:/sys/devices/pci0000:00/0000:00:19.0 (e1000e)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="3c:97:0e:79:b8:0a",
ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"
•
Mittels des Befehls udevadm können die Informationen von udev abgefragt werden, was aber im
Normalbetrieb meist nicht nötig ist.
Kernel - Allgemeines
•
Früher hat man den Linux-Kernel oft selbst kompiliert, um ihn auf die benutzte Hardware
abzustimmen. Das richtige Konfigurieren und Kompilieren eines Linux-Kernels ist aber nicht einfach
und es können leicht Fehler passieren.
•
Heutzutage wird üblicherweise der Kernel verwendet, den die Distribution liefert. Dieser ist
getestet, beinhaltet die wichtigsten Komponenten und stellt alle sonstigen Komponenten als KernelModule zur Verfügung. Das ist dann ein generischer Kernel, der nicht speziell auf die persönliche
Hardware zugeschnitten wurde, sondern auf unterschiedlichster Hardware läuft.
•
Wichtig: Alle Treiber, die der Kernel beim Booten benötigt, müssen entweder fix in den Kernel
eingebunden oder in einer sogenannten Initial Ramdisk (wird als Root-Dateisystem benutzt bis das
echte Root-Dateisystem geladen werden kann) vorhanden sein.
•
Der Kernel selbst und die zusätzlich benötigten Dateien (wie z.B. eine initiale RAM-Disk) liegen im
Verzeichnis /boot. Üblicherweise heißt die Datei für den Kernel vmlinuz-RELEASE (wobei RELEASE
die Kernel-Release ist).
Seite 13 von 139
Kernel-Module
•
Kernel-Module erlauben es dem Kernel, im Nachhinein zusätzliche Funktionalitäten wie z.B. neue
Treiber oder neue Dateisysteme zu verwenden. Üblicherweise werden z.B. die Treiber für die
Soundkarte oder die Netzwerkkarte als Kernel-Module zur Verfügung gestellt.
•
Kann der Kernel mit einem Gerät nicht umgehen/kommunizieren, so wird automatisch versucht, den
richtigen Treiber (i.e. das richtige Kernel-Modul) für das Gerät zu laden. Das funktioniert
mittlerweile sehr gut, d.h. nur in Ausnahmefällen muss man das richtige Kernel-Modul händisch
laden.
•
Die Kernel-Module liegen unterhalb des Verzeichnisses /lib/modules/RELEASE.
•
Über die Konfigurationsdatei /etc/modules bzw. Dateien mit der Endung .conf im Verzeichnis
/etc/modules-load.d/ kann man festlegen, welche Kernel-Module beim Start geladen werden
sollen.
Kernel - Sonstiges
•
Unter Ubuntu findet man den Standardkernel im Paket linux-image-generic und die zugehörigen
Header-Dateien im Paket linux-headers-generic.
•
Weiters werden die initiale RAM-Disks über die initramfs-tools verwaltet, mehr Informationen dazu
unter initramfs-tools(8).
Dynamic Kernel Module Support (DKMS)
•
Früher hat es immer das Problem gegeben, dass man Kernel-Module, die nicht mit dem Kernel selbst
mitinstalliert wurden, bei einem Kernelupdate selbst neu kompilieren musste.
•
Das Dynamic Kernel Module Support-System (DKMS) wurde aus diesem Grund 2003 bei Dell
entwickelt. Es erlaubt unter anderem das automatische Kompilieren von Kernel-Modulen nach
Installation eines neuen Kernels bzw. bei Installation eines Kernel-Moduls.
•
Damit das DKMS funktionieren kann, braucht man natürlich die Header-Dateien des verwendeten
Kernels sowie die benötigten Programme zur Kompilation der Kernel-Module.
•
Unter Ubuntu wird das DKMS mit Hilfe des Pakets dkms installiert. Pakete, die Kernel-Module
enthalten, die über DKMS verwaltet werden, haben üblicherweise das Suffix „-dkms“ im
Paketnamen.
Befehle zur Kernelverwaltung - uname, dmesg
uname - Zeigt Systeminformationen an.
» Nützliche Optionen: -a → alle Informationen anzeigen, -r → Kernel-Release anzeigen.
» $ uname -a
Linux noweto 4.2.0-27-generic #32-Ubuntu SMP Fri Jan 22 04:49:08 UTC 2016 x86_64
x86_64 x86_64 GNU/Linux
$ ls -l /lib/modules/`uname -r` | head -4
total 4380
lrwxrwxrwx 1 root root
39 Jän 22 08:14 build -> /usr/src/linux-headers-4.2.027-generic
drwxr-xr-x 2 root root
4096 Jän 22 08:06 initrd
Seite 14 von 139
drwxr-xr-x 12 root root
4096 Jän 25 09:03 kernel
dmesg - Zeigt den Kernel-Buffer an.
» Ist zum Beispiel nützlich um zu sehen, ob beim Laden oder Entfernen eines Kernel-Moduls ein
Problem aufgetreten ist.
» Optionen: -e → lesbare Zeitstempel verwenden
» $ dmesg -e | head
[Feb16 19:32] usb
[ +0,094753] usb
[ +0,000007] usb
[ +0,000004] usb
-n 4
3-1.2:
3-1.2:
3-1.2:
3-1.2:
new high-speed USB device number 6 using ehci-pci
New USB device found, idVendor=0781, idProduct=5580
New USB device strings: Mfr=1, Product=2, SerialNumber=3
Product: Extreme
Befehle für Kernel und Kernel-Module - lsmod, insmod
lsmod - Zeigt die Liste der geladenen Kernel-Module an.
» $ lsmod | head -5
Module
Size Used by
uvcvideo
80847 0
videobuf2_vmalloc
13056 1 uvcvideo
videobuf2_memops
13202 1 videobuf2_vmalloc
videobuf2_core
40513 1 uvcvideo
insmod - Lädt ein Kernel-Modul.
» Beachtet keine Abhängigkeiten, sondern versucht einfach, das gegebene Kernel-Modul zu in den
Kernel zu laden. Besser ist modprobe.
» Syntax: insmod Modulpfad [Optionen]
Befehle für Kernel und Kernel-Module - rmmod, modinfo
rmmod - Entfernt ein Kernel-Modul aus dem Kernel.
» Sehr einfaches Programm; besser ist modprobe.
» Syntax: rmmod Modulname
modinfo - Zeigt Informationen zu einem Kernel-Modul an.
» Syntax: modinfo Modulname
» $ modinfo snd
filename:
alias:
license:
description:
author:
srcversion:
depends:
intree:
vermagic:
signer:
sig_key:
sig_hashalgo:
parm:
parm:
parm:
/lib/modules/4.2.0-27-generic/kernel/sound/core/snd.ko
char-major-116-*
GPL
Advanced Linux Sound Architecture driver for soundcards.
Jaroslav Kysela <[email protected]>
FBB791631E8C58B815FCEAD
soundcore
Y
4.2.0-27-generic SMP mod_unload modversions
Build time autogenerated kernel key
94:21:CE:78:F7:DD:69:32:D7:A7:1D:3B:AB:89:BB:03:6A:FA:29:EB
sha512
slots:Module names assigned to the slots. (array of charp)
major:Major # for sound driver. (int)
cards_limit:Count of auto-loadable soundcards. (int)
Seite 15 von 139
Befehle für Kernel und Kernel-Module - modprobe
modprobe - Lädt oder entfernt ein Kernel-Modul.
» Löst automatisch die Abhängigkeiten zwischen Kernel-Modulen auf (dazu wird eine von depmod
generierte Datei verwendet), d.h. benötigte Kernel-Module werden automatisch geladen bzw. nicht
mehr gebrauchte automatisch entfernt.
» Es muss nicht der Pfad zu einem Modul angegeben werden, sondern nur der Modulname.
» Modul-Parameter können als Argumente übergeben werden. Es werden dabei aber auch die
Konfigurationsdateien im Verzeichnis /etc/modprobe.d/ beachtet (siehe man modprobe.d).
» Optionen: -r → Entfernen eines Kernel-Moduls.
» Syntax: modprobe [-r] Modulname [Optionen]
» $ modprobe iwlwifi 11n_disable=2
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 „abhängig“ von dem Admin-Programm.
Hilfsmittel für Systemadministration 2
•
Besser sind Konfigurationsmanagementprogramme (z.B. Puppet oder Chef), die meist aus einer
Server- und einer Client-Komponente bestehen (siehe Vergleich von mehreren dieser Programme auf
Wikipedia).
•
Diese erlauben es, einen Computer 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/Arbeitsplatzcomputer verwalten muss, sollte man sich überlegen, ob
man nicht so ein Programm einsetzen sollte.
•
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 Computers schnell wieder alles
richtig konfiguriert zu haben.
Seite 16 von 139
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 Introduction to Puppet
oder mit der Learning VM.
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 Computers).
•
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
Seite 17 von 139
Puppet - Module und Umgebungen
•
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.
•
In der aktuellen Version von Puppet können einzelne Manifeste und „lose“ Dateien und Templates
weiterhin verwendet werden, allerdings ist das gesamte System nun primär auf Module ausgelegt.
•
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.
•
Weiters unterstützt Puppet Umgebungen (Environments), wobei jede Umgebung unterschiedliche
Module verwenden kann. Damit ist es z.B. leicht, eine Testumgebung für nur ein paar Computer
aufzusetzen.
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.
•
Zusätzlich besitzt jeder Ressourcetyp ein spezielles namevar Attribut, um eine Ressource eindeutig
identifizieren zu können. Wird dieses namevar Attribute nicht gesetzt, so wird standardmäßig der
Wert des Titels dafür genommen. Über die Kombination Ressourcetyp/namevar kann die Ressource
später eindeutig referenziert werden.
•
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.
Seite 18 von 139
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'],
source => "puppet:///files/ntp.conf",
}
Um dieses Manifest anzuwenden, muss noch die Datei ntp.conf im aktuellen Vereichnis angelegt und
folgenden Befehl ausgeführt werden:
$ puppet apply --fileserverconfig=<(echo -e "[files]\npath `pwd`\nallow *") manifest.pp
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 nicht unbedingt ein Server benötigt, man kann auch eine Manifestdatei angeben:
$ puppet apply manifest.pp
•
Wenn man seine Manifeste in Module gegliedert hat, muss man über die Option --modulepath
diesen Pfad angeben, damit Puppet sie findet.
•
Zum Testen sind die Optionen --test (mehr anzeigen) und --noop (nichts wirklich ändern)
nützlich.
Seite 19 von 139
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 ClientZertifikat 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
die
in
/etc/puppet/environments/production/manifests/ definierten Manifeste und erstellt daraus
einen Katalog, der an den Client zurückgesandt und auf das System angewandt wird.
Dateiverwaltung mit Puppet
•
Dateien werden in Puppet über die Ressource file verwaltet.
•
Unter Ubuntu wird standardmäßig der Provider posix verwendet.
•
Wichtige Attribute:
•
path: Der absolute Pfad der Datei (falls nicht angegeben, wird der Titel verwendet).
•
ensure: Der gewünschte Zustand (present, absent, file, directory oder link)
•
backup: Spezifiziert, ob und wie ein Backup gemacht werden soll (false, Zeichenkette beginnend
mit Punkt oder sonstige Zeichenkette)
•
content: Der Inhalt der Datei (nicht gleichzeitig mit source verwendbar).
•
source: Eine URI, deren Inhalt verwendet werden soll (lokale Datei oder vom Puppetserver).
•
target: Linkziel.
•
owner: Der Besitzer der Datei.
•
group: Der Gruppenbesitzer der Datei.
•
mode: Die Rechte der Datei.
Dateiverwaltung mit Puppet - Beispiele
•
Anlegen eines Verzeichnisses:
file {'/var/local': ensure => directory}
•
Erstellen eines symbolischen Links:
file {'/var/local/test':
ensure => link,
target => '/etc/modules' }
•
Erstellen einer Datei mit einem bestimmten Inhalt:
file {'/etc/my.secret':
Seite 20 von 139
owner => root,
group => root,
mode => 600,
content => 'My secret secret' }
•
Kopieren einer Datei von der Dateisektion ‚common‘ vom Puppetserver:
file {'/etc/ssh/sshd_config':
ensure => present,
owner => root,
group => root,
mode => 644,
source => ["puppet:///common/sshd_config.$fqdn", 'puppet:///common/sshd_config'] }
Puppet - Weitere 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)
•
Verwenden eines Moduls zur Einrichtung eines OpenSSH-Servers
•
Ändern von Dateien mit Hilfe von Augeas
Seite 21 von 139
Foliensatz 2
Systemstart und -services
Inhalt
•
Bootloader (GRUB 2)
•
init-Programme (SysVinit, systemd)
•
Logging
•
Systemzeit, Zeitzonen, Zeitserver
•
Locale
•
Automatisierung (cron, at)
•
OpenSSH-Server
Start des Betriebssystems
•
Das BIOS (Basic Input Output System) bzw. das UEFI (Unified Extensible Firmware Interface) –
gespeichert auf einem Chip direkt am Motherboard – initialiert die Hardware und läd den Bootloader
von einer Partition einer Festplatte, von einem USB Gerätes, von einer CD, …
•
Der Bootloader (unter Linux meist GRUB 2) übergibt die Kontrolle an ein Betriebssystem, in
unserem Fall dem Linux-Kernel.
•
Der Linux-Kernel bereitet die Hardware vor und übergibt dann an den init-Prozess, welcher das
System konfiguriert.
•
Sobald die initiale Konfiguration des Systems abgeschlossen ist, werden die Login-Programme
gestartet und der Benutzer kann sich einloggen.
Bootloader GRUB 2
•
Ubuntu verwendet den Bootloader GRUB 2, wie die meisten anderen Distributionen.
•
Einige Features von GRUB:
•
Über ein Bootmenü kann ausgewählt werden, welches Betriebssystem gestartet werden soll bzw.
kann ein Eintrag auch bearbeitet und dann ausgeführt werden.
•
Bootmenüeinträge können durch Passwörter geschützt werden.
•
Nicht nur der Linux-Kernel, sondern auch andere Betriebssysteme wie z.B. DOS, Windows oder
BSD-Varianten können gestartet werden.
Links: GRUB Manual, Ubuntu GRUB Dokumentation, GRUB 2 auf ubuntuusers.de, ArchLinux GRUB
Dokumentation
Seite 22 von 139
GRUB 2 - Konfiguration 1
•
Die fertige Konfiguration sowie benötigte Dateien von GRUB befindet sich im Verzeichnis
/boot/grub. Die Konfigurationsdatei ist /boot/grub/grub.cfg, welche eine ähnliche Syntax wie
Bash-Skripte besitzt. Allerdings sollten Änderung nicht direkt vorgenommen werden, weil sie bei
Updates überschrieben werden.
•
Damit GRUB die Konfigurationsdateien lesen kann, müssen sie auf einem unterstützten Dateisystem
liegen. Deswegen ist unter /boot/ oft eine eigene Partition einghängt.
•
Zum Konfigurieren werden die Datei /etc/default/grub sowie Shell-Skripte in /etc/grub.d/
benutzt. Nach Änderungen muss der Befehl update-grub ausgeführt werden, damit die Änderungen
nach /boot/grub/ geschrieben werden.
•
In /etc/default/grub sind Shell-Variablen definiert, über welche einfache Änderungen an der
Konfiguration gemacht werden können, wie z.B. ändern des Timeouts für das Bootmenü oder
deaktivieren des graphischen Terminals.
GRUB 2 - Konfiguration 2
•
Die Skripte in /etc/grub.d/ werden unter Berücksichtigung der Shell-Variablen von
/etc/default/grub der Reihe nach ausgeführt und deren Ausgabe erzeugt die Datei
/boot/grub/grub.cfg.
•
Dabei werden automatisch die installierten Kernel erkannt und Menüeinträge für sie erzeugt.
•
Genauso wird nach anderen Betriebssystemen auf alle Festplatten und Partitionen gesucht und
Menüeinträge für die gefundenen Betriebssystem erstellt.
•
Werden spezielle Menüeinträge zusätzlich gebraucht, so können diese in der Datei 40_custom
definiert werden.
GRUB 2 - Utilities
•
Mit Hilfe von grub-set-default kann der Standardmenüeintrag festgelegt werden, der automatisch
nach einem Timeout verwendet wird, wenn nichts anderes ausgewählt wird.
Damit das funktioniert, muss zusätzlich GRUB_DEFAULT=saved in /etc/default/grub gesetzt werden.
•
Soll nur einmalig beim nächsten Boot ein anderer Menüeintrag als Voreinstellung verwendet
werden, so kann das mit grub-reboot festgelegt werden.
•
Beide obigen Befehle setzen Umgebungsvariablen für GRUB in der Datei /boot/grub/grubenv. Zum
Auslesen und Editieren dieser Datei kann der Befehl grub-editenv verwendet werden.
GRUB 2 - Sonstiges
•
Bei der Installation der Linux-Distribution wird GRUB automatisch auf der Festplatte installiert.
Dazu wird der Befehl grub-install verwendet.
•
Bei Systemen mit einem BIOS wird GRUB entweder in den MBR (Master Boot Record) oder bei
Verwendung von GPT in eine eigene Partition geschrieben.
•
Bei UEFI-Systemen wird GRUB auf die ESP (EFI System Partition) geschrieben.
Seite 23 von 139
Meist braucht man grub-install selbst nicht ausführen. Es kann aber trotzdem nützlich sein, z.B.
wenn bei Nicht-UEFI-Systemen Windows nach Linux installiert worden ist und Windows daher den
MBR überschrieben hat.
•
Andere Bootloader:
•
Neben GRUB wird auch noch LILO als Bootloader verwendet, allerdings wird LILO derzeit nicht
weiterentwickelt.
•
Für das Booten über PXE gibt es einen eigenen Bootloader namens PXELINUX.
Systemstart
•
Beim Systemstart werden durch den init-Prozess mit der PID 1 die nötigen Systemservices bzw.
Daemonen (Disk and execution monitor) gestartet.
•
Welche Programme beim Systemstart automatisch gestartet werden, wird durch das init-Programm
und dessen Konfiguration vorgegeben.
•
Es gibt mehrere verschiedene init-Programme, früher war SysVinit mit den init-Skripten (ShellSkripte) der Standard. Um den Start zu optimieren, verwenden moderne Distributionen aber andere
init-Programme, die meisten davon systemd (Ausnahme z.B. Gentoo mit OpenRC).
•
Daemonen laufen im Hintergrund und führen wichtige Systemaufgaben aus (z.B. udevd oder dbus)
oder stellen bestimmte Services bereit (z.B. sshd oder atd).
•
Im Verzeichnis /etc/default/ finden sich zu vielen Systemservices und Daemonen zusätzliche
Konfigurationsdateien (Shell-Skripte, welche Variablen definieren), z.B. /etc/default/dbus.
•
Kommuniziert wird mit Daemonen meist über Signale (z.B. wird HUP oft verwendet, um die
Konfiguration neu zu laden), in den letzten Jahren wird verstärkt auch D-Bus für die Kommunikation
verwendet.
SysVinit
•
Ursprünglich für das Unix-Betriebssystem System V geschrieben, war SysVinit aber bis vor einigen
Jahren auch der Standard bei den meisten Linux-Distributionen.
•
Bei SysVinit wird ein kleines init-Programm vom Kernel als erster Prozess mit PID 1 gestartet und
dieser Prozess startet dann, je nach Runlevel, die Systemservices.
•
Für jedes Service gibt es im Verzeichnis /etc/init.d/ ein Shell-Skript, welches als Argument
zumindest start, stop und status erlaubt (meist auch noch restart und reload). D.h. um ein
bestimmtes Service zu starten, braucht man nur /etc/init.d/SERVICE start aufrufen.
•
In den meisten init-Skripten ist zu Beginn ein sogenannter LSB-Block (Linux Standards Base)
eingebaut, damit das Skript von unterschiedlichen init-Programmen richtig verwaltet werden kann.
Siehe auch LSBInitScripts im Debian Wiki.
Links: SysVinit im Debian Manual, SysVinit auf ubuntuusers.de, ArchLinux SysVinit Dokumentation
Seite 24 von 139
SysVinit - Runlevels
•
Es gibt 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 Einzelnutzer-Modus (danach befindet sich das System im Runlevel S).
Die Runlevel 2, 3, 4 und 5 haben distributionsabhängige Bedeutung.
•
Zu jedem Runlevel gibt es ein entsprechendes Verzeichnis /etc/rc{0..6,S}.d/, in welchem
symbolische Links der Form „S<NUMMER><NAME>“ bzw. „K<NUMMER><NAME>“ liegen, die
auf die Skripte in /etc/init.d/ verweisen.
Wird in ein bestimmtes Runlevel gewechselt, so werden die Skripte mit dem Prefix „S“ der Reihe
nach ausgeführt, beim Verlassen des Runlevels jene mit dem Prefix „K“.
•
Was in welchem Runlevel gemacht wird, wird zentral durch die Konfigurationsdatei /etc/inittab
festgelegt. Dort ist z.B. definiert, dass die Skripte der Runlevels wie oben beschrieben ausgeführt
werden.
SysVinit - Programme 1
runlevel - Zeit das vorherige und aktuelle Runlevel an.
» „N“ bedeutet, dass das Runlevel seit dem Start nicht geändert worden ist.
» $ runlevel
N 5
telinit - Ändert das Runlevel.
» $ telinit 6 # Neustart
update-rc.d - Installiert und entfernt Links auf SysVinit-Skripte.
» Wird benutzt, um die symbolischen Links in /etc/rc{0..6,S}.d zu verwalten.
» $ update-rc.d ntp defaults # init-Skript-Links für ntp installieren
$ update-rc.d ntp disable # Deaktivieren von ntp
insserv: warning: current start runlevel(s) (empty) of script `ntp' overrides LSB
defaults (2 3 4 5).
insserv: warning: current stop runlevel(s) (1 2 3 4 5) of script `ntp' overrides
LSB defaults (1).
$ update-rc.d ntp enable # Reaktivieren von ntp
SysVinit - Programme 2
shutdown - Hält den Computer an oder startet ihn neu.
» Man kann zwar mit telinit das Runlevel ändern und den Computer neustarten, allerdings ist das
nicht sehr gut, wenn Benutzer eingeloggt sind, da diese nichts mehr speichern können etc.
» shutdown sendet zuerst eine Warnung an die Terminals aller eingeloggten Benutzer und nach
einer definierten Zeit wird der Runlevel geändert.
» Optionen: -r → Neustart, -H → Anhalten, -P → Herunterfahren (default), -c → Abschaltung
widerrufen
» $ shutdown -r +10 "Das System wird in 10 Minuten neugestartet."
Shutdown scheduled for Wed 2016-03-02 18:54:31 CET, use 'shutdown -c' to cancel.
Und in einem anderen Terminal erscheint die Nachricht:
Seite 25 von 139
Broadcast message from root@noweto on pts/3 (Wed 2016-03-02 18:44:31 CET):
Das System wird in 10 Minuten neugestartet.
The system is going down for reboot at Wed 2016-03-02 18:54:31 CET!
systemd
•
Das init-Programm systemd hat in der jüngeren Vergangenheit an Popularität gewonnen. Es wurde
schon länger z.B. in Fedora benutzt und ist nun auch das Standard-init-Programm in Debian und
Ubuntu.
•
systemd hat einige Vorteile, bringt aber auch tiefgreifende Änderungen mit sich:
•
Der Start des Systems ist sehr schnell, er dauert meist nur wenige Sekunden.
•
Abhängigkeiten zwischen Services werden (meist) automatisch aufgelöst.
•
Viele Services werden nicht automatisch, sondern on-demand gestartet (z.B. via D-BusAktivierung oder Socket-Aktivierung).
•
systemd ist kompatibel zu SysVinit, d.h. alte init-Skripte funktionieren weiterhin (siehe man
systemd-sysv-generator).
•
Logging funktioniert bei systemd über journald, welches ein Binärformat zur Speicherung der
Logdaten benutzt.
•
systemd ist nicht mehr portabel, da es viele Linux-spezifische Funktionalitäten braucht.
Links: systemd Homepage, Ubuntu Wiki-Eintrag zu systemd, Debatte über Systemd bei Debian
systemd - Allgemeines
•
Im Gegensatz zu anderen init-Programmen ist systemd ein sehr großes Programm, was auch an der
Fülle an Funktionalitäten liegt (das hört man oft als Kritik an systemd).
•
Zudem besitzt systemd eine Reihe an optionalen Komponenten/Programmen, die Programme wie z.B.
ntpd (durch systemd-timesyncd) oder NetworkManager (durch systemd-networkd) ersetzen können.
•
Daneben übernehmen Hilfsprogramme von systemd auch Aufgaben wie das Setzen der Systemzeit
(timedatectl, systemd-timedated) oder des Hostnamens (hostnamectl, systemd-hostnamed).
•
Das alles macht es nicht einfach, bei systemd den Überblick zu bewahren, was wann wie verwendet.
•
In der Datei /etc/systemd/system.conf können allgemeine, systemd-betreffende Einstellungen
verändert werden, wie z.B. das Logging-Level.
systemd - Units 1
•
Die Konfiguration bei systemd besteht aus Unit-Dateien mit 12 unterschiedliche Typen. Die für uns
wichtigsten sind:
•
Service Units
Diese dienen dem Starten und Kontrollieren von Systemservices und entsprechen, mehr oder
weniger, den Shell-Skripten bei SysVinit.
Seite 26 von 139
•
Target Units
Diese fassen mehrere Units zusammen und entsprechen, mehr oder weniger, den Runlevels bei
SysVinit. Das Standard-Target ist default.target.
•
Daneben gibt es noch Units, die Sockets, Mountpoints oder auch Geräte beschreiben, um on-demand
Aktivierung zu ermöglichen.
•
Zudem werden Units dynamisch von systemd zur Laufzeit erzeugt, z.B. Device Units, die via udev mit
einem speziellen Tag versehen sind.
•
Die Unit-Dateien liegen in /{etc,run,lib}/systemd/system/ (die Reihenfolge der Ordner bestimmt,
von wo eine Unit-Datei geladen wird, falls es mehrere mit dem gleichen Namen gibt).
systemd - Units 2
Beispielkonfiguratsdatei für cron:
[Unit]
Description=Regular background program processing daemon
Documentation=man:cron(8)
[Service]
EnvironmentFile=-/etc/default/cron
ExecStart=/usr/sbin/cron -f $EXTRA_OPTS
IgnoreSIGPIPE=false
[Install]
WantedBy=multi-user.target
•
Unter „[Service]“ ist definiert, wie der cron-Daemon gestartet werden soll. Man sieht, dass
Umgebungsvariablen aus /etc/default/cron verwendet werden.
•
Unter „[Install]“ ist definiert, dass beim Aktivieren dieses Services eine Abhängigkeit zu multiuser.target aufgebaut wird, damit das cron-Service automatisch mitgestartet wird.
systemd - systemctl 1
systemctl - Steuert systemd.
» Bei systemd benutzt man dieses Programm, um alle Funktionen, die früher auf verschiedene
Programme aufgeteilt waren, durchzuführen. Daher besitzt es eine Fülle an möglichen Befehlen.
» Anzeige des Statuses des Systems:
$ systemctl status | head -n 15
● noweto
State: running
Jobs: 0 queued
Failed: 0 units
Since: Son 2016-02-14 15:49:45 CET; 2 weeks 3 days ago
CGroup: /
├─
1 /lib/systemd/systemd --system --deserialize 18
├─1439 /sbin/cgmanager -m name=systemd
├─1440 /usr/bin/lxcfs /var/lib/lxcfs/
├─system.slice
│ ├─avahi-daemon.service
Seite 27 von 139
│ │ ├─1442 avahi-daemon: running [noweto.local
│ │ └─1447 avahi-daemon: chroot helpe
│ ├─mdadm.service
│ │ └─1407 /sbin/mdadm --monitor --pid-file
--daemonise --scan --syslog
/run/mdadm/monitor.pid
systemctl Fortsetzung
» Befehle für einzelne Units (mit cron.service als Beispielunit):
$ systemctl start cron.service # Unit starten
$ systemctl stop cron.service # Unit stoppen
$ systemctl restart cron.service # Unit stoppen und starten
$ systemctl is-enabled cron.service # Wird die Unit beim Systemstart gestartet
enabled
$ systemctl disable cron.service &>/dev/null # Aktivieren der Unit
$ systemctl enable cron.service &>/dev/null # Deaktivieren der Unit
$ systemctl help cron.service # Hilfe zur Unit anzeigen (z.B. Manpage)
$ systemctl status cron.service
● cron.service - Regular background program processing daemon
Loaded:
loaded
(/lib/systemd/system/cron.service;
enabled;
vendor
preset:
enabled)
Active: active (running) since Don 2016-03-03 12:41:46 CET; 19h ago
Docs: man:cron(8)
Main PID: 12085 (cron)
CGroup: /system.slice/cron.service
└─12085 /usr/sbin/cron -f
Mär 03 12:41:46 noweto systemd[1]: Started Regular background program processing
daemon.
Mär 03 12:41:46 noweto cron[12085]: (CRON) INFO (pidfile fd = 3)
Mär 03 12:41:46 noweto cron[12085]: (CRON) INFO (Skipping @reboot jobs -- not
system startup)
systemctl Fortsetzung
» Befehle für die Energieverwaltung:
$ systemctl reboot # System neustarten, wie shutdown -r
$ systemctl poweroff # System abschalten, wie shutdown -P
$ systemctl suspend # System in den Schlafmodus versetzen
» Andere nützliche Befehle:
$ systemctl cat cron.service # Zeigt die zugehörige Unit-Datei an
# /lib/systemd/system/cron.service
[Unit]
Description=Regular background program processing daemon
Documentation=man:cron(8)
$ systemctl list-units --type=target | head -n 3 # Alle Units eines Typs anzeigen
UNIT
LOAD
ACTIVE SUB
DESCRIPTION
basic.target
loaded active active Basic System
bluetooth.target
loaded active active Bluetooth
$ systemctl isolate rescue.target # Den Einzelnutzer-Modus aktivieren
Seite 28 von 139
Einschub: D-Bus
•
D-Bus dient zur Interprozesskommunikation. Es stellt eine genormte Schnittstelle zur Verfügung,
über die sich Prozesse gegenseitig Nachrichten schicken können.
•
Aber D-Bus bietet noch einiges mehr:
•
Ein Prozess kann sich für eine bestimmte Nachricht registrieren und wird automatisch
benachrichtigt, sobald eine solche Nachricht geschickt wird (z.B. Netzwerkverbindung
hergestellt/getrennt).
•
D-Bus-Services können on-demand gestartet werden, d.h. erst, sobald ein Prozess auf das Service
zugreift.
•
Es kann festgelegt, welche Nutzer auf welche Services zugreifen dürfen.
•
Ein D-Bus-Service wird für das System selbst gestartet und eines für jeden eingeloggten Benutzer.
•
systemd verwendet D-Bus, um Daemonen und Services bei Bedarf zu aktivieren und danach wieder
zu deaktivieren (z.B. für systemd-timedated).
•
Auch Desktopumgebungen wie Gnome und KDE verwenden mittlerweile D-Bus anstatt CORBA bzw.
DCOP.
Logging 1
•
Unter Linux können alle Programme auf eine zentrale Logging-Infrastruktur namens Syslog
zugreifen.
•
Um Einträge im Syslog zu erzeugen, kann entweder die syslog-Funktion der C-Bibliothek (siehe man
3 syslog bzw. syslog im Glibc-Manual) oder der Socket /dev/log benutzt werden.
•
Der Kernel selbst verwendet nicht das Syslog, sondern den Kernel-Buffer, um Nachrichten zu
loggen (siehe man 2 syslog). Dieser Buffer kann mittels dmesg angezeigt werden.
•
Syslog-Einträge bestehen aus der Nachricht selbst, einem Tag (normalerweise der Programmname),
einer Facility (welche Art von Programm die Nachricht geschickt hat) und einem Log-Level (der
Wichtigkiet) - für Details siehe man 3 syslog.
Logging 2
•
Das Syslog sowie meist auch der Kernel-Buffer werden von einem Logging-Daemon ausgelesen und
verarbeitet. Man hat dabei (wie üblich) die Wahl zwischen mehreren Logging-Daemonen, z.B.
rsyslog (Standard in Ubuntu) und syslog-ng.
Bei systemd ist systemd-journald inkludiert, welcher nicht deaktiviert, aber gleichzeitig mit einem
klassischen Logging-Daemon verwendet werden kann.
•
Daneben erstellen Programme auch selbst Log-Dateien in /var/log/, z.B. der Apache HTTP Server
im Unterverzeichnis apache2.
Links: Glibc Syslog Overview, Logdateien auf ubuntuusers.de
Seite 29 von 139
Logging - rsyslog
•
rsyslog ist der Standard-Logging-Daemon, der bei Ubuntu neben dem systemd Journal verwendet
wird.
•
Er unterscheidet sich von anderen Logging-Daemonen nur geringfügig in der Funktionalität. Alle
solche Daemonen sind standardmäßig in der Art konfiguriert, dass sie die Nachrichten des Syslogs
und Kernel-Buffers entgegen nehmen und in Logdateien unter den gleichen, üblichen Pfaden in
/var/log speichern.
•
Wichtige Logdateien:
•
•
/var/log/auth.log → Authentifizierungsnachrichten (z.B. erfolglose/-reiche Logins)
•
/var/log/syslog → Alle Informationen
•
/var/log/kern.log → Kernel-Nachrichten
Falls an den Einstellungen von rsyslog selbst etwas geändert werden soll, wird die Datei
/etc/rsyslog.conf benutzt. Die Regeln, die angeben, welche Nachrichten wo gespeichert werden,
werden über Dateien in /etc/rsyslog.d festgelegt (siehe man rsyslog.conf).
Logging - systemd Journal
•
systemd kommt mit einem eigenen Logging-Daemon namens journald, wodurch ein separater
Logging-Daemon nicht mehr unbedingt notwendig ist.
•
Im Gegensatz zu den klassischen Logging-Daemonen speichert journald standardmäßig die Daten in
einem Binärformat unter /var/log/journal, falls dieses Verzeichnis existiert, ansonsten unter
/run/log/journal (hier keine permanente Speicherung!).
•
Die Konfiguration des Journals wird über /etc/systemd/journal.conf gesteuert. Dort können
Einstellungen wie die maximale Größe des Journals, optionale Kompression, etc. eingestellt werden.
Zudem kann festgelegt werden, ob die Log-Einträge an einen klassischen Logging-Daemon
weitergeleitet werden sollen.
•
Da die Daten im Binärformat vorliegen, muss der Befehl journalctl zum Anzeigen und Verarbeiten
des Logs herangezogen werden.
Logging - journalctl
journalctl - Zeigt das systemd Journal an.
» Der Befehl erlaubt das Anzeigen und Filtern der Einträge nach vielen Kriterien (siehe man
systemd.journal-fields), z.B.: _PID (Prozessid), _UID (Benutzer), _EXE (ausführbare Datei) oder
SYSLOG_FACILITY (Nummerischer Wert einer Syslog Facility, siehe Syslog Parameters).
» Einige nützliche Optionen:
•
-b → Einträge seit dem letzten Start
•
-e → zum Ende des Journals springen
•
--since → Einträge seit eines bestimmten Zeitpunkts
•
-u → Einträge einer bestimmten Unit
•
-f → neue Zeilen ausgeben, sobald sie erscheinen.
•
-k → Kernel-Nachrichten des aktuellen Systemstarts (ähnlich wie dmesg)
» $ # Ausgaben nicht dargestellt!
Seite 30 von 139
$ journalctl --since today # Alles von heute
$ journalctl _PID=1 # Alles vom Prozess mit der PID=1
$ journalctl -u cron.service # Alles von der Unit cron.service
Logging - logger
logger - Nachrichten in das Syslog eintragen.
» Dieser Befehl erlaubt es, beliebige Nachrichten in das Syslog einzutragen, was vor allem für ShellSkripte sehr nützlich ist.
» Optionen:
•
-i → PID mitloggen
•
-p → Priorität festlegen (eine Kombination aus Facility und Log-Level, z.B. auth.warn)
•
-t → Tag für die Nachricht festlegen
» $ logger -i -p user.info -t ict-test Ein neuer Eintrag von der Shell...
$ journalctl -n 1 -q
Mär 05 21:11:06 noweto ict-test[20888]: Ein neuer Eintrag von der Shell...
Logging - logrotate
•
Das Programm logrotate wurde entwickelt, um die Administration von Logdateien zu vereinfachen
(trifft natürlich nicht mehr auf das systemd Journal zu).
•
Es wird einmal täglich als Cronjob aufgerufen und kann Logdateien in bestimmten Abständen
(täglich, wöchentlich, monatlich) rotieren, eine bestimmte Anzahl an Logdateien vorhalten, sie
komprimieren und einiges mehr.
•
Die Konfiguration erfolgt über die Datei /etc/logrotate.conf und Dateien im Verzeichnis
/etc/logrotate.d/ (siehe man logrotate).
Beispiel:
/var/log/syslog
{
rotate 7
daily
missingok
notifempty
delaycompress
compress
postrotate
service rsyslog rotate >/dev/null 2>&1 || true
endscript
}
Systemzeit
•
Die Systemzeit unter Linux wird durch die Systemuhr angegeben. Daneben gibt es auch noch die
Hardwareuhr, die durch eine Batterie betrieben wird und daher sogar dann richtig läuft, wenn der
Computer ausgeschalten ist.
•
Beim Starten wird die Systemzeit von der Hardwareuhr gelesen und durch die Systemuhr während
des Betriebs richtig gehalten. Umgekehrt wird beim Beenden die aktuelle Systemzeit in die
Hardwareuhr geschrieben.
Seite 31 von 139
•
Die Hardwareuhr kennt keine Zeitzone, daher muss darauf geachtet werden, dass alle installierten
Betriebssysteme die in der Hardwareuhr gespeicherte Zeit richtig interpretieren. Mac OS X und
Linux benutzen UTC, Windows aber die lokale Zeit!
•
Damit die Systemuhr die richtige Zeit anzeigt, muss zusätzlich die Zeitzone, in der sich der
Computer befindet, eingestellt werden.
•
Deshalb wird schon bei der Installation nach der richtigen Zeitzone und Uhrzeit gefragt.
Links: UbuntuTime, Kapitel im System Administrator‘s Guide, Uhr Mini-Howto, ArchLinux Zeit
Dokumentation, Gentoo Zeit Dokumentation
Systemzeit - Zeitzone
•
Die Zeitzone wird durch die Datei /etc/localtime bestimmt. Das ist ein symbolischer Link auf
eine/eine Kopie einer der vordefinierten Dateien unter /usr/share/zoneinfo.
•
Weiters gibt es die Datei /etc/timezone, in der der Name der verwendeten Zeitzone gespeichert
wird, z.B. Europe/Vienna.
•
Um die Zeitzone einzustellen, gibt es folgende Möglichkeiten (Änderungen werden sofort wirksam):
•
•
Beim Ausführen von dpkg-reconfigure tzdata wird interaktiv die gewünschte Zeitzone über
ein Menü abgefragt.
•
Bei Systemen mit systemd kann der Befehl timedatectl zum Ändern verwendet werden.
•
Manuell durch Ändern der zwei oben genannten Dateien.
In der Datei /etc/default/rcS ist zudem festgelegt, ob die Hardwareuhr UTC verwendet oder nicht.
Systemzeit - date
date - Zeigt die Uhrzeit an oder setzt sie.
» Nicht verwechseln mit dem Befehl time, welcher die Ausführungszeit eines Prozess misst!
» Die Anzeige kann durch Formatsequenzen angepasst werden. Wichtige Formatsequenzen sind %H
(Stunde 00..23), %M (Minute 00..59), %S (Sekunde 00..59), %d (Tag 01..31), %m (Monat 01..12) und
%Y (Jahr).
» Mit der Option -d kann ein beliebiges Datum, nicht nur das aktuelle, formatiert werden.
» $ date
Son Mär 6 08:40:39 CET 2016
$ date +"%Y-%m-%d foo %H:%M:%S"
2016-03-06 foo 08:40:47
$ date -d "9:13 next friday" +"%Y-%m-%d foo %H:%M:%S"
2016-03-11 foo 09:13:00
$ date -s "2016-03-06 11:11:11"
Son Mär 6 11:11:11 CET 2016
Systemzeit - hwclock
hwclock - Liest oder setzt die Hardwareuhr (RTC).
» Nur der Administrator darf dieses Programm verwenden.
» Optionen:
•
--get → die Hardwareuhrzeit anzeigen (angepasst an die lokale Zeitzone)
Seite 32 von 139
•
--set --date=ZEITSTEMPEL → setzt die Hardwareuhr auf den angegebenen Zeitstempel
•
--systohc → die Hardwareuhr an die Systemuhr anpassen
•
--hctosys → die Systemuhr an die Hardwareuhr anpassen
» $ hwclock --get
Fre 11 Mär 2016 19:34:18 CET
.515231 seconds
Systemzeit - timedatectl
timedatectl - Verwaltet die Systemzeit.
» Teil von systemd, verwendet das Service systemd-timedated.service.
» Kann sowohl die Systemuhrzeit anzeigen/setzen als auch die Zeitzone und die Hardwareuhrzeit.
» $ timedatectl
Local time: Son 2016-03-06 11:16:11 CET
Universal time: Son 2016-03-06 10:16:11 UTC
RTC time: Son 2016-03-06 10:16:11
Time zone: Europe/Vienna (CET, +0100)
Network time on: yes
NTP synchronized: yes
RTC in local TZ: no
$ timedatectl set-timezone America/Los_Angeles
$ timedatectl | head -n 1
Local time: Son 2016-03-06 02:18:29 PST
$ timedatectl set-timezone Europe/Vienna
$ timedatectl set-time 08:53
Systemzeit - Zeitserver
•
Da die Systemzeit über Interrupts aktualisiert wird, weicht sie von der echten Uhrzeit mit der Zeit
ab.
•
Damit die Systemzeit trotzdem immer stimmt (für einige Anwendungen wie z.B. Kerberos sehr
wichig), werden Zeitserver und NTP (Network Time Protocol - siehe RFC5905 und ntp.org) benutzt.
•
Zeitserver erlauben es, die lokale Systemuhr über das Internet an die Uhr des Zeitservers
anzupassen. Sprünge in der Zeit werden dabei, wenn möglich, vermieden.
•
Unter Linux wird meist das Programm ntpd zur Synchronisation eingesetzt, bei Verwendung von
systemd aber auch systemd-timesyncd (ist nicht so genau wie ntpd, aber für die meisten Zwecke
ausreichend).
Systemzeit - ntpd, systemd-timesyncd
•
Der Daemon ntpd wird durch die Datei /etc/ntp.conf konfiguriert (siehe man ntp.conf). Die
wichtigste Einstellung ist die Angabe der Zeitserver, die verwendet werden sollen. Falls keine
speziellen Server verwendet werden sollen, muss nichts geändert werden.
ntpd ändert die Zeit nicht abrupt, sondern nur in sehr kleinen Schritten. Damit werden Probleme mit
Programme vermieden, die auf eine sehr genaue Uhrzeit angewiesen sind.
Möchte man ntpd mit Puppet verwalten, so bietet sich das puppetlabs/ntp Modul an.
•
Der Daemon systemd-timesyncd wird durch die Datei /etc/systemd/timesyncd.conf konfiguriert
(siehe man timesyncd.conf). Dabei kann nur die Liste der Zeitserver geändert werden.
Seite 33 von 139
systemd-timesyncd wird automatisch deaktiviert, sobald ein anderer Zeit-Daemon wie ntpd installiert
wird.
Locale
•
Unter Internationalisierung bzw. i18n versteht man das Gestalten von Software in der Art, dass ohne
Quelltextänderungen eine Vielzahl an Sprachen und Kulturen unterstützt werden können.
•
Linux implementiert i18n unter anderem mit Hilfe von Locales. Eine Locale-Bezeichnung besteht
dabei aus
•
einem Sprachecode (z.B. „de“ für Deutsch, „en“ für Englisch) und optional
•
aus einem Ländercode (z.B. „DE“ für Deutschland, „AT“ für Österreich) und
•
einer Kodierung (z.B. „UTF-8“ oder „ISO-8859-1“).
Die drei Teile werde folgendermaßen miteinander verbunden: „de_AT.UTF-8“.
Links: Debian Introduction
ubuntuusers.de
to
i18n,
Ubuntu
Locale
Dokumentation,
Spracheinstellungen
auf
Locale - Umgebungsvariablen
•
Die Locale-Implementierung in der C-Bibliothek benutzt die Umgebungsvariablen LANG bzw. LC_*,
welche eine Locale-Bezeichnung beinhalten müssen, um die Lokalisierung durchzuführen. Dabei
bestimmen die verschiedenen Umgebungsvariablen die verschiedene Aspekte der Lokalisierung,
z.B.:
•
LANG → Standardwert für alle Variablen, die nicht explizit gesetzt wurden
•
LC_NAME → wie werden Namen repräsentiert
•
LC_NUMERIC → wie Nummer formatiert werden sollen
•
LC_TIME → wie Uhrzeit und Datum formatiert werden sollen
Siehe man 7 locale für die gesamte Liste der möglichen LC_* Kategorien.
•
Wird die Variable LC_ALL gesetzt, so haben die einzelnen LC_* Variablen keine Wirkung!
Locale - Konfiguration
•
Bei Ubuntu wird das System-Locale in der Datei /etc/default/locale gesetzt. Darin weist man den
Umgebungsvariablen die gewünschten Werte zu. Benutzer können ihr Locale in der Datei
$HOME/.pam_environment
•
Bei Verwendung von systemd kann das System-Local auch mittels localectl geändert werden.
•
Damit ein Locale funktioniert, müssen die nötigen Dateien dafür vorhanden sein. Bei Installation
eines „language-pack-??“ Pakets (Unterstützung einer bestimmten Sprache, z.B. „language-pack-de“)
wird auch das entsprechende Locale installiert.
Ein Locale kann aber auch durch locale-gen generiert werden, z.B. locale-gen de_AT.UTF-8.
•
Die derzeit aktiven Locale-Werte können mittels des Befehls locale abgefragt werden. Zusätzlich
können damit auch einzelnen Einstellungen oder alle Einstellungen einer Kategorie angezeigt
werden (siehe man 5 locale), z.B.:
Seite 34 von 139
$ locale -k decimal_point
decimal_point=","
Locale - Tastatureinstellungen
•
Durch das Locale bekommt man die richtige Ausgabe, aber auch die Eingabe muss an das Land
angepasst werden.
•
In der Datei /etc/default/keyboard werden die systemweiten Einstellungen für die Tastatur
definiert, sowohl für die virtuellen Konsolen als auch für die GUI (i.e. X11):
•
XKBMODEL → das Tastaturmodell (z.B. „pc105“, „apple“)
•
XKBLAYOUT → das Tastaturlayout (z.B. „us“, „at“)
•
XKBVARIANT → die Layoutvariante (z.B. „altgr-intl“)
•
XKBOPTIONS → zusätzliche Optionen (z.B. „caps:escape“)
Für Informationen zu den Werten siehe man xkeyboard-config.
Wie schon das Locale selbst können auch die Tastatureinstellungen über localectl gesetzt werden.
•
Um geänderten Einstellungen auf einer virtuellen Konsole (tty{1..6}) verwenden zu können, muss
entweder neugestartet oder der Befehl setupcon ausgeführt werden. Dieser aktiviert die Schriftund Tastatureinstellungen (siehe auch man console-setup).
Automatisierung
•
Es ist oft notwendig, Befehle zu einem bestimmten Zeitpunkt in der Zukunft auszuführen (z.B. Server
wegen Wartungsarbeiten in einem bestimmten Zustand versetzen) bzw. regelmäßig auszuführen
(z.B. alte Logdateien löschen).
•
Linux bietet für beide Aufgaben die nötigen Werkzeuge:
•
Regelmäßig auszuführende Jobs werden Cronjobs genannt, nach dem Befehl, der sie ausführt.
Auch hierfür wird ein beim Systemstart ausgeführter Daemon benutzt. Es gibt mehrere
Implementierungen, unter Ubuntu wird zumeist Vixie-cron verwendet (Paket cron).
Zusätzlich gibt es das Programm anacron, welches speziell für Computer, die nicht 24/7 laufen,
gedacht ist und verpasste Jobs beim Booten ausführt.
•
Mit Hilfe von at kann unter Linux ein Job (Sammlung von Befehlen) einmalig zu einem bestimmten
Zeitpunkt ausgeführt werden. Dazu wird beim Systemstart der Dämon atd gestartet, der diese
Aufgabe übernimmt.
•
Sowohl Cronjobs als auch at-Jobs können von normalen (ie. nicht-root) Benutzern genutzt werden.
Links: Cron Howto, Cron auf ubuntuusers.de, crontab.guru, at auf ubuntuusers.de
Automatisierung - Cron 1
•
Die Konfigurationsdateien für Cron befinden sich in
•
/etc/crontab → globale Konfigurationsdatei
•
/etc/cron.d/ → weitere crontab-Konfigurationsdateien
•
/etc/cron.{hourly,daily,weekly,monthly} → Jobs, die in bestimmten Intervallen ausgeführt
Seite 35 von 139
werden sollen
•
/var/spool/cron/crontabs/ → Konfigurationsdateien für Benutzer
•
Editieren kann man die eigene Konfigurationsdateien mittels crontab -e. Die Anzeige der eigenen
Konfigurationsdatei erfolgt mittels crontab -l.
•
Durch Eintragen von Benutzern in /etc/cron.allow bzw. /etc/cron.deny kann die Verwendung von
Cron Benutzern explizit erlaubt bzw. verweigert werden (siehe man 1 crontab).
•
Beispiele für crontab-Einträge:
#
5
#
0
Befehl zur Minute 5 jeder Stunde ausführen
* * * * /bin/bash /path/to/some/script.sh
Befehl um 17 Uhr an jedem Wochentag (Mo-Fr) ausführen
17 * * 1-5 mail -s "Go home!" [email protected]
Automatisierung - cron 2
•
Format für crontab-Dateien (siehe auch man 5 crontab):
*
*
*
*
* auszuführender Befehl
|
|
|
|
|
|
|
|
|
+----- Tag der Woche (0 - 6) (Sonntag ist 0)
|
|
|
+------- Monat (1 - 12)
|
|
+--------- Tag des Monats (1 - 31)
|
+----------- Stunde (0 - 23)
+------------- Minute (0 - 59)
Die Zeitangaben können einzelne Zahlen (12), Bereiche mit optionalen Schrittweiten (1-5/2) oder
Listen (1,3-5,7) sein. Die Angabe von * ist gleichbedeutend mit Anfang-Ende (also der Bereich, der
alles abdeckt).
In der globalen Konfigurationsdatei kommt vor dem Befehl noch der Benutzername, mit dem der
Befehl ausgeführt werden soll.
Automatisierung - at
at - Erlaubt das Ausführen von Jobs zu einem bestimmten Zeitpunkt.
» Syntax: at [Optionen] Zeitangabe
» Die Befehle eines Jobs werden entweder von der Standardeingabe (mit EOF – CTRL+d – beenden)
oder von einer Datei gelesen; und später mittels /bin/sh ausgeführt.
» Die Zeitangabe ist sehr flexibel (z.B. 13:15 tomorrow, 10am Jul 31 2013, now + 1min).
» Optionen: -f Datei → Datei mit Befehlen, -l → anhängende Jobs auflisten, -r Job → Job mittels
Jobnummer löschen, -c Job → Befehls des Jobs ausgeben
» $ at now + 1min
warning: commands will be executed using /bin/sh
at> echo "created file" > created
at> <EOT>
job 3 at Tue Nov 20 12:01:00 2012
$ at -l
3
Tue Nov 20 12:01:00 2012 a thomas
$ ls -l created; sleep 1m; ls -l created
ls: cannot access created: No such file or directory
-rw-rw-r-- 1 thomas thomas 13 Nov 20 12:01 created
Seite 36 von 139
OpenSSH
•
Um sich auf einem anderen Computer einzuloggen, wurde früher telnet verwendet und ab circa
1983 vermehrt rlogin bzw. rsh. Beide Programm haben aber Sicherheitsprobleme und sollten daher
nicht mehr benutzt werden!
•
Im Jahr 1995 wurde die Secure Shell (SSH) entwickelt, um ein sicheres Einloggen auf anderen
Computern zu gewährleisten. Zunächst war das Programm frei, später aber proprietäre Software.
•
Daher wurde ab 1999 ausgehend von einer freien Version des ursprünglichen Programms die
Software OpenSSH entwickelt, die mittlerweile Standard auf Linux- und BSD-Systemen geworden
ist.
•
SSH benutzt ein asymmetrisches Kryptosystem zum Authentifizieren des Servers. Weiters wird der
Datenverkehr zwischen Client und Server symmetrisch verschlüsselt, wobei der Schlüssel über den
Diffie-Hellman-Schlüsseltausch erzeugt wird, und Benutzer können sich entweder mittels
Benutzername und Passwort oder mit Hilfe von Public-Key-Authentifizierung anmelden.
•
OpenSSH aus Clientsicht wurde bereits in der VO „Technische Praxis der Computersysteme 1“ im
Wintersemester behandelt.
OpenSSH - Konfiguration
•
Unter Ubuntu gibt es zwei Pakete: openssh-server (die Serversoftware) und openssh-client (die
Software zum Zugriff auf einen Server).
•
Bei der Installation von openssh-server werden automatisch die benötigten Host-Schlüssel erstellt
und der Server gestartet. Die Default-Konfiguration reicht für Desktopsysteme, bei Servern sollte
man sie eventuell noch ein wenig modifizieren, um optimale Sicherheit gewährleisten zu können
(z.B. Authentifizierung mittels Passwort deaktivieren).
•
Zusätzlich sollte man die automatisch generierten Host-Schlüssel verwerfen, wenn es für den Host
schon Schlüssel gibt, weil sonst bei den Clients eine Meldung über nicht übereinstimmende
Schlüssel auftaucht.
•
Das Konfigurationsverzeichnis für OpenSSH ist /etc/ssh. Darin befindet sich die
Konfigurationsdatei sshd_config für das Serverprogramm und die globale Konfigurationsdatei
ssh_config für das Clientprogramm (siehe man sshd_config und man ssh_config).
OpenSSH - Konfiguration mit Puppet
•
Um OpenSSH (Client und Server) mit Puppet zu verwalten, installiert man das saz/ssh Modul. Hier
betrachten wir nur die Serverkonfiguration.
•
Anschließend kann man den OpenSSH-Server konfigurieren:
class {'ssh::server':
options => {
'PasswordAuthentication' => 'yes',
'PermitRootLogin' => 'no',
'Port' => ['22', '10022'],
}
}
Alle gültigen OpenSSH-Serveroptionen können dabei angegeben werden.
Seite 37 von 139
•
Weiters können auch die Host-Schlüssel verwaltet werden:
ssh::server::host_key {'ssh_host_rsa_key':
private_key_content => 'PRIVATER SCHLÜSSEL', # oder
private_key_source => 'puppet:///MODUL_NAME/ssh_host_rsa_key',
public_key_content => 'ÖFFENTLICHER SCHLÜSSEL', # oder
public_key_source => 'puppet:///MODUL_NAME/ssh_host_rsa_key'.pub,
}
Seite 38 von 139
Foliensatz 3
Datenverwaltung
Inhalt
•
Speichermedien und Partitionen
•
Dateisysteme erstellen und verwalten
•
Verschlüsselung (cryptsetup, LUKS)
•
Logical Volume Manager (LVM)
•
RAID
Speichermedien und Partitionen
•
Jedes Medium (USB-Stick, Festplatte, DVD) ist im Prinzip eine Folge von Bits, die ausgelesen bzw.
geschrieben werden.
•
Um den Zugriff darauf zu vereinfachen und dadurch die Datenübertragung zu beschleunigen, wird
das gesamte Medium meist in Blöcke mit einer fixen Anzahl an Bytes unterteilt. Die Blockgröße ist
bei Festplatten üblicherweise 512 Bytes, seit einigen Jahren auch 4096 Bytes.
•
Ein Medium kann mit einem einzigen Dateisystem versehen sein oder mehrere Teile, Partitionen,
besitzen, mit eventuell unterschiedlichen Dateisystemen.
Das ist z.B. für das Aufteilen eines Systems in eine Betriebssystem-Partition und eine Daten-Partition
nützlich. Es hat zudem den Vorteil, dass beim Einhängen verschiedene Optionen verwendet werden
können.
•
Es gibt unterschiedliche Varianten, Partitionen auf einem physischen Medium zu kennzeichnen.
Früher wurde auf x86-Rechnern ein MBR (Master Boot Record) und die darin enthaltene
Partitionstabelle verwendet, der Nachfolger nennt sich GPT (GUID Partition Table).
Links: Master Boot Record, GUID Partition Table
Master Boot Record (MBR)
•
Der MBR wurde 1983 für IBM-PC XT und DOS 2.0 eingeführt, hat sich allerdings schnell als
Industriestandard etabliert.
•
Die Informationen zum MBR sind innerhalb der ersten 512 Bytes (erster Block) einer Festplatte
gespeichert.
•
Auf Grund von historischen Begebenheiten ist der erste für Partitionen nutzbare Block der Block 63.
Wegen der Erhöhung der Blockgröße auf 4096 Bytes wird derzeit auch oft Block 2048 als Start für
die erste Partition genommen. Der Platz zwischen dem MBR und der ersten Partition wird häufig von
Bootloadern zum Ablegen von Programmcode verwendet (z.B. von GRUB).
•
Die Partitionierung gemäß MBR erlaubt es vier primäre Partitionen anzulegen.
Seite 39 von 139
•
Werden mehr gebraucht, so kann eine primäre Partition als erweiterte Partition markiert werden.
Innerhalb der erweiterten Partition können beliebig viele logische Partitionen angelegt werden.
•
Zusätzlich zur der Partitionstabelle ist auch ein Bootloader (bzw. zumindest ein Teil davon) direkt im
MBR gespeichert (z.B. die Stage 1 von GRUB 2).
MBR - fdisk
fdisk - Manipuliert Partitionstabellen.
» Ursprünglich für MBR-Partitionierung gedacht, unterstützt es mittlerweile auch andere Format,
wie GPT.
» Wird keine Option angegeben, startet fdisk in den Befehlsmodus, mit dem die Partitionstabelle
manipuliert werden kann. Um die Partitionstabelle nur anzuzeigen, wird die Option -l verwendet.
» Ausgabe von fdisk für eine MBR-partitionierte Festplatte:
$ fdisk -l /dev/sda
Disk /dev/sda: 160.0 GB, 160041885696 bytes
255 heads, 63 sectors/track, 19457 cylinders, total 312581808 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x000b57a2
Device Boot
/dev/sda1
*
/dev/sda2
/dev/sda3
/dev/sda5
Start
16065
34668270
43070326
43070328
End
34668269
43054199
312576704
312576704
Blocks
17326102+
4192965
134753189+
134753188+
Id
83
82
f
83
System
Linux
Linux swap / Solaris
W95 Ext'd (LBA)
Linux
GUID Partition Table (GPT) 1
•
Um die Einschränkungen des MBRs loszuwerden, wurde von Intel im Rahmen der Entwicklung von
UEFI auch die GPT entwickelt.
•
Die Vorteile von der GPT gegenüber dem MBR sind:
•
•
Unterstützung von beliebig vielen primären Partitionen (mindestens 128)
•
Unterstützung für Festplatten mit mehr als 2TB Speicher
•
Partitions-ID sind GUIDs (Globally Unique IDentifiers)
•
Bootloader kann bei einer OS-Neuinstallation nicht überschrieben werden, da es direkt im GPT
keinen gibt
•
Redundanz der GPT-Daten durch zwei getrennte GPTs
Das GPT-Schema verwendet LBA (Logical Block Addresses), um Beginn und Ende einer Partition
anzuzeigen. Wie erwähnt, ist ein Block üblicherweise 512 Bytes groß.
Hinweis: Die Grafik zum GPT-Schema stammt von Kbolino und ist CC BY-SA 2.5.
GUID Partition Table (GPT) 2
Seite 40 von 139
•
Um den Übergang von MBR auf GPT zu vereinfachen, wird in LBA 0 der sogenannte Protective
MBR gespeichert. Damit sehen Betriebssysteme, die GPT nicht unterstützen, eine einzige, große
Partition von unbekanntem Typ und verhindern meist die versehentlich Änderung.
•
Die primäre GPT ist ab LBA 1 abgelegt und verwendet mindestens 33 LBAs. Im LBA 1 ist der GPTHeader gespeichert, LBA 2 enthält die Informationen für die ersten vier Partitionen, LBA 3 die
Information für die nächsten vier und so weiter.
•
Am Ende der Festplatte ist die sekundäre GPT gespeichert, die herangezogen wird, falls die primäre
GPT beschädigt ist.
•
Jeder Partitionseintrag ist (üblicherweise) 128 Bytes lang und enthält den Partitionstyp (eine GUID),
eine eindeutige Partitions-GUID, Anfangs- und End-LBA, Attribute und den Partitionsnamen.
GPT - gdisk
gdisk - Manipuliert GUID-Partitionstabellen.
» Wird wie fdisk benutzt und hat eine sehr ähnliche Benutzerschnittstelle.
» Das Programm erlaubt die Konvertierung von MBR in GPT und vice versa.
» Ausgabe von gdisk:
$ gdisk -l /dev/sda | tail -n +9
Found valid GPT with protective MBR; using GPT.
Disk /dev/sda: 1000215216 sectors, 476.9 GiB
Logical sector size: 512 bytes
Disk identifier (GUID): 7DC1C01A-22A6-4216-AA7A-68CE77861CA4
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 1000215182
Partitions will be aligned on 8-sector boundaries
Total free space is 5357 sectors (2.6 MiB)
Number
1
2
3
4
5
Start (sector)
2048
411648
283414528
102813696
200469946
End (sector)
411647
102811647
1000214527
200469945
283413887
Size
200.0 MiB
48.8 GiB
341.8 GiB
46.6 GiB
39.5 GiB
Code
EF00
0700
0700
0700
0700
Name
EFI System Partition
Ein anderes CLI-Programm für die Bearbeitung von Partitionen wäre parted bzw. die GUI-Variante
gparted.
Seite 41 von 139
Dateisysteme
•
Ein Dateisystem kontrolliert, wie Daten auf einem Speichermedium angeordnet werden, damit diese
Daten später wieder gefunden und gelesen werden können.
Wichtige Dateisysteme:
•
Windows: FAT, NTFS
•
Linux/Unix: ext2-4, ReiserFS, XFS, JFS, ZFS, btrfs
•
Netzwerk: NFS, SMB/CIFS (vorrangig Windows), Lustre (Supercomputing)
•
Das gängiste Dateisystem unter Linux ist ext4, welches performant ist und riesige, bis zu 1 EiB
große Partitionen.
•
ZFS, ursprünglich von Sun Microsystems für Solaris entworfen, besitzt wohl von den genannten
Dateisystemen die meisten Funktionalitäten, ist stabil und performant, braucht aber sehr viel RAM
und ist lizenztechnisch nicht mit dem Linux-Kernel kompatibel.
•
Die Zukunft unter Linux wird sehr wahrscheinlich bei btrfs (B-tree FS) liegen, da es ähnliche
Funktionalitäten wie ZFS unterstützt.
Dateisysteme erstellen
•
Für jeden Typ von Dateisystem werden Befehle zum Erstellen bzw. Bearbeiten zur Verfügung
gestellt:
•
Zum Erstellen wird die Familie von mkfs.* Befehlen benutzt.
•
Zum Überprüfen eines Dateisystems wird der entsprechende fsck.* Befehl.
•
Die Namen der zusätzlichen Befehle variieren: Für ext2/3/4 gibt es noch debugfs, dumpe2fs,
tune2fs, resize2fs und ein paar mehr, bei btrfs wird nahezu alles mit dem Befehl btrfs
erledigt.
•
Die Optionen der Programme für das Erstellen bzw. Überprüfen unterscheiden sich natürlich, da die
Dateisysteme unterschiedliche Funktionalitäten besitzen.
•
Für die Erstellung von Swap-Partitionen wird mkswap, da diese kein eigentliches Dateisystem
darstellen.
Dateisysteme erstellen - Beispiel ext4
$ dd if=/dev/null of=dateisystem bs=1M seek=100
$ mkfs.ext4 -L "Mein EXT4-FS" dateisystem
mke2fs 1.42.12 (29-Aug-2014)
Discarding device blocks: done
Creating filesystem with 102400 1k blocks and 25688 inodes
Filesystem UUID: 67787682-7606-44be-ad92-6df6ef4d0aed
Superblock backups stored on blocks:
8193, 24577, 40961, 57345, 73729
Allocating group tables: done
Writing inode tables: done
Creating journal (4096 blocks): done
Seite 42 von 139
Writing superblocks and filesystem accounting information: done
$ file dateisystem
dateisystem:
Linux
rev
1.0
ext4
filesystem
data,
UUID=67787682-7606-44be-ad926df6ef4d0aed,
volume name "Mein EXT4-FS" (extents) (huge files)
$ fsck.ext4 -f dateisystem
e2fsck 1.42.12 (29-Aug-2014)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
dateisystem: 11/25688 files (0.0% non-contiguous), 8896/102400 blocks
Dateisysteme erstellen - Beispiel vfat
$ dd if=/dev/null of=dateisystem bs=1M seek=100
$ mkfs.vfat -n "MEIN USB" dateisystem
mkfs.fat 3.0.28 (2015-05-16
$ file dateisystem
dateisystem: DOS/MBR boot sector, code offset 0x3c+2, OEM-ID "mkfs.fat", sectors/cluster
4,
root entries 512, Media descriptor 0xf8, sectors/FAT 200, sectors/track 32, heads 64,
sectors 204800 (volumes > 32 MB) , serial number 0x9c3ad795, label: "MEIN USB
", FAT
(16 bit)
$ fsck.vfat dateisystem
fsck.fat 3.0.28 (2015-05-16)
dateisystem: 1 files, 0/51091 clusters
Dateisysteme einhängen
•
Die Dateien eines Dateisystems können erst verwendet werden, wenn das Dateisystem in das VFS
eingehängt wurde.
•
Um ein Dateisystem einzuhängen, wird das Gerät, auf dem es liegt (z.B. das DVD-Gerät oder eine
Festplattenpartition) und ein Verzeichnis, in dem die Dateien aufscheinen sollen, benötigt. Falls der
Typ des Dateisystems nicht automatisch erkannt wird, muss auch dieser zusätzlich angeben werden.
•
Bei Linux-Desktopsystemen werden Wechselmedien wie USB-Sticks und -Festplatten sowie DVDs
automatisch erkannt und, falls möglich, unter /media/ eingehängt.
•
Es kann auch ein sogenannter bind-Mount durchgeführt werden. Dabei wird ein Teil der
Verzeichnishierarchie (oder auch nur eine einzige Datei) an einer anderen Stelle zusätzlich zur
Verfügung gestellt. Das wird z.B. für Chroot-Umgebungen oder bei NFSv4 benutzt.
Dateisysteme einhängen - mount, umount
mount - Hängt Dateisysteme in das VFS ein und listet sie auf.
» Ohne Parameter werden die eingebundenen Dateisysteme aufgelistet.
» Optionen: -t → Dateisystemtyp, -o → Mount-Optionen, --bind → einen bind-Mount durchführen
» $ mount | head -n 5
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
Seite 43 von 139
udev
on
/dev
type
devtmpfs
(rw,nosuid,relatime,size=105312k,nr_inodes=26328,mode=755)
devpts
on
/dev/pts
type
devpts
(rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)
tmpfs on /run type tmpfs (rw,nosuid,noexec,relatime,size=24256k,mode=755)
/dev/mapper/ict-root on / type ext4 (rw,relatime,errors=remount-ro,data=ordered)
$ mkdir /mnt/data
$ mount -o ro,noexec /dev/sdb1 /mnt/data
$ mkdir -p /mnt/chroot/proc
$ mount --bind /proc /mnt/chroot/proc
umount - Hängt Dateisysteme aus dem VFS aus.
» Als Parameter sind ein oder mehrere Mountpoints anzugeben.
» Wenn das Dateisystem noch in Verwendung ist, kann es nicht ausgehängt werden! Um
festzustellen, welcher Prozess darauf zugreift, eignet sich lsof.
» $ umount /mnt/data
$ umount /mnt/chroot/proc
Dateisysteme einhängen - /etc/fstab
•
Dateisysteme, die automatisch beim Start eingehängt werden sollen, werden in der Datei
/etc/fstab (siehe man fstab) definiert.
•
Jede nicht kommentierte Zeile besteht aus sechs Feldern und beschreibt, wie und wo ein
Dateisystem mit welchen Optionen eingehängt werden soll:
1. Dateisystem (Pfad zu einer Gerätedatei oder Angabe eines Geräts über eine UUID –
UUID=Gesamte_UUID – oder eine Bezeichnung – LABEL=Dateisystembezeichnung).
2. Mount-Point
3. Dateisystemtyp
4. Einhängeoptionen (siehe man 8 mount)
5. Dump (der dump-Befehl sichert das Dateisystem, wenn der Wert 1 ist)
6. fsck-Durchgangsnummer (Reihenfolge, in der die Dateisysteme beim Starten geprüft werden
sollen; 0 bedeutet „nicht überprüfen“)
•
Beispiel:
/dev/mapper/data
UUID=1499-33B6
/home
/home
/boot/efi
/srv/nfs/home
ext4
vfat
none
defaults,discard
defaults
bind
0
0
1
1
Dateien als Blockgeräte - Loop-Geräte
•
Mit Hilfe eines sogenannten Loop-Gerätes (loop device) ist es möglich, eine normale Datei als
Blockgerätedatei darzustellen.
•
Damit können Dateisysteme, die als Dateien vorliegen, ganz einfach mit mount eingehängt werden
(z.B. ISO-Dateien). Weiters ist diese Funktionalität praktisch zum Testen von Befehlen, die ein oder
mehrere Blockgeräte brauchen.
•
Der Befehl mount kann mittels der Option -o loop direkt normale Dateien einhängen:
Seite 44 von 139
$ mount -o loop ubuntu-15.10.iso /mnt/cdrom
Dabei wird im Hintergrund automatisch ein Loop-Gerät erstellt und benutzt.
Dateien als Blockgeräte - losetup
losetup - Verwaltet Loop-Geräte.
» Optionen: -f → nächstes freies Loop-Gerät anzeigen, -l → alle Loop-Geräte anzeigen, -d
LOOP_DEV → Loop-Gerät entfernen, -D → alle Loop-Geräte entfernen
» Zum Anlegen eines Loop-Geräts: losetup -f [--show] PFAD oder losetup /dev/LOOP_DEV PFAD
» $ dd if=/dev/null of=fakefs bs=1M seek=10 &>/dev/null
$ ls -ls fakefs
0 -rw-r--r-- 1 root root 10485760 Mär 13 13:46 fakefs
$ losetup -f --show fakefs
/dev/loop0
$ mkfs.ext4 -q /dev/loop0 && mount /dev/loop0 /mnt
$ ls -ls fakefs
$ dd if=/dev/zero of=/mnt/file bs=1M count=2 &>/dev/null
$ umount /mnt; losetup -D; ls -ls fakefs
Dateisysteme verschlüsseln
•
Um vor allem bei mobilen Geräten, wie Laptops, Android-basierten Mobiltelefonen und Tablets,
Daten zu schützen, können ganze Dateisysteme verschlüsselt werden. Ubuntu bietet diese
Funktionalität direkt bei der Installation an.
•
Für die Verschlüsselung von Dateisystemen wird das Kernel-Modul dm-crypt und das Programm
cryptsetup verwendet. Das Programm erlaubt auch die Verwendung von LUKS (Linux Unified Key
Setup, ein Standard für Festplattenverschlüsselung).
•
Das Kernel-Modul dm-crypt ist Teil der Device Mapper Infrastruktur des Kernels, die es erlaubt, ein
Blockgerät auf ein anderes Blockgerät abzubilden. Diese Infrastruktur wird nicht nur für die
Verschlüsselung, sondern auch zum Beispiel für LVM (Logical Volume Manager) genutzt.
•
In der Datei /etc/crypttab kann man die Daten der verschlüsselten Dateisysteme eintragen, damit
die entschlüsselten Dateisysteme beim Starten des Systems zur Verfügung gestellt werden können.
Dazu wird, falls nötig, das Passwort auf der (graphischen) Konsole abgefragt.
Links: cryptsetup Homepage, dm-crypt im ArchLinux Wiki, dm-crypt auf Wikipedia
Dateisysteme verschlüsseln - Beispiel
•
Beispiel für die Erstellung eines verschlüsselten ext4-Dateisystems:
$ dd if=/dev/zero of=filesystem count=10000 2>/dev/null
$ cryptsetup luksFormat filesystem
WARNING!
========
This will overwrite data on filesystem irrevocably.
Are you sure? (Type uppercase yes): YES
Enter LUKS passphrase:
Seite 45 von 139
Verify passphrase:
$ cryptsetup luksOpen filesystem encfs
Enter passphrase for /tmp/filesystem:
$ mkfs.ext4 /dev/mapper/encfs &> /dev/null
Logical Volume Manager
•
Der Logical Volume Manager (LVM) erlaubt das Zusammenfassen von mehreren physischen
Festplatten oder Partitionen (physical volumes, PV) zu einem logischen Gesamten (volume group,
VG), welches dann beliebig in logische Partitionen (logical volumes, LV) unterteilt werden kann.
•
Das hat mehrere Vorteile:
•
LVs können größer als ein einzelnes PV sein.
•
Hinzufügen und Entfernen von PVs zu/von einer VG ist möglich.
•
LVs können im Nachhinein leicht vergrößert werden.
•
Es können Snapshots von LVs angelegt werden.
•
Ubuntu erlaubt bei der Installation die Benutzung von LVM, damit man sich z.B. nicht von Anfang an
für bestimmte Partitionsgrößen entscheiden muss.
•
LVM benutzt im Hintergrund die Device Mapper Infrastruktur des Kernels.
•
Zur Verwendung von LVM muss das Paket lvm2 installiert werden.
Links: LVM2 Ressource Page, LVM HOWTO, A Beginner‘s Guide to LVM, LVM auf Wikipedia
Logical Volume Manager - PV
•
Physical Volumes (PV) bieten den eigentlichen Speicherplatz für LVM. PVs können Blockgeräte wie
ganze Festplatten und einzelne Partitionen sein oder aber auch Geräte, die wie Blockgeräte agieren
(z.B. ein Loop-Gerät).
•
Damit ein Blockgerät für LVM verwendet werden kann, muss es initialisiert werden. Dazu wird der
Befehl pvcreate verwendet.
•
Der Befehl pvscan durchsucht alle Blockgeräte nach bereits initialisierten PVs und mit pvdisplay
kann man sich Informationen über ein PV anzeigen lassen.
•
Beispiel (erstellt 5 „Festplatten“ mit 10MiB, initialisiert sie als PVs und zeigt die Informationen
darüber an):
$
>
>
$
for I in loop{1..5}; do
dd if=/dev/zero of=$I bs=1M count=10; losetup /dev/$I $I; pvcreate /dev/$I
done &>/dev/null
pvdisplay # Ausgabe nicht dargestellt!
Logical Volume Manager - VG
•
Eine Volume Group (VG) fasst mehrere PVs zu einer großen Einheit zusammen, die als eine
Festplatte betrachtet werden kann.
•
Beim Erstellen einer VG mittels des Befehls vgcreate kann auch die Größe eines pyhsical extent
(PE) über die Option -s angeben. PEs sind die kleinsten Einheiten einer PV, die von einer VG
Seite 46 von 139
verwaltet werden.
•
VGs können im Nachhinein verändert werden, d.h. man kann später PVs hinzufügen (vgextend) oder
entfernen (vgreduce; natürlich nur, wenn sie nicht benutzt werden). Auch kann man PEs einer PV
auf andere PVs verschieben (pvmove).
•
Beispiel (erstellt die VG „bigdisk“ und zeigt Informationen für sie an; beachte, dass nur 40MiB
benutzbar sind, obwohl alle PVs zusammen circa 48,8MiB zur Verfügung stellen):
$ vgcreate bigdisk /dev/loop{1..5}
Volume group "bigdisk" successfully created
$ vgdisplay bigdisk # Ausgabe nicht dargestellt!
Logical Volume Manager - LV
•
Ein Logical Volume (LV) ist ein Teil einer VG und entspricht einer Partition, d.h. auf einem LV kann
ein Dateisystem angelegt werden.
•
LVs werden mit dem Befehl lvcreate erstellt und beim Erstellen sollte man mittels der Option -n
Name einen sinnvollen Namen angeben. Die Option -L Größe erlaubt das Festlegen der Größe der LV.
•
LVs können auch im Nachhinein verändert werden, d.h. man kann sie vergrößern (lvextend), aber
auch verkleinern (lvreduce). Wichtig: Das zu Grunde liegende Dateisystem muss auch
dementsprechend vergrößert oder verkleinert werden!
Der Befehl lvresize kann sowohl vergrößern als auch verkleinern und gleichzeitig das zu Grunde
liegende Dateisystem verändern.
•
Beispiel (erstellt zwei LVs und erzeugt ext4-Dateisysteme darauf):
$ lvcreate -n root -L 10M bigdisk
Rounding up size to full physical extent 12,00 MiB
Logical volume "root" created
$ lvcreate -n data -L 16M bigdisk
Logical volume "data" created
$ mkfs.ext4 /dev/bigdisk/root; mkfs.ext4 /dev/bigdisk/data
RAID
•
Bei einem RAID (Redundant Array of Independent Disks) werden zwei oder mehr Festplatten zu
einem Verbund zusammengefasst, um den Datendurchsatz und/oder die Ausfallssicherheit zu
erhöhen.
•
Es wichtigsten RAID-Level sind:
•
•
RAID 0 (Striping): Die Daten werden auf zwei oder mehr Festplatten aufgeteilt.
•
RAID 1 (Mirroring): Die Daten werden gespiegelt auf zwei oder mehr Festplatten gespeichert.
•
RAID 5: Die Daten und eine Prüfsumme werden auf drei oder mehr Festplatten aufgeteilt.
Oft werden auch noch folgende RAID-Level benutzt:
•
RAID 6: Wie RAID 5, aber mit zwei Prüfsummen statt einer und verträgt daher den Ausfall von
zwei Festplatten.
•
RAID 10: Eine Kombination von mehreren RAID 1 mit übergeordnetem RAID 0.
Seite 47 von 139
Links: RAID auf Wikipedia, Linux RAID Wiki
Hinweis: Die RAID-Grafiken stammen von Colin M.L. Burnett und sind CC BY-SA 3.0.
RAID 0
•
Bei RAID 0 werden die Daten verteilt auf mindestens zwei Festplatten geschrieben.
•
Die volle Kapazität aller Festplatten kann genutzt werden.
•
Es gibt keine Datensicherheit, fällt auch nur eine Festplatte aus, so sind die Daten verloren.
•
Sowohl das Lesen als auch das Schreiben ist performant, weil alle Festplatten gleichzeitig genutzt
werden können.
RAID 1
•
Bei RAID 1 werden die Daten gespiegelt auf mindestens zwei Festplatten geschrieben.
•
Die Nutzkapazität des RAIDs ist die Kapazität der kleinsten Festplatte im Verbund.
•
Es können alle bis auf eine Festplatte ausfallen, diese Variante bietet daher hohe Ausfallssicherheit.
•
Die Leseperformanz ist hoch, weil von allen Festplatten gleichzeitig verschiedene Teile gelesen
Seite 48 von 139
werden können. Allerdings wird das Schreiben nicht schneller, weil alle Daten auf alle Festplatten
geschrieben werden müssen.
RAID 5
•
Ein RAID 5 braucht mindestens drei Festplatten. Die Daten werden auf n - 1 Festplatten verteilt
geschrieben, auf der übrigen werden Paritätsinformationen gespeichert.
•
Die Nutzkapazität eines RAID 5 mit n gleichen Festplatten beträgt n - 1.
•
Eine Festplatte kann ausfallen, da auf Grund der Paritätsinformationen die Daten einer beliebigen
Festplatte wiederhergestellt werden können.
•
Die Leseperformanz ist hoch, da von allen Festplatten gleichzeitig gelesen werden kann. Allerdings
ist die Schreibperformanz, je nach Implementierung, meist nicht so hoch, weil die
Paritätsinformationen berechnet werden müssen.
Multiple Device Administration
•
Der Kernel bietet Unterstützung für Software RAIDs in Form des MD (Multiple Devices)
Kerneltreibers.
•
Das Programm mdadm (Multiple Device Administration) ist das zugehörige Programm zum
Verwalten dieser Software RAIDs.
•
mdadm erlaubt das Erstellen von RAID-Geräten in mehreren Konfigurationen (z.B. RAID 0, RAID 1
oder RAID 5) und das Verwalten dieser Geräte (z.B. das Entfernen fehlerhafter Festplatten oder das
Hinzufügen von Reservefestplatten).
•
Die Datei /proc/mdstat enthält Informationen zum aktuellen Status:
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
md0 : active raid5 loop5[5](S) loop4[4](S) loop3[3] loop2[1] loop1[0]
18432 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/3] [UUU]
unused devices: <none>
Die erste Zeile gibt Auskunft über die unterstützten Konfigurationen. Danach finden sich
Informationen zum Gerät md0 (aktiv/nicht aktiv, RAID-Level, genutzte Blockgeräte, …).
Seite 49 von 139
mdadm
mdadm - Verwaltet MD Geräte, i.e. Softare RAIDs.
» Besitzt mehrer Ausführungsmodi, z.B. zum Erstellen oder zum Verwalten eines RAIDs.
» Die Manpage zu mdadm gibt detaillierte Auskunft zu den Modi und den vielen Optionen.
» Mit --create kann ein RAID erzeugt werden, --level LEVEL gibt das RAID-Level an und --raid
-devices=N die Anzahl der Geräte.
$ # Erstellung von 5 Blockgeräten zur Nutzung im RAID
$ for I in loop{1..5}; do dd if=/dev/zero of=$I bs=1M count=10; losetup /dev/$I $I
> done &>/dev/null
$ mdadm --create /dev/md0 --level raid5 --raid-devices=3 /dev/loop{1..3}
mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md0 started.
» Nachdem das RAID-Gerät erstellt worden ist, kann es wie jedes andere Blockgerät genutzt
werden. Es scheint dann auch unter /proc/mdstat auf:
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5]
[raid10]
md0 : active raid5 loop5[5](S) loop4[4](S) loop3[3] loop2[1] loop1[0]
18432 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/3] [UUU]
[raid4]
unused devices: <none>
mdadm - Fortsetzung
mdadm - Fortsetzung
» Zusätzliche Blockgeräte kann man mit --add hinzufügen. Diese werden dann als Ersatz für
ausfallende Blockgeräte genutzt (Hot Spares):
$ mdadm /dev/md0 --add /dev/loop{4..5}
mdadm: added /dev/loop4
mdadm: added /dev/loop5
$ mdadm /dev/md0
/dev/md0: 18.00MiB raid5 3 devices, 2 spares. Use mdadm --detail for more detail.
» Mit --stop kann das RAID-Gerät gestoppt werden:
$ mdadm --stop /dev/md0
mdadm: stopped /dev/md0
» Ein zuvor erzeugtes, aber derzeit nicht aktives RAID-Gerät kann über --assemble wieder aktiviert
werden (z.B. nach einem Neustart). Dabei müssen entweder alle Geräte wie beim Erzeugen
angegeben werden oder zusätzlich die Option --scan:
$ mdadm --assemble --scan
mdadm: /dev/md/0 has been started with 3 drives and 2 spares.
$ # oder: mdadm --assemble /dev/md0 /dev/loop{1..5}
mdadm - Fortsetzung
mdadm - Fortsetzung
» Um die RAID-Konfiguration zu speichern, damit sie automatisch beim Booten verwendet werden
kann, wird --detail --scan verwendet, eventuell noch um --verbose erweitert. Die Ausgabe
eignet sich für die Inkludierung in die Konfigurationsdatei /etc/mdadm/mdadm.conf (siehe man
mdadm.conf):
Seite 50 von 139
$ mdadm --detail --scan --verbose
ARRAY /dev/md/0 level=raid5 num-devices=3 metadata=1.2 spares=2
name=noweto:0 UUID=6066dedf:b06a575f:00ec3792:4ac37fa4
devices=/dev/loop1,/dev/loop2,/dev/loop3,/dev/loop4,/dev/loop5
$ mdadm --detail --scan --verbose >> /etc/mdadm/mdadm.conf
» Einzelne Blockgeräte können aus dem RAID mit --remove entfernt werden, wenn sie entweder
Ersatzgeräte oder fehlerhaft sind. Um ein Gerät als fehlerhaft zu markieren, verwendet man
--fail:
$ mdadm /dev/md0 --fail /dev/loop1
mdadm: set /dev/loop1 faulty in /dev/md0
$ mdadm /dev/md0 --remove /dev/loop1
mdadm: hot removed /dev/loop1 from /dev/md0
$ mdadm /dev/md0
/dev/md0: 18.00MiB raid5 3 devices, 1 spare. Use mdadm --detail for more detail.
mdadm - Fortsetzung
mdadm - Fortsetzung
» Mit Hilfe von --grow kann die Anzahl der benutzten Blockgeräte im RAID erhöht werden:
$ mdadm /dev/md0 --grow --raid-devices=4
mdadm: Need to backup 3072K of critical section..
» Zur Anzeige von detaillierten Informationen verwendet man --detail:
$ mdadm --detail /dev/md0 | head -n 9
/dev/md0:
Version : 1.2
Creation Time : Sat Apr 2 10:28:26 2016
Raid Level : raid5
Array Size : 27648 (27.00 MiB 28.31 MB)
Used Dev Size : 9216 (9.00 MiB 9.44 MB)
Raid Devices : 4
Total Devices : 4
Persistence : Superblock is persistent
$ mdadm --detail /dev/md0 | tail -n 5
Number
Major
Minor
RaidDevice State
4
7
4
0
active
1
7
2
1
active
3
7
3
2
active
5
7
5
3
active
sync
sync
sync
sync
/dev/loop4
/dev/loop2
/dev/loop3
/dev/loop5
Kombinieren von RAID und LVM
•
Es ist natürlich möglich, die Funktionalitäten von RAID via mdadm und LVM zu kombinieren:
1. Zusammenfassen mehrerer Festplatten zu einem RAID mittels mdadm
2. Das erstellte MD-Gerät /dev/mdX als PV initialisieren.
3. Eine VG auf dem PV anlegen.
4. In der VG ein oder mehrere LVs anlegen.
Seite 51 von 139
Foliensatz 4
Software und Paketverwaltung
Inhalt
•
Software unter Linux
•
Pakete verwalten mit dpkg
•
Pakete und Repositories verwalten mit apt
•
Paketverwaltung mit Puppet
Software - Geschichtliches
•
Fast alle Softwarepakete, die für Linux verfügbar sind, können gratis benutzt werden (z.B. jede GNU
Software). Alleine bei einer Basisinstallation werden hunderte wichtige Pakete installiert. Ohne
diesen Grundgedanken der freien Software wäre Linux nicht das, was es jetzt ist!
•
Als der Linux Kernel noch sehr jung war (Anfang der 90er Jahre), haben die Softwareentwickler in
der Linux-Community rasch festgestellt, dass es zwar gut ist, frei verfügbare Software zu haben,
aber dass man es den meisten Benutzern nicht zumuten kann, diese selbst zu kompilieren. Neben
dem Kernel braucht man ja noch jede Menge anderer Software (Shell, C-Bibliothek, …), um ein
funktionierendes System zu erhalten.
•
Das Ergebnis war, dass man den Linux-Kernel und die nötige Software im Binärformat in
Softwarepaketen in einer sogenannten Distribution zur Verfügung stellte. Gab es ganz am Anfang
nur sehr primitive Mittel, um den Linux-Kernel und die Software mittels so einer Distributionen zu
installieren, ging die Entwicklung rasch voran und schon 1993 gab es die ersten Distributionen auf
Basis von dpkg (Debian) und rpm (Red Hat).
Software - Aufteilung der Dateien
Unter Linux gibt es eine andere Herangehensweise an Software als unter Microsoft Windows oder Apple
Mac OS X (zumindest bei den meisten Distributionen, eine Ausnahme ist z.B. GoboLinux).
Während in den letzteren zwei Betriebssystem die Dateien einer Applikation zumeist in einem einzigen
Verzeichnis zu finden sind, sind die Dateien einer Applikation unter Linux auf mehrere Verzeichnisse
aufgeteilt:
•
/bin/ → Hier liegen die ausführbaren Dateien, wenn sie für den Systembetrieb wichtig sind.
•
/lib/ → Hier liegen die Systembibliotheken.
•
/usr/bin/ → Hier liegen alle sonstigen ausführbaren Dateien.
•
/usr/lib/ → Hier liegen die benötigten Bibliotheken.
•
/usr/share/APP_NAME/ → Hier liegen Datendateien (z.B. Bilder).
•
/usr/share/doc/PAKET_NAME → Hier findet man die Dokumentation zum Paket.
•
/usr/share/man/ → In diesem Verzeichnisbaum werden die Manpages abgelegt.
•
/sbin/ und /usr/sbin/ → Ausführbare Dateien für den Administrator
Seite 52 von 139
Software - Vergleich mit Windows
•
Unter Windows installieren alle Applikationen alle benötigten Bibliotheken, die nicht auf dem System
installiert sind, entweder in das System- oder das Applikationsverzeichnis.
•
Im Gegensatz dazu wird unter Linux eine Bibliothek nur einmal separat von den Applikationen
installiert (in /usr/lib/) und alle Applikationen können darauf zugreifen. Durch die standardisierten
Bibliotheksnamen und die Verwendung symbolischer Links ist es auch möglich, mehrere Versionen
ein und derselben Bibliothek auf einem System installiert zu haben.
•
Das System von Linux hat mehrere Vorteile:
•
•
Es ist bekannt, wo sich alle Bibliotheken befinden und welche installiert sind.
•
Weniger Speicherplatz wird gebraucht.
•
Bei Sicherheitsproblemen muss man die Bibliothek nur an einer Stelle austauschen.
Das hat aber auch zur Folge, dass man sicherstellen muss, dass alle benötigten Komponenten für
eine Applikation installiert sind. Hier kommt die Softwarepaketverwaltung von Linux ins Spiel.
Softwareverzeichnisse
•
Die meisten Open Source Projekte können nicht wie Firmen durch Marketing auf sich aufmerksam
machen, da das Geld dafür meist nicht vorhanden ist. Viele Entwickler haben nicht einmal selbst
einen Webserver, um die Software zu publizieren.
•
Dadurch gab es schon sehr früh Dienste, die es Entwicklern ermöglichte, Softwareprojekte einfach
durchzuführen. Dazu stellen diese Dienste Webspace, Issue Tracker, Versionskontrollsysteme und
einiges mehr bereit.
•
Das hat nicht nur für die Entwickler Vorteile, sondern auch Anwender haben eine (oder mehrere)
Anlaufstellen, wo sie nach Software suchen können.
•
Einer der ältesten solcher Dienste ist SourceForge. Die Software dahinter kann man selbst kostenlos
verwenden und es gibt einige Webseiten im Stil von Source Forge, die sich auf spezielle Software
beschränken.
•
Andere Dienste sind Github (derzeit der populärste) und Microsoft CodePlex.
Software - Installation ohne Paketmanager 1
•
Nachdem die meiste Software für Linux als Open Source vertrieben wird, kann man üblicherweise
von der Projekthomepage ein gepacktes Archiv herunterladen, das den Quellcode enthält.
•
In diesem Archiv befindet sich oft eine README-Datei mit grundlegenden Informationen zur
Software sowie eine INSTALL-Datei mit einer Installationsanleitung.
•
Muss die Software kompiliert werden, so erfolgt dies meist unter Verwendung des GNU Build
Systems und der GNU Toolchain (i.e. GNU Make, GNU Compiler Collection, Autotools, …). Unter
Ubuntu reicht die Installation des build-essential Pakets, um die benötigte Software zu installieren.
•
Die Vorgehsweise zum Kompilieren und Installieren ist dabei (nahezu) immer die gleiche:
$ configure
$ make
$ make install
Seite 53 von 139
Software - Installation ohne Paketmanager 2
•
Das configure-Skript erfüllt dabei folgende Aufgaben:
•
Überprüfen, auf welchem System das Skript ausgeführt wird und setzen der entsprechenden
Variablen
•
Überprüfen, ob die benötigten Headerdateien und Bibliotheken installiert sind
•
Aktivieren oder deaktivieren von optionalen Komponenten
•
Definieren der Installationsverzeichnisse
•
Um die möglichen Parameter für das configure-Skript anzuzeigen, ruft man es mit der Option
--help auf.
•
Möchte man die Software nicht systemweit installieren (weil man dafür z.B. nicht die benötigten
Rechte besitzt), benutzt man die Option --prefix=PREFIX (z.B. configure --prefix=$HOME/usr).
•
Das Ergebnis des configure-Skripts
Konfigurationsdateien.
•
Die Makefiles enthalten unter anderem Anweisungen, wie die Software kompiliert bzw. installiert
werden soll.
sind
die
Makefiles
und
eventuell
noch
andere
Softwarepaketverwaltung - Allgemeines
•
Einer der wichtigsten Unterschiede zwischen den verschiedenen Linux-Distribution ist diese
Softwarepaketverwaltung.
•
Die Paketverwaltung erlaubt die einfache Installation, Deinstallation und Wartung von
Softwarepaketen, durch z.B. das automatische Auflösen von Abhängigkeiten oder das Verwenden von
Binärpaketen.
•
Die zwei verbreitetsten Paketformate sind deb („Debian package“; von Debian, Ubuntu und anderen
Debian-Derivaten verwendet) und rpm („RPM Package Manager“; z.B. von Red Hat und openSUSE
verwendet). In der Vorlesung werden wir Ubuntu und das deb-Format betrachten und rpm nur
streifen.
•
Die Softwarepakete werden über ein sogenanntes Repository zur Verfügung gestellt, welches
spezifisch für jede Distribution ist. Es umfasst jeden Typ von Software (Kernel, Administration,
Anwendung) und zusätzlich auch Dokumentation sowie Default-Konfigurationen.
•
Das Ubuntu Package Repository bietet einen Überblick über alle Pakete, die man in Ubuntu direkt
über die eingebaute Paketverwaltung installieren kann.
Softwarepaketverwaltung - Pakete
•
Die Softwarepakete unter Ubuntu beinhalten unter anderem folgende Komponenten (genaue
Informationen dazu sind im Debian FAQ zu finden):
•
Programmdateien, Konfigurationsdateien, sonstige Daten
•
Skripte, die bei der (De)Installation benötigt werden
•
Meta-Information (Name, Version, Beschreibung, Abhängigkeiten, …)
•
Signatur (zur Sicherstellung, dass niemand das Paket verändert hat)
Seite 54 von 139
•
Die Pakete enthalten dabei nicht mehr den Quellcode der Software und alles, was zum Kompilieren
benötigt wird, sondern nur mehr die Dateien, die für die Ausführung benötigt werden (es gibt auch
Paketmanager, die am Rechner selbst die Pakete kompilieren, z.B. Portage bei Gentoo).
•
Ein ganz wichtiger Punkt ist, dass zwischen diesen Paketen Abhängigkeiten definiert sind. Das
heißt in der Praxis, dass ein Paket zusätzlich die Anwesenheit von weiteren Paketen benötigen kann.
So wird zum Beispiel sichergestellt, dass bei der Installation eines Audio-Players die nötigen AudioCodecs installiert werden.
Softwarepaketverwaltung - Paketabhängigkeiten
Das Programm apt-rdepends erleichtert die Analyse von Paketabhängigkeiten, z.B. durch das Erstellen
solcher Grafiken.
apt-rdepends -d coreutils | dot -Tpng >coreutils.png
Softwarepaketverwaltung - dpkg vs apt
•
•
Unter Ubuntu gibt es zwei primäre Werkzeuge, die für die Verwaltung von Paketen und Repositories
verwendet werden:
•
dpkg → Dieses Werkzeug arbeitet auf der untersten Ebene, also direkt mit den Paketen. Es wird
benutzt um einzelne Pakete zu installieren, zu entfernen bzw. um allgemein lokale Pakete zu
verwalten.
•
apt → Die Abkürzung für Advanced Packaging Tool bezeichnet eine Familie von Programmen, die
auf dpkg aufbauen und für die eigentliche Paketverwaltung benutzt werden. Es besitzt unter
anderem eingebaute Funktionalitäten zum Verwalten von Repositories, Herunterladen von
Paketen und zum automatischen Installieren von Abhängigkeiten.
Die entsprechenden Pendants bei RedHat Linux wären rpm (zu dpkg) und yum (zu apt).
Seite 55 von 139
Softwarepaketverwaltung - Aufgaben von dpkg
•
•
Auf den ersten Blick scheint die Installation eines Softwarepakets selbst nicht aufwändig zu sein. Es
müssen ja nur Dateien in bestimmte Verzeichnisse kopiert werden. Allerdings reicht das nicht immer
aus:
•
Vor der Installation muss geprüft werden, ob das zu installierende Paket nicht bestehende
Dateien eines anderen Pakets überschreibt.
•
Das Paket darf auch erst dann installiert werden, wenn benötigte, andere Pakete installiert
worden sind.
•
Bei einigen Paketen müssen Aufgaben vor oder nach der Installation durchgeführt werden (z.B.
Starten eines Services oder Anlegen eines Benutzers)
•
Konfigurationsdateien eines Pakets, die seit der Installation geändert worden sind, dürfen bei
einer Aktualisierung des Pakets nicht einfach überschrieben werden.
Weiters muss eine Liste der installierten Pakete geführt werden sowie pro Paket eine Liste der
installierten Dateien (inkl. Berechtigungen und Prüfsummen).
Softwarepaketverwaltung - dpkg
dpkg - Verwaltet deb-Softwarepakete
» Optionen:
•
-i Package.deb → Installiert ein Paket
•
-r Paketname → Entfernt ein Paket, aber nicht dessen Konfigurationsdateien
•
-P Paketname → Entfernt ein Paket inkl. der Konfigurationsdateien
•
-L Paketname → Listet die Dateien des Pakets auf
•
-l → Listet alle installierten Pakete auf
•
-S Pfad → Sucht das Paket, in dem der Pfad vorkommt
» $ dpkg -l | grep dpkg
ii dpkg
1.16.7ubuntu6
ii dpkg-dev
1.16.7ubuntu6
ii libdpkg-perl
1.16.7ubuntu6
$ dpkg -S /usr/bin/dpkg
dpkg: /usr/bin/dpkg
amd64
all
all
Debian package management system
Debian package development tools
Dpkg perl modules
Bei rpm wären die entsprechenden Befehle rpm -i Package.rpm (Paket installieren), rpm -e Paket
(Paket entfernen), rpm -qa (alle Pakete auflisten), rpm -ql (Dateien des Pakets auflisten) und rpm -qf
Pfad (Paket zu Pfad finden).
Softwarepaketverwaltung - Paketintegrität prüfen
Für jede Datei in einem Paket wird ein kryptographischer Hashwert erstellt (ein MD5-Hashwert).
Dadurch kann man später überprüfen, ob eine Datei seit der Installation verändert worden ist.
Falls man ein verändertes Paket findet, kann man dieses mit apt-get install --reinstall Paket neu
installieren.
debsums - Überprüft MD5-Werte von installierten Paketen
» Optionen: -s → Nur Fehler ausgeben, -c → Veränderte Dateien ausgeben.
» $ debsums -s curl
Seite 56 von 139
$ echo test > /usr/bin/curl
$ debsums curl
/usr/bin/curl
/usr/share/doc/curl/MANUAL.gz
/usr/share/doc/curl/TheArtOfHttpScripting.gz
/usr/share/doc/curl/copyright
/usr/share/man/man1/curl.1.gz
$ apt-get install --reinstall curl
...
$ debsums -s curl
$
FAILED
OK
OK
OK
OK
Softwarepaketverwaltung - Aufgaben von apt
•
dpkg kann Pakete installieren, die schon heruntergeladen worden sind, bzw. die bereits installierten
Pakete verwalten. Es bietet aber keine darüber hinausgehenden Möglichkeiten, z.B. Pakete aus dem
Internet für die Installation herunterladen.
•
Hier kommt apt ins Spiel. Während dpkg auf der unteren Ebene arbeitet, ist apt darüber angesiedelt
und bietet Funktionalitäten, die das Arbeiten mit Paketen noch vereinfachen:
•
Automatisches Auflösen von Paketabhängigkeiten und Installation der Pakete in der richtigen
Reihenfolge
•
Installation/Aktualisierung/Deinstallation von Paketen mit Hilfe von Paketnamen (und nicht direkt
über Paketdateien)
•
Verifizieren der Signaturen von Paketen
•
Einfaches Verwalten von mehreren Software-Repositories und der zugeordneter GPG-Schlüssel
•
Automatische Sicherheits-Updates von Paketen
Softwarepaketverwaltung - Repositories
•
Repositories werden über die APT-Familie von Werkzeugen verwaltet. Die Konfigurationsdateien
liegen in /etc/apt/:
•
sources.list → Definiert die Hauptrepositories, die das System verwenden soll (man
sources.list)
•
sources.list.d/*.list → Zusätzliche Repositories
•
apt.conf.d/* → Konfigurationsdateien
•
trusted.gpg → GnuPG Schlüsseldatei
•
Repositories sind über HTTP oder FTP freigegeben Verzeichnisse, die einer bestimmten Struktur
folgen. In dieser Struktur gibt es neben den eigentlichen Paketdateien (mit der Endung .deb) auch
Dateien mit Informationen über alle verfügbaren Pakete des Repositories.
•
Die Liste der Paketdaten eines Repositories wird (ähnlich wie Pakete) mit Hilfe einer Signatur vor
Fälschung geschützt. Die dafür benötigten Schlüssel werden in der oben angegeben Datei verwaltet.
•
Bei yum sind Repositories entweder in /etc/yum.conf oder in Dateien unter /etc/yum.repos.d
definiert.
Seite 57 von 139
Softwarepaketverwaltung - apt-key
apt-key - Verwaltet Repository-Schlüssel
» Verwendet GPG im Hintergrund.
» Befehle: list → Auflisten aller Schlüssel, add Datei → Hinzufügen eines Schlüssel aus einer
Datei, del KeyID → Löschen eines Schlüssels.
» $ apt-key list | head -n 11
/etc/apt/trusted.gpg
-------------------pub
1024D/437D05B5 2004-09-12
uid
Ubuntu Archive Automatic Signing Key <[email protected]>
sub
2048g/79164387 2004-09-12
pub
uid
1024D/FBB75451 2004-12-30
Ubuntu CD Image Automatic Signing Key <[email protected]>
pub
1024D/3E5C1192 2010-09-20
uid
<[email protected]>
Ubuntu
Extras
Archive
Automatic
Signing
Key
Bei rpm/yum werden die GPG-Schlüssel mit rpm verwaltet, z.B. kann man mit rpm --import einen
Schlüssel importieren.
Softwarepaketverwaltung - apt-get
apt-get - APT Paketverwaltungstool
» Bietet extrem viele Unterbefehle und Optionen (und hat sogar Super-Kuh-Fähigkeiten…).
» Die wichtigsten Befehle:
•
update → Paketquellen von Repositories herunterladen und überprüfen, ob Updates vorhanden
sind
•
upgrade → Alle Pakete auf den neuesten Stand bringen (zuvor ein update machen)
•
install Paket... → Installiert die Pakete und eventuell benötigte Abhängigkeiten
•
remove Paket/purge Paket → Entfernen das Paket (und im zweiten Fall auch die
Konfigurationsdateien)
•
autoremove → Alle nicht mehr benötigten Pakete entfernen
Bei yum wären die entsprechenden Befehle yum install (Paket installieren), yum remove (Paket
entfernen) und yum update (alles aktualisieren).
Softwarepaketverwaltung - apt-cache
apt-cache - Durchsucht den APT-Cache
» Nach einem apt-get update liegen die aktuellen Paketindexdateien lokal am Rechner und können
mit Hilfe dieses Programms durchsucht werden.
» Befehle: show → Informationen zu einem Paket anzeigen, search → Mit Hilfe eines Regexps die
Paketquellen durchsuchen
» Bei yum wären die entsprechenden Befehle yum
(Paketinformationen anzeigen).
search (Paket suchen) bzw. yum
info
» $ apt-cache search kramdown
ruby-kramdown - Fast, pure-Ruby Markdown-superset converter
ruby-kramdown-rfc2629 - generate XML2RFC XML from Markdown
$ apt-cache show ruby-kramdown | head -n 11
Seite 58 von 139
Package: ruby-kramdown
Priority: optional
Section: universe/ruby
Installed-Size: 1889
Maintainer: Ubuntu Developers <[email protected]>
Original-Maintainer:
Debian
Ruby
Extras
Maintainers
<[email protected]>
Architecture: all
Version: 1.8.0-1
Depends: ruby | ruby-interpreter, ruby-prawn, ruby-prawn-table, ruby-coderay, rubyrouge (>= 1.8~), ruby-stringex, libjs-jquery
Suggests: libjs-mathjax
Filename: pool/universe/r/ruby-kramdown/ruby-kramdown_1.8.0-1_all.deb
Softwarepaketverwaltung - aptitude
aptitude - APT Paketverwaltungstool
» Vereint unter anderem die Funktionalitäten von apt-cache und apt-get.
» Hat ein paar Vorteile gegenüber apt-get, z.B. werden nicht mehr benötigte Pakete beim Entfernen
eines Pakets automatisch mitentfernt.
» Wird aptitude ohne Parameter aufgerufen, startet eine interaktive Konsolenapplikation zum
Verwalten von Paketen.
»
apt-get update
aptitude update
apt-get upgrade
aptitude safe-ugprade
apt-get install
aptitude install
apt-get install –reinstall
aptitude reinstall
apt-get remove
aptitude remove
apt-get purge
aptitude purge
apt-cache search
aptitude search
apt-cache show
aptitude show
Softwarepaketverwaltung - Präferenzsystem
•
Es kann vorkommen, dass bei einem Systemupdate ein Paket aktualisiert werden soll und man das
vermeiden möchte (z.B. weil etwas nur mit der alten Version funktioniert). Oder dass man Pakete
eines Repositories gegenüber den Paketen eines anderen bevorzugen will.
•
Mit Hilfe des Präferenzsystems von apt kann man solche Aufgabenstellung lösen - siehe man
apt_preferences.
•
Die Präferenzen können in Dateien im Verzeichnis /etc/apt/preferences.d/ festgelegt werden.
•
Um zum Beispiel die aktuellesten Pakete zu installieren, auch wenn sie gerade noch getestet werden
oder instabil sind, kann man folgende Datei verwenden (die Standardpriorität ist 500):
Package: *
Pin: release a=testing
Pin-Priority: 900
Seite 59 von 139
Package: *
Pin: release a=unstable
Pin-Priority: 800
Softwarepaketverwaltung - Automatische Updates
•
Um Sicherheitsupdates automatisch einspielen zu lassen, gibt es mehrere Möglichkeiten (z.B. cronapt und unattended-upgrades).
•
Für die Verwendung von unattended-upgrades das gleichnamige Paket installieren und die
Konfiguration anpassen:
•
Das Programm durch Setzen der folgenden Optionen in /etc/apt/apt.conf.d/10periodic
aktiveren:
APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Unattended-Upgrade "1";
Die erste Option stellt sicher, dass die Repository-Daten aktuell sind und die zweite aktiviert die
automatischen Updates mittels unattended-upgrades.
•
In der Datei /etc/apt/apt.conf.d/50unattended-upgrades sollte man zusätzlich zumindest noch
einstellen, welche Repositories für Updates herangezogen werden sollen, wenn man mit den
Standardeinstellungen nicht zufrieden ist (Option Unattended-Upgrade::Allowed-Origins).
•
Das Programm wird dann regelmäßig durch den Cronjob /etc/cron.daily/apt ausgeführt.
Paketverwaltung mit Puppet
•
Pakete werden in Puppet über die Ressource package verwaltet.
•
Unter Ubuntu wird standardmäßig der Provider apt verwendet, alternativ dazu gäbe es noch
aptitude und dpkg.
•
Wichtige Attribute:
•
name: Der Name des Pakets (falls nicht angegeben, wird der Titel verwendet).
•
ensure: Der gewünschte Zustand (present oder installed, absent, purged, held, latest oder eine
Versionsnummer; falls nicht angegeben wird der Wert installed genommen).
•
responsefile: Eine Datei mit den benötigten Antworten, die von dem Paket abgefragt werden
(zum Beispiel zum Akzeptieren einer Lizenz oder zum Vorkonfigurieren)
Paketverwaltung mit Puppet - Beispiele
•
Installation von OpenSSH-Server und -Client:
package {'openssh-client':
ensure => latest
}
package {'openssh-server': }
•
Sicherstellen, dass das Paket ntp nicht installiert ist:
Seite 60 von 139
package {'ntp':
ensure => purged
}
Verwaltung von APT mit Puppet 1
•
Zur Verwaltung von Quellen, Schlüsseln und Konfigurationsoptionen für APT mit Puppet eignet sich
das puppetlabs/apt Modul.
•
Die Klasse apt muss inkludiert werden, damit die nötigen Ressourcen definiert werden (z.B. für das
Ausführen von apt-get update).
•
Schlüssel verwalten:
apt::key { "CC key":
id => '9E2E7FFB465D2C010F6834FE1985A9276BB7CA7A',
source => "http://cc.mat.univie.ac.at/ubuntu/pub.key",
}
•
Paketquellen verwalten:
apt::source { "cc-mat":
comment => 'CC Repo',
location => "http://cc.mat.univie.ac.at/ubuntu",
release => trusty,
repos => 'contrib',
}
Verwaltung von APT mit Puppet 2
•
Konfigurationsoptionen setzen (entweder direkt mittels content den gesamten Inhalt der Datei oder
über source eine Datei spezifizieren):
apt::conf { 'unattended-upgrade'
content => "APT::Periodic::Unattended-Upgrade \"1\";\n"
priority => 99
}
•
Präferenzen für Pakete festsetzen:
apt::pin {
'testing':
packages => '*',
release => 'testing',
priority => 900;
'unstable':
packages => '*',
release => 'unstable',
priority => 800;
}
Seite 61 von 139
Foliensatz 5
Benutzer- und Gruppenverwaltung
Inhalt
•
Benutzer und Gruppen
•
Name Service Switch (NSS)
•
Lokal definierte Benutzer und Gruppen
•
Pluggable Authentication Modules (PAM)
•
Benutzer- und Gruppenverwaltung mit Puppet
Benutzer und Gruppen
•
•
•
Unter Linux gibt es ein einfaches Benutzer(konto)- bzw. Berechtigungskonzept:
•
Es gibt einen speziellen Benutzer, üblicherweise root genannt, der alles darf.
•
Daneben gibt es noch viele „normale“ Benutzer, die grundsätzlich die gleichen Rechte haben.
•
Ein Benutzer ist immer einer oder mehreren Gruppen zugeordnet, die bestimmte Rechte haben.
Allerdings gibt es eine Vielzahl an Möglichkeiten, wie man bestimmten Benutzern mehr erlauben
kann:
•
durch Zuordnung zu bestimmten Gruppen
•
über den sudo-Befehl
•
durch Zuordnung sogenannter Fähigkeiten (Capabilities; seit Linux 2.2)
Wichtig ist auch immer der Unterschied Authentifikation (Bin ich wirklich der, der ich vorgebe zu
sein?) und Autorisation (Was darf ich?)!
Benutzer/Gruppen - Namen und Nummern
•
Sowohl Benutzer als auch Gruppen werden üblicherweise über einen Namen referenziert.
•
Nachdem aber Computer mit Zahlen besser umgehen können als mit Namen (und Zahlen auch
weniger Speicherplatz brauchen), verwendet der Kernel intern zum Referenzieren von Benutzern
und Gruppen Nummern, die sogenannten UIDs (User IDs) und GIDs (Group IDs).
•
Die Zuordnung von UID zu Benutzer bzw. GID zu Gruppe muss nicht eindeutig sein, sollte es aber.
Ein Grund, warum eine UID mit mehreren Benutzernamen assoziiert wird, ist z.B., um verschiedene
Passwörter verwenden zu können.
Seite 62 von 139
Benutzer/Gruppen - Automatisierierung
Wie generell bei der Systemadministration ist es auch bei der Benutzerverwaltung wichtig, möglichst
alles zu automatisieren:
•
Anlegen von Benutzern (kann in manchen Umgebungen aus vielen Schritten bestehen, z.B. Anlegen
eines Benutzerkontos in einem LDAP-Verzeichnis, Erstellen des Home-Verzeichnisses und eines
Windows-Profil-Verzeichnisses auf einem Dateiserver, Eintragen des Benutzers in Mailing-Listen, …)
•
Löschen von Benutzern (Benutzerkonto und sämtliche Daten löschen; zur Sicherheit ein Backup der
Daten machen)
•
Regelmäßiges Entfernen von „Karteileichen“ aus dem System
Damit können Fehler vermieden und alle Schritte auch ohne Zusatzaufwand dokumentiert werden.
Benutzer - Merkmale
Jedes Benutzerkonto besitzt die folgenden Merkmale:
•
Name: Ein eindeutiger Loginname für den Benutzer.
•
UID (User ID): Eine eindeutige Nummer für den Benutzer (>=0).
•
GID (Group ID): Die Nummer der primären Gruppe des Benutzers.
•
GECOS-Feld: Enthält den realen Namen sowie eventuell zusätzliche Informationen über den
Benutzer (z.B. Raumnummer und Telefonnummer). Der Name stammt von frühen Unix-Maschinen
mit dem Namen GECOS (General Comprehensive Operating System), die dieses Feld für zusätzliche
Informationen nutzten.
•
Home-Verzeichnis: Das Verzeichnis, in dem der Benutzer alle seine Daten abspeichern kann bzw. in
dem seine Konfigurationsdateien liegen (üblicherweise /home/BENUTZER_NAME).
•
Login-Shell: Der Pfad des Programms, das beim Einloggen des Benutzers ausgeführt werden soll.
Benutzer - Details zu den Merkmalen
•
Der Loginname sollte nur aus Kleinbuchstaben, Ziffern und dem Unterstrich bestehen und mit einem
Buchstaben beginnen (siehe CAVEATS in useradd(8)).
•
Die Loginnamen dienen lediglich der Darstellung gegenüber Benutzern des Systems, intern (z.B. auf
Prozess- und Dateisystemebene) werden immer die numerischen Werte (UID, GID) verwendet.
•
Die Anzahl der möglichen UIDs/GIDs seit Linux 2.6 ist 4294967296 (i.e. 2^32).
•
Der spezielle Benutzer root hat immer die UID 0.
•
Das Home-Verzeichnis eines Benutzers muss nicht unbedingt existieren. Als Ersatz wird dann das
Root-Verzeichnis (/) verwendet. Da ein normaler Benutzer nicht die Berechtigung hat, im RootVerzeichnis Dateien anzulegen/zu verändern, funktionieren dann aber einige Anwendungen nicht
richtig (z.B. funktioniert das Einloggen auf der graphischen Oberfläche meist nicht).
•
Die Informationen im GECOS-Feld werden von einigen Applikationen ausgewertet (z.B. vom
Programm finger), sind aber nicht direkt für das System wichtig.
•
Ist keine Login-Shell gesetzt, so wird als Login-Shell /bin/sh verwendet.
Seite 63 von 139
Benutzer - Passwortmerkmale
Zusätzlich zu den allgemeinen Merkmalen kann jedes Benutzerkonto auch Passwortmerkmale enthalten:
•
Passwort in verschlüsselter Form
•
Datum der letzten Passwortänderung
•
Minimales Passwortalter in Tagen
•
Maximales Passwortalter in Tagen
•
Warnzeitraum vor Passwortablauf in Tagen
•
Passwortänderungszeitraum nach Passwortablauf in Tagen
•
Ablaufdatum des Kontos
Benutzer - Details zu den Passwortmerkmalen
•
Die Datumsangaben erfolgen immer als Anzahl der Tage seit 1. Jänner 1970.
•
Keine Angaben zum Datum der letzten Passwortänderung, dem minimalen oder maximalen
Passwortalter, dem Warnzeitraum oder dem Passwortänderungszeitraum bedeuten, dass diese
Funktionalität deaktiviert ist.
•
Das verschlüsselte Passwort kann folgende Werte enthalten:
•
Kein Wert: Der Benutzer kann sich ohne Passwort einloggen. Allerdings kann es sein, dass
manche Applikationen dann den Zugriff vollständig verbieten. D.h. man sollte hier immer etwas
eintragen!
•
Verschlüsseltes Passwort: Erkennt man daran, dass der Wert mit $ID$ anfängt (ID gibt den
Verschlüsselungsalgorithmus an, siehe man 3 crypt).
•
!...: Fängt das Passwort-Feld mit einem Rufzeichen an, so ist das Konto für die
Authentifizierung über das Passwort gesperrt. Andere Authentifizierungsmethoden sind aber
noch erlaubt.
•
Andere Werte (z.B. *) zeigen ein ungültiges Passwort an; der Benutzer kann also nicht mit einem
Passwort einloggen (aber eventuell mit anderen Methoden).
Gruppen
•
Wie Benutzer haben auch Gruppen bestimmte Merkmale:
•
Name: Ein eindeutiger Gruppenname.
•
GID: Eine eindeutige Nummer für die Gruppe.
•
Gruppenmitglieder: Eine Liste der Benutzer, die in dieser Gruppe Mitglied sein sollen.
•
Jeder Benutzer hat eine primäre Gruppe, welche direkt bei den Merkmalen des Benutzers über die
GID angegeben ist.
•
Die primäre Gruppe wird z.B. beim Anlegen von neuen Dateien oder beim Starten von Prozessen
verwendet (jeder Datei/jedem Prozess ist ja sowohl eine UID als auch eine GID zugeordnet, um
Berechtigungen zu prüfen).
•
Zusätzlich kann ein Benutzer Mitglied in beliebig vielen anderen Gruppen sein, das sind dann die
sekundären Gruppen des Benutzers. Temporär kann ein Benutzer mittels des Befehls newgrp seine
primäre Gruppe ändern.
Seite 64 von 139
Allgemeine Befehle - id, groups
id - Zeigt Benutzer- und Gruppeninformationen an.
» Verwendet den aktuellen Benutzer oder den via Parameter angegebenen.
» $ id
uid=1000(praxis) gid=1000(praxis) Gruppen=1000(praxis),4(adm),24(cdrom),27(sudo),
30(dip),46(plugdev),111(lpadmin),112(sambashare)
$ id root
uid=0(root) gid=0(root) Gruppen=0(root)
groups - Zeigt die Gruppen eines Benutzers an.
» Verwendet den aktuellen Benutzer oder die via Parameter angegebenen.
» $ groups
praxis adm cdrom sudo dip plugdev lpadmin sambashare
$ groups root praxis
root : root
praxis : praxis adm cdrom sudo dip plugdev lpadmin sambashare
Name Service Switch (NSS)
•
Der Name Service Switch (NSS) dient dazu, verschiedene Quellen für Namensdatenbanken zu
konfigurieren. Darunter fallen zum Beispiel Datenbanken für Benutzerdaten, Passwortdaten,
Gruppendaten und Host-Namen.
•
Dabei gibt es zwar eine fix definierte Liste an Namensdatenbanken, aber über Bibliotheken können
die Mechanismen zum Abfragen der Daten erweitert werden.
•
Standardmäßig werden als Quellen Dateien im Verzeichnis /etc/ benutzt (über die „files“ bzw.
„compat“ Bibliotheken) bzw. für die Host-Namen auch DNS (über die „dns“ Bibliothek), aber die
Informationen könnten auch aus NIS, LDAP oder einem ActiveDirectory kommen.
•
Eine Auflistung aller möglichen Bibliotheken bekommt man über aptitude search libnss, die
installierten Bibliotheken findet man als Dateien der Form /lib/libnss_NAME.so.X.
NSS - Konfiguration
•
•
Konfiguriert wird der NSS über die Datei /etc/nsswitch.conf. Die Standardkonfiguration auf einem
Ubuntu-Server sieht folgermaßen aus:
passwd:
group:
shadow:
compat
compat
compat
hosts:
networks:
files dns
files
protocols:
services:
ethers:
rpc:
db
db
db
db
netgroup:
nis
files
files
files
files
Die Syntax ist sehr einfach: Pro Zeile wird eine Namensdatenbank konfiguriert, deren Name am
Seite 65 von 139
Anfang steht. Danach kommen die Quellen, aus denen die Daten der Reihe nach gelesen werden
sollen, bis ein Ergebnis gefunden wird.
Zusätzlich könnte man über die Angabe von [STATUS=AKTION] nach einer Quelle die Standardaktion
beeinflussen, also was im Falle des Erfolgs oder eines Fehlers gemacht wird (siehe man
nsswitch.conf).
NSS - getent
getent - Zeigt Datensätze aus einer NSS-Datenbank an.
» Alle über NSS konfigurierbaren Datenbanken können ausgelesen werden, z.B. passwd, group,
hosts, services, protocols und networks.
» Der Befehl ist besonders nützlich, wenn nicht nur lokale (d.h. am System definierte) Daten
vorhanden sind, sondern auch externe Daten (z.B. aus einem LDAP-Verzeichnis).
» $ getent passwd | head -n 3
root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/bin/sh
bin:x:2:2:bin:/bin:/bin/sh
$ getent group root
root:x:0:
$ getent hosts
127.0.0.1
localhost
127.0.1.1
praxis
127.0.0.1
ip6-localhost ip6-loopback
Lokale Benutzer - /etc/passwd
•
Lokale Benutzer werden mittels der Dateien /etc/passwd und /etc/shadow definiert. Diese Dateien
sollten mit vipw editiert werden, um Datenkorruption vorzubeugen.
•
In der Passwortdatei /etc/passwd sind die Merkmale der Benutzerkonten gespeichert. Diese Datei
muss von allen Benutzern gelesen werden können.
Im Gegensatz zu ihrem Namen sollte das Passwort in der Passwortdatei nicht gespeichert werden!
•
Jede Zeile in der Datei beschreibt einen Benutzeraccount, die einzelnen Werte sind mit
Doppelpunkten von einander getrennt.
•
Eine typische Zeile sieht zum Beispiel so aus (man 5 passwd):
root:x:0:0:root:/root:/bin/bash
/
| \ \
\
\
\
Benutzername
|
\ GID GECOS \
Login-Shell
Passwort
UID
Home-Verzeichnis
Lokale Benutzer - Details
•
Alle erwähnten Merkmale eines Benutzerkontos können in /etc/passwd definiert werden.
•
Zusätzlich gibt es auch noch ein Passwort-Feld, welches folgende Werte besitzen darf:
•
Kein Wert: Der gleiche Effekt, wie bei den Details zu den Passwortmerkmalen erwähnt.
•
x: Steht im Passwort-Feld ein kleines „x“, dann bedeutet das, dass das verschlüsselte Passwort in
der Datei /etc/shadow zu finden ist. In diesem Fall muss es eine entsprechende Zeile in dieser
Seite 66 von 139
Datei geben!
•
Jeder andere Wert wird als verschlüsseltes Passwort interpretiert (siehe Details zu den
Passwortmerkmalen).
Lokale Passwörter und Passwortmerkmale - /etc/shadow
•
Da die Passwortdatei /etc/passwd von allen Benutzer gelesen werden können soll, ist es nicht
ratsam, darin die Passwörter zu speichern. Daher gibt es die Möglichkeit, beim Passwort-Feld ein „x“
einzugeben, was für das System bedeutet, dass das eigentlich Passwort in der Shadowdatei
/etc/shadow gespeichert ist.
•
Diese Datei hat die gleiche Syntax wie /etc/passwd, die Felder entsprechen den Passwortmerkmalen
eines Benutzers. Hier wieder eine typische Zeile (siehe auch man 5 shadow):
root:*:15779:0:99999:7: : :
|
| |
|
|
| | | \
|
| |
|
|
| | \ Reserviertes Feld
|
| |
|
|
| \
Ablaufdatum des Kontos
|
| |
|
|
\ Passwortänderungszeitraum nach Passwortablauf (Tage)
|
| |
|
\
Warnzeitraum vor Passwortablauf (Tage)
|
| |
\
Maximales Passwortalter (Tage)
|
| \
Minimales Passwortalter (Tage)
|
\ Datum der letzten Passwortänderung
\
verschlüsseltes Passwort
Benutzername
Benutzerverwaltung - useradd
useradd - Legt ein neues Benutzerkonto an.
» Standardwerte für einige Optionen sind in /etc/default/useradd und /etc/login.defs
hinterlegt.
» Man könnte auch direkt ein verschlüsseltes Passwort angeben (erzeugt z.B. mit mkpasswd), was
aber vermieden werden sollte, weil dieses dann in der Prozessliste aufscheint.
» Optionen:
•
-d Home-Verzeichnis → Home-Verzeichnis
•
-m → Home-Verzeichnis anlegen, Daten von Skeleton-Verzeichnis kopieren
•
-k Verzeichnis → Verzeichnis als Skeleton-Verzeichnis verwenden
•
-g GID → primäre Gruppe (GID oder Name)
•
-G Gruppe[,Gruppe...] → sekundäre Gruppen
•
-e Ablaufdatum → Ablaufdatum des Kontos
•
-s Shell → Login-Shell
» $ useradd -d /home/leitnert -k /etc/skel_lehrer -m -g lehrer leitnert
$ getent passwd leitnert
leitnert:x:1001:1002::/home/leitnert:/bin/sh
Seite 67 von 139
Benutzerverwaltung - usermod
usermod - Modifiziert ein Benutzerkonto.
» Optionen:
•
-L → Benutzerpasswort sperren
•
-U → Benutzerpasswort entsperren
•
-g GID → primäre Gruppe ändern
•
-G Gruppe[,Gruppe...] → sekundäre Gruppen setzen
•
-l NeuerName → Benutzernamen ändern
•
-u UID → UID ändern (Dateien im Home-Verzeichnis bekommen die neue UID automatisch
gesetzt)
•
-s Shell → Login-Shell ändern.
» Aufpassen beim Ändern des Namens und der UID: Der Benutzer sollte nicht eingeloggt sein!
» $ getent passwd leitnert
leitnert:x:1001:1002::/home/leitnert:/bin/sh
$ usermod -s /bin/bash -g adm leitnert
leitnert:x:1001:4::/home/leitnert:/bin/bash
Benutzerverwaltung - userdel
userdel - Löscht ein Benutzerkonto.
» Optionen: -r → lösche das Home-Verzeichnis des Benutzers.
» $ find /home/leitnert
/home/leitnert
$ userdel -r leitnert
$ find /home/leitnert
find: "/home/leitnert": Datei oder Verzeichnis nicht gefunden
Benutzerverwaltung - adduser
adduser - Legt ein neues Benutzerkonto an (benutzerfreundlicher).
» Dieser Befehl funktioniert wie useradd, benutzt aber die Vorgaben in
/etc/adduser.conf und ist auf Konformität mit den Debian-Richtlinien ausgelegt.
der
Datei
» Über die Optionen --shell, --home, --uid, --gecos und --gid können die entsprechenden
Merkmale gesetzt werden.
» $ adduser --shell /bin/zsh thomas
Adding user `thomas' ...
Adding new group `thomas' (1001) ...
Adding new user `thomas' (1001) with group `thomas' ...
Creating home directory `/home/thomas' ...
Copying files from `/etc/skel' ...
Enter new UNIX password:
Retype new UNIX password:
passwd: password updated successfully
Changing the user information for thomas
Enter the new value, or press ENTER for the default
Full Name []:
Room Number []:
Seite 68 von 139
Work Phone []:
Home Phone []:
Other []:
Is the information correct? [Y/n] y
Benutzerverwaltung - deluser
deluser - Löscht ein Benutzerkonto.
» Analog zum Befehl adduser funktioniert dieser Befehl wie userdel, benutzt aber die Vorgaben in
der Datei /etc/deluser.conf.
» Die Option --remove-home entfernt das Home-Verzeichnis, --remove-all-files entfernt alle
Dateien des Benutzers vom System. Mittels --backup kann ein Backup der gelöschten Daten
angelegt werden.
» $ deluser --backup --remove-all-files thomas
Looking for files to backup/remove ...
/usr/sbin/deluser: Cannot handle special file /dev/parport0
[...]
/usr/sbin/deluser: Cannot handle special file /lib/systemd/system/mountnfs.service
Backing up files to be removed to . ...
backup_name = ./thomas.tar
/bin/tar: Removing leading `/' from member names
Removing files ...
Removing user `thomas' ...
Warning: group `thomas' has no more members.
Done.
$ tar tvf thomas.tar.bz2
-rw-r--r-- thomas/thomas
220 2016-04-08 20:33 home/thomas/.bash_logout
-rw-r--r-- thomas/thomas
675 2016-04-08 20:33 home/thomas/.profile
-rw-r--r-- thomas/thomas 3771 2016-04-08 20:33 home/thomas/.bashrc
-rw------- thomas/thomas
56 2016-04-08 20:43 home/thomas/.bash_history
-rw-rw-r-- thomas/thomas
5 2016-04-08 20:43 home/thomas/test
-rw-rw-r-- thomas/thomas
5 2016-04-08 20:43 tmp/data
Benutzerverwaltung - chsh, chfn
chsh - Ändert die Login-Shell.
» Kann ein Benutzer selbst ausführen.
» Die Datei /etc/shells wird konsultiert und nur die darin aufgelisteten Programme kann ein
Benutzer als Login-Shell setzen.
» Vor dem Ändern muss man sich authentifizieren.
chfn - Ändert die Informationen im GECOS-Feld.
» Kann ein Benutzer selbst ausführen.
» Vor dem Ändern muss man sich authentifizieren.
» Was genau der Benutzer ändern darf, ist über den Schlüssel CHFN_RESTRICT in der Datei
/etc/login.defs festgelegt.
Benutzerverwaltung - chage
chage - Ändert Passwortablaufinformation oder zeigt sie an.
» Alle in der Shadowdatei gespeicherter Passwortmerkmale können geändert werden.
» Optionen (Auszug):
•
-d Datum → Ändert das Datum der letzten Passwortänderung
•
-E Datum → Ändert das Ablaufdatum
Seite 69 von 139
•
-l → Zeigt die Passwortablaufinformationen an
» Nur der Administrator kann Änderungen durchführen, unpriviligierte Benutzer können nur die
Option -l verwenden.
» $ chage -l praxis
Last password change
Password expires
Password inactive
Account expires
Minimum number of days between password change
Maximum number of days between password change
Number of days of warning before password expires
$ chage -d 2013-03-01 praxis
$ chage -l praxis | head -n 1
Last password change
:
:
:
:
:
:
:
Mär 17, 2013
never
never
Mär 20, 2013
0
99999
7
: Mär 01, 2013
Befehle für Benutzerverwaltung - passwd
passwd - Ändert das Passwort eines Benutzers.
» Der Administrator kann ohne Wissen des Passworts das Passwort eines Benutzers ändern (sofern
es lokal gespeichert ist). Er muss sich auch nicht an die Passwortrichtlinien halten.
» Ein unpriviligierter Benutzer kann nur sein eigenes Passwort ändern.
» Ähnlich zu chage können auch Passwortablaufinformationen geändert werden.
» $ passwd praxis
Ändern des Passworts für praxis.
(aktuelles) UNIX-Passwort: -->Aktuelles Passwort eingeben<-Geben Sie ein neues UNIX-Passwort ein: -->Kurzes Passwort eingeben<-Geben Sie das neue UNIX-Passwort erneut ein: -->Kurzes Passwort eingeben<-Sie müssen ein längeres Passwort auswählen.
Geben Sie ein neues UNIX-Passwort ein: -->Langes Passwort eingeben<-Geben Sie das neue UNIX-Passwort erneut ein: -->Langes Passwort eingeben<-passwd: password updated successfully
$ passwd -l praxis
passwd: password expiry information changed.
$ passwd -S praxis
praxis L 03/01/2013 0 99999 7 -1
$ passwd -u praxis
passwd: password expiry information changed.
$ passwd -S praxis
praxis P 03/01/2013 0 99999 7 -1
Lokale Gruppen - /etc/group
•
Lokale Gruppen werden mittels der Dateien /etc/group und /etc/gshadow definiert. Diese Dateien
sollten mit vigr editiert werden, um Datenkorruption vorzubeugen.
•
In der Datei /etc/group sind die Gruppen mit ihren Merkmalen gespeichert. Wie in /etc/passwd
wird pro Zeile eine Gruppe definiert.
•
Eine typische Zeile sieht so aus:
adm:x:4:thomas,admin
/
| |
\
Gruppenname
/
\
Liste von Gruppenmitgliedern
Seite 70 von 139
Passwort
•
GID
In der Datei /etc/gshadow könnten verschlüsselte Passwörter für Gruppen gesetzt werden. Es ist
allerdings sehr unüblich, Passwörter für Gruppen zu vergeben.
Gruppenverwaltung - groupadd, groupmod, groupdel
groupadd - Legt eine neue Gruppe an.
» Optionen: -g GID → die GID der Gruppe.
» $ groupadd lehrer
$ getent group lehrer
lehrer:x:1002:
groupmod - Ändert Gruppeninformationen.
» Optionen: -g GID → ändert die GID, -n Name → ändert den Gruppennamen.
» $ groupmod -g 1515 -n teachers lehrer
$ getent group teachers
teachers:x:1515:
groupdel - Löscht eine Gruppe.
» $ groupdel teachers
$ groupdel praxis
groupdel: cannot remove the primary group of user 'praxis'
Analog zu den Befehlen für die Benutzerverwaltung gibt es auch addgroup und delgroup (sind
eigentlich nur Ausführungsvarianten von adduser und deluser).
Authentifikation/Autorisation mit PAM
•
Die Authentifikation (und ein Teil der Autorisation) erfolgt (fast) immer über PAM (Pluggable
Authentication Modules for Linux, siehe auch man 7 pam).
•
Es gibt vier unterschiedliche Bereiche innerhalb vom PAM:
•
account: Methoden zur Überprüfung des Kontos (Ist das Passwort abgelaufen? Darf der
Benutzer auf das Service zugreifen?)
•
auth: Methoden zur Authentifizierung des Benutzer (z.B. über ein Passwort, eine ID-Karte oder
einen Fingerabdruckscanner)
•
password: Methoden zur Änderung der Authentifikation (z.B. ändern des Passworts)
•
session: Methoden, die es erlauben, vor und nach Erteilung des Zugriffs bestimmte Dinge zu tun
(z.B. Loggen, wenn sich ein Benutzer an- bzw. abmeldet)
PAM - Konfiguration
•
Die Konfiguration erfolgt durch Dateien im Verzeichnis /etc/pam.d/. Unter Ubuntu sind die
allgemeinen Einstellungen in den Dateien common-account, common-auth, common-password und
common-session zu finden.
•
Der Name einer Konfigurationsdatei gibt das Service an, von welchem dieses benutzt wird (z.B. wird
/etc/pam.d/sshd vom OpenSSH-Server benutzt).
•
In einer Konfigurationsdatei sind zeilenweise Einträge folgender Form (siehe man pam.conf):
Seite 71 von 139
Bereich
Kontrollanweisung
Modulpfad
Moduloptionen
•
Bereich ist einer der vier genannten Bereiche.
•
Die Kontrollanweisung bestimmt, was bei Erfolg/Fehler gemacht werden soll.
•
Modulpfad ist der Pfad zu dem zu verwendenen Modul, relativ zu /lib/security (z.B.
pam_unix.so).
•
Moduloptionen sind Optionen, die an das Modul übergeben werden.
Zum Beispiel:
auth
auth
[success=1 default=ignore]
requisite
pam_unix.so nullok_secure
pam_deny.so
PAM - Module
•
Eine Liste aller möglichen Module bekommt man über aptitude search libpam. Bei der Installation
von PAM-Authentifizierungs-Modulen werden diese üblicherweise auch automatisch aktiviert.
•
Mit Hilfe von pam-auth-update können aus den installierten Authentifizierungs-Modulen die zu
benutzenden im Nachhinein auch ausgewählt werden.
•
Das Paket libpam-modules stellt viele Standardmodule zur Verfügung, von denen einige über
Dateien im Verzeichnis /etc/security konfiguriert werden.
Die folgenden Module werden häufig benutzt:
•
pam_permit: Erlaubt immer den Zugriff.
•
pam_deny: Verweigert immer den Zugriff.
•
pam_unix: Das Standard-Unix-Modul für die Authentifikation und Autorisation über die
Passwort- und über die Shadowdatei.
•
pam_access: Definiert, welcher Benutzer sich von wo aus einloggen darf (verwendet
/etc/security/access.conf).
PAM - Module - Fortsetzung
•
Fortsetzung:
•
pam_lastlog: Zeigt Informationen zum letzten
/var/log/lastlog (siehe auch Befehl lastlog).
•
pam_env: Setzt oder löscht Umgebungsvariablen, die in /etc/security/pam_env.conf definiert
sind, bzw. kann auch Dateien mit NAME=Wert-Paaren auslesen.
•
pam_group: Weist Benutzern dynamisch Gruppen zu (z.B. nützlich für nicht lokal definiert
Benutzer; verwendet /etc/security/group.conf).
•
pam_limits: Aktiviert Beschränkungen
verwendet /etc/security/limits.conf).
•
pam_time: Definiert, welcher Benutzer sich zu welchen Zeiten anmelden darf (verwendet
/etc/security/time.conf).
•
pam_nologin: Erlaubt nur dem Administrator, sich einzuloggen, wenn die Datei /etc/nologin
in
Bezug
Login
auf
an
und
verwaltet
Systemressourcen
(z.B.
die
Datei
CPU-Zeit;
Seite 72 von 139
oder /var/run/nologin existiert.
•
pam_motd: Zeigt eine „Nachricht des Tages“ beim Einloggen an.
Benutzerverwaltung mit Puppet
•
Benutzer werden in Puppet über die Ressource user verwaltet.
•
Unter Ubuntu wird standardmäßig der Provider useradd verwendet.
•
Wichtige Attribute:
•
name: Der Name des Benutzers (falls nicht angegeben, wird der Titel verwendet).
•
ensure: Der gewünschte Zustand (present, absent, role)
•
allowdupe: Spezifiziert, ob doppelte UIDs erlaubt sind.
•
comment: Beschreibung des Benutzers (i.e. GECOS-Informationen).
•
expiry: Ablaufdatum (absent oder ein Datum im Format YYYY-mm-dd)
•
gid: Die primäre Gruppe (mittels Zahl oder Name).
•
groups: Sekundäre Gruppen (als Namen).
•
home: Das Home-Verzeichnis.
•
password: Das verschlüsselte (!) Passwort.
•
shell: Die Login-Shell.
•
uid: Die UID.
Benutzerverwaltung mit Puppet - Beispiele
•
Anlegen oder Modifizieren eines Benutzers:
user {'test':
ensure => present,
uid => 1234,
gid => 100,
groups => ['adm', 'sudo'],
home => '/home/praxis',
shell => '/bin/bash',
password => '$1$lj/Uyf9q$omFP02phveFcFZ63UF4jt/' # test
}
•
Löschen eines Benutzer:
user {'test': ensure => absent}
Gruppenverwaltung mit Puppet
•
Gruppen werden in Puppet über die Ressource group verwaltet.
•
Unter Ubuntu wird standardmäßig der Provider groupadd verwendet.
•
Wichtige Attribute:
•
name: Der Name der Gruppe (falls nicht angegeben, wird der Titel verwendet).
•
ensure: Der gewünschte Zustand (present oder absent)
Seite 73 von 139
•
allowdupe: Spezifiziert, ob doppelte GIDs erlaubt sind.
•
gid: Die primäre Gruppe (mittels Zahl oder Name).
Gruppenverwaltung mit Puppet - Beispiele
•
Anlegen oder Modifizieren einer Gruppe:
group {'test':
ensure => present,
gid => 1515
}
•
Löschen einer Gruppe:
group {'test': ensure => absent}
Seite 74 von 139
Foliensatz 6
Netzwerkgrundlagen und
-konfiguration
Inhalt
•
Netzwerke
•
TCP/IP-Schichtenmodell
•
Netzwerkkonfiguration
•
DNS und DHCP
•
Netzwerkkonfiguration mit Puppet
Hinweis: Die Grafiken „Ethernetkabel mit RJ45-Stecker“ sowie Ethernetframe stehen unter der CC BYSA 3.0 Lizenz.
Netzwerke
•
Computernetzwerke dienen dem Austausch von Daten zwischen Computern. Die Daten können dabei
über Kabel, Glasfaser, durch elektromagnetische Strahlung, … übertragen werden (es gibt auch
etwas unüblichere Übertragungsmedien - siehe RFC 1149).
•
Eines der ersten großen Netzwerke war das ARPANET, der Vorläufer des heutigen Internets. Die USRegierung (genauer, DARPA) wollte ein dezentrales und fehlertolerantes Netzwerk für die
militärische Forschung schaffen.
•
Anfang der 1970er Jahre wurde von Vint Cerf und Robert Kahn schließlich die Grundlage für das
heutige Internet geschaffen, nämlich die Protokolle TCP und IP, und Anfang der 1980er Jahre löste
dann das neue Internet das alte ARPANET ab.
Links: Wired - Vint Cerf: We Knew What We Were Unleashing on the World, Internet Hall of Fame
Netzwerke - Abkürzungen
•
Wichtige Abkürzungen:
•
Request For Comments (RFC)
Öffentliche Dokumente, die Internetstandards und -protokolle beschreiben. Einmal veröffentlicht,
werden
sie
nicht
mehr
verändert
(siehe
auch
Ubuntu-Pakete
doc-rfc*).
Auf
http://tools.ietf.org/rfc/index findet sich die Lister aller RFCs.
•
Internet Engineering Task Force (IETF)
Organisation, die sich mit der technische Weiterentwicklung des Internet befasst. Gibt die RFCs
heraus.
•
Internet Corporation for Assigned Names and Numbers (ICANN)
Zuständig z.B. für die Vergabe von Namen (z.B. DNS-Namen) und Adressen (z.B. IP-Adressen).
Seite 75 von 139
Derzeit noch unter US-Kontrolle, es gibt aber ein Vorhaben, die zentralen Internetservices unter
internationale Aufsicht zu stellen.
•
Internet Assigned Numbers Authority (IANA)
Abteilung von ICANN, die die Vergabe von Nummern (z.B. Protokollnummern oder PortNummern) und Namen übernimmt.
Logische Karte von ARPANET, März 1977
Netzwerkmodelle
•
Damit Computer über ein Netzwerk kommunizieren können, müssen sie sich auf eine gemeinsame
Sprache einigen, d.h. es müssen Protokolle definiert sein, an die sich alle Beteiligten halten.
•
Das OSI-Modell (Open Systems Interconnection Model) ist ein Referenzmodell für
Netzwerkprotokolle. Es umfasst sieben Schichten und beschreibt, wie Geräte miteinandern
kommunizieren können. Jede dieser Schichten erfüllt eine andere Aufgabe.
•
Im OSI-Modell kommunizieren immer die Instanzen der selben Schicht über ein Protokoll
miteinander, z.B. Schicht 3 auf dem ersten Gerät mit Schicht 3 auf dem zweiten Gerät.
•
Die Daten werden von der obersten Schicht bis zur untersten Schicht auf dem sendenden Gerät
durchgereicht (und ev. mit Meta-Informationen versehen), übertragen und auf der Empfangsseite
von der untersten Schicht bis zur obersten Schicht durchgereicht (wobei die Meta-Informationen
ausgelesen und entfernt werden).
Seite 76 von 139
TCP/IP-Modell
•
Für das Internet wird ein einfacheres Netzwerkmodell verwendet, nämlich das vier Schichten
umfassende TCP/IP-Modell (beschrieben im RFC 1122):
•
Netzzugangsschicht: Beschreibt die physische Kommunikation von Geräten (z.B. über Kabel,
Glasfaser oder Funk)
•
Internetschicht:
Beschreibt
Netzwerkgrenzen hinweg.
•
Transportschicht: Beschreibt Ende-zu-Ende-Verbindungen,
miteinander kommunizieren können.
•
Anwendungsschicht: Umfasst alle Protokolle, die Anwendungen für die Kommunikation
miteinander verwenden.
die
Übermittlung
von
Datenpaketen
also
wie
über
zwei
mehrere
Applikationen
In jeder Schicht können verschiedene Protokolle benutzt werden.
•
Wir betrachten nun das TCP/IP-Modell, da andere Netzwerkmodelle auf Basis des OSI-Modells für
unsere Zwecke nicht relevant sind. Bei den einzelnen Schichten werden wird dann auch die
Implementierung und Verwendung unter Linux betrachten.
Datenverschachtelung bei TCP/IP
•
Wie auch beim OSI-Modell, werden beim TCP/IP-Modell beim Verschicken von Daten diese in ein
Paket verpackt, in der nächsten Schicht wird das gesamte Paket in ein anderes Paket verpackt und
so weiter bis hinunter zur Netzzugangsschicht. Am Zielgerät wird in umgekehrter Reihenfolge
wieder ausgepackt.
•
Beispiel für die Datenverschachtelung:
Netzzugangsschicht (Link Layer)
Seite 77 von 139
•
Die Netzzugangsschicht ist die unterste Schicht im TCP/IP-Modell und für die physische
Übertragung der Daten zuständig. Sie entspricht den Schichten 1 und 2 im OSI-Modell.
•
Die zuständige Hardware in einem Computer ist z.B. die Netzwerkkarte für kabelgebundene
Verbindungen oder die WLAN-Karte für Funkverbindungen.
•
Standardprotokoll für kabelgebundene Datenübertragung ist Ethernet (weitgehend ident zur IEEE
802.3 Norm). Für die Verbindung von Geräten werden bestimmte Kabel (CAT-5/CAT-6) und Stecker
benutzt.
Für die Übertragung von Daten via Funk über ein WLAN wird meist ein Standard aus der IEEE
802.11-Familie benutzt.
Netzzugangsschicht - MAC-Addresse
•
Jedem Netzwerkgerät ist eine eindeutige Nummer zur Identifikation, die MAC-Adresse (Media
Access Control Address), fix zugeordnet. Diese sollte weltweit eindeutig sein, aber es reicht, wenn
sie lokal eindeutig ist.
•
Eine MAC-Adresse besteht aus sechs Bytes, die hexadezimal und mit Doppelpunkten getrennt
geschrieben werden (z.B. 3C:97:0E:79:B8:0A).
•
Die spezielle MAC-Adresse FF:FF:FF:FF:FF:FF heißt Broadcastadresse, Pakete an diese Adresse
werden von allen Geräten im Netzwerk verarbeitet.
•
Ethernet und WLAN unterstützen auch Multicastadressen. Dabei muss das niedrigste Bit des
ersten Bytes der MAC-Addresse 1 sein (z.B. 01:00:5E:XX:XX:XX für IPv4 Multicast). Pakete an solche
Adressen werden nicht von allen, sondern nur von dafür registrierten Geräten verarbeitet.
•
MAC-Adressen können nicht beliebig von Herstellern vergeben werden. Jeder Hersteller bekommt
einen oder mehrere 3-Byte-Prefixe zugeordnet (siehe OUI-Liste der IEEE, z.B. 52:54:00:XX:XX:XX für
QEMU), die restliche drei Bytes kann der Hersteller dann beliebig vergeben.
Seite 78 von 139
•
Ethernet und WLAN verwenden die gleiche Art von MAC-Adressen.
Netzzugangsschicht - Ethernet-Frame
•
Die zu sendenden Daten werden gemeinsam mit den nötigen Informationen (unter anderem die
Quell- und Ziel-MAC-Adresse) in ein Paket (genannt Ethernet-Frame) verpackt und dann über die
physische Verbindung verschickt.
•
Müssen mehr Daten verschickt werden, als in ein Paket passen (bei Ethernet z.B. 1500 Byte), so
müssen mehrere Pakete verschickt werden.
•
Die Technologie VLAN (Virtual Local Area Network) ermöglicht es, mehrere logische Netze über ein
physisches Netz zu betreiben, ohne dass die logischen Netze sich stören.
Siehe auch Ethernet Theory of Operation.
Netzwerkgeräte unter Linux
•
Jedem Netzwerkgerät (auch Netzwerkschnittstelle genannt) unter Linux wird ein Name zugeordnet.
In älteren Linuxsystem werden z.B. die Namen ethX und wlanX benutzt (dabei steht X für eine
Nummer). Dabei gibt es aber das Problem, dass beim Starten die Reihenfolge der Erkennung der
Netzwerkgeräte durch den Kernel die Benennung beeinflusst.
•
Dies wurde später umgangen, indem mittels udev in /etc/udev/rules.d/70-persistent-net.rules
ein fixer Name für ein Gerät basierend auf der MAC eingetragen wurde. Diese Lösung hatte aber
ihre eigenen Probleme, z.B. beim Kopieren von VM-Images.
•
Um eine konsistente Namensgebung zu erreichen, wird daher mittlerweile von udev die Benennung
nach einem vordefinierten Schema organisiert. Ethernetgeräte haben z.B. den Prefix „en“ und
WLAN-Geräte den Prefix „wl“. Danach folgt z.B. „o<index>“, falls es ein On-Board-Gerät ist, wobei
der Index der eindeutige Geräteindex ist.
Netzwerkgeräte unter Linux - Fortsetzung
•
Unabhängig von den physischen Netzwerkgeräten gibt es immer ein sogenanntes Loopback-Gerät
mit dem Namen „lo“. Damit lässt sich ein Netzwerk auch ohne physisches Netzwerkgerät simulieren,
z.B. um lokal Serveranwendungen zu testen.
Dieses Gerät sollte nie deaktiviert werden, weil viele Anwendung von dessen Funktionieren
ausgehen!
•
Mit Hilfe sogenannter TUN- bzw. TAP-Geräte können auch virtuelle Netzwerkgeräte simuliert
werden. Dabei simuliert ein TUN-Gerät ein Point-to-Point-Netzwerkgerät und TAP ein Ethernetgerät.
TUN- bzw. TAP-Geräte werden oft für VPNs (z.B. beim Uni-VPN) oder für Netzwerke virtueller
Seite 79 von 139
Maschinen verwendet.
•
Die Datei /proc/net/dev listet alle verfügbaren Kernel-Netzwerkgeräte auf, inklusive einiger
Statistiken. Und in /proc/net/dev_mcast findet man für jedes Netzwerkgerät die registrierten
Multicastadressen.
Internetschicht (Internet Layer)
•
Die Internetschicht erlaubt den Transport von Paketen über mehrere physischen Netze und
unterschiedliche Netzzugangsschichtprotokolle (z.B. Ethernet und WLAN) hinweg.
•
Es werden dabei keine Garantien abgegeben, ob die Pakete in der richtigen Reihenfolge bzw.
überhaupt am Zielgerät ankommen. D.h. das System arbeitet verbindungslos und versucht nur, die
Pakete von einem Rechner bestmöglich zum anderen Rechner zu transportieren.
•
Ein Gerät, das in zwei oder mehr logischen Netzen hängt, heißt Router. Dieses leitet Pakete von
einem Netz in ein anderes weiter.
•
Das Hauptprotokoll in dieser Schicht ist IP (Internet Protokoll, definiert in RFC 791). Dieses braucht,
so wie das Ethernet-Protokoll, wieder Adressen, die sogenannten IP-Adressen. Jedes Gerät, das über
das Internet mit anderen Geräten kommunizieren will, braucht eine eindeutige IP-Adressen (Notiz
am Rande: Es gibt auch Möglichkeiten, das zu umgehen, z.B. durch NAT bei IPv4).
Internetschicht - IP
•
Es gibt zwei Arten des IP-Protokolls: IPv4 und IPv6. Einer der wichtigsten Unterschiede zwischen
diesen beiden Protokollen ist die Größe des Adressraumes:
•
Bei IPv4 gibt es 2^32 IP-Adressen, also 4.294.967.296!
•
Bei
IPv6
gibt
es
2^128
340.282.366.920.938.463.463.374.607.431.768.211.456!
IP-Adressen,
also
•
IPv4-Adressen werden üblicherweise dezimal in vier Blöcken zu einem Byte geschrieben, z.B.
131.130.16.250. IPv6-Adressen werden hexadezimal in acht Blöcken zu zwei Bytes geschrieben, z.B.
2001:62a:4:2f00::22:250 (genau eine durchgehende Reihe von Blöcken mit Nullen kann durch
zwei Doppelpunkte ersetzt werden).
•
Derzeit wird fast ausschließlich IPv4 verwendet, aber IPv6 nimmt stetig an Bedeutung zu, da immer
mehr Geräte eine IP-Adresse brauchen. Von Vorteil dabei ist, dass IPv6 gleichzeitig zu IPv4 betrieben
werden kann.
Seite 80 von 139
Internetschicht - IPv4
•
In dem Header eines IP-Pakets sind neben Quell- und Zieladresse auch verschiedene andere Felder
vorhanden, z.B. das TTL-Feld (time to live), das angibt, wie viele Zwischenstationen das Paket
passieren darf; oder das Protokoll-Feld, das angibt, welches Protokoll im Datenteil verwendet wird
(siehe auch /etc/protocols für eine Lister der möglichen Protokollnummern).
Internetschicht - IPv4-Netze
•
Früher wurden IPv4-Adressen in Netzklassen (z.B. Klassen A, B und C) eingeteilt. Da diese
Einteilung aber sehr unflexibel ist, kommt heutzutage fast ausschließlich das Classless Inter-Domain
Routing-Verfahren (CIDR, definiert in RFC 1518 und RFC 4632) zum Einsatz.
•
Beim CIDR wird durch die Angabe einer Netzwerkmaske die IP-Adresse in einen Netzwerk- und
einen Hostteil aufgeteilt. Die Netzwerkmaske gibt an, wie viele Bits vom Anfang der IP-Adresse den
Netzpräfix ausmachen.
Beispiel: IP-Adresse 131.130.16.33 und Netzwerkmaske 255.255.252.0 (entspricht 22 Bits), d.h.
das Netzwerk hat die IP-Adressen von 131.130.16.0 bis 131.130.19.255.
•
Diese künstliche Aufteilung der IP-Adresse in einen Netzwerk- und einen Hostteil erlaubt das
einfache Routing von IP-Paketen. Wie man am IP-Header sieht, muss diese Information den
beteiligten Geräten bekannt sein, weil es dafür kein Feld gibt.
Internetschicht - IPv4-Netze - Fortsetzung
•
Jedes IP-Netzwerk hat zwei spezielle Adressen: die Netzwerkadresse (die erste Adresse; im Beispiel
131.130.16.0) und die Broadcastadresse (die letzte Adresse, im Beispiel 131.130.19.255).
Die Netzwerkadresse zusammen mit der Netzwerkmaske bestimmt ein IP-Netzwerk eindeutig. Die
Broadcastadresse kann benutzt werden, um Daten an alle Geräte des Netzes zu schicken.
•
•
Damit ein Gerät Datenpakete an den richtigen Empfänger schicken kann, gibt es sogenannten
Routing-Tabellen:
•
Pakete für das selbe logische Netz werden direkt an den Empfänger zugestellt
•
Pakete für andere Netze werden an einen Router geschickt, der sie weiterleitet
Zusammen bedeutet das, dass man die IP-Adresse, die Netzwerkmaske als auch den Standardrouter
Seite 81 von 139
(Default-Gateway) wissen muss, damit ein Gerät in einem IP-Netzwerk richtig funktioniert.
Internetschicht - IPv4-Netze - Fortsetzung
•
Jede IP-Adresse aus dem Bereich 127.0.0.0/8 kann als Adresse für das Loopback-Gerät verwendet
werden. Üblicherweise verwendet man aber nur 127.0.0.1.
•
Die Netze 10.0.0.0/8, 172.16.0.0/12 und 192.168.0.0/16 sind private Netze. IPs aus diesen
Bereichen werden von Routern nicht in das globale Internet weitergeleitet.
Private Netzwerkadressen werden oft zuhause für WLAN-Netzwerke verwendet bzw. bei NAT.
•
So wie auf der Netzzugangsschicht gibt es auch auf der Internetschicht Multicastadressen. Alle IPAdressen im Bereich 224.0.0.0/4 sind Multicastadressen.
Unter anderem gibt es fixe Multicast-IP-Adressen zum Ansprechenr aller Geräte (224.0.0.1), zum
Ansprechen alle Router (224.0.0.2), für Multicast DNS (mDNS; 224.0.0.251) und für NTP (224.0.1.1).
Netzzugangs-/Internetschicht - ARP
•
Damit man Geräten im selben logischen Netz IP-Pakete schicken kann, muss deren MAC-Adresse
bekannt sein, da diese ja für die Ethernet-Frames auf der Netzzugangsschicht gebraucht werden.
•
Zum Zuordnen von IP- zu MAC-Adressen wird das Address Resolution Protocol (ARP, definiert in
RFC 826) benutzt. Das Protokoll gehört technisch gesehen zur Netzzugangsschicht.
IPv6 verwendet nicht ARP, sondern das Neighbor Discovery Protocol (NDP).
•
Ist für eine bestimmte IP-Adresse im gleichen Netz die MAC-Adresse noch nicht bekannt, so wird ein
ARP-Request mit der Bitte um Bekanntgabe der zur IP-Adresse gehörigen MAC-Adresse an die
Broadcastadresse der Netzzugangsschicht gesendet. Das Gerät mit der zugehörigen IP-Adresse
antwortet mit einem ARP-Reply, der die Zuordnung MAC-Adresse zu IP-Adresse enthält, direkt an die
MAC-Adresse des ersten Geräts.
•
Diese Zuordnungen von IP- zu MAC-Adressen werden üblicherweise lokal in einem ARP- bzw.
Neighborhood-Cache gespeichert. Der ARP-Cache kann über die Datei /proc/net/arp angezeigt
werden.
Internetschicht - ICMP
•
Das Internet Control Message Protocol (ICMP, definiert in RFC 792) dient zum Austausch von
Informationen und Fehlermeldungen. Es gehört zur Internetschicht und ist Bestandteil von IPv4,
benutzt aber IP zur Datenübertragung (d.h. es repräsentiert sich selbst als Protokoll einer höheren
Schicht).
•
Eine typische Verwendung von ICMP ist das Pingen von Geräten um herauszufinden, ob ein
bestimmtes Gerät verfügbar ist und wie groß die Paketumlaufzeit (round trip time, RTT) ist. Dazu
werden ICMP-Pakete vom Typ Echo Request bzw. Echo Reply und das TTL-Feld des IP-Headers
benutzt.
•
Eine weitere, für Benutzer nützliche Anwendung von ICMP ist Traceroute, mit der man den Weg
eines Pakets durch das Internet nachvollziehen kann.
Seite 82 von 139
•
Bei einem Ubuntu-Desktop-System wird für die Konfiguration der Netzwerkgeräte das Programm
NetworkManager verwendet. Dieses erlaubt eine einfache Konfiguration über die CLI oder GUI und
ist mittlerweile schon tief in verschiedene Desktop-Umgebungen wie Gnome oder KDE eingebunden.
Für die CLI gibt es z.B. den Befehl nmcli (zur Kontrolle des NetworkManager-Daemons).
•
Auf
jedem
Ubuntu-System
kann
die
auch
über
die
Datei
/etc/network/interfaces vorgenommen. Aus mehreren Gründen (z.B. Sicherheit, statische
Konfiguraion) wird der NetworkManager z.B. auf Servern nicht verwendet.
•
Wir betrachten nur die manuelle Konfiguration bzw. die Konfiguration über die Konfigurationsdatei.
Konfiguration - Manuell via ip
•
Der Befehl ip kann nicht nur Netzwerkschnittstellen konfigurieren, sondern auch die Routing- sowie
die ARP-Tabellen manipulieren und noch einiges mehr.
•
Wir werden die folgenden Unterbefehle genauer betrachten und wie man damit eine Schnittstelle
von Hand konfiguriert:
•
•
ip link konfiguriert die Schnittstellen selbst.
•
ip address konfiguriert IP-Adressen für Schnittstellen.
•
ip route manipuliert die Routing-Tabellen.
•
ip neighbour verwaltet den ARP (und für IPv6 den Neighbourhood)-Cache.
Hinweise:
•
Viele Unterbefehl können abgekürzt werden, z.B. reicht ip l statt ip link.
•
Die globale Option -c aktiviert die Farbausgabe.
•
Einige Unterbefehle zeigen unterschiedliche Informationen
Protokollfamilie mit der Option -f FAMILIE gewählt wurde.
an,
je
nachdem,
welche
Links: Vergleich von ifconfig und ip, iproute2 auf Wikipedia, IPRoute Howto, Linux Advanced Routing &
Traffic Control HOWTO, Deprecated Linux networking commands and their replacements.
Konfiguration - ip link
ip link - Konfiguriert Netzwerkschnittstellen.
» Dieser Befehl kann virtuelle Schnittstellen anlegen und bestehende konfigurieren.
» Mit Hilfe des Unterbefehls set dev GERÄT [up|down] kann eine Schnittstelle (de)aktiviert
werden.
Nur über eine aktivierte Schnittstelle können Paket verschickt bzw. empfangen werden.
» Der Unterbefehl show zeigt die Schnittstellen inklusive zusätzlicher Informationen (z.B. der MACAdresse) an.
» $ ip link set dev eth0 up
$ ip link # Äquivalent zu: ip link show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT
group default
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode
Seite 83 von 139
DEFAULT group default qlen 1000
link/ether 52:54:00:12:34:56 brd ff:ff:ff:ff:ff:ff
Konfiguration - ip address
ip address - Konfiguriert IP-Addressen einer Schnittstelle.
» Der Unterbefehl add ADRESSE/PRÄFIX dev GERÄT fügt eine IP-Adresse in CIDR-Notation zur
Schnittstelle hinzu. Zusätzlich wird eine Route generiert, die angibt, dass IP-Adressen aus dem
angegebenen IP-Netzwerk direkt über das angegebene Gerät erreichbar sind.
Verwendet man „del“ statt „add“ wird die entsprechende IP-Adresse und Route gelöscht.
» Der Unterbefehl show zeigt alle Schnittstellen inklusive ihrer Adressen an.
» $ ip address add 10.10.10.101/24 dev eth0
$ ip address # Äquivalent zu: ip address show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group
default qlen 1000
link/ether 52:54:00:12:34:56 brd ff:ff:ff:ff:ff:ff
inet 10.10.10.101/24 scope global eth0
inet6 fe80::5054:ff:fe12:3456/64 scope link
Konfiguration - ip route
ip route - Manipuliert die Routing-Tabellen
» Der Unterbefehl add [ADRESSE/PRÄFIX | default] [via ADRESSE] [dev GERÄT] fügt eine neue
Route hinzu. Man gibt entweder die Adresse in CIDR-Notation an oder benutzt „default“ für die
Standardroute. Sollen Pakete über einen Router geleitet werden, wird die „via“ Anweisung
verwendet.
Verwendet man „del“ statt „add“ wird die entsprechende Route gelöscht.
» Der Unterbefehl show zeigt die Einträge der Routing-Tabellen an.
» $ ip route add default via 10.10.10.1
$ ip route # Äquivalent zu: ip route show
default via 10.10.10.1 dev eth0
10.10.10.0/24 dev eth0 proto kernel scope link
src 10.10.10.101
Konfiguration - ip neighbour
ip neighbour - Verwaltet den ARP (und für IPv6 den Neighbourhood)-Cache.
» Der Unterbefehl add ADRESSE lladdr LLADRESSE dev GERÄT fügt einen neuen IP-zu-MAC-Eintrag
in den Cache ein.
» Der Unterbefehl del ADRESSE löscht einen Eintrag aus dem Cache.
» Der Unterbefehl show zeigt alle Einträge des Caches an.
» $ ip neighbour # Äquivalent zu: ip neighbour show
$ ping -c 1 10.10.10.1 &>/dev/null
Seite 84 von 139
$ ip neighbour
10.10.10.1 dev eth0 lladdr 46:2e:38:61:0f:35 REACHABLE
Konfiguration - ifconfig
ifconfig - Konfiguriert eine Netzwerkschnittstelle.
» Wird benutzt, um Netzwerkschnittstellen zu (de)aktivieren und IP-Address-Konfigurationen
zuzuweisen bzw. um die aktuelle Konfiguration anzuzeigen.
» Option -a zeigt alle Schnittstellen (auch deaktivierte) an.
» $ ifconfig eth0 up 10.10.10.101/24
$ ifconfig eth0
eth0
Link encap:Ethernet HWaddr 52:54:00:12:34:56
inet addr:10.10.10.101 Bcast:10.10.10.255 Mask:255.255.255.0
inet6 addr: fe80::5054:ff:fe12:3456/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:34680 errors:0 dropped:0 overruns:0 frame:0
TX packets:24889 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:19349325 (19.3 MB) TX bytes:3917637 (3.9 MB)
Konfiguration - route
route - Zeigt/Ändert die Routing-Tabelle.
» Wird üblicherweise nach ifconfig benutzt, um eine statische Route für einen Host/ein Netzwerk
anzulegen (z.B. um das Default-Gateway einzutragen).
» Optionen: -n → keine Namensauflösung von IP-Adressen, -net → Route für ein Netzwerk statt
einem Host anlegen.
» Für das Löschen einer Route del statt add verwenden.
» $ # Anlegen einer Netzwerk-Route
$ route add -net 10.10.10.0 netmask 255.255.255.0 dev
$ # Anlegen der Route für das Default-Gateway
$ route add default gw 10.10.10.1
$ route
Kernel IP routing table
Destination
Gateway
Genmask
Flags
default
10.10.10.1
0.0.0.0
UG
10.10.10.0
*
255.255.255.0
U
eth0
Metric Ref
0
0
0
0
Use Iface
0 eth0
0 eth0
Konfiguration - arp
arp - Manipuliert den ARP-Cache.
» Wird hauptsächlich für die Anzeige des ARP-Caches benutzt, man kann aber auch gespeicherte
Zuordnungen löschen bzw. neue hinzufügen.
» $ arp -i eth0 -s 10.10.10.1 46:2e:38:61:0f:35 # Hinzufügen eines Eintrags
$ arp
Address
HWtype HWaddress
Flags Mask
10.10.10.1
ether
46:2e:38:61:0f:35
CM
$ arp -i eth0 -d 10.10.10.1 # Entfernen eines Eintrags
$ arp
Address
HWtype HWaddress
Flags Mask
10.10.10.1
(incomplete)
Iface
eth0
Iface
eth0
Seite 85 von 139
Konfiguration - /etc/network/interfaces
•
Man kann über die Datei /etc/network/interfaces die vorhandenen Netzwerkschnittstellen
entweder statisch oder über DHCP konfigurieren und auch festlegen, ob Schnittstellen automatisch
beim Booten aktiviert werden sollen.
•
Weiters können auch virtuelle Geräte (z.B. TAP-Geräte) damit erstellt und konfiguriert werden und
zusätzliche Informationen, wie z.B. die zu nutzenden DNS-Server, hinterlegt werden.
•
Die Befehle ifup und ifdown nutzen die Information aus der Datei, um Netzwerkschnittstellen zu
aktivieren und konfigurieren oder um sie zu deaktivieren. Weiters können mit ifquery die
Informationen zu einer oder mehreren konfigurierten Schnittstellen ausgegeben werden.
•
Ausführliche Informationen zur Syntax und zu den möglichen Anweisungen findet man in man 5
interfaces.
Konfiguration - /etc/network/interfaces Beispiel
source /etc/network/interfaces.d/*
auto lo
iface lo inet loopback
auto eno1
iface eno1 inet static
address 131.130.61.5
netmask 255.255.255.240
network 131.130.61.0
broadcast 131.130.61.15
gateway 131.130.61.1
•
Die Anweisung „source“ erlaubt das Einbinden anderer Schnittstellendateien.
•
Die Anweisung „auto“ gefolgt von Schnittstellennamen bewirkt, dass diese Geräte in der
angegebenen Reihenfolge automatisch beim Starten aktiviert werden.
•
Die Konfiguration einer Schnittstelle erfolgt mittels der „iface“ Anweisung, gefolgt vom
Schnittstellennamen und „inet“ für IPv4 (bzw. „inet6“ für IPv6). Danach steht die Art der
Konfiguration: „loopback“ für das Loopback-Gerät, „static“ für eine statische Konfiguration, „dhcp“
für eine Konfiguration via DHCP bzw. „manual“ für eine manuelle Konfiguration.
Konfiguration - ifup/ifdown/ifquery
ifup/ifdown/ifquery - Verwalte eine konfigurierte Netzwerkschnittstelle.
» Es ist nur ein Programm mit drei Aufrufvarianten:
•
Als ifup werden Netzwerkschnittstellen aktiviert.
•
Als ifdown werden Netzwerkschnittstellen deaktiviert.
•
Als ifquery werden die Informationen aus den Konfigurationsdatein ausgelesen.
» In der Datei /run/network/ifstate ist der aktuelle Zustand gespeichert.
» Optionen: -a → alle als „auto“ markierte Schnittstellen verwenden, --force → Durchführung
erzwingen, -v → Befehle anzeigen, die ausgeführt werden, --list → bei ifquery alle Schnittstellen
auflisten, --state → bei ifquery den Status der Schnittstellen anzeigen.
Seite 86 von 139
» $ ifup -a # alle Netzwerkschnittstellen aktivieren
$ ifquery --state
lo=lo
eth0=eth0
$ ifquery eth0
address: 10.10.10.101
netmask: 255.255.255.0
gateway: 10.10.10.1
broadcast: 10.10.10.255
Konfiguration - Zusammenfassung
•
Um eine Netzwerkschnittstelle manuell zu konfigurieren müssen also folgende Schritte durchgeführt
werden:
•
Aktivieren der Schnittstelle (mit ip link oder ifconfig)
•
Hinzufügen der IP-Adresse (mit ip address oder ifconfig)
•
Eventuell Hinzufügen eines Default-Gateways (mit ip route oder route)
•
Oder man fügt die entsprechenden Werte in /etc/network/interfaces ein und benutzt ifup.
•
Oder man benutzt ein Hilfsprogramm wie NetworkManager und dessen CLI- oder GUISchnittstellen.
•
Hinweis: Bei manchen Schnittstellen müssen noch zusätzliche Schritte durchgeführt werden, z.B.
Verbinden mit dem WLAN-Netzwerk bei einer WLAN-Schnittstelle.
Internetschicht - Befehle: arping
arping - Schickt ARP-Requests an einen Host.
» Nützlich, um die MAC-Adresse für eine bestimmte IP-Adresse herauszufinden.
» $ arping -c 1 10.10.10.1
ARPING 10.10.10.1 from 10.10.10.101 eth0
Unicast reply from 10.10.10.1 [46:2E:38:61:0F:35]
Sent 1 probes (1 broadcast(s))
Received 1 response(s)
0.615ms
Internetschicht - Befehle: ping
ping - Schickt einen Ping (ICMP-Echo-Request) an einen Host.
» Zum Testen, ob ein bestimmter Host erreichbar ist. Achtung: Manche Hosts sind aus
Sicherheitsgründen so konfiguriert, dass sie nicht antworten!
» Optionen: -c ANZAHL → Anzahl der zu sendenden Pakete, -b → Ping an Broadcastadresse erlauben,
-I SCHNITTSTELLE → Netzwerkschnittstelle auswählen, -s GRÖSSE → Paketgröße festlegen, -M do
→ Fragmentierung verbieten
» $ ping -c 1 www.orf.at
PING www.orf.at (194.232.104.139) 56(84) bytes of data.
64 bytes from orf.at (194.232.104.139): icmp_req=1 ttl=56 time=1.19 ms
--- www.orf.at ping statistics --1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 1.195/1.195/1.195/0.000 ms
$ ping -c 1 -M do -s 1800 orf.at
Seite 87 von 139
PING orf.at (194.232.104.141) 1800(1828) bytes of data.
ping: local error: Message too long, mtu=1500
--- orf.at ping statistics --1 packets transmitted, 0 received, +1 errors, 100% packet loss, time 0ms
Internetschicht - Befehle: traceroute
traceroute - Zeigt die Route eines Pakets zu einem Host an.
» Kann neben ICMP-Echo-Requests auch andere Methoden verwenden (z.B. TCP und UDP).
» Optionen: -I → ICMP-Methode, -T → TCP-Method, -U → UDP-Methode.
» $ traceroute www.google.com
traceroute to www.google.com (173.194.44.244), 30 hops max, 60 byte packets
1 selene.cc.univie.ac.at (131.130.254.145) 1.499 ms 1.522 ms 1.480 ms
2 hekate.cc.univie.ac.at (131.130.254.37) 1.486 ms 1.459 ms 1.724 ms
3 ares.cc.univie.ac.at (131.130.253.113) 1.434 ms 1.399 ms 1.707 ms
4 vlan1501.wien1.aco.net (193.171.13.1) 1.365 ms * 1.659 ms
5 * * *
6 * * *
7 * * *
8 nixcz.net.google.com (91.210.16.211) 7.347 ms 7.313 ms 7.309 ms
9 209.85.241.79 (209.85.241.79) 7.607 ms 7.863 ms 7.520 ms
10 173.194.44.244 (173.194.44.244) 7.086 ms 7.106 ms 7.097 ms
$ traceroute6 www.google.com 2>/dev/null | tail -n 1
15 bk-in-x93.1e100.net (2a00:1450:4008:c01::93) 29.472 ms 29.337 ms 29.492 ms
Internetschicht - Befehle: mtr
mtr - Kombiniert die Funktionalität von ping und traceroute.
» Im Standardmodus zeigt mtr die Route zum Ziel an und aktualisiert laufend die Einträge.
» Optionen: -c ANZAHL → Anzahl der zu sendenden Pakete, -r → Reportmodus, -n → keine
Namensauflösung, -u → UDP-Methode, -T → TCP-Methode
» $ mtr -r orf.at
Start: Sun Apr 10 12:55:19 2016
HOST: ict
1.|-- minerva.cc.univie.ac.at
2.|-- vlan742.wien21.aco.net
3.|-- vlan71.wien1.aco.net
4.|-- 2001:628:1100:4::2
5.|-- 2001:628:1100:1015::2
6.|-- rou-vie-pe-101.apa.net
7.|-- c65-rz1-1.apa.net
8.|-- 2a01:468:1000:9::150
Loss%
0.0%
0.0%
0.0%
0.0%
0.0%
0.0%
0.0%
0.0%
Snt
10
10
10
10
10
10
10
10
Last
4.1
0.9
20.4
1.2
1.7
141.8
1.2
1.2
Avg
2.0
1.5
9.4
10.9
2.0
15.3
2.2
15.3
Best Wrst StDev
1.3
4.1
0.7
0.9
6.1
1.6
1.1 64.0 20.1
1.2 98.2 30.7
1.7
4.1
0.7
1.2 141.8 44.4
1.2 10.9
3.0
1.1 143.1 44.9
Transportschicht (Transport Layer)
Seite 88 von 139
•
Die Transportschicht ist für die Ende-zu-Ende-Übertragung von Daten von einem zu einem anderen
Gerät zuständig, unabhängig von der Art der Daten und von der Art und Weise, wie sie übermittelt
werden.
•
Die Anwendungen, die die Daten schicken bzw. empfangen, werden über sogenannte Portnummern
eindeutig identifiziert.
Bevor Daten ausgetauscht werden können, muss eine Anwendung eine Portnummer reservieren.
Damit wird sichergestellt, dass Daten immer zu richtigen Anwendung weitergeleitet werden.
Portnummern unter 1024 können nur vom Benutzer root reserviert werden. Eine Liste von
bekannten Portnummern findet man in der Datei /etc/services.
•
Zwei Protokolle werden hauptsächlich in dieser Schicht verwendet: das Transmission Control
Protocol (TCP, definiert in RFC 793) und das User Datagram Protocol (UDP, definiert in RFC 768).
TCP ist ein verbindungsorientiertes, zuverlässiges Protokoll. UDP hingegen stellt nur sicher, dass die
Pakete an die richtige Anwendung geschickt werden.
Transportschicht - TCP
•
TCP ist neben IP der Namensgeber für das gesamte Modell (TCP/IP-Modell), weil es das am
häufigsten verwendete Protokoll in der Transportschicht ist.
•
Das Protokoll erlaubt den zuverlässigen Austausch von Daten. Es kümmert sich darum, dass die
Pakete in der richtigen Reihenfolge an die Anwendung weitergegeben werden und dass verlorene
oder fehlerhafte Pakete nochmal gesendet werden.
•
Der TCP-Header wird an die Daten vorne angefügt.
Seite 89 von 139
Transportschicht - TCP-Verbindungen
•
Damit zwei Anwendungen miteinander kommunizieren können, müssen zuerst sogenannte Sockets
(Paare aus IP-Adresse und Portnummern) erzeugt werden.
Durch ein Paar aus Server- und Client-Socket kann eine TCP-Verbindung eindeutig identifiziert
werden.
•
Bevor nun Daten ausgetauscht werden können, muss die Verbindung mittels des TCP-Handshakes
aufgebaut werden:
•
Der Client schickt ein SYN-Paket an den Server.
•
Der Server antwortet mit einem SYN/ACK-Paket an den Client.
•
Der Client schließt den Verbindungsaufbau mit einem ACK-Paket an den Server ab.
•
Nach dem TCP-Handshake können Daten ausgetauscht werden. Die Verbindung bleibt auch dann
bestehen, wenn keine Daten ausgetauscht werden. Erst der geordnete Verbindungsabbau (ähnlich
zum Verbindungsaufbau) beendet eine Verbindung.
•
Folgene Anwendungen verwenden beispielsweise TCP: HTTP, FTP, SSH
Transportschicht - UDP
•
Im Gegensatz zu TCP ist UDP ein verbindungsloses Protokoll, d.h. es wird keine Verbindung
aufgebaut, sondern es werden einfach nur Daten verschickt.
•
Wie bei TCP bezeichnet man ein Paar aus IP-Adresse und UDP-Portnummer mit Socket.
•
Es werden auch keinerlei sonstige Garantien gemacht, d.h. man hat hier die gleichen Probleme wie
bei IP-Datagrammen:
•
Die Reihenfolge der ankommenden Pakete kann sich ändern.
•
Es können Pakete mehrfach oder gar nicht ankommen.
•
Anwendungen, die UDP benutzen, müssen also robust gegenüber solchen Problem sein, haben aber
den Vorteil, dass Daten schneller verschickt werden können (der Verbindungsaufbau fällt ja komplett
weg).
•
Folgende Anwendungen verwenden beispielsweise UDP: DNS, DHCP, SNMP
Transportschicht - Befehle: ss
ss - Zeigt Socket-Statistiken an.
» Gehört zu dem selben Paket wie ip.
» Optionen: -l → nur Sockets im Status LISTEN anzeigen, -a → alle Sockets anzeigen, -r →
Adressen und Ports zu Namen auflösen, -n → keine Namensauflösung, -p → Prozess anzeigen, -t
→ TCP-Sockets anzeigen, -u → UDP-Sockets anzeigen, -x → Unix-Sockets anzeigen.
» $ ss -t -n -a
State
Recv-Q Send-Q
LISTEN
0
128
LISTEN
0
128
LISTEN
0
128
LISTEN
0
128
ESTAB
0
0
Local Address:Port
*:22
:::22
127.0.0.1:6010
::1:6010
192.168.56.101:22
Peer Address:Port
*:*
:::*
*:*
:::*
192.168.56.1:54330
Seite 90 von 139
Transportschicht - Befehle: netstat
netstat - Zeigt Netzwerkinformationen an.
» Sehr vielseitiges Programm mit vielen Optionen zur Anzeige von Routing-Tabellen, offenen
Verbindungen, Statistiken, …
» Anzeigen von: keine Angabe → offene Sockets, -r → Routing-Tabellen,
Netzwerkschnittstellen, -s → Statistiken, -g → registrierte Multicast-Gruppen.
-i
→
» Optionen: -n → keine Namensauflösung, -l → nur Sockets im Status LISTEN anzeigen, -a → alle
Sockets anzeigen, -t → TCP-Sockets anzeigen, -u → UDP-Sockets anzeigen, -p → Prozess
anzeigen.
» $ netstat -t -n -a
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address
Foreign Address
tcp
0
0 0.0.0.0:22
0.0.0.0:*
tcp
0
0 10.10.10.101:22
10.10.10.1:44240
tcp6
0
0 :::22
:::*
$ netstat -g -n
IPv6/IPv4 Group Memberships
Interface
RefCnt Group
--------------- ------ --------------------lo
1
224.0.0.1
eth0
1
224.0.0.1
lo
1
ff02::1
lo
1
ff01::1
eth0
1
ff02::1:ff12:3456
eth0
1
ff02::1
eth0
1
ff01::1
State
LISTEN
ESTABLISHED
LISTEN
Anwendungsschicht
•
Die Anwendungsschicht umfasst alle Protokolle, die Anwendungen für die Kommunikation
miteinander verwenden.
•
Dazu gehören standardisierte Protokolle wie HTTP, FTP oder SSH, aber auch alle anderen, nichtstandardisierten Protokolle, die beliebige Anwendungen verwenden.
•
Wir betrachten im Folgenden zwei Protokolle, nämlich DHCP und DNS, da diese wichtige Aufgaben
bei der Netzwerkkonfiguration haben.
Seite 91 von 139
DNS (Domain Name System)
•
Das Domain Name System (DNS, definiert in RFC 1034 und RFC 1035) erlaubt die Verbindung eines
Namens mit einer IP-Adresse. Erst dadurch konnte das Internet so richtig erfolgreich werden, da
sich Namen viel leichter merken lassen, als die IP-Adressen dahinter.
•
Die einzelnen Teile eines Domainnamens werden mit Punkten voneinander getrennt geschrieben,
z.B. mathematik.univie.ac.at.
•
Das DNS ist hierarchisch aufgebaut. Es gibt nicht ein paar DNS-Server, die alles wissen, sondern
viele, die Teile wissen und wissen, wo sie nachschauen können.
Ganz oben in dieser Hierarchie stehen die Root-Server, die die DNS-Server der Top Level Domains
(TLDs, im Domainnamen ganz rechts zu finden) kennen.
•
Soll ein Domainname zu einer IP-Adresse aufgelöst werden, wird dieser (im schlimmsten Fall) an
einen Root-Server geschickt. Dieser antwortet mit der IP-Adresse des DNS-Servers, der die TLD des
Domainnamens verwaltet. Dann wird dieser DNS-Server gefragt, der dann den nächsten Teil des
Domainnamens (von rechts nach links) auflöst und so weiter (iterative Auflösung).
Namensauflösung unter Linux
•
Jedes Linuxsystem hat einen Hostnamen, auch wenn der Computer keine Netzwerkschnittstellen
haben sollte. Dieser ist in /etc/hostname festgehalten und kann über hostname bzw. bei Verwendung
von systemd auch über hostnamectl angezeigt und geändert werden.
•
Für die Namensauflösung gibt es die NSS-Datenbank „hosts“. Die Standardkonfiguration benutzt die
Datei /etc/hosts und dann DNS als Quellen.
•
In der Datei /etc/hosts werden pro Zeile ein oder mehrere Namen mit einer IP-Adresse assoziiert:
127.0.0.1
127.0.1.1
localhost
host99.ict
host99
# The following lines are desirable for IPv6 capable hosts
::1
localhost ip6-localhost ip6-loopback
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
Namensauflösung unter Linux - /etc/resolv.conf
•
Für die Konfiguration von DNS wird die Datei /etc/resolv.conf benutzt. Früher wurde diese Datei
manuell erstellt, aktuell wird dafür das Paket resolvconf verwendet.
•
Auch wenn die Datei dynamisch generiert wird, kann man Änderungen immer noch manuell
vornehmen, muss aber damit rechnen, dass diese bei der nächsten Änderung der
Netzwerkkonfiguration überschrieben werden.
•
Eine /etc/resolv.conf-Datei kann z.B. so aussehen:
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
#
DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
nameserver 10.10.10.1
search ict univie.ac.at
Seite 92 von 139
•
Die wichtigsten Anweisungen sind (siehe man resolv.conf):
•
nameserver IP-ADRESSE → Gibt den zu benutzenden DNS-Server an. Maximal drei DNS-Server
können so angegeben werden.
•
search DOMAIN1 [DOMAIN2 ...] → Gibt die Suchliste an, die verwendet wird, wenn der
Hostname nicht vollständig ist (i.e. es wird dann HOST.DOMAIN1, HOST.DOMAIN2, usw.
gebildet).
Namensauflösung unter Linux - resolvconf
•
Das Paket „resolvconf“ wird über Dateien in /etc/resolvconf konfiguriert. Dort können z.B. fixe
DNS-Server eingetragen werden.
•
Weiters ist resolvconf in verschiedene Netzwerkdienste wie NetworkManager, ifup, dnsmasq und
dhclient eingebunden, um DNS-Serveränderungen mitgeteilt zu bekommen.
•
Bei Verwendung von ifup können z.B. in /etc/network/interfaces bei einer Netzwerkschnittstelle
die zusätzlichen Optionen „dns-nameserver“ und „dns-search“ verwendet werden, um DNS
automatisch beim Aktivieren der Netzwerkschnittstelle zu konfigurieren.
Namensauflösung - Befehle: host, dig
host - Löst DNS-Namen auf.
» Mit der Option -t kann der Abfragetyp ausgewählt werden (z.B. „A“ für IPv4, „AAAA“ für IPv6
oder „MX“ für Mailserver)
» $ host login.univie.ac.at
login.univie.ac.at has address 131.130.20.69
login.univie.ac.at has IPv6 address 2001:62a:4:22::22:4
login.univie.ac.at mail is handled by 10 zidmx1.univie.ac.at.
dig - Löst DNS-Namen auf (und ist viel flexibler als host).
» Der Befehl wird meist in der Variante dig @SERVER NAME TYP verwendet, wobei SERVER der
DNS-Server, NAME der aufzulösende Name und TYP der Abfragetyp ist.
» Über „+ABFRAGEOPTION“ kann die Abfrage bzw. die Ausgabe beeinflusst werden.
» $ dig +nocomments +nostats +nocmd login.univie.ac.at
;login.univie.ac.at.
IN
A
login.univie.ac.at.
249
IN
A
131.130.20.69
$ dig +nocomments +nostats +nocmd login.univie.ac.at AAAA
;login.univie.ac.at.
IN
AAAA
login.univie.ac.at.
148
IN
AAAA
2001:62a:4:22::22:4
DHCP (Dynamic Host Configuration Protocol)
•
In größeren Netzwerken ist es mühsam, wenn jedes Gerät einzeln konfiguriert werden muss, d.h. IPAdresse, Netzwerkmaske und Default-Gateway zugewiesen werden müssen. Abhilfe schafft DHCP
(definiert in RFC 2131).
•
Bei DHCP wird eine Anfrage an einen DHCP-Server geschickt (mittels der Broadcastadresse
255.255.255.255), in der um eine IP-Adresse und zusätzliche Konfiguration gebeten wird.
Seite 93 von 139
•
Der DHCP-Server antwortet mit einer noch nicht vergebenen IP-Adresse sowie der Netzwerkmaske.
Zusätzlich werden normalerweise das Default-Gateway sowie DNS-Server mitgeteilt. Die vergebene
IP-Adresse kann zudem zeitlich beschränkt gültig sein, vor Ablauf der Gültigkeit muss das Gerät
erneut den DHCP-Server fragen.
•
Die meisten WLAN-Router und z.B. auch VirtualBox (für NAT- und interne Netzwerke) verwenden
DHCP zur Konfiguration der angeschlossenen Geräte.
DHCP-Konfiguration
•
Bei Verwendung von ifup braucht als Konfigurationsart nur „dhcp“ eingestellt werden. D.h. folgende
Zeilen reichen für die automatische Konfiguration einer Netzwerkschnittstelle via DHCP:
auto eno1
iface eno1 inet dhcp
•
Im Hintergrund verwendet ifup das Programm dhclient. Dieses kann natürlich auch manuell
verwendet werden. Dazu braucht man nur dhclient SCHNITTSTELLE eingeben und das Programm
konfiguriert die Schnittstelle via DHCP.
Unter /etc/dhcp/ liegen die Konfigurationsdateien für dhclient, dort kann z.B. in dhclient.conf
eingestellt werden, welche Informationen vom DHCP abgefragt werden sollen.
Sonstige Befehle - Netzwerkmonitoring
Zur Überwachung eines Netzwerks oder zum Untersuchen von Netzwerkpaketen gibt es mehrere
Programme unter Linux:
•
tcpdump: CLI; Pakete, gefiltert nach Bedingungen, werden ausgegeben.
•
wireshark: GUI/CLI; Ähnlich wie tcpdump, aber leichter benutzbar. Kann tcpdump Ausgaben
verwenden.
•
iptraf: CLI (ncurses); Zeigt unter anderem Statistiken für verschiedene Protokolle an.
Netzwerkkonfiguration mit Puppet
•
In Puppet gibt es keine eingebauten Möglichkeiten, Netzwerkschnittstellen zu verwalten.
•
Es gibt aber mehrere nachinstallierbare Module, mit denen Netzwerkschnittstellen verwaltet werden
können, z.B. das puppet/network Modul.
Hostverwaltung mit Puppet
•
Hostnamen und deren IP werden in Puppet über die Ressource host verwaltet.
•
Unter Ubuntu wird standardmäßig der Provider parsed verwendet (der einzig mögliche). Dieser
modifiziert die Datei /etc/hosts.
•
Wichtige Attribute:
•
name: Der Name des Computers (falls nicht angegeben, wird der Titel verwendet).
•
ensure: Der gewünschte Zustand (present oder absent).
•
comment: Ein Kommentar zum Computer.
•
host_aliases: Ein Aliasname oder ein Array von Aliasnamen.
Seite 94 von 139
•
ip: Die IP-Adresse des Computers.
•
target: Die Zieldatei, in der die Informationen gespeichert werden (Standardwert: /etc/hosts).
Hostverwaltung mit Puppet - Beispiele
•
Anlegen oder Modifizieren eines Hosteintrags:
host {'ict-infrastruktur.home:
ensure => present,
host_aliases => 'ict-infrastruktur',
ip => '127.0.0.1',
}
•
Löschen eines Hosteintrags:
host {ict-infrastruktur.home': ensure => absent}
Seite 95 von 139
Foliensatz 7
Kerberos, LDAP und SSSD
Inhalt
•
Kerberos
•
LDAP (Lightweight Directory Access Protocol)
•
SSSD (System Security Services Daemon)
Die Grafik „Kerberos Protokoll“ steht unter der CC BY-SA 3.0 Lizenz.
Kerberos
•
Kerberos ist ein Netzwerkauthentifizierungsprotokoll, das für das Athena-Projekt des MIT
entwickelt wurde. Die aktuelle Version 5 ist in RFC4120 definiert.
•
Mittels Kerberos kann man eine sichere Authentifizierung in einem ungesicherten Netzwerk
auf sicheren Rechnern anbieten, wobei die Authentifizierung durch eine dritte Partei, dem
Kerberos-Server, übernommen wird.
•
Der Kerberos-Server authentifiziert den Client gegenüber dem Server, den Server gegenüber dem
Client und sich selbst gegenüber dem Client und den Server. Dabei werden sogenannte Tickets
verwendet, um die Identität nachzuweisen. Diese Tickets erlauben auch ein Single-Sign-On, d.h.
Passwörter müssen nur einmal eingegeben werden. Zudem kann die Kommunikation zwischen den
Parteien verschlüsselt werden.
•
Bekannte Implementierung sind MIT Kerberos (diese betrachten wir genauer), Heimdal Kerberos
und Microsoft Active Directory.
Links: Designing an Authentication System: a Dialogue in Four Scenes, Kerberos Tutorial
Kerberos - Realm
•
Ein Kerberos-Server verwaltet genau ein Realm. Innerhalb dieses Realms kann der Server Benutzer,
Rechner und Dienste authentifizieren. D.h. ein Benutzer/Rechner/Dienst gehört zu dem Realm, wenn
er ein Geheimnis, nämlich einen Schlüssel, mit dem Kerberos-Server teilt.
•
Das bedeutet aber nicht, dass ein Benutzer und ein Dienst, an dem sich der Benutzer
authentifizieren will, zum selben Realm gehören müssen. Falls sie zu verschiedenen Realms gehören
und es eine Vertrauensstellung zwischen den Realms gibt, findet eine sogenannte Cross-Realm
Authentifizierung statt.
•
Beim Namen eines Realms muss auf die Groß- und Kleinschreibung geachtet werden. Üblich ist die
Verwendung des DNS-Domainnamens in Großbuchstaben als Name für ein Realm.
Seite 96 von 139
Kerberos - Schlüssel
•
Kerberos verwendet symmetrische Kryptographie, um die verschiedenen, über das unsichere
Netzwerk geschickten Nachrichten zu ver- bzw. entschlüsseln und erlaubt dabei die Verwendung
mehrerer Algorithmen (z.B. DES, 3DES, AES256, …).
•
Damit verschiedene Kerberos-Implementierungen miteinander interagieren können, müssen sie
zumindest einen Verschlüsselungsalgorithmus gemeinsam haben.
•
Jedem Benutzer/Rechner/Dienst ist ein Schlüssel zugeordent, der für die unterschiedlichen
Verschlüsselungsalgorithmen verwendet wird.
•
Dienste verwenden üblicherweise per Zufall generierte Schlüssel, während der Schlüssel eines
Benutzers mit Hilfe seines Passworts reproduzierbar erzeugt werden kann.
•
Zusätzlich hat jeder Schlüssel eine Versionnummer (kvno), die erhöht wird, wenn sich der
Schlüssel/das Passwort ändert.
Kerberos - Principal
•
Jedem Schlüssel am Kerberos-Server ist ein Name zugeordnet, der Principal. Dieser Principal hat
die Form Komponente1/Komponente2/...@REALM.
•
Für Benutzer werden üblicherweise ein oder zwei Komponenten, Name/Instanz@REALM, verwendet,
wobei der Name dem Benutzernamen entspricht und die Instanz eine zusätzliche Funktion
beschreibt, z.B. ob der Benutzer Administrator ist.
•
Bei Diensten hat der Principal die Form Dienstname/FQDN@REALM. Oft wird als Dienstname „host“
verwendet, um den generischen Zugriff auf den Rechner selbst zu beschreiben.
Kerberos - KDC, AS, TGS, Tickets
•
Der Kerberos-Server wird als Key Distribution Center (KDC) bezeichnet und besteht aus zwei
logisch separaten Diensten: dem Authentication Server (AS) und dem Ticket Granting Server (TGS).
•
Der Authentication Server wird benutzt, um einen Benutzer über sein Passwort zu authentifizieren
und ein Ticket Granting Ticket (TGT) auszustellen. Danach kann der Benutzer das TGT benutzen
und braucht sein Passwort nicht mehr einzugeben.
•
Mit dem TGT können über den Ticket Granting Server spezielle Servicetickets für Dienste
angefordert und über diese Tickets die Authentifizierung gegenüber den Diensten erledigt werden.
Der Principal für den TGS hat die Form krbtgt/REALM@REALM.
•
Jedes Ticket, sowohl das TGT als auch ein Serviceticket, ist mit dem Schlüssel des Principals
verschlüsselt, für den das Ticket vorgesehen ist.
•
Weiters besitzt jedes Ticket auch ein Ablaufdatum, nach dem es nicht mehr gültig ist, damit es nicht
ewig verwendet werden kann.
Kerberos - Funktionsweise
Seite 97 von 139
Kerberos - Funktionsweise Schritt 1
•
Der Benutzer (der Client) schickt eine Authentifizierungsanfrage an den Server. Die Anfrage enthält
seinen Principal, die IP-Adressen, für denen das TGT gültig sein soll, als auch die gewünschte
Lebenszeit des TGT.
•
All diese Informationen werden unverschlüsselt übertragen, da diese nicht geheim sind.
•
Der AS erzeugt einen zufälligen Sitzungsschlüssel für den Client und den TGS. Dieser
Sitzungsschlüssel zusammen mit dem Client-Principal, dem TGS-Principal, den IP-Adressen, dem
aktuellen Zeitstempel und der Lebenszeit werden in ein Ticket verpackt (das TGT) und mit dem
Schlüssel des TGS verschlüsselt.
•
Zusätzlich wird der TGS-Principal, der Zeitstempel, die Lebenszeit und der Sitzungsschlüssel mit
dem Schlüssel des Benutzers verschlüsselt. Dieses Paket sowie das TGT werden an den Client
zurückgesandt.
•
Gibt der Benutzer das richtige Passwort ein, so kann der Client den Teil, der mit dem
Benutzerschlüssel verschlüsselt ist, öffnen und ist somit authentifiziert, da er nun den
Sitzungschlüssel besitzt.
Seite 98 von 139
•
Der Client fordert ein Serviceticket für einen Dienst an, in dem er folgende Informationen an den
TGS schickt:
•
Das TGT
•
Den Principal des Dienstes, für den das Serviceticket gewünscht ist, sowie die gewünschte
Lebenszeit des Servicetickets
•
Einen Authenticator bestehend aus dem Benutzerprincipal und dem aktuellen Zeitstempel,
verschlüsselt mit dem Sitzungsschlüssel für das TGS
•
Der TGS prüft die Anfrage auf Richtigkeit, z.B. Lebenszeit des TGT noch nicht vorbei, IP-Adresse der
Anfrage passt auf die im TGT gespeicherten, Authenticator kann entschlüsselt werden und Inhalt
passt zum TGT, …
•
Passt alles, so wird analog zum Ausstellen des TGT ein Serviceticket ausgestellt (i.e. Situngsschlüssel
erzeugen, nötige Informationen hineinpacken, mit Schlüssel des Services verschlüsseln) und
genauso auch ein entsprechendes Antwortpaket geschickt.
•
Der Client erzeugt wieder einen Authenticator, dieses Mal verschlüsselt mit dem Sitzungsschlüssel
für den Dienst, und schickt diesen gemeinsam mit dem Serviceticket an den Dienst.
•
Kann der Dienst das Serviceticket entschlüsseln, so kann der darin enthaltene Sitzungschlüssel für
das Entschlüsseln des Authenticators verwendet und damit der Benutzer authentifiziert werden.
•
Um auch den Dienst gegenüber den Client zu authentifizieren, schickt der Dienst als Antwort den
Zeitstempel des Authenticators verschlüsselt mit dem Sitzungsschlüssel zurück an den Client. Kann
der Client die Antwort entschlüsseln und passt der Zeitstempel, so wurde der richtige
Sitzungsschlüssel verwendet und damit ist auch der Dienst gegenüber den Client authentifiziert.
Kerberos - Vertrauensstellungen
•
Wie erwähnt, können zwischen zwei Realms A und B Vertrauensstellungen aufgebaut werden. Diese
können unidirektional sein (Benutzer von A können auf Dienste von B zugreifen) oder bidirektional.
•
Weiters gibt es neben den direkten Vertrauensstellungen auch transitive und hierarchische.
•
Bei einer unidirektionalen Vertrauensstellung hat der KDC von B Vertrauen in den KDC von A. Dieses
Vertrauen wird über einen geteilten Schlüssel für den Principal krbtgt/B@A (Remote TGT)
bewerkstelligt.
•
Bei bidirektionalen Vertrauensstellungen wird zusätzlich noch ein geteilter Schlüssel für krbtgt/A@B
gebraucht.
Kerberos - Vertrauensstellungen - Beispiel
•
Zum besseren Verständnis ein Beispiel, in dem der Benutzer [email protected] auf den SSH-Dienst auf
ssh.beta.at zugreifen möchte:
•
Der Benutzer „ict“ authentifiziert sich an seinem AS und bekommt ein TGT.
Seite 99 von 139
•
Er verbindet sich nun mit dem Server ssh.beta.at. Der SSH-Client sieht anhand der Domain,
dass der Server nicht zum Realm ALPHA.AT gehört. Daher fragt er den TGS von ALPHA.AT nach
dem Remote TGT krbtgt/[email protected].
•
Mit dem Remote TGT fragt der SSH-Client den TGS von BETA.AT nach dem Serviceticket
host/[email protected]. Der TGS überprüft, ob das Remote TGT mit dem lokal
gespeicherten zusammenpasst und falls dem so ist, wird das Serviceticket an den SSH-Client
geschickt.
•
Der SSH-Client kann nun das Serviceticket zum Authentifizieren beim SSH-Dienst verwenden.
Kerberos - Vor- und Nachteile
Vorteile:
•
Kerberos-Nachrichten sind gegen Lauschangriffe und Replay-Attacken geschützt.
•
Die Kommunikation zwischen Client und Server kann verschlüsselt werden.
•
Der Client und der Server können gegenseitig ihre Identität verifizieren.
•
Single-Sign-On wird unterstützt.
•
Das Protokoll funktioniert über ungesicherte Netzwerke hinweg.
•
Benutzerpasswörter müssen nicht über das Netzwerk übertragen werden.
Nachteile:
•
Ohne Kerberos-Server funktioniert die Authentifizierung von Benutzern und Diensten nicht mehr
(beheben durch Verwenden mehrerer Kerberos-Servern).
•
Die Uhren aller Rechner müssen wegen der Benutzung von Zeitstempeln unbedingt synchron
gehalten werden (z.B. durch Verwendung von NTP).
•
Wird ein Server geknackt, auf dem ein Kerberos-Dienst läuft, so ist dessen privater Schlüssel nicht
mehr sicher (beheben durch Erzeugen eines neues Schlüssels).
•
Wird der Kerberos-Server geknackt, sind alle Schlüssel potentiell kompromitiert.
•
Läuft das TGT ab, muss es vom Benutzer durch Eingabe seines Passworts erneuert werden.
Kerberos - Microsoft Active Directory
•
Microsoft Active Directory (AD) verwendet für die Authentifizierung von Rechnern, Diensten und
Benutzern auch Kerberos v5.
•
Jeder AD Server fungiert dabei als KDC, die Kerberos-Datenbank wird automatisch auf alle AD
Server verteilt.
•
Die nötigen Schlüssel für Rechner, Dienste und Benutzer werden im entsprechenden Objekt im
LDAP-Teil des AD gespeichert.
•
Hat man eine gemischte Systemumgebung bestehend aus Windows- und Linux-Rechnern, so ist es
meistens am einfachsten, das AD zum Speichern der Benutzerdaten zu verwenden und dann die
Benutzerdaten auf den Linux-Rechnern über LDAP vom AD abzufragen bzw. die Benutzer über
Kerberos zu authentifizieren.
Seite 100 von 139
Kerberos - Installation
•
Wichtig: Damit Kerberos richtig funktioniert, müssen alle Domainnamen aufgelöst werden können!
•
Die für den Kerberos-Server nötigen Pakete sind krb5-admin-server und krb5-kdc. Bei der
Installation wird man nach einigen Daten gefragt:
•
„Voreingestellter Realm für Kerberos Version 5“
•
„Kerberos-Server für Ihren Realm“
•
„Administrations-Server für Ihren Kerberos-Realm“
•
Der Administrationsserver ist üblicherweise der gleiche wie der Kerberos-Server und wird zum
Verwalten der Kerberos-Datenbank verwendet.
•
Danach muss der Realm mit Hilfe von krb5_newrealm angelegt und mit einem Passwort geschützt
werden. Die Kerberos-Datenbank selbst wird dabei unter /var/lib/krb5kdc/ abgelegt und die Datei
mit dem Master-Passwort in der Datei /etc/krb5kdc/stash.
Links: Ubuntu Kerberos Seite, Kerberos Installation von Spinlock Solutions
Kerberos - Server-Konfiguration
•
Im Verzeichnis /etc/krb5kdc finden sich die folgenden Dateien:
•
kdc.conf → Konfigurationsdatei für die Server
•
kadm5.acl → Enthält ACLs für den Zugriff auf die Kerberos-Datenbank
•
stash → Enthält den Schlüssel für die Kerberos-Datenbank
•
In der Datei kdc.conf wird der Kerberos-Server sowie der Administrationsserver konfiguriert. Hier
wird z.B. eingetragen, wo für welches Realm die Kerberos-Datenbank liegt und wie bzw. wo
Informationen geloggt werden.
•
Damit Administratoren (Principals der Form Benutzername/admin@REALM) Vollzugriff auf die
Kerberos-Datenbank haben, muss folgender Eintrag zu kadm5.acl hinzugefügt und danach der
krb5-admin-server neu gestartet werden:
*/admin *
Achtung: Beim Starten des Administrationsservers werden Zufallszahlen gebraucht, falls der
Entropy-Speicher leer ist, hängt der Server bis genügend Entropy wieder vorhanden ist!
Kerberos - Allgemeine Konfiguration
•
Die Clientprogramme für Kerberos sind im Paket krb5-user enthalten. Zusätzlich empfiehlt sich die
Installation von krb5-doc, um die restlichen Manpages und die Kerberos-Dokumentation lokal
verwenden zu können.
•
In der Datei /etc/krb5.conf sind Daten für die Grundkonfiguration von Kerberos eingetragen.
•
Diese Datei wird sowohl auf dem Serverrechner gebraucht als auch auf den Clientrechnern.
•
Es ist u.a. definiert, welche Realms es gibt und wie deren Server heißen. Zudem kann ein Realm
als Standard-Realm festgelegt werden.
•
Weiters kann festgelegt werden, wie das Mapping von DNS-Domain bzw. Rechnername auf
Seite 101 von 139
Kerberos-Realm funktionieren soll.
•
Eine weitere, wichtige Option is k5login_authoritative (default: yes), die angibt, dass
standardmäßig nur dem Benutzer NAME@DEFAULT_REALM der Login erlaubt wird, falls die Datei
$HOME/.k5login nicht existiert bzw. falls sie existiert nur den Principals, die darin zeilenweise
gelistet sind.
Kerberos - Administration der Datenbank - kadmin
•
Es gibt zwei Programme zur Administration der Kerberos-Datenbank: kadmin und kadmin.local.
Letzters kann als Administrator nur lokal am Administrationsserver, dafür ohne Authentifizierung
ausgeführt werden, das andere auf jedem Rechner im Realm, da es die Kerberos-Authentifizierung
verwendet.
•
Mit diesen Programmen können u.a. Principals aufgelistet (listprincs), erstellt (addprinc),
gelöscht (delprinc), umbenannt (renprinc) oder ausgegeben (getprinc) werden.
•
Weiters können die zu einem Principal gehörenden Schlüssel in einer sogenannten keytab-Datei
gespeichert (ktadd) oder von dieser gelöscht (ktremove) werden. Dies wird gebraucht, um Diensten
den entsprechenden Schlüssel zur Verfügung stellen zu können.
•
Damit man als Administrator von überall die Kerberos-Datenbank administrieren kann, empfiehlt es
sich, einen Principal root/admin@REALM anzulegen.
Kerberos - Clientprogramme - kinit, kdestroy, klist
kinit - Holt Ticket Granting Tickets.
» Wird benutzt, um ein TGT vom KDC zu holen und lokal zu speichern.
» $ kinit root/admin
Password for root/[email protected]:
kdestroy - Zerstört zwischengespeicherte Tickets.
» Die Tickets werden durch Löschen der Datei mit den Tickets zerstört.
» $ kdestroy
klist - Zeigt zwischengespeicherte Tickets an.
» Zeigt entweder die Principals und Tickets des Benutzers-Caches an oder den Inhalt einer keytabDatei.
» Optionen: -f → zeige zusätzlich Flags an, -k → muss angegeben werden bei Verwendung mit einer
keytab-Datei.
» $ klist -f
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: root/[email protected]
Valid starting
Expires
Service principal
2016-04-23 16:45:23 2016-04-24 02:45:23 krbtgt/[email protected]
renew until 2016-04-24 16:45:10, Flags: FPRIA
Kerberos - Clientprogramme - kpasswd, ktutil
kpasswd - Ändert das Kerberos-Passwort eines Benutzers.
» $ kpasswd [email protected]
Password for [email protected]:
Seite 102 von 139
Enter new password:
Enter it again:
Password changed.
ktutil - Verwaltet keytab-Dateien.
» Dient zum Hinzufügen bzw. Löschen von Einträgen in einer keytab-Datei.
» $ ktutil
ktutil: l
slot KVNO Principal
---- ---- --------------------------------------------------------------------ktutil: rkt /etc/krb5.keytab
ktutil: l
slot KVNO Principal
---- ---- -------------------------------------------------------------------- 1
1
host/[email protected]
2
1
3
1
4
1
Kerberos - Konfiguration eines Dienstes am Beispiel SSH
•
Damit man per Kerberos über OpenSSH einloggen kann, muss man einen Principal host/FQDN@REALM
mit zufälligem Schlüssel erzeugen.
•
Dieser Schlüssel muss dann in eine keytab-Datei exportiert werden, damit OpenSSH ihn verwenden
kann. Die Standard-keytab-Datei, die Applikationen verwenden, wenn nichts anderes angegeben ist,
ist /etc/krb5.keytab.
•
Anschließend muss der SSH-Server noch umkonfiguriert werden, damit die Authentifikation via
Kerberos auch erlaubt ist. Dies wird mittels der Optionen KerberosAuthentication und
GSSAPIAuthentication bewerkstelligt.
Die erste Option sollte eigentlich nicht verwendet werden, weil hier das Passwort über die Leitung
an den SSH-Server geschickt wird und der SSH-Server versucht, den Benutzer mit dem Passwort am
Kerberos-Server zu authentifizieren.
Bei der zweiten Option muss sich der Benutzer lokal am Kerberos-Server authentifizieren und das
TGT wird dann benutzt, um ein entsprechendes Serviceticket für den SSH-Server zu bekommen.
•
Mittels der ssh-Option -K können die Tickets vom Client-Cache auch am Server verwendet werden.
Kerberos - Konfiguration einer Vertrauensstellung
•
Um Dienste eines anderen Realms benutzen zu können, muss eine Vertrauensstellung hergestellt
werden.
•
Wie erwähnt, müssen für eine bidirektionale Vertrauensstellung Principals der Form krbtgt/A@B und
krbtgt/B@A in beiden Realms angelegt werden.
•
Zum Anlegen dieser Principals verwendet man auf beiden KDCs am besten kadmin.local und
möglichst lange, zufällige Passwörter (aber nicht die Option -randkey).
•
Sobald beide KDCs konfiguriert sind, funktioniert das Verwenden der Dienste im jeweils anderen
Realm.
Seite 103 von 139
Kerberos - Zusammenfassung Konfiguration
•
Pakete für die Serverdienste installieren, entsprechende Werte bei der Installation eingeben
•
Realm mittels krb5_newrealm erzeugen
•
In /etc/krb5kdc/kadm5.acl eine Zeile */admin * für die Administration über kadmin hinzufügen
und Administrationsserver neu starten
•
In /etc/krb5.conf für alle beteiligten Realms im Abschnitt „[realms]“ die Adressen der Server
hinterlegen und im Abschnitt „[domain_realm]“ die nötigen Mappings Domain-Realm eintragen
•
Principals für Benutzer, Hosts und Dienste anlegen sowie für etwaige Vertrauensstellungen
Kerberos - Einbindung in die Authentifizierung
•
Bis jetzt haben wird die Kerberos-Authentifizierung immer alleine betrachtet. D.h. um ein TGT zu
bekommen, musste immer kinit verwendet werden.
•
Ist Kerberos aber einmal konfiguriert, so können die Benutzer natürlich auch über ihr KerberosPasswort authentifiziert werden.
•
Die einfachste Möglichkeit, dies zu bewerkstelligen, ist mittels des PAM-Moduls pam_krb5, welches
durch das Paket libpam-krb5 installiert werden kann. Nach der Installation wird automatisch die
PAM-Konfiguration aktualisiert und pam_krb5 aktiviert, wodurch die Authentifizierung über das
Kerberos-Passwort möglich gemacht wird.
•
Loggt sich dann ein Benutzer mit seinem Kerberos-Passwort ein, so wird dann auch ein
entsprechender Ticket-Cache erstellt, so, wie wenn kinit aufgerufen worden wäre.
•
Wird pam_krb5 verwendet, so ist auch die Aktivierung von „KerberosAuthentication“ im SSHDaemon nicht mehr nötig, da beide die selbe Aufgabe erfüllen.
LDAP
•
Das Leightweight Directory Access Protocol (LDAP) ist ein Protokoll zur Abfrage von Daten eines
Verzeichnisdienstes. Die aktuelle Version LDAPv3 ist in den RFCs 4510 bis 4519 definiert.
•
Ein LDAP-Server ist ein Verzeichnisdienst (Directory Server), der über LDAP abgefragt werden kann
und dessen interne Struktur der LDAP-Spezifikation entspricht.
•
Das LDAP-Protokoll erlaubt auch die Anmeldung (LDAP-Bind) über ein Passwort oder mittels SASL
an einen LDAP-Server sowie Suchabfragen bzw. Änderungsanfragen.
•
Bekannte Implementierungen von LDAP-Servern sind OpenLDAP, Apache Directory Server, 389
Directory Server (von RedHat) und Microsoft Active Directory.
LDAP - DIT und DN
•
Ein LDAP-Server speichert zusammengehörige Daten in LDAP-Objekten, die ihrerseits hierarchisch
in einer Baumstruktur, dem Directory Information Tree (DIT), angeordnet sind.
•
Die LDAP-Objekte können über den sogenannten Distinguished Name (DN) eindeutig referenziert
werden.
Seite 104 von 139
Jedes Objekt besitzt einen auf seiner Hierarchieebene eindeutigen Relative Distinguished Name
(RDN). Die Zusammensetzung des RDNs eines Objekts mit dem DN seines übergeordneten Objekts
(getrennt durch einen Beistrich) ist dann der eindeutig DN des Objekts.
Ein Beispiel für einen DN ist cn=admin,dc=ict, wobei cn=admin der RDN ist und dc=ict der DN des
übergeordneten Objekts.
LDAP - Schema
•
Die Struktur des DIT wird durch ein genormtes, erweiterbares LDAP-Schema festgelegt.
Erweiterbar bedeutet, dass auch im Nachhinein neue Schema zum DIT hinzugefügt werden können.
•
In einem Schema werden Objekt-Klassen und deren Attribute definiert.
•
Eine Objekt-Klasse fasst eine Menge von Attributen zusammen und definiert auch, welche Attribute
zwingend vorhanden sein müssen bzw. welche optional sind. Weiters ist über Objekt-Klassen
festgelegt, wie die Hierarchie aussehen muss, i.e. welche Objekte welche Sub-Objekte haben dürfen.
•
Für jedes Attribut einer Objekt-Klasse ist festgelegt, welcher Syntax es folgen muss (z.B. ob der Wert
eine Ganzzahl oder eine Zeichenfolge sein muss), wie es verglichen werden kann und ob es ein oder
mehr Werte haben darf.
•
Jedem LDAP-Objekt ist eine strukturelle Objekt-Klasse zugeordnet (die „Hauptklasse“) und eventuell
zusätzliche Hilfsklassen. Diese Objekt-Klassen bestimmen, welche Attribute das Objekt haben muss
bzw. welche es zusätzlich haben kann.
LDAP - Schema - Beispiel Attribut und Objekt-Klasse
attributetype ( 2.5.4.35 NAME 'userPassword'
DESC 'RFC2256/2307: password of user'
EQUALITY octetStringMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.40{128} )
objectclass ( 2.5.6.6 NAME 'person'
DESC 'RFC2256: a person'
SUP top STRUCTURAL
MUST ( sn $ cn )
MAY ( userPassword $ telephoneNumber $ seeAlso $ description ) )
•
Die Zeichenfolgen „2.5.4.35“, „2.5.6.6“ und „1.3.6.1.4.1.1466.115.121.1.40“ sind Object Identifier
(OIDs), die eindeutig ein Attribut, eine Attributsyntax oder eine Objekt-Klasse beschreiben.
•
Beim Attribut „userPassword“ ist angegeben, welcher Syntax es folgen muss und wie es mit Werten
verglichen werden kann. Wäre zusätzlich noch ‚SINGLE-VALUE‘ angegeben, so dürfte das Attribute
nur einmal in einem Objekt vorkommen.
•
Die Objekt-Klasse „person“ ist von „top“ abgeleitet. Objekte dieser Klasse müssen die Attribute „sn“
und „cn“ besitzen, können optional aber auch noch ein paar andere besitzen.
LDAP - Wichtige Objekt-Klassen und Attribute
•
Die folgenden Objekt-Klassen und Attribute trifft man häufig an:
•
dcObject: Domain-Komponente mit dem Attribut „dc“
Seite 105 von 139
•
organization: Organisation mit den Attributen „o“ (Name), „street“ (Straßenname), „
postalCode“ (PLZ), …
•
organizationalUnit: Organisationseinheit mit den Attributen „ou“ (Name) und sonst den
gleichen Attributen wie für Organisationen
•
person → organizationalPerson → inetOrgPerson (Hierarchie von Objekt-Klassen): Person mit
den Attributen „sn“ (Nachname), „cn“ (Common Name), „userPassword“ (Anmeldepasswort),
„mail“ (E-Mailadresse), …
•
posixAccount: POSIX-Benutzerkonto mit den Attributen „uid“ (Benutzername), „uidNumber“
(UID), „gidNumber“ (GID), „loginShell“ (Shell), …
•
posixGroup: POSIX-Gruppe mit den Attributen „cn“, „gidNumber“ (GID der Gruppe) und
„memberUid“ (Benutzername eines Gruppenmitglieds)
LDAP - LDAP Data Interchange Format (LDIF)
•
Objekte eines LDAP-Verzeichnisses können mittels LDAP Data Interchange Format (LDIF) als
ASCII-Text dargestellt werden.
•
LDIF-Dateien können zwei Arten von Informationen darstellen: Entweder eine Menge von LDAPObjekten oder eine Menge von Änderungseinträgen.
•
Die Syntax von LDIF ist relativ einfach: Attribute werden durch Doppelpunkte getrennt von den
Werten geschrieben, Kommentare beginnen mit einem Hash-Zeichen und eine Leerzeile trennt
einzelne Einträge.
•
Achtung: Die Werte dürfen nur ASCII-Zeichen (ohne NUL, CR und LF) enthalten und nicht mit „<“
oder „:“ anfangen, damit sie direkt verwendet werden können. Ansonsten müssen statt einem
Doppelpunkt zwei Doppelpunkte verwendet und der Wert Base64-kodiert werden.
LDAP - LDIF - Beispieldatei mit Objekten
# ict
dn: dc=ict
objectClass: top
objectClass: dcObject
objectClass: organization
o: ict
dc: ict
# admin, ict
dn: cn=admin,dc=ict
objectClass: simpleSecurityObject
objectClass: organizationalRole
cn: admin
description: LDAP administrator
LDAP - LDIF - Änderungseinträge
•
Bei Änderungseinträgen im LDIF-Format wird zuerst das Objekt, das geändert werden soll, über den
DN angegeben und dann über das Attribut „changetype“ die Aktion.
Seite 106 von 139
•
Die Aktion „add“ fügt einen neuen Eintrag zum DIT hinzu. Die Attribute des Eintrags folgen direkt in
den nächsten Zeilen:
dn: ou=users,dc=ict
changetype: add
objectclass: organizationalUnit
ou: users
description: Bereich für die Benutzer
•
Die Aktion „delete“ löscht einen Eintrag aus dem DIT:
dn: ou=users,dc=ict
changetype: delete
LDAP - LDIF - Änderungseinträge Fortseztung
•
Mittels der Aktion „modify“ kann ein Eintrag modifiziert und Attribute hinzugefügt, geändert oder
gelöscht werden. Was gemacht werden soll, wird über die Attribute „add“, „delete“ und „replace“
angegeben, wobei der Wert immer der Name des Attributs ist, auf den sich die Aktion bezieht.
Mehrere Anweisungen für ein Objekt können durch eine Zeile bestehend aus einem Bindestrich von
einander getrennt werden.
dn: ou=users,dc=ict
changetype: modify
add: telephoneNumber
telephoneNumber: +43 1 4277 50639
telephoneNumber: +43 664 60277 50639
replace: description
description: Neue Beschreibung
delete: postalCode
LDAP - Suchanfragen
•
Für das Durchführen von Suchanfragen wird eine spezielle Filtersyntax, die in RFC4515 definiert
ist, benutzt.
•
Ein einfacher Filter hat die Form (Attribut Operator Wert).
•
•
•
Wird das Attribut weggelassen, so trifft der Filter auf alle Attribute zu.
•
Der Operator kann „=“, „>=“, „<=“ oder „~=“ (ungefähr gleich) sein.
•
Wird als Operator „=“ verwendet, so kann im Wert das Zeichen „*“ als Platzhalter benutzt
werden.
Weiters können die Filter logisch verknüpft werden:
•
(!(Filter)) → negierter Filter muss zutreffen
•
(&(Filter)(Filter)(...)) → alle Filter müssen zutreffen
•
(|(Filter)(Filter)(...)) → einer der Filter muss zutreffen
Die Filtersyntax ist noch mächtiger als hier gezeigt, aber meistens kommt man mit dem
Seite 107 von 139
Beschriebenen aus.
LDAP - Beispiele für Suchanfragen
•
(givenName=Thomas)
Objekte, bei denen das Attribut „givenName“ den Wert „Thomas“ hat
•
(!(givenName=Thomas))
Objekte, bei denen das Attribut „givenName“ nicht den Wert „Thomas“ hat
•
(sn=*)
Objekte, bei denen das Attribut „sn“ irgendeinen Wert hat
•
(givenName=*ris*)
Objekte, bei denen im Attribut „givenName“ irgendwo der Wert „ris“ vorkommt
•
(&(objectClass=posixAccount)(|(uid=leitner)(sn=*leitner*)))
Objekte, deren Attribut „objectClass“ den Wert „posixAccount“ hat und entweder „uid“ den Wert
„leitner“ hat oder „sn“ den Wert „leitner“ enthält.
OpenLDAP
•
Der Standard-LDAP-Server für Linux ist OpenLDAP. Dieser LDAP-Server wird schon seit fast 20
Jahren entwickelt, ist schnell, weit verbreitet und sehr stabil/gut getestet.
•
OpenLDAP kann zum Speichern der Daten sehr viele verschiedene Backends verwenden (z.B.
Berkeley DB, LDIF, SQL, LMDB, LDAP, …). Standardmäßig wird derzeit LMDB verwendet.
•
Die eingebaute Replikation erlaubt den Betrieb mehrer LDAP-Server mit den gleichen Daten, was die
Verfügbarkeit erhöht. Dabei können verschiedene Replikationsarten verwendet werden, z.B. eine
Master/Slave- oder eine Multi-Master-Konfiguration.
•
OpenLDAP hat noch weitere Funktionalitäten, z.B. können Anfragen an den Server über Module
durch sogenannte Overlays dynamisch geändert werden.
Links: OpenLDAP Administrationshandbuch, Ubuntu OpenLDAP Server Installation/Konfiguration,
OpenLDAP Installation von Spinlock Solutions
OpenLDAP - Clientprogramme
•
Die CLI-Programme von OpenLDAP zur Kommunikation mit einem LDAP-Server können mittels des
Pakets ldap-utils installiert werden. Diese Programme werden auch zur Konfiguration eines
OpenLDAP-Servers gebraucht.
•
Die wichtigsten dieser Programme sind ldapmodify (Hinzufügen, Ändern oder Löschen von
Objekten), ldapsearch (Durchsuchen des Verzeichnisses), ldapadd (Hinzufügen eines Objekts) und
ldapdelete (Löschen eines Objekts).
•
Die folgenden Optionen werden von all diesen Programmen unterstützt:
•
-H → Server-URI (z.B. „ldapi://“ oder „ldap://host95.ict“)
•
-Y EXTERNAL → Externe SASL-Authentifizierung verwenden, nötig für „ldapi://“
•
-x → Einfache Authentifizierung mit Passwort statt SASL verwenden
•
-D Bind-DN → DN zur Authentifizierung am Server
Seite 108 von 139
•
-W → Passwort für Authentifizierung
•
-Z → Verwendung von StartTLS (bei -ZZ wird StartTLS erzwungen)
•
-f Datei → Verwenden der Datei anstatt der Standardeingabe
OpenLDAP - Clientprogramme - ldapadd, ldapmodify
ldapadd - Erstellt ein neues Objekt am LDAP-Server.
» Ist eigentlich nur eine Aufrufform von ldapmodify mit der Option -a.
» Eine über -f angegebene LDIF-Datei muss eine Liste von LDAP-Objekten beinhalten.
» $ ldapadd -D cn=admin,dc=ict -W << EOF
> dn: ou=users,dc=ict
> objectClass: organizationalUnit
> ou: users
> EOF
Enter LDAP Password: PASSWORT EINGEBEN
adding new entry "ou=users,dc=ict"
ldapmodify - Modifiziert ein Objekt am LDAP-Server.
» Eine über -f angegebene LDIF-Datei muss eine Liste von Änderungsanfragen beinhalten.
» $ ldapmodify -D cn=admin,dc=ict -W << EOF
> dn: ou=users,dc=ict
> changetype: modify
> add: description
> description: Bereich fuer Benutzer
> EOF
Enter LDAP Password: PASSWORT EINGEBEN
modifying entry "ou=users,dc=ict"
OpenLDAP - Clientprogramme - ldapdelete, ldapsearch
ldapdelete - Löscht ein Objekt vom LDAP-Server.
» Als Argument muss der DN des zu löschenden Objekts übergeben werden.
» $ ldapdelete -D cn=admin,dc=ict -W ou=users,dc=ict
Enter LDAP Password: <PASSWORT EINGEBEN>
ldapsearch - Sucht am LDAP-Server nach Objekten.
» Als Argumente können ein Suchfilter und danach die auszugebenden Attribute angegeben werden.
» Optionen: -b → Suchbasis (Angabe erforderlich)
» $ ldapsearch
dn: dc=ict
objectClass:
objectClass:
objectClass:
o: ict
dc: ict
-b dc=ict -x -LLL
top
dcObject
organization
dn: cn=admin,dc=ict
objectClass: simpleSecurityObject
objectClass: organizationalRole
cn: admin
description: LDAP administrator
Seite 109 von 139
OpenLDAP - Clientprogramme - Konfiguration
•
Über die Datei /etc/ldap/ldap.conf können einige Standardwerte für die Clientprogramme gesetzt
werden (diese Datei wird üblicherweise auch von anderen Programme respektiert):
•
URI: Die abzufragenden Server (analog zur Option -H)
•
BASE: Die Standardsuchbasis (analog zur Option -b)
•
BINDDN: Der Standard-DN für die Authentifizierung (analog zur Option -D)
•
TIMEOUT: Anzahl an Sekunden, nachdem eine Anfrage abbrechen soll
•
TLS_CACERT: Die Datei mit den CA-Zertifikaten
•
TLS_REQCERT: Legt fest, ob das Zertifikat des Server überprüft werden soll:
•
never: Das Zertifikat wird nicht angefragt und auch nicht überprüft.
•
allow: Das Zertifikat wird angefragt, aber ein fehlendes oder ungültiges Zertifikat wird
ignoriert.
•
try: Das Zertifikat wird angefragt und ein fehlendes wird ignoriert, aber bei einem ungültigen
wird abgebrochen.
•
demand: Das Zertifikat wird angefragt und bei einem fehlenden oder ungültigen wird
abgebrochen.
OpenLDAP - Installation
•
OpenLDAP kann unter Ubuntu mittels des Pakets slapd (stand-alone LDAP daemon) installiert
werden.
•
Bei der Installation wird ein DIT mit der Domain des Rechners als Wurzel angelegt (z.B. dc=ict) und
ein zugehöriges Administratorkonto (z.B. cn=admin,dc=ict), dessen Passwort bei der Installation
eingegeben werden muss. Dieser DIT kann dann über dieses Konto administriert werden.
•
Die Konfigurationsdateien für den Server befinden sich in /etc/ldap/slapd.d im LDIF-Format.
Obwohl es so aussieht, als könnte man diese direkt dort ändern, darf das nicht gemacht werden! Es
ist gedacht, die Konfiguration mittels LDAP-Anfragen durchzuführen!
•
Früher gab es auch die Möglichkeit, den LDAP-Server über die Datei /etc/ldap/slapd.conf zu
konfigurieren. Diese Art der Konfiguration sollte aber nicht mehr verwendet werden.
OpenLDAP - Konfiguration
•
Detailierte Informationen zur Konfiguration finden sich im Administrationshandbuch.
•
Die Schema-Definitionen core, cosine, nis und inetorgperson sind standardmäßig aktiviert.
Weitere können bei Bedarf hinzugefügt werden (siehe Dateien im Verzeichnis /etc/ldap/schema/).
•
Die Konfiguration des Servers wird in einem speziellen DIT mit der Wurzel cn=config durchgeführt
(siehe man 5 slapd-config).
•
Im DN cn=config wird die allgemeine Serverkonfiguration festgelegt.
•
In Einträgen unterhalb von cn=schema,cn=config befinden sich die benutzten SchemaDefinition.
•
Einträge der Form olcDatabase=BACKEND,cn=config definieren je einen DIT und legen dessen
Konfiguration fest.
Seite 110 von 139
•
Bei Änderungsanfragen über LDAP werden die Änderungen automatisch aktiv und zusätzlich nach
/etc/ldap/slapd.d gesichert.
•
Wichtig: Konfigurationsänderungen müssen als Benutzer root und den CLI-Optionen -Y EXTERNAL
-H ldapi:/// gemacht werden, da standardmäßig kein Passwort für den Konfigurations-DIT gesetzt
ist!
OpenLDAP - Beispiel für DIT-Konfiguration
$ ldapsearch -LLL -Y EXTERNAL -H ldapi:/// -b cn=config olcDatabase=mdb
SASL/EXTERNAL authentication started
SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
SASL SSF: 0
dn: olcDatabase={1}mdb,cn=config
objectClass: olcDatabaseConfig
objectClass: olcMdbConfig
olcDatabase: {1}mdb
olcDbDirectory: /var/lib/ldap
olcSuffix: dc=ict
olcAccess: {0}to attrs=userPassword,shadowLastChange by self write by anonymou
s auth by * none
olcAccess: {1}to dn.base="" by * read
olcAccess: {2}to * by * read
olcLastMod: TRUE
olcRootDN: cn=admin,dc=ict
olcRootPW: {SSHA}gA82cCLDItWFzpXz4Ujt/8TVwUCnlrpR
olcDbCheckpoint: 512 30
olcDbIndex: objectClass eq
olcDbIndex: cn,uid eq
olcDbIndex: uidNumber,gidNumber eq
olcDbIndex: member,memberUid eq
olcDbMaxSize: 1073741824
OpenLDAP - Konfiguration von TLS
•
Standarmäßig läuft der Server ohne Verschlüsselung auf Port 389 (Zugriff via ldap://-URL).
Außerdem ist er lokal am Server auch mittels IPC erreichbar (Zugriff via ldapi://-URL).
•
Um LDAPS auf Port 636 oder STARTTLS verwenden zu können, müssen zuerst die nötigen
Zertifikate erstellt bzw. angefordert werden. Anschließend müssen im Konfigurations-DIT unter dem
DN „cn=config“ folgende Attribute gesetzt werden:
•
•
olcTLSCACertificateFile: Der Pfad zum CA-Zertifikat
•
olcTLSCertificateFile: Der Pfad zum Zertifikat des Servers, das gegenüber den Clients verwendet
wird
•
olcTLSCertificateKeyFile: Der Pfad zum privaten Schlüssel für das Zertifikat des Servers
Weiters muss in /etc/default/slapd bei SLAPD_SERVICES den Wert ldaps:/// hinzugefügt und der
Server neu gestartet werden.
Seite 111 von 139
OpenLDAP - Konfiguration von TLS - Fortsetzung
•
Um die Verwendung von TLS zu erzwingen, kann die Konfigurationsoption olcSecurity mit dem Wert
„tls=1“ verwendet werden. Dann können sich Clients nur mehr per TLS mit dem Server verbinden.
Achtung: Diese Option sollte nicht direkt auf „cn=config“ angewendet werden, sondern auf den DN
einer DIT-Datenbank!
•
Zum Konfigurieren von TLS kann folgende LDIF-Datei verwendet werden (Werte entsprechend
anpassen):
dn: cn=config
add: olcTLSCACertificateFile
olcTLSCACertificateFile: /etc/ssl/certs/ca-certificate.pem
add: olcTLSCertificateFile
olcTLSCertificateFile: /etc/ssl/certs/ldap-certificate.pem
add: olcTLSCertificateKeyFile
olcTLSCertificateKeyFile: /etc/ssl/private/ldap-certificate.key
-
•
Zusätzlich könnte man den Server so konfigurieren, dass er auch Client-Zertifikate verlangt
(Attribute olcTLSVerifyClient, olcTLSCRLFile und olcTLSCRLCheck).
OpenLDAP - Zugriffskontrolle
•
Die Standardkonfiguration erlaubt recht breiten Zugriff auf den während der Installation erstellten
DIT. Ohne Authentifizierung können z.B. alle Attribute bis auf userPassword und shadowLastChange
gelesen werden.
•
Im Produktivbetrieb sollte der Zugriff eingeschränkt werden, um größtmögliche Sicherheit und
Datenschutz zu gewähren.
•
Die Zugriffskontrolle wird über das Attribut olcAccess gesteuert, welches mehrfach vorkommen
kann. Für die vollständige Syntax und alle Möglichkeiten siehe man 5 slapd.access.
•
Da die Reihenfolge wichtig ist, sollten die Werte mit dem Präfix {Nummer} versehen werden (bei
LDAP-Objekten gibt es keine festgelegte Attributordnung).
•
Der Wert von olcAccess hat vereinfacht die Form to <Was> [ by <Wem> <Zugriffsrechte> ]+.
•
Beim Überprüfen der Zugriffsrechte werden die Attribute nach dem Präfix sortiert und sobald
sowohl <Was> als auch <Wer> zutrifft, werden die entsprechenden Zugriffsrechte angewandt.
OpenLDAP - Zugriffskontrolle - Was
•
Über <Was> wird festgelegt, auf welche Objekte sich die Zugriffsrechte beziehen.
•
Mögliche Werte dafür sind:
•
dn.<Bereich>=<Pattern>
Die Objekte werden auf Grund des DNs ausgewählt. <Pattern> ist ein Ausdruck, in dem auch die
Wildcard ‚*‘ vorkommen kann. <Bereich> gibt an, ob genau das Objekt ausgewählt wird (
dn.base), alle direkten Einträge unterhalb (dn.one), alle Einträge im Unterbaum (dn.subtree)
Seite 112 von 139
oder alle Einträge unterhalb (dn.children).
•
filter=<Filter>
Die Objekte werden auf Grund des LDAP-Filters ausgewählt.
•
attrs=<Attributlist>
Die Zugriffsrechte beziehen sich auf die kommaseparierte Liste von Attributen.
OpenLDAP - Zugriffskontrolle - Wem
•
Über <Wem> wird festgelegt, auf welche Clients, meist Benutzer, sich die Zugriffsrechte beziehen.
•
Einige mögliche Werte dafür sind:
•
dn.<Bereich>=DN
Funktioniert analog zur ähnlichen Angabe bei <Was> und wählt einen Client über einen DN aus.
•
*
Wählt alle Clienten aus.
•
anonymous
Wählt alle Clienten aus, die sich nicht authentifiziert haben.
•
users
Wählt alle Clienten aus, die sich authentifiziert haben.
•
self
Wählt das Objekt selbst aus, das über <Was> festgelegt wurde.
OpenLDAP - Zugriffskontrolle - Zugriffsrechte
•
Über <Zugriffsrechte> werden schließlich die Zugriffsrechte festgelegt.
•
Mögliche Werte dafür sind:
•
•
none: Kein Zugriff, auch keine Fehlermeldung (=0)
•
disclose: Kein Zugriff, aber Fehlermeldung (=d)
•
auth: Erlaubnis zum Zugriff während der Authentifizierung (=dx)
•
compare: Erlaubnis zum Vergleichen (=dxc)
•
search: Erlaubnis zum Verwenden von Suchfiltern (=dxcs)
•
read: Erlaubnis zum Lesen von Einträgen (=dxcsr)
•
write: Erlaubnis zum Schreiben (=dxcsrw)
•
manage: Vollzugriff (=dxcsrwm)
Wie man an den Rechten sieht, erlauben höhere Rechte automatisch alle niederen Rechte, d.h. read
erlaubt auch automatisch search, compare, auth und disclose.
Seite 113 von 139
OpenLDAP - Zugriffskontrolle - Beispiele
•
to * by * read
Alle haben Lesezugriff.
•
to attr=userPassword by self write by anonymous auth by * none
Clients, die als das Objekt authentifiziert sind, können das Attribut userPassword schreiben,
anonyme Benutzer können sich gegen das Attribut authentifizieren, alle anderen haben keinen
Zugriff.
•
to * by dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth manage
Ein über -Y EXTERNAL authentifizierter Benutzer mit der UID=0 und GID=0 hat Vollzugriff auf alle
Einträge.
OpenLDAP - Integration mit Kerberos
•
Um Clients via Kerberos am LDAP-Server zu authentifizieren, muss das Paket libsasl2-modulesgssapi-mit installiert werden. Dieses stellt die GSSAPI/Kerberos-Authentifizierung für SASL zur
Verfügung.
•
Als nächstes muss ein Principal ldap/FQDN@REALM für das LDAP-Service angelegt werden und in die
/etc/krb5.keytab exportiert werden (Achtung: Darauf achten, dass der Server Zugriff hat – er läuft
unter dem Benutzer „openldap“).
•
Anschließend wird der LDAP-Server neugestartet. Hat alles geklappt, so sollte nun GSSAPI als
unterstützte SASL-Methode in der Root DSE auftauchen:
$ ldapsearch -x -b '' -s
dn:
supportedSASLMechanisms:
base -LLL supportedSASLMechanisms
SCRAM-SHA-1
GS2-IAKERB
GS2-KRB5
GSSAPI
GSS-SPNEGO
DIGEST-MD5
CRAM-MD5
NTLM
OpenLDAP - Integration mit Kerberos - Fortsetzung
•
Zum Zwecke der Authentifizierung wird der Principal BENUTZER/INSTANZ@REALM auf einen DN
uid=BENUTZER/INSTANZ,cn=REALM,cn=gssapi,cn=auth abgebildet. Achtung: Der Teil cn=Realm wird
weggelassen, falls es das Standard-Realm ist.
•
Mit Hilfe des Befehls ldapwhoami kann geprüft werden, welcher DN aktuell zugeordnet ist.
•
Um über Kerberos angemeldete Clients entsprechenden Zugriff auf Objekte zu geben, muss man
deren DNs entweder direkt via olcAccess den Zugriff erlauben oder man bildet sie auf andere DNs
ab, die bereits Zugriff haben.
•
Die Abbildung auf einen DN erfolgt über die Konfigurationsoption olcAuthzRegexp. Der Wert hat die
Form REGEX ERSETZUNG. Im Ersetzungsstring können auch Gruppenreferenzen $1, $2, etc. verwendet
Seite 114 von 139
werden. Nach Änderungen muss der Server neu gestartet werden.
Beispiel für die Abbildung aller */[email protected] Principals auf das bei der Installation
angelegte DIT-Administrator-Objekt:
olcAuthzRegexp: uid=.*?/admin(,cn=HOST95.ICT)?,cn=gssapi,cn=auth cn=admin,dc=ict
OpenLDAP - Kerberosdatenbank, Sudoers, Autofs
•
Möchte man zur Authentifizierung Kerberos anstatt LDAP verwenden, so kann man einfach das
entsprechende PAM-Modul dafür verwenden. Allerdings muss man dann weiterhin zwei getrennte
Datenbanken (LDAP und Kerberos) vorhalten bzw. synchronisieren.
•
Die bessere Methode ist für Kerberos als Datenbankbackend LDAP zu verwenden. Dann können die
Schlüssel für Benutzer, Computer und Services im LDAP-Verzeichnis direkt bei den entsprechenden
LDAP-Objekten gespeichert werden. Eine Anleitung für die Einrichtung findet sich im Ubuntu
Kerberos and LDAP Guide und im Kerberos Admin Guide von MIT Kerberos.
•
Weiters ist es möglich, sowohl die sudo-Konfiguration als auch die autofs-Konfiguration in das LDAPVerzeichnis zu verlagern. Dazu müssen die entsprechenden Schema-Dateien in den LDAP-Server
geladen und dann die nötigen Objekte angelegt werden.
SSSD - System Security Services Daemon
•
SSSD ist ein Daemon, der Zugang zu auf entfernten Ressourcen gespeicherten
Identitätsinformationen und Authentifizierungsmöglichkeiten ermöglicht. Üblicherweise ist das die
Anbindung an einen LDAP- bzw. Kerberos-Server.
•
Es ist auch möglich, SSSD so zu konfigurieren, dass diese Informationen am lokalen System
gecached werden und damit auch bei Ausfall des Netzwerkes gearbeitet werden kann.
•
Weiters können mehrer Verwaltungsdomains verwendet werden, sprich, Informationen aus z.B.
mehreren LDAP-Servern.
•
Damit kann SSSD statt den Paketen libpam-krb5, libnss-ldap und libpam-ldap verwendet werden und
hat den Vorteil, dass alles über einen Daemon läuft und an einer Stelle konfiguriert werden kann.
•
Zur Verwendung muss das Paket sssd installiert werden. Zusätzlich sollten auch noch die Pakete
sssd-ldap (für die LDAP-Anbindung) bzw. sssd-krb5 (für die Kerberos-Anbindung) installiert werden.
SSSD - Konfiguration - Allgemein
•
SSSD wird über die Datei /etc/sssd/sssd.conf konfiguriert (siehe man 5 sssd.conf). Damit SSSD
diese Datei akzeptiert, müssen der Besitzer und der Gruppenbesitzer „root“ und die Rechte „0600“
sein.
•
Die Syntax orientiert sich am INI-Format, d.h. Sektionen werden mit „[Name]“ eingeleitet, darauf
folgen Schlüssel-Wert-Paare im Format „Schlüssel = Wert“. Kommentarzeilen sind alle Zeilen, die mit
einem Hash-Zeichen beginnen.
•
In der Sektion „[sssd]“ werden die globalen Einstellungen konfiguriert:
•
config_file_version: Gibt die Version der Datei an und muss vorhanden sein mit dem Wert „2“.
•
services: Gibt die Services an, die verwaltet werden sollen. Für uns interessant sind „pam“ und
Seite 115 von 139
„nss“, es gäbe z.B. auch noch „sudo“ und „ssh“.
•
•
domains: Enthält die Namen der zu verwenden Domains. Jede Domain muss in einer eigenen
Sektion konfiguriert werden.
In den Sektionen „[nss]“ und „[pam]“ können allgemeine Einstellungen zu diesen Services
konfiguriert werden. Bei „[nss]“ könnte hier z.B. der Wert des Home-Verzeichnisses eines Benutzers
modifiziert werden.
SSSD - Konfiguration - Domains
•
In den Domain-Sektionen können die einzelnen Verwaltungsdomains konfiguriert werden. Diese
Sektionen haben als Namen „[domain/DOMAIN_NAME]“.
•
Wichtige Optionen sind:
•
id_provider: Gibt an, von wo die Identitätsinformationen geholt werden. Mögliche Werte sind z.B.
„proxy“ (über einen NSS-Provider) und „ldap“ (aus einem LDAP-Verzeichnis).
•
auth_provider: Gibt an, wie die Authentifizierung gemacht wird. Mögliche Werte sind z.B. „proxy“
(für die Weiterleitung an ein PAM-Modul), „ldap“ (LDAP-Authentifizierung) und „krb5“ (KerberosAuthentifizierung).
•
chpass_provider: Gibt an, wie Passwortänderungen gemacht werden. Mögliche Werte sind z.B.
„proxy“ (für die Weiterleitung an ein PAM-Ziel), „ldap“ (um ein LDAP-Passwort zu ändern) und
„krb5“ (um ein Kerberos-Passwort zu ändern).
•
Die einzelnen Provider müssen natürlich noch entsprechend konfiguriert werden.
•
An Benutzernamen einer Domain kann optional „@DOMAIN_NAME“ angehängt werden, damit SSSD
nur diese eine Domain benutzt. Ansonsten wird die erste Domain, in der der Benutzername
vorkommt, verwendet.
SSSD - Konfiguration - LDAP
•
SSSD kann LDAP für Identitätsinformationen, Authentizifierung und Passwortänderungen benutzen.
•
Die Informationen im LDAP müssen entweder dem RFC2703, RFC2703bis oder dem Active Directory
Schema folgen. Allerdings können über Optionen alle benötigten Attribute auf andere Attribute
abgebildet werden. Damit könnten z.B. das Problem umgangen werden, wenn der Benutzername
nicht wie erwartet im Attribut „uid“, sondern im Attribut „username“ gespeichert ist.
•
Die wichtigsten Optionen sind (siehe man 5 sssd-ldap):
•
ldap_uri: Der oder die URIs der LDAP-Server.
•
ldap_search_base: Die Suchbasis (meist die Wurzel des abzufragenden DIT)
•
ldap_default_bind_dn: Der DN, mit dem sich SSSD gegen den LDAP-Server authentifizieren soll
•
ldap_default_authtok: Das Passwort für den DN
•
Wichtig: SSSD verweigert die Authentifizierung, wenn die Verbindung zum LDAP-Server nicht
geschützt ist, z.B. durch TLS.
•
Es ist natürlich auch möglich, SSSD über GSSAPI (Kerberos) am LDAP-Server zu authentifizieren.
Seite 116 von 139
SSSD - Konfiguration - Kerberos, Proxy
•
SSSD kann Kerberos für Authentifizierung verwenden.
Die wichtigsten Optionen sind (siehe man 5 sssd-krb5):
•
•
krb5_server: Der oder die Kerberos-Server
•
krb5_realm: Der Name des Kerberos-Realms
•
krb5_keytab: Die keytab-Datei, die zur Validierung der Tickets verwendet wird (Default ist
/etc/krb5.keytab; SSSD muss Zugriff darauf haben)
Der „proxy“-Provider für SSSD erlaubt die Kombination mit beliebigen NSS- bzw. PAM-Ziele. Es gibt
nur zwei Optionen:
•
proxy_lib_name: Der Name einer NSS-Bibliothek (z.B. „files“)
•
proxy_pam_target: Ein PAM-Target, an das die Authentifizierung delegiert wird
SSSD - Beispiel: Reine LDAP-Anbindung
[sssd]
services = nss, pam
domains = ICT
config_file_version = 2
[domain/ICT]
enumerate = true
id_provider = ldap
auth_provider = ldap
chpass_provider = ldap
ldap_uri = ldap://localhost
ldap_search_base = dc=ict
In dieser Konfiguration wird alles über den LDAP-Server abgewickelt.
SSSD - Beispiel: Kerberos mit lokalen Benutzern
[sssd]
services = nss, pam
domains = HOST95.ICT
config_file_version = 2
[domain/HOST95.ICT]
id_provider = proxy
proxy_lib_name = files
auth_provider = krb5
krb5_server = host95.ict
krb5_realm = HOST95.ICT
In dieser Konfiguration werden die Identitätsinformationen von den lokalen Dateien geholt und die
Authentifizierung über Kerberos erledigt.
Seite 117 von 139
OpenLDAP - Beispielszenario
•
Der LDAP-Server ist in einer Grundkonfiguration fertig und nun kann das LDAP-Verzeichnis
organisiert, i.e. hierarchisch gegliedert, und mit Objekten befüllt werden. Zum Beispiel könnte man
Äste für Organisationseinheiten erstellen und darunter Objekte speichern, die Computer, Benutzer
und Gruppen innerhalb dieser Organisationseinheiten beschreiben.
•
Im Beispielszenario werden wir zwei Organisationseinheiten, eine für Personen und eine für
Gruppen, definieren und dann einen Beispielbenutzer und eine Beispielgruppe hinzufügen.
•
Zum Abschluss wird SSSD so eingerichtet, dass sich ein LDAP-Benutzer am System einloggen kann.
OpenLDAP - Beispielszenario - Benötigte Objekte
dn: ou=users,dc=ict
ou: users
objectClass: organizationalUnit
dn: ou=groups,dc=ict
ou: groups
objectClass: organizationalUnit
dn: cn=ict-group,ou=groups,dc=ict
cn: ict-group
gidNumber: 20000
objectClass: posixGroup
dn: cn=ict,ou=users,dc=ict
uid: ict
uidNumber: 20000
gidNumber: 20000
cn: ict
sn: Nescio
givenName: Nomen
gecos: Nomen Nescio
objectClass: inetOrgPerson
objectClass: posixAccount
objectClass: shadowAccount
loginShell: /bin/bash
homeDirectory: /home/ict
OpenLDAP - Beispielszenario - Benötigte Objekte
•
Die Einträge werden mit folgendem Befehl dem Verzeichnis hinzugefügt:
$ ldapadd -x -D cn=admin,dc=ict -W -f /tmp/daten.ldif
•
Jetzt muss noch das Passwort für den Benutzer gesetzt werden:
$ ldappasswd -D cn=admin,dc=ict -x -W -S "cn=ict,ou=users,dc=ict"
Achtung: Zuerst wird das
Authentifizierungspasswort!
•
zu
setzende
Passwort
zweimal
abgefragt,
dann
erst
das
Nun können die Einträge auch abgefragt werden:
Seite 118 von 139
$ ldapsearch -xLLL -b dc=ict '(uid=ict)'
dn: cn=ict,ou=users,dc=ict
uid: ict
uidNumber: 20000
gidNumber: 20000
cn: ict
sn: Nescio
givenName: Nomen
gecos: Nomen Nescio
objectClass: inetOrgPerson
objectClass: posixAccount
objectClass: shadowAccount
loginShell: /bin/bash
homeDirectory: /home/ict
OpenLDAP - Beispielszenario - Systemeinbindung
•
Nachdem im LDAP-Verzeichnis Benutzer und Gruppen definiert sind, werden wir das System so
anpassen, dass diese auch am System aufscheinen (NSS) und Benutzer sich authentifizieren können
(PAM).
•
Dazu verwenden wir SSSD und passen die Datei /etc/sssd/sssd.conf entsprechend an. Folgender
Abschnitt muss hinzugefügt werden:
[domain/ICT]
enumerate = true
id_provider = ldap
auth_provider = ldap
chpass_provider = ldap
ldap_uri = ldap://localhost
ldap_search_base = dc=ict
Anschließend muss noch im Abschnitt „[sssd]“ die Domain aktiviert und der SSSD neu gestartet
werden.
•
Zum Testen, ob alles funktioniert hat, kann getent verwendet bzw. das Einloggen getestet werden.
Seite 119 von 139
Foliensatz 8
Paketfilter
Inhalt
•
Paketfilter/Firewall mit iptables
•
NAT mit iptables
•
iptables konfigurieren mit Puppet
Paketfilter
•
Ein Paketfilter verarbeitet Netzwerkpakete, d.h. er entscheidet auf Grund von bestimmten
Merkmalen eines Pakets und seiner Konfiguration, was mit einem Paket gemacht werden soll. Die
Palette reicht dabei von annehmen oder verwerfen bis hin zur Änderungen von Informationen im
Paket selbst.
•
Paketfilter werden z.B. zur Implementierung von Firewalls benutzt. Eine Firewall kann dabei der
Sicherung eines ganzen Netzwerks (externe Firewall) oder eines einzelnen Computers dienen.
•
Wenn ein einzelner Computer geschützt werden soll, so wird die Paketfilter-Software auf dem
Computer selbst installiert und der Administrator muss sicherstellen, dass Schadprogramme die
Paketfilter nicht manipulieren.
•
Eine externe Firewall hat den Vorteil, dass sie vor Manipulationen besser geschützt ist und bietet,
weil sie üblicherweise durch eine dezidierte Hardware implementiert ist, meist besseren Schutz und
höhere Geschwindigkeit.
•
Es gibt verschiedene Arten, wie eine Firewall Netzwerkzugriffe unterbinden kann, z.B. durch das
Sperren von bestimmten IP-Adressen (Internetschicht) oder das Sperren von bestimmten Ports oder
durch anderen Informationen (Transportschicht).
Paketfilter in Linux - netfilter
•
Die Paketfilterung in Linux wird durch das netfilter-Framework, das Teil des Linux-Kernels ist,
bewerkstelligt.
•
Dieses Framework ermöglicht neben der zustandslosen und zustandsorientierten Paketfilterung auch
Adressübersetzung (z.B. NAT), zusätzliche Paketmanipulationen (z.B. connection tracking) und
Logging.
•
Der für uns interessante Bestandteil des netfilter-Frameworks heißt iptables. Dieser umfasst
mehrere Kernelmodule, die die verschiedenen Funktionalitäten implementieren (dadurch kann das
Framework leicht erweitert werden), und ein gleichheißendes Programm zur Verwaltung der Regeln.
Seite 120 von 139
Paketfilter in Linux - netfilter - Fortsetzung
•
Die Implementierung der Paketfilter-Mechanismen direkt im Kernel hat den Vorteil, dass die IPPakete sehr schnell verarbeitet werden können.
•
Randnotiz: Der erste Paketfilter hieß ipfw, basierte auf BSD-Code und wurde 1994 implementiert.
Mitte 1998 wurde dann für Linux 2.2 ein neuer Paketfilter namens ipchains eingeführt, der dann von
iptables abgelöst wurde.
Aber auch die Tage von iptables sind gezählt, denn diese Implementierung soll durch die schnelleren
nftables abgelöst werden.
Links: Homepage des netfilter-Frameworks, Fruzentux iptables Tutorial, Linux 2.4 Packet Filtering
HOWTO, man iptables, man iptables-extensions.
iptables - Tabellen und Ketten
•
Mit Hilfe des iptables-Befehls werden Filterregeln in Filterketten (chains) hinterlegt, die
wiederum zu Tabellen (tables) gehören. Die Filterregeln legen fest, wie Pakete verarbeitet werden
sollen.
•
Die
standardmäßig
vorhandenen
/proc/net/ip_tables_names):
•
Tabellen
sind
(alle
vorhandenen
•
filter: Die Standardtabelle, in der man allgemeine Filter hinterlegen kann.
•
nat: Eine spezielle Tabelle für NAT (network address translation).
•
mangle: Eine spezielle Tabelle für Veränderungen an Paketen.
sieht
man
in
In der Standardtabelle filter gibt es immer die folgenden drei Filterketten:
•
INPUT: Für Pakete, die lokal zugestellt werden sollen.
•
FORWARD: Für Pakete, die der Computer weiterleiten soll.
•
OUTPUT: Für Pakete, die lokal generiert werden.
•
Zusätzlich zu den diesen Ketten können auch weitere Ketten angelegt werden.
•
Da die Tabellen im gesicherten Speicher des Kernels hinterlegt sind, muss man die Regeln beim
Start des Systems in den Kernel laden (z.B. mittles der Befehle iptables-save und iptablesrestore).
iptables - Durchlaufen der Tabellen und Ketten
Seite 121 von 139
Achtung: Nicht alle Ketten sind eingetragen!
Siehe auch: Traversing of tables and chains
iptables - Filterregeln und deren Verarbeitung
•
In einer Filter-Kette werden die eigentlichen Regeln hinterlegt, die der Reihe nach durchgearbeitet
werden.
•
Eine Regel besteht dabei aus einer oder mehreren Bedingungen und einem Ziel, das angibt, was
mit einem passenden Paket gemacht werden soll.
•
•
Es gibt sehr viele Bedingungen, die man verwenden kann. Meist braucht man aber nur einen
kleinen Teil davon.
•
Ein Ziel kann entweder der Name einer Kette sein (dann werden die Regeln dieser Kette der
Reihe nach abgearbeitet) oder ein spezielles Ziel (ACCEPT, DROP, …).
Passen alle Bedingungen einer Regel auf ein Paket, so wird diese Regel angewandt und zu dem in
der Regel definierten Ziel gesprungen. Falls eine Regel nicht passt, wird die nächste Regel in der
Kette probiert. Passen alle Regeln einer Kette nicht, so wird zum Standardziel der Kette (chain
policy, nur für eingebaute Ketten) gesprungen.
iptables - Chain Policy
•
Je nachdem, ob als Standardziel einer Kette ACCEPT oder DROP verwendet wird, spricht man von
einem Blacklist- oder Whitelist-Filterdesign.
•
Verwendet man eine Blacklist, so ist grundsätzlich alles erlaubt, was nicht explizit verboten wurde.
Daher ist das Standardziel ACCEPT und die Filterregeln bestimmen, welche Pakete abgelehnt
werden sollen.
•
Im Gegensatz dazu wird bei einer Whitelist von vorne herein nichts erlaubt. D.h. das Standardziel
ist DROP und die Filterregeln bestimmen, welche Pakete dennoch durchgelassen werden.
•
Wenn man davon ausgehen kann, dass es nur wenige, „falsche“ Pakete gibt, so eignet sich dafür eine
Blacklist. Obwohl der Whitelist-Ansatz meist ein wenig aufwändiger zu implementieren ist (z.B. muss
für jeden neuen Dienst zumindest eine Regel hinzugefügt werden), ist er inhärent sicherer und man
Seite 122 von 139
hat mehr Kontrolle.
iptables - Ziele
•
•
Es gibt drei eingebaute Ziele:
•
ACCEPT: Paket akzeptieren.
•
DROP: Paket verwerfen und keine Rückmeldung an den Sender schicken.
•
RETURN: Aktuelle Kette verlassen und bei der nächsten Regel der vorigen Kette weitermachen.
Weiters gibt es auch noch einige durch Erweiterungen verfügbare Ziele:
•
LOG: Informationen zum Paket in das Kernel-Log schreiben. Achtung: Es wird bei der nächsten
Regel weitergemacht!
•
REJECT: Paket verwerfen, aber zusätzlich ein Antwortpaket zurückschicken.
Mittels der Option --reject-with Typ wird festgelegt, welches Antwortpaket zurückgeschickt
wird, standardmäßig wird „Port nicht verfügbar“ (icmp-port-unreachable) verwendet.
iptables Befehl - Allgemeines
iptables, ip6tables - Administrieren der IPv4/IPv6 Paketfilter.
» Das sind die Programme, mit denen man die Paketfilter im Kernel verwalten kann. Man braucht
root-Rechte für das Ausführen.
» Es unterstützt alle Filtermethoden, die durch Kernel-Module bereitgestellt werden, d.h. man
braucht wirklich nur dieses Programm.
» Alle Unterbefehle (zum Erstellen/Löschen von benutzerdefinierten Ketten und Verwalten von
Ketten) sind ähnlich aufgebaut und unterstützen eine Unmenge von Optionen. Wir sehen uns die
Unterbefehle der Reihe nach an.
» Standardmäßig wird die filter-Tabelle benutzt.
» Globale Optionen:
•
-t TABELLE → Die angegebene Tabelle anstatt der filter-Tabelle verwenden.
•
-n → Keine Namensauflösung durchführen.
•
-v → Detailierte Ausgabe verwenden.
•
--line-numbers → Zeilennummer bei Regeln anzeigen.
iptables Befehl - Ketten verwalten
Optionen zum Verwalten von Ketten
» -L [Kette] → Anzeigen der Regeln der spezifizierten Kette oder von allen Ketten.
» -N Kette → Eine neue, benutzerdefinierte Kette anlegen.
» -F [Kette] → Alle Regeln der spezifizierten Kette oder aller Ketten löschen.
» -X [Kette] → Die spezifizierte oder alle benutzerdefinierten Ketten löschen (dürfen keine Regeln
enthalten und auch nirgends referenziert werden).
» -Z [Kette] → Die Zähler der spezifizierten Kette oder aller Ketten zurücksetzen.
» -P Kette Ziel → Das Standardziel der Kette definieren.
» # Zurücksetzen auf den Ursprungszustand
$ iptables -F
$ iptables -X
Seite 123 von 139
$
$
$
$
iptables
iptables
iptables
iptables
-Z
-P INPUT ACCEPT
-P FORWARD ACCEPT
-P OUTPUT ACCEPT
iptables Befehl - Regeln verwalten
Optionen zum Verwalten von Regeln
» -A Kette Regel → Anfügen einer Regel an eine Kette.
» -D Kette Regel|Zeile → Löschen einer Regel (durch Angabe der Regel oder der Zeilennummer).
» -I Kette [Zeile] Regel → Einfügen der Regel in die erste oder der spezifizierten Zeile.
» -R Kette Zeile Regel → Ersetzen der Regel in der spezifizierten Zeile.
» -j Ziel → Spezifiziert das Ziel einer Regel.
» # Einige Beispielaufrufe
$ iptables -A INPUT -p tcp -j
$ iptables -D INPUT -p tcp -j
$ iptables -I INPUT -p tcp -j
$ iptables -I INPUT -p udp -j
$ iptables -L INPUT
Chain INPUT (policy ACCEPT)
target
prot opt source
DROP
udp -- anywhere
DROP
tcp -- anywhere
DROP
DROP # oder: iptables -D INPUT 1
DROP
DROP
destination
anywhere
anywhere
iptables Befehl - Standardbedingungen
Nützliche Standardbedingungen für Regeln
» -p Protokoll → Angabe des Protokolls (z.B. tcp oder udp).
» -i Schnittstelle → Angabe der Netzwerkschnittstelle, über die das Paket hereingekommen ist
(z.B. lo oder eth0).
» -o Schnittstelle → Angabe der Netzwerkschnittstelle, über die das Paket versandt werden wird.
» -s Quelladresse → Angabe der Quell-IP oder des Quell-Netzes (z.B. 131.130.16.0/22).
» -d Zieladresse → Angabe der Ziel-IP oder Ziel-Netzes.
» Das Voranstellen eines Rufzeichens vor einer der obigen Bedingungen invertiert die Bedingung.
» -m Modul → Modul für erweiterte Bindungen verwenden.
» #
$
#
$
Alle Pakete
iptables -A
Alle Pakete
iptables -A
wegwerfen, außer die von einem bestimmten Netz
INPUT ! -s 131.130.16.0/22 -j DROP
an eine bestimmte IP wegwerfen
OUTPUT -o eth0 -d 131.130.16.5 -j DROP
iptables Befehl - Bedingungen für TCP/UDP/ICMP
Zusätzliche Bedingungen für TCP/UDP/ICMP
» -m tcp → Bedingungen für TCP-Pakete (wenn -p tcp)
•
--sport Port → Quellport
•
--dport Port → Zielport
•
--tcp-flags Maske Vergleich → Betrachtet alle über „Maske“ festgelegten Flags; alle in
„Vergleich“ gelisteten müssen gesetzt sein, die anderen fehlen.
•
--syn → Paket, bei dem das SYN-Flag gesetzt und RST-, ACK- und FIN-Flags nicht gesetzt sind
(erstes Paket bei Verbindungsaufbau)
» -m udp → Bedingungen für UDP-Pakete (wenn -p udp)
Seite 124 von 139
•
--sport Port → Quellport
•
--dport Port → Zielport
» -m icmp/icmp6 → Bedingungen für ICMP(v6)-Pakete (wenn -p icmp(6))
•
--icmp-type Typ, --icmpv6-type Typ → ICMP(v6)-Pakete des angegebenen Typs
» # Das erste Paket einer TCP-Verbindung akzeptieren
$ iptables -A INPUT -p tcp --tcp-flags SYN,RST,ACK,FIN SYN -j ACCEPT # äquivalent
zu: --syn
# Alle Pakete an TCP-Port 80 zulassen
$ iptables -A INPUT -p tcp --dport 80 -j ACCEPT
iptables Befehl - Bedingungen für den Verbindungsstatus
Zusätzliche Bedingungen für den Verbindungsstatus
» Wie anfangs erwähnt, kann in Filterregeln der Zustand einer Verbindung berücksichtigt werden.
Hinweis: Der Befehl conntrack aus dem gleichnamigen Paket erlaubt das Anzeigen der aktuell
verfolgten Verbindungen.
» -m state → Bedingungen für Verbindungsstatus
•
--state Status[,Status,...] → Verbindungsstatus muss einem der Werte entsprechen.
Mögliche Werte:
•
NEW → Paket baut eine neue Verbindung auf.
•
ESTABLISHED → Paket gehört zu einer aufgebauten Verbindung.
•
RELATED → Paket hat eine neue Verbindung aufgebaut, steht aber in Beziehung zu einer
bereits aufgebauten Verbindung (z.B. Datentransfer bei FTP).
•
INVALID → Paket gehört zu keiner bekannten Verbindung.
» # Alle Pakete, die zu einer aufgebauten Verbindung gehören, zulassen
$ iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables - Beispielkonfiguration
# Pakete von der lokalen Schnittstelle werden immer akzeptiert
$ iptables -A INPUT -i lo -j ACCEPT
# Pakete von aufgebauten Verbindungen werden erlaubt
$ iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
# Pakete zum Verbindungsaufbau an den OpenSSH-Server sind erlaubt
$ iptables -A INPUT -p tcp -m tcp --dport 22 --syn -j ACCEPT
#
$
$
$
Standardziele der Ketten zum Abschluss sinnvoll setzen
iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT ACCEPT
iptables - IP-Forwarding
•
Der Linux-Kernel kann, wie auch in der Grafik zu Beginn gezeigt, Pakete von einer Schnittstelle an
eine andere weiterleiten. Dazu muss aber der sysctl-Wert net.ipv4.ip_forward = 1 sein.
•
Die zur Weiterleitung bestimmten Pakete können dann in der FORWARD-Kette gefiltert werden.
Seite 125 von 139
•
Beispiel:
# Erlauben des Weiterleitens von Paketen, die an Port 22 gehen
$ iptables -A FORWARD -p tcp --dport 22 -j ACCEPT
iptables - NAT
•
Network Address Translation (NAT) wird verwendet, um einen Addressbereich auf einen anderen
abzubilden. Dies wird z.B. oft bei WLAN-Routern benutzt, um viele private IP-Adressen hinter einer
öffentlichen zu verbergen.
•
Man unterscheidet zwischen Source NAT (SNAT) und Destination NAT (DNAT). Mit Hilfe von
SNAT kann die Quelladresse/der Quellport, mit Hilfe von DNAT die Zieladresse/der Zielport eines
Pakets verändert werden.
•
Unter Linux wird NAT mittels iptables eingerichtet. Dafür gibt es eine eigene nat-Tabelle mit den
folgenden Standardketten:
•
PREROUTING: Zur Verarbeitung, sobald die Pakete von Netzwerk hereinkommen.
•
INPUT: Zur Verarbeitung von lokal zugestellten Paketen.
•
OUTPUT: Zur Verarbeitung von lokal erzeugten Paketen.
•
POSTROUTING: Zur Verarbeitung, bevor die Pakete ins Netzwerk gehen.
iptables - NAT - Fortsetzung
•
Weiters gibt es drei spezielle Ziele:
•
SNAT: Für SNAT, nur gültig in den POSTROUTING- und INPUT-Ketten
Mit --to-source [ipaddr][:port] kann die Quelladresse/der Quellport angegeben werden.
SNAT wird z.B. benutzt, um viele IP-Adressen hinter einer zu verbergen.
•
DNAT: Für DNAT, nur gültig in den PREROUTING- und OUTPUT-Ketten.
Mit --to-destination [ipaddr][:port] kann die Zieladresse/der Zielport angegeben werden.
DNAT wird oft zum Weiterleiten von Ports verwendet, d.h. ein Computer kann damit eingehende
Verbindungen an einen gewissen Port an einen anderen Computer weiterleiten:
$ iptables -t nat -A PREROUTING -p tcp --dport 12299 -j DNAT --to-destination
10.10.10.199:22
•
MASQUERADE: Nur gültig in der POSTROUTING-Kette.
Dieses Ziel ist eine Variante von SNAT, die automatisch die Quelladdresse der
Netzwerkschnittstelle benutzt, über die das Paket verschickt wird. Dies ist vor allem für
Netzwerkschnittstellen ohne statische IP-Adressen nützlich.
$ iptables -t nat -A POSTROUTING -s 10.10.10.0/24 -j MASQUERADE
iptables - Konfiguration mit Puppet
•
Um iptables mit Puppet zu verwalten, verwendet man am besten das puppetlabs/firewall Modul.
Dieses erlaubt die Nutzung aller iptables-Befehle, um den Packetfilter zu konfigurieren.
Seite 126 von 139
•
Die Regeln werden automatisch durch Benutzung des Pakets iptables-persistent dauerhaft
gespeichert.
•
Zuerst konfiguriert man das System so, dass alle nicht von Puppet verwalteten Regeln gelöscht
werden:
resources {'firewall':
purge => true,
}
•
Bei den Regeln, die über die Ressource firewall definiert werden, muss man im Namen am Anfang
eine Zahl angeben, welche benutzt wird, um die Regeln zu sortieren.
iptables - Konfiguration mit Puppet - Fortsetzung
•
Anschließend erstellt man eine Grundkonfiguration, damit man bei der Aktivierung der Regeln nicht
aus dem System gesperrt wird:
class firewall_pre {
Firewall {
require => undef,
}
firewall { '000 Akzeptieren von ICMP-Paketen':
proto => 'icmp',
action => 'accept',
}->
firewall { '001 Akzeptieren von Paketen von der Loopback-Schnittstelle':
proto
=> 'all',
iniface => 'lo',
action => 'accept',
}->
firewall { '002 Verwerfen von lokalen Paketen, die nicht auf der LoopbackSchnittstelle sind':
iniface
=> '! lo',
proto
=> 'all',
destination => '127.0.0.1/8',
action
=> 'reject',
}->
firewall { '003 Akzeptieren von Paketen von verwandten/aufgebauten Verbindungen':
proto => 'all',
state => ['RELATED', 'ESTABLISHED'],
action => 'accept',
}
}
•
Dann werden noch Regeln gebraucht, um die restlichen Pakete zu verwerfen:
class firewall_post {
firewall { '999 Verwerfen von allen Paketen:
proto => 'all',
action => 'drop',
before => undef,
}
Seite 127 von 139
}
•
Der letzte Schritt ist das Aktivieren der obigen Konfiguration:
Firewall {
before => Class['firewall_post'],
require => Class['firewall_pre'],
}
class { ['firewall_pre', 'firewall_post']: }
class {'firewall': }
•
Jetzt können die eigentlichen Regeln definiert werden:
firewall { "100 Pakete an den SSH-Server erlauben":
proto => 'tcp',
dport => 22,
action => accept,
}
firewall { "100 DNAT zur Portweiterleitung":
table => 'nat',
chain => 'PREROUTING',
proto => 'tcp',
dport => "12299",
jump => 'DNAT',
todest => "10.10.10.199:22",
}
firewall { "100 SNAT/MASQUERADE von Paketen aus dem internen Netz":
table => 'nat',
proto => all,
chain => 'POSTROUTING',
source => '10.10.10.0/24',
jump => 'MASQUERADE',
}
Seite 128 von 139
Foliensatz 9
Netzwerkdateisysteme NFS und
CIFS
Inhalt
•
Network File System (NFS)
•
Common Internet File System (CIFS)
Network File System (NFS)
•
Das Network File System (NFS) (definiert in RFC 1094, RFC 1813, RFC 7530 und RFC 5661)
wurde ursprünglich von Sun Microsystems entwickelt und erlaubt den Zugriff auf Dateien über ein
Netzwerk.
•
Am Server liegen die Dateien nicht in einer Datenbank oder etwas Ähnlichem, sondern sind in einem
normalen Dateisystem (z.B. EXT4) gespeichert.
•
Es gibt verschiedene Versionen von NFS. Derzeit kommen die Versionen NFSv3, NFSv4 und NFSv4.1
zum Einsatz. Hauptvorteile von NFSv4 sind:
•
•
Authentifikation von Benutzern, nicht nur Hostauthentifikation
•
Unterstützung von access control lists (ACLs) für erweiterte Zugriffsrechte
•
Datenübertragung nur mehr über TCP, weil das Protokoll nicht mehr zustandslos ist
•
Früher benötigte Serverdienste wie portmapper, rpc.mountd und rpc.lockd werden nicht mehr
gebraucht
Alle gängigen UNIX-/Linux-/BSD-Systeme unterstützen mittlerweile sowohl NFSv3 als auch NFSv4
und NFSv4.1. In aktuellen Windows-Versionen gibt es auch Unterstützung für NFSv3 und NFSv4.1.
NFSv4 - Überblick
•
Da NFSv4 gegenüber NFSv3 viele Vorteile bietet, sollte, wenn möglich, nicht mehr NFSv3 eingesetzt
werden. Dies wird dadurch erleichtert, dass NFSv4 in einem zu NFSv3 ähnlichen Modus ohne
Benutzerauthentifikation betrieben werden kann.
Wir betrachten ab jetzt nur mehr NFSv4, das meiste ist aber auch für NFSv3 gültig.
•
NFS basiert auf Open Network Computing (ONC) Remote Procedure Call (RPC). Das ist ein
System, mit dem Applikationen Nachrichten über das Netzwerk austauschen können. Dabei sieht es
für den Programmier so aus, als würde er nur lokal Nachrichten austauschen.
Seite 129 von 139
NFSv4 - Authentifizierung
•
Die Authentifizierung erfolgt über RPC und nicht direkt über NFSv4.
•
Der einfachste Mechanismus, und der einzig sinnvolle, der vor NFSv4 verfügbar war, ist AUTH_SYS.
Dabei werden einfach die UID, die primäre GID und die sekundären GIDs mitgeschickt. Damit kann
dann der Zugriff auf Dateien am Server gesteuert werden.
Da der Server aber nicht feststellen kann, ob der Benutzer sich am Client wirklich authentifiziert
hat, ist diese Variante nicht sicher und sollte nur verwendet werden, wenn sowohl das Netzwerk als
auch alle Rechner darin gesichert sind.
•
Mit NFSv4 wurde die Authentifizierung über GSS-API eingeführt, wobei sowohl Server als auch
Clients Kerberos V5 via GSS-API unterstützen müssen.
Man kann sich auf drei Arten via Kerberos verbinden:
•
Nur beidseitige Authentifizierung via Kerberos (krb5)
•
Beidseitige Authentifizierung via Kerberos und Integritätschecks (krb5i)
•
Beidseitige Authentifizierung via Kerberos und Verschlüsselung (krb5p)
NFSv4 - Abbilden von Benutzern und Gruppen
•
Nachdem jeder Datei ein Benutzer und eine Gruppe zugeordnet ist, müssen diese Informationen
auch per NFS übertragen werden.
•
Vor NFSv3 wurden einfach die UID und GID übertragen. Der Systemadministrator musste daher
sicherstellen, dass auf dem Server und den Clients die Zuordnung von Benutzer-/Gruppennamen zu
UIDs/GIDs übereinstimmt.
Außerdem konnte damit NFS nur eingesetzt werden, wenn es am Client überhaupt so etwas wie eine
UID gab.
•
Um diese beiden Probleme zu beheben, werden bei NFSv4 nicht mehr UID und GIDs über das
Netzwerk übertragen, sondern Zeichenketten der Form „user@domain“ bzw. „group@domain“.
Damit aber die Kompatibilität zu NFSv3 gewahrt bleibt, ist es weiterhin möglich, statt Namen UIDs
und GIDs zu übertragen (siehe RFC 7530, Sektion 5.9). Diese Möglichkeit besteht aber nur, wenn
nicht Kerberos verwendet wird und beide Seiten, Server und Client, sie unterstützen (was nicht der
Fall sein muss!).
NFSv4 - Abbilden von Benutzern und Gruppen unter Linux
•
Die NFS-Implementierung des Linux-Kernels unterstützt die Übertragung von UIDs und GIDs.
•
Standardmäßig ist diese Unterstützung aktiviert, d.h. es werden bei Verwendung von AUTH_SYS
UIDs und GIDs übertragen. Durch Änderung der Modulparameter nfs.nfs4_disable_idmapping
(für den Client) sowie nfsd.nfs4_disable_idmapping (für den Server) kann diese Unterstützung
aber deaktiviert werden.
•
Das Zuordnen von UID/GID zu einem Namen erfolgt durch einen ID-Mapping-Dienst am Client bzw.
Server. Unter Linux gibt es dafür zwei Möglichkeiten: die alte Variante mittels des rpc.idmapd
Daemons oder die neue mittels des nfsidmap Programms.
Standardmäßig wird die neue Variante verwendet und die alte nur dann, wenn die neue Variante
Seite 130 von 139
nicht konfiguriert ist.
•
Beide Varianten verwenden zur Konfiguration /etc/idmapd.conf. Dort solle man den Domain-Teil
festlegen, wenn er nicht der DNS-Domain entspricht.
NFSv4-Server einrichten
•
Es empfiehlt sich, dass am Server sowie auf den Clients die gleichen Benutzer die gleichen UIDs
besitzen. Dies ist zwar nicht mehr unbedingt nötig, beugt aber Problemen vor (vor allem, wenn
Kerberos nicht eingesetzt wird).
•
Unter Ubuntu werden alle nötigen Programme bei der Installation des Pakets nfs-kernel-server
installiert und nach der Installation laufen alle benötigten Dienste mit den Standardeinstellungen.
•
Da nur NFSv4 angeboten werden soll, muss in /etc/default/nfs-kernel-server bei
RPCMOUNTDOPTS die Optionen --no-nfs-version 3 --no-nfs-version 2 hinzugefügt und das
nfs-kernel-server Service neugestartet werden.
•
In /etc/idmapd.conf muss der Domainnname der NFS-Domain festgelegt werden (außer er
entspricht der DNS-Domain). Weiters sollen keine numerischen IDs unterstützt werden, daher
müssen die entsprechenden Kernelmodulparameter geändert werden, i.e. die Datei
/etc/modprobe.d/nfs.conf mit folgendem Inhalt anlegen:
options nfs nfs4_disable_idmapping=N
options nfsd nfs4_disable_idmapping=N
NFSv4-Server einrichten - Exports
•
Nachdem die Dienste entsprechend eingerichtet worden sind, muss dem NFS-Server noch mitgeteilt
werden, welche Verzeichnisse exportiert werden sollen. Dazu braucht man die Datei /etc/exports
und den Befehl exportfs.
•
In der Datei /etc/exports werden die Verzeichnisse mit den dazugehörigen Optionen eingetragen,
die man freigeben will. Jede Zeile enthält ein Verzeichnis und dann eine Liste von Rechnern (durch
Leerzeichen getrennt), die darauf zugreifen können. Direkt nach der Angabe von Rechnern können
Optionen in runden Klammern angegeben werden.
/srv/exports hostname1(rw,sync,no_subtree_check) hostname2(ro,sync,no_subtree_check)
•
Wichtig: Bei NFSv4 müssen (im Gegensatz zu NFSv3) alle Verzeichnisse unter einem
Wurzelverzeichnis liegen. Das heißt, wenn das Wurzelverzeichnis /srv/exports ist, müssen alle zu
exportierenden Verzeichnisse in diesem Verzeichnis liegen. Will man ein schon existierendes
Verzeichnis exportieren, so muss man ein bind-Mount machen.
NFSv4-Server einrichten - Exports Optionen
•
Einige wichtige Export-Optionen:
•
sec=Security → Authentifizierungsvariante angegben („sys“, „krb5“, „krb5i“ und „krb5p“)
•
rw → Lese- und Schreibzugriff ist möglich (sonst nur Lesezugriff)
•
sync → Synchroner Zugriff (Antwort von Server erst, nachdem Änderungen geschrieben worden
sind)
•
no_subtree_check → Keine Überprüfung von Unterverzeichnissen (sollte man fast immer
verwenden)
Seite 131 von 139
•
•
fsid=Wert → Angabe einer eindeutigen ID für das exportierte Verzeichnis (unter NFSv4 muss
man die Wurzel der exportierten Verzeichnisse mit fsid=root exportieren)
•
[no_]root_squash → Den Administrator (nicht) auf den anonymen Benutzer abbilden
Nach dem Eintragen der zu exportierenden Verzeichnisse müssen die Änderungen dem NFS-Server
mitgeteilt werden:
$ exportfs -rav
NFSv4-Server einrichten - Kerberos
•
Sowohl für den Server als auch für den Client wird ein Principal der Form nfs/FQDN@REALM in
/etc/krb5.keytab gebraucht.
•
In /etc/idmapd.conf muss das Kerberos-Realm als NFS-Domain angegeben werden.
•
Danach muss am Server das nfs-kernel-server Service neugestartet und am Client das rpc-gssd
gestartet werden. Die Services rpc-gssd bzw. rpc-svcgssd sind für die Authentifizierung via
GSS/Kerberos nötig.
•
Nun muss noch die Datei /etc/exports angepasst werden. Damit die Authentifizierung via Kerberos
verwendet wird, muss bei den exportierten Verzeichnisse bei der Option sec= zusätzlich entweder
krb5, krb5i oder krb5p angegeben werden.
NFS-Client einrichten
•
Der ID-Mapper am Client muss gleich wie am Server konfiguriert werden, d.h. die NFS-Domain muss
übereinstimmen.
•
Weiters muss auch der Modulparameter nfs.nfs4_disable_idmapping mit der Einstellung am
Server übereinstimmen.
•
Anschließend braucht man das Netzwerkdateisystem nur wie ein normales Dateisystem einhängen.
Die URIs, die NFS verwendet, haben die Form hostname:/Pfad/zu/Verzeichnis.
$ mount -t nfs4 server:/ /mnt
•
Um ein NFS-Verzeichnis mittels Kerberos zu mounten, muss als Mount-Option „sec=krb5“ oder eine
Variante davon verwendet werden.
Common Internet File System (CIFS)
•
Das Common Internet File System (CIFS), auch bekannt unter Server Message Block (SMB), ist,
wie NFS, ein Netzwerkdateisystem. Allerdings bietet es darüber hinaus auch noch andere
Möglichkeiten, zum Beispiel Druckerfreigaben.
•
Das Protokoll wurde ursprünglich Anfang der 1980er Jahre bei IBM entwickelt und später stark von
Microsoft weiterentwickelt. Änderungen im Protokoll müssen von Microsoft auf Druck der EU seit
einige Jahren veröffentlicht werden, damit andere als die Microsoftimplementierung ohne ReverseEngineering möglich sind.
•
Unter Unix-artigen Betriebssystemen gibt es seit 1992 die freie Software Samba, die die
Kommunikation über SMB bzw. CIFS ermöglicht. Die aktuelle Version von Samba ist Version 4, die es
nun auch ermöglicht, einen Active Directory-Domain Controller zu betreiben. Damit kann man mit
Samba ohne Microsoft-Server ein Windows-Netzwerk betreiben.
Seite 132 von 139
Samba-Server einrichten - Basiskonfiguration
•
Unter Ubuntu werden die benötigten Komponenten für den Server durch das Paket samba
bereitgestellt (ab Ubuntu 14.04 wird damit Samba 4 installiert).
•
Im Gegensatz zu NFS umfasst ein Samba-Server viel mehr Komponenten und ist dementsprechend
auch schwieriger aufzusetzen, auch wenn man nur die Netzwerkdateisystem-Komponente benutzen
will.
•
Die Konfigurationsdatei /etc/samba/smb.conf wird sowohl für die Konfiguration des Servers als
auch der Client-Programme verwendet. Es gibt eine Unmenge von einstellbaren Optionen. Die
Konfiguration von Samba als Active Directory-Domain Controller sprengt den Rahmen der Vorlesung,
wir werden uns nur mit der Freigabe von Dateien beschäftigen.
•
Wichtige Konfigurationsoptionen der Gruppe global:
•
workgroup → Der Name der Arbeitsgruppe bzw. der Domain
•
security → Bestimmt das verwendete Sicherheitsmodell, ist für unseren einfachen Fall auf user zu
setzen
Samba-Server einrichten - Shares konfigurieren
•
•
Konfigurationsoptionen für die Gruppe homes (erlaubt das automatische Exportieren der HomeVerzeichnisse der Benutzer unter deren Benutzernamen, falls aktiviert) bzw. für allgemeine Shares:
•
read only → Sollte no sein, wenn auch Schreibzugriffe möglich sein soll
•
guest ok → Anonymen Zugriff auf das Share erlauben
•
path → Das zu exportierende Verzeichnis (nicht nötig für die Gruppe homes)
Um ein Verzeichnis als Share zu exportieren, eine Optionengruppe mit dem Namen anlegen und
darin die nötigen Optionen setzen:
[home]
path = /home
guest ok = no
read only = no
•
Hinweis: Die geänderte Konfigurationsdatei kann mittels samba-tool testparm auf Fehler überprüft
werden.
•
Nach Änderungen an der Konfigurationsdatei müssen die Samba-Dienste neugestartet werden:
$ systemctl restart nmbd smbd
Samba-Server einrichten - Benutzer definieren
•
Samba benutzt für die Authentifikation von Benutzern eine eigene Datenbank oder, falls so
konfiguriert, einen LDAP-Server (Option passdb backend). Das heißt, dass die am System definierten
Benutzer nicht automatisch zum Zugriff auf den Samba-Server verwendet werden.
•
Damit ein Benutzer zugreifen kann, muss man ihn als Administrator in die Passwortdatenbank
mittels smbpasswd aufnehmen.
$ smbpasswd -a ict
New SMB password:
Seite 133 von 139
Retype new SMB password:
Added user ict.
Benutzer können später mit Hilfe dieses Programmes auch ihr Samba-Passwort ändern.
•
Das Programm pdbedit kann von root auch für die Verwaltung der Passwortdatenbank genutzt
werden:
$ pdbedit -x praxis # Benutzer löschen
$ pdbedit -a praxis # Benutzer hinzufügen
$ pdbedit -L # Benutzer auflisten
Samba-Client einrichten
•
Am Client-Rechner müssen die Pakete smbclient und cifs-utils installiert werden. Das erste stellt das
Programm smbclient zur Verfügung, das zweite erlaubt das Einhängen eines Samba-Shares mittels
mount.cifs.
•
Der Befehl smbclient agiert ähnlich wie ein FTP-Client-Programm und kann für die Interaktion mit
einem CIFS-Dateiserver verwendet werden.
$ smbclient -U ict -L //server # Auflisten aller Shares am Server
$ smbclient -U ict //server/home # Verbinden zum Share home
•
Um ein CIFS-Share in das Dateisystem einzuhängen, verwendet man den Befehl mount.cifs,
welcher wie der Befehl mount funktioniert.
Die wichtigsten Optionen sind dabei user, pass und dom (Arbeitsgruppenname bzw. Domain), wobei
das Passwort interaktiv abgefragt wird, wenn es nicht spezifiziert worden ist.
$ mount.cifs //host99.ict/home /mnt -o user=ict,dom=ICT
Password:
Ein Nachteil dieser Methode ist, dass nur ein Benutzer auf so ein Share zugreifen kann, weil beim
Mounten der Benutzername explizit angegeben werden muss.
Samba-Server einrichten - Kerberos
•
Soll die Authentifizierung am CIFS-Server statt über Benutzername und Passwort mittels Kerberos
funktionieren, so hat man prinzipiell zwei Möglichkeiten:
•
Man richtet Samba als komplette Active Directory Domain ein. Dies erfordert mehr Aufwand und
ist auch komplizierter.
•
Oder man verwendet wirklich nur die Authentifizierung via Kerberos und sonst keine
zusätzlichen Komponenten von Samba.
Diese Variante betrachten wir. Achtung: Bei dieser Variante ist aber ein Anmelden mit Passwort
nicht mehr möglich!
•
Es muss ein Kerberos-Principal cifs/FQDN@REALM erstellt werden und am Server in die
/etc/krb5.keytab exportiert werden.
•
Weiters muss die Samba-Konfiguration folgendermaßen angepasst werden (statt „ICT“ den richtigen
Kerberos-Realm einsetzen):
workgroup = ICT
Seite 134 von 139
realm = ICT
security = ads
kerberos method = dedicated keytab
dedicated keytab file = /etc/krb5.keytab
Samba-Server einrichten - Kerberos - Fortsetzung
•
Jetzt kann auf die Shares des Servers nur mehr mittels Kerberos (oder als anonymer Benutzer, falls
eingestellt) zugegriffen werden. Für smbclient verwendet man die Option -k (zuvor ein KerberosTicket holen):
$ smbclient -L //server -k
•
Hat man Kerberos aktiviert, so ist es auch möglich, Shares mit der Option multiuser zu mounten.
Damit kann ein CIFS-Share einmal z.B. beim Start des Computer gemountet werden und die
Benutzer können mit ihren eigenen Rechten darauf zugreifen (so wie bei NFSv4).
Dazu legt man fürs Mounten am besten einen eigenen Systembenutzer cifs-mount am CIFS-Server
an, erzeugt einen Kerberos-Principal mit zufälligem Schlüssel für diesen Benutzer und exportiert
diesen Schlüssel in die /etc/krb5.keytab-Datei am Client.
Anschließend kann als Administrator das Share so gemountet werden:
$ mount -o sec=krb5,dom=ICT,multiuser,user=cifs-mount //server/share /mountpoint
Seite 135 von 139
Foliensatz 10
Verschiedenes
Inhalt
•
Webserver mit Apache
•
Druckserver mit CUPS
•
Überblick: DHCP- und DNS-Server
•
Überblick: Sicherheit
Webserver
•
Man könnte sich die Welt heutzutage kaum mehr ohne das World Wide Web vorstellen. Das Web ist
ein Teil des Internets und besteht aus Hypertext-Dokumenten, die durch Hyperlinks miteinandern
verbunden sind.
•
Grundlage für den Datenaustausch ist das Hypertext Transfer Protocol (HTTP; definiert in RFC 1945,
RFC 2616 und RFC 7540) bzw. die sichere Variante HTTPS (definiert in RFC 2818).
•
Um auf Inhalte im Web zuzugreifen, verwendet man im Allgemeinen einen Webbrowser. Dieser
verbindet sich dann über HTTP mit einem Webserver und lädt die angeforderten Dokumente.
•
Gerade im Bereich der Webserver haben Unix-artige Betriebssysteme eine Vorrangstellung, speziell
auch Linux. Und der Webserver schlechthin ist der Apache HTTP Server, der freie Software ist.
Andere oft benutzte Webserver sind nginx und Microsoft Internet Information Services (IIS).
Apache HTTP Server
•
Der Apache HTTP Server ist modular aufgebaut, d.h. man braucht nur die Komponenten installieren,
die man auch wirklich verwendet, was Ressourcen schont. Zudem ist er sehr stabil und schnell.
•
Einige Funktionen des Servers:
•
Virtual Hosts zur Bereitstellung von Websites verschiedener Domänen
•
Verschlüsselung der Daten mittels SSL (HTTPS-Protokoll) mittels mod_ssl
•
Manipulieren von HTTP-Kopfdaten (mod_headers) oder URLs (mod_rewrite)
•
Einbinden dynamischer Inhalte mittels CGI, FastCGI, oder anderen Modulen (z.B. mod_passenger
für die Programmiersprache Ruby)
•
Verschiedene Authentifizierungsmodule
•
Unterstützung von zusätzlichen Protokollen wie WebDAV
Seite 136 von 139
Apache HTTP Server einrichten 1
•
Die Installation des Servers erfolgt mittels des Pakets apache2. Damit sind auch die wichtigsten
Module bereits vorhanden.
•
Die Konfigurationsdateien befinden sich im Verzeichnis /etc/apache2. In diesem Verzeichnis
befinden sich mehrere Dateien und Verzeichnisse, unter anderem:
•
apache2.conf → Die Hauptkonfigurationsdatei
•
conf-available/ → Verzeichnis für zusätzliche Konfigurationen
•
conf-enabled/ → Symlinks nach conf-available/ für die aktivierten Konfigurationen
•
mods-available/ → Konfigurationsdateien für die verfügbaren Module
•
mods-enabled/ → Symlinks nach mods-available/ für die aktivierten Module
•
sites-available/ → Konfigurationsdateien für einzelne Websites
•
sites-enabled/ → Symlinks nach sites-available/ für aktivierte Websites
•
Das (de)aktivieren von Konfigurationen, Modulen und Webseiten kann entweder händisch durch
Setzen der entsprechende Links gemacht werden oder über die Progamme a2enconf, a2disconf,
a2enmod, a2dismod, a2ensite und a2dissite.
•
Das Standard-Webserver-Verzeichnis ist /var/www/html. Alle darin vorhandenen Dateien können
über den Webserver abgefragt werden.
Apache HTTP Server einrichten 2
•
Die Standardkonfiguration ist für einfache Websites, die nur statische Dateien benutzen,
ausreichend. Falls man auch dynamische Webseiten generieren will, muss man die entsprechenden
Module nachinstallieren (z.B. das Paket libapache2-mod-php5 für die Programmiersprache PHP5).
Nicht vergessen die Module mit Hilfe von a2enmod zu aktivieren!
•
Die Apache Dokumentation liefert zu allen Modulen und Einstellungen genaue Informationen und
auch Anwendungsbeispiele. Falls etwas unklar ist, sollte man dort als erstes nachsehen.
Druckserver
•
In einer Netzwerkumgebung bzw. auf einem Mehrbenutzersystem gibt es an das Drucksystem
spezielle Anforderungen, z.B.:
•
Druckaufträge von Benutzern dürfen nicht durcheinander geraten.
•
Druckaufträge sollen nach Priorität abgearbeitet werden.
•
Festlegen von erzwungenen Richtlinien soll möglich sein.
•
Diese Anforderungen können durch die Benutzung eines Druckserver erfüllt werden. Dabei werden
Druckaufträge nicht direkt an den Drucker geschickt, sondern zuerst an eine Warteschlange
(Queue) des Druckservers. Dieser arbeitet die Warteschlange nach dem FIFO-Prinzip (und/oder
anderen Kriterien, z.B. Druckpriorität) ab.
•
Unter Mac OS X und Unix/Linux wird CUPS als Standarddruckserver verwendet. CUPS unterstützt
die meisten gängigen Drucker sowie das Internet Printing Protocol (IPP), um die Druckdienste
über ein Netzwerk anbieten zu können.
•
Andere Druckserver unter Linux sind lpd/lpr (ursprünglich von BSD) und das neuere lprng, welche
beide das LPD-Protokoll verwenden. Auch Samba kann als Druckserver fungieren.
Seite 137 von 139
CUPS
•
Die Installation des Servers erfolgt mittels des Pakets cups. Damit ist alles für die Verwendung
installiert. Zusätzliche Druckertreiber finden sich in printer-driver-* Paketen.
•
Die Konfigurationsdateien befinden sich im Verzeichnis /etc/cups, die wichtigsten sind:
•
cupsd.conf → Konfigurationsdatei für den Druckserver
•
printers.conf → Konfigurationsdatei für die Drucker
•
ppd/ → Verzeichnis mit PPD-Dateien für jeden Drucker
•
Über das Paket cups-bsd sind die Programme lpr, lprm und lpq verfügbar, die die LPD-Befehle
emulieren und so den Umstieg auf CUPS vereinfachen.
•
Nach dem Starten des Serverdienstes cupsd kann man den Druckserver über eine Webschnittstelle
auf Port 631 administrieren (standardmäßig nur vom eigenen Rechner aus). Das Programm lpadmin
erlaubt die Konfiguration auf der Kommandozeile.
CUPS - Konfiguration
•
Die Syntax der Konfigurationsdatei cupsd.conf ähnelt der von Apache. In ihr werden allgemeine
Servereinstellungen getroffen und man kann auch genau festlegen, welche Benutzer/Gruppen auf
welche Teile der Webschnittstelle zugreifen können.
•
Wichtige Einstellungen:
•
•
Listen → IP-Adresse und Port, auf dem der Server lauschen soll.
•
Browsing → Definiert, ob Drucker über das Netzwerk erreichbar sein sollen.
•
SystemGroup → Benutzergruppen, die den Server administrieren dürfen (definiert in cupsfiles.conf)
Die Drucker fügt man am einfachsten über die Webschnittstelle hinzu. Benötigt werden dafür
zumindest folgende Informationen:
•
Verbindung zum Drucker (USB, seriell, parallel, LPD, AppSocket, IPP, SMB)
•
Name des Druckers
•
PPD-Datei oder Auswahl einer PPD-Datei über Marke und Modell des Druckers
DHCP- und DNS-Server
•
Wir haben die Konfiguration von DHCP bzw. DNS auf Clientseite betrachtet, aber nicht die
zugehörigen Serverdienste.
•
Der am weitesten verbreitete DHCP-Server ist DHCP des Internet Systems Consortium. Er wird
mittels des Pakets isc-dhcp-server installiert, Details zur Konfiguration finden sich in der Ubuntu
Dokumentation.
•
Der bekannteste DNS-Server ist BIND des Internet Systems Consortium. Er wird mittels des Pakets
bind9 installiert, Details zur Konfiguration finden sich in der Debian Wiki und in der Ubuntu
Dokumentation.
•
Für kleinere Netze wird oft dnsmasq als DHCP- und DNS-Server eingesetzt. Dieser Server ist nicht
so ausgiebig konfigurierbar, hat aber eine gute Standardkonfiguration und reicht in vielen Fällen
aus.
Seite 138 von 139
Sicherheit
•
Hardware physisch schützen (ev. Zutrittskontrolle, BIOS/UEFI mit Passwort sichern, etc.)
•
Benutzerauthentifikation über PAM zentral erledigen.
•
Passwort-Policy festlegen (z.B. mindestens acht Zeichen, davon eine Ziffer und ein Sonderzeichen;
siehe auch z.B. Passwort-Policy des ZID).
•
Login von root über OpenSSH nur mit Schlüssel erlauben.
•
Die Dateien /etc/hosts.{allow,deny} für Host-basierte Zugriffskontrolle verwenden (siehe man
hosts_access).
•
Eine Firewall mit iptables erstellen, die nur die benötigten Ports für Verbindungsanfragen von außen
zulässt.
•
Für Netzwerkdienste wenn möglich SSL oder TLS verwenden.
•
Nur die unbedingt notwendigen Programme installieren (je mehr Programme, desto mehr
Angriffsmöglichkeiten bietet man).
•
Dateien/Verzeichnisse mit den richtigen Zugriffsrechten versehen.
•
Auf mobilen Datenträgern
verschlüsseln.
verschlüsselte
Dateisysteme
verwenden
oder
einzelne
Dateien
Seite 139 von 139

Alle Unterlagen in einem PDF - Fakultät für Mathematik

Transcription

Similar documents

PDF-Version

Modellierungsbeschreibung

Technische Praxis der Computersysteme Teil 2-1

PDF-Version

Grundlagen, TCP/IP, Proxy, Firewall

Netzwerkgrundlagen - der Online Plattform der VHS Hagen

IP-Adressen - Osna-net

tec_Linux Server

Kommunikationsnetze I