Hi everyone.
I'm working on an eDir-to-eDir driver in our test environment and have the basics up and running. However, I am having issues with a policy I wrote to prevent users from being moved around. What I am trying to do is detect when a user object is moved to a different container in the connected tree and then move the object back to where it was. Essentially, prevent people from moving associated users around.
My test environment consists of three servers. One hosts the IDM tree and IDM engine. The other two are in the CSCC tree, one of which has the IDM engine installed. See this diagram: http://i.imgur.com/sheUe.png.
So, I wrote the following policy and added it to the command transformation set in the publisher channel on the vault's eDir driver (that's a mouthful :P).
And it works. When I move an associated user in the CSCC tree to another container the policy moves it right back. However, while doing a level 3 trace I found that a retry is being sent back from the CSCC driver, causing IDM to continuously retry the operation. Below is a snippet from the trace.
Some research suggested that this is being caused by stuck obituaries from the move operation. I used ndsrepair to check for obits on cscc2:
I also ran ndstrace with the OBIT flag on cscc2 and found this:
So it looks like stuck obits are indeed the problem. However, I don't see these on cscc1 (which may be normal for all I know). Unfortunately I'm at the limit of my knowledge of eDirectory. Perhaps IDM moved the object back before the obituaries from the original moved had been processed? Or maybe this is indicitive of a replication problem between the two CSCC servers?
Does anyone have any suggestions on how to deal with this? Would somehow introducing a delay between the moves help?
I'm working on an eDir-to-eDir driver in our test environment and have the basics up and running. However, I am having issues with a policy I wrote to prevent users from being moved around. What I am trying to do is detect when a user object is moved to a different container in the connected tree and then move the object back to where it was. Essentially, prevent people from moving associated users around.
My test environment consists of three servers. One hosts the IDM tree and IDM engine. The other two are in the CSCC tree, one of which has the IDM engine installed. See this diagram: http://i.imgur.com/sheUe.png.
So, I wrote the following policy and added it to the command transformation set in the publisher channel on the vault's eDir driver (that's a mouthful :P).
Code:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE policy PUBLIC "policy builder-dtd" "/opt/novell/idm/Designer/plugins/com.novell.idm.policybuilder_4.0.0.201105171813/DTD/dirxmlscript4.0.1.dtd">
<policy>
<rule>
<conditions>
<or>
<if-class-name mode="nocase" op="equal">User</if-class-name>
</or>
<or>
<if-operation op="equal">move</if-operation>
</or>
<!-- TODO: Do we need to check if this is an associated object? -->
</conditions>
<actions>
<do-move-src-object>
<arg-dn>
<token-parse-dn src-dn-format="src-dn" dest-dn-format="src-dn" start="0" length="-1">
<token-xpath expression="@old-src-dn"/>
</token-parse-dn>
</arg-dn>
</do-move-src-object>
<do-veto/>
</actions>
</rule>
</policy>Code:
eDirectory (CSCC) ST:
DirXML Log Event -------------------
Driver: \IDM\IDM\Driver Sets\Driver Set 1\eDirectory (CSCC)
Channel: Subscriber
Status: Retry
Message: Code(-9006) The driver returned a "retry" status indicating that the operation should be retried later. Detail from driver: Code(-9011) eDirectory returned an error indicating that the operation should be retried later: novell.jclient.JCException: moveEntry -637 ERR_PREVIOUS_MOVE_IN_PROGRESS<application>DirXML</application>
<module>Identity Vault</module>
<object-dn>IDM\Data\Users\deansa (\CSCC\CSCC\Groups\deansa)</object-dn>
<component>Publisher</component>Code:
cscc2:~ # ndsrepair -C -Ad -A
[1] Instance at /etc/opt/novell/eDirectory/conf/nds.conf: cscc2.OU=Servers.O=CSCC.CSCC
Repair utility for Novell eDirectory 8.8 - 8.8 SP6 V20601.07
DS Version 20601.18 Tree name: CSCC
Server name: .cscc2.Servers.CSCC
Size of /var/opt/novell/eDirectory/log/ndsrepair.log = 7699 bytes.
Preparing Log File "/var/opt/novell/eDirectory/log/ndsrepair.log"
Please Wait...
External Reference Check
External Reference Check
Start: Wednesday, February 08, 2012 14:07:19 Local Time
(1) Found obituary for: EID: 0000d4c4, DN: CN=deansa.OU=Groups.O=CSCC.T=CSCC
Value CTS : 02-08-2012 14:07:14 R = 0001 E = 0049
Value MTS = 02-08-2012 14:07-14 R = 0001 E = 0049, Type = 0002 MOVED,
Flags = 0000
MoveObit: destID = 0000d3c6, CN=deansa.OU=Departments.O=CSCC.T=CSCC
(2) Found obituary for: EID: 0000d4c4, DN: CN=deansa.OU=Groups.O=CSCC.T=CSCC
Value CTS : 02-08-2012 14:07:14 R = 0001 E = 004a
Value MTS = 02-08-2012 14:07-16 R = 0001 E = 0004, Type = 0006 BACKLINK,
Flags = 0001,
NOTIFIED
Backlink: Type = 00000002 MOVED, RemoteID = ffffffff,
ServerID = 00008021, CN=cscc2.OU=Servers.O=CSCC.T=CSCC
(3) Found obituary for: EID: 0000d3c6, DN: CN=deansa.OU=Departments.O=CSCC.T=CSCC
Value CTS : 02-08-2012 14:07:14 R = 0001 E = 0032
Value MTS = 02-08-2012 14:07-14 R = 0001 E = 0032, Type = 0003 INHIBIT_MOVE,
Flags = 0000
Checked 0 external references
Found: 3 total obituaries in this DIB,
2 Unprocessed obits, 0 Purgeable obits,
0 OK_To_Purge obits, 1 Notified obits
Total errors: 0
NDSRepair process completed.Code:
cannot purge primary obit 2012/02/08 14:20:11, 1, 73 on [0000d4dc] <.deansa.Groups.CSCC.CSCC.>Does anyone have any suggestions on how to deal with this? Would somehow introducing a delay between the moves help?