Failed to get name_resolve_order via s3 lpcfg wrapper and improving s3 ldap import
abartlet at samba.org
Sun Jul 15 17:43:24 MDT 2012
On Sun, 2012-07-15 at 09:00 +0200, Gémes Géza wrote:
> 2012-07-14 13:26 keltezéssel, Andrew Bartlett írta:
> > On Sat, 2012-07-14 at 13:13 +0200, Gémes Géza wrote:
> >> 2012-07-14 12:10 keltezéssel, Andrew Bartlett írta:
> >>> On Sat, 2012-07-14 at 09:35 +0200, Gémes Géza wrote:
> >>>> Hi,
> >>>> Unfortunately you lose. It is running without problem, except the
> >>>> ldb=samDB line and below (which is part of a function called for every
> >>>> user to be migrated). The only (seems to be a red herring) error message
> >>>> is at the beginning of the execution: no talloc stackframe around,
> >>>> leaking memory
> >>>> and valgrind reports lots of memory leaks in (seems to be) unrelated
> >>>> functions, but tested with a pristine upgrade.py and the situation seems
> >>>> to be the same.
> >>> Perhaps at this point send me the patch and I'll see what I can do to
> >>> help out.
> >>> Andrew Bartlett
> >> Hi,
> >> Now with import (in upgrade.py) of SamDB and system_session it gets even
> >> more interesting. Now it fails.
> >> Under gdb it produces:
> >> Starting program: /usr/bin/python /usr/local/samba/bin/samba-tool domain
> >> classicupgrade --dbdir=/tmp/samba_tdb/ --use-xattrs=yes
> >> --realm=KZSDABAS.HU /tmp/smb.conf.reg
> >> [Thread debugging using libthread_db enabled]
> >> Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
> >> no talloc stackframe around, leaking memory
> >> Reading smb.conf
> >> Provisioning
> >> Exporting account policy
> >> Exporting groups
> >> Exporting users
> >> PANIC: assert failed at ../lib/param/loadparm.c(1540):
> >> lp_ctx->s3_fns->name_resolve_order
> >> PANIC (pid 2513): assert failed: lp_ctx->s3_fns->name_resolve_order
> > Thanks, that gives me the detail I need. I'll see what I can do to fix
> > that up, it's a limitation in the loadparm system. However, you can
> > work around this limitation.
> > In this case, there are two different loadparm contexts that are valid.
> > instead of
> > lp=samba3.lp
> > use
> > lp=result.lp
> > (where result is the result of provision). Also, don't open the ldap DB
> > on each entry, open it once before starting the iteration and re-use the
> > handle.
> > Also, use Ldb not SamDB (as this isn't a AD-like database).
> > I hope this helps,
> > Andrew Bartlett
> I've basically completed the transition from SamDB to Ldb and from
> samba3.lp result.lp, the upgrade doesn't segfaults, but it doesn't work
> either :-(
> Failed to bind - LDAP client internal error: NT_STATUS_INVALID_PARAMETER
> Failed to connect to 'ldap://192.168.122.100' with backend 'ldap': (null)
Again, can you post your failing script, so I can look over it?
> My question: would it be too unorthodox to use python-ldap insted of ldb
> to retrieve the posix attrs?
Yes, we need to use ldb. The reason is that this script runs in make
test, and so if we were to use an extra python package outside the
standard distribution, we would need to bundle a copy (we do that for a
DNS package already).
Andrew Bartlett http://samba.org/~abartlet/
Authentication Developer, Samba Team http://samba.org
More information about the samba-technical