On 16/07/13 21:19, Quanah Gibson-Mount wrote:
--On Tuesday, July 16, 2013 6:53 PM +0100 Adrian Bridgett <adrian@smop.co.uk> wrote:On 16/07/13 18:36, Quanah Gibson-Mount wrote:are the olcAccess rules identical between the two? When you bind via ldapi, if you examine the logs at 256, is the search being mapped to the same DN on both master and replicas?Hi Quanah, yes, the olcAccess is identical (I've even diffed them). I forgot to mention the version - it's 2.4.28-1.1ubuntu5, the debug logs look like this on the slave:Ok. I assume you get back valid data when using the rootdn for that DB on the replica?
If I run "slapcat" on the replica I see: dn: dc=example,dc=com entryUUID: 90b0b784-ad62-1031-85c2-c9aecd89570c creatorsName: cn=admin,dc=example,dc=com createTimestamp: 20121018112737Z entryCSN: 20121018112737.972264Z#000000#000#000000 modifiersName: cn=admin,dc=example,dc=com modifyTimestamp: 20121018112737Z objectClass: top objectClass: glue structuralObjectClass: glue contextCSN: 20130716160414.209246Z#000000#000#000000 ... (rest of the entries)Ah - the olcRootPw wasn't set properly on the replicas, fixed that now, but still no joy via either EXTERNAL or LDAPS auth - I'm authenticated just fine but can't see that top level object. Hmmm, maybe I need to find the correct debug args to show up the differences between the two systems.
I would note that this ACL:
olcAccess: {2}to dn.base="" by * read
does not belong in this DB. It belongs in the frontend DB. Here's my
olcAccess statements for my frontend DB:
Thanks Quanah - I've fixed that, our frontend was okay.