Hi there,
I’m currently trying to convert my shell script which is responsible for creating my domains and was wondering if there’s any way of using a custom directory besides /srv with Salt and qubesctl in order to move all my *.sls and *.top files to my home directory?
Can’t find anything that points in that direction from the source code I have been reading.
Thanks in advance!
The answer is either on the forum or on qubes-users.
I know as I gave it back then.
Qubes ships with the ability to use a custom user directory under /srv
If you want to use another directory, then this will be a new
environment (in Salt terms) - this is fairly standard Salt, and you will
need to set the relevant _roots in /etc/salt/minions.d/f_defaults.conf
I was able to set up user_salt, user_pillar and user_formulas (the github docs don’t mention user_formulas).
I then copied a couple of my sls files into user_salt to try them out there (they formerly lived in a subdirectory of salt). I eliminated all references to the subdirectory, either changing the path to user_salt, or just wiping out the subdirectory name if all I saw was it (no /srv/salt in front of it), depending on context–in some cases it’s going off the “root” and in others (like jinja include statements) the full path must be specified.
Unfortunately when I try them out qubesctl insists on running in the environment “base” and user_salt is in “user”. So qubesctl can’t even find the state I am trying to run. I can’t figure out (and I did try to look at saltstack’s site) how to run in some environment other than “base.”
If the prior paragraph made no sense, I’m sorry it’s not my fault. None of these concepts have a coherent explanation anywhere; it’s just assumed in all the documentation that it’s understood already. (saltstack had one passing reference to an environment in a tutorial, promising to discuss it later…it never did, at least not in the next ten pages…and searching only located a thing about how to reference a file in another environment.) It doesn’t help that we have no minion…or no master…I can’t even figure that out, so much of the info is a non sequitur.
It seems to me that you haven’t found this which explains the principles in quite a coherent way.
On running salt masterless, this is also documented - see this quick start
Hi @SteveC,
It took me a while to figure that out as well, and I empathize with you on navigating the various documentation sources.
When applying Salt states you can specify the environment using the saltenv option.
Example:
# dom0
sudo qubesctl state.apply split-ssh.client.vm split-ssh.vault.vm saltenv=user
# ① ② ③
- ① This is the same command we used in the introduction to using Salt in Qubes OS. The implicit target is dom0.
- ② When referring to Salt states in Salt commands or files, the directories are separated by dots and the extension is omitted. This parameter corresponds to
split-ssh/client/vm.sls.- ③ When applying a single state like we’re doing here, it is necessary to specify the environment
userin order to instruct Salt to look it up in the user directories (/srv/user_salt).
That example is taken from the notes I took while learning to use Salt in Qubes OS (the saltenv keyword will be higlighted if you follow the link):
Eventually, you may find out that writing top files makes the environment management a little less tedious because the top files take care of the targetting. (It’s a bit more work upfront, but I personally find the trade-off worth it and that’s what my notes suggest if you keep reading beyond the example.)
From further down the same notes:
A Salt top file allows to group several state files and to specify which environment and machines each state applies to.
Have fun! 
Ah!
Something for me to play with. I have a metric shit tonne of salt files (as well as actual data files, mostly ones for dom0) all in /srv/salt/, which is probably not the best place for that pile of stuff. /srv/user_salt will work better no doubt–now that I know how to actually run the sls files I would keep there!
(My other option was to go to some file over in /etc/salt and tell it to put user-salt into the base environment…which seemed like a bad idea. If someone went to the trouble of creating a new environment, they probably had a reason for it even if I am still totally clueless about it. Now off to read unman’s link)
You’re right, I never saw that page on top files.
There’s an awful lot there to digest, for midnight my time. But it looks like it will make a lot of things clear, or at least clearer!
At the beginning of the notes I linked there is an intro on user directories (i.e. the user environment), with a link to the relevant docs.
All that being said, I don’t know of anyone else than me (and you!) using them so far.