6a37140a | 03-Dec-2024 |
Ed Tanous <etanous@nvidia.com> |
Put simple update behind an option
4e338b2313f9f2a91aa1fb36693e36a328d58933 Removed tftp update support from the codebase, but left SimpleUpdate in a non functional state.
Given that a number of fo
Put simple update behind an option
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>
show more ...
|
92e26be5 | 21-Aug-2024 |
Ed Tanous <etanous@nvidia.com> |
Reformat meson files with meson format
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
Reformat meson files with meson format
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>
show more ...
|
253f11b8 | 16-May-2024 |
Ed Tanous <ed@tanous.net> |
Allow configuring "bmc" and "system"
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"
Allow configuring "bmc" and "system"
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>
show more ...
|
25b54dba | 17-Apr-2024 |
Ed Tanous <ed@tanous.net> |
Bring consistency to config options
The configuration options that exist in bmcweb are an amalgimation of CROW options, CMAKE options using #define, pre-bmcweb ifdef mechanisms and meson options usi
Bring consistency to config options
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>
show more ...
|
36c0f2a3 | 09-Feb-2024 |
Ed Tanous <ed@tanous.net> |
Consolidate Vm implementations
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 (nb
Consolidate Vm implementations
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>
show more ...
|
8db83747 | 13-Apr-2024 |
Ed Tanous <ed@tanous.net> |
Clean up BMCWEB_ENABLE_SSL
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 dep
Clean up BMCWEB_ENABLE_SSL
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>
show more ...
|
0e373b53 | 31-Oct-2023 |
Marco Kawajiri <kawajiri@meta.com> |
mutual-tls: Add support for Meta certificates
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 =
mutual-tls: Add support for Meta certificates
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>
show more ...
|
fca2cbea | 28-Jan-2021 |
Ed Tanous <edtanous@google.com> |
HTTP/2 support
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 b
HTTP/2 support
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>
show more ...
|
7f3e84a1 | 28-Dec-2022 |
Ed Tanous <ed@tanous.net> |
Add an option flag for multi-computersystem
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 n
Add an option flag for multi-computersystem
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>
show more ...
|