| commit | e6feae518c5a153af2dc64d3810fd029f0875366 | [log] [tgz] |
|---|---|---|
| author | Andrew Geissler <geissonator@yahoo.com> | Thu Apr 06 10:27:41 2023 -0600 |
| committer | Ed Tanous <ed@tanous.net> | Fri May 19 16:03:46 2023 +0000 |
| tree | 9a2e4a5fe7cfe58298fc9ab2d64f6d29e0ed6cf9 | |
| parent | a6695a8441445e441009ad64ff04c732f2538426 [diff] |
redfish: network protocol fix for multiple interfaces Some OpenBMC systems may have multiple ethernet interfaces available but choose to only enable a subset of them. In these situations, the bmcweb code needs to ensure it has the proper logic to determine if a particular protocol is enabled under the redfish API: redfish/v1/Managers/bmc/NetworkProtocol For example, to determine if the IPMI service is enabled, bmcweb looks at systemd units (phosphor-ipmi-net@<eth>.socket) that are instantiated based on the ethernet interfaces in the system. This commit changes the logic which determines if a particular protocol is enabled to look to see if the systemd service is enabled on _any_ network interface. If it is found on any interface then it is considered to be enabled. For example, if the netipmid application is running against any of the available network interfaces then it should be returned to the user that the IPMI protocol is enabled. The current behavior of the code is somewhat undefined in that it just uses the state of the last phosphor-ipmi-net@ethX.socket to determine what it returns to the user. Tested: - Confirmed on system with netipmid running on eth0 and not on eth1 that response was IPMI enabled - Confirmed on same system that a POST to disable IPMI worked, netipmid was stopped, and the NetworkProtocol response indicated IPMI disabled* - Confirmed on same system that a POST to enable IPMI worked, netipmid was running on eth0, and the NetworkProtocol response indicated IPMI enabled - Confirmed on system with both eth0 and eth1 enabled that we got expected behavior - No issues in Redfish Validator * Testing showed an issue introduced with 5c3e927 where a default of "Disabled" is no longer returned when services like IPMI and SSH are disabled. The protocol is simply not shown in the NetworkProtocol response. It can still be enabled via a PATCH operation. As this issue is unrelated to this patch, I'll submit a separate commit to discuss whether we should go back to a default when protocols are disabled. Change-Id: Ib55914b1403ca96ed7ace450f79af3b47b5c8e59 Signed-off-by: Andrew Geissler <geissonator@yahoo.com>
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 setup 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 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.
bmcweb is capable of aggregating resources from satellite BMCs. Refer to AGGREGATION.md for more information on how to enable and use this feature.