Simplifying the multiple password backend code in HEAD and 3.0.

Jelmer Vernooij jelmer at nl.linux.org
Tue Oct 1 22:24:01 GMT 2002


On Tue, Oct 01, 2002 at 09:49:53PM +0000, jra at dp.samba.org wrote about 'Simplifying the multiple password backend code in HEAD and 3.0.':
> Spurred on by some complaints in IRC :-) I took a look at the passdb
> backend code in HEAD and 3.0.
> 
> It looks nice, but it's horribly complex for what it needs to do
> (IMHO). Is there any real reason to have multiple possible backends
> simultaneously in a cascaded interface ?
> 
> I can see the benefits of a plug-in architecture to allow different
> backends to be tested, but what we need is to do *one* good backend
> implementation (my vote would be for an LDAP one) and then use that
> to implement others - modfying the interfaces as needed to support
> any idiosyncracies that come out of the different backends.
> 
> If someone wants to change from one backend to another a decent
> export_all/import_all interface method is all we need (probably
> using the enumerate methods). Changing backends is a major thing
> to do (IMHO) as it means moving data between different databases,
> and I'm worried that the existing code makes it look as though you
> can just change a parameter and have it happen automatically.
> 
> Comments welcome..... but I do want to start cutting out some of
> this code soon.
I originally wrote this code, but I agree. Having multiple backends can be useful some 
times (I used such a configuration at my school - saving machine accounts in tdbsam,
students accounts in a mysql db and teacher accounts in another mysql db - thus 
not having to modify any student administration tools or php scripts that used 
these tables as well). 

Multiple passdb backends should be supported in a seperate passdb backend. A plugin possibly.
That's exactly the way we will implement it in sam as well. Currently we don't do 
any checking on whether a user exists in more than one database (in getpwnam for example), 
and there are more like problems.

Jelmer



More information about the samba-technical mailing list