Operations grimoire/Salt: Difference between revisions
From Nasqueron Agora
(→Master) |
|||
| (5 intermediate revisions by the same user not shown) | |||
| Line 4: | Line 4: | ||
=== Master === | === Master === | ||
<pre> | <pre> | ||
master.pub: | 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 | ||
</pre> | </pre> | ||
This fingerprint should be used by | This fingerprint should be used by minions in the `master_finger` value in configuration file. | ||
It can be updated running <code>salt-call --local key.finger</code> from Complector. | |||
== Troubleshoot == | |||
=== Request timeout === | |||
;Symptoms on master | |||
:The minion doesn't reply with job result | |||
;Symptoms on minion | |||
:When running through <code>salt-call</code>, output shows <code>SaltReqTimeoutError, retrying. (1/7)</code>. | |||
;Possible cause and solutions | |||
: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 | |||
=== Upgrade considerations === | |||
Do hotfixes apply correctly, like in {{D|3392}}? | |||
== 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 {{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. | |||
Decision tree: | |||
* Do we only have one configuration file for that service? | |||
** Yes -> provision a unique file /etc/rc.conf.d/<service name> | |||
** No -> provision a first file in the service directory: /etc/rc.conf.d/<service name>/<configuration file> | |||
* Do we have any service configuration in addition to <service>_enable to set in that file? | |||
** Yes -> provision /etc/rc.conf.d/<service name> through file.managed and a template, e.g. {{Ops file|roles/prometheus/prometheus/service.sls}} | |||
** No -> use <code>service.running</code> with <code>enabled: True</code>, e.g. [https://devcentral.nasqueron.org/D3413#52413 D3413] | |||
Latest revision as of 20:57, 20 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
Upgrade considerations
Do hotfixes apply correctly, like in D3392?
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.
Decision tree:
- Do we only have one configuration file for that service?
- Yes -> provision a unique file /etc/rc.conf.d/<service name>
- No -> provision a first file in the service directory: /etc/rc.conf.d/<service name>/<configuration file>
- Do we have any service configuration in addition to <service>_enable to set in that file?
- Yes -> provision /etc/rc.conf.d/<service name> through file.managed and a template, e.g. rOPS: roles/prometheus/prometheus/service.sls
- No -> use
service.runningwithenabled: True, e.g. D3413
