2. Installation Guide

2.3 Installation Procedure

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

Installation overview

Before we begin, here is a recap of the installation process:

• 1. Revisit the Installation Checklist. Taking extra time making sure you have everything set up and ready may save you from running into problems during the installation process. The main boxes you need to tick are:
  • Git authentication: Git installed, and using authentication.
  • JDK: You'll need to be running an Oracle JDK. We recommend JDK 7, but 6 will work, with warnings.
  • Java Memory Settings: The Java process on which Git MultiSite runs is assigned a minimum and maximum amount of system memory, by default it will get 128MB at start up and 4GB Maximum.
  • System resources: Ensure that your system is going to operate with a comfortable margin.
• 2. Ensure that your repositories are copied into place on all nodes.
• 3. Download and copy the MultiSite files into place.
• 4. Run the setup, then complete the installation from a web browser.

First steps

Some things you should bear in mind before starting the installation:

• Check through the Pre-installation Checklist
• Ensure that you have WANdisco's latest Git binaries pre-installed. Git MultiSite edition requires FSFSWD libraries that are built into WANdisco's version of Git
• Repositories need to be created using the file system switch (--fs-type fsfswd)

Starting the installation

• 1. Extract the setup file.
• 2. Save the wandisco-git-multisite.sh installer file to your Installation site.
• 3. Make the script executable, e.g. enter the command:

  chmod a+x wandisco-git-multisite.sh

• 4. Run the setup script.

  
  [root@redhat6 ~]# chmod a+x git-multisite.sh
  [root@redhat6 ~]# ./git-multisite.sh
  Verifying archive integrity... All good.
  Uncompressing WANdisco MultiSite .......
      ::   ::  ::     #     #   ##    ####  ######   #   #####   #####   ##### 
     :::: :::: :::    #     #  #  #  ##  ## #     #  #  #     # #     # #     # 
    ::::::::::: :::   #  #  # #    # #    # #     #  #  #       #       #     # 
   ::::::::::::: :::  # # # # #    # #    # #     #  #   #####  #       #     # 
    ::::::::::: :::   # # # # #    # #    # #     #  #        # #       #     # 
     :::: :::: :::    ##   ##  #  ## #    # #     #  #  #     # #     # #     # 
      ::   ::  ::     #     #   ## # #    # ######   #   #####   #####   #####  
  
  
  
  
  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) 
  

• 5. Enter "Y" and click enter.

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

  Confirm the port you wish to run the admin interface on

  We strongly advise against running Git MultiSite as the root user.
  
  Which user should Git MultiSite run as?

  Confirm the user who will run Git Multisite.

  This user will need to have read and write access to your git repos

  Which group should Git MultiSite run as?

  Confirm the group of the user running Git Multisite

  Installing with the following settings:
  
  MultiSite user:    gitms
  MultiSite group:   gitms
  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)

  Confirm the configuration settings and hit Y to finish the install. In our example, our server will run as gitms with a group of gitms.

• 10. 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:

  http://<IP_Adress>:<admin port>/multisite-local

  e.g.
  http://10.0.100.252:8080/
  
  
• 11. The web installer begins with the Welcome screen Welcome to the installation of Git MultiSite.
  

  Welcome to Git MultiSite.
  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.
• 12. The next (Terms & Conditions) screen contains the WANdisco Master Subscription Agreement.
  To continue the installation click the I AGREE button.
• 13. 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.
  
  

• 14. On the Administrator Setup screen you enter the username plus an associated password which you will use to login to Git MultiSite's 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.

  User Interface HTTP Port

  You entered the port during the first part of the installation, it's now possible to choose an alternate port here.
  This port is sometimes referred to as the jetty port.

• 15. The last screen in the setup process covers Server Settings.
  
  

  Node ID

  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 Git MultiSite to be associated.

  Latitude

  Git MultiSite schedules changes to replication based on the local time. For this reason we capture the coordinates of the node's location. The default location is close to WANdisco's Sheffield office. You can quickly capture your node's location using one of many online map tools

  Longitude

  The longitude of the server's location.

  Replication Port

  Select the port that will be used for replicated Git repository data. (Default: 6444)

  Content Server Port

  Select the port that will be used to transfer replicated content (repository changes). (Default: 4321)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, it is adjusted to total 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 Git MultiSite's REST-based API. (Default: 8082)

  REST API UI Using SSL

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

  REST API SSL Port

  The port to be used for Git MultiSite's REST-based API when traffic is secured using SSL encryption. (Default: 8445)

  UI Port

  The port for HTTP access to the MultiSite administrative interface. (Default: 8080)

  UI SSL Port

  The port for HTTPS encrypted access to the MultiSite administrative interface. (Default: 8443)

  SSL Certificate Alias

  The name of your SSL Certificate file.

  SSL Key Password

  The password for your HTTPS service.

  SSL Key Store

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

  SSL Key Store Password

  The password associated with the keystore.

  SSL Trust Store

  The location of your trust store file. The Truststore contains CA certifcates to trust. If your server's certificate is signed by a recognized Certification Authority (CA), the default truststore that ships with the JRE 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.

  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 communications 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, iIn isolation, however, 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 truststore. An SSL implementation that uses both keystore and truststore files offers a more secure SSL solution.

• 16. Click FINISH when you have entered everything. The installer will now complete the configuration. Once that's all done a START USING MULTISITE button will appear. Click the button to login for the first time.
  
  
• 17. Time to login. Enter the username and password during step 12. Then click FINISHED - LET'S GO!.
• 18. 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.

Repeat the installation process at all sites

Now repeat section 3 for each node that you wish to share your Git repositories.
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 will help you ensure that your replicas are in exactly the same state.

2.4 Node Configuration

After installing Git MultiSite 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.

Membership Induction

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

• 1. When Git MultiSite 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. Login 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 you 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 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.

Create a Replication Group

Git MultiSite 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. Once you have sites defined, click on the REPLICATION GROUPS tab. Then click on the CREATE REPLICATION GROUP button.
  
  

  Create Replication Group

  
  


Local node automatically made the first member
It's not possible to 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 node.



• 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

  Once 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.

Add Repositories

Once you have added at least one Replication Group you will be able to add repositories to your node. Here's how:

• 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 Ready-only You can deselect this later. Click ADD REPO.
  
  

  Repositories > Enter details then click ADD REPO

Alert If a repository that you added gets stuck in the deploying state - you'll see this on the Dashboard, in the Replicator Tasks window - you can cancel the deployment and try adding the repository again. To cancel a deployment, go to the Replicator Tasks window and click on the Cancel Task link.
• 3. Once added, a repository will appear in a list on the REPOSITORIES tab. The list provides the following details.
  
  

  Repositories listed

  
  

  Name

  The name of the repository - this will be the same as the folder name in the Git directory.

  Path

  The full path to the Repository.

  Replication Group

  The Replication Group in which the repository may be replicated.

  Size

  The file size of the repository.

  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.

  Last Modified

  The timestamp for the last revision, which provides a quick indicator for the last time a Git 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.

Using Git Sub-Modules

If you use sub-modules, they are typically defined using the full URL of the repository, for example:

git add submodule test2 git@192.168.1.30:/home/wandisco/repos/subrepo.git

This adds the following into your .gitmodules file:

[submodule "test2"]
path = test2
url = git@192.168.1.30:/home/wandisco/repos/subrepo.git

It is possible to use them in this way, but this means that submodule activity will occur against a specific Git server. If the repository used as a submodule is being replicated through Git MultiSite, you will lose the benefits of using the repository on a local node.

To maintain the benefits of the replicated environment, specify the relationship to the sub-module using a relative path, such as:

git submodule add REPONAME ../RELATIVE-PATH-TO-REPO

For example:

git submodule add ../subrepo.git test2

This would then add the following entry to your .gitmodules file:

[submodule "test2"]
path = test2
url = ../subrepo.git

Note: If you're using external sub-modules, you can continue to specify them using full URLs. This is only applicable to local sub-modules you want replicated.

2.5 Upgrading Git MultiSite - 1.2.0 to 1.2.1

To upgrade from version 1.2.0 to version 1.2.1 use the following procedure:

1. Connect to each node in the 1.2.0 replication group, by command line, as root.
2. Backup your 1.2.0 databases on each node using the following command:
   

   curl --user <admin user>:<admin password> -X POST http://<node ip address>:8082/api/backup

3. Stop the Git MultSite service on each node:
   

   service git-multisite stop

4. Make a backup of the replicator database to allow for rollback:
   

   cp -r /opt/wandisco/git-multisite/replicator/database/* /path/to/your/backup/directory

5. Copy the 1.2.1 installer script to each Node and run it as root
6. Stop the 1.2.1 Git MultiSite service on each node:
   

   service git-multisite stop

7. Change to your gitms user:
   

   su gitms

8. Optional step
   Transform the 1.2.0 backup (produced in step 2 above) into a 1.2.1 backup that can be restored in step 9 below. Run the following two commands to do this:
   

   cd /opt/wandisco/git-multisite/replicator
   java -jar transformer-tool.jar -r /path/to/your/backup/directory

9. As the gitms user, restore from your backup on each node:
   

   java -jar git-ms-replicator-1.2.1.7-gitmsrestore.jar -c properties/application.properties -r /path/to/your/backup/directory

10. Exit from your gitms account back to the root account
11. Start the git-multisite service:
    

    service git-multisite start

12. Finally, check the following:
    • All nodes have running replicators
    • Recplicator and GUI versions are showing 1.2.1
    • You can push to a repository successfully
    • The pushed change is replicated across the entire replication group

2.6 Rollback procedure - 1.2.1 to 1.2.0

If you need to roll back to the previous version of Git Multisite, use the following procedure:

1. Log in as root on each node
2. On each node, uninstall the current version using the following script:
   

   #This script removes the install of git-multsite to be able to install cleanly
   echo "Removing Git-Multisite RPMS"
   yum remove -y git-multisite git-multisite-gui git-multisite-hook git-multisite-all
   echo "Removing Git-Multisite Directory"
   rm -rf /opt/wandisco/git-multisite
   killall java
   cd /tmp
   rm -rf *
   cd

3. On each node, re-install the previous version
4. Stop the git-multisite service:
   

   service git-multisite stop

5. Remove the contents of the Git MultiSite database directory:
   

   rm -r /opt/wandisco/git-multisite/replicator/database/*

6. Change to the gitms user:
   

   su gitms

7. On each node, copy the content of your backed up database directory into place:
   

   cd /opt/wandisco/git-multisite/replicator/database
   cp -r /path/to/your/backup/directory/* .

8. Check the database directory and all its contents are owned by gitms:gitms and permissions are set to 755
9. Exit from your gitms account back to the root account
10. Restart the git-multisite service:
    

    service git-multisite start

11. Finally, check the following:
    • All nodes have running replicators
    • Recplicator and GUI versions are showing 1.2.0
    • You can push to a repository successfully
    • The pushed change is replicated across the entire replication group

Copyright © 2010-2013 WANdisco plc.
All Rights Reserved

This product is protected by copyright and distributed under licenses restricting copying, distribution and decompilation.

Git MultiSite
Last doc build: 16:45 - Thursday 3rd July 2014