3

The short version: How to get test.ping to work, after keys are -Added? And how to re-push a key if you -Deleted it from the master?

The long version: Steps to reproduce:

  • on two RPIs
  • install the latest Raspbian on an RPI from the 2014-09-09-wheezy-raspbian image
  • aptitude upgrade
  • aptitude install build-essential python-dev javascript-common libjs-jquery msgpack-python python-async python-crypto python-git python-gitdb python-jinja2 python-m2crypto python-mako python-markupsafe python-pkg-resources python-smmap python-yaml wwwconfig-common
  • add deb http://debian.saltstack.com/debian wheezy-saltstack main to /etc/apt/sources.list
  • install salt 2014.7.0 or thereabouts
  • doesn't work
  • uninstall it
  • git clone --depth=1 https://github.com/saltstack/salt.git
  • sudo pip install -e ./salt
  • on the minion RPI, edit /etc/salt/minion and change master: salt to the IP of the master.
  • salt-master -l debug on one RPI, and salt-minion -l debug
  • salt-key -L shows the minion key. salt-key -A to accept it
  • salt --verbose '*' test.ping. Does nothing
  • salt-key -D on the master.
  • erase the keys from /etc/salt/pki/minion/... on the minion
  • restart the minion to generate new keys

When I had the factory-compiled salt, test.ping did nothing, and the traffic on SuperUser (and lessor sites) implied I should get the latest version. As usual. So when I did, I decided to try recycling the keys.

Now I can't get the minion's new keys to appear in salt-key -L.

The debug tracings from the minion only say happy things like [DEBUG ] Attempting to authenticate with the Salt Master at 192.168.0.19 / [DEBUG ] Loaded minion key: /etc/salt/pki/minion/minion.pem.

The debug tracings from the server only say happy things like generating master keys.

Then the minion says SaltReqTimeoutError: after 60 seconds.

In online posts about that error, people only answer with the "is the CPU switched on?" style answers. Yes, there's no firewall between the two RPIs. Yes, I can telnet to the correct IP and port. Yes, everyone's running as root, in debug mode.

So what am I missing from my mental model of this situation? If I get the keys to work, test.ping won't work. An entire project is held up, waiting for this one stupid configuration detail...

inb4 someone asks for the salt --versions-report:

           Salt: 2014.7.0-n/a-43c01ef
         Python: 2.7.3 (default, Mar 18 2014, 05:13:23)
         Jinja2: 2.6
       M2Crypto: 0.21.1
 msgpack-python: 0.4.2
   msgpack-pure: Not Installed
       pycrypto: 2.6
        libnacl: Not Installed
         PyYAML: 3.10
          ioflo: Not Installed
          PyZMQ: 14.3.1
           RAET: Not Installed
            ZMQ: 4.0.4
           Mako: 0.7.0
user246604
  • 131
  • 1
  • 1
  • 5

2 Answers2

2

Following procedure to reset a minion's key works for me (tested on salt 2015.5.2 up to 2017.7.2):

  1. On master, delete current key: sudo salt-key -d <minion_name>
  2. On minion, restart the service: sudo systemctl restart salt-minion (or sudo service salt-minion restart on an older, non-systemd OS)
  3. Back to master, accept the new key: sudo salt-key -a <minion_name>
sxc731
  • 297
  • 2
  • 15
  • unfortunatelly not working for me, 04/2016 – Divisadero Apr 14 '16 at 06:55
  • This will work as long as you the minion knows where to look. Make sure that your /etc/hosts file has the salt host name listed with the master's IP (or add the IP directly into the /etc/salt/minion config file). – Gregory Martin May 16 '19 at 18:17
0

While the inner question - how to recover after -Deleting a key - remains unanswered, the answer to the outer question was, naturally, to re-image the SD card and install Salt version '2014.1.10' from the Aptitude repositories.

user246604
  • 131
  • 1
  • 1
  • 5