Die wichtigsten Befehle, erklärt an echten Situationen aus dem Alltag von Sysadmins, DevOps-Engineers und Entwicklern. Mit eingebautem Übungs-Terminal, in dem du alles sofort selbst tippst. Kostenlos, ohne Anmeldung, eine einzige Seite.
Kein Linux installiert? Egal. Das Terminal hier unten ist echt genug zum Lernen.
Zehn Module, aufgebaut wie eine Boot-Sequenz: Du arbeitest dich vom ersten pwd bis zur Produktions-Forensik vor. Abgeschlossene Module melden sich mit [ OK ].
Du landest per SSH auf einem fremden Server. Keine Oberfläche, nur ein blinkender Cursor. Die ersten drei Fragen sind immer gleich: Wo bin ich? Was liegt hier? Wie komme ich woanders hin? Diese acht Befehle beantworten sie, und sie sind 80 Prozent deines Terminal-Alltags.
Kurz für print working directory. Keine Optionen nötig, einfach tippen.
~. Das ist die Abkürzung für dein Home-Verzeichnis, pwd zeigt dir den vollen Pfad dahinter.-l zeigt Details (Rechte, Besitzer, Größe, Datum), -a auch versteckte Dateien (alles mit Punkt am Anfang), -h macht Größen lesbar (4,0K statt 4096). -t sortiert nach Änderungszeit.
ls -lah als Muskelgedächtnis. Auf vielen Servern gibt es dafür schon den Alias ll.cd .. geht eine Ebene hoch, cd ohne Ziel bringt dich heim, cd - springt ins vorherige Verzeichnis zurück. Der Unterstrich-Klassiker beim Pendeln zwischen zwei Pfaden.
Perfekt für kurze Dateien: Configs, Hostnamen, Umgebungsdateien. Bei langen Dateien nimmst du less, sonst rauscht alles durch.
Drinnen navigierst du mit den Pfeiltasten. /wort sucht vorwärts, n springt zum nächsten Treffer, G ans Ende, q beendet. less +F folgt live wie tail -f, mit Ctrl-C kannst du zurückscrollen.
q ist fast immer der Ausgang.tail zeigt die letzten 10 Zeilen, head die ersten. -n 50 ändert die Anzahl. Der Star ist tail -f: Er bleibt dran und zeigt jede neue Zeile sofort. So schaust du einem Log live zu.
tail -f beendest du mit Ctrl-C. Das bricht nur das Zuschauen ab, dem Log passiert nichts.man ls öffnet die Handbuchseite (Navigation wie in less). Kennst du den Befehlsnamen nicht, sucht man -k kopieren (alias apropos) in allen Kurzbeschreibungen. Für die Schnellversion: befehl --help.
history listet deine letzten Befehle nummeriert. !42 führt Nummer 42 erneut aus, !! den letzten Befehl. Am schnellsten: Ctrl-R drücken und tippen, die Shell sucht rückwärts live mit.
Ctrl-R, drei Buchstaben, Enter.Slack-Nachricht vom Kollegen: „Das Deploy auf web-01 hängt, schau mal ins Log, ich muss in die Bahn." Du hast SSH-Zugang und weißt nur: Die Logs liegen irgendwo unter /var/log/app. Was tippst du, in welcher Reihenfolge?
Erst orientieren, dann das neueste Log finden, dann live zuschauen:
ls -lt sortiert nach Änderungszeit, das zuletzt beschriebene Log steht oben. head -n 3 zeigt nur die obersten drei Zeilen. Danach hängst du dich mit tail -f live dran und siehst den Healthcheck-Fehler sofort.
ls -lt | head zeigt dir, wo gerade wirklich geschrieben wird.Anlegen, kopieren, verschieben, löschen: klingt banal, ist aber der Bereich, in dem die teuersten Fehler passieren. Ein falsches rm und der Feierabend fällt aus. Hier lernst du die Handgriffe, und die Leitplanken dazu.
-p legt verschachtelte Pfade in einem Rutsch an und meckert nicht, wenn es Teile schon gibt. Ohne -p bricht mkdir a/b/c ab, sobald a fehlt.
Existiert die Datei nicht, wird sie leer angelegt. Existiert sie, wird nur ihr Änderungszeitstempel auf jetzt gesetzt. Daher der Name.
Für Verzeichnisse brauchst du -r (rekursiv), sonst verweigert cp. Vor riskanten Änderungen an einer Config ist cp datei datei.bak der billigste Lebensretter überhaupt.
cp nginx.conf nginx.conf.bak, dann editieren. Immer.Umbenennen ist unter Linux nur Verschieben auf einen neuen Namen. mv braucht kein -r, Verzeichnisse nimmt es einfach mit.
-r löscht Verzeichnisse rekursiv, -i fragt vor jeder Datei nach, -f unterdrückt jede Rückfrage. Es gibt keinen Papierkorb: Was rm nimmt, ist weg.
rm -rf plus falscher Pfad ist der klassischste anzunehmende Unfall. Vor jedem rm -rf: einmal durchatmen und den Pfad lesen. Profis testen vorher mit ls, was das Muster wirklich trifft.Ein Symlink ist ein Wegweiser auf eine andere Datei oder ein Verzeichnis. Deployments nutzen das ständig: current zeigt auf die aktive Version, ein Release-Wechsel ist nur ein neuer Link.
cp: erst das echte Ziel, dann der Name des Links.Die wichtigsten Kriterien: -name "*.log" (Muster), -type f (nur Dateien) oder -type d (nur Verzeichnisse), -size +100M (größer als), -mtime -1 (in den letzten 24h geändert). Mit -exec befehl {} \; führst du pro Treffer einen Befehl aus.
-s fasst pro Argument zusammen, -h macht die Größen lesbar. Die Kombi du -sh * | sort -rh | head ist DER Handgriff bei voller Platte: größte Brocken zuerst.
Das Monitoring weckt dich: Auf web-01 sind nur noch 6 Prozent Platz frei. Du willst in unter einer Minute wissen: Welches Verzeichnis frisst den Platz, und welche Datei genau? Wie gehst du vor?
Vom Groben ins Feine: erst die Partition, dann das Verzeichnis, dann die Datei.
Täter gefunden: ein 27-GB-Debug-Log, das jemand im Fehlereifer angelassen hat. Jetzt nicht einfach löschen, sondern erst klären, ob es noch beschrieben wird, dann leeren statt löschen (truncate -s 0), sonst hält der Prozess die Datei offen und der Platz bleibt belegt.
df sagt dir, DASS es eng ist. du sagt dir, WO. find -size sagt dir, WER.Unter Linux ist fast alles Text: Logs, Configs, CSV-Exporte, Prozesslisten. Wer Text filtern, schneiden und zählen kann, beantwortet Fragen in Sekunden, für die andere ein Dashboard bauen. Diese acht Befehle sind deine Klingen.
-i ignoriert Groß-/Kleinschreibung, -n zeigt Zeilennummern, -r durchsucht ganze Verzeichnisse, -v zeigt alle Zeilen, die das Muster NICHT enthalten. Mit -E nutzt du reguläre Ausdrücke wie "ERROR|WARN".
Das s heißt substitute, das g ersetzt alle Treffer pro Zeile statt nur den ersten. Ohne weitere Optionen schreibt sed nur auf die Ausgabe, die Datei bleibt unberührt. -i ändert die Datei direkt, dann vorher ein Backup machen (Modul 02 lässt grüßen).
awk zerlegt jede Zeile an Leerzeichen in Spalten: $1 ist die erste, $NF die letzte. awk kann eine ganze Programmiersprache sein, aber '{print $N}' deckt schon die Hälfte aller Alltagsfälle ab.
Wie awk, aber für Dateien mit festem Trennzeichen (Doppelpunkt, Semikolon, Komma). -d: setzt den Trenner, -f1 wählt das erste Feld, -f1,3 mehrere.
-n sortiert numerisch (sonst käme 10 vor 9), -r dreht die Reihenfolge um, -h versteht menschliche Größen wie 2,3G und 812M. -k2 sortiert nach der zweiten Spalte.
uniq entfernt doppelte Zeilen, aber nur wenn sie direkt untereinander stehen. Deshalb steht davor fast immer ein sort. -c stellt jeder Zeile ihren Zähler voran: fertig ist die Häufigkeitsstatistik.
sort | uniq -c | sort -rn ist das Statistik-Dreigespann: gruppieren, zählen, Top-Liste.-l zählt Zeilen und ist die mit Abstand häufigste Form: Wie viele Fehler? Wie viele Deployments heute? Ans Ende einer Pipe gehängt beantwortet wc -l jede „Wie viele…?"-Frage.
-u zeigt das gewohnte Patch-Format mit Kontext, wie in Git. Der Klassiker: die laufende Config gegen das Backup vergleichen, bevor du einen Neustart wagst. Keine Ausgabe heißt: identisch.
Die API ist träge, das Team vermutet einen Scraper. Vor dir liegt das nginx-access.log mit 1,2 Millionen Zeilen. Frage ans Log: Welche fünf IP-Adressen rufen am häufigsten auf? Ein Einzeiler reicht.
Lies die Pipe von links nach rechts wie einen Satz: awk greift die IP-Spalte, sort gruppiert gleiche IPs nebeneinander, uniq -c zählt jede Gruppe, sort -rn stellt die größten Zähler nach oben, head zeigt die Top 5. Eine IP mit 411.000 Aufrufen bei 1,2 Millionen Zeilen: Da ist dein Scraper.
uniq zählt nur direkt benachbarte Duplikate. Ohne sort davor ist die Statistik falsch, und zwar leise falsch.Einzelne Befehle kann jeder. Die eigentliche Superkraft der Shell ist das Verketten: kleine Werkzeuge, die ihre Ausgabe aneinander weiterreichen. Wer Pipes liest und schreibt, baut aus grep, sort und wc in einer Zeile Auswertungen, für die andere ein Python-Script anfangen.
Die Pipe reicht die Ausgabe des linken Befehls als Eingabe an den rechten weiter. Beim Lesen denkst du an jedem | einfach „… und damit dann". Jedes Werkzeug macht eine Sache, die Pipe macht daraus eine Kette.
grep das Richtige zeigt, hängst du | wc -l dran.> schreibt die Ausgabe in eine Datei statt aufs Terminal, >> hängt sie ans Ende an. Damit erzeugst du Reports, sammelst Ergebnisse über mehrere Läufe oder baust dir schnell eine Testdatei aus echo.
> überschreibt kommentarlos. Ein vertipptes > statt >> und der alte Inhalt ist weg. Keine Rückfrage, kein Papierkorb.Programme haben zwei Ausgabekanäle: stdout (Kanal 1) für Ergebnisse, stderr (Kanal 2) für Fehler. > fängt nur Kanal 1. Deshalb stehen Fehlermeldungen trotz Umleitung weiter auf dem Bildschirm. 2>&1 schickt Kanal 2 dorthin, wo Kanal 1 gerade hingeht, 2>/dev/null wirft Fehler weg.
> datei, dann 2>&1. Andersherum landet stderr doch wieder auf dem Terminal.tee ist das T-Stück im Rohr: Die Daten fließen weiter Richtung Terminal und landen gleichzeitig in der Datei. -a hängt an statt zu überschreiben. Berühmter Nebenjob: echo '…' | sudo tee /etc/datei, um mit Root-Rechten in eine Datei zu schreiben.
sudo befehl > datei scheitert an Root-Dateien, weil deine Shell (ohne sudo) die Datei öffnet. | sudo tee datei löst genau das.Eine Pipe füttert die Standardeingabe, aber viele Befehle wollen Argumente: rm liest keine Dateiliste von stdin. xargs übersetzt, es nimmt die Zeilen aus der Pipe und hängt sie als Argumente hinten an. find … | xargs … ist das Traumpaar.
find -print0 | xargs -0. Sonst zerlegt xargs einen Namen in zwei Argumente.Kurz vor Feierabend fragt dein Teamlead: „Wie viele INFO, WARN und ERROR hatten wir heute in logs/app.log? Häng die Auswertung als Datei ans Ticket, aber sag mir die Zahlen gleich hier." Eine Zeile, beides erledigt. Wie sieht sie aus?
Level-Spalte herausschneiden, sortieren, zählen, absteigend ordnen, und mit tee gleichzeitig anzeigen und speichern:
Von links gelesen: cut nimmt die dritte Spalte (das Level), sort stellt gleiche Werte nebeneinander, uniq -c zählt sie, sort -rn ordnet nach Häufigkeit, tee schreibt das Ergebnis in report.txt und zeigt es trotzdem an. Die Zeile funktioniert 1:1 im Übungs-Terminal unten.
sort | uniq -c | sort -rn ist die Standard-Kette für jede „Was kommt am häufigsten vor?"-Frage. Sie lohnt sich als Muskelgedächtnis.„Permission denied" ist die häufigste Fehlermeldung deiner Linux-Laufbahn. Wer das Rechtesystem einmal verstanden hat, liest ls -l wie einen Satz: Wer darf hier was, und wer sagt das? Dazu kommt sudo, der Generalschlüssel mit Protokollpflicht.
Rechte gibt es dreimal: Besitzer (u), Gruppe (g), Rest der Welt (o). Jede Stelle ist die Summe aus Lesen=4, Schreiben=2, Ausführen=1: 755 heißt rwxr-xr-x, 644 heißt rw-r--r--. Symbolisch geht es auch: chmod +x script.sh macht ausführbar, -R wirkt rekursiv.
Jede Datei hat einen Besitzer und eine Gruppe. Der Klassiker: Nach einem Deploy als root gehört plötzlich alles root, und der Webserver darf seine eigenen Dateien nicht mehr lesen. chown -R www-data:www-data stellt das richtig. chgrp ändert nur die Gruppe, chown darf nur root.
ls -l statt eines Namens nur eine Zahl (1003 1003), wurde der Besitzer-User gelöscht. Die Datei zeigt seine verwaiste UID.Die umask ist die Schablone, die beim Anlegen von den Maximalrechten abgezogen wird: 666 für Dateien, 777 für Verzeichnisse. Standard 022 ergibt darum 644 und 755. Gehärtete Umgebungen setzen 027: Die Gruppe darf lesen, alle anderen gar nichts.
chmod +x.sudo führt genau einen Befehl als root aus und protokolliert, wer wann was durfte. sudo -l zeigt, welche Befehle dir erlaubt sind. Konfiguriert wird das in /etc/sudoers, und zwar ausschließlich mit visudo: Das prüft die Syntax vor dem Speichern. Ein Tippfehler dort sperrt sonst alle aus.
sudo !! wiederholt den letzten Befehl mit Root-Rechten. Praktisch, wenn die Fehlermeldung gerade eben „Permission denied" war, und er wirklich Root braucht.Für einzelne Befehle reicht sudo. Willst du länger als root arbeiten, öffnet sudo -i eine echte Root-Shell samt Roots Umgebung. su - deploy wechselt zum Service-User, etwa um ein Problem mit dessen Rechten und Umgebung nachzustellen.
rm wirkt sofort und überall. Reingehen, erledigen, mit exit wieder raus.Dein Backup-Script liegt in /tmp, hat 755, gehört dir, und trotzdem: bash: ./backup.sh: Permission denied. Noch ein chmod +x ändert nichts. Was prüfst du als Nächstes?
Nicht die Rechte, sondern das Dateisystem: mount verrät, ob die Partition mit noexec eingehängt ist. Auf gehärteten Systemen ist genau das für /tmp Standard.
Die Rechte-Bits sind nur die halbe Wahrheit: Auch der Mount hat ein Wörtchen mitzureden. noexec verbietet Ausführen auf der ganzen Partition, egal was chmod sagt. bash backup.sh würde es auch umgehen (bash liest die Datei nur), sauberer ist ein Verzeichnis ohne noexec.
ls -l auf die Datei, dann die Verzeichnisse darüber, dann mount. Erst wenn alle drei sauber sind, wird es exotisch.Auf jedem Server laufen hunderte Prozesse, und meistens ist es genau einer, der dir den Tag versaut. CPU auf 100 %, API zäh, Monitoring rot: Hier lernst du, den Schuldigen zu finden, ihn sauber zu beenden und Dienste im Griff zu behalten.
ps aux zeigt alle Prozesse aller Nutzer: PID, CPU- und Speicheranteil, Startzeit, Befehl. Mit --sort=-%cpu oder -%mem stehen die größten Verbraucher oben, mit | grep suchst du gezielt nach einem Namen.
kill, /proc/PID, strace. Erst identifizieren, dann eingreifen.top ist das Live-Dashboard: Lastdurchschnitt, CPU, Speicher und die Prozessliste, sekündlich aktualisiert. Drinnen sortiert M nach Speicher, P nach CPU, k beendet eine PID, q geht raus. htop kann dasselbe hübscher, mit Scrollen, Suche und F-Tasten.
kill schickt Signale. Ohne Angabe SIGTERM (15): die höfliche Bitte, sich geordnet zu beenden, Verbindungen zu schließen, aufzuräumen. kill -9 (SIGKILL) reißt den Prozess sofort weg, ohne jedes Aufräumen. killall name trifft alle Prozesse mit diesem Namen.
kill -9 ist der Vorschlaghammer: keine Cleanup-Handler, Locks und Temp-Dateien bleiben liegen. Erst normal killen, ein paar Sekunden warten, dann eskalieren.Ein & am Ende startet den Befehl im Hintergrund, dein Terminal bleibt frei. Läuft schon etwas im Vordergrund: Ctrl-Z hält es an, bg lässt es hinten weiterlaufen, fg holt es zurück. jobs zeigt die Liste mit den %-Nummern.
Schließt du das SSH-Fenster, sterben deine Prozesse mit. nohup macht sie immun gegen das Auflegen (HUP-Signal), die Ausgabe landet in nohup.out. nice -n 10 startet einen Prozess mit niedrigerer Priorität: gut für dicke Batch-Jobs, die niemanden ausbremsen sollen.
nohup ./job.sh &, später mit tail -f nohup.out reinschauen. Für ernsthafte Dienste nimmst du systemd, nächste Karte.Echte Dienste (nginx, Postgres, deine App) laufen unter systemd. status zeigt Zustand, PID und die letzten Log-Zeilen, restart startet neu, enable sorgt für Autostart beim Boot. systemctl --failed listet auf, was gerade kaputt ist.
systemctl enable --now dienst.Monitoring-Alarm: CPU auf web-01 seit 20 Minuten bei 100 %, die API antwortet zäh. Du loggst dich ein. Wie findest du den Schuldigen, und wie wirst du ihn los, ohne Kollateralschaden anzurichten?
Erst identifizieren, dann höflich beenden, erst danach eskalieren:
397 % CPU heißt: fast vier Kerne nur für export.py. Nach dem TERM ein paar Sekunden warten und nachprüfen, erst wenn er dann noch lebt, kill -9 4711. Danach die eigentliche Arbeit: Warum lief der Export Amok? Cron-Job, Endlosschleife, zu große Datenmenge? Und falls der Prozess ein systemd-Dienst ist, lieber systemctl restart statt kill, sonst startet systemd ihn sowieso gleich neu.
Speicher zu 95 % belegt? Bloß nicht sofort neu starten. Linux nutzt freien RAM absichtlich als Cache, und wer das nicht weiß, jagt Geister. Hier lernst du, echte Speichernot von gesundem Caching zu unterscheiden, und den OOM-Killer zu überführen, wenn nachts eine App verschwindet.
free -h zeigt gesamt, benutzt, frei, und die entscheidende Spalte: verfügbar. Linux parkt ungenutzten RAM als Datei-Cache und gibt ihn sofort wieder her, sobald ein Programm ihn braucht. Ein „voller" Speicher ist deshalb meistens ein gesunder Speicher.
Wenn available wirklich schrumpft, willst du den Verursacher: Nach %MEM sortiert stehen die Speicherfresser oben, die Spalte RSS zeigt die echten Bytes im RAM. Ein Prozess, dessen RSS stetig wächst und nie wieder fällt, ist dein Leak-Kandidat.
vmstat 1 druckt jede Sekunde eine Zustandszeile. Die wichtigsten Spalten: r (Prozesse, die auf CPU warten), si/so (Swap rein/raus), wa (CPU wartet auf die Platte). Steht so dauerhaft über 0, lagert das System aktiv aus, und jetzt wird es wirklich eng.
free ist nur die hübsche Ansicht von /proc/meminfo. Dort stehen die Rohwerte, allen voran MemAvailable: die Kernel-Schätzung, wie viel RAM ohne Swapping nutzbar ist. swapon --show zeigt die aktiven Swap-Bereiche, ob Datei oder Partition.
Geht der Speicher wirklich aus, wählt der Kernel ein Opfer und beendet es: der OOM-Killer. Deine App ist nachts „einfach weg"? Das steht im Kernel-Log. dmesg | grep -i oom (oder journalctl -k) liefert den Beweis samt Prozessname, PID und Speicherbedarf zum Tatzeitpunkt.
03:12 Uhr Monitoring-Alarm, die App war down, der Kollege aus der Frühschicht hat sie um sechs neu gestartet. Jetzt sollst du klären: Absturz, Deploy-Fehler, oder hat der OOM-Killer zugeschlagen? Wie beweist du es, und was prüfst du danach?
Der Kronzeuge ist das Kernel-Log, danach schaust du dir die aktuelle Lage an:
Das Log beantwortet die Schuldfrage eindeutig: Der Kernel hat PID 4711 beendet, und anon-rss:6291456kB verrät, dass die App zum Tatzeitpunkt gut 6 GB im RAM hielt. Danach die Anschlussfrage: Wächst der Speicher der neu gestarteten App schon wieder stetig (Leak), oder war es eine einmalige Lastspitze? Das klärt ps aux --sort=-%mem im Zeitvergleich. Je nach Befund: Leak fixen, Memory-Limit setzen, oder ehrlich sein und die Maschine vergrößern.
Volle Platten sind der leiseste Ausfall der Welt: Erst schreibt das Log nicht mehr, dann stirbt die Datenbank, und keiner weiß warum. Hier lernst du, Platz zu finden, Übeltäter einzukreisen und Daten sicher zu verpacken und zu verschieben.
df zeigt pro Dateisystem: Größe, belegt, verfügbar, Einhängepunkt. -h macht die Zahlen lesbar. Mit Pfad-Argument siehst du sofort, auf welcher Partition ein Verzeichnis liegt. df -i zeigt Inodes: Auch die können ausgehen, während noch Platz frei ist (Millionen Mini-Dateien).
/ ist ein Notfall: Dienste können nicht mehr schreiben und sterben leise. Ab 90 % handeln, nicht ab 100.du misst, was Verzeichnisse wirklich belegen: -s fasst zusammen, -h lesbar. Der Alltagsgriff: du -sh * | sort -rh | head zeigt die dicksten Brocken zuerst. Dann steigst du in den größten hinab und wiederholst das Spiel, Ebene für Ebene.
lsblk zeigt den Hardware-Baum: Platten (sda), Partitionen (sda1), Größen, Einhängepunkte. mount zeigt, was wo mit welchen Optionen eingehängt ist, inklusive der Fallen ro (read-only) und noexec.
mount | grep verrät die Mount-Optionen der Partition.Vier Buchstaben, ein System: c create, x extract, t table (nur reinschauen), z gzip, f file (der Dateiname folgt direkt). tar -czf backup.tar.gz projekt packt, -xzf entpackt, -tzf zeigt vorher, was drin ist.
tar -tzf. Manche explodieren als hundert Einzeldateien ins aktuelle Verzeichnis, die berüchtigte Tarbomb.rsync überträgt nur, was sich geändert hat: Abgebrochene Läufe setzen fort, wiederholte Läufe sind fast sofort fertig. -a erhält Rechte und Zeitstempel, -v zeigt Dateien, -z komprimiert. Über SSH ist es das Standard-Werkzeug für Deployments und Backups.
quelle/ kopiert den Inhalt, quelle ohne Slash das Verzeichnis selbst. Der Unterschied hat schon viele doppelt verschachtelte Backups erzeugt.Alarm: / ist bei 97 %, die Datenbank verweigert Schreibzugriffe. Du hast fünf Minuten, bevor es eskaliert. Wie findest du heraus, was den Platz frisst, und was tust du zuerst?
Erst bestätigen (df), dann eingrenzen (du), Ebene für Ebene wie eine Schnitzeljagd:
Der Übeltäter ist ein rotiertes, nie gelöschtes Riesen-Log. Soforthilfe: komprimieren oder löschen (gzip /var/log/app.log.1 schafft sofort Luft). Danach die Ursache abstellen: logrotate konfigurieren, damit alte Logs komprimiert und nach X Tagen gelöscht werden, sonst stehst du nächsten Monat wieder hier.
„Die API ist down!" Ist sie meistens gar nicht: Irgendwo zwischen Prozess, Port, Firewall und DNS klemmt genau eine Schicht. Mit sechs Befehlen grenzt du systematisch ein, welche, und debuggst nie wieder auf gut Glück.
ip a zeigt Interfaces und Adressen (-br macht es kompakt), ip r die Routen samt Default-Gateway. Das alte ifconfig ist im Ruhestand. Für die Sicht von außen: curl ifconfig.me verrät deine öffentliche IP.
ip a, dann ip r.ping schickt Echo-Pakete und misst die Antwortzeit, -c 4 begrenzt auf vier Versuche. Paketverlust und schwankende Zeiten sind die ersten Hinweise auf Netzprobleme. Aber: Manche Server filtern ICMP weg und sind trotzdem kerngesund.
Die vier Buchstaben: t TCP, l nur Lauschende, n Nummern statt Namen, p Prozess dazu. Damit beantwortest du die wichtigste Netzwerkfrage auf jedem Server: Läuft mein Dienst, und auf welcher Adresse? (netstat ist der Vorgänger, ss der Standard.)
127.0.0.1:8080 heißt: nur lokal erreichbar. 0.0.0.0:8080 heißt: von überall. Dieser Unterschied ist die halbe Miete beim „von außen geht nichts"-Debugging.curl holt URLs, perfekt zum API-Testen ohne Browser. -I zeigt nur die Antwort-Header (Statuscode!), -v das komplette Gespräch inklusive TLS und Redirects, -s macht es still für Pipes. curl ifconfig.me verrät deine öffentliche IP.
dig fragt DNS-Server direkt. +short liefert nur die IP, ideal für Skripte. Mit @8.8.8.8 fragst du gezielt einen anderen Resolver: Unterscheiden sich die Antworten, ist dein DNS oder ein alter Cache das Problem.
dig +short in die ersten drei Befehle.ssh ist deine Standleitung auf fremde Maschinen, mit Schlüsseln statt Passwörtern (ssh-keygen, dann ssh-copy-id). scp kopiert Dateien durch denselben Tunnel, in beide Richtungen. Für große oder wiederholte Kopien: rsync über SSH (Modul 08).
ssh user@host 'befehl' führt einen einzelnen Befehl remote aus und kommt zurück. Das ist die Grundlage von fast jeder Automatisierung.Deine App antwortet auf dem Server (curl localhost:8080 liefert 200), aber vom Laptop aus: Timeout. DNS stimmt, ping auf den Server geht. Wo suchst du weiter, und was ist die häufigste Ursache?
Wenn der Dienst lokal antwortet, ist die nächste Frage: An welche Adresse ist er gebunden?
Da steht die Antwort: Die App bindet nur an 127.0.0.1, das Loopback-Interface. Von außen führt dorthin kein Weg, egal was Firewall und DNS sagen. Fix: in der App-Config an 0.0.0.0 binden, oder sauberer: einen Reverse-Proxy (nginx) davorschalten, der 80/443 nach innen weiterreicht. Die zweithäufigste Ursache wäre die Firewall (ufw status). Die beiden Befehle oben funktionieren übrigens 1:1 im Übungs-Terminal, auch das ist eine Mission.
Das letzte Modul macht aus Befehlen einen Beruf: Aufgaben automatisieren, Logs lesen, Systeme pflegen, Nutzer verwalten. Und am Ende richtest du dir die Shell so ein, dass sie sich anfühlt wie dein Werkzeug, nicht wie geliehen.
Fünf Felder, dann der Befehl: Minute Stunde Monatstag Monat Wochentag. 0 3 * * * heißt täglich 03:00, */10 * * * * alle zehn Minuten, 0 9 * * 1-5 werktags um neun. -l zeigt deine Jobs, -e öffnet sie im Editor.
>> /var/log/job.log 2>&1 (Modul 04 lässt grüßen).journalctl liest das zentrale systemd-Journal. -u nginx filtert auf einen Dienst, -f folgt live (wie tail -f), --since "1 hour ago" und -p err grenzen Zeitraum und Priorität ein. -k zeigt nur Kernel-Meldungen, bekannt aus der OOM-Forensik.
systemctl status (Zustand jetzt), journalctl -u (die Geschichte), journalctl -u -f (live dabei).Erste Minute auf einer fremden Maschine: uname -a (Kernel, Architektur), cat /etc/os-release (welche Distribution), dazu df -h und free -h für die Reserven. dmesg -T zeigt das Kernel-Log mit lesbaren Zeitstempeln: Hardware, Disk-Fehler, OOM-Kills.
apt update lädt nur die Paketlisten (was gäbe es Neues?), apt upgrade installiert die Updates dann wirklich. install holt Neues, search sucht, remove entfernt. Auf RHEL/Fedora heißt das Ganze dnf, auf Arch pacman, das Prinzip bleibt gleich.
id zeigt, wer du bist und in welchen Gruppen du steckst. sudo useradd -m -s /bin/bash anna legt einen User samt Home an, sudo usermod -aG docker anna nimmt ihn in eine Gruppe auf. Die neue Mitgliedschaft gilt erst nach dem nächsten Login.
usermod -G ohne -a ERSETZT alle bisherigen Gruppen des Users. Das kleine -a (append) ist der Unterschied zwischen „hinzufügen" und „aussperren".Ein alias macht aus deinem Lieblings-Langbefehl einen Kurzbefehl. Dauerhaft wird er in ~/.bashrc (bzw. ~/.zshrc): Die läuft bei jedem Shell-Start. Auch PATH-Erweiterungen und export EDITOR=vim wohnen dort. Nach Änderungen: source ~/.bashrc.
type befehl zeigt, ob ein Alias dazwischenfunkt.Dein nächtlicher Cron-Job (0 3 * * * backup.sh) hat heute Nacht nichts geschrieben. Von Hand gestartet läuft backup.sh sauber durch. Wie findest du heraus, was um 03:00 passiert ist, und was ist die klassische Ursache?
Drei Fragen, drei Befehle: Steht der Job? Hat Cron ihn gestartet? Was hat er gesagt?
Cron HAT den Job gestartet (das syslog beweist es), aber die Shell fand backup.sh nicht: Cron läuft mit Mini-PATH und nicht in deinem Home. Von Hand klappt es nur, weil DEINE Shell den Pfad kennt. Fix: absoluter Pfad in der Crontab (/home/ich/bin/backup.sh). Und weil die Ausgabe schon umgeleitet war, stand die Fehlermeldung im Log, statt spurlos zu verschwinden. Genau dafür war das 2>&1 da.
>> log 2>&1 am Ende debuggst du ein Gespenst.Lesen ist nett, tippen bleibt hängen. Hier läuft ein simuliertes Linux mit echtem Dateisystem: Home-Verzeichnis, Logs, Configs. Alle Befehle aus den Modulen funktionieren. Du kannst nichts kaputt machen, und genau dafür ist es da. Tipp help für den Überblick.