This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 1.7.35-0.3

On 02/20/2015 11:24 AM, Corinna Vinschen wrote:
On Feb 20 11:07, Tom Honermann wrote:
On 02/20/2015 04:56 AM, Corinna Vinschen wrote:
Lastly, running cygserver to cache the LDAP data has another side-effect
when using VPN.  Since the cygserver is usually started before you've
dialed into the VPN, your username and some groups will get reported as
"DOM+User(12345)".  You have to restart cygserver after the VPN is up to
correct that.

Yep.  We should contemplate to allow sending a signal to cygserver to
invalidate its cache.

Perhaps cygserver could subscribe to network event notifications and
automatically invalidate its cache?

How do you know if and when an interface change requires a cache

I doubt there is a perfect algorithm, but perhaps a heuristic would work fairly well. For non-mobile systems, interface changes are presumably rather rare and invalidation on the addition of any new interface might be acceptable. For mobile systems migrating between networks, the situation is tougher - invalidating the cache when not connected to a network from which it can be rebuilt would be frustrating. An ugly solution would be to invalidate depending on whether a (set of) user specified address(es) has transitioned from non-reachable to reachable (perhaps cache addresses of previously known AD servers?). A not-quite-as-ugly solution might be to invalidate based on specific networks (ie, a user specified wifi network name). None of these sound great to me, but perhaps would work well enough in practice.


Problem reports:
Unsubscribe info:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]