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