PDF-Version

Transcription

PDF-Version

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.
ICT-Infrastruktur für Bildungsaufgaben | Sommersemester 2016 | Version: 2016-04-02 17:10
Seite 1 von 16
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 2 von 16
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 3 von 16
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 4 von 16
•
/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 5 von 16
•
•
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 6 von 16
•
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 7 von 16
/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 8 von 16
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 9 von 16
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 <perex@perex.cz>
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 10 von 16
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 11 von 16
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 12 von 16
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 13 von 16
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 14 von 16
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 15 von 16
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 16 von 16

PDF-Version

Transcription

Similar documents

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

HIQuad B 4235 Datenblatt

R-Studio 3.5 - Data Recovery