I think we are in a situation similar to this picture
We shall improve it!
This is the core of the problem, and it’s outside of rsync-based procedures. It affects the core of them: backup/restore, which implements also restore from ns6 (upgrade).
The ns6upgrade from backup was discussed here: Upgrade paths to ns7
If we implement a live-upgrade path, we’ll rely on that anyway.
In other words, a development effort is required on backup/restore to simplify both ns7-ns7 and ns6-ns7 procedures.
We recently tried to improve the gateway case:
- Hotsync restore fails with no internet connection · Issue #5430 · NethServer/dev · GitHub
- Dashboard hangs after hotsync-restore and restore-config · Issue #5434 · NethServer/dev · GitHub
It’s surely more critical than a standalone server but I expect it’s widely spread because NS is “all-in-one”.
Anything that is different from cloning by backup/restore becomes making an “instance of” a template, obtaining a new system with slightly different settings (IP? hostname?).
I don’t see the need of supporting this kind of transformations, if we have a procedure that correctly clones a system. It can be tweaked at a later step manually. In other words, if backup/restore (also by rsync) gives back a running system, its “details” can be adjusted manually.
Do I miss something?