November 30, 2004, 3:13 PM — A few weeks, this column introduced its first troubleshooting scenario in which you, the reader, were asked to follow along as I unravelled one of the many little system administration problems that crop up in a normal work day. In that particular column, we tracked down a problem in which one of a pair of Solaris systems could not connect to a third system because it was provided the wrong IP address by the local DNS server.
This week, we're going to look at another command that can be helpful in situations of this type -- getent.
Getting an Entry with getent
While there are numerous ways to look up the IP address associated with a particular hostname, most of these methods imply that you have some knowledge about the sources that the system you are troubleshooting will be using. Thus, if you grep on a hostname in the /etc/hosts file, you may find an IP address for that system, but it may not be the one that the local system is using. Why? Because, until you look a little further -- at the /etc/nsswitch.conf file -- you won't know whether the entries in the /etc/hosts file take precedence over other sources of such information, such as DNS, NIS+ and LDAP. Similarly, if you use nslookup to find an IP address for the host in question, you have the same basic issue. Without looking at the /etc/nsswitch.conf file, you won't know whether the information retrieved is the same information that the local system will be using.
The getent command requires two arguments -- the name of the "database" that you want to search (for example, "hosts" or "passwd") and the particular record or "key" that you are searching for. Where you would type "nslookup bubba" to find a host in DNS, you would type "getent hosts bubba" to find the same host using getent. The benefit is that getent will determine which source the local system is using and look there. With getent, therefore, you are always looking for network information as the system itself will look for it.
Using getent, we might look up the host bubba.example.org:
# getent hosts bubba
10.215.214.213 bubba.example.org
Had we used nslookup instead, we might have received the same answer -- and generally would:
# nslookup bubba
Server: ns1.whatever.com
Address: 10.244.232.140
Name: bubba.example.org
Addresses: 10.215.214.213
The getent command isn't just for host lookups though. You can use it to look up entries from any of these databases: passwd, group, hosts, ipnodes, services, protocols, ethers, networks or netmasks.
bullfrog> getent passwd shs
shs:x:1234:10:Sandra Henry-Stocker:/export/home/shs:/bin/bash
bullfrog> getent services echo
echo 7/tcp
bullfrog> getent group staff
staff::10:
For each of these target databases, getent uses the appropriate library routines, such as gethostbyname or getipnodebyaddr.
If you were troubleshooting a connection issue and the getent command on the suspect host responded with an incorrect IP address for the target system, you would still have to determine why it was using a less than up-to-date source for host information. The getent command provides the answers requested without delineating the methods that it used to find them.
If your "getent hosts bubba" command, for example, replied that bubba was at the IP address 10.167.17.8 while you knew it to be 10.215.214.213, you would still need to look at the nsswitch.conf file to determine where the incorrect information was coming from.
