Design and create salt formulas distribution method (#1939)

[unman]

Here’s my current thinking about providing some sort of app-store.
I’m going to reference salt, but the same would apply to other
mechanisms.

I like the idea of providing states using rpm packages:
they are easily signed, for authentication purposes; there would be
minimal set-up required; they fit with existing methods.

Interaction with existing?

1. Don’t override current configuration, unless that is purpose of
   package.
2. Work with current defaults,(e.g default template), unless good reason not
   to.
3. Don’t download a template unless that is explicitly part of package
   install, or explained in description.
4. Don’t assume - a user may delete debian-10 template and create a Fedora
   qube called debian-10.
5. Don’t surprise.
6. If install requires user intervention - e.g. selecting qubes to which
   a change should be applied - provide a basic tool for this. - How should
   this be signalled to user?
7. If an install requires user configuration - e.g. placing an openvpn
   config file - how should user be told what to do, and how to do it?

If you are using a configuration tool like salt,(or ansible, or bash
scripts, or …), install if you can.
If you cant install, leave the formula in a known place.
An informed user may want to edit the module and then install state.

Packages for the app store must be reviewed before inclusion.
Packages must be easily understandable.

Should removing the package remove the build? I don’t know. That sounds
sensible, but could have side effects depending on what the user has
done post install.

Thoughts?

[grey_olli]

@gonzalo-bulnes

I’ve been able to create a range of states and formulas from the following limited set of patterns .

I’ll use “qube” generically for brevity, some of the patterns make sense for an AppVM or a TemplateVM or dom0 or several of them but the idea is the same:

• ensuring that a qube exists
• ensuring that a package is available in a qube
• ensuring that a file is present in a persitent location of a qube
• ensuring that a file is present in a non-persistent location of a qube (that is, gets created when the qube starts)
• ensuring that some content is present in a persistent file in a qube
• ensuring that some content is present in a non-persistent file in a qube (that is, gets added to the file when the qube starts)

Each of those patterns, in turn, can be rendered quite simply in Salt, which is good for review. (Happy to provide examples for discussion if useful.)

Just share your samples w/ github. Think there’re more people like me that prefer to learn by sample. If you put a readme (i.e. quick howto how to apply the sample) - even better.
At least I’ve got a reason to get into salt - too many work on Qubes OS reinstall - some should be done by automation.

[grey_olli]

@unman

I like the idea of providing states using rpm packages:
they are easily signed, for authentication purposes; there would be
minimal set-up required; they fit with existing methods.

With rpm you have to definitely trust the rpm builder since anything could be placed in install script. And it’s not very handy to check what rpm does - require some digging. If the rpm w/ salt stuff is signed by Qubes OS team that’s definitely a reason to trust. I’ve seen you provide samples w/ salt stuff. Is there something that is already signed by Qubes OS team?

@unman

Don’t override current configuration, unless that is purpose of
package.

Agree.

@unman

Work with current defaults,(e.g default template), unless good reason not
to.

You should copy the default template & modify copy. It’s not a good idea to alter default template - if something gets wrong you cannot replace it from backup-clone - you have to reinstall default template w/ rpm. Also default template may be already used for many app qubes & I think it’s better to ask user to alter template value for his/her app vm not to silently apply a new template w/o user intervention.

@unman

Don’t download a template unless that is explicitly part of package
install, or explained in description.

Agree

@unman

Don’t assume - a user may delete debian-10 template and create a Fedora
qube called debian-10.

Agree

@unman

Don’t surprise.

Agree.

@unman

If install requires user intervention - e.g. selecting qubes to which
a change should be applied - provide a basic tool for this. - How should
this be signalled to user?

Depends to the way the software installed - terminal or gui. It should take a list of qubes present & allow user to select it either by menu either by entering a number pointing to existing qube. In gui it should be a menu. In terminal - numbers will be enough. This is not possible w/ RPM w/o hacks, but maybe it is possible to call external utility from rpm? At least I guess rpm installation should provide ability to get things in some order. So external tool should just not return till user response.

@unman

If an install requires user configuration - e.g. placing an openvpn
config file - how should user be told what to do, and how to do it?

external to rpm tool needed. One possible solution - It could write user response to files & these files then will be parsed by next command inside rpm.

@unman

If you cant install, leave the formula in a known place.
An informed user may want to edit the module and then install state.

That would be even better - two-step installs. 1st step places the formula for salt & whatever script, user reviews it and then executes apply step. Sounds good. Then both install and apply utilities could be verified and distributed by Qubes team. People just put recipes in easy readable form & users will have to trust less for third party recipes (easier to check than ready to use rpms)

@unman

Should removing the package remove the build? I don’t know. That sounds
sensible, but could have side effects depending on what the user has
done post install.

This should be controlled by an option controlled by user.

@unman

Thoughts?

I would be glad to have a video tutorial. At least instead of reading tons of documentation I’d like to have many samples in github & one-two videos to get started as quick as possible. Well, the problem w/ videos is that is could be done only w/ external camera - no one would like to install in their Dom0 full software for screen capture with huge dependencies.

[gonzalo-bulnes]

@grey_olli My Qubes Os-related Salt formulas and states are available on GitHub already, along with the tooling I use to package them as RPM. If you follow the forum link in the post you quoted, you’ll quickly find references to my notes and the corresponding GitHub repositories.