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.
It’s flexible; you can write/read whatever data your script has access to and will handle XML or text equally well.
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