Installation Guide

This guide describes everything you need to deploy Git MultiSite:

• Installation requirements
• A standard installation
• Node configuration

1. Before you deploy

Before installing SVN MultiSite Plus, make sure that you have sufficient hardware and that all required software is configured appropriately.

1.1 Skills requirements

This section details the knowledge and technical requirements for deployment and operation of SVN MultiSite Plus. You should ensure that each of these requirements is satisfied before you begin the deployment.

If you're not confident about handling any of these tasks, you can request a supported installation from WANdisco.

A single administrator can manage all the systems running MultiSite Plus, although it's a good idea to have someone at each site who is familiar with the MultiSite Plus Basics.

1.2 Deployment overview

As with any software implementation you should deploy SVN MultiSite Plus following a well defined plan. We recommend that any deployment plan includes the following steps:

1. Pre-deployment Planning: Identifying the requirements, people and skills needed for deployment and operation. Also covers agreeing schedule and milestones, highlighting any assumptions, constraints, dependencies and risks to a successful deployment.
2. Deployment Preparation: Preparation and identification of server specifications, locations, node configuration, repository set-up, replication architecture, server and software configurations.
3. Testing Phase: Activities related to an initial installation and testing in a non production environment, executing test cases, and verifying deployment readiness.
4. Production Deployment: Activities related to the installation, configuration, testing, and deployment in the production environment.
5. Post-deployment Operations and Maintenance: Post-deployment activities including environment monitoring, system maintenance, training and technical support.

1.3 System requirements

This section describes everything you need to know if you are preparing existing servers for replication. You should view this information as a set of guidelines, not as a fixed set of requirements, and run your own performance tests during an evaluation period.

1.3.1 Hardware recommendations

1.3.2 Storage tips

• For SVN and SVN MultiSite Plus: Use separate physical disks for SVN and SVN MultiSite Plus. This ensures that heavy disk usage by either should not impact the other. If you are running with SAN storage we recommend using a fiber connection between the server and the SAN with a minimum dedicated bandwidth of 1GiB.
• SVN repository storage requirement: Plan your requirements. Clarify what version control changes may be on the horizon so that you can account for any sudden leaps in your repository storage requirement. Consider that it's usually a lot less costly to over-specify disk capacity than have to deal with running out of storage.
• SVN MultiSite Plus storage requirement: Although the storage requirements for the installed files is fairly modest (800 mebibytes), SVN MultiSite Plus will store data that has not yet been replicated to all other replication group members. Should a node be offline for an extended period this can result in the buildup of lots of temporary data.
  How much storage does SVN MultiSite Plus need?
  We provide a guideline for calculating for WANdisco's replication products: Hardware Sizing Guide
• Use the fastest possible disks for storage, disk IO is the critical path for improving repository responsiveness.
• The use of RAID-1 or RAID-2 solutions are recommended. You should not use RAID-0, the performance benefits are not worth the drop in resilience (and increased risk of data loss). Where performance is considered more important than resilience then RAID 0+1 can be used instead. This mirrors two or more striped segments, providing the high I/O performance of RAID-0 without the increased risk of failure.
• Spinning vs Solid State: Solid state drives (SSDs) offer significant benefits for deployments that make big demands of disk I/O. SSDs are recommended if you have a large deployment or require extra capacity for future growth. However, if your concurrent SVN usage is not very high you may get acceptable performance from trustly old HDD technology.

1.3.3 Running in virtualization

• Deploying on a virtual server platform provides lots of practical benefits. Costs, admin time, flexibility can all see big improvements when running services from a small number of specialist servers. However, there is no escaping the fact that virtualization doesn't suit every application. Dedicated servers give you confidence about what resources will be available - and whilst well designed virtual platforms can build in load balancing and failover, these are often bolt-ons that work against the whole drive to consolidate physical equipment and never really offer the seperation of services or militate the risks of a single point of failure.

1.3.4 Processor tips

• SVN MultiSite Plus will run on a single 2GHz CPU, but for production you should run fast multi-core CPUs and scale the number of physical processors based on your peak concurrent usage.
• You should aim to have no more than 15 concurrent SVN users per single-core CPU or 7 concurrent users per core with multi-core CPUs.
  Example 1: A server with 4 physical single core processors is expected to support (15x1x4) = 60 concurrent users.
  Example 2: A server with 4 physical processors, each being a quad core is expected to support (7x4x4) = 112 concurrent users.

1.4 Setup requirements

1.4.1 MultiSite Plus servers

This is a summary of the requirements, you'll need to run through the more detailed Installation Checklist.

• the same operating system - including same architecture and patch versions.
  Everything the same
  The reason for keeping the setup of nodes identical is that subtle variations in software could result in non-deterministic behavior that might lead to a loss of sync.
• Java and Python installed
• a browser with network access to all servers
• a command line compression utility
• a unique license key file. (This is provided by WANdisco: you will need one for each node and you may need to provide the server IP addresses)

1.4.2 SVN installations:

We recommend that you install SVN during the installation of SVN MultiSite Plus. You can choose between version 1.7 or 1.8, both have the necessary WANdisco-modified FSFS libraries already included. Regardless of the version of SVN that you use, it must include:

• Matching file and directory level permissions on repositories
• Exactly matched contents of the svnroot directories between servers including the repository UUID, specifically:

  /conf

  Strongly recommend that the contents match between replicas

  /db

  As this is where repository data is stored it is crucial that this is a perfect match between servers

  hooks

  Pre-commit Hooks
  Wandisco's modified version of the FSFS libraries will intercept commits after any pre-commit hooks have run. This means that the pre-commit hook run on the initiating node (on the server, Apache, SVNserve, etc.) rather than in the replicator. Should a pre-commit hook fail then the server will return an error to the client before the FSFSWD intercept call. As a result, the replicator is never involved with failed pre-commit hooks (with the possible exception of protorev/abort notifications. So, if a commit (on the originating node) is delegated for replication, any related pre-commit hook will already have succeeded.

  Post-commit Hooks
  The replicator completes the commit on the originating node by invoking a JNI function - a low level function that doesn't run any hooks. When the replicator returns the commit status to the originating repository FSFSWD a successful commit will cause the post-commit to run on the server.

  The net effect is that pre- and post- hooks run in the server on the originating repository and they do not run at all for the replicated repositories. Although a replicator could explicitly invoke the hooks for the replicated repositories if required.

  
  

  Replicated Post-commit Hooks
  There are lots of scenarios where it is essential that a post-commit hook runs on other nodes, not just the node on which it is initially triggered, for example - running continous build servers that are triggered by post-commit hooks.

  In order to support these situations there's a method for ensuring that Post-commit Hooks are triggered on some or all other nodes.

  Supported Replicated Hooks

  Hooks that start with the prefix "repl-" are recognised and picked up by WANdisco's replicator. When run locally, the replicator will trigger them on all other nodes in which they are placed. You can exclude nodes by not including a "repl-" version of the hook.

  Listed below is a list of the replicated hook names that are currently supported:

  • repl-post-commit
  • repl-post-revprop-change
  • repl-post-lock
  • repl-post-unlock

  Hook scripts that are replicated are run in the following temp directory which will be created on each applicable node:

  /opt/wandisco/svn-multisite-plus/replicator/hooks/tmp

  The usual requirements for running hook scripts still apply, the hook must be executable for the system user.

  Limitations
  Replication of post-commit hooks is straight forward, however other post-hooks, such as post-revprop-change may carry arguments, such as "username" to which replicated hook scripts won't have access (the replicator is working below the authn layer). In situations where "USER" is needed, we implant the value "UNKNOWN" in order to ensure that the hook doesn't error.

  locks

  Locks must be sync'ed between nodes. You can't afford for a commit to be rejected on one site that was allowed on all the others.

2. Installation checklist

Though you may have referred to the Installation Checklist prior to an evaluation of SVN MultiSite Plus we strongly recommend that you revisit the checklist and confirm that your system still meets all requirements.

        /opt/wandisco/svn-multisite-plus/resources/svn
        -rwxr-xr-x 1 root root    78400 Jun 17 16:20 mod_dav_svn-1.8.8-1.x86_64.rpm
        -rwxr-xr-x 1 root root    44276 Jun 17 16:20 serf-1.3.4-1.x86_64.rpm
        -rwxr-xr-x 1 root root  2267700 Jun 17 16:20 subversion-1.8.8-1.x86_64.rpm
        -rwxr-xr-x 1 root root 11352880 Jun 17 16:20 subversion-debuginfo-1.8.8-1.x86_64.rpm
        -rwxr-xr-x 1 root root  3715880 Jun 17 16:20 subversion-devel-1.8.8-1.x86_64.rpm
        -rwxr-xr-x 1 root root    24124 Jun 17 16:20 subversion-fsfswd-1.8.8-1.x86_64.rpm
        -rwxr-xr-x 1 root root   259648 Jun 17 16:20 subversion-javahl-1.8.8-1.x86_64.rpm
        -rwxr-xr-x 1 root root   968424 Jun 17 16:20 subversion-perl-1.8.8-1.x86_64.rpm
        -rwxr-xr-x 1 root root   690808 Jun 17 16:20 subversion-python-1.8.8-1.x86_64.rpm
        -rwxr-xr-x 1 root root    71288 Jun 17 16:20 subversion-tools-1.8.8-1.x86_64.rpm
      

      	svnadmin create Repo --fs-type fsfswd
      	Then edit Repository_name/db/fsfs.conf (view an example fsfs.conf file)

      	uncomment the line:
      	#rep_port = 7777
      

[root@redhat6 wandisco]# lsb_release -a

          LSB Version:    :base-4.0-amd64:base-4.0-noarch:core-4.0-amd64:core-4.0-noarch:graphics-4.0-amd64:
          graphics-4.0-noarch:printing-4.0-amd64:printing-4.0-noarch
          Distributor ID: RedHatEnterpriseServer
          Description:    Red Hat Enterprise Linux Server release 6.4 (Santiago)
          Release:        6.4
          Codename:       Santiago
        

      ulimit -u && ulimit -n
      

      RHEL6 and later:
      A file /etc/security/limits.d/90-nproc.conf explicitly overrides the settings in security.conf, i.e.:
      # Default limit for number of user's processes to prevent
      # accidental fork bombs.
      # See rhbz #432903 for reasoning.
      * soft nproc 1024 <- Increase this limit or ulimit -u will be reset to 1024
      

$JAVA_HOME/lib/security/

2.1 Migrating from SVN MultiSite 4.x

SVN MultiSite Plus uses a new version of WANdisco's DConE replication engine and has a different architecture compared with earlier versions of MultiSite. As a result there are some special considerations when migrating from SVN MultiSite 4.x

2.1.1 Byte-for-byte replicas

Repository replicas must be byte-for-byte mirrors of each other. This stringent requirement did not apply to SVN MultiSite 4.x - the previous tests for whether replicas are identical are not sufficient for FSFSWD replication (see 4.2 vs Plus, below). As a result you will need to recreate your replica repositories using a nominated master repository.

• You'll need to identify which of your current replicas is to be the master repository.
• You'll then remove / backup all other replicas.
• Rsync from master to remote servers using checksumming *recursively (-r)*.

The exact process of copying repositories may need to be carefully thought out in order to be practical and achievable. Many production repositories will take a long time to checksum. If you are in any doubt about handling the process, talk to your WANdisco account manager.

2.1.2 Authentication and Apache

SVN MultiSite Plus opens up more options because MultiSite is no longer running as proxy and options that were previously not compatible with MultiSite now are compatible.

Other factors to consider include:

• Access Control is no longer working as a proxy, all the traffic goes through Apache, everything at the repository level.

• Access Control rules no longer supports regular expressions for defining repository paths and the concept of pre-replication authentication has been done away with.
• Access Control still needs to be integrated with existing LDAP.
• Lost the ability to specify rules using regular expressions - the concept of pre-replication authentication has been done away with.
• Hook scripts - these no longer need to all run on all nodes. See Hook Scripts.

2.2 Configuring Apache

This section gives an example Apache configuration. In Apache's config file, httpd.conf:

1. Set the listen port. There's more information about the Listen directive in the Binding chapter of the Apache documentation.
2. Change the Apache KeepAlive settings to allow long-lived HTTP connections.
3. Make sure that the SVN DAV settings in Apache's configuration files are exactly the same at all nodes. The top-level location URI prefix should be the same.

       # Needed to do Subversion Apache server.
       LoadModule dav_svn_module modules/mod_dav_svn.so
   
       # Only needed if you decide to do "per-directory" access control.
       LoadModule authz_svn_module modules/mod_authz_svn.so
   
   
       Listen 80
       MaxKeepAliveRequests 0
       KeepAlive On
       KeepAliveTimeout 30000
       Timeout 7200
   
         <Location /svn>
             DAV svn
             SVNParentPath /opt/Subversion
             AuthType Basic
             AuthName "SVN Repo"
             AuthUserFile /opt/Subversion/svn.passwd
             #AuthzSVNAccessFile /home/user/svnauthfiles/authz.authz
             Require valid-user
         </Location>
       

4. Make sure that the Apache usernames and passwords match at all nodes.
   Note:
   SVN MultiSite must have a valid username inside the HTTP authorization header to be passed for all DAV commands.

3. Installation

The installation guide runs through setting up SVN MultiSite Plus for the first time. If you are upgrading from an earlier version of SVN MultiSite Plus you should also follow this procedure - SVN MultiSite Plus is a completely new class of product so it's not possible to follow a shortcut upgrade procedure.

3.1 Installation overview

This is an overview of the process:

1. Double-check the Installation checklist. Take time to make sure that you have everything set up and ready. This avoids problems during installation. In particular, check:
   • SVN authentication: SVN installed, and using authentication. If you require a SVN access control solution see our Access Control product.
   
   
   • JDK7: You need to have Oracle's Java JDK 7 installed.
     
     Important: use Oracle JAVA JDK 7
     All our development and testing is done using JDK 7. You will need to use JDK 7 to ensure compatibility with SVN MultiSite Plus. It may be possible to run SVN MultiSite Plus with other versions of Java, although, in future, we won't support it.
   
   
   • Java memory settings: The Java process on which SVN MultiSite Plus runs is assigned a minimum and maximum amount of system memory. By default it gets 128MB at startup and 4GB maximum.
   
   
   • System resources: Ensure that your system meets the hardware recommendations.
   
   
2. Ensure that your repositories are copied into place on all nodes.


3. Download and copy the MultiSite Plus files into place.


4. Run the setup (as root user), then complete the installation from a web browser.
Setting the LOG_FILE environmental variable
If you need to capture a complete record of installer messages, warnings, errors, then you need to set the LOG_FILE environment variable before running the installer. Run:
 export LOG_FILE="opt/wandiscoscp/log/file.file"
This file's permissions must allow being appended to by the installer. Ideally, the file should not already exist (or it should exist and be empty) and its directory should enable the account running the installer to create the file.

3.2 Before you start

• Check through the Installation checklist
• Back up Apache Config> Because the installation could modify your Apache configuration, we recommend that if you have existing config, you back it up before the installation and do a reconcillation once the installation has completed to check any changes are not going to adversely affect your operation.

3.3 Starting the installation

This procedure requires the entry of various settings into the terminal session during the installation. You can run the installation in a non-interactive mode which doesn't require user input (until then post-installation browser-based set up). To use the Non-interactive mode, see Non-interactive Installation

Run SVN MultiSite Plus installer as root
The installation will require full system access so you must run the installer as root or a user with equivalent permissions.
1. Extract the setup file.
2. Save the svn-multisite-plus.sh installer file to your Installation site.
3. Make the script executable, e.g. enter the command:

   chmod a+x svn-multisite-plus.sh

4. Run the setup script.
   Running with Apache?
   Run both SVN MultiSite Plus and Apache with the same user.
   
   Back up any existing Apache configuration files
   When the installation is complete, perform a verification to check that any changes will not impact your operation.

       [root@redhat6 wandisco]# chmod a+x multisite-plus.sh
       [root@redhat6 wandisco]# ./svn-multisite-plus.sh
       Verifying archive integrity... All good.
       Uncompressing WANdisco SVN MultiSite Plus....................
           ::   ::  ::     #     #   ##    ####  ######   #   #####   #####   #####
          :::: :::: :::    #     #  #  #  ##  ## #     #  #  #     # #     # #     #
         ::::::::::: :::   #  #  # #    # #    # #     #  #  #       #       #     #
        ::::::::::::: :::  # # # # #    # #    # #     #  #   #####  #       #     #
         ::::::::::: :::   # # # # #    # #    # #     #  #        # #       #     #
          :::: :::: :::    ##   ##  #  ## #    # #     #  #  #     # #     # #     #
           ::   ::  ::     #     #   ## # #    # ######   #   #####   #####   #####
   
       Welcome to the WANdisco SVN MultiSite Plus installation
   
       Checking prerequisites:
   
       Checking for perl: OK
       Checking for svn: SVN MultiSite Plus requires a compatible version of SVN to be installed.
   
       Install SVN? [Y] > Y
       Installing SVN 1.8.3-1
       

5. On a clean system you need to enter "Y" to install a compatible version of SVN onto your server. If you already have a suitable SVN installation in place you could select "N".

       Install mod_dav_svn? (Y/n) Y
   
       Stopping httpd: [  OK  ]
       Starting httpd: [  OK  ]
       OK
   
       

   Select "Y".
6. The next test looks at the Java heap settings. It lists the maximum and minimum allocations for both the replicator component of SVN MultiSite Plus as well as the admin console UI:

       INFO: Using the following Memory settings:
   
       INFO: UI:         -Xms128m -Xmx1024m
       INFO: Replicator: -Xms1024m -Xmx4096m
   
       Do you want to use these settings for the installation? (Y/n) Y
       

   Enter "Y" if these heap settings will suit the needs of your deployment, then enter your preferred values. If you have any doubts, discuss the heap requirements with WANdisco's support team before going into production.
7. You'll now be asked to enter a TCP port number for accessing the browser part of the installation process.

       Which port should the MultiSite UI listen on? [8080]:
       

   We use port 8080 in our documentation. If that port is okay, press Enter. Check with your network administrator about which ports are available. You can change the port during the next part of the installation.
8. The installer now checks to see which system user and system group should be used to run SVN MultiSite Plus.
   Run SVN MultiSite Plus with the same user that runs Apache
   When deploying SVN MultiSite Plus with Apache, ensure that they are both run by the same system user. Their operations are so entwined that attempting to run the services with separate users will introduce the risk of permission problems that would halt replication.

       We strongly advise against running SVN MultiSite Plus as the root user.
   
       Which user should SVN MultiSite Plus run as? wandisco
       Do you want to continue? (Y/n)Y
   
       Which group should SVN MultiSite Plus run as? wandisco
       

   In this example we have system user and group set up for 'wandisco'. Also, take note of the above warning about not running SVN MultiSite Plus with a different user account.
9. The installer now asks you to set the umask value for SVN MultiSite Plus:

   What umask should SVN MultiSite Plus use? [022]:

   You can with the default of 022, this will result in permissions set at 755, if the owner permission is set less than 7 the replicator won't have sufficient permission to start up. Group/Other permissions are not so critical.
   Testing your umask setting
   To check what umask value is being applied, create a repository via the Admin UI then check the new repositories permissions on the file system to ensure they match your umask value.
10. The installer provides you with a summary of the settings you've so far provided:

        MultiSite user:    wandisco
        MultiSite group:   wandisco
        MultiSite UI Port: 8080
        MultiSite UI Minimum memory: 128
        MultiSite UI Maximum memory: 1024
        MultiSite Replicator Minimum memory: 1024
        MultiSite Replicator Maximum memory: 4096
    
        Do you want to continue with the installation? (Y/n) y
        

    Enter "Y" unless you want to make changes to any of these choices.
11. Open a browser and go to the provided URL. If your server's DNS isn't running you can go to the next step at the following address:

        Starting ui:[  OK  ]
        ..........
    
        Please access the Web UI with a browser at the following address -
        http://ip-10-0-100-152:8080/multisite-local
        Installation Complete
        

    e.g.
    http://10.0.100.152:8080/multisite-local/
    
    
12. 
    

    Welcome to SVN MultiSite Plus.
    You're about to run through the installation, which should only take a couple of minutes.
    
    If you run into difficulties on the way, check our documentation or talk to our support team through the Customer Support Website.
    
    Before you click Next, make sure you Read the Installation Checklist
    

    Click Next to begin the installation.
13. The next (Terms & Conditions) screen contains the WANdisco Master Subscription Agreement.
    To continue the installation click the I AGREE button.


14. On the next (License Upload) screen you are prompted to browse for your product license key file. Click on the + Browse button and locate your file. You will have been sent this by the WANdisco sales team, contact them if you have any problems locating or using your license file.
    
15. On the Administrator Setup screen you indicate whether this is the installation of the first node or a subsequent node.
    This is the first node:
    If this is the first node you'll be prompted to enter the username plus an associated password which you will use to log in to SVN MultiSite Plus' UI.
    
    

    Username

    The administrator's username.

    Password

    The administrator's password.

    Confirm Password

    Enter your password again to confirm that it's been typed in correctly.

    Full Name

    Enter your full name.

    Email address

    Enter the email address that you wish to associate with your SVN MultiSite Plus admin account

    This is the second or a subsequent node:
    For later installations, you will, instead, be prompted for the users.properties
    (default location: /opt/wandisco/svn-multisite-plus/replicator/properties/users.properties) file of the first node rather than risking a mismatch in admin account details between nodes - something that could prevent you from connecting the nodes together during induction.
    Can I just enter the same details?
    No, while you could enter exactly the same details for each node, encrypted password would not match. You've got to copy the users.properties file, there's no shortcut. In the event that this has been done, you can match up the neccessary details using the procedure for Matching a node's admin settings.
    Important
    If you are providing a users.properties file, take extra care to select the correct file. You won't be warned if the file is invalid and selecting the wrong file will prevent you from connecting the node to the replication network.


16. The last screen in the setup process covers Server Settings.
    
    

    Node Name

    The default name for this node.

    Temporary limitation
    Node names can not contain spaces or ".".

    Node IP/Host

    The node's IP or hostname. If the server is multi-homed, you can select the IP to which you want SVN MultiSite Plus to be associated.

    Replication Port

    Select the port that will be used for agreement traffic between nodes.

    Content Server Port

    Select the port that will be used to transfer replicated content (repository changes). This is different from the port used by WANdisco's DConE² agreement engine.

    Content Node Count

    This setting gives you the ability to enforce a degree of resiliance. The value represents the number of nodes within a membership that must receive the content before a proposal is submitted for agreement. If the value is greater than the total learners in the current membership, then the value is adjusted to equal the total number of learners in the current membership. The proposing node is not considered in the calculation.

    Minimum Content Nodes Required

    Ticking this checkbox will enforce the Content Node Count as a prerequisite for replication.

    REST API Port

    The port to be used for SVN MultiSite Plus's REST-based API. (Default:8082)

    REST API SSL Port

    The port to be used for SVN MultiSite Plus's REST-based API when traffic is secured using SSL encryption.

    REST API Using SSL

    Check box for enabling the use of SSL for all API traffic.

    SSL Trust Store

    The location of your trust store file. Trust stores contain CA certifcates to trust. If your server's certificate is signed by a recognized Certification Authority (CA), the default trust store that ships with the JR will already trust it (because it already trusts trustworthy CAs), so you don't need to build your own, or to add anything to the one from the JRE.

    SSL Trust Store Password

    The password for your trust store.

    SSL Key Store

    The name of the keystore file. The keystore contains a public keys. for authorized users.

    SSL Key Store Password

    The password associated with the keystore.

    A word about trust stores and key stores
    You might be familiar with the Public-key system that allows two parties to use encryption to keep their communication with each other private (incomprehensible to an intercepting third-party). The keystore is used to store the public and private keys that are used in this system. However, in isolation, the system remains susceptible to the hijacking of the public key file, where an end user may receive a fake public key and be unaware that it will enable communication with an impostor. Enter Certificate Authorities (CAs). These trusted third parties issue digital certificates that verify that a given public key matches with the expected owner. These digital certificates are kept in the trust store. An SSL implementation that uses both keystore and trust store files offers a more secure SSL solution.

If you need help getting your SSL keys set up, check out our guide in the Appendix - Setting up SSL

17. Click FINISH when you have entered everything. The installer will now complete the configuration. Once that's all done a START USING MULTISITE PLUS button will appear. Click the button to login for the first time.
18. Time to log in. Enter the username and password during step 12. Then click FINISHED - LET'S GO!.
19. Next, you'll need to agreed to the WANdisco Subscription Agreement. Click I Agree to continue.
    
    Temporary duplication of license agreement
    Currently the license agreement is presented twice - once during installation and then here, when the first end user logs in. In a future release we'll phase out is end-user agreement screen to remove the apparent duplication.
    
20. The first time you view the dashboard, it will contain mostly blank areas. You can view the reference section to learn what all the buttons and options mean. At this point you can set up some of your settings, such as SSL. However, we recommend holding off more advanced admin account management until you have completed induction.
    

3.4 Non-interactive installation

You can now install SVN MultiSite Plus non-interactively. To do so the following environment variables must be set:

MSP_USER

The system user that run MultiSite Plus.

MSP_GROUP

The system group that MultiSite Plus will run within.

MSP_UI_PORT

The TCP port the browser UI will initially use - you'll be able to change this during the browser-based setup.

MSP_NO_SVN

Should you wish to exclude the SVN installation that is incorporated into the SVN MultiSite Plus installer you should use this variable. Note that if the server doesn't already have a compatible version of SVN installed, the SVN MultiSite Plus installation will not complete.

MSP_UMASK

Set your required Umask settings. We validate your entry so that it must be a three digit number that begins with a zero, e.g. 077.


Optional variables:

MSP_UI_MEM_LOW

The minimum amount of UI memory.

MSP_UI_MEM_HIGH

The maximum amount of UI memory.

MSP_REP_MEM_LOW

The minimum amount of Replicator memory.

MSP_REP_MEM_HIGH

The maximum amount of Replicator memory.

A scripted start to the installation requires the running of the following command:

MSP_USER=wandisco
MSP_GROUP=wandisco
MSP_UI_PORT=8181
MSP_UMASK=0777
export MSP_USER MSP_GROUP MSP_UI_PORT
./svn-multisite-plus.sh

The installation will then run without user interaction. Once installation is completed, the browser-based UI will start. You'll then need to complete the node set up from step 10.

4. Repeat the installation process at all sites

Now repeat the installation process for every node that you want to share your SVN repositories.

Note
To ensure a successful induction, you will take the configuration files from the first node and use them during the installation of all additional nodes to ensure that all nodes are started with the same administrator account.

You may benefit from creating an image of your initial server, with the repositories in place and using this as a starting point on your other sites. This helps ensure that your replicas are in exactly the same state.
Same Location
All replicas must be in the same location (same absolute path) and in exactly the same state before replication can start.
Same UUID
If you start with new repositories, don't create them individually at each node. This is because even though they may share the same repository data, each will have it's own universally unique identifier (UUID) - unless they have the same UUID they're not replicas.<

Ensure that all nodes have matching configuration before completing the inductions

• Copy configuration (e.g. admin account property file, SSL certs) to all other servers on which you intent to install SVN MultiSite Plus.
• Run the installer on the servers nodes and continue to the the induction. Installer will let you select the copied-over admin property file instead of manually entering details for the admin account.
• If you do not provide the admin account property file during installation, or the admin accounts use LDAP, or the admin accounts change before induction, then you have to use the regular export-import process.
• If you have conflicts in the admin accounts then you need to delete or rename accounts on the to-be-inducted node to remove the conflicts.

5. Node induction

After installing SVN MultiSite Plus at all sites, you'll need to make the sites aware of each other through the node induction process. There's a particular way that you need to run through this process so get another coffee and don't skip this section.

5.1 Membership induction

It's important that sites are connected together in a specific sequence. Run through the following steps to ensure that your sites are all able to talk to each other:

1. When SVN MultiSite Plus is installed on all your sites, select one node to be your Inductor. This node will accept requests for membership and share its existing membership information. It doesn't matter which node you select.
   
2. Log in to this Inductor's admin console (http://<Inductor's IP>:8080/multisite-local/) and gather the following information, most is available from the Settings tab.
   
   All your remaining sites are now classed as Inductees.
3. Select one of your remaining Inductee sites. Connect to its web admin console (http://<Inductee1:8080/multisite-local/) and go to the Nodes tab.
4. Click on the CONNECT TO NODE button and enter the details that you collected from your Inductor node.
   
   

   Node Id *

   The name of the inductor node - you can verify this from the NODE ID entry on the Inductor node's Settings tab (see step 2, above.)

   Node Location Id *

   The reference code that is used to define the inductor node's location -you can verify this from the NODE ID entry on the Inductor node's SETTINGS tab (see step 2, above).

   Node IP Address *

   The IP address of the inductor node server.

   Node Port No *

   The DConE Port number (6444 by default), defined on the inductor node's SETTINGS tab.

   
   When these details are entered, click the SEND CONNECTION REQUEST button. The inductor node will accept the request and add the inductee to its membership. You will need to refresh your browser to see that this has happened..
   
5. Go back to step 3 and select one of your remaining inductees. Repeat this process until all the sites that you want to be included in the current membership have been connected to the inductor.



5.2 If induction fails

If the induction process fails, you may be left with the inductee in a pending state:

1. From the Nodes tab, review the state of your prospective node. During the induction process a prospect will display a Connectivity Status of "Pending Induction". The process should complete within a few seconds, providing that there isn't a network connection problem.
   
   If the prospect appears to be stuck in the pending state then click the Cancel Induction link.
2. A growl message confirms that the induction was cancelled successfully. Click the Reload button to clear the cancelled induction.
   
   
3. Repeat the induction procedure after confirming:
   
   • You are entering the correct details for the inductee node.
   • There isn't a network outage between nodes.
   • There isn't a network configuration problem, such as a firewall blocking the necessary ports.
   • There isn't an admin account mismatch between nodes - this occurs if you don't use the correct procedure for installing a second or subsequent node If the admin account doesn't match because nodes were not installed using the first node's user.properties file then you should follow Matching a node's admin settings.
   • There isn't a product license problem. Should the license file clash between two nodes, or be missing from a node this could cause induction to fail. License problems are noted in the Application Logs.

5.3 Matching a node's admin settings

Ensure that all nodes start with a common admin account by importing the admin settings from the first installed node during the installation of all subsequent nodes. If a node is accidently installed without this match you can use the following procedure to resync them. You'll need to follow this if you wish to induct the mismatched node into a replication network that includes the other nodes.

1. Log in to your first node, click on the Security and click Export Security Settings to perform a security (user) settings export.
   
2. Access the same node using a terminal window. Copy the exported settings file (/opt/wandisco/svn-multisite-plus/replicator/export/security-export.xml) to a location on the node that you fixing. e.g.

   /opt/wandisco/svn-multisite-plus/replicator/import/security-export.xml

3. Log in to the admin UI of the node that you're fixing. Click on the Security tab then click the Import Secure Settings button.
   
4. Enter the path to the copied across security-export.xml file then click Check. You'll be presented with a Diff report that shows you what differences exist between the current user settings and those in the exported file. Click Import to overwrite the existing admin user settings with the correct user settings that will match those used in the other nodes.


5. Now that the admin user account details are matching again you'll be able to complete an induction of the corrected node into a replication network.

6. Create a replication group

SVN MultiSite Plus lets you share specific repositories between selected sites. This is done by creating Replication Groups that contain a list of sites and the specific repositories they will share.




This illustration shows a collection of four sites that are running two replication groups. Replication Group one replicates Repo1 across all four sites, whilst Replication Group 2 replicates repo2 across a subset of sites.

Follow this procedure to create a Replication Group. You can create as many replication groups as you like. However, each repository can only be part of one active replication group at a time.



1. When you have sites defined, click on the REPLICATION GROUPS tab. Then click on the CREATE REPLICATION GROUP button.
   
   Replication Group Validation
   The admin UI won't let you create a replication group that doesn't meet the requirement set by DConE, for example, the proposed replication group must not have an even number of "acceptor" nodes (without also having a tie-breaker. When the selected member nodes don't make a valid replication group, the "Create Replication Group" button will be disabled (greyed out).
   
   

   Create Replication Group

   Local node automatically made the first member
   You cannot create a replication group remotely - the node on which you are creating the group must itself be an member. For this reason, when creating a replication group, the first node is added automatically.
2. Enter a name for your Replication Group in the Replication Group Name field. Then enter an existing Node name in the Add Sites field - any existing sites that match your entry will appear and can be selected with a click. Instead of typing in a name you can click on the drop-down button and choose from a list of existing sites (that are not already members of the new group).
   You can select any number of available Sites. Those sites that you select will appear as clickable buttons in the Add Node field.
   

   Enter a name and add some nodes.

3. New sites are added as Active Voters (denoted with "AV"). You can change the type of a node by clicking on its label. For an explanation of what each node type does, view the Reference Section - Node Types
   

   Change node type

   When you have added all sites and configured their type, click CREATE REPLICATION GROUP to see a groups details.
4. Replication Groups that you create will be listed on the REPLICATION GROUPS tab.
   

   Groups boxes, click QUICK VIEW view your options.

Important: Don't cancel replication group creation tasks
If you create a new replication group, then find that the task is stuck in pending because one of your nodes is down, do not use the Cancel Tasks option on the Dashboard's Pending Tasks table.
If, when all nodes are up and running, the replication group creation tasks are still not progressing, please contact the WANdisco support team for assistance.


7. Add repositories

When you have added at least one replication group you can add repositories to your node:

Warning A repository UUID is integral to the way SVN Multisite Plus tracks repositories. You must not introduce repositories that have duplicate UUIDs.
This means:
• You cannot add two existing repositories with the same UUID.
• You cannot use "svnadmin load --force-uuid" if the load will use a UUID that already exists on an SVN MultiSite Plus replicated repository.
• You cannot use "svnadmin setuuid" on a repository, and use a UUID that already exists on an SVN MultiSite Plus replicated repository.
1. Click on the REPOSITORIES tab. Click on the ADD button.
   
   

   Repositories > ADD

2. Enter the Repository's name, the file system path (full path to the repository) and use the drop-down to select the replication group. You can set the repository to be Read-only by ticking the Global Read-Only option. This option, if selected, means that the repository will not accept write activity from any node until the setting is cleared. You may find it useful to set this to verify successful replication activity before allowing end user access to the repository. You can deselect this later. Click ADD REPO.
   
   

   Repositories > Enter details then click ADD REPO

3. When added, a repository will appear in a list on the REPOSITORIES tab. The list provides the following details.
   
   

   Repositories listed

   Repo Name

   The name you assign to the repository - this can be the same name that you give to the repository's folder on the file system, or it could be something else. There are no obvious limitations when naming a repository, although we recommend that you use a conservative naming scheme that avoids spaces and special characters etc.

   FS Path

   The file system path to the Repository.

   Replication Group

   The Replication Group in which the repository will be replicated.

   Size

   The file size of the repository. We use the binary prefix (KiB, MiB, GiB, etc) to denote that data is measured in blocks of 1024 bytes.

   Youngest Rev

   The youngest (latest) revision in the repository. Comparing the youngest revisions between replicas is a quick test that a repository is in the same state on all sites.

   Transactions

   The number of pending transactions associated with each repositorty.

   Last Modified

   The timestamp for the last revision, which provides a quick indicator for the last time a SVN user made a change.

   Global RO

   Checkbox that indicates whether the repository is globally Read-only, that is Read-only at all sites.

   Local RO

   Checkbox that indicates whether the repository is locally Read-only, that is Read-only to users at this node. The repository receives updates from the replicas on other sites, but never instigates changes itself.

   Status

   Indicates the replication status of each repository. Normally a repository status will be "Replicating".