Suggestion: VyOS/Vyatta/EdgeOS should run 'show configuration commands'

[sliddjur]

These OS's should run 'show configuration commands' rather than just 'show configuration'.

The first command shows the actual commands specified rather than the config node objects in json format.

Since "Oxidized is a network device configuration backup tool" it makes more sense to have the actual commands available to copy paste in case of a failure.

Right now we've made a work-around and edited oxidized-0.21.0/lib/oxidized/model/vyatta.rb for every new release.

[ZacharyPuls]

PR #1164

As an aside, while I do like this format (especially for Accedian NIDs, given their configuration format has a ton of cruft), the idea behind the config backup is to have a flat file you can import back into the device to "roll back" configuration changes.

[laf]

As an aside, while I do like this format (especially for Accedian NIDs, given their configuration format has a ton of cruft), the idea behind the config backup is to have a flat file you can import back into the device to "roll back" configuration changes.

@ZacharyPuls Does the PR you submitted give you that?

Does anyone have an example diff that this new PR would provide.

The current file that is backed up seems to make more sense to me as it's what the devices use natively, this new format would need to be pasted in to the cli to restore wouldn't it?

[laf]

@ZacharyPuls / @sliddjur Any feedback?

@thakala You originally created the vyatta support, what do you think to this proposed change?

[sliddjur]

@laf without having tested it, this looks like its going to do the right thing https://github.com/ytti/oxidized/pull/1164/commits/5868223e73a4f90d5e078d1b622c59fbfd48d6ff

[yzguy]

Diff with the new commands

[laf]

This was merged in. Thanks for testing everyone :)

[yzguy]

One thing to note is that this change would introduce a "secrets exposure" even if the user put a remove_secret: true. The show configuration command itself would not show the secrets, only a bunch of **********, however now that it is show configuration commands, it does not hide those secrets anymore.

Previous output:

        user ubnt {
            authentication {
                encrypted-password ****************
            full-name ""
            level admin
        }

New output even with secrets: true (part of hash removed for sanitization)

set system login user ubnt authentication encrypted-password '$6$jDbuuQ7wo7poBDCN$oBxcVRqhVRk6...'

I presume we must add a cmd :secret to just look for the hashes, etc. in this new form.

[laf]

It would be something similar to what's done here: https://github.com/ytti/oxidized/blob/master/lib/oxidized/model/fortios.rb#L17

[yzguy]

I'll make another issue with the details, just figured I'd bring it up. Definitely easy to add.

[zoc]

Hi,

I'm using oxidized with LibreNMS and to be honest I'm quite disappointed by this change, which basically renders the web output of my EdgeOS router config unreadable, and then the ability to display it in LibreNMS quite useless...

I understand the reason behind the change, but at the same time I do not see the issue with the previous format, because on EdgeOS you can always "load configfile.txt" to restore a full configuration file (using the previous format).

Could we have a configuration flag in Oxidized for us to choose between the two formats ?

Thanks.

[jceresini]

I realize this is closed and presumably nobody will see it, but I have to say that i completely disagree with this statement:

Since "Oxidized is a network device configuration backup tool" it makes more sense to have the actual commands available to copy paste in case of a failure.

A backup of something doesn't imply that restoring it is as simple as copy/paste. And the set commands make diff-ing config versions way more annoying in my opinion. Also, lets consider a simple config diff:

- set interfaces ethernet eth0 address dhcp
+ set interfaces ethernet eth0 address 203.0.113.1/28

Let's say that config was change erroneously, and we need to roll it back. If I run the first set command, here's what I end up with:

user@edgerouter# show interfaces ethernet
 ethernet eth0 {
+     address dhcp
     address 203.0.113.1/28

That config wont commit (you'll get an error) until I run delete interfaces ethernet eth0 address 203.0.113.1/28. So, should the config backup also include all the delete/unset commands for a platform?

If what we really wanted was a way to use the config directly, I think the appropriate solution would be to talk to the vendor to support loading the config from the terminal, as Junos supports. We can already load from flat files:

user@edgerouter# load ?
Possible completions:
  <Enter>               Load from system config file
  <file>                Load from file on local machine
  scp://<user>:<passwd>@<host>/<file>   Load from file on remote machine
  ftp://<user>:<passwd>@<host>/<file>   Load from file on remote machine
  http://<host>/<file>          Load from file on remote machine
  tftp://<host>/<file>          Load from file on remote machine

I just dont think this is something that should be fixed by a backup tool. The config for the device is the json-ish style config.