Dave Augustus wrote: > Sorry! (Let me get my head out of the sand) > > I use a check script called ldap.monitor. It comes with mon, a > monitoring package written in perl. > > The script just binds and checks that a certain attribute exists and is > a certain value. Here is an example: > > monitor ldap.monitor \ > --username "uid=mscript,ou=Special Users,dc=hq,dc=org" \ > --password "12345678" \ > --basedn "uid=mscript,ou=Special Users,dc=hq,dc=org" \ > --filter "uid=*" \ > This seems bad to use this filter if the search is using scope SUBTREE. It doesn't appear to be the case here, but you might want to check and make sure. > --attribute "uid" \ > --value "mscript" \ > 192.168.16.10 > > I use this on BOTH of my servers. The other day I attempted to delete > alot of objects (>10,000) as the admin user from my ou=people leaf and > then my admin account was locked out with this SAME error. > > Then my script started failing. I ended up having to login as Directory > Manager to complete the deletion. > > So my script now fails and neither my admin account (admin) nor my > script account(mscript) can login successfully. > > The log entries are the same: > > "RESULT err=3 tag=101 nentries=0 etime=0" > > All that is happening is that the script is checking to see if an > attribute is the right value. The script cant login and therefore fails > the *check*. > > I have restarted the server several times. > If the script is really just doing a BASE level search, I don't see how this can happen. You can raise the search limits on a per user/role basis - see http://www.redhat.com/docs/manuals/dir-server/ag/7.1/password.html#1085603 > Thanks for your time, > > Dave > > On Thu, 2006-12-14 at 23:54 +0100, Pierangelo Masarati wrote: > >> Dave Augustus wrote: >> >>> I have a check script running on 2 server. One of them is failing. The >>> logs are stating this: >>> >>> RESULT err=3 tag=101 nentries=0 etime=0 >>> >>> Why? >>> >>> >> (server-enforced?) time limit is being exceeded (err=3) >> >>> How can I fix this? >>> >>> >> You don't provide enough info to understand why the server is going into >> timelimit without returning a single entry and with what appears to be >> zero elapsed time (etime=0). >> >> p. >> >> -- >> Fedora-directory-users mailing list >> Fedora-directory-users at redhat.com >> https://www.redhat.com/mailman/listinfo/fedora-directory-users >> > > -- > Fedora-directory-users mailing list > Fedora-directory-users at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-users > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.fedoraproject.org/pipermail/389-users/attachments/20061215/e8ae91d0/attachment.bin
