Management of Samba (again)

[Christopher R. Hertel]

I read the thread titled "Management of Samba" with great interest.  In
fact, I printed the whole thing off so that I could make notes.  It was
a good discussion, but I felt that there were two critical pieces
missing:

  1) A layer of abstraction between the running configuration and the
     management back-end
                --------
  2) an overall design

If'n you've read my rantings before, you know that I'm always talking
about modularization.  That's the approach I've taken with this, as you
might expect.  Keep in mind, though, that this is an abstraction, not
an implementation.  Think conceptually...

Okay.

The "running", or "live" configuration (as opposed to a static one,
eg.  smb.conf) manages the behavior of the Samba daemons; smbd & nmbd.
The daemons access the the running config via the lp calls.  Without
challenging that relationship (or mechanism), try thinking of the
running config as an entity on its own.  The lp calls are one way--an
internal way--in which we currently communicate with that entity.
Another way is to send a signal to the daemons which cause them to
reload from smb.conf.

You knew all that, but I need to set the basis for the next bit...
Step back a minute now and abstract this:

          +---------+  read
          | running |--------->
          | config  |<---------
          +---------+  write

Nice.  Simple. Obvious.

...and it says so much.

In the discussion I read, several mechanisms were suggested as an
addition or replacement for the read/write portion of the above.  I
also think that people were suggesting the model below, but I'm not
sure that it was stated plainly.

Instead of building ORBs or SNMP or RPC or whatever directly into
Samba, we can add an additional layer that would allow any and/or all
of these to be build external to Samba, and offered as options:

                                       :
                                  +--------+
                                  | config |
                                  | client |
                                  +--------+
                                       |
          +---------+  generic    +--------+
          | running |  interface  | config |
          | config  |<----------->| client |
          +---------+             +--------+
                                       |
                                  +--------+
                                  | config |
                                  | client |
                                  +--------+
                                       :

In this model, the config readers (nmbd, smbd) and the configuration
management agents (swat, etc.) are all clients of the running
configuration.  They communicate with the running config using the
"generic interface" (which needs a lot more definition, see below).
Before anyone panics, keep in mind that this is an abstraction.  I'm
not suggesting getting rid of the lp calls (yet).  They can be adapted
to work on top of a new model if necessary.

Okay, so what is the "generic interface"?

I can think of a lot of ways to do this.  Currently, we use the lp
calls and the signaled re-load.  This method isn't optimal for adding
on additional clients, though, so we will want to consider others.  I
would like to propose the following constraints:

  * Local only.
    Am I insane?  Don't think so.  Configuration agents such as swat,
    or the CORBA stuff would provide the network access.  Allowing
    local- only access to the config itself provides a security
    checkpoint and simplifies the design of the interface.

  * Access controlled.
    Only authorized users should be able to talk to the interface.  On
    Unix systems, root would be the default, but it would be nice to be
    able to add other users.  The configuration agents would run as an
    authorized user.

  * Portable or replaceable.
    One way or the other, we need to be able to port this *model* to
    all platforms.  On Unix, communication might be implemented via a
    named pipe or shared memory.  On Amiga, an AREXX port.  On VMS, it
    might be something else.

      (BTW, how many of you know that Bill Hawes--the SMBFS
      developer--wrote AREXX.  It was an independent product that was
      so good and so popular that Commodore bought it an added it to
      the standard Amiga OS distribution.  It's still there and still a
      major feature.  Amazing stuff.)

    Anyway, this is where we go modular again.  Each environment might
    have it's own communications method.  I've only suggested a few.
    In fact, I could break my own "local only" requirement above and
    suggest that a IP socket be one communication option.  The point is
    that we'd need independent, replaceable modules for each method.
    If we're really clever, we could allow multiple communications
    paths at the same time.

  * Standard clients.
    It would make sense to include swat as a standard config agent.  It
    would also make sense to include a command-line interface (sort of
    like xntpdc for xntpd).  This latter is something I've *really*
    wanted.

  * Backward compatibility.
    Most important.  We still want to be able to send a signal and have
    the smb.conf re-read.  We still want to have the lp calls.

Anything else?

Yes.

It would be necessary that the running config be able to supply a list
of parameters and legitimate values for those parameters.  We want to
be able to add, remove, and change parameters without breaking all of
the configuration agents that people might write.  In other words,
there needs to be a mechanism by which the config agents can determine
how to talk to the running config.  I'm not sure how this would work
yet, but I'm thinking about it.

So, how would we implement such a thing?

One obvious means would be to run a config daemon that would manage the
live configuration.  nmbd & smbd would talk to that daemon when they
needed config information (i.e., the lp calls would be rewritten to
talk via the communications link).  Both Samba daemons, then, would
need to start the config daemon if it wasn't already running.

There are probably other options, and I want to avoid getting too deep
into implementation while I'm still talking about design.

The real feature of all this is that it allows Dave to write to CORBA
without directly impacting Samba itself.  Samba needs to do Samba's
job, and I agree with Andrew that we should (and can) make it smaller
where ever possible.  Providing convenient hooks to allow additional
development around Samba, without hacking into Samba itself, is a
direction that I recommend.  This is one way to make the product truly
open.

That's my 2 cents.  Anyone have change for a dime?

Chris -)-----

-- 
Christopher R. Hertel -)-----                   University of Minnesota
crh at nts.umn.edu              Networking and Telecommunications Services