Closed Bug 570020 Opened 14 years ago Closed 14 years ago

Create 2 linux and 2 win32 try builder VMs

Categories

(mozilla.org Graveyard :: Server Operations, task)

x86
All
task
Not set
major

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: lsblakk, Assigned: phong)

References

Details

Attachments

(1 file)

try-linux-slave24.build
try-linux-slave25.build
try-win32-slave30.build
try-win32-slave31.build

Please use the current ref image for each platform, the disk size of the current try slaves (smaller than moz2 production builders) and update Nagios.
Assignee: server-ops → phong
Blocks: 568268
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Seems like a firewall is up between the try-linux-slave{24,25} and production-puppet.build - can you open that up?
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
These are 10.2.91.1/2/3/4, so I bet we need to open up a new subnet for the NFS share, or just wait until Ben is through killing the need for that. No doubt there will be other things that will need firewall rules expanded.
(In reply to comment #2)
> These are 10.2.91.1/2/3/4, so I bet we need to open up a new subnet for the NFS
> share, or just wait until Ben is through killing the need for that. No doubt
> there will be other things that will need firewall rules expanded.

Yeah, we don't need to concern ourselves with NFS -- I'm landing the patch that does away with it this morning. They'll still need to be added to the Puppet file server config, though.
Is this fixed now or do we still need the firewall open for NFS?
Attachment #449606 - Flags: review?(lsblakk) → review+
Don't need NFS anymore, I think the fileserver.conf changes will do it. Need to land them still.
Comment on attachment 449606 [details] [diff] [review]
add new subnet to fileserver configs

changeset:   176:b5533e98ac95
I updated production-puppet for this
I am going to move this to the RelEng queue.
Assignee: phong → lsblakk
Component: Server Operations → Release Engineering
QA Contact: mrz → release
try-linux slaves are connecting to puppet properly now.  closing.
Status: REOPENED → RESOLVED
Closed: 14 years ago14 years ago
Resolution: --- → FIXED
Turns out that the linux machines are slightly different when it comes to firewall / network setup. They should be able to access production-puppet on port 80, which they can't:
[cltbld@try-linux-slave02 ~]$ telnet production-puppet.build.mozilla.org 80
Trying 10.2.71.243...

And their resolv.conf is different than that of an existing slave:
[cltbld@try-linux-slave02 ~]$ cat /etc/resolv.conf
; generated by /sbin/dhclient-script
search mozilla.org
nameserver 10.2.74.127
nameserver 10.2.74.125

[cltbld@try-linux-slave06 ~]$ cat /etc/resolv.conf
; generated by /sbin/dhclient-script
search build.mozilla.org
nameserver 10.2.74.125
nameserver 10.2.74.127


Can you please fix those, and double check that the Windows machines are set-up properly?
Assignee: lsblakk → server-ops
Status: RESOLVED → REOPENED
Component: Release Engineering → Server Operations
QA Contact: release → mrz
Resolution: FIXED → ---
Over to Phong for the stuff in Comment #11
Assignee: server-ops → phong
Severity: critical → major
try-linux-slave02 is still on vlan76 and try-linux-slave06.build was moved over to the build network.  That is to be expected.  I was asked to keep that one in the sandbox network.

comment # of bug 567147
Status: REOPENED → RESOLVED
Closed: 14 years ago14 years ago
Resolution: --- → FIXED
Product: mozilla.org → mozilla.org Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: