Saltstack中关于ID的那些故事

tgdf

今儿个来说说关于ID设置这些事儿，以及碰到问题解决过程。希望对大家有用....

在前期主机名规划当中，我们会根据业务特定设计出一套主机名识别方法。。
有一天，一台测试机器安装完毕，但在Saltstack认证key时，会发现master和minions对接时，发现minion传过来的ID是localhost.localdomain，就奇怪了，这是为什么呢。？

默认主机操作系统安装完毕，/etc/sysconfig/network配置文件的hostname是localhost.localdomain，当你在salt master和minion认证时(未显示指定minion id情情况下)，对端接受后，minion id一定是localhost.localdomain。。请看下面的认证过程


minion和master认证过程
1.minion在启动时，会在/etc/salt/pki/minion下自动生成minion.pem和minion.pub，然后将minion.pub发送给master。
2.master在收到minion的public key，我们在通过salt-key -a允许minion key，这样就会在master的/etc/salt/pki/master/minions下面存放以minion id命名的public key，此时认证通信已完成

上述认证过程不难发现，master是在收到minion传过来的public key，然后以minion id为其命名的。而有些的是localhost.localdomain，这是神马原因呢。？

前期未在salt minion的配置文件中显示指定minion id时，那将以默认值传递，那么这个默认值是这么得来的呢。？
在配置文件中有这么一段话， if left commented the id will be the hostname as returned by the python call: socket.getfqdn()， 是通过socket.getfqdn()函数获取而来。

那么我们可以写个小脚本来验证fqdn

1 2 3 4

cat a.py #!/usr/bin/python env import socket print socket.getfqdn(socket.gethostname())

验证
[roo@test-01 ~]# python a.py
localhost.localdomain
在执行脚本验证时，发现FQDN不正确，这就需要重新配置Hostname  #重现场景

Hostname配置方法
1. /etc/sysconfig/network
NETWORK = XXXX
配置完毕，重新network服务

2./etc/hosts，做映射
内网IP  HOST
hostname -f进行验证fqdn，在执行a.py脚本验证，在删除缓存minion_id(为什么请看下面)

这里又碰到个小问题，在未重新配置hostname而直接连接salt master，传过去的key会是localhost.localdomain，这个时候你重新设置完hostname，从master上删除localhost.localdomain这个ID，再认证永远都是这个id，除非你强制指定id(minion端配置文件的ID项)。为什么呢.?  我们来看下minion启动过程



第二行，他使用了cache的minion id， minion在启动时会生成一个id文件，这个文件就在/etc/salt/minion_id，然后会加载进cache，每次重启都会读取这个，这就是为什么永远是localhost.localdomian id的原因
文件内容为
cat /etc/salt/minion_id
localhost.localdomain

上述解决办法，删除minion id文件
minion#  rm -f /etc/salt/minion_id
minion#  /etc/salt/minion restart

重新认证，即可解决问题~~

好啦。关于id这个，碰到的问题都在这。。
推荐：在连接master时配置好Hostname，并能解析FQDN，再进行salt master认证；希望对你有帮助