Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
panos (Palo Alto): Make it possible to configure configuration format #1101
Currently, the panos model retrieves and stores the configuraiton in the default configuration format that looks something like this:
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:
In order to accomplish this, the command
The current code uses the command
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.
referenced this pull request
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:
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.
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
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
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
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):
Implementation notes / examples then get defined in
As an implementation note for example - in
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.
I think this should be closed and instead the existing Panos support should be replaced to use the api model. See #1110Den 27 feb. 2018 3:35 em skrev Neil Lathwood <firstname.lastname@example.org>:@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. —You are receiving this because you were mentioned.Reply to this email directly, view it on GitHub, or mute the thread.