13.2.7. Configuring Services: autofs

download PDF

About Automount, LDAP, and SSSD

Automount maps are commonly flat files, which define a relationship between a map, a mount directory, and a fileserver. (Automount is described in the Storage Administration Guide.)
For example, let's say that there is a fileserver called which hosts the directory pub, and automount is configured to mount directories in the /shares/ directory. So, the mount location is /shares/pub. All of the mounts are listed in the auto.master file, which identifies the different mount directories and the files which configure them. The auto.shares file then identifies each file server and mount directory which goes into the /shares/ directory. The relationships could be viewed like this:
   |                 |
   |                 |
/shares/        auto.shares
Every mount point, then, is defined in two different files (at a minimum): the auto.master and auto.whatever file, and those files have to be available to each local automount process.
One way for administrators to manage that for large environments is to store the automount configuration in a central LDAP directory, and just configure each local system to point to that LDAP directory. That means that updates only need to be made in a single location, and any new maps are automatically recognized by local systems.
For automount-LDAP configuration, the automount files are stored as LDAP entries, which are then translated into the requisite automount files. Each element is then translated into an LDAP attribute.
The LDAP entries look like this:
# container entry
dn: cn=automount,dc=example,dc=com
objectClass: nsContainer
objectClass: top
cn: automount

# master map entry
dn: automountMapName=auto.master,cn=automount,dc=example,dc=com
objectClass: automountMap
objectClass: top
automountMapName: auto.master

# shares map entry
dn: automountMapName=auto.shares,cn=automount,dc=example,dc=com
objectClass: automountMap
objectClass: top
automountMapName: auto.shares

# shares mount point
dn: automountKey=/shares,automountMapName=auto.master,cn=automount,dc=example,dc=com
objectClass: automount
objectClass: top
automountKey: /shares
automountInformation: auto.shares

# pub mount point
dn: automountKey=pub,automountMapName=auto.shares,cn=automount,dc=example,dc=com
objectClass: automount
objectClass: top
automountKey: pub
description: pub
The schema elements, then, match up to the structure like this (with the RFC 2307 schema):
                      objectclass: automountMap
                      filename attribute: automountMapName
   |                                               |
   |                                               |
/shares/                                       auto.shares
objectclass: automount                         objectclass: automountMap
mount point name attribute: automountKey       filename attribute: automountMapName
map name attribute: automountInformation           |
                                          objectclass: automount
                                          mount point name attribute: automountKey
                                          fileserver attribute: automountInformation
autofs uses those schema elements to derive the automount configuration. The /etc/sysconfig/autofs file identifies the LDAP server, directory location, and schema elements used for automount entities:
Rather than pointing the automount configuration to the LDAP directory, it can be configured to point to SSSD. SSSD, then, stores all of the information that automount needs, and as a user attempts to mount a directory, that information is cached into SSSD. This offers several advantages for configuration — such as failover, service discovery, and timeouts — as well as performance improvements by reducing the number of connections to the LDAP server. Most important, using SSSD allows all mount information to be cached, so that clients can still successfully mount directories even if the LDAP server goes offline.

Procedure 13.4. Configuring autofs Services in SSSD

  1. Make sure that the autofs and sssd-common packages are installed.
  2. Open the sssd.conf file.
    ~]# vim /etc/sssd/sssd.conf
  3. Add the autofs service to the list of services that SSSD manages.
    services = nss,pam,autofs
  4. Create a new [autofs] service configuration section. This section can be left blank; there is only one configurable option, for timeouts for negative cache hits.
    This section is required, however, for SSSD to recognize the autofs service and supply the default configuration.
  5. The automount information is read from a configured LDAP domain in the SSSD configuration, so an LDAP domain must be available. If no additional settings are made, then the configuration defaults to the RFC 2307 schema and the LDAP search base (ldap_search_base) for the automount information. This can be customized:
    • The directory type, autofs_provider; this defaults to the id_provider value; a value of none explicitly disables autofs for the domain.
    • The search base, ldap_autofs_search_base.
    • The object class to use to recognize map entries, ldap_autofs_map_object_class
    • The attribute to use to recognize map names, ldap_autofs_map_name
    • The object class to use to recognize mount point entries, ldap_autofs_entry_object_class
    • The attribute to use to recognize mount point names, ldap_autofs_entry_key
    • The attribute to use for additional configuration information for the mount point, ldap_autofs_entry_value
    For example:
  6. Save and close the sssd.conf file.
  7. Configure autofs to look for the automount map information in SSSD by editing the nsswitch.conf file and changing the location from ldap to sss:
    # vim /etc/nsswitch.conf
    automount: files sss
  8. Restart SSSD.
    # service sssd restart
Red Hat logoGithubRedditYoutubeTwitter


Try, buy, & sell


About Red Hat Documentation

We help Red Hat users innovate and achieve their goals with our products and services with content they can trust.

Making open source more inclusive

Red Hat is committed to replacing problematic language in our code, documentation, and web properties. For more details, see the Red Hat Blog.

About Red Hat

We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.

© 2024 Red Hat, Inc.