Thank you for your donation!


Cloudsmith graciously provides open-source package management and distribution for our project.


Solved: Backup and restore configuration across versions
#1
Provide a means of downloading and uploading configuration settings (as a single file -- .ZIP, .tgz, .xml, .txt, .bin, etc. -- don't care) through the browser interface.  That way, users could first backup the settings on their current moOde installation and then restore them on a new version that requires a fresh installation.  

I understand that new versions of moOde will likely have some additional settings and will remove some settings that exist in older versions. But I'd rather not have to recreate everything from scratch (or screenshots).  It would make fresh installations much easier if the settings that could transfer 1-to-1 would do so.

That would be a big time savings for me as my settings are significantly different than default and I'm dealing with a NAS login, password, and path, and WiFi SSIDs and keys (I have two in my home on 2.4 and 5GHz).  I'm sure that others have invested as much, or more, time in configuring their versions of moOde and this would help them, too.
Cheers,
  Miss Sissy Princess
Reply
#2
Many of the settings reflected in the UI have underlying config files and processing logic so it's not as simple as just saving off some settings into a zip file. It's not really necessary tho because in-place updates are equivalent to "settings migration" and we generally can provide these except in certain cases for example a major new release of RaspiOS where we choose to only release an image. This is also what the Raspberry Pi Foundation recommends and its to ensure maximum reliability for such a major change.

For example the upcoming 6.6.0 release will consist of an image based on the newly released RaspiOS 10.4 and time permitting an in-place update for moOde 6.5.2 that upgrades to 6.6.0 with the exception of the OS upgrade to 10.4.
Enjoy the Music!
moodeaudio.org | Mastodon Feed | GitHub
Reply
#3
(07-06-2020, 09:58 PM)Tim Curtis Wrote: Many of the settings reflected in the UI have underlying config files and processing logic so it's not as simple as just saving off some settings into a zip file.
I've just gone through the upgrade from 6.4.x to 6.5.2, as well as others in the past which required fresh installs, so that was the inspiration for that feature suggestion.  I also had an installation get corrupted, forcing me to start over and go through and make all of the configuration settings again.

I know that the settings are contained in multiple underlying configuration files.  I would expect that implementing the requested feature would require a pair of applications -- one to extract the relevant configuration elements from the files and one to modify the new installation's configuration files accordingly.  Making the modifications could be as simple as invoking SED in some cases while in others it would require something more involved.  But moOde already reads the files, extracts the relevant items, displays them, allows users to modify them (using GUI elements like switches, drop-down menus, and text entry boxes), and writes the modified values back, format-adjusted as necessary.

I spent decades in engineering (primarily embedded systems), so I recognize that the feature I'm requesting probably represents a very large (maybe too large) investment of effort to implement.  But it would be a real time saver for many people, especially those with complex moOde implementations that differ greatly from the stock configuration.  

Just a feature request to consider, even if it the complexity means that it can't be on the short-range radar.
Cheers,
  Miss Sissy Princess
Reply
#4
Hello, not about topic but similar: with a simply copy/paste between a SD (with all settings, added webradio etc) and a new SD (to use in another system), all the data will be copied?
Thanks
Reply
#5
(07-07-2020, 06:46 PM)Blixa Wrote: Hello, not about topic but similar: with a simply copy/paste between a SD (with all settings, added webradio etc) and a new SD (to use in another system), all the data will be copied?
Thanks

Rather than threadjacking my feature request thread, please post your question under moodeaudio.org > Moode Forum › moOde audio player > Support

Here is a link to that forum section for your convenience.
Cheers,
  Miss Sissy Princess
Reply
#6
@Blixa you should start a new thread.
Enjoy the Music!
moodeaudio.org | Mastodon Feed | GitHub
Reply
#7
(07-07-2020, 02:17 AM)fmaxwell Wrote:
(07-06-2020, 09:58 PM)Tim Curtis Wrote: Many of the settings reflected in the UI have underlying config files and processing logic so it's not as simple as just saving off some settings into a zip file.
I've just gone through the upgrade from 6.4.x to 6.5.2, as well as others in the past which required fresh installs, so that was the inspiration for that feature suggestion.  I also had an installation get corrupted, forcing me to start over and go through and make all of the configuration settings again.

I know that the settings are contained in multiple underlying configuration files.  I would expect that implementing the requested feature would require a pair of applications -- one to extract the relevant configuration elements from the files and one to modify the new installation's configuration files accordingly.  Making the modifications could be as simple as invoking SED in some cases while in others it would require something more involved.  But moOde already reads the files, extracts the relevant items, displays them, allows users to modify them (using GUI elements like switches, drop-down menus, and text entry boxes), and writes the modified values back, format-adjusted as necessary.

I spent decades in engineering (primarily embedded systems), so I recognize that the feature I'm requesting probably represents a very large (maybe too large) investment of effort to implement.  But it would be a real time saver for many people, especially those with complex moOde implementations that differ greatly from the stock configuration.  

Just a feature request to consider, even if it the complexity means that it can't be on the short-range radar.

As I mentioned in earlier post the in-place update scripts perform any necessary settings migration and thus a backup/restore settings utility is not really needed except for possibly a disaster recovery scenario but in that case a simple backup of the image would suffice.

The issue really boils down to whether it's wise to include whole OS upgrade as part of in-place update. The Pi Foundation recommends against it to ensure max reliability with a new OS and thats the view that I've adopted. Some users though, @philrandal comes to mind, have had success with OS upgrades. 

Adding that to in-place update though would create risks to users systems becoming corrupted or bricked if OS upgrade does not complete successfully. OS upgrade is a lengthy process requiring solid internet connectivity, lot of free space on the system and if even one of the many repositories that are accessed during the process happens to be too busy to service the request, the entire upgrade is a fail.

Here are some links
https://www.raspberrypi.org/documentatio...pdating.md
https://www.raspberrypi.org/blog/buster-...-raspbian/
Enjoy the Music!
moodeaudio.org | Mastodon Feed | GitHub
Reply
#8
Quote:As I mentioned in earlier post the in-place update scripts perform any necessary settings migration and thus a backup/restore settings utility is not really needed except for possibly a disaster recovery scenario but in that case a simple backup of the image would suffice.

So I didn't need to do a complete new installation, and subsequent reconfiguration, when I went from 6.4.x to 6.5.2?  I could have just relied on in-place update scripts to upgrade to a version that 6.4.x?  How?  The GUI didn't even identify that 6.5.2 was available -- it said what I had was up-to-date.

Quote:The issue really boils down to whether it's wise to include whole OS upgrade as part of in-place update. The Pi Foundation recommends against it to ensure max reliability with a new OS and thats the view that I've adopted. Some users though, @philrandal comes to mind, have had success with OS upgrades. 

In-place OS upgrades? You're arguing against something I never suggested or requested.

I asked for two buttons; one to download configuration settings and one to upload them.  See my original message.

The issue boils down to whether users should have a convenient way to backup and restore configuration settings to facilitate migrating the settings to a new installation or to restore settings on an existing one.  This is not some weird, esoteric feature that I've requested.  It's pretty commonplace.  See these examples:
[Image: Example1.png]
[Image: Example2.png]
Cheers,
  Miss Sissy Princess
Reply
#9
Whats your point?

I've already explained why our project doesn't include major OS upgrades in our in-place updates.

If as you have said "I spent decades in engineering (primarily embedded systems)" then you should consider volunteering your time to the moOde project to help create and support the code that can deliver the update process that you envision.
Enjoy the Music!
moodeaudio.org | Mastodon Feed | GitHub
Reply
#10
(07-08-2020, 02:55 AM)Tim Curtis Wrote: Whats your point?

That moOde would benefit from having a feature commonplace to our industry; buttons to save and restore configuration settings.

Quote:I've already explained why our project doesn't include major OS upgrades in our in-place updates.

Yes, you did, in your very first reply to me.  But I didn't know why since I had not asked about it or suggested that it should be done in any other way.

Quote:If as you have said "I spent decades in engineering (primarily embedded systems)" then you should consider volunteering your time to the moOde project to help create and support the code that can deliver the update process that you envision.

I'm not envisioning an update process.  I'm envisioning two buttons that could be used at any time; one to backup the moOde configuration settings to a file and one to restore configuration settings from a file.  

I am flattered by your invitation to join the development team, but I retired because 30-some years of writing software and firmware was more than enough for me.  I probably would be a poor fit anyway as most of my recent firmware development was in assembly language and it got debugged with hardware test equipment.
Cheers,
  Miss Sissy Princess
Reply


Forum Jump: