To release Samba 4.0 'as is'

[Andrew Tridgell]

Hi Jeremy,

> Wouldn't it be easy to just add a different backend into the
> s3 winbindd cachine server, and let the AD-DC code handle the
> complicated bits (the path lookups to the right DC etc. etc.) ?

no. There is very little about the s3 winbind code that makes sense on a
AD DC, especially if it is a global catalog.

The forked process model, the async callbacks, the connect to multiple
domain DCs, the cacheing. All of it makes no sense for a global catalog
DC. The whole strategy behind the daemon is not suitable for a AD DC
environment.

> After all, I think that's what Windows servers do (or something
> similar)

I'm not sure what you mean here. What part of windows is like winbindd?

> winbindd certainly isn't the right place for the
> complexity you describe - but what you're describing isn't
> really what we've previously described as winbindd. I think
> you're describing a daemon with different functionality than
> the current s3 winbindd code. Maybe it should either have a
> different name or be a separate service inside the s4 'samba'
> binary (as other functionality is implemented).

it is already a separate service inside the samba daemon, and has been
for years. The service is still called 'winbind', because it inherited
the winbind socket protocol to nss clients and to wbinfo. This is what
all of the current deployments of AD have been using.

> For stability I'd suggest we leave the s3 caching winbindd
> functionality alone so the codepaths from smbd just call into the
> existing winbindd as they currently do.

sure, I was proposing not to change this. I'm proposing to build on what
we've been doing for years, which is to use the internal winbind service
inside bin/samba when we are an AD DC, and use the external s3 winbind
service when a member server.

> Remember there are person-years of testing and production
> use of that code, so I'd be loath to change out the code
> completely for 4.0.

and I am equally reluctant to take on a complete rewrite and replacement
of the internal winbind service in bin/samba that has been used
successfully in all of our deployments so far.

> Can't we end up with both running on a box functioning as an AD-DC ?
> nsswitch can definitely handle that (if indeed the new functionality
> needs to be plumbed into nsswitch).

We can have both installed, but I don't think running both at the same
time makes any sense. The s3 winbind code just doesn't do anything
useful on a DC. 

Cheers, Tridge