Transitioning RelEng Status¶
From time to time, folks move in and out of the Release Engineering role. As they do so, access to various systems should be granted and removed * .
When someone moves into the organization, permissions should be granted as needed to perform the various tasks. While permissions are granted only as needed, there are also minimum requirements for the permissions. For example, some permissions may only be available to someone who is both a member of the RelEng team and an employee.
The table below lists all the permissions, and which requirements are required to have that permission. When a person no longer has a specific status, all permissions which require that status need to be check and revoked. (Refer to the day one page for details on permissions.) Legend:
access to releng password files 1
#mozbuild password 2
releng etherpad account 3
cltbld & root slave farm password
releng puppet masters
AWS console access
releng LDAP bits (IT bug) releng, vpn_releng, RelengWiki, & SysAdminWiki
unassign any resources in slavealloc
RelEng machine access e.g. puppet, scriptworkers, etc. 4
github ownership roles 6
hg.mozilla.org special access 5
github write access (review)
releng/build bugzilla group access 7
Google Drive RelEng folder access
Release google calendar
Release google group
Release Trello group
other Google Drive documents 8
named contact in Nagios escalation chain
Allowed to merge to puppet production 3
Almost all passwords are now shared via gpg encrypted files. To get a list of passwords shared with a user, use the “
scripts/who_knows_what” script to identify passwords that should be changed. Also, add the departing user’s id to the “
access to the repo requires both membership in both the
vpn_releng) and either (
To change the password on an IRC channel where you have ops permissions:
Make sure user is not in #mozbuild, a kick or ban is sometimes necessary (due to auto-reconnect)
/msg chanserv set #mozbuild mlock +k newpass
Bouncer: change via bounceradmin.m.c
Balrog: go to permissions from https://aus4-admin.mozilla.org/rules.html
Treestatus: from users page.
Puppet Merge: commit update to hook <https://hg.mozilla.org/hgcustom/version-control-tools> and request deploy.
In addition to password changes governing access to compute resources, a scan of systems must be made to ensure no processes or cron jobs have been left running.
These are systems where the user is granted access via their ssh key, either to their user specific account, or to a shared account (such as
cltbld). However, these systems have keys deployed via the RelEng puppet servers, which only sync with MoCo ldap via a cron job.
These systems are unique, so you may need to refer to other documentation for instructions.
There are some hand maintained white lists for push permissions to certain branches. (E.g. puppet production) Changes need to be approved by a RelEng/RelOps manager.
For now, the accounts to check are mozilla & mozilla-b2g. Note that we’re only discussing the ownership role here on RelEng owned resources. If the person has ownership rights to repositories due to their contributor status, that does not change.
This bugzilla group can cause some confusion for folks transitioning out of MoCo but remaining a RelEng contributor. Perform on the admin page.
To find documents where exceptional access has been granted, use the script at http://labnol.org/?p=28237
Unlike most of Mozilla development, some Release Engineering roles are only available to employees for various legal or contractual reasons. That leads to layers of access:
Folks directly performing tasks which require knowledge of how Release Engineering systems work and interact.
- MoCo Emp:
Folks who have a contractual arrangement with Mozilla that may be required for access to certain restricted systems and data.
Folks who have valid committer’s agreement on file.