What is the pillar import path when using Salt user directories?

User Support
1

Hi everyone,

I am using Salt to record some of my personal configuration. I enabled the user directories.

I am currently turning my original split-SSH state into a formula. Part of that is taking advantage of Salt pillar.

So far, placing my pillar data in /srv/user_pillar/split-ssh/ makes it accessible as I expect. Using Jinja to template some of those files work fine too, until I try to:

{% from 'example.jinja' import example_macro %}

At that point I get:

jinja2.exceptions.TemplateNotFound: example.jinja

The file example.jinja is in the same directory as the file Iā€™m trying to importing it from (/srv/user_pillar/split-ssh/).

My understanding is that the path needs to be relative to pillar_roots, which is defined in /etc/salt/master as /srv/pillar.

Iā€™ve tried without success:

  • '../user_pillar/split-ssh/example.jinja'
  • 'split-ssh/example.jinja'
  • 'example.jinja'

Does anyone know what the pillar import path should look like when using the /srv/user_pillar?

For additional context: I experience the same problem when attempting to:

{% load_yaml 'config.yaml' as config %}

Any clues welcome! I can provide entire code snippets if that helps :slightly_smiling_face:

2

I can confirm that placing example.jinja in /srv/pillar makes it found. But that doesnā€™t really solve the problem when the goal is to use /srv/user_pillar.

Additionally, adding /srv/user_pillar doesnā€™t have any visible effect (?) - even after restarting.

# /etc/salt/master.d/user.conf

pillar_roots:
  base:
    - /srv/pillar
  user:
    - /srv/user_pillar
3

What I do:
Append my/your user directory to /srv/pillar/topd/config.top
and then run qubesctl saltutil.refresh_pillar
after that it will find the files.

4

I use a salt state to do this:
cat /srv/salt/dom/pilla.sls
add_topd:
file.append:
- name: /srv/pillar/topd/config.top
- ignore_whitespace: false
- text:
" - qub"
- order: 1

pillar_sync:
cmd.run:
- names:
- qubesctl saltutil.refresh_pillar
- order: 1

5

Read about the use of environments in salt - thatā€™s what
ā€œbaseā€ and ā€œuserā€ are.
You can target environments using saltenv and pillarenv

Example:

/srv/user_salt/get.top

base:
   target:
     - get

/srv/user_salt/get.sls

get_page:
   cmd.run:
     - name: wget {{pillar['host'] }}

/srv/user_pillar/get.sls

host: www.qubes-os.org

qubesctl --skip-dom0 --targets=target state.apply saltenv=user get

2 Likes
6

OKā€¦I was getting hopelessly confused here, but I think this is the right way to go about this.

First a tiny bit of background:
I am not yet using the ā€˜userā€™ environment, but I know for it to work fully, it needs its own pillar data and not to be using the pillar data I am presently putting into the base environment. (As I port to the new environment, I want to change a lot of things; things that depend on this self-supplied pillar data.) What I did there, was to create a directory /srv/salt/sac [sac=my initials, also my user name in dom0 on this box]. I put ā€˜init.slsā€™ in that directory, I also created init.top like this:

base:
    '*':
        - sac

I then created a soft link from /srv/pillar/sac/init.top to /srv/pillar/_tops/base. The result is if I edit init.sls the changes show up in the pillar.

OKā€¦so analagously:

Put an init.sls file to load into the pillar, in /srv/user_pillar. (I do not need a subdirectory here to keep my stuff separate from ā€œnormalā€ salt stuff, because thatā€™s what this environment is for.) For purposes of this test I simply copied the other init.sls and made some changes to it so I could tell which one I was looking at.

Also in /srv/user_pillar, I created init.top:

user:
     '*':
       - init

ā€¦And I am not sure this is right. [Not necessarily] obviously, change ā€˜baseā€™ to ā€˜user.ā€™ But in the original file I had ā€˜sacā€™ in the list, because that was the subdirectory. But this time there is no subdirectory.

However, it seems to have worked, which makes me wonder if itā€™s superfluous.

Finally, I went to /srv/pillar/_tops/user (I had to create that directory) and put a soft link in there to my new init.top.

It seems to work, at least sudo qubesctl pillar.items saltenv=user shows me what I put in user_pillar and I see no sign of ā€˜crosstalkā€™ from the original init.sls in the base environment.

However, one other thing that bothers me (other than the -init in the user version of init.top), is that /srv/pillar/_tops/user appears to be a directory that should belong to the base environment, yet I seem to have to go into there to specify files for the user environment.