[SOLVED] Backup and restore configuration across versions

[TheOldPresbyope]

My grandmother used to love to admonish us grandkids that "the proof of the pudding is in the eating." The late Patrick Henry Winston (MIT AI Lab) was fond of telling his students that the proof of an idea is in a working implementation.

The idea of backing up and restoring moOde's configuration is dead simple conceptually; it gets proposed at least once a year by one user or another. Trouble is, the execution of the idea is anything but dead simple.

I rate backing up and restoring moOde as much closer in degree of difficulty to backing up and restoring a Linux desktop system than it is to backing up and restoring a router. It's hard enough when staying with the same version, rather harder when going across versions.

I've gained enough understanding of the inner workings of moOde to be able to propose some extensions and repairs, either to this forum or to the github repo, and Tim has always considered them fairly. There is this ongoing opportunity for someone to do the same with backup and restore. 

Regards,
Kent

[the_bertrum]

My grandmother used to love to admonish us grandkids that "the proof of the pudding is in the eating."

How nice to see this in full as opposed to the more usual but meaningless "The proof is in the pudding"

The idea of backing up and restoring moOde's configuration is dead simple conceptually; it gets proposed at least once a year by one user or another. Trouble is, the execution of the idea is anything but dead simple.

It is actually relatively simple in most cases: create an ISO of your working system and restore from that.
Do in-place upgrades where offered, then re create your ISO backup.
When an in-place upgrade isn't available for good reasons, then we are likely in a situation where a "settings backup" of an older version would incompatible with the new version anyway, so manual reentry of settings is going to be needed.

Am I over-simplifying somehow?

[TheOldPresbyope]

My grandmother used to love to admonish us grandkids that "the proof of the pudding is in the eating."

How nice to see this in full as opposed to the more usual but meaningless "The proof is in the pudding"

The idea of backing up and restoring moOde's configuration is dead simple conceptually; it gets proposed at least once a year by one user or another. Trouble is, the execution of the idea is anything but dead simple.

It is actually relatively simple in most cases: create an ISO of your working system and restore from that.
Do in-place upgrades where offered, then re create your ISO backup.
When an in-place upgrade isn't available for good reasons, then we are likely in a situation where a "settings backup" of an older version would incompatible with the new version anyway, so manual reentry of settings is going to be needed.

Am I over-simplifying somehow?

Not over-simplifying, but since the OP explicitly titled the thread "across versions" I wanted to address the landscape which has to be covered.

[Blixa]

I'm sorry guys, i didn't want open a new thread only for an yes/no answer, i thought it might have relevance with this thread.

[Miss Sissy Princess]

Not over-simplifying, but since the OP explicitly titled the thread "across versions" I wanted to address the landscape which has to be covered.

Let's make up a hypothetical "config.txt" file which has a section like this:

Code:

:WiFi:
DHCP: TRUE
SSID: "SpaceMonkey"
Security:  "WPA/WPA2 Personal"
Password: "T0asted0ats"

Any future version of moOde could interpret that section of the config.txt file and fully restore the WiFi settings contained therein.  The same concept would apply throughout.

Note:  The above is meant to illustrate a concept, not serve as a design or a best-practices example.

I rate backing up and restoring moOde as much closer in degree of difficulty to backing up and restoring a Linux desktop system than it is to backing up and restoring a router.

Backing up the settings for the pfSense firewall (based on FreeBSD), another example I gave, is orders of magnitude more difficult than backing up the GUI-accessible settings in moOde.

It would be reasonable to "grow" a feature like this.  Maybe just start with one or two of the four major sections (Library, Audio, Network, or System).  Between Library and Network, there are only about a dozen user-accessible settings that could be backed up or restored (action buttons like "Regenerate" aren't settings one would have to back up.).

---

Every version of moOde already reads and writes system configuration files in order to populate the GUI and accept user-entered configuration settings. moOde knows what settings go in which files and in what format they are stored (quoted string, number as text, boolean, etc.). What I am proposing is extending that capability to populate a single configuration settings backup file (rather than the web GUI) and interpreting said file (rather than keyboard input) to import the settings into a new instance of moOde.  

Because these configuration settings backup files would be created by moOde, there would not be a need to do all of the checking one has to do to make sure that (dimwitted) users didn't enter numbers that were out of range, strings with invalid characters, strings that were of the wrong length, null fields, and so forth.  

---

Notes:

• This is a "feature request" -- nothing more.
  
• If there isn't an interest in pursuing it, that's fine.
  
• I am not suggesting that the implementation of the feature would be "easy" or that anyone owes it to me to develop, release, and support this feature.
  
• Nothing I have written should be construed as a criticism of the moOde application, for which I am very grateful.
  
  

[Tim Curtis]

moOde already has the moodecfg.txt file for updating some settings on first boot of a fresh image. It's described in the Setup guide. https://github.com/moode-player/moode/bl.../setup.txt

Maybe this could be used as a starting point for a more comprehensive audio configuration utility.

[Miss Sissy Princess]

Thanks, Tim. I know you're busy with the 6.6.0 rollout (it's working great for me -- I did a clean install to a new MicroSD card, supposedly that benchmarks faster than my old one). So I'll go into lurker mode for a while.

That config file is a great starting place.

Thanks. Sorry for the communications breakdown during this.

[Tim Curtis]

No comms issue just good discussion.

[swizzle]

Backup / restore is fraught but it’d be interesting to store moode & mpd configuration files on something other than the sd card if available. The tricky part is those files aren’t necessarily compatible (e.g. the library db for mpd might change or the old moode config files might be missing data used by a new moode version. You can work around those kinds of things but it introduces more complexity and that makes life harder and programs more prone to bugs.

[normand]

For my curiosity, where are the web interface settings stored, file, db?
Are they all in the same place or bits and pieces all over the place, some files, some db?


I like (love) the idea of a settings/config backup.
It's not that hard to restore all the settings, a pain sometimes, but not hard.


Many of the systems i work with have a settings/config backup utility.  The way they usually do it is using a json or xml file.  Any setting that is not recognized by the system importing the data gets ignored so only valid settings get restored.

For example:

Old system export:
TZ=America/Chicago
NTP=192.168.1.1

New System Format:
TZ=America/Chicago
TimeServer=192.168.1.1

So importing old settings would restore TZ but not NTP as NTP is invalid option on new system.