Warum dieser Schritt so wichtig ist

Viele Anleitungen vermitteln den Eindruck, dass WSL2 nach der Installation „fertig“ ist.
Technisch stimmt das – praktisch jedoch nicht.

Eine ungepflegte Standardinstallation führt in der Webentwicklung häufig zu:

langsamen Builds bei Composer oder npm
unklaren Datei- und Benutzerrechten
Problemen mit Git, Docker oder Node-Tools
einer Umgebung, die sich nicht wie echtes Linux anfühlt

WSL2 ist kein klassischer Linux-Server, sondern:

eine virtuelle Linux-Umgebung mit sehr enger Windows-Integration

Genau diese Integration muss bewusst konfiguriert werden, damit sie hilft statt behindert.

Ubuntu unter WSL2 starten und den Zustand prüfen

Ubuntu wird idealerweise über das Windows Terminal gestartet:

wsl

Oder explizit:

wsl -d Ubuntu

Was passiert beim Start technisch?

Windows startet eine leichte virtuelle Maschine
Ein eigenes Linux-Dateisystem (ext4) wird geladen
Prozesse laufen isoliert von Windows, aber mit Brücken (Netzwerk, Dateisystem, Prozesse)

Ubuntu-Version prüfen

lsb_release -a

Warum das wichtig ist:
Bestimmte Tools, PHP-Versionen oder Node-Releases setzen neuere Systembibliotheken voraus.
Für 2025 solltest du auf Ubuntu 22.04 LTS oder 24.04 LTS setzen.

Benutzer, Rechte und das Linux-Sicherheitsmodell verstehen

Warum Benutzer unter Linux anders funktionieren als unter Windows

Linux basiert auf einem strikten Rechte- und Eigentümermodell:

Jede Datei gehört genau einem Benutzer
Jeder Prozess läuft unter genau einem Benutzer
Root ist kein „Admin“, sondern ein uneingeschränktes Systemkonto

Aktuellen Benutzer prüfen

whoami

Wenn du hier root siehst, solltest du sofort umstellen.

Warum man nicht als root entwickeln sollte

Arbeiten als root:

verschleiert echte Berechtigungsprobleme
erzeugt Dateien, die später niemand ändern darf
führt bei Git, npm und Docker zu schwer nachvollziehbaren Fehlern

Best Practice:

Entwickle immer als normaler Benutzer. Nutze sudo nur für Systemänderungen.

Standard-Benutzer für WSL festlegen

Damit Ubuntu immer mit dem richtigen Benutzer startet, wird eine Konfigurationsdatei verwendet.

sudo nano /etc/wsl.conf

[user]

Was bewirkt das?

WSL startet immer mit diesem Benutzer
Skripte, Services und Shells laufen konsistent
Weniger Seiteneffekte zwischen Sitzungen

Danach WSL vollständig neu starten:

wsl --shutdown

System aktualisieren – mehr als nur Höflichkeit

sudo apt update && sudo apt upgrade -y

Warum das nicht optional ist

Sicherheitsupdates werden nicht automatisch installiert
Viele Tutorials scheitern, weil Pakete veraltet sind
Neue Kernel-Funktionen werden besser unterstützt

Ein gepflegtes System ist schneller, stabiler und sicherer.

Basis-Tools installieren und warum sie gebraucht werden

sudo apt install -y \
  build-essential \
  curl \
  wget \
  unzip \
  zip \
  git \
  ca-certificates \
  software-properties-common

Erklärung der wichtigsten Pakete

build-essential: Compiler und Build-Tools für native Node-Module
curl / wget: Download-Tools für Installer und APIs
git: Versionskontrolle, unverzichtbar
ca-certificates: HTTPS-Zertifikate für sichere Verbindungen
software-properties-common: Verwaltung externer Paketquellen

Ohne diese Basis stoßen viele Frameworks sehr schnell an Grenzen.

WSL2 richtig konfigurieren: Linux-Seite (`wsl.conf`)

sudo nano /etc/wsl.conf

[automount]
enabled =

Was hier wirklich passiert

Automount & Dateirechte

Windows-Laufwerke werden automatisch eingebunden
Linux-Dateirechte bleiben erhalten
Git, Composer und npm verhalten sich korrekt

Ohne diese Optionen entstehen die bekannten:

„Permission denied“-Fehler
nicht ausführbare Skripte
kaputte Node-Module

Windows-PATH deaktivieren

appendWindowsPath =

Das verhindert:

doppelte Binaries
Konflikte zwischen Windows- und Linux-Tools
schwer nachvollziehbare Versionen

Windows-seitige WSL2-Konfiguration (`.wslconfig`)

Diese Datei steuert Ressourcen wie RAM und CPU.

Pfad:

[wsl2]
memory=

Warum das relevant ist

Standardmäßig nutzt WSL:

dynamisch viel RAM
teils zu viele CPU-Kerne

Das führt zu:

unnötiger Windows-Verlangsamung
ineffizientem Ressourcenmanagement

Eine feste Zuweisung sorgt für vorhersagbares Verhalten.

Das wichtigste Performance-Thema: Dateisystem

Der häufigste Fehler überhaupt

Projekte unter:

/mnt/c/Users/...

Warum das langsam ist

Jede Dateioperation läuft über eine Übersetzungsschicht
Tausende kleine Dateien (Node, Vendor) werden extrem teuer
Tools wie Composer und npm sind besonders betroffen

Die richtige Lösung

mkdir -p ~/projects
cd ~/projects

Merksatz:

Code gehört ins Linux-Dateisystem, nicht ins Windows-Dateisystem.

Netzwerk unter WSL2 verstehen

WSL2 besitzt:

eine eigene virtuelle Netzwerkkarte
eine eigene IP-Adresse
automatisches Port-Forwarding zu Windows

Warum `localhost` trotzdem funktioniert

Windows leitet:

alle offenen Linux-Ports
automatisch an localhost weiter

Das ist kein Zufall, sondern explizit für Entwickler gedacht.

Typische Fehler und warum sie entstehen

Langsame Builds

Ursache:

Projekt liegt auf /mnt/c

Lösung:

Projekt nach ~/projects verschieben

Dienste starten nicht automatisch

Ursache:

WSL nutzt standardmäßig kein systemd

Lösung:

bewusst manuell starten oder systemd aktivieren
(Das behandeln wir später in der Serie.)

Best Practices 2025 – strategisch gedacht

Denke in Schichten:

Windows: Editor, Browser, Debugging
WSL2: Laufzeitumgebung
Linux: Code, Services, Abhängigkeiten

Behandle WSL2 wie:

einen lokalen Entwicklungscontainer mit Linux-Komfort

Das erleichtert später:

Docker
CI/CD
Cloud-Deployments

Warum das Terminal bewusst ein eigener Teil ist

Bis zu diesem Punkt haben wir Ubuntu unter WSL2 technisch korrekt eingerichtet:

saubere Benutzer- und Rechteverwaltung
performantes Dateisystem
stabile Netzwerk- und Ressourcen-Konfiguration

Was wir bewusst noch nicht behandelt haben, ist das Terminal selbst.

Der Grund ist einfach:

Das Terminal ist kein Detail, sondern das zentrale Werkzeug im Entwickleralltag.

Eine gute Terminal-Konfiguration beeinflusst:

Produktivität
Fehleranfälligkeit
Lesbarkeit von Ausgaben
tägliche Arbeitsqualität

Deshalb bekommt das Terminal einen eigenen, fokussierten Artikel.

Ausblick auf Teil 3 der Serie

Teil 3: Terminal konfigurieren unter WSL2
(Windows Terminal, Bash, Oh My Posh)

Dort behandeln wir:

Windows Terminal richtig konfigurieren
Schriftarten und Unicode korrekt einrichten
Bash sinnvoll erweitern
Oh My Posh verständlich einsetzen (nicht nur kopieren)
ein aufgeräumtes, funktionales Entwickler-Prompt erstellen

Damit wird aus einer funktionierenden Umgebung eine wirklich angenehme Arbeitsumgebung.

BLOG & INSIGHTS

Ubuntu auf WSL2 konfigurieren