This would be pretty epic. One thing that could be particularly useful (I think) would be a boilerplate salt config with some examples. (If this exists already, please let me know!). But a nicely documented tutorial could be nice as well
I only took a quick look, but that reference sure helps! It still requires to copy from a
dom0, but it builds an RPM package on the fly and that is something I’ll definitely look into!
I’ll also take a better look to how the RPM is used once in
dom0. I’ve a gut feeling that importing it into
dom0 from a package repository (vs copying it via a tarball) may allow for additional confidence that is what it pretends to be -I know there is a two-step process to update packages- but I haven’t looked enough into how updates work yet to be sure and I might well be wrong. This is a great first step, thank you for the pointer!
Also your link lead me to a way of tagging qubes for targetting by qubectl! That’s awesome, thanks again!
Glad it helped!
I’m in the process of posting my salt formulae to GitHub.
Building packages is simple, and I have an example of how to do this
for a Kali template.
I’ll add spec files for the other formulae too, and host some packages
on https://qubes.3isec.org - too late to do it now, so maybe tomorrow.
Thanks for the examples @unman. I’ve done some progress and have a proof-of-concept for building a package out of the Salt state (using Tito).
I think I’ve got a good understanding of what it would take to publish the RPM (and it seems relatively straightforward).
I’ll look further into checking integrity of the sources and signing the resulting RPM packages, and once the loop is complete I’ll look into turning the Salt state into a formula.
Today I learned: split-GPG and RPM packaging play nice together in general.
I took note of the corresponding RPM configuration because it seems generic enough.
From there, signing and verifying packages can be performed “the usual way”:
# sign both source package and regular package: rpm --resign example-1.0.0-1.f32.src.rpm rpm --resign example-1.0.0-1.fc32.noarch.rpm # verify them: rpm -K example-1.0.0-1.fc32.src.rpm rpm -K example-1.0.0-1.fc32.noarch.rpm
Cross-referencing @unman’s examples:
I’ll call this done for now. If anyone is interested in setting up a personal YUM/DNF repository for RPM packages, here is a starting point:
I’ve merged that pull request, and got the verify / build / verify / sign loop complete. Things can certainly be refined, but I think the essential elements are there and I installed qubes-mgmt-salt-user-split-ssh-0.1.0-1.fc32.noarch.rpm in my dom0
Next step I believe is turning the Salt state into a formula (corresponding issue in GitHub).
If anyone want to join me figuring that out, please chime in, you’d be welcome!
Quick update: this is coming along nicely. As of qubes-mgmt-salt-user-split-ssh-0.2.2-1.fc32.noarch.rpm the Salt formula is behaving the way I expect, and I am satisfied with its structure.
For reference, the configuration file looks like this (and persists between updates):
# /srv/user_pillar/split-ssh/config.yaml --- vaults: - name: ssh-vault template: fedora-32 label: black mem: 400 vcpus: 2 autostart: True clients: - name: work template: fedora-32 label: blue mem: 400 vcpus: 2 autostart: False - name: another-ssh-client template: fedora-32 label: blue mem: 400 vcpus: 2 autostsart: True
Beyond a few limitations (e.g. I haven’t looked into supporting other templates than fedora-based ones though it is certainly possible; I don’t personally need more than one vault and left support for multiple vaults incomplete) the formula covers what I believe are the most common uses cases.
There are a couple of things that I’d like to refine in the way the RPM packages / installation behave (e.g. the package currently includes a workaround for this issue that is not very elegant) but I think at this point the next step is writing some documentation.
If you’re able to follow along the code (Salt formula, RPM packaging, or RPM publishing, linked in earlier updates) and have thoughts on what would be most valuable to explain, please let me know here!
Referencing a similar thread about packaging Salt config as Debian packages from the mailing list. (I can’t perform the cross reference there from the forum.)
- How to publish RPM packages - done.
- If you’ve thoughts on what you’d like to see next, comment below!
I’ve also set up some context and outlined the missing sections before I take on the next guide.
Of course, feedback (well-intended and actionable) is welcome! I think the qubes-packages’ discussions are a good place for that.
- How to publish RPM packages
- Tutorial: create a split-SSH Salt state for Qubes OS - done
- I’ll take a break from writing, but if you’ve thoughts on what you’d like to see next, let me know!
@deeplow if you’ve got time to skim through the tutorial linked above, I’d love to hear your thoughts!
I’m thinking of structuring the generalization as a collection of how-to guides / code snippets based on the tutorial steps: how to create/ensure a qube exists, how to set up qube preferences, how to ensure packages are available in a qube, how to ensure presence of persistent files in a qube, how to ensure presence of non-persistent files in a qube, and so on.
That’s what I think would match more closely your suggestion of boilerplate config with examples:
One thing that could be particularly useful (I think) would be a boilerplate salt config with some examples.
Thank you very much for this work.
Kind of busy right now, but I was looking and I think I will finally learn the basics of Salt (from the docs you linked). It seems not too difficult and incredibly useful.
Just want to say, I think this is a good path.
Note: I am a intermediate level user, not too technical, not excessively comfortable with the cmd line.
Not a lot at the moment. I’ll see what I can but. But I welcome the contribution very much and extend the offer for other people to provide feedback on it.
Sounds nice! I must also say that your “read-the-docs” looks much nicer than the default markdown files of the community documentation. But have you considered making your contributions there?
Or if you prefer to do on your website, maybe after you’re done you could open a pull request to add a link to that under “external documentation” over on the official docs.
I considered submitting this to the community docs, but at the moment I don’t have the bandwidth to write and manage the back and forth that publishing on third-party docs requires. I am very much figuring out the format as I go, and self-publishing gives me the room to iterate quickly.
I’ll take on your suggestion, though, and open a pull request to add a link or two under the “external documentation” section of the official docs when I’m done writing the how-tos.
@gonzalo-bulnes just want to point to this. If you already knew it, please ignore this message.
I hadn’t seem that. This is super useful @qubicrm thank you!