You are browsing a read-only backup copy of Wikitech. The primary site can be found at wikitech.wikimedia.org
UID: Difference between revisions
Jump to navigation
Jump to search
imported>BryanDavis m (→UID ranges) |
imported>Jbond |
||
Line 126: | Line 126: | ||
|916 | |916 | ||
|kafka | |kafka | ||
|- | |||
| 917 | |||
|917 | |||
|bgpalerter | |||
|- | |- | ||
|10002||10002||l10nupdate | |10002||10002||l10nupdate |
Revision as of 14:07, 1 February 2022
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 resever 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 { 'git':
content => [
'usertype' => 'u',
'name' => 'git',
'id' => 915:915,
'gecos' => 'git used by GitLab',
'home_dir' => '/var/opt/gitlab',
]
}
- (table columns are sortable)
UID | GID | user name |
---|---|---|
33 | 33 | www-data |
48 | 48 | apache |
107 | 112 | puppet |
110 | 115 | nagios |
111 | 116 | mwdeploy |
444 | 444 | gerrit2 |
445 | 445 | rancid |
498 | 498 | phd (phabricator) |
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 | (available for use) |
915 | 915 | git |
916 | 916 | kafka |
917 | 917 | bgpalerter |
10002 | 10002 | l10nupdate |
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