@gonzalo-bulnes just want to point to this. If you already knew it, please ignore this message.
regards
3 Likes
I hadn’t seem that. This is super useful @qubicrm thank you! 
A quick update on this project, in case anyone is interested in taking part.
After packaging my Split-SSH and Split-GPG formulas, I stopped publishing for a long time. For various reasons; but one of them was that I was finding those formulas way too complex to be pleasant to work with (as a developer, no as an end-user).
It turns out that one idea that was brought up in this topic held water: targeting qubes through their tags, instead of their names. While I didn’t doubt it was a good idea, it is only relatively recently that I found a way to do it that I found satisfactory, thanks to walking into some code written by @brian.
I’m in the process of publishing two Salt formulas that enable QVM tags and QVM features to be used as pillar data, and I found out that:
- The RPM packaging setup I did two years ago wasn’t bad. It’s actually pretty convenient.
- Using QVM tags to target qubes alows to simplify significantly the formulas, while retaining the flexibility that I was trying to maintain at high cost. (Spoiler for those who’ve seen that code: the custom Salt pillar created out of a pile of YAML files and Jinja templates is entirely gone.)
- I identify as a desirable pattern / boundary to leave the existence of the qubes (
qvm.present) out of the scope of the formulas that configure them. You may want to create states that ensure the presence of qubes, and for example their tags, but I’d recommend keeping those separate from application-style formulas like split-ssh or @unman’s cacher.
Once that done, I’ll publish new versions of the Split-SSH and Split-GPG packages that have those packages as dependencies and take full advantage of the new targeting strategy (codename: version 2.0.0). I’ve been using them for a while now, and I think they might be interesting if you’re into creating your own Salt formulas. The RPM package-level dependency management is also something that I want to explore.
Last but not least, I’m currently working in parallel towards making the RPM packages I create reproducible. I share progress on GitHub if you’re interested. See the Reproducible RPM builds? issue.
As usual, once I’m done I hope to write some docs about those new processes. Keep tuned, and/or let me know what parts would be most interesting to start with.
5 Likes
Quick update for anyone who might be following this: while my current implementation works as expected in R4.1, some troubleshooting seems to be necessary in R4.2. Help testing is welcome!
3 Likes