[Fedora-infrastructure-list] Account system updates

[Dennis Gilmore]

On Wednesday 05 July 2006 11:03 pm, Elliot Lee wrote:
> On Jul 5, 2006, at 23:38, Dennis Gilmore wrote:
> >> 			- In particular, there is a lot of concern that getting a GPG key
> >> is too complicated for a lot of people such as translators, who are
> >> not technical types. We need to make that process as clear and simple
> >> and documented as possible
> >
> > can we provide a script for nontechnical types?
>
> One good possible solution...

> >> 	- Allow groups to be members of other groups (i.e. you are a member
> >> in group B because you are a member in group A, and A is a member of
> >> B). Can't do this nicely with the current SQL schema. I did it nicely
> >> with the old Red Hat build system, but it requires using text fields
> >> instead of numeric IDs to specify the names of the group members...
> >
> > with the right interface it shouldn't matter if GID's/UID's  are
> > numerical or
> > text
>
> This was where I diverged into an implementation detail rather than
> stating a problem. At the SQL schema level, it does matter. All this
> should be totally transparent to the user...
that was what i was trying to get to the user should have no clue of the 
implementation. I could be wrong  but i think it could be done either way


> >> 	- On a related note, we need to add proper support for the corporate
> >> CLA. If we had 'groups being members of other groups' implemented, it
> >> would be fairly easy to create a group for each corporation that
> >> signed the CCLA, have each of those groups be a member of the
> >> cla_done group, and having access to the corporate CLA groups
> >> administered by a designated contact...
> >
> > Sounds good.  is there many corporate CLA's?
>
> I believe Dell and IBM are the only ones (I know Dell, not sure about
> IBM).
So not huge  but with it being easy for the corporate type  to participate  It 
could encourage others to sign up

> >> 	- Figure out the whole LDAP vs SQL thing
> >
> > Why not use both? some thing will be  just easier in ldap, some in
> > SQL,  use
> > SQL as a backend  to ldap Its a little more work  but would provide
> > greatest
> > flexibility.
>
> Can you explain more of what you're thinking in this area? In my
> thinking you have to have one authoritative place to store the data,
> and while you can do things like offer other interfaces as desired,
> it's not really a matter of using two solutions where one will do...
What i was thinking was to keep the authoritative data in a SQL server with 
ldap server as a client  

http://www.flatmtn.com/computer/Linux-LDAP.html  provides one way to implent.  
I personally  have not done  it.  But  i think it could be  an option. 

> (BTW, how hard would it be to implement an LDAP server whose tables
> were the direct results of SQL queries, with no gatewaying done? Is
> there a python module to make it easy to implement an LDAP server?)
>
> Best,
> -- Elliot
>
> _______________________________________________
> Fedora-infrastructure-list mailing list
> Fedora-infrastructure-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list

-- 
Dennis Gilmore, RHCE
Proud Australian