Another way could be to check in the postinst files if there is already an existing sssd.conf file and, if yes, do not enable the systemd units.
This should prevent breaking existing installations but would allow to use the services after adjusting sssd.conf and new users would use the sockets directly. Admins of existing installations could be informed about this change via the NEWS file. Would that be a useful solution? Jan Am 21.03.19 um 14:56 schrieb Timo Aaltonen: > On 6.3.2019 19.22, Jan Luca Naumann wrote: >> Package: sssd-tools >> Version: 1.16.3-3 >> Severity: normal >> >> Since Debian deactivates the installation of the sssd-ifp.service (c.f. >> changelog for >> Debian release 1.16.0-4) the subcommands using infopipe (e.g. list-domain >> and domain-status) >> of the tool sssctl are broken: >> >> $ sssctl domain-list >> Unable to get domains list [3]: Communication error >> org.freedesktop.systemd1.NoSuchUnit: Unit sssd-ifp.service not found. >> >> Anyway, it would be nice if the responder service/socket can be installed >> and a different solution is applied to avoid the problem of old configs, >> e.g. do not enable the sockets at installation time. > > I can push a package to experimental which re-enables socket activation, > but I don't have a way to test if pam auth is still broken if the config > has duplicate entries on the 'services=' line.. > > One option would be to enable just some of them, like ifp. >