Linux Basis Know How fuer System Administratoren

1 Einleitung

Warum ein Pinguin?

• Kurs Dauer: 3 Tage
• Publikum: System Administratoren

Ziel dieses Kurses ist es einen "Enterprise tauglichen" Einstieg in die OpenSource Welt zu finden.
Es werden alle wichtigen Faktoren besprochen um Entscheidungen für die Einführung von Systemen und Applikationen zu finden welche später nicht bitter und teuer bereut werden müssen.
Wir erlernen wir Basis Kenntnisse über Installation und Grund-Funktion des OpenSource Enterprise Betriebssystems CentOS 8 Core welches die freie Variante von "Red Hat Enterprise Linux" darstellt.
Des weiteren erarbeiten wir durch praxisnahe Beispiele einen Einstieg in die System Administration von CentOS.

2 Ziele

• Das Konzept von Linux und OpenSource verstehen
• Enterprise-relevante Kriterien von OpenSource Software analysieren
• Ein CentOS 8 mit dem GUI Installer aufsetzen
• Sich per SSH/Konsole auf einem Linux System anmelden
• Grundlegende BASH Konsolen Kenntnisse erlangen
• Das OS Derivat bestimmen
• Pakete hinzufügen/entfernen

• Config Files bearbeiten
• Einen Dienst in Betrieb nehmen

• Updates einspielen
• Oberflächlicher Health Check
• Log Files finden und lesen
• Prozesse und deren Ressourcen finden
• Dienste und deren Status prüfen
• Rudimentäre Admin Arbeiten ausführen

3 Voraussetzungen

Um in der geplanten Zeit die Ziele erreichen zu können, setzen wir ein paar Dinge voraus...

3.1 Vorkenntnisse

Es wird davon ausgegangen das die Teilnehmer über mehrjährige Erfahrung im System-Administrations-Bereich und Grundwissen Wissen in den Bereichen

• Hardware
• Software
• Betriebssysteme
• Consolen Grundkenntnisse (DOS, BASH, KSH)
• Netzwerk

verfügen.

Im Zweifelsfall ist vor der Durchführung mit dem Trainer Rücksprache zu halten.

3.2 Kurs Raum

Es wird ein Kurs Raum mit genügend Platz und den gängigen Mitteln benötigt:

• Genügend Platz für alle Teilnehmer (Corona)
• Beamer
• Flip Chart
• WLAN
• Genügend Steckdosen
• Getränke, Snaks
• Kantine/Restaurant für Mittags-Pause

3.3 Arbeitsmittel der Teilnehmer

Zugriff auf eine VMware Virtualisierung mit mindestens folgenden Ressourcen:

• 2 vCPU
• 2GB Memory
• 20 GB Disk
• Internet Access via LAN für die VM

Ein Notebook mit WLAN, VMware Workstation und genügend Ressourcen ist absolut ausreichend, soll aber vor dem Kurs Beginn installiert, konfiguriert und getestet sein. Wird ein Remote LAB verwendet, soll vor dem Kurs sichergestellt werden das dies im Kursraum genutzt werden kann. (Zugriff, File Transfer, Copy Paste vom Notebook, …)

4 OpenSource Überblick

4.1 Ursprung

• Angelehnt an MINIX welches als Anschauungs OS von Andrew S. Tannenbaum für den Unterricht entwickelt wurde
• Erster Kernel 1991 von Linus Torvalds (10 000 Zeilen)
• Aktueller Kernel 4.14.x LTS (25'071'693 Zeilen)

4.2 Einsatzgebiete

• Apliances: VCSA, vRA, vRO, vROPS, LI,..., OpenFiler, GreenBone Security Manager...
• Embedded Devices: WLAN AccessPoints, Raspberry Pi, Beagle Bone, many more...
• Super Computer
• Cloud Services: Google, AWS, RackSpace, ...
• Netzwerk Services (Apache,Nginx,Tomcat,Datenbanken,...)
• Mobile Devices
• IoT
• Medizin
• Automobil Industrie
• überall eigentlich ...

4.3 OpenSource verstehen

OpenSource ist nicht einfach eine Lizenz, es ist viel mehr die einzig bislang funktionierende Form von Kommunismus in der Geschichte.
Die Grundsätze von OpenSource sind am einfachsten im Essay von Eric S. Raymond in Die Kathedrale und der Basar beschrieben.
Viele Davon würde sich so mancher Mitarbeiter heute in seiner Firma wünschen

Folgendes sind die Grundsätze dieses Textes:

1. Jede gute Software wird von einem Entwickler geschrieben, der ein persönliches Problem lösen will.
2. Gute Programmierer wissen, was sie schreiben müssen. Brillante wissen, was sie neuschreiben müssen (und was sie wiederverwenden können).
3. Plane, eine Version zu verwerfen; du wirst es sowieso tun.
4. Wenn du die richtige Einstellung hast, werden dich interessante Probleme finden.
5. Wenn du das Interesse an einem Programm verlierst, ist es deine Pflicht, dieses einem kompetenten Nachfolger zu übergeben.
6. Wenn du deine Benutzer als Mitprogrammierer betrachtest, ist dies der einfachste Weg zu schneller Verbesserung und effizientem Debugging.
7. Veröffentliche früh. Veröffentliche häufig. Und höre auf die Benutzer.
8. Mit einer hinreichend großen Gruppe von Betatestern und Mitentwicklern wird fast jedes Problem schnell erkannt und die Lösung von jemandem gefunden.
9. Schlaue Datenstrukturen und einfacher Code (im englischen Original: „dumb code“) funktionieren viel besser als andersherum.
10. Wenn du deine Betatester wie deine wertvollste Ressource behandelst, werden sie dies auch werden.
11. Fast so gut wie eigene gute Ideen zu haben, ist es, gute Ideen von den Benutzern zu erkennen. Manchmal ist letzteres besser.
12. Meist entstehen die brillanten Lösungen aus der Erkenntnis, dass das Problem falsch verstanden wurde.
13. Perfektion (im Design) ist nicht erreicht, wenn man nichts mehr hinzufügen kann, sondern wenn nichts mehr entfernt werden kann.
14. Jedes Tool soll so funktionieren, wie erwartet. Aber ein wirklich gutes Tool ermöglicht Verwendungszwecke, an die du niemals gedacht hättest.
15. Wenn du Schnittstellencode schreibst, verhindere um jeden Preis, den Datenstrom zu verändern – und verwirf nur etwas, wenn dies der Empfänger verlangt.
16. Wenn deine Programmiersprache nicht ansatzweise Turing-vollständig ist, kann syntaktischer Zucker dein Freund sein.
17. Ein Sicherheitssystem ist nur so sicher wie sein Geheimnis. Vermeide Pseudogeheimnisse.
18. Um ein interessantes Problem zu lösen, suche eines.
19. Mit ausreichend guter Kommunikation, wie über das Internet, und Führung ohne Zwang, sind viele Köpfe immer besser als einer.

Ein gutes Beispiel für...

• die Kathedrale ist Zimbra, Macintosh, Android, ChromeOS
• den Basar ist Fedora, Arch, Debian

4.3.1 Copy Left

Jeder kennt ein Copyright, das Markante an Linux ist aber die Copyleft Lizenz welche das Gegenteil ist.
Wer das Produkt erweitert verpflichtet sich die Erweiterung zur Verfügung zu stellen.
Die wohl bekannteste Lizenz ist die GPL.

4.3.2 Community

Mitglieder der Community zeichnen sich dadurch aus, sie andere Community Mitglieder und/oder deren Prdukte unterstützen.
Dies kann in ganz vielen Formen geschehen:

• Entwicklung
• QA Testing
• Dokumentation/HowTos/Übersetzungen
• Forums Betreuung/Beiträge

Distributionen wie Fedora, CentOS, Debian, Ubuntu, Arch, ... sind zwar oft exklusiv einer Firma zugeordnet.
Es ist aber nicht möglich Dienstleistungen via SLA darauf zu beziehen, da das fortführen der zum Erhalt notwenidgen Arbeiten durch die Comunity geleistet wird.

4.3.3 Free Beer vs. Free Speak

Mit Forderungen und Negativer Kritik in Foren auf zu treten ist ein guter Weg sich schnell unbeliebt zu machen.
Denkt daran, das die meisten Produkte unentgeltlich gepflegt werden, da macht es sich unglaublich schlecht wenn im Forum Fragen stellt welche in der Doku behandelt wurden.
Behandelt die Community Mitglieder wie eure Wertvollsten Mitarbeiter, Sie haben Sich durch Ihr Engagement bereits bewiesen.

Taucht dennoch ein Problem mit einer "Community Supported Software" auf, könnte folgendes Verhalten helfen:

• Wertschätzung

Erst mal bedanken ist immer eine gute Idee.

• Eine kleine Spende

Wenn eine Lösung dringend ist hat das Produkt offenbar einen Wert?!

• Genaue Fehler Beschreibung

So das jeder der das liest das Problem selbst herbeiführen kann

• Ein dediziertes System zur Analyse des Problems und externen Zugang bereit stellen

Den Zugang bitte nicht in den Foren posten

• Workaround oder Lösung für andere Mitglieder aufbereiten

Dokumentation, Zusammenfassung, HowTo, ...

Neulich konnte ich ein Problem mit Guacamole (HTML5-Gateway) innerhalb von 24h im Code lösen.
Selbst gute Enterprise Firmen brauchen oft länger um ein Problem zu analysieren, geschweige denn zu Lösen.

5 Linux Überblick

High Level Linux Distro Timeline

Die Gemeinsamkeit aller Linux Distributionen ist der Kernel, und die damit verbundene Lizenz.
Niemand der eine Linux Distribution pflegt programmiert einen eigenen Kernel.
Bekannte Abspaltungen des Ursprünglichen Linux Ursprungs sind:

• Debian basierend (Ubuntu)
• Red Hat basierend (CentOS)
• Slackware basierend (SuSE)
• Gentoo (Chrome OS)
• Arch (System Rescue CD)

Distributionen können unter Distrwatch gefunden werden, es sind ganz schön viele.
Das markanteste an einer jeden Linux Distribution ist wohl der Paket Manager hier sind DPKG (Debian) und RPM (Red Hat) die am weitesten verbreiteten Formate.

5.1 Kernel

Linux Monolitic Kernel

Linux System Call Interface

• Linux Basiert auf einem Monolithischen Kernel
• Ein monolithischer Kernel ist ein Kernel, in dem nicht nur Funktionen zu Speicher- und Prozessverwaltung und zur Kommunikation zwischen den Prozessen, sondern auch Treiber für die Hardwarekomponenten und möglicherweise weitere Funktionen direkt eingebaut sind.
• Treiber und Kernel Funktionalität wird über Module bei Bedarf geladen (XFS, KVM, SCSI, NET, ...)
• Dies ermöglicht das auf einem AccessPoint und einem DB Server exakt der gleiche Kernel ausgeführt werden kann
• Schlechter Treiber Code kann jedoch ein ganzes OS mit sich reissen (Gefahr von "Vendor Closed Source Treibern")

Bei einem Mikrokernel kann der defekte Bereich neu geladen werden, was aber auf Grund der abhängigkeiten (Appkikation, Netz, ...) in der Praxis keine besseren Resutlate bringt.

5.1.1 Treiber sind Kernel Module

Kernel Spaces

Kern Funktionalität und Treiber sind in Kernel Modulen zusammengefasst.
Dies bedingt das die Quellen aller Treiber offen zur Verfügung stehen.
Ist dies nicht der Fall, werden die Module nicht in den Vanilla Kernel aufgenommen.
Aus diesem Vanilla Kernel werden die Kernel aller Linux Distributionen abgeleitet.

Hier entsteht aber genau das erste Problem für eine Enterprise Distribution.
Wer garantiert mir ob meine neuen teuren Server auch wirklich mit Linux performant laufen?

• Red Hat Enterprise Linux Kompatibilitäts Liste
• Red Hat Enterprise Linux Limitierungen

Closed Treiber sind in der Community offenkundig verhasst. Wie zum Beispiel dieses provokative Statement von Linus zeigt.
Diese werden auch von den wenigsten Enterprise Distros supported und wenn dann nur für sehr hohe Gebühren an die Hersteller.

Ein manuell kompiliert und ins System geladenes Kernel Modul wird nach einem Kernel-Update des Betriebs Systems nicht mehr funktionieren.

5.2 Boot Vorgang

SystemV Boot Prozess

SystemD Boot Prozess

• Vom Bootloader wird immer ein Kernel in eine RamDisk geladen, diese enthält zum Booten benötigte Konfigurationen und Programme
• Dem Kernel übergebene Start Parameter können unter /proc/cmdline geprüft werden

5.2.1 SystemV

• Bis und mit RHEL6 wurde Linux nach dem SystemV Konzept gebootet.
• Dieser Standard kommt aus den frühen Unix Tagen und ermöglicht ein einfaches, sequentielles starten von Diensten und Funktionen.
• Um verschiedene Runlevels zu ermöglichen wurde jeweils ein Directory pro Runlevel benutzt
• Die zentrale Konfigurations Datei eines SystemV Systems ist /etc/inittab
• Die Start und Stop Scripte (/etc/rc.d/init.d/*) der Dienste wurden jeweils mit K (kill) oder S (start) in die Runlevel Directories gelinkt (/etc/rc.d/rcX.d)
• Folgende Standard Runlevel haben sich etabliert:
  • 0 – halt
  • 1 – Single user mode
  • 2 – Multiuser, without NFS
  • 3 – Full multiuser mode
  • 4 – unused
  • 5 – X11
  • 6 – reboot
• Das Runlevel kann mit dem init Befehl gewechselt werden: init 6 -> reboot

5.2.2 SystemD

• Mit RHEL7 wurde SystemD eingeführt, welcher ein dynamisches laden von Diensten und deren Abhängikeiten ermöglicht.
• So kann zB Tomcat mit einer Abhängigkeit zum Netzwerk Dienst konfiguriert werden.
  • Ein Restart des Netzwerks kann beispielsweise automatisch einen Restart des Tomcat auslösen
• Die Verwaltung von SystemD Diensten ist aufwändig, aber sehr mächtig
• ACHTUNG: Verändern Sie NIE SystemD Service Dienste! Kopieren Sie diese immer nach /etc/systemd/system/

5.3 Grund Konzepte

Einige Dinge haben alle Linux Systeme gemeinsam. Wer diese Dinge versteht kann weiteres Wissen darauf aufbauen.

5.3.1 Alles ist eine Datei

man virt-filesystems
man hier
lshw

• Geräte: /dev/
• Prozesse: /proc/
• Memory: /dev/, /proc/
• Kernel Parameter: /proc/, /sys/
• Netzwerk Verbindungen: /proc/net/
• Dateisystem

Viele dieser Zugriffe werden über Tools und Bibliotheken abstrahiert: top, lscpu, dstat, ps, ...

5.3.2 Dateisystem Struktur

man file-hierarchy
man hier
lsblk

Begonnen beim / (root-direcotry genannt) baut sich die gesamte Dateistruktur eines Linux Systems Baumförmig auf.
Laufwerke heissen unter Linux Mount-Points und werden einen anderen Directory unter geordnet.

5.3.3 System Meldungen

Jede Software hat Meldungen welche relevante Vorgänge mitteilt.
Anbei die gängigsten Formate/Standards.

5.3.3.1 Log Files

Klassische Logfiles sind der unabhängigste und zugleich schlechteste Weg um Mitteilungen einer Applikation zu speichern.
Logfiles befinden sich meistens unter /var/log/

5.3.3.2 Syslog

lsof | grep /var/log/

5.3.4 =Journal

journalctl -af