Using Qubes base Salt pillar in user_salt?

[Vasilis]

Hi,

When using the Salt user configuration located in '/srv/user_salt' what is the
best way to use the Qubes specific pillars located (for this example) in
'/srv/salt/_pillar'?

Step to reproduce my test:

- Install qubes.user-dirs

`qubesctl state.apply qubes.user-dirs`

- Enable custom-qubes.top

`qubesctl top.enable custom-qubes`

- File contents

/srv/user_salt/custom-qubes.top:

```
user:
qubes:type:template:
- match: pillar
- template-prefs
```

/srv/user_salt/template-prefs.sls:

```
# -*- coding: utf-8 -*-
# vim: set syntax=yaml ts=2 sw=2 sts=2 et :

template-vm-preferences:
qvm.prefs:
- include_in_backups: False
- label: black
- maxmem: 1000
- netvm: sys-firewall
- vcpus: 1

```

I get the following obvious error:

fedora-32:
----------
ID: template-vm-preferences
Function: qvm.prefs
Result: False
Comment: State 'qvm.prefs' was not found in SLS 'template-prefs'
Reason: 'qvm.prefs' is not available.
Changes:


Cheers,
~Vasilis
--
PGP Fingerprint: 8FD5 CF5F 39FC 03EB B382 7470 5FBF 70B1 D126 0162
PGP Public Key:
https://keys.openpgp.org/vks/v1/by-fingerprint/8FD5CF5F39FC03EBB38274705FBF70B1D1260162

[David Hobach]

On 12/16/20 9:41 AM, Vasilis wrote:
> When using the Salt user configuration located in '/srv/user_salt' what is the best way to use the Qubes specific pillars located (for this example) in '/srv/salt/_pillar'?

The below script should give you the idea how to do it:

#!/bin/bash
#
# Run the salt configuration of _this_ folder in dom0.
#
# Assumes that you have `user_[formulas|pillar|salt]` directories in _this_ folder.
#
# NOTE: If even `sudo qubesctl top.enabled` failed for you, you can try re-installing `qubes-mgmt-salt-* salt salt-minion`
# (first via `sudo qubes-dom0-update`, then via `sudo dnf reinstall`.
#
# Useful info:
# - initially sync all modules etc: sudo qubesctl saltutil.sync_all saltenv=user
# - to enable a state (only needed for everything not in top.sls): sudo qubesctl top.enable tripleh.vms saltenv=user
# - to apply a state (set test=true for testing): sudo qubesctl --show-output state.apply saltenv=user
# - list enabled states: sudo qubesctl top.enabled saltenv=user
# - local salt doc: qubesctl sys.doc | less (details for e.g. archive: qubesctl sys.doc archive)
# - all available grains: sudo qubesctl --targets dom0 grains.items
# - show sls output after jinja: sudo qubesctl --show-output state.show_sls vm-install.vim saltenv=user
# - Logs: /var/log/qubes/mgmt-[target-vm].log
# - Further doc:
# - https://github.com/unman/notes/tree/master/salt (also locally saved here; he always refers to the examples/ dir)
# - https://www.qubes-os.org/doc/salt/
# - The qvm.[module] doc can be found in dom0 inside `/srv/salt/_modules/ext_module_qvm.py`.
# (_Warning_: The `README.rst` appears outdated. --> Only the code has current information.)

set -e -o pipefail

#error [msg]
function error {
local msg="$1"
>&2 echo "ERROR: $msg"
exit 1
}

[[ "$(whoami)" != "root" ]] && error "This script must be run as root."

#path of this directory (hopefully...)
SCRIPT_DIR="$(dirname "$(readlink -f "${BASH_SOURCE[0]}")")"

#saltModSymlink [target]
function saltModSymlink {
local target="$1"
local tpath="/srv/user_salt/$target"
rm -f "$tpath"
ln -s "/srv/salt/$target" "$tpath"
}

#create user_ symlinks @/srv/ for the saltenv=user (explicitly configured by Qubes OS)
echo "Creating user_ symlinks in /srv/..."
for file in "$SCRIPT_DIR"/* ; do
if [ -d "$file" ] && [[ "$file" == *"user_"* ]] ; then
target="/srv/${file##*/}"

#remove previous instances & update new
rm -f "$target"
ln -s "$file" "$target"
fi
done

#create module symlinks
echo "Creating Qubes module symlinks..."
saltModSymlink "_grains"
saltModSymlink "_modules"
saltModSymlink "_pillar"
saltModSymlink "_states"
saltModSymlink "_utils"

#sync modules (we just added some via the symlinks above)
#echo "Syncing modules..."
#qubesctl saltutil.sync_all saltenv=user

#call
ret=0
if [ $# -gt 0 ] ; then
echo "Calling qubesctl saltenv=user with your arguments..."$'\n'
#e.g. state.show_top is quite useful to see what state is applied where (doesn't seem to work for anything != dom0)
qubesctl --show-output "$@" saltenv=user || ret=$?
else
echo "Using qubesctl to apply the top.sls state..."$'\n'
#state.highstate respects the top file, state.sls ignores it (just targets anything mentioned as target)
qubesctl --show-output --all state.highstate saltenv=user || ret=$?
fi

echo ""
echo "All done."
exit $ret

[Vasilis]

Hi David,

David Hobach:

> On 12/16/20 9:41 AM, Vasilis wrote:
>> When using the Salt user configuration located in '/srv/user_salt' what is the
>> best way to use the Qubes specific pillars located (for this example) in
>> '/srv/salt/_pillar'?
>
> The below script should give you the idea how to do it:

[..]

Thank you very much for sharing this script.

I would prefer very much to do it in a Salt way rather than symlinking
directories. It seems that this is possible in Saltstack and it's mentioned in
the Management stack documentation of Qubes here:
https://www.qubes-os.org/doc/salt/#top-files

"For each target you can write a list of state files. Each line is a path to a
state file (without the .sls extension) relative to the main directory. Each /
is exchanged with a ., so you can’t reference files or directories with a . in
their name."

Any directions on how can I include the base PATH of the pillars '/srv/salt' to
the top or sls file?

/srv/user_salt/custom-qubes.top:

```
user:
qubes:type:template:
- match: pillar

- .template-prefs
```