| taavi | |
| Jan 23 2024, 11:36 AM |
| F62405926: Screenshot 2025-06-20 at 16.10.06.png | |
| Jun 20 2025, 10:21 PM |
We currently allocate UIDs up to 49999 to human users. We're currently using IDs up to 45977 as of writing which seems to indicate to me that we need to start thinking what to do in about 4,000 users.
Given that UIDs are a 32-bit integer it seems like we could just allocate IDs from 1,000,000 to 1,999,999 for users and call it good for the next few centuries at least.
Currently the highest number in use is 47058. So that's 1081 accounts in the 148 days since I created this task, or about 7.3 accounts per day. Assuming a similar rate of growth we're looking at running out of numbers in about 400 days, which would be late July next calendar year.
Today we're up to 48484. So the growth has slowed a bit to about 6.7 accounts per day, which would mean we have until mid-September (and not until late July I predicted last June).
Hello @MoritzMuehlenhoff and @SLyngshede-WMF -- this re-allocation/bitu change needs to happen soon. We have a corresponding change we'll need to make in the striker config when you change the ID range.
I've made the necessary edit to reserve 1000000 to 2000000 for users.
Next week I'll create a dummy user with uid=1000000 manually via ldapmodify and test that it works for web access and SSH access (no issues expected, just to make sure). Once we have 1000000 in place, Bitu will automatically increment based on the highest allocated number. @Andrew We'll reach out to you when the change is in place, so that Striker can be adapted.
If anyone sees a problem with that plan, please speak up :-)
I'm not sure it is much of an issue, but that range overlaps with systemd-nspawn's range, 524288 to 1879048191 [1]. We don't use systemd-nspawn at present, but perhaps we should avoid it anyways?
[1]: https://systemd.io/UIDS-GIDS/#:~:text=Unused-,524288%E2%80%A61879048191,-Container%20UID%20ranges
That's a good point! I poked around if I could find a way to configure the range differently, but it seems there is no such way. nspawn is really nice, I use it lot for my personal systems and we should strive not to block the use for us if we can avoid it.
My alternative proposal would be to allocate 100.000 to 500.000 for human users, then. How does that sound to everyone?
Sounds good to me, 400.000 should last a pretty long time.
I still think that we should stop allocating uidNumbers to users who don't need them, but we can discuses that some other time.
By this I assume you mean somehow changing Developer accounts to no longer be objectClass: posixAccount records. I imagine that would be possible. We would need to add some new automation to Cloud-VPS and Striker in that case to make sure that Developer accounts which are being attached to our OpenStack deployment as tenants were promoted to being proper objectClass: posixAccount records when they are added to Keystone and made members of any Cloud VPS project.
In the current LDAP tree it looks like this might have saved ~37K historic user id allocations. (ldap '(&(!(memberOf=cn=project-bastion,ou=groups,dc=wikimedia,dc=org))(objectClass=posixAccount))' cn -b ou=people,dc=wikimedia,dc=org| grep cn: | wc -l) That is probably a slight over count because of accounts that once had Cloud VPS project membership but no longer do.
I have a hunch that a reasonably large percentage of the 37K Developer accounts that are not connected to Cloud VPS projects were the byproduct of spam bots signing up for wikitech.wikimedia.org accounts prior to October 2024. Graphing the account creations by month seems to show that we did have an extended period of higher than average account creation from 2020-2023 that has since returned to something a bit more historically normal. The normal rate seems to be around 175 new accounts created per month.
$ ldapsearch -xLLL -P 3 -E pr=5000/noprompt -o ldif-wrap=no 'objectClass=posixAccount' createTimestamp -b ou=people,dc=wikimedia,dc=org | grep createTimestamp: | cut -d' ' -f 2 | cut -c 1-6 | sort | uniq -c
Mentioned in SAL (#wikimedia-operations) [2025-07-08T08:30:23Z] <moritzm> created a stub user "bumpuid" to move the allocation of UIDs for accounted created in Wikimedia IDM to 100000+ T355663
Change #1167155 had a related patch set uploaded (by Majavah; author: Majavah):
[labs/striker@master] settings: Update UID ranges
I created a user manually with the folllowing LDIF:
dn: cn=bumpuid,ou=people,dc=wikimedia,dc=org uid: bumpuid cn: bumpuid sn: bumpuid uidNumber: 100000 gidNumber: 500 givenName: Not a real user homeDirectory: /home/bumpuid objectClass: person objectClass: inetOrgPerson objectClass: organizationalPerson objectClass: posixAccount userPassword: REDACTED description: The only purpose is to move the UID in use to 100k
Since then a new user has been created in Bitu (paws-infra), which got the UID 100001 assigned.
Change #1167155 merged by jenkins-bot:
[labs/striker@master] settings: Update UID ranges
Change #1167165 had a related patch set uploaded (by Majavah; author: Majavah):
[operations/puppet@production] hieradata: Bump Striker to 2025-07-08-094946-production
Change #1167165 merged by Majavah:
[operations/puppet@production] hieradata: Bump Striker to 2025-07-08-094946-production
Change #1169235 had a related patch set uploaded (by Ssingh; author: Ssingh):
[operations/puppet@production] admin: data_test.py: bump system_uid_max to 499999
Change #1169235 merged by Ssingh:
[operations/puppet@production] admin: data_test.py: bump system_uid_max to 499999
Change #1169250 had a related patch set uploaded (by Ssingh; author: Ssingh):
[operations/puppet@production] admin: schema.yaml: bump max for uid
Change #1169250 merged by Ssingh:
[operations/puppet@production] admin: schema.yaml: bump max for uid