Maniphest T120585

Make l10nupdate user a system user
Closed, DeclinedPublic
Actions

Assigned To

None

Authored By

	bd808
	Dec 6 2015, 10:20 PM

Description

In the process of working on T119746: localisationupdate broken on wmf wikis by scap master-master sync changes the use of the l10nupdate user was simplified so that it no longer has its own ssh key pair for updating the MediaWiki servers and instead uses a scap command and the normal shared deployment key. As a consequence of this, the l10nupdate user will no longer be provisioned on normal MediaWiki hosts.

@faidon has asked several times why the l10nupdate user is not a system user. With the current state of the system this should now be possible:

Renumber l10nupdate uid on tin and mira to use a system id (100-999)
Renumber l10nupdate gid on tin and mira to use as system id (100-999)
Change puppet to provision the l10nupdate user and group with new uid/gid
Change puppet to remove provisioning ~l10nupdate/.gitconfig
Remove /home/l10nupdate on tin and mira
Restart cron on tin and mira to recognize the new uid/gid

See T119165: l10nupdate user uid mismatch between tin and mira for an explanation of why we want/need a static uid/gid for the l10nupdate account in general (TL;DR rsync+chroot uses numeric ids).

Details

	Subject	Repo	Branch	Lines +/-
	scap: change l10nupdate UID from 10002 to 120	operations/puppet	production	+3 -2

Customize query in gerrit

Related Objects
Search...

		Status	Subtype	Assigned	Task
		Open		None	T121610 system users with UIDs > 500
		Declined		None	T120585 Make l10nupdate user a system user

Event Timeline

bd808 created this task.Dec 6 2015, 10:20 PM

bd808 raised the priority of this task from to Medium.

bd808 updated the task description. (Show Details)

bd808 added projects: SRE, Deployments.

bd808 added subscribers: bd808, faidon, Dzahn.

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptDec 6 2015, 10:20 PM

bd808 mentioned this in T119746: localisationupdate broken on wmf wikis by scap master-master sync changes.Dec 6 2015, 10:21 PM

Krenair subscribed.Dec 6 2015, 11:45 PM

Let's start by agreeing on a specific (lower) UID for this and then update
https://wikitech.wikimedia.org/wiki/UID

So what number do we pick?

after taking a look at tin and mira (and finding more inconsistencies and "system" users with UIDs over 10000) i suggest we do

UID 120 for l10nupdate

Change 259441 had a related patch set uploaded (by Dzahn):
scap: change l10nupdate UID from 10002 to 120

https://gerrit.wikimedia.org/r/259441

gerritbot added a project: Patch-For-Review.Dec 16 2015, 1:05 AM

Dzahn mentioned this in T121610: system users with UIDs > 500.Dec 16 2015, 1:17 AM

Dzahn added a parent task: T121610: system users with UIDs > 500.

bd808 updated the task description. (Show Details)Dec 16 2015, 4:23 PM

bd808 set Security to None.

At https://gerrit.wikimedia.org/r/259441 @faidon has raised questions:

Does this need to be statically assigned?

I responded with:

We need the account to have the same uid on all deploy servers. This is required by our chrooted rsync setup and the need to mirror /srv/mediawiki-staging between tin and mira. I did a pretty detailed write up on the "why" of this in T119165#1825437.

That response led to additional questions from @faidon:

How does it work with mwdeploy then?

The implemented cross-master sync component of scap works by allowing the mwdeploy user to sudo as root one specific script that is provisioned via Puppet. These changes were made in rOPUP5d74cf04a44f: scap: Create wrapper script for master-master rsync and rMSCA1092d12630ab: Sync with master via external script for T117016: beta-scap-eqiad mira / deployment-bastion permissions problem.

What's the benefit of using rsync with a chroot?

That is the default behavior of our ::rsync::server puppet class. The man page for rsyncd.conf suggests "This has the advantage of extra protection against possible implementation security holes".

In any case, this change is broken: there is no guarantee 120 won't be reused by a different system user (either via puppet, or via a simple package install).

Choosing a low number in the system reserved range (100-999) does seem likely to cause a conflict with another package that has claimed a UID via adduser --system. Would allocating from the top end of the range instead of the bottom be less likely to cause issues?

Or should we reassess the use of use chroot = yes for the scap rsync server so we can drop the identical uid/gid requirement across the deploy masters and let rsync use its default named based system?

Change 259441 abandoned by Dzahn:
scap: change l10nupdate UID from 10002 to 120

https://gerrit.wikimedia.org/r/259441

In T120585#1885495, @bd808 wrote:

Choosing a low number in the system reserved range (100-999) does seem likely to cause a conflict with another package that has claimed a UID via adduser --system. Would allocating from the top end of the range instead of the bottom be less likely to cause issues?

Puppet does that when you don't specify a uid, so there is still the possibility of collisions.

Or should we reassess the use of use chroot = yes for the scap rsync server so we can drop the identical uid/gid requirement across the deploy masters and let rsync use its default named based system?

That sounds like a better idea to me, yeah. Definitely better than hardcoding uids in the puppet tree.

Dzahn removed Dzahn as the assignee of this task.Dec 23 2015, 12:26 AM

The last comment "Definitely better than hardcoding uids in the puppet tree." sounds like this ticket might be rejected?

• Phabricator_maintenance moved this task from To Triage to Localization on the Deployments board.Sep 26 2017, 11:24 PM

• Phabricator_maintenance moved this task from Backlog to Acknowledged on the SRE board.Jan 26 2019, 8:27 PM

Umherirrender removed a project: Patch-For-Review.Apr 5 2022, 6:44 PM