Giter Site home page Giter Site logo

opensuse / salt Goto Github PK

View Code? Open in Web Editor NEW
22.0 18.0 51.0 306.98 MB

openSUSE and SUSE patches and backports for SaltStack

License: Apache License 2.0

Makefile 0.01% Shell 1.24% Python 97.92% C 0.01% Batchfile 0.03% NSIS 0.18% HTML 0.02% SaltStack 0.07% PowerShell 0.30% Scheme 0.01% Roff 0.01% Dockerfile 0.01% Ruby 0.01% Rich Text Format 0.01% HCL 0.01% Groovy 0.01% Scilab 0.01% Jinja 0.10% Cython 0.01% C# 0.12%

salt's Introduction

Salt Project License: Apache v2.0

PyPi Package Downloads

PyPi Package Downloads

Salt Project Slack Community

Salt Project Twitch Channel

Salt Project subreddit

Follow SaltStack on Twitter

Salt is the world's fastest, most intelligent and scalable automation engine.

About Salt

Built on Python, Salt is an event-driven automation tool and framework to deploy, configure, and manage complex IT systems. Use Salt to automate common infrastructure administration tasks and ensure that all the components of your infrastructure are operating in a consistent desired state.

Salt has many possible uses, including configuration management, which involves:

  • Managing operating system deployment and configuration.
  • Installing and configuring software applications and services.
  • Managing servers, virtual machines, containers, databases, web servers, network devices, and more.
  • Ensuring consistent configuration and preventing configuration drift.

Salt is ideal for configuration management because it is pluggable, customizable, and plays well with many existing technologies. Salt enables you to deploy and manage applications that use any tech stack running on nearly any operating system, including different types of network devices such as switches and routers from a variety of vendors.

In addition to configuration management Salt can also:

  • Automate and orchestrate routine IT processes, such as common required tasks for scheduled server downtimes or upgrading operating systems or applications.
  • Create self-aware, self-healing systems that can automatically respond to outages, common administration problems, or other important events.

About our sponsors

Salt powers VMware's vRealize Automation SaltStack Config, and can be found under the hood of products from Juniper, Cisco, Cloudflare, Nutanix, SUSE, and Tieto, to name a few.

The original sponsor of our community, SaltStack, was acquired by VMware in 2020. The Salt Project remains an open source ecosystem that VMware supports and contributes to. VMware ensures the code integrity and quality of the Salt modules by acting as the official sponsor and manager of the Salt project. Many of the core Salt Project contributors are also VMware employees. This team carefully reviews and enhances the Salt modules to ensure speed, quality, and security.

Download and install Salt

Salt is tested and packaged to run on CentOS, Debian, RHEL, Ubuntu, MacOS, Windows, and more. Download Salt and get started now. See supported operating systems for more information.

To download and install Salt, see: * The Salt install guide * Salt Project repository

Technical support

Report bugs or problems using Salt by opening an issue: https://github.com/saltstack/salt/issues

To join our community forum where you can exchange ideas, best practices, discuss technical support questions, and talk to project maintainers, join our Slack workspace: Salt Project Community Slack

Salt Project documentation

Installation instructions, tutorials, in-depth API and module documentation:

Security advisories

Keep an eye on the Salt Project Security Announcements landing page. Salt Project recommends subscribing to the Salt Project Security RSS feed to receive notification when new information is available regarding security announcements.

Other channels to receive security announcements include the Salt Community mailing list and the Salt Project Community Slack.

Responsibly reporting security vulnerabilities

When reporting security vulnerabilities for Salt or other SaltStack projects, refer to the SECURITY.md file found in this repository.

Join our community

Salt is built by the Salt Project community, which includes more than 3,000 contributors working in roles just like yours. This well-known and trusted community works together to improve the underlying technology and extend Salt by creating a variety of execution and state modules to accomplish the most common tasks or solve the most important problems that people in your role are likely to face.

If you want to help extend Salt or solve a problem with Salt, you can join our community and contribute today.

Please be sure to review our Code of Conduct. Also, check out some of our community resources including:

There are lots of ways to get involved in our community. Every month, there are around a dozen opportunities to meet with other contributors and the Salt Core team and collaborate in real time. The best way to keep track is by subscribing to the Salt Project Community Events Calendar on the main https://saltproject.io website.

If you have additional questions, email us at [email protected] or reach out directly to the Community Manager, Jimmy Chunga via Slack. We'd be glad to have you join our community!

License

Salt is licensed under the Apache 2.0 license. Please see the LICENSE file for the full text of the Apache license, followed by a full summary of the licensing used by external modules.

A complete list of attributions and dependencies can be found here: salt/DEPENDENCIES.md

salt's People

Contributors

akm0d avatar basepi avatar cbosdo avatar ch3ll avatar cro avatar cvrebert avatar dwoz avatar garethgreenaway avatar gtmanfred avatar jacksontj avatar jacobhammons avatar jfindlay avatar kiorky avatar meaksh avatar mgwilliams avatar mirceaulinic avatar mkleb avatar nicholasmhughes avatar nmadhok avatar s0undt3ch avatar sejeff avatar sjorge avatar smithsamuelm avatar techhat avatar terminalmage avatar thatch45 avatar twangboy avatar utahdave avatar waynew avatar whiteinge avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

salt's Issues

saltstack server_id changes with each run on python3 backport patch

Description of Issue/Question

saltstack server_id changes with each run

Setup

Opensuse Tumbleweed

Steps to Reproduce Issue

install tumbleweed, install salt-master, salt-minion, exchange keys,
run salt-call grains.item server_id multiple times

[[email protected] stack (master)]# salt-call grains.item server_id && date
local:
    ----------
    server_id:
        812924806

[[email protected] stack (master)]# salt-call grains.item server_id && date
local:
    ----------
    server_id:
        533218382

Versions Report

Salt Version:
           Salt: 2018.3.0
 
Dependency Versions:
           cffi: 1.11.5
       cherrypy: Not Installed
       dateutil: 2.6.1
      docker-py: 3.3.0
          gitdb: Not Installed
      gitpython: Not Installed
          ioflo: Not Installed
         Jinja2: 2.10
        libgit2: 0.27.0
        libnacl: Not Installed
       M2Crypto: Not Installed
           Mako: Not Installed
   msgpack-pure: Not Installed
 msgpack-python: 0.5.6
   mysql-python: Not Installed
      pycparser: 2.18
       pycrypto: 3.6.1
   pycryptodome: Not Installed
         pygit2: 0.27.0
         Python: 3.6.5 (default, Mar 31 2018, 19:45:04) [GCC]
   python-gnupg: Not Installed
         PyYAML: 3.12
          PyZMQ: 17.0.0
           RAET: Not Installed
          smmap: Not Installed
        timelib: 0.2.4
        Tornado: 4.5.3
            ZMQ: 4.2.5
 
System Versions:
           dist:   
         locale: UTF-8
        machine: x86_64
        release: 4.17.2-1-default
         system: Linux
        version: Not Installed

This was fixed in:

saltstack/salt#46649

numeric uid owner breaks salt file module/state

Description of Issue

This output is from a state.highstate. the file on the machine is owned by an unresolvable UID.

          ID: zypp_conf_solver_dupAllowVendorChange
    Function: file.replace
        Name: /etc/zypp/zypp.conf
      Result: False
     Comment: An exception occurred in this state: Traceback (most recent call last):
                File "/usr/lib/python3.6/site-packages/salt/state.py", line 1987, in call
                  ret = self.states[cdata['full']](*cdata['args'], **cdata['kwargs'])
                File "/usr/lib/python3.6/site-packages/salt/loader.py", line 2031, in wrapper
                  return f(*args, **kwargs)
                File "/usr/lib/python3.6/site-packages/salt/states/file.py", line 4823, in replace
                  backslash_literal=backslash_literal)
                File "/usr/lib/python3.6/site-packages/salt/modules/file.py", line 2485, in replace
                  check_perms(path, None, pre_user, pre_group, pre_mode)
                File "/usr/lib/python3.6/site-packages/salt/modules/file.py", line 4577, in check_perms
                  not salt.utils.platform.is_windows() and salt.utils.stringutils.to_str(user) != perms['luser']
                File "/usr/lib/python3.6/site-packages/salt/utils/stringutils.py", line 103, in to_str
                  raise TypeError('expected str, bytes, or bytearray not {}'.format(type(s)))
              TypeError: expected str, bytes, or bytearray not <class 'int'>
     Started: 16:44:07.373835
    Duration: 5.901 ms
     Changes:   

you can also reproduce it with

salt '*' file.check_perms /etc/zypp/locks '{}' 65433 root 644

hostname:
    Passed invalid arguments to file.check_perms: expected str, bytes, or bytearray not <class 'int'>

Versions Report

Salt Version:
           Salt: 3000.3
 
Dependency Versions:
           cffi: 1.14.3
       cherrypy: Not Installed
       dateutil: 2.8.1
      docker-py: Not Installed
          gitdb: Not Installed
      gitpython: Not Installed
         Jinja2: 2.11.2
        libgit2: Not Installed
       M2Crypto: 0.36.0
           Mako: 1.1.3
   msgpack-pure: Not Installed
 msgpack-python: 1.0.0
   mysql-python: Not Installed
      pycparser: 2.20
       pycrypto: 3.9.8
   pycryptodome: Not Installed
         pygit2: Not Installed
         Python: 3.8.6 (default, Nov 09 2020, 12:09:06) [GCC]
   python-gnupg: Not Installed
         PyYAML: 5.3.1
          PyZMQ: 19.0.2
          smmap: Not Installed
        timelib: Not Installed
        Tornado: 4.5.3
            ZMQ: 4.3.2
 
System Versions:
           dist: opensuse-tumbleweed 20201121 n/a
         locale: utf-8
        machine: x86_64
        release: 5.8.15-1-default
         system: Linux
        version: openSUSE Tumbleweed 20201121 n/a

opensuse leap 42.2 salt package out of date, 2015.8.7 should be 2016.3.2

On a fresh install of opensuse leap 42.2 beta:

zypper search -s salt-minion
Loading repository data...
Reading installed packages...

S | Name | Type | Version | Arch | Repository
--+-------------+---------+----------------+--------+---------------------------------------------------------
v | salt-minion | package | 2015.8.7-1.31 | x86_64 | Main Repository (OSS)
i | salt-minion | package | 2015.8.7-1.31 | x86_64 | openSUSE-42.2-0

When adding the systemsmanagement repo's from 42.1 which work:

search -s salt-minion
Loading repository data...
Reading installed packages...

S | Name | Type | Version | Arch | Repository
--+-------------+---------+----------------+--------+---------------------------------------------------------
i | salt-minion | package | 2016.3.2-7.1 | x86_64 | Testing EXPERIMENTAL Salt versions (openSUSE_Leap_42.1)
v | salt-minion | package | 2015.8.10-76.1 | x86_64 | SaltStack, dependencies, and addons (openSUSE_Leap_42.1)

[DOCS] Dedplicating Content

Description

Currently we maintain manually multiple sources of Salt Versions we maintain and related documents.

Suggested Fix

Collect and deduplicate. Then possibly automate some processes.

Type of documentation

openSUSE/salt - GH Wiki

Location or format of documentation

Not applicable

Additional context

Originally this was discovered by @agraul here

[BUG] Transactional update module prevents sls execution

Description
When invoking salt commands: salt '*' state.apply I receive the stack trace below:

   The minion function caused an exception: Traceback (most recent call last):
      File "/usr/lib/python3.10/site-packages/salt/minion.py", line 1939, in _thread_return
        return_data = minion_instance._execute_job_function(
      File "/usr/lib/python3.10/site-packages/salt/minion.py", line 1898, in _execute_job_function
        return_data = self.executors[fname](opts, data, func, args, kwargs)
      File "/usr/lib/python3.10/site-packages/salt/loader/lazy.py", line 149, in __call__
        return self.loader.run(run_func, *args, **kwargs)
      File "/usr/lib/python3.10/site-packages/salt/loader/lazy.py", line 1230, in run
        return self._last_context.run(self._run_as, _func_or_method, *args, **kwargs)
      File "/usr/lib/python3.10/site-packages/salt/loader/lazy.py", line 1245, in _run_as
        return _func_or_method(*args, **kwargs)
      File "/usr/lib/python3.10/site-packages/salt/executors/transactional_update.py", line 123, in execute
        opts, data, __salt__[DELEGATION_MAP[fun]], args, kwargs
      File "/usr/lib/python3.10/site-packages/salt/loader/context.py", line 78, in __getitem__
        return self.value()[item]
      File "/usr/lib/python3.10/site-packages/salt/loader/lazy.py", line 336, in __getitem__
        super().__getitem__(item)  # try to get the item from the dictionary
      File "/usr/lib/python3.10/site-packages/salt/utils/lazy.py", line 105, in __getitem__
        raise KeyError(key)
    KeyError: 'transactional_update.apply'

Setup
I've installed a fresh microos server with salt-master and salt-minion version 3005.1-3.1

OS details:

NAME="openSUSE MicroOS"
# VERSION="20230124"
ID="opensuse-microos"
ID_LIKE="suse opensuse opensuse-tumbleweed"
VERSION_ID="20230124"
PRETTY_NAME="openSUSE MicroOS"
ANSI_COLOR="0;32"
CPE_NAME="cpe:/o:opensuse:microos:20230124"
BUG_REPORT_URL="https://bugs.opensuse.org"
HOME_URL="https://www.opensuse.org/"
DOCUMENTATION_URL="https://en.opensuse.org/Portal:MicroOS"
LOGO="distributor-logo-MicroOS"

Please be as specific as possible and give set-up details.

  • VM (Virtualbox, KVM, etc. please specify)
    • VM running on ESXi 6.5

Steps to Reproduce the behavior
run salt '*' state.apply

Versions Report
image

Upstreaming patches: do not enforce zypper refresh if not needed

If someone can tell me how to make a master/minion option for "force" or "no force" I will happily extend the patch accordingly. but this patch reduced our highstate times a lot.

We setup the refresh option on the repositories that need it (updates- and buildservice repositories) and leave it out at the static GA repositories.

With the current code you can still force a force refresh via a salt module call.

Index: salt-2019.2.2-suse/salt/modules/zypperpkg.py
===================================================================
--- salt-2019.2.2-suse.orig/salt/modules/zypperpkg.py
+++ salt-2019.2.2-suse/salt/modules/zypperpkg.py
@@ -1277,9 +1277,10 @@ def mod_repo(repo, **kwargs):
     return repo
 
 
-def refresh_db(root=None):
+def refresh_db(root=None, force=False):
     '''
-    Force a repository refresh by calling ``zypper refresh --force``, return a dict::
+    Force a repository refresh by calling ``zypper refresh``, if the "force=True" flag is passed it will run with ``--force``.
+    It will return a dict::
 
         {'<database name>': Bool}
 
@@ -1290,12 +1291,15 @@ def refresh_db(root=None):
 
     .. code-block:: bash
 
-        salt '*' pkg.refresh_db
+        salt '*' pkg.refresh_db [force=true|false]
     '''
     # Remove rtag file to keep multiple refreshes from happening in pkg states
     salt.utils.pkg.clear_rtag(__opts__)
     ret = {}
-    out = __zypper__(root=root).refreshable.call('refresh', '--force')
+    refresh_opts = ['refresh']
+    if force:
+        refresh_opts.append('--force')
+    out = __zypper__(root=root).refreshable.call(*refresh_opts)
 
     for line in out.splitlines():
         if not line:

Warning about systemd units when upgrading

Is it harmless?

Checking for file conflicts: ....................................................................[done]
(1/3) Installing: salt-2015.8.8-67.1.x86_64 .....................................................[done]
(2/3) Installing: salt-master-2015.8.8-67.1.x86_64 ..............................................[done]
Additional rpm output:
The unit files have no [Install] section. They are not meant to be enabled
using systemctl.
Possible reasons for having this kind of units are:
1) A unit may be statically enabled by being symlinked from another unit's
   .wants/ or .requires/ directory.
2) A unit's purpose may be to act as a helper for some other unit which has
   a requirement dependency on it.
3) A unit may be started when needed via activation (socket, path, timer,
   D-Bus, udev, scripted systemctl call, ...).

[BUG] Test mode for `x509.certificate_managed` is broken

Description
x509.certificate_managed state isn't working with test mode enabled. It looks like the problem is with SUSE backport patch 094b347. There is an usage of undefined private_key_args variable. It was probably pulled from some old code.

Error:

     Comment: An exception occurred in this state: Traceback (most recent call last):
                File "/usr/lib/python3.6/site-packages/salt/state.py", line 2402, in call
                  *cdata["args"], **cdata["kwargs"]
                File "/usr/lib/python3.6/site-packages/salt/loader/lazy.py", line 149, in __call__
                  return self.loader.run(run_func, *args, **kwargs)
                File "/usr/lib/python3.6/site-packages/salt/loader/lazy.py", line 1234, in run
                  return self._last_context.run(self._run_as, _func_or_method, *args, **kwargs)
                File "/usr/lib/python3.6/site-packages/contextvars/__init__.py", line 38, in run
                  return callable(*args, **kwargs)
                File "/usr/lib/python3.6/site-packages/salt/loader/lazy.py", line 1249, in _run_as
                  return _func_or_method(*args, **kwargs)
                File "/usr/lib/python3.6/site-packages/salt/loader/lazy.py", line 1282, in wrapper
                  return f(*args, **kwargs)
                File "/usr/lib/python3.6/site-packages/salt/states/x509.py", line 708, in certificate_managed
                  private_key_args.update(managed_private_key)
              NameError: name 'private_key_args' is not defined

Setup
salt-minion-3006.0-150500.4.24.2.x86_64

Steps to Reproduce the behavior

salt-call state.single x509.private_key_managed name=/tmp/test.key
salt-call state.single x509.certificate_managed name=/tmp/test.crt signing_private_key=/tmp/test.key test=true

Expected behavior
No error returned.

Versions Report

salt --versions-report (Provided by running salt --versions-report. Please also mention any differences in master/minion versions.)
Salt Version:
          Salt: 3006.0

Python Version:
        Python: 3.6.15 (default, Sep 23 2021, 15:41:43) [GCC]

Dependency Versions:
          cffi: 1.13.2
      cherrypy: unknown
      dateutil: Not Installed
     docker-py: Not Installed
         gitdb: Not Installed
     gitpython: Not Installed
        Jinja2: 2.10.1
       libgit2: Not Installed
  looseversion: 1.0.2
      M2Crypto: 0.38.0
          Mako: Not Installed
       msgpack: 0.5.6
  msgpack-pure: Not Installed
  mysql-python: Not Installed
     packaging: 20.3
     pycparser: 2.17
      pycrypto: Not Installed
  pycryptodome: Not Installed
        pygit2: Not Installed
  python-gnupg: Not Installed
        PyYAML: 5.4.1
         PyZMQ: 17.1.2
        relenv: Not Installed
         smmap: Not Installed
       timelib: Not Installed
       Tornado: 4.5.3
           ZMQ: 4.2.3

System Versions:
          dist: opensuse-leap 15.5
        locale: UTF-8
       machine: x86_64
       release: 5.14.21-150500.55.39-default
        system: Linux
       version: openSUSE Leap 15.5

Creating mysql users via salt fails with traceback

traceback

2020-08-12 17:29:42,897 [salt.state       :323 ][ERROR   ][32435] An exception occurred in this state: Traceback (most recent call last):
  File "/usr/lib/python3.6/site-packages/salt/state.py", line 1987, in call
    ret = self.states[cdata['full']](*cdata['args'], **cdata['kwargs'])
  File "/usr/lib/python3.6/site-packages/salt/loader.py", line 2031, in wrapper
    return f(*args, **kwargs)
  File "/usr/lib/python3.6/site-packages/salt/states/mysql_user.py", line 142, in present
    **connection_args):
  File "/usr/lib/python3.6/site-packages/salt/modules/mysql.py", line 1268, in user_exists
    server_version = salt.utils.data.decode(version(**connection_args))
  File "/usr/lib/python3.6/site-packages/salt/modules/mysql.py", line 860, in version
    dbc = _connect(**connection_args)
  File "/usr/lib/python3.6/site-packages/salt/modules/mysql.py", line 394, in _connect
    dbc = MySQLdb.connect(**connargs)
  File "/usr/lib64/python3.6/site-packages/MySQLdb/__init__.py", line 84, in Connect
    return Connection(*args, **kwargs)
  File "/usr/lib64/python3.6/site-packages/MySQLdb/connections.py", line 148, in __init__
    for k, v in conv.items():
AttributeError: 'str' object has no attribute 'items'

when logging connargs in /usr/lib/python3.6/site-packages/salt/modules/mysql.py

it is shown as 'conv': '' this does not match the API descriptions in the mysqlclient 1.4.6 (which is in 15.2 and TW), which requires conv to be a dictionary.

The culprit seems to be

val = __salt__['config.option']('mysql.{0}'.format(name), None)

which returns an empty string instead of None so the check below is not catching that case. when we extend the check below with

if val is not None and val != '':

then the state works as expected.

postgres_user:present: Add support for scram-sha-256

Description of Issue/Question

Creating a postgres user with:

p:
  postgres_user.present:
    - name: wurst
    - password: brot
    - encrypted: True

only supports md5 and not scram-sha256! I would expect something like:

p:
  postgres_user.present:
    - name: wurst
    - password: brot
    - encryption: no|md5|scam-sha-256

Versions Report

(Provided by running salt --versions-report. Please also mention any differences in master/minion versions.)

Salt Version:
           Salt: 3000
 
Dependency Versions:
           cffi: 1.13.2
       cherrypy: Not Installed
       dateutil: 2.7.3
      docker-py: Not Installed
          gitdb: Not Installed
      gitpython: Not Installed
         Jinja2: 2.10.1
        libgit2: 0.28.4
       M2Crypto: 0.35.2
           Mako: 1.0.7
   msgpack-pure: Not Installed
 msgpack-python: 0.5.6
   mysql-python: 1.4.6
      pycparser: 2.17
       pycrypto: 3.9.0
   pycryptodome: Not Installed
         pygit2: 0.28.2
         Python: 3.6.10 (default, Jan 16 2020, 09:12:04) [GCC]
   python-gnupg: Not Installed
         PyYAML: 5.1.2
          PyZMQ: 17.0.0
          smmap: Not Installed
        timelib: Not Installed
        Tornado: 4.5.3
            ZMQ: 4.2.3
 
System Versions:
           dist:   
         locale: UTF-8
        machine: x86_64
        release: 5.3.18-lp152.36-default
         system: Linux
        version: Not Installed

[BUG] Salt minion bundle broken for openEuler

Description
Salt minion bundle stopped working.
All comes from the implementation of openEuler client support for Uyuni, see uyuni-project/uyuni#6623

Setup

  • on-prem machine
  • VM (KVM)
  • VM running on a cloud service, please be explicit and add details
  • container (Kubernetes, Docker, containerd, etc. please specify)
  • or a combination, please be explicit
  • jails if it is FreeBSD

Steps to Reproduce the behavior
I was using a PoC for the salt bundle from this repo in July, which used to work:
https://download.opensuse.org/repositories/home:/vzhestkov:/saltstack:/bundle:/next/AlmaLinux_8/
I can see the package got rebuilt in December, and it is not working any more.

Error in the web-ui:

stderr: "Traceback (most recent call last):
  File "/var/tmp/venv-salt-minion/bin/salt-call", line 10, in <module>
    salt_call()
  File "/var/tmp/venv-salt-minion/lib64/python3.10/site-packages/salt/scripts.py", line 426, in salt_call
    import salt.cli.call
  File "/var/tmp/venv-salt-minion/lib64/python3.10/site-packages/salt/cli/call.py", line 3, in <module>
    import salt.cli.caller
  File "/var/tmp/venv-salt-minion/lib64/python3.10/site-packages/salt/cli/caller.py", line 14, in <module>
    import salt.loader
  File "/var/tmp/venv-salt-minion/lib64/python3.10/site-packages/salt/loader/__init__.py", line 15, in <module>
    import salt.config
  File "/var/tmp/venv-salt-minion/lib64/python3.10/site-packages/salt/config/__init__.py", line 26, in <module>
    import salt.utils.user
  File "/var/tmp/venv-salt-minion/lib64/python3.10/site-packages/salt/utils/user.py", line 7, in <module>
    import ctypes
  File "/var/tmp/venv-salt-minion/lib64/python3.10/ctypes/__init__.py", line 8, in <module>
    from _ctypes import Union, Structure, Array
ImportError: libffi.so.6: cannot open shared object file: No such file or directory", stdout: ""

I tried to fool the system and link libffi:

[root@vm-panaditas ~]# ln -s /usr/lib64/libffi.so.8.1.0 /usr/lib64/libffi.so.6
[root@vm-panaditas ~]# ls -l /usr/lib64/libffi.so*
lrwxrwxrwx. 1 root root    15 Mar 15  2022 /usr/lib64/libffi.so -> libffi.so.8.1.0
lrwxrwxrwx. 1 root root    26 Feb  2 16:27 /usr/lib64/libffi.so.6 -> /usr/lib64/libffi.so.8.1.0
lrwxrwxrwx. 1 root root    15 Mar 15  2022 /usr/lib64/libffi.so.8 -> libffi.so.8.1.0
-rwxr-xr-x. 1 root root 43264 Mar 15  2022 /usr/lib64/libffi.so.8.1.0

But obviously it wasn't that easy. The error in the web-ui changed to a non-descriptive "An error has occurred during salt execution: unable to parse json.". The bundle rpm doesn't even get installed (see later for the manual installation). More info can be checked in the salt master api log:

2023-02-02 16:28:30,004 [salt.utils.templates:274 ][ERROR   ][25840] Rendering exception occurred
Traceback (most recent call last):
  File "/usr/lib/python3.6/site-packages/salt/utils/templates.py", line 501, in render_jinja_tmpl
    template = jinja_env.from_string(tmplstr)
  File "/usr/lib/python3.6/site-packages/jinja2/environment.py", line 880, in from_string
    return cls.from_code(self, self.compile(source), globals, None)
  File "/usr/lib/python3.6/site-packages/jinja2/environment.py", line 591, in compile
    self.handle_exception(exc_info, source_hint=source_hint)
  File "/usr/lib/python3.6/site-packages/jinja2/environment.py", line 780, in handle_exception
    reraise(exc_type, exc_value, tb)
  File "/usr/lib/python3.6/site-packages/jinja2/_compat.py", line 37, in reraise
    raise value.with_traceback(tb)
  File "<unknown>", line 302, in template
  File "/usr/lib/python3.6/site-packages/jinja2/environment.py", line 497, in _parse
    return Parser(self, source, name, encode_filename(filename)).parse()
  File "/usr/lib/python3.6/site-packages/jinja2/parser.py", line 901, in parse
    result = nodes.Template(self.subparse(), lineno=1)
  File "/usr/lib/python3.6/site-packages/jinja2/parser.py", line 883, in subparse
    rv = self.parse_statement()
  File "/usr/lib/python3.6/site-packages/jinja2/parser.py", line 130, in parse_statement
    return getattr(self, 'parse_' + self.stream.current.value)()
  File "/usr/lib/python3.6/site-packages/jinja2/parser.py", line 213, in parse_if
    'name:endif'))
  File "/usr/lib/python3.6/site-packages/jinja2/parser.py", line 170, in parse_statements
    self.fail_eof(end_tokens)
  File "/usr/lib/python3.6/site-packages/jinja2/parser.py", line 104, in fail_eof
    return self._fail_ut_eof(None, stack, lineno)
  File "/usr/lib/python3.6/site-packages/jinja2/parser.py", line 90, in _fail_ut_eof
    self.fail(' '.join(message), lineno)
  File "/usr/lib/python3.6/site-packages/jinja2/parser.py", line 59, in fail
    raise exc(msg, lineno, self.name, self.filename)
jinja2.exceptions.TemplateSyntaxError: Unexpected end of template. Jinja was looking for the following tags: 'elif' or 'else' or 'endif'. The innermost block that needs to be closed is 'if'.

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/lib/python3.6/site-packages/salt/utils/templates.py", line 261, in render_tmpl
    output = render_str(tmplstr, context, tmplpath)
  File "/usr/lib/python3.6/site-packages/salt/utils/templates.py", line 520, in render_jinja_tmpl
    "Jinja syntax error: {}{}".format(exc, out), line, tmplstr
salt.exceptions.SaltRenderError: Jinja syntax error: Unexpected end of template. Jinja was looking for the following tags: 'elif' or 'else' or 'endif'. The innermost block that needs to be closed is 'if'.; line 302

---
[...]
reboot_transactional_server:
  mgrcompat.module_run:
    - name: transactional_update.reboot
    - require:
      - {{ salt_minion_name }}
{%- endif %}    <======================
---
2023-02-02 16:28:30,006 [salt.state       :4099][CRITICAL][25840] Rendering SLS 'base:bootstrap' failed: Jinja syntax error: Unexpected end of template. Jinja was looking for the following tags: 'elif' or 'else' or 'endif'. The innermost block that needs to be closed is 'if'.; line 302

---
[...]
reboot_transactional_server:
  mgrcompat.module_run:
    - name: transactional_update.reboot
    - require:
      - {{ salt_minion_name }}
{%- endif %}    <======================
---

Expected behavior
Salt bundle should work just fine. Something wrong with an old version libffi?

Screenshots
NA

Versions Report

salt --versions-report (Provided by running salt --versions-report. Please also mention any differences in master/minion versions.)

Master (uyuni):

vm-cachitomio:~ # salt --versions-report
Salt Version:
          Salt: 3004
 
Dependency Versions:
          cffi: 1.13.2
      cherrypy: unknown
      dateutil: 2.8.1
     docker-py: Not Installed
         gitdb: Not Installed
     gitpython: Not Installed
        Jinja2: 2.10.1
       libgit2: 1.3.0
      M2Crypto: 0.38.0
          Mako: Not Installed
       msgpack: 0.5.6
  msgpack-pure: Not Installed
  mysql-python: Not Installed
     pycparser: 2.17
      pycrypto: 3.9.0
  pycryptodome: Not Installed
        pygit2: 1.7.0
        Python: 3.6.15 (default, Sep 23 2021, 15:41:43) [GCC]
  python-gnupg: Not Installed
        PyYAML: 5.4.1
         PyZMQ: 17.1.2
         smmap: Not Installed
       timelib: Not Installed
       Tornado: 4.5.3
           ZMQ: 4.2.3
 
System Versions:
          dist: opensuse-leap 15.4 
        locale: UTF-8
       machine: x86_64
       release: 5.14.21-150400.24.41-default
        system: Linux
       version: openSUSE Leap 15.4 

Minion (after manually installing the package venv-salt-minion-3004-54.7.x86_64):

[root@vm-panaditas ~]# venv-salt-minion --versions-report
Salt Version:
          Salt: 3004
 
Dependency Versions:
          cffi: Not Installed
      cherrypy: Not Installed
      dateutil: Not Installed
     docker-py: 4.2.0
         gitdb: Not Installed
     gitpython: Not Installed
        Jinja2: 3.0.3
       libgit2: Not Installed
      M2Crypto: 0.38.0
          Mako: Not Installed
       msgpack: 0.5.6
  msgpack-pure: Not Installed
  mysql-python: Not Installed
     pycparser: Not Installed
      pycrypto: Not Installed
  pycryptodome: Not Installed
        pygit2: Not Installed
        Python: 3.10.5 (main, Jul 20 2022, 09:44:52) [GCC]
  python-gnupg: Not Installed
        PyYAML: 5.4.1
         PyZMQ: 23.2.0
         smmap: Not Installed
       timelib: Not Installed
       Tornado: 4.5.3
           ZMQ: 4.2.3
 
System Versions:
          dist: openeuler 22.03 
        locale: utf-8
       machine: x86_64
       release: 5.10.0-60.18.0.50.oe2203.x86_64
        system: Linux
       version: openEuler 22.03 
PASTE HERE

Additional context
Add any other context about the problem here.

[BUG] salt-master 3004-9.10 and python310-pyzmq-23.2.0-1.1 issue

Description
salt-master can't connect to zmq bus because of an error in salt/transport/zeromq.py
see: saltstack/salt#62119

Setup
salt-master and salt-minion running on opensuse tumbleweed same machine.

Please be as specific as possible and give set-up details.

  • on-prem machine
  • VM (Virtualbox, KVM, etc. please specify)
  • VM running on a cloud service, please be explicit and add details
  • container (Kubernetes, Docker, containerd, etc. please specify)
  • or a combination, please be explicit
  • jails if it is FreeBSD

Steps to Reproduce the behavior

start salt-master -l all

Traceback (most recent call last):
  File "/usr/local/lib/python3.10/multiprocessing/process.py", line 315, in _bootstrap
    self.run()
  File "/usr/local/lib/python3.10/multiprocessing/process.py", line 108, in run
    self._target(*self._args, **self._kwargs)
  File "/usr/local/lib/python3.10/site-packages/salt/transport/zeromq.py", line 1020, in _publish_daemon
    pub_sock.setsockopt(zmq.HWM, self.opts.get("pub_hwm", 1000))
  File "zmq/backend/cython/socket.pyx", line 447, in zmq.backend.cython.socket.Socket.set
  File "zmq/backend/cython/socket.pyx", line 279, in zmq.backend.cython.socket._setsockopt
  File "zmq/backend/cython/checkrc.pxd", line 28, in zmq.backend.cython.checkrc._check_rc
zmq.error.ZMQError: Invalid argument

Expected behavior
no errors and salt-master and salt-minion can communicate with each other

Versions Report

salt --versions-report (Provided by running salt --versions-report. Please also mention any differences in master/minion versions.)
Salt Version:
Salt: 3004

Dependency Versions:
cffi: 1.15.0
cherrypy: 18.6.1
dateutil: 2.8.2
docker-py: Not Installed
gitdb: Not Installed
gitpython: Not Installed
Jinja2: 3.0.3
libgit2: 1.4.3
M2Crypto: 0.38.0
Mako: Not Installed
msgpack: 1.0.4
msgpack-pure: Not Installed
mysql-python: Not Installed
pycparser: 2.21
pycrypto: 3.15.0
pycryptodome: Not Installed
pygit2: 1.9.1
Python: 3.10.5 (main, Jun 06 2022, 22:34:44) [GCC]
python-gnupg: Not Installed
PyYAML: 6.0
PyZMQ: 23.2.0
smmap: Not Installed
timelib: 0.2.4
Tornado: 4.5.3
ZMQ: 4.3.4

System Versions:
dist: opensuse-tumbleweed 20220703 n/a
locale: utf-8
machine: x86_64
release: 5.18.6-1-default
system: Linux
version: openSUSE Tumbleweed 20220703 n/a

Additional context

fix is already in saltstack main repo:
void-linux/void-packages#37369

"An importable Python 2 pip module is required" for pip.installed

Description of Issue/Question

The package python-gnupg is necessary to decrypt passwords with gpg in Salt. openSUSE Leap is providing only python-python-gnupg or python3-python-gnupg which are not containing the package for decryption. Therefore I wanted to install that with pip.installed.
After that I received following message:

  Function: pip.installed
  Name: python-gnupg
  Result: False
 Comment: An importable Python 2 pip module is required but could not be found on your system.      This usually means that the system's pip package is not installed properly.
 Started: 16:20:59.651024
Duration: 1.738 ms
 Changes:

The package python2-pip is installed on the salt master and on the client.
It seems that is a result of 2018 with urllib3: saltstack/salt#46163 (comment)

Setup

python-gnupg-installation:
pip.installed:
- name: python-gnupg
- require:
- pkg: gpg-decryption

gpg-decryption:
pkg.installed:
- names:
- python2-python-gnupg
- gpg2
- python2-pip

Steps to Reproduce Issue

  1. Install Salt on openSUSE Leap 15.0
  2. Create a SLS file with the content above
  3. Add any client as a salt-minion
  4. Execute (apply) the SLS on the openSUSE system
  5. You can not use pip.installed.

Versions Report

salt 2018.3.2

Upstreaming patches: filter_by_networks

Index: salt-2019.2.2-suse/salt/utils/network.py
===================================================================
--- salt-2019.2.2-suse.orig/salt/utils/network.py
+++ salt-2019.2.2-suse/salt/utils/network.py
@@ -2032,3 +2032,42 @@ def is_fqdn(hostname):
 
     compliant = re.compile(r"(?!-)[A-Z\d\-\_]{1,63}(?<!-)$", re.IGNORECASE)
     return "." in hostname and len(hostname) < 0xff and all(compliant.match(x) for x in hostname.rstrip(".").split("."))
+
+
+def _filter_by_networks(values, networks):
+    filtered_addresses = []
+
+    for value in values:
+        address = ipaddress.ip_address(value)
+        for network in networks:
+            if network.__contains__(address):
+                filtered_addresses.append(value)
+
+    return filtered_addresses
+
+
+@jinja_filter('filter_by_networks')
+def filter_by_networks(values, filters=None):
+    '''
+    Returns a the list of IPs filtered by the optional network list.
+    If no filter is specified all all items are returned.
+    {% set networks = ['192.168.0.0/24', 'fe80::/64'] %}
+    {{ grains['ip_interfaces'] | filter_by_networks(networks) }}
+    {{ grains['ipv6'] | filter_by_networks(networks) }}
+    {{ grains['ipv4'] | filter_by_networks(networks) }}
+    '''
+    if filters:
+        networks = [ipaddress.ip_network(network) for network in filters]
+        new_values = None
+        if isinstance(values, dict):
+            new_values = {}
+            for interface, addresses in values.items():
+                new_values[interface] = _filter_by_networks(addresses,
+                                                            networks)
+        elif isinstance(values, list):
+            new_values = _filter_by_networks(values, networks)
+        else:
+            raise ValueError('Do not know how to filter a {}'.format(type(values)))
+        return new_values
+    else:
+        return values

[BUG] running pkg.version_cmp on openEuler minions fails

Description
Running pkg.version_cmp on openEuler minions fails. PR fixing the problem will be created soon.

Setup
Salt master is a uyuni server, latest available version (based on opensuse 15.4). Salt minion is an openEuler 22.03 LTS with latest patches.

  • on-prem machine
  • VM (KVM)
  • VM running on a cloud service, please be explicit and add details
  • container (Kubernetes, Docker, containerd, etc. please specify)
  • or a combination, please be explicit
  • jails if it is FreeBSD

Steps to Reproduce the behavior

uyuni:~ # salt '192*' pkg.version_cmp 4.10.0-3.oe2203 4
192.168.122.173:
    The minion function caused an exception: Traceback (most recent call last):
      File "/usr/lib/venv-salt-minion/lib64/python3.10/site-packages/salt/minion.py", line 1916, in _thread_return
        return_data = minion_instance._execute_job_function(
      File "/usr/lib/venv-salt-minion/lib64/python3.10/site-packages/salt/minion.py", line 1873, in _execute_job_function
        return_data = self.executors[fname](opts, data, func, args, kwargs)
      File "/usr/lib/venv-salt-minion/lib64/python3.10/site-packages/salt/loader/lazy.py", line 149, in __call__
        return self.loader.run(run_func, *args, **kwargs)
      File "/usr/lib/venv-salt-minion/lib64/python3.10/site-packages/salt/loader/lazy.py", line 1203, in run
        return self._last_context.run(self._run_as, _func_or_method, *args, **kwargs)
      File "/usr/lib/venv-salt-minion/lib64/python3.10/site-packages/salt/loader/lazy.py", line 1218, in _run_as
        return _func_or_method(*args, **kwargs)
      File "/usr/lib/venv-salt-minion/lib/python3.10/site-packages/salt/executors/venv.py", line 24, in execute
        return __executors__["direct_call.execute"](opts, data, func, args, kwargs)
      File "/usr/lib/venv-salt-minion/lib64/python3.10/site-packages/salt/loader/lazy.py", line 149, in __call__
        return self.loader.run(run_func, *args, **kwargs)
      File "/usr/lib/venv-salt-minion/lib64/python3.10/site-packages/salt/loader/lazy.py", line 1203, in run
        return self._last_context.run(self._run_as, _func_or_method, *args, **kwargs)
      File "/usr/lib/venv-salt-minion/lib64/python3.10/site-packages/salt/loader/lazy.py", line 1218, in _run_as
        return _func_or_method(*args, **kwargs)
      File "/usr/lib/venv-salt-minion/lib/python3.10/site-packages/salt/executors/direct_call.py", line 10, in execute
        return func(*args, **kwargs)
      File "/usr/lib/venv-salt-minion/lib64/python3.10/site-packages/salt/loader/lazy.py", line 149, in __call__
        return self.loader.run(run_func, *args, **kwargs)
      File "/usr/lib/venv-salt-minion/lib64/python3.10/site-packages/salt/loader/lazy.py", line 1203, in run
        return self._last_context.run(self._run_as, _func_or_method, *args, **kwargs)
      File "/usr/lib/venv-salt-minion/lib64/python3.10/site-packages/salt/loader/lazy.py", line 1218, in _run_as
        return _func_or_method(*args, **kwargs)
      File "/usr/lib/venv-salt-minion/lib/python3.10/site-packages/salt/modules/yumpkg.py", line 685, in version_cmp
        return __salt__["lowpkg.version_cmp"](pkg1, pkg2, ignore_epoch=ignore_epoch)
      File "/usr/lib/venv-salt-minion/lib64/python3.10/site-packages/salt/loader/context.py", line 78, in __getitem__
        return self.value()[item]
      File "/usr/lib/venv-salt-minion/lib64/python3.10/site-packages/salt/loader/lazy.py", line 334, in __getitem__
        super().__getitem__(item)  # try to get the item from the dictionary
      File "/usr/lib/venv-salt-minion/lib64/python3.10/site-packages/salt/utils/lazy.py", line 105, in __getitem__
        raise KeyError(key)
    KeyError: 'lowpkg.version_cmp'
ERROR: Minions returned with non-zero exit code

uyuni:~ # salt '192*' grains.get os_family
192.168.122.173:
    openEuler

Expected behavior

uyuni:~ # salt '192*' grains.get os_family
192.168.122.173:
    openEuler

uyuni:~ # salt '192*' pkg.version_cmp 4.10.0-3.oe2203 4
192.168.122.173:
    1

Screenshots
If applicable, add screenshots to help explain your problem.

Versions Report
Master:

salt --versions-report (Provided by running salt --versions-report. Please also mention any differences in master/minion versions.)
uyuni:~ # salt --versions-report
Salt Version:
          Salt: 3004
 
Dependency Versions:
          cffi: 1.13.2
      cherrypy: unknown
      dateutil: 2.8.1
     docker-py: Not Installed
         gitdb: Not Installed
     gitpython: Not Installed
        Jinja2: 2.10.1
       libgit2: 1.3.0
      M2Crypto: 0.38.0
          Mako: Not Installed
       msgpack: 0.5.6
  msgpack-pure: Not Installed
  mysql-python: Not Installed
     pycparser: 2.17
      pycrypto: 3.9.0
  pycryptodome: Not Installed
        pygit2: 1.7.0
        Python: 3.6.15 (default, Sep 23 2021, 15:41:43) [GCC]
  python-gnupg: Not Installed
        PyYAML: 5.4.1
         PyZMQ: 17.1.2
         smmap: Not Installed
       timelib: Not Installed
       Tornado: 4.5.3
           ZMQ: 4.2.3
 
System Versions:
          dist: opensuse-leap 15.4 
        locale: UTF-8
       machine: x86_64
       release: 5.14.21-150400.22-default
        system: Linux
       version: openSUSE Leap 15.4 

Minion:

salt --versions-report (Provided by running salt --versions-report. Please also mention any differences in master/minion versions.)
[root@openeuler ~]# venv-salt-call --versions-report
Salt Version:
          Salt: 3004
 
Dependency Versions:
          cffi: Not Installed
      cherrypy: Not Installed
      dateutil: Not Installed
     docker-py: 4.2.0
         gitdb: Not Installed
     gitpython: Not Installed
        Jinja2: 2.10.1
       libgit2: Not Installed
      M2Crypto: 0.38.0
          Mako: Not Installed
       msgpack: 0.5.6
  msgpack-pure: Not Installed
  mysql-python: Not Installed
     pycparser: Not Installed
      pycrypto: Not Installed
  pycryptodome: Not Installed
        pygit2: Not Installed
        Python: 3.10.2 (main, Mar 01 2022, 07:23:53) [GCC]
  python-gnupg: Not Installed
        PyYAML: 5.4.1
         PyZMQ: 22.2.1
         smmap: Not Installed
       timelib: Not Installed
       Tornado: 4.5.3
           ZMQ: 4.2.3
 
System Versions:
          dist: openeuler 22.03 
        locale: utf-8
       machine: x86_64
       release: 5.10.0-60.18.0.50.oe2203.x86_64
        system: Linux
       version: openEuler 22.03 

Additional context
Add any other context about the problem here.

code understanding

Hi there, When I was learning and trying to understand the function "build_network_settings" in salt/salt/modules/debian_ip.py, I was confused about the description of the its delivered function. My understanding of this code snippet is "build the global script path". Do I understand that right?

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    πŸ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. πŸ“ŠπŸ“ˆπŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❀️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.