Major new ubiqx release
Christopher R. Hertel
crh at NTS.Umn.EDU
Tue Apr 21 15:52:03 GMT 1998
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!
> 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!)
> 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.
I think we're on the right track here.
Chris -)-----
PS. A lot of my thinking on this is related to my thoughts on the WINS
database. When I started thinking about swappable database modules for
WINS, I came up with the ubiqx database stuff. It was a RGI (really good
idea) and I'm glad I wrote the stuff because I learned a bigbunch. On the
other hand...
The interface in Samba needs to be a bit different. In Samba, we have
specific data structures and we'd like to be able to store them in any
number of underlying systems. The specificity is significant. Let's say,
for example, that we want to use Oracle or LDAP as a back-end. In doing
so, we'll really *want* to know the structure of the data so that we can
read it from the database interface. That in mind, the packed Datum
format used in the ubiqx modules is *not* appropriate. Instead, I'm
thinking that I'll re-use the code a bit but build a different tool.
Chaining is going to be important here. The WINS database, for example,
is something we'll want to store in more than one way. Here's where it
gets trickty:
* 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?
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?
--
Christopher R. Hertel -)----- University of Minnesota
crh at nts.umn.edu Networking and Telecommunications Services
More information about the samba-technical
mailing list