Difference between revisions of "SAC TODO List"
(mark as stale) |
(cleanup, new link to trac tickets) |
||
| Line 1: | Line 1: | ||
| − | '''This page is stale, todo items now primarily kept in [http://trac.osgeo.org/osgeo/query?status= | + | '''This page is stale, todo items now primarily kept in [http://trac.osgeo.org/osgeo/query?status=assigned&status=new&status=reopened&component=Systems+Admin&order=priority Trac]''' |
| − | == Short Term == | + | == Short Term == |
| − | |||
* Share network user directories between systems. | * Share network user directories between systems. | ||
* Define [[SAC:Security Groups Policy]] | * Define [[SAC:Security Groups Policy]] | ||
| − | |||
| − | |||
| − | |||
| − | |||
* Admit more volunteers to SAC. | * Admit more volunteers to SAC. | ||
| − | |||
* Build a [[Membership Application]]. | * Build a [[Membership Application]]. | ||
== Longer Term == | == Longer Term == | ||
| − | |||
| − | |||
* Setup buildbot master system. | * Setup buildbot master system. | ||
* Define backup strategy and put into operation. | * Define backup strategy and put into operation. | ||
Latest revision as of 11:38, 17 September 2011
This page is stale, todo items now primarily kept in Trac
Short Term
- Share network user directories between systems.
- Define SAC:Security Groups Policy
- Admit more volunteers to SAC.
- Build a Membership Application.
Longer Term
- Setup buildbot master system.
- Define backup strategy and put into operation.
Issues to bear in mind
(This is content moved from the Infrastructure Working Group page after SAC was formed)
Knowledge Transfer
This group is going to need to document procedures, locations of things, and so forth quite carefully so that stuff doesn't get completely forgotten, and so that we aren't too limited to one person to fix things. This will require dicipline but will be important.
Permissions Management
We will need a way of managing the permissions level of various OSGeo members. It is planned that an LDAP server will be used to handle the user database (a distinct list from those at CollabNet for now). But does this address how we delegate permissions to different people? How do we decide who has login permissions on test systems for instance, or who has update permissions in a given Plone instance?
Some categories of permissions we need to address:
- Some systems would only provide login access to the system administration working group. These systems we would hope could be very stable.
- Login on some systems, such as test systems would need to be very widely available, essentially to all OSGeo project developers for testing. Presumably normal developers would not require root access, but we could still assume these systems are likely to be subject to damage and need to be fairly easily recreated.
- We may also want "Project" systems, roughly owned by a single project with appropriate project staff having full (ie. root) permissions. Can we provide some sort of virtualization to offer roughly this to people? Perhaps "chrooted jails"? This might be the sort of place that projects would have automated scripts running to create nightly snapshots, re-create projects web pages or whatever.