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... dnsmasq is an irrelevant example of software which has absolutely nothing to do with the topic at hand.
Maybe, but currently most config snippets in /usr/lib/sysusers.d/ do not specify UID (except qemu.conf shipped with qemu). So I assume those get assigned randomly.
Again, that is the whole point. useradd assigns them randomly, and sysusers assigns them randomly. But there is a range of UIDs reserved for stuff that needs a non-random UID (because the UID needs to be known during makepkg for packaging). So yes, Arch expects hardcoded UIDs to be available below 500, which means system user UIDs can be and should be allocated from 500-999 (as opposed to, say, preemptively clobbering any potentially reserved UIDs below that).
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...
Of course, this needs to be done for all Arch machines.
Plus that.
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. -- Eli Schwartz