= phenomenon = The [https://fedoraproject.org/wiki/Starting_services_by_default service policy] prohibits packages from enabling services by default at install-time.
The nss-pam-ldapd package enables nslcd when it detects that it is being installed (not upgraded) onto a system on which the authconfig settings indicate that the nsswitch client stub which it includes would be called by applications.
= background analysis = The current logic in nss-pam-ldapd is there to ease updates in cases where the system is being upgraded and the package is being installed to obsolete nss_ldap. The older implementation of nss_ldap did not use a local daemon to do its heavy lifting, so if the system had been configured to use nss_ldap before the upgrade, without something enabling the service, it would find itself failing to look up information after the upgrade.
= implementation recommendation = I suggest adding an exception for nss-pam-ldapd, and adding similar logic to detect cases where nss-pam-ldapd is being installed to obsolete the older pam_ldap package, where upgrading to nss-pam-ldapd presents a similar concern.
nslcd and the nss clients seem to communicate using an AF_UNIX socket, so the only thing that prevents this package from using the blanket exception is that nss-pam-ldapd requires configuration to be useful, isn’t it?
If so, I’m +1.
Yes. We make some effort to pull in (the basics of, at least) the configuration of packages we're obsoleting at the same time when we do this, but in all other cases it has to be configured before it's used.
I think that the current script is okay, and if an exception is needed, I think it should be granted.
Alternatively, this could be more general if needed: this service seems to enable itself only if it's already configured, which might be a reasonable extension of the current policy.
AGREED: Exception for enabling nss-pam-ldapd's nslcd approved (+7).
Login to comment on this ticket.