Inhalte: Wochen 13 bis 16
- Woche 13 Linux-Grundlagen (B3, A6, LF9) - Woche 14 Betrieb und Ueberwachung (A8, A5, LF11) - Woche 15 Serviceanfragen bearbeiten (A1, A2, A5, LF6) - Woche 16 Vorbereitung auf Teil 1 (C3, C4, A10, LF2, LF5) 12 Handouts, 36 Merkkarten, 4 Praxisaufgaben, 3 Checklisten, 2 Lernzielkontrollen und eine Probepruefung Teil 1 (90 Minuten, 100 Punkte, eine durchgehende Fallsituation). Alle Rechenbeispiele nachgerechnet. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This commit is contained in:
Florian Wilde
co-authored by
Claude Opus 5.5
Claude Opus 5.5
parent
86c0ab4f65
commit
70a3cd2d28
@@ -0,0 +1,65 @@
|
||||
---
|
||||
id: A10
|
||||
titel: Störung, Anfrage, Problem, Änderung – vier Arten von Tickets
|
||||
block: arbeitsalltag
|
||||
woche: 15
|
||||
worum: Nicht jedes Ticket ist eine Störung. Wer Störung, Serviceanfrage, Problem und Änderung auseinanderhält, löst schneller und lernt aus Wiederholungen.
|
||||
rahmenplan: [A1, A5, A8]
|
||||
lernfeld: LF6
|
||||
merksatz: Die Störung wird behoben, das Problem wird gelöst. Jede Änderung wird geplant, freigegeben und hat einen Rückweg.
|
||||
karten:
|
||||
- frage: Was ist der Unterschied zwischen einer Störung (Incident) und einem Problem?
|
||||
antwort: Eine Störung ist eine einzelne ungeplante Unterbrechung oder Beeinträchtigung – Ziel ist, den Nutzer schnell wieder arbeiten zu lassen. Ein Problem ist die Ursache hinter einer oder mehreren Störungen – Ziel ist, sie dauerhaft zu beseitigen.
|
||||
- frage: Was ist eine Serviceanfrage (Service Request)?
|
||||
antwort: Eine Bitte um eine vorgesehene Standardleistung, ohne dass etwas kaputt ist – etwa ein neues Konto, eine Softwareinstallation aus dem Katalog oder ein zurückgesetztes Passwort.
|
||||
- frage: Was ist ein Workaround?
|
||||
antwort: Eine Umgehungslösung, mit der der Nutzer weiterarbeiten kann, obwohl die eigentliche Ursache noch nicht beseitigt ist – etwa ein anderer Drucker, solange der Treiberfehler besteht.
|
||||
- frage: Welche drei Arten von Änderungen unterscheidet man?
|
||||
antwort: Standardänderungen sind vorab genehmigt, risikoarm und laufen nach festem Ablauf. Normale Änderungen werden einzeln geprüft und freigegeben. Notfalländerungen sind eilig und werden mit verkürzter Freigabe umgesetzt und nachträglich dokumentiert.
|
||||
---
|
||||
|
||||
## Das Wesentliche
|
||||
|
||||
- **Störung (Incident):** Etwas funktioniert nicht oder schlechter als vorgesehen. Ziel ist,
|
||||
den Betrieb **schnell** wiederherzustellen – notfalls mit einem Workaround.
|
||||
- **Serviceanfrage (Service Request):** Nichts ist kaputt, jemand braucht eine vorgesehene
|
||||
Leistung: neues Konto, Software, Zugriff, Gerät. Solche Anfragen laufen nach festen Abläufen
|
||||
und lassen sich oft vorab genehmigen.
|
||||
- **Problem:** die Ursache hinter einer oder mehreren Störungen. Drei Tickets mit „Outlook hängt
|
||||
morgens" sind drei Störungen und vermutlich ein Problem. Ziel ist, die Ursache **dauerhaft**
|
||||
zu beseitigen.
|
||||
- **Bekannter Fehler (Known Error):** ein Problem mit bekannter Ursache und dokumentiertem
|
||||
Workaround, dessen endgültige Lösung noch aussteht. Gehört in die Wissensdatenbank.
|
||||
- **Änderung (Change):** alles, was an Systemen verändert wird. Jede Änderung hat ein Risiko –
|
||||
deshalb wird sie beschrieben, bewertet, freigegeben, angekündigt und hat einen Rückweg.
|
||||
- **Drei Arten von Änderungen:** Standard (vorab genehmigt, festgelegter Ablauf, etwa Arbeitsplatz
|
||||
einrichten), normal (einzeln prüfen und freigeben), Notfall (sofort, Freigabe verkürzt,
|
||||
Dokumentation danach).
|
||||
- **Die Störung schließt man, wenn der Nutzer wieder arbeiten kann** – nicht erst, wenn die
|
||||
Ursache gefunden ist. Die Ursache verfolgt man im Problem weiter.
|
||||
- **Begriffe nach ITIL**, dem verbreitetsten Rahmenwerk für IT-Servicemanagement. Man muss es
|
||||
nicht vollständig einführen, um von seinen Begriffen zu profitieren.
|
||||
|
||||
## Übersicht
|
||||
|
||||
| Ticket | Art | Ziel |
|
||||
|---|---|---|
|
||||
| „Ich kann nicht drucken" | Störung | Nutzer wieder arbeitsfähig machen |
|
||||
| „Ich brauche Zugriff auf die Ablage Einkauf" | Serviceanfrage | Leistung nach festem Ablauf erbringen |
|
||||
| Zum fünften Mal diese Woche hängt der Druckserver | Problem | Ursache finden und beseitigen |
|
||||
| Druckserver bekommt neuen Treiber | Änderung | geplant, freigegeben, mit Rückweg umsetzen |
|
||||
|
||||
## Prüfungsfrage
|
||||
|
||||
**Frage:** Im Laufe einer Woche gehen sieben Tickets ein, dass die Verbindung zum
|
||||
Warenwirtschaftssystem morgens zwischen 8 und 9 Uhr abbricht. Beschreiben Sie, wie Sie mit
|
||||
diesen Tickets umgehen.
|
||||
|
||||
**Antwort:** Jedes Ticket ist zunächst eine Störung, die möglichst schnell behoben wird – etwa
|
||||
durch einen Neustart der Anwendung oder einen Workaround wie das Arbeiten über eine andere
|
||||
Verbindung. Weil sich die Störungen zur selben Zeit wiederholen, wird ein Problem angelegt und
|
||||
mit den sieben Störungen verknüpft. Im Problem wird die Ursache gesucht, z. B. ein zeitgesteuerter
|
||||
Vorgang wie eine Sicherung oder Anmeldespitzen am Morgen. Bis zur Lösung wird der Workaround als
|
||||
bekannter Fehler in der Wissensdatenbank dokumentiert, damit der Support weitere Meldungen
|
||||
schnell bedienen kann. Die endgültige Behebung – etwa die Verlegung der Sicherung – wird als
|
||||
Änderung geplant, freigegeben und umgesetzt; danach wird das Problem geschlossen.
|
||||
@@ -0,0 +1,63 @@
|
||||
---
|
||||
id: A11
|
||||
titel: Priorisieren und eskalieren – was zuerst, und wer übernimmt
|
||||
block: arbeitsalltag
|
||||
woche: 15
|
||||
worum: Wer immer das lauteste Ticket zuerst bearbeitet, lässt die wichtigen liegen. Die Priorität ergibt sich aus Auswirkung und Dringlichkeit – nicht aus der Lautstärke.
|
||||
rahmenplan: [A1, A2, A7]
|
||||
lernfeld: LF6
|
||||
merksatz: Priorität = Auswirkung × Dringlichkeit. Eskalieren ist keine Niederlage, sondern ein vereinbarter Weg.
|
||||
karten:
|
||||
- frage: Woraus ergibt sich die Priorität eines Tickets?
|
||||
antwort: Aus der Auswirkung (wie viele Nutzer, wie wichtige Abläufe sind betroffen) und der Dringlichkeit (wie schnell entsteht Schaden, gibt es eine Umgehung). Beides wird eingestuft und in einer Matrix zur Priorität verknüpft.
|
||||
- frage: Was ist der Unterschied zwischen funktionaler und hierarchischer Eskalation?
|
||||
antwort: Funktional wird ein Ticket an eine Stelle mit mehr Fachwissen weitergegeben, etwa vom ersten an den zweiten Level. Hierarchisch wird die Führungsebene einbezogen, etwa wenn eine Frist zu reißen droht oder Ressourcen fehlen.
|
||||
- frage: Was unterscheidet die Reaktionszeit von der Lösungszeit in einem SLA?
|
||||
antwort: Die Reaktionszeit ist die Zeit bis zur ersten qualifizierten Rückmeldung an den Nutzer, die Lösungszeit die Zeit bis zur Wiederherstellung des Betriebs.
|
||||
---
|
||||
|
||||
## Das Wesentliche
|
||||
|
||||
- **Auswirkung:** Wie viele sind betroffen, und wie wichtig ist, was nicht geht? Ein einzelner
|
||||
Nutzer ist gering, eine Abteilung mittel, der ganze Betrieb oder ein Kernprozess hoch.
|
||||
- **Dringlichkeit:** Wie schnell entsteht Schaden? Kann gar nicht gearbeitet werden, nur
|
||||
eingeschränkt, oder gibt es eine Umgehung?
|
||||
- **Priorität aus beidem**, nicht aus Gefühl, Lautstärke oder Rang des Anrufers. Der Drucker der
|
||||
Geschäftsführung ist eine Störung mit geringer Auswirkung; die Kasse im Lager, an der zwanzig
|
||||
Lieferungen hängen, nicht.
|
||||
- **Prioritäten dürfen sich ändern.** Kommt heraus, dass mehr Nutzer betroffen sind, wird
|
||||
hochgestuft – und das im Ticket vermerkt.
|
||||
- **Level:** Der erste Level nimmt an, erfasst, löst Bekanntes. Der zweite Level bearbeitet, was
|
||||
Fachwissen braucht. Der dritte Level sind Spezialisten oder der Hersteller.
|
||||
- **Funktional eskalieren**, wenn das eigene Wissen nicht reicht – rechtzeitig, mit vollständigem
|
||||
Ticket. **Hierarchisch eskalieren**, wenn eine Frist zu reißen droht oder Entscheidungen
|
||||
nötig sind, die man selbst nicht treffen darf.
|
||||
- **SLA:** Vereinbarte Reaktions- und Lösungszeiten je Priorität. Die Uhr läuft ab Eingang, nicht
|
||||
ab dem Moment, in dem man das Ticket öffnet.
|
||||
- **Den Nutzer informieren**, auch wenn es nichts Neues gibt. Ein Nutzer, der weiß, dass jemand
|
||||
dran ist, ruft nicht dreimal an.
|
||||
|
||||
## Übersicht
|
||||
|
||||
| Auswirkung ↓ / Dringlichkeit → | hoch | mittel | gering |
|
||||
|---|---|---|---|
|
||||
| **hoch** | P1 kritisch | P2 hoch | P3 mittel |
|
||||
| **mittel** | P2 hoch | P3 mittel | P4 gering |
|
||||
| **gering** | P3 mittel | P4 gering | P4 gering |
|
||||
|
||||
Beispiel für Zielzeiten: P1 Reaktion 15 Minuten, Lösung 4 Stunden · P2 1 Stunde / 1 Arbeitstag ·
|
||||
P3 4 Stunden / 3 Arbeitstage · P4 1 Arbeitstag / nach Absprache.
|
||||
|
||||
## Prüfungsfrage
|
||||
|
||||
**Frage:** Gleichzeitig gehen drei Tickets ein: (a) Der Geschäftsführer kann an seinem zweiten
|
||||
Bildschirm nichts sehen. (b) Im Lager kann niemand Lieferscheine drucken, der LKW wartet.
|
||||
(c) Eine Mitarbeiterin bittet um Installation eines neuen PDF-Programms. Priorisieren Sie mit
|
||||
Begründung.
|
||||
|
||||
**Antwort:** (b) zuerst – hohe Auswirkung, weil ein Kernprozess (Versand) für alle im Lager
|
||||
steht, und hohe Dringlichkeit, weil der wartende LKW unmittelbar Kosten verursacht: P1. (a) danach
|
||||
– geringe Auswirkung (ein Nutzer, ein Teil seines Arbeitsplatzes) und mittlere Dringlichkeit, weil
|
||||
er mit einem Bildschirm weiterarbeiten kann: P4, auch wenn der Melder ranghoch ist; eine kurze
|
||||
Rückmeldung mit Zeitangabe ist trotzdem angebracht. (c) ist keine Störung, sondern eine
|
||||
Serviceanfrage, die nach dem vorgesehenen Ablauf (Freigabe, Softwarekatalog) erledigt wird.
|
||||
@@ -0,0 +1,61 @@
|
||||
---
|
||||
id: A12
|
||||
titel: Wissen festhalten – ein Wissensartikel, der wirklich hilft
|
||||
block: arbeitsalltag
|
||||
woche: 15
|
||||
worum: Jede Störung, die zum zweiten Mal gelöst wird, hätte ein Wissensartikel beim ersten Mal verhindert. Gute Artikel sind kurz, auffindbar und aktuell.
|
||||
rahmenplan: [A5, C5, A1]
|
||||
lernfeld: LF6
|
||||
merksatz: Symptom so, wie der Nutzer es sagt. Ursache, Lösung in Schritten, Gültigkeit, Stand. Wer etwas zum zweiten Mal löst, schreibt es auf.
|
||||
karten:
|
||||
- frage: Welche Teile gehören in einen Wissensartikel?
|
||||
antwort: Das Symptom in den Worten des Nutzers samt Fehlermeldung, die Ursache, die Lösung in nummerierten Schritten, für welche Systeme und Versionen sie gilt, sowie Verfasser und Datum des letzten Stands.
|
||||
- frage: Warum formuliert man das Symptom in den Worten des Nutzers?
|
||||
antwort: Weil danach gesucht wird. Wer „Outlook fragt ständig nach dem Passwort" sucht, findet keinen Artikel mit dem Titel „Probleme mit der modernen Authentifizierung".
|
||||
---
|
||||
|
||||
## Das Wesentliche
|
||||
|
||||
- **Wann schreiben?** Wer eine Lösung zum zweiten Mal braucht, schreibt sie auf. Bei jeder
|
||||
Störung mit unklarer Ursache, sobald sie gefunden ist.
|
||||
- **Titel = Symptom.** So, wie der Nutzer es am Telefon sagt, mit der Fehlermeldung im Wortlaut.
|
||||
Danach wird gesucht.
|
||||
- **Aufbau:** Symptom, betroffene Systeme und Versionen, Ursache, Lösung in nummerierten Schritten,
|
||||
ggf. Workaround, Verfasser und Datum.
|
||||
- **Eine Lösung, ein Artikel.** Ein Artikel „Alles zu Outlook" findet niemand und pflegt niemand.
|
||||
- **Für wen?** Artikel für den Support dürfen Fachbegriffe und Befehle enthalten. Artikel für
|
||||
Nutzer brauchen Bildschirmfotos und einfache Sprache.
|
||||
- **Keine Zugangsdaten** in Wissensartikeln. Ein Verweis auf den Eintrag im Passwortmanager genügt.
|
||||
- **Mit Tickets verknüpfen:** Im Ticket auf den Artikel verweisen, im Artikel auf Beispieltickets.
|
||||
So sieht man, wie oft er gebraucht wird.
|
||||
- **Pflegen:** Ein Artikel mit veralteter Lösung ist schlimmer als keiner. Wer einen Artikel nutzt
|
||||
und ihn falsch findet, korrigiert ihn sofort oder meldet es.
|
||||
|
||||
## Übersicht
|
||||
|
||||
```
|
||||
Titel: Outlook fragt nach jedem Start erneut nach dem Passwort
|
||||
Gilt für: Outlook (Microsoft 365) unter Windows 11
|
||||
Symptom: Anmeldefenster erscheint bei jedem Start, Passwort wird nicht gespeichert
|
||||
Ursache: Beschädigter Eintrag in der Windows-Anmeldeinformationsverwaltung
|
||||
Lösung: 1. Outlook schließen
|
||||
2. Systemsteuerung → Anmeldeinformationsverwaltung → Windows-Anmeldeinformationen
|
||||
3. Alle Einträge mit „MicrosoftOffice" entfernen
|
||||
4. Outlook starten und einmal anmelden
|
||||
Prüfen: Outlook schließen und erneut starten – keine Abfrage mehr
|
||||
Stand: 2026-10-05, Ausbildung IT
|
||||
Tickets: #4711, #4733
|
||||
```
|
||||
|
||||
## Prüfungsfrage
|
||||
|
||||
**Frage:** Ihr Team beantwortet dieselben Fragen immer wieder neu, obwohl es ein Wiki gibt.
|
||||
Nennen Sie drei mögliche Ursachen und je eine Maßnahme.
|
||||
|
||||
**Antwort:** (1) Die Artikel sind nicht auffindbar, weil die Titel technisch statt nach Symptom
|
||||
formuliert sind – Titel nach den Worten der Nutzer und mit Fehlermeldung formulieren. (2) Die
|
||||
Artikel sind veraltet, deshalb traut ihnen niemand – Datum und Verantwortlichen angeben und
|
||||
beim Gebrauch prüfen und korrigieren. (3) Schreiben gehört nicht zum Ablauf – festlegen, dass beim
|
||||
Schließen eines Tickets mit neuer Lösung ein Artikel angelegt oder verknüpft wird. Ebenfalls
|
||||
richtig: zu lange Sammelartikel aufteilen, Artikel mit Tickets verknüpfen, Suche im Ticketsystem
|
||||
statt in einem getrennten Wiki.
|
||||
@@ -0,0 +1,64 @@
|
||||
---
|
||||
id: H4
|
||||
titel: Ergonomie am Bildschirmarbeitsplatz
|
||||
block: hardware
|
||||
woche: 16
|
||||
worum: Wer einen Arbeitsplatz einrichtet, richtet ihn für acht Stunden am Tag und viele Jahre ein. Nacken, Augen und Handgelenke merken jeden Zentimeter, den der Bildschirm falsch steht.
|
||||
rahmenplan: [C3, A2, A7]
|
||||
lernfeld: LF2
|
||||
merksatz: Oberkante auf Augenhöhe, eine Armlänge Abstand, seitlich zum Fenster. Füße flach, Arme im rechten Winkel. Und zwischendurch aufstehen.
|
||||
karten:
|
||||
- frage: Wie wird ein Bildschirm richtig aufgestellt?
|
||||
antwort: Die oberste Zeile liegt auf oder leicht unter Augenhöhe, der Abstand beträgt etwa eine Armlänge (rund 50 bis 70 cm), und die Blickrichtung verläuft parallel zum Fenster, damit weder Spiegelungen noch Blendung entstehen.
|
||||
- frage: Welche Vorschrift regelt die Anforderungen an Bildschirmarbeitsplätze?
|
||||
antwort: Die Arbeitsstättenverordnung (ArbStättV), Anhang Nr. 6. Sie hat 2016 die frühere Bildschirmarbeitsverordnung abgelöst. Der Arbeitgeber muss die Gefährdungen in einer Gefährdungsbeurteilung ermitteln.
|
||||
- frage: Was muss der Arbeitgeber Beschäftigten an Bildschirmarbeitsplätzen zur Augenvorsorge anbieten?
|
||||
antwort: Eine arbeitsmedizinische Angebotsvorsorge mit Untersuchung der Augen und des Sehvermögens. Ergibt sie, dass eine spezielle Sehhilfe für die Bildschirmarbeit nötig ist, muss der Arbeitgeber sie bezahlen.
|
||||
---
|
||||
|
||||
## Das Wesentliche
|
||||
|
||||
- **Bildschirm:** Oberste Zeile auf oder knapp unter Augenhöhe, sodass der Blick leicht nach
|
||||
unten geht. Abstand etwa eine Armlänge. Zwei Bildschirme gleich hoch, der Hauptbildschirm
|
||||
direkt vor dem Körper.
|
||||
- **Licht:** Blickrichtung parallel zum Fenster, nicht davor und nicht mit dem Rücken dazu.
|
||||
Keine Lampe, die sich im Bildschirm spiegelt. Für Büroarbeit sind 500 Lux am Arbeitsplatz
|
||||
vorgesehen.
|
||||
- **Stuhl:** Füße flach auf dem Boden, Oberschenkel etwa waagerecht, Rückenlehne stützt den
|
||||
unteren Rücken. Die Armlehnen so hoch, dass die Schultern locker bleiben.
|
||||
- **Tisch:** Unterarme liegen bei entspannten Schultern etwa waagerecht auf, die Ellbogen im
|
||||
rechten Winkel. Höhenverstellbare Tische erlauben den Wechsel zwischen Sitzen und Stehen.
|
||||
- **Tastatur und Maus:** Vor dem Körper, etwa eine Handbreite Platz zur Tischkante. Die Maus
|
||||
direkt neben der Tastatur, nicht am ausgestreckten Arm.
|
||||
- **Notebooks** sind für Unterwegs. Wer täglich stundenlang daran arbeitet, braucht
|
||||
Dockingstation, externen Bildschirm, Tastatur und Maus – sonst ist der Blick dauerhaft zu tief.
|
||||
- **Bewegung:** Bildschirmarbeit wird durch andere Tätigkeiten oder Pausen unterbrochen. Kein
|
||||
Stuhl gleicht acht Stunden Stillsitzen aus.
|
||||
- **Rechtlicher Rahmen:** Arbeitsstättenverordnung, Anhang Nr. 6. Der Arbeitgeber ermittelt die
|
||||
Belastungen in der Gefährdungsbeurteilung und bietet arbeitsmedizinische Vorsorge für die
|
||||
Augen an.
|
||||
|
||||
## Übersicht
|
||||
|
||||
| Beschwerde | Wahrscheinliche Ursache | Abhilfe |
|
||||
|---|---|---|
|
||||
| Nackenschmerzen | Bildschirm zu hoch, zu tief oder seitlich versetzt | Höhe und Position anpassen, Hauptbildschirm mittig |
|
||||
| Brennende, müde Augen | Spiegelungen, Blendung, zu kleine Schrift | Bildschirm drehen, Licht ändern, Skalierung erhöhen |
|
||||
| Verspannte Schultern | Tisch zu hoch, Armlehnen falsch | Stuhl und Armlehnen nachstellen, Tischhöhe anpassen |
|
||||
| Schmerzen im Handgelenk | abgeknickte Hand, Maus zu weit weg | Maus heran, Handballen auflegen, ggf. vertikale Maus |
|
||||
| Rückenschmerzen | Rückenlehne nicht genutzt, zu langes Sitzen | Lehne einstellen, Steh-Phasen, Bewegungspausen |
|
||||
|
||||
## Prüfungsfrage
|
||||
|
||||
**Frage:** Eine Mitarbeiterin klagt über Nackenschmerzen und brennende Augen. Ihr Bildschirm
|
||||
steht seitlich neben dem Notebook, mit dem Fenster im Rücken. Nennen Sie vier Maßnahmen und
|
||||
begründen Sie zwei davon.
|
||||
|
||||
**Antwort:** (1) Den Bildschirm direkt vor die Mitarbeiterin stellen, damit sie den Kopf nicht
|
||||
dauerhaft dreht – Ursache der Nackenschmerzen. (2) Die Höhe so einstellen, dass die oberste Zeile
|
||||
auf oder leicht unter Augenhöhe liegt. (3) Den Arbeitsplatz so drehen, dass die Blickrichtung
|
||||
parallel zum Fenster verläuft – mit dem Fenster im Rücken spiegelt es sich im Bildschirm, und
|
||||
die Augen ermüden. (4) Notebook mit Dockingstation, externer Tastatur und Maus betreiben, statt auf
|
||||
den Notebook-Bildschirm zu schauen. (5) Schriftgröße bzw. Skalierung erhöhen. (6) Auf die
|
||||
Angebotsvorsorge für die Augen hinweisen; ggf. ist eine Bildschirmarbeitsbrille nötig, die der
|
||||
Arbeitgeber bezahlt.
|
||||
@@ -0,0 +1,60 @@
|
||||
---
|
||||
id: H5
|
||||
titel: Energie rechnen und nachhaltig beschaffen
|
||||
block: hardware
|
||||
woche: 16
|
||||
worum: Ein Rechner, der nachts läuft, kostet Geld und Strom, ohne dass jemand etwas davon hat. Wer den Verbrauch rechnen kann, kann Entscheidungen begründen – auch beim Kauf und bei der Entsorgung.
|
||||
rahmenplan: [C4, A3, A6]
|
||||
lernfeld: LF2
|
||||
merksatz: Leistung in kW mal Stunden mal Preis je kWh. Länger nutzen schlägt sparsamer kaufen. Daten vernichten, bevor das Gerät den Betrieb verlässt.
|
||||
karten:
|
||||
- frage: Wie berechnet man die Stromkosten eines Geräts?
|
||||
antwort: Leistung in Kilowatt mal Betriebsstunden ergibt die Energie in Kilowattstunden, mal Preis je kWh ergibt die Kosten. Ein Server mit 150 W, der das ganze Jahr läuft – 0,15 kW × 8.760 h = 1.314 kWh, bei 0,30 € je kWh also 394,20 €.
|
||||
- frage: Welche Norm regelt die Vernichtung von Datenträgern, und welche Sicherheitsstufe ist für personenbezogene Daten üblich?
|
||||
antwort: DIN 66399. Sie kennt drei Schutzklassen und sieben Sicherheitsstufen. Für personenbezogene Daten wird in der Regel mindestens Sicherheitsstufe 3 angesetzt, für besonders schützenswerte Daten wie Gesundheitsdaten höher.
|
||||
- frage: Warum ist eine längere Nutzung oft nachhaltiger als ein sparsameres neues Gerät?
|
||||
antwort: Weil ein großer Teil der Umweltbelastung eines Rechners bei der Herstellung entsteht, nicht im Betrieb. Ein Gerät ein, zwei Jahre länger zu nutzen, spart meist mehr als der geringere Verbrauch eines neuen.
|
||||
---
|
||||
|
||||
## Das Wesentliche
|
||||
|
||||
- **Die Formel:** Leistung (kW) × Zeit (h) = Energie (kWh). Energie × Preis je kWh = Kosten.
|
||||
Watt erst durch 1.000 teilen, sonst stimmt die Kommastelle nicht.
|
||||
- **Die Stunden richtig zählen:** Ein Arbeitsplatz läuft etwa 8 Stunden an 220 Arbeitstagen,
|
||||
ein Server 24 Stunden an 365 Tagen, also 8.760 Stunden.
|
||||
- **Leerlauf kostet am meisten**, weil er die meisten Stunden hat. Ruhezustand und
|
||||
Energiesparpläne per Gruppenrichtlinie, Abschalten über Nacht, Drucker mit Ruhemodus.
|
||||
- **Beim Kauf:** Verbrauch im Leerlauf und unter Last vergleichen, Energielabel bei Bildschirmen,
|
||||
Siegel wie TCO Certified, Blauer Engel, EPEAT oder ENERGY STAR. Netzteile mit hohem
|
||||
Wirkungsgrad (80 PLUS).
|
||||
- **Länger nutzen:** Ein großer Teil der Umweltbelastung entsteht bei der Herstellung. Aufrüsten
|
||||
(SSD, Arbeitsspeicher), Reparieren und Weitergeben sind oft nachhaltiger als ein neues Gerät.
|
||||
Aufbereitete Geräte (refurbished) sind für viele Arbeitsplätze eine gute Wahl.
|
||||
- **Entsorgen:** Elektrogeräte gehören nicht in den Restmüll. Nach dem Elektro- und
|
||||
Elektronikgerätegesetz (ElektroG) gehen sie über Rücknahmestellen oder zertifizierte
|
||||
Entsorger zurück in die Verwertung.
|
||||
- **Vorher die Daten:** Datenträger werden vor der Abgabe nachweisbar gelöscht oder vernichtet –
|
||||
nach DIN 66399, mit Protokoll. Ein formatierter Datenträger ist nicht gelöscht.
|
||||
|
||||
## Übersicht
|
||||
|
||||
| Gerät | Leistung | Stunden im Jahr | kWh | Kosten bei 0,30 €/kWh |
|
||||
|---|---|---|---|---|
|
||||
| Arbeitsplatzrechner, 8 h an 220 Tagen | 45 W | 1.760 | 79,2 | 23,76 € |
|
||||
| Server, durchgehend | 150 W | 8.760 | 1.314 | 394,20 € |
|
||||
| Rechner, der außerhalb der Arbeitszeit im Leerlauf läuft | 30 W | 7.000 | 210 | 63,00 € |
|
||||
|
||||
Bei 100 Rechnern, die nachts und am Wochenende nicht ausgeschaltet werden, sind das allein für
|
||||
den Leerlauf 6.300 € im Jahr.
|
||||
|
||||
## Prüfungsfrage
|
||||
|
||||
**Frage:** In einem Betrieb laufen 60 Arbeitsplatzrechner rund um die Uhr. Im Leerlauf nimmt jeder
|
||||
35 W auf. Wie viel ließe sich im Jahr sparen, wenn die Rechner außerhalb der Arbeitszeit
|
||||
(8 Stunden an 220 Tagen) ausgeschaltet würden? Strompreis 0,30 € je kWh.
|
||||
|
||||
**Antwort:** Stunden außerhalb der Arbeitszeit: 8.760 h − (8 h × 220) = 8.760 h − 1.760 h =
|
||||
7.000 h. Energie je Rechner: 0,035 kW × 7.000 h = 245 kWh. Für 60 Rechner: 245 kWh × 60 =
|
||||
14.700 kWh. Ersparnis: 14.700 kWh × 0,30 €/kWh = **4.410 €** im Jahr. Hinzu kommt, dass
|
||||
ausgeschaltete Rechner nachts nicht angegriffen werden können; Updates lassen sich mit
|
||||
Wake-on-LAN trotzdem außerhalb der Arbeitszeit einspielen.
|
||||
@@ -0,0 +1,95 @@
|
||||
---
|
||||
id: P4
|
||||
titel: Pseudocode, Struktogramm und Schreibtischtest
|
||||
block: programmierung
|
||||
woche: 16
|
||||
worum: In der Prüfung schreibt man keinen lauffähigen Code, sondern beschreibt den Ablauf so, dass ihn jeder umsetzen kann. Drei Bausteine genügen – Folge, Verzweigung, Schleife.
|
||||
rahmenplan: [A10, A4]
|
||||
lernfeld: LF5
|
||||
merksatz: Erst den Ablauf in Worten, dann in Pseudocode. Jede Schleife braucht ein Ende. Mit einem Schreibtischtest prüfen, bevor man abgibt.
|
||||
karten:
|
||||
- frage: Was unterscheidet eine kopfgesteuerte von einer fußgesteuerten Schleife?
|
||||
antwort: Die kopfgesteuerte Schleife (SOLANGE … ENDE SOLANGE) prüft die Bedingung vor jedem Durchlauf und läuft unter Umständen gar nicht. Die fußgesteuerte (WIEDERHOLE … BIS) prüft erst danach und läuft deshalb mindestens einmal.
|
||||
- frage: Was ist ein Schreibtischtest?
|
||||
antwort: Man spielt einen Algorithmus von Hand mit Beispielwerten durch und notiert in einer Tabelle nach jedem Schritt die Werte aller Variablen. So findet man Fehler, ohne den Code auszuführen.
|
||||
- frage: Was liefert dieser Ablauf für die Liste 72, 91, 85, 60 – zaehler ← 0; FÜR jeden wert IN liste – WENN wert > 80 DANN zaehler ← zaehler + 1?
|
||||
antwort: 2, denn nur 91 und 85 sind größer als 80.
|
||||
---
|
||||
|
||||
## Das Wesentliche
|
||||
|
||||
- **Drei Bausteine** reichen für jeden Ablauf: **Folge** (Schritt für Schritt), **Verzweigung**
|
||||
(WENN … DANN … SONST), **Schleife** (wiederholen, bis etwas erreicht ist).
|
||||
- **Pseudocode** ist strukturierte Umgangssprache mit festen Schlüsselwörtern. In der Prüfung
|
||||
gibt es keine verbindliche Schreibweise; wichtig ist, dass Einrückung und Schlüsselwörter
|
||||
eindeutig zeigen, was wozu gehört.
|
||||
- **Zuweisung:** `summe ← 0` – die Variable bekommt einen Wert. Vergleich: `summe = 0`.
|
||||
- **Schleifen:**
|
||||
- `FÜR i ← 1 BIS n` – Anzahl der Durchläufe steht vorher fest
|
||||
- `SOLANGE bedingung` – kopfgesteuert, prüft vorher, läuft eventuell nie
|
||||
- `WIEDERHOLE … BIS bedingung` – fußgesteuert, läuft mindestens einmal
|
||||
- **Struktogramm (Nassi-Shneiderman):** Der Ablauf als Kasten; eine Verzweigung teilt den Kasten
|
||||
mit einem Dreieck in Ja und Nein, eine Schleife umschließt die zu wiederholenden Schritte.
|
||||
Sprünge gibt es nicht.
|
||||
- **Programmablaufplan (PAP):** Ablauf mit Symbolen nach DIN 66001 – Oval für Start und Ende,
|
||||
Rechteck für Tätigkeiten, Raute für Entscheidungen, Parallelogramm für Ein- und Ausgabe.
|
||||
- **Schreibtischtest:** Beispielwerte wählen, Schritt für Schritt durchgehen und die Werte aller
|
||||
Variablen in einer Tabelle festhalten. Grenzfälle mitnehmen: leere Liste, ein Element, genau
|
||||
der Grenzwert.
|
||||
|
||||
## Übersicht
|
||||
|
||||
Gesucht: Wie viele Server haben mehr als 80 % Plattenbelegung, und wie hoch ist die höchste?
|
||||
|
||||
```
|
||||
anzahlKritisch ← 0
|
||||
maximum ← belegung[0]
|
||||
FÜR i ← 0 BIS laenge(belegung) − 1
|
||||
WENN belegung[i] > 80 DANN
|
||||
anzahlKritisch ← anzahlKritisch + 1
|
||||
ENDE WENN
|
||||
WENN belegung[i] > maximum DANN
|
||||
maximum ← belegung[i]
|
||||
ENDE WENN
|
||||
ENDE FÜR
|
||||
AUSGABE anzahlKritisch, maximum
|
||||
```
|
||||
|
||||
Schreibtischtest mit `belegung = [72, 91, 85, 60]` – „Wert" ist `belegung[i]`, „Anzahl" ist
|
||||
`anzahlKritisch`, „Max." ist `maximum`:
|
||||
|
||||
| i | Wert | > 80? | Anzahl | Max. |
|
||||
|---|---|---|---|---|
|
||||
| – | – | – | 0 | 72 |
|
||||
| 0 | 72 | nein | 0 | 72 |
|
||||
| 1 | 91 | ja | 1 | 91 |
|
||||
| 2 | 85 | ja | 2 | 91 |
|
||||
| 3 | 60 | nein | 2 | 91 |
|
||||
|
||||
Ausgabe: 2 und 91.
|
||||
|
||||
## Prüfungsfrage
|
||||
|
||||
**Frage:** Ein Prüfprogramm erhält eine Liste von Messwerten. Ein Wert ist in Ordnung, wenn er
|
||||
zwischen 9,8 und 10,2 liegt (Grenzen eingeschlossen). Schreiben Sie einen Pseudocode, der
|
||||
ausgibt, wie viele Werte außerhalb der Toleranz liegen, und ob mehr als 5 % der Werte betroffen
|
||||
sind.
|
||||
|
||||
**Antwort:**
|
||||
|
||||
```
|
||||
ausserhalb ← 0
|
||||
FÜR jeden wert IN messwerte
|
||||
WENN wert < 9,8 ODER wert > 10,2 DANN
|
||||
ausserhalb ← ausserhalb + 1
|
||||
ENDE WENN
|
||||
ENDE FÜR
|
||||
AUSGABE ausserhalb
|
||||
WENN laenge(messwerte) > 0 UND ausserhalb / laenge(messwerte) > 0,05 DANN
|
||||
AUSGABE "Mehr als 5 % außerhalb der Toleranz"
|
||||
ENDE WENN
|
||||
```
|
||||
|
||||
Die Bedingung prüft beide Grenzen mit ODER, weil ein Wert entweder zu klein oder zu groß sein
|
||||
kann. Die Grenzwerte selbst gelten als in Ordnung, deshalb `<` und `>` statt `≤` und `≥`. Die
|
||||
Prüfung auf eine leere Liste verhindert eine Division durch null.
|
||||
@@ -0,0 +1,64 @@
|
||||
---
|
||||
id: S10
|
||||
titel: Protokolle lesen – und warum die Uhrzeit stimmen muss
|
||||
block: system
|
||||
woche: 14
|
||||
worum: Protokolle sagen, was passiert ist. Aber nur, wenn man weiß, wo man suchen muss, und wenn die Uhren aller Systeme übereinstimmen.
|
||||
rahmenplan: [A8, A6, B3]
|
||||
lernfeld: LF11
|
||||
merksatz: Zeitpunkt eingrenzen, dann suchen. Alle Uhren per NTP gleich. Protokolle enthalten personenbezogene Daten.
|
||||
karten:
|
||||
- frage: Welche drei Protokolle der Windows-Ereignisanzeige sind für die Fehlersuche am wichtigsten?
|
||||
antwort: System (Treiber, Dienste, Neustarts), Anwendung (Meldungen der Programme) und Sicherheit (Anmeldungen, Zugriffe, Änderungen an Konten).
|
||||
- frage: Warum muss die Uhrzeit auf allen Systemen übereinstimmen?
|
||||
antwort: Damit sich Ereignisse aus verschiedenen Protokollen einander zuordnen lassen, und weil Kerberos-Anmeldungen im Active Directory scheitern, wenn die Uhren um mehr als fünf Minuten abweichen.
|
||||
- frage: Was bedeuten die Ereignis-IDs 4624 und 4625 im Sicherheitsprotokoll von Windows?
|
||||
antwort: 4624 ist eine erfolgreiche Anmeldung, 4625 eine fehlgeschlagene. Viele 4625 in kurzer Zeit für dasselbe Konto deuten auf Passwortraten hin.
|
||||
---
|
||||
|
||||
## Das Wesentliche
|
||||
|
||||
- **Erst den Zeitpunkt eingrenzen, dann suchen.** „Seit wann?" ist die wichtigste Frage bei
|
||||
jeder Störung. Wer den Zeitraum kennt, findet die Ursache im Protokoll in Minuten statt
|
||||
Stunden.
|
||||
- **Windows – Ereignisanzeige:** Protokoll *System* für Dienste, Treiber und Neustarts,
|
||||
*Anwendung* für Programme, *Sicherheit* für Anmeldungen und Zugriffe. Filtern nach Zeitraum,
|
||||
Ebene (Fehler, Warnung) und Ereignis-ID.
|
||||
- **Linux – Journal:** `journalctl --since "2026-10-05 08:00" --until "09:00"`, `-u dienst`
|
||||
für einen Dienst, `-p err` für Fehler. Klassische Textdateien unter `/var/log`.
|
||||
- **Bekannte Ereignis-IDs sparen Zeit:** 4624 Anmeldung erfolgreich, 4625 fehlgeschlagen,
|
||||
4740 Konto gesperrt, 6008 unerwartetes Herunterfahren, 41 (Kernel-Power) Neustart ohne
|
||||
sauberes Herunterfahren.
|
||||
- **Zeitsynchronisation:** Alle Systeme beziehen ihre Zeit per **NTP** aus derselben Quelle –
|
||||
in einer Domäne vom Domänencontroller, dieser von einer verlässlichen externen Quelle.
|
||||
Weichen Uhren um mehr als fünf Minuten ab, scheitert die Anmeldung über Kerberos.
|
||||
- **Zentral sammeln:** Bei mehr als einer Handvoll Systeme gehören die Protokolle an einen
|
||||
zentralen Ort. Dann lässt sich eine Anmeldung über mehrere Systeme verfolgen – und ein
|
||||
Angreifer kann seine Spuren nicht auf dem befallenen System löschen.
|
||||
- **Protokolle sind personenbezogen.** Sie zeigen, wer sich wann wo angemeldet hat. Deshalb:
|
||||
Aufbewahrung begrenzen, Zugriff beschränken, nur für den vereinbarten Zweck auswerten.
|
||||
|
||||
## Übersicht
|
||||
|
||||
| Frage | Windows | Linux |
|
||||
|---|---|---|
|
||||
| Warum ist der Server neu gestartet? | System, Ereignis 6008 bzw. 41 und 1074 | `journalctl --list-boots`, `last -x reboot` |
|
||||
| Wer hat sich angemeldet? | Sicherheit, Ereignis 4624 | `last`, `journalctl -u ssh` |
|
||||
| Warum startet der Dienst nicht? | System, Quelle „Service Control Manager" | `systemctl status`, `journalctl -u dienst` |
|
||||
| Stimmt die Uhrzeit? | `w32tm /query /status` | `timedatectl` |
|
||||
|
||||
## Prüfungsfrage
|
||||
|
||||
**Frage:** Mehrere Benutzer können sich seit heute Morgen nicht mehr an der Domäne anmelden,
|
||||
andere schon. Die Fehlermeldung nennt einen Zeitunterschied. Erklären Sie die Ursache und Ihr
|
||||
Vorgehen.
|
||||
|
||||
**Antwort:** Die Anmeldung im Active Directory erfolgt über Kerberos, das nur eine geringe
|
||||
Abweichung der Uhrzeiten zwischen Client und Domänencontroller zulässt (standardmäßig fünf
|
||||
Minuten). Bei den betroffenen Rechnern geht die Uhr vermutlich falsch, etwa weil die
|
||||
Zeitsynchronisation nicht läuft oder eine leere CMOS-Batterie die Uhr nach einem Neustart
|
||||
zurückgesetzt hat. Vorgehen: (1) Auf einem betroffenen Client mit `w32tm /query /status`
|
||||
Zeitquelle und Abweichung prüfen. (2) Prüfen, ob der Domänencontroller selbst die richtige
|
||||
Zeit hat und von einer verlässlichen Quelle bezieht. (3) Die Zeit mit `w32tm /resync`
|
||||
synchronisieren und die Anmeldung testen. (4) Die Ursache beheben – Zeitdienst, Gruppenrichtlinie
|
||||
für die Zeitquelle oder Batterie – und die Zeitabweichung in die Überwachung aufnehmen.
|
||||
@@ -0,0 +1,64 @@
|
||||
---
|
||||
id: S11
|
||||
titel: Updates und Patches – planbar statt hektisch
|
||||
block: system
|
||||
woche: 14
|
||||
worum: Die meisten erfolgreichen Angriffe nutzen Lücken, für die es längst ein Update gibt. Patch-Management sorgt dafür, dass Updates zuverlässig ankommen, ohne dass dabei der Betrieb stehen bleibt.
|
||||
rahmenplan: [A8, A6, A5]
|
||||
lernfeld: LF11
|
||||
merksatz: Wissen, was läuft. Erst Test, dann Pilotgruppe, dann alle. Kritische Lücken sofort, der Rest im festen Takt.
|
||||
karten:
|
||||
- frage: In welcher Reihenfolge verteilt man Updates im Betrieb?
|
||||
antwort: Zuerst auf Testsysteme, dann auf eine kleine Pilotgruppe aus normalen Arbeitsplätzen, und erst wenn dort nach einigen Tagen nichts auffällt, auf alle. Server in einem angekündigten Wartungsfenster.
|
||||
- frage: Wann ist der Patchday von Microsoft?
|
||||
antwort: Am zweiten Dienstag jedes Monats. Für Lücken, die bereits aktiv ausgenutzt werden, erscheinen zusätzlich außerplanmäßige Updates.
|
||||
- frage: Was bedeutet End of Life bei Software, und was folgt daraus?
|
||||
antwort: Der Hersteller liefert keine Sicherheitsupdates mehr – neue Lücken bleiben für immer offen. Solche Software muss ersetzt oder, wenn das nicht sofort geht, vom Netz getrennt und besonders abgesichert werden. Beispiel – Windows 10 seit dem 14. Oktober 2025.
|
||||
---
|
||||
|
||||
## Das Wesentliche
|
||||
|
||||
- **Ohne Bestand kein Patch-Management.** Man muss wissen, welche Geräte, Betriebssysteme und
|
||||
Programme mit welcher Version im Betrieb laufen. Was nicht in der Liste steht, wird auch nicht
|
||||
aktualisiert.
|
||||
- **Fester Takt:** Microsoft veröffentlicht am **zweiten Dienstag** im Monat. Viele Betriebe
|
||||
planen danach: Test in der Woche danach, Pilotgruppe, dann alle innerhalb von zwei bis drei
|
||||
Wochen.
|
||||
- **Ringe statt alle auf einmal:** Testsysteme, Pilotgruppe (die IT selbst und einige
|
||||
freiwillige Nutzer), dann alle. Ein fehlerhaftes Update trifft so zehn Rechner, nicht hundert.
|
||||
- **Kritische Lücken außer der Reihe.** Wird eine Lücke bereits aktiv ausgenutzt, wird sofort
|
||||
gehandelt – notfalls mit verkürztem Test. Hinweise liefern der Hersteller und die Warnungen
|
||||
des BSI.
|
||||
- **Nicht nur Windows:** Programme wie Browser und PDF-Leser, Firmware von Firewall, Switch, NAS
|
||||
und BIOS, Linux-Server, Smartphones. Gerade Netzwerkgeräte werden oft jahrelang vergessen.
|
||||
- **Server im Wartungsfenster**, angekündigt, mit Snapshot oder Sicherung vorher und einem
|
||||
Rückweg, falls etwas schiefgeht.
|
||||
- **Nachprüfen:** Kam das Update überall an? Ein Bericht über den Stand aller Geräte gehört zum
|
||||
Abschluss jedes Zyklus.
|
||||
- **End of Life im Blick behalten.** Software ohne Sicherheitsupdates wird rechtzeitig ersetzt –
|
||||
das Ende ist Jahre vorher bekannt.
|
||||
|
||||
## Übersicht
|
||||
|
||||
| Ring | Wer | Wann nach Veröffentlichung |
|
||||
|---|---|---|
|
||||
| 0 – Test | Testsysteme der IT | sofort |
|
||||
| 1 – Pilot | IT und einige freiwillige Nutzer | nach 2–3 Tagen |
|
||||
| 2 – Breit | alle Arbeitsplätze | nach etwa einer Woche |
|
||||
| 3 – Server | Server im Wartungsfenster | nach etwa zwei Wochen |
|
||||
| Notfall | alle betroffenen Systeme | sofort, bei aktiv ausgenutzter Lücke |
|
||||
|
||||
## Prüfungsfrage
|
||||
|
||||
**Frage:** In Ihrem Betrieb werden Updates bisher „wenn jemand Zeit hat" eingespielt.
|
||||
Entwerfen Sie ein Vorgehen für das Patch-Management und begründen Sie zwei Bestandteile.
|
||||
|
||||
**Antwort:** (1) Einen vollständigen Bestand aller Geräte und Programme mit Version führen.
|
||||
(2) Einen festen Takt nach dem monatlichen Patchday festlegen. (3) Updates in Ringen verteilen:
|
||||
Testsysteme, Pilotgruppe, alle Arbeitsplätze, Server im angekündigten Wartungsfenster mit
|
||||
Sicherung vorher. (4) Für aktiv ausgenutzte Lücken ein beschleunigtes Notfallverfahren
|
||||
vorsehen. (5) Nach jedem Zyklus prüfen und berichten, auf welchem Stand alle Geräte sind.
|
||||
(6) Firmware von Netzwerkgeräten und Software ohne automatische Aktualisierung einbeziehen.
|
||||
Begründungen etwa: Die Ringe begrenzen den Schaden eines fehlerhaften Updates auf wenige
|
||||
Geräte. Der Bestand ist Voraussetzung, weil ein Gerät, das niemand kennt, auch nie aktualisiert
|
||||
wird – und genau dort sitzt dann die Lücke.
|
||||
@@ -0,0 +1,62 @@
|
||||
---
|
||||
id: S6
|
||||
titel: Linux – Dateisystem und die Befehle für jeden Tag
|
||||
block: system
|
||||
woche: 13
|
||||
worum: Unter Linux gibt es keine Laufwerksbuchstaben, sondern einen einzigen Verzeichnisbaum. Wer weiß, wo was liegt, findet Konfiguration und Fehler in Minuten.
|
||||
rahmenplan: [B3, A8]
|
||||
lernfeld: LF9
|
||||
merksatz: Konfiguration in /etc, Protokolle in /var/log, Benutzer in /home. Erst lesen mit less und grep, dann ändern.
|
||||
karten:
|
||||
- frage: Wo liegen unter Linux die Konfigurationsdateien und wo die Protokolle?
|
||||
antwort: Konfiguration in /etc, etwa /etc/ssh/sshd_config. Protokolle in /var/log und im Journal von systemd, das man mit journalctl liest.
|
||||
- frage: Was zeigen df -h und du -sh?
|
||||
antwort: df -h zeigt die Belegung der eingehängten Dateisysteme, also wie voll jede Platte ist. du -sh zeigt, wie viel Platz ein bestimmtes Verzeichnis belegt – damit findet man, wer die Platte füllt.
|
||||
- frage: Wie findet man alle Zeilen mit „error" in den Protokollen unter /var/log, ohne Groß- und Kleinschreibung zu beachten?
|
||||
antwort: Mit grep -ri error /var/log – r durchsucht die Unterverzeichnisse, i ignoriert die Schreibweise. Für das Journal von systemd stattdessen journalctl -p err.
|
||||
---
|
||||
|
||||
## Das Wesentliche
|
||||
|
||||
- **Ein Baum ab `/`.** Weitere Platten und Freigaben werden irgendwo in diesen Baum
|
||||
eingehängt, etwa unter `/mnt` oder `/srv`.
|
||||
- **Die wichtigsten Orte:** `/etc` Konfiguration, `/var/log` Protokolle, `/home` die
|
||||
Benutzer, `/root` der Administrator, `/usr/bin` Programme, `/tmp` Zwischendateien,
|
||||
`/opt` und `/srv` für eigene Anwendungen und Daten.
|
||||
- **Groß- und Kleinschreibung zählt.** `Bericht.txt` und `bericht.txt` sind zwei Dateien.
|
||||
- **Navigieren:** `pwd` (wo bin ich?), `ls -la` (was liegt hier, auch versteckt, mit Rechten),
|
||||
`cd` (wechseln), `cd ~` (nach Hause), `cd -` (zurück).
|
||||
- **Dateien:** `cp`, `mv`, `rm`, `mkdir -p`. `rm -r` löscht ohne Papierkorb und ohne
|
||||
Rückfrage – vorher mit `ls` prüfen, was getroffen wird.
|
||||
- **Lesen:** `less` zum Blättern (`/` sucht, `q` beendet), `tail -f` zum Mitlesen eines
|
||||
wachsenden Protokolls, `grep` zum Suchen in Dateien.
|
||||
- **Finden:** `find /etc -name "*.conf"` nach Namen, `find /var -size +500M` nach Größe.
|
||||
- **Platz:** `df -h` für die Platten, `du -sh /var/*` für die Verzeichnisse darin.
|
||||
- **Bearbeiten:** `nano` ist für den Anfang der freundlichste Editor. Vor jeder Änderung eine
|
||||
Kopie: `cp datei datei.bak`.
|
||||
- **Hilfe:** `man befehl` oder `befehl --help`.
|
||||
|
||||
## Übersicht
|
||||
|
||||
| Frage | Befehl |
|
||||
|---|---|
|
||||
| Wie voll sind die Platten? | `df -h` |
|
||||
| Welches Verzeichnis ist so groß? | `du -sh /var/* \| sort -h` |
|
||||
| Was steht zuletzt im Protokoll? | `tail -n 50 /var/log/syslog` oder `journalctl -n 50` |
|
||||
| Welche Netzwerkadressen habe ich? | `ip a` |
|
||||
| Welche Ports sind offen? | `ss -tlnp` |
|
||||
| Welche Prozesse brauchen Leistung? | `top` oder `htop` |
|
||||
| Welche Distribution läuft? | `cat /etc/os-release` |
|
||||
|
||||
## Prüfungsfrage
|
||||
|
||||
**Frage:** Ein Linux-Server meldet, dass die Platte voll ist. Beschreiben Sie mit Befehlen,
|
||||
wie Sie die Ursache finden.
|
||||
|
||||
**Antwort:** (1) Mit `df -h` prüfen, welches Dateisystem voll ist und wo es eingehängt ist.
|
||||
(2) Mit `du -sh /pfad/* | sort -h` die Unterverzeichnisse nach Größe sortieren und schrittweise
|
||||
in das größte hineingehen, bis die Ursache gefunden ist – häufig sind es Protokolle unter
|
||||
`/var/log`, alte Sicherungen oder ungenutzte Container-Abbilder. (3) Mit `find /pfad -size +1G`
|
||||
gezielt nach sehr großen Dateien suchen. (4) Vor dem Löschen klären, ob die Daten noch
|
||||
gebraucht werden, und bei Protokollen die Ursache beheben, etwa eine fehlende
|
||||
Protokollrotation oder einen Dienst, der in einer Fehlerschleife schreibt.
|
||||
@@ -0,0 +1,60 @@
|
||||
---
|
||||
id: S7
|
||||
titel: Linux – Benutzer, Gruppen und Dateirechte
|
||||
block: system
|
||||
woche: 13
|
||||
worum: Unter Linux hat jede Datei einen Besitzer, eine Gruppe und drei Mal drei Rechte. Das ist einfacher als unter Windows – und genauso schnell falsch gesetzt.
|
||||
rahmenplan: [B3, A6]
|
||||
lernfeld: LF9
|
||||
merksatz: Lesen 4, Schreiben 2, Ausführen 1 – für Besitzer, Gruppe, alle anderen. Täglich arbeiten als Benutzer, Rechte holen mit sudo.
|
||||
karten:
|
||||
- frage: Was bedeutet chmod 640 bericht.txt?
|
||||
antwort: Der Besitzer darf lesen und schreiben (6 = 4 + 2), die Gruppe darf lesen (4), alle anderen dürfen nichts (0).
|
||||
- frage: Was bedeutet das Recht x bei einem Verzeichnis?
|
||||
antwort: Man darf in das Verzeichnis wechseln und auf die Dateien darin zugreifen. Ohne x nützt auch das Leserecht r wenig – man sieht die Namen, kommt aber nicht an die Dateien.
|
||||
- frage: Wie nimmt man einen Benutzer nachträglich in eine Gruppe auf, ohne ihn aus den anderen zu entfernen?
|
||||
antwort: Mit sudo usermod -aG gruppe benutzer. Das a für append ist entscheidend – ohne es ersetzt -G alle bisherigen Zusatzgruppen.
|
||||
---
|
||||
|
||||
## Das Wesentliche
|
||||
|
||||
- **Jede Datei** hat einen Besitzer, eine Gruppe und Rechte für drei Klassen: Besitzer (u),
|
||||
Gruppe (g), alle anderen (o).
|
||||
- **Drei Rechte:** r lesen (4), w schreiben (2), x ausführen (1). Bei Verzeichnissen heißt x:
|
||||
hineinwechseln dürfen.
|
||||
- **Lesen in `ls -l`:** `-rw-r----- 1 anna buchhaltung bericht.txt` – Datei, Besitzerin
|
||||
anna liest und schreibt, Gruppe buchhaltung liest, alle anderen nichts.
|
||||
- **Setzen:** `chmod 640 datei` als Zahl oder `chmod g+w datei` als Zeichen. `chown anna:buchhaltung
|
||||
datei` ändert Besitzer und Gruppe.
|
||||
- **777 ist nie die Lösung.** Wer „Permission denied" mit `chmod 777` beseitigt, hat das Problem
|
||||
versteckt und eine Lücke geöffnet. Richtig ist, Besitzer oder Gruppe passend zu setzen.
|
||||
- **Benutzer:** `sudo adduser anna` legt Benutzer samt Heimatverzeichnis an (Debian, Ubuntu).
|
||||
Gespeichert wird in `/etc/passwd`, die Passwort-Hashes in `/etc/shadow`, Gruppen in
|
||||
`/etc/group`.
|
||||
- **Gruppen:** `sudo usermod -aG gruppe anna`. Wirksam erst nach erneuter Anmeldung.
|
||||
- **root und sudo:** root darf alles. Im Alltag arbeitet man als normaler Benutzer und holt sich
|
||||
Rechte für einen einzelnen Befehl mit `sudo`. Jeder `sudo`-Aufruf wird protokolliert.
|
||||
- **Konto sperren statt löschen**, wenn jemand geht: `sudo usermod -L anna` und
|
||||
`sudo chage -E 0 anna`. So bleibt nachvollziehbar, wem welche Dateien gehörten.
|
||||
|
||||
## Übersicht
|
||||
|
||||
| Zahl | Zeichen | Bedeutung | Typisch für |
|
||||
|---|---|---|---|
|
||||
| 644 | rw-r--r-- | Besitzer schreibt, alle lesen | Konfigurationsdateien, Webseiten |
|
||||
| 640 | rw-r----- | Besitzer schreibt, Gruppe liest | Dateien mit vertraulichem Inhalt |
|
||||
| 600 | rw------- | nur der Besitzer | private Schlüssel, Zugangsdaten |
|
||||
| 755 | rwxr-xr-x | Besitzer schreibt, alle lesen und führen aus | Programme, Verzeichnisse |
|
||||
| 750 | rwxr-x--- | wie 755, aber ohne die anderen | Verzeichnisse einer Abteilung |
|
||||
|
||||
## Prüfungsfrage
|
||||
|
||||
**Frage:** Im Verzeichnis `/srv/einkauf` sollen alle Mitglieder der Gruppe `einkauf` Dateien
|
||||
anlegen und ändern dürfen, andere Benutzer gar nichts. Wie richten Sie das ein?
|
||||
|
||||
**Antwort:** `sudo chown root:einkauf /srv/einkauf` setzt die Gruppe; `sudo chmod 2770
|
||||
/srv/einkauf` gibt Besitzer und Gruppe Lesen, Schreiben und Hineinwechseln und den anderen
|
||||
nichts. Die vorangestellte 2 setzt das setgid-Bit: Neue Dateien im Verzeichnis gehören dann
|
||||
automatisch der Gruppe `einkauf` statt der primären Gruppe ihres Erstellers – sonst könnten die
|
||||
Kollegen eine neu angelegte Datei womöglich nicht ändern. Die Benutzer kommen mit `sudo usermod
|
||||
-aG einkauf benutzer` in die Gruppe und müssen sich danach neu anmelden.
|
||||
@@ -0,0 +1,63 @@
|
||||
---
|
||||
id: S8
|
||||
titel: Linux – Pakete, Dienste und Fernzugang per SSH
|
||||
block: system
|
||||
woche: 13
|
||||
worum: Ein Linux-Server wird über drei Werkzeuge betrieben – den Paketmanager, systemd und SSH. Wer die drei beherrscht, kann fast jeden Server pflegen.
|
||||
rahmenplan: [B3, A6, A8]
|
||||
lernfeld: LF9
|
||||
merksatz: apt für Software, systemctl für Dienste, journalctl für Protokolle, SSH nur mit Schlüssel. Zweite Sitzung offen lassen, bevor man den Zugang ändert.
|
||||
karten:
|
||||
- frage: Was ist der Unterschied zwischen systemctl start und systemctl enable?
|
||||
antwort: start startet den Dienst jetzt, enable sorgt dafür, dass er bei jedem Systemstart mitstartet. systemctl enable --now erledigt beides auf einmal.
|
||||
- frage: Warum meldet man sich per SSH mit Schlüssel statt mit Passwort an?
|
||||
antwort: Ein Schlüssel lässt sich nicht erraten und nicht durch Durchprobieren knacken, und der private Teil verlässt nie den eigenen Rechner. Danach kann die Anmeldung per Passwort am Server ganz abgeschaltet werden.
|
||||
- frage: Warum lässt man beim Ändern der SSH-Konfiguration eine zweite Sitzung offen?
|
||||
antwort: Weil man sich mit einem Fehler in der Konfiguration aussperren kann. Die offene Sitzung bleibt bestehen, und man kann den Fehler darüber beheben, bevor man sie schließt.
|
||||
---
|
||||
|
||||
## Das Wesentliche
|
||||
|
||||
- **Pakete (Debian, Ubuntu):** `sudo apt update` holt die Paketlisten, `sudo apt upgrade`
|
||||
spielt Aktualisierungen ein, `sudo apt install nginx` installiert. Sicherheitsupdates lassen
|
||||
sich mit `unattended-upgrades` automatisch einspielen.
|
||||
- **Software nur aus den Paketquellen**, nicht per heruntergeladenem Skript, wenn es sich
|
||||
vermeiden lässt. Was der Paketmanager kennt, aktualisiert er auch.
|
||||
- **Dienste mit systemd:** `systemctl status nginx` zeigt Zustand und letzte
|
||||
Protokollzeilen, `start`, `stop`, `restart` steuern, `enable` startet ihn beim Hochfahren mit.
|
||||
- **Protokolle:** `journalctl -u nginx` für einen Dienst, `-f` zum Mitlesen, `-b` seit dem
|
||||
letzten Start, `--since "1 hour ago"` für einen Zeitraum, `-p err` nur Fehler.
|
||||
- **SSH-Schlüssel:** Auf dem eigenen Rechner `ssh-keygen -t ed25519` erzeugen, mit
|
||||
`ssh-copy-id benutzer@server` hinterlegen. Der private Schlüssel bleibt beim Benutzer und
|
||||
bekommt eine Passphrase.
|
||||
- **SSH absichern** in `/etc/ssh/sshd_config`: `PermitRootLogin no`,
|
||||
`PasswordAuthentication no`. Danach `sudo systemctl reload ssh` – und **in einer zweiten
|
||||
Sitzung testen**, bevor die erste geschlossen wird.
|
||||
- **Firewall:** `sudo ufw allow OpenSSH`, danach nur die Dienste freigeben, die gebraucht
|
||||
werden, und `sudo ufw enable`. Mit `ss -tlnp` prüfen, was tatsächlich lauscht.
|
||||
- **Neustart nach Kernel-Updates:** Ob einer nötig ist, zeigt unter Debian und Ubuntu die
|
||||
Datei `/var/run/reboot-required`.
|
||||
|
||||
## Übersicht
|
||||
|
||||
| Aufgabe | Befehl |
|
||||
|---|---|
|
||||
| Aktualisieren | `sudo apt update && sudo apt upgrade` |
|
||||
| Dienst starten und dauerhaft einschalten | `sudo systemctl enable --now nginx` |
|
||||
| Läuft der Dienst? | `systemctl status nginx` |
|
||||
| Warum startet er nicht? | `journalctl -u nginx -b --no-pager \| tail -n 30` |
|
||||
| Schlüssel erzeugen und hinterlegen | `ssh-keygen -t ed25519` und `ssh-copy-id anna@srv-web-01` |
|
||||
| Firewall-Zustand | `sudo ufw status verbose` |
|
||||
|
||||
## Prüfungsfrage
|
||||
|
||||
**Frage:** Ein frisch installierter Linux-Server soll per SSH verwaltet werden. Beschreiben Sie
|
||||
die Schritte, mit denen Sie den Zugang absichern, in der richtigen Reihenfolge.
|
||||
|
||||
**Antwort:** (1) Einen persönlichen Benutzer mit `sudo`-Recht anlegen, damit nicht als root
|
||||
gearbeitet wird. (2) Auf dem eigenen Rechner ein Schlüsselpaar erzeugen und den öffentlichen
|
||||
Schlüssel mit `ssh-copy-id` für diesen Benutzer hinterlegen. (3) Die Anmeldung mit dem Schlüssel
|
||||
testen. (4) In `sshd_config` die direkte Anmeldung als root und die Anmeldung per Passwort
|
||||
abschalten und den Dienst neu laden. (5) In einer zweiten Sitzung prüfen, dass die Anmeldung
|
||||
weiterhin funktioniert, bevor die erste geschlossen wird. (6) Die Firewall so einrichten, dass
|
||||
SSH nur aus dem Verwaltungsnetz erreichbar ist, und automatische Sicherheitsupdates einschalten.
|
||||
@@ -0,0 +1,66 @@
|
||||
---
|
||||
id: S9
|
||||
titel: Überwachung – wissen, dass etwas kaputt ist, bevor es jemand meldet
|
||||
block: system
|
||||
woche: 14
|
||||
worum: Eine gute Überwachung meldet sich selten, aber dann zu Recht. Eine schlechte meldet sich ständig – und wird deshalb irgendwann ignoriert.
|
||||
rahmenplan: [A8, A5, B3]
|
||||
lernfeld: LF11
|
||||
merksatz: Überwachen, was dem Nutzer wehtut. Warnen bei Trend, alarmieren bei Handlungsbedarf. Jeder Alarm braucht eine Handlung.
|
||||
karten:
|
||||
- frage: Was ist der Unterschied zwischen einer Warnung und einem kritischen Alarm?
|
||||
antwort: Eine Warnung zeigt, dass sich etwas in eine falsche Richtung entwickelt und bald Handlung nötig wird – etwa Platte zu 80 Prozent voll. Ein kritischer Alarm verlangt sofortiges Handeln – etwa Platte zu 95 Prozent voll oder Dienst ausgefallen.
|
||||
- frage: Was versteht man unter Alarmmüdigkeit, und wie vermeidet man sie?
|
||||
antwort: Wer zu viele unwichtige Alarme bekommt, beachtet irgendwann auch die wichtigen nicht mehr. Abhilfe – nur alarmieren, wenn eine Handlung nötig ist, Schwellwerte nach Erfahrung anpassen, Warnungen gesammelt statt einzeln zustellen.
|
||||
- frage: Warum überwacht man auch die Datensicherung und den Ablauf von Zertifikaten?
|
||||
antwort: Weil beide still ausfallen. Eine Sicherung, die seit Wochen fehlschlägt, merkt man erst beim Zurückspielen; ein abgelaufenes Zertifikat erst, wenn alle Nutzer eine Fehlermeldung bekommen.
|
||||
---
|
||||
|
||||
## Das Wesentliche
|
||||
|
||||
- **Von außen nach innen überwachen.** Zuerst, was der Nutzer merkt: Ist die Anwendung
|
||||
erreichbar, antwortet sie schnell genug? Dann die Ursachen darunter: Dienste, Prozessor,
|
||||
Arbeitsspeicher, Platte, Netz.
|
||||
- **Was nicht fehlen darf:** Erreichbarkeit, wichtige Dienste, Plattenplatz, Ergebnis der
|
||||
Datensicherung, Ablauf von Zertifikaten, Zustand von RAID und Platten (SMART), USV und
|
||||
Temperatur im Serverraum.
|
||||
- **Zwei Schwellen:** Warnung, wenn Zeit zum Handeln bleibt, kritisch, wenn sofort gehandelt
|
||||
werden muss. Eine Platte, die von 70 auf 90 Prozent in einer Woche wächst, ist schlimmer als
|
||||
eine, die seit einem Jahr bei 92 steht.
|
||||
- **Trends ansehen.** Eine Kurve über Wochen sagt mehr als der aktuelle Wert. Sie zeigt, wann
|
||||
die Platte voll sein wird, bevor sie es ist.
|
||||
- **Jeder Alarm braucht eine Handlung** und einen Empfänger. Ein Alarm, auf den niemand
|
||||
reagieren muss, ist eine Information und gehört in einen Bericht, nicht aufs Handy.
|
||||
- **Alarmmüdigkeit** ist die größte Gefahr. Wer täglich zwanzig unwichtige Meldungen bekommt,
|
||||
übersieht die eine wichtige.
|
||||
- **Die Überwachung überwachen.** Fällt das Überwachungssystem aus, ist alles still – und Stille
|
||||
sieht aus wie „alles in Ordnung". Ein externer Check oder ein täglicher Lebenszeichen-Alarm
|
||||
hilft.
|
||||
- **Werkzeuge:** Checkmk, Zabbix, PRTG für ganze Umgebungen, Uptime Kuma für einfache
|
||||
Erreichbarkeitsprüfungen. Wichtiger als das Werkzeug ist, was man damit überwacht.
|
||||
|
||||
## Übersicht
|
||||
|
||||
| Prüfung | Warnung | Kritisch | Handlung |
|
||||
|---|---|---|---|
|
||||
| Plattenplatz | 80 % | 90 % | Aufräumen oder erweitern |
|
||||
| Webanwendung erreichbar | Antwort über 2 s | keine Antwort | Dienst und Server prüfen |
|
||||
| Datensicherung | ein Lauf fehlgeschlagen | zwei Läufe in Folge | Ursache finden, Lauf wiederholen |
|
||||
| Zertifikat | läuft in 30 Tagen ab | läuft in 7 Tagen ab | Verlängern |
|
||||
| RAID | – | Platte ausgefallen | Platte tauschen |
|
||||
| Temperatur Serverraum | 27 °C | 32 °C | Klimaanlage prüfen |
|
||||
|
||||
## Prüfungsfrage
|
||||
|
||||
**Frage:** Ihr Ausbilder bittet Sie, eine Überwachung für den neuen Dateiserver einzurichten.
|
||||
Nennen Sie fünf Prüfungen mit sinnvollen Schwellwerten und begründen Sie, warum eine
|
||||
Überwachung nur des Prozessors nicht genügt.
|
||||
|
||||
**Antwort:** Fünf aus: (1) Erreichbarkeit per Ping und SMB – kritisch bei Ausfall. (2)
|
||||
Plattenplatz je Laufwerk – Warnung 80 %, kritisch 90 %. (3) Ergebnis der nächtlichen Sicherung –
|
||||
Warnung bei einem, kritisch bei zwei fehlgeschlagenen Läufen. (4) Zustand von RAID und SMART –
|
||||
kritisch bei ausgefallener oder auffälliger Platte. (5) Arbeitsspeicher – Warnung über 85 %
|
||||
über längere Zeit. (6) Dienst „Server" bzw. Freigabedienst läuft. (7) Ablauf von Zertifikaten,
|
||||
falls verwendet. Der Prozessor allein genügt nicht, weil die häufigsten Ausfälle eines
|
||||
Dateiservers gar nicht mit Rechenlast zusammenhängen: Eine volle Platte, ein ausgefallener
|
||||
Dienst oder eine fehlgeschlagene Sicherung lassen die Prozessorlast unauffällig.
|
||||
Reference in New Issue
Block a user