Description
If a state using x509_v2.certificate_managed is running, then another state is queued, the states using x509_v2.certificate_managed will fail with a TypeError.
[ERROR ] An exception occurred in this state: Traceback (most recent call last):
File "/opt/saltstack/salt/lib/python3.10/site-packages/salt/state.py", line 2440, in call
ret = self.states[cdata["full"]](
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/loader/lazy.py", line 1296, in wrapper
return f(*args, **kwargs)
File "/opt/saltstack/salt/lib/python3.10/site-packages/salt/states/x509_v2.py", line 434, in certificate_managed
file_managed_test = _file_managed(name, test=True, replace=False, **file_args)
File "/opt/saltstack/salt/lib/python3.10/site-packages/salt/states/x509_v2.py", line 1599, in _file_managed
log.info(f'res[next(iter(res))]: {res[next(iter(res))]}')
TypeError: list indices must be integers or slices, not str
The issue occurs in the _file_managed method of states/x509_v2.py. The variable, res, is expected to be a dictionary, but in this case it is a list equal to something similar to ['The function "state.apply" is running as PID 99052 and was started at 2024, Sep 26 14:43:35.351043 with jid 20240926144335351043']
def _file_managed(name, test=None, **kwargs):
if test not in [None, True]:
raise SaltInvocationError("test param can only be None or True")
# work around https://github.com/saltstack/salt/issues/62590
test = test or __opts__["test"]
res = __salt__["state.single"]("file.managed", name, test=test, **kwargs)
return res[next(iter(res))]
In brief testing making the following change resolves the issue and seems like it may be a good solution, but I am unsure if this would be a best practice.
res = __salt__["state.single"]("file.managed", name, test=test, concurrent=True, **kwargs)
Setup
[root@jppsalt salt]# cat ca.sls
certs_dir:
file.directory:
- name: /etc/pki/issued_certs
- makedirs: True
pki_private_key:
x509.private_key_managed:
- name: /etc/pki/ca.key
- keysize: 4096
- passphrase:
- backup: True
pki_public_crt:
x509.certificate_managed:
- name: /etc/pki/ca.crt
- signing_private_key: /etc/pki/ca.key
- CN: jppsalt
- C: US
- ST: Utah
- L: Salt Lake City
- basicConstraints: "critical CA:true"
- keyUsage: "critical cRLSign, keyCertSign"
- extendedkeyUsage: "serverAuth, clientAuth"
- subjectKeyIdentifier: hash
- authorityKeyIdentifier: keyid:always, issuer
- days_valid: 3650
- days_remaining: 0
- backup: True
- replace: False
- timeout: 30
- retry:
attempts: 5
interval: 30
[root@jppsalt salt]# cat sleep.sls
sleep_now:
cmd.run:
- name: date && sleep 10 && date
Please be as specific as possible and give set-up details.
Steps to Reproduce the behavior
Create the ca.sls and sleep.sls states. Run salt-call state.apply ca in another terminal immediately run salt-call state.apply sleep queue=True. This issue can be also illustrated on more lengthy highstates that use x509_v2.certificate_managed. You will see the x509_v2 states fail and retry until the retries expire.
Expected behavior
The x509_v2.certificate_managed states should not fail if another states is queued after the state containing the x509_v2 state is initiated.
Versions Report
salt --versions-report
(Provided by running salt --versions-report. Please also mention any differences in master/minion versions.)
Salt Version:
Salt: 3006.9
Python Version:
Python: 3.10.14 (main, Jun 26 2024, 11:44:37) [GCC 11.2.0]
Dependency Versions:
cffi: 1.14.6
cherrypy: 18.6.1
cryptography: 42.0.5
dateutil: 2.8.1
docker-py: Not Installed
gitdb: Not Installed
gitpython: Not Installed
Jinja2: 3.1.4
libgit2: Not Installed
looseversion: 1.0.2
M2Crypto: Not Installed
Mako: Not Installed
msgpack: 1.0.2
msgpack-pure: Not Installed
mysql-python: Not Installed
packaging: 22.0
pycparser: 2.21
pycrypto: Not Installed
pycryptodome: 3.19.1
pygit2: Not Installed
python-gnupg: 0.4.8
PyYAML: 6.0.1
PyZMQ: 23.2.0
relenv: 0.17.0
smmap: Not Installed
timelib: 0.2.4
Tornado: 4.5.3
ZMQ: 4.3.4
System Versions:
dist: oracle 9.4
locale: utf-8
machine: x86_64
release: 5.15.0-101.103.2.1.el9uek.x86_64
system: Linux
version: Oracle Linux Server 9.4
Description
If a state using x509_v2.certificate_managed is running, then another state is queued, the states using x509_v2.certificate_managed will fail with a TypeError.
The issue occurs in the
_file_managedmethod of states/x509_v2.py. The variable,res, is expected to be a dictionary, but in this case it is a list equal to something similar to['The function "state.apply" is running as PID 99052 and was started at 2024, Sep 26 14:43:35.351043 with jid 20240926144335351043']In brief testing making the following change resolves the issue and seems like it may be a good solution, but I am unsure if this would be a best practice.
Setup
Please be as specific as possible and give set-up details.
Steps to Reproduce the behavior
Create the ca.sls and sleep.sls states. Run
salt-call state.apply cain another terminal immediately runsalt-call state.apply sleep queue=True. This issue can be also illustrated on more lengthy highstates that use x509_v2.certificate_managed. You will see the x509_v2 states fail and retry until the retries expire.Expected behavior
The x509_v2.certificate_managed states should not fail if another states is queued after the state containing the x509_v2 state is initiated.
Versions Report
salt --versions-report
(Provided by running salt --versions-report. Please also mention any differences in master/minion versions.)