Closed Bug 1193774 Opened 9 years ago Closed 9 years ago

reimage mac-signing[23].srv.releng.scl3.mozilla.com as mac-v2-signing[67].srv.releng.scl3.mozilla.com

Categories

(Infrastructure & Operations :: RelOps: General, task)

task
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: bhearsum, Assigned: arich)

References

Details

esr31 is finally dead, so we can get rid of the v1 signing servers and use them as additional v2 ones.

The existing ones run 10.9.5, but Amy would like to try 10.10 on the new ones. Let's do that with just one of them first and see how it goes. If they don't work out of box, we'll have to bail and go with 10.9.5.
Should also note that it's important they keep the same IPs (for netflows reasons) and nagios checks.
We sent 5 to TOR for DR, so I'll name these 6 and 7.
Assignee: relops → arich
Summary: reimage mac-signing[23].srv.releng.scl3.mozilla.com as mac-v2-signing[56].srv.releng.scl3.mozilla.com → reimage mac-signing[23].srv.releng.scl3.mozilla.com as mac-v2-signing[67].srv.releng.scl3.mozilla.com
nagios changes in svn revision 106988.
Depends on: 1193794
This turned out to be a bit more complicated because the hosts were on a VLAN that DS doesn't work on. I had dcops move them to VLAN 252 (build) so I could use install.build.releng.scl3.mozilla.com to install them (I also had to copy over the yosemite workflow and make a change to only format one disk, and I needed to copy over the Yosemite images and the Puppet puppet and facter packages). Unfortunately they lost link, so they had to physically go to the datacenter to netboot them. Because of that, I had them do both at once instead of just one.

Once the machines were installed (and after the reboot where the final DS scripts ran), I logged in using the kickstart password and killed the puppetize script.

Dcops then moved them back to the correct VLAN and power cycled them, but they had information left over for the prior network settings. We generally handle this in DS with a post-script, but I had to log into the machines from another host on the local network (the puppet servers) and clean out those files by hand (they're defined in /Deploy/Scripts/remove_systemconfig_plist.sh on the DS servers).

Once I did that and rebooted, the machines came up with the proper network config and I was able to puppetize them.

Hopefully we'll find that yosemite works just fine for the signing servers, since this will be painful to do again (since it needed onsite assistance).
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
If anyone else wants to do some testing, I've published an installer that's SHA-1 signed which contains a SHA-2 signed Firefox, and will update to a newer SHA-2 signed build. My testing was done as follows:
On XP SP2 (64-bit) machine:
1) Downloaded http://people.mozilla.org/~bhearsum/sha1/firefox-43.0a1.en-US.win32.installer.sha1.exe
2) Checked signature, looked fine: http://people.mozilla.org/~bhearsum/sattap/25ff42e9.png
3) Ran installer, got the usual "Security Warning" dialog: http://people.mozilla.org/~bhearsum/sattap/e9b01e46.png
4) Clicked through installer, taking all of defaults except for launching Firefox immediately
5) Browsed to installation location and checked signature of firefox.exe, which was invalid because of sha2: http://people.mozilla.org/~bhearsum/sattap/220f7cec.png
6) Launched Firefox with Desktop icon. No extra warnings or dialogs were shown.
7) Set app.update.log to true, opened Browser Console, and checked for updates
8) Update was successfully found and applied in the background: http://people.mozilla.org/~bhearsum/sattap/62083312.png
9) Restarted for update without issue
(In reply to Ben Hearsum (:bhearsum) from comment #5)
> If anyone else wants to do some testing, I've published an installer that's
> SHA-1 signed which contains a SHA-2 signed Firefox, and will update to a
> newer SHA-2 signed build. My testing was done as follows:
> On XP SP2 (64-bit) machine:
> 1) Downloaded
> http://people.mozilla.org/~bhearsum/sha1/firefox-43.0a1.en-US.win32.
> installer.sha1.exe
> 2) Checked signature, looked fine:
> http://people.mozilla.org/~bhearsum/sattap/25ff42e9.png
> 3) Ran installer, got the usual "Security Warning" dialog:
> http://people.mozilla.org/~bhearsum/sattap/e9b01e46.png
> 4) Clicked through installer, taking all of defaults except for launching
> Firefox immediately
> 5) Browsed to installation location and checked signature of firefox.exe,
> which was invalid because of sha2:
> http://people.mozilla.org/~bhearsum/sattap/220f7cec.png
> 6) Launched Firefox with Desktop icon. No extra warnings or dialogs were
> shown.
> 7) Set app.update.log to true, opened Browser Console, and checked for
> updates
> 8) Update was successfully found and applied in the background:
> http://people.mozilla.org/~bhearsum/sattap/62083312.png
> 9) Restarted for update without issue

This was meant for a different, not related to this at all...
You need to log in before you can comment on or make changes to this bug.