Command Line Interface (CLI)
This chapter introduces various ways to administer N series systems through the command line interface (CLI).
The following topics are covered:
19.1 Introduction to CLI administration
The CLI provides a command-based mechanism that is similar to the UNIX tcsh shell. On storage systems shipped with Clustered Data ONTAP 8.2 and later, secure protocols are enabled and non-secure protocols are disabled by default:
•Secure protocols (SSH v2 only) are enabled by default.
•Non-secure protocols (including RSH, Telnet) are disabled by default.
We advise using only the SSH Version 2 protocol and using SSH public key authentication. SSH public keys provide a stronger and more granular method of SSH access to N series storage systems.
The cluster has three different shells for CLI commands, the clustershell, the nodeshell, and the systemshell. Depending on the task you perform, you might need to use different shells to execute different commands:
•The clustershell is the native shell that is started automatically when you log in to the cluster. It provides all the commands you need to configure and manage the cluster.
The clustershell CLI help (triggered by ? at the clustershell prompt) displays available clustershell commands. The man command_name command in the clustershell displays the man page for the specified clustershell command.
•The nodeshell is a special shell containing a subset of commands that are available in 7-Mode Data ONTAP systems that take effect only at the node level. The nodeshell is accessible through the system node run command.
The nodeshell CLI help (triggered by ? or help at the nodeshell prompt) displays available nodeshell commands. The man command_name command in the nodeshell displays the man page for the specified nodeshell command.
•The systemshell is a low-level shell that is used only for diagnostic and troubleshooting purposes.
The systemshell is not intended for general administrative purposes. You access the systemshell only with guidance from technical support.
19.2 New features in Clustered Data ONTAP CLI
Starting with Clustered Data ONTAP, a new CLI was introduced. Commands in the CLI are now organized into a hierarchy by command directories. You can run commands in the hierarchy either by entering the full command path or by navigating through the directory structure.
You can use the top command to go to the top level of the command hierarchy, and the up command or .. command to go up one level in the command hierarchy.
It is also possible to abbreviate commands by entering only the minimum number of letters in a command that makes the command unique. For example, to abbreviate the command network interface show, you can enter n i show.
The CLI is also capable of command-line completion. You can type the first few characters of a command and press the completion key (Tab key) to fill out the rest of the command. In case of multiple possible completions, the CLI will list all possible parameters beginning with the specified characters. You can type more characters and press the Tab key again to complete the command or display possible parameters, including defaults, until you have built up the whole command.
Press the ? key at any time to get context-sensitive help.
Command history
Each CLI session keeps a history of all commands issued in it. You can view the command history of the session that you are currently in. You can also reissue commands. To view the command history, you can use the history command.
To reissue a command, you can use the redo command with one of the following arguments:
•A string that matches part of a previous command. For example, if the only volume command you have run is volume show, you can use the redo volume command to reexecute the command.
•The ID of a previous command, as listed by the history command. For example, you can use the redo 4 command to reissue the fourth command in the history list.
•A negative offset from the end of the history list. For example, you can use the redo -2 command to reissue the command that you ran two commands ago.
Query operators
The management interface supports queries, UNIX-style patterns and wildcards to match multiple values in command-parameter arguments.
See Table 19-1, which describes the possible query operators.
Table 19-1 Query operators
|
Operator
|
Description
|
|
*
|
Wildcard that matches all entries.
For example, the command volume show -volume *backup* displays a list of all volumes whose names include the string backup.
|
|
!
|
NOT operator.
For example, the command volume show -state !online displays a list of all volumes which are in a state that does not match the value online.
|
|
|
|
OR operator.
Separates two values that are to be compared.
For example, the command vserver show -vserver *cifs*|vs_* displays a list of all SVMs that contain the value cifs or begin with vs_.
|
|
..
|
Range operator.
For example, the command vol show -size 1GB..10GB displays all volumes that have a size between and including 1 GB and 10 GB.
|
|
<
|
Less-than operator.
For example, the command vol show -size <10GB displays all volumes smaller than 10 GB.
|
|
>
|
Greater-than operator.
For example, the command vol show -size >10GB displays all volumes bigger than 10 GB.
|
|
<=
|
Less-than-or-equal-to operator.
For example, the command vol show -size <=10GB displays all volumes smaller or equal than 10 GB.
|
|
>=
|
Greater-than-or-equal-to operator.
For example, the command vol show -size >=10GB displays all volumes bigger or equal than 10 GB.
|
|
Tip: You can use multiple query operators in one command line. For example, the command volume show -size >10GB -percent-used >80 -vserver vs_cifs* displays all volumes that are greater than 10 GB in size, more than 80% utilized, and in a storage virtual machine (SVM) whose name begins with “vs_cifs.”
|
Extended queries
You can use extended queries to match and perform operations on objects that have specified values.
You specify extended queries by enclosing them within curly brackets ({}). An extended query must be specified as the first argument after the command name, before any other parameters.
Example 19-1 sets offline all volumes whose names include the string temp.
Example 19-1 Extended query example 1
cluster01::> volume modify {-volume *temp*} -state offline
Example 19-2 enables compression on all volumes where it is disabled.
Example 19-2 Extended query example 2
cluster01::> sis modify {-compression false} -compression true
19.3 Audit logging
An audit log is a record of commands executed at the console through a telnet shell or an SSH shell or by using the rsh command. Administrative HTTP operations, such as those resulting from the use of System Manager or ONTAP API application, are logged. All login attempts to access the storage system, with success or failure, are also audit logged.
Clustered Data ONTAP enables you to audit two types of requests, set requests and get requests. A set request typically applies to non-display commands, such as creating, modifying, or deleting an object. A get request occurs when information is retrieved and displayed to a management interface. This is the type of request that is issued when you run a show command, for example.
You can configure auditing with the security audit modify command. By default, Clustered Data ONTAP is configured to save an audit log. The audit log data is stored in the /etc/log/mlog directory of every node in the files shown in Table 19-2.
Table 19-2 Audit log files
|
file
|
explanation
|
|
mgwd.log
|
Depending on the security audit settings, this file can include the following audit information:
•Set requests for the CLI (audited by default)
•Set requests for the ONTAP API (audited by default)
•Get requests for the CLI
•Get requests for the ONTAP API
The file also includes information about login attempts or failures.
For more information, see the man pages for the security audit commands.
|
|
command-history.log
|
Regardless of the settings for the security audit commands, set requests are always recorded in this file. This file is included in the AutoSupport to the specified recipients.
|
The command-history.log and mgwd.log files are rotated when they reach 100 MB in size, and their previous 34 copies are preserved (with a maximum total of 35 files, respectively).
You can display the content of the /etc/log/mlog directory by using a web browser if your cluster user account and the required web services have been configured for the access.
Example 19-3 shows how to create a user with read-only permissions to the web services and enable the web services so that the user is able to browse and download files from the /etc/log/mlog directory with a browser.
Example 19-3 Enable spi webservice
cdot-cluster01::> security login create -username webuser -application http -authmethod password -role readonly -vserver cdot-cluster01
Please enter a password for user 'webuser':
Please enter it again:
cdot-cluster01::> vserver services web modify -vserver cdot-cluster01 -name spi -enabled true
cdot-cluster01::> vserver services web access create -vserver cdot-cluster01 -name spi -role readonly
After the web service has been enabled, it is possible to browse the directory with the http(s) link as shown in Figure 19-1:
http(s)://cluster-mgmt-ip/spi/node-name/etc/log/mlog
Figure 19-1 Browse /etc/log/mlog directory
19.4 Accessing the cluster by using SSH
You can issue SSH requests to the cluster to perform administrative tasks. SSH is enabled by default.
Take note of the following information regarding SSH access:
•You must have a user account that is configured to use ssh as an access method. See the -application parameter in man security login for more information.
•The Clustered Data ONTAP 8.2 release family supports OpenSSH client version 5.4p1 and OpenSSH server version 5.4p1.
•Only the SSH v2 protocol is supported; SSH v1 is not supported.
•Clustered Data ONTAP supports a maximum of 64 concurrent SSH sessions per node.
•If the cluster management logical interface (LIF) resides on the node, it shares this limit with the node management LIF.
•If the rate of in-coming connections is higher than 10 per second, the service is temporarily disabled for 60 seconds.
•Clustered Data ONTAP supports only the AES and 3DES encryption algorithms (also known as ciphers) for SSH.
•If you want to access the Clustered Data ONTAP CLI from a Windows host, you can use a third-party utility such as PuTTY.
From an administration host, enter the ssh command in one of the following formats to access the cluster:
ssh username@hostname_or_IP [command]
ssh -l username hostname_or_IP [command]
If you are using an AD domain user account, you must specify username in the format of domainname\AD_accountname (with double backslashes after the domain name) or "domainnameAD_accountname" (enclosed in double quotation marks and with a single backslash after the domain name). This does not apply for a session from a Windows host with PuTTY. Use the username as it was specified when the user was created.
|
Note: If you use an Active Directory (AD) domain user account to access the cluster, an authentication tunnel for the cluster must have been set up through a CIFS-enabled SVM, and your AD domain user account must also have been added to the cluster with ssh as an access method and domain as the authentication method. Only one SVM is allowed to be used as a tunnel. See the man page of security login domain-tunnel for more information.
|
Note that hostname_or_IP is the host name or the IP address of the cluster management LIF or a node management LIF. Use of the cluster management LIF is advised. Use of command is not required for SSH-interactive sessions.
Example 19-4 shows how the user account named “admin” can issue an SSH request to access a cluster whose cluster management LIF is 9.155.66.26.
Example 19-4 SSH login to clustershell
$ ssh -l admin 9.155.66.26 date
Password:
Node Date Time zone
--------- ------------------------ -------------------------
cdot-01 Tue Oct 22 11:25:03 2013 Europe/Berlin
cdot-02 Tue Oct 22 11:25:03 2013 Europe/Berlin
2 entries were displayed.
$ ssh -l admin 9.155.66.26
Password:
cdot::> cluster show
Node Health Eligibility
--------------------- ------- ------------
cdot-01 true true
cdot-02 true true
2 entries were displayed.
19.5 Enabling Telnet or RSH access
Telnet and RSH are disabled in the predefined management firewall policy (mgmt). To enable the cluster to accept Telnet or RSH requests, you must create a new management firewall policy that has Telnet or RSH enabled and then associate the new policy with the cluster management LIF.
See the following steps for information about creating a new firewall policy and assigning it the cluster management LIF:
1. Use the system services firewall policy clone command to create a new management firewall policy based on the mgmt management firewall policy as shown in Example 19-5.
Example 19-5 Clone firewall policy
cluster01::> system services firewall policy clone -policy mgmt -new-policy-name mgmt_rsh_telnet
2. Use the system services firewall policy create command to enable Telnet or RSH in the new management firewall policy as shown in Example 19-6.
Example 19-6 Enable Telnet and RSH
cluster01::> system services firewall policy create -policy mgmt_rsh_telnet -service telnet -action allow -ip-list 0.0.0.0/0
cluster01::> system services firewall policy create -policy mgmt_rsh_telnet -service rsh -action allow -ip-list 0.0.0.0/0
3. Use the network interface modify command to associate the new policy with the cluster management LIF as shown in Example 19-7.
Example 19-7 Modify management LIF
cluster01::> network interface modify -vserver cluster01
-lif cluster_mgmt -firewall-policy mgmt_rsh_telnet
|
Note: Telnet and RSH are not supported on the service-processor (SP) or remote-lan-module (RLM). Enabling the protocols does not have an effect on SP or RLM.
|
19.5.1 Accessing the cluster by using Telnet
You can issue Telnet requests to the cluster to perform administrative tasks. Telnet is disabled by default.
Consider the following information regarding SSH access:
•You must have a cluster local user account that is configured to use Telnet as an access method. See the -application parameter in man security login for more information.
•Telnet must already be enabled in the management firewall policy that is used by the cluster or node management LIFs. See 19.5, “Enabling Telnet or RSH access” on page 332 for more information.
•Clustered Data ONTAP supports a maximum of 50 concurrent Telnet sessions per node.
•If the cluster management LIF resides on the node, it shares this limit with the node management LIF.
•If the rate of in-coming connections is higher than 10 per second, the service is temporarily disabled for 60 seconds.
•If you want to access the Clustered Data ONTAP CLI from a Windows host, you can use a third-party utility such as PuTTY.
From an administration host, enter the telnet command in one of the following formats to access the cluster:
telnet username@hostname_or_IP
Note that hostname_or_IP is the host name or the IP address of the cluster management LIF or a node management LIF. Using the cluster management LIF is advised.
|
Note: Telnet is not a secure protocol. Take care when using this protocol to maintain the storage and take precautions to ensure that your passwords and user IDs are not compromised in transit from the client to the storage system.
|
19.5.2 Accessing the cluster by using RSH
You can issue Telnet requests to the cluster to perform administrative tasks. Telnet is disabled by default.
Consider the following information regarding SSH access:
•You must have a cluster local user account that is configured to use Telnet as an access method. See the -application parameter in man security login for more information.
•RSH must already be enabled in the management firewall policy that is used by the cluster or node management LIFs. See 19.5, “Enabling Telnet or RSH access” on page 332 for more information.
•Clustered Data ONTAP supports a maximum of 50 concurrent RSH sessions per node.
•If the cluster management LIF resides on the node, it shares this limit with the node management LIF.
•If the rate of in-coming connections is higher than 10 per second, the service is temporarily disabled for 60 seconds.
From an administration host, enter the rsh command in one of the following formats to access the cluster:
rsh username@hostname_or_IP command
Note that hostname_or_IP is the host name or the IP address of the cluster management LIF or a node management LIF. Using the cluster management LIF is advised. Rather, command is the command you want to execute over RSH.
|
Note: RSH is not a secure protocol. Take care when using this protocol to maintain the storage and take precautions to ensure that your passwords and user IDs are not compromised in transit from the client to the storage system.
|
19.6 7-Mode to Clustered Data ONTAP
If you are moving from Data ONTAP running in 7-Mode to Clustered Data ONTAP, this chapter can provide you information about equivalents in Clustered Data ONTAP regarding some 7-Mode commands and configuration files.
19.6.1 Configuration files
In Data ONTAP operating in 7-Mode, you typically use flat files to configure the storage system. In Clustered Data ONTAP, you use configuration commands. Table 19-3 shows how 7-Mode configuration files map to Clustered Data ONTAP configuration commands.
Table 19-3 Configuration files map to Clustered Data ONTAP commands
|
7-Mode configuration file
|
Clustered Data ONTAP configuration command
|
|
/etc/cifs_homedir.cfg
|
vserver cifs home-directory search-path
|
|
/etc/exports
|
vserver export-policy
|
|
/etc/hosts
|
vserver services dns hosts
|
|
/etc/hosts.equiv
|
Not applicable. Use security login commands to create user access profiles.
|
|
/etc/messages
|
event log show
|
|
/etc/nsswitch.conf
|
vserver modify -ns-switch | -nm-switch
|
|
/etc/rc
|
In Clustered Data ONTAP, the retention of node configuration information processed at boot is transferred to other internal files that retain the configuration information. This contrasts with Data ONTAP operating in 7-Mode, in which features configured in memory are also retained in the /etc/rc file to be replayed at boot and reconfigured.
|
|
/etc/quotas
|
volume quota
|
|
/etc/resolv.conf
|
vserver services dns modify
|
|
/etc/snapmirror.allow
|
Intercluster relationships exist between two clusters. Intracluster relationships exist between two nodes on the same cluster. Authentication of the remote cluster occurs during the creation of the cluster peering relationship. Intracluster snapmirror create can be performed only by the cluster administrator to enforce per Vserver security.
|
|
/etc/snapmirror.conf
|
snapmirror create
|
|
/etc/symlink.translations
|
vserver cifs symlink
|
|
/etc/usermap.cfg
|
vserver name-mapping create
|
19.6.2 Commands
You can use Table 19-4 to determine the Clustered Data ONTAP equivalents of some useful 7-Mode commands.
Table 19-4 7-Mode commands map to Clustered Data ONTAP commands
|
7-Mode command
|
Clustered Data ONTAP command
|
|
aggr status
|
storage aggregate show
|
|
aggr show_space
|
system node run -node nodename aggr show_space
|
|
aggr status -f
|
disk show -broken
|
|
cf status
|
storage failover show
|
|
cf takeover
|
storage failover takeover -ofnode nodename
|
|
cf giveback
|
storage failover giveback -ofnode nodename
|
|
cifs domaininfo
|
vserver cifs domain discovered-servers show
|
|
cifs resetdc
|
vserver cifs domain discovered-servers reset-servers
|
|
disk zero spares
|
storage disk zerospares
|
|
environment status
|
system node environment sensors show
|
|
exportfs
|
vserver export-policy
|
|
halt
|
system node halt -node nodename
|
|
ifconfig -a
|
network interface show or
network port show
|
|
license
|
system license show
|
|
nfsstat
|
statistics show -object nfs*
|
|
passwd
|
security login password
|
|
ping {host}
|
network ping -node nodename -destination {host}
|
|
sp status
|
system node service-processor show
|
|
sysstat
|
statistics show-periodic
|
|
uptime
|
node show -node nodename -fields uptime
|
|
useradmin user list
|
security login show
|
|
version -b
|
system image show
|
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.