To all Qubes OS enthusiasts!
Continuing from our last meetup this Friday, we're diving into the exciting topics of Salt and Android in Qubes OS! 
(see our homepage 
)
Before we get started, we want to hear from YOU – whether you're based in Berlin or anywhere else in the world!
How have you incorporated Salt into your Qubes setup?
What are your use cases?
Share your experiences and let's learn from each other! 
i'm making my salts for my qubes set up distributable as rpms, which is also a convenient way to transfer them from domUs to dom0 in a more secure manner (since the rpms are signed)
what i'm unsure of is this: currently, i have one rpm that is my whole repo, and the repo contains topfiles that a user can enable individually. should i instead offer the vms (or bundles of them, in some cases) as individual rpms?
on the topic of salt states for qubes, i found this extremely cool repo: https://github.com/gonzalo-bulnes/qubes-mgmt-salt-user
brilliant way to organize the salts and distribute them imo
calling all qubes users who use salt! is there a way to target domUs with `state.highstate` when using many topfiles?
my repo is at https://git.sr.ht/~xyhhx/qubes-salts
(details in reply)
I'm new to #k8s and am wondering how to handle templating large amounts of config files. I couldn't find anything super useful in my search so I have an #Ansible sidecar I run to generate the kustomizations and config files. My most recent Ansible change was 30 lines, it resulted in changing 5,000 lines of YAML which will further be fed to Kustomize.
There has to be a better way?
I've heard about Helm, Yoke, KRO, and using an operator pattern. My understanding of those options is:
* Helm - My Org recommends avoiding (I don't know why)
* KRO - Not stable, but FFS neither is Kustomize
* Yoke - Almost kinda operator pattern
* Operator Pattern - This feels like reinventing a fucking config manager (ala #Ansible, #Puppet, #Chef, #Saltstack) for every fucking project. What new hell this is.
I'm hoping I'm missing something because the only workable flow for this workload is:
1) Create ansible roles/playbook to generate the kustomization.yaml and resources
2) Generate those kustomizations, check them into git
3) Use Kustomize via GitOps to expand the YAML even more
4) Push a metric fuckton of YAML to production
I'm losing my mind over here.
Macht irgendeines davon wirklich Spaß?
Sobald ich nur mit etwas komplexeren Datenstrukturen in Jinja ankomme, "zerreißt" es mir förmlich den Schädel.
Und gerade bei #saltstack finde ich die Fehlermeldungen, wenn mal etwas schief geht, meist nicht super hilfreich.
Exciting News!
We’ve just launched a FREE COURSE: Salt-Stack DevOps Automation Powered by Semaphore UI!
Learn how to:
Automate tasks using SaltStack Use Semaphore UI for simplified workflows Manage cloud setups on AWS, GCP, and Azure
Enroll for free today!
Boost your DevOps skills and take automation to the next level!
@sizeofvoid I'd rather wish for good #ansible support of #OpenBSD as well as other orchestration tools like #fleetdm, #Landscape, #puppet and #saltstack...
@paulsanders yeah suddenly that #proxmox cluster with #ceph and #zfs running #selfhosted #kubernetes for running stuff such as #nextcloud #matrix #dex of course all managed with #devops principles #git ified in #forgejo with #argocd and all managed by #saltstack seems completley justified.
@simondeutschl Habs auch vor ein paar Jahren gemacht. Sobald man drin ist in der Sache ist alles weitere sehr recht einfach, es kommt natürlich. Was ich direkt empfehle ist Konfiguration in Versions-Kontrolle z.B. git zu halten so ist es viel einfacher Übersicht zu halten. Gleiches gilt wenn es um Probleme geht, am besten todo listen machen. Das nächste Level ist dann alles deklarativ zu machen z.B. mit #Saltstack. Es kompliziert das ganze aber auf lange sicht kann es vieles vereinfachen.
Free and Open Source Infra and Software #Hackathon
Wir laden euch zum gemeinsamen Arbeiten an #FOSS in den @cccffm vom 17.–19. Januar 2025 ein.
Pretix: https://pretix.ffffm.net/ffffmev/hackathon202401/
Raum zum Entwickeln und Austauschen bezüglich Freier und Offener #Infrastruktur und Software.
Zum Beispiel Entwicklung an #OpenWrt, der Umbau von #Saltstack oder #Puppet auf #NixOS oder #Ansible, genauso aber auch Dokumentationserweiterung oder das Erstellen von Anleitungen fürs Routing im Internet
Do you still recommend #ansible? We're a #saltstack shop currently, but we're nervous given the most recent changes.
How's the health of the ansible project?
For those of you having troubles with the migration of
#SaltProject to #Broadcom, and if you use #Docker, you can check https://github.com/cdalvaro/docker-salt-master for running salt-master containerized.
Hahah! Oh man, so #saltstack was bought by #VMWare and that was bought by #broadcom
SaltStack just got #broadcom -ed with a 1 week notice of changing repos (not even a damn CNAME put in place) and dropped certain older packages and with no way to make your own copy of them.
@kfdm @eliasp @isotopp the decline of Saltstack is continuing. They shut down the repo.saltstack.io repos and switched to packages.broadcom.com. AFAICT they notified the community only 1 week in advance: https://saltproject.io/blog/upcoming-salt-project-docs-and-repo-migration/
And the best: packages.broadcom.com does not support IPv6. I have dozens of servers right now that cannot update packages. 
Sounds like Broadcom Is engaging in more enshittification of Salt Stack.
https://saltproject.io/blog/salt-project-package-repo-migration-and-guidance/
(plz hire me) 
Toxic Flange (Gurjeet)
Sven Seeberg 
