Community technical support mailing list was retired 2010 and replaced with a professional technical support team. For assistance please contact: Pre-sales Technical support via email to sales@march-hare.com.
<I know this is old news, but I struggled with getting pserver going for a long time. Some of the problem was due to inexperience, some it was due to the fact that the documents in the Wiki are quite brief in dealing with this topic. Basically, I just didn't get what was going on and I had to accumulate more CVS wisdom before I could see what I needed to do. At any rate, I am posting this in the hope that someone will find it useful.> These instructions spell out one method for getting pserver to work in a fairly secure fashion. The goal is to have all CVS users authenticate against CVS using just the pserver password file (cvsroot/passwd), avoiding both the need for local logins on the NT server hosting CVS NT and the need to enter a (very valuable) NT domain password into the lightly-encrypted pserver password file. In this scheme, all CVS users are aliased to a single local login (namely cvsuser) on the CVSNT machine. CVSNT itself uses the NT SYSTEM login to perform repository operations. Here is a diagram of what happens. Remote machine passwd file CVSNT host machine CVS user------------------------------>cvs login sam, password <secret1>---------->sam secret1 cvsuser------->CVSNT (logs operations as user sam) Phase 1: Set up the local users 1. Using the computer management applet (reached from the control panel), create a cvsadmin group and give it full access to the repository, including the 'CVSROOT' administration directory. For example, if the repository is c:\cvsrepo, then the cvsadmin group should have full access to d:\cvsrepo all all its subdirectories. 2. Create a cvsusers group and give it full access to the repository root, but NOT the 'CVSROOT' administration directory. 3. Create a cvsuser local user and make that user a member of the cvsusers group. 4. Create a cvsadmin local user and make that user a member of the cvsadmin group. You will probably want to give this user some fairly hefty NT priviliges, as well. 5. Validate the cvsadmin user by logging to the NT machine as that user and making sure you can read and write files in the repository directory. 6. Validate the cvsuser user by logging in to the NT machine as that user and making sure you can read and write files in the repository root directory. I am not sure about how CVS handles the absence of these local users, but I think that if a user is not a member of the cvsusers group, CVSNT disallows addition of that user to the passwd file and cvs passwd -a issues a 'user is not a real user error message'. Phase 2: Create the pserver password file (passwd) and add the local users just created to that file. 1. Important! Go to the cvsroot directory and edit the config file. Change the line reading #SystemAuth=yes to SystemAuth=no That is, remove the comment indicator (#) and change the yes to no. The SystemAuth switch determines whether or not CVSNT will use Windows user authentication (either local logins or domain logins) to authenticate access to the server. Bo Bergland's 'CVSNT Installation Tips' suggests that you leave SystemAuth set to 'Yes' (the default) because this will eliminate the need to add yourself to passwd as a CVS user. In my experience using SystemAuth=yes in this way was problematic, and I still ended up needing to add myself to the passwd file as a CVS user. (On reflection, this is of course because I turned off SystemAuth and restarted CVS, so sspi was looking in the passwd file.) Also, the aliasing scheme we want to set up simply won't work if we let Windows authenticate the CVS users--because that forces logins to be real local users on the NT machine, not aliases. Note that aliasing rules out the use of Windows NT file protection to fine-tune user access to the repository, so you have to make some choices here. Aliasing is a good choice when your CVS users are "completely non-trusted" in the sense that you don't want to give them a login on your domain or a login on your CVSNT machine. 2. Important! Go to the CVSNT service control panel and uncheck all of the checkboxes on the 'advanced' tab. 3. Important! Stop and re-start both the CVSNT service and the lock service. 4. Open a DOS window and give yourself access the repository in local mode, as follows: set cvsroot=:local:c:/cvsrepo/main 5. While in local mode, add cvsadmin to the admin file (cvsroot/admin). If you don't do this, CVSNT will disallow any additions to the passwd file as these can only be performed by a CVS administrator. After editing the admin file, you will need to stop and restart the CVSNT services. 6. Add your real users to the passwd file using the cvs passwd command. Here are some examples. cvs passwd -a cvsadmin password:<mysecret1> password:<mysecret1> cvs passwd -a cvsuser password:<mysecret2> password:<mysecret2> Phase 3: Create the aliases for the local users. 1. Change your CVS access protocol to pserver by changing your cvsroot environment variable. set cvsroot=:pserver:cvsadmin@<server machine>:/main 2. Log in to CVS as the CVS administrator cvs login cvsadmin passwd:<mysecret1> passwd:<mysecret2> If CVS allows you access without complaining, you may congratulate yourself. If you get an error message like CVS refused access to :/main, you have probably failed to set the username in cvsroot. Unfortunately CVSNT doesn't override the username specified in the cvsroot environment variable with the username supplied in the cvs login command line. It works the other way. 3. Alias the CVS users to the cvsuser you created in the preceding steps. Write the passwords you use down (temporarily, obviously) so you can give them to the users. cvs passwd -a -r cvsuser sam password:<samsword> password:<samsword> cvs passwd -a -r cvsuser tom password:<tomsword> password:<tomsword> 4. Test your work by logging out and then logging in using an alias and password you just created. cvs logout cvs login sam password:<samsword> password:<samsword> If you get to this point, all is well and you can have your (aliased) CVS users import source code, set up sandboxes, etc. Notes: 1. It is important to understand the difference between aliasing and impersonation. Aliasing means that a CVS user is matched to a local user on the CVSNT server (usually cvsuser) and then CVS does operations for that local user. CVSNT itself still does its work as the SYSTEM user. Impersonation means that instead of CVSNT accessing the OS to do its work as the SYSTEM user, it access the OS as the authenticated local user. Aliasing refers to front-end authentication into CVS, impersonation refers to back-end access by CVS to Windows NT. You can have aliasing without impersonation, and you can also have impersonation without aliasing. My recommendation is that you get aliasing going and worry about impersonation (if you need it) at a later date. 2. IMHO, the documents in the Wiki give mixed messages about SystemAuth=no and the need to set yourself up as a user. If you are using 'CVSNT Installation tips' you should read the notes regarding the SSPI protocol carefully, as Bo supplies some useful information about SystemAuth in that section. You should also consult the write up on the config file at http:/durak.org/cvswebsites/doc/cvs_177.php 3. As far as I know, the information in the Wiki documents is both clear and correct--at least I haven't found anything wrong or unclear. However, the documents ARE densely packed and the first time you set up a CVSNT repository creating pserver users can be pretty frustrating. If you get stuck, the newsgroup and/or the mailing list can be a great help. You may comment on this document either in the newsgroup or by email to me (Scott Warnick) at scott.warnick at NOSPAM dot flyingj dot com.