Bug 1262032

Since there is no install script prompting the admin for 
the LDAP server there really is no way to pre-able 
LDAP... And I don't see any script coming soon.

(In reply to Steve Dickson from comment #2)
> Since there is no install script prompting the admin for 
> the LDAP server there really is no way to pre-able 
> LDAP... And I don't see any script coming soon.

I don't see why an install script is required.  If you look at the additional info section of the bug, you will see that LDAP_server and LDAP_base are defined and yet the init script does not recognize it and fails to start.  This seems to be an issue with the init script rather than an install script.

(In reply to Jon L from comment #0)
> Actual results:
> Starting RPC idmapd: rpc.idmapd: umichldap_init: Missing required
> information: LDAP_server LDAP_base
> 
> rpc.idmapd: libnfsidmap: requested translation method, 'umich_ldap', is not
> available
> 
> rpc.idmapd: Unable to create name to user id mappings.
>                                                            [FAILED]
> 
> 
> Expected results:
> Service to start
> 
> Additional info:
> $ egrep '^Domain|^Method|^LDAP' /etc/idmapd.conf
> Domain = mydomain.tld
> Method = umich_ldap
> LDAP_server = ldap.mydomain.tld
> LDAP_base = dc=ldap,dc=mydomain,dc=tld
> $ sudo service rpcidmapd start
> Starting RPC idmapd: rpc.idmapd: umichldap_init: Missing required
> information: LDAP_server LDAP_base
> 
> rpc.idmapd: libnfsidmap: requested translation method, 'umich_ldap', is not
> available
> 
> rpc.idmapd: Unable to create name to user id mappings.
>                                                            [FAILED]
You are right... I'm not seeing the problem... the '^Domain|^Method|^LDAP'
reset to invalid setting and the service is failing... 

To start the service successfully those values would have to have
valid entries.

So what am I missing?

(In reply to Steve Dickson from comment #4)
> You are right... I'm not seeing the problem... the '^Domain|^Method|^LDAP'
> reset to invalid setting and the service is failing... 
> 
> To start the service successfully those values would have to have
> valid entries.
> 
> So what am I missing?

With the bug report I used the dummy domain of domain.tld and ldap.mydomain.tld for the LDAP server.  The report is that no matter what values are entered for LDAP_server and LDAP_base in idmapd.conf, rpcidmapd won't start.  If the values provided in the report do not follow the proper format for RPC idmapd to start, then perhaps the documentation in idmapd.conf should be updated.  The default is the following and even commenting out those lines and setting Method = umich_ldap, the service still won't start:

# server information (REQUIRED)
#LDAP_server = ldap-server.local.domain.edu

# the default search base (REQUIRED)
#LDAP_base = dc=local,dc=domain,dc=edu

What would be considered as valid entries for those two parameters in order for RPC idmapd to start?

I took a quick look at the relevant nfs-utils-lib code.  The relevant lines appear to be:

  char missing_msg[128] = "";
  ...
  server_in = conf_get_str(LDAP_SECTION, "LDAP_server");
  ldap_info.base = conf_get_str(LDAP_SECTION, "LDAP_base");
  ...
  if (server_in == NULL || strlen(server_in) == 0)
    strncat(missing_msg, "LDAP_server ", sizeof(missing_msg));
  if (ldap_info.base == NULL || strlen(ldap_info.base) == 0)
    strncat(missing_msg, "LDAP_base ", sizeof(missing_msg));
  if (strlen(missing_msg) != 0) {
    IDMAP_LOG(0, ("umichldap_init: Missing required information: "
                  "%s\n", missing_msg));
    goto fail;
  }

So it's not doing any kind of sanity checking on those values, it's really just checking that they're there.

So, I'm stumped.  I guess either there's some kind of syntax error in the idmapd.conf file (could we see the whole thing?), or it's not finding the config file (make sure rpc.idmapd isn't being started with a -c option?), or there's a bug in the config-file-reading code.

By the way, why are you interested in using umich_ldap?  For most people, the right thing to do is to leave idmapd and configure ldap with /etc/nsswitch.conf.

(In reply to J. Bruce Fields from comment #6)
> By the way, why are you interested in using umich_ldap?  For most people,
> the right thing to do is to leave idmapd

(Sorry, I meant "to leave idmapd using nsswitch".)

Below is my complete /etc/idmapd.conf (actual server names redacted for security purposes):

[General]
#Verbosity = 0
# The following should be set to the local NFSv4 domain name
# The default is the host's DNS domain name.
Domain = ldap.mydomain.tld

# The following is a comma-separated list of Kerberos realm
# names that should be considered to be equivalent to the
# local realm, such that <user>@REALM.A can be assumed to
# be the same user as <user>@REALM.B
# If not specified, the default local realm is the domain name,
# which defaults to the host's DNS domain name,
# translated to upper-case.
# Note that if this value is specified, the local realm name
# must be included in the list!
#Local-Realms =

[Mapping]

Nobody-User = nobody
Nobody-Group = nobody

[Translation]

# Translation Method is an comma-separated, ordered list of
# translation methods that can be used.  Distributed methods
# include "nsswitch", "umich_ldap", and "static".  Each method
# is a dynamically loadable plugin library.
# New methods may be defined and inserted in the list.
# The default is "nsswitch".
Method = umich_ldap

# Optional.  This is a comma-separated, ordered list of
# translation methods to be used for translating GSS
# authenticated names to ids.
# If this option is omitted, the same methods as those
# specified in "Method" are used.
#GSS-Methods = <alternate method list for translating GSS names>
GSS-Methods = umich_ldap,static

#-------------------------------------------------------------------#
# The following are used only for the "static" Translation Method.
#-------------------------------------------------------------------#
#[Static]

# A "static" list of GSS-Authenticated names to
# local user name mappings

#someuser@REALM = localuser


#-------------------------------------------------------------------#
# The following are used only for the "umich_ldap" Translation Method.
#-------------------------------------------------------------------#

#[UMICH_SCHEMA]

# server information (REQUIRED)
LDAP_server = server.ldap.mydomain.tld

# the default search base (REQUIRED)
LDAP_base = dc=ldap,dc=mydomain,dc=tld

#-----------------------------------------------------------#
# The remaining options have defaults (as shown)
# and are therefore not required.
#-----------------------------------------------------------#

# whether or not to perform canonicalization on the
# name given as LDAP_server
#LDAP_canonicalize_name = true

# absolute search base for (people) accounts
#LDAP_people_base = <LDAP_base>

# absolute search base for groups
#LDAP_group_base = <LDAP_base>

# Set to true to enable SSL - anything else is not enabled
#LDAP_use_ssl = false

# You must specify a CA certificate location if you enable SSL
#LDAP_ca_cert = /etc/ldapca.cert

# Objectclass mapping information

# Mapping for the person (account) object class
#NFSv4_person_objectclass = NFSv4RemotePerson

# Mapping for the nfsv4name attribute the person object
#NFSv4_name_attr = NFSv4Name

# Mapping for the UID number
#NFSv4_uid_attr = UIDNumber

# Mapping for the GSSAPI Principal name
#GSS_principal_attr = GSSAuthName

# Mapping for the account name attribute (usually uid)
# The value for this attribute must match the value of
# the group member attribute - NFSv4_member_attr
#NFSv4_acctname_attr = uid

# Mapping for the group object class
#NFSv4_group_objectclass = NFSv4RemoteGroup

# Mapping for the GID attribute
#NFSv4_gid_attr = GIDNumber

# Mapping for the Group NFSv4 name
#NFSv4_group_attr = NFSv4Name

# Mapping for the Group member attribute (usually memberUID)
# The value of this attribute must match the value of NFSv4_acctname_attr
#NFSv4_member_attr = memberUID

Red Hat Enterprise Linux 6 is in the Production 3 Phase. During the Production 3 Phase, Critical impact Security Advisories (RHSAs) and selected Urgent Priority Bug Fix Advisories (RHBAs) may be released as they become available.

The official life cycle policy can be reviewed here:

http://redhat.com/rhel/lifecycle

This issue does not meet the inclusion criteria for the Production 3 Phase and will be marked as CLOSED/WONTFIX. If this remains a critical requirement, please contact Red Hat Customer Support to request a re-evaluation of the issue, citing a clear business justification. Note that a strong business justification will be required for re-evaluation. Red Hat Customer Support can be contacted via the Red Hat Customer Portal at the following URL:

https://access.redhat.com/