Grouper Users - Open Discussion List

["Dr. Loris Bennett" <>]

On Tue, 2009-03-10 at 13:23 -0400, Chris Hyzer wrote:
> I can think of four ways to ensure uniqueness:
> 
> 1. The hook that Gary mentioned... just do a query in the attribute to
>  table to make sure the same one doesn’t exist with another group uuid.
> 
> 2. Or you could make a new custom table which relates GID and
>  group_UUID (and has a unique constraint on GID and on GID/group_UUID
>  pair).  Still keep it in the attribute too.  When you do your hook,
>  also check the table to see if one exists, and insert if not.  This
>  way, since things are in a transaction, you cant have a duplicate.
> 
> 3. Another way would be to make a DB trigger on grouper_attributes
>  which checks on insert/update to see if one exists by another group
>  and if so, blows up.
> 
> 4. Have all 500 groups in one stem where the group extension is
>  whateverUnix_123 [where 123 is the GID] (granted this will bring about
>  other problems, like the UI might not work well...)  Maybe it could
>  partition with 10 groups per stem (or something like this):  so group
>  50 would be: whateverUnix5:whatever0.  Group 579 would be
>  somethingElse5:whateverUnix7:whatever9.

Approach 1 appeals to me, mainly on the grounds of being simple and
allowing the changes to be decoupled from the rest of Grouper. 

> I don’t understand why Grouper is assigning/maintaining the GID and the
>  customer's system isn’t sending it to Grouper, does the OS
>  originate/assign it?  Or do they change it in the group file once
>  Grouper tells them what it is?

The trouble is that customers are unlikely to have completely disjunct
sets of GIDS. We can recycle the first customer's GIDs, but subsequent
customers will just be assigned new ones to avoid any overlap.  

> Im thinking about what we could do to Grouper if we wanted, we could
>  add a col to the groups table in 1.5 which is unique and nullable
>  where sites could assign an internal identifier...  this would solve
>  the unique issue.  Though its not much better than one of the methods
>  above.  I wonder if other places are interested in this.

I wouldn't necessarily think that special changes to Grouper are
required. I see this Unix GID just as another attribute that happens to
have the extra restriction of needing to be unique. Adding a query to
the hook seems to me to be a perfectly adequate approach.

> > The customer is the only party using the GID and will only ever be
> > drawing information from the production system, so I wasn't planning on
> > differentiating here. Am I missing something?
> 
> If you only have one env then it isn’t an issue.
> 
> Regards,
> Chris

Thanks for all the feedback.

Loris

-- 
Dr. Loris Bennett (Mr.)
Freie Universität Berlin
ZEDAT - Zentraleinrichtung für Datenverarbeitung / Computer Center
Compute & Media Service
Fabeckstr. 32, Room 221
D-14195 Berlin
Tel ++49 30 838 51024
Fax ++49 30 838 56721
Email 

Web www.zedat.fu-berlin.de