Closed Bug 586874 Opened 14 years ago Closed 13 years ago

Setting up a Mac Dev Environment for remote access

Categories

(Infrastructure & Operations Graveyard :: NetOps, task)

Product:
Infrastructure & Operations Graveyard
Component:
NetOps
Platform:
x86
macOS
Type:
task
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: rags, Assigned: ravi)

Details

On Aug 9, 2010, at 10:11 PM, Ragavan Srinivasan wrote:

> > Hey mrz,
> > 
> > Some of the folks in our l10n community who are helping to localize Firefox Home have neither an iPhone nor a Mac. So, they have no way for test their work.
> > 
> > Can we help them out by setting up a Mac that they can log into, that has the iPhone simulator running so they can test their work?
> > 
> > We can set up one account that they can all share between them.
> > 
> > Thoughts on whether this is doable? Also open to better alternatives.
> > 
> > Thanks,
> > Ragavan


And mrz said:

It's doable but pretty tricky to make sure the host isn't used for something it shouldn't be.

Can you file a bug and we'll track it there?
Would a mac mini or a virtual machine be better for this? Also, how to handle auth and access? I presume using VNC. How many users are we talking about and would they need to log in at the same time, or one at a time?
Assignee: server-ops → jdow
Probably a mac mini. Auth/access via VNC would work just fine.

Number of users: I'd budget for about 30 for now, with room to grow. This is for our l10n community and as we add more locales to Firefox Home, I expect more people to want access.

Ideally, they'd be able to log in at the same time, but again in the interest of time, if it's easier to set it up for one at a time for now and then switch to multiple simultaneous, I'd be fine with that.
More questions - 

1. I suspect after each "run" you'll want to wipe the OS to start from a clean environment again.  That tends to suggest VMs.
(In reply to comment #3)
> More questions - 
> 
> 1. I suspect after each "run" you'll want to wipe the OS to start from a clean
> environment again.  That tends to suggest VMs.

By "run", you mean release? I don't think we'll need to wipe the OS (I don't think we do that now). We'll load different builds into the simulator, but that shouldn't require an OS wipe.

That said, if it's easier to do VMs, that's fine. Can we run OS X desktop edition as a VM these days?
No, only server.  

If you're testing, how do you make sure you're testing in a clean enviro?  

Maybe I'm over thinking it.
(In reply to comment #5)
> No, only server.  
> 
> If you're testing, how do you make sure you're testing in a clean enviro?  
> 
> Maybe I'm over thinking it.

Once we set up the machine, we don't change the OS or install any additional libraries and I'd think that stuff that runs in the simulator is sufficiently sandboxed and doesn't affect system libs etc.

That said, I'm cc:ing Dan in case he has other thoughts.
Ideally, they'd only have access to the simulator.  That would prevent most imagined abuses.  But I don't know how to do that.  Otherwise they need access to the whole machine, which raises lots of security concerns, even if it's outside our firewall.
chris - any ideas how to best do this?
From a logistics standpoint, I'm not sure what the best way to achieve this is. Obviously VNC access would be quick and easy, but limited to one concurrent user. I'm currently not sure whether OS X Server edition has concurrent terminal sessions available to it or not, which would be a better way of dealing with it.

Are the community people in question all collaborating together? Would it be plausible to have one person accessing a box with the iPhone simulator and the rest of the community could submit their changes to be tested?
(In reply to comment #9)
> 
> Are the community people in question all collaborating together? Would it be
> plausible to have one person accessing a box with the iPhone simulator and the
> rest of the community could submit their changes to be tested?

That won't work - we have different locales and languages that individual communities will need to test separately.
(In reply to comment #7)
> Ideally, they'd only have access to the simulator.  That would prevent most
> imagined abuses.  But I don't know how to do that.  Otherwise they need access
> to the whole machine, which raises lots of security concerns, even if it's
> outside our firewall.

I don't see why they would need anything other than the simulator preloaded with a build that you put on it.
Just talked to sethb. All of the people that need access to this machine already have ldap accounts. Is there pam_ldap or something like it that we can turn on for their access?
jdow - get a mini on order.  We'll put this on the community-build network and try to do LDAP based screen sharing auth.  Each user will have parental controls turned on such that the only app they can run is the emulator.

Okay to ship quick.
Mini is in my hands. I'm installing Xcode and iPhone SDK. What should hostname be, and where should it live (which network) ?
We talked about this IRL.  community-build.
I need a list of all applications that should be allowed to run by these users. Currently I have Xcode in the list. What else is needed to successfully run the iPhone simulator. Also, how will the people be getting their code onto the machine?
Jlazaro is going to take this to the colo today. We should be able to finish up any further configuration from there.
Assignee: jdow → jlazaro
No, we specifically do _not_ want them to be able to run XCode, only the emulator.
I will need XCode to be on the machine, but only I need access to it.
So, I need a separate non-restricted account for dwalkowski? What is the path to the iPhone emulator?
For a standard install, it's here:

/Developer/Platforms/iPhoneSimulator.platform/Developer/Applications/iPhone Simulator

(All of XCode is in /Developer)

I need XCode because it's the only way I know to install new binaries into the emulator.
For the network configuration:

l10n-fxhome.community (.sj.mozilla.com)

address: 63.245.210.51
gateway: 63.245.210.1
netmask: 255.255.255.192

vlan: 20
Box is online at MPT.

Still need to fine tune the parental controls and set it up in DNS. Shooting for late tonight or tomorrow morning for that.
(In reply to comment #22)
> Box is online at MPT.
> 
> Still need to fine tune the parental controls and set it up in DNS. Shooting
> for late tonight or tomorrow morning for that.

Awesome. cc:ing Sethb

Seth - this is the machine that the l10n community can use to test. Once it's ready, can we get them to test over the weekend? I'd like to get any final tweaks needed in on Monday (Aug 23rd) so we can ship on Tuesday. Is that doable?
Dan Walkowski just gave me a set of strings today that need localization.  I'll file those to get people working, but it depends a bit on how fast those new strings get translated in the 15 locales.
Assignee: jlazaro → jdow
I handed this off to dwalkowski to get the iPhone Simulator working as needed.
The iPhone Simulator, to work properly, needs to be run by an admin account. Currently the idea is to run it under the fxhome user account, which is an admin account, but the password will NOT be given out to any community members. Instead the account will be set to auto-login and they will get a different password to use for the VNC connection and all the settings in System Preferences will have the lock locked such that a password is required to make any changes to the box. (sudo would also require a password).

This machine is located in the community build network, which is behind some switch ACLs which only allow access through an internal jump host (ldap account required).

We need infrasec to sign off on this, so punting to clyon.
Assignee: jdow → clyon
(In reply to comment #26)
> The iPhone Simulator, to work properly, needs to be run by an admin account.
> Currently the idea is to run it under the fxhome user account, which is an
> admin account, but the password will NOT be given out to any community members.
> Instead the account will be set to auto-login and they will get a different
> password to use for the VNC connection and all the settings in System
> Preferences will have the lock locked such that a password is required to make
> any changes to the box. (sudo would also require a password).
> 
> This machine is located in the community build network, which is behind some
> switch ACLs which only allow access through an internal jump host (ldap account
> required).
> 
> We need infrasec to sign off on this, so punting to clyon.

Also, we really need this box over the weekend and perhaps for a day or two next week. We can wipe the box clean and/or look into other longer term options once we ship Firefox Home 1.0.2.
I need simple to understand instructions on how localizers can use this environment to test.  So far, I have this:

1)  Localizers access the machine by visiting l10n-fxhome.community.sj.mozilla.com
2)  Account will be set to auto-login 
3)  Localizers receive a different password to use for the VNC connection (with all the settings in System locked such that a password is required to make
any changes to the box)

Then what?

4)  Localizer uses the unique password to log into VNC
5)  Localizer launches emulator (Will there be an icon in the dock?)
6)  Localizer initiates proper OS language on emulator
7)  Launches FxHome and tests

Do 4-7 seem correct?
Adding dmoore to CC. I think there is an extra trick to be able to reach the machine directly from the internet.

I believe 4-7 are correct.
The localizers will only be using VNC for remote access, correct?
I've set the machine to auto-login to the fxhome account, and auto-launch the iPhone Simulator.  It's running now, so if we can test that people can get into our network (a 'jumphost'?) and then vnc into the machine, then we are ready to go.
(In reply to comment #31)
> I've set the machine to auto-login to the fxhome account, and auto-launch the
> iPhone Simulator.  It's running now, so if we can test that people can get into
> our network (a 'jumphost'?) and then vnc into the machine, then we are ready to
> go.

Does that mean I should pass the URL from comment 28 to a localizer to test run this?
For this short-term duration, VNC is now directly accessible. No need for localizers to use the jumphost.
Hostname correction: l10n-fxhome.community.mozilla.com
It would be really great if someone could test it now, before we all go home for the weekend.  I mean from outside our network.
I can't test it for real, but I can reach the vnc port on that server from outside the infrastructure, so it looks like it works.
I'll find someone right now.
Seth, additional instructions for testers: 

- Obviously, take turns. :)  If someone else is testing, try back later.
- Try everything, visit every page, and definitely view a web page
- To change the language of the iPhone, tap the 'Settings' icon, then 'General', then 'International', then 'Language'.  Choose your preference from the list.
- Be sure to change the language back to English when you are finished!
I just had a localizer in Belgium test it.  The URL timed out.
What VNC client is he using? It is listening on the default VNC port 5900 (display 0), in case his client isn't using those defaults.
This might be part of the simple to understand and explicit instructions that need to be spelled out.  :P  I don't think I told him any of that.  Can anyone provide some reference docs on how to setup a VNC client.  It's not a guarantee that everyone will have one set up immediately.  It's likely that most will have to install and set it up.
Can only one person at a time connect?  because I was signed in.  I have now disconnected
(In reply to comment #42)
> Can only one person at a time connect?  because I was signed in.  I have now
> disconnected

Time out again, after you disconnected.
Pretty sure multiple connections will work. Would need to be tested though. For VNC, just download realvnc or tightvnc (viewer only), run it and it should just ask for a hostname, enter in the hostname, then comes a password prompt, enter in the password and should be in. Maybe you can translate into lay terms. I'd just google for Tightvnc Viewer.
(In reply to comment #44)
> Pretty sure multiple connections will work. Would need to be tested though. For
> VNC, just download realvnc or tightvnc (viewer only), run it and it should just
> ask for a hostname, enter in the hostname, then comes a password prompt, enter
> in the password and should be in. Maybe you can translate into lay terms. I'd
> just google for Tightvnc Viewer.

This is great, thank you.
I use vnc viewer to connect to remote machines daily, but I can confirm l10n-fxhome.community.sj.mozilla.com times out using :5900 from the outside world.
(In reply to comment #34)
> Hostname correction: l10n-fxhome.community.mozilla.com

Try that one. (without the .sj.)
Works like a charm.
Also confirmed by a localizer in Chile.  Resolving as fixed for now.
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
One more note, I have updated the tracking bug for Firefox Home so localizers can begin to test.
I'd like to keep this open, so that the Infrasec team can comment on the security of this system and to sign off on a long-term solution for this box, as surely it will need to be used for subsequent releases.

Changing the component to Infrastructure Security.
Status: RESOLVED → REOPENED
Component: Server Operations → Server Operations: Security
QA Contact: mrz → clyon
Resolution: FIXED → ---
Not sure if this came up on irc today or not but I think as a rule of thumb, we don't want to open up vnc to the world given the issues we have seen in the past. Can we look at another option?
Assignee: clyon → infrasec
Component: Server Operations: Security → Infrastructure Security: Server Security
What needs to happen here? 

I think the long term solution would be to have some other method of access for these systems if we are going to open them up. Adding in mrz for comment.
@clyon, would those SSL VPNs help here?  Auth off LDAP, restrict where users can go?
(In reply to comment #54)
> @clyon, would those SSL VPNs help here?  Auth off LDAP, restrict where users
> can go?

yes, SSL VPN here is a perfect fit.
You're blocked on those coming in - ETA a couple weeks but probably in early Jan.  Does that schedule work?
moving back over to IT as this is really on them at this point.

The SSL VPN should resolve this issue and from infrasec, we are good.
Assignee: infrasec → server-ops
Component: Infrastructure Security: Server Security → Server Operations
QA Contact: clyon → mrz
Assignee: server-ops → network-operations
Component: Server Operations → Server Operations: Netops
Assignee: network-operations → nobody
Component: Server Operations: Netops → Operations
Product: mozilla.org → Mozilla Services
QA Contact: mrz → operations
Version: other → unspecified
Okay, to summarize what's left for this bug (and save everyone reading the past 57 comments):


Ravi, there is a server "l10n-fxhome.community.mozilla.com" which is currently exposed directly to the internet (5900/tcp) but would preferably be behind the SSL VPN, so that localizers with limited LDAP access can still VNC to it somehow to do their localizing work.


Any solution that means l10n-fxhome.community.mozilla.com:5900/tcp isn't listening on the public internet anymore (and is still accessible somehow to localizers) would resolve this bug successfully.


Handing off to Ravi per conversation with Netops.
Assignee: nobody → ravi
Status: REOPENED → NEW
Component: Operations → Server Operations: Netops
Product: Mozilla Services → mozilla.org
QA Contact: operations → mrz
Version: unspecified → other
Do we really have to make things more complicated for the testers? Is it not possible to isolate that Mac Mini on the network? Or to install some firewall rules on it so that it can only chat with the few services that it needs for Firefox Home testing?

What are we afraid of?
The issue is the VNC port is exposed to the world and by extension the entire host.  This is setup, as I understand it, so community members can validate some aspect of localization on builds.  By placing it behind a VPN it shifts the attack surface to the SSL VPN, a trusted device.  I question your claim that it will be more complicated when you haven't tried the new method.

Go ahead and give it a try.  Login with your full LDAP credentials to https://vpn.mozilla.com/ and select VNC.  This is a test Build host and right now is only available to MoCo users.

The SSL VPN allows for centralized access via LDAP without having to distribute the actual password of the host to others.  InfoSec made a recommendation in comments 52-55 and quite frankly this is the best balance of security and usability.
Ravi, is this completely web based? I assumed (wrongly?) that people would need to install VPN software.

(I tried to login but I got an error saying that i am not allowed to use the service)
It is 100% web based.  I expanded the group restrictions to accommodate your account.  Give it a go again.
Tried it. It is nice. My only gripe is that is is considerably slower. I'm not able to see any visual effects or drag stuff around smoothly. Not sure if this is a problem for Firefox Home and the iPhone simulator. Let's just try it.
Status: NEW → RESOLVED
Closed: 14 years ago → 13 years ago
Resolution: --- → FIXED
Product: mozilla.org → Infrastructure & Operations
Product: Infrastructure & Operations → Infrastructure & Operations Graveyard
You need to log in before you can comment on or make changes to this bug.