| commit | b0d3a8562bb11ac9279aa234ce60cf619b64ca6a | [log] [tgz] |
|---|---|---|
| author | Ed Tanous <edtanous@google.com> | Tue Jun 28 08:35:47 2022 -0700 |
| committer | Ed Tanous <ed@tanous.net> | Wed Aug 17 17:26:19 2022 +0000 |
| tree | bd776f6b8163748d3713a151a29090d6ef6f922e | |
| parent | 17dcc312e534b33c2ea18a1dbf287e30ea79cfb5 [diff] |
Section out the maintainership of bmcweb As bmcweb grows, it's important that we distribute the load amongst the available community. This commit pivots slightly from our usual process of giving full repo maintainership to a small list of one or two people, and instead proposes passing out smaller pieces of maintainership. The hope is that over time, these maintainers can grow into owning larger portions of the stack. In this way, we can increase our breadth of available maintainers for the things that are straightforward, like adding new redfish schemas or doing migrations, while still keeping a few core maintainers responsible for the core. I've reached out to both Krzysztof and Nan, and asked them which pieces they feel that they're comfortable maintaining, and I've added all components they listed to the OWNERS files. Each has a track record of doing reviews in upstream, and given that Gunnar and myself will still be present and active, this seems like a good thing for the project overall. The specific sections of maintainership for each person is laid out in the OWNERS file, and we can modify over time as each person gets more experience in reviewing and testing. The expectations are that for the files explicitly listed, these new maintainers will be able to handle all reviews that touch those sections of functionality (including reviews not yet merged). Please continue to communicate as you have previously. To those being added, it is expected that if there are core issues brought up in the modules that you maintain, you escalate them to the entire group of maintainers, and remain active on our communication channels. In the past, we've had significant issues where individual modules tried to implement generalized solutions in a handler-specific way, and while most of that has been cleaned up, it caused significant thrash. Lets try to avoid that going forward. I look forward to working with both of you more. Change-Id: I7750a12703af68fc82f84a0e22496dabca582208 Signed-off-by: Ed Tanous <edtanous@google.com>
This component attempts to be a "do everything" embedded webserver for OpenBMC.
The webserver implements a few distinct interfaces:
bmcweb at a protocol level supports http and https. TLS is supported through OpenSSL.
Bmcweb supports multiple authentication protocols:
Each of these types of authentication is able to be enabled or disabled both via runtime policy changes (through the relevant Redfish APIs) or via configure time options. All authentication mechanisms supporting username/password are routed to libpam, to allow for customization in authentication implementations.
All authorization in bmcweb is determined at routing time, and per route, and conform to the Redfish PrivilegeRegistry.
*Note: Non-Redfish functions are mapped to the closest equivalent Redfish privilege level.
bmcweb is configured per the meson build files. Available options are documented in meson_options.txt
meson builddir ninja -C builddir
If any of the dependencies are not found on the host system during configuration, meson will automatically download them via its wrap dependencies mentioned in bmcweb/subprojects.
bmcweb by default is compiled with runtime logging disabled, as a performance consideration. To enable it in a standalone build, add the
-Dlogging='enabled'
option to your configure flags. If building within Yocto, add the following to your local.conf.
EXTRA_OEMESON:pn-bmcweb:append = "-Dbmcweb-logging='enabled'"
bmcweb relies on some on-system data for storage of persistent data that is internal to the process. Details on the exact data stored and when it is read/written can seen from the persistent_data namespace.
When SSL support is enabled and a usable certificate is not found, bmcweb will generate a self-signed a certificate before launching the server. Please see the bmcweb source code for details on the parameters this certificate is built with.