Restoring (old) config backups and

[Henrique de Moraes Holschuh]

Hello,

I am bringing the topic here because I am pretty sure it is something 
that affects any downstream firmware that focus on regular users...

We'd like to know if anyone has specific thoughts on the issue, or has 
implemented/is testing/considered solutions to the issues I describe in 
this email...


TL;DR: users do a backup, and sometime later restore after several 
sysupgrades, which ends up being a simple reboot (no uci-defaults or any 
other specific post-processing) into outdated config from the PoV of the 
current firmware, and things go bad.



OpenWRT has a config backup functionality, tied to sysupgrade, and 
exposed through LuCI.  So far, so good.  This is very valuable 
functionality, and users make use of it for several reasons, so it is 
not something anyone would like to take away [downstream] even if it is 
causing trouble.


The problems we've observed with the backup *restore* functionality are:

* It is applied with a simple reboot, and _apparently_, it has no hooks 
or other way to ensure system sanity before (or after) the backup restore.

Which would be fine if the following point was never true:

* End users are likely to use the backup-restore facility across 
sysupgrade (i.e. use older backups).



Some possible root causes of the issues created on backup restoration:

1. /etc/uci-defaults is not "reset" like a sysupgrade would.  When the 
backup is "outdated" from the PoV of current packages in the running 
firmware image, it can cause issues ranging from minor, to severe.

2. Account information is not properly sanitized/recreated (/etc/passwd, 
shadow, group).  Thus, system accounts that were meant to be used by 
packages might be missing or have incorrect contents.   This is a 
consequence of (1), thus not a "root cause", but I find it relevant 
enough to mention it explicitly.

If things fail to start because of missing system users, it is bad. 
When they *don't* fail to start and instead run as root, it is arguably 
*worse*.


Some possible solutions:

* It is not too hard to bake a firmware image uuid, randomly generated 
at build-time, add it to the backup tarball, and use it to detect the 
fact that we (re-)booted into a new environment that should go through 
/etc/uci-defaults processing as if it had been through a sysupgrade.

This requires /etc/uci-defaults scripts that can handle being run when 
the changes they need to apply are already in place, which is *already* 
a best-practice, but still...

Alternatively, or perhaps additionally to uci-defaults, it could run 
package-provided scripts from a directory on restore (pre-reboot, 
after-reboot).

* If uci-defaults handling is impossible, at the very least fish out the 
system user handling and other key points that are already in place, and 
somehow arrange to have them run as a post-backup-restore functionality.


Any thoughts on this?  I am certainly to have overlooked a lot of stuff, 
especially if it is present only on master.  Also, handling of an 
uci-defaults "reset" (so that they'd run again) in 
non-initramfs/overlayfs based system is likely to pose some challenges 
depending on how it is implemented...

-- 
Henrique de Moraes Holschuh