Please let me know if there’s a better place to post this.
I’ve been facing this issue for some time. I have all the users on my network defined in LDAP, including users for system services, for example postgres, jellyfin.
I’m using a hand rolled OpenLDAP setup (as opposed to e.g. FreeIPA, mainly for the learning experience). My postgres user looks like:
dn: uid=postgres,ou=system,ou=users,dc=mydomain,dc=com
objectClass: account
objectClass: posixAccount
objectClass: shadowAccount
objectClass: top
cn: postgres
gidNumber: 11004
homeDirectory: /var/lib/pgsql
uid: postgres
uidNumber: 11004
loginShell: /sbin/nologin
Users and groups are looked up via sssd
$ grep -E '(passwd|group)' /etc/nsswitch.conf
passwd: files sss systemd
group: files [SUCCESS=merge] sss [SUCCESS=merge] systemd
When it comes to installing a package that uses a given user with that user definition existing in LDAP trouble begins. The symptoms vary a bit by package, but usually the following is emitted when installing a package:
>>> [RPM] user postgres does not exist - using root
>>> [RPM] group postgres does not exist - using root
>>> [RPM] user postgres does not exist - using root
>>> [RPM] group postgres does not exist - using root
>>> [RPM] user postgres does not exist - using root
>>> [RPM] group postgres does not exist - using root
>>> [RPM] user postgres does not exist - using root
>>> [RPM] group postgres does not exist - using root
Depending on the package, this can mean various files get chowned to root instead of the correct user, or in some cases a new entry is added to passwd/group and files are chowned to that user. I generally have to clean up after upgrades for packages that have their users in LDAP.
In the case of postgres my /var/lib/pgsql is on a Kerberised NFSv4 server. So running the package extraction as root fails because root doesn’t have a ticket.
My expected/desired behaviour is the package can see the LDAP defined user/group during installation and use them. 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 - so I don’t think this is an issue with either of these packages specifically.
System is Fedora 43, this has been an issue for me through many versions though, as long as I’ve been running Fedora + LDAP.
I vaguely suspect that my users/groups are not defined correctly in LDAP somehow, except they work perfectly in every other respect, so I’m uncertain.
Has anyone seen these symptoms before?
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 = memberUidall lookups with
getentperform 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
[SUCCESS=merge]is a group specific thing which merges membership of groups from each of the sources. From the nsswitch.conf man:I think one statement that I made in the OP is incorrect. I said:
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
%attrmacro that the lines in the OP are emitted.So I went digging through the
rpmsource 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.
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!