Minion registration with incorrect hostname???

[Jonathan Sanders]

Hello, I have a minion attempting to register with my Master as 66-152-109-25.tvc-ip.com. The hostname is completely different, and I can not seem to tell why in the world it would do so. I also have a second minion that is failing to register completely. I have attached the minion and master logs.

Please let me know your thoughts, thanks!

Jon

[Sean Coates]

> Hello, I have a minion attempting to register with my Master as 66-152-109-25.tvc-ip.com. The hostname is completely different, and I can not seem to tell why in the world it would do so. I also have a second minion that is failing to register completely. I have attached the minion and master logs.

You probably have a minion ID locked in (probably inherited from DHCP before the hostname was set explicitly, but after the salt minion started for the first time). Try /etc/salt/minion_id (if you delete it, the minion will create a new one with your current hostname).

S

[Jonathan Sanders]

Thanks Sean,

I have so far deleted on the Minions /etc/salt/minion_id, /etc/salt/minion/*, and /var/cache/salt/* with no prevail.

Running python -c 'import socket; print socket.getfqdn()' on these minions returns: 66-152-109-25.tvc-ip.com. But I have no clue as to where this could be coming from.

[Mike Flood]

Hi Jonathon,
That name is coming from the PTR record associated with the IP address of the host.
Unless you can change that PTR record, it's easiest just to override the name set in the minion_id file and restart the salt-minion service.

[Jonathan Sanders]

Genius Mike, something so simple, yet we should be able to work that into our startup scripts on new imaged devices when it renames the hostname.

Thanks a ton! 

[Dan Garthwaite]

I always hardcode the minion id. I then have state.highstate set hostname, /etc/hosts, /etc/resolv.conf, etc, based on the minion name. Relying on anything else to get the name right leads to madness.