Software to automate the management and configuration of any infrastructure or application at scale. Get access to the Salt software package repository here:

Description My all servers with salt-minion installed，An unknown program suddenly ran today， He's /tmp/salt-minions

[root@yunwei ~]# top

top - 10:06:44 up 511 days, 18:39, 3 users, load average: 2.01, 2.02, 1.91 Tasks: 193 total, 1 running, 192 sleeping, 0 stopped, 0 zombie Cpu(s): 7.2%us, 18.3%sy, 0.0%ni, 74.1%id, 0.4%wa, 0.0%hi, 0.0%si, 0.0%st Mem: 8060948k total, 7502768k used, 558180k free, 76316k buffers Swap: 4194300k total, 437368k used, 3756932k free, 188012k cached

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
2280 root 20 0 56.0g 541m 1588 S 101.1 6.9 345886:48 tp_core
27061 root 20 0 2797m 1848 1000 S 99.1 0.0 36:02.75 salt-minions

[root@yunwei ~]# ps -ef |grep 27061 | grep -v grep root 27061 1 89 09:26 ? 00:36:37 /tmp/salt-minions

sal-minion version 2018.3.2 sys：CentOS release 6.5 (Final)

Since my upgrade to 14.04 and sync of @makinacorpus fork to last develop, something is weird.

I get intermittent total unfunctionnality of the saltmaster , on a period of 1 at 2 minutes, i cant ping any minion, and the next 2 minutes ping is working, and 2 minutes after this does not work.

 mastersalt '*' test.ping
Failed to authenticate, is this user permitted to execute commands?

I rebuilded all the eggs locally installed to be sure of the linking, but this seems not to be sufficient.

Ill check tomorow to double check if this is one of our maintainance crons, but i would suspect yet another regression.

Happy to be proven wrong here, but from my best understanding, calls to lxc.init will always fail as long as it attempts to remove the seed marker prior to starting the container.

remove_seed_marker is set to True at: https://github.com/saltstack/salt/blob/develop/salt/modules/lxc.py#L1197

The bit that looks like it could use some reordering is: https://github.com/saltstack/salt/blob/develop/salt/modules/lxc.py#L1230-L1259

Steps to reproduce:

$ salt-call lxc.init testbuntu template=ubuntu options="{'release':'trusty', 'arch': 'amd64'}"

First failure is in attachable()

[ERROR   ] Command 'lxc-attach --clear-env -n testbuntu -- /usr/bin/env' failed with return code: 1

Versions report:

$ salt --versions-report
                  Salt: 2015.5.0
                Python: 2.7.6 (default, Mar 22 2014, 22:59:56)
                Jinja2: 2.7.2
              M2Crypto: 0.21.1
        msgpack-python: 0.3.0
          msgpack-pure: Not Installed
              pycrypto: 2.6.1
               libnacl: Not Installed
                PyYAML: 3.10
                 ioflo: Not Installed
                 PyZMQ: 14.0.1
                  RAET: Not Installed
                   ZMQ: 4.0.4
                  Mako: 0.9.1
 Debian source package: 2015.5.0+ds-1trusty1

I have a RHEL6 minion running 0.15.3, which used to work fine, but at some point seems to have stopped responding to the master (which is also running 0.15). Any command (test.ping) that I attempt to run against this minion eventually fails with "Minion failed to return".

I tried starting up the minion in debug mode, but that didn't explain much to me:

#############
# /usr/bin/python /usr/bin/salt-minion -d -c /etc/salt -l debug
[DEBUG   ] Reading configuration from /etc/salt/minion
[DEBUG   ] Guessing ID. The id can be explicitly in set /etc/salt/minion
[INFO    ] Found minion id from getfqdn(): cuda-linux-gputest10
[INFO    ] Configuration file path: /etc/salt/minion

# tail -f /var/log/salt/minion
2013-06-17 15:47:26,440 [salt             ][INFO    ] Setting up the
Salt Minion "cuda-linux-gputest10"
2013-06-17 15:47:26,445 [salt.utils.process    ][DEBUG   ] Created
pidfile: /var/run/salt-minion.pid
2013-06-17 15:47:26,446 [salt.utils.process    ][DEBUG   ] Chowned
pidfile: /var/run/salt-minion.pid to user: root
2013-06-17 15:47:26,446 [salt.config           ][DEBUG   ] Reading
configuration from /etc/salt/minion
2013-06-17 15:47:26,493 [salt.loader           ][DEBUG   ] loading
grain in ['/var/cache/salt/minion/extmods/grains',
'/usr/lib/python2.6/site-packages/salt/grains']
2013-06-17 15:47:26,493 [salt.loader           ][DEBUG   ] Skipping
/var/cache/salt/minion/extmods/grains, it is not a directory
2013-06-17 15:47:26,551 [salt.minion           ][DEBUG   ] Attempting
to authenticate with the Salt Master at 10.31.96.152
2013-06-17 15:47:26,553 [salt.crypt            ][DEBUG   ] Loaded
minion key: /etc/salt/pki/minion/minion.pem
############

The only uncommented line in /etc/salt/minion is:

master: cuda-fs1

which is the correct hostname of the master, and the same as a few hundred other minions.

I looked at the master's salt log, but it has no references to this minion at all.

On the master,

salt --versions-report:
           Salt: 0.15.1
         Python: 2.7.3 (default, Jul 24 2012, 10:05:38)
         Jinja2: 2.6
       M2Crypto: 0.21.1
 msgpack-python: 0.1.13
   msgpack-pure: Not Installed
       pycrypto: 2.6
         PyYAML: 3.10
          PyZMQ: 2.2.0.1
            ZMQ: 3.2.2

On the minion:

salt-call --versions-report
           Salt: 0.15.3
         Python: 2.6.6 (r266:84292, Oct 12 2012, 14:36:13)
         Jinja2: unknown
       M2Crypto: 0.20.2
 msgpack-python: 0.1.9.final
   msgpack-pure: Not Installed
       pycrypto: 2.0.1
         PyYAML: 3.10
          PyZMQ: 2.2.0.1
            ZMQ: 3.2.2

Description of Issue/Question

I have a standby saltmaster on saltstack 2017.7.4 and I am trying to upgrade it to 8.3.0 salt just released. After 8.3.0 upgrade, I am getting following issue.

[root@salt01 ~]# sudo salt minion01 test.version
Salt request timed out. The master is not responding. 
You may need to run your command with `--async` in order to bypass the congested event bus. 
With `--async`, the CLI tool will print the job id (jid) and exit immediately without
 listening for responses.  You can then use `salt-run jobs.lookup_jid` to look up 
the results of the job in the job cache later.
[root@salt01 ~]#

Setup

(Please provide relevant configs and/or SLS files (Be sure to remove sensitive info).)

Steps to Reproduce Issue

• snapshot salt01 VM (VMware image) for backup.
• disable /etc/yum.repos.d/salt-latest.repo
• yum update -y && reboot
• enable /etc/yum.repos.d/salt-latest.repo
• yum update -y salt && reboot
• run test.ping on all minions or just one minion

[root@salt01 ~]# sudo salt minion01 test.version
Salt request timed out. The master is not responding. 
You may need to run your command with `--async` in order to bypass 
the congested event bus. With `--async`, the CLI tool will print the job id (jid) and 
exit immediately without listening for responses. You can then 
use `salt-run jobs.lookup_jid` to look up the results of the job in the job cache later.
[root@salt01 ~]#

• If I revert the salt01's VM image back to saltstack 7.4 version. this problem disappear.

Versions Report

• errors in systemctl status -l salt-master.

[root@salt01 ~]# systemctl status -l salt-master
? salt-master.service - The Salt Master Server
   Loaded: loaded (/usr/lib/systemd/system/salt-master.service; enabled; vendor preset: disabled)
   Active: active (running) since Wed 2018-04-04 09:08:33 CDT; 19min ago
     Docs: man:salt-master(1)
           file:///usr/share/doc/salt/html/contents.html
           https://docs.saltstack.com/en/latest/contents.html
 Main PID: 1090 (salt-master)
   CGroup: /system.slice/salt-master.service
           +-1090 /usr/bin/python /usr/bin/salt-master
           +-1480 /usr/bin/python /usr/bin/salt-master
           +-1707 /usr/bin/python /usr/bin/salt-master
           +-1708 /usr/bin/python /usr/bin/salt-master
           +-1715 /usr/bin/python /usr/bin/salt-master
           +-1716 /usr/bin/python /usr/bin/salt-master
           +-1717 /usr/bin/python /usr/bin/salt-master
           +-1718 /usr/bin/python /usr/bin/salt-master
           +-1724 /usr/bin/python /usr/bin/salt-master
           +-1726 /usr/bin/python /usr/bin/salt-master
           +-1727 /usr/bin/python /usr/bin/salt-master
           +-1728 /usr/bin/python /usr/bin/salt-master
           +-1729 /usr/bin/python /usr/bin/salt-master
           +-1730 /usr/bin/python /usr/bin/salt-master

Apr 04 09:12:15 salt01 salt-master[1090]: pub = salt.crypt.get_rsa_pub_key(pubfn)
Apr 04 09:12:15 salt01 salt-master[1090]: File "/usr/lib/python2.7/site-packages/salt/crypt.py", line 210, in get_rsa_pub_key
Apr 04 09:12:15 salt01 salt-master[1090]: key = RSA.load_pub_key(path)
Apr 04 09:12:15 salt01 salt-master[1090]: File "/usr/lib64/python2.7/site-packages/M2Crypto/RSA.py", line 406, in load_pub_key
Apr 04 09:12:15 salt01 salt-master[1090]: return load_pub_key_bio(bio)
Apr 04 09:12:15 salt01 salt-master[1090]: File "/usr/lib64/python2.7/site-packages/M2Crypto/RSA.py", line 422, in load_pub_key_bio
Apr 04 09:12:15 salt01 salt-master[1090]: rsa_error()
Apr 04 09:12:15 salt01 salt-master[1090]: File "/usr/lib64/python2.7/site-packages/M2Crypto/RSA.py", line 302, in rsa_error
Apr 04 09:12:15 salt01 salt-master[1090]: raise RSAError, m2.err_reason_error_string(m2.err_get_error())
Apr 04 09:12:15 salt01 salt-master[1090]: RSAError: no start line
[root@salt01 ~]#

• version report

[root@salt01 ~]# salt --versions-report
Salt Version:
           Salt: 2018.3.0

Dependency Versions:
           cffi: 1.6.0
       cherrypy: unknown
       dateutil: 1.5
      docker-py: Not Installed
          gitdb: 0.6.4
      gitpython: 1.0.1
          ioflo: 1.3.8
         Jinja2: 2.7.2
        libgit2: 0.24.6
        libnacl: 1.4.3
       M2Crypto: 0.21.1
           Mako: 0.8.1
   msgpack-pure: Not Installed
 msgpack-python: 0.5.1
   mysql-python: 1.2.5
      pycparser: 2.14
       pycrypto: 2.6.1
   pycryptodome: 3.4.3
         pygit2: 0.24.2
         Python: 2.7.5 (default, Aug  4 2017, 00:39:18)
   python-gnupg: Not Installed
         PyYAML: 3.11
          PyZMQ: 15.3.0
           RAET: Not Installed
          smmap: 0.9.0
        timelib: 0.2.4
        Tornado: 4.2.1
            ZMQ: 4.1.4

System Versions:
           dist: centos 7.4.1708 Core
         locale: UTF-8
        machine: x86_64
        release: 3.10.0-693.21.1.el7.x86_64
         system: Linux
        version: CentOS Linux 7.4.1708 Core

[root@salt01 ~]#

This is a massive overhaul of the entire transport system within salt (this is the one I mentioned @ SaltConf)

The basic idea in this PR is to abstract out the transport within salt-- since Salt shouldn't care how the bits are shipped to the minion, just that they can and will be. To do this I've taken the "channel" idea and run with it. To do this I've created a "reqchannel" and a "pubchannel" these 2 classes encapsulate the 2 types of messages that salt cares about. For each channel type there are server and client implementations, which means that adding a new transport is simply implementing a base-class and configuring the master.

Now that there is an interface to write transport to I also created a basic TCP implementation which uses the same auth as the current zeromq implementation.

In addition to the abstraction of transport this also introduces tornado as an async programming framework (read: ioloop). This means that we can actually run N transports on a master simultaneously. In addition to making all transport async-- this means we can now make API calls within the master/minion async-- meaning a given MWorker thread could actually have multiple requests in-flight (unlike the single request at a time of today).

In addition to running multiple transports at once this also means we can remove the threading we've been using in MultiMinion and Syndics-- and just use the IOLoop.

There is going to need to be some transition to the new Async interfaces, but this PR includes wrappers which make the async interfaces sync friendly-- so it should be 100% backwards compatible. This just means that if you want your module/runner/etc. to be async (meaning the thread can do something else) you'd have to switch your calls to channels (which are very uncommon) to the async versions.

Before we merge this in I'll need to finish up the docs, but I want to get this opened sooner rather than later to get other people's eyes on it.

I try this command but in my minion this command work by if it call that from the master it's jam and take infinite time

start_service:
   cmd.run:
      - name: 'service manticore start'
      - user: test_dev
      - group: test_dev

I change for this command

manticore:
   service:
      - running
      - enable: true
      - reload: true
      - require:
        - file: /etc/init.d/manticore

result:

----------
    State: - service
    Name:      manticore
    Function:  running
        Result:    True
        Comment:   Service manticore is already enabled, and is in the desired state
        Changes:

the service is not started and can't work ?

salt-master 0.15.3 salt-minion 0.15.1 CentOS release 6.4 (Final)

I started wrapping the boto VPC API and realized that I have no idea what should be exposed and what shouldn't. I'd like that you guys and @colinbjohnson to review this PR and https://boto.readthedocs.org/en/latest/ref/vpc.html and tell me what should I expose. This module is not tested at all. Can you guys provide instructions on how to test this? Should I be using moto? Does salt have an AWS environment where the integration tests can run?

Everything worked in 2014.1.3, to test as soon as I installed 2014.1.4 it stopped working.

Having this as pillar data on the minion.

docker-registries:
    https://index.private.io/v1:
        username: test
        password: test
        email: [email protected]

sudo salt 'minion' docker.pull index.private.io/project/image:latest --timeout 300

That command always results in a 403 error now, the authentication information is no longer being sent.

What does this PR do?

Brings few more Jinja filters & a potential solution for https://github.com/saltstack/salt/issues/37791

https://github.com/saltstack/salt/pull/37801 is for IP-specifc only, this one is more generic providing filters such default, min, max etc.

Tests written?

Yes

MSI installers for windows minions would be extremely beneficial for windows corporate environments. I use salt to manage all of our workstations and it's very useful for the remote systems that seldom see one of our offices or even a VPN. Having an MSI installer would allow minion deployment through group policies to existing systems (as they touch the corporate environment) and to new systems as they join the active directory domain using native windows deployment technologies.

Description When you go to the Downloads section of the website, the bar on top links to Tutorials from 2016 instead of the newer Salt User Guide. Every other tab on the website links to the Salt User Guide instead.

Suggested Fix Make all navbar tabs consistently link to documentation instead of changing when you go to different pages.

Type of documentation Salt documentation and Getting Started guide.

Location or format of documentation https://repo.saltproject.io/

Additional context I'm new to SaltStack and I find it rather confusing that different parts of the website link me to different documentation. Where am I actually supposed to start, documentation-wise? Some parts of the website say I should start with the Salt User Guide, while others say I should start with the Tutorials section.

Description of Issue

State ssh_auth.absent does not work with source file

SLS file example

xxxxxxx:
  ssh_auth.absent:
    - user: xxxxxxx
    - source: salt://sudo/files/xxxxxxx.rsa.pub-remove

If I do ssh_auth.absent state for the same key with -name and -enc parameters, without -source file it works properly. Same source file was used to add this key before with ssh_auth.present function which confirms that file is in correct authorized_keys format.

Reported error

          ID: xxxxxxx
    Function: ssh_auth.absent
      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 2277, 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 1228, 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 1243, in _run_as
                  return _func_or_method(*args, **kwargs)
                File "/usr/lib/python3.6/site-packages/salt/loader/lazy.py", line 1276, in wrapper
                  return f(*args, **kwargs)
                File "/usr/lib/python3.6/site-packages/salt/states/ssh_auth.py", line 464, in absent
                  key = key.rstrip().split("\n")
              AttributeError: 'bool' object has no attribute 'rstrip'
     Started: 14:21:05.560949
    Duration: 17.931 ms
     Changes:

Versions Report

Salt Version:
          Salt: 3005.1

Dependency Versions:
          cffi: Not Installed
      cherrypy: Not Installed
      dateutil: 2.6.1
     docker-py: Not Installed
         gitdb: Not Installed
     gitpython: Not Installed
        Jinja2: 2.10.1
       libgit2: Not Installed
      M2Crypto: 0.35.2
          Mako: Not Installed
       msgpack: 0.6.2
  msgpack-pure: Not Installed
  mysql-python: Not Installed
     pycparser: Not Installed
      pycrypto: Not Installed
  pycryptodome: Not Installed
        pygit2: Not Installed
        Python: 3.6.8 (default, Nov  9 2022, 09:57:34)
  python-gnupg: Not Installed
        PyYAML: 3.12
         PyZMQ: 20.0.0
         smmap: Not Installed
       timelib: Not Installed
       Tornado: 4.5.3
           ZMQ: 4.3.4

System Versions:
          dist: almalinux 8.7 Stone Smilodon
        locale: UTF-8
       machine: x86_64
       release: 4.18.0-348.20.1.el8_5.x86_64
        system: Linux
       version: AlmaLinux 8.7 Stone Smilodon

What does this PR do?

What issues does this PR fix or reference?

Fixes:

Previous Behavior

Remove this section if not relevant

New Behavior

Remove this section if not relevant

Merge requirements satisfied?

[NOTICE] Bug fixes or features added to Salt require tests.

• [ ] Docs
• [ ] Changelog - https://docs.saltproject.io/en/master/topics/development/changelog.html
• [ ] Tests written/updated

Commits signed with GPG?

Yes/No

Please review Salt's Contributing Guide for best practices.

See GitHub's page on GPG signing for more information about signing commits with GPG.

I spent a lot of time scheduling a job in salt 3004.1 and 3005.1. I found at https://docs.saltproject.io/salt/user-guide/en/latest/topics/scheduler.html#declaring-scheduled-jobs that job_args should be used not args.

What does this PR do?

What issues does this PR fix or reference?

Fixes: args parameter name

Previous Behavior

Remove this section if not relevant

New Behavior

Remove this section if not relevant

Merge requirements satisfied?

[NOTICE] Bug fixes or features added to Salt require tests.

• [ ] Docs
• [ ] Changelog - https://docs.saltproject.io/en/master/topics/development/changelog.html
• [ ] Tests written/updated

Commits signed with GPG?

Yes/No

Please review Salt's Contributing Guide for best practices.

See GitHub's page on GPG signing for more information about signing commits with GPG.

What does this PR do?

This is an alternate approach to #63257

What issues does this PR fix or reference?

Fixes:

Previous Behavior

Remove this section if not relevant

New Behavior

Remove this section if not relevant

Merge requirements satisfied?

[NOTICE] Bug fixes or features added to Salt require tests.

• [ ] Docs
• [ ] Changelog - https://docs.saltproject.io/en/master/topics/development/changelog.html
• [ ] Tests written/updated

Commits signed with GPG?

Yes/No

Please review Salt's Contributing Guide for best practices.

See GitHub's page on GPG signing for more information about signing commits with GPG.