PDE GETHOST Help |
gethost - display network information to debug Kerberos configurations
B<gethost> [ B<-v> ] [ B<-c> [ B<-b> ]] [ B<-t> ] hostname B<gethost> [ B<-s> ] [ B<-t> ] hostname B<gethost> { B<-h> | B<-?> }
The gethost
utility always treats the machine that it is run on as a client
system. The hostname is assumed to be either a Teradata TDPID (system) name or
a the name of node in a Teradata system. For example, in a Teradata system
named "delmar", with nodes "delmar1" and "delmar2", any of those three names
could be used as a hostname.
With no options specified, gethost displays a summary of client, domain and
host information. For the client, the fully qualified domain name (FQDN) is
displayed. For the domain, the DNS domain name is displayed. For the hostname,
the FQDN, as returned by both getaddrinfo
(the forward DNS lookup) and
getnameinfo
(the reverse DNS lookup), is displayed. In addition, strings in
the form of "cop1", "cop2", "cop3", etc, are appended to the hostname, and the
FQDN of the result is displayed. This is done until one of the "cop" names
fails on the getaddrinfo
lookup. Furthermore, the associated IP address(es)
of each cop name and its corresponding FQDN resulting from the getnameinfo
lookup are displayed.
With the -v
option, gethost produces the summary information previously
mentioned, plus further details for the client system, the domain and the
Teradata nodes represented by the hostname.
With the -c
option, gethost builds a service principle name (SPN), as
used by Kerberos, from each of the cop entries and IP address entries. It then
does the first step of context initiation to see if the SPN has been registered
at the domain controller, and displays this information. This is useful for
debugging target name issues in Kerberos.
The -s
option prints the fully qualifed domain name of the hostname, and
returns. This makes it useful for use in scripts.
The -b
option is available in TDGSS only. When run from the TDGSS package
including the -b
option causes the gethost
utility to read TDGSS
configuration from the tdgssconfig.bin file rather than the TDGSSCONFIG GDO.
This option is useful when debugging Kerberos from Unity nodes.
The -t
option enables printing of time spent in functions that use network
services. This makes it useful for diagnosing poor Kerberos logon performance
involving network issues.
-v
Enable verbose mode. In this mode, more detailed information about the targets and client are produced.
-c
Check to see if the computed SPNs (service principal names) have been properly registered.
-b
When used in conjunction with -c
, causes gethost
to read configuration
from the tdgssconfig.bin file rather than the TDGSSCONFIG GDO. This option
is available only in the TDGSS package. Include it to test Kerberos
configurations on Unity nodes. Omit it to test Kerberos configurations on
database nodes.
-t
Prints the elapsed times spent resolving network names and addresses, as well as time spent communicating with a KDC to verify a service principal name.
Any unusual time spikes observed could provide clues about where the network issues lie.
-h
| -?
Display help information.
# B<gethost dbc>
Running on client machine: peach1.example.com Running in DNS Domain: example.com TERADATA HOST SERVERS dbc (host not found) dbccop1 dbc1.example.com dbccop2 dbc2.example.com dbccop3 dbc3.example.com dbccop4 dbc4.example.com 153.64.110.185 dbc1.example.com 153.64.110.186 dbc2.example.com 153.64.110.187 dbc3.example.com 153.64.110.188 dbc4.example.com
# B<gethost -c dbc>
Running on client machine: peach1.example.com Running in DNS Domain: example.com TERADATA HOST SERVERS dbc (host not found) dbccop1 dbc1.example.com dbccop2 dbc2.example.com dbccop3 dbc3.example.com dbccop4 dbc4.example.com 153.64.110.185 dbc1.example.com 153.64.110.186 dbc2.example.com 153.64.110.187 dbc3.example.com 153.64.110.188 dbc4.example.com SERVICE PRINCIPAL NAME (SPN) VERIFICATION FOR EACH TERADATA HOST SERVER Embedded configuration used. TERADATA/dbc1.example.com ok TERADATA/dbc2.example.com ok TERADATA/dbc3.example.com ok TERADATA/dbc4.example.com ok
# B<gethost -c -v dbc> Running on client machine: peach1.example.com Running in DNS Domain: example.com TERADATA HOST SERVERS dbc (host not found) dbccop1 dbc1.example.com dbccop2 dbc2.example.com dbccop3 dbc3.example.com dbccop4 dbc4.example.com 153.64.110.185 dbc1.example.com 153.64.110.186 dbc2.example.com 153.64.110.187 dbc3.example.com 153.64.110.188 dbc4.example.com SERVICE PRINCIPAL NAME (SPN) VERIFICATION FOR EACH TERADATA HOST SERVER TERADATA/dbc1.example.com ok TERADATA/dbc2.example.com ok TERADATA/dbc3.example.com ok TERADATA/dbc4.example.com ok DETAILED CLIENT INFORMATION NetBIOS Name: PEACH1 Physical DNS Domain Name: EXAMPLE.COM Phys DNS Fully Qual Name: peach1.EXAMPLE.COM Physical DNS Host Name: peach1 Physical NetBIOS Name: PEACH1 Fully Qual Domain Name: CN=PEACH1,CN=Computers,DC=EXAMPLE,DC=COM SAM Compatible Name: EXAMPLE\PEACH1$ Display Name: PEACH1$ Unique ID Name: {8c5df90a-cc00-4201-b828-b65011b6b4fe} Canonical Name: EXAMPLE.COM/Computers/PEACH1 Client Hosts File (C:\WINDOWS\system32\drivers\etc\hosts) 10.0.1.1 dbc1.example.com dbc1 dbc1cop1 dbccop1 10.0.1.2 dbc2.example.com dbc2 dbc2cop1 dbccop2 10.0.1.3 dbc3.example.com dbc3 dbc3cop1 dbccop3 10.0.1.4 dbc4.example.com dbc4 dbc4cop1 dbccop4 DETAILED DOMAIN INFORMATION Domain Controllers (P=PDC, K=KDC, T=Windows Time Service) (no Domain Controllers found) DETAILED HOST INFORMATION Host name: dbc - (No host servers found) Host name: dbccop1 Official host name: dbc1.example.com Number of associated addresses: 1 Reverse lookup of associated addresses: IP address: 153.64.110.185 Type: IPv4 Length: 4 Host name: dbc1.example.com Host name: dbccop2 Official host name: dbc2.example.com Number of associated addresses: 1 Reverse lookup of associated addresses: IP address: 153.64.110.186 Type: IPv4 Length: 4 Host name: dbc2.example.com Host name: dbccop3 Official host name: dbc3.example.com Number of associated addresses: 1 Reverse lookup of associated addresses: IP address: 153.64.110.187 Type: IPv4 Length: 4 Host name: dbc3.example.com Host name: dbccop4 Official host name: dbc4.example.com Number of associated addresses: 1 Reverse lookup of associated addresses: IP address: 153.64.110.188 Type: IPv4 Length: 4 Host name: dbc4.example.com
# B<gethost -t dbc> --- Elapsed Time for getaddrinfo: 7 ms Running on client machine: peach1.example.com Running in DNS Domain: example.com --- Elapsed Time for getaddrinfo: 116 ms --- Elapsed Time for getaddrinfo: 32 ms --- Elapsed Time for getaddrinfo: 32 ms --- Elapsed Time for getaddrinfo: 32 ms --- Elapsed Time for getaddrinfo: 31 ms --- Elapsed Time for getaddrinfo: 103 ms TERADATA HOST SERVERS dbc (host not found) dbccop1 dbc1.example.com dbccop2 dbc2.example.com dbccop3 dbc3.example.com dbccop4 dbc4.example.com 153.64.110.185 dbc1.example.com 153.64.110.186 dbc2.example.com 153.64.110.187 dbc3.example.com 153.64.110.188 dbc4.example.com --- Total Elapsed Time: 482 ms
Notice that this example shows six invoactions of getaddrinfo
. The first
invocation is for a machine named dbc
which is later noted to not exist.
This call took around a tenth of a second. The gethost
utility then begins
constructing node names by appending cop1
, cop2
, cop3
and cop4
to
the name dbc
. It finds all of these cop names, and each lookup takes around
three hundreths of a second. Finally, gethost
fails to find dbccop5
which takes about a tenth of second.
None.
PDE GETHOST Help |