GENESIS: Documentation

Related Documentation:

Create a Backup Server for the Repository

This is a guide to setting a backup_server option in order to synchronize with a backup server in the event that the primary server is unconnectable.

Setting the backup server address for the client

In the developer package, located in ~/neurospaces_project/developer/source/snapshots/0 there is a script in the bin directory named neurospaces_build. To set the backup server address there is an associative array value that must be set. For example:

my $version_control_servers  
   = [  
      {  
        name => ’default’,  
        address => ’repo-genesis3.cbi.utsa.edu’,  
      },  
      {  
        name => ’default2’,  
        address => ’repo.cbi.utsa.edu’,  
      },  
      {  
        name => ’backup_server’,  
        address => ’129.115.117.50’,  
      },  
      {  
        name => ’mercurial_server’,  
        address => ’http://repo-genesis3.cbi.utsa.edu/hg/’,  
      },  
    ];

For the value for backup_server set address to the intended host address using a text editor, then save the changes. Next the scripts must be installed to your system, so perform:

   neurospaces_install --regex developer

and your updated script is installed and ready to use. This will allow you to pull from the indicated backup repository should it be listening.

Client Operations

pulling revisions

To perform a pull from the backup server enter the command:

   neurospaces_pull --repo-pull backup_server

To perform an upgrade of your system against the backup repository perform the command:

   neurospaces_upgrade --repo-pull backup_server

synchronizing with a repository

To synchronize with a repository backup server issue the command:

   neurospaces_sync --repo-sync backup_server

For this to succeed you must be given write permission on the backup server’s repositories.

Setting your machine up as a “backup” server

Permissions

There are two files which manage permissions in monotone:

To allow all users to pull from your repositories enter:

   pattern "*"  
      allow "*"

into your  /.monotone/read-permissions file.

To allow users to write to your repositories they must first have their public key stored on your databases. You can check to see which keys are currently present via the command:

   mtn list keys

when you are in your project workspace directory. This will list a hash along with the email address used to identify the key. For example:

   [public keys]  
   23f8b6bee72df6421e49cec4a766225c0604046c user1@email.com  
   1e12560c49d1ca8f23dcf360ce6e6eaebc46c251 user2@email.com  
   2d451ae15d697afb4f92cb04ca7a582c90434130 user3@gmail.com  
   cbc91b2ec1d19e95f64cb164cc2166f4bdfe7bf4 user4@email.com

Now if a user has a public key present, all that needs to be done is to enter each identifier email you wish to give access once per line in the file ~/.monotone/write-permissions. The following write-permissions file will grant user2, user3, and user4 access, since they already have a corresponding key stored in the repository:

   user2@email.com  
   user3@email.com  
   user4@email.com

NOTE: This file would exclude user1, who will still be able to pull from the repository but will be unable to write (or push) to it. If you need to read in new public keys into your repositories to allow new users access see Developer Repository.

Serving repositories

To serve your own repositories to another user you must provide them with your ip address so that they can input it into the data array in neurospaces_build. Opening up a page like whatismyip.com/ or whatismyipaddress.com/ will provide you with your ip address quickly. Once the intended user has entered your ip you can serve your repositories via the command:

   neurospaces_serve

Status messages should then appear in the terminal window indicating when a client has successfully connected to your machine or if there was a connection error.

It is common for non-standard ports to be blocked via a firewall on some networks. If your client has been configured correctly and the backup server appears to be online, but no monotone connection is made, check with your network administrator to see if ports 4692–4700 are currently blocked by the firewall.