[Review Request] libwbclient-sssd

Sumit Bose sbose at redhat.com
Mon May 19 03:48:12 MDT 2014


On Sat, May 17, 2014 at 11:19:05AM +0200, Michael Adam wrote:
> Hi Sumit,
> 
> It is a good move to make sssd a server for the
> libwbclient API.
> 
> As Andrew said, this API is not optimal and we should
> consider extending and changing it in the future, i.e.
> get provide a "next version" of the API.
> 
> But since this is what we have right now, it is
> absolutely correct to attach sssd to it.
> 
> Now, regarding your request to include the libwbclient-sssd
> library into the samba code tree:
> I think this is wrong: a libwbclient-implementation belongs
> to the sever for which is written as an interface, not tho
> the consumer(s).
> I.e. samba's libwbclient belongs to winbindd, and the libwbclient-ssd
> belongs to sssd. (I.e. if we would ever split winbindd out into a
> separate code tree, then the libwbclinent belongs into that tree
> not into the file server...)
> 
> That being said, there is of course the problem of testing.
> We would actually need an "official" test suite for libwbclient
> that fixes the api and semantics. This test suite would belong to
> a libwbclient-devel package and can then be used by any
> server+libwbclient implementation to test the implementation.
> Of course we don't have it, but it would be the right thing to
> do imho.

Hi Michael,

I completely agree and initially I wrote libwbclient-sssd in the SSSD
tree.

However I think it would help to include this version of
libwbclient-sssd into the samba tree for the following reasons:

- code duplication, there are a number of calls which do not call a
  backend and can be used by both libraries. I can easily copy them to
  the SSSD tree but I would prefer to avoid this duplication.
- easier testing, as Andrew pointed out there is already a basic test
  available for libwbclient. I can (maybe with the help of Andreas) add
  code so that libwbclient-sssd can be tested in the same way as well.
  This way libwbclient-sssd can be tested and you do not have to spend
  time on the old API but can start working on the new one and
  corresponding tests.
- easier migration to the new API, with libwbclient-sssd in the samba
  tree I think it would be easier to migrate to a new API because then
  you can drop libwbclient-sssd and the old API in one step. If we
  maintain libwbclient-sssd in the SSSD tree the old API is out in the
  wild and I would expect the people will ask you to support the old and
  the new API in parallel for some time.

bye,
Sumit

> 
> Cheers - Michael
> 
> 
> On 2014-05-09 at 18:52 +0200, Sumit Bose wrote:
> > Hi,
> > 
> > I'm looking for review and comments on my patches in
> > http://fedorapeople.org/cgit/sbose/public_git/samba.git/log/ .
> > 
> > They add a replacement for libwbclient which talks to SSSD
> > (https://fedorahosted.org/sssd/) instead of winbindd. One of the
> > use-cases for this library is to run Samba on FreeIPA clients where the
> > FreeIPA domain already has a trust relationship to an AD forest.
> > 
> > Currently not all calls are implemented but it already works quite well.
> > I would prefer to maintain this library in the Samba source tree
> > instead e.g. in the SSSD tree. We already have a id-mapping plugin for
> > cifs-utils in the SSSD tree but here the plugin interface is very small
> > and I think chances are low that it will change any time soon.
> > libwbclient on the other hand is more complex and contains quite some
> > calls which are independent of the backend (e.g. memory management and
> > conversion utilities). I tired to extract this common code in some of
> > the patches so that it can be used by both libraries.
> > 
> > Please let me know if you think that those patches can be included in
> > the samba tree (and what I have to fix/change to make it happen) or if
> > you think it would be better to maintain it externally?
> > 
> > Btw, I will be available for discussion next week on SambaXP.
> > 
> > Thank you for your help.
> > 
> > bye,
> > Sumit




More information about the samba-technical mailing list