Hello project maintainers, Some of the files that are currently stored on NFS by several projects are currently owned by users whose numerical IDs are not stable between instances, and may cause issues now or in the future term as a consequence of work on:
https://phabricator.wikimedia.org/T87870 Please examine the list in the ticket above to see if your project is one of the affected ones and for a list of directories containing possibly problematic files. == How to fix this? == Simply changing the owner to the files to that of a user in LDAP (actual users as well as project service groups), or a user managed by puppet will prevent any possible issue. Please note that users managed by debian packages (such as the 'syslog' user) are *not* stable between instances as the actual UID assigned varies between instances depending on what packages are installed and in which order they happened to be installed). == What happens if you don't change it? == You may already be experiencing issues as a consequence of this if you attempt to access the files from more than one instance, but if the files remain with that UID after idmap is turned off for NFS then it may become impossible to access them without using root if the users on your instance change. Process or services that expect to be able to read from or write to these files may fail, either immediately or at some point in the future when and if the UID changes as a consequence of reinstallation or changing which instance is attempting to do the access. This is not a consequence of the pending change, but a property of the way NFS manages file permissions. == When must this be done? == While there is no urgency (files which are being used without issues now will continue to work past the change to idmap with no change), the change means that any /future/ change in UID on any of your instances may introduce problems. As best practice, files on shared NFS filesystems should only be owned by users whose UID are being centrally managed. Please review the listed directories and consider alternate users to own the files, or store those files on instance-local storage. -- Marc _______________________________________________ Labs-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/labs-l
