Major new ubiqx release

[Christopher R. Hertel]

> 
> On Mon, 20 Apr 1998, Christopher R. Hertel wrote:
> 
> > > if i may take the liberty of answering this one as jf has kept me
> > > informed: he is adding a drop-in replacement for private/smbpasswd.
> 
> private/smbpasswd is just a part of it.

Yes.  I've been thinking along similar lines.

> I little thing on LDAP. LDAP is not a database model, it's a object
> database. You have entries in it (lines for a flat model) and inside each
> entries you have attributes and their corresponding values, (fields in a
> line for a flat file) What's interresting with ldap, is you can add or
> remove attributes as you want and you can lookup on any attributes.

Okay, a few things on this:

1) LDAP is a directory access protocol, not a database.  The database 
   underlying LDAP does need to be a heirarchical, object-oriented 
   database.  LDAP was originally developed as a replacement to DAP which 
   is an OSI-related protocol used to access X.500 databases.  When it 
   became clear to the folks at Mich U. that OSI was not going to boil, 
   and that DAP was too big to implement without a major grant, they 
   wrote LDAP.  Then they also got the idea that X.500 was a pain in the 
   tush so they wrote their own underlying database system.

2) The sparse array code that I've written can be used to build exactly 
   the same sort of database.  Really.  ...and...

   *** THIS MODEL WORKS REALLY WELL IF YOU CONSIDER A HIERARCHICAL 
       CONFIGURATION DATABASE FOR SAMBA ***

   Sorry, had to get that in.  Really worth thinking about, folks.  Such 
   a database could *still* be loaded from the existing smb.conf.  
   Backward compatibility, LDAP access, access via pipes and/or sockets,
   config tools... anyone's mouth watering yet?

> The really cool point about LDAP are:
> 	-the API is really simple (I wrote my first search program in less
> than 1 hour)

Yep.

> 	- you can define fine-grain access on the database, for example,
> you can grant to a user the right to change his password, nobody else can
> see it, you can define administrators or operators who can create certains
> kind of entries, and so on ...

Yep.

> 	- it includes a replication system between as many as you define
> servers, and the API take care to contact an alive server.

Okay, here we have a *BIG* question.  Do we (Samba team & assoc. 
developers) commit to LDAP as our internal database access scheme (for
config, WINS, passwords, etc.), or do we consider a lower level system and
put LDAP on top of it?  BIG issue!

  * do we require that there be an LDAP server available with which to 
    communicate?
  * do we write our own LDAP service attached to Samba (code is available)
    and, if so, will it conflict with another LDAP service on the same 
    machine?
  * do we avoid all of these problems and write something else which can, 
    if desired, talk to an LDAP server?

NOTE:  The LDAP folks are all at NetScape Corp. these days.

> 	-it hierarchical and the referrals are automatics (it's
> interresting for trust-relationship I think)

Yep.

> And communication to ldap is thru a TCP/IP socket, so you can have
> multiple samba servers connecting to the same LDAP server ! 

Which, as I've listed, raises some questions.

> Well honestly I didn't have time to grab your DB stuff. I will try to look
> at it this week. 

The ubi_SparseArrayDB module implements a simple hierarchical database.  
This is probably *not* the best way to do what we're talking about, but 
it's a start.  From what I've read here, you're talking about asking 
Samba to propogate updates to a separate LDAP server.  That's cool.  We'd 
have to have all relavent data in the correct form, though.

I think that this is a good idea but it requires design work first.  
Let's keep each other thinking for a while.

> I think the main point is to have simple and well define entry points in
> samba. Like the Getpwnam which is already a wrapper to getpwnam, the
> concept need to be extented to all the functions which will need
> informations from any kind of source. To some extend even smb.conf can be
> stored in an external file.
> 
> But currently I have a lot of idea about what we can store, and a lot are
> not implemented in samba yet.

It sounds as though we're thinking along the same lines.  Keep talking, 
I'm listening!

Chris -)-----

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