Directory Services : weblog

Wednesday Jul 16, 2008

Using OpenDS to provide LDAP naming services for Solaris

An article got posted showing the steps for installing OpenDS and using it to provide name services for Solaris. Right now generating an SSL certificate is a bit more complex than it will be in the future, but once you are past that, the rest of the configuration is a piece of cake. Check out the article at:

http://developers.sun.com/identity/reference/techart/opends-namesvcs.html

Posted at 02:22PM Jul 16, 2008 by William Hathaway in General | Comments[0]

Friday May 16, 2008

Using frozen mode for quick backups in Directory Server 6

Frozen Mode

In the 6.x branch of Sun's Directory Server software, a new feature was introduced called frozen mode. Frozen mode essentially tells the server to stop all operations and puts the database(s) into a consistent state. This is a very handy feature since it means you can then use snapshots at the file system or volume manager layer to create a consistent image which can be backed up. Once the snapshot has been taken, you then put the server back into normal read-write mode so it can handle queries. If your storage layers provide a rollback capability, you may be able to perform usable restores very quickly. Using ZFS's snapshot and rollback mechanisms this can typically be done in a matter of seconds.

During the time the server is frozen, any operations that are attempted on the directory data (except the configuration) will fail. While this is typically for a very short period of time, it can be disruptive to client applications. For this reason, it is best that frozen mode backups either be performed on servers that are either receiving no or little client traffic. If a Sun Directory Proxy Server (DPS) is used in the environment, it is easy to have the DPS server disable the directory server during the time the frozen mode backup is taken, making the operation invisible to clients. This can be achieved with a dpconf set-ldap-data-source-prop $server is-enabled:false command and then set the is-enabled property back to true once the server has been restored to read-write mode.

Here is a table that lists the pros and cons of frozen mode backups versus the traditional binary backup method.

Binary Backup Type

Pros

Cons

Standard

(dsconf backup)

Server remains operational throughout backup

Takes a while for backup to complete

Resource intensive

Copy of all data requires 2x the space

Frozen Mode

(setting read-write-mode to frozen and snapshotting)

Minimal space needed for snapshot

Not resource intensive

May allow very quick restores through rollback

Directory server not available for normal operations during snapshot

Needs a storage layer with snapshot capability

Tips for using frozen mode

Put the directory server's database directory on a separate file system (minimize the data that needs to be captured)

Disable tracking 'atime' modifications on the directory server's file systems

Move the DB cache files to a memory based file system (a good idea even if frozen mode isn't used)

Example

This example will show the command line steps for installing a directory server 'slapd_master1' from scratch on a zfs pool named 'data' and using the frozen mode, snapshot, and rollback features.

Installing and configuring the directory server

1. Create a zfs file system to install the directory server

zfs create -o noatime data/slapd_master1

2. Install a new directory server instance

dsadm create -B /data/slapd_master1

3. Create a zfs file system to hold the directory server databases

zfs create data/slapd_master1/db

4. Start the directory server

dsadm start /data/slapd_master1

5. Set the directory server's db-env-path to point to /tmp/slapd_master1

dsconf set-server-prob db-env-path:/tmp/slapd_master1

6. Restart the directory server so the change will take effect

dsadm restart /data/slapd_master1

7. Remove the old cache files

rm /data/slapd_master1/db/__db.00?

8. Add a suffix to the directory server

dsconf create-suffix dc=example,dc=com

9. Import some entries

ldapadd -D cn=directory\ manager -f /tmp/some_sample_entries.ldif

At this point you should have a functioning directory server and could setup replication if you wanted to. Perform a few queries and verify everything functions ok. Now we will set the server into frozen mode, take a zfs snapshot, and place the server back into read-write mode.

Using frozen mode

1. Place the server into frozen mode

dsconf set-server-prop read-write-mode:frozen

2. Copy the dse.ldif file to the db directory so we will have a consistent configuration file to go with our database

cp /data/slapd_master1/config/dse.ldif /data/slapd_master1/db/dse.ldif

3. Take a ZFS snapshot (we will name the snapshot '20080516' since that is today's date )

zfs snapshot data/slapd_master1/db@20080516

4. Remove the dse.ldif copy in the db directory (we only want it there during the snapshot so we retain a copy of the config file that matches the db)

rm /data/slapd_master1/db/dse.ldif

5. Place the server back into read-write mode

dsconf set-server-prop read-write-mode:read-write

6. Use zfs list to view the snapshot

zfs list -t snapshot

You can now backup the snapshot using standard backup tools by accessing the

/data/slapd_master1/db/.zfs/snapshot/20080516

directory.

Using ZFS rollback to restore your data

In the event that something bad happens to your database, you can quickly use the zfs rollback command to get access to your earlier copy of data.

1. Use zfs list to view the snapshots available and pick the most recent one if there are several

zfs list -t snapshot

2. Stop the directory server

dsadm stop /data/slapd_master1

3. Use the zfs rollback command to restore to the snapshot

zfs rollback data/slapd_master1/db@20080516

4. Move the dse.ldif file we placed into the db directory back into the config directory

mv /data/slapd_master1/db/dse.ldif /data/slapd_master1/config/dse.ldif

5. Start the directory server

dsadm start /data/slapd_master1

You should now be back in business. Give these steps a spin in your test environment and see how easy it is.

Posted at 11:28PM May 16, 2008 by William Hathaway in General | Comments[0]

Monday Mar 31, 2008

Slicing and Dicing Directory Server Logs

One of the primary sources of information while troubleshooting LDAP problems is looking at the directory server's access logs, where all of the standard LDAP operations are logged. The access log contain a pair of lines for every operation, showing the operation (ADD/SRCH/DEL, etc) and the result. If you performed a search you might see something like the following lines get logged. The first line will be logged when the operations starts, the 2nd line will be logged once the operation is completed.



[01/Apr/2008:12:48:55 -0500] conn=3797 op=54 msgId=0 - SRCH base="ou=people,dc=example,dc=com" 
  scope=2 filter="(mobile=7175551212)" attrs=ALL
[01/Apr/2008:12:48:57 -0500] conn=3797 op=54 msgId=0 - RESULT err=0 tag=101 nentries=1 etime=2

(To read the full details about the access log format, check out the access log section in the DS reference manual.)

If you have a busy LDAP server, the access log line for the operation might be hundreds or thousands of lines before the RESULT line.

One of the common activities when looking at the logs is trying to find all the operations that match some criteria and then also find the matching RESULT lines. At many sites this is done manually by using something like:
grep $SOME_EXPRESSION logs/access

In our example, lets say we are trying to find all searches that looked for mobile=7175551212.
If we ran:

grep mobile=7175551212 logs/access

This would return the first line shown above, then the LDAP admin would need to look at the connection (conn=) and operation (op=) numbers and run a 2nd grep to get the matching RESULT line.

grep "conn=3797 op=54" logs/access

As you can tell, this would be really tedious, especially if we had 10 or 20 (or 1000!) searches or other operations that we wanted to find the matching RESULT lines for. This is where a script we wrote called search_logs comes into play You can pass a regular expression to search_logs and it will print out all the matching operation and RESULT lines whenever either of the lines matches the regular expression. This makes it a very simple process to answer queries such as:

what did all the searches for uid=foo look like ?
what operations took more than 1 second ?
what operations reported an error ?

Examples

Finding all operations that returned an error code of 4

./search_logs "err=4 " logs/access

[01/Apr/2008:12:51:34 -0500] conn=17 op=1975 msgId=1975 - SRCH base="ou=people,dc=example,dc=com" 
  scope=2  filter="(mobile=71715551234)" attrs=ALL
[01/Apr/2008:12:51:34 -0500] conn=17 op=1975 msgId=1975 - RESULT err=4 tag=101 nentries=1 etime=2

[01/Apr/2008:12:51:34 -0500] conn=20 op=195 msgId=195 - SRCH base="ou=people,dc=example,dc=com" scope=2 filter="(cn=smith)" attrs=ALL
[01/Apr/2008:12:51:34 -0500] conn=20 op=195 msgId=195 - RESULT err=4 tag=101 nentries=1 etime=

Finding all operations that took a second or more (using a regular expression for etime != 0)

./search_logs "etime=[^0]" logs/access

[01/Apr/2008:12:51:34 -0500] conn=17 op=1975 msgId=1975 - SRCH base="ou=people,dc=example,dc=com" 
  scope=2 filter="(mobile=71715551234)" attrs=ALL
[01/Apr/2008:12:51:36 -0500] conn=17 op=1975 msgId=1975 - RESULT err=4 tag=101 nentries=1 etime=2


[01/Apr/2008:12:51:34 -0500] conn=20 op=195 msgId=195 - SRCH base="ou=people,dc=example,dc=com" 
  scope=2 filter="(cn=smith)" attrs=ALL
[01/Apr/2008:12:51:35 -0500] conn=20 op=195 msgId=195 - RESULT err=0 tag=101 nentries=1 etime=1

[01/Apr/2008:12:51:34 -0500] conn=20 op=196 msgId=196 - MOD dn="uid=bob,ou=people,dc=example,dc=com"
[01/Apr/2008:12:51:65 -0500] conn=20 op=196 msgId=196 - RESULT err=0 tag=101 nentries=1 etime=4

As you can see, the search_logs program is very handy for performing ad-hoc queries against your directory server logs. You can also use a pipeline of search_log invocations to search for even more complex data. Here is an example searching for all modifications (MOD) that took more than 1 second

./search_logs " MOD " logs/access | ./search_logs etime=[^0].

Please give search_logs a try and send us feedback if you find it useful or have suggestions for improving it.

Posted at 07:52AM Mar 31, 2008 by William Hathaway in General | Comments[0]

Friday Mar 28, 2008

New version of Sun's Directory Server coming out soon

The next version (6.3) of Sun's Directory Server Enterprise Edition is scheduled to be released soon ( next week or two). I would highly recommend sites that are looking to deploy DSEE 6.x in the near future wait for the 6.3 release. The 6.3 release fixes a number of bugs, and some are fairly critical.

Posted at 09:42AM Mar 28, 2008 by William Hathaway in General | Comments[0]