You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Feature: The role can manage user units in addition to system units. Each item
in each input list can be a string or a `dict` consisting of the item
(file, template, or unit), a user name, and a state (for files and templates).
The role will not create users and will give an error if a non-existent user
is specified.
Reason: The role should allow management of user units.
Result: The role can manage user units.
NOTE: User units only supported on EL8 and later.
Signed-off-by: Rich Megginson <[email protected]>
List of variables consumed by the role follows, note that none of them is mandatory.
26
27
28
+
Each of the variables can either be a list of strings, or a list of `dicts`.
29
+
30
+
The list of strings form assumes that the items to be managed are system units
31
+
owned by `root`, and for files, assumes that the files should be `present`.
32
+
33
+
The list of `dict` form looks like this:
34
+
35
+
```yaml
36
+
systemd_unit_files:
37
+
- item: some.service
38
+
user: my_user
39
+
state: [present|absent]
40
+
```
41
+
42
+
Use the `dict` form to manage user units, and to remove unit files. If using
43
+
user units, the role will manage lingering for those users.
44
+
45
+
*NOTE:* Support for user units is not available in EL7 or earlier. This feature
46
+
is only available in EL8 and later.
47
+
27
48
### systemd_unit_files
28
49
29
50
List of systemd unit file names that should be deployed to managed nodes.
@@ -79,7 +100,7 @@ List of unit files that shall be unmasked via systemd.
79
100
80
101
This variable is used to handle reboots required by transactional updates. If a transactional update requires a reboot, the role will proceed with the reboot if systemd_transactional_update_reboot_ok is set to true. If set to false, the role will notify the user that a reboot is required, allowing for custom handling of the reboot requirement. If this variable is not set, the role will fail to ensure the reboot requirement is not overlooked.
81
102
82
-
Example of setting the variables:
103
+
Example of setting the variables for the simple list of strings format:
83
104
84
105
```yaml
85
106
systemd_unit_files:
@@ -96,12 +117,49 @@ systemd_enabled_units:
96
117
- bar.service
97
118
```
98
119
120
+
Example of setting the variables for the list of `dict` format:
121
+
122
+
```yaml
123
+
systemd_unit_files:
124
+
- item: foo.service
125
+
user: root
126
+
state: present
127
+
- item: bar.service
128
+
user: my_user
129
+
state: absent
130
+
systemd_dropins:
131
+
- item: cups.service.conf.j2
132
+
user: root
133
+
state: present
134
+
- item: avahi-daemon.service.conf.j2
135
+
user: my_user
136
+
state: absent
137
+
systemd_started_units:
138
+
- item: foo.service
139
+
user: root
140
+
- item: bar.service
141
+
user: my_user
142
+
systemd_enabled_units:
143
+
- item: foo.service
144
+
user: root
145
+
- item: bar.service
146
+
user: my_user
147
+
```
148
+
99
149
## Variables Exported by the Role
100
150
101
151
### `systemd_units`
102
152
103
-
Variable shall contain a list of dictionaries where each entry describes state of one systemd unit
104
-
present on the managed host.
153
+
The variable is a `dict`. Each key is the name of a systemd unit. Each value
154
+
is a dict with fields that describe the state of that systemd unit present on
155
+
the managed host for the system scope.
156
+
157
+
### `systemd_units_user`
158
+
159
+
Variable shall contain a dict. Each key is the name of a user given in one of
160
+
the lists passed to the role, and `root` (even if `root` is not given). Each
161
+
value is a dict of systemd units for that user, or system units for `root`, in
0 commit comments