SAC TODO List

Short Term

• Get LDAP user authentication working on all configured servers with the possible exception of the LDAP server itself.
• Share network user directories between systems.
• Define SAC:Security Groups Policy
• Come up with a procedure for creating new users, and altering user groups reasonably conveniently.
• Setup SVN server(s).
• Hook up Apache to do LDAP authentication as well, so things like a subversion repository or just a dumb folder of files can be authenticated in the same way as everything else.
• The LDAP needs to be doing SSL, or be firewalled to only talk to internal TelaScience machines
• Admit more volunteers to SAC.
• Get some appropriate DNS entries under .osgeo.org pointing to the SAC systems. Stuff like svn.mapbender.osgeo.org perhaps.
• Build a Membership Application.

Longer Term

• Setup/migrate mediawiki.
• 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.