[Fedora-infrastructure-list] Security, access and the config CVS

[Jeffrey Tadlock]

Mike McGrath wrote:
> We need to re-think the cvs situation.  Not only have the configs
> become woefully out of date with whats on the actual builders, but
> upgrades can become difficult when moving from one OS to another
> because of incompatibilities.  I don't know that we should get rid of
> all of it just re-think what goes in it or try to simplify it a bit.
> Maybe write a script that runs daily and compares whats in CVS with
> what's live?  Not perfect but better than what we have.  Regardless of
> what we do with it we need to figure out where to put CVS because not
> everyone has access to lockbox.

As for the configs being out of synch with the cvs admin repo, we 
definitely need to do what we can to keep that from happening.  Some of 
this can probably be solved just by reinforcing the use of the cvs repo 
and making sure new folks know of its existance and the importance of 
checking any configuration changes made on a server into cvs.

A script to compare what's in the repo and what's on the servers could 
be useful though to help make sure the proper steps are being followed.

Why do we need to move the admin cvs repo?  Isn't the fedora-config repo 
kept on it to keep it isolated from the other servers performing 
mainstream production duties?  Wouldn't limiting root access on lockbox 
get us what we are after?  Then we could give shell access to people 
that needed it and use permissions to restrict them from locations 
deemed more sensitive than others.  I may just be missing something on 
this point, so feel free to point out the core of the concern.

> Which brings me to restarting the topic of
> officers/leaders/sponsors/whatever.  By creating more fine-grained
> security on the servers there is less of a need for root access on
> those machines.  People interested in working on mail, will be in a
> mail group and have access to it.   Nagios, web, proxy, builders, cvs,
> etc, all come to mind of things that can be administered without full
> root access.  So the question is how do we determine who has root to
> what boxes?  Should we pick some leaders of Red Hat engineers and
> community members to have full root?  If so should it be of a set
> number, similar to the FESCo?  I lean towards this setup because it
> allows more people to participate sooner (without having to prove
> themselves as much) but it will keep those with full root access to
> the box low.

I think the majority of people tended to agree that areas of focus would 
be good for the group.

I am not sure moving to a set number of people with root is necessarily 
good.  I think it could lead towards an inflexible process.  I would 
start with a smallish group - but large enough to have someone available 
without causing long delays in critical troubleshooting (i.e. being a 
volunteer group has some unique considerations as to availability).

Once the smaller group is established requests for access are 
distributed as needed.  The members of focus groups are given access via 
permissions to areas they need more control of.  We can probably cover 
many of the areas you mention above in that manner.

I will give some more thought and see if I can post some more specific 
ideas.

-Jeffrey