1 |
On Wednesday, November 30, 2016 8:54:42 AM EST Michał Górny wrote: |
2 |
> On Tue, 29 Nov 2016 18:13:29 -0500 |
3 |
> |
4 |
> "William L. Thomson Jr." <wlt-ml@××××××.com> wrote: |
5 |
>> |
6 |
> > I think you mean enewgroup and enewuser |
7 |
> |
8 |
> FYI, enew* functions handle UID/GID collisions gracefully, and just |
9 |
> fallback to using next free UID/GID. |
10 |
|
11 |
I would disagree with such and some what makes specifying a UID/GID pointless |
12 |
if it simply will use the next available in the event of a collision. Which |
13 |
available likely comes from the default allocation range > 500 or 1000. If |
14 |
system and was intended to be below that, not really ideal. |
15 |
|
16 |
> I'm not sure if you're aware that but most of tools doing backups |
17 |
> actually use usernames/group names. So does new enough tar. So does |
18 |
> ssh. |
19 |
|
20 |
tar can map users and groups via file, but why waste the time with such? |
21 |
|
22 |
> Are you specifically using some obsolete or braindead tools to prove |
23 |
> your point? If you don't sync UIDs/GIDs properly, then you don't use |
24 |
> them when moving data across systems. Simple as that. |
25 |
|
26 |
I start with consistent base images and have the same uid/gid all on all so |
27 |
syncing is not needed. Nor do I need to deal with it during restoration. |
28 |
|
29 |
> The only thing that you could worry about then are missing users/groups |
30 |
> on the target system. But then, so far none of your talk solved that |
31 |
> problem. |
32 |
|
33 |
A problem that should not exist with a proper setup. |
34 |
|
35 |
-- |
36 |
William L. Thomson Jr. |