| A/I Orange Book (1.0): An how-to for the realization of a resilient network of self-managed servers | ||
|---|---|---|
| Prev | Chapter 4. The users database | Next |
First of all, you need to install slapd (the server part of the free OpenLDAP suite). The server configuration is defined in the /etc/ldap/slapd.conf file. The very same file it's used also by slurpd (the daemon managing the replicatoin mechanism).
There are three different type of directives in the configuration file of the server:
global
backend-specific
database-specific
The first set of directives set generic parameters for slapd, like the address to bind to, where to put logs, ACLs, and so on...
The second set of options defines parameters needed by the database backend. We decided to use BDB notwithstanding the reported consistency problems (a quick search on the web suggests daily backup of the data), since the other OpenLDAP-supported backend (LDBM) is even officially deprecated...
Last but not least, the third set of options defines parameter to configure the databases (in our case it's a single database), allowing you to specify what indexes to create, where to store teh database, and other options that it's better to check closely. It is absolutely necessary to create an index for each attribute that could be present in a filter. Note that you can create the index at any given moment, so if you forget something you can always add it later (using the slapindex command). However if you missed an index on a frequently used search attribute you will notice it very soon, since a missing index can almost bring a busy server to a complete halt!
We will not enter into the detail of the basic slapd configuration that anybody can find in Chpater 6: "The slapd configuration file" of the "OpenLDAP Administration Guide". In this chapter we would like instead to cover the fine tuning we deployed for increased stability and performance. Nearly any operation on the servers, in fact, implies an LDAP request: this lets you understand how important the efficiency of slapd is to the overall system.
The main problem can be faced from two complementary perspectives: on one side we can try to reduce the number of request to the minimum (for example using various sorts of caching mechanisms); on the other side, we need to optimize the slapd configuration so as to get better performances.
As an example of the first perspective we can relief the server of the very frequent NSS requests. Many unnecessary requests can be avoided by specifying the files directive before the ldap directive in /etc/nssswitch.conf, so as to resolve system users without querying the LDAP database right away. The NSS caching daemon nscd can reduce further these queries to the bare minimum.
Concerning the optimization of the slapd configuration, you can find some thoughts below:
It is absolutely necessary to create indexes in the LDAP database for every attribute used in the various service filters. This is the example you can find in our slapd.conf configuration file, in the database-specific section:
index objectClass,status eq
index sn,uid,mail,alias,cn eq,pres
index host,uidNumber eq,pres
index mailForwardingAddress eq,pres
index mailAlternateAddress eq,pres
When a query is done with a filter depending on an attribute that has not
been indexed, the server needs to examine individually each object in the
database. This is to be avoided at all costs.
Increasing as much as possible the slapd object cache could be handy. A value that could be used to keep the whole database in the cache (if it's not too big) is the amount of directives in the database. You can get this value running the slapcat | wc -l command.
cachesize 50000
Increasing the number of threads the server can spawn and configure a decent timeout for hanging connections can be very useful especially if the load on the LDAP server can lead to client timeouts:
threads 64
idletimeout 300
If local LDAP connection uses up TCP sockets instead of UNIX socket, it
could come in handy to widen the range of available
ephemeral ports, editing for
example the /etc/sysctl.conf file as follows:
net/ipv4/ip_local_port_range=20000 65535It has to be noted that this sort of tuning does good to the overall health of your server even independently of the LDAP suite and server.
Last but least you can modify some parameter of the Berkley DB backend creating a file named DB_CONFIG in the directory where the database are stored (in Debian the directory is /var/lib/ldap). Here also it is better to increase the cache size up to at least 50 Mb (that in modern system is not a problem):
set_cachesize 0 52428800 0It is possible then to specify that the creatoin of temporary files is to be carried on in a tmpfs filesystem:
set_tmp_dir /dev/shmBut most important of all, even if a bit risky, is to disable the write transaction log of the slave servers:
set_flags DB_TXN_NOSYNCThis log provides for data integrity but impacts the performance of the slapd server: on slave servers we can think of giving this security away knowing we can recover a full copy of the database from the master server in the blink of an eye.
The most complex part of the LDAP server configuration is the creation of the ACL (Access Control Lists) needed to make it work properly. This is due partly to the particularly deranged syntax of the ACL themselves... For each requested uid and for each given requesting uid, OpenLDAP will check the first ACL rule (scanning the file from the top down) that it can apply to the requested uid. Then it will check for the first ACL rule it can apply to the requesting uid. For example the following ACL is needed to controll the access to the userPassword attribute:
access to attrs=userPassword
by dn="cn=manager,o=anarchy" write
by group/groupofnames/member=\
"cn=admins,ou=Group,dc=infra,dc=org,o=Anarchy" write
by dn="cn=ring0op,ou=Operators,dc=infra,dc=org,o=Anarchy" read
by dn="cn=ring1op,ou=Operators,dc=infra,dc=org,o=Anarchy" read
by dn="cn=dovecot,ou=Operators,dc=infra,dc=org,o=Anarchy" read
by anonymous auth
by self write
by * none
Modification of the attribute is in any case allowed to ldap manager and to
the servers administrators, while operators can only read the attribute to
use it for authentication.
The order of ACLs in the configuration files is very important: they need to be written starting with the most specific to the least specific (concerning the access to approach).