diff --git a/README.md b/README.md index 910d3f3..07c4785 100755 --- a/README.md +++ b/README.md @@ -1,3 +1,7 @@ +> **Dieses Repo ist Historie.** Groundcontrol (`mscadm/groundcontrol`) hat den +> Code seit 2026-07-28 uebernommen; das ITSM lebt dort als Modul *Service Desk* +> weiter (siehe ADR-010). Neue Arbeit bitte im Groundcontrol-Repo. + # ITSM ITSM-Plattform (Service-Katalog, Tickets, Wissensdatenbank, CMDB) -- AES ist ein diff --git a/docs/adr/ADR-009-konzernplattform-modul-monolith.md b/docs/adr/ADR-009-konzernplattform-modul-monolith.md index 983cb38..2d870ed 100755 --- a/docs/adr/ADR-009-konzernplattform-modul-monolith.md +++ b/docs/adr/ADR-009-konzernplattform-modul-monolith.md @@ -1,6 +1,6 @@ # ADR-009: Konzernplattform als Modul-Monolith -**Datum:** 2026-07-15 · **Status:** Akzeptiert · **Vorgabe:** "Wir machen aus dem ITSM eine Konzernplattform inkl. HR, CRM, usw." +**Datum:** 2026-07-15 · **Status:** ERSETZT durch ADR-010 (2026-07-28) — Modul-Monolith bleibt gueltig, aber die Plattform (Groundcontrol) ist der Kern, nicht das ITSM · **Vorgabe:** "Wir machen aus dem ITSM eine Konzernplattform inkl. HR, CRM, usw." ## Kontext Das ITSM soll zur Unternehmensplattform mit Fachmodulen (HR, CRM, weitere) diff --git a/docs/adr/ADR-010-groundcontrol-plattformschnitt.md b/docs/adr/ADR-010-groundcontrol-plattformschnitt.md new file mode 100755 index 0000000..9b651fd --- /dev/null +++ b/docs/adr/ADR-010-groundcontrol-plattformschnitt.md @@ -0,0 +1,41 @@ +# ADR-010: Groundcontrol — Plattform als Kern, ITSM als Modul + +**Datum:** 2026-07-28 · **Status:** Akzeptiert (ersetzt ADR-009) +**Vorgabe:** "Wir brauchen einen besseren Projektnamen für die Plattform und ITSM darf nicht der Kern sein, eher ein Bestandteil (von Anfang an)." + +## Kontext +ADR-009 hatte HR/CRM als Module in die bestehende ITSM-Anwendung gehängt: das +ITSM blieb Namens- und Codekern (Repo `mscadm/ITSM`, Binary `itsm`, Routen +ohne Modul-Präfix, Rollen in `itil.rs`). Mit weiteren Domänen — insbesondere +der Systemverwaltung (Groundwork-OS, Linux, Windows) — wird diese Schieflage +strukturell falsch: Fleet ist kein „ITSM-Feature". + +## Entscheidung +**Name: GROUNDCONTROL** (Fortsetzung der Hausmarke Leerlauf.works / +Groundwork-OS / PureIdle: Fundament legen → von hier steuern). + +Neues Repo `mscadm/groundcontrol`; `mscadm/ITSM` wird nach der Migration +archiviert. Codeschnitt trennt Kern und Module strikt: + + src/platform/ Mandanten, Auth/Sessions, RBAC, Audit, Retention, + UI-Shell, Konfiguration, DB-Pool (modulagnostisch) + src/modules/servicedesk/ ITIL v3/v4 (vormals „das ITSM") + src/modules/people/ HR + src/modules/sales/ CRM + src/modules/fleet/ Systemverwaltung (siehe ADR-011) + src/modules/aes/ AES-Suite-Erweiterung + +Module sind gleichrangig: eigener Routen-Präfix, eigene Tabellen-Präfixe +(`sd_`, `hr_`, `crm_`, `fleet_`), eigene Rolle(n), eigene Nav-Gruppe, eigene +Doku. Der Kern kennt kein Modul namentlich außer in der Registrierung. + +Bestandsdaten bleiben: bestehende Tabellen (tickets, kb_articles, …) werden +NICHT umbenannt (Datenrisiko ohne Nutzen); der Präfix gilt für neue Tabellen. + +## Konsequenzen ++ Fleet und künftige Domänen sind erstklassig statt „angebaut". ++ Kern bleibt schlank und wiederverwendbar; Module sind einzeln testbar. ++ Marke passt zur Produktfamilie; „ITSM" wird zum Modulnamen *Service Desk*. +− Einmaliger Migrationsaufwand (Repo, Pfade, URLs, Doku, Deployment). +− Ein-Rollen-Modell wird durch Fleet endgültig zu eng → Modul-Grants sind + als groundcontrol phase-003 eingeplant. diff --git a/docs/adr/ADR-011-fleet-agent-und-ssh.md b/docs/adr/ADR-011-fleet-agent-und-ssh.md new file mode 100755 index 0000000..fc9f083 --- /dev/null +++ b/docs/adr/ADR-011-fleet-agent-und-ssh.md @@ -0,0 +1,46 @@ +# ADR-011: Fleet-Anbindung — Pull-Agent mit SSH-Fallback + +**Datum:** 2026-07-28 · **Status:** Akzeptiert +**Vorgabe:** "Systemverwaltung aller Groundwork-OS Systeme, aber auch Windows und Linux System via Agent" (Anbindung: Agent + SSH-Fallback) + +## Kontext +Zu verwaltende Systeme: Groundwork-OS-Instanzen, Linux-Server, Windows- +Clients/Server. Sie stehen teils hinter NAT/Firewalls, teils ohne Möglichkeit +zur Softwareinstallation. Reine Push-Steuerung (Server → Host) verlangt +erreichbare Ports und hinterlegte Zugangsdaten für jedes System. + +## Entscheidung +**Primär: Pull-Agent.** Der Agent wird mit einem mandantengebundenen +Enrollment-Token einmalig registriert und erhält ein eigenes Host-Token +(in der DB nur als SHA-256-Hash — gleiches Prinzip wie Sessions, ADR-002). +Danach ausschließlich ausgehende HTTPS-Verbindungen: + + POST /api/fleet/enroll einmalig, mit Enrollment-Token + POST /api/fleet/heartbeat zyklisch: Status + Inventar, Antwort = offene Jobs + POST /api/fleet/jobs/:id/result Ergebnis (exit code, stdout/stderr gekürzt) + +Kein offener Port auf dem verwalteten System, NAT-tauglich, Token pro Host +einzeln widerrufbar (Host sperren ⇒ Agent verliert sofort Zugriff). + +**Sekundär: SSH/WinRM-Fallback** für agentenlose Hosts — als Host-Typ +`ssh` gepflegt, ausgeführt vom Server aus. Zugangsdaten werden **nicht** in +Groundcontrol gespeichert (kein Passwort-Tresor im Produkt); genutzt wird der +SSH-Key des Servers. Reichweite bewusst kleiner als beim Agenten. + +**Job-Sicherheit:** Jobs sind Kommandos auf fremden Systemen — daher +- nur Rolle `fleet_operator`/`admin` darf Jobs anlegen (Rolle `fleet_viewer` + sieht nur Inventar), +- jeder Job wird im Audit-Log mit Kommando, Ziel und Auslöser protokolliert, +- Jobs sind an einen Host gebunden und laufen genau einmal (Status + Offen → Zugestellt → Erledigt/Fehler), +- Agent führt Jobs unter seiner eigenen Kennung aus; Rechteausweitung ist + Sache des Systems, nicht der Plattform. + +## Konsequenzen ++ Funktioniert über NAT/Firewall hinweg, ohne eingehende Ports. ++ Host-Token einzeln widerrufbar; Kompromittierung bleibt lokal begrenzt. ++ Ein Agent-Binary für Linux und Windows (Rust, statisch gelinkt). +− Latenz durch Polling (Heartbeat-Intervall statt Echtzeit) — für + Verwaltungsaufgaben akzeptabel; WebSocket wäre eine spätere Option. +− SSH-Fallback ist bewusst eingeschränkt (Server-Key statt Credential-Store); + ein Passwort-Tresor wäre ein eigener ADR mit deutlich höherem Schutzbedarf. diff --git a/docs/adr/README.md b/docs/adr/README.md index ee06838..b539cce 100755 --- a/docs/adr/README.md +++ b/docs/adr/README.md @@ -14,3 +14,6 @@ neue, ersetzende ADRs (nie stillschweigend editieren). | 006 | Multi-Stage-Docker-Build statt Clone-on-Start | 2026-07-15 | | 007 | CSP ohne Inline-JavaScript | 2026-07-15 | | 008 | SSRF-Policy für Service-Endpoints | 2026-07-15 | +| 009 | Konzernplattform als Modul-Monolith (ersetzt durch 010) | 2026-07-15 | +| 010 | Groundcontrol — Plattform als Kern, ITSM als Modul | 2026-07-28 | +| 011 | Fleet-Anbindung — Pull-Agent mit SSH-Fallback | 2026-07-28 |