Scripting Driver- Entitlement handling

I am implementing scripting driver and whenever the user gets an
entitlement via workflow, i have to create an account in respective
unix system. Fan out driver is the perfect match here but due to some
other reasons, we opted Scripting driver. SO the following are basic
requirements.

1.  An addition of a new entitlement should result in an <add>
document
2.  The removal of an entitlement should result in a <delete> document
3.  The delete of an Object should result in 1..n <delete> documents
4.  A modification of nspmDistributionPassword should result in 1..n
<modify-password> documents
5.  A modification ot terminationDate should result in 1..n <modify>
documents

Now, the question becomes...should there be an association held on the
IDV object? one per system? is it good idea?

So, assuming we do not hold any associations on the object, then we
need to convert the <modify> document which will be coming into the Sub
event transformation because of an addition of a new entitlement
(system) into an <add> document so the add.sh script can be run.  So,
if there is an add entitlement, out of the Event transform I would
expect an <add> document.

On the flip side, on a removal of an entitlement, out of the Event
transform I would expect a <delete> document.  On a modify to
nspmDistributionPassword I would expect many <modify> documents out of
the Event transform, but since we do not have an association, both for
the <delete> and the <modify> document, we have to add in a dummy
association so that:

how will i able to differential <modify> action? In both cases (when
user gets an entitlment or revoked entitlement) eDir responds with a
modify event but scritping driver should respond differently
(add/delete)

Any body has any logic or example to share with above kind of
situation.

Thanks


-- 
novellguest007
------------------------------------------------------------------------
novellguest007's Profile: http://forums.novell.com/member.php?userid=14903
View this thread: http://forums.novell.com/showthread.php?t=327081

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Unless there is a reason to do otherwise I would probably try to have an
association (uidnumber or maybe just username depending on what you plan
on happening and how much you want to script) so that modifies and
deletes would run without any querying to the destination.  Unless you
plan on not ever matching you'll need to write something for that as
well I presume.

Also unless you are doing a Scripting driver for some specific reason
there is the Linux/Unix Bidirectional driver which may work out for you.
~ What were the reasons against Fan-Out?

Good luck.





novellguest007 wrote:
| I am implementing scripting driver and whenever the user gets an
| entitlement via workflow, i have to create an account in respective
| unix system. Fan out driver is the perfect match here but due to some
| other reasons, we opted Scripting driver. SO the following are basic
| requirements.
|
| 1.  An addition of a new entitlement should result in an <add>
| document
| 2.  The removal of an entitlement should result in a <delete> document
| 3.  The delete of an Object should result in 1..n <delete> documents
| 4.  A modification of nspmDistributionPassword should result in 1..n
| <modify-password> documents
| 5.  A modification ot terminationDate should result in 1..n <modify>
| documents
|
| Now, the question becomes...should there be an association held on the
| IDV object? one per system? is it good idea?
|
| So, assuming we do not hold any associations on the object, then we
| need to convert the <modify> document which will be coming into the Sub
| event transformation because of an addition of a new entitlement
| (system) into an <add> document so the add.sh script can be run.  So,
| if there is an add entitlement, out of the Event transform I would
| expect an <add> document.
|
| On the flip side, on a removal of an entitlement, out of the Event
| transform I would expect a <delete> document.  On a modify to
| nspmDistributionPassword I would expect many <modify> documents out of
| the Event transform, but since we do not have an association, both for
| the <delete> and the <modify> document, we have to add in a dummy
| association so that:
|
| how will i able to differential <modify> action? In both cases (when
| user gets an entitlment or revoked entitlement) eDir responds with a
| modify event but scritping driver should respond differently
| (add/delete)
|
| Any body has any logic or example to share with above kind of
| situation.
|
| Thanks
|
|
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFIInGN3s42bA80+9kRAiYcAJ0T9tFXXtubm9Q32kPiM7HNEx0segCdG+/B
iKFHN7tP6C5k0xIwDhc1XHk=
=G4eF

The fan out works but as we need to install an agent and opening ports
on the connected system, client opted for scripting driver.
My biggest road block now is, I have to differentiate various <modify>
events. If the entitlement pop ups, i have to send <add> document to
shim. If the entitlement is revoked i have to send <delete>. but both
are <modify> events. I have to differentiate such kind of events and
prepare the document.


ab@novell.com;1553188 Wrote: 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Unless there is a reason to do otherwise I would probably try to have
> an
> association (uidnumber or maybe just username depending on what you
> plan
> on happening and how much you want to script) so that modifies and
> deletes would run without any querying to the destination.  Unless you
> plan on not ever matching you'll need to write something for that as
> well I presume.
> 
> Also unless you are doing a Scripting driver for some specific reason
> there is the Linux/Unix Bidirectional driver which may work out for
> you.
> ~ What were the reasons against Fan-Out?
> 
> Good luck.
> 
> 
> 
> 
> 
> novellguest007 wrote:
> | I am implementing scripting driver and whenever the user gets an
> | entitlement via workflow, i have to create an account in respective
> | unix system. Fan out driver is the perfect match here but due to
> some
> | other reasons, we opted Scripting driver. SO the following are basic
> | requirements.
> |
> | 1.  An addition of a new entitlement should result in an <add>
> | document
> | 2.  The removal of an entitlement should result in a <delete>
> document
> | 3.  The delete of an Object should result in 1..n <delete>
documents
> | 4.  A modification of nspmDistributionPassword should result in 1..n
> | <modify-password> documents
> | 5.  A modification ot terminationDate should result in 1..n
<modify>
> | documents
> |
> | Now, the question becomes...should there be an association held on
> the
> | IDV object? one per system? is it good idea?
> |
> | So, assuming we do not hold any associations on the object, then we
> | need to convert the <modify> document which will be coming into the
> Sub
> | event transformation because of an addition of a new entitlement
> | (system) into an <add> document so the add.sh script can be run. 
> So,
> | if there is an add entitlement, out of the Event transform I would
> | expect an <add> document.
> |
> | On the flip side, on a removal of an entitlement, out of the Event
> | transform I would expect a <delete> document.  On a modify to
> | nspmDistributionPassword I would expect many <modify> documents out
> of
> | the Event transform, but since we do not have an association, both
> for
> | the <delete> and the <modify> document, we have to add in a
dummy
> | association so that:
> |
> | how will i able to differential <modify> action? In both cases
(when
> | user gets an entitlment or revoked entitlement) eDir responds with a
> | modify event but scritping driver should respond differently
> | (add/delete)
> |
> | Any body has any logic or example to share with above kind of
> | situation.
> |
> | Thanks
> |
> |
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.2 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - 'Enigmail: A simple interface for
> OpenPGP email security' (http://enigmail.mozdev.org)
> 
> iD8DBQFIInGN3s42bA80+9kRAiYcAJ0T9tFXXtubm9Q32kPiM7HNEx0segCdG+/B
> iKFHN7tP6C5k0xIwDhc1XHk=
> =G4eF
> -----END PGP SIGNATURE-----


-- 
novellguest007
------------------------------------------------------------------------
novellguest007's Profile: http://forums.novell.com/member.php?userid=14903
View this thread: http://forums.novell.com/showthread.php?t=327081

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Won't you need to have something on the boxes as well with the Scripting
Driver, or are you making some kind of remote calls to the box?  Doing
so should be easy enough... if nothing else you could send commands via
SSH... it's just that most of the time the scripting is done on the box
for simplicity.

If you use associations the system should be able to differentiate types
of events for you.  For example a delete coming from the engine will
come through as a delete, as will an add.  Whether or not a modify comes
through properly may depend on policies but there are other drivers that
use entitlements the way you have suggested from which you can probably
steal some policy (check the MAD driver for starters).

Good luck.





novellguest007 wrote:
| The fan out works but as we need to install an agent and opening ports
| on the connected system, client opted for scripting driver.
| My biggest road block now is, I have to differentiate various <modify>
| events. If the entitlement pop ups, i have to send <add> document to
| shim. If the entitlement is revoked i have to send <delete>. but both
| are <modify> events. I have to differentiate such kind of events and
| prepare the document.
|
|
| ab@novell.com;1553188 Wrote:
| Unless there is a reason to do otherwise I would probably try to have
| an
| association (uidnumber or maybe just username depending on what you
| plan
| on happening and how much you want to script) so that modifies and
| deletes would run without any querying to the destination.  Unless you
| plan on not ever matching you'll need to write something for that as
| well I presume.
|
| Also unless you are doing a Scripting driver for some specific reason
| there is the Linux/Unix Bidirectional driver which may work out for
| you.
| ~ What were the reasons against Fan-Out?
|
| Good luck.
|
|
|
|
|
| novellguest007 wrote:
| | I am implementing scripting driver and whenever the user gets an
| | entitlement via workflow, i have to create an account in respective
| | unix system. Fan out driver is the perfect match here but due to
| some
| | other reasons, we opted Scripting driver. SO the following are basic
| | requirements.
| |
| | 1.  An addition of a new entitlement should result in an <add>
| | document
| | 2.  The removal of an entitlement should result in a <delete>
| document
| | 3.  The delete of an Object should result in 1..n <delete> documents
| | 4.  A modification of nspmDistributionPassword should result in 1..n
| | <modify-password> documents
| | 5.  A modification ot terminationDate should result in 1..n <modify>
| | documents
| |
| | Now, the question becomes...should there be an association held on
| the
| | IDV object? one per system? is it good idea?
| |
| | So, assuming we do not hold any associations on the object, then we
| | need to convert the <modify> document which will be coming into the
| Sub
| | event transformation because of an addition of a new entitlement
| | (system) into an <add> document so the add.sh script can be run.
| So,
| | if there is an add entitlement, out of the Event transform I would
| | expect an <add> document.
| |
| | On the flip side, on a removal of an entitlement, out of the Event
| | transform I would expect a <delete> document.  On a modify to
| | nspmDistributionPassword I would expect many <modify> documents out
| of
| | the Event transform, but since we do not have an association, both
| for
| | the <delete> and the <modify> document, we have to add in a
dummy
| | association so that:
| |
| | how will i able to differential <modify> action? In both cases (when
| | user gets an entitlment or revoked entitlement) eDir responds with a
| | modify event but scritping driver should respond differently
| | (add/delete)
| |
| | Any body has any logic or example to share with above kind of
| | situation.
| |
| | Thanks
| |
| |
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFIIvj/3s42bA80+9kRAlihAKCEezYnAYUNIfEECawzbPgandnxwgCfRhMN
pdafu6gWf4iZWI259lkoCto=
=IpaI

Correct. If I have association then everything works great in my local
vm. But that is 1:1 in my local envrionemnt whereas client as 1:many.
My question would, as there is no association, every modify will be
converted into add and that puts me into corner. I have to the driver
that do not convert <modify> into <add> if there is no association.
don't know how to do that.



ab@novell.com;1553453 Wrote: 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Won't you need to have something on the boxes as well with the
> Scripting
> Driver, or are you making some kind of remote calls to the box?  Doing
> so should be easy enough... if nothing else you could send commands
> via
> SSH... it's just that most of the time the scripting is done on the
> box
> for simplicity.
> 
> If you use associations the system should be able to differentiate
> types
> of events for you.  For example a delete coming from the engine will
> come through as a delete, as will an add.  Whether or not a modify
> comes
> through properly may depend on policies but there are other drivers
> that
> use entitlements the way you have suggested from which you can
> probably
> steal some policy (check the MAD driver for starters).
> 
> Good luck.
> 
> 
> 
> 
> 
> novellguest007 wrote:
> | The fan out works but as we need to install an agent and opening
> ports
> | on the connected system, client opted for scripting driver.
> | My biggest road block now is, I have to differentiate various
> <modify>
> | events. If the entitlement pop ups, i have to send <add> document
to
> | shim. If the entitlement is revoked i have to send <delete>. but
> both
> | are <modify> events. I have to differentiate such kind of events
and
> | prepare the document.
> |
> |
> | ab@novell.com;1553188 Wrote:
> | Unless there is a reason to do otherwise I would probably try to
> have
> | an
> | association (uidnumber or maybe just username depending on what you
> | plan
> | on happening and how much you want to script) so that modifies and
> | deletes would run without any querying to the destination.  Unless
> you
> | plan on not ever matching you'll need to write something for that as
> | well I presume.
> |
> | Also unless you are doing a Scripting driver for some specific
> reason
> | there is the Linux/Unix Bidirectional driver which may work out for
> | you.
> | ~ What were the reasons against Fan-Out?
> |
> | Good luck.
> |
> |
> |
> |
> |
> | novellguest007 wrote:
> | | I am implementing scripting driver and whenever the user gets an
> | | entitlement via workflow, i have to create an account in
> respective
> | | unix system. Fan out driver is the perfect match here but due to
> | some
> | | other reasons, we opted Scripting driver. SO the following are
> basic
> | | requirements.
> | |
> | | 1.  An addition of a new entitlement should result in an <add>
> | | document
> | | 2.  The removal of an entitlement should result in a <delete>
> | document
> | | 3.  The delete of an Object should result in 1..n <delete>
> documents
> | | 4.  A modification of nspmDistributionPassword should result in
> 1..n
> | | <modify-password> documents
> | | 5.  A modification ot terminationDate should result in 1..n
> <modify>
> | | documents
> | |
> | | Now, the question becomes...should there be an association held on
> | the
> | | IDV object? one per system? is it good idea?
> | |
> | | So, assuming we do not hold any associations on the object, then
> we
> | | need to convert the <modify> document which will be coming into
> the
> | Sub
> | | event transformation because of an addition of a new entitlement
> | | (system) into an <add> document so the add.sh script can be run.
> | So,
> | | if there is an add entitlement, out of the Event transform I would
> | | expect an <add> document.
> | |
> | | On the flip side, on a removal of an entitlement, out of the Event
> | | transform I would expect a <delete> document.  On a modify to
> | | nspmDistributionPassword I would expect many <modify> documents
> out
> | of
> | | the Event transform, but since we do not have an association, both
> | for
> | | the <delete> and the <modify> document, we have to add in a
dummy
> | | association so that:
> | |
> | | how will i able to differential <modify> action? In both cases
> (when
> | | user gets an entitlment or revoked entitlement) eDir responds with
> a
> | | modify event but scritping driver should respond differently
> | | (add/delete)
> | |
> | | Any body has any logic or example to share with above kind of
> | | situation.
> | |
> | | Thanks
> | |
> | |
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.2 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - 'Enigmail: A simple interface for
> OpenPGP email security' (http://enigmail.mozdev.org)
> 
> iD8DBQFIIvj/3s42bA80+9kRAlihAKCEezYnAYUNIfEECawzbPgandnxwgCfRhMN
> pdafu6gWf4iZWI259lkoCto=
> =IpaI
> -----END PGP SIGNATURE-----


-- 
novellguest007
------------------------------------------------------------------------
novellguest007's Profile: http://forums.novell.com/member.php?userid=14903
View this thread: http://forums.novell.com/showthread.php?t=327081