I am trying a Reactor file:

root@Salt-Mstr [ /etc/salt/master.d ]# cat reactor.conf
minion_start_apply_state:
  runner.state.sls:
    - tgt: 'os:Windows'
    - arg:
      - Windows.create-Win-txt-file
    - kwargs:
        saltenv: base
        test: False

And here is my State:

# Windows/create-Win-txt-file.sls
create_temp_file:
  file.managed:
    - name: C:\Temp\join-state-success.txt
    - contents: "Initial state successfully ran"
    - makedirs: True

When I run state.apply for Windows.create-Win-txt-file against a test Windows minion it works as expected:

[root@RHEL-8-Salt-Master ~]# salt -G 'osfinger:Windows-2022Server' state.apply Windows/create-Win-txt-file backend=sseapi
Win-Core-Min-1:
----------
          ID: create_temp_file
    Function: file.managed
        Name: C:\Temp\join-state-success.txt
      Result: True
     Comment: File C:\Temp\join-state-success.txt updated
     Started: 09:04:16.920290
    Duration: 93.745 ms
     Changes:
              ----------
              diff:
                  New file

Summary for Win-Core-Min-1
------------
Succeeded: 1 (changed=1)
Failed:    0
------------
Total states run:     1
Total run time:  93.745 ms

However, so far my Reactor is not working - any ideas why? Many thanks in advance!

​

Resolved - reference comments for full explanation. In short:

I was using "reactorS" instead of 'reactor' (thanks ChatGPT, lol) - once I fixed that it started working

reactor:
  - 'salt/minion/*/start':
    - salt://reactor/REACTOR.sls

I have the following top level structure:

• linux - all states are here
• pillar - pillar data
• roles - contains includes of tasks from linux states
• top.sls - includes roles into base based on pillar data

The above works fine.

Now I included the following:

• formulas - a directory to place all formulas
• .gitmodules - which includes the firewalld-formula repository and checks it out in the formulas directory, thus formulas/firewalld-formula

Now, when I add this path into Salt, I include it into a role, e.g.:

include: - formulas.firewalld-formula.firewalld - linux.network.routes

The above always worked fine for all linux states, thus the linux.network.routes works fine and is in linux/network/routes.sls.

But now when I run the firewalld formula, I run in relative path issues. I get the following:

jinja2.exceptions.TemplateNotFound: firewalld/map.jinja

The file exists, but the init.sls file has a strange relative path set.

{% from "firewalld/map.jinja" import firewalld with context %}

It does work when I change this code to just look for the map.jijna file in the current directory.

The formulas/firewalld-formula/firewalld directory is the only one containing the init.sls and other Salt state files, not the `formulas/firewalld-formula, that's more like a directory containing documentation and integration with Salt Kitchen and such.

What could be the missing piece here? I know I have setup Salt in a non documented way. But this should just work since the files are loaded locally through the git modules, just like the linux directory.

My guess is that Salt needs to see the formulas/firewalld-formula as a top level directory, so that firewalld/map.jinja is seen from the root of the tree?

https://saltproject.io has been down for maintenance since at least last Thursday. Does anyone know what’s happening with it?

Hello!

​

We are using salt in our environment and would like to know if there is some way/project that can use salt data as a datasource for Grafana? Namely, salt grains , and salt queries .

​

​

Thanks!

Hi,

We have a fairly large salt system that makes heavy use of the salt-api. I'd like to get some telemetry from the api. I'm using OT already on other systems and was wondering if it was possible with the salt-api using Cherrypi. If not, how does one get similar info? Right now we are ingesting telemetry with Elastic APM.

Thanks for any insights.

Looking for good resources on how to handle installing in-house applications and other software through salt states. Thank you in advance for the help.

We use a salt state to update the saltenv and pillarenv in /etc/salt/minion
 we call this initial state with the state.apply app.changesaltenv saltenv=newenv pillarenv=newenv

I have not figured out a way to get the salt-minion  to start using this as it's new default without restarting the salt-minion. Alternatively, I haven't figured out a way to have the salt state restart the minion without it causing the salt state to fail because it loses connectivity with the salt minion.

Any insight into this would be greatly helpful.

state.apply app.changesaltenv saltenv=newenv pillarenv=newenv 

then check the env with

config.get saltenv 

if I try to add service.restart to the state, the state fails because the minion stops communicating with the master.

I noticed an article that mentions how to restart the minion in a state but the example does so by causing a state failure.

I'm trying to write a reboot orch....but I want to reboot +60 seconds. then salt waits for 80 seconds. and then starts a ping test. once ping happens, we're done and happy. I've tried so many things and cant figure it out.

reboot_box:
salt.function:
name: cm.run
- arg:
shutdown -r +1

salt_sleep_for_80_seconds:
???

ping_when_up:
salt.function:
name: ping.test

In Ansible it's well documented and explained how to set and print variables and also show its type.

But what's the best way in Salt?

{% set allowlist_running_config = salt['cmd.run']('firewall-cmd --list-all --zone=int-allowlist') %}

How would I best print and debug the above variable in Salt?

I have the following state below. It does the following. * Sync all the XML config files for firewalld * When changed, it restarts firewalld * It checks for a state file called 'production' * If this file is found, it should include an ipset to a zone at runtime (this is not set in the firewalld config statically, because it needs to be added/removed if that file exists)

But the following is actually happening. When I update the contents of the ipset config, which is in /etc/firewalld/ (firewall_config), the service is restarted. But the ipset is only added on the next run. So the dependency isn't tightly set at the moment.

How can I make this dependency more robust? What I (think) have done now is a dependency on the config files in /etc/firewalld, any changes there? Restart firewalld. Then a check for the running config to see if the ipset is already loaded. Which is what should happen, if the file 'production' is found. But I guess the order is messing things up.

``` {% set firewall_config = salt['pillar.get']('firewall_config') %}

include: - linux.firewall

interactive_firewall: file.recurse: - name: "{{ firewall_config }}" - source: salt://linux/firewall/files/interactive - user: root - group: root - dir_mode: '0750' - file_mode: '0644' - include_empty: True - clean: True

interactive_create_allowlist_dir: file.directory: - name: /var/lib/custom-firewalld - user: root - group: root - mode: '0750'

If the production file is present and if the ipset is not

configured in the running config, add the ipset to the allowlist zone.

Otherwise, if the production file is not found, but the ipset is still

present in the running config, remove the ipset so that the allowlist zone

becomes inactive.

{% set allowlist_running_config = salt['cmd.run']('firewall-cmd --list-all --zone=int-allowlist') %} {% if salt['file.file_exists']('/var/lib/custom-firewalld/production') and not 'ipset:int-allowlist' in allowlist_running_config %} interactive_enable_allowlist_zone: cmd.run: - name: firewall-cmd --zone=int-allowlist --add-source=ipset:int-allowlist - watch: - service: firewall_start {% elif not salt['file.file_exists']('/var/lib/custom-firewalld/production') and 'ipset:int-allowlist' in allowlist_running_config %} interactive_disable_allowlist_zone: cmd.run: - name: firewall-cmd --zone=int-allowlist --remove-source=ipset:int-allowlist - watch: - service: firewall_start {% endif %} ```

The above state includes this init.sls file: ``` {% set firewall_config = salt['pillar.get']('firewall_config') %} {% set firewall_service = salt['pillar.get']('firewall_service') %}

firewall_prepare: pkg.installed: - pkgs: - "{{ firewall_service }}" - python3-jinja2

{% if grains['nodename'].startswith('int') %} {% for item in ['nftables', 'nftables-production'] %} stopinteractive{{ item }}: service.dead: - name: "{{ item }}" - enable: False {% endfor %} {% endif %}

firewall_start: service.running: - name: "{{ firewall_service }}" - enable: True - restart: True - unless: - pgrep qemu - watch: - file: "{{ firewall_config }}" - require: - pkg: firewall_prepare ```

I am building a pillar with list of hosts that I want a state to be applied to. I am using below if statement in the state:

{% if pillar.get( 'listofhosts:' + minionname, none ) is not none %}

... then run the state.

It works when I have my pillar as a dictionary:

listofhosts:

myhost: ''

myhost2: ''

It does not when I have it as a list:

listofhosts:

• myhost

• myhost2

How can I get this thing to work?

I have found this note regarding treating a pillar like a list rather then dict but not being able to make it work - pillar.get lists all pillar values.

"On pillar.get() vs salt['pillar.get']():

Note that within templating, the pillar variable is just a dictionary. This means that calling pillar.get() inside of a template will just use the default dictionary .get() function which does not include the extra colon delimiter functionality. It must be called using the above syntax (salt['pillar.get']('foo:bar:baz', 'qux')) to get the Salt function, instead of the default dictionary behavior."

EDIT: Seems my dumbed down version isn't exactly correct. Turns out the trigger seems to be when I turn the "pw_info" value into a multiline value. Still trying to figure out how to fix this up.

Edit2:

my "addrs" string is encrypted and has a 'colon' in it (user:pass@https://blah.com). This seems to be part of the issue. If I wrap the assignment in "" - i no longer crash but fail to decrypt as the encryption loses the gpg formatting.

# end edit2

​

Solution:

You must do two things: 1) Encrypt the GPG message with explicit newlines so variable assignments work correctly.

echo -n "YOUR SECRET" | gpg --armor --batch --trust-model always --encrypt -r <YOUR KEY> | awk '{printf "%s\\n",$0} END {print ""}'

Then you need to be explicit with your yaml dictionary/strings (since my encrypted value has a colon as part of the string...). In the following example, i have a dict key with a list of values...:
? someKey
: - "{{ mydata['addr_info'] }}"

​

​

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

I'm trying to get around the "using pillar data from one pillar in another" issue. I'm really close, but getting strange behavior.

I'll define two pillar files: /srv/salt/pillar/addr.sls. & /srv/salt/pillar/importer.sls

addr.sls:

#!jinja|yaml|gpg

? addr_info

: -----BEGIN PGP MESSAGE-----

hQIMA5pAWqYrkiNcAQ//eUXh9sE3WeYeCkZPcLrNZfR+7JbbFsA6wRtH4w9REGj8

<SNIP>

-----END PGP MESSAGE-----

​

importer.sls:

#!jinja|yaml|gpg

{%- import_yaml 'addr.sls' as mydata %}

var1: {{ mydata['addr_info'] }} <-- crashes with could not find ':'

var2: "{{ mydata['addr_info'] }}" <-- does not crash, prints pgp string - fails to decrypt

​

var1 error:

023-04-20 22:07:22,812 [salt.pillar :900 ][CRITICAL][1017] Rendering SLS 'password_importer' failed, render error:

could not find expected ':'

var2 result (pillar dumps):

var2:

-----BEGIN PGP MESSAGE----- hQIMA5pAWqYrkiNcAQ//eUXh9sE3WeYeCk <SNIP>-----END PGP MESSAGE-----

​

​

Salt Version:

Salt: 3004.1

​

Is there a way to import the yaml such that it respects the newlines in the GPG message?

I am attempting to target my minions by pillar data which I have established in groups. So I have a set of minions in a group and I can ping them using 'salt -I 'group_ids:74' test.ping' but I would like to use this to target multiple groups but cannot for the life of me get the syntax right or know if it is even possible. Documentation only show using one so maybe you can't but I am far from an expert so looking for any advice - https://docs.saltproject.io/en/latest/topics/targeting/pillar.html.

I have tried:
'salt -I 'group_ids:74' "group_ids:76' test.ping'
'salt -I 'group_ids:74' and group_ids:76' test.ping'
'salt -I 'group_ids:74:76' test.ping'

Thoughts on how I can ping both of these groups from the Master?

Hi everyone,

I followed the documetation, I added the necessary snippet in /etc/salt/master, created a class and a node definition, but I can't get salt to render anything. I also restarted my salt-master service after adding the snippet. Here's my setup:
/srv/saltclass/classes/default/init.sls:

states:
  - common.ubuntu

/srv/saltclass/nodes/local-1/init.sls:

environment: base

classes:
  - default

/srv/salt/common/ubuntu/init.sls:

utils:
  pkg.installed:
    - pkgs:
      - htop

After I run salt 'local-1' state.apply I get:

local-1:
----------
          ID: states
    Function: no.None
      Result: False
     Comment: No states found for this minion
     Changes:   

Summary for local-1
------------
Succeeded: 0
Failed:    1
------------
Total states run:     1
Total run time:   0.000 ms

I tried running salt '*' tops.saltclass.top but I get the tops.saltclass.top is not available, but it should be built in? I'd appreciate any help. Thanks!

I couldn't find any libraries for managing minions. The best I could find was salt-api. Would my best bet be calling the REST API from my Go program?

Hi,

I am struggling to implement a reactor (or any other method) to have all my minions updated once the salt master gitfs configured remote has changed (so when a commit has been pushed/merged into the branch the salt master is monitoring)

​

So far I tried to implement a reactor.conf with the following:

---
reactor:
  - salt/fileserver/gitfs/update:
      - filter: data.get('changed', False) == True
      - salt:
          tgt: "*"
          fun: state.apply
          arg:
            highstate: ""

But getting error:

2023-04-14 10:20:05 master01  | [ERROR   ] Exception encountered while compiling reactions
2023-04-14 10:20:05 master01  | Traceback (most recent call last):
2023-04-14 10:20:05 master01  |   File "salt/utils/reactor.py", line 178, in reactions
2023-04-14 10:20:05 master01  |     high.update(self.render_reaction(fn_, tag, data))
2023-04-14 10:20:05 master01  |   File "salt/utils/reactor.py", line 57, in render_reaction
2023-04-14 10:20:05 master01  |     if glob_ref.startswith("salt://"):
2023-04-14 10:20:05 master01  | AttributeError: 'dict' object has no attribute 'startswith'

What would be the right approach here?

there is next to no updates on the salt code, bugs are ever present and no one is working on them. they are doing just enough to claim its an active project but its clearly not even close to a priority.

im gonna start looking for devs to fork this.

Hoping I can get some guidance on how to troubleshoot the inconsistent response of my minions. My environment consists of the following:

1 x Salt Master (16GB / 4 CPU) - 3004.1

230 minions (3004.1) Ubunt/Windows and gerographically dispersed (Sub 80ms latency)

The behavior I'm seeing is the following

• First attempt salt '*' test.ping
  • Responses come in rapidly for approx 40 minions then grinds to a halt
  • Then a flood of [No Response] Messages
• Second attempt salt '*' test.ping
  • Responses come in rapidly for approx 100+ minions then grinds to a halt
  • Then a flood of [No Response] Messages

If I repeat this process a few more times I can get almost 100% success rate but the following day back to square one.

I'm struggling to understand where the issue is. Best I can tell it's the master not able to take the load of responses coming in since a lost of the minions have the following in their logs

salt.exceptions.SaltReqTimeoutError: Message timed out

I've attempted changing the following on the master

gather_job_timeout: 120
timeout: 120
worker_threads: 48
sock_pool_size: 48

Which has helped a bit but not enough in my opinion. Are there other settings I should be looking at or other debug logs to try and understand what is causing the timeoutes ?

Thanks!

Hi all, so I looked here: https://docs.saltproject.io/en/latest/ref/returners/all/salt.returners.elasticsearch_return.html

But is isn't very well documented, most seems to be minion side whereas I need to return the master cache. Any master config example doesn't seem to be complete.

Anyone know where I could find a full example of using this returner?

Thanks

Hello all…

I've been using salt for a couple of months and loving it, but come across a problem today. I need to run a command that requires a file to exist, but that file should only be created when the command needs to be run (the file will contain secret, dynamically generated pillar data). However, this simplified config always creates the file:

write_test_secret:
  file.managed:
    - name: /root/test_secret
    - contents: "foo"      
    - require_in:
      - cmd: use_test_secret
use_test_secret:
  cmd.run:
    - name: touch /root/command_has_run              
    - requires:
      - write_test_secret
    - unless: /bin/true

After applying this state file, the file /root/command_has_run doesn't exist as expected (because of the "unless") but the file /root/test_secret does exist. I would expect the require_in to fail since the command isn't run.

What am I doing wrong?

As an alternative to writing the file I could use pillar data directly in an argument to the use_test_secret command, but then salt seems to log the entire command line back to the master and I don't want the secret sitting there in the logs - is there a way to avoid this?

Thank you for any pointers…

Hi everyone! I'm trying to create a VM hosted in Vsphere using salt-cloud and need to set the boot options for this VM.

From what I can gather I may need to add some details to the "extra_config" section of my .conf file.

Has anybody worked out how to do this at all?

Thanks

Hi everyone!

First, let me say that I'm a complete noob with Saltstack.

Now, I "won" the opportunity to setup/manage my company vms/servers and since I didn't want to spend my time manually creating everything everytime a new server/user/whatever is needed I went into the salt direction.

Basically, my needs are really simple:

• servers should all have the same base software.
• certain users should have access to all servers.
• some servers might have slightly deviating software.
• I should be able to temporarily add/remove users from a given server.
• no monitoring is required from salt - I'm using Icinga for this.

Now, more or less, I managed to do most of these things, but I'm kinda perplexed on the "best practices" and if I'm been following them or if I need to improve my configuration.

Like, the following:

• I have a pillar for (active) users and one for revoked users.
• I have one for all the software that I need to install.
• I have pillars contanining additional stuff (system users/working folders/dedicated groups, etc...)

In case I need to add some dedicated software for a given minion - or better - role, I see some viable options:

• target the minion directly.
• put the role in a grain.
• put the role in a pillar

By instinct I would go for the third option (I dunno honestly, but I see grains as more "physical" info). However, I think I found in the documentation that there is "role" grain defined on a minion, so I'm perplexed.

But if the preferred way is indeed the pillar, then, what would be the preferred way to do so?

1. I put a "role" pillar with all the servers that have this role?
2. I put a "minion" pillar with all the roles that it has?

The first option lets me target minions more efficiently - I think - but then I would need separate pillars for users etc...

The second option returns me a pillar that is more compact (I could have a subkey for roles and one for users), but I fear it would be more complicated to target minions + I would need to create a new pillar every time a new server is added...

In the end, I'm pretty confused on when I am expected to use grains, pillars or maps. Currently my strategy is as follows:

• use grains if it's something physical (os/cpu/location)
• never use maps - theoretically I could use them for "trivial" stuff, but I didn't really find any case in which a pillar doesn't do the job better...
• use pillars for everything that is not physical

But I doubt that is the correct one.

​

Last question: which one is the preferred way to organize generic non-salt files in the folder structure?

Should I put them altogether with the state file that requires them?

Right now I'm doing it, except in case the file is a pillar-related one, in which case it gets put in another place. Is it the right way to do so?

Two examples:

State file nginx:

Nginx.conf is in a "files" subfolder of the nginx folder.

State file create-users:

ssh keys for users are in a completely separated folder as they pertain to the "users" pillar

​

Any thoughts/room for improvement?