|
|
|||
|
||||
Rsh and telnet are Unix commands for accessing remote hosts (Windows has them now too. Kinda. Sorta). Using them, you can access the Command Line Interface (CLI) of the filer. While this is very useful for sysadmins performing ad hoc administrative tasks, there are good reasons for avoiding these techniques when writing scripts or programs.
| Summary |
With telnet, you log in using your username and password, and then issue commands exactly as if you were sitting at the filer console:
vero% telnet jeckle
Trying 172.24.1.20...
Connected to jeckle.lab.netapp.com.
Escape character is '^]'.
login: root
Password:
jeckle> Fri Feb 7 01:54:02 GMT [jeckle: telnet_0:info]: root logged in from host: vero.eng.netapp.com
jeckle> version
NetApp Release 6.4X10: Thu Jan 23 03:37:23 PST 2003
<1d>
jeckle> snap list
Volume vol0
working...
%/used %/total date name
---------- ---------- ------------ --------
0% ( 0%) 0% ( 0%) Feb 07 00:00 nightly.0
0% ( 0%) 0% ( 0%) Feb 06 20:00 hourly.0
0% ( 0%) 0% ( 0%) Feb 06 16:00 hourly.1
Volume vol1
working...
%/used %/total date name
---------- ---------- ------------ --------
11% (11%) 0% ( 0%) Feb 07 00:00 nightly.0
23% (14%) 0% ( 0%) Feb 06 20:00 hourly.0
32% (14%) 0% ( 0%) Feb 06 16:00 hourly.1
jeckle>
With rsh you don't have to log in, and you pass in a string which gets executed as if you had typed a single command at the console. After returning the console output of that command, rsh exits. :
vero% rsh heckle snap list
Volume nate_kitten1_1040097652
working...
%/used %/total date name
---------- ---------- ------------ --------
19% (19%) 0% ( 0%) Feb 07 00:00 nightly.0
35% (24%) 0% ( 0%) Feb 06 20:00 hourly.0
46% (23%) 0% ( 0%) Feb 06 16:00 hourly.1
Volume vol0
working...
%/used %/total date name
---------- ---------- ------------ --------
0% ( 0%) 0% ( 0%) Feb 07 00:00 nightly.0
0% ( 0%) 0% ( 0%) Feb 06 20:00 hourly.0
0% ( 0%) 0% ( 0%) Feb 06 16:00 hourly.1
vero %
With rsh, access is determined by the /etc/hosts.equiv file. (Google "online man pages rsh" for a man page describing the format of this file, and also see the filer man pages for hosts.equiv and rshd). Briefly, you enter hostnames and optionally user names:
vero joe
vero root
mayo
Above, users joe and root are able to rsh into the filer from host vero, and anyone can rsh in from host mayo.
Executing a simple "rsh <filer>" command doesn't log you into the shell, unlike on a Unix box, as there is no shell to run (the console is an integral part of the Data ONTAP operating system, not a program to run like Unix shells are). You can, however, execute multiple commands by separating them with a semicolon:
priv set -q advanced; help
for example, will print out the available advanced level commands. Like a Unix shell this time, the filer executes these rsh commands in a separate context; the above command doesn't affect the priv level of the current console session.
Additional information is in the SAG (System Administrator's Guide) sections on rsh and telnet.
| Issues |
The advantage of telnet/rsh, of course, is that the filer CLI is often the first available interface to new functionality. Unfortunately, the advantages end there.
A big issue is that parsing command line output is not easy. Edge cases such as reports in which a field is occasionally empty are common. Furthermore, CLI changes break code that previously worked. Network Appliance does try to minimize backwards-incompatible CLI changes, but longtime scriptwriting filer admins tend to look sceptical when we say that.
Using rsh from Windows code is particularly annoying in that Windows pops up a separate command line window, over which you have no control, while the rsh is running. If it's a command that takes a while, you're stuck with an ugly window in front of your application until the command returns. If there is a network partition, or the filer goes down, it will remain there until the TCP timeout expires, a couple minutes, during which the user is cussing you.
For these and other reasons, Network Appliances considers the use of telnet and rsh the "court of last resort" when writing management code. Your efforts to use other interfaces will be rewarded with easier-to-use and more well-behaved management applications
| Support |
The sample code and documents in the SDK are unsupported by Network Appliance CS. To obtain direct engineering support for your development effort and purchase incident packs, please contact Network Appliance by sending email to dl-manage-ontap-api@netapp.com.
Your feedback is important to us. If you have suggestions for improvement of this sample code or documentation, please send them to sdk-feedback@netapp.com.