This may be invalid? id l10nupdate returns 'uid=602(l10nupdate) gid=602(l10nupdate) groups=602(l10nupdate)' on the deployment-scap.eqiad.wmflabs instance and grep l10nupdate /etc/passwd returns no matches.

I filed the bug because I got this notice when trying to apply puppet:

err: /Stage[main]/Groups::L10nupdate/Group[l10nupdate]/gid: change from 602 to 10002 failed: Could not set gid on group[l10nupdate]: Execution of '/usr/sbin/groupmod -g 10002 l10nupdate' returned 10: groupmod: group 'l10nupdate' does not exist in /etc/group

Ok so it turns out that the root problem is that groups::l10nupdate in admins.pp defines the gid for l10nupdate as 10002 rather than the 602 that is in labs ldap. I'll work around the issue by making the gid realm specific.

A probably better solution is not not use the gid but the group name; this has the virtue of not caring what the gid is. :-)

(Specifically in your case, don't attempt to create the group at all since it already exists; this attempts to renumber a local group that does not exist)

Change 118071 had a related patch set uploaded by coren:
beta: skip l10nupdate user/group creation

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

Change 118071 merged by coren:
beta: skip l10nupdate user/group creation

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

I did create a l10nupdate user using the wikitech interface and Coren tweaked it is uid/gid:

$ ldaplist -l passwd l10nupdate

dn: uid=l10nupdate,ou=people,dc=wikimedia,dc=org
uid: l10nupdate
objectClass: person
objectClass: organizationalPerson
objectClass: inetorgperson
objectClass: ldappublickey
objectClass: shadowaccount
objectClass: posixaccount
objectClass: top
loginShell: /usr/local/bin/sillyshell
uidNumber: 602
gidNumber: 602
sn: L10nupdate
homeDirectory: /home/l10nupdate
mail: hashar@free.fr
cn: L10nupdate

Aka GID/UID set to 602.

The email is mine, we would need a generic email somehow.

Fixed up by Coren, the account no more have any user email :-]