SVN

Sysadmins

Poseidon runs our subversion server as user svn, which is both a local and an AFS/kerberos user. See http://www.ugcs.caltech.edu/svn/svn/ for files

Nagios tests

• TCP port 3690
• Makes sure the svn k5start process is running
• Makes sure the svn process is running with the k5start process as its parent

Important Files

• /afs/.ugcs/svn - The svnroot. Contains symlinks to every user's ~/public/svn, whether or not it exists. Links are both ~USERNAME and USERNAME so either will work. These have been retroactively created for all users with a home, and the account creation scripts have been modified to create one for all new users.
• ~/public/svn - Created at account creation as of 2009-FEB-11. Not retro-created. Has acl rlidwka for user svn. Mapped to svn://svn.ugcs.caltech.edu/USERNAME/ and svn://svn.ugcs.caltech.edu/~USERNAME/.
• clio:/usr/local/bin/svnadmin - If invoked attempting to create a bdb-backed svn-repository (a non-default option known to break on AFS), warns the user that this is unsupported and will cause issues, and asks whether to continue. Otherwise acts like normal svnadmin. This is a short python script that calls /usr/bin/svnadmin.
• poseidon:/etc/keytabs/svn.keytab - keytab for the svn account
• poseidon:/etc/init.d/svn - script written to start and stop svn.

Bugs/Issues

Fixed

• Initially, sometimes after doing checkout / restart svn / make change / checkin / restart /checkout and similar sets of steps, some files in the user's volume will begin getting permission denied errors. This will occur when accessed as the user or as svn, but only on poseidon, on other hosts it behaves normally. You can fix it by renaming the offending files (on poseidon or elsewhere) the naming them back. (2009-02-08)
  • Since we went to separate process svnserve instead of threaded, and added kdestroy and unlog in the stop script, this has not recurred to my knowledge. (2009-02-10)
    • Began having these issues again. I added in instructions to flush all svn-using users' volumes on svn start, which appears to fix the problem. As in, I was able to reliably recreate it, did this, and now can no longer get it at all.(2009-02-15)
      • Continued to have issues. Now flushes svn user volumes once per minute. Should work now (2009-02-15)
        • Reverted all of the above to actually solve the problem. k5start expects the process it starts not to terminate, as the wrapper script was doing. Should work now (2009-02-15). Cronjob to restart svn once per month, as the tickets it gets are only issued for 1 year.
          • Found that despite my instructions, the ticket still expires in 10 hours. We now restart svn every 8 hours. Should eventually fix, but for now it works. Good enough to go public.