Home

Results 1 to 3 of 3

Thread: Google driver question: is NOVLGGLEUSER-sub-otp_HandleDeleteEventsstill relevant?

  1. #1

    Google driver question: is NOVLGGLEUSER-sub-otp_HandleDeleteEventsstill relevant?

    This policy in the output transform is used to rename about-to-be-deleted
    objects in Google, because Google doesn't immediately delete objects, it
    leaves them around for a while. By renaming them, first, the driver
    ensures that a later <add> event won't error out because the new object
    name conflicts with a deleted but not yet purged object in Google.

    For some time now, I've been ignoring a problem here where a user account
    is deleted (account lifecycle), so it gets renamed and deleted in Google,
    but then the user returns to an active status. What I've been seeing
    happen, if they come back during the period where Google has marked the
    account as deleted, but has not yet purged it, is that the driver hits
    the matching rule, finds the deleted account, and restores it.

    That would be fine, except that what the driver doesn't do is rename the
    restored account back to what it used to be named before this rename-then-
    delete policy was applied to it. So what I see is student (z025853) has a
    Google account (z025853@students.niu.edu).

    He gets deleted, so in Google I see him renamed and deleted as
    (z0258531442257504@students.niu.edu).

    He comes back, so I see the driver process an <add> for him, the matching
    rule finds him, and he ends up restored as
    (z0258531442257504@students.niu.edu).

    I have this in old traces, and can see it happening like:

    Code:
    <modify class-name="UserEntry" event-id="LidGen
    Input#Publisher#0:7e671a46-e021-4f8b-8d77-1e135e4d07f7" from-merge="true"
    qualified-src-dn="O=NIU\OU=Users\CN=Z025853" src-dn="\NIU-FLAT\NIU\Users
    \Z025853" src-entry-id="905613">
    <association>Z0258531436059158@students.niu.edu</association>
    <modify-attr attr-name="GivenName">
    <remove-all-values/>
    <add-value>
    <value timestamp="1416192435#4" type="string">David</value>
    </add-value>
    </modify-attr>
    <modify-attr attr-name="FamilyName">
    <remove-all-values/>
    <add-value>
    <value timestamp="1416192435#5" type="string">Gersic</value>
    </add-value>
    </modify-attr>
    <modify-attr attr-name="IsSuspended">
    <remove-all-values/>
    </modify-attr>
    <operation-data/>
    </modify>
    I had a few minutes while waiting on somebody else to do something, so I
    thought I'd see about fixing this. It seemed that it should be possible
    to catch the <modify> with the @from-merge=true on it, and rename the
    restored account back to what it should be (z025853@students.niu.edu). It
    turns out not to be quite that simple, but I don't understand why not.

    In watching the trace now, I don't see the driver matching policies find
    the deleted account. So, with no match, there's no <modify @from-
    merge=true> to do anything with. The <add> proceeds through the usual
    processing, and a new account is created.

    I suspect that this is a change in how the shim and the back end Google
    API work. I think the old shim, prior to spring 2015, and the old Google
    API worked one way, and the new shim, with the new Google API, work
    differently in this regard. If so, then it seems to me that NOVLGGLEUSER-
    sub-otp_HandleDeleteEvents is no longer relevant and could be removed
    from the Google Apps User Package.

    The point of this rename was to stop name collisions with deleted
    objects. If I delete an object now, and create a new one that should
    conflict, it doesn't. The matching rules that used to find the deleted
    object by its alias, no longer do, so the <modify> never happens, and I
    can't therefor catch the <modify> and add a <rename> to it.

    I'm thinking, therefor, that NOVLGGLEUSER-sub-otp_HandleDeleteEvents is
    no longer needed, and could be removed.

    Alternately, I'm missing something here and I should be seeing the
    Matching Rules find the deleted account, but I'm not.


    --
    --------------------------------------------------------------------------
    David Gersic dgersic_@_niu.edu
    Knowledge Partner http://forums.microfocus.com

    Please post questions in the forums. No support provided via email.
    If you find this post helpful, please click on the star below.

  2. #2
    Join Date
    Apr 2008
    Posts
    104

    Re: Google driver question: is NOVLGGLEUSER-sub-otp_HandleDeleteEventsstill relevant?


    Hi David.

    I came to the same conclusion a month ago. I have disabled these rules
    as the makes no sense to have them anymore.

    The problem I ran into was a timing issue when the renamed user was not
    found for deletion probably because the rename event wasnt fully handled
    fully by Google before the delete event.

    This happened for about 1% of delete events.


    --
    marcus_jonsson
    ------------------------------------------------------------------------
    marcus_jonsson's Profile: https://forums.netiq.com/member.php?userid=1157
    View this thread: https://forums.netiq.com/showthread.php?t=54319


  3. #3
    cpedersen is offline Micro Focus Employee - Ultra Contributor
    Join Date
    Feb 2008
    Posts
    371

    Re: Google driver question: isNOVLGGLEUSER-sub-otp_HandleDeleteEvents still relevant?

    I looked into this, as I was of the exact same opinion. But was told
    that it's still there to handle name collision / name reuse.

    The thing with finding deleted users and re-activating them might be an
    issue.....

    Casper


    On 9/18/15 3:30 PM, David Gersic wrote:
    > This policy in the output transform is used to rename about-to-be-deleted
    > objects in Google, because Google doesn't immediately delete objects, it
    > leaves them around for a while. By renaming them, first, the driver
    > ensures that a later <add> event won't error out because the new object
    > name conflicts with a deleted but not yet purged object in Google.
    >
    > For some time now, I've been ignoring a problem here where a user account
    > is deleted (account lifecycle), so it gets renamed and deleted in Google,
    > but then the user returns to an active status. What I've been seeing
    > happen, if they come back during the period where Google has marked the
    > account as deleted, but has not yet purged it, is that the driver hits
    > the matching rule, finds the deleted account, and restores it.
    >
    > That would be fine, except that what the driver doesn't do is rename the
    > restored account back to what it used to be named before this rename-then-
    > delete policy was applied to it. So what I see is student (z025853) has a
    > Google account (z025853@students.niu.edu).
    >
    > He gets deleted, so in Google I see him renamed and deleted as
    > (z0258531442257504@students.niu.edu).
    >
    > He comes back, so I see the driver process an <add> for him, the matching
    > rule finds him, and he ends up restored as
    > (z0258531442257504@students.niu.edu).
    >
    > I have this in old traces, and can see it happening like:
    >
    >
    Code:
    >   <modify class-name="UserEntry" event-id="LidGen
    > Input#Publisher#0:7e671a46-e021-4f8b-8d77-1e135e4d07f7" from-merge="true"
    > qualified-src-dn="O=NIU\OU=Users\CN=Z025853" src-dn="\NIU-FLAT\NIU\Users
    > \Z025853" src-entry-id="905613">
    >    <association>Z0258531436059158@students.niu.edu</association>
    >    <modify-attr attr-name="GivenName">
    >    <remove-all-values/>
    >    <add-value>
    >     <value timestamp="1416192435#4" type="string">David</value>
    >    </add-value>
    >    </modify-attr>
    >    <modify-attr attr-name="FamilyName">
    >    <remove-all-values/>
    >    <add-value>
    >     <value timestamp="1416192435#5" type="string">Gersic</value>
    >    </add-value>
    >    </modify-attr>
    >    <modify-attr attr-name="IsSuspended">
    >    <remove-all-values/>
    >    </modify-attr>
    >    <operation-data/>
    >   </modify>
    >
    >
    > I had a few minutes while waiting on somebody else to do something, so I
    > thought I'd see about fixing this. It seemed that it should be possible
    > to catch the <modify> with the @from-merge=true on it, and rename the
    > restored account back to what it should be (z025853@students.niu.edu). It
    > turns out not to be quite that simple, but I don't understand why not.
    >
    > In watching the trace now, I don't see the driver matching policies find
    > the deleted account. So, with no match, there's no <modify @from-
    > merge=true> to do anything with. The <add> proceeds through the usual
    > processing, and a new account is created.
    >
    > I suspect that this is a change in how the shim and the back end Google
    > API work. I think the old shim, prior to spring 2015, and the old Google
    > API worked one way, and the new shim, with the new Google API, work
    > differently in this regard. If so, then it seems to me that NOVLGGLEUSER-
    > sub-otp_HandleDeleteEvents is no longer relevant and could be removed
    > from the Google Apps User Package.
    >
    > The point of this rename was to stop name collisions with deleted
    > objects. If I delete an object now, and create a new one that should
    > conflict, it doesn't. The matching rules that used to find the deleted
    > object by its alias, no longer do, so the <modify> never happens, and I
    > can't therefor catch the <modify> and add a <rename> to it.
    >
    > I'm thinking, therefor, that NOVLGGLEUSER-sub-otp_HandleDeleteEvents is
    > no longer needed, and could be removed.
    >
    > Alternately, I'm missing something here and I should be seeing the
    > Matching Rules find the deleted account, but I'm not.
    >
    >



Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •