I create a user foo on a minion. The minion evalutes /etc/default/useradd. This means the salt master does not know whether the new $HOME will be /home/foo or in our case /localhome/foo.
How can I get the $HOME of user foo as jinia variable?
I need it in a systemd service file.
I would like to avoid custom pillar data, since this is redundant. Is there a way to get it via grains?
Does it work during boostrapping? First the user foo needs to be created, then the systemd file can be created by looking up the $HOME of foo...
This would work if the user does already exist:
{{ salt['user.info'](user).get('home') }}/foo:
file.recurse:
- source: salt://conf/common/foo
Related issue: https://github.com/saltstack/salt/issues/7883
Answer this question:
Is there a way to get it via grains?
1) add file '_grains/homeprefix.py' under the file_roots specified by the master config file, the content of which is :
#!/usr/bin/env python
from os.path import dirname, expanduser
def gethomeprefix():
# initialize a grains dictionary
grains = {}
# Some code for logic that sets grains like
grains['homeprefix'] = dirname(expanduser("~"))
return grains
2) run sync cmd on master to sync grains info to minion :
salt '*' saltutil.sync_grains
3) run grains.get on master to test :
salt '*' grains.get homeprefix
Related
I have a simple saltstate. My question is using jinja or whatever else, how can I specify it or steps of it to run only if inventory name contains some string?
Where I can check all the saltstack variables documentation btw?
I think you want to target minions by grains. Salt have many grains set by default, but you can add your own grain. After adding you own "inventory" grain, you can target the minion in the top file.
Check all grains of a minion: salt "minion" grains.items
Set your own grain: salt "minion" grains.set inventory inventory_num
Target minion by new grain: salt -G "inventory:inventory_num" test.ping
Further information:
https://docs.saltproject.io/en/latest/ref/modules/all/salt.modules.grains.html#salt.modules.grains.set
https://docs.saltproject.io/en/latest/topics/targeting/index.html
https://docs.saltproject.io/en/latest/topics/grains/index.html
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....
Can I set relayhost = [1.2.3.4] in /etc/postfix/main.cf via a salt sls file equivalent to the salt command below?
salt 'mymachine.*' postfix.set_main relayhost "[1.2.3.4]"
If so what would the sls file contents be?
I don't believe there's a built-in state for this. Though you may want to use postfix-formula . Salt-formulas are explained in a doc
After installing a formula you will be able to set a relayhost from pillar. Example Salt top.sls:
base:
'*':
- postfix
- postfix.config
Please note postfix.config state that actually manages the configuration files.
Pillar will look as follows:
postfix:
config:
relayhost: "[1.2.3.4]"
I need to read the host entries from pillar file and update the /etc/hosts file accordingly
This is my simple sls file to update the /etc/hosts file.
#/srv/salt/splunk_dep/hosts.sls
dnsutil:
dnsutil.hosts-append:
- hostsfile: '/etc/hosts'
- ip_addr: '10.10.10.10'
- entries: 'hostname'
when i execute the sls file
salt Minion-name state.apply splunk_dep/hosts
Getting the following error
ID: dnsutil
Function: dnsutil.hosts-append
Result: False
Comment: State 'dnsutil.hosts-append' was not found in SLS 'splunk_dep/hosts'
Reason: 'dnsutil.hosts-append' is not available.
Started:
Duration:
Changes:
If i execute through command line its working fine
salt 'DS-110' dnsutil.hosts_append /etc/hosts 10.10.10.10 hostname
I need to update the /etc/hosts file through sls file. Can someone please help me on this.
I am using the salt version : salt 2015.8.3 (Beryllium)
dnsutil is a Salt module, and not a Salt state. Therefore it can be used from the command line, but not directly via SLS state file.
To run modules from state file you'll need module.run. Please note that in this case you'll need to put an underscore in hosts_append, not a hyphen.
dnsutil:
module.run:
- name: dnsutil.hosts_append
- hostsfile: '/etc/hosts'
- ip_addr: '10.10.10.10'
- entries: 'hostname'
Some caveats with modules: even if they don't change your system, they will be reported as "changed" in the summary of your salt call. Please consider using file.blockreplace for managing hosts file instead to avoid this.
Using the Salt python client API, is there a way to copy files from the master to minion without using Salt File Server?
I don't want to use the cp module or source salt://.
You could create salt state to do this:
Contents of /srv/salt/copyfiles.sls:
copy_my_files:
file.recurse:
- source: salt://DIR_TO_COPY
- target: /home/DESTINATION_DIR
- makedirs: True
Then run salt \* state.sls copyfiles
or
ret = local.cmd('*', 'state.sls', ['copyfiles', ])
print json.dumps(ret, indent=2)
Test the syntax of the local.cmd above. I haven't tried it on my system, but it should be similar to that.
Use a different fileserver backend.