Lines Matching refs:it

14 aren't IRL. With that in mind, when we discuss UIDs below it should be assumed
30    `systemd`. If you do change it you void your warranty.) Because Fedora is a
69 available regular user range only, usually 1000..60000. And it's also usually
81 above). However, it does define some special group/GID assignments, which are
91 group must have the GID 5. That's because it must be encoded in the `devpts`
104    might get different UIDs assigned in case of conflict, though it is
111    range has been chosen so that it is below the 16bit boundary (i.e. below
125    `-U`) then it will automatically find a so far unused 16bit subrange of this
126    range and assign it to the container. The range is picked so that the upper
133    range is above the 16bit boundary. Moreover it's below the 31bit boundary,
144 subsystems allocating from the same ranges it is hence essential that they
148 do an NSS check for the first UID of the range it allocates, not all 65536 of
188 given that it's assigned the UID 65534, you should really cover the full 16bit
195 2. While it's fine to assign more than 65536 UIDs/GIDs to a container, there's
199 care for nested containers, it's hence probably a good idea to allocate exactly
209 `systemd-nspawn` and all other container managers following the scheme, as it
211 as that's what they do, too. Moreover, it makes `chown()`ing container file
213 internal UID in a fixed way, it's very easy to adjust the container's base UID
227 you want to pick, then it's already in use: pick a different one. Wrap that
236 5. `systemd-homed` by default mounts the home directories it manages with UID
250 or not), given this typically breaks quota assumptions, makes it impossible for
253 restricts compatibility with networked home directories. Typically, it's a much
308 Regular users do not need to be resolvable during early boot, it is sufficient
312 providers of the user database and consumers of it. Services that require that
314 `systemd-logind.service`) are ordered *after* it, while services that provide
316 ordered *before* it. Note that `nss-user-lookup.target` is a *passive* unit: in
317 order to minimize synchronization points on systems that don't need it the unit
319 that really needs it, and that means only if there's a service providing the
322 service `Before=nss-user-lookup.target` and that you pull it in with
325 `After=nss-user-lookup.target`, but do *not* pull it in via a `Wants=`