Shulou(Shulou.com)06/02 Report--

Table of contents:

(1) understand what automatic mounting is

(2) configure autofs

(3) autofs automatically mounts the NFS server

(4) realizing "roaming users" with LDAP

(1) understand what automatic mounting is

(1. 1) mount is used to mount the file system. It can be mounted when the system starts or after the system starts. For local fixed devices, such as hard disk, mount can be used to mount, while CD, floppy disk, NFS, SMB and other file systems are dynamic, that is, it is necessary to mount when needed. We generally know when optical drives and floppy disks need to be mounted, but we don't necessarily know when NFS and SMB shares can be mounted, that is, we generally can't know when NFS and SMB shares can be mounted in time. The autofs service provides this function, just like the automatic opening function of the optical drive in windows, which can mount the dynamically loaded file system in time. Save us the trouble of mounting manually.

Autofs differs from mount/umount in that it is a daemon. If it detects that a user is trying to access an unmounted file system, it automatically detects the file system, and if it exists, autofs mounts it automatically. On the other hand, if it detects that a mounted file system is not in use for a period of time, autofs automatically unmounts it. So once autofs is running, users no longer need to manually mount and unmount the file system.

(1.3) suppose that there is such a rule in our system: associate a device / dev/cdrom with a directory / mnt/cdromx, no matter whether it is mounted now or not, as long as we visit / mnt/cdromx, then the system thinks that I am going to access / dev/cdrom now, regardless of whether the directory and the device are mounted together or not, it will be automatically mounted to provide services.

(2) configure autofs

We configure auto-mount on the vms002 host. We first make sure that there is no CD-ROM image of / dev/cdrom mounted on the vms002 host, and then we install the autofs package on the vms002 host.

We want to automatically associate the CD / dev/cdrom to the / mnt/cdromx directory, we create the relevant files in the / mnt directory, and confirm that there is no cdromx directory, then we edit the / etc/auto.master file, and we specify the / mnt directory and / etc/auto.aa file to associate (figure 2-3).

# vim / etc/auto.master

(2.3) then we use a template file to build the auto.aa file. We specify the cdromx in the auto.aa file, and specify the mounted file system type and read-write type. At the same time, the third paragraph indicates that the left side of the colon refers to the remote host (usually represented by the IP address), and the right side of the colon refers to the local device name. At this point, we have implemented the need to link the / mnt/cdromx and / dev/cdrom directories. Then we restart the autofs service and set it to boot automatically (figure 2-6).

# systemctl restart autofs

# systemctl enable autofs

(2.4) at this time, we use the mount command to check and find that the system does not mount cdrom-related entries, and we find that no files are generated in the / mnt directory, but when we use the command to enter cdromx, we find that we can normally enter the cdromx directory and query the files in the directory, while using the mount command to find the relevant entries mounted by cdrom can be found normally.

It should be noted that we have specified the parent directory in auto.master, so the original files in our parent directory will be hidden, so we find that the aa.txt, bb.txt, cc.txt and dd.txt files created in figure 2-2 can not be seen after entering the / mnt directory. If we do not want the files in the parent directory to be hidden, we can change the parent directory to "/ -" in the / etc/auto.master file and the associated directory to / mnt/cdromx in the / etc/auto.aa file (figure 2-9). At this time, after restarting the autofs service, we found that the previously created aa.txt and other files in the / mnt directory all exist and are not hidden, and the system does not generate any mount information about the CD image at present, but when we finish querying the files in the / mnt/cdromx directory, we find that the system has automatically generated the mount information of the CD image at this time (figure 2-10).

(3) autofs automatically mounts the NFS server

First of all, we quickly build a NFS server on the vms001 host. By default, the NFS server is installed in the system, so we can start it directly. We create a / zz directory on the vms001 host and copy the / etc/hosts file to the / zz directory.

# cp / etc/hosts.

# systemctl start nfs-server

# systemctl enable nfs-server

# vim / etc/exports

Then we write the following entry in the / etc/exports file, share the / zz directory, and make it readable and writable, transfer asynchronously, and then re-validate the entry in the NFS file.

Then we try to mount the NFS server-side directory of the vms001 host automatically on the vms002 host. We set the local mount directory to / mnt/nfs in the / etc/auto.aa configuration file of the vms002 host, and the mount data source is the / zz directory provided by the vms001 host (figure 2-14).

# showmount-e vms001

# mount | grep 'zz'

# vim / etc/auto.aa

Then we restart the autofs service, and we find that no directory information on the vms001 host is mounted on the vms002 host at the beginning. When we query "# ls / mnt/nfs/", we can find that the / zz directory shared by NFS service on the vms001 host has been automatically mounted on the vms002 host (figure 2-15).

Note: we can also define multiple mount file names in the / etc/auto.master file, and then classify each file name for a different mount (figure 2-16)

(4) realizing "roaming users" with LDAP

We created two KVM virtual machines, host and station, using install.sh on the vms001 host.

Then we can follow "[my Linux, I'm in charge!" ] exposure: network users-- deploying LDAP directory service in the article "(2) Building an experimental environment" and "(3) using a LDAP client" to operate, so that our station virtual machine can normally view the network user ldapuser1 on the host virtual machine.

Note: the IP of the host virtual machine is 192.168.122.10 the host name of the host.rhce.cc;station virtual machine is: the IP of the host.rhce.cc;station virtual machine is 192.168.122.100 the hostname of the host virtual machine is: station.rhce.cc

However, we found that when switching directly from the station virtual machine login to the network user ldapuser1, the switch could not be successful because there is no local home directory (figure 2-20). All the home directories of the network users created in the host virtual machine are stored in the / home/guests directory, all of these network users are created on the server, and their home directories have been shared through NFS (figure 2-21).

(4.4) previously, we created the home directory of the network user locally on the LDAP client, so that when the station virtual machine switched to the ldapuser1 network user, we were able to log in normally, but this operation was very clumsy. When the number of network users of the server is very large, and the number of member servers is also very large, it is basically impossible to create the home directory of network users manually. Our solution to this problem is to install the autofs package on the station virtual machine (figure 2-22), and then we indicate the home directory of the network user in the host virtual machine LDAP service in the / etc/auto.master of the station virtual machine, as well as the file name of the current host configuration autofs (figure 2-23).

Then we copy the template file / etc/auto.misc to / etc/auto.aa, and we need to specify the "client user name, (file system type, readable and writable, version), server user name" in the auto.aa file, of course, when the number of users is large, we can use wildcards to replace the user name, which can greatly improve work efficiency.

Note: "*" means any field, and "&" means that no matter what any field is, it is consistent with the "*" field.

(4.6) when we restart the autofs service of the station virtual machine, we find that when the station host switches to the network user ldapuser4, it automatically creates a home directory locally, so it can log in normally (figure 2-25). At the same time, we also found that the station virtual machine has automatically mounted the guests directory of the host virtual machine (figure 2-26).

Note: when using "# su-ldapuser4", we add a bar to indicate that the login switch will access the home directory of the network user ldapuser4, while the home directory of the network user has been shared through the NFS service, so the home directory of the network user will be automatically created locally.

# systemctl restart autofs

# mount | grep-v auto | grep guests--- queries whether station virtual machine has a file directory where host virtual machine is mounted

(4.7) at this time, we log in to the ldapuser3 user on the station virtual machine, and use the ldapuser3 user to create a file, which is actually written to the host virtual machine, and even if we log in to the ldapuser3 account using other hosts, we can see the file we created before, so we can achieve the need of "roaming users" in the LDAP environment.

-this is the end of this article. Thank you for reading-

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.