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:
RE Emp CM Permission password changes: X access to releng password files  X X #mozbuild password  X bouncer  X balrog  X treestatus  X releng etherpad account  X cltbld & root slave farm password X releng puppet masters compute resources X X X AWS console access X X releng LDAP bits (IT bug) releng, vpn_releng, RelengWiki, & SysAdminWiki X unassign any resources in slavealloc X RelEng machine access e.g. cruncher, stage, buildbot masters, etc.  miscellaneous systems X X github ownership roles  X hg.mozilla.org special access  X X X github write access (review) X releng/build bugzilla group access  X X Google Drive RelEng folder access X X Release google calendar X X Release google group X X Release Trello group X other Google Drive documents  X re-assign bugs X named contact in Nagios escalation chain X Allowed to merge to puppet production 
Almost all passwords are now shared via gpg encrypted files. To get a
list of passwords shared with a user, use the
access to the repo requires both membership in both the
To change the password on an IRC channel where you have ops permissions:
|||(1, 2, 3, 4, 5) |
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 |
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: