commit | 1a2a14379d515c393cc134ea719d56efbae2116e | [log] [tgz] |
---|---|---|
author | Andrew Geissler <geissonator@yahoo.com> | Wed Jan 06 13:48:57 2021 -0600 |
committer | Andrew Geissler <geissonator@yahoo.com> | Fri Jan 08 01:49:02 2021 +0000 |
tree | 0e13669ad4871ff807eabb01b91f3b94eabd5e6c | |
parent | c638bc456612a44355dadc9788ae3e18ad54a37c [diff] |
transition support for system state The following commit defined two new values for the host state: https://github.com/openbmc/phosphor-dbus-interfaces/commit/9f65dfeaa5ab22cae03db45c9916868da9864f83 These new state values, TransitioningToOff and TransitioningToRunning, map quite well to the Redfish system PowerState values of PoweringOff and PoweringOn. There have been requests from external users of our Redfish interfaces to know this level of detail, especially in the PoweringOff path due to the length of time it can take (up to 2 hours is allowed for the host to shut itself down gracefully). Tested: - Put host state D-Bus property in each of new states and verified Redfish API returned expected results. Change-Id: I0c43dc2fa8b057beea48bc6f3dcde80d094ccfdb Signed-off-by: Andrew Geissler <geissonator@yahoo.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 -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.