There is a script at bigworld/tools/server/install/bwlockd.sh that can be used to install the BWLockD service. Run the following command as root in the bigworld/tools/server/install directory.

# ./bwlockd.sh install

This will install the lock server init-script into /etc/init.d/bw_lockd and install symlinks for the /etc/rc*.d directories, such that the lock server starts up at boot.

By default, the log file is at /var/log/bigworld/bwlockd.log. Check the log for a text message saying the daemon is listening on port 8168.

You can edit the installed /etc/init.d/bw_lockd to tune the behaviour of the lock server. In particular, useful variables to change are:

As a system service, you can query the running state of the Lock Server.

# /etc/init.d/bw_lockd status

You can also run the lock server from the command line in the foreground. There are various command-line options as the --help output shows:

usage: bwlockd.py [options] 

options: 

  -h, --help            show this help message and exit 
  --daemon              run process in the background (daemon mode) 
  -I BIND_IP, --bind-ip=BIND_IP 
                        IP/hostname of interface to bind to (default all 
                        interfaces) 
  -p BIND_PORT, --port=BIND_PORT 
                        port to listen on (default 8168) 
  --pid=PID_FILE 
                        default daemon PID file (default "bwlockd.pid") 
  -o OUT_FILE, --output=OUT_FILE 
                        default daemon output file (only applies to non-daemon 
                        mode, default "bwlockd.log") 
  -v, --verbose         verbose output (only applies to non-daemon output, 
                        daemon output is always verbose) 
  --history=HISTORYPATH 
                        output a history file that contains recent lock server 
                        operations in XML format
  --data-dir=DATADIR
                        path to the data directory 

In the event that you remove a space and recreate it before all clients have relinquished their locks on the old space, you may need to clear the locks and restart the lock server.

BWLockD maintains its state in files with the .computer suffix for each workstation that has ever created a lock. Each .computer file is an XML file, such as the one below.

<?xml version="1.0"?>
<hostname>
    <space>
        <name> space_name </name>
        <lock>
            <rect> left top right bottom </rect>
            <username> username </username>
            <desc> lock_description </desc>
            <time> timestamp </time>
        </lock>
        <lock>
            ...
        </lock>
        ...
    </space>
    <space>
        ...
    </space>
    ....
</hostname>

For each space the given host has ever locked, there is a space element that contains a name element for the space, and multiple lock elements that describe the locks that the workstation has currently acquired. Each lock element has a rect element describing the lock rectangle, who locked the region described by the username element, the lock description entered when the lock was made in the desc element, and the lock time in the time element.

It may be necessary to clear locks manually by remove sections from the .computer state files. For example, if a space is removed and a new space is recreated with the same name, any existing locks on the old space will be applied incorrectly to the new space.If modifying the state files is required, you should shut down the lock server, make your changes, and restart the server.

You can run the BWLockD init-script with the remove command line option:

/etc/init.d/bwlockd remove

This will stop any running BWLockD service and remove the startup symlinks so that the service is no longer started on boot.

There is some additional configuration when using Subversion server hosted using the svn+ssh scheme. This is not required for the svn, http or the https schemes. As an example of this, you may have a Subversion URL svn+ssh://developer@repository/srv/repos/your_game/trunk. In this case, there is a user called developer with an account accessible by SSH on machine called repository, and the repository is located at /srv/repos/your_game, and the trunk branch is at the top-level called trunk.

The Subversion version control stub uses the PySVN client, but by default, the it has no way of authenticating automatically with your server over SSH. We supply the authentication mechanism by using PuTTY and its associated utilities PuTTYgen and PLink. To download these tools, go to http://www.chiark.greenend.org.uk/~sgtatham/putty. The documentation for PuTTY can be found on that site as well.

Use PuTTYgen to generate a key-pair to use when authenticating to a Subversion server hosted over SSH. This key-pair can be saved away on the client machine somewhere memorable (it will be saved into a file with a .PPK extension by default). Part of the output of the key-pair generation will be a string that can be used in a SSH authorized_keys file. This string will need to be added to the user's .ssh/authorized_keys on the machine hosting the repository.

PuTTY can also protect the key-pair so that a passphrase is needed to use it. It also comes with a authentication agent called Pageant that you can use to keep decoded keys in memory so that key-pairs that are protected can be used after only unlocking them once per session. Refer to the PuTTY documentation for more details.

Subversion has a per-user config file that can usually be located in the user's directory under Application Data\Subversion\config. A new option needs to be added to the [tunnels] section that calls the PLink executable with the key file that you created in PuTTYgen. For example:

[tunnels]
ssh=C:\Program Files\PuTTY\plink -i C:\...\keypair_file.ppk

The link can be tested by running a command such as svn update on a working copy already checked out (using TortoiseSVN, for example) using the svn+ssh scheme.