Description of problem: 389-ds-base has a postinstall script that intends to add a passwd entry for dirsrv, hunting for an unused uid starting at 389, like this: dirsrv_uid=389 while [ "`getent passwd | awk -F: '{print $3}' | grep $dirsrv_uid`" != "" ]; do dirsrv_uid=`expr $dirsrv_uid + 1` done This is bad for several interacting reasons. First, it downloads the *entire* passwd map for every loop iteration. This is very expensive for large ldap passwd maps, especially since such downloads are not cached by sssd (or nscd). Second, the loop termination test is sloppy, because the grep regexp isn't anchored to match the entire uid, so there are many false matches, like this: shell$ getent passwd | awk -F: '{print $3}' | grep 389 389 11389 23895 23389 5389 3389 10389 23896 23893 23890 12389 23899 23898 22389 23894 23892 23897 23891 24389 13389 25389 It actually loops until it finds a sequence of digits that does not occur in *any* uid, which can require thousands of iterations for large passwd maps. Third, the combination of many hosts doing many passwd downloads can cause so much ldap abuse that getent passwd occasionally fails, which can cause an already assigned uid to be chosen. The script similarly tries to update the group map, with similar bad results, but the group termination test is even sloppier ... while [ "`getent group | grep $dirsrv_gid`" != "" ]; do ... which incorrectly matches the proposed gid *anywhere* within each group line. Version-Release number of selected component (if applicable): 389-ds-base-1.3.5.10-12.el7_3.x86_64 How reproducible: Always
git patch file (master) 0001-Ticket-49088-389-ds-base-rpm-postinstall-script-bugs.patch
I'm happy to ack this, but I think there is a facility in RHEL / Fedora where we can register a name -> uid, so we can guarantee it will always be ours. Consider apache is always uid 80 for example. Should we investigate this? Because that way we wouldn't need the "random if not found" .
Replying to [comment:3 firstyear]:
Yeah... What we'd like to solve is finding out an available uid/gid. By default, we chose (389,389). When it is already taken by some other account, do you think which uid needs to be assigned?
But in what case would it already be taken? That's the point of the fedora / rhel system to reserve ids, so that no one else can take them. I think there would be very few cases 389 is already claimed.
The greatest risk is that two server end up installed with different uids for dirsrv, and it causes issue on nfs or backups, or something. Unlikely, but possible.
Still, like I said I think this conflict will be very rare, so lets go ahead with this change.
git patch file (master) -- revised following the Fedora Project allocation strategy 0001-Ticket-49088-389-ds-base-rpm-postinstall-script-bugs.2.patch
Thanks for the discussion and the review, William.
As suggested by Frank, it'd be the safest to follow the Fedora Project allocation strategy, which you also pointed out in the discussion.
Pushed to master: 28e5e15..c969a82 master -> master commit c969a82
Pushed to 389-ds-base-1.3.5: b9e565d..0cb9c6c 389-ds-base-1.3.5 -> 389-ds-base-1.3.5 commit 0cb9c6c
Metadata Update from @nhosoi: - Issue assigned to nhosoi - Issue set to the milestone: 1.3.5 backlog
389-ds-base is moving from Pagure to Github. This means that new issues and pull requests will be accepted only in 389-ds-base's github repository.
This issue has been cloned to Github and is available here: - https://github.com/389ds/389-ds-base/issues/2147
If you want to receive further updates on the issue, please navigate to the github issue and click on subscribe button.
subscribe
Thank you for understanding. We apologize for all inconvenience.
Metadata Update from @spichugi: - Issue close_status updated to: wontfix (was: Fixed)
Login to comment on this ticket.