<div dir="ltr">Agree.</div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Sep 20, 2017 at 7:04 AM, Kenneth Wilke <span dir="ltr"><<a href="mailto:kenneth.wilke@rackspace.com" target="_blank">kenneth.wilke@rackspace.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>
<div id="m_-828739750837930923divtagdefaultwrapper" style="font-size:12pt;color:#000000;font-family:Calibri,Helvetica,sans-serif" dir="ltr">
<p>It is a pretty common practice to terminate SSL at a reverse proxy like NGINX. I think this model of routing http to the other daemons listening on localhost sockets should work well for OpenBMC.</p>
<p><br>
</p>
<p>Kenneth<br>
</p>
</div>
<hr style="display:inline-block;width:98%">
<div id="m_-828739750837930923divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" style="font-size:11pt" color="#000000"><b>From:</b> openbmc <openbmc-bounces+kenneth.<wbr>wilke=<a href="mailto:rackspace.com@lists.ozlabs.org" target="_blank">rackspace.com@lists.<wbr>ozlabs.org</a>> on behalf of Chris Austen <<a href="mailto:austenc@us.ibm.com" target="_blank">austenc@us.ibm.com</a>><br>
<b>Sent:</b> Tuesday, September 19, 2017 1:19:12 PM<br>
<b>To:</b> <a href="mailto:openbmc@lists.ozlabs.org" target="_blank">openbmc@lists.ozlabs.org</a><br>
<b>Subject:</b> Re: RFC Adding Interfaces to OpenBMC </font>
<div> </div>
</div><div><div class="h5">
<div>
<p><tt>After some discussion that did not make it to the mailing list I am revising the RFC to integrate with Nginx technology. The theme is the same; create interfaces in a way that anyone can add/remove/replace per their business needs through with a prescriptive
process</tt><br>
<br>
<br>
<tt>Request - https ---> Nginx (Reverse-Proxy)<br>
|</tt><br>
<tt> |http</tt><br>
<tt> |<br>
/|\ <br>
| | `-> rest_dbus <a href="http://127.0.0.1:8081" target="_blank">127.0.0.1:8081</a><br>
| `--> webui <a href="http://127.0.0.1:8082" target="_blank">127.0.0.1:8082</a><br>
`----> redfish <a href="http://127.0.0.1:8083" target="_blank">127.0.0.1:8083</a></tt><br>
<br>
<font size="2">With Nginx accepting https would there be a need for localhost applications incur the cost of secure https too?</font><br>
<br>
<br>
<tt><font size="2">Chris Austen/Austin/IBM wrote on 09/01/2017 10:54:06 AM:<br>
<br>
> From: Chris Austen/Austin/IBM</font></tt><br>
<tt><font size="2">> To: <a href="mailto:openbmc@lists.ozlabs.org" target="_blank">openbmc@lists.ozlabs.org</a></font></tt><br>
<tt><font size="2">> Date: 09/01/2017 10:54 AM</font></tt><br>
<tt><font size="2">> Subject: RFC Adding Interfaces to OpenBMC </font></tt><br>
<tt><font size="2">> <br>
> I'd like to get some feed back on draft...</font></tt><br>
<tt><font size="2">> <br>
> It should not be any surprise that we are trying to implement a web <br>
> user interface and Redfish. I think requiring every implementation <br>
> of OpenBMC to now support a webui and Redfish goes against the basic<br>
> principals of the project. A better approach would be to allow the <br>
> machine configuration to determine what features/apps to support. <br>
> The OpenBMC core would provide the infrastructure to reverse(?) <br>
> proxy incoming requests to the various applications based on the <br>
> application defining which routes it can handle. With those <br>
> thoughts in mind, the current design needs to be tweaked slightly.</font></tt><br>
<tt><font size="2">> <br>
> FROM:</font></tt><br>
<tt><font size="2">> | server | app (dbus) |</font></tt><br>
<tt><font size="2">> TO:</font></tt><br>
<tt><font size="2">> | server | reverse | app (dbus) |</font></tt><br>
<tt><font size="2">> | | proxy | app (web) |</font></tt><br>
<tt><font size="2">> | | | app (redfish) |</font></tt><br>
<tt><font size="2">> | | | app (...) |</font></tt><br>
<tt><font size="2">> Route handler added at service startup to create the proxy environment</font></tt><br>
<tt><font size="2">> (figure 1: In todays design the single app defines all routes at
<br>
> compile time. Adding routes to that single app forces all OpenBMC <br>
> machines to pick up the new routes which is undesirable) </font></tt><br>
<tt><font size="2">> <br>
> Note: due to legacy decisions the '/' and '/xyz' route are owned by <br>
> the dbus app. (Could the dbus route be helpful here? All browsers <br>
> use 'text/html' and our rest uses 'application/json', perhaps a <br>
> nudge/redirect the user to the correct uri) </font></tt><br>
<tt><font size="2">> <br>
> Security:</font></tt><br>
<tt><font size="2">> ~~~~~~~~</font></tt><br>
<tt><font size="2">> None at the proxy level</font></tt><br>
<tt><font size="2">> <br>
> Registering Routes:</font></tt><br>
<tt><font size="2">> ~~~~~~~~~~~~~~~</font></tt><br>
<tt><font size="2">> Route registration will happen at service start up. An application
<br>
> configuration file placed in to a predetermined location will be <br>
> parsed by the proxy code</font></tt><br>
<tt><font size="2">> <br>
> Application Requirements:</font></tt><br>
<tt><font size="2">> ~~~~~~~~~~~~~~~~~~~~~~</font></tt><br>
<tt><font size="2">> 1) The cfg file will be based on a common xxx format</font></tt><br>
<tt><font size="2">> - likely need a decision as to proxy or reverse proxy before
<br>
> declaring config format type </font></tt><br>
<tt><font size="2">> <br>
> 2) Create a bb file in the appropriate layer. Keep in mind the openbmc/<br>
> meta-phosphor/common/recipes-<wbr>phosphor/interfaces/ is for core <br>
> functionality only. </font></tt><br>
<tt><font size="2">> i.e. PROVIDES = 'phosphor-webui'</font></tt><br>
<tt><font size="2">> <example of how to copy the apps config file to the correct<br>
> route registration location></font></tt><br>
<tt><font size="2">> </font></tt><br>
<tt><font size="2">> 3) Declare in the appropriate machine conf file the bb file which
<br>
> contains your application </font></tt><br>
<tt><font size="2">> i.e. OBMC_MACHINE_FEATURES += 'phosphor-webui'</font></tt><br>
<tt><font size="2">> <br>
> <br>
> Chris Austen<br>
> POWER Systems Enablement Manager <br>
> <a href="tel:(512)%20286-5184" value="+15122865184" target="_blank">(512) 286-5184</a> (T/L: 363-5184)</font></tt><br>
</p>
</div>
</div></div></div>
</blockquote></div><br></div>