Stories about IDs in saltstack

Today, let's talk about how to set IDs and how to solve problems. I hope it will be useful to you ....

In the early stage of Host Name planning, we will design a host name recognition method based on the specific business ..

One day, the installation of a test machine is complete, but when the saltstack authenticates the key, it will find that when the master and minions are connected, it is found that the ID passed by Minion is localhost. localdomain. That's strange. Why .?

By default, the host operating system is installed. The hostname in the/etc/sysconfig/network configuration file is localhost. localdomain: When you authenticate the salt master and Minion (the specified minion ID is not displayed), after the peer accepts the minion ID, it must be localhost. localdomain .. Please refer to the following authentication process

Minion and master authentication process

1. minion will automatically generate Minion. PEM and Minion. Pub under/etc/salt/pki/minion at startup, and then send Minion. Pub to the master.

2. the master receives the minion public key, and we allow the minion key through Salt-key-, in this way, the Public Key named by minion ID will be stored under/etc/salt/pki/master/minions of the master, and the authentication communication is completed.

In the above authentication process, it is not difficult to find that the master receives the Public Key passed by minion and names it with minion ID. Some of them are localhost. localdomain. Why .?

If the specified minion ID is not displayed in the configuration file of salt minion in the early stage, it will be passed by default. What is the default value .?

In the configuration file, if left commented the ID will be the hostname as returned by the python call: Socket. getfqdn () is obtained through the socket. getfqdn () function.

Then we can write a small script to verify the FQDN.

cat a.py#!/usr/bin/python envimport socketprint socket.getfqdn(socket.gethostname())

Verify

[[Email protected] ~] # Python A. py
Localhost. localdomain

During script verification, the FQDN is found to be incorrect, and you need to reconfigure hostname # to reproduce the scenario.

Hostname configuration method

1./etc/sysconfig/Network

Network = xxxx

After the configuration is complete, re-run the network service.

2./etc/hosts for ing

Intranet IP host

Hostname-F verifies the FQDN. Execute the. py script for verification, and delete the cache minion_id (For details, refer to the following)

Here, we encountered a small problem. We directly connected to the salt master without re-configuring the hostname. The key passed in would be localhost. localdomain. At this time, you reset the hostname and delete localhost from the master. the ID of localdomain, which is always used for re-authentication, unless you force the ID (ID of the minion configuration file ). Why .? Let's take a look at the minion startup process.

650) This. width = 650; "src =" http://s3.51cto.com/wyfs02/M02/4D/63/wKioL1RQjXSAR9OdAAHVjf8O7CU808.jpg "Title =" clipboard.png "alt =" wkiol1rqjxsar9odaahvjf8o7cu808.jpg "/>

The second line uses the cache's minion ID. minion will generate an ID file at startup, which will be loaded into the cache at/etc/salt/minion_id, this will be read every restart, which is why it is always localhost. localdomian ID

The file content is

CAT/etc/salt/minion_id

Localhost. localdomain

The preceding solution deletes the minion ID file.

Minion # rm-F/etc/salt/minion_id

Minion #/etc/salt/minion restart

Re-authenticate to solve the problem ~~

Okay. This is all about ID ..

Recommended: configure the hostname when connecting to the master node, resolve the FQDN, and then perform the salt master authentication. I hope it will help you.

This article from the "bin" blog, please be sure to keep this source http://binbin158.blog.51cto.com/2659767/1569212

Stories about IDs in saltstack