<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body style="overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;">Some previous discussion on Backup and Restore for reference: <a href="https://lore.kernel.org/all/YiEbhAQEdJzf706i@heinlein/T/#m50f639da25e073f973e18b5728c15cc1bf61d168">https://lore.kernel.org/all/YiEbhAQEdJzf706i@heinlein/T/#m50f639da25e073f973e18b5728c15cc1bf61d168</a><div><br></div><div>In summary, the DMTF is open to having a schema proposal submitted, they're just looking for someone from the OpenBMC community to help drive it.</div><div><br id="lineBreakAtBeginningOfMessage"><div><br><blockquote type="cite"><div>On Mar 17, 2025, at 4:36 AM, Paul Fertser <fercerpav@gmail.com> wrote:</div><br class="Apple-interchange-newline"><div><div>Hello,<br><br>I was thinking about an "ideal" way to allow backing up and restoring<br>the BMC configuration in production and came up with this set of<br>goals:<br><br>1. The saved config should be easy to inspect and change;<br><br>2. It should not require any additional changes on the BMC side, so<br> should be usable not only with OpenBMC but also with other<br> implementations;<br><br>3. The tool usage should be easy to automate;<br><br>4. The tool should be easy to integrate into larger management<br> systems and it should scale to arbitrary amount of BMCs;<br><br>5. It should be as beneficial as possible to the communities using<br> Free Software.<br><br><br>To my surprise I couldn't find any existing solution so following<br>these ideas I prepared a prototype and published at<br>https://github.com/paulfertser/ansible_redfish_settings .<br><br>Please feel free to comment on approach and the implementation, and of<br>course to provide patches. I have to note I'm not personally herding a<br>bunch of servers so my notions can be quite off, do not hesitate to<br>point out when it doesn't match real life usecases.<br><br><br>Point 1 is followed by saving config in YAML format, that's nice to<br>edit both manually and automatically if needed. Point 2 is fulfilled<br>by doing only Redfish interactions, optional Oem settings can be added<br>conditionally. Points 3 and 4 come naturally from using Ansible which<br>seems to be the most popular system for reproducible mass<br>configuration (and much more), so should be familiar to most BMC<br>operators. Point 5 is helped by repository organisation which makes it<br>natural to submit patches upstream to community.general Ansible<br>collection.<br><br><br>While working on this prototype I contributed few changes for missing<br>functionality in community.general collection, the experience was<br>highly positive as the upstream is welcoming and helpful. So extending<br>the project to handle the settings you care about shouldn't be<br>problematic, see my changes for example:<br><br>https://github.com/ansible-collections/community.general/commit/e853bdf6f907872fdd39e8c507061269399942e9<br>https://github.com/ansible-collections/community.general/commit/129f51cf9d284d107cf197a1805481c2e4645efe<br>https://github.com/ansible-collections/community.general/commit/abe4e5ce95e6cae4a42629640345e0769c3724a1<br><br><br>Here follows the copy of the project README.md with some more details.<br><br># Description #<br><br>This project aims at providing an easy to use mechanism for creating a<br>human-readable and editable BMC settings configuration bundle and for<br>reliable idempotent application of them to an arbitrary number of<br>machines. It should be possible to use it directly or to seamlessly<br>integrate into larger Ansible playbooks as desired. The tasks files<br>are provided under MIT licence terms.<br><br>Added as a submodule is a fork of community.general Ansible<br>collection. The changes are minimal: extending backwards compatibility<br>and renaming to not clash with system-wide installation. The idea is<br>to provide fast, easy and straightforward mechanism to prepare and<br>test patches for submitting Github pull requests to upstream<br>repository: https://github.com/ansible-collections/community.general .<br>After the PRs are merged it's trivial to rebase to get the<br>latest-and-greatest code. Please note this collection is published<br>under GPL-3.0.<br><br>The testing was performed against OpenBMC hosts but it should be<br>working reasonably with any other Redfish compliant server.<br><br><br># System requirements #<br><br>Ansible version 2.10.0 (released in 2020) or later.<br><br><br># Installation instructions #<br><br>```<br># apt install ansible<br>$ git clone --recursive https://github.com/paulfertser/ansible_redfish_settings<br>```<br><br>If you really need a fully "standalone" solution, consider packaging with<br>Nuitka as described here: https://github.com/HexmosTech/Ansika .<br><br><br># Usage examples #<br><br>Example command to retrieve all the settings from a single host:<br>```<br>$ ansible-playbook get_settings.yaml --extra-vars "baseuri=172.41.1.38 username=root password=0penBmc"<br>```<br><br>The data will be saved to `settings_172.41.1.38.yaml` file.<br><br>Example command to set settings for a single host:<br>```<br>$ ansible-playbook set_settings.yaml --extra-vars "baseuri=172.41.1.38 username=root password=0penBmc" --extra-vars @settings_172.41.1.38.yaml<br>```<br><br>The repository includes sample `inventory.ini` which allows to retrieve and set<br>settings en masse:<br>```<br>$ ansible-playbook get_settings.yaml -i inventory.ini<br>```<br><br>-- <br>Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software!<br>mailto:fercerpav@gmail.com<br></div></div></blockquote></div><br></div></body></html>