I've downloaded the PHP formula by following the instructions here: https://docs.saltstack.com/en/latest/topics/development/conventions/formulas.html
I've changed apache to php. In my salt config file (which I assume is /etc/salt/master), I've set file_roots like so:
file_roots:
base:
- /srv/salt
- /srv/formulas/php-formula
I don't know how I'm supposed to run it now. I've successfully run a salt state file by discovering that the documentation is incomplete, so I'd missed a step I wasn't aware of.
If I try to run the formula the same way I've been running the state, I just get errors.
salt '*' state.apply php-formula
salt-minion:
Data failed to compile:
----------
No matching sls found for 'php-formula' in env 'base'
ERROR: Minions returned with non-zero exit code
I've also tried: sudo salt '*' state.highstate, and it also has errors:
salt-minion:
----------
ID: states
Function: no.None
Result: False
Comment: No Top file or master_tops data matches found.
Changes:
Summary for salt-minion
------------
Succeeded: 0
Failed: 1
------------
Total states run: 1
Total run time: 0.000 ms
ERROR: Minions returned with non-zero exit code
You have to add a top.sls file to /srv/salt/, not just in /srv/pillar/. If you have a file called /srv/salt/php.sls, you have remove it, otherwise it will interfere with /srv/pillar/php.sls.
Contents of /srv/salt/top.sls:
base:
'*':
- php
This is kind of bizarre, because my previous test (which wasn't a formula) used /srv/salt/php.sls and /srv/pillar/top.sls. Now I'm using /srv/pillar/php.sls and /srv/salt/top.sls.
Related
On Minion:
ID: run_snmpv3_config
Function: file.managed
Name: /tmp/run_snmpv3_config_cmd.sh
Result: False
Comment: Source file salt://files/run_snmpv3_config_cmd.sh not found in saltenv 'base'
Started: 15:11:56.175325
Duration: 27.084 ms
Changes:
On master we confirm that the minion does in fact see the file:
master # salt minion cp.list_master | grep snmp
- files/run_snmpv3_config_cmd.sh
So why isn't it able to get it?
(In fact I wanted to use cmd.script but that errors out with Unable to cache script, so I tried to just copy the file, which doesn't work either as we see above.)
I called the state for debugging purposes on a client system using
salt-call --local state.apply teststate -l debug
Of course in this case it will look for file salt://x inside /srv/salt (or whatever the minion's config is) on the minion and not the master....
Having issues applying state files to minions on salt, they're just basic test ones, nothing complicated.
In my master config file I have the following file roots definition:
file_roots:
base:
- /srv/salt/
My /srv/salt/top.sls file looks like this:
base:
'*':
- vim
Then at /srv/salt/vim/init.sls I have the following:
vim:
pkg.installed
So, that should be applied to all minions when applied, so I run the following:
sudo salt '*' state.apply
I get the following output, and it's not applied, as it seems to not be detecting the top.sls file?
salt-master-1:
----------
ID: states
Function: no.None
Result: False
Comment: No Top file or master_tops data matches found.
Changes:
Summary for salt-master-1
------------
Succeeded: 0
Failed: 1
------------
Total states run: 1
Total run time: 0.000 ms
dev-docker-1:
----------
ID: states
Function: no.None
Result: False
Comment: No Top file or master_tops data matches found.
Changes:
Summary for dev-docker-1
------------
Succeeded: 0
Failed: 1
------------
Total states run: 1
Total run time: 0.000 ms
ERROR: Minions returned with non-zero exit code
If I look at the logs for the minion, dev-docker-1 nothing is logged as an error, all that I see is this.
2018-11-08 18:33:12,993 [salt.minion :1429][INFO ][4883] User sudo_salt Executing command state.apply with jid 20181108183312990343
2018-11-08 18:33:13,015 [salt.minion :1564][INFO ][5438] Starting a new job with PID 5438
2018-11-08 18:33:13,331 [salt.state :933 ][INFO ][5438] Loading fresh modules for state activity
2018-11-08 18:33:13,448 [salt.minion :1863][INFO ][5438] Returning information for job: 20181108183312990343
Any help greatly appreciated as I'm a bit lost as to why this isn't working . . .
Edit 1
I have enabled verbose logging on the minion, and I see the following, seems it can't see the top.sls file
[DEBUG ] Could not find file 'salt://top.sls' in saltenv 'base'
[DEBUG ] No contents loaded for saltenv 'base'
[DEBUG ] No contents found in top file. If this is not expected, verify that the 'file_roots' specified in 'etc/master' are accessible. The 'file_roots' configuration is: {u'base': []}
Ok so I worked this out, operator error.
I had enabled gitfs backend in the config file, which has overridden the default base file system, so I just needed to do.
fileserver_backend:
- gitfs
- base
Doh!
I have a new Debian (9.3) install with new salt-master (2017.7.4) and salt-minion installed. In /etc/salt/minion.d I have a conf file containing:
master: 127.0.0.1
grains:
roles:
- 'introducer'
In /srv/salt/top.sls I have:
base:
# https://docs.saltstack.com/en/latest/ref/states/top.html
'G#roles:introducer':
- 'introducer'
In /srv/pillar/data.sls I have:
introducer:
location: 'tcp:x.x.x.x:y'
port: 'tcp:y'
When I run salt '*' state.apply, I encounter this failure:
668629:
Data failed to compile:
----------
Rendering SLS 'base:introducer' failed: Jinja variable 'salt.pillar object' has no attribute 'introducer'
ERROR: Minions returned with non-zero exit code
Why isn't the pillar data available?
Pillar data requires a top definition as well. The configuration described in the question has no Pillar top.sls so no Pillar data is selected for any of the minions.
To correct this, add a top.sls to the Pillar directory which selects the desired minions and makes the data available to them. For example, this /srv/pillar/top.sls:
base:
'*':
- 'data'
This makes the contents of /srv/pillar/data.sls available to all minions (selected by *) in the base environment.
Here is my /etc/salt/master config:
#GitFS
gitfs_provider: pygit2
gitfs_base: DEVELOPMENT
gitfs_env_whitelist:
- base
fileserver_backend:
- git
gitfs_remotes:
- ssh://git#github.com/myrepo/salt-states.git:
- pubkey: /root/.ssh/my.pub
- privkey: /root/.ssh/my
- mountpoint: salt:///srv/salt/salt-states
Here is my directory structure for the repo:
.
|-- README.md
|-- formulas
| `-- test
| |-- test.sls
`-- top.sls
Here is my very basic top.sls:
base:
'*':
- test
If i try to run highstate on my test node I get:
root#saltmaster:/etc/salt] salt -v '*' state.highstate
Executing job with jid 1234567890
-------------------------------------------
test-minion.domain:
----------
ID: states
Function: no.None
Result: False
Comment: No Top file or external nodes data matches found.
Started:
Duration:
Changes:
Summary for test-minion.domain
------------
Succeeded: 0
Failed: 1
------------
Total states run: 1
Total run time: 0.000 ms
I'm not sure why this isn't working and would appreciate any help with this. I've tried just applying the test.sls to see if it was the top file that was the issue but I got this:
root#saltmaster:/etc/salt] salt -v '*' state.sls test
Executing job with jid 1234567890
-------------------------------------------
test-minion.domain:
Data failed to compile:
----------
No matching sls found for 'test' in env 'base'
I had a similar problem, which was due to the cache being out of sync and not updating. If I tried to run:
salt-run fileserver.update
I got:
[WARNING ] Update lock file is present for gitfs remote 'git#github.com:mention-me/Salt.git', skipping. If this warning persists, it is possible that the update process was interrupted, but the lock could also have been manually set. Removing /var/cache/salt/master/gitfs/7d8d9790a933949777fd5a58284b8850/.git/update.lk or running 'salt-run cache.clear_git_lock gitfs type=update' will allow updates to continue for this remote.
Deleting the cache file specified, and running the above command fixed the problem.
I talked to the folks on the saltstack IRC and someone helped me fix the problem. It seems that adding a mountpoint was screwing everything up. Credit goes to:
12:20] == realname : Thomas Phipps
[12:20] == channels : #salt
[12:20] == server : orwell.freenode.net [NL]
[12:20] == : is using a secure connection
[12:20] == account : whytewolf
[12:20] == End of WHOIS
I installed salt master and minion on my Ubuntu OS. Now i want to install tomcat server using salt master.
How can i install Tomcat server using salt-master
I tried like below
tomcat:
archive:
- extracted
- name: /opt/
- source: http://tomcat.apache.org/download-70.cgi/apache-tomcat-7.0.47.tar.gz
- source_hash: md5=efbae77efad579b655ae175754cad3df
- archive_format: tar
- tar_options: z
- if_missing: /opt/apache-tomcat-7.0.47
getting outout like below
ubuntu:
----------
ID: tomcat
Function: archive.extracted
Name: /opt/
Result: False
Comment: File sum set for file /var/cache/salt/minion/_opt_apache-tomcat-7.0.47.tar of efbae77efad579b655ae175754cad3dd does not match real sum of dbe64e2e9c509f949539b41447a875e5
Changes:
----------
diff:
New file
Summary
------------
Succeeded: 0
Failed: 1
------------
Total: 1
I dont know exactly is this correct way or not
Can any one please help me
The output says it all
ubuntu:
----------
ID: tomcat
Function: archive.extracted
Name: /opt/
Result: False
Comment: File sum set for file /var/cache/salt/minion/_opt_apache-tomcat-7.0.47.tar of efbae77efad579b655ae175754cad3dd does not match real sum of dbe64e2e9c509f949539b41447a875e5
Changes:
----------
diff:
New file
Particularly the message /var/cache/salt/minion/_opt_apache-tomcat-7.0.47.tar of efbae77efad579b655ae175754cad3dd does not match real sum of dbe64e2e9c509f949539b41447a875e5. It says you what http request file cached at /var/cache/salt/minion/_opt_apache-tomcat-7.0.47.tar does not match the checksum you supplied in state metadata.