Getting Started with OpenLDAP, Part 6

Before we get into creating centralised authentication and roaming profiles, we need to look at the process that ensures all users on the network get access to their data, irrespective of the location or system they log on to. It might be beyond the scope of an article pertaining to LDAP, but it is important in the context of centralised authentication environments, where all users must have access to their desktop. This feature is an essential requirement in modern computing environments and therefore, I feel the need to elaborate on auto-mounting here.

Let’s get down to work

The test environment for this month’s article is as follows:

1. OpenLDAP server consisting of user names, passwords and other required details running on RHEL 5.4 (IP address is 192.168.122.1; hostname is bg.knafl.org)
2. Linux client running RHEL 5.5 (virtualised over KVM; IP address is 192.168.122.82; hostname is rdso.knafl.org)

As I write this, we are awaiting the launch of RHEL 6. I have had a chance to grab my copy of the latest RHEL6 and am enjoying the SPICE (simple protocol for independent computing environments) experience on my laptop. For those of you who are uninitiated into KVM and SPICE, I would suggest you visit www.spice-space.org. It is an exciting protocol and holds much promise.

In the previous article, we had discussed how to configure Linux client authentication through LDAP. Here, I will provide users with a centralised home directory, that will contain all the profile details and user data. The only way to achieve this is to keep a central location of file shares, and depending on the users who log on to a client, their particular home folder should get mounted at the desired path.

First, let’s achieve the desired functionality, manually. To be able to do so, you need to add the following to your infrastructure:

1. A file server with a suitable protocol (e.g., Samba, NFS, etc)
2. A client-side software capable of mounting the shared file system, locally.

For the purpose of this article, we will use NFS as the protocol for file sharing since both the server and the client-side software are available in Linux. Let’s create a share on the LDAP server itself for the users to keep their data.

To prepare a basic NFS share on the NFS server, you need to go through the following steps:

1. Decide on the folder to be shared
2. Export it

Note: We will not go into NFS details; our aim is to present roaming profiles to users.

To create a central file share on the NFS server, let us create a new folder called myusersdata. The following commands on the NFS server should achieve this:

[root@vbg ~]# mkdir /myusersdata
[root@vbg ~]# echo “/myusersdata
[root@vbg ~]# service nfs restart

[root@vbg ~]# showmount -e localhost
Export list for localhost:       /myusersdata *    *(rw)” >> /etc/exports

Now we need to create home directories for all the users created in LDAP; an easy way to do this would be to check the valid users from the client.

On the client, let’s take a look at the last four users:

[root@rdso ~]# getent passwd | tail -n 4
vbg1:x:501:501:vbg1:/home/vbg1:/bin/bash
websms:x:502:502:websms:/home/websms:/bin/bash
rajveer:x:503:503:rajveer:/home/rajveer:/bin/bash
testrpm:x:504:504:testrpm:/home/testrpm:/bin/bash
[root@rdso ~]#

The above output shows that the home directories of these users are /home/vbg1, /home/websms, /home/rajveer and /home/testrpm, respectively. Ideally, we should change these locations because /home is also the folder where the home folders of local users are stored, and there might be situations in which you would want /home to remain intact.

Therefore, change the homeDirectory attribute in your LDAP server. To do so, create a small ldif file as shown below and run the ldapmodify command.

[root@vbg ~]# cat /tmp/modify.ldif
dn: uid=vbg1,ou=People,dc=knafl,dc=org
changetype: modify
replace: homeDirectory
homeDirectory: /home/userhome/vbg1

dn: uid=websms,ou=People,dc=knafl,dc=org
changetype: modify
replace: homeDirectory
homeDirectory: /home/userhome/websms

dn: uid=rajveer,ou=People,dc=knafl,dc=org
changetype: modify
replace: homeDirectory
homeDirectory: /home/userhome/rajveer

dn: uid=testrpm,ou=People,dc=knafl,dc=org
changetype: modify
replace: homeDirectory
homeDirectory: /home/userhome/testrpm

[root@vbg ~]#

The above ldif file is self-explanatory. The various permissible values for changetype are: add, modify, delete, and modrdn. The modrdn option is used when the relative distinguished name of an entry is about to change. We will look into these kinds of ldif files a little later in the series.

As of now, the ldif file specifies which DNs to modify and the values of which attributes to change. Let us run the ldapmodify command on the LDAP server.

[root@vbg ~]# ldapmodify -xh localhost -D
"cn=Manager,dc=knafl,dc=org" -W -f /tmp/modify.ldif
Enter LDAP password:
modifying entry "uid=vbg1,ou=People,dc=knafl,dc=org"
modifying entry "uid=websms,ou=People,dc=knafl,dc=org"
modifying entry "uid=rajveer,ou=People,dc=knafl,dc=org"
modifying entry "uid=testrpm,ou=People,dc=knafl,dc=org"
[root@vbg ~]#

Before proceeding further, let us check from the client machine whether the changes have been successfully made:

[root@rdso ~]# getent passwd | tail -n 5
dovecot:x:97:97:dovecot:/usr/libexec/dovecot:/sbin/nologin
vbg1:x:501:501:vbg1:/home/userhome/vbg1:/bin/bash
websms:x:502:502:websms:/home/userhome/websms:/bin/bash
rajveer:x:503:503:rajveer:/home/userhome/rajveer:/bin/bash
testrpm:x:504:504:testrpm:/home/userhome/testrpm:/bin/bash
[root@rdso ~]#

This shows that the required changes have been made. Once this is done, the following remains to be completed:

1. On the file server, individual folders for all users need to be created and exported;
2. On the clients, suitable mountpoints need to be created and NFS exports need to be mounted.

Let us create the home directory for these users in the shared export folder on the NFS server:

[root@vbg ~]# mkdir /myusersdata/vbg1
[root@vbg ~]# mkdir /myusersdata/rajveer
[root@vbg ~]# mkdir /myusersdata/websms
[root@vbg ~]# mkdir /myusersdata/testrpm
[root@vbg ~]# ls -l /myusersdata/
total 16
drwxr-xr-x 2 root root 4096 Oct 21 00:14 rajveer
drwxr-xr-x 2 root root 4096 Oct 21 00:15 testrpm
drwxr-xr-x 2 root root 4096 Oct 21 00:08 vbg1
drwxr-xr-x 2 root root 4096 Oct 21 00:14 websms
[root@vbg ~]#

Now that you have the users, you just need to mount the corresponding folders in the client. To get the home directory for the user vbg1 at the right location, as per the output of the getent passwd command, i.e., /home/userhome/vbg1, mount the NFS exported folder /myusersdata to the mount point /home/userhome in the client machine:

[root@rdso ~]# mkdir /home/userhome
[root@rdso ~]# mount 192.168.122.1:/myusersdata /home/userhome
Filesystem                       Size  Used Avail Use% Mounted on
/dev/mapper/VolGroup00-LogVol00  8.6G  5.3G  3.0G  64% /
/dev/hda1                         99M   13M   82M  14% /boot
tmpfs                            250M     0  250M   0% /dev/shm
192.168.122.1:/myusersdata        19G   17G  1.6G  92% /home/userhome
[root@rdso ~]#

On the client, log in as user vbg1 and see the results:

[root@rdso ~]# su - vbg1
-bash-3.2$ pwd
/home/userhome/vbg1

Your job is primarily done. But there are various problems with this approach:

1. The entire folder /userhome is mounted on this system and the data of all the users is visible to all, as can be seen from the following command:

   [root@rdso ~]# ls /home/userhome/
   rajveer testrpm vbg1 websms

2. To avoid the above, if we were to just mount a specific user’s folder, then we would have had to create individual folders for each user. That would be a nightmare for the management. Every time a new user joined the organisation, you would need to create a new mount point
   (/home/userhome/xyz) in all the client machines.

Auto-mount is an elegant way of dealing with this problem. As the name (auto-mount) suggests, it will automatically mount filesystems for you when they are required, and unmount them when not required. Automounter is implemented through autofs in RHEL systems. The RPM installed in my system is autofs-5.0.1-0.rc2.131.el5. Generally, auto-mounter is configured through text files —
auto.master and map file(s).

The default configuration file, auto.master, defines mount point(s) under which filesystems are automatically mounted on the client machine and the map file(s) that are associated with these. As an example, the first map defined in the default /etc/auto.master on my client looks like what’s shown below:

/misc    /etc/auto.misc

This basically means that for all automatically mounted partitions under /misc, the definitions are provided by the file /etc/auto.misc. Let’s create our own entry. We have to auto-mount folders as /home/userhome/[xyz], where [xyz] represents the name of the logged in user. Therefore, our top folder in the mount hierarchy is /home.
Hence, you can add the following line to /etc/auto.master and comment the other lines:

/home    /etc/auto.home

Now, let us create the map file /etc/auto.home. This map contains the parameters found in the mount command. If we, use the following command to manually mount the NFS partition:

[root@rdso ~]# mount 192.168.122.1:/myusersdata /home/userhome

…then our /etc/auto.home shall look like:

[root@rdso ~]# cat /etc/auto.home
userhome    -rw    192.168.122.1:/myusersdata

The above map indicates the filesystem parameters to mount a filesystem at the userhome folder relative to /home (defined in /etc/auto.master), or in other words, /home/userhome.

Let’s test our autofs settings now.

1. First, check whether the filesystem is manually mounted. If it is, unmount it:

   [root@rdso ~]# df -h
   Filesystem                       Size  Used Avail Use% Mounted on
   /dev/mapper/VolGroup00-LogVol00  8.6G  5.3G  3.0G  64% /
   /dev/hda1                         99M   13M   82M  14% /boot
   tmpfs                            250M     0  250M   0% /dev/shm
   [root@rdso ~]#

2. Let’s restart the autofs service:

   [root@rdso ~]# /etc/init.d/autofs restart

3. Log in as vbg1 user (to auto-mount the NFS exported folder from the server):

   [root@rdso ~]# su - vbg1

4. Now, check the mounted filesystems:

   Filesystem                       Size  Used Avail Use% Mounted on
   /dev/mapper/VolGroup00-LogVol00  8.6G  5.3G  3.0G  64% /
   /dev/hda1                         99M   13M   82M  14% /boot
   tmpfs                            250M     0  250M   0% /dev/shm
   192.168.122.1:/myusersdata        19G   17G  1.6G  92% /home/userhome
   [root@rdso ~]#

Voila! Your folder has been mounted automatically.

An important feature of auto-mount is that unused folders get unmounted automatically, which is why it is great for writing backup scripts. We use it often in our day to day jobs while scripting backup jobs. When the backup starts, the backup command (the rsync/cp command — or any other) gets activated; and the remote folders required by it get automatically mounted on the client. After a period of inactivity (that is, when the backup completes) the automounted folder gets unmounted. The set of commands given below demonstrate what I mean. Let’s test auto-unmounting.

1. Log out of the user vbg1, so that /home/userhome access is no longer needed
2. Note the current time and the mount points in the client
3. Wait for some time and try again; then note the mount points:

   [root@rdso ~]# date
   Thu Oct 21 07:16:58 IST 2010
   [root@rdso ~]# df -h
   Filesystem                       Size  Used Avail Use% Mounted on
   /dev/mapper/VolGroup00-LogVol00  8.6G  5.3G  3.0G  64% /
   /dev/hda1                         99M   13M   82M  14% /boot
   tmpfs                            250M     0  250M   0% /dev/shm
   192.168.122.1:/myusersdata        19G   17G  1.6G  92% /home/userhome
   [root@rdso ~]#

4. After about five minutes of inactivity, check the mount points:

   [root@rdso ~]# df -h
   Filesystem                       Size  Used Avail Use% Mounted on
   /dev/mapper/VolGroup00-LogVol00  8.6G  5.3G  3.0G  64% /
   /dev/hda1                         99M   13M   82M  14% /boot
   tmpfs                            250M     0  250M   0% /dev/shm
   [root@rdso ~]# date
   Thu Oct 21 07:21:55 IST 2010
   [root@rdso ~]#

So auto-mount solves the first problem of having to mount all the partitions, manually, and of then keeping them mounted. But the second issue still remains — of all the user partitions being visible:

[root@rdso ~]# df -h
Filesystem                       Size  Used Avail Use% Mounted on
/dev/mapper/VolGroup00-LogVol00  8.6G  5.3G  3.0G  64% /
/dev/hda1                         99M   13M   82M  14% /boot
tmpfs                            250M     0  250M   0% /dev/shm
192.168.122.1:/myusersdata        19G   17G  1.6G  92% /home/userhome
[root@rdso ~]#
[root@rdso ~]# ls /home/userhome/
rajveer testrpm vbg1 websms
[root@rdso ~]#

To solve the second problem of mounting only the user’s home folder (similar to the command: mount 192.168.122.1:/myusersdata/vbg1 /home/userhome/vbg1), let’s make a few changes in the auto-mount maps /etc/auto.master and /etc/auto.home:

[root@rdso ~]# cat /etc/auto.master | grep home
/home/userhome /etc/auto.home
[root@rdso ~]#

In the auto.master map, I have changed the base mount folder from /home to /home/userhome, as I would now like to have this as the base mounting folder. The important change is in the /etc/auto.home map:

[root@rdso ~]# cat /etc/auto.home
*        -rw        192.168.122.1:/myusersdata/&
[root@rdso ~]#

We need to take a deeper look at the changes:

1. Instead of a fixed local mountpoint, now the mount point is specified by the wildcard character *
2. Instead of a fixed remote filesystem name, the path of the remote filesystem ends with /&

What this does is, whenever the system accesses any (‘*‘ in /etc/auto.home) folder in /home/userhome, e.g., /home/userhome/vbg1, this folder gets mounted from the remote path, 192.168.122.1:/myusersdata/vbg, specified by the trailing ‘&‘). In other words, if I access folder /home/userhome/lfy, then the automounter will try to mount 192.168.122.1/myusersdata/lfy at /home/userhome/lfy.

Make the above changes and restart the autofs service. If you are now able to log in as user vbg1, the differences are obvious:

[root@rdso ~]# /etc/init.d/autofs restart
[root@rdso ~]# su - vbg1

To check the mountpoints:

[vbg1@rdso ~]$ df -h
Filesystem                       Size  Used Avail Use% Mounted on
/dev/mapper/VolGroup00-LogVol00  8.6G  5.3G  3.0G  64% /
/dev/hda1                         99M   13M   82M  14% /boot
tmpfs                            250M     0  250M   0% /dev/shm
192.168.122.1:/myusersdata/vbg1   19G   17G  1.6G  92% /home/userhome/vbg1

[root@rdso ~]#
Wow! Only /myusersdata/vbg1 has been mounted — exactly what we need.

[vbg1@rdso ~]$ ls -l /home/userhome/
total 4
drwxrwxrwx 3 root root 4096 Oct 21 06:46 vbg1
[vbg1@rdso ~]$

Therefore, we see that auto-mounter really helps in establishing roaming profiles for centrally authenticated environments. The major management bottleneck here is that these files (/etc/auto/master and /etc/auto.home) need to be created in every system. Once again, LDAP comes to the rescue. You can store the automount maps information in the directory. As usual, the logical flow of steps required to accomplish this would be as follows:

1. Create the necessary ldif files
2. Ensure that the required schema files are present
3. Import the ldif files in the directory
4. Make changes in the client to read autofs information from LDAP rather than files (/etc/auto/.master)
5. Log in and test

We will again use the “very useful” migration tool to create the ldif files. For this, we will copy the map files from the client to the OpenLDAP server and run the migration scripts:

[root@vbg migration]# scp 192.168.122.82:/etc/auto.master /tmp
[root@vbg migration]# scp 192.168.122.82:/etc/auto.home /tmp
[root@vbg migration]# pwd
/usr/share/openldap/migration
[root@vbg migration]# ./migrate_automount.pl /tmp/auto.master > /tmp/auto1.ldif
[root@vbg migration]# ./migrate_automount.pl /tmp/auto.home > /tmp/auto2.ldif

In the next article of the series, we will have a detailed look at these files. We need to make minor adjustments in our ldif files. I have combined the two files /tmp/auto1.ldif and /tmp/auto2.ldif to create a single file /tmp/auto.ldif, that looks like what’s given below:

[root@vbg migration]# cat /tmp/auto.ldif
dn: nisMapName=auto.master,dc=knafl,dc=org
objectClass: top
objectClass: nisMap
nisMapName: auto.master

dn: cn=/home/userhome,nisMapName=auto.master,dc=knafl,dc=org
objectClass: nisObject
cn: /home/userhome
nisMapEntry: auto.home
nisMapName: auto.master

dn: nisMapName=auto.home,dc=knafl,dc=org
objectClass: top
objectClass: nisMap
nisMapName: auto.home

dn: cn=*,nisMapName=auto.home,dc=knafl,dc=org
objectClass: nisObject
cn: *
nisMapEntry: -rw
192.168.122.1:/myusersdata/&
nisMapName: auto.home
[root@vbg migration]#

Let’s add this data to our directory:

[root@vbg migration]# ldapadd -c -xh localhost -D
"cn=Manager,dc=knafl,dc=org" -W -f /tmp/auto.ldif
Enter the LDAP password:
adding new entry "nisMapName=auto.master,dc=knafl,dc=org"
adding new entry "cn=/home/userhome,nisMapName=auto.master,dc=knafl,dc=org"
adding new entry "nisMapName=auto.home,dc=knafl,dc=org"
adding new entry "cn=*,nisMapName=auto.home,dc=knafl,dc=org"
[root@vbg migration]#

Our directory is ready; now configure the client. For autofs configuration, the file to edit is /etc/sysconfig/autofs. I have uncommented the following entries:

MAP_OBJECT_CLASS="nisMap"
ENTRY_OBJECT_CLASS="nisObject"
MAP_ATTRIBUTE="nisMapName"
ENTRY_ATTRIBUTE="cn"
VALUE_ATTRIBUTE="nisMapEntry"

…and set the values of the following two entries:

LDAP_URI="ldap://192.168.122.1/"
SEARCH_BASE="dc=knafl,dc=org"

Finally, I also commented the map declaration in the file /etc/auto.master to ensure that the auto-mounts would take place through LDAP only, as can be seen below:

[root@rdso ~]# cat /etc/auto.master | grep home
# /home/userhome /etc/auto.home
[root@rdso ~]#

Now restart the autofs service and check:

[root@rdso ~]# /etc/init.d/autofs restart
[root@rdso ~]# su - vbg1
[vbg1@rdso ~]$ df -h
Filesystem                       Size  Used Avail Use% Mounted on
/dev/mapper/VolGroup00-LogVol00  8.6G  5.3G  3.0G  64% /
/dev/hda1                         99M   13M   82M  14% /boot
tmpfs                            250M     0  250M   0% /dev/shm
192.168.122.1:/myusersdata/vbg1   19G   17G  1.6G  92% /home/userhome/vbg1
[root@rdso ~]#

It works. Now as a sysadmin, all you need is to install a Linux system (from a kickstart preferably that also creates the desired /etc/sysconfig/autofs), add a new user to LDAP, create the user’s home folder in the NFS share, and lo and behold, the roaming profiles are activated!