Hot answers tagged

9

Check out the slsutil.renderer module. This should do what you want salt my-minion-id slsutil.renderer /srv/salt/network/init.sls 'jinja' This module just calls the compile_template function directly for you. Edit: /srv/salt/network/init.sls is the path on the minion, if you are not targeting the master as your minion, you will probably need to do the ...


7

Given how much time I spent weeks ago struggling with a closely-related issue, I wish I'd figured this out sooner. The solution appears to be to use salt.modules.cp.get_template to have the Salt minion retrieve the file, render it through the templating engine and place it in a readable place: # salt my-minion-id cp.get_template salt://network/init.sls /...


6

It's a bit hacky, but you can always do something like: check_process: cmd.run: name: ps aux | grep '[f]oobar' The exit code will be non-0 and the state will fail if foobar doesn't exist.


5

This turns out to be a known issue: The require_in requisite does not support everything that require does, mainly id does not support sls or state_id without specifying a state module. So by modifying our SLS file to include the state module (specifying file: /root/b as the require_in target instead of simply /root/b), we get the correct result. I don'...


4

This templated SLS file works splendidly: {% if 'components' in salt.pillar.items() %} include: {% for component in salt.pillar.get('components').keys() %} - {{ component }} {% endfor %} {% endif %} However, it requires changing my pillar key structure. From the original question, you see the structure as: my-minion-id: ---------- components: ...


4

You can only insert the return into the mine. Just specify the cmd.run (or possibly cmd.script) in your mine_functions and you will get the whole return back. If you want to have a script that sets up extra config on the minion, I would recommend writing a custom grain. https://docs.saltstack.com/en/latest/topics/grains/#writing-grains


3

Globbing is a term used for matching file name patterns with wild cards. You can see a more detailed definition here https://searchsecurity.techtarget.com/definition/globbing As it relates to Salt Stack, it's finding the minion id using wild cards. Additional details here: https://docs.saltstack.com/en/latest/topics/targeting/globbing.html


3

You can also do it like: {% if pillar['components'] is defined %} include: {% for component in pillar['components'] %} - {{ component }} {% endfor %} {% endif %} {% if pillar['components'] is defined %} components: require: {% for component in pillar['components'] %} - {{ component }} {% endfor %} {% endif %}


3

SaltStack provides a method for modifying grains and adding additional information to the grains dictionary in several different ways by either setting them in the /etc/salt/minion config and/or through the /etc/salt/grains file. For example: 1. add grains to the minion config. Note, simply include the grains key here: id: minion-07 grains: roles: - ...


3

The answer is that you can't directly. You have to set a grain on the minions first by doing something similar to: salt '*' cmd.run 'grep environment /etc/salt/minion | awk "{print \"environment: \" \$2}" >> /etc/salt/grains' salt '*' saltutil.sync_grains salt -G environment:prod cmd.run 'df -h'


3

There is currently one safe way to do this. You can use {{opts.id}} as an explicit way to grab the minion ID. opts is technically an implementation detail; the opts dictionary is a Salt internal structure that doesn't appear to be formally specified. Its candidacy for the purpose was pointed out to me in a bug comment. In the next version of Salt (so, ...


2

State and pillar environments are set independently. Specifing environment: prod in the minion configuration will force the minion to use the prod state, but it will still use the default pillar data. To select a pillar environment you will also need: pillarenv: prod This also does not work in old versions of salt and is only supported with pillar.get ...


2

When I encountered a related problem, I wound up having Jinja run execute Salt modules. In my case, it was cmd.run to run mktmp (and, at the end of the template, rm for cleanup), with file.append and file.grep, though in your case, you might be able to use Salt's load_yaml extension to Jinja. So, something like this (rough, untested): {% set tmpfile = ...


2

I have found the answer to my own question after some more investigation. The reason the state was skipping the contents of my if statement was because the hostname of the server was in lower-case (god knows why). Therefore the in-built salt grains.item host which is called upon didn't recognise the server I was specifying.


2

You can have more than if statement per state. The issue is that your conditional doesn't seem actually be checking the hostname, it's just passing everything. Try this: {% if grains['host'] in ['dev-server2', 'test-server2'] %}


2

A capture group is a type of backreference. Saltstack, being python based, uses the re.match object to do regular expression matching, which appears to support backreferences, so these backreferences are allowed. However, you be unable to pass the value of the backreference \1 in the - include_pat field back to - name because the - name field is never ...


2

This question seems similar to another on StackOverflow, but seems to be a close, but not exact duplicate of https://stackoverflow.com/questions/37018509/jenkinsfile-build-log To quote those : if you just want to check, that your log contains string myTestString you can just call manager.logContains('.myTestString.') If you want to get some ...


2

There are currently 5 dunder dictionaries. They are available at runtime and generally not stored statically. __opts__ - Master or Minion configuration options; stored in configuration files of master and minion, collected at startup __salt__ - Execution module functions (i.e. __salt__['test.echo']('foo')); from built-in and custom execution modules ...


1

Please follow official doc to create LB Please create a IAM role or mentioned secret and access key as below elb.keyid: HHTYHLSHDJFJFJFJFJFJFFSVJS elb.key: basjbsdfbdsfdsjfbkgbsfbdsjfbfdgdfgdfs Then Create config for ELB Ensure myelb ELB exists: boto_elb.present: - name: myelb - region: us-east-1 - availability_zones: ...


1

There is no much choices regarding your situation, I see two of them : You ask your dev dpt to add your jinja templating to their builds (which may be hard or even impossible) You can use salt module such as file.append or file.replace to add / replace your jinja code inside (this is not very clean that's the least we can say) If you'd share an example ...


1

I was able to find the root of issue. The problem was in the configuration of salt master. After every change of reactor config, I must run salt-call state.highstate command on master to sync reactor source code changes with it. I missed this step and thus my reactor config differed from my original source code in IDE. So once I ran mentioned command, ...


1

Yes - there are at least two options available for managing files in the manner you describe. The first such way is to manage the entire directory using file.directory: /opt/apiv2: file.directory: - user: root - group: root - dir_mode: 755 - file_mode: 644 - recurse: - user - group - mode The second way can manage a ...


1

You aren't actually using file.managed, you are using file.append - so salt is expecting to add onto the end of an existing file. This may be the cause of your issue. Instead try: /home/vagrant/.bash_profile: file.managed: - name: /home/vagrant/.bash_profile - source: salt://config/user/.bash_profile - mode: 0775 - user: vagrant - ...


Only top voted, non community-wiki answers of a minimum length are eligible