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).


<?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">
<if-class-name mode="nocase" op="equal">User</if-class-name>
<if-operation op="equal">move</if-operation>
<!-- TODO: Do we need to check if this is an associated object? -->
<token-parse-dn src-dn-format="src-dn" dest-dn-format="src-dn" start="0" length="-1">
<token-xpath expression="@old-src-dn"/>


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.


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>


Some research suggested that this is being caused by stuck obituaries
from the move operation. I used ndsrepair to check for obits on cscc2:


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,

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.


I also ran ndstrace with the OBIT flag on cscc2 and found this:


cannot purge primary obit 2012/02/08 14:20:11, 1, 73 on [0000d4dc] <.deansa.Groups.CSCC.CSCC.>


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?

andrewgd's Profile: http://forums.novell.com/member.php?userid=21252
View this thread: http://forums.novell.com/showthread.php?t=452011