We're pulling our hair out over this issue and wondering if it rings a bell for anyone or perhaps there's a bug fix in a later version of 389 that might resolve it. I've looked and not found anything but it's also not the easiest issue to search for. We are on CentOS DS now but can move to 389 of course but hesitate to put forth the effort if we aren't reasonably sure it will resolve our issue. Certain bind DNs (so far only service accounts) are unable to search for users. For instance: [20/Feb/2014:10:18:05 -0500] conn=15600927 op=1 BIND dn="uid=copier,ou=employees,dc=domain,dc=org" method=128 version=3 [20/Feb/2014:10:18:05 -0500] conn=15600927 op=1 RESULT err=0 tag=97 nentries=0 etime=0 dn="uid=copier,ou=employees,dc=domain,dc=org" [20/Feb/2014:10:18:05 -0500] conn=15600927 op=2 SRCH base="ou=employees,dc=domain,dc=org" scope=2 filter="(uid=user1)" attrs="cn mail uid" [20/Feb/2014:10:18:05 -0500] conn=15600927 op=2 RESULT err=0 tag=101 nentries=0 etime=0 I did a search of the directory at the same time on the same replica as myself and other users with the same access level and was able to search uid=user1. It sometimes only lasts a few minutes though in a few instances it was much longer. In one case we resolved it by adding a service account with a different name but the same access level and moved the application to that account. In another case where hundreds of copiers are configured with the binddn and thus changing the binddn wasn't practical we were able to resolve it by restoring the masters from a db2ldif and re-initializing the consumers. It's not isolated to once consumer--we've seen it on at least 2: one partial, one full. Our environment is CentOS DS on CentOS 5. We have ~35,000 entries in the directory, most of them users. We only have 9 acis, most of which provide access via groups. We have 2 multi-masters, 2 full consumers and until recently 2 partial replicas. We converted the partial replicas to full replicas recently as we know there are/were issues with partial replication and wanted to rule that out. We're at the latest version of CentOS DS: [morgan@ldap01 ~]$ rpm -qa|grep centos-ds centos-ds-admin-8.2.1-1.el5.centos centos-ds-console-8.2.0-4.el5.centos centos-ds-base-8.2.8-2.el5.centos centos-ds-8.2.0-2.el5.centos [morgan@ldap01 ~]$ This issue is killing us as it effectively denies access to a service for all users that use it. This could be the VPN for instance which many users depend on all day for their work. We are considering many options, primarily just moving to 389 on CentOS 6. That's a fairly big task for a site of our size so we'd like some confidence that we won't see a repeat of this issue. There's talk of considering other products which no one wants to do but we're all edgy as this has caused a fair amount of downtime and about all I can do at the moment is monitor for it and re-initialize when it happens which doesn't inspire confidence. thank you, -morgan -- 389 users mailing list 389-users@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/389-users
