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
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>
  • unfortunatelly not working for me, 04/2016 – Divisadero Apr 14 '16 at 6: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 2 days ago
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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.