Unify remap user tasks from os_setup role

[kysrpex]

Remove remap user tasks for CentOS 8 (roles/os_setup/tasks/remap_user/centos8.yml) and use the RHEL 9 tasks file for all RHEL versions.

The tasks for CentOS 8 do not work with other operating system releases, while the tasks for RHEL 9 are more general and should work across operating system versions.

[kysrpex]

@mira-miracoli wrote:

What was the issue again with the OS major version separated remap_user.py? (how it was before #16 )

There were several issues with the status before #16:

• roles/os_setup/tasks/remap_user/centos8.yml solves the problem only for CentOS8, because it replaces lines that you can only expect in CentOS8 (e.g. input:x:999: and systemd-coredump:x:999:997:systemd Core Dumper:/:/sbin/nologin).
• The above alone is not an issue but, roles/os_setup/tasks/remap_user/rhel9.yml solves the same problem in a more general way, in particular, it works for CentOS8. This means that there are two tasks to solve a single problem. It does not make sense to have two tasks to solve a single problem. In general, it does not make sense to have two pieces of code meant to solve exactly the same problem, just like it does not make sense to have more than one single source of truth for data.
• The solution for RHEL9 itself has the following problems:
  • It runs when: (not "galaxy" in getent_group.keys()) and when: (not "galaxy" in getent_passwd.keys()). This role runs on nodes, such as mq.galaxyproject.eu, where the user with UID 999 is not named galaxy and the group with GID 999 is not named galaxy. This causes nasty effects, for example changing the ownership of all files owned by 999 to user 500, on every run, and the same for group ownership. This is the biggest issue.
  • It replaces all occurrences of 999 with 500 in the passwd file. Each line in the passwd file contains two numbers, one for the uid of the user and one for the gid of the user. I think if you only ever want to have a user and group galaxy both with id 999 this is a problem, but it breaks down in more complex use cases because in addition to remapping user ids, that also reassings the user to group 500. Considering that we have a task create_user.yml that let's you specify arbitrary users, not just galaxy, I think it makes sense to make things work whatever users or groups you want to add, hence Enhance remap user tasks from os_setup role #18.

[kysrpex]

@mira-miracoli To add to the previous message, in #16 I have just blindly trusted roles/os_setup/tasks/remap_user/rhel9.yml to be correct for all our use cases (including machines where the user and/or 999 is not named galaxy), which is not the case. Hence #18.

[kysrpex]

@mira-miracoli I think in fact you already wrote about all this yourself here, sorry for not realizing earlier.