Simplifying the multiple password backend code in HEAD and 3.0.
abartlet at samba.org
Wed Oct 2 00:42:01 GMT 2002
jra at dp.samba.org wrote:
> Spurred on by some complaints in IRC :-) I took a look at the passdb
> backend code in HEAD and 3.0.
So I see... Must remember never to sleep...
> 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 ?
The cascaded stuff was added because I felt it could be useful - and
ctrlsoft wrote a patch the used the existing code to maximal advantage.
Then, I took this work further and used it to help keep the issue of
'unix accounts not in the sam' (and their matching rids) at bay.
Personally, I like the idea of abstraction, where this special case is
dealt with in a module, rather than in the interface. This appears to
be contrary to the fundamental design philosophies of others :-(
> 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.
I'm not sure what you mean here, but it sounds like a really bad idea...
I much prefer a relatively sane (yes, it has it's problems) interface
that all backends can implement without difficulty.
> 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.
Well, how do you propose to make it 'harder'. It really is just export
and change an option, and I think that is a good thing.
> Comments welcome..... but I do want to start cutting out some of
> this code soon.
Yes, well while the current design has it's problems, I do think that it
provides a solid base to move into 3.0. (vl has a patch for it that I
think does some nice stuff too, without pulling it apart too far).
Andrew Bartlett abartlet at pcug.org.au
Manager, Authentication Subsystems, Samba Team abartlet at samba.org
Student Network Administrator, Hawker College abartlet at hawkerc.net
http://samba.org http://build.samba.org http://hawkerc.net
More information about the samba-technical