Use an Alternate Source Location for a Script
Refresh 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
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, 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 one or more scripts using the set refresh-from
configuration mode command:
Alternatively, 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.
user@host> request system scripts refresh-from (commit | event | extension-service | op | snmp) file filename url url <sync>
Where
-
filename—Name of the script.
-
url—URL of the remote script or directory. Specify the source as an HTTPS URL, HTTP URL, FTP URL, or secure copy (scp)-style remote file specification.
If you specify an HTTPS URL, you must also include the cert-file
option in supported releases. The cert-file
option specifies the
path to the certificate (Root CA or self-signed) in PEM format that the device uses
to validate the server's certificate. For example:
user@host> request system scripts refresh-from op file ospf-neighbors.slax url https://example.juniper.net/scripts/ospf-neighbors.slax cert-file /var/tmp/root-ca-cert-example-juniper-net.pem refreshing 'ospf-neighbors.slax' from 'https://example.juniper.net/scripts/ospf-neighbors.slax' /var/home/user/...transferring.file........100% of
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 refreshing 'nonexistent.slax' from 'http://host1.juniper.net/nonexistent.slax' fetch-secure: http://host1.juniper.net/nonexistent.slax: Not Found error: file-fetch failed error: communication error: rpc failed (file-fetch) error: error retrieving file http://host1.juniper.net/nonexistent.slax
When you issue the set refresh-from
command, Junos OS creates a
temporary folder, which is used for the file transfer. After the transfer and
refresh operations are complete, Junos OS deletes the temporary folder.
See Also
Configuring the Routing Instance Used to Update a Script from an Alternate Source
Before Junos OS Release 18.1R1, scripts could be updated from
a alternate source using the default management interface. However,
starting in Junos OS Release 17.3R1, you are able to confine the management
interface in a nondefault virtual routing and forwarding (VRF) instance
so that management traffic no longer has to share a routing table
with other control or protocol traffic. Starting in Junos OS Release
18.1R1, you can specify a routing instance to use to refresh or download
a commit, event, JET, op, or SNMP script from a alternate source.
This routing instance can be either the nondefault management instance mgmt_junos
or some other routing instance.
You must configure the routing instance you specify to update
scripts through at the [edit system routing-instances]
hierarchy
level.
To use a non-management routing instance to update scripts from an alternate source:
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
.
See Also
Example: Refresh 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
- Download and Enable the Script
- Verify the Script
- Refresh the Script from the Alternate Location
- Verify the Updated Script
Download and Enable the Script
Step-by-Step Procedure
To download and enable the script:
Copy the script to the /var/db/scripts/op/ directory on the device.
In configuration mode, configure the
file
statement to enable the iso.xsl script.[edit system scripts op] user@R1# set file iso.xsl
Issue the
commit and-quit
command to commit the configuration and exit to operational mode.[edit] user@R1# commit and-quit
Results
system { scripts { op { file iso.xsl; } } }
Verify 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 /var/db/scripts/op: total 128 -rw-r--r-- 1 root admin 13897 Feb 10 2011 iso.xsl ...
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 file iso.xsl
Refresh 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.[edit system scripts op file iso.xsl] user@R1# set refresh-from http://my.example.com/pub/scripts2/iso.xsl
Verify 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 /var/db/scripts/op: total 128 -rw-r--r-- 1 root admin 14128 May 26 2011 iso.xsl ...
Change History Table
Feature support is determined by the platform and release you are using. Use Feature Explorer to determine if a feature is supported on your platform.