/chronicle

One of the things I have always disliked about administering Windows servers and workstations is their inherent inability to act as a basic terminal. You’ve got to use terminal emulation software to login to NFS based firmware and appliances. Recently this became a huge issue when we were required to delete the contents of a volume on a NetApp SAN at Dillon Supply. Here was the scenario:

We have a volume vol0/dscsql2db on a NetApp FAS270 filer. Every night all of the NetApp “snapshots” on this volume need to be deleted. The snap delete command native to the snapdrive service on Windows 2003 servers cannot perform the force deletion of an entire volume. The snap delete command in the OS of the filer can delete the entire contents of a volume regardless of a snapshots state or condition. More specifically, one of the snapshots we wanted to delete is mounted as a read/writable volume on a server (busy, LUNs). Therefore the arguments available in the snap delete command on the filer are required.

So we needed a way to log on directly to the NetApp filer from within a Microsoft SQL DTS (Data Transformation Service) and execute the snap delete command to remove the entire contents of the volume. Basically, I needed to run a Vbscript as a job executed by a DTS against the Netapp filer. That’s where VanDyke CRT came in. I could have used custom expect scripts and spent a long time figuring out how to get them to run through Telnet. Instead we set up a default Telnet session for the CRT application to use when called by the parent DTS (by IP Address) then it automatically executes the following login script:

#$language = “VBScript”
#$interface = “1.0”

Sub main

‘ turn on synchronous mode so we don’t miss any data
crt.Screen.Synchronous = True

‘ Wait for a string that looks like “login: ” or “Login: ”
crt.Screen.WaitForString “ogin: ”

‘ Send your username followed by a carriage return
crt.Screen.Send “root” & vbCr

‘ Wait for a tring that looks like “password: ” or “Password: ”
crt.Screen.WaitForString “assword:”

‘ Send your password followed by a carriage return
crt.Screen.Send “ya, you wish” & vbCr

crt.Screen.WaitForString “etapp1”

‘ ++++ Begin Production commands to delete snapshots

crt.Screen.Send “snap delete -a -f -q dscsql2db” & vbCr

crt.Screen.WaitForString “etapp1”

crt.Screen.Send “snap delete -a -f -q dscsql2logs” & vbCr

‘ ++++ End Production commands to delete snapshots

‘ turn off synchronous mode to restore normal input processing

crt.Screen.Synchronous = False

‘ This will wait 30 seconds
crt.Sleep 30000
‘ dismiss the app
crt.quit

End Sub

Notice the crt.whatever.wait and .send vb scripting objects. It’s these objects included in CRT that made this all possible. Once the script command executes to delete the contents of the volume on the NetApp filer, it closes CRT and our SQL DTS can proceed with creating a new snapshot of our production database volume, mounting this snapshot to a remote server where it is then attached to MS SQL as one of the last steps. Bang! The refreshed reporting server is on-line.

None of this would have been possible without our $35 copy of CRT.