commit | ff85ed3d82f16f3e23de5ddf9115b429a15bf364 | [log] [tgz] |
---|---|---|
author | Gunnar Mills <gmills@us.ibm.com> | Thu Jun 24 13:30:46 2021 -0500 |
committer | Gunnar Mills <gmills@us.ibm.com> | Fri Jun 25 13:07:18 2021 -0500 |
tree | 63bf2a5de7fd01159e014d043fcff8707b267f21 | |
parent | 49e429ca172365bd4ba16c924501321c73527cbe [diff] |
Add Privileges schema to allow list The allow list should contain all schemas implemented by bmcweb. The allow list was missing the Privileges schema. The Privileges schema is referenced in the Role schema here: "AssignedPrivileges": { "description": "The Redfish privileges for this role.", "items": { "$ref": "http://redfish.dmtf.org/schemas/v1/Privileges.json#/definitions/PrivilegeType" https://redfish.dmtf.org/schemas/v1/Role.v1_3_1.json In OpenBMC CI Redfish Validator testing the following error was hit 3 times: ERROR - ConnectionError on http://redfish.dmtf.org/schemas/v1/Privileges_v1.xml: ConnectionError(ProtocolError('Connection aborted.', RemoteDisconnected('Remote end closed connection without response'))) Network glitch somewhere but inspired this change. Long term not sure if the allow list makes sense. While still used today (and for the immediate future) it should attempt to accurately reflect the implemented schemas in bmcweb. The allow list was added in 349a2ac3 to save space. Information on the CI Redfish Validator testing can be found at https://github.com/openbmc/openbmc-test-automation/search?q=Redfish-Service-Validator The test redownloads the schemas each time. Tested: Validator passed. See the new schema: { "@odata.id": "/redfish/v1/JsonSchemas/Privileges" }, Change-Id: Iaf3de36b211efab4115a17fd43f0263b8bd3107f Signed-off-by: Gunnar Mills <gmills@us.ibm.com>
This component attempts to be a "do everything" embedded webserver for openbmc.
At this time, the webserver implements a few interfaces:
BMCWeb is configured by setting -D
flags that correspond to options in bmcweb/meson_options.txt
and then compiling. For example, meson <builddir> -Dkvm=disabled ...
followed by ninja
in build directory. The option names become C++ preprocessor symbols that control which code is compiled into the program.
meson builddir ninja -C builddir
meson builddir -Dbuildtype=minsize -Db_lto=true -Dtests=disabled ninja -C buildir
If any of the dependencies are not found on the host system during configuration, meson automatically gets them via its wrap dependencies mentioned in bmcweb/subprojects
.
meson builddir -Dwrap_mode=nofallback ninja -C builddir
meson builddir -Dbuildtype=debug ninja -C builddir
meson builddir -Db_coverage=true -Dtests=enabled ninja coverage -C builddir test
When BMCWeb starts running, it reads persistent configuration data (such as UUID and session data) from a local file. If this is not usable, it generates a new configuration.
When BMCWeb SSL support is enabled and a usable certificate is not found, it will generate a self-sign a certificate before launching the server. The keys are generated by the secp384r1
algorithm. The certificate
C=US, O=OpenBMC, CN=testhost
,SHA-256
algorithm.