LPIC

Ich bereite mich auf die Prüfung zu den Linux-Zertifikaten LIPC vor. Dabei arbeite ich nach den Büchern von Peer Heinlein "LPIC-1 Vorbereitung auf die Prüfung des Linux Proffesional Institute" (5.Auflage) Verlag open source PRESS ISBN 978-3-941841-82-6 und von Harald Maaßen "LPIC-1 Sicher zur erfolgreichen Linux-Zertifizierung" erschienen im Rheinwerk Verlag Bonn ISBN 978-3-8362-3527-3. Ich notiere für mich wichtige Dinge und Ergänzungen und erhebe keinen Anspruch auf Vollständigkeit ;-)

Montag, 16. Mai 2016

101.1 virtuelles Dateisystem sysfs und udev, hald, dbus

virtuelles Dateisystem sysfs

Exportiert Informationen bezüglich der Kernelmodule aus dem Verzeichnis /sys
Darstellung proszessrelevanter Informationen strukturiert und einheitlich aufbereitet
Jedes Unterverzeichnis repräsentiert ein Treibermodell des laufenden Kernel
Viele symbolische Links innerhalb der Verzeichnisse um den Zusammenhang der verschiedenen Geräte darzustellen
/sys wird dynamisch generiert und enthält somit keine überflüssigen Informationen -> Ressourcenverbrauch auf Minimum
wichtige Grundlage für udev und HAL

udev, hald und dbus

hald (repräsentiert) Hardware Abstraction Layer (HAL) -> Daemon
hald informiert dbus darüber, wenn ein Wechsellaufwerk gesteckt und entfernt wird -> sichtbar: Zeichen für das Laufwerk erscheint z.B. im Launcher
udev Gerätemanager, der in modernen Kernelversionen /dev verwaltet, indem sich nur tatsächlich angeschlossene Geräte befinden

101.1 USB - Universal Serial Bus (TOTAL veraltet) USB wird heute über udev verwaltet

USB-Host-Controller-Typen USB 1.1 (Übertragungsrate 2MB/s)

OHCI (Open Host Controller Interface) -> Treiber usb-ohci.o
UHCI (Universal Host Controller Interface) -> Treiber usb-uhci.o

USB 2.0 (Übertragungsrate 480MB/s) -> Treiber usb-ehci.o (EHCI Enhanced Host Host Controller Interface)
USB-Klassen: nachdem der richtige Treiber für den passenden Controller geladen wurde, müssen nun die entsprechenden Klassentreiber geladen werden

HID -> Human Interface Devices: Maus, Tastatur. Treiber hid.o
Massenspeicher -> USB-Sticks, Festplatten. Treiber usb-storage.o
Kommunikationsgeräte -> Modems u.a.
Audiogeräte -> Wavetables
Infrarotgeräte
Bluetooth
Drucker

Wurde ein Gerät initialisiert wird unter /proc ein Verzeichnis für dieses Gerät angelegt, worunter es ab dann erreichbar ist (binäre Form, nicht einsehbar -> nur über lsusb)
lsusb Aufruf aller angeschlossenen USB-Geräte

-t Tree-Ausgabe
-d <Vendor-ID> -v Ausgabe zu einem bestimmten Gerät

Treiber laden, wenn Gerät angesteckt wird; Treiber entladen, wenn es wieder entfernt werden soll -> Treiberverwaltung automatisieren: Zwei Mechanismen stehen zur Verfügung
usbmgr dieser Daemon kann ausschließlich USB-Geräte verwalten.

Wird ein USB-Gerät angeschlossen, wird die Vendor ID und Product ID übermittelt (lsusb).
usbmgr lädt nun die korrespondierenden Treiber aus der /etc/usbmgr/usbmgr.conf in den Arbeitsspeicher und führt ihn aus. Die Datei usbmgr.conf muss in regelmäßigen Abständen aktualisiert werden, damit auch neue Hardware erkannt werden kann
/etc/usbmgr/preload.conf enthält Treiber, die schon beim Systemstart mit geladen werden
/etc/usbmgr/host enthält die Namen des Treibers für den Host (usb-ohci, usb-uhci oder usb-ehci

hotplug dieser Daemon ist die bessere Wahl zur Verwaltung der USB-Geräte, da er zusätzlich auch PCMCIA-Karten und Fire-Wire Geräte verwalten kann.

Übermittlung der Daten nach Anschluss des Gerätes an hotplug.
In /etc/hotplug befinden sich zu den Geräte passende Skripte, welche die Installation der Treiber übernehmen.

Coldplug und Hotplug

Hotplug kann im laufenden Betrieb gesteckt und entnommen werden

PCMCIA Karten
Fire-Wire- und USB-Geräte
Konfigurationsdateien unter /etc/hotplug

Coldplug hier muss das System zum Einbau runter gefahren sein

101.1 Der PCI-Bus

PCI-Bus -> Peripheral Component Interconnect Bus ist ein 32-Bit-System, inzwischen auch 64 Bit
Verwendung: Erweiterungskarten auf Hauptplatine stecken (Onboard-Karten: Soundkarte, Grafikkarte, etc.)
IDE Controller auf Hauptplatine ist ebenfalls an den PCI-Bus angeschlossen
lspci Auflistung des PCI-Bus. Auch der Komponenten, die noch kein Kernelmodul geladen haben.

-vvv ermöglicht eine Detailausgabe in gewünschter Auflösung
-t Tree-Darstellung

lspci arbeitet mit /proc/bus/pci (Auswertung aller Dateien und übersichtliche Darstellung der Informationen)

101.1 Ressourcen für Hardwarekomponenten

Prüfung der aktuellen Konfiguration der Hardwareressourcen über /proc
/proc ist kein Verzeichnis im eigentlichen Sinn, sondern bildet Parameter des Kernels ab
Abfrage der Hardwarekomponenten über lshw
Abfrage des Kernels ebenfalls möglich lsmod
/proc/interrupts Information der verwendeten Interrupts, die vom Kernel bereits registriert wurden (Hardware, die noch kein Kernelmodul geladen hat, wird hier nicht angezeigt);

1. Spalte: IRQ Nummer
2. Spalte: Angabe des Handler, den die CPU verwendet (gibt es mehrere CPUs, sind entsprechend mehr Spalten vorhanden)
3. Spalte: der verwendete Interrupt-Typ
4. Spalte (unter Ubuntu 5.Spalte): Angabe der Treiber, die diesen IRQ nutzen (kommagetrennt)
Es werden in den realen Dateien wesentlich mehr IRQs aufgeführt, als die beschriebenen 15. Unter Ubuntu habe ich 17 nummerierte und 19 buchstabenbezeichnete IRQs zusätzlich. Unter RedHat sind es 7 nummerierte und 15 buchstabenbezeichnete IRQs. Warum?

/proc/ioports Information zu den verwendeten I/O Adressen der Hardwarekomponenten, die entsprechend der Interrupts ebenfalls über ein Kernelmodul registriert sein müssen
/proc/dma Liste der DMA Kanäle die von den Geräten verwendet werden (unter Ubuntu nicht mehr vorhanden, DMA scheint ein veraltetes System zu sein?!)
/proc/pci veraltetes Verzeichnis, enthielt früher Informationen über den PCI Bus -> heute sind diese Informationen unter /proc/bus/pci zu finden
SCSI Geräte werden in der /proc/scsi abgebildet, aber mit anderen Bezeichner als die IDE Geräte
Gerätedateien der SCSI Geräte werden nicht mit der SCSI-ID oder der Unit Number (LUN) verknüpft, sondern die Position am Bus ist hier maßgeblich (/dev/sda für erste Platte am Bus)
USB Geräte unter Linux werden ebenfalls als SCSI Geräte gehandhabt
https://wiki.ubuntuusers.de/Systeminformationen_ermitteln/

101.1 Modulkonfigurationsdateien

modules.dep Darstellung der Abhängigkeiten zwischen allen Modulen. Trennung der Module durch ":" Gibt es keine Abhängigkeiten, bleibt es hinter dem ":" leer
/proc/sys/kernel Ablage der Konfigurationsdateien des Kernels während des laufenden Betriebs.

Einsehen der Dateien z.B. mit cat.
Dateinamen sind zumeist selbsterklärend.
Änderungen an diesen Dateien gehen bei Neustart verloren, da die hier abgelegten Dateien nicht auf der Festplatte abgelegt werden, sondern den Arbeitsspeicher darstellen

/usr/src/ Quelle der zum Kernel gehörenden Dateien und Verzeichnisse.

Ein Verzeichnis für jede Kernelversion, die die genaue Versionsnummer enthält (per Softlink auch unter /usr/src/linux zu finden).
Unter Ubuntu wird kein /usr/src/linux Verzeichnis angelegt, sondern es wird ein Verzeichnis parallel zu dem Kernel-Verzeichnis angelegt, wo der Kernelbezeichnung ein "linux-" vorangestellt wird. Dort befinden sich dann die Softlinks
Statische Teil des Kernels befindet sich in /boot. Hier sollte sich im Normalfall der Softlink vmlinuz befinden, der auf den tatsächlichen Namen des Kernels verweist (bei Verwendung mehrer Kernel und distributionsabhängige Unterschiede denkbar)

/lib/modules für jeden installierten Kernel ein Unterverzeichnis.

Seit Version 2.4 erst Unterverzeichnis Kernel
Dann die Verzeichnisse mit den jeweiligen Kategorien, z.B.

fs -> Dateisystem
net -> Netzwerkkartenmodule
scsi -> SCSI-Adaptermodule
video -> Grafikadaptermodule.

In diesem Verzeichnis befindet sich ebenfalls die modules.dep.
Moduldateien, die durch den Kompiler in ausführbare Dateien umgewandelt wurden enden auf .ko (Kernel-Objekt, früher nur o für Objekt)

/dev sowohl physikalische als auch logische Laufwerke werden unter Linux als Gerätedateien unter /dev dargestellt. Nicht Festplattenverzeichnis, sondern Darstellung des Geräts im Kernel (Geräte werden ins Userland exportiert) Gerätedateien sind Prüfungsrelevant!!

Geräte an IDE Bus: Bezeichnung durch /dev/hda - /dev/hdd
/dev/hda -> Primary Master
/dev/hdb -> Secondary Master
/dev/hdc -> Primary Slave
/dev/hdd -> Secondary Slave
Buchstaben a - d beschreiben die Position des Geräts am Controller
Aufgrund des Bezeichners können keine Rückschlüsse auf das Gerät getroffen werden (CD-ROM Laufwerk, Festplatte, DVD-Laufwerk)
Meisten (E)IDE-Controller verfügen über zwei Kanäle (Primary IDE, Secondary IDE), an die jeweils zwei Geräte (Master, Slave) angeschlossen werden können
IDE-RAID Conroller können mehr Geräte verwalten
wird z.B. ein CD-ROM Laufwerk als Secondary Master angeschlossen, wird ein Softlink von /dev/cdrom nach /dev/hdc erzeugt
Geräte an SCSI Bus: Bezeichnung erfolgt durch /dev/sda - /dev/sdd
SATA Festplatten werden wie SCSI-Geräte gehandhabt
Achtung!!! Unter bestimmten Derivaten werden auch IDE-Festplatten mit /dev/sdx bezeichnet z.B. unter Ubuntu und RedHat
Gerätedateien für Partitionen: wegen dem Aufbau des Master-Boot-Records und der darin enthaltenen Partitionstabellen, kann eine Festplatte max. vier Partitionen enthalten.
Unterscheidung zwischen primärer und erweiterten Partition

primäre Partition ist direkt ansprechbar, bis zu vier primäre Partitionen sind möglich
erweiterte Partition stellt einen Container für weitere logische Partitionen dar, ist aber nicht direkt ansprechbar. Es kann max. eine erweiterte Partition angelegt werden. IDE Gerät -> bis zu 60 logische Partitionen innerhalb möglich. SCSI Gerät -> nur bis zu 12 logische Partitionen

Primäre und erweiterte Partitionen werden von 1-4 durchnummeriert
Die erste logische Partition bekommt die Ordnungszahl 5, egal wie viele primäre und erweiterte Partitionen angelegt wurden
/dev/hda1 -> erste primäre Partition auf dem primary Master
/dev/hda2 -> zweite primäre Partition
/dev/hda3 -> .../dev/hda5 -> erste logische Partition
/dev/hda6 -> weitere logische Partition, usw.
Nach der Partitionierung sind genau n-1 Partitionen nutzbar, wenn eine erweiterte Partition angelegt wurde
Unterscheidung zwischen Laufwerken und Partitionen beachten (/dev/hda, hdb, hdc, hdd => /dev/hda1, hda2, hda3....)
Partition der SCSI Laufwerke erfolgt nach dem gleichen Prinzip
weitere Laufwerke und ihre Bezeichner:

/dev/scdX SCSI-CD/DVD Laufwerke
/dev/drX SCSI-raw ermöglicht direkten Zugriff auf ein Device (z.B. wichtig bei Brennern, um über das raw-Interface die zu brennenden Daten zu übermitteln)dev/sda3)
/dev/sgX SCSI generic (veraltete) Vorgänger von /dev/srX; früher wurden hierüber die Brennner angesprochen
/dev/stX SCSI tape -> Streamer und Bandlaufwerke
/dev/nstX Ebenfalls SCSI-tape nur das am Ende der Bandoperation nicht zurück gespult wird (n = norewind); nächste Schreiboperation wird eingehängt
Unterscheidung /dev/stX und /dev/nstX beachten

101.1 Identifizieren von Kernel Versionen und Modul-Abhängigkeiten

uname -r Version des aktuellen Kernels bestimmen
/lib/modules/ Auflistung aller jemals installierter Kernel auf dem System
/usr/src/<Kernel-Version> hier befindet sich der Quellcode des Kernel (auch auf http://kernel.org)

Was verbirgt sich hinter dem Bezeichner des Kernels:

1. Zahl: Major Release: wird nur bei revolutionären Veränderungen geändert (oder wenn Linus Torvald es beschließt). Aktuelles Major Release (2016) ist bei 4
2.Zahl: Minor Release: Änderung wenn dem Kernel neuen wesentliche Funktionen hinzugefügt werden. Zusätzliche Unterscheidung zwischen geraden und ungeraden Minor Releases:

gerade Versionen: stable
ungerade Versionen: Entwicklerversionen

3. Zahl: Patch Level: hier werden kleinere Änderungen und Fehlerbeseitigungen am Kernel dokumentiert
der REST: Bezeichnung, die man dem Kompilieren im Makefile des Kernels angegeben hat. Es gibt keine Namenskonventionen

lsmod Status der Module des laufenden Kernels. lsmod greift auf /proc/modules zu
modinfo detaillierte Infos zu einem Modul des Kernels: z.B. Autor, Verwendungszweck, Versionsnr., Lizenz, Abhängigkeiten

-a zeigt nur den Autor an
-d nur die Beschreibung
-l Lizenz
-p übergebene Parameter (falls vorhanden)
-n Dateiname des Moduls

insmod Module in den laufenden Kernel integrieren unter Angabe des kompletten Pfads und eventuell notwendigen Optionen. Abhängigkeiten werden geprüft, aber nicht aufgelöst -> Fehlermeldung. Keine Erfolgsbestätigung
Aufrufparameter
-k (autoclean) entfernt das Modul aus dem Speicher, wenn es nicht mehr benötigt wird
-p (probe) Test, ob ein Laden des Moduls erfolgreich wäre
rmmod entfernen eines nicht mehr benötigten Kernelmoduls. Sollte das Modul noch in Gebrauch sein, erfolgt eine Fehlermeldung. Keine Pfadangabe möglich, da mit /proc/modules-Dateien gearbeitet wird. Keine Erfolgsmeldung

-v Verbose Mode
-f erzwingt das Entladen des Moduls, auch wenn eventuelle Abhängigkeiten nicht erfüllt sind

modprobe Kombination von insmod und rmmod, modprobe kann nicht nur Abhängigkeiten zwischen den Modulen erkennen, sondern auch Probleme beheben. Zur Installation ist nur der Modulname, nicht der ganze Pfad notwendig. Auflösen von Abhängigkeiten durch selbständiges Suchen da es die Informationen aus uname -r verwendet, um notwendige Module zu suchen. Nicht alle Optionen mehr für aktuelle Kernel vohanden

Auflistung aller Module eines Typs möglich mit Option -at (sofern noch verfügbar) (-t unter Ubuntu 14.04 nicht mehr verfügbar)
basename -s ".ko" $(find /lib/modules/$(uname -r) -type f -name "*.ko") mit diesem Befehl kann unter Ubuntu die vollständige Liste aufgerufen, oder man schaut sich die verfügbaren Module im Verzeichniss selbst an
Auflisten und Entfernen von Modulen. Gleichzeitiges Entfernen mehrerer Module (durch Leerzeichen getrennt) möglich

Unterschied zu lsmod: modprobe zeigt alle Module an, die in den laufenden Kernel installiert werden können (-l unter Ubuntu 14.04 nicht mehr verfügbar)
depmod Erzeugung einer neuen modules.dep -Datei. Dabei werden die Abhängigkeiten aller vorhandenen Modulen abgefragt und in die neue Datei eingetragen. modules.dep listet die Abhängigkeiten zwischen allen Modulen auf und liegt unter /lib/modules/<Kernel-Version>/

-n Trockenlauf mit Ausgabe nach stdout
-A Schnelldurchgang bei dem vor der Erstellung der neuen Datei ge

101.1 Hardwareeinstelleungen ermitteln: I/O Adressen und Interrupts

Wichtung: 2

Kernel: Schnittstelle zwischen Software und Hardware
Kernel = Softwareprodukt
Kernel von Linux -> modularer Aufbau (zum großen Teil)
einzelne Teile des Kernels können zur Laufzeit ge- und entladen werden
modularer Aufbau verhindert unnötige Neustarts des Systems
Gegensatz zu modular: monolithischer Kernel -> versagt eine Hardwarekomponente oder wird sie entfernt, können schwere Störungen auftreten
SCSI - Small Computer System Interface (Familie von standardisierten Protokollen und Schnittstellen)
IDE - Integrated Disc Electronic

I/O Adressen und Interrupts

I/O Speicheradressen werden genutzt, um Input/Output Daten an den Computer zu übergeben
Hexadezimal dotiert: beginnen immer mit 0x
I/O Adresse ist eindeutig, da ansonsten die Karten sich gegenseitig den Speicherbereich überschreiben würden
Werte für alte ISA-Karten (werden eher nicht mehr verwendet):

Soundkarte: 0x110, 0x330
Netzwerkkarten: 0x240, 0x330
Serielle Schnittstellen/ Modem: 0x2e8, 0x3e8,0x2f8, 0x3f8

PCI-Karten haben höhere I/O-Adressen: z.B. 0xd000
Interrupts (IRQ Interrupt Request): Signalleitungen zur CPU zur Meldung, dass Daten im I/O-Speicherbereich zur Verarbeitung vorliegen
Es gibt 16 IRQ (0-15)
Shared Interrupts: Ursprünglich sollten auch die IRQs eindeutig sein, aufgrund der geringen Menge hat man der Hardware die shared interrupts beigebracht, was mal besser und mal schlechter funktioniert -> 1 IRQ wird von 2 Controllern verwendet
Gängige IRQ Belegungen:

IRQ 0: Timer (Motherboard)
IRQ 1: Tastatur (Motherboard)
IRQ 2: IRQ-Kaskadierung; um die IRQs 8-15 nutzbar zu machen
IRQ 3: /dev/ttyS1 alias COM2 (zweite serielle Schnittstelle)
IRQ 4: /dev/ttyS0 alias COM1 (erste serielle Schnittstelle)
IRQ 5: /dev/lp1 alias LPT2 (zweiter Parallelport); wurde früher für Netzwerkkarten und Soundkarten benutzt, da die wenigsten Rechner zwei Parallelports hatten
IRQ 6: Floppy Controller
IRQ 7: /dev/lp0 alias LPT1 (erster Parallelport)
IRQ 8: RTC (Real Time Clock, Hardware-Uhr Motherboard)
IRQ 9: frei -> wird häufig für die Grafikkarte verwendet (früher mit IRQ 2 "parallel geschaltet", was zu Problemen führen konnte)
IRQ 10: frei
IRQ 11: frei
IRQ 12: frei; häufig für PS/2 Maus
IRQ 13: frei
IRQ 14: erster IDE Controller
IRQ 15: zweiter IDE Controller

Unter RedHat werden in der /proc/interrupt tatsächlich nur die IRQs 0,1,8,9,12,14,15 aufgeführt
Unter Ubuntu dagegen werden die IRQs 0,1,6,7,8,9 geführt; Da die IRQs 14 und 15 ja für die IDE Controller gedacht sind, stellt sich mir die Frage, ob unter Ubuntu die IRQs 6 und 7 hier als IDE- bzw. SCSI-Interrupt nutzt? Antwort: Bei dem RedHat System handelt es sich um eine VM, die den IDE-Bus mit anhängigen Komponenten verwendet. Mein Live-System dagegen hat keine klassische IDE-Geräte mehr, sondern dort wird alles über SCSI gehandelt, daher die Abweichungen. Ein Ubuntu-VM-System weißt ebenfalls die IRQs 14 und 15 auf, jedoch nicht 6 und 7

101.2 Das System startet

Wichtung: 3

Betriebssystem ist dazu da, um Software zu starten, ist aber selbst Software
=> Boot-Strap-Problem (Henne-Ei-Problem)

Einschaltprozess

Einschalten
Initiale Prozesse im BIOS

Power-On-Self-Test -> grundsätzliche Funktionstüchtigkeit
Arbeitsspeicher auf Größe und Funktionstüchtigkeit prüfen
sehr oberflächlicher Test

nach Initialisierung aller Hardwarekomponenten, sucht das BIOS nach einem Betriebssystem oder Programm, das ein Betriebssystem laden kann

Suchreihenfolge ist im BIOS hinterlegt

logischer Aufbau einer Festplatte:

max. 4 Partitionen (drei primäre + eine erweiterte)
Partitionstabelle befindet sich im Master Boot Record (MBR)
MBR ist eigenständig, gehört keiner Partition an und ist genau 512 Byte groß
MBR befindet sich am Anfang der Festplatte (Spur 0, Sektor 0)

BIOS liest nun den MBR aus

Beispiel in Buch zeigt ein Ladeprogramm in hexadezimaler Schreibweise (erste Stufe GRUB 2) und im unteren Bereich (letzten 5 Zeilen) die Partitionstabelle
2 Möglichkeiten den Bootvorgang fortzusetzen:

Bootloader im MBR -> Übergabe der Kontrolle an diesen
Kein Bootloader vorhanden (nur Nullen in oberer Zeile des Ladeprogramms) -> Konsultation der Partitionstabelle nach Verweis auf eine startfähige Partition

Partionen werden im Ladeprogramm in den letzten 5 Zeilen dargestellt

Erste Partition (Startpartition) ist mit 8020 gekennzeichnet
Die Abschlussmarkierung der letzten Partition 55aa
Jede Partition nimmt eine Zeile ein
Darstellung der Hexadezimalen Bytes:

Big-Endian-First-Byte-Abfolge -> Vertauschung des High- und Lowbytes
Little-Endian-First-Byte-Abfolge -> niederwertigste Bits werden zuerst angezeigt
Historische Entwicklung: Intel verwendet Little-Endian, Motorola z.B. verwendet Big-Endian

Boot-Strap-Loader: GRUB Legacy, GRUB 2
Kernel Parameter werden durch dem Bootloader übergeben, oder man kann die Parameter auch per Hand initiieren
Automatisch: Eintrag in die Konfigurationsdateien des Bootloaders (z.B. /boot/grub/grub.conf)

z.B. kernel /bzImage-2.6.11 root=/dev/hda2 ide=nodma apm=off

Übergabe von Hand nur sinnvoll für Tests oder Fehlerbehebung, nicht permanent

Stoppen des Bootvorgangs, wenn Bootmenü erscheint, durch kurzes Betätigen der Cursortasten (in einer VM kommt man ins Auswahlmenü über die Shift-Taste)
Eintrag aus Bootmenü auswählen, mit Taste e bestätigen
Editor, in dem der entsprechende Booteintrag bearbeitet werden kann
Änderungen sind nicht permanent, nächsten Systemstart werden sie revidiert
Fortsetzen des Startvorgangs GRUB 2 Strg + X, GRUB Legacy Eingabetaste gefolgt von B
prominenter Übergabeparameter: init=/bin/bash Wird benötigt, um ein lokales Terminal zu initiieren. Dieses wird im nur lesen Modus gestartet, daher ist noch ein mount -o remount, rw / und passwd root notwendig, um dann das Kennwort für root neu setzten zu können

initramfs (initiale RAM-Disk): abgelegt unter /boot/initrd, Erzeugen mit mkinitrd (Red Hat) und mkinitramfs (Debian)
Startprotokollierung -> Protokollierung der Ausgaben, die der Kernel beim Start produziert

Auslesen des sogenannten Kernel-Ring-Buffers mit Hilfe des Programms dmesg
Ausgabe kann recht groß sein, daher empfiehlt es sich die Protokollierung entweder direkt in eine Datei umzuleiten, oder mit | less die Ausgabe zu kanalisieren
Ausgabe wird wohl extrem gekürzt, da die Firewall direkt im Kernel integriert ist. Kann ich unter Ubuntu jedoch nicht bestätigen
Ansonsten findet man dieses Log auch unter /var/log/messages (nicht unter Ubuntu und RedHat) Hier werden die Informationen über einen längeren Zeitraum gespeichert.
Unter Ubuntu finden sich die Logs, wie z.B. syslog unter /var/log/ Dort findet man die gleichen Einträge wie unter dem Aufruf dmesg. Diese Protokolldateien haben zusätzlich zu den Informationen, ebenfalls einen Zeitstempel gespeichert.

Fragen:

Wenn ein Bootloader installiert ist, wird die Kontrolle an diesen abgegeben. Ansonsten werden die Partitionen nach bootfähigen Programmen durchsucht. Bei meinen Ubuntu Installationen habe ich immer den GRUB Bootloader installiert. Übernimmt der nun, obwohl ich bootfähige Partitionen habe? Antwort: GRUB startet den Kernel, der auf der Partition abgelegt ist. Gibt es keine bootfähige Partition, sucht er nach anderen bootfähigen Medien
Unterschied zwischen Startsektor einer Partition und MBR genauer klären. Startsektor ist mir nicht ganz klar... Antwort: Der MBR ist eigenständig und gehört keiner Partition an. Der Startsektor ist der Anfang einer erweiterten Partition und verweist

Sonntag, 15. Mai 2016

Konzept der Posts

Befehle/ Kommandos Courier
Inhalte von Dateien Courier
Themenworte lila
Schlagworte blau
Wichtige Zusammenhänge schwarz bold
Verzeichnisse bold kursiv
prüfungsrelevante Optionen unterstrichen
Inhalte mit Klärungsbedarf rot
Wichtung in der Prüfung bold
Unter Ubuntu (oder anderen Distris) nicht verfügbar, oder wie es dort vorhanden ist gün

Donnerstag, 12. Mai 2016

Dateisystem Filesystem Hierarchy Standard FHS

Richtlinie für die Verzeichnisstruktur unter Linux Distributionen

Wikipedia Eintrag

Dateikategorien

static Dateien, die sich ohne Eingriff des Systemadmins nicht ändern; z.B. Systemprogramme und Bibliotheken (vorzugweise in /usr zu finden)
variable Alles Dateien, die sich durchaus häufig ändern; z.B. MySQl Datenbanken (Dateien werden hauptsächlich unter /var abgelegt)
shareable Dateien, die für alle Rechner identisch sind und daher zentral vorgehalten werden können und übers Netzwerk verteilt werden (/urs/bin)
unshareable Hostspezifische Dateien (/etc-Verzeichnis)

Aus diesen Aspekten ergeben sich 4 Datei-Kategorien:

static shareable z.B. /usr/bin
static unshareble z.B. /etc
variable shareable z.B. /home
variable unshareable z.B. /var/run

Hauptverzeichnisse

Es gibt 13 Verzeichnisse oder symbolische Verknüpfungen im Stammverzeichnis /

/bin grundlegende Systembefehle (Binärdateien), die auch bei nicht gemountedem Dateisystem benötigt werden (Single User Mode z.B.); es sind keine Unterverzeichnisse erlaubt; Liste der meist verwendeten Befehle findet sich im Wikipedia-Artikel

/boot alle Dateien des Bootloaders für den Bootvorgang, auch den MBR

/dev Gerätedateien; u.a. die Dateien /dev/null (in dieser Datei wird alles, was geschrieben wird, wieder verworfen) , /dev/zero (aus dieser Datei werden Nullbytes in beliebiger Menge gelesen) und /dev/random (Hardware-Zufallsgenerator)

/etc spezifische Konfigurationsdateien; statische Dateien, keine Binärdateien (im Ubuntu Verzeichnis sind jedoch Binärdateien vorhanden) (etc = editable text configuration; urspr. et cetera); hier liegen wichtige Konfigurationsdateien, wie fstab, inittab, networks, passwd, profile, usw.
Unterverzeichnisse:

/etc/opt systemspezifische Konfigurationsdateien für die Programme in /opt; für zusätzlliche installierte Softwarepakete müssen entsprechende Unterverzeichnisse angelegt werden; Regelung zur Unterverteilung von /etc/opt/ existiert nicht

/etc/X11 optional Konfiguration des X-Window-System (Dateien Xconfig, xorg.conf, Xmodmap)

/etc/sgml SGML-Systeme speichern hier grundlegende Konfigurationen ab

/etc/xml Grundeinstellungen von evtl. vorhandenen XML-Systemen

/etc/mc Konfiguration des Midnight Commanders (Dateimanager)

/etc/network Konfigurationsdateien, die das Netz betreffen (Debian)

/lib installierte dynamische Bibliotheken und Kernel-Module (Unterverzeichnis modules), die zum Starten und für die Programme in /bin und /sbin benötigt werden; dynamische C-Standardbibiothek libc.so.* und Linker Bibliothek ld*

/media Einhängepunkt für Wechseldatenträger

/mnt temporärer Einhängepunkt für Dateisysteme

/opt zusätzliche Softwarepakete, die nicht in den Reposorities enthalten sind

/sbin wichtige Systembefehle für die Systemadministration u.a. die nur als root ausgeführt werden dürfen (shutdown, fastboot, fdisk, mkswap, swapoff, etc)

/srv Daten, die von Diensten angeboten werden; Verzeichnisstruktur ist noch nicht definiert

/tmp temporäre Dateien von Programmen, für alle Benutzer zum Schreiben frei gegeben und muss ein Sticky-Bit haben

/usr Unix System Resource; enthält Daten, die von mehreren Rechnern parallel genutzt werden können (shareable)
folgende Unterverzeichnisse müssen vorhanden sein:

/usr/bin primäre Verzeichnis für ausführbare Dateien auf dem System und enthält viele Benutzerbefehle

/usr/include Header-Dateien (enthalten Include-Dateien mit Prototypendefinition), die durch Programme eingebunden werden

/usr/lib modularer Programmcode, der über Bibliotheken verschiedenen Programmen zur Verfügung gestellt werden kann

/usr/local Ort, wo Dateien und Programme abgelegt werden können, die von der Distribution nicht verwendet werden dürfen

/usr/sbin Ablage von Systembefehlen, die nicht zwingend notwendig sind und entsprechend auch nicht für den Bootvorgang verwendet werden

/usr/share von der Architektur unabhängige Daten

optional:

/usr/X11R6 X-Window-System Version11 Release 6

/usr/games Spiele

/usr/lib<nr> alternative Versionen dynamischer Bibliotheken

/usr/src Quellcode

/var varible Daten, die im Zuge der Abarbeitung entstehen. Es werden folgende Verzeichnisse erwartet:

/var/cache zwischengespeicherte Daten von Anwendungsprogrammen

/var/lib variable Statusinformationen

/var/local variable Daten im Zusammenhang mit /usr/local

/var/lock Lock-Dateien zur Prozesssynchronisation

/var/log Logdateien

/var/opt variable Daten in Zusammenhang mit /opt

/var/run Daten des laufenden Prozesses

/var/spool abzuarbeitende Warteschlangen (Druckaufträge, E-Mail-Versandaufträge,...)

/var/tmp temporäre Dateien, die über den Neustart erhalten bleiben

falls entsprechende Anwendungen installiert sind, existieren auch noch die folgenden Verzeichnisse

/var/account Prozessabrechnungsdaten
/var/crash Systemdumps bei Rechnerabstürzen
/var/game variable Spieledaten
/var/mail Benutzerpostfachdateien
/var/yp Datenbankdateien des Network Information Service

/run Ersatz für /var/run; Eigentlich kein Bestandteil des FHS, aber steht dem auch nicht entgegen; Soll die Problematik beheben, dass /var/run während des Bootvorgangs unter bestimmten Umständen nicht verfügbar ist

zusätzliche Verzeichnisse, wenn Untersysteme installiert sind

/home Verzeichnisstruktur zur Aufnahme von benutzerspezifischen Daten; Konfigurationsdateien werden dabei in versteckten Dateien und Verzeichnissen abgelegt (dot.files)
/root Benutzerverzeichnis für den Benutzer root
/lib<nr> alternative Kernel-Module und dynamische Bibliotheken, wenn das System mehrere Binärformate (32 Bit und 64 Bit) unterstützt. Für diese Systeme sind entsprechend eigene Versionen derselben Bibliothek vorhanden, die entsprechend in den /lib<nr> Verzeichnissen abgelegt werden