Description of problem:
Gluster NFS server rejects client connection if rpc-auth is specified in volume file using hostname as opposed to IP address or '*'.

Version-Release number of selected component (if applicable):
Current github tree.

How reproducible:
Always reproducible after a specific config.

Steps to Reproduce:
1. Create and start a volume which gets exported over NFS.
2. Add rpc-auth entry for NFS server in volume file. Example:
 
 31: volume nfs-server
 32:     type nfs/server
 33:     option nfs3.gv0.volume-id 566f56a4-dbe5-4d3a-9b0e-8061c57b9ca8
 34:     option rpc-auth.addr.gv0.allow host1.localdomain
 35:     option nfs.nlm on
 36:     option nfs.dynamic-volumes on
 37:     subvolumes gv0
 38: end-volume
 Where 'host1.localdomain' is the remote client host name.

3. Restart gluster
4. Try to mount NFS from the remote client specified above.

Actual results:
NFS mount from the remote client fails with access denied.

Expected results:
Mount should succeed.

Additional info:
It appears that Gluster NFS translator is not handling rpc-auth.addr.*.allow option properly. The following hack makes the problem go away:

--- ./rpc/rpc-transport/socket/src/name.c.orig  2013-02-03 12:22:16.995837454 -0500
+++ ./rpc/rpc-transport/socket/src/name.c.new   2013-02-03 12:05:24.973842568 -0500
@@ -666,7 +666,7 @@
                            tmpaddr_len,
                            host, sizeof (host),
                            service, sizeof (service),
-                           NI_NUMERICHOST | NI_NUMERICSERV);
+                           NI_NUMERICSERV);
         if (ret != 0) {
                 gf_log (this->name, GF_LOG_ERROR,
                         "getnameinfo failed (%s)", gai_strerror (ret));

This however is not a fix as this will probably break IP address entries for the option. Ideally the NFS translator should map hostnames to IP and store them when initializing the volume config.