Nach dem ersten Login steht da eine Zeile und blinkt: leser@homelab:~$. Kein Menü, kein Symbol, kein Hinweis, was man jetzt tun könnte. Wer von Windows oder vom Mac kommt, kennt diese Stille nicht, und sie ist der Grund, warum viele Homelab-Projekte nach dem Login enden. Dabei ist die Zeile freundlicher, als sie aussieht: Sie sagt dir, wer du bist (leser), auf welchem Rechner (homelab), in welchem Ordner (~, dein Zuhause) und dass du ein normaler Benutzer bist ($, bei Root stünde dort #). Alles Weitere musst du ihr sagen.

Diese Anleitung geht die Befehle durch, die du dafür wirklich brauchst. Keine 200, keine Tabelle zum Ausdrucken, sondern zwanzig, sortiert nach der Situation, in der du sie tippst: Wo bin ich? Wie fasse ich eine Datei an? Was macht die Kiste gerade? Jeder Befehl kommt mit der Ausgabe, die du sehen wirst, damit du weißt, ob es geklappt hat. Es sind dieselben Befehle, die in jeder Anleitung auf dieser Seite zwischen den Docker-Zeilen stehen; hier bekommen sie einmal die Bühne.

Kurz gesagt: Am Ende bewegst du dich auf einem Linux-Rechner ohne Maus: Ordner finden und anlegen, Dateien schreiben, lesen, kopieren und löschen, Platte und Speicher prüfen, einen Dienst neu starten und seine Logs lesen, Updates einspielen. Zwanzig Befehle in drei Situationen, dazu sechs Tastenkürzel, die mehr Zeit sparen als jeder Befehl. Dauer: rund 45 Minuten zum Mittippen. Stufe: Einsteiger, normale PC-Kenntnisse reichen, alles Weitere wird erklärt. Stand: Debian 13 (Trixie) und Ubuntu 26.04 LTS, geprüft am 07-10-2026.
Schaubild: 20 Linux-Befehle in drei Situationen: Orientieren mit pwd, ls und cd; Anfassen mit mkdir, nano, cat, cp, mv und rm; Nachsehen mit df, free, top, systemctl, journalctl, sudo und apt
Der ganze Weg auf einen Blick: erst orientieren, dann anfassen, dann nachsehen.

Was die Shell ist, und warum sie nicht antwortet

Das schwarze Fenster heißt Terminal. Das Programm darin, das deine Eingaben liest und ausführt, heißt Shell; auf Debian und Ubuntu ist das die Bash. Das Terminal ist der Hörer, die Shell die Person am anderen Ende. Sie versteht eine feste Grammatik: zuerst der Befehl, dann Optionen mit Bindestrich, dann das Ziel. ls -l /etc heißt: Liste (ls), ausführlich (-l), den Ordner /etc.

Warum kommt nach manchen Befehlen nichts? Die Shell hat eine Angewohnheit, die Einsteiger für einen Fehler halten: Wenn alles geklappt hat, sagt sie oft gar nichts. mkdir, cp, mv und rm melden Erfolg durch Schweigen und Misserfolg durch eine Zeile Text. Kein Text ist also die gute Nachricht. Wer trotzdem sehen will, was passiert ist, hängt ein ls hinterher. Das machen wir unten bei jedem Schritt.

Noch zwei Dinge, bevor es losgeht. Linux unterscheidet Groß- und Kleinschreibung: Dokumente und dokumente sind zwei verschiedene Ordner. Und Leerzeichen trennen Argumente. Ein Ordner namens Meine Fotos wird von der Shell als zwei Ordner gelesen, Meine und Fotos. Deshalb benennen Linux-Leute ihre Ordner meine-fotos. Die Gewohnheit lohnt sich vom ersten Tag an.

Was du brauchst

  • Einen Linux-Rechner, auf dem du ein Terminal vor dir hast. Das kann ein alter Büro-PC mit Debian oder Ubuntu Server sein, ein Raspberry Pi, eine VM oder ein LXC-Container auf Proxmox, dessen Konsole du im Browser öffnest. Steht der Rechner im Keller, verbindest du dich per SSH; wie das sicher geht, steht im SSH-Beitrag.
  • Ein Konto, das sudo darf, also Befehle mit Verwaltungsrechten ausführen. Beim ersten Benutzer einer Ubuntu-Installation ist das immer so, bei Debian nur, wenn du bei der Installation kein Root-Passwort gesetzt hast. Prüfen wir gleich.
  • Eine halbe Stunde, in der niemand den Rechner braucht. Wir löschen nichts außer dem, was wir selbst anlegen.
So liest du diese Anleitung: Alles, was du selbst tun sollst, steht in einem farbigen Kasten. [ per klick ] heißt: Das erledigst du mit der Maus in einer Web-Oberfläche, hier kommt das nur einmal vor, beim Öffnen der Konsole in Proxmox. [ über die shell ] heißt: Den Befehl kopieren, ins Terminal einfügen, Enter. Stehen beide Kästen direkt untereinander, führen sie zum selben Ergebnis. Du gehst EINEN davon, nicht beide.

Alle Beispiele rechnen mit denselben Werten. Wo sie unten auftauchen, setzt du deine ein. Die Ausgaben stehen so da, wie ein auf Englisch eingerichtetes System sie zeigt; das ist bei Server-Installationen und Container-Vorlagen der Normalfall. Hast du bei der Installation Deutsch gewählt, sind die Wörter übersetzt, die Spalten und ihre Reihenfolge bleiben dieselben.

  • Benutzername: leser
  • Rechnername: homelab
  • Home-Verzeichnis: /home/leser, in der Shell abgekürzt als ~
  • Übungsordner, den wir anlegen und am Ende wieder löschen: ~/uebung
  • Ein Dienst zum Nachsehen: ssh (der SSH-Server; auf Ubuntu heißt er genauso, auf älteren Systemen sshd)

Zuerst die Vorprüfung: Welches System läuft, wer bist du, und darfst du sudo?

Wer auf Proxmox arbeitet: links im Baum den Container oder die VM anklicken, dann im mittleren Menü Konsole (Stand Proxmox VE 9.x). Es öffnet sich ein schwarzes Fenster mit der Anmeldung; Benutzername und Passwort eingeben, danach steht da die Zeile mit dem $. Alle folgenden Shell-Kästen tippst du in dieses Fenster.

cat /etc/os-release
whoami
sudo -v
PRETTY_NAME="Debian GNU/Linux 13 (trixie)"
NAME="Debian GNU/Linux"
VERSION_ID="13"
leser
[sudo] password for leser:

Die erste Ausgabe nennt dein System; hier stehen nur ihre ersten drei Zeilen, es folgen noch ein paar mit Adressen der Debian-Webseiten. Die zweite nennt deinen Benutzernamen. Die dritte fragt nach deinem Passwort und sagt danach nichts, und das ist, siehe oben, die gute Nachricht: Du darfst sudo. Käme stattdessen leser is not in the sudoers file, fehlt dir das Recht; dann ist der Beitrag trotzdem zu zwei Dritteln für dich, nur die letzte Situation braucht es.

Situation 1: Wo bin ich? (pwd, ls, cd)

Jede Shell steht immer in genau einem Ordner, dem Arbeitsverzeichnis. Alles, was du tippst, bezieht sich auf diesen Ordner, solange du keinen anderen Pfad nennst. Deshalb ist die erste Frage nach dem Login immer dieselbe.

Wo bin ich, und was liegt hier?

pwd
ls
/home/leser

pwd steht für print working directory und antwortet mit dem vollen Pfad. Das ~ in der Eingabezeile ist nur die Abkürzung dafür. ls listet den Inhalt, und auf einem frischen System ist dein Home-Verzeichnis leer, also kommt nichts. Nicht ganz: Es gibt versteckte Dateien, deren Name mit einem Punkt beginnt, und die zeigt ls nur auf Nachfrage.

Alles zeigen, ausführlich, mit lesbaren Größen:

ls -lah
total 24K
drwx------ 3 leser leser 4.0K Oct  6 12:45 .
drwxr-xr-x 3 root  root  4.0K Oct  6 12:43 ..
-rw-r--r-- 1 leser leser  220 May  9 11:07 .bash_logout
-rw-r--r-- 1 leser leser 3.5K May  9 11:07 .bashrc
-rw-r--r-- 1 leser leser  807 May  9 11:07 .profile
drwx------ 2 leser leser 4.0K Oct  6 12:45 .ssh
-rw-r--r-- 1 leser leser    0 Oct  6 12:45 .sudo_as_admin_successful

Drei Optionen in einem Wort: -l für die lange Form, -a für all inklusive Punkt-Dateien, -h für human-readable, also 3.5K statt 3542. Die Zeile liest sich von links: Rechte, Anzahl Verweise, Besitzer, Gruppe, Größe, Datum, Name. Datum und Größe sehen bei dir anders aus, der Rest nicht. Ein d am Anfang heißt Ordner. Die Rechte erklärt ein eigener Beitrag irgendwann; für heute reicht, dass leser leser in der Mitte bedeutet, die Datei gehört dir. Die beiden Einträge . und .. sind keine Dateien, sondern der Ordner selbst und sein Elternordner. Den zweiten brauchst du gleich. Und die leere Datei ganz unten hat eben unser sudo -v angelegt: Debian und Ubuntu merken sich so, dass du sudo schon einmal erfolgreich benutzt hast.

Einen Ordner hoch, nachsehen, wieder zurück nach Hause:

cd ..
pwd
cd
pwd
/home
/home/leser

cd heißt change directory. cd .. geht eine Ebene nach oben, cd ohne alles bringt dich immer nach Hause, egal wo du gerade steckst, und cd - springt zurück in den Ordner, aus dem du gerade gekommen bist. Pfade, die mit / beginnen, gelten vom Wurzelverzeichnis aus; alle anderen vom aktuellen Ordner. cd /etc landet immer in /etc, cd etc sucht einen Ordner etc dort, wo du gerade stehst.

Und jetzt der Handgriff, der mehr Tipparbeit spart als alle Befehle zusammen: Tipp cd /et und drück die Tab-Taste. Die Shell ergänzt zu cd /etc/. Tab vervollständigt Befehle, Ordner- und Dateinamen, und bei mehreren Möglichkeiten zeigt ein zweites Tab die Liste. Wer Tab benutzt, vertippt sich nicht mehr bei Pfaden. Das ist der eine Griff, den ich jedem beibringen würde, bevor er den zweiten Befehl lernt.

Situation 2: Dateien anfassen (mkdir, nano, cat, less, cp, mv, rm)

Ab hier legen wir etwas an. Alles passiert in einem Übungsordner, den wir am Ende wieder löschen.

Ordner anlegen, hineinwechseln, Datei im Editor öffnen:

mkdir -p ~/uebung
cd ~/uebung
nano notiz.txt

Es öffnet sich ein leerer Editor mit einer Leiste unten. Ein paar Zeilen tippen, etwa:

Erster Dienst: Pi-hole
Zweiter Dienst: Uptime Kuma
Dritter Dienst: noch offen

Speichern mit Strg+O, dann Enter (der Dateiname wird bestätigt); schließen mit Strg+X. Danach prüfen:

ls -l
cat notiz.txt
total 4
-rw-r--r-- 1 leser leser 78 Oct  6 12:45 notiz.txt
Erster Dienst: Pi-hole
Zweiter Dienst: Uptime Kuma
Dritter Dienst: noch offen

Drei Befehle, drei Werkzeuge. mkdir legt den Ordner an; das -p sorgt dafür, dass fehlende Zwischenordner gleich mit entstehen und dass kein Fehler kommt, wenn der Ordner schon existiert. Fast jede Anleitung auf dieser Seite beginnt mit genau dieser Zeile. nano ist der Texteditor, der auf Debian und Ubuntu vorinstalliert ist; die Leiste unten zeigt seine Tasten, das ^ dort steht für Strg. Neuere Versionen nehmen auch Strg+S zum Speichern, Strg+O geht überall. Und cat gibt die Datei einfach aus. Für drei Zeilen perfekt, für 3.000 unbrauchbar, weil alles vorbeirauscht.

Eine lange Datei seitenweise lesen; q beendet die Ansicht, Leertaste blättert, /wort sucht:

less /etc/services

less ist das Lesegerät für alles, was nicht auf einen Bildschirm passt. Es lädt nichts in den Speicher, man kann rauf- und runterblättern, und das q zum Beenden ist das, was Einsteiger am häufigsten suchen. Dieselbe Taste beendet auch top und die Manpages, die weiter unten kommen. Wer einmal in less festhing, vergisst sie nicht mehr.

Kopieren, umbenennen, nachsehen:

cp notiz.txt notiz-backup.txt
mv notiz-backup.txt dienste.txt
ls
dienste.txt  notiz.txt

cp kopiert Quelle nach Ziel, mv verschiebt. Dass mv auch das Umbenennen erledigt, verwirrt kurz und ist dann logisch: Umbenennen ist Verschieben an denselben Ort unter neuem Namen. Beide überschreiben ein vorhandenes Ziel ohne Nachfrage. Wer das nicht will, hängt -i an, dann fragt die Shell vorher. Für Ordner braucht cp die Option -r, rekursiv, also mitsamt Inhalt; mv nimmt Ordner auch so.

Bleibt das Löschen, und dazu gehört die Warnung, die in der Ubuntu-Doku steht und die ich wörtlich übernehme, weil sie nicht zu übertreffen ist: Anders als in grafischen Oberflächen gibt es keinen Papierkorb. Was rm entfernt, ist weg, vollständig und endgültig. Mein Backup-Tick kommt hier nicht am Ende, sondern vor dem Befehl: Bevor du ein rm tippst, tippst du ein ls mit demselben Pfad. Dann siehst du, was gleich verschwindet.

Erst nachsehen, dann eine Datei löschen, dann den Rest des Übungsordners:

ls ~/uebung
rm ~/uebung/dienste.txt
ls ~/uebung
cd
rm -r ~/uebung
ls ~/uebung
dienste.txt  notiz.txt
notiz.txt
ls: cannot access '/home/leser/uebung': No such file or directory

Die letzte Zeile ist eine Fehlermeldung, und sie ist das gewünschte Ergebnis: Der Ordner ist weg. rm -r löscht einen Ordner mit allem darin. Du wirst im Netz überall rm -rf lesen; das f steht für force und unterdrückt jede Rückfrage und jede Fehlermeldung. Ich lasse es weg, solange es geht. Die Rückfragen, die rm von sich aus stellt, kommen selten, und wenn sie kommen, gibt es einen Grund. Und zwischen rm -r ~/uebung und rm -r ~ /uebung liegt ein Leerzeichen und dein gesamtes Home-Verzeichnis. Auch deshalb Tab statt Tippen.

Dazwischen: in Dateien lesen und suchen (tail, grep)

Zwei Befehle passen in keine der drei Schubladen und sind trotzdem täglich dran, sobald der erste Dienst läuft. Beide arbeiten mit Logs, also mit den Protokolldateien, in die Programme schreiben, was sie tun.

Die letzten 20 Zeilen einer Datei, dann live zusehen, wie neue dazukommen (Strg+C beendet das Zusehen):

tail -n 20 /var/log/dpkg.log
tail -f /var/log/dpkg.log

Zeilen finden, in denen ein Wort vorkommt, Groß- und Kleinschreibung egal:

grep -i "install" /var/log/dpkg.log

tail zeigt das Ende einer Datei, ohne -n die letzten zehn Zeilen. Mit -f, follow, bleibt es offen und zeigt jede neue Zeile, sobald sie geschrieben wird; das ist der Befehl, mit dem man einem Dienst beim Starten zusieht. grep durchsucht Dateien nach einem Muster und gibt die passenden Zeilen aus, mit -i ohne Rücksicht auf Groß- und Kleinschreibung, mit -n mit Zeilennummer, mit -r durch alle Dateien eines Ordners.

Das Interessante an grep ist weniger der Befehl als das Zeichen, mit dem man ihn an andere hängt: der senkrechte Strich |, die Pipe. Sie leitet die Ausgabe des linken Befehls als Eingabe in den rechten. ls -la | grep ssh listet alles und zeigt nur die Zeilen mit ssh. Wenn du in einer Anleitung ein | grep siehst, weißt du jetzt, dass davor eine lange Ausgabe kommt und dahinter der Filter. Die Datei /var/log/dpkg.log habe ich gewählt, weil sie auf jedem Debian und Ubuntu existiert und harmlos ist; sie protokolliert Paketinstallationen.

Situation 3: Was macht die Kiste? (df, free, top, ip)

Sobald ein Dienst läuft, werden das die vier Fragen, die du am häufigsten stellst: Ist die Platte voll? Reicht der Speicher? Warum ist alles langsam? Welche Adresse hat der Rechner überhaupt?

Platte und Arbeitsspeicher, in lesbaren Einheiten:

df -h /
free -h
Filesystem                        Size  Used Avail Use% Mounted on
/dev/mapper/pve-vm--103--disk--0   20G  1.3G   18G   7% /
               total        used        free      shared  buff/cache   available
Mem:           4.0Gi        75Mi       3.0Gi       140Ki       933Mi       3.9Gi
Swap:          512Mi          0B       512Mi

df berichtet die Belegung der Dateisysteme, das / dahinter beschränkt es auf die Systemplatte, ohne das kommt eine lange Liste mit allen eingehängten Geräten. Der Name in der ersten Spalte hängt davon ab, wo das System läuft: In einem Proxmox-Container ist es wie hier eine virtuelle Platte mit der Container-Nummer im Namen, auf einem echten PC steht dort /dev/sda2 oder /dev/nvme0n1p2. Die Spalte Use% ist die, nach der du schaust; ab 90 Prozent wird es Zeit, nachzusehen, wer den Platz nimmt. Bei free lesen Einsteiger die falsche Spalte: Nicht free zählt, sondern available. Linux nutzt ungenutzten Speicher als Zwischenspeicher für Dateien, die Spalte buff/cache, und gibt ihn sofort her, wenn ein Programm ihn braucht. Die Manpage nennt available ausdrücklich als die Schätzung, wie viel Speicher ein neues Programm bekäme, ohne dass ausgelagert wird. Oben sind das die 933 Megabyte Cache, die zu den 3 Gigabyte free dazukommen und 3,9 Gigabyte available ergeben. Ein Rechner mit free 400Mi und available 12Gi hat kein Speicherproblem, er hat einen gut gefüllten Cache. Auf einem deutsch eingerichteten System heißen die Spalten Verw%, frei, Puffer/Cache und verfügbar; die Reihenfolge ist dieselbe.

Was läuft gerade und frisst Rechenzeit; q beendet die Ansicht:

top

Welche IP-Adressen der Rechner hat:

ip -brief -4 address
lo               UNKNOWN        127.0.0.1/8
eth0@if114       UP             10.0.0.103/24

top ist der Task-Manager fürs Terminal: oben die Lastzahlen und der Speicher, darunter die Prozesse, sortiert nach CPU. Die drei Zahlen hinter load average sind die durchschnittliche Zahl wartender Prozesse der letzten 1, 5 und 15 Minuten; liegt die erste dauerhaft über der Zahl deiner CPU-Kerne, ist der Rechner ausgelastet. Wer es bunter mag, installiert später htop, aber top ist überall da. ip -brief -4 address zeigt pro Netzwerkkarte eine Zeile; das -4 lässt die langen IPv6-Adressen weg, die hier nur Platz kosten. lo ist die interne Schleife, die jeder Rechner hat, eth0 (oder ens18, enp3s0, je nach Hardware) deine echte Karte mit der Adresse, die du in den Browser tippst. Der Anhang @if114 erscheint nur in einem Container und nennt die Gegenstelle der Karte auf dem Proxmox-Host; auf einem echten PC steht dort nur der Name. Ist Docker installiert, kommt eine dritte Zeile docker0 dazu, die Brücke, über die Container ins Netz gehen; sie steht auf DOWN, bis der erste Container läuft. Das lange -brief gibt es laut Manpage nur für address, link und neigh, aber das sind auch die drei, die man braucht.

Dienste und ihre Logs (systemctl, journalctl)

Jeder Dienst auf einem modernen Linux, der SSH-Server, Docker, Pi-hole ohne Container, wird von systemd verwaltet, dem Hausmeister des Systems. Er startet Dienste beim Hochfahren, startet sie neu, wenn sie abstürzen, und sammelt alles, was sie auf die Konsole schreiben, in einem zentralen Protokoll, dem Journal. Zwei Befehle reden mit ihm.

Zustand eines Dienstes, hier des SSH-Servers:

systemctl status ssh
● ssh.service - OpenBSD Secure Shell server
     Loaded: loaded (/usr/lib/systemd/system/ssh.service; enabled; preset: enabled)
     Active: active (running) since Thu 2026-09-03 22:56:11 CEST; 1 month 0 days ago
       Docs: man:sshd(8)
             man:sshd_config(5)
   Main PID: 612 (sshd)
      Tasks: 1 (limit: 18923)
     Memory: 8.4M (peak: 44.1M)
        CPU: 2.311s
     CGroup: /system.slice/ssh.service
             └─612 "sshd: /usr/sbin/sshd -D [listener] 0 of 10-100 startups"

Zwei Zeilen zählen. Loaded mit enabled heißt: startet beim Hochfahren automatisch. Active mit active (running) heißt: läuft gerade, seit dem genannten Zeitpunkt. Stünde dort failed, ist der Dienst abgestürzt, und inactive (dead) heißt, er wurde gestoppt. Wenn der Dienst auf failed steht oder sich nach einer Konfigurationsänderung nicht gemeldet hat, kommen die beiden nächsten Befehle.

Dienst neu starten (braucht Verwaltungsrechte), dann die letzten 30 Protokollzeilen genau dieses Dienstes:

sudo systemctl restart ssh
journalctl -u ssh -n 30

Live mitlesen, wie bei tail -f; Strg+C beendet:

journalctl -u ssh -f

Alles seit dem letzten Hochfahren, seitenweise wie in less:

journalctl -b

Ein Neustart von ssh wirft dich übrigens nicht aus deiner laufenden SSH-Sitzung; die bestehende Verbindung läuft als eigener Prozess weiter, nur neue Anmeldungen gehen kurz über den frischen Dienst. journalctl ist der Leser für das Journal: -u filtert auf eine Unit, also einen Dienst, -n begrenzt die Zeilenzahl, -f folgt live und -b zeigt den aktuellen Bootvorgang. Die Kombination -u dienst -n 50 ist das, was du bei jedem Problem als Erstes tippst, noch vor der Suchmaschine. Für Docker-Container gilt dasselbe Prinzip mit docker compose logs; das steht in den Compose-Grundlagen.

Verwaltungsrechte und Updates (sudo, apt)

Zwei Befehle fehlen noch, und sie gehören zusammen, weil der eine ohne den anderen nicht geht. sudo führt den Befehl dahinter mit den Rechten des Verwalters aus, genannt Root. Du tippst dein eigenes Passwort, nicht ein Root-Passwort, und laut Manpage merkt sich sudo das für 15 Minuten pro Terminal, damit du es nicht bei jedem Befehl neu eingeben musst. Die Regel, wann sudo davorkommt, ist einfacher als sie klingt: dann, wenn der Befehl ohne sudo mit Permission denied antwortet. Lesen im eigenen Home braucht es nie, Schreiben unter /etc immer, Dienste neu starten und Pakete installieren auch. Die Ubuntu-Doku ergänzt einen Satz, den ich unterschreibe: Sei sicher, dass du verstehst, was der Befehl tut, bevor du ihn mit sudo ausführst. Ein rm -r mit sudo davor kennt keine Grenze mehr.

apt ist der Paketmanager von Debian und Ubuntu, der App-Store ohne Store: Programme und Updates kommen aus Paketquellen, die das System kennt. Drei Befehle decken 95 Prozent ab.

Paketlisten aktualisieren (lädt nur Informationen, ändert nichts), dann nachsehen, was ansteht:

sudo apt update
apt list --upgradable
46 packages can be upgraded. Run 'apt list --upgradable' to see them.
base-files/stable 13.8+deb13u7 amd64 [upgradable from: 13.8+deb13u6]
bash/stable 5.2.37-2+b10 amd64 [upgradable from: 5.2.37-2+b9]

Vor der Zeile mit der Zahl stehen noch ein paar Zeilen, die mit Hit oder Get beginnen, eine je Paketquelle. Meldet apt update am Ende All packages are up to date und kommt nach apt list --upgradable nichts zurück, ist alles aktuell. Sonst folgt pro Paket eine Zeile mit Name, Quelle, neuer Version und in eckigen Klammern der alten; oben stehen die ersten zwei. Die Reihenfolge der Befehle ist keine Deko. apt update lädt laut Manpage nur die Paketinformationen aus den Quellen; ohne diesen Schritt weiß apt nichts von neuen Versionen, und upgrade meldet fröhlich, alles sei aktuell.

Updates einspielen. Vor dem Download zeigt apt die Liste der Pakete und fragt Continue? [Y/n]; Enter nimmt die großgeschriebene Vorgabe, also Ja:

sudo apt upgrade

apt upgrade installiert die Updates und entfernt dabei nie ein Paket; braucht ein Update das, wird es zurückgestellt. Dafür gibt es full-upgrade, und das ist auch der Befehl, vor dem mein Backup-Tick anspringt. Für den normalen Monatsrhythmus reicht upgrade. Ein Update des Kernels wird erst nach einem Neustart wirksam; sudo reboot erledigt den, und bei einer SSH-Sitzung fliegst du dabei raus, das ist normal.

Ein Programm installieren, hier den bunteren Task-Manager:

sudo apt install htop
Installing:
  htop
Summary:
  Upgrading: 0, Installing: 1, Removing: 0, Not Upgrading: 0
Setting up htop (3.4.1-5) ...

Dazwischen stehen die Download-Zeilen und eine Zeile Suggested packages mit Werkzeugen, die htop gern hätte, aber nicht braucht. Die Nachfrage Continue? kommt hier nicht, weil nur ein einzelnes kleines Paket ansteht. Die letzte Zeile Setting up ist die Erfolgsmeldung; danach startet htop mit dem gleichnamigen Befehl und endet wie top mit q.

Sechs Tasten, die mehr bringen als der nächste Befehl

TasteWas sie tut
TabVervollständigt Befehle, Pfade und Dateinamen. Zweimal Tab zeigt alle Möglichkeiten. Die wichtigste Taste der Shell.
Pfeil hochHolt den vorherigen Befehl zurück, nochmal drücken für den davor. Ändern, Enter.
Strg+RSucht rückwärts in allem, was du je getippt hast. Strg+R, dann compose tippen, und der letzte Befehl mit compose steht da. Enter führt ihn aus, Pfeiltasten holen ihn zum Ändern.
Strg+CBricht den laufenden Befehl ab. Rettet dich aus tail -f, journalctl -f und jedem Befehl, der nicht aufhören will. Kopiert nichts; Kopieren und Einfügen gehen im Terminal über die rechte Maustaste oder Strg+Shift+C und Strg+Shift+V.
Strg+LRäumt den Bildschirm frei. Dasselbe wie der Befehl clear, nur ohne Enter.
qBeendet less, top, man und jede seitenweise Ansicht, auch die von journalctl und systemctl status, wenn sie länger als der Bildschirm wird.

Und wenn du bei einem Befehl nicht weiterweißt, hat er seine Anleitung dabei: ls --help gibt die Kurzfassung aus, man ls die vollständige Manpage, die du mit q wieder verlässt. Die Manpages sind trocken, aber sie lügen nicht, und sie sind die Quelle, aus der dieser Beitrag seine Erklärungen zu free, rm und apt hat.

Was am Ende sitzt

Bei einer Installation heißt dieser Abschnitt sonst „Was am Ende eingestellt ist". Bei Befehlen gibt es nichts einzustellen, aber fünf Gewohnheiten, die den Unterschied machen zwischen jemandem, der die Shell benutzt, und jemandem, der sie fürchtet.

  1. Vor jedem rm ein ls mit demselben Pfad. Es gibt keinen Papierkorb, und -f bleibt weg, bis du weißt, warum du es brauchst.
  2. sudo erst, wenn Permission denied kommt. Nicht vorsorglich vor jeden Befehl. Wer alles mit sudo macht, legt Dateien an, die ihm selbst nicht mehr gehören, und wundert sich beim nächsten nano.
  3. Bei jedem Problem zuerst systemctl status, dann journalctl -u dienst -n 50. In neun von zehn Fällen steht die Antwort in den letzten zwanzig Zeilen, bevor du die erste Suchmaschine aufmachst.
  4. Einmal im Monat apt update und apt upgrade, dann ein Blick auf df -h /. Ein Rechner im Keller, den niemand ansieht, holt sich seine Updates nicht von selbst, und seine Platte läuft leise voll. Wer das automatisieren will: Debian und Ubuntu bringen dafür unattended-upgrades mit, das verdient einen eigenen Beitrag.
  5. Tab und Strg+R statt Abtippen. Die Hälfte aller Fehlermeldungen in diesem Beitrag entsteht durch Tippfehler in Pfaden. Die Shell kann sie dir abnehmen.

Wo es klemmt

command not found oder Befehl nicht gefunden. Entweder vertippt (sl statt ls ist ein Klassiker) oder das Programm ist nicht installiert, bei htop oder tree zum Beispiel. Debian und Ubuntu schlagen oft gleich das passende apt install vor. Seltener: Der Befehl existiert nur für Root, dann hilft sudo davor.

No such file or directory oder Datei oder Verzeichnis nicht gefunden. Der Pfad stimmt nicht. Fast immer Groß- und Kleinschreibung, ein Leerzeichen im Namen oder ein relativer Pfad aus dem falschen Ordner heraus. pwd und ls klären das in zwei Sekunden, und Tab hätte es verhindert.

Permission denied oder Keine Berechtigung. Die Datei gehört nicht dir, siehe die Spalten Besitzer und Gruppe in ls -l. Beim Lesen von Systemdateien und beim Schreiben außerhalb deines Home-Verzeichnisses ist sudo die Antwort. Kommt die Meldung in deinem eigenen Home, hat irgendwann ein sudo zu viel eine Datei als Root angelegt; sudo chown leser:leser dateiname gibt sie dir zurück.

Das Terminal reagiert nicht mehr. Du steckst in einem Programm. q versuchen (less, top, man), dann Strg+C (laufender Befehl), dann Strg+X (nano, fragt bei ungespeicherten Änderungen mit J/N nach). Steht links unten ein :, bist du in less; steht eine Leiste mit ^X, in nano. Hilft nichts, ist der Rechner vermutlich wirklich beschäftigt, und ein zweites Terminal zeigt mit top, womit.

E: Sperre /var/lib/dpkg/lock-frontend konnte nicht erlangt werden. Ein anderes apt läuft gerade, auf frischen Systemen meist die automatische Update-Prüfung direkt nach dem Hochfahren. Eine Minute warten und noch einmal. Nicht die Sperrdatei löschen, auch wenn Foren das vorschlagen; dann läuft das zweite apt ins erste hinein.

Die Zeile blinkt immer noch, aber sie ist jetzt kein leerer Bildschirm mehr, sondern eine Frage, auf die du zwanzig Antworten hast. Alles, was auf dieser Seite folgt, Docker, Pi-hole, Reverse Proxy, setzt genau diese zwanzig voraus und keinen mehr. Welcher Befehl hat dich beim ersten Linux-Rechner am längsten aufgehalten, und welchen hättest du gern früher gekannt? Schreib's in die Kommentare, ich sammle die Antworten für den Nachfolger über Rechte und Besitzer.

Wenn der nächste Schritt für dich der erste Dienst ist, liest sich die Docker-Compose-Anleitung für Einsteiger jetzt deutlich entspannter: Jede Zeile dort, die mit mkdir, cd oder nano beginnt, kennst du schon.

Quellen