Grouper Users - Open Discussion List

["Black, Carey M." <>]

Jeffrey,

 

Ah. The “Does case matter?” dilemma surfaces again. 

                IMHO: Case always matters and trying to pretend that it doesn’t will likely cause you more pain instead of less.

                ( Others will likely disagree with my perspective. )

 

 

 

I have a few ideas on how I might try to “fix it”. However the first choice is “what does fixed look like?”.

                One way to “Fix it” would be to use GSH to loop over the members, find any SubjectID value that is “all lower” or “has any upper case” characters and then remove the set you want to remove.

 

                Another way would be to export the list to Excel.

                                Use Excel to separate the two sets.

                                Then upload the membership to the group via the “file upload” method and check the “replace all members” box.

                                I have actually loaded a group of 39K users this way. It is not instantaneous, but it works. :)

 

While I suspect the GSH script may be a bit faster to run, your choice should likely depend on your confidence writing the code vs using Excel.

 

Assuming you are using PSPNG to sync the group to LDAP that would likely cause some churn for PSPNG, but it depends on how PSPNG matches the user’s in AD.

                My suggestion would be to stop the loader.

                Run the GSH script to “fix the group”. ( Or throw file at server and wait for the member count to reach the expected number )

                And manually run the “full sync” process in GSH.

 

That way the individual event will not yet be processed and you can get the group square with LDAP.

 

When you start the loader, I am 90% sure that PSPNG will see the remove event and check Grouper to find that the member is still in the group. (And thus skip the remove from LDAP. ) Or it will find the user is not in Grouper, because you removed that one, and helpfully also not in AD. ( But I guess that depends on the matching rules for your PSPNG too…. You may not be using the SubjectID to match to AD…. Hum…) But worst case is that after PSPNG runs through the removes then you manually run the full sync again and all is well.

 

 

If you want to get “real fancy” you could …. Use this order… Likely safer… but “trickier too”….

                Disable PSPNG

                Restart the daemon (leave it running)

                Run the GSH script to “fix the group”. ( Or throw file at server and wait for the member count to reach the expected number )

                Jump the PSPNG Changelog Consumer to the end of the events that were created. (SQL use required)

                Enable PSPNG

                Restart the daemon (leave it running)

                Do a PSPNG full sync.

 

HTH.

 

--

Carey Matthew

 

From: <> On Behalf Of Crawford, Jeffrey
Sent: Thursday, September 19, 2019 6:01 PM
To: Grouper Users <>
Subject: Re: [grouper-users] Double memberships in one group

 

Update,

 

This may have been self imposed, I had this setting misspelled, so I corrected it, but it looks like our memberships which have HEX values in them are now saving a capital version of the name and a lower case version of the name. We need to know how to fix and if it would be better to go back to the original capital based or go forward with lower case

 

subjectApi.source.ldap.param.SubjectID_formatToLowerCase.value = true

 

 

 

From: <> on behalf of "Crawford, Jeffrey" <>
Reply-To: "Crawford, Jeffrey" <>
Date: Thursday, September 19, 2019 at 1:55 PM
To: Grouper Users <>
Subject: [grouper-users] Double memberships in one group

 

This is an odd one and I can’t figure out how to deal with it. We had a loader job say that it deleted all members and added them back, and when we look at the group in question. All the members are in there twice (I didn’t even think that was possible) How does that get fixed? And will removing the duplicate cause them to go into the changelog and remove the group memberships in the LDAP instance because there was one removal?:

 

 

Thanks

Jeffrey C.