On Sun, Nov 27, 2016 at 10:32:38PM -0500, Eli Schwartz via arch-general wrote:
On 11/27/2016 10:03 PM, Leonid Isaev wrote:
Well, packages can have files that need to have a specific system user ownership. That is why the UID/GID database exists, right? Because the UID baked into the *.pkg.tar.xz has to match /etc/passwd, and systemd-sysusers can't inherently do anything that repetitive useradd + getent scripting wasn't always capable of.
For example, dnsmasq ships /usr/lib/sysusers.d/dnsmasq.conf which contains 'u dnsmasq - "dnsmasq daemon" /' and on my system the user dnsmasq has (randomly-generated) ID = 997. Such packages won't have any files owned by a non-root user because they don't know the UID.
Let's rephrase that. Some packages contain software which requires runtime files owned by a non-root user associated with the software.
The fact that they don't know the UID during makepkg is precisely the reason why the UID/GID database exists...
Yes, if such packages exist, then of course, they would require hardcoded UID.
Yes, why not? You can override files in /usr/lib/sysusers.d with files in /etc/sysusers.d having identical names, no? For example, on my workstation, there are only 23 lines in total where UID need to be changed below 500.
Because that is the classic definition of working around buggy software? useradd/sysusers was carefully designed to be able to dynamically allocate UIDs and now you have to copy and override every single sysusers definition because systemd won't let you configure the allocation range...
I kinda agree with Lennart Poettering here as to why systemd shouldn't read login.defs at runtime. Still, dealing with systemd ppl sucks... I mean once you do change ranges in login.defs, you'll have to fix user memberships as well, yes?
Of course, this needs to be done for all Arch machines.
Plus that.
Not only that, but also updates must be carefully monitored...
That is why I think that changing ownership in NFS share is a better idea...
Well, depending on the number of files... Anyway, modifying a single file in a very predictable manner on multiple *new* machines is an even better idea. Plus, Hauke Fath indicated that there were also plenty of files scattered across 50 other existing machines.
Hmm, I thought all /home's were on an NFS share... But I still don't understand why is it such a difficult task? Sure, migrating 10 year old installations this way is not pleasant, but at least this will be future-proof. Because how do you avoid clashes with hard-coded UID in packages now? Cheers, -- Leonid Isaev GPG fingerprints: DA92 034D B4A8 EC51 7EA6 20DF 9291 EE8A 043C B8C4 C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D