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:
- 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
) - 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:
- A file server with a suitable protocol (e.g., Samba, NFS, etc)
- 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:
- Decide on the folder to be shared
- 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:
- On the file server, individual folders for all users need to be created and exported;
- 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:
- 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
- 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.
- 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 ~]#
- Let’s restart the
autofs
service:[root@rdso ~]# /etc/init.d/autofs restart
- Log in as vbg1 user (to auto-mount the NFS exported folder from the server):
[root@rdso ~]# su - vbg1
- 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.
- Log out of the user vbg1, so that
/home/userhome
access is no longer needed - Note the current time and the mount points in the client
- 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 ~]#
- 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:
- Instead of a fixed local mountpoint, now the mount point is specified by the wildcard character
*
- 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:
- Create the necessary ldif files
- Ensure that the required schema files are present
- Import the ldif files in the directory
- Make changes in the client to read autofs information from LDAP rather than files (
/etc/auto/.master
) - 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!
hii….Varad…I read all articles of openLDAP & understand it very well….
Thanks to provide this info…
…. I want to known another thing that
I successfully install & configure DNS master & slave servers with one DNS name in RHEL-5x & want to configure 2nd DNS name in same DNS server.
PLZ help me….
Thanls
********
yogesh kumar
Thanks a lot,
It has been couple of weeks I am trying to explore and implement LDAP(OpenLDAP),
I have gone through dozens of articles. I can the this one is the best up to now I have found. I wish i have found this some weeks ago, for sure it would have save me alot of time and not being tortured by lots of junk material font on web…
I just really appreciate well explanation…straight to point.
Cheers and well done
Could you please publish some solutions how to make nfs( autofs ) secure…Thanks