This has been driving me up the wall and I wondered if someone could point out the bit I'm missing - the desk is getting badly damaged by my head bashing it :-)
On our master server I can query the rootdb no problem, but I can't do this on the slaves - this applies whether I use external or ldaps authentication. I've turned on access and search filter debugging and I can't see any rejections. I'm trying to query contextCSN to ensure that the slave is in sync. "slapcat" works, but seems an ugly hack. I can query all the children - just not the root.
The config is the same (ish) on both - here's the slave: dn: olcDatabase={1}hdb objectClass: olcDatabaseConfig objectClass: olcHdbConfig olcDatabase: {1}hdb olcDbDirectory: /var/lib/ldap olcSuffix: dc=example,dc=com olcLastMod: TRUE olcRootDN: cn=admin,dc=example,dc=com olcRootPW:: ....... olcDbCheckpoint: 512 30 olcDbConfig: {0}set_cachesize 0 2097152 0 olcDbConfig: {1}set_lk_max_objects 1500 olcDbConfig: {2}set_lk_max_locks 1500 olcDbConfig: {3}set_lk_max_lockers 1500 structuralObjectClass: olcHdbConfig entryUUID: 07f3fede-c201-1031-8b17-f3837148ab05 creatorsName: cn=config createTimestamp: 20121113171221Z olcSyncrepl: {0}rid=000 provider=ldap://ldap.example.com type=refreshandPers ist interval=00:00:00:60 retry="60 10 300 +" timelimit=10 searchbase="dc=example ,dc=com" binddn="cn=admin,dc=example,dc=com" bindmethod=simple credent ials=..... starttls=critical tls_reqcert=demand attrs="*,+" olcUpdateRef: ldap://ldap.example.com olcDbIndex: entryCSN eq olcDbIndex: entryUUID eq olcDbIndex: objectClass eq olcDbIndex: cn,sn pres,eq,sub olcDbIndex: uid,uidNumber,gidNumber,memberOf,sudoUser,memberUid pres,eq olcAccess: {0}to attrs=userPassword,shadowLastChange by self write by anonymou s auth by dn="cn=admin,dc=example,dc=com" manage by group.exact="cn=admins, ou=Group,dc=example,dc=com" manage by dn.exact=gidNumber=0+uidNumber=0,cn=p eercred,cn=external,cn=auth manage by * none olcAccess: {1}to attrs=SambaLMPassword,SambaNTPassword by self write by dn="cn =freenas-auth,ou=services,dc=example,dc=com" read by dn="cn=admin,dc=example ,dc=com" manage by group.exact="cn=admins,ou=Group,dc=example,dc=com" ma nage by dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth mana ge by * none olcAccess: {2}to dn.base="" by * read olcAccess: {3}to * by self write by dn="cn=admin,dc=example,dc=com" manage b y group.exact="cn=admins,ou=Group,dc=example,dc=com" manage by dn.exact=gid Number=0+uidNumber=0,cn=peercred,cn=external,cn=auth manage by * read olcAccess: {4}to dn.base="dc=example,dc=com" by * read
On the slave: ldapsearch -Y EXTERNAL -H ldapi:/// -b dc=example,dc=com -s base -Q# extended LDIF # search result search: 2 result: 0 Success # numResponses: 1
On the master: ldapsearch -Y EXTERNAL -H ldapi:/// -b dc=example,dc=com -s base dn: dc=example,dc=com objectClass: top objectClass: dcObject objectClass: organization o: example.com dc: example # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1
--On Tuesday, July 16, 2013 6:12 PM +0100 Adrian Bridgett adrian@smop.co.uk wrote:
This has been driving me up the wall and I wondered if someone could point out the bit I'm missing - the desk is getting badly damaged by my head bashing it :-)
On our master server I can query the rootdb no problem, but I can't do this on the slaves - this applies whether I use external or ldaps authentication. I've turned on access and search filter debugging and I can't see any rejections. I'm trying to query contextCSN to ensure that the slave is in sync. "slapcat" works, but seems an ugly hack. I can query all the children - just not the root.
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?
--Quanah
--
Quanah Gibson-Mount Lead Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration
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:
51e58768 conn=1002 fd=20 ACCEPT from PATH=/var/run/slapd/ldapi (PATH=/var/run/slapd/ldapi) 51e58768 conn=1002 op=0 BIND dn="" method=163 51e58768 conn=1002 op=0 BIND authcid="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" authzid="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" 51e58768 conn=1002 op=0 BIND dn="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" mech=EXTERNAL sasl_ssf=0 ssf=71 51e58768 conn=1002 op=0 RESULT tag=97 err=0 text= 51e58768 conn=1002 op=1 SRCH base="dc=example,dc=com" scope=0 deref=0 filter="(objectClass=*)" 51e58768 conn=1002 op=1 SEARCH RESULT tag=101 err=0 nentries=0 text= 51e58768 conn=1002 op=2 UNBIND 51e58768 conn=1002 fd=20 closed
and this on the master: 51e5881d conn=1000 fd=16 ACCEPT from PATH=/var/run/slapd/ldapi (PATH=/var/run/slapd/ldapi) 51e5881d conn=1000 op=0 BIND dn="" method=163 51e5881d conn=1000 op=0 BIND authcid="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" authzid="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" 51e5881d conn=1000 op=0 BIND dn="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" mech=EXTERNAL sasl_ssf=0 ssf=71 51e5881d conn=1000 op=0 RESULT tag=97 err=0 text= 51e5881d conn=1000 op=1 SRCH base="dc=example,dc=com" scope=0 deref=0 filter="(objectClass=*)" 51e5881d conn=1000 op=1 SEARCH RESULT tag=101 err=0 nentries=1 text= 51e5881d conn=1000 op=2 UNBIND 51e5881d conn=1000 fd=16 closed
Thanks,
Adrian
--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?
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:
dn: olcDatabase={-1}frontend olcAccess: {0}to * by dn.children="cn=admins,cn=zimbra" write by * +0 break olcAccess: {1}to dn.base="" by * read olcAccess: {2}to dn.base="cn=subschema" by * read
--Quanah
--
Quanah Gibson-Mount Lead Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration
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.
--On Wednesday, July 17, 2013 5:28 PM +0100 Adrian Bridgett adrian@smop.co.uk wrote:
dn: dc=example,dc=com objectClass: glue structuralObjectClass: glue contextCSN: 20130716160414.209246Z#000000#000#000000
Why is this a glued object? Is it a glued object on your master?
--Quanah
--
Quanah Gibson-Mount Lead Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration
Aha! I hadn't noticed that, I must be blind. I've just read up about glue objects, not quite sure what happened there, I've removed the DB, restarted and it's resynced nicely and everything now works!
If you are ever around in London, give me a shout - I definitely owe you a few drinks :-)
Adrian (sanity restored)
On 17/07/13 18:07, Quanah Gibson-Mount wrote:
--On Wednesday, July 17, 2013 5:28 PM +0100 Adrian Bridgett adrian@smop.co.uk wrote:
dn: dc=example,dc=com objectClass: glue structuralObjectClass: glue contextCSN: 20130716160414.209246Z#000000#000#000000
Why is this a glued object? Is it a glued object on your master?
--Quanah
--
Quanah Gibson-Mount Lead Engineer Zimbra, Inc
Zimbra :: the leader in open source messaging and collaboration
openldap-technical@openldap.org
-
Adrian Bridgett -
Quanah Gibson-Mount