Re: samba-libs package in bookworm-backports has version dependency errors

Hello.

Thank you for the clarification. This makes perfect sense given the 
context. It is a shame its such a shitshow tbh given that samba/winbind 
even supports the sss backend for enumerating the uid/gid for users and 
groups to support consistent mapping even without kerberos for nfs and 
smb shares which is otherwise practically impossible otherwise with nfs 
sys auth schema as well.

The fileserver employs the following config with smb.conf

idmap config * : backend = tdb
idmap config * : range = 10000-19999

idmap config FOO : backend = sss
idmap config FOO : range = 20000-4294967295

machine password timeout = 0

This allows the AD sid translation for uid and gid to be consistent in a 
way that idmap_rid does not provide a consistent way to do for a mixed 
nfs and smb environment which requires a unififed access policy.

FOO here is the internal domain workgroup which is mapped via the rest 
of the config.

I have a setup where we do an active directory setup purely based on 
samba where my test setup also relies heavily on kerberos for nfs (to 
catch these kinds of issues).

sssd and samba can perfectly coexist and do a wonderful setup where sss 
handles the uid and gid enumeration and kerberos handles access control 
along with samba handling any smb access with consistent uid/gid mapping 
even with smb authenticated users. :)

-Jupiter Vuorikoski

On 07/09/2024 7.56, Michael Tokarev wrote:
> 30.08.2024 11:55, Micha Lenk wrote:
>> Hi Jupiter,
>>
>> Am 29. August 2024 23:05:36 MESZ schrieb Jupiter Vuorikoski 
>> <[email protected]>:
>>> Hi.
>>>
>>> Ran across this by accident with bookworm-backports:
>>>
>>> The following packages have unmet dependencies:
>>>   samba-libs : Breaks: sssd-ad (< 2.9.4-1+b1) but 2.8.2-4 is to be 
>>> installed
>>>                Breaks: sssd-ad-common (< 2.9.4-1+b1) but 2.8.2-4 is 
>>> to be installed
>>>                Breaks: sssd-ipa (< 2.9.4-1+b1) but 2.8.2-4 is to be 
>>> installed
>>> E: Error, pkgProblemResolver::Resolve generated breaks, this may be 
>>> caused by held packages.
>>>
>>> So if someone is running sssd with samba and tries to upgrade to 
>>> bookworm-backports samba it will break the setup.
>
> No, it will not break the setup, - apt wont allow to install both
> at the same time.
>
>> Thanks for letting us know. Dear Samba maintainers, can you please 
>> look into how this could be resolved?
>
> This is a well-known issue, and I placed these Breaks on purpose, - or 
> else
> it really would break existing setups by allowing to install two 
> pieces of
> software which aren't compatible with each other.
>
> The root cause is that sssd uses internal-to-samba library (libndr) which
> samba people does not want to be used in external projects.  This library
> does not have a well-defined external interface and is not maintained by
> upstream in a way to stay backwards-compatible (at least not with as much
> efforts as other, actually public, libraries).  So it breaks from time to
> time (from libndr3 in bookworm to libndr5 now with samba 4.21).
>
> The only way to go forward from here is to update backport of sssd at the
> same time when updating backport of samba.  But this isn't going to work
> in all combinations, and especially there's no mechanism like library
> soname transition in backports (when switching from libndr4 to libndr5
> in this case, all users of libndr4 have to be rebuilt to use libndr5
> instead).  So even backport of sssd will break in a similar way when
> I'll upload samba 4.21 to bookworm-backports.
>
> The only sane solution I can offer for now is to ensure a user can not
> easily break sssd by installing a more recent samba, which is exactly
> what I did by adding the above Breaks: lines.
>
> Maybe someone is willing to keep sssd backport current (and maybe find
> a way to perform soname transition when this is needed).  It would
> definitely be someone else, not me, - I know nothing about sssd and
> don't use it in any way, so have no idea even how to verify if it
> works or not.
>
>> Thanks,
>> Micha
>
> /mjt
>