commit	0d9462115c53d478ed757ca4a3cccd0acf593781	[log] [tgz]
author	Claire Weinan <cweinan@google.com>	Wed Jul 13 19:40:19 2022 -0700
committer	Claire Weinan <cweinan@google.com>	Fri Jan 13 22:58:36 2023 +0000
tree	bc880dc3b46bd2d72492c32e0d6e4d5624a70676
parent	51f65b0caa10aa785bd0050d31cf0c01ed17ac8e [diff]

LogService: Use DeleteAll DBus method in clearDump

Update the clearDump() implementation to call the DeleteAll D-Bus
method instead of iterating through D-Bus objects representing
individual log entries and calling the Delete D-Bus method on each one.
(It's more efficient for phosphor-debug-collector to iterate through
entries in its DeleteAll method handler than for bmcweb to iterate
through them.)

It seems like clearDump() wasn't originally implemented using DeleteAll
because dumps of various types were under the same D-Bus path namespace
at the time and there wasn't a way to selectively clear dumps of only a
specific type. The commit at [1] put different dump types under
different path namespaces (enabling us to now use DeleteAll).

Now clients should see a bit of performance improvement when running
the ClearLog action on dump LogServices, due to the reduced number of
D-Bus method calls needed to execute ClearLog.

Also updated getDumpServiceInfo() to populate the ClearLog action for
dump LogServices based on whether their dump manager object implements
xyz.openbmc_project.Collection.DeleteAll.

Tested:
Cleared the fault log containing 100 entries.
Ran with the time command several times before and after the change:
```
time curl -k -H "X-Auth-Token: $token" -X POST http://${bmc}/redfish/v1/Managers/bmc/LogServices/FaultLog/Actions/LogService.ClearLog
```

Before the change, "real" time reported was ~1.2s.
After the change, "real" time reported was ~0.4s.

Forced creation of dump entries and then ran Redfish ClearLog action on
each dump type:
```
curl -k -H "X-Auth-Token: $token" -X POST http://${bmc}/redfish/v1/Managers/bmc/LogServices/Dump/Actions/LogService.ClearLog

curl -k -H "X-Auth-Token: $token" -X POST http://${bmc}/redfish/v1/Managers/bmc/LogServices/FaultLog/Actions/LogService.ClearLog

curl -k -H "X-Auth-Token: $token" -X POST http://${bmc}/redfish/v1/Systems/system/LogServices/Dump/Actions/LogService.ClearLog
```

Then verified that there were no dump LogService entries afterwards:
```
curl -k -H "X-Auth-Token: $token" -X GET http://${bmc}/redfish/v1/Managers/bmc/LogServices/Dump/Entries

curl -k -H "X-Auth-Token: $token" -X GET http://${bmc}/redfish/v1/Managers/bmc/LogServices/FaultLog/Entries

curl -k -H "X-Auth-Token: $token" -X GET http://${bmc}/redfish/v1/Systems/system/LogServices/Dump/Entries
```

Also verified that the corresponding D-Bus objects were gone from the
D-Bus tree after running ClearLog on each dump type:

Before ClearLog:
busctl tree xyz.openbmc_project.Dump.Manager
`-/xyz
  `-/xyz/openbmc_project
    `-/xyz/openbmc_project/dump
      |-/xyz/openbmc_project/dump/bmc
      | `-/xyz/openbmc_project/dump/bmc/entry
      |   `-/xyz/openbmc_project/dump/bmc/entry/101
      |-/xyz/openbmc_project/dump/faultlog
      | `-/xyz/openbmc_project/dump/faultlog/entry
      |   |-/xyz/openbmc_project/dump/faultlog/entry/11
      |   |-/xyz/openbmc_project/dump/faultlog/entry/12
      |   |-/xyz/openbmc_project/dump/faultlog/entry/13
      |   |-/xyz/openbmc_project/dump/faultlog/entry/14
      |   |-/xyz/openbmc_project/dump/faultlog/entry/15
      |   |-/xyz/openbmc_project/dump/faultlog/entry/16
      |   |-/xyz/openbmc_project/dump/faultlog/entry/17
      |   |-/xyz/openbmc_project/dump/faultlog/entry/18
      |   |-/xyz/openbmc_project/dump/faultlog/entry/19
      |   `-/xyz/openbmc_project/dump/faultlog/entry/20
      |-/xyz/openbmc_project/dump/internal
      | `-/xyz/openbmc_project/dump/internal/manager
      `-/xyz/openbmc_project/dump/system
        `-/xyz/openbmc_project/dump/system/entry
          |-/xyz/openbmc_project/dump/system/entry/3
          `-/xyz/openbmc_project/dump/system/entry/4

After ClearLog:
busctl tree xyz.openbmc_project.Dump.Manager
`-/xyz
  `-/xyz/openbmc_project
    `-/xyz/openbmc_project/dump
      |-/xyz/openbmc_project/dump/bmc
      |-/xyz/openbmc_project/dump/faultlog
      |-/xyz/openbmc_project/dump/internal
      | `-/xyz/openbmc_project/dump/internal/manager
      `-/xyz/openbmc_project/dump/system

Confirmed that ClearLog action is listed for the following
LogServices:
  /redfish/v1/Managers/bmc/LogServices/Dump
  /redfish/v1/Managers/bmc/LogServices/FaultLog
  /redfish/v1/Systems/system/LogServices/Dump
Then ran "systemctl stop xyz.openbmc_project.Dump.Manager" (which
removes dump manager objects including their
xyz.openbmc_project.Collection.DeleteAll interface) and saw that the
ClearLog action was no longer listed. Also locally built a version of
phosphor-debug-collecor with the interface
xyz.openbmc_project.Collection.DeleteAll removed from dump managers and
ran it and saw that the ClearLog action wasn't listed.

Redfish Service Validator passed on the following URIs
(with service xyz.openbmc_project.Dump.Manager running):
  /redfish/v1/Managers/bmc/LogServices/Dump
  /redfish/v1/Managers/bmc/LogServices/FaultLog
  /redfish/v1/Systems/system/LogServices/Dump

Note: Most dump LogService unit tests were removed in this patchset
since this patchset adds a D-Bus call to getDumpServiceInfo(), and
we haven't decided how to mock D-Bus calls for unit testing yet.

[1] https://github.com/openbmc/phosphor-debug-collector/commit/fef66a951fe6fe283515480b2c493dfdc2275a95

Signed-off-by: Claire Weinan <cweinan@google.com>
Change-Id: Ic5f8f9e3528f521887766d8710bd77f969d8236a

2 files changed

tree: bc880dc3b46bd2d72492c32e0d6e4d5624a70676

README.md

OpenBMC webserver

This component attempts to be a "do everything" embedded webserver for OpenBMC.

Features

The webserver implements a few distinct interfaces:

DBus event websocket. Allows registering on changes to specific dbus paths, properties, and will send an event from the websocket if those filters match.
OpenBMC DBus REST api. Allows direct, low interference, high fidelity access to dbus and the objects it represents.
Serial: A serial websocket for interacting with the host serial console through websockets.
Redfish: A protocol compliant, DBus to Redfish translator.
KVM: A websocket based implementation of the RFB (VNC) frame buffer protocol intended to mate to webui-vue to provide a complete KVM implementation.

Protocols

bmcweb at a protocol level supports http and https. TLS is supported through OpenSSL.

AuthX

Authentication

Bmcweb supports multiple authentication protocols:

Basic authentication per RFC7617
Cookie based authentication for authenticating against webui-vue
Mutual TLS authentication based on OpenSSL
Session authentication through webui-vue
XToken based authentication conformant to Redfish DSP0266

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.

Authorization

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.

Configuration

bmcweb is configured per the meson build files. Available options are documented in meson_options.txt

Compile bmcweb with default options

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.

Debug logging

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'"

Use of persistent data

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.

TLS certificate generation

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.