s4 provision with ol fails (bugzilla.samba 7040?)
Oliver Liebel
oliver at itc.li
Wed Mar 3 03:48:18 MST 2010
and the next one (only ol 2.4.21):
i have temporarily adjusted the rids in provisionbackend.py to 500+ to
test ist again.
if --ol-mmr-urls are commited during provision, slapd fails to startup:
#> setup/provision --realm=ldap.local.site --domain=LDAP
--server-role='domain controller' --ldap-backend-type=openldap
--username=samba-admin --password=linux --adminpass=linux
--ldapadminpass=linux --slapd-path='/usr/local/libexec/slapd'
--domain-sid=S-1-5-4444
--ol-mmr-urls="ldap://samba4dc1.ldap.local.site:9000
ldap://samba4dc2.ldap.local.site:9000"
----
slap_startup failed (test would succeed using the -u switch)
Failed to bind - LDAP client internal error:
NT_STATUS_UNEXPECTED_NETWORK_ERROR
Failed to connect to
'ldapi://%2Fusr%2Flocal%2Fsamba%2Fprivate%2Fldap%2Fldapi'
Traceback (most recent call last):
File "setup/provision", line 245, in <module>
nosync=opts.nosync,ldap_dryrun_mode=opts.ldap_dryrun_mode,useeadb=eadb)
File "bin/python/samba/provision.py", line 1267, in provision
provision_backend.start()
File "bin/python/samba/provisionbackend.py", line 238, in start
raise ProvisioningError("slapd died before we could make a
connection to it")
samba.provisionexceptions.ProvisioningError: slapd died before we could
make a connection to it
----
greetings
oliver
Am 03.03.2010 11:20, schrieb Oliver Liebel:
> sorry, i have to correct my last statement:
> provision works now with kamens ldb_ildap.c patch,
> tested it against ol 2.4.18 and 2.4.21.
> seems my VM was somehow corrupted.
>
>
> but there are more things to fix:
>
> mmr-provision wont work anymore with ol > 2.4.20 according to
> ITS#6394 (Fixed slapd RID range to be decimal only);
> means in short: ol > 2.4.20 only allows rids with 3 digits to prevent
> buffer overflows.
> since we had caclulated the rids during mmr-prov with 4 digits
> (starting from 1000),
> it fails.
>
> ---
> /usr/local/samba/private/ldap/slapd.conf: line 433: Error:
> parse_syncrepl_line: syncrepl id 1001 is out of range [0..999].
> failed to add syncinfo
> slaptest: bad configuration directory!
> Traceback (most recent call last):
> File "setup/provision", line 245, in <module>
>
> nosync=opts.nosync,ldap_dryrun_mode=opts.ldap_dryrun_mode,useeadb=eadb)
> File "bin/python/samba/provision.py", line 1266, in provision
> provision_backend.init()
> File "bin/python/samba/provisionbackend.py", line 213, in init
> self.provision()
> File "bin/python/samba/provisionbackend.py", line 531, in provision
> raise ProvisioningError("conversion from slapd.conf to cn=config
> failed")
> samba.provisionexceptions.ProvisioningError: conversion from
> slapd.conf to cn=config failed
>
> ----
> another point: after mmr-provision (2.4.18) the displayed helpline
> (how to start slapd
> from commandline) only shows ldapi, not the needed
> external url commited during provision. this should be
> appended, as mmr wont work with ol and ldapi only.
>
>
>
> thanks
> oliver
>
>
>
>
>
> Am 03.03.2010 08:53, schrieb Oliver Liebel:
>> as endi said, there must be still other problems.
>> i have tried it with the patch from kamen, but provision still fails:
>>
>> Traceback (most recent call last):
>> File "setup/provision", line 245, in <module>
>>
>> nosync=opts.nosync,ldap_dryrun_mode=opts.ldap_dryrun_mode,useeadb=eadb)
>> File "bin/python/samba/provision.py", line 1305, in provision
>> dom_for_fun_level=dom_for_fun_level)
>> File "bin/python/samba/provision.py", line 942, in setup_samdb
>> samdb.add_ldif(schema.schema_data, controls=["relax:0"])
>> File "bin/python/samba/__init__.py", line 258, in add_ldif
>> self.add(msg,controls)
>> _ldb.LdbError: (3, 'error in module acl: Time limit exceeded (3)')
>> A transaction is still active in ldb context [0x944ecf0] on
>> /usr/local/samba/private/secrets.ldb
>>
>>
>> greetings
>> oliver
>>
>> Am 03.03.2010 02:20, schrieb Endi Sukma Dewata:
>>> Hi Kamen,
>>>
>>> The patch seems to have fixed this particular problem. There are
>>> still other problems which I will investigate, but I don't think
>>> they are related to this. Thanks a lot!
>>>
>>> --
>>> Endi S. Dewata
>>>
>>>
>>> ----- "Kamen Mazdrashki"<kamen.mazdrashki at postpath.com> wrote:
>>>
>>>> Hi Endi,
>>>>
>>>> Attached patch should fix the problem you have encountered
>>>> (thanks a lot for that).
>>>> I have implemented it wrong - I haven't noticed that
>>>> ildb_context is to be freed when a request is marked as 'done'.
>>>>
>>>> Could you please try if that works for you?
>>>>
>>>> --
>>>> CU,
>>>> Kamen Mazdrashki
>>>> kamen.mazdrashki at postpath.com
>>>> http://repo.or.cz/w/Samba/kamenim.git
>>>> -------------------------------------
>>>> CISCO SYSTEMS BULGARIA EOOD
>>>> http://www.cisco.com/global/BG/
>>>>
>>>>
>>>>> -----Original Message-----
>>>>> From: samba-technical-bounces at lists.samba.org
>>>> [mailto:samba-technical-
>>>>> bounces at lists.samba.org] On Behalf Of Endi Sukma Dewata
>>>>> Sent: Wednesday, March 03, 2010 2:03 AM
>>>>> To: abartlet at samba.org
>>>>> Cc: samba-technical at lists.samba.org
>>>>> Subject: Re: s4 provision with ol fails (bugzilla.samba 7040?)
>>>>>
>>>>> Andrew,
>>>>>
>>>>> Here's the valgrind trace. As you can see the write on ldb_ildap.c
>>>>> line 391 triggers the error. The earlier read& write on line 231
>>>>> and 235 didn't cause any problem.
>>>>>
>>>>> ==18041== Invalid write of size 1
>>>>> ==18041== at 0x4AF4536: ildb_callback (ldb_ildap.c:391)
>>>>> ==18041== by 0x4AF5B8B: ldap_match_message (ldap_client.c:177)
>>>>> ==18041== by 0x4AF5CB5: ldap_recv_handler (ldap_client.c:209)
>>>>> ==18041== by 0x4BB53E4: packet_recv (packet.c:414)
>>>>> ==18041== by 0x4AF5D1E: ldap_read_io_handler (ldap_client.c:221)
>>>>> ==18041== by 0x4AF5DA0: ldap_io_handler (ldap_client.c:237)
>>>>> ==18041== by 0x5022051: epoll_event_loop (tevent_standard.c:309)
>>>>> ==18041== by 0x50226E8: std_event_loop_once
>>>> (tevent_standard.c:544)
>>>>> ==18041== by 0x501E750: _tevent_loop_once (tevent.c:497)
>>>>> ==18041== by 0x4AC5136: ldb_wait (ldb.c:578)
>>>>> ==18041== by 0x4ABF4C3: py_ldb_modify (pyldb.c:706)
>>>>> ==18041== by 0x568B059: PyCFunction_Call (methodobject.c:81)
>>>>> ==18041== by 0x56E7072: PyEval_EvalFrameEx (ceval.c:3706)
>>>>> ==18041== by 0x56E8E49: PyEval_EvalCodeEx (ceval.c:2968)
>>>>> ==18041== by 0x56E7297: PyEval_EvalFrameEx (ceval.c:3802)
>>>>> ==18041== by 0x56E8E49: PyEval_EvalCodeEx (ceval.c:2968)
>>>>> ==18041== by 0x56E7297: PyEval_EvalFrameEx (ceval.c:3802)
>>>>> ==18041== by 0x56E8E49: PyEval_EvalCodeEx (ceval.c:2968)
>>>>> ==18041== by 0x56E7297: PyEval_EvalFrameEx (ceval.c:3802)
>>>>> ==18041== by 0x56E8E49: PyEval_EvalCodeEx (ceval.c:2968)
>>>>> ==18041== Address 0xe553490 is 64 bytes inside a block of size 72
>>>>> free'd
>>>>> ==18041== at 0x40057F6: free (vg_replace_malloc.c:325)
>>>>> ==18041== by 0x502445C: _talloc_free_internal (talloc.c:669)
>>>>> ==18041== by 0x502436B: _talloc_free_internal (talloc.c:631)
>>>>> ==18041== by 0x502436B: _talloc_free_internal (talloc.c:631)
>>>>> ==18041== by 0x502436B: _talloc_free_internal (talloc.c:631)
>>>>> ==18041== by 0x502436B: _talloc_free_internal (talloc.c:631)
>>>>> ==18041== by 0x502436B: _talloc_free_internal (talloc.c:631)
>>>>> ==18041== by 0x502436B: _talloc_free_internal (talloc.c:631)
>>>>> ==18041== by 0x502436B: _talloc_free_internal (talloc.c:631)
>>>>> ==18041== by 0x502436B: _talloc_free_internal (talloc.c:631)
>>>>> ==18041== by 0x502436B: _talloc_free_internal (talloc.c:631)
>>>>> ==18041== by 0x502436B: _talloc_free_internal (talloc.c:631)
>>>>> ==18041== by 0x502436B: _talloc_free_internal (talloc.c:631)
>>>>> ==18041== by 0x502436B: _talloc_free_internal (talloc.c:631)
>>>>> ==18041== by 0x502436B: _talloc_free_internal (talloc.c:631)
>>>>> ==18041== by 0x502436B: _talloc_free_internal (talloc.c:631)
>>>>> ==18041== by 0x502436B: _talloc_free_internal (talloc.c:631)
>>>>> ==18041== by 0x502436B: _talloc_free_internal (talloc.c:631)
>>>>> ==18041== by 0x502509E: _talloc_free (talloc.c:1133)
>>>>> ==18041== by 0x4AF0C62: extended_replace_dn
>>>>> (extended_dn_store.c:138)
>>>>>
>>>>> If I remove talloc_free() in extended_dn_store.c line 138 and rerun
>>>>> valgrind the problem will still happen and the trace will point to
>>>>> another talloc_free() on line 197. If I remove both of them the
>>>> problem
>>>>> will disappear. Thanks.
>>>>>
>>>>> --
>>>>> Endi S. Dewata
>>>>>
>>>>>
>>>>> ----- "Andrew Bartlett"<abartlet at samba.org> wrote:
>>>>>
>>>>>> On Tue, 2010-03-02 at 18:01 -0500, Endi Sukma Dewata wrote:
>>>>>>> Andrew, Oliver,
>>>>>>>
>>>>>>> It seems like the in_ildb_callback field added in this
>>>> revision:
>>>>>>>
>>>>>> http://gitweb.samba.org/?p=samba.git;a=commitdiff;
>>>>> h=80786148145e128c961a6f80a05585a17dfca63b
>>>>>>> was causing the problem. Valgrind indicates that it's trying to
>>>>>> write
>>>>>>> into a memory location was already freed by talloc_free() in
>>>>>>> extended_dn_store.c line 138 and 197. If I remove those
>>>>>> talloc_free()
>>>>>>> the problem will disappear. Any idea? Thanks.
>>>>>> Can you post the valgrind trace? (So I can see what write is
>>>>>> invalid).
>>>>>>
>>>>>> (BTW, well done in tracking this down)
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> Andrew Bartlett
>>>>>> --
>>>>>> Andrew Bartlett
>>>>>> http://samba.org/~abartlet/
>>>>>> Authentication Developer, Samba Team http://samba.org
>>>>>> Samba Developer, Cisco Inc.
>>>
>>
>>
>>
>
>
More information about the samba-technical
mailing list