|
Hi All – I’ve got another one today. We have 1 attribute in our infrastructure that’s extremely large – it’s a PKI CRL that’s around 15MB. It sits in an entry that has about 6300 sub entries. We had some previously mentioned issues running out of file descriptors on our consumers.
After resolving those, we were getting err=11s on searches under that entry, returning nentries=699,700,701. 700 didn’t make sense, but I thought that the issue might be the search limit – these are anonymous,
so I tried the anonlimitsdn setting with a template, and set it higher than 700. That wasn’t it.
We then started getting err=53s searching that entry – we don’t even seem to get the err=11s anymore. These searches ARE showing up un-indexed. We have indexes for the attributes though – is it because of the
;binary versions? Example; [21/Jan/2014:13:32:28 -0500] conn=37952 op=1 SRCH base="ou=Entrust Managed Services SSP CA,ou=Certification Authorities,o=Entrust,c=US" scope=2 filter="(&(|(objectClass=cRLDistributionPoint)(objectClass=pkiCA))(cn=CRL*8))"
attrs="authorityrevocationlist;binary authorityRevocationList certificaterevocationlist;binary certificateRevocationList" [21/Jan/2014:13:32:28 -0500] conn=37952 op=1 RESULT err=53 tag=101 nentries=0 etime=0 notes=U |
-- 389 users mailing list 389-users@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/389-users
