The ipdir2bin utility transfers the directory-based IP address restrictions to the IP GDO.
- From the /site directory on the lowest numbered Teradata database node, run the ipdir2bin utility, to commit directory IP restrictions to the database GDO.
$ ipdir2bin -u dir_username [-w dir_password] [-h dir_server_name] [-S system_name] Enter LDAP password: Parse successful 608 bytes written to the ipfilter GDO.
Option Description -u dir_username Required. Specifies the FQDN of the directory user running the utility. -w dir_password Optional. Specifies the password for the -u user.
If -w does not contain a value, the system prompts the user for a password.
-h dir_server_name Optional. Identifies the directory server.
If this option is not present in the statement, the utility uses the value for the LdapServerName property.
If the LdapServerName property is unavailable or not specified, the utility uses the name of the default directory server for the system. See LdapServerName.
The default directory server is specified by the administrator when:
- Adding a system to a domain
- Explicitly naming the server in the etc/ldap.conf file on a Teradata Database system running Linux
-S system_name Optional. Identifies the FQDN of the Teradata Database system, as it appears in the tdatSystem object in the directory.
If restrictions are configured for a single Teradata Database system, the tdatSystem object has the name of the system.
If directory users log on through Unity, the IP restrictions must be configured identically for all Teradata Database systems. IP restrictions for all database systems are the children of a single tdatSystem object.
- If -S does not specify a value, ipdir2bin uses the value of the LdapSystemFQDN property from the TDGSS configuration files.
- If the LdapSystemFQDN property also contains no value, the utility exits with an error.
The command populates the GDO and distributes it to all database nodes.
- To enable the committed restrictions, run the tpareset utility. See Utilities. This step is only necessary for the initial implementation of IP restrictions, and does not apply to revisions.
- If the fully enabled IP restrictions do not function as needed, you can:
- Edit the restrictions, retest them, as shown in Testing XML-Based IP Restrictions, and then re-enable them as shown in the first step.
- Disable the restrictions, as shown in Removing All IP Restrictions in an Emergency.
In most cases, Testing XML-Based IP Restrictions should uncover any problems before you enable them on the system.
- In a Unity environment, repeat this procedure for each Teradata Database system.