RFC Adding Interfaces to OpenBMC

[Kenneth Wilke]

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.


Kenneth

________________________________
From: openbmc <openbmc-bounces+kenneth.wilke=rackspace.com at lists.ozlabs.org> on behalf of Chris Austen <austenc at us.ibm.com>
Sent: Tuesday, September 19, 2017 1:19:12 PM
To: openbmc at lists.ozlabs.org
Subject: Re: RFC Adding Interfaces to OpenBMC


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


Request - https ---> Nginx (Reverse-Proxy)
                 |
                  |http
                  |
                /|\
                | | `-> rest_dbus   127.0.0.1:8081
                |  `--> webui       127.0.0.1:8082
                 `----> redfish     127.0.0.1:8083

With Nginx accepting https would there be a need for localhost applications incur the cost of secure https too?


Chris Austen/Austin/IBM wrote on 09/01/2017 10:54:06 AM:

> From: Chris Austen/Austin/IBM
> To: openbmc at lists.ozlabs.org
> Date: 09/01/2017 10:54 AM
> Subject: RFC Adding Interfaces to OpenBMC
>
> I'd like to get some feed back on draft...
>
> It should not be any surprise that we are trying to implement a web
> user interface and Redfish.  I think requiring every implementation
> of OpenBMC to now support a webui and Redfish goes against the basic
> principals of the project.  A better approach would be to allow the
> machine configuration to determine what features/apps to support.
> The OpenBMC core would provide the infrastructure to reverse(?)
> proxy incoming requests to the various applications based on the
> application defining which routes it can handle.  With those
> thoughts in mind, the current design needs to be tweaked slightly.
>
> FROM:
> | server | app (dbus) |
> TO:
> | server | reverse | app (dbus)    |
> |        |  proxy  | app (web)     |
> |        |         | app (redfish) |
> |        |         | app (...)     |
> Route handler added at service startup to create the proxy environment
> (figure 1: In todays design the single app defines all routes at
> compile time.  Adding routes to that single app forces all OpenBMC
> machines to pick up the new routes which is undesirable)
>
> Note: due to legacy decisions the '/' and '/xyz' route are owned by
> the dbus app.  (Could the dbus route be helpful here?  All browsers
> use 'text/html' and our rest uses 'application/json', perhaps a
> nudge/redirect the user to the correct uri)
>
> Security:
> ~~~~~~~~
> None at the proxy level
>
> Registering Routes:
> ~~~~~~~~~~~~~~~
> Route registration will happen at service start up.  An application
> configuration file placed in to a predetermined location will be
> parsed by the proxy code
>
> Application Requirements:
> ~~~~~~~~~~~~~~~~~~~~~~
> 1) The cfg file will be based on a common xxx format
> - likely need a decision as to proxy or reverse proxy before
> declaring config format type
>
> 2) Create a bb file in the appropriate layer.  Keep in mind the openbmc/
> meta-phosphor/common/recipes-phosphor/interfaces/ is for core
> functionality only.
> i.e.    PROVIDES = 'phosphor-webui'
>          <example of how to copy the apps config file to the correct
> route registration location>
>
> 3) Declare in the appropriate machine conf file the bb file which
> contains your application
> i.e.    OBMC_MACHINE_FEATURES += 'phosphor-webui'
>
>
> Chris Austen
> POWER Systems Enablement Manager
> (512) 286-5184 (T/L: 363-5184)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20170920/9333223a/attachment-0001.html>