ReleaseEngineering/How To/Set Up a Freshly Imaged Slave: Difference between revisions
ChrisCooper (talk | contribs) |
No edit summary |
||
| Line 11: | Line 11: | ||
These are installed from golden AMIs created every night. There should be nothing for you to do here. | These are installed from golden AMIs created every night. There should be nothing for you to do here. | ||
== Linux Talos slaves == | == Linux Talos slaves == | ||
After puppet is run, | After puppet is run, nothing else is needed.The machine can be returned back to service by simply enable in slavealloc. | ||
You should check to make sure that ~root/puppetize.log's modified time is after the re-image time. | |||
== Mac test slaves == | == Mac test slaves == | ||
Puppet does everything. You should check to make sure that ~root/puppetize.log's modified time is after the re-image time. | Puppet does everything. You should check to make sure that ~root/puppetize.log's modified time is after the re-image time. | ||
= Windows (GPO) = | = Windows (GPO) = | ||
| Line 25: | Line 24: | ||
* '''staging machines are not setup via GPO.''' they either will have no keys or they will be given prod keys. Either way, you need to cp keys from another staging slave to the freshly imaged one via [https://wiki.mozilla.org/ReleaseEngineering/How_To/Adjust_SSH_keys_on_a_slave#Staging setup staging ssh keys] | * '''staging machines are not setup via GPO.''' they either will have no keys or they will be given prod keys. Either way, you need to cp keys from another staging slave to the freshly imaged one via [https://wiki.mozilla.org/ReleaseEngineering/How_To/Adjust_SSH_keys_on_a_slave#Staging setup staging ssh keys] | ||
== Test slaves == | == Test slaves == | ||
* Host names: t-xp32-ix, t-w732-ix, t-w864-ix | * Host names: t-xp32-ix, t-w732-ix, t-w864-ix, t-w1064-ix | ||
* No additional steps needed. Simply enable on slavealloc | * No additional steps needed. Simply enable on slavealloc | ||
Revision as of 12:48, 21 November 2017
If the machine is a re-purposed machine there are more steps that these needed. Check How to create new slaves or move them to other pools.
If your machine has simply been re-imaged follow the instructions from the appropriate section.
Linux/MacOS X (PuppetAgain)
Build/Try slaves
Puppet does everything. You should check to make sure that ~root/puppetize.log's modified time is after the re-image time.
Linux AWS slaves
These are installed from golden AMIs created every night. There should be nothing for you to do here.
Linux Talos slaves
After puppet is run, nothing else is needed.The machine can be returned back to service by simply enable in slavealloc. You should check to make sure that ~root/puppetize.log's modified time is after the re-image time.
Mac test slaves
Puppet does everything. You should check to make sure that ~root/puppetize.log's modified time is after the re-image time.
Windows (GPO)
Build/Try slaves
- Host names: w64-ix-* or b-2008-ix-*
- try/build(prod) machines now have their ssh keys copied via GPO. Simply enable in slavealloc.
- It is worth verifying that the keys are set up correctly as this is relatively new (july 15, 2014)
- staging machines are not setup via GPO. they either will have no keys or they will be given prod keys. Either way, you need to cp keys from another staging slave to the freshly imaged one via setup staging ssh keys
Test slaves
- Host names: t-xp32-ix, t-w732-ix, t-w864-ix, t-w1064-ix
- No additional steps needed. Simply enable on slavealloc