Re: [Fedora-infrastructure-list] Security, access and the config CVS
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