Can't access auto.master directory entries in console
On 01/05/2011 08:56 AM, Orion Poplawski wrote:
> On 01/04/2011 08:19 PM, Marc Sauton wrote: >> On Tue, 2011-01-04 at 17:04 -0700, Orion Poplawski wrote: >>> On 01/04/2011 02:40 PM, Rich Megginson wrote: >>>> On 01/04/2011 02:30 PM, Orion Poplawski wrote: >>>>> In 389-console, my auto.master folder entry does not appear on the left pane >>>>> so I can't edit the entries in it. It does appear as a folder icon on the >>>>> right. Any ideas why this would be? File a bug? >>>> I'm assuming you mean in the directory browser. First step would be to run the >>>> console using 389-console -D 9 -f console.log then post the console.log (first >>>> obscure any sensitive information). Also check the directory server access log >>>> to see what searches it is performing. >>> This appears to be the relevant searches. Not that it does not appear to be >>> searching inside "ou=auto.master,dc=cora,dc=nwra,dc=com". >>> >>> [04/Jan/2011:16:56:35 -0700] conn=81117 op=28 SRCH >>> base="dc=cora,dc=nwra,dc=com" scope=1 >>> filter="(|(&(numSubordinates=*)(numSubordinates>=1 )(|(objectClass=*)(objectClass=ldapsubentry)))(obj ectClass=organization)(objectClass=organizationalU nit)(objectClass=netscapeServer)(objectClass=netsc apeResource)(objectClass=domain))" >>> attrs="distinguishedName" >>> [04/Jan/2011:16:56:37 -0700] conn=81117 op=32 SRCH base="cn=MCC dc=cora >>> dc=nwra dc=com,cn=userRoot,cn=ldbm database,cn=plugins,cn=config" scope=0 >>> filter="(|(objectClass=*)(objectClass=ldapsubentry ))" attrs="distinguishedName" >>> [04/Jan/2011:16:56:37 -0700] conn=81117 op=33 SRCH >>> base="dc=cora,dc=nwra,dc=com" scope=0 >>> filter="(|(objectClass=*)(objectClass=ldapsubentry ))" attrs="objectClass >>> numSubordinates ref aci" >>> [04/Jan/2011:16:56:37 -0700] conn=81117 op=34 SRCH >>> base="dc=cora,dc=nwra,dc=com" scope=1 >>> filter="(|(&(numSubordinates=*)(numSubordinates>=1 )(|(objectClass=*)(objectClass=ldapsubentry)))(obj ectClass=organization)(objectClass=organizationalU nit)(objectClass=netscapeServer)(objectClass=netsc apeResource)(objectClass=domain))" >>> attrs="objectClass numSubordinates ref aci" >>> [04/Jan/2011:16:56:37 -0700] conn=81117 op=35 SRCH >>> base="ou=auto.home,dc=cora,dc=nwra,dc=com" scope=1 >>> filter="(|(&(numSubordinates=*)(numSubordinates>=1 )(|(objectClass=*)(objectClass=ldapsubentry)))(obj ectClass=organization)(objectClass=organizationalU nit)(objectClass=netscapeServer)(objectClass=netsc apeResource)(objectClass=domain))" >>> attrs="distinguishedName" >> You may want to look for the matching log entry indicating the RESULT of >> this operation. >> It could be also good to know what was the BIND at the begining of the >> connection, may be you have some aci in use. > This appears to be the search that gets the contents of the > dc=cora,dc=nwra,dc=com directory that are themselves "folders": > > [04/Jan/2011:16:56:37 -0700] conn=81117 op=34 SRCH > base="dc=cora,dc=nwra,dc=com" scope=1 > filter="(|(&(numSubordinates=*)(numSubordinates>=1 )(|(objectClass=*)(objectClass=ldapsubentry)))(obj ectClass=organization)(objectClass=organizationalU nit)(objectClass=netscapeServer)(objectClass=netsc apeResource)(objectClass=domain))" > attrs="objectClass numSubordinates ref aci" > [04/Jan/2011:16:56:37 -0700] conn=81117 op=34 RESULT err=0 tag=101 nentries=6 > etime=0 notes=U > > But it does not return auto.master or auto.nfs (which I see now also does not > show up in the folder list). > > Now, there's nothing different between say auto.home and auto.nfs at the top > level: > > # auto.home, cora.nwra.com > dn: ou=auto.home,dc=cora,dc=nwra,dc=com > ou: auto.home > objectClass: top > objectClass: automountMap > > # auto.nfs, cora.nwra.com > dn: ou=auto.nfs,dc=cora,dc=nwra,dc=com > ou: auto.nfs > objectClass: top > objectClass: automountMap > > Entries have the same properties as well. > > # ftp, auto.home, cora.nwra.com > dn: cn=ftp,ou=auto.home,dc=cora,dc=nwra,dc=com > objectClass: automount > objectClass: top > cn: ftp > automountInformation: hawk:/export/ftp > > # local, auto.nfs, cora.nwra.com > dn: cn=local,ou=auto.nfs,dc=cora,dc=nwra,dc=com > objectClass: automount > objectClass: top > cn: local > automountInformation: earth:/export/local > > > If I remove the (numSubordinates>=1) clause then I get all the entries. It > appears that the server isn't calculating that value correctly. Is there a > way to check/repair? Try doing the ldapsearch you used to test, but add numSubordinates to the list of attributes to return: ldapsearch .... "big filter with (numSubordinates>=1) clause removed" * numSubordinates > -- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users |
Can't access auto.master directory entries in console
On 01/05/2011 09:06 AM, Rich Megginson wrote:
> Try doing the ldapsearch you used to test, but add numSubordinates to the list > of attributes to return: > > ldapsearch .... "big filter with (numSubordinates>=1) clause removed" * > numSubordinates Okay, something is wrong here. These results appear correct: [root@earth slapd-cora]# ldapsearch -Z -x -b "dc=cora,dc=nwra,dc=com" -s one numSubordinates # extended LDIF # # LDAPv3 # base <dc=cora,dc=nwra,dc=com> with scope oneLevel # filter: (objectclass=*) # requesting: numSubordinates # # nis, cora.nwra.com dn: ou=nis,dc=cora,dc=nwra,dc=com numSubordinates: 0 # auto.master, cora.nwra.com dn: ou=auto.master,dc=cora,dc=nwra,dc=com numSubordinates: 4 # auto.home, cora.nwra.com dn: ou=auto.home,dc=cora,dc=nwra,dc=com numSubordinates: 88 # auto.data, cora.nwra.com dn: ou=auto.data,dc=cora,dc=nwra,dc=com numSubordinates: 21 # auto.nfs, cora.nwra.com dn: ou=auto.nfs,dc=cora,dc=nwra,dc=com numSubordinates: 3 # auto.datag, cora.nwra.com dn: ou=auto.datag,dc=cora,dc=nwra,dc=com numSubordinates: 21 # auto.data4, cora.nwra.com dn: ou=auto.data4,dc=cora,dc=nwra,dc=com numSubordinates: 21 # auto.data4g, cora.nwra.com dn: ou=auto.data4g,dc=cora,dc=nwra,dc=com numSubordinates: 21 # search result search: 3 result: 0 Success # numResponses: 9 # numEntries: 8 But this is wrong: [root@earth slapd-cora]# ldapsearch -Z -x -b "dc=cora,dc=nwra,dc=com" -s one 'numSubordinates>=1' numSubordinates # extended LDIF # # LDAPv3 # base <dc=cora,dc=nwra,dc=com> with scope oneLevel # filter: numSubordinates>=1 # requesting: numSubordinates # # auto.home, cora.nwra.com dn: ou=auto.home,dc=cora,dc=nwra,dc=com numSubordinates: 88 # auto.data, cora.nwra.com dn: ou=auto.data,dc=cora,dc=nwra,dc=com numSubordinates: 21 # auto.datag, cora.nwra.com dn: ou=auto.datag,dc=cora,dc=nwra,dc=com numSubordinates: 21 # auto.data4, cora.nwra.com dn: ou=auto.data4,dc=cora,dc=nwra,dc=com numSubordinates: 21 # auto.data4g, cora.nwra.com dn: ou=auto.data4g,dc=cora,dc=nwra,dc=com numSubordinates: 21 # search result search: 3 result: 0 Success # numResponses: 6 # numEntries: 5 This works: ldapsearch -Z -x -b "dc=cora,dc=nwra,dc=com" -s one 'numSubordinates>0' numSubordinates # numResponses: 9 # numEntries: 8 I also tried >=2 through >=4 but none returned auto.master. >=22 successfully eliminated the auto.data* entries. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA Division FAX: 303-415-9702 3380 Mitchell Lane orion@cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com -- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users |
| All times are GMT. The time now is 03:53 AM. |
VBulletin, Copyright ©2000 - 2013, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.