Special considerations for Name Service
In some requests to the master server, the NetBackup Request Daemon/Service needs to confirm the configured name by which it knows the connecting client host. It does this by using the getnameinfo library function, supplied by the operating system, to query name services. The returned peer name is then compared to the client names known to the master server, both current clients in a policy and clients for which a backup image is available. If no match is found, then each known client is checked for hostname aliases using the getaddrinfo library function to query name services. The returned aliases are then compared to the peer name. This comparison is performed by the get_ccname function which will appear in the debug logs for the bprd process.
get_ccname: determine configured name for client2-nic2.veritas.com
get_ccname: configured name is: client2
If getnameinfo returns an unexpected peer name or the various getaddrinfo calls do not return a matching alias, problems occur.
One possible solution is to reconfigure name services, possibly via the master server hosts file. Another option is to create a special file in the altnames directory on the master server. The file provides a direct translation of the peer names to the client host names.
On Windows:
install_path\NetBackup\db\altnames\host.xlate
On UNIX:
/usr/openv/netbackup/db/altnames/host.xlate
Each line in the host.xlate file contains three elements: a numeric key and two host names. Each line is left-justified, and a space character separates each element of the line:
key peername_from_client_IP_address client_as_known_by_server
Where
key is a numeric value used by NetBackup to specify the cases where translation is to be done. Currently this value must always be 0, which indicates a configured name translation.
peername_from_client_IP_address is the value to translate.
client_as_known_by_server must match the name in the NetBackup configuration on the master server and must also be known to the media server's network services. It should also be known to the master server's network services.
Consider the following example:
0 xxxx xxxx.eng.aaa.com
The line specifies that when the master server receives a request for a configured client name (numeric key 0), the client name xxxx.eng.aaa.com is used for peer name xxxx.
The substitution resolves the problem if the following conditions are true:
When getnameinfo on the master server resolves the source IP from the client to xxxx, which is not a policy client and does not have any backup images.
When getaddrinfo on the master for the known policy and backup clients does not return an alias that matches the name xxxx.
The client was configured and named in the NetBackup configuration as xxxx.eng.aaa.com.