Hello,
for the 389-ds-base package we'd need static uid/gid assignment. The name to be used in /usr/share/doc/setup/uidgid should be "dirsrv" with uid/gid 389. We use those IDs already for a long time in 389-ds packaging and to avoid any issues that might occur in the future we'd like to request a static assignment .
FPC can indeed talk about whether 389 might need a static allocation, but to my knowledge the maintainers of the setup package have not ever allocated IDs out of order and the next free ID appears to be 194. The use of "389" specifically appears to be simple vanity and that's not going to be our call to make.
To be completely honest, I'm not sure where the static range ends. It used to be at 200.
As for what FPC can decide, can you give us a technical reason why the UID/GID pair for your packages needs to always be the same across machines?
Metadata Update from @tibbs: - Issue tagged with: meeting
Hi,
I'm a developer for the 389 Directory Server package.
The 389 uid/gid is indeed, vanity. There is no specific reason it has to be this allocation, but of course, on upgrade we would like the "dirsrv" user to remain with it's current uid - and that's a lot of freeipa installs out there in the wild. Splitting this so that some people have 389 or some "other number", would create some (limited) confusion. My concern would be upgrades.
The main reason for a "static" id would be backup/restore/migration between machines where the id's of the backup need to remain constant. FreeIPA I believe makes use of this (but I could be wrong).
Sadly, I think historical dependence on this value and uid name will be the cause of a static request.
I'm also not completely opposed to a dynamic allocation, but it does entail a risk that I'm not sure has been completed tested or examined yet.
Thanks,
William
I'm not sure why upgrades would be an issue.
If you're following the guidelines for the creation of the users you need, then nothing will change. The users are only added if they don't exist. No part of the packaging should actually care what numeric UID/GID was assigned, since ownership is done with the symbolic names. Since the user/group are added in %pre (i.e. before the actual package payload installation) everything simply works out.
Backups (via tar or cpio, at least) would generally use symbolic UIDs and GIDs as well. I would hope any application-level backup thing would not be tied to a specific numeric UID assignment; doing so would have to be considered a bug.
Really, the kind of things that need a static allocation are network filesystems or other network protocols which somehow require that multiple machines have the exact same UIDs. Even then, most of that should get solved as part of system deployment but that's what this committee has approved in the past. There are, of course, other situations but we would need a good explanation and certainly not conjecture about what a specific backup system might need.
Cool. So what's the correct process for us for gid/uid allocation in our rpm spec in this case?
We discussed this at this weeks meeting (https://meetbot-raw.fedoraproject.org/fedora-meeting-2/2018-01-24/fpc.2018-01-24-18.22.txt):
The guidelines for this are https://fedoraproject.org/wiki/Packaging:UsersAndGroups, specifically the "Dynamic Allocation" section.
I guess must must have already seen that because you appear to have been following that document when you filed your request. What remains unclear to me is why dynamic allocation fails to meet your needs.
Metadata Update from @tibbs: - Issue untagged with: meeting - Issue tagged with: needinfo
No answer for 4 months, closing.
Don't hesitate to reopen.
Metadata Update from @ignatenkobrain: - Issue close_status updated to: rejected - Issue status updated to: Closed (was: Open)
FYI: During a recent regular 389-ds meeting we have decided not to pursue this request any more as there is not enough reasoning for having this.
Log in to comment on this ticket.