s4 provision with ol fails (bugzilla.samba 7040?)
Oliver Liebel
oliver at itc.li
Wed Mar 3 03:20:06 MST 2010
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