[Review Request] libwbclient-sssd

Sumit Bose sbose at redhat.com
Wed Jul 2 08:44:32 MDT 2014


On Thu, Jun 19, 2014 at 01:16:05PM +0200, Sumit Bose wrote:
> On Wed, Jun 18, 2014 at 05:25:59PM +0200, Michael Adam wrote:
> > On 2014-06-18 at 16:38 +0200, Sumit Bose wrote:
> > > On Mon, Jun 02, 2014 at 01:38:39PM +0200, Sumit Bose wrote:
> > > > On Fri, May 30, 2014 at 03:37:13PM -0700, Jeremy Allison wrote:
> > > > > On Fri, May 30, 2014 at 05:55:02PM +0200, Sumit Bose wrote:
> > > > > > 
> > > > > > Andrew, Michael, Jeremy,
> > > > > > 
> > > > > > thank you for your comments and suggestions. I got the impression that
> > > > > > you prefer that this library will be maintained outside of the samba
> > > > > > tree. If you agree I will port the common code and my additions to the
> > > > > > SSSD build system and maintain it in the SSSD tree.
> > > > > > 
> > > > > > I will be looking for discussions about the new winbind interface on
> > > > > > this mailing-list and try to contribute.
> > > > > 
> > > > > No, I didn't say that!
> > 
> > But I did. :-)
> > 
> > Let me explain my thoughts a litte more:
> > 
> > I think that it is conceptually wrong to have the sssd wbclient
> > library not with the sssd server (where it belongs) but in samba code.
> > 
> > I understand the reason, and that may be considered a design
> > problem, namely that we have the test infrastructure along
> > with the reference implementation (i.e. winbindd). Maybe the
> > solution would be to publish the libwbclient-test code
> > separately, or at least create a package with it that one can . :-)
> > 
> > And I don't see how libwbclient_sssd being in the samba tree will
> > help a lot with regards to changing the wbclient API: libwbclient_sssd
> > will always be running with a released version of samba, i.e.
> > against a published version. I understand that libwbclient_sssd
> > would have to be adapted while we go along modifying samba
> > internally, and this feels wrong. It would also *require* any
> > Samba developer who changes libwbclient API to change the
> > libwbclient_sssd implementation at the same time when it is
> > (as you proposed) integrated in our selftest/autobuild. And this
> > would require also setting up sssd and testing that the server
> > still works. I don't quite see that we are there yet.
> 
> Thank you for your comments. As said earlier I don't want to push you to
> add libwbclient_sssd to the samba tree. I'm equally fine maintaining it
> in the SSSD tree and I agree that it should in general be the preferred
> solution (we are doing this already in SSSD with various Kerberos client
> plugins and are currently discussing an idmap plugin for NFSv4). But
> since samba is the main consumer and winbind the main provider of the
> API I wanted to ask first if you want to keep a stronger control about
> its implementations.
> 
> Other comments in this thread mentioned that there are other
> implementations of the API which might or might not work with recent
> samba versions. So it looks like it is a real public API and you might
> have to support it even if a completely new designed API is available.
> If this is the case my original concern that offering libwbclient_sssd
> with SSSD will cause additional maintenance work to you is void because
> it is already caused by the other implementations.
> 
> About testing, my idea was to work with Andreas to include
> libwbclient_sssd in selftest/autobuild with the help of socket wrappers
> or cmocka to keep the additional dependencies for samba small.
> > 
> > Of course, even with the libwbclient_sssd external, the sssd
> > developers will by the overlap with the samba development be
> > part of the process of modifying the libwbclient API, and are
> > most welcome to join the discussion and design for a good one.
> 
> Thank you, I certainly will :-) I also want to look at the existing
> tests for the API and see how they can be adopted for external
> providers.
> 
> > 
> > All that being said, I will gladly accept being proven wrong.
> > And I will look at the patches. From the first superficial
> > glance, they look very clean.
> > 
> > > > yes, as I said I think there are good reasons to include it in the samba
> > > > tree until a new winbind API is available and I'd be happy to be an
> > > > active maintainer of this library until then.
> > > 
> > > It would be nice if someone can review the patches. I think as an
> > > external contributer I need two reviews. I have rebased my git tree at
> > > http://fedorapeople.org/cgit/sbose/public_git/samba.git/log/ to a recent
> > > version of the samba master tree. Shall I send the patches to the list
> > > as well?
> > 
> > Not necessary for me personally, but others may
> > have a different preference.
> > 
> > > It would be easy to ask some of my Red Hat co-workers to do the review
> > > but I was hoping for others as well to not make this a Red Hat only
> > > party.
> > 
> > That is very decent!
> > 
> > Please give us a couple of days to try and find
> > the time to review...
> 
> Thank you but please do not spend too much time on it as long as it is
> not clear if it will go to samba or SSSD.

Please allow me to pull back my request for review.

As mentioned earlier I fully agree with Michael that conceptually the
SSSD tree is a better place for libwbclient-sssd. So I will port the
patches to SSSD and ask the SSSD team for review.

Thank you for your comments, suggestions and discussion.

bye,
Sumit


More information about the samba-technical mailing list