summaryrefslogtreecommitdiff
path: root/config
AgeCommit message (Collapse)AuthorFilesLines
2026-07-02Allow setting Mozilla modernEd Tanous1-0/+1
Mozilla publishes recommendations for TLS cipher suites to support. For many years bmcweb selected "intermediate" because of compatibility with clients that didn't yet support TLS1.3. This commit adds the ability to use the Mozilla modern recommendations, and disable TLS1.2 support through a new meson option, tls-profile. Tested: Loaded on qemu, and verified with testssl.sh[1] that parameters were applied. [1] https://github.com/testssl/testssl.sh Change-Id: I38e915b3943b5dbe5fb31e54eb3ebda9bbaeb811 Signed-off-by: Ed Tanous <etanous@nvidia.com>
2026-03-27fix systemd unit descriptionAlexander Hansen1-1/+1
Observed following problem: ``` Mar 27 13:10:04 s5549-bmc-a0423f63b4a5 systemd[1]: Stopping Start bmcweb server... Mar 27 13:10:04 s5549-bmc-a0423f63b4a5 systemd[1]: bmcweb.service: Deactivated successfully. Mar 27 13:10:04 s5549-bmc-a0423f63b4a5 systemd[1]: Stopped Start bmcweb server. Mar 27 13:10:04 s5549-bmc-a0423f63b4a5 systemd[1]: bmcweb.service: Consumed 1.946s CPU time. Mar 27 13:10:04 s5549-bmc-a0423f63b4a5 systemd[1]: Started Start bmcweb server. ``` The description is wrong and logs do not form properly. Fix the unit description as per systemd docs [1] Tested: on Tyan S5549 ``` Mar 27 13:56:36 s5549-bmc-a0423f63b4a5 systemd[1]: Stopping bmcweb server... Mar 27 13:56:36 s5549-bmc-a0423f63b4a5 systemd[1]: bmcweb.service: Deactivated successfully. Mar 27 13:56:36 s5549-bmc-a0423f63b4a5 systemd[1]: Stopped bmcweb server. Mar 27 13:56:36 s5549-bmc-a0423f63b4a5 systemd[1]: bmcweb.service: Consumed 1.017s CPU time. Mar 27 13:56:36 s5549-bmc-a0423f63b4a5 systemd[1]: Started bmcweb server. ``` References: [1] https://www.freedesktop.org/software/systemd/man/latest/systemd.unit.html#%5BUnit%5D%20Section%20Options Fixes: 5a7094b22c9b ("Add systemd unit files") Change-Id: Ia363b15a4e4de6b825473f8761adbdaedd5ca95c Signed-off-by: Alexander Hansen <alexander.hansen@9elements.com>
2026-03-11Fix socket startup when mode is httpEd Tanous1-1/+8
When starting up in http mode, the socket needs to be of type http to allow the flow to work correctly. As is, enabling insecure-disable-ssl results in a non functional api due to hardcoded https. Teted: enabled insecure-disable-ssl; Verify that curl to http port 80 works Change-Id: I2958d6f39b642a02b6ce5f1c69d1da409dafc70d Signed-off-by: Ed Tanous <etanous@nvidia.com>
2026-02-05Sensors: Convert fan_tach sensors to PercentJanet Adkins1-0/+1
Redfish 2025.3 clarified the reporting of fan sensors should always be as ReadingType Percent to address issue #6197. [1] The fan_tach sensors on D-Bus are Rotational sensors. Conversion is necessary for these sensor values to reflect Percent instead. [2] This is reflected in a published mockup. [3] The Redfish update includes an additional sentence for the ReadingType description: ``` "... Services should represent fan speed and pump speed sensors with the `ReadingType` value `Percent`." ``` The ReadingRangeMax and ReadingRangeMin properties also must be converted to percent basis as they are defined to reflect the range of the Reading property. ``` curl -s https://redfish.dmtf.org/schemas/v1/Sensor.v1_11_1.json | jq .definitions.Sensor.properties.ReadingRangeMax.longDescription "This property shall indicate the maximum possible value of the `Reading` property for this sensor. This value is the range of valid readings for this sensor. Values outside this range are discarded as reading errors." ``` A new compile option, redfish-allow-rotational-fans, will maintain the old behavior of reporting fan_tach sensors as Rotational. When the option is disabled they will be reported as Percent. This will allow time for distributions to make adjustments to handle Percent reported fan sensors. The SpeedRPM Redfish property contains the RPM value for these sensors whether this option is enabled or disabled. Clients wanting to use the RPM value should convert to use the SpeedRPM property instead of the Reading property. ``` curl -s https://redfish.dmtf.org/schemas/v1/Sensor.v1_11_1.json | jq .definitions.Sensor.properties.SpeedRPM { "description": "The rotational speed.", "excerpt": "SensorFan,SensorFanArray,SensorPump", "longDescription": "This property shall contain a reading of the rotational speed of the device in revolutions per minute (RPM) units.", "readonly": true, "type": [ "number", "null" ], "units": "{rev}/min", "versionAdded": "v1_2_0" } ``` With the compile option disabled the following differences will be reflected in the responses for /redfish/v1/Chassis/chassis/Sensors/{}: - ReadingRangeMax/ReadingRangeMin: Converted to percent range, (100,0) - ReadingType: "Percent" - ReadingUnits: "%" - Reading: Computed percent value. The computation is the percent of the RPM Value within the MaxValue to MinValue range as reported by D-Bus for the sensor. - Note: If the percent cannot be computed for any reason the Reading property is set to null. - Note: SpeedRPM: Remains unchanged, it continues to report the RPM value as reported by D-Bus. Implementation Notes: - The SensorFanExcerpt and SensorFanArrayExcerpt definitions also include the SpeedRPM property. So moved setting of this property to be handled for excerpts as well. - The Sensor schema version has been updated regardless of the compile option setting. [1] https://github.com/DMTF/Redfish/issues/6197 [2] https://redfish.dmtf.org/schemas/v1/Sensor.v1_11_1.json [3] https://github.com/DMTF/Redfish-Publications/blob/main/mockups/public-rackmount1/Chassis/1U/Sensors/CPUFan1/index.json Tested: - Added new unit tests for new function getFanPercent() - Adjusted existing unit tests for Sensors to reflect changes for fan_tach sensors. - Redfish Service Validator passes (with option enabled and disabled) - Using hardware simulator hand-edited values for the min/max of the fan_tach sensors: - Option enabled: confirmed Redfish response same before and after code changes. - Option disabled: Confirmed Redfish responses and percent calculation. Example responses with compile option disabled: ``` // D-Bus: "Value" d 18000 "MaxValue" d 18000 "MinValue" d 0 curl -s -k -H "X-Auth-Token: $token" -X GET https://${bmc}/redfish/v1/Chassis/chassis/Sensors/fantach_fan0_0 { "@odata.id": "/redfish/v1/Chassis/chassis/Sensors/fantach_fan0_0", "@odata.type": "#Sensor.v1_11_1.Sensor", "Id": "fantach_fan0_0", "Name": "fan0 0", "Reading": 100, "ReadingRangeMax": 100, "ReadingRangeMin": 0, "ReadingType": "Percent", "ReadingUnits": "%", "SpeedRPM": 18000.0, "Status": { "Health": "OK", "State": "Enabled" } } // D-Bus: "Value" d 18000 "MaxValue" d 36000 "MinValue" d 0 curl -s -k -H "X-Auth-Token: $token" -X GET https://${bmc}/redfish/v1/Chassis/chassis/Sensors/fantach_fan1_0 { "@odata.id": "/redfish/v1/Chassis/chassis/Sensors/fantach_fan1_0", "@odata.type": "#Sensor.v1_11_1.Sensor", "Id": "fantach_fan1_0", "Name": "fan1 0", "Reading": 50, "ReadingRangeMax": 100, "ReadingRangeMin": 0, "ReadingType": "Percent", "ReadingUnits": "%", "SpeedRPM": 18000.0, "Status": { "Health": "OK", "State": "Enabled" } } // Minimum is non-zero // D-Bus: "Value" d 18000 "MaxValue" d 27000 "MinValue" d 9000 curl -s -k -H "X-Auth-Token: $token" -X GET https://${bmc}/redfish/v1/Chassis/chassis/Sensors/fantach_fan2_0 { "@odata.id": "/redfish/v1/Chassis/chassis/Sensors/fantach_fan2_0", "@odata.type": "#Sensor.v1_11_1.Sensor", "Id": "fantach_fan2_0", "Name": "fan2 0", "Reading": 50, "ReadingRangeMax": 100, "ReadingRangeMin": 0, "ReadingType": "Percent", "ReadingUnits": "%", "SpeedRPM": 18000.0, "Status": { "Health": "OK", "State": "Enabled" } } // Minimum is not initialized - Reading is null // D-Bus: "Value" d 18000 "MaxValue" d 18000 "MinValue" d -inf curl -s -k -H "X-Auth-Token: $token" -X GET https://${bmc}/redfish/v1/Chassis/chassis/Sensors/fantach_fan3_0 { "@odata.id": "/redfish/v1/Chassis/chassis/Sensors/fantach_fan3_0", "@odata.type": "#Sensor.v1_11_1.Sensor", "Id": "fantach_fan3_0", "Name": "fan3 0", "Reading": null, "ReadingRangeMax": 100, "ReadingRangeMin": 0, "ReadingType": "Percent", "ReadingUnits": "%", "SpeedRPM": 18000.0, "Status": { "Health": "OK", "State": "Enabled" } } // Minimum and Maximum are not initialized - so Reading is null // D-Bus: "Value" d 18000 "MaxValue" d inf "MinValue" d -inf curl -s -k -H "X-Auth-Token: $token" -X GET https://${bmc}/redfish/v1/Chassis/chassis/Sensors/fantach_fan4_0 { "@odata.id": "/redfish/v1/Chassis/chassis/Sensors/fantach_fan4_0", "@odata.type": "#Sensor.v1_11_1.Sensor", "Id": "fantach_fan4_0", "Name": "fan4 0", "Reading": null, "ReadingRangeMax": 100, "ReadingRangeMin": 0, "ReadingType": "Percent", "ReadingUnits": "%", "SpeedRPM": 18000.0, "Status": { "Health": "OK", "State": "Enabled" } } ``` Example of unchanged response with compile option enabled: ``` curl -s -k -H "X-Auth-Token: $token" -X GET https://${bmc}/redfish/v1/Chassis/chassis/Sensors/fantach_fan0_0 { "@odata.id": "/redfish/v1/Chassis/chassis/Sensors/fantach_fan0_0", "@odata.type": "#Sensor.v1_11_1.Sensor", "Id": "fantach_fan0_0", "Name": "fan0 0", "Reading": 18000.0, "ReadingRangeMax": 18000.0, "ReadingRangeMin": 0.0, "ReadingType": "Rotational", "ReadingUnits": "RPM", "SpeedRPM": 18000.0, "Status": { "Health": "OK", "State": "Enabled" } } ``` Change-Id: I8ec1e739bcd5ebce7453a2570569f2edc2284341 Signed-off-by: Janet Adkins <janeta@us.ibm.com>
2026-02-03Fabric: add support for PCIe Switch Port URIHarshit Aghera1-0/+1
This patch enable support for following properties for Port of a PCIe Switch. [1] - PortProtocol - PortType - CurrentSpeedGbps - ActiveWidth One of the devices that gets enabled with this patch is Nvidia ConnectX devices, which are network cards featuring an integrated PCIe switch. These devices combine both PCIe ports and network ports in a single unit. Since such devices don't strictly qualify as Fabric Adapters, the Switch URI is used instead of the FabricAdapter URI. Port schema only allows certain URIs as Port URI. URI /redfish/v1/Fabrics/{FabricId}/Switches/{SwitchId}/Ports/{PortId} seems most appropriate choice for PCIe Switch Port. [1] The Fabric resource is modeled similarly to the System resource, meaning that only one Fabric resource will exist for each BMC. Route handler for collections and each individual components are added in this patch for each URI resource under /redfish/v1/Fabrics. DBus Interface "xyz.openbmc_project.Inventory.Item.PCIeSwitch" is used to identify the Switch resources. Association between Switch and Port is `connecting` and `connected_to`. Feature like Port Metrics properties (for PCIe Error Counters) can be added in future at Port Metric URI. dbus-sensors patches - https://gerrit.openbmc.org/c/openbmc/dbus-sensors/+/84079 https://gerrit.openbmc.org/c/openbmc/dbus-sensors/+/83202 Tested: Build an image for nvl32-obmc machine with the following patch cherry picked. https://gerrit.openbmc.org/c/openbmc/dbus-sensors/+/84079 https://gerrit.openbmc.org/c/openbmc/openbmc/+/85490 The openbmc patch cherry-picks the following patches that are currently under review. ``` 1. device tree https://lore.kernel.org/all/aRbLqH8pLWCQryhu@molberding.nvidia.com/ 2. mctpd patches https://github.com/CodeConstruct/mctp/pull/85 3. u-boot changes https://lore.kernel.org/openbmc/20251121-msx4-v1-0-fc0118b666c1@nvidia.com/T/#t 4. kernel changes as specified in the openbmc patch (for espi) 5. entity-manager changes https://gerrit.openbmc.org/c/openbmc/entity-manager/+/85455 6. platform-init changes https://gerrit.openbmc.org/c/openbmc/platform-init/+/85456 7. spi changes https://lore.kernel.org/all/20251121-w25q01jv_fixup-v1-1-3d175050db73@nvidia.com/ ``` redfish service validator is passing. ``` $ curl -k -u 'root:0penBmc' https://${bmc_ip}/redfish/v1/Fabrics/ { "@odata.id": "/redfish/v1/Fabrics", "@odata.type": "#FabricCollection.FabricCollection", "Members": [ { "@odata.id": "/redfish/v1/Fabrics/fabric" } ], "Members@odata.count": 1, "Name": "Fabric Collection" }% $ curl -k -u 'root:0penBmc' https://${bmc_ip}/redfish/v1/Fabrics/fabric/ { "@odata.id": "/redfish/v1/Fabrics/fabric", "@odata.type": "#Fabric.v1_2_0.Fabric", "Id": "fabric", "Name": "fabric Fabric", "Switches": { "@odata.id": "/redfish/v1/Fabrics/fabric/Switches" } }% $ curl -k -u 'root:0penBmc' https://${bmc_ip}/redfish/v1/Fabrics/fabric/Switches/ { "@odata.id": "/redfish/v1/Fabrics/fabric/Switches", "@odata.type": "#SwitchCollection.SwitchCollection", "Members": [ { "@odata.id": "/redfish/v1/Fabrics/fabric/Switches/Nvidia_ConnectX_0" }, { "@odata.id": "/redfish/v1/Fabrics/fabric/Switches/Nvidia_ConnectX_1" }, { "@odata.id": "/redfish/v1/Fabrics/fabric/Switches/Nvidia_ConnectX_2" }, { "@odata.id": "/redfish/v1/Fabrics/fabric/Switches/Nvidia_ConnectX_3" } ], "Members@odata.count": 4, "Name": "fabric Switch Collection" }% $ curl -k -u 'root:0penBmc' https://${bmc_ip}/redfish/v1/Fabrics/fabric/Switches/Nvidia_ConnectX_0 { "@odata.id": "/redfish/v1/Fabrics/fabric/Switches/Nvidia_ConnectX_0", "@odata.type": "#Switch.v1_7_0.Switch", "Id": "Nvidia_ConnectX_0", "Name": "Nvidia_ConnectX_0", "Ports": { "@odata.id": "/redfish/v1/Fabrics/fabric/Switches/Nvidia_ConnectX_0/Ports" }, "Status": { "Health": "OK", "State": "Enabled" } }% $ curl -k -u 'root:0penBmc' https://${bmc_ip}/redfish/v1/Fabrics/fabric/Switches/Nvidia_ConnectX_0/Ports/ { "@odata.id": "/redfish/v1/Fabrics/fabric/Switches/Nvidia_ConnectX_0/Ports", "@odata.type": "#PortCollection.PortCollection", "Members": [ { "@odata.id": "/redfish/v1/Fabrics/fabric/Switches/Nvidia_ConnectX_0/Ports/DOWN_0" }, { "@odata.id": "/redfish/v1/Fabrics/fabric/Switches/Nvidia_ConnectX_0/Ports/DOWN_1" }, { "@odata.id": "/redfish/v1/Fabrics/fabric/Switches/Nvidia_ConnectX_0/Ports/UP_0" } ], "Members@odata.count": 3, "Name": "Nvidia_ConnectX_0 Port Collection" }% $ curl -k -u 'root:0penBmc' https://${bmc_ip}/redfish/v1/Fabrics/fabric/Switches/Nvidia_ConnectX_0/Ports/UP_0/ { "@odata.id": "/redfish/v1/Fabrics/fabric/Switches/Nvidia_ConnectX_0/Ports/UP_0", "@odata.type": "#Port.v1_4_0.Port", "ActiveWidth": 8, "CurrentSpeedGbps": 32.0, "Id": "UP_0", "Metrics": { "@odata.id": "/redfish/v1/Fabrics/fabric/Switches/Nvidia_ConnectX_0/Ports/UP_0/Metrics" }, "Name": "Nvidia_ConnectX_0 UP_0 Port", "PortProtocol": "PCIe", "PortType": "UpstreamPort", "Status": { "Health": "OK", "State": "Enabled" } }% ``` [1]: https://redfish.dmtf.org/schemas/v1/Port_v1.xml Change-Id: I52f4ca62b4953f6196c589e340602a0d7885d9c1 Signed-off-by: Harshit Aghera <haghera@nvidia.com>
2026-01-07Enable TCP keepalives for HTTP connectionsJoey Berkovitz1-0/+1
This fix enables TCP keepalives at the OS layer. It also enables a 15 minute deadline timer at the bmcweb level when waiting on an idle HTTP keepalive connection. Tested: romulus image running bmcweb, start connections with keepalive, block incoming connections `iptables -P INPUT DROP`, validate that sockets eventually die and are tracked with keepalives `ss -nto` Change-Id: I8f5040440348c060dae1d0516ec202a0e4dc349e Signed-off-by: Joey Berkovitz <joey@berkovitz.us>
2025-11-25Add temp file and FD support to TemporaryFileHandlerajeeranjan1-0/+1
This commit adds file descriptor and temporary file management to DuplicatableFileHandle, removing the redundant test-only TemporaryFileHandle utility. Changes: - Add file descriptor constructor and setFd() method - Add temporary file constructor with string_view content - Add filePath member and automatic cleanup in destructor - Add configurable temp-dir meson option (default: /tmp/bmcweb) - Remove include/file_test_utilities.hpp - Update all tests to use DuplicatableFileHandle - Rename stringPath to filePath These features will be used by the multipart parser to stream large uploads to temporary files instead of keeping them in memory, and by the update service to pass file descriptors over D-Bus. Change-Id: I982f5928d453f9f0c13d91c3525006134ddc87b3 Signed-off-by: Rajeev Ranjan <ranjan.rajeev1609@gmail.com>
2025-11-21Add Journal EventLog to ManagerOliver Brewka1-0/+1
In order to get access to the EventLog on multi-host platforms, add Journal EventLog to Manager. This implementation is based on the discussion we had on patch 76319 [1]. TLDR: On multi-host, we technically would have to split the event log on a per host node basis, so that each host node has its own specific event log. However, this is currently not supported so we had to decide, whether we put it on a specific ComputerSystem, or refactor the current implementation of the EventLog, to allow for the EventLog LogService to be part of the Managers resource. We chose the latter one, because a), it is not clear on which ComputerSystem to put the EventLog, as long as we aren't splitting the event log per host node, and b), if that particular ComputerSystem is not existing at runtime, there would be no access to the EventLog at all. This feature can be enabled with the redfish-eventlog-location meson option. By default it is set to 'systems', which translates to the EventLog being under the Systems resource. To enable the EventLog under the Managers resource set ``` -Dredfish-eventlog-location=managers ``` This in turn, disables the EventLog under the ComputerSystem resource. Tested: Redfish validation succeeded for both ComputerSystem and Managers tree. ``` curl command: curl -w "@curl-format.txt" -c cjar -b cjar -k -X GET 'https://'"${BMC}"':4443/redfish/v1/'"$ROUTE"'' \ -H 'X-Auth-Token: '"$BMCWEB_SESSION_TOKEN"'' GET /redfish/v1/Managers/bmc/LogServices { "@odata.id": "/redfish/v1/Managers/bmc/LogServices", "@odata.type": "#LogServiceCollection.LogServiceCollection", "Description": "Collection of LogServices for this Manager", "Members": [ { "@odata.id": "/redfish/v1/Managers/bmc/LogServices/Journal" }, { "@odata.id": "/redfish/v1/Managers/bmc/LogServices/EventLog" } ], "Members@odata.count": 2, "Name": "Open BMC Log Services Collection" } GET /redfish/v1/Managers/bmc/LogServices/EventLog { "@odata.id": "/redfish/v1/Managers/bmc/LogServices/EventLog", "@odata.type": "#LogService.v1_2_0.LogService", "Actions": { "#LogService.ClearLog": { "target": "/redfish/v1/Managers/bmc/LogServices/EventLog/Actions/LogService.ClearLog" } }, "DateTime": "2025-09-24T15:22:36+00:00", "DateTimeLocalOffset": "+00:00", "Description": "Manager Event Log Service", "Entries": { "@odata.id": "/redfish/v1/Managers/bmc/LogServices/EventLog/Entries" }, "Id": "EventLog", "Name": "Event Log Service", "OverWritePolicy": "WrapsWhenFull" } GET /redfish/v1/Managers/bmc/LogServices/EventLog/Entries { "@odata.id": "/redfish/v1/Managers/bmc/LogServices/EventLog/Entries", "@odata.type": "#LogEntryCollection.LogEntryCollection", "Description": "Collection of Manager Event Log Entries", "Members": [ { "@odata.id": "/redfish/v1/Managers/bmc/LogServices/EventLog/Entries/1730009576", "@odata.type": "#LogEntry.v1_9_0.LogEntry", "Created": "2024-10-27T06:12:56+00:00", "EntryType": "Event", "Id": "1730009576", "Message": "Host system DC power is off", "MessageArgs": [], "MessageId": "OpenBMC.0.1.DCPowerOff", "Name": "Manager Event Log Entry", "Severity": "OK" }, ... ], "Members@odata.count": 2820, "Members@odata.nextLink": "/redfish/v1/Managers/bmc/LogServices/EventLog/Entries?$skip=1000", "Name": "Manager Event Log Entries" } GET /redfish/v1/Managers/bmc/LogServices/EventLog/Entries/1730009576 { "@odata.id": "/redfish/v1/Managers/bmc/LogServices/EventLog/Entries/1730009576", "@odata.type": "#LogEntry.v1_9_0.LogEntry", "Created": "2024-10-27T06:12:56+00:00", "EntryType": "Event", "Id": "1730009576", "Message": "Host system DC power is off", "MessageArgs": [], "MessageId": "OpenBMC.0.1.DCPowerOff", "Name": "Manager Event Log Entry", "Severity": "OK" } ``` ClearLog action: Log files are being successfully deleted from /var/log [1] https://gerrit.openbmc.org/c/openbmc/bmcweb/+/76319 Change-Id: If5b4fe10151b6bfd28a1b49c41f8cfcec1b9132c Signed-off-by: Oliver Brewka <oliver.brewka@9elements.com>
2025-11-10Remove redfish-use-3-digit-messageidGunnar Mills1-1/+0
redfish-use-3-digit-messageid stated it would be removed in 2Q25, it is now 4Q25. Searching OpenBMC doesn't show any users of this option. This option was added in December 2014 and fixed a bug with us not following the Redfish Spec.[1] [1]: https://gerrit.openbmc.org/c/openbmc/bmcweb/+/76180 Tested: This is a pretty straightforward removal. Inspection and build only. Change-Id: I8a103d42184c21f75db19d44d8004f54d3fae01a Signed-off-by: Gunnar Mills <gmills@us.ibm.com>
2025-10-14Allow configuring userEd Tanous2-2/+28
Add a new option to allow configuring bmcweb to run as a 'bmcweb' user instead of root. This option is disabled by default, and the behavior is very broken at this point, but should serve as a starting point for getting the issues resolved. Tested: Enabled option. Observed with ps, that bmcweb launched correctly, and was running as the bmcweb user. With authentication disabled, passes redfish service validator. Booted without option enabled, and saw bmcweb boot and function. Change-Id: Iac0335697020308bb632f5522b712f5eea0b2486 Signed-off-by: Ed Tanous <etanous@nvidia.com>
2025-10-03Read state directory from systemd fileEd Tanous1-0/+1
Reading the state dir from the systemd service file gives us flexibility to define the bmcweb state from wherever we like, rather than just using the current directory, which might not be writable. Tested: bmcweb boots, shows state is persisted in the same location as previously. Change-Id: I9c048421fe249b73b1cae2ff5204ffd357cd3123 Signed-off-by: Ed Tanous <etanous@nvidia.com>
2025-09-18Systems: Restore old-style LocationIndicatorActiveJanet Adkins1-0/+1
The commit 2eaa927 [1] altered the D-Bus associations used for setting and getting the LED state for the Systems resource. Machines which use entity-manager do not have the new association yet. This commit is adding back the use of the old D-Bus method under a compile option. This will be enabled by default until October 15, 2025 and completely removed by June 2026. [1] https://gerrit.openbmc.org/c/openbmc/bmcweb/+/82078 Tested: - Built with option enabled and confirmed logging showed old method being used. - Built with option disabled and confirmed logging showed new method being used. Change-Id: I271fc464ef512b742a8c85419668aa09d38e525d Signed-off-by: Janet Adkins <janeta@us.ibm.com>
2025-09-18merge binaries bmcweb and bmcwebdAlexander Hansen1-2/+2
Solution to reduce compressed rofs size. Conclusion: The compiler is better at reducing binary size than the rofs compression is at deduplicating sections of already compiled binaries, in the case of bmcweb. What's been changed? `bmcweb` and `bmcwebd` have been merged into `bmcweb`. The webserver can be started with `bmcweb daemon`. Commands used to check size ``` wc -c build/s8030/tmp/work/*-openbmc-linux-gnueabi/obmc-phosphor-image/1.0/obmc-phosphor-image-1.0/static/image-rofs wc -c build/s8030/tmp/deploy/images/s8030/image-rofs xz -c build/s8030/tmp/work/*-openbmc-linux-gnueabi/obmc-phosphor-image/1.0/rootfs/bin/bmcweb | wc -c xz -c build/s8030/tmp/work/*-openbmc-linux-gnueabi/obmc-phosphor-image/1.0/rootfs/usr/libexec/bmcwebd | wc -c ``` Base commit used for testing: `2169e896448fac1b59c57516b381492e4b2161c7` Results: Before patch: ``` image-rofs compressed size: 25526272 build/s8030/tmp/work/s8030-openbmc-linux-gnueabi/obmc-phosphor-image/1.0/obmc-phosphor-image-1.0/static/image-rofs rootfs 25526272 build/s8030/tmp/deploy/images/s8030/image-rofs bmcweb cli 95424 bmcwebd 1016004 ``` After patch: ``` image-rofs compressed size: 25477120 build/s8030/tmp/work/s8030-openbmc-linux-gnueabi/obmc-phosphor-image/1.0/obmc-phosphor-image-1.0/static/image-rofs rootfs 25477120 build/s8030/tmp/deploy/images/s8030/image-rofs bmcweb cli 96 bmcwebd 1059556 ``` Calculating the difference in compressed rofs 25526272 - 25477120 = 49152 which is around 0.2% in terms of the total image but around 4.6% in terms of bmcwebd binary. Tested: on yosemite4 qemu `bmcweb` cli interactions work as before. ``` root@yosemite4:~# bmcweb --help BMCWeb CLI Usage: bmcweb [OPTIONS] SUBCOMMAND Options: -h,--help Print this help message and exit Subcommands: loglevel Set bmcweb log level daemon Run webserver root@yosemite4:~# bmcweb loglevel info <6>[webserver_cli.cpp:97] logging level changed to: INFO root@yosemite4:~# bmcweb loglevel level is required Run with --help for more information. root@yosemite4:~# bmcweb loglevel debug <6>[webserver_cli.cpp:97] logging level changed to: DEBUG ``` systemd service still working ``` root@yosemite4:~# systemctl status bmcweb ● bmcweb.service - Start bmcweb server Loaded: loaded (/usr/lib/systemd/system/bmcweb.service; enabled; preset: enabled) Active: active (running) since Thu 2025-04-03 13:35:45 PDT; 5 months 15 days ago ``` Change-Id: Ib5dde568ac1c12c5414294ed96404c6a69417424 Signed-off-by: Alexander Hansen <alexander.hansen@9elements.com>
2025-08-26Fix runtime error when add `additional-ports` configurationThu Nguyen1-2/+2
The bmcweb has runtime errors when adding `additional-ports` configuration. ```text Dec 19 21:25:54 board systemd[1]: sockets.target: Wants dependency dropin /etc/systemd/system/sockets.target.wants/bmcweb_440 is not a valid unit name, ignoring. ``` and ```text Dec 19 21:25:54 board systemd[1]: bmcweb_440.socket: Unit has no Listen setting (ListenStream=, ListenDatagram=, ListenFIFO=, ...). Refusing. Dec 19 21:25:54 board systemd[1]: bmcweb_440.socket: Cannot add dependency job, ignoring: Unit bmcweb_440.socket has a bad unit file setting. ``` Update the code to fix that. Change-Id: I792b9fdf29df40137fdbc7418b140e8445080961 Signed-off-by: Thu Nguyen <thu@os.amperecomputing.com>
2025-08-21IndicatorLED: Add compile option for deprecated propertyJanet Adkins1-0/+1
The IndicatorLED property has been deprecated by Redfish since September 2020. The Redfish Service Validator reports a WARNING for this property: ``` WARNING - IndicatorLED: The given property is deprecated: This property has been deprecated in favor of the `LocationIndicatorActive` property. ``` The LocationIndicatorActive property is now implemented in bmcweb in all places where IndicatorLED was implemented. So a new meson option (redfish-allow-deprecated-indicatorled) is being added to control whether this property is part of get or patch requests. The option is disabled by default with plans to remove the option by March 2026. Tested: - Built with option enabled and confirmed IndicatorLED still part of Redfish responses and can be patched. - Built with option disabled and confirmed Redfish Service Validator no longer reports the warning. - Built with option disabled and confirmed IndicatorLED no longer part of Redfish responses and patch fails appropriately. ``` curl -k -H "X-Auth-Token: $token" -H "Content-Type: application/json" -X PATCH -d '{"IndicatorLED":"Blinking"}' https://${bmc}/redfish/v1/Systems/system { "error": { "@Message.ExtendedInfo": [ { "@odata.type": "#Message.v1_1_1.Message", "Message": "The property IndicatorLED is not in the list of valid properties for the resource.", "MessageArgs": [ "IndicatorLED" ], "MessageId": "Base.1.19.PropertyUnknown", "MessageSeverity": "Warning", "Resolution": "Remove the unknown property from the request body and resubmit the request if the operation failed." } ], "code": "Base.1.19.PropertyUnknown", "message": "The property IndicatorLED is not in the list of valid properties for the resource." } } curl -k -H "X-Auth-Token: $token" -H "Content-Type: application/json" -X PATCH -d '{"IndicatorLED":"Off"}' https://${bmc}/redfish/v1/Chassis/chassis { "error": { "@Message.ExtendedInfo": [ { "@odata.type": "#Message.v1_1_1.Message", "Message": "The property IndicatorLED is not in the list of valid properties for the resource.", "MessageArgs": [ "IndicatorLED" ], "MessageId": "Base.1.19.PropertyUnknown", "MessageSeverity": "Warning", "Resolution": "Remove the unknown property from the request body and resubmit the request if the operation failed." } ], "code": "Base.1.19.PropertyUnknown", "message": "The property IndicatorLED is not in the list of valid properties for the resource." } } ``` Change-Id: I2c0d415a7a54aa3122b18d2a1aa69bd9259d567e Signed-off-by: Janet Adkins <janeta@us.ibm.com>
2025-07-14Implement zstd decompressionEd Tanous1-0/+1
Given the size of Redfish schemas these days, it would be nice to be able to store them on disk in a zstd format. Unfortunately, not all clients support zstd at this time. This commit implements reading of zstd files from disk, as well as decompressing zstd in the case where the client does not support zstd as a return type. Tested: Implanted an artificial zstd file into the system, and observed correct decompression both with an allow-encoding header of empty string and zstd. Change-Id: I8b631bb943de99002fdd6745340aec010ee591ff Signed-off-by: Ed Tanous <etanous@nvidia.com>
2025-07-09Move http2 out of experimentalEd Tanous1-1/+1
Http2 support in bmcweb has been relatively stable for a while. The http2 implementation passes all known Redfish tests (some of which require ported to httpx to support http2), the UI loads, and so far as the project is concerned, is a complete improvement over the existing http1 stack. This commit removes the experimental classification from http2, and declares it ready for production use, while enabling it by default. note, that enabling this by default only makes the server advertise that http2 is available. Http2 must still be supported by the client to enable ALPN negotiation, so existing http1 clients that only support http1 will continue to function as they did before. Tested: Enabled http option and saw http2 advertised, http2 now takes effect. Change-Id: I92843a3afc532f0b2a64904bb872e5d84a1a54fe Signed-off-by: Ed Tanous <etanous@nvidia.com>
2025-06-04remove meta-tls-common-name-parsing flagMalik Akbar Hashemi Rafsanjani1-1/+0
as we remove all `meta-tls-common-name-parsing` usages from all references in openbmc and bmcweb repos, we can safely remove `meta-tls-common-name-parsing` flag. This flag was intended to be a flag to enable meta/facebook specific auth parse mode. As meta/facebook have migrated our implementation into using UPN field, we can safely remove all codes related to meta/facebook specific auth parse mode, including this flag Tested - build bmcweb binary - deploy to a device that already use UPN parse mode - check if it works fine by sending curl, eg: to /AccountService Change-Id: Iabffcee177b3c48da90eba97e2a84a8d5a9f57d2 Signed-off-by: Malik Akbar Hashemi Rafsanjani <malikrafsan@meta.com>
2025-04-16Fix watchdog timeout variableRoger G. Coscojuela2-2/+4
The meson option to define the watchdog timeout was written in different places with different names, resulting in the service file not having the configured timeout, and the bmcweb daemon not displaying the warning when the watchdog was disabled at runtime, but enabled at compile time. Tested: - After building, the systemd service file contains the configured timeout - If the watchdog is disabled during runtime, the message is displayed properly Change-Id: I21d23b02bc13e21a516f04527dbda5b4ec0659f1 Signed-off-by: Roger G. Coscojuela <roger.gili-coscojuela@sipearl.com>
2025-03-18Clean up meson summaryEd Tanous1-17/+35
Make the meson summary better by: Adding new sections for each value type (this implicitly sorts each section, making the pattern more clear) Remove the generated messon message, where we print the values of ifdefs. Enable bool_yn for feature options, which allows us to pass the feature in directly, and print and colorize yes/no answers Tested: meson setup builddir Results in no messages printed for the ifdefs, and colorized output, with yes/no answers, summarized below. Feature Options basic-auth : YES String Options dns-resolver : systemd-dbus Numeric Options http-body-limit : 30 Change-Id: I13f003846edaa355090c14113b61aacb05cbeb9a Signed-off-by: Ed Tanous <etanous@nvidia.com>
2025-03-17Add support for systemd service watchdogrohitpai2-2/+6
Systemd has support for enabling service level watchdog. The MR enables this support for bmcweb daemon. Request for watchdog monitor from systemd is added in bmcweb.service.in. From the event loop a timer is registered to kick the watchdog periodically The default watchdog timeout is set at 120 seconds and the timer is set to kick it at a quarter of the interval (every 30 seconds). This timeout is set somewhat arbitrarily based on the longest blocking call that could occur and still give a valid HTTP response. Suspect lower values could work equally as well. Benefits of Service Watchdog - Bmcweb route handlers should not make any blocking IO calls which block the event loop for considerable amount of time and slowdown the response of other URI requests in the queue. Watchdog can help to detect such issues. - Watchdog can help restart the service if any route handler code has uncaught bugs resulting from system API errors (this is in theory, currently we don't have any use case). Tested 1. UT is passing 2. Service validator is passing 3. Fw upgrade POST requests are working Change-Id: If62397d8836c942fdcbc0618810fe82a8b248df8 Signed-off-by: rohitpai <ropai@nvidia.com> Signed-off-by: Ed Tanous <etanous@nvidia.com>
2025-02-25Sort the config listEd Tanous1-3/+3
Keep the list sorted. Change-Id: I208ee3b388dc48b52c15d7ff6534e1f0af300bbf Signed-off-by: Ed Tanous <etanous@nvidia.com>
2025-02-23Enable port 18080Janet Adkins1-6/+6
The commit [1] altered how sockets are created and inadvertently removed the default port 18080. We use this port extensively in development. The bmcweb documentation describes the port 18080 for this use. [2] Adding back the default port 18080. The commit [1] added meson build options for adding additional ports. In attempting to enable port 18080 using that mechanism I ran into various build errors when additional-ports has a value. I've corrected the config/meson.build file to address those errors. These changes are not necessary to re-enable port 18080 but worth fixing anyway. Note: Meson defines arrays as containing strings so there is no to_string() method for the array member. [3] ``` ../../../../../../workspace/sources/bmcweb/config/meson.build:137:39: ERROR: Unknown method "to_string" in object <[StringHolder] holds [str]: '18080'> of type StringHolder. ``` Tested: - Started bmcweb from /tmp and was able to connect through port 18080. Log shows: ``` [DEBUG app.hpp:111] Got 0 sockets to open [INFO app.hpp:150] Starting webserver on port 18080 ``` [1] https://gerrit.openbmc.org/c/openbmc/bmcweb/+/35265 [2] https://github.com/openbmc/bmcweb/blob/cc67d0a0fed101c930b334a583d9ca9b222ceb77/TESTING.md?plain=1#L57 [3] https://mesonbuild.com/Build-options.html#arrays Change-Id: Ia1b326bedca808e43e73ce2b241178bc4bfab23c Signed-off-by: Janet Adkins <janeta@us.ibm.com> Signed-off-by: Ed Tanous <etanous@nvidia.com>
2025-02-17Use systemd logging levelsEd Tanous1-0/+1
Systemd has an option[1] that allows it to interpret our log levels directly. This allows for journald to sort/filter/colorize our logs better than it was able to previously. Its indexes don't map perfectly to bmcwebs, so come up with a constexpr lookup table to map the two values across. Tested: Enabled logging, and dumped journal logs. Observed colorized output. [1] https://www.freedesktop.org/software/systemd/man/latest/systemd.exec.html#SyslogLevelPrefix= Change-Id: I7722ae86e114daec88709b68405498eeb8164c07 Signed-off-by: Ed Tanous <etanous@nvidia.com>
2025-02-10Enable HTTP additional socketsEd Tanous2-10/+53
This commit attempts to add the concept of an SSL detector from beast, and add the capability into bmcweb. This allows directing multiple socket files to the bmcweb instance, and bmcweb will automatically sort out whether or not they're SSL, and give the correct response. This allows users to plug in erroneous urls like "https://mybmc:80" and they will forward and work correctly. Some key design points: The HTTP side of bmcweb implements the exact same http headers as the HTTPS side, with the exception of HSTS, which is explicitly disallowed. This is for consistency and security. The above allows bmcweb builds to "select" the appropriate security posture (http, https, or both) for a given channel using the FileDescriptorName field within a socket file. Items ending in: both: Will support both HTTPS and HTTP redirect to HTTPS https: Will support HTTPS only http: will support HTTP only Given the flexibility in bind statements, this allows administrators to support essentially any security posture they like. The openbmc defaults are: HTTPS + Redirect on both ports 443 and port 80 if http-redirect is enabled And HTTPS only if http-redirect is disabled. This commit adds the following meson options that each take an array of strings, indexex on the port. additional-ports Adds additional ports that bmcweb should listen to. This is always required when adding new ports. additional-protocol Specifies 'http', 'https', or 'both' for whether or not tls is enfoced on this socket. 'both' allows bmcweb to detect whether a user has specified tls or not on a given connection and give the correct response. additional-bind-to-device Accepts values that fill the SO_BINDTODEVICE flag in systemd/linux, and allows binding to a specific device additional-auth Accepts values of 'auth' or 'noauth' that determines whether this socket should apply the normal authentication routines, or treat the socket as unauthenticated. Tested: Previous commits ran the below tests. Ran the server with options enabled. Tried: ``` curl -vvvv --insecure --user root:0penBmc http://192.168.7.2/redfish/v1/Managers/bmc * Trying 192.168.7.2:80... * Connected to 192.168.7.2 (192.168.7.2) port 80 (#0) * Server auth using Basic with user 'root' > GET /redfish/v1/Managers/bmc HTTP/1.1 > Host: 192.168.7.2 > Authorization: Basic cm9vdDowcGVuQm1j > User-Agent: curl/7.72.0 > Accept: */* > * Mark bundle as not supporting multiuse < HTTP/1.1 301 Moved Permanently < Location: https://192.168.7.2 < X-Frame-Options: DENY < Pragma: no-cache < Cache-Control: no-Store,no-Cache < X-XSS-Protection: 1; mode=block < X-Content-Type-Options: nosniff < Content-Security-Policy: default-src 'none'; img-src 'self' data:; font-src 'self'; style-src 'self'; script-src 'self'; connect-src 'self' wss: < Date: Fri, 08 Jan 2021 01:43:49 GMT < Connection: close < Content-Length: 0 < * Closing connection 0 ``` Observe above: webserver returned 301 redirect. webserver returned the appropriate security headers webserver immediately closed the connection. The same test above over https:// returns the values as expected Loaded the webui to test static file hosting. Webui logs in and works as expected. Used the scripts/websocket_test.py to verify that websockets work. Sensors report as expected. Change-Id: Ib5733bbe5473fed6e0e27c56cdead0bffedf2993 Signed-off-by: Ed Tanous <ed@tanous.net>
2024-12-11Put simple update behind an optionEd Tanous1-0/+1
4e338b2313f9f2a91aa1fb36693e36a328d58933 Removed tftp update support from the codebase, but left SimpleUpdate in a non functional state. Given that a number of forks have implemented the HTTPS/SCP versions of simple update, we don't want to fully delete the code at this time, so for the moment put it behind an option flag. Tested: WIP Change-Id: Ibab1e3a48ff640787eabf8ed5f7a5c08e3381307 Signed-off-by: Ed Tanous <etanous@nvidia.com>
2024-12-10Make message registries use 2 digit versionsEd Tanous1-0/+1
Redfish specification, section 9.5.11.2 says: The MessageId property value shall be in the format: <MessageRegistryPrefix>.<MajorVersion>.<MinorVersion>.<MessageKey> bmcweb in certain places has incorrectly used the 3 digit version instead of the 2 digit version. This commit fixes that by modifying the parse_registries script to generate 3 separate struct entries to represent the registry version, and parse them where appropriate. MessageRegistryFileCollection uses the 3 digit version. No behavior changes. Message/event log entries use the 2 digit version. This will cause a MessageId change from: Base.1.19.0.InternalError to Base.1.19.InternalError This is a breaking change, so a new option to allow the old behavior is provided. Tested: Redfish Service validator passes. Heartbeat events on EventService show 2 digit versions. Change-Id: I4165e994f73e200f13bed8ea76cb58bee2b69faa Signed-off-by: Ed Tanous <etanous@nvidia.com>
2024-11-27event service: dbus log: enable event subscriptionAlexander Hansen1-0/+1
enable the event subscriptions /redfish/v1/EventService/Subscriptions/ to work for the dbus event log. So if you are enabling redfish-dbus-log option, event subscriptions should work similar to when this option is disabled, with one difference: - 'MessageArgs' property is currently not implemented and cannot be found in the returned json. Tested: - Using Redfish Event Listener, test subscriptions and eventing. - Manual Test below with the Redfish Event Listener: 1. Created a maximal Event Log Subscription redfish { "@odata.id": "/redfish/v1/EventService/Subscriptions/2023893979", "@odata.type": "#EventDestination.v1_8_0.EventDestination", "Context": "EventLogSubscription", "DeliveryRetryPolicy": "TerminateAfterRetries", "Destination": "http://${ip}:5000/event-receiver", "EventFormatType": "Event", "HttpHeaders": [], "Id": "2023893979", "MessageIds": [], "MetricReportDefinitions": [], "Name": "Event Destination 2023893979", "Protocol": "Redfish", "RegistryPrefixes": [], "ResourceTypes": [], "SubscriptionType": "RedfishEvent", "VerifyCertificate": true } which matches on all registries and all message ids. 2. created a new phosphor-logging entry busctl call xyz.openbmc_project.Logging \ /xyz/openbmc_project/logging \ xyz.openbmc_project.Logging.Create \ Create 'ssa{ss}' \ OpenBMC.0.1.PowerButtonPressed \ xyz.openbmc_project.Logging.Entry.Level.Error 0 3. bmcweb picks up this new entry via the dbus match, this can be verified by putting bmcweb in debug logging mode. 4. the event log entry makes it through the filtering code 5. the POST request is sent to the subscribed server as expected, and contains the same properties as with the file-based backend. Change-Id: I122e1121389f72e67a998706aeadd052ae607d60 Signed-off-by: Alexander Hansen <alexander.hansen@9elements.com>
2024-08-26Reformat meson files with meson formatEd Tanous1-14/+8
Meson recently got a new format command in 1.5.0 [1]. It makes slightly different formatting decisions compared to muon (what we used previously) but given it's the official tool, we should switch to it. There is one bug resolved recently that requires this format be done using the meson from master. Ideally this would be enforced by CI in the future, but that's WIP. Tested: Whitespace only, code compiles. [1] https://mesonbuild.com/Commands.html#format [2] https://github.com/mesonbuild/meson/commit/df706807239095ddbbfd2975b3fe067ad6b5d535 Change-Id: I91506efb659c431e913c717d8a26aa349fccbd75 Signed-off-by: Ed Tanous <etanous@nvidia.com>
2024-08-23Enable bmcweb dynamic loggingAushim Nagarkatti2-3/+3
Create a CLI app called "bmcweb" that can set logging levels on "bmcwebd", the new bmcweb daemon. Create a dbus connection to set log level using the CLI app Define the "setLogLevel" method on dbus to control logging level in bmcwebd Add logic to move logging level from build option to dynamic overloading Reason: bmcweb picks up logging level as a compile flag. We want it to be more flexible to debug errors in the field. Using the bmcweb CLI app, we can set log levels on the bmcweb daemon during runtime. Splitting bmcweb. For example, to set logging level to INFO on the target: bmcweb -l INFO Change-Id: I7192e4d0ac7aa3a91babecc473521be27ea8acd1 Signed-off-by: Aushim Nagarkatti <anagarkatti@nvidia.com>
2024-08-21Add a Hypervisor Computer System OptionGunnar Mills1-0/+1
Today to determine if the hypervisor computer system resource should be added to the System Collection a call to the Settings Manager is made. Based on discussion in https://gerrit.openbmc.org/c/openbmc/bmcweb/+/73203 and to help the multihost stuff move forward, lets move this hypervisor under a meson option which any company that needs can enable. I think IBM is the only one who uses this so the risk of breaking someone should be small. One day hope to converge at some point, this probably doesn't happen until after the multihost stuff goes in. This is also better for implementations that don't have this backend because now routes like /redfish/v1/Systems/hypervisor/EthernetInterfaces/ aren't put out. I.e. a call to /redfish/v1/Systems/hypervisor/EthernetInterfaces/ is now going to return 404 instead of 500 on systems without this backend support. Tested: Enabled this and see the hypervisor system. Without this enabled do not see the hypervisor system. No new validator errors either way. Change-Id: Ie05e6644dd6f640cf8225f96becb99b9c2d0de20 Signed-off-by: Gunnar Mills <gmills@us.ibm.com>
2024-08-09update service: remove tftp simple update flowJagpal Singh Gill1-1/+0
Remove the flow for tftp simple update as this is an insecure method and there is no active user for this. Redfish service validator passing: ``` Elapsed time: 0:04:33 metadataNamespaces: 3727 pass: 5184 passAction: 16 passGet: 213 passRedfishUri: 205 skipNoSchema: 3 skipOptional: 3535 unvalidated: 1 warnDeprecated: 5 warningPresent: 6 ``` Change-Id: I466dcb09be4ee806451abe91ab86d8b3b001a333 Signed-off-by: Jagpal Singh Gill <paligill@gmail.com>
2024-07-11Mutual TLS parsing change at runtimeEd Tanous1-1/+2
Redfish AccountService[1] defines methods for selecting how to map a certificate CommonName attribute to a user. These are intended to be a patch parameter. This commit implements the Redfish defined schemas; The parsing mode is stored in the bmcweb persistent configuration file as an integer enum, with Mapping to the Redfish schema. To handle OEM specific parsing modes, an enum value of 100+ is defined to allow the additional OEM parameters. Unfortunately, Redfish doesn't have a way to represent these today, so those modes are currently not selectable at runtime. Now that things are runtime selectable, this obsoletes the option mutual-tls-common-name-parsing, as it is not longer required at compile time. Tested: GET /redfish/v1/AccountService returns MultiFactorAuth/ClientCertificate/CertificateMappingAttribute PATCH /redfish/v1/AccountService ``` {"MultiFactorAuth": {"ClientCertificate": {"CertificateMappingAttribute":"CommonName"}}} ``` Returns 200 [1] https://github.com/DMTF/Redfish-Publications/blob/5b217908b5378b24e4f390c063427d7a707cd308/csdl/AccountService_v1.xml#L1631 Change-Id: I67db0dfa5245a9da973320aab666d12dbd9229e4 Signed-off-by: Ed Tanous <ed@tanous.net>
2024-05-21Allow configuring "bmc" and "system"Ed Tanous1-0/+2
In the early days of bmcweb, we made two pretty critical assumptions; First, is that a given platform would only have a single BMC instance (represented as "bmc") and a single host instance (represented as "system"). Second we assumed that, given that Redfish suggests against hardcoding URIs in client implementation and leaves them freeform, clients would code to the standard. Our own webui-vue hardcodes Redfish URIs [1], and the documentation is littered with examples of hardcoded curl examples of hardcoding these URIs. That bug was filed in 2020, and the issue has only gotten worse over time. This patchset is an attempt to give a target that we can start solving these issues, without trying to boil the ocean and fix all clients in parallel. This commit adds the meson options redfish-manager-uri-name and redfish-system-uri-name These are used to control the "name" that bmcweb places in the fixed locations in the ManagerCollection and ComputerSystemCollection schemas. Note, managers is added, but is not currently testable. It will be iterated on over time. Tested: Changed the URL options to "edsbmc" and "edssystem" in meson options. Redfish service validator passes. URLs appear changed when walking the tree. [1] https://github.com/openbmc/webui-vue/issues/43 Change-Id: I4b44685067051512bd065da8c2e3db68ae5ce23a Signed-off-by: Ed Tanous <ed@tanous.net>
2024-05-20Remove options from configure fileEd Tanous3-66/+27
Ideally, we should only have to declare meson options in one place, in the meson_options.txt, and have all files generate from that list. This patchset gets us one step closer, where we have to list options in 2 places, whereas previously it was 3. Tested: Code compiles. Manual inspection of generated bmcweb_config.h shows only minor differences in generated file. Change-Id: I4a4f863c95463e3cdf8b629de5a0a73f74cf001e Signed-off-by: Ed Tanous <ed@tanous.net>
2024-05-03updateservice: add start-update meson optionJagpal Singh Gill2-0/+2
Add the meson option for the start-update D-Bus interface feature to be used in UpdateService. More more details refer to - https://gerrit.openbmc.org/c/openbmc/phosphor-dbus-interfaces/+/65738 https://gerrit.openbmc.org/c/openbmc/docs/+/65739 Tested: Build passes. Change-Id: I594ddc0d2df6c032823eaeba9429cf50047d5dcd Signed-off-by: Jagpal Singh Gill <paligill@gmail.com>
2024-05-01Bring consistency to config optionsEd Tanous2-46/+118
The configuration options that exist in bmcweb are an amalgimation of CROW options, CMAKE options using #define, pre-bmcweb ifdef mechanisms and meson options using a config file. This history has led to a lot of different ways to configure code in the codebase itself, which has led to problems, and issues in consistency. ifdef options do no compile time checking of code not within the branch. This is good when you have optional dependencies, but not great when you're trying to ensure both options compile. This commit moves all internal configuration options to: 1. A namespace called bmcweb 2. A naming scheme matching the meson option. hyphens are replaced with underscores, and the option is uppercased. This consistent transform allows matching up option keys with their code counterparts, without naming changes. 3. All options are bool true = enabled, and any options with _ENABLED or _DISABLED postfixes have those postfixes removed. (note, there are still some options with disable in the name, those are left as-is) 4. All options are now constexpr booleans, without an explicit compare. To accomplish this, unfortunately an option list in config/meson.build is required, given that meson doesn't provide a way to dump all options, as is a manual entry in bmcweb_config.h.in, in addition to the meson_options. This obsoletes the map in the main meson.build, which helps some of the complexity. Now that we've done this, we have some rules that will be documented. 1. Runtime behavior changes should be added as a constexpr bool to bmcweb_config.h 2. Options that require optionally pulling in a dependency shall use an ifdef, defined in the primary meson.build. (note, there are no options that currently meet this class, but it's included for completeness.) Note, that this consolidation means that at configure time, all options are printed. This is a good thing and allows direct comparison of configs in log files. Tested: Code compiles Server boots, and shows options configured in the default build. (HTTPS, log level, etc) Change-Id: I94e79a56bcdc01755036e4e7278c7e69e25809ce Signed-off-by: Ed Tanous <ed@tanous.net>
2024-04-30Consolidate Vm implementationsEd Tanous2-0/+8
As much as the two vm implementations SEEM different, the differences largely lie in how we're getting the nbd proxy socket. One is relying on launching a process (nbd-proxy), the other is getting the fd from dbus. Given [1] exists and is in process, we need to have a plan for getting these two VM implementations into one, once that patchset is complete. This commit: Splits the vm-websocket option into vm-websocket-provider, providing two options, nbd-proxy, and virtual-media (the names of the respective apps). To accomplish this, it moves the contents of nbd-proxy into include/vm-websocket, so we can compare the similarities and start consolidating. The longer term intent is that the nbd-proxy option will be completely removed, and the code deleted. This has the additional advantage that we will no longer require the boost::process dependency, as all info will be available on dbus. As part of this, the nbd proxy websocket is also registered at /vm/0/0, to be backward compatible with the old interfaces. Tested: Code compiles. Need some help here. [1] https://gerrit.openbmc.org/c/openbmc/jsnbd/+/49944 Change-Id: Iedbca169ea40d45a8775f843792b874a248bb594 Signed-off-by: Ed Tanous <ed@tanous.net>
2024-04-23Remove XSS prevention codeEd Tanous2-5/+0
This feature was created for a time before webpack had a built in proxy, and to debug the UI required setting specific flags. The webpack proxy solves this problem in a much better way, by proxying everything. This commit is one piece in the solving a use after free bug. Removing this allows us to no longer have to cache the origin header [1], which is only used in this mode. Tested: Code compiles. [1] https://gerrit.openbmc.org/c/openbmc/bmcweb/+/70850 Change-Id: I01d67006e217c0c9fd2db7526c0ec34b0da068f3 Signed-off-by: Ed Tanous <ed@tanous.net>
2024-04-18Clean up BMCWEB_ENABLE_SSLEd Tanous2-0/+6
This macro came originally from CROW_ENABLE_SSL, and was used as a macro to optionally compile without openssl being required. OpenSSL has been pulled into many other dependencies, and has been functionally required to be included for a long time, so there's no reason to hold onto this macro. Remove most uses of the macro, and for the couple functional places the macro is used, transition to a constexpr if to enable the TLS paths. This allows a large simplification of code in some places. Tested: Redfish service validator passes. Change-Id: Iebd46a68e5e417b6031479e24be3c21bef782f4c Signed-off-by: Ed Tanous <ed@tanous.net>
2024-04-17Reformat meson filesEd Tanous1-20/+29
Meson has a style guide, we should follow it. This includes: 4 space indents on new scopes. Trailing commas on the final entry in a list/array Tested: Whitespace only. Code compiles. Change-Id: Ib7f96a2bd722b55410818c766c0261f5d44cb84d Signed-off-by: Ed Tanous <ed@tanous.net>
2024-04-04Remove redfish-health-populateGunnar Mills2-4/+0
The redfish-health-populate option was scheduled to be removed in 1Q 2024. It is now 2Q, so remove the option. No upstream layers enabled it and did not find a downstream layer that did either. This was always limited to a few resources. Overall this design was only half done. A future "HealthRollup" can be proposed. Some discord discussion: [1]: https://discord.com/channels/775381525260664832/855566794994221117/1110728560819327069 Commit disabling this (merged 10 months ago): [2]: https://github.com/openbmc/bmcweb/commit/6f8273e49cffdd347c223b9538558edfb05e818a Tested: Code compiles Change-Id: I4d33c1e674ecdb0fd256df62f3795073454ae7a1 Signed-off-by: Gunnar Mills <gmills@us.ibm.com>
2024-04-02Remove redfish-enable-proccessor-memory-statusGunnar Mills2-4/+0
The redfish-enable-proccessor-memory-status option was scheduled to be removed in 1Q 2024. It is now 2Q, so remove the option. No upstream layers enabled it and I could not find a downstream layer that did either. Redfish deprecated the Processor/Memory Summary Status (state, health, healthrollup) attributes. Discussion on discord, when disabling: [1]: https://discord.com/channels/775381525260664832/855566794994221117/1093939076710793296 Commit disabling this (merged 10 months ago): [2]: https://github.com/openbmc/bmcweb/commit/5fd0aafb0f14fb3011970e8575647bb608688c7c Tested: Code builds. Change-Id: I539cd5f384633afa7badf1cecfc6c7a87062f672 Signed-off-by: Gunnar Mills <gmills@us.ibm.com>
2023-12-09mutual-tls: Add support for Meta certificatesMarco Kawajiri2-1/+4
Meta Inc's client certificates use an internal Subject CN format which AFAIK is specific to Meta and don't adhere to a known standard: Subject: CN = <type>:<entity>/<hostname> Commit adds the `mutual-tls-common-name-parsing=meta` option to, on Meta builds, parse the Subject CN field and map either the <entity> to a local user. The <type> field determines what kind of client identity the cert represents. Only type="user" is supported for now with <entity> being the unixname of a Meta employee. For example, the Subject CN string below maps to a local BMC user named "kawmarco": Subject CN = "user:kawmarco/dev123.facebook.com" Tested: Unit tests, built and tested on romulus using the script below: https://gist.github.com/kawmarco/87170a8250020023d913ed5f7ed5c01f Flags used in meta-ibm/meta-romulus/conf/layer.conf : ``` -Dbmcweb-logging='enabled' -Dmutual-tls-common-name-parsing='meta' ``` Change-Id: I35ee9b92d163ce56815a5bd9cce5296ba1a44eef Signed-off-by: Marco Kawajiri <kawajiri@meta.com>
2023-11-29build: use allowed over enabledPatrick Williams1-8/+8
Meson feature options are typically in a tri-state of enabled, disabled, or auto. The enabled and disabled functions on an option (from `get_option`) no longer return true for auto features. Instead, the expectation is to use `allowed()` which is true for both enabled and auto. Switch all uses of `enabled` to `allowed`. Change-Id: Ia40b13fdce7af88085cf23a4a87d9be939edd1e3 Signed-off-by: Patrick Williams <patrick@stwcx.xyz>
2023-07-27Fix loggingEd Tanous1-0/+1
The recent change to logging has caused a couple of bugs. First, when building within yocto, the complete path is now returned on log messages. This is wasteful of speed, and not super helpful to developers to have a full path. Per the discussion on the original patchset, drop this down to just the filename. 2, because of it's use as a pseudo log level, "enabled" is in the list of strings. This causes an index mismatch, which causes logs to be logged at the wrong level beyond debug. Move the entry to the end to fix this. Third, move the logging of level to upper case, to follow the old convention. Tested: Enabled meson option for logging, observed logs like: ``` Jul 25 18:39:20 qemux86-64 bmcweb[209]: [DEBUG query.hpp:121] setup redfish route Jul 25 18:39:20 qemux86-64 bmcweb[209]: [DEBUG http_response.hpp:248] 0x561bc11a7a40 releasing ce Jul 25 18:39:20 qemux86-64 bmcweb[209]: [DEBUG http_response.hpp:238] 0x561bc11a7a40 setting comr Jul 25 18:39:20 qemux86-64 bmcweb[209]: [DEBUG http_response.hpp:223] 0x561bc11a7a40 calling comr Jul 25 18:39:20 qemux86-64 bmcweb[209]: [DEBUG http_response.hpp:226] 0x561bc11a7a40 completion d Jul 25 18:39:20 qemux86-64 bmcweb[209]: [DEBUG query_param.hpp:1019] Processing query params ``` Change-Id: I4ac506c623a17f81ae83545e59291d2729dc82cb Signed-off-by: Ed Tanous <edtanous@google.com>
2023-06-28HTTP/2 supportEd Tanous2-0/+4
HTTP/2 gives a number of optimizations, while keeping support for the protocol. HTTP/2 support was recently added to the Redfish specification. The largest performance increase in bmc usage is likely header compression. Almost all requests reuse the same header values, so the hpack based compression scheme in HTTP/2 allows OpenBMC to be more efficient as a transport, and has the potential to significantly reduce the number of bytes we're sending on the wire. This commit adds HTTP2 support to bmcweb through nghttp2 library. When static linked into bmcweb, this support adds 53.4KB to the bmcweb binary size. nghttp2 is available in meta-oe already. Given the experimental nature of this option, it is added under the meson option "experimental-http2" and disabled by default. The hope is to enable it at some point in the future. To accomplish the above, there a new class, HTTP2Connection is created. This is intended to isolate HTTP/2 connections code from HttpConnection such that it is far less likely to cause bugs, although it does duplicate about 20 lines of code (async_read_some, async_write_some, buffers, etc). This seems worth it for the moment. In a similar way to Websockets, when an HTTP/2 connection is detected through ALPN, the HTTP2Connection class will be instantiated, and the socket object passed to it, thus allowing the Connection class to be destroyed, and the HTTP2Connection to take over for the user. Tested: Redfish service validator passes with option enabled With option disabled GET /redfish/v1 in curl shows ALPN non negotiation, and fallback to http1.1 With the option enable GET /redfish/v1 in curl shows ALPN negotiates to HTTP2 Change-Id: I7839e457e0ba918b0695e04babddd0925ed3383c Signed-off-by: Ed Tanous <edtanous@google.com>
2023-06-21Add an option flag for multi-computersystemEd Tanous2-0/+4
A number of discussions have occurred, and it's clear that multi-computer system is not a transition that can be done in a single series of commits, and needs to be done incrementally over time. This commit adds the initial option for multi-computer system support, with an option flag that can be enabled when the new behavior is desired. This is to prevent needing a long-lived fork. This option operatates such that if enabled, all ComputerSystem route options will now return 404. This is to allow the redfish service validator to pass, and to be used for incremental development. As the routes are moved over, they will be enabled, and service validator re-run. Per the description in the meson options, this option flag, and all code beneath of it will be removed on 9/1/23. The expectation is that by this date, given the appropriate level of effort in implementation, there will be no code remaining under that option flag. After this date, code beneath this option flag will be removed. Tested: No functional changes without option. With option enabled, /redfish/v1/Systems produces no entries. Spot check of various routes returns 404. Redfish service validator passes. Change-Id: I3b58642cb76d61df668076c2e0f1e7bed110ae25 Signed-off-by: Ed Tanous <ed@tanous.net>
2023-06-13Remove 2nd get_option('https_port')Gunnar Mills1-1/+0
https://github.com/openbmc/bmcweb/commit/13451e3913c29bb380ef6778f11749d337ddd442 added this. I think just a mistake. Noticed this while reviewing https://gerrit.openbmc.org/c/openbmc/bmcweb/+/40978/23/config/meson.build#24 Tested: None. Confirmed via find these lines are the exact same. Change-Id: I40ec3e7f27ef0cbdc1afd6ba2daad637f1041d11 Signed-off-by: Gunnar Mills <gmills@us.ibm.com>
2023-06-06Fix meson warningEd Tanous1-5/+5
NOTICE: Future-deprecated features used: * 0.64.0: {'copy arg in configure_file'} Port to the new version of this, which is install_data. Tested: Meson configure no longer throws the above warning. Signed-off-by: Ed Tanous <edtanous@google.com> Change-Id: I9c4d91c3c45bc52dde69ca34d7fc686e2e6c0d74
generated by cgit v1.2.3 (git 2.39.0) at 2026-09-30 03:23:28 +0300