You are browsing a read-only backup copy of Wikitech. The live site can be found at wikitech.wikimedia.org

UID: Difference between revisions

From Wikitech-static
Jump to navigation Jump to search
imported>Dzahn
 
imported>Jbond
(18 intermediate revisions by 10 users not shown)
Line 1: Line 1:
===reserved UIDs & GIDs===
==UID ranges==
{| class="wikitable"
|+Used UID ranges on Wikimedia systems
!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 [https://www.debian.org/doc/debian-policy/ch-opersys.html#uid-and-gid-classes policy § 9.2.2])
|-
|65000-65535
|Reserved by Debian
|This includes:
 
* 65000-65533 unused at the time
* 65534 is the user "nobody"
* 65535 must not be used due to compatibility issues with legacy systems (65535 = 2^16 - 1)
|-
|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 [[gerrit:plugins/gitiles/operations/puppet/+/production/modules/admin/data/data.yaml|admin.yaml]]


This is most likely not the desired state yet, but just starting out with the current situation on [[fenari]]. Should be edited to reflect the desired situation, being equal on all servers.
'''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 [[gerrit:c/operations/puppet/+/573991/7/modules/admin/data/data.yaml|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 [[gerrit:c/operations/puppet/+/666133/5/modules/admin/data/data.yaml|this example]], then create the user with a normal user block e.g.
 
<syntaxhighlight lang="puppet">
    systemd::sysuser { 'git':
      content    => [
      'usertype' => 'u',
      'name'    => 'git',
      'id'      => 915:915,
      'gecos'    => 'git used by GitLab',
      'home_dir' => '/var/opt/gitlab',
      ]
    }
</syntaxhighlight>


*(table columns are sortable)
*(table columns are sortable)
{| class="wikitable sortable"
{| class="wikitable sortable"
|-
|-
! UID !! GID !! user name
!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. [[phab:T123918|T123918]])
|-
|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|| minio-user
|-
|915||915||git
|-
|-
| 33 || 33 || www-data
| 916
|916
|kafka
|-
|-
| 48 || 48 || apache
| 917
|917
|bgpalerter
|-
|-
| 107 || 112 || puppet
|918
|918
|stats
|-
|-
| 110 || 115 || nagios
|919
|919
|scap
|-
|-
| 111 || 116 || mwdeploy
|10002||10002||l10nupdate
|}
|}


=== permission/security hierarchy ===
==Permission/security hierarchy==


the security hierarchy looks as follows as decribed by TimStarling:
the security hierarchy looks as follows as decribed by TimStarling:  


*'''root > wikidev > mwdeploy > apache'''
*'''root > wikidev > mwdeploy > www-data'''
**root can own wikidev but wikidev can't own root
**root can own wikidev but wikidev can't own root
**wikidev can own mwdeploy but mwdeploy can't own wikidev
**wikidev can own mwdeploy but mwdeploy can't own wikidev
**scripts owned by mwdeploy can only be run by apache
**scripts owned by mwdeploy can only be run by www-data
**everything has to su to apache before running maintenance scripts
**everything has to su to www-data before running maintenance scripts




also see: [[RT:1406]]
also see: {{phabT|79786}}

Revision as of 13:06, 9 May 2022

UID ranges

Used UID ranges on Wikimedia systems
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:
  • 65000-65533 unused at the time
  • 65534 is the user "nobody"
  • 65535 must not be used due to compatibility issues with legacy systems (65535 = 2^16 - 1)
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
130 130 (swift on some old systems, to be phased out by late 2024 cf. T123918)
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 minio-user
915 915 git
916 916 kafka
917 917 bgpalerter
918 918 stats
919 919 scap
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

Retrieved from "https://wikitech-static.wikimedia.org/w/index.php?title=UID&oldid=590383"