Configuration
The File Replication Service is automatically installed and started on the Bravura Security Fabric server during setup. You can also modify the following parameters related to this service on the Service information page:
Option | Description |
|---|---|
Port number this service is running on | Specifies the port or the shared memory ID to listen on. The default is 2380. |
Command-line options for idfilerep are listed below:
Argument | Description |
|---|---|
-h | Displays usage information. |
-v | Displays version number only. |
-restart | Restart a running service. |
-config | Displays service configuration information. |
-server | Run the service in server mode. |
-start | Starts the service. |
-stop | Stops the server/service |
The File Replication Service (idfilerep) archives existing files before overwriting them. By default, the archived files are stored in the Logs directory for the instance (<Program Files path>\Bravura Security\Bravura Security Fabric\Logs\<instance> ). You can change the archive directory by using the Manage the system > Maintenance > Options > FILE REPLICATION ARCHIVE DIR setting. This directory will be automatically created on the other instances during file replication if it does not already exist.
The Manage the system > Maintenance > Options > FILE REPLICATION TIMEOUT setting is used to specify a timeout value (in seconds) before the File Replication Service disconnects. The default value is 300 seconds. This timeout only applies if servers lose their connection while backing up or deleting files; an error occurs immediately if the servers are unable to maintain a connection while replicating files.
To manually perform file synchronization:
Click Manage the system > Maintenance > File synchronization .
Select all file replication servers that you want to synchronize. You can choose file replication servers and proxy servers.
Click Synchronize .
If any nodes are missing from the File synchronization page (Manage the system > Maintenance > File synchronization), verify that the missing nodes have network connectivity, then restart their File Replication Services. Reload the File synchronization page. The missing nodes should be displayed after restarting their File Replication Services.
If the server on which you are running the File Replication Service cannot access the other replication servers using the hostname (that is, database replication has to use the node’s IP address to connect with other nodes), you can set the "server address" string value in the instance’s registry to broadcast the node’s IP address to other replication nodes. This address can be used to set the file replication information.
You can control whether or not to archive existing files by adding the following registry entry in:
HKLM\SOFTWARE\Bravura Security\Bravura Security Fabric\<instance>\IDFileRep
Entryname | backups |
Value | 0—1 Set to 0 to disable backups |
Datatype | DWORD |
Default | 1 |
The File Replication Service is used in conjunction with updinst . To determine which files and registry settings updinst replicates, there are whitelists and blacklists that specify what data to include and what data to omit in the context of file/registry replication You can write an updinst.cfg file to provide additional configuration.
A sample of updinst.cfg is located in the samples directory. This configuration file must be placed in the \ <instance> \ psconfig \ directory before it can be used by the File Replication Service. Use this configuration file to control which files and registry settings are replicated to other instances (whitelist) and which are not replicated (blacklist). The whitelist settings override blacklist settings.
Warning
All file and configuration modifications should be done on the same server (the primary). When attempting to run updinst from a node other than the primary, an error will occur, and the operation will be aborted. In extreme circumstances there is an option to force external data store replication (-extdb -forcerun) from a secondary node; however that should be done only when that database was corrupted on the primary (and its backups that are created every time the external data store is updated, were also corrupted) but the database, or a backup, survived on a secondary node. If updinst is run from more than one server, or if file or registry changes are made on secondary nodes, it is possible for it to overwrite newer files or settings that exist on secondary nodes. If a server with missing files runs updinst , that will remove those same files on all other instances.
Do not attempt to replace Database Service (iddb) files using updinst or the File Replication Service. Updating the Database Service and related files (such as iddbmssql.dll) must be done manually on all instances. This only applies to the Database Service service. All other services can be updated using the File Replication Service. To update the Database Service files manually, shut down all services on the instance, back up all services, and then replace the Database Service files. If a problem occurs during file replication then a notification email is sent to the administrator, and the FILE REPLICATION FAILURE event is triggered.