From 50406e22d1c919dcaacba6f716d006cce8bbe414 Mon Sep 17 00:00:00 2001 From: Mathias Schneider Date: Mon, 28 Sep 2026 17:37:46 +0200 Subject: [PATCH] update --- Linux/SSH Verbindung in Linux.md | 57 +++++- Linux/psql.md | 59 ++++++- .../DBeaver PostgreSQL via SSH-Tunnel.md | 144 +++++++++++++++ git/Git-History-Truncation.md | 164 ++++++++++++++++++ verschiedene/Docker.md | 66 ++++++- 5 files changed, 487 insertions(+), 3 deletions(-) create mode 100644 datenbanken/DBeaver PostgreSQL via SSH-Tunnel.md create mode 100644 git/Git-History-Truncation.md diff --git a/Linux/SSH Verbindung in Linux.md b/Linux/SSH Verbindung in Linux.md index 9734014..7ca9fa0 100644 --- a/Linux/SSH Verbindung in Linux.md +++ b/Linux/SSH Verbindung in Linux.md @@ -98,4 +98,59 @@ ssh benutzername@192.168.178.42 --- -👉 Soll ich dir ein **kurzes Beispiel-Setup mit zwei Testbenutzern** schreiben, das du direkt im Heimnetz nachmachen kannst? \ No newline at end of file +👉 Soll ich dir ein **kurzes Beispiel-Setup mit zwei Testbenutzern** schreiben, das du direkt im Heimnetz nachmachen kannst? + +--- + +## 5. SSH-Tunnel fĂŒr lokale Datenbankzugriffe + +Mit einem lokalen SSH-Tunnel (`-L`) wird ein Port auf dem eigenen Rechner an +einen Zielhost und Zielport weitergeleitet, die aus Sicht des SSH-Servers +erreichbar sind: + +```bash +ssh -L :: @ +``` + +Beispiel fĂŒr PostgreSQL: + +```bash +ssh -L 15432:127.0.0.1:5432 benutzername@vm.example.org +``` + +Danach kann ein lokaler Client ĂŒber `127.0.0.1:15432` auf PostgreSQL zugreifen. +Die Verbindung verlĂ€uft dabei so: + +```text +Datenbank-Client auf dem eigenen Rechner + | + | 127.0.0.1:15432 + v +SSH-Tunnel zur VM + | + | 127.0.0.1:5432 aus Sicht der VM + v +PostgreSQL auf der VM +``` + +`` wird aus Sicht der VM aufgelöst. Wenn PostgreSQL in einem +Docker-Container lĂ€uft, kann das je nach Setup beispielsweise `127.0.0.1`, +ein Docker-Service-Name oder eine Container-IP sein. Eine Container-IP wie +`172.19.0.2` sollte nicht dauerhaft vorausgesetzt werden, weil sie sich nach +dem Neuerstellen des Containers Ă€ndern kann. Siehe auch +[[DBeaver PostgreSQL via SSH-Tunnel]] und [[Docker]]. + +### Adressen nicht verwechseln + +`hostname -I` gibt alle Adressen des Rechners aus. Darunter können sich auch +Docker-Bridge-Adressen befinden. Die Ausgabe zeigt nicht, welche Adresse fĂŒr +einen bestimmten Dienst die richtige ist: + +```text +10.2.0.4 Adresse der VM im Azure-Netzwerk +172.19.0.1 Docker-Bridge-Gateway +172.19.0.2 möglicherweise eine Container-IP +``` + +Die tatsĂ€chlich passende Adresse und der passende Port sollten mit `ss`, +`docker inspect`, `nc` oder `psql` geprĂŒft werden. diff --git a/Linux/psql.md b/Linux/psql.md index 9bc4ae7..806a790 100644 --- a/Linux/psql.md +++ b/Linux/psql.md @@ -27,4 +27,61 @@ docker exec -i psql -U -d -c "SELECT psql -U -d -A -F, --csv -c "SELECT FROM ;" > path/tp/file.csv ``` ErklĂ€rung: ->The `-A` flag (unaligned output), `-F,` (field separator comma), and `--csv` together produce CSV \ No newline at end of file +>The `-A` flag (unaligned output), `-F,` (field separator comma), and `--csv` together produce CSV + +## Verbindung zu einem bestimmten Host und Port + +FĂŒr eine Verbindung zu einem PostgreSQL-Server auf einem bestimmten Host und +Port werden `-h` und `-p` verwendet: + +```bash +psql -h -p -U -d +``` + +Beispiel: + +```bash +psql -h 127.0.0.1 -p 15432 -U -d +``` + +Das ist beispielsweise der lokale Endpunkt eines SSH-Tunnels. Bei einem +Docker-Setup kann der Host dagegen eine Container-IP, ein Docker-Service-Name +oder die Loopback-Adresse der VM sein. Entscheidend ist, von wo aus die +Verbindung hergestellt wird. + +## PostgreSQL-Verbindung diagnostizieren + +Eine schrittweise PrĂŒfung hilft dabei, Netzwerk-, Tunnel- und +Authentifizierungsprobleme voneinander zu unterscheiden: + +```bash +# Ist der TCP-Port erreichbar? +nc -vz + +# Lauscht auf der VM ein Prozess auf dem PostgreSQL-Port? +sudo ss -ltnp | grep 5432 + +# Funktioniert die PostgreSQL-Verbindung mit denselben Parametern? +psql -h -p 5432 -U -d +``` + +Wenn `psql` direkt auf der VM funktioniert, ist damit nur bewiesen, dass die +VM diesen Endpunkt erreichen kann. Es ist noch nicht bewiesen, dass ein +externer Client denselben Weg ĂŒber den SSH-Tunnel verwendet. Zu prĂŒfen sind +deshalb zusĂ€tzlich der lokale Tunnel-Port, der entfernte Zielhost, der +entfernte Zielport und die SSL-Einstellung des Clients. + +FĂŒr eine Docker-Datenbank sind außerdem hilfreich: + +```bash +docker ps +docker inspect +docker logs --tail 100 +``` + +Eine Container-IP kann sich Ă€ndern, wenn der Container neu erstellt wird. FĂŒr +dauerhafte Konfigurationen sind veröffentlichte Host-Ports oder Docker- +Service-Namen meist besser geeignet als eine fest eingetragene Container-IP. + +Siehe auch [[SSH Verbindung in Linux]], [[Docker]] und +[[DBeaver PostgreSQL via SSH-Tunnel]]. diff --git a/datenbanken/DBeaver PostgreSQL via SSH-Tunnel.md b/datenbanken/DBeaver PostgreSQL via SSH-Tunnel.md new file mode 100644 index 0000000..51e3e54 --- /dev/null +++ b/datenbanken/DBeaver PostgreSQL via SSH-Tunnel.md @@ -0,0 +1,144 @@ +# PostgreSQL mit DBeaver ĂŒber einen SSH-Tunnel + +Ein SSH-Tunnel erlaubt den Zugriff auf eine Datenbank, die nur von einer +entfernten VM aus erreichbar ist. Der Tunnel löst dabei nicht automatisch alle +Netzwerkprobleme: Der Zielhost und Zielport werden aus Sicht der VM bewertet. + +## Verbindungsweg + +```text +DBeaver auf dem eigenen Rechner + | + | lokaler Tunnel-Endpunkt + v +SSH-Client ───────────────â–ș SSH-Server auf der VM + | + | Zielhost:Zielport + v + PostgreSQL auf der VM + oder PostgreSQL-Container +``` + +Ein möglicher manueller Tunnel sieht so aus: + +```bash +ssh -L 15432:127.0.0.1:5432 @ +``` + +Danach ist die Datenbank vom eigenen Rechner aus typischerweise ĂŒber +`127.0.0.1:15432` erreichbar. Bei DBeaver hĂ€ngen die genauen Felder von der +verwendeten SSH-Tunnel-Konfiguration ab. Wichtig ist, die lokale +Datenbankadresse nicht mit dem entfernten Ziel der Weiterleitung zu +verwechseln. + +## Docker als Datenbank-Host + +Wenn PostgreSQL in Docker lĂ€uft, gibt es mehrere mögliche Ziele: + +| Situation | Typisches Ziel aus Sicht der VM | +| --- | --- | +| PostgreSQL lĂ€uft direkt auf der VM | `127.0.0.1:5432` | +| PostgreSQL-Port ist veröffentlicht | `127.0.0.1:` | +| Zugriff aus einem anderen Container | Compose-Service-Name, z. B. `postgres:5432` | +| Direkter Zugriff auf einen Container | aktuelle Container-IP, z. B. `172.19.0.2:5432` | + +Eine Container-IP sollte nur zum Testen verwendet werden. Sie kann sich nach +dem Neustart oder Neuerstellen des Containers Ă€ndern. FĂŒr eine dauerhafte +Konfiguration sind ein Compose-Service-Name innerhalb des Docker-Netzwerks +oder ein veröffentlichter Host-Port vorzuziehen. + +## Schrittweise Diagnose + +### 1. Den aktuellen Container und seine Ports prĂŒfen + +Auf der VM: + +```bash +docker ps +docker inspect +sudo ss -ltnp | grep 5432 +``` + +Bei `docker ps` auf die Spalte `PORTS` achten. Eine Ausgabe wie +`127.0.0.1:5432->5432/tcp` bedeutet, dass PostgreSQL auf der VM lokal +veröffentlicht ist. Eine Ausgabe wie `0.0.0.0:15432->5432/tcp` bedeutet, dass +der Host-Port `15432` zum Container-Port `5432` weiterleitet. + +### 2. Den Zielendpunkt von der VM aus testen + +```bash +nc -vz +psql -h -p -U -d +``` + +Diese Tests mĂŒssen mit dem Host und Port durchgefĂŒhrt werden, die der +SSH-Tunnel aus Sicht der VM erreichen soll. Ein funktionierendes `psql` ohne +`-h` kann beispielsweise ĂŒber einen lokalen Unix-Socket verbinden und sagt +nichts ĂŒber die TCP-Verbindung aus. + +### 3. PostgreSQL-Logs beobachten + +```bash +docker logs --tail 100 -f +``` + +Dann in DBeaver den Verbindungstest ausfĂŒhren: + +- **Kein neuer Logeintrag:** DBeaver erreicht PostgreSQL nicht. Tunnel, + Zielhost, Zielport oder lokale/entfernte Portzuordnung prĂŒfen. +- **Eintrag mit Authentifizierungsfehler:** Netzwerkweg funktioniert; Benutzer, + Passwort, Datenbank oder `pg_hba.conf` prĂŒfen. +- **Verbindung wird sofort beendet:** SSL-Modus, PostgreSQL-Treiber und + Tunnelziel vergleichen. + +## Typische Fehler + +### `hostname -I` liefert mehrere Adressen + +`hostname -I` zeigt alle Adressen der VM. Dazu können die Azure-Adresse und +mehrere Docker-Bridge-Adressen gehören. Die Ausgabe ist keine Liste von +gleichwertigen Datenbankadressen: + +```text +10.2.0.4 VM-Adresse im privaten Azure-Netzwerk +172.19.0.1 Docker-Bridge-Gateway +172.19.0.2 möglicherweise PostgreSQL-Container +``` + +Mit `docker network inspect ` lĂ€sst sich prĂŒfen, welchem +Container eine Docker-Adresse aktuell zugeordnet ist. + +### SSH funktioniert, DBeaver meldet `EOF Exception` + +Ein erfolgreicher SSH-Aufbau beweist nur, dass der SSH-Server erreichbar ist. +Der weitergeleitete TCP-Stream kann trotzdem am falschen Ziel oder Port enden. +PrĂŒfen: + +1. Welcher lokale Port wird von DBeaver verwendet? +2. Welcher entfernte Host und Port werden durch den Tunnel angesprochen? +3. Ist der PostgreSQL-Container noch unter derselben IP erreichbar? +4. Lauscht PostgreSQL auf TCP und nicht nur auf einem Unix-Socket? +5. Verwendet DBeaver denselben SSL-Modus wie `psql`? +6. Erscheint der Test in den PostgreSQL-Logs? + +Die Verbindung sollte zunĂ€chst mit einer expliziten TCP-Verbindung geprĂŒft +werden: + +```bash +psql -h 127.0.0.1 -p -U -d +``` + +Dabei muss `` dem tatsĂ€chlich veröffentlichten Port oder dem lokalen +Port des SSH-Tunnels entsprechen. + +## Sicherheits- und Wartungshinweise + +- Keine Passwörter oder produktiven Zugangsdaten in Notizen oder + Verbindungsdefinitionen im Klartext speichern. +- Container-IPs nicht als langfristige Infrastrukturkonfiguration verwenden. +- FĂŒr dauerhafte Zugriffe DNS-Namen, Compose-Service-Namen oder stabile + Host-Port-Zuordnungen bevorzugen. +- FĂŒr einen Diagnosefall die verwendeten Hosts, Ports, SSL-Einstellungen und + den Verbindungsweg dokumentieren, aber sensible Werte anonymisieren. + +Siehe auch [[SSH Verbindung in Linux]], [[psql]] und [[Docker]]. diff --git a/git/Git-History-Truncation.md b/git/Git-History-Truncation.md new file mode 100644 index 0000000..f578a31 --- /dev/null +++ b/git/Git-History-Truncation.md @@ -0,0 +1,164 @@ +# Git-History kuerzen + +Wenn ein Repository zu gross geworden ist und die alte Historie nicht mehr benoetigt wird, kann die Git-History ab einem bestimmten Commit abgeschnitten werden. Dabei wird die Historie **umgeschrieben**: Der Commit-Hash des neuen Anfangs und die Hashes aller folgenden Commits aendern sich. + +> **Achtung:** Das ist eine destruktive Operation fuer die bisherige Historie. Vorher unbedingt ein Backup erstellen und mit allen anderen Personen abstimmen, die mit dem Repository arbeiten. + +## Nicht verwechseln: Shallow Clone + +Ein flacher Clone verbirgt alte Historie nur lokal: + +```bash +git clone --shallow-since="2024-01-01" +``` + +Das Repository selbst wird dadurch nicht gekuerzt. Fuer eine dauerhafte Kuerzung muss die Historie umgeschrieben und anschliessend mit Force-Push auf das Remote uebertragen werden. + +## Vorbereitung: Backup erstellen + +Am sichersten arbeitet man mit einem Mirror-Clone: + +```bash +git clone --mirror repository-backup.git +cd repository-backup.git +``` + +Den urspruenglichen Clone bzw. das Backup erst loeschen, wenn das Ergebnis geprueft wurde. + +## `git-filter-repo` unter Arch Linux installieren + +Das Arch-Paket heisst `git-filter-repo`: + +```bash +sudo pacman -S git-filter-repo +``` + +Pruefen: + +```bash +git filter-repo --version +``` + +Ein systemweites `pip install` funktioniert auf Arch Linux wegen PEP 668 normalerweise nicht. Die Paketinstallation ist vorzuziehen. + +## Einen Commit zum neuen Root machen + +Angenommen, dieser Commit soll der neue Anfang der Historie werden: + +```text +464e39c1234567890abcdef1234567890abcdef +``` + +Dann werden seine Eltern entfernt: + +```bash +git filter-repo --force \ + --commit-callback 'if commit.original_id == b"464e39c1234567890abcdef1234567890abcdef": commit.parents = []' +``` + +`commit.original_id` enthaelt die vollstaendige 40-stellige Commit-ID. Eine kurze ID wie `464e39c` funktioniert mit `==` nicht. Alternativ kann ein eindeutiger Prefix so verwendet werden: + +```bash +git filter-repo --force \ + --commit-callback 'if commit.original_id.startswith(b"464e39c"): commit.parents = []' +``` + +Die vollstaendige ID kann vorher ermittelt werden: + +```bash +git rev-parse 464e39c +``` + +Aus: + +```text +A -- B -- C -- D -- E +``` + +wird dadurch sinngemaess: + +```text +C' -- D' -- E' +``` + +Der Commit `C` bleibt inhaltlich und mit seinen Metadaten erhalten, bekommt aber wegen der entfernten Eltern einen neuen Hash. Auch `D` und `E` erhalten neue Hashes. + +## Den Cutoff-Commit ebenfalls verwerfen + +Wenn der Cutoff-Commit selbst nicht erhalten bleiben soll, kann ein neuer Root-Commit mit seinem Dateistand erstellt und die spaetere Historie darauf rebased werden: + +```bash +git checkout --orphan temp +git commit -m "Start truncated history" +git rebase --onto temp main +git branch -D temp +``` + +Dabei ist `` der **letzte Commit, der verworfen werden soll**. Der neue Root-Commit enthaelt den Dateistand dieses Commits, ist aber ein neuer Commit. Bei Merge-Commits oder komplexen Branches kann die Rebase-Variante Konflikte verursachen. In solchen Faellen ist `git-filter-repo` in der Regel die bessere Wahl. + +## Ergebnis pruefen + +Vor dem Push die neue Historie kontrollieren: + +```bash +git log --all --graph --oneline --decorate +git status +``` + +Der neue Root-Commit darf keine `parent`-Zeile haben: + +```bash +git show --no-patch --pretty=raw +``` + +Auch der aktuelle Dateistand sollte unveraendert sein. Einen Vergleich kann man beispielsweise vor dem Umschreiben speichern oder mit dem Backup pruefen. + +## Remote wieder hinzufuegen + +`git-filter-repo` entfernt das Remote oft absichtlich als Sicherheitsmassnahme. Deshalb zuerst pruefen: + +```bash +git remote -v +``` + +Falls kein `origin` vorhanden ist: + +```bash +git remote add origin +git ls-remote origin +``` + +`origin/main` ist eine Branch-Referenz und kein Remote-Name. Der Push verwendet daher `origin main`, nicht `origin/main`. + +## Umschriebene Historie pushen + +Nur den Hauptbranch pushen: + +```bash +git push --force origin main +``` + +Alle lokalen Branches und Tags pushen: + +```bash +git push --force --all origin +git push --force --tags origin +``` + +Das Remote kann den Push wegen Branch-Schutzregeln ablehnen. In diesem Fall muss der Schutz voruebergehend angepasst werden. + +## Nacharbeiten und wichtige Folgen + +- Alle Commit-Links, Pull Requests und Tags koennen durch die neuen Hashes ungueltig werden. +- Andere Clone enthalten weiterhin die alte Historie und muessen neu geklont oder manuell angepasst werden. +- Andere Branches oder Tags koennen die alte Historie weiterhin erreichbar machen. +- Ein Force-Push kann nicht ohne Weiteres rueckgaengig gemacht werden; das Backup aufbewahren. + +Alte, nicht mehr erreichbare Objekte koennen nach der Pruefung lokal bereinigt werden: + +```bash +git reflog expire --expire=now --all +git gc --prune=now +``` + +`git gc --aggressive` ist normalerweise nicht notwendig und kann bei grossen Repositories lange dauern. Auf einem Hosting-Dienst werden nicht mehr erreichbare Objekte eventuell erst spaeter durch dessen eigene Garbage Collection geloescht. diff --git a/verschiedene/Docker.md b/verschiedene/Docker.md index 6966733..4b01483 100644 --- a/verschiedene/Docker.md +++ b/verschiedene/Docker.md @@ -777,4 +777,68 @@ docker-compose up --build - ✅ Automatische File-Verarbeitung - ✅ Persistente Datenspeicherung -**Das ist die Macht von Docker! 🐳** \ No newline at end of file +**Das ist die Macht von Docker! 🐳** + +--- + +## Docker-Netzwerk bei Datenbankproblemen untersuchen + +Bei einer Datenbank in einem Docker-Container muss zwischen verschiedenen +Netzwerkperspektiven unterschieden werden: + +- **Innerhalb eines Docker-Netzwerks:** Container erreichen sich normalerweise + ĂŒber den Compose-Service-Namen, zum Beispiel `postgres:5432`. +- **Auf dem Docker-Host:** Ein veröffentlichter Port wie `5432:5432` ist ĂŒber + den Host erreichbar, hĂ€ufig ĂŒber `127.0.0.1:5432`. +- **Von außerhalb des Hosts:** Ein SSH-Tunnel kann einen lokalen Port auf den + Host-Port oder auf einen aus Sicht des Hosts erreichbaren Container-Endpunkt + weiterleiten. + +### Docker-Bridge-Adressen + +Adressen wie `172.19.0.1` und `172.19.0.2` gehören hĂ€ufig zu einem Docker- +Bridge-Netzwerk: + +- `172.19.0.1` ist typischerweise das Gateway des Netzwerks auf dem Host. +- `172.19.0.2` kann die aktuelle IP eines Containers sein. + +Container-IPs sind nicht als dauerhafte Konfiguration geeignet. Nach einem +`docker compose up`, einer Neuerstellung oder einem Deployment kann derselbe +Container eine andere IP erhalten. Innerhalb von Compose-Netzwerken sollte der +Service-Name verwendet werden. Von außerhalb sollte nach Möglichkeit ein +veröffentlichter Host-Port verwendet werden. + +### NĂŒtzliche Diagnosebefehle + +```bash +# Laufende Container und veröffentlichte Ports anzeigen +docker ps + +# Netzwerkdetails und aktuelle Container-IP anzeigen +docker inspect + +# Vorhandene Docker-Netzwerke anzeigen +docker network ls + +# Teilnehmer und IPs eines Netzwerks anzeigen +docker network inspect + +# PrĂŒfen, ob der Host lokal auf dem PostgreSQL-Port lauscht +sudo ss -ltnp | grep 5432 + +# TCP-Erreichbarkeit eines bestimmten Ziels testen +nc -vz 5432 + +# PostgreSQL-Logs wĂ€hrend eines Verbindungsversuchs beobachten +docker logs --tail 100 -f +``` + +Wenn ein Client eine Verbindung mit `EOF` beendet, sollte zuerst geprĂŒft +werden, ob ĂŒberhaupt ein neuer Eintrag in den PostgreSQL-Logs erscheint. Ohne +Logeintrag liegt das Problem wahrscheinlich vor PostgreSQL, beispielsweise am +Tunnel, am Zielhost oder am Zielport. Ein Logeintrag zeigt, dass PostgreSQL +erreicht wurde; dann kommen unter anderem SSL- oder +Authentifizierungsparameter als Ursache infrage. + +Siehe auch [[psql]], [[SSH Verbindung in Linux]] und +[[DBeaver PostgreSQL via SSH-Tunnel]].