Overview

Our publically-accessible CVS repositories are situated differently depending on whether or not external folks are going to have write access. Public access to any of the repositories are via cvs.zope.org, the difference is where the master copy of the repository resides:

Internal-only writes

The master copies of the repositories that are only for writing by digital creations folks are mirrored to the public host from our internal cvs repository (at time of writing, korak:/cvs-repository but that should soon change). DC folk can access them directly by logging into a system inside the DC firewall and using direct, file-system firewall or SSH-mediated access to the internal host. An automated system (hooked into the CSV checkin mechanism, and also running separately to catch any strays) synchronizes the internal master copy of the repository with the external copy on the public host.

External and Interal-write Repositories

The master copies of the repositories are situated on the public host, cvs.zope.org. DC folk and the external folk all do their writes via SSH-mediated CVS access. Below are instructions for setting up a targeted public-write repository and adding users privileged to access it.

Public targeted public-write CVS

Creating a new respository section

There are three things you have to do, all on cvs.zope.org and all requiring root access.

• Add a group for the repository, using the groupadd command. Some example groups are zopemoz, docscvs, zopeptk.
• Add the repository directory. In /cvs-repository, create the directory, set the mode to 2777 (sticky gid), and set the user to dccvs and the group to the group you created for the repository section.
• Include the path to the repository in the string value for the TARGETS variable in the /usr/local/etc/wwrite script. (As with the wide-open permissions, use of this script is a bit of a kluge - it runs every few minutes and enforces the permissions that allow writing in this scheme.)

Create and authorize the user, if necessary

You also do this on cvs.zope.org as root, using a script created for the purpose. For external users you have to create an account that is locked into SSH-mediated cvs-only access. (Internal DC folk can use one of these special accounts, as well, or they can get a regular account set up with RSA-based ssh authentication, and use that for their SSH-mediated CVS checkins.)

• On cvs.zope.org, as root:

  /usr/local/etc/addcvsuser username group[,group,...] [ personal name ... ]

  Where the groups are supplemental groups, separated by commas (and no whitespace) to which the user should be added, and personal name is any trailing tokens which are taken as the real name of the user.

  Use a lone comma to specify no supplemental groups. Specified supplemental groups that do not already exist are created, after prompting.

  The script will prompt you for other information, including the SSH RSA public key - the line exactly as you would put it in the authorized_keys file for the user. (The script actually creates the .ssh/authorized_keys file, if it doesn't exist, and situates the line such that the user can only use that key for remote CVS commands - via CVS :ext: mode. See the targeted public-write instructions for details on using that scheme.)

Add an existing user to the group for the repository

You can also use the addcvsuser to add an existing user to a group for some repository - see above.

Hooking up checkin email notifications

We use hooks in the CVS bookkeeping (cvs co CVSROOT) to do things like automatic propagation of changes from our internal repository to the public one, and more relevant here, dispatching of change notices via email. The file traffic_table.py specifies the "routing" for repositories. Fairly low-level, it's used as a python module, with the settings in python dictionaries. See the module for examples and instructions, and talk with ken - he doesn't have time right now to document it further, alas.

To Be Done

• We need to scope out the permissions and set things so only group write is needed, not world write! Someone needs time to poke around and do this, that's all. Then the /usr/local/etc/wwrite script can be changed, and the permissions can be set to be more restrictive (and not allow users of one of the public repositories to get write access to another!)
• The addcvsuser script interface is awkward, at best. It would be nice to have some more comprehensive user manager tool.
• Change the traffic_table arrangement to use a simple ConfigParser (standard python module) style config files in the module's root dir. This way, the info about the module is specific to it. This situates the info about the module in the right place, and means that (1) the module maintainer can control the email and propagation destinations, and (2) the info about the module is propagated only where the module is propagated.