solving cleanly the wrong storage of DNs on non linked attribute

[Matthieu Patou]

Hi All,


> Hello Tridge, Andrew,
>
> On Wednesday, you tried to push this:
>
> +    # the way we construct the database leaves some DN links without 
> GUIDs. This
> +    # is a easy way to fix them
> +    logger.info("Fixing schema GUIDs")
> +    samdb.transaction_start()
> +    chk = dbcheck(samdb, verbose=False, fix=True, yes=True, quiet=True)
> +    chk.check_database(DN=None, scope=ldb.SCOPE_SUBTREE,
> +                       controls=["search_options:1:2"],
> +                       attrs=['objectCategory',
> +                              'defaultObjectCategory',
> +                              'ipsecFilterReference',
> +                              'ipsecISAKMPReference',
> +                              'ipsecNegotiationPolicyReference',
> +                              'ipsecNFAReference',
> +                              'ipsecOwnersReference'])
> +    samdb.transaction_commit()
>
> So far it fails for some very strange reasons.
>
> In anycase, I was working on my pseudobacklinks today and realized 
> that with my patches most of the problem for this DN would go away as 
> I used to have a patch for reordering the ipsec* object creation (I 
> already did it on other attributes like fsmo), only objectCategory and 
> defaultObjectCategory were left.
>
> I realized that handling correctly this attribute was in fact very 
> similar to what I do with pseudobacklink attributes, that is to say 
> when the request for  add or update arrive on this object the value 
> can or can not have extended information, pretty much like the pointed 
> DN exists or do not exists.
> When it doesn't exists we wait up to the moment when will create the 
> pseudobacklink (that is to say in the commit) to check if it really 
> exists or not (this is needed because when you replicated from another 
> DC, attributes that are with DN syntax but that are not linked 
> attributes you are not sure that the request for adding/changing the 
> value will come after the creation of the pointed DN ...).
> So the idea is to check that if the DN (the "pseudoforwardlink" that 
> we are about to store), does have extended component, if not then we 
> put it's name, the value and the name of the object in a list and on 
> commit we retrieve the DN and restore it with extended DN infos.
>
So I pushed a patch in my pseudobacklinks branch for this.
It works pretty well as now samba-tool dbcheck --cross-ncs on a fresh 
provision didn't generate any error !

Matthieu.

-- 
Matthieu Patou
Samba Team        http://samba.org
Private repo      http://git.samba.org/?p=mat/samba.git;a=summary