Re: Major new ubiqx release

Jean-Francois Micouleau (Jean-Francois.Micouleau@utc.fr)
Wed, 22 Apr 1998 00:23:10 +0200 (MET DST)

Date:	Wed, 22 Apr 1998 00:23:10 +0200 (MET DST)
From:	Jean-Francois Micouleau <Jean-Francois.Micouleau@utc.fr>
To:	"Christopher R. Hertel" <crh@NTS.Umn.EDU>
Subject: Re: Major new ubiqx release
In-Reply-To: <199804211552.KAA24056@unet.unet.umn.edu>

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@utc.fr :
: Universite de : Tel : 03 44 23 47 78 :
: Technologie de : Service Informatique :
: Compiegne France : Division IRNM :
-----------------------------------------------------------