Configuring the exports file
This topic explains the purpose of the exports file, describes the available options, and details how to configure it. This topic includes the following sections:
About the exports file
The exports file determines which TrueSight Server Automation clients have access to a server. With the exports file you can set permissions on a per-client basis and, when necessary, use the users or users.local files to override those permissions for particular users. Often the exports file is used to set global permission that apply to users on all client machines.
For example, you can use the exports file to limit all clients to read-only permission on the server. Then you can use the users or users.local files to specify individual users who are granted read/write permission on that server.
Access permissions are defined for each individual RSCD agent and must be configured separately on each host where the RSCD agent is running. Updating the exports file on the host where you are running Network Shell or other TrueSight Server Automation applications does not set access permissions for managed servers.
When an rscd daemon starts on a server, it automatically reads the exports file. When changes are made to the exports file, the daemon automatically re-reads it. All subsequent client connections have the access permissions defined in the modified version of the exports file. Existing client connections are not affected by the changes. You do not have to restart the agent or otherwise instruct it to read the new exports file.
If the exports file does not exist or it does not contain any configuration information, you cannot establish a connection with an agent.
The exports file resides in different locations in Windows and UNIX systems, as described in the following table.
Platform | Location |
---|---|
Solaris, Linux, AIX, HP-UX | /etc/rsc/exports |
Windows | <WINDIR>\rsc\exports (For example, <WINDIR> can be \windows or \winnt.) |
The exports file does not grant permissions on Windows servers to roles that are set up for Windows user mapping. For information about Windows user mapping, see the Windows user mapping and agent ACLs. If you are using Windows user mapping to grant permissions to roles, the exports file might still include entries that apply to Windows servers. Only the user mapping information in the exports file is ignored.
The following topics provide more information about configuring the exports file.
To configure the exports file
Create entries that correlate the host names of clients with the permissions that should be granted to those clients. Use the following format for each entry:
<hostNnames> <option1...optionN>
<hostNnames>
is a list of comma-separated IP addresses, resolvable host names, or subnet designations. Subnet designations are used to define a range of addresses (see Subnet designations in configuration files). Using an asterisk instead of a list of host names defines default options that apply to any host not specifically named in the *exports* file.<option1...optionN>
is a list of comma-separated fields. Each option defines a type of access permission that applies to the hosts you have named in that entry. For a complete list of available options, see Options for exports file. If a single option sets multiple values, separate each value with a colon, as in the following:validusers=user1:user2
Lines in the exports file that begin with # are considered to be comments.
Options for the exports file
For each of the entries in the exports file, you can apply any of the options listed below. When defining multiple options, enter options in a comma-separated list.
Option | Description |
---|---|
| This option can be used to restrict access to specific users who do not have a local account. The user names entered here should be the login names of the users on the client machines. This option is similar to the |
| (UNIX only.) This option specifies how unknown users should be treated. If a request comes from an unknown user, the user is treated as an anonymous user and the effective user ID is uid. Root users (uid 0) are always considered "unknown" by the RSCD agent unless they are included in the |
| By default, TrueSight Server Automation clients are allowed to execute any command against an agent. The |
| (UNIX only.) By default, clients are allowed to create special files (character special and block special). Specifying the |
| (UNIX only.) By default, clients are allowed to create files with the setuid or setgid bits enabled and to set setuid and setgid permission using chown(2). If you specify the |
| All clients have read-only access except those listed in the |
| All clients have read-write access except those listed in the |
| Hosts listed in this option are granted read/write permissions. Hosts not specified have read-only permissions if You can specify host names and/or IP addresses (in IPv4 or IPv6 formats). However when using an IPv6 address, ensure that the server address is enclosed in square brackets. |
| Hosts listed in this option are granted read-only permissions. Hosts not specified have read/write permissions if You can specify host names and/or IP addresses (in IPv4 or IPv6 formats). However when using an IPv6 address, ensure that the server address is enclosed in square brackets. |
| This option gives root access to root users from specified hosts. The default is for no hosts to be granted root access. You can specify host names and/or IP addresses (in IPv4 or IPv6 formats). However when using an IPv6 address, ensure that the server address is enclosed in square brackets. |
| (Linux and UNIX only) By default, the rscd server allows the client to "see" the complete directory tree from / on down. By specifying the |
| The client command |
| This option forces all incoming client connections to run with the permissions of If a numeric UID is entered, then the corresponding UID on the server is used even if no known user account is associated with that UID. If an account is associated with a UID, then its corresponding GID is also set. On Windows, if a user name or user account SID is entered, it is validated against a list of local users on the machine. If the user name that is entered is not known, access to the machine is denied. Note that on Windows domain controllers, you can map a user to a domain user. The user name you enter is validated against the domain users on the domain controller. See How TrueSight Server Automation grants access to RSCD agents for more details. |
| This option allows you to specify user groups that are allowed access. Enter user groups in a colon (:) separated list. For each group name and/or GID entered, the RSCD agent looks at the effective GID of the calling user (as reported by the calling host) and only allows it access if the GID is in the specified list. If the GID is not in the list, the connection is refused. Group information can be provided in the form of group names or numeric GIDs. The comparison is done as a numeric equivalency and as such group names must be known on the local system to determine their corresponding GID. Numeric GIDs do not have to correspond to a local group name. Use /etc/groups to define group names. |
| This option allows you to specify users who are allowed access. Enter users in a colon (:) separated list. For each user name and/or UID that is entered, the RSCD agent looks up the corresponding UID and user name to create a user name/UID combination. The RSCD agent then matches the user name/UID combination to each attempted client connection. If the user name and UID of the client connection does not exactly match one of the user name/UID combinations generated by the daemon, the connection is refused. The user information you provide for |
Permission examples
The following code examples provide different levels of access to users and administrators.
Example | Description |
---|---|
* ro,rootdir=/pubs,user=guest |
|
* rw,nosuid,anon=-1 | Grants read/write access to all users but turns off the setting of setuid/setgid bits and denies unknown users access. |
admin1,admin2 rw,user=Administrator | Maps incoming connections from machines called admin1 and admin2 to the local user called Administrator.
|
host1,host2,host3 rw,rootdir=/reports,root=host1 host4,host5 ro,rootdir=/reports | Allows both read/write and read-only access for selected hosts, granting them root access from only one host and changing the root directory to /reports. |
host1,host2,host3 rw,rootdir=/reports,root=host1 host4,host5 ro,rootdir=/reports | Allows both read/write and read-only access for selected hosts, granting them root access from only one host and changing the root directory to /reports. |
* rw,allowed=sysadmin1:sysadmin2,user=root | Grants two users (sysadmin1 and sysadmin2 ) read/write permission for all servers, and also maps their user privileges to root. Notes:
|
host1.foo.com rw,root=host1.foo.com @host1.foo.com/26 ro | Defines exception hosts and values for subnets. To create different access (ro/rw) permissions for various hosts In this example, the host ( |
@192.168.10.1/24 rw=@192.168.10.1/25,ro=@192.168.10.129/25 | Splits an address range. In this example, an address range of 192.168.10.1-255 is split up such that the range from 1-127 has |
Comments