UID
UID ranges
| UIDs | Usage | Notes |
|---|---|---|
| 0 | root | |
| 1-999 | System users | Also includes a few human users for legacy reasons |
| 1000-49999 | Humans | LDAP is the authoritative source for UID assignments; do not use an UID for a production shell account that is not assigned to the same user in LDAP (LDAP uid = shell username) |
| 50000-59999 | Toolforge tools | Stored in LDAP, created by toolsadmin.wikimedia.org. |
| 60000-64999 | System users | Assigned by Debian (see policy § 9.2.2) |
| 65000-65535 | Reserved by Debian | This includes:
|
| 65536-4294967293 | Unused | Unused for now. Potential future use includes extra IDs for users/toolforge tools if the current allocations aren't enough |
Reserved UIDs & GIDs
Althrough we try to keep this up-to-date it the authoritative source is admin.yaml
Make sure to add reservation entry to admin.yaml
If you want the account to be created every where you must reserve the UID in the puppet admin module and use systemd-sysuser. like in this example.
If the user will just exist on a few machines then you should reserve the account in the admin module with a commented block. like in this example, then create the user with a normal user block e.g.
systemd::sysuser { 'phd':
ensure => present,
id => '920:920',
description => 'Phabricator daemon user',
home_dir => '/var/run/phd',
}
- (table columns are sortable)
| UID | GID | user name |
|---|---|---|
| 33 | 33 | www-data |
| 48 | 48 | apache |
| 107 | 112 | puppet |
| 110 | 115 | nagios |
| 111 | 116 | mwdeploy |
| 130 | 130 | (swift on some old systems, to be phased out by late 2024 cf. T123918) |
| 445 | 445 | rancid |
| 497 | 498 | phd (phabricator) (outdated! on newer servers replaced with 920) |
| 499 | 499 | trebuchet |
| 901 | 901 | reprepro |
| 902 | 902 | swift |
| 903 | 903 | hdfs (previously jenkins) |
| 904 | 904 | yarn |
| 905 | 905 | mapred |
| 906 | 906 | analytics |
| 906 | 906 | analytics |
| 907 | 907 | druid |
| 908 | 908 | hadoop |
| 909 | 909 | analytics-privatedata |
| 910 | 910 | analytics-product |
| 911 | 911 | analytics-search |
| 912 | 912 | analytics-research |
| 913 | 913 | analytics-platform-eng |
| 914 | 914 | minio-user |
| 915 | 915 | git |
| 916 | 916 | kafka |
| 917 | 917 | bgpalerter |
| 918 | 918 | stats |
| 919 | 919 | scap |
| 920 | 920 | phd (phabricator, was 497:498) |
| 921 | 921 | librenms |
| 922 | 922 | doc-uploader |
| 923 | 923 | zuul |
| 924 | 924 | jenkins |
| 925 | 925 | gerrit |
| 926 | 926 | spark |
| 927 | 927 | analytics-wmde |
| 928 | 928 | authdns |
| 929 | 929 | librenms |
Permission/security hierarchy
the security hierarchy looks as follows as decribed by TimStarling:
- root > wikidev > mwdeploy > www-data
- root can own wikidev but wikidev can't own root
- wikidev can own mwdeploy but mwdeploy can't own wikidev
- scripts owned by mwdeploy can only be run by www-data
- everything has to su to www-data before running maintenance scripts
also see: task T79786