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