SLAX Development Environment

[Chip Gwyn]

Hi all,

  I'm trying to setup an environment where I can hack on some SLAX scripts without actually needing Juniper hardware.  I DO have plenty of Juniper kit in the network and I can pull any kind of output needed from them.  However I would like to have a workflow that didn't involve uploading a script to the device, running it, checking output, modifying, rinse-wash-repeat.  From talking to some folks it is my understanding that using juise and libslax/slaxproc I can do this.  What I imagine is something like getting output from a Juniper router and saving it in a file that I then develop against, using that as my "input", basically faking the router.

Sooooo.  I was hoping someone could provide me exactly what I need to get from the running router and then show me an example of how to run an op script using that input.  Or perhaps I'm misunderstanding the whole setup.

Can someone educate me?

Thanks!

--chip

[Phil Shafer]

On Jul 15, 2013, at 12:52 PM, Chip Gwyn wrote:

Sooooo.  I was hoping someone could provide me exactly what I need to get from the running router and then show me an example of how to run an op script using that input. 

This is exactly what juise does.  You'll need two pieces:

libslax - an implementation of the SLAX language
URL: https://github.com/Juniper/libslax
Wiki:  https://github.com/Juniper/libslax/wiki
Manual: http://juniper.github.io/libslax/slax-manual.html

juise: the JUNOS User Interface Scripting Environment
URL: https://github.com/Juniper/juise
Wiki:  https://github.com/Juniper/juise/wiki
Manual: http://juniper.github.io/juise/juise-manual.html

Juise adds the jcs:* functions to libslax, as well as hooks for testing op and commit scripts.

What environment are you building these in (mac, linux, windows, freebsd)?

Once you have these packages installed, running an op script is easy:

juise [[user]@target] script-name [name value]*

For example, this command line runs the "test.slax" script:

$ juise @my-router test.slax interface fe-0/0/0

which is equivalent to:

me@my-router> op test interface fe-0/0/0

Hope this helps....

Thanks, 
Phil

[Jeremy Schulman]

Hi Chip,

The technique I use is to save the output of each of the Junos commands to separate XML files.  You can do "<command> | save <filename.xml>".  You'll need to modify the files slightly to remove namespace bindings (if I recall correctly).   I then load the contents of those files to simulate the interaction with the Junos device.  The XSLT function "document()" is used to load arbitrary XML files into SLAX programs. 

There's probably a better way to do this, but this is the "brute force" approach I've used in the past.  If you want to check out a complex example, take a look at the "Junos Snapshot Adminstrator" application; written in SLAX.  You can find it here:
https://github.com/Juniper/junos-snapshot-administrator

HTH,
-- Jeremy

[Phil Shafer]

On Jul 16, 2013, at 9:17 AM, Jeremy Schulman wrote:

The technique I use is to save the output of each of the Junos commands to separate XML files.  You can do "<command> | save <filename.xml>".  You'll need to modify the files slightly to remove namespace bindings (if I recall correctly).   I then load the contents of those files to simulate the interaction with the Junos device.  The XSLT function "document()" is used to load arbitrary XML files into SLAX programs.  

Are you doing this for simplicity, reproducibility, or to work offline?  Or are the boxes you testing against not local/reachable?

I can make an op script that runs a command and writes the output of that command to a script so it can be served up by the NETCONF server that's built into juise (juise --server), so that you can run your script as "juise @localhost script-name".  Would that help?

Thanks,

 Phil