Management of Samba

[Andrew Tridgell]

Luke wrote:
> can we move this one to samba-technical, purleez?

done!

For those of you on samba-technical but not on samba-team here is a
bit of an explanation on samba-technical/samba-team ...

samba-team has been where really low down technical discussions on
Samba have been for the last year or two. It contains 15 people
comprising "the team". It isn't an open list because we sometimes
discuss matters that can't be really discussed in an open forum (there
aren't many of those, really!). For example, when Johns book was still
being written he couldn't announce it but we discussed it on
samba-team.

anyway, we realised recently that this was all rather silly and we
were missing out on input from lots of really good people. We used to
have technical discussions on the samba list but they started getting
swamped by user questions, so we followed the path of least resistance
and starting using the team list. Now we have established the
samba-technical list to try to get things all out into the open (where
they belong!) again. Hopefully the samba-team list will be used less
and less as there isn't really much we have to hide ...

unfortunately old habits die hard. We are still discussing technical
issues on the samba-team list. When we catch ourselves doing this we
will move them to samba-technical. This will confuse the hell out of
some people, but hopefully it will happen less and less.

now back to our scheduled discussions .....

Dave Fencick has proposed doing some magic ORB stuff with Samba. He
wants to build a ORB interface so people can administer Samba from a
ORB aware system. The following email should get samba-technical up to
speed. Of course, as this was an email from me it probably paints a
different picture to what Dave would paint ... let the discussion begin!

Cheers, Andrew


From: Andrew Tridgell <tridge at samba.anu.edu.au>
To: djf at assetsw.com
CC: samba-team at samba.anu.edu.au
Subject: Re: Management of Samba

Dave wrote:
> Somewhat, I should say.  The way I look at it, people are looking for
> several things:
> 
> 1)  An easy means of doing Samba admin straight from the distribution
> 2)  An extensible administrative back-end for Samba
> 3)  An extensible administrative front-end for Samba
> 4)  Specs for everything

yep, with 1 being the most asked for :-)

> (1) can be handled with SWAT, although most administrators would agree that
> it is not as simple to use as it could be - And never will be overly simple
> due to gaping holes in HTML that reduce functionality.

I'd be interested in what holes you are thinking of here. My plan at
the moment is to use javascript to fill any really obvious interface
holes, while trying to leave it fairly functional with non-javascript
browsers. (for example, javascript is currently used for the
auto-refresh code)

The big one I've pondered lately is authentication. HTTP
authentication really is rather poor, with only https being a good
general solution. Unfortunately https can only be used with MSIE if
you pay a commercial certificate provider (a _really_ disgusting move
by MS I think).

> (2) is what we're talking about now.  I think we could put together a
> relatively robust interface and provide specs for other software needed
> (Apache?  ORB?) to make it work.

yep!

> (3) we would provide at least some level of interface, and let developers go
> where they will with it.  Perhaps providing the mod-jserv with our servlet
> and some level of how things work might be sufficient.  Also, providing a
> Java front-end that talks directly to the ORB might be a good thing too.
> This would show people how to directly tie to the ORB rather than through
> the web server.
> 
> (4) is what I'm trying to ascertain now.

my biggest worry with the whole ORB thing is that it is
complex. Setting up an ORB is a complex business (akin to setting up
an RDBMS) that can go wrong in any number of ways. If an organisation
already needs an ORB for some other reason then great, we can provide
a way for them to interface Samba to an ORB. If they don't need an ORB
for anything else then installation/running of an ORB is just a
pain. How many Samba servers have an ORB installed on the same box
now? 1% ? less?

You will notice that I built a tiny web server into SWAT. That was
because I didn't want users to have to install a web server to use
it. It worked because HTTP is a really simple protocol that can be
implemented from the ground up in less than 100 lines of C, including
authentication and file download.

An ORB is another beast entirely. It requires a large body of code and
uses a very complex protocol (it has to be complex to handle all the
magic that it does!).

> Now, to try and persuade Andrew to update his Computer Science thinking into
> the 1990s <<< GRIN >>>  :-)

better get me to the 80's first ...

> You are absolutely right in your thinking of not bundling EVERYTHING in
> Samba.  However, it *could* be an option.  Any time a vendor (I consider us
> a vendor these days - we provide a service for others, including
> functionality, support, and bug fixes) gets to the critical mass level,
> their distributions generally start growing.  Microsoft provided a decent
> level of functionality in LANMAN, but the interface was brutal.  When the
> Windows Networking approach hit, it was better, but still painful.  With NT,
> it provided additional functionality including administrative interfaces,
> and the distribution grew significantly.

my proudest moments with Samba have been when we shipped a new version
which was smaller than the last version but better (faster, less bugs,
more features etc). It hasn't happened often, but it has happened.

> -  A Java servlet element for the mod-jserv in Apache that talks to our
> CORBA objects
> -  A CORBA IDL that can be compiled with whatever IDL interface the user
> has.
> -  The user interface elements for the Java servlet implementation
> -  A Java application or applet that shows how to directly tie in to the
> Samba CORBA objects
> -  Links for where to get all the other pieces needed to implement this
> functionality (Apache web pages, OmniOrb web pages, etc.)

there are some other problems that come to mind. For example, how are
you going to link this stuff into the internals of Samba? To control
the locking and connections you need to get at the shared memory
segment. That can only be done from C (unless you want to cast the
layout in concrete and do some pretty fancy footwork with a different
language). You could do it via calling C programs but that presents
problems of its own.

It only makes sense to me to do it via linking to the Samba code. That
way we can change the smb.conf parser, or update the shared memory
structures or anything else that takes our fancy without major
compatibility problems.

> Now, the last convincing argument for CORBA - IIOP.  I've written a lot of
> sockets code over the years.  Both Unix BSD sockets and Winsock
> applications.  Writing any significant interface with either requires a good
> deal of time.  Generally, you pull some previous sources you have laying
> around, delete out the things that make it specific, and implement the new
> functionality from there.  Then you have to invent some type of protocol at
> layer 5 to implement your interface.  With IIOP in CORBA, all of that is
> already taken care of.  You implement the work you want to do, and it's
> done. 

that's also exactly what HTTP gives you. swat has no sockets code in
it (it relies on inetd or a web server) and has the interface layer
taken care of by the browser. Generating UI code in HTML is very 
simple. 

I'm not trying to give the impression that a ORB interface for Samba
is a bad idea. I think it is a great idea. I just think that it
shouldn't be pushed as the only (or even the primary) way of getting
at a Samba server for admin. For most users simplicity is best.

Cheers, Andrew