commit | a2dd60a69046cdda90077463f614140aeb91edc4 | [log] [tgz] |
---|---|---|
author | Brandon Kim <brandonkim@google.com> | Mon Mar 14 11:42:34 2022 -0700 |
committer | Ed Tanous <ed@tanous.net> | Mon Mar 21 22:57:11 2022 +0000 |
tree | cd2fd3166038a62a9d97833f11b1139bedbd8585 | |
parent | 91ac2e57c416bbdf95fa9242eaf8e5f9e118d5ba [diff] |
log_services: Initialize Members@odata.count as 0 Currently when Members array is initialized to an empty array, the Members@odata.count is not present. Initialize it as 0. The bug seems to have been introduced by: https://gerrit.openbmc-project.xyz/50224 Tested: On QEMU - Before change: { "@odata.id": "/redfish/v1/Systems/system/LogServices/Crashdump/Entries", "@odata.type": "#LogEntryCollection.LogEntryCollection", "Description": "Collection of Crashdump Entries", "Members": [], "Name": "Open BMC Crashdump Entries" } After change: { "@odata.id": "/redfish/v1/Systems/system/LogServices/Crashdump/Entries", "@odata.type": "#LogEntryCollection.LogEntryCollection", "Description": "Collection of Crashdump Entries", "Members": [], "Members@odata.count": 0, "Name": "Open BMC Crashdump Entries" } { "@odata.id": "/redfish/v1/Systems/system/LogServices/Crashdump/Entries", "@odata.type": "#LogEntryCollection.LogEntryCollection", "Description": "Collection of Crashdump Entries", "Members": [ { "@odata.id": "/redfish/v1/Systems/system/LogServices/Crashdump/Entries/OnDemand", "@odata.type": "#LogEntry.v1_7_0.LogEntry", "AdditionalDataURI": "/redfish/v1/Systems/system/LogServices/Crashdump/Entries/OnDemand/crashdump_ondemand_1970-01-01T00:05:23Z.json", "Created": "1970-01-01T00:05:23Z", "DiagnosticDataType": "OEM", "EntryType": "Oem", "Id": "OnDemand", "Name": "CPU Crashdump", "OEMDiagnosticDataType": "PECICrashdump" } ], "Members@odata.count": 1, "Name": "Open BMC Crashdump Entries" } Signed-off-by: Brandon Kim <brandonkim@google.com> Change-Id: I5d17a8a62db23ad0da1c97113a4c6521bdec02cb
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 -C builddir test ninja -C builddir coverage
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.