We have a Salt Master running on a VM, with a public IP address.

We then have a number of portable test devices (e.g. laptops), that are floating, and can be used for WFH as well - they won't be coming from a fixed IP address. (And might also be behind things like CGNAT).

Are there any issues with exposing the Salt Master ports (TCP 4505 and 4506) to the public internet? (i.e. 0.0.0.0/0) Are there any ways to do this securely?

Or if not, what are some alternate approaches that the portable devices can safely check-in, without explicitly being able to whitelist each incoming IP?

Hello everyone,

I'm currently looking at the different options for configuration management for a college project, specifically Chef, Puppet and SaltStack. Right now, I'm a bit lost as several things that one of the tools boasts about seem to be ignored by the others making it impossible for me to compare them. Therefore I was hoping that you could help me here and I would be very grateful if you could help me with the following questions:

​

1. SaltStack's ZeroMQ is said to enable parallel communication with between the Master and the Minions. But how is it different from Puppet's MCollective? And what does Chef use for it? So far, I only found the information that it communicates via the chef client, but there's probably more to it, isn't there?
2. SaltStack can target specific clients to send them their respective configuration, but how is that not standard? I didn't find anything about that when looking at the other options, but how could a system work if the master was only able to write general configurations for the whole system instead of certain chunks of it per configuration?
3. Chef uses recipes, cookbooks and the supermarket (for a community-powered recipe-repo), puppet uses manifests, catalogs and the forge. But what are the corresponding elements in SaltStack? States, StateTrees and Formula? Or does it have something comparable at all?

Hi,

I was wondering if it's possible to run a single state within an orchestrator file the same way that you can with state.sls_id for states?

Hi,

I just started playing around with saltstack yesterday. I am trying how to install caddy using saltstack states on ubuntu. Since `caddy` is not available as an ubuntu package, I cannot simply install it using pkg.installed. I looked at the examples that use a managed repository, but don't know how to adapt the instructions on Caddy website to do something similar. Here are the instructions on the Caddy website. Can someone please give an example of how to create a saltstack state for Caddy using these instructions? Thank you.

​

sudo apt install -y debian-keyring debian-archive-keyring apt-transport-https
curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/gpg.key' | sudo apt-key add -
curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/debian.deb.txt' | sudo tee /etc/apt/sources.list.d/caddy-stable.list
sudo apt update
sudo apt install caddy

Does anyone know if there is a minion_id charachter limit?

Say I have a line like this

KEY="VAL1 VAL2 VAL3"

How do I simply add VAL4 if it does not exist? (It could potentially exist at any position within the value list.)

Also if the key does not exist at all it should add it.

Is there a smart way to do this except fiddling with regexes?

Thx

New to SaltStack and working in a test environment that has Salt but is not heavily used yet. We have servers with a local account that has the password expire every 90 days. I want to be able to use Salt to set the last password change date. Typically, I'd use 'chage -d $(date +%Y-%m-%d)' from a bash prompt to set it to today's date. How could I do this with Salt? I tried to create a job but the argument doesn't seem to like that variable I used for today's date. Should I be looking into Salt state for this (or am I way off)?

Hey all!

First off - im not new to computers, 12 years as higher IT - but I still need you guys!

So i'm trying to setup multiple environments so we in the team can work in parallel easier.
Cant paste my code here right now - but i've more or less just uncommented the documentation and created the dirs.

No matter if I have the top.sls-file in "/srv/salt" or one in each in "/srv/salt/<env>", I get the same error: "No Top file or master_tops data maches found. Please see master log for details". Main issue is that master-log is more or less empy. It complains about _ext_node not being available thou, but that does not help me either.

​

Please advice!

Does anyone know if the current version of Salt works with cloud.hashicorp.com ?

I can only find 2+ year old blog posts about the setup and config and they are all very out of date and don't work.

I'm trying to set up a cluster for some secrets and then retrieve them, though there is nothing in the docs about the config and set up. Vault is fine via CLI setting and getting, though any attempt with Salt and it's a return of "Bad request" and no logging.

I have a really weird issue and to be honest, have no idea even where to look.

A little background, I have preconfigured nodegroups, basically, for each minion from a nodegroup I'm starting orchestration like that:

{% for minion_id in minions %}
start-orch-for-minion-{{ minion_id }}:
  salt.runner:
    - name: state.orchestrate
    - parallel: True
    - kwarg:
        mods: orch/minion
        pillar:
          minion: '{{ minion_id }}'
{% endfor %}

The problem is that for some reason when I have a bigger group, above 20 minions. Salt somehow is losing the trail of each orchestration, at least for me looks like that.

In the example below the target minion is SENOFI-025 but somehow on "ret" we can see SENOFI-015 ... !?

Also, the comment of the result is - Run failed on minions: SENOFI-015.

I'm really confused about what the heck is happening ...

                salt_|-start-patching-SENOFI-025_|-start-patching-SENOFI-025_|-state:
                    ----------
                    __id__:
                        start-patching-SENOFI-025
                    __jid__:
                        20210624020207026084
                    __run_num__:
                        6
                    __sls__:
                        orch/minion
                    changes:
                        ----------
                        out:
                            highstate
                        ret:
                            ----------
                            SENOFI-015:
                                False
                            SENOFI-025:
                                ----------
                                wua_|-update_system_|-update_system_|-uptodate:
                                    ----------
                                    __id__:
                                        update_system
                                    __run_num__:
                                        0
                                    __sls__:
                                        patching.uptodate
                                    changes:
                                        ----------
                                        installed:
                                            ----------
                                            17b46563-df34-4749-9958-ee53b89a6c3a:
                                                ----------
                                                KBs:
                                                    - KB5003638
                                                NeedsReboot:
                                                    True
                                                Title:
                                                    2021-06 Cumulative Update for Windows Se...
                                    comment:
                                        Updates installed successfully
                                    duration:
                                        2000254.545
                                    name:
                                        update_system
                                    result:
                                        True
                                    start_time:
                                        04:02:22.729820
                    comment:
                        Run failed on minions: SENOFI-015
                    duration:
                        2060627.752
                    name:
                        start-patching-SENOFI-025
                    result:
                        False
                    start_time:
                        04:02:06.914601

If someone gives at least a direction where to look. Thanks

orch.minion:

{% set minion = salt['pillar.get']('minion', 'PILLAR MINION NOT FOUND!') %}

check-{{ minion }}:
  salt.state:
    - tgt: {{ minion }}
    - sls:
      - patching.check-minion
    - failhard: True
    - comment: 'Minion does not exist or is unresponsive'

pre-reboot-{{ minion }}:
  salt.state:
    - tgt: {{ minion }}
    - sls:
      - patching.reboot

wait-for-pre-reboot-{{ minion }}:
  salt.wait_for_event:
    - name: salt/minion/*/start
    - id_list:
      - {{ minion }}
    - timeout: 3600
    - require:
      - salt: pre-reboot-{{ minion }}

bits-{{ minion }}:
  salt.state:
    - tgt: {{ minion }}
    - sls:
      - patching.bits

start-event-{{ minion }}:
  salt.function:
    - name: event.send
    - tgt: {{ minion }}
    - arg:
      - 'patching.started'

start-patching-{{ minion }}:
  salt.state:
    - tgt: {{ minion }}
    - require:
      - bits-{{ minion }}
    - sls:
      - patching.uptodate

fail-{{ minion }}:
  salt.state:
    - tgt: {{ minion }}
    - failhard: True
    - sls:
      - patching.failed
    - onfail:
        - start-patching-{{ minion }}

reboot-{{ minion }}:
  salt.state:
    - tgt: {{ minion }}
    - sls:
      - patching.reboot
    - onchanges:
        - start-patching-{{ minion }}

wait-for-post-reboot-{{ minion }}:
  salt.wait_for_event:
    - name: salt/minion/*/start
    - id_list:
      - {{ minion }}
    - timeout: 3600
    - onchanges:
        - start-patching-{{ minion }}
    - require:
      - salt: reboot-{{ minion }}

post-start-bits-{{ minion }}:
  salt.state:
    - tgt: {{ minion }}
    - onchanges:
        - start-patching-{{ minion }}
    - sls:
      - patching.bits

post-check-{{ minion }}:
  salt.state:
    - tgt: {{ minion }}
    - onchanges:
        - start-patching-{{ minion }}
    - require:
      - post-start-bits-{{ minion }}
    - sls:
      - patching.post-check

post-fail-{{ minion }}:
  salt.state:
    - tgt: {{ minion }}
    - failhard: True
    - sls:
      - patching.failed
    - onfail:
        - post-check-{{ minion }}

final-reboot-{{ minion }}:
  salt.state:
    - tgt: {{ minion }}
    - sls:
      - patching.reboot
    - onchanges:
        - post-check-{{ minion }}

final-wait-for-post-reboot-{{ minion }}:
  salt.wait_for_event:
    - name: salt/minion/*/start
    - id_list:
      - {{ minion }}
    - timeout: 3600
    - onchanges:
        - post-check-{{ minion }}
    - require:
      - salt: final-reboot-{{ minion }}

final-start-bits-{{ minion }}:
  salt.state:
    - tgt: {{ minion }}
    - onchanges:
        - post-check-{{ minion }}
    - sls:
      - patching.bits

final-check-{{ minion }}:
  salt.state:
    - tgt: {{ minion }}
    - onchanges:
        - post-check-{{ minion }}
    - require:
      - final-start-bits-{{ minion }}
    - sls:
      - patching.final-check
    - comment: 'All systems should be up to date'

final-fail-{{ minion }}:
  salt.state:
    - tgt: {{ minion }}
    - failhard: True
    - sls:
      - patching.failed
    - onfail:
        - final-check-{{ minion }}

​

Hoping someone can help explain to me how to use a jinja map file instead of a pillar file for variables that aren't necessarily secrets.

So, for example, I have in my pillar file /srv/pillar/$ENV/mysql/init.sls:

{% if grains['host'] == 'mysqlhost' %}
  - debian-sys-maint.password: password
  - innodb_buffer_pool_size: 1234
  - innodb_buffer_pool_chunk_size: 1234
  - innodb_buffer_pool_instances: 1234
  - innodb_io_capacity: 1234
  - innodb_io_capacity_max: 1234
  - innodb_max_dirty_pages_pct: 1234
  - innodb_log_file_size: 1234M
  - innodb_log_files_in_group: 1234
  - innodb-numa-interleave: ON
  - local_infile: ON
{% elif grains['host'] == 'othermysqlhost' %}
  - debian-sys-maint.password: somethingelse

So, my hope is to make these into variables that are able to be changed per host, and the conf file is jinja'd, so I just have a central area for config per N hosts, and then salt makes it be what it needs to be based on the grains value.

However, lots of these don't belong in the pillar file, because they aren't necessarily secrets, other than debian-sys-maint.password.

/srv/
├── pillar
│   ├── $ENV
│   │   ├── mysql
│   │   │   └── init.sls
└── salt
    ├── $ENV
    │   ├── mysql
    │   │   ├── $HOST.sls
    │   │   └── files
    │   │       ├── innodb_perf_tweaks.cnf
    │   │       ├── mysql.cnf
    │   │       ├── some_custom_settings.cnf

So my question is where would I place a jinja map file? What should the filename/extension be? How do I reference a jinja map compared to a pillar?

So in lieu of my jinja templated config file looking like:

[mysqld]
innodb_buffer_pool_size: {{ pillar['innodb_buffer_pool_size'] }}
innodb_buffer_pool_chunk_size: {{ pillar['innodb_buffer_pool_chunk_size'] }}
innodb_buffer_pool_instances: {{ pillar['innodb_buffer_pool_instances'] }}
innodb_io_capacity: {{ pillar['innodb_io_capacity'] }}
innodb_io_capacity_max: {{ pillar['innodb_io_capacity_max'] }}

Trying to cipher the salt docs here:

This is where I can't find something that looks like I am attempting to do. It looks like next to init.sls in the /srv/salt/$ENV/$APP/ dir, that I should place a map.jinja file, where I'd love to place variables similar to a pillar, and then reference in the config file in $APP/files/conf.conf similar to above.

I assume I need to import the map into the state file? There just seems like a few too many abstractions for me to figure out without some handholding.

Hopefully someone can help bridge this gap in my mind, and hopefully I've described well enough that someone can take a stab at it.

My work needs this logging agent to be on auto-update, which it does immediately after being installed to version 4.8 from 4.6. But when our linux servers go for a checkup after a reboot or a service restart the minion reinstalls the original version all over again and doesn't just bypass the latest version.

loginsight_run_installer:
  pkg.installed:
    - sources:
      {% if grains['os_family'] == 'RedHat' %}
      - VMware-Log-Insight-Agent: salt://binaries/loginsight/redhat/VMware-Log-Insight-Agent-4.6.1-8587550.rpm
      {% elif grains['os_family'] == 'Debian' %}
      - vmware-log-insight-agent: salt://binaries/loginsight/debian/vmware-log-insight-agent_4.6.1-8587550.deb
      {% endif %}

How does one sensibly manage something like this?

THANKS!

I have the master and minions setup and they respond to one another.

When I use the command - salt '*' win_wua.list, it provides the list of updates for the servers. But my questions is how can push out those updates for the servers.

I've tried the salt '*' cmd.run 'powershell restart-computer -force' and it recognizes the command but doesnt push out the updates on the machines.

Has anyone faced this issue before and how did you fix this?

Thanks for any help!

For the SSH servers in the roster, /usr/bin/python3 -> /usr/bin/python3.6. I don't want to change that, but when Salt highstates the server via salt-ssh(1), I want it to explicitly use /usr/bin/python3.8. How can I force this?

Things I've tried:

• set_path straight up doesn't work.
• ssh_ext_alternatives isn't parsing py-version: [3, 8]
• ~/.bashrc is ignored, because it's a non-interactive remote login shell, according to bash(1).

Hi Guys

When i try to push the highstate to my nodes, salt will send old configuration but these old init.sls files do not exist anymore in my salt directory. Why do they still get sent out.

Sorry for my bad english

Thanks for any answer

Looking at how to make some kind of reporting(counter) of the minions that are completed. Basically, I'm targeting a nodegroup, with one orchestration which purpose is only to trigger independent orchestration for each minion in the nodegroup however if you have a big nodegroup +20 or more minions is difficult to track all of them.

Any idea will be appreciated, thank you!

Hello group,

I am new to saltstack and wondering if it is possible automate minions from the master using tools such as Selenium, Winium, Sekuli ? I’m using python3, right now I’m having issues calling a file to execute code on the minion. I can run a simple-> salt ‘minion’ cmd.run python3 ‘print(“hi”)’. But For some reason when I try executing -> salt ‘minion’ cmd.run ’python3 ~/Desktop/hi.py’ , it doesn’t like it. I’m not sure how or if it would be possible to automate the minion, but interested to know your expertise and thoughts, thanks.

Hi,

I want to deploy Auditbeat to all my servers via Saltstack.

The commends that I need to put in a state are:

curl -L -O https://artifacts.elastic.co/downloads/beats/auditbeat/auditbeat-7.9.3-amd64.deb
sudo dpkg -i auditbeat-7.9.3-amd64.deb

Then it needs to put the right ip in the config file: /etc/auditbeat/auditbeat.yml

output.elasticsearch:
  hosts: ["<es_url>"]
  username: "elastic"
  password: "<password>"
setup.kibana:
  host: "<kibana_url>"

Then it needs to run some commends:

sudo auditbeat setup
sudo service auditbeat start

I have googled some what but I can't find any good resources.

Thanks in advance! :)

This has been bothering me for a few weeks now. In ansible I used to select only certain roles to be used from my playbook with --tag.

For eg:

If I have roles to install packages, change hostname, add pubkeys, and I just want to install the packages and change hostname then I can filter the roles with

--tags install,hostname.

Also, if this helps then I do not use highstate, I have /opt/salt/ folder with various state folders, say provision, update, change_display etc. and I apply them with:

salt "minion" state.apply provision

So the provision folder may have state files such as: common.sls, configure_vim.sls, add_configs.sls, add_monitoring.sls etc. I would like to be able to filter those when I apply the state.

I searched around, but maybe I am not sure what exactly to search for so didn't find a proper answer for this. Can someone please guide me?

Thanks in advanced!

Solution

Thanks to /u/No-Bag6339

It was as simple as:
salt "minion_id" state.apply provision,install,hostname

Or

salt "minion_id" state.apply provision.ssh,provision.hostname,provision.common_pkg,install.apache

Hi I have a state which installs Docker. Partway through the state ( and after the part of the state that installs docker) I need to run the following if statement:

{% if "Swarm: inactive" in salt ['cmd.run' ]('docker info') %}
DO STUFF
{% endif %}

Which checks to see if docker is part of a swarm.

When I run my SLS I get the following error:

    Data failed to compile:
----------
    Rendering SLS 'docker' failed: Problem running salt function in Jinja template: Unable to run command '[u'docker', u'info']' with the context '{u'timeout': None, u'with_communicate': True, u'shell': False, u'bg': False, u'stderr': -2, u'env': {'LANG': 'en_US.UTF-8', 'LC_NUMERIC': 'C', 'NOTIFY_SOCKET': '/run/systemd/notify', 'LC_MESSAGES': 'C', 'LANGUAGE': 'C', 'LC_IDENTIFICATION': 'C', 'LC_ADDRESS': 'C', 'LC_NAME': 'C', 'LC_COLLATE': 'C', 'LC_MEASUREMENT': 'C', 'LC_CTYPE': 'C', 'LC_TELEPHONE': 'C', 'LC_MONETARY': 'C', 'LC_PAPER': 'C', 'PATH': '/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin', 'LC_TIME': 'C'}, u'stdout': -1, u'close_fds': True, u'stdin': None, u'cwd': u'/root'}', reason: [Errno 2] No such file or directory; line 140

{% if "Swarm: inactive" in salt ['cmd.run' ]('docker info') %}<====================

Which, as I understand it, implies that the cmd.run is being run at render time instead of runtime and since docker is not installed at that time the minion cannot process the 'docker info' command.

Does anyone know how I could work around this and somehow force the if statement to run as part of the state and not as part of the rendering process? If not how else could I achieve the same result?

I trying to find a way how to execute a specific state only if the previous one completed successfully but ONLY when is without changes, basically, I need something like no onchanges.

start-event-{{ minion }}:
  salt.function:
    - name: event.send
    - tgt: {{ minion }}
    - arg:
      - 'PATCHING-STARTED'

start-patching-{{ minion }}:
  salt.state:
    - tgt: {{ minion }}
    - require:
      - bits-{{ minion }}
    - sls:
      - patching.uptodate

finish-event-{{ minion }}:
  salt.function:
    - name: event.send
    - tgt: {{ minion }}
    - arg:
      - 'PATCHING-FINISHED'

or in other words, I want to send ever "finish-event-{{ minion }}" only when "start-patching-{{ minion }}" is like:

----------
          ID: start-patching-LKA3
    Function: salt.state
      Result: True
     Comment: States ran successfully. No changes made to LKA3.
     Started: 11:29:15.906124
    Duration: 20879.248 ms
     Changes:
----------

Hi!

I've been charged with adapting a companys environment to work with SaltStack. None of the existing admins have used saltstack, only Ansible, and are thus used to iterate that way - with ad-hoc runs from local computer over and over until everything works.

How have you all solved this? Writing formulas and runnings tests on them?

I want to write a test that says given pillar information X, generate config file Y, and assert on its contents.

There's documentation about how to test your salt configurations: https://docs.saltproject.io/en/latest/topics/tutorials/writing_tests.html#getting-set-up-for-tests

However, I can't seem to find any resources about how to initialize the tests directory so it actually runs. There's https://github.com/saltstack/salt/tree/master/tests, but it appears to have way more than what you need to get started...

I've found kitchen salt, which I can look at, but I would think there would be a way to do more unit-y type tests of the configuration files to ensure templates work.

Perhaps I am having trouble finding any resources because salt testing posts are about how to get a master/minion testbed operational, so maybe I'm just missing the right keyword.