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:

Related topics

Configuration files overview

Configuring the users or users.local files

Configuring the secure file

Configuring the securecert file

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
`allowed=<username[:username]>`	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 `validusers` option except that the users named here are not required to have an account on the local system. The `allowed=` option is read before the `validusers=` option. If possible, use the `validusers` option instead of the allowed= option.
`anon=uid`	(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 `root=` option, described below. The default value for `anon=` is the UID of the user nobody. If the user nobody does not exist, the value 65534 is used. Setting `anon=-1` disables anonymous access. The value entered can be numeric or a user name. If a user name is entered, the corresponding UID and GID are determined and set accordingly. If a UID is entered, a corresponding GID is searched for. If the GID is not found, the GID is set to the GID for the user nobody.
`commands=<cmd1[:cmd2]>`	By default, TrueSight Server Automation clients are allowed to execute any command against an agent. The `commands=` option allows you to limit the commands a client can execute against an agent. See Restricting commands for more details on how to use this option.
`nomknod`	(UNIX only.) By default, clients are allowed to create special files (character special and block special). Specifying the `nomknod` option instructs the RSCD agent to prevent the client from making a mknod(2) call generating an EACCES (Permission denied) error.
`nosuid`	(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 `nosuid` option, the RSCD agent silently ignores any attempt to enable the setuid or setgid bits when creating a file or changing a file's permissions.
`ro`	All clients have read-only access except those listed in the `rw=` option. The `ro` option takes precedence over the `rw` option if both are defined. This is only applicable for NSH commands and not for the remote commands that are executed through the nexec utility.
`rw`	All clients have read-write access except those listed in the `ro=` option. The `ro` option takes precedence over the `rw` option if both are defined.
`rw=<hostname[:hostname]>`	Hosts listed in this option are granted read/write permissions. Hosts not specified have read-only permissions if `ro` is defined or they are listed in the `ro=` option. If `ro` is not set or the host is not listed in the `ro=` option, the client is denied access. If both the `ro=` and `rw=` options are defined, the `ro` and `rw` options are ignored. 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.
`ro=<hostname[:hostname]>`	Hosts listed in this option are granted read-only permissions. Hosts not specified have read/write permissions if `rw` is defined or they are listed in the `rw=` option. If `rw` is not set or the host is not listed in the `rw=` option, the client is denied access. If both the `ro=` and `rw=` options are defined, the `ro` and `rw` options are ignored. 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.
`root=<hostname[:hostname]>`	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.
`rootdir=<dirname>`	(Linux and UNIX only) By default, the rscd server allows the client to "see" the complete directory tree from / on down. By specifying the `rootdir=` option, the rscd server sets the "root" directory to `<dirname>` by making a call to or emulating chroot(2) . Clients can only see files and directories from `<dirname>` on down. When setting `rootdir=` on Windows systems, you can use the native file naming convention rather than a Network Shell path.
`rsu=<user[:user]>`	The client command `rsu` allows a client to get alternate remote permissions on the agent. By default the client is challenged for the user's password, but with the `-p` option no password is requested. The `rsu=` entry defines which users the client is allowed to rsu without challenging them for a password. If the client tries to use the `rsu` command with the `-p` option (that is, no password challenge) and then tries to switch to a user not in the list, access is denied.
`user=<username>`	This option forces all incoming client connections to run with the permissions of `<username>`. For Windows systems, you can enter Windows user account SIDs rather than user names. This option takes precedence over the `root=` and `anon=` options if they exist. The single entry you provide for `<username>` can be a user name or a numeric UID (UNIX only). On UNIX, if a user name is entered, the UID and GID for the user are determined and set accordingly. If the user name entered is not known, default user mapping applies. 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.
`validgroups=<groupname[:groupname]>`	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.
`validusers=<username[:username]>`	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 `validusers=` can be in the form of user names or numeric UIDs. User names and UIDs must correspond to a locally known user account. If no corresponding user account can be found, the entry is ignored.

Permission examples

The following code examples provide different levels of access to users and administrators.

Example	Description
`* ro,rootdir=/pubs,user=guest`	Allows customers access to software updates from servers. The asterisk means permissions apply to all clients unless there are other entries that define different permissions for specific hosts. Grants read-only access to all clients and maps all incoming connections so that users have "guest" privileges. The root directory for these users is set to /pubs.
`* 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. Notes: On Windows, the user name entered is validated against a list of local users on the machine. When using the exports file to set up user privilege mapping on Domain Controllers, map users to Administrator or an account in one of the BuiltIn groups.
`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: This configuration can be assigned when administrators (who typically work on Windows clients) need to manage remote UNIX servers. Because Windows machines have no inherent concept of root, a configuration entry such as this example is important if administrators working on Windows clients want to modify the configuration of UNIX servers. This entry would be added to the exports file on every remote server being managed by the two administrators.
`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 within a subnet, you first define the exception hosts and then define the default value for the remaining subnet. In this example, the host (`host1.foo.com`) has read/write privileges while everybody else in the subnet (subnet mask 255.255.255.192) has read-only privileges.
`@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 read/write privileges, while the range 128-255 has read-only privileges.

Configuring the exports file

About the exports file

To configure the exports file

Options for the exports file

Permission examples

Comments