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.
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'm trying to use SaltStack to setup configuration on a MariaDB instance. I'm trying to make a symbolic link equivalent to this command
ln -s /var/lib/mysql/dbaas/mysql_client.cnf /etc/my.cnf
Is that the right salt syntax ?
link-mysql-client-cnf:
file.symlink:
- name: /etc/my.cnf
- target: /var/lib/mysql/dbaas/mysql_client.cnf
- force: True
For some reason the symlink fails because my.cnf already exists, I read the documentation and set Force to True but it didn't work. Any suggestions please?
I solved the issue.
What was causing the problem is that the engine was created before putting force=True and that was cached even when I modified the salt script. My advice is to clear out the engine and start-over by creating an engine and an instance anytime you change the salt.
About two-month-old sls files are working no more. I've tried to put the minimal example below:
salt 'myserver.internal' state.highstate gave:
myserver.internal:
Data failed to compile:
----------
Requisite declaration dhparam in SLS nginx is not formed as a single key dictionary
----------
Requisite declaration /etc/nginx/sites-available/myapp.conf in SLS nginx is not formed as a single key dictionary
ERROR: Minions returned with non-zero exit code
with the following nginx.sls:
/etc/nginx/sites-available/myapp.conf:
file.managed:
- name: /etc/nginx/sites-available/myapp.conf
- source: salt://nginx-myapp.conf.jinja
- template: jinja
- require:
- dhparam
dhparam:
cmd:
- run
- name: "mkdir -p /etc/nginx/ssl/; openssl dhparam -out /etc/nginx/ssl/dhparam.pem 2048"
- unless: ls /etc/nginx/ssl/dhparam.pem
And there are tens of those errors when I run the whole configuration. Am I missing something? Maybe, some crucial dependency not installed/updated/broken? yamllint did not find any problems in my SLS files. Same files worked well on another server two months ago.
Versions:
salt-master 2016.11.6+ds-1
salt-minion 2015.8.8+ds-1
The system is Ubuntu Xenial 16.04.2 LTS on both master and minion.
The problem is the version of the minion. While I added repo key for saltstack, I forgot to add
deb http://repo.saltstack.com/apt/ubuntu/16.04/amd64/latest xenial main
to /etc/apt/sources.list.d/saltstack.list and run apt update before installing salt-minion.
When I corrected that, files started to work again.
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.