getent not working, solaris 10 only

Hello, thanks in advance for any help!

We use LDAP for our unix boxes
When I run getent passwd on solaris 10, it only returns some of the ldap entries, not all. Aprox 300 of 4000. When i run the same command on linux or solaris 9, it comes back correct.

my nsswitch file is good.

I ran a truss, and you can clearly see in solaris 9, where it queries ldap. But, in solaris 10 truss output, i'm having a hard time seeing where it queried ldap at all, i dont see it!

And ideas why it would only return part of the ldap entries?

What about the directory server logs ?

good idea,

I have access to the logs, but i dont see anything happening, i did a tail -f [accesslog] while doing a getent passwd, i dont see anything happeneing.
Where would executing a getent command get logged in the DS logs, it may not be set for that verbose level...?

Knowing what DS server it is might help. However, having it not logging queries in its access log would seem to me a very useless configuration.

What says

ldaplist passwd

?

Thanks you guys for helping!

It's a sun one dir server, there are basically 3 logs i see, access, errors, and audit.

im tailing the access log, i would think that would register something, but i just did a ldaplist as you suggested while tailing access, i didnt seething in that log.

but,

this issue i have is only with getent passwd, i can use ldaplist, that works good, like it should.

Well, if ldaplist list all entries but the access log shows nothing, perhaps are you looking at the wrong directory server ...

Another explanation would be everything is cached but I'm skeptical about the cache storing all the user's database. To rule that out, you might want to disable temporarily the name service cache (nscd) and see if that improves the replies:

svcadm disable -t name-service-cache

I had the same problem on our Sol10 servers, the "getent passwd" command stopped after 4300 entries (from 12.000 entries). But the getent command on Sol8 and Linux clients still worked well.

I found out, that the reason for this behaviour was in my case a ":" character in the gecos attribute string of one user on the Oracle Directory Server. This is a bug in the LDAP client implementation of Solaris10.