Winbindd Success :) [was Re: winbindd, (radio)active directory and other pains...]

Bogdan Iamandei bogdan at its.uq.edu.au
Thu Jul 18 16:55:01 GMT 2002


Mike Gerdts wrote:
> On Thu, 2002-07-18 at 02:03, Bogdan Iamandei wrote:
> 
> 
>>1). I don't seem to be able to specify multiple ranges of ID's for
>>winbindd. For example:
>>
>>        winbind uid = 1000-20000 25000-30000
>>
>>Would this be possible in the future? :) Please? :)
>>
>>2). For some reason winbindd is reading the winbindd_cache.tdb and
>>winbindd_idmap.tdb after a restart. All would be fine, but if I change
>>the UID ranges, winbindd will still use the old range. The workaround
>>is to remove those two TDBs and try again.
> 
> 
> Are you proposing that if winbindd finds a UID in the cache that does
> not fit in the range that a new UID from the range should be assigned? 
> That wouldn't be too hard to implement, but I am not sure that it is
> desirable.  The side effect would be that all the files and ACLs that
> were created would maintain the old uids.  When the user gets a new uid,
> files that they previously created or ACLs that they were added to would
> not be accessible with the new uid.  

Damn - I haven't thought of this. You're right.

> 
> 
>>3). (not really a nitpick - more like a small warning) Beware of nscd
>>daemon on Solaris. It basically takes a little while until it kicks in
>>for the first time.
> 
> 
> A while back I reported a bug in winbindd that caused it to crash nscd. 
> While debugging this problem, I found that winbindd was horribly slow
> without the caching done by nscd.  After fixing the problem so that nscd
> would stay alive, name lookups became MUCH faster because repeat lookups
> were being answered by nscd rather than by winbindd.
>
> I suspect that this slowness is because winbindd talking to PDC across
> the WAN rather than the local PDC.  I never really looked into it. 
> Since I didn't see other people complaining about slowness, I assumed
> that it was something wierd with our domain configuration.

Hmm... not really - since same authentication - going over the WAN to 
the Kerberos5 swerver goes faster. But then again - the usernames are
all in the local passwd file, so lookup is necessary.

>>4). After a while (5-10 minutes) running samba, attempting to connect
>>a share - takes a long - long time and in the end it fails with
>>something like Error - 0. I'll have to test it some more - before giving
>>some more details though.
> 
> 
> I have seen that one too, but forget the exact circumstances.

Ahaa! so it's not only my perception. That's good to know.

							Ino!~

-- 
I have seen things you people wouldn't believe.  Attack ships on fire
off the shoulder of Orion.  I watched C-beams glitter in the dark
near the Tannhauser Gate.  All those moments will be lost in time,
like tears in rain.  Time to die.





More information about the samba-technical mailing list