Using the Loopback Driver
Novell Cool Solutions: Tip
Digg This -
Posted: 14 Oct 2004
About the Loopback Driver
There is a driver, called the Loopback driver, which is quite unique, as part of DirXML and Nsure Identity Manager 2.0.
The layout for this driver is something like this:
--- subscriber channel ---
eDirectory Loopback driver
--- publisher channel ---
Figure: Information flow for Loopback driver
This means that data flows into this driver from eDirectory. The data is checked against the event filter, runs through all the rules, and gets passed back to the same eDirectory tree where it came from.
We can do useful things when object events happen. For example, on a user create event, we can check whether the apple-user-homeDirectory attribute is available. If not, we can populate it with values based on the user's info in the object (CN, or even the NDS homeDirectory property). Or, we could check to see if the iFolderUser attribute is set when the user is created. If the user is in a certain container, that container could be set and the user pointed at the correct server.
Here's the main reason this is of interest to my group. Our provisioning system is written as a Java app running on Netware, but the person who maintains the app is booked solid for the next 6 months. We need to make modifications to all users created, until he can add the app features we need. The Loopback driver will allow us to do this on the fly.
Using the Driver
To use the driver:
- Create a driver set on a server, or a new driver in a driver set. There is one driver set per server, so be careful!
- Name the driver file in the new driver set as "move_proxy.xml". move_proxy is the default name.
- Edit the Driver Filter on the subscriber channel and add the object classes you care about.
- Remove the DirXML-MoveProxyTrigger attribute. This was used so that if an object was moved, the other driver doing the move could set this flag, which would trigger the Loopback driver to do its magic after the move.
- You will probably want to add a User and object class. In the two examples above, the attributes are iFolderUser and apple-user-homeDirectory.
- Set the attributes to Notify. Since you are working in the same tree, there's no need to automatically synchronize the attributes (you would get in to a circular loop doing that).
- Set the Merge authority to None (again, trying to avoid a loop).
- Edit the Event Transformation policies.
- Remove the existing rule if desired, since it is meant for a complex special case.
- Add a rule that watches for Create Events of object class User, and then checks if an attribute is available. If it's not, I would just do the work in here, and make the changes I need. I would need help with the XPATH expression to convert HOME_DIRECTORY format to the afp:// format that Apple needs.
This procedure should work to monitor the tree for create events.
You can add a condition on the above rule, so that only users with a source-dn in the subtree you care about will be watched for. This narrows the scope of the driver. And you can use rules, etc. in any of the other filters along the way, as appropriate to get your work done.
What other neat things can you think of to do with this driver? Or, what are other good examples of on-the-fly modifications do you need, to match your environment? Send us your suggestions!
Novell Cool Solutions (corporate web communities) are produced by WebWise Solutions. www.webwiseone.com