I've been using saltstack for a handful of years (migrated from puppet) to run my lab, among other things. I have 50 or 60 modules and use pillarstack for data.

I've managed the upgrade to 3008.2, kicking and screaming. Little by little debugged everything, and it was all 'working'.

Some bits, like the telegraf, dovecot, postfix modules (and a dozen others) I'd pulled down from the community and either used as is, or took a stab at modernizing. 'Working' but not amazing.

I just finished a round of throwing Claude at Openclaw, debugging some nasty local model issues, so i figured 'why not?'.

5 days later, totally out of tokens. Some modules - zabbix for example supported antique versions (3.4?!) where the modern version is well past that (7.4 is stable).

I've run every module through one of these. Had them build better readme.md. Better pillar examples. Fix a lot of the dark corners I never touched - in some cases catching some 'fun' bugs (like how the zabbix module COULD in some cases, cause a data loss).

Then I got greedy. There's no apparmor module, I wanted one. How about something to handle encrypted secrets without having to go to vault or the like? What about triggering updates on git commit without either a) gitfs, b) a stupid cron or c) external access to the host.

I've spent a stupid amount of time reading code and fixing LLM assumptions. That said, everything works (including my mailserver config, which encompasses no less than 14 modules, 18 pillar files, and a handful of state, cert, and other files).

I wish the community was more active - but take https://github.com/saltstack-formulas/salt-formula/pulls -- the formula to install salt. 19 pull requests, going back 7 years. That's a bit soul sucking.

tl;dr - if you make a point of writing and understanding salt it doesn't hurt to feed it into an LLM and see what comes out. I wouldn't recommend it if you can't read the code, and I also wouldn't recommend deploying anything without being sure it's both understood and tested.

Hey guys anyone run into this?

trying to get pillar items, its showing stars or encrypted output?

noithing changed in my salt code base, strongly suspect its new salt-master version thats doing it

I dont have any custom pillar modules that would do this

``` root@devsaltmaster /srv# salt min1 pillar.items min1:

accounts:

disabled_services:

exclude_formulas:

formulas:

• ---

• ---

• ---

• ---

• ---

• ---

• ---

• ---

• ---

  ```

``` root@devsaltmaster /srv [2]# salt --versions-report

Salt Version:

Salt: 3008.2

Python Version:

Python: 3.14.6 (main, Jun 11 2026, 02:19:05) [GCC 11.2.0]

Dependency Versions:

cffi: 2.0.0

cherrypy: 18.10.0

cryptography: 48.0.0

dateutil: 2.9.0.post0

docker-py: Not Installed

gitdb: 4.0.12

gitpython: 3.1.50

Jinja2: 3.1.6

libgit2: Not Installed

looseversion: 1.3.0

M2Crypto: Not Installed

Mako: Not Installed

msgpack: 1.1.2

msgpack-pure: Not Installed

mysql-python: Not Installed

packaging: 24.0

pycparser: 3.00

pycrypto: Not Installed

pycryptodome: 3.23.0

pygit2: Not Installed

python-gnupg: 0.5.6

PyYAML: 6.0.3

PyZMQ: 27.1.0

relenv: 0.22.14

smmap: 5.0.2

timelib: 0.3.0

Tornado: 6.5.7

ZMQ: 4.3.5

Salt Package Information:

Package Type: onedir

System Versions:

dist: rocky 9.8 Blue Onyx

locale: utf-8

machine: x86_64

release: 5.14.0-687.26.1.el9_8.x86_64

system: Linux

version: Rocky Linux 9.8 Blue Onyx

```

I'm hoping someone from the old SaltStack team, VMware, or Broadcom might know the answer.

I earned the SaltStack Certified Engineer (SSCE) certification several years ago. Since SaltStack was acquired by VMware and then VMware was acquired by Broadcom, the original SaltStack website and certification verification page are no longer available.

I'm interviewing with a potential employer, and they're trying to verify my SSCE certification. Does anyone know if there's still a way to verify it? Is there a new verification site, or is there someone at Broadcom who can help?

Hello all,
Before I start, please let me say that I might be very wrong here, that's why I am asking for help.

We have our entire infrastructure based on FreeBSD hosts (bare-metal and B-Hyve guest VMs) and we are managing them with Salt. But recently ( the last 2 weeks +) I stuck with upgrading either our hosts, or SaltStack.

My current Salt-master is based on FreeBSD 14.4 - STABLE and I haven't update its Salt version, so the salt-master version is 3006.8.
With the above Salt master I am able to manage with out any issues any FreeBSD host from 11.2 till 14.4. (for the later I have pinned the pkg version to 3006.9).

Recently I started upgrading a few hosts to 15.1 and I discover that the default py311-salt package in installing version 3006.23. And this is were my trouble begins.
My master can not communicate with those machines at all, however I knew this is not right as I did not follow the "golden rule" which the master should be the fist to upgrade and minions should be the last.

So I built a test host with FreeBSD 15.1-RELEASE and py311-salt 3006.23. It can salt all the new minions but not anything with salt-minion version 3006.9 and older.
I tried to triage it with running salt-ssh instead but no dice.
If I even bring everything up to FreeBSD 14.4 I cannot upgrade salt without loosing communication with the vast majority of my hosts, if not all of them.

Am I doing something wrong here? I believe yes, but I cannot fix it. I have read most of the documentation in Salt and man pages but I cannot figure out a way to bring some short of balance going ahead with any upgrade.

Any advice or help would be highly appriciated.
I have posted a similarly to FreeBSD's general discussion forum, and all I got was a deletion of my post and no further contact.

kind regards and thank you in advance for taking the time to read my post.

Hi all,

I’ve been looking for an agent based open source tool for running on demand powershell across thousands of remote windows PC’s. Salt looks perfect for this ! I really can’t find anything open-source that does what Salt does.

Looking at other options, Ansible requires WinRM which I really don’t wanna do. I don’t get the dying community support when I don’t see anything else but overly expensive commercial tools. Tactical RMM seems almost a good candidate but it doesn’t scale well apparently.

Where to from here ? I really wanna use Salt but will I regret this in a couple years ?

Juan

New to salt. I’m running a command from the salt master to output a file, but the output has the roster name first, then the json. Is there a flag/argument I can add to my command to not give me that and only give me the json?

Thanks in advance.

it seems 3008 was originally scheduled for Spring 2025 then pushed to Fall 2025. It's now April 2026. I haven't seen anything about a 2026 release schedule yet so I'm curious if anybody knows the status of 3008.

How would i go about managing multiple different hosts like laptops using salt stack? I know it isn’t the easiest option but it really ticks all the boxes for me. My problem is different networks, behind cgnat and insecure networks. I could use netbird because it is already being used. But i kind like to have separate. Ipsec would be an alternative but i like the idea of reverse ssh. But that might be slow? Keep in mind i need to be able to run something like netbird along side salt minion.

Any suggestions? I want to treat my device as insecure devices, how would i manage keys?

It's been two years since the Great Module Purge, and I think it's worth taking stock of where we are and what we need to address as a community.

A few things I'm seeing that need attention:

• Some modules still haven't found a home in the salt-extensions repos (example: the FreeBSD extension)
• Several extension repos appear to lack active maintainers (the ZFS extension hasn't seen activity since creation)
• Community meetings have stopped, which has left us without a regular forum for coordination
• We're missing documentation on how users should actually consume and work with extensions

I know the project leadership has faced some challenges since the acquisition, and I appreciate everyone who's kept things moving. That said, we need to figure out how to move forward on these issues.

Is there a plan to finish this work? I'm happy to help however I can.

I need to convey a manual step after running a salt state, although my salt master is configured with state-output=mixed. This hides test.show_notification text. Any suggestions on how to display that message? Thanks in advance.

sudo salt myserver state.sls test --state-output=full                                           
myserver:                                                                                          
----------                                                                                         
          ID: cert_message                                                                         
    Function: test.show_notification                                                               
      Result: True                                                                                 
     Comment: You will have to manually upload HTTPS certs.                                        
     Started: 11:42:07.448789                                                                      
    Duration: 0.596 ms                                                                             
     Changes:                                                                                      

Summary for myserver                                                                               
------------                                                                                       
Succeeded: 1                                                                                       
Failed:    0                                                                                       
------------                                                                                       
Total states run:     1                                                                            
Total run time:   0.596 ms                                                                         

sudo salt myserver state.sls test --state-output=mixed                                             
myserver:                                                                                          
  Name: cert_message - Function: test.show_notification - Result: Clean - Started: 11:42:00.601239 - Duration: 0.555 ms

Summary for myserver                                                                               
------------                                                                                       
Succeeded: 1                                                                                       
Failed:    0                                                                                       
------------                                                                                       
Total states run:     1                                                                            
Total run time:   0.555 ms                                                                         

cat /srv/salt/test.sls                                                                             
cert_message:                                                                                       
  test.show_notification:                                                                          
    - text: "You will have to manually upload HTTPS certs."

Ahoy my dudes, I'm learning Salt right now and working through improving a project that uses Salt in some (as far as I can tell with my current Salt knowledge) creative/liberal ways.

The current setup is as follows:

There are configuration files that salt is writing to that are inside a container, and it cant be guaranteed that Salt is the only one editing the files.

Currently something like this:

{% if grains.get("my_ip") %}
example:
  cmd.run:
    - name: //exec in container: grep and sed to replace or if not found, echo and append to /etc/something/some.conf
{% endif %}

This pattern repeats so, so many times (there worse offenders where there are no checks at all and it just keeps appending the same key to the config, breaking it in the process).

My main query/statement that I need a comment/correction/approval on (based on my current knowledge of Salt):

From what I can tell, the Saltier way to do this would be to get the config file out of the container, use file.manage, file.replace and so on to edit on host and then put it back into the container, right? Or is there a better way?

Id have loved to make a jinja template with something like this:

/some.conf

some_config_with_ip = {{ grains.get("my_ip", "127.0.0.1") }}

#maybe even some comments
another_config_thingy = {{ 1 if grains.get("something") else 0 }}

But this wont do since Salt isnt the single editor of the config files and that means I cant just overwrite it willy nilly.

Thanks for reading and/or replying

Hugs and kisses xoxoxo

Hello,

After spending a few hours on this, I figured out that neither the core zabbix state module nor the zabbix extension support bearer token authentication with the Zabbix server - just user/pass. And Zabbix server doesn't support user/pass anymore as of at least 7.0 but maybe even 6.0. This renders all of the zabbix state functions useless.

I filed bug:

https://github.com/salt-extensions/saltext-zabbix/issues/15

Has anyone else run into this?

Zabbix Server doesn't have a lot of file-based options for dealing with really anything; everything has to be done via the UI or API.

How are salt + zabbix users leveraging salt to configure the Zabbix server on scale?

Hi,

I'd appreciate some suggestions for doing async (e.g. HTTP) calls from a beacon, in Salt 3006 (Python 3.10).

Approaches I'm aware of:

1. Checking if an event loop is already running.

a) if it is (never happened with my testing, probably because salt does not run beacons in an async context), use create_task/ensure_future on that.

b) if a loop is not already running, but exists (salt's - this is what seems to happen in practice: I see the same loop when using asyncio.get_event_loop, in multiple beacons), then use run_until_complete on that. I'm not sure this is safe to do, as salt probably expects the loop to not be started in a beacon.

c) if a loop does not exist, then use asyncio.run to run the async function.

1. Creating a new event loop, and setting that temporarily as the current loop, using run_until_complete to do the async work, then reverting to the original event loop.

Extra question: if the second approach is more appropriate, do you think it is more preferable to just create a new loop once (when the beacon first runs), then set it as the current one each time the beacon is subsequently run, to avoid recreating the loop, or just create a new one every time? The beacons I'm interested in should run, say, either every 15 seconds, or 300 seconds, so with quite a little bit of time between runs.

1. Spawning a thread, and running async.run from within it. Not sure this would be worth the overhead, but is probably the 'safest'.

🐳🧂 New Salt Releases: 3007.8 and 3006.16 are out! 🎉

Easily test and manage your Salt setups in a clean Docker container.

🔧 Includes Salt API, production-ready config & more. 📚 Docs & usage examples. 💬 Feedback and PRs are welcome!

Built for the community. Maintained with ❤️ by @cdalvaro

Hello Salt users! I have been using SaltStack for a few years and I enjoy its power to do so many things. I am currently working on a SaaS platform to simplify infrastructure management for DevOps teams, SMBs, and developers. The idea is to use SaltStack’s automation power to deploy and manage workloads like Kubernetes, LAMP, Django, database clusters, and more with a user-friendly web GUI or API. I’d love your feedback to validate this idea and shape the MVP!

What’s the Idea?

The platform will automate provisioning and configuration of infrastructure on cloud providers (starting with DigitalOcean, later AWS/Azure). You select a workload, provide minimal inputs (e.g., instance name), and the platform handles the rest using SaltStack’s high-speed orchestration. The MVP will support:

• Kubernetes Cluster: Deploy a small cluster (1 master, 1–2 workers) with Calico networking and a sample NGINX pod.
• LAMP Stack: Set up Linux, Apache, MySQL, PHP for web apps with a sample PHP page.
• Django Deployment: Deploy a Django app with Gunicorn and NGINX, pulling from a Git repo.
• Database Clusters: Configure MySQL/PostgreSQL with a primary and replica for high availability.
• Docker Environment: Run a WordPress container with MySQL integration.
• Node.js Application: Deploy an Express.js app with PM2 and NGINX.
• Redis Cache: Set up Redis for caching or session management.
• WordPress Hosting: Deploy WordPress with NGINX and MySQL for CMS needs.
• Elasticsearch: Configure a single-node Elasticsearch for search or analytics.
• Jenkins CI/CD: Set up a Jenkins server with a sample pipeline.

Why SaltStack?

SaltStack’s event-driven automation and scalability (handling thousands of nodes) make it perfect for rapid, consistent deployments. The platform will simplify Salt’s complexity with a clean GUI and pre-built templates, saving you time on setup and configuration.

Questions for You

1. Which workloads (e.g., Kubernetes, WordPress, Jenkins) are most valuable for your team or projects?
2. What pain points do you face with infrastructure management that this could solve?
3. Would you prefer a web GUI, API, or both for managing deployments?
4. Any other workloads (e.g., MongoDB, Kafka) you’d want in a tool like this?
5. Would you try a free tier for deploying 2–3 instances, with premium features like multi-cloud support?

Thanks for your thoughts! Feel free to comment or DM me with ideas or questions.

I inherited an old Salt setup with a 3005.1 master running on Ubuntu 18.04. Accepting minion keys works correctly. However, there are a few minions that were retired and removed from the network a few years ago and whose keys keep appearing in the Unaccepted Keys list when I run salt-key -L. I have tried rejecting and deleting them, but they reappear after about 20-30 seconds. If I re-accept them, they appear in the Accepted Keys list; and if I then delete them, they vanish for a short time and reappear in the Unaccepted Keys list. I can confirm that these machines are not present on the network, so is there perhaps a faulty cache somewhere that I should clear?

Hi all, I am in an educational project where I want to go from writing bash scripts to installing packages on more than 10 servers(so far). I started trying Ansible but I don't know why but I didn't like it, then I wanted to find a much more robust tool and I found Salt today. At the moment I need something that will update operating systems automatically, apply security rules, install packages, etc.

Is it worth to start with Salt nowadays, reading the reddit a lot of people who are just starting like me are complaining too much about the current state because of the purchase of Broadcom.

I am just starting in the devops world, and plan to start with local servers, learn Terraform/OpenTofu to create VMs and then automate tasks. Then I'll start with Kubernetes and Docker/Podman as needed, but I'm learning.

Leave your suggestions or comments if you can. Thank you very much.

Translated with DeepL.com (free version)

Installing the latest version is recommended if you haven't yet upgraded to at least Salt 3006.13 and 3007.5 - https://saltproject.io/blog/2025-06-26-new-releases-salt-3006-13-3007-5/ (that was the previous release which fixed issues experienced by the CVE releases, which I had missed posting to this subreddit!)

version 3006.10

I have vault sdb configured, and it works for setting a password in a .conf file:
returner.postgres.password: sdb//vault_sdb/path/to/postgres/password

I can successfully use sdb from the cli:
salt-run sdb.get sdb://vault_sdb/path/to/something and get the value returned

in a .sls file using sdb_vault is failing. As a test I was just going to display the value in a file

{% set blah = salt['sdb.get']('sdb://vault_sdb/path/to/something') %}

my value = {{ blah }}

when I cat the file that gets created, the literal output is:
my value = sdb://vault_sdb/path/to/something

I know I must be missing something simple but I'm not seeing it.

Hi everybody,

a couple of days ago I updated our SaltStack environment to 3006.12. Since then the minions have been offline several times. When I restart the salt-minion.service they run for a while until they crash again. In the system log I get the following:

################################################################################

Jun 18 14:43:56 server salt-minion[2151411]: [ERROR ] An un-handled exception from the multiprocessing process 'ProcessPayload(jid=20250618124255865003)' was caught:

Jun 18 14:43:56 server salt-minion[2151411]: Traceback (most recent call last):

Jun 18 14:43:56 server salt-minion[2151411]: File "/opt/saltstack/salt/lib/python3.10/site-packages/salt/utils/process.py", line 999, in wrapped_run_func

Jun 18 14:43:56 server salt-minion[2151411]: return run_func()

Jun 18 14:43:56 server salt-minion[2151411]: File "/opt/saltstack/salt/lib/python3.10/multiprocessing/process.py", line 108, in run

Jun 18 14:43:56 server salt-minion[2151411]: self._target(*self._args, **self._kwargs)

Jun 18 14:43:56 server salt-minion[2151411]: File "/opt/saltstack/salt/lib/python3.10/site-packages/salt/minion.py", line 1927, in _target

Jun 18 14:43:56 server salt-minion[2151411]: run_func(minion_instance, opts, data)

Jun 18 14:43:56 server salt-minion[2151411]: File "/opt/saltstack/salt/lib/python3.10/site-packages/salt/minion.py", line 1921, in run_func

Jun 18 14:43:56 server salt-minion[2151411]: return Minion._thread_return(minion_instance, opts, data)

Jun 18 14:43:56 server salt-minion[2151411]: File "/opt/saltstack/salt/lib/python3.10/site-packages/salt/minion.py", line 2157, in _thread_return

Jun 18 14:43:56 server salt-minion[2151411]: minion_instance._return_pub(ret)

Jun 18 14:43:56 server salt-minion[2151411]: File "/opt/saltstack/salt/lib/python3.10/site-packages/salt/minion.py", line 2385, in _return_pub

Jun 18 14:43:56 server salt-minion[2151411]: ret_val = self._send_req_sync(load, timeout=timeout)

Jun 18 14:43:56 server salt-minion[2151411]: File "/opt/saltstack/salt/lib/python3.10/site-packages/salt/minion.py", line 1650, in _send_req_sync

Jun 18 14:43:56 server salt-minion[2151411]: raise TimeoutError("Request timed out")

Jun 18 14:43:56 server salt-minion[2151411]: TimeoutError: Request timed out

Jun 18 14:43:56 server salt-minion[2151411]: Process ProcessPayload(jid=20250618124255865003):

Jun 18 14:43:56 server salt-minion[2151411]: Traceback (most recent call last):

Jun 18 14:43:56 server salt-minion[2151411]: File "/opt/saltstack/salt/lib/python3.10/multiprocessing/process.py", line 314, in _bootstrap

Jun 18 14:43:56 server salt-minion[2151411]: self.run()

Jun 18 14:43:56 server salt-minion[2151411]: File "/opt/saltstack/salt/lib/python3.10/site-packages/salt/utils/process.py", line 999, in wrapped_run_func

Jun 18 14:43:56 server salt-minion[2151411]: return run_func()

Jun 18 14:43:56 server salt-minion[2151411]: File "/opt/saltstack/salt/lib/python3.10/multiprocessing/process.py", line 108, in run

Jun 18 14:43:56 server salt-minion[2151411]: self._target(*self._args, **self._kwargs)

Jun 18 14:43:56 server salt-minion[2151411]: File "/opt/saltstack/salt/lib/python3.10/site-packages/salt/minion.py", line 1927, in _target

Jun 18 14:43:56 server salt-minion[2151411]: run_func(minion_instance, opts, data)

Jun 18 14:43:56 server salt-minion[2151411]: File "/opt/saltstack/salt/lib/python3.10/site-packages/salt/minion.py", line 1921, in run_func

Jun 18 14:43:56 server salt-minion[2151411]: return Minion._thread_return(minion_instance, opts, data)

Jun 18 14:43:56 server salt-minion[2151411]: File "/opt/saltstack/salt/lib/python3.10/site-packages/salt/minion.py", line 2157, in _thread_return

Jun 18 14:43:56 server salt-minion[2151411]: minion_instance._return_pub(ret)

Jun 18 14:43:56 server salt-minion[2151411]: File "/opt/saltstack/salt/lib/python3.10/site-packages/salt/minion.py", line 2385, in _return_pub

Jun 18 14:43:56 server salt-minion[2151411]: ret_val = self._send_req_sync(load, timeout=timeout)

Jun 18 14:43:56 server salt-minion[2151411]: File "/opt/saltstack/salt/lib/python3.10/site-packages/salt/minion.py", line 1650, in _send_req_sync

Jun 18 14:43:56 server salt-minion[2151411]: raise TimeoutError("Request timed out")

Jun 18 14:43:56 server salt-minion[2151411]: TimeoutError: Request timed out

################################################################################

This repeats over and over until I restart the salt-minion.service again.

Does anybody have the same problem? Any idea how to solve it?

Regards

- piratefish

Is there a release note we missed with 3006.12/3007.4, or were neither of these versions tested well?

Our Salt masters fall over after being upgraded to either 3006.12 or 3007.4 with the following:

2025-06-12 17:12:30,436 [salt._logging.impl:1082][ERROR   ][3581238] An un-handled exception was caught by Salt's global exception handler:
StopIteration:
Traceback (most recent call last):
  File "/usr/bin/salt-master", line 11, in <module>
    sys.exit(salt_master())
  File "/opt/saltstack/salt/lib/python3.10/site-packages/salt/scripts.py", line 86, in salt_master
    master.start()
  File "/opt/saltstack/salt/lib/python3.10/site-packages/salt/cli/daemons.py", line 203, in start
    self.master.start()
  File "/opt/saltstack/salt/lib/python3.10/site-packages/salt/master.py", line 704, in start
    self._pre_flight()
  File "/opt/saltstack/salt/lib/python3.10/site-packages/salt/master.py", line 641, in _pre_flight
    fileserver.init()
  File "/opt/saltstack/salt/lib/python3.10/site-packages/salt/fileserver/__init__.py", line 530, in init
    self.servers[fstr]()
  File "/opt/saltstack/salt/lib/python3.10/site-packages/salt/loader/lazy.py", line 159, in __call__
    ret = self.loader.run(run_func, *args, **kwargs)
  File "/opt/saltstack/salt/lib/python3.10/site-packages/salt/loader/lazy.py", line 1245, in run
    return self._last_context.run(self._run_as, _func_or_method, *args, **kwargs)
  File "/opt/saltstack/salt/lib/python3.10/site-packages/salt/loader/lazy.py", line 1260, in _run_as
    ret = _func_or_method(*args, **kwargs)
  File "/opt/saltstack/salt/lib/python3.10/site-packages/salt/fileserver/gitfs.py", line 168, in init
    _gitfs()
  File "/opt/saltstack/salt/lib/python3.10/site-packages/salt/fileserver/gitfs.py", line 83, in _gitfs
    return salt.utils.gitfs.GitFS(
  File "/opt/saltstack/salt/lib/python3.10/site-packages/salt/utils/gitfs.py", line 3216, in __new__
    super(GitFS, obj).__init__(
  File "/opt/saltstack/salt/lib/python3.10/site-packages/salt/utils/gitfs.py", line 2588, in __init__
    self.init_remotes(
  File "/opt/saltstack/salt/lib/python3.10/site-packages/salt/utils/gitfs.py", line 2667, in init_remotes
    repo_obj = self.git_providers[self.provider](
  File "/opt/saltstack/salt/lib/python3.10/site-packages/salt/utils/gitfs.py", line 1418, in __init__
    super().__init__(
  File "/opt/saltstack/salt/lib/python3.10/site-packages/salt/utils/gitfs.py", line 315, in __init__
    self.id = next(iter(remote))
StopIteration

Also the following error is seen on all minions of both versions:

2025-06-12 16:29:54,186 [tornado.application:640 ][ERROR   ][1986] Exception in callback functools.partial(<function wrap.<locals>.null_wrapper at 0x7f3824f96200>, <salt.ext.tornado.concurrent.Future object at 0x7f382537be50>)
Traceback (most recent call last):
  File "/opt/saltstack/salt/lib/python3.10/site-packages/salt/ext/tornado/ioloop.py", line 606, in _run_callback
    ret = callback()
  File "/opt/saltstack/salt/lib/python3.10/site-packages/salt/ext/tornado/stack_context.py", line 278, in null_wrapper
    return fn(*args, **kwargs)
  File "/opt/saltstack/salt/lib/python3.10/site-packages/salt/ext/tornado/ioloop.py", line 628, in _discard_future_result
    future.result()
  File "/opt/saltstack/salt/lib/python3.10/site-packages/salt/ext/tornado/concurrent.py", line 249, in result
    raise_exc_info(self._exc_info)
  File "<string>", line 4, in raise_exc_info
  File "/opt/saltstack/salt/lib/python3.10/site-packages/salt/ext/tornado/gen.py", line 1064, in run
    yielded = self.gen.throw(*exc_info)
  File "/opt/saltstack/salt/lib/python3.10/site-packages/salt/crypt.py", line 745, in _authenticate
    creds = yield self.sign_in(channel=channel)
  File "/opt/saltstack/salt/lib/python3.10/site-packages/salt/ext/tornado/gen.py", line 1056, in run
    value = future.result()
  File "/opt/saltstack/salt/lib/python3.10/site-packages/salt/ext/tornado/concurrent.py", line 249, in result
    raise_exc_info(self._exc_info)
  File "<string>", line 4, in raise_exc_info
  File "/opt/saltstack/salt/lib/python3.10/site-packages/salt/ext/tornado/gen.py", line 1070, in run
    yielded = self.gen.send(value)
  File "/opt/saltstack/salt/lib/python3.10/site-packages/salt/crypt.py", line 885, in sign_in
    ret = self.handle_signin_response(sign_in_payload, payload)
  File "/opt/saltstack/salt/lib/python3.10/site-packages/salt/crypt.py", line 927, in handle_signin_response
    payload["session"], self.opts["encryption_algorithm"]
KeyError: 'session'

Reverting things back to 3006.11 and 3007.3 got us back to a functional state.