---
canonical: https://safekit.evidian.com/wp-content/uploads/downloads_safekit/version-82/safekituserguidehtml/documentation/safekituserguideen.htm
---
# 15. Examples of application module configurations
Section 15.1 “Mirror module example with mirror.safe”
Section 15.2 “Farm module example with farm.safe”
Section 15.3 “Macro and script variables example with hyperv.safe”
Section 15.4 “Process monitoring example with softerrd.safe”
Section 15.5 “TCP checker example”
Section 15.6 “Ping checker example”
Section 15.7 “Custom checker example with customchecker.safe”
Section 15.8 “Split-brain checker example”
Section 15.9 “Module checker example”
Section 15.10 “Interface checker example”
Section 15.11 “IP checker example”
Section 15.12 “Virtual hostname example with vhost.safe”
Some examples are taken from the application
modules delivered with the SafeKit package, under SAFE/Application\_Modules. Many real integration examples are also described in SafeKit Quick Installation Guides.
| | |
| --- | --- |
| Commentaire important contour | The .safe are platform dependent and therefore different in Windows and Linux, mainly for application module scripts. |
The application module configuration can be
modified in two ways:
·
either through the module configuration wizard
in the SafeKit web console (see section 3.3)
·
or by directly editing the files SAFE/module/AM/conf/userconfig.xml or the scripts under SAFE/module/*AM*/bin (where *AM* is
the name of the installed module)
To take effect, at the next application
module startup, the new configuration must be applied:
·
either at the last step of the module
configuration wizard
·
or with the command safekit config -H "node1,node2" -E
AM executed on the node where the files have been
modified
| | |
| --- | --- |
| Commentaire important contour | Before applying the configuration, close all editors, file explorers, shells, or command prompts that may access a file under SAFE/modules/*AM* on the nodes. |
## 15.1 Mirror module example with mirror.safe
Below is the configuration of the mirror
module, mirror.safe.
To test a mirror module, refer to section 4.2.
| | |
| --- | --- |
| Commentaire, ajouter contour | The following description is for Windows. For Linux, please refer to mirror.safe delivered with the Linux package that includes Linux configuration and scripts. |
### 15.1.1 Cluster configuration with two networks
The cluster configuration includes two
networks, such as default and private. The second network is designed to illustrate the configuration of
a dedicated network for replication traffic within the module configuration.
Most configurations typically include only one network.
| | |
| --- | --- |
| SafeKit web console image Edit the cluster configuration using cluster configuration wizard. Add a new LAN and define IP addresses of 2 nodes on both networks To start the cluster configuration wizard, refer to section 3.2. Switch to “Advanced configuration” to edit the XML if needed. | For detail on XML configuration refer to section 12.1. |
### 15.1.2 Mirror module configurations
The mirror.safe delivered
since SafeKit 8.2.4, has been enhanced to allow the definition of the
services list using a macro called SERVICES into the module configuration. The
module scripts utilize this value to:
·
check that the listed services exist on the
server and disable their automatic startup at boot during module configuration
·
automatically start and stop the listed services
when necessary, during the module runtime
Therefore, integrating a new application
using mirror.safe is limited to:
·
getting the names of the relevant services
To list all
installed services on a server, use:
o the PowerShell cmdlet Get-Service in Windows
o the command systemctl
list-unit-files --type=service in Linux
·
determining the paths of the directories to
replicate
·
obtaining an unused IP address as the virtual IP
Below are examples of mirror module
configurations, featuring a virtual IP address, real-time replication, and
failover.
#### 15.1.2.1 Configuration with a virtual IP address, real-time replication, and failover
The following configuration use only one
network for the heartbeats and replication flow.
| | |
| --- | --- |
| To start the module configuration wizard, refer to section 3.3. Switch to “Advanced configuration” to edit the XML if needed. | For detail on XML configuration of: · refer to section 13.2 · refer to section 13.3 · refer to section 13.4 · refer to section 13.6 · refer to section 13.7 · , refer to section 13.8 |
| | |
| --- | --- |
| Commentaire, ajouter contour | Define the names of the services in the SERVICES macro. These services will be automatically started and stopped by the module's scripts of SafeKit 8.2.4's mirror.safe. |
#### 15.1.2.2 Configuration of a dedicated replication network
The module is configured to use both cluster
networks as defined in section 15.1.1. The one named private is
selected as the “Replication flow” for
replication traffic.
| | |
| --- | --- |
| SafeKit web console image Edit a mirror module configuration with a virtual IP address, real-time replication, failover, and dedicated replication network, using module configuration wizard To start the module configuration wizard, refer to section 3.3. Switch to “Advanced configuration” to edit the XML if needed. | For detail on XML configuration see section 13. |
### 15.1.3 Mirror module scripts
Below are Windows scripts of the mirror
module to start/stop services on the primary node. For Linux, please refer to
the mirror.safe delivered with the Linux package that includes Linux scripts.
For detail on
module scripts, refer to section 14.
For details on script logging (with echo, Write-Host and safekit
printe commands), refer to section 14.3.
With the mirror.safe module
delivered since SafeKit 8.2.4, the user no longer needs to modify the scripts
to insert the start and stop commands for each service. Indeed, the new module
scripts use the value of SERVICES to retrieve the names of the services to be started or stopped.
Below, we still show how to edit the
scripts in case you need to adapt them for specific needs. For example, milestone.safe requires starting App pools after the IIS service has been started.
It does not present any difficulty to adapt the generic script to insert this
operation.
#### 15.1.3.1 start\_prim script
start\_prim script is called when the mirror module is starting as primary
(manual or automatic start
after stopstart or wait) or restarting on a primary node (restart). It must contain the start of the services integrated into the
module. The services run on only on the primary node.
| | |
| --- | --- |
| | … # Start and check of services defined in SERVICES Write-Host "--- Start and check of SERVICES $($servicesArray -join ', ')" foreach ($serviceName in $servicesArray) { # Start the service … # Check the service status } |
| | |
| --- | --- |
| Commentaire, ajouter contour | With the mirror.safe module delivered since SafeKit 8.2.4, the script stops the module if a service start fails or does not reach a started status. This behavior can be changed by commenting out the call to the function Stop\_Module\_And\_Exit. |
#### 15.1.3.2 stop\_prim script
stop\_prim script is called when the module is stopping (stop, stopstart or wait) or restarting on a primary node (restart). It must contain the stop of the services integrated into the
module.
| | |
| --- | --- |
| | … $gracefulStop = ($args[0] -ne "force") … # Stop and check of services if ($gracefulStop) { Write-Host "--- Stop and check of SERVICES $($servicesArray -join ', ')" foreach ($serviceName in $servicesArray) { # Graceful stop # Stop the service … } } … |
## 15.2 Farm module example with farm.safe
Below is the configuration of the farm
module, farm.safe.
To test a mirror module, refer to section 4.3.
| | |
| --- | --- |
| Commentaire, ajouter contour | The following description is for Windows. For Linux, please refer to farm.safe delivered with the Linux package that includes Linux configuration and scripts. |
### 15.2.1 Cluster configuration with three nodes
The cluster configuration includes a single
network, named default, and three nodes to demonstrate advanced load balancing
configuration. Most cluster configurations typically include only two nodes.
| | |
| --- | --- |
| Commentaire important contour | Only a farm module with load balancing and no replication can be configured on more than 2 nodes. A mirror module with replication can be configured only on two nodes. |
| | |
| --- | --- |
| SafeKit web console image Edit the cluster configuration using cluster configuration wizard. Define 1 LAN and IP addresses of 3 nodes on this network, for a farm module To start the cluster configuration wizard, refer to section 3.2. Switch to “Advanced configuration” to edit the XML if needed. | For detail on XML configuration refer to section 12.1. |
### 15.2.2 Farm module configurations
The farm.safe delivered
since SafeKit 8.2.4, has been enhanced to allow the definition of the
services list using a macro called SERVICES into the module configuration.
The module scripts utilize this value to:
·
check that the listed services exist on the
server and disable their automatic startup at boot during module configuration
·
automatically start and stop the listed services
when necessary, during the module runtime
Therefore, integrating a new application
using farm.safe is limited to:
·
getting the names of the relevant services
To list all
installed services on a server, use:
o the PowerShell cmdlet Get-Service in Windows
o the command systemctl
list-unit-files --type=service in Linux
·
obtaining an unused IP address as the virtual IP
·
determining the load-balancing rules
Below are examples of the farm module
configurations, featuring a virtual IP address, load-balancing rules, and
failover.
#### 15.2.2.1 Configuration with a virtual IP address, load-balancing rule, and failover
The defined load-balancing rule defined
below, allows you to view the load distribution among the nodes by accessing
the SafeKit web page http://host:9010/safekit/mosaic.html.
| | |
| --- | --- |
| To start the module configuration wizard, refer to section 3.3. Switch to “Advanced configuration” to edit the XML if needed. | For detail on XML configuration of: · refer to section 13.2 · refer to section 13.3 · refer to section 13.5 · refer to section 13.6 · , refer to section 13.8 |
Other examples of load balancing rules
configuration are described in the following.
#### 15.2.2.2 Configuration of TCP load-balancing rules
Below is the load balancing configuration
for accessing the virtual IP using the TCP protocol on the specified ports:
·
80 (HTTP), 443 (HTTPS), 8080 (HTTP proxy)
With HTTP
and HTTPS, network load balancing is set on the client IP source address and
not on the client TCP source port, to ensure that the same client is always
connected to the same web server over several TCP connections (stateful versus
stateless servers: see section 1.3.3).
·
389 (LDAP) et 23 (Telnet)
| | |
| --- | --- |
| SafeKit web console image Edit a farm module configuration with a virtual IP address, TCP load-balancing rules, and failover, using module configuration wizard To start the module configuration wizard, refer to section 3.3. Switch to “Advanced configuration” to edit the XML if needed. | For details on configuration, refer to section 13.6.6. |
#### 15.2.2.3 Configuration of UDP load-balancing rules
Below is the load balancing configuration
for accessing the virtual IP using the UDP protocol on the specified ports:
·
53 (DNS)
·
1645 (RADIUS)
With "on\_ipid", the load balancing is made on the IP identifier field in the
packet IP header. The load balancing works even if the client always presents
the same client IP address and client port at input.
| | |
| --- | --- |
| SafeKit web console image Edit a farm module configuration with a virtual IP address, UDP load-balancing rules, and failover, using module configuration wizard To start the module configuration wizard, refer to section 3.3. The wizard do not present on\_ipid filter. Switch to “Advanced configuration” to edit it. | For details on configuration, refer to section 13.6.6. |
#### 15.2.2.4 Configuration with power attribute
The power attribute is
used to define priorities between nodes for handling traffic directed to the
virtual IP. With the following configuration example, you are defining a farm
of 3 nodes with a priority for HTTP traffic on the 1st node (port
80), HTTPS on the 2nd node (port 443) and proxy HTTP on the 3rd
node (port 8080).
| | |
| --- | --- |
| SafeKit web console image Edit a farm module configuration with a virtual IP address, advanced load-balancing rules, and failover, using module configuration wizard To start the module configuration wizard, refer to section 3.3. The wizard do not present details on the load-balancing groups. Switch to “Advanced configuration” to edit them. | Une image contenant texte, capture d’écran, Police Le contenu généré par l’IA peut être incorrect. <**group** name="http\_service"> <**group** name="https\_service"> <**group** name="httpproxy\_service"> For details on configuration, refer to section 13.6.6. |
#### 15.2.2.5 Configuration with scriptcontrol="on" attribute
By default, with scriptcontrol="off", the opening and closing of traffic to the virtual IP (VIP) are
automatically managed by SafeKit based on the module’s state:
·
Traffic to the VIP is opened before the
execution of start\_both, when the module transitions to the UP (Ready)
state. This activates load balancing on the node.
·
Traffic to the VIP is closed after the execution
of stop\_both, when the module leaves the UP (Ready)
state. This deactivates load balancing on the node.
While this default behavior suits most
applications, it may not be appropriate for those with particularly long
startup times. In such cases, traffic to the VIP may be opened before the
application is ready to handle it, causing a temporary service disruption for
the client.
With scriptcontrol="on", automatic control is disabled and can be performed manually via
command line at the appropriate time:
·
Traffic to the VIP can be opened in the start\_both
script after the application has started
·
Traffic to the VIP can be closed in the stop\_both
script before the application shuts down
Below is an example of a farm configuration
where the scriptcontrol="on" attribute is set in the “Advanced configuration”.
| | |
| --- | --- |
| Une image contenant texte, capture d’écran, logiciel, Logiciel multimédia Le contenu généré par l’IA peut être incorrect. To start the module configuration wizard, refer to section 3.3. Switch to “Advanced configuration” to edit the scriptcontrol attribute. | For details on configuration, refer to section 13.6 |
Additionally, when scriptcontrol="on" is configured, it is necessary to add the module’s update
script to support dynamic reconfigurations of the cluster or the module. For
more details on the script contents, see section 15.2.3.2.
### 15.2.3 Farm module scripts
Below are Windows scripts for a farm module
to start/stop services on all nodes. For Linux, please refer to the farm.safe
delivered with the Linux package that includes Linux scripts.
For detail on module scripts, refer to section 14.
For details on script logging (with echo,
Write-Host and safekit printe commands), refer to section 14.3.
With the farm.safe module
delivered since SafeKit 8.2.4, the user no longer needs to modify the scripts
to insert the start and stop commands for each service. Indeed, the new module
scripts use the value of SERVICES to retrieve the names of the services to be started or stopped.
Below, we still show how to edit the
scripts in case you need to adapt them for specific needs. For example, with
the scriptcontrol="on" attribute, it is necessary to add the commands to open and close
traffic to the virtual IP. This does not present any difficulty, as the generic
script can be easily adapted to include these commands.
#### 15.2.3.1 Farm module scripts (with the default attribute scriptcontrol="off")
##### 15.2.3.1.1 start\_both script
start\_both script is called when the farm module is starting (manual or
automatic start after stopstart
or
wait) and restarting (restart). It must contain the start of the application integrated into the
module. The application runs on all nodes.
| | |
| --- | --- |
| | … # Start and check of services defined in SERVICES Write-Host "--- Start and check of SERVICES $($servicesArray -join ', ')" foreach ($serviceName in $servicesArray) { # Start the service … # Check the service status } |
| | |
| --- | --- |
| Commentaire, ajouter contour | With the farm.safe module delivered since SafeKit 8.2.4, the script stops the module if a service start fails or does not reach a started status. This behavior can be changed by commenting out the call to the function Stop\_Module\_And\_Exit. |
##### 15.2.3.1.2 stop\_both script
stop\_both script is called when the farm module is stopping (stop, stopstart or wait exit) or restarting (restart). It must contain the stop of the
application integrated into the module.
| | |
| --- | --- |
| Une image contenant texte, capture d’écran, logiciel, Police Le contenu généré par l’IA peut être incorrect. | Une image contenant texte, capture d’écran, Police, ligne Le contenu généré par l’IA peut être incorrect.… $gracefulStop = ($args[0] -ne "force") … # Stop and check of services if ($gracefulStop) { Write-Host "--- Stop and check of SERVICES $($servicesArray -join ', ')" foreach ($serviceName in $servicesArray) { # Graceful stop # Stop the service … } } … |
#### 15.2.3.2 Farm module scripts (with the attribute scriptcontrol="on")
With scriptcontrol="on", it is necessary to add traffic control commands to the module
scripts to manage access to the virtual IP:
·
Traffic to the VIP is opened using the command:
SAFE/safekit -r saferpc\_send vipd SETGROUPS
all all all
·
Traffic to the VIP is closed using the command:
SAFE/safekit -r saferpc\_send vipd SETGROUPS
none none none
Additionally, the module’s update
script must be added (in the same location as start\_both and stop\_both)
to support dynamic reconfigurations of the cluster or the module.
##### 15.2.3.2.1 start\_both script
Below is the start\_both script,
which includes, in addition to the standard version, calls to traffic control
commands for the virtual IP:
·
Closing traffic (for safety) before starting the
services
·
Opening traffic after the services have started
| | |
| --- | --- |
| Une image contenant texte, capture d’écran, logiciel Le contenu généré par l’IA peut être incorrect. | Une image contenant texte, capture d’écran, Police, ligne Le contenu généré par l’IA peut être incorrect.… **# Close traffic to the VIP** **& "$env:SAFE\safekit" -r saferpc\_send vipd SETGROUPS none none none** # Start and check of services defined in SERVICES Write-Host "--- Start and check of SERVICES $($servicesArray -join ', ')" foreach ($serviceName in $servicesArray) { # Start the service … # Check the service status } **# Open traffic to the VIP** **& "$env:SAFE\safekit" -r saferpc\_send vipd SETGROUPS all all all** |
##### 15.2.3.2.2 stop\_both script
Below is the stop\_both script,
which includes, in addition to the standard version, calls to traffic control
commands for the virtual IP:
·
Closing traffic before stopping the services
| | |
| --- | --- |
| Une image contenant texte, capture d’écran, logiciel, Police Le contenu généré par l’IA peut être incorrect. | Une image contenant texte, capture d’écran, Police, ligne Le contenu généré par l’IA peut être incorrect.… **# Close traffic to the VIP** **& "$env:SAFE\safekit" -r saferpc\_send vipd SETGROUPS none none none** $gracefulStop = ($args[0] -ne "force") … # Stop and check of services if ($gracefulStop) { Write-Host "--- Stop and check of SERVICES $($servicesArray -join ', ')" foreach ($serviceName in $servicesArray) { # Graceful stop # Stop the service … } } … |
##### 15.2.3.2.3 update script
This script is not provided by default and
must be added (in the same location as start\_both and stop\_both)
to support dynamic reconfigurations of the cluster or the module. During a
dynamic reconfiguration, the module executes the update action, which
stops and then restarts the load balancer manager (vipd). With scriptcontrol="on", the manager keeps traffic to the VIP closed. The update script
opens traffic to the VIP if the module is in the UP state.
| | |
| --- | --- |
| Switch to “Advanced configuration” to add or edit the update script | Une image contenant texte, capture d’écran, Police, ligne Le contenu généré par l’IA peut être incorrect. # Script called on module update $scriptName = Split-Path -Path $PSCommandPath -Leaf Write-Host "Running ${scriptName} $args" if ($args.Count -ge 2 -and $args[0] -eq "UP" -and $args[1] -eq "UP") { # Open traffic to the VIP & "$env:SAFE\safekit" -r saferpc\_send vipd SETGROUPS all all all } exit 0 |
## 15.3 Macro and script variables example with hyperv.safe
The module hyperv.safe brings
high availability to Hyper-V between two Windows servers. It is a mirror module
configuration, with a virtual IP address, real-time replication, and failover. It
is presented to demonstrate the use of macros and module script environment
variables.
### 15.3.1 Module configuration with macros and var
In the following example, four are configured and their values are used to define the replicated
directory path (i.e. E:\Hyper-V\Ubuntu20-1)and the environment variables for
module scripts. Note that in the example, the names of the macros and the
variables are identical, which is not a requirement.
| | |
| --- | --- |
| SafeKit web console image Edit a module configuration with macro, using module configuration wizard To start the module configuration wizard, refer to section 3.3. The wizard do not present the user configuration. Switch to “Advanced configuration” to edit it. | For detail on XML configuration of: · refer to section 13.2. · , refer to section 13.8. |
### 15.3.2 Module scripts with var
Below, the start\_prim.ps1 accesses
the environment variables defined at the time the script is executed:
·
the SafeKit environment variables SAFE and SAFEUSERVAR
·
the module environment variables VM\_PATH, VM\_NAME…
defined in the sections of
For details, refer to section 14.2.
| | |
| --- | --- |
| SafeKit web console image Edit start_prim script of a mirror module, using module configuration wizard | $safe = (Get-Item env:SAFE).Value $suv = (Get-Item env:SAFEUSERVAR).Value $vmname = (Get-Item env:VM\_NAME).Value $vmpath = (Get-Item env:VM\_PATH).Value … |
## 15.4 Process monitoring example with softerrd.safe
The module softerrd.safe is a
demonstration mirror module for process monitoring. This feature is also
available in a farm module.
The tests consist of terminating the
monitored processes (i.e., mybin, myotherbin, or myappli) using the safekit
kill command.
To test the process/service monitoring,
refer to section 4.4.1.
| | |
| --- | --- |
| Commentaire, ajouter contour | The following description is for Windows. For Linux, please refer to softerrd.safe delivered with the Linux package that includes Linux configuration and scripts. |
### 15.4.1 Module configuration with process monitoring
Detecting the shutdown of:
·
mybin.exe causes the module to restart (action="restart"). Its monitoring enabled/disabled after/before the execution of start\_prim/stop\_prim
(class="prim").
·
myotherbin.exe causes a stop of
the module (action="stop"). Its monitoring
enabled/disabled after/before the execution of start\_second/stop\_second (class="second").
·
myappli.exe causes the execution of a special handler restart\_myappli.cmd (action="restart\_myappli") located in the bin directory of the
module. The monitoring of myappli is manually enabled/disabled in the module scripts after/before its
launch/stop (e.g. class="myappli"). Refer to scripts detailed
in section 15.4.2.
This
configuration allows for the individual restart of the myappli process
without having to completely restart the application integrated in start\_prim/stop\_prim.
The actions restart and stopstart
automatically increment the maxloop counter to limit the number of automatic actions in the event of
persistent errors. By default, the
module is stopped on the 4th error detection within 24
hours (see maxloop and loop\_interval in section 13.3.3).
If the action involves executing a special
script, this script must manually manage the maxloop counter
(i.e., restart\_myappli.cmd).
| | |
| --- | --- |
| SafeKit web console image Edit a module configuration with process monitoring or service monitoring, using the module configuration wizard To start the module configuration wizard, refer to section 3.3. The wizard do not present details on class associated to process. Switch to “Advanced configuration” to edit them. | For details on XML configuration of , see section 13.10. |
### 15.4.2 Advanced configuration of module scripts
The module monitors the presence of the
following processes:
·
mybin and myappli started/stopped on the primary node with start\_prim/stop\_prim
·
myotherbin started/stopped on the secondary node with start\_second/stop\_second
| | |
| --- | --- |
| SafeKit web console image Edit start_prim script of a mirror module, using module configuration wizard | @echo off echo "Running **start\_prim** %\*" %SAFE%\safekit printi "start mybin" start %SAFEUSERBIN%\mybin.exe 10000000 %SAFE%\safekit printi "start myappli" start %SAFEUSERBIN%\myappli.exe 10000000 %SAFE%\safekit errd enable myappli Note the call to safekit errd enable myappli to start monitoring the process with class="myappli" once this process is launched. Refer to section 13.10.4 for the description of this command. |
| SafeKit web console image Edit start_prim script of a mirror module, using module configuration wizard | @echo off echo "Running **stop\_prim** %\*" %SAFE%\safekit printi "stop mybin" %SAFE%\safekit kill -level="terminate" -name="mybin.exe" %SAFE%\safekit printi "stop myappli" %SAFE%\safekit errd disable myappli %SAFE%\safekit kill -level="terminate" -name="restart\_myappli.cmd" %SAFE%\safekit kill -level="terminate" -name="myappli.exe" :end Note the call to safekit errd disable myappli to stop monitoring the process with class="myappli", before terminating this process. |
The specific handler restart\_myappli.cmd is editable in "Advanced
Configuration". This script increments the maxloop counter and
restarts the myappli process.
| | |
| --- | --- |
| SafeKit web console image Edit the process restart script called upon process monitoring error detection using the module configuration wizard Switch to “Advanced configuration” to list and edit all scripts. | @echo off %SAFE%\safekit printi "restart\_myappli" rem first disable monitoring of the application %SAFE%\safekit errd disable myappli rem increment loop counter %SAFE%\safekit incloop -i "restart\_myappli" if %errorlevel% == 0 goto next rem max loop reached %SAFE%\safekit stop -i "restart\_myappli" %SAFEBIN%\exitcode 0 :next rem **max loop not reached**: go on restarting the application %SAFE%\safekit printi "Restart myappli" %SAFE%\safekit kill -level="terminate" -name="myappli.exe" start %SAFEUSERBIN%\myappli.exe 10000000 rem finally, enable monitoring of the application %SAFE%\safekit errd enable myappli %SAFEBIN%\exitcode 0 Note the increment of the loop counter with safekit incloop -i "restart\_myappli" and the stopping of the module when maxloop is reached. Refer to section 14.5.3 for the description of this command. |
## 15.5 TCP checker example
Below is an example of the configuration of
a TCP checker in a farm module. This checker tests the connection to the local
web service on port 80. If the connection fails, the checker sets the resource **tcp.**Apache\_80 to down. The
associated failover rule, named **t\_**Apache\_80, executes a restart of the module when the resource goes down.
| | |
| --- | --- |
| Commentaire, ajouter contour | · The resource name prefix is **tcp.** · The failover rule name prefix is **t\_** · The suffix is the value of the attribute ident |
For a description of checkers, refer to section 13.11.3.
To test the TCP checker, refer to section 4.4.2 and section 4.4.3.
| | |
| --- | --- |
| To start the module configuration wizard, refer to section 3.3. Switch to “Advanced configuration” to edit the XML if needed. | For details on XML configuration of , see section 13.12. |