Is there a way to preview what files will be served to a minion on a state.highstate? I know that you can run state.show_highstate, but that is not the output I am looking for. For example, inside /path/to/recurse/dir/ I have foo.txt and bar.txt and in my sls file I have
/path/to/recurse/dir/:
file.recurse:
- source: salt://dir/
I would like to run state.preview_highstate and it would show me the contents of foo.txt and bar.txt. Does anyone know how to go about this without just running state.highstate?
If you are able to run the state on the minion but just don't want to apply any changes you can append the test=True to your command:
salt '*' state.highstate test=True
This will run the highstate on the minion but will not make any changes to the system. Changes that would be applied are shown in yellow.
Related
I am configuring a local Salt setup and I have hit a bit of a wall.
My setup is:
CentOS: Red Hat Enterprise Linux Server release 7.7 (Maipo)
Salt: salt 3000.1
I have a very basic configuration with nothing changed from default in the Master or Minion config.
My directory structure is as follows:
/srv/salt/apache/init.sls
/srv/salt/uptodate/common.sls
If I run the following:
salt '*' state.sls apache Test=true
It correctly applies the sls files inside the apache folder.
If I run:
salt '*' state.sls uptodate Test=true
It returns:
minion:
Data failed to compile:
----------
No matching sls found for 'uptodate' in env 'base'
I have no top.sls files configured and if I move common.sls into the apache directory it also does not get applied.
Does anyone have any idea what is going wrong here?
The init.sls can be compared to an index.html file on a webserver.
If you want to apply a statefile other than a init.sls you need to add the name of the state file.
This should work for you:
salt '*' state.sls uptodate.common test=True
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 want to copy a directory from my Salt master to my Salt Minion. All the files are executable. I want to then execute the files on my Salt minion.
I want to achieve this using a Salt state. This is what I have so far:
copy_scripts:
file.recurse:
- name: /root/scripts
- source: salt://files/scripts
- user: root
- group: root
- file_mode: 744
This puts the files on my Salt minion. How can I execute all the scripts inside?
You can do this with cmd.script. cmd.script will copy the file (script?) to the minion and run it in a single state.
https://docs.saltstack.com/en/latest/ref/states/all/salt.states.cmd.html#salt.states.cmd.script
You'd need a state for every script you wanted to run.
bonus points: You can use Jinja to loop through a list to generate the states automatically https://docs.saltstack.com/en/latest/topics/tutorials/states_pt3.html
After copying the directory to the desired path, you can use cmd.run to execute these scripts.
my web server generates a shell script with more than 100 lines of code based on complex user selections. I need to orchestrate this over several machines using salt-ssh. what I need is to copy this shell script to remote and execute it from there for all devices. how to achieve this with salt-ssh ?. I can not install minions on the remote device.
Just as with normal minion. Write a state...
add script:
file.managed:
- name: file.sh
- source: /path/to/file.sh
run script:
cmd.run:
- name: file.sh
...and apply it
salt-ssh 'minions*' state.apply mystate.sls
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.