Samba management

[Dave Fenwick]

The problem we've had with Samba up until Samba4 is that it just wasn't
ready for an API.  I've been trying to find the right way to APIify (if
that's a word) Samba since 1995, but the code base has always been
pretty monolithic.  There was also the considerable problem in Samba2
and Samba3 of having the scads of globals that were required in order to
make any lib functions work for any management interface.  With the work
that you've all done in Samba4 to get the globals cut out of the
picture, and with contexts, an API is now workable.

I've given an awful lot of thought to this over the last many years, and
there really are multiple paths that can be taken.  One path is to
create the monolithic library like we did in Samba3 and let anyone call
functions within that library.  However, I'm not sure that makes a lot
of sense from a management perspective.  From a management perspective,
we need a set of generalized calls for things like creating a user,
creating a group, adding a specific service (file or print), querying
status of the existing services, stopping, restarting, etc.

We need to think of EJS just as another client of the Samba4 library and
not as the encompassing management strategy for Samba4.  It'll be great
having some of those functions available directly in the distribution
(when they're done) but we should be looking for more than that.  We
need a library that allows for separation of Samba4 functions from
delivery, as well as allowing for multiple delivery paths and delivery
data types to be used.  For example, if we want to allow someone to
create an AJAX frontend for Samba4, we'd need to provide an HTTP
delivery mechanism for retrieving pieces from Samba4.  In that
particular case, we could reuse the existing SWAT HTTP engine, but link
it to the library and provide secure URL transactions through it, with
delivery in XML, XHTML, or even proprietary data sets.

With the library in place, bindings for Perl, Python, PHP, etc. would be
easily achievable.  The API would probably end up looking a LOT like the
Win32 API because, well, that's what we do.  In fact, some 10 years ago,
I had proposed doing a CORBA object engine for Samba, but it just wasn't
ready for it at the time.

I still have some of my old documentation as well as some code I put
together for Samba2 and Samba3 that I can pull back out of the dust. 
Let me know how I can help.

-- Dave

On Thu, 22 Jun 2006 09:46:08 +0400, "Alexander Bokovoy" <ab at samba.org>
said:
> James Peach &#1087;&#1080;&#1096;&#1077;&#1090;:
> > On Wed, 2006-06-21 at 17:06 -0500, Gerald (Jerry) Carter wrote:
> >>> SWAT would be ok for the first consumer / to polish the API.
> >> Please...no.  We need an API that will get used.  SWAT has its
> >> fingers in everything and is just broken as a management tool.
> > 
> > Agreed. I'm all for ditching SWAT. There's an ocean of management
> > tools out there, both open source and proprietary. IMHO, providing a
> > rich management interface for these is of more value than supporting
> > SWAT.
> So, let me round up this discussion:
> 
> 1. Reviving SWAT in Samba 3 is pointless.
> 2. Better to concentrate on API for external management tools
> 3. Such an API is actually a set of MSRPC interfaces, including registry
>   management
> 4. Encapsulating those interfaces into a sort of library and providing
> its bindings for popular scripting languages (Perl, Python, etc) is seem
> of better value.
> 5. Additionally, local operation via Unix socket is probably a good
> thing as user of that library and probably will be subject to test via
> 'make test'.
> 
> Anything else?
> 
> 
> -- 
> / Alexander Bokovoy
> Samba Team                      http://www.samba.org/
> ALT Linux Team                  http://www.altlinux.org/
> Midgard Project Ry              http://www.midgard-project.org/
>