Red Hat Training
A Red Hat training course is available for RHEL 8
Chapter 111. Using Ansible to automount NFS shares for IdM users
Automount is a way to manage, organize, and access directories across multiple systems. Automount automatically mounts a directory whenever access to it is requested. This works well within an Identity Management (IdM) domain as it allows you to share directories on clients within the domain easily.
You can use Ansible to configure NFS shares to be mounted automatically for IdM users logged in to IdM clients in an IdM location.
The example in this chapter uses the following scenario:
- nfs-server.idm.example.com is the fully-qualified domain name (FQDN) of a Network File System (NFS) server.
- nfs-server.idm.example.com is an IdM client located in the raleigh automount location.
- The NFS server exports the /exports/project directory as read-write.
- Any IdM user belonging to the developers group can access the contents of the exported directory as /devel/project/ on any IdM client that is located in the same raleigh automount location as the NFS server.
- idm-client.idm.example.com is an IdM client located in the raleigh automount location.
If you want to use a Samba server instead of an NFS server to provide the shares for IdM clients, see the How do I configure kerberized CIFS mounts with Autofs in an IPA environment? KCS solution.
The chapter contains the following sections:
- Autofs and automount in IdM
- Configuring an IdM keytab for an NFS server
- Exporting NFS shares in IdM
- Preparing your Ansible control node for managing IdM
- Configuring automount locations, maps, and keys in IdM by using Ansible
- Using Ansible to add IdM users to a group that owns NFS shares
- Configuring automount on an IdM client
- Verifying that an IdM user can access NFS shares on an IdM client
111.1. Autofs and automount in IdM
The autofs
service automates the mounting of directories, as needed, by directing the automount
daemon to mount directories when they are accessed. In addition, after a period of inactivity, autofs
directs automount
to unmount auto-mounted directories. Unlike static mounting, on-demand mounting saves system resources.
- Automount maps
On a system that utilizes
autofs
, theautomount
configuration is stored in several different files. The primaryautomount
configuration file is/etc/auto.master
, which contains the master mapping ofautomount
mount points, and their associated resources, on a system. This mapping is known as automount maps.The
/etc/auto.master
configuration file contains the master map. It can contain references to other maps. These maps can either be direct or indirect. Direct maps use absolute path names for their mount points, while indirect maps use relative path names.- Automount configuration in IdM
While
automount
typically retrieves its map data from the local/etc/auto.master
and associated files, it can also retrieve map data from other sources. One common source is an LDAP server. In the context of Identity Management (IdM), this is a 389 Directory Server.If a system that uses
autofs
is a client in an IdM domain, theautomount
configuration is not stored in local configuration files. Instead, theautofs
configuration, such as maps, locations, and keys, is stored as LDAP entries in the IdM directory. For example, for theidm.example.com
IdM domain, the default master map is stored as follows:dn: automountmapname=auto.master,cn=default,cn=automount,dc=idm,dc=example,dc=com objectClass: automountMap objectClass: top automountMapName: auto.master
Additional resources
111.2. Configuring an IdM keytab for an NFS server
Configure a Kerberos-aware NFS server so that users logged in to other Identity Management (IdM) clients can access directories and files on this NFS server.
The example describes how to configure NFS service running on nfs-server.idm.example.com.
Prerequisites
- You are logged in as an IdM administrator.
-
You have
root
access to the NFS server. - You have installed the required packages to export NFS shares.
- [Optional] You have configured the NFS server to run behind a firewall.
Procedure
On any IdM-enrolled host, add the NFS service to IdM:
$ ipa service-add nfs/nfs-server.idm.example.com ------------------------------------------------------------ Added service "nfs/nfs-server.idm.example.com@IDM.EXAMPLE.COM" ------------------------------------------------------------ Principal name: nfs/nfs-server.idm.example.com@IDM.EXAMPLE.COM Principal alias: nfs/nfs-server.idm.example.com@IDM.EXAMPLE.COM Managed by: nfs-server.idm.example.com
On the NFS server, obtain the keytab for the NFS service:
# ipa-getkeytab -p nfs/nfs-server.idm.example.com -k /etc/krb5.keytab Keytab successfully retrieved and stored in: /etc/krb5.keytab
On the NFS server, restart the NFS service:
# systemctl restart nfs-server
On the NFS server, enable the NFS service:
# systemctl enable nfs-server Created symlink /etc/systemd/system/multi-user.target.wants/nfs-server.service → /usr/lib/systemd/system/nfs-server.service.
111.3. Exporting NFS shares in IdM
As an Identity Management (IdM) system administrator, you can use an NFS server to share a directory with IdM users over the network.
Prerequisites
- You are logged in as an IdM administrator.
-
You have
root
access to the NFS server. - You have installed the required packages to export NFS shares.
- [Optional] You have configured the NFS server to run behind a firewall.
Procedure
Create the directory you want to export:
# mkdir -p /exports/project
Give the owner and group the rights to read, write and execute the directory:
# chmod 770 /exports/project
Add the
GSID
sticky bit so that any files created in the directory will have their group ownership set to that of the directory owner:# chmod g+s /exports/project
Create a file in the directory with some content:
# echo "this is a read-write file" > /exports/project/rw_file
To a file in the
/etc/exports.d/
directory, add the following information:- Which directory you want to export
- How you want users to authenticate to access the files in the directory
What permissions you want users to have on the files in the directory
# echo "/exports/project *(sec=krb5,rw)" > /etc/exports.d/project.exports
sec=krb5
uses the Kerberos V5 protocol instead of local UNIX UIDs and GIDs to authenticate users.
Alternatively, use
sec=krb5i
orsec=krb5p
:sec=krb5i
- uses Kerberos V5 for user authentication and performs integrity checking of NFS operations using secure checksums to prevent data tampering.
sec=krb5p
- uses Kerberos V5 for user authentication, integrity checking, and encrypts NFS traffic to prevent traffic sniffing. This is the most secure setting, but it also involves the most performance overhead.
Re-export all directories, synchronizing the main export table kept in
/var/lib/nfs/etab
with/etc/exports
and files under/etc/exports.d
:# exportfs -r
Display the current export list suitable for
/etc/exports
:# exportfs -s /exports/project *(sync,wdelay,hide,no_subtree_check,sec=krb5p,rw,secure,root_squash,no_all_squash)
Additional resources
-
For information on
krb5
methods, see thenfs
man page.
111.4. Preparing your Ansible control node for managing IdM
As a system administrator managing Identity Management (IdM), when working with Red Hat Ansible Engine, it is good practice to do the following:
- Create a subdirectory dedicated to Ansible playbooks in your home directory, for example ~/MyPlaybooks.
-
Copy and adapt sample Ansible playbooks from the
/usr/share/doc/ansible-freeipa/*
and/usr/share/doc/rhel-system-roles/*
directories and subdirectories into your ~/MyPlaybooks directory. - Include your inventory file in your ~/MyPlaybooks directory.
By following this practice, you can find all your playbooks in one place and you can run your playbooks without invoking root privileges.
You only need root
privileges on the managed nodes to execute the ipaserver
, ipareplica
, ipaclient
, ipabackup
, ipasmartcard_server
and ipasmartcard_client
ansible-freeipa
roles. These roles require privileged access to directories and the dnf
software package manager.
This section describes how to create the ~/MyPlaybooks directory and configure it so that you can use it to store and run Ansible playbooks.
Prerequisites
- You have installed an IdM server on your managed nodes, server.idm.example.com and replica.idm.example.com.
- You have configured DNS and networking so you can log in to the managed nodes, server.idm.example.com and replica.idm.example.com, directly from the control node.
-
You know the IdM
admin
password.
Procedure
Create a directory for your Ansible configuration and playbooks in your home directory:
$ mkdir ~/MyPlaybooks/
Change into the ~/MyPlaybooks/ directory:
$ cd ~/MyPlaybooks
Create the ~/MyPlaybooks/ansible.cfg file with the following content:
[defaults] inventory = /home/your_username/MyPlaybooks/inventory [privilege_escalation] become=True
Create the ~/MyPlaybooks/inventory file with the following content:
[ipaserver] server.idm.example.com [ipareplicas] replica1.idm.example.com replica2.idm.example.com [ipacluster:children] ipaserver ipareplicas [ipacluster:vars] ipaadmin_password=SomeADMINpassword [ipaclients] ipaclient1.example.com ipaclient2.example.com [ipaclients:vars] ipaadmin_password=SomeADMINpassword
This configuration defines two host groups, eu and us, for hosts in these locations. Additionally, this configuration defines the ipaserver host group, which contains all hosts from the eu and us groups.
[Optional] Create an SSH public and private key. To simplify access in your test environment, do not set a password on the private key:
$ ssh-keygen
Copy the SSH public key to the IdM
admin
account on each managed node:$ ssh-copy-id admin@server.idm.example.com $ ssh-copy-id admin@replica.idm.example.com
You must enter the IdM
admin
password when you enter these commands.
Additional resources
111.5. Configuring automount locations, maps, and keys in IdM by using Ansible
As an Identity Management (IdM) system administrator, you can configure automount locations and maps in IdM so that IdM users in the specified locations can access shares exported by an NFS server by navigating to specific mount points on their hosts. Both the exported NFS server directory and the mount points are specified in the maps. In LDAP terms, a location is a container for such map entries.
The example describes how to use Ansible to configure the raleigh location and a map that mounts the nfs-server.idm.example.com:/exports/project share on the /devel/project mount point on the IdM client as a read-write directory.
Prerequisites
-
You know the IdM
admin
password. You have configured your Ansible control node to meet the following requirements:
- You are using Ansible version 2.8 or later.
-
You have installed the
ansible-freeipa
package on the Ansible controller. - The example assumes that in the ~/MyPlaybooks/ directory, you have created an Ansible inventory file with the fully-qualified domain name (FQDN) of the IdM server.
-
The example assumes that the secret.yml Ansible vault stores your
ipaadmin_password
.
Procedure
On your Ansible control node, navigate to your ~/MyPlaybooks/ directory:
$ cd ~/MyPlaybooks/
Copy the
automount-location-present.yml
Ansible playbook file located in the/usr/share/doc/ansible-freeipa/playbooks/automount/
directory:$ cp /usr/share/doc/ansible-freeipa/playbooks/automount/automount-location-present.yml automount-location-map-and-key-present.yml
-
Open the
automount-location-map-and-key-present.yml
file for editing. Adapt the file by setting the following variables in the
ipaautomountlocation
task section:-
Set the
ipaadmin_password
variable to the password of the IdMadmin
. -
Set the
name
variable to raleigh. Ensure that the
state
variable is set topresent
.This is the modified Ansible playbook file for the current example:
--- - name: Automount location present example hosts: ipaserver vars_files: - /home/user_name/MyPlaybooks/secret.yml tasks: - name: Ensure automount location is present ipaautomountlocation: ipaadmin_password: "{{ ipaadmin_password }}" name: raleigh state: present
-
Set the
Continue editing the
automount-location-map-and-key-present.yml
file:In the
tasks
section, add a task to ensure the presence of an automount map:[...] vars_files: - /home/user_name/MyPlaybooks/secret.yml tasks: [...] - name: ensure map named auto.devel in location raleigh is created ipaautomountmap: ipaadmin_password: "{{ ipaadmin_password }}" name: auto.devel location: raleigh state: present
Add another task to add the mount point and NFS server information to the map:
[...] vars_files: - /home/user_name/MyPlaybooks/secret.yml tasks: [...] - name: ensure automount key /devel/project is present ipaautomountkey: ipaadmin_password: "{{ ipaadmin_password }}" location: raleigh mapname: auto.devel key: /devel/project info: nfs-server.idm.example.com:/exports/project state: present
Add another task to ensure auto.devel is connected to auto.master:
[...] vars_files: - /home/user_name/MyPlaybooks/secret.yml tasks: [...] - name: Ensure auto.devel is connected in auto.master: ipaautomountkey: ipaadmin_password: "{{ ipaadmin_password }}" location: raleigh mapname: auto.map key: /devel info: auto.devel state: present
- Save the file.
Run the Ansible playbook and specify the playbook and inventory files:
$ ansible-playbook --vault-password-file=password_file -v -i inventory automount-location-map-and-key-present.yml
111.6. Using Ansible to add IdM users to a group that owns NFS shares
As an Identity Management (IdM) system administrator, you can use Ansible to create a group of users that is able to access NFS shares, and add IdM users to this group.
This example describes how to use an Ansible playbook to ensure that the idm_user account belongs to the developers group, so that idm_user can access the /exports/project NFS share.
Prerequisites
-
You have
root
access to the nfs-server.idm.example.com NFS server, which is an IdM client located in the raleigh automount location. -
You know the IdM
admin
password. You have configured your Ansible control node to meet the following requirements:
- You are using Ansible version 2.8 or later.
-
You have installed the
ansible-freeipa
package on the Ansible controller. - The example assumes that in the ~/MyPlaybooks/ directory, you have created an Ansible inventory file with the fully-qualified domain name (FQDN) of the IdM server.
-
The example assumes that the secret.yml Ansible vault stores your
ipaadmin_password
. -
In ~/MyPlaybooks/, you have created the
automount-location-map-and-key-present.yml
file that already contains tasks from Configuring automount locations, maps, and keys in IdM by using Ansible.
Procedure
On your Ansible control node, navigate to the ~/MyPlaybooks/ directory:
$ cd ~/MyPlaybooks/
-
Open the
automount-location-map-and-key-present.yml
file for editing. In the
tasks
section, add a task to ensure that the IdM developers group exists and idm_user is added to this group:[...] vars_files: - /home/user_name/MyPlaybooks/secret.yml tasks: [...] - ipagroup: ipaadmin_password: "{{ ipaadmin_password }}" name: developers user: - idm_user state: present
- Save the file.
Run the Ansible playbook and specify the playbook and inventory files:
$ ansible-playbook --vault-password-file=password_file -v -i inventory automount-location-map-and-key-present.yml
On the NFS server, change the group ownership of the /exports/project directory to developers so that every IdM user in the group can access the directory:
# chgrp developers /exports/project
111.7. Configuring automount on an IdM client
As an Identity Management (IdM) system administrator, you can configure automount services on an IdM client so that NFS shares configured for a location to which the client has been added are accessible to an IdM user automatically when the user logs in to the client. The example describes how to configure an IdM client to use automount services that are available in the raleigh location.
Prerequisites
-
You have
root
access to the IdM client. - You are logged in as IdM administrator.
- The automount location exists. The example location is raleigh.
Procedure
On the IdM client, enter the
ipa-client-automount
command and specify the location. Use the-U
option to run the script unattended:# ipa-client-automount --location raleigh -U
Stop the autofs service, clear the SSSD cache, and start the autofs service to load the new configuration settings:
# systemctl stop autofs ; sss_cache -E ; systemctl start autofs
111.8. Verifying that an IdM user can access NFS shares on an IdM client
As an Identity Management (IdM) system administrator, you can test if an IdM user that is a member of a specific group can access NFS shares when logged in to a specific IdM client.
In the example, the following scenario is tested:
- An IdM user named idm_user belonging to the developers group can read and write the contents of the files in the /devel/project directory automounted on idm-client.idm.example.com, an IdM client located in the raleigh automount location.
Prerequisites
- You have configured an IdM keytab for an NFS server and exported an NFS share.
- You have configured automount locations, maps, and mount points in IdM in which you configured how IdM users can access the NFS share.
- You have used Ansible to add IdM users to the developers group that owns the NFS shares.
- You have configured automount on the IdM client.
Procedure
Verify that the IdM user can access the
read-write
directory:Connect to the IdM client as the IdM user:
$ ssh idm_user@idm-client.idm.example.com Password:
Obtain the ticket-granting ticket (TGT) for the IdM user:
$ kinit idm_user
[Optional] View the group membership of the IdM user:
$ ipa user-show idm_user User login: idm_user [...] Member of groups: developers, ipausers
Navigate to the /devel/project directory:
$ cd /devel/project
List the directory contents:
$ ls rw_file
Add a line to the file in the directory to test the
write
permission:$ echo "idm_user can write into the file" > rw_file
[Optional] View the updated contents of the file:
$ cat rw_file this is a read-write file idm_user can write into the file
The output confirms that idm_user can write into the file.