Turns out the LDAP groups issue was just a misconfigured nsswitch, fixed it and off it goes (“groups” instead of “group”—yay for typos).
The beast is setup to replicate the entire LDAP directory to the servers via slurpd. It’s not totally necessary, but does cut down on bandwidth usage (daemons contact their own local slapd rather than the master server) and reliability (the isc-dhcp+ldap patch we’re using makes dhcpd die silently if the LDAP connection is broken [e.g. when you restart slapd]—which sucks on a lot of levels, most noticibly when all the OSX boxes freeze as their dhcp leases come up for renewal, dhcpd having quit hours ago when you were trying to debug something else LDAP-related).
Originally, I had wanted to use the “polling” replication in OpenLDAP 2.2, where the local slapd periodically polls the master slapd for changes to bits of the DIT it’s interested in. The idea is that only those entries that will actually get used are replicated (everything can use the user data, dhcpd needs the DHCP data, PowerDNS needs the DNS data, postfix needs the relaying data, the future samba PDC needs the samba data, etc.). Unfortunately, sarge only had OpenLDAP 2.1, so I had to replicate the entire tree using slurpd across all the machines I wanted to replicate to. Of course, as soon as I had done this, sarge updates to OpenLDAP 2.2.
Oh well, at least I know replication with slurpd now…
James Cape 