The Wrapper Project

[Andreas Schneider]

On Friday 12 July 2013 10:27:55 Andrew Bartlett wrote:
> > > > On the way to get 'make test' in Samba working I found serveral bugs
> > > > which I already sent patches for. The remaining patches are my git
> > > > repository [4].  I've changed selftest to write a hosts file for
> > > > name resolution and changed waf to look for the preloadable system
> > > > version of the wrappers.
> 
> Once we get this in, we should remove the ugly hack I currently have
> doing DNS in a hosts-like file at the libcli/resolv layer.

Hi Andrew,

yes, that would be great. In the meantime Nalin and I have implemented 
getnameinfo()/gethostbyaddr_r()/gethostbyname_r/gethostname(). So we are more 
complete. I'm working on getting nss_wrapper working on Solaris right now.

> > I don't expect that they need to be updated very often once they are in a
> > working state. So they need only be updated when we add new features we
> > will use in Samba.
> 
> The biggest reason I have for keeping a copy in the Samba tree (rather
> than require installation) is that when I've found bugs in
> socket_wrapper, it tends to be of the incredibly subtle kind - the kind
> that could take another developer just as many hours to debug.  It might
> only need a proper pkg-config dependency, but whatever we do needs to
> ensure we always use the same version that Samba was autobuilt with.
> 
> I guess the same applies just as much to all the other users however :-)

That's the reason why we need more tests. We have more or less no specific 
socket_wrapper tests at all.

> 
> It certainly is incredibly encouraging to see this little project grow
> wings and gain a life of it's own, as it has been the keystone to the
> level of automated testing we have, and it would be great to have other
> projects use it too.

Nalin started to use it for MIT Kerberos testing and SSSD will follow soon. 
The wrappers are an awesome piece of software and we should encourage others 
to use it and help improving it.

> I'm still sceptical about loosing support for handling this without
> LD_PRELOAD (it seems an unfortunate feature to loose), but your testing
> across BSD, Solaris and Linux variants seems to rebut my concerns.

I plan to write more tests and make sure it will work in future.

> My biggest concern is ensuring we don't make it any harder than we need
> to build it, to test Samba on an unusual platform (where we are seeing
> other issues, and want to run make test), and in particular for the
> build farm.

You probably have to install them only once and then update if there is a bug 
hitting us or a feature we require for testing. Changes to the wrappers are 
seldom and once they are implemented correctly and we have tests it should 
just work.

> My preference would be for it to build with wafsamba like our other
> subprojects, and for it to stay in samba.git like tdb/talloc/etc.

I'm happy with creating repositories for them on git.samba.org but I plan to 
maintain them out of the Samba tree. I want to encourage others to use, 
contribute patches and create packages for that. Having them in the big 
monster tree of Samba is counterproductive in my opinion. I'm fine if someone 
contributes a waf build, but I will not abandon CMake as the main build system 
cause it offers a lot of features waf doesn't have. The most important for me 
is the testing infrastructure it provides out of the box. 

https://mock.cryptomilk.org/index.php?project=socketwrapper&date=2013-07-21

> That said, provided you patch the build farm scripts with whatever magic
> is required to build this before the test run, I'll consider my concerns
> here addressed.   (This is not unprecedented:  We once had to build
> samba4 to get smbtorture4 for the samba3 build to test with).

I'm sure we will find a way once they are working and are better tested.

> 
> Finally, congratulations on taking a Samba-specific hack and exposing it
> to the world!

Thanks, there is still a lot of work to do!


	-- andreas

-- 
Andreas Schneider                   GPG-ID: F33E3FC6
Samba Team                             asn at samba.org
www.samba.org