Previous Article: Best Practices Series: Considerations for On-Box Data Storage and Access
Next Article: On-Box Storage: Option 2 - JUNOS Device Configuration as a Data Store
For SLAX version 1.0 and higher, you can pretty much always save data in a flat file of your choosing for your script. Using XML formatting on the data can be useful, and will save you having to develop/support your own parsing mechanism (since SLAX processes XML without breaking a sweat).
The<exsl:document> instruction element available in SLAX allows you to write your data to an output file on your local JUNOS device. It supports XML, HTML, or plain text formats.
Pros
It’s flexible; you can write/read whatever data your script has access to and will handle XML or text equally well.
Cons
- You still need to make sure you’re using valid XML or HTML when you use it.
- You have to exercise a little extra caution on file creation. (See “Gotchas” below).
- In multi-Routing Engine configurations, each Routing Engine maintains its own file system. You’re responsible for handling replication or synchronization of your data between the Routing Engines (if needed).
Gotchas
Using the <exsl:document> element without some care can potentially leave your local storage littered with files that may only be removed by a super-user at the CLI. The following except from The JUNOS Automation Reference for SLAX 1.0, explains this “gotcha” very concisely:
The <exsl:document> element always accesses the file system as user “nobody”. This means that files cannot be overwritten or appended unless their permissions give write access to user “nobody” or to everyone and files cannot be created unless the directory provides similar permissions.
As a consequence, when the <exsl:document> element creates an output file, it is owned by user “nobody” and its file permissions are (octal) 644, meaning that while anyone can read it, only user “nobody” can edit or delete it. (As of Junos OS 10.0R3 Release, super-users can delete these files from the CLI.)
As a workaround, create the file initially using the <file-put> RPC with permissions 666, giving everyone read and write access, then use<exsl:document> overwrite that original file. The resulting file will then be owned by the executing script’s user and will have the desired contents as created by <exsl:document>.
Written by Douglas McPherson
Solutions Consultant at Juniper