Ldap mass email system database application guide

Article Title: Database Application Guide for ldap large-capacity Mail System. Linux is a technology channel of the IT lab in China. Includes basic categories such as desktop applications, Linux system management, kernel research, embedded systems, and open source.

Most of the ldap documents on the Internet today are copied from each other. It's all about him. In fact, ldap is mainly used in large-capacity mail systems. Almost all documents have avoided this issue and always go around in the address book!

Ldap is actually a database. How does it store data? However, it is different from our common relational databases. A relational database has a two-dimensional table to store data. Ldap is similar to our dns system and tree-like. Use nodes to store data. Of course, a branch can have n nodes, and the data stored on each node is in the form of key => value. Like our dns system. . Is the root, below is com, org, net, cn and so on some branches, under these branches there are abc.com, bcd.com and so on branches. Nodes can be placed under each branch. In fact, hosts under the domain name are www, ftp, mail, and so on. All these contents constitute a dns tree called a database in ldap. This should be a good image.

The following describes the implementation of ldap. I mainly use ldap to store user information in the mail system, including username, clearpw, maildir, and so on, in this way, you can retrieve ldap to know the location of the mail to the hard disk during the mail delivery process.
First pull the source code of berkeley-DB (http://www.sleepycat.com/), My is 4.1.25, openldap needs this thing, it is actually nothing bad, so I mounted it to/usr.
# Tar zxvf db-4.1.25.tar.gz
# Cd db-4.1.25
# Cd dist
#./Configure -- prefix =/usr
# Make
# Make install

Then you can start to install openldap. I use 2.1.22 and the original code is from
Http://www.openldap.org.
# Tar zxvf openldap-2.1.22.tgz
# Cd openldap-2.1.22
#./Configure -- prefix =/usr/local/openldap
# Make depend
# Make
# Make test
# Make install

There should be no problems with this part of the installation. If there is a problem, go to the online documentation. Although I cannot mention the key points, this aspect is still detailed. The following is the configuration.


Schema

Schema is similar to the field description of a relational database, including the field name, data type, and data length. The system has some default schemas. My default schema file is under/usr/local/openldap/etc/openldap/schema. The most important thing is core. schema. It defines some basic fields.

To adapt to our application, we need to create our own schema file. The shema file I created is as follows: (File Name: kunmail. schema)

#
# Kunmail-ldap v3 directory schema
#
# Written by hefish@cz8.net
#
# Attribute Type Definitions

Attributetype (1.3.6.1.4.1.7914.1.2.1.1 NAME 'username'
DESC 'name of the user on the mailsystem'
EQUALITY caseIgnoreIA5Match
SYNTAX 1.3.6.1.4.1.1466.115.121.1.26
SINGLE-value)

Attributetype (1.3.6.1.4.1.7914.1.2.1.2 NAME 'vuid'
DESC 'uid of the user on the mailsystem'
EQUALITY integerMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
SINGLE-value)

Attributetype (1.3.6.1.4.1.7914.1.2.1.3 NAME 'vgid'
DESC 'Gid of the user on the mailsystem'
EQUALITY integerMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
SINGLE-value)

Attributetype (1.3.6.1.4.1.7914.1.2.1.4 NAME 'maildir'
DESC 'path to the maildir/mbox on the mail system'
EQUALITY caseExactMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
SINGLE-value)

Attributetype (1.3.6.1.4.1.7914.1.2.1.5 NAME 'forwardaddr'
SUBSTR caseIgnoreSubstringsMatch
DESC 'forward mail address'
EQUALITY caseIgnoreIA5Match
SYNTAX 1.3.6.1.4.1.1466.115.121.1.26)

Attributetype (1.3.6.1.4.1.7914.1.2.1.6 NAME 'quota'
DESC 'the amount of space The user can use until all further messages get bounced .'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.44
SINGLE-value)

Attributetype (1.3.6.1.4.1.7914.1.2.1.7 NAME 'storehost'
DESC 'on which kunmail server the messagestore of this user is located .'
EQUALITY caseIgnoreIA5Match
SYNTAX 1.3.6.1.4.1.1466.115.121.1.26
SINGLE-value)

Attributetype (1.3.6.1.4.1.7914.1.2.1.8 NAME 'delivery'
DESC 'program to execute for all incoming mails .'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
SINGLE-value)

Attributetype (1.3.6.1.4.1.7914.1.2.1.9 NAME 'clearpw'
DESC 'name of the user on the mailsystem'
EQUALITY caseIgnoreIA5Match
SYNTAX 1.3.6.1.4.1.1466.115.121.1.26
SINGLE-value)

Attributetype (1.3.6.1.4.1.7914.1.2.1.10 NAME 'home'
DESC 'program to execute for all incoming mails .'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
SINGLE-value)

Attributetype (1.3.6.1.4.1.7914.1.2.1.11 NAME 'mailreplytext'
DESC 'a reply text for every incoming message'
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.44 {4096}
SINGLE-value)

Attributetype (1.3.6.1.4.1.7914.1.2.1.12 NAME 'active'
DESC 'the status of a user account: active, nopop, disabled'
EQUALITY integerMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
SINGLE-value)

# Object Class Definitions

Objectclass (1.3.6.1.4.1.7914.1.2.2.1 NAME 'kunmailuser'
DESC 'kunmail-LDAP user' SUP top STRUCTURAL
MUST (username $ cn $ vuid $ vgid)
MAY (maildir $ home $ clearpw $
ForwardAddr $ quota $
StoreHost $ delivery $
MailReplyText $ active ))

Now let's talk about this schema file. The start part is the attributeType definition, which is equivalent to the field definition. The final objectclass defines the attributes contained in the data. Here, the kunmailUser data should include maildir $ home $ clearpw $ forwardAddr $ quota $ storeHost $ delivery $ mailReplyText $ active and other Optional options, and also include the username $ cn $ vuid $ vgid required. MAY () can be used for inclusion, and MUST () is required for inclusion. DESC is the description. SUP indicates the parent class (somewhat like object-oriented programming). top indicates that there is no parent class, and he is a top-level class. STRUCTURAL is a storage method, no matter which one (I cannot tell)
Next, describe attributeType.

The first number indicates the serial number. At least what I think is wrong, maybe not,... Ignore him. NAME indicates the attribute NAME.
DESC is a description
The following describes the matching method. SUBSTR indicates string matching, while EQUALITY indicates EQUALITY matching. These are available in the admin guide of openldap. SYNTAX indicates the field data type. This admin guide also provides instructions. SINGLE-value indicates that this attribute has only one value. Some attributes can have multiple values, such as the contact address. The default value is multi-value.

After the schema is ready, we need to include the schema in the configuration file for the schema to take effect. Add the following sentence to the beginning part of the slapd. conf configuration file: include/usr/local/openldap/etc/openldap/schema/kunmail. schema.

It should be noted that before the above sentence, make sure that there is one sentence: include/usr/local/openldap/etc/openldap/schema/core. schema
Because kunmail. schema depends on core. schema.

Then slapd. conf should look like the following:

# $ OpenLDAP: pkg/ldap/servers/slapd. conf, v 1.23.2.8 2003/05/24 23:19:14 kurt Exp $
#
# See slapd. conf (5) for details on configuration options.
# This file shoshould NOT be world readable.
#
Include/usr/local/openldap/etc/openldap/schema/core. schema
Include/usr/local/openldap/etc/openldap/schema/kunmail. schema

# Define global ACLs to disable default read access.

# Do not enable referrals until AFTER you have a working directory
# Service AND an understanding of referrals.
# Referral ldap: // root.openldap.org

Pidfile/usr/local/openldap/var/slapd. pid
Argsfile/usr/local/openldap/var/slapd. args

######################################## ###############################
# Ldbm database definitions
######################################## ###############################

Database bdb
Suffix "dc = cz8, dc = net"
Rootdn "cn = Manager, dc = cz8, dc = net"
# Cleartext passwords, especially for the rootdn, shocould
# Be avoid. See slappasswd (8) and slapd. conf (5) for details.
# Use of strong authentication encouraged.
Rootpw abcd1234

# The database directory MUST exist prior to running slapd AND
# Shoshould only be accessible by the slapd and slap tools.
# Mode 700 recommended.
Directory/usr/local/openldap/var/openldap-data
# Indices to maintain
Index objectClass eq


I have configured a Database "dc = cz8, dc = net". If necessary, you can configure multiple databases, each of them starts with a database. For more information, see the admin guide. (Generally, a company uses a database) to start the ldap service!
# Cd/usr/local/openldap/libexec
#./Slapd

The next thing is to add data to the database. Ldap does not support SQL. Therefore, ldapadd is used to add the program. When adding the program, an ldif file is used to write the content to be added. The ldif format is described in the admin guide, here is a brief introduction.

First, add the root. This step is necessary. Otherwise, no data is added. Edit a root. ldif file:

Dn: dc = cz8, dc = net
Dc: cz8
Description: YuCa Network Studio
ObjectClass: dcObject
ObjectClass: organization
O: YuCa Network



Then run the ldapadd command to add it to ldap.
#./Ldapadd-f root. ldif-x-D "cn = Manager, dc = cz8, dc = net"-w abcd1234

Then I want to add a branch to the database to store the user data of the mail system. This branch is said to be an ou (organizational unit). Generally, different branches, store different types of data. I name this ou mail. Check the ldif file (mail. ldif)
Dn: ou = mail, dc = cz8, dc = net
ObjectClass: organizationalUnit
Ou: mail
Description: Mail Directory

Continue to use ldapadd.

Add user data under the ou = mail, cd = cz8, dc = net branch: (user. ldif)
Dn: cn = heyu, ou = mail, dc = cz8, dc = net
ObjectClass: kunmailUser
Cn: heyu
Username: heyu@cz8.net
Vuid: 1000
Vgid: 1000.
Clearpw: tmd8427
Home:/exports/mailhome/system/heyu
Maildir:/exports/mailhome/system/heyu/Maildir/
ForwardAddr: hefish@czlib.net
Quota: 10000000
Active: 1

This section mainly explains the above ldif file, mainly the objectClass line, which means that this node stores data records of the kunmailUser type. All others are attributes of the kunmailUser type. Run ldapadd and add it. Now go to an ldap browser/editor and log on to our ldap server to see the tree structure of ldap.