Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

Configuring and Using a Master Source Location for a Script

 

You can store a master copy of each script in a central repository. This eases file management because you can make changes to the master script in one place and then update the copy on each device where the script is currently enabled. This section discusses the following concepts:

Configuring the Master Source for a Script

To specify the location of the master source for a single script, configure the source statement and the URL of the master file. Including the source statement in the configuration does not affect the local copy of the script until you issue the set refresh command. At that point, the device retrieves the master copy from the specified URL and overwrites the local copy.

The hierarchy location for the source statement depends on the script type and filename.

  • Where

    • filename—Name of the script.

    • url—URL of the script’s master source file. Specify the source as a Hypertext Transfer Protocol (HTTP) URL, FTP URL, or secure copy (scp)-style remote file specification.

Configuring the Routing Instance Used to Update a Script from the Master Source

Prior to Junos OS Release 18.1R1, scripts could be updated from a master source using the default management interface. Starting in Junos OS Release 17.3R1, you are able to confine the management interface in a non-default virtual routing and forwarding (VRF) instance so that management traffic no longer has to share a routing table with other control or protocol traffic. As of Junos OS Release 18.1R1, you can specify a routing instance that is used to update a script from a master source as either the non-default management instance, mgmt_junos, or some other non-management routing instance.

Whichever routing instance you specify to update scripts must also be configured at the [edit system routing-instances] hierarchy level.

To use mgmt_junos to update scripts from a master source:

  1. Enable mgmt_junos by configuring the management-instance statement at the [edit system] hierarchy level.
  2. Configure the mgmt_junos routing instance at the [edit routing-instances] hierarchy level.
  3. Configure the mgmt_junos routing instance at one of the three routing-instance hierarchy levels for scripts:
    • For commit, op, or SNMP scripts, configure the mgmt_junos routing instance at the [edit system scripts (commit | op | snmp)] hierarchy level.

    • For event scripts, configure the mgmt_junos routing instance at the [edit event-options event-script file] hierarchy level.

    • For JET scripts, configure the mgmt_junos routing instance at the [edit system extensions extension-service application file] hierarchy level.

Note

To update scripts from a master source using a configured management interface, you can configure only mgmt_junos for the routing-instance-name. To use a non-management interface, you can configure anything for the routing-instance-name.

Updating a Script from the Master Source

If you configure a master source for one or more scripts on a device, you can refresh the scripts on that device using the set refresh configuration mode command. You can update a single script or all scripts of a given script type that have a master source location configured.

The update operation occurs as soon as you issue the set refresh command. When you issue the set refresh command, the switch, router, or security device immediately attempts to connect to the specified URL and retrieve a copy of the master file. The master copy overwrites the local script stored in the scripts directory on the device. If the load-scripts-from-flash statement is configured, the device updates the script on the flash drive instead of the script on the hard disk. If a master source is not defined for a script, that script is not updated and a warning is issued. For commit scripts, the updated commit script is executed when you next issue the commit command. If the script configuration includes the routing-instance statement, then Junos OS updates the script using that routing instance.

Note

Issuing the set refresh command does not add the refresh statement to the configuration. Thus the command behaves like an operational mode command by executing an operation, instead of adding a statement to the configuration.

The set refresh command is unique in the Junos OS CLI in that it behaves like an operational mode command and yet it can be executed from within configuration mode. All other Junos OS CLI operational mode commands can only be executed from command mode. The functionality is provided in this manner as a convenience to users developing commit scripts.

If the device has dual Routing Engines and you want to update a script on both Routing Engines, you must issue the set refresh command on each Routing Engine separately. Alternatively, you can refresh the scripts on the requesting Routing Engine and then use either the request system scripts synchronize operational mode command to synchronize scripts to the other Routing Engine or the commit synchronize scripts configuration mode command to synchronize all scripts to the other Routing Engine when you commit and synchronize the configuration. The commit synchronize command does not cause the refresh statement to update scripts on both Routing Engines.

To update a single script from its master source, issue the set refresh command at the hierarchy level where the script is configured. The hierarchy location depends on the script type and filename as shown in the following examples. The source statement specifying the master source location must already be configured.

  • Where filename is the name of the script.

To update all enabled scripts of a given script type from their master source files, issue the set refresh command at the hierarchy level for that script type.