I was working on a project to stand up a NetApp array running Data OnTAP 8.1.2 and encountered the need to fire off some pretty large scale scripts. The scripts fulfilled the job of creating a very large number of volumes, qtrees, LUNs, LUN mapping, and various tuning options. I’ve not normally had to run such a large number of scripts in the past, but this was a rather large configuration.

My normal method of copy and paste into an SSH session was met with overflowing the buffer and general frustration. Also, when you have thousands of lines to paste in it becomes rather trivial to accidentally miss something. I dug through the Internets and the OnTAP command reference and stumbled upon a little gem.

The SOURCE Command

OnTAP has the ability to run a script file by way of the source command. It’s a bit heavy handed and just runs through a text list of commands without any sort of error catching or piping to other files, so its use may be limited in some scenarios. But for the initial configuration of a controller it should be a real beneficial command to leverage.

In this case, I dumped the various commands into a Notepad++ file (to ensure no rogue carriage returns snuck in). The file was then renamed to “something.txt” for making volumes, qtrees, etc. and uploaded to the /etc directory. To call the file, use the syntax:

source -v /etc/something.txt

The SSH console will then show the commands within the file being executed. If a command fails, you’ll see it in the list and can scroll up and down to find any errors (if they exist). This is why I’d suggest splitting your script files into smaller chunks so that you can view the results in your SSH session. Another option is to bump up the amount of cache held by the SSH session so that you can scroll back further.

If there are issues you can first resolve them and potentially just run the script again. Most any previously successful creation commands will just fail stating that the object already exists. This will vary depending on what you are scripting, but in my case was safe.

Thoughts

I’m always an advocate of using a method of scripting to eliminate as much potential human error as possible. In this case, using something like the source command gives an administrator an easy method of creating a master configuration than can either be duplicated on various controllers or handed down to junior members of the team via delegation. As always, it’s best to first test the scripts before running on an array hosting production workloads.