docs: Hinweis auf Nachfolger mscadm/groundcontrol (ITSM lebt dort als Modul Service Desk weiter, ADR-010)
This commit is contained in:
parent
970cd24972
commit
90438a24af
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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)
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
@ -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.
|
||||
|
|
@ -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 |
|
||||
|
|
|
|||
Loading…
Reference in New Issue