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
_______________________________________________
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
