[BB #257] Feature request - Add a way to export configuration / import configuration via a format such as xml or json

[xixix-ft]

Ref. https://bitbucket.org/pedro311/freshtomato-arm/issues/257/feature-request-add-a-way-to-export

Mikael Du Bois created an issue 2022-10-31

When updating firmware and flushing nv-ram, it would be great if there was a way to speed up setup with all the options we had before update (large static table for ips, etc), This could include a log post-import for options that are no longer valid etc so that we may take note and adjust manually for anything that could not be imported.
Comments (6)

rs232

https://www.linksysinfo.org/index.php?threads/a-curiosity-why-cant-tomato-have-router-config-backup-across-versions.76565/post-326993
    2022-11-07
Mikael Du Bois reporter

Awesome, that will probably be helpful, however, the initial request stands: some way in gui to run this type of backup and restore of settings with checkmarks to select which flags the script should run with. This would be really helpful. Also, if there was a way to log which settings are no longer valid upon import (so we can reset those options manually) would be even better!
    2022-11-10
DJK

There should be some balance. Backing up select variables, you’ll reach a point where it negates even caring nvram in the beginning. A text file vs the binary “nvram save” configuration backup differences how if you’re going to restore virtually everything…. just because you can read it?
    2022-11-10
Mikael Du Bois reporter

Human readable format allows for manual removal/update of values prior to import. Something a binary format does not really help with. It also allows for easier mass editing of certain values outside of the firmware update context. For instance, i could start a static allocation, export, edit the json/xml/whatever to add multiple values using a helpful editor such as sublime text and re-import making multiple configurations quicker to edit than manual Gui adjustment.
    2022-11-10
Alex

There is a way of handling cross-version import/export is a safe way.

Considering the fact that FT’s GUI already knows how to map between the nvram and the GUI (that is: it can save the input fields from the web page to the nvram, or populate the web page fields from the nvram), the same functionality can be used to import/export to a file that will map the settings in all the web pages to a “tagged” format (XML, JSON, etc.) including the defaults.

For example, in JSON format:

    {
      "FreshTomato": {
        "Version": "2023.1",
        "Hardware": "Asus RT-AC3100",
        ...
      },
      "Basic": {
        "Network": {
          "Number of Logical WANs": 1,
          "Check connections every": "2 minutes",
          ...
        },
        "IPv6": {
          "IPv6 Service Type": "Disabled",
          ...
        },
        ...
      },
      "Advanced": {
        ...
      }
      ...
    }

Or similarly for XML, with some extra metadata:

    <?xml version='1.0' encoding='UTF-8' ?>
    <FreshTomato version='2023.1' hardware='Asus RT-AC3100'/>
        <group name='Basic'>
            <page name='Network'>
                <setting name='Number of Logical WANs' type='int' default='yes'>1</setting>
                <setting name='Check connections every' type='string' default='no'>2 minutes</setting>
                ...
            </page>
            <page name='IPv6'>
                <setting name='IPv6 Service Type' type='string' default='yes'>Disabled</setting>
                ...
            </page>
            ...
        </group>
        <group name='Advanced'>
            ...
        </group>
        ...
    </FreshTomato>

Or any internal format that is easy to parse and provides similar functionality.

Differences between versions can be handled as follows:
    Field name change: Keep a list of aliases from previous versions.
    Field value name change: Store the numerical value instead of the textual representation, or use aliases as above.
    New variables introduced: Leave as default and alert the user.
    Existing variable modified default: Use the imported value and alert the user. Will need to remember previous defaults, or encode them in the file (see XML example above).
    Removed variable: Alert the user.
    Hardware-dependent settings: If the hardware changed and some settings are incompatible, ignore them and alert the user. Otherwise, if settings are missing or non-applicable, alert the user.

When the user exports the configuration, the code will convert the nvram content to the corresponding strings in a similar way that the GUI does.

When the user tries to import a configuration, the code will attempt to parse it according to the current GUI rules, display the list of discrepancies and issues to the user (potentially marking them with icons according to severity) and either refuse to proceed until the user manually fixes the issues deemed fatal, or gives them a continue/cancel choice if none of the issues were deemed fatal.

‌
    2023-02-25
Alex

I took a quick look at the GUI and it looks that the createFieldTable code could be leveraged for this.

Entries marked with * can be considered “default”
    2023-02-25