On Tue, 23 Apr 2024 12:23:21 +0100 Colin Watson <cjwatson@debian.org> wrote: > On Tue, Apr 23, 2024 at 09:32:00AM +0200, Rasmus Villemoes wrote: > > According to systemd.special(7) > > > > nss-user-lookup.target > > > > A target that should be used as synchronization point for all > > regular UNIX user/group name service lookups. [...] All > > services for which the availability of the full user/group > > database is essential should be ordered after this target, but > > not pull it in. All services which provide parts of the > > user/group database should be ordered before this target, and > > pull it in. > > > > I have a custom .service that does exactly as described in the second > > part, i.e. provides part of the user/group database and says > > Before=nss-user-lookup.target, Wants=nss-user-lookup.target > > (concretely, it modifies /etc/shadow to update a default password, but > > that's not really important). I believe sshd definitely belongs in the > > former category, i.e. sshd should not be started until any such > > service that updates the user/group database, such as updating > > /etc/shadow, have run. > > > > Hence the ssh.service and ssh.socket files should add > > > > After=nss-user-lookup.target > > > > in their [Unit] sections. This is a no-op on systems that do not have > > any service pulling in that target, but required for correctness on > > systems that do. > > > > Of course, I could, and currently do, handle this via a drop-in config > > fragment in some ssh.service.d/ directory. But this, and other similar > > synchronization targets, exist so that one does not necessarily need > > to know about every other service running on the system. > > This sounds like a reasonable proposal to me. I'm just CCing Debian's > systemd maintainers for a quick review to make sure I'm not missing > anything subtle. That sounds fine - maybe the service, but not the socket, so that connections can start to come in early. I also note there's accountsservice pulling that target in but it shouldn't, but that's a separate matter and can be handled upstream. -- Kind regards, Luca Boccassi
Attachment:
signature.asc
Description: This is a digitally signed message part