Wrong usage of lp_idmap_backend() value?
abartlet at samba.org
Thu Jul 3 08:01:40 GMT 2003
On Thu, 2003-07-03 at 17:49, Simo Sorce wrote:
> On Thu, 2003-07-03 at 07:45, Stefan (metze) Metzmacher wrote:
> > At 05:34 03.07.2003 +0000, Jeremy Allison wrote:
> > >On Thu, Jul 03, 2003 at 07:31:16AM +0200, Stefan (metze) Metzmacher wrote:
> > > > At 18:09 02.07.2003 +0000, Jeremy Allison wrote:
> > > > >On Wed, Jul 02, 2003 at 07:16:30PM +0300, Alexander Bokovoy wrote:
> > > > > > Greetings!
> > > > > >
> > > > > > In smbd/server.c we are supposed to use value of 'idmap backend'
> > > option to
> > > > > > initialize idmap but code logic is different: it decides to override
> > > > > > everything in 'idmap backend' by 'winbind' unless 'idmap backend'
> > > is empty
> > > > > > in which case we supply NULL as argument to idmap_init().
> > > > >
> > > > >It's on purpose. smbd should only talk to winbindd as a
> > > > >remote backend. winbindd can talk to the configured backends.
> > > >
> > > > This is very bad!
> > > >
> > > > I think it have to be possible to use
> > > > passdb backend = ldapsam
> > > > idmap backend = ldap
> > > >
> > > > without using winbind!!!
> > > > (I'm using nss_ldap)
> > >
> > >The problem with this is it causes many smbd connections to
> > >ldap and has been reported to overload ldap servers. Funelling
> > >everything via winbindd prevents this problem.
> > Ok, this is a problem...
> Well sorry, but, first of all, you're on the wrong route.
> Running winbind doesn't mean you need necessarily to run nss_winbind or
> pam_winbindd, or use only them.
> You may continue to use nss_ldap or even nss_ldap+nss_winbind i think.
> > I think we should let pdb_ldap and idmap_ldap
> > register an idle event that close an idle connection.
> > (time out 60 sec should ok here)
> NO, it may add too big delays in smbd code imho, and really makes no
> sense, winbind can maintain a single connection and answer all the
> queries from smbd effectiely, think at winbindd as a proxy.
This is a different matter - having an idle even for pdb_ldap is sane.
I'm not sure it should be 60 secs, but certainly we should do it after 5
mins or the like.
> > because this connections are not often used
> > because normal idmap lookups should be handle by the local tdb...
> yes, most mapping will be dealt locally.
> > and pdb_ldap is only used on connection startup
> > and on using something like usrmgr.exe
> > and the connection is only used for a view mins.
> > I think the following should be possible
> > idmap backend = ldap:ldaps://ldapserver.domain
> > (means smbd directly used ldap as remote backend
> > and winbind used also ldap as remote backend)
> > and
> > idmap backend = winbind:ldap:ldaps://ldapserver.domain
> > (means smbd used winbind as remote backend
> > and winbind uses ldap as remote backend
> > so smbd uses winbind as proxy for the ldap remote idmap backend)
> NO, this makes the code a mess and it is really a waste of time.
> I really think that makind winbind the ldap proxy is the right way to
> go, even for pdb_ldap.
I'm not sure on this. I think that making winbind do everything just
searialises the entire server - and that just kills performance.
IDMAP is a different beast in this regard, due to the way it's mostly
read, and has a tdb cache.
> And also I do not understand why you should specify ldap parameters
> twice, once for pdb and once for idmap.
> You cannot use 2 different ldap servee for them.
> I think we really should merge pdb_ldap and idmap_ldap code so that they
> use the same parameters (except for idamp base dn perhaps), and make all
> queries go through winbindd.
The problem is that we want to run idmap_ldap without pdb_ldap (for
winbind distributed IDMAP).
But yes - we need a way to make this foolproof.
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.samba.org/archive/samba-technical/attachments/20030703/c4dfb919/attachment.bin
More information about the samba-technical