williamhathaway.com

I’m working on an environment for a customer where we are using Directory Server Enterprise Edition (DSEE) and ZFS.   On the DSEE side, my co-worker Mitch and I were inspired by Ludovic’s post a while back about setting up command line completion for  dsconf and dpconf.   One small item Mitch noticed was that in the original examples, if you had a command name that didn’t contain a hypen (like dsconf import), it wouldn’t be completed (but command like dsconf get-server-prop would be).

Here is what Mitch came up with:

for cmd in dsconf dsadm dpconf dpadm; do
  complete -W "`$cmd --help | \
    perl -lane 'print $F[0] if \
      (/^The accepted values for SUBCMD/ .. \
       /^The accepted values for GLOBAL_OPTS/ \
       and not /^The /)'`" $cmd
done

For ZFS, check out this script on Big Admin by Mark Musante.
Mitch did a small update to the script which made the list of sub-commands on the fly to account for additions. Mitch’s updated version is available here.

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).