[Review Request] libwbclient-sssd

Sumit Bose sbose at redhat.com
Thu Jun 19 05:16:05 MDT 2014


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.

bye,
Sumit

> 
> Cheers - Michael




More information about the samba-technical mailing list