3:30 p.m.
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?
--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA/CoRA Division FAX: 303-415-9702
3380 Mitchell Lane orion(a)cora.nwra.com
Boulder, CO 80301 http://www.cora.nwra.com
3:40 p.m.
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.
6:04 p.m.
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)))(objectClass=organization)(objectClass=organizationalUnit)(objectClass=netscapeServer)(objectClass=netscapeResource)(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)))(objectClass=organization)(objectClass=organizationalUnit)(objectClass=netscapeServer)(objectClass=netscapeResource)(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)))(objectClass=organization)(objectClass=organizationalUnit)(objectClass=netscapeServer)(objectClass=netscapeResource)(objectClass=domain))"
attrs="distinguishedName"
[04/Jan/2011:16:56:37 -0700] conn=81117 op=36 SRCH
base="ou=auto.data,dc=cora,dc=nwra,dc=com" scope=1
filter="(|(&(numSubordinates=*)(numSubordinates>=1)(|(objectClass=*)(objectClass=ldapsubentry)))(objectClass=organization)(objectClass=organizationalUnit)(objectClass=netscapeServer)(objectClass=netscapeResource)(objectClass=domain))"
attrs="distinguishedName"
[04/Jan/2011:16:56:37 -0700] conn=81117 op=37 SRCH
base="ou=auto.datag,dc=cora,dc=nwra,dc=com" scope=1
filter="(|(&(numSubordinates=*)(numSubordinates>=1)(|(objectClass=*)(objectClass=ldapsubentry)))(objectClass=organization)(objectClass=organizationalUnit)(objectClass=netscapeServer)(objectClass=netscapeResource)(objectClass=domain))"
attrs="distinguishedName"
[04/Jan/2011:16:56:37 -0700] conn=81117 op=38 SRCH
base="ou=auto.data4,dc=cora,dc=nwra,dc=com" scope=1
filter="(|(&(numSubordinates=*)(numSubordinates>=1)(|(objectClass=*)(objectClass=ldapsubentry)))(objectClass=organization)(objectClass=organizationalUnit)(objectClass=netscapeServer)(objectClass=netscapeResource)(objectClass=domain))"
attrs="distinguishedName"
[04/Jan/2011:16:56:37 -0700] conn=81117 op=39 SRCH
base="ou=auto.data4g,dc=cora,dc=nwra,dc=com" scope=1
filter="(|(&(numSubordinates=*)(numSubordinates>=1)(|(objectClass=*)(objectClass=ldapsubentry)))(objectClass=organization)(objectClass=organizationalUnit)(objectClass=netscapeServer)(objectClass=netscapeResource)(objectClass=domain))"
attrs="distinguishedName"
Relevant console.log when I open the dc=cora folder appears to be:
CreateVLVIndex.indexStatus(): dc=cora,dc=nwra,dc=com
CreateVLVIndex.getBackendConfigRoot(): backend config root for
dc=cora,dc=nwra,dc=com is cn=MCC dc=cora dc=nwra dc=com, cn=userRoot, cn=ldbm
database, cn=plugins, cn=config
--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA/CoRA Division FAX: 303-415-9702
3380 Mitchell Lane orion(a)cora.nwra.com
Boulder, CO 80301 http://www.cora.nwra.com
9:19 p.m.
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)))(objectClass=organization)(objectClass=organizationalUnit)(objectClass=netscapeServer)(objectClass=netscapeResource)(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)))(objectClass=organization)(objectClass=organizationalUnit)(objectClass=netscapeServer)(objectClass=netscapeResource)(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)))(objectClass=organization)(objectClass=organizationalUnit)(objectClass=netscapeServer)(objectClass=netscapeResource)(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.
[04/Jan/2011:16:56:37 -0700] conn=81117 op=36 SRCH
base="ou=auto.data,dc=cora,dc=nwra,dc=com" scope=1
filter="(|(&(numSubordinates=*)(numSubordinates>=1)(|(objectClass=*)(objectClass=ldapsubentry)))(objectClass=organization)(objectClass=organizationalUnit)(objectClass=netscapeServer)(objectClass=netscapeResource)(objectClass=domain))"
attrs="distinguishedName"
[04/Jan/2011:16:56:37 -0700] conn=81117 op=37 SRCH
base="ou=auto.datag,dc=cora,dc=nwra,dc=com" scope=1
filter="(|(&(numSubordinates=*)(numSubordinates>=1)(|(objectClass=*)(objectClass=ldapsubentry)))(objectClass=organization)(objectClass=organizationalUnit)(objectClass=netscapeServer)(objectClass=netscapeResource)(objectClass=domain))"
attrs="distinguishedName"
[04/Jan/2011:16:56:37 -0700] conn=81117 op=38 SRCH
base="ou=auto.data4,dc=cora,dc=nwra,dc=com" scope=1
filter="(|(&(numSubordinates=*)(numSubordinates>=1)(|(objectClass=*)(objectClass=ldapsubentry)))(objectClass=organization)(objectClass=organizationalUnit)(objectClass=netscapeServer)(objectClass=netscapeResource)(objectClass=domain))"
attrs="distinguishedName"
[04/Jan/2011:16:56:37 -0700] conn=81117 op=39 SRCH
base="ou=auto.data4g,dc=cora,dc=nwra,dc=com" scope=1
filter="(|(&(numSubordinates=*)(numSubordinates>=1)(|(objectClass=*)(objectClass=ldapsubentry)))(objectClass=organization)(objectClass=organizationalUnit)(objectClass=netscapeServer)(objectClass=netscapeResource)(objectClass=domain))"
attrs="distinguishedName"
Relevant console.log when I open the dc=cora folder appears to be:
CreateVLVIndex.indexStatus(): dc=cora,dc=nwra,dc=com
CreateVLVIndex.getBackendConfigRoot(): backend config root for
dc=cora,dc=nwra,dc=com is cn=MCC dc=cora dc=nwra dc=com, cn=userRoot, cn=ldbm
database, cn=plugins, cn=config
--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA/CoRA Division FAX: 303-415-9702
3380 Mitchell Lane orion(a)cora.nwra.com
Boulder, CO 80301 http://www.cora.nwra.com
--
389 users mailing list
389-users(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users
9:56 a.m.
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)))(objectClass=organization)(objectClass=organizationalUnit)(objectClass=netscapeServer)(objectClass=netscapeResource)(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)))(objectClass=organization)(objectClass=organizationalUnit)(objectClass=netscapeServer)(objectClass=netscapeResource)(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)))(objectClass=organization)(objectClass=organizationalUnit)(objectClass=netscapeServer)(objectClass=netscapeResource)(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)))(objectClass=organization)(objectClass=organizationalUnit)(objectClass=netscapeServer)(objectClass=netscapeResource)(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?
--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA/CoRA Division FAX: 303-415-9702
3380 Mitchell Lane orion(a)cora.nwra.com
Boulder, CO 80301 http://www.cora.nwra.com
10:06 a.m.
New subject: 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)))(objectClass=organization)(objectClass=organizationalUnit)(objectClass=netscapeServer)(objectClass=netscapeResource)(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)))(objectClass=organization)(objectClass=organizationalUnit)(objectClass=netscapeServer)(objectClass=netscapeResource)(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)))(objectClass=organization)(objectClass=organizationalUnit)(objectClass=netscapeServer)(objectClass=netscapeResource)(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)))(objectClass=organization)(objectClass=organizationalUnit)(objectClass=netscapeServer)(objectClass=netscapeResource)(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
10:16 a.m.
New subject: 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(a)cora.nwra.com
Boulder, CO 80301 http://www.cora.nwra.com
10:55 a.m.
New subject: Can't access auto.master directory entries in console
On 01/05/2011 09:16 AM, Orion Poplawski wrote:
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:
Looks like a problem
with the numSubordinates index - it looks like it
is only indexed for presence - try adding an equality index for
numSubordinates and reindex.
I don't know when or why this changed - looks like a regression.
[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.
12:39 p.m.
New subject: Can't access auto.master directory entries in console
On 01/05/2011 09:55 AM, Rich Megginson wrote:
On 01/05/2011 09:16 AM, Orion Poplawski wrote:
> 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:
Looks like a problem with the numSubordinates index - it looks like it is only
indexed for presence - try adding an equality index for numSubordinates and
reindex.
I don't know when or why this changed - looks like a regression.
I added an index for equality by adding nsIndexTypes: eq to:
cn=numsubordinates,cn=index,cn=userRoot,cn=ldbm database,cn=plugins,dn=config
cn=numsubordinates,cn=index,cn=NetscapeRoot,cn=ldbm database,cn=plugins,dn=config
cn=numsubordinates,cn=default indexes,cn=config,cn=ldbm
database,cn=plugins,dn=config
I triggered an index rebuild by adding:
dn: cn=db2index_2011_1_5_11_21_50, cn=index, cn=tasks, cn=config
changetype: add
objectclass: top
objectclass: extensibleObject
cn: db2index_2011_1_5_11_21_50
nsInstance: userRoot
nsIndexAttribute: numsubordinates:eq
Saw in the error log:
[05/Jan/2011:11:30:26 -0700] - userRoot: Indexing attribute: numsubordinates
[05/Jan/2011:11:30:27 -0700] - userRoot: Finished indexing.
But now my numSubordinates>=1 search comes up empty. Interestingly,
numSubordinates>4 doesn't work either, but in this case it returns all, even
those with numSubordinates <= 4.
Restarting the slapd process didn't help.
Filed https://bugzilla.redhat.com/show_bug.cgi?id=667488
--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA/CoRA Division FAX: 303-415-9702
3380 Mitchell Lane orion(a)cora.nwra.com
Boulder, CO 80301 http://www.cora.nwra.com
2:46 p.m.
New subject: Can't access auto.master directory entries in console
On 01/05/2011 11:39 AM, Orion Poplawski wrote:
On 01/05/2011 09:55 AM, Rich Megginson wrote:
> On 01/05/2011 09:16 AM, Orion Poplawski wrote:
>> 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:
> Looks like a problem with the numSubordinates index - it looks like
> it is only
> indexed for presence - try adding an equality index for
> numSubordinates and
> reindex.
>
> I don't know when or why this changed - looks like a regression.
I added an index for equality by adding nsIndexTypes: eq to:
cn=numsubordinates,cn=index,cn=userRoot,cn=ldbm
database,cn=plugins,dn=config
cn=numsubordinates,cn=index,cn=NetscapeRoot,cn=ldbm
database,cn=plugins,dn=config
cn=numsubordinates,cn=default indexes,cn=config,cn=ldbm
database,cn=plugins,dn=config
I triggered an index rebuild by adding:
dn: cn=db2index_2011_1_5_11_21_50, cn=index, cn=tasks, cn=config
changetype: add
objectclass: top
objectclass: extensibleObject
cn: db2index_2011_1_5_11_21_50
nsInstance: userRoot
nsIndexAttribute: numsubordinates:eq
Saw in the error log:
[05/Jan/2011:11:30:26 -0700] - userRoot: Indexing attribute:
numsubordinates
[05/Jan/2011:11:30:27 -0700] - userRoot: Finished indexing.
But now my numSubordinates>=1 search comes up empty. Interestingly,
numSubordinates>4 doesn't work either, but in this case it returns
all, even those with numSubordinates <= 4.
Restarting the slapd process didn't help.
Filed https://bugzilla.redhat.com/show_bug.cgi?id=667488
What does dbscan say?
dbscan -f /var/lib/dirsrv/slapd-instancename/db/userRoot/numsubordinates.db4
?
3:10 p.m.
New subject: Can't access auto.master directory entries in console
I might have missed something in the discussion, but even if
numsubordinates is indexed only with presence:
# dbscan -f numsubordinates.db4 -n -r
+ 3
1 3 4
the range search should return the expected result:
$ ldapsearch [...] -b "dc=example,dc=com"
"*(&(numsubordinates=*)(numsubordinates>=1))*" numsubordinates
entryid
dn: dc=example,dc=com
numsubordinates: 4
entryid: 1
dn: ou=Groups,dc=example,dc=com
numsubordinates: 4
entryid: 3
dn: ou=People,dc=example,dc=com
numsubordinates: 2
entryid: 4
Rich Megginson wrote:
On 01/05/2011 11:39 AM, Orion Poplawski wrote:
> On 01/05/2011 09:55 AM, Rich Megginson wrote:
>> On 01/05/2011 09:16 AM, Orion Poplawski wrote:
>>> 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:
>> Looks like a problem with the numSubordinates index - it looks like
>> it is only
>> indexed for presence - try adding an equality index for
>> numSubordinates and
>> reindex.
>>
>> I don't know when or why this changed - looks like a regression.
> I added an index for equality by adding nsIndexTypes: eq to:
>
> cn=numsubordinates,cn=index,cn=userRoot,cn=ldbm
> database,cn=plugins,dn=config
> cn=numsubordinates,cn=index,cn=NetscapeRoot,cn=ldbm
> database,cn=plugins,dn=config
> cn=numsubordinates,cn=default indexes,cn=config,cn=ldbm
> database,cn=plugins,dn=config
>
> I triggered an index rebuild by adding:
>
>
> dn: cn=db2index_2011_1_5_11_21_50, cn=index, cn=tasks, cn=config
> changetype: add
> objectclass: top
> objectclass: extensibleObject
> cn: db2index_2011_1_5_11_21_50
> nsInstance: userRoot
> nsIndexAttribute: numsubordinates:eq
>
>
> Saw in the error log:
>
> [05/Jan/2011:11:30:26 -0700] - userRoot: Indexing attribute:
> numsubordinates
> [05/Jan/2011:11:30:27 -0700] - userRoot: Finished indexing.
>
> But now my numSubordinates>=1 search comes up empty. Interestingly,
> numSubordinates>4 doesn't work either, but in this case it returns
> all, even those with numSubordinates<= 4.
>
> Restarting the slapd process didn't help.
>
> Filed https://bugzilla.redhat.com/show_bug.cgi?id=667488
What does dbscan say?
dbscan -f /var/lib/dirsrv/slapd-instancename/db/userRoot/numsubordinates.db4
?
--
389 users mailing list
389-users(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users
11:31 a.m.
New subject: Can't access auto.master directory entries in console
On 01/05/2011 02:10 PM, Noriko Hosoi wrote:
I might have missed something in the discussion, but even if
numsubordinates
is indexed only with presence:
# dbscan -f numsubordinates.db4 -n -r
+ 3
1 3 4
the range search should return the expected result:
$ ldapsearch [...] -b "dc=example,dc=com"
"*(&(numsubordinates=*)(numsubordinates>=1))*" numsubordinates
entryid
dn: dc=example,dc=com
numsubordinates: 4
entryid: 1
dn: ou=Groups,dc=example,dc=com
numsubordinates: 4
entryid: 3
dn: ou=People,dc=example,dc=com
numsubordinates: 2
entryid: 4
Perhaps the index got corrupted then some how. I've updated the bug
https://bugzilla.redhat.com/show_bug.cgi?id=667488
with some further thoughts about why db2index fails with numsubordinates.
Is there any other way to recreate the index? As it stands now, it is
completely broken.
--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA/CoRA Division FAX: 303-415-9702
3380 Mitchell Lane orion(a)cora.nwra.com
Boulder, CO 80301 http://www.cora.nwra.com
11:46 a.m.
New subject: Can't access auto.master directory entries in console
(2011年01月06日 09:31), Orion Poplawski wrote:
On 01/05/2011 02:10 PM, Noriko Hosoi wrote:
> I might have missed something in the discussion, but even if
> numsubordinates
> is indexed only with presence:
>
> # dbscan -f numsubordinates.db4 -n -r
> + 3
> 1 3 4
>
> the range search should return the expected result:
>
> $ ldapsearch [...] -b "dc=example,dc=com"
> "*(&(numsubordinates=*)(numsubordinates>=1))*" numsubordinates
entryid
> dn: dc=example,dc=com
> numsubordinates: 4
> entryid: 1
>
> dn: ou=Groups,dc=example,dc=com
> numsubordinates: 4
> entryid: 3
>
> dn: ou=People,dc=example,dc=com
> numsubordinates: 2
> entryid: 4
>
Perhaps the index got corrupted then some how. I've updated the bug
https://bugzilla.redhat.com/show_bug.cgi?id=667488
with some further thoughts about why db2index fails with numsubordinates.
Is there any other way to recreate the index? As it stands now, it is
completely broken.
Could you try exporting the backend into an ldif file and
importing it back?
# cd /usr/lib[64]/dirsrv/slapd-ID
# ./db2ldif -n <backend_name>
If the corrupted index is for o=netscaperoot, <backend_name> is
netscaperoot.
The command returns the exported ldif file path (assuming it is
/path/to/the/exported/ldif/file)
# ./ldif2db -n <backend_name> -i /path/to/the/exported/ldif/file
# ./start-slapd
4:20 p.m.
New subject: Can't access auto.master directory entries in console
On 01/05/2011 01:46 PM, Rich Megginson wrote:
On 01/05/2011 11:39 AM, Orion Poplawski wrote:
> Filed https://bugzilla.redhat.com/show_bug.cgi?id=667488
What does dbscan say?
dbscan -f /var/lib/dirsrv/slapd-instancename/db/userRoot/numsubordinates.db4
?
So, my numsubordinates.db4 file has been wiped out apparently by db2index, and
I cannot get it back. I've updated the bug with this information.
Thanks everyone for their help. Hopefully we can figure this out soon.
--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA/CoRA Division FAX: 303-415-9702
3380 Mitchell Lane orion(a)cora.nwra.com
Boulder, CO 80301 http://www.cora.nwra.com
4851
days inactive
4853
days old
389-users@lists.fedoraproject.org
13 comments
4 participants
participants (4)
-
Marc Sauton -
Noriko Hosoi -
Orion Poplawski -
Rich Megginson