Major new ubiqx release

[Jean-Francois Micouleau]

On Wed, 22 Apr 1998, Christopher R. Hertel wrote:

> Jeremy wrote:
> >
> > Well, I've recently implemented a UNIX style of password
> > interface (getsmbpwnam() etc.) through which all access
> > to the underlying password database is now funnelled in
> > the main branch code.
> 
> This is the way to go!

Yep, 
While I think of it, we also need a function returning a chained-list of
all the users (for the NT user manager program).

> > So long as we stick with these interafaces, we can
> > build whatever we want as the backend - and even have 
> > them plugged in. I would say not to commit to an
> > LDAP storage yet, until we know what the best
> > method will be (we don't even have a gdbm backend
> > yet - let's walk before we run :-).
> 
> Not just plugged in, but swappable, or even chainable.  Underlying your
> API there could be a variety of storage & retrieval mechanisms.  LDAP
> could be one, the normal flat file could be the default, there may be 
> others that communicate with something like Active Directory (just 
> brainstorming, but hey!)

Like robert Frank proposed something like the nsswitch.conf ???

while we brainstrom, why not an SQL backend ?

> > The main thing we have to decide is what schema gets
> > mapped into the 'struct smb_passwd' that is returned
> > by these functions. It needs to be a superset of all
> > the desired schema - with reasonable defaults returned
> > for systems that do not store all the data (the current
> > smbpasswd file for instance).
> 
> We also need to define the minimum set.  What *must* the underlying schema
> or schemes be able to handle.

That's the big dilema I currently have :) An as much as complete schema
with a minimal requirement plugable in an existing schema for people
already having one...

> I think we're on the right track here.

yep, but does samba really need to communicate with some specific backend ? 

How many sites will use this kind of feature ? Does in the past people
have asked for such features ?

>   * Samba could have it's own *authoritative* list, and also (optionally!)
>     copy changes out to other databases (inc., LDAP, the WINS.DAT file,
>     whatever).  Changes made directly to these outside databases would
>     *not* be sent back to Samba.
> 
> --or--
> 
>   * Do we want to allow changes to the outside database back in to Samba?

If I understood what luke told me, he wants such a feature.

> For WINS, I'm not sure (except that we already allow the WINS.DAT to be
> modified while Samba is down--and then it's loaded back in).  The
> configuration information is a different story.  In that case, the goal is
> to provide for input more than for output.
> 
> What about passwords?
> 
> I think we may need to identify all of the data to which we would like to
> provide external access.  So far I have the password database, the 
> configuration database, and the WINS database.  What else?

the groups, the user mapping, the printers definition file, 

I certainly forgot other important ones.

	Jean Francois

-----------------------------------------------------------
: Jean Francois Micouleau       : Email: jfm at utc.fr       :
: Universite de                 : Tel  : 03 44 23 47 78   :
: Technologie de                :  Service Informatique   :
: Compiegne              France :     Division IRNM       :
-----------------------------------------------------------