|
Post by mraineri on Apr 15, 2024 14:05:43 GMT
1) No, this only applies when a user supplies only "UserName" and "Password", and the MFA configuration is to generate onetime tokens in response to the login attempt. This is like when you log into your bank's website and it prompts you for a token they just sent to you via text or email.
2) Correct; you can have this enabled in a ManagerAccount resource and email the user without having any LDAP/AD configurations.
3) Yes, but it's conditional on whether it's configured with the lead-in "When a multi-factor authentication type that requires tokens is enabled". It's not required to support the capability. The same is true with the email usage with the lead-in "if the multi-factor authentication type uses a service-generated onetime passcode". This is also an optional capability, but the behavior is mandatory if you support it and the user has it enabled.
|
|
|
Post by mraineri on Apr 15, 2024 11:11:06 GMT
Why is your BMC a Chassis and not a Manager? BMCs are traditionally modeled as Manager resources.
I assume "Erot" is some "root of trust"; why is this it's own Chassis and not something like the "TrustedComponent" resource?
Regardless of the answer to the modeling questions, what you're highlighting is an issue that every aggregator needs to solve. Some aggregators cache resource trees and response bodies locally so they do not have to query downstream devices as often. The method you use is ultimately going to depend upon your aggregator's design and accounting for any limitations with the devices you're aggregating (such as if you can rely on event notifications for resource changes).
|
|
|
Post by mraineri on Apr 11, 2024 14:16:10 GMT
For FW Update: "Targets" is the right thing to use here. That gives the user the control to specify an exact device to update if they do not want the service to automatically pick the "right" devices. This would be the URI of the resource representing the device (like /redfish/v1/Managers/BMC5). We have the following in the long description for Targets to call out some expected behaviors:
> These targets should correspond to software inventory instances or their related items. If this parameter is not present or contains no targets, the service shall apply the software image to all applicable targets, as determined by the service. If the target specifies a device resource, the software image file shall be applied to the specified device. If the target specifies a resource collection, the software image shall be applied to each applicable member of the specified collection. If the target resource specifies an Aggregate resource, the software image file shall be applied to each applicable element of the specified aggregate. If the target resource specifies a ComputerSystem resource, the software image file shall be applied to the applicable components within the specified computer system.
For FW Inventory: You'd need to grow the members of the FW inventory collection. It's a flat list of everything known to the service. So, I would expect URIs like "/redfish/v1/UpdateService/FirmwareInventory/BMC5".
For Tasks: It would be the responsibility of the aggregator to instantiate a task for itself and internally track the task of the satellite BMC. From the external user's perspective. This would be rolled up under /redfish/v1/TaskService/Tasks like every other task for the aggregator.
|
|
|
Post by mraineri on Apr 11, 2024 14:03:01 GMT
Are these new schema files populated in the local directory where the tool caches schema files? It should be in "./SchemaFiles/metadata".
If they're there, can you add "--debugging" to the CLI for the tool and provide the text log file?
|
|
|
Post by mraineri on Apr 10, 2024 19:12:35 GMT
I think you're right... I'll raise it to discuss further.
|
|
|
Post by mraineri on Apr 10, 2024 13:38:36 GMT
You do not need to define an entity like that. You only need to do that if you're making an OEM resource.
Since the prefix of the action name is "Contoso_ABC_ComputerSystem", then it would be in a namespace called "Contoso_ABC_ComputerSystem".
There is a full example of how to define this in the public-oem-examples mockup. The "/redfish/v1/AccountService" resource has an example "AutoConfig" OEM action, and the schema definition is found in Contoso.com/ContosoAccountService_v1.xml.
|
|
|
Post by mraineri on Apr 10, 2024 13:34:00 GMT
If you're using an action, then it would be a POST operation. All actions are performed via POST operations, and you can specify requirements for the request body with action parameters.
|
|
|
Post by mraineri on Apr 5, 2024 19:17:30 GMT
What's the usage for this from the user's perspective? Today, we use "Conditions" to show everything that is affecting the health of the resource, and so the condition is still true until the underlying fault has been addressed.
|
|
|
Post by mraineri on Apr 5, 2024 19:11:32 GMT
Curious about this statement:
> This is commonly seen on applications already for turning off sensors that may not be needed for some customers.
Does this mean that the sensor is shut off as part of building the product? Or does an end user really have this level of control?
Do you also have examples of sensors with this sort of capability?
|
|
|
Post by mraineri on Apr 5, 2024 17:58:59 GMT
You can define an action with a side effect that deletes a resource. For example, the ClearLog action on LogService can be thought of as a glorified "delete all" for the members of the log entry collection. You just need to define the action in schema, give clear descriptions for its behaviors, and show the action in the resource in question where you want to perform this type of operation.
|
|
|
Post by mraineri on Apr 5, 2024 12:10:04 GMT
Like with HTTP, we don't define payload semantics with the DELETE operation. You could allow a client to provide a request body, but at that point you're stepping outside of the Redfish spec. There is an update about this in RFC9110: datatracker.ietf.org/doc/html/rfc9110#name-delete> Although request message framing is independent of the method used, content received in a DELETE request has no generally defined semantics, cannot alter the meaning or target of the request, and might lead some implementations to reject the request and close the connection because of its potential as a request smuggling attack (Section 11.2 of [HTTP/1.1]). A client SHOULD NOT generate content in a DELETE request unless it is made directly to an origin server that has previously indicated, in or out of band, that such a request has a purpose and will be adequately supported. An origin server SHOULD NOT rely on private agreements to receive content, since participants in HTTP communication are often unaware of intermediaries along the request chain. So, while you can do that, it's certainly frowned upon. The semantics of DELETE are to remove the URI specified by the client; you don't need a payload to augment that sort of request.
|
|
|
Post by mraineri on Apr 1, 2024 12:44:15 GMT
You're free to do either; we state this in the specification:
> If the action request contains unsupported parameters, the service shall ignore the unsupported parameters or return the HTTP 400 Bad Request status code.
If you do return a 400, then using the ActionParameterUnknown message from the Base Message Registry makes the most sense.
|
|
|
Post by mraineri on Mar 28, 2024 17:46:16 GMT
If your implementation supports PATCHing the attribute in the active resource directly (as in you can make on-the-fly BIOS attribute updates without a system reboot) and you can also support staging the attribute to be staged for the next reboot, then that falls into the "Writable, updates immediately or at a future point in time.". This means you omit the attribute from GET responses for the settings resource unless there is a pending change. So, it would map to case 2.
However, specifically for BIOS attributes, I have not seen the capability to modify attributes without a reboot in a real product; the implementations I've seen always map this to the "Writable, updates at a future point in time, but not immediately." row in that clause. So, I'd be cautious about this to ensure you really do have that support in your product.
|
|
|
Post by mraineri on Mar 27, 2024 19:01:11 GMT
1) Yes, that's correct. It looks like we added "ForceUpdate" as a parameter after the paper was first published, so we should update the paper to be in sync with the schema. Thanks for catching that. "UpdateFile" is specific to the HTTP header usage with the multipart forms and is not described in schema.
2) Currently there's not a way to convey device-specific supported apply times for updates. For the context of the UpdateService showing allowable operation apply time values, this is a "service-wide" allowable setting. I think you're the first one to raise this type of condition, and we'd have to discuss this further internally.
|
|
|
Post by mraineri on Mar 27, 2024 13:17:57 GMT
Q1) Yes, that mapping looks correct to me.
Q2) Yes, I believe that's what's typically done.
|
|