Well I’ll be dammed. There is an open issue to support NSS for user/group info again, apparently it was removed about three years ago.
I would have started running postgres in my homelab less than three years ago, and was not using the rpm distribution of jellyfin at that time either.
So there is hope!
Thanks for the reply. Yes to all of the LDAP assumptions. LDAP is configured inside sssd only with:
[domain/mydomain.com]
cache_credentials = true
enumerate = true
id_provider = ldap
ldap_uri = ldap://ldap.mydomain.com
ldap_search_base = dc=mydomain,dc=com
ldap_schema = rfc2307
ldap_group_member = memberUid
all lookups with getent perform as expected.
I don’t think the postgres assumptions matter here because I’m not using LDAP for anything inside postgres - the issue is entirely during rpm operations.
The [] is a group specific thing which merges membership of groups from each of the sources. From the nsswitch.conf man:
When a group is located in the first of the two group entries, processing will continue on to the next one. If the group is also found in the next entry (and the group name and GID are an exact match), the member list of the second entry will be added to the group object to be returned.
I think one statement that I made in the OP is incorrect. I said:
Having examined the specs for postgresql-server and jellyfin, there are checks for existing users in there which don’t seem to be picking up my LDAP users
Having thought about it a bit more today I realised that clearly the part of the package which tries to create the user locally is correctly seeing the ldap user (and hence not creating a new one) - it’s later when it tries to set ownership of files with the %attr macro that the lines in the OP are emitted.
So I went digging through the rpm source code this evening. I traced the source of those log messages. The lookups for uid and gid read directly from the passwd and group files.
So it appears that rpms simply cannot consume users and groups from LDAP when setting attributes of files. This seems like a good opportunity to replace those file lookups with NSS lookups instead. Unfortunately I am time poor, otherwise I’d have a try, but maybe one day.
At least now the mystery is solved. Thanks again for your response - if I didn’t have someone to whom I felt I should reply, I probably wouldn’t have dug this deep.
I was also confused for a moment due to the way my Lemmy client shows it, but op has actually linked two articles, one from 2022 and one more recent.