|
|
Post by sunitha on Feb 6, 2024 7:07:25 GMT
I am looking for a redfish resource, which will represent the files as resources. With this, I should be able to perform create, read, update and delete a file at the servers file system.
Something like redfish/v1/Systems/<systemdId>/FileCollection/<fileId>
There should be relevant security validations at the backend, and the spec can contain the allowed file content types, file permissions, max and min size limitations etc.
Please share your views on the same.
|
|
|
|
Post by mraineri on Feb 6, 2024 22:07:07 GMT
What exactly is your use case for allowing a user to add/delete/edit files on a system? SNIA does touch on some of these concepts with their file system modeling, but it doesn't go down to the level you're thinking of.
I have concerns with this sort of functionality since it's duplicative of other tools used to log into a system and edit files, like using SSH to the host and editing files over that interface. The OS already carries around permissions for who can access each of the files, and allowing Redfish to bypass the OS/recreate access rights for system files might be very problematic.
|
|
|
|
Post by sunitha on Feb 7, 2024 4:46:31 GMT
My use case is to allow the redfish client to use the server's persistency storage to save critical data as files. There is no SSH available to the server(we block it for security) to upload and manage files. Yes, I too share the same concerns of letting the file system edits - but there should be rules & validations at the server to allow the operations without causing any security threats.
|
|
|
|
Post by sunitha on Feb 21, 2024 9:54:12 GMT
Any further thoughts ?
|
|
|
|
Post by mraineri on Feb 21, 2024 13:38:19 GMT
If you're looking to get "critical data" off a system when SSH or other methods are not available, the existing CollectDiagnosticData action should let you do this in a fairly arbitrary manner. One of the options is to specify the type of data to collect, and "OS" is already one of the options. The result of the action will produce an opaque package that a user can download from the BMC.
Beyond this, doing proper file management on a system is out of scope for Redfish at this time.
|
|
|
|
Post by jautor on Feb 21, 2024 21:19:40 GMT
My use case is to allow the redfish client to use the server's persistency storage to save critical data as files. There is no SSH available to the server(we block it for security) to upload and manage files. Yes, I too share the same concerns of letting the file system edits - but there should be rules & validations at the server to allow the operations without causing any security threats.
By "save critical files" do you mean items like crash dumps or debug logs? Although you say "client" - and those types of files would be created by the service/manager.
I'm not sure I understand what files a client would need to upload to the system via this interface. Unless this is for accessing a "virtual media store" or other storage repository that is owned by the BMC and exposed to the host OS?
As Mike indicated, I think the group will be very reluctant to open up a filesystem interface if it "owned" by a host operating system. But I'd want to understand the use cases before making any decision on that...
Jeff
|
|
|
|
Post by sunitha on Feb 22, 2024 6:57:08 GMT
Thank you for the response.
I will check the schema for the CollectDiagnosticData to see if this can be suitable.
These are not dumps or debug logs. These are some persistent host configuration/resource data which should be accessible to all the admins (redfish client) connected. Our usecase needs this data to be available even when the system host is powered off. Thus we arrived at some specific directory at the BMC persistent file system to be the best place to store them. The storage is owned by the BMC, but the data is consumable to the host, and the managing redfish clients.
|
|
|
|
Post by mraineri on Feb 22, 2024 13:44:11 GMT
That all still sounds like debug data in the scope of Redfish. Internal files like that on a BMC are not standardized as to their contents or structures. I would still recommend looking at the CollectDiagnosticData action (but in that specific usage you can use the parameter "Manager" as the data type).
However, if the data is consumable by Redfish clients, I would expect the data to be mapped accordingly to a hardened resource and not left as an opaque file.
|
|
