minion id: getfqdn() vs. gethostname()

[Dan Garthwaite]

On my debian systems, if I add a second IP address ( eth0:1 ) socket.getfqdn() returns the wrong hostname.   The (often) private IP address assigned to eth0:1 is listed before eth0 when quering IPs, and gethostbyip() is run against the eth0:1 address.

This leads to unacceptable key names in salt-master.

Setting the ID in /etc/salt/minion is a confirmed work around.

As a sys admin, I expect the canonical FQDN of a server to be what I set it to be in /etc/hostname, or to be able to override it on a per environment basis using the HOSTNAME environment variable.

I propose using socket.gethostname()  for ID, or adding some logic to reject ethN:N FQDN's in favor of the base NIC's ip.

[Dan Garthwaite]

Some details on this.  The last command shows what I think is happening, the IP address for eth0:1 is listed before eth0.

root@drone1:~

# head -5 /etc/hosts

127.0.0.1       localhost

127.0.1.1       drone1.example.com drone1

# The following lines are desirable for IPv6 capable hosts

::1     ip6-localhost ip6-loopback

root@drone1:~

# hostname

drone1.example.com

root@drone1:~

# cat /etc/hostname

drone1.example.com

root@drone1:~

# grep domain /etc/resolv.conf

domain example.com

root@drone1:~

# python -c 'import socket; print socket.getfqdn()'

liXXX-XXX.members.linode.com

root@drone1:~

# python -c 'import socket; print socket.gethostname()'

drone1.example.com

root@drone1:~

# ip addr | grep inet

    inet 127.0.0.1/8 scope host lo

    inet6 ::1/128 scope host

    inet 192.168.XXX.XXX/17 brd 192.168.255.255 scope global eth0:1

    inet 50.116.XX.XXX/24 brd 50.116.XXX.255 scope global eth0

    inet6 2600:XXXX:XXXX::XXXX:XXXX/64 scope global dynamic

    inet6 fe80::XXXX:XXXX:XXXX:XXXX/64 scope link

[Thomas S Hatch]

This has come up before with strong arguments on both sides. I don't want to make a major change that could break everyone's existing setups. I think that the correct solution here is to add some logic to salt for this process. The other problem is that I have seen some varying behavior here on different platforms.

Does anyone else have any input here? I think that this is a legitimate problem but I would like to hear some more input on it.

[Bret Palsson]

Here are some ideas, but haven't had time to implement or try:

We can still use the fqdn or hostname for easy identification, human readable… but each minion/master should have it's own UUID of some sort that all operations key off of. This way we can ensure uniqueness. I'm not sure if the public key should be stored as hostname or the uuid and a comment placed after the "-----END PUBLIC KEY-----" than can be parsed to get the readable name.

Obviously this idea need lots more baking… any feedback?

-Bret

[Thomas S Hatch]

I think that a generated specific uuid could be used to double track the key association, we also have the serverid grain

[Dan Garthwaite]

I searched the mailing list before posting for previous discussions and didn't find any.

What would the decision tree look like?  Gather all IP addresses and rank them in order of likeliness?

Least to most:

Loopbacks.   Virtualbox's 10.0.2.15.   Private IP space 1..N.  Public IP space 1..N.   Then try and determine the "base" virtual NIC?

[Sean Channel]

hostname and fqdn are really two different things in practice. I've also had
Salt come up with names that are not what I expected for this same reason. I
think gethostname() is going to return more predictable results in that regard.

_S

[Dan Garthwaite]

... because the sys admin has explicit control over it.

[Thomas S Hatch]

Yes, this is honestly a tough call, because we would gather all ip addrs and then basically need to look for the first non localhost name and have a fairly predictable sequence.

[Sean Channel]

'hostnames' are local, for admin purposes, whereas an FQDN is an internet
address for production URLs. A system may or may not have an internet FQDN, but
will always have a hostname (even if "localhost"), which I kind of expect to be
the default.

it seems simpler to use gethostname(), then determine which port is configured
w/ the corresponding address, rather than try to guess, but I'm sure there are
many factors.

_S.

[Corey Quinn]

I agree wholeheartedly. I can set this easily in EC2-- I can't get an FQDN that makes sense to humans for love or money.

Make it a toggle, I'll whack it every time.