LXC – be smarter

Ich entwickle auf drei verschiedenen Linux-Rechnern: einem Desktop zuhause, einem zweiten Arbeitsplatz und einem Notebook unterwegs. Alle drei laufen unter Linux Mint. Das Problem: Ich möchte überall am gleichen Projekt weiterarbeiten können — ohne Setup-Overhead, ohne offene Dateien nachzuziehen, ohne mich zu fragen, wo ich gestern aufgehört habe.

Die Lösung ist ein einzelner Befehl. Ich tippe partyplaner ins Terminal — und VSCodium öffnet sich, die richtige tmux-Session auf dem Entwicklungsserver ist aktiv, alle Dateien sind da. Egal an welchem der drei Rechner ich sitze.

Das Fundament: Proxmox und ein LXC-Container

Der Kern des Setups ist ein Proxmox-Server im lokalen Netz. Proxmox ist ein Hypervisor — ein System, das virtuelle Maschinen und Container verwaltet. Ich nutze keinen Cloud-Anbieter, kein gemietetes VPS, kein Kubernetes. Alles läuft auf eigener Hardware, unter meiner Kontrolle.

Auf diesem Proxmox-Host läuft ein einziger LXC-Container (Linux Containers) mit Debian — das ist dockerdev. Darin laufen alle meine Entwicklungsprojekte, jedes in seinem eigenen Unterordner unter /root/projects/. Der Container läuft rund um die Uhr, braucht wenig Ressourcen, ist schnell gestartet und einfach zu sichern.

Der entscheidende Vorteil gegenüber Cloud-Entwicklung: keine Latenz, keine Abhängigkeit von Drittanbietern, volle Datenkontrolle. Die Dateien verlassen das lokale Netz nicht.

Architektur-Diagramm: Linux-Clients verbinden sich per SSH auf LXC-Container — Setup-Übersicht: Clients → SSH → LXC-Container · *Klicken zum Vergrößern*

SSH-Zugang einrichten: Public Key Auth

Damit der Alias-Trick reibungslos funktioniert, muss jeder Client-Rechner seinen SSH-Public-Key auf dockerdev hinterlegt haben.

Schritt 1: Key generieren

ssh-keygen -t ed25519 -C "mein-rechner"
# Erzeugt ~/.ssh/id_ed25519 (privat) und ~/.ssh/id_ed25519.pub (öffentlich)

Schritt 2: Public Key eintragen

ssh-copy-id root@dockerdev
# Oder manuell: Inhalt von ~/.ssh/id_ed25519.pub
# in /root/.ssh/authorized_keys auf dockerdev einfügen

Schritt 3: Berechtigungen setzen

chmod 700 /root/.ssh
chmod 600 /root/.ssh/authorized_keys

Diese Berechtigungen sind nicht optional — SSH verweigert den Key-Zugang, wenn authorized_keys zu offen ist.

Schritt 4: Root-Login erlauben

In /etc/ssh/sshd_config auf dockerdev:

PermitRootLogin yes
PubkeyAuthentication yes

Danach: systemctl restart sshd

Der Alias-Trick: _proj und VSCodium SSH Remote

VSCodium (die Open-Source-Variante von VS Code, ohne Microsoft-Telemetrie) hat eine SSH Remote Extension. Mit ihr öffnet sich die IDE direkt im Dateisystem des Remote-Hosts — als wäre der Entwicklungsserver der lokale Rechner.

function _proj() {
    local name="$1" host="$2" path="$3"
    ssh -o ConnectTimeout=5 root@"$host" \
        "tmux new-session -A -d -s '$name' -c '$path' 2>/dev/null; true"
    codium --folder-uri "vscode-remote://ssh-remote+root@${host}${path}"
}

function partyplaner() { _proj partyplaner dockerdev /root/projects/partyplaner; }
function wsai()        { _proj wsai        dockerdev /root/projects/wsai; }
function hermesagent() { _proj hermesagent dockerdev /root/projects/hermesagent; }

tmux: der stille Held

tmux ist ein Terminal-Multiplexer: Er erzeugt Sessions, die auf dem Server weiterläufen, auch wenn der Client getrennt wird. Das -A-Flag (attach if exists) sorgt dafür, dass man am zweiten Arbeitsplatz in exakt der gleichen Session weitermacht, die man am Desktop verlassen hat.

tmux new-session -A -d -s 'partyplaner' -c '/root/projects/partyplaner'

tmux Session-Konzept: Persistente Session, mehrere Clients — tmux hält die Session — von jedem Client einsteigen · *Klicken zum Vergrößern*

Dotfiles und Gitea: alle Rechner synchron

Die _proj-Funktion und alle Projekt-Aliases leben in ~/dotfiles/bashrc_shared — einem Bash-Skript, das per Symlink als ~/.bashrc eingebunden wird. Das Dotfiles-Repo liegt auf einem eigenen Gitea-Server im lokalen Netz.

Wenn ich auf einem Rechner einen neuen Alias anlege, sind alle anderen mit zwei Befehlen auf dem Stand:

git -C ~/dotfiles pull && source ~/.bashrc

Gitea ist der einzige Ort, an dem die Aliases gepflegt werden — kein rsync, kein manuelles Verteilen.

Neues Projekt anlegen: Claude übernimmt

Wenn ich ein neues Projekt anlegen will, sage ich Claude einfach: „Lege ein neues Projekt mit dem Namen X an.“

Gitea-Repo erstellen (via Gitea API)
Git auf dockerdev initialisieren (per SSH, mit Initial Commit)
VSCodium tmux-Integration anlegen (.vscode/settings.json)
Alias in bashrc_shared eintragen
Dotfiles committen und pushen — alle anderen Rechner haben den Alias beim nächsten Pull

function neuprojekt() { _proj neuprojekt dockerdev /root/projects/neuprojekt; }

tmux Schnellreferenz

Fazit: Einmal denken, überall arbeiten

Ein LXC-Container der immer läuft. Ein tmux der die Session hält. Ein Alias der alles zusammenbringt. Gitea als Synchronisationsschicht. Claude als Assistent der neue Projekte auf Zuruf anlegt. Kein Cloud-Anbieter, keine monatliche Rechnung, keine Daten bei Dritten.

Einmal aufgesetzt, ist es unsichtbar. Und das ist genau der Punkt.

Dieser Beitrag ist Teil der Reihe „KI in der Praxis“ — echte Setups, keine Theorie.

Schlagwort: LXC

Ein Befehl, eine IDE, eine Session: VSCodium + tmux + Proxmox auf Linux