Advanced Options

Using Variables in Configuration File Templates

In addition to static files, you may create templated ZTP configuration or script files. This is useful if your file needs to reference site- specific values such as an assigned IP addresses.

Any file uploaded via the web UI, or into the downloads directly with a file suffix of .j2 (Jinja2) will be automatically templated. The .j2 suffix is stripped when serving templated files to devices.

Available variables:

  • {{ nom_remote_server }}

    • Address of provisioning interface on the node

    • Example: 10.0.0.1

  • {{ nom_remote_interface }}

    • Name of provisioning interface on the node

    • Example: net2

  • {{ nom_remote_netmask }}

    • Netmask of provisioning interface on the node (and netmask assigned in DHCP offers)

    • Example: 255.255.255.0

  • {{ nomremotenetmaskcidr }}_

    • CIDR format netmask (prefix length) of provisioning interface on the node

    • Example: 24

  • {{ nom_remote_ntp_server }}

    • Address of NTP server assigned in DHCP offers (same as nom_remote_server)

    • Example: 10.0.0.1

  • {{ nom_remote_dns_server }}

    • Address of DNS server assigned in DHCP offers (same as nom_remote_server)

    • Example: 10.0.0.1

  • {{ nom_device_ipv4_address }}

    • This feature is only supported by Operations Manager nodes.

    • DHCP address assigned to target device

    • Example: 10.0.0.13

  • {{ nomremotesshpubkey }}

    • Public part of an auto-generated SSH keypair on the remote node, which may be injected into device config to pre- authenticate the node for any post-provisioning activities.

    • Example: ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDHO50MVT4A9Nl7vjDlS+76LgDBtEDm+J1gaQPNiIV62CGA6cm5wASDiddY/KZkHA

    • root@platypus.employee.bne.opengear.com (example only).

 

  • {{ nom_device_hostname }}

    • This feature is only supported by Operations Manager nodes.

    • Hostname advertised by target device

    • Example: router

  • {{ nom_device_mac_address }}

    Note:This feature is only supported by Operations Manager nodes.

  • MAC Address of target device

  • Example: 00:12:34:56:78:9A

For example, a basic Cumulus templated provisioning script may look like:

cumulus_setup.sh.j2

#!/bin/bash
curl tftp://{{nom_remote_server}}/cumulus_interfaces > /etc/network/interfaces

Post-provisioning Scripts

Note:This feature is only supported by Operations Manager nodes.

It is possible to upload a script and associated with a device Resource Bundle, to be run by remote Operations Manager node once a Managed Device is considered provisioned. A device is considered to be in a provisioned state once has downloaded all of the files in the Resource Bundle it is being provisioned with.

The script may be uploaded and associated via the UI during Resource Bundle creation using the Post-Provisioning Script option, or checked-in to the downloads directly via git/scp and specified in the YAML configuration for the device Resource Bundle:

demo_arista:
 device_type: arista
 config_file: 'demo_arista.cfg'
 image_file: 'arista_eos.swi'
 post_provision_script: arista_fixups_over_ssh.py
 post_provision_script_timeout: 900

Scripts may be implemented in bash, Python 2 or Python 3, and must start with a shebang – i.e. the first line must be one of:

#!/bin/bash
#!/usr/bin/env python2
#!/usr/bin/env python3

Notes:

  • Scripts are run in a monitored background processes in the Secure Provisioning container (remote-dop) on the node

  • Scripts have a default 15 minute timeout, this can be manually configured in the YAML config (postprovisionscripttimeout_)

  • Scripts may login to target device via the network using SSH key auth where nomremotesshpubkey has been injected into the device config (see Templated resource above), or using username/password with the sshpass command

Ordered Provisioning

Note:This feature is only supported by Operations Manager nodes.

The Provision After option allows you to create basic dependency chains, to enforce the order in which devices are provisioned. In certain scenarios it may be advantageous to control the order in which devices are provisioned, for example:

  • Ensure security infrastructure is provisioned ahead of systems that may other become inadvertently exposed on the network.

  • Bring the production WAN up early to allow devices to provision services in-band, saving cellular data.

  • Disallow local user access to the LAN until the network is fully up and running.

When a dependent Resource Bundle has the Provision After option set, the node will not respond to ZTP requests for these resources until all required dependencies have been met.

The Provision After property lists of one or more other, required Resource Bundles. Each required Resource Bundle creates a dependency that at least one device has been provisioned using the required bundle.

If multiples of a particular required device must be provisioned before a dependent device, simply specify the dependency multiple times in the list.

You may configure this via the UI during Resource Bundle creation using the Provision After option, or directly via git/scp in the YAML configuration for the device Resource Bundle:

access_switch:
 device_type: juniper
 config_file: 'jn-switch35.config'
 image_file: 'jinstall-ex-4200-13.2R1.1-domestic-signed.tgz'
 provision_after:
 - branch_router