Is there a way to exclude minions from being targeted even if I run salt '*' state.apply on CLI?
Ideally the exclusion should be declared somewhere in top.sls
From CLI, you can exclude minion as follows,
salt -C 'not minion-id' test.ping
Above pattern is available since version 2015.8.0. If you are using older version then,
salt -C '* and not minion-id' test.ping
Please read more about Compound matchers here.
You want to use compound matching. Targetting all the minions for the webserver states except minion_id_1 can be done like this.
base:
'not minion_id_1':
- match: compound
- webserver
Documentation on compound matching can be found here: docs.saltstack.com/en/latest/topics/targeting/compound.html
Related
I'm new to salt, and I'm trying to use salt-ssh to manage hosts. I have the following roster file
~/salt/roster
pi:
host: raspberypi1.local
tty: True
sudo: True
I have salt states
~/salt/states/docker.sls
I am able to apply the salt states by calling the state explicitly
sudo salt-ssh '*' -c . state.apply docker
How can I make it so that I don't have to call the state directly? I want the raspberypi1.local node to always run the docker state.
Things I've tried
Make ~/salt/top.sls
base:
'pi*':
- docker
However the top.sls appears to be ignored by salt-ssh
I've tried editing ~/salt/Saltfile to point at a specific file_roots
salt-ssh:
roster_file: /Users/foobar/salt/roster
config_dir: /Users/foobar/salt
log_file: /Users/foobar/salt/log.txt
ssh_log_file: /Users/foobar/salt/ssh-log.txt
file_roots:
base:
- /Users/foobar/salt/top.sls
Here file_roots also appears to be ignored.
Whats the proper way to tie states to nodes when using salt-ssh?
I moved ~/salt/top.sls to ~/salt/states/top.sls, and removed file_roots: entirely from the Saltfile (it belongs in the master file). And now I am able to apply states like so:
sudo salt-ssh '*' -c . state.apply
I have the following saltstack top file.
'blog.php.*':
- php-apps
- php-apps.blog
'app.php.*':
- php-apps
- php-apps.some-app
'*phpone*':
- php-apps
- php-apps.blog
- php-apps.some-app
When I run high state for the above to environments It works fine. like this
salt 'blog.php.*' state.highstate or salt 'app.php.*' state.highstate
But when I run the same for the third server it fails.
salt '*phpone*' state.highstate
Error:
No matching sls found for 'php_apps' in env 'base'
I went to the minion server and found that the init.sls file in php-apps is not being copied over to minion cache location /var/cache/salt/minion/files/base/php-apps
I am not able to find any logs of state file having any compilation error which could cause this.
I tried the following but It still does not work.
Cleared master cache
Cleared minion cache
Recreated minion from scratch
What am I missing? Please let me know if any other information is required.
First , I will use yaml validator to validate the yaml meta structure. i.e.. install kwalify
#install kwalify
sudo apt-get install kwalify
# Now try to check the top file with yaml meta-validation
kwalify -m top.sls
# to check many yaml sls file
find . | grep "sls" | xargs kwalify -m
Don't be surprised when salt doesn't verify the most basic meta structure.
Because saltstack using YAML, it also suffer from tab vs space indentation issues, if you didn't force your editor to convert all TABS to fix spaces.
Is it possible to target a specific set of minions when applying a state? Instead of doing:
salt '*' state.sls mystate.sls
I want to do:
salt '[key1,key2,...]' state.sls mystate.sls
Of course, just use -L
salt -L 'key1,key2,key3,...' state.sls mystate.sls
http://docs.saltstack.com/en/latest/topics/targeting/globbing.html#lists
I installed salt master and minion, and it look like right. It successfully run:
salt '*' file.rmdir dir_path=/root/abc user=root group=root mode=700
It's great. But I got a error when follow command run:
sudo salt '*' user.present name=salt
The error message:
'user.present' is not available.
I Google'd and haven't any result. Do you have any suggestion? Thanks!
When you are on the command line you are executing Salt "execution modules", which are imperative commands.
user.present is a Salt "state", which is a declarative, idempotent statement that you generally put inside a "state file" (a yaml file with an .sls extension)
To add a user from the command line you will need to use the user execution module. http://docs.saltstack.com/en/latest/ref/modules/all/salt.modules.useradd.html#salt.modules.useradd.add
It would look something like this:
salt "minion id" user.add sarah
By default, salt-api uses glob method to match target minion. Is it possible to use other way(maybe grains, pcre and so on) to find minions.
I tried to pass tgt_type to salt-api, but it didn't work.
curl -s -H "Accept: application/json" -d username='user' -d password='pwd' -d eauth='pam' -d fun='test.ping' -d tgt='127.0.0.1' -d client='local' -d tgt_type='ipcidr' localhost:8000/run
expr_form is the option you're looking for.
expr_form='ipcidr'
This is found quite often in various parts of Salt.
Here's a legend with the different types of matching in Salt:
http://docs.saltstack.com/en/latest/topics/targeting/compound.html
tgt_type should work with latest versions of Salt API. As referred to as the type of tgt (Salt target matcher for minions).
Starting from version 2017.7.0, expr_form has been renamed to tgt_type.
tgt_type can be one of the following:
glob - Bash glob completion - Default
pcre - Perl style regular expression
list - Python list of hosts
grain - Match based on a grain comparison
grain_pcre - Grain comparison with a regex
pillar - Pillar data comparison
pillar_pcre - Pillar data comparison with a regex
nodegroup - Match on nodegroup
range - Use a Range server for matching
compound - Pass a compound match string
ipcidr - Match based on Subnet (CIDR notation) or IPv4 address.
For more information, please refer official client function documentation:
https://docs.saltstack.com/en/latest/ref/clients