ReleaseEngineering/How To/Set Up a Freshly Imaged Slave

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, these hardware slaves need to have httpd restarted to pick-up the contents of talos.conf until bug 1141416 is fixed:

 # root@talos-linux64-ix-001
 service apache2 restart

You can also just reboot the machine one extra time before returning it to service as this accomplishes the same thing.

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
  • No additional steps needed. Simply enable on slavealloc