Linux--Directory service configuration and application (LDAP protocol) (2)

Source: Internet
Author: User
Tags ldap ldap protocol ldapsearch tmp file openldap



14.5 setting up a master-slave LDAP server



At some point, you may want to set up multiple LDAP servers in order to load balance the LDAP server. The key issue for setting up multiple LDAP servers is the synchronization of data, using the SLURPD process to replicate data from the LDAP server to the primary LDAP server. This section describes the process of erecting a master-slave LDAP server.



14.5. More than 1 LDAP server working processes



For multiple LDAP servers, one can be set as the primary server and the other from the server. This section describes the configuration of a slave server that can be operated by multiple slave servers.



Note: You should first ensure that each LDAP server has the OPENLDAP server program installed and works correctly before you configure it.



After configuring the master-slave LDAP server with the method described below in this section, run the SLURPD process on the primary server, which uses the LDAP protocol to update the data from the server from the primary server's database, as follows:



(1) The LDAP client submits an LDAP modification request from the server.



(2) Returns a reference to the primary server from the server to the LDAP client.



(3) The LDAP client submits an LDAP modification request to the primary server.



(4) The master server modifies the data in the database and changes the log file written to the local computer.



(5) The SLURPD process running on the primary server checks for new content in the log and sends changes to the slave server through the log information.



(6) Receive SLURPD information from the server and modify the local data.



The above process is the process of using the SLURPD process for data replication. As you can see from the above process, you need to set up a log file in the master server's configuration file to which you want to send replication information from the server, the primary server, and a record data change, and a link from the server to the primary server.



14.5.2 setting up the primary server



To set up the primary server, you first need to modify the configuration file sladp.conf of the primary LDAP server, add the replication options to it, and set the location and name of the log file.



Execute the following command to open the main configuration file slapd.conf:


# vi/etc/openldap/slapd.conf


Add the following at the end of the open configuration file:


1: # Replicas of this database 2:replogfile/var/lib/ldap/openldap-master-replog 3:replica host=192.168.206.130:389 4:binddn= "Cn=manager, Dc=wyh, dc=com" 5:bindmethod=simple Credentials=secret


The meanings of the lines are as follows:



Line 2nd sets the location and name of the log file.



Line 3rd sets the domain name or IP address from the server, where 389 represents the LDAP service process default port.



Line 4th sets the DN of the Super Administrator and has a setting from the server that must correspond to this line.



The 5th line sets the authentication method.



Modify the configuration file as shown in interface 14-15.








When the data on the primary server changes, the changes are added to the log file Openldap-master-replog, and the file does not exist at the beginning.






Tip: To test whether the master server is set up successfully, you can modify an entry in the master server to see if the log file Openldap-master-replog is generated.



"Instance 14-4" tests whether the master server is configured successfully.



The following are the steps:



(1) Use the following command to abort the SLAPD service process:


# kill-int ' Cat/var/run/openldap/slapd.pid '


(2) Restart the SLAPD service process with the new configuration file using the following command:


# SLAPD


(3) Use the following command to modify an existing entry:


# ldapmodify-x-D "cn=manager,dc=wyh,dc=com"-W Secret


Enter the following to modify the CN=WYH entry:


dn:cn=wyh,ou=managers,dc=wyh,dc=com changetype:modify REPLACE:SN Sn:wuyunhui.modi


Enter and press ENTER to complete the modification operation, press CTRL + C key to exit the Modify command. Modify procedure 14-16 as shown.








(4) Viewing the/var/lib/ldap/directory, you can see that there are 2 additional files, which is the log file generated after the data entry in the master server is modified, as shown in 14-17.



After the above test, you can know the master server configuration is complete.








14.5.3 settings from the server



The configuration file sladp.conf also needs to be modified from the LDAP server so that it can be linked to the primary LDAP server.



Tip: The same settings are required for each slave from the LDAP server.



Execute the following command to open the configuration file from the server slapd.conf:


# vi/etc/openldap/slapd.conf


Add the following at the end of the open configuration file:


1:updatedn "cn=manager,dc=wyh,dc=com" 2:updateref ldap://192.168.206.11:389


Where the 1th line must correspond to the BINDDN in the primary server configuration file. Specifies the DN used by the SLURPD daemon of the master server when updating data from the server.



The Updateref of line 2nd is set to the primary server. When the client submits an update request from LDAP, the client is redirected to the primary server from the server.



The added content is shown in 14-18.











14.5.4 Copying a database



When the data entry in the primary server changes, the SLURPD process will replicate, but the primary server's initial data cannot be replicated through the SLURPD process, so you will also need to manually copy the database contents from the primary server to the corresponding directory from the server.



By default, the database that holds the LDAP data entry is in the/var/lib/ldap/directory (which can also be modified in the slapd.conf file), and the simplest way is to copy all the data from that directory to the corresponding directory for each slave server.



Tip: There are many ways to copy, you can use a USB flash drive and other mobile storage devices, but also using NFS, SFTP and other network applications.



Instance 14-5 copies the LDAP data file to the slave server using the Sftp method described in chapter 8th.



The following are the steps:



(1) Stop the SLAPD process using the following command in the master server:


# kill-int ' Cat/var/run/openldap/slapd.pid '


(2) Connect to the primary server using the SFTP command from the server:


# SFTP 192.168.206.11


After you connect to the server, enter the correct password to log on to the primary server in TTP mode.



(3) Use the following FTP command to switch to the/var/lib/ldap/directory and download all of the files locally, as shown in procedure 14-19.


sftp> cd/var/lib/ldap sftp> ls sftp> get * *







(4) If you download the data from the/var/lib/ldap/directory in the master server to the home directory from the server, you also need to copy it to the/var/lib/ldap/directory from the server, overwriting the data in that directory.



Tip: You can also export the data from the master server and import it from the server.





14.5.5 testing the master-slave LDAP server



After the above steps, the master-slave LDAP server is ready to test the related operations.



1. Booting from an LDAP server



The preceding operation copies the database files of the primary LDAP server directly to the slave server, and first tests whether the data entries are available from the server.



Start the OPENLDAP server process by using the following command from the server:


# SLAPD


Use the Ldapsearch command to test the correct copy of the database, with the following code:


# ldapsearch-x-B "dc=wyh,dc=com" "Cn=wyh"


As shown in the execution result 14-20, you can see that the CN=WYH entry already exists in the database from the server.



2. Start the primary LDAP server



Start the SLAPD process and the SLURPD process in the primary LDAP server and make an entry modification to see if it has been modified from the server.








"Instance 14-6" starts the primary LDAP server.



The following are the steps:



(1) Use the following command to start the OPENLDAP server process for the primary LDAP server:


# SLAPD


(2) Use the following command to start the SLURPD process:


# SLURPD


(3) Modify an entry using the following command in the primary LDAP server:


# ldapmodify-x-D "cn=manager,dc=wyh,dc=com"-W Secret


Enter the following to modify the contents of the CN=WYH entry:


dn:cn=wyh,ou=managers,dc=wyh,dc=com changetype:modify REPLACE:SN Sn:wuyunhui


Enter and press ENTER to complete the modification, as shown in procedure 14-21 (change SN to Wuyunhui).





(4) in the operation from the LDAP server, see if the operations in the primary LDAP server are replicated to the LDAP server. Query by using the following command from the LDAP server:


# ldapsearch-x-B "dc=wyh,dc=com" "Cn=wyh"


As shown in result 14-22, you can see that the SN is also modified to Wuyunhui (the original content in the database is Wuyunhui.modi, which is the value modified in the previous example), which is replicated synchronously by the primary LDAP server.










Application of 14.6 OpenLDAP in user authentication



OpenLDAP is often used for user login authentication, which allows users to log on to all servers in the network using an LDAP service using an LDAP data replication feature. Set the user account data in the primary LDAP server, and then use the set account to log on through any client on the network. This section provides a brief introduction to how user authentication is migrated to LDAP.



Ojbectclass for 14.6.1 user authentication



The objectclass used to save user authentication entries in LDAP are mainly the following 3, which are used to save groups, users, passwords and other information into the directory entries.



Posixgroup: Can set properties cn, UserPassword, Gidnumber and so on.



Posixaccount: Can set properties cn, Gidnumber, UID, Uidnumber, homedirectory, Loginshell and so on.



Shadowaccount: Can set attribute uid, Shadowexpire, Shadowflag, Shadowinactive, Shadowlastchange, Shadowmax, Shadowmin, Shadowwarning, UserPassword and so on.



Tip: The names of the properties listed above can be easily linked to information about groups and users.



14.6.2 Using the Migration Tool



To use LDAP for user authentication, the first thing to consider is the amount of data migration. If you want operators to re-enter information from/etc/passwd and/etc/group files one by one, the workload will be very large.



OpenLDAP has taken these migrations into account for the user and provided a number of scripts for the Migration tool, which are located in the/usr/share/openldap/migration/directory, where there are many script files with the extension PL and SH, through which the migration tools Users in the system can easily be migrated to the LDAP directory database. The specific migration steps are described below.



"Instance 14-7" migrates user information from the system to the LDAP directory database.



The following are the steps:



(1) Modify the/usr/share/openldap/migration/migrate_common.ph file to find the following:


$DEFAULT _base = "dc=padl,dc=com";


Modify it to the root used by the directory server, such as the example used in this chapter to change to the following form:


$DEFAULT _base = "dc=wyh,dc=com";


Exit after saving.



(2) Use the following command to execute script migrate_base.pl, to create a root entry, and to create a lower-level organizational unit for hosts, Networks, group, and people:


#./migrate_base.pl > Base.ldif


(3) Because the root entry "dc=wyh,dc=com" is already created in the LDAP server earlier in this chapter, the 1th entry in the Base.ldif file is deleted, in addition, only groups and users are used in user authentication, and other unrelated entries are deleted, saving only the following:


dn:ou=people,dc=wyh,dc=com ou:people objectclass:top objectclass:organizationalunit dn:ou=group,dc=wyh,dc=com ou: Group Objectclass:top Objectclass:organizationalunit


(4) Use the following command to import entries from the Base.ldif file into the catalog database:


# ldapadd-x-D "cn=manager,dc=wyh,dc=com"-W secret-f base.ldif


The execution results are shown in 14-23.





(5) Start migrating group information. Use the following command to save the group information in/etc/group to the temporary file group.tmp:


# Cat/etc/group > Group.tmp


(6) System groups are not imported into the LDAP directory database, so the information in the Group.tmp file needs to be edited, leaving only the information for the group that needs to import the LDAP directory database.



(7) Use the following command to generate the LDIF entry information for the group's data:


#./migrate_group.pl group.tmp > Group.ldif


(8) using the Cat command to view the contents of the GROUP.LDIF, you can see that the group's data has been posixgroup by this objectclass, as shown in 14-24.









(9) Similarly, use the following command to export the user data in the/etc/passwd, delete the unwanted users, and then use the migrate_passwd.pl script to generate the LDIF file:


# cat/etc/passwd > Passwd.tmp # VI passwd.tmp #./migrate_passwd.pl passwd.tmp > Passwd.ldif # Cat PASSW D.ldif


The execution procedure is shown in 14-25.






Tip: Users of system administration, such as root, are best removed from passwd.tmp, who still use local logon methods.



(10) Use the following command to import group and user information into the catalog database:



  1. #  ldapadd  -x  -d   " CN = manager , dc = Wyh , dc = com " 
    -w  secret  -f  group.ldif  

  2. # ldapadd-x-D " cn = Manager , DC = Wyh , DC = com "
    -W secret-f passwd.ldif


The execution of the above command is shown in procedure 14-26.




(11) Use the following command to view the user wyh information in the directory database, using "UID=WYH" as the query criteria:


# ldapsearch-x "Uid=wyh"


Look for the results shown in 14-27.






Through the above operation, the need to import the group and the user's information into the directory database, the next need to set up the client, using LDAP for login verification operation.








14.6.3 Setting up Client Login



If the client wants to use LDAP for user logon authentication, it can log on using a user name that does not exist on the local computer.

"Instance 14-8" modifies the configuration file and sets the client to authenticate using LDAP.



The following are the steps:



(1) Modify the/etc/sysconfig/authconfig file on the client computer to modify the following to Yes:


Useldap=yes useldapauth=yes usemd5=no Useshadow=yes uselocauthorize=yes


(2) Modify the/etc/openldap/ldap.conf file on the client computer and modify the contents as follows:


Host 192.168.206.11 BASE dc=wyh,dc=com SSL off


(3) Modify the/etc/nsswitch.conf file on the client computer, followed by ldap,14-28 in passwd, Shadow, and group.





14.7 Summary of this chapter



This chapter describes the content of using the OpenLDAP directory service, first introduces the LDAP basic model, then details the process of installing and configuring the OpenLDAP server, and then describes the commands to add entries, modify entries, and query entries to OpenLDAP through client commands. And the method of setting up the master-slave OpenLDAP Server for data replication, and finally introduces the method of migrating user authentication data to OpenLDAP.



OpenLDAP is a very useful tool for saving information, this chapter describes the procedure for installing an LDAP server, and describes how to access the OpenLDAP entry by means of a command method. In real-world applications, it is more like accessing data in a database, using program code to access and modify the entry information in LDAP.






Reference: http://book.51cto.com/art/201002/182321.htm






This article comes from the "Ricky's blog" blog, please be sure to keep this source http://57388.blog.51cto.com/47388/1554680



Linux--Directory service configuration and application (LDAP protocol) (2)


Contact Us

The content source of this page is from Internet, which doesn't represent Alibaba Cloud's opinion; products and services mentioned on that page don't have any relationship with Alibaba Cloud. If the content of the page makes you feel confusing, please write us an email, we will handle the problem within 5 days after receiving your email.

If you find any instances of plagiarism from the community, please send an email to: info-contact@alibabacloud.com and provide relevant evidence. A staff member will contact you within 5 working days.

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.