RFC Adding Interfaces to OpenBMC

[Rick Altherr]

Agree.

On Wed, Sep 20, 2017 at 7:04 AM, Kenneth Wilke <kenneth.wilke at rackspace.com>
wrote:

> 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/afce4a44/attachment.html>