| 1 |
On 2021-11-11 11:59, Ulrich Mueller wrote:
|
| 2 |
> We could: |
| 3 |
> |
| 4 |
> - Open some part of the range between 500 and 1000. For example, |
| 5 |
> 500..799, which would leave 200 IDs for dynamic allocation. |
| 6 |
> |
| 7 |
> - Open part of the range 60001..65533. Not sure if all software will be |
| 8 |
> happy with that. |
| 9 |
> |
| 10 |
> - Admit that the concept of static allocation has failed, and return to |
| 11 |
> dynamic allocation. |
| 12 |
|
| 13 |
Only the third option is really possible.
|
| 14 |
|
| 15 |
The first option (500-1000) would be technically possible but would
|
| 16 |
clash with knowledge people gained in the past and would violate LPIC
|
| 17 |
(=making Gentoo even more special and unusable for companies relying on
|
| 18 |
certifications).
|
| 19 |
|
| 20 |
In addition, it would just delay the problem we currently have and not
|
| 21 |
solve/address it.
|
| 22 |
|
| 23 |
Allowing ranges 60001+ is technically not an option. Expect that daemons
|
| 24 |
using IDs >1000 will run into problems. Expect security problems because
|
| 25 |
known system user range is hardcoded in many places so 60001+ is
|
| 26 |
unexpected. This will really make Gentoo 'unique' in a really bad way
|
| 27 |
and will break with everything which is/was being taught/documented in
|
| 28 |
the world.
|
| 29 |
|
| 30 |
Let's face it: The idea of static ID allocation didn't scale. Let's stop
|
| 31 |
this experiment before it is too late. Like you know, I always ask why
|
| 32 |
someone is proposing a change, i.e. asking for the motivation. The main
|
| 33 |
driver behind static IDs was that when you are maintaining multiple
|
| 34 |
systems, that if IDs are identical, it will make life a little bit
|
| 35 |
easier because you could copy files from service A on system 1 to
|
| 36 |
service A on system 2 without the need of adjusting permission
|
| 37 |
afterwards. But is this really a problem? From my POV it isn't:
|
| 38 |
|
| 39 |
1) If this really was bothering you, you already had a solution in
|
| 40 |
place. Keep in mind: Most setups don't just consist of
|
| 41 |
Gentoo/Debian/RHEL-only... you usually have a mix of setups so you need
|
| 42 |
a solution which works everywhere so you don't need that 'feature'
|
| 43 |
Gentoo offered (not to mention that you probably have something like AD
|
| 44 |
in place which will make things like that very easy).
|
| 45 |
|
| 46 |
2) Pay attention to the way how you do stuff today. You will not create
|
| 47 |
systems manually anymore (and if you do, you would just clone so there
|
| 48 |
isn't even a need for this). You will automate this in scripts and use
|
| 49 |
tools like Ansible, Salt, Chef, Puppet.... and of course, Dockers (which
|
| 50 |
is basically a script) and like mentioned, AD.
|
| 51 |
|
| 52 |
From my POV I cannot imagine a single reason why we should stick to
|
| 53 |
this idea and invest more time into it with the risk of making Gentoo
|
| 54 |
more unique causing more _severe_ problems in future.
|
| 55 |
|
| 56 |
Anyone who wants to keep this around and wants to extend UID ranges
|
| 57 |
instead should answer the following questions:
|
| 58 |
|
| 59 |
1) How are you going to solve the mentioned problems?
|
| 60 |
|
| 61 |
2) Why do you believe this feature is worth all the trouble?
|
| 62 |
|
| 63 |
3) At the moment we can stop. But once we start altering systems to mark
|
| 64 |
additional ranges for system users there is _no_ easy way back anymore.
|
| 65 |
Any blow up will probably require user to reinstall their entire system...
|
| 66 |
|
| 67 |
|
| 68 |
--
|
| 69 |
Regards,
|
| 70 |
Thomas Deutschmann / Gentoo Linux Developer
|
| 71 |
fpr: C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5 |
Archives