Learn › Linux Automation with Salt › Meet and trust your fleet

Meet and trust your fleet

Verify two Salt agents through your private VLAN, compare keys, and repair a misconfigured second machine.

Meet and trust your fleet

Make two named machines answer a Salt request, after checking which machines you are trusting. By the end, you should be able to explain why a machine can answer an ordinary network ping but still fail a Salt request.

Salt helps you operate several machines from one place. It can run a request on selected machines and manage their configuration. For example, you can describe a desired condition: the web server package should be installed and its service running. Salt checks each selected machine and makes the changes needed to reach that condition.

Salt runs an agent on each managed machine. Salt calls that agent a minion. The master coordinates requests. A minion connects to the master; after they establish trust, the master can ask it to run work. Before changing packages or services, you need to know which machines will receive those requests. This lesson establishes that trust and uses a harmless request: test.ping asks whether the agent can answer through Salt.

There are three different checks:

Check	What it tells you	What it does not establish
Network path	Which interface and source address Linux selects; a successful network probe can add delivery evidence	The identity of the Salt process
Listening service	A process has opened the expected local TCP ports	A remote machine can reach it, or trust it
Verified identity and live response	The expected key was enrolled and the named agent answered a new request	Every service on that machine is healthy

Your three machines

Terminal label	Role	VLAN address in this example
salt-master	Coordinator	10.77.0.10
minion-a	First managed agent	10.77.0.21
minion-b	Second managed agent	10.77.0.22

The three machines share your session's private VLAN. Salt uses this path. Your authenticated lab terminal uses a separate management path. Keep that management connection and its interface settings intact.

The lab has installed Salt and prepared the network. The master is running; the two minion services are stopped and no minion keys are accepted. The second agent also has a deliberately incorrect Salt setting for your independent task. You will inspect, configure and enroll the agents. Check the terminal label before every command: commands marked master belong on salt-master.

You should already know how to use sudo, edit a short text file, and read an IP address. systemctl inspects a service; journalctl reads its log. Neither a running service nor a log line replaces an end-to-end check.

Worked example: check minion-a's path

On minion-a:

hostname
ip -br address
ip route get 10.77.0.10

Locate the VLAN interface and the address 10.77.0.21. In the route result, identify dev (outgoing interface) and src (selected source address). They should match your session inventory. This command asks Linux how it would send a packet; it does not send a Salt request.

On the master:

sudo systemctl is-active salt-master
sudo ss -lntp '( sport = :4505 or sport = :4506 )'

Check that both listeners bind to 10.77.0.10, not a public address or an all-address wildcard. Minions connect to TCP 4505 for published work and TCP 4506 for requests and returns. A local listener is only one part of the path. If these initial checks disagree with your inventory, use the lab's setup help before enrolling a key.

• [ ] The Salt master's public key is trusted.
• [x] Linux has selected an outgoing interface and source address.
• [ ] The Salt request has reached the master and succeeded.

>>> Route selection happens before delivery and authentication. A correct route is useful evidence, but it does not identify the service at the other end.

Establish which master you mean

A hostname is a label; it is not proof of identity. A public key identifies a Salt installation, and a fingerprint is a compact value calculated from that public key. Compare the entire fingerprint obtained through a trusted path.

In the authenticated master terminal:

sudo salt-key -F master

Record the fingerprint beside master.pub. Choose this public-key entry, not master.pem or a signing key. This value comes from the master terminal whose machine association the platform established. A fingerprint supplied only by an unknown machine asking to connect would not establish that association.

On minion-a, open its course configuration:

sudo nano /etc/salt/minion.d/lesson-01.conf

Enter these four settings. Replace the text between quotes with the complete master.pub fingerprint you just obtained; the explanatory text is not a fingerprint.

master: 10.77.0.10
id: minion-a
hash_type: sha256
master_finger: 'PASTE_THE_VERIFIED_MASTER_PUBLIC_KEY_FINGERPRINT'

These are YAML key/value pairs. Keep the colon and a space after each key, use spaces rather than tabs, and keep the fingerprint on one line. master chooses the network destination; master_finger supplies the identity you expect there. id is the name you will target.

The lab sets SHA-256 on the master too, so both sides compare the same kind of fingerprint. Save the file, then start the agent:

sudo systemctl start salt-minion
sudo systemctl is-active salt-minion
sudo salt-call --local key.finger hash_type=sha256

Record the minion's fingerprint from this minion-a terminal. --local asks this installed agent's local tools, without asking the master. If the key is not yet present, inspect sudo journalctl -u salt-minion -n 40 --no-pager; do not substitute a fingerprint copied from the pending-key list.

Check the agent before accepting it

On the master:

sudo salt-key --list all
sudo salt-key -f minion-a

Find minion-a in the unaccepted keys. Compare its entire fingerprint with the one obtained directly on minion-a. Matching values connect the pending identity to the machine you intended to enroll. If they differ, stop: accepting the name would trust a different key. Leave any other pending keys alone.

• [ ] A matching ID is enough for Salt requests to work.
• [ ] A network ping automatically accepts the key.
• [x] It must remain unable to run this master's Salt requests.

>>> A pending key means a request reached the enrollment process. The master has not yet authorized that identity, and pending status does not prove the complete trust exchange succeeded.

When the fingerprint matches, accept that one key:

sudo salt-key -a minion-a

Read the listed identity and confirm the prompt only if it is minion-a. Then send a new, narrowly targeted request:

sudo salt --timeout=10 'minion-a' test.ping

For a successful request, look for the minion-a result with a Boolean true value. This describes what to inspect, not output captured from your session. No response within the timeout is not a false result from the function; it means the master did not collect a response in that interval. Enrollment retries can take time. Read the minion's recent log if the first attempt does not answer, then make a fresh request.

On minion-a, check the stored master identity too:

sudo salt-call --local key.finger_master hash_type=sha256

Compare it to the original master fingerprint. The stored value alone is not proof of a current connection; combine it with the fresh response. Keep the verified master_finger configured. If you edit configuration later, restart the minion so the service reads it. A changed setting does not continuously recheck an already running connection.

Explain your evidence

State one thing each observation established: the selected route, the listener, the matched pending key, and the fresh Salt reply. test.ping runs inside Salt; the ordinary ping command uses ICMP. Either can fail while the other works because they test different mechanisms.

Your turn: diagnose and enroll minion-b

Bring minion-b into this fleet. Its required ID is minion-b; its intended master is 10.77.0.10. Its network is prepared, but its initial Salt configuration contains a wrong destination and its minion service is stopped. Inspect the existing configuration before replacing anything. Identify the actual wrong value and explain why it cannot reach the intended master through that setting.

Before making changes, gather the configured master address, the minion service state, the route to the intended master and a fresh response from the healthy minion-a. Write which observation suggests a configuration fault and which observation shows the agent process is not currently working. A Salt timeout alone cannot distinguish those causes.

Then repair the destination, configure verified trust, start the agent and enroll only its matching key. Use the trusted terminals to verify both identities and request a fresh response specifically from minion-b. Preserve minion-a and leave unrelated pending keys unaccepted. Choose your commands using the earlier tools; this section does not give a second completed configuration to copy.

The worked example remains available beside the real console. If you use it, treat the attempt as assisted practice. The pilot's current-state checks provide practice feedback and award no assessment points; they do not certify independent mastery or prove you performed the fingerprint comparison yourself.

• [x] ICMP reached the intended IP; Salt still needs its correct destination and running agent.
• [ ] Salt's key has been accepted, so no configuration change is needed.
• [ ] TCP ports 4505 and 4506 are open and the minion has authenticated.

>>> ICMP and Salt use different mechanisms. A network reply from 10.77.0.10 does not start the agent or correct its configured master address. Check your actual session rather than assuming the hypothetical ping result occurred.

Check both machines and explain the repair

Finish with fresh, separately targeted Salt requests to both minion-a and minion-b. Check that only the intended keys are accepted and that your management terminals still work. Run the lab check for current-state feedback.

Explain the original wrong value, why the stopped service was a separate obstacle, where each trusted fingerprint came from, and which new results show both agents working. Correct files alone would not show that a running process loaded them. Reading completion, prediction questions and machine-state feedback each show different kinds of progress.

Practice Meet and trust your fleet in a real Linux terminal at The Linux Camp. Progress is verified automatically as you type commands on the machine.