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