[Pkg-sssd-devel] Bug#923882: Bug#923882: sssd-tools: sssctl list-domains is broken

[Jan Luca Naumann]

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.
>