<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
</head>
<body>
<style type="text/css" style="display:none;"><!-- P {margin-top:0;margin-bottom:0;} --></style>
<div id="divtagdefaultwrapper" 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%" tabindex="-1">
<div id="divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" style="font-size:11pt" color="#000000"><b>From:</b> openbmc <openbmc-bounces+kenneth.wilke=rackspace.com@lists.ozlabs.org> on behalf of Chris Austen <austenc@us.ibm.com><br>
<b>Sent:</b> Tuesday, September 19, 2017 1:19:12 PM<br>
<b>To:</b> openbmc@lists.ozlabs.org<br>
<b>Subject:</b> Re: RFC Adding Interfaces to OpenBMC </font>
<div> </div>
</div>
<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 127.0.0.1:8081<br>
| `--> webui 127.0.0.1:8082<br>
`----> redfish 127.0.0.1:8083</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: openbmc@lists.ozlabs.org</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-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>
> (512) 286-5184 (T/L: 363-5184)</font></tt><br>
</p>
</div>
</body>
</html>