CLI based WorkFLow

Advanced automation users may choose to manage device resources and resource distribution with direct access to the central ﬁle repository on Lighthouse.

All necessary resource and conﬁguration ﬁles are uploaded to Lighthouse using the Secure Copy protocol such as scp, WinScp or similar - or advanced users may prefer to use git directly.

If you have adopted DevOps-style conﬁguration management using your own source repository (such as git, Mercurial or Subversion) and/or conﬁguration deployment using continuous integration (such as Jenkins or GitLab), this interface also provides a convenient way to hook the Opengear system into these tools and workﬂows. For example, a conﬁguration commit in the upstream system could automatically proliferate to the Lighthouse ﬁle repository, and then in turn to the downstream nodes.

Note that changes pushed to nodes via the Lighthouse UI or API will override those made by direct repository access, therefore UI- based or CLI-based workﬂows should be considered mutually exclusive modes of operation.

Create CoNFIguration YAML

The ﬁrst step is to assign resource ﬁles to speciﬁc device types (collectively known as device resources), and to assign device resources to be deployed to speciﬁc nodes.

Tip: The web UI provides a convenient way to start provisioning managed devices without needing to be fully familiar with YAML or git. The generated YAML files that controls resource bundling and distributions is located on Lighthouse, inside the central-dop container. You can view it by running the following command:
sudo docker exec -it central-dop cat /srv/central-ui/root/config.yml | less

Use a YAML ﬁle to bundle device resources, and control the distribution of device resources from Lighthouse to the nodes.

PROCEDURE

Create a new directory or folder of your choosing, for example: nom-prov
Inside the nom-prov directory, create a new directory or folder called: downloads.
In the nom-prov directory, create a ﬁle with the .yml or.yaml extension, using the following format:

nom-prov.yml

device_resources:
demo_arista:
  device_type: arista
  config_file: 'demo_arista.cfg'
  image_file: 'arista_eos.swi'

node_inventory:
MyNodes:
  static:
  - nodes-1

deployment:
MyNodes:
- demo_arista

Note:Note that indentation is meaningful in YAML, and you must use space characters not tabs to indent.

The device_resources list groups and assigns resource ﬁles to particular device types (i.e. resource bundles).

Choose an identiﬁer for each resource bundle item, for example:. demo_arista.

For each item, you must provide the device_type, as well as well as one or more resources, ie. conﬁg_ﬁle or image_ﬁle.

device_type matches this device resource item to all devices from the speciﬁed vendor – it may be one of the folowing: Cisco, Cisco_xe, Cisco_xr, Cisco_nx, Juniper, Arista, Aruba, Huawei, Cumulus, Pica, Opengear.
conﬁg_ﬁle is the initial conﬁguration ﬁle for the device to load via ZTP, as present in the downloads directory.
image_ﬁle is the initial software image for the device to load via ZTP, as present int he downloads directory.

Note:HPE/Aruba devices do not support the image upgrade via ZTP.

The Cisco Autoinstall process does not support image upgrade via ZTP, to automate image upgrade you must supply a TCL script ﬁle rather than a conﬁguration ﬁle.

mac_address optionally target this bundle at the listed MAC address(es), which may be speciﬁed in full, using a wildcard (for example, 00:10:FA:C2:BF:*), or negated to exclude from the match (for example, !01:23:45:67:89:AB)
serial_number optionally target this bundle at the listed serial number(s)

Device resource items are then assigned to nodes using the deployment and optionally the node_inventory lists. See Node Inventory for an overview of available distribution methods.

The node_inventory list deﬁnes groups of nodes.

Choose an identiﬁer for each inventory, for example:. branchinventory_ or labinventory_

DeFIne a Static Inventory:

Create a list named static.
List nodes by node ID, for example, nodes-1.
You can view node IDs by running the following command on Lighthouse: node-info --all

Deﬁne a Dynamic Inventory:

Create a Lighthouse Smart Group, as documented in the Creating Smart Groups section of the Lighthouse User Guide.
Create a key named smartgroup with a value of the Smart Group name, this Smart Group search is dynamically evaluated to a list of nodes each time resources are pushed

The deployment list assigns device resources to the node inventories deﬁned above, or all nodes.

Deployment identiﬁers correspond to node_inventory identiﬁers, for example, branchinventory_ .
Assign device resources by listing device resource items, for example, demo_arista.
You may have multiple device resources per deployment.

A more comprehensive YAML ﬁle may look like:

more-devices.yml

device_resources:
access_switch:
  device_type: juniper
  config_file: 'jn-switch35.config'
  image_file: 'jinstall-ex-4200-13.2R1.1-domestic-signed.tgz'
  mac_address:
  - '00:00:0c:15:c0:*'
  - '!00:00:0c:15:c0:99'
branch_router:
  serial_number:
  - 'SAD15300D4W'
  - 'FOC1749N1BD'
  - 'AVJ18163A52'
  config_file: 'branch_xr.cfg'
  device_type: cisco_xr
demo_arista:
  device_type: arista
  config_file: 'demo_arista.cfg'
  image_file: 'arista_eos.swi'

node_inventory:
branch_inventory:
  static:
  - nodes-1
  - nodes-2
  - nodes-10
lab_inventory:
  smartgroup: LabNodes

deployment:
lab_inventory:
- demo_arista
- access_switch
branch_inventory:
- branch_router
- access_switch

How UI Fields Correspond to the YAML File (Example)

The following example YAML file contains line-by-line comments (blue text) denoting the UI page or field above each corresponding YAML element:

# CONFIGURE NODES > Secure Provisioning > Device Resources
device_resources:
# Device Resource Details > Name
access_switch:
  # Device Resource Details > Device Type
  device_type: juniper
  # Device Resource Details > Configuration File
  config_file: 'jn-switch35.config'
  # Device Resource Details > Image File
  image_file: 'jinstall-ex-4200-13.2R1.1-domestic-signed.tgz'
  # Device Resource Details > MAC Addresses
  mac_address:
  - '00:00:0c:15:c0:*'
  - '!00:00:0c:15:c0:99'
# Device Resource Details > Provision After
  provision_after:
  - branch_router

# Device Resource Details > Name
  branch_router:
  # Device Resource Details > Device Type
   device_type: cisco_xr
   # Device Resource Details > Serial Numbers
   serial_number:
   - 'SAD15300D4W'
   - 'FOC1749N1BD'
   - 'AVJ18163A52'
  # Device Resource Details > Configuration File
   config_file: 'branch_xr.cfg'

# Device Resource Details > Name
  demo_arista:
   # Device Resource Details > Device Type
   device_type: arista
   # Device Resource Details > Configuration File
   config_file: 'demo_arista.cfg.j2'
   # Device Resource Details > Image File
   image_file: 'arista_eos.swi'
   # Device Resource Details > Post-Provisioning Script
   post_provision_script: arista_fixups_over_ssh.py
   post_provision_script_timeout: 900
# CONFIGURE NODES > Secure Provisioning > Resource Distribution
node_inventory:
# Static Node Inventory List > Inventory Details > Name
BranchInventory:
  # Inventory Details > Select Nodes
  static:
  - nodes-1
  - nodes-2
  - nodes-10

# Dynamic Node Inventory List > Inventory Details > Name
LabInventory:
  # Inventory Details > Smart Group
  smartgroup: LabNodes

# CONFIGURE NODES > Secure Provisioning > Resource Distribution (mostly!)
deployment:

  # CONFIGURE NODES > Secure Provisioning > Resource Distribution        Inventory Details > Resource Push
  LabInventory:
  - demo_arista
  - branch_router
  - access_switch
  # CONFIGURE NODES > Secure Provisioning > Resource Distribution > Inventory Details > Resource Distribution
  BranchInventory:
  - branch_router
  - access_switch

Upload Conﬁguration and Resources

Assemble device resources on your PC or laptop in preparation for upload.
Locate the nom-prov directory created in the previous section
Copy device resources into nom-prov/downloads.

Your locally assembled ﬁles will now look similar to that below:

.
└── nom-prov
  ├── nom-prov.yml
  └── downloads
    ├── arista_eos.swi
    └── demo_arista.cfg

You must now choose how you will upload ﬁles to the central Secure Provisioning repository, using Secure Copy or git.

Option A. Secure Copy Method

Secure copy the entire nom-prov directory to Lighthouse port 2222, to the /srv/central-auto/ directory and authenticating as root, for example, using the scp command:

cd nom-prov
scp -P 2222 -rp ./* root@192.168.0.1:/srv/central-auto/

.. where 192.168.0.1 is the IP address of Lighthouse.

Secure Provisioning now automatically propagates the device resources to the nodes speciﬁed by the YAML, it automatically conﬁgures and starts or restarts ZTP services on the nodes.

At this point, target device will begin the ZTP process and become provisioned.

Option B. git Method

Advanced users may choose to access the Secure Provisioning git repository on Lighthouse directly, rather than using scp. This has the advantage of supporting commit messages and integrate with upstream git or other continuous integration systems.

Example commands to initialize the repository for the ﬁrst time:

ssh-copy-id root@192.168.0.1
cd nom-prov
git init
git remote add origin ssh://root@192.168.0.1:2222/srv/central
git add -A
git commit -a -m "Initial commit of ZTP resources"
git push origin master

.. where 192.168.0.1 is the IP address of Lighthouse.

Once the repository has been initialized, subsequent users can operate on it using the clone command:

ssh-copy-id root@192.168.0.1
git clone ssh://root@192.168.0.1:2222/srv/central nom-prov
cd nom-prov
echo >> nom-prov.yml
git commit -a -m "Whitespace change for testing, please ignore"
git push origin master

.. where 192.168.0.1 is the IP address of Lighthouse.

Additional Resource Files and Device Type Files

You may also provide additional resource ﬁles that are not explicitly part of Device Resource Bundles, for example, ﬁnal conﬁguration ﬁles that may be conditionally fetched and applied by the device's primary ZTP script.

You may also extend Secure Provisioning to support additional device types by providing ISC DHCP conﬁguration snippets, for example:

new-vendor.conf

class "new-vendor-class" {
match if (option vendor-class-identifier = "new-vendor";
option bootfile-name "new-vendor.cfg";
}

Additional ﬁles must be placed in the subdirectory named after the Node Inventory they will be deployed to. Within this subdirectory, ﬁles must be placed in the following:

Resource ﬁles such as device conﬁguration or image ﬁles are placed in the downloads directory.
Advanced: DHCP snippets may be placed in the dhcpd directory.

Directly added ﬁles are pushed together with YAML-generated ﬁles to the nodes. An example local directory structure is shown below with a YAML conﬁg ﬁle from the earlier example, as well as manual new-vendor ﬁles added to the my_inventory directory:

.
└── nom-prov
├── nom-prov.yml
├── downloads
│   ├── demo_arista.cfg
│   ├── cumulus_interfaces
│   ├── cumulus_setup.sh
│   └── arista_eos.swi
└── my_inventory
     ├── downloads
     │   └── new-vendor.cfg
     └── dhcpd
         └── new-vendor.conf

The ﬁles are uploaded to the central Secure Provisioning repository, using Secure Copy or git, in the same way as the earlier example.