Factory Reset for Configuration Settings

Factory Reset for Configuration Settings

[Adriana Kobylak]

This note is to propose a new Factory Reset implementation to clear out 
configuration settings and restore them to default. The following 
applies for both static and ubi filesystem layouts.

The current Software implementation of the Factory Reset clears the 
whole read-write filesystem[1].
The reset can be problematic for example if it's issued when the host is 
on, since the inventory gets deleted and the fan controller has no 
knowledge if the system has working fans, leading to shutting off the 
host.
This can be unexpected if the user just wants to reset the configuration 
data, like user passwords or LDAP settings.

The /etc dir is intended to contain the configuration files[2], so we 
can implement the configuration reset by clearing out the data in /etc 
and putting back the defaults. The /etc dir is an overlay, so this can 
be accomplished by clearing the overlay's upper dir.

Proposal:
* Move any configuration file that is currently created in /var to /etc, 
like the Time Owner and Reboot Policy (most are currently under the 
Settings interface).
* Have the init script which mounts the overlay, clear the etc upper dir 
before mounting if a u-boot environment variable is set.
* Implement a new Reset method under the path 
/xyz/openbmc_project/settings/ or configuration/ or 
settings/configuration/ or other.


---
[1] 
https://github.com/openbmc/phosphor-dbus-interfaces/tree/master/xyz/openbmc_project/Common/FactoryReset#xyzopenbmc_projectsoftwarebmcupdater

[2] https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch03s07.html

Re: Factory Reset for Configuration Settings

[Vernon Mauery]

On 30-Aug-2018 01:33 PM, Adriana Kobylak wrote:
>This note is to propose a new Factory Reset implementation to clear 
>out configuration settings and restore them to default. The following 
>applies for both static and ubi filesystem layouts.
>
>The current Software implementation of the Factory Reset clears the 
>whole read-write filesystem[1].
>The reset can be problematic for example if it's issued when the host 
>is on, since the inventory gets deleted and the fan controller has no 
>knowledge if the system has working fans, leading to shutting off the 
>host.
>This can be unexpected if the user just wants to reset the 
>configuration data, like user passwords or LDAP settings.

This seems like a very system-specific sort of thing. I can imagine some 
systems not having any trouble with this, while others might need 
interaction from the host to behave correctly.

>The /etc dir is intended to contain the configuration files[2], so we 
>can implement the configuration reset by clearing out the data in /etc 
>and putting back the defaults. The /etc dir is an overlay, so this can 
>be accomplished by clearing the overlay's upper dir.
>
>Proposal:
>* Move any configuration file that is currently created in /var to 
>/etc, like the Time Owner and Reboot Policy (most are currently under 
>the Settings interface).
>* Have the init script which mounts the overlay, clear the etc upper 
>dir before mounting if a u-boot environment variable is set.
>* Implement a new Reset method under the path 
>/xyz/openbmc_project/settings/ or configuration/ or 
>settings/configuration/ or other.

Our BMCs support multiple levels of 'factory reset' with each level 
removing more and more user data. In addition to my point above, it 
might be a data-driven reset. /usr/share/system-reset/level-1 contains 
information to perform a level-1 reset, .../level-2 contains a level-2 
reset, etc. Where each system may have a different number of levels of 
resets and each system may have a different list of resets that is could 
do. Clearly the nuclear option is to just reformat the NV partition and 
start from ground zero, but what level that is may depend on the system.

The reset manager or settings manager (wherever this lives) can 
determine the number of levels of reset from the config files and then 
on the next reboot, the init script can consume the config files to 
perform the correct operation.

These files can then be stored in platform layers and installed on the 
appropriate targets.

--Vernon