Closed
Bug 618109
Opened 15 years ago
Closed 14 years ago
[tracking bug] point to internal tools from http://build.mozilla.org
Categories
(Release Engineering :: General, defect)
Release Engineering
General
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: dustin, Assigned: dustin)
Details
We have a number of private web services, and are building more (slave allocator).
Catlee mentioned in bug 614629 that we need a place to host such things *within* the build network. Cruncher is sorta serving this purpose right now, but it's not a good place for it.
I'm thinking of
http://webservices.build.mozilla.org
and also hosting potentially hefty services at vhosts to make it easier to move them if the need arises, e.g.,
http://stackwalker.build.mozilla.org
(realizing this service is dead - just an example)
Assignee | ||
Updated•15 years ago
|
Assignee: nobody → dustin
Assignee | ||
Comment 1•15 years ago
|
||
I'd like to get some feedback on this before I go asking for subdomains from server ops, etc.
Summary: dedicated build-internal web-services system → [tracking bug] dedicated build-internal web-services system
Comment 2•15 years ago
|
||
What was wrong with bug 617129 that a new bug is needed, or if this is a tracking bug then the conversation shouldn't happen, IMO, in this bug but the other
Also, you are asking for decisions when we, at least from what I can see, we haven't hashed out internally all of the items
Once we know internally what the starting services are, what systems they are based on and what the breakdown is between internal/external then I think we can go to IT with a single set of requests
Assignee | ||
Comment 3•15 years ago
|
||
Bug 617129 is about an external server. This one is about an internal system. The two will have very different requirements in terms of accessibility to us, infrasec, etc.
I'm asking to hash things out, then for decisions. I only mentioned server ops, etc., because someone suggested I request the subdomain and that seemed premature.
So you can think of this as "find a beefier replacement for cruncher" if you'd like.
Assignee | ||
Comment 4•14 years ago
|
||
I'm going to re-purpose this to list the build-internal tools on build.mozilla.org, with appropriate annotations so outsiders are not surprised they can't access them. Maybe that means a separate "internal.html"?
Summary: [tracking bug] dedicated build-internal web-services system → [tracking bug] point to internal tools from http://build.mozilla.org
Comment 5•14 years ago
|
||
The security part of me wants to say "no" to this - anything that is a link to a web interface to an internal system may not be protected because of the buildvpn assumption.
Having link to private services on a web page that is public viewable is an "H4cK M3 M04R" sign just inviting trouble.
Assignee | ||
Comment 6•14 years ago
|
||
We could condition displaying the links on the source IP. I'm not much for security by obscurity, especially in an open environment like ours.
Comment 7•14 years ago
|
||
Please don't make any more public urls on build.m.o until it's renamed.
See bug 604688.
Assignee | ||
Comment 8•14 years ago
|
||
Oops, sorry, this bug is for *internal* services, which should also be renamed. Bug 614629 is for external interfaces. Let's concentrate there for now, since self-serve and BuildAPI are the topics du jour.
No longer depends on: 604688
Assignee | ||
Comment 9•14 years ago
|
||
So we've been solving this by adding a VM for each service, e.g., slavealloc. This will probably apply to external services, too, and we'll just proxy them via build.mozilla.org.
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Updated•12 years ago
|
Product: mozilla.org → Release Engineering
You need to log in
before you can comment on or make changes to this bug.
Description
•