docs: README — Windows-Arbeitsrechner (native .exe + Claude Desktop) ergaenzt
CI / test (push) Successful in 11m41s
CI / test (push) Successful in 11m41s
This commit is contained in:
@@ -7,7 +7,7 @@ Zwei Frontends, eine gemeinsame Tool-Logik:
|
|||||||
|
|
||||||
| Modus | Binary | Einsatz |
|
| Modus | Binary | Einsatz |
|
||||||
|---|---|---|
|
|---|---|---|
|
||||||
| **stdio** | `dtrack-stdio` | Lokal: von Claude Desktop via `docker run -i` gestartet |
|
| **stdio** | `dtrack-stdio` | Lokal/Arbeitsrechner: von Claude Desktop gestartet (`docker run -i` oder native `.exe`) |
|
||||||
| **HTTP** | `dtrack-http` | Server: StreamableHTTP `/mcp`, Multi-Client, Bearer-Auth/RBAC, Admin-UI |
|
| **HTTP** | `dtrack-http` | Server: StreamableHTTP `/mcp`, Multi-Client, Bearer-Auth/RBAC, Admin-UI |
|
||||||
|
|
||||||
> **Status: Stage 3** -- HTTP-Frontend, Bearer-Auth, persistente Config,
|
> **Status: Stage 3** -- HTTP-Frontend, Bearer-Auth, persistente Config,
|
||||||
@@ -161,6 +161,65 @@ docker load -i dtrack-stdio-0.1.0-amd64.tar.gz
|
|||||||
> und den vollen Pfad als `command` setzen (z.B. `/usr/local/bin/docker`).
|
> und den vollen Pfad als `command` setzen (z.B. `/usr/local/bin/docker`).
|
||||||
> Das stdio-Release-Image ist amd64 -> laeuft auf Apple Silicon emuliert (ok zum Testen).
|
> Das stdio-Release-Image ist amd64 -> laeuft auf Apple Silicon emuliert (ok zum Testen).
|
||||||
|
|
||||||
|
### Windows (Arbeitsrechner): native `.exe` -- empfohlen hinter Firmen-VPN
|
||||||
|
|
||||||
|
Auf Windows ist die native `.exe` der zuverlaessigste Weg: sie laeuft im
|
||||||
|
Netz-Kontext des Windows-Hosts, also greift die **VPN-Route zur Firmen-DT
|
||||||
|
direkt**. Container (Docker/Podman Desktop) laufen dagegen in einer WSL2-VM --
|
||||||
|
`--network=host` bindet dort an die VM, und die DT ueber die Host-VPN ist von da
|
||||||
|
drin oft nicht erreichbar.
|
||||||
|
|
||||||
|
**1. `.exe` bauen** -- Cross-Compile von CachyOS aus. reqwest nutzt rustls (kein
|
||||||
|
OpenSSL), darum keine nativen TLS-Libs noetig, nur der MinGW-Linker:
|
||||||
|
|
||||||
|
```sh
|
||||||
|
rustup target add x86_64-pc-windows-gnu
|
||||||
|
sudo pacman -S --needed mingw-w64-gcc
|
||||||
|
cargo build --release --target x86_64-pc-windows-gnu --bin dtrack-stdio
|
||||||
|
# -> target/x86_64-pc-windows-gnu/release/dtrack-stdio.exe
|
||||||
|
```
|
||||||
|
|
||||||
|
Findet cargo den Linker nicht, in `.cargo/config.toml`:
|
||||||
|
|
||||||
|
```toml
|
||||||
|
[target.x86_64-pc-windows-gnu]
|
||||||
|
linker = "x86_64-w64-mingw32-gcc"
|
||||||
|
```
|
||||||
|
|
||||||
|
> **Fallback**, falls der rustls-Crypto-Provider beim `windows-gnu`-Cross zickt:
|
||||||
|
> direkt auf dem Windows-Rechner mit rustup/MSVC bauen --
|
||||||
|
> `cargo build --release --bin dtrack-stdio` erzeugt dieselbe `.exe`.
|
||||||
|
|
||||||
|
Die `dtrack-stdio.exe` dann auf den Arbeitsrechner ziehen, z.B. nach
|
||||||
|
`C:\Tools\dtrack-mcp\dtrack-stdio.exe`.
|
||||||
|
|
||||||
|
**2. Claude Desktop einbinden** -- Config-Datei unter Windows:
|
||||||
|
`%APPDATA%\Claude\claude_desktop_config.json`
|
||||||
|
(oder **Settings -> Developer -> Edit Config**):
|
||||||
|
|
||||||
|
```json
|
||||||
|
{
|
||||||
|
"mcpServers": {
|
||||||
|
"dependency-track": {
|
||||||
|
"command": "C:\\Tools\\dtrack-mcp\\dtrack-stdio.exe",
|
||||||
|
"env": {
|
||||||
|
"DTRACK_URL": "https://dtrack.firma.intern",
|
||||||
|
"DTRACK_API_KEY": "odt_...",
|
||||||
|
"DTRACK_INSECURE": "0"
|
||||||
|
}
|
||||||
|
}
|
||||||
|
}
|
||||||
|
}
|
||||||
|
```
|
||||||
|
|
||||||
|
Pfad mit doppelten Backslashes (oder Forward-Slashes). Bei internem CA-Cert
|
||||||
|
`DTRACK_INSECURE` auf `"1"` setzen. Danach Desktop **komplett neu starten**.
|
||||||
|
|
||||||
|
**3. Testen** -- VPN verbinden, im Chat z.B. *"liste die DT-Projekte"* ->
|
||||||
|
`list_projects` muss Treffer liefern. Kommt nichts: `DTRACK_URL`/Key pruefen,
|
||||||
|
bei TLS-Fehler `DTRACK_INSECURE=1`, VPN-Verbindung pruefen. Logs:
|
||||||
|
`%APPDATA%\Claude\logs\mcp*.log`.
|
||||||
|
|
||||||
### HTTP als echter Remote-Connector
|
### HTTP als echter Remote-Connector
|
||||||
|
|
||||||
Der HTTP-Modus ist fuer den Betrieb als **oeffentlich erreichbarer** Remote-MCP
|
Der HTTP-Modus ist fuer den Betrieb als **oeffentlich erreichbarer** Remote-MCP
|
||||||
|
|||||||
Reference in New Issue
Block a user