Sun IDM now supports MySQL in production

For a long time, Sun has supported use of a MySQL repository for development purposes only with their Identity Manager product. After Sun purchased MySQL, it seemed like only a matter of time until they supported it in production, as Sean O'Neill detailed here.

Well finally it looks like there is a low-cost option for IDM repositories. With patch 137621-08, Sun has released support for MySQL in IDM 7.1 and patch 139010-04 does the same for IDM 8.0.

We're currently using Oracle and it sure would be nice to move to MySQL. The repository doesn't use any of the advanced functionality that Oracle provides and administering an Oracle database is a lot more work than MySQL. Actually most of the headaches are caused by Oracle's "creative" licensing practices.

#@%#$ user-customizable config files (AKA nss_ldap configuration)

I just finished configuring a RHEL system to pull its account information from a central LDAP directory. This shouldn't have been a big deal, I've done it many times before in a lot of different permutations. But this time, TLS certificate verification just would not work no matter what I did. I'd copied the certificate from the LDAP server, put in all of the possible configuration options possible and still nothing.

My tests worked with openssl:

# openssl s_client -connect hostname:636 -CAfile /etc/openldap/cacerts/hostname.domain.com.cert
...

...
Verify return code: 0 (ok)
---
DONE


but not ldapsearch or getent passwd:

# ldapsearch -v -D "uid=user,ou=services,dc=domain,dc=com" -w password -H "ldaps://hostname.domain.com:636" -b "dc=domain,dc=com" -s sub -Z -x "(uid=b*)"
ldap_initialize( ldaps://hostname.domain.com:636 )
ldap_start_tls: Can't contact LDAP server (-1)
ldap_bind: Can't contact LDAP server (-1)


After scratching my head for a while, fiddling with a bunch of configuration options (which I'll talk more about later), I finally noticed the mention of .ldaprc files in the ldap.conf(5) man page. These are user-customizable config files similar to .bashrc or .netrc that sit in a user's home directory and override the global configuration values. I check the /root/.ldaprc file and bingo!!! There's a reference to a non-existent certificate for the TLS_CERT setting. I comment this out and everything starts working. It turns out that a developer had been experimenting with client certificate authentication to LDAP and had left this setting in after their PoC was done.

On a side note, nss_ldap configuration is confusing even without random .ldaprc files getting in your way because you have to deal with both the /etc/ldap.conf and /etc/openldap/ldap.conf files and it is not at all clear what should go in which file. Many of the configuration options overlap, so you will often see duplicate settings in both files. A benefit of all the experimentation that I had to do to solve this problem was that I have a much clearer idea of what needs to be set in which file. For our setup (RHEL 4 client, SSL LDAP server on port 636, no anonymous LDAP access) I configured the following:

/etc/ldap.conf:

# hostname
host hostname.domain.com

# search base
base dc=domain,dc=com

# service user to perform searches
binddn uid=user,ou=services,dc=domain,dc=com

# service user password
bindpw password

# port
port 636

# passwd file configuration
nss_base_passwd dc=domain,dc=com?sub

# enable ssl
ssl on

# Verify the certificate
tls_checkpeer yes

# disable SASL
sasl_secprops maxssf=0
use_sasl off


/etc/openldap/ldap.conf: (only one line, but it's vital!)
# The location of the trusted certificate (or its CA certificate)
TLS_CACERT /etc/openldap/cacerts/watson.uoregon.edu.cert

Zimbra 5 memory usage tweaking

We support several small installations of Zimbra (less than 20 users) along with a couple of larger installations. Everyone loves the features that it provides and the price tag for the ZCS edition. In the past six months we've upgraded several clients from Zimbra 4 to Zimbra 5. In most of the cases, the driving factor was support for Firefox 3 and/or Safari 3.

One thing that has come up in the small Zimbra upgrades is a big increase in memory usage with the default settings. The default Zimbra settings are appropriate for installations supporting a couple of hundred users, but are overkill for for small user bases. Below is a set of the steps that we've taken with the small installations:

* Reduce the amount of memory that the Java mailbox process and the MySQL server can use. By default these are 30% and 40% respectively. We've been using 25% for both and seen no problems so far.

zmlocalconfig -e mailboxd_java_heap_memory_percent=25
zmlocalconfig -e mysql_memory_percent=25

* Reduce the number of amavisd processes that are started by default. Amavis is a mail content checker that is used by the anti-spam and anti-virus components. By default 10 processes start up, each taking up about 45 MB of memory. We've reduced this to two without seeing any ill effects.

Edit $ZIMBRA_HOME/conf/amavisd.conf.in and change this line:
$max_servers = 10;
to:
$max_servers = 2;

* If you are really strapped for memory, you can also disable anti-virus, but make sure you have some other method of virus filtering enabled first! Whether it's on a mail filtering service that sits in front of your mail server or on the desktop, you need some sort of protection.