Thanks for the reply.
The matter is it happens exactly after reboot and
there is no chance to look into Netinfo database unless youäre logged in. And I
think that any temp cache is empty after reboot, or?
According to the article below
summary, lookupd calls Open
Directory when its local cache and NetInfo cannot find an answer. Whether Open
Directory is called by lookupd or
called by another application, Open Directory always searches its local NetInfo
database first and then conducts other searches using whatever search technology
it has been configured to use. Most of the time, that search technology is
But I finally found that my OS X client never asks
LDAP server right after reboot. But it does ask LDAP several minutes
Sorry for the possible off-topic... Looks like it
is better to redicect it to some OS X list.
BTW I tried to configure DHCP explicitely via
/etc/resolv.conf but it didn't help. My OS X client gets IP config from DHCP.
LDAP config in Directory Access is manual.
----- Original Message -----
Sent: Wednesday, April 14, 2004 4:44
Subject: Re: Antwort: MAC OS X clients
and OpenLDAP [Virus checked]
To truly know that what ever changes you have made to your LDAP
are in effect. You should go into the "netinfo" manager and clear your
cache entries then reboot. OS X will look to these cache settings in
it's local netinfo database
first before going out to the LDAP server. The
MCX cache contains information on known computer list, computers, groups, and
Here is some info on Mac OS X client access.
Wednesday, Apr 14, 2004, at 04:45 US/Pacific, firstname.lastname@example.org
have a strange problem with MAC clients trying to authenticate via
>After rebooting MAC it takes some several minutes for the
client to be able
>to log in with username and password stored in
I have 0 experience with Macs, but I've been trying to use
"zeroconf" with Mandrake Linux some time ago, and run in a somewhat similar
problem. I believe Macs use "zeroconf" type of DNS resolution per
Make sure your Macs actually use a real DNS server for name
resolution, and see if the problem goes again.
/smaller>/fontfamily>Obviously I may be
completely wrong on this, but it's easy to test...