Woche 01 · Kursstart: Labor, Git und Dokumentation¶

A. Überblick¶

Firmennetz-Baustein: Projekt-Repository stegmoor-it (privates Remote) mit README, .gitignore und Ordnerstruktur; Firmenprofil der fiktiven Stegmoor Haustechnik GmbH (15 Mitarbeitende, 3 Abteilungen); Projektplan.

In dieser ersten Woche entsteht noch kein einziges Netzwerkgerät. Du baust das Fundament, auf dem alle weiteren 79 Wochen aufsetzen: eine saubere Arbeitsumgebung, ein Kurs-Repository, in dem jede Übung nachvollziehbar festgehalten wird, einen Tresor für Kennwörter und einen Plan für das Gesamtprojekt.

Lernziele dieser Woche

ID	Lernziel
NT-A01	Aufbau, Aufgaben und Abläufe eines IT-Dienstleistungsbetriebs erklären
NT-A02	Arbeitsplatz ergonomisch und gesundheitsgerecht einrichten und bewerten
NT-A09	Englische Fachbegriffe verwenden und englische technische Dokumentation lesen
NT-S02	Alle Arbeitsschritte und Tests dokumentieren
NT-S06	Projektziel, Umfang, Ressourcen, Meilensteine und Risiken planen
NT-S07	Projekt durchführen, steuern und dokumentieren; Teile auf Englisch erstellen
NT-R04	Technische Dokumentation, FAQ, Benutzeranleitung und Handbuch verständlich erstellen
NT-M10	Git-Grundlagen anwenden: Repository anlegen, add/commit, log, diff, .gitignore, Remote (clone/push/pull); Skripte, Konfigurationen und Dokumentation versionieren; keine Kennwörter/Secrets im Repository
NT-S09	Laufende Lerndokumentation im Git-Repository führen: je Laborübung ein nachvollziehbarer Commit mit aussagekräftiger Nachricht

Zeitplan

Block	Inhalt	h
1	Theorie: IT-Dienstleister, Ergonomie, Englisch, Dokumentation, Projektplanung, Git (B)	1,25
2	Security (E)	0,25
3	Labor: Werkzeuge, Tresor, Repository, Remote (C.1–C.5)	1,0
4	Labor: Firmenprofil, Heimnetz-Präfix, Projektplan (C.6–C.8)	0,75
5	Labor: Arbeitsplatz-Check, englisches How-to, Probe-Klon (C.9–C.10)	0,5
6	Troubleshooting (D)	0,5
7	Selbsttest, Prüfungsfragen, Push (G)	0,25

Zeitsumme: Theorie 1,5 h + Praxis 3,0 h + Plus 0,0 h = 4,5 h

Plus-Pfad: In dieser Woche gibt es keine Plus-Pfad-Inhalte.

Prüfungsbezug: Fachgespräch – Abläufe eines IT-Dienstleisters. Der Abschnitt B.1 und eine Frage in Abschnitt G bereiten darauf vor.

Tipp

Lies Abschnitt B am Tablet, bevor du am Precision arbeitest. Für das Labor stellst du diese Seite auf den zweiten Bildschirm und kopierst die Befehle mit dem Kopier-Knopf.

B. Theorie¶

B.1 Der IT-Dienstleistungsbetrieb (NT-A01)¶

Ein IT-Dienstleister (IT service provider) betreibt, wartet und entwickelt die IT anderer Unternehmen, die dafür kein eigenes Personal haben oder haben wollen. Auch die Stegmoor Haustechnik GmbH hat keine eigene IT-Abteilung: Die Betreuung liegt extern bei dir. Ein Dienstleister verkauft keine Geräte, sondern Verfügbarkeit, Beratung und Sicherheit.

Typische Bereiche eines IT-Dienstleisters

Bereich	Aufgabe	Beispiel Stegmoor
Beratung und Vertrieb (sales)	Bedarf klären, Angebot erstellen	Welche Anforderungen hat die Firma an das Netz?
Projekt und Umsetzung (project delivery)	Neue Systeme planen und einführen	Aufbau des Firmennetzes Woche für Woche
Betrieb und Support (operations, service desk)	Störungen beheben, Systeme warten	Ein Arbeitsplatz erreicht den Server nicht
Verwaltung (administration)	Verträge, Rechnungen, Lizenzen	Abrechnung der Betreuungsstunden
Leitung (management)	Ziele, Personal, Qualität	Entscheidungen über Leistungen und Preise

In einem kleinen Betrieb wie deinem Lernprojekt übernimmt eine Person mehrere Rollen. Trotzdem hilft es, die Rollen gedanklich zu trennen: Wer ein Angebot schreibt, denkt anders als wer eine Störung behebt.

Ablauf eines Kundenauftrags

flowchart LR
    A["Anfrage"] --> B["Bedarf klären"]
    B --> C["Angebot"]
    C --> D["Beauftragung"]
    D --> E["Umsetzung"]
    E --> F["Übergabe und Dokumentation"]
    F --> G["Betrieb und Wartung"]
    G --> H["Abrechnung"]

Ticketsystem und Störungsbearbeitung. Jede Meldung eines Kunden wird als Ticket (ticket) erfasst. Ein Ticket durchläuft feste Schritte: erfassen, einstufen (Priorität), bearbeiten, beheben, mit dem Kunden bestätigen, schließen, dokumentieren. Die Fachsprache unterscheidet:

Begriff	Bedeutung	Beispiel
Störung (incident)	Ein Dienst funktioniert nicht oder eingeschränkt	Drucker druckt nicht
Problem (problem)	Ursache hinter mehreren Störungen	Der Druckserver verliert nachts die Verbindung
Änderung (change)	Geplante Anpassung eines Systems	Neue Firewall-Regel einführen
Serviceanfrage (service request)	Standardwunsch ohne Störung	Neues Benutzerkonto anlegen

Support-Stufen (support levels). Level 1 nimmt die Meldung entgegen und löst Standardfälle; Level 2 bearbeitet technisch tiefere Fälle; Level 3 sind Spezialisten oder Hersteller. Wer nicht weiterkommt, eskaliert (escalate) an die nächste Stufe und gibt dabei alles bisher Herausgefundene mit.

Vereinbarte Qualität. Ein Dienstleistungsvertrag (service level agreement, SLA) legt fest, wie schnell reagiert wird, wann der Support erreichbar ist und was er kostet. Ohne klare Vereinbarung entstehen Streit und falsche Erwartungen.

Pflichten. Ein Dienstleister sieht vertrauliche Daten seiner Kunden. Verschwiegenheit, Datenschutz und sorgfältige Dokumentation sind keine Kür, sondern Kern des Geschäfts. Genau deshalb gehören Kennwörter nie ungeschützt in Unterlagen (siehe B.6 und Abschnitt E).

Hinweis

Das Betriebsmodell, das du in dieser Woche im Firmenprofil niederschreibst, ist der Nachweis für NT-A01. Es muss nicht perfekt sein, aber die Abläufe, Rollen und das Ticketverfahren erklären können.

B.2 Ergonomie am Arbeitsplatz (NT-A02)¶

Ergonomie (ergonomics) passt die Arbeit an den Menschen an. Du verbringst in diesem Kurs 360 Stunden vor Bildschirmen, dazu kommen Tablet und Labortisch. Rückenschmerzen und trockene Augen sind vermeidbar.

Die wichtigsten Richtwerte

Bereich	Richtwert
Sitzhöhe	Oberschenkel etwa waagrecht, Füße flach am Boden oder auf einer Fußstütze
Armhaltung	Ellbogen etwa im rechten Winkel, Handgelenke gerade
Bildschirmabstand	etwa 50–70 cm, ungefähr eine Armlänge
Bildschirmhöhe	Oberkante auf oder knapp unter Augenhöhe, Blick leicht nach unten
Bildschirmstellung	seitlich zum Fenster, nie mit dem Rücken oder Gesicht zum Fenster (Spiegelung, Blendung)
Beleuchtung	blendfrei, ausreichend hell, keine Reflexe auf dem Bildschirm
Tablet zum Lesen	auf einem Ständer, leicht geneigt, nicht flach auf dem Tisch
Pausen	nach etwa 50–60 Minuten eine kurze Pause oder Tätigkeitswechsel

Eine bekannte Faustregel für die Augen ist die 20-20-20-Regel: alle 20 Minuten für 20 Sekunden auf etwas in etwa 6 Metern Entfernung schauen. In Österreich regelt die Bildschirmarbeitsverordnung (BS-V) die Anforderungen an Bildschirmarbeitsplätze. Den genauen Wortlaut, insbesondere zu Pausen, liest du selbst bei der Arbeitsinspektion nach; die Tabelle oben sind Richtwerte, keine Rechtsauskunft.

Laborarbeitsplatz. Zusätzlich zur Bildschirmarbeit gilt am Labortisch: Steckdosenleisten fest montiert und nicht überlastet, Kabel nicht als Stolperfalle, Flüssigkeiten nie neben Geräten. Den ESD-Schutz (Schutz vor elektrostatischer Entladung) richtest du in Woche 02 ein.

B.3 Englische Fachsprache (NT-A09)¶

Fast jede Herstellerdokumentation, jede Fehlermeldung und jede Anleitung im Netzwerkbereich ist englisch. Du musst nicht perfekt Englisch sprechen, aber technische Texte sicher lesen. Die ersten Begriffe dieser Woche:

Englisch	Deutsch	Bedeutung
repository	Repository, Projektarchiv	Ordner samt Änderungsgeschichte
commit	Commit, Versionsstand	gespeicherter Stand mit Nachricht
staging area	Bereitstellungsbereich	Vorbereitung für den nächsten Commit
working tree	Arbeitsverzeichnis	die Dateien, wie sie gerade im Ordner liegen
remote	Gegenstelle	Repository auf einem Server
push / pull	hochladen / herunterladen	Commits zur Gegenstelle senden bzw. holen
clone	Klon	vollständige Kopie eines Repositorys
branch	Zweig	getrennte Entwicklungslinie
diff	Unterschied	Vergleich zweier Stände
ignore	ignorieren	Dateien von der Versionsverwaltung ausnehmen

Wie liest man ein englisches Datenblatt oder How-to? Zuerst die Gliederung ansehen: Überblick (overview), Voraussetzungen (prerequisites), Schritte (steps), Warnungen (warnings, cautions), Fehlerbehebung (troubleshooting). Dann die Voraussetzungen prüfen, bevor du den ersten Schritt ausführst. Auf Hilfswörter achten: must heißt zwingend, should heißt empfohlen, may heißt erlaubt, must not heißt verboten. Zahlen und Einheiten immer ganz lesen, denn hier entstehen die teuersten Fehler.

B.4 Dokumentation (NT-S02, NT-R04)¶

Wer nicht dokumentiert, hat nichts getan, das jemand nachvollziehen kann. Dokumentation hat drei Zwecke: Du findest dein eigenes Vorgehen in drei Monaten wieder, ein Kollege kann übernehmen, und im Streitfall ist belegt, was getan wurde.

Laborprotokoll (NT-S02). Jede Laborübung bekommt ein Protokoll mit: Datum, Ziel, Ausgangslage, Schritte mit den tatsächlich eingegebenen Befehlen, Ergebnis und Tests, aufgetretene Probleme und ihre Behebung, Zeitaufwand. Wichtig ist, dass auch gescheiterte Versuche stehen, denn aus ihnen lernst du am meisten. Ein Test gilt nur als bestanden, wenn der erwartete und der tatsächliche Wert nebeneinander stehen.

Arten technischer Dokumente (NT-R04). Die Art richtet sich nach der Zielgruppe:

Dokument	Zielgruppe	Inhalt
Technische Dokumentation	andere Fachleute	Aufbau, Konfiguration, Adressen, Entscheidungen
Benutzeranleitung (user guide)	Anwender ohne IT-Wissen	wenige Schritte, einfache Sprache, Bilder
FAQ (frequently asked questions)	Anwender mit konkreter Frage	kurze Fragen und Antworten
Handbuch (manual)	Betrieb und Nachfolger	vollständige Beschreibung, Abläufe, Notfallplan

Regeln für verständliche Anleitungen. Ein Schritt enthält genau eine Handlung. Sätze beginnen mit einem Verb in der Befehlsform („Öffne …“). Zu jedem Schritt gehört das erwartete Ergebnis. Warnungen stehen vor dem Schritt, nicht danach. Begriffe werden einheitlich verwendet. Fachwörter, die der Leser nicht kennt, werden einmal erklärt.

Markdown. Dieser Kurs schreibt alles in Markdown, einer einfachen Auszeichnungssprache für Text: # für Überschriften, - für Listen, | für Tabellen, drei Rückstriche für Codeblöcke. Markdown-Dateien sind reiner Text, lassen sich deshalb in Git sauber vergleichen und sind in jedem Editor lesbar.

B.5 Projektplanung (NT-S06, NT-S07)¶

Ein Projekt (project) ist ein einmaliges Vorhaben mit klarem Ziel, festem Zeitrahmen und begrenzten Ressourcen. Der gesamte Kurs ist ein solches Projekt: Du baust über 80 Wochen das Firmennetz der Stegmoor Haustechnik GmbH auf und dokumentierst es.

Das magische Dreieck (project triangle). Leistung, Zeit und Ressourcen hängen zusammen: Wer mehr Leistung will, braucht mehr Zeit oder mehr Ressourcen. Bei dir ist die Zeit fest (4,5 Stunden pro Woche), also muss der Umfang gesteuert werden.

Bestandteile eines Projektplans

Baustein	Frage	Beispiel für dieses Projekt
Projektziel	Was soll am Ende gelten? Möglichst messbar	Funktionierendes, dokumentiertes Firmennetz mit allen Diensten nach Plan
Umfang (scope)	Was gehört dazu, was nicht?	Hauptsitz und Filiale; kein echtes Heimnetz, kein Echtbetrieb
Ressourcen	Zeit, Geräte, Software, Geld	360 Stunden, Precision 7550, Open-Source- und Evaluierungssoftware
Meilensteine (milestones)	Prüfbare Zwischenziele mit Termin	Blockprüfung 1 in Woche 16
Risiken (risks)	Was kann schiefgehen?	Hardwareausfall, Zeitmangel, Kennwort im Repository

Risikobewertung. Jedes Risiko bekommt eine Eintrittswahrscheinlichkeit und eine Auswirkung, jeweils niedrig, mittel oder hoch. Wer beides kombiniert, erkennt, wo Vorsorge nötig ist. Zu jedem wichtigen Risiko gehört eine Gegenmaßnahme und eine verantwortliche Person; in deinem Projekt bist das immer du.

Phasen eines Projekts. Starten (initiating), Planen (planning), Durchführen und Steuern (executing and controlling), Abschließen (closing). Steuern heißt: regelmäßig Soll und Ist vergleichen und rechtzeitig gegensteuern. Dein regelmäßiger Vergleich ist der Selbsttest am Ende jeder Woche.

Teile auf Englisch (NT-S07). Im Abschlussprojekt in Woche 80 und in der Berufspraxis müssen Teile der Dokumentation englisch sein. Deshalb schreibst du schon jetzt eine kurze englische Zusammenfassung in die README.

B.6 Versionsverwaltung mit Git (NT-M10, NT-S09)¶

Git ist eine Versionsverwaltung (version control system): Es speichert jede Änderung an Dateien als Schnappschuss mit Autor, Zeitpunkt und Nachricht. Du kannst jederzeit nachsehen, wer wann was geändert hat, und zu einem früheren Stand zurückkehren.

Die drei Bereiche und der Weg einer Änderung

flowchart LR
    A["Arbeitsverzeichnis<br/>(working tree)"] -- "git add" --> B["Bereitstellung<br/>(staging area)"]
    B -- "git commit" --> C["Lokales Repository"]
    C -- "git push" --> D["Remote<br/>(GitHub, privat)"]
    D -- "git pull" --> A

Du änderst Dateien im Arbeitsverzeichnis, wählst mit git add aus, was in den nächsten Commit kommt, und schreibst mit git commit den Stand fest. Erst git push überträgt die Commits zur Gegenstelle. Ein Commit ist ein Stand mit eindeutiger Kennung (hash).

Die wichtigsten Befehle

Befehl	Wirkung
`git init`	legt in einem Ordner ein neues Repository an
`git status`	zeigt, welche Dateien neu, geändert oder bereitgestellt sind
`git add <Datei>`	stellt eine Datei für den nächsten Commit bereit
`git commit -m "<Nachricht>"`	schreibt die bereitgestellten Änderungen als Commit fest
`git log --oneline`	listet die Commits kurz auf
`git diff`	zeigt die noch nicht bereitgestellten Änderungen
`git remote add origin <URL>`	verknüpft das Repository mit einer Gegenstelle
`git push` / `git pull`	sendet Commits zur Gegenstelle bzw. holt neue
`git clone <URL>`	kopiert ein Remote-Repository vollständig

Die Datei .gitignore. Sie enthält Muster für Dateien, die Git nie aufnimmt, etwa Kennwort-Tresore, Schlüssel, große Abbilder und Paketaufzeichnungen. Das ist ein Sicherheitsnetz, kein Ersatz für Aufmerksamkeit.

Commit-Konvention dieses Kurses. Jede Nachricht hat die Form wNN <bereich>: <was wurde gemacht>. Bereiche sind doku, konfig, skript, protokoll und fix. Ein Beispiel: w01 doku: Firmenprofil angelegt. Je Laborübung gibt es mindestens einen Commit (Pflicht, NT-S09). Am Wochenende gilt zusätzlich git push. Eine gute Nachricht sagt, was und warum, nicht nur „Update“.

Warum keine Kennwörter ins Repository? Git vergisst nichts. Ein Kennwort, das einmal in einem Commit stand, bleibt in der Historie, auch wenn die Datei später gelöscht wird. Wer das Repository klont oder liest, findet es. Auch ein privates Remote schützt nicht dauerhaft: Zugriffsrechte ändern sich, Konten werden gehackt, Repositorys werden irgendwann geteilt. Deshalb gilt in diesem Kurs ohne Ausnahme: Kennwörter, Schlüssel und Tokens liegen nur im KeePassXC-Tresor labor.kdbx, in Anleitungen steht ein Platzhalter wie <KENNWORT-GitHub>.

C. Laboranleitung¶

Ausgangslage (Startzustand, es gibt noch keinen Soll-Zustand einer Vorwoche): Du hast den Dell Precision 7550 mit Windows 11 Pro 25H2 als Labor-Rechner. Das Kurs-Repository stegmoor-it existiert noch nicht; sein Anlegen ist die erste Übung. Es sind noch keine virtuellen Maschinen und keine Labornetze eingerichtet.

Hinweis

Diese Woche arbeitest du an keiner VM, deshalb ist kein Hyper-V-Prüfpunkt vor-w01 nötig. Ab Woche 05, wenn VMs sich ändern, legst du vor jeder Laborwoche den Prüfpunkt vor-wNN an und behältst die letzten zwei.

Die Vorbereitung (C.1 und C.2) endet ohne Commit, weil das Repository erst in C.3 entsteht. Ab C.3 endet jede Übung mit einem Commit im Kurs-Repository stegmoor-it. Alle Ordner liegen unter C:\Labor\ und nicht in einem OneDrive-synchronisierten Verzeichnis.

C.1 Werkzeuge installieren¶

Du brauchst Git for Windows, den Editor Visual Studio Code und den Kennwort-Tresor KeePassXC. Sind sie schon installiert, überspringst du den jeweiligen Befehl.

Erklärung: winget ist der Paketmanager von Windows. install installiert ein Programm, --id wählt es eindeutig aus, -e verlangt genau diese Kennung. Die drei Befehle installieren Git, VS Code und KeePassXC.

winget install --id Git.Git -e
winget install --id Microsoft.VisualStudioCode -e
winget install --id KeePassXCTeam.KeePassXC -e

⚠ vor Ausführung prüfen

Paketkennungen und Meldungen von winget können sich ändern. Findet winget ein Paket nicht, lade das Programm von der offiziellen Herstellerseite (https://git-scm.com, https://code.visualstudio.com, https://keepassxc.org). Die Installationsassistenten kannst du mit den Voreinstellungen durchklicken.

Öffne danach ein neues PowerShell-Fenster, damit die Programme gefunden werden.

Erklärung: Der Befehl fragt die installierte Git-Version ab. Er beweist, dass Git installiert ist und im Suchpfad (PATH) gefunden wird. Die Versionsnummer trägst du ins Laborprotokoll ein.

git --version

Lege Namen und Mail-Adresse für die Commits fest und setze den Standardnamen für den ersten Zweig. Für die Mail-Adresse nimmst du die Adresse deines GitHub-Kontos oder die Noreply-Adresse, die GitHub in den Konto-Einstellungen anzeigt.

Erklärung: git config --global schreibt eine Einstellung für alle Repositorys deines Windows-Kontos. user.name und user.email stehen in jedem Commit. init.defaultBranch main bewirkt, dass neue Repositorys mit dem Zweig main beginnen. Ersetze <DEINE-MAIL-ADRESSE> durch deine Adresse.

git config --global user.name "Ferdinand"
git config --global user.email "<DEINE-MAIL-ADRESSE>"
git config --global init.defaultBranch main

C.2 Kennwort-Tresor anlegen¶

Der Tresor labor.kdbx nimmt alle Kennwörter des Labors auf. Er liegt außerhalb jedes Repositorys.

Starte KeePassXC und wähle „Neue Datenbank erstellen“ (Menüpunkte können je nach Version abweichen).
Name der Datenbank: labor. Die Verschlüsselungseinstellungen kannst du auf den Voreinstellungen lassen.
Als Master-Kennwort wählst du eine lange Kennphrase, am besten vier oder mehr zufällige Wörter. Das Master-Kennwort schreibst du nirgends digital auf; notiere es auf Papier und bewahre es sicher auf.
Speichere die Datei als C:\Labor\Tresor\labor.kdbx (den Ordner Tresor legt der Speichern-Dialog an oder du erstellst ihn im Explorer).
Lege den ersten Eintrag mit dem Namen GitHub an (Benutzername, Kennwort und die Adresse des Dienstes). In Anleitungen steht dafür der Platzhalter <KENNWORT-GitHub>: Das Wort nach KENNWORT- ist immer der Name des Tresoreintrags.
Kopiere labor.kdbx im Explorer zusätzlich auf eine externe Platte. Erneuere diese Sicherung nach jeder größeren Änderung.

Achtung

Geht die Datei labor.kdbx oder das Master-Kennwort verloren, sind alle Laborkennwörter unwiederbringlich weg. Die Sicherung auf der externen Platte ist deshalb Pflicht, nicht Kür.

C.3 Repository anlegen¶

Erklärung: Test-Path fragt, ob der Ordner existiert. Die Ausgabe muss False lauten: Laut Labor-Masterplan darf das Kurs-Repository vor Woche 1 nicht existieren, sein Anlegen ist die erste Übung.

Test-Path C:\Labor\stegmoor-it

Erklärung: New-Item -ItemType Directory legt den Ordner an, -Force legt fehlende übergeordnete Ordner mit an. Set-Location wechselt hinein. git init macht aus dem Ordner ein Git-Repository: Es entsteht der versteckte Ordner .git, in dem Git seine Daten führt.

New-Item -ItemType Directory -Force -Path C:\Labor\stegmoor-it
Set-Location C:\Labor\stegmoor-it
git init

Erklärung: Diese Befehle legen die Ordnerstruktur nach Labor-Masterplan Kap. 8.2 an, soweit sie diese Woche gebraucht wird. Git verwaltet keine leeren Ordner; die leere Datei .gitkeep ist nur ein Platzhalter, damit konfig und skripte im Repository vorhanden sind. Die beiden Dateien README.md und .gitignore werden angelegt und gleich befüllt.

New-Item -ItemType Directory -Force -Path doku\sicherheit, konfig, skripte, woche-01
New-Item -ItemType File -Path konfig\.gitkeep, skripte\.gitkeep, README.md, .gitignore, woche-01\laborprotokoll.md

C.4 README, .gitignore und Laborprotokoll – erster Commit¶

Erklärung: code . öffnet den aktuellen Ordner in VS Code. Dort trägst du den Inhalt der nächsten drei Blöcke in die drei Dateien ein und speicherst jede Datei mit Strg+S.

code .

Inhalt von .gitignore (Mindestinhalt laut Labor-Masterplan Kap. 8.3):

# Kennwoerter, Schluessel, Zertifikate: nie ins Repository
*.kdbx
*.key
*.pem
*.pfx
.env
secrets/

# Grosse Abbilder und Paketaufzeichnungen (nur Textausschnitte als Nachweis)
*.vhdx
*.iso
*.pcap
*.pcapng

Inhalt von README.md (passe die englische Zusammenfassung gern in eigenen Worten an):

# stegmoor-it

Lern- und Dokumentationsrepository zum Aufbau des Firmennetzes der fiktiven Stegmoor Haustechnik GmbH
(Selbststudium Netzwerktechnik, Ziel: Lehrabschlussprüfung Informationstechnologie – Systemtechnik).

## Aufbau

- doku/        Dokumente der Firma (Firmenprofil, Projektplan, Netz, Sicherheit, Betrieb)
- konfig/      bereinigte Konfigurationsstände je Gerät
- skripte/     Skripte (PowerShell, Bash, Python)
- woche-NN/    Laborprotokoll und Nachweise der jeweiligen Woche

## Firmenkurzprofil

Stegmoor Haustechnik GmbH, Leoben (Hauptsitz) und Bruck an der Mur (Filiale), 15 Mitarbeitende in drei
Abteilungen. Details: doku/firmenprofil.md

## Regeln

- Commit-Nachricht: wNN <bereich>: <was wurde gemacht>
- Keine Kennwörter, Schlüssel oder Tokens im Repository. Sie liegen im KeePassXC-Tresor.

## Summary (English)

This repository documents a self-study project: building and documenting the network of a fictional
small company, week by week. It contains the company profile, the project plan, lab reports, scripts
and sanitised configuration files. No passwords or secrets are stored here.

Inhalt von woche-01/laborprotokoll.md (Vorlage, die du Übung für Übung ausfüllst):

# Laborprotokoll Woche 01

Datum: <TT.MM.JJJJ>
Ziel der Woche: Kurs-Repository, Firmenprofil, Projektplan, Dokumentationsgewohnheit

## Umgebung
- Windows-Version (winver): <eintragen>
- Git-Version (git --version): <eintragen>

## Übungen
### C.4 Repository angelegt
- Befehle: <was du eingegeben hast>
- Erwartet: <...>   Tatsächlich: <...>
- Probleme und Behebung: <...>

## Zeitaufwand
Soll 4,5 h, Ist: <eintragen>

Erklärung: Der Test zeigt, dass .gitignore wirkt. Zuerst wird eine Scheindatei test.kdbx angelegt. git status --short listet sie nicht auf, git check-ignore -v nennt das passende Muster. Danach wird die Scheindatei wieder gelöscht, sie liegt nur in deinem Repository-Ordner.

New-Item -ItemType File -Path test.kdbx
git status --short
git check-ignore -v test.kdbx
Remove-Item test.kdbx

Erklärung: git status zeigt den Zustand des Arbeitsverzeichnisses: Alles ist „untracked“, also noch unbekannt. git add stellt die genannten Dateien für den Commit bereit. git commit -m schreibt sie mit der Nachricht nach der Kurs-Konvention fest. git log --oneline zeigt den ersten Eintrag der Historie.

git status
git add README.md .gitignore konfig/.gitkeep skripte/.gitkeep woche-01/laborprotokoll.md
git commit -m "w01 doku: README, .gitignore, Ordnerstruktur und Laborprotokoll angelegt"
git log --oneline

Tipp

Meldet Git „LF will be replaced by CRLF“, ist das eine harmlose Hinweismeldung zu Zeilenenden unter Windows. Der Commit ist trotzdem gelungen.

C.5 Privates Remote auf GitHub¶

Lege im Browser auf GitHub ein neues Repository mit dem Namen stegmoor-it an. Stelle es auf „Private“ (nur du siehst es). Hake keine der Optionen „Add a README file“, „.gitignore“ oder „license“ an, denn diese Dateien hast du schon.

⚠ vor Ausführung prüfen

Die Oberfläche von GitHub ändert sich gelegentlich; Bezeichnungen und Anordnung können von der Beschreibung abweichen. Achte vor dem Anlegen darauf, dass „Private“ gewählt ist. Aktiviere für dein GitHub-Konto die Zwei-Faktor-Anmeldung, wenn du das noch nicht getan hast, und lege das Kennwort des Kontos im Tresor unter GitHub ab (<KENNWORT-GitHub>).

Erklärung: git remote add origin verknüpft dein lokales Repository mit der Gegenstelle und gibt ihr den Namen origin. Ersetze <GITHUB-BENUTZER> durch deinen GitHub-Benutzernamen. git remote -v zeigt die gespeicherten Adressen. git push -u origin main lädt den Zweig main hoch; -u merkt sich die Zuordnung, damit später git push und git pull ohne Zusatz funktionieren.

git remote add origin https://github.com/<GITHUB-BENUTZER>/stegmoor-it.git
git remote -v
git push -u origin main

Beim ersten Push öffnet der in Git for Windows enthaltene Anmeldehelfer (Git Credential Manager) ein Browserfenster, in dem du dich bei GitHub anmeldest. Gib dein Kennwort nie in der Adresse (URL) oder in einem Befehl an. Lade danach die GitHub-Seite des Repositorys neu: Du siehst deine Dateien und den Commit.

Erklärung: Dieser Befehl hält die Übung im Protokoll fest. Trage zuvor in woche-01/laborprotokoll.md unter „C.4“ die tatsächlichen Befehle und Ergebnisse ein. git diff zeigt dir, was sich gegenüber dem letzten Commit geändert hat. Erst danach wird die Änderung committet und hochgeladen.

git diff
git add woche-01/laborprotokoll.md
git commit -m "w01 protokoll: Repository und Remote eingerichtet"
git push

C.6 Firmenprofil und Betriebsmodell¶

Lege die Datei doku/firmenprofil.md an (New-Item -ItemType File -Path doku\firmenprofil.md, dann in VS Code öffnen) und trage den folgenden Inhalt ein. Die Daten stammen aus dem Labor-Masterplan Kap. 2; das Betriebsmodell am Ende ist dein eigener Nachweis für NT-A01.

# Firmenprofil Stegmoor Haustechnik GmbH (fiktiv)

| Merkmal | Festlegung |
|---|---|
| Name | Stegmoor Haustechnik GmbH (Kurzname STEGMOOR) |
| Branche | Planung, Installation und Wartung von Heizungs-, Sanitär- und Lüftungsanlagen |
| Standorte | Hauptsitz Leoben (12 Mitarbeitende), Filiale Bruck an der Mur (3 Mitarbeitende) |
| Mitarbeitende | 15 |
| IT-Betreuung | extern, durch Ferdinand als IT-Dienstleister |

## Abteilungen

| Abteilung | Mitarbeitende | Leitung | Arbeitsweise |
|---|---:|---|---|
| Verwaltung (inkl. Geschäftsführung) | 5 | Gerda Leitner | Büroarbeit, Buchhaltung, Datei- und Druckserver |
| Technik (Planung) | 6 | Thomas Berger | Planungsdaten, Projektlaufwerk |
| Außendienst (Montage) | 4 | Markus Wimmer | mobil, Laptop und Smartphone |

Die vollständige Personenliste steht im Labor-Masterplan Kap. 2.1 und wird beim Aufbau der Benutzerkonten verwendet.

## Betriebsmodell der IT-Betreuung

| Frage | Festlegung (in eigenen Worten ergänzen) |
|---|---|
| Leistungen | Betrieb und Wartung, Störungsbehebung, Änderungen, Projekte |
| Rollen | <Beratung, Umsetzung, Support, Verwaltung: wer übernimmt was?> |
| Ablauf einer Störungsmeldung | Meldung, Ticket erfassen, Priorität festlegen, bearbeiten, mit Kunde bestätigen, schließen, dokumentieren |
| Eskalation | <wann und an wen wird eskaliert?> |
| Vereinbarte Qualität (SLA) | <Erreichbarkeit und Reaktionszeit, im Kurs frei wählbar> |
| Pflichten | Verschwiegenheit, Datenschutz, Dokumentation, keine Kennwörter in Unterlagen |

Ersetze alle Texte in spitzen Klammern durch deine eigenen Festlegungen; das Betriebsmodell muss am Ende nachvollziehbar erklären, wie der IT-Dienstleister arbeitet (siehe B.1).

Erklärung: Die Befehle ergänzen das Laborprotokoll um einen Eintrag (C.6) und schreiben dann Firmenprofil und Protokoll als einen Commit fest. git add nennt beide Dateien ausdrücklich; so kommt nichts Unbeabsichtigtes mit. git status vor dem Commit zeigt dir, dass genau diese zwei Dateien bereitstehen.

git add doku/firmenprofil.md woche-01/laborprotokoll.md
git status
git commit -m "w01 doku: Firmenprofil und Betriebsmodell der IT-Betreuung"

C.7 Heimnetz-Präfix ermitteln und Trennung festhalten¶

Das Labor ist strikt vom Heimnetz, vom produktiven Intel-NUC und von Tailscale getrennt. Ab Woche 20 sperrt die Firewall FW01 jeden Verkehr zu diesen Netzen, und dafür muss das Heimnetz-Präfix bekannt sein. Du ermittelst es jetzt, solange das Labor noch leer ist.

Erklärung: Get-NetIPAddress listet die Adressen aller Netzwerkkarten. -AddressFamily IPv4 beschränkt auf IPv4, Select-Object zeigt nur den Kartennamen, die Adresse und die Präfixlänge (die Zahl hinter dem Schrägstrich, zum Beispiel 24). Die WLAN-Karte, über die der Precision ins Heimnetz geht, trägt die Heimnetz-Adresse.

Get-NetIPAddress -AddressFamily IPv4 | Select-Object InterfaceAlias, IPAddress, PrefixLength

Bei einer Präfixlänge von 24 ist das Heimnetz-Präfix die ersten drei Zahlen der Adresse, gefolgt von .0/24. Heimrouter verwenden meist ein Netz im Bereich 192.168.x.0/24. Liegt die Präfixlänge woanders, notiere sie genau so, wie sie angezeigt wird, und ergänze die Frage in Abschnitt J. Der Tailscale-Bereich ist fest: 100.64.0.0/10.

Lege die Datei doku/sicherheit/trennung.md an und trage ein (ersetze <HEIMNETZ-PRAEFIX> durch den ermittelten Wert):

# Trennung von Labor, Heimnetz, NUC und Tailscale

## Grundsatz
Der produktive Intel-NUC, das Heimnetz (ZTE-Router/Mesh) und Tailscale sind nie Teil des Labors.
Das Labor hat einen eigenen Switch, der nicht mit dem Heimnetz verbunden ist. Internet bekommt das
Labor nur über den NAT-Übergang des Precision (vs-WAN, ab Woche 04).

## Ermittelte Werte (Stand Woche 01)
| Netz | Präfix | Verwendung |
|---|---|---|
| Heimnetz | <HEIMNETZ-PRAEFIX> | Sperrregel auf FW01 ab Woche 20 |
| Tailscale | 100.64.0.0/10 | Sperrregel auf FW01 ab Woche 20 |
| Firmennetz (Labor) | 10.42.0.0/21 | überschneidet sich mit keinem der beiden |

## Regeln
- Der Onboard-LAN-Port des Precision ist das Labor, der Host geht über WLAN ins Heimnetz.
- Kein Kabel vom Labor-Switch in das Heimnetz.
- Keine Kennwörter, Schlüssel oder Tokens im Repository (Tresor labor.kdbx).

Erklärung: Die Befehle halten die Übung im Protokoll und im Repository fest. git add stellt die neue Datei und das Protokoll bereit, git commit schreibt sie fest, git push lädt den Stand hoch.

git add doku/sicherheit/trennung.md woche-01/laborprotokoll.md
git commit -m "w01 doku: Heimnetz-Praefix und Trennung Labor/Heimnetz festgehalten"
git push

C.8 Projektplan¶

Der Projektplan ist der Nachweis für NT-S06; die Durchführung und Steuerung über 80 Wochen ist der Nachweis für NT-S07. Lege doku/projektplan.md an und fülle ihn nach diesem Gerüst aus. Die Meilensteine und Risiken kannst du aus dem Prüfungskalender und deinen eigenen Überlegungen ergänzen.

# Projektplan: Firmennetz Stegmoor Haustechnik GmbH

## Projektziel
Bis Woche 80 steht ein funktionierendes, dokumentiertes und gesichertes Firmennetz für Hauptsitz und
Filiale mit allen Diensten nach Masterplan. Nachweis: Kurs-Repository mit Dokumentation und
Abschlussprojekt in Woche 80.

## Umfang
- Im Umfang: Netz, Server, Dienste, Sicherheit, Sicherung und Dokumentation im Hyper-V-Labor.
- Nicht im Umfang: Heimnetz, produktiver NUC, echter Kundenbetrieb.

## Ressourcen
| Ressource | Umfang |
|---|---|
| Zeit | 80 Wochen × 4,5 h = 360 h |
| Hardware | Dell Precision 7550, Alt-PC, später Switch und Access Point |
| Software | Hyper-V, Open-Source-Systeme, Evaluierungsversionen von Microsoft |
| Dokumentation | Git-Repository stegmoor-it (privat), Tresor labor.kdbx |

## Meilensteine
| Woche | Meilenstein |
|---:|---|
| 9 | Phase 1 abgeschlossen: Labor und Grundlagen stehen |
| 16 | Blockprüfung 1, Netzplan V1 |
| 29 | Blockprüfung 2 |
| 37–38 | Große Zwischenprüfung |
| 48 | Blockprüfung 3 |
| 61 | Blockprüfung 4 |
| 72 | Übergabe Version 1.0 des Firmennetzes (Tag v1.0-uebergabe) |
| 80 | Abschlussprojekt |

## Risiken
| Risiko | Wahrscheinlichkeit | Auswirkung | Gegenmaßnahme |
|---|---|---|---|
| <Zeitmangel pro Woche> | <...> | <...> | <...> |
| <Ausfall oder Defekt des Precision> | <...> | <...> | <...> |
| <Datenverlust, Tresor verloren> | <...> | <...> | <...> |
| <Kennwort im Repository> | <...> | <...> | <...> |
| <Verwechslung von Labor und Heimnetz> | <...> | <...> | <...> |

## Steuerung
Wöchentlicher Soll-Ist-Vergleich über den Selbsttest und die Commit-Historie. Woche 36 ist Puffer.

Ergänze jede Zeile mit spitzen Klammern durch eigene Einschätzungen (niedrig, mittel oder hoch) und eine konkrete Gegenmaßnahme.

Erklärung: git diff zeigt zuerst die Änderung an README.md (eine neue Zeile, die auf den Projektplan verweist). Füge dazu in README.md unter „Aufbau“ die Zeile Projektplan: doku/projektplan.md hinzu. Danach stellt git add die Dateien bereit, und git commit schreibt sie fest.

git diff README.md
git add README.md doku/projektplan.md woche-01/laborprotokoll.md
git commit -m "w01 doku: Projektplan mit Zielen, Meilensteinen und Risiken"

C.9 Arbeitsplatz-Check und englisches How-to¶

Arbeitsplatz-Check (NT-A02). Prüfe deinen Arbeitsplatz am Precision und deinen Leseplatz am Tablet nach folgender Tabelle. Trage Befund und eine Verbesserungsmaßnahme in das Laborprotokoll ein. Miss die Maße wirklich nach.

Prüfpunkt	Richtwert	Mein Befund	In Ordnung?
Sitzhöhe	Oberschenkel waagrecht, Füße flach
Ellbogenwinkel	etwa 90 Grad, Handgelenke gerade
Bildschirmabstand	50–70 cm
Bildschirmoberkante	auf oder knapp unter Augenhöhe
Stellung zum Fenster	seitlich, keine Blendung
Beleuchtung	blendfrei, ausreichend hell
Zweiter Bildschirm / Tablet	bequem lesbar, kein Verdrehen des Halses
Kabel und Steckdosen	keine Stolperfallen, Leiste nicht überlastet
Pausenplan	kurze Pause nach 50–60 Minuten

Englisches How-to auswerten (NT-A09). Lies den folgenden englischen Text, den du später fast genauso bei GitHub antriffst, und beantworte die Aufgaben im Laborprotokoll.

How to: Create a private repository and push a first commit

Overview
This guide explains how to publish a local project to a private remote repository.

Prerequisites
- Git is installed (version 2.28 or later).
- You have an account on a Git hosting service and have signed in once.
- The local project folder already contains at least one committed file.

Steps
1. On the hosting service, create a new repository. Set the visibility to "Private".
   Do not add a README, a licence file or a .gitignore file, because the local project
   already provides them.
2. In the local folder, connect the remote: git remote add origin <URL>
3. Push the main branch and set the upstream: git push -u origin main
4. Reload the repository page. The files and the commit history should now be visible.

Warnings
- You must not commit passwords, keys or tokens. Anything you push may remain in the
  history, even if you delete the file later.
- A private repository is not a safe place for secrets either.

Troubleshooting
- If the push is rejected with "fetch first", the remote contains commits that you do not
  have locally. Run git pull first, then push again.

Aufgaben:

Schreibe für die Begriffe repository, visibility, upstream, commit history, rejected und licence file die deutsche Entsprechung auf.
Welche drei Voraussetzungen nennt das How-to?
Wofür steht das Wort must not im Abschnitt Warnings?
Was tust du laut Fehlerbehebung, wenn der Push abgelehnt wird?

Lösung

Repository (Projektarchiv); visibility (Sichtbarkeit); upstream (die verknüpfte Gegenstelle für push und pull); commit history (Commit-Historie, Änderungsgeschichte); rejected (abgelehnt, zurückgewiesen); licence file (Lizenzdatei).
Git ist installiert (ab Version 2.28), ein Konto bei einem Git-Hosting-Dienst besteht und ist einmal angemeldet, der lokale Projektordner enthält mindestens eine committete Datei.
must not bedeutet „darf nicht“, ein striktes Verbot: Kennwörter, Schlüssel und Tokens dürfen nie committet werden.
Zuerst git pull, damit die fehlenden Commits der Gegenstelle lokal ankommen, danach den Push wiederholen.

Erklärung: Die Befehle schreiben Arbeitsplatz-Check und englische Übung als Protokoll-Commit fest. Trage vorher beides in woche-01/laborprotokoll.md ein. git status zeigt dir vorher noch einmal, was geändert ist, damit nur Beabsichtigtes im Commit landet.

git status
git add woche-01/laborprotokoll.md
git commit -m "w01 protokoll: Arbeitsplatz-Check und englisches How-to ausgewertet"

C.10 Probe: Klonen und Pullen¶

Ein Remote ist nur dann eine Sicherung, wenn du daraus wiederherstellen kannst. Du klonst das Repository deshalb in einen Probeordner und prüfst den Inhalt.

Erklärung: git push lädt die letzten Commits hoch. git clone kopiert das gesamte Repository von GitHub in den Ordner stegmoor-it-probe unter %TEMP% ($env:TEMP ist der Temp-Ordner von Windows). Get-ChildItem zeigt die geklonten Dateien. Ersetze <GITHUB-BENUTZER> durch deinen Benutzernamen.

git push
git clone https://github.com/<GITHUB-BENUTZER>/stegmoor-it.git $env:TEMP\stegmoor-it-probe
Get-ChildItem $env:TEMP\stegmoor-it-probe

Erklärung: git pull holt neue Commits der Gegenstelle in dein Arbeitsrepository; hier ist nichts Neues da und Git meldet „Already up to date“. Danach wird der Probeordner, den du gerade selbst angelegt hast, wieder gelöscht. -Recurse löscht auch den Inhalt, -Force auch versteckte Dateien wie den Ordner .git.

git pull
Remove-Item -Recurse -Force $env:TEMP\stegmoor-it-probe

D. Troubleshooting¶

Szenario laut Plan: Versehentlich committetes Testkennwort. Beim Üben hast du eine Datei konfig/test-zugang.txt angelegt, die ein Testkennwort enthält, und sie mit git add . und git commit in das Repository übernommen. Erst beim Blick in git log ist dir aufgefallen, dass die Datei darin steht. Du hast sie noch nicht hochgeladen. Die Aufgabe: Entferne das Testkennwort so aus dem Repository, dass es auch in der Historie nicht mehr vorkommt, und ergänze die .gitignore, damit sich dasselbe nicht wiederholt.

Zum Nachstellen legst du den Fehler zuerst selbst an. Der Wert ist ein Testwert ohne Bedeutung; schreibe nie ein echtes Kennwort in diese Datei.

Erklärung: Set-Content schreibt den Text in die Datei, -Path ist die Datei und -Value der Inhalt. git add . nimmt alles auf, was sich geändert hat (genau diese Gewohnheit führt zum Fehler). git commit -m schreibt es fest, git log --oneline zeigt das Ergebnis.

Set-Content -Path konfig\test-zugang.txt -Value 'Testkennwort-nur-Uebung'
git add .
git commit -m "w01 konfig: Testzugang"
git log --oneline

Überlege, bevor du die Behebung ansiehst: Welche Befehle machen den letzten Commit rückgängig, ohne die Datei im Repository zurückzulassen? Reicht es, die Datei zu löschen und neu zu committen? Wie prüfst du, dass der Wert wirklich weg ist?

Lösung

Ein bloßes Löschen und erneutes Committen genügt nicht: Der alte Commit mit dem Kennwort bliebe in der Historie. Weil der Fehler noch nicht hochgeladen wurde und der fehlerhafte Commit der letzte ist, kannst du ihn zurücknehmen.

Erklärung: git reset --soft HEAD~1 nimmt den letzten Commit zurück, lässt seinen Inhalt aber bereitgestellt. git rm --cached nimmt die Datei wieder aus der Bereitstellung, ohne sie von der Platte zu löschen. Remove-Item löscht die Datei danach auch von der Platte, denn sie wird nicht gebraucht.

git reset --soft HEAD~1
git rm --cached konfig/test-zugang.txt
Remove-Item konfig\test-zugang.txt

Ergänze am Ende der Datei .gitignore diese Zeilen, damit Zugangsdateien nie wieder aufgenommen werden:

# Zugangsdaten gehören in den Tresor
*zugang*

Erklärung: Die Befehle schreiben die ergänzte .gitignore als Commit mit dem Bereich fix fest. Danach löschen git reflog expire und git gc die zurückgenommenen, jetzt nirgends mehr verwiesenen Commits endgültig aus dem lokalen Repository. git log --all -S sucht den Testwert in allen Commits: Die Ausgabe muss leer sein.

git add .gitignore
git commit -m "w01 fix: Testzugang aus Commit entfernt, .gitignore ergaenzt"
git reflog expire --expire=now --all
git gc --prune=now
git log --all -S"Testkennwort-nur-Uebung" --oneline

Wäre der Commit schon hochgeladen worden, gälte das Kennwort als bekannt: Zuerst das echte Kennwort sofort ändern (beim betroffenen Dienst und im Tresor). Dann die Historie bereinigen: entweder mit dem Zusatzwerkzeug git filter-repo und anschließendem Überschreiben des Remotes, oder, bei einem so jungen Repository wie deinem, das Remote auf GitHub löschen, neu anlegen und den bereinigten Stand frisch hochladen. Kopien, die jemand zwischenzeitlich gezogen hat, lassen sich nicht zurückholen; deshalb steht das Ändern des Kennworts an erster Stelle.

E. Security und Mathematik¶

E.1 Security: Trennung des Labors und keine Secrets im Repository¶

Grundsatz 1: Das Labor ist strikt von NUC und Heimnetz getrennt. Im Labor laufen später Dienste, die in einem fremden Netz Schaden anrichten: ein DHCP-Server (er verteilt Adressen), ein DNS-Server und Firewall-Regeln. Würde das Labor mit dem Heimnetz verbunden, könnte ein Labor-DHCP-Server die Geräte der Familie aus dem Netz werfen oder auf falsche Adressen umleiten. Außerdem sollen Fehlkonfigurationen und Übungsangriffe des Labors nie auf produktive Geräte wie den NUC treffen. Technisch heißt das: eigener Labor-Switch ohne Verbindung zum Heimnetz, Internet nur über den NAT-Übergang des Precision (ab Woche 04), und ab Woche 20 sperrt FW01 alles in Richtung Heimnetz und Tailscale.

Grundsatz 2: Keine Secrets im Repository. Secrets sind Kennwörter, private Schlüssel, Tokens, vorab geteilte Schlüssel (PSK) und Zugangsdaten jeder Art. Sie liegen im Tresor labor.kdbx, die Anleitungen verwenden Platzhalter, die .gitignore fängt typische Dateien ab (*.kdbx, *.key, *.pem, *.pfx, .env, secrets/). Konfigurationsstände ab Woche 20 werden vor dem Commit bereinigt.

Gute Kennwörter. Die Länge zählt mehr als Sonderzeichen: Eine Kennphrase aus vier oder mehr zufälligen Wörtern ist stark und merkbar. Jeder Dienst bekommt ein eigenes Kennwort, der Tresor erzeugt und speichert sie. Wo möglich, wird eine zweite Stufe (Zwei-Faktor-Anmeldung) aktiviert.

Aufgabe 1 (LAP-Stil): Nenne drei Gründe, weshalb das Labor nie mit dem Heimnetz verbunden werden darf.

Lösung

Dienste wie DHCP oder DNS des Labors könnten im Heimnetz Geräte stören oder umleiten.
Fehler und Angriffsübungen im Labor könnten produktive Geräte (NUC, Familienrechner) treffen.
Eine Verbindung würde Adressbereiche und Zugriffe vermischen; Daten des Heimnetzes könnten ins Labor gelangen und umgekehrt, und die Fehlersuche wird unübersichtlich.

Aufgabe 2 (LAP-Stil): Warum reicht es nicht, eine Datei mit einem Kennwort aus dem Repository zu löschen, nachdem sie committet wurde?

Lösung

Git bewahrt jeden Commit samt Inhalt in der Historie auf. Das Löschen entfernt die Datei nur im neuesten Stand; frühere Commits enthalten sie weiterhin, und jeder, der das Repository klont, kann sie lesen. Man muss die Historie bereinigen und das Kennwort zusätzlich ändern.

Aufgabe 3 (LAP-Stil): Welche der folgenden Dateien dürfen in das Repository? (a) Textdatei mit dem Ergebnis von ipconfig des Labors, (b) labor.kdbx, (c) ein Skript, das das Kennwort mit Read-Host -AsSecureString abfragt, (d) eine Datei .env mit Zugangsdaten, (e) ein Konfigurationsexport ohne Bereinigung der Kennwort-Hashes.

Lösung

(a) ja, wenn sie keine Geheimnisse enthält; (b) nein, steht in .gitignore und gehört nur auf den Precision und die externe Platte; (c) ja, denn das Skript enthält kein Kennwort; (d) nein, steht in .gitignore; (e) nein, Konfigurationen werden vor dem Commit bereinigt (ab Woche 20 vorgeschrieben).

E.2 Mathematik¶

Mathematik entfällt laut Plan.

F. Wiederholung¶

Wiederholung entfällt laut Plan: In Woche 01 gibt es keine Wiederholungs-IDs, weil alle Inhalte neu sind.

G. Selbsttest und Prüfungsfragen¶

Selbsttest laut Plan: Repository mit README, Projektplan, erstem Laborprotokoll; git log zeigt ≥ 3 sinnvolle Commits

Erklärung: git ls-files listet alle Dateien auf, die Git verwaltet; erwartet werden README, .gitignore, Firmenprofil, Projektplan, Trennungsdokument, die beiden Platzhalter und das Laborprotokoll. git status muss „nothing to commit“ melden. git log --oneline zeigt die Historie: mindestens drei Commits mit Nachricht nach der Konvention wNN <bereich>: …. git push lädt den Endstand hoch.

git ls-files
git status
git log --oneline
git push

Frage 1¶

Beschreibe in drei Sätzen den Ablauf eines Kundenauftrags bei einem IT-Dienstleister und nenne die Stufen des Supports. (Vorbereitung auf das Fachgespräch)

Lösung

Ein Auftrag beginnt mit der Anfrage; der Bedarf wird geklärt, es folgt das Angebot und mit der Beauftragung die Umsetzung. Nach der Übergabe samt Dokumentation geht das System in Betrieb und Wartung über, am Ende steht die Abrechnung. Der Support läuft über Level 1 (Annahme und Standardfälle), Level 2 (tiefere technische Fälle) und Level 3 (Spezialisten oder Hersteller); Störungen werden als Ticket erfasst und bei Bedarf eskaliert.

Frage 2¶

Nenne vier Merkmale eines ergonomischen Bildschirmarbeitsplatzes.

Lösung

Bildschirmabstand etwa 50–70 cm; Oberkante des Bildschirms auf oder knapp unter Augenhöhe; Bildschirm seitlich zum Fenster, blendfrei; Ellbogen etwa im rechten Winkel, Oberschenkel waagrecht, Füße flach; regelmäßige kurze Pausen. (Vier davon genügen.)

Frage 3¶

Erkläre den Unterschied zwischen git add, git commit und git push.

Lösung

git add stellt Änderungen für den nächsten Commit bereit. git commit schreibt die bereitgestellten Änderungen als Stand mit Nachricht in das lokale Repository. git push lädt die lokalen Commits zur Gegenstelle (hier GitHub) hoch.

Frage 4¶

Welche Dateien gehören in die .gitignore eines Kurs-Repositorys, und warum?

Lösung

Dateien, die nie ins Repository gehören: Kennwort-Tresore und Schlüssel (*.kdbx, *.key, *.pem, *.pfx), .env und der Ordner secrets/, weil sie Geheimnisse enthalten; große Abbilder (*.vhdx, *.iso) und Paketaufzeichnungen (*.pcap, *.pcapng), weil sie das Repository aufblähen und Daten enthalten können. Die .gitignore ist ein Sicherheitsnetz gegen Versehen.

Frage 5¶

Nenne die fünf Bausteine eines Projektplans und je ein Beispiel aus deinem Projekt.

Lösung

Projektziel (funktionierendes, dokumentiertes Firmennetz bis Woche 80); Umfang (Hauptsitz und Filiale, nicht das Heimnetz); Ressourcen (360 Stunden, Precision 7550); Meilensteine (Blockprüfung 1 in Woche 16); Risiken (Hardwareausfall mit Gegenmaßnahme Sicherung).

H. Stand des Firmennetzes nach Woche 01¶

Gerät	Netz	Adresse	Dienste
PREC	noch kein Labornetz	keine	Git for Windows, VS Code, KeePassXC (Labor-Tresor `labor.kdbx` außerhalb jedes Repositorys)

Repository stegmoor-it – neu: README.md, .gitignore, doku/firmenprofil.md, doku/projektplan.md, doku/sicherheit/trennung.md, konfig/.gitkeep, skripte/.gitkeep, Wochenordner woche-01/ mit laborprotokoll.md.

Lokal unter C:\Labor\stegmoor-it, privates Remote auf GitHub. Die Git-Historie ist frei von Kennwörtern (Übung D bereinigt).

I. Selbstkontrolle¶

ID	Abschnitt
NT-A01	A, B, C, G
NT-A02	B, C, G
NT-A09	B, C
NT-S02	B, C
NT-S06	B, C, G
NT-S07	B, C
NT-R04	B, C
NT-M10	B, C, D, E, G
NT-S09	B, C, G

Zeitsumme: Theorie 1,5 h + Praxis 3,0 h + Plus 0,0 h = 4,5 h

Abweichungen vom Masterplan: keine

J. Offene Fragen¶

Der Ablageort des Tresors labor.kdbx ist im Labor-Masterplan nicht festgelegt (nur „außerhalb beider Repositorys“). Diese Woche wurde C:\Labor\Tresor\ vorgeschlagen. Bitte bestätigen oder einen anderen Ort festlegen.