Bug#1069706: systemd unit files lack ordering wrt nss-user-lookup.target

[Colin Watson]

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.

-- 
Colin Watson (he/him)                              [cjwatson at debian.org]