Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

Using an Alternate Source Location for a Script

 

Refreshing a Script from an Alternate Location

In addition to updating a script from the master source defined by the source statement, you also can update a script from an alternate location using the set refresh-from configuration mode command or the request system scripts refresh-from operational mode command. This is convenient when, for example, the master source cannot be accessed due to network issues or other problems.

The update operation occurs as soon as you issue either the set refresh-from configuration mode command or the request system scripts refresh-from operational mode command. When you issue the command, the switch, router, or security device immediately attempts to connect to the specified URL and retrieve a copy of the file. The copy overwrites the local script stored in the scripts directory on the device. If a copy of the source is not available at the remote URL, 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.

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

If a device has dual Routing Engines and you want to update the script on both Routing Engines, you must issue the set refresh-from command on each Routing Engine separately. Alternatively, starting in Junos OS Release 13.2, 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. In operational mode, you can also use the request system scripts refresh-from command with the sync option to refresh the script on both Routing Engines.

To update a single script from an alternate source, issue the set refresh-from command under the hierarchy level where the script is configured, and specify the location of the remote file. The hierarchy location depends on the script type and filename as shown in the following examples:

To update all enabled scripts of a given script type from an alternate source, issue the set refresh-from command at the hierarchy level for that script type, and specify the URL of the remote repository that houses the scripts.

In operational mode, to update a single script from an alternate source, issue the request system scripts refresh-from command, and specify the script type, filename, and remote URL.

Where

  • filename—Name of the script.

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

If you request to refresh a script that does not exist at the remote site, the device generates an error message. For example:

user@host> request system scripts refresh-from op file nonexistent.slax url http://host1.juniper.net/nonexistent.slax

When you issue the set refresh-from command, Junos OS creates a folder in the /var/tmp directory, which is used for the file transfer. After the transfer and refresh operations are complete, Junos OS deletes the temporary folder.

Configuring the Routing Instance Used to Update a Script from an Alternate Source

Prior to Junos OS Release 18.1R1, scripts could be updated from an alternate 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 an alternate 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 a non-management routing instance to update scripts from an alternate source:

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

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

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

Note

To update scripts from an alternate 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.

Example: Refreshing a Script from an Alternate Source

The following example uses an alternate source location to update the local copy of the script on a device running Junos OS. The remote source is defined as an HTTP URL.

Requirements

  • Routing, switching, or security device running Junos OS.

Overview

You can update a script from a location other than that of the master source. This is convenient when, for example, the master source cannot be accessed due to network issues or other problems. You can refresh a single script or all scripts of a given type from the alternate location.

This example enables the op script iso.xsl on a device running Junos OS and then refreshes the script from a location other than the master source location. The remote source for the iso.xsl file is the HTTP URL http://my.example.com/pub/scripts2/iso.xsl.

You refresh the local script by issuing the set refresh-from configuration mode command at the hierarchy level where you configured the script. In this example, you would issue the set refresh-from command at the [edit system scripts op file iso.xsl] hierarchy level.

Configuration

Step-by-Step Procedure

To download and enable the script:

  1. Copy the script to the /var/db/scripts/op/ directory on the device.
  2. In configuration mode, configure the file statement to enable the iso.xsl script.

  3. Issue the commit and-quit command to commit the configuration and exit to operational mode.

Results

Verifying the Script

Purpose

Verify that the script is on the device and enabled in the configuration.

Action

Issue the file list operational mode command to view the files in the specified directory. The detail option provides additional information such as permissions, file size, and modified date.

user@R1> file list /var/db/scripts/op detail

Issue the show configuration system scripts op operational mode command to list the op scripts currently enabled on the device.

user@R1> show configuration system scripts op

Refreshing the Script from the Alternate Location

Step-by-Step Procedure

To refresh the local copy of the script from the alternate location:

  • In configuration mode, issue the set refresh-from command at the [edit system scripts op file iso.xsl] hierarchy level.

Verification

Verifying the Updated Script

Purpose

After refreshing the script, verify that the local copy is updated.

Action

Issue the file list operational mode command with the detail option to view the files in the specified directory. Verify that the modified date reflects the refreshed version.

user@R1> file list /var/db/scripts/op detail