ooni / sysadmin

System administration tools
https://ooni.org
59 stars 26 forks source link

Change the uid scheme #289

Closed hellais closed 5 years ago

hellais commented 5 years ago

Currently in ooni-sysadmin we have a user id scheme whereby the uid of every user on (human and non-human) on all the ooni controlled hosts is unified, see: https://github.com/ooni/sysadmin/blob/master/ansible/group_vars/all/vars.yml#L21.

This means, for example, that the user art will have on all machines always the uid 1002.

The idea behind having a unified user id was that it would solve the issue of working with NFS. Since we are not actually using or planning on using NFS in the end we don't really need to have unified UID accross machines.

This would also solve the problem that currently exists with some uid conflict for example with the pipeline benchmark user:

roles/node_exporter/files/seeksample.py
10:# TODO: `benchmark` is an ugly legacy username for uid=1000 at datacollector.infra.ooni.io, it should be eventually re-numbered
12:  file: path={{item}} owner=benchmark group=benchmark
roles/airflow/tasks/main.yml
24:  file: dest=/data/ooni/private/spool/{{ item }} state=directory owner=benchmark group=root mode=0755
roles/airflow/files/docker-trampoline
13:# FIXME: 1000 = `id -u benchmark` at the datacollector dom0
219:# FIXME: hardcoded uid of the `benchmark` user at `datacollector`

failed: [awsairflow] (item=/srv/etc/collector_ssh/id_ed25519) => {"changed": false, "gid": 0, "group": "root", "item": "/srv/etc/collector_ssh/id_ed25519", "mode": "0600", "msg": "chown failed: failed to look up user benchmark", "owner": "root", "path": "/srv/etc/collector_ssh/id_ed25519", "size": 411, "state": "file", "uid": 0}
failed: [awsairflow] (item=/srv/etc/collector_ssh/id_ed25519.pub) => {"changed": false, "gid": 0, "group": "root", "item": "/srv/etc/collector_ssh/id_ed25519.pub", "mode": "0644", "msg": "chown failed: failed to look up user benchmark", "owner": "root", "path": "/srv/etc/collector_ssh/id_ed25519.pub", "size": 102, "state": "file", "uid": 0}
darkk commented 5 years ago

we are not actually using or planning on using NFS in the end

Just a historical node: the plan to use NFS actually existed as one of the options to fetch files in the pre-object-store-era for the reason I don't quite remember (e.g. I don't recall the reason to consider NFS in favor of plain nginx serving files).

Now, as GH's object store in a betta shape, NFS has no reason to appear in the foreseeable future.