Highlighted
Regular Contributor.
Regular Contributor.
294 views

Scripting Driver DUM Question(s) ...

Hello!

While I've got a fair amount of experience with NetIQ IDM--well, I'm certainly no Aaron  or David or Geoff--I've never written a scripting driver before.

And I'm sure that to all of you reading this, it seems like I'm being lazy by not going through all the setup to test this myself.  However, we're on such a tight timeline, I really need the driver scripts I write to work as quickly as possible.

We're  now embroiled in a Team Dynamix deployment.  We've selected the scripting driver to do the heavy lifting of user and group provisioning.  A colleague of mine is writing the driver code, while I'm writing the driver scripts.

We are NOT using Team Dynamix's terrible, awful People Import Utility.  I can elaborate on that privately, if you'd like.

We're only concerned about synchronizing data from our identity vault to Team Dynamix, so I'm doing everything via the subscriber channel.  Also, my scripting driver scripts are written in Python.

Now, onto my "Scripting Driver DUM Question(s) ...".

So, I assume the data leaves the driver after the output transform, but how is the information actually transmitted from the driver to the driver scripts?

I know the scripting driver scripts don't see an actual XML document.  Instead, the scripting driver scripts actually see the driver output as a series of lines of "ADD_[attribute name][space][attribute value]" and REMOVE_[attribute name][space][attribute value]" pairs.

I also know that you use the ussmh command to interact with the driver.

But, what is ussmh actually "touching"?  Shell environment variables?  A text file?  A stream?  Even my colleagues who have written scripting driver drivers are confused about this.

And, here's the "Scripting Driver DUM Question": how can I take what's being passed to the scripting driver scripts and dump it to a file?  I mean, I *do* know how to write to the file system within Python, I just don't know what to write ...

Any experience, strength, and hope you can give me would be very much appreciated!

I hope you, all your families, and all your friends are safe and healthy!  Stay free of the V!

Most cordially,

Jack Stewart

University of Michigan

**PERSONAL INFORMATION REMOVED**

Labels (1)
Tags (2)
0 Likes
5 Replies
Highlighted
Honored Contributor.
Honored Contributor.

There are no DUM questions. Sorry I'm not Aaron, David or Geoffrey either, but they all either previously or currently work for me.

I'm also sorry I can't be totally specific about your question, but I can give you the benefit of my experience working with the scripting driver.

Basically the scripting drivers (each language is a separate implementation) really consist of a few parts:

  • A "shell" of scripts for each subscriber command (event) for each class you are synchronizing (usually with examples)
  • An object or library implementation to translate the XDS (XML using the DirXML DTD) into the native interface
  • Objects or methods to send replies back (for queries)
  • Sample script(s) you can call for the publisher channel which can be used to run native scripts and then call libraries/methods to send events back to IDM

I have done most of my scripting with that driver in vbscript or powershell, I have not done a whole lot with Python personally. I understand there is a library called /opt/novell/usdrv/idmLib.py that has a number of functions to access the data in each subscriber command and allows you to respond with replies and publisher events.

When the shim receives a subscriber command, it puts it into variables and calls subscriber.py which looks at the type of command (add, modify, move, rename, delete, query, etc.) and dispatches it to the script for each of the scripts (add.py, modify.py, move.py, rename.py, delete.py, query.py, etc.). These are the scripts you modify in your implementation to make updates to your application by calling their libraries or taking whatever action you need to.

Within those scripts, library commands give you access to the data from the command that came in from the shim. Other than a live invocation by the shim of these pre-delivered scripts, I don't believe there is any place on disk where this data is persisted. You would have to work that out yourself in Python.

The publisher is implemented in poll.py which is called regularly for you to call the application and get anything you want to send on the publisher channel. There is also a heartbeat.py intended for you to check application availability status.

I hope this was helpful.

-Rob Rawson

 

0 Likes
Highlighted
Super Contributor.
Super Contributor.

I work with the third-party team that develops the Scripting Driver. The 'ussmh' program is the "unix scripting shared memory helper"--the usdrv executable creates an area of secure shared memory from which the scripts can read data. The full Python Developer's Guide is here: https://www.netiq.com/documentation/identity-manager-48-drivers/bi_impl_scripting/data/bf1lm3e.html. Additionally, we added a way to get the subscriber event XML directly--I would look through the idmLib.py file Rob mentioned for something like a getxml function. (I'm on the Windows side so I don't know the exact name of the python function.)
I hope this gets you started--don't hesitate to ask questions.

Sam Sampson
NetIQ IDM Drivers (Third-Party)
0 Likes
Highlighted
Regular Contributor.
Regular Contributor.

Apparently, this wasn't a DUM question after all.

I've done some poking around and can't find any way to access the XML document.

That said, while I appreciate the help, I wouldn't want that anyway.

I want to basically see the contents of the shared memory space, and apparently that's a lot harder than I thought.

I also haven't found any information about these commands anywhere on the interwebs.  Nor can I find any information at all on ututil.

So, does anyone know how I can print the entire contents of the shared memory space?

0 Likes
Highlighted
Honored Contributor.
Honored Contributor.

The only starting place you could reenigne that I could imagine would be reviewing the source of idmLib.py or if possible, by decompiling the shim (DISCLAIMER: could be a licensing violation to do so)


0 Likes
Highlighted
Micro Focus Contributor
Micro Focus Contributor

The shared memory storage area is internally binary.  This is done so lookups for individual attributes are quick.  The key/value pairs are done to make it easier to write in shell scripts, while still being compatible with higher-level languages.  The XML mode was intended to allow languages such as Python/Perl to use XML libs to do more advanced stuff.  Sounds like you want to print all available keys/values, which simply isn't in the existing shared memory utility (ussmh).  

 

0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.