Wikimedia Bugzilla is closed!

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 :-]