Website:Subversion
From UGCS
(Difference between revisions)
| Line 1: | Line 1: | ||
| − | + | =Status= | |
| − | + | ||
Pending code review, this service is ready to be considered beta, meaning we know of no reason it wouldn't be stable but it is not yet thoroughly tested. | Pending code review, this service is ready to be considered beta, meaning we know of no reason it wouldn't be stable but it is not yet thoroughly tested. | ||
| − | + | =For Users= | |
| − | + | ==Configuration== | |
To set up your subversion on UGCS: | To set up your subversion on UGCS: | ||
* Make the directory ~/public/svn, if it doesn't already exist (mkdir ~/public/svn) | * Make the directory ~/public/svn, if it doesn't already exist (mkdir ~/public/svn) | ||
* Give user svn permissions on it (fs sa ~/public/svn svn rlidwka) | * Give user svn permissions on it (fs sa ~/public/svn svn rlidwka) | ||
* Create/move repositories somewhere under ~/public/svn | * Create/move repositories somewhere under ~/public/svn | ||
| − | |||
* Set up users and permissions in ~/public/svn/REPOSITORY/conf [see below for help] | * Set up users and permissions in ~/public/svn/REPOSITORY/conf [see below for help] | ||
* Access your repository ~/public/svn/REPOSITORY at any of the following: | * Access your repository ~/public/svn/REPOSITORY at any of the following: | ||
| Line 15: | Line 13: | ||
** svn://svn.ugcs.net/USERNAME/REPOSITORY | ** svn://svn.ugcs.net/USERNAME/REPOSITORY | ||
** svn://svn.ugcs.net/~USERNAME/REPOSITORY | ** svn://svn.ugcs.net/~USERNAME/REPOSITORY | ||
| − | + | * NOTE: Make sure you use fsfs for the storage mechanism when creating the repository. This is currently the default, but you can pass --fs-type fsfs to svnadmin to be on the safe side. If you don't know what this means, just follow the above directions and you'll be fine. | |
| + | ==Tutorial== | ||
* If you don't have it already, create ~/public/svn. and type: fs sa ~/public/svn svn rlidwka | * If you don't have it already, create ~/public/svn. and type: fs sa ~/public/svn svn rlidwka | ||
* Anything in ~/public/svn will be accessible at svn://svn.ugcs.caltech.edu/USERNAME. You can also use svn://svn.ugcs.net/USERNAME. A tilde before the username is optional but not required. | * Anything in ~/public/svn will be accessible at svn://svn.ugcs.caltech.edu/USERNAME. You can also use svn://svn.ugcs.net/USERNAME. A tilde before the username is optional but not required. | ||
| Line 29: | Line 28: | ||
** Done! You can access your new repository at svn://svn.ugcs.caltech.edu/USERNAME/REPOSITORYNAME | ** Done! You can access your new repository at svn://svn.ugcs.caltech.edu/USERNAME/REPOSITORYNAME | ||
** Note: You will need to add an entry for yourself in the passwd file as well, it is NOT the same as your ugcs password. DO NOT REUSE YOUR UGCS PASSWORD! Since you only have to enter the svn password once on your computer (svn will remember it for that repository), the first time you access the repository on a given machine, choose something strong; you can always check the passwd file later if you forget. | ** Note: You will need to add an entry for yourself in the passwd file as well, it is NOT the same as your ugcs password. DO NOT REUSE YOUR UGCS PASSWORD! Since you only have to enter the svn password once on your computer (svn will remember it for that repository), the first time you access the repository on a given machine, choose something strong; you can always check the passwd file later if you forget. | ||
| − | + | =Sysadmins= | |
Poseidon runs our subversion server as user svn, which is both a local and an AFS/kerberos user. | Poseidon runs our subversion server as user svn, which is both a local and an AFS/kerberos user. | ||
| − | + | ==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. | * /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/. | * ~/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/. | ||
| Line 38: | Line 37: | ||
* poseidon:/etc/init.d/svn - script written to start and stop svn. Makes use of /usr/local/sbin/start-svn | * poseidon:/etc/init.d/svn - script written to start and stop svn. Makes use of /usr/local/sbin/start-svn | ||
* poseidon:/usr/local/sbin/start-svn - script to start svn and flush all volumes of svn-using users. | * poseidon:/usr/local/sbin/start-svn - script to start svn and flush all volumes of svn-using users. | ||
| − | + | =Bugs/Issues= | |
| − | + | ==Presumed 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. | * 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. | ||
** 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. | ** 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. | ||
*** 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. | *** 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. | ||
| − | * Despite instructions to the contrary in kadmin and in the init script, svn will eventually get permission denied errors. This is presumed due to ticket expiration. I have added a daily restart to svnserve once per day to poseidon's crontab. A better fix would be nice but this should do for now. | + | * Despite instructions to the contrary in kadmin and in the init script, svn will eventually get permission denied errors. This is presumed due to ticket expiration. I have added a daily restart to svnserve once per day to poseidon's crontab. A better fix would be nice but this should do for now. Please fix to win two internets. |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | Please | + | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
Revision as of 05:13, 16 February 2009
Contents |
Status
Pending code review, this service is ready to be considered beta, meaning we know of no reason it wouldn't be stable but it is not yet thoroughly tested.
For Users
Configuration
To set up your subversion on UGCS:
- Make the directory ~/public/svn, if it doesn't already exist (mkdir ~/public/svn)
- Give user svn permissions on it (fs sa ~/public/svn svn rlidwka)
- Create/move repositories somewhere under ~/public/svn
- Set up users and permissions in ~/public/svn/REPOSITORY/conf [see below for help]
- Access your repository ~/public/svn/REPOSITORY at any of the following:
- NOTE: Make sure you use fsfs for the storage mechanism when creating the repository. This is currently the default, but you can pass --fs-type fsfs to svnadmin to be on the safe side. If you don't know what this means, just follow the above directions and you'll be fine.
Tutorial
- If you don't have it already, create ~/public/svn. and type: fs sa ~/public/svn svn rlidwka
- Anything in ~/public/svn will be accessible at svn://svn.ugcs.caltech.edu/USERNAME. You can also use svn://svn.ugcs.net/USERNAME. A tilde before the username is optional but not required.
- To create a new repository in less than two minutes:
- type: cd ~/public/svn
- type: svnadmin create REPOSITORYNAME --fs-type fsfs
- type: cd REPOSITORYNAME/conf
- edit the file passwd. At the bottom, in the users section, add one line per person who needs to be able to access the server. Each line is formatted like USERNAME=PASSWORD. Don't forget to include one for yourself.
- edit the file svnserve.conf. Add the following under the [general] section:
- anon-access = none # Can also be read or write to let anyone in the world perform that op.
- auth-access = write # Can also be read or none to control what users in the passwd file can do. Write permission implies read permission
- password-db = passwd
- Done! You can access your new repository at svn://svn.ugcs.caltech.edu/USERNAME/REPOSITORYNAME
- Note: You will need to add an entry for yourself in the passwd file as well, it is NOT the same as your ugcs password. DO NOT REUSE YOUR UGCS PASSWORD! Since you only have to enter the svn password once on your computer (svn will remember it for that repository), the first time you access the repository on a given machine, choose something strong; you can always check the passwd file later if you forget.
Sysadmins
Poseidon runs our subversion server as user svn, which is both a local and an AFS/kerberos user.
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. Makes use of /usr/local/sbin/start-svn
- poseidon:/usr/local/sbin/start-svn - script to start svn and flush all volumes of svn-using users.
Bugs/Issues
Presumed 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.
- 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.
- 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.
- 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.
- Despite instructions to the contrary in kadmin and in the init script, svn will eventually get permission denied errors. This is presumed due to ticket expiration. I have added a daily restart to svnserve once per day to poseidon's crontab. A better fix would be nice but this should do for now. Please fix to win two internets.
