Junos Automation (Scripting)
Junos Automation (Scripting)

Trying to understand scripting Junos Space

2 weeks ago

I am trying to setup a simple script to save the rescue config on the switches to get rid of the alarm. this is what the script looks like

<rpc-reply xmlns:junos="[http://xml.juniper.net/junos/12.3R6/junos](http://xml.juniper.net/junos/12.3R6/junos)">

<rpc>

<request-save-rescue-configuration>

</request-save-rescue-configuration>

</rpc>

<cli>

<banner>{master:0}</banner>

</cli>

</rpc-reply>

this is the error I get

Script is staged, but script enabled is failed. /var/db/scripts/commit/rescue.slax:1: unexpected '<'; file may be XML/XSLT /var/db/scripts/commit/rescue.slax: 1 error detected during parsing error reading stylesheet: rescue.slax 3 errors reported by commit scripts commit script failure

Im probably completely off base on how to implement this. I am new to this so I'm kinda lost.

1 REPLY 1
Junos Automation (Scripting)

Re: Trying to understand scripting Junos Space

yesterday

Hi,

OK, first things first. 

1.  Scripts can be either on-box (installed onto the Junos router/switch/firewall) or they can be off-box (installed on some suitable server, or Junos Space for that matter).

2.  On-box scripts  for Junos can be written in either SLAX, XSLT or depending upon the version of Junos running on the device Python.

3. On-box scripts for Junos Space can be written in either SLAX or XSLT only (as far as I know, I've not checked very recent Junos Space versions, but I doubt that it supports Python scripts yet, no matter how much we wish it would!).

 

What you have created is an on-box script but it isn't written in either SLAX or XSLT, in fact that is just the RPC structure...

 

So, next up I guess we should say that there are 4 different types of scripts that can be written for Junos, and they go in a different location and perform different tasks.

1. Operational (op) scripts - these get installed into /var/db/scripts/op and they allow a user from the CLI to execute the script, e.g. "op foo"

2.  Commit scripts - these get installed into /var/db/scripts/commit and they are executed automatically by Junos whenever there is an attempt to commit the candidate database to the running configuration of the device.  Typically these types of scripts are used to validate that a user has entered all the necessary configuration that is expected or some other stuff based upon an attempt to commit the configuration.

3. Event scripts - these get installed into /var/db/scripts/event and they are very similar to op scripts, however they are triggered by events rather than by a user executing a command.  These types of scripts can be scheduled via event options to trigger at specific times, or based on a wide range of criteriea e.g. traps or system events on Junos.

4. SNMP scripts - these get installed into /var/db/scripts/snmp and they react to SNMP requests for specific OIDs. They can then execute and collect some data and return it to the SNMP agent that made the request.  In effect giving the ability to add SNMP support for counters that don't actually exist on the device.

 

So, OK, where to begin with about learning to write SLAX scripts... first checkout the Juniper Day One archive:

https://forums.juniper.net/t5/Day-One-Books-Archive/bg-p/DayOneArchive

You will be interested in looking at the following:

This Week: Junos Automation Reference for SLAX 1.0

This Week: Mastering Junos Automation Programming

This Week: Applying Junos Automation

If you need to start understanding the XML data that you can get back from a Junos device and using XPATH to navigate through that data then the following book is also very useful.

Day One Book: Navigating the Junos XML Hierarchy

The op script that you will then need to create will be something along the lines of the folllwing:

 

version 1.0;
ns junos = "http://xml.juniper.net/junos/*/junos";
ns xnm = "http://xml.juniper.net/xnm/1.1/xnm";
ns jcs = "http://xml.juniper.net/junos/commit-scripts/1.0";

import "../import/junos.xsl"; var $local = jcs:open(); /* open connection to device */ match / { <op-script-results> { /* clear autorecovery state */ var $clear-rpc = <request-delete-rescue-configuration>; var $clear-results = jcs:execute($local,$clear-rpc); /* save autorecovery state */ var $save-rpc = <request-save-rescue-configuration>; var $save-results = jcs:execute($local,$save-rpc); expr jcs:close($local); /* Close connection to device */ } }

Once this is created as /var/db/scripts/op/rescue.slax then it is necessary to activate this script within the configuration of Junos.

e.g.

# set system scripts op file rescue.slax

# show | compare
[edit system scripts op]
+ file rescue.slax;

If you are deploying/staging the script via Junos Space onto the devices then you wouldn't need to adjust the configuration as Junos Space would manage that for the devices that the script is staged and deployed upon.

Then you can trigger the script to be executed from the CLI via the command "op rescue" in my example.

 

foo@mySRX> show system configuration rescue
error: No rescue configuration is set.

foo@mySRX> op rescue

foo@mySRX> show system configuration rescue
## Last changed: 2019-12-11 18:50:06 UTC
version 12.1X46-D40.2;

I realise that this is an awful lot to take onboard to begin with, I learnt SLAX by being thrown in at the deep end so to speak, but start off small, examine the examples in the books that I've mentioned and with some degree of trial and error it will start to make sense.

 

Of course, shout if you think you're stuck and can't get anywhere.

Regards

Andy