Hi,
On 2021/11/11 14:10, Pacho Ramos wrote:
> In any case, 300 additional IDs may not be future proof at the rate
>> we're currently allocating them. So I wonder if we shouldn't move to
>> above 60000 immediately, or alternatively, give up the whole concept.
>>
>> Ulrich
> Personally I would move to >60000 and keep the 300 additional IDs for the case
> some software really really needs them
# getent passwd | awk -F: '{ print $3 }' | sort -g | tail -n3
37945
37946
65534 <-- this happens to be nobody.
>60000 up to where? 65533? I'll need to make a "hole" in our
allocations but that's perfectly do-able. Others may run into similar
issues and be caught unawares (especially if UID/GID values are
allocated from some other system which may not be aware of UID/GID
values on specific servers). Might be worth the trouble to head to
>=2^31, but that will again fail on systems that still use 16-bit
UID/GID values (I'm not aware that we still support kernels older than 2.4).
https://systemd.io/UIDS-GIDS/ basically says system users (which we're
discussing here) is <1000. systemd also already violates this statement
itself just a few paragraphs down with special systemd UID and GID
ranges. And already >60000 ranges listed here (most of 60000 to 65533
is reserved by systemd).
Kind Regards,
Jaco
