On Thu, 2002-12-05 at 16:26, Nick Urbanik wrote: > > We are using LDAP authentication for all our laboratory machines, using > OpenLDAP 2.0.23 on RH 7.3.
I assume then that you're also using it for NSS. That being the case, you should be running "nscd" on all of your clients. In "authconfig", it's the option to cache information. If you don't run nscd, then performance is going to suffer, because stuff like this will always happen for one reason or another. I know you don't want to modify hundreds of clients, but nscd is generally considered essential when using LDAP as an NSS back-end. > There are about 8000 user accounts, and the system > has worked for a couple of years. It all works fine until we get requests like > this at the rate of up to 345/second: > > base="uid=020526238,ou=People,dc=tyict,dc=vtc,dc=edu,dc=hk" scope=0 > filter="(objectClass=*) > (many other user ids in the base for other queries) Well, that's odd, isn't it? Why would it expect there to be such a uid? > I have turned the sgi_fam service off on the removable hard disks for that > class, but there are many more classes, full and part time. I have searched > bugzilla and the redhat list, but there seems to be no one else reporting this. > I would be most grateful for any suggestions or ideas on how to resolve this, > particularly on our server (rather than modify hundreds of clients). Offhand, I'd say that it would be helpful to index the presence of the uid attribute, if those uid's are invalid. AFAIK, you'll have to modify slapd.conf to specify: index uid pres,eq This is a change from it's predefined index of just "eq". After that you'll have to shut down the directory server and run /usr/sbin/slapindex -- redhat-list mailing list unsubscribe mailto:[EMAIL PROTECTED]?subject=unsubscribe https://listman.redhat.com/mailman/listinfo/redhat-list
