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.