On 11 January 2018 at 01:41, Zbigniew Jędrzejewski-Szmek <zbyszek@xxxxxxxxx> wrote: > On Wed, Jan 10, 2018 at 10:26:24AM -0500, Nico Kadel-Garcia wrote: >> On Wed, Jan 10, 2018 at 6:18 AM, Zbigniew Jędrzejewski-Szmek >> <zbyszek@xxxxxxxxx> wrote: >> > On Wed, Jan 10, 2018 at 11:56:46AM +0100, Reindl Harald wrote: >> >> >> >> Am 10.01.2018 um 11:46 schrieb Jan Kurik: >> >> >On existing systems, to make upgrades easier: >> >> >* if nfsnobody was defined, keep it in /etc/passwd *after* the new >> >> >line for nobody:nobody, so that both the old name and the new name map >> >> >to the same numbers >> >> >* if nobody user or group with number 99 was defined, keep it in >> >> >/etc/passwd and /etc/group, but rename to _nobody >> >> that don't make updates easier but breaks existing setups where >> >> nobody:nobody with 99:99 already owns files - don't touch long years >> >> running machines due dist-upgrades please - at least not with "dnf >> >> --releasever=28 distro-sync" >> > >> > That'd amount to leaving existing systems unchanged. That's an option >> > that I didn't like and initially rejected, but yeah, it's probably better. >> > I'll wait a bit more for feedback and update the proposal a bit later >> > to leave existing systems alone (i.e. systems which have either nobody >> > or nfsnobody already defined in the old style). >> > >> > Zbyszek >> >> This is particularly relevant for rsync or tar restorations from old >> backups, and to NFS shares exposed across old and new environments. >> It's why changing active uid and and gid for any account can be >> perniciously awkward. > > Based on this and other feedback, we updated the proposal. > We discussed all the ways in which we could try to reliably determine > if "nobody" is actually used, but that seems impossible. So the updated > version is: > > 1. update setup.rpm to nobody=65534 on new systems > 2. teach systemd to not provide any mapping for nobody (in PID1 and in > nss-systemd) based on a flag file, and create this file in %post if > either nobody=99 or nfsnobody users are defined. > > This essentially means that existing systems would behave as before, > and new systems will have just one nobody user with uid=65534. > > See https://fedoraproject.org/wiki/Changes/RenameNobodyUser for more > detailed description. > I know this may sound fairly nasty in terms of work required to agree a solution but I honestly have a strong dislike to taking this approach. Having upgraded and freshly installed systems so different is going to be messy with supporting users and in many deployed environments... and it's not even about F26 and F27 -> F28 but what happens on an F29+ system? Is this workaround going to be maintained in perpetuity? Is it just going to cause even more confusion then? As a very simple example take a docker host that has been upgraded with a fresh container on it. The nobody user is going to differ between the two which will at a minimum cause confusion, if not actual issues to arise. Sometimes you just need to "bite the bullet" on a change and accept it will be painful in the short term for benefit in the longer term. Because of these concerns I'd strongly favour the original plan (renaming existing nobody user and creating the new one). To make sure this is clear and to mitigate any potential issues make sure that this change of behaviour is clearly communicated. Document the change in the release notes and in known issues. Put up an article on Fedora Magazine highlighting it. For fresh installs there's effectively no difference. For anyone upgrading they need to check release notes and known issues anyway so they are the ones that need to know about this. This then ensures consistency of what "nobody" means going forwards to minimise the potential support problems and to make QA have an easier time with what it means for upgrades, installs and containers. _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
