8

I am considering to move to salt (currently using ansible) to manage a set of standalone IoT devices (Raspberry Pi in practical terms).

The devices would be installed with a generic image, to which I would add on top the installation of salt (client side) as well as a configuration file pointing to salt-master, which is going to serve state files to be consumed by the minions.

The state files include an HTTP query for a name, which is then applied to the device (as its hostname). The obvious problem is that at that stage the minion has already registered with salt-master under the previous (generic) name.

How to handle such a situation? Specifically: how to propagate the new hostname to salt-master? (just changing the hostname and rebooting did not help, I assume the hostname is bundled, on the server, with the ID of the minion).

The more general question would be whether salt is the right product for such a situatiuon (where setting the state of the minion changes its name, among others)

WoJ
  • 27,165
  • 48
  • 180
  • 345

3 Answers3

13

Your Minion ID is based on the hostname during the installation. When you change the hostname after you installed the salt-minion, the Minion ID will not change.

The Minion ID is specified in /etc/salt/minion_id. When you change the Minion ID:

  • The Minion will identify itself with the new ID to the Master and stops listening to the old ID.
  • The Master will detect the new Minion ID as a new Minion and it shows a new key in Unaccepted Keys.
  • After accepting the key on the Master you will be able to use the Minion with the new key only. The old key is still accepted on the Master but doesn't work anymore.

I can come up with two solutions for your situation:

  1. Use salt-ssh to provision your minions. The Master will connect to your Raspberry PI using SSH. It will setup the correct hostname, install and configure salt-minion. After this is finished, your minion will connect to the master with the correct ID. But this requires the Master to know when and where a minion is available...
  2. You mentioned the state where the hostname is set. Change the Minion ID and restart the minion service in the same state. This will change the Minion ID but you need to accept the new key afterwards. Note that the minion will never report a state as successfully finished when you restart the salt-minion service in it.
Josh Correia
  • 3,807
  • 3
  • 33
  • 50
Gijs Brandsma
  • 933
  • 7
  • 13
  • 1
    Thank you. The first solution is one of the reasons I am considering migrating from `ansible` (the need to know how to contact the clients). The second soulution is very interesting - even if this means doing some cleanup on the server afterwards (to delete the old keys and accept the new ones). – WoJ Dec 05 '17 at 10:14
2

Here is a short script to change the hostname/minion_id. It should also work well for batch jobs. Simply call the script like so: sudo ./change-minion-id oldminionid newminionid

change-minion-id:

#! /bin/bash

echo $2; salt "$1" cmd.run "echo $2> /etc/hostname && hostname $2 && hostname > /etc/salt/minion_id" && salt "$1" service.restart "salt-minion" && salt-key -d $1 -y && salt-key -a $2 -y
benathon
  • 7,455
  • 2
  • 41
  • 70
deput_d
  • 21
  • 2
1

My answer is a direct rip off from user deput_d. I modified it a bit for what I needed.

Even my code will return a Minion did not return. [No response] (due to the salt-minion restart) but this error should be ignored, just let it run. I wait for 40 seconds just to be sure that the minion has re-connected:

#!/bin/bash

echo "salt rename $1->$2"; salt "$1" cmd.run "echo $2> /etc/hostname && hostname $2 && hostname > /etc/salt/minion_id" && salt "$1" cmd.run "/etc/init.d/salt-minion restart &" || true
salt-key -d $1 -y && echo "Will sleep for 40 seconds while minion reconnects" && sleep 40 && salt-key -a $2 -y
benathon
  • 7,455
  • 2
  • 41
  • 70