williamhathaway.com

I’ve been following the (sometimes controversial) OpenDS project for a while now.  This morning I woke up a bit earlier than usual so I decided to try out the latest build.

It is very straightforward to use, and took about two minutes to download, extract, setup, and start running.  I needed a resonable number of entries to test with, so I created a million synthetic users (via makeldif) and then kicked off the import process (which ran at about 3-4k a second).  After the import finished, I ran a modrate job and forgot about it.  When I returned home this evening, I saw in an open SSH session that it was still crunching away, averaging about 7,000 modifications a second.  I accidentally performed a 13 hour stress test and it held up just fine (after approximately 327 million mods!).

This was on a 2 processor quad-core Sun x4150 running Solaris 10.  No settings were changed from the default.

./modrate  -p 1389 -D cn=directory\ manager -w password -b uid=%d,ou=people,dc=example,dc=com -M ‘description:60:[a-z]‘ -r 1000000 -K -t 16

….
(this is the output I came home to)
Avg r=1955.44/thr (6257.40/sec), total= 31287
Avg r=2005.94/thr (6419.00/sec), total= 32095
Avg r=2035.00/thr (6512.00/sec), total= 32560
Avg r=2040.62/thr (6530.00/sec), total= 32650
Avg r=2013.12/thr (6442.00/sec), total= 32210
Avg r=2301.25/thr (7364.00/sec), total= 36820
Avg r=2397.00/thr (7670.40/sec), total= 38352
Avg r=2443.69/thr (7819.80/sec), total= 39099
Avg r=2748.69/thr (8795.80/sec), total= 43979
Avg r=2899.12/thr (9277.20/sec), total= 46386
Avg r=2475.25/thr (7920.80/sec), total= 39604
Avg r=2333.06/thr (7465.80/sec), total= 37329
Avg r=2673.19/thr (8554.20/sec), total= 42771
Avg r=2652.88/thr (8489.20/sec), total= 42446
Avg r=2371.06/thr (7587.40/sec), total= 37937
Avg r=2065.69/thr (6610.20/sec), total= 33051
Avg r=2228.38/thr (7130.80/sec), total= 35654
Avg r=2326.81/thr (7445.80/sec), total= 37229
^C

Not shabby at all!

I was working with dsadm on a Sun Directory Server 6.2 install yesterday and ran into a snag with using the cert-export/cert-import functionality. Here are my notes:

1) When using the dsadm cert-export command, you provide a cert alias name, but it actually exports all your certificates.

2) When using dsadm cert-import, I had a problem where it re-imported the serverCert and caCert but the trust permissions on caCert weren’t correct. This caused outbound SSL connections to fail since it wasn’t able to validate the other server’s certificate. (this scenario was for an in-house certificate authority, so it may not apply for people using certificates issued by Verisign and the like)

You can read about the NSS trust flags at the certutil man page.

Steps to show/fix the caCert trust issue (using the certutil located in /usr/sfw/bin on Solaris 10)

——————————————————————————————————-

# look at the trust settings for caCert, which should be C,,

/var/directory/master1/alias> certutil -L -d . -P slapd-
defaultCert CTu,u,u
serverCert u,u,u
caCert c,c,

# modify the trust settings to the right values

/var/directory/master1/alias> certutil -M -n caCert -t C,, -d . -P slapd-

# list the trust settings again, now they are correct

/var/directory/master1/alias> certutil -L -d . -P slapd-
defaultCert CTu,u,u
serverCert u,u,u
caCert C,,

This is basically a rehash of an email conversation I had on a mailing list with someone who was trying to get ldapsearch and the Solaris LDAP namesevice commands to communicate with a DS 6 instance over SSL.

Problem: The self-signed certs generated by DS6 have a certificate name that doesn’t validate properly to tools like the Solaris 10 ldapsearch command or ldap_cachemgr when used in SSL mode.

Background: Any SSL based software that wants to verify certificates will compare the subject/cn of the certificate against the hostname of the server.
The default subject of the DS6 auto-generated certs looks something like this:

CN=$SHORTNAME,CN=636,CN=Directory Server,O=Sun Microsystems

Solution: In order to work with software that validates that the hostname matches the subject, we need to remove the existing certificate and create a new certificate with a subject. that matches the hostname. The steps below will generate a self-signed cert with a proper subject :

# dsadm stop $PATH_TO_YOUR_INSTANCE

# dsadm remove-cert $PATH_TO_YOUR_INSTANCE defaultCert
(will see error msg: You are going to remove the certificate used by the instance. You will not be able to restart the instance.)

# dsadm add-selfsign-cert -S cn=$YOUR_FQDN_HERE \

         $PATH_TO_YOUR_INSTANCE  defaultCert

# dsadm start $PATH_TO_YOUR_INSTANCE

Once you have done this, you will still need to export the certificate and import it into your certificate database (typically cert7.db/cert8.db for NSS based commands or a java keystore).