New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

panos (Palo Alto): Make it possible to configure configuration format #1101

Closed
wants to merge 1 commit into
base: master
from

Conversation

Projects
None yet
4 participants
@pv2b
Contributor

pv2b commented Nov 16, 2017

Hi.

Currently, the panos model retrieves and stores the configuraiton in the default configuration format that looks something like this:

config {
  mgt-config {
    users {
      admin {
        phash <redacted>
        permissions {
          role-based {
            superuser yes;
          }
        }
      }

This format lends itself really poorly to diffing, because it's unclear without a lot of context information where you actually are in a configuration. Instead I prefer to retrieve the configuration in "set" format which looks like this:

set mgt-config users admin phash <redacted>
set mgt-config users admin permissions role-based superuser yes

In order to accomplish this, the command set cli config-output-format set has to be issued. Instead of "set" also valid is: default, json, set and xml. If someone prefers, he can set these instead.

The current code uses the command show config running to dump the command output. Unfortunately, this command does not respect the set cli config-output-format setting. Instead it always outputs in the bogus format above. As an alternative, instead you have to enter configure mode, and then issue the command show. For this reason, I also had to widen the legal prompt regex.

The code I have submitted looks to work on my end, but I'm not sure if I've done this in the "correct" way.

Finally, I have some doubts as to whether it's actually possible to restore configuration files that have been dumped out on CLI in their entirety, or whether either of these formats is useful for auditing purposes only. It may be that you have to use XML format (ugh) no matter what. But this is not really a topic for this PR at the moment.

@ZacharyPuls

This comment has been minimized.

Show comment
Hide comment
@ZacharyPuls

ZacharyPuls Nov 16, 2017

Contributor

I don't know what the stance of the project owner is, but I would personally be leery of adding model-specific configuration items to the Oxidized config. As it stands today, it looks like all of the config options are global, not specific to a single model (meaning things like cisco_option_1, alcatel_option_2, you can specify config options per-model).

Maybe we could create a separate model for the config formats? Something like:

panos_xml.rb
panos_json.rb
panos_set.rb

I am not opposed to doing the panos_config_format vars specifically, just wondering if there is a more generic way we can approach this.

Contributor

ZacharyPuls commented Nov 16, 2017

I don't know what the stance of the project owner is, but I would personally be leery of adding model-specific configuration items to the Oxidized config. As it stands today, it looks like all of the config options are global, not specific to a single model (meaning things like cisco_option_1, alcatel_option_2, you can specify config options per-model).

Maybe we could create a separate model for the config formats? Something like:

panos_xml.rb
panos_json.rb
panos_set.rb

I am not opposed to doing the panos_config_format vars specifically, just wondering if there is a more generic way we can approach this.

@laf

This comment has been minimized.

Show comment
Hide comment
@laf

laf Nov 17, 2017

Collaborator

It might be worth hearing from @ytti on his stance with things like this.

At present users only have the ability to specify a model to be used in the source or a config option so it can be tricky. This seems like it might be better to implement this as a perm fix in the model though if it makes the configs useable.

It did highlight to me that the same is true for Vyatta and Edgeos. Both could run show configuration commands | no-more

Collaborator

laf commented Nov 17, 2017

It might be worth hearing from @ytti on his stance with things like this.

At present users only have the ability to specify a model to be used in the source or a config option so it can be tricky. This seems like it might be better to implement this as a perm fix in the model though if it makes the configs useable.

It did highlight to me that the same is true for Vyatta and Edgeos. Both could run show configuration commands | no-more

@pv2b

This comment has been minimized.

Show comment
Hide comment
@pv2b

pv2b Nov 17, 2017

Contributor

I am actually leaning to the fact that this approach of getting configuration from PanOS is broken to start with because there's no way to restore configs from either of these format. Not even if you actually set the output format to xml do you get an "importable" XML configuration. So this is trying to repair something that is fundamentally broken (see #440)

I have given a try to implementing a new version of the PanOS model that instead uses the HTTP API to download an XML configuration, unfortunately I haven't quite been able to get it to work because of my unfamiliarity with oxidized/ruby. See #1103

Contributor

pv2b commented Nov 17, 2017

I am actually leaning to the fact that this approach of getting configuration from PanOS is broken to start with because there's no way to restore configs from either of these format. Not even if you actually set the output format to xml do you get an "importable" XML configuration. So this is trying to repair something that is fundamentally broken (see #440)

I have given a try to implementing a new version of the PanOS model that instead uses the HTTP API to download an XML configuration, unfortunately I haven't quite been able to get it to work because of my unfamiliarity with oxidized/ruby. See #1103

@jsynack

This comment has been minimized.

Show comment
Hide comment
@jsynack

jsynack Nov 17, 2017

Contributor

Some good discussions/points - My thoughts have been that the config should be copy-n-paste ready (or whatever config restoration method exists). Else the items should be commented (generic reporting on the model etc).

If the config as exported with a given command doesn't work in this fashion, it doesn't fulfill the ability for a reasonable restoration based on what oxidized has stored. So it would seem this should certainly be a model change / default behavior change if the current PANOS configs are not useful for quick/complete restoration (I dont have any devices to test with).

@laf - On the command changes -there are a few others that are similar (NOS and SLXOS support a similar syntax of command | nomore, and the SLX model was just adjusted to have role-specific adjustments for the oxidized user).

I think it probably would be best to define a list of oxidized least privilege and order of preference for model implementation and see how each of the models shape up. This can then be used as a guide of how to acquire content.

Something like (this is just random order as they came to me - feel free to adjust):

  • Prefer SCP/HTTPS/REST/FTP/HTTP/TFTP method to a model if possible and reliable. This excludes ability to get non-configuration items, but probably provides the cleanest configuration copy. Some devices support a scp oxidized@device:running-config blah style of syntax that removes all the pagination and scraping 'fun'. If non-configuration items are desired, they be probed via CLI and appended before committing to the backend output.
  • Read-only oxidized CLI user using a session-level pagination disable sent via post_login (sadly, not support session-level pagination disable).
  • Read-only oxidized CLI user with commands / pipes to disable pagination (eg command | nomore) - probably implemented as a capability of the model so the cmd command doesnt have to get too crazy and oxidized automatically adds the | nomore .
  • Read-only oxidized CLI user with user-level or system-level disable of pagination already set either in the configuration or arriving via AAA if the model supports it. (not ideal if it is a global setting as all sessions will then but non-paginated)
  • Model detects the pagination prompt on the device and continues automatically, trying to remove the device-specific --More-- (can be problematic)
  • Read-write oxidized user that can toggle the pagination at login. Set to disable prior to running commands and then restore to the default / sane value. It means technically the device configuration is slightly different than the repo, but it also means that the device/model doesnt have any of the other capabilities or they do not work reliably enough (software rev support, etc.)

Implementation notes / examples then get defined in docs/implementation/<MODEL>.md so users can see what is needed for the oxidized specific user (e.g. role/RBAC allowances, etc) or any version-specific gotchas/caveats that have been seen/reported.

As an implementation note for example - in fortios models, instead of toggling the system global for pagination, you can do a trick such as show | grep .* without having to set the default or give the oxidized user Read/write to toggle pagination each time.

Perhaps even a template of 'dear vendor - please support session-level pagination disable and export/import ability of text configuration' that folks can use if they encounter vendors that are not quite there. 😄

Just some random thoughts - happy to contribute where I can on any of the above.

Contributor

jsynack commented Nov 17, 2017

Some good discussions/points - My thoughts have been that the config should be copy-n-paste ready (or whatever config restoration method exists). Else the items should be commented (generic reporting on the model etc).

If the config as exported with a given command doesn't work in this fashion, it doesn't fulfill the ability for a reasonable restoration based on what oxidized has stored. So it would seem this should certainly be a model change / default behavior change if the current PANOS configs are not useful for quick/complete restoration (I dont have any devices to test with).

@laf - On the command changes -there are a few others that are similar (NOS and SLXOS support a similar syntax of command | nomore, and the SLX model was just adjusted to have role-specific adjustments for the oxidized user).

I think it probably would be best to define a list of oxidized least privilege and order of preference for model implementation and see how each of the models shape up. This can then be used as a guide of how to acquire content.

Something like (this is just random order as they came to me - feel free to adjust):

  • Prefer SCP/HTTPS/REST/FTP/HTTP/TFTP method to a model if possible and reliable. This excludes ability to get non-configuration items, but probably provides the cleanest configuration copy. Some devices support a scp oxidized@device:running-config blah style of syntax that removes all the pagination and scraping 'fun'. If non-configuration items are desired, they be probed via CLI and appended before committing to the backend output.
  • Read-only oxidized CLI user using a session-level pagination disable sent via post_login (sadly, not support session-level pagination disable).
  • Read-only oxidized CLI user with commands / pipes to disable pagination (eg command | nomore) - probably implemented as a capability of the model so the cmd command doesnt have to get too crazy and oxidized automatically adds the | nomore .
  • Read-only oxidized CLI user with user-level or system-level disable of pagination already set either in the configuration or arriving via AAA if the model supports it. (not ideal if it is a global setting as all sessions will then but non-paginated)
  • Model detects the pagination prompt on the device and continues automatically, trying to remove the device-specific --More-- (can be problematic)
  • Read-write oxidized user that can toggle the pagination at login. Set to disable prior to running commands and then restore to the default / sane value. It means technically the device configuration is slightly different than the repo, but it also means that the device/model doesnt have any of the other capabilities or they do not work reliably enough (software rev support, etc.)

Implementation notes / examples then get defined in docs/implementation/<MODEL>.md so users can see what is needed for the oxidized specific user (e.g. role/RBAC allowances, etc) or any version-specific gotchas/caveats that have been seen/reported.

As an implementation note for example - in fortios models, instead of toggling the system global for pagination, you can do a trick such as show | grep .* without having to set the default or give the oxidized user Read/write to toggle pagination each time.

Perhaps even a template of 'dear vendor - please support session-level pagination disable and export/import ability of text configuration' that folks can use if they encounter vendors that are not quite there. 😄

Just some random thoughts - happy to contribute where I can on any of the above.

@pv2b

This comment has been minimized.

Show comment
Hide comment
@pv2b

pv2b Nov 22, 2017

Contributor

Another strike against this patch - this behaviour will make oxidized save the candidate configuration, not the running configuration, which may not be what is actually desired.

Contributor

pv2b commented Nov 22, 2017

Another strike against this patch - this behaviour will make oxidized save the candidate configuration, not the running configuration, which may not be what is actually desired.

@laf

This comment has been minimized.

Show comment
Hide comment
@laf

laf Feb 27, 2018

Collaborator

@pv2b Is this PR something we should close down now then? Trying to get back on top of things in this repo so I'd like to close anything that is no longer needed.

Collaborator

laf commented Feb 27, 2018

@pv2b Is this PR something we should close down now then? Trying to get back on top of things in this repo so I'd like to close anything that is no longer needed.

@pv2b

This comment has been minimized.

Show comment
Hide comment
@pv2b

pv2b Feb 27, 2018

Contributor
Contributor

pv2b commented Feb 27, 2018

@laf

This comment has been minimized.

Show comment
Hide comment
@laf

laf Feb 27, 2018

Collaborator

@pv2b Thanks for responding. I've actually commented in that PR as well asking one of the other maintainers to take a look. Might be worth you looking at my comments as well and feeding back.

Collaborator

laf commented Feb 27, 2018

@pv2b Thanks for responding. I've actually commented in that PR as well asking one of the other maintainers to take a look. Might be worth you looking at my comments as well and feeding back.

@laf laf closed this Feb 27, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment