Bug#859451: [Pkg-utopia-maintainers] Bug#859451: dbus: error messages on boot for systems with NSS LDAP
On 04/04/2017 15:58, Michael Biebl wrote: > Can you double check that all users from > > grep -s -R -E "(user|group)=" /etc/dbus-1/system.d/ > /usr/share/dbus-1/system.d/ | sed 's/.*/\1/' | sort -u > > are available in /etc/passwd and /etc/group Here it is: # grep -s -R -E "(user|group)=" /etc/dbus-1/system.d/ /usr/share/dbus-1/system.d/ | sed 's/.* /\1/' | sort -u user="root" user="systemd-network" user="systemd-resolve" # grep systemd /etc/passwd systemd-timesync:x:100:103:systemd Time Synchronization,,,:/run/systemd:/bin/false systemd-network:x:101:104:systemd Network Management,,,:/run/systemd/netif:/bin/false systemd-resolve:x:102:105:systemd Resolver,,,:/run/systemd/resolve:/bin/false systemd-bus-proxy:x:103:106:systemd Bus Proxy,,,:/run/systemd:/bin/false -- Laurent.
Bug#859451: [Pkg-utopia-maintainers] Bug#859451: dbus: error messages on boot for systems with NSS LDAP
Am 04.04.2017 um 13:53 schrieb Laurent Bonnaud: > On 04/04/2017 13:29, Simon McVittie wrote: >> Alternatively, your NSS configuration might be such that the NSS-backed >> library calls that dbus-daemon uses during configuration loading (mainly >> getpwuid_r() and getgrnam_r() I think) hit the network even if the >> group is configured locally. > > In /etc/nsswitch.conf LDAP is configured as follows: > > passwd: files ldap > group: files ldap Any idea why NSS tries to use ldap although, as you said, all system users are local? Can you double check that all users from grep -s -R -E "(user|group)=" /etc/dbus-1/system.d/ /usr/share/dbus-1/system.d/ | sed 's/.*/\1/' | sort -u are available in /etc/passwd and /etc/group -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#859451: dbus: error messages on boot for systems with NSS LDAP
On 04/04/2017 13:29, Simon McVittie wrote: > Sorry, I meant /etc/dbus-1/system.d/*.conf No problem! This system has only standard unmodified stuff: # ls -l /etc/dbus-1/system.d/ total 48 -rw-r--r-- 1 root root 947 May 26 2015 org.freedesktop.hostname1.conf -rw-r--r-- 1 root root 937 May 26 2015 org.freedesktop.locale1.conf -rw-r--r-- 1 root root 12499 Jul 28 2016 org.freedesktop.login1.conf -rw-r--r-- 1 root root 1604 Jul 28 2016 org.freedesktop.network1.conf -rw-r--r-- 1 root root 953 Jul 28 2016 org.freedesktop.resolve1.conf -rw-r--r-- 1 root root 11898 Mar 2 09:21 org.freedesktop.systemd1.conf -rw-r--r-- 1 root root 947 May 26 2015 org.freedesktop.timedate1.conf > For completeness, several other paths could potentially > mention users and groups, including /etc/dbus-1/system-local.conf > and /usr/share/dbus-1/system.d/*.conf. Those do not exist on this system. > The bus configuration often also references group names and identities - > are those all local? (I suspect not.) In fact dbus is only installed as a dependency for libpam-systemd and I did not touch anything. > Alternatively, your NSS configuration might be such that the NSS-backed > library calls that dbus-daemon uses during configuration loading (mainly > getpwuid_r() and getgrnam_r() I think) hit the network even if the > group is configured locally. In /etc/nsswitch.conf LDAP is configured as follows: passwd: files ldap group: files ldap and I use the following packages: ii libnss-ldapd:amd64 0.9.7-2amd64 NSS module for using LDAP as a naming service ii libpam-ldapd:amd64 0.9.7-2amd64 PAM module for using LDAP as an authentication service > I'd rather not: this is very much an "at own risk, if you are absolutely > sure you know what you are doing" option that can easily cause circular > dependencies. (Much like getting your user and group information from > the network, in fact...) The suggestion in README.Debian could be preceded with a big warning such as: "Warning, the following only applies to systems that use /etc/network/interfaces for network configuration and not daemons that use dbus such as NetworkManager, ConnMan, wicd, ..." -- Laurent.
Bug#859451: dbus: error messages on boot for systems with NSS LDAP
On Tue, 04 Apr 2017 at 12:36:35 +0200, Laurent Bonnaud wrote: > On 03/04/2017 20:21, Simon McVittie wrote: > > > Yes: if any user or group mentioned in /etc/dbus/system.d/ > > comes from LDAP, then it needs to know who they are. > > This directory does not exist on this system. Sorry, I meant /etc/dbus-1/system.d/*.conf (my earlier mail was missing the -1). For completeness, several other paths could potentially mention users and groups, including /etc/dbus-1/system-local.conf and /usr/share/dbus-1/system.d/*.conf. > > and doubly so if system users are in LDAP. > > System users are all local in /etc/passwd. That's good - it's very easy to get circular dependencies otherwise. The bus configuration often also references group names and identities - are those all local? (I suspect not.) Alternatively, your NSS configuration might be such that the NSS-backed library calls that dbus-daemon uses during configuration loading (mainly getpwuid_r() and getgrnam_r() I think) hit the network even if the group is configured locally. > >> - would it be possible to order the dbus start after network is available? > > In general no, because some ways to get on the network require D-Bus > > (NetworkManager, ConnMan, wicd), so you would have a circular > > dependency. > > This system is minimal and uses plain old /etc/network/interfaces Right, so this works *for you*, but it cannot be applied in general. > > # /etc/systemd/system/dbus.service.d/local.conf > > [Unit] > > Wants=network-online.target > > After=network-online.target > > How about suggesting this solution in /usr/share/doc/dbus/README.Debian? I'd rather not: this is very much an "at own risk, if you are absolutely sure you know what you are doing" option that can easily cause circular dependencies. (Much like getting your user and group information from the network, in fact...) S
Bug#859451: dbus: error messages on boot for systems with NSS LDAP
On 03/04/2017 20:21, Simon McVittie wrote: > Yes: if any user or group mentioned in /etc/dbus/system.d/ > comes from LDAP, then it needs to know who they are. This directory does not exist on this system. > I would not recommend using non-local NSS without some sort of cache > (unscd, nss-updatedb or sssd), This system has nslcd but I think it only has RAM cache and I guess that a cache on persistent storage would be needed. > and doubly so if system users are in LDAP. System users are all local in /etc/passwd. >> - would it be possible to order the dbus start after network is available? > In general no, because some ways to get on the network require D-Bus > (NetworkManager, ConnMan, wicd), so you would have a circular > dependency. This system is minimal and uses plain old /etc/network/interfaces > If you don't use any of those, then you can configure this locally > by creating /etc/systemd/system/dbus.service.d/local.conf containing > something like this (untested and quite possibly wrong, see systemd > documentation): > > [Unit] > Wants=network-online.target > After=network-online.target Thanks for this solution! I tried it and after a limited number of boots I have not seen the problem again. Since boots are non deterministic it is not a perfect test, and I'll let you know if I see the error messages again. How about suggesting this solution in /usr/share/doc/dbus/README.Debian? -- Laurent.
Bug#859451: dbus: error messages on boot for systems with NSS LDAP
Control: tags -1 + wontfix On Mon, 03 Apr 2017 at 19:35:36 +0200, Laurent Bonnaud wrote: > - does dbus really need to query the NSS databases on boot? Yes: if any user or group mentioned in /etc/dbus/system.d/ comes from LDAP, then it needs to know who they are. I would not recommend using non-local NSS without some sort of cache (unscd, nss-updatedb or sssd), and doubly so if system users are in LDAP. Unfortunately, many commonly-used packages (e.g. BlueZ) still use the firewall-style policies found in /etc/dbus/system.d/ for group-based access control, instead of letting all users communicate with the service and then doing their own authorization via polkit (like NetworkManager does). > - would it be possible to order the dbus start after network is available? In general no, because some ways to get on the network require D-Bus (NetworkManager, ConnMan, wicd), so you would have a circular dependency. If you don't use any of those, then you can configure this locally by creating /etc/systemd/system/dbus.service.d/local.conf containing something like this (untested and quite possibly wrong, see systemd documentation): [Unit] Wants=network-online.target After=network-online.target Regards, S