bashclub/bashclub-os
Watch
1
0
Fork
You've already forked bashclub-os
 0
Code Issues 12 Pull requests Projects Releases Packages Wiki Activity Actions

Idee: Metapakete für Werkzeug-Sets (Monitoring, miyagi-Backup) mit zentraler Konfiguration #16

New issue
Open
opened 2026-10-26 11:45:09 +01:00 by thorsten.spille · 1 comment
thorsten.spille commented 2026-10-26 11:45:09 +01:00
Owner
Copy link

Idee Thorsten (2026-10-26), ausdrücklich nur festgehalten – mit der Konfiguration vermutlich nicht ganz umsetzbar, kann eine Idee bleiben.

Metapakete für Werkzeug-Sets, auf bashclub OS mit einem Paket vorinstalliert:

  • Monitoring/Verwaltung: Wazuh-Agent, Checkmk-Agent (bzw. cmk-push-agent), PatchMon, Tactical-RMM-Agent
  • „miyagi workflow“ (Backup/Replikation): zsync, PBS (Proxmox Backup Client/Server), checkzfs, Salmora Backup oder UrBackup

Konfiguration über eine Datei auf einem Webserver (z. B. Server-URL, Token, Mandant je Werkzeug), abgerufen bei Installation und danach.

Offene Fragen, warum es schwierig ist:

  • Agents brauchen Geheimnisse (Registrierungs-Token, Schlüssel) → Abruf nur authentifiziert, nie im Klartext auf einem öffentlichen Webserver; Bindung an den Rechner (z. B. per Tang/Clevis oder einmaligem Token aus der Antwortdatei)
  • Einige Werkzeuge haben keine Debian-Pakete bzw. eigene Installer (Tactical RMM, PatchMon, Wazuh mit eigenem Repo) → fremde Paketquellen und deren Schlüssel einbinden
  • Lizenz/Weitergabe (z. B. Tactical-RMM-Agent unter eigener Lizenz)
  • Wer pflegt die Versionen, Test in der CI je Werkzeug
  • Abgrenzung zu Freehold (dort per Antwortdatei und freehold apply)

Mögliche Form, falls es weiterverfolgt wird: Metapakete bashclub-tools-monitoring und bashclub-tools-miyagi mit Recommends, plus ein Dienst bashclub-config-pull (Timer), der eine signierte YAML-Datei holt und je Werkzeug ein kleines Konfigurationsskript ausführt.

Idee Thorsten (2026-10-26), ausdrücklich nur festgehalten – mit der Konfiguration vermutlich nicht ganz umsetzbar, kann eine Idee bleiben. **Metapakete für Werkzeug-Sets**, auf bashclub OS mit einem Paket vorinstalliert: - **Monitoring/Verwaltung:** Wazuh-Agent, Checkmk-Agent (bzw. cmk-push-agent), PatchMon, Tactical-RMM-Agent - **„miyagi workflow“ (Backup/Replikation):** zsync, PBS (Proxmox Backup Client/Server), checkzfs, Salmora Backup oder UrBackup **Konfiguration über eine Datei auf einem Webserver** (z. B. Server-URL, Token, Mandant je Werkzeug), abgerufen bei Installation und danach. Offene Fragen, warum es schwierig ist: - Agents brauchen Geheimnisse (Registrierungs-Token, Schlüssel) → Abruf nur authentifiziert, nie im Klartext auf einem öffentlichen Webserver; Bindung an den Rechner (z. B. per Tang/Clevis oder einmaligem Token aus der Antwortdatei) - Einige Werkzeuge haben keine Debian-Pakete bzw. eigene Installer (Tactical RMM, PatchMon, Wazuh mit eigenem Repo) → fremde Paketquellen und deren Schlüssel einbinden - Lizenz/Weitergabe (z. B. Tactical-RMM-Agent unter eigener Lizenz) - Wer pflegt die Versionen, Test in der CI je Werkzeug - Abgrenzung zu Freehold (dort per Antwortdatei und `freehold apply`) Mögliche Form, falls es weiterverfolgt wird: Metapakete `bashclub-tools-monitoring` und `bashclub-tools-miyagi` mit Recommends, plus ein Dienst `bashclub-config-pull` (Timer), der eine signierte YAML-Datei holt und je Werkzeug ein kleines Konfigurationsskript ausführt.
PadawanDeluxe commented 2026-10-26 23:28:00 +01:00
Copy link

Metapakete für Sets von Paketen ist ein toller Weg, um grundsätzlich ein Bündel auf ein System zu bringen. Du bringst hier zwei Dinge zusammen: Installation+Provision des Werkzeug-(Sets).

mein aktuell bevorzugter Ansatz:

  • bring nur TacticalRMM aus => danach greifen die Scripte/Jobs die du definiert hast für das System bzw. Site. Das ist das Szenario für "nur bei Registrierung ausführen" Tasks
  • Agents werden mittels Script nachinstalliert => Geheimnisse für weitere Pakete bleiben in der Verwaltung (bspw. Tactical)
  • Repos werden global hinzugefügt und mittels Parameter individualisiert (bspw. PMG/PVE Subscription-Key)
  • einfacher One-Liner per Copy&paste

Alternative 2:

  • Individuelle Installations-ISO für Kunde A,B,C. Leicht anpassbar mittels CI auf dem jeweiligen PXE/Build Server
  • unterschiedliche Images für das gezielte Szenario (Server/Workstation)
  • Build gem. Zeitplan(vorgabe)

Alternative 3:

  • Ansible als Provisionierungswerkzeug nutzen dann wäre hier auch Unveränderlichkeit der Konfiguration möglich oder über weitere Tools sogar eine Revision (Git-Repo?)

Bedingt:

  • Pull: Ansible Installation auf dem Ziel
  • Push: Ansible ssh-key auf dem Ziel

Ich habe das im Push Verfahren im Einsatz. Das ist Klasse für Tasks und Config Änderungen wenn man denn wirklich nur eine Beschreibung braucht. Allerdings bin ich hiervon rüber zu TacticalRMM gegangen, da es "Anwenderfreundlicher" ;-) für manche Kollegen ist. Es gibt einige UIs. Pull-Verfahren habe ich mehrere Ansätze gesehen - empfand ich allerdings als sehr aufwendig.

Metapakete für Sets von Paketen ist ein toller Weg, um grundsätzlich ein Bündel auf ein System zu bringen. Du bringst hier zwei Dinge zusammen: Installation+Provision des Werkzeug-(Sets). mein aktuell bevorzugter Ansatz: - bring nur TacticalRMM aus => danach greifen die Scripte/Jobs die du definiert hast für das System bzw. Site. Das ist das Szenario für "nur bei Registrierung ausführen" Tasks - Agents werden mittels Script nachinstalliert => Geheimnisse für weitere Pakete bleiben in der Verwaltung (bspw. Tactical) - Repos werden global hinzugefügt und mittels Parameter individualisiert (bspw. PMG/PVE Subscription-Key) - einfacher One-Liner per Copy&paste Alternative 2: - Individuelle Installations-ISO für Kunde A,B,C. Leicht anpassbar mittels CI auf dem jeweiligen PXE/Build Server - unterschiedliche Images für das gezielte Szenario (Server/Workstation) - Build gem. Zeitplan(vorgabe) Alternative 3: - Ansible als Provisionierungswerkzeug nutzen dann wäre hier auch Unveränderlichkeit der Konfiguration möglich oder über weitere Tools sogar eine Revision (Git-Repo?) Bedingt: - Pull: Ansible Installation auf dem Ziel - Push: Ansible ssh-key auf dem Ziel Ich habe das im Push Verfahren im Einsatz. Das ist Klasse für Tasks und Config Änderungen wenn man denn wirklich nur eine Beschreibung braucht. Allerdings bin ich hiervon rüber zu TacticalRMM gegangen, da es "Anwenderfreundlicher" ;-) für manche Kollegen ist. Es gibt einige UIs. Pull-Verfahren habe ich mehrere Ansätze gesehen - empfand ich allerdings als sehr aufwendig.
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
main
debconf-vorbelegung
logo-oben-links
ruhiger-start
ableitung-haken
No results found.
Labels
Clear labels
No items
No labels
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
2 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
bashclub/bashclub-os#16
No description provided.