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)
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
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
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.
No longer depends on: 629477
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
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.
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.
Please don't make any more public urls on build.m.o until it's renamed. See bug 604688.
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
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
Last Resolved: 8 years ago
Resolution: --- → FIXED
Product: mozilla.org → Release Engineering
You need to log in before you can comment on or make changes to this bug.