| commit | 9e03140656b1d93c2f4d0f3894eee8d664eb646e | [log] [tgz] |
|---|---|---|
| author | Carson Labrado <clabrado@google.com> | Fri Jul 08 20:56:52 2022 +0000 |
| committer | Ed Tanous <ed@tanous.net> | Sun Jan 08 01:12:24 2023 +0000 |
| tree | 350ed0f217777f6a91c08de386d695b0d7ba311d | |
| parent | 9017faf2918308a375f37bebc9d431da9a75a7b2 [diff] |
Aggregation: Generate collections from schema In aggregation we need to account for when a satellite BMC supports a resource collection that the aggregating BMC does not. We need to add links in responses from upstream resources to indicate that these satellite only resources exist. These top level collections do not always have the location format of /redfish/v1/<collection_id>. We determine all of those from the schema rather than hardcoding a few choice exceptions that do not fit that format such as /redfish/v1/UpdateService/FirmwareInventory. This patch is the first step in accomplishing this. We parse all xml schema files in order to determine what are the top level collection URIs. For URIs that are upstream from top level collections we'll be able to derive what URIs could appear in the response which are also on the same path to a top level collection. The xml files for resources that aren't currently supported by bmcweb are ignored when creating the schema index and later deleted once the above parsing completes. Later patches will use this information to make sure that we are properly handling all schema defined top level collections. Tested: Compiles with aggregation enabled Signed-off-by: Carson Labrado <clabrado@google.com> Change-Id: Icff825f4e4e9d84c96254561350f82839abdc074
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.