Samba4 patch for manipulating Unix attributes via ADUC

[Gémes Géza]

2012-07-14 08:22 keltezéssel, Andrew Bartlett írta:
> On Sat, 2012-07-14 at 08:14 +0200, Gémes Géza wrote:
>> 2012-07-14 01:09 keltezéssel, Andrew Bartlett írta:
>>> On Fri, 2012-07-13 at 22:05 +0200, Gémes Géza wrote:
>>>> 2012-07-13 07:50 keltezéssel, Andrew Bartlett írta:
>>>>> On Fri, 2012-07-13 at 07:30 +0200, Gémes Géza wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> Sorry for being annoying, but what is your opinion about the patch? Is
>>>>>> there anything you would recommend changing?
>>>>>> For simplicity I've reattached the patch.
>>>>>>
>>>>>> Cheers
>>>>>>
>>>>>> Geza
>>>>> The patch is in autobuild.  Indeed, if it had not hit a flaky test (s3dc
>>>>> failed the samr.large-dc test, which is unrelated and quite unusual), it
>>>>> would be in master by now.
>>>>>
>>>>> There is nothing I find more uplifting than enthusiastic developers who
>>>>> are ready and willing to provide tested patches the solve real-world
>>>>> problems.
>>>>>
>>>>> Thanks so very much for your hard work, and I look forward to seeing
>>>>> your patches for the improved s3 migration!
>>>>>
>>>>> Andrew Bartlett
>>>>>
>>>> Thank you for your kindness with me.
>>>>
>>>> I still have to sort out some problems with the migration patch.
>>>> What is your opinion shall we set the
>>>> msSFU30MaxUidNumber/msSFU30MaxGidNumber attributes to the current
>>>> maximum uidnumber/gidnumber + 1?
>>>> Or leave that attrs for now?
>>> I looked to see what precedent we could follow.  The ldapsam:editposix
>>> behaviour is to ask winbind for an id from the idmap pool at runtime,
>>> but that won't help us specify a fixed base for these attributes.
>>>
>>> I don't like just leaving this, particularly if it defaults to 10000 in
>>> the GUI (as then we have no control, and we might know that 10000 is
>>> unsuitable), but I would like time to think about this more before we
>>> put this into the provision.
>>>
>>> Thanks,
>>>
>>> Andrew Bartlett
>>>
>> Hi,
>>
>> First, I interpret your answer as the following (correct me if I'm wrong):
>>
>> In the case of classicupgrade populate the
>> msSFU30MaxUidNumber/msSFU30MaxGidNumber attributes
> I actually meant the opposite.  For now, don't populate them ever, while
> I keep thinking about what the right thing to do is.
>
>> Second, sorry for whining, but I'm simply too stupid to see the problem
>> with the following code:
>>
>> urls = samba3.lp.get("passdb backend").split(":",1)[1].strip('"')
>> res = None
>> for url in urls.split():
>>       print "URL OK: "+url+"!"
>>       ldb = SamDB(url, session_info=system_session(samba3.lp),
>> credentials=creds, lp=samba3.lp)
>>       print "ldb OK!"
>>       domain_dn = ldb.domain_dn()
>>       try:
>>           res = ldb.search(domain_dn, scope=ldb.SCOPE_SUBTREE,
>> expression=("(&(objectClass=posixAccount)(uid=%u))"
>>                                      % (user)), attrs=[attr])
>>       except LdbError:
>>           continue
>>       if res != None:
>>           return res
>>       else:
>>           continue
>>
>> The prints are for debugging. The only thing I can get of it is th url
>> part. "ldb OK!" never gets printed, neither any error message. So I
>> don't know what could happen in the ldb = SamDB(... part. the url is
>> checked, the credentials part is initialized with the ldap admin dn and
>> the corresponding password from secrets.tdb, also checked. I'm simply
>> out of ideas.
> Run the script under gdb or valgrind.  I bet it's crashing.
> eg
> gdb --args python /usr/local/samba/sbin/samba-tool domain classicupgrade
>
> valgrind python /usr/local/samba/sbin/samba-tool domain classicupgrade
>
> This may give some clues.
>
> Andrew Bartlett
>
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.

Cheers

Geza