Use SPDX identifiers

SPDX identifiers are simpler, and reduce the amount of cruft we have in
code files. They are recommended by linux foundation, and therefore we
should do as they allow.

This pa

Use SPDX identifiers

SPDX identifiers are simpler, and reduce the amount of cruft we have in
code files. They are recommended by linux foundation, and therefore we
should do as they allow.

This patchset does not intend to modify any intent on any existing
copyrights or licenses, only to standardize their inclusion.

[1] https://www.linuxfoundation.org/blog/blog/copyright-notices-in-open-source-software-projects

Change-Id: I935c7c0156caa78fc368c929cebd0f068031e830
Signed-off-by: Ed Tanous <etanous@nvidia.com>

show more ...

Make message registries use 2 digit versions

Redfish specification, section 9.5.11.2 says:

The MessageId property value shall be in the format:
<MessageRegistryPrefix>.<MajorVersion>.<MinorVersion>

Make message registries use 2 digit versions

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>

show more ...

Bump base registry to 1.19.0

Adds GenerateSecretKeyRequired registry to the Base for MFA

Change-Id: Ia690639b4bebbbd265b223bd626b0eb814103f99
Signed-off-by: Jishnu CM <jishnunambiarcm@duck.com>

Make PATCH return 204 again

It was correctly pointed out that for PATCH, we cannot return 200
success without also returning the object, per Redfish. This commit
partially reverts cdf25ff, to give

Make PATCH return 204 again

It was correctly pointed out that for PATCH, we cannot return 200
success without also returning the object, per Redfish. This commit
partially reverts cdf25ff, to give PATCH the old (204) behavior again.

Tested: Patch now returns 204

Change-Id: I8ede932a73ae064586d94c47393e4418350adb00
Signed-off-by: Ed Tanous <etanous@nvidia.com>

show more ...

Make set properties return 200 Success not 204

Both 200 and 204 are allowed by the Redfish specification. Table 11
states:

200 OK Success, and the action's schema definition does not contain an
ac

Make set properties return 200 Success not 204

Both 200 and 204 are allowed by the Redfish specification. Table 11
states:

200 OK Success, and the action's schema definition does not contain an
action response.

204 No Content: Success, and the action's schema definition does not
contain an action response.

While both of these are allowed, we accidentally changed behavior in the
following commit:
87c4496 Move to Redfish setProperty call

When we transitioned these over to the common dbus calling methods.

This commit restores the old behavior of returning 200 success on
actions, which some implementations are expecting.

Tested: WIP.

Change-Id: I02e47585acf85bd04dcb9d428ef3e39a21d9c75f
Signed-off-by: Ed Tanous <ed@tanous.net>

show more ...

Bump base registry to 1.18.1

72169 points out a mistake in 1.16 which is fixed in 1.18. Let's pull
1.18.1 in. 1.18.1 is the latest.

Changed 1 line in parse_registries.py and reran it.

Tested: None

Bump base registry to 1.18.1

72169 points out a mistake in 1.16 which is fixed in 1.18. Let's pull
1.18.1 in. 1.18.1 is the latest.

Changed 1 line in parse_registries.py and reran it.

Tested: None. In the past bumping these hasn't caused problems.

Change-Id: I79b135b8366d9b423f789c34802b1c0366d4e8a5
Signed-off-by: Gunnar Mills <gmills@us.ibm.com>
Signed-off-by: Ed Tanous <ed@tanous.net>

show more ...

Add missing headers

Most of these were found by breaking every redfish class handler into
its own compile unit:

When that's done, these missing headers become compile errors. We
should just fix the

Add missing headers

Most of these were found by breaking every redfish class handler into
its own compile unit:

When that's done, these missing headers become compile errors. We
should just fix them.

In addition, this allows us to enable automatic header checking in
clang-tidy using misc-header-cleaner. Because the compiler can now
"see" all the defines, it no longer tries to remove headers that it
thinks are unused.

[1] https://github.com/openbmc/bmcweb/commit/4fdee9e39e9f03122ee16a6fb251a380681f56ac

Tested: Code compiles.

Change-Id: Ifa27ac4a512362b7ded7cc3068648dc4aea6ad7b
Signed-off-by: Ed Tanous <ed@tanous.net>

show more ...

Create Redfish specific setProperty call

There are currently 78 sdbusplus::asio::setProperty calls in
redfish-core. The error handler for nearly all of them looks something
like:

```
if (ec)
{

Create Redfish specific setProperty call

There are currently 78 sdbusplus::asio::setProperty calls in
redfish-core. The error handler for nearly all of them looks something
like:

```
if (ec)
{
const sd_bus_error* dbusError = msg.get_error();
if ((dbusError != nullptr) &&
(dbusError->name ==
std::string_view(
"xyz.openbmc_project.Common.Error.InvalidArgument")))
{
BMCWEB_LOG_WARNING("DBUS response error: {}", ec);
messages::propertyValueIncorrect(asyncResp->res, "<PropertyName>", <PropertyValue>);
return;
}
messages::internalError(asyncResp->res);
return;
}
messages::success(asyncResp->res);

```

In some cases there are more errors handled that translate to more error
messages, but the vast majority only handle InvalidArgument. Many of
these, like the ones in account_service.hpp, do the error handling in a
lambda, which causes readability problems. This commit starts to make
things more consistent, and easier for trivial property sets.

This commit invents a setDbusProperty method in the redfish namespace
that tries to handle all DBus errors in a consistent manner. Looking
for input on whether this will work before changing over the other 73
calls. Overall this is less code, fewer inline lambdas, and defaults
that should work for MOST use cases of calling an OpenBMC daemon, and
fall back to more generic errors when calling a "normal" dbus daemon.

As part of this, I've ported over several examples. Some things that
might be up in the air:
1. Do we always return 204 no_content on property sets? Today there's a
mix of 200, with a Base::Success message, and 204, with an empty body.
2. Do all DBus response codes map to the same error? A majority are
covered by xyz.openbmc_project.Common.Error.InvalidArgument, but there
are likely differences. If we allow any daemon to return any return
code, does that cause compatibility problems later?

Tested:
```
curl -k --user "root:0penBmc" -H "Content-Type: application/json" -X PATCH -d '{"HostName":"openbmc@#"}' https://192.168.7.2/redfish/v1/Managers/bmc/EthernetInterfaces/eth0
```

Returns the appropriate error in the response
Base.1.16.0.PropertyValueIncorrect

Change-Id: If033a1112ba516792c9386c997d090c8f9094f3a
Signed-off-by: Ed Tanous <ed@tanous.net>

show more ...