re-registering a salt minion

[Zippy Zeppoli]

Hi List,
I was wondering, what is the proper process for re-registering a salt minion?

I imagine it's something like:

1) Shutdown minion
2) Delete /var/cache/salt/* on the minion
3) startup minion

Thanks in advance

[David Boucha]

Delete the minion's key:

salt-key -d 'minionname'

You may have to restart the minion.

salt-key -a 'minionname'

[Jeff Bauer]

Zippy,

You also have to delete the old minion key from the master:

# rm /etc/salt/pki/minions/<old-minion-key>

And afterward, accept the new minion key.

Jeff Bauer
Rubicon, Inc.

[Sean Channel]

It is not be necessary to also remove the key file. salt-key should take
care of that.

_S.

[Jeff Bauer]

Yes, I posted before I saw David's reply to use salt-key to
delete the old minion key.

-Jeff

[Zippy Zeppoli]

Hmm,
on the master I did salt-key -D
then I show now minions on the master:

# salt-key -L
Unaccepted Keys:
Accepted Keys:
Rejected:


Then I restarted the minion and I don't see it show up when I do salt-key -L

[Trevor Walker]

-D and -d are different

-D would have deleted all your minion keys

[Zippy Zeppoli]

It still would have deleted the offender, would it have not?
So this is mutually exclusive of removing it via -d?

So far yum remove salt is the only thing that works.
I'm looking for something a bit less intrusive.

I recall doing it before, I'm just wondering where / how the actual registration data is saved?

[Trevor Walker]

Sorry,  I thought you were concerned about the output of salt-key -L after running salt-key -D.

I see that you were expecting that behavior

I think that data is stored in the /etc/salt/pki directory

on the master in the /minions directory there should be a file with minion id as the name

on the minion there are 3 files present in that directory (of which the minion.pub file should have the same content as the <minion id> file on the master)

Are you successfully starting the minion? are there errors in the log?

You can start the minion manually with debug on with:

salt-minion -d --log-level=debug 

This usually spits out any pki issues quickly

[Sean Channel]

There isn't any registration data. The minions just 'subscribe' to the
master and listen for commands. Salt will synchronize the minions with
anything they need when commands are issued.

Your output was normal. The minions would have all shown up again under
unaccepted keys at some point, but restarting them is a good way to make
sure.

_S.

>>>>>> # rm /etc/salt/pki/minions/<old-**minion-key>

[Sean Channel]

I'm sorry, I misread that. If you *don't* see any minions coming back,
try re-starting salt-master.

If you are still having trouble getting the minions to connect, you
could also try setting "pub_refresh: False" in the master config (and
re-start salt-master)

_S.

[HansJ]

I did the following on the salt-master:

# salt-key -d <minion-name>


... then on the salt-minion:

# service salt-minion restart


... then back on the salt-master:

# salt-key -L

... or

# salt-key -F

.. to see all fingerprints of all keys ... and finally

# salt-key -a <minion-name>


NOTE:

If not done already you need to add to the configuration file '/etc/hosts'
on the mineon (or add the salt-master ip-addr to the config of the mineon):

<IP-address-of-salt-master> salt

... and restart the salt-mineon:

# service salt-mineon restart

[Josh Smith]

In case anyone coming across this has changed the minion's hostname, I found running 

salt-minion -g --log-level=debug

showed that the old hostname was cached in 

/etc/salt/minion_id

Deletiong the key from the Salt master, changing this and then restarting the salt-minion process sent the new hostname to the master.