|
|
|||||||||
WANdisco CVS Replicator makes it possible to have multiple active replicas of a CVS repository that stay in sync. Each repository acts as if it is the local CVS server for the user base. This is achieved via the Distributed Agreement Engine technology underlying WANdisco CVS Replicator.
CVS, which stands for Concurrent Versions System, is a popular open source code versioning system. CVS, like most source code versioning systems, is designed to run as a central server to which multiple CVS clients connect using a CVS protocol over TCP. The CVS server, as implemented, forks a process per client connection to handle a CVS request from the client. This is similar to how the CGI model works for the Web server world. WANdisco CVS Replicator allows you to break the central paradigm and have multiple replicas of the CVS repository.
In this administration guide, you will learn how to easily setup WANdisco CVS Replicator and its Distributed Agreement Engine.
This guide is intended for a CVS administrator or a user who is reasonably comfortable with:
inetd/xinetd service on Unix/Cygwin or CVSNT Windows service
If you don't meet the pre-requisites you may want to contact your CVS administrator or have WANdisco do an install for you.
Ensure that everything is installed on paths with no spaces in the names. For example, on the Windows platforms, the default installation path for java looks like C:/Program Files/java/jdk1.5.0_03.
Choose an alternate installation directory, for example C:/java.
Before running the WANdisco CVS Replicator, please ensure:
license.key file into cvs-replicator/config. Depending upon your license,
certain features may be disabled. This document will highlight any features that require an Enterprise
Edition license.
JAVA_HOME environment variable is defined.
JDK is installed, not just the JRE. This can be confirmed by running java -server -version. If it generates a not found error, uninstall the JRE Java package and reinstall the JDK Java package. You can also setup the PATH to pick up the correct java instead of the the JRE version.
perl executable is on
the system PATH.
cvspasswd tool requires Perl package Term::ReadKey. You need cvspasswd only if you are going to use the :ext protocol.
logtimefix script requires Perl package Date::Manip.
- To install a Perl package on UNIX/Cygwin, using CPAN, for example:
$ perl -MCPAN -eshell cpan> install Term::ReadKey
perl executable is on
the system PATH. Please download the MSI installer for ActivePerl from here: [http://activestate.com/Products/Download/Download.plex?id=ActivePerl]
logtimefix script requires Perl package Date::Manip.
- To install a Perl package on Windows, using ActivePerl package manager, for example:
c:\>ppm ... ppm>install DateManip
importauditdb script requires Perl package Perl::DBI.
validate-local-setup script requires Perl package Term::ReadKey and File::Which.
pserver protocol.
Although the WANdisco CVS Replicator uses the pserver protocol to communicate with the CVS
server, the CVS client can communicate with the WANdisco CVS Replicator using either SSH or PServer
protocol.
cvs-replicator/config/cvsnt/keywords to CVSROOT/keywords for each cvsroot.
Untar or unzip (using WinZip for example on Windows) the WANdisco CVS Replicator package (tar.gz) into the intended subdirectory.
You should see the following directory structure:
$ cd cvs-replicator $ ls audit config lib logs bin docs systemdb
cvsreplicator , shutdown
jar files and DLLs that are required to run the product.
ProxyServer-prefs.log.0.
The WANdisco CVS Replicator supports either an express setup or a custom setup. If this is the first time setting up the WANdisco CVS Replicator, we recommend starting with the express setup method.
If the installation requirements as specified in the previous section have been met, the express setup should take 20 minutes or less to get a basic WANdisco CVS Replicator environment configured.
The express setup option can be used to quickly create the prefs xml configuration file used by WANdisco CVS Replicator. This is accomplished by running the bundled program, cvs-replicator/bin/setup. The text based UI will guide you through basic configuration options.
At the end of the setup program, you would have created a prefs-{hostname}.xml file for each replicator in the replication group. Simply copy the prefs-{hostname}.xml to the cvs-replicator/config/prefs.xml file on the corresponding replicator host.
We will now walk you step by step, through the various setup screens.
setup program:
$ cvs-replicator/bin/setup
prefs.xml configuration file.
=====================================================
Welcome to the WANdisco Replicator's Express Setup
You can use it to setup configuration files used by
WANdisco CVS Replicator.
You will just need to enter the minimum information
required to setup each replicator instance. At the end
of the setup run, you will have a "perfs.xml" for
each replicator. Just copy it to the remote replicator's
config/ directory and start the cvsreplicator.
=====================================================
How many replicas do you want? [2] :
Setting up replicator instance .... #1
______________________________________
Now you will specify the Ethernet MAC address of the host on which
Replicator would be running. It is required that you specify a unique
MAC address for each host on which Replicator would be running.
The MAC address on UNIX can be obtained via "ifconfig" command
and on Windows via "ipconfig /all" command. The MAC Address looks like
this - 00-02-A5-C1-7A-2F (Windows) or 00:02:A5:C1:7A:2F (UNIX). If you
don't have all the MAC addresses handy, now would be a good time to
get them before proceeding further.
Enter the MAC Address :
Setting up replicator instance .... #1
______________________________________
Now you will specify the host:port used by CVS clients to
connect with the Replicator. Setting the port to 2401,
would be the most transparent option from the CVS client
perspective. Note you can NOT specify 0.0.0.0 or localhost
as the the host on which Replicator would be running. The
hostname needs to be the DNS hostname or the valid IP address to
which remote CVS clients can connect.
Enter the hostname or IP address of the Replicator#1 : cvshost.com
You specified cvshost.com, is this correct?[Y|N] [Y] :
Enter the TCP port for the Replicator#1 [2401] :
Setting up replicator instance .... #1
______________________________________
Now you will specify the DConeNet port used by the Replicator to
communicate with other Replicators. This is not visible to CVS
clients but used for actual data transfer between the Replicators.
Enter the TCP port for DConeNet [6444] :
setup program will generate a GUID for the WANdisco CVS Replicator being configured.
Setting up replicator instance .... #1
______________________________________
Now you will specify the cvspserver host:port used by CVS server.
This is typically specified in the /etc/services or inetd file on UNIX.
For CVSNT on Windows, consult the CVSNT documentation. It is recommended
you change the default cvspserver port to something other than 2401 to avoid
operational errors. If the cvspserver is allowed to ONLY run on localhost, do
NOT specify a remote hostname or IP address then just specify localhost. The
default is 0.0.0.0 which means the Replicator and cvs pserver are running on
the same host. If that is not the case, please change it.
Enter the cvspserver hostname [0.0.0.0] :
You specified 0.0.0.0, is this correct?[Y|N] [Y] :
Enter the cvspserver port [2402] :
You specified 2402, is this correct?[Y|N] [Y] :
Generating a GUID for Replicator#1...b1e7b22c-b9ae-11d9-902a-0002a5c17a2f [Done]
Hit Enter to continue ....
Quorum Selection
-----------------
Singleton Quorum optimizes performance at the Distinguished node (which
can be rotated using a cron job or Replicator's scheduler).
Majority Quorum optimizes availability by ensuring a majority of sites
vote on a write transaction first.
Unanimous Quorum requires all sites to be up and running to commit a
transaction. See the DCone Administration Guide for further information.
You can select from the quorum list below:
1. Singleton
2. Majority
3. Unanimous
Choose a quorum [1] :
Which of the following Replicators will be the initial Distinguished Node?
1. cvshost-usa.com
2. cvshost-uk.com
Select the distinguished node [1] :
2 for example in the dialog below.
CVS Server Type Selection
-------------------------
Backend CVS repository can use either standard CVS distribution
or CVSNT distribution. You can use the "cvs version" command to
determine the server version and type.
You can select the CVS server type from the list below:
1. CVS
2. CVSNT
Choose a server type [1] : 2
prefs xml files. The setup program will create the prefs-{hostname}.xml configuration files.
Now you will specify the destination directory where prefs xml file for
each replicator will be generated. Remember to copy the generated
prefs-{replicator name}.xml file to the cvs-replicator/config directory
on each Replicator's host machine. After copying, make sure you
*rename* the file to "prefs.xml". If you forget to rename the
configuration will not take effect!
Enter the directory where prefs xml files will be saved [../config] :
config directory on each host and rename them to prefs.xml. Now you are ready to run the WANdisco CVS Replicator.
Express setup tool supports a -silent and -record option to allow
an admin to perform a silent install without being prompted for input
on the console.
An admin could start the setup program in the record mode
and then latter use the recorded answers file to replay the
answers and perform a silent install. The admin could modify
the recorded answers in a text editor and then use -silent
to create new configuration files. For example
$ ./cvs-replicator/bin/setup -record my-answers $ vi my-answers $ ./cvs-replicator/bin/setup -silent my-answers $ ./cvs-replicator/bin/setup -silent old-ans -record new-ans
The answers are recorded continuously, so if you restart setup you can also use the recorded file to pick up from where you left off, without having to re-enter the answers.
For more information look at the usage of the setup command:
$ ./cvs-replicator/bin/setup -h
setup [-silent recorded-setup-file] [-record file-to-record-to]
-silent recorded-setup-file :
Silent install will use the supplied "recorded-setup-file" to
automatically answer the setup interview questions. If all the
answers are not supplied, it will prompt on the console.
-record file-to-record-to
Will record all the valid interview answers to the
"file-to-record-to". Can latter be used for silent install.
Both options can also be used at the same time. For
example to continue an install from where you last
left off you could do:
setup -silent prev-silent-file -record new-silent-file
In order to use this feature, you must have recorded the answers when you did your initial setup.
Consider the following scenario: The administrator wants to change a 3 site installation to a 4 site installation. In other words bring one more site online.
The administrator can use the silent install as following:
nreplicas="3"
or changing the number from 3 to 4.
$ setup -record answers3sites ... $ vi ./answers3sites nreplicas="3" <== Change 3 to 4 or comment out the line by putting # at the start mac.1="00:08:5B:19:3E:F5" repHost.1="pao" repPort.1="2401" dconePort.1="6444" cvsHost.1="localhost" ...
$ setup -silent answers3sites
answers3sites file. The administrator does not have
to re-answer questions that have already been answered.
We will walk through a setup scenario with minimal changes to the preferences. It is recommended that you use the bundled prefs xml files under cvs-replicator/config. Please browse the cvs-replicator/config/readme-prefs for suggestions on picking an appropriate prefs file for a specific scenario. If you choose to use an existing prefs file you do not need to generate new GUIDs as described latter in this section. Out of the box, the default settings are good enough. Eventually, you may want to tweak some of the advanced performance tuning options.
The scenario assumes you are setting up a two node configuration as below:
To get this scenario working quickly all you need is :
Open the cvs-replicator/config/prefs.xml file in your favorite editor and modify:
Modify the listenerHost:listenerPort in the cvs-replicator/config/prefs.xml file to
the host:port on which the WANdisco CVS Replicator will listen for incoming CVS
client traffic. If you do not want the CVS client to modify
it's CVSROOT, just ensure that the listenerHost:listenerPort
stays the same as the current CVS server settings.
Next, point the serverHost:serverPort to point to the
host:port on which CVS pserver is going to listen to.
If using xinetd.d for launching CVS pserver, you may have
to modify a file with a name like cvspserver to change the
default port (2401) on which CVS pserver will listen on. This
is required to avoid port conflicts when replicator and CVS pserver
are running on the same box.
Here is a sample from cvs-replicator/config/prefs.xml that you can use as an example:
<CVSProxy>
<listenerHost>cvs-host</listenerHost>
<listenerPort>2401</listenerPort>
<serverHost>cvs-pserver</serverHost>
<serverPort>2401</serverPort>
<isCVSNT>true</isCVSNT>
</CVSProxy>
In the above, the same port (2401) was kept for both the
WANdisco CVS Replicator and CVS pserver as they are running on different hosts.
If that wasn't the case you will have to modify the CVS pserver
port if you want the CVS clients to retain their CVSROOT setting.
If changing the xinetd.d file, you would typically change
the port as following:
service cvspserver
{
disable = no
flags = REUSE
socket_type = stream
wait = no
user = root
log_type = FILE /var/log/cvspserver
protocol = tcp
log_on_failure += USERID
# port = 2401
# change port to avoid conflict with WANdisco CVS Replicator's listening port : 2401
port = 2402
server = /usr/bin/cvs
server_args = -f --allow-root=/tmp/cvsroot pserver
}
Sometimes, administrators specify the CVS pserver port in /etc/services:
cvspserver 2401/tcp # CVS client/server operations
In that case, it may be simpler to just change the definition of the cvspserver
port.
#cvspserver 2401/tcp # CVS client/server operations cvspserver 2402/tcp # CVS client/server operations
If you made any changes to /etc/services or the xinetd/inetd configuration files like cvspserver, be sure to restart inetd/xinetd itself. Otherwise the changes will not take effect and you will have trouble connecting with the CVS server.
You will install and setup a WANdisco CVS Replicator for each replica in your configuration. Each WANdisco CVS Replicator needs to be configured to connect with other replicators. We are essentially establishing initial group membership.
Let us say you need to create two replicas - one in San Francisco and one in Bangalore. You will install WANdisco CVS Replicator at each location. Then you will point them at each other as followings:
guidgen utility that is bundled with WANdisco CVS Replicator to
instantiate two GUIDs for the San Francisco and Bangalore data centers.
$ guidgen 2 GUID 0. = c9bcec19-4301-11d9-b12d-080020b0d8b8 GUID 1. = 3bfbf219-2918-11d7-80c5-00065be02953
<ProviderDescriptor>
<DefaultProviderId>3bfbf219-2918-11d7-80c5-00065be02953</DefaultProviderId>
</ProviderDescriptor>
<MemberList>
<Member name="3bfbf219-2918-11d7-80c5-00065be02953">
<Profiles>
<TransportPolicy>AlwaysDConeNet</TransportPolicy>
<Transport>
<DConeNet>
<ListenerIP>sanfranciso-replicator</ListenerIP>
<ListenerPort>6020</ListenerPort>
</DConeNet>
</Transport>
</Profiles>
</Member>
<Member name="c9bcec19-4301-11d9-b12d-080020b0d8b8">
<Profiles>
<TransportPolicy>AlwaysDConeNet</TransportPolicy>
<Transport>
<DConeNet>
<ListenerIP>bangalore-replicator</ListenerIP>
<ListenerPort>6020</ListenerPort>
</DConeNet>
</Transport>
</Profiles>
</Member>
</MemberList>
The first configuration parameter is a DefaultProviderId. This associates a
GUID with the specific data center at which we are setting up the replicator.
In the above cvs-replicator/config/prefs.xml file, we are associating the GUID 3bfbf219-2918-11d7-80c5-00065be02953 with the San Francisco data center. For Bangalore data center we
will associate the GUID c9bcec19-4301-11d9-b12d-080020b0d8b8 by
specifying it in the DefaultProviderId setting.
Next, we specify the Distributed Agreement Engine host:port for each data center. You can choose
any static port. The ListenerIP field could specify a host name or
an IP address. Now, when San Francisco data center starts up it
knows how to communicate with the Bangalore data center and vice versa.
That's it, now you are ready to run the WANdisco CVS Replicator, using the startup script provided. To run it from the command line:
$ cvs-replicator/bin/cvsreplicator & $ tail -f cvs-replicator/logs/ProxyServer-prefs.log.0 .... INFO: [cvspserver] CVS Proxy listener is now turned ON at port :2401
When you see the last line, you know WANdisco CVS Replicator has started successfully. Alternatively, you can go to the web console and check the dashboard.
To shutdown WANdisco CVS Replicator, just run
$ cvs-replicator/bin/shutdown
Caution: To ensure that the CVS repositories do not go out of sync, we recommend taking all possible precautions to avoid direct access to the CVS server, bypassing the WANdisco CVS Replicator. For example, you could setup CVS server to only allow connection from the IP address of the host on which Replicator is running.
Please ensure your license.key file specifies valid number of users, sites and allowed IP addresses on which the WANdisco CVS Replicator is allowed to run. If you have an unlimited license, you do not have any restrictions on number of users, sites or IP addresses.
In order for CVS users to access CVS repoistory via WANdisco CVS Replicator, the administrator must have registered valid users using either the Web console or the import facility (see User Management section under Access Control chapter). With an unlimited license this is not required. However, with an Enterprise CVS Edition license you have to register the users unless you turn off access control.
The WANdisco CVS Replicator evalutaion license is an unlimited Enterprise CVS Edition license with a limited expiration time.
Please ensure the following prior to running the cvsreplicator:
cvsroot directories on all the replicas match. In other words if host1 uses /data/cvsroot and host2 uses /data2/cvsroot that is not valid. Both host1 and host2 need to use the same root e.g. /data/cvsroot.
This is an optional step. After completing the replicator setup, an administrator can run the bundled validation tools to ensure a consistent replicator environment.
In the WANdisco CVS Replicator cvs-replicator/bin directory there are two validation tool:
Running validate-local-setup will cause checks to be performed based on the configuration specified in prefs.xml, prefs.conf files. In addition the tool will prompt for user input. The tool will print warnings and informational messages to the console. It is best to run the tool with the replicator running so that TCP connectivity can also be verified.
Please double check the warnings to ensure a valid configuration. Here is an output from a run -
$ bin/validate-local-setup
=====================================================
In order to validate local config against remote nodes,
you need to save the results from this run in a status file.
=====================================================
Specify the file to save config status. [./rep-config-tao.status] :
will save status to - ./rep-config-tao.status
=====================================================
Replicator requires cvs server versions to be exactly same
at all sites. Note client versions can be different
=====================================================
Enter the full path to your cvs server binary. [./cvs] : /usr/bin/cvs
INFO: You selected the cvs binary - /usr/bin/cvs
INFO: You are using cvs server version 1.11.17
=====================================================
Replicator requires cvs roots to match across cvs servers
at all sites. For e.g. if host1 uses /data/cvsroot and host2
uses /data2/cvsroot that is not valid. Both host1 and host2
need to use the same root e.g. /data/cvsroot. This is not
required by CVSNT which can use logical repository naming.
In that case, CVSNT repository prefix must be the same.
=====================================================
What is the cvsroot you are replicating? [/home/cvsroot] : /data/cvsroot
Need to specify more cvsroots - Y|N? [N] :
WARNING: the current version (1.4.2_04) of java (/export/share/apps/jdks/1.4.2/bin/java)
you are using has known problems. Please upgrade to JDK version 1.5.0_03 or higher
INFO: Replicator is listening on 0.0.0.0:2410
INFO: Verify Mode is ON, all CVS writes (commit,tag...) will be verified locally first
INFO:CVS Server is listening on localhost:2401
WARNING: Please change the default MAC Address in prefs.xml to
this machine's MAC address
INFO: cvsrelay prefs.conf file found. Presuming SSH access to CVS is required.
INFO: cvsrelay was able to connect to CVS replicator at (127.0.0.1:2410)
WARNING: Failed to connect to member(196979d3-5aba-11d9-8e24-001111690e1a) at tao:6333
The tool will produce a status file which is used as input to the remote setup validation tool.
Running validate-remote-setup allows the administrator to ensure all
the replicators in a replication group have consistent settings. For
instance, it will check if all of them are using same version of cvs
server. In order to run this tool following steps must have been completed already:
Please double check the warnings to ensure a valid configuration. Here is an output from a run -
$ bin/validate-remote-setup
=====================================================
In order to validate the setup of remote nodes for mutual
consistency, you will need to provide the status file generated
by running "validate-local-setup" at each replicator node.
=====================================================
Enter fully qualified status file name. [./rep-config-tao.status] :
Need to specify more status files - Y|N? [N] : Y
Enter fully qualified status file name. [./rep-config-tao.status] : ./pee.status
Need to specify more status files - Y|N? [N] : N
WARNING: Number of entries (6) in pee status file doesn't match tao (10)
WARNING: java.minor : "07" on pee doesn't match "04" on tao
WARNING: cvs.version : "1.11.19" on pee doesn't match "1.11.17" on tao
WARNING: cvs.root0 : "/data2/cvsroot" on pee doesn't match "/data/cvsroot" on tao
Here are common gotchas and their solutions:
logs/ProxyServer*.log.* to know if the replicator even got the write or commit changes:
... INFO: [reader-2] Submitted after verification: cvs-proposal-2f195a4b-dea9-11d9-b140-00065b193ef5_4 1118955513564 org.nirala.communication.transport.cvsproxy.CVSProposal output INFO: [gsn-1] Executing cvs-proposal-2f195a4b-dea9-11d9-b140-00065b193ef5_4 1118955513575 org.nirala.communication.transport.cvsproxy.CVSProposal onCommit INFO: [reader-1] Committed CVS transaction cvs-proposal-2f195a4b-dea9-11d9-b140-00065b193ef5_4 ...If you don't see a
Submitted line in the log file, the CVS write operation never made it the the WANdisco CVS Replicator and hence can't be replicated. On completing a write or a commit operation, the WANdisco CVS Replicator will print a Committed line in the log file.
Submitted lines in the log file after doing commits
Most common reason for this is incorrectly setup CVSROOT. For example if the CVSROOT environment variable is setup as /home/cvs then the CVS client will directly modify the repository using the local access protocol.
The CVSROOT environment variable needs to be setup as:
$ setenv CVSROOT :pserver:<cvs-user>@<replicator-host>:<replicator-port>/<cvsroot-directory>If the replicator is running on port
2401 then replicator-port setting can be skipped on non-localhost machines. If the replicator and CVS server are co-located, you need to specify the port when running on the CVS server host. See the Official CVS administration guide
$ cvs-replicator/bin/reset
<SVNProxy>
<AutoBypassGlobalFailures>true</AutoBypassGlobalFailures>
</SVNProxy>
If you choose to do this, note the above caveat regarding the consequences of
SBVN bugs.
However, if the SBVN transaction failed at some sites but not at others,
the WANdisco CVS Replicator can not bypass the transaction, since that would cause the repositories to
be out of sync. These transactions are listed on the dashboard as problem transactions.
The cause of the fatal error can be determined from the log files. After addressing the cause,
(for example, if a disk-full error was encountered, add more disk) restart the WANdisco CVS Replicator. Finally,
verify from the dashboard that there are no outstanding problem transactions.
cvs-replicator/bin/talkback at each WANdisco CVS Replicator site and upload the generated tar ball.
If you can not run the talkback tool, send us the current logs files in logs/Proxy*.log at each site and the configuration files (prefs.xml and /etc/prefs.conf). We may request you to gather more information using the WANdisco CVS Replicator web administration interface if needed.
It is customary to use the CVS_RSH environment variable to specify the remote shell to use in lieu of pserver authentication. The CVS_RSH environment variable can specify for example SSH as the remote shell and can directly use the encryption feature of SSH.
WANdisco CVS Replicator doesn't restrict you in any way when you choose to use a CVS_RSH based remote shell. Just follow the setup directions below to get SSH, Kerberos etc support going for your CVS clients.
There are two ways do this. You can directly have the CVS client connect with the SSH daemon (Direct SSH Method) or you can tunnel the CVS pserver protocol over SSH (SSH Tunneling Method).
We will walk through an example with SSH as the remote shell.
Set CVS_RSH to point to ssh or ssh.exe depending upon the platform. For Windows, if you use a Putty based ssh client, set CVS_RSH to the path to plink.exe
Ensure that your ssh credentials are accessible from the machine you will be running CVS client on. For example if you have a private key, you may want to use the ssh-agent (pageant for Putty) and ssh-add to have ssh pre-register your private key.
Use the bundled cvsrelay executable as the CVS_SERVER. This can be done in two
ways:
CVS_SERVER to point to the bundled cvsrelay executable. For example using tcsh :
setenv CVS_SERVER <path-to-WANdisco-install>/bin/cvsrelay
cvsrelay to cvs and modify the PATH so that the ssh daemon
(sshd) will invoke cvsrelay instead of cvs when a CVS client connects to it.
If sshd is launched via the init.d startup script, you could modify the script that starts sshd to set the PATH to point to cvsrelay bin directory before any other path element. This lets you essentially invoke cvsrelay when a CVS
client request comes in. The cvsrelay executable will then be able to relay CVS request/response packets from sshd to WANdisco CVS Replicator.
> cd cvs-replicator/bin > pwd cvs-replicator/bin > ln -s cvsrelay cvs
Due to security concerns, on most UNIXs sshd is typically compiled with a hardwired PATH. Then setting the PATH in init.d sshd startup script will not work. This
can typically be confirmed via:
> strings `which sshd` | grep -i bin ... /usr/bin:/bin:/usr/sbin:/sbin ...
If you see a colon separated string like above, that might be the compiled in PATH.
Alternatively you may look at the first couple of lines in /etc/ssh/sshd_config:
#$OpenBSD: sshd_config,v 1.65 2003/08/28 12:54:34 markus Exp $ # This is the sshd server system-wide configuration file. See # sshd_config(5) for more information. # This sshd was compiled with PATH=/usr/bin:/bin:/usr/sbin:/sbin
If you determine that your sshd has a path hardwired at compilation time
you could do one of the following:
sshd with PATH to cvsrelay ahead of standard
cvs executable.
cvs to something like
cvs.org and change references to cvs in xinet.d/cvspserver to point
to cvs.org. Finally link cvsrelay into /usr/bin or any system directory
that is on sshd compiled in PATH.
If you use cvsrelay, you must setup the CVS server's password database in $CVSROOT/CVSROOT/passwd file. The passwords in this file are encrypted using standard UNIX crypt() function so it is possible to cut and paste from /etc/passwd (on some system /etc/shadow)file. Since the authentication is already done via sshd, all we need to do is select a single system password and have all users in the CVSROOT/passwd file share the same password.
In essence the CVSROOT/passwd file would look like:
Bach:1sOp854gDF3DY Mozart:1sOp854gDF3DY Handel:1sOp854gDF3DY
All users, as you can see, share the same password. A default passwd file can be copied from cvs-replicator/config/passwd-template. The template file already contains the default password used by cvsrelay. If you decide to over-ride the default password, you have to modify the configuration (/etc/prefs.conf) for cvsrelay to tell it the new system password to use.
You can also use the bundled utility cvs-replicator/bin/cvspasswd to generate crypt() password for CVSROOT/passwd file:
$ cvspasswd Enter CVS password : CVSROOT/passwd : sa0Pk81ulv7qc CVSRelay Password : 117:99:121:32:73:121:60:121
Also the CVSROOT/config file needs to turn off System authentication:
#Set this to "no" if pserver shouldn't check system users/passwords SystemAuth=no # Put CVS lock files in this directory rather than directly in the repository. #LockDir=/var/lock/cvs
The above scheme is essentially delegating the credentials that were obtained after authenticating with sshd to the cvs server as shown below.
The CVS user authenticates with the SSH daemon, which then invokes cvsrelay with the user ID of the secure shell. This is the user ID that the CVS client transparently passes to sshd. The cvsrelay process in turns looks up the system password at startup time from prefs.conf and passes the user-name and encrypted password to CVS. The CVS server in turn verifies the delegated credentials with entries in CVSROOT/passwd file.
The cvsrelay process acts as the bridge between sshd and the WANdisco CVS Replicator. The prefs.conf file contains the configuration parameters for cvsrelay.
The prefs.conf file is first located in the current working directory (cwd). If it is not found, cvsrelay attempts to locate it in the /etc directory. If it is still not found an error message is logged to UNIX syslog.
The prefs.conf can be automatically generated by the setup tool during the express setup or post-setup using the bundled install-cvsrelay tool.
The following are sample screens depicting how setup or install-cvsrelay can auto-generate the prefs.conf needed by cvsrelay.
Specify Replicator Host name [localhost] :
You specified localhost, is this correct?[Y|N] [Y] :
Specify Replicator port [2409] :
You specified 2409, is this correct?[Y|N] [Y] :
Specify CVS pserver host name [localhost] : tao
You specified tao, is this correct?[Y|N] [Y] :
Specify CVS pserver port [2401] : 2409
You specified 2409, is this correct?[Y|N] [Y] :
Specify path to the cvs client binary [/usr/bin/cvs] :
You specified /usr/bin/cvs, is this correct?[Y|N] [Y] :
Are CVS Clients using WinCVS or TortoiseCVS? Y/N [N] : Y
You specified Y, is this correct?[Y|N] [Y] :
Enter a valid CVS user on tao [admin0] : user1
You specified user1, is this correct?[Y|N] [Y] :
Enter any valid CVS Root directory on tao [/home/cvs] : /cvsd/admin0/cvsroot
You specified /cvsd/admin0/cvsroot, is this correct?[Y|N] [Y] :
Enter CVS password :
Creating ../config/prefs-localhost.conf ... [DONE]
**I: Please copy ../config/prefs-localhost.conf to
localhost:/etc/prefs.conf
In order to complete the SSH configuration, ensure:
1. All cvspserver host:<cvsroot>/CVSROOT/config have the
entry "SystemAuth=no".
2. Copy ../config/passwd-template file to
cvspserver host:<cvsroot>/CVSROOT/passwd file
and ensure all users added to passwd file have the same password.
3. Ensure SSH daemon (sshd) is using cvsrelay instead of cvs.
See Replicator admin guide for more details.
The prefs.conf syntax is name=value pairs. The following parameters can be specified in prefs.conf to customize its defaults:
2401
Specifies the port of the CVS Replicator to which the CVS requests will be relayed.
127.0.0.1
Specifies the IP address (in IPv4 dot notation, not DNS name) of the CVS replicator to forward to. Using the cvsrelay one can run sshd and the CVS server on separate hosts. It is not necessary to collocate them.
117:99:121:32:73:121:60:121
Specifies the octet sequence denoting the system password to pass to the CVS server when delegating the credentials to cvs from sshd. Use the included cvs-replicator/bin/cvspasswd program to generate password encoded in WANdisco format for cvsrelay. This is done to encode the pass phrase generated by the CVS scrambling algorithm when transmitting cleartext passwords on the wire.
4 KBytes
Specifies the buffer size used by the relay. Used to tune the performance of the cvsrelay.
Here is a sample /etc/prefs.conf file:
$ cat /etc/prefs.conf cvs.port=2401 cvs.host=192.168.1.20 cvs.password=117:99:121:32:73:121:60:121
When using many of the popular GUI clients with cvsrelay, you may need to patch your cvsrelay installation to make it work. For example when using Tortoise and WinCVS, you may see the following error message:
warning: unrecognized response `Please run install-cvsrelay for this client' from cvs server
If you see the above message, then the administrator needs to run the bundled install-cvsrelay utility. Note this is needed iff you are using cvsrelay.
The install-cvsrelay utility will prompt you for the fully qualified path to the cvs server executable. It will then attempt create a patch specific to the version of cvs server being used. If you install a different version of cvs server at a latter date, be sure to re-run install-cvsrelay.
> cd cvs-replicator/bin > pwd cvs-replicator/bin > ./install-cvsrelay
Once install-cvsrelay has patched the prefs.conf, you can then start using Tortoise, WinCVS clients.
Configuring SSH access from CVS clients requires getting the SSH credentials setup correctly as well as configuring the cvsrelay as outlined above.
Here are common gotchas and their solutions:
pageant or ssh-agent is running with private keys already loaded, a less secure way is to have no pass-phrase on the private keys at creation time.
cvsrelay is being picked up as the cvs executable by sshd. This can be done by setting up CVS_SERVER environment variable in Windows system variables dialog box or renaming cvs to point to cvsrelay. A write or a commit operation will only be replicated if submitted to the replicator. Bypassing the replicator will change the CVS repository directly and cause other replicas to go out of sync. Remember to look for the following pattern in the logs/ProxyServer*.log to know if the replicator even got the write or commit changes:
... INFO: [reader-2] Submitted after verification: cvs-proposal-2f195a4b-dea9-11d9-b140-00065b193ef5_4 1118955513564 org.nirala.communication.transport.cvsproxy.CVSProposal output INFO: [gsn-1] Executing cvs-proposal-2f195a4b-dea9-11d9-b140-00065b193ef5_4 1118955513575 org.nirala.communication.transport.cvsproxy.CVSProposal onCommit INFO: [reader-1] Committed CVS transaction cvs-proposal-2f195a4b-dea9-11d9-b140-00065b193ef5_4 ...If you don't see a
Submitted line in the log file, the CVS write operation never made it the the WANdisco CVS Replicator and hence can't be replicated.
Also check the host and port setting in /etc/prefs.conf.
cvsrelay is being invoked?
First check the system log (on Linux /var/log/messages) for any error messages from cvsrelay, for example:
tao /var/log# pwd /var/log tao /var/log# grep cvsrelay messages Dec 1 21:02:04 tao cvs-replicator/bin/cvsrelay[15105]: failed to open /etc/pref s.conf Feb 24 22:03:07 tao ./cvsrelay[5348]: cvs: delegated login failure. Check syslog for further info. Server response - "error 0 /tmp/cvstest: no such repository"
You can also setup cvsrelay to run in verbose mode by passing an optional -v parameter:
setenv CVS_SERVER "...../bin/cvsrelay -v"
This will cause the system log (on Linux /var/log/messages) to contain detailed messages from cvsrelay.
This method requires first setting up a secure SSH tunnel between the CVS client and the SSH daemon. Once the tunnel is set up, ssh will allocate a listen socket on the client-side. All traffic to this port will be automatically forwarded to the remote host (cvs server) over a secure connection.
Using the usual ssh -L option setup a local listen port on the client side.
>ssh -L 2401:cvs-server-host:2401 cvs-server-host >setenv CVSROOT :pserver:user@cvs-server-host:/a/b/c.../cvsroot >cvs co ..
The local port could be 2401, the standard CVS port, but it does not have to. Make sure the remote host:port is the normal pserver host:port for CVS server. Setup CVSROOT on the client to point to localhost. In the example above, all traffic to localhost:2401 will be forwarded via SSH to the CVS server.
Note that even a temporary disruption in connectivity will tear down an SSH tunnel. When this happens, the tunnel will have to be recreated using the above ssh command.
The WANdisco CVS Replicator has a pre-commit access control mechanism that supplements the access control normally performed via commitinfo triggers, for example using the cvs_acl scripts. The commitinfo triggers fire after replication has been performed. Under some circumstances it may be desirable to perform access control on CVS write operations prior to any replication. This is what the WANdisco CVS Replicator authorization plugin can be used for, it fires just before replication is about to begin. The pre-replication trigger can be used for non-security purposes too, for instance generating email alerts.
The WANdisco CVS Replicator has a pluggable authorization model. By default a No-op auth plugin is enabled which allows unrestricted access. A CVS administrator can customize the bundled lib/authperlscript and setup a PerlAuthPlugin. Peek inside the authperlscript for more details on how to use it for access control. In addition to cvs user name, the IP address of the CVS client machine is also available as a parameter to access control rules. This can be used to ensure commits happen only from valid subnets or IP addresses, further tightening security constraints. The commitinfo triggers that run from backend CVS repository does not have the client IP address available due to limitations of CVS server itself, but using the WANdisco CVS Replicator access control trigger, the administrator can setup rules based on client IP address.
In order to use the lib/authperlscript please add the following line to the CVSProxy section of the cvs-replicator/config/prefs.xml file:
<CVSProxy> .... <AccessControlPlugin>org.nirala.admin.cvsproxy.security.PerlAuthPlugin</AccessControlPlugin> .... </CVSProxy>
For maximum flexibility it is possible to write a custom trigger in Java and install it such that the WANdisco CVS Replicator will invoke it prior to replication. You must be conversant with Java programming language in order to take advantage of this feature.
Follow these steps to invoke your own custom pre-replication trigger:
public interface AuthorizationPlugin {
/**
* Returns true if user is authorized to execute the CVS command in question
* else returns false.
* @param user CVS user trying to perform the write command
* @param ip IP address of the CVS client
* @param cmd CVS command user is trying to execute
* @param dirs List of CVS directories on which command will operate
* @param cvsroot The CVSROOT directory
* @return
*/
boolean allow(String user, String ip, String cmd, Set dirs, String cvsroot);
}
cvs-replicator/lib directory
.class suffix) in cvs-replicator/config/prefs.xml file using the AccessControlPlugin tag, for instance:
<CVSProxy> .... <AccessControlPlugin>my.custom.AuthPlugin</AccessControlPlugin> .... </CVSProxy>
The WANdisco for CVS Enterprise Edition enables an administrator to implement a comprehensive security model that provides features beyond file-system permissions or cvs_acl scripts that are bundled with CVS sources:
The Group Management functions allow an administrator to:
The WANdisco Groups are hierarchical with parent-children associations between sub-groups. Groups provide a convenient way of organizing multiple users into a related category for controlling access as well as searching for users. It is recommended that you setup ACLs on a group basis rather than users (both are allowed) for easier management of security policies.
The first step towards setting up security is to map organization or project structure to WANdisco Groups (also referred to as Roles in security literature). The groups are hierarchical. If a user belongs to a parent group, they children groups automatically inherit users in the top-level parent groups. In the same way, Access Rules or ACLs attached to children group are automatically applied to the parent groups. Before creating new groups it is important to work out the parent-child hierarchy. For instance an engineering team may be split up along geographical sites: sanramon-engr, tokyo-engr. These two groups may belong to a parent group: engr. Within sanramon-engr group there may be role based hierarchy: sanramon-project-projectlead, sanramon-qa.
To add a new group, click on the Create Group option in the security menu and specify its name. The name can contain any character including white-space, there are no restrictions. The group name is the primary key into the group database, it can not be changed. If you need to change it just delete the group and add a new one with a different name. Description field can contain any relevant text describing the group. The WANdisco for CVS Enterprise Edition tracks the creation and modification time-stamp on the groups automatically.
Once a group is created, you can start assigning users to it.
Please note that a system group Admin always exist in the WANdisco for CVS Enterprise Edition. As mentioned in the ACL section below, a user belonging to the Admin group gets Admin privileges which include List,Read,Write privileges on all resources.
The group is assigned under the checked group as a sub-group. To de-assign, uncheck the checkbox and click 'Save Details'. Note by selecting a group, this group is automatically assigned as its sub-group. A sub-group can have exactly one parent. Clicking on the icon e will allow you to edit the specific group.
From the security web console, click on an edit Group icon to go to the Edit Group page. The edit Group icons are visible from any Group management page. Click on the delete button to remove a group.
When a group is deleted it is also removed from the all users who previously belonged to that group. The ACLs associated with the groups are not deleted, they no longer apply though. You can edit them and assign them to a different group.
On the Web console, the Add or remove function under Group management is context-aware. When you select a group by clicking on its checkbox, only users that can be added or removed are shown. This ensures you don't have to worry about duplicate users when adding them to a group. You can use it to quickly add/remove multiple users to/from a given group or sub-group.
If a user has been added to a parent group, they automatically belong to any sub-groups underneath it. So there is no need to add them to the sub-groups. The context-aware web UI will show users who are not in parent groups for example when adding them to a sub-group.
For the initial setup you can also use the bulk user import option to quickly import multiple users and their associated groups.
To quickly view a list of users who belong directly to a specific group, just click on the "List users only in this group" in the Edit Group page. To view the list of all users including the ones inherited from ancestor groups, click on the "List all users including inherited from parent groups" hyperlink.
Go to the Edit Group page for the group. Scroll down to the "Resource Details" panel. The resource table contains the listing of all the files and directory patterns (regular expressions) and corresponding ACLs applicable to the specified group. You can click on the ACL hyperlink to edit the associated rule.
The User Management functions allow an administrator to:
The users must exist in the authentication database (NIS, LDAP, /etc/passwd etc) used by CVS server. The User management function allows administrator to specify licensed users who can access CVS repository via the WANdisco for CVS Enterprise Edition. Even if you are not using security features like ACL, you must register the valid users with the WANdisco for CVS Enterprise Edition.
If a CVS user has not been registered and they try to access WANdisco for CVS Enterprise Edition configured with an unlimited user license, they will see an error message as below:
cvs acl: Access Denied: The CVS administrator has not granted cvs acl: you sufficient permissions to execute this command. cvs acl: Please contact your local CVS administrator for help. cvs acl: Aborting the cvs operation.
With a limited user license the above error message changes to:
cvs acl: Access Denied: The CVS administrator has not registered cvs acl: you as a user of WANdisco CVS Replicator. cvs acl: Please contact your CVS administrator for help. cvs acl: Aborting the cvs operation.
To add a new user, click on the Create User option in the security menu and specify a login id (cvs user name). The last and first name can contain any character including white-space, there are no restrictions. You can specify an optional email address for the user. The user id is the primary key into the user database, it can not be changed. If you need to change it just delete the user and add a new one with a different user id. The WANdisco for CVS Enterprise Edition tracks the creation and modification time-stamp on the users automatically.
To remove a user, just click on "Delete" button in the Edit User page. You can also delete multiple users from the User List page.
The user can be assigned to any number of checked groups. To de-assign, uncheck the checkbox and click 'Save Details'. Note by selecting a group, the user is automatically assigned to the group and all its sub-groups. Clicking on the icon e will allow you to edit the specific group.
To get a list of all the registered users, just click on the User List option. The user list page shows all the users by default. The page size by default is set to show 25 users per page. You can change that by selecting the page size on the upper right corner. The page control on the left corner allow you to go to next or previous page.
If you want to locate a user by first or last name quickly, just start typing the name in the User name like textbox and an incremental search starts automatically. To get the full list back just hit the backspace button on the keyboard till you have deleted all the characters you typed in the textbox.
All the columns in the user list are enabled for sorting. By clicking on the column header you can sort the list in ascending or descending order. The sortable columns include: CVS user id, last name, first name, email, last modified date.
To restrict the list by a group or role, just select a group name from the drop down menu. To see users in the selected group as well as all the ancestor groups click the Inherited Users checkbox.
You can click on the user id hyperlink to edit the user. Mass delete action is supported via selecting the checkbox in the table header (next to User Login id column) and then clicking the delete button.
In order to import users from other databases like NIS, etc/passwd you can have a script create a comma separated import file with all relevant users. The data to be imported must be in a text file with comma separated fields. The syntax of a user row in the csv file is:
cvsuserid,lastName,firstName[[,email],group1[,group2..groupN]]
Here is an example of a csv file:
> cat userlist.csv ravi,Shastri,Ravi,ravi@email.com,Admin,sc-engr rchen,Chen,Roger,rchen@email.com,engr sony,Richards,Sony,Admin,engr vanu,Xandau,Vanu
Line 1: Will import a cvs user ravi with last name Shastri, first name Ravi, email address ravi@email.com and assign him groups: Admin and sc-engr.
Line 2: Will import a cvs user rchen with last name Chen, first name Roger, email address rchen@email.com and assign him group: engr.
Line 3: Will import a cvs user sony with last name Richards, first name Sony, no email address and assign him groups: Admin and engr.
Line 4: Will import a cvs user vanu with last name Xandau, first name Vany, no email address and no groups.
The cvs user id, last and first name are required and can not be empty. The email and group names are optional. Further if a group name is specified, the group must already exists in the WANdisco for CVS Enterprise Edition group database, if not the user will not be added. If the 4th field contains the character "@" it is presumed to be an email address.
The path to the CSV file must be accessible by the WANdisco for CVS Enterprise Edition server process. Before doing the import make sure the csv file is either copied on the WANdisco for CVS Enterprise Edition machine or NFS/Samba accessible to the WANdisco for CVS Enterprise Edition process.
The Access Control or authorization mechanism in WANdisco for CVS Enterprise Edition is based on the concept of a set of valid principals with adequate privileges to access a secured resource. The ACL management features allow an administrator to:
Here are the definitions of the commonly used terms when describing the WANdisco for CVS Enterprise Edition's ACL mechanism:
/a/b/c/, not /a/b/c.
The privileges are ordered. In other words if a principal has Admin privilege, they also have the other three: List, Read, Write. If a principal has Write privilege, they do not get Admin privilege but have the other two: List, Read. If a principal has Read privilege, they do not get Admin and Write privileges but have the List privilege. If a principal has only List privilege, they do not get Admin, Write, Read privileges.
The following is the mapping of actual CVS commands to minimum privilege needed to execute them:
| CVS Command | Privilege Needed |
|---|---|
| status | List |
| log | List |
| ls | List |
| list | List |
| diff | Read |
| checkout | Read |
| export | Read |
| update | Read |
| annotate | Read |
| commit | Write |
| tag | Write |
| import | Write |
| add | Write |
| remove | Write |
| admin | Admin |
| watch | Admin |
| init | Admin |
| history | Admin |
| release | Admin |
| edit | Admin |
| rdiff | Admin |
| rtag | Admin |
| rlog | Admin |
| rlist | Admin |
| rls | Admin |
| rannotate | Admin |
The WANdisco for CVS Enterprise Edition ships with no rules in the rules database. That implies by default everyone is denied. This is essential for security - it closes the window of vulnerability that would have allowed everyone full access between the time the product is first installed and the admin creates access rules. In order to grant access, the administrator has to explicitly create allow rules.
Using the ACL editor from the web console, the admin can create allow or deny rules.
Powerful Perl style regular expressions can be used wherever patterns are allowed. Principal (user/group) or IP patterns for instance - engineering.* (note the dot) or 217.[0-9]+ are all valid patterns. By default the HEAD branch is specified but you can enter a regular expression just as well - release9.0_.* for instance. Note: With the Perl regular expression syntax, if you need to use the '.' (dot) character literally, you need to escape it with a backslash, otherwise '.' (dot) will match any character. To learn more about regular expressions look at a tutorial here.
Multiple rules can be edited atomically using the WANdisco for CVS Enterprise Edition. When you submit changes to ACLs, the WANdisco for CVS Enterprise Edition guarantees either all the rules are updated or none at all. This ensures consistent rules database across multiple sites, with any pattern of failures.
The following steps are followed by the WANdisco for CVS Enterprise Edition's ACL engine when making an allow or deny decision on a CVS command the user is trying to execute:
To illustrate how the ACL enforcement works, lets walk through several examples below:
User doe belongs to group engr. The administrator has setup the following rules:
| Rule | Privilege | Group Pattern | IP Pattern | File/Dir Pattern | Branch Pattern |
|---|---|---|---|---|---|
| Allow | List | engr.* | 192.* | /data/cvsroot/ecommerce.* | HEAD |
The user is allowed to execute the following commands that require only list privilege:
$ echo $CVSROOT :pserver:doe@mypc:/data/cvsroot $ cd /home/ecommerce/ $ cvs status $ cvs ls
The user is denied access when executing the following commands that require read or write privilege:
$ cvs update foo cvs acl: Access Denied: The CVS administrator has not granted cvs acl: you sufficient permissions to execute this command. cvs acl: Please contact your local CVS administrator for help. cvs acl: Aborting the cvs operation. $ cvs commit -m "my changes" cvs acl: Access Denied: The CVS administrator has not granted cvs acl: you sufficient permissions to execute this command. cvs acl: Please contact your local CVS administrator for help. cvs acl: Aborting the cvs operation.
The user is denied access when executing the following list commands from subnet 10.23.1:
$ ifconfig -a
eth0 Link encap:Ethernet HWaddr 00:09:5B:19:3E:F8
inet addr:10.23.1.7 Bcast:10.23.1.255 Mask:255.255.255.0
...
$ cvs status
cvs acl: Access Denied: The CVS administrator has not granted
...
User jane belongs to group build-engr. The administrator has setup the following rules:
| Rule | Privilege | Group Pattern | IP Pattern | File/Dir Pattern | Branch Pattern |
|---|---|---|---|---|---|
| Allow | Write | build-engr | 192.* | /data/cvsroot/build.* | rel.* |
| Deny | Write | build-engr | 192.* | /data/cvsroot/build/secret.make | rel.* |
The user is allowed to execute the following command:
$ echo $CVSROOT :ext:jane@mypc:/data/cvsroot $ cd /home/build $ ls foo.c bar.v secret.make $ cvs update secret.make $ cvs ci -m "new" foo.c bar.v
The deny rule above doesn't restrict read access to secret.make, only write access is limited.
The user is denied access when executing the following command:
$ cvs ci -m "new changes" secret.make cvs acl: Access Denied: The CVS administrator has not granted ...
In this example, the deny rule is used to restrict access to the file secret.make. Deny rules can be applied to a file or directory pattern as well.
User jane belongs to group qa. The administrator has setup the following rules:
| Rule | Privilege | Group Pattern | IP Pattern | File/Dir Pattern | Branch Pattern |
|---|---|---|---|---|---|
| Allow | Read | qa | 192.* | /data/cvsroot/ecommerce.* | HEAD |
| Allow | Read | qa | 192.* | /data/cvsroot/ecommerce.* | rel_1_0 |
The user is allowed to execute the following commands that require only list privilege:
$ echo $CVSROOT :ext:jane@mypc:/data/cvsroot $ cd /home/ecommerce/ $ ls foo.c bar.v $ cvs status foo.c $ cvs ls $ cvs up -r rel_1_0 bar.v $ cvs diff -r rel_1_0 foo.c
The user is denied access when executing the following commands:
$ cvs ci -m "new changes" cvs acl: Access Denied: The CVS administrator has not granted ... $ cvs up -j rel_2_0 cvs acl: Access Denied: The CVS administrator has not granted ... $ cd /home $ cvs co ecommerce cvs acl: Access Denied: The CVS administrator has not granted ...
The last checkout command is denied because to checkout from the CVSROOT requires read privilege not only on the module ecommerce but also the top level cvsroot /data/cvsroot.
To checkout the module the administrator would setup access rules as:
| Rule | Privilege | Group Pattern | IP Pattern | File/Dir Pattern | Branch Pattern |
|---|---|---|---|---|---|
| Allow | Read | qa | 192.* | /data/cvsroot[/] | HEAD |
| Allow | Read | qa | 192.* | /data/cvsroot/ecommerce.* | HEAD |
User bigoram belongs to parent group div-engr, while user smalloram belongs to sub-group nyc-engr of div-engr.
The administrator has setup the following rules:
| Rule | Privilege | Group Pattern | IP Pattern | File/Dir Pattern | Branch Pattern |
|---|---|---|---|---|---|
| Allow | Read | div-engr | .* | /data/cvsroot/dvd/sfo.* | .* |
| Allow | Read | nyc-engr | .* | /data/cvsroot/dvd/nyc.* | rel.* |
The user bigoram belongs to both the groups (div-engr, nyc-engr), therefore is allowed to execute the following commands:
$ echo $CVSROOT :pserver:bigoram@mypc:/data/cvsroot $ cd /home/dvd $ cvs update -P -d sfo $ cvs update -P -d nyc
The user smalloram is belongs to only the group (nyc-engr), therefore is allowed to execute the command:
$ echo $CVSROOT :pserver:smalloram@mypc:/data/cvsroot $ cd /home/dvd $ cvs update -P -d nyc
The user smalloram is denied access when executing the following command:
$ cvs -z6 update -P -d sfo cvs acl: Access Denied: The CVS administrator has not granted ...
The following properties in the prefs.xml file can be used to control the ACL engine:
<Security>
<AccessControl>
<Enable>true</Enable>
<Replicate>true</Replicate>
<ClientTimeout>15s</ClientTimeout>
</AccessControl>
</Security>
By default, the WANdisco for CVS Enterprise Edition has access control enabled. To turn it off set /Security/AccessControl/Enable to false.
The principal (user/group) and rules database are replicated across all sites by default, to not replicate and instead use a site-specific local database, just set /Security/AccessControl/Replicate to false.
If the principal/rules databases are replicated and a change is submitted via a web client, the /Security/AccessControl/ClientTimeout specifies the time after which the web client will timeout while waiting for a confirmation from the WANdisco for CVS Enterprise Edition. Default timeout is 15 seconds. This is only an issue if the quorum of sites are not available (network down) when committing the change. The changes are kept in a pending transaction journal and applied latter when the quorum is restored.
In order to setup security policies the ADMIN needs to setup the users in the WANdisco CVS Replicator's internal database. For large organization this can be cumbersome if the user information is already maintained in an external database like LDAP or NIS. For such a deployment, the WANdisco CVS Replicator for CVS provides integration with LDAP/NIS based authentication databases.
The integration allows the ADMIN to automatically synchronize the user properties (user id, password) from an LDAP/NIS database. The WANdisco CVS Replicator for CVS will periodically (default is every 5 minutes) connect with the LDAP/NIS database server and pull the user information. Using the WANdisco web console, the ADMIN can go and select the new users that were discovered during the synchronization with LDAP/NIS. The selected users are then added to the WANdisco CVS Replicator's internal database. If CVS repository properties are configured correctly and 'Update Passwords' flag is set, the user and password information is also updated in the CVSROOT/passwd file. Using the CVSROOT/passwd file is a good idea as it increases the availability of CVS if the external authentication database is unavailable.
The following properties can be configured from the WANdisco CVS Replicator's web console to setup the LDAP/NIS integration:
The CVS properties section is common to both NIS and LDAP (* indicates mandatory):
CVSROOT/passwd file when updating the file with new users. The CVS server will switch to this user when executing the command.
If setting up integration with LDAP, the following properties need to be setup (* indicates mandatory):
Note: The password should be stored in the same format (crypt etc) on LDAP server as the format on the CVS server machine if 'Update Passwords' flag is set.
If setting up integration with NIS, the following properties need to be setup (* indicates mandatory):
Note: The password should be stored in the same format (crypt etc) on NIS server as the format on the CVS server machine if 'Update Passwords' flag is set.
With the WANdisco for CVS Enterprise Edition, any CVS access (allowed or denied) by the user is logged in an audit trail file. The text file has a complete history of all CVS actions in the following format:
# Column syntax - # 0 seq | 1 time | 2 txid | 3 cmd | 4 user | 5 ipaddress | 6 access | # 7 dir | 8 file | 9 rev | 10 branch
The column description is as following:
| Column Number | Description |
|---|---|
| 0 | Record Sequence Number |
| 1 | UNIX Timestamp |
| 2 | Transaction Id |
| 3 | CVS Command Name |
| 4 | CVS User id |
| 5 | IP Address of User |
| 6 | Access Decision (Allow or Deny) |
| 7 | CVS Directory being accessed |
| 8 | CVS File being accessed |
| 9 | User's File Revision |
| 10 | Branch Name |
The audit trail files are created under cvs-replicator/audit directory. By default they are automatically rotated upto 10 times when they get to 10MBytes. These defaults can be changed via configuration in config/prefs.xml file:
<Audit>
<MaxFileSize>10485760</MaxFileSize>
<MaxFileCount>10</MaxFileCount>
<Disable>false</Disable>
</Audit>
The MaxFileSize specifies a size in bytes, MaxFileCount specifies how many files to rotate before recycling the files. By default auditing is enabled in WANdisco for CVS Enterprise Edition, it can be turned off by setting Disable to true. To ensure no audit records are lost, please schedule a job (using cron for example) to import the audit records into a SQL database periodically. Inserting in a SQL database also enables complex SQL queries to be made against the audit database.
To create audit files in a different directory just create a symbolic link (cvs-replicator/audit) to another directory.
The WANdisco for CVS Enterprise Edition bundles a tool importauditdb that allows audit records in audit-trail files to be imported to a SQL database. The usage of the import command is as below:
[admin@smp1 ~/cvs-replicator]$ bin/importauditdb -h
Usage:
importauditdb [-host <db-host>] [-port <db-port>] [-user <db user>]
[-pass <db user password>] [-db <database to use>]
-f file-pattern1 file-pattern2 .. file-pattern-N
Defaults:
host : localhost
port : Default DB Port
user : root
password : empty
Database : wd_audit_db
The import tool requires Perl::DBI module to be installed. Please run cvs-replicator/bin/checkdbi
to check if the module is installed and correct database driver is available on your system.
Note: Before using import you must create a database (default name is wd_audit_db) on the database server. The import tool will automatically create the table schema in that database, the first time it runs. The import tool uses standard SQL syntax, it makes use of a system function FROM_UNIXTIME, please ensure your database version supports it. MySQL, Microsoft SQLServer support this function.
Please note: Audit Reports are only available with the WANdisco for CVS Enterprise Edition of the product.
Alias /reports/ "/home/wandisco/reports/"
<Directory "/home/wandisco/reports">
Options Indexes MultiViews
AllowOverride None
Order allow,deny
Allow from all
</Directory>
apachectl restartor
apache2ctl restart
% for wildcards
Shows all transactions against the CVS system.
Shows all user modifications made via the proxy's security administration user interface.
Shows all group modifications made via the proxy's security administration user interface.
Shows a history of all ACL modifications.
List file access and filter by parameters such as: date, access, command, user, ip address, directory, filename, revision or branch.
Show CVS allowed / denied access per user.
Display all denied access to the CVS system.
By default the WANdisco for CVS Enterprise Edition will replicate ALL cvsroots associated with a backend CVS pserver repository. Under some circumstances, it may be desirable to selectively replicate a limited set of cvsroots associated with a backend CVS pserver repository.
The cvs-replicator/config/prefs.xml file can contain Includes and Excludes sections that specify using Perl Regular Expression syntax which cvsroots are included in the replication set. Any write operation on excluded cvsroots is passed through to the backend CVS repository directly.
Consider the following example:
<CVSProxy>
....
<cvsroots>
<Includes>
/my/.*
/home/cvsroot/design/?.*
/cvs/admin\d+/
/enterprise/source/repository/
</Includes>
<Excludes>
^/bad.*
/home/cvsroot/secret.*
</Excludes>
</cvsroots>
....
</CVSProxy>
The above rules would allow any CVS write operation on cvsroots like - /my/bad/ /home/cvsroot/design/ /home/cvsroot/design/ /cvs/admin0/ /enterprise/source/repository/ - to be replicated.
CVS write operations on the cvsroots like - /bad/root /home/cvsroot/secret/fbi /cvsroot /cvs/admin/d1 - will not be replicated as they fall under the Excludes pattern.
Note that cvsroots should be specified in their slash-terminated form - thus, specify /a/b/c/ and not /a/b/c
The Excludes section always has precedence over Includes. If only the Excludes section is specified then that is equivalent to allowing ALL and denying only the cvsroots that match the patterns specified with Excludes. If the Includes section is specified then allowed cvsroots are constrained to only the ones that match the patterns specified in Includes.
Note: Selective Replicaton feature is not available with the standard edition. It is offered only with the Enterprise edition.
The replicator by default verifies if a network quorum is reachable when a write command is submitted. If the quorum is un-reachable, by default the write command is aborted and the following message appears on the CVS client console:
Check the Network connectivity, failed to reach a minimum quorum of nodes. Aborting the svn write operation.
To turn off the quorum check, just set the parameter, AlwaysVerifyQuorum to false in the cvs-replicator/config/prefs.xml file. For instance,
<CVSProxy>
<AlwaysVerifyQuorum>false</AlwaysVerifyQuorum>
....
</CVSProxy>
If the check is turned off and quorum is un-reachable, the write transaction will be applied to the WANdisco CVS Replicator's transaction journal and stay in a pending state till network connectivity and quorum is restored. Note: With singleton quorum, if the current site is also the distinguished node, the quorum check will always succeed irrespective of network connectivity to other sites.
The replicator by default waits for 60 seconds when a write transaction is initiated by the CVS client and then issues a message to the CVS client console if the transaction has not completed in 60 seconds. The transaction time may exceed 45 seconds due to couple of reasons - slow network, large checkins, local replicator that the client is connecting to may be back logged. In other words the client after getting the deferred write message can disconnect and replicator will attempt to apply the changes in the background. This doesn't guarantee that the write will not be aborted by the CVS server due to "upto-date check failed" condition. All it means is the user CVS sandbox doesn't need to block. This behavior can be turned off.
The message that the replicator puts out when it detects a slow write operation (exceeds the default 60 seconds timeout) :
WANdisco CVS Replicator has accepted the change-set. You can disconnect the CVS client if you want. Your command will be applied to the CVS repository even if you disconnect. After your command has been applied, do a "cvs update" to make your sandbox consistent with the CVS repository. Your transaction ID is NNNN
This behavior can be controlled via the following parameters in the cvs-replicator/config/prefs.xml file.
<CVSProxy>
..........
<!-- Defaults to true -->
<UseDeferredWrites>true</UseDeferredWrites>
<!-- Defaults to 60s or 60000 milliseconds -->
<ClientWaitTimeout>60000</ClientWaitTimeout>
</CVSProxy>
The CVS user can check the completion status of their transaction by going to the
WANdisco Web Console, entering the transaction ID, the site at which the transaction
was initiated and clicking the Track button. The 0.0.0.0 IP address indicates the local site.
If the WANdisco CVS Replicator has been restarted since the transaction was submitted or command replication has not commenced, the detailed status for the transaction will not be available. The Replication Details specify the completion status of the CVS command at each site. If the command's completion status is Executed, that implies the command finished with the actual CVS status as either Successful (committed for a cvs commit command) or an error from CVS (for example, up-to date check failed). If the command has not yet executed, the completion status could be In-Progress or Scheduled. The status In-Progress indicates the command is replicating. The status Scheduled indicates replication is finished and the command is waiting for locks to be obtained in order to execute.
At this time, the WANdisco CVS Replicator does not report the completion time for the remote sites. The completion time field is only valid for the local site at which the transaction was submitted. The completion status is reported for each site. The CVS user can use that to tell if the command has completed at remote sites.
When running the WANdisco CVS Replicator in a production environment it is often necessary to have the replicator process restart on termination or have the WANdisco CVS Replicator automatically start on machine reboot.
The WANdisco CVS Replicator has a built-in watchdog which can monitor the replicator process and restart it on termination. By default the watchdog mode is turned on. In the watchdog mode, the cvsreplicator process will automatically disassociate from the terminal and become a daemon process so don't background it using &.
To turn off the watchdog mode specify the -nowdog option.
If the WANdisco CVS Replicator is unable to start up; i.e., if it terminates several times in quick succession, the watchdog will start the WANdisco CVS Replicator in read-only mode.
When started in this mode,
$ ./bin/cvsreplicator -h
Usage: cvsreplicator [-v] [-verbose] [-nowdog] [-pause time]
[-email email-address]
-v Print the cvsreplicator version
-verbose
Verbose, console messages go to STDOUT/STDERR
instead of logs/console.txt
-nowdog
Turn off watchdog mode, cvsreplicator will not start a
watchdog which can automatically restart cvsreplicator
process if it terminates. Use this option for testing.
-pause
Time in seconds that the watchdog will pause for, before
restarting service. Defaults to 0 seconds.
-email
Specify an email address to send an alert to, whenever the
Watchdog restarts/shuts down the cvsreplicator service.
For email alert to work, sendmail or sendmail wrapper must be
installed in /usr/sbin/sendmail. You may want to test it by
running "sendmail -t" first.
As noted above the admin can specify an -email option to generate email alerts on WANdisco CVS Replicator restarts.
For instance:
$ cvs-replicator/bin/cvsreplicator -pause 5 -email admin@cvsjungle.com
In order to have the WANdisco CVS Replicator automatically started on system reboots, the admin can setup a init.d script at an appropriate run-level on UNIX. Here is a sample script on RedHat or Fedora Core Linux:
#!/bin/bash
#
# chkconfig: - 91 35
# description: Red Hat Linux dist compatible rc script for \
# starting/stoppping a WANdisco agent like cvs|svn replicator etc
#
# Copyright (c) 2006-2016 WANdisco,Inc. Pleasanton,CA,USA
# All rights reserved.
#
# Author: WANdisco Support Staff <support@wandisco.com>
#
# To setup boot time start : chkconfig --level 345 rh-repd on|off
# chkconfig --list rh-repd
# Source function library.
. /etc/init.d/functions
# Source networking configuration.
. /etc/sysconfig/network
# Check that networking is up.
[ ${NETWORKING} = "no" ] && exit 0
# Start: Please change to your env
USER="wandisco"
WD_cvsreplicator_TYPE="cvs"
WD_cvsreplicator_NAME="${WD_cvsreplicator_TYPE}replicator" # or cvssecurityagent or failoveragent
WD_DISPLAY_NAME="WANdisco Replicator daemon"
WD_cvsreplicator_HOME="/home/${USER}/${WD_cvsreplicator_TYPE}-replicator" # or cvs-security or svn-security
WD_cvsreplicator_OPTS="-wdog -email svnadmins@mycompany.org"
export JAVA_HOME="/export/share/apps/jdks/1.5.0"
# Stop: Please change to your env
WD_cvsreplicator_BIN="${WD_cvsreplicator_HOME}/bin/${WD_cvsreplicator_NAME}"
WD_cvsreplicator_CONF="${WD_cvsreplicator_HOME}/config/prefs.xml"
PID_FILE="${WD_cvsreplicator_HOME}/logs/my.pid"
JAVA_PID="${WD_cvsreplicator_HOME}/logs/java.pid"
NOFILES="65000"
pidfile="my.pid"
checkconfig() {
if [ ! -x ${WD_cvsreplicator_BIN} ]; then
failure "No ${WD_cvsreplicator_BIN} present"
fi
prog=${WD_DISPLAY_NAME}
}
start() {
checkconfig
echo -n "Starting $prog:"
ulimit -S -c 0 >/dev/null 2>&1
ulimit -n ${NOFILES} >/dev/null 2>&1
RETVAL=0
runuser ${USER} -c "${WD_cvsreplicator_BIN} ${WD_cvsreplicator_OPTS}" >/dev/null 2>&1
RETVAL=$?
[ "$RETVAL" -eq 0 ] && success "$WD_cvsreplicator_NAME startup" || \
failure "$WD_cvsreplicator_NAME start"
echo
[ "$RETVAL" -eq 0 ] && touch /var/lock/subsys/$WD_cvsreplicator_NAME
}
stop() {
checkconfig || return 1
echo -n "Shutting down $prog:"
runuser ${USER} -c "${WD_cvsreplicator_HOME}/bin/shutdown" >/dev/null 2>&1
RETVAL=$?
[ "$RETVAL" -eq 0 ] && success "$WD_cvsreplicator_NAME shutdown" || \
failure "$WD_cvsreplicator_NAME shutdown"
echo
[ "$RETVAL" -eq 0 ] && rm -f /var/lock/subsys/$WD_cvsreplicator_NAME
}
case "$1" in
start)
start
;;
stop)
stop
;;
restart|reload)
stop
sleep 3
start
;;
condrestart)
if [ -f /var/lock/subsys/$WD_cvsreplicator_NAME ]; then
stop
sleep 3
start
fi
;;
*)
echo $"Usage: $0 {start|stop|restart|condrestart}"
exit 1
esac
Please check the download area on our support site (http://support.wandisco.com) for scripts like the above for other platforms (Red Hat Linux etc).
When you first deploy the WANdisco CVS Replicator in your environment, you can easily test if basic CVS setup is working by using the pass through mode. This mode allows you to create a short circuit within the replicator and causes all CVS traffic to be directly relayed between CVS client and server without any replication or distributed synchronization occurring.
For example, to test if authentication via SSH is working as expected, you
may turn on this mode. The Distributed Agreement Engine is not invoked in the pass through mode,
so all configuration pertaining to it is ignored.
To setup the pass through mode, modify cvs-replicator/config/prefs.xml as :
<CVSProxy>
...
<passThrough>true</passThrough>
...
</CVSProxy>
Just set the passThrough option to true.
Normally, when a CVS write request (check in, tag, admin) arrive at the CVS server, it performs a series of checks before attempting to commit the changes. These include verifying if the revision at the client is up to date, confirming that the write actually needs to change the state on disk etc. It is possible for a CVS request to be rejected if any of these conditions is violated.
WANdisco CVS Replicator support a verify write mode. If it is turned on, WANdisco CVS Replicator will first try to verify with the local CVS pserver if the write request is valid. If and only if the request is valid, will it try to initiate network activity to apply the write in a globally consistent fashion. Thus, if the request is invalid due to say another CVS user's check in preempting this check in, the WANdisco CVS Replicator can reject it locally without incurring any network traffic. The cost of verifying a priori is negligible, so this option is turned on by default.
To turn off/on this option set verifyWrites option true or false,
by modifying cvs-replicator/config/prefs.xml file as following:
<CVSProxy>
...
<verifyWrites>true</verifyWrites>
...
</CVSProxy>
During the normal course of running WANdisco CVS Replicator, temporary files are generated.
These have the prefix cvs-proposal-{GUID}. By default, they are
written to cvs-replicator/log/fp directory. This can be over-ridden
using the cvs-replicator/config/prefs.xml file as following:
<DirPrefixMap>
<fp->/home/cvs/replicator/tmp/dir</fp->
</DirPrefixMap>
These files are periodically garbage-collected by Distributed Agreement Engine at a configurable interval. For more details see the Distributed Agreement Engine Administration Guide
An extremely light-weight HTTP/1.1 web server is built into the WANdisco CVS Replicator
infrastructure. There is no need to install or manage a separate web
server to acts as a HTTP front-end to the WANdisco CVS Replicator.
To connect to the HTTP server, simply point the browser to the Distributed Agreement Engine port.
For example, if the Distributed Agreement Engine settings are as follows:
....
<DConeNet>
<ListenerIP>sfo-cvs</ListenerIP>
<ListenerPort>6020</ListenerPort>
</DConeNet>
...
The web server can be accessed via a URL similar to [http://sfo-cvs:6020]. The Distributed Agreement Engine port is multi-protocol enabled. A single port supports a variety of connections - http, DFTP, DConeNet.
The Web interface can be used to run administrative commands on the local replicator, as well as view status of the WANdisco CVS Replicator.
The WANdisco web console requires a super user login with a password to do sensitive operations like shutdown. When you first install the WANdisco CVS Replicator, default super user name is set to root and password is set to wandisco. You should immediately change the default settings. The default super user name can be changed in the cvs-replicator/config/prefs.xml file:
<Security>
<Admin>
<user>super</user>
</Admin>
</Security>
The default password can be changed using the web console password form directly. The WANdisco CVS Replicator never stores the actual password but a one-way hash of the password string in it's internal password database.
You can also control which web console URLs require authentication. The Includes and Excludes elements in the cvs-replicator/config/prefs.xml file can be used to specify white-space separated Perl regular expression patterns to mark which URLs require security and which can be accessed without authentication. For example:
<Security>
<Http>
<SecureURL>
<Includes> ^/$ ^/write/.* </Includes>
<Excludes> ^/cvs/dashboard ^/read/.* </Excludes>
</SecureURL>
</Http>
</Security>
To secure the web traffic from the WANdisco web console to the WANdisco CVS Replicator, you can setup an SSH or SSL tunnel from the web client machine to the WANdisco CVS Replicator machine. For example:
$ ssh -p 222 -L80:localhost:6444 cvs-replica-machine
The above SSH tunnel will ensure passwords and sensitive configuration data never travels in clear-text.
From the web interface, the WANdisco CVS Replicator dashboard can be accessed. It can be used to view all the vital stats of each replicator site from a single console. The dashboard also shows the last few CVS transactions that have been committed at each site. The default is 5 transactions, it can be changed using the MaxTxnTrackInDashBoard setting in the cvs-replicator/config/prefs.xml file. For example:
<CVSProxy> ... <MaxTxnTrackInDashBoard>20</MaxTxnTrackInDashBoard> ... <.CVSProxy>
The dashboard indicates the status of the rotating quorum. The status is indicated by the color of the word Site in the top left
corner of the frame. The color is green for the distinguished node, and black for the non-distinguished node. When the distinguished node is in transit, the
old distinguished node is indicated in orange, and the new one in red.
WANdisco CVS Replicator comes bundled with several utilities for monitoring and status checking. These include:
logtimefix on the Proxy*log files. For instance:
[logs]$ tail ProxyServer-prefs.log 1121854527179 org.nirala.communica......neNet.AsyncConnector makeConnection [logs]$ ../bin/logtimefix ProxyServer-prefs.log Crunching ProxyServer-prefs.log Wrote ./time-ProxyServer-prefs.log [logs]$ tail time-ProxyServer-prefs.log Wed Jul 20 03:15:27 -0700 2005 org.nirala.comm.....yncConnector makeConnectionThe UNIX epoch date 1121854527179 was converted to Wed Jul 20 03:15:27 -0700 2005 PST by
logtimefix.
The utility can also be used to report any uncommitted but submitted CVS transactions. Just pass the -match option and a list of cvs transaction ids will be printed on the stdout.
commitrate utility. For instance :
[cvs-replicator]$ bin/commitrate logs/ProxyServer-prefs.log.0 Crunching logs/ProxyServer-prefs.log.0 Writing output to logs/commits-ProxyServer-prefs.log.0 [cvs-replicator]$ tail logs/commits-ProxyServer-prefs.log.0 CVS TxnId, C-S ms, C-S, C-E ms, C-E .......... cvs-proposal-d349fd19-fa41-11d9-b957-0011110ee979_50559, 5080, 5 s,11, 11 ms cvs-proposal-d349fd19-fa41-11d9-b957-0011110ee979_50562, 5742, 5 s,6, 6 ms cvs-proposal-d349fd19-fa41-11d9-b957-0011110ee979_50564, 5788, 5 s,8, 8 ms STATS: Min txn commit time : 3 s Max txn commit time : 11 s Last Txn Submitted at - Thu Jul 21 18:24:00 -0700 2005 Last Txn Committed at - Thu Jul 21 18:24:00 -0700 2005 1294 commits in 11 min, 110 commits/minThe summary statistics are reported at the end of
commits-Proxy* file. Prior to the summary, actual list of committed cvs transactions with various timing parameters is generated. The column format is - CVS transaction id, net time to commit after submit in milliseconds and seconds, net time to commit after the transaction starts executing in milliseconds and seconds. The C-S number indicates time consumed by Replicator and CVS server. The C-E number indicates the time consumed by the backend CVS server primarily.
WANdisco CVS Replicator contains a built-in distributed file transfer protocol (DFTP). This is used
to reliably transfer CVS files and directories between remote replicators.
DFTP optimizes the network bandwidth by streaming the files, using OS level
system calls like sendfile if available. It can automatically open
multiple connections if the connection speed is slow. It can resume
incomplete transfers to deal with network outages or process death.
By default, DFTP uses the same port as Distributed Agreement Engine. Remember - the Distributed Agreement Engine port is multi-protocol so it allows independent TCP connections for multiple protocols. If you want to dedicate a separate network channel for DFTP, you could use a different port than Distributed Agreement Engine. You could then configure a specific QoS in your routers for the DFTP ports.
To setup a DFTP port that is different from the Distributed Agreement Engine port, modify the cvs-replicator/config/prefs.xml file as following:
<MemberList>
<Member name="3bfbf219-2918-11d7-80c5-00065be02953">
<Profiles>
<TransportPolicy>AlwaysDConeNet</TransportPolicy>
<Transport>
<DConeNet>
<ListenerIP>localhost</ListenerIP>
<ListenerPort>6020</ListenerPort>
</DConeNet>
<!-- Setup a unique DFTP port /-->
<DConeFTP>
<ListenerIP>localhost</ListenerIP>
<ListenerPort>6021</ListenerPort>
</DConeFTP>
.....
WANdisco CVS Replicator uses a local locking scheduler for ensuring consistent ordering of CVS write transactions. The locking scheduler will try to maximize the concurrency of CVS writes by executing them in parallel. The concurrency level can be tuned by controlling the maximum number of threads the scheduler uses. Modify the cvs-replicator/config/prefs.xml files as follows to tune this setting:
<CVSProxy>
......
<writeStage>
<MaxBufferSize>10000</MaxBufferSize>
<!-- Concurrency of CVS locking scheduler -->
<MaxThreads>3</MaxThreads>
</writeStage>
.....
</CVSProxy>
By default the max threads used by scheduler is set to 3 and the associated wait queue size is set to 10000 CVS operations.
The WANdisco CVS Replicator allows an administrator to setup a quorum change schedule to move quorum across the replication group. This can give tremendous performance boost for sites separated by multiple timezones. For more details, please see the quorum change section in the Distributed Agreement Engine Administration Guide.
Beyond the basic setup, you may want to tune the network performance, recovery log disk IO performance, change high availability setup. All of these options apply to the Distributed Agreement Engine. Please refer to the Distributed Agreement Engine Administration Guide for further reference.
We recommend gradually increasing the complexity of your deployment scenario, and testing at each stage. Please visit our support web-site for the current deployment checklist in our knowledgebase.
WANdisco CVS Replicator will detect resource exhaustion errors and other system errors from CVS server and in response will shut itself down. The idea is to fail-fast under severe exception conditions rather than continue and cause inconsistencies in the system.
The three files cvs-replicator/config/{cvserr-sys.catalog , cvserr-nonsys.catalog , cvsnterr.catalog}
contain the regular expressions for all the errors that WANdisco CVS Replicator treats as fatal
and triggers a shutdown of the server process. These are designed to catch
disk full errors, CVS files corrupted/truncated etc kind of error conditions.
We recommend periodic incremental diffs to ensure
all the remote CVS repositories are in sync. This could be done periodically
using a cron job for example. But do remember the way WANdisco CVS Replicator works, it is possible
for two CVS repositories to appear to be different while updates are happening.
In other words if you take a snapshot while updates are being applied, the snapshots could differ from each other. This does not indicate a failure of WANdisco CVS Replicator.
So, when making snapshots for comparing, please make sure repositories are not being updated. The easiest way is to -
To do