[
https://issues.apache.org/jira/browse/MESOS-2856?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16814147#comment-16814147
]
shashank commented on MESOS-2856:
---------------------------------
Any Update after this ?? i am facing the same issue
> fully functional webui requires all masters+slaves to be routable by browser
> ----------------------------------------------------------------------------
>
> Key: MESOS-2856
> URL: https://issues.apache.org/jira/browse/MESOS-2856
> Project: Mesos
> Issue Type: Bug
> Reporter: Oliver Nicholas
> Assignee: Oliver Nicholas
> Priority: Major
>
> The core issue is that the Mesos web UI doesn't play well behind a proxy.
> This is closely related to MESOS-1822, but I propose a different mechanism to
> resolve it.
> The mesos webui expects that it can both:
> # redirect your browser to the {{--hostname}} registered for another master
> if the master you're currently hitting isn't the leader (this is MESOS-1822)
> # redirect you directly to the {{--hostname}} of any slave (eg/ to look at
> sandbox logs)
> But I don't want that to be possible really - fundamentally, mesos-master's
> webui is not appropriate for direct exposure to the Internet; in many
> enterprise cases it's not appropriate for wide exposure on a VPN either. It
> has no access controls. And those machines shouldn't really have public IPs
> or DNS entries anyway.
> The way I want to resolve this for my enterprise is to have a _single_
> hostname (as in URL component, not literally unix host), with public DNS that
> can handle the entire webui experience (aside: the vhost this hits has a
> authentication middleware to handle the access control part). In my case,
> the vhost is load balanced randomly across the mesos master quorum machines,
> and some slightly complex nginx rules allow it to effectively proxy any
> request to the actual leader master regardless of where the request goes.
> This works nicely.
> However, the mesos webui also attempts to route directly to slave machines
> with JSONP requests (eg/ as i mentioned above, to load the sandbox stdout for
> a task). My slave machines don't even have public IPs.
> Given this existing code for generating the parameters for URLs to slaves:
> {code:javascript}
> var pid = $scope.slaves[$routeParams.slave_id].pid;
> var hostname = $scope.slaves[$routeParams.slave_id].hostname;
> var id = pid.substring(0, pid.indexOf('@'));
> var host = hostname + ":" + pid.substring(pid.lastIndexOf(':') + 1);
> {code}
> I'd like to implement a {{--enable-webui-proxy-urls}} option on the master
> that would change behavior in the webui from generating a slave URL as:
> {code:javascript}
> var url = '//' + host + '/files/browse.json?jsonp=JSON_CALLBACK';
> {code}
> to instead generate the URL as:
> {code:javascript}
> var url = '/proxy?host=' + encodeURIComponent(host) + '&orig='
> encodeURIComponent('/files/browse.json?jsonp=JSON_CALLBACK');
> {code}
> and then nginx can take care of rewriting/reissuing the request and proxying
> the results back to the browser.
> All of this could be obviated and probably made more elegant by implementing
> MESOS-2130/MESOS-2131 but..this seems like a simple change to make. Any
> thoughts?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
