CVSNT
Introduction
CVSNT (which does
not stand for "CVS for NT") is a rewrite of the open-source CVS source code management, with enhancements
such as atomicity (CHECK), support for the SSPI protocol to authenticate users
against the NT user list (the legacy pserver protocol is also available), and encryption
of the data stream
(using the -x flag.)
Pros
- Open-source, and used world-wide by a lot of developers: Little risk
of CVS going down the drain
- Under active development
- Server and client programs available for different OS's
- ASCII-based (RCS) repository: Little chance of file corruption and files
can be accessed by other SCM software lowering the cost of switching to
another SCM software
- Atomicity? (standard CVS doesn't provide this)
- Good performance over WAN links
- Allow file/directory renaming? "This is the simplest way to move
a file, it is not error-prone, and it preserves the history of what was
done. Note that to access the history of the file you must specify
the old or the new name, depending on what portion of the history you are
accessing. For example, cvs log old will give the log up until the
time of the rename."
Cons
- Addded?
No atomic changes: If, for some reason, the check-in fails halfway through,
CVS cannot rollback changes made to the first half
- Documentation is widely available, but is generally incorrect and/or
outdated
No change control, ie. assigning a label when checking in more than
one file and logically link those changes as one set of changes
see this
entry in the manual
- GUI clients such as WinCVS not that good. Try TortoiseCVS
- If you don't mind having CVS/ directories spread all over your sandbox
:-)
Setup
It is highly recommended that the repositories be located on the same host
where the CVSNT server is running. While the server can be located on any filesystem,
the repository should (must?) be located on an NTFS filesystem. It is also highly
recommended that repositories and directories/filenames that will be placed
in repositories do not contain spaces. Educate your users :-)
If using the SSPI protocol, each authorized user needs to have NTFS permissions
to the CVS files on the server. Read-write users need "full control."
Same applies to the temporary folder specified in the CVSNT control panel applet.
Server
- Log on as Administrator, and run the installer. In the list of options,
remove all authentication protocols except SSPI (Other protocols are either
non-secure or experimental). If users will connect from a different location,
and no trust relationship or ActiveDirectory is set up, use the legacy,
less secure pserver protocol
- (CHECK) Reboot, even if you installed on W2K. If you do not restart, you will
get a "Repository initialization failed" error when you try to
create a repository. This is necessary because services will not see the
updated system path until after the system is restarted.
- (CHECK: Doesn't seem needed in 2.0.11) Check that the PATH environment variable includes the path to wherever
you installed the CVS binaries, eg. c:\program files\cvsnt
- On an NTFS partition, create two directories, one to hold the file repository (eg. C:\CVSREPO),
a.k.a. CVSROOT, another to hold temporary files (eg. C:\CVSTEMP)
- Open Control Panel, and run the "CVS for NT" applet. If the service is running, stop it
- Check "Repository Prefix", and click on the "..."
button to tell CVS where the repository lives (C:\CVSREPO)
- If you only need to host a single repository in this
CVS server, just click on the Add button, type "/.", and hit OK to add a repository
right under C:\CVSREPO.
You can host more than one repository on
one CVS server, each one located under in C:\CVSREPO\ . As explained in
the NT applet, any change to the list of repositories requires restarting
the CVS service
- Click on the Advanced tab, and tell CVS where to locate the directory for temporary files.
Important: The cvstemp directory must NOT be located in either c:\WINNT\Temp
or anywhere in the "C:\Documents and Settings" tree because these
locations have imposed restrictions on user access in Win2000 and Win-XP!
- If you intend to use the SSPI protocol (recommended), uncheck "Support
ntserver protocol". Note that the setting 'Require Encryption' in the
CVSNT control panel effectively disables pserver as it doesn't support any
level of encryption. It also ensures that clients are using an encrypted
protocol to communicate with the server
- (important) Click on the Apply button
- Go back to the Service Status tab, and click on Start
- Open a DOS box, and run "netstat -an". Make sure there are
applications listening on TCP 2401 and 2402
FYI, to provide access to the repository through the Net, you just need to
open TCP 2401. TCP 2402 (lockserver) is only used by cvsnt itself and is not
used elsewhere. All client communication is done over 2401.
Client
We will use the nice CVS front-end TortoiseCVS instead of WinCVS, as it seems easier to use.
- Download and install the application
- (Steps here?)
- Start | Programs | TortoiseCVS | Preferences : Click on the ".cvsignore"
tab, and input the files that you would not add to the repository, each
extension preceded by a space (eg. *.exe *.ocx)
- Click on the Main tab, and set the diff program you'll want to use to
compare changes graphically. Click OK to close.
- Launch Windows Explorer, and right-click on a folder that contains files
(and sub-directories) whose contents you want to add to the CVS repository
- In the pop-up menu, choose CVS, followed by "Make new module..."
- In the dialog box, Protocol = Windows authentication (:sspi:), Server
= host on which CVSNT was installed, Repository folder = /. (or /test if
you set up a repository as a sub-directory under C:\REPO). If the username
under which you are logged doesn't match a user account set up on the CVSNT
server, fill the "User name" field (you will be prompted for the
password at the next step). Hit OK.
This new set of files will be added under C:\REPO, in
a sub-directory that matches what you typed under Module in the previous
dialog (by default, the name of the directory where the contents live)
- Next, right-click a second time on the directory where the contents are
located, and choose "CVS Add Contents...". By default, all the
contents are checked, but you can ignore some of them. Click OK
- Use your favorite development tools, and modify any file in the directory
- Once you're done, right-click on the
directory (so all the files that were modified will be commited in one go),
and choose "CVS Commit..."
- Add a comment that will be shared among all the files to be commited.
Click OK
Done! You have successfully installed CVSNT, followed by TortoiseCVS, the
GUI front-end to CVS, added files to the repository, and commited changes :-)
Using pserver authentication
Creating CVS user accounts
In case you prefer to use pserver authentication instead of sspi (eg. you
need to work from home, so don't want to bother with cross-domain NT authentication.
Note, however, that if the CVSNT is a workgroup server, it just takes a password
to log on from a remote host since TortoiseCVS lets you specify the username
in the dialog box), make sure
you included this protocol when installing CVSNT (reinstall CVSNT if you removed
the DLL), and do the following:
- On the CVS server, log on with an NT administrator account
- Create a user on this NT host (Control Panel, etc.), eg. cvsuser
- Open a DOS box
- Set a CVSROOT environment variable to avoid typing it with every single
command: set cvsroot=:pserver:localhost:/test
- cvs login, and type this admin's password (by default, the admin account
that you used to log on to this NT host is used)
- cvs passwd -a cvsuser
- type a password for this user
There is now a file named passwd in the CVSROOT sub-directory of the test/
repository (c:\repo\test\CVSROOT\passwd). Passwords are hashed using the Unix
crypt() function. To disable a CVS user account, use "cvs passwd -x cvsuser".
To remove a CVS user, run "cvs passwd -X cvsuser". You can also edit
the passwd file in your favorite editor.
Important: When the password field in $CVSROOT/CVSROOT/passwd is omitted or empty, then
the client's authentication attempt will succeed with any password, including
the empty string. However, the colon after the CVSNT username is always necessary,
even if the password is empty.
After you enter the password, CVSNT verifies it with the server. If
the verification succeeds, then that combination of username, host, repository,
and password is permanently recorded, so future transactions with that repository
won't require you to run cvs login. (If verification fails, CVSNT will
exit complaining that the password was incorrect, and nothing will be recorded.)
The records are stored, by default, in the file `$HOME/.cvspass' (Unix) or
the Registry (NT). The format human-readable, and to a degree human-editable,
but note that the passwords are not stored in cleartext--they are trivially
encoded to protect them from "innocent" compromise (i.e., inadvertent
viewing by a system administrator or other non-malicious person).
Note that if SystemAuth is set to Yes in CVSROOT/config,
pserver will use NT authentication if a user cannot be authenticated using the
passwd file. Set this to No if you want pserver to stop instead of resorting
to NT authentication.
To avoid creating user accounts both in the NT user database AND in CVS,
you can create a single user in NT, create users in CVS, and have CVS use the
NT account to perform tasks, ie. impersonation. Changes in CVS will be marked
as the CVS user, not the NT user. Here's the command:
- cvs passwd -d :pserver:cvsuser@localhost:c:/repo -r cvsuser -a <login
user name>
where cvsuser is the NT account, and <login user name> is the new CVS
account, which will actually be impersonated as cvsuser.
Alternatively: cvs passwd -a -r <real accountname> <cvs account
name>
Setting admin rights
To allow a CVS user to have admin rights on the CVS repository, create CVSROOT/admin,
and add usernames.
If "SystemAuth = Yes" in CVSROOT/config, the user is considered to be an administrator if they
are listed in the CVSROOT/admin file or if they are in the 'Administrators'
group (NT) or 'cvsadmin' group (Unix). If SystemAuth = No only the CVSROOT/admin file is checked.
Important: CVSROOT/admin should *not* be put under CVSNT
control, as that would be a security risk.
Using sspi authentication
In CVSROOT/config, if SystemAuth=yes, users are validated against the current NT domain, or
against the domain specified in CVSROOT, and only users listed in CVSROOT/passwd
exists are granted access to the repository (in which case, you don't need hashed
passwords in this file, since authentication is handled by NT.)
Configuration files and variables
You edit the administrative files in the same way that you would edit any
other module. Use `cvs checkout CVSROOT' to get a working copy, edit it,
and commit your changes in the normal way.
The repository is split in two parts. $CVSROOT/CVSROOT contains administrative
files for CVSNT. The other directories contain the actual user-defined
modules, each containing its own CVSROOT/ .
CVSROOT
This is an environment variable that must be set so the CVS.EXE client knows
how to connect to the CVS server. Alternatively, you can use the -d switch on
the command line to specify this information. The format is:
- :protocol:[domain\]userid@server:repository
eg.
- set CVSROOT=:pserver:notes\waynej@goldenrod:d:\cvsroot
CVSROOT/config
SystemAuth
Not set by default. If you wish to use the pserver protocol, set this to
No. If you wish to use the sspi protocol, set this to Yes (in this case, the
passwd file is used to tell CVSNT which accounts in the NT user database are
allowed to connect to it. Since users are authenticated by NT, no password is
set in the passwd file.)
CVSROOT/passwd
A passwd file is located in every repository, not just the top-level CVSROOT
subdirectory under $CVSROOT
$CVSEDITOR, $EDITOR
The environment variable $CVSEDITOR determines which editor is started. If
$CVSEDITOR is not set, then if the environment variable $EDITOR is set, it will
be used. If both $CVSEDITOR and $EDITOR are not set then there is a default
which will vary with your operating system, for example vi for unix or notepad
for Windows NT/95.
CVSROOT/cvswrapper
Used to tell CVS which file extensions map to binary files.
Commands
To login using the CLI CVS
- log on the CVSNT server locally
- set CVSROOT=:pserver:cvsadmin@myserver:/.
- cvs login
- Type the NT password set for this account
To add a user
cvsadmin must be listed in $CVSROOT/CVSROOT/admin before being allowed to
add users?
- If you closed the DOS box, relog in as explained above
- cvs passwd -a jdoe
A passwd file is created in CVSROOT/, with this user name and a hashed password.
To check out a module
- Launch Windows Explorer, navigate to a directory where you would like
the files that make up this module to be checked out from the server
- Right-click on this folder, and choose "CVS Checkout..."
- Choose a protocol (if you followed the install instructions above, only
SSPI is available), give the hostname or IP address of the server where
CVSNT is running, the name of the repository, and the name of the module
you want to checkout (the "Fetch List" button only works if a
web-based application is installed on the CVSNT server to fetch the list
of existing modules)
A subdirectory is now available with the name of the module you selected.
To commit a module
After you worked on files in your sandbox, here's how to check those changes
into the repository on the CVSNT server:
- In your sandbox, folder, right-click on the folder named after the module
- Select CVS Update, to make sure that no one has commited changes to
the same module while you were working on your local copy in your sandbox
- Select "CVS Commit..."
- Add a comment explaining what you did
- If you want to know which changes you made compared to the previous
version of a file located in the repository, right-click on the file, and
choose "Diff..."
- Click OK to commit changes to the repository
To view changes between two revisions
- In your sandbox, right-click on a file, and choose CVS, followed by
History
- Using the SHIFT or CTRL keys, right-click on an older you wish to compare
with the revision in your sandbox
- Choose "Diff (working file)"
User Authentication
CVS-NT supports various methods to authenticate users:
- ntserver: delegate user authentication to NT DCs; all clients must be
NT/2K or XP. As it requires mailslots, very unsafe to use on a server connected
to the Net since that requires opening Windows ports. This is what CVSNT used to use for NT connectivity, but it
is being phased out in favor of the SSPI protocol, which works over TCP/IP
and is more reliable
- sspi: less restrictive than the ntserver protocol; A more secure method
of authenticating using NT domain passwords over TCP/IP. To force users
to connect through sspi instead of pserver, set the StartPServer registry setting to 0 (refer to the CVSNT
readme) and restart the cvs service.
In this mode passwords in the CVSROOT/passwd are ignored.
If SystemAuth=No, the passwd file is used as a list of users who can
use this repository.
Needless to say, if accessing the CVS server
from two different locations, SSPI has the drawback of requiring that you
either share authentication between two domains or via ActiveDirectory,
or suse the same username/password in the two locations.
- pserver: Password server. As it uses its own user database instead of
delegating authentication to NT, this is the most compatible protocol, as clients can be any client
running the CVS client utility. However, it is less secure as passwords
are only hashed using the Unix crypt() function. If you don't intend to use this
protocol, make sure you disable pserver access to remove the security risk
it entails by.
The
name pserver is somewhat confusing. It refers to both a generic framework
which allows the CVS protocol to support several authentication mechanisms,
and a name for a specific mechanism which transfers a username and a cleartext
password.
The reason pserver uses its own user list is precisely
because this protocol is barely secure. Hence, in case a CVS user got his
login/password stolen, a hacker could not use it to have a shell account
on the hosts where CVS is running. This file is `$CVSROOT/CVSROOT/passwd'
(see section 2.4 The administrative files). It uses a colon-separated
format, similar to `/etc/passwd' on Unix systems, except that it has fewer
fields.
CVSNT can also fall back to use system authentication. When
authenticating a password, the server first checks for the user in the `$CVSROOT/CVSROOT/passwd'
file. If it finds the user, it will use that entry for authentication
as described above. But if it does not find the user, or if
the CVSNT `passwd' file does not exist, then the server can try to authenticate
the username and password using the operating system's user-lookup routines
(this "fallback" behavior can be disabled by setting SystemAuth=no
in the CVSNT `config' file
- sserver: 'SSL Server' mode. This works in the same way as pserver
except the entire server communication is encrypted. In other words, sserver
requires its own user list
- ext: External command
- fork: Fork
- gserver: GSSAPI; a generic interface to security services such as
kerberos
- server: RSH client
- ssh: SSH client
- local: Should never be used by CVS clients as accessing raw repository
files will result in corrupt files and dangling file locks; Other protocols
go through the CVSNT service
Backing up a repository
- net stop cvs
- xcopy c:\cvsrepo \\server\cvsbackup /Q /S /C /H /R /O /Y
- net start cvs
In some situations it is a good idea to have more than one repository, for
instance if you have two development groups that work on separate projects without
sharing any code. All you have to do to have several repositories is to
specify the appropriate repository, using the CVSROOT environment variable,
the `-d' option to CVSNT, or (once you have checked out a working directory)
by simply allowing CVSNT to use the repository that was used to check out the
working directory
Accessing CVS through the web
Beautifier
Vocabulary
Repository
Where the source files live on the CVS server. Each time you commit changes,
CVS will determine what the changes are, and only remember those changed from
the previous version.
Module
A set of files
Add
This is what you do when adding a new file to the repository
Import
Same as Add
Checkout
Getting files out of the repository and into a sandbox, ie. a local directory
where you will be working with your usual development tools.
Checkin
Sending changes made to files to the CVS repository after you're through
working with them.
Commit
Same as Check-in
Update
Syncing the files in your sandbox with the revision that lives in the repository.
Used to make sure that you are working with the latest (and possibly) greatest.
If someone checked in changes while you were working in your sandbox, the CVS
client will try to merge this new stuff from the repository into your local
version. If it fails, which happens if someone changed the same line as you
did, you'll have to resolve this conflict manually, choosing which change to
keep.
Show Edited Files
Edit/Unedite
Make Patch
Update Special
Tag
"At a given stage of development, giving one or more files a common label that
refers to their revisions, is known as tagging those files. Tagging is typically
used on entire modules, so that the current state of the module can be
reconstructed in the future. This kind of tagging should always be done on
project deliverables, and before starting major changes. "
Branch
Merge
Weg Log
History
Revision Graph
Remove
Q&A
Does Add recursively in Tortoise respects directory structure?
Check to see if sub-directories are created in the module on the CVS server
Does CVSNT support fetching a list of modules?
TortoiseCVS provides a "Fetch list" button to download a list of
available modules from the server, but it attempts to connect to a web-based
viewer. Any way to get the list directly?
How to forbid users from creating new repositories?
From TortoiseCVS, if a repository cannot be found, a new one can be created.
To forbid this, is the solution to use the admin file to reserve this option
only to admin users?
How to find answers in the mailing list archives?
Can we use a fully-qualified path to the repository?
set CVSROOT=:pserver:notes\waynej@goldenrod:d:\cvsroot
I get an error. Tried d:/cvsroot, d://cvsroot, d:\\cvsroot,
to no avail. Must use eg. /. instead
Can revision numbers start at 1.0 instead of 1.1?
Can I set site-wide config infos in $CVSROOT/CVSROOT...
... and expect those infos to be used as default in other repositories below?
How to add an authentication protocol on an existing CVSNT server?
If you wish to add pserver after using sspi, you just need to build the password
file. If you removed the ad hoc file pserver_protocol.dll, you'll have to reinstall
CVSNT, and add the password file required by pserver.
Why the need to "Add Contents" before "Commit" when
adding new files to the repo?
And is it normal that revisions start at 1.1 instead of 1.0?
Once installed, how can I remove such and such authentication scheme?
Disabling any protocol on the CVSNT server is normally done by physically
deleting the corresponding xxx_protocol.dll file from the CVSNT programs directory.
To remove the pserver protocol, erase the pserver_protocol.dll.
Note that the setting 'Require Encryption' in the CVSNT control panel effectively
disables pserver as it doesn't support any level of encryption. It also
ensures that clients are using an encrypted protocol to communicate with the
server.
Diff betwen server and sserver?
server_protocol.dll
sserver_protocol.dll
With SSPI, how to limit logon to only certain users?
When used, normally sspi will accept connections from all system users that
authenticate against the system (local or domain). Often this is not really
what we want, instead we want to use the same mechanism as is used with :pserver:.
Here the CVSROOT/passwd file limits the logins accepted by CVSNT to those
mentioned in the file.
Meaning of stuff in the Control Panel applet
Encryption: Optional, Request Authentication, Request Encryption, Require
Authentication, Require Encryption
Compression: Optional, Request Compression, Require Compression
Why one port for CVS, and a second for the Lock Server?
The reason you need to create the LockServer is that you cannot set a repository
directory to read only because CVS needs to be able to create lock files for
each operation even if the operation is not going to modify the repository.
These lockfiles are normally stored in the repository itself and if it is read
only then the operation fails.
How should I set up NTFS permissions on my repository?
Read this.
Resources
Temp stuff
On the client host (which can be the same host where the CVS server
is running), open a DOS box, and type:
set cvsroot=:ntserver:<computername>:/TEST
cvs
passwd -a <your NT username>
... where computername is either
the computer's hostname (ie. not "localhost") or its IP address.
If using the pserver protocol instead of the ntserver protocol, and for
security reasons, make sure you choose a password that is different from
that user's NT domain account (if any.) CVS will now create a file named
"password" under $CVSROOT/test/ . Note that this CVS user account
must match an NT user account; otherwise, use "cvs passwd -a -r <real
accountname> <cvs account name>" to create an alias.
Check that you can log on the CVS server by opening a DOS box, and typing:
set
cvsroot=:pserver:<user>@<computername>:/TEST
cvs login
(enter password on prompt)
cvs ls -l -R
... where the last
command should return a list of the files located under $CVSROOT/test/ .
Use an env't variable to make the CVSROOT variable permanent
Old, complicated stuff
Create a CVSROOT environment variable that contains the following: :local:c:/cvs
Create a HOME environment variable for the user account under which
CVS will run (eg. the SYSTEM account), and set it to C:/
Check that variables TMP and TEMP exist and point both to the same folder,
eg. C:\WINNT\TEMP, that the folder exists, and is accessible in read-write
mode by the user account under which the CVSNT service will run
Create the CVS root folder, eg. C:\CVS
Open a DOS box, and run "ntservice -i c:\cvs"
Depending on which version of CVSNT you are using...
Launch the CVS applet either trough a DOS command ("cvsservice
-i c:\cvs") or the Control Panel
Start the CVS service ("net start cvs") or Control Panel
Initialize CVS ("cvs init") or Control Panel
Choose which authentication protocol to use, and set things up accordingly
pserver:
Create an empty $HOME\.passwd file
Decide if you wish to use domain passwords (not recommended
as pserver transmits data in an easily crackable format) or CVS
passwords
Check out the config file in the CVSROOT module: mkdir sandbox;
cd sandbox; cvs -d :local:c:/cvs checkout CVSROOT; cd CVSROOT
Edit this file through cvs -d :local:c:/cvs commit, and change
the line that says SystemAuth: Set it to "yes"
(without the quotes!) to use domain password; Set it to "no"
to use the CVS passwords saved in the passwd file:
If you choose to use the NT domain authentication, CVS will
use the domain name of the host on which it is running, but
you can use a different domain name for a given user using a
field in the passwd file (eg. this user's entry in the passwd
file will look like this: joe:!SOUTHPARK, where SOUTHPARK is
a domain name). Use "cvs passwd" to edit the passwd
file
If you choose to use CVS passwords, create a file named
passwd in the CVSROOT directory. Remember that this file should
never be checked into the CVS repository
ntserver:
Make sure that each user is authorized to access the NTFS partition
and files of the CVS repository
Install either the command-line utility CVS.EXE or GUI-based alternatives
eg. WinCVS
Set the CVSROOT variable to indicate which authentication protocol to
use, which NT domain you belong to (if different from the one to which the
CVS server belongs), your user account, the hostname of the CVS server,
and the path to the file repository on the server. This setting is set through
an environment variable (CVS.EXE) or through a configuration menu (WinCVS:
Admin | Preferences, General tab):
:pserver:MYNTDOMAIN\jdoe@mycvsserver:c:\the_cvs_repository_on_the_server
(in WinCVS, choose "Authentication" = "passwd",
and "Use version" = "cvs 1.10 (Standard)" )
:sspi:MYNTDOMAIN\jdoe@mycvsserver:c:\the_cvs_repository_on_the_server
:ntserver:tiger:c:/cvs (in WinCVS, choose "Authentication"
= ntserver, and "Use version" = cvs 1.10 (NT server) )
If using the ntserver authentication, users do not need to log on to
the server as the CVS server will query the DC to check user credentials,
but must open a DOS box and run "net use \\CVSMachineName /user:CVSServerDomainName\userName"
if their host is located in an NT domain that is different from the one
where the CVS server is runnning.