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
