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?
My LDAP PTSD is coming back…
I’ll make the following LDAP assumptions:
- LDAP directory is configured and available
- LDAP uri is configured and a lookup on system level is working and returns the correct POSIX uid/gid with LDAP query
- no POSIX conflicts on the client (no object in passwd has uid/uid 11004) I can assume this because the fail over is root
- LDAP search base is configured and returns expected POSIX values
And I’ll make the following postgres assumptions:
- pg_hba.conf is configured for LDAP server address, port, and search base
- postgres can instantiate and connect to its dbs using LDAP with ldap
Finally, I’ll assume that your nfsv4 mount is active and that POSIX operations work at Pam - level tests.
The line
group: files [SUCCESS=merge] sss [SUCCESS=merge] systemdSeems weird to me; either you add success clause to both uid and gid, or none, but not one and not the other.
This would also hint that Pam has not been updated to use LDAP.
That’s where I’d start.
Side note: LDAP is by default unencrypted on the wire, so to complete this exercise, you may want to setup secrecy on the server. This is especially important for db creds.
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
[]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
%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!