solving cleanly the wrong storage of DNs on non linked attribute

Matthieu Patou mat at
Thu Jun 23 15:19:36 MDT 2011

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
+"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.

What do you think of this ?


Matthieu Patou
Samba Team
Private repo;a=summary

More information about the samba-technical mailing list