The Suretec Blog

OpenLDAP Quick Tips: Replication Strategies

nospam@example.com (Gavin Henry) — Wed, 17 Dec 2008 12:31:00 +0000

Hi All,

Here's the 22nd tip in the "OpenLDAP Quick Tips" series:

"You are not sure what type of OpenLDAP replication to use, but you know you need to".

This tip won't actually go into the technical setup (and isn't very quick ) of the different replication types, we'll leave that for another set of tips. You can always read up on them yourself in the Replication section of the OpenLDAP 2.4 Administrator's Guide. Or if you're coming to the UKUUG's annual Large Installation Systems Administration (LISA) you'll be able to hear Howard Chu and myself give our talks:

- OpenLDAP Replication Strategies - Gavin Henry (Suretec Systems & OpenLDAP project)
- OpenLDAP and MySQL: Bridging the Data Model Divide - Howard Chu (Symas Corp. & OpenLDAP project).

Andrew Findlay (Skills 1st), another respected authority on LDAP^[?] will also be giving a talk on Writing Access Control Policies for LDAP.

Anyway, on to the strategies.

You already know that replicated directories are a fundamental requirement for delivering a resilient enterprise deployment, but which one to choose?

You'll probably be thinking in terms of a master server and some number of slave servers. Stop, this is old terminology now and in 2.4 they are now called provider and consumer. Let me explain.

In older releases of OpenLDAP (2.3) a master accepted directory updates from other clients, and a slave only accepted updates from a (single) master. The replication structure was rigidly defined and any particular database could only fulfill a single role, either master or slave:

As OpenLDAP now supports a wide variety of replication topologies, these terms have been deprecated in favor of provider and consumer: A provider replicates directory updates to consumers; consumers receive replication updates from providers. Unlike the rigidly defined master/slave relationships, provider/consumer roles are quite fluid: replication updates received in a consumer can be further propagated by that consumer to other servers, so a consumer can also act simultaneously as a provider. Also, a consumer need not be an actual LDAP server; it may be just an LDAP client.

The 5 main options are:

Syncrepl replication

Delta-syncrepl replication

N-Way Multi-Master replication

MirrorMode replication

Syncrepl Proxy Mode

1. Syncrepl is covered exhaustively in the Admin Guide, but briefly it always starts from the consumer, i.e. pull-based. Depending on how it's been configured, the consumer will check for updates at certain intervals or it will remain active and process the persistent messages from the provider, i.e. push based. It will always start from the consumer though, so bear this in mind for firewall issues. This is best used for directory replication where bandwidth isn't an issue due the fact that each consumer fetches and processes the complete changed object, including both the changed and unchanged attribute values:

For example, suppose you have a database consisting of 100,000 objects of 1 KB each. Further, suppose you routinely run a batch job to change the value of a single two-byte attribute value that appears in each of the 100,000 objects on the master. Not counting LDAP and TCP/IP protocol overhead, each time you run this job each consumer will transfer and process 1 GB of data to process 200KB of changes!

2. Delta-syncrepl came into existence due to the above fact. This isn't all bad though:

One advantage of this approach is that when multiple changes occur to a single object, the precise sequence of those changes need not be preserved; only the final state of the entry is significant. But this approach may have drawbacks when the usage pattern involves single changes to multiple objects.

Delta-syncrepl uses a changelog and the consumer checks this log for any updates. If these updates are too out of sync, the consumer will fall back to syncrepl to catch up and switch back to delta when ready.

3. N-Way Multi-Master replication is new in 2.4 and will keep quiet all the people that complained about it not being there when comparing OpenLDAP to other proprietry directory servers. Why not to use it and when to use it is discussed in full in the guide. Basically you would use it because:

- If any provider fails, other providers will continue to accept updates
- Avoids a single point of failure
- Providers can be located in several physical sites i.e. distributed across the network/globe.
- Good for Automatic failover/High Availability

4. MirrorMode replication is for Active-Active Hot-Standby and is often the best solution versus N-Way multimaster:

In MirrorMode two providers are set up to replicate from each other (as a multi-master configuration), but an external frontend is employed to direct all writes to only one of the two servers. The second provider will only be used for writes if the first provider crashes, at which point the frontend will switch to directing all writes to the second provider. When a crashed provider is repaired and restarted it will automatically catch up to any changes on the running provider and resync.

5. Syncrepl Proxy Mode is used for push-based replication and can be used to replace slurpd whereby the provider pushes out changes. This is useful when a provider is behind a firewall which doesn't allow incoming connections and your slaves are outside the main network.

Hopefully above helps you pick which replication to technique to use, but to quickly decide, ask yourself:

1. Is bandwidth an issue?
2. Where do I want my directories located?
3. What firewalling do I have?
4. What is most important to me; the ability to accept writes? an available directory? Distributed directories? Easy backups (mirrormode and N-way need careful planning)?

There are more questions to ask and answer, but I'm sure you'll get there with the help of the docs and the OpenLDAP Project support facilities. If not, speak to us.

Thanks,

Gavin.

If you have an entry for our "OpenLDAP Quick Tips" series, why not e-mail your tip to us.

P.S. For direct access to this section, you can click OpenLDAP Quick Tips.

OpenLDAP Quick Tips: Interacting with LDAP from shell scripts by Vincent van Gelder

nospam@example.com (Gavin Henry) — Fri, 12 Dec 2008 13:30:02 +0000

Hi All,

Here's the 21st tip in the "OpenLDAP Quick Tips" series kindly contributed by Vincent van Gelder.

"You need to carry out LDAP^[?] operations using shell scripts".

The following is an example sent in by Vincent van Gelder (you can e-mail your tip to us too):

------------------------
The following script I use when interacting with ldap^[?] from shell scripts:

http://members.tripod.com/vgoenka/unixscripts/unldif.sed.txt

Sample script:

CODE:

###################################### #!/bin/bash PHOTO=/tmp/tux.jpg IFS=$'\n' for dn in $(ldapsearch -ZZ -LLL -A -b 'ou=Users,ou=Intranet,o=Company,c=NL' -s one '(&(!(jpegPhoto=*))(objectClass=inetOrgPerson))' jpegPhoto \ | unldif | grep '^dn' ) do echo $dn echo "changetype: modify" echo "add: jpegPhoto" echo "jpegPhoto::$(openssl base64 -in $PHOTO | sed 's/^/ /')" echo done ######################################

The sample script fetches users from ldap whithout a photo and adds a
default photo. Output is a ldif.

It also demonstrates how to add binary attributes from shell using
openssl tool.

The unldif script makes sure the dn is always just one line.

--
Met vriendelijke groet,

Vincent van Gelder
------------------------

Thanks,

Gavin.

If you have an entry for our "OpenLDAP Quick Tips" series, why not e-mail your tip to us.

P.S. For direct access to this section, you can click OpenLDAP Quick Tips.

OpenLDAP Source vs Symas OpenLDAP

nospam@example.com (Suretec) — Thu, 11 Dec 2008 10:57:22 +0000

We've just published two comparisons of OpenLDAP source management versus Symas OpenLDAP Packages:

OpenLDAP™ Source vs Symas™ OpenLDAP™

Debian OpenLDAP™ vs Symas™ OpenLDAP™

Nothing special, just a quick comparison.

Suretec^®

OpenLDAP Quick Tips: Enable in Directory Monitoring

nospam@example.com (Gavin Henry) — Thu, 11 Dec 2008 10:14:43 +0000

Hi All,

Here's the 20th tip in the "OpenLDAP Quick Tips" series:

"You need to obtain information regarding the current state of your slapd instance":

slapd(8) supports an optional LDAP^[?] monitoring interface you can use to obtain information regarding the current state of your slapd instance. For instance, the interface allows you to determine how many clients are connected to the server currently. The monitoring information is provided by a specialized backend, the monitor backend. A manual page, slapd-monitor(5) is available.

At the end of your slapd.conf file add:

CODE:

database monitor

and restart.

You'll now be able to query information like the following and use it in your monitoring tools:

CODE:

dn: cn=Total,cn=Connections,cn=Monitor structuralObjectClass: monitorCounterObject monitorCounter: 4 entryDN: cn=Total,cn=Connections,cn=Monitor subschemaSubentry: cn=Subschema hasSubordinates: FALSE

Thanks,

Gavin.

If you have an entry for our "OpenLDAP Quick Tips" series, why not e-mail your tip to us.

P.S. For direct access to this section, you can click OpenLDAP Quick Tips.

OpenLDAP Quick Tips: Encrypt your Oracle Berkeley DB if necessary

nospam@example.com (Gavin Henry) — Tue, 09 Dec 2008 09:39:00 +0000

Hi All,

Here's the 18th tip in the "OpenLDAP Quick Tips" series:

"You need to encrypt the raw bdb files":

This might be useful various reasons:

It may actually provide some value to sites that do regular backups of their raw DB files. It may actually be useful in some cases where you provide an encryption key on separate removable media (e.g. a USB flash drive). It might actually prevent a news article down the road on how some organization lost their 5 million record customer database and now all that unprotected data is now being exploited by criminals.

I doubt it, of course. It exacts a performance penalty on every DB operation, so I don't think anyone will be able to use this long-term. For the off-site backup scenario, it makes more sense to just encrypt the backup images (tar format or whatever backup utility is used). That way you only spend cycles on encryption once, at backup time. Any site that's savvy enough to do automated backups can certainly figure out how to protect those backups with encryption.

Also:

The one place where I could see using this is if one is using OpenLDAP as
the backend to a Kerberos KDC. It's considered best practice right now to
always encrypt the KDC database at rest on disk, and some sites even
require an administrator be present with a USB key to unlock the database
whenever a KDC has to be rebooted. Given the increasing interest in using
LDAP^[?] as a backend store for the KDC, this may be a simpler method for
providing equivalent KDC security without encrypting various bits of data
individually

Taking this all into account, what is needed is simply adding to your slapd.conf file:

CODE:

cryptkey testing

Note: there is also a cryptfile option to store the password in a seperate file.

If you already have a directory setup, then exporting your data and importing it again is needed to encrypt the files. A basic slapd.conf file needed would be:

CODE:

include /usr/local/etc/openldap/schema/core.schema pidfile ./slapd.pid argsfile ./slapd.args modulepath /usr/local/libexec/openldap moduleload back_bdb.la database bdb suffix "dc=suretecsystems,dc=com" rootdn "cn=admin,dc=suretecsystems,dc=com" rootpw secret directory ./openldap-data cryptkey testing index objectClass eq

Then import your data with slapadd and test with the bdb tools:

CODE:

[ghenry@suretec openldap-data]$ /usr/local/BerkeleyDB.4.7/bin/db_dump objectClass.bdb db_verify: Encrypted environment: no encryption key supplied [ghenry@suretec openldap-data]$ /usr/local/BerkeleyDB.4.7/bin/db_dump -P "test" objectClass.bdb db_verify: Invalid password [ghenry@suretec openldap-data]$ /usr/local/BerkeleyDB.4.7/bin/db_dump -P "testing" objectClass.bdb VERSION=3 format=bytevalue type=btree chksum=1 duplicates=1 dupsort=1 db_pagesize=4096 HEADER=END 0096defd 00000001 21d9e0af 00000001 62c4d55f 00000001 DATA=END

Things to note:

You need the bdb version that supports encryption, i.e. not the one that has NC in the package name and that the only encrypted parts of a database environment are its databases and its log files. Specifically, the shared memory regions supporting the database environment are not encrypted. For this reason, it may be possible for an attacker to read some or all of an encrypted database by reading the on-disk files that back these shared memory regions.

For more information see the slapd-bdb man page.

Thanks,

Gavin.

If you have an entry for our "OpenLDAP Quick Tips" series, why not e-mail your tip to us.

P.S. For direct access to this section, you can click OpenLDAP Quick Tips.

OpenLDAP Quick Tips: Always 'make test'

nospam@example.com (Gavin Henry) — Thu, 04 Dec 2008 11:22:00 +0000

Hi All,

Here's the 17th tip in the "OpenLDAP Quick Tips" series:

"You've successfully built your own instance of OpenLDAP but want to make sure you've done it right":

So, you've grabbed the latest version, compiled it and want to get started straight way, but stop! Hours and hours have been spent writing test scripts for OpenLDAP, so please, please, please run:

CODE:

make test

before

CODE:

su -c "make install"

and save the OpenLDAP Issue Tracking System from getting full with silly reports!

Also, see our installation section of the FAQ.

If this is too much, why not get supported, prepackaged versions of OpenLDAP: Symas™ OpenLDAP™ Directory Services™

Thanks,

Gavin.

If you have an entry for our "OpenLDAP Quick Tips" series, why not e-mail your tip to us.

P.S. For direct access to this section, you can click OpenLDAP Quick Tips.

OpenLDAP Quick Tips: Auditing - who modified what at what times?

nospam@example.com (Gavin Henry) — Wed, 03 Dec 2008 15:22:16 +0000

Hi All,

Here's the 16th tip in the "OpenLDAP Quick Tips" series (as requested by Bronius Motekaitis):

"You want to audit OpenLDAP for changes: who modified what at what times?":

Apart from normal logging via syslog there are two options for this; file based audit logging or LDAP^[?] based logging (in directory).

For file based see Audit Logging and related man page slapo-auditlog:

The Audit Logging overlay can be used to record all changes on a given
backend database to a specified log file. Changes are logged as stan-
dard LDIF, with an additional comment header giving the timestamp of
the change and the identity of the user making the change.

For in directory logging see Access Logging and related man page slapo-accesslog:

The Access Logging overlay can be used to record all accesses to a
given backend database on another database. This allows all of the
activity on a given database to be reviewed using arbitrary LDAP
queries, instead of just logging to local flat text files.

Thanks,

Gavin.

If you have an entry for our "OpenLDAP Quick Tips" series, why not e-mail your tip to us.

P.S. For direct access to this section, you can click OpenLDAP Quick Tips.

OpenLDAP Quick Tips: Change loglevels on the fly!

nospam@example.com (Gavin Henry) — Tue, 02 Dec 2008 12:45:00 +0000

Hi All,

Here's the 15th tip in the "OpenLDAP Quick Tips" series:

"You want to change your OpenLDAP loglevel to get more information, but can't take your directory server offline":

If you've been following the OpenLDAP Quick Tips series, you would have already read Switch to the dynamic config backend (cn=config) and will now have a live slapd dynamic backend configured. If not, go back and read it over

Let's say you are running the stats (256) loglevel, but you want to know look at the sync loglevel or both. Making the change is much the same as with Check your indices. First we check our current level:

CODE:

[ghenry@suretec ~]$ ldapsearch -x -H ldap^[?]://xxx.xxx.xxx.xxx -b 'cn=config' -D 'cn=config' -s base -LLL -W olcLoglevel Enter LDAP^[?] Password: dn: cn=config olcLogLevel: Stats

This shows that we are on the stats (256) level. We can either swap this to sync or add it to the current level not loosing the stats level. Let's add it with the following LDIF:

CODE:

dn: cn=config changetype: modify add: olcLoglevel olcLoglevel: Sync

The results will look like:

CODE:

ldapmodify -x -D 'cn=config' -W -f newloglevel.ldif

which will show in your logs as:

CODE:

Dec 2 13:06:23 suretecsystems slapd[27824]: conn=13687 fd=46 ACCEPT from IP=XXX.XXX.XXX.XXX:46272 (IP=0.0.0.0:389) Dec 2 13:06:23 suretecsystems slapd[27824]: conn=13687 op=0 BIND dn="cn=config" method=128 Dec 2 13:06:23 suretecsystems slapd[27824]: conn=13687 op=0 BIND dn="cn=config" mech=SIMPLE ssf=0 Dec 2 13:06:23 suretecsystems slapd[27824]: conn=13687 op=0 RESULT tag=97 err=0 text= Dec 2 13:06:23 suretecsystems slapd[27824]: conn=13687 op=1 MOD dn="cn=config" Dec 2 13:06:23 suretecsystems slapd[27824]: conn=13687 op=1 MOD attr=olcLoglevel Dec 2 13:06:23 suretecsystems slapd[27824]: slap_queue_csn: queing 0x8b986aa2 20081202130623.645866Z&000000;000#000000 Dec 2 13:06:23 suretecsystems slapd[27824]: conn=13687 op=1 RESULT tag=103 err=0 text= Dec 2 13:06:23 suretecsystems slapd[27824]: slap_graduate_commit_csn: removing 0xa39d730 20081202130623.645866Z&000000;000#000000 Dec 2 13:06:23 suretecsystems slapd[27824]: conn=13687 op=2 UNBIND Dec 2 13:06:23 suretecsystems slapd[27824]: conn=13687 fd=46 close

To remove it just use a delete changetype.

It should now be obvious how to add and change settings via cn=config.

Thanks,

Gavin.

If you have an entry for our "OpenLDAP Quick Tips" series, why not e-mail your tip to us.

P.S. For direct access to this section, you can click OpenLDAP Quick Tips.

OpenLDAP Quick Tips: OpenLDAP Logfile analysis

nospam@example.com (Gavin Henry) — Mon, 01 Dec 2008 14:32:43 +0000

Hi All,

Here's the 14th tip in the "OpenLDAP Quick Tips" series and today it comes from "Pablo Chamorro":

"You want to analyse your OpenLDAP logfile":

There are various ways to do this yourself by hand, but the have community already done the work for you and written the:

OpenLDAP Logfile analysis utility:

ldap^[?]-stats.pl is a Perl program that can be used to analyze and report on OpenLDAP logfiles. The available reports include: operations (e.g., Connect, Bind, Unbind) performed per host, unindexed searches, attributes requested, search filters used, total operations per server, and operation breakdowns by day, hour and month.

A short sample output would look like:

CODE:

[root@suretec ~]# ./ldap-stats.pl /var/log/openldap.log Report Generated on Mon Dec 1 14:57:43 2008 -------------------------------------------- Processed "/var/log/openldap.log": Apr 5 00:01:50 - Dec 1 08:39:33 Operation totals ---------------- Total operations : 19258 Total connections : 7061 Total authentication failures : 2358 Total binds : 4403 Total unbinds : 6661 Total searches : 7849 Total compares : 0 Total modifications : 215 Total modrdns : 0 Total additions : 128 Total deletions : 2 Unindexed attribute requests : 0 Operations per connection : 2.73 ..... ..... .....

A longer sample is available.

Thanks,

Gavin.

If you have an entry for our "OpenLDAP Quick Tips" series, why not e-mail your tip to us.

P.S. For direct access to this section, you can click OpenLDAP Quick Tips.

OpenLDAP Quick Tips: Use the FAQ!

nospam@example.com (Gavin Henry) — Fri, 28 Nov 2008 09:09:33 +0000

Hi All,

Here's my 13th tip in the "OpenLDAP Quick Tips" series:

"You have a question, but you're sure someone has been there before":

That's what our FAQ-O-Matic is for!

Search it, browse it and check the common areas:

Installation

Configuration

Integration

Maintenance

Common Errors

When all else fails...

When all else fails, join our mailing lists.

Thanks,

Gavin.

If you have an entry for our "OpenLDAP Quick Tips" series, why not e-mail your tip to us.

P.S. For direct access to this section, you can click OpenLDAP Quick Tips.

OpenLDAP Quick Tips: Switch to the dynamic config backend (cn=config)

nospam@example.com (Gavin Henry) — Thu, 27 Nov 2008 10:30:00 +0000

Hi All,

Here's my 12th tip in the "OpenLDAP Quick Tips" series:

"You want to switch from slapd.conf to the configuration backend to slapd":

The config backend is backward compatible with the older slapd.conf(5)
file but provides the ability to change the configuration dynamically
at runtime. If slapd is run with only a slapd.conf file dynamic changes
will be allowed but they will not persist across a server restart.
Dynamic changes are only saved when slapd is running from a slapd.d
configuration directory.

The following should be getting you very excited:

provides the ability to change the configuration dynamically
at runtime.

"What, I don't need to restart my directory server if I make config changes?"

Not only that, but you can do cool things like promoting/switching a slave directory server to a master server on the fly! (that's one for another tip though).

To start, we will simply show you how to convert an existing fully configured slapd.conf to the slapd.d format.

It's worth mentioning if you missed it above, but you can already do this if you have the cn=config user password set, as changes must be made via that user. When you make a config change over LDAP^[?], it will take affect but not on a restart, as slapd.conf gets read again. This is usefull though if you always want to start from a known config and just make runtime changes when needed.

Here, try this:

CODE:

[ghenry@suretec ]$ ldapsearch -x -b 'cn=config' # extended LDIF # # LDAPv3 # base <cn=config> with scope subtree # filter: (objectclass=*) # requesting: ALL # # config dn: cn=config objectClass: olcGlobal cn: config olcConfigFile: slapd.conf olcConfigDir: slapd.d olcArgsFile: /usr/local/var/run/slapd.args olcAttributeOptions: lang- olcAuthzPolicy: none olcConcurrency: 0 olcConnMaxPending: 100 olcConnMaxPendingAuth: 1000 olcGentleHUP: FALSE olcIdleTimeout: 0 olcIndexSubstrIfMaxLen: 4 olcIndexSubstrIfMinLen: 2

Before we convert, add this to the bottom of your existing slapd.conf file because you can't make changes with out a password configured (use slappasswd later to encrypt the password):

CODE:

# Dynamic Config database config rootpw secret

To convert to the new format do:

CODE:

cd /usr/local/etc/openldap mkdir slapd.d /usr/local/sbin/slaptest -f /usr/local/etc/openldap/slapd.conf -F slapd.d

The directory created looks like:

CODE:

[ghenry@suretec ]$ ls slapd.d/ cn=config cn=config.ldif

You can edit those files prior to startup if you like also, but you have now converted to the new format.

If you created the slapd.d directory in the default place, then slapd will automatically ignore the old slapd.conf and use the new config backend slapd.d. This is clearly stated in the man page:

-F slapd-config-directory
Specifies the slapd configuration directory. The default is
/usr/local/etc/openldap/slapd.d. If both -f and -F are speci-
fied, the config file will be read and converted to config
directory format and written to the specified directory. If
neither option is specified, slapd will attempt to read the
default config directory before trying to use the default config
file. If a valid config directory exists then the default config
file is ignored. All of the slap tools that use the config
options observe this same behavior.

You can also just point slapd as normal to the new directory with the -F option.

In another tip we will talk about making changes to this backend using normal LDAP operations.

Thanks,

Gavin.

If you have an entry for our "OpenLDAP Quick Tips" series, why not e-mail your tip to us.

P.S. For direct access to this section, you can click OpenLDAP Quick Tips.

Community Request: Real World OpenLDAP Deployments

nospam@example.com (Gavin Henry) — Thu, 27 Nov 2008 10:14:15 +0000

Dear All,

I'd like to get some examples written up for:

http://www.openldap.org/doc/admin24/appendix-deployments.html

If anyone is interested and allowed to share some information, I'd
love to hear from you.

The more strange the setup the better!

Many thanks,

Gavin.

P.S. This has also been sent to the openldap-technical@openldap.org mailing list, so if you are a subscriber please reply to that email. Thanks.

OpenLDAP Quick Tips: Check your indices

nospam@example.com (Gavin Henry) — Wed, 26 Nov 2008 11:12:24 +0000

Hi All,

Here's my 11th tip in the "OpenLDAP Quick Tips" series:

"You want to make sure you have the correct indices configured for the best performance":

It's easy to discover when you do not have the correct indices set by checking your ldap^[?] log. If you see something similar to:

CODE:

Nov 26 11:10:16 localhost slapd[2957]: conn=17 fd=13 ACCEPT from IP=XXX.XXX.XXX.XXX:38019 (IP=0.0.0.0:389) Nov 26 11:10:16 localhost slapd[2957]: conn=17 op=0 BIND dn="" method=128 Nov 26 11:10:16 localhost slapd[2957]: conn=17 op=0 RESULT tag=97 err=0 text= Nov 26 11:10:16 localhost slapd[2957]: conn=17 op=1 SRCH base="dc=suretecsystems,dc=com" scope=2 deref=0 filter="(o=suretec systems ltd.)" Nov 26 11:10:16 localhost slapd[2957]: <= bdb_equality_candidates: (o) not indexed Nov 26 11:10:16 localhost slapd[2957]: conn=17 op=1 SEARCH RESULT tag=101 err=0 nentries=3 text= Nov 26 11:10:16 localhost slapd[2957]: conn=17 op=2 UNBIND Nov 26 11:10:16 localhost slapd[2957]: conn=17 fd=13 closed

namely:

CODE:

Nov 26 11:10:16 localhost slapd[2957]: <= bdb_equality_candidates: (o) not indexed

then you have not configured an equality index for the o attribute.

Add index o eq to your slapd.conf and then stop slapd and run slapindex as the user that runs slapd (probably the ldap user). Now start slapd up again.

If you add an index over the LDAP^[?] protocol whilst using the slapd config backend, then the index will be created on the fly and you won't need to use slapdindex or restart your directory server. Use the following LDIF as your starting point:

CODE:

dn: olcDatabase={1}hdb,cn=config changetype: modify add: olcDbIndex olcDbIndex: o eq

The above assumes you have an hdb backend and it is configured to hold your directory data as the first database (database 0 holds cn=config):

CODE:

ldapmodify -D 'cn=config' -W -f newindex.ldif

will show in your logs as:

CODE:

Nov 26 11:57:51 localhost slapd[2957]: conn=27 fd=13 ACCEPT from IP=XXX.XXX.XXX.XXX:45776 (IP=0.0.0.0:389) Nov 26 11:57:51 localhost slapd[2957]: conn=27 op=0 BIND dn="cn=config" method=128 Nov 26 11:57:51 localhost slapd[2957]: conn=27 op=0 BIND dn="cn=config" mech=SIMPLE ssf=0 Nov 26 11:57:51 localhost slapd[2957]: conn=27 op=0 RESULT tag=97 err=0 text= Nov 26 11:57:51 localhost slapd[2957]: conn=27 op=1 MOD dn="olcDatabase={1}hdb,cn=config" Nov 26 11:57:51 localhost slapd[2957]: conn=27 op=1 MOD attr=olcDbIndex Nov 26 11:57:51 localhost slapd[2957]: slap_queue_csn: queing 0xa2b4aa52 20081126115751.937214Z&000000;000#000000 Nov 26 11:57:51 localhost slapd[2957]: conn=27 op=1 RESULT tag=103 err=0 text= Nov 26 11:57:51 localhost slapd[2957]: slap_graduate_commit_csn: removing 0x98743b8 20081126115751.937214Z&000000;000#000000 Nov 26 11:57:51 localhost slapd[2957]: conn=27 op=2 UNBIND Nov 26 11:57:51 localhost slapd[2957]: conn=27 fd=13 closed

and then to confirm by searching for the o attribute again:

CODE:

Nov 26 11:58:25 localhost slapd[2957]: conn=28 fd=19 ACCEPT from IP=XXX.XXX.XXX.XXX:33576 (IP=0.0.0.0:389) Nov 26 11:58:25 localhost slapd[2957]: conn=28 op=0 BIND dn="" method=128 Nov 26 11:58:25 localhost slapd[2957]: conn=28 op=0 RESULT tag=97 err=0 text= Nov 26 11:58:25 localhost slapd[2957]: conn=28 op=1 SRCH base="dc=suretecsystems,dc=com" scope=2 deref=0 filter="(o=suretec systems ltd.)" Nov 26 11:58:25 localhost slapd[2957]: conn=28 op=1 SEARCH RESULT tag=101 err=0 nentries=3 text= Nov 26 11:58:25 localhost slapd[2957]: conn=28 op=2 UNBIND Nov 26 11:58:25 localhost slapd[2957]: conn=28 fd=19 closed

No more compliants about the lack of an index and no restarting slapd!

Thanks,

Gavin.

If you have an entry for our "OpenLDAP Quick Tips" series, why not e-mail your tip to us.

P.S. For direct access to this section, you can click OpenLDAP Quick Tips.

Fedora 10 is out!

nospam@example.com (Gavin Henry) — Tue, 25 Nov 2008 17:58:12 +0000

Grab it whilst it's hot!

OpenLDAP Quick Tips: Regularly upgrade OpenLDAP!

nospam@example.com (Gavin Henry) — Tue, 25 Nov 2008 09:23:46 +0000

Hi All,

Here's my 10th tip in the "OpenLDAP Quick Tips" series:

"You want to stay up to date with the latest version of OpenLDAP to benefit from bug fixes":

There's never been a better time to upgrade to the 2.4 series. It's actually very easy. If there haven't been any significant core changes between releases (excluding a 2.3.x to 2.4.x upgrade), then you can easily just install a new version on top of the existing one and restart.

If there has been a Berkeley DB change or any form data storage change (indexing etc.) then you should follow these steps:

1. Stop the current server when convenient
2. slapcat the current data out
3. Clear out the current data directory (/usr/local/var/openldap-data/) leaving DB_CONFIG in place
4. Perform the software upgrades
5. slapadd the exported data back into the directory
6. Start the server

It is recommended to do the above anyway, just to make sure as you can always start fresh with exported data.

Obviously this doesn't cater for any complicated deployments like MirrorMode or N-Way Multi-Master, but should you need advice or help, you can use either commercial support or community support to help you....or contact Suretec.

Thanks,

Gavin.

If you have an entry for our "OpenLDAP Quick Tips" series, why not e-mail your tip to us.

P.S. For direct access to this section, you can click OpenLDAP Quick Tips.