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
Related
I am trying to mount a repository with server config files (think nginx, mysql, etc) inside my salt fileserver in order to be able to distribute these files to my minions (Without having to do a checkout of the full repository on all my minions).
If I've understood correctly: All gitfs_remotes will be 'flattened' into one filesystem structure (I can confirm this when I run salt-run fileserver.file_list.
What worries me is that, as far as I know, this 'config file only' repository is now also being searched by Salt for state modules.
Is there some way to either:
Designate a gitfs mount as 'don't search for SLS files'.
Mount the actual salt state repository (which contains my top.sls and state modules) under a subdirectory of the salt fileserver and point salt to the top.sls therein?
I stand open to the possibility that this is a wrong approach entirely of course, my only requirement is that the server config files (again, nginx, mysql, etc) live in a separate repository, and that the entire high state (state modules, top file) lives in git.
master config:
fileserver_backend:
- gitfs
gitfs_remotes:
- git#github.com:MyOrg/salt-configs.git:
- git#github.com:MyOrg/server-config-files.git:
- mountpoint: config-files
Have you considered storing your configuration file in a pillar?
For example:
HostFiles:
LinuxBasic: |
192.168.1.1 server1
192.168.1.2 server2
And then in your state file, when you want to render the hostfile:
LinuxBasicHostFile:
file.managed:
- name: /etc/hosts
- contents_pillar: {{ HostFiles:LinuxBasic }}
You could also GPG that file if it was sensitive using the keys on your Salt master's server:
$ cat nginx.hostfile | sudo gpg --armor --batch --trust-model always --encrypt --homedir <salthomdir> -r <keyname>
Paste the output of that into your pillar:
HostFiles:
LinuxBasic: |
-----BEGIN PGP MESSAGE-----
Xks383...a bunch of encrypted text...BjAs0
-----END PGP MESSAGE-----
And inform your salt master that HostFiles contains GPG encrypted content in your master.conf, or better yet, in a local conf file in /etc/salt/master.d/decrypt.conf:
decrypt_pillar:
- 'HostFiles': gpg
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 mandatory to put files in /srv/salt folder of master to transfer file/directory from master to connected minions.
Can we transfer files without using salt file server
1) Can we transfer files without using salt file server?
2) Also the document says "You can't run interactive scripts" .
Does it mean there are some limitations to execute arbitrary linux commands with cmd.run eg. we can run salt "*" cmd.run ['ls -l /home'] .
Similarly can we run commands like scp,ssh with cmd.run.
You don't have to use the salt file server. You can also set the source to for example a http location. In that case though, you must also declare the hash of the file, for example:
/etc/nginx/sites-enabled/mysite:
file.managed:
- source: http://example.com/mysite
- source_hash: abc123....
The document suggests the default location as /srv/salt as mentioned here
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.