Confirmed users
3,990
edits
ReleaseEngineering/How To/Set Up a Freshly Imaged Slave: Difference between revisions
Jump to navigation
Jump to search
ReleaseEngineering/How To/Set Up a Freshly Imaged Slave (view source)
Revision as of 19:29, 24 September 2013
, 24 September 2013no edit summary
(hostname comes correctly from IT now) |
No edit summary |
||
| Line 5: | Line 5: | ||
If your machine has simply been re-imaged follow the instructions from the appropriate section. | If your machine has simply been re-imaged follow the instructions from the appropriate section. | ||
= Linux/Mac = | = Linux & MacOS X (puppet again) = | ||
== hostname verification == | {{note|For PuppetAgain slaves (e.g. HP Slaves) you should not need to do anything special for it to puppetize after a reimage. Just make sure that ~root/puppetize.log is from somepoint after it was imaged and the last lines in it do not show errors.<br> | ||
=== Linux === | See [[ReleaseEngineering/PuppetAgain/Puppetization_Process|PuppetAgain Process Docs]] for the gritty details on why this is true.}} | ||
= Windows 2008 rev2 = | |||
Coming soon. | |||
= Windows XP (managed) = | |||
No additional steps needed. Simply add to slavealloc | |||
= Windows 7 (managed) = | |||
No additional steps needed. Simply add to slavealloc | |||
= Windows 8 (managed) = | |||
No additional steps needed. Simply add to slavealloc | |||
= Slavealloc notes and settings keys = | |||
# Install the correct set of secrets on the machine. These include: | |||
#* [[ReleaseEngineering/How_To/Adjust_SSH_keys_on_a_slave|Update the ssh keys]] to the correct values for the destination pool | |||
#* if you're troubleshooting a recently returned slave, you may want to also reverse engineer [https://intranet.mozilla.org/RelEngWiki/index.php/How_To/Clean_A_Slave_For_Shipment_Externally How To/Clean A Slave For Shipment Externally] | |||
# Change the slave's fields, eg production (non-try): | |||
#* Trust: core | |||
#* Environ: prod | |||
#* Pool: build-scl1 (or whatever is appropriate) | |||
# reboot it. | |||
= Being deprecated = | |||
== Windows 2008 64-bit (MDT & unmanaged)== | |||
These machines are set up almost all the way with Group policy and only this is required to be setup after re-imaging: | |||
* follow the [[ReferencePlatforms/Win64#Post-reimaging_steps|post reimaging]] steps. | |||
== Windows 2003 (soon to be obsoleted) == | |||
=== Activation === | |||
Nothing to be done but keeping track of it. | |||
Windows 2003 already comes pre-activated. You can check with: | |||
oobe/msoobe /a | |||
=== Hostname === | |||
* change the hostname by following the steps on [[ReleaseEngineering/Set_Up_a_Freshly_Imaged_Slave#How_to_fix_the_hostname_for_Windows|How to fix the hostname for Windows]]. | |||
=== OPSI === | |||
* No action required | |||
The entry of your slave on OPSI has been created from a template which has a package called "passwordupdate". That package is set to run "always" which ensures that the snapshot could have an older password and be updated immediately to the current ones. | |||
== Windows XP (OPSI partially)== | |||
=== tasklist === | |||
Make sure that you can run the command tasklist. | |||
If you can't, ask IT to re-image again. | |||
This issue is documented in their imaging instructions: | |||
https://mana.mozilla.org/wiki/pages/viewpage.action?pageId=28575847 | |||
=== Hostname === | |||
* change the hostname by following the steps on [[ReleaseEngineering/How_To/Set_Up_a_Freshly_Imaged_Slave#How_to_fix_the_hostname_for_Windows]]. | |||
If you don't add the DNS change for Windows slaves using OPSI you will most likely get a [[ReleaseEngineering/OPSI#Mit_Netzlaufwerken_verbinden.2C_bitte_noch_etwas_warten|Mit_Netzlaufwerken_verbinden]] error before the machine logs in. | |||
=== OPSI === | |||
* No action required | |||
The entry of your slave on OPSI has been created from a template which has a package called "passwordupdate". That package is set to run "always" which ensures that the snapshot could have an older password and be updated immediately to the current ones. | |||
== Windows 7 (unmanaged) == | |||
The [[ReferencePlatforms/Test/Win7|test reference platform]] is fairly complete. | |||
=== Activation === | |||
Win7 will need to be activated. IT should have done this, but check by going to Control Panel -> System -> Activate Windows - a failure to activate will burn builds later. | |||
If it is not activated asked IT to do so. | |||
=== Hostname === | |||
* change the hostname by following the steps on [[ReleaseEngineering/Set_Up_a_Freshly_Imaged_Slave#How_to_fix_the_hostname_for_Windows]]. | |||
== Linux/Mac (old puppet) == | |||
=== hostname verification === | |||
==== Linux ==== | |||
Verify the hostname, checking that it ends in 'build.(datacenter).mozilla.com': | Verify the hostname, checking that it ends in 'build.(datacenter).mozilla.com': | ||
hostname --fqdn | hostname --fqdn | ||
| Line 17: | Line 88: | ||
* reboot before running puppet | * reboot before running puppet | ||
=== Mac === | ==== Mac ==== | ||
Verify the hostname, checking that it ends in 'build.(datacenter).mozilla.com': | Verify the hostname, checking that it ends in 'build.(datacenter).mozilla.com': | ||
hostname | hostname | ||
| Line 34: | Line 105: | ||
* '''cmd-K vnc://...''' on mac finder | * '''cmd-K vnc://...''' on mac finder | ||
== puppet == | === puppet === | ||
Note that initial setup of puppet on slaves is very different than from buildbot masters. On slaves, the daemon is not run, rather updates are polled for when it won't impact jobs. Do not enable the standard puppet service daemon on slaves. | Note that initial setup of puppet on slaves is very different than from buildbot masters. On slaves, the daemon is not run, rather updates are polled for when it won't impact jobs. Do not enable the standard puppet service daemon on slaves. | ||
| Line 87: | Line 155: | ||
** once puppet hits the right master, it will both blow away the certificates (even though they were correct) and reboot. So you'll need to wait for a restart, log in, and go through the above process again. Hopefully you'll only need to do this once. | ** once puppet hits the right master, it will both blow away the certificates (even though they were correct) and reboot. So you'll need to wait for a restart, log in, and go through the above process again. Hopefully you'll only need to do this once. | ||
* once puppet is done eviscerating itself, have a look at the slave's twistd.log. If it's getting an UnauthorizedLogin for connection to the staging master, fix the password or add the slave to the master's config. Otherwise, watch the staging master until the slave finishes a job. | * once puppet is done eviscerating itself, have a look at the slave's twistd.log. If it's getting an UnauthorizedLogin for connection to the staging master, fix the password or add the slave to the master's config. Otherwise, watch the staging master until the slave finishes a job. | ||
= How to fix the hostname for Windows = | |||
== How to fix the hostname for Windows == | |||
Instead of replicating the information. Here are the instructions for all of our Windows platforms. | Instead of replicating the information. Here are the instructions for all of our Windows platforms. | ||
| Line 96: | Line 165: | ||
Windows slaves will come back from a re-image with "talos-r3-xp-ref" or "talos-r3-w7-ref" as the hostname. | Windows slaves will come back from a re-image with "talos-r3-xp-ref" or "talos-r3-w7-ref" as the hostname. | ||