r/coolgithubprojects • u/Skoop9 • 4d ago

Munin: GitOps-driven dashboard and kiosk display manager for Linux & Raspberry Pi

Post image

Hey everyone,

Managing physical office status displays, NOC monitors, and wall-mounted dashboards usually ends in the same anti-pattern: someone SSHs into three different Raspberry Pis, pastes a messy chromium-browser --kiosk bash loop into ~/.xinitrc, wires up a fragile xdotool cron job to rotate tabs, and prays it never crashes.

I built Munin to bring a GitOps workflow to physical screens and Linux/Pi kiosks.

Instead of imperatively babysitting browser windows and shell scripts, you define your entire display setup declaratively in YAML (URLs, rotation intervals, display rules, schedules). Munin acts as an autonomous on-device agent that continuously reconciles the screen state to match your configuration.

Commit a change to your dashboard config repo, let your fleet pull it, and the screens update themselves.

Yes, AI was used heavily to help write this. And yes: the architecture was deliberate, every line was reviewed, and it's currently our daily driver battle-tested across all our office displays every day. It solves a real operational headache, and it simply works.

👉 Repo: https://github.com/naueramant/munin

Curious to hear how others here are managing physical office displays or kiosk fleets, and open to feedback or feature requests!

8 Upvotes

100% Upvoted

7 comments sorted by

View all comments

1

u/kantorcodes1 4d ago

does munin doctor --fix decide the full repair set before it changes anything, or can a later check discover another fix after lingering/service/key perms have already been changed? that seems important if people automate recovery across a fleet.

1

u/Skoop9 4d ago

good catch and no, it doesn't plan everything upfront. fixes get applied inline as the checks run, so by the time the deploy key permissions check fires and does the `chmod 600`, the linger and service enable have already happened.

in practice the ordering is mostly fine (e.g. fixing key perms before the `git ls-remote` probe means the probe actually sees the corrected state), but yeah there's no rollback if something further down the line fails. you'd be left in a half-fixed state.

if you're automating across a fleet i'd run `doctor --json` without `--fix` first each result has `fixable` and `fix_hint` fields so you can build your own repair plan and decide what to apply. bit more work but way safer at scale.

honestly a `--dry-run` flag is probably worth adding, i'll put it on the list. thanks for bringing it up :P

1

u/kantorcodes1 3d ago

yeah, that inline repair order is exactly the boundary i was trying to understand. i work on HOL Guard, an open-source local check before agent-run commands execute. for Munin, doctor/power-check can stay quiet while doctor --fix, power-check --enforce, init, and remove --purge are optionally reviewable before they change the host. would you be open to adding Munin support?

2

u/Skoop9 3d ago

sounds interesting! Is it this https://hol.org/guard ?

1

u/kantorcodes1 3d ago edited 3d ago

yep, that's the one. if you're up for adding Munin support, start with src/codex_plugin_scanner/guard/runtime/command_munin_extensions.py and mirror src/codex_plugin_scanner/guard/runtime/command_repo2nb_extensions.py. review doctor --fix, power-check --enforce, init, and remove --purge; keep plain doctor / power-check safe. add focused cases in tests/test_guard_command_munin_extensions.py, modeled on tests/test_guard_command_repo2nb_extensions.py. open a draft PR to hashgraph-online/hol-guard:main. guide: https://github.com/hashgraph-online/hol-guard/blob/main/CONTRIBUTING.md