Introduction

opConfig 3 introduces the ability to 'push' configuration changes to devices, complete with error detection, support for change rollback and complete audit trails.

...

opConfig has always supported 'command sets', which consist of (individual) commands that can be sent to devices and whose output is collected and analyzed. Command sets are expected to be idempotentindependent, safely repeatable and without side effects. Command sets don't support sequencing or error detection, and thus are not suitable (or intended!) for modifying device configurations.

...

The primary storage and exchange format for config sets is JSON; example config  sets can be find found in install/config_sets.d/ and it is recommended that you store your actively developed config sets in conf/config_sets.d/.

...

1. an explicit single value
   for example,  "os_info.platform": "x86_64" would match if the node's OS platform value is exactly equal to "x86_64".
2. a list of alternative values
   for example "name": [ "nodeA", "nodeB"] would match either of the two nodes named nodeA or nodeB. The comparison is again strict equality.
   The filter clause is considered a match if one or more choices amongst the list of alternatives do match.
   1. If you are using the GUI, just introduce a list of node names separated by commas. 
3. a regular expression
   for example "os_info.os":  "/IOS/i" would select nodes whose OS contains the string "IOS" (or "ios", "IoS" etc.) anywhere.
   Note that the regular expression must be given as a string, starting and ending with a "/" and optionally including the "i" modifier for case-insensitive matching.

...

{
    "name": "IOS - Configuration Best Practices",
    "description": "A configuration set to configure the IOS device, by enabling and disabling various services and features.",
    "filter":
    {
        "os_info.os": "IOS"
    },
    "notify": { "email": "you@company.com" },
    "error_handling":
    {
        "match": [ "/Invalid input detected/" ],
        "break_on_error": false
    },
    "pre-commands":
    [
        "_reload_in 5"
    ],
    "commands":
    [
    "no ip http server",
    "no ip http secure-server",
    "no ip finger",
    "no service finger",
    "no service udp-small-servers",
    "no service tcp-small-servers",
    "no boot network",
    "no service config",
    "service password-encryption",
    "service timestamps debug datetime msec",
    "service timestamps log datetime msec",
    "service sequence-numbers",
    "service tcp-keepalives-in",
    "service tcp-keepalives-out",
    "no ip source-route",    
    "line con 0 ",
    "exec-timeout 10 0",
    "exit",
    "line vty 0 4",
    "exec-timeout 10 0",
    "exit"
    ],
    "post-commands":
    [
        "reload cancel"
    ]
}

Config Set GUI

From opConfig 4.2.6 it is possible to edit the config sets in the GUI. 

In the menu System > Manage Config Sets you can access the editor: 

Image Added

Please note, once a config set is saved, a new version will be created in the database. 

It is not possible to delete a config set, but you can export one in json format:

Image Added

Config Set Parameters

From opConfig 4.2.6 it is possible to use parameters in a config set. 

The parameters are global to commands, pre commands or post commands, and are specified with the parameter name preceded by $

Example

Image Added

Using a config set with parameters

cli Example

Using the cli tool opconfig-cli, you can specify parameters to push a config set using parameter.parametername, like:

./opconfig-cli.pl act=push_configset name="my configset" parameter.interface=Tunnel100 parameter.description="Configuration change example" debug=2

GUI Example

Using the GUI, if a config set has parameters, you will have a second modal window to specify all the needed parameters:

Image Added

Config set parameters will be introduced on a second screen: 

Image Added