BREAKING CHANGES: This commit changes upstream repository naming conventions
to get latest binaries and keys. If you depends on versions of salt from older,
please stick with version 1.x.x of this formula
Don't add key_url as it is deprecated and not needed when
pkgrepo_keyring is set. This has been supported since stretch so make it
the default. Also use py3 repo by default for Debian family as it is now
the only option.
Additionally, Raspbian has been updated to use signed-by by default.
Avoid this error:
```
ID: salt-master
Function: pkg.installed
Result: False
Comment: Error occurred installing package(s). Additional info follows:
errors:
- Running scope as unit run-402.scope.
Loaded plugins: ovl, ulninfo
https://repo.saltproject.io/py3/redhat/7Server/x86_64/3002/repodata/repomd.xml:
[Errno 14] HTTPS Error 404 - Not Found
Trying other mirror.
No package salt-master available.
Error: Nothing to do
```
Use the `retry_options` already being used for the Salt minion service,
since we're getting failures such as this one:
* https://github.com/myii/salt-formula/runs/2415072504
This is made worse by the fact that GitHub Actions cannot re-run a
single job (at the current time).
Right now when you set module_config entries in your pillar data
like this:
salt:
minion:
module_config:
smtp.from: 'Kali Salt <admins+salt@kali.org>'
smtp.to: 'Kali Admins <admins+salt@kali.org>'
smtp.host: localhost
smtp.subject: 'Results of salt actions on'
smtp.fields: id,fun
On each run, you will always a different ordering of the various
fields in the minion configuration file, leading to spurious restart
of the minion and admin annoyance:
ID: salt-minion
Function: file.recurse
Name: /etc/salt/minion.d
Result: True
Comment: Recursively updated /etc/salt/minion.d
Started: 13:39:25.689775
Duration: 874.318 ms
Changes:
----------
/etc/salt/minion.d/f_defaults.conf:
----------
diff:
---
+++
@@ -930,10 +930,10 @@
# A dict for the test module:
#test.baz: {spam: sausage, cheese: bread}
#
+smtp.fields: id,fun
+smtp.from: Kali Salt <admins+salt@kali.org>
smtp.to: Kali Admins <admins+salt@kali.org>
-smtp.fields: id,fun
smtp.host: localhost
-smtp.from: Kali Salt <admins+salt@kali.org>
smtp.subject: Results of salt actions on
With the change here, this bad behaviour is gone...
Make the upstream salt package repository selectable, thus allowing the
use of archived salt versions (hosted in
https://archive.repo.saltproject.io), as well as custom salt versions
hosted in alternate repositories.
* CVE-2021-25283 enables Jinja2 safe mode, which breaks use of
`'dict' in x.__class__.__name__` workaround
* Workaround no longer needed as CentOS 6 is EOL
Use ugly `zypper lr --uri` hack to get around failure if the `base_url`
already exists under a different name:
```
ID: salt-pkgrepo-install-saltstack-suse
Function: pkgrepo.managed
Name: systemsmanagement_saltstack_products
Result: False
Comment: Failed to configure repo 'systemsmanagement_saltstack_products':
Repository 'systemsmanagement_saltstack_products' already exists as 'systemsmanagement_saltstack'.
Started: 09:28:39.154054
Duration: 2760.727 ms
```
Upstream code:
* 45cc49daed/salt/modules/zypperpkg.py (L1262-L1265)
When running a high-state on the salt-master to deploy itself, the run fails
with an Authentication error occurred because the master restarts half way though.