Access methods

What type of access is needed

The ways to access the storage system depend on the tasks you intend to perform. You can

Administer the storage system--To access the storage system to administer it, you only need network connectivity to the storage system and authentication privileges. No licenses are required to access the storage system to administer it.
Store data on the storage system--To store and retrieve data on the storage system, you must have an NFS or a CIFS license installed to access the storage system, mount system directories, and store data and retrieve data.

Accessing the storage system to administer it
(no licenses are required)

You can directly access a storage system to administer it using one of the following methods:

From a console that is attached by a cable to the storage system's serial port
From the Ethernet network interface card (NIC) that is preinstalled in the storage system. Use this card to connect to a TCP/IP network to administer the storage system:
- From any client by using a Telnet session
- From any client by using a Remote Shell connection
- From any client by using a Web browser and the FilerView interface
- From any client by using a secure shell client application, such as SSH, OpenSSH for UNIX hosts or PuTTY for Windows hosts (required for connecting the host to storage systems with an RLM installed)

Accessing the storage system to store and retrieve data (licenses are required)

You can directly access a storage system to administer it, and to store and retrieve data, using one of the following methods:

From a console that is attached by a cable to the storage system's serial port
From the Ethernet network interface card (NIC) that is preinstalled in the storage system. Use this card to connect to a TCP/IP network to administer the storage system, as well as to store and retrieve data:
- From an NFS client or CIFS client by using a Telnet session
- From an NFS client or CIFS client by using a Remote Shell connection
- From an NFS client or CIFS client by using a Web browser and the FilerView interface
- From an NFS or CIFS client by using a secure shell client application, such as SSH, OpenSSH for UNIX hosts or PuTTY for Windows hosts (required for connecting the host to storage systems with an RLM installed and using the console redirection feature)
- From an NFS client or CIFS client by using a Web browser and the DataFabric Manager interface (a DataFabric Manager license is also required)
- From a CIFS client to provide support for the SnapDrive^TM feature in a Windows environment
- From an NFS client or CIFS client to manage Fibre Channel switches (in a SAN environment)

Sharing a console session

You use the telnet.distinct.enable option to control whether the console session is shared with a Telnet or an SSH-interactive session at the same time or the console session is a distinct user environment separate from Telnet and SSH-interactive sessions. However, if you have the RLM installed in your storage system, the console session is always shared with the RLM session, regardless of the telnet.distinct.enable option setting.

The default setting for the telnet.distinct.enable option is Off. This causes the console session to share a Telnet or SSH-interactive session. The telnet.distinct.enable option also determines when the autologout program logs you out of a Telnet session.

Note
An SSH-interactive session is initiated by opening the session without entering a command. For example, you would enter the following command: ssh toaster -l root:"" (instead of ssh filer -l root:"" command, which initiates a non-interactive session).

Rules that apply to console, Telnet, and SSH-interactive sessions

The following rules apply to console, Telnet, and SSH-interactive sessions regardless of the telnet.distinct.enable option setting:

You cannot open more than one Telnet or SSH-interactive session at a time.
You cannot open a Telnet and an SSH-interactive session at the same time.
Note
You can prevent commands from being aborted at the console or through a Telnet or SSH session by using the rsh command to initiate commands from an administration host.

Sharing the console session

If the telnet.distinct.enable option is set to Off, the console shares a session with a Telnet or SSH-interactive session, and the following rules apply:

Commands typed at either the console or the Telnet or SSH-interactive session are echoed to the other location.
Pressing Ctrl-C aborts the current command regardless of where the command was entered.
Messages are displayed at both locations.
Auditlog entries identify all console commands as "console shell," as shown in the following example:
Fri Feb 18 12:51:13 GMT [toaster: rc:debug]: root:IN:console shell:df
Auditlog entries identify all Telnet and SSH-interactive commands as "telnet shell."
The autologout program logs the user out of the Telnet session after the number of minutes specified by the autologout.telnet.timeout option has elapsed. The timeout counter starts after the Enter or Return key is pressed. For example, if the autologout.telnet.timeout option is set to ten minutes, every time you press the Enter key, the timeout counter starts counting. If ten minutes elapse before you press the Enter key again, the autologout program logs you out.

Not sharing the console session

If the telnet.distinct.enable option is On, the console session has a distinct user environment and the following rules apply:

Commands that are typed at one location are not echoed to the other location.
Messages are not displayed at both locations.
User privileges are not shared between console and Telnet sessions.
Auditlog entries identify all console, Telnet, and SSH-interactive commands as "console shell."
The autologout program logs the user out of the Telnet session after the number of minutes specified by the autologout.telnet.timeout option has elapsed. The timeout counter starts after the command is executed.