geistc Valued Contributor.
Valued Contributor.
680 views

Persist dynamic data through driver restarts

I have a SOAP driver that I wrote back in 2010 that I currently use for account creation in eDirectory from some internal applications. One of the account types it creates are service accounts and our naming convention is an alpha prefix with a 5 digit number that is incremented for each account created for the username. I have the below action using the unique name token to iterate through the existing accounts to find the first number that is not used. There definitely may be much better ways to do this but I wrote this as one of my first drivers so I am sure there are a lot of things in there that can be done better. 😄

The problem I have with this solution is I use a GCV to contain the starting point to start incrementing from since we don't won't to reuse any accounts. Since it is a GCV, that means I have to manually update the value every so often and restart the driver so we don't end up reusing an account that was deleted. What I am wondering is if there is somewhere else I can store a counter that can be read/written to from policy that will not be lost on a driver restart. I see there is a DirXML-PersistentData attribute on the drivers that it appears the drivers read/write to so not sure if there is a way to read/write to that location in policy or if there is somewhere else better suited for this purpose. If there is somewhere that I could write to from policy then I could store the number in their so it will always have the last account number that was created and I wouldn't have to use the unique name token to loop through to find the next open number.

Thanks in advance.

<token-unique-name counter-digits="5" counter-pad="true" counter-pattern="first" counter-start="~XX-start-counter~" counter-use="always" name="uniqueID" on-unavailable="error" scope="subordinates">
<arg-dn>
<token-text xml:space="preserve">\</token-text>
<token-global-variable name="dirxml.auto.treename"/>
<token-text xml:space="preserve">\</token-text>
<token-map dest="RDN" src="Account_Type" table="..\..\Mapping Tables\Account Types Table">
<token-local-variable name="accounttype"/>
</token-map>
</arg-dn>
<arg-string>
<token-lower-case>
<token-local-variable name="accounttype"/>
</token-lower-case>
</arg-string>
</token-unique-name>
Labels (1)
0 Likes
8 Replies
Knowledge Partner
Knowledge Partner

Re: Persist dynamic data through driver restarts

I don't think, that you suppose to use DirXML-PersistentData

https://www.novell.com/support/kb/doc.php?id=7004982
DirXML-PersistentData stores counters for health monitoring. If the attribute XML content get corrupted, the errors mentioned in this TID will occur.
Since it is is recreated when it does not exist and the driver is started, there is no loss of driver configuration or logic in deleting the DirXML-PersistentData attribute.

You can use any custom attribute for store your own counter or I can recommend to use the standard ID-Provider driver.
https://www.netiq.com/communities/cool-solutions/idm-401-id-provider-configuration/
https://www.netiq.com/documentation/identity-manager-47-drivers/idprovider/data/bc0igns.html
Knowledge Partner
Knowledge Partner

Re: Persist dynamic data through driver restarts

al b wrote:

> I can recommend to use the standard *ID-Provider* driver.


+1


--
http://www.is4it.de/en/solution/identity-access-management/

(If you find this post helpful, please click on the star below.)
______________________________________________
https://www.is4it.de/identity-access-management
0 Likes
Knowledge Partner
Knowledge Partner

Re: Persist dynamic data through driver restarts

On 9/6/2018 3:04 PM, geistc wrote:
>
> I have a SOAP driver that I wrote back in 2010 that I currently use for
> account creation in eDirectory from some internal applications. One of
> the account types it creates are service accounts and our naming
> convention is an alpha prefix with a 5 digit number that is incremented
> for each account created for the username. I have the below action using
> the unique name token to iterate through the existing accounts to find
> the first number that is not used. There definitely may be much better
> ways to do this but I wrote this as one of my first drivers so I am sure
> there are a lot of things in there that can be done better. 😄
>
> The problem I have with this solution is I use a GCV to contain the
> starting point to start incrementing from since we don't won't to reuse
> any accounts. Since it is a GCV, that means I have to manually update
> the value every so often and restart the driver so we don't end up
> reusing an account that was deleted. What I am wondering is if there is
> somewhere else I can store a counter that can be read/written to from
> policy that will not be lost on a driver restart. I see there is a
> DirXML-PersistentData attribute on the drivers that it appears the
> drivers read/write to so not sure if there is a way to read/write to
> that location in policy or if there is somewhere else better suited for
> this purpose. If there is somewhere that I could write to from policy
> then I could store the number in their so it will always have the last
> account number that was created and I wouldn't have to use the unique
> name token to loop through to find the next open number.


Try DirXML-DriverStorage instead...
ukrause Super Contributor.
Super Contributor.

Re: Persist dynamic data through driver restarts

We have many of those demands for several drivers. Therefor we use a "HelperObject" named Object of any class you like (we use inetOrgPerson). In there we use different Attributes to keep such persistent data or setup queues other drivers have to work on. We use GCV to reference that object and other GCV to reference the attributes and their meaning
0 Likes
geistc Valued Contributor.
Valued Contributor.

Re: Persist dynamic data through driver restarts

Is there any built-in ways of managing that attribute from within policy or do you just modify it by just modifying the driver the same as you would modify other objects (i.e. set dest attribute or the like)?
0 Likes
Knowledge Partner
Knowledge Partner

Re: Persist dynamic data through driver restarts

On 9/7/2018 9:44 AM, geistc wrote:
>
> Is there any built-in ways of managing that attribute from within policy
> or do you just modify it by just modifying the driver the same as you
> would modify other objects (i.e. set dest attribute or the like)?


Just modify the driver. You can see the Generic File Shim from Stephaan
do it to store the last line read, so on a restart you pick up where you
left off.


0 Likes
Knowledge Partner
Knowledge Partner

Re: Persist dynamic data through driver restarts

Sure, you can modify the object, but the functionality you are describing
(a counter for a unique name) is what "al b" has already answered using
the ID Provider driver; its whole purpose in life is to give out unique
IDs in a counter-like way, and to do so in a way that guarantees no reuse,
and even to do so via non-IDM-driver RPC-based calls if desired.

DirXML-DriverStorage is per-replica, so if you lose your server, you lose
your counter since it will not have replicated anywhere else; the same
goes for GCVs stored on the driver object I believe.

Once upon a time, before the ID Provider driver existed, I wrote a
CoolSolution that would LUM-enable users (adding posixAccount and the
related attributes) via IDM, and in that case I used the LUM-default "Unix
Config" object to store the counter, since that is where it was stored
when used outside of IDM anyway, but there was always a risk of a race
condition where somebody could be LUM-enabling via iManager at the same
time IDM was doing something on another object and you could end up with
duplicate IDs. That probably exists for anything not coded explicitly to
prevent it, like the ID Provider.

--
Good luck.

If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below.

If you want to send me a private message, please let me know in the
forum as I do not use the web interface often.
0 Likes
Knowledge Partner
Knowledge Partner

Re: Persist dynamic data through driver restarts

geistc;2487147 wrote:
I have a SOAP driver that I wrote back in 2010 that I currently use for account creation in eDirectory from some internal applications. One of the account types it creates are service accounts and our naming convention is an alpha prefix with a 5 digit number that is incremented for each account created for the username. I have the below action using the unique name token to iterate through the existing accounts to find the first number that is not used. There definitely may be much better ways to do this but I wrote this as one of my first drivers so I am sure there are a lot of things in there that can be done better. 😄

The problem I have with this solution is I use a GCV to contain the starting point to start incrementing from since we don't won't to reuse any accounts. Since it is a GCV, that means I have to manually update the value every so often and restart the driver so we don't end up reusing an account that was deleted. What I am wondering is if there is somewhere else I can store a counter that can be read/written to from policy that will not be lost on a driver restart. I see there is a DirXML-PersistentData attribute on the drivers that it appears the drivers read/write to so not sure if there is a way to read/write to that location in policy or if there is somewhere else better suited for this purpose. If there is somewhere that I could write to from policy then I could store the number in their so it will always have the last account number that was created and I wouldn't have to use the unique name token to loop through to find the next open number.

Thanks in advance.

<token-unique-name counter-digits="5" counter-pad="true" counter-pattern="first" counter-start="~XX-start-counter~" counter-use="always" name="uniqueID" on-unavailable="error" scope="subordinates">
<arg-dn>
<token-text xml:space="preserve">\</token-text>
<token-global-variable name="dirxml.auto.treename"/>
<token-text xml:space="preserve">\</token-text>
<token-map dest="RDN" src="Account_Type" table="..\..\Mapping Tables\Account Types Table">
<token-local-variable name="accounttype"/>
</token-map>
</arg-dn>
<arg-string>
<token-lower-case>
<token-local-variable name="accounttype"/>
</token-lower-case>
</arg-string>
</token-unique-name>



You could replace your use of GCVs with driver scoped local variables. Create a resource object to store the data in. Write a startup policy to read your resource object, and set your variables with the data. I'd be tempted to keep everything in a nodeset variable, referencing it with XPath, to make it easy to store in the resource object every time something changes. Or, if it doesn't have to be a perfect reflection of reality, only store updates if something changed, and use the heartbeat to check to see if the cached copy on disk needs to be updated.
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.