Operations grimoire/Salt: Difference between revisions
No edit summary |
(For a FreeBSD service, Salt is able to create /etc/rc.conf.d/<service name> itself) |
||
| Line 20: | Line 20: | ||
:The master key has expired on the minion: remove it on the minion with <code>rm /etc/salt/pki/minion/minion_master.pub</code>. If you can repro faithfully a scenario with this issue, add more details at https://github.com/saltstack/salt/issues/46923 | :The master key has expired on the minion: remove it on the minion with <code>rm /etc/salt/pki/minion/minion_master.pub</code>. If you can repro faithfully a scenario with this issue, add more details at https://github.com/saltstack/salt/issues/46923 | ||
== | == Best practices for configuration == | ||
=== UIDs and GIDs should be unique === | === UIDs and GIDs should be unique === | ||
UIDs and GIDs are created autoincrementally by the OSes, so it's very easy to have two different usernames using the same uid on two machines. To avoid that, every user.present and group.present Salt state should specify the uid explictly. To avoid to reuse one, document it in {{Ops file|UIDs}} and {{Ops file|GIDs}}. | UIDs and GIDs are created autoincrementally by the OSes, so it's very easy to have two different usernames using the same uid on two machines. To avoid that, every user.present and group.present Salt state should specify the uid explictly. To avoid to reuse one, document it in {{Ops file|UIDs}} and {{Ops file|GIDs}}. | ||
=== Enable a service On FreeBSD === | |||
A lot of code manually create /etc/rc.conf.d/<service name> and provision it with file.managed. | |||
In [https://devcentral.nasqueron.org/D3413#52413 D3413], a simpler approach is to let Salt create that file automatically and put <service>_enable="YES" on it. That solution should be used when no other service option than _enable has to be set. | |||
Revision as of 10:45, 10 August 2024
Salt is used for deployment. Configuration can be found in the rOPS repository.
Keys
Master
master.pub: 67:8b:e6:b2:7b:73:5b:f1:50:f4:48:38:9a:4c:1c:31:e1:b7:6e:eb:9f:47:98:40:1f:53:29:9e:86:bb:83:38
This fingerprint should be used by minions in the `master_finger` value in configuration file.
It can be updated running salt-call --local key.finger from Complector.
Troubleshoot
Request timeout
- Symptoms on master
- The minion doesn't reply with job result
- Symptoms on minion
- When running through
salt-call, output showsSaltReqTimeoutError, retrying. (1/7). - Possible cause and solutions
- The master key has expired on the minion: remove it on the minion with
rm /etc/salt/pki/minion/minion_master.pub. If you can repro faithfully a scenario with this issue, add more details at https://github.com/saltstack/salt/issues/46923
Best practices for configuration
UIDs and GIDs should be unique
UIDs and GIDs are created autoincrementally by the OSes, so it's very easy to have two different usernames using the same uid on two machines. To avoid that, every user.present and group.present Salt state should specify the uid explictly. To avoid to reuse one, document it in rOPS: UIDs and rOPS: GIDs.
Enable a service On FreeBSD
A lot of code manually create /etc/rc.conf.d/<service name> and provision it with file.managed.
In D3413, a simpler approach is to let Salt create that file automatically and put <service>_enable="YES" on it. That solution should be used when no other service option than _enable has to be set.
