Bug#1068649: winbind: Should be wanted by and ordered before nss-user-lookup.target
onsdag 24 april 2024 11:55:55 CEST skrev du: > 08.04.2024 17:27, Magnus Holmgren wrote: > > Package: winbind > > Version: 2:4.17.12+dfsg-0+deb12u1 > > > > I'm not entirely sure, but I think winbind.service should include > > > > [Unit] > > Wants=nss-user-lookup.target > > Before=nss-user-lookup.target > > > > systemd.special(7) says: > > > > "All services which provide parts of the user/group database should be > > ordered before this target, and pull it in." > > > > and winbind does provide parts of the user/group database (as long as it's > > mentioned in nsswitch.conf, but typically that's the point, isn't it?). > > This is a grey area (to me anyway). Myself, I tend to avoid this sort of > dependencies as much as possible. Since winbind itself is ordered after > network.target, we're at risk to make login impossible until network is up, > and network might not be up until, say, wifi is running, etc. If this is an issue, I believe it's on a different level. But I don't think you need to worry about it. systemd.special(7) also says: "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." So getty, display managers, etc. shouldn't wait for nss-user-lookup, and they don't, precisely because (I presume) you should be able login as any known user; all users don't have to be known before you're allowed to login. > > We've had trouble with cron not running some jobs for a good while, and I > > just now figured out that it's because we have some jobs configured to run > > as Samba users, and cron started before winbind on boot and complained > > about invalid users. > > Please note how /etc/init.d/cron is set up: cron itself is ordered after > winbindd. Maybe this is not a nice as systemd variant which you outlined > above, but in my view it is more reliable. Looks like basically the same to me, except that systemd has a group alias for those services so /etc/init.d/cron doesn't have to be updated whenever a new NSS backend is added. -- Magnus Holmgren
Bug#1068649: winbind: Should be wanted by and ordered before nss-user-lookup.target
08.04.2024 17:27, Magnus Holmgren wrote: Package: winbind Version: 2:4.17.12+dfsg-0+deb12u1 I'm not entirely sure, but I think winbind.service should include [Unit] Wants=nss-user-lookup.target Before=nss-user-lookup.target systemd.special(7) says: "All services which provide parts of the user/group database should be ordered before this target, and pull it in." and winbind does provide parts of the user/group database (as long as it's mentioned in nsswitch.conf, but typically that's the point, isn't it?). This is a grey area (to me anyway). Myself, I tend to avoid this sort of dependencies as much as possible. Since winbind itself is ordered after network.target, we're at risk to make login impossible until network is up, and network might not be up until, say, wifi is running, etc. We've had trouble with cron not running some jobs for a good while, and I just now figured out that it's because we have some jobs configured to run as Samba users, and cron started before winbind on boot and complained about invalid users. Please note how /etc/init.d/cron is set up: cron itself is ordered after winbindd. Maybe this is not a nice as systemd variant which you outlined above, but in my view it is more reliable. Or maybe not, - cron often used to run @reboot jobs to start services... which is a bad idea anyway :) But I dunno what to do here. Thanks, /mjt
Bug#1068649: winbind: Should be wanted by and ordered before nss-user-lookup.target
Package: winbind Version: 2:4.17.12+dfsg-0+deb12u1 I'm not entirely sure, but I think winbind.service should include [Unit] Wants=nss-user-lookup.target Before=nss-user-lookup.target systemd.special(7) says: "All services which provide parts of the user/group database should be ordered before this target, and pull it in." and winbind does provide parts of the user/group database (as long as it's mentioned in nsswitch.conf, but typically that's the point, isn't it?). We've had trouble with cron not running some jobs for a good while, and I just now figured out that it's because we have some jobs configured to run as Samba users, and cron started before winbind on boot and complained about invalid users. -- Magnus Holmgren ./¯\_/¯\. Milient Software (also holmg...@debian.org)
