[proof of concept] libwbclient.so

[simo]

On Tue, 2007-09-04 at 11:21 -0500, Gerald (Jerry) Carter wrote:
> This still makes no sense to me.   Winbind is the LSA service
> of Unix.  Your FreeIPA server should be built upon system
> services.  Write your own daemon, link against libwbclient,
> Write backends for your daemon and do whatever you want.

My service would do pretty much the same job as winbind, that's why I
see them very affine.

> Winbind provides a service and should also provides the means
> to programaticly access that service.  This is fundamental
> any real AD desktop and server integration solution beyond
> just PAM logins for ssh.

I never said we should not provide that, I am only disagreeing on
providing this to PAM/NSS because I think the policy should be in
winbindd and not in the PAM module, this is where we disagree.

> >> So any discussion about unchanged NSS/PAM interfaces doesn't
> >> make a lot of sense.  All your server daemon needs do is
> >> to link against the winbindd client DSO.
> > 
> > Except that doing this way I am on the wrong side of 
> > the fence.  My daemon is like winbindd it is just that
> > I need to talk with other things then just windows/samba servers.
> > That's why I'd like to be able to stay on the winbindd side
> > and reuse, if at all possible, caching and offline capabilities.
> 
> No.  I completely disagree.  Write your own daemon.  Write
> your own caching service and your own offline capabilities.

So if my daemon talks to winbindd I will have to do my own cache/offline
code on top of the winbindd cache/offline .. kind of wasteful, and will
probably not work well (disagreements on "offline-ity" will be very fun
to see), but if there will be no other way ...

> Things that try to do everything very seldom do anything
> well.  If you try to make Winbind a generic name service,
> you will completely destroy any usefulness that it currently
> provides as you needs are well beyond the scope of what Winbind
> should be providing.

I guess debating on this without code doesn't make much sense, I guess I
will open up again the discussion on this half (this is why I split the
answer in 2) when I have something more in my hands.

> > I still don't get why we try to bring so much on the other
> > side, when all we need is to do auth/pwdchange or return
> > passwd/group entries.   Why don't we do all the elaboration
> > on the winbindd side? Is there a technical reason?
> 
> Please seen my comment about policy and mechanism and then
> explain to me how our design is not combining the two into one.

Perhaps by mechanism you mean something different from what I mean.
I see pam_winbindd/winbind as a single entity that is separated by a
pipe just because of technical reasons. Whether you put policy in
winbindd or in pam_winbind makes a difference only on technical grounds,
my other email have some hints on why I think that pam_winbindd should
be just as simple as possible and winbindd should instead do all the
work.

Simo.

-- 
Simo Sorce
Samba Team GPL Compliance Officer
email: idra at samba.org
http://samba.org