Closed Bug 1033672 Opened 10 years ago Closed 10 years ago

Allow developers to access Android emulator AVDs

Categories

(Release Engineering :: General, defect)

x86_64
Linux
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: gbrown, Unassigned)

References

Details

Several developers want to re-create our production Android 2.3 emulator environment on their local computers. To do that, they need to get AVDs-armv7a-gingerbread-build-2014-01-23-ubuntu.tar.gz, which is available from https://secure.pub.build.mozilla.org/tooltool/pvt/build -- but most developers don't have access to that.

(As I recall, our last discussion about this issue resulted in bug 1019011 and https://wiki.mozilla.org/ReleaseEngineering/Applications/Tooltool#Need_to_download_files_from_it.3F, but now I think there is a larger, harder-to-define, and probably changing-over-time group of people interested in access.)

Can we make AVDs-armv7a-gingerbread-build-2014-01-23-ubuntu.tar.gz public, or otherwise reduce its access restrictions such that most developers can access it easily? If not, let's identify why not.
See Also: → 1003927
dustin, can we please widen the LDAP restrictions to every employee?

AFAIK we got no secrets there (secrets are on puppet). At most, some non-redistributable files.
Flags: needinfo?(dustin)
I'm in no position to determine whether that's OK from a licensing standpoint, but it does seem like it reinforces segregation between developers who work for moco (get access) and developers who don't (no access).

If you give the assurances that it's OK, and the least-bad solution with respect to segregating developers, then sure -- I can do that.
There's no problem with licensing. As long as it is not public we're OK.

Let's please start with MoCo and if Non-MoCo need access in the future we can ask them to request access or someone to retrieve it for them.
Flags: needinfo?(dustin)
OK - I need to figure out which group or LDAP filter to use, which could take a bit of digging.
:digi, the suggested AuthLDAPURL didn't work (rejected my login).

This is for a sub-URL of a site with a different, broader AuthLDAPURL.  So one possibility is that overriding AuthLDAPURL for a subdirectory like this doesn't work (which would be sad).

Any other suggestions?
Flags: needinfo?(bhourigan)
The code I provided was an example that's in use elsewhere.. I'd look at a service that does what you want and adapt their mod_auth_ldap configs to your specific situation.
Flags: needinfo?(bhourigan)
Ah, I figured it out -- specifying AuthLDAPURL again in a <Location> block requires also re-specifying the bind username/password.

Should be working now!
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.