Gitiles
Code Review Sign In
gerrit.openbmc.org / openbmc / bmcweb / 743eb1c0cb44c955078daa2912767cd6d6bb6432
commit743eb1c0cb44c955078daa2912767cd6d6bb6432[log] [tgz]
authorJohnathan Mantey <johnathanx.mantey@intel.com>Wed Apr 03 12:05:57 2024 -0700
committerEd Tanous <ed@tanous.net>Fri May 03 17:57:57 2024 +0000
tree68465614493c6c3dd1632e14f36bed5edcc4d0d2
parent102a4cdacb0a6d8c8c3c97e10bedbb66000ac5dc [diff]
Delete IPv4 default gateway when deleting an IPv4 static address

The Redfish schema for creating static IPv4 addresses requires the IP
address, the netmask, and a gateway IP address. There's an issue
inherent with this method. A network interface is only permitted a
single IPv4 default gateway. If more than one IPv4 static address is
assigned to the NIC each entry is processed, and potentially
conflicting default gateways may be assigned. The last entry processed
assigns the IPv4 default gateway. This behavior will cause unexpected
results. It is necessary to prevent assigning mismatched default
gateway values.

The IPv4 address removal process requires additional work also. The
default gateway value is left in place even after the final static
IPv4 address is removed. It is necessary to perform an additional
action to clear the gateway address. Without explicit removal the
network is left in a condition that may prevent IP traffic from being
able to be sent from the BMC. This even in the event that the NIC is
actively being managed via DHCPv4.

Tested:
Disabled DHCPv4 on a secondary NIC (eth1)
Assigned a static IPv4 address.
Inspected the systemd-networkd config file in order to confirm the
Gateway entry is added. This is done to be explicitly sure the
network.config file has the Gateway entry.
Sent a Redfish PATCH command to delete the static IPv4 address.
Confirmed that the systemd-networkd config file no longer contained a
Gateway entry. This is done to be explicitly sure the network.config
file no longer contains the Gateway entry.
Created a PATCH containing multiple IPv4 static addresses all with
different Gateway values. Confirmed an error is returned when a
mismatch occurs in the Gateway values.
Assigned a new static address, and then restored DHCPv4.
Confirmed that the default gateway entry in the config file is removed.
Submitted a delete request for the remaining static IPv4 address that
is now orphaned by re-enabling DHCPv4. This removed the static IPv4
address.

Change-Id: Ia12cf2a38ba86266ce71dc28475b0d07b7e09ebc
Signed-off-by: Johnathan Mantey <johnathanx.mantey@intel.com>
1 file changed
tree: 68465614493c6c3dd1632e14f36bed5edcc4d0d2
  1. .github/
  2. config/
  3. http/
  4. include/
  5. redfish-core/
  6. scripts/
  7. src/
  8. static/
  9. subprojects/
  10. test/
  11. .clang-format
  12. .clang-tidy
  13. .codespell-ignore
  14. .dockerignore
  15. .gitignore
  16. .markdownlint.yaml
  17. .openbmc-enforce-gitlint
  18. .prettierignore
  19. .shellcheck
  20. AGGREGATION.md
  21. CLIENTS.md
  22. COMMON_ERRORS.md
  23. DBUS_USAGE.md
  24. DEVELOPING.md
  25. HEADERS.md
  26. LICENSE
  27. meson.build
  28. meson_options.txt
  29. OEM_SCHEMAS.md
  30. OWNERS
  31. README.md
  32. Redfish.md
  33. REDFISH_CHECKLIST.md
  34. run-ci
  35. TESTING.md
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 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.

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.

Redfish Aggregation

bmcweb is capable of aggregating resources from satellite BMCs. Refer to AGGREGATION.md for more information on how to enable and use this feature.