Systems Configurations Administration

The system configuration administration is divided into 3 parts, reachable from the Administration --> Manage --> Configurations menu

  • Manage Hosts' configuration : manage the host name and IP addresses assigned to systems for the event (in the event floor)
  • All configurations : manage all the configuration of all the systems
  • OIDs management : manage the OIDs to be used by system during the event


Network Configuration

Before managing the hosts and the system network configurations, you need to configure the network of the testing event. To do this, go to Configurations --> Network configuration Overview. This page is made of three sections materialized by three tabs.

Hosts configuration

This page shows to text area. In the first one, you can give tips to the user regarding the network configuration during the event. We usually provide the Wireless SSID and keys, the subnet information (netmask, gateway, DNS server, internal domain name and so on), the URL of the tools and their IP addresses.

In the second area, you are requested to provide the header of the host file so that people will be able to download a complete host file gathering the hostnames and addresses of all the systems connected during the connectathon.

Participants to the testing session who do not want to use DNS can download the host file and use it to configure their system. THIS OPTION IS NOT RECOMMENDED BUT WAS IMPLEMENTED FOR ONE DEVICE THAT COULD NOT USE DNS. DNS IS THE PREFERRED SOLUTION AS IT IS DYNAMIC !

Configure IPs and DNS

Filling out those information will help the tool with assigning IP addresses and build the DNS and DNS reverse file. 

Example of DNS file header and DNS reverse file header are provided below.

; BIND data file for local loopback interface
$TTL    604800
@    IN      SOA root.localhost. (
                              1         ; Serial
                         604800         ; Refresh
                          86400         ; Retry
                        2419200         ; Expire
                         604800 )       ; Negative Cache TTL
@                      IN      NS
@                   IN      A
ntp                  IN  A
dns                  IN  A
ihe-eu0            IN  A
gazelle            IN  A
proxy              IN  A
printer             IN  A
syslog           IN  A
central-archive     IN  A
central    IN  A
gazelle-tools     IN  A
dvtk    IN A
$TTL    86400
@       IN      SOA (
                              1         ; Serial
                         604800         ; Refresh
                          86400         ; Retry
                        2419200         ; Expire
                          86400 )       ; Negative Cache TTL
; authoritative name server
;       NS
@       IN      NS
10.0  PTR
10.0  PTR
10.0  PTR
11.0  PTR
11.0  PTR
12.0  PTR
12.0 PTR
13.0 PTR
13.0 PTR

DNS automatic configuration on the server

In order to automatically update the DNS configuration on the server that is hosting the Gazelle Test Management application, one need to run the following script update_dns.csh

  • Download the script and place it in the directory /opt/gazelle/dns
  • install bind9 on the server :
apt-get install bind9 


You also need to configure bind9 (see documentation) in order to add a new zone that matches the requirement of the network on your session. 

In the file /etc/bind/named.conf.local add a line specific to your zone 

include "/etc/bind/named.conf.ihe-zones" 


Here is an example of the file named.conf.ihe-zones as used at one of our event for illustration. Note that the file makes references to the 2 files created by the update_dns.csh script.

zone "" IN {
  type master;
  file "/etc/bind/";
  forwarders {;

zone "" IN {
  type master;
  file "/etc/bind/db.192.168";
  forwarders {;

zone "" {
  type master;
  file "/etc/bind/reverse.192.168";


Finally edit the script update_dns.csh and configure it in order to match the configuration of your network and the session in use.

Currently the DNS can only be updated for ONE SINGLE testing session. 

We recommend to use a cron to automatically update the DNS configuration on the server 

*/15 * * * * /opt/gazelle/dns/update_dns.csh


Then SUT can be configured to point to the DNS server that is configured that way. 

Configure IPs and port for proxy

You may have configue the URL of the proxy in the application preferences. However, you might not want to use the Gazelle Proxy tool for all the testing event registered in the tool. From this page, you can enable/disable the use of the proxy during the event. In order to help users with using the Proxy, you are asked to provide the IP address used to contact it. 

When generating the system network configurations, if the proxy is enabled, each configuration will have a proxy port assigned. You need to provide the range of port used by the proxy so that the tool knows which values are allowed.

From this page, you can also start all the channels on the proxy; that means that the tool will gather all the system network configuration of receivers and tell the proxy to open the corresponding ports.

Manage Hosts' configuration

The list of hosts which is displayed on that page is restricted to the host assigned to the systems from the testing session you are currently logged in. If you need to access the list of hosts for another testing event, you need to change your testing session from the Gazelle --> Change testing session menu.


From the Manage Hosts' configuration page, you can assign internal IP addresses to all the hosts/systems registered for the testing event or you can even release all the IP addresses. The latter means that for each host defined in this testing session, the IP address will be set to null.

  • A host name in Gazelle Test Management has the following attribute
  • The system it is assigned to
  • The host name
  • An alias for this host name
  • The assigned IPv4 address 
  • A comment about its usage

You can edit each host and then get additional options/informations:

  • Is the host external to the testing event network
  • Assign the next available IP address from the range defined for the event

All Configurations

A network system configuration gives information to the user on how to configure their systems for the testing event and how to reach the systems of their partners for testing. Which type of configuration is requested by each actor is defined in Gazelle Master Model. 

From menu Administration --> Manage --> Configurations --> All configurations, you will access the list of configurations defined for the testing session you are currently logged in. From this page, you can edit each configuration one by one, approve it (it is usually an action to be performed by the SUT operator) or delete it.

"Add a config" button will allow you to create a new entry in the list for a system registered in the testing session you are currently logged in.

"Generate configs for selected session" will generate all the entries for all the systems registered in the testing session. Note that this task is long and performed in background; you will have to refresh the page latter on to get the list of configurations.

Note that if you select an Organization in the filter available at the top of the page, you will get a button to generate the configurations for all the systems owned by this organization; if you select a system from this same filter, you will get a button to generate the configuration for this specific system.

OIDs management

In some profiles, the messages or the documents described must be populated with OIDs. An Object Identifier shall be unique, it is composed of a root, managed by an authority and the rest manage by the system to which the root is assigned; in order to help vendor to configure their system, Gazelle Test Management offers a feature to manage the OID roots. 

From menu Administration --> Manage --> Configuration --> OIDs management, you will access a page divided into four tabs; they are described below:

OID - System assignement

In this tab, you will find the list of OID roots assigned to the systems registered within the tool. You can filter the list by testing session; knowing that the testing session set when you accessed the page is the testing session you are currently logged into.

Note that you can edit those values by clicking on the edit icon.

OID requirements

This section allows the administrator of the tool to define for which actors OIDs need to be defined and what this OID will be used for. You can edit, delete or create requirements. Before creating a new requirement, if you intent to use an OID different from the ones already used, first jump to OID Roots tab to define a new OID. Note that those OID requrements are common to all the testing sessions.

When you edit or create a requirement, you are ask to provide the list of Actor/Integraiton Profile/ Option tuples to which it applies; to do so, use the "add AIPO" button; select your AIPO and click on the "Add new AIPO" button.

You can also remove an AIPO from the list, only click on the red cross in the table on the corresponding line.

OID Roots

Here are listed all the OID roots which are used to build OIDs; the last value coming from the database is already displayed there. For each root, you can also provide a comment to inform the users what this root is used for.

You can edit and delete root OID, you can also create new ones; only click on the "Add a new OID Root" button and fill out the form which appears in the pop-up. Note that those roots are common to all the testing sessions.

OID Testing Session Management

From this section, you are allowed to perform three actions:

  • Removing all the OIDs which have been assigned to the systems registered to the current testing session
  • Removing and generating again all the OIDs for the current testing session
  • Updating the OIDs assigned to the systems; that means that systems which have been newly added will get OIDs and if no requirements have been creating, they will be applied to the concerning systems.